perm filename CLCLEA.4[COM,LSP] blob sn#865849 filedate 1988-12-10 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00625 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00091 00002	
C00092 00003	∂08-Oct-88  0048	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 6)  
C00109 00004	∂08-Oct-88  1150	CL-Cleanup-mailer 	Issue: RETURN-VALUES-UNSPECIFIED (Version 4)  
C00112 00005	∂08-Oct-88  1243	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)    
C00133 00006	∂08-Oct-88  1306	CL-Cleanup-mailer 	DRAFT Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)   
C00154 00007	∂08-Oct-88  1818	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 5)  
C00156 00008	∂08-Oct-88  1902	CL-Cleanup-mailer 	Issue: PACKAGE-DELETION (Version 4) 
C00158 00009	∂08-Oct-88  2006	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)   
C00162 00010	∂08-Oct-88  2021	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (version 2)   
C00170 00011	∂08-Oct-88  2211	CL-Cleanup-mailer 	DRAFT Issue: TAILP-NIL (Version 2)  
C00178 00012	∂08-Oct-88  2237	CL-Cleanup-mailer 	Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES   
C00180 00013	∂08-Oct-88  2347	CL-Cleanup-mailer 	DRAFT Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)  
C00183 00014	∂09-Oct-88  0828	CL-Cleanup-mailer 	Re: Issue: TEST-NOT-IF-NOT (Version 1)   
C00185 00015	∂09-Oct-88  0943	CL-Cleanup-mailer 	Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES   
C00187 00016	∂09-Oct-88  0953	CL-Cleanup-mailer 	Re: Issue: PRINT-PRETTY-HOOK (version 1) 
C00190 00017	∂09-Oct-88  1902	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 5) 
C00192 00018	∂10-Oct-88  0800	CL-Cleanup-mailer 	RE: Issue SYMBOL-MACROLET-SEMANTICS, Version 4
C00194 00019	∂10-Oct-88  1111	CL-Cleanup-mailer 	Re: DRAFT Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
C00198 00020	∂10-Oct-88  1252	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)    
C00203 00021	∂10-Oct-88  1352	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
C00207 00022	∂11-Oct-88  0854	CL-Cleanup-mailer 	Issue: LAMBDA-FORM (Version 3) 
C00210 00023	∂11-Oct-88  1000	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (version 2)   
C00213 00024	∂11-Oct-88  1007	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)   
C00215 00025	∂11-Oct-88  1043	CL-Cleanup-mailer 	Re: several hundred ugly things     
C00222 00026	∂11-Oct-88  1601	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION (Version 3)   
C00226 00027	∂11-Oct-88  1614	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION (Version 3)   
C00231 00028	∂11-Oct-88  2004	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION (Version 3)   
C00236 00029	∂13-Oct-88  0726	CL-Cleanup-mailer 	DRAFT Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)  
C00238 00030	∂13-Oct-88  1135	CL-Cleanup-mailer 	Fairfax meeting summary   
C00243 00031	∂13-Oct-88  1147	CL-Cleanup-mailer 	oops  
C00246 00032	∂13-Oct-88  1200	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATIONS (version 3)   
C00251 00033	∂13-Oct-88  1210	CL-Cleanup-mailer 	Issue: DEFSTRUCT-REDEFINITION  
C00253 00034	∂13-Oct-88  1205	CL-Compiler-mailer 	summary on issue LOAD-TIME-EVAL    
C00258 00035	∂13-Oct-88  1232	CL-Cleanup-mailer 	Issue: HASH-TABLE-ACCESS (version 2)
C00262 00036	∂13-Oct-88  1237	CL-Cleanup-mailer 	Issue: ALIST-NIL (Version 4)   
C00264 00037	∂13-Oct-88  1240	CL-Cleanup-mailer 	Issue: ARGUMENTS-UNDERSPECIFIED (Version 4)   
C00266 00038	∂13-Oct-88  1243	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)    
C00268 00039	∂13-Oct-88  1245	CL-Cleanup-mailer 	issue ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS  
C00270 00040	∂13-Oct-88  1246	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATIONS (Version 2)   
C00272 00041	∂13-Oct-88  1248	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 1)
C00274 00042	∂13-Oct-88  1251	CL-Cleanup-mailer 	Issue: COERCE-INCOMPLETE (Version 1)
C00276 00043	∂13-Oct-88  1254	CL-Cleanup-mailer 	Issue: CONSTANT-SIDE-EFFECTS (no proposal)    
C00278 00044	∂13-Oct-88  1255	CL-Cleanup-mailer 	Issue: CONTAGION-ON-NUMERICAL-COMPARISONS (Version 1)   
C00280 00045	∂13-Oct-88  1256	CL-Cleanup-mailer 	issue COERCE-FROM-TYPE    
C00282 00046	∂13-Oct-88  1258	CL-Cleanup-mailer 	Issue: DECLARATION-SCOPE (Version 2)
C00284 00047	∂13-Oct-88  1301	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE  
C00286 00048	∂13-Oct-88  1303	CL-Cleanup-mailer 	Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 2)  
C00288 00049	∂13-Oct-88  1307	CL-Cleanup-mailer 	Issue: DECLARE-FUNCTION-AMBIGUITY (Version 3) 
C00291 00050	∂13-Oct-88  1311	CL-Cleanup-mailer 	Issue: DEFPACKAGE (Version 6)  
C00293 00051	∂13-Oct-88  1314	CL-Cleanup-mailer 	Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 2)    
C00295 00052	∂13-Oct-88  1314	CL-Cleanup-mailer 	Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1)   
C00297 00053	∂13-Oct-88  1315	CL-Cleanup-mailer 	issue DECLARATION-SCOPE   
C00299 00054	∂13-Oct-88  1316	CL-Cleanup-mailer 	Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 2) 
C00301 00055	∂13-Oct-88  1318	CL-Cleanup-mailer 	Issue: DEFSTRUCT-REDEFINITION (Version 1)
C00303 00056	∂13-Oct-88  1319	CL-Cleanup-mailer 	Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 2) 
C00305 00057	∂13-Oct-88  1322	CL-Cleanup-mailer 	Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 3)
C00307 00058	∂13-Oct-88  1324	CL-Cleanup-mailer 	Issue: DESCRIBE-INTERACTIVE (Version 2)  
C00309 00059	∂13-Oct-88  1329	CL-Cleanup-mailer 	Issue: DOTTED-MACRO-FORMS (Version 2)    
C00311 00060	∂13-Oct-88  1333	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION (version 4)   
C00319 00061	∂13-Oct-88  1336	CL-Cleanup-mailer 	issue DEFPACKAGE
C00322 00062	∂13-Oct-88  1337	CL-Cleanup-mailer 	issue DEFSTRUCT-REDEFINITION   
C00324 00063	∂13-Oct-88  1339	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT (Version 1)   
C00326 00064	∂13-Oct-88  1343	CL-Cleanup-mailer 	issue DOTTED-MACRO-FORMS  
C00328 00065	∂13-Oct-88  1343	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 5)  
C00331 00066	∂13-Oct-88  1345	CL-Cleanup-mailer 	Issue: PRINT-CIRCLE-STRUCTURE  
C00333 00067	∂13-Oct-88  1346	CL-Cleanup-mailer 	EVAL-OTHER (Version 2)    
C00335 00068	∂13-Oct-88  1350	CL-Cleanup-mailer 	Issue: EXIT-EXTENT (Version 3) 
C00337 00069	∂13-Oct-88  1351	CL-Cleanup-mailer 	Issue: EXPT-RATIO (Version 2)  
C00339 00070	∂13-Oct-88  1353	CL-Cleanup-mailer 	Issue: FILE-LENGTH-PATHNAME (no proposal)
C00341 00071	∂13-Oct-88  1354	CL-Cleanup-mailer 	issue EXIT-EXTENT    
C00344 00072	∂13-Oct-88  1355	CL-Cleanup-mailer 	Issue: FILE-WRITE-DATE-IF-NOT-EXISTS (no proposal) 
C00346 00073	∂13-Oct-88  1357	CL-Cleanup-mailer 	issue FIXNUM-NON-PORTABLE 
C00348 00074	∂13-Oct-88  1358	CL-Cleanup-mailer 	Issue: FIXNUM-NON-PORTABLE (Version 3)   
C00350 00075	∂13-Oct-88  1359	CL-Cleanup-mailer 	Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
C00352 00076	∂13-Oct-88  1400	CL-Cleanup-mailer 	Issue: FORMAT-PRETTY-PRINT (Version 5)   
C00354 00077	∂13-Oct-88  1401	CL-Cleanup-mailer 	Issue: FUNCTION-CALL-EVALUATION-ORDER (Version 1)  
C00356 00078	∂13-Oct-88  1401	CL-Cleanup-mailer 	issue FUNCTION-COERCE-TIME
C00358 00079	∂13-Oct-88  1401	CL-Cleanup-mailer 	Issue: ELIMINATE-FORCED-CONSING (Version 3)   
C00360 00080	∂13-Oct-88  1405	CL-Cleanup-mailer 	Issue: FUNCTION-COERCE-TIME (Version 2)  
C00363 00081	∂13-Oct-88  1410	CL-Cleanup-mailer 	Issue: FUNCTION-COMPOSITION (Version 2)  
C00366 00082	∂13-Oct-88  1410	CL-Cleanup-mailer 	issue FUNCTION-COMPOSITION
C00368 00083	∂13-Oct-88  1414	CL-Cleanup-mailer 	issue FUNCTION-DEFINITION 
C00370 00084	∂13-Oct-88  1418	CL-Cleanup-mailer 	issue FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS   
C00372 00085	∂13-Oct-88  1420	CL-Cleanup-mailer 	issue HASH-TABLE-ACCESS   
C00374 00086	∂13-Oct-88  1428	CL-Cleanup-mailer 	issue HASH-TABLE-PRINTED-REPRESENTATION  
C00376 00087	∂13-Oct-88  1432	CL-Cleanup-mailer 	Issue: FUNCTION-DEFINITION (Version 1)   
C00379 00088	∂13-Oct-88  1437	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (Version 2)
C00381 00089	∂13-Oct-88  1438	CL-Cleanup-mailer 	issue PACKAGE-CLUTTER
C00383 00090	∂13-Oct-88  1450	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 4) 
C00385 00091	∂13-Oct-88  1452	CL-Cleanup-mailer 	Issue: GC-MESSAGES (Version 1) 
C00387 00092	∂13-Oct-88  1453	CL-Cleanup-mailer 	Issue: GET-MACRO-CHARACTER-READTABLE (no proposal) 
C00389 00093	∂13-Oct-88  1456	CL-Cleanup-mailer 	issue IN-PACKAGE-FUNCTIONALITY 
C00392 00094	∂13-Oct-88  1456	CL-Cleanup-mailer 	Issue: HASH-TABLE-GC (no proposal)  
C00394 00095	∂13-Oct-88  1458	CL-Cleanup-mailer 	issue PACKAGE-DELETION    
C00396 00096	∂13-Oct-88  1519	CL-Cleanup-mailer 	Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 2)    
C00401 00097	∂13-Oct-88  1519	CL-Cleanup-mailer 	issue HASH-TABLE-PRINTED-REPRESENTATION  
C00404 00098	∂13-Oct-88  1521	CL-Cleanup-mailer 	Issue: HASH-TABLE-TESTS (Version 1) 
C00406 00099	∂13-Oct-88  1522	CL-Cleanup-mailer 	Issue: HASH-TABLE-TESTS (Version 1) 
C00409 00100	∂13-Oct-88  1523	CL-Cleanup-mailer 	Issue: IN-PACKAGE-FUNCTIONALITY (Version 2)   
C00411 00101	∂13-Oct-88  1526	CL-Cleanup-mailer 	Issue: LAMBDA-FORM (Version 3) 
C00413 00102	∂13-Oct-88  1526	CL-Cleanup-mailer 	issue PROCLAIM-LEXICAL    
C00417 00103	∂13-Oct-88  1532	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION (Version 3)   
C00420 00104	∂13-Oct-88  1536	CL-Cleanup-mailer 	Issue: LIST-TYPE-SPECIFIER (Version 1)   
C00422 00105	∂13-Oct-88  1537	CL-Cleanup-mailer 	issue REQUIRE-PATHNAME-DEFAULTS
C00424 00106	∂13-Oct-88  1538	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (Version 2)   
C00426 00107	∂13-Oct-88  1539	CL-Cleanup-mailer 	Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 2) 
C00428 00108	∂13-Oct-88  1542	CL-Cleanup-mailer 	Issue: NTH-VALUE (Version 3)   
C00430 00109	∂13-Oct-88  1550	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 4)  
C00433 00110	∂13-Oct-88  1551	CL-Cleanup-mailer 	Issue: PACKAGE-DELETION (Version 4) 
C00435 00111	∂13-Oct-88  1553	CL-Cleanup-mailer 	Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)   
C00437 00112	∂13-Oct-88  1553	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (Version 2)    
C00439 00113	∂13-Oct-88  1555	CL-Cleanup-mailer 	Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)   
C00441 00114	∂13-Oct-88  1557	CL-Cleanup-mailer 	issue HASH-TABLE-PRINTED-REPRESENTATION  
C00444 00115	∂13-Oct-88  1600	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 8) 
C00446 00116	∂13-Oct-88  1806	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 2)    
C00448 00117	∂13-Oct-88  1807	CL-Cleanup-mailer 	Issue: SUBTYPEP-TOO-VAGUE (Version 4)    
C00450 00118	∂13-Oct-88  1807	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 5) 
C00452 00119	∂13-Oct-88  1808	CL-Cleanup-mailer 	Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 5)   
C00454 00120	∂13-Oct-88  1819	CL-Cleanup-mailer 	Re:  issue IN-PACKAGE-FUNCTIONALITY 
C00458 00121	∂13-Oct-88  1820	CL-Cleanup-mailer 	issue TAILP-NIL 
C00459 00122	∂13-Oct-88  1908	CL-Cleanup-mailer 	Re:  issue IN-PACKAGE-FUNCTIONALITY 
C00463 00123	∂13-Oct-88  1909	CL-Cleanup-mailer 	Issue: RETURN-VALUES-UNSPECIFIED (Version 4)  
C00466 00124	∂13-Oct-88  1912	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 2)  
C00469 00125	∂13-Oct-88  1917	CL-Cleanup-mailer 	Issue: HASH-TABLE-ACCESS (version 2)
C00472 00126	∂13-Oct-88  1920	CL-Cleanup-mailer 	issue TEST-NOT-IF-NOT
C00474 00127	∂13-Oct-88  1927	CL-Cleanup-mailer 	Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)    
C00476 00128	∂13-Oct-88  1929	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 5) 
C00478 00129	∂13-Oct-88  1935	CL-Cleanup-mailer 	Issue: STREAM-ACCESS (Version 1)    
C00480 00130	∂13-Oct-88  1940	CL-Cleanup-mailer 	Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 5)   
C00482 00131	∂13-Oct-88  1943	CL-Cleanup-mailer 	issue SYMBOL-MACROLET-SEMANTICS
C00485 00132	∂13-Oct-88  1943	CL-Cleanup-mailer 	issue TAILP-NIL 
C00486 00133	∂13-Oct-88  1943	CL-Cleanup-mailer 	issue UNREAD-CHAR-AFTER-PEEK-CHAR   
C00488 00134	∂13-Oct-88  1940	CL-Compiler-mailer 	Re:  issue IN-PACKAGE-FUNCTIONALITY
C00490 00135	∂13-Oct-88  1804	CL-Cleanup-mailer 	Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)   
C00492 00136	∂13-Oct-88  1804	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (Version 2)    
C00494 00137	∂13-Oct-88  1804	CL-Cleanup-mailer 	Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)   
C00496 00138	∂13-Oct-88  1804	CL-Cleanup-mailer 	issue HASH-TABLE-PRINTED-REPRESENTATION  
C00499 00139	∂13-Oct-88  1804	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 4)  
C00502 00140	∂13-Oct-88  1804	CL-Cleanup-mailer 	Issue: PACKAGE-DELETION (Version 4) 
C00504 00141	∂13-Oct-88  1806	CL-Cleanup-mailer 	Issue: RANGE-OF-COUNT-KEYWORD (Version 3)
C00506 00142	∂13-Oct-88  1806	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 8) 
C00508 00143	∂13-Oct-88  1806	CL-Cleanup-mailer 	Issue: RETURN-VALUES-UNSPECIFIED (Version 4)  
C00511 00144	∂13-Oct-88  1807	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 2)  
C00514 00145	∂13-Oct-88  1807	CL-Cleanup-mailer 	Issue: SETF-FUNCTION-VS-MACRO (Version 3)
C00517 00146	∂13-Oct-88  1807	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (Version 8)  
C00519 00147	∂13-Oct-88  1807	CL-Cleanup-mailer 	Issue: SPECIAL-VARIABLE-TEST (Version 2) 
C00521 00148	∂13-Oct-88  1807	CL-Cleanup-mailer 	Issue: ROOM-DEFAULT-ARGUMENT (Version 1) 
C00523 00149	∂13-Oct-88  1807	CL-Cleanup-mailer 	Issue: STREAM-ACCESS (Version 1)    
C00525 00150	∂13-Oct-88  1807	CL-Cleanup-mailer 	Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)    
C00527 00151	∂13-Oct-88  1807	CL-Cleanup-mailer 	Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
C00529 00152	∂13-Oct-88  1807	CL-Cleanup-mailer 	Issue: TEST-NOT-IF-NOT (Version 2)  
C00531 00153	∂13-Oct-88  2051	CL-Cleanup-mailer 	Issue: FUNCTION-DEFINITION (Version 1)   
C00535 00154	∂14-Oct-88  1058	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT (Version 1)   
C00537 00155	∂14-Oct-88  1058	CL-Cleanup-mailer 	Issue: PRINT-CIRCLE-STRUCTURE  
C00540 00156	∂14-Oct-88  1217	CL-Cleanup-mailer 	WITH-DYNAMIC-EXTENT  
C00547 00157	∂14-Oct-88  1221	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL
C00555 00158	∂14-Oct-88  1239	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL
C00559 00159	∂14-Oct-88  1304	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-GC (no proposal)   
C00563 00160	∂14-Oct-88  1329	CL-Cleanup-mailer 	RE: Issue: HASH-TABLE-ACCESS (version 2) 
C00565 00161	∂14-Oct-88  1434	CL-Cleanup-mailer 	Re: Issue: EQUAL-STRUCTURE (Version 5)   
C00567 00162	∂14-Oct-88  1449	CL-Cleanup-mailer 	Re: DRAFT Issue: TAILP-NIL (Version 2)   
C00569 00163	∂14-Oct-88  1537	CL-Cleanup-mailer 	Re: several hundred ugly things     
C00573 00164	∂15-Oct-88  1015	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL
C00576 00165	∂17-Oct-88  1003	CL-Cleanup-mailer 	Re: Issue: CLOSED-STREAM-OPERATIONS (version 3)    
C00578 00166	∂17-Oct-88  1156	CL-Cleanup-mailer 	New issue: LCM-NO-ARGUMENTS    
C00581 00167	∂17-Oct-88  1213	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATIONS (version 3)   
C00587 00168	∂17-Oct-88  1235	CL-Cleanup-mailer 	RE: Issue: CLOSED-STREAM-OPERATIONS (version 3)    
C00589 00169	∂17-Oct-88  1313	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)    
C00591 00170	∂17-Oct-88  1410	CL-Cleanup-mailer 	New issue: LCM-NO-ARGUMENTS    
C00593 00171	∂17-Oct-88  1512	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
C00601 00172	∂17-Oct-88  1624	CL-Cleanup-mailer 	Issue: HASH-TABLE-ACCESS (version 2)
C00604 00173	∂17-Oct-88  1636	CL-Cleanup-mailer 	DRAFT Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)  
C00606 00174	∂17-Oct-88  1647	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)   
C00609 00175	∂17-Oct-88  1700	CL-Cleanup-mailer 	Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 2)    
C00612 00176	∂17-Oct-88  1717	CL-Cleanup-mailer 	Re: Issue: DEFPACKAGE (version 5)   
C00616 00177	∂17-Oct-88  1716	CL-Cleanup-mailer 	issue HASH-TABLE-PRINTED-REPRESENTATION  
C00619 00178	∂17-Oct-88  1716	CL-Cleanup-mailer 	RE: Issue: HASH-TABLE-ACCESS (version 2) 
C00620 00179	∂17-Oct-88  1748	CL-Cleanup-mailer 	Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 2)    
C00624 00180	∂17-Oct-88  1800	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)   
C00630 00181	∂17-Oct-88  1808	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (version 2)   
C00633 00182	∂17-Oct-88  1840	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)   
C00642 00183	∂17-Oct-88  2021	CL-Cleanup-mailer 	Issue: HASH-TABLE-GC (no proposal)  
C00647 00184	∂17-Oct-88  2130	CL-Cleanup-mailer 	Issue: HASH-TABLE-GC (no proposal)  
C00649 00185	∂17-Oct-88  2349	CL-Cleanup-mailer 	Issue: HASH-TABLE-GC (no proposal)  
C00652 00186	∂18-Oct-88  0841	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C00655 00187	∂18-Oct-88  0852	CL-Cleanup-mailer 	Re: issue HASH-TABLE-PRINTED-REPRESENTATION   
C00657 00188	∂18-Oct-88  0910	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C00660 00189	∂18-Oct-88  0928	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-GC (no proposal)   
C00662 00190	∂18-Oct-88  0953	CL-Cleanup-mailer 	Fairfax notes   
C00664 00191	∂18-Oct-88  1020	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C00668 00192	∂18-Oct-88  1025	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C00670 00193	∂18-Oct-88  1042	CL-Cleanup-mailer 	Issue: HASH-TABLE-GC (no proposal)  
C00676 00194	∂18-Oct-88  1113	CL-Cleanup-mailer 	Issue: HASH-TABLE-GC (no proposal)  
C00681 00195	∂18-Oct-88  1138	CL-Cleanup-mailer 	Issue: TAILP-NIL (version 3)   
C00687 00196	∂18-Oct-88  1148	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
C00691 00197	∂18-Oct-88  1159	CL-Cleanup-mailer 	Issue: HASH-TABLE-GC (no proposal)  
C00700 00198	∂18-Oct-88  1218	CL-Cleanup-mailer 	Issue: TAILP-NIL (version 3)   
C00702 00199	∂18-Oct-88  1220	CL-Cleanup-mailer 	Re: Issue: TAGBODY-CONTENTS    
C00704 00200	∂18-Oct-88  1224	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C00708 00201	∂18-Oct-88  1225	CL-Cleanup-mailer 	RE: Issue: TAILP-NIL (version 3)    
C00710 00202	∂18-Oct-88  1340	CL-Cleanup-mailer 	issue PACKAGE-CLUTTER
C00713 00203	∂18-Oct-88  1428	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 8) 
C00720 00204	∂18-Oct-88  1448	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 8) 
C00724 00205	∂18-Oct-88  1456	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 2)  
C00727 00206	∂18-Oct-88  1539	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C00729 00207	∂18-Oct-88  1541	CL-Cleanup-mailer 	DRAFT Issue: SYMBOL-MACROLET-DECLARE (version 1)   
C00731 00208	∂18-Oct-88  1722	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-GC (no proposal)   
C00734 00209	∂18-Oct-88  2146	CL-Cleanup-mailer 	DRAFT Issue: TEST-NOT-IF-NOT (Version 2) 
C00736 00210	∂19-Oct-88  1153	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 6)
C00743 00211	∂19-Oct-88  1243	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 6)
C00757 00212	∂19-Oct-88  1305	CL-Cleanup-mailer 	Issue: DESCRIBE-INTERACTIVE (Version 3)  
C00764 00213	∂20-Oct-88  1246	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
C00769 00214	∂20-Oct-88  1307	CL-Cleanup-mailer 	DRAFT Issue: TEST-NOT-IF-NOT (Version 2) 
C00773 00215	∂20-Oct-88  1316	CL-Cleanup-mailer 	DRAFT Issue: SYMBOL-MACROLET-DECLARE (version 1)   
C00777 00216	∂20-Oct-88  1719	CL-Cleanup-mailer 	Issue: EVAL-OTHER (Version 2)  
C00781 00217	∂20-Oct-88  1725	CL-Cleanup-mailer 	New Issue: WRITE-NEWLINE  
C00784 00218	∂20-Oct-88  1828	CL-Cleanup-mailer 	Issue: MAKE-STRING-FILL-POINTER (Version 1)   
C00788 00219	∂20-Oct-88  1955	CL-Cleanup-mailer 	Issue: DEFSTRUCT-REDEFINITION  
C00791 00220	∂20-Oct-88  2110	CL-Cleanup-mailer 	Issue: CONSTANT-SIDE-EFFECTS (no proposal)    
C00794 00221	∂21-Oct-88  0807	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-GC (no proposal)   
C00799 00222	∂21-Oct-88  0928	CL-Cleanup-mailer 	New Issue: WRITE-NEWLINE  
C00802 00223	∂21-Oct-88  1102	CL-Cleanup-mailer 	Issue: IN-SYNTAX (Version 1)   
C00809 00224	∂21-Oct-88  1303	CL-Cleanup-mailer 	Issue: THE-AMBIGUITY 
C00816 00225	∂21-Oct-88  1338	CL-Cleanup-mailer 	Issue: STANDARD-VALUE (Version 1)   
C00831 00226	∂21-Oct-88  1347	CL-Cleanup-mailer 	Re: Issue: THE-AMBIGUITY  
C00833 00227	∂21-Oct-88  1400	CL-Cleanup-mailer 	Issue: THE-AMBIGUITY 
C00836 00228	∂21-Oct-88  1400	CL-Cleanup-mailer 	Issue: PATHNAME-PRINT-READ (Version 1)   
C00842 00229	∂21-Oct-88  1401	CL-Compiler-mailer 	Issue: IN-SYNTAX (Version 1)  
C00846 00230	∂21-Oct-88  1415	CL-Cleanup-mailer 	Issue: IN-SYNTAX (Version 1)   
C00851 00231	∂21-Oct-88  1418	CL-Cleanup-mailer 	Issue: PATHNAME-PRINT-READ (Version 1)   
C00853 00232	∂21-Oct-88  1420	CL-Cleanup-mailer 	Issue: IN-SYNTAX (Version 1)   
C00856 00233	∂21-Oct-88  1429	CL-Cleanup-mailer 	Re: Issue: STANDARD-VALUE (Version 1)    
C00859 00234	∂21-Oct-88  1432	CL-Cleanup-mailer 	Re: Issue: STANDARD-VALUE (Version 1)    
C00863 00235	∂21-Oct-88  1435	CL-Cleanup-mailer 	Re: Issue: PATHNAME-PRINT-READ (Version 1)    
C00865 00236	∂21-Oct-88  1511	CL-Cleanup-mailer 	Issue: THE-AMBIGUITY 
C00867 00237	∂21-Oct-88  1520	CL-Cleanup-mailer 	Issue: PACKAGE-FUNCTION-CONSISTENCY (Version 1)    
C00874 00238	∂21-Oct-88  1526	CL-Cleanup-mailer 	Issue: THE-AMBIGUITY 
C00877 00239	∂21-Oct-88  1527	CL-Cleanup-mailer 	Issue: PACKAGE-FUNCTION-CONSISTENCY (Version 1)    
C00879 00240	∂21-Oct-88  1757	CL-Cleanup-mailer 	Issue: LAMBDA-FORM (Version 3) 
C00881 00241	∂21-Oct-88  1854	CL-Compiler-mailer 	issue DEFPACKAGE    
C00887 00242	∂21-Oct-88  1912	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 5)  
C00892 00243	∂21-Oct-88  1951	CL-Cleanup-mailer 	issue DECLARATION-SCOPE   
C00897 00244	∂21-Oct-88  2019	CL-Cleanup-mailer 	Issue: FUNCTION-COERCE-TIME (Version 2)  
C00900 00245	∂21-Oct-88  2032	CL-Cleanup-mailer 	Issue: FUNCTION-COMPOSITION (Version 2)  
C00903 00246	∂24-Oct-88  1816	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
C00909 00247	∂25-Oct-88  1122	CL-Characters-mailer 	Re: cs proposal   
C00918 00248	∂25-Oct-88  1330	CL-Cleanup-mailer 	Re: Issue: THE-AMBIGUITY  
C00921 00249	∂25-Oct-88  1333	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C00924 00250	∂25-Oct-88  1344	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C00927 00251	∂25-Oct-88  1614	CL-Cleanup-mailer 	Re: Issue: ALIST-NIL (Version 4)    
C00929 00252	∂25-Oct-88  1632	CL-Cleanup-mailer 	RE: Issue: CLOSED-STREAM-OPERATIONS (version 3)    
C00933 00253	∂25-Oct-88  1655	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C00937 00254	∂25-Oct-88  1723	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C00942 00255	∂26-Oct-88  0906	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C00945 00256	∂26-Oct-88  1151	CL-Cleanup-mailer 	Issue: COERCE-INCOMPLETE  
C00948 00257	∂26-Oct-88  1151	CL-Cleanup-mailer 	Re: Issue: CONSTANT-SIDE-EFFECTS (no proposal)
C00950 00258	∂26-Oct-88  1320	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATION 
C00953 00259	∂26-Oct-88  1346	CL-Cleanup-mailer 	Issue: CONCATENATE-STREAM-EXAMPLE   
C00956 00260	∂26-Oct-88  1347	CL-Cleanup-mailer 	Issue: INPUT-STREAM-P-EXAMPLE  
C00958 00261	∂26-Oct-88  1350	CL-Cleanup-mailer 	Issue: OUTPUT-STREAM-P-EXAMPLE 
C00960 00262	∂26-Oct-88  1350	CL-Cleanup-mailer 	Issue: STREAM-ELEMENT-TYPE-EXAMPLES 
C00964 00263	∂26-Oct-88  1501	CL-Cleanup-mailer 	Re: Issue: CONCATENATE-STREAM-EXAMPLE    
C00965 00264	∂26-Oct-88  1501	CL-Cleanup-mailer 	Re: Issue: INPUT-STREAM-P-EXAMPLE   
C00967 00265	∂26-Oct-88  1536	CL-Cleanup-mailer 	Re: Issue: STREAM-ELEMENT-TYPE-EXAMPLES  
C00969 00266	∂26-Oct-88  1545	CL-Cleanup-mailer 	Re: issue DECLARATION-SCOPE    
C00971 00267	∂26-Oct-88  1622	CL-Cleanup-mailer 	Re: Issue: DECLARE-FUNCTION-AMBIGUITY (Version 3)  
C00973 00268	∂26-Oct-88  1623	CL-Cleanup-mailer 	Re: Issue: ALIST-NIL (Version 4)    
C00975 00269	∂26-Oct-88  1724	CL-Characters-mailer 	Re: cs proposal   
C00982 00270	∂26-Oct-88  1833	CL-Cleanup-mailer 	Issue: STREAM-ELEMENT-TYPE-EXAMPLES 
C00985 00271	∂26-Oct-88  1837	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATION 
C00987 00272	∂26-Oct-88  1850	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATIONS (version 4)   
C00991 00273	∂26-Oct-88  1911	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C00995 00274	∂26-Oct-88  1912	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C01000 00275	∂26-Oct-88  1946	CL-Cleanup-mailer 	Issue: DESCRIBE-INTERACTIVE (Version 3)  
C01003 00276	∂26-Oct-88  1958	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 6)  
C01007 00277	∂26-Oct-88  2011	CL-Cleanup-mailer 	issue DEFPACKAGE
C01014 00278	∂26-Oct-88  2017	CL-Cleanup-mailer 	logical pathnames    
C01017 00279	∂26-Oct-88  2039	CL-Cleanup-mailer 	issue DECLARATION-SCOPE   
C01020 00280	∂26-Oct-88  2053	CL-Cleanup-mailer 	issue DECLARATION-SCOPE   
C01026 00281	∂26-Oct-88  2102	CL-Cleanup-mailer 	issue SYMBOL-MACROLET-SEMANTICS
C01030 00282	∂26-Oct-88  2141	CL-Compiler-mailer 	Re: issue DEFPACKAGE
C01033 00283	∂27-Oct-88  0947	CL-Cleanup-mailer 	Re: Issue: CLOSED-STREAM-OPERATION  
C01035 00284	∂27-Oct-88  0954	CL-Cleanup-mailer 	Re: issue DEFPACKAGE 
C01039 00285	∂27-Oct-88  1008	CL-Cleanup-mailer 	Re: Issue: STREAM-ELEMENT-TYPE-EXAMPLES  
C01044 00286	∂27-Oct-88  1414	CL-Cleanup-mailer 	DRAFT Issue: SYMBOL-MACROLET-DECLARE (version 1)   
C01048 00287	∂27-Oct-88  1832	CL-Cleanup-mailer 	Issue: TAILP-NIL (version 3), or NTHCDR-P?    
C01053 00288	∂27-Oct-88  1900	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
C01056 00289	∂27-Oct-88  2014	CL-Cleanup-mailer 	Issue: CONSTANT-SIDE-EFFECTS (no proposal)    
C01062 00290	∂27-Oct-88  2214	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)   
C01067 00291	∂27-Oct-88  2230	CL-Compiler-mailer 	Issue: IN-SYNTAX (Version 1)  
C01070 00292	∂27-Oct-88  2247	CL-Cleanup-mailer 	Issue: IN-SYNTAX?    
C01074 00293	∂27-Oct-88  2300	CL-Cleanup-mailer 	Issue: STANDARD-VALUE (Version 1)   
C01077 00294	∂28-Oct-88  0906	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C01081 00295	∂28-Oct-88  1005	CL-Cleanup-mailer 	Re: Issue: CONSTANT-SIDE-EFFECTS (no proposal)
C01087 00296	∂28-Oct-88  1110	CL-Cleanup-mailer 	Issue: IN-SYNTAX?    
C01089 00297	∂28-Oct-88  1151	CL-Cleanup-mailer 	Issue: IN-SYNTAX?    
C01092 00298	∂28-Oct-88  1322	CL-Cleanup-mailer 	Issue: IN-SYNTAX?    
C01095 00299	∂28-Oct-88  1341	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C01098 00300	∂28-Oct-88  1358	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C01101 00301	∂28-Oct-88  1403	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C01103 00302	∂28-Oct-88  1549	CL-Cleanup-mailer 	Issue: IN-SYNTAX?    
C01109 00303	∂28-Oct-88  1645	CL-Cleanup-mailer 	Issue: IN-SYNTAX?    
C01118 00304	∂28-Oct-88  2333	CL-Cleanup-mailer 	issue DECLARATION-SCOPE   
C01128 00305	∂29-Oct-88  0016	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 6)  
C01132 00306	∂30-Oct-88  1339	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C01134 00307	∂31-Oct-88  0957	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 4)  
C01141 00308	∂31-Oct-88  1018	CL-Cleanup-mailer 	Re: Issue: DESCRIBE-INTERACTIVE (Version 3)   
C01145 00309	∂31-Oct-88  1059	CL-Cleanup-mailer 	Re: Issue: DEFPACKAGE (version 6)   
C01148 00310	∂31-Oct-88  1118	CL-Cleanup-mailer 	Re: Issue: DESCRIBE-INTERACTIVE (Version 3)   
C01152 00311	∂31-Oct-88  1200	CL-Cleanup-mailer 	Re: Issue: DESCRIBE-INTERACTIVE (Version 3)   
C01156 00312	∂31-Oct-88  1202	CL-Cleanup-mailer 	Issue: IN-SYNTAX?    
C01160 00313	∂31-Oct-88  1226	CL-Cleanup-mailer 	Re: Issue: DESCRIBE-INTERACTIVE (Version 3)   
C01162 00314	∂31-Oct-88  1358	CL-Cleanup-mailer 	Re: issue EXIT-EXTENT
C01167 00315	∂31-Oct-88  1517	CL-Cleanup-mailer 	Re: issue EXIT-EXTENT
C01170 00316	∂31-Oct-88  1842	CL-Cleanup-mailer 	Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 2) 
C01173 00317	∂31-Oct-88  1843	CL-Cleanup-mailer 	Re: Issue: ELIMINATE-FORCED-CONSING (Version 3)    
C01176 00318	∂31-Oct-88  1843	CL-Cleanup-mailer 	Re: issue EXIT-EXTENT
C01181 00319	∂31-Oct-88  1842	CL-Cleanup-mailer 	Re: Issue: DEFPACKAGE (version 6)   
C01184 00320	∂31-Oct-88  1843	CL-Cleanup-mailer 	Re: issue DOTTED-MACRO-FORMS   
C01186 00321	∂31-Oct-88  1843	CL-Cleanup-mailer 	Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 4)
C01192 00322	∂31-Oct-88  1843	CL-Cleanup-mailer 	Re: logical pathnames
C01195 00323	∂31-Oct-88  1843	CL-Cleanup-mailer 	Issue: EXPT-RATIO (Version 3)  
C01201 00324	∂31-Oct-88  1844	CL-Cleanup-mailer 	Issue: FILE-WRITE-DATE-IF-NOT-EXISTS (no writeup)  
C01208 00325	∂31-Oct-88  1844	CL-Cleanup-mailer 	Re: Issue: FILE-WRITE-DATE-IF-NOT-EXISTS (no proposal)  
C01210 00326	∂31-Oct-88  1844	CL-Cleanup-mailer 	Re: issue EXIT-EXTENT
C01212 00327	∂31-Oct-88  1844	CL-Cleanup-mailer 	Re: Issue FIXNUM-NON-PORTABLE (Version 3)     
C01215 00328	∂01-Nov-88  0657	CL-Cleanup-mailer 	Re: Issue FIXNUM-NON-PORTABLE (Version 3)     
C01218 00329	∂01-Nov-88  1005	CL-Cleanup-mailer 	Re: Issue FIXNUM-NON-PORTABLE (Version 3)     
C01220 00330	∂01-Nov-88  2331	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
C01224 00331	∂01-Nov-88  2348	CL-Cleanup-mailer 	Issue: CONSTANT-SIDE-EFFECTS (no proposal)    
C01228 00332	∂02-Nov-88  1057	CL-Cleanup-mailer 	Re: logical pathnames
C01231 00333	∂02-Nov-88  1612	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
C01236 00334	∂03-Nov-88  1236	CL-Cleanup-mailer 	Issue: ALIST-NIL (Version 4)   
C01238 00335	∂03-Nov-88  1333	CL-Cleanup-mailer 	Issue: SUBTYPEP-TOO-VAGUE (Version 4)    
C01243 00336	∂03-Nov-88  1508	CL-Cleanup-mailer 	Re: Issue: SUBTYPEP-TOO-VAGUE (Version 4)     
C01245 00337	∂03-Nov-88  2021	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 7)  
C01267 00338	∂03-Nov-88  2142	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)    
C01305 00339	∂04-Nov-88  1255	CL-Cleanup-mailer 	New version of proposal format?
C01306 00340	∂04-Nov-88  1619	CL-Cleanup-mailer 	Issue SPECIAL-TYPE-SHADOWING (V1)   
C01312 00341	∂05-Nov-88  1348	CL-Cleanup-mailer 	New version of proposal format?
C01321 00342	∂07-Nov-88  1547	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COERCE-TIME (Version 2)   
C01324 00343	∂07-Nov-88  1626	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COERCE-TIME (Version 2)   
C01327 00344	∂07-Nov-88  1627	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 2)   
C01329 00345	∂07-Nov-88  1713	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COERCE-TIME (Version 2)   
C01333 00346	∂08-Nov-88  1143	CL-Cleanup-mailer 	Re: Issue: FUNCTION-DEFINITION (Version 1)    
C01335 00347	∂08-Nov-88  1251	CL-Cleanup-mailer 	Issue: FUNCTION-DEFINITION (Version 1)   
C01338 00348	∂08-Nov-88  2201	CL-Cleanup-mailer 	Issue deadlines 
C01341 00349	∂09-Nov-88  1402	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C01346 00350	∂10-Nov-88  0951	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C01351 00351	∂10-Nov-88  1034	CL-Cleanup-mailer 	Issue: DEFSTRUCT-ACCESS-FUNCTIONS (Version 1) 
C01354 00352	∂10-Nov-88  1034	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)   
C01373 00353	∂10-Nov-88  1058	CL-Cleanup-mailer 	Issue: FORMAT-PRETTY-PRINT (Version 6)   
C01383 00354	∂10-Nov-88  1221	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)   
C01388 00355	∂10-Nov-88  1256	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
C01392 00356	∂10-Nov-88  1328	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)   
C01395 00357	∂10-Nov-88  1515	CL-Cleanup-mailer 	Issue: MAKE-STRING-FILL-POINTER (Version 1)   
C01399 00358	∂10-Nov-88  1557	CL-Cleanup-mailer 	Issue: PACKAGE-FUNCTION-CONSISTENCY (Version 1)    
C01402 00359	∂10-Nov-88  1607	CL-Cleanup-mailer 	Re: Issue: DEFSTRUCT-ACCESS-FUNCTIONS (Version 1)  
C01404 00360	∂10-Nov-88  1607	CL-Cleanup-mailer 	Re: Issue: MAKE-STRING-FILL-POINTER (Version 1)    
C01406 00361	∂10-Nov-88  1629	CL-Cleanup-mailer 	Re: Issue: DEFSTRUCT-ACCESS-FUNCTIONS (Version 1)  
C01409 00362	∂10-Nov-88  1913	CL-Cleanup-mailer 	Issue: MAKE-STRING-FILL-POINTER (Version 1)   
C01411 00363	∂10-Nov-88  2052	CL-Cleanup-mailer 	Issue: MAKE-STRING-FILL-POINTER (Version 1)   
C01415 00364	∂10-Nov-88  2115	CL-Cleanup-mailer 	Issue: MAKE-STRING-FILL-POINTER (Version 1)   
C01418 00365	∂10-Nov-88  2121	CL-Cleanup-mailer 	Issue: EXIT-EXTENT   
C01428 00366	∂10-Nov-88  2229	CL-Cleanup-mailer 	Issue: DEFSTRUCT-ACCESS-FUNCTIONS (Version 1) 
C01430 00367	∂11-Nov-88  0821	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C01432 00368	∂11-Nov-88  0937	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C01435 00369	∂11-Nov-88  1037	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C01441 00370	∂11-Nov-88  1228	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C01443 00371	∂11-Nov-88  1339	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
C01447 00372	∂11-Nov-88  1421	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C01451 00373	∂11-Nov-88  1431	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C01454 00374	∂11-Nov-88  1723	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
C01457 00375	∂11-Nov-88  1810	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C01459 00376	∂13-Nov-88  1532	CL-Cleanup-mailer 	Issue: DELETE-NONEXISTENT-FILE (Version 1)    
C01462 00377	∂13-Nov-88  1534	CL-Cleanup-mailer 	Issue: FORMAT-ROUNDING (Version 1)  
C01465 00378	∂13-Nov-88  1833	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
C01472 00379	∂13-Nov-88  2025	CL-Cleanup-mailer 	Issue: FORMAT-ROUNDING (Version 1)  
C01475 00380	∂14-Nov-88  0620	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
C01478 00381	∂14-Nov-88  0713	CL-Cleanup-mailer 	Issue GC-MESSAGES (Version 2)  
C01485 00382	∂14-Nov-88  0852	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
C01488 00383	∂14-Nov-88  0919	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
C01490 00384	∂14-Nov-88  1212	CL-Cleanup-mailer 	Issue: FORMAT-ROUNDING (Version 1)  
C01492 00385	∂14-Nov-88  1224	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
C01494 00386	∂14-Nov-88  1347	CL-Cleanup-mailer 	more to do with DEFPACKAGE than with REQUIRE-PATHNAME-DEFAULTS    
C01499 00387	∂14-Nov-88  1416	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)   
C01505 00388	∂14-Nov-88  1448	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 5) 
C01514 00389	∂14-Nov-88  1529	CL-Cleanup-mailer 	RE: Issue: HASH-TABLE-ACCESS (version 2) 
C01518 00390	∂14-Nov-88  1529	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1) 
C01520 00391	∂14-Nov-88  1601	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 5) 
C01529 00392	∂14-Nov-88  1601	CL-Cleanup-mailer 	Re: issue HASH-TABLE-PRINTED-REPRESENTATION   
C01531 00393	∂14-Nov-88  1601	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)    
C01533 00394	∂14-Nov-88  1619	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-TESTS (Version 1)  
C01535 00395	∂14-Nov-88  1844	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)    
C01538 00396	∂15-Nov-88  1140	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)  
C01546 00397	∂15-Nov-88  1309	CL-Cleanup-mailer 	Issue: WITH-DYNAMIC-EXTENT (Version 1)   
C01565 00398	∂15-Nov-88  1315	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT (Version 1)   
C01581 00399	∂15-Nov-88  1320	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT
C01583 00400	∂15-Nov-88  1412	CL-Cleanup-mailer 	Issue: DESCRIBE-INTERACTIVE (Version 4)  
C01594 00401	∂15-Nov-88  1416	CL-Cleanup-mailer 	Issue: FORMAT-PRETTY-PRINT (Version 7)   
C01604 00402	∂15-Nov-88  1434	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)  
C01621 00403	∂15-Nov-88  1510	CL-Cleanup-mailer 	Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)   
C01623 00404	∂15-Nov-88  1539	CL-Cleanup-mailer 	Issue: DOTTED-MACRO-FORMS (Version 3)    
C01632 00405	∂16-Nov-88  1038	CL-Cleanup-mailer 	Issue: DESCRIBE-INTERACTIVE (Version 4)  
C01636 00406	∂16-Nov-88  1052	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)  
C01639 00407	∂16-Nov-88  1253	CL-Cleanup-mailer 	Re: Issue: DESCRIBE-INTERACTIVE (Version 4)   
C01642 00408	∂16-Nov-88  1300	CL-Cleanup-mailer 	Issue: SETF-PLACES (version 1) 
C01674 00409	∂16-Nov-88  1312	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)   
C01679 00410	∂16-Nov-88  1323	CL-Cleanup-mailer 	Re: Issue: STREAM-CAPABILITIES (Version 1)    
C01683 00411	∂16-Nov-88  1324	CL-Cleanup-mailer 	Issue: HASH-TABLE-STABILITY (version 1)  
C01714 00412	∂16-Nov-88  1522	CL-Cleanup-mailer 	Issue: GET-MACRO-CHARACTER-READTABLE (version 1)   
C01720 00413	∂16-Nov-88  1654	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)   
C01723 00414	∂18-Nov-88  0021	CL-Cleanup-mailer 	Re: Issue DOTTED-MACRO-FORMS   
C01726 00415	∂18-Nov-88  0021	CL-Cleanup-mailer 	Re: Issue HASH-TABLE-STABILITY 
C01728 00416	∂18-Nov-88  0354	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-STABILITY (version 1)   
C01730 00417	∂18-Nov-88  1518	CL-Cleanup-mailer 	Issue HASH-TABLE-STABILITY
C01732 00418	∂18-Nov-88  1522	CL-Cleanup-mailer 	Issue: HASH-TABLE-STABILITY (version 1)  
C01734 00419	∂19-Nov-88  1358	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-STABILITY (version 1)   
C01737 00420	∂20-Nov-88  1855	CL-Cleanup-mailer 	Re: Issue GC-MESSAGES (Version 2)   
C01739 00421	∂20-Nov-88  1855	CL-Cleanup-mailer 	Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)   
C01744 00422	∂21-Nov-88  1119	CL-Cleanup-mailer 	Re: Issue DOTTED-MACRO-FORMS   
C01746 00423	∂21-Nov-88  1502	CL-Cleanup-mailer 	Issue: COERCE-INCOMPLETE (Version 2)
C01765 00424	∂21-Nov-88  1643	CL-Compiler-mailer 	Re:  issue IN-PACKAGE-FUNCTIONALITY
C01768 00425	∂21-Nov-88  1724	CL-Cleanup-mailer 	Issue: PACKAGE-DELETION (Version 5) 
C01782 00426	∂21-Nov-88  1948	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)  
C01787 00427	∂21-Nov-88  2251	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)  
C01794 00428	∂22-Nov-88  1237	CL-Cleanup-mailer 	Re: Issue: COERCE-INCOMPLETE (Version 2) 
C01798 00429	∂22-Nov-88  1347	CL-Cleanup-mailer 	Issue: LAMBDA-FORM (Version 4) 
C01808 00430	∂22-Nov-88  1351	CL-Cleanup-mailer 	Re: Issue: COERCE-INCOMPLETE (Version 2) 
C01825 00431	∂22-Nov-88  1414	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION (version 5)   
C01835 00432	∂22-Nov-88  1503	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)  
C01838 00433	∂22-Nov-88  1516	CL-Cleanup-mailer 	Issue: HASH-TABLE-STABILITY (version 1)  
C01841 00434	∂22-Nov-88  1521	CL-Cleanup-mailer 	Re: Issue: COERCE-INCOMPLETE (Version 2) 
C01845 00435	∂22-Nov-88  1533	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)   
C01847 00436	∂22-Nov-88  1541	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)  
C01852 00437	∂22-Nov-88  1628	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)   
C01873 00438	∂22-Nov-88  1649	CL-Cleanup-mailer 	Issue: SETF-PLACES (version 1) 
C01877 00439	∂22-Nov-88  1651	CL-Cleanup-mailer 	Re: Issue: SETF-PLACES (version 1)  
C01882 00440	∂22-Nov-88  1700	CL-Cleanup-mailer 	Re: Issue: SETF-PLACES (version 1)  
C01884 00441	∂22-Nov-88  1816	CL-Cleanup-mailer 	Re: Issue: SETF-PLACES (version 1)  
C01886 00442	∂22-Nov-88  1838	CL-Cleanup-mailer 	Issue names
C01888 00443	∂23-Nov-88  1102	CL-Cleanup-mailer 	Issue: LIST-TYPE-SPECIFIER (Version 1)   
C01892 00444	∂23-Nov-88  1258	CL-Cleanup-mailer 	Issue: COERCE-INCOMPLETE (Version 2)
C01900 00445	∂23-Nov-88  1351	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (version 2)   
C01902 00446	∂23-Nov-88  1539	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C01904 00447	∂23-Nov-88  1539	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2) 
C01907 00448	∂23-Nov-88  1539	CL-Cleanup-mailer 	Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
C01910 00449	∂23-Nov-88  1539	CL-Cleanup-mailer 	Re: Issue: PACKAGE-CLUTTER (Version 4)   
C01913 00450	∂23-Nov-88  1555	CL-Cleanup-mailer 	Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
C01915 00451	∂23-Nov-88  1556	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2) 
C01917 00452	∂28-Nov-88  0930	CL-Cleanup-mailer 	Issue: SETF-PLACES (version 1) 
C01920 00453	∂28-Nov-88  1118	CL-Cleanup-mailer 	dispatch macro characters 
C01923 00454	∂28-Nov-88  1141	CL-Cleanup-mailer 	Re: Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1)  
C01926 00455	∂28-Nov-88  1141	CL-Cleanup-mailer 	Re: Issue: PATHNAME-WILD (Version 2)
C01928 00456	∂28-Nov-88  1141	CL-Cleanup-mailer 	Issue: RETURN-VALUES-UNSPECIFIED (Version 5)  
C01933 00457	∂28-Nov-88  1142	CL-Cleanup-mailer 	Issue: SETF-FUNCTION-VS-MACRO (version 5)
C01976 00458	∂28-Nov-88  1141	CL-Cleanup-mailer 	Re: Issue: PRINT-CIRCLE-STRUCTURE   
C01978 00459	∂28-Nov-88  1141	CL-Cleanup-mailer 	Issue: SETF-FUNCTION-VS-MACRO  
C01979 00460	∂28-Nov-88  1420	CL-Cleanup-mailer 	EOF during READ-DELIMITED-LIST 
C01982 00461	∂28-Nov-88  1543	CL-Cleanup-mailer 	Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)  
C01985 00462	∂28-Nov-88  1543	CL-Cleanup-mailer 	Re: dispatch macro characters  
C01987 00463	∂28-Nov-88  2200	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)   
C01991 00464	∂28-Nov-88  2247	CL-Cleanup-mailer 	Issue: SETF-PLACES (version 1) 
C01998 00465	∂28-Nov-88  2305	CL-Cleanup-mailer 	Issue: SETF-PLACES (version 1) 
C02001 00466	∂28-Nov-88  2312	CL-Cleanup-mailer 	Issue: SETF-PLACES (version 1) 
C02004 00467	∂28-Nov-88  2324	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (version 2)   
C02006 00468	∂29-Nov-88  0920	CL-Cleanup-mailer 	Re: Issue: SETF-PLACES (version 1)  
C02015 00469	∂29-Nov-88  0922	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)   
C02020 00470	∂29-Nov-88  1049	CL-Cleanup-mailer 	Issue: LIST-TYPE-SPECIFIER (version 1)   
C02022 00471	∂29-Nov-88  1353	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)    
C02040 00472	∂29-Nov-88  1603	CL-Cleanup-mailer 	Re: Issue: STREAM-CAPABILITIES (Version 1)    
C02043 00473	∂29-Nov-88  1619	CL-Cleanup-mailer 	Re: Issue: STREAM-CAPABILITIES (Version 1)    
C02047 00474	∂29-Nov-88  1737	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)   
C02050 00475	∂29-Nov-88  1937	CL-Cleanup-mailer 	Issue: SETF-PLACES (version 1) 
C02059 00476	∂29-Nov-88  2053	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)   
C02062 00477	∂29-Nov-88  2221	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)    
C02067 00478	∂30-Nov-88  0039	CL-Cleanup-mailer 	Merger SETF-FUNCTION-VS-MACRO and SETF-PLACES proposals 
C02072 00479	∂30-Nov-88  1050	CL-Cleanup-mailer 	*** POLL *** Issue: SETF-FUNCTION-VS-MACRO (version 6)  
C02112 00480	∂30-Nov-88  1158	CL-Cleanup-mailer 	Re: Issue: CLOSED-STREAM-OPERATIONS (Versions 3vR, 3R, 4)    
C02114 00481	∂30-Nov-88  1200	CL-Cleanup-mailer 	Re: Issue: CLOSED-STREAM-OPERATIONS (Versions 3vR, 3R)  
C02117 00482	∂30-Nov-88  1209	CL-Cleanup-mailer 	Re: *** POLL *** Issue: SETF-FUNCTION-VS-MACRO (version 6)   
C02119 00483	∂30-Nov-88  1219	CL-Cleanup-mailer 	Issue: STREAM-ACCESS (version 2)    
C02130 00484	∂30-Nov-88  1648	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)   
C02133 00485	∂30-Nov-88  1732	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)   
C02137 00486	∂30-Nov-88  1743	CL-Cleanup-mailer 	Re: *** POLL *** Issue: SETF-FUNCTION-VS-MACRO (version 6)   
C02140 00487	∂30-Nov-88  1800	CL-Compiler-mailer 	Re:  issue IN-PACKAGE-FUNCTIONALITY
C02143 00488	∂30-Nov-88  1836	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 6) 
C02168 00489	∂30-Nov-88  1904	CL-Cleanup-mailer 	Issue: SETF-FUNCTION-VS-MACRO (version 6)
C02171 00490	∂30-Nov-88  1904	CL-Cleanup-mailer 	Issue SYMBOL-MACROLET-SEMANTICS, Version 5    
C02181 00491	∂30-Nov-88  2104	CL-Cleanup-mailer 	Issue: TAGBODY-CONTENTS (Version 4) 
C02183 00492	∂30-Nov-88  2123	CL-Cleanup-mailer 	Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2) 
C02186 00493	∂30-Nov-88  2130	CL-Cleanup-mailer 	Re: Issue: TAILP-NIL (version 3)    
C02188 00494	∂30-Nov-88  2226	CL-Cleanup-mailer 	Issue: TAGBODY-CONTENTS (Version 4) 
C02192 00495	∂30-Nov-88  2241	CL-Cleanup-mailer 	Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS (Version 1)    
C02204 00496	∂30-Nov-88  2254	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 6) 
C02207 00497	∂30-Nov-88  2317	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)    
C02213 00498	∂01-Dec-88  1108	CL-Cleanup-mailer 	Issue: TAILP-NIL (Version 4)   
C02224 00499	∂01-Dec-88  1112	CL-Cleanup-mailer 	Issue: TAILP-NIL (Version 4)   
C02226 00500	∂01-Dec-88  1205	CL-Cleanup-mailer 	Re:  Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)    
C02228 00501	∂01-Dec-88  1216	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 6) 
C02230 00502	∂01-Dec-88  1310	CL-Cleanup-mailer 	Ballot form
C02232 00503	∂01-Dec-88  1311	CL-Cleanup-mailer 	Issue: TEST-NOT-IF-NOT (Version 3)  
C02242 00504	∂01-Dec-88  1355	CL-Cleanup-mailer 	Issue ALIST-NIL 
C02244 00505	∂01-Dec-88  1403	CL-Cleanup-mailer 	Issue: TEST-NOT-IF-NOT (Version 3)  
C02247 00506	∂01-Dec-88  1520	CL-Cleanup-mailer 	Re:  Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)    
C02251 00507	∂01-Dec-88  1520	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATIONS (Version 4)   
C02264 00508	∂01-Dec-88  1634	CL-Cleanup-mailer 	Issue: TYPE-OF-UNDERCONSTRAINED (Version 1)   
C02271 00509	∂01-Dec-88  1634	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)    
C02273 00510	∂01-Dec-88  1709	CL-Cleanup-mailer 	Re: Issue: CLOSED-STREAM-OPERATIONS (Version 4)    
C02275 00511	∂01-Dec-88  1742	CL-Cleanup-mailer 	Re: Issue: CLOSED-STREAM-OPERATIONS (Version 4)    
C02279 00512	∂01-Dec-88  2348	CL-Cleanup-mailer 	Re: Issue: TAILP-NIL (Version 4)    
C02281 00513	∂02-Dec-88  0153	CL-Cleanup-mailer 	Re: Issue: TAILP-NIL (Version 4)    
C02284 00514	∂02-Dec-88  0223	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
C02297 00515	∂02-Dec-88  0235	CL-Cleanup-mailer 	Re: Issue: CLOSED-STREAM-OPERATIONS (Version 4)    
C02301 00516	∂02-Dec-88  0325	CL-Cleanup-mailer 	Issue: TYPE-OF-UNDERCONSTRAINED (Version 1)   
C02305 00517	∂02-Dec-88  1014	CL-Cleanup-mailer 	Re: Issue: TAILP-NIL (Version 4)    
C02307 00518	∂02-Dec-88  1020	CL-Cleanup-mailer 	Re: Issue: CLOSED-STREAM-OPERATIONS (Version 4)    
C02309 00519	∂02-Dec-88  1214	CL-Cleanup-mailer 	Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 2)
C02315 00520	∂02-Dec-88  1245	CL-Cleanup-mailer 	Re: Issue: TAILP-NIL (Version 4)    
C02321 00521	∂02-Dec-88  1359	CL-Cleanup-mailer 	Re: Issue: TYPE-OF-UNDERCONSTRAINED (Version 1)    
C02323 00522	∂02-Dec-88  1920	CL-Cleanup-mailer 	Status on cleanup items   
C02325 00523	∂02-Dec-88  1920	CL-Cleanup-mailer 	Re: Issue ALIST-NIL  
C02327 00524	∂03-Dec-88  0002	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 6)   
C02351 00525	∂03-Dec-88  0150	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)    
C02356 00526	∂04-Dec-88  2241	CL-Cleanup-mailer 	Re: Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 2) 
C02358 00527	∂05-Dec-88  0823	CL-Cleanup-mailer 	Status on cleanup items   
C02360 00528	∂05-Dec-88  1249	CL-Cleanup-mailer 	Issue: CLOSE-CONSTRUCTED-STREAMS (not yet submitted)    
C02362 00529	∂05-Dec-88  1249	CL-Cleanup-mailer 	Issue: INPUT-STREAM-P-CLOSED (not yet submitted)   
C02364 00530	∂05-Dec-88  1530	CL-Cleanup-mailer 	Issue: DECLARATION-SCOPE  
C02366 00531	∂05-Dec-88  1641	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 6) 
C02369 00532	∂05-Dec-88  1726	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 6)
C02380 00533	∂05-Dec-88  1742	CL-Cleanup-mailer 	Re:  [David A. Moon: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)] 
C02382 00534	∂05-Dec-88  1752	CL-Cleanup-mailer 	Re:  [David A. Moon: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)] 
C02385 00535	∂05-Dec-88  1853	CL-Cleanup-mailer 	Issue: SETF-MULTIPLE-STORE-VARIABLES
C02392 00536	∂06-Dec-88  0800	CL-Cleanup-mailer 	Issue: DEFPACKAGE (Version 7)  
C02395 00537	∂06-Dec-88  1133	CL-Cleanup-mailer 	New proposed issue APPEND-ATOM 
C02403 00538	∂06-Dec-88  1134	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 6) 
C02405 00539	∂06-Dec-88  1142	CL-Compiler-mailer 	issue IN-PACKAGE-FUNCTIONALITY
C02409 00540	∂06-Dec-88  1340	CL-Cleanup-mailer 	Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)    
C02422 00541	∂06-Dec-88  1428	CL-Cleanup-mailer 	Re: Issue: DECLARATION-SCOPE   
C02424 00542	∂06-Dec-88  1515	CL-Cleanup-mailer 	Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)    
C02431 00543	∂06-Dec-88  1808	CL-Cleanup-mailer 	Re: New proposed issue APPEND-ATOM  
C02433 00544	∂06-Dec-88  1808	CL-Cleanup-mailer 	Re: Issue: DEFPACKAGE (Version 7)   
C02435 00545	∂06-Dec-88  1843	CL-Cleanup-mailer 	Issue: DECLARATION-SCOPE (version 4)
C02464 00546	∂06-Dec-88  1915	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 6)
C02469 00547	∂06-Dec-88  1916	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 6)
C02474 00548	∂06-Dec-88  1918	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 6)
C02476 00549	∂06-Dec-88  2123	CL-Cleanup-mailer 	Issue: TYPE-OF-UNDERCONSTRAINED (Version 1)   
C02481 00550	∂06-Dec-88  2134	CL-Cleanup-mailer 	Issue: DEFPACKAGE (Version 7)  
C02484 00551	∂06-Dec-88  2241	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
C02489 00552	∂06-Dec-88  2305	CL-Cleanup-mailer 	Issue: TAILP-NIL (Version 4)   
C02491 00553	∂07-Dec-88  0018	CL-Cleanup-mailer 	Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE, (Version 3) 
C02497 00554	∂07-Dec-88  0111	CL-Cleanup-mailer 	Issue: DEFPACKAGE (Version 7)  
C02501 00555	∂07-Dec-88  0842	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 6) 
C02505 00556	∂07-Dec-88  1013	CL-Cleanup-mailer 	Re: Issue: TYPE-OF-UNDERCONSTRAINED (Version 1)    
C02507 00557	∂07-Dec-88  1410	CL-Cleanup-mailer 	Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3) 
C02513 00558	∂07-Dec-88  1501	CL-Cleanup-mailer 	Issue: DEFPACKAGE (Version 7)  
C02518 00559	∂07-Dec-88  1554	CL-Cleanup-mailer 	Issue: DEFPACKAGE (Version 7)  
C02525 00560	∂07-Dec-88  1620	CL-Compiler-mailer 	Re:  issue IN-PACKAGE-FUNCTIONALITY
C02529 00561	∂07-Dec-88  1659	CL-Cleanup-mailer 	Note on mailing to members of cl-cleanup 
C02531 00562	∂07-Dec-88  1810	CL-Cleanup-mailer 	Issue: TYPE-OF-UNDERCONSTRAINED (Version 1)   
C02534 00563	∂07-Dec-88  1830	CL-Cleanup-mailer 	Re: Issue: DYNAMIC-EXTENT (Version 1)    
C02537 00564	∂07-Dec-88  1948	CL-Cleanup-mailer 	Re:  [David A. Moon: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)] 
C02539 00565	∂07-Dec-88  2026	CL-Cleanup-mailer 	Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)    
C02543 00566	∂07-Dec-88  2058	CL-Cleanup-mailer 	Issue: EXIT-EXTENT (Version 4) 
C02567 00567	∂07-Dec-88  2123	CL-Cleanup-mailer 	Issue FIXNUM-NON-PORTABLE (Version 4)    
C02577 00568	∂07-Dec-88  2143	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COERCE-TIME (Version 2)   
C02579 00569	∂07-Dec-88  2246	CL-Cleanup-mailer 	Issue: FUNCTION-COMPOSITION (Version 3)  
C02590 00570	∂08-Dec-88  0019	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 8)
C02603 00571	∂08-Dec-88  0019	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 3)
C02616 00572	∂08-Dec-88  0935	CL-Compiler-mailer 	Re:  issue IN-PACKAGE-FUNCTIONALITY
C02619 00573	∂08-Dec-88  1129	CL-Cleanup-mailer 	Issue: HASH-TABLE-KEY-MODIFICATION (and HASH-TABLE-STABILITY)
C02621 00574	∂08-Dec-88  1216	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (Version 7)   
C02624 00575	∂08-Dec-88  1221	CL-Cleanup-mailer 	Re: issue HASH-TABLE-PRINTED-REPRESENTATION   
C02626 00576	∂08-Dec-88  1317	CL-Cleanup-mailer 	Macros expanding into declarations  
C02629 00577	∂08-Dec-88  1643	CL-Cleanup-mailer 	Issue: IN-PACKAGE-FUNCTIONALITY (Version 3)   
C02636 00578	∂08-Dec-88  1745	CL-Cleanup-mailer 	Re: Issue: EXIT-EXTENT (Version 4)  
C02640 00579	∂08-Dec-88  1745	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 3)   
C02642 00580	∂08-Dec-88  1844	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 5)  
C02658 00581	∂08-Dec-88  2105	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 3)   
C02660 00582	∂08-Dec-88  2116	CL-Cleanup-mailer 	Re: Issue: EXIT-EXTENT (Version 4)  
C02663 00583	∂08-Dec-88  2137	CL-Cleanup-mailer 	Issue: PRINT-CIRCLE-SHARED (not yet submitted)
C02664 00584	∂08-Dec-88  2156	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 9) 
C02686 00585	∂08-Dec-88  2322	CL-Cleanup-mailer 	Re: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
C02690 00586	∂08-Dec-88  2328	CL-Cleanup-mailer 	Re: Issue: REMF-MULTIPLE (Version 1)
C02693 00587	∂08-Dec-88  2337	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)   
C02695 00588	∂09-Dec-88  0025	CL-Cleanup-mailer 	DRAFT Issue: REST-LIST-ALLOCATION (Version 1) 
C02708 00589	∂09-Dec-88  0146	CL-Cleanup-mailer 	Re: issue HASH-TABLE-PRINTED-REPRESENTATION   
C02710 00590	∂09-Dec-88  0820	CL-Cleanup-mailer 	Re: Issue: SETF-PLACES (Version 1)  
C02713 00591	∂09-Dec-88  0830	CL-Cleanup-mailer 	Re: Issue: STREAM-ACCESS (Version 2)
C02715 00592	∂09-Dec-88  0840	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)   
C02718 00593	∂09-Dec-88  0840	CL-Cleanup-mailer 	RE: Re: Issue: EXIT-EXTENT (Version 4)   
C02720 00594	∂09-Dec-88  0842	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 6)  
C02728 00595	∂09-Dec-88  0925	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)   
C02730 00596	∂09-Dec-88  0944	CL-Cleanup-mailer 	Re: Issue: STREAM-ACCESS (Version 2)
C02732 00597	∂09-Dec-88  0944	CL-Cleanup-mailer 	Re: Macros expanding into declarations   
C02734 00598	∂09-Dec-88  1036	CL-Cleanup-mailer 	Moon's silence  
C02736 00599	∂09-Dec-88  1047	CL-Cleanup-mailer 	Re: Moon's silence   
C02738 00600	∂09-Dec-88  1112	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)   
C02742 00601	∂09-Dec-88  1122	CL-Cleanup-mailer 	Re: Moon's silence   
C02745 00602	∂09-Dec-88  1407	CL-Cleanup-mailer 	Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2) 
C02747 00603	∂09-Dec-88  1430	CL-Cleanup-mailer 	TAILP-NIL (Version 5)
C02758 00604	∂09-Dec-88  1531	CL-Cleanup-mailer 	Re: issue TRUENAME-SYNTAX-ONLY 
C02759 00605	∂09-Dec-88  1535	CL-Cleanup-mailer 	Cleanup committee organization 
C02762 00606	∂09-Dec-88  1611	CL-Cleanup-mailer 	Re: Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 2) 
C02764 00607	∂09-Dec-88  1617	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (Version 7)   
C02766 00608	∂09-Dec-88  1636	CL-Cleanup-mailer 	Pass 2 complete: 45 out of 97 issues "released"    
C02768 00609	∂09-Dec-88  1649	CL-Cleanup-mailer 	Re: Issue: COERCE-INCOMPLETE (Version 2) 
C02772 00610	∂09-Dec-88  1712	CL-Cleanup-mailer 	Re: Issue: COERCE-INCOMPLETE (Version 2) 
C02774 00611	∂09-Dec-88  1732	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)  
C02778 00612	∂09-Dec-88  1735	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)  
C02780 00613	∂09-Dec-88  1748	CL-Cleanup-mailer 	Re: Issue: DEFPACKAGE (Version 7)   
C02782 00614	∂09-Dec-88  2337	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
C02789 00615	∂10-Dec-88  0020	CL-Cleanup-mailer 	Issue: DEFPACKAGE (Version 7)  
C02795 00616	∂10-Dec-88  0134	CL-Compiler-mailer 	issue IN-PACKAGE-FUNCTIONALITY
C02799 00617	∂10-Dec-88  0146	CL-Cleanup-mailer 	Issue: IN-PACKAGE-FUNCTIONALITY (Version 3)   
C02802 00618	∂10-Dec-88  0348	CL-Cleanup-mailer 	Issue: TYPE-OF-UNDERCONSTRAINED (Version 2)   
C02804 00619	∂10-Dec-88  0407	CL-Cleanup-mailer 	(Released?)Issue: DEFPACKAGE (Version 7) 
C02807 00620	∂10-Dec-88  0457	CL-Cleanup-mailer 	Issue: FUNCTION-COMPOSITION (Version 3)  
C02811 00621	∂10-Dec-88  0513	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 8)
C02815 00622	∂10-Dec-88  0537	CL-Cleanup-mailer 	Issue: HASH-TABLE-KEY-MODIFICATION (and HASH-TABLE-STABILITY)
C02818 00623	∂10-Dec-88  0655	CL-Cleanup-mailer 	Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3) 
C02821 00624	∂10-Dec-88  0816	CL-Cleanup-mailer 	Re: Issue: EXIT-EXTENT (Version 4)  
C02823 00625	∂10-Dec-88  1259	CL-Cleanup-mailer 	Issue: DEFPACKAGE (Version 7)  
C02826 ENDMK
C⊗;
∂08-Oct-88  0048	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 6)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 8 Oct 88  00:47:53 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01325g; Sat, 8 Oct 88 00:46:31 PDT
Received: by bhopal id AA03642g; Sat, 8 Oct 88 00:44:52 PDT
Date: Sat, 8 Oct 88 00:44:52 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810080744.AA03642@bhopal>
To: CL-Cleanup@Sail.stanford.edu
Subject: Issue: DEFPACKAGE (version 6)

Fix up :EXPORT to also refer to :INTERNAL.
Tighten up requirements as to package redefinition -- "retractions" permitted
  after continuing from a continuable error.
Fixed a few nits as suggedted by KMP's msg of Date: Thu, 6 Oct 88 04:12 EDT.
-- Incorporated the "use" and "shadow" suggestions
-- Slight re-wording about the ordering of execution re :export
-- Fixed up the commentary for the first example; downcased much of the
   second example.

Note that we now have three continuable errors being specified, but have
not specified the condition names.  This ought to be remedied.

-- JonL --

!

Issue:         DEFPACKAGE

References:    CLtL section 11.7.
               Issue: IN-PACKAGE-FUNCTIONALITY

Category:      ADDITION

Edit history:  Version 1, 12-Mar-88, Moon
               Version 2, 23-Mar-88, Moon, changes based on discussion
               Version 3, 27-Sep-88, JonL 
                (remove :import, :shadowing-import; allow :export to work on
                 imported and inherited; update references to in-package, etc.)
               Version 4,  1-Oct-88, Masinter
               Version 5, 6-Oct-88, Moon
               Version 6, 6-Oct-88, JonL (little nits)

Problem description:

The package functions included in CLtL encourage a programming style
that tends to evoke the worst aspects of the package system.  The
problem is that if the definition of a package is scattered through
a program, as a number of individual forms, it is very easy to read
a symbol before the package setup needed to read that symbol correctly
has been accomplished.  Three examples: an inherited symbol that should
have been shadowed might be accessed; a single-colon prefix might be
used for a symbol that will later be exported, causing an error; a local
symbol might be accessed where a symbol that will later be imported or
inherited was intended.  These problems can be difficult to understand
or even to recognize, are difficult to recover from without completely
restarting the Lisp, and frustrating to programmers.

Proposal (DEFPACKAGE:ADDITION):
      
Add a DEFPACKAGE macro to the language.  In the description below,
'package-name' and 'symbol-name' can be a symbol or a string; if a symbol, 
only its name matters, not what package it is in.


The syntax of DEFPACKAGE is

  (DEFPACKAGE package-name {option}*)

where each option is a list of a keyword and arguments.  Nothing in a
DEFPACKAGE form is evaluated.

Standard options for DEFPACKAGE are listed below.   Options may appear
more than once (useful mainly for :IMPORT-FROM and :SHADOWING-IMPORT-FROM).
It is an error to specify :SIZE more than once.

(:NICKNAMES {package-name}*)
        Set the package's nicknames to the specified names.

(:USE {package-name}*)
        The package is to "use" the other designated packages; that is,
        it will inherit from them.

(:SHADOW {symbol-name}*)
        Create the specified symbols in the package being defined, 
        making them shadows, just at the function SHADOW would do.

(:SHADOWING-IMPORT-FROM package-name {symbol-name}*)
        Find the specified symbols in the specified package and import
        them into the package being defined, and place them on the 
        shadowing symbols list.  In no case will 
        symbols be created in any package other than the one being defined; 
        a continuable error is signalled if no symbol is accessible in the
        package named package-name for one of the symbol-names.

(:IMPORT-FROM package-name {symbol-name}*)
        Find the specified symbols in the specified package and import
        them into the package being defined.  In no case will 
        symbols be created in a package other than the one being defined; 
        a continuable error is signalled if no symbol is accessible in the
        package named package-name for one of the symbol-names.

(:INTERNAL {symbol-name}*)
        Find or create symbols with the specified names.  This is useful
        if a :IMPORT-FROM or :SHADOWING-IMPORT-FROM option in a later
        DEFPACKAGE for another package expects to find these symbols,
        but the symbols are not to be exported.

(:EXPORT {symbol-name}*)
        Find or create symbols with the specified names and export them.
        Note an interaction with the :USE option, since intern'ing may inherit 
        symbols rather than creating new ones; note also an interaction 
        with the :INTERNAL, :IMPORT-FROM and :SHADOWING-IMPORT-FROM options,
        since intern'ing will merely access an already imported symbol. 

(:SIZE integer)
        Declare the approximate number of symbols expected in the package.
        This is an efficiency hint only, so that the package's table will
        not have to be frequently re-expanded when new symbols are added
        to it (e.g., by reading in a large file "in" that package.)


Additional options might be allowed by an implementation; all
implementations should signal an error if an option not recognized by
that implementation is present.

The collection of symbol-name arguments given to the options :SHADOW,
:INTERNAL, :IMPORT-FROM, and :SHADOWING-IMPORT-FROM must all be
disjoint; an error is signalled otherwise.  The :EXPORT option can
be thought of as occuring after all the other options have been
executed, since it may reference names found in "used" packages, 
or found in the argument lists to a :SHADOW, :INTERNAL, :IMPORT-FROM, 
or :SHADOWING-IMPORT-FROM option.

DEFPACKAGE creates the package as specified, and returns it as its value.
It has no other side effects; i.e., it does not do an IN-PACKAGE.  

If a package with the specified name already exists, the existing package 
is modified by possibly adding to its attributes.  An attempt to re-define
a package with a smaller set of attributes should signal a continuable error;
at most one such error is to be signalled per call to DEFPACKAGE, regardless 
of how many attributes are being re-tracted; upon continuation, the package
is created with exactly as specified.


Examples:

;;; An example which "plays it super-safe", by using only strings as names; 
;;;  does not even assume that the package it is read in to "uses" LISP; 
;;   *never* creates any symbols whatsoever in the package that it is read 
;;     in to.

(LISP:DEFPACKAGE "MY-PACKAGE"
  (:NICKNAMES "MYPKG" "MY-PKG")
  (:USE "LISP")
  (:SHADOW "CAR" "CDR")
  (:SHADOWING-IMPORT-FROM "VENDOR-COMMON-LISP"  "CONS")
  (:IMPORT-FROM           "VENDOR-COMMON-LISP"  "GC")
  (:EXPORT "EQ" "CONS" "FROBOLA")
  )

;;; A similar call, mostly using symbols rather than strings as names.
;;; Expects to be read in to a package that "uses" LISP, and *may* create
;;;  random internal symbols in that package (such as MY-PACKAGE etc).

(defpackage my-package
  (:nicknames mypkg :MY-PKG)		;remember CL conventions for case
  (:use lisp)				; conversion on symbols
  (:shadow CAR :cdr #:cons)
  (:export "CONS")			;yes, this is the shadowed one.
  )

Rationale:

The availability of DEFPACKAGE encourages putting the
entire definition of a package in a single place.  It also encourages
putting all the package definitions of a program in a single file, which
can be loaded before loading or compiling anything that depends on those
packages.  This file can be read in the USER package, avoiding any
package bootstrapping issues.

In addition, DEFPACKAGE allows a programming environment to process
the whole package setup as a unit, providing better error-checking and
more assistance with package problems, by dint of global knowledge of
the package setup.

Current practice:

Symbolics Common Lisp has always had a DEFPACKAGE, and uses it in 
preference to individual calls to EXPORT, IMPORT, SHADOW, etc.  The SCL 
version of DEFPACKAGE has quite a few additional options, but none of them
appear to be necessary to propose for Common Lisp at this time.  This
proposal is incompatible with Symbolics DEFPACKAGE in some ways that
will probably not cause major problems.

Cost to Implementors:

Small; DEFPACKAGE can be implemented simply as a bunch of
calls to existing functions.

Cost to Users:

Small, this is upward compatible.

Cost of non-adoption:

Packages continue to be difficult to use correctly.

Benefits:

Guide users away from using packages in ways that get them into trouble.

Esthetics:

Neutral.

Discussion:

The "Put in seven extremely random user interface commands" mnemonic
described in CLtL p.191 could be removed, and the special compiler 
handling of these functions necessary to support that could be removed 
(except possibly for REQUIRE and PROCLAIM -- see the compiler Issue 
PROCLAIM-ETC-IN-COMPILE-FILE).  As this would be an incompatible change,
it is not part of this proposal.

The issue IN-PACKAGE-FUNCTIONALITY recommends that IN-PACKAGE  be 
incompatibly changed to recognize only existing packages, not to create 
them.  IN-PACKAGE would then not accept any keyword arguments.

The function MAKE-PACKAGE might also be extended to take all the keywords
that DEFPACKAGE does. This could be the subject of a separate cleanup.

The macroexpansion of DEFPACKAGE can usefully canonicalize
into the strings-as-name form, so that even though the source file
showed random symbols in the DEFPACKAGE form, the compiled file might
have only strings in it.

Frequently additional implementation-dependent options take the
form of a keyword standing by itself as an abbreviation for a list
(keyword T); this syntax should be properly reported as an unrecognized
option in implementations that do not support it.

∂08-Oct-88  1150	CL-Cleanup-mailer 	Issue: RETURN-VALUES-UNSPECIFIED (Version 4)  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88  11:49:54 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Sat, 8 Oct 88 14:47:13 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Sat, 8 Oct 88 14:46:39 EDT
Date: Sat, 8 Oct 88 14:47 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: RETURN-VALUES-UNSPECIFIED (Version 4)
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu, Masinter.pa@xerox.com
In-Reply-To: <881007-211606-1727@Xerox>
Message-Id: <19881008184726.3.BARMAR@OCCAM.THINK.COM>

    Date: 7 Oct 88 21:16 PDT
    From: masinter.pa@xerox.com

    Proposal (RETURN-VALUES-UNSPECIFIED:SPECIFY)
 
    Clarify that the return values for the listed constructs are as follows:
 
    CLOSE -- the stream argument.
    IN-PACKAGE -- the new package, i.e. the value of *PACKAGE* after the
    execution of IN-PACKAGE.
    RENAME-PACKAGE -- the renamed package.
    SET-SYNTAX-FROM-CHAR -- T
    LOCALLY -- the return values of the last form of its body, i.e. the body is
	    surrounded by an implicit PROGN.
 
    Cost to Implementors:
 
    Small.

    Benefits:
 
    This clarification will assist users in writing portable code.
 
Except for LOCALLY, I don't see the point of specifying the return
values of the above functions.  Yes, the cost to implementors is small,
but why bother in the first place?  I think they should be made
explicitly implementation defined, like the other functions that were
listed.

If others do prefer to specify explicit return values, I agree with the
particular choices (although for SET-SYNTAX-FROM-CHAR I don't see why it
shouldn't return one of the characters).

                                                barmar

∂08-Oct-88  1243	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88  12:42:51 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 12:32:44 PDT
Date: 8 Oct 88 12:32 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)
To: cl-cleanup@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-123244-2125@Xerox>

I modified this issue to tone down its criticizm of the current
Common Lisp situation (e.g., removed the assertion that it has been
a "disaster"). I think it still reads well. I also tried to squeeze
into the discussion section some of the alternatives that were tried
and not adopted, and the reasons for not adopting them.

I don't think there are two many others that I'll have last
minute revisions to; if you're there and listening today, let
me know. (Or call at (415) 494-4365).

!
Issue:         ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS

References:    Data types and Type specifiers: CLtL p. 11; Sect. 4.5, p.45
                    TYPEP and SUBTYPEP; CLtL Sect. 6.2.1, p.72
                    ARRAY-ELEMENT-TYPE, CLtL p. 291
               The type-specifiers ARRAY, COMPLEX, SIMPLE-ARRAY, and VECTOR

Related Issues: SUBTYPEP-TOO-VAGUE, LIST-TYPE-SPECIFIER

Category:      CHANGE

Edit history:  Version 1, 13-May-88, JonL
               Version 2, 23-May-88, JonL  
                (typo fixes, comments from moon, rearrange some discussion)
               Version 3, 02-Jun-88, JonL  
                (flush alternate proposal ["flush-upgrading"]; consequently,
                 move more of discussion back to discussion section.
               Version 4, 01-Oct-88, Jan Pedersen & JonL
                (reduce discussion, and "cleanup" wordings)
               (Version 5 edit history missing)
               Version 6, 6-Oct-88, Moon
                (fix typos, cover subtypep explicitly, add complex,
                 change name of UPGRADE-ARRAY-ELEMENT-TYPE)
               Version 7, 7-Oct-88, JonL (more name and wording changes)
               Version 8,  8-Oct-88, Masinter (wording, discussion)


Problem description:

 CLtL occasionally draws a distinction between type-specifiers "for
 declaration" and "for discrimination".  Many people are confused by
 this situation.  A consequence of this distinction is that a variable
 declared to be of type <certain-type> and all of whose assigned objects
 are created in accordance with that type, may still have none of its
 values ever satisfy the TYPEP predicate with that type-specifier.

 One type-specifier with this property is  
         (ARRAY <element-type>) 
 for various implementation dependent values of <element-type>.  For
 example, in most implementations of CL, an array X created with an
 element-type of (SIGNED-BYTE 5) will, depending on the vendor, either
 satisfy
        (TYPEP X '(ARRAY (SIGNED-BYTE 8))), or
        (TYPEP X '(ARRAY T)) 
 but (almost) never will it satisfy 
        (TYPEP X '(ARRAY (SIGNED-BYTE 5))).


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

 Summary of changes:

 Eliminate the distinction between type-specifiers "for declaration" and
 "for discrimination".  Change the meaning of the <element-type> in the
 ARRAY type-specifier and its subtypes, and in the COMPLEX type-specifier,
 to be the same for TYPEP and SUBTYPEP as for TYPE declarations.
 Specify how SUBTYPEP behaves on these type-specifiers.  Add a function
 to provide access to the implementation-dependent set of array types
 and another function to provide access to the implementation-dependent
 set of complex number types.

 Specifics:

 1. Eliminate references to the distinction between types "for declaration"
 and "for discrimination" in the discussion of array and complex
 type-specifiers. This would include documentation patterned after CLtL:
        a.) The discussion in section 4.5, pp. 45-7
        b.) p. 291, the sentence begining "This set may be larger than the set
        requested when the array was created; for example . . ."
 Instead, (ARRAY <type>) always means all arrays that can result by specifying
 <type> as the :ELEMENT-TYPE argument to the function MAKE-ARRAY, and
 (COMPLEX <type>) always means all complex numbers that can result by
 giving numbers of type <type> to the function COMPLEX, plus all other
 complex numbers of the same specialized representation.

 2. Change the meaning of (TYPEP <x> '(ARRAY <type>)) to be true if and
 only if <x> is an array of the most specialized representation capable
 of holding elements of type <type>.  In other words, it is true if and
 only if <x> is an array and (ARRAY-ELEMENT-TYPE <x>) is type-equivalent
 to (ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE <type>)).
 Do the same for SIMPLE-ARRAY and VECTOR.

 3. Change the meaning of (TYPEP <x> '(COMPLEX <type>)) to be true if
 and only if <x> is a complex number of the most specialized
 representation capable of holding parts of type <type>,  or if <x> is of 
 any subtype of that representation.  Both the real and imaginary parts
 must satisy (TYPEP <real-or-imag-part> '<type>). 

 4. Define that for all type-specifiers <type1> and <type2>, other than *,
 (ARRAY <type1>) and (ARRAY <type2>) are either equivalent or disjoint,
 depending on whether they use the same specialized representation or
 distinct representations.  This defines the behavior of SUBTYPEP.

 5. Define that for all type-specifiers <type1> and <type2>, other than *,
 (SUBTYPEP '(COMPLEX <type1>) '(COMPLEX <type2>)) is T T if they use the
 same specialized representation, T T if they use distinct specialized
 representations but (SUBTYPEP '<type1> '<type2>) is true, and NIL T
 otherwise.

 6. Require that the resultant ARRAY-ELEMENT-TYPE from a call to
 MAKE-ARRAY is independent of any argument to MAKE-ARRAY except for the
 :ELEMENT-TYPE argument.  Thus the set of specialized array
 representations must be consistent between single-dimensional and
 multi-dimensional, simple and non-simple, short and long arrays.

 7. Add the function IMPLEMENTED-ARRAY-ELEMENT-TYPE of one argument 
 which returns the same result as:
    (DEFUN IMPLEMENTED-ARRAY-ELEMENT-TYPE (TYPE)
      (ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE TYPE)))
 The type specifiers (ARRAY <type1>) and (ARRAY <type2>), where neither
 <type1> nor <type2> is *, are equivalent if <type1> and <type2> produce
 the same value from IMPLEMENTED-ARRAY-ELEMENT-TYPE, and disjoint
 otherwise.

 8. Add the function IMPLEMENTED-COMPLEX-PART-TYPE of one argument 
 which  returns the part type of the most specialized complex number
 representation that can hold parts of the given argument type.


Test cases:

 Let <aet-x> and <aet-y> be two distinct type specifiers that are
 definitely not type-equivalent in a given implementation, but for which
 make-array will return an object of the same array type.  This will be
 an implementation dependent search, but in every implementation that
 the proposer has tested, there will be some such types; often,
 (SIGNED-BYTE 5) and (SIGNED-BYTE 8) will work.

 Thus, in each case, both of the following forms return T T:

  (subtypep (array-element-type (make-array 0 :element-type '<aet-x>))
            (array-element-type (make-array 0 :element-type '<aet-y>)))

  (subtypep (array-element-type (make-array 0 :element-type '<aet-y>))
            (array-element-type (make-array 0 :element-type '<aet-x>)))

 To eliminate the distinction between "for declaration" and "for
 discrimination" both of the following should be true:

  [A]
   (typep (make-array 0 :element-type '<aet-x>)
          '(array <aet-x>))
   (typep (make-array 0 :element-type '<aet-y>)
          '(array <aet-y>))

 Since (array <aet-x>) and (array <aet-y>) are different names for
 exactly the same set of objects, these names should be type-equivalent.
 That implies that the following set of tests should also be true:

  [B]
   (subtypep '(array <aet-x>) '(array <aet-y>))
   (subtypep '(array <aet-y>) '(array <aet-x>))

 Additionally, to show that un-equivalent type-specifiers that use the
 same specialized array type should be equivalent as element-type
 specifiers, the following type tests should be true:

  [C]
   (typep (make-array 0 :element-type '<aet-y>)
          '(array <aet-x>))
   (typep (make-array 0 :element-type '<aet-x>)
          '(array <aet-y>))


Rationale:

 This proposal legitimizes current practice, and removes the obscure and
 un-useful distinction between type-specifiers "for declaration" and
 "for discrimination".  The suggested changes to the interpretation of
 array and complex type-specifiers follow from defining type-specifiers
 as names for collections of objects, on TYPEP being a set membership
 test, and SUBTYPEP a subset test on collections of objects.

 The small differences between the specification for ARRAY and the
 specification for COMPLEX are necessary because there is no creation
 function for complexes which allows one to specify the resultant type
 independently of the types of the parts.  Thus in the case of COMPLEX
 we must refer to the type of the two parts, and to the fact that a 
 number can be a member of more than one type.  Note that:
     (SUBTYPEP '(COMPLEX SINGLE-FLOAT) '(COMPLEX FLOAT))
 is true in all implementations, but 
     (SUBTYPEP '(ARRAY SINGLE-FLOAT) '(ARRAY FLOAT))
 is only true in implementations that do not have a specialized array
 representation that can hold single-floats but not other floats.


Current Practice:

 Every vendor's implementation that the proposer has queried has a
 finite set of specialized array representations, such that two
 non-equivalent element types can be found that use the same specialized
 array representation; this includes Lucid, Vaxlisp, Symbolics, Franz,
 and Xerox. Most implementations fail tests [A] and [C] part 1, but pass
 tests [A] and [C] part 2; this is a consequence of implementing the
 distinction between "for declaration" and "for discrimination".  Lucid
 and Xerox both pass test [B], and the other implementations fail it.

 No vendor that the proposer has queried has any specialized representation
 for complexes.

Cost to Implementors:

 This proposal is an incompatible change to the current language
 specification, but only a small amount of work should be required in
 each vendor's implementation of TYPEP and SUBTYPEP.


Cost to Users:

 Because of the prevalence of confusion in this area, it seems unlikely
 that any user code will have to be changed.  In fact, it is more likely
 that some of the vendors will cease to get bug reports about MAKE-ARRAY
 returning a result that isn't of "the obvious type".  Since the change
 is incompatible, some user code might have to be changed.


Cost of non-adoption:

 Continuing confusion in the user community.


Benefits:

 It will greatly reduce confusion in the user community.  The fact that
 (MAKE-ARRAY <n> :ELEMENT-TYPE '<type>) frequently is not of type 
 (ARRAY <type>) has been very confusing to almost everyone.  

 Portability of applications will be increased slightly, since
 the behavior of 

 (TYPEP (MAKE-ARRAY <n> :ELEMENT-TYPE <type>) '(ARRAY <type>))

  will no longer be implementation-dependent. 


Esthetics:

 Reducing the confusing distinction between type-specifiers "for
 declaration" and "for discrimination" is a simplifying step -- it is a
 much simpler rule to state that the type-specifiers actually describe
 the collections of data they purport to name.  Thus this is a step
 towards increased elegance.


Discussion:

 This issue was prompted by a lengthy discussion on the Common Lisp
 mailing list. It was the subject of a lengthy discussion in the
 cleanup committee, as well as a number of individual efforts.

 We considered the possibility of requiring that arrays remember
 the element-type given in the make-array call, e.g., require that
 (equal <x> (array-element-type (make-array <n> :element-type <x>)))
 for all valid type specifiers <x>. This has several problems: it
 increases the storage requirement for arrays, and 'hides' a 
 relevant part of the underlying implementation for no apparently 
 good reason. In addition, there might be some problems with
 equivalent but separate types (although this might be handled
 by changing "equal" to "equal-type", given a more rigorous
 definition of SUBTYPEP; see issue SUBTYPEP-TOO-VAGUE.)
 However, it would increase portability, since it would be much
 more difficult to write a program that, for example, created 
 an array with one element-type and then assumed an upgraded
 element-type. It would be valid for an implementation to do so 
 -- to remember the original array element-type or its canonical
 or expanded  form -- and satisfy all of the constraints of this
 proposal.

 We considered a suggestion to restrict the set of "known" array
 element types; this would gain portability at the expense of limiting
 the language.

∂08-Oct-88  1306	CL-Cleanup-mailer 	DRAFT Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88  13:05:50 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 12:55:16 PDT
Date: 8 Oct 88 12:55 PDT
From: masinter.pa@Xerox.COM
Subject: DRAFT Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)
To: cl-cleanup@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-125516-2151@Xerox>

There have been last-minute edits to the wording (but not the intent) of this issue/proposal that cause me to write DRAFT in the issue status.


!
Issue:         ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS

References:    Data types and Type specifiers: CLtL p. 11; Sect. 4.5, p.45
                    TYPEP and SUBTYPEP; CLtL Sect. 6.2.1, p.72
                    ARRAY-ELEMENT-TYPE, CLtL p. 291
               The type-specifiers ARRAY, COMPLEX, SIMPLE-ARRAY, and VECTOR

Related Issues: SUBTYPEP-TOO-VAGUE, LIST-TYPE-SPECIFIER

Category:      CHANGE

Edit history:  Version 1, 13-May-88, JonL
               Version 2, 23-May-88, JonL  
                (typo fixes, comments from moon, rearrange some discussion)
               Version 3, 02-Jun-88, JonL  
                (flush alternate proposal ["flush-upgrading"]; consequently,
                 move more of discussion back to discussion section.
               Version 4, 01-Oct-88, Jan Pedersen & JonL
                (reduce discussion, and "cleanup" wordings)
               (Version 5 edit history missing)
               Version 6, 6-Oct-88, Moon
                (fix typos, cover subtypep explicitly, add complex,
                 change name of UPGRADE-ARRAY-ELEMENT-TYPE)
               Version 7, 7-Oct-88, JonL (more name and wording changes)
               Version 8,  8-Oct-88, Masinter (wording, discussion)


Problem description:

 CLtL occasionally draws a distinction between type-specifiers "for
 declaration" and "for discrimination".  Many people are confused by
 this situation.  A consequence of this distinction is that a variable
 declared to be of type <certain-type> and all of whose assigned objects
 are created in accordance with that type, may still have none of its
 values ever satisfy the TYPEP predicate with that type-specifier.

 One type-specifier with this property is  
         (ARRAY <element-type>) 
 for various implementation dependent values of <element-type>.  For
 example, in most implementations of CL, an array X created with an
 element-type of (SIGNED-BYTE 5) will, depending on the vendor, either
 satisfy
        (TYPEP X '(ARRAY (SIGNED-BYTE 8))), or
        (TYPEP X '(ARRAY T)) 
 but (almost) never will it satisfy 
        (TYPEP X '(ARRAY (SIGNED-BYTE 5))).


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

 Summary of changes:

 Eliminate the distinction between type-specifiers "for declaration" and
 "for discrimination".  Change the meaning of the <element-type> in the
 ARRAY type-specifier and its subtypes, and in the COMPLEX type-specifier,
 to be the same for TYPEP and SUBTYPEP as for TYPE declarations.
 Specify how SUBTYPEP behaves on these type-specifiers.  Add a function
 to provide access to the implementation-dependent set of array types
 and another function to provide access to the implementation-dependent
 set of complex number types.

 Specifics:

 1. Eliminate references to the distinction between types "for declaration"
 and "for discrimination" in the discussion of array and complex
 type-specifiers. This would include documentation patterned after CLtL:
        a.) The discussion in section 4.5, pp. 45-7
        b.) p. 291, the sentence begining "This set may be larger than the set
        requested when the array was created; for example . . ."
 Instead, (ARRAY <type>) always means all arrays that can result by specifying
 <type> as the :ELEMENT-TYPE argument to the function MAKE-ARRAY, and
 (COMPLEX <type>) always means all complex numbers that can result by
 giving numbers of type <type> to the function COMPLEX, plus all other
 complex numbers of the same specialized representation.

 2. Change the meaning of (TYPEP <x> '(ARRAY <type>)) to be true if and
 only if <x> is an array of the most specialized representation capable
 of holding elements of type <type>.  In other words, it is true if and
 only if <x> is an array and (ARRAY-ELEMENT-TYPE <x>) is type-equivalent
 to (ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE <type>)).
 Do the same for SIMPLE-ARRAY and VECTOR.

 3. Change the meaning of (TYPEP <x> '(COMPLEX <type>)) to be true if
 and only if <x> is a complex number of the most specialized
 representation capable of holding parts of type <type>,  or if <x> is of 
 any subtype of that representation.  Both the real and imaginary parts
 must satisy (TYPEP <real-or-imag-part> '<type>). 

 4. Define that for all type-specifiers <type1> and <type2>, other than *,
 (ARRAY <type1>) and (ARRAY <type2>) are either equivalent or disjoint,
 depending on whether they use the same specialized representation or
 distinct representations.  This defines the behavior of SUBTYPEP.

 5. Define that for all type-specifiers <type1> and <type2>, other than *,
 (SUBTYPEP '(COMPLEX <type1>) '(COMPLEX <type2>)) is T T if they use the
 same specialized representation, T T if they use distinct specialized
 representations but (SUBTYPEP '<type1> '<type2>) is true, and NIL T
 otherwise.

 6. Require that the resultant ARRAY-ELEMENT-TYPE from a call to
 MAKE-ARRAY is independent of any argument to MAKE-ARRAY except for the
 :ELEMENT-TYPE argument.  Thus the set of specialized array
 representations must be consistent between single-dimensional and
 multi-dimensional, simple and non-simple, short and long arrays.

 7. Add the function IMPLEMENTED-ARRAY-ELEMENT-TYPE of one argument 
 which returns the same result as:
    (DEFUN IMPLEMENTED-ARRAY-ELEMENT-TYPE (TYPE)
      (ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE TYPE)))
 The type specifiers (ARRAY <type1>) and (ARRAY <type2>), where neither
 <type1> nor <type2> is *, are equivalent if <type1> and <type2> produce
 the same value from IMPLEMENTED-ARRAY-ELEMENT-TYPE, and disjoint
 otherwise.

 8. Add the function IMPLEMENTED-COMPLEX-PART-TYPE of one argument 
 which  returns the part type of the most specialized complex number
 representation that can hold parts of the given argument type.


Test cases:

 Let <aet-x> and <aet-y> be two distinct type specifiers that are
 definitely not type-equivalent in a given implementation, but for which
 make-array will return an object of the same array type.  This will be
 an implementation dependent search, but in every implementation that
 the proposer has tested, there will be some such types; often,
 (SIGNED-BYTE 5) and (SIGNED-BYTE 8) will work.

 Thus, in each case, both of the following forms return T T:

  (subtypep (array-element-type (make-array 0 :element-type '<aet-x>))
            (array-element-type (make-array 0 :element-type '<aet-y>)))

  (subtypep (array-element-type (make-array 0 :element-type '<aet-y>))
            (array-element-type (make-array 0 :element-type '<aet-x>)))

 To eliminate the distinction between "for declaration" and "for
 discrimination" both of the following should be true:

  [A]
   (typep (make-array 0 :element-type '<aet-x>)
          '(array <aet-x>))
   (typep (make-array 0 :element-type '<aet-y>)
          '(array <aet-y>))

 Since (array <aet-x>) and (array <aet-y>) are different names for
 exactly the same set of objects, these names should be type-equivalent.
 That implies that the following set of tests should also be true:

  [B]
   (subtypep '(array <aet-x>) '(array <aet-y>))
   (subtypep '(array <aet-y>) '(array <aet-x>))

 Additionally, to show that un-equivalent type-specifiers that use the
 same specialized array type should be equivalent as element-type
 specifiers, the following type tests should be true:

  [C]
   (typep (make-array 0 :element-type '<aet-y>)
          '(array <aet-x>))
   (typep (make-array 0 :element-type '<aet-x>)
          '(array <aet-y>))


Rationale:

 This proposal legitimizes current practice, and removes the obscure and
 un-useful distinction between type-specifiers "for declaration" and
 "for discrimination".  The suggested changes to the interpretation of
 array and complex type-specifiers follow from defining type-specifiers
 as names for collections of objects, on TYPEP being a set membership
 test, and SUBTYPEP a subset test on collections of objects.

 The small differences between the specification for ARRAY and the
 specification for COMPLEX are necessary because there is no creation
 function for complexes which allows one to specify the resultant type
 independently of the types of the parts.  Thus in the case of COMPLEX
 we must refer to the type of the two parts, and to the fact that a 
 number can be a member of more than one type.  Note that:
     (SUBTYPEP '(COMPLEX SINGLE-FLOAT) '(COMPLEX FLOAT))
 is true in all implementations, but 
     (SUBTYPEP '(ARRAY SINGLE-FLOAT) '(ARRAY FLOAT))
 is only true in implementations that do not have a specialized array
 representation that can hold single-floats but not other floats.


Current Practice:

 Every vendor's implementation that the proposer has queried has a
 finite set of specialized array representations, such that two
 non-equivalent element types can be found that use the same specialized
 array representation; this includes Lucid, Vaxlisp, Symbolics, Franz,
 and Xerox. Most implementations fail tests [A] and [C] part 1, but pass
 tests [A] and [C] part 2; this is a consequence of implementing the
 distinction between "for declaration" and "for discrimination".  Lucid
 and Xerox both pass test [B], and the other implementations fail it.

 No vendor that the proposer has queried has any specialized representation
 for complexes.

Cost to Implementors:

 This proposal is an incompatible change to the current language
 specification, but only a small amount of work should be required in
 each vendor's implementation of TYPEP and SUBTYPEP.


Cost to Users:

 Because of the prevalence of confusion in this area, it seems unlikely
 that any user code will have to be changed.  In fact, it is more likely
 that some of the vendors will cease to get bug reports about MAKE-ARRAY
 returning a result that isn't of "the obvious type".  Since the change
 is incompatible, some user code might have to be changed.


Cost of non-adoption:

 Continuing confusion in the user community.


Benefits:

 It will greatly reduce confusion in the user community.  The fact that
 (MAKE-ARRAY <n> :ELEMENT-TYPE '<type>) frequently is not of type 
 (ARRAY <type>) has been very confusing to almost everyone.  

 Portability of applications will be increased slightly, since
 the behavior of 

 (TYPEP (MAKE-ARRAY <n> :ELEMENT-TYPE <type>) '(ARRAY <type>))

  will no longer be implementation-dependent. 


Esthetics:

 Reducing the confusing distinction between type-specifiers "for
 declaration" and "for discrimination" is a simplifying step -- it is a
 much simpler rule to state that the type-specifiers actually describe
 the collections of data they purport to name.  Thus this is a step
 towards increased elegance.


Discussion:

 This issue was prompted by a lengthy discussion on the Common Lisp
 mailing list. It was the subject of a lengthy discussion in the
 cleanup committee, as well as a number of individual efforts.

 We considered the possibility of requiring that arrays remember
 the element-type given in the make-array call, e.g., require that
 (equal <x> (array-element-type (make-array <n> :element-type <x>)))
 for all valid type specifiers <x>. This has several problems: it
 increases the storage requirement for arrays, and 'hides' a 
 relevant part of the underlying implementation for no apparently 
 good reason. In addition, there might be some problems with
 equivalent but separate types (although this might be handled
 by changing "equal" to "equal-type", given a more rigorous
 definition of SUBTYPEP; see issue SUBTYPEP-TOO-VAGUE.)
 However, it would increase portability, since it would be much
 more difficult to write a program that, for example, created 
 an array with one element-type and then assumed an upgraded
 element-type. It would be valid for an implementation to do so 
 -- to remember the original array element-type or its canonical
 or expanded  form -- and satisfy all of the constraints of this
 proposal.

 We considered a suggestion to restrict the set of "known" array
 element types; this would gain portability at the expense of limiting
 the language.

∂08-Oct-88  1818	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 5)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Oct 88  18:18:29 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 473405; Sat 8-Oct-88 21:17:01 EDT
Date: Sat, 8 Oct 88 21:16 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EQUAL-STRUCTURE (Version 5)
To: JonL@Lucid.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881008-163306-2318@Xerox>
Message-ID: <881008211646.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

It was still on my agenda to fix the complaints you had about the EQUALP
description. Your comments about my proposed changes to v4 and my v5
crossed in the mail so this got left out. Larry sent v5 to X3J13 before
I had a chance to fix that. Anyway, please just come to the meeting with
a proposed change to the wording in hand so we don't have to conjure it
from scratch when the issue comes up. Thanks.
 -kmp

∂08-Oct-88  1902	CL-Cleanup-mailer 	Issue: PACKAGE-DELETION (Version 4) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Oct 88  18:43:09 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 473416; Sat 8-Oct-88 21:41:38 EDT
Date: Sat, 8 Oct 88 21:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-DELETION (Version 4)
To: JonL@Lucid.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8810080219.AA02759@bhopal>
Supersedes: <881008214054.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <881008214120.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Fri, 7 Oct 88 19:19:18 PDT
    From: Jon L White <jonl@lucid.com>

    Could you double check to be sure that you didn't misread something?
    ...

You're right. I misread this part. Sorry for doubting you.

I won't belabor the style point now. Everyone's got too much to read already.

∂08-Oct-88  2006	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Oct 88  20:06:39 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 473427; Sat 8-Oct-88 23:05:01 EDT
Date: Sat, 8 Oct 88 23:04 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)
To: JonL@Lucid.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8810070517.AA07620@bhopal>
Message-ID: <881008230447.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

I can't approve of this proposal.

Many portable programs will be forced to put :USE "LISP" in where they
do not currently specify. There is no ambiguity in those programs --
they are using a well-advertised default -- so it is not proper to make
claims like "if they care, they should be specific".

Similar arguments could be made for the OPEN keywords. Perhaps all keys
should default in an implementation-dependent fashion and users should be
highly-specific about their intent.

I think it is appropriate for Common Lisp to specify useful portable defaults.
I think it is inappropriate for Common Lisp to be encouraging vendor
divergence. Common Lisp tolerates such divergence of necessity, but it
should not be a goal because it does not serve the user community.

Finally, under current practice, you ignored my remarks about Cloe so I'll
repeat them. Cloe shadows MAKE-PACKAGE, IN-PACKAGE, etc. in the default
package so that it offers the functionality you desire in a way that is
not incompatible to Lisp. I would recommend that you do the same.
 LISP:MAKE-PACKAGE name &KEY nicknames (USE "LISP")
 CLOE:MAKE-PACKAGE name &KEY nicknames (USE "CLOE")
Once you've chosen a package to work from, all calls to an unqualified
MAKE-PACKAGE do the thing that is natural for that initial package.

∂08-Oct-88  2021	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (version 2)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88  20:20:53 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 OCT 88 20:18:22 PDT
Date: 8 Oct 88 20:18 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: MAKE-PACKAGE-USE-DEFAULT (version 2)
To: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881008-201822-2495@Xerox>

There's enough debate on this that this might be helpful.
!
Issue:        MAKE-PACKAGE-USE-DEFAULT 

References:    MAKE-PACKAGE, CLtL p183
               "USER" package, CLtL p181

Related issues: PACKAGE-CLUTTER

Category:      CHANGE

Edit history:  JonL White, 6-Oct-88 (version 1)
               Masinter,  8-Oct-88  (version 2)

Problem description:

The proposal in the issue PACKAGE-CLUTTER would specify that 
implementation-specific extensions are not in the LISP package.

With that restriction, access to implementation-specific features
is awkward; it is necessary to always name the vendor-specific
extensions in the :USE list of MAKE-PACKAGE or (if the proposal
in DEFPACKAGE is adopted) in DEFPACKAGE.

This forces users of a specific implementation to always have
to type something to get the default set of features for that
implementation, even if they have no intention of writing portable
code.


Proposal MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT

Change the specification of MAKE-PACKAGE (and DEFPACKAGE, if
adopted, and IN-PACKAGE, if IN-PACKAGE-FUNCTIONALITY is not
adopted) so that the default for the :USE keyword is 
implementation-dependent. Normally, the default will include
the packages containing the implementation-specific features.

Portable programs should instead always specify :USE '("LISP")
explicitly.  

Examples:

(package-use-list (make-package "SOME-USER"))
(package-use-list "USER")


Test Cases:

(assert 
    (subsetp `(,(find-package "LISP"))
              (package-use-list (or (find-package "SOME-USER")
				    (make-package "SOME-USER")))))


Rationale:

Every implementation either already does the equivalent of this, or
else has a confusing assymetry about the USER package (i.e., their
extensions are "available" in USER, but not in SOME-USER).

Current practice:

TI and Lucid's  3.0 versions "implement" this proposal in that they set 
the default :USE argument to be a list of the LISP package and the 
implementation-specific package. 

In VAXLISP the LISP package is the implementation-specific
package, which contains the 775 symbols supposed to be in the LISP packge
along with all the extensions; the package named COMMON-LISP
has only the 775.  Thus this implements the proposal in the sense that
the inheritance of a package made with a default :USE list contains
all the implementation-specific symbols -- not just the 775 "LISP" ones.

Symbolics release 7, and Lucid's 2.1 release use only '("LISP") for the
default MAKE-PACKAGE use list, but have the aforementioned assymetry
about the USER package.

Cost to Implementors:

None; this relaxes a constraint imposed by CLtL.

Cost to Users:

In theory, every user porting code from one vendor to another would
have to ensure that every package definition, via IN-PACKAGE or
MAKE-PACKAGE, had an explicit :USE list.  This is probably at most
a 5-minute text editor search.  But in fact this imposition is moot,
since virtually every such user has *already* supplied explicit
:USE lists; given the current practice, he has had no alternative.


Cost of non-adoption:

There will continue to be a lack of clear standardization in this area,
especially since vendors are more willing to violate this apparently
unuseful mandate from CLtL than they are to give up a minor bias towards
their customer base.

Performance impact:

None.

Benefits:

This new default behaviour for package creation will permit 
documented extensions to appear on equal footing with the basic facilities
in the LISP package.  It appears as though the _majority_ of any  
users are developing and running their code totally within the 
enviornment provided by that one vendor; hence it seems reasonable for
implementations to bias their default use list towards those making 
frequent use of their specific extensions to Common Lisp.


Esthetics:

Some feel that fewer implementation-dependent loopholes in the language
is preferable, even when the practical import is virtually moot.

Discussion:

Lucid "exposes" the default :use list as the value of the special
variable *DEFAULT-MAKE-PACKAGE-USE-LIST*, so that at site-configuration
time, one could do
	  (setq *DEFAULT-MAKE-PACKAGE-USE-LIST* '("LISP"))
to return to the 1984 CLtL behaviour.  [This is not being proposed
at this time.]

∂08-Oct-88  2211	CL-Cleanup-mailer 	DRAFT Issue: TAILP-NIL (Version 2)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88  22:11:01 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 22:06:05 PDT
Date: 8 Oct 88 22:06 PDT
From: masinter.pa@Xerox.COM
Subject: DRAFT Issue: TAILP-NIL (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881008-220605-2581@Xerox>


!
Issue:		TAILP-NIL
References:	TAILP (p275)
Category:	CLARIFICATION/CHANGE
Edit History:	13-Sep-88, version 1 by Walter van Roggen,
		13-Sep-88, version 2 by Pitman

Problem Description:

  CLtL (p275) specifies TAILP as:

    TAILP sublist list				[Function]

    This predicate is true if SUBLIST is a sublist of LIST (i.e.,
    one of the conses that makes up LIST); otherwise, it is false.
    Another way to look at this is that TAILP is true if
    (NTHCDR n list) is SUBLIST, for some value of N. See LDIFF.

  Two common implementations of this definition are:

   (defun tailp (sublist list)			;Definition "A"
     (do ((list list (cdr list)))
	 ((endp list) nil)
       (if (eq sublist list)
	   (return t))))

   (defun tailp (sublist list)			;Definition "B"
     (do ((list list (cdr list)))
	 ((atom list) (eq list sublist))
       (if (eq sublist list)
	   (return t))))

  They differ only in their treatment of the atomic case.

  At issue is the fact that () is a list, and hence some would
  argue that it is a sublist of all other lists. On the other hand,
  the definition of TAILP seems to imply that being a cons is a
  necessary precondition of being a "sublist".

Proposal (TAILP-NIL:NIL):

  Clarify that the sublist argument to TAILP must be a list
  and that (TAILP NIL X) returns NIL for all lists X.

  Qualify the description in CLtL by saying that (TAILP sublist list)
  is true if SUBLIST is a cons and (NTHCDR n list) is SUBLIST for
  some value of N, and is false otherwise.

  Rationale:

   This is the status quo in a number of implementations.

Proposal (TAILP-NIL:T):

  Strike any text in the definition of TAILP which suggests that a
  sublist must be a cons.

  Clarify that (TAILP any-atom list) returns T iff (NTHCDR n list) is
  SUBLIST for some value of N, and false otherwise.

  Rationale:

   This is more consistent with the definition of LDIFF, which
   gives a useful meaning to arbitrary atomic SUBLIST arguments.

   This gives a more elegant definition of SUBLIST, allowing it to
   refer to any list -- including the empty list -- which is a
   part of another list.

Test Cases:

 #1: (LET ((X '(B C))) (TAILP X (CONS 'A X)))
     should return T in all implementations.

 #2: (TAILP '(X Y) '(A B C))
     should return NIL in all implementations.

 #3: (TAILP '() '(A B C))
     returns NIL under proposal TAILP-NIL:NIL
     returns T   under proposal TAILP-NIL:T

 #4: (TAILP 3 '(A B C))
     is an error under proposal TAILP-NIL:NIL
     returns NIL under proposal TAILP-NIL:T

 #5: (TAILP 3 '(A B C . 3))
     is an error under proposal TAILP-NIL:NIL
     returns T under proposal TAILP-NIL:T

 #6: (TAILP '(X Y) '(A B C . 3))
     is an error under proposal TAILP-NIL:NIL
     returns NIL under proposal TAILP-NIL:T

Current Practice:

  Symbolics Genera is consistent with TAILP-NIL:T.

  [Walter alleges TAILP-NIL:NIL is what all implementations already
   do, but since Genera is not in conformance, KMP regards that
   hypothesis as suspect. We need real data points, folks.]

Cost to Implementors:

  An implementation of TAILP-NIL:NIL is given as Definition "A" in the
  problem description.

  An implementation of TAILP-NIL:T is given as Definition "B" in the
  problem description.

  Some implementations might have compiler optimizers for these definitions
  as well, so a slight amount of additional effort might be required.

Cost to Users:

  Given that current practice varies widely on the disputed case,
  this is unlikely to have a practical effect on existing portable code.

Benefits:

  Either description makes the language more precise.

  [Pitman believes that] TAILP-NIL:T is more consistent with the behavior
  of TAILP and more consistent with what he thinks should be the 
  definition of a sublist.

Discussion:

  This issue was first raised in ">GLS>clarifications.text" of 12/06/85.

  Pitman supports TAILP-NIL:T.



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

∂08-Oct-88  2237	CL-Cleanup-mailer 	Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Oct 88  22:37:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 88 22:33:21 PDT
Date: 8 Oct 88 22:33 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES 
In-reply-to: Dan L. Pierson <pierson%mist@MULTIMAX.ENCORE.COM>'s message of
 Fri, 07 Oct 88 19:10:08 EDT
To: Dan L. Pierson <pierson%mist@MULTIMAX.ENCORE.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881008-223321-2629@Xerox>

I think this issue is also addressed by ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS;
certainly the ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS "Problem Description" has a
lot of overlap with the problem description here.

∂08-Oct-88  2347	CL-Cleanup-mailer 	DRAFT Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Oct 88  23:47:40 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 473524; Sun 9-Oct-88 02:46:12 EDT
Date: Sun, 9 Oct 88 02:45 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DRAFT Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)
To: JonL@Lucid.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881008-173818-2382@Xerox>
Message-ID: <881009024557.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

I didn't find your Proposal section to be clear on whether the
body was naturally iterated or whether you had to do your own
iteration. I assumed the latter, but it should be made clearer.
The following example you gave makes things very muddy:

    The following functions prints out every interned symbol:

    (defun print-all-symbols () 
      (with-package-iterator (next-symbol nil)
	(print (next-symbol))))


The problem this caused me is:
 - This doesn't iterate. I assume it just prints one thing and exits.
 - NEXT-SYMBOL is supposed to return a boolean value as its primary
   value. That means this will print a lot of T's, no?

Why not make the first value returned be something useful. I suggest
it should be the hash-key for hash-tables and the symbol for packages.
The second value should be the hash-value or the status, and the last
value should be the valid-p info.

∂09-Oct-88  0828	CL-Cleanup-mailer 	Re: Issue: TEST-NOT-IF-NOT (Version 1)   
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Oct 88  08:27:20 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa03086; 9 Oct 88 16:20 BST
Date: Sun, 9 Oct 88 16:20:02 BST
Message-Id: <8729.8810091520@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: TEST-NOT-IF-NOT (Version 1)
To: Jim McDonald <@sail.stanford.edu:jlm@lucid.com>, gls@think.com
In-Reply-To: Jim McDonald's message of Thu, 6 Oct 88 12:33:16 PDT
Cc: KMP@scrc-stony-brook.arpa, CL-Cleanup@sail.stanford.edu

>     My only complaint about this is that I use REMOVE-IF-NOT much more
>     frequently than REMOVE-IF.
>     --Guy
> 
> Maybe we should add KEEP-IF :-)
> 
> I could even get serious if we called it ABSTRACT.

How about FILTER.

∂09-Oct-88  0943	CL-Cleanup-mailer 	Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES   
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 9 Oct 88  09:43:46 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA10066; Sun, 9 Oct 88 12:43:21 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA05988; Sun, 9 Oct 88 12:45:09 EDT
Message-Id: <8810091645.AA05988@mist.UUCP>
To: masinter.pa%Xerox.COM@multimax
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES 
In-Reply-To: Your message of 08 Oct 88 22:33:00 -0700.
             <881008-223321-2629@Xerox> 
Date: Sun, 09 Oct 88 12:45:07 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    I think this issue is also addressed by
    ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS; certainly the
    ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS "Problem Description" has a lot
    of overlap with the problem description here.

So did I until JonL and others (?) pointed out that it was specifically
not covered by ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS.  (I was going to
append JonL's message, but I seem to have lost it.)

∂09-Oct-88  0953	CL-Cleanup-mailer 	Re: Issue: PRINT-PRETTY-HOOK (version 1) 
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 9 Oct 88  09:52:53 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA10098; Sun, 9 Oct 88 12:52:24 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA06034; Sun, 9 Oct 88 12:54:12 EDT
Message-Id: <8810091654.AA06034@mist.UUCP>
To: "David A. Moon" <Moon%STONY-BROOK.SCRC.Symbolics.COM@multimax>
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: PRINT-PRETTY-HOOK (version 1) 
In-Reply-To: Your message of Thu, 06 Oct 88 15:55:00 -0400.
             <19881006195542.6.MOON@EUPHRATES.SCRC.Symbolics.COM> 
Date: Sun, 09 Oct 88 12:54:10 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    		 Once that's clear a name can be chosen.  Possibly the
    	feature already exists in the language, via a :AROUND method
    	on PRINT-OBJECT with no specialized parameters, depending on whether
    	what that does is precisely what you wanted.
    
        Does it do what I want (I'm not yet a CLOS theologian)?
    
    Yes.
    
    I think this means we can withdraw the PRINT-PRETTY-HOOK proposal, since
    Common Lisp as amended by CLOS already will do what you want.

OK, consider it withdrawn UNLESS CLOS is later voted optional (which I
will not support).

∂09-Oct-88  1902	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 5) 
Received: from rice-chex.ai.mit.edu ([128.52.38.46]) by SAIL.Stanford.EDU with TCP; 9 Oct 88  19:02:41 PDT
Received: by rice-chex.ai.mit.edu; Sun, 9 Oct 88 22:01:43 EDT
Date: Sun, 9 Oct 88 22:01:43 EDT
From: dick@wheaties.ai.mit.edu (Richard C. Waters)
Message-Id: <8810100201.AA13115@rice-chex.ai.mit.edu>
To: masinter.pa@xerox.com
Cc: masinter.pa@xerox.com, Scott.Fahlman@b.gp.cs.cmu.edu,
        CL-Cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@xerox.com's message of 7 Oct 88 23:01 PDT <881007-230055-1825@Xerox>
Subject: Issue: STREAM-INFO (Version 5) 


The name can be changed any way you want.  I will work to change the
form any way you want too, if you give me a bit of guidance.

As for graphic characters.  I do not see that they should be any
problem. the printed width is simply the change in horizontal position
without regard to any vertical changes.  The printed width can be zero
if that is what is happening, or negative for that matter.  As long as it
is deterministic what the character will do, I do not see the problem.

			Dick Waters

∂10-Oct-88  0800	CL-Cleanup-mailer 	RE: Issue SYMBOL-MACROLET-SEMANTICS, Version 4
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 10 Oct 88  08:00:41 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA16527; Mon, 10 Oct 88 07:58:18 PDT
Date: Mon, 10 Oct 88 07:58:18 PDT
Message-Id: <8810101458.AA16527@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
To: Moon@stony-brook.scrc.symbolics.com
Subject: RE: Issue SYMBOL-MACROLET-SEMANTICS, Version 4

Maybe I mailed out something other than the text I kept, but my copy has all
reference to SETQ of a symbol macro removed.  Since 88-002R specifies that SETQ
of a symbol macro is OK, then it should remain OK.  Did I overlook something?

/JEP

∂10-Oct-88  1111	CL-Cleanup-mailer 	Re: DRAFT Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Oct 88  11:11:08 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 10 OCT 88 11:03:04 PDT
Date: 10 Oct 88 11:03 PDT
From: cutting.pa@Xerox.COM
Subject: Re: DRAFT Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
In-reply-to: Kent M Pitman's message of Mon, 1 Aug 88 14:32 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU,
 Cutting.PA@Xerox.COM
Message-ID: <881010-110304-3799@Xerox>

"- A misreading of the proposal might lead one to believe that one could
   do (SETQ CH1 (READ-CHAR STREAM))
      (SETQ CH2 (PEEK-CHAR NIL STREAM))
      (SETQ CH3 (READ-CHAR STREAM))
      (UNREAD-CHAR CH1 STREAM)
   since the unread-char is correctly separated from the PEEK-CHAR by an
   intervening READ-CHAR. The problem is that the wrong char is being
   unread. Some implementations support this, but it's definitely not
   condoned by the description of UNREAD-CHAR on p379."

I assume that the proposal, as a clarification, is to be read in the
context of CLtL.  Your example is already prohibited by CLtL, hence this
proposal need not address it.

There are thus a set of constraints on UNREAD-CHAR:

(1) UNREAD-CHAR must only be applied to the
    result of the last call to READ-CHAR;
(2) UNREAD-CHAR must not be called twice in succession
    without an intervening call to READ-CHAR;
(3) UNREAD-CHAR must not be called after PEEK-CHAR
    without an intervening call to READ-CHAR.

(1) and (2) are in CLtL and (3) is my proposed clarification.
Your example is prohibited by (1).

  "It would be clearer for the proposal to just say that doing either a
   PEEK-CHAR or READ-CHAR `commits' all previous characters. UNREAD-CHAR
   on any character preceding that which is seen by the PEEK-CHAR
(including
   those passed over by PEEK-CHAR when `seeking' with a non-NIL first
   argument) is not portable."

I don't find this clearer, but I could live with it.

	Doug

∂10-Oct-88  1252	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Oct 88  12:52:25 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02272g; Mon, 10 Oct 88 12:50:55 PDT
Received: by bhopal id AA11361g; Mon, 10 Oct 88 12:49:15 PDT
Date: Mon, 10 Oct 88 12:49:15 PDT
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8810101949.AA11361@bhopal>
To: cl-cleanup@sail.stanford.edu
Cc: cl-cleanup@sail.stanford.edu, Masinter.pa@Xerox.COM
In-Reply-To: masinter.pa@Xerox.COM's message of 8 Oct 88 12:32 PDT <881008-123244-2125@Xerox>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)

     ... It would be valid for an implementation to ... remember the
     original array element-type or its canonical or expanded form ...
     and satisfy all of the constraints of this proposal.

This observation makes the proposal much more palatable, so I won't
press the issue beyond the following two observations:

(1)  The extra storage per array for remembering the original type can
     be quite minimal, depending on the implementation.  If arrays
     already allocate a full pointer for the type, that can just as
     well point at the pair (<upgraded-type> . <given-type>) shared
     among all such arrays.  If arrays use a special encoding of a few
     bits to identify the updgraded type, then a small number of extra
     bits suffices to index into a table of given types, overflowing
     to the use of a full pointer.  This does not necessarily
     complicate the runtime array access code, but could require enough
     trickiness in laying out arrays to be considered non-trivial. 

(2)  I find it esthetically disturbing that the existing proposal
     seems to force the following to be legal in many implementations:

       (setf (aref (the (array (unsigned-byte 5)) foo) 0)
	     127)

     Any proposal to make such code illegal would seem to be
     incompatible with ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING 
     since then, e.g., for any implementation for which 
     (array (unsigned-byte 5)) upgrades to (array (unsigned-byte 8))
     the following code would be illlegal or legal depending whether 
     baz is declared inline or not:

       (defun baz (x) (setf (aref x 0) 127)) 

       (defun peculiar ()
         (let ((x (make-array 0 :element-type '(unsigned-byte 4))))
	   (declare (type (array (unsigned-byte 4)) x))
	   (baz x)
           (aref x 0)))

     In fact, I can't even portably assume that PECULIAR returns a
     number, since in implementions which upgrade to (array t),
     BAZ could be consistently redefined to install a string.

     I keep wondering what the potential convert from FORTRAN or
     PASCAL would think of all this. 

Thanks for bearing with me.

 jlm      


 


∂10-Oct-88  1352	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.Stanford.EDU with TCP; 10 Oct 88  13:52:43 PDT
Received: from DOUGHNUT.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 59923; Mon 10-Oct-88 16:41:37 EDT
Date: Mon, 10 Oct 88 16:41 EDT
From: Brad Miller <miller@CS.ROCHESTER.EDU>
Subject: Re: Issue: EVAL-OTHER (Version 2) 
To: masinter.pa@XEROX.COM, common-lisp-object-system@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU
cc: Warren Harris <harris%hplwhh@HPLABS.HP.COM>
In-Reply-To: <881008-164009-2324@Xerox>
Message-ID: <19881010204134.1.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Sender: miller@CS.ROCHESTER.EDU
Reply-To: miller@CS.ROCHESTER.EDU
Organization: University of Rochester, Department of Computer Science
Postal-address: 610 CS Building, Comp Sci Dept., U. Rochester, Rochester NY 14627
Phone: 716-275-1118

    Date: 8 Oct 88 16:40 PDT
    From: masinter.pa@Xerox.COM

    The official procedure for participating in the Common Lisp Standardization
    effort is through your representitive to the X3J13 committee.

    While we're willing to accept proposals from the community at large,
    there's a large amount of work involved in the actual creation of the
    standard, and a fair amount of context. 

Well, I guess I'm part of the "community at large" but let me make one
inflammatory comment...

w/o generic EVAL or APPLY, CLOS is just a bag on the side of CL. It seems to
me the better approach is to make CLOS the language, and "traditional" CL
the subset. I know I would be a lot happier (as a heavy user of CL) that
way. I'd be happy to write this up as a formal proposal if that is what's
needed, but I don't really know what to do... edit Issue: EVAL-OTHER and
make it version 3, or do something else?

Asbestos suit on.

----
Brad Miller		U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}

∂11-Oct-88  0854	CL-Cleanup-mailer 	Issue: LAMBDA-FORM (Version 3) 
Received: from IVORY.S4CC.Symbolics.COM ([128.81.51.1]) by SAIL.Stanford.EDU with TCP; 11 Oct 88  08:54:33 PDT
Received: from ROCKY-MOUNTAINS.S4CC.Symbolics.COM by IVORY.S4CC.Symbolics.COM via INTERNET with SMTP id 194646; 11 Oct 88 11:10:05 EDT
Date: Tue, 11 Oct 88 11:16 EDT
From: Allan C. Wechsler <ACW@IVORY.S4CC.Symbolics.COM>
Subject: Issue: LAMBDA-FORM (Version 3)
To: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
In-Reply-To: <881007-160733-1324@Xerox>
Message-ID: <19881011151620.6.ACW@ROCKY-MOUNTAINS.S4CC.Symbolics.COM>

I have an observation against the proposal LAMBDA-FORM:NEW-MACRO.

In Scheme, the operator of a function invocation form has the same
evaluation semantics as the operands.  In CL, however, the operator is
not evaluated in the same way that the operands are.

I am concerned lest the new macro called LAMBDA should obscure this
difference in evaluation semantics.  A novice Lisp programmer would have
a hard time understanding why the #' is optional in

     (MAP [#'](LAMBDA (POINT) (+ (POINT-X POINT) (POINT-Y POINT))) 
          POINT-LIST)

... but is required in

     (MAP #'SUM-OF-COORDS POINT-LIST)

.  

In sum, I believe that #' is a valuable marker of the difference in
syntax between operator and operand.

(If CL were to become truly Scheme-like, and the evaluation semantics of
operators and operands became the same, I would certainly drop this
objection.  But I am opposed to papering over asymmetries with deceptive
macrology.)

∂11-Oct-88  1000	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (version 2)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Oct 88  10:00:05 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 474097; Tue 11-Oct-88 12:58:26 EDT
Date: Tue, 11 Oct 88 12:58 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MAKE-PACKAGE-USE-DEFAULT (version 2)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881008-201822-2495@Xerox>
Message-ID: <19881011165801.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT is okay with me.
I think it might be better to strengthen it and say that the
default for :USE is identical to the use list of the USER package.
Does anyone agree?

In response to Kent's remarks, the issue is whether the default should
be a portable way to get the local extensions, or a portable way to
get the portable language without the extensions.  I think either of
those choices is portable and reasonable, it just depends on what you
want to make easier, which probably depends on whether a package is
being set up for use only by a predefined program or for use by user
typein and/or user-written programs, either of which are likely to
expect the local extensions.

Hence I would also accept a proposal to make the default for :USE
continue to be the LISP package, rather than incompatibly changing it,
and add a portable name for the local extensions.

∂11-Oct-88  1007	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Oct 88  10:07:24 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 474104; Tue 11-Oct-88 13:05:21 EDT
Date: Tue, 11 Oct 88 13:05 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8810080425.AA03150@bhopal>
Message-ID: <19881011170501.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

As Kent pointed out, the new example doesn't make any sense.  Also
I still think the with-package-iterator syntax isn't right.  The way
you have it now, there is a required argument <package> which by
default is ignored!  Richard's idea of using keyword arguments is
a good one, but something is still a little bit off.  I think everything
else is okay.

∂11-Oct-88  1043	CL-Cleanup-mailer 	Re: several hundred ugly things     
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 11 Oct 88  10:40:49 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa03324; 9 Oct 88 18:07 BST
Date: Sun, 9 Oct 88 18:06:33 BST
Message-Id: <8809.8810091706@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: several hundred ugly things 
To: Scott.Fahlman@b.gp.cs.cmu.edu, masinter.pa@xerox.com
In-Reply-To: Scott.Fahlman@edu.cmu.cs.gp.b's message of Thu, 06 Oct 88 20:51:36 EDT
Cc: CL-Cleanup@sail.stanford.edu

L.Masinter:
   There's some desire in some parts of ISO to make Common Lisp
   "smaller". I'd just as soon see it done carefully -- rather than with
   an axe. If you can think of several hundred things that could be done
   to Common Lisp that would make it smaller and not as ugly, perhaps you
   could help name a few?

Scott Fahlman replied:
> The point of my comment about hundreds of ugly things was that if we throw
> a few existing features out of the standard on aesthetic grounds, we would
> open the door to demands that we throw hundreds of other things out.  I
> thought our charter was to introduce incompatible changes only if
> necessary, and not on strictly aesthetic grounds.

I agree with Scott's point to a large extent.  Merely saying that
something "looks nicer" (or something of that sort) is not much
reason for an incompatible change in a group, such as X3J13, where
compatibility is rated very high.  However, I think it may be useful
to say a bit more about what is happening in ISO.  Of course, I can
give only my own understanding of what is going on.

There is indeed interest in having something smaller than Common Lisp,
but the reasons are not strictly aesthetic.  One might argue a bit
about just how far "aesthetic" extends.  Are simplicity, consistency,
and economy of basic concepts strictly aesthetic?  I think they are
not, but it doesn't matter all that much: for we can always go back a
step and consider the implications for ease of learning and teaching,
for reasoning about programs and implementations, for ease of
implementation, the size and efficiency of applications, and so on.
These arguments might still be unconvincing in the end, but at least
we might agree that they are not strictly aesthetic.

Actually, I think it is rather difficult to find purely aesthetic
reasons at all.  Even the "eliminate -IF-NOT functions" proposal
is not being advance on aesthetic grounds alone.

> But to address the question you raise...
> 
> It seems to me that we could coherently divide the language into two
> levels: a kernel of necessary low-level functions and special forms, and a
> set of functions that can be straightforwardly implemented in terms of
> these kernel mechanisms.  [...]  Nobody would want to use a language
> that had just the kernel stuff, but making the division explicit
> might be of some use to implementors and to people doing formal
> analysis of programs.

It would almost certainly be useful for the ISO standard and, I would
think, for the ANSI one as well.  A formal semantics, if given, would
presumably be for a kernel, perhaps even a smaller kernel than the one
needed for straightforward implementation of the rest.  The EuLisp
group has long advocated layers of more or less this sort, though
Scott might consider their level 1 a subset of the unprincipled sort.

> I have never seen a principled proposal for a Common Lisp subset that
> includes some amount of non-kernel functionality.

I am inclined to agree.  However, there might be different approaches
to devising the kernel.  One apporach would be to identify a subset of
Common Lisp as it is now.  But it might be possible to get a more
compact kernel by adding a few new primitives instead.  I would not
like to rule out the latter approach in advance.

∂11-Oct-88  1601	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION (Version 3)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Oct 88  16:01:02 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 474475; Tue 11-Oct-88 18:59:36 EDT
Date: Tue, 11 Oct 88 18:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LISP-SYMBOL-REDEFINITION (Version 3)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881007-190359-1626@Xerox>
Message-ID: <19881011225918.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 7 Oct 88 19:04 PDT
    From: masinter.pa@Xerox.COM

    David was right; version 2 was full of typos. The original problem
    description -- about an incident where a beginning user redefined
    MAKE-LIST -- is not in fact really addressed by this issue, since we
    haven't required implementations to signal an error (and don't want
    to.)

LISP-SYMBOL-REDEFINITION:DISALLOW looks okay.  I'm not concerned about
the original problem description -- a good programming environment for
beginning users would keep them from redefining MAKE-LIST
unintentionally, and a bad programming environment for beginning users
would not, but they both implement Common Lisp the language as amended
by this proposal.  So actually I think the original problem description
really is addressed by this issue, it's just not eliminated by it.

    Clarify that, as implied by CLtL p. 69, it is an error to rebind
    any symbol in CL defined as a constant.

Does "rebind" mean as with LET, or as with SETQ, or as with MAKUNBOUND?
I think you mean all three, it would be better to be more explicit.

You also need to cover redefining type-specifiers with DEFTYPE, DEFSTRUCT,
or DEFCLASS, and redefining SETF macros or functions with DEFSETF or
DEFINE-SETF-METHOD (or with DEFUN or equivalent when the cleanup
proposal for that goes through, sorry its name escapes me at the moment,
maybe setf-function-vs-macro).

∂11-Oct-88  1614	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION (Version 3)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Oct 88  16:14:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 474487; Tue 11-Oct-88 19:12:43 EDT
Date: Tue, 11 Oct 88 19:12 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LISP-SYMBOL-REDEFINITION (Version 3)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881007-190359-1626@Xerox>
Supersedes: <19881011225918.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: After thinking a bit, realized the proposal is inadequate.
Message-ID: <19881011231233.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 7 Oct 88 19:04 PDT
    From: masinter.pa@Xerox.COM

    David was right; version 2 was full of typos. The original problem
    description -- about an incident where a beginning user redefined
    MAKE-LIST -- is not in fact really addressed by this issue, since we
    haven't required implementations to signal an error (and don't want
    to.)

LISP-SYMBOL-REDEFINITION:DISALLOW looks okay.  I'm not concerned about
the original problem description -- a good programming environment for
beginning users would keep them from redefining MAKE-LIST
unintentionally, and a bad programming environment for beginning users
would not, but they both implement Common Lisp the language as amended
by this proposal.  So actually I think the original problem description
really is addressed by this issue, it's just not eliminated by it.

    Clarify that, as implied by CLtL p. 69, it is an error to rebind
    any symbol in CL defined as a constant.

Does "rebind" mean as with LET, or as with SETQ, or as with MAKUNBOUND?
I think you mean all three, it would be better to be more explicit.

You also need to cover redefining type-specifiers with DEFTYPE, DEFSTRUCT,
or DEFCLASS, and redefining SETF macros or functions with DEFSETF or
DEFINE-SETF-METHOD (or with DEFUN or equivalent when the cleanup
proposal for that goes through, sorry its name escapes me at the moment,
maybe setf-function-vs-macro).

On the other hand, there is a major gap between what this proposal says
and what KMP wanted, and I think KMP was right.  This proposal doesn't
forbid users from redefining things that -aren't- already defined, but
are in the Lisp package.  For example, it doesn't forbid doing

  (proclaim '(special type))

[I am not making this up] which can cause other programs to fail by
making what should have been a lexical binding turn into a special
binding.

∂11-Oct-88  2004	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION (Version 3)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Oct 88  16:14:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 474487; Tue 11-Oct-88 19:12:43 EDT
Date: Tue, 11 Oct 88 19:12 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LISP-SYMBOL-REDEFINITION (Version 3)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881007-190359-1626@Xerox>
Supersedes: <19881011225918.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: After thinking a bit, realized the proposal is inadequate.
Message-ID: <19881011231233.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 7 Oct 88 19:04 PDT
    From: masinter.pa@Xerox.COM

    David was right; version 2 was full of typos. The original problem
    description -- about an incident where a beginning user redefined
    MAKE-LIST -- is not in fact really addressed by this issue, since we
    haven't required implementations to signal an error (and don't want
    to.)

LISP-SYMBOL-REDEFINITION:DISALLOW looks okay.  I'm not concerned about
the original problem description -- a good programming environment for
beginning users would keep them from redefining MAKE-LIST
unintentionally, and a bad programming environment for beginning users
would not, but they both implement Common Lisp the language as amended
by this proposal.  So actually I think the original problem description
really is addressed by this issue, it's just not eliminated by it.

    Clarify that, as implied by CLtL p. 69, it is an error to rebind
    any symbol in CL defined as a constant.

Does "rebind" mean as with LET, or as with SETQ, or as with MAKUNBOUND?
I think you mean all three, it would be better to be more explicit.

You also need to cover redefining type-specifiers with DEFTYPE, DEFSTRUCT,
or DEFCLASS, and redefining SETF macros or functions with DEFSETF or
DEFINE-SETF-METHOD (or with DEFUN or equivalent when the cleanup
proposal for that goes through, sorry its name escapes me at the moment,
maybe setf-function-vs-macro).

On the other hand, there is a major gap between what this proposal says
and what KMP wanted, and I think KMP was right.  This proposal doesn't
forbid users from redefining things that -aren't- already defined, but
are in the Lisp package.  For example, it doesn't forbid doing

  (proclaim '(special type))

[I am not making this up] which can cause other programs to fail by
making what should have been a lexical binding turn into a special
binding.

∂13-Oct-88  0726	CL-Cleanup-mailer 	DRAFT Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Oct 88  07:25:58 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Thu, 13 Oct 88 10:23:36 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 13 Oct 88 10:22:43 EDT
Date: Thu, 13 Oct 88 10:23 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: DRAFT Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881008-173818-2382@Xerox>
Message-Id: <19881013142325.5.BARMAR@OCCAM.THINK.COM>

    Date: 8 Oct 88 17:38 PDT
    From: cl-cleanup@sail.stanford.edu

    The following functions prints out every interned symbol:

    (defun print-all-symbols () 
      (with-package-iterator (next-symbol nil)
	(print (next-symbol))))

This example is incorrect.  It should be:

(defun print-all-symbols () 
  (with-package-iterator (next-symbol nil)
    (loop
      (multiple-value-bind (more? symbol) (next-symbol)
	(if more? (next-symbol)
	    (return))))))

                                                barmar

∂13-Oct-88  1135	CL-Cleanup-mailer 	Fairfax meeting summary   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  11:35:41 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA14968; Thu, 13 Oct 88 12:34:02 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19764; Thu, 13 Oct 88 12:34:00 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810131834.AA19764@defun.utah.edu>
Date: Thu, 13 Oct 88 12:33:59 MDT
Subject: Fairfax meeting summary
To: cl-cleanup@sail.stanford.edu

Here is a summary of what happened at the Fairfax meeting that affects
the compiler committee.  This is what I have in my notes and if I've
got something confused, feel free to speak up and correct me.

Issues COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS,
EVAL-WHEN-NON-TOP-LEVEL, and DEFINING-MACROS-NON-TOP-LEVEL were tabled
in order to allow time to prepare new proposals.  If new proposals
don't materialize in time for voting at the next meeting, we will vote
on the existing proposals then. 

Issues COMPILE-ARGUMENT-PROBLEMS (with amendment), COMPILE-FILE-PACKAGE
(with wording change suggested by Pitman), OPTIMIZE-DEBUG-INFO, and
PROCLAIM-INLINE-WHERE (with wording change suggested by Slater) were
voted on and accepted.

Two polls were taken on things relating to outstanding issues.  The
first indicated substantial opposition and very little support for
doing anything that would require interpreters to do macroexpansion
and other kinds of syntactic processing in a prepass before doing the
actual evaluation.  Pitman wanted it pointed out that this reflected
people's (possibly) uninformed opinion, however.

The second poll was on the various options for issue LOAD-TIME-EVAL.  I'm
going to address this issue in more detail in a separate message, but
here are the results of the voting.

option				like	hate
----------------------------------------------
remove #, completely		14	8
new special form		19	4
quoted magic token		6	13
do nothing			1	19

I would like to put as many of the remaining issues as we can on a
mail ballot in December.  To do so, the latest we can accept comments
and requests for revisions on those issues is mid-November -- that is,
about a month from now.  I'm going to have to assume that if people on
the compiler committee don't submit their comments in a timely manner,
that implies approval of the way things are going. 

Other specific people I have marked down as doing specific things:

  Pierson, Haflich, Barrett, and Perdue indicated they would try
  to prepare new proposals on the three issues that were tabled.  I
  am expecting that they will either distribute draft versions or give
  up within the next month.

  JonL volunteered to help figure out what compiler support is needed
  by CLOS. 

  Dan Pierson and I are working on the compiler warnings issue.

  The cleanup committee has two issues open that deal with the special
  compiler handling of package functions; I will ask Masinter to keep us
  informed on what happens with them.

-Sandra
-------

∂13-Oct-88  1147	CL-Cleanup-mailer 	oops  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  11:47:30 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA15286; Thu, 13 Oct 88 12:45:49 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19784; Thu, 13 Oct 88 12:45:46 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810131845.AA19784@defun.utah.edu>
Date: Thu, 13 Oct 88 12:45:45 MDT
Subject: oops
To: cl-cleanup@sail.stanford.edu

Sorry, that last message slipped out prematurely before I'd finished
editing it.  I had intended to add the following blurb to the front:

This is the report I've just mailed out to the cl-compiler mailing
list.  As I've noted, there are a few cleanup issues pending that we
compiler people need to keep track of, particularly the two that
relate to the magic compiler handling of the package functions
(DEFPACKAGE and IN-PACKAGE-FUNCTIONALITY).  Some of us (including me)
who are on the cl-compiler mailing list are not also on cl-cleanup.
I'd like to ask that people who are submitting new proposals on these
issues cc them to cl-compiler, so that the compiler people can stay
informed.  (I don't know if we need to see all the discussion, though;
use your own discretion there.)

-Sandra
-------

∂13-Oct-88  1200	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATIONS (version 3)   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Oct 88  12:00:37 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA13409; Thu, 13 Oct 88 11:58:56 PDT
Date: Thu, 13 Oct 88 11:58:56 PDT
Message-Id: <8810131858.AA13409@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: CLOSED-STREAM-OPERATIONS (version 3)

Status: DRAFT
Issue:        CLOSED-STREAM-OPERATIONS
References:   CLOSE (CLtL p 332)
Category:     CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
               8-Oct-88, Version 2 by Masinter
              13-Oct-88, Version 3 by van Roggen
 
Related Issues: STREAM-ACCESS, STREAM-INFO
 
 
Problem Description:
 
The description of CLOSE is not completely clear about the functions
which are allowed to be performed on a closed stream.
 
On p332 it says:
	"The stream is closed. No further Input/output operations may be
	performed on it. However, certain inquiry operations may still
	be performed, ..."
but the list of inquiry operations is not specified.
 
At least one implementation interpreted the list to include
at least OUTPUT-STREAM-P, while another has disallowed that operation
to be performed on a closed stream. 

 
Proposal (CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY)
 
Clarify that one may call the following functions on closed streams without
error due to the stream being closed:

  STREAMP, INPUT-STREAM-P, OUTPUT-STREAM-P, CLOSE, PATHNAME, TRUENAME,
  MERGE-PATHNAMES, PATHNAME-HOST, PATHNAME-DEVICE, PATHNAME-DIRECTORY,
  PATHNAME-NAME, PATHNAME-TYPE, PATHNAME-VERSION, NAMESTRING, FILE-NAMESTRING,
  DIRECTORY-NAMESTRING, HOST-NAMESTRING, ENOUGH-NAMESTRING, OPEN,
  PROBE-FILE, DIRECTORY

If proposal STREAM-ACCESS:PROVIDE is adopted, all of its functions will work
on closed streams.

If proposal STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS is adopted, none of its
functions are required to work on closed streams.
 
Rationale:
 
One can consider many characteristics of a stream to be independent of
the ability to do I/O.  Being able to determine a stream's direction and
its name is often useful for debugging.  A number of the descriptions in
CLtL imply (weakly) the ability to work on closed streams.  Functions
such as OPEN and DIRECTORY don't really depend on the stream, but on
the name of the stream.
 
Current Practice:
 
At least two implementations differ in which functions are allowed to be
performed on a closed stream.
 
Cost to Implementors:
 
Unknown, but likely to be small in most implementations.  A nontrivial
amount of work may be necessary if the pathname information is held
externally and is normally deleted when the stream is closed.  The
implementation will have to copy the information at some time for later
inquiries.

Cost to Users:

None.
 
Benefits:
 
This clarification will assist users in writing portable code.
 
Aesthetics:
 
Yes.
 
Discussion:

There are some separate, but related, issues regarding what CLOSE should
do on composite streams or constructed streams.

∂13-Oct-88  1210	CL-Cleanup-mailer 	Issue: DEFSTRUCT-REDEFINITION  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Oct 88  12:10:29 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA13980; Thu, 13 Oct 88 12:08:50 PDT
Date: Thu, 13 Oct 88 12:08:50 PDT
Message-Id: <8810131908.AA13980@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: DEFSTRUCT-REDEFINITION

I'd favor requiring redefining the same DEFSTRUCT as not being an error.
One way to tell that two DEFSTRUCTs are the same (although probably not
the way any implementation would really want to do it) it that two
calls to DEFSTRUCT are the same if they are EQUAL.  It's hard to specify
something more general that might not get into problems with various
implementations.
			---Walter

∂13-Oct-88  1205	CL-Compiler-mailer 	summary on issue LOAD-TIME-EVAL    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  12:05:34 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA15821; Thu, 13 Oct 88 13:03:54 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19793; Thu, 13 Oct 88 13:03:52 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810131903.AA19793@defun.utah.edu>
Date: Thu, 13 Oct 88 13:03:50 MDT
Subject: summary on issue LOAD-TIME-EVAL
To: cl-compiler@sail.stanford.edu
Cc: cl-cleanup@sail.stanford.edu

(I've cc'ed this to cl-cleanup, but let's restrict further discussion
on this to cl-compiler, please.)

Here are the results of a poll taken at the Fairfax meeting on the various
alternatives for LOAD-TIME-EVAL.  People were allowed to vote for or
against multiple alternatives.

option				like	hate
----------------------------------------------
remove #, completely		14	8
new special form		19	4
quoted magic token		6	13
do nothing			1	19

Something that came out during the discussion is that these
alternatives are not necessarily mutually exclusive. 

Another poll showed that there was general (but possibly uninformed)
opposition to doing anything that would require the interpreter to do
a code-walking prepass to perform processing such as macroexpansion.
(I'd suggest to Pitman that if he wants to pursue this further, he
write it up as a new issue.)

At least one person (Masinter) was of the opinion that it is OK to
allow for some slight differences between compiled and interpreted
code (such as allowing LOAD-TIME-VALUE to do the evaluation more than
once in the interpreter), provided that the possible differences are
well-documented. 

What I plan to do with this issue is to continue working on the two
alternatives that received the most support.  I will put together some
variant of the REVISED-NEW-SPECIAL-FORM proposal I started on earlier,
that decouples LOAD-TIME-VALUE from #, read syntax.  I will prepare a
separate issue to deal with removing #, from the standard language.
This approach would not rule out consideration of some other possible
alternatives later on.  For example, if both proposals are accepted,
it would be possible to introduce another proposal later to re-add #,
to the language and make it a synonym for LOAD-TIME-VALUE.  Or, if
removing #, is rejected, we could still propose to add the quoted
magic token function regardless of what happens to LOAD-TIME-VALUE. 

If anybody thinks that I've misunderstood the general sentiment on
this issue, please speak up *soon*.  I don't want to waste a lot of
time preparing proposals that would not have a reasonable chance of
being accepted. 

-Sandra
-------

∂13-Oct-88  1232	CL-Cleanup-mailer 	Issue: HASH-TABLE-ACCESS (version 2)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Oct 88  12:32:25 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA15360; Thu, 13 Oct 88 12:30:44 PDT
Date: Thu, 13 Oct 88 12:30:44 PDT
Message-Id: <8810131930.AA15360@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: HASH-TABLE-ACCESS (version 2)

 
Issue: HASH-TABLE-ACCESS
References:	hash-tables (Chapter 21 of CLtL)
Category:	ADDITION
Edit History: 13-Sept-88, version 1 by Walter van Roggen
              13-Oct-88, version 2 by Walter van Roggen
 
Problem Description:
 
  There are many characteristics of hash-tables which are specified upon
  creation but are not accessible afterwards.
 
Proposal: (HASH-TABLE-ACCESS:PROVIDE)
 
  Add the following functions to the language:
 
  HASH-TABLE-REHASH-SIZE hash-table
 
    Returns the current rehash size of a hash table.
 
  HASH-TABLE-REHASH-THRESHOLD hash-table
 
    Returns the current rehash threshold of a hash table.
 
  HASH-TABLE-SIZE hash-table
 
    Returns the current size of a hash table.
 
  HASH-TABLE-TEST hash-table
 
    Returns the test used for comparing keys in the hash table.
    By default the value will be EQL.
 
 
Current Practice:
 
  VAX LISP and Lucid 3.0 implement the proposal.
 
Cost to Implementors:
 
  Most of these should be trivial to implement, since the information
  must be present for nearly all types.
 
Cost to Users:
 
  None.  This is an upward-compatible extension.
 
Cost of Non-Adoption:
 
  The benefits would not be available in a portable fashion.
 
Benefits:
 
  Programs would be able to access useful information otherwise hidden.
  For example, it would allow programs to gain statistics about hash
  table usage that might enable better tuning.
 
Discussion:
 
  None of these are required to be SETF'able, though some might be
  reasonable implementation-dependent extensions.  Including such
  modification abilities might constrain some implementations unduly.
 
  This first appeared in ">GLS>clarifications.text" of 12/06/85.

∂13-Oct-88  1237	CL-Cleanup-mailer 	Issue: ALIST-NIL (Version 4)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  12:37:44 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475700; Thu 13-Oct-88 15:36:11 EDT
Date: Thu, 13 Oct 88 15:35 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ALIST-NIL (Version 4)
To: CL-Cleanup@Sail.Stanford.EDU
cc: JonL@Lucid.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <881013153546.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from the Fairfax meeting...

Cleanup meeting:

 KMP: Moon has weak opposition to this proposal, primarily on compatibility grounds.

 Otherwise, we felt this was ready to vote.

X3J13 meeting:

 JonL: Worried that Lucid would have to change.
       [KMP pointed out that this isn't true because it becomes an "is an error"
       situation. JonL said that might be ok, but wanted to think more about it.]

 The issue was not voted upon.

∂13-Oct-88  1240	CL-Cleanup-mailer 	Issue: ARGUMENTS-UNDERSPECIFIED (Version 4)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  12:40:15 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475706; Thu 13-Oct-88 15:38:35 EDT
Date: Thu, 13 Oct 88 15:38 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ARGUMENTS-UNDERSPECIFIED (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <881013153825.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 KMP: Moon observes that MAKE-STRING is also addressed by Character committee.

 Otherwise, ready to vote.

X3J13 meeting:

 RWK: Content to allow this proposal ammend MAKE-STRING per CLtL, and have
      Character proposal supersede that when voted in, but maybe document
      should be explicit.

 Not voted upon.

∂13-Oct-88  1243	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  12:42:59 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475715; Thu 13-Oct-88 15:41:36 EDT
Date: Thu, 13 Oct 88 15:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013154128.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

X3J13 meeting:

 Masinter: Impact on character proposal.

 JonL: This issue seems mostly about TYPEP yet in one place
       addresses MAKE-ARRAY. [KMP couldn't figure out if JonL
       meant he didn't think it appropriate for the proposal
       to affect both or if he just didn't think the writeup
       did a good job of stating it had an impact on both.]

∂13-Oct-88  1245	CL-Cleanup-mailer 	issue ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  12:45:09 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA17097; Thu, 13 Oct 88 13:43:34 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19810; Thu, 13 Oct 88 13:43:32 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810131943.AA19810@defun.utah.edu>
Date: Thu, 13 Oct 88 13:43:30 MDT
Subject: issue ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
To: cl-cleanup@sail.stanford.edu

I don't see anything obviously wrong with the general approach taken
by this proposal.  However, I think the new functions added by
sections 7 and 8 are unnecessary and I would either like those parts
removed, or something added to the "Rationale" section to explain why
some people think they *are* necessary.  Also, since this proposal
changes the behavior of TYPEP on array type specifiers, I'd like to
see some clarification of how functions such as BIT-VECTOR-P that are
defined in terms of TYPEP in CLtL are affected by the change, or an
explicit statement that they're not.

-Sandra
-------

∂13-Oct-88  1246	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATIONS (Version 2)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  12:46:38 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475724; Thu 13-Oct-88 15:45:08 EDT
Date: Thu, 13 Oct 88 15:44 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOSED-STREAM-OPERATIONS (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013154459.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Responsibility for this issue was delegated to Jim Allard (@Gensym)
 and Dan Pierson.

X3J13 meeting:

 RWK: Existing propsoal maximizes incompatibilty
      [Barmar pointed out that this proposal doesn't force implementors
       to change -- it just points out what's portable. KMP agrees but
       doesn't know for sure if RWK bought this argument. In any case,
       the point should be clarified to avoid further discussion.]

∂13-Oct-88  1248	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  12:47:57 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475727; Thu 13-Oct-88 15:46:28 EDT
Date: Thu, 13 Oct 88 15:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013154620.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Responsibility for writing next draft of this issue was delegated to KMP.

∂13-Oct-88  1251	CL-Cleanup-mailer 	Issue: COERCE-INCOMPLETE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  12:51:32 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475736; Thu 13-Oct-88 15:50:10 EDT
Date: Thu, 13 Oct 88 15:50 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COERCE-INCOMPLETE (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013155002.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 KMP took responsibility for next draft.

X3J13 meeting:

 RWK: Maybe we should just remove COERCE?

 Beckerle: Maybe we should make COERCE generic?

 KMP: It is inappropriate to make anything generic if you cannot describe
      what it does. Since this issue is about what COERCE does, the issue
      cannot be solved by making COERCE generic. 

 Greenblatt: Let's keep generic functions out of the language as must as
	     possible on this "first round". [KMP thinks he meant the standard
	     we're working on -- leaving the issue of making more things
	     generic for a later standard.]

∂13-Oct-88  1254	CL-Cleanup-mailer 	Issue: CONSTANT-SIDE-EFFECTS (no proposal)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  12:54:44 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475742; Thu 13-Oct-88 15:53:07 EDT
Date: Thu, 13 Oct 88 15:52 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONSTANT-SIDE-EFFECTS (no proposal)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013155257.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Chris Perdue is supposedly doing this for the Compiler Committee.

X3J13 meeting:

 KMP: The relationship to #, which should be dealt with.

∂13-Oct-88  1255	CL-Cleanup-mailer 	Issue: CONTAGION-ON-NUMERICAL-COMPARISONS (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  12:55:48 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475745; Thu 13-Oct-88 15:54:20 EDT
Date: Thu, 13 Oct 88 15:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONTAGION-ON-NUMERICAL-COMPARISONS (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013155412.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

X3J13 meeting:

 There was discussion of voting on this, but van Roggen wanted time to
 review the issue carefully before voting.

∂13-Oct-88  1256	CL-Cleanup-mailer 	issue COERCE-FROM-TYPE    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  12:56:12 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA17317; Thu, 13 Oct 88 13:54:35 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19818; Thu, 13 Oct 88 13:54:32 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810131954.AA19818@defun.utah.edu>
Date: Thu, 13 Oct 88 13:54:31 MDT
Subject: issue COERCE-FROM-TYPE
To: cl-cleanup@sail.stanford.edu

I don't like the idea of adding another argument to COERCE just to
handle one or two strange cases.  For coercing NIL to be a string, I
agree with Ida that the right thing to do is to use the same
precedence rules as CLOS to disambiguate the situation.  And, I think
the whole idea of coercing a number to a string is pretty bogus,
particularly since there isn't any one obvious way to do it.

-Sandra
-------

∂13-Oct-88  1258	CL-Cleanup-mailer 	Issue: DECLARATION-SCOPE (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  12:58:45 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475754; Thu 13-Oct-88 15:57:14 EDT
Date: Thu, 13 Oct 88 15:57 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARATION-SCOPE (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: JonL@Lucid.COM
Message-ID: <881013155704.0.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 JonL will produce next writeup.

X3J13 meeting:

 Sandra: DECLARE-TYPE-FREE conflicts with this: This proposal mentions that
	 free declarations are not possible. Make the relationship between
	 the two proposals explicit in both.

∂13-Oct-88  1301	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:01:49 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475761; Thu 13-Oct-88 16:00:26 EDT
Date: Thu, 13 Oct 88 16:00 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-TYPE-FREE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013160017.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Thought to be ready to vote.

X3J13 meeting:

 Sandra: DECLARATION-SCOPE conflicts with this: It mentions that free
	 declarations are not possible. Make the relationship between
	 the two proposals explicit in both.

 Pierson wants this issue coordinated with this array proposal.
 See DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES.

 No vote was attempted.

∂13-Oct-88  1303	CL-Cleanup-mailer 	Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 2)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:03:23 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475763; Thu 13-Oct-88 16:01:37 EDT
Date: Thu, 13 Oct 88 16:01 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013160128.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 No opposition -- ready to vote.

X3J13 meeting:

 RWK thought he'd probably go along, but wanted time to study the issue.

∂13-Oct-88  1307	CL-Cleanup-mailer 	Issue: DECLARE-FUNCTION-AMBIGUITY (Version 3) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:07:26 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475776; Thu 13-Oct-88 16:05:58 EDT
Date: Thu, 13 Oct 88 16:05 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-FUNCTION-AMBIGUITY (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013160548.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 KMP: Moon is opposed but not vehemently -- thinks the incompatible
      change is gratuitous.

 Deemed ready for vote.

X3J13 meeting:

 Barmar: People he talked to back home seemed to prefer to document the
	 issue rather than change it.

 Sandra: Observes that a number of implementations accidentally implement
   	 this incorrectly. They first check the type table and then handle
	 the elaborate function declaration style. But, as it happens,
	 they never reach the code for the second case because function is
	 in the type table!

 van Roggen: Having both styles is worse than having either one or the other.

∂13-Oct-88  1311	CL-Cleanup-mailer 	Issue: DEFPACKAGE (Version 6)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:10:56 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475780; Thu 13-Oct-88 16:08:44 EDT
Date: Thu, 13 Oct 88 16:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFPACKAGE (Version 6)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013160835.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

X3J13 meeting:

 A straw poll was taken and there was unanimous approval of the
 concept of DEFPACKAGE, so it seems very likely this will
 ultimately pass.

 Walter: Wants to see a portable definition distributed.

 KMP: Notes that one issue is that DEFPACKGE needs to work somewhat
      differently when definitions are re-loaded than it did the
      first time. That issue would show up in the portable code,
      but the proposal is not specific enough to address that.
      Perhaps the proposal should be expanded to cover this situation?

∂13-Oct-88  1314	CL-Cleanup-mailer 	Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 2)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:14:05 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475786; Thu 13-Oct-88 16:12:00 EDT
Date: Thu, 13 Oct 88 16:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013161151.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Deemed ready to vote.

X3J13 meeting:

 No vote was attempted.

∂13-Oct-88  1314	CL-Cleanup-mailer 	Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:14:22 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475789; Thu 13-Oct-88 16:12:59 EDT
Date: Thu, 13 Oct 88 16:12 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013161251.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

X3J13 meeting:

 This was voted upon and ACCEPTED.

∂13-Oct-88  1315	CL-Cleanup-mailer 	issue DECLARATION-SCOPE   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:15:22 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA18009; Thu, 13 Oct 88 14:13:46 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19827; Thu, 13 Oct 88 14:13:44 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132013.AA19827@defun.utah.edu>
Date: Thu, 13 Oct 88 14:13:43 MDT
Subject: issue DECLARATION-SCOPE
To: cl-cleanup@sail.stanford.edu

I generally like this proposal because the wording it uses is much more
understandable than the terminology in CLtL (which I have never succeeded
in grokking fully).  I have two big problems with the current writeup:
other hand, it has two big problems:

(1) The treatment of TYPE declarations contradicts proposal
DECLARE-TYPE-FREE.  I don't think I could vote for either proposal
without some better indication of how they are supposed to work
together. 

(2) Since issue FLET-DECLARATIONS was passed at the March meeting, the
writeup needs to be changed to reflect that and give TYPE and FTYPE
declarations the same treatment (either both "bound" or both "free").

-Sandra
-------

∂13-Oct-88  1316	CL-Cleanup-mailer 	Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 2) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:16:37 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475792; Thu 13-Oct-88 16:14:59 EDT
Date: Thu, 13 Oct 88 16:14 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013161449.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 KMP: Moon says the Genera current practice info is wrong.
      Nevertheless, we (Symbolics) don't oppose the proposal since
      it is more consistent with CLOS.

∂13-Oct-88  1318	CL-Cleanup-mailer 	Issue: DEFSTRUCT-REDEFINITION (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:18:44 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475799; Thu 13-Oct-88 16:17:14 EDT
Date: Thu, 13 Oct 88 16:17 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFSTRUCT-REDEFINITION (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013161705.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Masinter and Gregor will take care of preparing a new writeup.

X3J13 meeting:

 Someone noted there's an unstated relation to CLOS chapter 3.

 RWK: Typo -- some uses of "ERROR-ITSELF" should be
      "ERROR-BY-ITSELF" (or vice versa) for internal consistency.

∂13-Oct-88  1319	CL-Cleanup-mailer 	Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 2) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:19:52 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475804; Thu 13-Oct-88 16:18:24 EDT
Date: Thu, 13 Oct 88 16:18 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Supersedes: <881013161449.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <881013161815.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

[I left something out in previous version.]

My notes from Fairfax meeting...

Cleanup meeting:

 KMP: Moon says the Genera current practice info is wrong.
      Nevertheless, we (Symbolics) don't oppose the proposal since
      it is more consistent with CLOS.

X3J13 meeting:

 Someone wondered about how you get back the #S printer for something
 that has inherited a non-#S printer once this proposal goes into effect.

∂13-Oct-88  1322	CL-Cleanup-mailer 	Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:21:56 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475807; Thu 13-Oct-88 16:20:32 EDT
Date: Thu, 13 Oct 88 16:20 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013162024.0.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Deemed ready to vote.

X3J13 meeting:

 Haflich: Is NIL ok as a slot name?

 RWK: Is signalling an error really right? eg, mightn't signalling
      a warning be better?

 KMP: Maybe we need a general proposal on what compilers due with
      errors/warnings.

 Sandra: Compiler committee is planning to address this issue.

∂13-Oct-88  1324	CL-Cleanup-mailer 	Issue: DESCRIBE-INTERACTIVE (Version 2)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:24:00 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475810; Thu 13-Oct-88 16:22:35 EDT
Date: Thu, 13 Oct 88 16:22 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DESCRIBE-INTERACTIVE (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013162227.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Pierson will re-draft this issue using the "other sense".
 ie, he will propose that DESCRIBE be clarified/changed to be
 not interactive.

X3J13 meeting:

 RPG thinks it's stupid to waste time on issues like this.
 Pitman and others disagreed.

∂13-Oct-88  1329	CL-Cleanup-mailer 	Issue: DOTTED-MACRO-FORMS (Version 2)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:29:34 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475817; Thu 13-Oct-88 16:28:04 EDT
Date: Thu, 13 Oct 88 16:27 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DOTTED-MACRO-FORMS (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013162756.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Steele did some poking around in CLtL and verified that indeed, dotted lists
 are explicitly permitted at recursive levels of DEFMACRO destructuring. As
 such, it was decided that the most consistent approach would be to require
 them to be permitted at toplevel as well.

 KMP will write next draft of this issue, changing the sense as agreed.

X3J13 meeting:

 JonL: Gratuitous: We shouldn't take any action that would cause work for
       either users or implementors without substantial potential gain.

∂13-Oct-88  1333	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION (version 4)   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:31:12 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA19322; Thu, 13 Oct 88 13:29:25 PDT
Date: Thu, 13 Oct 88 13:29:25 PDT
Message-Id: <8810132029.AA19322@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: LISP-SYMBOL-REDEFINITION (version 4)


Issue:         LISP-SYMBOL-REDEFINITION
 
References:    Cleanup issue PACKAGE-CLUTTER
		CLtL pp 67-69 Defining named functions
 
Category:      CLARIFICATION
 
Edit history:  Masinter, Version 1, 17-Sep-88 from (Kolb, 14-Aug-87)
               Masinter, Version 2, 7-Oct-88
               Masinter, Version 3,  7-Oct-88, fix typos
               van Roggen, Version 4, 13-Oct-88, undefined, not unspecified
 
Problem description:
 
Is it legal to redefine Common Lisp functions? There is no explicit
prohibition, and many implementations do allow redefinition of
functions in the Lisp package.
 
CLtL only says that special forms can not be redefined. But this doesn't 
solve the general problem of redefining system functions.
 
Proposal LISP-SYMBOL-REDEFINITION:DISALLOW
 
The consequences of redefining as a function or macro any of the functions,
macros, or special forms defined in the LISP package are undefined;
similarly, the consequence of lexically defining (with FLET, LABELS or
MACROLET) any function or macro in the LISP package is undefined.
 
Clarify that, as implied by CLtL p. 69, it is an error to rebind
any symbol in CL defined as a constant.
 
The consequences of applying TRACE to any function in the LISP package is
undefined.
 
Following the proposed definition of "consequences are undefined", this means that
implementations may signal an error, or other undefined behavior may
ensue. For example, programming environments may warn the user about
redefinition of LISP symbols and then allow them. Some environments may
distinguish between functions that are safe to redefine and those that are
not.
 
Examples:
 
The behavior of the construct:
 
(FLET ((OPEN (filename &key direction) (format t "Open called....") 
			(OPEN filename :direction direction)))
    (with-open-file (x "frob" :direction ':output) 
		(format t "was Open called?")))
 
is undefined; for example, the macro expansion of with-open-file might refer
to the OPEN function and might not.
 
(DEFUN CAR (X) (CDR X))
 
might signal an error.
 
Rationale:
 
This proposal is the only simple resolution of the problem description that
we can imagine that is consistent with current implementation techniques.
 
Allowing arbitrary redefinition of symbols in the LISP package would place
severe restrictions on implementations not to actually use those symbols in
macro expansions of other LISP symbols, in function calls, etc. While some
looser restrictions might do for any particular Common Lisp implementation,
there seems to be no good way to distinguish between those symbols that are
redefinable and those that are not.
 
In general, programs can redefine functions safely by creating new symbols in
their own package, possibly shadowing the name.
 
Current practice:
 
Many Lisp environments have some mechanism for warning about redefinition of
Lisp symbols and preventing accidental redefinition while allowing it where
necessary (e.g., to patch the Lisp system itself, fix a bug, add an
optimization.)
 
Fewer check for lexical redefinition, since such redefinition is not as
dangerous. Certainly, there are some symbols that are never used in macro
expansions of the standard Common Lisp macros. However, implementations do
differ on the behavior of macro expansions.
 
Cost to Implementors:
 
This proposal clarifies the status quo -- that the consequences are undefined. It
allows and encourages implementors to check for such redefinition, but does not
require it.
 
Cost to Users:
 
This proposal clarifies that implementations are free to check for a condition
that they might not have before, and may clarify that some current user code is
non-portable.
 
Benefits:
 
This issue frequently arises. Adopting this proposal would clarify a frequent
source of question about Common Lisp. 
 
Cost of non-adoption:
 
Continued questions.
 
Esthetics:
 
Disallowing all redefinition is the simplest way of disallowing the ones that
really are trouble. 
 
Discussion:
 
There have been various proposals for allowing users to extend the "protection"
mechanism to their own macros, functions, packages. These proposals seem like
they are environment issues and not language ones, however. 
 
It is unfortunate that the restriction on reusing LISP package symbols in
FLET, LABELS or MACROLET is necessary, but the research into straightening out
the syntactic environment of macroexpansion isn't mature enough to put into
a standard yet.

∂13-Oct-88  1336	CL-Cleanup-mailer 	issue DEFPACKAGE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:35:47 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA18928; Thu, 13 Oct 88 14:34:08 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19839; Thu, 13 Oct 88 14:34:06 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132034.AA19839@defun.utah.edu>
Date: Thu, 13 Oct 88 14:34:04 MDT
Subject: issue DEFPACKAGE
To: cl-cleanup@sail.stanford.edu

A few minor complaints on this one.

A question was raised at the meeting about having macros signalling
errors during expansion at compile time.  Macro expansion time is the
obvious time for signalling a syntax error for an unrecognized option
and I think that should be made clear in the standard.  The compiler
committee is dealing with the issue of compile time errors and making
this particular error happen only at run-time won't get rid of the
more general problem.

I presume it's the intention of the proposal that the expansion of
DEFPACKAGE should be wrapped with an (EVAL-WHEN (EVAL COMPILE LOAD)
...).  An explicit statement of what you intend for the compiler to do
with DEFPACKAGE should either appear in this proposal, or be
communicated to the compiler committee so that we can put it in one of
our issues. 

I would also like to see more detail on the order that the various things
are supposed to happen in, in the expansion of the macro.  I'm guessing that
it's supposed to be the same as "Put In Seven Extremely Random ..." but
I think the description needs to be more explicit.
	
Finally, what is the motivation for not having DEFPACKAGE setq *PACKAGE*?

-Sandra
-------

∂13-Oct-88  1337	CL-Cleanup-mailer 	issue DEFSTRUCT-REDEFINITION   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:37:28 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA19000; Thu, 13 Oct 88 14:35:52 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19844; Thu, 13 Oct 88 14:35:50 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132035.AA19844@defun.utah.edu>
Date: Thu, 13 Oct 88 14:35:49 MDT
Subject: issue DEFSTRUCT-REDEFINITION
To: cl-cleanup@sail.stanford.edu

I would vote for either of the proposals given here, but I'd feel much
better about ERROR-IFF-OLD-USE.

-Sandra
-------

∂13-Oct-88  1339	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:39:18 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475827; Thu 13-Oct-88 16:37:55 EDT
Date: Thu, 13 Oct 88 16:37 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DYNAMIC-EXTENT (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013163747.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Issue names STACK-LET, DYNAMIC-VALUE, and DYNAMIC-VALUE-EXTENT
 are obsolete synonyms for this issue.

 This issue is related to, but very different than, issue
 WITH-DYNAMIC-EXTENT.

 KMP will write this up, removing the STACK-LET proposal in favor
 of something declaration-based.

X3J13 meeting:

 Masinter: This issue is related to the ISO proposal for multiple
  	   values and rest arguments.

 KMP: Perhaps this should be mentioned in Current Practice or Discussion
      of writeup.

∂13-Oct-88  1343	CL-Cleanup-mailer 	issue DOTTED-MACRO-FORMS  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:43:13 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA19231; Thu, 13 Oct 88 14:41:36 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19850; Thu, 13 Oct 88 14:41:32 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132041.AA19850@defun.utah.edu>
Date: Thu, 13 Oct 88 14:41:31 MDT
Subject: issue DOTTED-MACRO-FORMS
To: cl-cleanup@sail.stanford.edu

I had a hard time initially understanding this writeup because it
wasn't clear to me that "macro form" was being used to describe what I
would term a "macro call".  How about calling it "macro call form" or
something like that? 

The wording of the proposal suggests that (MACX . 1) is also supposed
to be an error, but the test case section says only that the other two
examples are in error.  Please clarify.

-Sandra
-------

∂13-Oct-88  1343	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 5)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:43:49 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475833; Thu 13-Oct-88 16:42:22 EDT
Date: Thu, 13 Oct 88 16:42 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EQUAL-STRUCTURE (Version 5)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013164213.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

X3J13 meeting:

 Sandra: Why not "fix" EQUALP?

 KMP: It's not fixable. Very brief discussion in writeup of why we
      didn't go with the other options might be appropriate to head
      off more questions like this at vote time.

 Masinter: Just to see how arbitrary the choice of equality operators
	   is, note that there is no overlap between any of the Interlisp 
	   equality operators and the Common Lisp ones!

 Beckerle: There would be an extremely high cost to making any change
	   to EQUALP. There would be lots of "sleeping" errors, for
	   which no error could be signalled -- programs would just
	   behave incorrectly in subtle ways.

 Someone (Slater?) asked why not add keyword arguments?

 KMP: Among other things, this would mean that EQUALP couldn't be
      a hash table predicate.

∂13-Oct-88  1345	CL-Cleanup-mailer 	Issue: PRINT-CIRCLE-STRUCTURE  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:45:27 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA19823; Thu, 13 Oct 88 13:43:44 PDT
Date: Thu, 13 Oct 88 13:43:44 PDT
Message-Id: <8810132043.AA19823@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: PRINT-CIRCLE-STRUCTURE

BTW, VAX LISP behaves as desired.

This reminds me of another issue which may deserve a cleanup issue:
*PRINT-CIRCLE* ought to say that the printer detects shared structure
as well as circularity.  The description of #n# and #n= does mention
referring to shared structures as well as circular ones, so it would
make sense that the printer should behave in this manner.

			---Walter

∂13-Oct-88  1346	CL-Cleanup-mailer 	EVAL-OTHER (Version 2)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:45:57 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475835; Thu 13-Oct-88 16:44:27 EDT
Date: Thu, 13 Oct 88 16:44 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: EVAL-OTHER (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013164418.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

X3J13 meeting:

 Haflich thought this made the language less regular and harder to learn.
 Virtually everyone in the room disagreed pretty strongly.

 This issue was voted upon and ACCEPTED.

∂13-Oct-88  1350	CL-Cleanup-mailer 	Issue: EXIT-EXTENT (Version 3) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:49:54 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475845; Thu 13-Oct-88 16:48:32 EDT
Date: Thu, 13 Oct 88 16:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXIT-EXTENT (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013164824.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Deferred for everyone to have time to study it more.

X3J13 meeting:

 RWK: Proposal is not readable.
      for example, but not exclusively, there's a phrase
      "when the value is returned" which is used where it isn't clear
      which of several times might be being referred to (before, during,
      or after).

 Sandra: Couldn't read the problem description.

 Barmar: Supports this proposal.

 Considerable concern among numerous people about relation of this to
 UNWIND-PROTECT-NON-LOCAL-EXIT and why the proposal accompanying that
 has no relation to the proposal accompanying this.

∂13-Oct-88  1351	CL-Cleanup-mailer 	Issue: EXPT-RATIO (Version 2)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:51:22 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475847; Thu 13-Oct-88 16:49:52 EDT
Date: Thu, 13 Oct 88 16:49 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXPT-RATIO (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013164944.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 GLS supports this proposal.

X3J13 meeting:

 Typo in problem description [Wrong number of arguments in some
 example of using SQRT, if I recall correctly. -kmp]

∂13-Oct-88  1353	CL-Cleanup-mailer 	Issue: FILE-LENGTH-PATHNAME (no proposal)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:53:38 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475853; Thu 13-Oct-88 16:52:18 EDT
Date: Thu, 13 Oct 88 16:52 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FILE-LENGTH-PATHNAME (no proposal)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013165210.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Some people didn't seem to think this was appropriate.
 No one seemed very interested in writing it up.

∂13-Oct-88  1354	CL-Cleanup-mailer 	issue EXIT-EXTENT    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:54:22 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA19676; Thu, 13 Oct 88 14:52:46 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19858; Thu, 13 Oct 88 14:52:43 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132052.AA19858@defun.utah.edu>
Date: Thu, 13 Oct 88 14:52:42 MDT
Subject: issue EXIT-EXTENT
To: cl-cleanup@sail.stanford.edu

I don't understand the "problem description" section of this proposal
well enough to comment on the remainder.  Specifically.... 

(1) I don't understand what the phrase "extent of an exit" means, or
what it means for the extent to end.  Could you put in a paragraph or
so at the beginning to explain this further? 

(2) Please give examples of each of the three situations.  I know there
are some in the test cases section, but those are all error situations.
Are there any non-error situations?

(3) If CLtL is unambiguous about case 1, please state how it resolves
the problem because it's not obvious to me.

If I'm having so much trouble understanding this, I really hate to think
of how confused naive readers of the standard are going to be.  

-Sandra
-------

∂13-Oct-88  1355	CL-Cleanup-mailer 	Issue: FILE-WRITE-DATE-IF-NOT-EXISTS (no proposal) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:54:54 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475856; Thu 13-Oct-88 16:53:32 EDT
Date: Thu, 13 Oct 88 16:53 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FILE-WRITE-DATE-IF-NOT-EXISTS (no proposal)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013165324.0.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 This should be handled under the auspices of a separate
 "error signalling committee".

X3J13 meeting:

 No attempt was made to form such a committee.

∂13-Oct-88  1357	CL-Cleanup-mailer 	issue FIXNUM-NON-PORTABLE 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:57:22 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA19761; Thu, 13 Oct 88 14:55:47 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19864; Thu, 13 Oct 88 14:55:45 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132055.AA19864@defun.utah.edu>
Date: Thu, 13 Oct 88 14:55:44 MDT
Subject: issue FIXNUM-NON-PORTABLE
To: cl-cleanup@sail.stanford.edu

I would really prefer to retain the part of the proposal that removes
the BIGNUM type specifier, but if there is a decision made that BIGNUM
should stay in the language I think it should also be clarified that 
BIGNUM == (AND INTEGER (NOT FIXNUM)).

-Sandra
-------

∂13-Oct-88  1358	CL-Cleanup-mailer 	Issue: FIXNUM-NON-PORTABLE (Version 3)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:58:30 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475869; Thu 13-Oct-88 16:57:10 EDT
Date: Thu, 13 Oct 88 16:57 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FIXNUM-NON-PORTABLE (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013165702.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 GLS: p14 and p34 disagree about bignums. One says that fixnum and bignums
      are an exhaustive partition of the integer space, the other says they
      might not be!

 KMP: Moon is "neutral" on flushing bignums, but supports rest of proposal.

 Not ready for vote.

X3J13 meeting:

 Barmar: Thinks change to bignums gratuitous.

 RWK: Let's just deprecate BIGNUM.

∂13-Oct-88  1359	CL-Cleanup-mailer 	Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  13:59:13 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475870; Thu 13-Oct-88 16:57:54 EDT
Date: Thu, 13 Oct 88 16:57 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013165746.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Ready for vote.

X3J13 meeting:

 No vote was taken.

∂13-Oct-88  1400	CL-Cleanup-mailer 	Issue: FORMAT-PRETTY-PRINT (Version 5)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  14:00:13 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475874; Thu 13-Oct-88 16:58:49 EDT
Date: Thu, 13 Oct 88 16:58 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-PRETTY-PRINT (Version 5)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013165841.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

X3J13 meeting:

 Haflich: Related issue: Which I/O functions can rebind -stream- vars.

∂13-Oct-88  1401	CL-Cleanup-mailer 	Issue: FUNCTION-CALL-EVALUATION-ORDER (Version 1)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  14:01:05 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475878; Thu 13-Oct-88 16:59:45 EDT
Date: Thu, 13 Oct 88 16:59 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-CALL-EVALUATION-ORDER (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013165936.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting:

Cleanup meeting:

 Ready to vote.

X3J13 meeting:

 This issue was voted upon and ACCEPTED.

∂13-Oct-88  1401	CL-Cleanup-mailer 	issue FUNCTION-COERCE-TIME
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  14:01:22 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA19846; Thu, 13 Oct 88 14:59:44 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19871; Thu, 13 Oct 88 14:59:42 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132059.AA19871@defun.utah.edu>
Date: Thu, 13 Oct 88 14:59:41 MDT
Subject: issue FUNCTION-COERCE-TIME
To: cl-cleanup@sail.stanford.edu

The writeup for the LAZY option should mention that this might cause a
substantial performance hit in some implementations.

Of the options presented, I prefer AMBITIOUS.  However, I would really
much rather see this whole issue left explicitly vague in the
standard.  If you'd like me to submit a proposal along those lines,
let me know.

-Sandra
-------

∂13-Oct-88  1401	CL-Cleanup-mailer 	Issue: ELIMINATE-FORCED-CONSING (Version 3)   
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 13 Oct 88  14:01:45 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 229507; Thu 13-Oct-88 16:33:15 EDT
Date: Thu, 13 Oct 88 16:33 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ELIMINATE-FORCED-CONSING (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013163306.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

X3J13 meeting:

 KMP: LOOP (or any iteration facility that makes idioms explicit)
      will help to address the same issue, making this less critical.

Side comment (not in any meeting):

 Masinter: Destructive and non-destructive versions of this are very
	   different, which makes things like inlining tough.

∂13-Oct-88  1405	CL-Cleanup-mailer 	Issue: FUNCTION-COERCE-TIME (Version 2)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  14:05:23 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 475890; 13 Oct 88 17:04:02 EDT
Date: Thu, 13 Oct 88 17:03 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-COERCE-TIME (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013170353.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Masinter: Eliminate the AMBITIOUS proposal. Continue to evolve the
	   HYBRID and LAZY variants.

 KMP: Relation to DEBUG quality.

 There was some discussion about the idea of permitting vagueness
 (ie, making LAZY/AMBITIOUS optional in some places).

 KMP will write next draft.

X3J13 meeting:

 JonL had some critical comments, but KMP couldn't understand them
 and believes it was because JonL didn't read the proposals carefully
 and was commenting on a superficial reading that led him to incorrect 
 conclusions.

 Some people weren't completely convinced that the HYBRID proposal
 would feel predictable enough. Others disagreed.

∂13-Oct-88  1410	CL-Cleanup-mailer 	Issue: FUNCTION-COMPOSITION (Version 2)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  14:10:18 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475898; Thu 13-Oct-88 17:08:46 EDT
Date: Thu, 13 Oct 88 17:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-COMPOSITION (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013170837.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 RPG opposed the proposal. Pitman asked if he could say why in just
 a couple of setences. RPG said "2 sentences? ok... I don't like it.
 I really don't."

 We decided to try to get a sense of X3J13 on this when it came up
 at the meeting...

X3J13 meeting:

 Greenblatt: If adopted, maybe use less "generic" names.

 JonL: Gratuitous.
       Also, no existing implementations have this.
       [He didn't seem willing to count the T language. -kmp]

 RPG: Ditto.

 Haflich: This woudl encourage good optimizations.

 Masinter: A no vote on this is not a vote against functional
 	   programming.

 KMP: That's nonsense. Of course it is. Passing this proposal would
      encourage a particular style of programming, and failing to
      pass it would (in the absence of other compensating proposals)
      discourage it.

∂13-Oct-88  1410	CL-Cleanup-mailer 	issue FUNCTION-COMPOSITION
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  14:10:48 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA20481; Thu, 13 Oct 88 15:09:11 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19879; Thu, 13 Oct 88 15:09:09 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132109.AA19879@defun.utah.edu>
Date: Thu, 13 Oct 88 15:09:08 MDT
Subject: issue FUNCTION-COMPOSITION
To: cl-cleanup@sail.stanford.edu

I tend to agree with the general sentiment expressed at the meeting that
this is an interesting concept but it's not appropriate for standardization
at this time, except for maybe the functions COMPLEMENT and ALWAYS.  I'd
vote for it if it only specified those two functions, against it otherwise.

If there is a serious effort made to push this idea in to the standard now,
I think it would also be appropriate to define MULTIPLE-VALUE-COMPOSE:

(funcall (multiple-value-compose #'f #'g #'h) a b c)

is the same as

(multiple-value-call #'f
    (multiple-value-call #'g
        (h a b c)))

-Sandra
-------

∂13-Oct-88  1414	CL-Cleanup-mailer 	issue FUNCTION-DEFINITION 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  14:14:04 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA20625; Thu, 13 Oct 88 15:12:27 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19884; Thu, 13 Oct 88 15:12:25 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132112.AA19884@defun.utah.edu>
Date: Thu, 13 Oct 88 15:12:24 MDT
Subject: issue FUNCTION-DEFINITION
To: cl-cleanup@sail.stanford.edu

I'd be willing to vote for proposal OPTIONAL as long as the name of the
function is changed to SOURCE-CODE (since it's my understanding that's
what both Lucid and VaxLisp call their functions that do this).

-Sandra
-------

∂13-Oct-88  1418	CL-Cleanup-mailer 	issue FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  14:18:36 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA20783; Thu, 13 Oct 88 15:17:01 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19892; Thu, 13 Oct 88 15:16:58 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132116.AA19892@defun.utah.edu>
Date: Thu, 13 Oct 88 15:16:57 MDT
Subject: issue FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
To: cl-cleanup@sail.stanford.edu

The writeup looks pretty good to me.  One thing I would like added is
something to emphasize that both this proposal and
FUNCTION-TYPE-REST-LIST-ELEMENT make FTYPE declarations describe calls
to the function, not the actual definition of the function.  It might
help to present a more coherent view of what an FTYPE declaration is.

As I've said elsewhere, I think that the nesting and scoping rules for
FTYPE declarations should be as close as possible to those for TYPE
declarations.

-Sandra
-------

∂13-Oct-88  1420	CL-Cleanup-mailer 	issue HASH-TABLE-ACCESS   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  14:20:02 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA20859; Thu, 13 Oct 88 15:18:24 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19898; Thu, 13 Oct 88 15:18:22 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132118.AA19898@defun.utah.edu>
Date: Thu, 13 Oct 88 15:18:21 MDT
Subject: issue HASH-TABLE-ACCESS
To: cl-cleanup@sail.stanford.edu

Adding accessors for hash tables seems like a reasonable idea to me,
but I don't like the idea of being able to SETF them.

-Sandra
-------

∂13-Oct-88  1428	CL-Cleanup-mailer 	issue HASH-TABLE-PRINTED-REPRESENTATION  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  14:27:50 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA21150; Thu, 13 Oct 88 15:26:02 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19904; Thu, 13 Oct 88 15:26:00 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132126.AA19904@defun.utah.edu>
Date: Thu, 13 Oct 88 15:25:59 MDT
Subject: issue HASH-TABLE-PRINTED-REPRESENTATION
To: cl-cleanup@sail.stanford.edu

I want to second the comments that have already been made at the
meeting, to the effect that the variable should be called *PRINT-HASH-TABLE*
and that there should be a corresponding :HASH-TABLE argument to WRITE.

I like the syntax suggested in what is described as "yet another proposal"
but the way it specifies the optional parts is broken.  It should be

#[size]H([type [rehash-size [rehash-threshold]]] (ki vi)*)

Finally, I agree that array printing is also broken and that it would be
a mistake to propagate the same problems to other types.

-Sandra
-------

∂13-Oct-88  1432	CL-Cleanup-mailer 	Issue: FUNCTION-DEFINITION (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  14:32:43 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475931; Thu 13-Oct-88 17:31:14 EDT
Date: Thu, 13 Oct 88 17:31 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-DEFINITION (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013173106.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 VAXLISP and Lucid have this function, but call it SOURCE-CODE.
 KMP agreed to name change.

X3J13 meeting:

 Beckerle: `Let 'em write hash tables.'

 Skona: This function would be very useful in teaching situations
	where people don't yet know about hash tables.

 KMP: Program modularity does not always permit the hash table
      solution. Also, the hash table solution has GC impact unless
      we have weak hash tables.

 Masinter: This would be an undue burden compiled-only implementations.

 KMP: Cloe is the only compiled-only implementation I can think of
      and doesn't consider it to be an undue burden as long as
      the info can be discarded by compile-file.

 van Roggen: VAXLISP now has several different kinds of evaluators,
	     and this might impact some of them. Wants to study issue
	     further.

 KMP thinks that some people seemed to have the mistaken belief
 that one of these proposals required source code info to files
 because they were worried about gratuitous bloating of dumped
 applications. Since both proposals only involve compile-to-core,
 they weren't nearly as wasteful of space as some seemed to believe.
 This needs to be made more apparent in the writeup.

∂13-Oct-88  1437	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  14:37:06 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475938; Thu 13-Oct-88 17:35:35 EDT
Date: Thu, 13 Oct 88 17:35 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013173527.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Walter was willing to write this up, but had had trouble
 with net access and was missing some mail. KMP will call him
 and provide the relevant information for him to do the writing.

 It seemed reasonable to write a proposal for two things:
  - FTYPE, which allowed a total specification of a function's
    possible arguments and values.
  - PTYPE which allowed a partial specification of same.
    Multiple PTYPE specs would presumably be ok, but multiple
    FTYPE would presumably not. Proposal should say what FTYPE
    does when a PTYPE has been seen already and vice versa.

∂13-Oct-88  1438	CL-Cleanup-mailer 	issue PACKAGE-CLUTTER
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  14:38:33 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA21463; Thu, 13 Oct 88 15:36:52 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19912; Thu, 13 Oct 88 15:36:50 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132136.AA19912@defun.utah.edu>
Date: Thu, 13 Oct 88 15:36:49 MDT
Subject: issue PACKAGE-CLUTTER
To: cl-cleanup@sail.stanford.edu

I generally like this proposal.  At the meeting I mentioned that I
thought the property lists were also a problem and Larry mentioned
that some extremely complicated-sounding wording to deal with the
problem could be added to the proposal.  Actually, I would be happy
with a simple statement that the implementation must not use any
keywords or external symbols in the Lisp package as indicators on the
property list of any symbol.  I don't care if the system puts things
on property lists behind my back, as long as it doesn't use indicators
that I might accidentally want to use myself.

-Sandra
-------

∂13-Oct-88  1450	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 4) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  14:50:03 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 475960; 13 Oct 88 17:48:26 EDT
Date: Thu, 13 Oct 88 17:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013174817.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

X3J13 meeting:

 RWK objects. Wants to see LIST-TYPE-SPECIFIER fleshed out.
 He was particularly interested in being able to type-declare
 things like &REST {keyword integer}*, but we realized later
 that the LIST-TYPE-SPECIFIER issue doesn't even pretend to
 get involved in repetition issues. Hmm...


∂13-Oct-88  1452	CL-Cleanup-mailer 	Issue: GC-MESSAGES (Version 1) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  14:52:33 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475966; Thu 13-Oct-88 17:51:03 EDT
Date: Thu, 13 Oct 88 17:50 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GC-MESSAGES (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013175055.0.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 KMP said he would do writeup.  Pierson and/or Sandra might also
 do their own. They wanted copies of the old mail on the subject.

X3J13 meeting:

 Skona wanted to know what relation is to *LOAD-VERBOSE*.
 Masinter insisted there was no relation because *LOAD-VERBOSE*
 addressed the level of verbosity of action you'd synchronously
 requested, while this issue relates to unsolicited messages.

∂13-Oct-88  1453	CL-Cleanup-mailer 	Issue: GET-MACRO-CHARACTER-READTABLE (no proposal) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  14:53:13 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 475969; Thu 13-Oct-88 17:51:50 EDT
Date: Thu, 13 Oct 88 17:51 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GET-MACRO-CHARACTER-READTABLE (no proposal)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013175142.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 JonL volunteered to write this up.

∂13-Oct-88  1456	CL-Cleanup-mailer 	issue IN-PACKAGE-FUNCTIONALITY 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  14:56:11 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA22083; Thu, 13 Oct 88 15:54:31 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19920; Thu, 13 Oct 88 15:54:24 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132154.AA19920@defun.utah.edu>
Date: Thu, 13 Oct 88 15:54:22 MDT
Subject: issue IN-PACKAGE-FUNCTIONALITY
To: cl-cleanup@sail.stanford.edu
Cc: cl-compiler@sail.stanford.edu

This proposal seems like a step in the right direction but I'm not 
entirely happy with it.

I'm speaking for myself here, and not the compiler committee, but I
think an alternate approach to this issue would simplify our work a
lot.  I would prefer to see the definition of IN-PACKAGE left alone,
the magic compiletime behavior of *all* of the random package
functions removed, and a new macro introduced to do what this proposal
wants IN-PACKAGE to do.  The reason for making it a macro instead of a
function is so that it can expand into an EVAL-WHEN to get the right
compiletime behavior instead of requiring the compiler to treat just
this one function specially.  The main problem I'm having is thinking
of what it should be called (since DEFPACKAGE is already being used
for another purpose).

I'm willing to do the writeup if you cleanup people who have been
handling the issue agree this is the right direction to proceed.  Let
me know. 

-Sandra
-------

∂13-Oct-88  1456	CL-Cleanup-mailer 	Issue: HASH-TABLE-GC (no proposal)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  14:56:31 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 475978; 13 Oct 88 17:54:56 EDT
Date: Thu, 13 Oct 88 17:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-GC (no proposal)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013175448.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 This issue is about the inordinately long discussion on Common-Lisp@SAIL
 about hash tables.

 Masinter said he would try to get Dalton to write up this issue as
 a proposal.

X3J13 meeting:

 KMP: There are several kinds of such hash tables. Those that are weak
      on key link, weak on value, and both.

 JonL, RWK: Nervous about this because it's "new technology".

 Gregor: It IS implemented -- just not in Lisp. It is NOT new technology.

∂13-Oct-88  1458	CL-Cleanup-mailer 	issue PACKAGE-DELETION    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  14:58:39 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA22334; Thu, 13 Oct 88 15:57:02 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19925; Thu, 13 Oct 88 15:56:59 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132156.AA19925@defun.utah.edu>
Date: Thu, 13 Oct 88 15:56:57 MDT
Subject: issue PACKAGE-DELETION
To: cl-cleanup@sail.stanford.edu

About the only complaint I have with this proposal is that I think it
ought to explicitly state whether the processing on the symbols in the
package is the same as uninterning them all.  It sounds kind of like it
is but I might have missed something.

-Sandra
-------

∂13-Oct-88  1519	CL-Cleanup-mailer 	Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 2)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:18:48 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476010; Thu 13-Oct-88 18:16:57 EDT
Date: Thu, 13 Oct 88 18:15 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013181527.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 JonL says he'll get Touretzky to do a writeup.

 Maybe expand to fix arrays for general case.

 Some people seemed to think there is some relation between this and
 a DUMP-FORMS facility. I think because you can print something with
 #. if you can figure out how to construct it. However, Touretzky had
 already indicated that grokking a #H expression is something a
 non-Lisp program might hope to do, while parsing a #. expression is 
 not -- so DUMP-FORMS is not the full answer. Still, such a facility
 might be a useful new topic to raise.

X3J13 meeting:

 JonL: One issue is that infinite printing might occur if circularities
       occur. [JonL said he doesn't believe this is reason not to do it,
       but he did want to raise the issue.]

 Haflich: Impact on #H in per-vendor extensions.

 Barmar: Need to modify the WRITE function to take a :PRINT-HASH argument.

 KMP: You mean :PRINT-HASH-TABLE. I want the variable called
      *PRINT-HASH-TABLE*, not *PRINT-HASH*.

 van Roggen: Not sure if it's possible to print enough information to
	     make re-reading the expression really construct an
	     equivalent object.

 GLS: The same could be said about other print representations, too, but
      there is at least a well-defined theory of how much you can expect
      out of print/read.

 van Roggen's position seemed to be that we might just want to provide
 *PRINT-HASH-TABLE* but not specify how the thing actually gets printed
 so it's not thought to be portable.

 I (KMP) made a note to myself that since #S(ARRAY ...) and 
 #S(HASH-TABLE ...) couldn't possibly be meaningful, one might define
 #S to be the generalized constructor for things other than structures.
 So #S(ARRAY ...) could be used to print arrays with attributes that
 would otherwise be lost. eg, #S(ARRAY :CONTENTS ... :FILL-POINTER ...).
 Similarly, #S(HASH-TABLE :CONTENTS ... :SIZE ...) for the cases where
 hairy options wanted to be shown. #A and the simpler #H notation could
 then be used unless some option variable were set that said to really
 print the full-blown info.

∂13-Oct-88  1519	CL-Cleanup-mailer 	issue HASH-TABLE-PRINTED-REPRESENTATION  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:19:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476009; Thu 13-Oct-88 18:15:20 EDT
Date: Thu, 13 Oct 88 18:15 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue HASH-TABLE-PRINTED-REPRESENTATION
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8810132126.AA19904@defun.utah.edu>
Message-ID: <19881013221502.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 13 Oct 88 15:25:59 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    I like the syntax suggested in what is described as "yet another proposal"
    but the way it specifies the optional parts is broken.  It should be

    #[size]H([type [rehash-size [rehash-threshold]]] (ki vi)*)

It is very important that the syntax for expressing hash table options
be extensible, and therefore keyword-based.  Any syntax like this that's
positional, and furthermore assumes that all option values are
non-lists, is simply not acceptable.  Putting the size out there in
front is weird, too.

I still don't see why #. can't be used, but that's a minor point.

∂13-Oct-88  1521	CL-Cleanup-mailer 	Issue: HASH-TABLE-TESTS (Version 1) 
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:20:58 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 287723; Thu 13-Oct-88 18:19:10 EDT
Date: Thu, 13 Oct 88 18:19 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-TESTS (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013181904.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

X3J13 meeting:

 Barmar: Will the CONTAGION-ON-NUMERICAL-COMPARISON issue make = useable
	 as a hash table key? [Some people said he could use EQUALP, but
	 all agreed that that wouldn't be as perspicuous.]

 Jonl: Hmmm, STRING= could be permitted, too.

 There was discussion of extending this proposal. People were mixed in their
 feelings about whether it was advisable to do that.

∂13-Oct-88  1522	CL-Cleanup-mailer 	Issue: HASH-TABLE-TESTS (Version 1) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:21:52 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476014; Thu 13-Oct-88 18:20:27 EDT
Date: Thu, 13 Oct 88 18:20 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-TESTS (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Supersedes: <881013181904.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <881013182017.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

[One comment was left out of previous version of this message.]

My notes from Fairfax meeting...

X3J13 meeting:

 Barmar: Will the CONTAGION-ON-NUMERICAL-COMPARISON issue make = useable
	 as a hash table key? [Some people said he could use EQUALP, but
	 all agreed that that wouldn't be as perspicuous.]

 JonL: Hmmm, STRING= could be permitted, too.

 There was discussion of extending this proposal. People were mixed in their
 feelings about whether it was advisable to do that.

 JonL made some comment about how CLtL was ambiguous about what hash on EQ
 meant, but neither I (KMP) nor anyone sitting near me could figure out
 what he meant by this.

∂13-Oct-88  1523	CL-Cleanup-mailer 	Issue: IN-PACKAGE-FUNCTIONALITY (Version 2)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:23:30 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476022; Thu 13-Oct-88 18:21:56 EDT
Date: Thu, 13 Oct 88 18:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: IN-PACKAGE-FUNCTIONALITY (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013182144.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from the Fairfax meeting...

Cleanup meeting:

 Ready for vote if DEFPACKAGE passes.

X3J13 meeting:

 RWK: Compatibility reservations.

 A number of people seemed to want to drop the last sentence of the proposal
 and raise it as a separate issue.

∂13-Oct-88  1526	CL-Cleanup-mailer 	Issue: LAMBDA-FORM (Version 3) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:26:02 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476029; Thu 13-Oct-88 18:24:26 EDT
Date: Thu, 13 Oct 88 18:24 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAMBDA-FORM (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013182415.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

X3J13 meeting:

 Masinter: Another motivation is that once LISP-SYMBOL-REDEFINITION passes,
	   people won't be able to write a LAMBDA macro portably.

 RWK: Issue should say why a special form was ultimately not proposed.

 RG: With this proposal, will LAMBDA be a flag, form, macro, ...? The issue
     adds confusion on this point, complicating the language where it was
     once simple.

∂13-Oct-88  1526	CL-Cleanup-mailer 	issue PROCLAIM-LEXICAL    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:25:41 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA26040; Thu, 13 Oct 88 16:23:54 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19945; Thu, 13 Oct 88 16:23:52 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132223.AA19945@defun.utah.edu>
Date: Thu, 13 Oct 88 16:23:50 MDT
Subject: issue PROCLAIM-LEXICAL
To: cl-cleanup@sail.stanford.edu

I don't really like proposal LG very much.  I gather from the discussion
that there was also a proposal LDG around at one time?  

This issue appears to be addressing what I consider to be actually two
separate problems.  The first problem is a way to undo SPECIAL
declarations.  Wasn't there once a proposal for an UNSPECIAL
declaration to deal with this? 

The second problem is a way to specify a "global lexical variable".
To me that implies something very much like what is specified for the
binding behavior of DEFCONSTANT (it specifies a separate set of
restrictions on SETQ'ing).  I've thought for a long time that Common
Lisp ought to provide a declaration for variable binding corresponding
to what DEFCONSTANT does.  Why not assign that meaning to the LEXICAL
declaration, or maybe call it GLOBAL if people object to using
LEXICAL?  (The behavior of DEFCONSTANT is actually pretty close to
what "GLOBAL" variables in PSL were like.) I suppose people would want
an UNGLOBAL too.... 

The thing about proposal LG that strikes me as being the most
confusing to users and troublesome to implementors is allowing access
to both the dynamic and global value of the same variable.  I think it
would be reasonable to make the two mutually exclusive. 

Finally, a comment on the existing writeup.  Given all the different
proposals on the interpretation of declarations that are floating
around, I had a hard time understanding the second example.  It would
be nice if the writeup stated which rules are being used.

-Sandra
-------

∂13-Oct-88  1532	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION (Version 3)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:32:38 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 476038; 13 Oct 88 18:30:38 EDT
Date: Thu, 13 Oct 88 18:30 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LISP-SYMBOL-REDEFINITION (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013183025.0.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Needs to be discussed concurrently with PACKAGE-CLUTTER since they
 are pretty closely related.

 Thought ready to vote.

X3J13 meeting:

 Perdue: Concern about not being able to TRACE functions in LISP.

 Masinter: It's already a dangerous thing to do. 

 KMP: Just noticed that proposal should say "undefined", -not- "unspecified".

 Haflich: Proposal should say if it's ok for users to redefine symbols
	  that CLtL doesn't define. PACKAGE-CLUTTER suggests that the
	  system can't provide a LAMBDA definition, but this proposal
	  should say whether users can create such a definition.

 Slater: Can you shadow CAR? [in the package sense]

 Masinter: Of course.

 JonL: The term "shadow" is used ambiguously. Don't talk about shadowing
       using FLET because it leads to confusion.

 No vote was attempted.

∂13-Oct-88  1536	CL-Cleanup-mailer 	Issue: LIST-TYPE-SPECIFIER (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:36:14 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476042; Thu 13-Oct-88 18:33:50 EDT
Date: Thu, 13 Oct 88 18:33 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LIST-TYPE-SPECIFIER (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013183340.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Needs work.

 Masinter sees two orthogonal issues: functionality to provide, names to use.

 To be returned to author (Beckerle) for re-draft.
 [I expect Masinter to take care of the reminding. -kmp]

X3J13 meeting:

 Beckerle: The idea was to have a way of using lists like record structures --
   	   structures with a fixed number of slots with known types.

 RWK: Related to FUNCTION-TYPE-REST-LIST-ELEMENT.

∂13-Oct-88  1537	CL-Cleanup-mailer 	issue REQUIRE-PATHNAME-DEFAULTS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:37:43 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA26464; Thu, 13 Oct 88 16:36:03 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19961; Thu, 13 Oct 88 16:36:01 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132236.AA19961@defun.utah.edu>
Date: Thu, 13 Oct 88 16:36:00 MDT
Subject: issue REQUIRE-PATHNAME-DEFAULTS
To: cl-cleanup@sail.stanford.edu

Again, I agree with the general direction here.  I approve of the
decision to remove the part about mangling LOAD.

I'd like the description of REQUIRE changed to make it more clear that
it's the responsibility of the user, not REQUIRE, to load files after
the correctible error is signalled.  How about replacing the last
sentence with:

    This gives the user the opportunity to load the appropriate files
    from the debugger before continuing.

The "Rationale" section should include some mention of the motivation
for not requiring REQUIRE not to use *MODULES*.

-Sandra
-------

∂13-Oct-88  1538	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (Version 2)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:38:21 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476048; Thu 13-Oct-88 18:36:41 EDT
Date: Thu, 13 Oct 88 18:36 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MAKE-PACKAGE-USE-DEFAULT (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013183624.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 I (KMP) don't like this proposal, but I made a note to myself about another
 reason that just occurred to me:  There is no syntax for getting the default
 (ie, system-dependent) package included if you want to -also- use some other
 package.

 We didn't think this was ready to vote on.

∂13-Oct-88  1539	CL-Cleanup-mailer 	Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 2) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:39:20 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476049; Thu 13-Oct-88 18:37:28 EDT
Date: Thu, 13 Oct 88 18:37 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013183716.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 People seemed to think this was ready for vote.

∂13-Oct-88  1542	CL-Cleanup-mailer 	Issue: NTH-VALUE (Version 3)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:42:47 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476052; Thu 13-Oct-88 18:40:33 EDT
Date: Thu, 13 Oct 88 18:40 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: NTH-VALUE (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013184023.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Thought to be ready to vote.

X3J13 meeting:

 JonL: Trivial, gratuitous.

 RWK: Not trivial -- allows index computation. Hard to do this
      in a portable, efficient way.

 Allard: Says he has an NTH-VALUE macro for a portable system that he
	 uses (which exploits the computed index feature) and that it's
	 a gross kludge on Lucid in order to make it efficient.

 KMP: Also, in principle, an implementation could make this more
      efficient than the alternatives.

∂13-Oct-88  1550	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 4)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:50:33 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476075; Thu 13-Oct-88 18:49:02 EDT
Date: Thu, 13 Oct 88 18:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-CLUTTER (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013184853.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

X3J13 meeting:

 Haflich had a comment about IMPORT that I didn't understand.

 Sandra: Good but doesn't go far enough. It should also say that
	 LISPxLISP properties were not ok -- ie, that you could
 	 have implementations with initial properties on LISP
	 symbols only if indicators were non-LISP symbols, and
	 symbols with LISP indicators if those symbols were
	 not on LISP.

 JonL: Clarify relation to LISP-SYMBOL-REDEFINITION. In particular,
       users -should- be permitted to put LISP-package properties
       on other LISP symbols, mostly for interactive convenience.
       The practice might be discouraged in production-quality
       systems for reasons of modularity hygiene but LISP shouldn't
       complain if it occurs.

∂13-Oct-88  1551	CL-Cleanup-mailer 	Issue: PACKAGE-DELETION (Version 4) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:51:08 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476076; Thu 13-Oct-88 18:49:45 EDT
Date: Thu, 13 Oct 88 18:49 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-DELETION (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013184936.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 We felt this was ready for vote.

∂13-Oct-88  1553	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; 13 Oct 88  15:53:11 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476081; Thu 13-Oct-88 18:51:50 EDT
Date: Thu, 13 Oct 88 18:51 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013185141.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 We thought this was ready to vote.

∂13-Oct-88  1553	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (Version 2)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:53:48 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476082; Thu 13-Oct-88 18:52:23 EDT
Date: Thu, 13 Oct 88 18:52 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013185213.0.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 We thought this was ready to vote.

∂13-Oct-88  1555	CL-Cleanup-mailer 	Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:55:43 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476086; Thu 13-Oct-88 18:54:15 EDT
Date: Thu, 13 Oct 88 18:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013185407.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 This issue looks ready for vote.

X3J13 meeting:

 RWK: Check spelling of plurals of "echo" and "unecho".

 Masinter: Draft 1 date in edit history is probably wrong.

∂13-Oct-88  1557	CL-Cleanup-mailer 	issue HASH-TABLE-PRINTED-REPRESENTATION  
Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:57:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 398232; Thu 13-Oct-88 18:18:18 EDT
Date: Thu, 13 Oct 88 18:15 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue HASH-TABLE-PRINTED-REPRESENTATION
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8810132126.AA19904@defun.utah.edu>
Message-ID: <19881013221502.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 13 Oct 88 15:25:59 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    I like the syntax suggested in what is described as "yet another proposal"
    but the way it specifies the optional parts is broken.  It should be

    #[size]H([type [rehash-size [rehash-threshold]]] (ki vi)*)

It is very important that the syntax for expressing hash table options
be extensible, and therefore keyword-based.  Any syntax like this that's
positional, and furthermore assumes that all option values are
non-lists, is simply not acceptable.  Putting the size out there in
front is weird, too.

I still don't see why #. can't be used, but that's a minor point.

∂13-Oct-88  1600	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 8) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  16:00:35 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476091; Thu 13-Oct-88 18:57:58 EDT
Date: Thu, 13 Oct 88 18:57 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL (Version 8)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013185748.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 KMP will be responsible for writing or acquiring new draft.

X3J13 meeting:

 Masinter: Not ready for vote, but comments solicited.

 JonL: Would the presence of UNSPECIAL declaration help?

 KMP: No. UNSPECIAL doesn't address the original issue of closing
      over these global variables.

 JonL hadn't studied this enough and had a bunch of questions.
 Maybe we'll get more feedback from him when he's read it more carefully.

Offline:

 Julian Padgett (I probably got the spelling wrong) said he
 supports the LG proposal. He doesn't like the D stuff getting
 mixed up in there at all.

∂13-Oct-88  1806	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 2)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:04:34 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476102; Thu 13-Oct-88 19:03:55 EDT
Date: Thu, 13 Oct 88 19:03 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013190346.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 KMP will either do next writeup or find someone to do it.

X3J13 meeting:

 KMP: Kathy was looking for examples of things for which it was
      an error but it was not possible to always signal an error
      even in the safest mode. This is an example.

∂13-Oct-88  1807	CL-Cleanup-mailer 	Issue: SUBTYPEP-TOO-VAGUE (Version 4)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:06:54 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476143; Thu 13-Oct-88 19:28:23 EDT
Date: Thu, 13 Oct 88 19:28 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SUBTYPEP-TOO-VAGUE (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013192815.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 For as far as it goes, it was thought ready to vote.
 Some felt we might need further restrictions (other proposals) later.

X3J13 meeting:

 JonL: Thinks EB can prove that only SATISFIES mucks things up and
       that OR, AND, etc. are safe.

 RWK: It couldn't be. You'd need more type cleanups before it could be.

 People generally doubted JonL's claim but said he was of course welcome
 to submit the proof.

∂13-Oct-88  1807	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 5) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:06:28 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476139; Thu 13-Oct-88 19:25:50 EDT
Date: Thu, 13 Oct 88 19:25 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-INFO (Version 5)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013192542.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Masinter: Printer scaling points to allowing non-integers.
	   Eg, you might want to say make my output 12% bigger, and there
	   might be no easy way to come up with a good set of units on the
	   fly without considerably complicated understanding of how the
	   device will deal with that request. Should maybe even allow floats
	   (ie, non-negative, non-complex numbers).

 Masinter said he'd return the issue to Waters for rewrite.

X3J13 meeting:

 Interacts with Character Proposal.

 RWK: Want less generic names. eg, maybe STREAM-xxx.

∂13-Oct-88  1808	CL-Cleanup-mailer 	Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 5)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:07:54 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476149; Thu 13-Oct-88 19:36:54 EDT
Date: Thu, 13 Oct 88 19:36 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 5)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013193646.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

X3J13 meeting:

 This issue was voted upon and ACCEPTED.

∂13-Oct-88  1819	CL-Cleanup-mailer 	Re:  issue IN-PACKAGE-FUNCTIONALITY 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:19:18 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA29837; Thu, 13 Oct 88 17:40:45 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA20008; Thu, 13 Oct 88 17:40:42 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132340.AA20008@defun.utah.edu>
Date: Thu, 13 Oct 88 17:40:41 MDT
Subject: Re:  issue IN-PACKAGE-FUNCTIONALITY
To: cperdue@sun.com (Cris Perdue)
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: cperdue@Sun.COM (Cris Perdue), Thu, 13 Oct 88 16:00:42 PDT

I'm well aware that removing the magical behavior of the package
functions is an incompatible change to the language and would have a
considerable impact on users.  I think the impact would be less than
that of the current proposal, though.  (It not only removes the
magical behavior of all of the other package functions, it changes
IN-PACKAGE in a way that does not allow implementations to maintain
the status quo as a compatible extension -- things that are currently
legal and common practice would be required to cause an error to be
signalled.)

My intention was not to prohibit implementations from treating the
package functions magically as an extension.  I expect that most would
wish to do so.  In fact, I was even considering continuing to require
them to do so, provided that the standard makes it clear that the use
of IN-PACKAGE and friends for declaring a package is considered
obsolete, that the magic behavior is provided only for compatibility
reasons and may be removed in future versions of the standard, and
that the "right" way to get the desired behavior is described.  An
alternate approach might be define the magical behavior as a standard
feature.

It would be really nice if we could decide on a standard policy for
handling obsolete "features" of the language, because this issue would
certainly fall into that category. 

-Sandra
-------

∂13-Oct-88  1820	CL-Cleanup-mailer 	issue TAILP-NIL 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:19:58 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA27775; Thu, 13 Oct 88 17:10:51 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19983; Thu, 13 Oct 88 17:10:49 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132310.AA19983@defun.utah.edu>
Date: Thu, 13 Oct 88 17:10:47 MDT
Subject: issue TAILP-NIL
To: cl-cleanup@sail.stanford.edu

I support proposal TAILP-NIL:T.

-Sandra
-------

∂13-Oct-88  1908	CL-Cleanup-mailer 	Re:  issue IN-PACKAGE-FUNCTIONALITY 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:19:18 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA29837; Thu, 13 Oct 88 17:40:45 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA20008; Thu, 13 Oct 88 17:40:42 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132340.AA20008@defun.utah.edu>
Date: Thu, 13 Oct 88 17:40:41 MDT
Subject: Re:  issue IN-PACKAGE-FUNCTIONALITY
To: cperdue@sun.com (Cris Perdue)
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: cperdue@Sun.COM (Cris Perdue), Thu, 13 Oct 88 16:00:42 PDT

I'm well aware that removing the magical behavior of the package
functions is an incompatible change to the language and would have a
considerable impact on users.  I think the impact would be less than
that of the current proposal, though.  (It not only removes the
magical behavior of all of the other package functions, it changes
IN-PACKAGE in a way that does not allow implementations to maintain
the status quo as a compatible extension -- things that are currently
legal and common practice would be required to cause an error to be
signalled.)

My intention was not to prohibit implementations from treating the
package functions magically as an extension.  I expect that most would
wish to do so.  In fact, I was even considering continuing to require
them to do so, provided that the standard makes it clear that the use
of IN-PACKAGE and friends for declaring a package is considered
obsolete, that the magic behavior is provided only for compatibility
reasons and may be removed in future versions of the standard, and
that the "right" way to get the desired behavior is described.  An
alternate approach might be define the magical behavior as a standard
feature.

It would be really nice if we could decide on a standard policy for
handling obsolete "features" of the language, because this issue would
certainly fall into that category. 

-Sandra
-------

∂13-Oct-88  1909	CL-Cleanup-mailer 	Issue: RETURN-VALUES-UNSPECIFIED (Version 4)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:05:07 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476111; Thu 13-Oct-88 19:11:14 EDT
Date: Thu, 13 Oct 88 19:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: RETURN-VALUES-UNSPECIFIED (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013191106.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Thought ready for vote.

X3J13 meeting:

 Barmar: Wants to leave some of these unspecified.

 KMP: That just causes portability problems. Don't want to leave it
      unspecified -unless- someone can cite a reason to do so.

 JonL: People doing things like (AND (PRINT X) (PRINT Y)) need
       return values specified. [KMP choked at this thought.]

 Haflich: If many weren't defined, maybe we should leave 'em, but
	  since nearly all -are- defined, let's just go ahead and
	  round out the set.

 Skona: Most text books she's seen show CLOSE returning NIL.
	One text book shows it returning T.
	Since some people like to think of T as success and NIL
	as failure, maybe it should always return T.
        [There was some ensuing discussion of whether it could
	 ever return NIL since it signals an error in that case.]

 People seemed to think CLOSE should probably return T.

 No vote was attempted.

∂13-Oct-88  1912	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 2)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:05:07 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476107; Thu 13-Oct-88 19:06:36 EDT
Date: Thu, 13 Oct 88 19:06 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013190628.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 It was thought we should divide this into two issues: What does it do
 (signals an error, doesn't try to load) and where should it go in the
 file (relation to load, other environment issues).

X3J13 meeting:

 Masinter: Maybe we should note that it might be extended on a per-implementation
	   basis to offer arguments saying how to load for implementations
	   that want to offer such.

 I (KMP) made a note to myself about the fact that we shouldn't encourage
 people to add optional arguments to things -- maybe we should have a policy
 that vendor extensions to arguments must be by keyword to help avoid 
 and/or detect portability conflicts.

∂13-Oct-88  1917	CL-Cleanup-mailer 	Issue: HASH-TABLE-ACCESS (version 2)
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Oct 88  19:17:04 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA21938@EDDIE.MIT.EDU>; Thu, 13 Oct 88 22:15:55 EDT
Received: by spt.entity.com (smail2.5); 13 Oct 88 21:09:35 EDT (Thu)
To: vanroggen%aitg.DEC@decwrl.dec.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: vanroggen%aitg.DEC@decwrl.dec.com's message of Thu, 13 Oct 88 12:30:44 PDT <8810131930.AA15360@decwrl.dec.com>
Subject: Issue: HASH-TABLE-ACCESS (version 2)
Message-Id: <8810132109.AA01858@spt.entity.com>
Date: 13 Oct 88 21:09:35 EDT (Thu)
From: gz@spt.entity.com (Gail Zacharias)

   Date: Thu, 13 Oct 88 12:30:44 PDT
   From: vanroggen%aitg.DEC@decwrl.dec.com

     HASH-TABLE-REHASH-SIZE hash-table
       Returns the current rehash size of a hash table.
     HASH-TABLE-REHASH-THRESHOLD hash-table
       Returns the current rehash threshold of a hash table.
     HASH-TABLE-SIZE hash-table
       Returns the current size of a hash table.

I don't think the "current" values of these are well defined except in
reference to one particular implementation technique (I believe the
corresponding arguments to make-hash-table are advisory in nature and can be
ignored when not applicable).  For instance, can you describe what an
implementation using alists should return from each of these functions?

I do support the addition of HASH-TABLE-TEST.

∂13-Oct-88  1920	CL-Cleanup-mailer 	issue TEST-NOT-IF-NOT
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  19:20:00 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA27987; Thu, 13 Oct 88 17:15:51 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19995; Thu, 13 Oct 88 17:15:48 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132315.AA19995@defun.utah.edu>
Date: Thu, 13 Oct 88 17:15:47 MDT
Subject: issue TEST-NOT-IF-NOT
To: cl-cleanup@sail.stanford.edu

I would vote for the FLUSH-TEST-NOT option if the COMPLEMENT function
were added to the language in its place.  I think that FLUSH-ALL would
have been a terrific idea 5 years ago but doing it now would cause too
many problems for existing code.  I expect that even if FLUSH-TEST-NOT
passes, many implementations would continue to provide the :TEST-NOT
arguments anyway to support existing applications.

-Sandra
-------

∂13-Oct-88  1927	CL-Cleanup-mailer 	Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:07:06 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476145; Thu 13-Oct-88 19:29:36 EDT
Date: Thu, 13 Oct 88 19:29 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: CL-Compiler@SAIL.Stanford.EDU
Message-ID: <881013192927.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

At Fairfax, we agreed that further discussion on this issue should take
place on CL-Compiler only to help reduce the load on CL-Cleanup.

∂13-Oct-88  1929	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 5) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:06:28 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476139; Thu 13-Oct-88 19:25:50 EDT
Date: Thu, 13 Oct 88 19:25 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-INFO (Version 5)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013192542.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Masinter: Printer scaling points to allowing non-integers.
	   Eg, you might want to say make my output 12% bigger, and there
	   might be no easy way to come up with a good set of units on the
	   fly without considerably complicated understanding of how the
	   device will deal with that request. Should maybe even allow floats
	   (ie, non-negative, non-complex numbers).

 Masinter said he'd return the issue to Waters for rewrite.

X3J13 meeting:

 Interacts with Character Proposal.

 RWK: Want less generic names. eg, maybe STREAM-xxx.

∂13-Oct-88  1935	CL-Cleanup-mailer 	Issue: STREAM-ACCESS (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:06:21 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476132; Thu 13-Oct-88 19:22:57 EDT
Date: Thu, 13 Oct 88 19:22 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-ACCESS (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013192249.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Thought to be ready for vote.

X3J13 meeting:

 RWK: Don't like all the -P functions for the new types.

 Someone said he wanted us to mention (which we apparently forgot)
 that these types are subtypes of STREAM.

 There were some people who wanted only the -P functions and not
 the types.

 A straw poll was taken to see if people wanted TYPES & -P FNS,
 just TYPES, or just -P FNS. Alas, I didn't record the outcome
 of this vote, though there were definitely people in all three
 camps. I think we said we'd put all three options on the letter
 ballot.

∂13-Oct-88  1940	CL-Cleanup-mailer 	Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 5)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:07:54 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476149; Thu 13-Oct-88 19:36:54 EDT
Date: Thu, 13 Oct 88 19:36 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 5)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013193646.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

X3J13 meeting:

 This issue was voted upon and ACCEPTED.

∂13-Oct-88  1943	CL-Cleanup-mailer 	issue SYMBOL-MACROLET-SEMANTICS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  19:43:22 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA27682; Thu, 13 Oct 88 17:09:04 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19978; Thu, 13 Oct 88 17:08:59 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132308.AA19978@defun.utah.edu>
Date: Thu, 13 Oct 88 17:08:55 MDT
Subject: issue SYMBOL-MACROLET-SEMANTICS
To: cl-cleanup@sail.stanford.edu

This seems like a reasonable thing to do here.  The only serious
problem I see is that the description of SYMBOL-MACROLET in the CLOS
document says that it changes SETQ's of the symbols in the body to
SETF's during macro expansion.  Now that you are proposing that
SYMBOL-MACROLET won't be a macro any more, I think you have to specify
a change in the behavior of SETQ as well as SETF.  It seems like they
would have to be pretty much the same now, right?

I am a bit concerned about how this proposal interacts with the SETF
processing model specified in issue SETF-FUNCTION-VS-MACRO -- with the
description of SETF being distributed in several places, something
might get overlooked in the final standards document. 

Another thing is that I really don't like the name SYMBOL-MACROLET and
as long as you are proposing to make it a special form, you might as
well try to change the name to something nicer at the same time.  For
one thing, it might be confusing because the "bodies" of the macros
are substituted directly in one case and evaluated in another.  If
compatibility is a problem implementations could keep SYMBOL-MACROLET
defined as a macro.

-Sandra
-------

∂13-Oct-88  1943	CL-Cleanup-mailer 	issue TAILP-NIL 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:19:58 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA27775; Thu, 13 Oct 88 17:10:51 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19983; Thu, 13 Oct 88 17:10:49 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132310.AA19983@defun.utah.edu>
Date: Thu, 13 Oct 88 17:10:47 MDT
Subject: issue TAILP-NIL
To: cl-cleanup@sail.stanford.edu

I support proposal TAILP-NIL:T.

-Sandra
-------

∂13-Oct-88  1943	CL-Cleanup-mailer 	issue UNREAD-CHAR-AFTER-PEEK-CHAR   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:20:35 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA28113; Thu, 13 Oct 88 17:17:32 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA20000; Thu, 13 Oct 88 17:17:30 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810132317.AA20000@defun.utah.edu>
Date: Thu, 13 Oct 88 17:17:29 MDT
Subject: issue UNREAD-CHAR-AFTER-PEEK-CHAR
To: cl-cleanup@sail.stanford.edu

I agree with the stuff in the discussion section -- the basic idea is
right but the wording has got to be fixed.

-Sandra
-------

∂13-Oct-88  1940	CL-Compiler-mailer 	Re:  issue IN-PACKAGE-FUNCTIONALITY
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:18:59 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA25997; Thu, 13 Oct 88 15:57:11 PDT
Received: from clam.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA24377; Thu, 13 Oct 88 16:00:04 PDT
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA12671; Thu, 13 Oct 88 16:00:42 PDT
Date: Thu, 13 Oct 88 16:00:42 PDT
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8810132300.AA12671@clam.sun.com>
To: cl-cleanup@sail.stanford.edu, sandra%defun@cs.utah.edu
Subject: Re:  issue IN-PACKAGE-FUNCTIONALITY
Cc: cl-compiler@sail.stanford.edu

From what I have personally seen, removing the "magic compiletime
behavior of the random package functions" would break the majority
of all programs written in Sun Common Lisp.  Since it is unnecessary,
surely this must be a bad idea.

				-Cris

∂13-Oct-88  1804	CL-Cleanup-mailer 	Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:55:43 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476086; Thu 13-Oct-88 18:54:15 EDT
Date: Thu, 13 Oct 88 18:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013185407.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 This issue looks ready for vote.

X3J13 meeting:

 RWK: Check spelling of plurals of "echo" and "unecho".

 Masinter: Draft 1 date in edit history is probably wrong.

∂13-Oct-88  1804	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (Version 2)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:53:48 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476082; Thu 13-Oct-88 18:52:23 EDT
Date: Thu, 13 Oct 88 18:52 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013185213.0.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 We thought this was ready to vote.

∂13-Oct-88  1804	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; 13 Oct 88  15:53:11 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476081; Thu 13-Oct-88 18:51:50 EDT
Date: Thu, 13 Oct 88 18:51 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013185141.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 We thought this was ready to vote.

∂13-Oct-88  1804	CL-Cleanup-mailer 	issue HASH-TABLE-PRINTED-REPRESENTATION  
Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:57:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 398232; Thu 13-Oct-88 18:18:18 EDT
Date: Thu, 13 Oct 88 18:15 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue HASH-TABLE-PRINTED-REPRESENTATION
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8810132126.AA19904@defun.utah.edu>
Message-ID: <19881013221502.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 13 Oct 88 15:25:59 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    I like the syntax suggested in what is described as "yet another proposal"
    but the way it specifies the optional parts is broken.  It should be

    #[size]H([type [rehash-size [rehash-threshold]]] (ki vi)*)

It is very important that the syntax for expressing hash table options
be extensible, and therefore keyword-based.  Any syntax like this that's
positional, and furthermore assumes that all option values are
non-lists, is simply not acceptable.  Putting the size out there in
front is weird, too.

I still don't see why #. can't be used, but that's a minor point.

∂13-Oct-88  1804	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 4)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:50:33 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476075; Thu 13-Oct-88 18:49:02 EDT
Date: Thu, 13 Oct 88 18:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-CLUTTER (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013184853.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

X3J13 meeting:

 Haflich had a comment about IMPORT that I didn't understand.

 Sandra: Good but doesn't go far enough. It should also say that
	 LISPxLISP properties were not ok -- ie, that you could
 	 have implementations with initial properties on LISP
	 symbols only if indicators were non-LISP symbols, and
	 symbols with LISP indicators if those symbols were
	 not on LISP.

 JonL: Clarify relation to LISP-SYMBOL-REDEFINITION. In particular,
       users -should- be permitted to put LISP-package properties
       on other LISP symbols, mostly for interactive convenience.
       The practice might be discouraged in production-quality
       systems for reasons of modularity hygiene but LISP shouldn't
       complain if it occurs.

∂13-Oct-88  1804	CL-Cleanup-mailer 	Issue: PACKAGE-DELETION (Version 4) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  15:51:08 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476076; Thu 13-Oct-88 18:49:45 EDT
Date: Thu, 13 Oct 88 18:49 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-DELETION (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013184936.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 We felt this was ready for vote.

∂13-Oct-88  1806	CL-Cleanup-mailer 	Issue: RANGE-OF-COUNT-KEYWORD (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:04:33 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476099; Thu 13-Oct-88 19:00:37 EDT
Date: Thu, 13 Oct 88 19:00 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: RANGE-OF-COUNT-KEYWORD (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013190029.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Consistency with FORMAT-NEGATIVE-PARAMETERS.
 Maybe merge and/or change sense to make negative an error.
 KMP will reconsider and make new writeup.

∂13-Oct-88  1806	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 8) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  16:00:35 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476091; Thu 13-Oct-88 18:57:58 EDT
Date: Thu, 13 Oct 88 18:57 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL (Version 8)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013185748.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 KMP will be responsible for writing or acquiring new draft.

X3J13 meeting:

 Masinter: Not ready for vote, but comments solicited.

 JonL: Would the presence of UNSPECIAL declaration help?

 KMP: No. UNSPECIAL doesn't address the original issue of closing
      over these global variables.

 JonL hadn't studied this enough and had a bunch of questions.
 Maybe we'll get more feedback from him when he's read it more carefully.

Offline:

 Julian Padgett (I probably got the spelling wrong) said he
 supports the LG proposal. He doesn't like the D stuff getting
 mixed up in there at all.

∂13-Oct-88  1806	CL-Cleanup-mailer 	Issue: RETURN-VALUES-UNSPECIFIED (Version 4)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:05:07 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476111; Thu 13-Oct-88 19:11:14 EDT
Date: Thu, 13 Oct 88 19:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: RETURN-VALUES-UNSPECIFIED (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013191106.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Thought ready for vote.

X3J13 meeting:

 Barmar: Wants to leave some of these unspecified.

 KMP: That just causes portability problems. Don't want to leave it
      unspecified -unless- someone can cite a reason to do so.

 JonL: People doing things like (AND (PRINT X) (PRINT Y)) need
       return values specified. [KMP choked at this thought.]

 Haflich: If many weren't defined, maybe we should leave 'em, but
	  since nearly all -are- defined, let's just go ahead and
	  round out the set.

 Skona: Most text books she's seen show CLOSE returning NIL.
	One text book shows it returning T.
	Since some people like to think of T as success and NIL
	as failure, maybe it should always return T.
        [There was some ensuing discussion of whether it could
	 ever return NIL since it signals an error in that case.]

 People seemed to think CLOSE should probably return T.

 No vote was attempted.

∂13-Oct-88  1807	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 2)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:05:07 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476107; Thu 13-Oct-88 19:06:36 EDT
Date: Thu, 13 Oct 88 19:06 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013190628.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 It was thought we should divide this into two issues: What does it do
 (signals an error, doesn't try to load) and where should it go in the
 file (relation to load, other environment issues).

X3J13 meeting:

 Masinter: Maybe we should note that it might be extended on a per-implementation
	   basis to offer arguments saying how to load for implementations
	   that want to offer such.

 I (KMP) made a note to myself about the fact that we shouldn't encourage
 people to add optional arguments to things -- maybe we should have a policy
 that vendor extensions to arguments must be by keyword to help avoid 
 and/or detect portability conflicts.

∂13-Oct-88  1807	CL-Cleanup-mailer 	Issue: SETF-FUNCTION-VS-MACRO (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:05:33 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476117; Thu 13-Oct-88 19:16:08 EDT
Date: Thu, 13 Oct 88 19:15 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-FUNCTION-VS-MACRO (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013191556.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting:

Cleanup meeting:

 KMP: Moon thinks it's important to get this vote on in some form soon,
      even if it takes an ammendment to leave out SYMBOL-FUNCTION and TRACE.

X3J13 meeting:

 Sandra brought an ammendment slide...

   Remove SYMBOL-FUNCTION, TRACE and UNTRACE from the list of affected
   functions.

   Add a new function:

   FDEFINITION <spec>					[Function]

   The current global function definition named by <spec> is returned.
   It is an error if the <spec> has no function definition.

   <spec> must be either a symbol or a list of the form (SETF <symbol>).

   FDEFINITION may be used with SETF to alter the global function
   definition.

 JonL, Gregor: De-couple the issue from the issue of essential
      	       functionality from that of function specs.

 The discussion ended due to lack of time.

∂13-Oct-88  1807	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (Version 8)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:06:01 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476125; Thu 13-Oct-88 19:19:18 EDT
Date: Thu, 13 Oct 88 19:19 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (Version 8)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013191910.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Thought ready for vote.

X3J13 meeting:

 RWK had some questions about things he thought the proposal might
 be saying that worried him, but he was pacified by people pointing
 him at definitive wording.

 People seemed not to object, but no vote was taken.

∂13-Oct-88  1807	CL-Cleanup-mailer 	Issue: SPECIAL-VARIABLE-TEST (Version 2) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:06:00 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476121; Thu 13-Oct-88 19:17:46 EDT
Date: Thu, 13 Oct 88 19:17 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SPECIAL-VARIABLE-TEST (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013191738.0.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 This might get put on hold pending outcome of
 SYNTACTIC-ENVIRONMENT-ACCESS issue. If that doesn't fly,
 this would get revived.

∂13-Oct-88  1807	CL-Cleanup-mailer 	Issue: ROOM-DEFAULT-ARGUMENT (Version 1) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:05:32 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476112; Thu 13-Oct-88 19:12:03 EDT
Date: Thu, 13 Oct 88 19:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013191155.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Thought ready for vote.

X3J13 meeting:

 Beckerle: Are there others in this category? Let's get them all at once.

 van Roggen: Gratuitous.

∂13-Oct-88  1807	CL-Cleanup-mailer 	Issue: STREAM-ACCESS (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:06:21 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476132; Thu 13-Oct-88 19:22:57 EDT
Date: Thu, 13 Oct 88 19:22 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-ACCESS (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013192249.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Thought to be ready for vote.

X3J13 meeting:

 RWK: Don't like all the -P functions for the new types.

 Someone said he wanted us to mention (which we apparently forgot)
 that these types are subtypes of STREAM.

 There were some people who wanted only the -P functions and not
 the types.

 A straw poll was taken to see if people wanted TYPES & -P FNS,
 just TYPES, or just -P FNS. Alas, I didn't record the outcome
 of this vote, though there were definitely people in all three
 camps. I think we said we'd put all three options on the letter
 ballot.

∂13-Oct-88  1807	CL-Cleanup-mailer 	Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:07:06 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476145; Thu 13-Oct-88 19:29:36 EDT
Date: Thu, 13 Oct 88 19:29 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: CL-Compiler@SAIL.Stanford.EDU
Message-ID: <881013192927.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

At Fairfax, we agreed that further discussion on this issue should take
place on CL-Compiler only to help reduce the load on CL-Cleanup.

∂13-Oct-88  1807	CL-Cleanup-mailer 	Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:07:26 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476147; Thu 13-Oct-88 19:31:21 EDT
Date: Thu, 13 Oct 88 19:31 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013193113.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Not ready. Needs more work.

 I (KMP) made a note to myself that this should probably be related to
 the new DEBUG quality.

 KMP will work out a rewrite.

∂13-Oct-88  1807	CL-Cleanup-mailer 	Issue: TEST-NOT-IF-NOT (Version 2)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Oct 88  18:07:35 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476148; Thu 13-Oct-88 19:35:03 EDT
Date: Thu, 13 Oct 88 19:34 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TEST-NOT-IF-NOT (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881013193454.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes from Fairfax meeting...

Cleanup meeting:

 Ready for vote (or straw vote).

 Pierson says, contrary to what's in writeup, that he endorses it only
 if it's deprecated (rather than removed).

X3J13 meeting:

 Barmar: want ability to express a contingent vote on the letter
         ballot. eg, "Yes, only if FUNCTION-COMPOSITION passes."

 RWK: want ability to to vote contingent on deprecation/removal
      strategy.

 JonL: visible change, low payback.

 van Roggen: Something should definitely be done. eg, some implementations
	     might extend the "is an error" case of both :TEST and :TEST-NOT
	     to use AND or OR to resolve the ambiguity!

∂13-Oct-88  2051	CL-Cleanup-mailer 	Issue: FUNCTION-DEFINITION (Version 1)   
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Oct 88  20:51:30 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA23995@EDDIE.MIT.EDU>; Thu, 13 Oct 88 23:51:19 EDT
Received: by spt.entity.com (smail2.5); 13 Oct 88 23:41:20 EDT (Thu)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Thu, 13 Oct 88 17:31 EDT <881013173106.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-DEFINITION (Version 1)
Message-Id: <8810132341.AA02256@spt.entity.com>
Date: 13 Oct 88 23:41:20 EDT (Thu)
From: gz@spt.entity.com (Gail Zacharias)

Coral implements something like this proposal (under a different name) with
both the OPTIONAL and REQUIRED options.  The requiredness is controlled by a
user variable (*save-definitions*) which applies whenever a function is
created from a lambda expression (as opposed to being fasloaded).  This
includes at least calls to COMPILE and the newly popular (EVAL '(FUNCTION
(LAMBDA ...))) idiom.  Thus program-manipulating programs can ensure (by
binding the variable) that the lambda expression is preserved whenever it's
coerced to a function under program control, while users can turn off its
interactive effect (by setting the global value) if space is tight.

Note that we have an (optional) compiler-based evaluator, and not only does
this not speak against this proposal, it was the main motivation for our
providing this functionality in the first place.  And since one of the
effects of disallowing the application of lambda expressions is to make
program-creating programs behave as if they were in a compiler-based
implementation, most such programs will require this functionality now, and
each one would need to reimplement it if it's not provided by the language.

I strongly prefer a name like FUNCTION-DEFINITION over SOURCE-CODE, as the
latter can be confused with the textual source code (as in meta-.).

I would also prefer that FUNCTION-NAME be split off as a separate function
rather than being one of the values from FUNCTION-DEFINITION, especially if
the suggestion above about unifying the two options with a *save-definitions*
variable is adopted.  This is because recording of function names should
not be controlled by this variable.

∂14-Oct-88  1058	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Oct 88  10:58:09 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476546; Fri 14-Oct-88 13:57:46 EDT
Date: Fri, 14 Oct 88 13:57 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DYNAMIC-EXTENT (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881013163747.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881014175733.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: Thu, 13 Oct 88 16:37 EDT
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

     Masinter: This issue is related to the ISO proposal for multiple
	       values and rest arguments.

I haven't seen that proposal, how does one obtain it?

∂14-Oct-88  1058	CL-Cleanup-mailer 	Issue: PRINT-CIRCLE-STRUCTURE  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Oct 88  10:55:56 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476544; Fri 14-Oct-88 13:55:35 EDT
Date: Fri, 14 Oct 88 13:55 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRINT-CIRCLE-STRUCTURE
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8810132043.AA19823@decwrl.dec.com>
Message-ID: <19881014175516.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 13 Oct 88 13:43:44 PDT
    From: vanroggen%aitg.DEC@decwrl.dec.com

    This reminds me of another issue which may deserve a cleanup issue:
    *PRINT-CIRCLE* ought to say that the printer detects shared structure
    as well as circularity.  The description of #n# and #n= does mention
    referring to shared structures as well as circular ones, so it would
    make sense that the printer should behave in this manner.

Good point.  This may in fact be controversial, since detecting shared
structure can be considerably more expensive to implement than only
detecting circular structure.

∂14-Oct-88  1217	CL-Cleanup-mailer 	WITH-DYNAMIC-EXTENT  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 14 Oct 88  12:17:24 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 14 Oct 88 15:00:58 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 14 Oct 88 15:15:52 EDT
Date: Fri, 14 Oct 88 15:16 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: WITH-DYNAMIC-EXTENT
To: cl-cleanup@sail.stanford.edu
Message-Id: <19881014191630.0.BARMAR@OCCAM.THINK.COM>

I just read the WITH-DYNAMIC-EXTENT proposal in CLtC-2 (Common Lisp: the
Cleanup Part 2), and I don't like it.  The problem, which is almost
touched on in the Discussion section, is that there may be some consing
going on that the user isn't aware of, and which is required to be of
indefinite extent.  I don't think a vendor who allows programmers to
specify that their objects should have dynamic extent should be forced
to go through their entire system and find all the places where
WITH-INDEFINITE-EXTENT should be added; I wouldn't trust them to be able
to find all of them (I don't think it's a mechanizable process).

I agree that some mechanism for this purpose should be provided.
However, I would prefer a mechanism that is a little more careful than
the current proposal.  Within a WITH-DYNAMIC-EXTENT form, a program
should have to explicitly indicate which objects should have dynamic
extent.  Something like:

(defun and-and-multiply (a b)
  (with-dynamic-extent ()
    (let ((x (dynamic (list a b)))
	  (y (cons nil nil)))
      (setf (car y) (apply #'+ x)
	    (cdr y) (apply #'* x))
      y)))

Here is the full description of my WITH-DYNAMIC-EXTENT and DYNAMIC
forms.  Please bear in mind that I just designed these now, and haven't
thought about them a great deal.

WITH-DYNAMIC-EXTENT			Macro

(WITH-DYNAMIC-EXTENT (&optional (INDICATOR NIL)) &body BODY)

This declares a contour during which the program may allocate objects
whose extent is specified to be within the dynamic lifetime of this
form [this wording is horrible, but you know what I mean].  To specify
which objects may be reclaimed when exiting this form, use the DYNAMIC
macro with a matching indicator.

INDICATOR is not evaluated.  BODY is evaluated as an implicit PROGN.

Value: the values of the last form of the body.

----------

DYNAMIC					Macro

(DYNAMIC FORM &optional (INDICATOR NIL))

The return values of FORM are specified to have the dynamic extent of
the most recent WITH-DYNAMIC-EXTENT form with a matching indicator.
FORM is evaluated, INDICATOR is not evaluated.

If a return value of this form is assigned to a place that is accessed
once the matching WITH-DYNAMIC-EXTENT form is exited, or if this value
is used as the return value of the WITH-DYNAMIC-EXTENT form or one
outside the WITH-DYNAMIC-EXTENT form (e.g. as the value in a throw to an
enclosing catch), the results are undefined.

Value: the values of FORM.

----------

An advantage of the WITH-DYNAMIC-EXTENT in the CLtC-2 proposal is that
it gives the application programmer some control over the internal
consing done by system and/or library routines.  However, I think it
should be the vendors' responsibility to make sure that these don't cons
any more than is necessary, if that is a concern of their customers.  I
don't think we should be providing a mechanism that allows developers to
control "behind the back" consing; it should only allow them explicit
control over the objects that they know about.

I made the indicators unevaluated because I was first thinking that this
would be a purely lexical facility.  Since I dropped that idea, it might
be appropriate to make the indicators be evaluated.

I am not wedded to the name DYNAMIC for the second operator.  Perhaps
DYNAMIC-VALUE would be better.

One problem with my version is that it doesn't provide a way to mark
objects that are bound to variables by macros as dynamic.  For example,
in a WITH-OPEN-FILE form, the OPEN form is not explicit, so it isn't
possible to wrap DYNAMIC around it.  The programmer would have to use
WITH-OPEN-STREAM in order to expose the OPEN call.  (On the other hand,
in most such cases it probably would be OK for the implementation of
such macros to allocate the objects dynamically, so the programmer
wouldn't need to).

                                                barmar

∂14-Oct-88  1221	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 14 Oct 88  12:18:42 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa06776; 14 Oct 88 19:09 BST
Date: Fri, 14 Oct 88 19:11:41 BST
Message-Id: <27644.8810141811@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: issue PROCLAIM-LEXICAL
To: sandra <@cs.utah.edu:sandra@defun>, cl-cleanup@sail.stanford.edu
In-Reply-To: sandra's message of Thu, 13 Oct 88 16:23:50 MDT

> I don't really like proposal LG very much.  I gather from the discussion
> that there was also a proposal LDG around at one time?

I think the description in termas of LG, LDG, etc. can be confusing.
LDG is supposedly what happens to free references: look in L; if not
there, it's dynamic and that means DG.  But variables declared special
are supposed to be just DG.  But what if there's a lexical binding
in the way?  Don't you have to look in L first?  So perhaps that
case should be called LDG too.

I prefer a prepainting model: first paint all special variables
red.  One of the rules for painting has free refs painted red.
Then they are just like variables declared special.  In this
way, we separate the question "what's special?" from "how is
the value found?".

> This issue appears to be addressing what I consider to be actually
> two separate problems.  The first problem is a way to undo SPECIAL
> declarations.  Wasn't there once a proposal for an UNSPECIAL
> declaration to deal with this? 

They can be separate.  But they might not be.  If there's a LEXICAL
proclamation for "global lexical" or "default to lexical and note that
this is a variable name that might occur free (so don't warn me about
it)", then the declaration that overrides a SPECIAL proclamation
should probably be LEXICAL too, rather than UNSPECIAL.

> The second problem is a way to specify a "global lexical variable".
> To me that implies something very much like what is specified for the
> binding behavior of DEFCONSTANT (it specifies a separate set of
> restrictions on SETQ'ing).  I've thought for a long time that Common
> Lisp ought to provide a declaration for variable binding corresponding
> to what DEFCONSTANT does.

Now, that (i.e., CONSTANT proclamation) I think should be a separate
issue.

> Why not assign that meaning to the LEXICAL
> declaration, or maybe call it GLOBAL if people object to using
> LEXICAL?  (The behavior of DEFCONSTANT is actually pretty close to
> what "GLOBAL" variables in PSL were like.) I suppose people would want
> an UNGLOBAL too.... 

There are some problems with the DEFCONSTANT model for "global lexical".
The constants are effectively proclaimed SPECIAL but (special) binding
is disallowed.  Because of the SPECIAL proclamation, this prevents
lexical binding too; but lexical binding should not be prevented for
global lexicals.  "Global" in Lisps like PSL means something like
"special but can't bind".

Another idea that comes out of Lisps that more or less had only dynamic
variables (and used deep binding) is that one wants to be able to get
the global value even if there are local (lexical) variables with the
same name in the way and perhaps even if there special bindings for that
name.  In the current proposal, the way to get the global value is
either to call a function that refers free (so there's no lexical
shadowing) or to agree not to special bind that name and then use
(LOCALLY (DECLARE (SPECIAL V)) V).  I think those are reasonable
solutions; whether the desire for something more is also reasonable is
less clear.

That said, however, I don't think I disagree with you very much.

> The thing about proposal LG that strikes me as being the most
> confusing to users and troublesome to implementors is allowing access
> to both the dynamic and global value of the same variable.  I think it
> would be reasonable to make the two mutually exclusive. 

True, that would be a reasonable position to fall back to.  But I would
prefer to think of it as lexical and special being mutually exclusive.
Either kind of variable might have a global value.  But, as in a LET,
there can be only one kind of binding for a given name at a given level.
Global should be a "given level".  You might think of this as saying
there are only two envs -- L and D -- and no separate G.  In the
current "LG" proposal, it's best to think of it as having three envs:
L, D, and G.  And if you think of it that way, the proposal makes
sense.

-- Jeff

∂14-Oct-88  1239	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Oct 88  12:38:54 PDT
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA27687; Fri, 14 Oct 88 13:38:33 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA20475; Fri, 14 Oct 88 13:38:28 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810141938.AA20475@defun.utah.edu>
Date: Fri, 14 Oct 88 13:38:27 MDT
Subject: Re: issue PROCLAIM-LEXICAL
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Fri, 14 Oct 88 19:11:41 BST

> Date: Fri, 14 Oct 88 19:11:41 BST
> From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>

> There are some problems with the DEFCONSTANT model for "global lexical".
> The constants are effectively proclaimed SPECIAL but (special) binding
> is disallowed.  Because of the SPECIAL proclamation, this prevents
> lexical binding too; but lexical binding should not be prevented for
> global lexicals.

That isn't what CLtL says about DEFCONSTANT.  From p. 69:

  Once a name has been declared by defconstant to be constant, any
  further assignment to or binding of that special variable is an error.
  [...]  A compiler may also choose to issue warnings about bindings of
  the lexical variable of the same name.

My impression is that this wording was carefully chosen with the
specific intent of allowing (but maybe not encouraging) lexical
binding of the name.  Note that it specifically outlaws special
binding but says something else entirely about lexical binding.  Also,
I don't believe this means constants are effectively proclaimed
SPECIAL, because (as the language is defined in CLtL) the question of
lexical bindings would never come up at all then.

> That said, however, I don't think I disagree with you very much.

Likewise.

-Sandra
-------

∂14-Oct-88  1304	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-GC (no proposal)   
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 14 Oct 88  13:03:19 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa05105; 14 Oct 88 15:43 BST
Date: Fri, 14 Oct 88 15:45:36 BST
Message-Id: <26808.8810141445@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: HASH-TABLE-GC (no proposal)
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, CL-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Thu, 13 Oct 88 17:54 EDT

> My notes from Fairfax meeting...
> 
> Cleanup meeting:
> 
>  This issue is about the inordinately long discussion on Common-Lisp@SAIL
>  about hash tables.

Much of the discussion was about secondary issues, so it wasn't really
so bad (I think).

>  Masinter said he would try to get Dalton to write up this issue as
>  a proposal.

I still plan to write it up.  I'd wanted to wait until discussion had
pretty much stabilized, and then some other things kept me from getting
to it.

> X3J13 meeting:
> 
>  KMP: There are several kinds of such hash tables. Those that are weak
>       on key link, weak on value, and both.

True.  Weak on key (if it becomes impossible to refer to the key
(modulo the test) the entry can be removed) had the greatest precedent
and seems the most useful.

>  JonL, RWK: Nervous about this because it's "new technology".
> 
>  Gregor: It IS implemented -- just not in Lisp. It is NOT new technology.

Pop11 has this feature as "temporary properties".  Pop implementations
have supported it from some time.  For the purposes of this discussion,
Pop can be considered Lisp with a different syntax.  PopLog Common Lisp
can use the tables in Pop.  Lisp/VM has weak tables.  Interlisp has (I
think) switched back and forth about what hash tables do.  At one point,
they may have been week.  T has weak sets (formerly populations).  T has
weak pointers.

There are a lot of other points.  I think I will be able to summarize
them adequately in the proposal.

Thanks, Kent, for sending the message.

Cheers,
Jeff

∂14-Oct-88  1329	CL-Cleanup-mailer 	RE: Issue: HASH-TABLE-ACCESS (version 2) 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Oct 88  13:29:48 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA06582; Fri, 14 Oct 88 13:29:08 PDT
Date: Fri, 14 Oct 88 13:29:08 PDT
Message-Id: <8810142029.AA06582@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: gz@spt.entity.com
Subject: RE: Issue: HASH-TABLE-ACCESS (version 2)

Well, I think there would be some leeway on the return values for
HASH-TABLE-REHASH-SIZE/REHASH-THRESHOLD/SIZE too.

If an implementation really did implement them with association lists,
perhaps reasonable return values would be:
  HASH-TABLE-REHASH-SIZE  1
  HASH-TABLE-REHASH-THRESHOLD  1.0
  HASH-TABLE-SIZE  the length of the association list

			---Walter

∂14-Oct-88  1434	CL-Cleanup-mailer 	Re: Issue: EQUAL-STRUCTURE (Version 5)   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 14 Oct 88  14:34:06 PDT
Received: by ti.com id AA25126; Fri, 14 Oct 88 16:34:04 CDT
Received: from Kelvin by tilde id AA22754; Fri, 14 Oct 88 16:22:18 CDT
Message-Id: <2801856256-4716520@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 14 Oct 88  16:24:16 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: EQUAL-STRUCTURE (Version 5)
In-Reply-To: Msg of 8 Oct 88 16:33 PDT from cl-cleanup@sail.stanford.edu

> Our intent is to leave EQUAL and EQUALP alone. We are just having
> difficulty saying what it does now.

There is one important thing that this proposal does do:  it specifies
the meaning of EQUALP for CLOS instances, which I don't think was
previously defined.

∂14-Oct-88  1449	CL-Cleanup-mailer 	Re: DRAFT Issue: TAILP-NIL (Version 2)   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 14 Oct 88  14:49:18 PDT
Received: by ti.com id AA25239; Fri, 14 Oct 88 16:49:18 CDT
Received: from Kelvin by tilde id AA23070; Fri, 14 Oct 88 16:39:35 CDT
Message-Id: <2801857295-4778903@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 14 Oct 88  16:41:35 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: DRAFT Issue: TAILP-NIL (Version 2)
In-Reply-To: Msg of 8 Oct 88 22:06 PDT from masinter.pa@XEROX.COM

> Current Practice:
> 
>   Symbolics Genera is consistent with TAILP-NIL:T.
> 
>   [Walter alleges TAILP-NIL:NIL is what all implementations already
>    do, but since Genera is not in conformance, KMP regards that
>    hypothesis as suspect. We need real data points, folks.]

The Explorer is consistent with TAILP-NIL:NIL, in accordance with the
1985 "clarifications" list, but I don't really have an opinion on
whether this is the best choice.

∂14-Oct-88  1537	CL-Cleanup-mailer 	Re: several hundred ugly things     
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Oct 88  15:37:48 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 14 OCT 88 15:11:06 PDT
Date: 14 Oct 88 15:10 PDT
From: masinter.pa@Xerox.COM
Subject: Re: several hundred ugly things 
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
cc: CL-Cleanup@sail.stanford.edu
Message-ID: <881014-151106-7509@Xerox>

Jeff:

We've reached the odd state where "aesthetic" is used perjoratively, as in
"merely aesthetic". I think of aesthetic considerations as strongly related
to the properties of elegance, ease of teaching, learning and
understanding. I tend to enjoy using computer systems that are
aesthetically pleasing. 

Personally, I reached the conclusion long ago that it would not be possible
to make major inroads into the aesthetics of Common Lisp by any small set
of "cleanups". What makes Common Lisp hard to teach and learn is not
necessarily even caused by a lack of elegance or simplicity. There is some
evidence that Scheme is hard to teach and learn, although this has been
mitigated by the excellent effort that has gone into teaching materials for
it.

I think I will claim that I was misquoted in my reference to ISO --
although perhaps I merely mispoke. I think there is much interest in
defining a language that is smaller than Common Lisp, e.g., that works well
with the current and pending generations of laptops and PCs.  While I heard
this interest most recently expressed at an ISO meeting, it is of serious
concern in the US as well, e.g., by those considering Lisp for applications
in embedded systems. 


However, on reflection, I believe that the issues of determining those
features of CL that should be declared "obsolete" is nearly orthogonal to
the issues of "delivery subsets" or some such. I think we can define a
class of features of CL that should be Obsolete. How these are to be dealt
with in any implementation is an important concern, but will be easier to
determine once we have the list of "obsolete" features. (I would include
:TEST-NOT and BIGNUM and STRING-CHAR and some other misfeatures into the
"obsolete" bucket; perhaps you have your own list.)


∂15-Oct-88  1015	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 15 Oct 88  10:12:51 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa01772; 15 Oct 88 17:58 BST
Date: Sat, 15 Oct 88 18:01:42 BST
Message-Id: <28618.8810151701@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: issue PROCLAIM-LEXICAL
To: sandra <@cs.utah.edu:sandra@defun>
In-Reply-To: sandra's message of Fri, 14 Oct 88 13:38:27 MDT
Cc: cl-cleanup@sail.stanford.edu

> > Date: Fri, 14 Oct 88 19:11:41 BST
> > From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
> 
> > There are some problems with the DEFCONSTANT model for "global lexical".
> > The constants are effectively proclaimed SPECIAL but (special) binding
> > is disallowed.  Because of the SPECIAL proclamation, this prevents
> > lexical binding too; but lexical binding should not be prevented for
> > global lexicals.
> 
> That isn't what CLtL says about DEFCONSTANT.  From p. 69:

You're right, but I was making deductions.  Perhaps I read too much
into "that special variable" and "like DEFPARAMETER but".  Nonetheless,
Lucid CL 2.1 does proclaim it special.

All I wanted to establish was that lexical bindings should be OK.

∂17-Oct-88  1003	CL-Cleanup-mailer 	Re: Issue: CLOSED-STREAM-OPERATIONS (version 3)    
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 17 Oct 88  10:03:13 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA00771; Mon, 17 Oct 88 13:02:12 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA11549; Mon, 17 Oct 88 12:16:30 EDT
Message-Id: <8810171616.AA11549@mist.UUCP>
To: "vanroggen%aitg.DEC@decwrl.dec.com"@multimax
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: CLOSED-STREAM-OPERATIONS (version 3) 
In-Reply-To: Your message of Thu, 13 Oct 88 11:58:56 -0700.
             <8810131858.AA13409@decwrl.dec.com> 
Date: Mon, 17 Oct 88 12:16:28 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

Thanks Walter.  Since this looks good at a first glance, I'm not
planning another writeup.

∂17-Oct-88  1156	CL-Cleanup-mailer 	New issue: LCM-NO-ARGUMENTS    
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Oct 88  11:56:28 PDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Mon, 17 Oct 88 14:29:53 EDT
Received: by joplin.think.com; Mon, 17 Oct 88 14:54:49 EDT
Date: Mon, 17 Oct 88 14:54:49 EDT
From: gls@Think.COM
Message-Id: <8810171854.AA00267@joplin.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: New issue: LCM-NO-ARGUMENTS

Issue:         LCM-NO-ARGUMENTS

References:    CLtL p. 202

Related issues: none

Category:      ADDITION

Edit history:  Version 1, Guy Steele 10/17/88

Problem description:

   CLtL incorrectly states that (lcm) should return infinity, and
   therefore specifies that giving lcm no arguments is an error.

   In point of mathematical fact, 1 is the identity for the lcm operation.

Proposal (LCM-NO-ARGUMENTS:1):  Define (lcm) to return the integer 1.

Examples:   (lcm) => 1

Test Cases:  (lcm) => 1

   Currently the behavior in this case is implementation-dependent.

Rationale:  Doing what is mathematically right.

Current practice:
   KCL signals an error.
   Lucid Lisp returns 1.
   Symbolics Common Lisp returns 1.

Cost to Implementors:  Pretty small (one-line fix).

Cost to Users:  None.

Cost of non-adoption:  Continued embarassment for Steele.

Performance impact:  Negligible.

Benefits:  Correct handling of a seldom-used boundary case.

Esthetics:  Mild improvement.

Discussion:  Mentioned in Steele's December 1985 "clarifications".

∂17-Oct-88  1213	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATIONS (version 3)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Oct 88  12:13:07 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 477479; Mon 17-Oct-88 15:11:57 EDT
Date: Mon, 17 Oct 88 15:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOSED-STREAM-OPERATIONS (version 3)
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8810131858.AA13409@decwrl.dec.com>
Message-ID: <881017151141.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Thu, 13 Oct 88 11:58:56 PDT
    From: vanroggen%aitg.DEC@decwrl.dec.com

    ...
    Issue:        CLOSED-STREAM-OPERATIONS
    ... 
    Proposal (CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY)
 
    Clarify that one may call the following functions on closed streams without
    error due to the stream being closed:

This is not the same as saying they will continue to return the same values.
For example...
 - perhaps CLOSE on a closed stream should return NIL, not T. 
 - perhaps some implementations would want INPUT-STREAM-P of closed streams to be NIL.
   i think there's no good reason to have that be so, but it's an issue that would
   have to be resolved and implementations would likely diverge in the absence of info
   so it could lead to portability troubles if we don't clarify that if a stream was
   INPUT-STREAM-P when open, it will be when closed, too. [we might acknowledge the
   possibilty that a stream could be `re-opened' in an implementation-specific way,
   in which case the way this function operated could change.]
    (SETQ S (OPEN "file" :DIRECTION :INPUT))
    (INPUT-STREAM-P S) => T
    (CLOSE S) => T
    (CLOSE S) => T ;NIL?
    (INPUT-STREAM-P S) => T
    (OPEN S :DIRECTION :OUTPUT) => ??
    (INPUT-STREAM-P S) => ??
 - I could imagine the pathname information for a pathname wanting to change from
   the opened name to the truename upon close. eg, if you open .NEWEST, you might
   know the truename only after you close. TRUENAME might therefore want to return
   something different after CLOSE. Whether it should be permitted is something
   -we- should decide, not something we should leave up to implementors ... at least
   not without making it explicit that we're doing so.
 - Gack. I never noticed that PATHNAME-VERSION could be called on a stream. Hmmmm.
   Same comment as for TRUENAME, I guess.
 - The interaction of DIRECTORY is particularly interesting. Even if the truename
   does not change, some file systems will treat DIRECTORY of foo.lisp.newest
   differently depending on whether the stream to that file is still open. Some can
   tell you the file is there but it's still open, while others will not admit its
   existence until it's closed. I don't think we can get away without saying
   something about this.

Any operation for which the level of well-definedness of its meaning is not preserved
by CLOSE is at least a candidate for making an out-and-out error since the behavior
after CLOSE will not be portably defined. Actually, we can probably say "unspecified"
in most cases rather than "undefined" since we can say the behavior is harmless, but
it just may not be particularly meaningful...

∂17-Oct-88  1235	CL-Cleanup-mailer 	RE: Issue: CLOSED-STREAM-OPERATIONS (version 3)    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 17 Oct 88  12:35:42 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA24044; Mon, 17 Oct 88 12:34:44 PDT
Date: Mon, 17 Oct 88 12:34:44 PDT
Message-Id: <8810171934.AA24044@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: KMP@stony-brook.scrc.symbolics.com
Subject: RE: Issue: CLOSED-STREAM-OPERATIONS (version 3)

The problems you mention are part of the reason Kathy and I originally
proposed the "can't-do-anything-on-closed-streams" version of this
proposal.  (Although I hadn't included STREAMP in the list of can't-do's,
since I hadn't thought of that predicate originally.)

Anyone else have any comments?  I don't want to spend too much time on this
issue.

∂17-Oct-88  1313	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Oct 88  13:13:51 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA05099g; Mon, 17 Oct 88 13:13:38 PDT
Received: by bhopal id AA03278g; Mon, 17 Oct 88 13:12:04 PDT
Date: Mon, 17 Oct 88 13:12:04 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810172012.AA03278@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Thu, 13 Oct 88 15:41 EDT <881013154128.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 8)

re: My notes from Fairfax meeting...

I also remember Sandra remarking that the proposal part was "unreadable".
This relates somewhat to my comment about the lack of focus on TYPEP
and unnecessary, possibly confusing, detail about how make-array should
work.  I expect to do another version "soon", but possibly as late as
next week.


-- JonL --

∂17-Oct-88  1410	CL-Cleanup-mailer 	New issue: LCM-NO-ARGUMENTS    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Oct 88  14:10:32 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 477603; Mon 17-Oct-88 17:06:36 EDT
Date: Mon, 17 Oct 88 17:06 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New issue: LCM-NO-ARGUMENTS
To: gls@Think.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8810171854.AA00267@joplin.think.com>
Message-ID: <19881017210614.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

LCM-NO-ARGUMENTS:1 is fine by me.

∂17-Oct-88  1512	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 17 Oct 88  15:11:50 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA03508; Mon, 17 Oct 88 16:09:47 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA11848; Mon, 17 Oct 88 16:13:44 EDT
Message-Id: <8810172013.AA11848@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Cc: "sandra%defun@cs.utah.edu"@multimax
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
Date: Mon, 17 Oct 88 16:13:42 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

Almost done.  Please note the second paragraph of the new Rationale.
Would it be better to just restrict REQUIRE to the *MODULES* list?  I
seem to remember that at least one implementation was unhappy with that.

Issue:         REQUIRE-PATHNAME-DEFAULTS
References:    *MODULES*, PROVIDE, REQUIRE, pp 188-191
               LOAD, pp 426-427
Category:      CHANGE
Edit history:  Version 1 by Pierson 9/13/88
               Version 2 by Pierson 9/19/88, change PROVIDE stuff per comments
               Version 3 by Pierson 10/17/88, remove PROVIDE locaction specs.
Status:        For Internal Discussion

Problem description:

PROVIDE and REQUIRE are a dual-purpose pair of functions that attempt
to provide multi-file Common Lisp programs with a single mechanism to
detect and correct incorrect load sequences.  These functions were
also designed to be used for general file inclusion in Common Lisp.
Unfortunately, the file loading feature of REQUIRE is specified such
that it is inherently non-portable and environment dependent.

Proposal (REQUIRE-PATHNAME-DEFAULTS:DECLARATIVE):

Remove the second argument from REQUIRE.  Change the description of
REQUIRE to:

    The REQUIRE function tests whether a module is already present
    (using a case-sensitive comparison); if the module is not present,
    REQUIRE signals a correctable error of type REQUIRE-ERROR.
    This gives the user the opportunity to load the appropriate files
    from the debugger before continuing.

Note that there is no requirement that a module consist of exactly one
file. 

Change the description of PROVIDE to:

   "The PROVIDE function adds a new module name to the list of
    modules maintained in the variable *MODULES* and possibly performs
    other implementation-dependant actions to indicate that the module
    in question has been loaded."

(There is no need to make a corresponding change to the definition of
REQUIRE, because it doesn't mention *MODULES*.)

Test Cases/Examples:

(REQUIRE 'fft)

Would still be legal.

(REQUIRE 'fft "fft")

Would no longer be Common Lisp.

Rationale:

The file loading feature of REQUIRE is non-portable.  Since we can't
figure out an acceptable portable solution, the feature should be
flushed.  Making REQUIRE signal a correctable error gives the user an
easy out in interactive situations.

REQUIRE is not required to use *MODULES* as it's database of loaded
modules in order to permit environment-specific extensions which
derive the loaded module database from other information.  While it is
always safe, and good practice, to explicitly PROVIDE every module, it
may not be necessary in all implementations.  

Current practice:

All implementations that I know of currently support a second argument
to REQUIRE.  Lucid and KCL use the second argment at the pathname to
load relative to the current working directory.

Cost to Implementors:

All currently conforming implementations will have to make a small
change.

Cost to Users:

Any (non-portable) user programs that rely on the current behaviour of
REQUIRE will have to change.  On the other hand, porting Common Lisp
programs from one system to another may well be simplified because
REQUIRE errors will always correctable.

Cost of non-Adoption:

Part of the documented functionality of REQUIRE will continue to
unavailable to portable (and many non-portable) programs.

Benefits:

PROVIDE and REQUIRE will be clearly restricted to a portable,
checking role.

Aesthetics:

This simplifies the language by removing an environment-dependent
feature. 

Discussion:

Pierson supports this proposal.

This proposal creates an asymmetry in the handling of *MODULES* that
may bother some people.

Several people would like to simply eliminate PROVIDE and REQUIRE from
the language and either leave this language space empty or provide a
portable DEFSYSTEM standard.  Others believe that PROVIDE and REQUIRE
are useful as a safety-net even in the presence of DEFSYSTEM.  This
proposal attempts to reduce PROVIDE and REQUIRE to a well-defined
safety-net and leaves the question of DEFSYSTEM to a separate
proposal (which I don't intend to write).

∂17-Oct-88  1624	CL-Cleanup-mailer 	Issue: HASH-TABLE-ACCESS (version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Oct 88  16:23:58 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA05331g; Mon, 17 Oct 88 16:23:55 PDT
Received: by bhopal id AA04673g; Mon, 17 Oct 88 16:22:21 PDT
Date: Mon, 17 Oct 88 16:22:21 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810172322.AA04673@bhopal>
To: vanroggen%aitg.DEC@decwrl.dec.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: vanroggen%aitg.DEC@decwrl.dec.com's message of Thu, 13 Oct 88 12:30:44 PDT <8810131930.AA15360@decwrl.dec.com>
Subject: Issue: HASH-TABLE-ACCESS (version 2)

I still would like to see SETF enabled for:

    HASH-TABLE-REHASH-SIZE
    HASH-TABLE-REHASH-THRESHOLD

At issue is the rate of "rehashing" between successive, novel entries
into the table, and the rate of consing to maintain the table.  [Perhaps 
this would be clearer if there were a function in the language called 
REHASH; Lucid 3.0 has such a function, and Interlisp-D had such a function.]

Of course, the setf methods for these two accessors would do a good deal of 
argument and consistency checking.  So what possible harm could come from 
permitting the user to alter these parameters after initial creation?  those 
implementations that substitute alists for "hash-tables" can try to adapt to 
this view, that some kind of "rehash" step [with some determined cost] is 
done after the entry which first makes:

    (hash-table-count x)  >  (* (hash-table-size x)
                                (hash-table-rehash-threshold x))

be true [assuming a floating-point value for the threshold].  This is part 
of the whole point for having "hash tables" in the language.


-- JonL --

∂17-Oct-88  1636	CL-Cleanup-mailer 	DRAFT Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Oct 88  16:36:37 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA05372g; Mon, 17 Oct 88 16:36:33 PDT
Received: by bhopal id AA04724g; Mon, 17 Oct 88 16:34:59 PDT
Date: Mon, 17 Oct 88 16:34:59 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810172334.AA04724@bhopal>
To: barmar@Think.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Thu, 13 Oct 88 10:23 EDT <19881013142325.5.BARMAR@OCCAM.THINK.COM>
Subject: DRAFT Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)

re: This example is incorrect.  It should be: . . .

Right, the 'print-all-symbols' example was prematurely "printed".   Your
rewrite of it was almost correct; it should be

(defun print-all-symbols () 
  (with-package-iterator (next-symbol nil)
    (loop
      (multiple-value-bind (more? symbol) (next-symbol)
	(if more? 
           (print symbol)				<<---
	   (return))))))


I'll fix up the proposal "shortly".


-- JonL --

∂17-Oct-88  1647	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Oct 88  16:46:56 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA05400g; Mon, 17 Oct 88 16:46:46 PDT
Received: by bhopal id AA04777g; Mon, 17 Oct 88 16:45:13 PDT
Date: Mon, 17 Oct 88 16:45:13 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810172345.AA04777@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 11 Oct 88 13:05 EDT <19881011170501.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)

re: I still think the with-package-iterator syntax isn't right.  The way
    you have it now, there is a required argument <package> which by
    default is ignored! 

The only time the <package> argument is ignored is when the other arguments
imply DO-ALL-SYMBOLS.  MLY's original suggestion (to me, privately) was to 
have the <package> argument be optional; that would work too, and make for a
bit nicer syntax in the one case of DO-ALL-SYMBOLS.  Richard [MLY] actually
suggested dropping the DO-ALL-SYMBOLS case, but I don't think we can do that.

However, there is a constraint that isn't easy to express in the existing 
CL language: namely, that the <package> argument is required if any of the 
other keyword arguments are supplied as non-nil.  One way out of this bind 
is to let the &optional <package> argument default to the symbol *PACKAGE*; 
this way, there would be no problem of syntax consistency, but only that of 
remembering that, in the DO-ALL-SYMBOLS case, passing the optional argument
doesn't do anything.


-- JonL --

∂17-Oct-88  1700	CL-Cleanup-mailer 	Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 2)    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Oct 88  17:00:17 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA05422g; Mon, 17 Oct 88 17:00:15 PDT
Received: by bhopal id AA04829g; Mon, 17 Oct 88 16:58:41 PDT
Date: Mon, 17 Oct 88 16:58:41 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810172358.AA04829@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Thu, 13 Oct 88 18:15 EDT <881013181527.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 2)

re: My notes from Fairfax meeting...
    . . . 
     JonL: One issue is that infinite printing might occur if circularities
	   occur. [JonL said he doesn't believe this is reason not to do it,
	   but he did want to raise the issue.]

Hmmm, I seem to remember rebutting a contention like the one you now
attribute to me; namely, I claimed that circularities in hash-table
components should be no different than circularities in cons cells or 
structure components.  Possibly I raised the "straw man" myself, but I 
really thought somebody else did.

-- JonL --

P.S. Are your "Farifax meeting" notes something you wrote down at the time,
    or something you reconstructed from memory?  This is not a criticism,
    I'm just curious; and I won't ask again, although there may be other
    places like this where my memory differs from yours.

∂17-Oct-88  1717	CL-Cleanup-mailer 	Re: Issue: DEFPACKAGE (version 5)   
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 17 Oct 88  17:17:51 PDT
Received: from snail.Sun.COM by Sun.COM (4.0/SMI-4.0)
	id AA29538; Mon, 17 Oct 88 17:15:21 PDT
Received: from denali.sun.com by snail.Sun.COM (4.0/SMI-4.0)
	id AA20323; Mon, 17 Oct 88 17:18:17 PDT
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
	id AA06479; Mon, 17 Oct 88 17:19:55 PDT
Message-Id: <8810180019.AA06479@denali.sun.com>
To: CL-Cleanup@Sail.stanford.edu
Subject: Re: Issue: DEFPACKAGE (version 5)
Date: Mon, 17 Oct 88 17:19:14 -0700
From: peck@Sun.COM

 I hope it isn't too late to pik a couple of nits on this proposal...

Nit 1, :INTERNAL
 Most of the clause names are verbals (:USE, :EXPORT, :IMPORT-FROM, ...)
But the lately added :INTERNAL is more adjectival, and unlike 
:EXPORT and :USE and :SHADOW which mimic the function of the same name,
it appears to have a gratuitously different name from INTERN.

I suggest that the :INTERNAL option be renamed :INTERN.


Another nit:
Re: interaction with PACKAGE-CLUTTER, default :use list

 Please verify for me that if there is no :USE clause, whether
the created package will use:
  1. (:lisp)
  2. *default-use-list* (or whatever it is in jonl's PACKAGE-CLUTTER proposal)
  3. NIL
The correct answer is 1, i believe.  If i do (:use NIL) then I get 3,
how would I get 2? 
[use #+ for implementation specific packages, this is for PORTABLE code!]

The rest of the question is whether using the :LISP package is done
in the MAKE-PACKAGE, or lastly, in the (USE-PACKAGE).  Like all USE'ing
this should be deferred until after the shadowing is done, no?


Next nit, order of events:
  I think it is implicit, but not stated that DEFPACKAGE arranges
to sort the execution of all the various clauses to conform to 
(put in seven...) [although proposal says Export happens last..?]
Clarify that the order of the clauses in the source code has no effect.


Final nit:
Also, it says re: side-effects "ie, no IN-PACKAGE is done", 
clarify that this does not proscribe an implementation like:
 `(let ((*package *package*))
   (in-package ,new-name :use nil)
   ...)


Ps,
  If anyone has code to implement DEFPACKAGE, i'd appreciate a copy.

∂17-Oct-88  1716	CL-Cleanup-mailer 	issue HASH-TABLE-PRINTED-REPRESENTATION  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Oct 88  17:15:40 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA05431g; Mon, 17 Oct 88 17:15:23 PDT
Received: by bhopal id AA04865g; Mon, 17 Oct 88 17:13:49 PDT
Date: Mon, 17 Oct 88 17:13:49 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810180013.AA04865@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: sandra%defun@cs.utah.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 13 Oct 88 18:15 EDT <19881013221502.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: issue HASH-TABLE-PRINTED-REPRESENTATION

re: Date: Thu, 13 Oct 88 15:25:59 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
     I like the syntax suggested in what is described as "yet another proposal"
     but the way it specifies the optional parts is broken.  It should be
	#[size]H([type [rehash-size [rehash-threshold]]] (ki vi)*)
  It is very important that the syntax for expressing hash table options
  be extensible, and therefore keyword-based.  Any syntax like this that's
  positional, and furthermore assumes that all option values are
  non-lists, is simply not acceptable.  Putting the size out there in
  front is weird, too.

Is it really that important that the extensible part of the syntax look 
exactly like that for the "Standard" components?  Even in Sandra's format,
you still have room for implementation-specific keyword options.

-- JonL --

∂17-Oct-88  1716	CL-Cleanup-mailer 	RE: Issue: HASH-TABLE-ACCESS (version 2) 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 17 Oct 88  17:16:33 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA10064; Mon, 17 Oct 88 17:16:05 PDT
Date: Mon, 17 Oct 88 17:16:05 PDT
Message-Id: <8810180016.AA10064@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: jonl@lucid.com
Subject: RE: Issue: HASH-TABLE-ACCESS (version 2)

I'm quite sympathetic to being able to SETF some of the hash-table readers,
but I didn't think it appropriate to require of all implementations.

∂17-Oct-88  1748	CL-Cleanup-mailer 	Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 2)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Oct 88  17:48:06 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 477721; Mon 17-Oct-88 20:47:01 EDT
Date: Mon, 17 Oct 88 20:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 2)
To: JonL@Lucid.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8810172358.AA04829@bhopal>
Message-ID: <881017204645.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Mon, 17 Oct 88 16:58:41 PDT
    From: Jon L White <jonl@lucid.com>

    ... Are your "Fairfax meeting" notes something you wrote down at the time,
    or something you reconstructed from memory?  This is not a criticism,
    I'm just curious; and I won't ask again, although there may be other
    places like this where my memory differs from yours.

[Replying to the whole group since others may have had the same question. -kmp]

With one or two exceptions [and this is not one], I wrote them at the
time.  That's why I kept encouraging people to just make their point and
then let us go on. I figured I could reconstruct it all fairly
accurately online later from the notes I was taking.

My notes say you brought up the issue, that you thought it was not
something to worry about, but that you were afraid it was something
other people might worry about so you wanted to make sure it was noted.

Btw, the point of the notes was not to pin anyone to a particular
opinion.  I may have made mistakes in my recording or you may have
changed your mind.  The main purpose, which I think I was achieved, was
that all that we not forget all the important points which got raised so
that we can come out with writeups that are well-researched in the areas
that people seemed to care about.

∂17-Oct-88  1800	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Oct 88  18:00:03 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA05500g; Mon, 17 Oct 88 17:59:57 PDT
Received: by bhopal id AA05092g; Mon, 17 Oct 88 17:58:22 PDT
Date: Mon, 17 Oct 88 17:58:22 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810180058.AA05092@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Sat, 8 Oct 88 23:04 EDT <881008230447.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)

re: Many portable programs will be forced to put :USE "LISP" in where they
    do not currently specify. 

I claim this is not so [i.e. the "do not currently specify" part].  The 
relevant, unchallenged part of the proposal says:

    Cost to Users:

    In theory, every user porting code from one vendor to another would
    have to ensure that every package definition, via IN-PACKAGE or
    MAKE-PACKAGE, had an explicit :use list.  This is probably at most
    a 5-minute text editor search.  But in fact this imposition is moot,
    since virtually every such user has *already* supplied explicit
    :use lists; given the current practice, he has had no alternative.


re: Finally, under current practice, you ignored my remarks about Cloe so I'll
    repeat them. Cloe shadows MAKE-PACKAGE, IN-PACKAGE, etc. in the default
    package so that it offers the functionality you desire in a way that is
    not incompatible to Lisp. I would recommend that you do the same.
     LISP:MAKE-PACKAGE name &KEY nicknames (USE "LISP")
     CLOE:MAKE-PACKAGE name &KEY nicknames (USE "CLOE")
    Once you've chosen a package to work from, all calls to an unqualified
    MAKE-PACKAGE do the thing that is natural for that initial package.

This doesn't work the same; namely, it forces a user to preface his files:
        (cloe:in-package <mumble> ...)
rather than:
        (in-package <mumble> ...)
That is, assuming that CLOE does the reasonable thing of reading the 
IN-PACKAGE command from the USER package.  If you have some other
default package, then that itself is an imposition on at least the
same order of magnitude as the proposal for MAKE-PACKAGE-USE-DEFAULT.

I see MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT; as the lesser
of several evils.  As moon said [in msg of  Tue, 11 Oct 88 12:58 EDT]
    "... the issue is whether the default should
     be a portable way to get the local extensions, or a portable way to
     get the portable language without the extensions.  I think either of
     those choices is portable and reasonable, it just depends on what you
     want to make easier, ..."

Now, there may be a separate issue we haven't addressed yet -- just
what package is current when you load a file?  A "good style" program
will have an IN-PACKAGE command as the first executable form in the
file [or, a DEFPACKAGE followed by an IN-PACKAGE ?].  The question is,
how do you read the IN-PACKAGE itself?   Unfortunately, all 
implementations I've examined, including Lucid's, just leave you in 
the current package.  I believe the "reasonable" thing to do is to 
rebind *package* to USER; the expectation, of course, is that the current
package will immediately be changed via IN-PACKAGE.

The same issue holds with respect to the CL-Compiler committee's issue
about what package you start out in when you compile-file a file.  I
fear that, at the recent x3j13 meeting, we too easily assented to a 
rebinding of *package* to itself, precisely because we hadn't thought
through this "separate issue" before.



-- JonL --

∂17-Oct-88  1808	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (version 2)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Oct 88  18:08:41 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA05512g; Mon, 17 Oct 88 18:08:35 PDT
Received: by bhopal id AA05120g; Mon, 17 Oct 88 18:07:01 PDT
Date: Mon, 17 Oct 88 18:07:01 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810180107.AA05120@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 11 Oct 88 12:58 EDT <19881011165801.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: MAKE-PACKAGE-USE-DEFAULT (version 2)

re: I think it might be better to strengthen it and say that the
    default for :USE is identical to the use list of the USER package.
    Does anyone agree?

I agree, sort of.  Especially since one of the motivating factors for 
this proposal was that some Lucid 2.1 user's were complaining that 
"things" look a lot different from the USER package than from a 
user-created package.

The only question is whether or not you really want the default to be
sensitive to subsequent alterations of USER's :use list.  As mentioned
in the Discussion section of the proposal, Lucid's implementation
exposes the default as the value of a global variable, which happens
to be a copy of the initial :use list of USER; but subsequent changes 
to USER have no affect on this global variable.


-- JonL --

∂17-Oct-88  1840	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Oct 88  18:40:40 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 477766; Mon 17-Oct-88 21:40:33 EDT
Date: Mon, 17 Oct 88 21:40 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)
To: jonl@lucid.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8810180058.AA05092@bhopal>
Message-ID: <881017214016.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Mon, 17 Oct 88 17:58:22 PDT
    From: Jon L White <jonl@lucid.com>

    ...
    re: Finally, under current practice, you ignored my remarks about Cloe so I'll
	repeat them. Cloe shadows MAKE-PACKAGE, IN-PACKAGE, etc. in the default
	package so that it offers the functionality you desire in a way that is
	not incompatible to Lisp. I would recommend that you do the same.
	 LISP:MAKE-PACKAGE name &KEY nicknames (USE "LISP")
	 CLOE:MAKE-PACKAGE name &KEY nicknames (USE "CLOE")
	Once you've chosen a package to work from, all calls to an unqualified
	MAKE-PACKAGE do the thing that is natural for that initial package.

This is a current practice statement. Please note it.

    This doesn't work the same; namely, it forces a user to preface his files:
	    (cloe:in-package <mumble> ...)
    rather than:
	    (in-package <mumble> ...)

No. Our USER package uses CLOE, so (IN-PACKAGE ...) [unqualified] calls
CLOE:IN-PACKAGE.

There is a command you can run to say that you would prefer the system not
show you Cloe extensions, so there is no trouble getting the other behavior
for people who want it.

    That is, assuming that CLOE does the reasonable thing of reading the 
    IN-PACKAGE command from the USER package.

There are no restrictions in CLtL about what packages the USER package may use,
what symbols it may shadow, etc.

Anyway, the -important- thing is that LOAD is documented to rebind *PACKAGE*
to its current value. Hence, a safe portable program must -always- say
LISP:IN-PACKAGE (if that's what it intends) just in case the "current value"
of *PACKAGE* is a package which has shadowed IN-PACKAGE to be something which
means nothing like what it means in CLtL... eg, what if *PACKAGE* is the keyword
package when you call LOAD?

    If you have some other default package, then that itself is an imposition
    on at least the same order of magnitude as the proposal for 
    MAKE-PACKAGE-USE-DEFAULT.

Nonsense. The user selects once at the beginning of his session whether he's
working with the Cloe extensions or not. From then on out, everything is
entirely consistent. In general, you have the problem that 

    I see MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT; as the lesser
    of several evils.  As moon said [in msg of  Tue, 11 Oct 88 12:58 EDT]
	"... the issue is whether the default should
	 be a portable way to get the local extensions, or a portable way to
	 get the portable language without the extensions.  I think either of
	 those choices is portable and reasonable, it just depends on what you
	 want to make easier, ..."

I think there should be a portable way to get portable code (ie, the language
without extensions). I don't want to waste -any- time figuring out how people
get to system-dependent stuff. There's already an adequate mechanism for doing
that. And even if there weren't, an extension could be added in a system-dependent
way without wasting any CL designers' time. 

    Now, there may be a separate issue we haven't addressed yet -- just
    what package is current when you load a file?  A "good style" program
    will have an IN-PACKAGE command as the first executable form in the
    file [or, a DEFPACKAGE followed by an IN-PACKAGE ?].  The question is,
    how do you read the IN-PACKAGE itself?   Unfortunately, all 
    implementations I've examined, including Lucid's, just leave you in 
    the current package.

That's because that's what p183 of CLtL says they have to do!

    I believe the "reasonable" thing to do is to 
    rebind *package* to USER; the expectation, of course, is that the
    current package will immediately be changed via IN-PACKAGE.


I strongly disagree. You have no idea what's in USER. Besides, it's gratuitously
incompatible with existing programs, as is your suggestion to change the
meaning of MAKE-PACKAGE with no :USE argument.

    The same issue holds with respect to the CL-Compiler committee's issue
    about what package you start out in when you compile-file a file.  I
    fear that, at the recent x3j13 meeting, we too easily assented to a 
    rebinding of *package* to itself, precisely because we hadn't thought
    through this "separate issue" before.

The compiler committee had thought it through. The ammendment to that
proposal to which we agreed -- my addition of wording saying "to its current
value" -- was exactly to make it consistent with the documented behavior
of LOAD (because we believe most implementations already provide such
consistency).

∂17-Oct-88  2021	CL-Cleanup-mailer 	Issue: HASH-TABLE-GC (no proposal)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Oct 88  20:21:15 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA05581g; Mon, 17 Oct 88 20:20:59 PDT
Received: by bhopal id AA05454g; Mon, 17 Oct 88 20:19:26 PDT
Date: Mon, 17 Oct 88 20:19:26 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810180319.AA05454@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Thu, 13 Oct 88 17:54 EDT <881013175448.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-GC (no proposal)

re: My notes from Fairfax meeting...
     . . . 
     JonL, RWK: Nervous about this because it's "new technology".
     Gregor: It IS implemented -- just not in Lisp. It is NOT new technology.

I still stand by my note of caution -- meaning I would oppose any such
item being included in the standard as early as January 1989.

Although several other languages have something vaguely reminiscent of what 
has been talked about for so long on the Common-Lisp mailing list, there is 
no justification at all for claiming that they set precedent for Common Lisp.
There are just too many differences as to what a "garbage collector" is, and 
what a "hash table" is, and what a "weak pointer" is.  [Not sure I used just
the bare word "technology", but was implying that this is new and non-obvious 
for Common Lisp].

In particular, Cedar's "finalization" technology is heavily involved with 
its reference counting garbage collector [or, "used to be" -- my reference 
is circa 1984].  Many commercial Common Lisps do not in fact "collect" the 
garbage, but instead  "abandon" the garbage by copying the living structure.
There are ways out, but they are by no means easy choices.

Similarly, whether "weakness" should be expressed as a property of
   (1) hash-table keys
   (2) locative properties
   (3) attribute properties [a la Pop11?]
is a crucial question.  For example, the consistency of what MAPHASH
will find is in question if (1) is chosen; and serious implementational
questions arise if "weakness" is to be ascribable to any old random 
SETF'able place.

Note that PDP10 MacLisp had "weak" tables for interned symbols back in 
the early 1970's;  what it didn't have was a user-extensible notion of 
"weakness", and that is the point of this (non-) proposal.

What this (non-) proposal needs is some implementation to give it a try,
based on an indentified, actual need.  [Please, no suggestions as to what 
someone "might need" -- there's been a surfeit of that on the CL mailing
list already].  At the CLOS symposium, I heard one case of "actual need" 
that could be satisfied by a very minimal version of (1) above.  I called 
that situation a "cache table" in that it was a hash-table used as a kind 
of performance accelerator; at any time, any element in the table may be 
randomly deleted, and no program operation other than speed is affected.

Anyone else know of other "actual needs"?


-- JonL --

∂17-Oct-88  2130	CL-Cleanup-mailer 	Issue: HASH-TABLE-GC (no proposal)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Oct 88  21:30:08 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 477822; Tue 18-Oct-88 00:29:57 EDT
Date: Tue, 18 Oct 88 00:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-GC (no proposal)
To: Jon L White <jonl@lucid.com>
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8810180319.AA05454@bhopal>
Message-ID: <19881018042934.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 17 Oct 88 20:19:26 PDT
    From: Jon L White <jonl@lucid.com>

    ....
    What this (non-) proposal needs is some implementation to give it a try,
    based on an indentified, actual need.

In Genera we've experimented with weak-key hash tables.  The identified,
actual need was internal to Statice (an object-oriented database
system).  I don't think this form of tables has been released yet.

I agree that it would be premature to standardize on something like this
this year.

∂17-Oct-88  2349	CL-Cleanup-mailer 	Issue: HASH-TABLE-GC (no proposal)  
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Oct 88  23:49:22 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA09626@EDDIE.MIT.EDU>; Tue, 18 Oct 88 02:48:44 EDT
Received: by spt.entity.com (smail2.5); 18 Oct 88 01:51:18 EDT (Tue)
To: jonl@lucid.com
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Jon L White's message of Mon, 17 Oct 88 20:19:26 PDT <8810180319.AA05454@bhopal>
Subject: Issue: HASH-TABLE-GC (no proposal)
Message-Id: <8810180151.AA17376@spt.entity.com>
Date: 18 Oct 88 01:51:18 EDT (Tue)
From: gz@spt.entity.com (Gail Zacharias)

   Date: Mon, 17 Oct 88 20:19:26 PDT
   From: Jon L White <jonl@lucid.com>

   Anyone else know of other "actual needs"?

We've implemented "weak" sets (populations?); the motivating "actual need" was
keeping track of buffer marks in the editor.  There are other uses, mostly of
the same form (i.e.  keep track of sets of objects which need to be updated
and kept in synch with some other data structure, provided they are otherwise
accessible).  We don't have any actual uses for weak hash tables so far, but
are considering using them for maintaining some auxillary debugging info.

None of this has been released to users yet, though we will almost certainly
have some form of user-accessible weak data structures (at least weak sets,
possibly weak hash tables) in a future release.  I think this is one of those
cases where a typical user might not even realize that such objects are
possible and just naturally structure his algorithms (possibly non-optimally)
in such a way as to not need them.  So in a way asking for "actual need"
before they are available is not entirely fair...

∂18-Oct-88  0841	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 18 Oct 88  08:40:52 PDT
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA29861; Tue, 18 Oct 88 09:40:15 MDT
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA22872; Tue, 18 Oct 88 09:40:04 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810181540.AA22872@defun.utah.edu>
Date: Tue, 18 Oct 88 09:40:02 MDT
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
To: Dan L. Pierson <pierson%mist@MULTIMAX.ENCORE.COM>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Dan L. Pierson <pierson%mist@multimax.ARPA>, Mon, 17 Oct 88 16:13:42 EDT

This looks better, but I feel really uncomfortable with the idea that
an implementation would be allowed to decide on its own that modules
which haven't been PROVIDE'd have been loaded anyway.  If I say
(REQUIRE "foo") and if I haven't done a (PROVIDE "foo"), I want to get
an error.  I don't want the implementation to decide on its own that
module "foo" has been loaded just because I've loaded a file named
"foo", for example.  The file named "foo" might contain only part of
the module "foo", or it might contain the system definition (defined
using some variant of DEFSYSTEM) for module "foo", or it might contain
something else entirely.

-Sandra
-------

∂18-Oct-88  0852	CL-Cleanup-mailer 	Re: issue HASH-TABLE-PRINTED-REPRESENTATION   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 18 Oct 88  08:49:48 PDT
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA00134; Tue, 18 Oct 88 09:44:25 MDT
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA22878; Tue, 18 Oct 88 09:42:21 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810181542.AA22878@defun.utah.edu>
Date: Tue, 18 Oct 88 09:42:19 MDT
Subject: Re: issue HASH-TABLE-PRINTED-REPRESENTATION
To: Jon L White <jonl@lucid.com>
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs,
        cl-cleanup@sail.stanford.edu
In-Reply-To: Jon L White <jonl@lucid.com>, Mon, 17 Oct 88 17:13:49 PDT

Thinking about this some more, perhaps keyword options would be better
after all.  I don't have really strong feelings on it.

-Sandra
-------

∂18-Oct-88  0910	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 18 Oct 88  09:10:01 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA09562; Tue, 18 Oct 88 12:09:08 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA13058; Tue, 18 Oct 88 12:13:05 EDT
Message-Id: <8810181613.AA13058@mist.UUCP>
To: "sandra%defun@cs.utah.edu"@multimax (Sandra J Loosemore)
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
In-Reply-To: Your message of Tue, 18 Oct 88 09:40:02 -0600.
             <8810181540.AA22872@defun.utah.edu> 
Date: Tue, 18 Oct 88 12:13:03 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    This looks better, but I feel really uncomfortable with the idea that
    an implementation would be allowed to decide on its own that modules
    which haven't been PROVIDE'd have been loaded anyway.  If I say
    (REQUIRE "foo") and if I haven't done a (PROVIDE "foo"), I want to get
    an error.  I don't want the implementation to decide on its own that
    module "foo" has been loaded just because I've loaded a file named
    "foo", for example.  The file named "foo" might contain only part of
    the module "foo", or it might contain the system definition (defined
    using some variant of DEFSYSTEM) for module "foo", or it might contain
    something else entirely.
    
I was thinking similar thoughts while writing the rationale.  If the
person who requested this feature (JonL?) doesn't come up with a
convincing defense soon, I'll probably remove it.

∂18-Oct-88  0928	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-GC (no proposal)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 18 Oct 88  09:28:27 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 18 OCT 88 09:28:06 PDT
Date: Tue, 18 Oct 88 09:27 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: HASH-TABLE-GC (no proposal)
To: Jon L White <jonl@lucid.com>
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <8810180319.AA05454@bhopal>
Message-ID: <19881018162709.1.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no

    Date: Mon, 17 Oct 88 20:19:26 PDT
    From: Jon L White <jonl@lucid.com>

    Anyone else know of other "actual needs"?

Network Resource management like in X implementations.
-------

∂18-Oct-88  0953	CL-Cleanup-mailer 	Fairfax notes   
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 18 Oct 88  09:52:51 PDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Tue, 18 Oct 88 12:54:59 EDT
Received: by joplin.think.com; Tue, 18 Oct 88 12:51:07 EDT
Date: Tue, 18 Oct 88 12:51:07 EDT
From: gls@Think.COM
Message-Id: <8810181651.AA00751@joplin.think.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: cl-cleanup@sail.stanford.edu
Subject: Fairfax notes

Thanks for all the work you obviously put into writing
up all those issues notes.  I'm sure they will prove
very helpful over the next several weeks.
--Guy

∂18-Oct-88  1020	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 18 Oct 88  10:19:51 PDT
Received: by ti.com id AA08910; Tue, 18 Oct 88 12:19:33 CDT
Received: from Kelvin by tilde id AA13138; Tue, 18 Oct 88 12:15:01 CDT
Message-Id: <2802186955-10350987@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 18 Oct 88  12:15:55 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: "Dan L. Pierson" <pierson%mist@multimax.ARPA>
Cc: CL-Cleanup@SAIL.Stanford.edu, sandra%defun@cs.utah.edu,
        Bartley@MIPS.csc.ti.com
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
In-Reply-To: Msg of Mon, 17 Oct 88 16:13:42 EDT from Dan L. Pierson <pierson%mist@multimax.ARPA>

>     The REQUIRE function tests whether a module is already present
>     (using a case-sensitive comparison); if the module is not present,
>     REQUIRE signals a correctable error of type REQUIRE-ERROR.
>     This gives the user the opportunity to load the appropriate files
>     from the debugger before continuing.

Is this saying that it is not appropriate for the system to load the
necessary files automatically if it knows how?  I agree that there is no
hope of trying to standardize on something like DEFSYSTEM, but it should
be possible (and encouraged) that REQUIRE be a standard interface to
load a group of files that has been specified in some
implementation-dependent way.  Signalling a correctable error for the
user to do something is appropriate if no definition of the module is
available.

I liked the specification of the interaction between LOAD and PROVIDE
that was included in version 2 but has been removed from version 3.  I
think that JonL's objections to a "lying PROVIDE" might be satisfied by
clarifying that the temporary behavior relates only to the relation
between PROVIDE and REQUIRE, and the user-visible *MODULES* list is not
actually updated until LOAD reaches the end of the file containing the
PROVIDE.

If this approach is not adopted, the the proposal needs to specify
instead a change to the specification currently on pages 189 and 191 of
CLtL to say that PROVIDE should be at the end of the file instead of the
beginning.

∂18-Oct-88  1025	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 18 Oct 88  10:25:38 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA00302; Tue, 18 Oct 88 13:24:33 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA13169; Tue, 18 Oct 88 13:28:29 EDT
Message-Id: <8810181728.AA13169@mist.UUCP>
To: David N Gray <Gray%DSG.csc.ti.com@multimax>
Cc: CL-Cleanup%SAIL.Stanford.edu@multimax, sandra%defun%cs.utah.edu@multimax
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
In-Reply-To: Your message of Tue, 18 Oct 88 12:15:55 -0500.
             <2802186955-10350987@Kelvin> 
Date: Tue, 18 Oct 88 13:28:20 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

We decided at the cleanup meeting last week to separate the REQUIRE
second argument issue from the issue of where to put PROVIDE.  Since
there seemed to a strong split in the committee with a lot of
sentiment toward not mandating either solution for the PROVIDE
question, I haven't written a proposal for that part.  Please feel
free to write one if you wish, I'd suggest PROVIDE-LOCATION as the
issue name.

∂18-Oct-88  1042	CL-Cleanup-mailer 	Issue: HASH-TABLE-GC (no proposal)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Oct 88  10:42:37 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 478063; Tue 18-Oct-88 13:42:16 EDT
Date: Tue, 18 Oct 88 13:42 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-GC (no proposal)
To: JonL@lucid.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8810180319.AA05454@bhopal>
Message-ID: <881018134206.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Mon, 17 Oct 88 20:19:26 PDT
    From: Jon L White <jonl@lucid.com>

    ... Anyone else know of other "actual needs"?

I run into cases all the time where these would be useful. Here are a few...

 - My portable error system needed weak hash tables for unique ids
   in printing (in order to simulate MAKNUM in a portable, reliable way).

 - In my work with Cloe (internally at Symbolics), I've had need to
   record various kinds of attribute information about non-symbols.
   An example is the keeping of :ADJUSTABLE information in the Cloe
   development environment (since Genera doesn't represent that info
   explicitly and some users want to be able to have ADJUST-ARRAY
   do error checking anyway).

 - Also internally to Cloe, before I'd worked out a way to have
   funcallable things with slots, I had hash tables from function
   objects to another structure which had the slots. The function was
   also closed over the structure with slots, so it didn't go through
   the hash table, but the hash table was important in debugging.

All of these items need hash table with weak key links only.
All of these items cause the accumulation of massive amounts of
garbage over time with no (semantically valid) hope of recovery
in the absence of weak hash tables.

It is especially important to provide an abstraction for dealing with
this kind of thing in a portable language because often the problems
are caused by portability. That is, most of these problems can be solved
within an implementation by ways better than weak hash tables. Eg, -- if
I knew all kinds of useful stuff about the internals of the Lisp in
question -- I would just implement MAKNUM, add an extra bit in arrays,
or make a new data type for generic functions. That being the case,
there is far less motivation to -ever- develop weak hash tables in any
given implementation.

Yet problems that demand this sort of solution continue to hit people
who have no access to such low-level/bit-twiddly solutions. So I agree
with GZ that it's a little unfair to ask who has a use without first
providing it. For all we know, lots of hash tables in use today could
be needless storage hogs because programmers really wanted weak tables
and couldn't find them -- and were willing to pay the storage penalty
of using normal hash tables because the application was so important.

There may be some little details to attend to, but abstractly the idea
of a table with weak key links is both simple and powerful. I think we
should look at the idea quite seriously. The question I have for those
who think it's premature to do this is: what is the worst case scenario
you can imagine for introducing this feature prematurely? Are you
envisioning a feature that is hard/expensive to implement? unreliable
in some way I'm not thinking about?  turns out to not be something
people want? Are the objections technical, economic, cultural ... or
superstitious?

∂18-Oct-88  1113	CL-Cleanup-mailer 	Issue: HASH-TABLE-GC (no proposal)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Oct 88  11:13:28 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 478088; Tue 18-Oct-88 14:12:36 EDT
Date: Tue, 18 Oct 88 14:12 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-GC (no proposal)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: JonL@lucid.com, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881018134206.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881018181211.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 18 Oct 88 13:42 EDT
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

    There may be some little details to attend to, but abstractly the idea
    of a table with weak key links is both simple and powerful. I think we
    should look at the idea quite seriously. The question I have for those
    who think it's premature to do this is: what is the worst case scenario
    you can imagine for introducing this feature prematurely? 

If it's this particular feature, not too bad.  There seemed to be a good
deal of confusion or disagreement about exactly what feature we were
really talking about, how to define "weak" in a portable way, whether to
include finalization also, etc.  It's all that ill-definedness that
bothers me.  The standard might end up being defined in a way that is so
implementation dependent that it's very difficult for anyone but its
author to implement.  Alternatively, the standard might be so vague as
to be meaningless.

							      Are you
    envisioning a feature that is hard/expensive to implement? unreliable
    in some way I'm not thinking about?  turns out to not be something
    people want? Are the objections technical, economic, cultural ... or
    superstitious?

Perhaps my objections are more to the (envisioned) process than to the product.
If there was a concensus in the community as to what feature we were
talking about, and how to define it portably, then assuming it wasn't
unduly expensive to implement (which I think should not be a problem,
although I'm not familiar with the internals of many implementations)
and that it was not a burden for users (which ought to go without saying,
no incompatible change should be involved), then I wouldn't think it
was premature.  So maybe I'm worrying unduly.  But it's very late in
the X3J13 process.  The practical alternative is likely to be a few
Lisp vendors setting a de facto standard.

∂18-Oct-88  1138	CL-Cleanup-mailer 	Issue: TAILP-NIL (version 3)   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 18 Oct 88  11:37:42 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA01883; Tue, 19 Apr 88 19:33:14 PDT
Date: Tue, 19 Apr 88 19:33:14 PDT
Message-Id: <8804200233.AA01883@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: TAILP-NIL (version 3)

Issue:		TAILP-NIL
References:	TAILP (p275)
Category:	CLARIFICATION/CHANGE
Edit History:	13-Sep-88, version 1 by Walter van Roggen,
		13-Sep-88, version 2 by Pitman
                18-Oct-88, version 3 by van Roggen (just one proposal)
 
Problem Description:
 
  CLtL (p275) specifies TAILP as:
 
    TAILP sublist list				[Function]
 
    This predicate is true if SUBLIST is a sublist of LIST (i.e.,
    one of the conses that makes up LIST); otherwise, it is false.
    Another way to look at this is that TAILP is true if
    (NTHCDR n list) is SUBLIST, for some value of N. See LDIFF.
 
  Two common implementations of this definition are:
 
   (defun tailp (sublist list)			;Definition "A"
     (do ((list list (cdr list)))
	 ((endp list) nil)
       (if (eq sublist list)
	   (return t))))
 
   (defun tailp (sublist list)			;Definition "B"
     (do ((list list (cdr list)))
	 ((atom list) (eq list sublist))
       (if (eq sublist list)
	   (return t))))
 
  They differ only in their treatment of the atomic case.
 
  At issue is the fact that () is a list, and hence some would
  argue that it is a sublist of all other lists. On the other hand,
  the definition of TAILP seems to imply that being a cons is a
  necessary precondition of being a "sublist".

Proposal (TAILP-NIL:T):
 
  Strike any text in the definition of TAILP which suggests that a
  sublist must be a cons.
 
  Clarify that (TAILP any-atom list) returns T iff (NTHCDR n list) is
  SUBLIST for some value of N, and false otherwise.
 
Rationale:
 
  This is more consistent with the definition of LDIFF, which
  gives a useful meaning to arbitrary atomic SUBLIST arguments.
 
  This gives a more elegant definition of SUBLIST, allowing it to
  refer to any list -- including the empty list -- which is a
  part of another list.
 
Test Cases:
 
 #1: (LET ((X '(B C))) (TAILP X (CONS 'A X)))
     should return T in all implementations.
 
 #2: (TAILP '(X Y) '(A B C))
     should return NIL in all implementations.
 
 #3: (TAILP '() '(A B C))
     returns NIL under proposal TAILP-NIL:NIL
     returns T   under proposal TAILP-NIL:T
 
 #4: (TAILP 3 '(A B C))
     is an error under proposal TAILP-NIL:NIL
     returns NIL under proposal TAILP-NIL:T
 
 #5: (TAILP 3 '(A B C . 3))
     is an error under proposal TAILP-NIL:NIL
     returns T under proposal TAILP-NIL:T
 
 #6: (TAILP '(X Y) '(A B C . 3))
     is an error under proposal TAILP-NIL:NIL
     returns NIL under proposal TAILP-NIL:T
 
Current Practice:
 
  Symbolics Genera is consistent with TAILP-NIL:T.  VAX LISP implements
  TAILP-NIL:NIL.
 
Cost to Implementors:
 
  An implementation of TAILP-NIL:T is given as Definition "B" in the
  problem description.
 
  Some implementations might have compiler optimizers for these definitions
  as well, so a slight amount of additional effort might be required.
 
Cost to Users:
 
  Given that current practice varies widely on the disputed case,
  this is unlikely to have a practical effect on existing portable code.
 
Benefits:
 
  Avoids unnecessary incompatibilities between implementations.
 
Discussion:
 
  This issue was first raised in ">GLS>clarifications.text" of 12/06/85.
  It recommended TAILP-NIL:NIL.

∂18-Oct-88  1148	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Oct 88  11:48:08 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA19864@EDDIE.MIT.EDU>; Tue, 18 Oct 88 14:46:54 EDT
Received: by spt.entity.com (smail2.5); 18 Oct 88 13:51:04 EDT (Tue)
To: sandra%defun@cs.utah.edu
Cc: pierson%mist@MULTIMAX.ENCORE.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 18 Oct 88 09:40:02 MDT <8810181540.AA22872@defun.utah.edu>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
Message-Id: <8810181351.AA19036@spt.entity.com>
Date: 18 Oct 88 13:51:04 EDT (Tue)
From: gz@spt.entity.com (Gail Zacharias)

Coral currently "decides that a module has been provided" if the module has
been loaded as the result of a previous REQUIRE or is in the process of being
loaded as the result of a REQUIRE.  This mode of operation has the advantage
of making it possible to handle both aborted loads and recursive dependencies
correctly.  I realize that the concept of "loaded as the result of a REQUIRE"
is less clear with the current proposal, but I'm not convinced that it becomes
entirely meaningless and would not want to disallow these sorts of extensions
out of hand.

If (PROVIDE x) can't be anything but (push x *modules*) and (REQUIRE x) can't
be anything but (or (member x *modules*) (error 'require-error x)), what's the
point of putting these two functions in the language?  Users can just be told
that one neato way of specifying interdependencies is by pushing things on a
variable called *modules*.  I don't see any point in having PROVIDE/REQUIRE if
nothing magical is allowed to happen and if users have to write their own
system-loading functions even in the simplest cases.  They just take up two
nice names that users might be able to put to a better use.

∂18-Oct-88  1159	CL-Cleanup-mailer 	Issue: HASH-TABLE-GC (no proposal)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 18 Oct 88  11:59:17 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA06074g; Tue, 18 Oct 88 11:55:44 PDT
Received: by bhopal id AA01089g; Tue, 18 Oct 88 11:54:10 PDT
Date: Tue, 18 Oct 88 11:54:10 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810181854.AA01089@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: Gregor.pa@Xerox.COM, gz@spt.entity.com, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: David A. Moon's message of Tue, 18 Oct 88 00:29 EDT <19881018042934.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-GC (no proposal)

re: Date: Tue, 18 Oct 88 00:29 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    . . . 
    In Genera ... The identified, actual need was internal to Statice 
     (an object-oriented database system).  ...

The "actual need" identified at the CLOS symposium was Larry Rowe's
object-oriented database work Picasso -- the management of "in-core
handles" for external, database stored objects.  I'd hazard a guess
that the Statice need was basically the same, namely a need for
"cache tables".  Probably Gregor's suggestion for "Network Resource
management like in X implementations" would fall into the same class,
as would Gail's mention of "maintaining some auxillary debugging info".


re: Date: Tue, 18 Oct 88 13:42 EDT
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
    . . . 
     - My portable error system needed weak hash tables for unique ids
       in printing (in order to simulate MAKNUM in a portable, reliable way).

     - In my work with Cloe (internally at Symbolics), I've had need to
       record various kinds of attribute information about non-symbols.
       An example is the keeping of :ADJUSTABLE information in the Cloe
       development environment (since Genera doesn't represent that info
       explicitly and some users want to be able to have ADJUST-ARRAY
       do error checking anyway).

     - [third case similar to second -- JonL]

This looks more like a need for attribute properties rather than for
"cache tables";  I'm not sure of how you, and others (such as pop11),
would use them, but it probably would be unacceptable for "lightening"
to strike haphazardly and delete random entries (as "cache tables" were
so graphically characterized).  Likely, Gail's mention of "keeping track
of editor marks" falls into this class.  Perhaps Dalton can shed some more 
light on the dynamics of such properties?

Incidentally, the design of VAX/NIL had to encompass a MAKNUM for
MacLisp compatibility; and we more-or-less talked ourselves into
believing that a single "unique id" table, specially handled by the
garbage collector, was satisfactory for all such usages.  That is, 
any desired "weak property" could be hung off the unique-id slot;
and all such properties would "go away" when the object was GC'd.
[See P.S. below about MacLisp semantics.]


In response to Gail and Kent's comment that it is unfair to ask for
"actual need" situations:  this question is motivated by the prospect 
of including such a feature in the upcoming standardard, not in regard
to any implementor's design.  In fact, my msg explicitly suggested that
standardization should come only after some implementation's lead in 
utilization.  I firmly believe in vendors making innovative extensions 
to the standard.

The meta point in this discussion is the "why" we are assembled into 
X3J13.  I call it the Moon-Gabriel-Weinreb-White viewpoint, that we
are standardizing an old, existing language -- not designing a new 
language without regard to an existing community of users.  Common Lisp
is the culmination of 30 years of Lisp development for AI research and 
commercial use; other dialects of Lisp are newer, and do better serve 
the purposes of Programming Language research.  There is certainly 
room in X3J13 Common Lisp for incompatible changes and novel additions;
but we simply should be MUCH MORE conservative about the speed of 
acceptance of these than we are about, say, fixing up clear ambiguities 
in our former understanding and extending the unfinished work that was 
overdue even in 1981 when the unification movement began [i.e., object-
oriented-programming/Flavors, Iteration/LOOP, Windows(sigh) and 
Compilation Semantics].

Hence, I look forward to "weak" tables etc in Common Lisp, but not
in January 1989.



-- JonL --



P.S. Reminder for those not familiar with MAKNUM -- since pdp10 MacLisp
     had a "collecting, non-relocating" garbage collector, the address 
     of any object was it's unique id; but for implementations using some
     form of copying garbage collector, either an extra slot in each 
     object had to be reserved for this purpose, or else some kind of 
     "weak" property table had to be maintained by the GC.  I think 
     Multics MacLisp had a special table for MAKNUM, but maybe entries 
     never got deleted; Moon may remember.

∂18-Oct-88  1218	CL-Cleanup-mailer 	Issue: TAILP-NIL (version 3)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Oct 88  12:17:53 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 478149; Tue 18-Oct-88 15:17:34 EDT
Date: Tue, 18 Oct 88 15:17 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL (version 3)
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8804200233.AA01883@decwrl.dec.com>
Message-ID: <881018151727.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

as you might expect, i support this writeup and the stated
proposal (TAILP-NIL:T).

do i take it from the fact that you removed the NIL proposal that you
also endorse it? your writeup is devoid of recommendations in the
Discussion.

∂18-Oct-88  1220	CL-Cleanup-mailer 	Re: Issue: TAGBODY-CONTENTS    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 18 Oct 88  12:19:59 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA04253; Tue, 19 Apr 88 20:15:23 PDT
Date: Tue, 19 Apr 88 20:15:23 PDT
Message-Id: <8804200315.AA04253@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: TAGBODY-CONTENTS

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

∂18-Oct-88  1224	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 18 Oct 88  12:24:32 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA01977; Tue, 18 Oct 88 15:23:34 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA13501; Tue, 18 Oct 88 15:27:29 EDT
Message-Id: <8810181927.AA13501@mist.UUCP>
To: gz%spt.entity.com@multimax (Gail Zacharias)
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
In-Reply-To: Your message of Tue, 18 Oct 88 13:51:04 -0400.
             <8810181351.AA19036@spt.entity.com> 
Date: Tue, 18 Oct 88 15:27:25 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    If (PROVIDE x) can't be anything but (push x *modules*) and
    (REQUIRE x) can't be anything but (or (member x *modules*) (error
    'require-error x)), what's the point of putting these two
    functions in the language?  Users can just be told that one neato
    way of specifying interdependencies is by pushing things on a
    variable called *modules*.  I don't see any point in having
    PROVIDE/REQUIRE if nothing magical is allowed to happen and if
    users have to write their own system-loading functions even in the
    simplest cases.  They just take up two nice names that users might
    be able to put to a better use.

The first proposal _was_ to just remove these from the language.  JonL
convinced several of us that this shouldn't be done because the
functions are useful as a safety net behind a real defsystem
facility.  If we can't agree on the stripped versions of PROVIDE and
REQUIRE, the total removal proposal will probably resurface because
the current definitions simply aren't portable and can't be made
portable without a lot more environment definition that anyone seems
willing to mandate.

Personally, I totally oppose any proposal that makes PROVIDE and
REQUIRE only work if all of your files are in the same directory; most
systems have tree-structured directories, they're there for a reason,
and large systems (the type that most need this feature) need to have
their sources distributed across multiple directories.

By the way, the proposed definition of REQUIRE is closer to:

 (or (member x *modules*) (cerror 'require-error x))

∂18-Oct-88  1225	CL-Cleanup-mailer 	RE: Issue: TAILP-NIL (version 3)    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 18 Oct 88  12:25:31 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA04896; Tue, 19 Apr 88 20:20:17 PDT
Date: Tue, 19 Apr 88 20:20:17 PDT
Message-Id: <8804200320.AA04896@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: KMP@stony-brook.scrc.symbolics.com
Subject: RE: Issue: TAILP-NIL (version 3)

Yes, I guess I endorse it also.  Either way was fine with me; I was
just surprised to see the alternate definition after reading the
original proposal both in Guy's clarifications list and in old
Symbolics documentation.

I don't feel justified in writing down recommendations in the Discussion
section unless I've heard from "enough" people.  So far most people seem
to have stayed away from this issue, as well as many others.

			---Walter

∂18-Oct-88  1340	CL-Cleanup-mailer 	issue PACKAGE-CLUTTER
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 18 Oct 88  13:39:54 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA06196g; Tue, 18 Oct 88 13:39:47 PDT
Received: by bhopal id AA01190g; Tue, 18 Oct 88 12:31:06 PDT
Date: Tue, 18 Oct 88 12:31:06 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810181931.AA01190@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Thu, 13 Oct 88 15:36:49 MDT <8810132136.AA19912@defun.utah.edu>
Subject: issue PACKAGE-CLUTTER

re: . . . Actually, I would be happy
    with a simple statement that the implementation must not use any
    keywords or external symbols in the Lisp package as indicators on the
    property list of any symbol.  I don't care if the system puts things ...

I like to plead again to please separate the PACKAGE-CLUTTER issue from
the LISP-SYMBOL-REDEFINITION issue.  Walter had a good idea some time
ago to rename PACKAGE-CLUTTER as LISP-PACKAGE-CONTENTS.  Larry has said 
that he would "group together" related issues like this; but I think the 
issue of LISP-PACKAGE-CONTENTS is _critical_ to a portable language, 
whereas the issue of LISP-SYMBOL-REDEFINITION simply helps smooth over 
some minor irritants.  More to the point, the former is at last 
non-controversial, while the latter still boils and stews.


-- JonL --

∂18-Oct-88  1428	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 8) 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 18 Oct 88  14:28:24 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA06265g; Tue, 18 Oct 88 14:28:01 PDT
Received: by bhopal id AA01653g; Tue, 18 Oct 88 14:26:28 PDT
Date: Tue, 18 Oct 88 14:26:28 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810182126.AA01653@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Thu, 13 Oct 88 18:57 EDT <881013185748.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL (Version 8)

re: . . . 
     JonL hadn't studied this enough and had a bunch of questions.
     Maybe we'll get more feedback from him when he's read it more carefully.
    Offline:
     Julian Padgett (I probably got the spelling wrong) said he
     supports the LG proposal. He doesn't like the D stuff getting
     mixed up in there at all.

My problem with this proposal was exactly that attributed to Padgett.
The LG proposal doesn't clearly spell out that it is an error to have 
dynamic bindings for variables declared LEXICAL -- I don't yet see it as
being distinct from the LDG proposal.   If this prohibition were agreed 
upon, then the whole set of issues discussed under the "Cost to 
Implementors" section would be moot, and that section could simply say 
"slight".

I'm just a bit puzzled by the current state of the proposal -- your
comments (KMP's) in the Discussion section indicate that you think it 
already rules out the objectional case:
  Pitman supports PROCLAIM-LEXICAL:LG and believes that giving LDG the
  name LEXICAL would be a serious mistake, leaving open the door for
  program bugs due to accidental binding of variables presumed by the
  programmer not to be bound. If someone (Moon?) seriously wanted LDG
  type variables in addition to LG variables (under a name other than
  LEXICAL), Pitman would not object.
If this is so, then perhaps all we need to do is clarify the wording
of the proposal a bit.


In particular, in the Proposal part, I would change:

  Clarify that dynamic binding does DG lookup.  That is, variables
  declared SPECIAL would be looked up first in the dynamic
  environment (D) and then in the global environment (G) if not found
  in the lexical. Further clarify that SYMBOL-VALUE does DG lookup.

  Define that a dynamic binding of a variable creates a new binding
  in the dynamic environment (D) leaving the global environment (G)
  unaffected.

into:

  Clarify that a dynamic binding of a variable creates a new binding
  in the dynamic environment (D) leaving the global environment (G)
  unaffected.

  Clarify that special variable access does DG lookup.  That is, 
  variables declared SPECIAL would be looked up first in the dynamic
  environment (D) and then in the global environment (G) if not found
  in the dynamic one. Further clarify that SYMBOL-VALUE does DG lookup.

And I would change:

  Define that a lexical binding of a variable creates a new binding
  in the lexical environment (L), leaving the global environment (G)
  unaffected.

into:

  Define that a lexical binding of a variable creates a new binding
  in the lexical environment (L), leaving the global environment (G)
  and the dynamic environment (D) unaffected.

Furthermore, I would ammended the Discussion section to explain the remark:

  JonL expressed concerns about the last-minute nature of this change,
  which he sees as untested.

so that the "last-minute" is clearly seen to be referring to the mixin of 
the dynamic environment implicit in the LDG proposal.


I have long favored the approach that permitted LEXICAL proclamation to
mean basically what QLISP's GLOBAL proclamation does.   I think LEXICAL 
would also permit local lexical bindings, whereas GLOBAL doesn't, but 
that isn't important; flushing the dynamic mixin is what I'd like to see.



-- JonL --



∂18-Oct-88  1448	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 8) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Oct 88  14:48:25 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 478250; Tue 18-Oct-88 17:48:10 EDT
Date: Tue, 18 Oct 88 17:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL (Version 8)
To: jonl@lucid.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8810182126.AA01653@bhopal>
Message-ID: <881018174804.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Tue, 18 Oct 88 14:26:28 PDT
    From: Jon L White <jonl@lucid.com>

    ... The LG proposal doesn't clearly spell out that it is an error to have 
    dynamic bindings for variables declared LEXICAL -- I don't yet see it as
    being distinct from the LDG proposal.

It isn't distinct if you prohibit such bindings. But it's gratuitous to
do so, in my opinion.

If by variable you mean variable name, it is not an error to have a
dynamic binding for a variable whose name has been proclaimed lexical.
Nor is it an error to have a lexical binding of a variable whose name
has been proclaimed special. That's what example 2 illustrates.  A
stripped down version is:

 (PROCLAIM '(LEXICAL X))
 (PROCLAIM '(SPECIAL Y))

 (SETQ X 1 Y 2)

 (DEFUN FOO (X Y)
   (DECLARE (SPECIAL X) (LEXICAL Y))
   (LIST X (LOCALLY (DECLARE (LEXICAL X)) X)
         Y (LOCALLY (DECLARE (SPECIAL Y)) Y)))

 (FOO 3 4) => (3 1 4 2)				;LG

    In particular, in the Proposal part, I would change:

      Clarify that dynamic binding does DG lookup.  That is, variables
      declared SPECIAL would be looked up first in the dynamic
      environment (D) and then in the global environment (G) if not found
      in the lexical. Further clarify that SYMBOL-VALUE does DG lookup.

If this is really out of the proposal; it has a typo. "lexical" in the
last line should be "dynamic".

I will ammend the proposal to make some of this clear. At that time I'll
review your wording changes in more detail and if they look good, I'll
merge them.

Your message was a bit rambly and so I had trouble extracting a `bottom
line.' Am I to mark you as favoring LG over LDG (in the Discussion)?

∂18-Oct-88  1456	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 2)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 18 Oct 88  14:51:27 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA06295g; Tue, 18 Oct 88 14:51:18 PDT
Received: by bhopal id AA01791g; Tue, 18 Oct 88 14:49:45 PDT
Date: Tue, 18 Oct 88 14:49:45 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810182149.AA01791@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Thu, 13 Oct 88 19:06 EDT <881013190628.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 2)

re:  I (KMP) made a note to myself about the fact that we shouldn't encourage
     people to add optional arguments to things -- maybe we should have a 
     policy that vendor extensions to arguments must be by keyword to help 
     avoid and/or detect portability conflicts.

Sounds like good advice.  But the situation re REQUIRE is a bit thornier
since the proposal is to make the incompatible change of flushing the
&optional argument.  I had imagined that Lucid's implementation would
accommodate to this merely by "doing nothing" (except retracting a
bit of documentation); this is so that those few souls here at Lucid
that actually use the second argument wouldn't be inconvenienced.

If your "good advice" about extending a standardized argument spectrum
is adopted seriously, then I don't suppose it would really pose a hardship
on these "few souls" at Lucid to modify their code.


-- JonL --

∂18-Oct-88  1539	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 18 Oct 88  15:39:17 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 18 OCT 88 14:23:05 PDT
Date: 18 Oct 88 14:13 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
In-reply-to: Dan L. Pierson <pierson%mist@MULTIMAX.ENCORE.COM>'s message of
 Tue, 18 Oct 88 15:27:25 EDT
To: Dan L. Pierson <pierson%mist@MULTIMAX.ENCORE.COM>
cc: gz%spt.entity.com@MULTIMAX.ENCORE.COM (Gail Zacharias),
 cl-cleanup@sail.stanford.edu
Message-ID: <881018-142305-5087@Xerox>

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.


∂18-Oct-88  1541	CL-Cleanup-mailer 	DRAFT Issue: SYMBOL-MACROLET-DECLARE (version 1)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 18 Oct 88  15:41:45 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA06396g; Tue, 18 Oct 88 15:41:37 PDT
Received: by bhopal id AA02072g; Tue, 18 Oct 88 15:40:02 PDT
Date: Tue, 18 Oct 88 15:40:02 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810182240.AA02072@bhopal>
To: cl-cleanup@sail.stanford.edu
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 8 Oct 88 21:58 PDT <881008-215806-2579@Xerox>
Subject: DRAFT Issue: SYMBOL-MACROLET-DECLARE (version 1)

This issue should be folded into SYMBOL-MACROLET-SEMANTICS; it would be
hardly one line in the descripton of SYMBOL-MACROLET as a special form.
Since it looks like SYMBOL-MACROLET-SEMANTICS is not very controversial
anymore, I see no reason to support separate proposals.

-- JonL --

∂18-Oct-88  1722	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-GC (no proposal)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 18 Oct 88  17:18:14 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 18 OCT 88 17:17:59 PDT
Date: 18 Oct 88 17:17 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: HASH-TABLE-GC (no proposal)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Tue, 18 Oct 88 13:42 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: JonL@lucid.com, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881018-171759-5382@Xerox>

There are two proposals being discussed her:

One proposal is to require "finalization" of some sort: some way to call a
user-written function when an object is "about" to be GC'd. The other,
which is implementable in terms of the first, is just to have hash tables
where entries are deletable when the keys are otherwise GCd. 

There are some problems which can be solved by either mechanism, and others
which need one or the other.

I think the hash-table-key-gc problem is compatible with a wide variety of
implementations and GC mechanisms. Since CL makes few requirements on
"garbage collection", this can be viewed as a "declaration" issue... I want
a way to declare that I will never care about keys disappearing when I call
MAPHASH in exchange for the possibility that the pointers can go away.

I think that finalization is difficult for some classes and implementations
of GCs, but still a "good idea".

I think we should write up both of these as "optional" and then decide what
we're going to do with "optional" features. I also don't see it as
necessary for the first draft of the ANSI standard, but perhaps I'm wrong.

∂18-Oct-88  2146	CL-Cleanup-mailer 	DRAFT Issue: TEST-NOT-IF-NOT (Version 2) 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 18 Oct 88  21:46:16 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA06569g; Tue, 18 Oct 88 21:46:10 PDT
Received: by bhopal id AA03592g; Tue, 18 Oct 88 21:44:37 PDT
Date: Tue, 18 Oct 88 21:44:37 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810190444.AA03592@bhopal>
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 8 Oct 88 22:07 PDT <881008-220711-2583@Xerox>
Subject: DRAFT Issue: TEST-NOT-IF-NOT (Version 2)

Several others have already expressed my sentiments towards this proposal --
that it would have been a nice idea five years ago, but is a gratuitous
incompatibility now.  "Gratuitous", because lots of uses will have to
worry about whether or not their code needs to be massaged, and the
_payback_ to them will be insignificant.

It would certainly be acceptable to "deprecate" the use of any ...-IF-NOT
function, and of the :TEST-NOT keyword argument; this ought to be an 
editorial discretion, rather than requireing lots of cl-cleanup time.


-- JonL --

∂19-Oct-88  1153	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 6)
Received: from void.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Oct 88  11:53:41 PDT
Received: by void.ai.mit.edu (5.59/1.5)
	id AA01461; Wed, 19 Oct 88 14:56:28 EDT
Date: Wed, 19 Oct 88 14:56:28 EDT
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8810191856.AA01461@void.ai.mit.edu>
To: cl-cleanup@sail.stanford.edu
In-Reply-To: System Files's message of 06 Oct 88  2007 PDT <OnAwy@SAIL.Stanford.EDU>
Subject: Issue: DECLARE-TYPE-FREE (Version 6)
Reply-To: jar@zurich.ai.mit.edu

I can't figure out at all what DECLARE-TYPE-FREE:ALLOW is supposed to mean.

    From: Masinter.PA@Xerox.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM
    Subject: Issue: DECLARE-TYPE-FREE (Version 6)
    To: X3J13@SAIL.Stanford.EDU

[A]   ... Clarify that a type
      declaration means that it is an error for the value of the variable not
      to be a member of the declared type, within the scope of the declaration.

[B]   Clarify that the above programs are valid, and that this  kind of 
      declaration means the same thing as wrapping a THE form around every 
      reference to the variable, including modifying references by setq or
      setf.
      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.

The phrase "within the scope of the declaration" in [A] is in direct
conflict with the explanation that follows [B].  If "scope" means
"lexical scope", then the following would be an error according to [A]
but not according to [B]:

	(let ((x 12) (y 'foo))
	  (flet ((zap () (rotatef x y)))
	    (locally (declare (fixnum x))
	      (zap)
	      (zap)
	      x)))

Here the declaration is violated at the "lexical" point in the program
between the two calls to ZAP.  If "scope" means "dynamic scope", you
still have a problem with

	(let ((x 12) (y 'foo))
	  (flet ((zap ()
		   (rotatef x y)
		   (rotatef x y)))
	    (locally (declare (fixnum x))
	      (zap)
	      x)))

since now there is one point *dynamically* where the declaration is
violated.

In either case, this seems like a tricky thing for a compiler to
attempt to understand, and also pretty tricky for an interpreter (and
in particular, a formal semantics) to enforce.  I would think that
recovering the needed information via data flow would be easier.

Even if you decide to trash definition [A] and go with definition [B],
I would think that you'd additionally want to specify that the
declaration must hold not only at all references and assignments
lexically in the scope of the declaration, but also at the point of
the declaration itself.  Consider the case where the variable is
unreferenced in the body; then the declaration wouldn't tell you a
thing, and e.g. it wouldn't help you with backward flow analysis.  Or
the variable might be referenced, but the declaration might not become
valid until some time a while after the point of the declaration:

	(let ((x 'foo))
	  (flet ((zap () (setq x 17)))
	    (locally (declare (fixnum x))
	      (zap)
	      x)))

Also, what does the declaration mean for non-lexical variables?  Would
it apply dynamically to any dynamic binding or reference in the
dynamic scope of the declaration, or just to the references to the
particular dynamic binding that was in effect at the point of
declaration, or just to lexically apparent references in the lexical
scope of the declaration?

I would strongly oppose the proposal in its current vague form.  I
think I would oppose the proposal in just about any form, because it
makes the semantics of variable references even more hairy than it
already is.  Compilers ought to recover this kind of information from
data flow analysis, assisted if necessary by assertions (e.g. uses of
THE in for-effect positions).

∂19-Oct-88  1243	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 19 Oct 88  12:42:56 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 478745; Wed 19-Oct-88 15:43:05 EDT
Date: Wed, 19 Oct 88 15:42 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-TYPE-FREE (Version 6)
To: jar@zurich.ai.mit.edu
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8810191856.AA01461@void.ai.mit.edu>
Message-ID: <881019154254.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Wed, 19 Oct 88 14:56:28 EDT
    From: jar@void.ai.mit.edu (Jonathan Rees)

    [A]   ... Clarify that a type
	  declaration means that it is an error for the value of the variable not
	  to be a member of the declared type, within the scope of the declaration.

    [B]   Clarify that the above programs are valid, and that this  kind of 
	  declaration means the same thing as wrapping a THE form around every 
	  reference to the variable, including modifying references by setq or
	  setf.
	  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.

If you take "A" to refer to "lexical scope", I see no serious inconsistency here.
Some minor wording to be dealt with. Probably it should say something to the effect
of "...for an access to this variable to occur in the lexical scope and for the
resulting value to not to be of the indicated type".

The point of this declaration was not to enable the creation of a specialized home
for the variable, so technically it's no trouble for non-matching values to come
and go through mechanisms such as you cite below. The point of this declaration was,
rather, to permit operations which occur on the contents of the variable within the
lexical scope to be interestingly optimized. eg,
 (COND ((SYMBOLP X) 
	;; You might wish the compiler could guess this one -- and some compilers
	;; might, but some not.
	(LOCALLY (DECLARE (SYMBOL X))
	  (STRING X))) ;Could presumably compile down to (SYMBOL-NAME X).
       ((PRIME-INTEGER-P X)
	;; I hope you wouldn't expect a compiler to ever guess this one.
	(LOCALLY (DECLARE (INTEGER X))
	  (ZEROP (- X 7)))) ;Could presumably compile down to (EQL (- X 7) 0)
       ((AND (PATHNAMEP X) (FROBBABLE X))
        ;; Again I hope you wouldn't expect a compiler to ever guess this one.
	;; Maybe FROB-PATHNAME only returns a PATHNAME if its argument is
	;; a frobbable pathname. It's hard to imagine having a way to declare
	;; that and it would be a violation of modularity for a compiler to
	;; notice the fact and compile it into another function, yet it still
	;; might be something a programmer could reasonably "just know" and
	;; so declaring it could be important.
	(LOCALLY (DECLARE (PATHNAME X))
	  (SETQ X (FROB-PATHNAME X))
	  ;; Note that PATHNAME-NAME is defined in CLtL to work on other
	  ;; types than just pathnames, though we could imagine a more
	  ;; efficient access being done here if we knew X was going to hold
	  ;; a real pathname.
	  (PATHNAME-NAME X))))
You could insist that the writer should make a new variable and type-declare
the new variable, but that is contrary to the programming style of many CL
programmers and hence not a practical solution. It also doesn't work for the
case of special variables (mentioned below).

    The phrase "within the scope of the declaration" in [A] is in direct
    conflict with the explanation that follows [B].  If "scope" means
    "lexical scope", then the following would be an error according to [A]
    but not according to [B]:

	    (let ((x 12) (y 'foo))
	      (flet ((zap () (rotatef x y)))
		(locally (declare (fixnum x))
		  (zap)
		  (zap)
		  x)))

Not so. The X referenced by ZAP is not in the lexical scope of the locally
declaration. As such, this program is not in error.

    Here the declaration is violated at the "lexical" point in the program
    between the two calls to ZAP.

This is the "If a tree falls in a forest and nobody hears it" problem. If
you had referred to X in that interim, your program would be in error.
Because you have not, your program is not in error.

    If "scope" means "dynamic scope", 

It does not.

    In either case, this seems like a tricky thing for a compiler to
    attempt to understand, and also pretty tricky for an interpreter (and
    in particular, a formal semantics) to enforce.  I would think that
    recovering the needed information via data flow would be easier.

The intent of the declaration is not to force anyone to detect all cases.
The idea is to permit a compiler to make use of that information if it can.

    Even if you decide to trash definition [A] and go with definition [B],
    I would think that you'd additionally want to specify that the
    declaration must hold not only at all references and assignments
    lexically in the scope of the declaration, but also at the point of
    the declaration itself.

This seems reasonable. It would permit compilers to internally rewrite
the LOCALLY as a (LET ((X X)) ...) for its own notational convenience 
when it could prove that didn't affect other semantics (eg, SETQ would
generally thwart such a rewrite).

    Consider the case where the variable is
    unreferenced in the body; then the declaration wouldn't tell you a
    thing, and e.g. it wouldn't help you with backward flow analysis.

I don't have any objection to this sort of thing happening, but it wasn't
our purpose to permit this. But even if you can't infer stuff backward,
that's not such a big deal. At least the person could extend the LOCALLY
backward if he cared. Right now you can't locally declare type information
at all, so isn't what we're proposing an improvement?

    Or
    the variable might be referenced, but the declaration might not become
    valid until some time a while after the point of the declaration:

	    (let ((x 'foo))
	      (flet ((zap () (setq x 17)))
		(locally (declare (fixnum x))
		  (zap)
		  x)))

Right. This is a case where your restriction that it have that type going
in would help. Then the compiler could internally rewrite it as
(LET ((X X)) (DECLARE (FIXNUM X)) ...).

    Also, what does the declaration mean for non-lexical variables?  Would
    it apply dynamically to any dynamic binding or reference in the
    dynamic scope of the declaration, or just to the references to the
    particular dynamic binding that was in effect at the point of
    declaration, or just to lexically apparent references in the lexical
    scope of the declaration?

The declaration itself is lexically scoped -- independent of the scope of
the variable.

    I would strongly oppose the proposal in its current vague form.

Thanks for the criticisms. I'm sure they'll be helpful in tightening things
up.

    I think I would oppose the proposal in just about any form, because it
    makes the semantics of variable references even more hairy than it
    already is.

This would be sad. Right now we have no way to do local declarations other
than at the time a variable binding is instantiated and we're proposing to
make the situation somewhat better. Some of your criticisms sound like 
they're saying we're not solving the whole problem (which we're not) and
so we're doing no good. In fact, I think that solving half the problem will
make serious strides toward people's being able to write programs which
are concise and efficient.

    Compilers ought to recover this kind of information from
    data flow analysis, assisted if necessary by assertions (e.g. uses of
    THE in for-effect positions).

That would be cute but not very perspicuous. There's no difference between
  (LOCALLY (DECLARE (FIXNUM X)) (+ X X))
and
  (PROGN (THE FIXNUM X) (+ X X))
other than that the former is clumsy and earthy-sounding. The latter is like
saying:
  "The accountant... Joe... Joe married Sally."
when you want to say:
  "Joe, who is an accountant, married Sally."
It gets the information across, but not in a way that makes it clear what
you were trying to say.

∂19-Oct-88  1305	CL-Cleanup-mailer 	Issue: DESCRIBE-INTERACTIVE (Version 3)  
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 19 Oct 88  13:03:37 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA01091; Wed, 19 Oct 88 16:02:28 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA14702; Wed, 19 Oct 88 15:35:42 EDT
Message-Id: <8810191935.AA14702@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: DESCRIBE-INTERACTIVE (Version 3)
Date: Wed, 19 Oct 88 15:35:39 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

As promised, this is a complete reversal of Version 2.

!
Issue:        DESCRIBE-INTERACTIVE
References:   DESCRIBE (p441)
Category:     CLARIFICATION/CHANGE
Edit history: 12-Sep-88, Version 1 by Pitman
              23-Sep-88, Version 2 by Masinter
	      19-Oct-88, Version 3 by Pierson, invert

Problem Description:

  CLtL is not clear about whether DESCRIBE may be interactive.
  While CLtL describes INSPECT as an interactive as an
  interactive version of DESCRIBE, it doesn't make explicit
  that DESCRIBE is non-interactive. In some implementations it is, 
  and in other implementations it is not.

  Users of systems in which DESCRIBE is not interactive may presume
  that it is safe to call DESCRIBE in a batch applications without
  hanging the application, which can lead to problems.

Proposal (DESCRIBE-INTERACTIVE:NO):

  Specify that DESCRIBE is forbidden to prompt for or require
  user input.  Permit implementations to extend describe via keyword
  arguments to prompt for or require user input as long as the default
  action if no keyword arguments are supplied does not prompt for or
  require user input.

Test Case:

  The following kind of interaction would be permissible in
  implementations which chose to do it:

   (DEFVAR *MY-TABLE* (MAKE-HASH-TABLE))
   (SETF (GETHASH 'FOO *MY-TABLE*) 1)
   (SETF (GETHASH 'BAR *MY-TABLE*) 2)
   (SETF (GETHASH 'FOOBAR *MY-TABLE*) 3)
   (DESCRIBE *MY-TABLE* :INTERACTIVE T)
   #<EQ-HASH-TABLE 259> has 3 entries.
   Do you want to see its contents? (Yes or No) Yes

Rationale:

  DESCRIBE is the only hook a portable program has for providing
  information about objects to the user.  The potential interactive
  functions of DESCRIBE are also likely to be available via INSPECT.

Current Practice:

  Symbolics Genera asks some questions interactively when describing
  some kinds of structured data structures, such as hash tables.
  Since users can define their own DESCRIBE methods and took their cue
  from the system, describing some user structures also require such
  interactions.

Cost to Implementors:

  Symbolics Genera and other non-conforming implementations will have
  to change.

Cost to Users:

  User code which depends on DESCRIBE running with user interaction
  will have to be modified. Such code is not currently portable,
  however.

Cost of Non-Adoption:

  Users would not have any portable way to have progams inform the
  user about object they are dealing with.  This might be important in
  traces and logs of portable progams or in portable debugging tools.

Benefits:

  It will be easier to provide some types of portable functionality.

Aesthetics:

  This simplifies the language slightly.

Discussion:

  Pitman thinks it's important to clarify this issue, but he isn't fussy
  about the particulars.

  It might be possible to extend DESCRIBE to have additional 
  keywords (:VERBOSE, :INTERACTIVE-ALLOWED) to cover 
  additional behavior. 

  Pierson thinks it's important for there to be some way for portable
  programs to present this sort of information to the user.  While the
  exact data and format presented is implementation dependent and thus
  outside of the bounds of standardization, the existance of such data
  is neither.


∂20-Oct-88  1246	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Oct 88  12:46:31 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 479491; Thu 20-Oct-88 15:46:21 EDT
Date: Thu, 20 Oct 88 15:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
To: pierson%mist@MULTIMAX.ARPA
cc: sandra%defun@cs.utah.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: <8810172013.AA11848@mist.UUCP>
Message-ID: <881020154612.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

    ...
    Current practice:
    ...

If (REQUIRE arg1 arg2) is done and arg1 is not present,
Symbolics Genera does (LOAD-SYSTEM arg2). With Genera's
LOAD-SYSTEM comes a theory of how to register things so
they will be found, regardless of what directory they
are on.

I'd like to have the current practice being by saying that
views on how to treat the arg2 vary pretty widely and then
cite Lucid/Vaxlisp vs Genera as examples. To an extent, this
is the real rationale for flushing the arg2 -- there is no
portable alternative.

    ...
    Discussion: This proposal creates an asymmetry in
    the handling of *MODULES* that may bother some people.

I didn't understand this reference. I think it should be 
spelled out.

    Several people would like to simply eliminate PROVIDE and REQUIRE from
    the language and either leave this language space empty or provide a
    portable DEFSYSTEM standard.  Others believe that PROVIDE and REQUIRE
    are useful as a safety-net even in the presence of DEFSYSTEM.  This
    proposal attempts to reduce PROVIDE and REQUIRE to a well-defined
    safety-net and leaves the question of DEFSYSTEM to a separate
    proposal (which I don't intend to write).

I think this should be promoted to Rationale, and expanded to include
this. The Rationale should say outright that the only two realistic options
are flushing the functions altogether or retaining them in this
labotomized form, and should then go on to give the reasons:
Larry's remarks about PROVIDE/REQUIRE having a declarative feel (which
can be easily grokked by a code walker) while a condition error signalling
mechanism such as GZ wants to fall back to would have an imperative
feel that would be largely opaque to code walkers.

Regarding JonL's remarks, I wonder if we should mention explicitly in the
proposal that implementations are permitted to extend the syntax to permit
an implementation-specific, optional second argument which specifies how
to find the module if it is not present.

Regarding the proposal as a whole, I buy into Larry's arguments and think
that this streamlined definition of REQUIRE/PROVIDE is the right way to go.

∂20-Oct-88  1307	CL-Cleanup-mailer 	DRAFT Issue: TEST-NOT-IF-NOT (Version 2) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Oct 88  13:07:06 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 479509; Thu 20-Oct-88 16:06:27 EDT
Date: Thu, 20 Oct 88 16:06 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DRAFT Issue: TEST-NOT-IF-NOT (Version 2)
To: jonl@lucid.com
cc: cl-cleanup@sail.stanford.edu, chapman%aitg.dec@decwrl.dec.com
In-Reply-To: <8810190444.AA03592@bhopal>
Message-ID: <881020160608.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

[X3J13 removed; Chapman added]

    Date: Tue, 18 Oct 88 21:44:37 PDT
    From: Jon L White <jonl@lucid.com>

    ...
    It would certainly be acceptable to "deprecate" the use of ...;
    this ought to be an editorial discretion, rather than requiring
    lots of cl-cleanup time.

It can't be an editorial discretion. No slight to Kathy intended, but
she just plain cannot be permitted to make unilateral arbitrary decisions
about what we might or might want to throw out of the language in some
subsequent standard. She must be able to justify any change from the
status quo on the basis of some technical backup provided by this or
another committee. Without input from X3J13, she is chartered to do
no more than modify the presentation. She cannot, of her own accord,
change the semantics and she cannot make claims about changes that will
happen in the future (which is what deprecation is about) without risking
amazing grief when it comes time to review her document.

Nothing prohibits us from making any proposal be to simply deprecate
something (and eventually we'll have to define technically what that
will mean). But it -does- require cleanup (or whatever committee) time
to prepare a vote for X3J13.

∂20-Oct-88  1316	CL-Cleanup-mailer 	DRAFT Issue: SYMBOL-MACROLET-DECLARE (version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Oct 88  13:16:28 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 479514; Thu 20-Oct-88 16:16:16 EDT
Date: Thu, 20 Oct 88 16:16 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DRAFT Issue: SYMBOL-MACROLET-DECLARE (version 1)
To: jonl@lucid.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8810182240.AA02072@bhopal>
Message-ID: <881020161608.0.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Tue, 18 Oct 88 15:40:02 PDT
    From: Jon L White <jonl@lucid.com>

    This issue should be folded into SYMBOL-MACROLET-SEMANTICS; it would be
    hardly one line in the descripton of SYMBOL-MACROLET as a special form.
    Since it looks like SYMBOL-MACROLET-SEMANTICS is not very controversial
    anymore, I see no reason to support separate proposals.

In general, people who think something is non-controversial should take only
one course of action: vote yes and move on to the next issue. The only
justification for asking for a rewrite should be that you either disagree
on technical grounds which are not stated or not stated fairly, or else
you think that a particular presentation is vague or controversial and a
rewrite would head off needless debate down the line. I don't see you asserting
either of those positions, so I don't see any reason to act on your suggestion.

If you support both proposals, I see no reason not to leave them separate
and just ask you to vote yes. One of our most valuable resources is time to
get proposals into shape. If we have two proposals which are ready to vote
we should not waste time debating over whether they should be a single
proposal. Making them so might involve more work than you think since the
rationales might not merge as neatly as you expect or people might vote down
one big proposal when they could at least vote in one of two proposals if
last-minute controversy comes up on half the issue.

Worrying about merging two reasonable proposals is like worrying about
rewriting a working program using LOOP because you're not a DO fan. It
doesn't contribute toward the end goal of just getting done.

∂20-Oct-88  1719	CL-Cleanup-mailer 	Issue: EVAL-OTHER (Version 2)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Oct 88  17:19:53 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA08318g; Thu, 20 Oct 88 17:19:26 PDT
Received: by bhopal id AA06100g; Thu, 20 Oct 88 17:17:51 PDT
Date: Thu, 20 Oct 88 17:17:51 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810210017.AA06100@bhopal>
To: miller@CS.ROCHESTER.EDU
Cc: masinter.pa@XEROX.COM, common-lisp-object-system@SAIL.STANFORD.EDU,
        cl-cleanup@SAIL.STANFORD.EDU, harris%hplwhh@HPLABS.HP.COM
In-Reply-To: Brad Miller's message of Mon, 10 Oct 88 16:41 EDT <19881010204134.1.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Subject: Issue: EVAL-OTHER (Version 2) 

re: w/o generic EVAL or APPLY, CLOS is just a bag on the side of CL. 

I can't agree with this at all.  CL is an extremely useful programming
language, and with CLOS added it is incredibly more  useful.  EVAL
is a boringly obscure operation to apply to any piece of data -- it
merely decodes the syntatic means by which programs are written.  Writing
programs encoded as strings rather than lists and symbols, or encoded in 
*any* other random datatype, is hardly a great step forward.

While that last sentence might be open to continuing theoretical debate,
there is the practical observation that MacLisp/NIL *did* make such an
extension (using the object-oriented system called EXTEND), and there
were virtually no meaningful uses of it.  [I'm not 100% sure but I think
Glenn Burke may have used it somehow in the Layered System Building
project.  Apologies, if that use was "meaningful".]

In fact, the EVAL-related extension that really has some vocal supporters
behind it is to *increase* the level on standardization in the coding of 
EVAL, so that research projects into the likes of debuggers and window 
systems can put more "hooks" into the interpreter.  See Henry Lieberman's
"Common Eval" proposal.


-- JonL --



∂20-Oct-88  1725	CL-Cleanup-mailer 	New Issue: WRITE-NEWLINE  
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Oct 88  17:25:36 PDT
Date: Thu, 20 Oct 88 17:20:14 PDT
From: Tim Koschmann <KOSCHMANN@SUMEX-AIM.Stanford.EDU>
Subject: New Issue: WRITE-NEWLINE
To: cl-cleanup@sail.Stanford.EDU
cc: koschmann@SUMEX-AIM.Stanford.EDU
Message-ID: <12440047204.16.KOSCHMANN@SUMEX-AIM.Stanford.EDU>

Issue: 		WRITE-NEWLINE
References:	CLtL p. 382
Category:	ADDITION
Edit history:	20-Oct-88, Version 1 Tim Koschmann

Problem Description:

CL introduced an omnibus write function with optional keywords for all of the print control variables.  However, to produce the behavior of the print function is cumbersome using only the write function.

Proposal WRITE-NEWLINE:

Add another keyword for the write function called :newline (or some such) to produce the behavior of the print function.


Test Case:
CL> (dotimes (index 4)
   (write index :newline))
0
1
2
3
NIL

Rationale:

There is no need for new users to have to know five different output primatives.  The language would be easier to learn if you only needed to know one function for printing.

Current Practice:

I am aware of no implementation that offers this feature.

Cost to Implementors:

Negligible

Cost to users:

none

Cost of Non-Adoption:

An opportunity lost to try and simplify the language.

Benefits:

The language would be more consistent and easier to learn.

Esthetics:

A small improvement.

Discussion:

None

-------

∂20-Oct-88  1828	CL-Cleanup-mailer 	Issue: MAKE-STRING-FILL-POINTER (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Oct 88  18:28:03 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 479762; 20 Oct 88 21:27:58 EDT
Date: Thu, 20 Oct 88 21:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MAKE-STRING-FILL-POINTER (Version 1)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19881021012549.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>

Issue:         MAKE-STRING-FILL-POINTER

References:    CLtL p.302

Related issues: none that I know of

Category:      ADDITION

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

Problem description:

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

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

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

Examples:

  (make-string 80 :fill-pointer 0)

Test Cases:

  See examples.

Rationale:

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

Current practice:

  I know of no implementations that support this.

Cost to Implementors:

  5 cents.

Cost to Users:

  none

Cost of non-adoption:

  none

Performance impact:

  none

Benefits:

  Increased language consistency.

Esthetics:

  Increased language consistency.

Discussion:

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

∂20-Oct-88  1955	CL-Cleanup-mailer 	Issue: DEFSTRUCT-REDEFINITION  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Oct 88  19:55:19 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA08389g; Thu, 20 Oct 88 19:55:06 PDT
Received: by bhopal id AA09021g; Thu, 20 Oct 88 19:53:30 PDT
Date: Thu, 20 Oct 88 19:53:30 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810210253.AA09021@bhopal>
To: vanroggen%aitg.DEC@decwrl.dec.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: vanroggen%aitg.DEC@decwrl.dec.com's message of Thu, 13 Oct 88 12:08:50 PDT <8810131908.AA13980@decwrl.dec.com>
Subject: Issue: DEFSTRUCT-REDEFINITION

re: I'd favor requiring redefining the same DEFSTRUCT as not being an error.
    One way to tell that two DEFSTRUCTs are the same (although probably not
    the way any implementation would really want to do it) it that two
    calls to DEFSTRUCT are the same if they are EQUAL.  It's hard to specify
    something more general that might not get into problems with various
    implementations.

I'll echo your sentiments.

One can also have a class of errors called REDEFINITION, meaning that
it wasn't mechanically certifiable that the new definition is compatible
with the previous one.  I wouldn't mind having the normal state for
this to be merely a warning.  Lucid has a global variable named
*REDEFINITION-ACTION* which controls whether such redefinition cause
warnings, interactive queries (equivalent to continuable error), or 
nothing at all.

Of course, compile-file might provider a "handler" for REDEFINITION.


-- JonL --


∂20-Oct-88  2110	CL-Cleanup-mailer 	Issue: CONSTANT-SIDE-EFFECTS (no proposal)    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Oct 88  21:10:23 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA08408g; Thu, 20 Oct 88 21:09:07 PDT
Received: by bhopal id AA09149g; Thu, 20 Oct 88 21:07:35 PDT
Date: Thu, 20 Oct 88 21:07:35 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810210407.AA09149@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Thu, 13 Oct 88 15:52 EDT <881013155257.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: CONSTANT-SIDE-EFFECTS (no proposal)

re: My notes from Fairfax meeting...

I remember remarking at the committee meeting that Jim Miller of the
Scheme community thought an important aspect of the "constants" problem
was to make "read-only-ness" a first class concept -- that being the only
way to distinguish the objects stored by a defparameter and those stored
by a defconstant [many, if not most, implementors concerned with this
issue have some phase wherein "constants" are put into a write-protected
memory.]   It wouldn't take much to add a couple functions like:

 CONSTANT-STORAGE-P -- tells whether an object is stored in "constants area",
                       which is considered "read-only"; it may or may not
                       actually be write-protected.
 CONSTANT-COPY      -- copies a random object into the "constants area" memory

But of course, since there isn't even a function COPY in CL, there will
be lots of discussion on this matter.


-- JonL --

∂21-Oct-88  0807	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-GC (no proposal)   
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 21 Oct 88  08:07:01 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa05291; 21 Oct 88 15:46 BST
Date: Fri, 21 Oct 88 15:49:34 BST
Message-Id: <1009.8810211449@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: HASH-TABLE-GC (no proposal)
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, JonL%lucid.com@NSS.Cs.Ucl.AC.UK
In-Reply-To: Kent M Pitman's message of Tue, 18 Oct 88 13:42 EDT
Cc: CL-Cleanup@sail.stanford.edu

I think Kent's message has it just right.

I've been allocated for a week and have not had time to do anything
about a proposal.  But to try to clear up a few points:

1. There is some question about whether weak-key hash tables are
   the right way to provide something of this sort.  On balance,
   I think they are.  There were suggestions on the CL list that
   weak pointers and finalization were better or at least more
   fundamental, but I think something based on hash tables is
   the (or at least a) right user-level facility to provide.
   Weak pointers, finalization, and so forth should be considered
   spearate issues.

2. Precedent.  It's true that there isn't much in the way of
   current practice in Common Lisp, but the idea is not untested.
   Temporary properties have been in Pop implementations for
   many years and, despite the name, they really are just hash
   tables.  Lisp/VM also seems to have them (but I can't be sure
   because I have only the documentation).

3. Need.  Hash tables are often used as a way to add properties
   (i.e., extra slots) to objects.  Imagine, say, that SYMBOL-PLIST
   was implemented not as part of the symbol but using a hash table.
   That seems reasonable until you realized than then any symbol
   with a plist could never be collected.  I should think that
   this problem greatly limits the usefulness of hash tables in
   many applications.

In case anyone is wondering "which Kent message?", it's the one
that said this:

>     ... Anyone else know of other "actual needs"?

>  - In my work with Cloe (internally at Symbolics), I've had need to
>    record various kinds of attribute information about non-symbols.

> All of these items need hash table with weak key links only.
> All of these items cause the accumulation of massive amounts of
> garbage over time with no (semantically valid) hope of recovery
> in the absence of weak hash tables.

> Yet problems that demand this sort of solution continue to hit people
> who have no access to such low-level/bit-twiddly solutions.

> There may be some little details to attend to, but abstractly the idea
> of a table with weak key links is both simple and powerful.

-- Jeff

∂21-Oct-88  0928	CL-Cleanup-mailer 	New Issue: WRITE-NEWLINE  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Oct 88  09:27:57 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 479966; Fri 21-Oct-88 12:28:09 EDT
Date: Fri, 21 Oct 88 12:27 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New Issue: WRITE-NEWLINE
To: KOSCHMANN@SUMEX-AIM.Stanford.EDU
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <12440047204.16.KOSCHMANN@SUMEX-AIM.Stanford.EDU>
Message-ID: <881021122757.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

The functionality you're requesting is not a duplication of what
PRINT does. Print prints a newline before AND a space after. I don't
think anyone's going to buy doing (WRITE frob :NEWLINE-BEFORE-AND-SPACE-AFTER T)
nor even (WRITE frob :NEWLINE-FIRST T :SPACE-AFTER T).

In practice, most programmers don't even use WRITE (probably for fear
that the keyword argument deciphering is going to be too inefficient)
and I suspect that the designers would be more likely to consider a
request to flush WRITE than to extend it. If you want a general purpose
I/O operator, FORMAT is probably a better candidate.

Anyway, regarding your test case:
 (dotimes (index 4)
   (write index :newline))
 0
 1
 2
 3
 NIL
I assume you meant :NEWLINE T, since keywords must have accompanying values.
I don't think it's unreasonable for us to ask you to do the following, which
is available now:
 (dotimes (index 4)
   (write #\Newline :escape nil)
   (write index))

∂21-Oct-88  1102	CL-Cleanup-mailer 	Issue: IN-SYNTAX (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Oct 88  11:02:00 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 480032; Fri 21-Oct-88 14:02:08 EDT
Date: Fri, 21 Oct 88 14:01 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: IN-SYNTAX (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881021140158.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

From my list of "pending issues" distributed at the last X3J13 meeting...

-----
Issue:        IN-SYNTAX
References:   None
Category:     ADDITION
Edit history: 21-Oct-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  There is no way to bind read syntax within a file.

  As a result, applications which require extended syntax of some sort
  tend to globally modify the lisp readtable at compile and load time,
  sometimes interfering with other modules and/or user interaction.

  Conscientious developers often avoid the creation of any stylized
  syntax because of its likely effect on parts of the environment which
  don't really belong to the application developer. This need for
  paranoia is probably contrived and the result of what amounts to
  an oversight in the design of Common Lisp.

Proposal (IN-SYNTAX:NEW-FUNCTION):

  Define that COMPILE-FILE and LOAD bind *READTABLE* to its current
  value.

  Introduce a new function IN-SYNTAX described as follows:

  IN-SYNTAX readtable					[Function]

   Assigns *READTABLE* to the value of its argument, which must
   be a readtable.

   Like IN-PACKAGE, this function is specially recognized by the
   compiler, and has the implicit effect of being within
   (EVAL-WHEN (EVAL COMPILE LOAD) ...).

  Rationale:

    IN-SYNTAX would make it possible to select a particular syntax for the
    remainder of a file, radically increasing the usefulness of readtables 
    in Common Lisp by localizing their effect.

Proposal (IN-SYNTAX:NEW-MACRO):

  Define that COMPILE-FILE and LOAD bind *READTABLE* to its current
  value.

  Define a new macro IN-SYNTAX which has the effect of:

   (DEFMACRO IN-SYNTAX (READTABLE)
     `(EVAL-WHEN (EVAL COMPILE LOAD)
	(SETQ *READTABLE* ,READTABLE)))

  Incompatibly change the status of IN-PACKAGE from Function to Macro,
  and describe it as:

   (DEFMACRO IN-PACKAGE (PACKAGE-NAME)
     `(EVAL-WHEN (EVAL COMPILE LOAD)
	(SETQ *PACKAGE* (FIND-PACKAGE ,PACKAGE-NAME))))

  Rationale:

    IN-PACKAGE is intended as a declarative form anyway. Making it a macro
    makes it unnecessary for the compiler to treat it specially.

    IN-SYNTAX would make it possible to select a particular syntax for the
    remainder of a file, radically increasing the usefulness of readtables 
    in Common Lisp by localizing their effect.

Proposal (IN-SYNTAX:MINIMAL):

  Define that COMPILE-FILE and LOAD bind *READTABLE* to its current
  value at the time 

  Rationale:

    This is enough of a foothold to implement a more elaborate facility
    for using readtables in a localized way.

Test Case:
 
   -----File A-----
   (DEFPACKAGE ACME ...)
   (DEFVAR *ACME-SYNTAX*  (COPY-READTABLE *READTABLE*))
   ----------------
 
   -----File B-----
   (IN-PACKAGE 'ACME)
   (IN-SYNTAX *ACME-SYNTAX*)
 
   (SET-MACRO-CHARACTER #\! ...)
 
   (... !... ...)
 
   ----------------
 
  (COMPILE-FILE "A")
  (LOAD "A")
  (COMPILE-FILE "B")
  (LOAD "B")
 
  At this point, "!" would still have its normal syntax globally,
  although it was used locally within B in a different way.

Current Practice:

  Presumably no one does this yet.

Cost to Implementors:

  Very small.

Cost to Users:

  None. This change is upward compatible.

Cost of Non-Adoption:

  Readtables would continue to be hard to use in a clean way.

Benefits:

  If people could use readtables safely, we might see more interesting
  experimentation with read syntax.

Aesthetics:

  A slight improvement to aesthetics by controlling what was formerly
  an unbounded side-effect (modification to the global readtable).

Discussion:

  Pitman supports (in order of decreasing preference) NEW-MACRO,
  NEW-FUNCTION, and MINIMAL.

∂21-Oct-88  1303	CL-Cleanup-mailer 	Issue: THE-AMBIGUITY 
Received: from void.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Oct 88  13:03:05 PDT
Received: by void.ai.mit.edu (5.59/1.5)
	id AA02556; Fri, 21 Oct 88 16:05:49 EDT
Date: Fri, 21 Oct 88 16:05:49 EDT
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8810212005.AA02556@void.ai.mit.edu>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: THE-AMBIGUITY
Reply-To: jar@zurich.ai.mit.edu

I hear that the issue deadline has past, but this is only a
question of clarification, and it seems to me like a necessary
clarification.

Issue:        THE-AMBIGUITY
References:   THE (page 161)
Category:     CLARIFICATION
Edit history: 21-Oct-88, version 1 by Rees
Status:	      For internal discussion

Problem description:

  CLtL does not explicitly say whether the type specifier in a THE
  form may be any type specifier or must be a type specifier suitable
  for discrimination.  Although THE is decsribed as a "declaration"
  form, some CL implementations have assumed that the specifier must
  be for discrimination, and disallow e.g.

    (THE (FUNCTION (T T) CONS) #'CONS)

  We should either say that the implementations are right, or
  explicitly say that they are wrong, since this case is easily
  overlooked.

Proposal (THE-AMBIGUITY:FOR-DECLARATION):

  Clarify that the type specifier in

	(THE type exp)

  may be any valid type specifier.  In the case that exp returns one
  value and type is not a VALUES type specifier, (THE type exp) is
  equivalent to

	(LET ((g exp))
	  (DECLARE (TYPE type g))
	  g)

  where "g" is a gensym.
  
Proposal (THE-AMBIGUITY:FOR-DISCRIMINATION):

  Clarify that the type specifier in

	(THE type exp)

  must be a valid type for discrimination, as for TYPEP, or it must
  be of the form (VALUES type*) where type* are all valid for declaration.

Current practice:

  The Symbolics Genera and VAX LISP V2.2 interpreters signal errors for

	(THE (FUNCTION (T T) CONS) #'CONS),

  but this may not be intentional.  CLtL would seem to allow it.

Test case:

  (THE (FUNCTION (T T) CONS) #'CONS),

  should return the CONS function under THE-AMBIGUITY:FOR-DISCRIMINATION,
  and should be an error under THE-AMBIGUITY:FOR-DECLARATION.

Cost to implementors:

  Trivial cost for THE-AMBIGUITY:FOR-DISCRIMINATION; this is a compatible
  restriction.

  For THE-AMBIGUITY:FOR-DECLARATION, implementations that do not
  already allow arbitrary type specifiers but which want to check that
  the type in a THE is satisfied would have to create an internal
  version of TYPEP which could manage not to signal invalid-type-specifier
  errors in those situations where TYPEP would because the type is a
  declaration-only one.

Cost to users:

  Users of implementations that support THE-AMBIGUITY:FOR-DECLARATION
  might have to remove or change some uses of THE in their code if the
  opposing alternative is adopted.

Benefits:

  Either way, an ambiguity in the language specification would be clarified.

Aesthetics:

  THE-AMBIGUITY:FOR-DECLARATION would seem to be more consistent with
  DECLARE and with the intent of THE, which is supposed to be a way to
  provide information for documentation and for the benefit of compilation.

Discussion:

  Rees supports THE-AMBIGUITY:FOR-DECLARATION.

  Appropriate error situation terminology must be chosen for the
  situation that a THE declaration (or other declaration) is
  unsatisfied, but that must be done regardless of this proposal.

  This proposal would suggest that a function should be added to CL to
  do the checking that THE would want to do:

	  (PROBABLY-TYPEP object type-spec)

  [terrible name of course] returns multiple values a la SUBTYPEP: T T
  if the object definitely has the type, NIL T if it definitely
  doesn't, and T NIL (or NIL NIL?) otherwise.  Assuming that an
  interpreted THE-expression actually checks types, you could almost
  define this function using the condition system and EVAL.  (Ugh!)
  Without PROBABLY-TYPEP, a meta-circular interpreter is more
  difficult to write.

  If a suitable name was found for this function, the additional
  functionality could be suggested as an independent proposal, since
  regardless of the outcome of this issue, the functionality is still
  useful for checking DECLARE's.

∂21-Oct-88  1338	CL-Cleanup-mailer 	Issue: STANDARD-VALUE (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Oct 88  13:38:16 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 480160; Fri 21-Oct-88 16:38:24 EDT
Date: Fri, 21 Oct 88 16:38 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STANDARD-VALUE (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881021163813.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

From my list of "pending issues" distributed at the last X3J13 meeting...

-----
Issue:        STANDARD-VALUE
References:   None
Category:     ADDITION
Edit history: 21-Oct-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  Sometimes a program binds option variables to implausible settings for a
  very temporary purpose. For example, *PRINT-BASE* might be bound temporarily
  to 3 or *PACKAGE* might be bound to the KEYWORD package.

  Entry to the debugger or some other form of recursive read-eval-print loop
  may happen either asynchronously (in some implementations) or synchronously
  due to a call to ERROR or BREAK. When that happens, if these option variables
  are bound to invalid values, it is most useful to bind them back to something
  useful.

  Unfortunately, Common Lisp does not provide a way of distinguishing 
   ``I'm binding/setting this variable for a temporary purpose which
     should not affect recursive read-eval-print loops.''
  from
   ``I'm binding/setting this variable for the express purpose of
     affecting recursive read-eval-print loops.''

  So, for example,

   (DEFUN PRINT-IN-KEYWORD-PACKAGE (X)
     (LET ((*PRINT-BASE* (FIND-PACKAGE "KEYWORD"))) (PRINT XX)))
   (PRINT-IN-KEYWORD-PACKAGE 'ZAP)
   >>Error: The variable XX is unbound.
   Debug> (HELP)
   >>Error: The function :HELP is undefined.

  It might be useful for *PACKAGE* to have been bound back to something
  other than keyword here.

   (DEFUN BASE-3-REPL ()
     (LET ((*PRINT-BASE* 3) (*READ-BASE* 3) (*PRINT-RADIX* NIL))
       (MY-READ-EVAL-PRINT-LOOP :PROMPT "Base 3> ")))
   Base 3> (- 10 1)
   2
   Base 3> (+ 'FOO 1)
   Error: FOO is not a valid argument to the + function.
   Debug> :Use-Value 10
   2

  Here it was useful that *PRINT-BASE* was not bound back to something.

Proposal (STANDARD-VALUE:NEW-FUNCTIONS):

  Introduce these new macros:

  DEFVAR-STANDARD name value					[Macro]

   Like DEFVAR, but the initial value is recorded as the `standard value.'
  
  LET-STANDARD let-bindings &body forms				[Macro]

   Like LET, but binds both the values and the standard values of the
   indicated variables (which must have been previously defined by
   DEFVAR-STANDARD).

  PROGV-STANDARD names values &body forms			[Macro]

   Like PROGV, but binds both the values and the standard values of the
   indicated variables (which must have been previously defined by
   DEFVAR-STANDARD).

  STANDARD-VALUE name						[Function]

   Returns the standard value of the indicated variable.
   Note that this may not be the same as (SYMBOL-VALUE name).

   SETF may be used with this function. Note that setting the
   standard value of NAME does not set (SYMBOL-VALUE name).

  When the debugger is entered, variables which have been declared standard
  but which do not currently have their standard values (as judged by EQL)
  will be rebound to their standard values (and a mechanism will be provided
  for viewing the values to which they were bound at debugger entry time).

  NON-STANDARD-VALUES						[Function]

   Returns a list of variables which are not currently bound to their
   standard values.

  The following variables in the LISP package are defined as if by
  DEFVAR-STANDARD:

    *PRINT-ARRAY*    *PRINT-GENSYM*   *READ-BASE*
    *PRINT-BASE*     *PRINT-LENGTH*   *READ-DEFAULT-FLOAT-FORMAT*
    *PRINT-CASE*     *PRINT-LEVEL*    *READ-SUPPRESS*
    *PRINT-CIRCLE*   *PRINT-PRETTY*   *READTABLE*
    *PRINT-ESCAPE*   *PRINT-RADIX*

  Define that LOAD and COMPILE-FILE bind *PACKAGE* using LET-STANDARD.

  Define that IN-PACKAGE sets both the SYMBOL-VALUE and the
  STANDARD-VALUE of the variable in question.

Test Case:

  Contrast these with the analogous cases in the problem description:

   (DEFUN PRINT-IN-KEYWORD-PACKAGE (X)
     (LET ((*PRINT-BASE* (FIND-PACKAGE "KEYWORD"))) (PRINT XX)))
   (PRINT-IN-KEYWORD-PACKAGE 'ZAP)
   >>Error: The variable XX is unbound.
   Rebinding *PACKAGE* from #<PACKAGE "KEYWORD"> to #<PACKAGE "USER">.
   Debug> (HELP)
   ...This is presumably typeout from some function called HELP...

   (DEFUN BASE-3-REPL ()
     (LET-STANDARD ((*PRINT-BASE* 3) (*READ-BASE* 3) (*PRINT-RADIX* NIL))
       (MY-READ-EVAL-PRINT-LOOP :PROMPT "Base 3> ")))
   Base 3> (- 10 1)
   2
   Base 3> (+ 'FOO 1)
   Error: FOO is not a valid argument to the + function.
   Debug> :Use-Value 10
   2

Rationale:

  This would allow users to say when, when binding a variable, whether they
  intended to bind it only `temporarily' or if they had some deeper purpose
  in mind.

  Also, users of Genera (where standard values already exist) have
  complained that IN-PACKAGE does not set the standard value of *PACKAGE*
  in Genera. The same is true for the binding of *PACKAGE* by LOAD. Other
  users would complain if standard values were affected. The confusion is
  not really due to the fact one meaning is preferrable over the other, but
  rather due to the fact that Common Lisp cannot document such a meaning
  without first admitting the concept of standard values. If standard
  values existed in Common Lisp and the documentation was clear on how
  IN-PACKAGE and LOAD related to that concept, users would no longer be
  forced to guess what these functions did with respect to such information,
  and so those users who are now surprised would no longer have reason to
  be surprised.

Current Practice:

  Symbolics Genera implements the proposed functionality (with slightly
  more options and slightly different names).

Cost to Implementors:

  Relatively small. A set of fairly straightforward definitions, looking
  something like:

  (DEFVAR *STANDARD-VALUES* '())

  (DEFUN STANDARD-VALUE (NAME)
    (LET ((ENTRY (ASSOC NAME *STANDARD-VALUES*)))
      (IF (NOT ENTRY) (ERROR ...) (CADR ENTRY))))

  (DEFUN SET-STANDARD-VALUE (NAME VALUE)
    (LET ((ENTRY (ASSOC NAME *STANDARD-VALUES*)))
      (IF (NOT ENTRY) (ERROR ...) (SETF (CADR ENTRY) VALUE))))

  (DEFSETF STANDARD-VALUE SET-STANDARD-VALUE)

  (DEFMACRO DEFVAR-STANDARD (NAME VALUE)
    `(PROGN (DEFVAR ,NAME ,VALUE)
	    (PUSHNEW (CONS ',NAME ,NAME) *STANDARD-VALUES* :KEY #'CAR)
	    ',NAME))

  (DEFMACRO LET-STANDARD (BINDINGS &BODY FORMS)
    `(LET ,@BINDINGS
       (LET ((*STANDARD-VALUES*
	       (LIST* ,@(MAPCAR #'(LAMBDA (BINDING) 
				    `(CONS ',(CAR BINDING) ,(CAR BINDING)))
			        BINDINGS)
		      *STANDARD-VALUES*)))
	 ,@FORMS)))

  (DEFMACRO PROGV-STANDARD (VARS VALUES &BODY FORMS)
    (LET ((TEMP (GENSYM)))
      `(LET ((,TEMP ,VARS))
         (PROGV ,TEMP ,VALUES
           (LET ((*STANDARD-VALUES* *STANDARD-VALUES*))
	     ;; This puts them on backward from how LET-STANDARD does, but
	     ;; if there are no duplicates, that won't matter... and
	     ;; duplicates are disallowed as per LET.
	     (DOLIST (,TEMP ,TEMP)
	       (PUSH (CONS ,TEMP (SYMBOL-VALUE ,TEMP)) *STANDARD-VALUES*))
	     ,@FORMS)))))

  (DEFUN NON-STANDARD-VALUES ()
    (LET ((RESULT '()))
      (DOLIST (ENTRY *STANDARD-VALUES*)
        (UNLESS (EQL (SYMBOL-VALUE (CAR ENTRY)) (CDR ENTRY))
	  (PUSH (CAR ENTRY) RESULT)))
      RESULT))

  [I wrote these quickly and didn't test them. If anyone else reviewing this
   has time to test them and let me know about bugs, that would be nice. -kmp]

Cost to Users:

  None. This change is upward compatible.

Cost of Non-Adoption:

  There is no way for Common Lisp programs to provide advice to systems
  already supporting this facility.

Benefits:

  The interaction between programs that bind important variables and the
  debugger would become more clear (and hence less frustrating) to users.

Aesthetics:

  Some might argue that this adds a small amount of undue hair.

  However, the hair is easy to overlook the nagging little problems that
  come from not using this facility. The problem is that, without a
  facility like this, those who do care about these issues have no way to
  express their intent.

Discussion:

  Pitman thinks a facility like this would probably improve the quality of
  debugging interaction in Common Lisp implementations.

  The problem with the meaning of IN-PACKAGE was first pointed out to
  Pitman by Rees, who encountered the problem while creating his portable
  Scheme implementation.

∂21-Oct-88  1347	CL-Cleanup-mailer 	Re: Issue: THE-AMBIGUITY  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Oct 88  13:47:36 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 OCT 88 13:38:34 PDT
Date: 21 Oct 88 13:38 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: THE-AMBIGUITY
In-reply-to: jar@void.ai.mit.edu (Jonathan Rees)'s message of Fri, 21 Oct
 88 16:05:49 EDT
To: jar@zurich.ai.mit.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881021-133834-6458@Xerox>

We've always said that issues that arise during the editorial process will
still be accepted. I'm trying to cut off the flood of "wouldn't it be nice
if..."'s. Its probably important for us to put off new issues until we get
the letter ballot for all of the old ones resolved. (I have your name down
next to a couple of them.)


On your proposed implementation: one string of issues that I still hope we
can resolve (if not by first draft) is to specify more fully the types of
errors signalled. CONDITIONS:INVALID-TYPE-SPECIFIER seems like a reasonable
error for TYPEP to signal if it is given one. An implementation of THE
might want to handler-bind that particular condition, although it would be
free to do something else instead.





∂21-Oct-88  1400	CL-Cleanup-mailer 	Issue: THE-AMBIGUITY 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Oct 88  14:00:30 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA00402g; Fri, 21 Oct 88 14:00:10 PDT
Received: by blacksox id AA00251g; Fri, 21 Oct 88 13:56:14 pdt
Date: Fri, 21 Oct 88 13:56:14 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8810212056.AA00251@blacksox>
To: jar@zurich.ai.mit.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Jonathan Rees's message of Fri, 21 Oct 88 16:05:49 EDT <8810212005.AA02556@void.ai.mit.edu>
Subject: Issue: THE-AMBIGUITY

   Date: Fri, 21 Oct 88 16:05:49 EDT
   From: jar@void.ai.mit.edu (Jonathan Rees)
   Reply-To: jar@zurich.ai.mit.edu

   Proposal (THE-AMBIGUITY:FOR-DISCRIMINATION):

     Clarify that the type specifier in

	   (THE type exp)

     must be a valid type for discrimination, as for TYPEP, or it must
     be of the form (VALUES type*) where type* are all valid for declaration.
								 ↑↑↑↑↑↑↑↑↑↑↑

You mean "discrimination", right?

By the way, I support FOR-DECLARATION.  Lucid CL has the same bug in
the interpreter as the others (a "bug" assuming FOR-DECLARATION).
TYPEP is used to check the legality of the type specifier in THE.

∂21-Oct-88  1400	CL-Cleanup-mailer 	Issue: PATHNAME-PRINT-READ (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Oct 88  14:00:40 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 480184; Fri 21-Oct-88 17:00:54 EDT
Date: Fri, 21 Oct 88 17:00 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-PRINT-READ (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881021170043.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

From my list of "pending issues" distributed at the last X3J13 meeting...

-----
Issue:        PATHNAME-PRINT-READ
References:   File System Interface (pp409-427)
Category:     CHANGE/ADDITION
Edit history: 21-Oct-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  Although pathnames are required to print re-readably, there is no
  standardized representation for pathnames and so no standardized
  way in which they should print.

  Further, it is common in programs to want pathnames to print in
  their file-system specific format.

Proposal (PATHNAME-PRINT-READ:SHARPSIGN-P):

  Define the reader syntax #P"..." to be equivalent to 
  #.(PARSE-NAMESTRING "...").

  Define that when *PRINT-ESCAPE* is T, the syntax #P"..." is
  how a pathname should be printed by WRITE (and hence by PRIN1,
  PRINT, etc.). The "..." is the namestring representation of the
  pathname.

  Define that when *PRINT-ESCAPE* is NIL, WRITE writes a pathname
  object P by writing (NAMESTRING p) instead.

Test Case:

  (PARSE-NAMESTRING "foo.lisp")
  => #P"foo.lisp"

  (FORMAT NIL "Written to ~A." #P"foo.bin")
  => "Written to foo.bin."

  (TYPEP #P"foo.bin" 'PATHNAME)
  => T

Rationale:

  This satisfies the stated goals.

  [For :ESCAPE T] It will not be possible to make the printed
  pathname printed representation totally portable because of
  variations in file systems, but for different Common Lisp
  implementations on the same file system, or for Common Lisp
  systems running on file systems having compatible syntax,
  portability would be improved by this specification.

  Also, some implementations (eg, Symbolics Genera) use
  specialized representations for pathnames on different file
  systems. Eg, an MSDOS pathname is of type MSDOS-PATHNAME,
  not just type PATHNAME. #S(PATHNAME ...) is not only more
  verbose than necessary but might be misleading to some users
  because the object created will not have a TYPE-OF PATHNAME.

  [For :ESCAPE NIL] Printing the namestring of a pathname is
  a common operation and it is convenient to have a shorthand
  for doing it. Further, some implementations may be able to
  optimize the presentation of a pathname in this mode by
  printing it without actually consing the string.

Current Practice:

  Symbolics Genera implements the proposed behavior.

Cost to Implementors:

  Fairly minor changes to the readtable and the printer.

Cost to Users:

  Users who now use the non-portable syntax #S(...) in order
  to enter literal pathnames might have to change. [However,
  implementations would be free to continue to support this
  read syntax for compatibility.]

Cost of Non-Adoption:

  Portability of code and data involving pathnames within a
  given file system (or between suitably similar file systems)
  would be hampered needlessly.

Benefits:

  The cost of non-adoption would be avoided.

Aesthetics:

  The #P syntax is pretty and hides unimportant details.

Discussion:

  Pitman supports this change.

∂21-Oct-88  1401	CL-Compiler-mailer 	Issue: IN-SYNTAX (Version 1)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Oct 88  14:01:13 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00405g; Fri, 21 Oct 88 14:00:49 PDT
Received: by bhopal id AA11541g; Fri, 21 Oct 88 13:59:17 PDT
Date: Fri, 21 Oct 88 13:59:17 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810212059.AA11541@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU, CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Fri, 21 Oct 88 14:01 EDT <881021140158.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: IN-SYNTAX (Version 1)

This issue is far too narrowly focused right now.  For example,

-- I would *strongly* favor the name IN-READTABLE over IN-SYNTAX; the
   analogy is that IN-PACKAGE sets *PACKAGE*.  Alternatively, IN-SYNTAX
   would have to jointly handle *READ-BASE* and *PACKAGE* as well as
   *READTABLE*.

-- The change suggested for IN-PACKAGE in the IN-SYNTAX:NEW-MACRO proposal 
   presumes:
    (1) acceptance of the more radical IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
        proposal, or at least eliminating the :use and :nicknames arguments;
    (2) acceptance of the Cl-compiler's EVAL-WHEN-NON-TOP-LEVEL proposal.
   While I favor both of these pivotal proposals, one might not want to
   get this issued hung up over them.

-- The rebindings of syntax parameters like *PACKAGE* and *READ-TABLE* by 
   LOAD and COMPILE-FILE are currently directed towards the perpetuation of 
   a horrible loophole; binding to "the current" values encourages the kind
   of viewpoint mistakes that occur frequently even to fairly compotent 
   programmers.


In short, we would all be better off if LOAD and COMPILE-FILE started out 
in a ***known*** configuration.  I would suggest binding *READ-BASE* to 10,
*PACKAGE* to USER, and *READTABLE* to a value like (copy-readtable nil).


The MIMIMAL proposal -- assuming the name change -- is nearly 
uncontroversial, and wouldn't preclude subsequent embellishments.
How about adding *READ-BASE* to it, and considering more standard
default values?


-- JonL --

∂21-Oct-88  1415	CL-Cleanup-mailer 	Issue: IN-SYNTAX (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Oct 88  14:15:17 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 480205; Fri 21-Oct-88 17:13:31 EDT
Date: Fri, 21 Oct 88 17:13 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: IN-SYNTAX (Version 1)
To: jonl@lucid.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU,
    CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: <8810212059.AA11541@bhopal>
Message-ID: <881021171320.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Fri, 21 Oct 88 13:59:17 PDT
    From: Jon L White <jonl@lucid.com>

    This issue is far too narrowly focused right now.  For example,

[Reasonable comments ommitted for now.]

    In short, we would all be better off if LOAD and COMPILE-FILE started out 
    in a ***known*** configuration.  I would suggest binding *READ-BASE* to 10,
    *PACKAGE* to USER, and *READTABLE* to a value like (copy-readtable nil).

I'm worried about this because:

   - LISP is unsuitable because you don't know what's in it.
   - USER is unsuitable because
     - it may contain implementation-dependent stuff, including
       shadowed definitions of standard common lisp things.
     - its express purpose is for users to muck around in, so even
       if it starts off clean, it won't stay that way. as such, either
       it will be unreliable to load anything once you've been fooling
       around awhile or you'll have to know not to do some things that
       might screw up loading. either of these is unacceptable.
   - SYSTEM is unsuitable because you can't know what's in it.
   - KEYWORD is unsuitable because it has no functions in it and you'd
     have to use package prefixes anyway.

    ...
    The MIMIMAL proposal -- assuming the name change -- is nearly 
    uncontroversial, and wouldn't preclude subsequent embellishments.
    How about adding *READ-BASE* to it, and considering more standard
    default values?

Something I just thought of (a result of thinking about your message):
In spite of my hesitation about using USER, I have to say that it might
be kinda nice if LOAD could rebind everything to its `standard value' if
we could adopt the STANDARD-VALUE proposal. If that were true, then
people could do LET-STANDARD to affect the value if they really wanted
to, yet not only *PACKAGE*, but also *READTABLE*, *PRINT-BASE*, etc.
could be handled in a reason which was intuitively nice and didn't have
to pick some arbitrary set of variables to bind. Maybe if we did that,
I wouldn't feel a need to push this issue. When you've had a chance to
review that proposal, let me know how you feel about this idea.

∂21-Oct-88  1418	CL-Cleanup-mailer 	Issue: PATHNAME-PRINT-READ (Version 1)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Oct 88  14:18:02 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA00442g; Fri, 21 Oct 88 14:17:45 PDT
Received: by blacksox id AA00256g; Fri, 21 Oct 88 14:13:50 pdt
Date: Fri, 21 Oct 88 14:13:50 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8810212113.AA00256@blacksox>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Fri, 21 Oct 88 17:00 EDT <881021170043.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-PRINT-READ (Version 1)

For Current Practice:

Lucid CL also implements the proposed behavior.

For Cost to Users:

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


I weakly support this change.  I wish someone would make a proposal
for generic pathnames.  I don't think they ever got the consideration
they deserved.  (I know they aren't really related to this issue,
except insofar as users would like to have portable pathnames in their
programs.)

∂21-Oct-88  1420	CL-Cleanup-mailer 	Issue: IN-SYNTAX (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Oct 88  14:20:11 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 480211; Fri 21-Oct-88 17:20:02 EDT
Date: Fri, 21 Oct 88 17:19 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: IN-SYNTAX (Version 1)
To: jonl@lucid.com
cc: CL-Cleanup@SAIL.Stanford.EDU, CL-Compiler@SAIL.Stanford.EDU
References: <881021171320.4.KMP@BOBOLINK.SCRC.Symbolics.COM>,
            <8810212059.AA11541@bhopal>
Message-ID: <881021171949.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

I noticed too late that you had added CL-Compiler. 
I would -really- prefer if you didn't cc CL-Compiler in
further debate and if CL-Compiler would just pretend for now
that they hadn't seen those two pieces of mail.
My reasoning:

 - The discussion style of the two lists is very different.

 - It's a pain for those of us who are on both lists to get
   two or three copies.

 - It isn't wise to have people involved in only half of a
   discussion.  They don't know what conversation has gone
   before and so are likely to duplicate points already made.
   Or else they may comment out of paranoia about what might
   have gone before rather than from an informed standpoint.

If and when we deem it appropriate to pass this off to CL-Compiler
for review, we should do so in some form of organized presentation
rather than in the form of random cc's of occassional messages.

∂21-Oct-88  1429	CL-Cleanup-mailer 	Re: Issue: STANDARD-VALUE (Version 1)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Oct 88  14:24:58 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 21 OCT 88 14:11:22 PDT
Date: 21 Oct 88 13:48 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: STANDARD-VALUE (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Fri, 21 Oct 88 16:38 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881021-141122-6552@Xerox>

Envos Medley does this only slightly differently: there's a list
IL:*PER-EXEC-VARIABLES* instead of *STAHDARD-VALUES*. If you really add a
new variable that really has to be rebound when a new debugger or EXEC is
invoked, you can push something onto it.

The initial value is ((*PACKAGE* (COND ((PACKAGEP *PACKAGE*) *PACKAGE*) (T
(PROMPTPRINT "Invalid package, reset to LISP") (SETQ *PACKAGE*
(FIND-PACKAGE LISP))))) (* *) (** **) (*** ***) (+ +) (++ ++) (+++ +++) (-
-) (/ /) (// //) (/// ///) (HELPFLAG T) (*EVALHOOK* NIL) (*APPLYHOOK* NIL)
(*ERROR-OUTPUT* *TERMINAL-IO*) (*READTABLE* *READTABLE*) (*EVAL-FUNCTION*
*EVAL-FUNCTION*) (*EXEC-PROMPT* *EXEC-PROMPT*) (*DEBUGGER-PROMPT*
*DEBUGGER-PROMPT*)) 

I don't think this will fly, because it seems to be too dependent on one
particular style of debugger.

∂21-Oct-88  1432	CL-Cleanup-mailer 	Re: Issue: STANDARD-VALUE (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Oct 88  14:31:51 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 480223; Fri 21-Oct-88 17:31:38 EDT
Date: Fri, 21 Oct 88 17:31 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: STANDARD-VALUE (Version 1)
To: masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881021-141122-6552@Xerox>
Message-ID: <881021173128.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: 21 Oct 88 13:48 PDT
    From: masinter.pa@Xerox.COM

    Envos Medley does this only slightly differently: there's a list
    IL:*PER-EXEC-VARIABLES* instead of *STAHDARD-VALUES*. If you really add a

Had I said STAHDARD? Must be that famous Boston accent creeping in. I meant
STANDARD.

    new variable that really has to be rebound when a new debugger or EXEC is
    invoked, you can push something onto it.

I'm not proposing we advertise the variable that holds them. That's
implementation-dependent.


    The initial value is ((*PACKAGE* (COND ((PACKAGEP *PACKAGE*) *PACKAGE*) (T
    (PROMPTPRINT "Invalid package, reset to LISP") (SETQ *PACKAGE*
    (FIND-PACKAGE LISP))))) (* *) (** **) (*** ***) (+ +) (++ ++) (+++ +++) (-
    -) (/ /) (// //) (/// ///) (HELPFLAG T) (*EVALHOOK* NIL) (*APPLYHOOK* NIL)
    (*ERROR-OUTPUT* *TERMINAL-IO*) (*READTABLE* *READTABLE*) (*EVAL-FUNCTION*
    *EVAL-FUNCTION*) (*EXEC-PROMPT* *EXEC-PROMPT*) (*DEBUGGER-PROMPT*
    *DEBUGGER-PROMPT*)) 

Mostly I'm content to union the LISP symbols in your list with ours. We
probably ought to have *EVALHOOK* and *APPLYHOOK* in our list anyway,
for example.

The issue of *, **, ***, etc. is an unclear one. I think our users prefer that
the values not be rebound, so they can abort out a level and still refer back
to a value they got in a breakpoint.

    I don't think this will fly, because it seems to be too dependent on one
    particular style of debugger.

I could weaken the restriction on the debugger to say it's only a mechanism for
programs to communicate such info with debuggers that can make use of it.
I'm not interested in restricting debugger styles so much as acknowledging that
many are like this and that many people have programs that would be happy to
give the debugger hints if only they knew how.

∂21-Oct-88  1435	CL-Cleanup-mailer 	Re: Issue: PATHNAME-PRINT-READ (Version 1)    
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 21 Oct 88  14:35:33 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA00495; Fri, 21 Oct 88 17:34:21 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA17855; Fri, 21 Oct 88 17:38:17 EDT
Message-Id: <8810212138.AA17855@mist.UUCP>
To: Kent M Pitman <KMP%STONY-BROOK.SCRC.Symbolics.COM@multimax>
Cc: CL-Cleanup%SAIL.Stanford.EDU@multimax
Subject: Re: Issue: PATHNAME-PRINT-READ (Version 1) 
In-Reply-To: Your message of Fri, 21 Oct 88 17:00:00 -0400.
             <881021170043.3.KMP@BOBOLINK.SCRC.Symbolics.COM> 
Date: Fri, 21 Oct 88 17:38:16 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

For current practice:

KCL uses #"..."

(This is going to give KCL users trouble with Water's new portable
pretty printer since Dick has said that he won't change because ``#"''
is just too nice for his purposes.)  

It would be nice to figure out some way to specify which characters
are for implementation extensions to the # read-macro and which are
for users, but that's probably a question to be answered by the
(inactive) conformance subcommittee if at all.

∂21-Oct-88  1511	CL-Cleanup-mailer 	Issue: THE-AMBIGUITY 
Received: from void.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Oct 88  15:11:34 PDT
Received: by void.ai.mit.edu (5.59/1.5)
	id AA02583; Fri, 21 Oct 88 18:14:02 EDT
Date: Fri, 21 Oct 88 18:14:02 EDT
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8810212214.AA02583@void.ai.mit.edu>
To: eb@lucid.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Eric Benson's message of Fri, 21 Oct 88 13:56:14 pdt <8810212056.AA00251@blacksox>
Subject: Issue: THE-AMBIGUITY
Reply-To: jar@zurich.ai.mit.edu

   Date: Fri, 21 Oct 88 13:56:14 pdt
   From: Eric Benson <eb@lucid.com>

      Proposal (THE-AMBIGUITY:FOR-DISCRIMINATION): ... for declaration.
					                   ↑↑↑↑↑↑↑↑↑↑↑

   You mean "discrimination", right?

Right.

∂21-Oct-88  1520	CL-Cleanup-mailer 	Issue: PACKAGE-FUNCTION-CONSISTENCY (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Oct 88  15:20:13 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 480261; Fri 21-Oct-88 18:20:20 EDT
Date: Fri, 21 Oct 88 18:20 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-FUNCTION-CONSISTENCY (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881021182009.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

From my list of "pending issues" distributed at the last X3J13 meeting...

-----
Issue:        PACKAGE-FUNCTION-CONSISTENCY
References:   11.7 Package System Functions and Variables (pp182-188)
Category:     CLARIFICATION/CHANGE
Edit history: 21-Oct-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  CLtL is vague about whether either or both of package or package name
  are permissible in some cases.

Proposal (PACKAGE-FUNCTION-CONSISTENCY:PERMISSIVE):

  Clarify that it is permissible to pass either a package object
  or a package name (symbol or string) in the following situations:
    - the :USE argument to MAKE-PACKAGE or IN-PACKAGE
    - the first argument to IN-PACKAGE, FIND-PACKAGE, and RENAME-PACKAGE
    - the second argument to INTERN, FIND-SYMBOL, UNINTERN
    - the second argument to EXPORT, UNEXPORT, IMPORT,
      SHADOWING-IMPORT, and SHADOW
    - the first argument (or a member of the list which is the first
      argument) to USE-PACKAGE or UNUSE-PACKAGE.
    - the PACKAGE argument to DO-SYMBOLS.
    - the PACKAGE argument to DO-EXTERNAL-SYMBOLS.
    - the PACKAGE argument to DO-ALL-SYMBOLS.

  If FIND-PACKAGE is given a package object as an argument, it simply
  returns it.

  If IN-PACKAGE is given a package object as an argument, that package
  is selected. It is an error if, when a package object is given as a
  first argument to IN-PACKAGE, a :USE list is explicitly specified and
  does not exactly match the package or :NICKNAMES is explicitly supplied
  and does not exactly match the package.

  Clarify that the functions PACKAGE-NAME, PACKAGE-NICKNAMES, 
  PACKAGE-USE-LIST, and PACKAGE-USED-BY-LIST are (at least conceptually)
  accessors to package data structures and permit only package objects
  as arguments.

  Clarify that the function MAKE-PACKAGE permits only a package name
  as an argument since it does not make sense to create an existing
  package.

  Clarify that package nicknames must always be expressed as package
  names (symbols or strings) and may never be actual package objects.

Test Case:

  (INTERN "FOO" "KEYWORD") => :FOO

  (DEFVAR *FOO-PACKAGE* (MAKE-PACKAGE "FOO"))
  (RENAME-PACKAGE "FOO" "FOO0")
  (PACKAGE-NAME *FOO-PACKAGE*) => "FOO0"

Rationale:

  This makes things more consistent.

Current Practice:

  Symbolics Genera permits strings as package names.
  Symbolics Cloe does not permit strings as package names.

Cost to Implementors:

  Very small.

Cost to Users:

  None. This change is upward compatible.

Cost of Non-Adoption:

  Implementations would continue to vary gratuitously, leaving a potential
  for portability problems.

Benefits:

  The cost of non-adoption is avoided.

Aesthetics:

  This makes things more regular, and so presumably more aesthetic.

Discussion:

  Pitman ran across this problem while trying to port Macsyma to various
  implementations. Discussion with other maintainers of portable programs
  shows this is a common source of aggravation in portable code.

  Since the pathname accessors all take namestrings or streams, one might
  easily argue that it would be more consistent for PACKAGE-NAME, 
  PACKAGE-NICKNAMES, etc. to also take arguments of package names. After
  all,
   (PACKAGE-NAME "FOO") => "FOO"
  is no stranger than
   (NAMESTRING "JOE:fred.lisp") => "JOE:fred.lisp".
  If anyone wants to see a redraft of this to include even these
  functions, they should speak up.

  It would be possible to say that MAKE-PACKAGE took package objects as
  arguments and just returned that package. That might have limited
  usefulness on rare occassions, but mostly seemed too far out in left
  field to bother suggesting it.

∂21-Oct-88  1526	CL-Cleanup-mailer 	Issue: THE-AMBIGUITY 
Received: from void.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Oct 88  15:24:55 PDT
Received: by void.ai.mit.edu (5.59/1.5)
	id AA02596; Fri, 21 Oct 88 18:27:19 EDT
Date: Fri, 21 Oct 88 18:27:19 EDT
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8810212227.AA02596@void.ai.mit.edu>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 21 Oct 88 13:38 PDT <881021-133834-6458@Xerox>
Subject: Issue: THE-AMBIGUITY
Reply-To: jar@zurich.ai.mit.edu

   Date: 21 Oct 88 13:38 PDT
   From: masinter.pa@Xerox.COM

   On your proposed implementation: one string of issues that I still hope we
   can resolve (if not by first draft) is to specify more fully the types of
   errors signalled. CONDITIONS:INVALID-TYPE-SPECIFIER seems like a reasonable
   error for TYPEP to signal if it is given one. An implementation of THE
   might want to handler-bind that particular condition, although it would be
   free to do something else instead.

This implementation doesn't quite work because then there'd be no way
to distinguish between
	(the (integer you lose big) #'cons)
and
	(the (function (t t) cons) #'cons),
the first of which should be an error and the second of which shouldn't.
I think there would have to be a distinct condition type, maybe
INAPPROPRIATE-TYPE-SPECIFIER, for valid type specifiers that are used
in the wrong context.

Also, in considering possible ways in which the type-checking logic
for THE and DECLARE might work, don't forget things like
	(the (not (function (t t) integer)) 7),
which you would want to signal an error.  I don't think this can be
done with only TYPEP and conditions.

Jonathan

∂21-Oct-88  1527	CL-Cleanup-mailer 	Issue: PACKAGE-FUNCTION-CONSISTENCY (Version 1)    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Oct 88  15:26:18 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA00521g; Fri, 21 Oct 88 15:25:59 PDT
Received: by blacksox id AA00268g; Fri, 21 Oct 88 15:22:02 pdt
Date: Fri, 21 Oct 88 15:22:02 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8810212222.AA00268@blacksox>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Fri, 21 Oct 88 18:20 EDT <881021182009.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-FUNCTION-CONSISTENCY (Version 1)

For Current Practice:

Lucid CL permits string as package names.

∂21-Oct-88  1757	CL-Cleanup-mailer 	Issue: LAMBDA-FORM (Version 3) 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Oct 88  17:56:47 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00690g; Fri, 21 Oct 88 17:56:17 PDT
Received: by bhopal id AA12447g; Fri, 21 Oct 88 17:54:44 PDT
Date: Fri, 21 Oct 88 17:54:44 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810220054.AA12447@bhopal>
To: ACW@IVORY.S4CC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu, Masinter.pa@Xerox.COM
In-Reply-To: Allan C. Wechsler's message of Tue, 11 Oct 88 11:16 EDT <19881011151620.6.ACW@ROCKY-MOUNTAINS.S4CC.Symbolics.COM>
Subject: Issue: LAMBDA-FORM (Version 3)

re: In Scheme, the operator of a function invocation form has the same
    evaluation semantics as the operands.  In CL, however, the operator is
    not evaluated in the same way that the operands are.
    I am concerned lest the new macro called LAMBDA should obscure this
    difference in evaluation semantics.  A novice Lisp programmer would have
    a hard time understanding why the #' is optional in

Hmmmm, having read your reasoning here, now I'm leaning towards rescinding
my tentative approval ("silence gives consent") on this issue.

-- JonL --

∂21-Oct-88  1854	CL-Compiler-mailer 	issue DEFPACKAGE    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Oct 88  18:54:47 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00712g; Fri, 21 Oct 88 18:54:30 PDT
Received: by bhopal id AA12710g; Fri, 21 Oct 88 18:52:57 PDT
Date: Fri, 21 Oct 88 18:52:57 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810220152.AA12710@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-cleanup@sail.stanford.edu, cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Thu, 13 Oct 88 14:34:04 MDT <8810132034.AA19839@defun.utah.edu>
Subject: issue DEFPACKAGE

re: I presume it's the intention of the proposal that the expansion of
    DEFPACKAGE should be wrapped with an (EVAL-WHEN (EVAL COMPILE LOAD)
    ...).  An explicit statement of what you intend for the compiler to do
    with DEFPACKAGE should either appear in this proposal, or be
    communicated to the compiler committee so that we can put it in one of
    our issues. 

This should be covered the "normal" way, like any other defining form, by 
the cl-compiler issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS.  I think
it should be implicitly eval-when(eval compile load).

Incidentally, echoing my previous sentiment, it seems simpler and hence
preferable to force the issue on COMPIL-FILE -- simply say that certain
toplevel forms are defaultly eval-when(eval compile load), unless the user 
explicitly wraps some other eval-when around them.  It's far too confusing 
to worry about when COMPILE-FILE retracts definitions that were in effect
"for the duration" of the compilation.  KMP also expressed this sentiment
when replying about the options for DEFCONSTANT-HARD-WIRED (or whatever).



re: I would also like to see more detail on the order that the various things
    are supposed to happen in, in the expansion of the macro.  I'm guessing 
    that it's supposed to be the same as "Put In Seven Extremely Random ..." 
    but I think the description needs to be more explicit.

The proposal does say something about this, and the only time ordering 
dependencies that are important (I think) are:
  (1) the package must be created, with it's :use links all set up, before
      any symbols are placed into it
  (2) most of the symbol creators/importers have to be disjoint, so it
      doesn't matter what order they are performed in.  The exception is
      :EXPORT.  The relevant wording from the proposal is:
	The collection of symbol-name arguments given to the options :SHADOW,
	:INTERNAL, :IMPORT-FROM, and :SHADOWING-IMPORT-FROM must all be
	disjoint; an error is signalled otherwise.  The :EXPORT option can
	be thought of as occuring after all the other options have been
	executed, since it may reference names found in "used" packages, 
	or found in the argument lists to a :SHADOW, :INTERNAL, :IMPORT-FROM, 
	or :SHADOWING-IMPORT-FROM option.

Perhaps a line or two like (1) and (2) could be added for clarity?


re: Finally, what is the motivation for not having DEFPACKAGE setq *PACKAGE*?

Defining forms usually just establish a name-to-object mapping; there is
little precedent for them also modifying global context state.  The one
form that is currently "confused" this way is the subject of an important
cleanup issue IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY to restore simplicity.

Note that if DEFPACKAGE also did an IN-PACKAGE, then the following 
reasonable file would become somewhat jumbled, because it wouldn't all 
be in on package:
   (in-package "USER")
   (defpackage "PHLOGISTON" (:use "LISP")             (:export "FIRE"))
   (defpackage "ALCHEMY"    (:use "LISP" "PHLOGISTON) (:export "GOLD"))



-- JonL --

∂21-Oct-88  1912	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 5)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Oct 88  19:12:31 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00724g; Fri, 21 Oct 88 19:12:14 PDT
Received: by bhopal id AA12781g; Fri, 21 Oct 88 19:10:42 PDT
Date: Fri, 21 Oct 88 19:10:42 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810220210.AA12781@bhopal>
To: peck@Sun.COM
Cc: CL-Cleanup@Sail.stanford.edu
In-Reply-To: peck@Sun.COM's message of Mon, 17 Oct 88 17:19:14 -0700 <8810180019.AA06479@denali.sun.com>
Subject: Issue: DEFPACKAGE (version 5)

re: I suggest that the :INTERNAL option be renamed :INTERN.

Hmmm, you've indeed exposed a serious discompatibility in nomenclature
style.  But I think I'd prefere to see the :EXPORT option renamed to
be :EXTERNAL rather than introduce a gratuitously new keyword [note
that symbols present in a package must be either :INTERNAL or :EXTERNAL.]

Anyone else on CL-Cleanup have a preference?


re: The rest of the question is whether using the :LISP package is done
    in the MAKE-PACKAGE, or lastly, in the (USE-PACKAGE). 

If the DEFPACKAGE form doesn't specify a :USE option, then the obvious
thing to do is to default it exactly the same as MAKE-PACKAGE would.  
[Incidentally, the name of the relevant issue on this topic is something 
like MAKE-PACKAGE-USE-DEFAULT -- PACKAGE-CLUTTER is a separte issue].


re:                                            . . . Like all USE'ing
    this should be deferred until after the shadowing is done, no?

Ooops, I guess you're right.  Shadowing that creates new symbols isn't
important; but shadowing that in effect "blocks" the inheritance of two 
different symbols with the same name must be done before the "using".
So the package should be created with a :use list of NIL, then the
two "shadowings" should be done (if any), then the :IMPORT and :INTERNAL
ones done, and then finally the :EXTERNAL.


re: Clarify that the order of the clauses in the source code has no effect.

Right! good point.  Indeed this will have to go in the ultimate version.


re: Also, it says re: side-effects "ie, no IN-PACKAGE is done", 
    clarify that this does not proscribe an implementation like: ...

I guess the more clear way to say what was intended here is that the
evaluation of a DEFPACKAGE form does not change the value of *package*.

I'll make another version "soon", to incorporate your "nits" and those
of Sandra and myself.



-- JonL --

∂21-Oct-88  1951	CL-Cleanup-mailer 	issue DECLARATION-SCOPE   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Oct 88  19:51:36 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00737g; Fri, 21 Oct 88 19:51:21 PDT
Received: by bhopal id AA12854g; Fri, 21 Oct 88 19:49:49 PDT
Date: Fri, 21 Oct 88 19:49:49 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810220249.AA12854@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Thu, 13 Oct 88 14:13:43 MDT <8810132013.AA19827@defun.utah.edu>
Subject: issue DECLARATION-SCOPE

re: (1) The treatment of TYPE declarations contradicts proposal
    DECLARE-TYPE-FREE.  I don't think I could vote for either proposal
    without some better indication of how they are supposed to work
    together. 

The source of much confusion here has long been that TYPE declarations had 
to be treated differently from all other declarations; this was  because of 
the crazy prohibition found on p158 of CLtL.  Let's assume for now that 
DECLARE-TYPE-FREE is accepted; then I think we can just flush all crazy 
categorizations into "pervasive"/"non-pervasive" and  "free"/"bound" and 
simply say that declarations:
  (1) always include the lexical scope of the body of the special form 
      in which  they are found;
  (2) and furthermore, they also include the scope of the name-bindings, 
      if any, to which they apply.  [LET, LAMBDA, FLET, and LABELS 
      introduce "name bindings"; LOCALLY doesn't.]
Since the scope of a "name-binding" also includes the body as mentioned
in (1), then the only additional comment needed concerns LET* and LABELS.

We might need to be reminded that:
  -- for LET*, a variable's scope also includes the remaining value
     forms, for subsequent variable bindings;
  -- for LABELS, a function name's scope includes all the code for the
     functions being defined [presumably, compiler writers know how not 
     to get into an infinite loop of in-line substitutions in these cases];

We might also need to be reminded that new name-bindings "shadow" (after
a fashion) any higher level binding or declarations.  E.g., presuming
no proclamations, consider the inner let bindings of:
   (locally (declare (special x) (float y)) 
     (let ((x 5) (y 10)) 
       (print (+ x y))))
then x is bound is local, not special; and y is bound with no particular
type information [because the 'y' being bound is a different variable
than the 'y' declared float in the outter scope].



-- JonL --

∂21-Oct-88  2019	CL-Cleanup-mailer 	Issue: FUNCTION-COERCE-TIME (Version 2)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Oct 88  20:19:43 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00752g; Fri, 21 Oct 88 20:17:59 PDT
Received: by bhopal id AA12917g; Fri, 21 Oct 88 20:16:26 PDT
Date: Fri, 21 Oct 88 20:16:26 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810220316.AA12917@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Thu, 13 Oct 88 17:03 EDT <881013170353.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-COERCE-TIME (Version 2)

re:  My notes from Fairfax meeting...
     . . . 
     JonL had some critical comments, but KMP couldn't understand them
     and believes it was because JonL didn't read the proposals carefully
     and was commenting on a superficial reading that led him to incorrect 
     conclusions.

This note doesn't say anyting at all to me (presumably it meant something
to you at the time?).

I favor FUNCTION-COERCE-TIME:HYBRID.

The proposal is ovely opaque because it is trying to be overly general.
Given the "cleanup" that we've already accepted for the FUNCTION type,
then the only non-"functions" that can be passed to the functions of
reference (MAP, SORT, SET-MACRO-CHARACTER, etc) are SYMBOLS.  Also,
it should be noted that the "coercion" involved is merely SYMBOL-FUNCTION.


-- JonL --

∂21-Oct-88  2032	CL-Cleanup-mailer 	Issue: FUNCTION-COMPOSITION (Version 2)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Oct 88  20:32:01 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00758g; Fri, 21 Oct 88 20:31:46 PDT
Received: by bhopal id AA12949g; Fri, 21 Oct 88 20:30:15 PDT
Date: Fri, 21 Oct 88 20:30:15 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810220330.AA12949@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Thu, 13 Oct 88 17:08 EDT <881013170837.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-COMPOSITION (Version 2)

re: My notes from Fairfax meeting...
    . . . 
     JonL: Gratuitous.
       Also, no existing implementations have this.
       [He didn't seem willing to count the T language. -kmp]

[I don't remember saying this, but if I did, it certainly would be
defensible on the grounds that we are standardizing Common Lisp, not T].

As I've outlined earlier, this is the sort of gratuitious addition to the 
language that ought to be tested first -- tested  by it's utililty to some 
vendor/implementor who feels it's worth the risk to add something like it
to his product.  I deplore the tendency to think that vendors shouldn't make
an offering unless it is "sanctioned" by the X3J13 committee.

I say "gratuitious" because
  (1) no vendor/implementor supplies them now; thus it is not "existing 
      practice" that needs to be standardized;
  (2) no fundamental problem has been exposed because of its lack; no
      implementational headaches would be resolved, and few (if any) pleas
      from the user community would be addressed;
  (3) no confusions exists among our community as to what these functionals
      (or similar such features) mean; hence no need to clarify.


-- JonL --

∂24-Oct-88  1816	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
Received: from PECAN.CS.ROCHESTER.EDU ([192.5.53.206]) by SAIL.Stanford.EDU with TCP; 24 Oct 88  18:16:16 PDT
Received: from DOUGHNUT.CS.ROCHESTER.EDU by PECAN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 4702; Mon 24-Oct-88 21:07:30 EDT
Date: Mon, 24 Oct 88 21:06 EDT
From: Brad Miller <miller@CS.ROCHESTER.EDU>
Subject: Re: Issue: EVAL-OTHER (Version 2) 
To: Jon L White <jonl@LUCID.COM>
cc: masinter.pa@XEROX.COM, common-lisp-object-system@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8810210017.AA06100@bhopal>
Message-ID: <19881025010655.7.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Sender: miller@CS.ROCHESTER.EDU
Reply-To: miller@CS.ROCHESTER.EDU
Organization: University of Rochester, Department of Computer Science
Postal-address: 610 CS Building, Comp Sci Dept., U. Rochester, Rochester NY 14627
Phone: 716-275-1118

    Date: Thu, 20 Oct 88 17:17:51 PDT
    From: Jon L White <jonl@lucid.com>

    re: w/o generic EVAL or APPLY, CLOS is just a bag on the side of CL. 

    I can't agree with this at all.  CL is an extremely useful programming
    language, and with CLOS added it is incredibly more  useful.  EVAL
    is a boringly obscure operation to apply to any piece of data -- it
    merely decodes the syntatic means by which programs are written.  Writing
    programs encoded as strings rather than lists and symbols, or encoded in 
    *any* other random datatype, is hardly a great step forward.

    While that last sentence might be open to continuing theoretical debate,
    there is the practical observation that MacLisp/NIL *did* make such an
    extension (using the object-oriented system called EXTEND), and there
    were virtually no meaningful uses of it.  [I'm not 100% sure but I think
    Glenn Burke may have used it somehow in the Layered System Building
    project.  Apologies, if that use was "meaningful".]

    In fact, the EVAL-related extension that really has some vocal supporters
    behind it is to *increase* the level on standardization in the coding of 
    EVAL, so that research projects into the likes of debuggers and window 
    systems can put more "hooks" into the interpreter.  See Henry Lieberman's
    "Common Eval" proposal.


    -- JonL --

I plan on writing you a response to this, but I'm currently swamped;
just to let you know that my silence isn't agreement. I suspect the
fault was mostly mine: I only gave a trivial example of such use, and
I can give much better ones from my work on the RHET project.

The short cleanup is that while theoretically a full-blown generic
EVAL is "interesting", I certainly *don't* consider it practical. I'm
simply trying to allow the user to specify an eval-function for user
created types, rather than having them always self-eval. Generating
code for these types as (EVAL-YOURSELF <instance>) rather than
<instance> doesn't seem to be a particularly difficult implementation
problem, nor do I think it has a particular bad effect on debuggers.
Appropriate method combination for EVAL-YOURSELF should allow for a
debugger hook (though I've not thought this through carefully).

Thanks for your response.

More later,
----
Brad Miller		U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}

∂25-Oct-88  1122	CL-Characters-mailer 	Re: cs proposal   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 25 Oct 88  11:22:31 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 25 OCT 88 11:03:47 PDT
Date: 25 Oct 88 11:03 PDT
From: masinter.pa@Xerox.COM
Subject: Re: cs proposal
In-reply-to: Thom Linden <baggins@ibm.com>'s message of Tue, 25 Oct 88
 09:51:42 PDT
To: Thom Linden <baggins@ibm.com>
cc: "X3J13: Character Subcommittee" <cl-characters@sail.stanford.edu>,
 yuasa%tutics.tut.junet%utokyo-relay.CSNet@relay.cs.net,
 rpk@wheaties.ai.mit.edu, brent%hpfcpsb@hplabs.hp.com,
 sandra%defun@cs.utah.edu, vanroggen%atig.dec@decwrl.dec.com,
 moon@stony-brook.scrc.symbolics.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881025-110347-11299@Xerox>

Thom:

The proposal did not ever say explicitly, and I feel strongly that it
should, that in fact Common Lisp *requires* absolutely no changes in order
to support extended character sets. The language as specified in CLtL is
entirely adequate to allow handling of multiple, international character
sets. The implementation of Xerox Common Lisp, now available on Xerox 1100
series workstations and Sun 3 and Sun 4 workstations, is an existance
proof.

There is a price, however, that implementations must pay in order to use
CltL unchanged. The price can either be in terms of space -- reserving
enough bits per character in a string -- or in terms of speed, in
implementations in which not all strings are displacable. (Briefly, the
implementation technique is to allocate a smaller number of bits per
character than the maximum in most strings, but allow for strings to be
displaced.)

Thus, the only changes to the language that can be justified from the point
of view of allowing support of International Character Sets are those that
have an arguably more efficient implementation.  The change to the type
hierarchy, the modification of the STRING type from an abbreviation of
(VECTOR STRING-CHAR) to an indefinite union of types, and the various
changes associated with that to STRINGP etc. should be justified by some
explicit rationale as to the efficiency of the implementations under that
regime.

The Character Proposal includes several other enhancements and
modifications which are probably good ideas, but which require separate
discussion and justification. Removing CHAR-FONT is a good idea, because
the feature is not used. Removing CHAR-BITS is probably a good idea,
because the feature is not used widely, and was (perhaps) based on a design
decision which confounded keystrokes with characters and which allowed for
"characters" which could not be held in "strings". These changes can and
should be justified completely independently of any notion of
"international character set handling".

Extending the "CHARACTER" type specifier to have a list form is probably a
good idea, although it does not conform to any current practice, as it
allows a single existing mechanism to provide what is otherwise an
overambitious proliferation of character-predicate functions in an easily
extensible manner. (Implementations that do not support hiragana can easily
support (typep x '(character :hiragana)) == NIL.) This is related to the
support of international character sets, but hardly required. Certainly
this does not go far enough to allow portable programs to be written. For
one small example, the proposal is silent about what char-upcase and
char-downcase do on greek or cyrillic characters, or accented characters in
european alphabets. Would not portable language manipulation programs would
need portable definitions of these? Is there some reason in principle for
not agreeing on the operation of CHAR-UPCASE? Are hiragana characters
ALPHA-CHAR-P? Etc.

The discussion of the proposal frequently confounds two separate
distinctions, of "backward compatibility" and "portability". Our primary
goal is to allow "portable" programs -- programs that, if written in the
standard language, will run unchanged in all implementations that support
the standard language.  We try to achieve that while also supporting
"backward compatibility" -- programs that run in current implementations of
Common Lisp should continue to work correctly unchanged. I fear that the
proposal, in the name of efficiency and backward compatibility,  damages
the portability of the resulting language, because it allows programs to
rely on implementation-dependent details of the nature of strings. It
damages backward compatibility, because valid programs that manipulated
strings will no longer be correct. And it does not make a convincing
argument that it has actually solved the problem of *efficient*
international character set handling.

I think you've done an admirable job of establishing the scope and extent
of possible changes to Common Lisp in the area of character handling.
However, I would like to see the proposal split up into separate "issues"
which each have their own pros and cons. I would like to see this happen so
that the cleanup committee doesn't have to clean up after the character
committee is done. 

Sincerely,

Larry Masinter


∂25-Oct-88  1330	CL-Cleanup-mailer 	Re: Issue: THE-AMBIGUITY  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 25 Oct 88  13:30:40 PDT
Received: by ti.com id AA01365; Mon, 24 Oct 88 20:04:07 CDT
Received: from Kelvin by tilde id AA29658; Mon, 24 Oct 88 19:59:19 CDT
Message-Id: <2802733274-1499644@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 24 Oct 88  20:01:14 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: jar@ZURICH.AI.MIT.EDU
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: THE-AMBIGUITY
In-Reply-To: Msg of Fri, 21 Oct 88 16:05:49 EDT from Jonathan Rees <jar@void.ai.mit.edu>

> Current practice:
> 
>   The Symbolics Genera and VAX LISP V2.2 interpreters signal errors for
> 
> 	(THE (FUNCTION (T T) CONS) #'CONS),
> 
>   but this may not be intentional.  CLtL would seem to allow it.

The TI Explorer permits this, so is consistent with proposal
THE-AMBIGUITY:FOR-DECLARATION. 

> Test case:
> 
>   (THE (FUNCTION (T T) CONS) #'CONS),
> 
>   should return the CONS function under THE-AMBIGUITY:FOR-DISCRIMINATION,
>   and should be an error under THE-AMBIGUITY:FOR-DECLARATION.

Shouldn't that be the other way around?

>   For THE-AMBIGUITY:FOR-DECLARATION, implementations that do not
>   already allow arbitrary type specifiers but which want to check that
>   the type in a THE is satisfied would have to create an internal
>   version of TYPEP which could manage not to signal invalid-type-specifier
>   errors in those situations where TYPEP would because the type is a
>   declaration-only one.

What you really want is an internal function that tests whether a type
specifier is valid for TYPEP and the compiler uses that to decide
whether to generate a call to TYPEP.  Since types should be defined before
being used in a declaration, there shouldn't be any need to postpone this
decision to runtime.

∂25-Oct-88  1333	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 25 Oct 88  13:33:35 PDT
Received: by ti.com id AA01008; Mon, 24 Oct 88 18:34:06 CDT
Received: from Kelvin by tilde id AA28622; Mon, 24 Oct 88 18:23:26 CDT
Message-Id: <2802727517-1153780@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 24 Oct 88  18:25:17 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Sandra J Loosemore <sandra%defun@CS.UTAH.EDU>
Cc: "Dan L. Pierson" <pierson%mist@MULTIMAX.ENCORE.COM>,
        CL-Cleanup@SAIL.Stanford.edu
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
In-Reply-To: Msg of Tue, 18 Oct 88 09:40:02 MDT from Sandra J Loosemore <sandra%defun@CS.UTAH.EDU>

> This looks better, but I feel really uncomfortable with the idea that
> an implementation would be allowed to decide on its own that modules
> which haven't been PROVIDE'd have been loaded anyway. 

It makes sense in the scenario where you say (REQUIRE "foo") where you
have defined in some implementation-dependent way what to do to install
"foo", then it would be reasonable to assume that after doing that,
"foo" has now been provided even if there wasn't an explicit PROVIDE
call in one of the files.  This would permit a user to define a module
name for a group of files without having to edit a file to add a
PROVIDE.  

For example, on the Explorer, REQUIRE with one argument calls
MAKE-SYSTEM, and MAKE-SYSTEM calls PROVIDE when it is finished.  
Can you feel comfortable with permitting that?

∂25-Oct-88  1344	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 Oct 88  13:44:07 PDT
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA02305; Tue, 25 Oct 88 14:43:13 MDT
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA28871; Tue, 25 Oct 88 14:42:57 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810252042.AA28871@defun.utah.edu>
Date: Tue, 25 Oct 88 14:42:56 MDT
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: Sandra J Loosemore <sandra%defun@CS>,
        "Dan L. Pierson" <pierson%mist@MULTIMAX.ENCORE.COM>,
        CL-Cleanup@SAIL.Stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Mon, 24 Oct 88  18:25:17 CDT


> Date: Mon, 24 Oct 88  18:25:17 CDT
> From: David N Gray <Gray@DSG.csc.ti.com>
> 
> For example, on the Explorer, REQUIRE with one argument calls
> MAKE-SYSTEM, and MAKE-SYSTEM calls PROVIDE when it is finished.  
> Can you feel comfortable with permitting that?

I think it's reasonable for MAKE-SYSTEM (or LOAD-SYSTEM, or whatever)
to implicitly or explicitly do a PROVIDE, since MAKE-SYSTEM is not
part of standard Common Lisp.  I'm more concerned about forbidding
things that -are- part of the standard language (like LOAD) from
having side effects that make REQUIRE behave differently in different
implementations.

Also, I don't think that making REQUIRE automatically do a MAKE-SYSTEM
is in the spirit of this proposal, which is intended to make REQUIRE
strictly declarative and never cause anything to be loaded without
user intervention.

-Sandra
-------

∂25-Oct-88  1614	CL-Cleanup-mailer 	Re: Issue: ALIST-NIL (Version 4)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 25 Oct 88  16:14:22 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 25 OCT 88 16:07:07 PDT
Date: 25 Oct 88 16:07 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ALIST-NIL (Version 4)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Thu, 13 Oct 88 15:35 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@Sail.Stanford.EDU 
Message-ID: <881025-160707-12043@Xerox>

I think the cleanup committee is, for the most part, mildly opposed to this
change, and the issue writeup should probably say that.


∂25-Oct-88  1632	CL-Cleanup-mailer 	RE: Issue: CLOSED-STREAM-OPERATIONS (version 3)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 25 Oct 88  16:32:03 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 25 OCT 88 16:31:40 PDT
Date: 25 Oct 88 16:31 PDT
From: masinter.pa@Xerox.COM
Subject: RE: Issue: CLOSED-STREAM-OPERATIONS (version 3)
In-reply-to: vanroggen%aitg.DEC@decwrl.dec.com's message of Mon, 17 Oct 88
 12:34:44 PDT
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881025-163140-12090@Xerox>

I think the goal is to standardly allow those operations that are usually
implemented and are useful.

I thus think it is useful to address explicitly the questions Kent asks --
I don't think we can or should finess them.

I would prefer INPUT-STREAM-P and OUTPUT-STREAM-P to return false for
streams which do not admit input or output respectively, which, I think,
includes closed streams.

So:

After a stream has been closed:

(STREAMP closed-stream)	returns true
(INPUT-STREAM-P closed-stream) returns false
(OUTPUT-STREAM-P closed-stream) returns false
(CLOSE stream) returns NIL (?)

All of the other functions in the list are the ones that that accept a
stream and coerce it to a pathname work at least as specifically as they
would with the open stream. (This is subject to some further work on the
pathname functions; the idea is that once the stream is CLOSEd that the
stream object may have *more* specific pathname information associated with
it than before, and that in some way the pathname used should be
best-effort name to get at the same data. )


The point here is that if I want to write out some data and read it back in
later, I should be able to

(let((saved-file (pathname (with-open-file (x pathname :direction :output)
(print stuff x) x))))
   (with-open-file (x saved-file :direction :input)
       (read x)))

and expect the second with-open-file to get at the same data that the first
one wrote.

The operation of CLOSE on constructed streams (as constructed with
WITH-OUTPUT-TO-STRING or MAKE-BROADCAST-STREAM) should be specified to have
no effect. 

∂25-Oct-88  1655	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 25 Oct 88  16:55:41 PDT
Received: by ti.com id AA02863; Tue, 25 Oct 88 18:50:53 CDT
Received: from Kelvin by tilde id AA21593; Tue, 25 Oct 88 18:31:40 CDT
Message-Id: <2802814400-1415862@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 25 Oct 88  18:33:20 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Cc: "Dan L. Pierson" <pierson%mist@MULTIMAX.ENCORE.COM>,
        CL-Cleanup@SAIL.Stanford.edu
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
In-Reply-To: Msg of Tue, 25 Oct 88 14:42:56 MDT from sandra%defun@cs.utah.edu (Sandra J Loosemore)

> I think it's reasonable for MAKE-SYSTEM (or LOAD-SYSTEM, or whatever)
> to implicitly or explicitly do a PROVIDE, since MAKE-SYSTEM is not
> part of standard Common Lisp.

I thought that was the intent of the phrase "permit environment-specific
extensions", but evidently it needs to be clarified.

>    I'm more concerned about forbidding
> things that -are- part of the standard language (like LOAD) from
> having side effects that make REQUIRE behave differently in different
> implementations.

Agreed.

> Also, I don't think that making REQUIRE automatically do a MAKE-SYSTEM
> is in the spirit of this proposal, which is intended to make REQUIRE
> strictly declarative and never cause anything to be loaded without
> user intervention.

Right; that's what is bothering me.  This proposal really does two things:

 1. It eliminates the second argument of REQUIRE.
 2. It changes the meaning of calling REQUIRE with one argument from what
    CLtL says at the bottom of page 188.

I agree with the first change.  I do not agree with the second change, and
there is nothing in the "rationale" to justify it.  All of the discussion
has been addressing the first change only.  Where did this second change
come from?

∂25-Oct-88  1723	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 Oct 88  17:23:30 PDT
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA12825; Tue, 25 Oct 88 18:22:42 MDT
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA28990; Tue, 25 Oct 88 18:22:35 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810260022.AA28990@defun.utah.edu>
Date: Tue, 25 Oct 88 18:22:33 MDT
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: sandra%defun@cs (Sandra J Loosemore),
        "Dan L. Pierson" <pierson%mist@MULTIMAX.ENCORE.COM>,
        CL-Cleanup@SAIL.Stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Tue, 25 Oct 88  18:33:20 CDT

> Date: Tue, 25 Oct 88  18:33:20 CDT
> From: David N Gray <Gray@DSG.csc.ti.com>
> 
> This proposal really does two things:
> 
>  1. It eliminates the second argument of REQUIRE.
>  2. It changes the meaning of calling REQUIRE with one argument from what
>     CLtL says at the bottom of page 188.
> 
> I agree with the first change.  I do not agree with the second change, and
> there is nothing in the "rationale" to justify it.  All of the discussion
> has been addressing the first change only.  Where did this second change
> come from?

The problem with calling REQUIRE without an argument, as it's
currently defined, is that you have no guarantee that it will know
where to find the right files.  There is not much point in having the
language specify a standard mechanism like this, if there is no
portable way to use it.  So, when the proposal says that the
file-loading feature of REQUIRE is nonportable, it's referring to both
the case where you give it an explicit pathname, and the case where
you don't.

My original proposal on this issue specified how REQUIRE should look
for files to load, using a search list of pathnames to be merged with
the module name.  (Implementations could still use some other
nonportable module registry mechanism if that failed to find
anything.) For various reasons, this idea was discarded by the cleanup
committee and for a time there was talk of flushing PROVIDE and
REQUIRE entirely.  Just about anything would be better than the
current situation, and I really don't have any problems with the
current proposal other than the one nit I've already brought up. 

The variation between implementations on what they do to REQUIRE
without a pathname argument is ridiculous.  As you've already noted,
the Explorer treats REQUIRE as a hook into DEFSYSTEM.  PCLS and HPCL-I
use a search list similar to what I originally was proposing, probably
because PSL had something similar.  VaxLisp (at least on VMS) uses a
logical name for the directory containing the files.  KCL looks only
in *DEFAULT-PATHNAME-DEFAULTS*, and I think that's what Lucid does too
(their documentation doesn't say).

-Sandra
-------

∂26-Oct-88  0906	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 26 Oct 88  09:05:51 PDT
Received: by ti.com id AA08516; Wed, 26 Oct 88 11:04:39 CDT
Received: from Kelvin by tilde id AA12560; Wed, 26 Oct 88 10:47:28 CDT
Message-Id: <2802872949-4933586@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 26 Oct 88  10:49:09 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Cc: "Dan L. Pierson" <pierson%mist@MULTIMAX.ENCORE.COM>,
        CL-Cleanup@SAIL.Stanford.edu
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
In-Reply-To: Msg of Tue, 25 Oct 88 18:22:33 MDT from sandra%defun@cs.utah.edu (Sandra J Loosemore)

> The variation between implementations on what they do to REQUIRE
> without a pathname argument is ridiculous.  As you've already noted,
> the Explorer treats REQUIRE as a hook into DEFSYSTEM.  PCLS and HPCL-I
> use a search list similar to what I originally was proposing, probably
> because PSL had something similar.  VaxLisp (at least on VMS) uses a
> logical name for the directory containing the files.  KCL looks only
> in *DEFAULT-PATHNAME-DEFAULTS*, and I think that's what Lucid does too
> (their documentation doesn't say).

Suppose we said that REQUIRE uses an implementation-defined registry of
module names and actions to be performed, if the implementation provides
such a feature, but that it does not try to guess what to do in the
absence of any kind of module definition.  I think that would permit what
I want to do, while ruling out surprising or unwanted behavior.

∂26-Oct-88  1151	CL-Cleanup-mailer 	Issue: COERCE-INCOMPLETE  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 26 Oct 88  11:51:28 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 26 OCT 88 11:40:05 PDT
Date: 26 Oct 88 11:37 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: COERCE-INCOMPLETE
To: cl-cleanup@sail.stanford.edu
Message-ID: <881026-114005-13463@Xerox>

a) the definition of COERCE says that "If {\arg object} is already of {\arg
result-type} (as determined by 
{\function typep}), {\arg object}
is returned. Copying of {\arg object} is not necessary."

Should this say "is not performed"? That is, 
(when (typep x y) (assert (eql x (coerce x y))))

for all objects x, for all valid type specifiers y?

Are there any implementations that do copy any types?

I think the specification of COERCE will be clearer if the operation is
described sorted by type specifier rather than by the type of the object. I
think that's how most implementations work. However, the description starts
out talking about the type of "object" and only then talks about the type
specifiers.

Certainly this is a "multi-method", but the resolution is right-to-left
rather than left-to-right, I think.

Does COERCE work for types that are DEFTYPEd? I.e.,

(DEFTYPE FROB () '(VECTOR (SIGNED-BYTE 3)))
(COERCE X 'FROB)?

The Problem Statement is that Coerce is incomplete and confusing. We may
not need to change the language to fix the problem, but we certainly need
to clear up the description.

∂26-Oct-88  1151	CL-Cleanup-mailer 	Re: Issue: CONSTANT-SIDE-EFFECTS (no proposal)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 26 Oct 88  11:51:42 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 26 OCT 88 11:42:27 PDT
Date: 26 Oct 88 11:42 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: CONSTANT-SIDE-EFFECTS (no proposal)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Thu, 20 Oct 88
 21:07:35 PDT
To: Jon L White <jonl@lucid.com>
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881026-114227-13467@Xerox>

While it is certainly possible to address the issue by making "constant" a
first-class run-time accessable property of data, I don't think we are
going to make a lot of progress if we choose that direction.

I think what we need here is a more accurate specification of what actually
is allowed and what is not, even though "constant" is not a first-class
attribute of data.

It is harder to specify, certainly. The specification might require the
introduction of a conceptual construct. There is no need, however, to
require implementations to actually reify the concept in order to make use
of it.


∂26-Oct-88  1320	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATION 
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 26 Oct 88  13:20:09 PDT
Date: 26 Oct 1988 16:19-EDT
Sender: ROSENKING@A.ISI.EDU
Subject: Issue: CLOSED-STREAM-OPERATION
From: ROSENKING@A.ISI.EDU
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]26-Oct-88 16:19:06.ROSENKING>


Status:	Draft
Issue:			CLOSED-STREAM-OPERATIONS
References:		CLOSE (CLtL, page 332 and ANSI Draft, page 
6-40)
Category:		CLARIFICATION
Edit History:		26-Aug-88, 	Version 1 by Chapman
			08-Oct-88, 	Version 2 by Masinter
			26-Oct-88, 	Version 3 by Rosenking

Related Issues:	STREAM-CAPABILITIES, STREAM-ACCESS, STREAM-
INFO

Problem Description:

Based on the type of stream, and the implementation used, when a 
stream is closed  using the close operation it may return one of
several different values, including the stream name or T, or even
an error if it was a broadcast or concatenated stream in the MAC
implementation which was already closed.

Proposal:

Require that CLOSE return the stream name at all times, of the form 
#<stream>, and that it is an error to perform any operation on a closed stream.

Rationale:

This will standardize the use of CLOSE on all implementations and 
require that only streams which are not closed may be closed.

Current Practice:

Depending upon the type of stream and implementation a variety of 
values may be returned, as stated above.

Adoption Cost:

None.

Benefits:

This clarification will assist users in writing portable code.

Conversion Cost:

None.

Aesthetics:

None

Discussion:

∂26-Oct-88  1346	CL-Cleanup-mailer 	Issue: CONCATENATE-STREAM-EXAMPLE   
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 26 Oct 88  13:46:33 PDT
Date: 26 Oct 1988 16:45-EDT
Sender: ROSENKING@A.ISI.EDU
Subject: Issue: CONCATENATE-STREAM-EXAMPLE
From: ROSENKING@A.ISI.EDU
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]26-Oct-88 16:45:31.ROSENKING>

←

Status:	Initial Proposal
Issue:			MAKE-CONCATENATED-STREAM-EXAMPLE
References:		MAKE-CONCATENATED-STREAM
          			 (CLtL, page 329, and ANSI Draft, page 6-19)
Category:		CLARIFICATION
Edit History:		26 -Oct-88, Version 1 by Rosenking

Related Issues:

Problem Description:

When evaluating the example from the ANSI Draft standard, shown below,

	(read (make-concatenated-stream
		     (make-string-input-stream "1")
		     (make-string-input-stream "2")))

the value returned is either 12, from MAC and VAX implementations, or 1, from 
the Symbolics implementation. 

Proposal:

Specify the correct value to be returned and verify that other implementations
do not make the same mistake.  (Note: I sent a bug report to Symbolics.)

Rationale:

For purposes of conformance and validity.

Current Practice:

As stated above.

Adoption Cost:

Benefits:

Conversion Cost:

Aesthetics:

Discussion:

∂26-Oct-88  1347	CL-Cleanup-mailer 	Issue: INPUT-STREAM-P-EXAMPLE  
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 26 Oct 88  13:47:12 PDT
Date: 26 Oct 1988 16:46-EDT
Sender: ROSENKING@A.ISI.EDU
Subject: Issue: INPUT-STREAM-P-EXAMPLE
From: ROSENKING@A.ISI.EDU
To: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]26-Oct-88 16:46:53.ROSENKING>


←

Status:	Initial Proposal
Issue:			INPUT-STREAM-P-EXAMPLE
References:		INPUT-STREAM-P (CLtL, page 332, ANSI Draft, page 6-36)
Category:		CLARIFICATION
Edit History:		26 -Oct-88, Version 1 by Rosenking

Related Issues:

Problem Description:

When evaluating the example from the ANSI draft, shown below,

	(input-stream-p (make-broadcast-stream))

the value returned is either NIL, in MAC and VAX implementations, or T in 
Symbolics implementations.

Proposal:

Specify the correct value to be returned and verify that other implementations
do not make the same mistake.  (Note: I sent a bug report to Symbolics.)

Rationale:

For validity and conformance.

Current Practice:

Adoption Cost:

Benefits:

Conversion Cost:

Aesthetics:

Discussion:

∂26-Oct-88  1350	CL-Cleanup-mailer 	Issue: OUTPUT-STREAM-P-EXAMPLE 
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 26 Oct 88  13:50:02 PDT
Date: 26 Oct 1988 16:48-EDT
Sender: ROSENKING@A.ISI.EDU
Subject: Issue: OUTPUT-STREAM-P-EXAMPLE
From: ROSENKING@A.ISI.EDU
To: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]26-Oct-88 16:48:14.ROSENKING>


←

Status:	Initial Proposal
Issue:			OUTPUT-STREAM-P-EXAMPLE
References:		OUTPUT-STREAM-P (CLtL, page 332, ANSI Draft, page 6-37)
Category:		CLARIFICATION
Edit History:		26 -Oct-88, Version 1 by Rosenking

Related Issues:

Problem Description:

When evaluating the example from the ANSI draft, shown below,

	(output-stream-p (make-concatenated-stream))

the value returned is either NIL, in MAC and VAX implementations, or T in 
Symbolics implementations.

Proposal:

Specify the correct value to be returned and verify that other implementations
do not make the same mistake.  (Note: I sent a bug report to Symbolics.)

Rationale:

For validity and conformance.

Current Practice:

Adoption Cost:

Benefits:

Conversion Cost:

Aesthetics:

Discussion:

∂26-Oct-88  1350	CL-Cleanup-mailer 	Issue: STREAM-ELEMENT-TYPE-EXAMPLES 
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 26 Oct 88  13:50:18 PDT
Date: 26 Oct 1988 16:49-EDT
Sender: ROSENKING@A.ISI.EDU
Subject: Issue: STREAM-ELEMENT-TYPE-EXAMPLES
From: ROSENKING@A.ISI.EDU
To: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]26-Oct-88 16:49:53.ROSENKING>


←

Status:	Initial Proposal
Issue:			STREAM-ELEMENT-TYPE-EXAMPLES
References:		STREAM-ELEMENT=TYPE (CLtL, page 332, ANSI Draft, 
								page 6-38)
Category:		CLARIFICATION
Edit History:		26 -Oct-88, Version 1 by Rosenking

Related Issues:

Problem Description:

Below is a list of the examples and specified outputs which are used in the
ANSI draft standard.

(stream-element-type *debug-io*)   --->   STRING-CHAR
(stream-element-type (make-concatenated-stream))   -->   T
(setq s (open "tempfile.temp"
		:element-type 'bit
		:if-does-not-exist :create))   -->   <stream identifier>
(stream-element-type s)   -->   (INTEGER 0 1)

The following describes the inconsistencies with the above examples.  
The first expression returns the value STRING-CHAR when executed on the Mac, 
but when executed on the Symbolics it returns the value CHARACTER (Note: 
STRING-CHAR is a subtype of CHARACTER). 

The second expression returns the value T when executed on the Symbolics, 
though it returns the value STRING-CHAR when executed on the Mac, and it then
 returns the value NIL when executed on the VAX.

The third expression does not evaluate correctly on the Symbolics and VAX
implementations where the :direction keyword default value is :input, though
it does evaluate correctly on the MAC implementation where the default value
for :direction is :output.

The fourth expression also returns different values. On the MAC and VAX
implementations the value BIT is returned for this expression, while
Symbolics returns the value (UNSIGNED-BYTE 16). The :direction :output 
specification had to be made to the third expression in order for the VAX
and Symbolics implementations to evaluate the last expression.

Proposal:

Clarify what the appropriate outputs for each of these expressions should be
over all implementations.

Rationale:

For validity and conformance.

Current Practice:

As stated in problem description for each expression and implementation.

Adoption Cost:

Benefits:

Standardization and portability.

Conversion Cost:

Aesthetics:

Discussion:

∂26-Oct-88  1501	CL-Cleanup-mailer 	Re: Issue: CONCATENATE-STREAM-EXAMPLE    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 26 Oct 88  15:01:28 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 26 OCT 88 14:49:10 PDT
Date: 26 Oct 88 14:49 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: CONCATENATE-STREAM-EXAMPLE
In-reply-to: ROSENKING@A.ISI.EDU's message of 26 Oct 88 16:45 EDT
To: ROSENKING@A.ISI.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <881026-144910-13931@Xerox>

I don't think this one needs a cleanup, its just a bug report, right? Is
there any possible ambiguity in CLtL?


∂26-Oct-88  1501	CL-Cleanup-mailer 	Re: Issue: INPUT-STREAM-P-EXAMPLE   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 26 Oct 88  15:01:46 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 26 OCT 88 14:50:42 PDT
Date: 26 Oct 88 14:50 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: INPUT-STREAM-P-EXAMPLE
In-reply-to: ROSENKING@A.ISI.EDU's message of 26 Oct 88 16:46 EDT
To: ROSENKING@A.ISI.EDU
cc: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <881026-145042-13939@Xerox>

Ditto here. How can a broadcast stream be INPUT-STREAM-P?

You might want to disambiguate between the 3 implementations of Common Lisp
available on the Mac, the 3 implementations available for the VAX, and
which Symbolics implementation (Genera, CLOE) of Common Lisp.


∂26-Oct-88  1536	CL-Cleanup-mailer 	Re: Issue: STREAM-ELEMENT-TYPE-EXAMPLES  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 26 Oct 88  15:36:42 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 26 OCT 88 15:27:03 PDT
Date: 26 Oct 88 15:26 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: STREAM-ELEMENT-TYPE-EXAMPLES
In-reply-to: ROSENKING@A.ISI.EDU's message of 26 Oct 88 16:49 EDT
To: ROSENKING@A.ISI.EDU
cc: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <881026-152703-14052@Xerox>

I think there are some genuine ambiguities around STREAM-ELEMENT-TYPE. The
issue is whether streams need to remember their element-type, even in
implementations that allow both binary and character I/O to the same
stream.


∂26-Oct-88  1545	CL-Cleanup-mailer 	Re: issue DECLARATION-SCOPE    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 26 Oct 88  15:45:13 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 26 OCT 88 15:44:20 PDT
Date: 26 Oct 88 15:44 PDT
From: masinter.pa@Xerox.COM
Subject: Re: issue DECLARATION-SCOPE
In-reply-to: Jon L White <jonl@lucid.com>'s message of Fri, 21 Oct 88
 19:49:49 PDT
To: Jon L White <jonl@lucid.com>
cc: sandra%defun@cs.utah.edu, cl-cleanup@sail.stanford.edu
Message-ID: <881026-154420-14099@Xerox>

I like your summary in this last message. I hope some form of it will get
into the next revision. Do you have an ETA on a revision for us?

I want to make sure we get some of these harder issues done sooner so we
have time to get them "right".


∂26-Oct-88  1622	CL-Cleanup-mailer 	Re: Issue: DECLARE-FUNCTION-AMBIGUITY (Version 3)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 26 Oct 88  16:22:45 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 26 OCT 88 16:14:32 PDT
Date: 26 Oct 88 16:14 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DECLARE-FUNCTION-AMBIGUITY (Version 3)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Thu, 13 Oct 88 16:05 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881026-161432-14168@Xerox>

I think we need to make the ballot have the choices:

(DECLARE (TYPE FUNCTION ...)) only
(DECLARE (FTYPE ...)) only
both interpretations, document more carefully


I don't know how to reduce the number of choices easily, do you?

∂26-Oct-88  1623	CL-Cleanup-mailer 	Re: Issue: ALIST-NIL (Version 4)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 26 Oct 88  16:23:11 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 26 OCT 88 16:21:59 PDT
Date: 26 Oct 88 16:20 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ALIST-NIL (Version 4)
In-reply-to: masinter.pa's message of 25 Oct 88 16:07 PDT
To: CL-Cleanup@Sail.Stanford.EDU
Message-ID: <881026-162159-14192@Xerox>

Kent and I spoke on the phone. The motivation for this proposal is that the
idea of NIL in an alist is confusing.

One possibility we discussed was to document that an "alist" is in fact a
list of pairs, but to document that the functions ASSOC, RASSOC, ASSOC-IF,
ASSOC-IF-NOT RASSOC-IF and RASSOC-IF-NOT will accept not only an alist but
any list whose elements are either pairs or NIL, and that NIL elements are
ignored. This means that the concept of "alist" is kept to the traditional
interpretation, but that the behavior of some of the functions are
extended.

In general we should try very hard to find ways to "simplify the language"
by changing its description, before we resort to changing its definition.


∂26-Oct-88  1724	CL-Characters-mailer 	Re: cs proposal   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Oct 88  17:24:26 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 482647; Wed 26-Oct-88 20:19:31 EDT
Date: Wed, 26 Oct 88 20:19 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: cs proposal
To: masinter.pa@Xerox.COM
cc: Thom Linden <baggins@ibm.com>, "X3J13: Character Subcommittee" <cl-characters@sail.stanford.edu>,
    yuasa%tutics.tut.junet%utokyo-relay.CSNet@relay.cs.net, rpk@wheaties.ai.mit.edu,
    brent%hpfcpsb@hplabs.hp.com, sandra%defun@cs.utah.edu, vanroggen%atig.dec@decwrl.dec.com,
    cl-cleanup@sail.stanford.edu
In-Reply-To: <881025-110347-11299@Xerox>
Message-ID: <19881027001914.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 25 Oct 88 11:03 PDT
    From: masinter.pa@Xerox.COM

    The proposal did not ever say explicitly, and I feel strongly that it
    should, that in fact Common Lisp *requires* absolutely no changes in order
    to support extended character sets. The language as specified in CLtL is
    entirely adequate to allow handling of multiple, international character
    sets. The implementation of Xerox Common Lisp, now available on Xerox 1100
    series workstations and Sun 3 and Sun 4 workstations, is an existance
    proof.

So is Symbolics Genera.  However, I doubt that programs and data files
written to exploit extended character sets are portable between
Symbolics and Xerox (Envos).  For programs, the primitives defined by
Common Lisp are insufficient for meaningful manipulation of multiple
character sets.  For data files, Common Lisp says nothing about how
characters are represented.

Isn't portability between implementations the whole reason for additional
standardization in this area?

Most of your comments are consistent with the comments that Symbolics
sent in, I think.  Also your desire for better specification of such
things as what alphabetic case means in international character sets is
consistent with comments from International Lisp Associates that I saw.

    The discussion of the proposal frequently confounds two separate
    distinctions, of "backward compatibility" and "portability". Our primary
    goal is to allow "portable" programs -- programs that, if written in the
    standard language, will run unchanged in all implementations that support
    the standard language.  We try to achieve that while also supporting
    "backward compatibility" -- programs that run in current implementations of
    Common Lisp should continue to work correctly unchanged. I fear that the
    proposal, in the name of efficiency and backward compatibility,  damages
    the portability of the resulting language, because it allows programs to
    rely on implementation-dependent details of the nature of strings. It
    damages backward compatibility, because valid programs that manipulated
    strings will no longer be correct. And it does not make a convincing
    argument that it has actually solved the problem of *efficient*
    international character set handling.

I'd like to see some more detail on these allegations, particular the
one about allowing programs to rely on implementation-dependent details,
since unlike your other comments I don't agree with them, or maybe I
don't know what exactly you're saying.

    I think you've done an admirable job of establishing the scope and extent
    of possible changes to Common Lisp in the area of character handling.
    However, I would like to see the proposal split up into separate "issues"
    which each have their own pros and cons.

I think this is a good idea for issues that are truly separable, such as
removing char-bits, but splitting up the kernel of the proposal seems to
me to be just more work for both writers and readers, so I'd rather
see the main proposal remain all in one piece.

∂26-Oct-88  1833	CL-Cleanup-mailer 	Issue: STREAM-ELEMENT-TYPE-EXAMPLES 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Oct 88  18:33:19 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 482690; Wed 26-Oct-88 21:32:59 EDT
Date: Wed, 26 Oct 88 21:32 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-ELEMENT-TYPE-EXAMPLES
To: ROSENKING@A.ISI.EDU
cc: CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <[A.ISI.EDU]26-Oct-88 16:49:53.ROSENKING>
Message-ID: <19881027013240.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

Note that in many cases, the Common Lisp language does not specify
any particular value to be returned by STREAM-ELEMENT-TYPE.  The
function exists so you can find out what implementation-dependent
element type you got, not so you can store an object with OPEN
and read it back with STREAM-ELEMENT-TYPE.

The Common Lisp language also does not specify which of several
equivalent type specifiers (e.g. BIT, (INTEGER 0 1), (INTEGER 0 (2)),
(MEMBER 0 1)) is returned.

We need to be careful of putting examples in documentation that
imply that the language specification is more restrictive than
it was intended to be.

∂26-Oct-88  1837	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATION 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Oct 88  18:37:27 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 482693; Wed 26-Oct-88 21:37:42 EDT
Date: Wed, 26 Oct 88 21:37 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOSED-STREAM-OPERATION
To: ROSENKING@A.ISI.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <[A.ISI.EDU]26-Oct-88 16:19:06.ROSENKING>
Message-ID: <19881027013729.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

There was already a version 3 by VanRoggen.  Is yours really version 4?

∂26-Oct-88  1850	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATIONS (version 4)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Oct 88  18:50:39 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 482696; Wed 26-Oct-88 21:50:52 EDT
Date: Wed, 26 Oct 88 21:50 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOSED-STREAM-OPERATIONS (version 4)
To: ROSENKING@A.ISI.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <[A.ISI.EDU]26-Oct-88 16:19:06.ROSENKING>
Message-ID: <19881027015040.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

Note that I have corrected the misspelled issue name in the subject,
and guessed that the version was really 4 rather than 3.  Always
having stylized subject lines, free of typos, helps everyone cope
with the enormous flood of mail in CL-Cleanup.

    Date: 26 Oct 1988 16:19-EDT
    From: ROSENKING@A.ISI.EDU

    Require that CLOSE return the stream name at all times, of the form 
    #<stream>, and that it is an error to perform any operation on a closed stream.

The last clause clearly cannot work, since certain operations such as
TRUENAME are only valid on output streams -after- the stream has been
closed, in some file systems (ones with version numbers that don't
choose the version until after the file has been closed, for example.)
Similarly, FILE-WRITE-DATE on an open output stream is really only
meaningful after the stream has been closed, since the buffer forcing
inherent in CLOSE sets the write date in some file systems.

Also it contradicts CLtL p.332, which says "certain inquiry operations"
can be performed after a stream has been closed (unfortunately it
neglects to say which).

My point here is that this file system stuff requires careful consideration,
because there is so much variation in file systems, which in most cases are
not under the control of the Lisp implementors.  If there is insufficient
time for careful consideration, I would rather see Common Lisp left 
deliberately ambiguous or underspecified in this area.  That would be
preferable to specifying something which cannot be implemented or
which creates unanticipated problems.

∂26-Oct-88  1911	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Oct 88  19:11:34 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 482703; Wed 26-Oct-88 22:11:12 EDT
Date: Wed, 26 Oct 88 22:10 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
To: David N Gray <Gray@DSG.csc.ti.com>, Sandra J Loosemore <sandra%defun@cs.utah.edu>,
    Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Jon L White <jonl@lucid.com>,
    Dan L. Pierson <pierson%mist@MULTIMAX.ARPA>, Gail Zacharias <gz@spt.entity.com>
cc: Gail Zacharias <gz%spt.entity.com@MULTIMAX.ARPA>, David N Gray <Gray%DSG.csc.ti.com@MULTIMAX.ARPA>,
    Sandra J Loosemore <"sandra%defun@cs.utah.edu"@MULTIMAX.ARPA>, cl-cleanup%sail.stanford.edu@MULTIMAX.ARPA,
    CL-Cleanup@SAIL.Stanford.edu, sandra%defun%cs.utah.edu@MULTIMAX.ARPA,
    Bartley@MIPS.csc.ti.com
In-Reply-To: <2802872949-4933586@Kelvin>,
             <8810260022.AA28990@defun.utah.edu>,
             <2802814400-1415862@Kelvin>,
             <8810252042.AA28871@defun.utah.edu>,
             <2802727517-1153780@Kelvin>,
             <881020154612.7.KMP@BOBOLINK.SCRC.Symbolics.COM>,
             <8810182149.AA01791@bhopal>,
             <8810181927.AA13501@mist.UUCP>,
             <8810181351.AA19036@spt.entity.com>,
             <8810181728.AA13169@mist.UUCP>,
             <2802186955-10350987@Kelvin>,
             <8810181613.AA13058@mist.UUCP>,
             <8810181540.AA22872@defun.utah.edu>,
             <8810172013.AA11848@mist.UUCP>
Message-ID: <19881027021053.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

This whole discussion has strongly reinforced my belief that PROVIDE and
REQUIRE are ill-conceived and should be removed from the language.  I also
feel far too much of the limited remaining time has been spent on this
trivial issue.

If PROVIDE and REQUIRE are really trying to be DEFSYSTEM, there is little
chance of converging on a concensus of what they should be within the next
two months.  On the other hand, if REQUIRE is nothing but a way to check
whether a flag has been set, the language already contains global variables
and IF statements, so why duplicate a mechanism the user could implement
for himself?

∂26-Oct-88  1912	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 26 Oct 88  19:12:39 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA00584; Wed, 26 Oct 88 22:11:11 EDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 482703; Wed 26-Oct-88 22:11:12 EDT
Date: Wed, 26 Oct 88 22:10 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
To: David N Gray <Gray@DSG.csc.ti.com>,
        Sandra J Loosemore <sandra%defun@cs.utah.edu>,
        Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>,
        Jon L White <jonl@lucid.com>,
        Dan L. Pierson <pierson%mist@MULTIMAX.ARPA>,
        Gail Zacharias <gz@spt.entity.com>
Cc: Gail Zacharias <gz%spt.entity.com@MULTIMAX.ARPA>,
        David N Gray <Gray%DSG.csc.ti.com@MULTIMAX.ARPA>,
        Sandra J Loosemore <"sandra%defun@cs.utah.edu"@MULTIMAX.ARPA>,
        cl-cleanup%sail.stanford.edu@MULTIMAX.ARPA,
        CL-Cleanup@SAIL.Stanford.edu, sandra%defun%cs.utah.edu@MULTIMAX.ARPA,
        Bartley@MIPS.csc.ti.com
In-Reply-To: <2802872949-4933586@Kelvin>,
             <8810260022.AA28990@defun.utah.edu>,
             <2802814400-1415862@Kelvin>,
             <8810252042.AA28871@defun.utah.edu>,
             <2802727517-1153780@Kelvin>,
             <881020154612.7.KMP@BOBOLINK.SCRC.Symbolics.COM>,
             <8810182149.AA01791@bhopal>,
             <8810181927.AA13501@mist.UUCP>,
             <8810181351.AA19036@spt.entity.com>,
             <8810181728.AA13169@mist.UUCP>,
             <2802186955-10350987@Kelvin>,
             <8810181613.AA13058@mist.UUCP>,
             <8810181540.AA22872@defun.utah.edu>,
             <8810172013.AA11848@mist.UUCP>
Message-Id: <19881027021053.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

This whole discussion has strongly reinforced my belief that PROVIDE and
REQUIRE are ill-conceived and should be removed from the language.  I also
feel far too much of the limited remaining time has been spent on this
trivial issue.

If PROVIDE and REQUIRE are really trying to be DEFSYSTEM, there is little
chance of converging on a concensus of what they should be within the next
two months.  On the other hand, if REQUIRE is nothing but a way to check
whether a flag has been set, the language already contains global variables
and IF statements, so why duplicate a mechanism the user could implement
for himself?

∂26-Oct-88  1946	CL-Cleanup-mailer 	Issue: DESCRIBE-INTERACTIVE (Version 3)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Oct 88  19:46:14 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 482725; Wed 26-Oct-88 22:46:03 EDT
Date: Wed, 26 Oct 88 22:45 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DESCRIBE-INTERACTIVE (Version 3)
To: Dan L. Pierson <pierson%mist@MULTIMAX.ARPA>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8810191935.AA14702@mist.UUCP>
Message-ID: <19881027024541.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

I oppose DESCRIBE-INTERACTIVE:NO on the grounds that it creates
extra work for implementors and users of at least one implementation,
for no compelling reason.

Instead of eliminating functionality from DESCRIBE, it would be better
to suggest that DESCRIBE methods (and any other programs that ask
questions of the user) should call the recently added
STREAM-INTERACTIVE-P function (I'm not sure I've got the right name) so
as to avoid asking questions when there is no one to answer them.  This
would address the stated goal "to call DESCRIBE in a batch applications
without hanging the application" without requiring incompatible changes
to current practice.

∂26-Oct-88  1958	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 6)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Oct 88  19:58:44 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 482737; Wed 26-Oct-88 22:58:57 EDT
Date: Wed, 26 Oct 88 22:58 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFPACKAGE (version 6)
To: CL-Cleanup@Sail.stanford.edu
In-Reply-To: <8810080744.AA03642@bhopal>
Message-ID: <19881027025834.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

Version 6 is okay with me, except for two exceptions noted below:

  (:INTERNAL {symbol-name}*)

:INTERNAL was a typo for :INTERN; I apologize.  Wherever possible
the option keywords were chosen to be analogous to existing Common
Lisp functions, to make it easier for users to remember them and
to guess what they do.

    An attempt to re-define
    a package with a smaller set of attributes should signal a continuable error;
    at most one such error is to be signalled per call to DEFPACKAGE, regardless 
    of how many attributes are being re-tracted; upon continuation, the package
    is created with exactly as specified.

Even without the typos I would object to this.  It's not clear to me
that signalling an error is the correct response in all programming
environments for evaluating a DEFPACKAGE with fewer attributes.

Furthermore, in no other place (outside of DEFVAR and CLOS) does Common
Lisp currently define what happens when you define something twice.  It
took an enormous amount of time and effort to get that right in CLOS,
and many people still argue that CLOS got it wrong.  I think it's a bad
idea to take on that difficult a complex of issues in CL-Cleanup when
there are only two months left.  I think it would be a much better idea
to leave redefinition of packages undefined, just like redefinition of
functions or macros.

∂26-Oct-88  2011	CL-Cleanup-mailer 	issue DEFPACKAGE
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Oct 88  20:11:42 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 482749; Wed 26-Oct-88 23:11:16 EDT
Date: Wed, 26 Oct 88 23:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DEFPACKAGE
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>, peck@Sun.COM, Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu, cl-compiler@sail.stanford.edu
In-Reply-To: <8810132034.AA19839@defun.utah.edu>,
             <8810180019.AA06479@denali.sun.com>,
             <8810220152.AA12710@bhopal>,
             <8810220210.AA12781@bhopal>
Message-ID: <19881027031103.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

Comments on comments received.  I'll keep it as brief as I can.

    Date: Thu, 13 Oct 88 14:34:04 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    A question was raised at the meeting about having macros signalling
    errors during expansion at compile time.  Macro expansion time is the
    obvious time for signalling a syntax error for an unrecognized option
    and I think that should be made clear in the standard.

Sure, but I hope we don't have to address this separately for each and
every macro.

    I presume it's the intention of the proposal that the expansion of
    DEFPACKAGE should be wrapped with an (EVAL-WHEN (EVAL COMPILE LOAD)

I don't know about mandating that specific implementation, especially
when the definition of EVAL-WHEN is in flux, but certainly the idea is
that writing a DEFPACKAGE form at top level is sufficient to inform
the compiler of what you mean.  It's usually good practice to put
DEFPACKAGE forms into separate files, in which case the issue does
not arise, but I don't think we need to forbid putting a DEFPACKAGE
form in the same file as a program.

    Finally, what is the motivation for not having DEFPACKAGE setq *PACKAGE*?

What is the motivation for not having DEFUN call the function?
That's not a joke, my point is that the two operations of defining
a package and switching the current package have little to do with
each other and are rarely done together.

    Date: Mon, 17 Oct 88 17:19:14 -0700
    From: peck@Sun.COM

    I suggest that the :INTERNAL option be renamed :INTERN.

Right, that was a mistake on my part.  :INTERN is right.

     Please verify for me that if there is no :USE clause, whether
    the created package will use....

The default for DEFPACKAGE is the same as for MAKE-PACKAGE, and is
the subject of a separate cleanup issue.

    Clarify that the order of the clauses in the source code has no effect.

Right, good point.

    Date: Fri, 21 Oct 88 18:52:57 PDT
    From: Jon L White <jonl@lucid.com>

    re: I presume it's the intention of the proposal that the expansion of
	DEFPACKAGE should be wrapped with an (EVAL-WHEN (EVAL COMPILE LOAD)

    This should be covered the "normal" way, like any other defining form

Right.

    Date: Fri, 21 Oct 88 19:10:42 PDT
    From: Jon L White <jonl@lucid.com>

    I'd prefere to see the :EXPORT option renamed to
    be :EXTERNAL rather than introduce a gratuitously new keyword [note
    that symbols present in a package must be either :INTERNAL or :EXTERNAL.]

I strongly object to removing the analogy between the names of these
options and the already existing package functions.  :INTERNAL instead
of :INTERN was a typographical error on my part.

    re:                                            . . . Like all USE'ing
	this should be deferred until after the shadowing is done, no?

    Ooops, I guess you're right.  Shadowing that creates new symbols isn't
    important; but shadowing that in effect "blocks" the inheritance of two 
    different symbols with the same name must be done before the "using".

That's correct.  It's not hard to figure out in what order the options
should be processed, but part of the idea of having DEFPACKAGE is that
only implementors have to figure that out.

    I guess the more clear way to say what was intended here is that the
    evaluation of a DEFPACKAGE form does not change the value of *package*.

Right.

∂26-Oct-88  2017	CL-Cleanup-mailer 	logical pathnames    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Oct 88  20:17:25 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 482752; Wed 26-Oct-88 23:17:19 EDT
Date: Wed, 26 Oct 88 23:17 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: logical pathnames
To: Eric Benson <eb@lucid.com>
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8810212113.AA00256@blacksox>
Message-ID: <19881027031707.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 21 Oct 88 14:13:50 pdt
    From: Eric Benson <eb@lucid.com>

    I wish someone would make a proposal
    for generic pathnames.  I don't think they ever got the consideration
    they deserved.  (I know they aren't really related to this issue,
    except insofar as users would like to have portable pathnames in their
    programs.)

I deduce you mean "logical pathnames" (pathnames for an imaginary portable
file system, which get translated by site-dependent translations into
physical pathnames on an actual file system), rather than "generic
pathnames" (pathnames that stand for a family of related files, such as a
source file and its associated compiled file(s)).  I think this has been
proposed a couple of times, only to be shot down, either because it was
thought unnecessary or because the discussants didn't understand it.  I
too would like to see it proposed and adopted, but I won't propose it
myself, as I am very tired of trying to swim up waterfalls.

∂26-Oct-88  2039	CL-Cleanup-mailer 	issue DECLARATION-SCOPE   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Oct 88  20:39:47 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 482762; Wed 26-Oct-88 23:39:59 EDT
Date: Wed, 26 Oct 88 23:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DECLARATION-SCOPE
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8810132013.AA19827@defun.utah.edu>
Message-ID: <19881027033947.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 13 Oct 88 14:13:43 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    I generally like this proposal because the wording it uses is much more
    understandable than the terminology in CLtL (which I have never succeeded
    in grokking fully).  I have two big problems with the current writeup:
    other hand, it has two big problems:

    (1) The treatment of TYPE declarations contradicts proposal
    DECLARE-TYPE-FREE.  I don't think I could vote for either proposal
    without some better indication of how they are supposed to work
    together. 

    (2) Since issue FLET-DECLARATIONS was passed at the March meeting, the
    writeup needs to be changed to reflect that and give TYPE and FTYPE
    declarations the same treatment (either both "bound" or both "free").

Mumble.  Both of these problems were corrected in version 3 of the
proposal, which I sent to JonL on September 18.  Can it be that no
one but JonL and me ever saw that version?  I may have screwed up.

∂26-Oct-88  2053	CL-Cleanup-mailer 	issue DECLARATION-SCOPE   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Oct 88  20:53:25 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 482771; Wed 26-Oct-88 23:52:30 EDT
Date: Wed, 26 Oct 88 23:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DECLARATION-SCOPE
To: Jon L White <jonl@lucid.com>
cc: sandra%defun@cs.utah.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: <8810220249.AA12854@bhopal>
Message-ID: <19881027035211.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 21 Oct 88 19:49:49 PDT
    From: Jon L White <jonl@lucid.com>

    The source of much confusion here has long been that TYPE declarations had 
    to be treated differently from all other declarations; this was  because of 
    the crazy prohibition found on p158 of CLtL.  Let's assume for now that 
    DECLARE-TYPE-FREE is accepted; then I think we can just flush all crazy 
    categorizations into "pervasive"/"non-pervasive" and  "free"/"bound" and 
    simply say that declarations:
      (1) always include the lexical scope of the body of the special form 
	  in which  they are found;
      (2) and furthermore, they also include the scope of the name-bindings, 
	  if any, to which they apply.  [LET, LAMBDA, FLET, and LABELS 
	  introduce "name bindings"; LOCALLY doesn't.]
    Since the scope of a "name-binding" also includes the body as mentioned
    in (1), then the only additional comment needed concerns LET* and LABELS.

JonL, this makes me really angry.  I feel like I have explained this ten
times, but it never seems to get through to you.  I've started to reply
to this several times, but cancelled it.  I hope the following is
a calm and understandable explanation of the issue.  Please read it.

First of all, the "free"/"bound" distinction isn't some crazy
categorization that we can just remove.  It means exactly the same
thing as your phrase "the name-bindings, if any, to which they apply".
As long as we have in the language both declarations that are attached
to bindings and declarations that are not attached to bindings, we have
a "free"/"bound" distinction, whether we like it or not.  If we don't
like those names, we could use other ones, although those are the
standard names for the concepts; however, changing the name won't
eliminate the issue.

But that's not the major point.  The major point is your claim that it's
obvious that the scope of a free declaration should be just the body of
the special form, and not include any additional code, such as
initialization forms.  Perhaps we would choose to adopt this after
discussion, but it's not obviously correct, it's not obviously simpler
than setting the scope to the entire special form, and most importantly
it is an incompatible change, directly contradicting the scope defined
by CLtL for the FTYPE, INLINE, NOTINLINE, and OPTIMIZE declarations,
and for the SPECIAL declaration when not attached to a variable binding.
My reason for preferring that the scope of a free declaration is the
entire special form is to avoid an incompatible change.

If you don't see that, look at the "defun few" example in the middle
of page 155 of CLtL.

∂26-Oct-88  2102	CL-Cleanup-mailer 	issue SYMBOL-MACROLET-SEMANTICS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Oct 88  21:02:39 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 482776; Thu 27-Oct-88 00:02:49 EDT
Date: Thu, 27 Oct 88 00:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue SYMBOL-MACROLET-SEMANTICS
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8810132308.AA19978@defun.utah.edu>
Message-ID: <19881027040234.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 13 Oct 88 17:08:55 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    This seems like a reasonable thing to do here.  The only serious
    problem I see is that the description of SYMBOL-MACROLET in the CLOS
    document says that it changes SETQ's of the symbols in the body to
    SETF's during macro expansion.  Now that you are proposing that
    SYMBOL-MACROLET won't be a macro any more, I think you have to specify
    a change in the behavior of SETQ as well as SETF.  It seems like they
    would have to be pretty much the same now, right?

Yes.

    I am a bit concerned about how this proposal interacts with the SETF
    processing model specified in issue SETF-FUNCTION-VS-MACRO -- with the
    description of SETF being distributed in several places, something
    might get overlooked in the final standards document. 

How could they interact, when SYMBOL-MACROLET-SEMANTICS applies when the
<place> subform of SETF is a symbol, and SETF-FUNCTION-VS-MACRO applies
when the <place> subform of SETF is a cons?  It's true that the number
of issues being addressed simultaneously is getting out of hand; the
extremely long delay in resolving some issues is making this worse.

    Another thing is that I really don't like the name SYMBOL-MACROLET and
    as long as you are proposing to make it a special form, you might as
    well try to change the name to something nicer at the same time.  

I'm afraid I don't follow your syllogism here.  Also I think you'd have
to make a specific proposal of a new name to get anyone to pay attention.

∂26-Oct-88  2141	CL-Compiler-mailer 	Re: issue DEFPACKAGE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 26 Oct 88  21:39:40 PDT
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA00225; Wed, 26 Oct 88 22:30:28 MDT
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA29800; Wed, 26 Oct 88 22:28:19 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810270428.AA29800@defun.utah.edu>
Date: Wed, 26 Oct 88 22:28:17 MDT
Subject: Re: issue DEFPACKAGE
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs>, peck@Sun.COM,
        Jon L White <jonl@lucid.com>, cl-cleanup@sail.stanford.edu,
        cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 26 Oct 88 23:11 EDT

> Date: Wed, 26 Oct 88 23:11 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
>     Finally, what is the motivation for not having DEFPACKAGE setq *PACKAGE*?
> 
> What is the motivation for not having DEFUN call the function?
> That's not a joke, my point is that the two operations of defining
> a package and switching the current package have little to do with
> each other and are rarely done together.

My original impression of what this proposal was for was to introduce
a somewhat cleaner mechanism to do what one currently uses the Seven
Extremely Randoms for.  IN-PACKAGE is one of those.  If one follows
the style set forth in CLtL, then defining a package and switching the
current package -are- usually done together.  I don't have any problem
with DEFPACKAGE not setq'ing *PACKAGE*, I just think the proposal
should make it more clear why it doesn't, and emphasize that
DEFPACKAGE really isn't supposed to be used the same way as the Seven
Extremely Randoms.  I was confused and maybe other people are too.

-Sandra
-------

∂27-Oct-88  0947	CL-Cleanup-mailer 	Re: Issue: CLOSED-STREAM-OPERATION  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Oct 88  09:47:50 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 482983; Thu 27-Oct-88 12:48:00 EDT
Return-path: <ROSENKING@A.ISI.EDU>
Received: from A.ISI.EDU by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 482885; 27 Oct 88 09:54:14 EDT
Date: 27 Oct 1988 09:50-EDT
Sender: ROSENKING@A.ISI.EDU
Subject: Re: Issue: CLOSED-STREAM-OPERATION
From: ROSENKING@A.ISI.EDU
To: Moon@SCRC-STONY-BROOK.ARPA
Message-ID: <[A.ISI.EDU]27-Oct-88 09:50:16.ROSENKING>
In-Reply-To: <19881027013729.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Resent-To: CL-Cleanup@sail.stanford.edu
Resent-From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Thu, 27 Oct 88 12:47 EDT
Resent-Message-ID: <19881027164739.9.MOON@EUPHRATES.SCRC.Symbolics.COM>


I was unaware of VanRoggen's or any other version after 2. My version is
separate and hopefully unique.

∂27-Oct-88  0954	CL-Cleanup-mailer 	Re: issue DEFPACKAGE 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Oct 88  09:53:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 482989; Thu 27-Oct-88 12:53:29 EDT
Date: Thu, 27 Oct 88 12:53 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue DEFPACKAGE
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: peck@Sun.COM, Jon L White <jonl@lucid.com>, cl-cleanup@sail.stanford.edu,
    cl-compiler@sail.stanford.edu
In-Reply-To: <8810270428.AA29800@defun.utah.edu>
Message-ID: <19881027165315.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 26 Oct 88 22:28:17 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    > Date: Wed, 26 Oct 88 23:11 EDT
    > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    > 
    >     Finally, what is the motivation for not having DEFPACKAGE setq *PACKAGE*?
    > 
    > What is the motivation for not having DEFUN call the function?
    > That's not a joke, my point is that the two operations of defining
    > a package and switching the current package have little to do with
    > each other and are rarely done together.

    My original impression of what this proposal was for was to introduce
    a somewhat cleaner mechanism to do what one currently uses the Seven
    Extremely Randoms for.  IN-PACKAGE is one of those.  If one follows
    the style set forth in CLtL, then defining a package and switching the
    current package -are- usually done together.  

I see.  But the thing is, part of the reason for introducing DEFPACKAGE,
and for removing the ability of IN-PACKAGE to create packages, is that
the style set forth in CLtL is broken and doesn't work.  I guess I've been
saying that for so long now (about five years) that I've forgotten it isn't
intuitively evident.

						  I don't have any problem
    with DEFPACKAGE not setq'ing *PACKAGE*, I just think the proposal
    should make it more clear why it doesn't, and emphasize that
    DEFPACKAGE really isn't supposed to be used the same way as the Seven
    Extremely Randoms.  I was confused and maybe other people are too.

    -Sandra
    -------

∂27-Oct-88  1008	CL-Cleanup-mailer 	Re: Issue: STREAM-ELEMENT-TYPE-EXAMPLES  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Oct 88  10:08:34 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 483002; Thu 27-Oct-88 13:07:35 EDT
Date: Thu, 27 Oct 88 13:07 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: STREAM-ELEMENT-TYPE-EXAMPLES
To: ROSENKING@A.ISI.EDU
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <[A.ISI.EDU]27-Oct-88 09:47:10.ROSENKING>
Message-ID: <19881027170710.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

[added CL-Cleanup back, I think the whole subcommittee ought to
see these discussions]

    Date: 27 Oct 1988 09:47-EDT
    From: ROSENKING@A.ISI.EDU

    Thank you for your comments and recommendations. I wrote this issue
    based on reviewing the examples in the STREAMs chapter of the draft.
    I agree that there is an inconsistency among implementations, as I have
    found via several trials, over which type specifier(s) should be returned.
    BUT, is it not our task to correct this by at least stating what the generic
    type specifier, and possible subtype specifiers, should be returned in the
    standard ? If this is so then I would appreciate some feedback on what the
    general consensus is as to what type specifiers, and appropriate subtypes if
    necessary, should be returned. 

Yes and no.  Certainly, tightening up the standard to eliminate unwanted
inconsistencies among implementations is legitimate business of the
cleanup committee.  Since there is ten or more times as much such
business available as there is time to do, things have to be prioritized,
and I'd rate stream-element-type low on the scale of importance.  However,
the more important issue is that perhaps the differences among implementations
in what stream-element-type returns are not unwanted inconsistencies at all,
but are intentionally provided implementation freedom.  CLtL doesn't
appear to address the specific issue of stream-element-types, but my
belief is that the intention of the original design was that the :element-type
argument to OPEN says the minimum type required, and an implementation is
free to return a more capable stream whose element-type is a superset.

Your testing is also finding bugs in individual implementations, which is
certainly valuable.  Sometimes the bug indicates an unclarity in the Common
Lisp language definition, sometimes it just means the implementation was 
sloppy.  If several implementations have bugs in a particular area, it might
mean that in practice no one cares about that area and so bugs have gone
unnoticed.

    As per your note about examples, I will pass this on to the rest of the
    editorial committee since I believe that it may apply elsewhere.

Thanks.

∂27-Oct-88  1414	CL-Cleanup-mailer 	DRAFT Issue: SYMBOL-MACROLET-DECLARE (version 1)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Oct 88  14:14:10 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01210g; Thu, 27 Oct 88 14:12:03 PDT
Received: by bhopal id AA11436g; Thu, 27 Oct 88 14:09:05 PDT
Date: Thu, 27 Oct 88 14:09:05 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810272109.AA11436@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Thu, 20 Oct 88 16:16 EDT <881020161608.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: DRAFT Issue: SYMBOL-MACROLET-DECLARE (version 1)

re: From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
    Subject: DRAFT Issue: SYMBOL-MACROLET-DECLARE (version 1)

        Date: Tue, 18 Oct 88 15:40:02 PDT
	From: Jon L White <jonl@lucid.com>

	This issue should be folded into SYMBOL-MACROLET-SEMANTICS; it would be
	hardly one line in the descripton of SYMBOL-MACROLET as a special form.
	Since it looks like SYMBOL-MACROLET-SEMANTICS is not very controversial
	anymore, I see no reason to support separate proposals.

    If you support both proposals, I see no reason not to leave them separate
    and just ask you to vote yes. . . .

Uh, the problem is that the SYMBOL-MACROLET-DECLARE issue is raised
primarily because a macro-definition for SYMBOL-MACROLET would leave
the issue of DECLARE open.  But the special-form version of SYMBOL-MACROLET
really should address it [there already have been cleanup issues to address 
the declaration matter for the special forms that logically should have them
but for which CLtL didn't say -- FLET, LABELS, etc].

These two issues can no longer really be separated; if no one bothers to add 
the one-line sentence to SYMBOL-MACROLET-SEMANTICS that would fully subsume 
SYMBOL-MACROLET-DECLARE, then at least these two ought to be paired together
in discussions and voting.


-- JonL --

∂27-Oct-88  1832	CL-Cleanup-mailer 	Issue: TAILP-NIL (version 3), or NTHCDR-P?    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Oct 88  18:32:50 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01614g; Thu, 27 Oct 88 18:32:19 PDT
Received: by bhopal id AA12570g; Thu, 27 Oct 88 18:30:51 PDT
Date: Thu, 27 Oct 88 18:30:51 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810280130.AA12570@bhopal>
To: vanroggen%aitg.DEC@decwrl.dec.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: vanroggen%aitg.DEC@decwrl.dec.com's message of Tue, 19 Apr 88 19:33:14 PDT <8804200233.AA01883@decwrl.dec.com>
Subject: Issue: TAILP-NIL (version 3), or NTHCDR-P?

The difference between your Definition "A" and Definition "B" isn't just 
"in their treatment of the atomic case", but also that the loop termination
criteron is ENDP in one and ATOM in the other.  There is still something 
desirable about an ENDP termination test as long as the first argument to 
TAILP is described as a "sublist" [i.e. some kind of LIST].  For example, 
it is not acceptable to consider 35 as a list.  On the other hand, maybe 
you really want to suggest that TAILP be changed into the functionality 
implied by the name NTHCDR-P?  In  short, which of the following two
options is preferable?
  1.   (tailp 35 l)        ==> an error
  2.   (tailp 35 l)        ==> either true, or false.


Under Rationale, I would add that the current proposal makes the 
documentation of TAILP more consistent with the type definition of LIST, 
which isn't restricted to CONS cells.


Under Current Practice, Lucid does not implement TAILP-NIL:T, as previously
explained in my note:

    Date: Mon, 19 Sep 88 20:34:10 PDT
    From: Jon L White <jonl>
    To: vanroggen%aitg.DEC@decwrl.dec.com
    Cc: cl-cleanup@sail.stanford.edu
    In-Reply-To: vanroggen%aitg.DEC@decwrl.dec.com's message of Tue, 13 Sep 88 12:37:02 PDT <8809131937.AA14339@decwrl.dec.com>
    Subject: Issue: TAILP-NIL (version 1)

    TAILP-NIL:NIL is what Lucid Common Lisp supports, albeit for the 
    "wrong" reason.  Since this issue has been around for nearly three
    years (GLS's "Clarifications"), and since there has been no public 
    complaints about the many implementations that do it this way, then
    codifying this seems right.

    I wouldn't mind a line in your proposal that requires TAILP to signal
    an error if the 'sublis' argument is any non-null atom.

    -- JonL --

For Lucid, the choice between TAILP-NIL:NIL and TAILP-NIL:T is quite
arbitrary [i.e., don't read anything into "supports" above].



-- JonL --



∂27-Oct-88  1900	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Oct 88  18:59:53 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01634g; Thu, 27 Oct 88 18:57:57 PDT
Received: by bhopal id AA12623g; Thu, 27 Oct 88 18:56:24 PDT
Date: Thu, 27 Oct 88 18:56:24 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810280156.AA12623@bhopal>
To: Gray@DSG.csc.ti.com
Cc: sandra%defun@cs.utah.edu, pierson%mist@MULTIMAX.ENCORE.COM,
        CL-Cleanup@SAIL.Stanford.edu
In-Reply-To: David N Gray's message of Wed, 26 Oct 88  10:49:09 CDT <2802872949-4933586@Kelvin>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)

re: Suppose we said that REQUIRE uses an implementation-defined registry of
    module names and actions to be performed, if the implementation provides
    such a feature, . . . 

Well, that is more-or-less what CLtL says now for the case when the second
argument "is NIL ..." (CLtL, p188).  Since the force of this proposal is to 
retract any _standard_ way to hook REQUIRE into LOAD/DEFSYSTEM, then it 
would still be OK for an implementation to extend REQUIRE in an essentially 
upwards compatible way.  The point you are trying to make, if I read it 
right, is that previously this "essentially upwards compatible" way was 
applicable to forms like (REQUIRE <module>), but now would only be applicable 
to those like (REQUIRE <module> <more-stuff>).  How serious a problem is 
this change?


-- JonL --

∂27-Oct-88  2014	CL-Cleanup-mailer 	Issue: CONSTANT-SIDE-EFFECTS (no proposal)    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Oct 88  20:14:31 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01694g; Thu, 27 Oct 88 20:11:38 PDT
Received: by bhopal id AA13032g; Thu, 27 Oct 88 20:10:08 PDT
Date: Thu, 27 Oct 88 20:10:08 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810280310.AA13032@bhopal>
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 26 Oct 88 11:42 PDT <881026-114227-13467@Xerox>
Subject: Issue: CONSTANT-SIDE-EFFECTS (no proposal)

re: While it is certainly possible to address the issue by making "constant" a
    first-class run-time accessable property of data, I don't think we are
    going to make a lot of progress if we choose that direction.

Well, I mentioned this avenue -- elevating to first class the hidden concept
of "read-only", or whatever it is that is different about "constants" --
because it was one of the more sensible criticisms that came out of six
months of haggling.  "Haggling" first on the common-lisp@sail mailing list,
and verbally at the Scheme community meetings at Snowbird in mid July.

I would very much like to know what implementations do something akin to 
the PDP10 MacLisp treatment of "constants", or maybe an extension thereto:
  (1) except possibly for symbols, they are stored in a separate storage 
      area, which will be made write-protected at the next "disksave";
  (2) they ("constants") are identified by the compiler as the result of 
      any evaluable program like (QUOTE <anything>).  [Note that certain
      datatypes other than lists and symbols may be "implicitly quoted".]
I think that Symbolics and Lucid do this, and suspect TI of doing it too;
but what of the many others?  

Lucid also treats many "compiled-functions" as constants (i.e. "read-only"),
namely those loaded in from a file produced by compile-file; in effect, 
(FUNCTION (LAMBDA ...)) is recognized as a "constant" too [note that this 
isn't related to the discussion about a constant-function declaration, which
was primarily about what kinds of "functions" would ever be assigned to the
declared name].  For purposes of this discussion, (DEFUN FOO ...) is handled 
as if it were just (SETF (SYMBOL-FUNCTION 'FOO) (FUNCTION (LAMBDA ...))).

Additionally, before investing any time in such a proposal, I wonder how 
controversial it would be to insist (or, maybe just "suggest") that the 
interpreter evaluate (QUOTE <anything>) not merely into <anything>, but 
rather into a possibly-cached copy of <anything> that is known to be 
CONSTANT-STORAGE-P.  That is, the interpreter must do something very similar
to what the compiler does for constants.  Without this clause -- without
rectifying the Lisp 1.5 mistake that defines QUOTE like CAR -- there is
far too much potential for interpreted/compiled mismatch.  I really 
wouldn't want to address "constants" if it applied _only_ to the output
of the compiler.


Garbage-collection of "constants" is a separate issue that I think 
needn't be addressed by our emerging (non) proposal.


-- JonL --

∂27-Oct-88  2214	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Oct 88  22:14:16 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01734g; Thu, 27 Oct 88 22:13:35 PDT
Received: by bhopal id AA13338g; Thu, 27 Oct 88 22:12:02 PDT
Date: Thu, 27 Oct 88 22:12:02 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810280512.AA13338@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Mon, 17 Oct 88 21:40 EDT <881017214016.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)

[some of quoted parts of your msg are out of order, in order to reply to
the simpler ones first]

re: I think there should be a portable way to get portable code (ie, the 
    language without extensions). I don't want to waste -any- time figuring 
    out how people get to system-dependent stuff. . . 

So do I; as this proposal suggests, supplying an explicit :USE argument of 
"LISP" would be this portable way.


re: There are no restrictions in CLtL about what packages the USER package may 
    use, what symbols it may shadow, etc.

See CLtL, p181.  It is required to "use" LISP.  Current practice also has
it "inheriting" all the vendors extensions, and has it essentially free of
any other symbols.


re:     Cloe shadows MAKE-PACKAGE, IN-PACKAGE, etc. ...
        Once you've chosen a package to work from, all calls to an unqualified
	MAKE-PACKAGE do the thing that is natural for that initial package.
    This is a current practice statement. Please note it.

Uh, I'm not sure this is relevant to a proposal concerning the _standard_ 
definition of MAKE-PACKAGE;  a non-standard ACME:MAKE-PACKAGE can do just 
about whatever it wants.  Remember that this proposal concerns the
default value of the :use argument to MAKE-PACKAGE -- it is not directly
about some underlying problem that CLoe may address in a different way.


re: Our USER package uses CLOE, so (IN-PACKAGE ...) [unqualified] calls
    CLOE:IN-PACKAGE.

So either Cloe's USER package doesn't use LISP -- which would violate CLtL
p181 --  or it shadows LISP:IN-PACKAGE with CLOE:IN-PACKAGE  -- which
introduces yet another oddball variation between the shape of the USER
package and a vanilla package made like (make-package "FOO" :use "LISP").

As I mentioned before, one primary motivation for this proposal is the user
complaints about USER being so "different" (in the Lucid Sun3/2.1 release).




-- JonL --


∂27-Oct-88  2230	CL-Compiler-mailer 	Issue: IN-SYNTAX (Version 1)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Oct 88  22:30:29 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01747g; Thu, 27 Oct 88 22:29:53 PDT
Received: by bhopal id AA13376g; Thu, 27 Oct 88 22:28:24 PDT
Date: Thu, 27 Oct 88 22:28:24 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810280528.AA13376@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU, CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Fri, 21 Oct 88 17:19 EDT <881021171949.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: IN-SYNTAX (Version 1)

re: I noticed too late that you had added CL-Compiler.  . . . 

Because of the extensive implications for the CL-Compiler issue 
EVAL-WHEN-NON-TOP-LEVEL, and because of the (hasty) acceptance of
re-binding *package* to the "current" value by COMPILE-FILE.

I can appreciate your concern about double cc'ing, and will take
the issue only to CL-Cleanup now.  Anyone on CL-Compiler who isn't
also on CL-CLeanup, but would like to hear about the issue of
default bindings for *package*/*readtable*/*read-base* during
LOAD or COMPILE-FILE, please contact me privately, and I will add 
you individually to the cc list.


-- JonL --

∂27-Oct-88  2247	CL-Cleanup-mailer 	Issue: IN-SYNTAX?    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Oct 88  22:47:20 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01763g; Thu, 27 Oct 88 22:46:48 PDT
Received: by bhopal id AA13441g; Thu, 27 Oct 88 22:45:18 PDT
Date: Thu, 27 Oct 88 22:45:18 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810280545.AA13441@bhopal>
To: CL-Cleanup@SAIL.Stanford.EDU
Subject: Issue: IN-SYNTAX?

I'm still very serious about the question of the default  
package/readtable/read-base  to be in effect when LOAD and 
COMPILE-FILE start to work.  I think the choice made way back 
when, to let all of these assume their dynamic value current at 
the time of the call to LOAD etc, has been counter-productive.  

It means that normal files *cannot* be guaranteed to be loadable;
the caller of LOAD must at least guarantee that (1) some reasonable 
readtable is in effect, (2) that either read-base is 10 or the file has 
isolated itself against integer bases, and (3) that the current package 
is "reasonable enough" to get something correctly read-in for the initial 
IN-PACKAGE or the file has no unqualified symbols.  [Note that very few
users write LISP:IN-PACKAGE -- not even those actually involved in 
writing portable code!].  While it is reasonable for a file to have 
something in it like:
   (in-syntax :package sys:big-loser :read-base 16)
and thus be parsed in a truly non-standard way, I can think of no
other standardized computer language that leaves so much of its
syntax to environmental accidents rather than to clear specification.


I've "looked ahead" [actually "jumped around"] in my mail file to see 
Kent's proposal for STANDARD-VALUE; while quite interesting in its own 
right, it is more focused at shielding the debugger.  Furthermore,
only 3 of the proposed 14 "standard values" would be involved in simple
file reading/loading.

Is there anyone else in this community simiarly concerned about specifying
a standard "foot to stand on", for the syntax of LOADing files?  It may
be too late to bring up such an incompatible change now, but I still 
think it is a serious problem.


-- JonL --


∂27-Oct-88  2300	CL-Cleanup-mailer 	Issue: STANDARD-VALUE (Version 1)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Oct 88  23:00:08 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01772g; Thu, 27 Oct 88 22:59:01 PDT
Received: by bhopal id AA13471g; Thu, 27 Oct 88 22:57:33 PDT
Date: Thu, 27 Oct 88 22:57:33 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810280557.AA13471@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Fri, 21 Oct 88 16:38 EDT <881021163813.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: STANDARD-VALUE (Version 1)

Lucid does something like this -- for those interested, you can look at
lucid::*debugger-bindings* to get a flavor for what sorts of things are
re-bound, and to what kind of values they would be bound to.  Typically,
when the debugger exits, it notices if some value on this list has been
changed by the user, and asks whether you want to keep the changed
value, or to restore the "re-bound" value.

Although most implementations must be doing some very similar things,
I just don't feel this issue is worth trying to standardize now.  There
could be a lot of work involved in reaching a consensus, and I'd much
prefer to see that time spent on already open issues.  January '89 is
"real close" now.


-- JonL --

∂28-Oct-88  0906	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 28 Oct 88  09:06:39 PDT
Received: by ti.com id AA25541; Fri, 28 Oct 88 11:05:02 CDT
Received: from Kelvin by tilde id AA06817; Fri, 28 Oct 88 10:53:49 CDT
Message-Id: <2803046004-4897841@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 28 Oct 88  10:53:24 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@lucid.com>
Cc: sandra%defun@cs.utah.edu, pierson%mist@MULTIMAX.ENCORE.COM,
        CL-Cleanup@SAIL.Stanford.edu
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)
In-Reply-To: Msg of Thu, 27 Oct 88 18:56:24 PDT from Jon L White <jonl@lucid.com>

>   ... Since the force of this proposal is to 
> retract any _standard_ way to hook REQUIRE into LOAD/DEFSYSTEM, then it 
> would still be OK for an implementation to extend REQUIRE in an essentially 
> upwards compatible way. 

The current proposal says:

  ... if the module is not present, REQUIRE signals a correctable error of
  type REQUIRE-ERROR.

According to the new error terminology, this seems to rule out any
possibility of an implementation extension.  An "implementation may be
extended" clause would need to be added if the intent is to permit
extensions.

>    The point you are trying to make, if I read it 
> right, is that previously this "essentially upwards compatible" way was 
> applicable to forms like (REQUIRE <module>), but now would only be applicable 
> to those like (REQUIRE <module> <more-stuff>).

My point is that the behavior for the one-argument case that was required
by CLtL is now forbidden, and without an adequate reason.

>  How serious a problem is this change?

If REQUIRE cannot ever automatically cause the module to be loaded, then I
think it is worthless.   I would rather see it dropped from the standard,
leaving the description in CLtL as a common extension, than to have its
meaning completely changed.  

∂28-Oct-88  1005	CL-Cleanup-mailer 	Re: Issue: CONSTANT-SIDE-EFFECTS (no proposal)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 28 Oct 88  10:04:49 PDT
Received: by ti.com id AA25896; Fri, 28 Oct 88 12:04:14 CDT
Received: from Kelvin by tilde id AA08193; Fri, 28 Oct 88 11:46:42 CDT
Message-Id: <2803049170-5088086@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 28 Oct 88  11:46:10 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@LUCID.COM>
Cc: masinter.pa@XEROX.COM, KMP@SCRC-STONY-BROOK.ARPA,
        CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: CONSTANT-SIDE-EFFECTS (no proposal)
In-Reply-To: Msg of Thu, 27 Oct 88 20:10:08 PDT from Jon L White <jonl@LUCID.COM>

> I would very much like to know what implementations do something akin to 
> the PDP10 MacLisp treatment of "constants", or maybe an extension thereto:
>   (1) except possibly for symbols, they are stored in a separate storage 
>       area, which will be made write-protected at the next "disksave";

The TI and LMI implementations put constants that are referenced by
compiled functions into a write-protected memory area at the time a
compiled object file is loaded.  This is not done for constants in
top-level forms such as DEFVAR.

> Lucid also treats many "compiled-functions" as constants (i.e. "read-only"),

TI and LMI do also, but this doesn't seem relevant since there is no
standard way to reach inside a COMPILED-FUNCTION object.

> Additionally, before investing any time in such a proposal, I wonder how 
> controversial it would be to insist (or, maybe just "suggest") that the 
> interpreter evaluate (QUOTE <anything>) not merely into <anything>, but 
> rather into a possibly-cached copy of <anything> that is known to be 
> CONSTANT-STORAGE-P.  That is, the interpreter must do something very similar
> to what the compiler does for constants.  Without this clause -- without
> rectifying the Lisp 1.5 mistake that defines QUOTE like CAR -- there is
> far too much potential for interpreted/compiled mismatch.  I really 
> wouldn't want to address "constants" if it applied _only_ to the output
> of the compiler.

A couple of years ago I tried to have in-memory compilation write-protect
constants so that it would be consistent with code loaded from a compiled
file.  I eventually gave up because it proved too difficult to avoid
protecting things that users didn't expect to be protected and to avoid
problems with copying shared or recursive data structures.  Note that the
object file loader knows that a value is only used as a constant before it
creates it, so it can create it in the proper memory area, but READ does
not have any such context information, so write-protecting constants in
the interpreter or in-memory compilation means copying them.

Note that while it seems to be agreed that it is wrong to do

  (DEFUN FX () '(A B C))
  (SETF (SECOND (FX)) 'Z)

it is common practice to do things like

  (DEFVAR *X* '(A B C))
  (SETF (SECOND *X*) 'Z)

Perhaps it would be better to say (DEFVAR *X* (COPY-LIST '(A B C))) but
requiring that would invalidate a lot of existing code.  I don't think
that this inconsistency is really a problem because the main reason for
prohibiting alteration of constants in functions is that it (usually
unexpectedly) causes the function to be different the next time it is
called, but a particular instance of a top-level DEFVAR can only be
executed once.  The other reason, sharing of EQUAL constants, is also of
less interest for top-level forms than in functions.

In other words, I don't think an ideal solution is possible, but a
reasonable and useful solution is.

∂28-Oct-88  1110	CL-Cleanup-mailer 	Issue: IN-SYNTAX?    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Oct 88  11:10:40 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 483759; Fri 28-Oct-88 14:10:19 EDT
Date: Fri, 28 Oct 88 14:10 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: IN-SYNTAX?
To: Jon L White <jonl@lucid.com>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8810280545.AA13441@bhopal>
Message-ID: <19881028181006.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

Only one comment from me: be careful not to make it impossible to write
programs that set up the environment that they know they want, and then
call LOAD or COMPILE-FILE.  In other words, right now those functions
are (approximately) primitives that just do one thing, and if they are
changed to also set up a particular environment, the primitives need to
remain accessible too.

∂28-Oct-88  1151	CL-Cleanup-mailer 	Issue: IN-SYNTAX?    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Oct 88  11:51:02 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 483793; Fri 28-Oct-88 14:49:57 EDT
Date: Fri, 28 Oct 88 14:49 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: IN-SYNTAX?
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: jonl@lucid.com, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19881028181006.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <881028144955.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Fri, 28 Oct 88 14:10 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    Only one comment from me: be careful not to make it impossible to write
    programs that set up the environment that they know they want, and then
    call LOAD or COMPILE-FILE.  In other words, right now those functions
    are (approximately) primitives that just do one thing, and if they are
    changed to also set up a particular environment, the primitives need to
    remain accessible too.

Saying that LOAD and COMPILE-FILE bind the standard value of the variables
in question (and perhaps all standard variables) and then saying that people
should do LET-STANDARD-VALUE in the scenario you allude to would be ok, right?

∂28-Oct-88  1322	CL-Cleanup-mailer 	Issue: IN-SYNTAX?    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Oct 88  13:22:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 483876; Fri 28-Oct-88 16:21:34 EDT
Date: Fri, 28 Oct 88 16:21 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: IN-SYNTAX?
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: jonl@lucid.com, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881028144955.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881028202112.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 28 Oct 88 14:49 EDT
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

	Date: Fri, 28 Oct 88 14:10 EDT
	From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	Only one comment from me: be careful not to make it impossible to write
	programs that set up the environment that they know they want, and then
	call LOAD or COMPILE-FILE.  In other words, right now those functions
	are (approximately) primitives that just do one thing, and if they are
	changed to also set up a particular environment, the primitives need to
	remain accessible too.

    Saying that LOAD and COMPILE-FILE bind the standard value of the variables
    in question (and perhaps all standard variables) and then saying that people
    should do LET-STANDARD-VALUE in the scenario you allude to would be ok, right?

Yes, if "bind the standard value" means "bind each variable to its standard
value" rather than "temporarily change what the standard value is."  Of course
it would be an incompatible change.

∂28-Oct-88  1341	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 28 Oct 88  13:41:40 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA03194; Fri, 28 Oct 88 16:40:26 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA25763; Fri, 28 Oct 88 16:44:21 EDT
Message-Id: <8810282044.AA25763@mist.UUCP>
To: David N Gray <Gray%DSG.csc.ti.com@multimax>
Cc: CL-Cleanup%SAIL.Stanford.edu@multimax
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
In-Reply-To: Your message of Fri, 28 Oct 88 10:53:24 -0500.
Date: Fri, 28 Oct 88 16:44:18 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

It seems to me that several implementors have serious problems with
the proposed restriction that gives REQUIRE a portable meaning.  I put
the restriction in there because without it I feel that REQUIRE
contributes much more to non-portability than portability.

Given these objections I now think that the best (least bad?) option
is to admit that PROVIDE and REQUIRE supply only trivial portable
functionality and remove them from the language.  This will require no
implementations to change but will clearly indicate to users that
these constructs are not useful in portable code.

Can we decide to do this now and move on to more important topics?

∂28-Oct-88  1358	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Oct 88  13:58:17 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 483904; Fri 28-Oct-88 16:55:09 EDT
Date: Fri, 28 Oct 88 16:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
To: pierson%mist@MULTIMAX.ARPA
cc: Gray@DSG.CSC.TI.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8810282044.AA25763@mist.UUCP>
Message-ID: <881028165459.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Fri, 28 Oct 88 16:44:18 EDT
    From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    ... I feel that REQUIRE contributes much more to non-portability
    than portability. ... Given these objections I now think that the
    best (least bad?) option is to admit that PROVIDE and REQUIRE
    supply only trivial portable functionality and remove them from
    the language.  This will require no implementations to change
    but will clearly indicate to users that these constructs are not
    useful in portable code.

Excellent analysis.

    Can we decide to do this now and move on to more important topics?

Great idea.

∂28-Oct-88  1403	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 28 Oct 88  14:03:16 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 28 Oct 88 16:59:29 EDT
To: CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
In-reply-to: Your message of Fri, 28 Oct 88 16:44:18 -0400.
             <8810282044.AA25763@mist.UUCP> 
Date: Fri, 28 Oct 88 16:59:10 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU


I favor flushing PROVIDE and REQUIRE from the standard.  Maybe someday
we'll figure out what we really want instead, but not in this round of
discussion.  I'm now pretty sure that "the right thing" will look nothing
like the current PROVIDE and REQUIRE mechanisms, and that nothing is to be
gained by tightening them up slightly.

-- Scott

∂28-Oct-88  1549	CL-Cleanup-mailer 	Issue: IN-SYNTAX?    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Oct 88  15:49:01 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02415g; Fri, 28 Oct 88 15:48:00 PDT
Received: by bhopal id AA16141g; Fri, 28 Oct 88 15:46:31 PDT
Date: Fri, 28 Oct 88 15:46:31 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810282246.AA16141@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: David A. Moon's message of Fri, 28 Oct 88 14:10 EDT <19881028181006.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: IN-SYNTAX?

re: . . . be careful not to make it impossible to write
    programs that set up the environment that they know they want, and then
    call LOAD or COMPILE-FILE.  

I wondered about this -- namely, is it necessary to provide backwards
compatibility in exactly the same way it is done now, or would some
slightly more kludgy replacement be satisfactory?  It has always seemed
to me that the context sensitivity of LOAD/COMPILE-FILE has been a 
"throwback" to MacLisp days, where the standard input radix was octal!

But even if 99.44% of all programs never tamper with the improved syntax 
standards, I agree that there must be a reasonably convenient way to 
overide the "binding" parts of LOAD/COMPILE-FILE.  What would you think 
of the following avenues:

    (1) have a keyword argument to LOAD/COMPILE-FILE that says "start
        out in current syntax rather than in standard syntax"; or have
        keyword arguments for all the syntax variables.
	[Pro: simplest to user; Con: added complexity in general, and 
         more work for implementors in particular]

    (2) have all standard syntax specifications be user-accessible as
        the values of special variables; thus ordinary lambda-binding
        would suffice for tailoring the "standard" environment.
        [Pro: makes the "primitives" user-accessible; Con: the set of
        such variables might not be fixed between implementations, and
        global-variable access to internal data is less "safe" than
        a functional interface to it]

    (3) have a documentary suggestion that when one wants to retain the
        syntax environment, he should arrange such communication via
        his own global variables;  e.g.,
          (defun my-load (&rest args)
            (let ((*my-package* *package*)
                  (*my-readtable* *readtable*)
                  (*my-read-base* *read-base*))
              (apply #'load args)))
       then add the following statement at the beginning of any file
       for which this hack is needed:
           (in-syntax :package *my-package*
                      :readtable *my-readtable*
                      :read-base *my-read-base*)
       [Pro: puts the burden on the weirdo who _really_ wants this;
        Con: can work unless you can modify the in-syntax of the file.]


By the bye, I've ignored *READ-SUPPRESS* and *READ-DEFAULT-FLOAT-FORMAT*
til now.  Probably the former doesn't need to be redefinable by the
IN-SYNTAX form, but surely it needs to be "protected" over LOAD/COMPILE-FILE.
As to the latter, I don't have a great argument for it now, but I rather
tend to view it as a global "site installation" parameter, rather than as 
a useful dynamic variable; my mind would be changed if I heard of 
significant "dynamic" use of it.


-- JonL --



∂28-Oct-88  1645	CL-Cleanup-mailer 	Issue: IN-SYNTAX?    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Oct 88  16:38:58 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 484000; Fri 28-Oct-88 19:38:34 EDT
Date: Fri, 28 Oct 88 19:38 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: IN-SYNTAX?
To: Jon L White <jonl@lucid.com>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8810282246.AA16141@bhopal>
Message-ID: <19881028233810.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 28 Oct 88 15:46:31 PDT
    From: Jon L White <jonl@lucid.com>

    re: . . . be careful not to make it impossible to write
	programs that set up the environment that they know they want, and then
	call LOAD or COMPILE-FILE.  

    I wondered about this -- namely, is it necessary to provide backwards
    compatibility in exactly the same way it is done now, or would some
    slightly more kludgy replacement be satisfactory?  

I said don't make it impossible, not don't make it incompatible.  Of course
it would be better to be compatible, but that can be judged on its own
merits and might be outweighed by the esthetics of a new approach.

    ....What would you think of the following avenues:

I have another suggestion, which is to leave LOAD and COMPILE-FILE the
way they are, and add WITH-STANDARD-IO-ENVIRONMENT (a Symbolics Common
Lisp feature), which binds all of the variables to their standard values,
and say you should wrap this around calls to LOAD and COMPILE-FILE when
that's what you want.  The reason for WITH-STANDARD-IO-ENVIRONMENT rather
than LET is that you don't have to know all the variables to bind, and
indeed there might be implementation-dependent ones as well as all the
standard ones.

The only problem with this suggestion is that people might be calling
LOAD by hand as the way to load programs, and wouldn't like to have to
type in a WITH-STANDARD-IO-ENVIRONMENT form.  I suppose there are
probably still environments out there in which calling LOAD by hand is
the way to load programs.  But I would hope that more typically one
would call some kind of Load Program command, which would do the
WITH-STANDARD-IO-ENVIRONMENT for you.

	(1) have a keyword argument to LOAD/COMPILE-FILE that says "start
	    out in current syntax rather than in standard syntax"; or have
	    keyword arguments for all the syntax variables.
	    [Pro: simplest to user; Con: added complexity in general, and 
	     more work for implementors in particular]

I prefer the second of those two suggestions over the first of them,
it seems more consistent with the rest of Common Lisp.

In Symbolics Common Lisp, LOAD and COMPILE-FILE have a :PACKAGE argument
that does this.  However, we don't have arguments for the other things,
like base and readtable, because this is thought of as a way to override
what the file says via the -*- line.  In general our system is based
around the assumption that most files use the -*- mechanism for
specifying the attributes, which unfortunately Common Lisp didn't adopt,
and loading or compiling with the caller's attributes is an unusual case
seen only in a few straight Common Lisp programs.  It's also worth noting
that LOAD of a binary file always loads the file with the same attributes
it was compiled with, and if all implementations did this, the issue of
portable programs would be lessened, since compiled programs would always
be loaded correctly, and people who compile programs are no doubt more
careful than people who load them.

	(2) have all standard syntax specifications be user-accessible as
	    the values of special variables; thus ordinary lambda-binding
	    would suffice for tailoring the "standard" environment.
	    [Pro: makes the "primitives" user-accessible; Con: the set of
	    such variables might not be fixed between implementations, and
	    global-variable access to internal data is less "safe" than
	    a functional interface to it]

I agree with the Con.

	(3) have a documentary suggestion that when one wants to retain the
	    syntax environment, he should arrange such communication via
	    his own global variables;  e.g.,
	      (defun my-load (&rest args)
		(let ((*my-package* *package*)
		      (*my-readtable* *readtable*)
		      (*my-read-base* *read-base*))
		  (apply #'load args)))
	   then add the following statement at the beginning of any file
	   for which this hack is needed:
	       (in-syntax :package *my-package*
			  :readtable *my-readtable*
			  :read-base *my-read-base*)
	   [Pro: puts the burden on the weirdo who _really_ wants this;
	    Con: can work unless you can modify the in-syntax of the file.]

This does not appeal to me at all.

    By the bye, I've ignored *READ-SUPPRESS* and *READ-DEFAULT-FLOAT-FORMAT*
    til now.  Probably the former doesn't need to be redefinable by the
    IN-SYNTAX form, but surely it needs to be "protected" over LOAD/COMPILE-FILE.
    As to the latter, I don't have a great argument for it now, but I rather
    tend to view it as a global "site installation" parameter, rather than as 
    a useful dynamic variable; my mind would be changed if I heard of 
    significant "dynamic" use of it.

Outputting postscript.

The fact that there are several variables like this that people tend to
overlook is an argument for WITH-STANDARD-IO-ENVIRONMENT.

∂28-Oct-88  2333	CL-Cleanup-mailer 	issue DECLARATION-SCOPE   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Oct 88  23:33:50 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02661g; Fri, 28 Oct 88 23:31:51 PDT
Received: by bhopal id AA17474g; Fri, 28 Oct 88 23:30:24 PDT
Date: Fri, 28 Oct 88 23:30:24 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810290630.AA17474@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: sandra%defun@cs.utah.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 26 Oct 88 23:52 EDT <19881027035211.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: issue DECLARATION-SCOPE

re: First of all, the "free"/"bound" distinction isn't some crazy
    categorization that we can just remove.  

I've never claimed that; I've only claimed that embellishing it, and using
it for the purpose of explaining DECLARE scoping is not only unnecessary, 
but adding to the confusion surrounding the issue.  [Incidentally, the 
"crazy" in my msg came from a characterization of the "prohibition found 
on p158 of CLtL", which happily is a matter of the past now that 
DECLARE-TYPE-FREE is virtually approved.  The whole point of my msg
was to glory in the fact that declaration scoping is now free of this
"crazy" constraint; until this time, scoping had to have an explicit
exception for "free" type declarations.]


re: . . .  It [the "free"/"bound" distinction] means exactly the same
    thing as your phrase "the name-bindings, if any, to which they apply".

Well, I've never gotten that impression from the lengthy exposition in the
current proposal.  More to the point, the applicability of a declaration 
must be specified somewhere in the standards document *** and this must be 
done purely independently of the scoping issue ***.  My claim is that this 
independent specification can already be presumed when discussing the 
scoping issue.

That is, somehow, one comes to understand:
  (1) that SPECIAL and TYPE declarations never apply to function bindings;
  (2) that INLINE and FTYPE declarations never apply to variable bindings; 
  (3) that OPTIMIZE and DECLARATION never apply to either kind of binding;
  (4) and that (<declaration> X) never applies to a binding of Y.
This "understanding" is for the most part distributed throughout the 
individual declaration definitions.  Surely, you can appreciate the 
importance of this point -- that the name-applicibility issue for bindings
must be specified independently of how the declaration scoping issue is
decided, and it certainly will not depend on which of the three alternative 
scoping proposals is chosen!


re: . . .  The major point is your claim that it's
    obvious that the scope of a free declaration should be just the body of
    the special form, and not include any additional code, such as
    initialization forms.   ...

That wasn't my claim [or, not exactly].  Restating it (for the nth time!):
   (1) the scope should always include the body form, and
   (2) it should also include any correlated name binding ... which by 
       the _already-specified_ rules of lexical scoping for variables 
       would include certain init-forms in LET* [but of course wouldn't 
       include any in plain LET].
Part of the simplicity of the approach I've been advocating is that we
reduce the thorny part of the scoping issue for DECLARE to the *** already 
solved *** scoping issue for lexical variables.  There certainly is no need 
to bring in the "free/bound declaration" distinction for the purpose of 
understanding lexical variable scoping.

Indeed, not arbitrarily including init-forms in the declaration is slightly 
different from the opaque (even if "unambiguous") prescriptions given in 
CLtL; I claim it is a difference for the better, and will directly spell 
out three significant improvements when I put the claim into proposal 
format [Larry: I should have this done before next Wednesday].


re:                       ...   Perhaps we would choose to adopt this after
    discussion, but it's not obviously correct, it's not obviously simpler
    than setting the scope to the entire special form, and most importantly
    it is an incompatible change, directly contradicting the scope defined
    by CLtL ... If you don't see that, look at the "defun few" example in 
    the middle of page 155 of CLtL.

Quoting from the original DECLARATION-SCOPE proposal by Hornig, as well as
the version you most recently sent me privately, the categorey is listed 
as CHANGE -- meaning "incompatible change".  At stake is not whether one 
or the other is "an incompatible change", but which of the two alternative 
semantics is more natural, easier to specify, and less likely to be 
confusing to end-users.


re:  My reason for preferring that the scope of a free declaration is the
    entire special form is to avoid an incompatible change.

Not only does the Category CHANGE, from you own version of the proposal,
imply incompatible change, but you have apparently forgotten the
"Current practice:" section of that proposal, which says in part:

    ". . . Most implementations implement
     the rules in CLtL.  Symbolics currently implements rules based on
     Zetalisp which are different from both this proposal and Common Lisp.
     Symbolics plans to change to Common Lisp rules in the future."

The question, of course, is just what should "Common Lisp rules" be?  
Since many folks have been grossly confused by CLtL, and since your own
proposal calls for a CHANGE, then let us strive to obtain a Change For
The Better.  I might note that at least some part of one other system 
seems to implement the rules I've been praising.  



-- JonL --

∂29-Oct-88  0016	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 6)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Oct 88  00:16:18 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02676g; Sat, 29 Oct 88 00:15:27 PDT
Received: by bhopal id AA17560g; Sat, 29 Oct 88 00:14:00 PDT
Date: Sat, 29 Oct 88 00:14:00 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810290714.AA17560@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@Sail.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 26 Oct 88 22:58 EDT <19881027025834.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: DEFPACKAGE (version 6)

re: :INTERNAL was a typo for :INTERN; I apologize. 

Ok, fine by me; we stick with the "VERB" analogy for the options names
rather than the "ADJECTIVE" analogy.


re: 	An attempt to re-define a package with a smaller set of attributes 
	should signal a  continuable error; at most one such error is to be
	signalled per call to DEFPACKAGE, regardless of how many attributes 
        are being re-tracted; upon continuation, the package is created with 
        exactly as specified.

    Even without the typos I would object to this.  It's not clear to me
    that signalling an error is the correct response in all programming
    environments for evaluating a DEFPACKAGE with fewer attributes.
    . . . 
    I think it would be a much better idea to leave redefinition of packages
    undefined, just like redefinition of functions or macros.

I thought the above wording came from a consensus among several people 
(who? maybe KMP and vanMelle?); probably that was the week that you were 
out.  Nevertheless, I strongly disagree that we can leave the redefinition 
question completely alone; we simply cannot allow DEFPACKAGE to operate
like DEFUN, where only the name-to-object mapping is changed.  [By the
way, even if CLtL doesn't spell it out, "common practice" for more than
20 years says that re-doing a DEFUN or DEFMACRO doesn't alter an existing 
function object, but instead simply changes the symbol-function "cell".]

Like CLOS classes and generic functions, packages are a global database
referenced "by name" and incrementally definable; a subsequent redefinition
must give some accountability to the old instances.   I'm not at all 
impressed that "many people still argue that CLOS got it wrong";  at least 
it clearly states that class redefinition isn't merely an alteration of the 
name-to-class mapping.


-- JonL --





∂30-Oct-88  1339	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Oct 88  13:37:59 PST
Received: from Semillon.ms by ArpaGateway.ms ; 30 OCT 88 13:37:20 PST
Date: Sun, 30 Oct 88 13:37 PST
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
To: Scott.Fahlman@B.GP.CS.CMU.EDU
cc: CL-Cleanup@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: The message of 28 Oct 88 13:59 PDT from
 Scott.Fahlman@B.GP.CS.CMU.EDU
Message-ID: <19881030213708.9.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no

    Date: Fri, 28 Oct 88 16:59:10 EDT
    From: Scott.Fahlman@B.GP.CS.CMU.EDU

    I favor flushing PROVIDE and REQUIRE from the standard.  

I agree.
-------

∂31-Oct-88  0957	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 4)  
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 31 Oct 88  09:57:25 PST
Received:  by multimax.ARPA (5.51/25-eef)
	id AA29649; Mon, 31 Oct 88 12:56:21 EST
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA28263; Mon, 31 Oct 88 13:00:15 EST
Message-Id: <8810311800.AA28263@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 4)
Date: Mon, 31 Oct 88 13:00:12 EST
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

Here's the reversal.  The Current Practice section is intentionally
abstracted because the proposed change is incompatible with everyone.

Issue:         REQUIRE-PATHNAME-DEFAULTS
References:    *MODULES*, PROVIDE, REQUIRE, pp 188-191
               LOAD, pp 426-427
Category:      CHANGE
Edit history:  Version 1 by Pierson 9/13/88
               Version 2 by Pierson 9/19/88, change PROVIDE stuff per comments
               Version 3 by Pierson 10/17/88, remove PROVIDE locaction specs.
	       Version 4 by Pierson 10/31/88, remove from language
Status:        For Internal Discussion

Problem description:

PROVIDE and REQUIRE are a dual-purpose pair of functions that attempt
to provide multi-file Common Lisp programs with a single mechanism to
detect and correct incorrect load sequences.  These functions were
also designed to be used for general file inclusion in Common Lisp.
Unfortunately, the file loading feature of REQUIRE is specified such
that it is inherently non-portable and environment dependent.

Proposal (REQUIRE-PATHNAME-DEFAULTS:ELIMINATE):

Remove PROVIDE and REQUIRE from the Common Lisp standard.

Test Cases/Examples:

(PROVIDE 'fft)

Would not be Common Lisp.

(REQUIRE 'fft)

Would not be Common Lisp.

Rationale:

The file loading feature of REQUIRE is non-portable.  The remaining
functionality of PROVIDE and REQUIRE (pushing and testing *MODULES*)
can easily be implemented by user code.  Since some implementations
will retain the automatic module loading features of REQUIRE and some
won't, use of REQUIRE will almost always make code less portable.

Current practice:

All implementations currently support some sort of file loading via
REQUIRE.  In general, the Lisp Machine implementations use the second
argument to invoke the system module building/loading facility while
the Unix implementations simply try to load a file in the current
directory.

Cost to Implementors:

Implementations will have to move PROVIDE and REQUIRE to their package for
implementation extensions and change their documentation to indicate
that PROVIDE and REQUIRE are non-standard.  This is a fairly small change.

Cost to Users:

Any (non-portable) user programs that rely on PROVIDE and REQUIRE may
have to change.  Since most implementations will probably keep these
functions as extensions to Common Lisp, this change will probably only
be required by user programs that wish to be portable.  Since the
current behavior is decidedly non-portable, these programs would
probably have to change anyway.

Cost of non-Adoption:

PROVIDE and REQUIRE will continue as impediments to portability.

Benefits:

The non-portability of PROVIDE and REQUIRE will be made obvious.

Aesthetics:

This simplifies the language by removing an environment-dependent
feature. 

Discussion:

Pierson, Pitman, Fahlman, and Gregor support this proposal.

The cleanup committee tried to come up with a proposal to restrict
PROVIDE and REQUIRE to the portable subset of their functionality.
This failed because several implementors objected that it compelled
them to significantly reduce the functionality they provided users in
order to create a trivial feature which any user could easily write
for herself.

∂31-Oct-88  1018	CL-Cleanup-mailer 	Re: Issue: DESCRIBE-INTERACTIVE (Version 3)   
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 31 Oct 88  10:18:23 PST
Received:  by multimax.ARPA (5.51/25-eef)
	id AA29734; Mon, 31 Oct 88 13:17:26 EST
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA28477; Mon, 31 Oct 88 13:21:19 EST
Message-Id: <8810311821.AA28477@mist.UUCP>
To: "David A. Moon" <Moon%STONY-BROOK.SCRC.Symbolics.COM@multimax>
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: DESCRIBE-INTERACTIVE (Version 3) 
In-Reply-To: Your message of Wed, 26 Oct 88 22:45:00 -0400.
             <19881027024541.0.MOON@EUPHRATES.SCRC.Symbolics.COM> 
Date: Mon, 31 Oct 88 13:21:15 EST
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    I oppose DESCRIBE-INTERACTIVE:NO on the grounds that it creates
    extra work for implementors and users of at least one implementation,
    for no compelling reason.
    
I have to disagree that there is "no compelling reason".  The problem
centers on whether on not you believe that portable programs should be
able to describe objects to users (and how compelling you feel that
need is).

    Instead of eliminating functionality from DESCRIBE, it would be better
    to suggest that DESCRIBE methods (and any other programs that ask
    questions of the user) should call the recently added
    STREAM-INTERACTIVE-P function (I'm not sure I've got the right name) so
    as to avoid asking questions when there is no one to answer them.  This
    would address the stated goal "to call DESCRIBE in a batch applications
    without hanging the application" without requiring incompatible changes
    to current practice.

Unfortunately an implementation suggestion does not license portable
programs to rely on it.  While your proposal might increase the
probability that a portable program that called DESCRIBE wouldn't
break, it doesn't eliminate it.

In general, I don't see what the world gains from having DESCRIBE be a
restricted INSPECT instead of an output-only function.  On the other
hand, I don't want to waste a lot of everyone's time arguing this.

∂31-Oct-88  1059	CL-Cleanup-mailer 	Re: Issue: DEFPACKAGE (version 6)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 31 Oct 88  10:59:51 PST
Received: from Semillon.ms by ArpaGateway.ms ; 31 OCT 88 10:38:01 PST
Date: 31 Oct 88 10:37 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DEFPACKAGE (version 6)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Sat, 29 Oct 88
 00:14:00 PDT
To: CL-Cleanup@Sail.stanford.edu
Message-ID: <881031-103801-5947@Xerox>

Arguments of the form "we should leave A undefined because B is undefined"
are weak, especially if there is some hope of defining B.

However, I don't think we will make much progress on DEFPACKAGE unless we
leave, for now, that the results of executing more than one DEFPACKAGE on
the same string is unspecified. We might want to add to the commentary that
we expect some implementations may signal a continuable error, but other
environment-specific action might also be reasonable.


Now that we have the new error terminology, I think encoruaging the
signalling of an error might be a reasonable resolution if we expect
legitimate programs to actually catch the error and process it. One
criteria by which we should judge that might be how far we are willing to
specify the exact nature of the condition to be signalled.

In this case, we're not close to a good design that is agreeable.

Could we get a new writeup with the "redefinition" behavior explicitly
vague?

∂31-Oct-88  1118	CL-Cleanup-mailer 	Re: Issue: DESCRIBE-INTERACTIVE (Version 3)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 31 Oct 88  11:18:07 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 484669; Mon 31-Oct-88 14:17:32 EST
Date: Mon, 31 Oct 88 14:17 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DESCRIBE-INTERACTIVE (Version 3) 
To: Dan L. Pierson <pierson%mist@MULTIMAX.ARPA>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8810311821.AA28477@mist.UUCP>
Message-ID: <19881031191709.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 31 Oct 88 13:21:15 EST
    From: Dan L. Pierson <pierson%mist@multimax.ARPA>

	I oppose DESCRIBE-INTERACTIVE:NO on the grounds that it creates
	extra work for implementors and users of at least one implementation,
	for no compelling reason.
    
    I have to disagree that there is "no compelling reason".  The problem
    centers on whether on not you believe that portable programs should be
    able to describe objects to users (and how compelling you feel that
    need is).

I believe they should, but I don't feel that the DESCRIBE-INTERACTIVE:NO
proposal is necessary to allow them to do so.

	Instead of eliminating functionality from DESCRIBE, it would be better
	to suggest that DESCRIBE methods (and any other programs that ask
	questions of the user) should call the recently added
	STREAM-INTERACTIVE-P function (I'm not sure I've got the right name) so
	as to avoid asking questions when there is no one to answer them.  This
	would address the stated goal "to call DESCRIBE in a batch applications
	without hanging the application" without requiring incompatible changes
	to current practice.

    Unfortunately an implementation suggestion does not license portable
    programs to rely on it.  While your proposal might increase the
    probability that a portable program that called DESCRIBE wouldn't
    break, it doesn't eliminate it.

But this is simply an argument that no portable program can call any
function that it did not define itself, because that function might
have a bug in it!

    In general, I don't see what the world gains from having DESCRIBE be a
    restricted INSPECT instead of an output-only function.  On the other
    hand, I don't want to waste a lot of everyone's time arguing this.

I'll try not to send any more mail on this subject.

∂31-Oct-88  1200	CL-Cleanup-mailer 	Re: Issue: DESCRIBE-INTERACTIVE (Version 3)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 31 Oct 88  12:00:27 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 484699; 31 Oct 88 14:59:42 EST
Date: Mon, 31 Oct 88 14:59 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DESCRIBE-INTERACTIVE (Version 3) 
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: pierson%mist@MULTIMAX.ARPA, cl-cleanup@sail.stanford.edu
In-Reply-To: <19881031191709.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <881031145931.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Mon, 31 Oct 88 14:17 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    ... I believe they should, but I don't feel that the
    DESCRIBE-INTERACTIVE:NO proposal is necessary to allow them
    to do so. ...

I certainly think your intermediate proposal might be the right way to
gloss this messy issue with a minimum of incompatible change, but while
we're on the subject I feel I should point out that the issue of
interactive and the issue of batch, while strongly [inversely]
correlated in practice are not necessarily so strongly correlated in the
abstract. You could have batch applications which work on the terminal,
or even non-batch situations where it was important to see the output of
DESCRIBE without needing intervention.  The most irritating case is one
where the query gets asked on a window for which there is no way to
select the window to type to. Similarly, you could have situations where
data was going to a file and the query were still appropriate. So noticing
the interactiveness of the stream is one that is statistically less likely
to lead to trouble, but it is not, strictly, a real solution to the problem.

I keep falling back to what somebody once called "pitman's two-bit rule"
of language design -- it goes something like: if you have two bits of
info to represent, use at least two bits to do the representation. Since
interactiveness of the input argument and need for query are potentially
orthogonal, you can't get away with passing only one argument and using
it for both purposes without running into trouble some of the time. A
more robust solution would add a :DETAILED or :VERBOSE option to
DESCRIBE, which could be T, NIL, or :ASK.

∂31-Oct-88  1202	CL-Cleanup-mailer 	Issue: IN-SYNTAX?    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 31 Oct 88  12:02:39 PST
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA03394g; Mon, 31 Oct 88 12:01:41 PST
Received: by bhopal id AA01329g; Mon, 31 Oct 88 12:00:14 PST
Date: Mon, 31 Oct 88 12:00:14 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8810312000.AA01329@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: David A. Moon's message of Fri, 28 Oct 88 19:38 EDT <19881028233810.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: IN-SYNTAX?

re: The fact that there are several variables like this that people tend to
    overlook is an argument for WITH-STANDARD-IO-ENVIRONMENT.

Right, which is why my first suggestion was to add an argument to LOAD that 
says "let the syntax be the current one, rather than the standard one".  

I have the feeling that taking the standard defaults is what 99.44% of 
all programs would be doing, and am thus willing to contemplate the more 
incompatible change to LOAD.  This would leave open a possibility for
a macro named something like WITH-STANDARD-INPUT-SYNTAX, which would 
dynamically bind the "standard" settings to the current values of the 
various documented parameters (or to keyword arguments).  The burden is 
thus shifted to the 0.56% of the cases that wanted something "non-standard".
I gathered from your reply to KMP that you don't think much of being able 
to dynamically bind the "standards".


re:     [jonl] As to [*read-default-float-format*], I don't have a great 
	  argument for it now, but I rather tend to view it as a global "site 
	  installation"  parameter, rather than as a useful dynamic variable; 
	  my mind would be changed if I heard of significant "dynamic" use.
    [moon] Outputting postscript.

Well, FORMAT's ~E or ~G with hairy prefix parameters could be used instead. 
[I presume you mean while PRINTing, rather than while READing; the READ side
is the important one for IN-SYNTAX.]  This looks like a gap in CL in that 
there is no corresponding parameter *PRINT-DEFAULT-FLOAT-FORMAT*; it's a bit 
like letting PRINT use *READ-BASE* rather than *PRINT-BASE*.   Were that 
corrected, then I think the conjecture about "site installation parameter" 
_might_ stand.



-- JonL --



∂31-Oct-88  1226	CL-Cleanup-mailer 	Re: Issue: DESCRIBE-INTERACTIVE (Version 3)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 31 Oct 88  12:26:49 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 484723; Mon 31-Oct-88 15:24:34 EST
Date: Mon, 31 Oct 88 15:24 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DESCRIBE-INTERACTIVE (Version 3) 
To: pierson%mist@MULTIMAX.ARPA
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881031145931.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <881031152428.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

By the way, I had a few points I had wanted to make and feel like I
finally gotten around to making them in my last message.
Since any of Yes, No, or Explicitly-Vague is ok by me (with only
Implicitly-Vague, the status quo, being unacceptable), I don't plan
to say much more on this either.

∂31-Oct-88  1358	CL-Cleanup-mailer 	Re: issue EXIT-EXTENT
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 31 Oct 88  13:58:50 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA04617; Mon, 31 Oct 88 14:58:31 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA02796; Mon, 31 Oct 88 14:58:28 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810312158.AA02796@defun.utah.edu>
Date: Mon, 31 Oct 88 14:58:26 MST
Subject: Re: issue EXIT-EXTENT
To: masinter.pa@Xerox.COM
Cc: sandra%defun@cs (Sandra J Loosemore), cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM, 31 Oct 88 12:25 PST

OK, it's starting to make some sense now.  I think the thing that was
confusing me the most was the use of the noun "exit" to refer to the
thing that is being exited *from*, while I was interpreting it as its
dictionary definition as "the act of leaving".  Things would be much
more understandable if the writeup avoided this terminology and just
talked about the dynamic extent of CATCH, BLOCK, and TAGBODY forms.

Now that I think I understand the proposal, I see a serious problem.
In the implementation I did for the Atari ST, UNWIND-PROTECT cleanup
forms are executed with all outer CATCHes still in place.  It seems to
me like this falls into the category of the second paragraph in the
"Current Practice" section, and that this is legal according to CLtL.

Consider the case:

(defun test ()
    (catch 'foo
	(format t "The inner catch returns ~s.~%"
		(catch 'foo
		    (unwind-protect (throw 'foo :first-throw)
			(throw 'foo :second-throw))))
	:outer-catch))

In my implementation, the THROW in the cleanup form of the
UNWIND-PROTECT happens when the inner CATCH (that is the target of the
first throw) is still in effect.  This means that the inner catch
returns :SECOND-THROW and the outer CATCH returns :OUTER-CATCH.  (This
is also the behavior exhibited by Lucid.)

However, under the proposal EXIT-EXTENT:MINIMAL, the dynamic extent of
the inner CATCH must end as soon as the first THROW begins.  Therefore
the target of the second THROW must be the outer CATCH.  According to
this proposal, the inner CATCH would never return and the outer one
must return :SECOND-THROW.  Right? 

This leads me to conclude that in spite of what the "Cost to
Implementors" section says, currently valid implementations *will* be
made invalid by this proposal, and that it would not be legitimate for
implementations to implement longer extents (as mentioned in the
"Esthetics" section).  Or am I still misunderstanding something?

-Sandra
-------

∂31-Oct-88  1517	CL-Cleanup-mailer 	Re: issue EXIT-EXTENT
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 31 Oct 88  15:17:33 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA07883; Mon, 31 Oct 88 16:17:18 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA02896; Mon, 31 Oct 88 16:17:14 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810312317.AA02896@defun.utah.edu>
Date: Mon, 31 Oct 88 16:17:12 MST
Subject: Re: issue EXIT-EXTENT
To: masinter.pa@Xerox.COM
Cc: sandra%defun@cs.ARPA (Sandra J Loosemore), cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM, 31 Oct 88 14:47 PST

> Date: 31 Oct 88 14:47 PST
> From: masinter.pa@Xerox.COM
> 
> The proposal would separate the extent of the visibility of the CATCH tag
> from the actual extent of the exit. The CATCH tag would still be visible to
> the THROW inside the UNWIND-PROTECT cleanup clause, it would merely be an
> "error" to execute that THROW.

That doesn't seem very satisfying or useful.  My reading of the
proposal is that the dynamic extent of the CATCH definitely ends as
soon as the THROW commences.  If the intent is really to make it "an
error" to depend on this behavior, then why doesn't the proposal just
say that the dynamic extent of the CATCH is unspecified?

-Sandra
-------

∂31-Oct-88  1842	CL-Cleanup-mailer 	Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 2) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 31 Oct 88  18:42:32 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 31 OCT 88 10:52:53 PST
Date: 31 Oct 88 10:51 PST
From: masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 2)
To: cl-cleanup@sail.stanford.edu
Message-ID: <881031-105253-5995@Xerox>

I think this is the correct approach, and consistent with the charter to
deal with the CLOS integration issues that the CLOS proposal didn't. 

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

Date: Mon, 17 Oct 88 13:40 PDT
From: Gregor.pa
Subject: defstruct print function inhertiance
To: Masinter.PA
Message-ID: <19881017204013.9.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no


The proposal should say that it defines an approptiate method on the
print-object generic function.  This is simpler to say, and precisely
defines all the behavior that is being difficult to define here.  It
also gives the user more, since it makes it clear how they can override
an inherited print function with defmethod.

I guess its something like:

(defstruct (foo (:print-function (lambda (x y z) ..))) a b c)

==>
(defmethod print-object ((x foo) y)
  (let ((z <I don't know what>))
    ...))
-------


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

∂31-Oct-88  1843	CL-Cleanup-mailer 	Re: Issue: ELIMINATE-FORCED-CONSING (Version 3)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 31 Oct 88  18:43:07 PST
Received: from Semillon.ms by ArpaGateway.ms ; 31 OCT 88 11:40:44 PST
Date: 31 Oct 88 11:40 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ELIMINATE-FORCED-CONSING (Version 3)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Thu, 13 Oct 88 16:33 EDT
To: CL-Cleanup@SAIL.Stanford.EDU, trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Message-ID: <881031-114044-6089@Xerox>

We need to be careful about cc'ing the relevant parties on discussion on of
issues. I've forwarded to jrg those messages that originally went to
cl-cleanup only.

This issue was not distributed to X3J13 prior to the meeting, I think. I am
reluctant to have it on the list with its current name and am tempted, at
this late date, to rename it.
(SEQUENCE-FUNCTIONS-CONSING:ADD-TARGET-KEYWORDS) or some such.

Jim Allard, I believe, made the comment that, given a dynamic-extent
construct, it is possible to do "cons-free" programming with some larger
awkwardness by writing an idiom where the new sequence is generated with
dynamic extent and then the old sequence is either copied or modified.

I wonder whether some special purpose recognizition of idiomatic nesting of
REPLACE with a sequence function inside compilers or optimizers might well
have the same benefit without increasing the apparent complexity of the
language. (I believe some APL compilers work this way.)


∂31-Oct-88  1843	CL-Cleanup-mailer 	Re: issue EXIT-EXTENT
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 31 Oct 88  18:43:27 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 31 OCT 88 12:25:55 PST
Date: 31 Oct 88 12:25 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue EXIT-EXTENT
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
 Thu, 13 Oct 88 14:52:42 MDT
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881031-122555-6154@Xerox>

I think it is unfortunately the case that my original estimate

 "I think it is unlikely that the cleanup committee will
have much more to say on the issue." 

is unfortunately untrue.

I'll try to answer your questions, and hope that I can get a 
volunteer other than myself to produce a new writeup.

(1) What does "extent of an exit" mean?

An "exit" is something you can RETURN from, or that GO implicitly can
return from, or that THROW will return from. So its either a BLOCK body, a
top level form of a TAGBODY, or a CATCH.  CLtL makes it clear that "exit"s
have dynamic extent. For example, attempting to funcall the value of 

 (block frob #'(lambda () (return-from frob 3)) ) )

is an error, in that the "extent" the block  to which the return-from
returns from has elapsed since the block has been exited. On the other
hand,

(block frob (let ((a #'(lambda () (return-from frob 3)))) (funcall a )))

is not an error; the extent of the frob block has not elapsed when the
return-from is invoked.

The ambiguity only arised because of unwind-protect. (I can't think of any
other situations, although the condition proposal might introduce some
unwind-protect equivalents.)

While "exits" have dynamic extent,  the exact boundary of when that dynamic
extent ends is fuzzy, primarily because of UNWIND-PROTECT.

Given a block (block frob ...) which contains a (return-from frob ...) in
it, we normally think of (return-from frob ...) as a "instantaneous"
operation. However, if there's an UNWIND-PROTECT in between, user code an
execute between the "start" of (RETURN-FROM FROB ...) and when the (BLOCK
FROB ...) is actually exited. Is the extent of (BLOCK FROB ...) over when
(RETURN-FROM FROB ...) starts, or is it over when it ends? 

If the extent is over only when the block is exited, then the following
cases would *not* be an error:

(block nil                                              ;case 2
  (unwind-protect (return)
    (return)))

(block a                                                ;case 3
  (block b
    (unwind-protect (return-from a)
      (return-from b))))


(catch nil                                              ;case 2
  (unwind-protect (throw nil t)
    (throw nil t)))

(catch 'a                                               ;case 3
  (catch 'b
    (unwind-protect (throw 'a t)
      (throw 'b t))))



∂31-Oct-88  1842	CL-Cleanup-mailer 	Re: Issue: DEFPACKAGE (version 6)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 31 Oct 88  18:42:38 PST
Received: from Semillon.ms by ArpaGateway.ms ; 31 OCT 88 10:38:01 PST
Date: 31 Oct 88 10:37 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DEFPACKAGE (version 6)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Sat, 29 Oct 88
 00:14:00 PDT
To: CL-Cleanup@Sail.stanford.edu
Message-ID: <881031-103801-5947@Xerox>

Arguments of the form "we should leave A undefined because B is undefined"
are weak, especially if there is some hope of defining B.

However, I don't think we will make much progress on DEFPACKAGE unless we
leave, for now, that the results of executing more than one DEFPACKAGE on
the same string is unspecified. We might want to add to the commentary that
we expect some implementations may signal a continuable error, but other
environment-specific action might also be reasonable.


Now that we have the new error terminology, I think encoruaging the
signalling of an error might be a reasonable resolution if we expect
legitimate programs to actually catch the error and process it. One
criteria by which we should judge that might be how far we are willing to
specify the exact nature of the condition to be signalled.

In this case, we're not close to a good design that is agreeable.

Could we get a new writeup with the "redefinition" behavior explicitly
vague?

∂31-Oct-88  1843	CL-Cleanup-mailer 	Re: issue DOTTED-MACRO-FORMS   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 31 Oct 88  18:42:55 PST
Received: from Semillon.ms by ArpaGateway.ms ; 31 OCT 88 11:24:14 PST
Date: 31 Oct 88 11:22 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue DOTTED-MACRO-FORMS
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
 Thu, 13 Oct 88 14:41:31 MDT
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881031-112414-6056@Xerox>

I think we decided in the cleanup meeting to explicitly allow dotted lists
in macro calls; self-consistency of macros and macro expansions seemed more
important than consistency of macro expansion with function call.

Kent is supposed to produce a new draft of this issue....

∂31-Oct-88  1843	CL-Cleanup-mailer 	Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 31 Oct 88  18:42:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 31 OCT 88 11:01:58 PST
Date: 31 Oct 88 11:01 PST
From: masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 4)
TO: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: NO
Message-ID: <881031-110158-6025@Xerox>

I'm not satisfied with this as a legitimate use of the new
error terminology. Perhaps the error-signalling constraint
should be relaxed; we make no such requirement for
(DEFUN FOO (X X X) ...) as to when the error of duplicate
variable names should be signaled.

!
Issue:          DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
References:     CLtL p.308 & 86-003 p.4
Category:       CLARIFICATION

Edit history:   Version 1 by Skona Brittain 05/13/88
                Version 2 by Larry Masinter 14-Sep-88
		Version 3 by Larry Masinter 23-Sep-88
		Version 4 by Larry Masinter 31-Oct-88

Problem Description:

The case of two slots of a structure having the same name is not 
discussed in CLtL. Is it allowed?

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

Test Cases:

(defstruct struc slot slot) would be an error.  So would
(defstruct (struc2 (:include struc1)) slot) if preceded by
(defstruct struc1 slot).

Rationale:

Since it would be difficult to prescribe reasonable behavior for
this situation, it should be considered an error.

Current Practice:

In KCL, if 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.

∂31-Oct-88  1843	CL-Cleanup-mailer 	Re: logical pathnames
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 31 Oct 88  18:43:43 PST
Received: from Semillon.ms by ArpaGateway.ms ; 31 OCT 88 14:41:54 PST
Date: 31 Oct 88 14:41 PST
From: masinter.pa@Xerox.COM
Subject: Re: logical pathnames
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Wed, 26 Oct 88 23:17 EDT
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Eric Benson <eb@lucid.com>, KMP@STONY-BROOK.SCRC.Symbolics.COM,
 CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881031-144154-6391@Xerox>

I think we need a set of coherent "pathname" proposals. They probably need
to be examined in toto. The combiniation of -CANONICAL-TYPE,
-COMPONENT-CASE, and a few others bother me because they don't necessarily
"hang together". 

It would be very useful to have a writeup of "current practice" in this
area. In the Common Lisp documentation I have (which includes recent
documententation for Envos Medley, Procyon, Franx EXCL, and Vax Lisp, but
no others) this information is sketchy. At least the Franx EXCL
documentation describes how various Unix pathnames are parsed by
PARSE-NAMESTRING. Since I don't have the symbolics documentation handy its
a little harder to figure out what Genera Logical Pathnames might do.

EB: can you be convinced to put together a proposal?




∂31-Oct-88  1843	CL-Cleanup-mailer 	Issue: EXPT-RATIO (Version 3)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 31 Oct 88  18:43:39 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 31 OCT 88 12:30:30 PST
Date: 31 Oct 88 12:30 PST
From: masinter.pa@Xerox.COM
Subject: Issue: EXPT-RATIO (Version 3)
to: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881031-123030-6167@Xerox>

Fix only to SQRT example.

!
Issue:         EXPT-RATIO

References:    CLtL pages 204 and 211

Category:      CLARIFICATION

Edit history:  Version 1, 4-Oct-88, by Aspinall and Moon
               Version 2,  6-Oct-88, Masinter (very minor discussion)
               Version 3, 31-Oct-88, Masinter (fix typo)

Problem description:

  The comment (page 204, 2nd para) that "... an implementation [of expt]
  might choose to compute (expt x 3/2) as if it had been written
  (sqrt (expt x 3))" disagrees with the principal value definition on
  page 211.  See the example below for a case where the two disagree.  We
  believe the principal value definitions are consistent and reasonable,
  therefore the implementation comment is wrong.

Proposal (EXPT-RATIO:211):

  Clarify that (sqrt (expt x 3)) is not equivalent to (expt x 3/2)
  and that page 211 rules.

Test Cases/Examples:

  (defvar x (exp (/ (* 2 pi #c(0 1)) 3)))         ;exp(2.pi.i/3)
  (expt x 3) => 1 (except for round-off error)
  (sqrt (expt x 3)) => 1 (except for round-off error)
  (expt x 3/2) => -1 (except for round-off error)
  
  There can be no question that 
          (expt x 3) ==> 1
  because expt is single-valued with an integer second argument, and
          (sqrt 1) ==> 1
  definitely follows the principal branch of the square root function.
  
  But (expt x 3/2) is defined as (exp (* (log x) 3/2)) (page 211).
          (log x) ==> 2.pi.i/3
  according to the definition of the logarithm's branch cuts on page 211
  (which really comes down to the branch cuts of phase - page 210), so
          (* (log x) 3/2) ==> pi.i
  and
          exp(pi.i) is -1.

Rationale:

  We believe the principal value definitions are consistent and
  reasonable, therefore the implementation comment is wrong.

Current practice:

  Symbolics Genera 7.3 currently returns the wrong answer, following page
  204 rather than page 211.  Lucid Common Lisp, and 
  Envos Medley implement the proposal.

Cost to Implementors:

  The obvious code changes in complex expt.

Cost to Users:

  None.

Cost of non-adoption:

  Self-contradictory language specification.

Benefits:

  Users can better predict the branch cuts in expt.

Discussion:

  Mathematical Explanation:  When the expt function returns a complex result
  in CL (Cartesian) form, the phase of the complex number is effectively
  canonicalized.  Information is lost, and that information is necessary to
  specify upon which branch of the sqrt function the final result should lie.
  
  Another way to put it would be that although
          sqrt(expt(x,3)) = expt(x,3/2)
  where expt and sqrt are the mathematical multi-valued functions, it is not
  true that:
          pvsqrt(pvexpt(x,3)) = pvexpt(x,3/2)
  where pvexpt and pvsqrt denote the principal value versions of those functions.

∂31-Oct-88  1844	CL-Cleanup-mailer 	Issue: FILE-WRITE-DATE-IF-NOT-EXISTS (no writeup)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 31 Oct 88  18:43:48 PST
Received: from Semillon.ms by ArpaGateway.ms ; 31 OCT 88 14:43:10 PST
Date: 31 Oct 88 14:43 PST
From: masinter.pa@Xerox.COM
Subject: Issue: FILE-WRITE-DATE-IF-NOT-EXISTS (no writeup)
To: cl-cleanup@sail.stanford.edu
Message-ID: <881031-144310-6392@Xerox>

I had this (and others) message filed under that issue name. The
disposition was "wait until there is an signal proposal." Now that there is
a signal proposal, I am pretty sure that it doesn't address this issue. 

I'd like a volunteer to write this up as an issue. (Is DLW a candidate?)

There is additional discussion on this topic, that I will forward. 


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

Date: Mon, 15 Dec 86 07:54 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: FILE-WRITE-DATE, FILE-AUTHOR
To: common-lisp@SU-AI.ARPA
cc: toto@YUKON.SCRC.Symbolics.COM, cal@THINK.COM
Message-ID: <861215075436.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

FILE-WRITE-DATE and FILE-AUTHOR are both vague on what
happens if the file does not exist.  The text says:

    @I[file] can be a filename or a stream that is open to a file.
    This returns the time at which the file was created or last
    written as an integer in universal time format (see section 25.4.1),
    or NIL if this cannot be determined.

(FILE-AUTHOR is similar).

My reading of this is that the phrase "if this cannot be determined"
means "determined by looking at the file", not "determined for any
reason".  I think the intent here is to cover such situations as
an operating system which doesn't support creation dates, or a
network link which doesn't support inquiring about dates.

Situations like giving the wrong pathname, temporary network failure,
or no access rights should signal an error.

PROBE-FILE and DIRECTORY are also a bit vague on these matters, saying
nothing about what happens when you can't inquire about files due to
network failure or no access rights.

I also think that if the directory doesn't exist, you should get an
error, not just return NIL, but this would need to wait until we have an
error system, or the incompatibility would be too large.

USER-HOMEDIR-PATHNAME says "if it is impossible to determine this
information, then NIL is returned instead of a pathname;".  It's
not clear whether this means "is impossible right now due to a
system error" or "is impossible to inquire of that host".  Returning
NIL due to a transient condition is both uninformative to the user
and may lead to suprising behaviour, like reading in the wrong files
or refusing to do something.

The :IF-DOES-NOT-EXIST NIL option to OPEN does not say what it
does about things like network errors, etc.

A lot of people seem to assume that if CLtL doesn't say anything
about errors, then a function may not signal any errors, even if
something goes wrong.  Hopefully the new error system standard will
address a lot of these issues, but some clarification (or at least
agreement on the intent) would help now.


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

Date: Tue, 26 May 87 14:40 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: file-write-date for non-existant files
To: kmp@ALDERAAN.SCRC.Symbolics.COM, Masinter.PA
cc: dlw@ALDERAAN.SCRC.Symbolics.COM, moon@ALDERAAN.SCRC.Symbolics.COM


Recently I tried porting a CL program from the Prime to the Symbolics
implementation.  I found that the program depended on the function
file-write-date, when given a non-existant file, to return NIL rather
than signalling an error.  CLtL, with its usual nonspecificity, says
that file-write-date should return NIL if the write date "cannot be
determined".  I feel this is not completely clear; does this mean "if
the file system doesn't keep track of write dates for files", or does it
mean "if anything goes wrong whatsoever, including 'the network is down
right now' or 'attempts to compute this file write date happen to
stimulate a bug in multiply'"?

I was wondering if there are any pending cleanup proposals that bear
on this question.  If not, I'd be interested in submitting one.  Thanks.

∂31-Oct-88  1844	CL-Cleanup-mailer 	Re: Issue: FILE-WRITE-DATE-IF-NOT-EXISTS (no proposal)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 31 Oct 88  18:44:19 PST
Received: from Semillon.ms by ArpaGateway.ms ; 31 OCT 88 14:59:52 PST
Date: 31 Oct 88 14:59 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: FILE-WRITE-DATE-IF-NOT-EXISTS (no proposal)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Thu, 13 Oct 88 16:53 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881031-145952-6430@Xerox>

Sorry, I misfiled this response. I guess this might yet be handled by a
cleanup, if only to set a precedent.


∂31-Oct-88  1844	CL-Cleanup-mailer 	Re: issue EXIT-EXTENT
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 31 Oct 88  18:44:01 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 31 OCT 88 14:47:39 PST
Date: 31 Oct 88 14:47 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue EXIT-EXTENT
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
 Mon, 31 Oct 88 14:58:26 MST
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
cc: masinter.pa@Xerox.COM, sandra%defun@cs.ARPA (Sandra J Loosemore),
 cl-cleanup@sail.stanford.edu
Message-ID: <881031-144739-6405@Xerox>

The proposal would separate the extent of the visibility of the CATCH tag
from the actual extent of the exit. The CATCH tag would still be visible to
the THROW inside the UNWIND-PROTECT cleanup clause, it would merely be an
"error" to execute that THROW. This is similar to the situation with BLOCK
tags, where

(FUNCALL (BLOCK FOO #'(LAMBDA () (RETURN-FROM FOO 3))))

is an error because, while the scope FOO in the RETURN-FROM allows the FOO
returned from to name the one in the BLOCK, the extent has ended.


∂31-Oct-88  1844	CL-Cleanup-mailer 	Re: Issue FIXNUM-NON-PORTABLE (Version 3)     
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 31 Oct 88  18:44:10 PST
Received: from Semillon.ms by ArpaGateway.ms ; 31 OCT 88 14:56:00 PST
Date: 31 Oct 88 14:55 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue FIXNUM-NON-PORTABLE (Version 3) 
In-reply-to: Barry Margolin <barmar@Think.COM>'s message of Fri, 7 Oct 88
 10:40 EDT
To: Barry Margolin <barmar@Think.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881031-145600-6418@Xerox>

The major reason for considering the removal of BIGNUM from the language
was that it didn't correspond to current practice in several
implementations; although all implementations had a single type which could
fit into the current and proposed definition of FIXNUM, many did not have a
single type that fit into BIGNUM. 

This is at least what led us to consider removing BIGNUM. 

We could not find programs that used the name BIGNUM.

I'm willing to split the issue into two parts, one of which says: constrain
FIXNUM and remove BIGNUM, and the other is to constrain FIXNUM and define
BIGNUM to be exactly (AND INTEGER (NOT FIXNUM)).
In the SUBTYPEP-TOO-VAGUE issue, we should probably make sure the
requirements for FIXNUM and BIGNUM are there.


∂01-Nov-88  0657	CL-Cleanup-mailer 	Re: Issue FIXNUM-NON-PORTABLE (Version 3)     
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 1 Nov 88  06:57:06 PST
Received:  by multimax.ARPA (5.51/25-eef)
	id AA26377; Tue, 1 Nov 88 09:56:09 EST
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA29852; Tue, 1 Nov 88 10:00:04 EST
Message-Id: <8811011500.AA29852@mist.UUCP>
To: masinter.pa%Xerox.COM@Multimax
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue FIXNUM-NON-PORTABLE (Version 3) 
In-Reply-To: Your message of 31 Oct 88 14:55:00 -0800.
             <881031-145600-6418@Xerox> 
Date: Tue, 01 Nov 88 09:59:55 EST
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    I'm willing to split the issue into two parts, one of which says: constrain
    FIXNUM and remove BIGNUM, and the other is to constrain FIXNUM and define
    BIGNUM to be exactly (AND INTEGER (NOT FIXNUM)).
    In the SUBTYPEP-TOO-VAGUE issue, we should probably make sure the
    requirements for FIXNUM and BIGNUM are there.
    
Here's why I don't like the second proposal:

Consider an implmentation with three numeric representations:

Fast                (INTEGER -1024 1023)
Immediate           29 bits
Extended            Multi-precision

(I understand from the discussion that similar implementations exist.)

Then, with the second proposal:

FIXNUM is Immediate
BIGNUM is (OR Fast Extended) because Fast can't be a FIXNUM.


∂01-Nov-88  1005	CL-Cleanup-mailer 	Re: Issue FIXNUM-NON-PORTABLE (Version 3)     
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Nov 88  10:05:41 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 01 NOV 88 10:01:13 PST
Date: 1 Nov 88 09:59 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue FIXNUM-NON-PORTABLE (Version 3) 
In-reply-to: Dan L. Pierson <pierson%mist@MULTIMAX.ENCORE.COM>'s message of
 Tue, 01 Nov 88 09:59:55 EST
To: Dan L. Pierson <pierson%mist@MULTIMAX.ENCORE.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881101-100113-8002@Xerox>

No, this can't be true. In such an implementation, 

Fast                (INTEGER -1024 1023)
Immediate           29 bits
Extended            Multi-precision

FIXNUM is (OR Fast Immediate)
and
BIGNUM is Extended


∂01-Nov-88  2331	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Nov 88  23:31:33 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00254g; Tue, 1 Nov 88 23:29:45 PST
Received: by bhopal id AA11190g; Tue, 1 Nov 88 23:28:11 PST
Date: Tue, 1 Nov 88 23:28:11 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811020728.AA11190@bhopal>
To: Gray@DSG.csc.ti.com
Cc: sandra%defun@cs.utah.edu, pierson%mist@MULTIMAX.ENCORE.COM,
        CL-Cleanup@SAIL.Stanford.edu
In-Reply-To: David N Gray's message of Fri, 28 Oct 88  10:53:24 CDT <2803046004-4897841@Kelvin>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)

re: >   ... Since the force of this proposal is to 
    > retract any _standard_ way to hook REQUIRE into LOAD/DEFSYSTEM, then it 
    > would still be OK for an implementation to extend REQUIRE in an 
    > essentially upwards compatible way. 
    . . . 
    According to the new error terminology, this seems to rule out any
    possibility of an implementation extension.  An "implementation may be
    extended" clause would need to be added if the intent is to permit
    extensions.

Read on!

re: My point is that the behavior for the one-argument case that was required
    by CLtL is now forbidden, and without an adequate reason.

But the two-argument case is the one in which I suggested that an
implementation can extend in an "upward-compatible" way.  That is,
the vendor's extension is upward-compatible with the portable definition
providing he achieves the "old" behaviour by doing (REQUIRE <file> NIL).


re: If REQUIRE cannot ever automatically cause the module to be loaded, then I
    think it is worthless.   

The problem is that the specification of how to do this can only be an
implementation-dependent extension.  Unless someone solves the
universal file name problem.   But removing them totally from the
language is much worse since that even breaks the code of those who
use PROVIDE/REQUIRE as a standardized "handshaking" signal (i.e.
without the interdependence to defsystem).



-- JonL --

∂01-Nov-88  2348	CL-Cleanup-mailer 	Issue: CONSTANT-SIDE-EFFECTS (no proposal)    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Nov 88  23:48:02 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00274g; Tue, 1 Nov 88 23:46:33 PST
Received: by bhopal id AA11234g; Tue, 1 Nov 88 23:45:07 PST
Date: Tue, 1 Nov 88 23:45:07 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811020745.AA11234@bhopal>
To: Gray@DSG.csc.ti.com
Cc: masinter.pa@XEROX.COM, KMP@SCRC-STONY-BROOK.ARPA,
        CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: David N Gray's message of Fri, 28 Oct 88  11:46:10 CDT <2803049170-5088086@Kelvin>
Subject: Issue: CONSTANT-SIDE-EFFECTS (no proposal)

re: it is common practice to do things like

      (DEFVAR *X* '(A B C))
      (SETF (SECOND *X*) 'Z)

    Perhaps it would be better to say (DEFVAR *X* (COPY-LIST '(A B C))) but
    requiring that would invalidate a lot of existing code.  I don't think
    that this inconsistency is really a problem . . . 

How about:

      (DEFCONSTANT X '(A B C))
      (SETF (SECOND X) 'Z)

Is this inconsistency not really a problem either??


re: . . . Note that the
    object file loader knows that a value is only used as a constant before it
    creates it, so it can create it in the proper memory area, but READ does
    not have any such context information, so write-protecting constants in
    the interpreter or in-memory compilation means copying them.

Many people assume that the definition of QUOTE in (QUOTE <x>) must be simply 
to return the program fragment <x> exactly as read in by the reader.  I have 
an interpreter design in mind that does something else -- namely it "caches" 
an equivalent copy of <x>.  Except for symbols (and packages, and classes) 
the results of QUOTE would never be simply the s-expression that was read-in.
At least you only need one copy in the constant area (where equivalence
of copies is something more featureful than EQUAL).


-- JonL --

∂02-Nov-88  1057	CL-Cleanup-mailer 	Re: logical pathnames
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Nov 88  10:57:27 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 486049; Wed 2-Nov-88 13:32:25 EST
Date: Wed, 2 Nov 88 13:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: logical pathnames
To: masinter.pa@XEROX.COM
cc: Eric Benson <eb@lucid.com>, KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881031-144154-6391@Xerox>
Message-ID: <19881102183220.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 31 Oct 88 14:41 PST
    From: masinter.pa@Xerox.COM

    I think we need a set of coherent "pathname" proposals. They probably need
    to be examined in toto. The combiniation of -CANONICAL-TYPE,
    -COMPONENT-CASE, and a few others bother me because they don't necessarily
    "hang together". 

    It would be very useful to have a writeup of "current practice" in this
    area. In the Common Lisp documentation I have (which includes recent
    documententation for Envos Medley, Procyon, Franx EXCL, and Vax Lisp, but
    no others) this information is sketchy. At least the Franx EXCL
    documentation describes how various Unix pathnames are parsed by
    PARSE-NAMESTRING. Since I don't have the symbolics documentation handy its
    a little harder to figure out what Genera Logical Pathnames might do.

Larry, I mailed you the relevant Symbolics book today.

    EB: can you be convinced to put together a proposal?

I assume you can pass it along to Eric if you think he should have it
instead of you, since you're in adjoining towns.

∂02-Nov-88  1612	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 2 Nov 88  16:11:32 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00923g; Wed, 2 Nov 88 16:09:56 PST
Received: by bhopal id AA17334g; Wed, 2 Nov 88 16:08:31 PST
Date: Wed, 2 Nov 88 16:08:31 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811030008.AA17334@bhopal>
To: Gray@DSG.csc.ti.com
Cc: pierson%mist@MULTIMAX.ENCORE.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: David N Gray's message of Wed, 2 Nov 88  15:17:04 CST <2803497424-11026245@Kelvin>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)

re: [implementationd-dependent extension] ...
    Similarly, (REQUIRE "FOO") should be defined as a standard way
    to invoke whatever module loading feature the implementation provides.
    You don't have to standardize how it is done in order to standardize how
    to ask it to be done.

Hey, I'll buy that.  This permits backwards compatibility for those
implementations that hook REQUIRE into their vendor-specific defsystem,
while at the same time permits those that don't have it to get the
"safety-net" feature.  I.e., the "hook" is merely a cerror call.
This still isn't going back on any part of the proposal that flushes
the second argument.  

Dan: would it be acceptable to you to alter the proposal and say that 
the action when the module isn't present is extendible by invoking any
implementation-specific "hooks"?

I still think (version 3) is an acceptable proposal -- especially after 
being emmended as above -- without superseding it with (version 4).  It 
is the least disturbance to the status quo that retracts the non-portability
parts.  Since there are many user's that do use the "safety-net" --
and do so in a portable way, I can't see flushing it simply in order to
continue the non-portable, non-standard usages.  I liked Larry's rationale
for it:

    Date: 18 Oct 88 14:13 PDT
    From: masinter.pa@Xerox.COM
    Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
    In-Reply-To: Dan L. Pierson <pierson%mist@MULTIMAX.ENCORE.COM>'s message of
     Tue, 18 Oct 88 15:27:25 EDT

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

∂03-Nov-88  1236	CL-Cleanup-mailer 	Issue: ALIST-NIL (Version 4)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Nov 88  12:36:19 PST
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA01447g; Thu, 3 Nov 88 12:35:27 PST
Received: by bhopal id AA20333g; Thu, 3 Nov 88 12:33:59 PST
Date: Thu, 3 Nov 88 12:33:59 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811032033.AA20333@bhopal>
To: masinter.pa@Xerox.COM
Cc: CL-Cleanup@Sail.Stanford.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 26 Oct 88 16:20 PDT <881026-162159-14192@Xerox>
Subject: Issue: ALIST-NIL (Version 4)

re: One possibility we discussed was to document that an "alist" is in fact a
    list of pairs, but to document that the functions ASSOC, RASSOC, ASSOC-IF,
    ASSOC-IF-NOT RASSOC-IF and RASSOC-IF-NOT will accept not only an alist but
    any list whose elements are either pairs or NIL, and that NIL elements are
    ignored. This means that the concept of "alist" is kept to the traditional
    interpretation, but that the behavior of some of the functions are
    extended.

I rather like this "way out" of the problem.

-- JonL --

∂03-Nov-88  1333	CL-Cleanup-mailer 	Issue: SUBTYPEP-TOO-VAGUE (Version 4)    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Nov 88  13:33:31 PST
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA01552g; Thu, 3 Nov 88 13:32:39 PST
Received: by bhopal id AA20559g; Thu, 3 Nov 88 13:31:15 PST
Date: Thu, 3 Nov 88 13:31:15 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811032131.AA20559@bhopal>
To: cl-cleanup@sail.stanford.edu
Cc: eb@lucid.com, jlm@lucid.com, jeb@lucid.com, fy@lucid.com
In-Reply-To: KMP's message of  Thu, 13 Oct 88 19:28 EDT
Subject: Issue: SUBTYPEP-TOO-VAGUE (Version 4)

Kent's notes summarizing the discussion at Fairfax were:

    X3J13 meeting:

     JonL: Thinks EB can prove that only SATISFIES mucks things up and
	   that OR, AND, etc. are safe.

     RWK: It couldn't be. You'd need more type cleanups before it could be.

     People generally doubted JonL's claim but said he was of course welcome
     to submit the proof.

Eric (EB) had intended to submit the "proof", but didn't send it out
before leaving for vacation.  In recent discussion here at Lucid, he,
Jim MacDonald, Jim Boyce, Frank Yellin and I were convinced of the "proof".

Before hinting at how the "proof" goes, I'll remark that RWK's claim is 
only partly true -- in the current state, an algorithm can easily be devised
for each implementation, once it is determined how that implementation
treats the disjointness of the primitive types on CLtL pp.33-35., and how 
it determines whether or not something is a defstruct name.  But in fact a
portable algorithm can be adduced if we added STRUCTURE-TYPE-P to the
language and if we required every implementation to follow a reasonable 
set of disjointness constraints. [It might also be necessary to add
UPGRADED-{ARRAY-ELEMENT,COMPLEX-PART}-TYPE.]

The "thumbnail" sketch of the proof goes like this.  First, completely
exclude SATISFIES; also, temporarily ignore type compositions using
AND, OR, and NOT.  Then, there is only a finite number of basic primitive 
types (CLtL, p.43); and there are only a few very simple rules for 
constructing more primitive types from them -- namely, numeric subranges,
array "specializations", and defstructs without the :type option.  Now,
considering the truly primitive types as "literals" in a propositional 
calculus language with AND/OR/NOT, one can produce a disjunctive normal 
form; thus type-equivalence and subtypeing are completely determined.  It 
doesn't matter that there is a infinite pool of "literals" -- in any given 
subtypep query, there will only be finitely many present; exactly the same 
situation is covered in college-level logic courses that talk about the 
decidibility of the propositional calculus.

Of course, an efficient implementation wouldn't follow such a "blind"
course, which might be NP-complete; one could do a lot better in the 
average cases.

Additionally, by my own previously set rules for such proposals, it would 
seem that Lucid (or somebody else) ought to go ahead and do the full 
non-satisfies SUBTYPEP first, before trying to impress it into the standard.


-- JonL --


∂03-Nov-88  1508	CL-Cleanup-mailer 	Re: Issue: SUBTYPEP-TOO-VAGUE (Version 4)     
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 3 Nov 88  15:08:09 PST
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU;  3 Nov 88 18:04:12 EST
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: SUBTYPEP-TOO-VAGUE (Version 4) 
In-reply-to: Your message of Thu, 03 Nov 88 13:31:15 -0800.
             <8811032131.AA20559@bhopal> 
Date: Thu, 03 Nov 88 18:03:00 EST
From: Scott.Fahlman@B.GP.CS.CMU.EDU


    Additionally, by my own previously set rules for such proposals, it would 
    seem that Lucid (or somebody else) ought to go ahead and do the full 
    non-satisfies SUBTYPEP first, before trying to impress it into the standard.
    
Not only "do", but make available as public-domain code.

-- Scott

∂03-Nov-88  2021	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 7)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Nov 88  20:21:32 PST
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA01943g; Thu, 3 Nov 88 20:20:37 PST
Received: by bhopal id AA21511g; Thu, 3 Nov 88 20:19:13 PST
Date: Thu, 3 Nov 88 20:19:13 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811040419.AA21511@bhopal>
To: CL-Cleanup@SAIL.Stanford.edu
Subject: Issue: DEFPACKAGE (version 7)

Here's a "cleanup" of the cleanup, incorporating nits etc from
    sandra%defun@cs.utah.edu on Date: Thu, 13 Oct 88 14:34:04 MDT
    peck@Sun.COM on Mon, 17 Oct 88 17:19:14 -0700
    Moon@STONY-BROOK.SCRC.Symbolics.COM on Wed, 26 Oct 88 22:58 EDT
    masinter.pa@Xerox.COM on 31 Oct 88 10:37 PST
as well as some further discussion and re-wordings by me.  In particular,
the discussion contains a new suggestion to replace the mnemonic of the 
"7 Extremely Randoms".

-- JonL --

!

Issue:         DEFPACKAGE

References:    CLtL section 11.7.
               Issue: IN-PACKAGE-FUNCTIONALITY
               Issue: MAKE-PACKAGE-USE-DEFAULT
               Issue: PACKAGE-DELETION

Category:      ADDITION

Edit history:  Version 1, 12-Mar-88, Moon
               Version 2, 23-Mar-88, Moon, changes based on discussion
               Version 3, 27-Sep-88, JonL 
                (remove :import, :shadowing-import; allow :export to work on
                 imported and inherited; update references to in-package, etc.)
               Version 4,  1-Oct-88, Masinter
               Version 5, 6-Oct-88, Moon
               Version 6, 6-Oct-88, JonL (little nits)
               Version 7, 2-Nov-88, JonL 
		 (incorporate further discussion; simplify handling of
		  syntactic errors; specify ordering constraints).

Problem description:

Many users incorrectly think that package operations can be performed
in any order.  CLtL (p.192) contributes to this misconception.
Programmers need direction on the ordering constraint, especially for
creating packages, since doing things out of order can lead to
confusing or even intractable problems.

If the definition of a package is scattered throughout a program as a 
number of individual forms, it is very easy to read a symbol before the 
package setup needed to read that symbol correctly has been accomplished. 
Three examples: an inherited symbol that should have been shadowed might 
be accessed; a single-colon prefix might be used for a symbol that hasn't
yet been exported; an internal symbol might be created afresh where a 
symbol that will later be imported or inherited was intended.  These 
problems can be difficult to understand or even to recognize; in some 
cases it is difficult or impossible to correct the situation in the
same Lisp image.


Proposal (DEFPACKAGE:ADDITION):
      
Add a DEFPACKAGE macro to the language.  In the description below,
'package-name' and 'symbol-name' can be a symbol or a string; if a 
symbol, only its name matters, not what package it is in.

The syntax of DEFPACKAGE is

  (DEFPACKAGE package-name {option}*)

where each option is a list of a keyword and arguments.  Nothing in a
DEFPACKAGE form is evaluated.

Standard options for DEFPACKAGE are listed below.   Except for :SIZE, 
options may appear more than once (this is useful primarily for 
:IMPORT-FROM and :SHADOWING-IMPORT-FROM).

(:NICKNAMES {package-name}*)
        Set the package's nicknames to the specified names.

(:USE {package-name}*)
        The package is to "use" the other designated packages; that is,
        it will inherit from them.  The default value for this option 
        should be the same as it is for MAKE-PACKAGE (also see the issue
        MAKE-PACKAGE-USE-DEFAULT).

(:SHADOW {symbol-name}*)
        Create the specified symbols in the package being defined, 
        making them shadows, just as the function SHADOW would do.

(:SHADOWING-IMPORT-FROM package-name {symbol-name}*)
        Find the specified symbols in the specified package, import
        them into the package being defined, and place them on the 
        shadowing symbols list.  In no case will symbols be created in 
        any package other than the one being defined; a continuable error 
        is signaled if no symbol is accessible in the package named 
        package-name for one of the symbol-names.

(:IMPORT-FROM package-name {symbol-name}*)
        Find the specified symbols in the specified package and import
        them into the package being defined.  In no case will symbols be 
        created in a package other than the one being defined; a continuable
        error is signaled if no symbol is accessible in the package named 
        package-name for one of the symbol-names.

(:EXPORT {symbol-name}*)
        Find or create symbols with the specified names and export them.
        Note an interaction with the :USE option, since inherited symbols 
        can be used rather than new ones created;  note also an interaction 
        with the :IMPORT-FROM and :SHADOWING-IMPORT-FROM options, since 
	imported symbols can be used rather than new ones created.

(:INTERN {symbol-name}*)
        Find or create symbols with the specified names.  Note an 
        interaction with the :USE option, since inherited symbols 
        can be used rather than new ones created.  This option is useful if 
        an :IMPORT-FROM or a :SHADOWING-IMPORT-FROM option in a subsequent 
        call to DEFPACKAGE (for some other package) expects to find these 
        symbols accessible but not necessarily external.

(:SIZE integer)
        Declare the approximate number of symbols expected in the package.
        This is an efficiency hint only, so that the package's table will
        not have to be frequently re-expanded when new symbols are added
        to it (e.g., by reading in a large file "in" that package).

The order in which the options occur in a DEFPACKAGE form is irrelevant;
but since the effects of the entry-making options are context-sensitive, 
the order in which they will be executed is as follows:
  (1) :SHADOW and :SHADOWING-IMPORT-FROM 
  (2) :USE 
  (3) :IMPORT-FROM and :INTERN
  (4) :EXPORT
Shadows are established first, since they may be necessary to block 
spurious name conflicts when the use link is established.  Use links are 
established next so that :intern and :export may refer to normally 
inherited symbols.  The :export is done last so that it may refer to 
symbols created by any of the other options; in particular, shadows and 
imported symbols can be made external.  Note also the prescription on CLtL 
p.178 to cover the case of calling EXPORT on an inherited symbol.

DEFPACKAGE creates the package as specified and returns it as its value.
It has no other side effects; e.g., it does not alter the value of *PACKAGE*.
The function COMPILE-FILE should treat top-level DEFPACKAGE forms the
same way it treats the other package-effecting functions (see CLtL p.182).

If the specified name already refers to an existing package, then the 
name-to-package mapping for that name is not changed.   At most, the 
existing package will be modified to reflect the new definition;  it is 
undefined what happens if the new definition is at variance with the 
current state of that package.  If one of the specified nicknames already
refers to an existing package, then an error is signaled just the same
as MAKE-PACKAGE would.  See the issue PACKAGE-DELETION for undoing the
name-to-package mapping.

Some DEFPACKAGE errors are, however,  purely syntactic.
  (1) An error should be signaled if :SIZE appears than once.
  (2) Since extended options might be allowed by other implementations, 
      an error should be signaled if an option is present that is not 
      actually supported in this implementation.
  (3) The collection of symbol-name arguments given to the options 
      :SHADOW, :INTERN, :IMPORT-FROM, and :SHADOWING-IMPORT-FROM must 
      all be disjoint; additionally, the symbol-name arguments given to 
      :EXPORT and :INTERN must be disjoint. If either condition is 
      violated, an error should be signaled.
Name conflict errors will, of course, be handled by the underlying calls to 
USE-PACKAGE, IMPORT, and EXPORT.


Examples:

;;; An example that "plays it super-safe" by using only strings as names; 
;;;  does not even assume that the package it is read in to "uses" LISP; 
;;   *never* creates any symbols whatsoever in the package that it is read 
;;     in to.

(LISP:DEFPACKAGE "MY-PACKAGE"
  (:NICKNAMES "MYPKG" "MY-PKG")
  (:USE "LISP")
  (:SHADOW "CAR" "CDR")
  (:SHADOWING-IMPORT-FROM "VENDOR-COMMON-LISP"  "CONS")
  (:IMPORT-FROM           "VENDOR-COMMON-LISP"  "GC")
  (:EXPORT "EQ" "CONS" "FROBOLA")
  )

;;; A similar call, mostly using symbols rather than strings as names.
;;; Expects to be read in to a package that "uses" LISP and *may* create
;;;  random internal symbols in that package (such as MY-PACKAGE etc).

(defpackage my-package
  (:nicknames mypkg :MY-PKG)		;remember CL conventions for case
  (:use lisp)				; conversion on symbols
  (:shadow CAR :cdr #:cons)
  (:export "CONS")			;yes, this is the shadowed one.
  )

Rationale:

The availability of DEFPACKAGE encourages putting the entire package 
definition in a single place.  It also encourages putting all the package 
definitions of a program in a single file, which can be loaded before 
loading or compiling anything else that depends on those packages; such a
file can be read in the USER package, avoiding any initial state issues.

In addition, DEFPACKAGE allows a programming environment to process
the whole package setup as a unit, providing better error-checking and
more assistance with package problems, by dint of global knowledge of
the package setup.

Current practice:

Symbolics Common Lisp (SCL) has always had a DEFPACKAGE, and users
prefer it to individual calls to EXPORT, IMPORT, SHADOW, etc.  The SCL
version of DEFPACKAGE has quite a few additional options, but none of
them appears to be necessary to propose for Common Lisp at this time.
This proposal is incompatible with Symbolics DEFPACKAGE in some ways
that will probably not cause major problems.

Cost to Implementors:

Small--DEFPACKAGE can be implemented simply as a bunch of
calls to existing functions.

Cost to Users:

Small, this is upward compatible.

Cost of non-adoption:

Packages continue to be difficult to use correctly.

Benefits:

Guide users away from using packages in ways that get them into trouble.

Esthetics:

Neutral.

Discussion:

It has been suggested that the "Put IN Seven EXtremely Random USEr
Interface COmmands" mnemonic described in CLtL p.191 could be removed;
and with possibly a few exceptions, the special handling of them by
COMPILE-FILE could be removed.  As this would be an incompatible change, 
it is not part of this proposal.  However, a new mnemonic can be offered, 
to help remember the ordering constraints mentioned above:
          I REmember Six USEr Interface Expressions
Each word in the sentence corresponds to one operation listed below:
   I				IN-PACKAGE	;"foot" to stand on
   REmember			REQUIRE		;ensure pre-requisite packages
   Six				SHADOW		;block multiple-inheritances
   USEr				USE-PACKAGE	;go for it!
   Interface			IMPORT		;bring in "foreign" symbols
   EXpressions			EXPORT		;a "face" to show to others.

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 macroexpansion of DEFPACKAGE could usefully canonicalize the names
into strings, so that even if a source file has random symbols in the
DEFPACKAGE form, the compiled file would only contain strings.

Frequently additional implementation-dependent options take the
form of a keyword standing by itself as an abbreviation for a list
(keyword T); this syntax should be properly reported as an unrecognized
option in implementations that do not support it.

Definition forms in Common Lisp usually just establish a name-to-object
mapping; there is little precedent for them to modify other global-context
state.  For this reason, we didn't want DEFPACKAGE also to "go" into the 
new package.  If it did so, like IN-PACKAGE, then the following reasonable 
file would become confused, because it wouldn't all be in one package:
   (in-package "USER")
   (defpackage "WATER"      (:use "LISP")             (:export "FISH"))
   (defpackage "ALCHEMY"    (:use "LISP" "PHLOGISTON) (:export gold))
Should the token 'gold' be read while in the USER package, or in the
the WATER package?

The issue IN-PACKAGE-FUNCTIONALITY recommends that IN-PACKAGE  be 
incompatibly changed to recognize only existing packages, not to create 
them.  IN-PACKAGE would then not accept any keyword arguments.

The function MAKE-PACKAGE might also be extended to take all the keywords
that DEFPACKAGE does. This could be the subject of a separate cleanup.

∂03-Nov-88  2142	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Nov 88  21:42:26 PST
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA01968g; Thu, 3 Nov 88 21:41:29 PST
Received: by bhopal id AA24037g; Thu, 3 Nov 88 21:40:04 PST
Date: Thu, 3 Nov 88 21:40:04 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811040540.AA24037@bhopal>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)

This version is a substantial re-write, to address issues raised since
the X3J13 meeting in Fairfax, especially in the mail msgs:
  10 Oct Jim McDonald <jlm@lucid.com>
  13 Oct Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> 
  13 Oct sandra%defun@cs.utah.edu (Sandra J Loosemore)

One major change is the re-introduction of "upgrading".  Not only has 
this word crept into most people's vocabulary, but Pedersen has provided 
a sufficient rationale for using it -- it is a movement upward in the
type-hierarchy lattice.  We have found one implementation that does no
upgrading; and we have had to clarify some things about upgrading, to
cover existing practice.  This is reflected in two sub-items in the 
proposal part.  

Although the proposal is a CHANGE, is now consists of seven sub-items:
  One ADDITION
  Two incompatible CHANGES
  Three CLARIFICATIONS
  And "a partridge in a pear tree"
The seventh item is the definition for subtypep on complexes; I'm not
sure whether this is new (because CLtL forgot about it), or a change,
or simply a clarification.  Let's hope it's at least right!


-- JonL --

P.S.  I say "we" above, since many people helped in the production of
      this version.

!

Issue:         ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS

References:    Data types and Type specifiers: CLtL p. 11; Sect. 4.5, p.45
               Functions: TYPEP and SUBTYPEP; CLtL Sect. 6.2.1, p.72
                          ARRAY-ELEMENT-TYPE, CLtL p. 291
               The type-specifiers:
                          ARRAY,  SIMPLE-ARRAY,  VECTOR,  SIMPLE-VECTOR
                          COMPLEX

Related Issues: SUBTYPEP-TOO-VAGUE, LIST-TYPE-SPECIFIER

Category:      CHANGE

Edit history:  Version 1, 13-May-88, JonL
               Version 2, 23-May-88, JonL  
                (typo fixes, comments from moon, rearrange some discussion)
               Version 3, 02-Jun-88, JonL  
                (flush alternate proposal ["flush-upgrading"]; consequently,
                 move more of discussion back to discussion section.
               Version 4, 01-Oct-88, Jan Pedersen & JonL
                (reduce discussion, and "cleanup" wordings)
               (Version 5 edit history missing)
               Version 6, 6-Oct-88, Moon
                (fix typos, cover subtypep explicitly, add complex,
                 change name of UPGRADE-ARRAY-ELEMENT-TYPE)
               Version 7, 7-Oct-88, JonL (more name and wording changes)
               Version 8,  8-Oct-88, Masinter (wording, discussion)
               Version 9, 31-Oct-88, JonL (major re-wording to accommodate
		 recent discussion; esp. re-introduce and clarify "upgrading")


Problem description:

 CLtL occasionally draws a distinction between type-specifiers "for
 declaration" and "for discrimination";  see CLtL, section 4.5 "Type 
 Specifiers That Specialize" (p.45 and following)  The phrase 
 "for declaration"  encompasses type-specifiers passed in as the 
 :element-type argument to  MAKE-ARRAY, passed in as the <result-type> 
 argument to COERCE, and used in THE and DECLARE type declarations.  The 
 phrase "for discrimination" refers to the type-specifiers passed in as 
 the <type> argument(s) to TYPEP and SUBTYPEP.

 One consequence of this distinction is that a variable declared to be of 
 type <certain-type>, and all of whose assigned objects are created in 
 accordance with that type, may still have none of its values ever satisfy 
 the TYPEP predicate with that type-specifier.   One type-specifier with 
 this property is  
         (ARRAY <element-type>) 
 for various implementation dependent values of <element-type>.  For
 example, in most implementations of CL, an array X created with an
 element-type of (SIGNED-BYTE 5) will, depending on the vendor, either
 satisfy
        (TYPEP X '(ARRAY (SIGNED-BYTE 8))), or
        (TYPEP X '(ARRAY T)) 
 but (almost) never will it satisfy 
        (TYPEP X '(ARRAY (SIGNED-BYTE 5))).

 This is entirely permissible within the scope of standardization on
 MAKE-ARRAY, where an implementation is required only to construct up the
 result out of "the most specialized [element] type that can nevertheless
 accommodate elements of the given type [the :element-type argument]"
 (see CLtL, p287).  That is, an implementation may in fact only provide a 
 very small number of equivalence classes of element-types for storing 
 arrays, corresponding to its repertoire of specialized storage techniques;
 and it is explicitly permitted to "upgrade" any element-type request into 
 one of its built-in repertoire (see also  CLtL, p45, second and third
 paragraphs under Section 4.5.)

 As a practical matter, almost every existing implementation does some 
 serious upgrading of the :element-type argument given to MAKE-ARRAY.  
 Yet the difference between "for declaration" and "for discrimination" 
 has been very confusing to many people.  Similarly, portability is
 hindered when users do not know just how a given implementation does 
 upgrading.
 
 The type specifier (COMPLEX <part-type>) also falls in the  domain of CLtL
 Section 4.5.  Currently, only one implementation actually provides any kind 
 of specialized storage for complex parts; and in this case, the practical
 matter is less urgent, since the kind of upgrading happening is so obvious 
 as to cause little or no confusion.


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

 Short Summary:

  ** Eliminate the distinction between type-specifiers "for declaration" and
     "for discrimination".  In short, change the meaning of array and
     complex type specifiers in favor of the "for declaration" meaning.

  ** Change the meaning of TYPEP to be in accord with "for declaration"
     meaning of type-specifiers.

  ** Add an implementation-dependent function that reveals how a given 
     type-specifier for array element-types is upgraded.  Add another such 
     function that reveals how a given type-specifier for complex parts is
     upgraded.

  ** Clarify that "upgrading" implies a movement upwards in the type-
     hierarchy lattice; i.e., if <type> upgrades to <Type>, then
     <Type> must be a super-type of <type>.

  ** Clarify that upgrading an array element-type is independent of any 
     other property of arrays, such as rank, adjustability, fill-pointers, 
     etc.  

  ** Clarify how SUBTYPEP thus behaves on array type-specifiers.  

  ** Define how SUBTYPEP behaves on complex type-specifiers.  

 Note that despite this issue's name, the detailed specifications herein 
 apply to the type system -- not to the behavior of MAKE-ARRAY, nor to how
 arrays are actually implemented.

 Details:

  First, some definitions: Two type-specifiers <type1> and <type2> are said 
  to be "type-equivalent" if and only if each one specifies a subtype of the
  other one.  For example, (UNSIGNED-BYTE 5) and (MOD 32) are two different 
  type- specifiers that always refer to the same sets of things; hence they 
  are type-equivalent.  But (UNSIGNED-BYTE 5) and (SIGNED-BYTE 8) are not 
  type- equivalent since the former refers to a proper subset of the latter.
  Two type-specifiers <type1> and <type2> are said to be "type-disjoint"
  if their specified intersection is null.  For example, INTEGER and FLOAT 
  are type disjoint by definition (see CLtL p.33), and (INTEGER 3 5) and 
  (INTEGER 7 10) are type-disjoint because the specified ranges have no
  elements in common.

 *. Eliminate the distinction between types "for declaration" and "for 
    discrimination".  In particular, elminate any such reference in the 
    discussion of array and complex type-specifiers; this would include 
    documentation patterned after the discussion in section 4.5, pp. 45-7, 
    especially the example on p.46 that says "See ARRAY-ELEMENT-TYPE".
    Change the meaning of (ARRAY <element-type>), as well as any of the
    subtypes of ARRAY (such as SIMPLE-ARRAY, VECTOR, etc.) in favor of the 
    "for declaration" meaning.  Make the similar simplification for the 
    <part-type> specifiers in the COMPLEX type-specifier.

 *. 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.  While
    (ARRAY *) refers to all arrays regardless of element type, (ARRAY <type>)
    refers only to those arrays that can result from giving <type> as the
    :element-type argument to the function MAKE-ARRAY.  Change the meanings
    for (SIMPLE-ARRAY <type>) and (VECTOR <type>) in the same way.

    Change the meaning of (TYPEP <x> '(COMPLEX <type>)) similarly.  Thus,
    (COMPLEX <type>) refers to all complex numbers that can result from 
    giving numbers of type <type> to the function COMPLEX, plus all other 
    complex numbers of the same specialized representation.  Remember that
    both the real and the imaginary parts of any such complex number must 
    satisfy:
                (TYPEP <real-or-imag-part> '<type>). 

 *. Add the function UPGRADED-ARRAY-ELEMENT-TYPE of one argument, which
    returns the element type of the most specialized array representation
    capable of holding items of the given argument type.   Note that except
    for storage allocation consequences, it could be defined as:

      (DEFUN UPGRADED-ARRAY-ELEMENT-TYPE (TYPE)
        (ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE TYPE)))

    Since element-type upgrading is a fundamental operation implicit in 
    almost every existing implementation of MAKE-ARRAY, the purpose of this 
    added function is primarily to reveal how an implementation does its
    upgrading.

    Add the function UPGRADED-COMPLEX-PART-TYPE of one argument that
    returns the part type of the most specialized complex number
    representation that can hold parts of the given argument type.

 *. Clarify that "upgrading" implies a movement upwards in the type-
    hierarchy lattice.  Specifically, the type-specifier <type> must be
    a subtype of (UPGRADED-ARRAY-ELEMENT-TYPE '<type>).  Furthermore, if 
    <type1> is a subtype of <type2>, then:
            (UPGRADED-ARRAY-ELEMENT-TYPE '<type1>)
    must also be a subtype of:
            (UPGRADED-ARRAY-ELEMENT-TYPE '<type2>).  
    Note however, that two type-disjoint types can in fact be upgraded into 
    the same thing.

    Clarify that ARRAY-ELEMENT-TYPE returns the upgraded element type
    for the array; in particular, any documentation patterned after 
    the sentence on p. 291 begining "This set may be larger than the 
    set requested when the array was created; for example . . ." should
    be embellished with this clarification.

    Similarly, the type-specifier <type> must be a subtype of 
    (UPGRADED-COMPLEX-PART-TYPE <type>).

 *. Clarify that upgrading an array element-type is independent of any 
    other property of arrays, such as rank, adjustability, fill-pointers, 
    displacement etc.  For all such properties other than rank this should 
    be obvious (since they are not expressible in the language of 
    type-specifiers); but note that unless it is also independent of rank, 
    it would not be consistently possible to displace arrays to those of 
    differing rank.

 *. Clarify that SUBTYPEP on ARRAY type-specifiers is as follows:  

    For all type-specifiers <type1> and <type2> other than *, require 
    (ARRAY <type1>) and (ARRAY <type2>) to be type-equivalent if and only 
    if they refer to arrays of exactly the same specialized representation; 
    and require them to be type-disjoint if and only if they refer to arrays 
    of different, distinct specialized representations.  This definition
    follows that implicitly prescribed in CLtL.

    As a consequence of the preceding change to TYPEP and of the definition 
    of UPGRADED-ARRAY-ELEMENT-TYPE, the two type specifiers 
                (ARRAY <type1>)  and 
                (ARRAY <type2>)
    are type-equivalent if and only if
                (UPGRADED-ARRAY-ELEMENT-TYPE '<type1>)  and
                (UPGRADED-ARRAY-ELEMENT-TYPE '<type2>) 
    are type-equivalent.  This is another way of saying that `(ARRAY <type>)
    and `(ARRAY ,(UPGRADED-ARRAY-ELEMENT-TYPE '<type>)) refer to the same
    set of specialized array representations.

    This defines the behavior of SUBTYPEP on array type-specifiers; namely:
                (SUBTYPEP '(ARRAY <type1>) '(ARRAY <type2>))
    is true if and only if
                (UPGRADED-ARRAY-ELEMENT-TYPE '<type1>)  and
                (UPGRADED-ARRAY-ELEMENT-TYPE '<type2>)
    are type-equivalent.

 *. Define SUBTYPEP on COMPLEX type-specifiers as follows: 

    For all type-specifiers <type1> and <type2> other than *, 
            (SUBTYPEP '(COMPLEX <type1>) '(COMPLEX <type2>))
    is  T T  if:
      1. <type1> is a subtype of <type2>, or
      2. (UPGRADED-COMPLEX-PART-TYPE '<type1>) is type-equivalent
         to (UPGRADED-COMPLEX-PART-TYPE '<type2>);  in this case,
         (COMPLEX <type1>) and (COMPLEX <type2>) both refer to the 
         same specialized representation.
   The result is  NIL T  otherwise.

 The small differences between the SUBTYPEP specification for ARRAY and 
 for COMPLEX are necessary because there is no creation function for 
 complexes which allows one to specify the resultant part type independently
 of the actual types of the parts.  Thus in the case of COMPLEX, we must 
 refer to the actual type of the parts, although a number can be a member 
 of more than one type; e.g., 17 is of type (MOD 18) as well as of type
 (MOD 256); and 2.3f5 is of type SINGLE-FLOAT was well as FLOAT.
 The form:
     (SUBTYPEP '(COMPLEX SINGLE-FLOAT) '(COMPLEX FLOAT))
 must be true in all implementations; but:
     (SUBTYPEP '(ARRAY SINGLE-FLOAT) '(ARRAY FLOAT))
 is true only in implementations that do not have a specialized array
 representation for single-floats distinct from that for other floats.


Test cases:

 Let <aet-x> and <aet-y> be two distinct type specifiers that are
 definitely not type-equivalent in a given implementation, but for which
 make-array will return an object of the same array type.  This will be
 an implementation dependent search, but in every implementation that
 the proposer has tested, there will be some such types; often,
 (SIGNED-BYTE 5) and (SIGNED-BYTE 8) will work.

 Thus, in each case, both of the following forms return T T:

  (subtypep (array-element-type (make-array 0 :element-type '<aet-x>))
            (array-element-type (make-array 0 :element-type '<aet-y>)))

  (subtypep (array-element-type (make-array 0 :element-type '<aet-y>))
            (array-element-type (make-array 0 :element-type '<aet-x>)))

 To eliminate the distinction between "for declaration" and "for
 discrimination" both of the following should be true:

  [A]
   (typep (make-array 0 :element-type '<aet-x>)
          '(array <aet-x>))
   (typep (make-array 0 :element-type '<aet-y>)
          '(array <aet-y>))

 Since (array <aet-x>) and (array <aet-y>) are different names for
 exactly the same set of objects, these names should be type-equivalent.
 That implies that the following set of tests should also be true:

  [B]
   (subtypep '(array <aet-x>) '(array <aet-y>))
   (subtypep '(array <aet-y>) '(array <aet-x>))

 Additionally, to show that un-equivalent type-specifiers that use the
 same specialized array type should be equivalent as element-type
 specifiers, the following type tests should be true:

  [C]
   (typep (make-array 0 :element-type '<aet-y>)
          '(array <aet-x>))
   (typep (make-array 0 :element-type '<aet-x>)
          '(array <aet-y>))


Rationale:

 This proposal legitimizes current practice, and removes the obscure and
 un-useful distinction between type-specifiers "for declaration" and
 "for discrimination".  The suggested changes to the interpretation of
 array and complex type-specifiers follow from defining type-specifiers
 as names for collections of objects, on TYPEP being a set membership
 test, and SUBTYPEP a subset test on collections of objects.


Current Practice:

 Every vendor's implementation that the proposer has queried has a finite 
 set of specialized array representations, such that two non-equivalent 
 element types can be found that use the same specialized array 
 representation; this includes Lucid, Vaxlisp, Symbolics, TI, Franz,
 and Xerox. Most implementations fail tests [A] and [C] part 1, but pass
 tests [A] and [C] part 2; this is a consequence of implementing the
 distinction between "for declaration" and "for discrimination".  Lucid
 and Xerox both pass test [B], and the other implementations fail it.
 The Explorer returns NIL for all six tests in [A], [B], and [C].

 Allegedly, the PCLS implementation does no "upgrading"; each array
 "remembers" exactly the type-specifier handed to the MAKE-ARRAY call
 that created it.  Thus the test cases are not applicable to PCLS,
 since the precondition cannot be met (i.e., find two non-type-equivalent
 type-specifiers that are non-trivially upgraded by make-array).

 Only the TI Explorer offers any specialized representation for complexes;
 part types of SINGLE-FLOAT and DOUBLE-FLOAT are specialized.


Cost to Implementors:

 This proposal is an incompatible change to the current language
 specification, but only a small amount of work should be required in
 each vendor's implementation of TYPEP and SUBTYPEP.

Cost to Users:

 Because of the prevalence of confusion in this area, it seems unlikely
 that any user code will have to be changed.  In fact, it is more likely
 that some of the vendors will cease to get bug reports about MAKE-ARRAY
 returning a result that isn't of "the obvious type".  Since the change
 is incompatible, some user code might have to be changed.


Cost of non-adoption:

 Continuing confusion in the user community.


Benefits:

 It will greatly reduce confusion in the user community.  The fact that
 (MAKE-ARRAY <n> :ELEMENT-TYPE '<type>) frequently is not of type 
 (ARRAY <type>) has been very confusing to almost everyone.  

 Portability of applications will be increased slightly, since
 the behavior of 
     (TYPEP (MAKE-ARRAY <n> :ELEMENT-TYPE <type>) '(ARRAY <type>))
  will no longer be implementation-dependent. 


Esthetics:

 Reducing the confusing distinction between type-specifiers "for
 declaration" and "for discrimination" is a simplifying step -- it is a
 much simpler rule to state that the type-specifiers actually describe
 the collections of data they purport to name.  Thus this is a step
 towards increased elegance.


Discussion:

 This issue was prompted by a lengthy discussion on the Common Lisp
 mailing list.  See for example a series of exchanges started on Thu, 
 17 Dec 87 10:48:05 PST by Jeff Barnett <jbarnett@nrtc.northrop.com>
 under the subject line of "Types in CL".  See also the exchange started 
 Wed, 6 Jan 88 23:21:16 PST by Jon L White <edsel!jonl@labrea.stanford.edu>
 under the subject line of "TYPEP warp implications"

 Although the types STRING,  BIT-VECTOR,  SIMPLE-STRING, and 
 SIMPLE-BIT-VECTOR are subtypes of the ARRAY type, they are not
 specifically discussed in this proposal.  The reason is that 
 they are not type-specifiers "that specialize", but are merely 
 abbreviations as follows:
   STRING             ==  (VECTOR STRING-CHAR)
   SIMPLE-STRING      ==  (SIMPLE-ARRAY STRING-CHAR (*))
   BIT-VECTOR         ==  (VECTOR BIT)
   SIMPLE-BIT-VECTOR  ==  (SIMPLE-ARRAY BIT (*))
 Thus their semantics could be affected only in an implementation that
 doesn't support a specific "specialized storage" type for arrays of
 bits and vectors of string-chars.  But in fact, every CL implementation 
 must appear to support "specialized storage" for bit-arrays and strings,
 even if it means nothing more than remembering the fact that such an
 array was created with that element-type.  This is required in order
 for strings, bit-vectors,  and bit-arrays to be disjoint datatypes 
 (see CLtL p.34; see also the definitions of BIT-ARRAY and STRING found 
 in CLtL p.293, Section 17.4, and in CLtL p.299.)

 We considered the possibility of flushing the permission to "upgrade";
 for example, it could be made a requirement that:
     (ARRAY-ELEMENT-TYPE (MAKE-ARRAY <n> :ELEMENT-TYPE <type>))
 always be equal to <type> (or, at least type-equivalent to <type>)
 for all valid type specifiers <type>.  This has several problems: it
 increases the storage requirement for many kinds of arrays, and hides
 a relevant part of the underlying implementation for no apparently 
 good reason.  However, it would increase portability, since it would be 
 much more difficult, for example, to write a program that created an
 array with one element-type, say, (UNSIGNED-BYTE 5), but operated on it 
 assuming a non-trivial upgraded element-type, say, (UNSIGNED-BYTE 8).
 Under this proposal, it is valid for an implementation of MAKE-ARRAY 
 to have arrays "remember" the type-equivalence class of the original 
 :element-type argument; such an implementation would satisfy all of 
 the  constraints listed above.

 We considered a suggestion to restrict the set of "known" array element 
 types; this would gain portability at the expense of limiting the 
 language.

 We considered leaving out of the proposal the addition of the two
 functions UPGRADED-ARRAY-ELEMENT-TYPE and UPGRADED-COMPLEX-PART-TYPE.
 But it was noted that every implementation of CL supports exactly
 that functionality somewhere in its implementation of MAKE-ARRAY; and
 exposing this to the user would be a good thing.  Furthermore, the
 existence of at least UPGRADED-ARRAY-ELEMENT-TYPE makes the clarifications
 on "upgrading" and SUBTYPEP implications easier.  Finally, there would
 be no other way at all to pinpoint just how complex parts are upgraded,
 since there is no type information available except for the actual
 types of the parts.

 Since this proposal contains the implication:
     (ARRAY <type1>)  is-type-equivalent-to  (ARRAY <type2>)
     ==> 
      <type1>  is-type-equivalent-to  <type2>
 then the question naturally arises "Does the reverse implication hold?"  
 That is, should two non-EQ but type-equivalent type-specifiers <type1>
 and <type2> always give rise to the same array types?   For example, 
 consider SHORT-FLOAT and SINGLE-FLOAT in an implementation where these 
 are type-equivalent (see CLtL section 2.1.3).  One may desire to implement 
 (ARRAY SHORT-FLOAT) and (ARRAY SINGLE-FLOAT) differently.  Say, for example 
 that the former is packed into 16-bit half-words, whereas the latter is 
 packed into 32-bit words; but for either kind of packing, the result of 
 AREF is an ordinary "single-float".  The whole point of the type-specifier
 to make-array is merely to specify a packing technique for "packed float" 
 arrays.  This "krinkle", however, will not be addressed by the proposal 
 herein; it should simply be remembered that the implication above goes 
 only one way, and is not an "if-and-only-if" link.

∂04-Nov-88  1255	CL-Cleanup-mailer 	New version of proposal format?
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Nov 88  12:55:51 PST
Received: from Semillon.ms by ArpaGateway.ms ; 04 NOV 88 12:41:49 PST
Date: 4 Nov 88 12:41 PST
From: masinter.pa@Xerox.COM
Subject: New version of proposal format?
To: cl-cleanup@sail.stanford.edu
Message-ID: <881104-124149-5137@Xerox>

I remember creating a new version of the proposal format and mailing it
out. However, I can't find it. Did any of you get and save a new version of
the proposal form? Could you mail it back to me?



∂04-Nov-88  1619	CL-Cleanup-mailer 	Issue SPECIAL-TYPE-SHADOWING (V1)   
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.

∂05-Nov-88  1348	CL-Cleanup-mailer 	New version of proposal format?
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 5 Nov 88  13:48:02 PST
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA03008g; Sat, 5 Nov 88 13:47:04 PST
Received: by bhopal id AA03753g; Sat, 5 Nov 88 13:45:41 PST
Date: Sat, 5 Nov 88 13:45:41 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811052145.AA03753@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 4 Nov 88 12:41 PST <881104-124149-5137@Xerox>
Subject: New version of proposal format?

re: I remember creating a new version of the proposal format and mailing it
    out. However, I can't find it. Did any of you get and save a new version of
    the proposal form? Could you mail it back to me?

Here is the one I obtained just before the last X3J13 meeting.

-- JonL --


!

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


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

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

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

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

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

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

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

Problem description:

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

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

Examples:

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

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

Rationale:

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

Current practice:

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

Cost to Implementors:

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

Cost to Users:

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

Cost of non-adoption:

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

Performance impact:

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

Benefits:

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

Esthetics:

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

Discussion:

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


∂07-Nov-88  1547	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COERCE-TIME (Version 2)   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Nov 88  15:42:38 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA00342; Mon, 7 Nov 88 16:40:22 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA03984; Mon, 7 Nov 88 16:40:12 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811072340.AA03984@defun.utah.edu>
Date: Mon, 7 Nov 88 16:40:10 MST
Subject: Re: Issue: FUNCTION-COERCE-TIME (Version 2)
To: masinter.pa@Xerox.COM
Cc: Jon L White <jonl@lucid.com>, sandra%defun@cs (Sandra J, Loosemore),
        KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: masinter.pa@Xerox.COM, 7 Nov 88 15:07 PST

Well, the main reason why I prefer "AMBITIOUS" to "HYBRID" is that it
seems kind of peculiar to make an exception for the two functions,
SET-MACRO-CHARACTER and SET-DISPATCH-MACRO-CHARACTER.  Besides being
different from all the other functions that take functional arguments,
it makes them different from the pathname functions (which always
coerce non-pathname "pathname" arguments to pathnames) and the package
functions (which always coerce non-package "package" arguments to
packages). 

Also, I disagree that there is no performance penalty, although it's
certainly small in comparison to the rest of the reader's processing.
For example, A-Lisp has a fast, opencoded funcall primitive that it
uses when its argument is guaranteed to be a function, which is *much*
faster than a normal funcall (by a factor of at least 20).

I don't feel really strongly about this -- HYBRID is not really all
that objectionable to me, and I would vote for it if AMBITIOUS is
thrown out. 

-Sandra
-------

∂07-Nov-88  1626	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COERCE-TIME (Version 2)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Nov 88  16:26:40 PST
Received: from Semillon.ms by ArpaGateway.ms ; 07 NOV 88 15:07:10 PST
Date: 7 Nov 88 15:07 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-COERCE-TIME (Version 2)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Fri, 21 Oct 88
 20:16:26 PDT
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
 Thu, 13 Oct 88 14:59:41 MDT
To: Jon L White <jonl@lucid.com>, sandra%defun@cs.utah.edu (Sandra J
 Loosemore)
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881107-150710-1136@Xerox>

JonL: Kent still has the hope that he'll be able to reverse the decision in
FUNCTION-TYPE and let lambda lists be standardly coerced to functions by
default. Rather than tie up this proposal with that issue, he resorted to
terminology that would otherwise unnecessarily link the two issues.

I think it is a good idea to make sure the two issues aren't linked. Maybe
all we need to do is to explain in the discussion section the reason why it
was written in this way.

Sandra: Can you explain the reasons why you like "ambitious"? I can't think
of any good reasons for making it the standard; it doesn't improve the
potential performance of applications and it does interfere with the
flexibility of the language; delayed "binding" is a feature we should be
cautious about removing from Lisp.  Similarly, there doesn't seem to be any
good reason for leaving it explicitly vague, does there? Could you explain?

∂07-Nov-88  1627	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 2)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Nov 88  16:26:52 PST
Received: from Semillon.ms by ArpaGateway.ms ; 07 NOV 88 15:13:03 PST
Date: 7 Nov 88 15:13 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-COMPOSITION (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Thu, 13 Oct 88 17:08 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881107-151303-1143@Xerox>

The points I remember from the meeting not reflected since are:

While it is useful to encourage the "functional style" of programming,
these functions are *not nearly enough* to do that. That is, if you really
wanted to build a useful library, you would find these few functions
inadequate.

Extensions that no current vendor offers -- even those that have extensive
sets of extensions to Common Lisp in their product -- should be viewed with
great suspicion.


∂07-Nov-88  1713	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COERCE-TIME (Version 2)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Nov 88  17:13:07 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 488700; Mon 7-Nov-88 20:12:33 EST
Date: Mon, 7 Nov 88 20:12 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FUNCTION-COERCE-TIME (Version 2)
To: masinter.pa@Xerox.com
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881107-150710-1136@Xerox>
Message-ID: <881107201238.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

Not only do I wish FUNCTION-TYPE would get changed back, but I think it is
appropriate for us to word things in such a way that they infringe on some
implementation-specific extensions.

To take an example from another domain, the Scheme community was discussing
defining EQ on symbols as simply comparing the print names (because Scheme
doesn't have gensyms). I tried to talk them into mentioning that this was
only incidental and that if gensyms were introduced that the (formal semantics)
location of the symbol should be used, not its print name. I met with 
opposition from people who said that we (Scheme) shouldn't be saying how
people extend things. But I continue to believe it would be a disaster if
someone extended Scheme to make EQ do anything other than pointer comparison
for non-interned symbols.

Getting back to this point, then, I think it's a good idea not only to separate
the issue of FUNCTION-TYPE from this issue, but also it's good to adopt wording
that says what we mean it to say in the case where we can reasonably anticipate
extensions.

By the way, I'm thinking of circulating a revision of this proposal which
might lean more toward explicitly vague on some of these issues. At the same
time, I'd like to encourage the use of the DEBUG and/or SPEED quality to help
compilers lean toward LAZY in the slow/easy-to-debug case and AMBITIOUS in the
fast/hard-to-debug case. There are some details to be worked out, though...
Does anyone have any thoughts on that. 

∂08-Nov-88  1143	CL-Cleanup-mailer 	Re: Issue: FUNCTION-DEFINITION (Version 1)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Nov 88  11:42:58 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 NOV 88 11:26:22 PST
Date: 8 Nov 88 11:26 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-DEFINITION (Version 1)
In-reply-to: gz@spt.entity.com (Gail Zacharias)'s message of 13 Oct 88
 23:41:20 EDT (Thu)
To: gz@spt.entity.com (Gail Zacharias)
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881108-112622-1084@Xerox>

I also don't like SOURCE-CODE. I unfortunately don't like
FUNCTION-DEFINITION very much, either, but more for the reason that I'm
used to thinking of the "definition" of a function as the entire DEFUN
form, rather than the lambda expression that might be recovered from it.
FUNCTION-LAMBDA-EXPRESSION? FUNCTION-SOURCE-CODE?

I'm unsure how far we're willing to proscribe how much the form of the
original definition is retained. For example, after

(DEFUN FOO (X) X)

what is (FUNCTION-DEFINITION 'FOO)? Can it be

(BLOCK-LAMBDA FOO (X) X)

or must it be

(LAMBDA (X) (BLOCK FOO X))

or something else?


∂08-Nov-88  1251	CL-Cleanup-mailer 	Issue: FUNCTION-DEFINITION (Version 1)   
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 8 Nov 88  12:50:15 PST
Received: from fafnir.think.com by Think.COM; Tue, 8 Nov 88 14:41:08 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 8 Nov 88 15:00:31 EST
Received: from joplin.think.com by verdi.think.com; Tue, 8 Nov 88 15:04:42 PST
Received: by joplin.think.com; Tue, 8 Nov 88 15:00:20 EST
Date: Tue, 8 Nov 88 15:00:20 EST
From: gls@Think.COM
Message-Id: <8811082000.AA06028@joplin.think.com>
To: masinter.pa@xerox.com
Cc: gz@spt.entity.com, KMP@stony-brook.scrc.symbolics.com,
        CL-Cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@xerox.com's message of 8 Nov 88 11:26 PST <881108-112622-1084@Xerox>
Subject: Issue: FUNCTION-DEFINITION (Version 1)

   Date: 8 Nov 88 11:26 PST
   From: masinter.pa@xerox.com

   I also don't like SOURCE-CODE. I unfortunately don't like
   FUNCTION-DEFINITION very much, either, but more for the reason that I'm
   used to thinking of the "definition" of a function as the entire DEFUN
   form, rather than the lambda expression that might be recovered from it.
   FUNCTION-LAMBDA-EXPRESSION? FUNCTION-SOURCE-CODE?

FUNCTION-SEXPR ?

   I'm unsure how far we're willing to proscribe how much the form of the
[prescribe?]
   original definition is retained. For example, after

   (DEFUN FOO (X) X)

   what is (FUNCTION-DEFINITION 'FOO)? Can it be

   (BLOCK-LAMBDA FOO (X) X)

   or must it be

   (LAMBDA (X) (BLOCK FOO X))

   or something else?

For example, can it be the same as the value of #'identity ?

∂08-Nov-88  2201	CL-Cleanup-mailer 	Issue deadlines 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 8 Nov 88  22:01:09 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02174g; Tue, 8 Nov 88 22:00:03 PST
Received: by bhopal id AA03393g; Tue, 8 Nov 88 21:58:42 PST
Date: Tue, 8 Nov 88 21:58:42 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811090558.AA03393@bhopal>
To: masinter.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu
Subject: Issue deadlines

I need more time to work on the several remaining issues that I'm a
central party to.  Could you possibly extend the deadline for one more
week?  In particular, I have three nascent new version of issues that 
need airing:

  SETF-FUNCTION-VS-MACRO  -- As per discussion at the Fairfax meeting --
                             Gregor and I have a good plan; it's just a 
                             matter of writing it out and proofreading it;
  DECLARATION-SCOPE       -- Again, I have it "scoped out", with partial
                             discussion appearing recently, but need an
                             hour or so to write out the simpler version;
  HASH-TABLE-STABILITY    -- The issue that I explicitly asked for "more 
                             time" on at Fairfax; clarify what "Hash on
                             EQ" implies.

The problem, as usual, is that one's companies product deadlines don't 
just disappear when we go into high-speed "Cleanup" mode, and there is 
only so much time per week I can spend on reading x3 mail etc. [plus
another bout with the "flu".]

I expect to be able to have fairly good versions of two of the three
issues above by this weekend, and the third one finished by the middle
of next week.  Can this time frame be accommodated?


-- JonL --

∂09-Nov-88  1402	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 9 Nov 88  14:02:45 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA06580; Wed, 9 Nov 88 17:00:37 EST
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA11136; Wed, 9 Nov 88 17:04:32 EST
Message-Id: <8811092204.AA11136@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax.encore.com
Cc: Jon L White <jonl%LUCID.COM@multimax.encore.com>,
        "sandra%defun@CS.UTAH.EDU"@multimax.encore.com
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
In-Reply-To: Your message of Wed, 02 Nov 88 15:17:04 -0600.
             <2803497424-11026245@Kelvin> 
Date: Wed, 09 Nov 88 17:04:28 EST
From: Dan L. Pierson <pierson@mist>

    Date: Wed, 2 Nov 88  15:17:04 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    Consider the function ED.  It is a standard way to invoke an editor; the
    ED function is specified without having to define a standard editor; the
    function is simply a way to invoke whatever editor the implementation
    provides.  Similarly, (REQUIRE "FOO") should be defined as a standard way
    to invoke whatever module loading feature the implementation provides.
    You don't have to standardize how it is done in order to standardize how
    to ask it to be done.

There is a major difference between ED and REQUIRE in this respect.

ED is an environmental feature which is very unlikely to be used by a
program (i.e. while a program may well call ED to put the user in the
editor, it is very unlikely that a program will call ED, then try to
talk to the editor itself).

REQUIRE is intended to be built into programs.  A non-loading REQUIRE
can be used as a portable safety net per JonL's comments.  A loading
REQUIRE is a very powerful (and valuable) file inclusion directive.
Most users of the implementation will come to depend on REQUIRE to
load files in multi-file applications.  This will tend to cause any
program from an implementation with a loading REQUIRE to fail to port
to non-loading implementations.  The triviality of the porting bugs
will be inversely proportional to the sophistication of the
implementation's REQUIRE.

In summary I claim that a loading REQUIRE has two unacceptable traits:
 - People will use and depend on the loading feature.
 - This will make REQUIRE an obstacle to portable code.

Therefore, I oppose any proposal that allows REQUIRE to load files.
If we're going to make the feature non-portable we should remove it
from the portable language so that users of powerful implementations
will not be unnecessarily misled by the standard.  However, if the
people in this committee feel that we should vote on all three
alternatives (ELIMINATE, DECLARATIVE, and STATUS-QUO), I'll write them
all up.

∂10-Nov-88  0951	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 10 Nov 88  09:51:16 PST
Received: by ti.com id AA20395; Thu, 10 Nov 88 11:50:23 CST
Received: from Kelvin by tilde id AA13118; Thu, 10 Nov 88 11:35:01 CST
Message-Id: <2804175396-3579026@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 10 Nov 88  11:36:36 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "Dan L. Pierson" <pierson%mist@MULTIMAX.ENCORE.COM>
Cc: cl-cleanup@sail.stanford.edu, Jon L White <jonl@LUCID.COM>,
        sandra%defun@CS.UTAH.EDU, Bartley@MIPS.csc.ti.com
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
In-Reply-To: Msg of Wed, 09 Nov 88 17:04:28 EST from "Dan L. Pierson" <pierson@mist>

> In summary I claim that a loading REQUIRE has two unacceptable traits:
>  - People will use and depend on the loading feature.
>  - This will make REQUIRE an obstacle to portable code.

That would seem to me to be an argument for making file loading a
required part of the functionality.  It is trivial to define a way to
associate a module name with a list of file names to be loaded; there
really isn't any reason why every implementation couldn't have a way to
do that.  The hard part about defining a file-loading utility is to have
it compile files that need to be compiled and to do the compiling and
loading in the right order, but it is quite sufficient for REQUIRE to
just load previously compiled files.  As an existence proof I offer the
following portable implementation of REQUIRE.  The call to DEFINE-MODULE
is necessarily implementation dependent because of pathname syntax and
directory usage, but re-doing it or its equivalent for each
implementation ported to would not be a big problem.


(DEFVAR *MODULES* NIL "List of modules marked present with PROVIDE.")
 
(DEFUN PROVIDE (MODULE)
  "Mark MODULE as being already loaded."
  (PUSHNEW (STRING MODULE) *MODULES* :TEST #'STRING=)
  (VALUES))

(DEFVAR *MODULE-HASH-TABLE* (MAKE-HASH-TABLE :TEST #'EQUAL))

(DEFUN DEFINE-MODULE (NAME &REST FILE-NAMES)
  "Specify which files REQUIRE should load for module NAME."
  (SETF (GETHASH (STRING NAME) *MODULE-HASH-TABLE*)
	(MAPCAR #'MERGE-PATHNAMES FILE-NAMES))
  NAME)

(DEFUN REQUIRE (MODULE)
  "Ensure that MODULE is loaded."
  (LET ((NAME (STRING MODULE)))
    (LOOP
      (IF (MEMBER NAME *MODULES* :TEST #'STRING=)
	  (RETURN)
	(LET ((FILES (GETHASH NAME *MODULE-HASH-TABLE* NIL)))
	  (IF (NULL FILES)
	      (CERROR "Re-try the REQUIRE call after manually loading the module."
		      "Required module ~S is neither loaded nor defined." NAME)
	    (LET ((MODULES *MODULES*))
	      (UNWIND-PROTECT
		  (PROGN (MAPC #'LOAD FILES)
			 (PROVIDE NAME)
			 (SETQ MODULES *MODULES*))
		(SETQ *MODULES* MODULES))
	      (RETURN)))))))
  (VALUES))

∂10-Nov-88  1034	CL-Cleanup-mailer 	Issue: DEFSTRUCT-ACCESS-FUNCTIONS (Version 1) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Nov 88  10:34:09 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 490477; Thu 10-Nov-88 13:34:05 EST
Date: Thu, 10 Nov 88 13:33 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFSTRUCT-ACCESS-FUNCTIONS (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881110133351.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

Kathy recently forwarded this to me. It looks reasonable to me.
I guess the question is whether anyone has an implementation in
which it would be inappropriate to do this inlining. If so, we'll
need to explore that.

-----
Issue:        DEFSTRUCT-ACCESS-FUNCTIONS
References:   DEFSTRUCT (p. 308)
Category:     CHANGE
Edit history: 5-Oct-88, Version 1 by Chapman

Problem Description:

 It is left up to the implementation whether or not the DEFSTRUCT access
 function is declared inline.

Proposal (DEFSTRUCT-ACCESS-FUNCTIONS:INLINE)

 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:

Adoption Cost:

 Minimal.

Benefits:

 This clarification will give users insurance that the inline declaration
 has been made for the access function.

Conversion Cost:

 Minimal.

Aesthetics:

 None.

Discussion:

 

∂10-Nov-88  1034	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Nov 88  10:34:32 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03352g; Thu, 10 Nov 88 10:33:20 PST
Received: by bhopal id AA05895g; Thu, 10 Nov 88 10:32:01 PST
Date: Thu, 10 Nov 88 10:32:01 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811101832.AA05895@bhopal>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)

Final nits:
    <KMP@STONY-BROOK.SCRC.Symbolics.COM>: Sun, 9 Oct 88 02:45 EDT
    <barmar@Think.COM> Thu, 13 Oct 88 10:23 EDT
    <jonl@LUCID.COM> Mon, 17 Oct 88 16:45:13 PDT
and dded discussion about syntax of with-package-iterator.

-- JonL --

!

Issue:         HASH-TABLE-PACKAGE-GENERATORS

References:    Issue: DO-SYMBOLS-DUPLICATES 

Category:      ADDITION

Edit history:  Version 1, 23-May-88 JonL
	       Version 2,  6-Oct-88 JonL (convert to "with" scoping).
	       Version 3,  7-Oct-88 JonL (mly's syntax for package iterator)
	       Version 4,  8-Nov-88 JonL (fix example; clarify some nits)

Problem description:

The Iteration subcommittee would like the several iteration proposals to be
writeable in portable Common Lisp code.  Unfortunately, the only complete
access to hash-tables and packages is through MAPHASH and DO-SYMBOLS (and
DO-EXTERNAL-SYMBOLS and DO-ALL-SYMBOLS); none of these existing primitives 
is satisfactory for building complex iteration clauses.


Proposal (HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER)

Add two new macros WITH-HASH-TABLE-ITERATOR and WITH-PACKAGE-ITERATOR 
to the language as follows:


    WITH-HASH-TABLE-ITERATOR ((<next-fn> <hash-table>) &body body)      [Macro]
    
    Within the lexical scope of 'body', the name <next-fn> is defined
    via MACROLET such that successive invocations of (<next-fn>) will 
    return the items, one by one, from the hash-table which is obtained 
    by evaluating <hash-table> [only once].

    An invocation (<next-fn>) returns three values as follows:
      ;;    1. a boolean indicating whether an entry is returned (T says yes)
      ;;    2. the key item (of a <key, value> pair)
      ;;    3. the value item (of a <key, value> pair)
      ;; After all entries have been returned [by successive invocations of
      ;;   (<next-fn>)], then only one value is returned, namely NIL.



    WITH-PACKAGE-ITERATOR ((<next-fn> <package>                         [Macro]
                            &key external internal inherited)
                           &body body)

    Within the lexical scope of 'body', the name <next-fn> is defined
    via MACROLET such that successive invocations of (<next-fn>) will 
    return the items, one by one, from the package which is obtained 
    by evaluating <package> [only once].  

    An invocation (<next-fn>) returns three values as follows:
      ;;    1. a boolean indicating whether an entry is returned (T says yes)
      ;;    2. a symbol (available in the indicated package)
      ;;    3. the availability type for that symbol; i.e. one of
      ;;       :INTERNAL, :EXTERNAL, or :INHERITED,  or unspecified for 
      ;;       the DO-ALL-SYMBOLS case.
      ;; After all entries have been returned [by successive invocations of
      ;;   (<next-fn>)], then only one value is returned, namely NIL.

    The keyword arguments are flags indicating which kinds of symbols are 
    wanted; they are not "evaluated".  The following combinations are 
    recognized:
    +----------+----------+-------------+-------------------------------------
    | external | internal | inherited   |   CLtL macro equivalent 
    +----------+----------+-------------+-------------------------------------
    |    T     |    T     |     T       |    DO-SYMBOLS
    |    T     |    T     |    NIL      |    DO-PRESENT-SYMBOLS      [not CLtL]
    |    T     |   NIL    |     T       |    <none> 		  [unspecified]
    |    T     |   NIL    |    NIL      |    DO-EXTERNAL-SYMBOLS
    |   NIL    |    T     |     T       |    <none> 		  [unspecified]
    |   NIL    |    T     |    NIL      |    DO-INTERNAL-SYMBOLS     [not CLtL]
    |   NIL    |   NIL    |     T       |    DO-INHERITED-SYMBOLS    [not CLtL]
    |   NIL    |   NIL    |    NIL      |    DO-ALL-SYMBOLS
    +----------+----------+-------------+--------------------------------------
    In the default case, equivalent to DO-ALL-SYMBOLS, the value of the
    <package> argument is ignored.  The lines marked "[not CLtL]" mention
    package iterator macros found in some implementations of Common Lisp;
    their meaning should be self-explanatory.  The lines marked "unspecified" 
    may be extended by an implementation to have the implied meaning.

    In accord with common practice, the options that include any "inherited"
    symbols, and the DO-ALL-SYMBOLS option, are allowed to present the 
    same symbol multiple times.  This is because a symbol may be "inherited"
    from several different used packages; and a symbol may be present in 
    several different packages (in the DO-ALL-SYMBOLS case).  See the 
    proposal DO-SYMBOLS-DUPLICATES:ALLOWED.

It is unspecified what happens if any of the implicit interior state 
of an iteration is returned outside the dynamic extent of the WITH-...
form (such as by returning some closure over the invocation form).


Test-case:

The following function should return T on any hash-table, and signal
an error if the usage of 'with-hash-table-iterator' doesn't agree
with the corresponding usage of 'maphash'.

(defun test-hash-table-iterator (hash-table)
  (let ((all-entries '())
	(generated-entries '())
	(unique (list nil)))
    (maphash #'(lambda (key value) (push (list key value) all-entries))
	     hash-table)
    (with-hash-table-iterator (generator-fn hash-table)
      (loop 	
	;;Note -- this is the "trivial" LOOP of CLtL p121
	(multiple-value-bind (more? key value) (generator-fn)
	  (unless more? (return))
	  (unless (eql value (gethash key hash-table unique))
	    (error "Key ~S not found for value ~S" key value))
	  (push (list key value) generated-entries))))
    (unless (= (length all-entries)
	       (length generated-entries)
	       (length (union all-entries generated-entries :test #'equal)))
      (error "Generated entries and Maphash entries don't correspond"))
    t))


The following function should return T on any package, and signal
an error if the usage of 'with-package-iterator' doesn't agree
with the corresponding usage of 'do-symbols'.

(defun test-package-iterator (package)
  (unless (packagep package)
    (setq package (find-package package)))
  (let ((all-entries '())
	(generated-entries '()))
    (do-symbols (x package) 
      (multiple-value-bind (symbol accessibility) 
		(find-symbol (symbol-name x) package)
	(push (list symbol accessibility) all-entries)))
    (with-package-iterator (generator-fn package 
			     :internal t :external t :inherited t)
      (loop 	
	;;Note -- this is the "trivial" LOOP of CLtL p121
	(multiple-value-bind (more? symbol accessibility) (generator-fn)
	  (unless more? (return))
	  (let ((l (multiple-value-list (find-symbol (symbol-name symbol) 
						     package))))
	    (unless (equal l (list symbol accessibility))
	      (error "Symbol ~S not found as ~S in package ~A [~S]"
		     symbol accessibility (package-name package) l))
	    (push l generated-entries)))))
    (unless (and (subsetp all-entries generated-entries :test #'equal)
		 (subsetp generated-entries all-entries :test #'equal))
     (error "Generated entries and Do-Symbols entries don't correspond"))
    t))

The following functions prints out every interned symbol:

(defun print-all-symbols () 
  (with-package-iterator (next-symbol nil)
    (loop
      ;;Note -- this is the "trivial" LOOP of CLtL p121
      (multiple-value-bind (more? symbol) (next-symbol)
	(if more? 
           (print symbol)
	   (return))))))


Rationale:

The particular way in which hash-tables and packages are represented
need not be standardized, or even exposed to the user.  Yet a simpler 
handle on them is needed for the various iteration paradigms to be written 
in portable code.  In fact, after these iterator macros are put into an 
implementation, then MAPHASH and DO-<mumble>-SYMBOLS are trivial usages 
of them; but no _efficient_ use of the current primitives will provide 
the effect of the new macros, namely a form that _returns_ the elements
of a table "one by one".


Current Practice:

Nobody does it this way, but both Symbolics and Lucid are not far off.

Cost to Implementors:

Moderate.  Possibly a couple day's to a week's work for an implementation 
that has to start completely afresh.  Something like this is already being
done by the standard package macros [CLtL, p187].

Cost to Users:

None.

Benefits:

Will provide a more basic primitive for iterating over hash-tables and 
packages; will permit new iteration paradigms to be written in portable code.

Aesthetics:

All other things being equal, it is better to have more general primitives
than less general ones.  


Discussion:

The Iteration Subcommittee supports this proposal (or, "used to" -- 
JonL 6-Oct-88).

One must be careful not to assume that the invocation (<next-fn>) is a 
"generator" function call -- since <next-fn> is MACROLET'd in an 
implementation dependent way, it could even turn into a special form like
    (if something
        (values nil)
        (yet-another-function-call))

The scoping called for herein may not be quite so useful to the "generators"
style proposals; in particular they offer an interface wherein one may 
create a "generator" function of indefinite extent that returns, one-by-one,
the elements of the table.  The constrained scoping implicit in these
WITH-... macros is not so much for any kind of optimization, but rather
for coordination of such hash-table "locking" as may occur in multi-
processing implementations like Symbolics.  Nevertheless, Dick Waters 
thinks these macros should be put in anyway, since it clearly is a 
requirement for a portable LOOP, and can be use in a limited context 
(i.e., not "indefinite scope") for portable versions of ITERATE and OSS.

Of course, if an implementation _can_ support an indefinite extent for
a "generator" object returned out of the iterator forms, it is allowed 
to do so by this proposal.

There has been some concern that the syntax of keyword arguments to 
WITH-PACKAGE-ITERATOR may be problematical; especially, it seems odd
that the <package> argument is a required argument, but is not used
at all in the case when the keyword arguments select a DO-ALL-SYMBOLS
meaning.  This is a constraint that isn't easy to express in the existing 
CL language: namely, that the <package> argument is required if and only
if any of the keyword arguments are supplied as non-nil.  One way out of 
this bind is to let the <package> argument be optional, defaulting to the
symbol *PACKAGE*.  Then the example above for 'print-all-symbols' could
be written as:
  (with-package-iterator (next-symbol) ...)
instead of:
  (with-package-iterator (next-symbol nil) ...)
or, instead of:
  (with-package-iterator 
        (next-symbol nil :external nil :internal nil :inherited nil )
     ...)



∂10-Nov-88  1058	CL-Cleanup-mailer 	Issue: FORMAT-PRETTY-PRINT (Version 6)   
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 10 Nov 88  10:58:26 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA13142; Thu, 10 Nov 88 13:57:14 EST
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA00931; Thu, 10 Nov 88 14:01:09 EST
Message-Id: <8811101901.AA00931@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax.encore.com
Subject: Issue: FORMAT-PRETTY-PRINT (Version 6)
Date: Thu, 10 Nov 88 14:01:06 EST
From: Dan L. Pierson <pierson@mist>

Here it is at last.

Issue:         FORMAT-PRETTY-PRINT
References:    FORMAT (pp. 385-388), PRIN1 (p. 83), PRINC (p. 83),
               WRITE (p. 382), *PRINT-PRETTY* (p. 371)
Category:      CLARIFICATION
Edit history:  Version 1 by Pierson 3/4/88
    	       Version 2 by Pierson 5/24/88 (fix name typo)
	       Version 3 by Pierson 6/10/88 incorporate comments
	       Version 4 by Pierson 6/10/88 comments from Van Roggen
	       Version 5 by Masinter  2-Oct-88
               Version 6 by Pierson 11/10/88 final nits

Problem description:

The FORMAT operators, ~A and ~S are defined to print their argument as
PRINC and PRIN1 respectively.  The text does not say whether or not
these FORMAT operators must obey the *PRINT-PRETTY* flag.

Proposal (FORMAT-PRETTY-PRINT:YES):

Specify that FORMAT does rebind any of the printer control
variables (*PRINT-...) except as follows:

~A
    Binds *PRINT-ESCAPE* to NIL.

~S
    Binds *PRINT-ESCAPE* to T.

~D
    Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
    *PRINT-BASE* to 10.

~B
    Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
    *PRINT-BASE* to 2.

~O
    Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
    *PRINT-BASE* to 8.

~X
    Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
    *PRINT-BASE* to 16.

~R
    Iff a first argument is specified, binds *PRINT-ESCAPE* to NIL,
    *PRINT-RADIX* to NIL, and *PRINT-BASE* to the value of the first
    argument.

    Iff no aruments are specified, binds *PRINT-BASE* to 10.

~@C
    Binds *PRINT-ESCAPE* to T.

~F,~G,~E,~$
    Binds *PRINT-ESCAPE* to NIL.

Test Cases/Examples:

(LET ((TEST '#'(LAMBDA (X)
		 (LET ((*PRINT-PRETTY* T))
		   (PRINT X)
		   (FORMAT T "~%~S " X)
		   (TERPRI) (PRINC X) (PRINC " ")
		   (FORMAT T "~%~A " X)))))
  (FUNCALL (EVAL TEST) TEST))

This should print four copies of the above lambda expression.  The
first pair should appear identical and the second pair should appear
identical.  The only difference between the two pairs should be the
absence of string quotes in the second pair.

Rationale:

FORMAT should interact with the printer control variables in a
predictable way.  This proposal is one of the two simplest possible
definitions and provides the most flexibility to the user.

A major advantage of this proposal is that the following two
expressions are guaranteed to have exactly the same effect:

    (FORMAT stream "~S" object)
    (PRIN1 object stream)

Thus use or non-use of FORMAT becomes a purely stylistic matter.

Current practice:

Ibuki Lisp and the TI Explorer obey the binding of *PRINT-PRETTY*.
Lucid Common Lisp always applies ~A and ~S with *PRINT-PRETTY* bound
to NIL.

Cost to Implementors:

While changing FORMAT to not bind *PRINT-foo* variables is trivial,
there are some painful implications.  How does a pretty-printing ~A
interact with MINCOL, etc?  How much of the user interface depends on
FORMAT in ways that might be uglified by pretty printing?

Cost to Users:

Truely portable code shouldn't be affected because existing
implementations are inconsistent.  Despite this, there are probably a
number of user programs in non-complying implementations which will
have to change whichever way this is decided.

Cost of non-Adoption:

The interaction of FORMAT and the printer control variables (especially
*PRINT-PRETTY*) will remain undefined.  This will continue to make
portable Common Lisp programming harder than it need be.

Benefits:

Life will be easier for users in two ways: (1) one more portability
problem will be removed, and (2) users will be more likely to be able
to persuade environmental features like debuggers to print in their
preferred way.

Aesthetics:

The interaction between two related parts of output will be clarified
in a simple way.

Discussion:

It is important to specify exactly what of Common Lisp's special
variables get rebound by other functions and macros in Common Lisp.
This cleanup issue addresses the interaction of FORMAT and the
*PRINT-  variables. There may be other similar interactions in 
Common Lisp that need clarification.

Otherwise, code that depends on FORMATs action in one implementation
will not port to others that do not have the same behavior.

CLtL might change as follows:

Add a header "Printer Control Variables" before the description of
*PRINT-ESCAPE* on page 370.

Add the following paragraph to page 386 just before the paragraph
starting with "It is an error":

    "The FORMAT function by itself never binds any of the printer
    control variables.  Specific FORMAT directives bind exactly the
    printer control variables specified in their description.  While
    implementations may specify the binding of new, implementation
    specific printer control variables for each FORMAT directive, they
    may neither bind any standard printer control variables not
    specified in description of a FORMAT directive nor fail to bind
    any standard printer control variables as specified in the
    description."

There was some discussion on whether *PRINT-BASE* should be bound for
~F, ~G, ~E, and ~$.  This is not necessary because page 341 of CLtL
states that floating point numbers are always printed in base 10.

∂10-Nov-88  1221	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Nov 88  12:21:35 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 490570; Thu 10-Nov-88 15:21:44 EST
Date: Thu, 10 Nov 88 15:21 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8811101832.AA05895@bhopal>
Message-ID: <19881110202131.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

I approve the WITH-HASH-TABLE-ITERATOR portion of
HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER.

I have two problems with WITH-PACKAGE-ITERATOR.  First, you use the
undefined phrase "available in the indicated package" a few times.  I
think you mean "accessible in the indicated package" (defined on CLtL
p.172).  The more important problem is that I think the syntactic
problem noted in the discussion section makes WITH-PACKAGE-ITERATOR
unacceptable.  I don't like having a required argument that is ignored,
and I don't like having those two unspecified cases: either the meaning
should be specified or they should signal an error.

I have two suggested alternatives that I think solve this.  Either of
them would be acceptable to me.  The second is simpler than the first so
I mildly prefer it.  If you like I can edit up an alternative proposal,
but I thought I would start by just presenting alternatives to this one
small piece of your proposal.

Alternative syntax #1:  In place of

	WITH-PACKAGE-ITERATOR ((<next-fn> <package>                         [Macro]
				&key external internal inherited)
			       &body body)

let's use the syntax

	WITH-PACKAGE-ITERATOR ((<next-fn>                                   [Macro]
				&optional <package>
				&rest symbol-types)
			       &body body)

The symbol-types arguments are symbols from the set {:INTERNAL, :EXTERNAL,
:INHERITED}.  Their order does not matter.

(WITH-PACKAGE-ITERATOR (next) body) is DO-ALL-SYMBOLS.
(WITH-PACKAGE-ITERATOR (next pkg) body) signals an error for invalid syntax.
(WITH-PACKAGE-ITERATOR (next pkg :EXTERNAL) body) is DO-EXTERNAL-SYMBOLS
(WITH-PACKAGE-ITERATOR (next pkg :INTERNAL :EXTERNAL :INHERITED) body) is DO-SYMBOLS
etc. for the other five cases.

Alternative syntax #2: Use the syntax

	WITH-PACKAGE-ITERATOR ((<next-fn>                                   [Macro]
				&optional <package>)
			       &body body)

If <package> is supplied, this is DO-SYMBOLS, otherwise it is DO-ALL-SYMBOLS.
The third value returned by <next-fn> can be used to filter out unwanted symbols
when doing such operations as DO-EXTERNAL-SYMBOLS.

∂10-Nov-88  1256	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Nov 88  12:56:11 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03569g; Thu, 10 Nov 88 12:54:13 PST
Received: by bhopal id AA06593g; Thu, 10 Nov 88 12:52:54 PST
Date: Thu, 10 Nov 88 12:52:54 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811102052.AA06593@bhopal>
O: Gray@DSG.csc.ti.com, 
Cc: pierson%mist@MULTIMAX.ENCORE.COM, cl-cleanup@sail.stanford.edu,
        sandra%defun@CS.UTAH.EDU, Bartley@MIPS.csc.ti.com
In-Reply-To: David N Gray's message of Thu, 10 Nov 88  11:36:36 CST <2804175396-3579026@Kelvin>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 

I think we are very close to agreement here, providing we can stay
clear of the deeply controversial areas.  Dan objects to having 
non-portable features be a required part of the standard; and you
(Dave) object to having no reference to the implementation-dependent 
way in which file-loading can be accomplished to "provide" a module.

How about a compromise along the lines I suggested on Nov 2?  First,
say that implementations may extend REQUIRE to hook into an
implementation-specific module loading system; but Second say that
any such extension should provide a means of disabling it.  That way,
one can check-out portable, pure "safety-net" applications by turning 
off the defsystem hook-in [the turning off would be in an implementation
specific way, but that should be fine.]



-- JonL --


P.S.: Your example DEFINE-MODULE is slanted towards a simple loading
      scheme, and certainly could be useful as it stands.  However, I 
      would prefer to see the notion of module "provision" a bit more 
      abstract.  In particular, the error strings to CERROR could be like:
       "Require'd module ~S is not present."
      rather than:
       "Required module ~S is neither loaded nor defined."
      and the continuation string culd be more like:
       "Re-try the REQUIRE call [after perhaps manually providing the module]"
      rather than:
       "Re-try the REQUIRE call after manually loading the module."
      Still, it must be admitted that we are not at all close to specifying
      a standard for defsystem-like facilities.

∂10-Nov-88  1328	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Nov 88  13:28:34 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03612g; Thu, 10 Nov 88 13:27:23 PST
Received: by bhopal id AA06710g; Thu, 10 Nov 88 13:26:05 PST
Date: Thu, 10 Nov 88 13:26:05 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811102126.AA06710@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 10 Nov 88 15:21 EST <19881110202131.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)

Your alternative syntax #1 is clearly superior to all the others.  Could 
you take the time to alter the proposal accordingly, and at the same time 
fix the typo "available" into "accessible"? [and also proof read the 
whole proposal again?]

Alternative #2 is unacceptable, because it presumes that filtering a
DO-ALL-SYMBOLS is a reasonable implementation of DO-EXTERNAL-SYMBOLS.  
In fact, in Lucid Common Lisp, the situation is much more complex; the 
"filtering" step could, in extreme circumstances, become pragmatically 
unworkable, whereas the native implementation has no trouble.


-- JonL --

∂10-Nov-88  1515	CL-Cleanup-mailer 	Issue: MAKE-STRING-FILL-POINTER (Version 1)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Nov 88  15:15:40 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04133g; Thu, 10 Nov 88 15:14:21 PST
Received: by bhopal id AA07665g; Thu, 10 Nov 88 15:13:01 PST
Date: Thu, 10 Nov 88 15:13:01 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811102313.AA07665@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 20 Oct 88 21:25 EDT <19881021012549.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Subject: Issue: MAKE-STRING-FILL-POINTER (Version 1)

This proposal isn't merely an ADDITION -- it is an incompatible CHANGE,
since CLtL explicitly states that the output of MAKE-STRING is a simple
string.

If we are to give up that semantics, then a separate function for 
MAKE-STRING makes sense only in two circumstances:
  (1) when STRINGs are fundamentally different from ARRAYS; or
  (2) when it is merely a "shorthand" syntax.

Since there has been no attempt to retrench strings away from their 
underlying implementation as arrays, then I suggest we either leave 
MAKE-STRING alone, or complete the (incompatible) "shorthand" extension
as follows:

  (defun make-string (size &key :initial-element :initial-contents
                                :adjustable  	 :fill-pointer 
                                :displaced-to    :displaced-index-offset)
    (check-type size integer)
    (make-array size :element-type           'string-char 
                     :initial-element        initial-element 
                     :initial-contents       initial-contents
                     :adjustable             adjustable 
                     :fill-pointer           fill-pointer
                     :displaced-to           displaced-to
                     :displaced-index-offset displaced-index-offset))

[When applicable, of course, compiler optimizers could convert MAKE-STRING 
calls into something more efficient.]


-- JonL --

∂10-Nov-88  1557	CL-Cleanup-mailer 	Issue: PACKAGE-FUNCTION-CONSISTENCY (Version 1)    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Nov 88  15:57:22 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04201g; Thu, 10 Nov 88 15:56:03 PST
Received: by bhopal id AA08229g; Thu, 10 Nov 88 15:54:45 PST
Date: Thu, 10 Nov 88 15:54:45 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811102354.AA08229@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Fri, 21 Oct 88 18:20 EDT <881021182009.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-FUNCTION-CONSISTENCY (Version 1)

Lucid Common Lisp implements the proposed "permissive" behavior except:
  (1) FIND-PACKAGE and IN-PACKAGE require names, based on our reading of
      the fine print in CLtL [extending to permit packages is no problem];
  (2) PACKAGE-USE-LIST and PACKAGE-USED-BY-LIST permit names.

I support this proposal in general; however I have one specific
disagreement with it that needs to be resolved: I think that
extending PACKAGE-NAME, PACKAGE-NICKNAMES, PACKAGE-USE-LIST, and
PACKAGE-USED-BY-LIST to accept names is generally useful; much more
so than is restricting them on the outside chance that open-coded
slot access is a critical performace issue.  Yes, it makes sense to
ask PACKAGE-NAME on a string; e.g., (PACKAGE-NAME "SYS") will be
"SYSTEM".

What do you think?

-- JonL --

∂10-Nov-88  1607	CL-Cleanup-mailer 	Re: Issue: DEFSTRUCT-ACCESS-FUNCTIONS (Version 1)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Nov 88  16:07:42 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 NOV 88 15:55:55 PST
Date: 10 Nov 88 15:55 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: <881110-155555-5818@Xerox>

I don't see what the problem is. Why is "It is left up to the
implementation whether or not the DEFSTRUCT access
 function is declared inline." a problem at all?


∂10-Nov-88  1607	CL-Cleanup-mailer 	Re: Issue: MAKE-STRING-FILL-POINTER (Version 1)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Nov 88  16:07:37 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 NOV 88 15:52:19 PST
Date: 10 Nov 88 15:52 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: MAKE-STRING-FILL-POINTER (Version 1)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Thu, 10 Nov 88
 15:13:01 PST
To: Jon L White <jonl@lucid.com>
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@sail.stanford.edu
Message-ID: <881110-155219-5804@Xerox>

Sigh, if you read carefully the character proposal you will see that it
proposes to extend the type STRING to be any vector whose element type is a
*subtype* of CHARACTER, which and would require MAKE-STRING to take an
:element-type keyword.

Your make-string definition is buggy, of course.

∂10-Nov-88  1629	CL-Cleanup-mailer 	Re: Issue: DEFSTRUCT-ACCESS-FUNCTIONS (Version 1)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Nov 88  16:29:25 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 490838; Thu 10-Nov-88 19:29:11 EST
Date: Thu, 10 Nov 88 19:28 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DEFSTRUCT-ACCESS-FUNCTIONS (Version 1)
To: masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881110-155555-5818@Xerox>
Message-ID: <881110192856.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: 10 Nov 88 15:55 PST
    From: masinter.pa@Xerox.COM

    I don't see what the problem is. Why is "It is left up to the
    implementation whether or not the DEFSTRUCT access
     function is declared inline." a problem at all?


I didn't raise this issue -- Kathy did. I'm not sure where she got it.

But since I happen to have endorsed it, I'll say why I did:

To keep people from having to write:

 (PROCLAIM '(INLINE FOO-A FOO-B FOO-C))
 (DEFSTRUCT FOO A B C)

I've seen this in portable code a number of times and it always turns my stomach.

∂10-Nov-88  1913	CL-Cleanup-mailer 	Issue: MAKE-STRING-FILL-POINTER (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Nov 88  19:13:29 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 490905; Thu 10-Nov-88 22:13:08 EST
Date: Thu, 10 Nov 88 22:12 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MAKE-STRING-FILL-POINTER (Version 1)
To: Jon L White <jonl@lucid.com>
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <8811102313.AA07665@bhopal>
Message-ID: <19881111031257.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 10 Nov 88 15:13:01 PST
    From: Jon L White <jonl@lucid.com>

    This proposal isn't merely an ADDITION -- it is an incompatible CHANGE,
    since CLtL explicitly states that the output of MAKE-STRING is a simple
    string.

It is not an incompatible change.  No portable program will stop working
on account of this change, because no portable program will use the newly
added feature.  I have no comment on the rest of your comments and don't
care much about this issue, since we are way past the point of adding
useful things to Common Lisp.

∂10-Nov-88  2052	CL-Cleanup-mailer 	Issue: MAKE-STRING-FILL-POINTER (Version 1)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Nov 88  20:52:00 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04437g; Thu, 10 Nov 88 20:50:08 PST
Received: by bhopal id AA12067g; Thu, 10 Nov 88 20:48:49 PST
Date: Thu, 10 Nov 88 20:48:49 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811110448.AA12067@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 10 Nov 88 15:52 PST <881110-155219-5804@Xerox>
Subject: Issue: MAKE-STRING-FILL-POINTER (Version 1)

re:  . . .the character proposal ... would require MAKE-STRING to take an
    :element-type keyword.

I don't see that this is absolutely necessary, since a default type could 
certainly be satisfactory for MAKE-STRING; you could use MAKE-ARRAY for
creating non-default types and features.  In the current situation, 
:element-type STRING-CHAR is what defines a string.

However, if we are to extend MAKE-STRING, what's the point of doing so 
unless it becomes capable of accepting all the same keyword arguments 
as MAKE-ARRAY?  It's only a shorthand for defaulting :element-type.
That's the point of the sample code [which was not intended to be run 
so please forgive the typos and neglect of the "suppliedp" question on 
initial element/contents.]  One can accommodate varieties of strings by 
overriding the default for an :element-type argument.  

  (defun make-string (size &key (element-type   'string-char)
                                initial-element initial-contents
                                adjustable  	fill-pointer 
                                displaced-to    displaced-index-offset)
    (check-type size integer)
    (make-array size :element-type           element-type
                     :initial-element        initial-element
                     :initial-contents       initial-contents
                     :adjustable             adjustable 
                     :fill-pointer           fill-pointer
                     :displaced-to           displaced-to
                     :displaced-index-offset displaced-index-offset))



-- JonL --

∂10-Nov-88  2115	CL-Cleanup-mailer 	Issue: MAKE-STRING-FILL-POINTER (Version 1)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Nov 88  21:15:17 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04447g; Thu, 10 Nov 88 21:14:05 PST
Received: by bhopal id AA12099g; Thu, 10 Nov 88 21:12:46 PST
Date: Thu, 10 Nov 88 21:12:46 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811110512.AA12099@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 10 Nov 88 22:12 EST <19881111031257.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: MAKE-STRING-FILL-POINTER (Version 1)

re:     [JonL] This proposal isn't merely an ADDITION -- it is an incompatible 
	CHANGE, since CLtL explicitly states that the output of MAKE-STRING is
	a simple string.
    [moon] It is not an incompatible change.  ... because no [currently?]
    portable program will use the newly added feature.  

Sorry, but it is an incompatiblity visible to any code-analysis system 
that does type-inferencing.  Those programs can "know" from CLtL that
MAKE-STRING returns a SIMPLE-STRING.

For example, Lucid's compiler contains detailed information about 
the specified argument types and function result types, and uses that
information to do some type-inferencing.  Furthermore, as Lucid 2.1 and
3.0 release documentation makes clear, AREF can only be open-coded on 
SIMPLE-ARRAYs; so the distinction _can_ be critically important.

Now, I don't claim that Lucid's type-inferencing is perfect in all 
circumstances; but it does matter to us when incompatible changes
are made to the type specifications of standard functions.


-- JonL --


∂10-Nov-88  2121	CL-Cleanup-mailer 	Issue: EXIT-EXTENT   
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 10 Nov 88  21:21:02 PST
Date: Thu 10 Nov 88 12:42:59-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue: EXIT-EXTENT
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim%ECLA@ECLC.USC.EDU
Message-ID: <12445512677.29.IIM@ECLA.USC.EDU>

I have several problems with the proposal for this issue.

  Date: 31 Oct 88 12:25 PST
  From: masinter.pa@Xerox.COM

    ...

  The ambiguity only arised because of unwind-protect.

Agreed.

    ...

  Given a block (block frob ...) which contains a (return-from frob ...) in it,
  we normally think of (return-from frob ...) as a "instantaneous" operation.

I don't agree with this at all.  I have never thought of the invocation of an
exit to be an "instantaneous" operation, due to the possible presence of
unwind-protects.  This part of my mental model for Lisp execution dates to well
before I ever got involved in implementation, so I don't think it is biased by
any particular implementation.  If I had encountered the behavior Symbolics
Genera exhibits without having seen the proposal, I would have submitted a bug
report. 

    ...

  If the extent is over only when the block is exited, then the following cases
  would *not* be an error: 

    < several examples >

This is the interpretation which I believe is correct.  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.}"

One of the alternatives mentioned in the proposal would be to "duck the issue
by outlawing all nonlocal exits from UNWIND-PROTECT cleanup forms".  As noted,
this alternative might have a substantial cost to some users.  However, it
seems to me that the proposal just about collapses to this alternative, since
there is in general no way to determine the target of the nonlocal exit, so the
cleanup forms usually cannot safely do any nonlocal exits without extra code to
in some way record the target.  In fact, in many implementations, due to the
presence of things like ABORT interrupts and such, it is probably almost
impossible to be certain of the target for a nonlocal exit.

I find it disturbing that the current dynamic environment of a cleanup form
depends on how the unwind-protect was exited.  This problem is even more
apparent if you extend the proposal to also apply to special variable bindings
in a manner similar to the way catch is specified in the proposal.  (Of course,
doing so would violate the implementation note on p.142).  I don't think you
can talk about the dynamic extent of exits in the way the proposal does without
also talking about the dynamic extent of other forms under the same situations.
And I think if you extend the proposal to other forms, the results begin to
look more and more strange.  For example,

    (block nil
      (let ((x 5))
        (declare (special x))
        (unwind-protect (return)
          (print x))))				;is this an error?

    (block nil
      (let ((x 5))
        (declare (special x))
        (unwind-protect
            (if (test) (return))
          (print x))))				;is this an error?

In the first example, if the dynamic extent of special variables is similar to
catchers, then under the proposal it is an error.  Similarly, in the second
example it is an error if (test) returns true, but might be ok if (test)
returns false.  It demonstrates an example of the problem I mentioned earlier,
of determining what things are dynamically available in the unwind-protect
cleanup forms.

And now for a slightly less contrived example which would probably be in error
under the proposal.  This is boiled down to mostly the essentials to keep from
cluttering it up, but I think it should be apparent that this is not a totally
unreasonable code fragment.

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

I understand the desire expressed in the proposal to avoid changing the
language in a way which invalidates certain implementation techniques, and
agree wholeheartedly with this desire.  However, I believe that the proposal
is in fact a change, rather than a clarification (as the proposal claims), and
that it is a change for the worse.

kab
-------

∂10-Nov-88  2229	CL-Cleanup-mailer 	Issue: DEFSTRUCT-ACCESS-FUNCTIONS (Version 1) 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Nov 88  22:29:30 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04487g; Thu, 10 Nov 88 22:27:35 PST
Received: by bhopal id AA12178g; Thu, 10 Nov 88 22:26:17 PST
Date: Thu, 10 Nov 88 22:26:17 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811110626.AA12178@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 Thu, 10 Nov 88 19:28 EST <881110192856.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: DEFSTRUCT-ACCESS-FUNCTIONS (Version 1)

re: To keep people from having to write:
     (PROCLAIM '(INLINE FOO-A FOO-B FOO-C))
     (DEFSTRUCT FOO A B C)
    I've seen this in portable code a number of times and it always turns 
    my stomach.

Yea, ugh, bletch.  But note that the proposal now shifts the burden 
to the user who *doesn't* want them in line, and who has to write:
     (PROCLAIM '(NOTINLINE FOO-A FOO-B FOO-C))
     (DEFSTRUCT FOO A B C)
However, the proposed change is probably the more commonly desired 
alternative.


-- JonL --

∂11-Nov-88  0821	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 11 Nov 88  08:21:08 PST
Received: by ti.com id AA28512; Fri, 11 Nov 88 10:20:08 CST
Received: from Kelvin by tilde id AA10441; Fri, 11 Nov 88 10:15:34 CST
Message-Id: <2804257054-8485159@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 11 Nov 88  10:17:34 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@LUCID.COM>
Cc: pierson%mist@MULTIMAX.ENCORE.COM, cl-cleanup@SAIL.STANFORD.EDU,
        sandra%defun@CS.UTAH.EDU, Bartley@mips.csc.ti.com
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
In-Reply-To: Msg of Thu, 10 Nov 88 12:52:54 PST from Jon L White <jonl@LUCID.COM>

> How about a compromise along the lines I suggested on Nov 2?  First,
> say that implementations may extend REQUIRE to hook into an
> implementation-specific module loading system; but Second say that
> any such extension should provide a means of disabling it.

If that makes you feel better about it, that's fine with me.

∂11-Nov-88  0937	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 11 Nov 88  09:37:14 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
	id AA01669; Fri, 11 Nov 88 10:35:43 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA00216; Fri, 11 Nov 88 09:35:43 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811111635.AA00216@defun.utah.edu>
Date: Fri, 11 Nov 88 09:35:42 MST
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: Jon L White <jonl@LUCID.COM>, pierson%mist@MULTIMAX.ENCORE.COM,
        cl-cleanup@SAIL.STANFORD.EDU, sandra%defun@cs.utah.edu,
        Bartley@mips.csc.ti.com
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Fri, 11 Nov 88  10:17:34 CST

Allowing REQUIRE to load files as an extension seems like a lousy idea
to me for the same reason that I gave against having modules magically
PROVIDE themselves -- namely, it might assume a file/module
correspondence other than what the user intended, and load the wrong
file. 

How about wording the proposal to indicate that implementations
can extend REQUIRE to load files automagically only if the user has
*explicitly* indicated (using some implementation-specific mechanism)
which files make up that module?

That would allow 

    (defsystem foo ....)
    (require "FOO")

to work, but would prevent

    (require "FOO")

from trying to load some random file named "FOO", which (as I've pointed
out earlier), may or may not contain the module "FOO".

-Sandra
-------

∂11-Nov-88  1037	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 11 Nov 88  10:36:36 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA24737; Fri, 11 Nov 88 13:32:20 EST
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA01642; Fri, 11 Nov 88 13:36:14 EST
Message-Id: <8811111836.AA01642@mist.UUCP>
To: "sandra%defun@cs.utah.edu"@multimax.encore.com (Sandra J Loosemore)
Cc: cl-cleanup%SAIL.STANFORD.EDU@multimax.encore.com,
        Bartley%mips.csc.ti.com@multimax.encore.com
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
In-Reply-To: Your message of Fri, 11 Nov 88 09:35:42 -0700.
             <8811111635.AA00216@defun.utah.edu> 
Date: Fri, 11 Nov 88 13:36:13 EST
From: Dan L. Pierson <pierson@mist>

    How about wording the proposal to indicate that implementations
    can extend REQUIRE to load files automagically only if the user has
    *explicitly* indicated (using some implementation-specific mechanism)
    which files make up that module?
    
    That would allow 
    
        (defsystem foo ....)
        (require "FOO")
    
    to work, but would prevent
    
        (require "FOO")
    
    from trying to load some random file named "FOO", which (as I've pointed
    out earlier), may or may not contain the module "FOO".
    
I'm still trying to think of an acceptable compromise based on JonL's
idea.  Unfortunately, this is a perfect example of what I can't accept
for the following reason:

Let's assume that the DEFSYSTEM's and REQUIRE's are part of a large,
real, potentially portable application.  Say 50 files in four
directories.  Somewhere in that complexity is one (or maybe four)
files containing one or more invocations of DEFSYSTEM.  Almost every
one of the 50 or so files contains at least one REQUIRE.  Since the
system was developed in an environment where all of this works, the
files with DEFSYSTEM are correctly loaded first thus causing all the
REQUIRE's to load files iff needed.

Let's further assume that all the rest of the code in the application
is portable because the author wanted to write a portable application
and was careful about it.

OK, now it's time to port it all.  Load up a portable DEFSYSTEM (we
carefully used a simple subset of the fancy native DEFSYSTEM) and load
and compile the rest.  Pity it didn't work because none of the
REQUIRE's did their normal loading functions in the new Common Lisp
implementation.  Pity it's a pain to debug because all the cross
references are implicit in this maze of REQUIRE's that _used_ to work.
It really would have been much easier if the author had simply avoided
REQUIRE and represented all the dependencies in a DEFSYSTEM file that
she knew was non-portable.  There's also the question: "if the
implementation had a DEFSYSTEM, why did she need to use REQUIRE to
load files?"

Once again, if you allow REQUIRE to load files it isn't portable and
code written in implementations that support it will be harder to
port (I haven't thought enough about the possible problems of going
from a non-loading implementation to a loading implementation).
If the feature isn't portable, why keep it in the language?  An
implementation can still support whatever version of REQUIRE it wants
as an extension to Common Lisp but:
 1. Users won't be fooled into believing it's a portable construct.
 2. Static portablility checks will be required to warn about it.

Almost the only compromise I can think of is something that forces you
to declare the non-portable loading intent in every use of REQUIRE, say:
 (REQUIRE "foo" :LOAD T)

It would be useful to hear from someone other than the 3-4 of us who
keep arguing this one.

∂11-Nov-88  1228	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 11 Nov 88  12:28:36 PST
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 11 Nov 88 15:27:21 EST
To: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
In-reply-to: Your message of Fri, 11 Nov 88 13:36:13 -0500.
             <8811111836.AA01642@mist.UUCP> 
Date: Fri, 11 Nov 88 15:27:15 EST
From: Scott.Fahlman@B.GP.CS.CMU.EDU


    Almost the only compromise I can think of is something that forces you
    to declare the non-portable loading intent in every use of REQUIRE, say:
     (REQUIRE "foo" :LOAD T)
    
    It would be useful to hear from someone other than the 3-4 of us who
    keep arguing this one.
    
OK.  I still think that the only reasonable course is to flush PROVIDE and
REQUIRE from the standard.  The discussions among those of you trying to
patch it up have only reinforced this view.  It didn't seem useful to keep
asserting this periodically, but that is my position until you hear
otherwise.  I suspect that many others share this view.

-- Scott

∂11-Nov-88  1339	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Nov 88  13:39:04 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA20009@EDDIE.MIT.EDU>; Fri, 11 Nov 88 16:36:51 EST
Received: by spt.entity.com (smail2.5); 11 Nov 88 14:29:22 EST (Fri)
To: sandra%defun@cs.utah.edu
Cc: Gray@DSG.csc.ti.com, jonl@LUCID.COM, pierson%mist@MULTIMAX.ENCORE.COM,
        cl-cleanup@SAIL.STANFORD.EDU, Bartley@mips.csc.ti.com
In-Reply-To: Sandra J Loosemore's message of Fri, 11 Nov 88 09:35:42 MST <8811111635.AA00216@defun.utah.edu>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
Message-Id: <8811111429.AA25742@spt.entity.com>
Date: 11 Nov 88 14:29:22 EST (Fri)
From: gz@spt.entity.com (Gail Zacharias)

   From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
   Date: Fri, 11 Nov 88 09:35:42 MST
   How about wording the proposal to indicate that implementations
   can extend REQUIRE to load files automagically only if the user has
   *explicitly* indicated (using some implementation-specific mechanism)
   which files make up that module?

Hey, I've got an idea!  How about
	 (REQUIRE module list-of-files-which-make-up-the-module) ?

But seriously, I'm not sure what "explicitly" means.  The user has to evaluate
some Lisp expression involving the module name?  What if the underlying
operating system provides some similar concept, is the Lisp allowed to use it
or would it still have to force the user to retype it in the Lisp?  How about
a search-path-based mechanims: is it ok if the user evaluates some Lisp
expression specifying a search path but not mentioning the module name
explicitly?  How about a default search path?  Is that allowed, or must it
start out empty regardless of local cultural conventions?  What about
vendor-provided modules?  Can we continue to tell our users to say (require
'quickdraw) and have that work in the off-the-shelf product, or would they
have to take some additional explicit action to allow this to work?

    but would prevent
       (require "FOO")
   from trying to load some random file named "FOO", which (as I've pointed
   out earlier), may or may not contain the module "FOO".

How about (REQUIRE "FOO" :if-not-present :error)?  Only half-kidding...

∂11-Nov-88  1421	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 11 Nov 88  14:20:45 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA02482; Fri, 11 Nov 88 17:18:01 EST
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA02053; Fri, 11 Nov 88 17:21:56 EST
Message-Id: <8811112221.AA02053@mist.UUCP>
To: gz%spt.entity.com@multimax.encore.com (Gail Zacharias)
Cc: cl-cleanup%SAIL.STANFORD.EDU@multimax.encore.com,
        Bartley%mips.csc.ti.com@Multimax.encore.com
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
In-Reply-To: Your message of Fri, 11 Nov 88 14:29:22 -0500.
             <8811111429.AA25742@spt.entity.com> 
Date: Fri, 11 Nov 88 17:21:53 EST
From: Dan L. Pierson <pierson@mist>

    But seriously, I'm not sure what "explicitly" means.  The user has
    to evaluate some Lisp expression involving the module name?  What
    if the underlying operating system provides some similar concept,
    is the Lisp allowed to use it or would it still have to force the
    user to retype it in the Lisp?  How about a search-path-based
    mechanims: is it ok if the user evaluates some Lisp expression
    specifying a search path but not mentioning the module name
    explicitly?  How about a default search path?  Is that allowed, or
    must it start out empty regardless of local cultural conventions?

This is a good examples of why most of us gave up on a portable
REQUIRE that loads files.

    What about vendor-provided modules?  Can we continue to tell our
    users to say (require 'quickdraw) and have that work in the
    off-the-shelf product, or would they have to take some additional
    explicit action to allow this to work?
    
If REQUIRE is removed from the standard language you can continue to
provide it as an implementation extension and tell your users anything
you want.  This would seem to be ideal for your example: "quickdraw"
sounds like an archtypical non-portable vendor provided module.  If
I'm going to use it, I don't care that the construct which obtains it
is non-standard.  (As I understand the status of other proposals, your
REQUIRE would have to be in a package other than LISP, but since the
default user package could use your extensions package, there would be
no visible change for most users.)

∂11-Nov-88  1431	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 11 Nov 88  14:30:57 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
	id AA10201; Fri, 11 Nov 88 15:23:58 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA00501; Fri, 11 Nov 88 15:22:48 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811112222.AA00501@defun.utah.edu>
Date: Fri, 11 Nov 88 15:22:46 MST
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
To: gz@spt.entity.com (Gail Zacharias)
Cc: sandra%defun@cs.utah.edu, Gray@DSG.csc.ti.com, jonl@LUCID.COM,
        pierson%mist@MULTIMAX.ENCORE.COM, cl-cleanup@SAIL.STANFORD.EDU,
        Bartley@mips.csc.ti.com
In-Reply-To: gz@spt.entity.com (Gail Zacharias), 11 Nov 88 14:29:22 EST (Fri)

Sigh, I really don't like the idea of having REQUIRE load things, but
I thought there was a compromise being reached here.  It appears that
isn't the case after all.

To summarize my position on this issue, the current definition of
REQUIRE is broken due to the way it tries to load files without
providing the user with any portable way to say which files should be
loaded.  (Passing a pathname as the second argument is not portable.)
It doesn't appear that we will be able to come up with a
DEFSYSTEM-like utility for specifying what files correspond with which
modules in the near future.  Therefore, I think the best solution
would be to either remove REQUIRE entirely, or just to get rid of its
file-loading behavior, whichever is the most acceptible to everybody else.

-Sandra
-------

∂11-Nov-88  1723	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Nov 88  17:23:18 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA23644@EDDIE.MIT.EDU>; Fri, 11 Nov 88 20:22:36 EST
Received: by spt.entity.com (smail2.5); 11 Nov 88 20:16:42 EST (Fri)
To: pierson@mist.encore.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: Dan L. Pierson's message of Fri, 11 Nov 88 17:21:53 EST <8811112221.AA02053@mist.UUCP>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
Message-Id: <8811112016.AA26928@spt.entity.com>
Date: 11 Nov 88 20:16:42 EST (Fri)
From: gz@spt.entity.com (Gail Zacharias)

   Date: Fri, 11 Nov 88 17:21:53 EST
   From: Dan L. Pierson <pierson@mist>
   If REQUIRE is removed from the standard language you can continue to
   provide it as an implementation extension and tell your users anything
   you want.

That's exactly right.  I have no objections to removing REQUIRE from the
language.  What I have problems with is leaving it in the language while (a)
breaking *all* current uses of it (since by definition (CLtL p.188) current
usage means loading) and (b) putting restrictions on the ability of
implementations to continue supporting current usage as an extension.

∂11-Nov-88  1810	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Nov 88  18:10:50 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 NOV 88 17:59:14 PST
Date: Fri, 11 Nov 88 17:59 PST
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
To: Scott.Fahlman@B.GP.CS.CMU.EDU
cc: cl-cleanup@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: The message of 11 Nov 88 12:27 PST from
 Scott.Fahlman@B.GP.CS.CMU.EDU
Message-ID: <19881112015907.4.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no


I too would still like to see REQUIRE and PROVIDE removed from the
language.  In my experience with PCL, they have never proved useful.
Worse, the fact that some people thought they were useful and kept
insisiting that I should use them has been annoying.
-------

∂13-Nov-88  1532	CL-Cleanup-mailer 	Issue: DELETE-NONEXISTENT-FILE (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Nov 88  15:32:36 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 491648; Sun 13-Nov-88 18:32:46 EST
Date: Sun, 13 Nov 88 18:32 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DELETE-NONEXISTENT-FILE (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881113183227.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

The enclosed proposal was distributed in hardcopy by Kathy at the
last X3J13 meeting. I just recently acquired electronic copy.
It happens that I don't think the writeup is clear and I don't
agree with the proposal, but I wanted to first get it into the
archives before discussing it. -kmp

-----
Issue:        DELETE-NONEXISTENT-FILE
References:   DELETE-FILE (p. 424)
Category:     CHANGE
Edit history: 5-OCT-88, Version 1 by Chapman


Problem Description:

An implementation determines whether an attempt to delete a nonexistent
file is considerd to be successful.

Proposal (DELETE-NONEXISTENT-FILE:RETURN-VALUE)

DELETE-FILE can currently return a non-nil value in the case of
success, or signal an error in the case of failure. The proposed change
is that DELETE-FILE return a non-nil value when the file exists and
is successfully deleted, nil when the file doesn't exist, and signals
an error otherwise.

Rationale:

This change allows users to portably depend on a return value when
DELETE-FILE is executed on a nonexistent file.

Current Practice:


Adoption Cost:

Minimal.

Benefits:

This change will assist users in writing portable code.

Conversion Cost:

Minimal.

Aesthetics:

None.

Discussion:

∂13-Nov-88  1534	CL-Cleanup-mailer 	Issue: FORMAT-ROUNDING (Version 1)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Nov 88  15:34:07 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 491649; Sun 13-Nov-88 18:34:11 EST
Date: Sun, 13 Nov 88 18:33 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-ROUNDING (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881113183353.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

Kathy distributed this in hardcopy at the last X3J13 meeting.
I'm agnostic on it for now, but wanted to get it into the
archives.  -kmp

-----
Issue:        FORMAT-ROUNDING
References:   FORMAT (p. 390)
Category:     CHANGE
Edit history: 5-OCT-88, Version 1 by Chapman


Problem Description:

For the ~F FORMAT directive, the implementation can either round up
or down when the rounding produces printed values equidistant from
the scaled value of the argument.  

Proposal (FORMAT-ROUNDING:SPECIFY)

Specify that the implementation rounds up when the rounding produces
printed values equidistant from
the scaled value of the argument.  

Rationale:

This change allows predictible results to occur when 
rounding occurs.

Current Practice:


Adoption Cost:

Mininal.

Benefits:

This clarification will assist users in writing portable code.

Conversion Cost:

Minimal.

Aesthetics:

None.

Discussion:

∂13-Nov-88  1833	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Nov 88  18:33:06 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA05643g; Sun, 13 Nov 88 18:02:39 PST
Received: by bhopal id AA19970g; Sun, 13 Nov 88 18:01:22 PST
Date: Sun, 13 Nov 88 18:01:22 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811140201.AA19970@bhopal>
To: pierson@mist.encore.COM
Cc: sandra%defun@cs.utah.edu, cl-cleanup@SAIL.STANFORD.EDU,
        Bartley@mips.csc.ti.com
In-Reply-To: Dan L. Pierson's message of Fri, 11 Nov 88 13:36:13 EST <8811111836.AA01642@mist.UUCP>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 

re: Once again, if you allow REQUIRE to load files it isn't portable and
    code written in implementations that support it will be harder to
    port (I haven't thought enough about the possible problems of going
    from a non-loading implementation to a loading implementation).
    If the feature isn't portable, why keep it in the language?  ...

Sorry to have to "chime in" again, but this goes to the crux of the
matter.  [Anyway, I think it's likely that only the four of us are
deeply concerned about the issue, and that if we can come to some
agreement amongst ourselves, then that will carry much weight with
the committee as a whole.  If the four us can't agree by deadline
time, then it's surely hopeless.]

David (Gray) suggested not that the standard allow REQUIRE to "load
files", but that an allowable extension be the interface to an
implementation-specific "defsystem", if one is available.  Thus he 
wants to reserve space for an interface, which in some implementations 
will just be an interface to the null feature!  A programmer who comes 
to depend on a given vendor's defsystem has a porting problem completely
independent of whether or not that vendor also made a non-portable
extension to REQUIRE.  [by the way, I use "DEFSYSTEM" to refer to this
interface, despite the fact that an entry from REQUIRE probably calls
"MAKE-SYSTEM; it's just that MAKE-SYSTEM is usuless without DEFSYSTEM.]

The advantage of this is that ***if*** one ports his code to a system
with a compatible defsystem, or ***if*** he ports his system specification
first, then the module-name interface in the one-argument version of
REQUIRE doesn't need any further porting.

On the other hand a truly _portable_ program must disable any defsystem
hooks.  I don't particularly mind if such disablement isn't standardized;
it all "comes with the territory" when you buy the big hamburger from a 
Lisp vendor.  Namely, the portable program writer has to figure out how to
configure his "hamburger" to have only the standardized, portable features,
in order to certify his work as portable.  And as we all agree, the only 
portable part of REQUIRE is the "safety net" part -- not the incestuous 
hook-in.  Remember FIXNUM-NON-PORTABLE!

Thus I'd rather add a new special-variable parameter with values T or
NIL than to force the step of backwards incompatibility on the current
REQUIRE users.  Many of these users are quite happy to see their
(REQUIRE "foo") simply load the file "foo" from the connected directory.
Forcing these people to go back and change all their code WHICH THEY
WOULD NEVER BE PORTING ANYWAY is not a guaranteed way to win friends and
influence people favorably towards this proposal.

Still, I don't see the situation as all that bad, because there really 
aren't that many programs around that are intended to be fully portable. 
[Of course, the coder of such ported programs may suffer complaints from
end-users who notice that he didn't hook into their own defsystem; but
we can at least take REQUIRE off this particular hot-seat.]  In fact, 
most Lisp users run on precisely one vendor's system, and could care 
less about full portability.  As some have suggested, what CL gives us 
is "portability of programmers" more than portability of particular
programs.

The "compromise", as I see it, is aimed a retaining a useful portable
meaning for REQUIRE, but not breaking existing code.  That is why we
have to say something about allowable, implementation-specific 
extensions, and how to disable them.



-- JonL --

∂13-Nov-88  2025	CL-Cleanup-mailer 	Issue: FORMAT-ROUNDING (Version 1)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Nov 88  20:25:05 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA05695g; Sun, 13 Nov 88 20:23:45 PST
Received: by bhopal id AA20085g; Sun, 13 Nov 88 20:22:28 PST
Date: Sun, 13 Nov 88 20:22:28 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811140422.AA20085@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Sun, 13 Nov 88 18:33 EST <881113183353.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-ROUNDING (Version 1)

I strongly oppose this change.

The choice to "Round Up" is counter to the choice for the ROUND function
on CLtL p.216, where "ties" are specified to round to the nearest even
integer.  It is counter to the general direction that CL should follow
IEEE conventions wherever possible. [Note that having "ties" do "Round
Up" is a unique property of VAX hardware -- there isn't even any IEEE
rounding mode that corresponds to it.]

According to CLtL, p390, the allegedly "unpredictable" results are in 
fact very predictable -- precisely one of two strings will be output, 
both of which are guaranteed to represent the number in question;
and there is no other possibility.  Narrowing the choice down to just 
one of these two strings serves no useful purpose, and may even cause 
some (very minimal) implementational difficulties for some machines.

But if we must choose between one of the two, I suggest we pick an
algorithm that follows the IEEE style rather than the VAX style.


-- JonL --


∂14-Nov-88  0620	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Nov 88  06:20:46 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 491797; Mon 14-Nov-88 09:19:30 EST
Date: Mon, 14 Nov 88 09:19 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
To: jonl@lucid.com
cc: pierson@mist.encore.COM, sandra%defun@cs.utah.edu,
    cl-cleanup@SAIL.STANFORD.EDU, Bartley@mips.csc.ti.com
In-Reply-To: <8811140201.AA19970@bhopal>
Message-ID: <881114091906.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

I think the key is in this concept of deprecation.

The problem Gregor has indicated is that REQUIRE's presence there
means he has to put up with people saying he shouldn't be writing
DEFSYSTEM stuff but rather should be using REQUIRE/PROVIDE since
``they wouldn't be there if you weren't intended to use them.''
I have to say I've run into this same attitude.

I think it's acceptable to retain the 1-argument case in the spec
for sake of compatibility, but that we should throw it into the
deprecated bin so that it's clear that its mere presence there is
not an endorsement.

∂14-Nov-88  0713	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; 14 Nov 88  07:13:22 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 491816; Mon 14-Nov-88 10:13:27 EST
Date: Mon, 14 Nov 88 10:13 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue GC-MESSAGES (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
References: <870423174645.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <881114101307.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

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

Problem Description:

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

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

Proposal (GC-MESSAGES:NEW-MACRO)

  Introduce a new macro WITH-GC-STATUS, described as follows:

    WITH-GC-STATUS (&key VERBOSE) &body forms

     Executes the body FORMS sequentially, as if by PROGN, returning the
     value(s) of the last form (or NIL if there were no FORMS).

      If :VERBOSE T is specified in the options list, the implementation
      is encouraged to provide some notice of any GC activity that occurs
      during the execution of the FORMS.
 
      If :VERBOSE NIL is specified in the options list, the implementation
      is discouraged from providing any notice of any GC activity that
      occurs during the execution of FORMS.
 
      If :VERBOSE :DEFAULT is specified (or if a :VERBOSE option is
      not supplied), then the implementation is neither encouraged nor
      discouraged from providing notice about any GC activity that occurs
      during the execution of FORMS.

     Implementations are permitted to extend this form to provide other,
     implementation-specific, GC-related keyword options.

      If :ALLOW-OTHER-KEYS T is specified, any unrecognized options will
      be ignored. For example,

	(WITH-GC-STATUS (:VERBOSE NIL
			 :ACME-GC-OPTION-17 T
			 :ALLOW-OTHER-KEYS T)
	  ...)

      might select GC Option #17 in ACME Common Lisp, but in other Common
      Lisp implementations (where that option presumably would not exist),
      the keyword would be ignored.

      If :ALLOW-OTHER-KEYS NIL is specified (or if the :ALLOW-OTHER-KEYS
      option is not supplied), then an error will be signalled if the
      implementation does not recognize all options in the options list.

Rationale:

  This facility addresses the stated problem in a straightforward way.

Current Practice:

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

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

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

Adoption Cost:

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

Benefits:

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

Conversion Cost:

  This is an upward compatible change.

Aesthetics:

  No significant impact.

Discussion:

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

  Version 1 of this proposal did not fly because it proposed a variable to
  control the behavior, and some people were not convinced that a simple
  variable would be powerful enough in all cases -- some feared a function
  call might be needed to toggle the state. This rewrite addresses those
  concerns.

  Pitman supports this proposal.

∂14-Nov-88  0852	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 14 Nov 88  08:52:31 PST
Received: from fafnir.think.com by Think.COM; Mon, 14 Nov 88 11:30:37 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 14 Nov 88 11:49:32 EST
Received: from joplin.think.com by verdi.think.com; Mon, 14 Nov 88 11:49:31 EST
Received: by joplin.think.com; Mon, 14 Nov 88 11:49:27 EST
Date: Mon, 14 Nov 88 11:49:27 EST
From: gls@Think.COM
Message-Id: <8811141649.AA10899@joplin.think.com>
To: Gregor.pa@xerox.com
Cc: Scott.Fahlman@b.gp.cs.cmu.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Gregor.pa@xerox.com's message of Fri, 11 Nov 88 17:59 PST <19881112015907.4.GREGOR@PORTNOY.parc.xerox.com>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 

   Date: Fri, 11 Nov 88 17:59 PST
   From: Gregor.pa@xerox.com
   Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
   Line-Fold: no


   I too would still like to see REQUIRE and PROVIDE removed from the
   language.  In my experience with PCL, they have never proved useful.
   Worse, the fact that some people thought they were useful and kept
   insisiting that I should use them has been annoying.
   -------


I would be happy to see PROVIDE and REQUIRE flushed.  The biggest
problem is coming up with a new mnemonic sentence.  I propose
"Insert Some Extremely Useless Interface Commands".  Doesn't quite
have the kick of the original, though.
--Guy

∂14-Nov-88  0919	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Nov 88  09:19:36 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 491941; Mon 14-Nov-88 12:12:20 EST
Date: Mon, 14 Nov 88 12:11 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
To: gls@Think.COM
cc: Gregor.pa@xerox.com, Scott.Fahlman@b.gp.cs.cmu.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: <8811141649.AA10899@joplin.think.com>
Message-ID: <19881114171153.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: Mon, 14 Nov 88 11:49:27 EST
    From: gls@Think.COM

    I would be happy to see PROVIDE and REQUIRE flushed.  The biggest
    problem is coming up with a new mnemonic sentence.  I propose
    "Insert Some Extremely Useless Interface Commands".  Doesn't quite
    have the kick of the original, though.

The combination of several pending cleanup proposals should eliminate
entirely the need for any variant of that mnemonic sentence.

∂14-Nov-88  1212	CL-Cleanup-mailer 	Issue: FORMAT-ROUNDING (Version 1)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Nov 88  12:12:31 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 492150; Mon 14-Nov-88 15:12:40 EST
Date: Mon, 14 Nov 88 15:12 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-ROUNDING (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881113183353.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881114201233.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

I agree with JonL's comment that IEEE round-to-nearest, rather
than round-towards-plus-infinity, should be used.  Of course IEEE
doesn't deal with decimal rounding, but the obvious analogy to
binary rounding should be employed.

I doubt that it's appropriate to say anything about this in the
standard, though, since Common Lisp leaves all other aspects of
floating-point rounding to the implementation's discretion.

∂14-Nov-88  1224	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3)   
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 14 Nov 88  12:23:51 PST
Received: from snail.Sun.COM by Sun.COM (4.0/SMI-4.0)
	id AA24721; Mon, 14 Nov 88 12:19:40 PST
Received: from denali.sun.com by snail.Sun.COM (4.0/SMI-4.0)
	id AA19402; Mon, 14 Nov 88 12:21:42 PST
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
	id AA19640; Mon, 14 Nov 88 11:43:48 PST
Message-Id: <8811141943.AA19640@denali.sun.com>
To: gls@Think.COM
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 
In-Reply-To: Your message of Mon, 14 Nov 88 11:49:27 -0500;
	<8811141649.AA10899@joplin.think.com> .
Date: Mon, 14 Nov 88 11:43:46 -0800
From: peck@Sun.COM

>I would be happy to see PROVIDE and REQUIRE flushed.  The biggest
>problem is coming up with a new mnemonic sentence.  I propose
>"Insert Some Extremely Useless Interface Commands".  Doesn't quite
>have the kick of the original, though.

How about "Use DEFPACKAGE as appropriate"?

∂14-Nov-88  1347	CL-Cleanup-mailer 	more to do with DEFPACKAGE than with REQUIRE-PATHNAME-DEFAULTS    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 14 Nov 88  13:47:32 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00449g; Mon, 14 Nov 88 13:39:48 PST
Received: by bhopal id AA21540g; Mon, 14 Nov 88 13:38:32 PST
Date: Mon, 14 Nov 88 13:38:32 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811142138.AA21540@bhopal>
To: gls@Think.COM
Cc: Gregor.pa@xerox.com, Scott.Fahlman@b.gp.cs.cmu.edu,
        cl-cleanup@sail.stanford.edu
In-Reply-To: gls@Think.COM's message of Mon, 14 Nov 88 11:49:27 EST <8811141649.AA10899@joplin.think.com>
Subject: more to do with DEFPACKAGE than with REQUIRE-PATHNAME-DEFAULTS

re: I would be happy to see PROVIDE and REQUIRE flushed.  The biggest
    problem is coming up with a new mnemonic sentence.  . . . 

The main reason I like keeping, at least, the "safety net" version of
REQUIRE in the standard is so that one can "call a halt" if a file is
*** about to be loaded *** but the packages which it depends on are not
yet set up.  Some problems with delayed package creation can be so
severe as to be almost intractable.  See the DEFPACKAGE proposal for
deatils.

Good standard practice would be to have a file of package and interface
creations, which PROVIDEs the "setup" module; and then every other file
would have, say, a (REQUIRE "phlogistion-setup") near the beginning.
Admittedly there is much less need for a user to remember the mnemonic
if he sticks just to this discipline; but of course lots of wizards will
not only want to "roll their own", but will demand to know what is going
on.  The Discussion section of the DEFPACKAGE proposal offers a new
mnemonic, based on the ordering constraints derived therein:

  It has been suggested that the "Put IN Seven EXtremely Random USEr
  Interface COmmands" mnemonic described in CLtL p.191 could be removed;
  and with possibly a few exceptions, the special handling of them by
  COMPILE-FILE could be removed.  As this would be an incompatible change, 
  it is not part of this proposal.  However, a new mnemonic can be offered, 
  to help remember the ordering constraints mentioned above:
	    I REmember Six USEr Interface Expressions
  Each word in the sentence corresponds to one operation listed below:
     I				IN-PACKAGE	;"foot" to stand on
     REmember			REQUIRE		;ensure pre-requisite packages
     Six			SHADOW		;block multiple-inheritances
     USEr			USE-PACKAGE	;go for it!
     Interface			IMPORT		;bring in "foreign" symbols
     EXpressions		EXPORT		;a "face" to show to others.


-- JonL --


∂14-Nov-88  1416	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Nov 88  14:16:21 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 492279; Mon 14-Nov-88 17:16:09 EST
Date: Mon, 14 Nov 88 17:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8811102126.AA06710@bhopal>
Message-ID: <19881114221549.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 10 Nov 88 13:26:05 PST
    From: Jon L White <jonl@lucid.com>

    Your alternative syntax #1 is clearly superior to all the others.  Could 
    you take the time to alter the proposal accordingly, and at the same time 
    fix the typo "available" into "accessible"? [and also proof read the 
    whole proposal again?]

Before I take the time to do that...

    Alternative #2 is unacceptable, because it presumes that filtering a
    DO-ALL-SYMBOLS is a reasonable implementation of DO-EXTERNAL-SYMBOLS.  
    In fact, in Lucid Common Lisp, the situation is much more complex; the 
    "filtering" step could, in extreme circumstances, become pragmatically 
    unworkable, whereas the native implementation has no trouble.

...could you explain why the syntax should be made more complicated to
deal with the special needs of a particular implementation?  It might be
that I don't understand just what these pragmatic unworkablenesses are,
and don't understand whether they are peculiar to Lucid or more general.
However, my immediate inclination is to suggest that Lucid's
implementation of WITH-PACKAGE-ITERATOR should check for and optimize
cases that look like

  (WITH-PACKAGE-ITERATOR (next-symbol package)
     ...
     (MULTIPLE-VALUE-BIND (valid symbol flag) (next-symbol)
       (WHEN valid
	 (WHEN (EQ flag :EXTERNAL)
           ...))))

Of course you don't want to look for that one particular source pattern,
what you want to look for is cases where no side-effects are affected by
suppressing returning of the internal symbols.

This is a somewhat complicated optimization but surely well within the
capabilities of Lucid's compiler writers.

Also, MLY had a good suggestion, which was that instead of having
special cases for one package and all packages, the macro should simply
accept a list of packages.  An implementation can of course recognize
and treat as a special case forms such as
  (WITH-PACKAGE-ITERATOR (next-symbol (LIST-ALL-PACKAGES)) ...)
and forms such as
  (WITH-PACKAGE-ITERATOR (next-symbol (LIST package)) ...)
We could also allow a single package in place of a list if we think that
convenience is worthwhile; USE-PACKAGE is a precedent for this.  This
eliminates the oddity of the optional argument that you omit to tell it
to do all packages.

If we adopt this suggestion I will feel better about having keyword
arguments for which symbols to access, although I still feel the simpler
syntax with no options is preferable unless you can show me that Lucid's
needs outweigh the desire for syntactic simplicity.

∂14-Nov-88  1448	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 5) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Nov 88  14:47:56 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 NOV 88 14:35:26 PST
Date: 14 Nov 88 14:35 PST
From: masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 5)
To: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: Masinter.pa@Xerox.COM
Message-ID: <881114-143526-2232@Xerox>

I attempted to shorten the discussion section while at the same time be more explicit that there were some serious objections to it. I wound up cutting a lot of it out. Do you think I should put it back in?


!
Issue:         FUNCTION-TYPE-REST-LIST-ELEMENT
References:    CLtL p. 27, 47-48, 61
               "Artifical Intelligence Programming", Charniak et. al.
               X3J13/86-003 (A:>GLS>clarifications.text.4)
Category:      CLARIFICATION, ADDITION
Edit history:  Version 1, 23-Nov-1987 Sandra Loosemore
               Version 2, 15-Jan-1988 Sandra Loosemore
	           (incorporate comments from Scott Fahlman & others)
               Version 3, 13-Feb-88 Masinter
               Version 4,  2-Oct-88 Masinter (update references, discussion)
               Version 5, 14-Nov-88 Masinter (add to discussion)
Related issues: FUNCTION-TYPE-KEY-NAME, 
                FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
                REST-LIST-ALLOCATION

Problem description:

The FUNCTION type specifier list is provided to allow declaration of function argument types and return value types.  This type specifier uses a syntax similar to the usual lambda list syntax to specify which types go with which lambda list variables.  However, this is actually of limited usefulness in the context of a declaration, where one normally wants type information about the actual arguments which can be passed to the function rather than the lambda variables to which they are bound.

There is a particular problem with &REST lambda variables, which are always bound to a value of type LIST.  For the sake of consistency, it would seem that the corresponding type given in the FUNCTION declaration must also be LIST, but since this provides no information about the actual arguments, some users/implementors have instead adopted the convention of supplying the type of the actual arguments which are gathered into the list.  

CLtL is vague on the issue, mentioning only that &REST may appear in the type specifier without touching upon its interpretation.

Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE):

Clarify that, in the FUNCTION type specifier, the type specifier provided with &REST is the type of each actual argument, not the type of the corresponding lambda variable.

Example:

The type of the function + would be specified as:

(FUNCTION (&REST NUMBER) NUMBER)

Rationale:

This is more useful than specifying that the type of a &REST parameter must be LIST, since it provides information about the actual arguments.

Current practice:

There does not appear to be any concensus on this issue.  Most Common Lisp implementations currently ignore FUNCTION type declarations. The only examples found so far are in a text book on Common Lisp, which follows the proposed syntax.

Cost to Implementors:

Implementations that ignore the FUNCTION type specifier may continue to do so.  Probably only a small amount of code would have to be written/changed in implementations that currently think that the  &REST argument should be LIST.

Cost to Users:

Users who have been using the convention that the &REST type parameter must be LIST will have to change their code.  However, because this issue is so unclear, the FUNCTION type specifier is probably not used very much.

Cost of non-adoption:

If nothing is done, the FUNCTION type specifier will continue to be of limited use for its intended purpose.

Benefits:

Adopting the proposal will clear up an area of confusion in the language design.

Esthetics:

Debatable.  One the one hand, since the argument type syntax used by the FUNCTION type specifier mirrors normal lambda-list syntax, it would be cleaner and less confusing to provide the type of the lambda variable rather than the type of the actual arguments. However, considering the types specified in the FUNCTION specifier to be the types of the actual arguments rather than the types of the parameters as seen on the receiving end makes the proposed semantics more palatable.

Discussion:

This issue provoked considerable debate in the cleanup committee and at X3J13. 

Many people objected to this proposal, and would prefer the alternative that the type given after a &REST in a function declaration apply to the value of the formal parameter rather than the actual arguments. This would be even more useful if complex LIST type specifiers were part of Common Lisp (as the proposal in issue LIST-TYPE-SPECIFIER might add) or if it were possible to declare, for example, &REST {keyword integer}*.

Some additional arguments against this proposal are the apparent mismatch between the external declarations of type and the internal ones. It might be that this proposals presumes that rest lists are always lists, and the following is illegal:

 (DEFUN FOO (&REST X) X)
 (APPLY #'FOO T)

which is not otherwise explicitly forbidden, but for which there is no legitimate declaration.

∂14-Nov-88  1529	CL-Cleanup-mailer 	RE: Issue: HASH-TABLE-ACCESS (version 2) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Nov 88  15:29:23 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 NOV 88 14:57:56 PST
Date: 14 Nov 88 14:57 PST
From: masinter.pa@Xerox.COM
Subject: RE: Issue: HASH-TABLE-ACCESS (version 2)
In-reply-to: vanroggen%aitg.DEC@decwrl.dec.com's message of Mon, 17 Oct 88
 17:16:05 PDT
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881114-145756-2292@Xerox>

I think we need a new version of this proposal that spells out the answers
to the questions that arose in response to version 2. If things are not
specified, give the reason for not specifying them; if the return values
are implementation-dependent, give that as well.

The value of HASH-TAbLE-REHASH-SIZE and HASH-TAbLE-REHASH-THRESHOLD are
implementation dependent, and guaranteed to be greater than or equal to the
values given to MAKE-HASH-TABLE, and idempotent, in that if you make a hash
table with the same values as a given hash table then the -REHASH-SIZE and
-REHASH-THRESHOLD of the newly created one will be the same as the input
values. (This says that they may be thresholded upward in some
implementation-dependent-manner.)

HASH-TABLE-SIZE should be greater than or equal to the count of things
MAPHASH would iterate over, and HASH-TABLE-TEST will return one of the
symbols EQ EQL EQUAL (or, if HASH-TABLE-TESTS passes, EQUALP), even if #'EQ
#'EQUAL #'EQL are given.

Normally implementation-dependent-extensions are explicitly discouraged;
I'm no longer sure at the momemnt whether PACKAGE-CLUTTER would explicilty
disallow such extensions unless they are explicitly allowed, but we should
be cautious in throwing around phrases like "might be
  reasonable implementation-dependent extensions" if we don't mean it. I
would take that out, actually.

Walter, as you are the author of this, I'll ask you first to produce a
revision. Will you?


∂14-Nov-88  1529	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Nov 88  15:29:36 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 NOV 88 15:21:35 PST
Date: 14 Nov 88 15:21 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Mon, 19 Sep 88 18:39 EDT
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <881114-152135-2356@Xerox>

David:

Let me encourage you to avoid feeling provoked by JonL's reaction to this
issue, and find the time to produce a slightly modified version of the
proposal which is a little more specific about the issues raised: eliminate
the "component" language in the definition except as a description of
intent (for EQUAL tables, what is a component might be different than for
EQUALP tables), change the "is an error to modify" language to be more
specific in saying that the value of subsequent GETHASH calls *on that key*
might be affected.

Please?

Larry



∂14-Nov-88  1601	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 5) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Nov 88  16:01:14 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 NOV 88 15:45:43 PST
Date: 14 Nov 88 15:45 PST
From: masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 5)
To: cl-cleanup@sail.stanford.edu
Message-ID: <881114-154543-2415@Xerox>


This version should arrive with line breaks.

!
Issue:         FUNCTION-TYPE-REST-LIST-ELEMENT
References:    CLtL p. 27, 47-48, 61
               "Artifical Intelligence Programming", Charniak et. al.
               X3J13/86-003 (A:>GLS>clarifications.text.4)
Category:      CLARIFICATION, ADDITION
Edit history:  Version 1, 23-Nov-1987 Sandra Loosemore
               Version 2, 15-Jan-1988 Sandra Loosemore
	           (incorporate comments from Scott Fahlman & others)
               Version 3, 13-Feb-88 Masinter
               Version 4,  2-Oct-88 Masinter (update references,
discussion)
               Version 5, 14-Nov-88 Masinter (add to discussion)
Related issues: FUNCTION-TYPE-KEY-NAME, 
                FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
                REST-LIST-ALLOCATION

Problem description:

The FUNCTION type specifier list is provided to allow declaration of
function argument types and return value types.  This type specifier uses a
syntax similar to the usual lambda list syntax to specify which types go
with which lambda list variables.  However, this is actually of limited
usefulness in the context of a declaration, where one normally wants type
information about the actual arguments which can be passed to the function
rather than the lambda variables to which they are bound.

There is a particular problem with &REST lambda variables, which are always
bound to a value of type LIST.  For the sake of consistency, it would seem
that the corresponding type given in the FUNCTION declaration must also be
LIST, but since this provides no information about the actual arguments,
some users/implementors have instead adopted the convention of supplying
the type of the actual arguments which are gathered into the list.  

CLtL is vague on the issue, mentioning only that &REST may appear in the
type specifier without touching upon its interpretation.

Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE):

Clarify that, in the FUNCTION type specifier, the type specifier provided
with &REST is the type of each actual argument, not the type of the
corresponding lambda variable.

Example:

The type of the function + would be specified as:

(FUNCTION (&REST NUMBER) NUMBER)

Rationale:

This is more useful than specifying that the type of a &REST parameter must
be LIST, since it provides information about the actual arguments.

Current practice:

There does not appear to be any concensus on this issue.  Most Common Lisp
implementations currently ignore FUNCTION type declarations. The only
examples found so far are in a text book on Common Lisp, which follows the
proposed syntax.

Cost to Implementors:

Implementations that ignore the FUNCTION type specifier may continue to do
so.  Probably only a small amount of code would have to be written/changed
in implementations that currently think that the  &REST argument should be
LIST.

Cost to Users:

Users who have been using the convention that the &REST type parameter must
be LIST will have to change their code.  However, because this issue is so
unclear, the FUNCTION type specifier is probably not used very much.

Cost of non-adoption:

If nothing is done, the FUNCTION type specifier will continue to be of
limited use for its intended purpose.

Benefits:

Adopting the proposal will clear up an area of confusion in the language
design.

Esthetics:

Debatable.  One the one hand, since the argument type syntax used by the
FUNCTION type specifier mirrors normal lambda-list syntax, it would be
cleaner and less confusing to provide the type of the lambda variable
rather than the type of the actual arguments. However, considering the
types specified in the FUNCTION specifier to be the types of the actual
arguments rather than the types of the parameters as seen on the receiving
end makes the proposed semantics more palatable.

Discussion:

This issue provoked considerable debate in the cleanup committee and at
X3J13. 

Many people objected to this proposal, and would prefer the alternative
that the type given after a &REST in a function declaration apply to the
value of the formal parameter rather than the actual arguments. This would
be even more useful if complex LIST type specifiers were part of Common
Lisp (as the proposal in issue LIST-TYPE-SPECIFIER might add) or if it were
possible to declare, for example, &REST {keyword integer}*.

Some additional arguments against this proposal are the apparent mismatch
between the external declarations of type and the internal ones. It might
be that this proposals presumes that rest lists are always lists, and the
following is illegal:

 (DEFUN FOO (&REST X) X)
 (APPLY #'FOO T)

which is not otherwise explicitly forbidden, but for which there is no
legitimate declaration.

∂14-Nov-88  1601	CL-Cleanup-mailer 	Re: issue HASH-TABLE-PRINTED-REPRESENTATION   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Nov 88  16:01:24 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 NOV 88 15:50:21 PST
Date: 14 Nov 88 15:50 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue HASH-TABLE-PRINTED-REPRESENTATION
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
 Tue, 18 Oct 88 09:42:19 MDT
To: cl-cleanup@sail.stanford.edu, Dave.Touretzky@B.GP.CS.CMU.EDU
Message-ID: <881114-155021-2429@Xerox>

Dave's last message is that he doesn't have any revisions to make. If there
is going to be a version 3, someone will have to produce it, right?

Volunteer?

We have only a short time to get a large number of issues resolved enough
to put them into votable form. If we don't get them into votable form, we
may have to drop them entirely.


∂14-Nov-88  1601	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Nov 88  16:01:05 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 NOV 88 15:33:01 PST
Date: 14 Nov 88 15:32 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Mon, 14 Nov 88 17:15 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Jon L White <jonl@lucid.com>, cl-cleanup@sail.stanford.edu
Message-ID: <881114-153301-2381@Xerox>

Frankly, although option #2 with filtering looks like it is simpler --
certainly the syntax description is shorter -- I think option #1, where you
spell out more explicitly the kind of iteration you want to do, looks like
it is easier to understand.

So I would vote for option #2 over option #1 even without some special
Lucid-specific circumstances.


The writeup should reference issue DO-SYMBOL-DUPLICATES which passed. 


∂14-Nov-88  1619	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-TESTS (Version 1)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Nov 88  16:18:50 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 NOV 88 16:10:18 PST
Date: 14 Nov 88 16:09 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: HASH-TABLE-TESTS (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881114-161018-2472@Xerox>

I am less at ease about adding = and STRING= than I am about EQUALP.
Certainly many other test functions could be added. However, given that we
are only going to require a limited set, which ones should be required?

So, why don't we leave the proposal as is, and merely note in the
discussion that these extensions are also a possibility but not included in
this proposal. 

Editorial notes: the description again says "vendor" for "implementor".
Rather than arguing whether = is more "major" than EQUALP, it might be
simpler to remove the claim that the proposal "Makes hash tables usable
with the major, remaining equivalence predicate" and stick to "Makes hash
tables more useful."

Change 'as a "side effect"' to "as a side benefit". 


∂14-Nov-88  1844	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Nov 88  18:44:30 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 492501; Mon 14-Nov-88 21:43:53 EST
Date: Mon, 14 Nov 88 21:43 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)
To: masinter.pa@Xerox.COM
cc: Jon L White <jonl@lucid.com>, cl-cleanup@sail.stanford.edu
In-Reply-To: <881114-153301-2381@Xerox>
Message-ID: <19881115024345.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 14 Nov 88 15:32 PST
    From: masinter.pa@Xerox.COM

    Frankly, although option #2 with filtering looks like it is simpler --
    certainly the syntax description is shorter -- I think option #1, where you
    spell out more explicitly the kind of iteration you want to do, looks like
    it is easier to understand.

Are you sure you really mean that?  Option 1 is the same as option 2 except
that it offers a bunch of additional features, so how can it be simpler?
Or to put it another way, option 1 is the same as option 2 except that you
write some of the control structure of your program in a special language
instead of Lisp.

    So I would vote for option #2 over option #1 even without some special
    Lucid-specific circumstances.

Oh, okay, so actually you think option 2 is easier to understand.

    The writeup should reference issue DO-SYMBOL-DUPLICATES which passed. 

Noted.

∂15-Nov-88  1140	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)  
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 15 Nov 88  11:39:49 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA25709; Tue, 15 Nov 88 14:38:33 EST
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA06734; Tue, 15 Nov 88 14:42:28 EST
Message-Id: <8811151942.AA06734@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax.encore.com
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)
Date: Tue, 15 Nov 88 14:42:25 EST
From: Dan L. Pierson <pierson@mist>

The user impact and discussion have been rewritten.
Bugs in current practice have been fixed.
The proposal itself is unchanged (eliminate).

Issue:         REQUIRE-PATHNAME-DEFAULTS
References:    *MODULES*, PROVIDE, REQUIRE, pp 188-191
               LOAD, pp 426-427
Category:      CHANGE
Edit history:  Version 1 by Pierson 9/13/88
               Version 2 by Pierson 9/19/88, change PROVIDE stuff per comments
               Version 3 by Pierson 10/17/88, remove PROVIDE locaction specs.
	       Version 4 by Pierson 10/31/88, remove from language
               Version 5 by Pierson 11/15/88, cleanup, fix discussion
Status:        Ready For Release

Problem description:

PROVIDE and REQUIRE are a dual-purpose pair of functions that attempt
to provide multi-file Common Lisp programs with a single mechanism to
detect and correct incorrect load sequences.  These functions were
also designed to be used for general file inclusion in Common Lisp.
Unfortunately, the file loading feature of REQUIRE is specified such
that it is inherently non-portable and environment dependent.

Proposal (REQUIRE-PATHNAME-DEFAULTS:ELIMINATE):

Remove PROVIDE and REQUIRE from the Common Lisp standard.

Test Cases/Examples:

(PROVIDE 'fft)

Would not be Common Lisp.

(REQUIRE 'fft)

Would not be Common Lisp.

Rationale:

The file loading feature of REQUIRE is non-portable.  The remaining
functionality of PROVIDE and REQUIRE (pushing and testing *MODULES*)
can easily be implemented by user code.  Since some implementations
will retain the automatic module loading features of REQUIRE and some
won't, use of REQUIRE will almost always make code less portable.

Current practice:

All implementations currently support some sort of file loading via
single-argument REQUIRE.  In general, the Lisp Machine implementations
invoke the system module building/loading facility while the Unix
implementations simply try to load a file in the current directory.

Cost to Implementors:

Implementations will have to move PROVIDE and REQUIRE to their package
for implementation extensions and change their documentation to
indicate that PROVIDE and REQUIRE are non-standard.  This is a fairly
small change.

Cost to Users:

Non-portable programs that rely on PROVIDE and REQUIRE will probably
be unaffected since implementations will probably maintain their
existing functionality.  Since the current behavior is decidedly
non-portable, portable programs have to aviod or special-case PROVIDE
and REQUIRE anyway.

Cost of non-Adoption:

PROVIDE and REQUIRE will continue as impediments to portability.

Benefits:

The non-portability of PROVIDE and REQUIRE will be made obvious.

Aesthetics:

This simplifies the language by removing an environment-dependent
feature. 

Discussion:

The cleanup committee tried to come up with a proposal to restrict
PROVIDE and REQUIRE to the portable subset of their functionality.
This failed because several implementors objected that it compelled
them to significantly reduce the functionality they provided users in
order to create a trivial feature which any user could easily write
for herself.

Fahlman, Gregor, Grey, Loosemore, Moon, Pierson, Pitman, Steele, and
Zacharias have expressed support for removing PROVIDE and REQUIRE from
the language, at least as the lesser of several evils.

JonL would much rather see PROVIDE and REQUIRE remain in the language
as a safety net behind any implementation-specific system building
facility.  Pierson likes the safety net idea, but doesn't think it's
workable without forbidding REQUIRE from loading files.

Pitman suggested that PROVIDE and REQUIRE should be depricated rather
than removed entirely.  Pierson agrees, but notes that Larry wants us
to deal with deprication versus elimination as a separate global topic.

Several people have expressed a desire not to break existing user
code.  If accepted, this proposal should not break existing code
because all implementations are expected to retain their current
PROVIDE and REQUIRE functionality as an extension to Common Lisp.


∂15-Nov-88  1309	CL-Cleanup-mailer 	Issue: WITH-DYNAMIC-EXTENT (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Nov 88  13:09:00 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 492913; Tue 15-Nov-88 16:08:59 EST
Date: Tue, 15 Nov 88 16:08 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: WITH-DYNAMIC-EXTENT (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881115160845.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

I got tired of having this lone piece of paper sitting on my desk with no
electronic version, so finally typed it in. Please encourage people who
submit hardcopy cleanup items to follow them up with electronic mail!

Please don't take my having done the typing as an endorsement; my commentary
will come under separate cover.
 -kmp

-----
Issue:	      WITH-DYNAMIC-EXTENT
References:   CLtL p. 39, p. 162
Category:     ENHANCEMENT
Edit History: 9-Oct-88, Version 1 by Jim Allard

Problem Description:

Users of Common Lisp cannot write programs which explicitly perform their
own memory management and do not rely on a garbage collector.

Proposal:

Introduce two new macros: WITH-DYNAMIC-EXTENT and WITH-INDEFINITE-EXTENT.

Add to the end of chapter 9, p. 162, the new section "Extent Declarations".

"By default, data objects within Common Lisp programs have indefinite extent
and so continue to exist as long as a possibility of reference to them exists.
Implementations are free to reclaim (garbage collect) any objects for which it
can be proven that no possible references exist. The following macros provide
programmers the ability to declare extra information about the extent of data
objects.

	with-dynamic-extent {form}*

The forms of the body are executed as an implicit PROGN and the values of the
last form in the body are returned. This macro declares that the objects
created within the dynamic extent of the body forms (but which are not further
nested within WITH-INDEFINITE-EXTENT forms) have dynamic extent, and may be
reclaimed on exit from this form. Note that the extent of any object created
within the dynamic extent of a further nested WITH-DYNAMIC-EXTENT form is
determined by the deepest nested call. This macro represents a guarantee by the
programmer that no objects created within the body will be referenced outside of
the body. The behavior of a reference to one of these objects outside the
dynamic extent is undefined.

	with-indefinite-extent {form}*

The forms of the body are executed as an implicit PROGN and the values of the
last form in the body are returned. This macro declares that the objects
created within the dynamic extent of the body forms (but which are not further
nested within WITH-DYNAMIC-EXTENT forms) have indefinite extent, and so may only
be reclaimed when it can be proven that no references exist to these objects.
This is the default behavior."

Add to p.39 after "The important scope and extent rules of Common Lisp follow:"

"* Data objects have indefinite extent, except when created within the dynamic
extent of a WITH-DYNAMIC-EXTENT form, in which case they may have dynamic
extent."

Rationale:

Lisp has always had automatic memory management as one of its features,
shielding the programmer from issues of memory usage and reclamation and
treating the machine as an abstraction. Several sophisticated garbage collection
techniques have been developed which lessen the impact of memory management on
performance. However, the wait times and larger memory requirements imposed by
garbage collection in most implementations of Lisp are still two of the biggest
practical problems faced when fielding Lisp programs. The problem becomes even
more serious when attempting to write real-time applications in Lisp.

Most widely used computer languages today require programmers to manage
their own data structures. In Common Lisp this is not currently
possible, since implementations are free to cons and discard objects at
will. This is especially true of the arithmetic functions. Most
implementations happen to be good about not unnecessarily consing, and
with careful use of a subset of Common Lisp, one can resource manage all
objects other than numbers. With the addition of these two macros and
mutation operations for the required subtypes of number, it becomes
possible to write garbage-free Lisp code.

Even in those applications where all garbage will not be eliminated,
optimization of specific parts of a program which are known to be producers of
large temporary data structures can greatly increase overall performance.

Current Practice:

Many vendors currently supply some form of facility which will reclaim allocated
memory outside of normal garbage collection. On Lisp machines, the temporary
are facility provides the ability to clear a region of memory on command. Some
vendors of Lisps for conventional architectures have produced the above facility
for customers who have requested it.  Some vendors have used it themselves in
their own compiler programs.  The response to this problem in general has been
to improve garbage collector performance rather than provide facilities to
reduce or eliminate the need for them. Users of Common Lisp have either
resigned themselves to the performance needs of the garbage collector, have
tried to tailor their garbage creation patterns to best fit the existing garbage
collector, or have ported to other languages, such as C, which support explicit
memory management. This facility would be an added tool for the second
approach, tailoring garbage creation patterns.

Adoption Cost:

Since the facility is a declaration, Common Lisp vendors may choose to not
implement any portion of this facility, and have the macros expand as PROGNs.
Vendors also have the choice of determining which types of Lisp objects
could have dynamic extent. Those vendors who already have an areas-like
facility would not have significant additional work to do in the object
allocation facilities. If a system depends upon keeping objects of different
types within different pages, then the task is somewhat complicated, but most
vendors can use an implementation where dynamic extent objects are allocated
into a special region of memory whose allocation pointer is reset on exit from
WITH-DYNAMIC-EXTENT back to where it was on entry to the form. Garbage
collectors may have to be modified to scan this region for pointers, but should
not evacuate it. Vendors will also have to evaluate how each type with dynamic
extent would affect other facilities in the system. See the discussion for more
details.

Benefits:

This facility allows programmers to exert greater control over the garbage
creation properties of their programs. Though automatic memory management is
one of the nicest facilities for programmers in Lisp, the performance penalty of
garbage collection is one of the biggest barriers to end user acceptance of Lisp
programs. Though improvements have been made in garbage collector technology in
the 80's, not all vendors will be able to adopt these techniques, and not all
application programmers will be able to accept even the modest loss of
performance imposed by modern garbage collection methods. The reclamation of
garbage objects at or near the source of their creation makes it possible to
reduce or eliminate this problem.

Conversion Cost:

Since this is a new facility, no currently existing Common Lisp code would be
affected.

Aesthetics:

Questionable. Though the facility fits well as an added type of extent for Lisp
objects, it can be rightly criticized as a dangerous facility when used
incorrectly. However, it does directly address a problem of garbage creation in
an efficient and consistent manner. This facility can cause data corruption in
much the same way as an incorrect type declaration. Though we do not want to
offer users invitations to hang themselves, we also do not need to treat them
like children.

Discussion:

This facility needs to be discussed in terms of the CLtL functions which mutate
data structures or cache consed data and depend on those values later on. The
problems which can arise here should be addressed per implementation by choosing
which types of objects may have dynamic extent, and choosing which operations
should signal errors when performed within a dynamic extent context.

The facilities for which this system does not have an obvious meaning are the
following: hash table mutation, readtable mutation, package mutation, stream
operations, random number generation, error signalling, and defining forms which
have side effect upon the environment. The following example illustrates the
problems which can arise in given facilities.

Say we have an implementation where streams and strings are allowed to have
dynamic extent. A user wishes to write a program which reads and processes
files. The user wants the file access portion of the program to not create
garbage and not require large amounts of memory. The user's program takes on
the following structure.

(defun process-file (pathname)
  (with-dynamic-extent
    (with-open-file (input pathname)
      (block read-file
	(loop
	  (with-dynamic-extent
	    (let ((line? (read-line input nil nil)))
	      (if (null line?) (return-from read-file nil))
	      (with-indefinite-extent
		;; Process this line
		))))))))

In PROCESS-THIS-FILE the user wants the extent of the stream in INPUT to be
bounded within the outermost call to WITH-DYNAMIC-EXTENT. The extent of each
line of the file should be bounded within each pass through the body of the
LOOP.

Where this program could run into problems is within the call to READ-LINE. If
the stream object is mutated such that a pointer is maintained to an object
created within the call to READ-LINE, and that created object has dynamic
extent, then on exit from WITH-DYNAMIC-EXTENT in the body of this loop the
stream will have been corrupted.

Several approaches may be taken within an implementation to address this
problem. READ-LINE (and other stream mutation operations) could be written to
perform its mutations so that no objects with dynamic extent are created. This
could be done by using data which is immediate, such as immediate fixnums for
current-position-in-file counters. The portions of READ-LINE which could create
such objects, such as input buffer creation code, could themselves be wrapped
with WITH-INDEFINITE-EXTENT forms and allow these objects to be subject to
garbage collection. Another approach is to resource manage any supplemental
structures, again wrapping the creation point with WITH-INDEFINITE-EXTENT, but
recycling these objects for reuse on stream close such that no actual garbage is
created.

Another approach for an implementation is to declare that the use of READ-LINE,
or any other system object mutating function, within a dynamic extent context
should be an error.

The point of the facility is to allow implementations to provide some means for
users to more explicitly manage memory requirements within an application. The
choice of which facilities should be affected and how smoothly it should
integrate with the rest of the system is up to each vendor. Defining the
facility in this way means that programs which use it will have to be tailored
to work within different Lisp implementation, as is the case now with producing
executable program images. However, the inclusion of these forms in the
language does present implementors with an invitation to provide their users
with some method of memory use optimization, which is sorely needed.

∂15-Nov-88  1315	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Nov 88  13:15:03 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 492918; Tue 15-Nov-88 16:15:07 EST
Date: Tue, 15 Nov 88 16:14 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DYNAMIC-EXTENT (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881115161453.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

For those who don't remember, this issue used to be called STACK-LET.
There was opposition to STACK-LET and STACK-LET* with people seeming
to prefer a DYNAMIC-EXTENT declaration. This is that rewrite.

-----
Issue:          DYNAMIC-EXTENT
References:     None
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)
Related-Issues: REST-ARGUMENT-EXTENT, WITH-DYNAMIC-EXTENT
Status:	        For Internal Discussion

Problem Description:

  Sometimes a programmers 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.

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

  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.

  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. As such, (CDR X) is not an appropriate return
  value from the above LET, but (CDR Y) is an appropriate return value.
  Further, in 

	(LET ((X (LIST 'A 'B (LIST 'C 'D))))
	  (DECLARE (DYNAMIC-EXTENT X))
	  ...)

  the three conses (A . <cons-cell>), (B . <cons-cell>), and 
  (<cons-cell> . NIL) are said to have dynamic extent, but the list (C D)
  has indefinite extent. To declare the entire structure to have dynamic
  extent, one must write something like:

	(LET* ((TEMP (LIST 'C 'D))
	       (X (LIST 'A 'B TEMP)))
	  (DECLARE (DYNAMIC-EXTENT X TEMP))
	  ...)

  If an implementation does not recognize the constructor, it calls
  MACROEXPAND-1 in hopes of seeing a constructor which it does recognize.
  It iterates this process until it either sees a constructor which it
  does recognize, or until no macro expansion is possible. If it is unable
  to recognize the constructor, it must treat the object as if it had
  indefinite extent.

Test Case:

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

  (DO ((L (LIST-ALL-PACKAGES) (CDR L)))
      ((NULL L))
    (DECLARE (DYNAMIC-EXTENT L))
    (PRINT (CAR L)))
  prints all packages

  (DEFUN ADD (&REST X) (DECLARE (DYNAMIC-EXTENT X)) (APPLY #'+ X))
  (ADD 1 2 3) => 6

  (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

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.

∂15-Nov-88  1320	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Nov 88  13:19:53 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 492922; Tue 15-Nov-88 16:20:02 EST
Date: Tue, 15 Nov 88 16:19 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DYNAMIC-EXTENT
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881115161949.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

Sorry. The subject line of my previous message should have referred to
version 2, not version 1.

∂15-Nov-88  1412	CL-Cleanup-mailer 	Issue: DESCRIBE-INTERACTIVE (Version 4)  
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 15 Nov 88  14:11:36 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA00481; Tue, 15 Nov 88 17:10:25 EST
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA07001; Tue, 15 Nov 88 17:14:19 EST
Message-Id: <8811152214.AA07001@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@Multimax.encore.com
Subject: Issue: DESCRIBE-INTERACTIVE (Version 4)
Date: Tue, 15 Nov 88 17:14:16 EST
From: Dan L. Pierson <pierson@mist>

Issue:        DESCRIBE-INTERACTIVE
References:   DESCRIBE (p441)
Category:     CLARIFICATION (EXPLICITLY-VAGUE) / CHANGE (NO)
Edit history: 12-Sep-88, Version 1 by Pitman
              23-Sep-88, Version 2 by Masinter
	      19-Oct-88, Version 3 by Pierson, invert
              15-Nov-88, Version 4 by Pierson, two-proposal version

Problem Description:

  CLtL is not clear about whether DESCRIBE may be interactive.
  While CLtL describes INSPECT as an interactive as an
  interactive version of DESCRIBE, it doesn't make explicit
  that DESCRIBE is non-interactive. In some implementations it is, 
  and in other implementations it is not.

  Users of systems in which DESCRIBE is not interactive may presume
  that it is safe to call DESCRIBE in a batch applications without
  hanging the application, which can lead to problems.

Proposal (DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE):

    Specify that DESCRIBE is permitted (though not required) to
    require user input, and that such input should be negotiated
    through *QUERY-IO*.

    Descriptive information would continue to go to *STANDARD-OUTPUT*.

  Test Case:

    The following kind of interaction would be permissible in
    implementations which chose to do it:

     (DEFVAR *MY-TABLE* (MAKE-HASH-TABLE))
     (SETF (GETHASH 'FOO *MY-TABLE*) 1)
     (SETF (GETHASH 'BAR *MY-TABLE*) 2)
     (SETF (GETHASH 'FOOBAR *MY-TABLE*) 3)
     (DESCRIBE *MY-TABLE*)
     #<EQ-HASH-TABLE 259> has 3 entries.
     Do you want to see its contents? (Yes or No) Yes

  Rationale:

    This validates current implementations.

  Current Practice:

    Symbolics Genera asks some questions interactively when describing
    some kinds of structured data structures, such as hash tables.
    Since users can define their own DESCRIBE methods and took their cue
    from the system, describing some user structures also require such
    interactions.

  Cost to Implementors:

    None.

  Cost to Users:

    User code which depended on DESCRIBE running without user interaction
    would have to be modified. Such code is not currently fully portable,
    however.

  Cost of Non-Adoption:

    Users would not know the straight story about whether they should
    expect interaction from DESCRIBE.

  Benefits:

    Implementations which don't do interactive querying in DESCRIBE only
    because their not 100% sure it's kosher would be free to do it.

  Aesthetics:

    Some people might think it's not aesthetic for DESCRIBE to require user
    intervention. Not saying whether it's permissible is probably less
    aesthetic, though.

Proposal (DESCRIBE-INTERACTIVE:NO):

    Specify that DESCRIBE is forbidden to prompt for or require
    user input.  Permit implementations to extend describe via keyword
    arguments to prompt for or require user input as long as the default
    action if no keyword arguments are supplied does not prompt for or
    require user input.

    This is an incompatible change for some implementations.

  Test Case:

    The following kind of interaction would be permissible in
    implementations which chose to do it:

     (DEFVAR *MY-TABLE* (MAKE-HASH-TABLE))
     (SETF (GETHASH 'FOO *MY-TABLE*) 1)
     (SETF (GETHASH 'BAR *MY-TABLE*) 2)
     (SETF (GETHASH 'FOOBAR *MY-TABLE*) 3)
     (DESCRIBE *MY-TABLE* :INTERACTIVE T)
     #<EQ-HASH-TABLE 259> has 3 entries.
     Do you want to see its contents? (Yes or No) Yes

  Rationale:

    DESCRIBE is the only hook a portable program has for providing
    information about objects to the user.  The potential interactive
    functions of DESCRIBE are also likely to be available via INSPECT.

  Current Practice:

    Symbolics Genera asks some questions interactively when describing
    some kinds of structured data structures, such as hash tables.
    Since users can define their own DESCRIBE methods and took their cue
    from the system, describing some user structures also require such
    interactions.

  Cost to Implementors:

    Symbolics Genera and other non-conforming implementations will have
    to change.

  Cost to Users:

    User code which depends on DESCRIBE running with user interaction
    will have to be modified. Such code is not currently portable,
    however.

  Cost of Non-Adoption:

    Users would not have any portable way to have progams inform the
    user about object they are dealing with.  This might be important in
    traces and logs of portable progams or in portable debugging tools.

  Benefits:

    It will be easier to provide some types of portable functionality.

  Aesthetics:

    This simplifies the language slightly.

Discussion:

  Pitman thinks it's important to clarify this issue, but he isn't fussy
  about the particulars.

  EXPLICITY-VAGUE proposal is the minimal proposal for compatibility
  with current behavior.

  Some members of the cleanup committee think that EXPLICITLY-VAGUE is
  really a change from the intent of CLtL. However, the current
  sentiment is to be less rather than more specific about the behavior
  of debugging tools (25.3 of CLtL).

  It might be possible to extend DESCRIBE to have additional 
  keywords (:VERBOSE, :INTERACTIVE-ALLOWED) to cover 
  additional behavior. 

  Pierson supports NO because he thinks it's important for there to be
  some way for portable programs to present this sort of information
  to the user.  While the exact data and format presented is
  implementation dependent and thus outside of the bounds of
  standardization, the existance of such data is neither.

  Moon opposes NO because "it creates extra work for implementors and
  users of at least one implementation, for no compelling reason."

  Moon suggested as a compromise only allowing DESCRIBE to require
  user input from "interactive streams".  Several other members of the
  committee like this in principle but question whether it's feasible
  since we have neither defined "interactive streams" nor provided any
  portable way to tell if a stream is interactive.

∂15-Nov-88  1416	CL-Cleanup-mailer 	Issue: FORMAT-PRETTY-PRINT (Version 7)   
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 15 Nov 88  14:16:02 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA00507; Tue, 15 Nov 88 17:14:43 EST
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA07012; Tue, 15 Nov 88 17:18:38 EST
Message-Id: <8811152218.AA07012@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@Multimax.encore.com
Subject: Issue: FORMAT-PRETTY-PRINT (Version 7)
Date: Tue, 15 Nov 88 17:18:36 EST
From: Dan L. Pierson <pierson@mist>

This just fixes one major typo discovered by David Grey.

Issue:         FORMAT-PRETTY-PRINT
References:    FORMAT (pp. 385-388), PRIN1 (p. 83), PRINC (p. 83),
               WRITE (p. 382), *PRINT-PRETTY* (p. 371)
Category:      CLARIFICATION
Edit history:  Version 1 by Pierson 3/4/88
    	       Version 2 by Pierson 5/24/88 (fix name typo)
	       Version 3 by Pierson 6/10/88 incorporate comments
	       Version 4 by Pierson 6/10/88 comments from Van Roggen
	       Version 5 by Masinter  2-Oct-88
               Version 6 by Pierson 11/10/88 final nits
               Version 7 by Pierson 11/15/88 "does" => "does not"

Problem description:

The FORMAT operators, ~A and ~S are defined to print their argument as
PRINC and PRIN1 respectively.  The text does not say whether or not
these FORMAT operators must obey the *PRINT-PRETTY* flag.

Proposal (FORMAT-PRETTY-PRINT:YES):

Specify that FORMAT does not rebind any of the printer control
variables (*PRINT-...) except as follows:

~A
    Binds *PRINT-ESCAPE* to NIL.

~S
    Binds *PRINT-ESCAPE* to T.

~D
    Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
    *PRINT-BASE* to 10.

~B
    Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
    *PRINT-BASE* to 2.

~O
    Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
    *PRINT-BASE* to 8.

~X
    Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
    *PRINT-BASE* to 16.

~R
    Iff a first argument is specified, binds *PRINT-ESCAPE* to NIL,
    *PRINT-RADIX* to NIL, and *PRINT-BASE* to the value of the first
    argument.

    Iff no aruments are specified, binds *PRINT-BASE* to 10.

~@C
    Binds *PRINT-ESCAPE* to T.

~F,~G,~E,~$
    Binds *PRINT-ESCAPE* to NIL.

Test Cases/Examples:

(LET ((TEST '#'(LAMBDA (X)
		 (LET ((*PRINT-PRETTY* T))
		   (PRINT X)
		   (FORMAT T "~%~S " X)
		   (TERPRI) (PRINC X) (PRINC " ")
		   (FORMAT T "~%~A " X)))))
  (FUNCALL (EVAL TEST) TEST))

This should print four copies of the above lambda expression.  The
first pair should appear identical and the second pair should appear
identical.  The only difference between the two pairs should be the
absence of string quotes in the second pair.

Rationale:

FORMAT should interact with the printer control variables in a
predictable way.  This proposal is one of the two simplest possible
definitions and provides the most flexibility to the user.

A major advantage of this proposal is that the following two
expressions are guaranteed to have exactly the same effect:

    (FORMAT stream "~S" object)
    (PRIN1 object stream)

Thus use or non-use of FORMAT becomes a purely stylistic matter.

Current practice:

Ibuki Lisp and the TI Explorer obey the binding of *PRINT-PRETTY*.
Lucid Common Lisp always applies ~A and ~S with *PRINT-PRETTY* bound
to NIL.

Cost to Implementors:

While changing FORMAT to not bind *PRINT-foo* variables is trivial,
there are some painful implications.  How does a pretty-printing ~A
interact with MINCOL, etc?  How much of the user interface depends on
FORMAT in ways that might be uglified by pretty printing?

Cost to Users:

Truely portable code shouldn't be affected because existing
implementations are inconsistent.  Despite this, there are probably a
number of user programs in non-complying implementations which will
have to change whichever way this is decided.

Cost of non-Adoption:

The interaction of FORMAT and the printer control variables (especially
*PRINT-PRETTY*) will remain undefined.  This will continue to make
portable Common Lisp programming harder than it need be.

Benefits:

Life will be easier for users in two ways: (1) one more portability
problem will be removed, and (2) users will be more likely to be able
to persuade environmental features like debuggers to print in their
preferred way.

Aesthetics:

The interaction between two related parts of output will be clarified
in a simple way.

Discussion:

It is important to specify exactly what of Common Lisp's special
variables get rebound by other functions and macros in Common Lisp.
This cleanup issue addresses the interaction of FORMAT and the
*PRINT-  variables. There may be other similar interactions in 
Common Lisp that need clarification.

Otherwise, code that depends on FORMATs action in one implementation
will not port to others that do not have the same behavior.

CLtL might change as follows:

Add a header "Printer Control Variables" before the description of
*PRINT-ESCAPE* on page 370.

Add the following paragraph to page 386 just before the paragraph
starting with "It is an error":

    "The FORMAT function by itself never binds any of the printer
    control variables.  Specific FORMAT directives bind exactly the
    printer control variables specified in their description.  While
    implementations may specify the binding of new, implementation
    specific printer control variables for each FORMAT directive, they
    may neither bind any standard printer control variables not
    specified in description of a FORMAT directive nor fail to bind
    any standard printer control variables as specified in the
    description."

There was some discussion on whether *PRINT-BASE* should be bound for
~F, ~G, ~E, and ~$.  This is not necessary because page 341 of CLtL
states that floating point numbers are always printed in base 10.

∂15-Nov-88  1434	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Nov 88  14:34:44 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 493022; Tue 15-Nov-88 17:34:53 EST
Date: Tue, 15 Nov 88 17:34 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881115173439.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

Ok, three proposals follow. There isn't enough overlap for me to to bother
trying to  share their components. Please just vote for one or more and
hopefully we can discard the unpopular ones as it becomes more clear which
they are. I would hope that ultimately we can present a single proposal
to X3J13, but I can't at this time figure out which that will be.
 -kmp

-----Version 2a (ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICT-COPY)-----
Issue:        ADJUST-ARRAY-NOT-ADJUSTABLE
References:   ADJUST-ARRAY (p297)
Category:     ADDITION
Edit history: 22-Apr-87, Version 1 by Pitman
	      15-Nov-88, Version 2a by Pitman
Status:	      For Internal Discussion

Problem Description:

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

Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY):

  Change the definition of ADJUST-ARRAY to say that any array is a valid argument.
  Say that if the array is not adjustable or if its old rank is not compatible
  with the newly specified rank, then a new array will be created and returned.

  In the case where the argument was not adjustable and a new array was returned,
  an implementation is permitted to (but not required to) recycle the storage
  backing up the original array. It is an error to continue to use an array
  which was not adjustable.

  As with other destructive operations (most of which have names starting with
  the letter "N"), are encouraged to use this for value wherever possible and
  would be told that they can rely on the array to be adjusted `for effect'
  only when it was adjustable and the new rank matched the old.

Rationale:

  ADJUST-ARRAY offers features which are offered by no other function and which
  are useful in cases involving non-adjustable arrays (for what amounts to copying).
  This change would allow an expression such as:

    (SETQ X (ADJUST-ARRAY X ...))

  to work reliably. Those desiring the old behavior could do:

    (IF (OR (NOT (ADJUSTABLE-ARRAY-P X))
	    (NOT (EQUAL (ARRAY-RANK X) (LENGTH NEW-DIMENSIONS))))
	(ERROR "Array cannot be adjusted."))
  
  to get the old style error checking.

Current Practice:

  Probably no one implements this extension.

Adoption Cost:

  Although this change is not trivial, it is localized and would probably not
  require an excessive amount of work to install. Probably most of the necessary
  routines already exist and it's just a matter of offering an interface.

Benefits:

  In cases where a user would want to adjust an array but the array is not
  adjustable, he may well decide to try to simulate the contract of 
  ADJUST-ARRAY in copying the array. This can be tedious and may be error
  prone. It would be better for such code to be written once, efficiently 
  and uniformly, and then offered to the user in a well-packaged way.

  Some implementations have implementation-specific array attributes.
  A COPY-ARRAY program written in Common Lisp cannot correctly copy
  arrays with implementation-dependent attributes, but the implicit array
  copying feature described here could preserve such attributes. As such,
  this feature could help Common Lisp code to be more compatible with
  native data objects.

Conversion Cost:

  No correct user code currently tries to modify arrays which are 
  non-adjustable, so this change is technically upward compatible.

  Some advanced code-walking tools which believe that this function 
  works only by side-effect would have to be modified very slightly
  to know that its return value was of interest.

Aesthetics:

  Some people think this change is unaesthetic because it loses
  potential error checking.

  Some people think the whole notion of :ADJUSTABLE is unaesthetic,
  and so this change improves aesthetics.

  Some people worry that a delete like the `DELETE bug' (failure to
  SETQ the array back) might lead to confusion. For that reason, they
  find this change unaesthetic.

Discussion:

  MACSYMA needed something like this.

-----Version 2b (ADJUST-ARRAY-NOT-ADJUSTABLE:SIGNAL-ERROR)-----
Issue:        ADJUST-ARRAY-NOT-ADJUSTABLE
References:   ADJUST-ARRAY (p297)
Category:     CLARIFICATION/CHANGE
Edit history: 22-Apr-87, Version 1 by Pitman
	      15-Nov-88, Version 2b by Pitman
Status:	      For Internal Discussion

Problem Description:

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

Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:SIGNAL-ERROR):

  Change the definition of ADJUSTABLE-ARRAY-P to say that it will return T
  if and only if the array was created with :ADJUSTABLE T.

  Change the definition of ADJUST-ARRAY to say that it will signal an error
  if and only if the array to be adjusted was not created with :ADJUSTABLE T.

Rationale:

  Although implementations such as Genera which make adjustable arrays
  even when :ADJUSTABLE NIL is specified (or when not :ADJUSTABLE option
  is specified) are within the letter of the law, many argue that they
  are not within the spirit of the law. They argue that this `feature'
  just reduces error checking. The failure of ADJUST-ARRAY to recognize
  arrays which were not explicitly requested to be adjustable leads to
  portability problems when moving to other implementations which do not
  support this feature.

  Many users do not expect to have to do (SETQ X (ADJUST-ARRAY X ...)) when
  adjusting an array. If they expect ADJUST-ARRAY to work by side-effect,
  serious problems might be introduced by the IMPLICIT-COPY option above.

Current Practice:

  Symbolics Genera is incompatible with this proposal (though not with CLtL).

  Many implementations implement this proposal.

Adoption Cost:

  Some implementations may not have enough bits in their current
  array representation to represent the :ADJUSTABLE option. This may be
  true of Symbolics Genera -- I don't think anyone's done a full study of
  all array types on all processor types in order to prove
  whether this change is feasible or not.

Benefits:

  Portability of programs using ADJUST-ARRAY between some implementations
  is improved.

Conversion Cost:

  None to portable code. This change is technically upward compatible.

  Note however, that some implementation-specific code is affected
  adversely since :ADJUSTABLE T options would have to be added to some
  calls to MAKE-ARRAY in order to accomodate a more restrictive
  ADJUST-ARRAY.

Aesthetics:

  Some people think this change is very aesthetic because it increases
  the amount of error checking which can be done by ADJUST-ARRAY.

  Some people find the kind of error checking done by ADJUST-ARRAY to
  be gratuitous because they think the whole notion of :ADJUSTABLE is
  unaesthetic. To them, any attempt to enforce adjustability is an intrusion.

Discussion:

  None yet.


-----Version 2c (ADJUST-ARRAY-NOT-ADJUSTABLE:SIGNAL-ERROR+NEW-FUNCTION)-----
Issue:        ADJUST-ARRAY-NOT-ADJUSTABLE
References:   ADJUST-ARRAY (p297)
Category:     CLARIFICATION/CHANGE/ADDITION
Edit history: 22-Apr-87, Version 1 by Pitman
	      15-Nov-88, Version 2c by Pitman
Status:	      For Internal Discussion

Problem Description:

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

Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:SIGNAL-ERROR+NEW-FUNCTION):

  Change the definition of ADJUSTABLE-ARRAY-P to say that it will return T
  if and only if the array was created with :ADJUSTABLE T.

  Change the definition of ADJUST-ARRAY to say that it will signal an error
  if and only if the array to be adjusted was not created with :ADJUSTABLE T.

  Introduce a function COPY-ARRAY which is like ADJUST-ARRAY which treats
  its arguments like COPY-ARRAY but which always produces a new array rather
  than modifying the original array.

Rationale: 

Current Practice:

  Symbolics Genera is incompatible with the part of this proposal which
  deals with ADJUST-ARRAY (though not with the analogous part of CLtL).
  Many other implementations are already compatible with that part of
  this proposal.

  Probably no one implements COPY-ARRAY.

Adoption Cost:

  Some implementations may not have enough bits in their current
  array representation to represent the :ADJUSTABLE option. This may be
  true of Symbolics Genera -- I don't think anyone's done a full study of
  all array types on all processor types in order to prove
  whether this change is feasible or not.

Benefits:

  Some implementations have implementation-specific array attributes.
  A COPY-ARRAY program written in Common Lisp cannot correctly copy
  arrays with implementation-dependent attributes, but a COPY-ARRAY
  function could. As such, the presence of COPY-ARRAY would help
  Common Lisp code to be more compatible with native data objects.

Conversion Cost:

  None to portable code. This change is technically upward compatible.

  Note however, that some implementation-specific code is affected
  adversely since :ADJUSTABLE T options would have to be added to some
  calls to MAKE-ARRAY in order to accomodate a more restrictive
  ADJUST-ARRAY.

Aesthetics:

  Some people think this change is very aesthetic because it increases
  the amount of error checking which can be done by ADJUST-ARRAY.

  Some people find the kind of error checking done by ADJUST-ARRAY to
  be gratuitous because they think the whole notion of :ADJUSTABLE is
  unaesthetic. To them, any attempt to enforce adjustability is an intrusion.

Discussion:

  MACSYMA needed something like this.

∂15-Nov-88  1510	CL-Cleanup-mailer 	Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)   
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 15 Nov 88  15:09:51 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA00972; Tue, 15 Nov 88 18:08:27 EST
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA07151; Tue, 15 Nov 88 18:12:22 EST
Message-Id: <8811152312.AA07151@mist.UUCP>
To: Kent M Pitman <KMP%STONY-BROOK.SCRC.Symbolics.COM@multimax.encore.com>
Cc: CL-Cleanup%SAIL.Stanford.EDU@Multimax.encore.com
Subject: Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c) 
In-Reply-To: Your message of Tue, 15 Nov 88 17:34:00 -0500.
Date: Tue, 15 Nov 88 18:12:20 EST
From: Dan L. Pierson <pierson@mist>

I mildly prefer IMPLICT-COPY.

∂15-Nov-88  1539	CL-Cleanup-mailer 	Issue: DOTTED-MACRO-FORMS (Version 3)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Nov 88  15:39:02 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 493088; Tue 15-Nov-88 18:38:58 EST
Date: Tue, 15 Nov 88 18:38 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DOTTED-MACRO-FORMS (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881115183844.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

Issue:        DOTTED-MACRO-FORMS
References:   forms (p54), lists and dotted lists (pp26-27),
	      DEFMACRO (p145), destructuring macro arguments (p146)
Category:     CLARIFICATION/CHANGE
Edit history: 28-Jun-88, Version 1 by Pitman   (explicitly-vague vs allow)
	      01-Oct-88, Version 2 by Masinter (disallow)
	      15-Nov-88, Version 3 by Pitman   (revive allow, flush disallow)

Problem Description:

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

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

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

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

Proposal (DOTTED-MACRO-FORMS:ALLOW):

 Define that it is permissible for a macro form (or subform) to be
 a dotted list when "&REST var" or ". var" is used to match it. It
 is the responsibility of the macro to recognize and deal with such
 situations.

Rationale:
  
 Some implementations permit dotted lists in macro forms at toplevel.
 Most or all implementations permit dotted lists in macro forms at
 embedded levels. This proposal makes the language internally
 consistent without requiring changes to existing code.

 Also, there's no reason to unnecessarily restrict &REST since there
 is no computational overhead and since there's no dispute about how
 to interpret programmer intent in this gray area.

Test Case:

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

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

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

    (MACW . 1) => -1 under this proposal.
    (MACR . 1) => -1 under this proposal.

    (MACX . 1) is an error under CLtL semantics and is not
	       changed by this proposal. The reason it is an
	       error is that the argument pattern does not
	       match. The pattern is dictated by the arguments
	       -other than- the &WHOLE argument, so the pattern
	       is () and MACX cannot be called with any arguments.

Current Practice:

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

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

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

Cost to Implementors:
  
 Some implementations would have to eliminate an error check.

 Some implementations which try to use APPLY of a normal lambda
 to accomplish part of the destructuring (in the non-recursive case)
 would have to be slightly more careful.
  
Cost to Users:
  
 None. This change is upward compatible.
  
Benefits:

 People would know what to expect.

Aesthetics:

 Mixed opinion: certainly it is better to specify whether they are
 allowed or an error than to be vague.

 Some feel that disallowing dotted macro forms helps catch syntax errors.
 Some feel that allowing dotted macro forms makes the language more regular.

Discussion:

 Goldman@VAXA.ISI.EDU raised this issue on Common-Lisp.
 This issue came up primarily in the context of program-written programs;
 a macro used in the program generated code might occasionally use
 a dotted tail to a list to explicitly represent special conditions.
 
 Allowing dotted macro forms may blur the data/code distinction too much, 
 particularly for people who are new to Lisp. On the other hand, some people
 argue that the point of macros is to help blur that distinction. Macro
 forms are data which must be translated to program, and only once the
 program claims to be macroexpanded ought syntax restrictions be imposed.

 This proposal was rewritten from `DISALLOW' to `ALLOW' after Steele pointed
 out in a recent meeting that dotted lists are allowed in subforms and 
 that permitting them at toplevel would be the most internally consistent
 interpretation.

 Pitman supports DOTTED-MACRO-FORMS:ALLOW.

∂16-Nov-88  1038	CL-Cleanup-mailer 	Issue: DESCRIBE-INTERACTIVE (Version 4)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Nov 88  10:38:28 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 493533; Wed 16-Nov-88 13:36:50 EST
Date: Wed, 16 Nov 88 13:33 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DESCRIBE-INTERACTIVE (Version 4)
To: Dan L. Pierson <pierson%mist@Multimax.encore.com>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8811152214.AA07001@mist.UUCP>
Message-ID: <19881116183348.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 15 Nov 88 17:14:16 EST
    From: Dan L. Pierson <pierson@mist>

      Moon opposes NO because "it creates extra work for implementors and
      users of at least one implementation, for no compelling reason."

I still take that position.

      Moon suggested as a compromise only allowing DESCRIBE to require
      user input from "interactive streams".  Several other members of the
      committee like this in principle but question whether it's feasible
      since we have neither defined "interactive streams" nor provided any
      portable way to tell if a stream is interactive.

You yourself proposed INTERACTIVE-STREAM-P in issue STREAM-CAPABILITIES
on July 5.  I'm not sure why this issue has gotten nowhere, but I suspect
it is because two essentially unrelated proposals got mixed together; one
is INTERACTIVE-STREAM-P, the other is the attempt to standardize a way to
tell whether two streams connect to the same ultimate source or sink of
data.  I don't think it's at all problematical to define INTERACTIVE-STREAM-P
in a practically precise enough way.

The STREAM-ACCESS proposal, which is released but apparently not voted on,
could have incorporated INTERACTIVE-STREAM-P, but apparently it didn't.

∂16-Nov-88  1052	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Nov 88  10:52:47 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 493547; Wed 16-Nov-88 13:52:46 EST
Date: Wed, 16 Nov 88 13:52 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881115173439.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881116185239.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

I strongly oppose ADJUST-ARRAY-NOT-ADJUSTABLE:SIGNAL-ERROR and
ADJUST-ARRAY-NOT-ADJUSTABLE:SIGNAL-ERROR+NEW-FUNCTION, since they would
break an existing implementation (Genera) by forcing it to enforce the
:ADJUSTABLE keyword for all arrays.  Currently Genera includes the
extension that all non-displaced arrays are adjustable (on Ivory, displaced
arrays are also adjustable).  There may be other implementations with
similar extensions.  Such a change would probably break large numbers
of user programs that were never intended to be portable and don't
bother with the :ADJUSTABLE keyword.

I haven't seen any good reason for this change; the only argument offered
is an argument that would forbid all extensions of any kind -- the argument
is that any program that uses an extension cannot be ported to an
implementation that lacks the extension.

I mildly favor ADJUST-ARRAY-NOT-ADJUSTABLE:IMPLICIT-COPY, although I
think I would be just as happy with the status quo.

∂16-Nov-88  1253	CL-Cleanup-mailer 	Re: Issue: DESCRIBE-INTERACTIVE (Version 4)   
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 16 Nov 88  12:53:33 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA02499; Wed, 16 Nov 88 15:48:58 EST
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA08564; Wed, 16 Nov 88 15:52:53 EST
Message-Id: <8811162052.AA08564@mist.UUCP>
To: "David A. Moon" <Moon%STONY-BROOK.SCRC.Symbolics.COM@multimax.encore.com>
Cc: cl-cleanup%sail.stanford.edu@multimax.encore.com
Subject: Re: Issue: DESCRIBE-INTERACTIVE (Version 4) 
In-Reply-To: Your message of Wed, 16 Nov 88 13:33:00 -0500.
             <19881116183348.4.MOON@EUPHRATES.SCRC.Symbolics.COM> 
Date: Wed, 16 Nov 88 15:52:50 EST
From: Dan L. Pierson <pierson@mist>


    You yourself proposed INTERACTIVE-STREAM-P in issue
    STREAM-CAPABILITIES on July 5.  I'm not sure why this issue has
    gotten nowhere, but I suspect it is because two essentially
    unrelated proposals got mixed together; one is
    INTERACTIVE-STREAM-P, the other is the attempt to standardize a
    way to tell whether two streams connect to the same ultimate
    source or sink of data.  I don't think it's at all problematical
    to define INTERACTIVE-STREAM-P in a practically precise enough
    way.
    
True, I haven't been pursuing the issue because it seemed to generate
a lot of opposition and little support.  I'll look through my archives
and see if I can come up with a new version.

I don't oppose your compromise in princple, I'm just reluctant to make
DESCRIBE-INTERACTIVE depend on STREAM-CAPABILITIES' passage.  Of
course, this probably matters more to me than you since I want to
change the status quo and you don't.

∂16-Nov-88  1300	CL-Cleanup-mailer 	Issue: SETF-PLACES (version 1) 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Nov 88  12:59:51 PST
Received: from bhopal by heavens-gate.lucid.com id AA00299g; Tue, 15 Nov 88 14:58:15 PST
Received: by bhopal id AA01215g; Tue, 15 Nov 88 14:56:59 PST
Date: Tue, 15 Nov 88 14:56:59 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811152256.AA01215@bhopal>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: SETF-PLACES (version 1)

The following is the emmendation of SETF-FUNCTION-VS-MACRO that was
discussed at the Fairfax meeting; it incorporates the suggestions  
made there by Gregor, Bob Kerns, and myself.  Eric Benson and Patrick
Dussud here at Lucid have also reviewed it.
 
I've started it out under a different issue name, since it is such
a drastic change; but I wouldn't object at all if someone wants it
to be just another version of SETF-FUNCTION-VS-MACRO.

-- JonL --

!

Issue: SETF-PLACES

References: SETF rules for what a place-specifier can be; CLtL pp.94-7
            X3J13 88-002R: 
               Accessing Slots, Ch. 1 p.11
               DEFGENERIC  Ch. 2 pp.26-9
               DEFMETHOD  Ch. 2 pp.39-41
               (SETF DOCUMENTATION)  Ch. 2 pp.43-5
               ENSURE-GENERIC-FUNCTION  Ch. 2 pp.46-7
               GENERIC-FLET  Ch. 2 p.52
               GENERIC-LABELS  Ch. 2 p.55-6
               WITH-ADDED-METHODS Ch. 2 pp.90-1

Related issues: SETF-FUNCTION-VS-MACRO

Category:  ADDITION

Edit history:  Version 1, 11-Nov-88, by JonL


Problem description:

Common Lisp explicitly refrains from giving names to accessor update
functions.  The intent is that the macro SETF should shield the user
from ever having to know such names; the correlation between an accessor
name and its corresponding updator name, or updating code sequence, is
to be established by DEFSETF and DEFINE-SETF-METHOD.  Update function
names like SET and RPLACA are retained primarily for backwards
compatibility.  See CLtL p.93-4.

However, this is extremely inconvenient for CLOS programing.  The rub 
is that the functionality of an updator function must be specifiable 
"in pieces", by incremental uses of DEFMETHOD distributed throughout 
perhaps dozens of files.  A single definition using either DEFSETF or
DEFINE-SETF-METHOD is not an acceptable constraint for this style.
A named, generic function is the CLOS interface for doing distributed
code specification.

Furthermore, it is not at all clear where a DEFSETF call for a generic
function should go.  Should it be before the first DEFMETHOD on the 
update function?  should it be bundled into every such DEFMETHOD?  
should it be bundled into ENSURE-GENERIC-FUNCTION?  Clearly, the first 
two options would violate the modularity CLOS has strived so hard to 
achieve; and the third violates the optionality of ENSURE-GENERIC-FUNCTION.
The best choice would be to elide the DEFSETF call completely.  Some 
way is needed to designate an update function, without necessarily 
doing a DEFSETF or DEFINE-SETF-METHOD first.

Additionally the simpler form of DEFSETF, which could be used for
almost all generic needs (e.g., slot updating), requires the new-
value argument to be the last argument to the update function.
But in order to be able to discriminate upon the class of the
new-value argument, it cannot be described simply as "last" --
it must come before any &optional and &key arguments.  Thus there
is need for some other avenue whereby the new-value argument would
come, say, first in the argument list of the update function.

Finally, the CLOS specification X3J13 88-002R seems to imply
that the CLOS exterior syntax for function specifiers must be 
implemented down in the innards of every conforming Lisp 
implementation.  There is a very large amount of resistance
in the X3J13 group, at present, to any proposal which requires
any non-symbols as ordinary function names; not only do people
object to code like (SYMBOL-FUNCTION '(SOME LIST)), but there
is great reluctance to carry out system-wide modifications to
all places that deal with function names (most of which now
presume that "name" means SYMBOL).  Yet is the current opinion
of most of the CLOS subcommittee that the exterior CLOS interface
can be kept intact without requiring the underlying Lisp 
implementation to support non-symbols as function names.


Proposal (SETF-PLACES:ADD-SETF-FUNCTIONS)

-- Specify that certain function names are reserved to be "SETF functions",
   or "updator functions", for use by SETF expansions.  The very existence 
   of such an updator function is implicitly similar to having done a 
   DEFSETF [or rather, a modified form of the simple DEFSETF, as explained 
   next below].  Every accessor function name is uniquely paired with such 
   an updator name, regardless of whether the updator name ever has a 
   functional definition.  However, these functions do not replace any 
   previously defined SETF methods, nor override the place specifications 
   of CLtL section 7.2; they simply provide a default expansion for SETF, 
   as described below.

-- Specify that such a a SETF function must take one more argument than 
   its corresponding access function.  Let <access-fn> and <update-fn> 
   be such a correlated pair; then when SETF is given a "place" that is 
   a call on <access-fn>, it expands into a call on <update-fn> that is 
   given all the arguments to <access-fn> and also, as its very first 
   argument, the new-value (which must be  returned by <update-fn> as 
   its value).  For example, suppose that ASET is the updator function
   name corresponding to AREF.  Then 
        (SETF (AREF a i1 i2 ... in) value)
   could expand into
        (ASET value a i1 i2 ... in)

-- Extend the set of valid "place specifiers" as defined on CLtL p.94-7 
   by adding the following clause after all the existing ones:
       For any other place specifier, the form
         (SETF (<access-fn> A1 A2 ... AN) NEW-VALUE)
       will expand into a call to the uniquely-named updator function
       corresponding to <access-fn>, that is to the function named by
       (UNDERLYING-NAME '(SETF <access-fn>)).
   Note that SETF will no longer signal any "unknown place specifier" 
   errors during macroexpansion, because the default behavior is to
   simply construct a call to the setf function [except, however, when
   "access-fn" isn't legal as the name of a function; for example,
   (setf ((spaz) i1 i2) value) is still syntaticly illegal].  But if
   at run time, the "setf function" still hasn't been defined as a
   function [such as by DEFUN, DEFMETHOD, setf of SYMBOL-FUNCTION etc.],
   then a run-time "undefined function" error may occur.

   Note also that not every SETF method for an accessor function can be
   defined using an updator function.  For example, LDB cannot be handled
   this way, even if its corresponding update name is a defined function;
   LDB must be handled by DEFINE-SETF-METHOD, and as such the prior rules
   of CLtL p.94-7 would apply.

-- Be reminded that the rules for interpreting SETF place specifiers
   are actually embodied in the functions GET-SETF-METHOD and
   GET-SETF-METHOD-MULTIPLE-VALUE, rather than in the SETF macro
   itself.  Thus these two functions must be altered to reflect the new 
   "place specifier" called for just above.  Since the rules on p.94-7 
   of CLtL are to be applied in order, then SETF functions will only be 
   used when no SETF "method" has been defined for the name, such as by 
   calling DEFINE-SETF-METHOD or DEFSETF; also, a macro definition for 
   the access name will block the use of the SETF function, since the 
   macro call must be expanded first.  Remember also that such a updator 
   name may have a lexically local definition, as well as (or in addition
   to) a global one.

-- Add a new function, UNDERLYING-NAME of one argument; and also add an
   inverse for this function, UNDERLYING-NAME-TO-SPEC of one argument.
   UNDERLYING-NAME is defined as:
      (i) on any list like (SETF <name>), it returns a unique, 
          implementation-dependent name suitable for actual use as 
          a function name in that implementaion.
     (ii) on symbols, it is the identity function; and
    (iii) on any other data, it is undefined; however, other lists
          like (<spec-kind> ...) should be reserved for extensions
          which the x3J13 committee may be considering.
   UNDERLYING-NAME-TO-SPEC is defined as:
      (i) on any argument which specifically is the output of part (i)
          above [i.e., an "underlying" name], it returns (SETF <name>);
          thus the argument is the unique name which is EQUAL to
          (UNDERLYING-NAME '(SETF <name>)).
     (ii) on any symbol or list not covered by part (i) just above, it 
          returns it's argument.
    (iii) on any other data, it is undefined; however, other lists
          like (<spec-kind> ...) should be reserved for extensions
          which the x3J13 committee may be considering.

   The reason EQUAL is the determiner of "uniqueness" above is that it
   is EQ for symbols; and for implementations which have "function specs"
   it permits non-EQ copies of (SETF <name>) to be used interchangably.

   The result of UNDERLYING-NAME should be constant across "incarnations"
   of the same release of an implementation, and should be of a data type
   that can be printed out and read back in reliably.
   
   Thus in one implementation, which uses only symbols to name functions,
   it might be that:
      (UNDERLYING-NAME '(SETF FOO)) ==> SETF:4.USER.FOO
      (UNDERLYING-NAME-TO-SPEC 'SETF:4.USER.FOO) ==> (SETF FOO)
   whereas in another implementation, which has LispMachine style
   "function specs", it would be that:
      (UNDERLYING-NAME '(SETF FOO)) ==> (SETF FOO)
      (UNDERLYING-NAME-TO-SPEC '(SETF FOO)) ==> (SETF FOO)

-- Alter all the above-referenced documentation in the CLOS specification
   so as not to imply that lists are suitable as function names.  In
   particular, 
    (a) phrases like "... if <function-specifier> names a function" should 
        be changed to a phrase like "... if <function-specifier> refers to
        a defined function", or possibly even something like
        "... if (UNDERLYING-NAME <function-specifier>) names a function"
    (b) phrases like "(FBOUNDP <function-specifier>)" should be changed
        into "(FBOUNDP (UNDERLYING-NAME <function-specifier>))"; or
        else other terminology should express the intent of what is to
        be said.  For example, instead of saying: "When (FBOUNDP <f-s>) 
        is  true ..." one could just as well say  "When <f-s> refers to 
        a defined function ..."  The choice of which of these two formats 
        to use is an editorial one.
    (c) phrases like "(SYMBOL-FUNCTION function-specifier)" should be changed
        into "(SYMBOL-FUNCTION (UNDERLYING-NAME <function-specifier>))";
        or else other terminology should express the intent of what is to
        be said.  For example, one might say "... the function referred 
        to by <f-s>".  The choice of which of these two formats to use is
        an editorial one.

Since the concept of a standard expansion for DEFMETHOD has been
accepted, then it is clear that a form like 
    (DEFMETHOD (SETF FOO) ...)
will expand exactly the same as
    (DEFMETHOD #.(UNDERLYING-NAME '(SETF FOO)) ...)
The underlying call to ADD-METHOD will see the real function name used
for the updator function.  The user-level interface of CLOS can still
present the list format as acceptable; it is only the implementation of
DEFMETHOD, DEFGENERIC, that will have to worry about converting to a
"real" name.

One expected use of UNDERLYING-NAME-TO-SPEC is in Lisp-level debuggers,
which could try to print out something more user-comprehensible than
the very internal names that an implementation might use in place of
function specs.



Examples:

;;; If CLtL did not already prescribe a SETF expansion for SUBSEQ calls,
;;;  it could be defined like this:

  (setf (symbol-function (underlying-name '(setf subseq)))
	#'(lambda (new-value sequence start &optional end)
	    (unless end (setq end (length sequence)))
	    (setq end (min end (+ start (length new-value))))
	    (do ((i start (1+ i))
		 (j 0 (1+ j)))
		((= i end) new-value)
	      (setf (elt sequence i) (elt new-value i)))))

or, for implementations that have "function specs", this could be writen:

  (defun (setf subseq) (new-value sequence start &optional end)
    . . .)


;;; Here's an example using a local function.  First, define 
;;;  MIDDLE-REF to be an accessor function as follows.  [Assume 
;;;  also that MIDDLE-REF's home package is BAR.]

    (defun middle-ref (vec i) 
      (check-type i fixnum)
      (aref vec (ceiling i 2)))

;;; Now let SETF:3.BAR.MIDDLE-REF be the (implementation-dependent) 
;;;  updator function name corresponding to MIDDLE-REF; a normal 
;;;  definition of an update function for MIDDLE-REF could be:

    (defun setf:3.bar.middle-ref (new-element vec i) 
      (check-type i fixnum)
      (setf (aref vec (ceiling i 2)) new-element))

;;; But the SETF below will call FILL, because of the local definition 
;;;  of SETF:3.BAR.MIDDLE-REF;  and nowhere have we have made any
;;;   explicit call to DEFSETF or DEFINE-SETF-METHOD for MIDDLE-REF.

    (flet ((setf:3.bar.middle-ref (new-element vec i) 
             ;;"wide-body" version of set-middle-ref
             (declare (ignore i))
             (fill vec new-element :end (ceiling i 2))))
      (setf (middle-ref "abc" 1) #\z))


;;; The following function could be called by GET-SETF-METHOD, to 
;;;  implement SETF functions, when none of the other rules of CLtL
;;;  p.94-7 apply.

  (defun get-setf-method-for-setf-functions (form)
    (let* ((new-value (gensym))
	   (temp-vars (do ((a (cdr form) (cdr a))
			   (v nil (cons (gensym) v)))
			  ((null a) v)))
	  ((access-fn (car form)))
	  ((update-fn (underlying-name `(SETF ,access-fn)))))
      (values temp-vars 
	      (cdr form) 
	      (list new-value)
	      `(,update-fn  ,new-value  ,@temp-vars)
	      `(,access-fn ,@temp-vars))))

;;; For those implementations using "function specs", the form:
;;;   `(,update-fn  ,new-value  ,@temp-vars)
;;;  would probably have to  be replaced by:
;;;   `(FUNCALL #',update-fn  ,new-value  ,@temp-vars)



Rationale:

The paragraphs of the "Problem description:", except for the first,
describe four major problems with the status quo -- three concerning
the unsuitability of current SETF methods for supporting the CLOS
generic style, and one for an unintended presumption that every
implementation of CL will have "function specs".  This proposal
corrects these problems, without adding any significant new ones.


Current practice:

Some implementations have "function specs", so that forms like 
(SETF FOO) are permitted to name functions;  but none have extended 
the setf place specifiers as proposed herein.

Cost to Implementors:

Basically, none.  Implementations which already have Lisp Machine 
style "function specs" can just define UNDERLYING-NAME and
UNDERLYING-NAME-TO-SPEC as the identity function.  For those without
such capabilities, there is a portable implementation listed in the 
discussion section.

Extending GET-SETF-METHOD etc. to handle SETF functions should be a
very modest task at most.

Cost to Users:

This is basically an upward-compatible addition, so there should be
no cost to users [at least not for correct programs -- incorrect
SETF expansions will no longer be signalled at macroexpand time,
but may simply result in a runtime error for undefined function.]

Cost of non-adoption:

Non-adoption of this proposal would be a significant setback for the 
Common Lisp Object System.  There seems to be no agreeable alternative
for implementing generic setf methods.

Performance impact:

N.A.

Benefits:

See "Cost of non-adoption".

Esthetics:

This proposal increases the size of the definition of SETF; but
it greatly simplifies the "default" case, namely just defining
an updator function to correspond to an accessor.



Discussion:


The following code can be used by an implementation which doesn't
have "function specs" to implement the new functions:

  ;;;; -*- Mode: LISP; Syntax: Common-Lisp; Package: SYSTEM; Base: 10 -*-
  ;;;
  ;;; Author: JonL White, 15-Nov-88
  ;;;

  (in-package "SYSTEM")			;or, your development package

  (eval-when (eval compile load)

  ;;; The SETF package should be reserved for this purpose
  ;;;
  (or (find-package "SETF") 
      (make-package "SETF" :use nil))
  (defparameter *setf-package* (find-package "SETF"))
  (unless (and (null (package-use-list *setf-package*))
	       (null (package-used-by-list *setf-package*)))
    (error "SETF package has connections?"))

  ;;; "Internal Markers", to be used for uninterned symbols.
  ;;;
  (export (intern "SETF-SPEC" *setf-package*) *setf-package*)
  (export (intern "SETF-NAME" *setf-package*) *setf-package*)

  )


  (eval-when (eval compile)

  (defmacro setf-spec-p (x)
    (let ((spec (gensym)))
      `(LET ((,spec ,x))
	 (AND (CONSP ,spec) 
	      (EQ (CAR ,spec) 'SETF)
	      (CONSP (CDR ,spec))
	      (NULL (CDDR ,spec))
	      (SYMBOLP (SECOND ,spec))))))

  )

  (defun UNDERLYING-NAME (spec)
    (cond 
      ((symbolp spec) 
       spec)
      ((setf-spec-p spec)
       (let* ((accessor (second spec))
	      (accessor-name (symbol-name accessor))
	      (home-package (symbol-package accessor)))
	 (if home-package
	     (let* ((package-name (package-name home-package))
		    ;; 'spec-name' is a form like "~D.~A.~A", but FORMAT has a
		    ;; problem with global print parameters like *print-radix*
		    (spec-name (concatenate 'string
				 (write-to-string (length package-name)
				   :radix nil :base 10 :length nil :level nil)
				 "."
				 package-name
				 "."
				 accessor-name))
		    (updator (or (find-symbol spec-name *setf-package*)
				 (let ((sym (intern spec-name *setf-package*)))
				   (export sym *setf-package*)
				   sym))))
	       ;; A possible optimization, which trades off space for time, is
	       ;;  as follows; see definition of UNDERLYING-NAME-TO-SPEC below
	       ;;(setf (get updator 'setf:setf-spec) (copy-list spec))
	       updator)
	     (or (get accessor 'setf:setf-name)
		 (let* ((uname (concatenate 'string "SET-" accessor-name))
			(updator (make-symbol uname)))
		   (setf (get accessor 'setf:setf-name) updator)
		   (setf (get updator 'setf:setf-spec) (copy-list spec))
		   updator)))))
	  (t 
	   (error "~S is an invalid arg for ~S" spec 'UNDERLYING-NAME))))

  (defun UNDERLYING-NAME-TO-SPEC (x)
    (cond
      ((not (symbolp x))
       (if (setf-spec-p x)
	   x
	   (error "~S is an invalid arg for ~S" 
		  x 'UNDERLYING-NAME-TO-SPEC)))
      ((get x 'setf:setf-spec))
      (t 
       (let ((home-package (symbol-package x)))
	  (if (not (eq home-package *setf-package*))
	      x
	      (let ((name (symbol-name x))
		    accessor package-name)
		;; Unpack the name, which is a form like "~D.~A.~A"
		(multiple-value-bind (nchars starti)
				(parse-integer name :radix 10 :junk-allowed t)
		  (incf starti)
		  (setq package-name (subseq name starti (incf starti nchars)))
		  (incf starti)
		  (setq accessor (find-symbol (subseq name starti) 
					      (find-package package-name)))
		  (unless accessor
		    (error "~S failed to parse in ~S" 
			   x 'UNDERLYING-NAME-TO-SPEC))
		  `(SETF ,accessor))))))))

∂16-Nov-88  1312	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Nov 88  13:12:52 PST
Received: from bhopal by heavens-gate.lucid.com id AA00269g; Tue, 15 Nov 88 00:29:22 PST
Received: by bhopal id AA25376g; Tue, 15 Nov 88 00:28:06 PST
Date: Tue, 15 Nov 88 00:28:06 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811150828.AA25376@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Mon, 14 Nov 88 17:15 EST <19881114221549.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)

re: ...could you explain why the syntax should be made more complicated to
    deal with the special needs of a particular implementation?  ...

I don't think either syntax is superior enough to warrant spending time
trying to figure out compiler optimizations.  After all, this fool 
function is definitely _not_ for the masses --  it is being designed
for precisely the 3 or 4 hackers who are working on portable iteration
paradigms; and they will use it in precisely three or four places
in their code.

Also, I think you are overestimating the complexity of what the current
SSC's[*] in our community can handle.  By making the iteration scope
macro define a 'macrolet' name, the implementor can put lots of
"smarts" into that one macro.  But expecting the compiler to do
enough source code analysis to figure out that when a bound variable
has a certain value, nothing "interesting" will be done ... I just
can't believe you're actually suggesting this.  And it's not just
the compiler -- people *do* run code interpretively, you know!

The particular thing I was referring to in Lucid's DO-EXTERNAL-SYMBOLS
is that Lucid represents packages differently depending on the ratio of
of internal and external symbols.  [This is consistent with good data
base design -- you have several "baskets" to use, depending on how big 
a fish you want to carry home.]  But even without Lucid's particular
optimizations, consider doing a DO-INHERITED-SYMBOLS over a package
MONGO, that uses LISP; and suppose MONGO is a "development" package 
with 80,000 internal symbols present.  Would you really want to iterate
through 79,000 internal symbols, swapping in all those jillions of
pages, before finding the desired 1000?  Probably not.  Any 
implementation -- not just Lucid's -- that takes the obvious step of
iterating thru the package-use-list and ignoring certain shadows would
be infinitely better than requiring user-level code to do filtering of
all accessible symbols.  This is *not* a LUCID-specific issue.


Even if I were to agree that your alternative #2 is minutely simpler 
than alternative #1, the point is that #1 is "real good" all by itself;
and this doesn't feel like a place where 50.001% is that much better 
than 49.999%.



-- JonL --



[*] SSC = "Sufficiently Smart Compiler"

∂16-Nov-88  1323	CL-Cleanup-mailer 	Re: Issue: STREAM-CAPABILITIES (Version 1)    
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 16 Nov 88  13:23:21 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA03392; Wed, 16 Nov 88 16:21:46 EST
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA08678; Wed, 16 Nov 88 16:25:41 EST
Message-Id: <8811162125.AA08678@mist.UUCP>
To: masinter.pa%Xerox.COM@multimax.encore.com
Cc: cl-cleanup%sail.stanford.edu@multimax.encore.com
Subject: Re: Issue: STREAM-CAPABILITIES (Version 1)
In-Reply-To: Your message of 20 Sep 88 02:16:00 -0700.
Date: Wed, 16 Nov 88 16:25:38 EST
From: Dan L. Pierson <pierson@mist>

A long delayed reply, now that Moon woke me up.

    Yes, its not so much the necessity of STREAM-SAME-xxx-P as it is the
    likelihood of them being correctly implementable for any of the likely
    operating systems, especially in the presence of network file systems,
    pipes, streams, indirects, redirects, etc.
    
Would it help if the functions returned the cannonical two values:
 T   T	    means Yes
 Nil T	    means No
 ?   Nil    means can't find out or not sure

It would be legitimate for an implementation to always return {Nil, Nil}
if either stream led to a network file.  However some network file
systems (and some implementations) might be able to answer the question
accurately in all cases.

    I think adding something that cannot be correctly implemented will
    lead to more rather than less portable code.
    
I don't think this is what you meant to say.

    Dans reasoning "Pierson supports STREAM-CAPABILITIES:NEW-PREDICATES
    because he is concerned that it may be hard for implementations to
    provide the list functions efficiently because the natural token type
    for multiple, disjoint types of streams may be integers.  The
    implementation would have to coerce these integers in to some other
    type of token that would be guaranteed unique across all possible
    stream types."
    
    doesn't follow from the proposal, does it? Some streams could have
    integers as tokens (are you thinking of their inode number or
    something?), and others not.
    
Well, I tried to explain this in more detail and ended up convincing
myself that I was wrong so please consider the objection withdrawn.

Would a new draft based on LIST-FUNCTIONS be useful?

Does this *have* to be broken up into two issues?

∂16-Nov-88  1324	CL-Cleanup-mailer 	Issue: HASH-TABLE-STABILITY (version 1)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Nov 88  13:23:53 PST
Received: from bhopal by heavens-gate.lucid.com id AA00255g; Mon, 14 Nov 88 23:15:59 PST
Received: by bhopal id AA25286g; Mon, 14 Nov 88 23:14:43 PST
Date: Mon, 14 Nov 88 23:14:43 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811150714.AA25286@bhopal>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: HASH-TABLE-STABILITY (version 1)

Issue:      HASH-TABLE-STABILITY

References:    CLtL, p.282 "Hash on Lisp object"
	       The Art of Computer Programming, vol 3, Section 6.4 "Hashing"

Category:     CLARIFICATION

Edit history: Version 1, 11-Nov-88, by JonL 


Problem description:

The performance, and to some degree the semantics, of hash tables
depends not only on the kind of table as specified by the :test
argument to MAKE-HASH-TABLE, but also on the underlying techniques
of key transformation (into an integer) and of "collision" resolution. 
CLtL is not specific enough to encompass current, desirable practice.

People tend to be confused as to what "Hash on EQ" means, both in terms
of semantics and expected performance.  Many will often suggest using
SXHASH as the key-transformation function for EQ/EQL type tables, in
order to circumvent the well-known GC-related problem with those tables.
[See, for example, the message from Barry Margolin to the common-lisp
mailing list dated "12 Sep 88 11:05 EDT"; it is reproduced at the end of
the Discussion section below.]  Unfortunately, this suggestion violates
the commonly perceived notion of what "Hash on EQ" means, even though
CLtL nowhere explicitly would rule it out.  CLtL is not precise enough
as to what is expected of these types of tables, and certainly the
phrase "commonly perceived notion" is not precise enough.

A similar ambiguity can arise as to what "Hash on EQUAL" means; CLtL
p.285 only indirectly implies that SXHASH should be used as the
key-transformation function for EQUAL type tables.  [See below for
definition of "key-transformation".]

The term "Hashing on Lisp objects" has come to be called "Hash on EQ", 
and "Hashing on Tree Structure" is called "Hash on EQUAL"; see CLtL
p.282 , which describes the differences between hash-table kinds as 
being merely which function they use as the equivalence predicate
(the :TEST function argument to MAKE-HASH-TABLE.)  However, the term 
"Hash Table" carries a strong connotation about how such a table is 
implemented; in particular, for sufficiently large tables, some technique
for "collision resolution" must be done.  (See Knuth vol 3, p507-8).  
Since CLtL merely focuses on the :test function, people -- implementors 
as well as end-users -- tend to be confused as to how these techniques 
play a central part in the notion of "hash tables; furthermore, CLtL is
silent about what actions must preserve the stabililty of these 
"collision chains"  (i.e., the ability of the table to "find" previously 
entered keys).



Proposal (HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS)

Summary of proposals:

-- Clarify that by "hashing", we mean more than simple linear search.
-- Generalize the following requirement from CLtL p.285:
           (EQUAL X Y)  implies  (EQUAL (SXHASH X) (SXHASH Y)) 
    and clarify that this requirement exactly prescribes how sensitive 
    hash tables can be to user-initiated data modifications.
-- Characterize just what key-transformation functions may be used for 
    EQ, EQL, EQUAL and EQUALP hash tables.

First, some terminology:

"Key-Transformation".  This is a term used by Knuth to describe the
homomorphic transformation of a hash-table key argument into an integer.
[See the index for "The Art of Computer Programming", vol 3; especially
see Section 6.4 and page 512.]  It also can refer to the transformation
into a set of two or more integers (which is not really a distinct
notion considering Goedel numbering).  From this integer, the pattern 
of table indices to use when searching for that key will be completely
characterized.  Knuth also uses a related term "hash function" to mean
"the address where the search begins"; that term is much too subject to
confusion, and will not be used herein.

"Collision Chain".  This term is limited in use by Knuth to just one
particular method of collision resolution; herein it will be used to
describe the sequence of probes specified for a given candidate entry 
by a particular key-transformation; i.e. a virtual "chain" of table 
indices (or address) to be examined.  Two different objects which "hash" 
to the same table address are "in conflict", and their respective 
collision chains may or may not be equal.

"Expected number of (re-)probes".  A particular algorithm for key-
transformation and collision-chain specification could be analyzed to
show a graph of the "Expected" number of calls on the :test function, 
as a function of the fullness of the table (number of entries divided 
by table size).  "Expected" has a technical, mathmatical meaning here:
it basically means "average", so one must be careful not to get carried
away with particular counter examples of "badly distributed" data.  A
"probe" is one comparison of the argument with the key of an entry in
the table, using the test function.

"%UNIQUE-NO".  The implementation of Lisp data, encoded into machine-
specific data and addresses, is not part of the portable specification
of CL; but we are aware that every implemetation _must_ do some such
embedding.  Thus we will use %UNIQUE-NO to name a one-to-one function
which maps any Lisp object into a Lisp integer.  Normally, this will
just be the machine address of where the object is stored, possibly with
some data-type tag bits added.  But for non-stored, or "immediate" data,
it doesn't matter what %UNIQUE-NO returns as long as its bijective nature
is maintained.  The following equivalence is a defining characterization:
    (eq x y)  <-->  (= (%unique-no x) (%unique-no y))


Now for the actual proposals.


1. Clarify that the term "hash table" implies the use of some techniques
 designed to make the expected number of probes be bounded by a small
 constant rather than growing linearly with the number of entries in the
 table [for "small constant", one could also accept "log of the number of
 entries"].  Although nothing in CLtL explicitly prohibits it, very few 
 people would accept simple linear searching as any kind of hash table.
 For example, the following definition is counter to our understanding:
    (defun gethash (x ht &optional default)
      (let ((index (position x (hash-table-key-vector ht) 
			    :test (hash-table-test ht))))
	(if index
	    (values (svref (hash-table-value-vector ht) index)
		    T)
	    (values default 
		    NIL)))) 
 Such a simple definition may be functionally useful when the total
 number of entries is small (e.g., a couple dozen or so); but the 
 "Expected" number of probes grows linearly with the number of entries.  

 As a consequence of this requirement, the collision chain for a give item
 in a given table will likely not cover the whole table; otherwise, if
 every such chain covered a substantial fraction of the table, then the
 behaviour time would be linear in the size of the table.  Thus it should
 be noted that even though an item is entered in a hash table, it
 typically _cannot_ be found by searching through the wrong collision
 chain.


2. Specify that for any equivalence relation <eqv> used as a hash table 
 :test function, there must be a corresponding key-transformation function 
 <sxh> used in that hash table such that the following implication is true
 for all X and Y:
	 (<eqv> x y) -->  (= (<sxh> x) (<sxh> y))
 This could be said to mean that a key-transformation function must be "not
 more discriminating" than the equivalence function it is associated with;
 i.e. as a numerical function, it must not create more equivalence classes 
 of data than the associated equivalence function does.  

 This requirement resembles that placed upon SXHASH [CLtL, p285], and
 from it, one may deduce that SXHASH is a acceptable key-transformation
 function for EQUAL type hash tables.  Note well, however, that there 
 are many many functions satisfying this property for EQUAL.  Hence 
 key-transformation for EQUAL tables:
   (1) need not be constant over all CL implementations;
   (2) need not be constant over all instances of EQUAL hash-tables in 
       a given implementation;
   (3) need not be constant even over all entry counts for a particular 
       hash table in a given implementation.

 Note also that this requirement -- "not more discriminating" -- rules
 out the use of key-transformations which "notice" data modifications
 that are not likewise "noticed" by the test function.  Since user-
 initiated data modifications might conceivably affect either the
 equivalence relation of a hash-table (the :test function) or the
 associated key-transformation function, we want to ensure that the
 ability of the table to "find" a previously entered key is related only
 to the ability of the :test function to identify equivalent copies of
 the key.

3. Clarify that %UNIQUE-NO is acceptable as a key-transformation for an
 EQ type table, but that it is not suitable for EQUAL or EQUALP tables.
 Clarify also that most SXHASH implementations are _not_ suitable for EQ 
 or EQL type tables.

 Numerous implementations have some function like %UNIQUE-NO called 
 either %POINTER or POINTER-TO-FIXNUM; they are generally acceptable for 
 EQ type tables.  But one must be careful to note that similar, unrelated
 functions could also be used; in particular, many "unique identification" 
 schemes have been employed where the integer is cached with the object by
 some means other than the bits of its address (e.g. a "hidden" component 
 inside the object). Of course, any %UNIQUE-NO defined as above would not 
 be acceptable for EQUAL or EQUALP tables; two EQUAL but non-EQ cons cells
 must have different %UNIQUE-NO values, violating the general rule stated
 in item 2 above.

 A trivial variant on %UNIQUE-NO is acceptable for EQL tables:
     (if (numberp x) (sxhash x) (%unique-no x))
 By itself, %UNIQUE-NO would not be acceptable since it would be too
 "discriminating" on numbers.

 Many persons have noted that the definition:
     (defun sxhash (x) 5)	    ;for any random integer value of "5"
 meets the CLtL criterion for SXHASH.  In fact, such a constant function
 may be quite useful for hash-tables with entry counts below a specified
 mininum.  But of course it is not really suitable in general since it 
 would put every entry into the same collision chain; that would cause 
 the expected re-probe cost to be linear in the number of entries, which
 violates item 1 above.

 On the other hand, an SXHASH function suitable for use as the key
 transformation in an EQUAL type table is _not_ acceptable for use
 with an EQ or EQL table.  Every implementation the proposer has queried 
 returns different values for the lists (A) and (B).  Thus consider the
 example of hashing a list (A) into an EQ type table, and observe what 
 happens after altering the (first) element of this list to be B.  Let
     x = the list before modification
     y = the list after modificaton
 now clearly (EQ X Y) is true, so we would obviously like a GETHASH call
 after the modification has been done to find the same cons cell that 
 had  been entered before the update.  If SXHASH were used as the key-
 transform, then the collision chain selected _after_ the alteration would 
 be different from the one selected beforehand.   Since the two different 
 collision chains can not be  guaranteed to intersect, then in at least 
 some circumstances, GETHASH on X would find the entry, but GETHASH on Y 
 would fail to find it.  See also the examples section.

 Although SXHASH is not very tightly defined in CLtL, one must be careful
 not to make assumptions about whether or not it is acceptable for use in
 EQUALP tables.  In order to get a reasonable amount of randomization in
 the collision chains, a key-transformation function for EQUAL tables
 ought to be "more discriminating" than any minimal function acceptable 
 for EQUALP tables [because EQUAL partitions the object world up into 
 many more equivalence classes than does EQUALP].


In item 2 above, there are listed three areas where key-transformation
functions may differ: when going from one vendor to another (or from one
release by the same vendor to another), when going from one hash-table
to another of the same type, and when increasing or decreasing the entry
count of the table.  To this list we can add another more general rule on
key-transformations.

  (4) [they] need not be constant even over a particular "core image" 
      saving and restoration, or over a "memory reorganization" such as 
      a garbage collection.

Of course, if a change is made at some point in time in the key-
transformation algorithm being used for a particular table, then that 
table should be "re-hashed" to ensure the continuity of its entries.  
As has been noted before, many implementations use algorithms for EQ 
type tables which change after any data is relocated; that is why 
re-hashing may be required after a "GC".



Examples:

It is not surprising that in the following example, the value Y
cannot be found in the table after it has been altered by the first
SETF, even though it could be found before the alteration. 
   (setq ht (make-hash-table :test 'equal))     ==>  #<Hash-Table>
   (setq x '(A (B) (C D))
	 y (copy-tree x))                       ==>  (A (B) (C D))
   (and (equal x y) (not (eq x y)))             ==>  T
   (setf (gethash x ht) T)                      ==>  T
   (setf (car (second y)) 'E)                   ==>  E
   (gethash x ht)                               ==>  T
   (gethash y ht)                               ==>  NIL
After all, the :test function will not be able to identify the
altered key with with the one originally entered, because at the
time gethash is called:
   (equal x y)                               ==>  NIL

However, the circumstances under which the following can fail are
not at all obvious:
   (setq ht (make-hash-table :test 'equal))      ==>  #<Hash-Table>
   (setq x '(A #(B) (C D))
	 y (copy-tree x))                        ==>  (A #(B) (C D))
   (and (equal x y) (not (eq x y)))              ==>  T
   (setf (gethash x ht) T)                       ==>  T
   (setf (aref (second y)) 'E)                   ==>  E
   (gethash x ht)                                ==>  T
   (gethash y ht)                                ==>  ?
Note however that:
   (equal x y)                                   ==> T 
If the key-transformation function used in this hashtable failed to obey
the "not more discriminating" contraint imposed by item 2 above, it
might be tempted to descend into the vector #(B) in order to randomize
the keys a bit more; but EQUAL on pointer vectors is defined to be EQ.
Thus X and Y, while being EQUAL, might fall into different collision
chains, and hence not be identified as the same key.


On the other hand, EQ/EQL type tables should be impervious to the
updates in the above examples:
   (setq ht (make-hash-table))                    ==>  #<Hash-Table>
   (setq y (setq x (copy-tree '(A (B) (C D)))))   ==>  (A (B) (C D))
   (setf (gethash x ht) T)                        ==>  T
   (gethash x ht)                                 ==>  T
   (setf (car (second y)) 'E)                     ==>  E
   (gethash y ht)                                 ==>  T
Thus x and y are "EQ, but not EQUAL" [which only makes sense when
they refer to the same object at different points in time]; however,
the EQ/EQL-type table is not affected by this.



Rationale:

The performance expectations about hash-tables, and consequent 
implementational constraints, need to be formalized.

Current practice:

Every implementation that the proposer has tried *seems* to satisfy
these constraints.

Cost to Implementors:

None.

Cost to Users:

None.

Cost of non-adoption:

Continuing confusion as to what is stable in EQ/EQL tables, and what
is stable in EQUAL tables.  Possible confusion when it comes to
implementing EQUALP tables.

Performance impact:

N.A.

Benefits:

See Cost of non-adoption.

Esthetics:

The proposal more closely relates the term "Hash Table" to the
classic use of it in  "The Art of Computer Programming", vol 3.


Discussion:

One of the attractions to Common Lisp is that many common techniques are
a required part of the language; C programmers who continue to re-invent
hasing techniques over and over have praised CL in particular for hash
tables.  After all, it is much more likely that efficient, correctly
coded algorithms will be provided by the system supplier than that every
code writer will understand and correctly apply the information found
in Knuth's "The Art of Computer Programming", vol 3.

The requirement that the expected number of reprobes be bounded by a 
"small constant" should not be taken to extreme.  In particular, a
simple trade-off of space for time can assure some compliance with it.
For example, a data set of size N could be partitioned into N/20
subsets; as long as the partitioning function does a fairly good job
of balancing the number of elements in each partition class, and as
long as the partition function can be quickly calculated, then the one
could say that the expected number of probes would be bounded by "about
twenty or so".  The generally understood meanings of the :rehash-size
and :rehash-threshold components of hash-tables may be biased towards 
an "open-addressing" implementation; but "bucketizing" implementations
are not arbitrarily ruled out.  This proposal is in no way intended to
rule out "bucketizing" implementations of hash tables.


Here's an example of how one might analyze the problems relating GC 
and EQ/EQL type tables:

  Date: Mon, 12 Sep 88 11:05 EDT
  From: Barry Margolin <barmar@Think.COM>
  Subject: MAKE-HASH-TABLE :TEST arg
  To: "Steve Bacher (Batchman)" <SEB1525@draper.com>
  Cc: common-lisp@sail.stanford.edu

  . . . 
  Various aspects of the behavior of a hash table are dependent upon the
  TEST argument.  An EQUAL hash table need not be rehashed after a copying
  GC.  The hash function is generally dependent upon the test function;
  for an EQUAL hash table it would be SXHASH, while for an EQ hash table
  it would probably be a simple hash on the address.

  I suppose you COULD use SXHASH for all hash tables, since EQ objects are
  necessarily EQUAL, and you COULD rehash ALL hash tables.  Or you could
  implement hash tables without actually hashing (e.g. implement them as
  alists).  But if performance is an issue (which it generally is when you
  use a hash table), you'll probably want to do things dependent on the
  test function.

						  barmar

This suggestion is not prohibited by CLtL, although it violates the
commonly accepted understanding of what "Hash on EQ" means.

∂16-Nov-88  1522	CL-Cleanup-mailer 	Issue: GET-MACRO-CHARACTER-READTABLE (version 1)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Nov 88  15:21:57 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00896g; Wed, 16 Nov 88 15:20:29 PST
Received: by bhopal id AA04741g; Wed, 16 Nov 88 15:18:38 PST
Date: Wed, 16 Nov 88 15:18:38 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811162318.AA04741@bhopal>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: GET-MACRO-CHARACTER-READTABLE (version 1)

Issue: GET-MACRO-CHARACTER-READTABLE (version 1)

References:  CLtL p.361: COPY-READTABLE, SET-SYNTAX-FROM-CHAR, and
                         GET-MACRO-CHARACTER
             CLtL p.364: GET-DISPATCH-MACRO-CHARACTER, 
             CLtL p.378: Example in middle of page

Category:    CLARIFICATION/CHANGE

Edit history:  Version 1, 16-Nov-88, by JonL


Problem description:

The 'readtable' argument to GET-DISPATCH-MACRO-CHARACTER and to
GET-MACRO-CHARACTER must be of type READTABLE; this may have been simply
an oversight, since it makes more sense for it to refer to values from
the standard readtable.  Both COPY-READTABLE and SET-SYNTAX-FROM-CHAR
explicitly say that a NIL in the 'from-readtable' argument refers to the
standard readtable.  Also, an example in the middle of the page, CLtL
p.378, supplies a NIL to GET-MACRO-CHARACTER, and is clearly intending
to access the standard readtable values.


Proposal (GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD)

Specify that the 'readtable' argument to GET-DISPATCH-MACRO-CHARACTER
and to GET-MACRO-CHARACTER mean the same thing it does for COPY-READTABLE,
and SET-SYNTAX-FROM-CHAR; namely a reference to the standard readtable.  
Thus (GET-MACRO-CHARACTER <char> NIL) would be equivalent to 
(GET-MACRO-CHARACTER <char> (COPY-READTABLE)), but without consing.

Test Cases:

(let ((standard-rt (copy-readtable))
      (chars '(#\* #\= #\| #\A #\  #\( #\# #\1)))
  ;; Test Case 1
  (dolist (char chars)
    (assert (eq (get-macro-character char nil)
                (get-macro-character char standard-rt))
            () "Lose on character ~C" char))
  ;; Test Case 2
  (dolist (char chars)
    (assert (eq (get-dispatch-macro-character #\# char nil)
                (get-dispatch-macro-character #\# char standard-rt))
            () "Lose on #\# dispatch character ~C" char))
  ;; Test Case 3
  (assert (eq (get-dispatch-macro-character #\# #\A nil)
              (get-dispatch-macro-character #\# #\a nil))
          () "Lose on #\# dispatch character ~C" char)
 )

Rationale:

Probably was the original intent; somebody wants it; also see "Esthetics".

Current practice:

Symbolics and Xerox have already implemented the proposal; Lucid, VAXLISP,
and KCL stuck to the more rigid interpretation.


Cost to Implementors:

Trivial.

Cost to Users:

None.

Cost of non-adoption:

Minor worry about porting between implementations that support the
generalization and those that don't; minor worry about consing when
calling (COPY-READTABLE) to get at standard readtable semantics.

Performance impact:

See "Cost of non-adoption".

Benefits:

See "Cost of non-adoption".

Esthetics:

Increases parallel design among similar readtable functions.

Discussion:

This question was raised in the Common Lisp mailing last summer:
    Date: 19 Jul 88 13:35
    Subject: Question about readtable null arguments
    From: quiroz%cs.rochester:EDU:Xerox
    To: common-lisp%sail.stanford:EDU:Xerox

∂16-Nov-88  1654	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Nov 88  16:31:06 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01012g; Wed, 16 Nov 88 16:27:18 PST
Received: by bhopal id AA05000g; Wed, 16 Nov 88 16:25:54 PST
Date: Wed, 16 Nov 88 16:25:54 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811170025.AA05000@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 14 Nov 88 15:32 PST <881114-153301-2381@Xerox>
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)

re: Frankly, although option #2 with filtering looks like it is simpler --
   certainly the syntax description is shorter -- I think option #1, where you
   spell out more explicitly the kind of iteration you want to do, looks like
   it is easier to understand.

   So I would vote for option #2 over option #1 even without some special
   Lucid-specific circumstances.

You made a typo here -- your "vote" is for option #1.  [Not only is this 
clear from the context of the remainder of the msg, but I checked it with 
Larry, by telephone.]  Moon take note.


-- JonL --


∂18-Nov-88  0021	CL-Cleanup-mailer 	Re: Issue DOTTED-MACRO-FORMS   
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 18 Nov 88  00:21:43 PST
Received: from relay2.cs.net by RELAY.CS.NET id am17791; 18 Nov 88 0:54 EST
Received: from draper.com by RELAY.CS.NET id ac02405; 17 Nov 88 15:51 EST
Date: Thu, 17 Nov 88 08:22 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue DOTTED-MACRO-FORMS
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: IN%"cl-cleanup@sail.stanford.edu",SEB1525

Sounds like a good idea to me.  In fact, I think it would be useful to allow
dotted function invocation forms.  It would make it simpler to code functions
like this:
 
 (defun send-formatted-message (format-text &rest format-args)
  (internal-send-message (apply #'format nil format-text format-args)))
 
Why not be able to say
 
 (defun send-formatted-message (format-text &rest format-args)
  (internal-send-message (format nil format-text . format-args)))
 
This would be meaningful only for functions that are defined to take &REST args,
of course.  
 
I suppose this is reminiscent of the old controversy about destructuring in
function lambda lists (which my implementation supports, mainly because it
would be a PITA to have the destructuring code arbitrarily signal an error
just because it was parsing a DEFUN lambda list instead of a DEFMACRO
lambda list).  But I still think this is useful.  Sure, a compiler could
optimize the (apply #'...), but why should it have to?

∂18-Nov-88  0021	CL-Cleanup-mailer 	Re: Issue HASH-TABLE-STABILITY 
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 18 Nov 88  00:21:50 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa17890; 18 Nov 88 0:55 EST
Received: from draper.com by RELAY.CS.NET id ad02405; 17 Nov 88 15:51 EST
Date: Thu, 17 Nov 88 09:18 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue HASH-TABLE-STABILITY
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525

Concerning "EQ but not EQUAL"...
 
Is a CL implementation in error if it implements EQUAL by returning T if
the arguments are EQ, as a performance hack?

∂18-Nov-88  0354	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-STABILITY (version 1)   
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 18 Nov 88  03:53:10 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa05167; 17 Nov 88 16:52 GMT
Date: Thu, 17 Nov 88 17:17:09 GMT
Message-Id: <17889.8811171717@subnode.aiai.ed.ac.uk>
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

∂18-Nov-88  1518	CL-Cleanup-mailer 	Issue HASH-TABLE-STABILITY
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 18 Nov 88  15:17:54 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02487g; Fri, 18 Nov 88 15:16:19 PST
Received: by bhopal id AA10635g; Fri, 18 Nov 88 15:15:00 PST
Date: Fri, 18 Nov 88 15:15:00 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811182315.AA10635@bhopal>
To: SEB1525@draper.com
Cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: "Steve Bacher (Batchman)"'s message of Thu, 17 Nov 88 09:18 EST <8811180823.AA01976@lucid.com>
Subject: Issue HASH-TABLE-STABILITY

re: Concerning "EQ but not EQUAL"...

    Is a CL implementation in error if it implements EQUAL by returning T if
    the arguments are EQ, as a performance hack?

The buzz words "EQ but not EQUAL" imply calling EQUAL at two different 
times; the altered item (which remains EQ to itself) is no longer EQUAL
to the "platonic" original version.

-- JonL --

∂18-Nov-88  1522	CL-Cleanup-mailer 	Issue: HASH-TABLE-STABILITY (version 1)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 18 Nov 88  15:22:45 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02504g; Fri, 18 Nov 88 15:21:06 PST
Received: by bhopal id AA10651g; Fri, 18 Nov 88 15:19:52 PST
Date: Fri, 18 Nov 88 15:19:52 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811182319.AA10651@bhopal>
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
Cc: @sail.stanford.edu:jonl@lucid.com, cl-cleanup@sail.stanford.edu
In-Reply-To: Jeff Dalton's message of Thu, 17 Nov 88 17:17:09 GMT <17889.8811171717@subnode.aiai.ed.ac.uk>
Subject: Issue: HASH-TABLE-STABILITY (version 1)

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.  [But you, Jeff, are a somewhat advanced-
to-wizard person, so you may not be the ultimate test needed.]

-- JonL --

∂19-Nov-88  1358	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-STABILITY (version 1)   
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 19 Nov 88  13:57:08 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa05348; 19 Nov 88 21:09 GMT
Date: Sat, 19 Nov 88 21:35:47 GMT
Message-Id: <1145.8811192135@subnode.aiai.ed.ac.uk>
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

∂20-Nov-88  1855	CL-Cleanup-mailer 	Re: Issue GC-MESSAGES (Version 2)   
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 20 Nov 88  18:54:33 PST
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 20 Nov 88 19:11:12 EST
To: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue GC-MESSAGES (Version 2) 
In-reply-to: Your message of Mon, 14 Nov 88 10:13:00 -0500.
             <881114101307.3.KMP@BOBOLINK.SCRC.Symbolics.COM> 
Date: Sun, 20 Nov 88 19:10:53 EST
From: Scott.Fahlman@B.GP.CS.CMU.EDU


Just catching up on old cleanup mail...

If we do want to address the problem of standardizing GC-message typeout, I
prefer the kind of solution that KMP describes for the Symbolics system: a
special variable that directs GC messages to some specified stream, or that
disables them if it is NIL.  The proposed WITH-GC-STATUS macro only lets
you control typeout messages for the things it surrounds; a special
variable would give you global control as well.

-- Scott

∂20-Nov-88  1855	CL-Cleanup-mailer 	Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)   
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 20 Nov 88  18:54:50 PST
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 20 Nov 88 21:53:06 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c) 
In-reply-to: Your message of Tue, 15 Nov 88 17:34:00 -0500.
             <881115173439.7.KMP@BOBOLINK.SCRC.Symbolics.COM> 
Date: Sun, 20 Nov 88 21:52:46 EST
From: Scott.Fahlman@B.GP.CS.CMU.EDU


A few comments on KMP's triple-barrelled proposal:

First, the problem statement says:

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

That's just a statement of fact.  It doesn't give the reader any clear idea
what we think the problem is.

I'm strongly opposed to the IMPLICIT-COPY option.  For users of
implementations that have non-adjustable arrays and that therefore do the
copy, this change would be very treacherous.  If the user is holding on to
old pre-adjustment array, things could start to fail in very mysterious and
confusing ways.  We get lots of spurious bug reports from users who screw
themselves by calling DELETE without doing the SETQ, despite all our
warnings.  This would bite fewer people, but might be harder to diagnose
when it did bite them.  And since code written on Symbolics systems, for
example, would work fine without the SETQ, it would bite people at the time
of a port to a standard architecture, often when the original author of the
code is not readily available for consultation.

I've got no strong objection to the SIGNAL-ERROR proposal, but if I were a
Symbolics-only user whose code was going to be broken by this, I might well
object.

Of the three options offered, I prefer SIGNAL-ERROR+NEW-FUNCTION, but again
I think this might bother users who are living happily under the current
system.  Also, a minor point, I think the new function should not be called
COPY-ARRAY if in fact it does adjustment.  It would be clearer to call it
FORCE-ADJUST-ARRAY or something like that.  Better still, we could just add
a :FORCE keyword arg to ADJUST-ARRAY that, if non-null, says to do the copy
in the case of receiving a non-adjustable array; the default value would be
NIL.

There's a fourth option we might want to consider: it would be like
SIGNAL-ERROR+NEW-FUNCTION, but implementations are only required to signal
the error in cases where they are unable to return an adjusted array that
is EQ to the old one.  If they can manage to adjust the array and return
it, they are allowed to do so, regardless of whether it was created with
the ADJUSTABLE keyword.  This would not break existing code in systems
where all arrays are adjustable, but would signal a nice solid
non-mysterious error when this code is ported to a different system.

-- Scott

∂21-Nov-88  1119	CL-Cleanup-mailer 	Re: Issue DOTTED-MACRO-FORMS   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Nov 88  11:19:12 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 495962; Mon 21-Nov-88 14:19:10 EST
Date: Mon, 21 Nov 88 14:19 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue DOTTED-MACRO-FORMS
To: SEB1525@draper.com
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: The message of 17 Nov 88 08:22 EST from "Steve Bacher (Batchman)" <SEB1525@draper.com>
Message-ID: <881121141923.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Thu, 17 Nov 88 08:22 EST
    From: "Steve Bacher (Batchman)" <SEB1525@draper.com>

    ... Why not be able to say ... (format nil format-text . format-args) ...
 
People ask for this a lot. It would be fun in the situations where it works,
but it's too error-prone. People like the ability to substitute one expression
for another in an evaluable position. Consider, then, what happens if you
substitute `(cons 'x format-args)' for `format-args' in the above expression:

 (format nil format-text . (cons 'x format-args))
 >>Error: Unbound variable: CONS

∂21-Nov-88  1502	CL-Cleanup-mailer 	Issue: COERCE-INCOMPLETE (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Nov 88  15:02:05 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 496145; Mon 21-Nov-88 18:02:01 EST
Date: Mon, 21 Nov 88 18:02 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COERCE-INCOMPLETE (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881121180215.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

Issue:		 COERCE-INCOMPLETE
Reference:	 COERCE (p50)
Category:	 ADDITION
Edit history:	 Version 1 of COERCE-INCOMPLETE, 26-Feb-88 by M. Ida
		 Version 1 of COERCE-FROM-TYPE,  20-Jun-88 by Pitman
		 Version 2 of COERCE-INCOMPLETE, 21-Nov-88 by Pitman
Required-Issues: TYPE-OF-UNDERCONSTRAINED

Problem Description:

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

  For example, if the symbol STRING were permitted as a second argument
  to coerce, as in (COERCE NIL 'STRING), there would be two posssible
  return values: "" or "NIL". The choice would be arbitrary and would
  have to be specified by the documentation. No matter which was chosen,
  it would probably turn out to be a problem for some applications at
  some times.

  Another example is (COERCE (CHAR-CODE #\A) 'STRING). This might
  return the same as (FORMAT NIL "~D" (CHAR-CODE #\A)) -- "65" in
  most ASCII-based implementations -- or it might return "A". Again,
  the choice would be arbitrary.

  There is clear desire on the part of the user community to lift some of
  the existing restrictions on arguments to COERCE, but because of legitimate
  concerns about ambiguities, the Common Lisp designers have thus far
  refused to do so.

  Unfortunately, the failure of COERCE to handle these cases means it is
  very difficult to learn to use COERCE. And the fact that COERCE is not
  easily learned contributes to difficulty in learning Common Lisp because
  instead of a single coercion operator with general purpose semantics, a
  number of very special purpose coercion operators must be learned instead.

  Some middle ground needs to be found, which neither compromises the
  clear semantics and portable nature of COERCE nor complicates COERCE
  in a way that makes it unlearnable.

  Also, some people have expressed a desire for COERCE to be more 
  `symmetric.' Usually they seem to mean that they want it to be the case
  that if (COERCE x y) works, then (COERCE (COERCE x y) (TYPE-OF x)) 
  should also work. Although this is not an essential desire, it would
  certainly be nice to achieve.

Proposal:

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

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

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

  Define new types as follows:

	CHAR-CODE					[Type]

	The subrange of the integers which are valid character codes.
	This type could be defined by:

	  (DEFTYPE CHAR-CODE () `(INTEGER 0 (,CHAR-CODE-LIMIT)))

	CHAR-INT					[Type]

	The subrange of the integers which are valid char ints.
	This would probably want to be defined in an 
	implementation-dependent way since there is no
	CHAR-INT-LIMIT, but a crude approximation might be:

	  (DEFTYPE CHAR-CODE ()
	    `(INTEGER 0 ,(CODE-CHAR (- CHAR-CODE-LIMIT 1)
				    (- CHAR-BITS-LIMIT 1)
				    (- CHAR-FONT-LIMIT 1))))

	ACCESSIBLE-SYMBOL				[Type]

	The set of symbols accessible the current package.
	This type could be defined by:
	
	  (DEFUN SYSTEM::ACCESSIBLE-SYMBOL-P (X)
	    (AND (SYMBOLP X)
	         (MULTIPLE-VALUE-BIND (SYMBOL FOUND)
		     (FIND-SYMBOL (SYMBOL-NAME X) *PACKAGE*)
		   (AND FOUND (EQ SYMBOL X)))))

	  (DEFTYPE ACCESSIBLE-SYMBOL () 
	    `(SATISFIES SYSTEM::ACCESSIBLE-SYMBOL-P))

	INTEGER-STRING					[Type]

	The set of strings which can be successfully parsed by
	PARSE-NAMESTRING. This type could be defined by:

	  (DEFUN SYSTEM::INTEGER-STRING-P (X)
	    (AND (STRINGP X)
	         (DOTIMES (I (LENGTH X) T)
		   (LET ((CHAR (AREF X I)))
		     (UNLESS (OR (DIGIT-CHAR-P CHAR)
			         (AND (= I 0) (MEMBER CHAR '(#\+ #\-))))
		       (RETURN NIL))))))

	  (DEFTYPE INTEGER-STRING () `(SATISFIES SYSTEM::INTEGER-STRING-P))

	INTEGRAL-FLOAT					[Type]

	The set of floats which have no fraction. Put another way, the set of
	floats X for which there is some integer Y such that (= X Y).
	This could be defined by:

	  (DEFUN SYSTEM::INTEGRAL-FLOAT-P (X)
	    (AND (TYPEP X 'FLOAT)
		 (OR (ZEROP X)
	             (MULTIPLE-VALUE-BIND (QUOTIENT REMAINDER)
		         (TRUNCATE X)
		       (DECLARE (IGNORE QUOTIENT))
		       (ZEROP REMAINDER)))))

	 (DEFTYPE INTEGRAL-FLOAT-P () `(SATISFIES SYSTEM::INTEGRAL-FLOAT-P))

  Extend COERCE to handle at least the following cases:

   1. CHARACTER <-> STRING

      a. (COERCE x 'STRING 'CHARACTER) == (STRING x)
      b. (COERCE x 'CHARACTER 'STRING) == (CHARACTER x)

   2. CHAR-CODE <-> CHARACTER

      a. (COERCE x 'CHARACTER 'CHAR-CODE) == (CODE-CHAR x)
      b. (COERCE x 'CHAR-CODE 'CHARACTER) == (CHAR-CODE x)

   3. CHAR-INT <-> CHARACTER

      a. (COERCE x 'CHARACTER 'CHAR-INT) == (INT-CHAR x)
      b. (COERCE x 'CHAR-INT 'CHARACTER) == (CHAR-INT x)

   4. STRING <-> SYMBOL

      a. (COERCE x 'SYMBOL 'STRING) == (MAKE-SYMBOL x)
      b. (COERCE x 'STRING 'SYMBOL) == (SYMBOL-NAME x)

   5. STRING <-> ACCESSIBLE-SYMBOL

      a. (COERCE x 'ACCESSIBLE-SYMBOL 'STRING) == (INTERN x)
      b. (COERCE x 'STRING 'ACCESSIBLE-SYMBOL) == (SYMBOL-NAME x)

   6. INTEGER <-> INTEGER-STRING

      a. (COERCE x 'INTEGER-STRING 'INTEGER)
	 == (WRITE-TO-STRING X :BASE 10 :RADIX NIL)

      b. (COERCE x 'INTEGER 'INTEGER-STRING)
	 == (PARSE-INTEGER x)

   7. CHAR-CODE <-> STRING

      a. (COERCE x 'STRING 'CHAR-CODE) ==
	 == (COERCE (COERCE x 'CHARACTER 'CHAR-CODE) 'STRING 'CHARACTER)
	 == (STRING (CODE-CHAR x))

      b. (COERCE x 'CHAR-CODE 'STRING)
	 == (COERCE (COERCE x 'CHARACTER 'STRING) 'CHAR-CODE 'CHARACTER)
	 == (CHAR-CODE (CHARACTER x))

   8. CHAR-INT <-> STRING

      a. (COERCE x 'STRING 'CHAR-INT) ==
	 == (COERCE (COERCE x 'CHARACTER 'CHAR-INT) 'STRING 'CHARACTER)
	 == (STRING (INT-CHAR x))

      b. (COERCE x 'CHAR-INT 'STRING)
	 == (COERCE (COERCE x 'CHARACTER 'STRING) 'CHAR-INT 'CHARACTER)
	 == (CHAR-INT (CHARACTER x))

   9. CHAR-CODE <-> SYMBOL

      a. (COERCE x 'SYMBOL 'CHAR-CODE)
	 == (COERCE (COERCE x 'STRING 'CHAR-CODE) 'SYMBOL 'STRING)
	 == (MAKE-SYMBOL (STRING (CODE-CHAR x)))

      b. (COERCE x 'CHAR-CODE 'SYMBOL)
	 == (COERCE (COERCE x 'STRING 'SYMBOL) 'CHAR-CODE 'STRING)
	 == (CHAR-CODE (CHARACTER (SYMBOL-NAME x)))

  10. CHAR-INT <-> SYMBOL

      a. (COERCE x 'SYMBOL 'CHAR-INT)
	 == (COERCE (COERCE x 'STRING 'CHAR-INT) 'SYMBOL 'STRING)
	 == (MAKE-SYMBOL (STRING (INT-CHAR x)))

      b. (COERCE x 'CHAR-INT 'SYMBOL)
	 == (COERCE (COERCE x 'STRING 'SYMBOL) 'CHAR-INT 'STRING)
	 == (CHAR-INT (CHARACTER (SYMBOL-NAME x)))

  11. CHAR-CODE <-> ACCESSIBLE-SYMBOL

      a. (COERCE x 'ACCESSIBLE-SYMBOL 'CHAR-CODE)
	 == (COERCE (COERCE x 'STRING 'CHAR-CODE) 'ACCESSIBLE-SYMBOL 'STRING)
	 == (INTERN (STRING (CODE-CHAR x)))

      b. (COERCE x 'CHAR-CODE 'ACCESSIBLE-SYMBOL)
	 == (COERCE (COERCE x 'STRING 'ACCESSIBLE-SYMBOL) 'CHAR-CODE 'STRING)
	 == (CHAR-CODE (CHARACTER (SYMBOL-NAME x)))

  12. CHAR-INT <-> ACCESSIBLE-SYMBOL

      a. (COERCE x 'ACCESSIBLE-SYMBOL 'CHAR-INT)
	 == (COERCE (COERCE x 'STRING 'CHAR-INT) 'ACCESSIBLE-SYMBOL 'STRING)
	 == (INTERN (STRING (INT-CHAR x)))

      b. (COERCE x 'CHAR-INT 'ACCESSIBLE-SYMBOL)
	 == (COERCE (COERCE x 'STRING 'ACCESSIBLE-SYMBOL) 'CHAR-INT 'STRING)
	 == (CHAR-INT (CHARACTER (SYMBOL-NAME x)))

  13. PATHNAME <-> STRING

      a. (COERCE x 'STRING 'PATHNAME)
	 == (NAMESTRING x)

      b. (COERCE x 'PATHNAME 'STRING)
	 == (PARSE-NAMESTRING x)

  14. INTEGRAL-FLOAT <-> INTEGER

      a. (COERCE x 'INTEGER 'INTEGRAL-FLOAT)
	 == (TRUNCATE x)

      b. (COERCE x 'INTEGRAL-FLOAT 'INTEGER)
	 == (FLOAT x)

  Note that restrictions on the X argument to COERCE are as they would
  be for the corresponding function. For example, in 1b only strings of
  length 1 can be converted by CHARACTER.

  Observe that in some cases, such as (COERCE NIL 'STRING) where the first
  argument has a type which is a subtype of more than one of the above
  cases, the result may not be what the user expects. To get a safe result
  from COERCE, use of the third argument is strongly recommended.
  (COERCE NIL 'STRING 'SYMBOL) and (COERCE NIL 'STRING 'LIST) are not
  subject to the confusion that (COERCE NIL 'STRING) is.

Rationale:

  These proposed extensions make COERCE able to deal with a much larger
  space of type coercions without the problems of ambiguity raised in
  the Problem Description.

  The proposed extensions are, for the most part, fairly symmetric.
  Nearly every coercion that COERCE could do could be undone in a 
  fairly straightforward and reasonably reliable way.

  Compatibility with the old style of coerce is handled by making the
  third argument optional.

  This proposal is upward compatible with the existing semantics of COERCE.
  (The previous version of this proposal, by M. Ida, proposed incompatible
  changes.)

Current Practice:

  Probably no one implements the proposed behavior at this time.

Cost to Implementors:

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

Cost to Users:

  This change is upward compatible.

Cost of Non-Adoption:

  Various proposals to extend COERCE would probably not pass because
  not everyone can agree on how to view the type of the first argument.

Benefits:

  Currently, whenver documentation refers to something being `coerced'
  from one type or another, it might mean that COERCE is called, or it
  might mean that some more specialized operator is called. This proposal
  brings us much closer to having the meaning of "is coerced to" be
  "the COERCE function is called", which would make things easier on
  the consumers of that documentation.

Aesthetics:

  This proposal regularizes the semantics of COERCE by making it more
  predictable and more 

  Pitman thinks this proposal would greatly improve the aesthetics of
  COERCE. Does anyone want to present  

Discussion:

  For purposes of getting this proposal through in parallel, we have not
  any assumptions about the impending character proposal. Nothing proposed
  in this document is inherently in conflict with any potential output of
  the Characters Committee. The fact that characters may have multiple
  representations as integers is an important way to highlight the value of
  this proposal, which is why character issues are included.

  Needless to say, the proposal TYPE-OF-UNDERCONSTRAINED will need to be
  dealt with. If a CL implementation is permitted to always return T for 
  (TYPE-OF anything), then the defaulting of the third argument in this
  proposal is not going to work so well. That's why that issue is listed
  as a `required issue' in the heading above.

  Pitman supports this proposal.

  Although this proposal is not the same in detail as M. Ida's original
  proposal, it does address the same issues.  Pitman is hopeful that the
  alternative solutions proposed here would still be satisfactory to the
  Japanese community, and looks forward to feedback from that community
  about this issue.

∂21-Nov-88  1643	CL-Compiler-mailer 	Re:  issue IN-PACKAGE-FUNCTIONALITY
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Nov 88  16:43:51 PST
Received: from Semillon.ms by ArpaGateway.ms ; 21 NOV 88 16:42:06 PST
Date: 21 Nov 88 16:41 PST
From: masinter.pa@Xerox.COM
Subject: Re:  issue IN-PACKAGE-FUNCTIONALITY
In-reply-to: cperdue@Sun.COM (Cris Perdue)'s message of Thu, 13 Oct 88
 16:00:42 PDT
To: cl-cleanup@sail.stanford.edu
cc: cl-compiler@sail.stanford.edu
Message-ID: <881121-164206-8723@Xerox>

My belief is that we can fix the "problem" stated in this issue--namely
that the current dual purpose of IN-PACKAGE reduces error checking--by
submitting a proposal as follows:

a) this proposal should say only:

  Eliminate the ability of IN-PACKAGE to create a package on demand.
  Eliminate the :NICKNAMES and :USE arguments to IN-PACKAGE, since they
  are no longer needed.


b) the DEFPACKAGE issue itself should contain the phrase 
"Clarify that DEFPACKAGE is the preferred way to declare a package,
  and MAKE-PACKAGE is the preferred way to construct a package at runtime."

c) The proposal

 "Require IN-PACKAGE to signal an error if the package does not exist."

should be changed; instead, the results are unspecified. Note that
implementations of CLtL might indeed create the package. This is exactly
because of the compatibility issue.

d) the proposal
"Eliminate the compile-time processing requirement for all package-related
  functions except IN-PACKAGE and DEFPACKAGE."

should be withdrawn at this time to be dealt with more uniformly by the
compiler committee.

∂21-Nov-88  1724	CL-Cleanup-mailer 	Issue: PACKAGE-DELETION (Version 5) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Nov 88  17:23:59 PST
Received: from Semillon.ms by ArpaGateway.ms ; 21 NOV 88 17:19:10 PST
Date: 21 Nov 88 17:18 PST
From: masinter.pa@Xerox.COM
To: CL-Cleanup@SAIL.Stanford.EDU
Subject: Issue: PACKAGE-DELETION (Version 5)
Line-fold: NO
Message-ID: <881121-171910-8795@Xerox>

I attempted to clarify that FIND-PACKAGE and INTERN have unspecified
results if handed a deleted-package object.

There was I think a mistake in the description of what happens if
other packages use the one being deleted, since it said something about
there being no other packages on the use list, but generally, if there is
a "use list" at all , it points to packages that are used rather than packages
that use the given one.

Can anyone supply a sample implementation of DELETE-PACKAGE?


!
Forum:	Cleanup
Issue:        PACKAGE-DELETION
References:   Packages (pp171-192), PACKAGE-NAME (p184), PACKAGEP (p76)
Category:     ADDITION
Edit history: 30-Sep-88, Version 1 by Pitman
	      01-Oct-88, Version 2 by Pitman
	      04-Oct-88, Version 3 by Pitman
		(provide for correctable errors in some cases)
	      07-Oct-88, Version 4 by JonL
		21-Nov-88, Version 5 by Masinter


Problem Description:

  There is no way to get rid of a package in Common Lisp.

  This absence makes interactive development work tricky in some
  implementations. If a package is accidentally built incorrectly, the
  user must either rename the package to another package or start over
  by reloading his program in a fresh lisp image.

  Some programs need to create and destroy packages at runtime.
  Without such a facility, some clumsy combination of RENAME-PACKAGE,
  UNINTERN, and UNUSE-PACKAGE is usually made to work. However, it is
  easy for a casual programmer to forget to undo some of the 
  bookkeeping, leading to unwanted effects.

Proposal (PACKAGE-DELETION:NEW-FUNCTION):

  Introduce the function DELETE-PACKAGE, described as follows:

  DELETE-PACKAGE package                                 [Function]

   Deletes PACKAGE from all package system data structures. PACKAGE may
   be either a package or the name of a package.

   If PACKAGE is a package name (i.e., not type PACKAGE) which does not
   currently name a package, a correctable error is signalled. If
   continued, no deletion action is attempted. Instead, DELETE-PACKAGE
   immediately returns NIL.

   If PACKAGE is a package object (i.e., an object of type PACKAGE)
   which has already been deleted, no error is signalled and no further
   deletion action is attempted. Instead, DELETE-PACKAGE immediately
   returns NIL.

   If the designated package is used by other packages, a correctable
   error is signalled. If continued, the effect of UNUSE-PACKAGE is
   done to remove any dependencies, causing its external symbols to stop
   being accessible to those packages. Once this is done, DELETE-PACKAGE
   goes on to delete the package just as it would had there been no 
   packages that used it.

   After this operation completes, the contents of the symbol-package  
   slot of any symbol homed in the deleted package is unspecified; for 
   those symbols not homed in that package, the contents remain unchanged.
   Except for this, symbols in the deleted package are not modified in
   any other way.  

   The effect of DELETE-PACKAGE is that the name and
   nicknames of the designated package cease to be recognized package
   names.   The package object is still a package -- PACKAGEP is true
   of it -- but  PACKAGE-NAME will return NIL.  The effect of any other 
   package operation on PACKAGE once it has been deleted is undefined.
   In particular, FIND-SYMBOL, INTERN and other functions that
  look for a symbol name in a package will have unspecified results if
  called with *PACKAGE* bound to the deleted package or with the
  deleted package as an argument.

   DELETE-PACKAGE returns T if the deletion attempt was successful
   and NIL otherwise.

Test Case:

  (SETQ *FOO-PACKAGE* (MAKE-PACKAGE "FOO" :USE NIL))
  (SETQ *FOO-SYMBOL*  (INTERN "FOO" *FOO-PACKAGE*))
  (EXPORT *FOO-SYMBOL* *FOO-PACKAGE*)

  (SETQ *BAR-PACKAGE* (MAKE-PACKAGE "BAR" :USE '("FOO")))
  (SETQ *BAR-SYMBOL*  (INTERN "BAR" *BAR-PACKAGE*))
  (EXPORT *FOO-SYMBOL* *BAR-PACKAGE*)
  (EXPORT *BAR-SYMBOL* *BAR-PACKAGE*)

  (SETQ *BAZ-PACKAGE* (MAKE-PACKAGE "BAZ" :USE '("BAR")))

  (SYMBOL-PACKAGE *FOO-SYMBOL*)        => #<Package "FOO">
  (SYMBOL-PACKAGE *BAR-SYMBOL*)        => #<Package "BAR">

  (PRIN1-TO-STRING *FOO-SYMBOL*)       => "FOO:FOO"
  (PRIN1-TO-STRING *BAR-SYMBOL*)       => "BAR:BAR"

  (FIND-SYMBOL "FOO" *BAR-PACKAGE*)    => FOO:FOO, :EXTERNAL

  (FIND-SYMBOL "FOO" *BAZ-PACKAGE*)    => FOO:FOO, :INHERITED
  (FIND-SYMBOL "BAR" *BAZ-PACKAGE*)    => BAR:BAR, :INHERITED

  (PACKAGEP *FOO-PACKAGE*)             => T
  (PACKAGEP *BAR-PACKAGE*)             => T
  (PACKAGEP *BAZ-PACKAGE*)             => T

  (PACKAGE-NAME *FOO-PACKAGE*)         => "FOO"
  (PACKAGE-NAME *BAR-PACKAGE*)         => "BAR"
  (PACKAGE-NAME *BAZ-PACKAGE*)         => "BAZ"

  (PACKAGE-USE-LIST *FOO-PACKAGE*)     => ()
  (PACKAGE-USE-LIST *BAR-PACKAGE*)     => (#<Package FOO>)
  (PACKAGE-USE-LIST *BAZ-PACKAGE*)     => (#<Package BAR>)

  (PACKAGE-USED-BY-LIST *FOO-PACKAGE*) => (#<Package BAR>)
  (PACKAGE-USED-BY-LIST *BAR-PACKAGE*) => (#<Package BAZ>)
  (PACKAGE-USED-BY-LIST *BAZ-PACKAGE*) => ()

  (DELETE-PACKAGE *BAR-PACKAGE*)
  Error: Package BAZ uses package BAR.
  If continued, BAZ will be made to unuse-package BAR,
	        and then BAR will be deleted.
  Type :CONTINUE to continue.
  Debug> :CONTINUE
  				       => T

  (SYMBOL-PACKAGE *FOO-SYMBOL*)        => #<Package "FOO">
  (SYMBOL-PACKAGE *BAR-SYMBOL*)        is unspecified

  (PRIN1-TO-STRING *FOO-SYMBOL*)       => "FOO:FOO"
  (PRIN1-TO-STRING *BAR-SYMBOL*)       is unspecified

  (FIND-SYMBOL "FOO" *BAR-PACKAGE*)    is undefined

  (FIND-SYMBOL "FOO" *BAZ-PACKAGE*)    => NIL, NIL
  (FIND-SYMBOL "BAR" *BAZ-PACKAGE*)    => NIL, NIL

  (PACKAGEP *FOO-PACKAGE*)             => T
  (PACKAGEP *BAR-PACKAGE*)             => T
  (PACKAGEP *BAZ-PACKAGE*)             => T

  (PACKAGE-NAME *FOO-PACKAGE*)         => "FOO"
  (PACKAGE-NAME *BAR-PACKAGE*)         => NIL
  (PACKAGE-NAME *BAZ-PACKAGE*)         => "BAZ"

  (PACKAGE-USE-LIST *FOO-PACKAGE*)     => ()
  (PACKAGE-USE-LIST *BAR-PACKAGE*)     is undefined
  (PACKAGE-USE-LIST *BAZ-PACKAGE*)     => ()

  (PACKAGE-USED-BY-LIST *FOO-PACKAGE*) => ()
  (PACKAGE-USED-BY-LIST *BAR-PACKAGE*) is undefined
  (PACKAGE-USED-BY-LIST *BAZ-PACKAGE*) => ()

Rationale:

  This facility corrects the deficiency described in the problem description.

Current Practice:

  Symbolics has a function PKG-KILL which satisfies the proposed behavior
  except that an error is not signalled if the package is used.
  When a package is killed by PKG-KILL, the home package of all symbols
  in that package are left undisturbed (i.e., local symbols pointing to
  the killed package); this aspect is compatible with the stated proposal.

  Procyon Common Lisp has a function called DELETE-PACKAGE already. It
  returns the name   of the package so deleted (as a string). [Perhaps it also
  differs in the correctability of the errors it signals?]

  Lucid Common Lisp implements DELETE-PACKAGE, except that the continuation
  option for a name that doesn't name a package is different.

Cost to Implementors:

  The cost of providing this facility is probably small.

Cost to Users:

  Very slight to none. This change is essentially compatible.

  Some code which cached packages in variables might have to be slightly
  more cautious, but experience in the Symbolics implementation suggests
  that it's really the responsibility of the person doing the DELETE-PACKAGE
  to take care of worrying about the effects of having deleted the package:
  normal programs need not bother testing a package for validity (using
  PACKAGE-NAME) before using it.

Cost of Non-Adoption:

  Getting rid of a package would continue to be difficult to do portably.

Benefits:

  Better control of storage usage would be available portably.

Aesthetics:

  No significant effect.

Discussion:

  This was discussed as part of a larger bulk issue of how to undo all
  sorts of definitions. Since that proposal has not gone anywhere 
  (perhaps bogged down under its own weight), this subtopic has been
  broken off for separate discussion.

  Note that if a symbol's package component is modified as a result
  of being "unintern'd" from a delete packaged, then it is unspecified
  as to how it will  be printed.

∂21-Nov-88  1948	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Nov 88  19:48:42 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00964g; Mon, 21 Nov 88 19:46:24 PST
Received: by bhopal id AA15102g; Mon, 21 Nov 88 19:45:10 PST
Date: Mon, 21 Nov 88 19:45:10 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811220345.AA15102@bhopal>
To: Scott.Fahlman@B.GP.CS.CMU.EDU
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Scott.Fahlman@B.GP.CS.CMU.EDU's message of Sun, 20 Nov 88 21:52:46 EST <8811210257.AA03776@lucid.com>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c) 

re: First, the problem statement says:

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

    That's just a statement of fact.  It doesn't give the reader any clear idea
    what we think the problem is.

I for one don't think there is anything wrong with that "statement of
fact".  But since Symbolics' array implementation has always been in
direct violation of this prescription, we must assume that they (and
Kent in particular) feel that adjustability must not be "an option" --
that it must be required of all arrays.

Lucid will oppose any measures to make adjustablility required of all 
arrays.  This is precisly the one place where a good compiler on "stock 
hardware" must have some options for creating and using a subclass of 
arrays competitively with "Conventional" computer lanugages [note that 
"Conventional" begins with a "C"].  CL's SIMPLE-ARRAYs are that subclass;
and SIMPLE implies "not adjustable" because, regardless of whether or
not ADJUST-ARRAY returns a copy, there is no way to modify such low-
overhead arrays as per CLtL 297 [special-purpose hardware systems can 
do so however, by using "invisible pointers"].

Incidentally, Lucid has a function SYS:COPY-ARRAY which does just that
-- it makes a copy preserving all the array's attributes; thus I too
would not like to see this name taken for some ersatz ADJUST-ARRAY.  
Lucid implements (ADJUST-ARRAY-NOT-ADJUSTABLE:SIGNAL-ERROR).

There was one aspect of your "fourth option" suggestion that bears some 
thought.  Suppose we made the default value of the :adjustable argument 
to MAKE-ARRAY be implementation-dependent?  That way, when adjustability
comes "for free", the user might as well have it.  But if the user
***explicitly*** passes in the :adjustable argument as NIL, then
he ought to be able to check out portable code that way [i.e., find
out just where he may trying to adjust a "non-adjustable" array.]


-- JonL --

∂21-Nov-88  2251	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Nov 88  22:51:48 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 496430; Tue 22-Nov-88 01:51:41 EST
Date: Tue, 22 Nov 88 01:51 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)
To: jonl@lucid.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8811220345.AA15102@bhopal>
Message-ID: <881122015109.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

fyi, KMP does -not- want all arrays to be adjustable, and would prefer
strong checking -- ie, signal of error required when attempting to adjust
an array not declared adjustable.

arguably, this is because KMP has a lot of experience in trying to port
programs where this happened to be a problem and he wants not to have such
problems recur for himself or anyone else. further, KMP does not currently
maintain any programs which would be hurt by this change, so doesn't worry
about the cost of upgrading his code.

in contrast, Symbolics (a company with financial investment in a particular
interpretation of the topic in question) would have to reimplement a bunch
of stuff at considerable expense, and would have to (arguably gratuitously)
break its users' code.

the symbolics view is not that all arrays must be adjustable, by the way.
the symbolics view is that we recognize that in some implementations that
is too expensive even though in ours it is not. as such, from the local
perspective, :adjustable is present so that portable code can specify which
arrays need the greater overhead for the sake of implementations which must
distinguish. adjustable-array-p does not predicate whether the array was
created with :adjustable t, it predicates whether the array is adjustable.
nothing in CLtL specifies that omitting :adjustable or specifying 
:adjustable nil means you can't make the array adjustable. as such, 
symbolics makes all arrays (except for a -very- few) adjustable but you can
always reliably detect which arrays will be adjustable by calling 
adjustable-array-p (if you don't know the array's lineage from context),
and you can always force an array to be adjustable in the first place by
doing :adjustable t. this is a fully consistent point of view that is not
in conflict with CLtL. you may be sad that this loophole is there, but i
assure you that it is no perverse reading of CLtL that led to this
interpretation. it is my belief that if there is confusion it is because
people had differing views on what :adjustable was about when they went into
writing CLtL and the wording was frobbed to make everyone happy without
being explicit about why that particular wording made everyone happy.
it's a case of a situation where person A thinks that everything is either
black or white and person B does not. person A describes a frob as Black.
person B, thinking frobs are really gray says "couldn't we just say it's
not white?" person A, thinking this is the same thing, says "sure." and
voila, person A and person B both have their model of the world supported,
they both agree that frobs are not white, but yet they have -- in some other
sense -- not really agreed.

this is a lot of what the `explicitly vague' issues are about. just to make
the disagreement visible to the reader, so that people from neither camp will
later be surprised by the discrepancies which are bound to arise from
differing world models.

and, getting back to the original subject, other companies have used
extraordinary expense as a show-stopper on other issues. even though i
disagree with moon from an abstract point of view on this, i certainly
think it's both fair and appropriate for him to characterize my favorite
alternative as unreasonably expensive for symbolics, and i hope everyone
will give that position its due consideration.

∂22-Nov-88  1237	CL-Cleanup-mailer 	Re: Issue: COERCE-INCOMPLETE (Version 2) 
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 22 Nov 88  12:37:27 PST
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU; 22 Nov 88 14:13:50 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: COERCE-INCOMPLETE (Version 2) 
In-reply-to: Your message of Mon, 21 Nov 88 18:02:00 -0500.
             <881121180215.8.KMP@BOBOLINK.SCRC.Symbolics.COM> 
Date: Tue, 22 Nov 88 14:12:55 EST
From: Rob.MacLachlan@WB1.CS.CMU.EDU


I am bothered by the addition of various bizarre types to the type system
just so that coerce can do its thing.  Are these "real" types?  If so, what
do they mean in a declaration?  If not "real", then why do we call them types?

ACCESSIBLE-SYMBOL seems especially twisted.  The use of the "current
package" is the most problematical.  What is the "current package" for a
declaration?

Especially in a language with dynamic typing, the boundary between "type"
and "value" tends to blur, but I think that this proposal uses the Common
Lisp type system in a way that isn't very type-like.  I am very suspicious
of any type that must be defined using SATISFIES.

I also wonder about INTEGRAL-FLOAT.  To say that a float has "no fraction"
is meaningless, or at least confusing.  I think that you really mean that
the remainder is 0.0 when you truncate it, but it is unclear how you are
going to tell this other than by doing the truncation.  If you do the
truncation, you have the result anyway, so why call COERCE?

I think that in general, it is treacherous to support symmetric coercion
for any pair of types where the coercion in either direction is information
losing.  This also applies to all the symbol coercions.

The dependence on TYPE-OF is also bothersome.  Any clarafication of TYPE-OF
isn't really a clarification of TYPE-OF, it is a clarification of the legal
run-time type systems in a Common Lisp implementation.  I consider the
function performed by TYPE-OF to be very troublesome from a language design
perspective, and I would rather people didn't depend on it.

Also, there is an error in the approximate definition for CHAR-INT.  It
should be something like:

	  (DEFTYPE CHAR-INT ()
	    `(INTEGER 0
		      ,(CHAR-INT
			(CODE-CHAR (- CHAR-CODE-LIMIT 1)
				   (- CHAR-BITS-LIMIT 1)
				   (- CHAR-FONT-LIMIT 1)))))


  Rob

∂22-Nov-88  1347	CL-Cleanup-mailer 	Issue: LAMBDA-FORM (Version 4) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Nov 88  13:47:08 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 22 NOV 88 13:38:20 PST
Date: 22 Nov 88 13:35 PST
From: masinter.pa@Xerox.COM
Subject: Issue: LAMBDA-FORM (Version 4)
To: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <881122-133820-10646@Xerox>

I added to the cost, benefits and discussion section in an attempt to
reflect the subsequent discussion. NACKs only, please.

!
Forum: CLeanup
Issue:        LAMBDA-FORM
References:   LAMBDA (p59)
Related Issues: LISP-SYMBOL-REDEFINITION, PACKAGE-CLUTTER
Category:     ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman
	      16-Sep-88, Version 2 by Pitman
	      02-Oct-88, Version 3 by Pitman
	      22-Nov-88, Version 4 by Masinter

Problem Description:

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

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

  Also, even though the definition is trivial,

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

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

Proposal (LAMBDA-FORM:NEW-MACRO):

  Add a LAMBDA macro, which has equivalent effect to:

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

Rationale:

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

Test Case:

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

  #3: (MACROEXPAND '(LAMBDA (X) (+ X Y)))
      => (FUNCTION (LAMBDA (X) (+ X Y)))

Current Practice:

  Symbolics Genera implements NEW-MACRO.

  Symbolics Cloe does not offer a LAMBDA macro because users who defined
  their own in portable code complained that they were getting redefinition
  warnings that CLtL had led them to believe shouldn't happen. [Ironically,
  the redefinition warnings always came when they tried to define LAMBDA
  in the way it was already defined!]

  Many other Common Lisp implementations do not offer such a macro.

Cost to Implementors:

  The cost is trivial. A portable definition is shown in the
  problem description above.

Cost to Users:

  No conversion cost. This change is basically upward compatible.
  

Cost of Non-Adoption:

  There are no really major consequences of non-adoption.

Benefits:

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

Aesthetics:

  In Scheme, the operator of a function invocation form has the same
  evaluation semantics as the operands.  In CL, however, the operator is
  not evaluated in the same way that the operands are.  This definition
  of LAMBDA as a macro would obscure this difference. A novice Lisp 
  programmer might have a hard time understanding why the #' is 
  optional in

  (MAP [#'](LAMBDA (POINT) (+ (POINT-X POINT) (POINT-Y POINT))) 
          POINT-LIST)
  
 but is required in
     (MAP #'SUM-OF-COORDS POINT-LIST)

  This proposal "clutters" the language because it makes the syntax
  more complex.  LAMBDA is then used not only as a "flag" for
  introducing lambda-expressions, but also is a macro which generates
  functions. There is at least one precedent for having two
  operations that do the identical thing -- NOT and NULL. Both have
  been retained because they express different intents. In this case,
  the intent of #'xxx might be to ``access'' a function by name (the
  name of an anoymous function being its lambda expression), and the
  intent of (LAMBDA ...) is to ``create'' a function. This distinction
  is subtle but may be expressionally interesting to some programmers
  in some situations.

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

Discussion:

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

  Technically, CLtL does already permit implementations to predefine a
  LAMBDA macro, but most argue that this leeway was accidental. CLtL
  says that "all" functions, etc in CLtL must be in the LISP package,
  but it does not say "all and only". This oversight leaves enough room
  for implementors to add all manner of extra junk in the LISP package.
  A separate cleanup item (LISP-SYMBOL-REDEFINITION) addresses
 this issue.

  An earlier revision of this proposal considered the alternative of
  making this a new special form. Many people prefered that alternative.
  However, there were also strong objections to requiring a new special form;
  since the FUNCTION special form is still necessary (for #'symbol), 
  it was deemed better  to have LAMBDA a macro which is defined
  in terms of FUNCTION than to have both LAMBDA and FUNCTION
  as special forms.

∂22-Nov-88  1351	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; 22 Nov 88  13:51:37 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 496806; Tue 22-Nov-88 16:50:45 EST
Date: Tue, 22 Nov 88 16:50 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: COERCE-INCOMPLETE (Version 2) 
To: Rob.MacLachlan@WB1.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: The message of 22 Nov 88 14:12 EST from Rob.MacLachlan@WB1.CS.CMU.EDU
Message-ID: <881122165053.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

I'm willing to deal with this on a line-item basis if people want to point to
some line items they would strike, change, or add in order to fix things.
If people wanted to flush all of the made-up types, I wouldn't probably object.
But I hope they'd do it for a more purposeful reason than just because it
doesn't perpetuate the status quo. I'm hoping that we'll at least adopt CHAR-CODE
and CHAR-INT because I believe them to be the most useful.  What I wanted to
do, though, was to present a fully elaborated proposal because the last version
(COERCE-FROM-TYPE, v1) only alluded to what might be done and I was worried
that the idea wasn't clear in everyone's mind. Perhaps now it's all too clear. :-)

In the case of ACCESSIBLE-SYMBOL, I certainly agree with your reservations
to an extent, but let me tell you where I was coming from. Btw, I think
the SYMBOL coercion is far more suspect than the ACCESSIBLE-SYMBOL declaration
for reasons that I hope will become apparent.

Anyway, let me address a number of specific points in an attempt to keep
this complicated conversation focused...

 * Version 1 of COERCE-INCOMPLETE from Japan proposed that coercing an
   integer to a character should assume that INTERN should be called.
   I wanted to address that request specifically and not just leave it
   out as if I'd ignored their request.

   The reason I could not address their proposal by simply including it
   in mind is that it doesn't have the good `symmetry' property mentioned
   in the outline. If you do 
	(COERCE (COERCE *SOME-SYMBOL* 'STRING) 'SYMBOL)
   and INTERN is the coercion from symbol to string, then this is only an
   identity if *SOME-SYMBOL* is in the current package. The thing that an
   ACCESSIBLE-SYMBOL declaration would tell you is that 
	(EQ *SOME-SYMBOL* (INTERN (SYMBOL-NAME *SOME-SYMBOL*)))
   The KEYWORD declaration provides that same piece of information, of
   course, but it's not possible to make every symbol a keyword, while it
   is possible to make every symbol accessible (albeit not at the same time).

   As it happens, I don't feel a need to justify these as declarations. It's
   not like all declarations in CL are indispensable. Sometimes it's good to
   provide the capability just for completeness. There are plenty of other
   declarations that are equivalently useful/useless. Nevertheless, in a
   very real sense, they ought to be useful from both a discrimination and a
   declaration standpoint because as discriminators they can test whether
   COERCE is defined on them, and as declarations, they can say it is safe
   for COERCE to do a particular coercion which in the absence of that 
   declaration might be very questionable.

   These are not types in the sense that they could be classes, but that
   doesn't make them unimportant. They are view types which specifically
   address the issue that one real type (class) can be used to represent any
   of several abstract types. And COERCE is about coercing abstract types,
   not classes. If it were not, then it would be obvious what definition to
   give it in all cases purely on the basis of CLASS-OF and there would be
   no dispute.

 * The same problem came up with CHAR-CODE, by the way. The Japanese proposal
   specified that they wanted integers to be treated as char-codes for
   no apparent reason (other than, presumably, some particular pragmatic
   reason they were focused on at the time they wrote the proposal). I wanted
   to suit that need without compromising the useful property, so I concocted
   CHAR-CODE.

 * You seem down on TYPE-OF. There are two issues here really:

     - Is it necessary/appropriate for the `type' arguments to really be
       types. It is possible, of course, to do like DOCUMENTATION and just
       say there's a fixed list of words with no necessary relation to
       types, for example.

       In fact though, as I mentioned above, it's potentially useful, both
       for discrimination and declaration, for them to be actual types.
       So I saw no need to restrict that.

     - More importantly, I might want to say that COERCE should just take
       4 required arguments. In fact, I might want to invert arg3 and arg4
       so that "coerce X from fixnum to float" was written 
       (COERCE X 'FIXNUM 'FLOAT).

       The issues here, though, are ...

	 . Compatibility. Making the argument required means that we'd
           break existing code. My proposal avoids that problem. If we're
	   going to break existing code, I'd just as soon we can justify it.

	 . Convenience. Often, TYPE-OF (were it more well-defined), is
	   exactly what is needed, so I think it's reasonable to establish
	   it as a default. Further, the to-type is not something for which
	   there is likely to be reasonable default, so it wants to precede
	   the optinoal argument.

       So I hope you can see from this why I resisted both my inclination to
       make the `from' argument required, and to invert the argument order.

  * I am, by the way, disturbed by your use of the phrase "isn't very
    type-like". To me, the purpose of types is to identify the set of
    operations on an object, and to restrict the amount of discrimination
    which must be done for those operations which are generic. I think this
    satisfies that purpose of types to the letter. If you want to make the
    case that I'm doing something creative and interesting, then I'll buy
    into it. If you want to make the case that I'm doing something
    blasphemous, you'll have to advance a considerably more elaborate
    philosophy and convince me to buy into it. I'm not saying I won't listen.
    I'm just saying I don't see it.

  * On the subject of INTEGRAL-FLOAT, I confess to using sloppy wording.
    "no fraction" was obviously a poor choice. It took me all day to write this
    thing and I didn't expect it to be a final draft, so I won't be surprised
    if that's not the last such little typo.

    Ditto about the typo in CHAR-INT. Thanks for spotting it.

  * In answer to your question about why call COERCE (rather than FLOAT), I
    think the answers are two (somewhat related):

      - Some people just want to learn fewer operators. They needn't learn
	FLOAT if they know COERCE. I happen not to be one of those people,
	but I've heard it enough places to believe it to be true.

      - You may wonder why COERCE is powerful enough to not need FLOAT.
 	Note that currently, CL says you can convert any (non-complex)
	number to a FLOAT. But that's not invertible. If instead it said
	you could convert any rational to a float or any integer to an
	integral-float, both of those operations would be invertible.
  	Also, the union of these two capabilities (and of float<->float
 	conversion, if you insist) is as powerful as what's offered now.
	No functionality would be lost, and yet things would be described
	in a way that permitted the nice `symmetry' property we're talking
	about.

 * I'm confused about your remark that it is "treacherous to support 
   symmetric coercion for any pair of types where the coercion in either
   direction is information losing". I'm trying to work through the exercise
   to see if in fact any information is necessarily lost. Consider:
    (COERCE (COERCE " S:>kmp>foo.lisp " 'PATHNAME 'STRING) 'STRING 'PATHNAME)
   might return "S:>kmp>foo.lisp" rather than " S:>kmp>foo.lisp ".
   Perhaps that argues for saying the argument type should be NAMESTRING,
   rather than STRING, to emphasize that the exact contents of the string do
   not matter, and that all that matters is the fact that the string 
   represents a particular pathname. If that's all it represents, then no
   information has been lost in the coercion because spaces were not part of
   the information. Remember, information is not structure -- it is structure
   + an intent to interpret that structure according to a particular set of
   rules. If those rules do not distinguish two structurally different
   objects, then those objects are equal.

   Anyway, I don't even necessarily think we have to -say- that COERCE is
   symmetric by nature. It might just be nice if it turned out to be true
   by accident ("true", but not "necessarily true" in the terms of Krypke --
   is that how you spell his name?).

[I keep putting `symmetry' in quotes because something tells me that when
 mathematicians say `symmetric' they mean something different than what we
 mean here. I think we know what we mean, but until someone tells me the
 usage is correct (or that it is not, and supplied a better term), I'll keep
 quoting it.]

The bottom line is that people have complained a lot about COERCE and
I'm trying to figure out what we might do about this. I'm not trying to
force anything down anyone's throat. But if we are going to analyze the
problem, we should do it thoughtfully and expect that there may be some
intermediate expression swell of ideas before we arrive at a bottom line.
I appreciate your having taken the time to read through the proposal in
detail and to answer it constructively. I hope you'll have time to get to
this reply in as much detail.

In particular, I'm interested in whether you buy any of my arguments at
all, whether you think there's another solution to COERCE or if you
think it's fine as it is or if you think it's just hopelessly broken,
and whether there are particular changes that could be made to my
proposal to make it more palatable to you -- ie, is there anything of
value in what I've said or do you think it's just way off track?

If you have time to go back and read the Japanese proposal (as annotated
and mailed to X3J13 by Masinter just before the last X3J13 meeting), you
might find that helpful. If you've lost your copy, I'll be happy to forward
you a copy.

 -kmp

∂22-Nov-88  1414	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION (version 5)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Nov 88  14:14:19 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 22 NOV 88 13:57:42 PST
Date: 22 Nov 88 13:57 PST
From: masinter.pa@Xerox.COM
Subject: Issue: LISP-SYMBOL-REDEFINITION (version 5)
To: cl-cleanup@sail.stanford.edu
line-fold: no
Message-ID: <881122-135742-10719@Xerox>

I attempted to incorporate the extra cases Moon pointed out (on 13 Oct)
and reorganized the proposal a bit to avoid some of the circumlocutions
involved in saying "the consequences of blah blah ...  blah are undefined."

!
Issue:         LISP-SYMBOL-REDEFINITION
 
References:    Cleanup issue PACKAGE-CLUTTER
		CLtL pp 67-69 Defining named functions
 
Category:      CLARIFICATION
 
Edit history:  Masinter, Version 1, 17-Sep-88 from (Kolb, 14-Aug-87)
               Masinter, Version 2, 7-Oct-88
               Masinter, Version 3,  7-Oct-88, fix typos
               van Roggen, Version 4, 13-Oct-88, undefined, not unspecified
               Masinter, Version 5, 22-Nov-88, add more cases
 
Problem description:
 
Is it legal to redefine Common Lisp functions? There is no explicit
prohibition, and many implementations do allow redefinition of
functions in the Lisp package.
 
CLtL only says that special forms can not be redefined. But this doesn't 
solve the general problem of redefining system functions.
 
Proposal LISP-SYMBOL-REDEFINITION:DISALLOW

This proposal uses the phrase "the consequences are undefined" in the
sense that implementations may signal an error, or other undefined behavior
may ensue, and attempts to specify that user programs generally cannot
portably modify the behavior of the symbols in the LISP package.

For example, programming environments may warn the user about
redefinition of LISP symbols and then allow them. Some environments may
distinguish between functions that are safe to redefine and those that are
not.

Specify that the consequences of performing any of the following
operations are undefined:

* redefining as a function or macro any of the functions,
macros, or special forms defined in the LISP package;
* lexically defining (with FLET, LABELS or
MACROLET) any function or macro in the LISP package;
 
* attempting to rebind any symbol in CL defined as a constant;
this covers binding as with LET or LAMBDA, assignment
as with SETQ or SETF, or using MAKUNBOUND;
(implied by CLtL p. 69)

* defining type-specifiers as with DEFTYPE, DEFSTRUCT, or
DEFCLASS, any of the built in type specifiers, classes;

* defining or redefining SETF macros or functions of any
of the functions, macros or special forms that have specified
SETF behavior, using either DEFSETF or DEFINE-SETF-METHOD
(or with DEFUN if the proposal under SETF-FUNCTION-VS-MACRO
is adopted);

* applying TRACE to any function in the LISP package.

No other restrictions are placed on users attaching definitions
on symbols in the LISP package; for example, a user program
may 
(DEFVAR CAR 3)

Examples:
 
The behavior of the construct:
 
(FLET ((OPEN (filename &key direction) (format t "Open called....") 
			(OPEN filename :direction direction)))
    (with-open-file (x "frob" :direction ':output) 
		(format t "was Open called?")))
 
is undefined; for example, the macro expansion of with-open-file might refer
to the OPEN function and might not.
 
(DEFUN CAR (X) (CDR X))
 
might signal an error.
 
Rationale:
 
This proposal is the only simple resolution of the problem description that
we can imagine that is consistent with current implementation techniques.
 
Allowing arbitrary redefinition of symbols in the LISP package would place
severe restrictions on implementations not to actually use those symbols in
macro expansions of other LISP symbols, in function calls, etc. While some
looser restrictions might do for any particular Common Lisp implementation,
there seems to be no good way to distinguish between those symbols that are
redefinable and those that are not.
 
In general, programs can redefine functions safely by creating new symbols in
their own package, possibly shadowing the name.
 
Current practice:
 
Many Lisp environments have some mechanism for warning about redefinition of
Lisp symbols and preventing accidental redefinition while allowing it where
necessary (e.g., to patch the Lisp system itself, fix a bug, add an
optimization.)
 
Fewer check for lexical redefinition, since such redefinition is not as
dangerous. Certainly, there are some symbols that are never used in macro
expansions of the standard Common Lisp macros. However, implementations do
differ on the behavior of macro expansions.
 
Cost to Implementors:
 
This proposal clarifies the status quo -- that the consequences are undefined. It
allows and encourages implementors to check for such redefinition, but does not
require it.
 
Cost to Users:
 
This proposal clarifies that implementations are free to check for a condition
that they might not have before, and may clarify that some current user code is
non-portable.
 
Benefits:
 
This issue frequently arises. Adopting this proposal would clarify a frequent
source of question about Common Lisp. 
 
Cost of non-adoption:
 
Continued questions.
 
Esthetics:
 
Disallowing all redefinition is the simplest way of disallowing the ones that
really are trouble. 
 
Discussion:
 
There have been various proposals for allowing users to extend the "protection"
mechanism to their own macros, functions, packages. These proposals seem like
they are environment issues and not language ones, however. 
 
It is unfortunate that the restriction on reusing LISP package symbols in
FLET, LABELS or MACROLET is necessary, but the research into straightening out
the syntactic environment of macroexpansion isn't mature enough to put into
a standard yet.

∂22-Nov-88  1503	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 22 Nov 88  15:03:32 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01845g; Tue, 22 Nov 88 15:01:42 PST
Received: by bhopal id AA16647g; Tue, 22 Nov 88 15:00:25 PST
Date: Tue, 22 Nov 88 15:00:25 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811222300.AA16647@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Tue, 22 Nov 88 01:51 EST <881122015109.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)

Hmmm, that's a most interesting view!

Still, I would very much like to hear you opinion on my suggestion for a
way out of the "loophole" conflict; namely, allow the default setting of
the of :adjustable argument to MAKE-ARRAY to be implementation-dependent.
That way, we could maintain portability on what the :adjustable argument 
means (i.e. NIL means "Not Adjustable").   Symbolics' users would likely 
have no code broken, since the Symbolics default setting would be just
be :adjustable = T.  (Does any user *ever* explicitly supply a NIL for 
this argument?).


-- JonL --

∂22-Nov-88  1516	CL-Cleanup-mailer 	Issue: HASH-TABLE-STABILITY (version 1)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Nov 88  15:16:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 496880; Tue 22-Nov-88 18:15:39 EST
Date: Tue, 22 Nov 88 18:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-STABILITY (version 1)
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8811150714.AA25286@bhopal>
Message-ID: <19881122231526.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

This proposal is so long that I got lost while reading it.  From the
examples, one would think it was proposing some rules about what users
can expect when they modify objects that are used as keys of hash
tables.  However, I couldn't find anything actually proposed about that.
Most of the proposal seems to be about what performance users of hash
tables should expect, but I didn't see anything specific enough that I
could write a Common Lisp program to test whether an implementation
conforms to the proposal.

I think this proposal needs to be shortened and rewritten.  I would
prefer to see it speak about the behavior a user can or cannot expect
from a Common Lisp implementation, rather than in terms of internal
details of how Common Lisp might be implemented.  The essay on
implementation techniques could go in the discussion section, or could
be published separately, but I don't think it is suitable as a language
specification.

It might be a good idea to break this into two proposals, one on key
modification and a separate one on performance.  The reason I say that
is that I think standardizing performance is extremely difficult, and I
would hate to see the problems with that sink the other proposal.

∂22-Nov-88  1521	CL-Cleanup-mailer 	Re: Issue: COERCE-INCOMPLETE (Version 2) 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 22 Nov 88  15:21:36 PST
Received: by ti.com id AA27050; Tue, 22 Nov 88 17:20:31 CST
Received: from Kelvin by tilde id AA22859; Tue, 22 Nov 88 17:15:18 CST
Message-Id: <2805232596-1141998@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 22 Nov 88  17:16:36 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, Bartley@MIPS.csc.ti.com
Subject: Re: Issue: COERCE-INCOMPLETE (Version 2)
In-Reply-To: Msg of Mon, 21 Nov 88 18:02 EST from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

> Problem Description:
> 
>   COERCE is difficult to extend because ambiguities arise about the
>   source type of the coercion.
> 
>   For example, if the symbol STRING were permitted as a second argument
>   to coerce, as in (COERCE NIL 'STRING), there would be two posssible
>   return values: "" or "NIL". The choice would be arbitrary and would
>   have to be specified by the documentation. No matter which was chosen,
>   it would probably turn out to be a problem for some applications at
>   some times.

In my opinion, I don't buy this as being a valid problem.  There are
actually more possibilities than you have listed -- converting NIL to a
string might be desired to result in "", "()", "NIL", "nil", "Nil", or
"LISP:NIL" depending on what the user has in mind.  Granted that 
(COERCE NIL 'STRING 'SYMBOL) may be easier to remember than using 
SYMBOL-NAME or using (FORMAT NIL ...) and having to decide whether to
use ~A or ~S, what *PRINT-CASE* should be, etc., but is that really
making it easier for the user to get the result he wants, or is it just
allowing him to write code without having to think about what he really
means?   

>   14. INTEGRAL-FLOAT <-> INTEGER
> 
>       a. (COERCE x 'INTEGER 'INTEGRAL-FLOAT)
> 	 == (TRUNCATE x)
> 
>       b. (COERCE x 'INTEGRAL-FLOAT 'INTEGER)
> 	 == (FLOAT x)

There are several specific cases I could pick on, but here, for example,
if a user can't remember the TRUNCATE function, how is he going to
remember the INTEGRAL-FLOAT type and understand how to use it correctly?
TRUNCATE seems a much simpler concept.

∂22-Nov-88  1533	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Nov 88  15:32:53 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 496892; Tue 22-Nov-88 18:32:16 EST
Date: Tue, 22 Nov 88 18:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 4)
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8811150828.AA25376@bhopal>
Message-ID: <19881122233213.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

OK, I will write up a version 5 that uses alternative #1, as you suggest,
and also incorporates MLY's suggestion.

∂22-Nov-88  1541	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Nov 88  15:37:18 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 496895; Tue 22-Nov-88 18:36:48 EST
Date: Tue, 22 Nov 88 18:37 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Versions 2a,2b,2c)
To: jonl@lucid.com
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8811222300.AA16647@bhopal>
Message-ID: <881122183700.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Tue, 22 Nov 88 15:00:25 PST
    From: Jon L White <jonl@lucid.com>

    ... I would very much like to hear you opinion on my suggestion for a
    way out of the "loophole" conflict; namely, allow the default setting of
    the of :adjustable argument to MAKE-ARRAY to be implementation-dependent.
    That way, we could maintain portability on what the :adjustable argument 
    means (i.e. NIL means "Not Adjustable").   Symbolics' users would likely 
    have no code broken, since the Symbolics default setting would be just
    be :adjustable = T.  (Does any user *ever* explicitly supply a NIL for 
    this argument?).

I don't usually supply :ADJUSTABLE NIL only because I know that's the default.
If you made the default implementation-dpeendent, I would have to supply it
a whole lot more than I do now. I recently spent a lot of time going through
some code of mine removing the need for ``:ADJUSTABLE T'' (ie, implicitly
making things ``:ADJUSTABLE NIL'' in order to incur less overhead in some
implementations to which I needed to be porting).

So I don't think what you're suggesting would be the easy solution you suggest
because any way you cut it, if you make NIL really mean not adjustable, then
you make Genera not compatible. We just don't have that bit allocated right now
and it's fairly possible that there's no room to add it. So you'd be breaking
us fairly badly under any scheme which required the distinction, regardless of
the default.

In terms of perceived breakage, your strategy might reduce the initial
perception of a problem because initially people's code would seem to run well
since most people don't have :ADJUSTABLE NIL explicitly in their code, but you'd
find that some code didn't run as efficiently when ported as it used to (and that
would be bad!) and so people would start to add :ADJUSTABLE NIL, and so the
problem would gradually become more visible.

∂22-Nov-88  1628	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Nov 88  16:28:39 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 496925; Tue 22-Nov-88 19:27:59 EST
Date: Tue, 22 Nov 88 19:27 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 5)
To: cl-cleanup@sail.stanford.edu
References: <8811101832.AA05895@bhopal>
Message-ID: <19881123002752.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

I have updated this according to suggestions from JonL and MLY.  I
elaborated on the description of <package-list> with more detail than
was in MLY's suggestion.  I also added examples and fixed the typo in
the discussion of package iteration and one or two other typos and
misspellings.  I'm happy with this version if everyone else is.

!

Issue:         HASH-TABLE-PACKAGE-GENERATORS

References:    Issue: DO-SYMBOLS-DUPLICATES 

Category:      ADDITION

Edit history:  Version 1, 23-May-88 JonL
               Version 2,  6-Oct-88 JonL (convert to "with" scoping).
               Version 3,  7-Oct-88 JonL (mly's syntax for package iterator)
               Version 4,  8-Nov-88 JonL (fix example; clarify some nits)
               Version 5, 22-Nov-88 Moon (improve syntax for package iterator,
                                          add examples, fix typos)


Problem description:

The Iteration subcommittee would like the several iteration proposals to be
writable in portable Common Lisp code.  Unfortunately, the only complete
access to hash-tables and packages is through MAPHASH and DO-SYMBOLS (and
DO-EXTERNAL-SYMBOLS and DO-ALL-SYMBOLS); none of these existing primitives 
is satisfactory for building complex iteration clauses.  In particular,
these primitives are fully packaged and do not allow control over the
individual operations of starting the iteration, stopping the iteration,
and advancing to the next step of the iteration.


Proposal (HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER)

Add two new macros WITH-HASH-TABLE-ITERATOR and WITH-PACKAGE-ITERATOR 
to the language as follows:


    WITH-HASH-TABLE-ITERATOR ((<next-fn> <hash-table>) &body body)      [Macro]

    Within the lexical scope of 'body', the name <next-fn> is defined
    via MACROLET such that successive invocations of (<next-fn>) will 
    return the items, one by one, from the hash-table which is obtained 
    by evaluating <hash-table> only once.

    An invocation (<next-fn>) returns three values as follows:
      ;;    1. a boolean indicating whether an entry is returned (T says yes)
      ;;    2. the key item (of a <key, value> pair)
      ;;    3. the value item (of a <key, value> pair)
      ;; After all entries have been returned [by successive invocations of
      ;;   (<next-fn>)], then only one value is returned, namely NIL.



    WITH-PACKAGE-ITERATOR ((<next-fn> <package-list>                    [Macro]
                            &rest <symbol-types>)
                           &body body)

    Within the lexical scope of 'body', the name <next-fn> is defined
    via MACROLET such that successive invocations of (<next-fn>) will 
    return symbols, one by one, from the packages that are elements
    of the list which is obtained by evaluating <package-list> only once.  
    Each element of <package-list> can be a package or the name of a
    package.

    The order of symbols returned does not necessarily reflect the order
    of packages in <package-list>.  When <package-list> has more than
    one element, it is unspecified whether duplicate symbols are
    returned once or more than once.  Even when <package-list> has only
    one element, it is unspecified whether symbols inherited from
    multiple packages are returned more than once.  See the proposal
    DO-SYMBOLS-DUPLICATES:ALLOWED.

    As a convenience, the value of <package-list> can be a package or
    the name of a package; this is equivalent to a list of one element.
    An argument of NIL is treated as an empty list of packages.

    The <symbol-types> subform consists of one or more symbols from the
    set {:INTERNAL, :EXTERNAL, :INHERITED}.  Their order does not
    matter.  The <symbol-types> subform is not evaluated.  This controls
    which symbols accessible in a package are returned.
      :INTERNAL means the symbols that are present in the package and
      not exported.
      :EXTERNAL means the symbols that are exported.
      :INHERITED means the symbols that are exported by used packages and
      not shadowed.
    If more than one <symbol-type> is specified, all symbols that
    satisfy at least one of the <symbol-types> are returned.
    WITH-PACKAGE-ITERATOR signals an error if no <symbol-types> are
    specified or if a <symbol-type> not recognized by the implementation
    is specified.  Implementations are permitted to extend this syntax
    by recognizing additional symbol types.

    An invocation (<next-fn>) returns four values as follows:
      ;;    1. a boolean indicating whether a symbol is returned (T says yes)
      ;;    2. a symbol (accessible in the indicated package)
      ;;    3. a package (in which the symbol is accessible)
      ;;    4. the accessibility type for that symbol; i.e. one of
      ;;       :INTERNAL, :EXTERNAL, or :INHERITED
      ;; After all symbols have been returned [by successive invocations of
      ;;   (<next-fn>)], then only one value is returned, namely NIL.


It is unspecified what happens if any of the implicit interior state 
of an iteration is returned outside the dynamic extent of the WITH-...
form (such as by returning some closure over the invocation form).

Any number of invocations of with-hash-table-iterator and
with-package-iterator can be nested, and the body of the innermost one
can invoke all of the MACROLET'ed macros, provided all those macros
have distinct names.


Test-case:

The following function should return T on any hash-table, and signal
an error if the usage of 'with-hash-table-iterator' doesn't agree
with the corresponding usage of 'maphash'.

(defun test-hash-table-iterator (hash-table)
  (let ((all-entries '())
        (generated-entries '())
        (unique (list nil)))
    (maphash #'(lambda (key value) (push (list key value) all-entries))
             hash-table)
    (with-hash-table-iterator (generator-fn hash-table)
      (loop     
        ;;Note -- this is the "trivial" LOOP of CLtL p121
        (multiple-value-bind (more? key value) (generator-fn)
          (unless more? (return))
          (unless (eql value (gethash key hash-table unique))
            (error "Key ~S not found for value ~S" key value))
          (push (list key value) generated-entries))))
    (unless (= (length all-entries)
               (length generated-entries)
               (length (union all-entries generated-entries :test #'equal)))
      (error "Generated entries and Maphash entries don't correspond"))
    t))


The following function should return T on any package, and signal
an error if the usage of 'with-package-iterator' doesn't agree
with the corresponding usage of 'do-symbols'.

(defun test-package-iterator (package)
  (unless (packagep package)
    (setq package (find-package package)))
  (let ((all-entries '())
        (generated-entries '()))
    (do-symbols (x package) 
      (multiple-value-bind (symbol accessibility) 
          (find-symbol (symbol-name x) package)
        (push (list symbol accessibility) all-entries)))
    (with-package-iterator (generator-fn package 
                            :internal :external :inherited)
      (loop     
        ;;Note -- this is the "trivial" LOOP of CLtL p121
        (multiple-value-bind (more? symbol pkg accessibility)
            (generator-fn)
          (unless more? (return))
          (let ((l (multiple-value-list (find-symbol (symbol-name symbol) 
                                                     package))))
            (unless (equal l (list symbol accessibility))
              (error "Symbol ~S not found as ~S in package ~A [~S]"
                     symbol accessibility (package-name package) l))
            (push l generated-entries)))))
    (unless (and (subsetp all-entries generated-entries :test #'equal)
                 (subsetp generated-entries all-entries :test #'equal))
     (error "Generated entries and Do-Symbols entries don't correspond"))
    t))

The following function prints out every interned symbol:

(defun print-all-symbols () 
  (with-package-iterator (next-symbol (list-all-packages)
                          :internal :external)
    (loop
      ;;Note -- this is the "trivial" LOOP of CLtL p121
      (multiple-value-bind (more? symbol) (next-symbol)
        (if more? 
           (print symbol)
           (return))))))


Examples:

The following macro definitions show how certain builtin Common Lisp
macros and functions could have been defined in terms of the proposed
primitives.  They are intended as illustrative examples, not as new
specifications of those builtin Common Lisp facilities.

(defun maphash (function hash-table)
  (with-hash-table-iterator (next-entry hash-table)
    (loop (multiple-value-bind (more key value) (next-entry)
            (unless more (return nil))
            (funcall function key value)))))

(defmacro do-symbols ((var &optional (package `*package*) result-form)
                      &body body)
  `(with-package-iterator (next-symbol (list ,package)
                           :internal :external :inherited)
     (loop (multiple-value-bind (more ,var) (next-symbol)
             (cond (more ,@body)
                   (t (return ,result-form)))))))

(defmacro do-all-symbols ((var &optional result-form) &body body)
  `(with-package-iterator (next-symbol (list-all-packages)
                           :internal :external)
     (loop (multiple-value-bind (more ,var) (next-symbol)
             (cond (more ,@body)
                   (t (return ,result-form)))))))

(defmacro do-external-symbols ((var &optional (package `*package*) result-form)
                               &body body)
  `(with-package-iterator (next-symbol (list ,package)
                           :external)
     (loop (multiple-value-bind (more ,var) (next-symbol)
             (cond (more ,@body)
                   (t (return ,result-form)))))))


Rationale:

The particular way in which hash-tables and packages are represented
need not be standardized, or even exposed to the user.  Yet a simpler 
handle on them is needed for the various iteration paradigms to be written 
in portable code.  In fact, after these iterator macros are put into an 
implementation, then MAPHASH and DO-<mumble>-SYMBOLS are trivial usages 
of them; but no _efficient_ use of the current primitives will provide 
the effect of the new macros, namely a form that _returns_ the elements
of a table "one by one".


Current Practice:

Nobody does it this way, but both Symbolics and Lucid are not far off.


Cost to Implementors:

Moderate.  Possibly a couple day's to a week's work for an implementation 
that has to start completely afresh.  Something like this is already being
done by the standard package macros [CLtL, p187].


Cost to Users:

None.


Benefits:

Will provide a more basic primitive for iterating over hash-tables and 
packages; will permit new iteration paradigms to be written in portable code.


Aesthetics:

All other things being equal, it is better to have more general primitives
than less general ones.  


Discussion:

The Iteration Subcommittee supports this proposal (or, "used to" -- 
JonL 6-Oct-88).

One must be careful not to assume that the invocation (<next-fn>) is a 
"generator" function call -- since <next-fn> is MACROLET'd in an 
implementation dependent way, it could even turn into a special form like
    (if something
        (values nil)
        (yet-another-function-call))

The scoping called for herein may not be quite so useful to the "generators"
style proposals; in particular they offer an interface wherein one may 
create a "generator" function of indefinite extent that returns, one-by-one,
the elements of the table.  The constrained scoping implicit in these
WITH-... macros is not so much for any kind of optimization, but rather
for coordination of such hash-table "locking" as may occur in multi-
processing implementations like Symbolics.  Nevertheless, Dick Waters 
thinks these macros should be put in anyway, since it clearly is a 
requirement for a portable LOOP, and can be use in a limited context 
(i.e., not "indefinite scope") for portable versions of ITERATE and OSS.

Of course, if an implementation _can_ support an indefinite extent for
a "generator" object returned out of the iterator forms, it is allowed 
to do so by this proposal.

∂22-Nov-88  1649	CL-Cleanup-mailer 	Issue: SETF-PLACES (version 1) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Nov 88  16:49:28 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 496949; Tue 22-Nov-88 19:49:27 EST
Date: Tue, 22 Nov 88 19:49 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-PLACES (version 1)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <8811152256.AA01215@bhopal>
Message-ID: <19881123004923.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

I am not happy with this proposal, because I think it is excessively
complicated.  I still prefer the SETF-FUNCTION-VS-MACRO proposal.
However, I would rather accept this kludge than not have CLOS at all, so
if X3J13 is adamantly against SETF-FUNCTION-VS-MACRO I will accept this
proposal.  I would prefer to see X3J13 allowed to vote on both proposals
as alternatives, since it's possible that when they see this one they
would prefer the one they rejected before.

Note: I am not complaining about the writeup of the proposal, which
is quite clear, but about the substance of the proposal.  I believe
the distinction between "specs" and "underlying names" is confusing
and unnecessary.  Evidently that is a minority position.

A few additional comments on the details of the proposal.  All of
these are easily corrected:

I believe that DEFUN should have syntax compatible with DEFGENERIC and
DEFMETHOD, for aesthetic reasons, and therefore the proposal should
specify that DEFUN will call UNDERLYING-NAME, just as DEFMETHOD does.
Once this is done, the first example can be simplified.

Similarly, LABELS and FLET should accept "specs", since GENERIC-LABELS
and GENERIC-FLET do.  This would eliminate the non-portability of
the FLET of setf:3.bar.middle-ref example.

The get-setf-method-for-setf-functions example has parenthesis errors.

I did not check whether this proposal preserves the carefully worked out
rules about local functions and local macros from the earlier proposal.
I'll assume that it does.

∂22-Nov-88  1651	CL-Cleanup-mailer 	Re: Issue: SETF-PLACES (version 1)  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 22 Nov 88  16:51:04 PST
Received: by ti.com id AA27756; Tue, 22 Nov 88 18:50:32 CST
Received: from Kelvin by tilde id AA24761; Tue, 22 Nov 88 18:37:41 CST
Message-Id: <2805237539-1438981@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 22 Nov 88  18:38:59 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@lucid.com>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: SETF-PLACES (version 1)
In-Reply-To: Msg of Tue, 15 Nov 88 14:56:59 PST from Jon L White <jonl@lucid.com>

>     (b) phrases like "(FBOUNDP <function-specifier>)" should be changed
>         into "(FBOUNDP (UNDERLYING-NAME <function-specifier>))"; or
>         else other terminology should express the intent of what is to
>         be said.  For example, instead of saying: "When (FBOUNDP <f-s>) 
>         is  true ..." one could just as well say  "When <f-s> refers to 
>         a defined function ..."  The choice of which of these two formats 
>         to use is an editorial one.
>     (c) phrases like "(SYMBOL-FUNCTION function-specifier)" should be changed
>         into "(SYMBOL-FUNCTION (UNDERLYING-NAME <function-specifier>))";
>         or else other terminology should express the intent of what is to
>         be said.  For example, one might say "... the function referred 
>         to by <f-s>".  The choice of which of these two formats to use is
>         an editorial one.

There is a non-editorial issue here:  are FBOUNDP and SYMBOL-FUNCTION
required to accept anything returned by UNDERLYING-NAME, or are they
only meaningful for symbols?  On Lisp Machines these are primitives for
accessing symbol definition cells while other functions, FDEFINEDP and
FDEFINITION, accept any function spec.

> Since the concept of a standard expansion for DEFMETHOD has been
> accepted, then it is clear that a form like 
>     (DEFMETHOD (SETF FOO) ...)
> will expand exactly the same as
>     (DEFMETHOD #.(UNDERLYING-NAME '(SETF FOO)) ...)
> The underlying call to ADD-METHOD will see the real function name used
> for the updator function.  The user-level interface of CLOS can still
> present the list format as acceptable; it is only the implementation of
> DEFMETHOD, DEFGENERIC, that will have to worry about converting to a
> "real" name.

For consistency, shouldn't this be accepted by all function-defining
macros and special forms?  Besides DEFMETHOD and DEFGENERIC, there are
DEFUN, FLET, LABELS, GENERIC-FLET, GENERIC-LABELS, WITH-ADDED-METHODS,
and DEFCLASS.  I also can't find any mention of the special form
FUNCTION in the proposal; shouldn't it also accept function specifiers?

> Cost to Implementors:
> 
> Basically, none.  Implementations which already have Lisp Machine 
> style "function specs" can just define UNDERLYING-NAME and
> UNDERLYING-NAME-TO-SPEC as the identity function. 

If we don't have to also extend the meaning of FBOUNDP and
SYMBOL-FUNCTION.

∂22-Nov-88  1700	CL-Cleanup-mailer 	Re: Issue: SETF-PLACES (version 1)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Nov 88  17:00:28 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 496964; Tue 22-Nov-88 20:00:25 EST
Date: Tue, 22 Nov 88 20:00 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: SETF-PLACES (version 1)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <2805237539-1438981@Kelvin>
Message-ID: <19881123010011.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

I think Gray's points are well-taken and I agree with them (passing
lightly over the typo of DEFCLASS in a list of function-defining forms).
I think they amplify my contention that this proposal is too complicated,
because by introducing a distinction between "names" and "specs" we
have to clarify which functions work with which.

∂22-Nov-88  1816	CL-Cleanup-mailer 	Re: Issue: SETF-PLACES (version 1)  
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 22 Nov 88  18:16:16 PST
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 22 Nov 88 21:14:06 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: SETF-PLACES (version 1) 
In-reply-to: Your message of Tue, 22 Nov 88 19:49:00 -0500.
             <19881123004923.5.MOON@EUPHRATES.SCRC.Symbolics.COM> 
Date: Tue, 22 Nov 88 21:13:26 EST
From: Scott.Fahlman@B.GP.CS.CMU.EDU


I'm inclined to agree with Moon on this.  However, I wasn't around when the
SETF-FUNCTION-VS-MACRO issue was voted on, so I don't know what arguments
were raised against it.  The current proposal looks like a recipe for
disaster, since this name/spec distinction is going to confuse people and
raise lots of questions about which can be used where.

-- Scott

∂22-Nov-88  1838	CL-Cleanup-mailer 	Issue names
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Nov 88  18:38:27 PST
Received: from Semillon.ms by ArpaGateway.ms ; 22 NOV 88 17:00:23 PST
Date: 22 Nov 88 17:00 PST
From: masinter.pa@Xerox.COM
Subject: Issue names
to: cl-cleanup@sail.stanford.edu
Message-ID: <881122-170023-11218@Xerox>

I've been filing messages about SETF-PLACES under SETF-FUNCTION-VS-MACRO
and issue HASH-TABLE-STABIITY under HASH-TABLE-KEY-MODIFICATION because I
haven't been convinced that they are really different issues.

(Along the same lines I should have kept EXIT-EXTENT under
UNWIND-PROTECT-NON-LOCAL-EXIT, but I didn't see the trend then....)

We must reach some closure, lest none of the proposals pass. At this point,
we're better off with several proposals than none.


∂23-Nov-88  1102	CL-Cleanup-mailer 	Issue: LIST-TYPE-SPECIFIER (Version 1)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Nov 88  11:02:18 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 NOV 88 10:55:54 PST
Date: 23 Nov 88 10:55 PST
From: masinter.pa@Xerox.COM
Subject: Issue: LIST-TYPE-SPECIFIER (Version 1)
In-reply-to: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>'s message of
 Wed, 31 Aug 88 15:25:52 EDT
To: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881123-105554-12679@Xerox>

Michael J. Beckerle:

Please reply if you get this... If you want to pursue this, can you produce
a new draft of the proposal quickly? Please let us know what your schedule
is.

The summary so far is that there are possibly two kinds of type specifier
syntax:

(<list-consisting-of-all> NUMBER)
	for example, (1 2 12323)
(<list-with-explicit-elements> NUMBER SYMBOL)
	for example, (1 A)

For the second type of description, there are some design choices about
whether "extra" arguments are legal, e.g., is

(typep '(1 A 3) '(<list-with-explicit-elements> NUMBER SYMBOL)) 

valid? There might be a possibility of using the function argument list
notation, e.g.,

(<list-with-explicit-elements> NUMBER SYMBOL &KEY (:FROB NUMBER)
&ALLOW-OTHER-KEYS)

which would lead to the recursive ambiguity of 
(<list-with-explicit-elements> &REST (<list-with-explicit-elements>
NUMBER))

(:->)

- - - - - - - -
For whatever additional type descriptors one might add, the question could
be whether an implementation which had a new kind of LIST which was not
read-only and not completely writable, but for which it would be an error
to modify the structure of the list so that it no longer conformed to a
predefined type specification.

This proposal would interact with TYPE-OF-UNDERSPECIFIED (would (TYPE-OF
'(1 2)) be allowed to return (<list-with-explicit-elements> (MEMBER 1)
(MEMBER 2))?)

Given the desired semantics, there is then some debate about what the
*name* of the type specifiers might be; the proposed names LIST and LIST-OF
could arguably be applied to either kind of specifier.

I not personally  inclined to pursue this issue. The fact that there is a
feature that several people want is not one of the more serious ones.




∂23-Nov-88  1258	CL-Cleanup-mailer 	Issue: COERCE-INCOMPLETE (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Nov 88  12:58:27 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 497416; Wed 23-Nov-88 15:58:29 EST
Date: Wed, 23 Nov 88 15:58 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COERCE-INCOMPLETE (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881121180215.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881123205815.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

I oppose this proposal.  I think what it's trying to do fundamentally
cannot work.  I would characterize what it's trying to do as trying to
bring as many one-input-one-output functions under the umbrella of
COERCE as possible.  (Even worse of course is cases like ACCESSIBLE-SYMBOL
where the function has two inputs, but you're getting the second input
from a special variable.)

type-specifiers are supposed to be names for sets of objects.  Two
type-specifiers that designate the same set of objects are supposed to
be usable interchangeably, except when their equivalence is uncomputable
because of SATISFIES.  However, when we start making up new
type-specifier names as a back-door way (or an elegant way, depending on
one's point of view) to tell COERCE what internal function to call, we
run into two problems:

First, it isn't clear whether one can call COERCE with a type-specifier
that designates the same set of objects as one of the builtin type
specifiers, and get the same result.  Suppose I define my own type
specifier that designates the same set of objects as INTEGER-STRING, for
example.  Are the second and third arguments to COERCE really
type-specifiers, or are they really just specially-recognized symbols
that are made to resemble type-specifiers to make them easier to
remember?

Second, and I think this is an even worse problem, when x is a subtype
of y, Kent sometimes calls for an x coercion which is not compatible with
the y coercion.  For example, the proposal appears to say that
(COERCE 65 'STRING) => "A" but (COERCE 65 'INTEGER-STRING) => "65", even
though INTEGER-STRING is a subtype of STRING.

I think the proposal is a good try, but I think the original idea of
COERCE was not well-founded enough to survive such addition of features.

Kent wanted line by line comments, I suppose I can do that too.
   1. CHARACTER <-> STRING
string -> character already exists, I don't see any harm in adding the inverse,
especially since the function STRING already does it.
   2. CHAR-CODE <-> CHARACTER
   3. CHAR-INT <-> CHARACTER
   7. CHAR-CODE <-> STRING
   8. CHAR-INT <-> STRING
   9. CHAR-CODE <-> SYMBOL
  10. CHAR-INT <-> SYMBOL
  11. CHAR-CODE <-> ACCESSIBLE-SYMBOL
  12. CHAR-INT <-> ACCESSIBLE-SYMBOL
I oppose all coercions between characters and numbers as fundamentally
wrong-headed.  The existing coercion from integer to character should be
removed.
   4. STRING <-> SYMBOL
1-character symbols can already be coerced to characters, so allowing
coercion of symbols to strings would be okay, especially since the
function STRING already does it.  The inverse direction is a 2-argument
function and so should not be added; although Kent's suggestion of
returning an uninterned symbol is interesting, I suspect this is not
what users would expect.
   5. STRING <-> ACCESSIBLE-SYMBOL
2-argument function, also has subtype problem noted earlier.
   6. INTEGER <-> INTEGER-STRING
Multi-argument function in both directions unless you are base-ten-centric.
I don't think this is a good idea.
  13. PATHNAME <-> STRING
This is okay.  The function STRING already does pathname -> string in SCL.
  14. INTEGRAL-FLOAT <-> INTEGER
Integer -> float already exists.  The inverse would be okay except that
the INTEGRAL-FLOAT type is implementation-dependent, since whether a
mathematical value is a member of this type depends on the precision of
the floating-point representation of the machine; the explanation given
in CLtL that float -> integer conversion requires the user to think
about rounding applies