perm filename CLCOMP.MSG[COM,LSP] blob sn#875426 filedate 1989-07-12 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00217 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00034 00002	
C00035 00003	∂13-Mar-89  1045	CL-Compiler-mailer 	Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
C00039 00004	∂13-Mar-89  1034	Common-Lisp-Object-System-mailer 	Re: remote environments   
C00044 00005	∂13-Mar-89  1043	CL-Compiler-mailer 	Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
C00048 00006	∂13-Mar-89  1054	Common-Lisp-Object-System-mailer 	Re: remote environments   
C00054 00007	∂13-Mar-89  1113	CL-Compiler-mailer 	issue COMPILER-VERBOSITY, version 6
C00057 00008	∂13-Mar-89  1149	CL-Compiler-mailer 	Re:  Issue CONSTANT-COMPILABLE-TYPES, version 7   
C00060 00009	∂13-Mar-89  1151	Common-Lisp-Object-System-mailer 	Re: remote environments   
C00065 00010	∂13-Mar-89  1206	CL-Compiler-mailer 	Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
C00068 00011	∂13-Mar-89  1221	CL-Compiler-mailer 	Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
C00071 00012	∂13-Mar-89  1233	CL-Compiler-mailer 	Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
C00074 00013	∂13-Mar-89  1319	CL-Compiler-mailer 	Re: issue SAFE-CODE, version 1
C00076 00014	∂13-Mar-89  1352	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 3)
C00083 00015	∂13-Mar-89  1501	CL-Compiler-mailer 	Issue MACRO-ENVIRONMENT-EXTENT
C00085 00016	∂13-Mar-89  1458	CL-Compiler-mailer 	Issue MACRO-ENVIRONMENT-EXTENT
C00092 00017	∂13-Mar-89  1500	CL-Compiler-mailer 	Issue WITH-COMPILATION-UNIT   
C00094 00018	∂13-Mar-89  1501	CL-Compiler-mailer 	Issue DEFINE-OPTIMIZER   
C00096 00019	∂13-Mar-89  1501	CL-Compiler-mailer 	Issue PROCLAIM-ETC-IN-COMPILE-FILE 
C00099 00020	∂13-Mar-89  1457	CL-Compiler-mailer 	Issue LOCALLY-TOP-LEVEL, v1   
C00101 00021	∂13-Mar-89  1545	CL-Compiler-mailer 	Issue MACRO-ENVIRONMENT-EXTENT
C00111 00022	∂13-Mar-89  1557	CL-Cleanup-mailer 	Issue LOCALLY-TOP-LEVEL, v1    
C00114 00023	∂13-Mar-89  1500	CL-Compiler-mailer 	Re: issue SAFE-CODE, version 1
C00117 00024	∂13-Mar-89  1647	CL-Compiler-mailer 	Re:  issue DEFINE-OPTIMIZER, version 5  
C00120 00025	∂13-Mar-89  1655	CL-Compiler-mailer 	Re: issue PROCLAIM-ETC-IN-COMPILE-FILE, version 3 
C00125 00026	∂13-Mar-89  1703	CL-Compiler-mailer 	**DRAFT** issue DEFCONSTANT-NOT-WIRED, version 6  
C00129 00027	∂13-Mar-89  1643	X3J13-mailer 	issue COMPILER-LET-CONFUSION, version 7  
C00132 00028	∂13-Mar-89  1730	CL-Compiler-mailer 	issue DEFINE-OPTIMIZER, version 5  
C00134 00029	∂13-Mar-89  1737	CL-Compiler-mailer 	Re: Issue: LOAD-OBJECTS (Version 3)
C00139 00030	∂13-Mar-89  1754	CL-Compiler-mailer 	Re: Issue: LOAD-OBJECTS (Version 3)
C00143 00031	∂13-Mar-89  1809	CL-Compiler-mailer 	**DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3    
C00146 00032	∂13-Mar-89  1836	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4 
C00150 00033	∂14-Mar-89  0644	CL-Compiler-mailer 	issue DEFINE-OPTIMIZER, version 5  
C00154 00034	∂14-Mar-89  0646	CL-Compiler-mailer 	issue COMPILER-LET-CONFUSION, version 7 
C00156 00035	∂14-Mar-89  0651	CL-Compiler-mailer 	Re: issue PROCLAIM-ETC-IN-COMPILE-FILE, version 3 
C00159 00036	∂14-Mar-89  0702	CL-Compiler-mailer 	Re: issue MACRO-CACHING, version 2 
C00162 00037	∂14-Mar-89  0738	CL-Compiler-mailer 	Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE  
C00165 00038	∂14-Mar-89  0938	CL-Compiler-mailer 	issue COMPILER-LET-CONFUSION, version 7 
C00170 00039	∂14-Mar-89  0956	CL-Compiler-mailer 	issue DEFINE-OPTIMIZER, version 5  
C00175 00040	∂14-Mar-89  1005	CL-Compiler-mailer 	issue WITH-COMPILATION-UNIT, version 3  
C00178 00041	∂14-Mar-89  1009	CL-Compiler-mailer 	Re: issue COMPILER-LET-CONFUSION, version 7  
C00184 00042	∂14-Mar-89  1053	CL-Compiler-mailer 	Re: issue WITH-COMPILATION-UNIT, version 3   
C00188 00043	∂14-Mar-89  1137	CL-Compiler-mailer 	issue DEFINE-OPTIMIZER, version 5  
C00192 00044	∂14-Mar-89  1217	CL-Compiler-mailer 	**DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3    
C00194 00045	∂14-Mar-89  1218	CL-Compiler-mailer 	Re: issue COMPILER-LET-CONFUSION, version 7  
C00201 00046	∂14-Mar-89  1232	CL-Compiler-mailer 	**DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE (version 4)    
C00206 00047	∂14-Mar-89  1310	CL-Compiler-mailer 	issue DEFINING-MACROS-NON-TOP-LEVEL, version 8    
C00210 00048	∂14-Mar-89  1326	CL-Compiler-mailer 	issue COMPILE-FILE-SYMBOL-HANDLING, version 2
C00213 00049	∂14-Mar-89  1340	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4  
C00215 00050	∂14-Mar-89  1351	CL-Compiler-mailer 	issue SAFE-CODE, version 1    
C00217 00051	∂14-Mar-89  1357	CL-Compiler-mailer 	issue COMPILER-VERBOSITY, version 6
C00219 00052	∂14-Mar-89  1414	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
C00226 00053	∂14-Mar-89  1432	CL-Compiler-mailer 	Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 2 
C00229 00054	∂14-Mar-89  1438	CL-Compiler-mailer 	issue COMPILER-DIAGNOSTICS, version 9   
C00233 00055	∂14-Mar-89  1448	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4   
C00236 00056	∂14-Mar-89  1508	CL-Compiler-mailer 	Re: issue COMPILER-DIAGNOSTICS, version 9    
C00240 00057	∂14-Mar-89  1544	CL-Compiler-mailer 	**DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)    
C00247 00058	∂14-Mar-89  1629	CL-Compiler-mailer 	issue CONSTANT-COMPILABLE-TYPES, version 8   
C00256 00059	∂14-Mar-89  1636	CL-Compiler-mailer 	issue CONSTANT-COMPILABLE-TYPES, version 8   
C00266 00060	∂14-Mar-89  1651	CL-Compiler-mailer 	issue QUOTE-SEMANTICS, version 2   
C00269 00061	∂14-Mar-89  1700	CL-Compiler-mailer 	issue MACRO-CACHING, version 2
C00272 00062	∂14-Mar-89  1704	CL-Compiler-mailer 	issue LOAD-TIME-EVAL, version 11   
C00274 00063	∂14-Mar-89  1722	CL-Compiler-mailer 	issue CONSTANT-CIRCULAR-COMPILATION, version 7    
C00276 00064	∂14-Mar-89  1722	CL-Compiler-mailer 	issue CONSTANT-COLLAPSING, version 5    
C00279 00065	∂14-Mar-89  1730	CL-Compiler-mailer 	issue COMPILED-FUNCTION-REQUIREMENTS, version 4   
C00282 00066	∂14-Mar-89  1732	CL-Compiler-mailer 	Re: Potential issue: MACRO-SPECIAL-FORMS
C00284 00067	∂14-Mar-89  1810	CL-Compiler-mailer 	Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
C00291 00068	∂14-Mar-89  1922	CL-Compiler-mailer 	comments on issues  
C00293 00069	∂15-Mar-89  0508	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4   
C00296 00070	∂15-Mar-89  0636	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4   
C00298 00071	∂15-Mar-89  0913	CL-Compiler-mailer 	Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
C00309 00072	∂15-Mar-89  1043	CL-Compiler-mailer 	Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
C00314 00073	∂15-Mar-89  0800	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
C00317 00074	∂15-Mar-89  1345	CL-Compiler-mailer 	issue COMPILER-LET-CONFUSION, version 7 
C00322 00075	∂15-Mar-89  1408	CL-Compiler-mailer 	issue COMPILER-LET-CONFUSION, version 7 
C00324 00076	∂15-Mar-89  1451	CL-Compiler-mailer 	Issue SAFE-CODE, version 1    
C00326 00077	∂15-Mar-89  1449	CL-Compiler-mailer 	Re: issue COMPILER-LET-CONFUSION, version 7  
C00328 00078	∂15-Mar-89  1756	CL-Cleanup-mailer 	Re: Issue LOCALLY-TOP-LEVEL, v1
C00330 00079	∂15-Mar-89  1941	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4  
C00334 00080	∂15-Mar-89  2035	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4   
C00339 00081	∂15-Mar-89  2046	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4  
C00341 00082	∂16-Mar-89  0601	X3J13-mailer 	Re: issue COMPILER-VERBOSITY, version 6  
C00344 00083	∂16-Mar-89  0645	CL-Compiler-mailer 	Re: issue CONSTANT-CIRCULAR-COMPILATION, version 7
C00347 00084	∂16-Mar-89  0648	CL-Compiler-mailer 	Re: issue LOAD-TIME-EVAL, version 11    
C00349 00085	∂16-Mar-89  0651	CL-Compiler-mailer 	Re: issue QUOTE-SEMANTICS, version 2    
C00351 00086	∂16-Mar-89  0655	CL-Compiler-mailer 	Re: issue QUOTE-SEMANTICS, version 2    
C00353 00087	∂16-Mar-89  0708	CL-Compiler-mailer 	Re: Issue SAFE-CODE, version 1     
C00356 00088	∂16-Mar-89  0720	CL-Compiler-mailer 	Re: issue QUOTE-SEMANTICS, version 2    
C00358 00089	∂16-Mar-89  0632	X3J13-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
C00379 00090	∂16-Mar-89  0731	CL-Compiler-mailer 	Re: Issue SAFE-CODE, version 1     
C00381 00091	∂16-Mar-89  0737	CL-Compiler-mailer 	Re: issue QUOTE-SEMANTICS, version 2    
C00383 00092	∂16-Mar-89  0801	CL-Compiler-mailer 	Re: issue EVAL-WHEN-NON-TOP-LEVEL, version 6 
C00387 00093	∂16-Mar-89  0928	CL-Compiler-mailer 	Issue SAFE-CODE, version 1         
C00390 00094	∂16-Mar-89  0919	CL-Compiler-mailer 	Re: issue EVAL-WHEN-NON-TOP-LEVEL, version 6 
C00393 00095	∂16-Mar-89  0941	CL-Compiler-mailer 	Re: issue EVAL-WHEN-NON-TOP-LEVEL, version 6 
C00396 00096	∂16-Mar-89  0958	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
C00399 00097	∂16-Mar-89  1041	CL-Compiler-mailer 	Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE  
C00401 00098	∂16-Mar-89  1046	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
C00404 00099	∂16-Mar-89  1111	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
C00408 00100	∂16-Mar-89  1117	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4  
C00411 00101	∂16-Mar-89  1121	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4   
C00415 00102	∂16-Mar-89  1122	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
C00420 00103	∂16-Mar-89  1147	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
C00427 00104	∂16-Mar-89  1157	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
C00433 00105	∂16-Mar-89  1213	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
C00436 00106	∂16-Mar-89  1217	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
C00440 00107	∂16-Mar-89  1225	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
C00444 00108	∂16-Mar-89  1231	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
C00447 00109	∂16-Mar-89  1356	CL-Compiler-mailer 	Issue SAFE-CODE, version 1         
C00449 00110	∂16-Mar-89  1400	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
C00453 00111	∂16-Mar-89  1407	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
C00456 00112	∂16-Mar-89  1417	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
C00458 00113	∂16-Mar-89  1443	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
C00461 00114	∂17-Mar-89  1019	CL-Compiler-mailer 	issue CONSTANT-FUNCTION-COMPILATION
C00465 00115	∂17-Mar-89  1047	CL-Compiler-mailer 	Re:  issue CONSTANT-FUNCTION-COMPILATION
C00468 00116	∂17-Mar-89  1105	CL-Compiler-mailer 	Re:  issue CONSTANT-FUNCTION-COMPILATION
C00472 00117	∂17-Mar-89  1225	CL-Compiler-mailer 	Issue: DEFINE-OPTIMIZER (Version 2)
C00474 00118	∂17-Mar-89  1251	CL-Compiler-mailer 	Re: issue QUOTE-SEMANTICS, version 2    
C00477 00119	∂17-Mar-89  1251	CL-Compiler-mailer 	**DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)    
C00480 00120	∂17-Mar-89  1223	X3J13-mailer 	**DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
C00483 00121	∂17-Mar-89  1223	X3J13-mailer 	issue SAFE-CODE, version 1
C00485 00122	∂17-Mar-89  1350	CL-Compiler-mailer 	Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE  
C00488 00123	∂17-Mar-89  1352	CL-Compiler-mailer 	Re:  issue CONSTANT-FUNCTION-COMPILATION
C00490 00124	∂17-Mar-89  1356	CL-Compiler-mailer 	**DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)    
C00493 00125	∂17-Mar-89  1401	CL-Compiler-mailer 	Re:  issue CONSTANT-FUNCTION-COMPILATION
C00495 00126	∂17-Mar-89  1415	CL-Compiler-mailer 	Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE  
C00498 00127	∂17-Mar-89  1558	CL-Compiler-mailer 	Re: issue QUOTE-SEMANTICS, version 2    
C00503 00128	∂17-Mar-89  1712	CL-Compiler-mailer 	Re: issue QUOTE-SEMANTICS, version 2    
C00509 00129	∂17-Mar-89  1729	CL-Compiler-mailer 	cl-compiler subcommittee meeting & agenda    
C00511 00130	∂17-Mar-89  2254	CL-Cleanup-mailer 	Re: Issue: LOAD-OBJECTS (Version 3) 
C00517 00131	∂17-Mar-89  2338	CL-Compiler-mailer 	Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
C00519 00132	∂18-Mar-89  0655	CL-Compiler-mailer 	Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
C00521 00133	∂18-Mar-89  0909	CL-Compiler-mailer 	issue SYNTACTIC-ENVIRONMENT-ACCESS 
C00526 00134	∂18-Mar-89  1608	CL-Compiler-mailer 	**DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)    
C00529 00135	∂19-Mar-89  1346	CL-Compiler-mailer 	Re:  issue SYNTACTIC-ENVIRONMENT-ACCESS 
C00532 00136	∂19-Mar-89  1655	CL-Compiler-mailer 	issue CONSTANT-COMPILABLE-TYPES, version 8   
C00536 00137	∂19-Mar-89  2019	CL-Compiler-mailer 	issue LOAD-TIME-EVAL, version 11   
C00540 00138	∂20-Mar-89  0805	CL-Compiler-mailer 	Re: issue LOAD-TIME-EVAL, version 11    
C00544 00139	∂20-Mar-89  0816	CL-Compiler-mailer 	Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
C00546 00140	∂20-Mar-89  0922	CL-Compiler-mailer 	Re:  issue SYNTACTIC-ENVIRONMENT-ACCESS 
C00549 00141	∂20-Mar-89  1056	CL-Compiler-mailer 	Re:  issue SYNTACTIC-ENVIRONMENT-ACCESS 
C00551 00142	∂20-Mar-89  1228	CL-Compiler-mailer 	Re: cl-compiler subcommittee meeting & agenda     
C00554 00143	∂20-Mar-89  1240	CL-Compiler-mailer 	Re:  issue SYNTACTIC-ENVIRONMENT-ACCESS 
C00557 00144	∂20-Mar-89  1240	CL-Compiler-mailer 	Re:  issue SYNTACTIC-ENVIRONMENT-ACCESS 
C00560 00145	∂20-Mar-89  1252	CL-Compiler-mailer 	issue LOAD-TIME-EVAL, version 11   
C00562 00146	∂20-Mar-89  1315	CL-Compiler-mailer 	Re: Issue CONSTANT-COMPILABLE-TYPES, version 7    
C00565 00147	∂20-Mar-89  1315	CL-Compiler-mailer 	issue COMPILER-VERBOSITY, version 6
C00567 00148	∂20-Mar-89  1321	CL-Compiler-mailer 	issue SYNTACTIC-ENVIRONMENT-ACCESS 
C00578 00149	∂20-Mar-89  1327	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS  
C00580 00150	∂20-Mar-89  1325	CL-Cleanup-mailer 	Re: Issue: LOAD-OBJECTS (Version 3) 
C00582 00151	∂20-Mar-89  1340	CL-Compiler-mailer 	Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
C00591 00152	∂20-Mar-89  1353	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS  
C00594 00153	∂20-Mar-89  1405	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS  
C00598 00154	∂20-Mar-89  1417	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS  
C00601 00155	∂20-Mar-89  1427	CL-Cleanup-mailer 	Re: Issue: LOAD-OBJECTS (Version 3) 
C00603 00156	∂20-Mar-89  1532	CL-Compiler-mailer 	issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5     
C00630 00157	∂20-Mar-89  1612	CL-Compiler-mailer 	issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5     
C00633 00158	∂20-Mar-89  2032	CL-Compiler-mailer 	issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5     
C00638 00159	∂21-Mar-89  0614	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
C00641 00160	∂21-Mar-89  0738	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
C00644 00161	∂21-Mar-89  0843	Common-Lisp-Object-System-mailer 	Compile Time Class Creation (was: remote environments)  
C00649 00162	∂21-Mar-89  0911	CL-Compiler-mailer 	issue DEFINE-OPTIMIZER, version 5  
C00654 00163	∂21-Mar-89  0932	CL-Compiler-mailer 	issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
C00659 00164	∂21-Mar-89  1020	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
C00661 00165	∂21-Mar-89  1338	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
C00668 00166	∂21-Mar-89  1344	CL-Compiler-mailer 	issue DEFINING-MACROS-NON-TOP-LEVEL
C00674 00167	∂21-Mar-89  1522	CL-Compiler-mailer 	issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5     
C00678 00168	∂21-Mar-89  1615	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL 
C00680 00169	∂21-Mar-89  1732	CL-Compiler-mailer 	**DRAFT** issue CLOS-MACRO-COMPILATION, version 2 
C00684 00170	∂21-Mar-89  1832	CL-Compiler-mailer 	Re: **DRAFT** issue CLOS-MACRO-COMPILATION, version 2  
C00687 00171	∂22-Mar-89  0836	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
C00693 00172	∂22-Mar-89  0905	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
C00696 00173	∂22-Mar-89  1031	CL-Compiler-mailer 	latest issue status summary   
C00702 00174	∂22-Mar-89  1213	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4 
C00705 00175	∂22-Mar-89  1219	CL-Compiler-mailer 	issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
C00715 00176	∂22-Mar-89  1351	CL-Compiler-mailer 	Re:  issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
C00718 00177	∂22-Mar-89  1354	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4 
C00722 00178	∂22-Mar-89  1523	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
C00728 00179	∂22-Mar-89  2115	CL-Compiler-mailer 	issue LOAD-TIME-EVAL, version 11   
C00735 00180	∂23-Mar-89  1139	CL-Compiler-mailer 	issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
C00738 00181	∂23-Mar-89  2107	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
C00745 00182	∂24-Mar-89  0824	CL-Compiler-mailer 	issue DEFINE-OPTIMIZER, version 6  
C00750 00183	∂24-Mar-89  0850	CL-Compiler-mailer 	Re: issue DEFINE-OPTIMIZER, version 6   
C00754 00184	∂24-Mar-89  0943	CL-Compiler-mailer 	Issue: DEFINE-OPTIMIZER  
C00759 00185	∂03-Apr-89  1421	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY   
C00763 00186	∂03-Apr-89  1453	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY   
C00767 00187	∂03-Apr-89  1456	CL-Compiler-mailer 	issue PROCLAIM-ETC-IN-COMPILE-FILE 
C00770 00188	∂03-Apr-89  1501	CL-Compiler-mailer 	Re: issue PROCLAIM-ETC-IN-COMPILE-FILE  
C00772 00189	∂03-Apr-89  1516	CL-Compiler-mailer 	issue PROCLAIM-ETC-IN-COMPILE-FILE 
C00775 00190	∂03-Apr-89  1510	Common-Lisp-Object-System-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY    
C00781 00191	∂03-Apr-89  1603	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
C00786 00192	∂03-Apr-89  1900	CL-Compiler-mailer 	issue PROCLAIM-ETC-IN-COMPILE-FILE 
C00790 00193	∂03-Apr-89  2131	CL-Compiler-mailer 	Re: issue PROCLAIM-ETC-IN-COMPILE-FILE  
C00792 00194	∂03-Apr-89  2217	CL-Compiler-mailer 	issue PROCLAIM-ETC-IN-COMPILE-FILE 
C00796 00195	∂04-Apr-89  0646	CL-Compiler-mailer 	Re: issue PROCLAIM-ETC-IN-COMPILE-FILE  
C00799 00196	∂04-Apr-89  0909	Common-Lisp-Object-System-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
C00801 00197	∂04-Apr-89  1215	CL-Compiler-mailer 	Issue: LOAD-TIME-EVAL    
C00804 00198	∂04-Apr-89  1252	CL-Compiler-mailer 	Re: Issue: LOAD-TIME-EVAL
C00806 00199	∂04-Apr-89  1252	CL-Compiler-mailer 	Re: Issue: LOAD-TIME-EVAL
C00808 00200	∂05-Apr-89  0807	CL-Compiler-mailer 	Re: issue PROCLAIM-ETC-IN-COMPILE-FILE  
C00810 00201	∂05-Apr-89  0953	CL-Compiler-mailer 	Re: issue PROCLAIM-ETC-IN-COMPILE-FILE  
C00817 00202	∂06-Apr-89  1140	CL-Compiler-mailer 	section 4.2    
C00823 00203	∂07-Apr-89  0954	CL-Compiler-mailer 	issue SYNTACTIC-ENVIRONMENT-ACCESS 
C00826 00204	∂10-Apr-89  0833	CL-Compiler-mailer 	lost mail 
C00828 00205	∂10-Apr-89  1536	CL-Compiler-mailer 	Issue WITH-COMPILATION-UNIT (Version 4) 
C00839 00206	∂11-Apr-89  0952	CL-Compiler-mailer 	Issue: COMPILER-DIAGNOSTICS (Version 11)
C00856 00207	∂11-Apr-89  1012	CL-Compiler-mailer 	Issue: CONSTANT-COMPILABLE-TYPES (Version 10)
C00880 00208	∂12-Apr-89  0657	CL-Compiler-mailer 	Re: Issue: COMPILER-DIAGNOSTICS (Version 11) 
C00883 00209	∂12-Apr-89  0904	CL-Compiler-mailer 	Re: Issue: COMPILER-DIAGNOSTICS (Version 11) 
C00885 00210	∂18-Apr-89  2114	CL-Compiler-mailer 	issue CONSTANT-FUNCTION-COMPILATION
C00888 00211	∂18-Apr-89  2119	CL-Compiler-mailer 	issue COMPILE-FILE-SYMBOL-HANDLING, version 3
C00905 00212	∂19-Apr-89  0835	CL-Compiler-mailer 	Re: Issue COMPILE-FILE-SYMBOL-HANDLING, version 3 
C00908 00213	∂19-Apr-89  0841	CL-Compiler-mailer 	Re: Issue COMPILE-FILE-SYMBOL-HANDLING, version 3 
C00911 00214	∂19-Apr-89  0948	CL-Compiler-mailer 	Re: Issue COMPILE-FILE-SYMBOL-HANDLING, version 3 
C00915 00215	∂20-Apr-89  0925	CL-Compiler-mailer 	issue COMPILE-FILE-SYMBOL-HANDLING, version 3
C00922 00216	∂20-Apr-89  0946	CL-Compiler-mailer 	Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 3 
C00927 00217	∂21-Apr-89  0904	CL-Compiler-mailer 	issue COMPILE-FILE-SYMBOL-HANDLING, version 3
C00931 ENDMK
C⊗;
∂13-Mar-89  1045	CL-Compiler-mailer 	Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89  10:44:47 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 555837; Mon 13-Mar-89 13:42:11 EST
Date: Mon, 13 Mar 89 13:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
To: David N Gray <Gray@DSG.csc.ti.com>, Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@sail.stanford.edu, Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>,
    KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <2814804793-2851395@Kelvin>
Message-ID: <19890313184158.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 13 Mar 89  12:13:13 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    > How about some wording like:
    > 
    >   The extent of the environment objects passed to MACROEXPAND or
    >   MACROEXPAND-1 by COMPILE-FILE, COMPILE, and EVAL is the dynamic extent
    >   during which the macro and its expansion are processed.  In
    >   particular, the extent includes the expansion of any other macro calls
    >   appearing lexically within the form returned from MACROEXPAND or
    >   MACROEXPAND-1.

    That would be fine.

It wouldn't be fine with me.  I would much prefer that we use the same
definition of dynamic extent here that we use everywhere else, namely
the extent ends when the macroexpander function returns.  That way we
don't have to spend the next year figuring out precisely what the
term "processed" means.  I have already thought of two problems with it.

    > I think this would fit in with issue SYNTACTIC-ENVIRONMENT-ACCESS, but
    > I'm still confused about why you would still need COPY-ENVIRONMENT.

    COPY-ENVIRONMENT would only be needed if there are implementations using
    stack list environments that disappear as soon as the macro expander
    returns.  Kent, does Symbolics need this?

I don't think Symbolics needs or wants COPY-ENVIRONMENT.  However, Symbolics
Genera does use macro expansion environments with dynamic extent.  I believe
Symbolics Cloe does also, although I haven't checked.

∂13-Mar-89  1034	Common-Lisp-Object-System-mailer 	Re: remote environments   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89  10:34:52 PST
Received: from Semillon.ms by ArpaGateway.ms ; 13 MAR 89 10:25:22 PST
Date: Mon, 13 Mar 89 10:22 PST
From: Gregor.pa@Xerox.COM
Subject: Re: remote environments
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
 Sandra.J.Loosemore%defun@cs.utah.edu, David N Gray <Gray@DSG.csc.ti.com>,
 Patrick%defun@cs.utah.edu, Dussud <dussud@lucid.com>, Kim A. Barrett
 <IIM%ECLA@ECLC.USC.EDU>, cl-compiler@sail.stanford.edu,
 common-lisp-object-system@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <8903131444.AA02017@defun.utah.edu>
Message-ID: <19890313182248.2.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no

    Date: Mon, 13 Mar 89 07:44:15 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    At least three of us (Moon, Gray, and myself) appear to agree that
    DEFMETHOD should not make the method function callable at compile time
    (by analogy to DEFUN).  If you're using the term "initfunctions" to
    refer to things like the SHARED-INITIALIZE method, then no, they can't
    be called at compile-time by default.

Yes, I understood that.  I didn't mean to suggest that it was an open
question, just that it was a basic question.  Answering it as we have
has some implications that I don't fully understand yet.  More on that
in a second.

    Personally, I think we could leave the issue of whether remote classes
    exist or are instantiable unspecified for now.  It would give those of
    you who are trying to sort out the meta-object protocol more freedom,
    and I don't think it would place an unreasonable burden on programmers.

This misses the major point from my message (looking back at my message,
the point is obscured).  The funny thing about specifying `meta-level'
behavior is that while we can specify minimal behavior, we can't specify
minimally.  In short, I think we have to take a stand on whether there
are remote metaobjects or not.

We must decide so that users who define their own metaobject classes can
know under what conditions those classes will be instantiated.  If a
user defined metaobject class is instantiated in the remote environment
some things will be `different'.  At the very least it will have these
funny remote functions.  User code needs to know that it must deal with
this.

I believe it is possible to take a minimal stance on what we specify.
One such workable minimal stance is to say that no portable metaobject
class will ever be instantiated in the remote environment.  In this
scheme, the implementation could instantiate its own metaobjects in the
remote environment, and it could instantiate placeholders for user
metaobjects as well.  This would make it possible to do the kind of file
compilation we all know and love when doing normal programming. Only
portable `compilers' would have to use the load, then compile approach.

-------

∂13-Mar-89  1043	CL-Compiler-mailer 	Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89  10:43:22 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA24753; Mon, 13 Mar 89 11:41:10 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA02266; Mon, 13 Mar 89 11:41:05 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131841.AA02266@defun.utah.edu>
Date: Mon, 13 Mar 89 11:41:04 MST
Subject: Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore),
        cl-compiler@sail.stanford.edu,
        "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
        "Kim A. Barrett" <IIM%ECLA@ECLC.USC.EDU>,
        KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Mon, 13 Mar 89  12:13:13 CST

Aha, that makes more sense now.  However, how would you handle 
AUGMENT-ENVIRONMENT without modifying your implementation?  
Presumably it would have to add things to the list in the special
variable, but how would you know when to take them off again?

For example, suppose I've written a code-walker using the primitives
in issue SYNTACTIC-ENVIRONMENT-ACCESS, and I'm walking a form like

    (let ((x ...))
      (let ((y ...))
          <body-1>)
      (let ((z ...))
          <body-2>))

To process <body-1>, I'd want to augment the environment from the outer
LET to contain the binding for Y.  But that binding has to be removed
before I add the binding for Z and process <body-2>.

One other thing that has occured to me on this issue is that it is
only information about lexical definitions that needs to be protected
against bashing, and that the implementation could be permitted to
bash global definitions in the environment.  This would eliminate the
objection to having to copy all the information about the compiler's
model of the remote environment, plus it's consistent with the
treatment of NIL to mean "whatever's in the local global environment
at the time you want to access that information". 

-Sandra
-------

∂13-Mar-89  1054	Common-Lisp-Object-System-mailer 	Re: remote environments   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 13 Mar 89  10:53:53 PST
Received: by ti.com id AA17001; Mon, 13 Mar 89 12:49:36 CST
Received: from Kelvin by tilde id AA27491; Mon, 13 Mar 89 12:41:40 CST
Message-Id: <2814806442-2950447@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 13 Mar 89  12:40:42 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Gregor.pa@Xerox.COM
Cc: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
        Sandra J Loosemore <sandra%defun@cs.utah.edu>,
        Patrick Dussud <dussud@lucid.com>,
        "Kim A. Barrett" <IIM%ECLA@ECLC.USC.EDU>,
        cl-compiler@sail.stanford.edu,
        common-lisp-object-system@sail.stanford.edu
Subject: Re: remote environments
In-Reply-To: Msg of Sun, 12 Mar 89 20:00 PST from Gregor.pa@Xerox.COM

> In this message I question, once again, the existence of remote
> metaobjects.  I may be behind the times here, but since no one answered
> the long message I sent about why we could do without remote metaobjects
> I am still stuck at that point.
...
> I don't understand these comments.  It seems to me that the only real
> questions are "is there a remote class object?" and "if so, how are
> remote functions represented?".

I don't see that we need to have separate classes for representing
things in the remote environment.  The problem with closures is very
easily dealt with by performing compile-time remote-environment
definitions only for top-level forms.  So I would say that yes there are
class objects in the remote environment and they look just like any
other class objects.  Generic functions and methods are another matter
though; permitting compile-time instantiation of classes in the remote
environment should not be difficult, but it may not be very useful
without having the methods for that class available.

>     > This is an interesting idea, but I think it's too restrictive.  Here's a
>     > plausible and many-times proposed application for metaobjects which
>     > would not be possible if we adopted this idea.  Suppose you made an
>     > optimizing compiler that is allowed to assume that no class
>     > redefinitions, no method redefinitions, and no newly-defined subclasses
>     > will be created at run time.  The compiler is to take advantage of this
> 
>     I certainly don't want to prevent any implementation from doing that.
>     The real issue is what is the minimal functionality that all
>     implementations must support.
> 
> As Moon says in a later message, the issue here is not what the
> implementation can do, its what portable programs can do.  It needs to
> be the case that one can write a portable, metaobject `compiler'.  Many
> people have wanted to do this.  People currently do this with PCL which
> surely has no remote metaobjects.

It sounds like there are two issues here:  (1) what a
standard-conforming Common Lisp compiler is required to do, and (2) what
a portable program is able to do with the meta-object protocol features
provided.  I was only addressing (1), but it sounds like you and Moon
have (2) in mind.

∂13-Mar-89  1113	CL-Compiler-mailer 	issue COMPILER-VERBOSITY, version 6
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89  11:13:45 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 555892; Mon 13-Mar-89 14:11:06 EST
Date: Mon, 13 Mar 89 14:10 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-VERBOSITY, version 6
To: barmar@Think.COM
cc: CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: <19890313165001.9.BARMAR@OCCAM.THINK.COM>
Message-ID: <890313141049.0.KMP@BOBOLINK.SCRC.Symbolics.COM>

[X3J13 removed.]

    Date: Mon, 13 Mar 89 11:50 EST
    From: Barry Margolin <barmar@Think.COM>

    I see the benefit of :PRINT, but do we really need :VERBOSE?
    At this stage of the game I don't see the need to add
    gratuitous features like this.

The original reason this was generated is that some implementations
already offer this `gratuitous feature' and some users (e.g., me) want a
way to get them to turn it off.  Adding a keyword is little extra effort
for those implementations not already providing the option; removing the
functionality is something I thought we'd get opposition to if we didn't
provide a way for people to switch it back on in implementations where
they were used to it.

Note, too, that the return value of compile-file gets lost if you put
calls to FORMAT in, so the rewrite is more complex if you care about
the data flow.

∂13-Mar-89  1149	CL-Compiler-mailer 	Re:  Issue CONSTANT-COMPILABLE-TYPES, version 7   
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89  11:49:45 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA15985; Mon, 13 Mar 89 11:23:36 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA20038; Mon, 13 Mar 89 11:19:51 PST
Received: by clam.sun.com (4.0/SMI-4.0)
	id AA23772; Mon, 13 Mar 89 11:23:23 PST
Date: Mon, 13 Mar 89 11:23:23 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903131923.AA23772@clam.sun.com>
To: cperdue@Sun.COM, rpg@lucid.com
Subject: Re:  Issue CONSTANT-COMPILABLE-TYPES, version 7
Cc: cl-compiler@sail.stanford.edu

> Therefore, variables are mutable, and EQness required by the standard
> for conforming programs should be maintained.
> 
Excuse me, but we can't just carry the usual "EQness required by the
standard" over to file compilation, regardless of the details of what
we think that requirement is.

Like READ and PRINT, file compilation gets Lisp's "feet" into the
distributed world in the sense that one cannot define the behavior
of everything with respect to a single Lisp address space.

> If there is a problem, I
> think it is better to change the semantics of Common Lisp rather than
> making compiling and loading special cases.

Well, that would be facing the problem squarely.  I'll let you
stick your fist into the tar baby first.  :-} .

∂13-Mar-89  1151	Common-Lisp-Object-System-mailer 	Re: remote environments   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89  11:51:37 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA26986; Mon, 13 Mar 89 12:43:02 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA02353; Mon, 13 Mar 89 12:42:59 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131942.AA02353@defun.utah.edu>
Date: Mon, 13 Mar 89 12:42:58 MST
Subject: Re: remote environments
To: Gregor.pa@Xerox.COM
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
        David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
        David N Gray <Gray@DSG.csc.ti.com>, Patrick Dussud <dussud@lucid.com>,
        Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>, cl-compiler@sail.stanford.edu,
        common-lisp-object-system@sail.stanford.edu
In-Reply-To: Gregor.pa@Xerox.COM, Mon, 13 Mar 89 10:22 PST

> Date: Mon, 13 Mar 89 10:22 PST
> From: Gregor.pa@Xerox.COM
> 
> We must decide so that users who define their own metaobject classes can
> know under what conditions those classes will be instantiated.

Perhaps my ignorance is showing, but I didn't think that chapters 1 &
2 gave users enough information to define their own metaobject classes
anyway.  If making this statement is only of interest for users of the
part of CLOS that is specified in chapter 3, I don't think we absolutely 
positively need to say anything about this now.  Frankly, I question 
whether the metaobject protocol is stable enough that we should even
*try* to do so now.

> I believe it is possible to take a minimal stance on what we specify.
> One such workable minimal stance is to say that no portable metaobject
> class will ever be instantiated in the remote environment.  In this
> scheme, the implementation could instantiate its own metaobjects in the
> remote environment, and it could instantiate placeholders for user
> metaobjects as well.  This would make it possible to do the kind of file
> compilation we all know and love when doing normal programming. Only
> portable `compilers' would have to use the load, then compile approach.

I guess part of the problem I'm having is understanding what this
implies for normal user code.  I think we ought to say something in
the standard that your average ignoramus like me can understand, about
how to arrange programs so they will compile correctly.  The current
writeup does that, your statement here doesn't.

Is there anything in the MINIMAL proposal that is fundamentally
incompatible with this stance?  I can see that wanting classes to be
instantiable at compile-time (as in proposal NOT-SO-MINIMAL) would
imply that the DEFCLASS macro causes some kind of metaobject to be
created at compile time.  However, it would still be possible to do
without distinguished "remote" metaobjects by having DEFCLASS make the
class fully defined in the compile-time environment.

-Sandra

-------

∂13-Mar-89  1206	CL-Compiler-mailer 	Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
Received: from ti.com by SAIL.Stanford.EDU with TCP; 13 Mar 89  12:06:40 PST
Received: by ti.com id AA00360; Mon, 13 Mar 89 14:06:16 CST
Received: from Kelvin by tilde id AA29423; Mon, 13 Mar 89 13:51:43 CST
Message-Id: <2814810638-3202528@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 13 Mar 89  13:50:38 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Cc: cl-compiler@sail.stanford.edu,
        "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
        "Kim A. Barrett" <IIM%ECLA@ECLC.USC.EDU>
Subject: Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
In-Reply-To: Msg of Mon, 13 Mar 89 11:41:04 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)

> Aha, that makes more sense now.  However, how would you handle 
> AUGMENT-ENVIRONMENT without modifying your implementation?  
> Presumably it would have to add things to the list in the special
> variable, but how would you know when to take them off again?

I hadn't thought about that before, but that could be handled by using
the interpreter's representation for the AUGMENT-ENVIRONMENT data and
having the environment accessors look there before using the compiler's
special variables.  The compiler wouldn't ever be looking at an
augmented environment; macros would, but the interpreter and compiler
already need to use the same representation for local macro definitions.

∂13-Mar-89  1221	CL-Compiler-mailer 	Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
Received: from ti.com by SAIL.Stanford.EDU with TCP; 13 Mar 89  12:21:26 PST
Received: by ti.com id AA00520; Mon, 13 Mar 89 14:20:16 CST
Received: from Kelvin by tilde id AA29821; Mon, 13 Mar 89 14:08:24 CST
Message-Id: <2814811645-3263023@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 13 Mar 89  14:07:25 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
        cl-compiler@sail.stanford.edu,
        "Kim A. Barrett" <IIM%ECLA@ECLC.USC.EDU>,
        KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
In-Reply-To: Msg of Mon, 13 Mar 89 13:41 EST from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

> It wouldn't be fine with me.  I would much prefer that we use the same
> definition of dynamic extent here that we use everywhere else, namely
> the extent ends when the macroexpander function returns.  That way we
> don't have to spend the next year figuring out precisely what the
> term "processed" means.  I have already thought of two problems with it.

But if a strict dynamic extent is adopted, then environments can't be
included in the expansion of the macro, and functions such as
FIND-CLASS, ENSURE-GENERIC-FUNCTION, and ENSURE-CLASS that are supposed
to accept environment arguments will need to be redesigned.

∂13-Mar-89  1233	CL-Compiler-mailer 	Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89  12:33:05 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 555974; Mon 13-Mar-89 15:29:18 EST
Date: Mon, 13 Mar 89 15:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, cl-compiler@sail.stanford.edu,
    Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <2814811645-3263023@Kelvin>
Message-ID: <19890313202914.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 13 Mar 89  14:07:25 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    > It wouldn't be fine with me.  I would much prefer that we use the same
    > definition of dynamic extent here that we use everywhere else, namely
    > the extent ends when the macroexpander function returns.  That way we
    > don't have to spend the next year figuring out precisely what the
    > term "processed" means.  I have already thought of two problems with it.

    But if a strict dynamic extent is adopted, then environments can't be
    included in the expansion of the macro, and functions such as
    FIND-CLASS, ENSURE-GENERIC-FUNCTION, and ENSURE-CLASS that are supposed
    to accept environment arguments will need to be redesigned.

That is correct.

∂13-Mar-89  1319	CL-Compiler-mailer 	Re: issue SAFE-CODE, version 1
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89  13:18:22 PST
Date: 13 Mar 1989 16:14-EST
Sender: ROSENKING@A.ISI.EDU
Subject: Re: issue SAFE-CODE, version 1
From: ROSENKING@A.ISI.EDU
To: cl-compiler@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]13-Mar-89 16:14:03.ROSENKING>
In-Reply-To: <8903131726.AA02193@defun.utah.edu>


I believe that the basis for this proposal is well justified and I support
the intent of what is being defined. I'm not 100% for the naming though.
Anyhow, I have seen these type of problems come up before in implementations
of C and FORTRAN, where it was unclear what the default values were for
OPTIMIZE and DEBUG are and so I agree that some known universal default
should be specified, though perhaps by a name besides SAFE-CODE.

    Jeff Rosenking

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

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

Two objections here:



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

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

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



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

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

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

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

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

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

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

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


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

∂13-Mar-89  1501	CL-Compiler-mailer 	Issue MACRO-ENVIRONMENT-EXTENT
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89  15:01:20 PST
Date: Sun 12 Mar 89 16:06:56-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue MACRO-ENVIRONMENT-EXTENT
To: cl-compiler@SAIL.STANFORD.EDU
cc: iim%ECLA@ECLC.USC.EDU
Message-ID: <12477531375.30.IIM@ECLA.USC.EDU>

I think the suggestions to move things to Chapter 3 if they are currently
specified as requiring an environment argument are misguided.  Chapter 3
probably won't make it into the standard, but we don't want to shut the door
on it for all time because we didn't take into account the needs of Chapter 3
when we "solved" some of these sticky problems.

kab
-------

∂13-Mar-89  1458	CL-Compiler-mailer 	Issue MACRO-ENVIRONMENT-EXTENT
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89  14:58:11 PST
Date: Sat 11 Mar 89 19:36:38-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue MACRO-ENVIRONMENT-EXTENT
To: Moon@SCRC-STONY-BROOK.ARPA
cc: iim%ECLA@ECLC.USC.EDU, cl-compiler@SAIL.STANFORD.EDU
Message-ID: <12477307405.30.IIM@ECLA.USC.EDU>

Your recent statement that you are convinced that CLOS made a mistake with
regard to environments has made me reconsider the problem, and I think I may be
convincable.  I'm going to throw some thoughts your way to see if maybe we can
reach some definite, defendable, conclusions on the subject.

Right now, our implementation provides some functions for manipulating remote
environments without specifying the environment as an argument.  These
functions work by referencing a special variable bound by the compiler.
Currently the only places it is legit to put calls to them is in the compiler
itself or in (eval-when (compile) ...) forms.  It wouldn't be hard to arrange
for a compiler-like user program to be able to use these.

It is because these functions usually seem to be adequate for the job that I
think you might be right.  The places where they currently don't work seem to
be precisely those places where somebody has said that a function (like
find-class) takes an environment argument just to distinguish between remote
and local environments.

Suppose we were to say that T is a special indicator for the remote null
lexical environment, just as NIL is a special indicator for the local null
lexical environment.  Then find-class could be defined as

  (defun find-class (name &optional (errorp t) env)
    (cond ((and (environment-remote-p env)
		<< look it up in the remote environment, in some special >>))
	  (<< look it up in the local environment >>)
	  (errorp (error ...))
	  (t nil)))

and your suggestion of using T as the argument to find-class works, and all the
places which might want to call find-class can either pass in an environment
argument if they've got one handy (rather than forcing them to call
environment-remote-p and passing the result) and it is legit to do so within
the constraints of the extent of the environment, or they can call
environment-remote-p and pass the result if they can't use the environment
because of the extent problem, or they can use T or NIL if they happen to know
which they want.

Saying that T is a null environment looks a little funny, but I thing something
like this would simplify some of SYNTACTIC-ENVIRONMENT-ACCESS and sort of
normalize everything.

To make this all fly we would have to say some things about when it is legit to
use T as an environment, but I don't think this is hard.  Admitedly, people can
get strange bugs if they use it wrongly, but many of the same kinds of problems
can occur with passing around environments that are real data structures.

The one thing I'm concerned about is the use of a special to hold the
environment.  I think its ok, as long as there is some specified way to bind it
and everybody who wants to do compile-file-like things uses that mechanism.
Some sort of with- construct, and don't even bother to document what the
special variable is, seems to me to be the right way to go.  The only case I
can think of where this might be a problem is if somebody were trying to
distribute the work of their 'compilation' over multiple processes/processors,
and I think any system that would support doing such a thing is likely to have
some mechanism for doing what's needed, like being able to have process trees,
with children inheriting bindings from parents.

Note that this does throw away the possibility of operating on multiple
distinct remote environements at the same time.  I mentioned this in a message
a while back to the small group discussing remote environment issues.  Is that
so bad?  Maybe we'll just have to say "Tough. You can't do it."

Note that I read your message after sending out version 3 of
syntactic-environment-access, which includes some stuff that goes off in a
different direction from what I think you are suggesting.  If we can agree to
something like what I'm describing here, that proposal will have to be yanked
around to a somewhat different path.

kab
-------

∂13-Mar-89  1500	CL-Compiler-mailer 	Issue WITH-COMPILATION-UNIT   
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89  15:00:50 PST
Date: Sun 12 Mar 89 16:00:00-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue WITH-COMPILATION-UNIT
To: kmp@SCRC-STONY-BROOK.ARPA
cc: cl-compiler@SAIL.STANFORD.EDU, iim%ECLA@ECLC.USC.EDU
Message-ID: <12477530111.30.IIM@ECLA.USC.EDU>

I strongly oppose the behavior you proposed for compile and compile-file.  It
is my belief that whether to override or not must be controlled through an
argument to the compile functions, with the default being to override.
Otherwise, all existing code which makes use of the compile functions must
be modified to protect itself by wrapping a
(with-compilation-unit (:override t) ...) around the calls to the compiler.

Consider a stream system built on an object system which will compose and
compile functions on the fly on an as needed basis.  It would be very strange
for the functions so generated while doing file io for the user's compile-file
to have any relationship with said compile-file.

I agree with your position that implementation-dependent extensions must be
explicitly requested.

kab
-------

∂13-Mar-89  1501	CL-Compiler-mailer 	Issue DEFINE-OPTIMIZER   
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89  15:01:17 PST
Date: Sun 12 Mar 89 16:02:34-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue DEFINE-OPTIMIZER
To: kmp@SCRC-STONY-BROOK.ARPA
cc: cperdue@SUN.COM, cl-compiler@SAIL.STANFORD.EDU, iim%ECLA@ECLC.USC.EDU
Message-ID: <12477530580.30.IIM@ECLA.USC.EDU>

I think you may have gotten the sense of Cris' INLINE comment wrong.  I
believe what he was suggesting is that NOTINLINE declarations should inhibit
optimizers, a position I agree with.  I also think it would be better to
specify the behavior when both an optimizer and an inline are present, rather
than leaving it 'unspecified but harmless'.  I'd suggest that optimizers have
precedence.  The rational is that this allows an optimizer to look for
special patterns in the arguments, and to defer to the inline if it doesn't
find them.  Of course, there's the problem that the compiler might then ignore
the inline.

I agree with you that OPTIMIZER-FUNCTION is a bad idea.  I think the main
problem is that it spells trouble for implementations which want to support
multiple optimizers for the same function.

kab
-------

∂13-Mar-89  1501	CL-Compiler-mailer 	Issue PROCLAIM-ETC-IN-COMPILE-FILE 
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89  15:01:10 PST
Date: Sun 12 Mar 89 16:05:59-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue PROCLAIM-ETC-IN-COMPILE-FILE
To: cl-compiler@SAIL.STANFORD.EDU
cc: iim%ECLA@ECLC.USC.EDU
Message-ID: <12477531202.30.IIM@ECLA.USC.EDU>

Proposal YES violates the general approach we've been taking of trying to
limit side-effects on the local environment during compilation.

Proposal NO makes PROCLAIM virtually worthless.

Proposal NEW-MACRO -- While this matches up with other stuff we've been doing,
I'm concerned about two things.  First, I really dislike the name DEFPROCLAIM.
This thing isn't defining anything!  It sounds like something that modifies
the behavior of PROCLAIM, not something that actually makes a proclamation.
Second, I'm concerned about the cost to users.  I think the statement that

  "Under any of these proposals, some users would probably have to make minor
   changes to their code."

is rather misleading for this case.  There are a lot of PROCLAIMs out there.

For current practice, the IIM compiler has special top-level handling for
PROCLAIM when the argument is a constant.  The information is recorded in the
remote environment.

kab
-------

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

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

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

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

kab
-------

∂13-Mar-89  1545	CL-Compiler-mailer 	Issue MACRO-ENVIRONMENT-EXTENT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89  15:44:47 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556182; Mon 13-Mar-89 18:41:47 EST
Date: Mon, 13 Mar 89 18:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue MACRO-ENVIRONMENT-EXTENT
To: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
cc: cl-compiler@SAIL.STANFORD.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <12477307405.30.IIM@ECLA.USC.EDU>
Message-ID: <19890313234142.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

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

    Your recent statement that you are convinced that CLOS made a mistake with
    regard to environments has made me reconsider the problem, and I think I may be
    convincable.  I'm going to throw some thoughts your way to see if maybe we can
    reach some definite, defendable, conclusions on the subject.

    Right now, our implementation provides some functions for manipulating remote
    environments without specifying the environment as an argument.  These
    functions work by referencing a special variable bound by the compiler.
    Currently the only places it is legit to put calls to them is in the compiler
    itself or in (eval-when (compile) ...) forms.  It wouldn't be hard to arrange
    for a compiler-like user program to be able to use these.

That's interesting, because that is exactly how I want to propose
things like the macroexpansion of defmethod should work.  The fact that
your implementation already works this way gives me more confidence
that I've made the right choice.

It's a little confusing, because this issue is being simultaneously discussed
on cl-compiler, common-lisp-object-system, and in private mail.  So if I say
something that seems totally off the wall, it might be that I'm assuming
you've seen something that was only sent to a different mailing list.

    It is because these functions usually seem to be adequate for the job that I
    think you might be right.  The places where they currently don't work seem to
    be precisely those places where somebody has said that a function (like
    find-class) takes an environment argument just to distinguish between remote
    and local environments.

    Suppose we were to say that T is a special indicator for the remote null
    lexical environment, just as NIL is a special indicator for the local null
    lexical environment.  

What I'm going to propose is nil for the local null lexical environment,
compile-file for the special environment the compile-file function uses
as a model of the load-time null lexical environment, and also a macroexpansion
environment can be used provided you are within its dynamic extent.

As I think you and I have both mentioned at various times, this could be
extended to allow other kinds of environments, for instance one that allows
hypothetical class setups that aren't in force in the running world.  However
I don't want to propose that at this time; it can be an implementation extension
at present and maybe be standardized in some future standard.

			  Then find-class could be defined as

      (defun find-class (name &optional (errorp t) env)
	(cond ((and (environment-remote-p env)
		    << look it up in the remote environment, in some special >>))
	      (<< look it up in the local environment >>)
	      (errorp (error ...))
	      (t nil)))

Right.  environment-remote-p just has to accept the special symbol
compile-file as well as nil and macroexpansion environments.

    To make this all fly we would have to say some things about when it is legit to
    use T as an environment, but I don't think this is hard.  Admitedly, people can
    get strange bugs if they use it wrongly, but many of the same kinds of problems
    can occur with passing around environments that are real data structures.

What I plan to say is that compile-file as an environment is valid only
inside of an (eval-when (compile) ...).  I think that has just the right
behavior.  Note that compile must be the -only- situation specified.

    The one thing I'm concerned about is the use of a special to hold the
    environment.  I think its ok, as long as there is some specified way to bind it
    and everybody who wants to do compile-file-like things uses that mechanism.
    Some sort of with- construct, and don't even bother to document what the
    special variable is, seems to me to be the right way to go.  The only case I
    can think of where this might be a problem is if somebody were trying to
    distribute the work of their 'compilation' over multiple processes/processors,
    and I think any system that would support doing such a thing is likely to have
    some mechanism for doing what's needed, like being able to have process trees,
    with children inheriting bindings from parents.

I don't think we should specify that it's a special variable, only that
the functions such as find-class that deal with this thing know the
implementation-dependent way to find it.

    Note that this does throw away the possibility of operating on multiple
    distinct remote environements at the same time.  I mentioned this in a message
    a while back to the small group discussing remote environment issues.  Is that
    so bad?  Maybe we'll just have to say "Tough. You can't do it."

Not entirely, see possible future proposal mentioned above.  What this really
does is to decouple the multiple remote environments idea from macroexpansion
environments.

    Note that I read your message after sending out version 3 of
    syntactic-environment-access, which includes some stuff that goes off in a
    different direction from what I think you are suggesting.  If we can agree to
    something like what I'm describing here, that proposal will have to be yanked
    around to a somewhat different path.

Fortunately I haven't read that proposal yet.  I'll postpone reading it for
a few days.

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

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

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

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

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

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

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

∂13-Mar-89  1500	CL-Compiler-mailer 	Re: issue SAFE-CODE, version 1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89  15:00:01 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556127; Mon 13-Mar-89 17:57:16 EST
Date: Mon, 13 Mar 89 17:56 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue SAFE-CODE, version 1
To: ROSENKING@A.ISI.EDU
cc: cl-compiler@SAIL.STANFORD.EDU
In-Reply-To: <[A.ISI.EDU]13-Mar-89 16:14:03.ROSENKING>
Message-ID: <890313175657.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

The concept of ``safe code'' is already defined by the issue
ERROR-TERMINOLOGY.  It is needed in order to define the term ``should
signal.''  See that proposal for details.

SAFE-CODE is only the issue name, it is not the name of any
proposed feature.

The only issue here is whether the abstract term ``safe code''
in Kathy's ERROR-TERMINOLOGY has any mapping to what you do 
in your code.  This issue seeks to define that at least in the
situation where you ask for (OPTIMIZE (SAFETY 3)), you are asking
for safe code.

If you agree that saying (OPTIMIZE (SAFETY 3)) is asking for your
code to be safe, then I think you should support this proposal.

If what you are worried about is whether the default in the absence
of such a declaration is `safe' or `unsafe' -- a separate issue
(now before CL-Cleanup) will address this.  I believe the issue
is called OPTIMIZE-SAFETY.

In retrospect, it's clear I should not have split the two issues
but at the time it seemed like the right thing.

∂13-Mar-89  1647	CL-Compiler-mailer 	Re:  issue DEFINE-OPTIMIZER, version 5  
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89  16:47:05 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA27387; Mon, 13 Mar 89 16:47:48 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA06344; Mon, 13 Mar 89 16:44:04 PST
Received: by clam.sun.com (4.0/SMI-4.0)
	id AA24118; Mon, 13 Mar 89 16:47:36 PST
Date: Mon, 13 Mar 89 16:47:36 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903140047.AA24118@clam.sun.com>
To: cl-compiler@sail.stanford.edu
Subject: Re:  issue DEFINE-OPTIMIZER, version 5

I think the spec for this is going to have to hedge on
whether optimizers defined in this way affect functions
in the LISP package.  Perhaps it would be acceptable
to say, "Defining an optimizer for a function in the LISP
package may affect some, all, or no calls on that function."

Barrett suggests that optimizers need to have precedence over
INLINE for a function.  This must surely be true.  Are we
to tell users to not declare a function INLINE because that
might calls not to be optimized?

Regarding the accessor primitive, the problems with that
are not much harder than the problems with DEFINE-OPTIMIZER.

For example, if it is permitted to define an optimizer on a function
in package LISP, then we specify that those are all NIL
as supplied by the LISP vendor.

The operations on optimizers are incomplete in the current proposal,
and adding a suitable primitive would fix that problem and let
users write portable code for testing for an optimizer, copying,
accessing, and moving.

I'm not at all sold on the argument that a primitive would
interfere with an implementation that wishes to have multiple
optimizers for the same function.  I see nothing in the current
proposal to support that capability.

∂13-Mar-89  1655	CL-Compiler-mailer 	Re: issue PROCLAIM-ETC-IN-COMPILE-FILE, version 3 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 13 Mar 89  16:55:11 PST
Received: by ti.com id AA04177; Mon, 13 Mar 89 18:52:42 CST
Received: from Kelvin by tilde id AA08146; Mon, 13 Mar 89 18:35:57 CST
Message-Id: <2814827699-4227621@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 13 Mar 89  18:34:59 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Cc: cl-compiler@sail.stanford.edu
Subject: Re: issue PROCLAIM-ETC-IN-COMPILE-FILE, version 3
In-Reply-To: Msg of Sat, 11 Mar 89 13:41:24 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)

> Proposal PROCLAIM-ETC-IN-COMPILE-FILE:YES:
> 
>   Require COMPILE-FILE to treat top-level calls to PROCLAIM as if they
>   were wrapped in an (EVAL-WHEN (COMPILE LOAD EVAL) ...).

This is my preference.

> Proposal PROCLAIM-ETC-IN-COMPILE-FILE:NO:
> 
>   Clarify that calls to PROCLAIM should be treated the same as any
>   other function call.  Users should wrap an explicit EVAL-WHEN around
>   top-level calls to PROCLAIM if they want them to affect compilation.

This means that the EVAL-WHEN would be needed on nearly every use of
PROCLAIM, which goes against the model that EVAL-WHEN is only needed for
exceptional situations.  (Page 69 of CLtL says about EVAL-WHEN that "Its
uses are relatively esoteric.")

> Proposal PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO:
> 
>   Add a new macro:
> 
>   DEFPROCLAIM &rest decl-specs					[Macro]
> 
>   This macro PROCLAIMs the given <decl-specs>, which are not
>   evaluated.  If a call to this macro appears at top-level in a file
>   being processed by the file compiler, the proclamations are also
>   made at compile-time.  As with other defining macros, it is 
>   unspecified whether or not the compile-time side-effects of a 
>   DEFPROCLAIM persist after the file has been compiled.

I don't like this name because the convention is that macros with names
beginning with DEF... are used to define things, with the name of the
thing being defined appearing as the first argument or as part of the
first argument.  DEFPROCLAIM doesn't define anything.  I think this
would also confuse users because it has the same syntax as DECLARE, but
the two can't be used interchangeably.  It makes me wonder whether we
should just permit top-level DECLAREs, but then _it_ would need special
handling by the compiler since a macro definition would confuse the
semantics of local declarations, so you don't win.

> Cost to users:
> 
>   For proposal YES, users would have no way to suppress compile-time
>   evaluation of a top-level call to PROCLAIM.  Wrapping it in an
>   (EVAL-WHEN (EVAL LOAD)...) wouldn't work under the model of how
>   EVAL-WHEN works in proposal EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL.

How about (LET () (PROCLAIM ...)) ?

∂13-Mar-89  1703	CL-Compiler-mailer 	**DRAFT** issue DEFCONSTANT-NOT-WIRED, version 6  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89  17:03:00 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 13 Mar 89 19:59:22 EST
Date: Mon, 13 Mar 89 20:00 EST
From: Barry Margolin <barmar@Think.COM>
Subject: **DRAFT** issue DEFCONSTANT-NOT-WIRED, version 6
To: cl-compiler@sail.stanford.edu
In-Reply-To: <8903132328.AA02557@defun.utah.edu>
Message-Id: <19890314010044.2.BARMAR@OCCAM.THINK.COM>

    Date: Mon, 13 Mar 89 16:28:37 -0700
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    Forum:		Compiler
    Issue:		DEFCONSTANT-NOT-WIRED

I have a terminology: use the term READ-ONLY in place of CONSTANT in the
suggested declaration, DEFINE-VARIABLE, etc.  The term "constant" should
be reserved for things that are truly constant (pi, e,
number-of-bits-per-word, etc.); this is why they can be wired into code.
A symbol whose value might change due to external influences but which
should not be changeable by the user program is simply "read only".
It's like PROM -- the program can't change the value of a location, but
the user can plug in a new chip with a new value.

I like the idea of a DEF-READ-ONLY, which could expand into a DEFVAR
followed by a (PROCLAIM '(READ-ONLY <var>)).  I also think that there
should be a NOT-READ-ONLY declaration; this way, if the constant needs
to be changed for some reason (e.g. reloading the file containing the
DEF-READ-ONLY form) there is a mechanism for turning off checking of
attempts to modify read-only variables.  I'm not wedded to this idea,
though, because it means that read-only variables could not be put in
ROM (and depending on the system architecture, it could also prevent
them from being put in read-only memory segments).

                                                barmar

∂13-Mar-89  1643	X3J13-mailer 	issue COMPILER-LET-CONFUSION, version 7  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89  16:43:27 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 13 Mar 89 19:39:46 EST
Date: Mon, 13 Mar 89 19:41 EST
From: Barry Margolin <barmar@Think.COM>
Subject: issue COMPILER-LET-CONFUSION, version 7
To: cl-compiler@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132314.AA02546@defun.utah.edu>
Message-Id: <19890314004109.1.BARMAR@OCCAM.THINK.COM>

    Date: Mon, 13 Mar 89 16:14:26 -0700
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

	In interpreters which do not do a semantic-prepass, it is necessary
	to fully macroexpand the body. Assuming the presence of a
	SYSTEM::MACROEXPAND-ALL primitive, the definition of COMPILER-LET
	could look like:
	  (DEFMACRO COMPILER-LET (BINDINGS &BODY FORMS &ENVIRONMENT ENV)
	    (SETQ BINDINGS ;; Assure no non-atom bindings
		  (MAPCAR #'(LAMBDA (BINDING) 
			      (IF (ATOM BINDING) (LIST BINDING) BINDING))
			  BINDINGS))
	    (PROGV (MAPCAR #'CAR BINDINGS)
		   (MAPCAR #'CDR BINDINGS)
	      (SYSTEM::MACROEXPAND-ALL `(PROGN ,@FORMS) ENV)))

Modulo some bugs in the code.  Shouldn't the second-to-last line be:

	(MAPCAR #'(LAMBDA (BINDING)
		    (eval (CaDR BINDING)))
		BINDINGS)

(my additions are in lowercase)?

                                                barmar

∂13-Mar-89  1730	CL-Compiler-mailer 	issue DEFINE-OPTIMIZER, version 5  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89  17:29:43 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 13 Mar 89 20:26:02 EST
Date: Mon, 13 Mar 89 20:27 EST
From: Barry Margolin <barmar@Think.COM>
Subject: issue DEFINE-OPTIMIZER, version 5
To: cl-compiler@sail.stanford.edu
In-Reply-To: <8903132331.AA02562@defun.utah.edu>
Message-Id: <19890314012719.3.BARMAR@OCCAM.THINK.COM>

While I like the proposal in general, I don't think it's appropriate to
add this to the language at this time.  If most Lisp vendors are in
favor of it, though, my objection is pretty weak.  But there's still the
editorial issue of adding it to the standard.  I don't really think it's
worth it for the first version of the standard.

Also, I don't see a whole lot of value in portable optimizers.  Yes, the
Macsyma example is a good one, but the real value of optimizers comes
when they translate into calls to extra fast, internal functions.
Portable optimizers can't do this, and non-portable optimizers don't
need to be defined using a portable mechanism.

                                                barmar

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

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

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

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

Think of it as input to the loader.

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

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

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

This example illustrates the following assumptions about dumping
constants: 

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

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

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

> One is that this scheme cannot support circular constants.

I second the objection.

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

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

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

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

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

∂13-Mar-89  1809	CL-Compiler-mailer 	**DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3    
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89  18:09:14 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 13 Mar 89 21:05:31 EST
Date: Mon, 13 Mar 89 21:06 EST
From: Barry Margolin <barmar@Think.COM>
Subject: **DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3
To: cl-compiler@sail.stanford.edu
In-Reply-To: <8903132355.AA02585@defun.utah.edu>
Message-Id: <19890314020643.4.BARMAR@OCCAM.THINK.COM>

I'm not really sure how I feel about this issue.  My gut reaction is
that only dynamic extent should really be necessary.

In any case, if DYNAMIC-WITH-COPIER is seriously proposed, I'd prefer a
different name for the function.  A function COPY-xxx that is permitted
to return its argument instead of a copy seems poorly named (do we have
any other such functions?).  COPY-ENVIRONMENT-IF-NECESSARY is better,
since it explicitly mentions the conditional nature, but it's pretty
long (but how often will it be used?).  INDEFINITE-EXTENT-ENVIRONMENT is
also a good name, but just as long.

Maybe a declaration is the right thing for this, as in the
DYNAMIC-EXTENT cleanup proposal.  I'd prefer dynamic extent to be the
default, with a declaration to request indefinite extent since that is
less commonly needed.  Implementations may ignore the declaration, but
they must then always provide indefinite extent.  A simpler proposal
would be to make indefinite extent the default, and then the
DYNAMIC-EXTENT cleanup proposal would permit programmers to explicitly
declare dynamic environments.

                                                barmar

∂13-Mar-89  1836	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 13 Mar 89  18:35:58 PST
Received: by ti.com id AA04725; Mon, 13 Mar 89 20:33:56 CST
Received: from Kelvin by tilde id AA10072; Mon, 13 Mar 89 20:28:54 CST
Message-Id: <2814834476-4634758@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 13 Mar 89  20:27:56 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Cc: cl-compiler@sail.stanford.edu, "Kim A. Barrett" <IIM@ECLA.USC.EDU>
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
In-Reply-To: Msg of Sun, 12 Mar 89 10:59:59 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)

Either alternative SMALL or LARGE is reasonable, but I don't think that
MEDIUM is viable because ENVIRONMENT-REMOTE-P and
WITH-REMOTE-ENVIRONMENT aren't very useful if you don't have
ENVIRONMENT-PROPERTY.  ENVIRONMENT-REMOTE-P might be useful in
conjunction with FIND-CLASS, but the use of environments by FIND-CLASS
seems to be in question now.

>   Using SETF of ENVIRONMENT-PROPERTY affects all environments which
>   refer to the same environment model.  In particular, if ENV is a
>   local environment then all local environments are affected, ...

Need to make clear that this affects the global environment, not just
all local environments.

>		... while if
>   ENV is a remote environment, then all environments refering to the
>   same remote environment model as the argument are affected.

"same model" is not a defined term; would be more precise to say all
environments which inherit from the same remote environment.

>  An possible alternative syntax for WITH-REMOTE-ENVIRONMENT might be
>    WITH-REMOTE-ENVIRONMENT (var &key) &body body
>  Can anyone suggest candidates for keyword options?  We could do this
>  even if we can't think of any immediately, leaving room for
>  implementation-specific extensions.  One candidate option that some
>  implementations might want would be to specify a target machine for
>  the compilation.

Yes, I think that would be a good idea.  For cross-compilation, I would
want the COMPILE-FILE remote environment to inherit from a remote
environment representing the target machine.  How about a :PARENT option
for specifying a parent environment?

∂14-Mar-89  0644	CL-Compiler-mailer 	issue DEFINE-OPTIMIZER, version 5  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  06:44:10 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556489; Tue 14-Mar-89 09:41:41 EST
Date: Tue, 14 Mar 89 09:41 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DEFINE-OPTIMIZER, version 5
To: barmar@Think.COM
cc: cl-compiler@sail.stanford.edu
In-Reply-To: <19890314012719.3.BARMAR@OCCAM.THINK.COM>
Message-ID: <890314094133.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Mon, 13 Mar 89 20:27 EST
    From: Barry Margolin <barmar@Think.COM>

    ... the real value of optimizers comes when they translate into calls
    to extra fast, internal functions. ...

What makes you say that you can't translate particular calls to
a user function into extra fast (even constant-time!) algorithms
based on domain-specific knowledge?

    Portable optimizers can't do this, and non-portable optimizers don't
    need to be defined using a portable mechanism.

I believe this claim is unsubstantiated and unsubstantiable. In many
implementations, internal functions have no special property that user
programs do not.  In some cases, that makes the optimizers that much
more important since most internal functions run a constant factor 
faster, but do not have any algorithmic leverage over user programs.
Optimizers are potentially able to do much better than built-in 
optimizations because they can use domain-specific information that
is beyond the power of even the proverbial SCC (Sufficiently Clever
Compiler).

Optimizers have been around for a -long- time. They are not new
technology. If we cannot adopt at least this much this time, I see
no reason why for CL 2000 we won't have the exact same arguments
raised and we -still- won't get anything.  On the other hand, if we
adopt them now we get years of field testing, and next time there
will be a lot of users with suggestions about how to improve them.
Some progress must be made incrementally -- but no progress is made
if the increment is zero.

The risks are very low. This proposal already says the optimizer
function has to be semantics-preserving, and that it might never be
called. It's hard to see how that can go wrong.

For so little cost and so much potential gain, I think it is worth any
associated risk.

∂14-Mar-89  0646	CL-Compiler-mailer 	issue COMPILER-LET-CONFUSION, version 7 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  06:46:46 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556490; Tue 14-Mar-89 09:44:20 EST
Date: Tue, 14 Mar 89 09:44 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-LET-CONFUSION, version 7
To: barmar@Think.COM
cc: cl-compiler@sail.stanford.edu
In-Reply-To: <19890314004109.1.BARMAR@OCCAM.THINK.COM>
Message-ID: <890314094413.0.KMP@BOBOLINK.SCRC.Symbolics.COM>

[X3J13 removed.]

    Date: Mon, 13 Mar 89 19:41 EST
    From: Barry Margolin <barmar@Think.COM>

	Date: Mon, 13 Mar 89 16:14:26 -0700
	From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

	      (DEFMACRO COMPILER-LET (BINDINGS &BODY FORMS &ENVIRONMENT ENV)
    ...
		(PROGV (MAPCAR #'CAR BINDINGS)
		       (MAPCAR #'CDR BINDINGS)
		  (SYSTEM::MACROEXPAND-ALL `(PROGN ,@FORMS) ENV)))
    Modulo some bugs in the code.  Shouldn't the second-to-last line be:
    (MAPCAR #'(LAMBDA (BINDING) (eval (CaDR BINDING))) BINDINGS) 
    ...?

Yes.

∂14-Mar-89  0651	CL-Compiler-mailer 	Re: issue PROCLAIM-ETC-IN-COMPILE-FILE, version 3 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  06:51:37 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556493; Tue 14-Mar-89 09:47:29 EST
Date: Tue, 14 Mar 89 09:47 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue PROCLAIM-ETC-IN-COMPILE-FILE, version 3
To: Gray@DSG.CSC.TI.COM, sandra%defun@CS.Utah.EDU
cc: CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: <2814827699-4227621@Kelvin>
Message-ID: <890314094721.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Mon, 13 Mar 89  18:34:59 CST
    From: David N Gray <Gray@DSG.csc.ti.com>
    ...

    > Cost to users:
    > 
    >   For proposal YES, users would have no way to suppress compile-time
    >   evaluation of a top-level call to PROCLAIM.  Wrapping it in an
    >   (EVAL-WHEN (EVAL LOAD)...) wouldn't work under the model of how
    >   EVAL-WHEN works in proposal EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL.

    How about (LET () (PROCLAIM ...)) ?

Actually, I often use (EVAL '...) to defer evaluation to load time.

I have to say, though, that I don't know of any reason why I would
use PROCLAIM at toplevel and not want the compiler to notice it.
I can't remember this ever coming up.

∂14-Mar-89  0702	CL-Compiler-mailer 	Re: issue MACRO-CACHING, version 2 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89  07:02:35 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 06:51:59 PST
Date: 14 Mar 89 06:51 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue MACRO-CACHING, version 2
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
 Mon, 13 Mar 89 09:47:38 -0700
To: cl-compiler@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890314-065159-22429@Xerox>

I think we would be better off just deprecating *MACROEXPAND-HOOK* or
removing the suggestions that it might be used for caching macro expansions
and just suggesting that it might be used for "debugging" purposes. Most of
the rest of this belongs in an "implementation note" or something, rather
than in the "spec" for *MACROEXPAND-HOOK*, doesn't it?

!

In fact, when I did macro caching for Xerox Common Lisp, I found that I had
to not do caching when there were any COMPILER-LETs in force, too.

The guard was:

	Don't cache if you're not in the interpreter
	(e.g., a "code-walk" or a "compiler" environment)

	Don't cache if there are any macros/functions
	lexically defined.

	Don't cache if inside a COMPILER-LET.

*Any* redefinition of any function or variable clears the cache. 

This is still a heuristic, of course, since there are legitimate ways of
changing something that a macro-expansion depends on that won't get
noticed.

∂14-Mar-89  0738	CL-Compiler-mailer 	Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE  
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 14 Mar 89  07:38:33 PST
Received: from relay2.cs.net by RELAY.CS.NET id ac25718; 14 Mar 89 10:16 EST
Received: from draper.com by RELAY.CS.NET id ae09120; 14 Mar 89 10:11 EST
Date: Tue, 14 Mar 89 08:14 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE
To: cl-compiler@SAIL.STANFORD.EDU
X-VMS-To: CL-COMPILER,SEB1525

> I don't like this name because the convention is that macros with names
> beginning with DEF... are used to define things, with the name of the
> thing being defined appearing as the first argument or as part of the
> first argument.  DEFPROCLAIM doesn't define anything.  I think this
> would also confuse users because it has the same syntax as DECLARE, but
> the two can't be used interchangeably.  It makes me wonder whether we
> should just permit top-level DECLAREs, but then _it_ would need special
> handling by the compiler since a macro definition would confuse the
> semantics of local declarations, so you don't win.

I don't understand the last sentence.  What kind of macro definition?
Can you give an example? 
 
I never understood why PROCLAIM was created in the first place, and why
it was decided ages ago that top-level DECLARE was no good.  Since DECLARE
is a special form, the compiler is free to do anything at all with it, and
we don't have to treat any functions specially at top level.  Who does
(PROCLAIM <function-call-or-variable>) anyway?

∂14-Mar-89  0938	CL-Compiler-mailer 	issue COMPILER-LET-CONFUSION, version 7 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  09:37:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556615; Tue 14-Mar-89 12:35:04 EST
Date: Tue, 14 Mar 89 12:35 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-LET-CONFUSION, version 7
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132314.AA02546@defun.utah.edu>
Message-ID: <19890314173505.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

I generally favor the COMPILER-LET-CONFUSION:REPAIR proposal, however
I have a couple of comments and questions.  Also of course I would want
to see the typo that BarMar found fixed.

What is the interaction between proposals COMPILER-LET-CONFUSION
and DEFINE-OPTIMIZER?  Neither proposal says anything about that
as far as I can see.  I believe the body of a optimizer must be
executed in the same dynamic environment as the body of a macro.

      Cost to Implementors:

	In interpreters which do not do a semantic-prepass, it is necessary
	to fully macroexpand the body. 

This is not true.  A possible implementation technique for such
interpreters, in fact the one I would use, is to save the COMPILER-LET
bindings in a slot in the interpreter's lexical environment in the form
of an alist, and to make the MACROEXPAND-1 function bind those bindings
with PROGV around its call to the macroexpander.  Using this technique
instead of fully macroexpanding the body deals with some of the
objections to the REPAIR proposal, I believe.  Also promoting this
technique in the proposal would remove the need for the discussion
section to address the side-issue of whether code analyzing programs can
or cannot be written portably (an important issue in its own right, but
not part this one).

    Current Practice:
  
     Some implementations have implemented the description in CLtL. 
     Users of those implementations (quite reasonably) can't figure how to 
     use COMPILER-LET and so don't use it much.

     Some implementations (the ones from which COMPILER-LET originally came)
     continue to use their pre-CLtL semantics. These semantics are useful, though
     incompatible with CLtL (which they largely consider to simply be in error).

Could you be more explicit about this?  I was unable to figure out what you
are talking about, even after twice reading the introductory portion of the
proposal and the writeup in CLtL.  I believe Symbolics Genera is one of those
implementations from which COMPILER-LET originally came and at the same time
implements COMPILER-LET exactly as CLtL specifies, so I must be missing some
important distinction.  I'd like to see a precise description of these two
competing semantics and I'd also like to know which, if either, of them is
compatible with the REPAIR proposal.

∂14-Mar-89  0956	CL-Compiler-mailer 	issue DEFINE-OPTIMIZER, version 5  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  09:56:35 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556621; Tue 14-Mar-89 12:54:02 EST
Date: Tue, 14 Mar 89 12:54 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DEFINE-OPTIMIZER, version 5
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132331.AA02562@defun.utah.edu>
Message-ID: <19890314175403.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

I generally like DEFINE-OPTIMIZER:NEW-FACILITY, but I would like
to suggest a couple of changes.

I'm not a fan of documentation strings, but shouldn't DEFINE-OPTIMIZER
allow them?  Was their omission accidental or intentional?

Instead of returning two values from the body, I suggest returning one
value, or NIL to decline to optimize.  If an optimizer wishes to
optimize into a form whose result is NIL, it should return (QUOTE NIL).
After all, if it wishes to optimize into a form whose result is FOO, it
has to return (QUOTE FOO), not FOO.  The two values returned by
OPTIMIZE-EXPRESSION-1 are okay, since they are compatible with the two
values returned by MACROEXPAND-1.  A reasonable alternative would be to
eliminate the two values at all levels, and also eliminate the special
casing of NIL, and simply specify that one declines to optimize by
returning the original form (compared with EQ).  This will work but is
slightly more awkward for the optimizer writer, since &WHOLE would
have to be used.  I'd accept this alternative if more people are in
favor of it, but I prefer special-casing NIL.  I'd greatly prefer either
of those alternatives over what the proposal says now.

It isn't made clear whether OPTIMIZE-EXPRESSION returns one value
or two.  It should be consistent with OPTIMIZE-EXPRESSION-1.

  Using FLET and MACROLET shadow...

I assume it was only accidental that LABELS, GENERIC-LABELS, and
GENERIC-FLET were omitted from this list.  I am unable to figure
out whether WITH-ADDED-METHODS should be included in this list
or not; I suspect not.

The similar Symbolics Genera facility allows more than one optimizer
to be defined for a given function; the optimizers are invoked in
unspecified order until one succeeds.  This feature is actually
used, however I think it is okay to leave it out.

I agree with Barrett's comments quoted in the discussion section.
I'd like to see the proposal amended the way he suggests.

∂14-Mar-89  1005	CL-Compiler-mailer 	issue WITH-COMPILATION-UNIT, version 3  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  10:05:29 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556623; Tue 14-Mar-89 13:03:02 EST
Date: Tue, 14 Mar 89 13:03 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue WITH-COMPILATION-UNIT, version 3
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903140025.AA02634@defun.utah.edu>
Message-ID: <19890314180303.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

I oppose this because I don't think it's finished, however I expect I
would support it if it were finished.  It may be that the amount of work
required to finish this is small and the proposal just needs amending.

I don't think it's acceptable to have something like this if its effect
is only defined for warnings, and its effect on compile-time
proclamations, compile-time macro definitions, compile-time defconstant
definitions, compile-time optimizer definitions, compile-time type
definitions, compile-time setf definitions, and compile-time CLOS
definitions is left unspecified.

I think lumping COMPILE and COMPILE-FILE together here reflects
confusion.  COMPILE and COMPILE-FILE have very little to do with each
other, and I think it's clear that COMPILE should not be affected in any
way by WITH-COMPILATION-UNIT.  Having COMPILE affected by
WITH-COMPILATION-UNIT is as unreasonable as having MACROEXPAND affected
by WITH-COMPILATION-UNIT, if you ask me.  I think removing COMPILE would
address Barrett's complaint in the discussion section; that is, I think
having COMPILE-FILE not override an enclosing WITH-COMPILATION-UNIT is
correct.

∂14-Mar-89  1009	CL-Compiler-mailer 	Re: issue COMPILER-LET-CONFUSION, version 7  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Mar 89  10:09:01 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA05592; Tue, 14 Mar 89 11:05:43 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA03474; Tue, 14 Mar 89 11:05:23 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903141805.AA03474@defun.utah.edu>
Date: Tue, 14 Mar 89 11:05:22 MST
Subject: Re: issue COMPILER-LET-CONFUSION, version 7
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: kmp@stony-brook.scrc.symbolics.com, cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 14 Mar 89 12:35 EST

> Date: Tue, 14 Mar 89 12:35 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
> What is the interaction between proposals COMPILER-LET-CONFUSION
> and DEFINE-OPTIMIZER?  Neither proposal says anything about that
> as far as I can see.  I believe the body of a optimizer must be
> executed in the same dynamic environment as the body of a macro.

I think you're right about this.

> A possible implementation technique for such
> interpreters, in fact the one I would use, is to save the COMPILER-LET
> bindings in a slot in the interpreter's lexical environment in the form
> of an alist, and to make the MACROEXPAND-1 function bind those bindings
> with PROGV around its call to the macroexpander.  Using this technique
> instead of fully macroexpanding the body deals with some of the
> objections to the REPAIR proposal, I believe.  Also promoting this
> technique in the proposal would remove the need for the discussion
> section to address the side-issue of whether code analyzing programs can
> or cannot be written portably (an important issue in its own right, but
> not part this one).

An earlier version of this issue actually contained a proposal
REDEFINE that suggested doing this very thing.  However, it didn't
seem like it had much support, and it had the problem that it could be
subverted by programs that call the MACRO-FUNCTION directly. 

Kent mentioned a similar implementation technique in his first
iteration on proposal REPAIR (in which it was the responsibility of
the compiler or interpreter to bind the variables before calling
MACROEXPAND-1).  I removed it partly because it would be even easier
to subvert than the earlier REDEFINE proposal, and partly because it
looked like we were going to get bogged down in a discussion of
side-effecting the variables.

>     Current Practice:
>   
>      Some implementations (the ones from which COMPILER-LET originally came)
>      continue to use their pre-CLtL semantics. These semantics are useful, though
>      incompatible with CLtL (which they largely consider to simply be in error).
> 
> Could you be more explicit about this?

Kent, since this is your language, can you do something about this?  This
is the second complaint we've gotten about this particular statement.
I must admit that I am also not sure how the pre-CLtL semantics differ
from the CLtL semantics.

-Sandra
-------

∂14-Mar-89  1053	CL-Compiler-mailer 	Re: issue WITH-COMPILATION-UNIT, version 3   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Mar 89  10:53:34 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA07757; Tue, 14 Mar 89 11:50:22 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA03524; Tue, 14 Mar 89 11:50:01 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903141850.AA03524@defun.utah.edu>
Date: Tue, 14 Mar 89 11:49:59 MST
Subject: Re: issue WITH-COMPILATION-UNIT, version 3
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: kmp@stony-brook.scrc.symbolics.com, cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 14 Mar 89 13:03 EST

> Date: Tue, 14 Mar 89 13:03 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
> I don't think it's acceptable to have something like this if its effect
> is only defined for warnings, and its effect on compile-time
> proclamations, compile-time macro definitions, compile-time defconstant
> definitions, compile-time optimizer definitions, compile-time type
> definitions, compile-time setf definitions, and compile-time CLOS
> definitions is left unspecified.

This point has been raised before.  Some of us have suggested that the
purpose of WITH-COMPILATION-UNIT is really to allow several files to
be treated as a unit sharing a single compilation environment, which
would include the information about undefined functions as well as all
the things you list above.  However, the whole notion of compilation
environments is still pretty vague right now and I don't really blame
Kent for wanting to avoid the issue.  I guess the real questions are,
can we firm up something on compilation environments in time to make
it into the standard; and if not, should we delay adding this feature
or define only the restricted form that Kent proposes? 

> I think lumping COMPILE and COMPILE-FILE together here reflects
> confusion.  COMPILE and COMPILE-FILE have very little to do with each
> other, and I think it's clear that COMPILE should not be affected in any
> way by WITH-COMPILATION-UNIT.

I agree with this.  In particular, the extended notion of what this
form is for is sharing of what we have been calling a "remote"
environment across multiple calls to COMPILE-FILE.  COMPILE always
uses a "local" environment and shouldn't be affected.

-Sandra
-------

∂14-Mar-89  1137	CL-Compiler-mailer 	issue DEFINE-OPTIMIZER, version 5  
Received: from goldhill.com ([128.168.1.211]) by SAIL.Stanford.EDU with TCP; 14 Mar 89  11:37:09 PST
Received: by goldhill.com; Tue, 14 Mar 89 14:09:51 EST
Date: Tue, 14 Mar 89 14:09:51 EST
From: rpk@goldhill.com (Robert Krajewski)
Message-Id: <8903141909.AA09480@goldhill.com>
To: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 13 Mar 89 16:31:17 -0700 <8903132331.AA02562@defun.utah.edu>
Subject: issue DEFINE-OPTIMIZER, version 5

I think a portable optimizer definer is a fine idea.  It's especially
useful for authors of Common Lisp-embedded subsystems that offer safe
access to their data structures in a development environment, but who
also wish to produce fast code for delivery.  In such cases, an
optimizer should only run when unsafe code is desired.

Assuming that optimizers are invoked no matter what the compiletime
parameters (except maybe a switch to turn optimizers off), it would be
useful if the optimizer could make inquiries about OPTIMIZE SPEED,
SPACE, SAFETY, and so on.  For example, Gold Hill Windows could turn a
call to WINDOW-X (a function which checks to see if its argument is a
window) into %WINDOW-X, a DEFSTRUCT-generated accessor which is
subject to further optimization.  However, such an optimization is
warranted only if the unsafe code is desired.  The optimization should
obtain only after an compile-time environment query is made.

I suppose the issue could be sidestepped if the subsystem advertises
compile-time parameters which are used by the optimizers.

(Another useful query is ``How many values are expected from this call ?''
but we'll leave all that for future standardization.)

Another issue: The documentation for the optimization for the facility
should make it clear that optimized form must preserve the Common
Lisp order-of-evaluation semantics of the form.  In other words,
optimizers like

(define-optimizer foo (x y) `(better-foo ,y ,x))

are bad.

∂14-Mar-89  1217	CL-Compiler-mailer 	**DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  12:17:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556715; Tue 14-Mar-89 15:09:52 EST
Date: Tue, 14 Mar 89 15:09 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132355.AA02585@defun.utah.edu>
Message-ID: <19890314200952.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

I strongly favor MACRO-ENVIRONMENT-EXTENT:DYNAMIC over any of the other four.

∂14-Mar-89  1218	CL-Compiler-mailer 	Re: issue COMPILER-LET-CONFUSION, version 7  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  12:18:00 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556712; Tue 14-Mar-89 15:06:51 EST
Date: Tue, 14 Mar 89 15:06 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue COMPILER-LET-CONFUSION, version 7
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: kmp@STONY-BROOK.SCRC.Symbolics.COM, cl-compiler@sail.stanford.edu
In-Reply-To: <8903141805.AA03474@defun.utah.edu>
Message-ID: <19890314200643.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 14 Mar 89 11:05:22 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    > Date: Tue, 14 Mar 89 12:35 EST
    > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    > A possible implementation technique for such
    > interpreters, in fact the one I would use, is to save the COMPILER-LET
    > bindings in a slot in the interpreter's lexical environment in the form
    > of an alist, and to make the MACROEXPAND-1 function bind those bindings
    > with PROGV around its call to the macroexpander.  Using this technique
    > instead of fully macroexpanding the body deals with some of the
    > objections to the REPAIR proposal, I believe.  Also promoting this
    > technique in the proposal would remove the need for the discussion
    > section to address the side-issue of whether code analyzing programs can
    > or cannot be written portably (an important issue in its own right, but
    > not part this one).

    An earlier version of this issue actually contained a proposal
    REDEFINE that suggested doing this very thing.  However, it didn't
    seem like it had much support, and it had the problem that it could be
    subverted by programs that call the MACRO-FUNCTION directly. 

I wouldn't take that problem too seriously, for two reasons.  First,
the CLtL writeup on MACRO-FUNCTION says you should call MACROEXPAND
rather than calling the function directly.  Second, if you think about
where the second argument to the function comes from, it's unlikely
that (funcall (macro-function ...) ...) could be used anywhere but
inside a macro expander, where the special variables are bound,
especially if MACRO-ENVIRONMENT-EXTENT:DYNAMIC passes, except when
the environment is explicitly null, in which case there cannot be
any COMPILER-LET anyway.

    Kent mentioned a similar implementation technique in his first
    iteration on proposal REPAIR (in which it was the responsibility of
    the compiler or interpreter to bind the variables before calling
    MACROEXPAND-1).  I removed it partly because it would be even easier
    to subvert than the earlier REDEFINE proposal, and partly because it
    looked like we were going to get bogged down in a discussion of
    side-effecting the variables.

I hadn't thought of side-effecting the variables.  It's important for
the language specification to say something about that.  I can't justify
forbidding it (the only reason for forbidding it I can think of is
efficiency, and that's minor here), so I think it should be explicitly
allowed.  This means that places that PROGV will have to copy the values
back.  Alternatively it could be explicitly forbidden; I'd rather see
that than see nothing.  I believe I have seen some programs that used
COMPILER-LET to bind a variable in which subsidiary macros collected
information, so side-effects are used, however those programs may have
been unportable anyway.

Note that this issue of side-effecting the variables is completely
orthogonal to everything else.  It's not tied up with this question
of implementation technique.

∂14-Mar-89  1232	CL-Compiler-mailer 	**DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE (version 4)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  12:32:34 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556743; Tue 14-Mar-89 15:29:24 EST
Date: Tue, 14 Mar 89 15:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE (version 4)
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903140008.AA02608@defun.utah.edu>
Message-ID: <19890314202917.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

I favor PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO, primarily because this
allows programs to be clear about the scope of the proclamation:
whether they are making a proclamation for purposes of compile-file or
to affect the running Lisp.  If you call the macro at top-level, you're
clearly doing it for compilation.  If you call the function at any level,
you're clearly doing it with global scope.

In PROCLAIM-ETC-IN-COMPILE-FILE:NO there is no way to say whether a
PROCLAIM inside an (EVAL-WHEN (COMPILE...) ...)  is intended to persist
after the compilation is over, which is just about the only reason
why I prefer PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO over :NO.

I'd like PROCLAIM-ETC-IN-COMPILE-FILE:NO better if it also proposed
to add an optional argument to PROCLAIM that expressed the intended
scope of the proclamation.  I'd suggest NIL (the default) for the
global scope and the symbol COMPILE-FILE to limit it to the compilation.
Given this, users who liked DEFPROCLAIM could trivially write it
themselves.

The only thing PROCLAIM-ETC-IN-COMPILE-FILE:YES has going for it is
that it's the status quo, in a subset of implementations.  I don't like it.

I agree with Barrett's comments quoted in the discussion section.

The proposal says:
  As with other defining macros, it is 
  unspecified whether or not the compile-time side-effects of a 
  DEFPROCLAIM persist after the file has been compiled.
but never says this about PROCLAIM.  In all three proposals,
this needs to be said about PROCLAIM.  But as you can see from my
comments above, I would rather that we did not leave this unspecified.

The proposal says:
  Current Practice:
  
    The Symbolics compiler has special top-level handling for PROCLAIM,
    although the details are not clear.

I'm not sure what you thought was not clear.  Symbolics Genera does the
same thing that the current practice section says IIM does.  In addition
(and I couldn't tell whether IIM does this too or not), the scope of the
PROCLAIM is only the compilation-unit if the PROCLAIM appears at
top-level, but is global and persists forever if the PROCLAIM appears in
an (EVAL-WHEN (COMPILE...) ...).  We might change that.

∂14-Mar-89  1310	CL-Compiler-mailer 	issue DEFINING-MACROS-NON-TOP-LEVEL, version 8    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  13:09:32 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556774; Tue 14-Mar-89 15:58:28 EST
Date: Tue, 14 Mar 89 15:58 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132333.AA02565@defun.utah.edu>
Message-ID: <19890314205826.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

I favor DEFINING-MACROS-NON-TOP-LEVEL:ALLOW except for one thing.
This sentence appears in the proposal but does not appear to have
any relation to the main issue:

  The order in which
  non-top-level subforms of a top-level form are processed by the
  compiler is explicitly left unspecified.

I can't figure out what this means and the example in the rationale
section that purports to explain this does not shed any light, since in
the example there is no change of order of evaluation.  I wouldn't be
surprised if I opposed this if I did understand what it means.  Can we
deal with this as a separate issue?  In fact the whole point (3) of the
proposal should be moved.  That issue should also discuss whether there
are any constraints on whether one top-level form is processed before
the next top-level form is read, in case the one form changes package,
changes readtable, defines a read-syntax, or defines a structure used in
#S read-syntax.

Also, when you say:

  Clarify
  that all defining macros which create functional objects (including
  DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and the complex form of
  DEFSETF, as well as DEFUN) must ensure that those functions are
  defined in the lexical environment in which the defining form is
  evaluated.

I strongly believe that MACROLET must be consistent with this, which
would be a change.  Has that been dealt with as a separate issue?  If
not, it should either be added to this issue or brought up as a
separate issue, with the interdependency noted in both writeups to
minimize the chance of an inconsistent vote.

∂14-Mar-89  1326	CL-Compiler-mailer 	issue COMPILE-FILE-SYMBOL-HANDLING, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  13:25:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556792; Tue 14-Mar-89 16:23:12 EST
Date: Tue, 14 Mar 89 16:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-FILE-SYMBOL-HANDLING, version 2
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132312.AA02542@defun.utah.edu>
Message-ID: <19890314212313.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

I favor COMPILE-FILE-SYMBOL-HANDLING:CURRENT-PACKAGE.
COMPILE-FILE-SYMBOL-HANDLING:HOME-PACKAGE seems superficially simpler,
but my experience when we tried it at MIT indicates that it does not
work very well.  Too often a symbol that had been moved from one package
to another, or had its export status changed, would be silently moved
back to its original package by loading a file.  I sort-of agree with
JonL's comment at the end of the discussion section: if we can't agree
on one solution to his issue, I think that in practice there would be
little harm to portable programs if we left it unspecified.  The issue
really affects development environments much more than it affects the
language in which portable programs are written, although it does have
some effect on that as well.

∂14-Mar-89  1340	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  13:40:33 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 556802; 14 Mar 89 16:37:50 EST
Date: Tue, 14 Mar 89 16:37 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132250.AA02499@defun.utah.edu>
Message-ID: <19890314213750.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

All the things I didn't like in version 3 have been fixed.
I would favor COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY if one change
were made.  The proposal says:

  Except where some other behavior is explicitly stated, when
  the compiletime and runtime definitions are different, it is
  unspecified which will prevail within the compiled code.

This means that either the compiletime or the runtime definition
will prevail, but nothing else can happen.  It must also be
permissible to signal an error complaining about the discrepancy.

∂14-Mar-89  1351	CL-Compiler-mailer 	issue SAFE-CODE, version 1    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  13:51:31 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556829; Tue 14-Mar-89 16:49:05 EST
Date: Tue, 14 Mar 89 16:49 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue SAFE-CODE, version 1
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131726.AA02193@defun.utah.edu>
Message-ID: <19890314214907.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

I agree with SAFE-CODE:SAFETY-3.

I disagree with the usage (in the examples) of "unsafe code" to mean
"all code where the OPTIMIZE quality of SAFETY is not 3."  I believe
that "unsafe code" should mean code that is actually unsafe, not code
that an implementation is permitted to treat as unsafe if it wishes.  I
believe there should be no portable way to write unsafe code.  This is
only a matter of wording.  If we need a shorter term for "all code where
the OPTIMIZE quality of SAFETY is not 3" I would suggest "potentially
unsafe code."

∂14-Mar-89  1357	CL-Compiler-mailer 	issue COMPILER-VERBOSITY, version 6
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  13:56:56 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556842; Tue 14-Mar-89 16:54:22 EST
Date: Tue, 14 Mar 89 16:54 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-VERBOSITY, version 6
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131546.AA02078@defun.utah.edu>
Message-ID: <19890314215423.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

I like COMPILER-VERBOSITY:LIKE-LOAD.  This fixes all of the
problems I had with the version 5 proposal.

Like BarMar, I question the need for either of :PRINT and :VERBOSE in
either of LOAD and COMPILE-FILE.  But that might be my own cultural
bias, due to the type of systems I use, where it's easy to see what's
going on inside.  If other people claim they need these, I'll believe
them.

∂14-Mar-89  1414	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Mar 89  14:14:00 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA15894; Tue, 14 Mar 89 15:11:44 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA03724; Tue, 14 Mar 89 15:11:21 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903142211.AA03724@defun.utah.edu>
Date: Tue, 14 Mar 89 15:11:20 MST
Subject: Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 14 Mar 89 15:58 EST

> Date: Tue, 14 Mar 89 15:58 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
>   The order in which
>   non-top-level subforms of a top-level form are processed by the
>   compiler is explicitly left unspecified.
> 
> I can't figure out what this means and the example in the rationale
> section that purports to explain this does not shed any light, since in
> the example there is no change of order of evaluation.

I don't know how to explain this any more clearly -- what's in the
current version of the proposal is about the third attempt I've made.
Well, here goes a fourth attempt.

Suppose I have a top-level DEFMACRO at the top of the file.  Item (3)
guarantees that this DEFMACRO will be processed before any top-level
forms that appear textually after it.  That means I can refer to the
DEFMACRO in those subsequent forms and guarantee that the compiler has
already "seen" the macro definition.  The same rule applies to any
other defining macros that do compile-time magic at top-level.

Now suppose expanding this macro has some side-effects, such as
SETQ'ing a special variable.  If I have two calls to the macro at
top-level, I can reliably depend on the side-effects happening in the
same order that the calls appear textually.  But, the other thing that
item (3) says is that if the two macro calls are embedded at
non-top-level, I can't rely on the order in which the compiler will
expand them.

The example shown in the rationale explains why.  Both code fragments
are semantically identical -- as you observe, there is no change in
the order of evaluation.  However, the *textual* order of subforms has
changed.  If we wanted to guarantee that compiler processing of 
*always* happens in the same order that they appear textually,
implementations would be prohibited from doing this kind of
transformation.  That's why item (3) makes an exception for embedded
non-top-level forms.

I agree this could be made into a separate issue and be expanded to
include a statement that processing of top-level forms is interleaved
with reading.  It had more to do with this issue when the definition
of top-level appeared here.

>   Clarify
>   that all defining macros which create functional objects (including
>   DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and the complex form of
>   DEFSETF, as well as DEFUN) must ensure that those functions are
>   defined in the lexical environment in which the defining form is
>   evaluated.
> 
> I strongly believe that MACROLET must be consistent with this, which
> would be a change.  Has that been dealt with as a separate issue?  If
> not, it should either be added to this issue or brought up as a
> separate issue, with the interdependency noted in both writeups to
> minimize the chance of an inconsistent vote.

The problem with MACROLET is that it defines the macro functions at
compile time even if it appears at non-top-level, while all the other
ones listed only do so at top-level.  Non-top-level environments are
not guaranteed to be "complete" at compile time; bindings of functions
and variables don't exist yet.  I suppose we could say that trying to
refer to those functions and variables in the macro functions is an
error of some variety.

In any case, this would be a somewhat more incompatible change than
what the proposal currently says.  Lucid, for example, evaluates
DEFMACRO macro functions in the lexical environment that the DEFMACRO
appears (in spite of what CLtL says), but always evaluates MACROLET
macro functions in a null lexical environment.

-Sandra
-------

∂14-Mar-89  1432	CL-Compiler-mailer 	Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 2 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Mar 89  14:32:15 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA16583; Tue, 14 Mar 89 15:29:56 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA03751; Tue, 14 Mar 89 15:29:51 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903142229.AA03751@defun.utah.edu>
Date: Tue, 14 Mar 89 15:29:49 MST
Subject: Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 2
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 14 Mar 89 16:23 EST

We've gotten two contrary reports from implementors who have tried it
both ways and come up with different conclusions (you and the TI
people), and a third (Leigh Stoller here at Utah) who's switched from
HOME-PACKAGE to CURRENT-PACKAGE and who now wants to switch back to
HOME-PACKAGE because it's less complicated.  The only conclusion I can
draw is that neither behavior has any great advantages over the other
in practice.

I believe we really do need to say something about how the loader
reconstructs symbols so that it is at least clear that the symbol name
and its package are the only "components" involved in the process (and
that things like the property list are not preserved).  I suppose we
could come up with a much wimpier UNSPECIFIED proposal that says that
if *any* changes at all to the package hierarchy (*package*, which
symbols are imported or exported from a package, its use list, etc.)
are made between compile and load time, it's unspecified where the
loader will put the symbols.

-Sandra
-------

∂14-Mar-89  1438	CL-Compiler-mailer 	issue COMPILER-DIAGNOSTICS, version 9   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  14:38:21 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556909; Tue 14-Mar-89 17:35:56 EST
Date: Tue, 14 Mar 89 17:35 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-DIAGNOSTICS, version 9
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131545.AA02075@defun.utah.edu>
Message-ID: <19890314223550.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

I favor COMPILER-DIAGNOSTICS:USE-HANDLER, but there are two
things that I think need to be changed:

  Conditions of type WARNING may be signalled by the compiler in 
  situations where ... the compiler can determine 
  that a situation that "is an error" would result at runtime.

We don't use the term "is an error" any more, do we?  In the old
CLtL terms, I think both "is an error" and "signals an error"
situations would justify a warning.  I think this part should
be updated to the new error terminology and also should state that
all error situations justify warnings.  Of course explicit calls
to the function ERROR don't justify warnings; I don't know whether
the proposal can be phrased in such a way as to make that clear,
or whether it will have to be left to common sense.

    (3) Require COMPILE and COMPILE-FILE to handle the ABORT restart by
    aborting the smallest feasible part of the compilation.

I think this is wrong.  The only documentation of the ABORT restart
that I could find says

  The purpose of the ABORT restart is generally to allow return to the
  innermost ``command level.''

I agree with this, and I believe it means that it is wrong for any
function other than one that establishes a read-eval-print loop or
a command-level to establish an ABORT restart.  It would be useful
to have some restart that aborts a portion of the compilation, but
it should be given some other name.

∂14-Mar-89  1448	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Mar 89  14:48:18 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA16862; Tue, 14 Mar 89 15:46:09 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA03773; Tue, 14 Mar 89 15:46:01 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903142246.AA03773@defun.utah.edu>
Date: Tue, 14 Mar 89 15:46:00 MST
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 14 Mar 89 16:37 EST

> Date: Tue, 14 Mar 89 16:37 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
> This means that either the compiletime or the runtime definition
> will prevail, but nothing else can happen.  It must also be
> permissible to signal an error complaining about the discrepancy.

The very first version of this proposal said "it is an error" here,
back before we had started talking seriously about adopting new error
terminology.  There was some discussion about it after that, the
consensus of which seemed to be that the right behavior should really
be "one or the other".  

I personally don't see anything wrong with allowing (but not
requiring) an error to be signalled, now that we seem to have agreed
that isn't inconsistent with the term "unspecified".

-Sandra
-------

∂14-Mar-89  1508	CL-Compiler-mailer 	Re: issue COMPILER-DIAGNOSTICS, version 9    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Mar 89  15:08:20 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA17542; Tue, 14 Mar 89 16:05:33 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA03799; Tue, 14 Mar 89 16:05:31 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903142305.AA03799@defun.utah.edu>
Date: Tue, 14 Mar 89 16:05:30 MST
Subject: Re: issue COMPILER-DIAGNOSTICS, version 9
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: kmp@stony-brook.scrc.symbolics.com, cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 14 Mar 89 17:35 EST

> Date: Tue, 14 Mar 89 17:35 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
> We don't use the term "is an error" any more, do we?  In the old
> CLtL terms, I think both "is an error" and "signals an error"
> situations would justify a warning.  I think this part should
> be updated to the new error terminology and also should state that
> all error situations justify warnings.  Of course explicit calls
> to the function ERROR don't justify warnings; I don't know whether
> the proposal can be phrased in such a way as to make that clear,
> or whether it will have to be left to common sense.

I had similar thoughts as I was looking this over before sending it
out, but I couldn't think of a way to state this that would make
sense.  I felt sure that if I just changed "is an error" to "is
undefined or where an error would be signalled", somebody would be
sure to complain about it being wrong for explicit calls to ERROR.
Actually, I was hoping that if I left it alone, somebody else would
propose some alternate wording.  :-)

>     (3) Require COMPILE and COMPILE-FILE to handle the ABORT restart by
>     aborting the smallest feasible part of the compilation.
> 
> I think this is wrong.

This was originally a suggestion from Kent Pitman, who probably knows
better than anybody what the ABORT restart was intended to be used
for.  You'll have to take it up with him, because I don't feel
qualified to argue about it one way or the other. 

-Sandra
-------

∂14-Mar-89  1544	CL-Compiler-mailer 	**DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)    
Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  15:44:06 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 438041; Tue 14-Mar-89 18:42:58 EST
Date: Tue, 14 Mar 89 18:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903140019.AA02631@defun.utah.edu>
Message-ID: <19890314234118.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

This looks good so far.  A few comments that might help you
along with the draft:

VARIABLE-KIND should return the same second value that FUNCTION-KIND
returns.

It's a good idea to avoid the ambiguous word "may" and say "might",
"must", or "is permitted to".

I would assume that VARIABLE-TYPE is not required to return the
exact declared type specifier, but could return another type
specifier that is equivalent, or possibly another type specifier
that is a supertype.  An implementation that canonicalizes type
declarations would do this.  For example, if A was declared
(INTEGER 0 4999), VARIABLE-TYPE might return that list, another
list that was EQUAL to it but not EQ, the list (INTEGER (-1) (5000)),
the symbol FIXNUM, or perhaps something else.  Similarly OR's and
AND's might be reduced to simpler type specifiers in an implementation
dependent way.  If, on the other hand, VARIABLE-TYPE is not permitted
to do this, but must return the exact type specifier used in the
declaration, that would be okay, but should be stated explicitly.
Similar comments apply to FUNCTION-FTYPE of course.

I assume AUGMENT-ENVIRONMENT is permitted to share structure with
its env argument, although the proposal says "a copy of ENV".

The :MACRO argument to AUGMENT-ENVIRONMENT shouldn't look like the CADR
of a MACROLET special form, instead it should be a list of lists (name
function).  That is, the expander functions should be supplied in the
form of functions rather than in the form of the source text used by
MACROLET.  Your rationale argues against this but I strongly believe
that the rationale is wrong.  I wouldn't mind seeing the parsing portion
of MACROLET made available as a separate function.

No way is provided to retrieve declarations other than SPECIAL, TYPE,
FTYPE, and LEXICAL (if PROCLAIM-LEXICAL passes).  I think all
declarations should be retrievable, but OPTIMIZE declarations seem
particularly useful to retrieve in macros or optimizers that expand into
different code depending on the safety level or the speed/space
tradeoff.  The irregular structure of declarations makes retrieving
them a bit complex, but here's my suggestion:

  DECLARATION decl-type name &optional env     [Function]

  decl-type is a symbol.  The interpretation of name depends
  on decl-type.  If a declaration of that type and name is
  in force in the specified environment, it is returned, otherwise
  NIL is returned.  The following decl-types are specified,
  additional implementation-dependent types could be added:

    INLINE function-name => T or NIL
    NOTINLINE function-name => T or NIL
    IGNORE variable-name => T or NIL
    OPTIMIZE quality => integer
    DECLARATION decl-type => T or NIL

The possible interpreter implementation of COMPILER-LET I mentioned
in another message earlier today would seem to require another
keyword argument to AUGMENT-ENVIRONMENT.  Does this mean that we
have to dictate some particular interpreter implementation of
COMPILER-LET?  I'm unsure.

Symbolics Genera includes an undocumented internal macro, used
quite a bit in the implementation of the interpreter and code
analyzers, that could have been called WITH-AUGMENTED-ENVIRONMENT,
taking keywords like AUGMENT-ENVIRONMENT and also body forms,
and producing an environment with dynamic extent bound to a
variable within the body forms.  Would it be useful to have this
too, or instead of AUGMENT-ENVIRONMENT?  I'm unsure.

On SYNTACTIC-ENVIRONMENT-ACCESS:MEDIUM, my feeling today is that
this should be left out for now, even though I think we will want
something like it later, at the same time that CLOS metaobjects
go in.

Ditto for SYNTACTIC-ENVIRONMENT-ACCESS:LARGE.

∂14-Mar-89  1629	CL-Compiler-mailer 	issue CONSTANT-COMPILABLE-TYPES, version 8   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  16:29:32 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557038; Tue 14-Mar-89 19:27:03 EST
Date: Tue, 14 Mar 89 19:27 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CONSTANT-COMPILABLE-TYPES, version 8
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131612.AA02083@defun.utah.edu>
Message-ID: <19890315002703.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

I apologize in advance for the length of this message.

This is good except for a few typos and the controversial business about
functions.  I'd really like to see another round of editing to clean up
these problems before we're asked to vote on this.

I suggest moving everything having to do with functions to a
separate proposal.  What's currently in the body of the proposal for
functions does not make any sense to me.  I basically agree with the
comments from both Loosemore and Gabriel about this quoted in the
discussion section.  However, we need to be careful when we discuss this
to distinguish between a function as a constant in compiled code, and a
form whose result is a function appearing in compiled code.  The former
is `(quote ,#'(lambda ...)), the latter is `#'(lambda ...).  The meaning
of the latter is clear, of course, and a useful question would be
whether it can fully satisfy the need for functions in compiled code and
eliminate any demand for the former.

I've said this before, but I still think the proposal would be
easier to understand if it explicitly dealt separately with
  (1) relation of objects in the input of COMPILE-FILE to corresponding
  objects in the result of LOAD of the output of COMPILE-FILE.
  (2) relation of two objects in the output of a single COMPILE-FILE.
  (3) relation of two objects in the output of two different COMPILE-FILEs.
instead of smushing these together in a fuzzy way.  Look at the discussion
of uninterned symbols, for example: I found it incomprehensible.

Typos:

  For any object that
  appears in a constant, but is not supported by the language as part of
  a constant, the behavior of the compiler is unspecified; either the
  the compiler and/or loader will handle that constant (in an
  implementation-dependent manner) or the compiler will detect the
  situation and signal an error.

This says that the behavior of the compiler is unspecified and then
proceeds to specify it!

  Because hash keys can be aggregate objects and because we treat hash
  tables as unordered sets of <key, value> pairs, similarity of hash
  tables is more complex.  See under "Hash Tables", below, for the
  definition.

I have no idea how this paragraph got into the middle of the discussion
of uninterned symbols.

  References to packages are permitted in any constant.  

This sentence is redundant, or else it implies that references to some
other types are permitted in some constants but not in other constants,
which I don't think you intended.

  At load time, the package becomes the same as returned by

I don't know what it means for a package to "become".  I think
this is just fractured syntax, though.  See again my suggestion
for distinguishing the three types of similarity, which I think
indicates how to rewrite this sentence to be clear.

Under hash table:
  The table's test is unchanged also.

Unchanged from what?  I think what this was supposed to say was
that the table's test is a "basic attribute."

   Consider a hash table as an unordered set of key and
   value pairs.  Two hash tables are similar as constants
   exactly if there is a one-to-one correspondence between
   the key and value pairs of each and a one-to-one
   correspondence between the uninterned symbols of each
   such that the two keys of each corresponding pair are
   similar as constants and the two values are also similar
   as constants.  The correspondence of uninterned symbols
   must be consistent with the correspondence defined for
   the entire set of constants in the file.

This paragraph is totally garbled.  If you took out the
stuff about uninterned symbols it might make sense.

Structure, Standard-object
             <<There is a cl-cleanup issue, LOAD-OBJECTS, pending
             which proposes a mechanism for dealing with objects.>>
             For structure instances with no method defined at compile
             time for MAKE-LOAD-FORM, the slot values and the name of
             structure type (a symbol reference) are recorded by the
             compiler and reconstructed by the loader.

The text not enclosed in french quotation marks directly contradicts
the LOAD-OBJECTS proposal.  It should be removed so we don't have two
proposals trying to talk about the same thing.

This sentence in the discussion section:

  The full extension of the concept of coalescing of constants is to say
  that they can be coalesced exactly when they are similar as constants.

seems to be in the wrong document, since this issue is not about
coalescing of constants and does not otherwise mention it, except
incidentally in connection with a bug in Coral Lisp.

∂14-Mar-89  1636	CL-Compiler-mailer 	issue CONSTANT-COMPILABLE-TYPES, version 8   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  16:36:44 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557048; Tue 14-Mar-89 19:34:07 EST
Date: Tue, 14 Mar 89 19:34 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CONSTANT-COMPILABLE-TYPES, version 8
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131612.AA02083@defun.utah.edu>
Supersedes: <19890315002703.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: Fix some typos in the definitions of the three concepts that I claim
          should not be smushed together.  Cris Perdue pointed out these typos
          earlier, but I forgot to fix them before sending the first copy of this
          message.
Message-ID: <19890315003408.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

I apologize in advance for the length of this message.

This is good except for a few typos and the controversial business about
functions.  I'd really like to see another round of editing to clean up
these problems before we're asked to vote on this.

I suggest moving everything having to do with functions to a
separate proposal.  What's currently in the body of the proposal for
functions does not make any sense to me.  I basically agree with the
comments from both Loosemore and Gabriel about this quoted in the
discussion section.  However, we need to be careful when we discuss this
to distinguish between a function as a constant in compiled code, and a
form whose result is a function appearing in compiled code.  The former
is `(quote ,#'(lambda ...)), the latter is `#'(lambda ...).  The meaning
of the latter is clear, of course, and a useful question would be
whether it can fully satisfy the need for functions in compiled code and
eliminate any demand for the former.

I've said this before, but I still think the proposal would be
easier to understand if it explicitly dealt separately with
  (1) relation of objects in the input of COMPILE-FILE to corresponding
  objects in the result of LOAD of the output of COMPILE-FILE.
  (2) relation of two objects in the result of LOAD of the output
  of a single COMPILE-FILE.
  (3) relation of two objects in the result of LOAD of the output
  of two different COMPILE-FILEs.
instead of smushing these together in a fuzzy way.  Look at the discussion
of uninterned symbols, for example: I found it incomprehensible.

Typos:

  For any object that
  appears in a constant, but is not supported by the language as part of
  a constant, the behavior of the compiler is unspecified; either the
  the compiler and/or loader will handle that constant (in an
  implementation-dependent manner) or the compiler will detect the
  situation and signal an error.

This says that the behavior of the compiler is unspecified and then
proceeds to specify it!

  Because hash keys can be aggregate objects and because we treat hash
  tables as unordered sets of <key, value> pairs, similarity of hash
  tables is more complex.  See under "Hash Tables", below, for the
  definition.

I have no idea how this paragraph got into the middle of the discussion
of uninterned symbols.

  References to packages are permitted in any constant.  

This sentence is redundant, or else it implies that references to some
other types are permitted in some constants but not in other constants,
which I don't think you intended.

  At load time, the package becomes the same as returned by

I don't know what it means for a package to "become".  I think
this is just fractured syntax, though.  See again my suggestion
for distinguishing the three types of similarity, which I think
indicates how to rewrite this sentence to be clear.

Under hash table:
  The table's test is unchanged also.

Unchanged from what?  I think what this was supposed to say was
that the table's test is a "basic attribute."

   Consider a hash table as an unordered set of key and
   value pairs.  Two hash tables are similar as constants
   exactly if there is a one-to-one correspondence between
   the key and value pairs of each and a one-to-one
   correspondence between the uninterned symbols of each
   such that the two keys of each corresponding pair are
   similar as constants and the two values are also similar
   as constants.  The correspondence of uninterned symbols
   must be consistent with the correspondence defined for
   the entire set of constants in the file.

This paragraph is totally garbled.  If you took out the
stuff about uninterned symbols it might make sense.

Structure, Standard-object
             <<There is a cl-cleanup issue, LOAD-OBJECTS, pending
             which proposes a mechanism for dealing with objects.>>
             For structure instances with no method defined at compile
             time for MAKE-LOAD-FORM, the slot values and the name of
             structure type (a symbol reference) are recorded by the
             compiler and reconstructed by the loader.

The text not enclosed in french quotation marks directly contradicts
the LOAD-OBJECTS proposal.  It should be removed so we don't have two
proposals trying to talk about the same thing.

This sentence in the discussion section:

  The full extension of the concept of coalescing of constants is to say
  that they can be coalesced exactly when they are similar as constants.

seems to be in the wrong document, since this issue is not about
coalescing of constants and does not otherwise mention it, except
incidentally in connection with a bug in Coral Lisp.

∂14-Mar-89  1651	CL-Compiler-mailer 	issue QUOTE-SEMANTICS, version 2   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  16:51:17 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557056; Tue 14-Mar-89 19:48:51 EST
Date: Tue, 14 Mar 89 19:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue QUOTE-SEMANTICS, version 2
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131721.AA02184@defun.utah.edu>
Message-ID: <19890315004852.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

I favor QUOTE-SEMANTICS:NO-COPYING for two reasons: 
(1) it's clearly more aesthetic.
(2) I can't support either of the other two proposals because they use
the words "copying" and "coalescing" without defining their meaning.

My position could be changed to
QUOTE-SEMANTICS:COPYING-ALLOWED-BUT-NO-CONSTRAINTS by adding definitions
for those two words and by a strong argument that the implementation
cost of QUOTE-SEMANTICS:NO-COPYING is too high, since I believe to some
extent JonL's argument (quoted in the discussion section) that EQL of
(some types of) constants does not matter.

I can't imagine any argument that would convince me to
support QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE.  I believe Kent's
arguments against it (quoted in the discussion section).

∂14-Mar-89  1700	CL-Compiler-mailer 	issue MACRO-CACHING, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  17:00:30 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557059; Tue 14-Mar-89 19:57:55 EST
Date: Tue, 14 Mar 89 19:57 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue MACRO-CACHING, version 2
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131647.AA02151@defun.utah.edu>
Message-ID: <19890315005756.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

I support MACRO-CACHING:DISALLOW.  I'd like to point out that the
"correct" way to do macro caching is not mentioned anywhere in this
writeup.  Perhaps that was justified because there is no portable way to
do it (an implementation can do it, but a user cannot), however I think
omitting it leaves a false impression.

The "correct" way to do macro caching is via a table inside the lexical
environment structure, which has very different properties from a table
keyed by the lexical environment structure, mentioned in the writeup.

I think a shorter writeup might be better.  It could simply say that
there is no correct portable way to use *MACROEXPANSION-HOOK* to cache
macro expansions, and that there is no requirement that an implementation
call the macro expansion function more than once for a given form
and lexical environment.  This prohibits the incorrect user code discussed
at some length in the existing writeup, leaves implementations license
to do macro caching correctly, and avoids a lot of unnecessary detail.

∂14-Mar-89  1704	CL-Compiler-mailer 	issue LOAD-TIME-EVAL, version 11   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  17:04:49 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 557069; 14 Mar 89 20:02:04 EST
Date: Tue, 14 Mar 89 20:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue LOAD-TIME-EVAL, version 11
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131631.AA02140@defun.utah.edu>
Message-ID: <19890315010205.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

I like LOAD-TIME-EVAL:R**3-NEW-SPECIAL-FORM.

∂14-Mar-89  1722	CL-Compiler-mailer 	issue CONSTANT-CIRCULAR-COMPILATION, version 7    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  17:21:59 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557096; Tue 14-Mar-89 20:15:39 EST
Date: Tue, 14 Mar 89 20:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CONSTANT-CIRCULAR-COMPILATION, version 7
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131619.AA02090@defun.utah.edu>
Message-ID: <19890315011539.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

I favor CONSTANT-CIRCULAR-COMPILATION:YES except that all references to
EQ should be changed to EQL.  There is no reason to require
implementations to be careful about EQ of numbers and characters.

∂14-Mar-89  1722	CL-Compiler-mailer 	issue CONSTANT-COLLAPSING, version 5    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  17:21:52 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557083; Tue 14-Mar-89 20:10:42 EST
Date: Tue, 14 Mar 89 20:10 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CONSTANT-COLLAPSING, version 5
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131622.AA02093@defun.utah.edu>
Message-ID: <19890315011043.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

The proposal says:

  State the an implementation is permitted to coalesce constants
  appearing in code to be compiled if they are equivalent under the
  relationship defined in proposal CONSTANT-COMPILABLE-TYPES:SPECIFY.

I can't understand what this means.  The referenced proposal uses
the word "similar", not "equivalent".  I'd support this alternate
wording:

  Suppose that A and B are two objects used as quoted constants in the
  input to COMPILE-FILE, and that A' and B' are the corresponding
  objects used as constants in the result of loading the output of
  that COMPILE-FILE.  If A' is similar as a constant to both A and B,
  then it is valid for A' and B' to be EQL even if A and B are not EQL.

This may still be too vague, since "objects in the input to
COMPILE-FILE" means not in the input text file, which doesn't contain
objects, but in the result of applying READ to the input file, and since
"corresponding objects" is not defined.

∂14-Mar-89  1730	CL-Compiler-mailer 	issue COMPILED-FUNCTION-REQUIREMENTS, version 4   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  17:29:45 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 557112; 14 Mar 89 20:27:21 EST
Date: Tue, 14 Mar 89 20:27 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131544.AA02070@defun.utah.edu>
Message-ID: <19890315012722.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

I much prefer the option FLUSH, which was in version 2 but has been
removed.  That option was to remove the COMPILED-FUNCTION type.
This type has no portable meaning and never should have existed.

I have no objection to the proposed specification of what the COMPILE
and COMPILE-FILE functions do, but it should be decoupled from the
COMPILED-FUNCTION type and discussed under the rubric of those two
functions.  The parts about COMPILER-LET and EVAL-WHEN can probably be
removed (assuming the COMPILER-LET-CONFUSION proposal that eliminates
the possibility of COMPILER-LET binding any variables at run time
passes, and the EVAL-WHEN-NON-TOP-LEVEL proposal passes) since they are
redundant; there is never any interpeter/compiler difference for
COMPILER-LET or EVAL-WHEN any more.

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

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


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

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

∂14-Mar-89  1810	CL-Compiler-mailer 	Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Mar 89  18:09:53 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA23949; Tue, 14 Mar 89 19:07:40 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA04006; Tue, 14 Mar 89 19:07:33 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903150207.AA04006@defun.utah.edu>
Date: Tue, 14 Mar 89 19:07:31 MST
Subject: Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 14 Mar 89 18:41 EST

> Date: Tue, 14 Mar 89 18:41 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
> I would assume that VARIABLE-TYPE is not required to return the
> exact declared type specifier, but could return another type
> specifier that is equivalent, or possibly another type specifier
> that is a supertype.

That sounds reasonable to me.

> The :MACRO argument to AUGMENT-ENVIRONMENT shouldn't look like the CADR
> of a MACROLET special form, instead it should be a list of lists (name
> function).  That is, the expander functions should be supplied in the
> form of functions rather than in the form of the source text used by
> MACROLET.  Your rationale argues against this but I strongly believe
> that the rationale is wrong.  I wouldn't mind seeing the parsing portion
> of MACROLET made available as a separate function.

Can you provide a rationale for this?

Actually, I wouldn't object to the change as long as the function to do
the parsing is provided.  (I speak from personal experience, this is 
really a hairy piece of code to have to write from scratch.)  How about

  PARSE-MACRO name-and-definition &optional env		[Function]

  Name-and-definition a list of the form (name lambda-list . body),
  as in the format of a MACROLET special form.  Two values are returned:
  the name of the macro and a macro function.
      
>   DECLARATION decl-type name &optional env     [Function]
> 
>   decl-type is a symbol.  The interpretation of name depends
>   on decl-type.  If a declaration of that type and name is
>   in force in the specified environment, it is returned, otherwise
>   NIL is returned.  The following decl-types are specified,
>   additional implementation-dependent types could be added:
> 
>     INLINE function-name => T or NIL
>     NOTINLINE function-name => T or NIL
>     IGNORE variable-name => T or NIL
>     OPTIMIZE quality => integer
>     DECLARATION decl-type => T or NIL

Hmmm.  Could we extend this to handle the TYPE and FTYPE declarations
too, and dispense with VARIABLE-TYPE and FUNCTION-FTYPE?  And, should
the symbols for the decl-type argument be keywords?

> The possible interpreter implementation of COMPILER-LET I mentioned
> in another message earlier today would seem to require another
> keyword argument to AUGMENT-ENVIRONMENT.  Does this mean that we
> have to dictate some particular interpreter implementation of
> COMPILER-LET?  I'm unsure.

I believe so.  It wouldn't work for a user codewalker to bind
COMPILER-LET variables specially before walking the body, if
MACROEXPAND-1 is going to look in the environment for variables to
bind.  (It may mistakenly bind a variable in an outer contour that is
supposed to be shadowed by one the codewalker bound.)  And it wouldn't
work for code walkers just to add the bindings to the environment if
MACROEXPAND-1 doesn't look for them. 

Do you really want to go ahead with this idea?  At the very least, I
think it would have to be presented as a separate proposal from
COMPILER-LET-CONFUSION:REPAIR, instead of just suggested as a way to
implement that proposal. 

-Sandra
-------

∂14-Mar-89  1922	CL-Compiler-mailer 	comments on issues  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Mar 89  19:22:43 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA25232; Tue, 14 Mar 89 20:20:34 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA04102; Tue, 14 Mar 89 20:20:32 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903150320.AA04102@defun.utah.edu>
Date: Tue, 14 Mar 89 20:20:30 MST
Subject: comments on issues
To: cl-compiler@sail.stanford.edu

Dave Moon has given us some excellent comments on our pending issues.
At this point, it seems like most of the writeups are going to need
one more round of tweaks before the meeting.  I propose to start doing
the revisions around the middle of next week.  So, if any of you have
anything more to say, please do so by next Tuesday (the 21st).

In other news, I've heard from Jan that the agenda for the meeting has
been reshuffled, and we are now scheduled to go on Thursday morning
right after the editorial committee report.

-Sandra
-------

∂15-Mar-89  0508	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89  05:07:47 PST
Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 89 05:00:44 PST
Date: 15 Mar 89 05:00 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
 Mon, 13 Mar 89 15:50:07 -0700
To: cl-compiler@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890315-050044-3449@Xerox>

I think I know what this means, but I worry that the language isn't precise
enough and we will have some problems with misreading. This leaves it an
"editorial" issue, I suppose, but I don't envy the job of the editor. Just
some examples:

    (b) In conforming code, variables that are intended to be bound
        specially must be declared SPECIAL in the compiletime environment
        before any bindings of that variable are processed by the compiler.
	The compiler must treat any binding of an undeclared variable as a
	lexical binding.


The terms I'd wish defined are

 "intended"  - by whom?
 
"declared... in the compiletime environment before"
	- probably you mean that the compiler must process an appropriate
	DECLARE or PROCLAIM, not that such a DECLARE or PROCLAIM actually
	be evaluated. Probably "before" means either chronologically or
	in some appropriate lexically enclosing scope.

"processed by the compiler"
	- probably "processed" doesn't include READ.


d

∂15-Mar-89  0636	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Mar 89  06:36:09 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA06665; Wed, 15 Mar 89 07:33:53 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA04537; Wed, 15 Mar 89 07:33:49 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903151433.AA04537@defun.utah.edu>
Date: Wed, 15 Mar 89 07:33:47 MST
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
To: masinter.pa@Xerox.COM
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM, 15 Mar 89 05:00 PST

Sigh.  I've already gone over the wording on this issue once with
Kathy Chapman and incorporated her suggestions.  If you have some
specific alternate wording you would like to see, please let me know.
I don't have any particularly strong attachment to the current
language.

-Sandra
-------

∂15-Mar-89  0913	CL-Compiler-mailer 	Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89  09:13:18 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557474; Wed 15-Mar-89 12:10:25 EST
Date: Wed, 15 Mar 89 12:10 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@sail.stanford.edu
In-Reply-To: <8903150207.AA04006@defun.utah.edu>
Message-ID: <19890315171024.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 14 Mar 89 19:07:31 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    > Date: Tue, 14 Mar 89 18:41 EST
    > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    > The :MACRO argument to AUGMENT-ENVIRONMENT shouldn't look like the CADR
    > of a MACROLET special form, instead it should be a list of lists (name
    > function).  That is, the expander functions should be supplied in the
    > form of functions rather than in the form of the source text used by
    > MACROLET.  Your rationale argues against this but I strongly believe
    > that the rationale is wrong.  I wouldn't mind seeing the parsing portion
    > of MACROLET made available as a separate function.

    Can you provide a rationale for this?

What if we got here not via looking at a MACROLET in the user's source,
but through some other path that causes us to want to use local macros?
Should we have to take the expander functions in our hand and somehow
turn them back into MACROLET syntax so AUGMENT-ENVIRONMENT can turn them
back into functions again?  It's a simple question of levels of abstraction.

    Actually, I wouldn't object to the change as long as the function to do
    the parsing is provided.  (I speak from personal experience, this is 
    really a hairy piece of code to have to write from scratch.)  

Not if you have DESTRUCTURING-BIND.  But I guess that hasn't been
accepted into the language yet.

    How about
    
      PARSE-MACRO name-and-definition &optional env		[Function]

      Name-and-definition a list of the form (name lambda-list . body),
      as in the format of a MACROLET special form.  Two values are returned:
      the name of the macro and a macro function.
      
It should return a lambda expression, not a function.  Most likely that
is what you really meant to say.  I have a mild preference for passing
the name, lambda-list, and body as separate arguments, and returning
only the function, not the name, but that's not vital.  But I would propose:

  PARSE-MACRO name lambda-list body &optional env		[Function]

  Processes the lambda-list in the same way that DEFMACRO and MACROLET do.
  Returns a lambda-expression that accepts two arguments (form and env)
  and returns the macro expansion.  Name is the name of the macro and
  is supplied as an argument for implementation-dependent use, such as
  including the name of the macro in error messages issued if the form
  does not match the lambda-list.

    >   DECLARATION decl-type name &optional env     [Function]
    > 
    >   decl-type is a symbol.  The interpretation of name depends
    >   on decl-type.  If a declaration of that type and name is
    >   in force in the specified environment, it is returned, otherwise
    >   NIL is returned.  The following decl-types are specified,
    >   additional implementation-dependent types could be added:
    > 
    >     INLINE function-name => T or NIL
    >     NOTINLINE function-name => T or NIL
    >     IGNORE variable-name => T or NIL
    >     OPTIMIZE quality => integer
    >     DECLARATION decl-type => T or NIL

    Hmmm.  Could we extend this to handle the TYPE and FTYPE declarations
    too, and dispense with VARIABLE-TYPE and FUNCTION-FTYPE?  

The problem is that the declaration scoping rules require that both
declarations and bindings be examined in parallel to decide whether a
declaration is in force or is shadowed by a binding inside it.  This
applies to TYPE, FTYPE, INLINE, NOTINLINE, SPECIAL, and IGNORE.  I
thought about this for quite some time.  The choice is whether to have
one DECLARATION function that behaves irregularly, using different
scoping rules for different decl-type arguments, or to have separate
functions VARIABLE-TYPE, FUNCTION-FTYPE, FUNCTION-INLINE, VARIABLE-KIND,
and VARIABLE-IGNORED.  FUNCTION-INLINE would return one of NIL, INLINE,
or NOTINLINE.
		       
I hadn't realized the full scope of this problem when I sent my comments
yesterday.  I haven't yet settled on a position that I believe, however
I don't like the proposal as it stands because it offers access to some
declarations but not to others.  I remember an older version of the
proposal had one function for variables and one for functions, and each
returned multiple values which were the complete information about the
variable or function.  What was the criterion for getting rid of that?
It might help decide this issue too.  Can we continue discussing this?

    And, should the symbols for the decl-type argument be keywords?

Absolutely not!  They should be the same symbols that DECLARE uses.

    > The possible interpreter implementation of COMPILER-LET I mentioned
    > in another message earlier today would seem to require another
    > keyword argument to AUGMENT-ENVIRONMENT.  Does this mean that we
    > have to dictate some particular interpreter implementation of
    > COMPILER-LET?  I'm unsure.

    I believe so.  It wouldn't work for a user codewalker to bind
    COMPILER-LET variables specially before walking the body, if
    MACROEXPAND-1 is going to look in the environment for variables to
    bind.  (It may mistakenly bind a variable in an outer contour that is
    supposed to be shadowed by one the codewalker bound.)  And it wouldn't
    work for code walkers just to add the bindings to the environment if
    MACROEXPAND-1 doesn't look for them. 

    Do you really want to go ahead with this idea?  At the very least, I
    think it would have to be presented as a separate proposal from
    COMPILER-LET-CONFUSION:REPAIR, instead of just suggested as a way to
    implement that proposal. 

I still believe that this way of doing COMPILER-LET is better than
fully expanding all macros whenever the interpreter sees a COMPILER-LET.
But I don't feel very confident in dictating a particular implementation.
Can we continue discussing this?

∂15-Mar-89  1043	CL-Compiler-mailer 	Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Mar 89  10:42:58 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA15806; Wed, 15 Mar 89 11:40:39 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA04690; Wed, 15 Mar 89 11:40:36 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903151840.AA04690@defun.utah.edu>
Date: Wed, 15 Mar 89 11:40:35 MST
Subject: Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
        cl-compiler@sail.stanford.edu

> Date: Wed, 15 Mar 89 12:10 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
> Not if you have DESTRUCTURING-BIND.  But I guess that hasn't been
> accepted into the language yet.

Is there a cleanup proposal afoot to add this?  I don't remember seeing
this on the list Larry distributed at the last meeting.  

>   PARSE-MACRO name lambda-list body &optional env		[Function]
> 
>   Processes the lambda-list in the same way that DEFMACRO and MACROLET do.
>   Returns a lambda-expression that accepts two arguments (form and env)
>   and returns the macro expansion.

If this function doesn't actually do any evaluation to construct a
real function, is it really necessary to have it accept an environment
argument?

Also, a long time ago we passed a cleanup issue saying that the body
of a macro definition established with MACROLET or DEFMACRO has an
implicit BLOCK around it.  Unless you want the "body" argument to
already include the BLOCK, you need the "name" argument for this
purpose.  Let's be explicit about it, one way or the other.

> I don't like the proposal as it stands because it offers access to some
> declarations but not to others.  I remember an older version of the
> proposal had one function for variables and one for functions, and each
> returned multiple values which were the complete information about the
> variable or function.  What was the criterion for getting rid of that?

Looking over back mail on this issue, I see that you made a similar
suggestion while we were discussing version 1, but that it was never
incorporated into any later version of the writeup.  It would help me
to understand the issues involved better if you can come up with
something specific on this.

Incidentally, version 1 did include individual accessor functions for
INLINE and OPTIMIZE declarations, plus hooks for dealing with block
names and go tags that are not included in later versions.

> Can we continue discussing this?

Yes, but let's discuss the problems with COMPILER-LET separately.
Neither of the existing COMPILER-LET proposals require anything
special to be done with the environment accessor issue.

-Sandra
-------

∂15-Mar-89  0800	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Mar 89  08:00:32 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA09473; Wed, 15 Mar 89 08:58:15 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA04583; Wed, 15 Mar 89 08:58:10 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903151558.AA04583@defun.utah.edu>
Date: Wed, 15 Mar 89 08:58:09 MST
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 14 Mar 89 20:27 EST

> I have no objection to the proposed specification of what the COMPILE
> and COMPILE-FILE functions do, but it should be decoupled from the
> COMPILED-FUNCTION type and discussed under the rubric of those two
> functions.

I was envisioning that this material would end up in section 4.2 of
the standard, in the subsection that presents our simple model of what
a compiler does.  If proposal TIGHTEN passes, the definition of the
COMPILED-FUNCTION type in section 2.2 would contain a reference to it.

I don't have any any objection to restoring the FLUSH proposal.

-Sandra
-------

∂15-Mar-89  1345	CL-Compiler-mailer 	issue COMPILER-LET-CONFUSION, version 7 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Mar 89  13:45:23 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA25671; Wed, 15 Mar 89 14:43:11 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA04763; Wed, 15 Mar 89 14:42:55 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903152142.AA04763@defun.utah.edu>
Date: Wed, 15 Mar 89 14:42:54 MST
Subject: issue COMPILER-LET-CONFUSION, version 7
To: moon@stony-brook.scrc.symbolics.com
Cc: cl-compiler@sail.stanford.edu

If you really want to pursue the idea of storing COMPILER-LET bindings
in the environment, perhaps we should try to revive another idea that
was suggested by Pitman some time ago in this connection:

> Suppose that instead of referencing the value as a special, you had 
> an operator COMPILER-SYMBOL-VALUE to get its value. [That could be a 
> function, macro, or special form.] I wouldn't have a problem calling
> a function to get this data because I still get to use the same basic
> `shape' of code. Also, uses of COMPILER-LET are rare enough that a
> bit of extra syntax is not overwhelming.
> 
>  (DEFMACRO mac (...) 
>    ... (COMPILER-SYMBOL-VALUE name) ...)
> 
>  (new-COMPILER-LET ((name val))
>    ...)
> 
> I don't know how other supporters of COMPILER-LET would feel about this.
> It looks ok to me, though.
> 
> I can't think of any implementations in which this would be prohibitively
> expensive to implement.

COMPILER-SYMBOL-VALUE would also have to take an optional environment
argument, of course.

As I've pointed out before, it's possible to implement something like
this already by using SYMBOL-MACROLET as a primitive, provided that
you're willing to do without SETF'ing the "variables".  Kent has
complained that he doesn't like the idea of having the symbol macros
shadow the normal (lexical or special) bindings of the variable that
would be visible at runtime, though.  (Personally, I believe anybody
who uses the same variables in a COMPILER-LET that are also used at
runtime in the same lexical scope is asking for trouble anyway.)

If the shadowing problem could be sorted out, I wouldn't object to
seeing this firmed up into a real proposal to redefine COMPILER-LET to
work this way.  You'd also have to add a keyword argument to
AUGMENT-ENVIRONMENT, and something so you can tell whether a variable
has a COMPILER-LET "binding" or not.

-Sandra
-------

∂15-Mar-89  1408	CL-Compiler-mailer 	issue COMPILER-LET-CONFUSION, version 7 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89  14:08:41 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557884; Wed 15-Mar-89 17:05:12 EST
Date: Wed, 15 Mar 89 17:05 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-LET-CONFUSION, version 7
To: sandra%defun@cs.utah.edu
cc: moon@STONY-BROOK.SCRC.Symbolics.COM, cl-compiler@sail.stanford.edu
In-Reply-To: <8903152142.AA04763@defun.utah.edu>
Message-ID: <890315170502.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

People have suggested that if it comes to making an incompatible change
on this one, it's probably better to just remove the feature and let
people continue to provide it compatibly where they think it's useful.
Even though I think the COMPILER-SYMBOL-VALUE thing is technically
doable, I find myself swayed by arguments that it's not the correct
avenue for us to pursue at this time.

∂15-Mar-89  1451	CL-Compiler-mailer 	Issue SAFE-CODE, version 1    
To:   cl-compiler@SAIL.Stanford.EDU, x3j13@SAIL.Stanford.EDU   
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


According to my understanding of the dictionary definitions,
``unsafe'' means primarily ``the opposite or reversal of `safe' '' and
secondarily ``not safe.'' This coincides with Moon's reading.
Therefore, I propose we use the term ``nonsafe'' which clearly means
``not safe.''  This, coupled with the already very explicit definition
of ``unsafe,'' which explains that unsafe code might actually be safe,
should take care of his objection.


			-rpg-

∂15-Mar-89  1449	CL-Compiler-mailer 	Re: issue COMPILER-LET-CONFUSION, version 7  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Mar 89  14:49:24 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA28484; Wed, 15 Mar 89 15:42:54 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA04812; Wed, 15 Mar 89 15:41:55 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903152241.AA04812@defun.utah.edu>
Date: Wed, 15 Mar 89 15:41:53 MST
Subject: Re: issue COMPILER-LET-CONFUSION, version 7
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: moon@STONY-BROOK.SCRC.Symbolics.COM, cl-compiler@sail.stanford.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 15 Mar 89 17:05 EST

I tend to agree -- proposal REPAIR is about the most we can do to
clean up COMPILER-LET without assigning it radically different
semantics from what's specified in CLtL.  While I don't want to
squelch further discussion on this issue if people really are
discontented with both of the existing proposals, I'm not going to
take the initiative to put together any additional proposals myself.

-Sandra
-------

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

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

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


∂15-Mar-89  1941	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4  
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 15 Mar 89  19:40:55 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
	Wed, 15 Mar 89 21:39:48 CST id AA08835 for cl-compiler@sail.stanford.edu
Posted-Date: Wed, 15 Mar 89 21:38:06 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
	id AA16529; Wed, 15 Mar 89 21:38:06 CST
Date: Wed, 15 Mar 89 21:38:06 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903160338.AA16529@pavo.src.honeywell.com>
To: cl-compiler@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 13 Mar 89 15:50:07 -0700 <8903132250.AA02499@defun.utah.edu>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4

If we permit the compiler to signal warnings for functions where the
compile-time environment signature is different from the function call
being compiled, why do we prohibit it for generic functions?

From COMPILE-ENVIRONMENT-CONSISTENCY:

    (3) The compiler *must not* make any additional assumptions about
    consistency between the compiletime and runtime environments.  In 
    particular:

	(a) The compiler may not ...  It is, however,
	    permissible for the compiler to emit warning messages when
	    compiling calls to functions that are defined in the compiletime
	    environment, but where the wrong number or type of arguments
	    are supplied.

But then in CLOS-MACRO-COMPILATION:

  
  DEFMETHOD:
  
  * The method is not callable at compile-time.  If there is a generic
    function with the same name at compile-time, compiling a DEFMETHOD
    will not add the method to that generic function.  The compiler may
    perform tests for lambda-list congruence only between the DEFGENERICs
    and DEFMETHODs for a given generic function name that appear within
    the file being compiled, and not against a generic function of the 
    same name which exists in the compile-time environment.
  

∂15-Mar-89  2035	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Mar 89  20:35:47 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA10009; Wed, 15 Mar 89 21:33:36 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA05125; Wed, 15 Mar 89 21:33:33 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903160433.AA05125@defun.utah.edu>
Date: Wed, 15 Mar 89 21:33:31 MST
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
To: alarson@src.honeywell.com (Aaron Larson)
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: alarson@src.honeywell.com (Aaron Larson), Wed, 15 Mar 89 21:38:06 CST

> Date: Wed, 15 Mar 89 21:38:06 CST
> From: alarson@src.honeywell.com (Aaron Larson)
> 
> If we permit the compiler to signal warnings for functions where the
> compile-time environment signature is different from the function call
> being compiled, why do we prohibit it for generic functions?

I believe there are two different (although related) issues being
addressed here.

The section from COMPILE-ENVIRONMENT-CONSISTENCY deals with
consistency requirements for function calls.  It says the compiler
can't assume you're not going to redefine functions between compile
time and run time. 

The section from CLOS-MACRO-COMPILATION deals with consistency between
methods and generic functions.  If you read the description of
DEFMETHOD in CLOS chapter 2, it says that an error must be signalled
if there are problems with lambda-list congruency, or if the function
isn't a generic function, and maybe other things too that I can't
remember off the top of my head.  The intent of the wording in this
proposal was to clarify that this error signalling should happen at
run time and not compile time, since the methods don't actually get
"added" to the generic function until then, and the generic function
might have been redefined between compile time and run time. 

I agree this is confusing, though.  To make things worse, there's been
a suggestion for issue COMPILER-DIAGNOSTICS to allow the compiler to
signal a warning whenever it runs into a situation that it can
determine will cause an error to be signalled at run time.  I will
make another pass over all three proposals to make sure that they are
all mutually consistent in this respect.  Probably this will involve
moving the piece allowing warnings to be signalled from issue
COMPILE-ENVIRONMENT-CONSISTENCY to COMPILER-DIAGNOSTICS, clarifying
that this is only a style warning, and fixing CLOS-MACRO-COMPILATION
to make it more clear that it's talking about the error signalling
required by the specification of DEFMETHOD in CLOS chapter 2 and not
random style warnings issued by the compiler.  Sound OK?

-Sandra
-------

∂15-Mar-89  2046	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4  
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 15 Mar 89  20:46:36 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
	Wed, 15 Mar 89 22:45:30 CST id AA09273 for cl-compiler@sail.stanford.edu
Posted-Date: Wed, 15 Mar 89 22:43:47 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
	id AA16592; Wed, 15 Mar 89 22:43:47 CST
Date: Wed, 15 Mar 89 22:43:47 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903160443.AA16592@pavo.src.honeywell.com>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Wed, 15 Mar 89 21:33:31 MST <8903160433.AA05125@defun.utah.edu>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4

Sounds like a winner to me.

∂16-Mar-89  0601	X3J13-mailer 	Re: issue COMPILER-VERBOSITY, version 6  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  06:01:53 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 05:48:37 PST
Date: 16 Mar 89 05:47 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue COMPILER-VERBOSITY, version 6
To: cl-compiler@sail.stanford.edu
cc: x3J13@sail.stanford.edu
Message-ID: <890316-054837-3596@Xerox>

The current practice of this proposal says that one implementation has a
:VERBOSE that is used for what this proposal calls :PRINT, gives no current
examples of :VERBOSE, etc.  I'm suspicious of a proposal to add something
that is significantly more complex than what any current implementation
already has.

COMPILE-FILE is significantly more part of the "environment" than LOAD is,
and I think that the less we specify its behavior, the better off we are.
While there are useful programmatic portable invocations of LOAD where
controlling the output behavior portably is important, the case for
portable control of output behavior of COMPILE-FILE is much less strong.
What about environments that support incremental compilation? Where
compilation is handled by a background process? Wouldn't this be
unnecessary junk for them to add?

If we have some doubts about whether some of these 'puppies' are really
useful, shouldn't we leave them behind? Not require them? 

Larry

∂16-Mar-89  0645	CL-Compiler-mailer 	Re: issue CONSTANT-CIRCULAR-COMPILATION, version 7
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  06:44:54 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 06:39:07 PST
Date: 16 Mar 89 06:38 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue CONSTANT-CIRCULAR-COMPILATION, version 7
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
 Mon, 13 Mar 89 09:19:28 -0700
To: cl-compiler@sail.stanford.edu
Message-ID: <890316-063907-3657@Xerox>

I think the 'error terminology' is probably misapplied in the use

"State that the consequences are undefined if an object containing a
circular reference appears as a constant to be compiled."

We speak of "... the consequences are undefined... " in reference to the
consequences of execution of a particular construct during the normal
evaluation process, either in interpreted or compiled code.

The appearance of the object itself does not have undefined consequences, I
don't think. Is it the consequence of attempting to invoke COMPILE or
COMPILE-FILE that is undefined, or is it the consequence of attempting to
execute the result of the COMPILE or COMPILE-FILE that you wish to leave
undefined?

If I say

(defun frob ()
	(when nil #1=(nil . #1#)))

(compile 'frob)
(frob)

are the consequences undefined?

Maybe I'm just quibbling.

Larry

∂16-Mar-89  0648	CL-Compiler-mailer 	Re: issue LOAD-TIME-EVAL, version 11    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  06:48:06 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 06:45:55 PST
Date: 16 Mar 89 06:45 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue LOAD-TIME-EVAL, version 11
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
 Mon, 13 Mar 89 09:31:50 -0700
To: cl-compiler@sail.stanford.edu
Message-ID: <890316-064555-3667@Xerox>

Um, I looked for and didn't find a justification for why what was passed at
the last meeting was inadequate. I'm puzzled as to why there are now two
proposals when there was one before, what the differences are between them,
etc.

Can you elucidate? (preferably to X3J13)

Larry

∂16-Mar-89  0651	CL-Compiler-mailer 	Re: issue QUOTE-SEMANTICS, version 2    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  06:50:39 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 06:48:29 PST
Date: 16 Mar 89 06:47 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue QUOTE-SEMANTICS, version 2
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
 Mon, 13 Mar 89 10:21:33 -0700
To: cl-compiler@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890316-064829-3674@Xerox>

Can you explain how QUOTE-SEMANTICS and CONSTANT-COLLAPSING aren't the
addressing the same issue?


∂16-Mar-89  0655	CL-Compiler-mailer 	Re: issue QUOTE-SEMANTICS, version 2    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Mar 89  06:55:47 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA20657; Thu, 16 Mar 89 07:53:34 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA05480; Thu, 16 Mar 89 07:53:32 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903161453.AA05480@defun.utah.edu>
Date: Thu, 16 Mar 89 07:53:30 MST
Subject: Re: issue QUOTE-SEMANTICS, version 2
To: masinter.pa@Xerox.COM
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM, 16 Mar 89 06:47 PST

> Can you explain how QUOTE-SEMANTICS and CONSTANT-COLLAPSING aren't the
> addressing the same issue?

QUOTE-SEMANTICS discusses in what circumstances (COMPILE-FILE only or
COMPILE and EVAL also) it is legitimate for constants to be coalesced
or copied. 

CONSTANT-COLLAPSING proposes to change the equivalence relationship
used to compare two constants to see if they can be coalesced from
EQUAL to something more general.

-Sandra
-------

∂16-Mar-89  0708	CL-Compiler-mailer 	Re: Issue SAFE-CODE, version 1     
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  07:08:22 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 07:03:17 PST
Date: 16 Mar 89 07:02 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue SAFE-CODE, version 1    
In-reply-to: Dick Gabriel <RPG@SAIL.Stanford.EDU>'s message of 15 Mar 89
 14:51 PST
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: cl-compiler@SAIL.Stanford.EDU, x3j13@SAIL.Stanford.EDU
Message-ID: <890316-070317-3708@Xerox>

I'm guessing that Moon's objections are more serious than yours.

Frankly, as long as we're playing definitions, I think the problem lies
with 

"Define that, formally, the term ``safe code'' is code refers to any
  code in which the OPTIMIZE quality for SAFETY has a value of 3."

I don't think this is a good definition. It is probably good to define that
"any code in which the OPTIMIZE quality for SAFETY has a value 3" is "safe
code", but there is other code that is "safe" too. 

It seems pretty awkward to say that:

(locally (declare (optimize (safety 0))) (list 1 2 3))

is "unsafe" or "nonsafe" or "potentially non-safe". We could use the words
that way, but it is pretty confusing. 

Counter-proposal: say "declared safe" or "not declared safe", since the
issue is not the (English) safety of the code but the declarations in
effect?




∂16-Mar-89  0720	CL-Compiler-mailer 	Re: issue QUOTE-SEMANTICS, version 2    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  07:20:41 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 07:17:20 PST
Date: 16 Mar 89 07:16 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue QUOTE-SEMANTICS, version 2
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
 Thu, 16 Mar 89 07:53:30 MST
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
cc: masinter.pa@Xerox.COM, cl-compiler@sail.stanford.edu
Message-ID: <890316-071720-3752@Xerox>

So, there are some outcomes of QUOTE-SEMANTICS where CONSTANT-COLLAPSING is moot?

∂16-Mar-89  0632	X3J13-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  06:32:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 06:23:30 PST
Date: 16 Mar 89 06:22 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Tue, 14 Mar 89 20:27 EST
To: cl-compiler@sail.stanford.edu
cc: X3J13@sail.stanford.edu
Message-ID: <890316-062330-3633@Xerox>

I think the previous sentiment was more strongly toward removing
COMPILED-FUNCTION rather than tightening its definition. However, in the
heat of the FUNCTION-TYPE discussion, this seemed to be a controversial
backward incompatibility (why not just leave it in, but leave it
unspecified?) 

I've extracted some quotes about COMPILED-FUNCTION from the CL-CLEANUP
discussion on FUNCTION-TYPE. Of course, these are taken out of context... 

Return-Path: <@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 02 MAR 87 21:29:49 PST
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 2 Mar
87  21:27:23 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 82Date: Tue, 3
Mar 87 00:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Tue, 3 Mar 87 00:26 EST

It might be wise to add LEXICAL-CLOSURE and INTERPRETED-FUNCTION data
types, to go along with the COMPILED-FUNCTION type that already exists.
These three would be disjoint subtypes of FUNCTION, but not necessarily
an exhaustive partition.  There might be other ways to slice the space
of types, since it's not so clear what a function not inside a closure
is good for.  Alternatively we could flush COMPILED-FUNCTION and say
that the subtypes of FUNCTION are all implementation-dependent.  But I
think having COMPILED-FUNCTION without the others is weird.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:FAHLMAN@C.CS.CMU.EDU>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 08 MAR 87 21:56:23 PST
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Mar 87
21:53:10 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 9 Mar 87 00:53:51-EST
Date: Mon, 9 Mar 87 00:53 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

Probably we should explicitly name COMPILED-FUNCTION and
INTERPRETED-FUNCTION as subtypes of FUNCTION, and make TYPEP work for
them.  
- - - - - - - - -
Return-Path: <RPG@SAIL.STANFORD.EDU>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 08 MAR 87 23:54:05 PST
Date: 08 Mar 87 23:51 PST
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

Possibly these should not be required to be pairwise disjoint (?).

I think we shouldn't presume that all implementations implement 
functions as closures. I can imagine an implementation with
COMPILED-FUNCTIONs, INTERPRETED-FUNCTIONs, COMPILED-CLOSUREs,
and INTERPRETED-CLOSUREs.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:FAHLMAN@C.CS.CMU.EDU>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 09 MAR 87 08:07:46 PST
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Mar 87
08:01:49 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 9 Mar 87 10:57:49-EST
Date: Mon, 9 Mar 87 10:57 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

Well, these make sense only in systems that do support both compiled and
interpreted code.  In compiler-only or interpreter-only systems, I guess
the best move would be to say that every function is a member of both of
these subtypes: it is both a fast function and a slow function.

Now you're the one who is letting the user see internal stuff that is
none of his concern.  All of these functions are closures, in that they
no longer have any free variables waiting to be closed.  In some cases,
there may have been none in the first place, and implementors may want
to use some efficient internal form in such cases, but is there any
reason the user needs to know that?  A confusing concept that does him
no good (I think).
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 10 MAR 87 07:54:56 PST
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Mar
87  07:48:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 89098; Tue
10-Mar-87 01:57:50 EST
Date: Tue, 10 Mar 87 01:57 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

... I vacillate between
saying that all of the subtypes of FUNCTION are implementation-dependent
and shouldn't be standardized (thus COMPILED-FUNCTION should be
removed), and saying that programs might want to know this information,
so all the plausible subtypes should have standard names, even if they
aren't distinct in some implementations.  The only thing I feel strongly
and consistently about is that COMPILED-FUNCTION should not be the only
standardized subtype of FUNCTION; it should either acquire some siblings
or go away.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 13 MAY 87 00:13:57 PDT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 13 May
87  00:12:36 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM
via CHAOS with CHAOS-MAIL id 138655; Wed 13-May-87 03:10:55 EDT
Date: Wed, 13 May 87 03:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

 * It seems to me that we might as well go ahead and create types
   INTERPRETED-FUNCTION and COMPILED-FUNCTION since the combination of
   the FUNCTION type and the COMPILED-FUNCTION-P predicate already
implements
   this distinction. Perhaps eventually COMPILED-FUNCTION-P could be
flushed.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:FAHLMAN@C.CS.CMU.EDU>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 17 MAY 87 19:32:45 PDT
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 May 87
19:31:22 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 17 May 87 22:30:44-EDT
Date: Sun, 17 May 87 22:30 EDT
Message-ID: <FAHLMAN.12303231779.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU

One possibility is not to define any of these and to eliminate
COMPILED-FUNCTION-P.  That's what I proposed in version 3.  The other
possibility is to define COMPILED-FUNCTION and INTERPRETED-FUNCTION as
subtypes of FUNCTION, but then we have to spell out what happens in
implementations that have only one internal representation or that have
more than two -- raw interpreted, transformed, and fully compiled, for
example.  Then there's the question of whether closures are, or can be,
a separate subtype.  In some sense, all true functions are closures,
since to get one you close a lambda expression in some lexical
environment.  However, we might want to reserve the word "closure" for
functions that actually capture some part of the lexical context outside
the function itself, and to create CLOSURE types based on this idea.

In my view, we are better off avoiding this whole thing and leaving it
to the individual implementations.
- - - - - - - - -
Date: 29 May 87 21:18 PDT
Subject: Issue: FUNCTION-TYPE (version 4)
From: Masinter.pa

Proposal FUNCTION-TYPE:REDEFINE

...
No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION.  Examples might be
COMPILED-FUNCTION, INTERPRETED-FUNCTION, and so on. Note that this
is a change from the current Common Lisp definition which explicitly
defines a COMPILED-FUNCTION type. This proposal removes the predicate
COMPILED-FUNCTION-P from the standard language.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 01 JUN 87 21:23:10 PDT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun
87  21:21:48 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161267; Tue
2-Jun-87 00:11:30 EDT
Date: Tue, 2 Jun 87 00:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    This proposal removes the predicate
    COMPILED-FUNCTION-P from the standard language.

If it also removes the COMPILED-FUNCTION type-specifier, say so here.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:Masinter.pa@Xerox.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 13 JUL 87 12:58:35 PDT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Jul 87  12:54:07
PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 87 12:54:07 PDT
Date: 13 Jul 87 12:53 PDT
From: Masinter.pa

... My notes [from X3J13 meeting] include ...  that we be more consistent
about justifying removing COMPILED-FUNCTION-P (i.e., why bother?) ...
- - - - - - - - -
Date: 23 Oct 87 11:51 PDT
From: Masinter.pa
Subject: Issue: FUNCTION-TYPE (Version 6)

here is a revised version... I left COMPILED-FUNCTION and
COMPILED-FUNCTION-P as subtypes of FUNCTION.
...
Proposal FUNCTION-TYPE:STRICT-REDEFINITION
...
The COMPILED-FUNCTION subtype of FUNCTION is defined; implementations are
free to define other subtypes of FUNCTION, e.g., INTERPRETED-FUNCTION.  
- - - - - - - - -
(wording preserved through several iterations)
- - - - - - - - -
Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU>
Redistributed: xerox-cl-cleanup↑.pa
Received: from SAIL.Stanford.EDU by Xerox.COM ; 16 FEB 88 09:41:39 PST
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Feb 88
09:39:23 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA23751; Tue, 16 Feb 88 10:39:08 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
	id AA25191; Tue, 16 Feb 88 10:39:04 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8802161739.AA25191@orion.utah.edu>
Date: Tue, 16 Feb 88 10:39:02 MST

Also, I have a question about 1b, where it states that COMPILED-FUNCTION
is a subtype of FUNCTION.  Does this imply that it must be a *proper*
subtype?  For example, in the Lisp I've been working on sporadically for
my Atari, the interpreted version of (FUNCTION (LAMBDA ...)) returns a
compiled function object (it's a closure which will apply the lambda
expression to the function arguments).  Likewise I can conceive of
implementations which compile everything and don't have an "interpreter"
at all.  I think this needs to be clarified.
- - - - - - - - -
Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU>
Redistributed: xerox-cl-cleanup↑.pa
Received: from SAIL.Stanford.EDU by Xerox.COM ; 19 FEB 88 14:37:22 PST
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Feb 88  14:34:11
PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 FEB 88 14:17:33 PST
Date: 19 Feb 88 14:17 PST
From: Masinter.pa
I intended not to require that it not be a "proper" subtype in the sense
that
there may be no data items that are FUNCTIONP but not COMPILED-FUNCTIONP.

This can be clarified. 
- - - - - - - - -
Return-Path: <edsel!jonl@labrea.Stanford.EDU>
Received: from labrea.Stanford.EDU by Xerox.COM ; 24 FEB 88 10:14:38 PST
Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 09:35:20 PST
Received: from bhopal.lucid.com by edsel id AA21578g; Wed, 24 Feb 88
10:03:43 PST
Received: by bhopal id AA26979g; Wed, 24 Feb 88 10:09:26 PST
Date: Wed, 24 Feb 88 10:09:26 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>

Lucid Common Lisp distinguishes "compiled" closures which exist for the
purpose of supporting entry into the interpreter from functions which are
truly compiled.  It only takes a bit in a header word.  If an
implementation
really doesn't support an interpreter, then having every function be
COMPILED-FUNCTIONP  doesn't sound like much of a loss.  

But most implementations in fact do support an interpreter -- which 
typically runs code at anywhere from 30 to 600 times slower than when
compiled.  Thus it seems reasonable to require COMPILED-FUNCTIONP in
those implementations to be false on, say,
	(eval '#'(lambda (x) (list x)))
no matter what underlying technique is used to support interpreter
closures.
- - - - - - - - -
Date:  4 Sep 88 13:39 PDT
From: Masinter.pa
Subject: Issue: FUNCTION-TYPE (version 12)
line-fold: NO

This is the final version of the FUNCTION-TYPE issue, as passed at the June
88 X3J13 meeting; that is, it incorporates the amendments that were adopted
before the issue was adopted.

...
    1b. Define that the type COMPILED-FUNCTION is a subtype of FUNCTION.
        Implementations are free to define other subtypes of FUNCTION.

∂16-Mar-89  0731	CL-Compiler-mailer 	Re: Issue SAFE-CODE, version 1     
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Mar 89  07:31:24 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA22139; Thu, 16 Mar 89 08:29:07 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA05531; Thu, 16 Mar 89 08:29:04 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903161529.AA05531@defun.utah.edu>
Date: Thu, 16 Mar 89 08:29:03 MST
Subject: Re: Issue SAFE-CODE, version 1    
To: masinter.pa@Xerox.COM
Cc: Dick Gabriel <RPG@SAIL.Stanford.EDU>, cl-compiler@SAIL.Stanford.EDU
In-Reply-To: masinter.pa@Xerox.COM, 16 Mar 89 07:02 PST

Hmmm.  I thought this would be the least controversial of any of our
issues!

Seriously folks, I believe the intent of this proposal was *only* to
say that (OPTIMIZE (SAFETY 3)) is the only magic incantation you need
to be guaranteed to get "safe code".  Some of the objections to the
way it's stated seem valid to me, but let's not try to read more into
the issue than was intended.

If anybody wants to submit a new version which fixes the wording, feel
free.

-Sandra
-------

∂16-Mar-89  0737	CL-Compiler-mailer 	Re: issue QUOTE-SEMANTICS, version 2    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Mar 89  07:37:26 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA22462; Thu, 16 Mar 89 08:35:12 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA05545; Thu, 16 Mar 89 08:35:09 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903161535.AA05545@defun.utah.edu>
Date: Thu, 16 Mar 89 08:35:08 MST
Subject: Re: issue QUOTE-SEMANTICS, version 2
To: masinter.pa@Xerox.COM
Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore),
        cl-compiler@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM, 16 Mar 89 07:16 PST

> So, there are some outcomes of QUOTE-SEMANTICS where
> CONSTANT-COLLAPSING is moot? 

No.  Coalescing of constants by COMPILE-FILE will be permitted under
all of the QUOTE-SEMANTICS proposals.

Again, all CONSTANT-COLLAPSING:GENERALIZE does is propose using a
different relationship than EQUAL for comparing two objects to see if
they are equivalent.  If this proposal fails, coalescing of EQUAL
objects will still be permitted.

-Sandra
-------

∂16-Mar-89  0801	CL-Compiler-mailer 	Re: issue EVAL-WHEN-NON-TOP-LEVEL, version 6 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  08:01:12 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 07:53:04 PST
Date: 16 Mar 89 07:52 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue EVAL-WHEN-NON-TOP-LEVEL, version 6
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
 Mon, 13 Mar 89 16:42:54 -0700
To: cl-compiler@sail.stanford.edu
Message-ID: <890316-075304-3840@Xerox>

I like the intent of EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL but have some
wording quibbles.

If "the file compiler" means COMPILE-FILE, why not say COMPILE-FILE?  I'm
sure you don't mean to refer to, say, a C compiler written in Common Lisp,
even though it might be a file compiler. 

Instead of "a top-level form in the file compiler", say "a top-level form
processed by COMPILE-FILE." In any case, you don't mean to talk about one
of the expressions that occur in the source code that defines COMPILE-FILE.



  For an EVAL-WHEN form that is not a top-level form in the file compiler
  (that is, one of: in the interpreter; in COMPILE; or in the file
  compiler but not at top-level) ...


The "(that is, ..." clauses are neither exhaustive or appropriate. I think
you really mean "all other cases". I don't think you can have an EVAL-WHEN
that is 'at top level' to COMPILE since COMPILE takes functions or lambda
expressions. It's possible to think of a version of COMPILE-FILE that
produces things that are then 'interpreted' to some extent (byte-code
interpreter, for example).
Try,


	For an EVAL-WHEN that is not a top-level form processed by
	COMPILE-FILE, 


-- - - - - - - - - -

I'm not too opposed to :EXECUTE, :COMPILE and :LOAD as keywords, but don't
see the need for the extra verbosity of :COMPILE-TOPLEVEL or
:LOAD-TOPLEVEL. There are other ways to emphasize the "toplevel" aspect;
e.g., put ***WARNING*** in your reference manual.

∂16-Mar-89  0928	CL-Compiler-mailer 	Issue SAFE-CODE, version 1         
To:   cl-compiler@SAIL.Stanford.EDU
CC:   x3j13@SAIL.Stanford.EDU  
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


The point of these definitions is to lay out terminology that
enables programmers to know with certainty on what ground they stand
with respect to the specification. ``Safe code'' is a technical term
that means that the code was ``processed'' under this declaration.

This means intuitively that it is as safe (English word) as it can get.
But it also means that it is ``safe code'' in the CL jargon, and eveything
we say about safe code there is also true of it. 

The meaning of safe code (English phrase), as in ``as safe as it can
get,'' is spelled out in the specification as the sequence of statements
we make about the attributes of safe code. It might be that some or all of
those attributes apply to code processed under lower safety optimization
levels, but the programmer can be sure only when the highest safety level
is used.

I think Moon's problem is that the usual practice is to borrow English
words for these technical terms, and that works fine until the
negation of the term is needed. We want some word to mean ``not `safe' ''.
``Unsafe'' is an available English word that does not mean the
complement of ``safe'', it means the reverse of safe. Thus, the parallel
senses of the technical pair ``safe/unsafe'' are not the same as the
vernacular pair safe/unsafe.

Also, the definitions of the terms point out that what is defined as
``unsafe code'' might actually be exactly as safe (English) as ``safe code.''

			-rpg-

∂16-Mar-89  0919	CL-Compiler-mailer 	Re: issue EVAL-WHEN-NON-TOP-LEVEL, version 6 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  09:19:50 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
	id AA13903; Thu, 16 Mar 89 09:20:26 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA13867; Thu, 16 Mar 89 09:16:34 PST
Received: by clam.sun.com (4.0/SMI-4.0)
	id AA03194; Thu, 16 Mar 89 09:20:08 PST
Date: Thu, 16 Mar 89 09:20:08 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903161720.AA03194@clam.sun.com>
To: cl-compiler@sail.stanford.edu, sandra%defun@cs.utah.edu
Subject: Re: issue EVAL-WHEN-NON-TOP-LEVEL, version 6

Ack.  What happened to any version that aims to "fix nesting"?
That problem has to be the main reason I've ever been
interested in this issue.

Suppose programmer A defines a macro DEFINE-FROB that expands into

(EVAL-WHEN (COMPILE LOAD EVAL) . . . )

Now suppose that for some reason programmer B, a user of FROBs,
desires to only define a frob at load time, and writes:

(EVAL-WHEN (LOAD)
  (DEFINE-FROB . . . ))

As defined in CLtL and in EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL,
the frob gets defined at compile-time (too), even though programmer
B specified only LOAD-time.

Is it unreasonable to try to delay such a thing until load time?
Am I wrong about what would happen in this scenario?
What *is* the story here?
				-Cris

∂16-Mar-89  0941	CL-Compiler-mailer 	Re: issue EVAL-WHEN-NON-TOP-LEVEL, version 6 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Mar 89  09:40:51 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA27198; Thu, 16 Mar 89 10:38:30 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA05681; Thu, 16 Mar 89 10:38:28 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903161738.AA05681@defun.utah.edu>
Date: Thu, 16 Mar 89 10:38:27 MST
Subject: Re: issue EVAL-WHEN-NON-TOP-LEVEL, version 6
To: cperdue@Sun.COM (Cris Perdue)
Cc: cl-compiler@sail.stanford.edu, sandra%defun@cs.utah.edu
In-Reply-To: cperdue@Sun.COM (Cris Perdue), Thu, 16 Mar 89 09:20:08 PST

> Date: Thu, 16 Mar 89 09:20:08 PST
> From: cperdue@Sun.COM (Cris Perdue)
> 
> Ack.  What happened to any version that aims to "fix nesting"?
> That problem has to be the main reason I've ever been
> interested in this issue.

I'm well aware that not everybody likes this proposal.  However,
nobody has given me anything specific to include as an alternate
proposal. 

My own personal position on this issue, as I have several times in the
past, is that I would also like to fix the nesting behavior.  However,
since I got several negative comments on the alternate proposal I
circulated myself, and nobody explicitly expressed support for it, I
decided there was little chance of us reaching consensus on it, and
that it wouldn't be worthwhile for me to pursue it further.

If you (or anybody else) absolutely positively cannot live with the
GENERALIZE-EVAL proposal, *and* you have something specific to propose
instead, by all means go ahead and do so.  The alternative would be to
say nothing on this issue, which I think would be far worse than
GENERALIZE-EVAL.

-Sandra
-------

∂16-Mar-89  0958	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
Received: from Aquinas.Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  09:58:47 PST
Received: from OCCAM.THINK.COM by Aquinas.Think.COM via INTERNET with SMTP id 124445; 16 Mar 89 12:31:52 EST
Date: Thu, 16 Mar 89 12:31 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
To: masinter.pa@xerox.com
cc: cl-compiler@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: <890316-062330-3633@Xerox>
Message-ID: <19890316173142.7.BARMAR@OCCAM.THINK.COM>

I'll just reiterate something I said at one of the meetings.  One
portable use I can think of for the COMPILED-FUNCTION type is as a
declaration to allow compiler optimization.  If a function knows (or
requires) that a parameter is a compiled function it can declare that
and the implementation may be able to optimize the FUNCALL better.

Another thing I just thought of is something like:

	(when (typep f '(and function (not compiled-function)))
	  (setq f (compile nil f)))

This doesn't actually work because COMPILE isn't required to accept
lexical closures (well, at least it doesn't accept them in Genera 7.2),
but they satisfy the type specifier, but it would be nice if there were
a standard set of primitives that would allow one to write something
that does what the above tries to do.

                                                barmar

∂16-Mar-89  1041	CL-Compiler-mailer 	Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 16 Mar 89  10:41:10 PST
Received: by ti.com id AA05571; Thu, 16 Mar 89 12:34:15 CST
Received: from Kelvin by tilde id AA13331; Thu, 16 Mar 89 12:28:00 CST
Message-Id: <2815064795-5736240@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 16 Mar 89  12:26:35 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Cc: cl-compiler@SAIL.STANFORD.EDU
Subject: Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE
In-Reply-To: Msg of 14 Mar 89  0738 PST from System Files <SYS@SAIL.Stanford.EDU>

>	...	 It makes me wonder whether we
> > should just permit top-level DECLAREs, but then _it_ would need special
> > handling by the compiler since a macro definition would confuse the
> > semantics of local declarations, so you don't win.
> 
> I don't understand the last sentence.  What kind of macro definition?
> Can you give an example? 

I just meant that we don't want to define DECLARE as a macro, and that
having a special form that is treated specially by the compiler at top
level doesn't seen any better than a function that is treated specially.

∂16-Mar-89  1046	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 16 Mar 89  10:46:05 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
	id AA06443; Thu, 16 Mar 89 13:43:51 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA07257; Thu, 16 Mar 89 13:42:10 EST
Message-Id: <8903161842.AA07257@mist.>
To: Barry Margolin <barmar@FAFNIR.THINK.COM>
Cc: cl-compiler@sail.stanford.edu
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4 
In-Reply-To: Your message of Thu, 16 Mar 89 12:31:00 -0500.
             <19890316173142.7.BARMAR@OCCAM.THINK.COM> 
Date: Thu, 16 Mar 89 13:42:07 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    Date: Thu, 16 Mar 89 12:31 EST
    From: Barry Margolin <barmar@FAFNIR.THINK.COM>
    
    Another thing I just thought of is something like:
    
    	(when (typep f '(and function (not compiled-function)))
    	  (setq f (compile nil f)))
    
    This doesn't actually work because COMPILE isn't required to accept
    lexical closures (well, at least it doesn't accept them in Genera 7.2),
    but they satisfy the type specifier, but it would be nice if there were
    a standard set of primitives that would allow one to write something
    that does what the above tries to do.
    
One of Kent's points in earlier discussion was that it should (read
MUST) be safe to blindly apply to COMPILE to any symbol with a
function definition.  I thought there was general agreement on this.
If the lastest draft contradicts this then it needs to be fixed.

    

∂16-Mar-89  1111	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Mar 89  11:11:32 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA00971; Thu, 16 Mar 89 12:05:45 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA05839; Thu, 16 Mar 89 12:05:35 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903161905.AA05839@defun.utah.edu>
Date: Thu, 16 Mar 89 12:05:34 MST
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4 
To: Dan L. Pierson <pierson@mist.encore.com>
Cc: Barry Margolin <barmar@FAFNIR.THINK.COM>, cl-compiler@sail.stanford.edu
In-Reply-To: Dan L. Pierson <pierson@mist.encore.com>, Thu, 16 Mar 89 13:42:07 EST

> Date: Thu, 16 Mar 89 13:42:07 EST
> From: Dan L. Pierson <pierson@mist.encore.com>
> 
> One of Kent's points in earlier discussion was that it should (read
> MUST) be safe to blindly apply to COMPILE to any symbol with a
> function definition.  I thought there was general agreement on this.
> If the lastest draft contradicts this then it needs to be fixed.

The current wording (from proposal COMPILE-ARGUMENT-PROBLEMS) says
"it is an error".  My recollection is that we agreed to an editorial
change to "the consequences are unspecified", assuming the error
terminology ever gets sorted out.

Now that I think about the interaction between the two proposals, it
does seem like there is a problem -- we can't require a
COMPILED-FUNCTION to be returned and leave the behavior unspecified at
the same time.  I think we need to do one of two things:

(1) Require COMPILE to signal an error if it can't return a 
    COMPILED-FUNCTION.

(2) Say that COMPILE is required to return a COMPILED-FUNCTION only
    in the situations that are not unspecified.

Any further thoughts on this?  My personal leanings are towards
signalling an error.

-Sandra
-------

∂16-Mar-89  1117	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89  11:16:55 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558656; Thu 16-Mar-89 14:13:55 EST
Date: Thu, 16 Mar 89 14:13 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
To: Aaron Larson <alarson@src.honeywell.com>
cc: cl-compiler@sail.stanford.edu, x3j13@sail.stanford.edu
In-Reply-To: <8903160338.AA16529@pavo.src.honeywell.com>
Message-ID: <19890316191343.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 15 Mar 89 21:38:06 CST
    From: alarson@src.honeywell.com (Aaron Larson)

    If we permit the compiler to signal warnings for functions where the
    compile-time environment signature is different from the function call
    being compiled, why do we prohibit it for generic functions?

I would say that what CLOS-MACRO-COMPILATION (which I have not reviewed yet)
is clearly incorrect.  Perhaps CLOS-MACRO-COMPILATION was trying only to rule
out signalling an error for a lack of lambda-list congruency between
compile-time and run-time, but went overboard and ruled out warnings
as well.  I think warnings in this circumstance can be desirable, but
errors are certainly wrong.

∂16-Mar-89  1121	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89  11:21:28 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558661; Thu 16-Mar-89 14:17:32 EST
Date: Thu, 16 Mar 89 14:17 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@sail.stanford.edu
In-Reply-To: <8903142246.AA03773@defun.utah.edu>
Message-ID: <19890316191734.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 14 Mar 89 15:46:00 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    > Date: Tue, 14 Mar 89 16:37 EST
    > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    > The proposal says:
    > Except where some other behavior is explicitly stated, when
    > the compiletime and runtime definitions are different, it is
    > unspecified which will prevail within the compiled code.
    >
    > This means that either the compiletime or the runtime definition
    > will prevail, but nothing else can happen.  It must also be
    > permissible to signal an error complaining about the discrepancy.

    The very first version of this proposal said "it is an error" here,
    back before we had started talking seriously about adopting new error
    terminology.  There was some discussion about it after that, the
    consensus of which seemed to be that the right behavior should really
    be "one or the other".  

    I personally don't see anything wrong with allowing (but not
    requiring) an error to be signalled, now that we seem to have agreed
    that isn't inconsistent with the term "unspecified".

with the term "the consequences are unspecified."

Then let's amend the proposal to permit signalling an error.  As it
currently reads, it does not permit that.  Or if you prefer, amend
the proposal to say

  Except where some other behavior is explicitly stated, when
  the compiletime and runtime definitions are different, the
  consequences are unspecified.

∂16-Mar-89  1122	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 16 Mar 89  11:22:03 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
	id AA07205; Thu, 16 Mar 89 14:19:53 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA07381; Thu, 16 Mar 89 14:18:12 EST
Message-Id: <8903161918.AA07381@mist.>
To: "sandra%defun@cs.utah.edu"@Multimax.encore.com (Sandra J Loosemore)
Cc: Barry Margolin <barmar@FAFNIR.THINK.COM>, cl-compiler@sail.stanford.edu
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4 
In-Reply-To: Your message of Thu, 16 Mar 89 12:05:34 -0700.
             <8903161905.AA05839@defun.utah.edu> 
Date: Thu, 16 Mar 89 14:18:10 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
    Date: Thu, 16 Mar 89 12:05:34 MST
    
    > Date: Thu, 16 Mar 89 13:42:07 EST
    > From: Dan L. Pierson <pierson@mist.encore.com>
    > 
    > One of Kent's points in earlier discussion was that it should (read
    > MUST) be safe to blindly apply to COMPILE to any symbol with a
    > function definition.  I thought there was general agreement on this.
    > If the lastest draft contradicts this then it needs to be fixed.
    
    The current wording (from proposal COMPILE-ARGUMENT-PROBLEMS) says
    "it is an error".  My recollection is that we agreed to an editorial
    change to "the consequences are unspecified", assuming the error
    terminology ever gets sorted out.
    
    Now that I think about the interaction between the two proposals, it
    does seem like there is a problem -- we can't require a
    COMPILED-FUNCTION to be returned and leave the behavior unspecified at
    the same time.  I think we need to do one of two things:
    
    (1) Require COMPILE to signal an error if it can't return a 
        COMPILED-FUNCTION.
    
    (2) Say that COMPILE is required to return a COMPILED-FUNCTION only
        in the situations that are not unspecified.
    
    Any further thoughts on this?  My personal leanings are towards
    signalling an error.
    
What I (and believe Kent) want is a guarantee that it won't signal an
error; if nothing else works COMPILE will simply apply #'IDENTITY to
the symbol's function.  Specifically, it should be legal and safe to
attempt to speed up my current program(s) by doing:

    (DO-SYMBOLS (SYM <my-package>)
    	(WHEN (FBOUNDP SYM) (COMPILE SYM)))

∂16-Mar-89  1147	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89  11:46:48 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558701; Thu 16-Mar-89 14:43:54 EST
Date: Thu, 16 Mar 89 14:43 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@sail.stanford.edu, Moon@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8903142211.AA03724@defun.utah.edu>
Message-ID: <19890316194352.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

This message is just about the environment of MACROLET issue.

    Date: Tue, 14 Mar 89 15:11:20 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    > Date: Tue, 14 Mar 89 15:58 EST
    > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    >   Clarify
    >   that all defining macros which create functional objects (including
    >   DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and the complex form of
    >   DEFSETF, as well as DEFUN) must ensure that those functions are
    >   defined in the lexical environment in which the defining form is
    >   evaluated.
    > 
    > I strongly believe that MACROLET must be consistent with this, which
    > would be a change.  Has that been dealt with as a separate issue?  If
    > not, it should either be added to this issue or brought up as a
    > separate issue, with the interdependency noted in both writeups to
    > minimize the chance of an inconsistent vote.

    The problem with MACROLET is that it defines the macro functions at
    compile time even if it appears at non-top-level, while all the other
    ones listed only do so at top-level.  Non-top-level environments are
    not guaranteed to be "complete" at compile time; bindings of functions
    and variables don't exist yet.  I suppose we could say that trying to
    refer to those functions and variables in the macro functions is an
    error of some variety.

That's what I had in mind.  I believe the implementation of such error
checking is extremely simple (although I admit there might be
implementations that I don't know about where it would be difficult).
I'd most prefer that an error must be signalled, somewhat less prefer
that the consequences be unspecified, and least prefer that the
macro functions use a special lexical environment specifically defined
to be current in the macros and declarations, but null in the symbols,
functions, and blocks.

Upon reflection I think MACROLET would better be handled as a separate
issue.  Has this been discussed and assigned an issue name already?
The basic question is whether DEFMACRO macros and MACROLET macros should
be consistent in the lexical environment of their body, or whether
MACROLET macros should use the null lexical environment, unlike anything
else.  If there is not already anything for this, let me know and I
will write it up.  Let me know whether it should go to the compiler
committee or the cleanup committee.

    In any case, this would be a somewhat more incompatible change than
    what the proposal currently says.  Lucid, for example, evaluates
    DEFMACRO macro functions in the lexical environment that the DEFMACRO
    appears (in spite of what CLtL says), but always evaluates MACROLET
    macro functions in a null lexical environment.

I think this is a rather narrow attitude on compatibility.  What you
seem to have just said is that it's more important for the standard to
be compatible with whatever Lucid's current release does than for the
standard to be self-consistent; I doubt that even most people at Lucid
would agree with that.

∂16-Mar-89  1157	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89  11:55:35 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558714; Thu 16-Mar-89 14:52:53 EST
Date: Thu, 16 Mar 89 14:52 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@sail.stanford.edu
In-Reply-To: <8903142211.AA03724@defun.utah.edu>
Message-ID: <19890316195255.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

This message is just about the issue of the order of non-top-level
subforms of a top-level form.

    Date: Tue, 14 Mar 89 15:11:20 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    > Date: Tue, 14 Mar 89 15:58 EST
    > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    > 
    >   The order in which
    >   non-top-level subforms of a top-level form are processed by the
    >   compiler is explicitly left unspecified.
    > 
    > I can't figure out what this means and the example in the rationale
    > section that purports to explain this does not shed any light, since in
    > the example there is no change of order of evaluation.

    I don't know how to explain this any more clearly -- what's in the
    current version of the proposal is about the third attempt I've made.
    Well, here goes a fourth attempt.

    Suppose I have a top-level DEFMACRO at the top of the file.  Item (3)
    guarantees that this DEFMACRO will be processed before any top-level
    forms that appear textually after it.  That means I can refer to the
    DEFMACRO in those subsequent forms and guarantee that the compiler has
    already "seen" the macro definition.  The same rule applies to any
    other defining macros that do compile-time magic at top-level.

    Now suppose expanding this macro has some side-effects, such as
    SETQ'ing a special variable.  If I have two calls to the macro at
    top-level, I can reliably depend on the side-effects happening in the
    same order that the calls appear textually.  But, the other thing that
    item (3) says is that if the two macro calls are embedded at
    non-top-level, I can't rely on the order in which the compiler will
    expand them.

This explanation is much clearer.  Nothing in the explanation that I
couldn't figure out indicated that it had anything to do with macro
expansion; that was the missing information.  Could you amend the
proposal to clarify this?  Also I found the phrase "non-top-level
subforms of a top-level form" confusing; I wonder if it would work
better to say that the order of expansion of macros is unspecified
for all forms other than top-level forms, i.e. list the cases where
the order is specified and don't try to list the cases where the
order is not specified.

    I agree this could be made into a separate issue and be expanded to
    include a statement that processing of top-level forms is interleaved
    with reading.  It had more to do with this issue when the definition
    of top-level appeared here.

I still think point (3) should be moved to be together with the rest
of the definition of top-level.

∂16-Mar-89  1213	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Mar 89  12:12:51 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA03572; Thu, 16 Mar 89 13:09:15 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA05971; Thu, 16 Mar 89 13:09:13 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903162009.AA05971@defun.utah.edu>
Date: Thu, 16 Mar 89 13:09:11 MST
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4 
To: Dan L. Pierson <pierson@mist.encore.com>
Cc: Barry Margolin <barmar@FAFNIR.THINK.COM>, cl-compiler@sail.stanford.edu
In-Reply-To: Dan L. Pierson <pierson@mist.encore.com>, Thu, 16 Mar 89 14:18:10 EST

> Date: Thu, 16 Mar 89 14:18:10 EST
> From: Dan L. Pierson <pierson@mist.encore.com>
> 
> What I (and believe Kent) want is a guarantee that it won't signal an
> error; if nothing else works COMPILE will simply apply #'IDENTITY to
> the symbol's function.

If this is the position people really want to adopt, I think we ought
to flush the COMPILED-FUNCTION type.  I can't imagine it would be
very useful in declarations if we always allow COMPILE to be a no-op
and never require it to return a COMPILED-FUNCTION.

I was going to restore the FLUSH proposal to this issue anyway, since
some people have now expressed an interest in seeing it back.

I still think that the minimum requirements for compilation specified in
the proposal should apply to COMPILE-FILE, regardless of what happens
to COMPILE and COMPILED-FUNCTION.

-Sandra
-------

∂16-Mar-89  1217	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
Received: from Aquinas.Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  12:16:53 PST
Received: from OCCAM.THINK.COM by Aquinas.Think.COM via CHAOS with CHAOS-MAIL id 124449; Thu 16-Mar-89 15:06:16 EST
Date: Thu, 16 Mar 89 15:06 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4 
To: Dan L. Pierson <pierson@mist.encore.com>
cc: cl-compiler@sail.stanford.edu
In-Reply-To: <8903161842.AA07257@mist.>
Message-ID: <19890316200608.9.BARMAR@OCCAM.THINK.COM>

    Date: Thu, 16 Mar 89 13:42:07 EST
    From: Dan L. Pierson <pierson@mist.encore.com>

	Date: Thu, 16 Mar 89 12:31 EST
	From: Barry Margolin <barmar@FAFNIR.THINK.COM>
    
	Another thing I just thought of is something like:
    
	    (when (typep f '(and function (not compiled-function)))
	      (setq f (compile nil f)))
    
	This doesn't actually work because COMPILE isn't required to accept
	lexical closures (well, at least it doesn't accept them in Genera 7.2),
	but they satisfy the type specifier, but it would be nice if there were
	a standard set of primitives that would allow one to write something
	that does what the above tries to do.
    
    One of Kent's points in earlier discussion was that it should (read
    MUST) be safe to blindly apply to COMPILE to any symbol with a
    function definition.  I thought there was general agreement on this.
    If the lastest draft contradicts this then it needs to be fixed.

I don't know what it says.  However, I didn't apply COMPILE to a symbol,
I applied it to NIL and a function, which means that the anonymous,
interpreted function should be compiled.

Actually, now I'm also a bit confused.  Since we passed the
FUNCTION-TYPE proposal, is the second argument to COMPILE supposed to be
a lambda expression or a function?  Should I have said (compile nil
(source-code f)) ?

                                                barmar

∂16-Mar-89  1225	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 16 Mar 89  12:25:22 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
	id AA07963; Thu, 16 Mar 89 15:23:04 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA07511; Thu, 16 Mar 89 15:21:24 EST
Message-Id: <8903162021.AA07511@mist.>
To: "sandra%defun@cs.utah.edu"@multimax.encore.com (Sandra J Loosemore)
Cc: Barry Margolin <barmar@FAFNIR.THINK.COM>, cl-compiler@sail.stanford.edu
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4 
In-Reply-To: Your message of Thu, 16 Mar 89 13:09:11 -0700.
             <8903162009.AA05971@defun.utah.edu> 
Date: Thu, 16 Mar 89 15:21:22 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
    Date: Thu, 16 Mar 89 13:09:11 MST

    > Date: Thu, 16 Mar 89 14:18:10 EST
    > From: Dan L. Pierson <pierson@mist.encore.com>
    > 
    > What I (and believe Kent) want is a guarantee that it won't signal an
    > error; if nothing else works COMPILE will simply apply #'IDENTITY to
    > the symbol's function.
    
    If this is the position people really want to adopt, I think we ought
    to flush the COMPILED-FUNCTION type.  I can't imagine it would be
    very useful in declarations if we always allow COMPILE to be a no-op
    and never require it to return a COMPILED-FUNCTION.
    
While I would expect that a COMPILE which resulted in IDENTITY would
not necessarily make the function a COMPILED-FUNCTION, I have absolutely no
objections to flushing the type.

    I still think that the minimum requirements for compilation specified in
    the proposal should apply to COMPILE-FILE, regardless of what happens
    to COMPILE and COMPILED-FUNCTION.
    
I agree.  I would also accept a requirement that COMPILE could cause a
function to become a COMPILED-FUNCTION iff it met the minimum
requirements in the proposal.  Note this could still mean, for a
function in which a prepass caused no changes, that IDENTITY could
cause the function to become a COMPILED-FUNCTION.  While this may
sound a bit absurd it's consistent with the position we seem to be
adopting that, COMPILE is "macroexpand-completely" in an
interpreted-only implementation.

∂16-Mar-89  1231	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 16 Mar 89  12:31:20 PST
Received: from mist by multimax.encore.com with SMTP (5.61/25-eef)
	id AA08012; Thu, 16 Mar 89 15:29:08 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA07524; Thu, 16 Mar 89 15:27:23 EST
Message-Id: <8903162027.AA07524@mist.>
To: Barry Margolin <barmar@FAFNIR.THINK.COM>
Cc: cl-compiler@sail.stanford.edu
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4 
In-Reply-To: Your message of Thu, 16 Mar 89 15:06:00 -0500.
             <19890316200608.9.BARMAR@OCCAM.THINK.COM> 
Date: Thu, 16 Mar 89 15:27:21 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    Date: Thu, 16 Mar 89 15:06 EST
    From: Barry Margolin <barmar@FAFNIR.THINK.COM>
    
    	Date: Thu, 16 Mar 89 12:31 EST
    	From: Barry Margolin <barmar@FAFNIR.THINK.COM>
        
    	Another thing I just thought of is something like:
        
    	    (when (typep f '(and function (not compiled-function)))
    	      (setq f (compile nil f)))
        
    I don't know what it says.  However, I didn't apply COMPILE to a symbol,
    I applied it to NIL and a function, which means that the anonymous,
    interpreted function should be compiled.
    
Oops, I misread your example.

    Actually, now I'm also a bit confused.  Since we passed the
    FUNCTION-TYPE proposal, is the second argument to COMPILE supposed to be
    a lambda expression or a function?  Should I have said (compile nil
    (source-code f)) ?
    
Not if you're interested in the value cell of f instead of the function cell.

∂16-Mar-89  1356	CL-Compiler-mailer 	Issue SAFE-CODE, version 1         
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89  13:56:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558883; Thu 16-Mar-89 16:53:42 EST
Date: Thu, 16 Mar 89 16:53 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue SAFE-CODE, version 1         
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>, masinter.pa@Xerox.COM
cc: cl-compiler@SAIL.Stanford.EDU, x3j13@SAIL.Stanford.EDU
In-Reply-To: <svXEG@SAIL.Stanford.EDU>,
             <890316-070317-3708@Xerox>,
             <1avs40@SAIL.Stanford.EDU>,
             <19890314214907.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890316215335.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

Either "nonsafe code" or "code not declared safe" has better connotations
for me than "unsafe code."  I don't really want to get too deeply involved
in choosing the terminology here (if I did, I would be on the editorial
committee), I only wanted to point out that the word used in version 1
of the proposal had an unwanted connotation for me.

∂16-Mar-89  1400	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  14:00:17 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Thu, 16 Mar 89 16:54:31 EST
Date: Thu, 16 Mar 89 16:55 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4 
To: Dan L. Pierson <pierson@mist.encore.com>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: <8903162027.AA07524@mist.>
Message-Id: <19890316215500.2.BARMAR@OCCAM.THINK.COM>

    Date: Thu, 16 Mar 89 15:27:21 EST
    From: Dan L. Pierson <pierson@mist.encore.com>

	Date: Thu, 16 Mar 89 15:06 EST
	From: Barry Margolin <barmar@FAFNIR.THINK.COM>
    
	    Date: Thu, 16 Mar 89 12:31 EST
	    From: Barry Margolin <barmar@FAFNIR.THINK.COM>
        
	    Another thing I just thought of is something like:
        
		(when (typep f '(and function (not compiled-function)))
		  (setq f (compile nil f)))
        
	I don't know what it says.  However, I didn't apply COMPILE to a symbol,
	I applied it to NIL and a function, which means that the anonymous,
	interpreted function should be compiled.
    
    Oops, I misread your example.

	Actually, now I'm also a bit confused.  Since we passed the
	FUNCTION-TYPE proposal, is the second argument to COMPILE supposed to be
	a lambda expression or a function?  Should I have said (compile nil
	(source-code f)) ?
    
    Not if you're interested in the value cell of f instead of the function cell.

Huh?  Doesn't (source-code f) return the source lambda expression for
the function in the value cell of F?  SOURCE-CODE is just a function, so
how could it access the function cell?  By the way, I may be
misremembering the name we gave to the function that returns the
original lambda expression; please correct me if so.

                                                barmar

∂16-Mar-89  1407	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 16 Mar 89  14:07:38 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
	id AA08824; Thu, 16 Mar 89 17:04:59 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA07776; Thu, 16 Mar 89 17:03:19 EST
Message-Id: <8903162203.AA07776@mist.>
To: Barry Margolin <barmar@Think.COM>
Cc: cl-compiler@sail.stanford.edu
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4 
In-Reply-To: Your message of Thu, 16 Mar 89 16:55:00 -0500.
Date: Thu, 16 Mar 89 17:03:17 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    	Actually, now I'm also a bit confused.  Since we passed the
    	FUNCTION-TYPE proposal, is the second argument to COMPILE
    	supposed to be a lambda expression or a function?  Should I
    	have said (compile nil (source-code f)) ?
        
        Not if you're interested in the value cell of f instead of the
        function cell.
    
    Huh?  Doesn't (source-code f) return the source lambda expression for
    the function in the value cell of F?  SOURCE-CODE is just a function, so
    how could it access the function cell?  By the way, I may be
    misremembering the name we gave to the function that returns the
    original lambda expression; please correct me if so.
    
Arg, I must be asleep today.  Of course it does.  However I believe
that COMPILE wants a function not a source lambda expression.

∂16-Mar-89  1417	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Mar 89  14:17:08 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA09686; Thu, 16 Mar 89 15:10:51 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA06119; Thu, 16 Mar 89 15:10:49 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903162210.AA06119@defun.utah.edu>
Date: Thu, 16 Mar 89 15:10:47 MST
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4 
To: Dan L. Pierson <pierson@mist.encore.com>
Cc: Barry Margolin <barmar@Think.COM>, cl-compiler@sail.stanford.edu
In-Reply-To: Dan L. Pierson <pierson@mist.encore.com>, Thu, 16 Mar 89 17:03:17 EST

> Arg, I must be asleep today.  Of course it does.  However I believe
> that COMPILE wants a function not a source lambda expression.

Issue COMPILE-ARGUMENT-PROBLEMS said it would take either.  If it gets
a lambda expression, it'll coerce it to a function.

-Sandra
-------

∂16-Mar-89  1443	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89  14:43:02 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558959; Thu 16-Mar-89 17:39:16 EST
Date: Thu, 16 Mar 89 17:39 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
To: Barry Margolin <barmar@FAFNIR.THINK.COM>
cc: masinter.pa@xerox.com, cl-compiler@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: <19890316173142.7.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890316223916.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: Thu, 16 Mar 89 12:31 EST
    From: Barry Margolin <barmar@FAFNIR.THINK.COM>

    I'll just reiterate something I said at one of the meetings.  One
    portable use I can think of for the COMPILED-FUNCTION type is as a
    declaration to allow compiler optimization.  If a function knows (or
    requires) that a parameter is a compiled function it can declare that
    and the implementation may be able to optimize the FUNCALL better.

But as someone said the last time this suggestion was brought up, if
there is no portable meaning of the COMPILED-FUNCTION type and no
portable way to create an object of that type, no useful correct program
can contain this declaration.

    Another thing I just thought of is something like:

	    (when (typep f '(and function (not compiled-function)))
	      (setq f (compile nil f)))

    This doesn't actually work because COMPILE isn't required to accept
    lexical closures

You just glimpsed the tip of the iceberg.

∂17-Mar-89  1019	CL-Compiler-mailer 	issue CONSTANT-FUNCTION-COMPILATION
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Mar 89  10:19:09 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA04848; Fri, 17 Mar 89 11:16:55 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA06877; Fri, 17 Mar 89 11:16:47 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903171816.AA06877@defun.utah.edu>
Date: Fri, 17 Mar 89 11:16:46 MST
Subject: issue CONSTANT-FUNCTION-COMPILATION
To: cperdue@sun.com, rpg@lucid.com, moon@stony-brook.scrc.symbolics.com
Cc: cl-compiler@sail.stanford.edu

Moon has suggested that we split off the issue of compiling constant
functions from issue CONSTANT-COMPILABLE-TYPES and call it
CONSTANT-FUNCTION-COMPILATION.  This would allow us to have real
proposals written down in advance instead of trying to compose
amendments on the fly at the meeting (which rarely seems to work out
very well), and keep the arguments over this from bogging down the
rest of issue CONSTANT-COMPILABLE-TYPES, which appears to be
noncontroversial. 

The issue is not only whether functions are dumpable, but if they are,
how COMPILE-FILE and LOAD arrange for the function to be
reconstructed.  If we can't arrive at a good definition of what
"similar as constants" means for functions, I contend we must leave
the entire question of their dumpability unspecified.

The current language from issue CONSTANT-COMPILABLE-TYPES says that
two (non-compiled, non-closed) functions are similar as constants if
their SOURCE-LAMBDA-EXPRESSIONs are similar as constants.  I assume
this was a typo for FUNCTION-LAMBDA-EXPRESSIONs, except that
FUNCTION-LAMBDA-EXPRESSION is always permitted to return NIL if it
can't figure out what the original source code looked like.  My
feeling is that this definition of "similar as constants" is
unacceptable because of this.

So, if any of you have some specific language to propose here, 
speak up.  Otherwise I think we have no choice but to say that
constant functions are not supported.

-Sandra
-------

∂17-Mar-89  1047	CL-Compiler-mailer 	Re:  issue CONSTANT-FUNCTION-COMPILATION
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  10:47:41 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
	id AA10182; Fri, 17 Mar 89 10:48:14 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA18058; Fri, 17 Mar 89 10:44:19 PST
Received: by clam.sun.com (4.0/SMI-4.0)
	id AA06760; Fri, 17 Mar 89 10:47:53 PST
Date: Fri, 17 Mar 89 10:47:53 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903171847.AA06760@clam.sun.com>
To: cperdue@Sun.COM, moon@stony-brook.scrc.symbolics.com, rpg@lucid.com,
        sandra%defun@cs.utah.edu
Subject: Re:  issue CONSTANT-FUNCTION-COMPILATION
Cc: cl-compiler@sail.stanford.edu

> The current language from issue CONSTANT-COMPILABLE-TYPES says that
> two (non-compiled, non-closed) functions are similar as constants if
> their SOURCE-LAMBDA-EXPRESSIONs are similar as constants.  I assume
> this was a typo for FUNCTION-LAMBDA-EXPRESSIONs, 

Yes.

> except that
> FUNCTION-LAMBDA-EXPRESSION is always permitted to return NIL if it
> can't figure out what the original source code looked like.  

So both must be non-NIL.

> My
> feeling is that this definition of "similar as constants" is
> unacceptable because of this.

Yes, please fix.

As long as the langauge of the current proposal can be fixed,
I would prefer to fix it.  If we wish to split off an issue
on compiling constant functions, it would be appropriate for
that to amend CONSTANT-COMPILABLE-TYPES.  Likewise it is very
easy to amend the current proposal to remove support for constant
functions.  Their status would become like the status of streams,
where an implementation may choose to support function constants,
but is not required to do so.

				-Cris

∂17-Mar-89  1105	CL-Compiler-mailer 	Re:  issue CONSTANT-FUNCTION-COMPILATION
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Mar 89  11:04:13 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA08374; Fri, 17 Mar 89 12:00:25 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA06917; Fri, 17 Mar 89 12:00:18 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903171900.AA06917@defun.utah.edu>
Date: Fri, 17 Mar 89 12:00:17 MST
Subject: Re:  issue CONSTANT-FUNCTION-COMPILATION
To: cperdue@Sun.COM (Cris Perdue)
Cc: moon@stony-brook.scrc.symbolics.com, rpg@lucid.com,
        cl-compiler@sail.stanford.edu
In-Reply-To: cperdue@Sun.COM (Cris Perdue), Fri, 17 Mar 89 10:47:53 PST

> Date: Fri, 17 Mar 89 10:47:53 PST
> From: cperdue@Sun.COM (Cris Perdue)
>
> > except that
> > FUNCTION-LAMBDA-EXPRESSION is always permitted to return NIL if it
> > can't figure out what the original source code looked like.  
> 
> So both must be non-NIL.
> 
> > My
> > feeling is that this definition of "similar as constants" is
> > unacceptable because of this.
> 
> Yes, please fix.

Let me get this straight.  In addition to the requirement that the
function not be compiled and not be closed over any variables, you would
like to add an additional requirement that FUNCTION-LAMBDA-EXPRESSION
for that function not return NIL?

There is still a problem with the informal nature of your first two
requirements.  Could we use the second value returned from
FUNCTION-LAMBDA-EXPRESSION for testing the second requirement?
If we retain the COMPILED-FUNCTION type, the problem with
detecting that a function is compiled is taken care of, but is there
any reason why we couldn't dispense with this?  If you have the lambda
expression available and that is how "similarity as a constant" is
defined, it shouldn't matter whether the function is compiled or not. 

Aside from the problems of specification, I am still wondering why,
since there is no portable way to construct a function which is
guaranteed to meet these requirements, we should bother to specify a
portable behavior for what happens when they are satisfied.

-Sandra
-------

∂17-Mar-89  1225	CL-Compiler-mailer 	Issue: DEFINE-OPTIMIZER (Version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89  12:25:46 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00773g; Wed, 15 Mar 89 10:41:07 PST
Received: by challenger id AA12228g; Wed, 15 Mar 89 10:34:58 PST
Date: Wed, 15 Mar 89 10:34:58 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903151834.AA12228@challenger>
To: cl-compiler@sail.stanford.edu
Subject: Issue: DEFINE-OPTIMIZER (Version 2)


I oppose this proposal. First, optimization is rarely something that
can be done portably. Using a name like define-optimizer gives the
impression that something will be done more optimally, and maybe it
won't.

Second, it appears that this functionality is isomorphic to macros,
except possibly macros that are only in effect during compilation.

Third, it seems to solve a problem that is addressed by all the various
abstraction mechanisms around already.

Fourth, it is part of a trend I will call ``featherbedding'', which I
will use in my messages to refer to adding comfortable features to
Common Lisp that are redundant or not strictly necessary.

			-rpg-

∂17-Mar-89  1251	CL-Compiler-mailer 	Re: issue QUOTE-SEMANTICS, version 2    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Mar 89  12:51:01 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA12581; Fri, 17 Mar 89 13:48:50 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA07042; Fri, 17 Mar 89 13:48:45 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903172048.AA07042@defun.utah.edu>
Date: Fri, 17 Mar 89 13:48:43 MST
Subject: Re: issue QUOTE-SEMANTICS, version 2
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 14 Mar 89 19:48 EST

> Date: Tue, 14 Mar 89 19:48 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
> I can't support either of the other two proposals because they use
> the words "copying" and "coalescing" without defining their meaning.

"Copying" means making an equivalent object that is similar as a
constant, but not necessarily EQL, to the original. 

I now have a question of my own about how proposal 
COPYING-ALLOWED-BUT-NO-CONSTRAINTS interacts with issue
CONSTANT-COMPILABLE-TYPES.  Maybe somebody who supports this 
issue can help clarify this.

On types where the notion of "similar as a constant" is left
unspecified (for example, readtables), do you want this proposal to
mean that copying is entirely forbidden, or that if the implementation
has defined some behavior for "similar as a constant" on that type,
that it can go ahead and copy?

If copying is entirely forbidden in such a case, the implementation 
cost for this proposal will be just as high as for proposal NO-COPYING.

-Sandra
-------

∂17-Mar-89  1251	CL-Compiler-mailer 	**DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89  12:51:13 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559802; Fri 17-Mar-89 15:48:20 EST
Date: Fri, 17 Mar 89 15:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
To: Eric Benson <eb@lucid.com>
cc: cl-compiler@sail.stanford.edu, x3j13@sail.stanford.edu
In-Reply-To: <8903152040.AA00297@blacksox>
Message-ID: <19890317204812.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 15 Mar 89 12:40:06 PST
    From: Eric Benson <eb@lucid.com>

       Date: Tue, 14 Mar 89 18:41 EST
       From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

       The :MACRO argument to AUGMENT-ENVIRONMENT shouldn't look like the CADR
       of a MACROLET special form, instead it should be a list of lists (name
       function).

    A small point: Shouldn't this be an a-list of the form
    (name . function) instead of a list of lists?

Oh, I keep forgetting that some people have to worry about the efficiency
of conses versus lists.  I don't care which it is.

∂17-Mar-89  1223	X3J13-mailer 	**DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89  12:23:14 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA00913g; Wed, 15 Mar 89 12:36:51 PST
Received: by blacksox id AA00297g; Wed, 15 Mar 89 12:40:06 PST
Date: Wed, 15 Mar 89 12:40:06 PST
From: Eric Benson <eb@lucid.com>
Message-Id: <8903152040.AA00297@blacksox>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-compiler@sail.stanford.edu, x3j13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 14 Mar 89 18:41 EST <19890314234118.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)

   Date: Tue, 14 Mar 89 18:41 EST
   From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

   This looks good so far.  A few comments that might help you
   along with the draft:

   ...

   The :MACRO argument to AUGMENT-ENVIRONMENT shouldn't look like the CADR
   of a MACROLET special form, instead it should be a list of lists (name
   function).  That is, the expander functions should be supplied in the
   form of functions rather than in the form of the source text used by
   MACROLET.  Your rationale argues against this but I strongly believe
   that the rationale is wrong.  I wouldn't mind seeing the parsing portion
   of MACROLET made available as a separate function.

A small point: Shouldn't this be an a-list of the form
(name . function) instead of a list of lists?

∂17-Mar-89  1223	X3J13-mailer 	issue SAFE-CODE, version 1
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89  12:22:54 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01090g; Wed, 15 Mar 89 14:31:11 PST
Received: by challenger id AA12754g; Wed, 15 Mar 89 14:25:03 PST
Date: Wed, 15 Mar 89 14:25:03 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903152225.AA12754@challenger>
To: cl-compiler@sail.stanford.edu, x3j13@sail.stanford.edu
Subject: issue SAFE-CODE, version 1


According to my understanding of the dictionary definitions,
``unsafe'' means primarily ``the opposite or reversal of `safe' '' and
secondarily ``not safe.'' This coincides with Moon's reading.
Therefore, I propose we use the term ``nonsafe'' which clearly means
``not safe.''  This, coupled with the already very explicit definition
of ``unsafe,'' which explains that unsafe code might actually be safe,
should take care of his objection.


			-rpg-

∂17-Mar-89  1350	CL-Compiler-mailer 	Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE  
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 17 Mar 89  13:50:24 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab27291; 17 Mar 89 15:08 EST
Received: from draper.com by RELAY.CS.NET id aa26896; 17 Mar 89 15:03 EST
Date: Fri, 17 Mar 89 08:07 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE
To: cl-compiler@SAIL.STANFORD.EDU
X-VMS-To: CL-COMPILER,SEB1525

>From: David N Gray <Gray@dsg.csc.ti.COM>
>Subject: Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE
>To: "Steve Bacher (Batchman)" <SEB1525@DRAPER.COM>
>Cc: cl-compiler@sail.stanford.EDU
>
>>	...	 It makes me wonder whether we
>> > should just permit top-level DECLAREs, but then _it_ would need special
>> > handling by the compiler since a macro definition would confuse the
>> > semantics of local declarations, so you don't win.
>> 
>> I don't understand the last sentence.  What kind of macro definition?
>> Can you give an example? 
>
>I just meant that we don't want to define DECLARE as a macro, and that
>having a special form that is treated specially by the compiler at top
>level doesn't seen any better than a function that is treated specially.


Well, aren't PROGN and EVAL-WHEN special forms that are treated specially
by the compiler?  Better a special form than a function, no?  

∂17-Mar-89  1352	CL-Compiler-mailer 	Re:  issue CONSTANT-FUNCTION-COMPILATION
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  13:51:50 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
	id AA14890; Fri, 17 Mar 89 13:52:21 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.1)
	id AA26492; Fri, 17 Mar 89 13:48:29 PST
Received: by clam.sun.com (4.0/SMI-4.0)
	id AA07023; Fri, 17 Mar 89 13:52:05 PST
Date: Fri, 17 Mar 89 13:52:05 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903172152.AA07023@clam.sun.com>
To: sandra%defun@cs.utah.edu
Subject: Re:  issue CONSTANT-FUNCTION-COMPILATION
Cc: cl-compiler@sail.stanford.edu, moon@stony-brook.scrc.symbolics.com,
        rpg@lucid.com

Sorry, my mistake.  Using FUNCTION-LAMBDA-EXPRESSION
is no good at all.

∂17-Mar-89  1356	CL-Compiler-mailer 	**DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)    
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  13:54:27 PST
Received: from fafnir.think.com by Think.COM; Fri, 17 Mar 89 16:48:54 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 17 Mar 89 16:50:04 EST
Received: by verdi.think.com; Fri, 17 Mar 89 16:46:51 EST
Date: Fri, 17 Mar 89 16:46:51 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903172146.AA09535@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: eb@lucid.com, cl-compiler@sail.stanford.edu, x3j13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 17 Mar 89 15:48 EST <19890317204812.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)

   Date: Fri, 17 Mar 89 15:48 EST
   From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>

       Date: Wed, 15 Mar 89 12:40:06 PST
       From: Eric Benson <eb@lucid.com>

	  Date: Tue, 14 Mar 89 18:41 EST
	  From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	  The :MACRO argument to AUGMENT-ENVIRONMENT shouldn't look like the CADR
	  of a MACROLET special form, instead it should be a list of lists (name
	  function).

       A small point: Shouldn't this be an a-list of the form
       (name . function) instead of a list of lists?

   Oh, I keep forgetting that some people have to worry about the efficiency
   of conses versus lists.  I don't care which it is.

Well, don't forget PAIRLIS and ACONS, which make the CONS format
a little easier to use than the LIST format.

[Voice 1: AAAAHHHHH!!!  No!!! Not FORMAT!!!]

Calm down; I meant it generically.  Make that "organization".

[Voice 2:  AUUGUGGHH!  Not generics!]

--Guy


∂17-Mar-89  1401	CL-Compiler-mailer 	Re:  issue CONSTANT-FUNCTION-COMPILATION
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Mar 89  14:01:14 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA15114; Fri, 17 Mar 89 14:58:54 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA07201; Fri, 17 Mar 89 14:58:17 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903172158.AA07201@defun.utah.edu>
Date: Fri, 17 Mar 89 14:58:16 MST
Subject: Re:  issue CONSTANT-FUNCTION-COMPILATION
To: cperdue@Sun.COM (Cris Perdue)
Cc: cl-compiler@sail.stanford.edu, moon@stony-brook.scrc.symbolics.com,
        rpg@lucid.com
In-Reply-To: cperdue@Sun.COM (Cris Perdue), Fri, 17 Mar 89 13:52:05 PST

> Sorry, my mistake.  Using FUNCTION-LAMBDA-EXPRESSION
> is no good at all.

Do you have any other ideas?  Like I said before, if nobody comes up
with something specific to define how COMPILE-FILE and LOAD
reconstruct functions, I don't see how we can do anything but say that
functions are unsupported in compiled constants.

-Sandra
-------

∂17-Mar-89  1415	CL-Compiler-mailer 	Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Mar 89  14:15:33 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA15746; Fri, 17 Mar 89 15:13:19 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA07216; Fri, 17 Mar 89 15:13:10 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903172213.AA07216@defun.utah.edu>
Date: Fri, 17 Mar 89 15:13:09 MST
Subject: Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE
To: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Cc: cl-compiler@SAIL.STANFORD.EDU
In-Reply-To: "Steve Bacher (Batchman)" <SEB1525@draper.com>, Fri, 17 Mar 89 08:07 EST

To me, the real problem with having DECLARE be meaningful at top-level
is not that it gets special treatment at compile-time, but that it
gets special treatment at run-time.  CLtL explicitly says that "it is
an error to evaluate a declaration", and I think it would be
incredibly ugly for it to be meaningful to evaluate DECLARE in some
cases and have it be an error in others.

I think of DECLARE as being more of a syntactic marker like LAMBDA
than a special form.  I suspect that the reason why it is documented
as a special form has more to do with history than anything else.  It's
useful so you can signal an error if it appears in the wrong place,
but that's about it.

Trying to get this discussion back along more productive lines, does 
anybody have a suggestion for a better name for DEFPROCLAIM?  A look at
the thesaurus came up with "announce" as another synonym for declare or
proclaim, but that might be too generic-sounding.

-Sandra
-------

∂17-Mar-89  1558	CL-Compiler-mailer 	Re: issue QUOTE-SEMANTICS, version 2    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89  15:58:38 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560066; Fri 17-Mar-89 18:55:56 EST
Date: Fri, 17 Mar 89 18:55 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue QUOTE-SEMANTICS, version 2
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@sail.stanford.edu
In-Reply-To: <8903172048.AA07042@defun.utah.edu>
Message-ID: <19890317235548.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 17 Mar 89 13:48:43 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    > Date: Tue, 14 Mar 89 19:48 EST
    > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    > 
    > I can't support either of the other two proposals because they use
    > the words "copying" and "coalescing" without defining their meaning.

    "Copying" means making an equivalent object that is similar as a
    constant, but not necessarily EQL, to the original. 

OK, but the proposal needs to be updated to say that, since I want
to base my vote only on what proposals actually say.

    I now have a question of my own about how proposal 
    COPYING-ALLOWED-BUT-NO-CONSTRAINTS interacts with issue
    CONSTANT-COMPILABLE-TYPES.  Maybe somebody who supports this 
    issue can help clarify this.

    On types where the notion of "similar as a constant" is left
    unspecified (for example, readtables), do you want this proposal to
    mean that copying is entirely forbidden, or that if the implementation
    has defined some behavior for "similar as a constant" on that type,
    that it can go ahead and copy?

I don't think I'm the one you were expecting a reply from, but if I
have to guess, I think it's the latter.  If an implementation is allowed
to extend "similar as a constant", then copying is consistent with the
definition of "similar as a constant" actually in force in that
implementation, not with the book definition.

    If copying is entirely forbidden in such a case, the implementation 
    cost for this proposal will be just as high as for proposal NO-COPYING.

Does this mean that as long as there is one data type for which copying
is forbidden, perhaps some user-defined data type, there is no implementation
advantage of COPYING-ALLOWED-BUT-NO-CONSTRAINTS over NO-COPYING?
If so, that would seem to knock COPYING-ALLOWED-BUT-NO-CONSTRAINTS
pretty completely out of the running.

∂17-Mar-89  1712	CL-Compiler-mailer 	Re: issue QUOTE-SEMANTICS, version 2    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Mar 89  17:11:56 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA21554; Fri, 17 Mar 89 18:09:42 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA07417; Fri, 17 Mar 89 18:09:40 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903180109.AA07417@defun.utah.edu>
Date: Fri, 17 Mar 89 18:09:38 MST
Subject: Re: issue QUOTE-SEMANTICS, version 2
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Fri, 17 Mar 89 18:55 EST

> Date: Fri, 17 Mar 89 18:55 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
> If an implementation is allowed
> to extend "similar as a constant", then copying is consistent with the
> definition of "similar as a constant" actually in force in that
> implementation, not with the book definition.

That has been my interpretation all along, too, but as I was looking over
the proposal to incorporate your suggested changes, I realized that it
didn't explicitly say that anywhere.

>     If copying is entirely forbidden in such a case, the implementation 
>     cost for this proposal will be just as high as for proposal NO-COPYING.
> 
> Does this mean that as long as there is one data type for which copying
> is forbidden, perhaps some user-defined data type, there is no implementation
> advantage of COPYING-ALLOWED-BUT-NO-CONSTRAINTS over NO-COPYING?
> If so, that would seem to knock COPYING-ALLOWED-BUT-NO-CONSTRAINTS
> pretty completely out of the running.

There would be an implementation advantage in that you could still
copy constants into some part of memory that is not GC'ed, for
example.  That could be beneficial from a memory-management point of
view.  But yes, those implementations that would have problems with
proposal NO-COPYING would have exactly the same problems with
COPYING-ALLOWED-BUT-NO-CONSTRAINTS unless they define what "similar as
a constant" means for all possible data types.

Incidentally, this afternoon I discussed this issue in some detail
with Leigh Stoller, who is the chief compiler hacker for Utah Common
Lisp.  UCL now implements COMPILE in a manner similar to KCL -- it
creates a temporary FASL file which it then LOADs in the usual way,
and the GC assumes that compiled constants never need to be relocated
or scanned.  Leigh says he thinks UCL will probably never be changed
to implement COMPILE any other way, regardless of the outcome of this
issue.  Partly it's a matter of the work involved, but it's also
because he feels pretty strongly that having different conformance
requirements for compiled and interpreted code would just encourage
people to write programs that would break when compiled.  I mentioned
the alternative of just implementing COMPILE as a simple-minded code
walker and not having it produce a "real" compiled function at all,
but he said he thought that would be a giant step backwards.  UCL will
probably never be a conforming implementation for other reasons, but
on this issue it looks like they'd rather be deliberately nonconforming 
than do something which Leigh described as being "really dumb". 

-Sandra
-------

∂17-Mar-89  1729	CL-Compiler-mailer 	cl-compiler subcommittee meeting & agenda    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Mar 89  17:28:51 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA21676; Fri, 17 Mar 89 18:26:36 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA07442; Fri, 17 Mar 89 18:26:34 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903180126.AA07442@defun.utah.edu>
Date: Fri, 17 Mar 89 18:26:33 MST
Subject: cl-compiler subcommittee meeting & agenda
To: cl-compiler@sail.stanford.edu

It looks like I am also going to get sucked into the editorial
committee meeting Monday night.  How would people feel about meeting
for an hour or so Tuesday morning, before the official meeting starts
(scheduled for 9:00)?  If anybody has serious problems with being awake
at that time of morning we could try to arrange something Tuesday 
evening, but my guess is it'll be harder to find a place to meet then.

I've heard from Jan again that the agenda has been changed back to
what it was originally.  We're scheduled for Wednesday afternoon
again. 

-Sandra
-------

∂17-Mar-89  2254	CL-Cleanup-mailer 	Re: Issue: LOAD-OBJECTS (Version 3) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89  22:54:01 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560294; Sat 18-Mar-89 01:50:31 EST
Date: Sat, 18 Mar 89 01:50 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Richard P. Gabriel <rpg@lucid.com>
cc: CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu, Common-Lisp-Object-System@sail.stanford.edu
In-Reply-To: <8903120142.AA00878@defun.utah.edu>
Message-ID: <19890318065022.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

There are a couple of small changes that seem warranted:

   MAKE-LOAD-FORM-USING-SLOTS is too easy to confuse with
   SLOT-VALUE-USING-CLASS.  MAKE-LOAD-FORM-FROM-SLOTS is better,
   except for form/from dyslexia.  MAKE-LOAD-FORM-FOR-SLOTS ?

   Maybe there should be a SIMILAR-AS-CONSTANTS generic function
   for the benefit of CONSTANT-COLLAPSING.  In the absence of that
   we're just using EQ.

On the subject of this proposed alternative:

    Date: Sat, 11 Mar 89 18:42:56 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    Have two generic functions, not one.  The first would get called by
    compile-file and it would return a list of components (or whatever)
    that are required to reconstruct the object.  The compiler would dump
    this list of objects in its usual way.  The loader would apply the
    second generic function to this list to reconstruct the object.  

This is exactly the way I did the first implementation of this idea,
back in about 1978.  It didn't work very well, basically for two reasons.
One is that representing information in the form of lists is pretty
impoverished and it's very easy to get the list the wrong length or
out of order; it's also more difficult than it should be to make
upward-compatible changes, because the new format always has to be
a superset of the old format.  Forms are more general.  You can make
upward-compatible changes by inventing a new function name and keeping
the old function name around forever with the old semantics; this also
ensures an undefined-function error if the new format is loaded into
the old system.

The second reason is more serious.  The way you propose cannot be nicely
extended to deal with circular structures, because it fails to separate
object creation from object initialization.  The second generic function
does both operations.  My application used circular structures
extensively and had a fairly horrible kludge for them, involving standin
objects that were replaced with the correct objects later in loading;
this was fragile and permeated the reconstruction methods, all the worst
characteristics for this kind of thing.

On the subject of forms versus functions as the interface, I think
David Gray has expressed very well the reasons why that is not
practical, at least at Common Lisp's present stage of development.

I've read all the mail on the subject, but I stand by LOAD-OBJECTS
version 3.  There may be more thought behind this proposal than is
apparent at first glance.

∂17-Mar-89  2338	CL-Compiler-mailer 	Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  23:38:32 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 17 MAR 89 23:35:49 PST
Date: 17 Mar 89 23:34 PST
From: masinter.pa@Xerox.COM
Subject: Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
 Mon, 13 Mar 89 17:19:48 -0700
To: cl-compiler@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890317-233549-3549@Xerox>

I think VARIABLE-TYPE is too "generic" a name for what you use it for. Its
maybe VARIABLE-TYPE-SPECIFIER or even VARIABLE-TYPE-DECLARATION. 

VARIABLE-KIND is probably also too generic, although "kind" isn't as
overloaded as "TYPE".

Perhaps VARIABLE-BINDING-KIND or even VARIABLE-BINDING-TYPE.

The problems with VARIABLE-KIND and VARIABLE-TYPE is that there are many
different categorizations that can apply to a VARIABLE, and KIND and TYPE
don't identify the dimensions. 

(VARIABLE-TYPE 'this-is-a-variable-with-a-bad-name)
		=> :long

(VARIABLE-TYPE '|``''W@#!|)
		=> :unreadable

etc.

∂18-Mar-89  0655	CL-Compiler-mailer 	Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 18 Mar 89  06:55:22 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA29761; Sat, 18 Mar 89 07:53:10 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA08047; Sat, 18 Mar 89 07:53:07 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903181453.AA08047@defun.utah.edu>
Date: Sat, 18 Mar 89 07:53:04 MST
Subject: Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
To: masinter.pa@Xerox.COM
Cc: cl-compiler@sail.stanford.edu, masinter.pa@Xerox.COM
In-Reply-To: masinter.pa@Xerox.COM, 17 Mar 89 23:34 PST

Thanks -- those are good suggestions.  I think we'd like to keep the
names of the FUNCTION-xxx functions similar to the VARIABLE-xxx ones,
too.

How about

    VARIABLE-DECLARED-TYPE		FUNCTION-DECLARED-TYPE
    VARIABLE-BINDING-KIND		FUNCTION-BINDING-KIND

-Sandra
-------

∂18-Mar-89  0909	CL-Compiler-mailer 	issue SYNTACTIC-ENVIRONMENT-ACCESS 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 18 Mar 89  09:09:08 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA00948; Sat, 18 Mar 89 10:06:44 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA08173; Sat, 18 Mar 89 10:06:18 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903181706.AA08173@defun.utah.edu>
Date: Sat, 18 Mar 89 10:06:16 MST
Subject: issue SYNTACTIC-ENVIRONMENT-ACCESS
To: cl-compiler@sail.stanford.edu
Cc: moon@stony-brook.scrc.symbolics.com, masinter.pa@xerox.com

Let's try to reach closure on this issue so I can get another draft
circulated before the meeting.  Here is a summary of what I think has
happened since the last version was mailed out.

* Standardizing remote environments at this time would probably be the
  wrong thing, since their use in CLOS is being reconsidered.  We should
  probably discard proposals MEDIUM and LARGE and work with SMALL only
  for now.

* VARIABLE-KIND should return the same second value as FUNCTION-KIND.

* Clarify that VARIABLE-TYPE is permitted to "upgrade" types.

* Change the format of the :MACRO argument to AUGMENT-ENVIRONMENT and
  add a function PARSE-MACRO.

* The names of the functions VARIABLE-TYPE and VARIABLE-KIND are too
  "generic" and ought to be changed.


The remaining issue is still troublesome:

* We need some way to access other kinds of declarations, particularly
  INLINE/NOTINLINE, IGNORE, and OPTIMIZE.

I see three possible solutions to this:

(1) Add a DECLARATION function:

    DECLARATION decl-type name &optional env     [Function]

(2) Add individual accessor functions for each declaration:

    VARIABLE-DECLARED-IGNORE name &optional env	 [Function]
    FUNCTION-DECLARED-INLINE name &optional env  [Function]
    OPTIMIZE-LEVEL quality &optional env	 [Function]

(3) Merge VARIABLE-KIND, VARIABLE-TYPE, and VARIABLE-DECLARED-IGNORE
    into a single function, VARIABLE-INFORMATION, that returns
    four values:
    
    - what the current proposal says VARIABLE-KIND returns.
    - a local-p boolean to indicate whether the binding is local or global
    - a type specifier as for VARIABLE-TYPE
    - an ignore-p boolean to indicate whether the variable has been
      declared IGNORE.

   Similarly, FUNCTION-KIND, FUNCTION-FTYPE, and FUNCTION-DECLARED-INLINE
   would be merged into FUNCTION-INFORMATION.

   Add the OPTIMIZE-LEVEL function.

Personally, I like option #3 best.  How about the rest of you?

-Sandra
-------

∂18-Mar-89  1608	CL-Compiler-mailer 	**DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)    
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 18 Mar 89  16:08:49 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
	Sat, 18 Mar 89 18:07:36 CST id AA02568 for cl-compiler@sail.stanford.edu
Posted-Date: Sat, 18 Mar 89 18:05:47 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
	id AA20237; Sat, 18 Mar 89 18:05:47 CST
Date: Sat, 18 Mar 89 18:05:47 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903190005.AA20237@pavo.src.honeywell.com>
To: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 13 Mar 89 17:19:48 -0700 <8903140019.AA02631@defun.utah.edu>
Subject: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)

I initially was going to ask if ENVIRONMENT-REMOTE-P shouldn't be called
REMOTE-ENVIRONEMENT-P

     ENVIRONMENT-REMOTE-P env					[Function]

      Returns true if ENV is a remote environment, false otherwise.

Shouldn't ENVIRONMENT-REMOTE-P be called REMOTE-ENVIRONEMENT-P?  Is it
required that the argument be an environment?

On a related note, there is no requirement that environments have a type
specifier (and consequently the disjointedness of that type), nor a
predicate ENVIRONMENT-P.  I assume this is because it would be nice if it
were possible to implement environments as alists.  I guess I don't have an
objection to that, but the possibility of the type not being disjoint
from any other CL type should be mentioned.  If this is already stated in
CLtL, then please ignore this comment (I'll check when I get to work).

∂19-Mar-89  1346	CL-Compiler-mailer 	Re:  issue SYNTACTIC-ENVIRONMENT-ACCESS 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 19 Mar 89  13:46:10 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
	id AA19051; Sun, 19 Mar 89 13:46:49 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.1)
	id AA25776; Sun, 19 Mar 89 13:43:00 PST
Received: by clam.sun.com (4.0/SMI-4.0)
	id AA12450; Sun, 19 Mar 89 13:46:38 PST
Date: Sun, 19 Mar 89 13:46:38 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903192146.AA12450@clam.sun.com>
To: cl-compiler@sail.stanford.edu, sandra%defun@cs.utah.edu
Subject: Re:  issue SYNTACTIC-ENVIRONMENT-ACCESS
Cc: masinter.pa@xerox.com, moon@stony-brook.scrc.symbolics.com

> * We need some way to access other kinds of declarations, particularly
>   INLINE/NOTINLINE, IGNORE, and OPTIMIZE.
> 
> I see three possible solutions to this:
> 
> (1) Add a DECLARATION function:
> 
> (2) Add individual accessor functions for each declaration:
> 
> (3) Merge VARIABLE-KIND, VARIABLE-TYPE, and VARIABLE-DECLARED-IGNORE
>     into a single function, VARIABLE-INFORMATION, that returns
>     four values:

The language permits implementation-dependent declaration types,
so I think we want to define accessors that can also be extended
by implementations.

Solution (2) already has the appearance of suffering from
profusion of names.

(1) is very general, but may require multiple requests to get
the information of interest.

(3) gets a predefined set of information in one operation.

Given what I understand of this issue, I somewhat prefer (1), especially
because it is so easily extended.

(3) looks acceptable also, but I think we would want to explicitly
permit implementations to add more return values to return information
about implementation-dependent declarations.

∂19-Mar-89  1655	CL-Compiler-mailer 	issue CONSTANT-COMPILABLE-TYPES, version 8   
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 19 Mar 89  16:55:14 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
	Sun, 19 Mar 89 18:21:09 CST id AA13098 for cl-compiler@sail.stanford.edu
Posted-Date: Sun, 19 Mar 89 18:19:20 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
	id AA21032; Sun, 19 Mar 89 18:19:20 CST
Date: Sun, 19 Mar 89 18:19:20 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903200019.AA21032@pavo.src.honeywell.com>
To: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 13 Mar 89 09:12:49 -0700 <8903131612.AA02083@defun.utah.edu>
Subject: issue CONSTANT-COMPILABLE-TYPES, version 8

    Some types such as streams are not supported in constants.  Put
    another way, an object containing one of these is not considered
    similar as a constant to any other object.  Some implementations may
    support them and define how they are treated.  For any object that
    appears in a constant, but is not supported by the language as part of
    a constant, the behavior of the compiler is unspecified; either the
    the compiler and/or loader will handle that constant (in an
    implementation-dependent manner) or the compiler will detect the
    situation and signal an error.

The part about "...is unspecified; either..." is somewhat confusing to me.
Is the intent of this to say that it will either "work", or an error will
be signalled at compile time?  I.e. it is illegal for the system to signal
an error at load time, or for the error to go unsignalled?  The
unspecified, harmless, undefined stuff is rapidly becomming a tar pit...

    Number

      If either of the two objects is a number, both must be of the same
      type and must represent the same mathematical value.

For Number and Character is there some reason why you don't use CL
functions in the definitions of similar as constants, e.g. "Numbers are
similar as constants iff they are EQL"?

	     Consider a hash table as an unordered set of key and
	     value pairs.  Two hash tables are similar as constants
	     exactly if there is a one-to-one correspondence between
	     the key and value pairs of each and a one-to-one
	     correspondence between the uninterned symbols ...

Where did the symbols come from?

∂19-Mar-89  2019	CL-Compiler-mailer 	issue LOAD-TIME-EVAL, version 11   
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 19 Mar 89  20:19:21 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
	Sun, 19 Mar 89 22:20:07 CST id AA14552 for cl-compiler@sail.stanford.edu
Posted-Date: Sun, 19 Mar 89 22:18:17 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
	id AA21128; Sun, 19 Mar 89 22:18:17 CST
Date: Sun, 19 Mar 89 22:18:17 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903200418.AA21128@pavo.src.honeywell.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 14 Mar 89 20:02 EST <19890315010205.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: issue LOAD-TIME-EVAL, version 11

    |  If the same (compared with EQ) list (LOAD-TIME-VALUE <form>) is
    |  evaluated or compiled more than once, it is unspecified whether <form>
    |  is evaluated only once or is evaluated more than once.  This can

I find myself strongly opposed to **3.  Given:

  (defun foo ()
    (macrolet ((bar () '(load-time-value (make-instance 'mumble))))
      (list (bar) (bar))))

  (defun foo1 ()
    (list (load-time-value (make-instance 'mumble))
          (load-time-value (make-instance 'mumble))))

I find that I would have a hard time explaining to someone why the value of
foo can be a list of two objects EQ to one another, but that foo1 is
gauranteed to return non EQ objects.  After they grasp that, the next
question is bound to be "Does that mean that in the following example N may
only be incremented by 1?"

  (defun baz (N)
    (macrolet ((bar () '(incf n)))
      (bar)
      (bar)))

I've had a hard enough time explaining why

  (let ((x '(a b c)))
    (eq (eval `(quote ,x))
        (eval `(quote ,x))))

should be permitted to return NIL.  My argument has been something like
"The identity of the conses that make up a program shouldn't be significant
to the value of the program".  Proposal **3 sort of shoots down that
argument.  

I appologize for not being able to put this in the form of a rational
argument, perhaps I will by the meeting.  The added semantic complexity
introduced by **3 just doesn't seam worth it.

∂20-Mar-89  0805	CL-Compiler-mailer 	Re: issue LOAD-TIME-EVAL, version 11    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Mar 89  08:04:52 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA10755; Mon, 20 Mar 89 09:04:10 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA09790; Mon, 20 Mar 89 09:03:46 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903201603.AA09790@defun.utah.edu>
Date: Mon, 20 Mar 89 09:03:45 MST
Subject: Re: issue LOAD-TIME-EVAL, version 11
To: alarson@src.honeywell.com (Aaron Larson)
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-compiler@sail.stanford.edu
In-Reply-To: alarson@src.honeywell.com (Aaron Larson), Sun, 19 Mar 89 22:18:17 CST

> Date: Sun, 19 Mar 89 22:18:17 CST
> From: alarson@src.honeywell.com (Aaron Larson)
> 
> My argument has been something like
> "The identity of the conses that make up a program shouldn't be significant
> to the value of the program".  Proposal **3 sort of shoots down that
> argument.  

The objection that was raised to proposal **2 was that the notion of
"references" to LOAD-TIME-VALUE forms was not well-defined.  The one
example that was raised that bothered me the most was something like

  (flet ((foo () (load-time-value (bar))))
    (declare (inline foo))
    (list (foo) (foo)))

Intuitively, there's only one reference to the LOAD-TIME-VALUE
expression, but if the compiler does the obvious transformation to
code FOO inline, you've suddenly got two references.

Basically, what proposal **3 does is avoid this whole problem by
putting the burden on programmers to be very careful about potential
sharing of LOAD-TIME-VALUE expressions.  (It's really only a problem
for ones that are non-read-only.) There are some of us who feel kind
of uncomfortable about this, but it seemed like trying to come up with
a formal definition of what a unique reference to a LOAD-TIME-VALUE
form meant would open up an even bigger can of worms.

-Sandra
-------

∂20-Mar-89  0816	CL-Compiler-mailer 	Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Mar 89  08:15:52 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA11458; Mon, 20 Mar 89 09:15:44 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA09814; Mon, 20 Mar 89 09:15:42 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903201615.AA09814@defun.utah.edu>
Date: Mon, 20 Mar 89 09:15:40 MST
Subject: Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
To: alarson@src.honeywell.com (Aaron Larson)
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: alarson@src.honeywell.com (Aaron Larson), Sat, 18 Mar 89 18:05:47 CST

I think there is now a consensus in the compiler committee that the
concept of remote environments is not yet ready to be standardized, so
proposals MEDIUM and LARGE will probably go away in the next
iteration.

As far as I can discover, CLtL doesn't say anything about the
representation of environments, and I don't want this issue to add any
restrictions.  One popular representation appears to be as a list of
structures. 

-Sandra
-------

∂20-Mar-89  0922	CL-Compiler-mailer 	Re:  issue SYNTACTIC-ENVIRONMENT-ACCESS 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Mar 89  09:22:09 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA13532; Mon, 20 Mar 89 10:22:04 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA09869; Mon, 20 Mar 89 10:21:48 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903201721.AA09869@defun.utah.edu>
Date: Mon, 20 Mar 89 10:21:47 MST
Subject: Re:  issue SYNTACTIC-ENVIRONMENT-ACCESS
To: cperdue@Sun.COM (Cris Perdue)
Cc: cl-compiler@sail.stanford.edu, masinter.pa@xerox.com,
        moon@stony-brook.scrc.symbolics.com
In-Reply-To: cperdue@Sun.COM (Cris Perdue), Sun, 19 Mar 89 13:46:38 PST

The problem I have with option 1 (adding a DECLARATION function to
access declarations) is that declarations don't have a regular syntax,
and that "decl-type" and "name" arguments might not be appropriate for
expressing the syntax of implementation-specific declarations.  For
example, several implementations support declarations that control
global attributes (like downward-only closures or suppressing style
warnings) that aren't associated with any "name".  Even more peculiar
would be something like the declaration Lucid supports that lets you
say that any objects of a given type really belong to a more specific
type (such as that all numbers will be fixnums).

-Sandra
-------

∂20-Mar-89  1056	CL-Compiler-mailer 	Re:  issue SYNTACTIC-ENVIRONMENT-ACCESS 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Mar 89  10:56:00 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA18614; Mon, 20 Mar 89 11:55:55 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA09943; Mon, 20 Mar 89 11:55:44 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903201855.AA09943@defun.utah.edu>
Date: Mon, 20 Mar 89 11:55:43 MST
Subject: Re:  issue SYNTACTIC-ENVIRONMENT-ACCESS
To: cperdue@Sun.COM (Cris Perdue)
Cc: cl-compiler@sail.stanford.edu, masinter.pa@xerox.com,
        moon@stony-brook.scrc.symbolics.com
In-Reply-To: cperdue@Sun.COM (Cris Perdue), Mon, 20 Mar 89 10:49:15 PST

I think I would rather have implementations provide their own
non-portable accessors for their non-portable declarations, than to
allow VARIABLE-INFORMATION and FUNCTION-INFORMATION to be extended to
return extra values.  I don't have really strong feelings about this,
however.  Are there any other functions that explicitly allow extra
values to be returned?

-Sandra
-------

∂20-Mar-89  1228	CL-Compiler-mailer 	Re: cl-compiler subcommittee meeting & agenda     
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 20 Mar 89  12:28:21 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
	id AA00941; Mon, 20 Mar 89 12:05:25 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA01346; Mon, 20 Mar 89 09:56:58 EST
Message-Id: <8903201456.AA01346@mist.>
To: "sandra%defun@cs.utah.edu"@multimax.encore.com (Sandra J Loosemore)
Cc: cl-compiler@sail.stanford.edu
Subject: Re: cl-compiler subcommittee meeting & agenda 
In-Reply-To: Your message of Fri, 17 Mar 89 18:26:33 -0700.
             <8903180126.AA07442@defun.utah.edu> 
Date: Mon, 20 Mar 89 09:56:55 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    It looks like I am also going to get sucked into the editorial
    committee meeting Monday night.  How would people feel about meeting
    for an hour or so Tuesday morning, before the official meeting starts
    (scheduled for 9:00)?  If anybody has serious problems with being awake
    at that time of morning we could try to arrange something Tuesday 
    evening, but my guess is it'll be harder to find a place to meet then.
    
I can probably manage to be physically present at an early meeting,
but won't be mentally there.  On the other hand, it may not matter
much since I'm not a prime mover on any of the current hot issues.

                                            dan

∂20-Mar-89  1240	CL-Compiler-mailer 	Re:  issue SYNTACTIC-ENVIRONMENT-ACCESS 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89  12:40:27 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
	id AA02507; Mon, 20 Mar 89 11:04:34 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.1)
	id AA15128; Mon, 20 Mar 89 11:00:32 PST
Received: by clam.sun.com (4.0/SMI-4.0)
	id AA02685; Mon, 20 Mar 89 11:04:07 PST
Date: Mon, 20 Mar 89 11:04:07 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903201904.AA02685@clam.sun.com>
To: cperdue@Sun.COM, sandra%defun@cs.utah.edu
Subject: Re:  issue SYNTACTIC-ENVIRONMENT-ACCESS
Cc: cl-compiler@sail.stanford.edu, masinter.pa@xerox.com,
        moon@stony-brook.scrc.symbolics.com

> I think I would rather have implementations provide their own
> non-portable accessors for their non-portable declarations, than to
> allow VARIABLE-INFORMATION and FUNCTION-INFORMATION to be extended to
> return extra values.  I don't have really strong feelings about this,
> however.  Are there any other functions that explicitly allow extra
> values to be returned?

I believe Moon has proposed that certain functions be allowed
to return implementation-dependent extra values.

				-Cris
 

∂20-Mar-89  1240	CL-Compiler-mailer 	Re:  issue SYNTACTIC-ENVIRONMENT-ACCESS 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89  12:38:32 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
	id AA02156; Mon, 20 Mar 89 10:49:34 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.1)
	id AA14068; Mon, 20 Mar 89 10:45:37 PST
Received: by clam.sun.com (4.0/SMI-4.0)
	id AA02660; Mon, 20 Mar 89 10:49:15 PST
Date: Mon, 20 Mar 89 10:49:15 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903201849.AA02660@clam.sun.com>
To: cperdue@Sun.COM, sandra%defun@cs.utah.edu
Subject: Re:  issue SYNTACTIC-ENVIRONMENT-ACCESS
Cc: cl-compiler@sail.stanford.edu, masinter.pa@xerox.com,
        moon@stony-brook.scrc.symbolics.com

Regarding your objections to option 1, it is true that not
all declaration specifiers must affect a particular "name".

What is your attitude toward allowing implementations to extend
the number of return values of VARIABLE-INFORMATION?

It would be unfortunate if we define SYNTACTIC-ENVIRONMENT-ACCESS
but don't make it as general as the declaration facilities
of Common Lisp.

The existence of the "declaration" declaration specifier
(CLtL p160) implies that the set of declaration specifier
names is extensible.  On page 161 there is even reference to
declarations "meant for another compiler or program processor",
so declarations could exist for processors that aren't even
compilers.

I would certainly still vote for a proposal that makes it
possible for implementations to return extra values from
VARIABLE-INFORMATION -- and FUNCTION-INFORMATION.

				-Cris

∂20-Mar-89  1252	CL-Compiler-mailer 	issue LOAD-TIME-EVAL, version 11   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89  12:51:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561221; Mon 20-Mar-89 15:46:26 EST
Date: Mon, 20 Mar 89 15:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue LOAD-TIME-EVAL, version 11
To: Aaron Larson <alarson@src.honeywell.com>
cc: cl-compiler@SAIL.STANFORD.EDU
In-Reply-To: <8903200418.AA21128@pavo.src.honeywell.com>
Message-ID: <19890320204610.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sun, 19 Mar 89 22:18:17 CST
    From: alarson@src.honeywell.com (Aaron Larson)

    I find myself strongly opposed to **3.

Read Sandra's answer first.

The problem is that the **2 proposal is not well specified and thus
cannot be implemented, or will require the implementor to make arbitrary
decisions that will probably come out different ways for different
implementations.

Thus I think it's incumbent on anyone who opposes **3 to propose an
alternative, and I think just going back to **2 is not a viable
alternative.

∂20-Mar-89  1315	CL-Compiler-mailer 	Re: Issue CONSTANT-COMPILABLE-TYPES, version 7    
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 20 Mar 89  13:15:09 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa08016; 20 Mar 89 19:00 GMT
Date: Mon, 20 Mar 89 19:00:20 GMT
Message-Id: <8080.8903201900@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue CONSTANT-COMPILABLE-TYPES, version 7
To: "Richard P. Gabriel" <@sail.stanford.edu:rpg@lucid.com>, 
    cl-compiler@sail.stanford.edu
In-Reply-To: Richard P. Gabriel's message of Sat, 11 Mar 89 16:09:56 PST

> I guess I pretty strongly object to leaving functions out of the list
> of constants that can appear in compiled code. The part that's
> disturbing is that such non-Lispy things like arrays, hashtables, and
> pathnames get better treatment than functions, the most Lispy part of
> Common Lisp.

I'd like to be able to dump functions, but some Common Lisps will
find it difficult to dump arbitrary compiled functions.  Dumping
names would be OK.

Arrays get better treatment because they have convenient printed
representations.  I suppose disassemble might be used...

> I wonder how many implementations will be forced to come within an
> inch of the required functionality to implement a first-rate CLOS?

But we don't require that implementations of CLOS be first-rate.

∂20-Mar-89  1315	CL-Compiler-mailer 	issue COMPILER-VERBOSITY, version 6
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 20 Mar 89  13:15:01 PST
Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa07991; 20 Mar 89 18:58 GMT
Received: from xenakis by mordell.maths.bath.AC.UK id aa19210;
          20 Mar 89 18:59 GMT
To: masinter.pa@xerox.com
CC: cl-compiler@sail.stanford.edu, x3J13@sail.stanford.edu
In-reply-to: masinter.pa@com.xerox's message of 16 Mar 89 05:47 PST <890316-054837-3596@Xerox>
Subject: issue COMPILER-VERBOSITY, version 6
Date: Mon, 20 Mar 89 19:02:07 GMT
From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
Sender: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK

b

∂20-Mar-89  1321	CL-Compiler-mailer 	issue SYNTACTIC-ENVIRONMENT-ACCESS 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89  13:20:56 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561266; Mon 20-Mar-89 16:19:11 EST
Date: Mon, 20 Mar 89 16:18 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue SYNTACTIC-ENVIRONMENT-ACCESS
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Cris Perdue <cperdue@Sun.COM>
cc: cl-compiler@SAIL.STANFORD.EDU, masinter.pa@XEROX.COM
In-Reply-To: <8903181706.AA08173@defun.utah.edu>,
             <8903192146.AA12450@clam.sun.com>,
             <8903201721.AA09869@defun.utah.edu>,
             <8903201849.AA02660@clam.sun.com>,
             <8903201855.AA09943@defun.utah.edu>,
             <8903201904.AA02685@clam.sun.com>
Message-ID: <19890320211858.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

I wasn't sure if you expected to hear from me again on this one,
but just in case you did, here are a few brief comments.

    Date: Sat, 18 Mar 89 10:06:16 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    Let's try to reach closure on this issue so I can get another draft
    circulated before the meeting.  Here is a summary of what I think has
    happened since the last version was mailed out....

All agreed.

    The remaining issue is still troublesome:

    * We need some way to access other kinds of declarations, particularly
      INLINE/NOTINLINE, IGNORE, and OPTIMIZE.

    I see three possible solutions to this:

    (1) Add a DECLARATION function:

	DECLARATION decl-type name &optional env     [Function]

    (2) Add individual accessor functions for each declaration:

	VARIABLE-DECLARED-IGNORE name &optional env	 [Function]
	FUNCTION-DECLARED-INLINE name &optional env  [Function]
	OPTIMIZE-LEVEL quality &optional env	 [Function]

    (3) Merge VARIABLE-KIND, VARIABLE-TYPE, and VARIABLE-DECLARED-IGNORE
	into a single function, VARIABLE-INFORMATION, that returns
	four values:
    
	- what the current proposal says VARIABLE-KIND returns.
	- a local-p boolean to indicate whether the binding is local or global
	- a type specifier as for VARIABLE-TYPE
	- an ignore-p boolean to indicate whether the variable has been
	  declared IGNORE.

       Similarly, FUNCTION-KIND, FUNCTION-FTYPE, and FUNCTION-DECLARED-INLINE
       would be merged into FUNCTION-INFORMATION.

       Add the OPTIMIZE-LEVEL function.

    Personally, I like option #3 best.  How about the rest of you?

I think the VARIABLE-INFORMATION and FUNCTION-INFORMATION parts of
option #3, combined with some form of option #1 for the other
declarations would suit me best.  If we have to, deciding that
declarations in general are too hard and just putting something
special in for OPTIMIZE would be acceptable, but not as nice.

I checked CLtL and the word is "declaration specifier" rather than
"declaration type" or "declaration kind".  I should have checked
CLtL before I first proposed the DECLARATION function, sorry.

    Date: Sun, 19 Mar 89 13:46:38 PST
    From: cperdue@Sun.COM (Cris Perdue)

    The language permits implementation-dependent declaration types,
    so I think we want to define accessors that can also be extended
    by implementations.

But the language also permits user-defined declaration specifiers via
the DECLARATION proclamation, and if this is to be real the user (not
the implementation) should be able to define declaration accessors.  The
simplest answer is to say that's too far-out and we're not going to
standardize it now.  The most comprehensive answer is some kind of
DEFDECLARATION that allows user control over the parsing, scoping, and
indexing of declarations, powerful enough so all the built-in
declaration specifiers could have been defined with it.  An
intermediate position would be just enough to handle the miscellaneous
declarations seen in current practice, but not general enough to take
over from e.g. VARIABLE-INFORMATION.  See suggestion below.

If done right, this will be another way to replace COMPILER-LET.
That is, information from an outer macro can be passed down to
an inner macro by encoding it in a declaration of a user-defined
declaration specifier.

    ....I think we would want to explicitly
    permit implementations to add more return values to return information
    about implementation-dependent declarations.

Agreed.  That can be done with the stroke of a pen.

    Date: Mon, 20 Mar 89 10:21:47 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    The problem I have with option 1 (adding a DECLARATION function to
    access declarations) is that declarations don't have a regular syntax,
    and that "decl-type" and "name" arguments might not be appropriate for
    expressing the syntax of implementation-specific declarations.  For
    example, several implementations support declarations that control
    global attributes (like downward-only closures or suppressing style
    warnings) that aren't associated with any "name".  

These are easy, the name can just be ignored for these declaration
specifiers.  But see suggestion below.

						       Even more peculiar
    would be something like the declaration Lucid supports that lets you
    say that any objects of a given type really belong to a more specific
    type (such as that all numbers will be fixnums).

This is more interesting; the "given type" can be the name, but maybe the
declaration lookup has to use the (nonexistent) function EQUAL-TYPEP
to compare the name for this declaration specifier?

Another approach would be for (DECLARATION declaration-specifier env)
to return a list of all decl-specs currently in force with the symbol
declaration-specifier in their car, sorted so the innermost declaration
is first on the list.  It's then up to the caller to parse this in
whatever way is appropriate for the particular declaration-specifier.
This is crude but makes it possible to get the job done.  Also this
should say that the results are unspecified (-not- undefined!) if
declaration-specifier is any built-in declaration-specifier other
than OPTIMIZE, so that implementations don't have to be able to
reproduce things like type declarations in their original form.
For implementation-dependent declaration-specifiers, require that
either DECLARATION works or the implementation provides an accessor
that is specialized for that declaration-specifier.

∂20-Mar-89  1327	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS  
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 20 Mar 89  13:26:56 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
	id AA03768; Mon, 20 Mar 89 16:06:14 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA01717; Mon, 20 Mar 89 16:08:04 EST
Message-Id: <8903202108.AA01717@mist.>
To: "sandra%defun@cs.utah.edu"@multimax.encore.com (Sandra J Loosemore)
Cc: cl-compiler@sail.stanford.edu
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS 
In-Reply-To: Your message of Sat, 18 Mar 89 10:06:16 -0700.
             <8903181706.AA08173@defun.utah.edu> 
Date: Mon, 20 Mar 89 16:07:55 EST
From: Dan L. Pierson <pierson@mist.encore.com>

I like option #3 too.  Among other things, the addition of NTH-VALUE
makes the other functions easy to derive if you want them, e.g.:

    (DEFUN VARIABLE-TYPE (FOO)
       (DECLARE (INLINE VARIABLE-TYPE))
       (NTH-VALUE 2 (VARIABLE-KIND FOO)))

∂20-Mar-89  1325	CL-Cleanup-mailer 	Re: Issue: LOAD-OBJECTS (Version 3) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89  13:24:54 PST
Received: from Semillon.ms by ArpaGateway.ms ; 20 MAR 89 13:17:33 PST
Date: 20 Mar 89 13:16 PST
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Sat, 18 Mar 89 01:50 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Richard P. Gabriel
 <rpg@lucid.com>, CL-Cleanup@sail.stanford.edu,
 CL-Compiler@sail.stanford.edu, Common-Lisp-Object-System@sail.stanford.edu
Message-ID: <890320-131733-6488@Xerox>

   MAKE-LOAD-FORM-USING-SLOTS is too easy to confuse with
   SLOT-VALUE-USING-CLASS.  MAKE-LOAD-FORM-FROM-SLOTS is better,
   except for form/from dyslexia.  MAKE-LOAD-FORM-FOR-SLOTS ?

How about MAKE-LOAD-FORM-SAVING-SLOTS

  danny

∂20-Mar-89  1340	CL-Compiler-mailer 	Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89  13:40:11 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561297; Mon 20-Mar-89 16:39:20 EST
Date: Mon, 20 Mar 89 16:39 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@SAIL.STANFORD.EDU
In-Reply-To: <8903151840.AA04690@defun.utah.edu>
Message-ID: <19890320213910.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 15 Mar 89 11:40:35 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    > Date: Wed, 15 Mar 89 12:10 EST
    > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    > 
    > Not if you have DESTRUCTURING-BIND.  But I guess that hasn't been
    > accepted into the language yet.

    Is there a cleanup proposal afoot to add this?  I don't remember seeing
    this on the list Larry distributed at the last meeting.  

It's a new issue:

!* DESTRUCTURING-BIND
Version 2, 25-Jan-89, Released 16-Mar-89
Synopsis: add DESTRUCTURING-BIND macro
Status: might need new version before vote

==================================================

    >   PARSE-MACRO name lambda-list body &optional env		[Function]
    > 
    >   Processes the lambda-list in the same way that DEFMACRO and MACROLET do.
    >   Returns a lambda-expression that accepts two arguments (form and env)
    >   and returns the macro expansion.

    If this function doesn't actually do any evaluation to construct a
    real function, is it really necessary to have it accept an environment
    argument?

It used to need it in case it had to expand macros in the body to see if
they were declarations, but we got rid of that feature.  I think it
might need it in some implementations to expand macros in order to do
code analysis on initialization forms for optional/keyword/auxiliary
variables in the lambda-list.  I think it's always better to give an
environment argument to functions like this; in principle a form has no
meaning except in the context of an environment, and any function that
takes a form, or something containing forms, as an argument should take
an environment as an argument also.  This would be more obvious if the
null lexical environment contained nothing, rather than containing the
bulk of the language.

==================================================

    Also, a long time ago we passed a cleanup issue saying that the body
    of a macro definition established with MACROLET or DEFMACRO has an
    implicit BLOCK around it.  Unless you want the "body" argument to
    already include the BLOCK, you need the "name" argument for this
    purpose.  Let's be explicit about it, one way or the other.

You're right, I forgot this.  PARSE-MACRO should definitely put in
the BLOCK.

==================================================

I didn't see any mail follow-up on this idea:

  Symbolics Genera includes an undocumented internal macro, used
  quite a bit in the implementation of the interpreter and code
  analyzers, that could have been called WITH-AUGMENTED-ENVIRONMENT,
  taking keywords like AUGMENT-ENVIRONMENT and also body forms,
  and producing an environment with dynamic extent bound to a
  variable within the body forms.  Would it be useful to have this
  too, or instead of AUGMENT-ENVIRONMENT?  I'm unsure.

I wasn't able to think of any applications for AUGMENT-ENVIRONMENT
that would not be happy using WITH-AUGMENTED-ENVIRONMENT instead.
That certainly does not prove that there aren't any.

==================================================

    > The possible interpreter implementation of COMPILER-LET I mentioned
    > in another message earlier today would seem to require another
    > keyword argument to AUGMENT-ENVIRONMENT.  Does this mean that we
    > have to dictate some particular interpreter implementation of
    > COMPILER-LET?  I'm unsure.
    
    I believe so.  It wouldn't work for a user codewalker to bind
    COMPILER-LET variables specially before walking the body, if
    MACROEXPAND-1 is going to look in the environment for variables to
    bind.  (It may mistakenly bind a variable in an outer contour that is
    supposed to be shadowed by one the codewalker bound.)  And it wouldn't
    work for code walkers just to add the bindings to the environment if
    MACROEXPAND-1 doesn't look for them. 
    
    Do you really want to go ahead with this idea?  At the very least, I
    think it would have to be presented as a separate proposal from
    COMPILER-LET-CONFUSION:REPAIR, instead of just suggested as a way to
    implement that proposal. 

This should be followed up.  I guess a separate proposal is a good idea.
I think COMPILER-LET-CONFUSION:REPAIR should be split into four proposals.
First, one that gives the general framework for repairing but doesn't
say anything about how the interpreter implements COMPILER-LET, other
than to say that an additional proposal is needed to cover that.  Then
three proposals for how the interpreter implements COMPILER-LET:
 (1) The interpreter always does a "semantic pre-pass" like the compiler.
 (2) The interpreter expands all macros inside COMPILER-LET before
 evaluating any of the code inside COMPILER-LET.
 (3) COMPILER-LET passes the variable bindings to MACROEXPAND-1
 through the lexical environment, and the time when the interpreter
 expands macros is not changed.

∂20-Mar-89  1353	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Mar 89  13:51:21 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA26581; Mon, 20 Mar 89 14:50:04 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA10158; Mon, 20 Mar 89 14:49:56 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903202149.AA10158@defun.utah.edu>
Date: Mon, 20 Mar 89 14:49:55 MST
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
        Cris Perdue <cperdue@Sun.COM>, cl-compiler@SAIL.STANFORD.EDU,
        masinter.pa@XEROX.COM
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 20 Mar 89 16:18 EST

> Date: Mon, 20 Mar 89 16:18 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
> Another approach would be for (DECLARATION declaration-specifier env)
> to return a list of all decl-specs currently in force with the symbol
> declaration-specifier in their car, sorted so the innermost declaration
> is first on the list.  It's then up to the caller to parse this in

Hmmm.  I think this has promise, provided that we either clarify that
for declarations that can be "bound", only those declarations that
apply to lexically visible bindings be returned, or else restrict this
to declarations that can only be "free".  Also, shouldn't this
function also ought to be required to know about the DECLARATION
decl-spec as well as OPTIMIZE?

-Sandra
-------

∂20-Mar-89  1405	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89  14:05:24 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561343; Mon 20-Mar-89 17:03:52 EST
Date: Mon, 20 Mar 89 17:03 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: Cris Perdue <cperdue@Sun.COM>, cl-compiler@SAIL.STANFORD.EDU, masinter.pa@XEROX.COM
In-Reply-To: <8903202149.AA10158@defun.utah.edu>
Message-ID: <19890320220334.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: Mon, 20 Mar 89 14:49:55 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    > Date: Mon, 20 Mar 89 16:18 EST
    > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    > 
    > Another approach would be for (DECLARATION declaration-specifier env)
    > to return a list of all decl-specs currently in force with the symbol
    > declaration-specifier in their car, sorted so the innermost declaration
    > is first on the list.  It's then up to the caller to parse this in

    Hmmm.  I think this has promise, provided that we either clarify that
    for declarations that can be "bound", only those declarations that
    apply to lexically visible bindings be returned, or else restrict this
    to declarations that can only be "free".  

I was restricting DECLARATION to have unspecified results if used with
any of the built-in declaration specifiers that are associated with
variable bindings.  But even without that restriction, I would say
that "currently in force" means "declarations whose scope includes
env" which means that for declarations attached to bindings, the
bindings must be lexically visible.

					      Also, shouldn't this
    function also ought to be required to know about the DECLARATION
    decl-spec as well as OPTIMIZE?

Right.  The documentation on DECLARATION says it can only be used with
PROCLAIM, but it should still be visible here.  All that that restriction
means is that you get the same answer regardless of env.

∂20-Mar-89  1417	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS  
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89  14:17:05 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
	id AA08498; Mon, 20 Mar 89 14:18:50 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.1)
	id AA26637; Mon, 20 Mar 89 14:14:54 PST
Received: by clam.sun.com (4.0/SMI-4.0)
	id AA02927; Mon, 20 Mar 89 14:18:31 PST
Date: Mon, 20 Mar 89 14:18:31 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903202218.AA02927@clam.sun.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS
Cc: cl-compiler@SAIL.STANFORD.EDU, masinter.pa@XEROX.COM

> > Date: Mon, 20 Mar 89 16:18 EST
> > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> > 
> > Another approach would be for (DECLARATION declaration-specifier env)
> > to return a list of all decl-specs currently in force with the symbol
> > declaration-specifier in their car, sorted so the innermost declaration
> > is first on the list.  It's then up to the caller to parse this in
> 
> Hmmm.  I think this has promise, provided that we either clarify that
> for declarations that can be "bound", only those declarations that
> apply to lexically visible bindings be returned, or else restrict this
> to declarations that can only be "free".  Also, shouldn't this
> function also ought to be required to know about the DECLARATION
> decl-spec as well as OPTIMIZE?

VARIABLE-INFORMATION, FUNCTION-INFORMATION, plus an accessor of
the sort you are describing would seem quite satisfactory to me.
I realize there are technical details to be worked out.

				-Cris

∂20-Mar-89  1427	CL-Cleanup-mailer 	Re: Issue: LOAD-OBJECTS (Version 3) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89  14:27:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561368; Mon 20-Mar-89 17:23:27 EST
Date: Mon, 20 Mar 89 17:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
To: Danny Bobrow <Bobrow.pa@XEROX.COM>
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Richard P. Gabriel <rpg@lucid.com>,
    CL-Cleanup@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU
In-Reply-To: <890320-131733-6488@Xerox>
Message-ID: <19890320222313.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 20 Mar 89 13:16 PST
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

       MAKE-LOAD-FORM-USING-SLOTS is too easy to confuse with
       SLOT-VALUE-USING-CLASS.  MAKE-LOAD-FORM-FROM-SLOTS is better,
       except for form/from dyslexia.  MAKE-LOAD-FORM-FOR-SLOTS ?

    How about MAKE-LOAD-FORM-SAVING-SLOTS

I like that name.

∂20-Mar-89  1532	CL-Compiler-mailer 	issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5     
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Mar 89  15:32:04 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA00402; Mon, 20 Mar 89 16:29:22 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA10232; Mon, 20 Mar 89 16:29:15 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903202329.AA10232@defun.utah.edu>
Date: Mon, 20 Mar 89 16:29:12 MST
Subject: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
To: cl-compiler@sail.stanford.edu
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, masinter.pa@XEROX.COM,
        cperdue@Sun.COM
In-Reply-To: cperdue@Sun.COM (Cris Perdue), Mon, 20 Mar 89 14:18:31 PST

OK, here's a new, improved writeup on this issue that incorporates all
the changes we seem to have agreed on.  If this doesn't say what you 
thought it would, let me know.

Forum:		Compiler
Issue:          SYNTACTIC-ENVIRONMENT-ACCESS
References:     CLtL Chapter 8: Macros
                Issue MACRO-FUNCTION-ENVIRONMENT
                Issue GET-SETF-METHOD-ENVIRONMENT
                Issue COMPILE-FILE-ENVIRONMENT
Related Issues: Issue FUNCTION-NAME
		Issue PROCLAIM-LEXICAL
		Issue MACRO-ENVIRONMENT-EXTENT
		Issue DESTRUCTURING-BIND
Category:       ADDITION
Edit history:   Version 1, 2-Oct-88, Eric Benson
                Version 2, 17-Feb-89, Kim A. Barrett
		Version 3, 9-Mar-89, Kim A. Barrett (respond to comments)
		Version 4, 12-Mar-89, Sandra Loosemore (more revisions)
		Version 5, 20-Mar-89, Sandra Loosemore (only proposal SMALL)
Status:         **DRAFT**


Problem description:

 When macro forms are expanded, the expansion function is called with
 two arguments: the form to be expanded, and the environment in which
 the form was found.  The environment argument is of limited utility.
 The only use sanctioned currently is as an argument to MACROEXPAND or
 MACROEXPAND-1 or passed directly as an argument to another macro
 expansion function.  Recent cleanup issues propose to allow it as an
 argument to MACRO-FUNCTION and to GET-SETF-METHOD.

 It is very difficult to write a code walker that can correctly handle
 local macro and function definitions, due to insufficient access to
 the information contained in environments and the inability to
 augment environments with local definitions.


Proposal (SYNTACTIC-ENVIRONMENT-ACCESS:SMALL):

 The following functions provide information about syntactic
 environment objects.  In all of these functions the argument named ENV
 is an environment of the sort received by the &ENVIRONMENT argument to
 a macro or as the environment argument for EVALHOOK.  (It is not
 required that implementations provide a distinguished representation
 for such objects.)  Optional "env" arguments default to NIL, which
 represents the local null lexical environment (containing only global
 definitions and proclamations that are present in the runtime
 environment).  All of these functions should signal an error of type
 TYPE-ERROR if the value of an environment argument is not a syntactic
 environment.

 The accessors VARIABLE-INFORMATION, FUNCTION-INFORMATION, and 
 DECLARATION retrieve information about declarations that are in
 effect in the environment.  Since implementations are permitted to
 ignore declarations (except for SPECIAL declarations), these accessors
 are required only to return information about declarations that were
 explicitly added to the environment using AUGMENT-ENVIRONMENT.
 Implementations are also permitted to canonicalize declarations, so
 the information returned by the accessors may not be identical to
 the information that was passed to AUGMENT-ENVIRONMENT.


 VARIABLE-INFORMATION variable &optional env		[Function]

  This function returns information about the interpretation of the
  symbol VARIABLE when it appears as a variable within the lexical 
  environment ENV.  At least the following four values are returned;
  implementations are permitted to extend this function to return 
  additional values.

  The first value indicates the type of definition or binding which is
  apparent in ENV:

    NIL            There is no apparent definition or binding for variable.
    :SPECIAL       VARIABLE refers to a special variable, either declared 
                   or proclaimed. 
    :LEXICAL       VARIABLE refers to a lexical variable.
    :SYMBOL-MACRO  VARIABLE refers to a SYMBOL-MACROLET binding.
    :CONSTANT      VARIABLE refers to a named constant, defined by
                   DEFCONSTANT.

 [Note: If issue PROCLAIM-LEXICAL passes, then the :LEXICAL result
  will also refer to variables proclaimed lexical.]

  The second value indicates whether there is a local binding of the
  name.  If the name is locally bound, the second value is true.
  Otherwise, NIL is returned.

  The third value is the type specifier associated with the variable
  named by the symbol in the environment.  If no explicit association
  exists, either by PROCLAIM or DECLARE, then the result is the type
  specifier T.  It is permissible for implementations to return a type
  specifier that is equivalent to or a supertype of the one appearing 
  in the original declaration.
  
  The fourth value is true if the variable has been declared IGNORE.
  If no such declaration has been made or the information is not 
  available, NIL is returned.


 FUNCTION-INFORMATION function &optional env		[Function]

  This function returns information about the interpretation of the
  function name FUNCTION when it in a functional position within
  lexical environment ENV.  At least the following four values are
  returned; implementations are permitted to extend this function to
  return additional values.

  The first value indicates the type of definition or binding of
  the function name which is apparent in ENV:

    NIL            There is no apparent definition for FUNCTION.
    :FUNCTION      FUNCTION refers to a function.
    :MACRO         FUNCTION refers to a macro.
    :SPECIAL-FORM  FUNCTION refers to a special form.

  Some function names may refer to both a global macro and a global
  special form.  In such a case, the macro takes precedence, and
  :MACRO is returned as the first value.

  The second value specifies whether the definition is local or
  global.  If local, the second value is true, and it is false when
  the definition is global. 

  The third value is the type specifier associated with the function
  in the environment, or the symbol FUNCTION if there is no functional
  type declaration or proclamation associated with the function.  This
  value might not include all the apparent FTYPE declarations for
  FUNCTION.  It is permissible for implementations to return a type 
  specifier that is equivalent to or a supertype of the one that
  appeared in the original declaration.

  The fourth value is one of the symbols :INLINE, :NOTINLINE, or NIL,
  depending on whether the function has been declared INLINE or NOTINLINE.
  NIL is returned if there are no such declarations present or if the
  information cannot be determined.

  [Note: The use of "function name" rather than "symbol" as the
   description of the function argument is intended to be compatible
   with the various proposals to extend the syntax of function
   specifiers.  If no such change actually occurs then this would only
   refer to symbols.]


 AUGMENT-ENVIRONMENT env &KEY variable
			      symbol-macro
                              function
                              macro
                              declare				[Function]

  This function returns a new environment containing the information
  present in ENV, augmented with the information provided by the keyword
  arguments.  The arguments are supplied as follows:

  :VARIABLE	A list of symbols which shall be visible as bound
		variables in the new environment.  Whether each
		binding is to be interpreted as special or lexical
		depends on SPECIAL declarations recorded in the
		environment or provided in the :DECLARE argument list.

  :SYMBOL-MACRO A list of symbol macro definitions, specified as a
                list of (name definition) lists (that is, in the same
                format as the CADR of a SYMBOL-MACROLET special form).
		The new environment will have local symbol-macro bindings
		of each symbol to the corresponding expansion, so that
		MACROEXPAND will be able to expand them properly.

  :FUNCTION	A list of function names which shall be visible as local
		function bindings in the new environment.

  :MACRO	A list of local macro definitions, specified as a
                list of (name definition) lists.  Each definition must
                be a function of two arguments (a form and an environment).
                The new environment will have local macro bindings of each
		name to the corresponding expander function, which
		will be returned by MACRO-FUNCTION and used by
		MACROEXPAND.

  :DECLARE	A list of decl-specs.  Information about these 
                declarations can be retrieved from the resulting
                environment using the VARIABLE-INFORMATION,
                FUNCTION-INFORMATION, and DECLARATION accessors.

  An error is signalled if any of the symbols naming macros in the
  :SYMBOL-MACRO alist are also included in the :VARIABLE list.
  An error is signalled if any of the names specified as keys in the
  :MACRO alist are also included in the :FUNCTION list.  The consequences
  of destructively modifying the list structure of any of the arguments
  to this function are undefined.

  The extent of the returned environment is the same as the extent of
  the argument environment.  The result may share structure with the
  argument environment, but the argument environment is not modified.

  While an environment argument from EVALHOOK is permitted to be used
  as the environment argument for this function, the reverse is not
  true.  If an attempt is made to use the result of AUGMENT-ENVIRONMENT 
  as the environment argument for EVALHOOK, the consequences are
  undefined.  The environment returned by AUGMENT-ENVIRONMENT may only
  be used for syntactic analysis, ie. the functions specified by this
  proposal and functions such as MACROEXPAND.


 PARSE-MACRO name lambda-list body &optional env	[Function]

  This function is used to process a macro definition in the same way
  as DEFMACRO and MACROLET.  It returns a lambda-expression that accepts
  two arguments (a form and an environment).  The "name", "lambda-list",
  and "body" arguments correspond to the parts of a DEFMACRO or MACROLET
  definition.

  The "lambda-list" argument may include &ENVIRONMENT and &WHOLE.
  The "name" argument is used to enclose the "body" in an implicit
  BLOCK, and may also be used for implementation-dependent purposes
  (such as including the name of the macro in error messages if the
  form does not match the lambda-list).


 DECLARATION decl-spec &optional env     		[Function]

  This function returns a list of declaration-specifiers whose CAR
  is the symbol DECL-SPEC that are in force in the environment ENV,
  sorted so that the innermost declaration is first on the list.

  It is required that this function recognize OPTIMIZE and DECLARATION
  declarations.  The results are unspecified for any other built-in
  declaration-specifier.

  If an implementation has been extended to recognize additional
  declaration specifiers in DECLARE or PROCLAIM, it is required that
  either the DECLARATION function should also recognize those
  declarations, or that the implementation provide an accessor that is
  specialized for that declaration specifier.  Note that if an
  extended declaration specifier may be "bound", this function should
  return only those declarations that apply to the lexically visible
  binding.


Rationale:

  This proposal defines a minimal set of accessors and a constructor
  for environments.

  The PARSE-MACRO function is provided so that users don't have to
  write their own code to destructure macro arguments.  Most
  implementations probably already have a similar internal function.

  Making TYPE and FTYPE declarations optional continues to allow
  implementations the freedom to simply ignore all such declarations.
  The same holds true for other declarations accessed with the
  DECLARATION function.


Examples:

#1:  This example illustrates the first value returned by the function
     VARIABLE-INFORMATION.

  (DEFMACRO KIND-OF-VARIABLE (VAR &ENVIRONMENT ENV)
    `',(VARIABLE-INFORMATION VAR ENV))

  (DEFVAR A)

  (DEFUN TEST ()
    (LET (B)
      (LET (C)
        (DECLARE (SPECIAL C))
        (SYMBOL-MACROLET ((D ANYTHING))
          (LIST (KIND-OF-VARIABLE A)
                (KIND-OF-VARIABLE B)
                (KIND-OF-VARIABLE C)
                (KIND-OF-VARIABLE D)
                (KIND-OF-VARIABLE E))))))

  (TEST) -> (:SPECIAL :LEXICAL :SPECIAL :SYMBOL-MACRO NIL)
      

#2:  This example illustrates the first value returned by the function
     FUNCTION-INFORMATION.

  (DEFMACRO KIND-OF-FUNCTION (FUNCTION-NAME &ENVIRONMENT ENV)
    `',(FUNCTION-INFORMATION FUNCTION-NAME ENV))

  (DEFUN A ())

  (DEFMACRO B ())

  (DEFUN TEST ()
    (FLET ((C ()))
      (MACROLET ((D ()))
        (MULTIPLE-VALUE-CALL #'LIST
              (KIND-OF-FUNCTION A)
              (KIND-OF-FUNCTION B)
              (KIND-OF-FUNCTION QUOTE)
              (KIND-OF-FUNCTION C)
              (KIND-OF-FUNCTION D)
              (KIND-OF-FUNCTION E)))))

  (TEST) -> (:FUNCTION      NIL
             :MACRO         NIL
             :SPECIAL-FORM  NIL
             :FUNCTION      T
             :MACRO         T
             NIL            NIL)


#3:  This example shows how a code-walker might walk a MACROLET special
     form.

(defun walk-macrolet (form env)
    (let ((macros  (make-macro-definitions (cadr form) env)))
	(multiple-value-bind (body decls) (parse-body (cddr form))
	    (walk-implicit-progn
	        body
		(augment-environment env :macro macros :declare decls))
             )))


(defun make-macro-definitions (defs env)
    (let ((results  nil))
	(dolist (d defs)
	    (push (list (car d)
			(coerce (parse-macro (car d) (cadr d) (cddr d) env)
				'function))
		  results))
	results))



Cost to Implementors:

 Most implementations already record some of this information in some
 form.  Providing these functions should not be too difficult, but it
 is a more than trivial amount of work.

Cost to Users:

 This change is upward compatible with user code.

Current practice:

 No implementation provides all of this interface currently.  Portable
 Common Loops defines a subset of this functionality for its code
 walker and implements it on a number of diffent versions of Common
 Lisp.

Discussion:

 The first version of this proposal expressly did not deal with the
 objects which are used as environments by EVALHOOK.  This version is
 extended to support them in the belief that such environments share a
 lot of functionality with the syntactic environments needed by a
 compiler.  While the two types of environments might have very
 different implementations, there are many operations which are
 reasonable to perform on either type, including all of the accessor
 functions described by this proposal.

 AUGMENT-ENVIRONMENT currently requires signaling an error when
 symbol-macro names match variable names in the same call.  This could
 be reduced to "should signal".  By requiring the error signaling, this
 proposal is compatable with Proposal SYMBOL-MACROLET-DECLARE:ALLOW,
 which says

   "... signals an error if a SPECIAL declaration names one of the symbols
   being defined as a symbol-macrolet."

 Maintaining compatability with the SYMBOL-MACROLET-DECLARE proposal
 allows fairly trivial implementations of the SYMBOL-MACROLET
 special-form in terms of the AUGMENT-ENVIRONMENT function.

 Moon notes:

  Symbolics Genera includes an undocumented internal macro, used
  quite a bit in the implementation of the interpreter and code
  analyzers, that could have been called WITH-AUGMENTED-ENVIRONMENT,
  taking keywords like AUGMENT-ENVIRONMENT and also body forms,
  and producing an environment with dynamic extent bound to a
  variable within the body forms.  Would it be useful to have this
  too, or instead of AUGMENT-ENVIRONMENT?  I'm unsure.

 Some people have indicated they think that the :MACRO argument (and
 the :SYMBOL-MACRO argument too?) to AUGMENT-ENVIRONMENT should be an
 a-list of the form (name . definition).
-------

∂20-Mar-89  1612	CL-Compiler-mailer 	issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5     
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Mar 89  16:12:34 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA05421g; Mon, 20 Mar 89 16:05:41 PST
Received: by blacksox id AA00812g; Mon, 20 Mar 89 16:09:38 PST
Date: Mon, 20 Mar 89 16:09:38 PST
From: Eric Benson <eb@lucid.com>
Message-Id: <8903210009.AA00812@blacksox>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu, Moon@STONY-BROOK.SCRC.Symbolics.COM,
        masinter.pa@XEROX.COM, cperdue@Sun.COM
In-Reply-To: Sandra J Loosemore's message of Mon, 20 Mar 89 16:29:12 MST <8903202329.AA10232@defun.utah.edu>
Subject: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 

This doesn't provide a way to distinguish pervasively SPECIAL
(proclaimed) variables from locally SPECIAL (declared) variables.
This is important because new bindings of names which are pervasively
SPECIAL are special bindings, while new bindings of names which are
locally SPECIAL (except those to which the declaration is attached)
are lexical bindings.  This is just the sort of thing a code walker
should do correctly.  I propose that instead of VARIABLE-INFORMATION
returning :SPECIAL as the first value, it should return
:PROCLAIMED-SPECIAL or :DECLARED-SPECIAL.

I would be happier if this difference between SPECIAL proclamations
and SPECIAL declarations were removed.  Does anyone have an opinion on
this?  I guess it's too late for another cleanup issue.

∂20-Mar-89  2032	CL-Compiler-mailer 	issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5     
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89  20:32:04 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561653; Mon 20-Mar-89 23:31:12 EST
Date: Mon, 20 Mar 89 23:30 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
To: Eric Benson <eb@lucid.com>
cc: sandra%defun@cs.utah.edu, cl-compiler@SAIL.STANFORD.EDU, masinter.pa@XEROX.COM,
    cperdue@Sun.COM
In-Reply-To: <8903210009.AA00812@blacksox>
Message-ID: <19890321043051.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: Mon, 20 Mar 89 16:09:38 PST
    From: Eric Benson <eb@lucid.com>

    This doesn't provide a way to distinguish pervasively SPECIAL
    (proclaimed) variables from locally SPECIAL (declared) variables.
    This is important because new bindings of names which are pervasively
    SPECIAL are special bindings, while new bindings of names which are
    locally SPECIAL (except those to which the declaration is attached)
    are lexical bindings.  

Good point.

			   This is just the sort of thing a code walker
    should do correctly.  I propose that instead of VARIABLE-INFORMATION
    returning :SPECIAL as the first value, it should return
    :PROCLAIMED-SPECIAL or :DECLARED-SPECIAL.

If PROCLAIM-LEXICAL passes, the same issue will arise for LEXICAL.  I
suggest that either the global binding type be returned as an additional
value, or that the programmer be reminded that the global binding type
may differ from the local one and can be retrieved by calling
VARIABLE-INFORMATION again with a null lexical environment.

    I would be happier if this difference between SPECIAL proclamations
    and SPECIAL declarations were removed.  Does anyone have an opinion on
    this?  I guess it's too late for another cleanup issue.

Removing that difference would be a disaster, since if you made SPECIAL
proclamations shadowable by bindings there would be no way to express
DEFVAR in terms of other constructs, and if you made SPECIAL
declarations not shadowable by bindings the scoping rules for
declarations would be inconsistent, unless you made all declarations not
shadowable by bindings, in which case (surprise!) you would be back to
the declaration scoping rules of Maclisp and ZetaLisp, which back in
1982 when all this was designed were considered terrible.
Vive la difference!

∂21-Mar-89  0614	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Mar 89  06:14:50 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA12519; Tue, 21 Mar 89 07:14:13 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA10699; Tue, 21 Mar 89 07:14:08 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903211414.AA10699@defun.utah.edu>
Date: Tue, 21 Mar 89 07:14:06 MST
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Eric Benson <eb@lucid.com>, cl-compiler@SAIL.STANFORD.EDU,
        masinter.pa@XEROX.COM, cperdue@Sun.COM
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 20 Mar 89 23:30 EST

Perhaps we could use the (newly added) second return value from
VARIABLE-INFORMATION to tell whether the declaration or definition of
the variable is local or global, instead of whether there is a local
binding of the variable.  That would complicate things a little
though, because the interpretation of the second value would depend on
the first:

First value	Second value
 NIL		 Always NIL
 :SPECIAL        T = declared special, NIL = proclaimed special
 :LEXICAL        T = declared lexical or assumed lexical because of 
 		   local binding, NIL = proclaimed lexical
 :SYMBOL-MACRO   Always T
 :CONSTANT	 Always NIL 

-Sandra
-------

∂21-Mar-89  0738	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 21 Mar 89  07:38:18 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
	id AA08780; Tue, 21 Mar 89 10:38:02 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA02608; Tue, 21 Mar 89 10:39:56 EST
Message-Id: <8903211539.AA02608@mist.>
To: "sandra%defun@cs.utah.edu"@multimax.encore.com (Sandra J Loosemore)
Cc: cl-compiler@SAIL.STANFORD.EDU
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
In-Reply-To: Your message of Tue, 21 Mar 89 07:14:06 -0700.
             <8903211414.AA10699@defun.utah.edu> 
Date: Tue, 21 Mar 89 10:39:53 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    Perhaps we could use the (newly added) second return value from
    VARIABLE-INFORMATION to tell whether the declaration or definition of
    the variable is local or global, instead of whether there is a local
    binding of the variable.  That would complicate things a little
    though, because the interpretation of the second value would depend on
    the first:
    
    First value	Second value
     NIL		 Always NIL
     :SPECIAL        T = declared special, NIL = proclaimed special
     :LEXICAL        T = declared lexical or assumed lexical because of 
     		   local binding, NIL = proclaimed lexical
     :SYMBOL-MACRO   Always T
     :CONSTANT	 Always NIL 
    
Seems reasonable.  I don't think the complication is significant since
what you want to do is likely to change as the first value changes anyway.

∂21-Mar-89  0843	Common-Lisp-Object-System-mailer 	Compile Time Class Creation (was: remote environments)  
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 21 Mar 89  08:42:47 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
	id AA28027; Tue, 21 Mar 89 08:44:46 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.1)
	id AA28469; Tue, 21 Mar 89 08:40:55 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA01870; Tue, 21 Mar 89 08:42:58 PST
Message-Id: <8903211642.AA01870@suntana.sun.com>
To: cl-compiler@sail.stanford.edu, common-lisp-object-system@sail.stanford.edu
Subject: Compile Time Class Creation (was: remote environments)
Date: Tue, 21 Mar 89 08:42:55 PST
From: kempf@Sun.COM


I've just had time to plough through the X3 mail on CLOS and there was
a point lurking in the correspondence on this topic that I think was
never clearly articulated. That point has to do with the role of
class objects in type checking and inference.

If the goal is to enable compiler implementors and extenders to write
type checking and inference code in an object-oriented way, then some
kind of object representing the class must be created at compile time.
The entire class need not be defined. For example, the slot accessor
method certainly don't need to be defined. 

I think the minimum amount of information which needs to be there is the
following:

	-class precedence list-Because the class precedence list is used
	 in subtyping, it must be available to the type checker.

	-slot location (instance, class)-The compiler might be able to
	 optimize slot access based on this.

	-slot type-Again, potentially necessary for slot access.

	-metaclass-Needed for slot access, possibly to optimize instance
	 creation and initialization.

	-interface information for slot access functions-So they can
	 be optimized.

Most compilers currently use list structures for their type checkers, and
it certainly would be possible to disallow compile time creation of
classes for standard-class objects, to simplify things. But to do so
for the metaobject protocol would limit the metaobject protocol in
a way that would be crippling, since the point of the metaobject protocol
is to allow extensibility in the language processing software. 

There are a number of possible decisions. It could be left either 
unintentionally or deliberately ambiguous. It could be specified that
standard-class objects either are created, are partially created, or
are not created at compile time, while leaving open the question for
other metaclasses (since the MOP will probably not be a part of the
official ANSI Common Lisp '89 standard anyway). However, it is important
to understand the effect of these decisions on future evolution and
user extensibility.

		jak



∂21-Mar-89  0911	CL-Compiler-mailer 	issue DEFINE-OPTIMIZER, version 5  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Mar 89  09:11:01 PST
Received: from wheat-chex.ai.mit.edu by life.ai.mit.edu; Tue, 21 Mar 89 12:10:44 EST
Received: from localhost by wheat-chex.ai.mit.edu; Tue, 21 Mar 89 12:10:40 EST
Date: Tue, 21 Mar 89 12:10:40 EST
From: dick@wheaties.ai.mit.edu
Message-Id: <8903211710.AA06262@wheat-chex.ai.mit.edu>
To: cl-compiler@sail.stanford.edu
Cc: cperdue@sun.com, dick@wheaties.ai.mit.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 13 Mar 89 16:31:17
Subject: issue DEFINE-OPTIMIZER, version 5


Cris perdue was kind enough to send a copy of this proposal to me.

I would like to say that I think that compiler optimizers are an
extremely good idea---right up there with the best of the ideas ever
presented to the committee.

I really hate having to make things macros for trivial reasons,
because this blocks you from funcalling them and using them as
arguments to MAPCAR REDUCE etc.  If this mechanism were in Common Lisp
I would use it all the time.  I bet it would cover a significant chunk
of what I use macros for.

To be more specific, there are a number of places where such compiler
optimizers would be of HUGE benefit in my portable implementation of
SERIES.  In particular, they would be an appropriate framework in
which to state the whole thing.  Now, since I have to do it all with
macros, a number of things that should, by every right, be functions
have to be macros instead.  This in fact makes it impossible to make an
implementation of what I really want.

Much as I like the proposal, I think there are a couple of places
where it might be improved.

(1) you might consider having OPTIMIZE-EXPRESSION-1 act like
MACRO-EXPAND-1 when given a macro call.  Or alternatively, have a
function called OPTIMIZE-OR-EXPAND-EXPRESSION-1.  Otherwise, code
walkers are going to have to implement this functionality themselves
since optimizations can expand into macros and vice versa.

(2) The same of course goes for OPTIMIZE-EXPRESSION.

(3)  Perhaps the proposal cannot require an implementation to actually
use the optimizers.  However, it should certainly encourage
compilers to use them in the strongest possible terms.

(4) I agree that things should be kept simple and not get into pattern
matching etc.

(5) I agree with what Barrett says about the interaction of
inline/noinline and optimizers.

In summary, I recommend the inclusion of this idea in the strongest
possible terms.  In particular, although I think the ideas above would
be improvements, I would much rather see the proposal accepted as is
rather than not accepted.

			Dick Waters

∂21-Mar-89  0932	CL-Compiler-mailer 	issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Mar 89  09:32:06 PST
Received: from wheat-chex.ai.mit.edu by life.ai.mit.edu; Tue, 21 Mar 89 12:32:06 EST
Received: from localhost by wheat-chex.ai.mit.edu; Tue, 21 Mar 89 12:32:05 EST
Date: Tue, 21 Mar 89 12:32:05 EST
From: dick@wheaties.ai.mit.edu
Message-Id: <8903211732.AA06334@wheat-chex.ai.mit.edu>
To: cl-compiler@sail.stanford.edu
Cc: cperdue@sun.com, dick@wheaties.ai.mit.edu
In-Reply-To: Sandra J Loosemore's message of Sun Mar 12 10:18:08 1989
Subject: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4


Cris Perdue was kind enough to send a copy of this proposal on to me.

I think that this fills an obvious hole in Common Lisp and should be
adopted.  It would definitely have been useful to me in implementing
my SERIES macro package.  However, I think that there are a couple of problems.

(1) The proposal should say somewhere what happens if an environment
gets returned out of its dynamic context.  In particular, what happens
in the first example if KIND-OF-VARIABLE is defined as follows:

 (DEFMACRO KIND-OF-VARIABLE (VAR &ENVIRONMENT ENV)
    `(VARIABLE-KIND ',VAR ',ENV))

I assume very bad things happen.

(2) I think it is very odd indeed to allow implementations to ignore
type and ftype information and fail to put it in the environment.

(3) I do not understand why we need to have AUGMENT-ENVIRONMENT.
Except for the recently added :declare argument it is completely
redundant with LET, SYMBOL-MACROLET, FLET, and MACROLET.

What is worse, while AUGMENT-ENVIRONMENT fully captures the
functionality of SYMBOL-MACROLET, and MACROLET, it behaves very oddly
with regard to LET and FLET.  In particular, if I understand it right,
it could be used to set things up so that the compiler thought a given
variable was a local varible, but it does nothing to actually create the
variable so things can be stored in it.  What does this even mean?
The same goes for FLET.  What function is going to end up being called
when instances of the given function appear?  Perhaps the compiler is
supposed to be able to work all this out.  If so this needs to be explained.

I would strongly recommend that AUGMENT-ENVIRONMENT be eliminated.
It just is not that hard to have macros expand into the right uses of
let-like forms before recursing to do further processing.  In any
case, it seems that they will have to continue doing that for LET and
FLET even if AUGMENT-ENVIRONMENT is retained.

(4) I agree that things should be kept just to the smallest proposal.


			Dick waters.


∂21-Mar-89  1020	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89  10:19:57 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562040; Tue 21-Mar-89 13:16:45 EST
Date: Tue, 21 Mar 89 13:16 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: Eric Benson <eb@lucid.com>, cl-compiler@SAIL.STANFORD.EDU, masinter.pa@XEROX.COM,
    cperdue@Sun.COM
In-Reply-To: <8903211414.AA10699@defun.utah.edu>
Message-ID: <19890321181630.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: Tue, 21 Mar 89 07:14:06 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    Perhaps we could use the (newly added) second return value from
    VARIABLE-INFORMATION to tell whether the declaration or definition of
    the variable is local or global, instead of whether there is a local
    binding of the variable.  

Losing the information about whether there is a local binding seems
like a bad idea.

∂21-Mar-89  1338	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 21 Mar 89  13:38:30 PST
Received: by ti.com id AA05344; Tue, 21 Mar 89 15:03:35 CST
Received: from Kelvin by tilde id AA23983; Tue, 21 Mar 89 14:50:23 CST
Message-Id: <2815505310-8473304@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 21 Mar 89  14:48:30 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Cc: cl-compiler@sail.stanford.edu, Moon@STONY-BROOK.SCRC.Symbolics.COM,
        cperdue@Sun.COM
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
In-Reply-To: Msg of Mon, 20 Mar 89 16:29:12 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)

>  DECLARATION decl-spec &optional env     		[Function]
> 
>   This function returns a list of declaration-specifiers whose CAR
>   is the symbol DECL-SPEC that are in force in the environment ENV,
>   sorted so that the innermost declaration is first on the list.
> 
>   It is required that this function recognize OPTIMIZE and DECLARATION
>   declarations.  The results are unspecified for any other built-in
>   declaration-specifier.

I'm uneasy about the notion of the notion of returning all the
declarations, innermost first.  First, note that since DECLARATION is only
valid in PROCLAIM, there isn't any lexical ordering.  OPTIMIZE
declarations do have lexical shadowing, but is that really relevant?
Don't you just want to know what the current values are, not all the
history of how they got that way?  For example, given

  (defmacro show-opt (&environment e)
    (print (declaration 'optimize e)))
  (proclaim '(optimize (speed 1)))
  (defun ff (x)
    (declare (optimize (space 2)))
    ...
    (dotimes (i n)
      (declare (optimize speed))
      (show-opt)
      ...) ...)

this specification would lead one to expect the value printed to be

  ((OPTIMIZE SPEED) (OPTIMIZE (SPACE 2)) (OPTIMIZE (SPEED 1)))

It should be valid for an implementation to return, for example:

  ((OPTIMIZE (SAFETY 1) (SPACE 2) (SPEED 3)))

because all the compiler cares about or wants to remember are the current
values.  (Any implementation that really uses OPTIMIZE declarations is
going to want to have a more efficient way of accessing them than searching
through a list.  The same thing applies to a macro that wants to use this
information; requiring them to search a list for what they want would
discourage the use of this feature.)  I think I'd rather see

  (DECLARATION 'OPTIMIZE env) => ((quality value)...)
  (DECLARATION 'DECLARATION env => (symbol symbol ...)

Note that this approach makes it much easier to do something like this:

  (let ((save-opt (declaration 'optimize)))
    (proclaim '(optimize ...)) 
    (compile-file ...)
    (proclaim `(optimize . ,save-opt))) ; restore previous values

>	...	Note that if an
>   extended declaration specifier may be "bound", this function should
>   return only those declarations that apply to the lexically visible
>   binding.

The binding of what?  Probably you mean "... that apply to some binding
which is lexically visible"?  I don't think this is feasible -- if binding
declarations are stored in the variable table entry, then it is not
reasonable to be asked for a list of all of them, while if you use a list
as a stack of declarations, then you don't have an easy way to keep track
of which ones are connected to non-shadowed variables.  Better to say that
the DECLARATION function is only for pervasive declarations.

Also, in regard to binding declarations, instead of just saying that
VARIABLE-INFORMATION can return additional values, how about saying that
the fifth value is a property list of implementation-dependent
declaration keys and values?  That way, extensions developed at different
places could later be mixed together rather than necessarily being
mutually incompatible.

∂21-Mar-89  1344	CL-Compiler-mailer 	issue DEFINING-MACROS-NON-TOP-LEVEL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Mar 89  13:44:21 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA27204; Tue, 21 Mar 89 14:42:29 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA10892; Tue, 21 Mar 89 14:42:14 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903212142.AA10892@defun.utah.edu>
Date: Tue, 21 Mar 89 14:42:12 MST
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL
To: cl-compiler@sail.stanford.edu
Cc: moon@stony-brook.scrc.symbolics.com

Moon and I have exchanged some private mail on this issue that has
turned up something very troublesome.  It has to do with the part of
the proposal that says that macro functions created by DEFMACRO are
evaluated in the lexical environment in which the defining macro
appears, and Moon's suggestion that MACROLET macro functions also be
evaluated in a possibly non-null lexical environment.

The problem is that there isn't a convenient way for code-walkers (and
presumably compilers) to do this, even with our proposal for issue
SYNTACTIC-ENVIRONMENT-ACCESS.  Basically, you would have to do two
code walkers -- one to do a total macroexpansion on the body of macro
functions before coercing it to be a function, and another to do what
you really wanted the code walker to do in the first place.  What's
more, I'm confused about the correctness of simply evaluating the
fully-macroexpanded macro function with EVAL because of the
possibility of the environment containing SPECIAL or LEXICAL
declarations that wouldn't be picked up.

I don't think that going back to the CLtL position that all macro
functions are defined in a null lexical environment is consistent with
our current model of how defining macros work.  Our model says that
DEFMACRO's expansion should include something like
    (function (lambda ...))  
Ensuring that the macro gets defined in a null environment (even if
the DEFMACRO appears in a non-null environment) would mean it would
have to look something like
    (eval (quote (lambda ...)))
which I think we are all pretty much agreed is wrong.

I believe we really have two choices:

(1) Change our definition of top-level back so that top-level implies
    null lexical environment again, and have MACROLET continue to
    evaluate the macros in a null environment.  (The problem of early
    evaluation in a non-null environment would never arise then.)

(2) Require implementations to provide some primitive for causing
    evaluation in a non-null syntactic environment.  (This is required
    now internally anyway in order to support EVAL-WHEN COMPILE
    evaluation.)  One possibility is the ENCLOSE function that has
    been mentioned in connection with the cleanup issue COERCE-INCOMPLETE,
    that takes a lambda expression and a syntactic environment, and
    returns a function.  It would be an error for the lambda
    expression to try to refer to any of the variable or function
    bindings established in the environment.

Unless somebody can convince me that declarations don't really pose a
problem after all, I'm not sure if doing nothing (and requiring users
to do a lot of extra work to handle macro definitions) is a reasonable
alternative.  It certainly tends to defeat the purpose of 
SYNTACTIC-ENVIRONMENT-ACCESS, which was to make it easy to write a
correct code-walker.

Anybody have thoughts on this?

-Sandra
-------

∂21-Mar-89  1522	CL-Compiler-mailer 	issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5     
Received: from RIVERSIDE.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89  15:18:10 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 324891; Tue 21-Mar-89 18:17:17 EST
Date: Tue, 21 Mar 89 18:17 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@SAIL.STANFORD.EDU, masinter.pa@XEROX.COM, cperdue@Sun.COM
In-Reply-To: <8903202329.AA10232@defun.utah.edu>
Message-ID: <19890321231717.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

I like this new version of SYNTACTIC-ENVIRONMENT-ACCESS:SMALL,
except for two minor comments:

 The accessors VARIABLE-INFORMATION, FUNCTION-INFORMATION, and 
 DECLARATION retrieve information about declarations that are in
 effect in the environment.  Since implementations are permitted to
 ignore declarations (except for SPECIAL declarations), these accessors
 are required only to return information about declarations that were
 explicitly added to the environment using AUGMENT-ENVIRONMENT.

I think this is wrong.  Certainly if DECLARATION is to be useful
implementations must not be allowed to discard any of the declarations
it can return.  As someone from an implementation that ignores type
declarations, I can say that I think all implementations should be
required to return all declarations from all three of these functions.
I think implementations should be permitted to ignore declarations
in the sense of the code generated by the compiler not being affected
by declarations, but should not be permitted to just throw declarations
away rather than putting them into the syntactic environment.

DECLARATION should be renamed DECLARATION-INFORMATION to match
with VARIABLE-INFORMATION and FUNCTION-INFORMATION.

∂21-Mar-89  1615	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 21 Mar 89  16:14:20 PST
Received: by ti.com id AA06212; Tue, 21 Mar 89 17:48:48 CST
Received: from Kelvin by tilde id AA27618; Tue, 21 Mar 89 17:36:29 CST
Message-Id: <2815515283-9072478@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 21 Mar 89  17:34:43 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Cc: cl-compiler@sail.stanford.edu, moon@stony-brook.scrc.symbolics.com
Subject: Re: issue DEFINING-MACROS-NON-TOP-LEVEL
In-Reply-To: Msg of Tue, 21 Mar 89 14:42:12 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)

>	...	One possibility is the ENCLOSE function that has
>     been mentioned in connection with the cleanup issue COERCE-INCOMPLETE,
>     that takes a lambda expression and a syntactic environment, and
>     returns a function. 

That sounds like the right answer to me.  I had been wondering earlier
today whether something like that might not be needed in order to
transform the result of PARSE-MACRO into a function object suitable for
use in the :MACRO argument of AUGMENT-ENVIRONMENT.

∂21-Mar-89  1732	CL-Compiler-mailer 	**DRAFT** issue CLOS-MACRO-COMPILATION, version 2 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89  17:32:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562475; Tue 21-Mar-89 20:32:29 EST
Date: Tue, 21 Mar 89 20:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue CLOS-MACRO-COMPILATION, version 2
To: cl-compiler@SAIL.STANFORD.EDU
cc: x3j13@SAIL.STANFORD.EDU
In-Reply-To: <8903132248.AA02496@defun.utah.edu>
Message-ID: <19890322013216.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

I would go with MINIMAL for now.  It leaves a lot of behavior
unspecified, and we can fill in that behavior later when we
add metaobjects to the standard.

Relatively small comments:

The compiler should be allowed to warn, but not error, about
failures of lambda-list congruence between methods or generic
functions in the file being compiled and methods or generic
functions in the Lisp doing the compilation.  When you say
the compiler may not "perform tests" between these, it's not
clear whether you mean to rule out only errors or both errors
and warnings.

The only thing here that might be overspecification is allowing a
DEFINE-METHOD-COMBINATION to be used later in the same compilation.
However, I see no real harm in that, and it would often be 
convenient for programmers, so leave it.  But if someone else
moves to remove it, I will not object.

Evaluation of the form in EQL parameter specializer names in DEFMETHOD
needs to be covered.  I think this is tied up with the pending compiler
committee issue DEFCONSTANT-VALUE (whose version 2 writeup I don't like,
it's too messy).  The choices seem to be to require the form in an EQL
parameter specializer name to be evaluable at compile time, to require
it to depend only on constants defined in the file being compiled, or to
permit its evaluation to be deferred until load time.  I don't like the
first choice.  I think for both DEFCONSTANT and EQL the semantics should
be as if it were never evaluated until load time, with the compiler
allowed to evaluate it sooner only if it can prove that that does not
change the semantics.  I'd be happier if the mechanism the compiler
uses to do this tentative evaluation were made available to the user,
but that can be deferred until metaobjects.

∂21-Mar-89  1832	CL-Compiler-mailer 	Re: **DRAFT** issue CLOS-MACRO-COMPILATION, version 2  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Mar 89  18:32:12 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA08626; Tue, 21 Mar 89 19:32:07 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA11085; Tue, 21 Mar 89 19:32:00 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903220232.AA11085@defun.utah.edu>
Date: Tue, 21 Mar 89 19:31:59 MST
Subject: Re: **DRAFT** issue CLOS-MACRO-COMPILATION, version 2
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 21 Mar 89 20:32 EST

FYI, issue DEFCONSTANT-VALUE is supposed to be dead.  It was originally
intended to amend issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS, but
we ended up amending that issue directly instead.

> I think for both DEFCONSTANT and EQL the semantics should
> be as if it were never evaluated until load time, with the compiler
> allowed to evaluate it sooner only if it can prove that that does not
> change the semantics.

This was what was specified for DEFCONSTANT in the initial incarnation
of COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS, but it seemed like
everybody (except me and possibly Walter) hated it.  If we want to
make DEFCONSTANT less vague than it is now, I think a proposal to
require the initial value form to be evaluated at macroexpand time and
treated as a literal constant in the expansion would probably have
more support.

-Sandra
-------

∂22-Mar-89  0836	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Mar 89  08:36:04 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562893; Wed 22-Mar-89 11:34:39 EST
Date: Wed, 22 Mar 89 11:34 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Moon@STONY-BROOK.SCRC.Symbolics.COM,
    cl-compiler@SAIL.STANFORD.EDU, cperdue@Sun.COM
In-Reply-To: <2815505310-8473304@Kelvin>
Message-ID: <19890322163431.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 21 Mar 89  14:48:30 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    >  DECLARATION decl-spec &optional env     		[Function]

    I'm uneasy about the notion of the notion of returning all the
    declarations, innermost first.  

That was done so that DECLARATION does not have to have specific
knowledge of how to deal with each different decl-spec; instead
the caller has that knowledge.  Otherwise we would have to add
a way for people defining new declarations to tell DECLARATION
how to parse them and how to decide whether an inner one shadows
an outer one.

    First, note that since DECLARATION is only
    valid in PROCLAIM, there isn't any lexical ordering.  

The proposal should say that the order of proclamations is most recent
first.

							  OPTIMIZE
    declarations do have lexical shadowing, but is that really relevant?
    Don't you just want to know what the current values are, not all the
    history of how they got that way?

Of course.  The issue is whether that knowledge, which is specific to
the format of the OPTIMIZE declaration, goes inside of the DECLARATION
function or goes in the caller of the DECLARATION function.

    I think I'd rather see

      (DECLARATION 'OPTIMIZE env) => ((quality value)...)
      (DECLARATION 'DECLARATION env => (symbol symbol ...)

That was what I originally proposed, so I'd rather see it too.  (Except
I also proposed an additional <name> argument, which was the quality for
OPTIMIZE, the decl-spec for DECLARATION, something else for other
declarations, in some cases ignored.)  The problem is that it is not
extensible without designing another mechanism that nobody wanted to
think about right now to tell DECLARATION how to parse the declarations.
Maybe we made a wrong choice here.  Do you want to propose the details
of that mechanism?

    Better to say that
    the DECLARATION function is only for pervasive declarations.

That would be okay with me.  I'm not sure "pervasive" is the correct word,
though; I assume you mean that the DECLARATION function is only for
"declarations that do not concern themselves with variable or function
bindings".

BTW I still think DECLARATION-INFORMATION might be a better name than
DECLARATION.

    Also, in regard to binding declarations, instead of just saying that
    VARIABLE-INFORMATION can return additional values, how about saying that
    the fifth value is a property list of implementation-dependent
    declaration keys and values?  That way, extensions developed at different
    places could later be mixed together rather than necessarily being
    mutually incompatible.

That's a good idea.  In fact I think IGNORE should be on that property
list rather than being a separate value, since it's so miscellaneous.

∂22-Mar-89  0905	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Mar 89  09:05:36 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA23988; Wed, 22 Mar 89 10:00:48 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA11610; Wed, 22 Mar 89 10:00:19 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903221700.AA11610@defun.utah.edu>
Date: Wed, 22 Mar 89 10:00:17 MST
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: David N Gray <Gray@DSG.csc.ti.com>, cl-compiler@SAIL.STANFORD.EDU,
        cperdue@Sun.COM
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 22 Mar 89 11:34 EST

We don't seem to be making much progress on resolving the problems
with accessors for declarations.  I'm beginning to wonder if we should
leave out that part of the proposal entirely for now, and instead just
try to standardize the parts that we seem to agree on.

If we want to continue to work towards some solution on the problem,
my suggestion is to have the DECLARATION-INFORMATION function only be
used for pervasive declarations, and that declarations that can apply
to a function or variable binding have to be returned in a property
list from FUNCTION-INFORMATION or VARIABLE-INFORMATION.

-Sandra
-------

∂22-Mar-89  1031	CL-Compiler-mailer 	latest issue status summary   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Mar 89  10:31:03 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA28525; Wed, 22 Mar 89 11:30:55 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA11679; Wed, 22 Mar 89 11:30:51 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903221830.AA11679@defun.utah.edu>
Date: Wed, 22 Mar 89 11:30:49 MST
Subject: latest issue status summary
To: cl-compiler@sail.stanford.edu

Here's the latest summary of what's going on with the various issues
we have pending.  The ones marked with an asterisk definitely need new
versions prepared before we can vote on them.  (I've already
circulated drafts of some of these to the people who requested the
changes, and I'm working on revising the others today.)  I don't plan
to revise the ones that aren't marked, so if you really want something
to happen on those issues you'd better speak up soon, and have some
specific suggestions. 

My plan is to mail the new versions out to X3J13 tomorrow or Friday at
the latest.  


* CLOS-MACRO-COMPILATION
    Clarify the language about errors under DEFMETHOD.

* COMPILE-ENVIRONMENT-CONSISTENCY
    Implementations are also permitted to signal an error if there
    are discrepancies between compiletime and runtime.  Clean up
    error language in item 3.  Minor wording changes to item 1b.

  COMPILE-FILE-SYMBOL-HANDLING

* COMPILED-FUNCTION-REQUIREMENTS
    Restore proposal FLUSH in response to popular demand.
    Clarify relation to issue COMPILE-ARGUMENT-PROBLEMS.

* COMPILER-DIAGNOSTICS
    Clean up error terminology in the section on warnings.
    Add notes on use of ABORT restart and resignalling to discussion section.

* COMPILER-LET-CONFUSION
    Fix bug in example code.
    Clarify relation to DEFINE-OPTIMIZER.
    Mention Moon's suggestion in discussion (unless a proposal is submitted)

  COMPILER-VERBOSITY
 
* CONSTANT-CIRCULAR-COMPILATION
    Change EQ to EQL, add to discussion.

* CONSTANT-COLLAPSING
    Clarify wording.

* CONSTANT-COMPILABLE-TYPES
    Revised with suggestions from Moon.

* CONSTANT-FUNCTION-COMPILATION
    This is a new issue, split off from CONSTANT-COMPILABLE-TYPES.
    Only one proposal to make handling of constant functions unspecified,
    unless somebody can figure out how to specify how to dump them.
    
  DEFCONSTANT-NOT-WIRED
    None of the proposals are ready to be voted on.

* DEFINE-OPTIMIZER
    Return only one value from optimizer.
    Optimizer has precedence over INLINE declaration.
    NOTINLINE declarations inhibit optimization.
    Minor clarifications to wording.
    Expand discussion section.

* DEFINING-MACROS-NON-TOP-LEVEL
    Revisions per Moon.  Move item 3 to EVAL-WHEN-NON-TOP-LEVEL.

* EVAL-WHEN-NON-TOP-LEVEL
    Add item 3 from DEFINING-MACROS-NON-TOP-LEVEL.

  LOAD-TIME-EVAL

  MACRO-CACHING
    Moon suggested simplifying the writeup.

  MACRO-ENVIRONMENT-EXTENT
    Barmar wants the copier function renamed (to what?)

  PROCLAIM-ETC-IN-COMPILE-FILE
    New name for DEFPROCLAIM? (no suggestions yet)

* QUOTE-SEMANTICS
    Revisions to language per Moon.  

  SAFE-CODE
    This issue has been withdrawn.

* SYNTACTIC-ENVIRONMENT-ACCESS
    Unresolved problems:  what to do about declaration accessors, whether
      to require declarations always to be saved, and what to do about
      ENCLOSE.

  WITH-COMPILATION-UNIT
    There have been complaints that the proposal is not ready.
-------

∂22-Mar-89  1213	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 22 Mar 89  12:13:19 PST
Received: by ti.com id AA10022; Wed, 22 Mar 89 12:48:37 CST
Received: from Kelvin by tilde id AA16309; Wed, 22 Mar 89 12:34:01 CST
Message-Id: <2815583502-434567@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 22 Mar 89  12:31:42 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: dick@wheaties.ai.mit.edu
Cc: cl-compiler@sail.stanford.edu, cperdue@sun.com
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
In-Reply-To: Msg of Tue, 21 Mar 89 12:32:05 EST from dick@wheaties.ai.mit.edu

> (1) The proposal should say somewhere what happens if an environment
> gets returned out of its dynamic context.

That is addressed by a separate proposal.

> What is worse, while AUGMENT-ENVIRONMENT fully captures the
> functionality of SYMBOL-MACROLET, and MACROLET, it behaves very oddly
> with regard to LET and FLET.  In particular, if I understand it right,
> it could be used to set things up so that the compiler thought a given
> variable was a local varible, but it does nothing to actually create the
> variable so things can be stored in it.  What does this even mean?

The result of AUGMENT-ENVIRONMENT can be passed to MACROEXPAND or the
various environment accessors, but it is not intended that the compiler
or evaluator would ever see it.  In fact, there is no way proposed that
an environment object can be given to the compiler.

∂22-Mar-89  1219	CL-Compiler-mailer 	issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Mar 89  12:19:13 PST
Received: from wheat-chex.ai.mit.edu by life.ai.mit.edu; Wed, 22 Mar 89 15:19:42 EST
Received: from localhost by wheat-chex.ai.mit.edu; Wed, 22 Mar 89 15:19:40 EST
Date: Wed, 22 Mar 89 15:19:40 EST
From: dick@wheaties.ai.mit.edu
Message-Id: <8903222019.AA10986@wheat-chex.ai.mit.edu>
To: Gray@dsg.csc.ti.com
Cc: cl-compiler@sail.stanford.edu, cperdue@sun.com, dick@wheaties.ai.mit.edu
In-Reply-To: David N Gray's message of Wed, 22 Mar 89  12:31:42 CST <2815583502-434567@Kelvin>
Subject: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4


    > What is worse, while AUGMENT-ENVIRONMENT fully captures the
    > functionality of SYMBOL-MACROLET, and MACROLET, it behaves very oddly
    > with regard to LET and FLET.  In particular, if I understand it right,
    > it could be used to set things up so that the compiler thought a given
    > variable was a local varible, but it does nothing to actually create the
    > variable so things can be stored in it.  What does this even mean?

    The result of AUGMENT-ENVIRONMENT can be passed to MACROEXPAND or the
    various environment accessors, but it is not intended that the compiler
    or evaluator would ever see it.  In fact, there is no way proposed that
    an environment object can be given to the compiler.

Yes, I should have put that differently.

  In particular, if I understand it right, AUGMENT-ENVIRONMENT could
  be used to set things up so that inner macroexpansions using the
  environment think a given variable is a lexical variable, but it
  does nothing to actually create the variable so things can be stored
  in it.  What does this even mean?

Consider the following example.  It is not clear exactly what some
macro might do with the knowledge that a variable is local, so I have
just made something up.  However, whatever a macro did with this
information, it would not do the right thing if the information was
wrong, and AUGMENT-ENVIRONMENT makes it very easy for the information
to be wrong.

(defmacro bind-if-not-lexical (var &body body &environment env)
  (if (eq (variable-kind var env) :lexical) `(progn , . body)
      `(let (var) , . body)))

I would expect that the code in the body of the macro
bind-if-not-lexical could depend on var being lexical.

So I could write something like the following:

(defmacro swap (x y &optional (using (gensym)))
  `(bind-if-not-lexical ,using 
     (setq ,using ,x ,x ,y ,y ,using)))

and have the following work correctly:

(defun dumb-test (x y &aux z)
  (funny-macro a
    (swap x y z)
    (swap x y a)))

However, what if funny-macro is defined as follows?

(defmacro funny-macro (var &body body &environment env)
  (setq env (augment-environment :variable (list var)))
  `(progn , .(mapcar #'(lambda (f) (macroexpand f env))
                     body)))

We are going to end up referring to the unbound variable a.

This is to be contrasted with the following

(defmacro funny-macro2 (var &body body &environment env)
  (setq env (augment-environment :variable (list var)))
  `(let (,var) , .(mapcar #'(lambda (f) (macroexpand f env))
           	          body)))

Which is of course all right.  At the very least it must be said very
carefully that you cannot go using augment-environment to say things
unless they are true.  With variables this is an odd thing to say
because anything that is true about a variable for some external
reason will already be entered into the environment and therefore
there would be no reason to bother to say anything.  The only case
where it would ever make sense to use augment-environment is ones like
the one above.  And you can always do something like the following instead.

(defmacro funny-macro3 (var &body body)
  `(let (,var) , . body))

or if things are really complex

(defmacro funny-macro4 (var &body body)
  `(let (,var) (funny-macro4* ',arbitrary-state-info , . body)))
(defmacro funny-macro4* (state-info &body body &environment env)
  <arbitrary-processing>)

(The point here being that you have to save some info for when you get
control back after the real macro-processer gets the environment set
up right.)

Note that this problem does not come up in the :symbol-macro and
:macro case because all of the activity is purely confined to the
macro expansion phase of things and therefore in a very real sense
something you say to augment-environment is true simply because you
say it is true.

With declarations things still at least make sense in that you might
have figured somthing out that is true, but is not yet in the
environment. 

-----

In summary, it just seems to me that AUGMENT-ENVIRONMENT is not at all
the same kind of thing as the accessors.  I can use the accessors any
way I like and things are fine, but I have to be very careful with
AUGMENT-ENVIRONMENT.  

If the intention is just to expose a subprimitive that can be used to
support code walkers, then at a minimum I suggest that this be
said loud and clear and that the inputs for :variable and :function be
made syntactically identical to Let/prog/do etc. and flet/labels
binding lists so that code walking will be easy to do.  (You did this
with the other three keywords.)

Better yet I suggest getting to the heart of the matter with a form
called something like 

WALK-INTO ENV FORM FN

FORM must be one of the key forms that alters the environment
(i.e, let,let*,flet,macrolet,prog, etc.).  Walk-into augments its
environment argument as FORM dictates including all declarations.  It
then calls FN with two arguments, the body of FORM and the augmented
environment.  It returns a copy of FORM with the body replaced by
whatever FN returns.  Using this, you could rewrite funny-macro4 as follows

(defmacro funny-macro4+ (var &body body &environment env)
  (walk-into env `(let (,var) , . body)
             #'(lambda (body env)  <arbitrary-processing>)))

You can get into trouble with this too by consing up some special code
and contriving not to put it into the final, but at least the
intention is clear.  Also it would be a lot easier to use for code walking.



∂22-Mar-89  1351	CL-Compiler-mailer 	Re:  issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 22 Mar 89  13:51:14 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
	id AA11206; Wed, 22 Mar 89 13:52:38 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.1)
	id AA18905; Wed, 22 Mar 89 13:48:39 PST
Received: by clam.sun.com (4.0/SMI-4.0)
	id AA08918; Wed, 22 Mar 89 13:52:19 PST
Date: Wed, 22 Mar 89 13:52:19 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903222152.AA08918@clam.sun.com>
To: Gray@dsg.csc.ti.com, dick@wheaties.ai.mit.edu
Subject: Re:  issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
Cc: cl-compiler@sail.stanford.edu, cperdue@Sun.COM

As far as I know, the main application of AUGMENT-ENVIRONMENT is
indeeed intended to be for code-walking:  cross-reference analysis,
type-analysis, code transformation, etc..  I think the objectives for
AUGMENT-ENVIRONMENT were to support this activity well.

Unfortunately, the simple definition of WALK-INTO you describe
doesn't quite work.

> WALK-INTO ENV FORM FN
> 
> FORM must be one of the key forms that alters the environment
> (i.e, let,let*,flet,macrolet,prog, etc.).  Walk-into augments its
> environment argument as FORM dictates including all declarations.  It
> then calls FN with two arguments, the body of FORM and the augmented
> environment.  

What if FORM is (lambda (x &optional (y (list x)) &aux (z (or x t)) ... )?

The scope of X is not just a body.  It is some initialization forms
and also a body.

PCL has a code walker.  It is a few hundred lines of code.  My sense
is that people are trying to design a subprimitive to make such
a code walker portable.  The entire code walker spec. might be too much
to freeze into a standard right now.

					-Cris

∂22-Mar-89  1354	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Mar 89  13:53:12 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA06425; Wed, 22 Mar 89 14:36:13 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA11763; Wed, 22 Mar 89 14:35:54 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903222135.AA11763@defun.utah.edu>
Date: Wed, 22 Mar 89 14:35:52 MST
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
To: dick@wheaties.ai.mit.edu
Cc: Gray@dsg.csc.ti.com, cl-compiler@sail.stanford.edu, cperdue@sun.com
In-Reply-To: dick@wheaties.ai.mit.edu, Wed, 22 Mar 89 15:19:40 EST

Just to respond to a few of the points you raised in your message:

AUGMENT-ENVIRONMENT is intended to be used by program analysis
programs, not to add things to the environment in macro functions just
for the heck of it.  I'd say that any macro expander that tries to add
things to the environment that aren't really there is broken, because
it doesn't "preserve semantics" of the macro call.  There are lots of
other ways users can get into trouble with macros that don't have
anything to do with environments, but I don't think the standard is
going to address that problem.

The reason why it's necessary to put some information about variable
and function bindings in the environment, even though the actual
bindings are not fully defined, is so that they will shadow macro
definitions or global definitions of those variables and functions.
For instance, binding a local function named FOO shadows any macro
definition of FOO in an outer contour.

Code walkers have to pick apart forms like LET and LABELS anyway
(because the initial binding forms and local function definitions have
to be walked in the appropriate environment), so there isn't much
motivation for making the corresponding inputs to AUGMENT-ENVIRONMENT
syntactically identical.  All you need is a call to (MAPCAR #'CAR ...)
to extract the right information, anyway.  Your suggestion for
WALK-INTO won't work for the same reason -- it would have to walk the
parts of the form that establish the initial values for the bindings,
as well as the body.  Also, I've experimented in the past with trying
to write a generic code-walker that used hook functions like you
suggest, and found that it didn't work very well.  It didn't give
enough control over the right kinds of information.

-Sandra
-------

∂22-Mar-89  1523	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 22 Mar 89  15:17:31 PST
Received: by ti.com id AA10725; Wed, 22 Mar 89 15:33:46 CST
Received: from Kelvin by tilde id AA20484; Wed, 22 Mar 89 15:29:19 CST
Message-Id: <2815594040-1067729@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 22 Mar 89  15:27:20 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
        cl-compiler@SAIL.STANFORD.EDU, cperdue@Sun.COM
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
In-Reply-To: Msg of Tue, 21 Mar 89 18:17 EST from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

> I like this new version of SYNTACTIC-ENVIRONMENT-ACCESS:SMALL,
> except for two minor comments:
> 
>  The accessors VARIABLE-INFORMATION, FUNCTION-INFORMATION, and 
>  DECLARATION retrieve information about declarations that are in
>  effect in the environment.  Since implementations are permitted to
>  ignore declarations (except for SPECIAL declarations), these accessors
>  are required only to return information about declarations that were
>  explicitly added to the environment using AUGMENT-ENVIRONMENT.
> 
> I think this is wrong.  Certainly if DECLARATION is to be useful
> implementations must not be allowed to discard any of the declarations
> it can return.  As someone from an implementation that ignores type
> declarations, I can say that I think all implementations should be
> required to return all declarations from all three of these functions.
> I think implementations should be permitted to ignore declarations
> in the sense of the code generated by the compiler not being affected
> by declarations, but should not be permitted to just throw declarations
> away rather than putting them into the syntactic environment.

I think there is a fundamental question here of what the purpose of the
proposal is -- is it to 

(1) Allow users to gain access to certain information in the compiler's
    data structures

or

(2) Require the compiler to do some extra bookkeeping for the user.

I have been assuming purpose (1), while you seem to be assuming purpose
(2).  

The only declarations that can be discarded are those which don't change
the semantics of the program.  Thus, a macro expander might like to know
what the type of a variable is, or what the OPTIMIZE levels are, but
neither is necessary for it to produce correct code.  If someone adds a
bunch of type declarations to their source in order to make the compiled
code faster, would they expect that this would make it run slower when
evaluated?  I don't like the idea of forcing the evaluator to remember a
lot of information that it has no use for just in case someone might
possibly ask to see it later.

What you want sounds like the way the special variable LOCAL-DECLARATIONS
was used in the Zetalisp compiler -- all declarations were simply pushed
on the list and anyone could access the variable to look up whatever they
were interested in.  This has proven to be very inefficient; everything
that our compiler really cares about is now stored some other way.  The
only declarations that we push on LOCAL-DECLARATIONS now are those that
are in a list of declarations that need to be treated that way; this was
just in case some users needed that capability, but I have never seen any
program that did use it.  I really don't want to standardize something
like LOCAL-DECLARATIONS unless there are real uses for it, not just
hypothetical ones.

∂22-Mar-89  2115	CL-Compiler-mailer 	issue LOAD-TIME-EVAL, version 11   
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 22 Mar 89  21:06:24 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
	Wed, 22 Mar 89 23:07:26 CST id AA24581 for cl-compiler@SAIL.STANFORD.EDU
Posted-Date: Wed, 22 Mar 89 23:05:30 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
	id AA25731; Wed, 22 Mar 89 23:05:30 CST
Date: Wed, 22 Mar 89 23:05:30 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903230505.AA25731@pavo.src.honeywell.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-compiler@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Mon, 20 Mar 89 15:46 EST <19890320204610.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: issue LOAD-TIME-EVAL, version 11

Summary:  I must be missing something...

   Posted-Date: Mon, 20 Mar 89 15:46 EST
   Date: Mon, 20 Mar 89 15:46 EST
   From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

       Date: Sun, 19 Mar 89 22:18:17 CST
       From: alarson@src.honeywell.com (Aaron Larson)

       I find myself strongly opposed to **3.

   Read Sandra's answer first.

Well, I appear to be out of it.  I've been thinking this over for the last
two days, and I still don't get it.  My mental model of what
LOAD-TIME-VALUE gives me is syntactic sugar.  E.g.

   (defun foo () .... (load-time-value XXX) ...)

could be (assuming DEFINING-MACROS-NON-TOP-LEVEL):

   (let ((val XXX))
     (defun foo () ... val ...))

My understanding of its need is that it can be difficult for macros to
expand into something like the above without a fair amount of cooperation
from the "top level" defining macro.

  From Sandra:
	  (flet ((foo () (load-time-value (bar))))
	    (declare (inline foo))
	    (list (foo) (foo)))

I personally don't see what the inlining example has to do with the issue
at all.  If I have a function defined like the following:

  (let ((val (make-array ...)))
    (defun bar () val))

it seems reasable for the compiler to put a constant value in the body of
bar, but if I then declare it to be inline, I don't see how the compiler
can propagate the constant unless it can ensure that the values it
propagates will always be EQ (for example if it is inlined into functions
from different files, the loader has to be smart enough to make the
constants one and the same at load time, or the inlining operation is not
legal).  I would think that the fact LOAD-TIME-VALUE is a special form
encompases this sort of analysis for its resultant value in an analagous
manner.  

The talk about EQ structures being coallesced I've always considered bogus,
LOAD-TIME-VALUE denotes a way of computing a value, the fact that it is
somehow not evaluated the next time around is a property of where it
appeared in code, not the identity of the cons cell that made it up.  For
example, is anyone considering that it would be legal to have only one
load-time-value expressing in the following:

   (defun foo (x)
     (if x
         #1=(load-time-value ....)
	 #1#))

My take of the **3 proposal is that foo could become a constant function,
that seems wrong to me, hence I believe the following two programs denote
different computations (the first foo being a constant function, the second
one not):

   (defun foo (x)
     (flet ((bar () (load-time-value XXX))))
       (if x (bar) (bar)))

   (defun foo (x)
     (macrolet ((bar () '(load-time-value XXX))))
       (if x (bar) (bar)))


Moon Again:

   The problem is that the **2 proposal is not well specified and thus
   cannot be implemented, or will require the implementor to make arbitrary
   decisions that will probably come out different ways for different
   implementations.

   Thus I think it's incumbent on anyone who opposes **3 to propose an
   alternative, and I think just going back to **2 is not a viable
   alternative.

I guess my problem is that I don't see the implementation lattitude
that you do.  Undoubtedly this comes from your far greater experience.
Since we will be in DC in a few days, perhaps someone can take a few
minutes (hours?) to explain it to me.  I'll even buy the beer.

∂23-Mar-89  1139	CL-Compiler-mailer 	issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89  11:39:28 PST
Received: from wheat-chex.ai.mit.edu by life.ai.mit.edu; Thu, 23 Mar 89 12:39:56 EST
Received: from localhost by wheat-chex.ai.mit.edu; Thu, 23 Mar 89 12:39:54 EST
Date: Thu, 23 Mar 89 12:39:54 EST
From: dick@wheaties.ai.mit.edu
Message-Id: <8903231739.AA13965@wheat-chex.ai.mit.edu>
To: sandra%defun@cs.utah.edu
In-Reply-To: Sandra J Loosemore's message of Wed, 22 Mar 89 14:35:52 MST <8903222135.AA11763@defun.utah.edu>
Cc: Gray@dsg.csc.ti.com, cl-compiler@sail.stanford.edu, cperdue@sun.com
Subject: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4



Yes I agree I was over simplifying things.  Sorry for taking you all
over what I expect is ground you have all been over before.  I also
certainly think that some kind of support facilitating code walking is
better than none.

So all and all, I guess I really only have one suggestion, and that is that
the description of AUGMENT-ENVIRONMENT should be clearer on what it
for.  Saying that it is for "constructing enviroments" lead me down the
wrong path all together.  Things would have been much clearer to me as
an outside observer if the documentation had made it clear that
facilitating code walking was all it was for.

∂23-Mar-89  2107	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89  21:07:20 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 563823; 23 Mar 89 15:14:15 EST
Date: Thu, 23 Mar 89 15:13 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5 
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Sandra J Loosemore <sandra%defun@CS.UTAH.EDU>, cl-compiler@SAIL.STANFORD.EDU,
    cperdue@Sun.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <2815594040-1067729@Kelvin>
Message-ID: <19890323201357.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 22 Mar 89  15:27:20 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    I think there is a fundamental question here of what the purpose of the
    proposal is -- is it to 

    (1) Allow users to gain access to certain information in the compiler's
	data structures

    or

    (2) Require the compiler to do some extra bookkeeping for the user.

    I have been assuming purpose (1), while you seem to be assuming purpose
    (2).  

You're right.  Not only the compiler, also the interpreter would have to do
the extra bookkeeping.  I didn't regard recording those declarations (as
opposed to acting on them) to be a significant effort, but I might be wrong.

    The only declarations that can be discarded are those which don't change
    the semantics of the program.  Thus, a macro expander might like to know
    what the type of a variable is, or what the OPTIMIZE levels are, but
    neither is necessary for it to produce correct code.  

This is no longer true.  With the introduction of the concept of "safe code",
it's necessary to know the OPTIMIZE SAFETY level in anything that does not
unconditionally produce safe code.

							  If someone adds a
    bunch of type declarations to their source in order to make the compiled
    code faster, would they expect that this would make it run slower when
    evaluated?  

I would, just because the code is larger.

		I don't like the idea of forcing the evaluator to remember a
    lot of information that it has no use for just in case someone might
    possibly ask to see it later.

I do see your point though.

    What you want sounds like the way the special variable LOCAL-DECLARATIONS
    was used in the Zetalisp compiler -- all declarations were simply pushed
    on the list and anyone could access the variable to look up whatever they
    were interested in.  This has proven to be very inefficient; everything
    that our compiler really cares about is now stored some other way.  The
    only declarations that we push on LOCAL-DECLARATIONS now are those that
    are in a list of declarations that need to be treated that way; this was
    just in case some users needed that capability, but I have never seen any
    program that did use it.  I really don't want to standardize something
    like LOCAL-DECLARATIONS unless there are real uses for it, not just
    hypothetical ones.

I didn't think the list returned by DECLARATION-INFORMATION would be actually
consed until you asked for it; the information could be remembered in some
other form.  The use of a list here was just to maximize the simplicity
and minimize the functionality of the interface.

Would it be reasonable to say that declarations that pertain to variable
bindings and function definitions are remembered at the discretion of the
implementation, but that other declarations (the kind you get at with
DECLARATION-INFORMATION) must be remembered?

Or are we concluding that we're not really ready to standardize
anything for SYNTACTIC-ENVIRONMENT-ACCESS?

∂24-Mar-89  0824	CL-Compiler-mailer 	issue DEFINE-OPTIMIZER, version 6  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 24 Mar 89  08:23:55 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 24 Mar 89 11:21:42 EST
Date: Fri, 24 Mar 89 11:22 EST
From: Barry Margolin <barmar@Think.COM>
Subject: issue DEFINE-OPTIMIZER, version 6
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: <8903232118.AA12741@defun.utah.edu>
Message-Id: <19890324162247.9.BARMAR@OCCAM.THINK.COM>

    Date: Thu, 23 Mar 89 14:18:27 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

      The editor is advised that a non-binding style note such as the
      following would also be appropriate:

	In general, it is poor style for a programmer to define optimizers for
	functions that he does not maintain. This is because the correct
	implementation of an optimizer for a function usually depends on an
	understanding of the internals of that function. As such, a function 
	definition and any optimizers should be maintained as a unit so that
	they can changes in either can be synchronized as appropriate with the
	other.

I think is is a bit strong.  All that an optimizer writer should need to
know is the externally-visible behavior of the function being optimized.
It may be useful to know the implementation of the function in order to
determine what optimizations are most necessary, but it's often possible
to do a decent job without such knowledge.  For example, an optimizer
for * that performs constant folding and recognizes the special case
where one argument is the constant 0 is pretty safe, no matter how * is
implemented.

Perhaps what is intended is a warning that programmers shouldn't define
optimizers for standard CL functions that the implementation might
extend, where the optimizer only implements the standard behavior, since
this might break any internal, non-portable uses of the function within
the implementation.

      If a function that has an optimizer function is declared INLINE,
      the optimizer has precedence.  If a function that has an optimizer
      function is declared NOTINLINE, the application of the optimizer
      function by OPTIMIZE-EXPRESSION and OPTIMIZE-EXPRESSION-1 is
      inhibited.

I'm not sure if this says what it intends to say.  The way I read it,
a user-defined function will only be optimized if it is also declared
INLINE.  This is because user-defined functions are NOTINLINE by
default.  Or is there a difference between functions explicitly declared
NOTINLINE and those whose INLINEness is allowed to default?  If so, then
I suggest we give a name to this so that users can make such cases
explicit.  However, this is the first time such a need has come up, and
I don't really care for it.

                                                barmar

∂24-Mar-89  0850	CL-Compiler-mailer 	Re: issue DEFINE-OPTIMIZER, version 6   
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 24 Mar 89  08:49:47 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
	id AA17549; Fri, 24 Mar 89 11:49:31 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA05035; Fri, 24 Mar 89 11:51:25 EST
Message-Id: <8903241651.AA05035@mist.>
To: Barry Margolin <barmar@Think.COM>
Cc: cl-compiler@sail.stanford.edu
Subject: Re: issue DEFINE-OPTIMIZER, version 6 
In-Reply-To: Your message of Fri, 24 Mar 89 11:22:00 -0500.
             <19890324162247.9.BARMAR@OCCAM.THINK.COM> 
Date: Fri, 24 Mar 89 11:51:22 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    Date: Fri, 24 Mar 89 11:22 EST
    From: Barry Margolin <barmar@Think.COM>
    
    I think is is a bit strong.  All that an optimizer writer should need to
    know is the externally-visible behavior of the function being optimized.
    It may be useful to know the implementation of the function in order to
    determine what optimizations are most necessary, but it's often possible
    to do a decent job without such knowledge.  For example, an optimizer
    for * that performs constant folding and recognizes the special case
    where one argument is the constant 0 is pretty safe, no matter how * is
    implemented.
    
Part of the point is if a user defines such an optimizer _and_ the
implementation causes user optimizers to override built-in optimizers,
the user might unknowingly override a built-in optimizer that did all
of the above and in addition converted multiplication by small
constant values to inline shifts and adds.  In general, defining an
optimizer for code you didn't right (especially built-in code) is
risking a chance that you have accidentally defined a pesimizer
instead.

Of course, you can and should should always test to see that such
optimizers really improve performance by your favorite metric and
don't break the function being optimized (and repeat such tests with
every new version of the implementation).  This is a lot of work, and
IMHO, the repeated testing part of it is all too likely to be
neglected.

We're not saying that you should *never* write an optimizer for code
you don't maintain.  We are saying that you should think very
carefully about it and we are giving implementations maximum freedom
by saying that defining optimizers for CLtL forms (really for any
implementation forms) are undefined.

∂24-Mar-89  0943	CL-Compiler-mailer 	Issue: DEFINE-OPTIMIZER  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Mar 89  09:43:27 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 564664; Fri 24-Mar-89 12:39:57 EST
Date: Fri, 24 Mar 89 12:39 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFINE-OPTIMIZER
To: BARMAR@Think.COM
cc: CL-Compiler@SAIL.Stanford.EDU, sandra%defun@cs.utah.edu
In-Reply-To: <19890324162247.9.BARMAR@OCCAM.THINK.COM>
Message-ID: <890324123929.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

I don't think the style warning is too strong.

The issue is not what you have to know about the internals of the function
being optimized, but rather what you have to know about the internals
of DEFINE-OPTIMIZER.

The proposal almost didn't make `escape velocity' (to leave cl-compiler
and get seen by x3j13) because of concern on the part of implementors
that people would try to optimize things in the system. This warning is
intended to put those fears to rest.

The issue is that the proposed definition doesn't tell you if the system
also has optimizers for a function and whether if you define your own you
will clobber the system's.  This again was an issue that nearly killed
this proposal on the first pass-- some people want their system optimizers
implemented in terms of this; some people want to do it the other way
around.  Rather than fight over it, it's better to just compromise on
a conservative definition.

For functions you wrote, you know no one has written optimizers in advance
so you won't be clobbering anyone's, regardless of how DEFINE-OPTIMIZER
is implemented. For anything else, you can't know for sure what the effect
of doing DEFINE-OPTIMIZER will be in all implementations, so it's best
left vague.

Implementations which provide a full set of meta-level operators for
inspecting the set of optimizers on a function would be within their rights
to (by virtue of that complete set) say you could do an optimizer on
functions you didn't write without feeling guilty. But even then I don't
think everyone would agree that it's still conceptually the right thing.

Anyway, my feeling is that if you pursue your gripe, you'll risk crushing
this fragile proposal and the community as a whole will lose because they
won't be able to write optimizers on -anything- because no operator got
voted in.

-----
I haven't studied the notinline issue enough yet to have an opinion.

∂03-Apr-89  1421	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Apr 89  14:21:20 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA24104; Mon, 3 Apr 89 15:21:15 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA18470; Mon, 3 Apr 89 15:21:13 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904032121.AA18470@defun.utah.edu>
Date: Mon, 3 Apr 89 15:21:11 MDT
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY
To: cl-compiler@sail.stanford.edu
Cc: common-lisp-object-system@sail.stanford.edu

At the meeting, an amendment was proposed to this issue to replace all of
the current item (g) with:

  The compiler can assume that type definitions made with DEFTYPE or
  DEFSTRUCT in the compiletime environment will retain the same
  definition in the runtime environment.  This implies that
  subtype/supertype relationships of type specifiers defined by DEFTYPE
  or DEFSTRUCT will not change between compiletime and runtime.  (Note
  that it is not an error for an unknown type to appear in a declaration
  at compiletime, although it is reasonable for the compiler to emit a
  warning in such a case.)

The proposal was tabled with this amendment pending (it was not
officially seconded or voted on).  

Having had time to think about this for a while, to me it seems like
this amendment is going to cause trouble.  I've been thinking about
our canonical example of a type-inferencing preprocessor.  Such a
preprocessor could conceivably be written so as not make use of
information about certain type relationships, provided that it is
possible to test whether a type specifier is one of the ones that it
can't make assumptions about.  That's the real problem: given a type
specifier, how do you know whether it was defined with DEFTYPE or
DEFSTRUCT, or some other way?

Also, one might want to define a metaclass that does license the
compiler to make assumptions about the type hierarchy of its instance
classes not changing.  (In fact, I think this would be a rather common
extension.)

I wouldn't object to rewording the amendment so that the compiler is
permitted to make assumptions about all type specifiers except those
that name classes whose metaclass is (a subclass of) STANDARD-CLASS.
It's at least possible (although a little convoluted) to test for that.

What do the rest of you think about this?

-Sandra
-------

∂03-Apr-89  1453	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Apr 89  14:53:10 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570544; Mon 3-Apr-89 17:52:13 EDT
Date: Mon, 3 Apr 89 17:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@sail.stanford.edu, common-lisp-object-system@sail.stanford.edu
In-Reply-To: <8904032121.AA18470@defun.utah.edu>
Message-ID: <19890403215202.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

  What do the rest of you think about this?

I think you're pointing in the right direction, however there is a
problem.  Any specification in terms of the metaclass requires that
class objects be created at compile time by COMPILE-FILE, or there
is no reasonable way to find out at compile time what the metaclass
is.  CLOS-MACRO-COMPILATION (which you wrote) seems to be trying to
avoid requiring any compile-time objects to be created.  So we have
a conflict between two proposals.  In fact it's possible that the
metaclass is the wrong way to say "this class will not be redefined
later" and instead that should be said by the way that the program
is compiled, not by anything in the program, making it an environment
issue rather than a language issue.

An interesting question is whether this type-inferencing preprocessor
is supposed to be able to accept all conforming programs, or only
a subset of conforming programs subject to additional restrictions,
for example that class definitions in the program are not changed
between preprocess time and run time.  Saying that we have two languages,
the full language and the type-inferencing preprocessable subset,
might eliminate the conflict here (although it will likely make
Gabriel sound off).

∂03-Apr-89  1456	CL-Compiler-mailer 	issue PROCLAIM-ETC-IN-COMPILE-FILE 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Apr 89  14:55:54 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA26412; Mon, 3 Apr 89 15:55:52 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA18515; Mon, 3 Apr 89 15:55:48 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904032155.AA18515@defun.utah.edu>
Date: Mon, 3 Apr 89 15:55:47 MDT
Subject: issue PROCLAIM-ETC-IN-COMPILE-FILE
To: cl-compiler@sail.stanford.edu

When we last left this issue, we had eliminated proposals YES and NO
and were debating new names for the DEFPROCLAIM macro in proposal
NEW-MACRO.

Talking to some people informally afterwards, the two suggestions that
appeared to have the most support were DECLAIM and PROCLAMATION.
However, some people said they didn't like DECLAIM because it might be
too obscure for non-native English speakers, and some people said they
didn't like PROCLAMATION because they thought the name should be a
verb. 

I don't remember the list of all the others that were mentioned
(except PROCLARE, which wasn't intended to be a serious suggestion).
Consulting a thesaurus, I find some additional synonyms:

    advertise
    advise
    announce
    annunciate
    broadcast
    disseminate
    promulgate
    pronounce
    publish

Of these, my favorites are ADVISE and ANNOUNCE.

(Oh yes, DECLAIM has a totally different set of synonyms, including
orate, bloviate (!), harangue, rant, and rave.  Is this really the
right connotation we want to give to this construct?)

-Sandra
-------

∂03-Apr-89  1501	CL-Compiler-mailer 	Re: issue PROCLAIM-ETC-IN-COMPILE-FILE  
Received: from multimax.encore.com ([129.91.1.14]) by SAIL.Stanford.EDU with TCP; 3 Apr 89  15:01:30 PDT
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
	id AA06574; Mon, 3 Apr 89 18:01:20 -0400
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA02213; Mon, 3 Apr 89 18:03:09 EDT
Message-Id: <8904032203.AA02213@mist.>
To: "sandra%defun@cs.utah.edu"@multimax.encore.com (Sandra J Loosemore)
Cc: cl-compiler@sail.stanford.edu
Subject: Re: issue PROCLAIM-ETC-IN-COMPILE-FILE 
In-Reply-To: Your message of Mon, 03 Apr 89 15:55:47 -0600.
             <8904032155.AA18515@defun.utah.edu> 
Date: Mon, 03 Apr 89 18:03:06 EDT
From: Dan L. Pierson <pierson@mist.encore.com>

ADVISE is not a good choice because it sounds like part of the
non-standard but common advice facility.

∂03-Apr-89  1516	CL-Compiler-mailer 	issue PROCLAIM-ETC-IN-COMPILE-FILE 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Apr 89  15:15:06 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA15383g; Mon, 3 Apr 89 15:09:10 PDT
Received: by challenger id AA06004g; Mon, 3 Apr 89 15:04:21 PDT
Date: Mon, 3 Apr 89 15:04:21 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8904032204.AA06004@challenger>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 3 Apr 89 15:55:47 MDT <8904032155.AA18515@defun.utah.edu>
Subject: issue PROCLAIM-ETC-IN-COMPILE-FILE

   From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
   Date: Mon, 3 Apr 89 15:55:47 MDT

   When we last left this issue, we had eliminated proposals YES and NO
   and were debating new names for the DEFPROCLAIM macro in proposal
   NEW-MACRO.

   Talking to some people informally afterwards, the two suggestions that
   appeared to have the most support were DECLAIM and PROCLAMATION.
   However, some people said they didn't like DECLAIM because it might be
   too obscure for non-native English speakers, and some people said they
   didn't like PROCLAMATION because they thought the name should be a
   verb. 

Actually the term Declaim is obvious to all native speakers of latin based
languages.

Patrick.

∂03-Apr-89  1510	Common-Lisp-Object-System-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Apr 89  15:10:36 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA15372g; Mon, 3 Apr 89 15:04:47 PDT
Received: by challenger id AA05980g; Mon, 3 Apr 89 14:59:57 PDT
Date: Mon, 3 Apr 89 14:59:57 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8904032159.AA05980@challenger>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu, common-lisp-object-system@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 3 Apr 89 15:21:11 MDT <8904032121.AA18470@defun.utah.edu>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY

   From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
   Date: Mon, 3 Apr 89 15:21:11 MDT

   At the meeting, an amendment was proposed to this issue to replace all of
   the current item (g) with:

     The compiler can assume that type definitions made with DEFTYPE or
     DEFSTRUCT in the compiletime environment will retain the same
     definition in the runtime environment.  This implies that
     subtype/supertype relationships of type specifiers defined by DEFTYPE
     or DEFSTRUCT will not change between compiletime and runtime.  (Note
     that it is not an error for an unknown type to appear in a declaration
     at compiletime, although it is reasonable for the compiler to emit a
     warning in such a case.)

   The proposal was tabled with this amendment pending (it was not
   officially seconded or voted on).  

   Also, one might want to define a metaclass that does license the
   compiler to make assumptions about the type hierarchy of its instance
   classes not changing.  (In fact, I think this would be a rather common
   extension.)

   I wouldn't object to rewording the amendment so that the compiler is
   permitted to make assumptions about all type specifiers except those
   that name classes whose metaclass is (a subclass of) STANDARD-CLASS.
   It's at least possible (although a little convoluted) to test for that.

   What do the rest of you think about this?

When we drafted the amendment, I was thinking of specifying the behavior of
conforming programs. Precisely, I think that it provides an answer to the
following question:
 What kinds of consistency should the programmer preserve, from compile-file
to load? with the understanding that these constraints of consistency are
dictated by the compiler.
What we are proposing, is that in the general case, the user is free to
redefine the class between compile-file and load. 

In this sense, the situation you describe has little bearing. I your case, the
kind of consistency that the programmer has to maintain is dictated by the
metaclass, not by the compiler. If compile-file can take advantage of this
restriction, fine. I don't think that an implementation doing just that would
violate the proposal as amended.


Your first question about type-inference preprocessor touches more on
compile-time meta-object creation, or syntatic-environment access. I
understand the problem, I don't know what is the best solution. I personally
lean towards extending the syntactic environment access, because we don't want
to specify that metaobject should be instantiated at compile time.

Patrick.

∂03-Apr-89  1603	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Apr 89  16:03:05 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA00322; Mon, 3 Apr 89 17:03:00 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA18576; Mon, 3 Apr 89 17:02:54 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904032302.AA18576@defun.utah.edu>
Date: Mon, 3 Apr 89 17:02:53 MDT
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
To: cl-compiler@sail.stanford.edu
Cc: common-lisp-object-system@sail.stanford.edu

> Date: Mon, 3 Apr 89 17:52 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
> CLOS-MACRO-COMPILATION (which you wrote) seems to be trying to
> avoid requiring any compile-time objects to be created.  So we have
> a conflict between two proposals.

Right.  In fact, I had such potential conflicts in the back of my mind
when I decided to keep CLOS-MACRO-COMPILATION on hold until we got a
better handle on how to resolve this issue.

> Date: Mon, 3 Apr 89 14:59:57 PDT
> From: Patrick Dussud <dussud@lucid.com>
> 
> Your first question about type-inference preprocessor touches more on
> compile-time meta-object creation, or syntatic-environment access. I
> understand the problem, I don't know what is the best solution. I personally
> lean towards extending the syntactic environment access, because we don't want
> to specify that metaobject should be instantiated at compile time.

The idea behind such a preprocessor is that it would preserve the
semantics of the code it examines.  It shouldn't make any assumptions
about types that the compiler itself would not be able to make.

I agree that extending SYNTACTIC-ENVIRONMENT-ACCESS would be a
reasonable solution to the problem.  In particular, I remember hearing
suggestions in the past to add TYPE-EXPAND and TYPE-EXPAND-1
functions, that would at least take care of the problems relating to
DEFTYPE.  (The interesting thing about DEFTYPE as it relates to this
problem is not determinining whether a type specifier has been defined
with DEFTYPE, but rather what that DEFTYPE expands into.)

I don't think that not having a metaclass for a STANDARD-CLASS object
defined at compile-time is a serious problem.  If there's no metaclass
around, that would just indicate that you can't make any assumptions
about the type, the same as if it were not defined at all.  (In fact,
I think it would be consistent if DEFCLASS didn't make the
corresponding type specifier defined at compile-time either.)

Is it unreasonable to require that DEFSTRUCT make the metaclass be
defined at compile-time?

-Sandra
-------

∂03-Apr-89  1900	CL-Compiler-mailer 	issue PROCLAIM-ETC-IN-COMPILE-FILE 
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 3 Apr 89  19:00:21 PDT
Received: from GANG-GANG.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 286847; Mon 3-Apr-89 21:59:19 EDT
Date: Mon, 3 Apr 89 21:59 EDT
From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
Subject: issue PROCLAIM-ETC-IN-COMPILE-FILE
To: sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu
In-Reply-To: <8904032155.AA18515@defun.utah.edu>
Message-ID: <19890404015918.6.GSB@GANG-GANG.SCRC.Symbolics.COM>

    Date: Mon, 3 Apr 89 15:55:47 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    When we last left this issue, we had eliminated proposals YES and NO
    and were debating new names for the DEFPROCLAIM macro in proposal
    NEW-MACRO.

    Talking to some people informally afterwards, the two suggestions that
    appeared to have the most support were DECLAIM and PROCLAMATION.
    However, some people said they didn't like DECLAIM because it might be
    too obscure for non-native English speakers, and some people said they
    didn't like PROCLAMATION because they thought the name should be a
    verb. 

    I don't remember the list of all the others that were mentioned
    (except PROCLARE, which wasn't intended to be a serious suggestion).
    Consulting a thesaurus, I find some additional synonyms:

	advertise
	advise
	announce
	annunciate
	broadcast
	disseminate
	promulgate
	pronounce
	publish

    Of these, my favorites are ADVISE and ANNOUNCE.

    (Oh yes, DECLAIM has a totally different set of synonyms, including
    orate, bloviate (!), harangue, rant, and rave.  Is this really the
    right connotation we want to give to this construct?)

    -Sandra
    -------


None of these sound good to me.  In fact, most of them sound like output functions.
I'd suggest trying from the synonyms of assert:
	affirm
	asseverate
	aver
	avouch
	avow
	declare		; my goodness
	hold
	maintain
	state

Of these, I like AVOW best.

∂03-Apr-89  2131	CL-Compiler-mailer 	Re: issue PROCLAIM-ETC-IN-COMPILE-FILE  
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Apr 89  21:30:54 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA09906@EDDIE.MIT.EDU>; Tue, 4 Apr 89 00:30:49 EDT
Received: by spt.entity.com (smail2.5); 4 Apr 89 00:10:58 EDT (Tue)
Date: Tue, 4 Apr 1989 0:10:58 EDT
From: Gail Zacharias <gz@spt.entity.com>
To: cl-compiler@sail.stanford.edu
Subject: Re: issue PROCLAIM-ETC-IN-COMPILE-FILE 
Message-Id: <CMM.0.88.607666258.gz@spt.entity.com>

Yes indeedy, what this language really needs is two similar concepts named by
randomly assigned synonyms.

I would prefer to just make PROCLAIM a macro, but as long as PROCLAIM must
continue to evaluate its args, how about PROCLAIM-DECLARATION for the
one that doesn't.

∂03-Apr-89  2217	CL-Compiler-mailer 	issue PROCLAIM-ETC-IN-COMPILE-FILE 
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 3 Apr 89  22:17:51 PDT
Received: from franz.UUCP by ucbarpa.Berkeley.EDU (5.61/1.33)
	id AA28490; Mon, 3 Apr 89 22:17:31 -0700
Received: from fiseqs by franz (3.2/3.14)
	id AA01950; Mon, 3 Apr 89 22:15:15 PDT
Received: by fiseqs (4.12/3.14)
	id AA03287; Mon, 3 Apr 89 22:15:13 pdt
Return-Path: <fiseqs!feast!smh>
Received: by feast (5.5/3.14)
	id AA00555; Tue, 4 Apr 89 00:12:51 EST
Date: Tue, 4 Apr 89 00:12:51 EST
From: franz!fiseqs!feast!smh@ucbarpa.Berkeley.EDU (Steven M. Haflich)
Message-Id: <8904040512.AA00555@feast>
To: franz!sail.stanford.edu!cl-compiler
In-Reply-To: Glenn S. Burke's message of Mon, 3 Apr 89 21:59 EDT <19890404015918.6.GSB@GANG-GANG.SCRC.Symbolics.COM>
Subject: issue PROCLAIM-ETC-IN-COMPILE-FILE

Although few people liked DEFPROCLAIM, I advocate reconsideration.
The suggested alternatives appearing at top level of a file are
neither clear nor do they evince any connection with related forms in
the language.  A word containing "proclaim" or "proclamation" is clear
about having to do with PROCLAIM.  Just as important, the "DEF" prefix
associates this symbol with the other CL DEF* forms, all of which are
macros and all of which appear (always, or at least usually, depending
on other votes) at the "top level" or "global" scope in lisp files.
None of the other words carries all this useful information.

There is a reason INCF isn't called "INCREMENT."  Few people known the
derivation of the "F" suffix, but everyone knows it denotes a macro
that side-affects its first argument.

Therefore I advocate either DEFPROCLAIM or DEFPROCLAMATION.  Even if
they are a little ugly and not very witty, either is immediately clear
even if one has not been told what they do.

====================

The despairing novice approached the master and asked: "Is it too late
to put a little consistency into Common Lisp?"  The master replied:
"Of course not, but it's far too late to put very *much* in."

∂04-Apr-89  0646	CL-Compiler-mailer 	Re: issue PROCLAIM-ETC-IN-COMPILE-FILE  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 4 Apr 89  06:46:51 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA20361; Tue, 4 Apr 89 07:46:50 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA18918; Tue, 4 Apr 89 07:46:48 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904041346.AA18918@defun.utah.edu>
Date: Tue, 4 Apr 89 07:46:47 MDT
Subject: Re: issue PROCLAIM-ETC-IN-COMPILE-FILE
To: franz!fiseqs!feast!smh@ucbarpa.Berkeley.EDU (Steven M. Haflich)
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: franz!fiseqs!feast!smh@ucbarpa.Berkeley.EDU (Steven M. Haflich), Tue, 4 Apr 89 00:12:51 EST

> Although few people liked DEFPROCLAIM, I advocate reconsideration.
> The suggested alternatives appearing at top level of a file are
> neither clear nor do they evince any connection with related forms in
> the language.

I'm inclined to agree.  It doesn't appear that any of the alternatives
we've considered are clearly "the right thing" that we can all agree
on, and DEFPROCLAIM is really not all that bad.  I'd rather not waste
a lot more time on arguing over such a relatively minor issue.

-Sandra
-------

∂04-Apr-89  0909	Common-Lisp-Object-System-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  09:09:32 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 APR 89 08:57:37 PDT
Date: Tue, 4 Apr 89 08:54 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
 cl-compiler@sail.stanford.edu, common-lisp-object-system@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <19890403215202.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890404155429.5.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no

I won't be able to respond to this until Friday as I am about to go out
of town.

In fact, the only reason I am here now is that 4 different airlines
cancelled their morning flights to Boston.
-------

∂04-Apr-89  1215	CL-Compiler-mailer 	Issue: LOAD-TIME-EVAL    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:11:30 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 571203; 4 Apr 89 15:11:29 EDT
Date: Tue, 4 Apr 89 15:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL
To: CL-Compiler@SAIL.Stanford.EDU
Message-ID: <890404151103.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes mention that Haflich brought up the issue of dead code removal.
That is, does
  (LAMBDA () (IF T 'ALWAYS (LOAD-TIME-VALUE (F))))
-ever- have to evaluate the given expression (given that the value
might never be used).

The issue was passed 12-2 in spite of this objection, but I think we
might still want to clarify this issue if it's not clear already [I
didn't have time to check yet.]

I think it would be most consistent to say this might not ever get 
evaluated so that dead-code removal was legit here.  (In general, I
think it's permissible for LOAD-TIME-VALUE forms to do a side-effect,
but I don't think the -purpose- of doing a LOAD-TIME-VALUE is to get
a side-effect.  The side-effects are usually incidental to getting
the value.)

∂04-Apr-89  1252	CL-Compiler-mailer 	Re: Issue: LOAD-TIME-EVAL
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:51:37 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571303; Tue 4-Apr-89 15:50:54 EDT
Date: Tue, 4 Apr 89 15:50 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: LOAD-TIME-EVAL
To: sandra%defun@cs.utah.edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: <8904041946.AA19191@defun.utah.edu>
Message-ID: <890404155029.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Tue, 4 Apr 89 13:46:20 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    Although I neglected to write down any notes on this issue at the
    meeting, my recollection is that we agreed an amendment was not
    necessary and that an editorial clarification would suffice.  It
    didn't seem like a controversial point. 

This is fine with me. It does seem like a non-controversial thing, so I
don't care specifically how it's handled as long as it doesn't fall through
the cracks.

∂04-Apr-89  1252	CL-Compiler-mailer 	Re: Issue: LOAD-TIME-EVAL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:46:27 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA06572; Tue, 4 Apr 89 13:46:24 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA19191; Tue, 4 Apr 89 13:46:21 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904041946.AA19191@defun.utah.edu>
Date: Tue, 4 Apr 89 13:46:20 MDT
Subject: Re: Issue: LOAD-TIME-EVAL
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 4 Apr 89 15:11 EDT

Although I neglected to write down any notes on this issue at the
meeting, my recollection is that we agreed an amendment was not
necessary and that an editorial clarification would suffice.  It
didn't seem like a controversial point. 

-Sandra
-------

∂05-Apr-89  0807	CL-Compiler-mailer 	Re: issue PROCLAIM-ETC-IN-COMPILE-FILE  
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 5 Apr 89  08:06:59 PDT
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU;  5 Apr 89 11:06:25 EDT
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
cc: franz!fiseqs!feast!smh@ucbarpa.Berkeley.EDU (Steven M. Haflich),
    cl-compiler@sail.stanford.edu
Subject: Re: issue PROCLAIM-ETC-IN-COMPILE-FILE 
In-reply-to: Your message of Tue, 04 Apr 89 07:46:47 -0600.
             <8904041346.AA18918@defun.utah.edu> 
Date: Wed, 05 Apr 89 11:06:13 EDT
From: Rob.MacLachlan@WB1.CS.CMU.EDU


Although I hate to be caught arguing about names, I'll put in my two cents.
There is nothing particularly good about the name "PROCLAIM": it ended up
as the way to make a global declaration after it was decided that DECLARE
couldn't be used.  If PROCLAIM is going to be deprecated, then consistency
with proclaim is unimportant.

I suggest GLOBAL-DECLARE or DECLARE-GLOBALLY.

  Rob

∂05-Apr-89  0953	CL-Compiler-mailer 	Re: issue PROCLAIM-ETC-IN-COMPILE-FILE  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Apr 89  09:53:11 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571766; Wed 5-Apr-89 12:53:12 EDT
Date: Wed, 5 Apr 89 12:52 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue PROCLAIM-ETC-IN-COMPILE-FILE 
To: CL-Compiler@SAIL.Stanford.EDU
References: The message of 5 Apr 89 11:06 EDT from Rob.MacLachlan@WB1.CS.CMU.EDU
Message-ID: <890405125246.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

I just asked some people around here what they thought of this issue.
I talked to people mostly individually and didn't tell them until near
the end of discussion where any of the suggestions came from.
The people I talked to were David Andre (DLA), Scott Cyphers, Bob Laddaga, 
Charlie Hornig, and Scott McKay (SWM). The following is a summary of the
results.

 -----
 No one liked the name DEFPROCLAIM. (What a surprise...)

 When I mentioned the idea of a cross between PROCLAIM and DECLARE to
 Scott Cyphers he immediately said ``PROCLARE? No... DECLAIM? Yeah...''
 repeating what Steele had done. He was pleased when I told him
 DECLAIM was just the name we were thinking of.

 No one liked the name DECLARE-GLOBALLY. Several people noted that
 it was trying hard not to be GLOBAL.

 No one liked COMPILER-DECLARE, especially since we just flushed
 COMPILER-LET.

 To one degree or another, Laddaga, SWM, DLA, Cyphers and Hornig liked
 the names like FILE-DECLARE (or DECLARE-IN-FILE). Hornig also 
 suggested FILE-PROCLAIM. [In fact, since it's half PROCLAIM, half DECLARE,
 I think the way we should decide whether it's -DECLARE or -PROCLAIM
 if we go this route is to call it FILE-DECLARE if SPECIAL declarations
 are not pervasive and FILE-PROCLAIM otherwise.]

 Some people noted a possible conflict with a Zetalisp function called
 FILE-DECLARE but since that's in a different package, it's really not
 a concern.

 KMP, DLA, SWM, and Cyphers liked the name DECLAIM. Laddaga was initially
 unhappy with it but liked it better after the pun was explained.
 -----

My dictionary says, among other things, that ``declaim'' means to
``speak pompously of.'' Tracking the definitions of related words
around, you find lots of references to ``vainglory'' and ``self
importance.'' I personally think this is a completely appropriate
connotation for a declaration which effectively wants to be seen
as being as important as a proclamation but which we the readers
secretly know will never have the power to be one. It is effectively
a ``pretend proclamation.''  This is an after-the-fact justification,
but we've used weaker ones.

Btw, I feel a little like we're repeating the ``Tower nomination''
phenomenon here.  If you subject this poor little word to such scrutiny,
why not go back and subject other words in the language to equivalent
scrutiny. For example, similar arguments about the inappropriateness of
``proclaim'' could have been made -- ``proclaim'' sounds to me like it
ought to have been an I/O function.  But the fact is that I quickly
learned it as a formal term and didn't care much after the first
fifteen seconds.

If we chose this name, I wonder if we could also introduce an English
``claimed to be X'' mean ``proclaimed, declaimed, or declared to be X.''
I personally have always tired of having to write even
``proclaimed or declared...''

It was not initially obvious to me before this survey that it mattered
whether DECLAIM (or whatever) scoped to a file or a compilation unit,
but since discussion with Hornig it's clear to me that it must scope to
a file.

[I think that ultimately PROCLAIM should be made to scope to a
compilation unit when seen in a compile-time-too context, just as I
think that property list references, variable assignments, etc. should
do. But all of that is beyond the scope of what we are likely to get
done on this standardization pass unless it's necessary for CLOS.]

∂06-Apr-89  1140	CL-Compiler-mailer 	section 4.2    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 6 Apr 89  11:40:26 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA12460; Thu, 6 Apr 89 12:40:23 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA00636; Thu, 6 Apr 89 12:40:20 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904061840.AA00636@defun.utah.edu>
Date: Thu, 6 Apr 89 12:40:19 MDT
Subject: section 4.2
To: cl-compiler@sail.stanford.edu
Cc: cl-editorial@sail.stanford.edu

Some time ago, I promised Kathy Chapman that I would prepare a draft
of section 4.2 for the standard.  I've started to outline the
organization and decide which issues go where, which is what follows.
Any comments you have on this before I get started on serious writing
would be welcome.

The issues I've listed are those that are relevant to the discussion,
and I expect that in some cases not all of the material from the issue
will be included directly in that place.  For example, issue
COMPILED-FUNCTION-REQUIREMENTS will probably end up being distributed
between the subsections on COMPILE and COMPILE-FILE in section 4.2,
and the description of the COMPILED-FUNCTION data type in section 2.2.
I haven't yet figured out the details of exactly what sections will be
affected by each of our issues yet, but I do plan to put together a
list eventually (once section 4.2 starts to take shape).

-Sandra

---- cut here -------- cut here -------- cut here -------- cut here ----

Introduction
------------

The compiler is a utility that translates programs into an
implementation-dependent form that can be represented or executed more
efficiently.  Compiling a program involves resolving certain kinds of
references appearing within the code at compiletime, instead of
waiting until the program is actually run. 

In some implementations, compilation may happen implicitly.  For
example, it is permissible to implicitly compile all functions defined
with DEFUN or FUNCTION, or to implement EVAL so that it implicitly
compiles the form and then executes the resulting code.  Common Lisp
also provides tools (the functions COMPILE and COMPILE-FILE) for
explicitly forcing compilation to take place.


Time of Binding
---------------

[OK, we've said that the compiler works by resolving some things in
advance.  Now talk about exactly what those things are.]

[Issues:
  *COMPILE-ENVIRONMENT-CONSISTENCY
   PROCLAIM-INLINE-WHERE
   ALLOW-LOCAL-INLINE
   ]


COMPILE
-------

[What COMPILE is required to/allowed to do.]

[Issues:
   COMPILE-ARGUMENT-PROBLEMS
  *COMPILED-FUNCTION-REQUIREMENTS
   ]


COMPILE-FILE
------------

[Present our model of how the file compiler works.  List all
   the macros that do special compile-time magic.]

[Issues:
   COMPILER-DIAGNOSTICS
   COMPILER-VERBOSITY
   WITH-COMPILATION-UNIT
  *COMPILED-FUNCTION-REQUIREMENTS
   EVAL-WHEN-NON-TOP-LEVEL
   DEFINING-MACROS-NON-TOP-LEVEL
   LOCALLY-TOP-LEVEL
   COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
  *CLOS-MACRO-COMPILATION
  *PROCLAIM-ETC-IN-COMPILE-FILE
   IN-PACKAGE-FUNCTIONALITY
   COMPILE-FILE-PACKAGE
   ]


Compiler/Loader Interface
-------------------------

[How COMPILE-FILE tells LOAD to reconstruct objects appearing in
the source code.]

[Issues:
   CONSTANT-COMPILABLE-TYPES
  *CONSTANT-FUNCTION-COMPILATION
  *COMPILE-FILE-SYMBOL-HANDLING
   LOAD-OBJECTS
   CONSTANT-COLLAPSING
   CONSTANT-CIRCULAR-COMPILATION
   LOAD-TIME-EVAL (?)
   ]
-------

∂07-Apr-89  0954	CL-Compiler-mailer 	issue SYNTACTIC-ENVIRONMENT-ACCESS 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Apr 89  09:54:05 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA24296; Fri, 7 Apr 89 10:54:07 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA01427; Fri, 7 Apr 89 10:54:04 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904071654.AA01427@defun.utah.edu>
Date: Fri, 7 Apr 89 10:54:03 MDT
Subject: issue SYNTACTIC-ENVIRONMENT-ACCESS
To: cl-compiler@sail.stanford.edu

I have been trying to implement this proposal and I've run into a
problem with the VARIABLE-INFORMATION function.  As you'll recall, the
first value is supposed to indicate the type of definition or binding
and the second is supposed to indicate whether there is a local
binding.  The question is whether the second value applies only to the
kind of binding specified by the first value, or to any binding. 

For example, suppose I have the following code fragment:

(let ((x 'foo))
  (locally (declare (special x))
    x))

Clearly, in the environment inside the LOCALLY, the first value
returned for variable X should be :SPECIAL.  However, should the
second value be true or false?  There is a local binding of X, but
it's a lexical binding rather than a special binding.

Also, am I correct in assuming that any type declarations attached to
the lexical binding of X should not be visible inside the LOCALLY?

-Sandra
-------

∂10-Apr-89  0833	CL-Compiler-mailer 	lost mail 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 10 Apr 89  08:32:55 PDT
Received: by ti.com id AA06288; Mon, 10 Apr 89 10:34:36 CDT
Received: from Kelvin by tilde id AA29979; Mon, 10 Apr 89 10:28:17 CDT
Message-Id: <2817214056-9763549@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 10 Apr 89  10:27:36 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Compiler@SAIL.Stanford.edu
Cc: Bartley@mips.csc.ti.com
Subject: lost mail

There was some trouble with TI's Internet connection last week, so we have
lost incoming mail from Thursday March 30 until about noon Thursday April
6.  If you sent any mail during that period that we need to see, please
resend a copy to me and David Bartley.

∂10-Apr-89  1536	CL-Compiler-mailer 	Issue WITH-COMPILATION-UNIT (Version 4) 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 Apr 89  15:36:11 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 574760; Mon 10-Apr-89 18:36:07 EDT
Date: Mon, 10 Apr 89 18:35 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue WITH-COMPILATION-UNIT (Version 4)
To: CL-Compiler@SAIL.Stanford.EDU
Message-ID: <890410183527.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

v3 passed 11-6 with an amendment to say it defers "warnings" rather than
"actions" and with an amendment to say it does not apply to the COMPILE
function (only to COMPILE-FILE). I had to make this new version for my
records to reflect that one-word change. -kmp

-----
Forum:	      Compiler
Issue:        WITH-COMPILATION-UNIT
References:   COMPILE (p438), COMPILE-FILE (p439)
Category:     ADDITION
Edit history: 29-Sep-88, Version 1 by Pitman
	      10-Mar-89, Version 2 by Pitman (merge comments)
	      13-Mar-89, Version 3 by Loosemore (update discussion)
	      10-Apr-89, Version 4 by Pitman (wording change per X3J13)
Status:	      Ready for release

Problem Description:

  Some actions done by the compiler (and particularly the file compiler)
  are typically deferred until the "very end" of compilation.  For example,
  some compilers complain about "functions seen but not defined".

  Unfortunately, since COMPILE-FILE is the largest unit of granularity,
  and since systems often extend over more than one file, it often happens
  that the compiler needlessly complains at the end of compiling one file
  about the absence of functions defined in the next file. 

Proposal (WITH-COMPILATION-UNIT:NEW-MACRO):

  Add the following new macro:

   WITH-COMPILATION-UNIT options &BODY forms			[Macro]

   Executes forms from left to right. Within the dynamic context
   of this form, warnings deferred by the compiler until "the end of
   compilation" will be deferred until the end of the outermost call
   to WITH-COMPILATION-UNIT. The result(s) are the same as that of
   the last of the FORMS (or NIL if FORMS is null).

   OPTIONS is a keyword/value list, where only the values are
   evaluated. The set of keywords permitted may be extended by the
   implementation, but the only keyword defined by this standard is:

     :OVERRIDE boolean

       The default is NIL. If nested dynamically only the outer call
       to WITH-COMPILATION-UNIT has any effect unless BOOLEAN is T,
       in which case warnings are deferred only to the end of the
       innermost call.

  It follows that the functions COMPILE and COMPILE-FILE should
  provide the effect of (WITH-COMPILATION-UNIT (:OVERRIDE NIL) ...)
  around their code.

  Any implementation-dependent extensions may only be provided
  as the result of an explicit programmer request by use of 
  an implementation-dependent keyword.  Implementations are forbidden
  from attaching additional meaning to a conforming use of this
  macro.

  Note also that not all warnings are deferred. In some implementations,
  it may be that none are deferred. This proposal only creates an
  interface to the capability where it exists, it does not require the
  creation of the capability. An implementation which does not do 
  deferred warnings may correctly implement this as expanding into PROGN.

Test Case:

  (DEFUN COMPILE-FILES (&REST FILES)
    (WITH-COMPILATION-UNIT ()
      (MAPCAR #'(LAMBDA (FILE) (COMPILE-FILE FILE)) FILES)))

  (COMPILE-FILES "A" "B" "C")

  processes deferred warnings only after compiling all of A, B, and C.

Rationale:

  This will make the development of portable system-construction tools
  considerably more convenient. 

Current Practice:

  Lucid has a very similar facility, called WITH-DEFERRED-WARNINGS.

  TI Explorer and Symbolics Genera have a similar facility, which they
  call COMPILER-WARNING-CONTEXT-BIND.

Cost to Implementors:

  In implementations which have no deferred warnings, there is no cost.
  
  In implementations which have deferred warnings, the cost is probably
  fairly small -- usually just a matter of writing interfacing the 
  proposed macro to an existing one.

Cost to Users:

  None. This is a compatible addition.

Cost of Non-Adoption:

  Portable system-construction tools would continue to print lots of
  spurious warnings because they would have no way to tell the system
  that a set of files was working together.

Benefits:

  The cost of non-adoption is avoided.

Aesthetics:

  The ability to create a compilation unit other than a file is important.

Discussion:

  Pitman and Benson support this addition.

  One could imagine adding more options at a later date.

  It was the opinion of the compiler committee that there was room for
  expansion here to address issues like bounding the scope of global
  proclamations, sharing compile-time environments across files, etc.
  However, insufficient work was done on this to justify putting such
  a thing into the standard. The only clear need we have at this time
  was to defer warnings, but we chose a general name like 
  WITH-COMPILATION-UNIT rather than a specific name like Lucid's
  WITH-DEFERRED-WARNINGS in order to encourage implementations to 
  experiment with other kinds of options under implementation-specific
  keywords. Perhaps by the time of the next standard there will be
  sufficient understanding of this area to warrant further elaboration
  of this primitive.

  Kim Barrett says:

    I strongly oppose the behavior you proposed for compile and
    compile-file.  It is my belief that whether to override or not must be
    controlled through an argument to the compile functions, with the
    default being to override.  Otherwise, all existing code which makes
    use of the compile functions must be modified to protect itself by
    wrapping a (with-compilation-unit (:override t) ...) around the calls
    to the compiler.
    
    Consider a stream system built on an object system which will compose
    and compile functions on the fly on an as needed basis.  It would be
    very strange for the functions so generated while doing file io for
    the user's compile-file to have any relationship with said
    compile-file.
    
    I agree with your position that implementation-dependent extensions
    must be explicitly requested.

∂11-Apr-89  0952	CL-Compiler-mailer 	Issue: COMPILER-DIAGNOSTICS (Version 11)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 11 Apr 89  09:51:57 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 575223; Tue 11-Apr-89 12:51:52 EDT
Date: Tue, 11 Apr 89 12:51 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMPILER-DIAGNOSTICS (Version 11)
To: CL-Compiler@SAIL.Stanford.EDU
Message-ID: <890411125108.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

This has the change to make it conform to what we actually voted on:
 - strike sentence 1 of item 3 per X3J13.
Everything else is as before.

-----
Forum:		Compiler
Issue:		COMPILER-DIAGNOSTICS
References:	CLtL p. 438-439, 62, 69, 160, 161
		Condition System, Revision #18
	    	S:>KMP>cl-conditions.text.34
	    	Issue GC-MESSAGES
	    	Issue RETURN-VALUES-UNSPECIFIED
	    	Issue COMPILER-VERBOSITY
		Issue CONDITION-RESTARTS
Category:	CLARIFICATION, ENHANCEMENT
Edit History:   V1, 15 Oct 1988, Sandra Loosemore
	    	V2, 19 Oct 1988, Sandra Loosemore (minor fixes)
	    	V3, 25 Oct 1988, Sandra Loosemore (input from Pitman & Gray)
	    	V4, 01 Nov 1988, Sandra Loosemore (fix typos)
	   	V5, 15 Dec 1988, Dan L. Pierson   (new condition types)
	   	V6, 15 Dec 1988, Sandra Loosemore (additions, fix wording)
	    	V7, 16 Dec 1988, Dan L. Pierson   (minor cleanup)
		V8, 07 Jan 1989, Sandra Loosemore (expand discussion)
		V9, 26 Jan 1989, Sandra Loosemore (simplify)
		V10, 22 Mar 1989, Sandra Loosemore (error terminology)
	        V11, 11 Apr 1989, Kent Pitman (changes per X3J13)
Status:		Ready for release
     
Problem Description:

It is unclear whether various diagnostics issued by the compiler are 
supposed to be true errors and warnings, or merely messages.

In some implementations, COMPILE-FILE handles even serious error
situations (such as syntax errors) by printing a message and then
trying to recover and continue compiling the rest of the file, rather
than by signalling an error.  While this user interface style is just
as acceptable as invoking the debugger, it means that a normal return
from COMPILE-FILE does not necessarily imply that the file was
successfully compiled.

Many compilers issue warnings about programming style issues (such as
binding a variable that is never used but not declared IGNORE).
Sometimes these messages obscure warnings about more serious problems,
and there should be some way to differentiate between the two.  For
example, it should be possible to suppress the style warnings.

Also, neither CLtL nor issue RETURN-VALUES-UNSPECIFIED states what the 
return value from COMPILE-FILE should be.


Proposal COMPILER-DIAGNOSTICS:USE-HANDLER:

(1) Introduce a new condition type, STYLE-WARNING, which is a subtype
    of WARNING.

(2) Clarify that ERROR and WARNING conditions may be signalled within 
    COMPILE or COMPILE-FILE, including arbitrary errors which may 
    occur due to compile-time processing of (EVAL-WHEN (COMPILE) ...) 
    forms or macro expansion.

    Considering only those conditions signalled -by- the compiler (as
    opposed to -within- the compiler),

    (a) Conditions of type ERROR may be signalled by the compiler in
        situations where the compilation cannot proceed without
        intervention.

        Examples:
	    file open errors
   	    syntax errors

    (b) Conditions of type WARNING may be signalled by the compiler in 
        situations where the standard explicitly states that a warning must,
        should, or may be signalled; and where the compiler can determine 
        that a situation with undefined consequences or that would cause
        an error to be signalled would result at runtime.

        Examples:
	    violation of type declarations
	    SETQ'ing or rebinding a constant defined with DEFCONSTANT
	    calls to built-in Lisp functions with wrong number of arguments
	        or malformed keyword argument lists
	    referencing a variable declared IGNORE
	    unrecognized declaration specifiers

    (c) The compiler is permitted to signal diagnostics about matters of
        programming style as conditions of type STYLE-WARNING.  Although 
        STYLE-WARNINGs -may- be signalled in these situations, no 
        implementation is -required- to do so.  However, if an 
        implementation does choose to signal a condition, that condition 
        will be of type STYLE-WARNING and will be signalled by a call to 
        the function WARN.

        Examples:
	    redefinition of function with different argument list
	    calls to function with wrong number of arguments
	    unreferenced local variables not declared IGNORE
	    declaration specifiers described in CLtL but ignored by 
	        the compiler

(3) State that both COMPILE and COMPILE-FILE are allowed to establish 
    a default condition handler.  If such a condition handler is 
    established, however, it must first resignal the condition to give any
    user-established handlers a chance to handle it.  If all user error
    handlers decline, the default handler may handle the condition in an
    implementation-specific way; for example, it might turn errors into
    warnings.

(4) Specify that COMPILE-FILE returns two values.  The first value
    is the truename of the output file, or NIL if the file could not be
    created.  The second value is T if the file was compiled without
    errors, or NIL if errors were signalled during compilation.


Rationale:

Introducing the STYLE-WARNING condition allows handlers to distinguish
between potentially serious problems and mere kibitzing on the part of
the compiler.

Requiring any condition handlers established by the compiler to resignal
the condition before proceeding with any implementation-specific action
gives user error handlers a chance to override the compiler's default
behavior.  For example, the user error handler could invoke a restart
such as ABORT or MUFFLE-WARNING.

Requiring the compiler to handle the ABORT restart reflects what
several implementations already do (although probably not using this
mechanism).  The intent of the wording is to allow an implementation
to abort the entire compilation if it is not feasible to abort a
smaller part.

Requiring a second success-p value to be returned from COMPILE-FILE
gives the user some indication of whether there were serious problems
encountered in compiling the file.


Test Case/Example:

Here is an example of how COMPILE-FILE might set up its condition
handlers.  It establishes an ABORT restart to abort the compilation
and a handler to take implementation-specific action on ERROR
conditions.  Note that INTERNAL-COMPILE-FILE may set up additional
ABORT restarts.

    (defvar *output-file-truename* nil)

    (defun compile-file (input-file &key output-file)
      (let ((*output-file-truename*    nil)
 	    (errors-detected           nil))
	(with-simple-restart (abort "Abort compilation.")
	  (handler-bind ((error  #'(lambda (condition)
				     (setq errors-detected t)
				     (signal condition)
				     ...)))
	    (internal-compile-file input-file output-file)))
	(values *output-file-truename*
		errors-detected)))



Current Practice:

No implementation behaves exactly as specified in this proposal.

In VaxLisp, COMPILE-FILE handles most compile-time errors without
invoking the debugger.  (It gives up on that top-level form and moves on
to the next one.)  Instead of signalling errors or warnings, it simply
prints them out as messages.

In Lucid Common Lisp, COMPILE-FILE invokes the debugger when it encounters
serious problems.  COMPILE-FILE returns the pathname for the output file.

Symbolics Genera usually tries to keep compiling when it encounters errors;
so does Symbolics Cloe.

On the TI Explorer, the compiler tries to catch most errors and turn
them into warnings (except for errors on opening a file), but the user
can change special variable COMPILER:WARN-ON-ERRORS to NIL if he wants
to enter the debugger on an error signalled during reading, macro
expansion, or compile-time evaluation.  The true name of the output
file is returned as the first value.  A second value indicates whether
any errors or warnings were reported.

IIM Common Lisp's compiler handles errors using a resignalling mechanism
similar to what is described here.


Cost to implementors:

The cost to implementors is not trivial but not particularly high.  This
proposal tries to allow implementations considerable freedom in what
kinds of conditions the compiler must detect and how they are handled,
while still allowing users some reasonably portable ways to deal with
compile-time errors.


Cost to users:

This is a compatible extension.  This proposal may cause users to see
some small differences in the user interface to the compiler, but
implementations already vary quite widely in their approaches.  Some
users will probably have to make some minor changes to their code.

Adding the STYLE-WARNING type may cause conflicts with programs
already using that name.


Benefits:

Users are given a way to detect and handle compilation errors, which
would simplify the implementation of portable code-maintenance
utilities.  The behavior of the compiler in error situations is made
more uniform across implementations.


Discussion:

The issue of whether the compiler may print normal progress messages
is discussed in detail in a separate issue, COMPILER-VERBOSITY.

Explicit calls to ERROR don't really justify warnings to be signalled
at compile-time, but we assume implementors have some common sense
about when it's appropriate to do so.

Proposal CONDITION-RESTARTS:PERMIT-ASSOCIATION would make it illegal
for conditions to be resignalled.  If that proposal is accepted, the
wording here would have to be changed to indicated that the compiler's
condition handler makes a copy of the condition and signals that.

Moon says:

  I think [requiring the ABORT restart to be handled] is wrong.  The only
  documentation of the ABORT restart that I could find says
  
    The purpose of the ABORT restart is generally to allow return to the
    innermost ``command level.''
  
  I agree with this, and I believe it means that it is wrong for any
  function other than one that establishes a read-eval-print loop or
  a command-level to establish an ABORT restart.  It would be useful
  to have some restart that aborts a portion of the compilation, but
  it should be given some other name.


∂11-Apr-89  1012	CL-Compiler-mailer 	Issue: CONSTANT-COMPILABLE-TYPES (Version 10)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 11 Apr 89  10:12:32 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 575239; Tue 11-Apr-89 13:12:37 EDT
Date: Tue, 11 Apr 89 13:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONSTANT-COMPILABLE-TYPES (Version 10)
To: CL-Compiler@SAIL.Stanford.EDU
Message-ID: <890411131153.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

This is changed to reflect what was voted at X3J13...
 - strike "generic function" from list near end of type list
   in proposal (effectively constraining gf's to behave like other functions).
The rest is exactly like v9.
 -kmp

-----
Forum:		Compiler
Issue:		CONSTANT-COMPILABLE-TYPES
References:	CLtL pp. 56, 77-80, 324
		Issue CONSTANT-MODIFICATION
		Issue CONSTANT-CIRCULAR-COMPILATION
		Issue CONSTANT-COLLAPSING
		Issue QUOTE-SEMANTICS
		Issue LOAD-OBJECTS
		Issue CONSTANT-FUNCTION-COMPILATION
Category:	CLARIFICATION, ADDITION
Edit history:	11/07/88, V1 by Cris Perdue
		11/14/88, V2 by Cris Perdue
		11/22/88, V3 by Cris Perdue
		12/20/88, V4 by Cris Perdue
		01/06/89, V5 by Sandra Loosemore (minor editorial
			clarifications, expand discussion)
		03/05/89, V6 by Cris Perdue (more response to comments,
			especially from Moon and and from Loosemore)
                03/05/89, V7 by Loosemore (more editorial tweaks)
		03/13/89, V8 by Loosemore (discussion)
		03/22/89, V9 by Loosemore (restructure)
	        04/11/89, V10 by Pitman (changes per X3J13)
Status:		Ready for release

Problem description:

CLtL does not specify what objects can be in compiled constants and it
does not say what relationship there is to be between the constant
passed to the compiler and the one that is established by compiling
and then loading its file.  Relevant remarks in CLtL concerning file
compilation and the definition of QUOTE suggest that the compiler
handles constants in ways that are not actually possible.


Introduction to the proposal:

The proposal CONSTANT-COMPILABLE-TYPES:SPECIFY attempts to spell out
what types can appear in compiled constants, and what it means when
they appear.

The key is a definition of an equivalence relationship between Lisp
objects, "similarity as constants".  Code passed through the file
compiler and then loaded must behave as though quoted constants in it
are "similar" to quoted constants in the corresponding source code.

Issue CONSTANT-COLLAPSING addresses the issue of whether, for two
objects that are not EQL in the source code (but which are similar as
constants), the corresponding objects in the compiled code may be
EQL.

Issue CONSTANT-CIRCULAR-COMPILATION addresses the issue of whether,
for two objects that are EQL in the source code, the corresponding
objects in the compiled code must also be EQL.

Comments within the text of the proposal are enclosed in double angle
brackets, <<like this>>.


Proposal:  CONSTANT-COMPILABLE-TYPES:SPECIFY

An object may be used as a quoted constant processed by COMPILE-FILE
if the compiler can guarantee that the resulting constant established
by loading the compiled file is "similar as a constant" to the
original.

Some types of objects, such as streams, are not supported in constants
processed by the file compiler.  Such objects may not portably appear
as constants in code processed with COMPILE-FILE.  Conforming
implementations are required to handle such objects either by having
the compiler and/or loader reconstruct an equivalent copy of the
object in some implementation-specific manner; or by having the
compiler signal an error.

Of the types supported in constants, some are treated as aggregate
objects.  For these types, being similar as constants is defined
recursively.  We say that an object of these types has certain "basic
attributes", and to be similar as a constant to another object, the
values of the corresponding attributes of the two objects must also be
similar as constants.

This kind of definition has problems with any circular or "infinitely
recursive" object such as a list that is an element of itself.  We use
the idea of depth-limited comparison, and say that two objects are
similar as constants if they are similar at all finite levels.  This
idea is implicit in the definitions below, and applies in all the
places where attributes of two objects are required to be similar as
constants.

The following terms are used throughout this proposal:

  The term "constant" refers to a quoted or self-evaluating constant,
  not a named (defconstant) constant.

  The term "source code" is used to refer to the objects constructed
  when COMPILE-FILE calls READ, and additional objects constructed by
  macroexpansion during COMPILE-FILE.

  The term "compiled code" is used to refer to objects constructed by 
  LOAD.

Two objects are defined to be "similar as a constant" if and only if
they are both of one of the types listed below and satisfy the
additional requirements listed for that type.

Number

  Two numbers are similar as constants if they are of the same type
  and represent the same mathematical value.
  
Character

  Two characters are similar as constants if they both represent
  the same character.

  <<Note that this definition has to depend on the results of the
  Character Set proposals.  The intent is that this be compatible with
  how EQL is defined on characters.>>

Symbol

  Issue COMPILE-FILE-SYMBOL-HANDLING defines how the file compiler
  and loader handle interned symbols.

  An uninterned symbol in the source code is similar as a constant
  to an uninterned symbol in the compiled code if their print names
  are similar as constants.

Package

  A package in the source code is similar as a constant to a package in
  the compiled code if their names are similar as constants.  Note that
  the loader finds the corresponding package object as if by calling
  FIND-PACKAGE with the package name as an argument.  An error is
  signalled if no package of that name exists at load time.

Random-state

  Let us say that two random-states are functionally equivalent if 
  applying RANDOM to them repeatedly always produces the same 
  pseudo-random numbers in the same order.  
  
  Two random-states are similar as constants if and only if copies of
  them made via MAKE-RANDOM-STATE are functionally equivalent.

  Note that a constant random-state object cannot be used as the "state"
  argument to the function RANDOM (because RANDOM side-effects this
  data structure).

Cons

  Two conses are similar as constants if the values of their respective
  CAR and CDR attributes are similar as constants.

Array

  Two arrays are similar as constants if the corresponding values each
  of the following attributes are similar as constants:

  For 1-dimensional arrays:
  LENGTH, ARRAY-ELEMENT-TYPE, and ELT for all valid indices.

  For arrays of other dimensions:
  ARRAY-DIMENSIONS, ARRAY-ELEMENT-TYPE, AREF for all valid indices.

  In addition, if the array in the source code is a SIMPLE-ARRAY, then
  the corresponding array in the compiled code must also be a
  SIMPLE-ARRAY.  If the array in the source code is displaced, has a
  fill pointer, or is adjustable, the corresponding array in the
  compiled code is permitted to lack any or all of these qualities.

Hash Table   

  Two hash tables are similar as constants if they meet the following
  three requirements:

  (1) They both have the same test (e.g., they are both EQL hash tables).

  (2) There is a unique one-to-one correspondence between the keys of
      the two tables, such that the corresponding keys are similar as
      constants.

  (3) For all keys, the values associated with two corresponding keys
      are similar as constants.

  If there is more than one possible one-to-one correspondence between
  the keys of the two tables, the results are unspecified.  A conforming
  program cannot use such a table as a constant.

Pathname

  Two pathnames are similar as constants if all corresponding pathname
  components are similar as constants.

Stream, Readtable, Method

  Objects of these types are not supported in compiled constants.

Function

  Issue CONSTANT-FUNCTION-COMPILATION specifies how the compiler and
  loader handle constant functions.


Structure, Standard-object

  <<There is a cl-cleanup issue, LOAD-OBJECTS, pending which proposes
  a mechanism for dealing with objects.>>


Rationale:

For the benefit of users, this proposal tries to define a fairly large
set of types that all Common Lisp implementations are to handle.  It
also attempts to leave room for implementations to differ.  Some
implementations have made opposing choices because the language
doesn't specify one over the other.  Some implementations already
handle constants that this proposal defines as not valid in Common
Lisp programs, and that is useful to users of those systems.
Different implementors have different amounts of resources to apply to
their system, and implementations differ in their whole approach in
some cases.

This proposal appears to reflect user demand and appears not to exceed
the capabilities of most implementations of the language.


Current practice:

>From Gail Zacharias (Nov 14): "Coral pretty much implements this
proposal (I think we currently coalesce hash table keys, but that's
just a bug that will be fixed).  We also fasdump packages (using the
package name) and compiled functions (but not foreign functions).  For
symbols, we dump the name, and if (roughly speaking) the symbol would
get printed with a package prefix, we also dump the package name and
load the symbol into that package (otherwise it gets loaded into the
current load-time package)."

>From David Gray (Nov 9): "The Explorer can compile constant functions,
read tables, and hash tables; an error is signalled for a stream.  A
package object used to break the compiler but in release 5 it has been
fixed to generate instructions to call FIND-PACKAGE on the package
name at load time."  (Nov 15): [The Explorer does not guarantee
retention of displaced-to and displaced-index-offset attributes.]
"The Explorer also does not currently support dumping closures (either
compiled or evaluated), although non-closure compiled functions can be
dumped."

>From David Moon (Jan 24): "Symbolics Genera current practice: aside
from some current bugs we have with circular structures of certain
types and with preserving the identity of CONSes under EQ, this is
more or less consistent with our current practice, if you made the
changes implied by my earlier comments.  We preserve the :displaced-to
and :fill-pointer array attributes.  I doubt that we do what the
proposal says for hash-tables, readtables, and random-states.  We
support dumping compiled and interpreted functions, but not closures,
which in effect means we don't support dumping functions."

>From Sandra Loosemore (Mar 3): "UCL currently can handle only
constants that are of type number, character, symbol, cons,
simple-vector, or string (which it turns into simple-string).  It
signals an error if an attempt is made to compile any other kind of
object as a constant."


Adoption cost:

Not known.  Probably moderate or low -- for most implementations.  The
cost would be to implementors rather than users since this part of the
language is currently underspecified.  The author believes the cost
will be reasonable for KCL, an implementation where there is some
concern about this issue.

This proposal is close to compatible with the Franz, Lucid, Coral,
Texas Instruments, and Symbolics implementations.  It is probably
compatible or nearly compatible with other "Lisp Machine"
implementations.


Benefits:

Users would be able to use aggregate objects in constants with
confidence about the behavior of their code.


Conversion cost:

Where this proposal *requires* different behavior than an existing
implementation, there is a conversion cost for users of that
implementation.  It appears that this cost will be small, less than
the cost of leaving things unspecified.


Esthetics:

Since there is no adequate definition at present, a fuller definition
would be more esthetic.


Discussion:

This proposal does leave some user-visible attributes of objects
unspecified across the compile-and-load process, except that they must
be consistent with the attributes that must be retained.  This
situation is a compromise between the desire for full specification on
the one hand, and on the other hand the desire to leave freedom for
different implementations to remain different and to support some
optimizations such as compacting hash tables and "simplifying" arrays.

Proposals will be entertained for tighter specification of datatypes
such as arrays.

The definition of similarity for random-states supports the
possibility of random states that are immutable because of being in
compiled constants.

Readtables need not be supported by an implementation.  If a readtable
contains only symbols to represent functions, here is Cris Perdue's
suggested spec for similarity of readtables:

  Character syntax type for each character in the table;
  function for each readmacro character, mappings for
  dispatch macros; whether terminating or nonterminating
  for each readmacro.

Interest has been expressed by a number of people including users, in
support for user-definable "dumping" of CLOS objects and structure
instances.  The cleanup issue LOAD-OBJECTS deals with this.

This subsumes the issue CONSTANT-ARRAY-ATTRIBUTES.

Earlier versions of this proposal specified an additional constraint
on uninterned symbols, requiring EQLness to be preserved across the
entire file.  However, this special case was removed because it was
thought that including it in this issue made its presentation
unnecessarily complicated, since preservation of EQLness is really a
separate issue (CONSTANT-CIRCULAR-COMPILATION).  A consequence of the
decision to remove the special casing for uninterned symbols is that,
unless we accept one of the two CONSTANT-CIRCULAR-COMPILATION
proposals that requires EQLness of constants to be preserved, the
behavior for uninterned symbols will be rather strange.  PCL will
reportedly break if uninterned symbols that are EQL in the source code
do not remain EQL in the compiled code.

∂12-Apr-89  0657	CL-Compiler-mailer 	Re: Issue: COMPILER-DIAGNOSTICS (Version 11) 
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 12 Apr 89  06:56:51 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ae03074; 12 Apr 89 9:56 EDT
Received: from draper.com by RELAY.CS.NET id aa12057; 12 Apr 89 9:49 EDT
Date: Wed, 12 Apr 89 07:39 EDT
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue: COMPILER-DIAGNOSTICS (Version 11)
To: cl-compiler@SAIL.STANFORD.EDU
X-VMS-To: CL-COMPILER,SEB1525

> (4) Specify that COMPILE-FILE returns two values.  The first value
>     is the truename of the output file, or NIL if the file could not be
>     created.  The second value is T if the file was compiled without
>     errors, or NIL if errors were signalled during compilation.   
 
Fine.  But in that case, the example...
 
>     (defun compile-file (input-file &key output-file)
...
> 	(values *output-file-truename*
>      		errors-detected)))

should be (values *output-file-truename* no-errors-detected-p), n'est-ce pas?

> On the TI Explorer, ...
> file is returned as the first value.  A second value indicates whether
> any errors or warnings were reported.
 
Which way does TI do it?  Is it T for no errors, or NIL for no errors?



∂12-Apr-89  0904	CL-Compiler-mailer 	Re: Issue: COMPILER-DIAGNOSTICS (Version 11) 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 12 Apr 89  09:04:05 PDT
Received: by ti.com id AA24195; Wed, 12 Apr 89 11:03:57 CDT
Received: from Kelvin by tilde id AA23959; Wed, 12 Apr 89 10:54:57 CDT
Message-Id: <2817388475-116809@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 12 Apr 89  10:54:35 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Cc: cl-compiler@SAIL.STANFORD.EDU
Subject: Re: Issue: COMPILER-DIAGNOSTICS (Version 11)
In-Reply-To: Msg of Wed, 12 Apr 89 07:39 EDT from "Steve Bacher (Batchman)" <SEB1525@draper.com>

> > On the TI Explorer, ...
> > file is returned as the first value.  A second value indicates whether
> > any errors or warnings were reported.
>  
> Which way does TI do it?  Is it T for no errors, or NIL for no errors?

Actually, it is a fixnum representing the severity level, with zero
meaning nothing is wrong.  Not very Lisp-ish.

∂18-Apr-89  2114	CL-Compiler-mailer 	issue CONSTANT-FUNCTION-COMPILATION
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 18 Apr 89  21:14:03 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA17421; Tue, 18 Apr 89 14:43:47 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA06493; Tue, 18 Apr 89 14:43:45 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904182043.AA06493@defun.utah.edu>
Date: Tue, 18 Apr 89 14:43:43 MDT
Subject: issue CONSTANT-FUNCTION-COMPILATION
To: cl-compiler@sail.stanford.edu
Cc: rpg@sail.stanford.edu

Just a reminder, this issue was tabled at the last meeting so people
could think about alternate proposals.  I personally think the
existing proposal NO is acceptable and I have a lot of other things to
spend my time on, so the initiative on this issue is going to have to
come from somebody else.  (Hint, hint.)

I will, however, take the time to lobby *against* any new proposal
that doesn't provide answers to both of the questions in the "problem
description" section:

  How does one test whether a particular function is a member of the
  subset of functions that are dumpable?

  For those functions that are dumpable, how do COMPILE-FILE and LOAD
  arrange for an "equivalent" copy of the function in the source code to
  be created in the compiled code?

-Sandra
-------

∂18-Apr-89  2119	CL-Compiler-mailer 	issue COMPILE-FILE-SYMBOL-HANDLING, version 3
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 18 Apr 89  21:14:22 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA16805; Tue, 18 Apr 89 14:33:25 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA06483; Tue, 18 Apr 89 14:33:21 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904182033.AA06483@defun.utah.edu>
Date: Tue, 18 Apr 89 14:33:20 MDT
Subject: issue COMPILE-FILE-SYMBOL-HANDLING, version 3
To: cl-compiler@sail.stanford.edu

At last month's meeting, we agreed that compromising on some variant
of proposal REQUIRE-CONSISTENCY was the only practical solution on
this issue, but several people have indicated they think it's
unacceptable to restrict IN-PACKAGE to being the first form in the
file.  Here's a modified proposal that tries to get around that
problem.

Forum:		Compiler
Issue:		COMPILE-FILE-SYMBOL-HANDLING
References:	CLtL p. 182
		Issue IN-PACKAGE-FUNCTIONALITY (passed)
		Issue CONSTANT-COMPILABLE-TYPES (passed)
		Issue DEFPACKAGE (passed)
Category:	CHANGE/CLARIFICATION 
Edit History:   V1, 01 Feb 1989, Sandra Loosemore
		V2, 12 Mar 1989, Sandra Loosemore (discussion, error terms)
		V3, 18 Apr 1989, Sandra Loosemore (new proposal)
Status:		Ready for release


Problem Description:

It is not clear how COMPILE-FILE is supposed to specify to LOAD how
symbols in the compiled file should be interned.  In particular, what
happens if the value of *PACKAGE* is different at load-time than it
was at compile-time, or if any of the packages referenced in the file
are defined differently?

There are two models currently being used to implement this behavior:

  (1) Symbols appearing in the output file produced by COMPILE-FILE
      are qualified with package prefixes in the same way that PRINT
      would qualify them.  Symbols that are accessible in *PACKAGE*
      at compile-time are looked up in *PACKAGE* at load-time.  (This
      is the "current-package" model.)

  (2) Symbols appearing in the output file produced by COMPILE-FILE
      are always qualified with the name of their home package,
      regardless of the value of *PACKAGE*.  (This is the
      "home-package" model.)


Proposal COMPILE-FILE-SYMBOL-HANDLING:NEW-REQUIRE-CONSISTENCY:

  In order to guarantee that compiled files can be loaded correctly,
  users must ensure that the packages referenced in the file are defined
  consistently at compile and load time.  Conforming Common Lisp programs
  must satisfy the following requirements:
  
  (1) The value of *PACKAGE* when a top-level form in the file is processed
      by COMPILE-FILE must be the same as the value of *PACKAGE* when the
      code corresponding to that top-level form in the compiled file is
      executed.  In particular:

      (a) Any top-level form in a file which alters the value of *PACKAGE*
          must change it to a package of the same name at both compile and
          load time.

      (b) If the first top-level form in the file is not a call to
          IN-PACKAGE, then the value of *PACKAGE* at the time LOAD is
          called must be a package with the same name as the package that
          was the value of *PACKAGE* at the time COMPILE-FILE was called.

  (2) For all symbols appearing lexically within a top-level form that
      were accessible in the package that was the value of *PACKAGE*
      during processing of that top-level form at compile time, but
      whose home package was another package, at load time there must
      be a symbol with the same name that is accessible in both the
      load-time *PACKAGE* and in the package with the same name as the
      compile-time home package. 
  
  (3) For all symbols in the compiled file that were external symbols in
      their home package at compile time, there must be a symbol with the
      same name that is an external symbol in the package with the same name
      at load time.
        
  If any of these conditions do not hold, the package in which LOAD looks
  for the affected symbols is unspecified.  Implementations are permitted 
  to signal an error or otherwise define this behavior.
  
  If all of these conditions hold, then when a compiled file is
  loaded, the interned symbols it references are found by calling
  INTERN at load time with two arguments, the name of the symbol and
  the package with the same name as the compile-time symbol's home
  package.  If no such package exists, an error is signalled.

  Rationale:

    This proposal is merely an explicit statement of the status quo,
    namely that users cannot depend on any particular behavior if the
    package environment at load time is inconsistent with what existed
    at compile time. 

    This proposal supports both the current-package and home-package
    models as implementation techniques. 

Current Practice:

  PSL/PCLS implements the home-package model, as does A-Lisp.  Utah
  Common Lisp implements the current-package model, but the chief
  compiler hacker says he thinks that the home-package model
  actually makes more sense, and agrees that any program that behaves
  differently under the two proposals is broken. 

  The TI Explorer currently implements the home-package model, after
  trying it both ways.
  
  KCL also implements the home-package model.
  
  Lucid Lisp appears to implement the current-package model.

  Symbolics Genera implements the current-package model.  Symbolics
  Cloe probably does also.
  
  Coral also implements the current-package model.
  
  
Cost to implementors:

  Proposal NEW-REQUIRE-CONSISTENCY is intended to be compatible with either
  of the two models, but it may not be entirely compatible with the 
  details of current implementations.

  In particular, some implementations that use the current-package
  model appear to restrict IN-PACKAGE to being the first top-level
  form in the file and dump all symbols referenced in the file after
  the entire file has been processed (so that the value of *PACKAGE*
  used to determine whether to qualify symbols in the output file is
  the same for all symbols in the file).  Under this proposal, these
  implementations would have to note when the value of *PACKAGE*
  changes during processing of a top-level form.


Cost to users:

  Any user program that would break under proposal NEW-REQUIRE-CONSISTENCY
  is probably already nonportable, since this proposal is intended to
  leave the behavior unspecified where it would differ under the
  two implementation models.

  For a discussion of how the two models treat nonportable or erroneous
  programs, see the "Analysis" section below.
  
  
Benefits:

  COMPILE-FILE's treatment of symbols is made explicit in the standard.
  
  
Analysis:

  The two implementation models differ in the following situations.
  Proposal NEW-REQUIRE-CONSISTENCY, in effect, says that valid programs do
  not cause any of these situations to occur, and the behavior in such
  cases is unspecified (allowing both models to be used as valid
  implementation techniques).
  
  (1) The situation where the file does not contain a IN-PACKAGE
      and where the compile-time value of *PACKAGE* is a package with a
      different name than the load-time value of *PACKAGE*.
      
      The current-package model would intern the names of symbols that 
      were accessible in *PACKAGE* at compile time in *PACKAGE* at load time.
      
      The home-package model would intern the names of symbols that
      were accessible in *PACKAGE* at compile time in the package with
      the same name as their compile-time home package.
      
      In general, programs must be compiled in the "right" package, so
      that the compiler can find and apply the correct macro expansions,
      type definitions, and so on; see issue COMPILE-ENVIRONMENT-CONSISTENCY.
      As a result of macroexpansion or other transformations applied by
      the compiler, the compiled file may contain symbol references that
      were not present in the source file.  The current-package model may
      cause problems because these references may be resolved to be
      symbols other than the ones that were intended.  The home-package
      model is more likely to find the correct symbols at load time.
          
  (2) The situation where there is a symbol accessible in the
      compile-time value of *PACKAGE* but with another home package, and
      where at load time there is not a symbol with the same name that
      is accessible in both packages.  This situation might occur, for
      example, if at compile time there is a symbol that is external in
      its home package and that package is used by *PACKAGE*, but where
      there is no such external symbol in that package at load time, or
      the load-time *PACKAGE* does not use the other package.
      
      The current-package model would find or create a symbol accessible
      in *PACKAGE*.
      
      The home-package model would find or create a symbol accessible in
      a package with the same name as the symbol's compile-time home
      package.
      
      Some people feel that the behavior of the current-package model is
      more intuitive in this situation, and that it is more forgiving of
      differences between the compile-time and load-time package
      structures.  Others feel that the behavior of the home-package
      model is more intuitive, and that if there have been significant
      changes to the package structures, it is probably an indication
      that the file needs to be recompiled anyway, since the compiler
      might have picked up macro definitions and the like from the
      wrong package. 
  
  (3) The situation where a symbol is external in its home package
      and where there is no such external symbol in that package at load
      time.
      
      The current-package model would quietly find or create the symbol
      in *PACKAGE* if the symbol were accessible in *PACKAGE* at compile
      time.  Otherwise, it will signal an error.
      
      The home-package model would always just quietly find or create the 
      symbol as internal in its home package.
      
      Not complaining when a symbol that is supposed to be external
      isn't can be seen as a violation of modularity.  However, it seems
      like this argument should apply equally to symbols whose home
      package is *PACKAGE* as symbols whose home package is somewhere
      else.
          

Discussion:

-------

∂19-Apr-89  0835	CL-Compiler-mailer 	Re: Issue COMPILE-FILE-SYMBOL-HANDLING, version 3 
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 19 Apr 89  08:31:06 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa20099; 19 Apr 89 11:30 EDT
Received: from draper.com by RELAY.CS.NET id ac11321; 19 Apr 89 11:28 EDT
Date: Wed, 19 Apr 89 07:52 EDT
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue COMPILE-FILE-SYMBOL-HANDLING, version 3
To: cl-compiler@SAIL.STANFORD.EDU
X-VMS-To: CL-COMPILER,SEB1525

I'm still not clear on one thing.  What happens if you have a file compiled
with *PACKAGE* set to a package C, and loaded in an environment with
*PACKAGE* set to a package L, and the "current-package" model is in use,
when the compiled file contains two symbols that appear as
   symbol1    and   c:symbol2
Both symbols will be read into package C, but according to the
"current-package" model, symbol1 should be loaded into package L and symbol2
should be interned in package C at load time.
 
My question:  How is the compiler supposed to tell whether or not the sm
ybol
name was qualified in the input file?  Presumably it gets the symbol via READ,
which doesn't transmit any indication of whether the package qualification
was explicit or not.
 
So how can it distinguish between symbol-name and current-package:symbol-name?
 
I contend that for this reason, the "current-package" model is unworkable.
This may not be an issue any longer, but I think this is sufficient
justification for the "home-package" model being the only reasonable one.

∂19-Apr-89  0841	CL-Compiler-mailer 	Re: Issue COMPILE-FILE-SYMBOL-HANDLING, version 3 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Apr 89  08:41:48 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA13163; Wed, 19 Apr 89 09:41:51 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA06990; Wed, 19 Apr 89 09:41:48 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904191541.AA06990@defun.utah.edu>
Date: Wed, 19 Apr 89 09:41:47 MDT
Subject: Re: Issue COMPILE-FILE-SYMBOL-HANDLING, version 3
To: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Cc: cl-compiler@SAIL.STANFORD.EDU
In-Reply-To: "Steve Bacher (Batchman)" <SEB1525@draper.com>, Wed, 19 Apr 89 07:52 EDT

> Date: Wed, 19 Apr 89 07:52 EDT
> From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
> 
> My question: How is the compiler supposed to tell whether or not the
> symbol name was qualified in the input file?  Presumably it gets the
> symbol via READ, which doesn't transmit any indication of whether the
> package qualification was explicit or not. 

The answer is, it can't.  The "current package" model depends on
knowing whether the symbol would have to be qualified with a package
prefix if it were PRINTed (not READ), using whatever value of
*PACKAGE* happens to be "current" at the time. 

-Sandra
-------

∂19-Apr-89  0948	CL-Compiler-mailer 	Re: Issue COMPILE-FILE-SYMBOL-HANDLING, version 3 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 19 Apr 89  09:48:20 PDT
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
	id AA09885; Wed, 19 Apr 89 09:50:59 PDT
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.1)
	id AA04296; Wed, 19 Apr 89 09:46:48 PDT
Received: by clam.sun.com (4.0/SMI-4.0)
	id AA03652; Wed, 19 Apr 89 09:50:50 PDT
Date: Wed, 19 Apr 89 09:50:50 PDT
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8904191650.AA03652@clam.sun.com>
To: SEB1525@draper.com, cl-compiler@SAIL.STANFORD.EDU
Subject: Re: Issue COMPILE-FILE-SYMBOL-HANDLING, version 3

> My question:  How is the compiler supposed to tell whether or not the symbol
> name was qualified in the input file?  Presumably it gets the symbol via READ,
> which doesn't transmit any indication of whether the package qualification
> was explicit or not.
>  
> So how can it distinguish between symbol-name and current-package:symbol-name?

It can't and it doesn't.
 
> I contend that for this reason, the "current-package" model is unworkable.
> This may not be an issue any longer, but I think this is sufficient
> justification for the "home-package" model being the only reasonable one.
> 

I contend essentially the same thing: the goal of mapping compile-time
symbols to load-time symbols with the same home package is the right
one, and the compiler and loader should work to accomplish that.  This
is the tightest enforcement of sameness between compiletime and runtime
that appears to be possible using compile-file in Common Lisp, so it is
the best choice.  It is also relatively simple for programmers to
understand.

Still, the principles expressed in the NEW-REQUIRE-CONSISTENCY
proposal look like to me like good ones for programmers to follow,
and the committee sentiment is that this approach is more practical
for the standard.  As I understand the requirements of the new
proposal, if programmers follow the rules their symbols wind up
with the same home package at compile- and load-time.

Am I mistaken in this?

				-Cris


∂20-Apr-89  0925	CL-Compiler-mailer 	issue COMPILE-FILE-SYMBOL-HANDLING, version 3
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Apr 89  09:25:18 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA12706g; Thu, 20 Apr 89 09:25:15 PDT
Received: by challenger id AA01408g; Thu, 20 Apr 89 09:25:06 PDT
Date: Thu, 20 Apr 89 09:25:06 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8904201625.AA01408@challenger>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 18 Apr 89 14:33:20 MDT <8904182033.AA06483@defun.utah.edu>
Subject: issue COMPILE-FILE-SYMBOL-HANDLING, version 3

   From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
   Date: Tue, 18 Apr 89 14:33:20 MDT


   At last month's meeting, we agreed that compromising on some variant
   of proposal REQUIRE-CONSISTENCY was the only practical solution on
   this issue, but several people have indicated they think it's
   unacceptable to restrict IN-PACKAGE to being the first form in the
   file.  Here's a modified proposal that tries to get around that
   problem.

   Forum:		Compiler
   Issue:		COMPILE-FILE-SYMBOL-HANDLING
   References:	CLtL p. 182
		   Issue IN-PACKAGE-FUNCTIONALITY (passed)
		   Issue CONSTANT-COMPILABLE-TYPES (passed)
		   Issue DEFPACKAGE (passed)
   Category:	CHANGE/CLARIFICATION 
   Edit History:   V1, 01 Feb 1989, Sandra Loosemore
		   V2, 12 Mar 1989, Sandra Loosemore (discussion, error terms)
		   V3, 18 Apr 1989, Sandra Loosemore (new proposal)
   Status:		Ready for release


   Problem Description:

   It is not clear how COMPILE-FILE is supposed to specify to LOAD how
   symbols in the compiled file should be interned.  In particular, what
   happens if the value of *PACKAGE* is different at load-time than it
   was at compile-time, or if any of the packages referenced in the file
   are defined differently?

   There are two models currently being used to implement this behavior:

     (1) Symbols appearing in the output file produced by COMPILE-FILE
	 are qualified with package prefixes in the same way that PRINT
	 would qualify them.  Symbols that are accessible in *PACKAGE*
	 at compile-time are looked up in *PACKAGE* at load-time.  (This
	 is the "current-package" model.)

     (2) Symbols appearing in the output file produced by COMPILE-FILE
	 are always qualified with the name of their home package,
	 regardless of the value of *PACKAGE*.  (This is the
	 "home-package" model.)


   Proposal COMPILE-FILE-SYMBOL-HANDLING:NEW-REQUIRE-CONSISTENCY:

     In order to guarantee that compiled files can be loaded correctly,
     users must ensure that the packages referenced in the file are defined
     consistently at compile and load time.  Conforming Common Lisp programs
     must satisfy the following requirements:

     (1) The value of *PACKAGE* when a top-level form in the file is processed
	 by COMPILE-FILE must be the same as the value of *PACKAGE* when the
	 code corresponding to that top-level form in the compiled file is
	 executed.  In particular:

You mean loaded instead of executed right?

     If all of these conditions hold, then when a compiled file is
     loaded, the interned symbols it references are found by calling
     INTERN at load time with two arguments, the name of the symbol and
     the package with the same name as the compile-time symbol's home
     package.  If no such package exists, an error is signalled.

I think this should be removed. It clearly is overspecification. We should
specify behaviour of conforming programs. You are trying to describe the
behavior of an implementation. Besides, this is incompatible with the current
package practice, because they lose the home package when they dump. 
I will be perfectly happy with just the requirement 1 and 2.

Patrick.

∂20-Apr-89  0946	CL-Compiler-mailer 	Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 3 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Apr 89  09:46:14 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA19641; Thu, 20 Apr 89 10:46:11 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA07614; Thu, 20 Apr 89 10:46:08 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904201646.AA07614@defun.utah.edu>
Date: Thu, 20 Apr 89 10:46:06 MDT
Subject: Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 3
To: Patrick Dussud <dussud@lucid.com>
Cc: sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu
In-Reply-To: Patrick Dussud <dussud@lucid.com>, Thu, 20 Apr 89 09:25:06 PDT

> Date: Thu, 20 Apr 89 09:25:06 PDT
> From: Patrick Dussud <dussud@lucid.com>
> 
>      (1) The value of *PACKAGE* when a top-level form in the file is processed
> 	 by COMPILE-FILE must be the same as the value of *PACKAGE* when the
> 	 code corresponding to that top-level form in the compiled file is
> 	 executed.  In particular:
> 
> You mean loaded instead of executed right?

I don't think "load" is the right word here because it's an operation
on files, not forms.  The forms in the file are executed as part of
loading, of course.  Perhaps I can come up with some better wording on
this, though.  I'll have to think about it.

>      If all of these conditions hold, then when a compiled file is
>      loaded, the interned symbols it references are found by calling
>      INTERN at load time with two arguments, the name of the symbol and
>      the package with the same name as the compile-time symbol's home
>      package.  If no such package exists, an error is signalled.
> 
> I think this should be removed. It clearly is overspecification. We should
> specify behaviour of conforming programs. You are trying to describe the
> behavior of an implementation. Besides, this is incompatible with the current
> package practice, because they lose the home package when they dump. 
> I will be perfectly happy with just the requirement 1 and 2.

I disagree -- this paragraph is the key to the whole proposal.  The
previous items are requirements for a program to be valid.  This
paragraph says how valid programs behave.  If we delete it, we will
still have no statement of how symbols referenced in the source code
for a file relate to the symbols in the compiled code for that file.

I do not believe what this paragraph is trying to say is incompatible
with the "current package" model because of item (2) -- if a symbol is
accessible in *PACKAGE* (and hence has no home package information),
the same symbol must also be accessible in the home package.  Now that
I look over the exact wording here though, it does rather give the
impression that implementations must remember the home package.
Suppose I changed it to say:

   ...the interned symbols it references are found as if INTERN were
   called at load time with two arguments....

-Sandra
-------

∂21-Apr-89  0904	CL-Compiler-mailer 	issue COMPILE-FILE-SYMBOL-HANDLING, version 3
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Apr 89  09:04:14 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA14300g; Fri, 21 Apr 89 09:04:12 PDT
Received: by challenger id AA00367g; Fri, 21 Apr 89 09:04:02 PDT
Date: Fri, 21 Apr 89 09:04:02 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8904211604.AA00367@challenger>
To: sandra%defun@cs.utah.edu
Cc: sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Thu, 20 Apr 89 10:46:06 MDT <8904201646.AA07614@defun.utah.edu>
Subject: issue COMPILE-FILE-SYMBOL-HANDLING, version 3


   From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
   Date: Thu, 20 Apr 89 10:46:06 MDT


   I don't think "load" is the right word here because it's an operation
   on files, not forms.  The forms in the file are executed as part of
   loading, of course.  Perhaps I can come up with some better wording on
   this, though.  I'll have to think about it.
I see your point. Maybe processed would convey what you want to say?


   I disagree -- this paragraph is the key to the whole proposal.  The
   previous items are requirements for a program to be valid.  This
   paragraph says how valid programs behave.  If we delete it, we will
   still have no statement of how symbols referenced in the source code
   for a file relate to the symbols in the compiled code for that file.

   I do not believe what this paragraph is trying to say is incompatible
   with the "current package" model because of item (2) -- if a symbol is
   accessible in *PACKAGE* (and hence has no home package information),
   the same symbol must also be accessible in the home package.  Now that
   I look over the exact wording here though, it does rather give the
   impression that implementations must remember the home package.
   Suppose I changed it to say:

      ...the interned symbols it references are found as if INTERN were
      called at load time with two arguments....
That's much better. 

Patrick.

∂24-Apr-89  0640	Quinquevirate-mailer 	Re: Function constants 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 24 Apr 89  06:39:42 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA18845; Mon, 24 Apr 89 07:39:48 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA10255; Mon, 24 Apr 89 07:39:45 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904241339.AA10255@defun.utah.edu>
Date: Mon, 24 Apr 89 07:39:43 MDT
Subject: Re: Function constants
To: Richard P. Gabriel <rpg@lucid.com>
Cc: cl-compiler@sail.stanford.edu, quinquevirate@sail.stanford.edu
In-Reply-To: Richard P. Gabriel <rpg@lucid.com>, Sun, 23 Apr 89 20:52:30 PDT

[CC'ed to cl-compiler.]

> Date: Sun, 23 Apr 89 20:52:30 PDT
> From: Richard P. Gabriel <rpg@lucid.com>
> 
> The first question is what it means to be a function constant.  It
> doesn't mean a constant function, which is a function that returns the
> same thing every time it's called. But, does it mean that it has
> an alterable environment?

I would define a function constant as an object of type FUNCTION that
appears as a quoted or self-evaluating form.  (This is quite distinct
from a FUNCTION special form.)

> The second question is how do you dump such a thing as a function.
> Well, if your compiler can compile-file this you are part way there:
> 
> (defun f (x y) (+ x y))
> 
> That is, you can dump and load functions.

No, this is a FUNCTION special form, not a function constant.  What
you are dumping and loading is code which will create a function
object when executed, not the function object itself.

> So the remaining problem is how to dump ``code vectors.'' This is
> simple if you have position-independent code, because then you just
> dump the bits as if it were a bit-vector. The question is whether we
> wish to support machines that have no such thing as position
> independent code or do we wish to require implementations to keep
> relocation information around (which they will anyway if they can
> garbage collect code and compact the space). [Note that the
> environments have to be put in something other than a readonly space,
> one that the GC sees.]

I agree this is the main question from an implementation point of
view.  I know that for some implementations (i.e., UCL), this
requirement would be a major headache. 

I'd argue that since this isn't compatible with current practice, and
is a lot of work to implement, that it probably isn't a good thing to
require unless doing so would provide some desperately needed
functionality that is now missing from the language.  I question
whether the need for the ability to dump function constants is really
all that great.  I'm having a hard time even coming up with a
realistic example that could not also be handled using
LOAD-TIME-VALUE.

There is also a problem with dumping closures that you didn't mention.
Unless the object is looked up "by name" by the loader, the dump/load
process inherently creates a copy of the original object.  Closure
environments are no exception to that rule, which could lead to some
unexpected behavior.

> An alternative to the function constant problem is as follows: We
> state that compilation is meaningful in only two situations: COMPILE
> in an image with no dumping allowed and COMPILE-FILE in a fresh Lisp
> where the compilation will not load any compiled code, where only one
> compilation unit will be compiled, and where the result will be loaded
> in a copy of the same fresh Lisp that was used to do the compilation.
> Calls to COMPILE are allowed in the second scenario.  (That is, you
> start a lisp, compile-file, quit, start afresh that same Lisp, load.)
> 
> In these two cases we can allow the free use of functions as constants
> because either there is no need to dump stuff, or else all the source
> code that is needed can be made available. That is, in this case, all
> the functions that could be constants have either had their source
> examined and saved by the very compiler doing all the work or else are
> functions in the Common Lisp package, which can be dumped by name.

We've already said that it's OK for function constants to appear in
code processed by COMPILE or EVAL -- issue QUOTE-SEMANTICS said that
constraints on what kinds of objects can appear in constants apply
only to COMPILE-FILE, and that COMPILE never copies. 

I'd accept a statement that your second case is the only situation in
which function constants seen by COMPILE-FILE make sense, but saying
that's the only situation in which compilation with COMPILE-FILE is
meaningful seems like it's going way too far in the wrong direction.
Random people picking up the Common Lisp standard would get a very bad
impression of the language from seeing a restriction like that, and
it's certainly not consistent with current practice.

-Sandra
-------

∂25-Apr-89  0835	CL-Compiler-mailer 	draft of section 4.2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 Apr 89  08:34:55 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA29397; Tue, 25 Apr 89 09:35:02 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA11058; Tue, 25 Apr 89 09:34:55 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904251534.AA11058@defun.utah.edu>
Date: Tue, 25 Apr 89 09:34:54 MDT
Subject: draft of section 4.2
To: cl-compiler@sail.stanford.edu
Cc: cl-editorial@sail.stanford.edu

Here's my draft of section 4.2.  There are a couple pieces that are
still missing (due to the issues involved not having been voted on
yet) but I've marked the places that will have to be updated. 

I will make one more round of edits on this (probably in about a week)
if any of you have comments on content or organization, but after that
I'd like to turn it over to Kathy and the drafting committee.  I
understand that some other parts of the standard are being rewritten
by the drafting committee and that this material will probably need
some additional changes to conform to the same style.


Introduction
============

The compiler is a utility that translates programs into an
implementation-dependent form that can be represented and/or executed
more efficiently.  The nature of the processing performed during
compilation is discussed in the "Compilation Semantics" section below.
This is followed by a discussion of the behavior of COMPILE-FILE and
the interface between COMPILE-FILE and LOAD.

% References:
%    CLtL page 143 (next to last paragraph)
%    CLtL page 321 (second paragraph)

The functions COMPILE and COMPILE-FILE are used to explicitly force
compilation to take place.  It is permissible for conforming
implementations to also perform implicit compilation during ordinary
evaluation.  While the evaluator is typically implemented as an
interpreter that traverses the given form recursively, performing each
step of the computation as it goes, a permissible alternate approach
is for the evaluator first to completely compile the form into
machine-executable code and then invoke the resulting code.  Various
mixed strategies are also possible.  All of these approaches should
produce the same results when executing a correct program, but may
produce different results for incorrect programs.

% This paragraph should really conclude with a stronger statement that
% conforming programs must be structured so they will work if implicit
% compilation does take place, but CLtL doesn't come right out and say
% that, and we have never voted on any issue to say that either.


Compilation Semantics
=====================

% References:
%    Issue COMPILE-ENVIRONMENT-CONSISTENCY [pending]
%    Issue COMPILED-FUNCTION-REQUIREMENTS [pending]
% The material in this section will have to be updated to reflect further
% changes to these issues.

Conceptually, compilation can be viewed as a process which traverses a
program, performs certain kinds of syntactic and semantic analysis
using information (such as proclamations and macro definitions)
present in the compile time environment, and produces a modified
program.  As a minimum, the compiler must perform the following
actions:

- All macro calls appearing lexically within the code being compiled
  must be expanded at compile time and will not be expanded again at
  run time.  The process of compilation effectively turns MACROLET
  and SYMBOL-MACROLET constructs int PROGNs, with all calls to the local
  macros in the body replaced by their expansions.

  The compiler must treat any form that is a list beginning with a
  symbol that does not name a macro or special form as a function call.
  (This implies that SETF methods must also be available at compile time.)

- The compiler must capture declarations to determine whether
  variable bindings and references appearing lexically within the
  code being compiled are to be treated as lexical or special.  The
  compiler must treat any binding of a variable that has not been
  declared or proclaimed to be SPECIAL as a lexical binding.

- The compiler must process EVAL-WHEN forms that appear lexically within
  the program being compiled.  Effectively, the compiler must replace
  the EVAL-WHEN form with either a PROGN containing the body forms, or
  a constant NIL.

- The compiler must process LOAD-TIME-VALUE forms that appear lexically
  within the program being compiled.  In the case of COMPILE, evaluation
  of the LOAD-TIME-VALUE form happens at compile time and the resulting
  value is treated as a literal constant at run time.  In the case of
  COMPILE-FILE, the compiler must arrange for evaluation of the form
  to take place at load time.

In addition, the compiler is permitted to incorporate the following
kinds of information into the code it produces, if the information is
present in the compile time environment and is referenced within the
code being compiled.  Except where some other behavior is explicitly
stated, when the compile time and run time definitions are different,
it is unspecified which will prevail within the compiled code.  It is
also permissible for implementations to signal an error at run time to
complain about the discrepancy.  In all cases, the absence of the
information at compile time is not an error, but its presence may
enable the compiler to generate more efficient code.

- The compiler may assume that functions that are defined and
  declared or proclaimed INLINE in the compile time environment will
  retain the same definitions at run time.

- The compiler may assume that, within a named function, a
  recursive call to a function of the same name refers to the
  same function, unless that function has been declared NOTINLINE.
  
- COMPILE-FILE may assume that, in the absence of NOTINLINE
  declarations, a call within the file being compiled to a named
  function which is defined in that file refers to that function.
  (This permits "block compilation" of files.)  The behavior of
  the program is unspecified if functions are redefined individually 
  at run time.
  
- The compiler may assume that the argument syntax and number of return
  values for all built-in Common Lisp functions will not change.  In
  addition, the compiler may treat all built-in Common Lisp functions
  as if they had been proclaimed INLINE.
  
- The compiler may assume that the argument syntax and number of return
  values for all functions with FTYPE information available at
  compile time will remain the same at run time.

% Reference:  CLtL page 69
- The compiler may assume that symbolic constants that have been
  defined with DEFCONSTANT in the compile time environment will retain
  the same value at run time as at compile time.  The compiler may replace
  references to the name of the constant with the value of the constant,
  provided that such "copies" are EQL to the object that is the
  actual value of the constant.
 
% The following paragraph from issue COMPILE-ENVIRONMENT-CONSISTENCY
%    seems likely to change:
 
- The compiler can assume that type definitions made with DEFTYPE 
  or DEFSTRUCT in the compile time environment will retain the same 
  definition in the run time environment.  It may also assume that
  a class defined by DEFCLASS in the compile time environment will
  be defined in the run time environment in such a way as to have
  the same superclasses and metaclass.  This implies that
  subtype/supertype relationships of type specifiers will not 
  change between compile time and run time.  (Note that it is not 
  an error for an unknown type to appear in a declaration at
  compile time, although it is reasonable for the compiler to 
  emit a warning in such a case.)

% Ref:  CLtL page 153
- The compiler may assume that if type declarations are present
  in the compile time environment, the corresponding variables and 
  functions present in the run time environment will actually be of
  those types; otherwise, the run time behavior of the program is 
  undefined.

The compiler *must not* make any additional assumptions about
consistency between the compile time and run time environments.  In 
particular:

- The compiler may not assume that functions that are defined
  in the compile time environment will retain the either the
  same definition or the same signature at run time, except in the
  situations explicitly listed above.

- The compiler may not signal an error if it sees a call to a
  function that is not defined at compile time, since that function
  may be provided at run time.



File Compilation
================

The function COMPILE-FILE performs compilation processing (described
in the previous section) on forms appearing in a file, producing an
output file which may then be loaded with LOAD.

Normally, the top-level forms appearing in a file compiled with
COMPILE-FILE are executed only when the resulting compiled file is
loaded, and not when the file is compiled.  However, it often happens
that some forms in the file must be evaluated at compile time in order
for the remainder of the file to be read and compiled correctly; for
example, forms that change the values of *PACKAGE* or *READTABLE* and
macro definitions.  In such cases, the distinction between processing
that is performed at compile time and processing that is performed at
load time becomes important.

The special form EVAL-WHEN can be used to give explicit control over
the time at which evaluation of a top-level form takes place, allowing
forms to be executed at compile time, load time, or both.  The
behavior of this construct may be more precisely understood in terms
of a model of how COMPILE-FILE processes forms in a file to be
compiled.

Successive forms are read from the file by the file compiler using
READ. These top-level forms are normally processed in what we call
`not-compile-time' mode; in this mode, the file compiler arranges for
forms to be evaluated only at load time and not at compile time.
There is one other mode, called `compile-time-too' mode, in which
forms are evaluated both at compile and load times.

Processing of top-level forms in the file compiler works as follows:

* If the form is a macro call, it is expanded and the result is
  processed as a top-level form in the same processing mode
  (compile-time-too or not-compile-time).

* If the form is a PROGN form, each of its body forms is
  sequentially processed as top-level forms in the same processing
  mode.

* If the form is a LOCALLY, MACROLET, or SYMBOL-MACROLET,
  the file compiler makes the appropriate bindings and recursively
  processes the body forms as an implicit top-level PROGN with those 
  bindings in effect, in the same processing mode.  (Note that this
  implies that the lexical environment in which top-level forms are
  processed is not necessarily the null lexical environment.)

* If the form is an EVAL-WHEN form, it is handled according to
  the following table:

  COMPILE LOAD EVAL compile-time-too  Action
   
     Yes   Yes  --     --             Process body in compile-time-too mode
     No    Yes  Yes    Yes            Process body in compile-time-too mode
     No    Yes  Yes    No             Process body in not-compile-time mode
     No    Yes  No     --             Process body in not-compile-time mode
     Yes   No   --     --             Evaluate body
     No    No   Yes    Yes            Evaluate body
     No    No   Yes    No             do nothing
     No    No   No     --             do nothing

  "Process body" means to process the body (using the procedure 
  outlined in this subsection) as an implicit top-level PROGN.
  "Evaluate body" means to evaluate the body forms as an implicit
  PROGN in the dynamic execution context of the compiler and in the
  lexical environment in which the EVAL-WHEN appears.

* Otherwise, the form is a top-level form that is not one of the
  special cases.  If in compile-time-too mode, the compiler first
  evaluates the form and then performs normal compiler processing
  on it.  If in not-compile-time mode, only normal compiler
  processing is performed.  Any subforms are treated as non-top-level
  forms.

Note that top-level forms are processed in the order in which they
textually appear in the file, and that each top-level form read by the
compiler is processed before the next is read.  However, the order of
processing (including, in particular, macro expansion) of subforms
that are not top-level forms is unspecified.

EVAL-WHEN forms cause compile time evaluation only at top-level.  In
non-top-level locations, both the :COMPILE-TOPLEVEL and :LOAD-TOPLEVEL
situations are ignored and only the :EXECUTE situation is considered.

The following macros make definitions that are typically used during
compilation and are defined to make those definitions available at
both compile time and run time when calls to those macros appear in a
file being compiled.  As with EVAL-WHEN, these compile time
side-effects happen only when the defining macros appear at top-level.

% The specific details of the compile time side effects should go under
% the description of the macro in chapters 6 & 7.
    DEFTYPE
    DEFMACRO
    DEFINE-MODIFY-MACRO
    DEFVAR
    DEFPARAMETER
    DEFCONSTANT
    DEFSETF
    DEFINE-SETF-METHOD
    DEFSTRUCT
    DEFINE-CONDITION
    DEFPACKAGE
    IN-PACKAGE
% These depend on the outcome of issue CLOS-MACRO-COMPILATION
    DEFCLASS
    DEFGENERIC
    DEFMETHOD
    DEFINE-METHOD-COMBINATION
% This depends on the outcome of issue PROCLAIM-ETC-IN-COMPILE-FILE
    DEFPROCLAIM

The compile time behavior of these macros can be understood as if
their expansions effectively include (EVAL-WHEN (:COMPILE-TOPLEVEL)
...) forms.  It is not required that the compile time definition be
made in the same manner as if the defining macro had been evaluated
directly.  In particular, the information stored by the defining
macros at compile time may or may not be available to the evaluator
(either during or after compilation), or during subsequent calls to
COMPILE or COMPILE-FILE.  If the definition must be visible during
compile time evaluation, it should be placed within an explicit
(EVAL-WHEN (:COMPILE-TOPLEVEL) ...) to ensure that it will be fully
defined at compile time.

   Wrong:  (defmacro foo (x) `(car ,x))
    	   (eval-when (:execute :compile-toplevel :load-toplevel)
             (print (foo '(a b c))))

   Right:  (eval-when (:execute :compile-toplevel :load-toplevel)
             (defmacro foo (x) `(car ,x))
             (print (foo '(a b c))))



Compiler/Loader Interface
=========================

% Reference: Issue QUOTE-SEMANTICS

The functions EVAL and COMPILE always ensure that constants referenced
within the resulting interpreted or compiled code objects are EQL to
the corresponding objects in the source code.  COMPILE-FILE, on the
other hand, must produce an output file which contains instructions
tell the loader how to reconstruct the objects appearing in the source
code when the compiled file is loaded.  The EQL relationship is not
well-defined in this case, since the compiled file may be loaded into
a different Lisp image than the one that it was compiled in.  This
section defines a notion of "similarity as constants" which relates
objects in the the compile time environment to the corresponding
objects in the load time environment.

The constraints on constants described in this subsection apply only
to COMPILE-FILE; implementations are not permitted to copy or coalesce
constants appearing in code processed by EVAL or COMPILE.


Terminology
-----------

% Reference:  Issue CONSTANT-COMPILABLE-TYPES

The following terminology is used in this section.

The term "constant" refers to a quoted or self-evaluating constant
or an object that is a substructure of such a constant, not a named
(DEFCONSTANT) constant.

The term "source code" is used to refer to the objects constructed
when COMPILE-FILE calls READ, and additional objects constructed by
macroexpansion during COMPILE-FILE.

The term "compiled code" is used to refer to objects constructed by 
LOAD.

The term "coalesce" is defined as follows.  Suppose A and B are two
objects used as quoted constants in the source code, and that A' and
B' are the corresponding objects in the compiled code.  If A' and B'
are EQL but A and B were not EQL, then we say that A and B have been
coalesced by the compiler.


What may appear as a constant
-----------------------------

An object may be used as a quoted constant processed by COMPILE-FILE
if the compiler can guarantee that the resulting constant established
by loading the compiled file is "similar as a constant" to the
original.

The notion of "similarity as a constant" is not well-defined on all
data types.  Objects of these types may not portably appear as
constants in code processed with COMPILE-FILE.  Conforming
implementations are required to handle such objects either by having
the compiler and/or loader reconstruct an equivalent copy of the
object in some implementation-specific manner; or by having the
compiler signal an error.

For some aggregate data types, being similar as constants is defined
recursively.  We say that an object of these types has certain "basic
attributes", and to be similar as a constant to another object, the
values of the corresponding attributes of the two objects must also be
similar as constants.

This kind of definition has problems with any circular or "infinitely
recursive" object such as a list that is an element of itself.  We use
the idea of depth-limited comparison, and say that two objects are
similar as constants if they are similar at all finite levels.  This
idea is implicit in the definitions below, and applies in all the
places where attributes of two objects are required to be similar as
constants.

% Reference:  issue CONSTANT-CIRCULAR-COMPILATION

Such circular objects may legitimately appear as constants to be
compiled.  More generally, if two constants are EQL in the source code
for a single file being compiled with COMPILE-FILE, the corresponding
constants in the compiled code must also be EQL.

% Reference:  issue CONSTANT-COLLAPSING

However, the converse of this relationship need not be true; if two
objects are EQL in the compiled code, that does not always imply that
the corresponding objects in the source code were EQL.  This is
because COMPILE-FILE is permitted to coalesce constants appearing in
the source code if and only if they are similar as constants, unless
the objects involved are of type SYMBOL, PACKAGE, STRUCTURE, or
STANDARD-OBJECT.


Similarity as constants
-----------------------

Two objects are defined to be "similar as a constant" if and only if
they are both of one of the types listed below and satisfy the
additional requirements listed for that type.

Number

  Two numbers are similar as constants if they are of the same type
  and represent the same mathematical value.
  
Character

  Two characters are similar as constants if they both represent
  the same character.

% Note that this definition has to depend on the results of the
% Character Set proposals.  The intent is that this be compatible with
% how EQL is defined on characters.

Symbol

% Issue COMPILE-FILE-SYMBOL-HANDLING defines how the file compiler
%  and loader handle interned symbols.

  An uninterned symbol in the source code is similar as a constant
  to an uninterned symbol in the compiled code if their print names
  are similar as constants.

Package

  A package in the source code is similar as a constant to a package in
  the compiled code if their names are similar as constants.  Note that
  the loader finds the corresponding package object as if by calling
  FIND-PACKAGE with the package name as an argument.  An error is
  signalled if no package of that name exists at load time.

Random-state

  Let us say that two random-states are functionally equivalent if 
  applying RANDOM to them repeatedly always produces the same 
  pseudo-random numbers in the same order.  
  
  Two random-states are similar as constants if and only if copies of
  them made via MAKE-RANDOM-STATE are functionally equivalent.

  Note that a constant random-state object cannot be used as the "state"
  argument to the function RANDOM (because RANDOM side-effects this
  data structure).

Cons

  Two conses are similar as constants if the values of their respective
  CAR and CDR attributes are similar as constants.

Array

  Two arrays are similar as constants if the corresponding values each
  of the following attributes are similar as constants:

  For 1-dimensional arrays:
  LENGTH, ARRAY-ELEMENT-TYPE, and ELT for all valid indices.

  For arrays of other dimensions:
  ARRAY-DIMENSIONS, ARRAY-ELEMENT-TYPE, AREF for all valid indices.

  In addition, if the array in the source code is a SIMPLE-ARRAY, then
  the corresponding array in the compiled code must also be a
  SIMPLE-ARRAY.  If the array in the source code is displaced, has a
  fill pointer, or is adjustable, the corresponding array in the
  compiled code is permitted to lack any or all of these qualities.

Hash Table   

  Two hash tables are similar as constants if they meet the following
  three requirements:

  (1) They both have the same test (e.g., they are both EQL hash tables).

  (2) There is a unique one-to-one correspondence between the keys of
      the two tables, such that the corresponding keys are similar as
      constants.

  (3) For all keys, the values associated with two corresponding keys
      are similar as constants.

  If there is more than one possible one-to-one correspondence between
  the keys of the two tables, the results are unspecified.  A conforming
  program cannot use such a table as a constant.

Pathname

  Two pathnames are similar as constants if all corresponding pathname
  components are similar as constants.

Stream, Readtable, Method

  Objects of these types are not supported in compiled constants.

Function

%  Issue CONSTANT-FUNCTION-COMPILATION specifies how the compiler and
%  loader handle constant functions.

Structure, Standard-object

% Reference: issue LOAD-OBJECTS

  Objects of type structure and standard-object may appear in compiled
  constants if there is an appropriate MAKE-LOAD-FORM method defined
  for that type.

  COMPILE-FILE calls MAKE-LOAD-FORM on any object that is referenced as
  a constant or as a self-evaluating form, if the object's metaclass is
  STANDARD-CLASS, STRUCTURE-CLASS, any user-defined metaclass (not a
  subclass of BUILT-IN-CLASS), or any of a possibly-empty
  implementation-defined list of other metaclasses.  COMPILE-FILE will
  only call MAKE-LOAD-FORM once for any given object (compared with EQ)
  within a single file.

Condition

% This somehow got overlooked.  Are they handled under LOAD-OBJECTS?



Compile Time Error Handling
===========================

% Reference:  Issue COMPILER-DIAGNOSTICS
% The STYLE-WARNING condition needs to be integrated into the section
%     describing the hierarchy of condition types.

Errors and warnings may be issued within COMPILE or COMPILE-FILE.
This includes both arbitrary errors which may occur due to
compile-time processing of (EVAL-WHEN (:COMPILE-TOPLEVEL) ...)  forms
or macro expansion, and conditions signalled by the compiler itself.

Conditions of type ERROR may be signalled by the compiler in
situations where the compilation cannot proceed without
intervention.

    Examples:
        file open errors
        syntax errors

Conditions of type WARNING may be signalled by the compiler in 
situations where the standard explicitly states that a warning must,
should, or may be signalled; and where the compiler can determine 
that a situation with undefined consequences or that would cause
an error to be signalled would result at runtime.

    Examples:
        violation of type declarations
        SETQ'ing or rebinding a constant defined with DEFCONSTANT
        calls to built-in Lisp functions with wrong number of arguments
          or malformed keyword argument lists
        referencing a variable declared IGNORE
        unrecognized declaration specifiers

The compiler is permitted to issue warnings about matters of
programming style as conditions of type STYLE-WARNING.  Although 
STYLE-WARNINGs -may- be signalled in these situations, no 
implementation is -required- to do so.  However, if an 
implementation does choose to signal a condition, that condition 
will be of type STYLE-WARNING and will be signalled by a call to 
the function WARN.

    Examples:
	redefinition of function with different argument list
	calls to function with wrong number of arguments
	unreferenced local variables not declared IGNORE
	declaration specifiers described in CLtL but ignored by 
	  the compiler


Both COMPILE and COMPILE-FILE are allowed to establish a default
condition handler.  If such a condition handler is established,
however, it must first resignal the condition to give any
user-established handlers a chance to handle it.  If all user error
handlers decline, the default handler may handle the condition in an
implementation-specific way; for example, it might turn errors into
warnings.

% Reference:  issue WITH-COMPILATION-UNIT

In some implementations, some kinds of warnings may be deferred until
"the end of compilation"; see WITH-COMPILATION-UNIT.

-------

∂27-Apr-89  0403	CL-Compiler-mailer 	issue COMPILE-FILE-SYMBOL-HANDLING, version 3
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Apr 89  04:03:24 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate.lucid.com id AA03032g; Thu, 27 Apr 89 04:03:11 PDT
Received: by bhopal id AA15007g; Thu, 27 Apr 89 04:03:06 PDT
Date: Thu, 27 Apr 89 04:03:06 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8904271103.AA15007@bhopal>
To: sandra%defun@cs.utah.edu
Cc: dussud@lucid.com, cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Thu, 20 Apr 89 10:46:06 MDT <8904201646.AA07614@defun.utah.edu>
Subject: issue COMPILE-FILE-SYMBOL-HANDLING, version 3

This is a bit befuddling.  I thought more people recognized the
fundamental problem with "fasdmping" of symbols; but none of the
discussion so far seems to show awareness of it (except a little bit of
Dussud's first msg).  If it did, one would be less likely to recommend
that "fasl loaders" should call INTERN with the "home package" as seen
at compile time.

The fundamental problem:

   "Reading in, Dumping out and Reading-Back in" of Lisp data is an
   inherently information-losing process.

You can't do it 100% correct even with source-to-source  files; so
there is no reason to suppose that the compiler's involvement will
cure the problem, especialy since the major part of loss has occured
via READ, before the compiler sees the input.  [By the bye, if you (one) 
can't figure out 100 examples of this information loss on your (his) own,
then please contact me privately rather than cluttering up cl-compiler 
with yet another extraneous discussion.]

Previous discussion on this issue highlighted one of the primary goals
of Common Lisp -- to make the execution of interpreted code and compiled 
code as indistinguishable as possible. [Indeed, this was one of the driving 
forces for "lexical" evaluators, since MacLisp et. al. had lexical variables
in compiled code, but not in interpreted code].  Given that goal, one can 
elaborate on it to say that the goal of the "fasl loader" is to do it's 
best towards making the same package qualifications as the original source 
would have done.  On the other hand, the "home package" approach is based 
on a non-goal of compilation!  COMPILE-FILE is certainly not intended to 
be a replacement for a persistent object data base [which is what most
proponents of the "home package" scheme presuppose.]

I hasten to point out that we _cannot_ be convinced of one goal over 
the other simply by finding "screw cases"; any approach whatsoever is 
destined to have unresolvable screw cases.  Instead, I suggest we look 
to a broader goal -- in this case the source/compiled uniformity -- and 
let that be the driving force.  With this in mind, it might be that the 
best approach is to allow each implementation to work out its "best foot
forward" towards the goal of source/compiled uniformity.  

Overspecification at this point would be a disaster.  Either you will
be saying nothing meaningful, or else you will be specifying as
"undefined" the major part of behaviour that makes developing programs
in Lisp so much more dynamic than developing them in any of the typical
conventional languages.  For example, proscribing the "fasl" loader from
making reference to *package* at load time is guaranteed to prevent one 
of the more common "incremental program development" scenarios from 
working -- the dynamic re-arrangement in the package layout itself.



-- JonL --

∂27-Apr-89  0638	CL-Compiler-mailer 	Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 3 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 27 Apr 89  06:38:47 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA14063; Thu, 27 Apr 89 07:38:24 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA12558; Thu, 27 Apr 89 07:38:21 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904271338.AA12558@defun.utah.edu>
Date: Thu, 27 Apr 89 07:38:20 MDT
Subject: Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 3
To: Jon L White <jonl@lucid.com>
Cc: sandra%defun@cs.utah.edu, dussud@lucid.com, cl-compiler@sail.stanford.edu
In-Reply-To: Jon L White <jonl@lucid.com>, Thu, 27 Apr 89 04:03:06 PDT

> Date: Thu, 27 Apr 89 04:03:06 PDT
> From: Jon L White <jonl@lucid.com>
> 
> The fundamental problem:
> 
>    "Reading in, Dumping out and Reading-Back in" of Lisp data is an
>    inherently information-losing process.

I would say that the fundamental problem is just dumping out and
reading back in, because of the potential for changes to the package
hierarchy between dumping and reading in. 

> Previous discussion on this issue highlighted one of the primary goals
> of Common Lisp -- to make the execution of interpreted code and compiled 
> code as indistinguishable as possible.

Agreed.

> Given that goal, one can 
> elaborate on it to say that the goal of the "fasl loader" is to do it's 
> best towards making the same package qualifications as the original source 
> would have done.  

Now that's overspecification.  Perhaps a more reasonable goal would be
to do its best towards ensuring that the loader resolve symbol
references to the same symbols that would result if the original
source were loaded (even for symbols that do not appear in the
original source file, but which show up as the result of macro
expansion, etc.).  The question is, what constraints must be placed on
conforming programs to ensure that this is possible?

> On the other hand, the "home package" approach is based 
> on a non-goal of compilation!

I don't think compilation is a non-goal of COMPILE-FILE (which, after
all, is what we're talking about here).  

The real problem we're trying to deal with here is that if the package
system is set up differently at compile time than at load time, which
information should prevail when the compiled file is loaded?  You're
likely to get screwed in some cases no matter which model you use.
Let's be realistic -- if the package structure is not set up correctly
when the file is compiled, chances are it's going to be compiled
incorrectly, because the compiler won't be able to find the "right"
macro definitions, etc.  that it needs.  This is independent of
whether or not symbols in the compiled file are qualified with package
names when they're dumped. 

> I hasten to point out that we _cannot_ be convinced of one goal over 
> the other simply by finding "screw cases"; any approach whatsoever is 
> destined to have unresolvable screw cases.  Instead, I suggest we look 
> to a broader goal -- in this case the source/compiled uniformity -- and 
> let that be the driving force.  With this in mind, it might be that the 
> best approach is to allow each implementation to work out its "best foot
> forward" towards the goal of source/compiled uniformity.

That is the intent of the current proposal.  Do you have any specific 
comments on this proposal, or do you have an alternate proposal you'd like
us to consider?

-Sandra
-------

∂27-Apr-89  1749	CL-Editorial-mailer 	draft of section 4.2    
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 27 Apr 89  17:49:05 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Thu, 27 Apr 89 20:48:29 EDT
Date: Thu, 27 Apr 89 20:48 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: draft of section 4.2
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
Cc: cl-compiler@sail.stanford.edu, cl-editorial@sail.stanford.edu
In-Reply-To: <8904251534.AA11058@defun.utah.edu>
Message-Id: <19890428004804.4.BARMAR@OCCAM.THINK.COM>

Here are my comments on your draft:

    * If the form is an EVAL-WHEN form, it is handled according to
      the following table:
    
      COMPILE LOAD EVAL compile-time-too  Action

Shouldn't the headings be fixed to use the new keywords?

    Such circular objects may legitimately appear as constants to be
    compiled.  More generally, if two constants are EQL in the source code
    for a single file being compiled with COMPILE-FILE, the corresponding
    constants in the compiled code must also be EQL.

Earlier you gave a specific definition of the term "source code", which
seemed to refer to the top-level forms read by COMPILE-FILE.  "Source
code for a single file" doesn't make sense in this light.  Perhaps "if
two constants contained in source code read from the same source file
are EQL, the corresponding constants in the compiled code must also be
EQL."

    because COMPILE-FILE is permitted to coalesce constants appearing in
    the source code if and only if they are similar as constants, unless
    the objects involved are of type SYMBOL, PACKAGE, STRUCTURE, or
    STANDARD-OBJECT.

I'm not sure what the "unless" means.  This could be saying that when
the objects are of one of these types, the rule for when they may be
coalesced is something other than (and perhaps more leniant than)
"similar as constants".  Or it could be saying that objects of these
types may never be coalesced, even if they are similar as constants.  If
it's the latter case, however, it might be simpler to just incorporate
this into the definition of "similar as constants" (e.g. two non-EQ
symbols are never similar as constants).

                                                barmar

∂27-Apr-89  2309	CL-Compiler-mailer 	issue COMPILE-FILE-SYMBOL-HANDLING, version 3
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Apr 89  23:09:00 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate.lucid.com id AA04522g; Thu, 27 Apr 89 23:08:44 PDT
Received: by bhopal id AA17710g; Thu, 27 Apr 89 23:08:38 PDT
Date: Thu, 27 Apr 89 23:08:38 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8904280608.AA17710@bhopal>
To: sandra%defun@cs.utah.edu
Cc: dussud@lucid.com, cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Thu, 27 Apr 89 07:38:20 MDT <8904271338.AA12558@defun.utah.edu>
Subject: issue COMPILE-FILE-SYMBOL-HANDLING, version 3

re: >    "Reading in, Dumping out and Reading-Back in" of Lisp data is an
    >    inherently information-losing process.

    I would say that the fundamental problem is just dumping out and
    reading back in, because of the potential for changes to the package
    hierarchy between dumping and reading in. 

That problem -- "just dumping out and reading back in" is precisely the 
non-goal I spoke about; namely, that taht is the problem of persisten 
objects in an given "image".  Instead, the "inherent" problem is that 
there are multiple read syntaxes for the same object, and there is no 
one canonical syntax.  Indeed, because the same source file will read
in slightly differently when the packages are set up diferently,
the _inherent_ loss, rather than accidental loss, is in the very
first conversion of source -- well before the "dumping" stage.

re:   > Given that goal [source/compiled similarity], one can 
      > elaborate on it to say that the goal of the "fasl loader" is to do 
      > it's best towards making the same package qualifications as the 
      > original source would have done.  

    Now that's overspecification.  Perhaps a more reasonable goal would be

Don't you have it backwards?  This is the minimal specification -- that 
the implementation "do it's best" at achiving a worthy goal, even if that 
goal is inherently unattainable at the 100% level.  The specifications
that talk about how the compiler/loader must treat specific symbols
and into what packages they must go is surely overspecification.


re: > On the other hand, the "home package" approach is based 
    > on a non-goal of compilation!

    I don't think compilation is a non-goal of COMPILE-FILE (which, after
    all, is what we're talking about here).  

Hey! [ha ha!] this is a parsing problem; the two options are:

   (1) Persistent object storage is NOT the goal of compilation
   (2) Compilation is NOT the goal of `compile-file`

I meant (1); you read (2).


re: > [compiler/interpreter consistency]...
    > let that be the driving force.  With this in mind, it might be that the 
    > best approach is to allow each implementation to work out its "best foot
    > forward" towards the goal of source/compiled uniformity.

    That is the intent of the current proposal.  Do you have any specific 
    comments on this proposal, or do you have an alternate proposal you'd like
    us to consider?

I feel, like Patrick, that the proposal encourages the "home package"
approach, which mistakenly presumes the problem arena of persistent
object storage in a single image.  [Even your recent comments focus
on "fasdmping and loading" rather than on the comparison between
"loading source, and loading binary".]  I would prefer no proposal to 
one that had this outcome.  

If we had enough time, perhaps we could trade a few "secrets" about
what screw cases we individually have come up against, and how we
dealt with them.  For example, Lucid's implementation found it
prudent to keep a bit or so saying whether the symbol was a shadow
at the time it was originally read into the compiler.  I'm not 
prepared to argue the merits one way or the other about Lucid's bag
of trick; but at some informal session, we might have more to say.


-- JonL --


∂28-Apr-89  0555	CL-Compiler-mailer 	Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 3 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 28 Apr 89  05:55:00 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA18303; Fri, 28 Apr 89 06:54:50 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA13155; Fri, 28 Apr 89 06:54:48 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904281254.AA13155@defun.utah.edu>
Date: Fri, 28 Apr 89 06:54:46 MDT
Subject: Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 3
To: Jon L White <jonl@lucid.com>
Cc: sandra%defun@cs.utah.edu, dussud@lucid.com, cl-compiler@sail.stanford.edu
In-Reply-To: Jon L White <jonl@lucid.com>, Thu, 27 Apr 89 23:08:38 PDT

> Date: Thu, 27 Apr 89 23:08:38 PDT
> From: Jon L White <jonl@lucid.com>
> 
> I feel, like Patrick, that the proposal encourages the "home package"
> approach, which mistakenly presumes the problem arena of persistent
> object storage in a single image.  [Even your recent comments focus
> on "fasdmping and loading" rather than on the comparison between
> "loading source, and loading binary".]  I would prefer no proposal to 
> one that had this outcome.  

I guess I'm confused about this idea of "persistent object storage" that
you keep bringing up.  Can you elaborate on what it is, why you think
it applies only to the "home package" model, and why you think it's a
bad thing?

I'd like to point out that this proposal *is* concerned with
"fasdmping and loading" and if the comparison between loading source
and loading binary comes into it at all, that is purely secondary.  If
you'll recall, this issue was split off from issue
CONSTANT-COMPILABLE-TYPES, which definitely *does* concern itself with
the relationship between objects seen by COMPILE-FILE and the
corresponding objects constructed by LOAD.  Our job with this issue is
to define that relationship for interned symbols.

-Sandra
-------

∂02-May-89  0259	CL-Compiler-mailer 	issue COMPILE-FILE-SYMBOL-HANDLING, version 3
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 2 May 89  02:59:39 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate.lucid.com id AA02558g; Tue, 2 May 89 02:59:20 PDT
Received: by bhopal id AA11589g; Tue, 2 May 89 02:59:12 PDT
Date: Tue, 2 May 89 02:59:12 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8905020959.AA11589@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu, dussud@lucid.com
In-Reply-To: Sandra J Loosemore's message of Fri, 28 Apr 89 06:54:46 MDT <8904281254.AA13155@defun.utah.edu>
Subject: issue COMPILE-FILE-SYMBOL-HANDLING, version 3

re: I'd like to point out that this proposal *is* concerned with
    "fasdmping and loading" and if the comparison between loading source
    and loading binary comes into it at all, that is purely secondary. 

The first few words of the proposal go as follows:

    It is not clear how COMPILE-FILE is supposed to specify to LOAD how
    symbols in the compiled file should be interned.  . . . 

Thus I think the proposal should stick to the semantics of COMPILE-FILE,
in which case the paramount problem of interest (re packagifications) is 
consistency between loading a source file and loading the corresponding
binary produced by COMPILE-FILE.


"persistent object" storage simply means that you are trying to "dump"
onto some long-term store (such as a disk volume) some partial state
of your world, such that it can be recreated  exactly at a later time
(or, even in a later "image").  If that were the goal, then it would
be proper to focus on retaining every aspect of the data **** including 
the home package of each symbol so "dumped".

Is that clear enough?



-- JonL --

∂02-May-89  0702	CL-Compiler-mailer 	Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 3 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 2 May 89  07:02:50 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA29593; Tue, 2 May 89 08:02:57 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA14362; Tue, 2 May 89 08:02:54 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8905021402.AA14362@defun.utah.edu>
Date: Tue, 2 May 89 08:02:52 MDT
Subject: Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 3
To: Jon L White <jonl@lucid.com>
Cc: sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu, dussud@lucid.com
In-Reply-To: Jon L White <jonl@lucid.com>, Tue, 2 May 89 02:59:12 PDT

I admit I'm getting kind of confused about exactly what you would like
to see done with this issue.  I don't believe that tabling it and
saying nothing in the standard is an alternative; the version of
CONSTANT-COMPILABLE-TYPES we passed at the last meeting said that only
objects for which the notion of "similarity as a constant" is defined
can be dumped, and that that notion as applied to interned symbols
would be handled in this issue.  Saying nothing would be equivalent to
saying that you can't dump symbols. 

Let's try to go through this one step at a time.  Do you agree with me
that conforming programs must arrange for COMPILE-FILE to read the
symbols in the source file into the "right" package, in order for it
to correctly compile the file?  (This is because some of the symbols
may name macros and the like that must be recognized by the compiler.)

-Sandra
-------

∂05-May-89  0310	CL-Compiler-mailer 	issue COMPILE-FILE-SYMBOL-HANDLING, version 3
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 5 May 89  03:10:44 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA06349g; Fri, 5 May 89 03:10:20 PDT
Received: by bhopal id AA22511g; Fri, 5 May 89 03:10:11 PDT
Date: Fri, 5 May 89 03:10:11 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8905051010.AA22511@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 2 May 89 08:02:52 MDT <8905021402.AA14362@defun.utah.edu>
Subject: issue COMPILE-FILE-SYMBOL-HANDLING, version 3

re: Let's try to go through this one step at a time.  Do you agree with me
    that conforming programs must arrange for COMPILE-FILE to read the
    symbols in the source file into the "right" package, in order for it
    to correctly compile the file?  (This is because some of the symbols
    may name macros and the like that must be recognized by the compiler.)

What I'm not agreeing to is that this version of the standard should
spell that out (what "right" means etc).  Rather, it should clearly
spell out the goal of compatibility between result whether loading
the source code or loading the product of compile-file.  And leave it
alone at that (for now).


-- JonL --

∂06-May-89  0851	CL-Compiler-mailer 	Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 3 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 6 May 89  08:51:28 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA21323; Sat, 6 May 89 09:51:39 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA17013; Sat, 6 May 89 09:51:37 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8905061551.AA17013@defun.utah.edu>
Date: Sat, 6 May 89 09:51:35 MDT
Subject: Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 3
To: Jon L White <jonl@lucid.com>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Jon L White <jonl@lucid.com>, Fri, 5 May 89 03:10:11 PDT

> Date: Fri, 5 May 89 03:10:11 PDT
> From: Jon L White <jonl@lucid.com>
> 
> What I'm not agreeing to is that this version of the standard should
> spell that out (what "right" means etc).  Rather, it should clearly
> spell out the goal of compatibility between result whether loading
> the source code or loading the product of compile-file.  And leave it
> alone at that (for now).

I don't think such a statement, by itself, would be very useful.  The
point I was trying to make in my previous message is that there has to
be some restriction on conforming code in order for COMPILE-FILE to be
able to produce an output file that meets your requirements.  Simply
requiring COMPILE-FILE to produce an output file that, when loaded, is
equivalent to loading the source file is tantamount to requiring
implementations to solve the halting problem, because in the general
case, the compiler can't predict the runtime behavior of the code it
compiles. 

What I was going to suggest as an alternative to the current proposal
was to define that interned symbols are "similar as constants" if they
have the same print name and are accessible in all the same packages.
Then, we put a requirement on conforming programs: all of the interned
symbols referenced in the source file when it is processed by
COMPILE-FILE must be "similar as constants" to the corresponding
symbols that would result if the source file were processed by LOAD.
Since the relationship is transitive, this has the effect you want:
the interned symbols you get by LOADing the output of COMPILE-FILE are
"similar as constants" to the symbols you would get by LOADing the
original source file.

-Sandra
-------

∂10-May-89  0212	CL-Compiler-mailer 	issue COMPILE-FILE-SYMBOL-HANDLING, version 3
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 May 89  02:12:13 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate.lucid.com id AA01989g; Wed, 10 May 89 02:11:41 PDT
Received: by bhopal id AA02128g; Wed, 10 May 89 02:11:30 PDT
Date: Wed, 10 May 89 02:11:30 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8905100911.AA02128@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Sat, 6 May 89 09:51:35 MDT <8905061551.AA17013@defun.utah.edu>
Subject: issue COMPILE-FILE-SYMBOL-HANDLING, version 3

re: . . .  Simply
    requiring COMPILE-FILE to produce an output file that, when loaded, is
    equivalent to loading the source file is tantamount to requiring
    implementations to solve the halting problem, because in the general
    case, the compiler can't predict the runtime behavior of the code it
    compiles. 

This is a straw-man.  I explicitly rejected the notion of laying such
a requirement on COMPILE-FILE.  Instead I continue to press for
elucidation of the "goal" --  even with the admission that it is 
inherently impossible to do 100% correctly.

The danger of trying to specify in minute detail how implementations 
approach that goal is simply that you will rule out elegant, but 
not-yet-thoght-of refinements.  The rush to judgement in favor of the 
"home package" model is precisely an example of just such a premature 
forclosure.

I think I've said all I'm going to on this issue.


-- JonL --

∂10-May-89  1012	CL-Compiler-mailer 	Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 3 
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 10 May 89  10:11:42 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK   via Janet with NIFTP
           id aa11520; 10 May 89 15:48 BST
Date: Wed, 10 May 89 15:43:27 BST
Message-Id: <4754.8905101443@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 3
To: sandra (Sandra J Loosemore) <@cs.utah.edu:sandra@defun>, 
    Jon L White <@sail.stanford.edu:jonl@lucid.com>
In-Reply-To: Sandra J Loosemore's message of Sat, 6 May 89 09:51:35 MDT
Cc: cl-compiler@sail.stanford.edu

I've stayed out of this so far, but I'm a bit worried about the
direction it sometimes seems to be taking.  

I think we need to be able to specify a subset of conforming programs
(perhaps RPS's "well-formed programs") that have the same semantics
whether or not they're compiled.  Part of this, I think, must be to
have semantics that are sufficiently abstract.  I think it's difficult
to do this if membership in the subset depends on lots of internal
state.  Besides, if the semantics are too complex, how can we be sure
they're implemented correctly or that a program conforms?

> What I was going to suggest as an alternative to the current proposal
> was to define that interned symbols are "similar as constants" if they
> have the same print name and are accessible in all the same packages.

This might be ok, as far as "compilable types" is concerned, though
I'm a bit worried about the "accessible in all the same packages".
Isn't there some simpler way to determine the desired equivalence?

From what you say, it's not immediately clear to me whether or not
there are any interned symbols that have the same print name but are
nonetheless not "similar as constants".  I think the answer is
probably "no" but then I have doubts: if it were that simple, surely
the definition would be simpler -- maybe there's some subtlety that
I'm missing.  

Moreover, all uninterned symbols that are accessible in no package
(the most common case) but have the same print name would be "similar
as constants".  Is that what you intended?

> Then, we put a requirement on conforming programs: all of the interned
> symbols referenced in the source file when it is processed by
> COMPILE-FILE must be "similar as constants" to the corresponding
> symbols that would result if the source file were processed by LOAD.

I have some difficulty making sense of this.  Should the definition of
comforming program depend so much on the behavior of LOAD?  How do we
specify what LOAD does?

-- Jeff

∂10-May-89  1121	CL-Compiler-mailer 	Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 3 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 10 May 89  11:21:23 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA20597; Wed, 10 May 89 12:21:18 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA20132; Wed, 10 May 89 12:21:14 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8905101821.AA20132@defun.utah.edu>
Date: Wed, 10 May 89 12:21:12 MDT
Subject: Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 3
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Cc: sandra (Sandra J Loosemore) <sandra%defun@cs.utah.edu>,
        Jon L White <jonl@lucid.com>, cl-compiler@sail.stanford.edu
In-Reply-To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>, Wed, 10 May 89 15:43:27 BST

> Date: Wed, 10 May 89 15:43:27 BST
> From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
> 
> This might be ok, as far as "compilable types" is concerned, though
> I'm a bit worried about the "accessible in all the same packages".
> Isn't there some simpler way to determine the desired equivalence?

If this idea ever makes its way into a real proposal, I'd expect that
we'd want to define "accessible in all the same packages" more formally.
I don't know if a better definition would make it simpler or not.

One way of looking at this is to consider a symbol S that is
accessible (either directly or by inheritance) in some package P at
compile-time.  The compiler can tell the loader to find a symbol that
is similar as a constant to S by evaluating something like
    `(intern ,(symbol-name s) (find-package ,(package-name p)))

P might be *PACKAGE*, the symbol's home package, or possibly even some
other package.  The point of saying "all the same packages" is so that
implementors can choose any or all one of them to remember.

We might want to add some restrictions about consistency of
internal/external status to the definition, too.  I don't want to get
hung up on the details just yet, though. 

> From what you say, it's not immediately clear to me whether or not
> there are any interned symbols that have the same print name but are
> nonetheless not "similar as constants".  I think the answer is
> probably "no" but then I have doubts: if it were that simple, surely
> the definition would be simpler -- maybe there's some subtlety that
> I'm missing.

I'm not sure what you're asking here.  You could have symbols that
have the same print name but are not "similar as constants" in the
same way that you can have distinct symbols with the same print name
but in different packages.  A consequence of defining "similarity as
constants" in this way is that, within a single Lisp image, two
interned symbols are "similar as constants" if and only if they are
EQ.

> Moreover, all uninterned symbols that are accessible in no package
> (the most common case) but have the same print name would be "similar
> as constants".  Is that what you intended?

Yup.  That's exactly what proposal CONSTANT-COMPILABLE-TYPES says
about uninterned symbols.

> > Then, we put a requirement on conforming programs: all of the interned
> > symbols referenced in the source file when it is processed by
> > COMPILE-FILE must be "similar as constants" to the corresponding
> > symbols that would result if the source file were processed by LOAD.
> 
> I have some difficulty making sense of this.  Should the definition of
> comforming program depend so much on the behavior of LOAD?  How do we
> specify what LOAD does?

The intent here is to make sure that the symbols appearing within the
file are read by COMPILE-FILE into the same package that LOAD would
read them into.  I think the behavior of both COMPILE-FILE and LOAD
are well-defined (or at least definable) in this respect.  Can you
explain why you think this might cause problems?

-Sandra
-------

∂11-May-89  1132	CL-Compiler-mailer 	Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 3 
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 11 May 89  11:31:56 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK   via Janet with NIFTP
           id aa02005; 11 May 89 18:45 BST
Date: Thu, 11 May 89 18:27:08 BST
Message-Id: <6343.8905111727@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 3
To: sandra (Sandra J Loosemore) <@cs.utah.edu:sandra@defun>
Cc: Jon L White <@sail.stanford.edu:jonl@lucid.com>, 
    cl-compiler@sail.stanford.edu

> One way of looking at this is to consider a symbol S that is
> accessible (either directly or by inheritance) in some package P at
> compile-time.  The compiler can tell the loader to find a symbol that
> is similar as a constant to S by evaluating something like
>     `(intern ,(symbol-name s) (find-package ,(package-name p)))
> 
> P might be *PACKAGE*, the symbol's home package, or possibly even some
> other package.

But then importing would have the potential of changing a symbols
home package, which seems clearly wrong.

> > From what you say, it's not immediately clear to me whether or not
> > there are any interned symbols that have the same print name but are
> > nonetheless not "similar as constants".

> I'm not sure what you're asking here.

I guess what I'm asking is whether any symbols with the same print
name and home package can ever not be similar as constants, and if
not why can't you say something much more straightforward about
what similar as constants means.

> > Moreover, all uninterned symbols that are accessible in no package
> > (the most common case) but have the same print name would be "similar
> > as constants".  Is that what you intended?
> 
> Yup.  That's exactly what proposal CONSTANT-COMPILABLE-TYPES says
> about uninterned symbols.

Doesn't this more or less make gensym useless in code to be file
compiled -- you might as well use gentemp.

> > > Then, we put a requirement on conforming programs: all of the interned
> > > symbols referenced in the source file when it is processed by
> > > COMPILE-FILE must be "similar as constants" to the corresponding
> > > symbols that would result if the source file were processed by LOAD.
> > 
> > I have some difficulty making sense of this.  Should the definition of
> > comforming program depend so much on the behavior of LOAD?  How do we
> > specify what LOAD does?
> 
> The intent here is to make sure that the symbols appearing within the
> file are read by COMPILE-FILE into the same package that LOAD would
> read them into.  I think the behavior of both COMPILE-FILE and LOAD
> are well-defined (or at least definable) in this respect.  Can you
> explain why you think this might cause problems?

It just seems a pretty roundabout way to define the semantics of
programs.

∂12-May-89  1217	CL-Compiler-mailer 	Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 3 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 12 May 89  12:17:53 PDT
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
	id AA14358; Fri, 12 May 89 12:23:19 PDT
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.1)
	id AA24135; Fri, 12 May 89 12:16:20 PDT
Received: by clam.sun.com (4.0/SMI-4.0)
	id AA24150; Fri, 12 May 89 12:20:42 PDT
Date: Fri, 12 May 89 12:20:42 PDT
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8905121920.AA24150@clam.sun.com>
To: jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK, sandra%defun@cs.utah.edu
Subject: Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 3
Cc: cl-compiler@sail.stanford.edu, jonl@lucid.com

> > Date: Wed, 10 May 89 15:43:27 BST
> > From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
> > 
> > This might be ok, as far as "compilable types" is concerned, though
> > I'm a bit worried about the "accessible in all the same packages".
> > Isn't there some simpler way to determine the desired equivalence?
> 
> If this idea ever makes its way into a real proposal, I'd expect that
> we'd want to define "accessible in all the same packages" more formally.
> I don't know if a better definition would make it simpler or not.

I don't see how "accessible in all the same packages" can possibly
be used to determine whether two symbols are equivalent.  If, for example,
there are more packages in existence at loadtime than compiletime,
that should never cause a problem as long as the "relevant packages"
are unaltered.  The extra packages naturally may use any exported
symbols they wish without doing any harm.

The problem is with symbols that would print without qualification.
We could require enough consistency between the state of the compiletime
package system and the loadtime package system to ensure that
the same result is achieved whether the name is printed out without
qualification, or as a pair: symbol name, home package name.  The state
of the package system should be constrained to be such that
(read-from-string "pkgname::symname") yields a symbol with HOME
package PKGNAME.

Of course things are simpler if we define interned symbols to be
equivalent exactly when they have the same name and home package . . .

				-Cris

∂20-May-89  1201	CL-Compiler-mailer 	cl-compiler issues  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 May 89  12:01:07 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA22418; Sat, 20 May 89 13:01:26 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA05754; Sat, 20 May 89 13:01:23 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8905201901.AA05754@defun.utah.edu>
Date: Sat, 20 May 89 13:01:22 MDT
Subject: cl-compiler issues
To: cl-compiler@sail.stanford.edu

Just to remind you folks, we still have some pending cl-compiler issues
that need to be resolved before next month's meeting:

CLOS-MACRO-COMPILATION
  Gregor proposed an amendment at the last meeting to the MINIMAL 
  proposal.  Does anybody have any objections to this amendment?

COMPILE-ENVIRONMENT-CONSISTENCY
  Bob Kerns made an amendment to change the wording of section (g) to
  disallow the compiler from making assumptions about subtype/supertype
  relationships of type specifiers defined with DEFCLASS.  However, I'm
  not happy with this amendment as it stands because there's no way for
  users to test how a type specifier was defined.  It's been suggested
  that we deal with this by extending SYNTACTIC-ENVIRONMENT-ACCESS to
  add a function to inquire about type specifiers.  Anybody else have
  any further comments?

COMPILE-FILE-SYMBOL-HANDLING
  I wrote up a new proposal, NEW-REQUIRE-CONSISTENCY.  Some people 
  still seem to be unhappy with this but there doesn't seem to be
  overwhelming support for any of the other alternatives we've
  considered either.  Unless somebody else submits another proposal,
  I will probably just make another pass over the existing proposal
  to fix the wording problems that have been pointed out.

COMPILED-FUNCTION-REQUIREMENTS
  At the last meeting, we took a straw vote that showed most people
  want to retain the COMPILED-FUNCTION type.  Proposal TIGHTEN had the
  most support, but some people wanted it only to apply to
  COMPILE-FILE and not COMPILE (ie, COMPILE would allowed to be a 
  no-op).  Unless somebody objects to this, I'll prepare a new
  proposal.

CONSTANT-FUNCTION-COMPILATION
  The last message I got from RPG on this indicated that he thought
  that either function constants ought to be allowed in all situations,
  or not ever.  The current proposal effectively says that they're
  OK in code processed by COMPILE and EVAL, but not by COMPILE-FILE.
  As I said before though, we're pretty much stuck with this proposal
  if nobody else submits another one (which nobody has yet).

MACRO-CACHING
  The writeup needs to be simplified.  If Kent doesn't get around to
  doing it pretty soon, I'll work on it myself.

PROCLAIM-ETC-IN-COMPILE-FILE
  When we last left this issue, DECLAIM seemed to be winning out as the
  name for the new macro.

SYNTACTIC-ENVIRONMENT-ACCESS
  This issue still needs quite a bit of work.

If you have something to say on any of these issues, please do so ASAP.

-Sandra
-------

∂27-May-89  1258	CL-Compiler-mailer 	issue PROCLAIM-ETC-IN-COMPILE-FILE 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 May 89  12:57:57 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA04609g; Sat, 27 May 89 12:56:53 PDT
Received: by bhopal id AA18839g; Sat, 27 May 89 12:56:33 PDT
Date: Sat, 27 May 89 12:56:33 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8905271956.AA18839@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Wed, 5 Apr 89 12:52 EDT <890405125246.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: issue PROCLAIM-ETC-IN-COMPILE-FILE 

re: I think that ultimately PROCLAIM should be made to scope to a
    compilation unit when seen in a compile-time-too context, . . . 

So do I.  In fact, at one time, MacLisp treated top-level DECLARE's just 
that way.  A perfectly logical explanation for a "top-level" DECLARE in 
Common Lisp would be that it is embedded in an implicit LOCALLY that 
encompasses the entire file (or maybe the entire compilation unit.)  To 
some degree, various other compiler proposals would convert top-level 
DEFMACRO's into something akin to MACROLET's in just such a context (and 
similar pseudo-lexical treatment for many other top-level defining forms).



-- JonL --

∂29-May-89  1233	CL-Compiler-mailer 	Re: issue PROCLAIM-ETC-IN-COMPILE-FILE  
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 29 May 89  12:33:02 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK   via Janet with NIFTP
           id aa09685; 29 May 89 20:17 BST
Date: Mon, 29 May 89 20:22:47 BST
Message-Id: <10958.8905291922@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: Re: issue PROCLAIM-ETC-IN-COMPILE-FILE 
To: Jon L White <@uunet.uu.net:jonl@lucid.com>, 
    KMP@stony-brook.scrc.symbolics.com
In-Reply-To: Jon L White's message of Sat, 27 May 89 12:56:33 PDT
Cc: CL-Compiler@sail.stanford.edu

> re: I think that ultimately PROCLAIM should be made to scope to a
>     compilation unit when seen in a compile-time-too context, . . . 
> 
> So do I.  In fact, at one time, MacLisp treated top-level DECLARE's just 
> that way.  A perfectly logical explanation for a "top-level" DECLARE in 
> Common Lisp would be that it is embedded in an implicit LOCALLY that 
> encompasses the entire file (or maybe the entire compilation unit.)  To 
> some degree, various other compiler proposals would convert top-level 
> DEFMACRO's into something akin to MACROLET's in just such a context (and 
> similar pseudo-lexical treatment for many other top-level defining forms).

For what it's worth, I agree with this proposal, at least in spirit.

∂30-May-89  0755	CL-Compiler-mailer 	issue MACRO-CACHING, version 3
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 30 May 89  07:55:50 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA22479; Tue, 30 May 89 08:56:10 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA12762; Tue, 30 May 89 08:56:08 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8905301456.AA12762@defun.utah.edu>
Date: Tue, 30 May 89 08:56:06 MDT
Subject: issue MACRO-CACHING, version 3
To: cl-compiler@sail.stanford.edu

Here's a much simplified writeup for this issue, incorporating 
suggestions from Moon and Masinter.

Issue:        MACRO-CACHING
Forum:	      Compiler
References:   8.2 Macro Expansion (CLtL pp151-152),
	      Issues PACKAGE-CLUTTER, LISP-SYMBOL-REDEFINITION, 
	      CONSTANT-MODIFICATION,
	      and MACRO-ENVIRONMENT-EXTENT
Category:     Clarification
Edit history: 31-Jan-89, Version 1 by Pitman
	      11-Mar-89, Version 2 by Loosemore (add discussion)
	      30-May-89, Version 3 by Loosemore (simplify, rewrite)
Status:	      Ready for release

Problem Description:

 The description of *MACROEXPAND-HOOK* in CLtL states that its purpose
 is "to facilitate various techniques for improving interpretation
 speed by caching macro expansions".  However, there is no portable way
 to correctly perform such caching.

 Caching by displacement won't work because the same (EQ) macro call
 form may appear in distinct lexical contexts.  In addition, the macro
 call form may be a read-only constant.

 Caching by table lookup won't work because such a table would have to
 be keyed by both the macro call form and the environment, and proposal
 MACRO-ENVIRONMENT-EXTENT:DYNAMIC (passed at the March 1989 meeting)
 states that macro environments are permitted to have only dynamic
 extent.

 Caching by storing macro call forms and expansions within the
 environment object itself would work, but there are no portable
 primitives that would allow users to do this.


Proposal (MACRO-CACHING:DISALLOW):

 (1) Remove the suggestion that *MACROEXPAND-HOOK* be used for caching
     macroexpansions.  Instead, suggest that it might be used for
     debugging purposes.

 (2) Clarify that although there is no correct portable way to use
     *MACROEXPAND-HOOK* to cache macro expansions, there is no
     requirement that an implementation call the macro expansion
     function more than once for a given form and lexical environment.

 Rationale:

  Item (1) fixes the description of what *MACROEXPAND-HOOK* is for, from
  the point of view of a user.  Item (2) allows implementors to use
  other, correct but nonportable techniques for caching macro
  expansions.

Proposal (MACRO-CACHING:DEPRECATE):

 This is the same as DISALLOW, but also deprecate *MACROEXPAND-HOOK*.

 Rationale:

  Since *MACROEXPAND-HOOK* has now been shown to be unusable for its
  original stated purpose, it is of questionable usefulness.


Test Case:

 ;; #1: File compiling this definition in some implementations will produce
 ;;     a definition that returns read-only list structure. The call to EVAL
 ;;     on the result must not try to modify the read-only structure during
 ;;     macroexpansion. [See issue CONSTANT-MODIFICATION.]

 (DEFUN READ-ONLY-FOO () '(MACROLET ((FOO (&WHOLE FORM) (+ 1 1))) (FOO)))

 (EVAL (READ-ONLY-FOO))
 => 2

 ;; #2: This constructs a form and then uses it in two places in another
 ;;     constructed form. Each of the uses is in a different lexical
 ;;     contour, so must be expanded differently.

 (LET ((FOO (LIST 'FOO)))
   (EVAL `(LIST (MACROLET ((FOO (&WHOLE FORM) '(+ 1 1))) ,FOO)
		(MACROLET ((FOO (&WHOLE FORM) '(+ 1 2))) ,FOO))))
 => (2 3)  

 ;; #3: This is effectively the same thing but involves a MACROLET
 ;;     shadowing a DEFMACRO rather than two MACROLETs, since some
 ;;     implementations might only be caching expansions that come
 ;;     from DEFMACRO.

 (DEFMACRO FOO (&WHOLE FORM) '(+ 1 1))

 (LET ((FOO (LIST 'FOO)))
   (EVAL `(LIST ,FOO (MACROLET ((FOO (&WHOLE FORM) '(+ 1 2))) ,FOO))))
 => (2 3)


Current Practice:

 Symbolics Genera does not use displacing or table caching in either
 the interpreter or compiler.

 Symbolics Cloe, a compiled only implementation, uses table caching
 to boost compilation by a little. Running the test cases above turned
 up a bug (in test case #3), which is now in the process of being fixed.
 [The fact that a bug was turned up in code written by a CL implementor
  is an existence proof that the potential for trouble was not imagined.]

 The TI Explorer evaluator does displacement of macros, but is careful
 to correctly handle the cases exemplified in test cases #1 and #2.  
 It does not do the right thing for #3, but that is a bug that can
 fairly easily be fixed.

Cost to Implementors:

 This proposal is upward compatible with correct implementations.

Cost to Users:

 There is no cost to users, unless they were using semantically invalid
 or nonportable caching techniques.  Nonportable caching techniques might
 continue to work in some implementations.

Cost of Non-Adoption:

 Continued confusion about the purpose of *MACROEXPAND-HOOK* and the
 validity of macro caching techniques.

Benefits:

 The misleading description of *MACROEXPAND-HOOK*'s purpose is
 removed.

Aesthetics:

 Most people agree that macro caching techniques are only supposed to
 improve speed without affecting semantics.  This proposal is only
 intended to underscore that necessary truth.  Insofar as this is only
 a clarification, it presumably has no significant aesthetic impact.

Discussion:
-------

∂30-May-89  1423	CL-Compiler-mailer 	issue COMPILED-FUNCTION-REQUIREMENTS, version 6   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 30 May 89  14:23:35 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA13746; Tue, 30 May 89 15:23:58 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA13087; Tue, 30 May 89 15:23:54 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8905302123.AA13087@defun.utah.edu>
Date: Tue, 30 May 89 15:23:52 MDT
Subject: issue COMPILED-FUNCTION-REQUIREMENTS, version 6
To: cl-compiler@sail.stanford.edu

My notes on this issue from the last meeting are that there was
support for proposal TIGHTEN but that we wanted to fix the proposal to
allow COMPILE to be a no-op.  Here's the new version incorporating
this change. 

Forum:		Compiler
Issue:		COMPILED-FUNCTION-REQUIREMENTS
References:	CLtL p. 32, 76, 112, 143, 438-439
		Issue FUNCTION-TYPE (passed)
		Issue COMPILER-LET-CONFUSION (passed)
		Issue EVAL-WHEN-NON-TOP-LEVEL (passed)
		Issue LOAD-TIME-EVAL (passed)
		Issue COMPILE-ENVIRONMENT-CONSISTENCY
		Issue COMPILE-ARGUMENT-PROBLEMS (passed)
Category:	CLARIFICATION, CHANGE
Edit History:   V1, 3 Jan 1989 Sandra Loosemore
		V2, 10 Jan 1989, Sandra Loosemore (additional proposal)
		V3, 10 Feb 1989, Sandra Loosemore (new proposal)
		V4, 11 Mar 1989, Sandra Loosemore (fix wording to agree
			with other pending proposals)
		V5, 23 Mar 1989, Sandra Loosemore (restore proposal FLUSH)
		V6, 30 May 1989, Sandra Loosemore (fix proposal TIGHTEN to
			apply only to COMPILE-FILE)
Status:		Ready for release


Problem Description:

There is confusion about what functions might be or must be of type
COMPILED-FUNCTION, and what attributes must be true of
COMPILED-FUNCTIONs.  Is the distinction between COMPILED-FUNCTIONs and
other functions only one of representation, or can user programs infer
anything about COMPILED-FUNCTIONs?  Are implementations required to
distinguish between compiled and non-compiled functions?

CLtL defines a COMPILED-FUNCTION as "a compiled code object".  (Issue
FUNCTION-TYPE says only that COMPILED-FUNCTION must be a subtype of
FUNCTION.)  Although it is not explicitly stated, CLtL implies that
compiled code must conform to certain rules; in particular, it states
that all macros are expanded at compile time, and specifies different
behavior for the COMPILER-LET and the EVAL-WHEN special forms
depending on whether they are interpreted or compiled.

The description of COMPILE in CLtL says that "a compiled-function object
[is] produced".  It is not clear to everyone whether this implies that
COMPILED-FUNCTION-P must be true of such functions.  CLtL says nothing
about whether functions defined in files compiled with COMPILE-FILE and
subsequently loaded must be of type COMPILED-FUNCTION.

This proposal presents a simple model of the compilation process.  A
minimal compiler could be implemented to perform a code walk to apply
the indicated transformations to the function source code.  Of course,
most compilers will perform other transformations as well, such as
translating the Lisp source code into a representation that is more
compact or which can be executed more efficiently.


Proposal COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN:

(1) Clarify that if a function is of type COMPILED-FUNCTION, the
    following are guaranteed about the function:

    - All macro calls appearing lexically within the function have 
      already been expanded and will not be expanded again when the
      function is called.  (See CLtL p. 143.)  The process of
      compilation effectively turns MACROLET and SYMBOL-MACROLET
      constructs into PROGNs with all instances of the local macros
      in the body fully expanded.

    - The compiler must capture declarations to determine whether
      variable bindings and references appearing lexically within 
      the function are to be treated as lexical or special.

    - Lexically nested EVAL-WHENs have been processed as stated in
      proposal EVAL-WHEN-NON-TOP-LEVEL; either the body is treated as
      an implicit PROGN or as the constant NIL.

    - If the function contains lexically nested LOAD-TIME-VALUE forms,
      these have already been pre-evaluated and will not be evaluated
      again when the function is called.

(2) Implementations are free to classify all functions as 
    COMPILED-FUNCTIONs, provided that all functions satisfy the criteria
    listed in item (1).  It is also permissible for functions that are
    not COMPILED-FUNCTIONs to satisfy the above criteria.

(3) Clarify when functions are defined in a file which is compiled
    with COMPILE-FILE, and the compiled file is subsequently LOADed,
    objects of type COMPILED-FUNCTION result.

(4) Clarify that COMPILE may or may not produce an object of type
    COMPILED-FUNCTION; if the implementation cannot compile a function,
    it may simply do nothing at all.  Change the description of
    COMPILE (from proposal COMPILE-ARGUMENT-PROBLEMS:CLARIFY) to state
    that the behavior of COMPILE when passed a function that was
    defined in a non-null lexical environment is unspecified (rather
    than "is an error").


Rationale:

This proposal allows users to count on COMPILE-FILE always producing
objects that are COMPILED-FUNCTION-P.  It also allows for the 
possibility that COMPILE may not actually do anything interesting
in some implementations.

Some specific properties are assigned to compiled functions.  Users
would be able to rely on any function which is of type
COMPILED-FUNCTION having really been (at least partially) compiled.

It also states what many people believe to be the minimum functionality 
required of a compiler.

 
Current Practice:

It appears that most implementations currently distinguish compiled
versus non-compiled functions on the basis of representation.  It seems
unlikely that any implementation would have problems satisfying the
stated minimum requirements for compilation.

Lucid uses the same representation for both compiled and non-compiled
functions, except there is a bit in the header used to distinguish them.

A-Lisp uses the same representation for both compiled and interpreted
functions and currently labels them both as COMPILED-FUNCTION, but the
implementation of COMPILED-FUNCTION-P could be easily fixed to
distinguish "real" compiled functions.

On the TI Explorer, the COMPILE function can return an object of
either type COMPILED-FUNCTION or LEXICAL-CLOSURE, where the latter
consists of two components -- an environment and a COMPILED-FUNCTION.
There is confusion about whether microcoded functions should be
considered compiled or not.

In Utah Common Lisp, COMPILED-FUNCTION-P currently returns true of all
function objects, but there is an internal tag field in the object
which allows real compiled functions to be distinguished from
interpreted functions.


Cost to implementors:

Unknown, but probably not too great.  Many implementations will
probably have to make some minor changes to representation of
functions and/or to the definition of COMPILED-FUNCTION-P, but
probably most of those changes are necessary to support the
FUNCTION-TYPE proposal anyway.


Cost to users:

Probably minimal.  Since the COMPILED-FUNCTION type specifier is
currently ill-defined, it is hard to imagine that existing programs
can portably rely on any interpretation of what it means that is
inconsistent with what is presented here.


Benefits:

The specification of what the compiler must do is made more explicit.


Discussion:

This writeup originally contained two other proposals, FLUSH and
TIGHTEN-COMPILE.  A straw vote at the March 1989 meeting indicated
that proposal TIGHTEN had the most support.

The FIXNUM and BIGNUM types were also defined in CLtL solely on the
basis of distinguished representations, and that this definition has
proved inadequate for just about all portable usages of these type
specifiers.  Defining COMPILED-FUNCTION solely on the basis of
distinguished representation seems like a bad idea.

David Gray notes:
  We make good use of the type COMPILED-FUNCTION in our implementation,
  but all of the accessor functions for objects of that type are
  non-standard, which makes me wonder if it might be best to just remove
  this type from the standard along with BIGNUM.

One use of the COMPILED-FUNCTION type is in declarations.  A-Lisp and
Lucid, for example, can compile FUNCALL more efficiently if it can be
determined that the function is of type COMPILED-FUNCTION.  However,
in order for such declarations to be really useful, there should be a
way to construct an object which is guaranteed to be of type
COMPILED-FUNCTION.

Moon says:
  I much prefer the option FLUSH...
  This type has no portable meaning and never should have existed.

Pierson says:
  What I (and believe Kent) want is a guarantee that [COMPILE] won't
  signal an error; if nothing else works COMPILE will simply apply
  #'IDENTITY to the symbol's function.  Specifically, it should be
  legal and safe to attempt to speed up my current program(s) by
  doing:

    (DO-SYMBOLS (SYM <my-package>)
    	(WHEN (FBOUNDP SYM) (COMPILE SYM)))
-------

∂01-Jun-89  0852	CL-Compiler-mailer 	issue CLOS-MACRO-COMPILATION  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 1 Jun 89  08:52:51 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA25231; Thu, 1 Jun 89 09:53:09 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA14532; Thu, 1 Jun 89 09:53:06 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906011553.AA14532@defun.utah.edu>
Date: Thu, 1 Jun 89 09:53:05 MDT
Subject: issue CLOS-MACRO-COMPILATION
To: cl-compiler@sail.stanford.edu
Cc: common-lisp-object-system@sail.stanford.edu

I'm in the process of revising the writeup on this issue to
incorporate the amendment Gregor proposed at the last meeting, and I
have a question.

The amendment uses the term "load time" to describe the time at which
certain things happen.  I think is not really what we want, since it's
possible that the defining macro in question might not appear at top
level.  I'd suggest saying something like "the time at which the macro
is normally executed" instead. 

However, to me this doesn't really make sense in the context of the
amendment to the DEFINE-METHOD-COMBINATION language: "clarify that the
bodies of such forms are evaluated no earlier than load time".  Does
this really mean "no earlier than the time at which the
DEFINE-METHOD-COMBINATION macro is executed"?  I've been under the
impression that DEFINE-METHOD-COMBINATION defines a functional object
and that its body could be evaluated no earlier than the time that
function is invoked, which would be (at the earliest) when a
DEFGENERIC form that references it is executed.  Or am I confused
again? 

-Sandra
-------

∂11-Jun-89  1239	CL-Compiler-mailer 	issue CLOS-MACRO-COMPILATION, version 4 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 11 Jun 89  12:39:01 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA04709; Sun, 11 Jun 89 13:39:24 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA20945; Sun, 11 Jun 89 13:39:21 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906111939.AA20945@defun.utah.edu>
Date: Sun, 11 Jun 89 13:39:20 MDT
Subject: issue CLOS-MACRO-COMPILATION, version 4
To: cl-compiler@sail.stanford.edu

This version incorporates Gregor's amendment from the last meeting,
with a few minor changes to the wording that I'm responsible for.  If
you don't like it, speak now.... 

Forum:		Compiler
Issue:		CLOS-MACRO-COMPILATION
References:	CLOS chapters 1 & 2 (88-002R)
		CLOS chapter 3 (89-003)
		Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
		Issue DEFINING-MACROS-NON-TOP-LEVEL
Category:	CLARIFICATION
Edit History:   V1, 10 Mar 1989, Sandra Loosemore
		V2, 13 Mar 1989, Sandra Loosemore
		V3, 21 Mar 1989, Sandra Loosemore (fix error language)
		V4, 11 Jun 1989, Sandra Loosemore (Gregor's amendment)
Status:		Ready for release


Problem Description:

Do the CLOS defining macros (DEFCLASS, DEFMETHOD, DEFGENERIC, and
DEFINE-METHOD-COMBINATION) have compile-time side-effects similar
to those for DEFSTRUCT or DEFMACRO?

A part of the problem is that we do not currently have a full
understanding of all the issues involved.  In particular, work on
defining the CLOS meta-object protocol is still in progress.  The goal
of this proposal is to say enough about the behavior of these macros
in the standard so that users can use them portably in compiled code,
but to leave as much of the behavior as possible unspecified to avoid
placing undue restrictions on the meta-object protocol.


Proposal CLOS-MACRO-COMPILATION:MINIMAL:

 State that top-level calls to the CLOS defining macros have the
 following compile-time side-effects.  Any other compile-time behavior
 is explicitly left unspecified.

  DEFCLASS:
  
  * The class name may appear in subsequent type declarations.
  
  * The class name can be used as a specializer in subsequent 
    DEFMETHOD forms.
  
  DEFGENERIC:
  
  * The generic function can be referenced in subsequent DEFMETHOD forms.  

  * The generic function is not callable at compile-time.
  
  DEFMETHOD:
  
  * The method is not callable at compile-time.  If there is a generic
    function with the same name at compile-time, compiling a DEFMETHOD
    will not add the method to that generic function.  

    The error-signalling behavior described in the specification of
    DEFMETHOD in CLOS chapter 2 (if the function isn't a generic function
    or if the lambda-list is not congruent) happens only when the defining
    form is executed, not at compile time.

    The forms in EQL specializers are evaluated when the defining form
    is executed.  The implementation may try to evaluate them at
    compile time, but must not depend on being able to do so.

    
  DEFINE-METHOD-COMBINATION:
  
  * The method combination can be used in subsequent DEFGENERIC forms.  

    The body of a DEFINE-METHOD-COMBINATION form is evaluated no earlier 
    than when the defining macro is executed and possibly as late as 
    generic function invocation time.  The compiler may attempt to
    evaluate these forms at compile time but must not depend on being able
    to do so.

 Rationale:

  The compile-time behavior of DEFCLASS is similar to DEFSTRUCT or
  DEFTYPE.  

  DEFGENERIC and DEFMETHOD are similar to DEFUN, which doesn't add the
  function definition to the compile-time environment.  Since generic
  functions may be freely redefined between compile and run time (just
  like any other function), a method may end up "belonging" to a
  different generic function at load time than at compile time.  This
  is why it is inappropriate to signal errors about congruency problems
  (etc) until the method is actually added to the generic function at
  run time.


Current Practice:

  The items listed under DEFCLASS in proposal MINIMAL are fairly standard
  programming style.

  Flavors does not support compile-time instantiation of classes.  It
  does not make method combinations available at compile-time either, but
  Moon considers that to be a bad design choice.

Cost to implementors:

  Unknown.

Cost to users:

  Unknown, but probably fairly small.

  Wrapping an (EVAL-WHEN (EVAL COMPILE LOAD) ...) around the appropriate
  definitions will make sure they are fully defined at compile-time.
  Alternatively, the definitions could be placed in a separate file,
  which is loaded before compiling the file that depends on those
  definitions.

Benefits:

  Programmers can rely on programs that use the CLOS defining macros 
  being able to compile correctly in all implementations, without having
  to wrap explicit EVAL-WHENs around every macro call.

Discussion:

  This writeup is based on discussions between Moon, Gray, and
  Loosemore, who are mostly in agreement on the things presented in
  proposal MINIMAL.  We have purposely avoided saying anything about
  whether meta-objects representing the classes, methods, etc. get
  created at compile-time, or whether such meta-objects are fully or
  partially defined.  The basic questions addressed by this issue are
  what kinds of things can be defined and then used during compilation
  of the same file that defines them, and what restrictions might apply.

  These proposals are not completely compatible with the meta-object 
  protocol document (89-003).  Gregor Kiczales says:
    No one believes that what is written in draft 10 of the MOP is valid.

  Sandra Loosemore says:
    Although I admit I don't understand all of the issues involved with
    the meta-object protocol, I prefer proposal MINIMAL over 
    NOT-SO-MINIMAL.  I don't think leaving the issue of whether or not
    classes can be instantiated at compile-time unspecified places an
    undue burden on users, and it does leave more freedom for the
    meta-object protocol to decide what the right behavior really is.

  Dick Gabriel notes:
    The question I have about the process going on with respect to the
    CLOS-MACRO-COMPILATION issue is whether the fine-grained behavior of
    CLOS under various compilation/evaluation situations is being
    over-specified. 

    At this stage of the game I worry that we might go a little too far in
    one direction in specification when we are actually engaged in design
    work. This isn't intended to be a criticism of any committees, but I
    would feel a lot more comfortable with a conservative specification
    that defined well-formed programs being loaded or compiled in fresh
    Common Lisps with a pretty simple eval-when model that is easier to
    specify and which makes it easy for all but the hairiest
    compilation-environment-frobbing programs to be written.

-------

∂13-Jun-89  1522	CL-Compiler-mailer 	Issue: SYNTACTIC-ENVIRONMENT-ACCESS (version 9)   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 13 Jun 89  15:20:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 610815; 13 Jun 89 18:22:33 EDT
Date: Tue, 13 Jun 89 18:22 EDT
From: Kim Barrett <IIM@ECLA.USC.EDU>
Sender: Moon@STONY-BROOK.SCRC.Symbolics.COM
Subject: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (version 9)
To: CL-Compiler@sail.stanford.edu
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, IIM@ECLA.USC.EDU
Message-ID: <19890613222245.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

Kim sent us version 8 on floppy disk with a request to redistribute to
the network.  I've made a couple of typographical corrections.

Forum:          Compiler
Issue:          SYNTACTIC-ENVIRONMENT-ACCESS
References:     CLtL Chapter 8: Macros,
                CLtL Chapter 9: Declarations,
                Issue COMPILE-FILE-ENVIRONMENT,
                Issue DEFINING-MACROS-NON-TOP-LEVEL,
                Issue DESTRUCTURING-BIND,
                Issue EVAL-WHEN-NON-TOP-LEVEL,
                Issue GET-SETF-METHOD-ENVIRONMENT,
                Issue FUNCTION-NAME,
                Issue FUNCTION-TYPE,
                Issue MACRO-ENVIRONMENT-EXTENT,
                Issue MACRO-FUNCTION-ENVIRONMENT,
                Issue PROCLAIM-LEXICAL
Category:       ADDITION
Edit history:   Version 1, 2-Oct-88, Eric Benson
                Version 2, 17-Feb-89, Kim A. Barrett
                Version 3, 9-Mar-89, Kim A. Barrett (respond to comments)
                Version 4, 12-Mar-89, Sandra Loosemore (more revisions)
                Version 5, 20-Mar-89, Sandra Loosemore (only proposal SMALL)
                Version 6, 23-Mar-89, Sandra Loosemore (more revisions)
                Version 7,  7-Apr-89, Moon & Barrett (more revisions)
                Version 8,  9-Jun-89, Kim A. Barrett (add DEFDECLARE)
                Version 9, 13-Jun-9, Moon (small corrections)
Status:         **DRAFT**


Problem description:

 When macro forms are expanded, the expansion function is called with two
 arguments: the form to be expanded, and the environment in which the form was
 found.  The environment argument is of limited utility.  The only use
 sanctioned currently is as an argument to MACROEXPAND or MACROEXPAND-1 or
 passed directly as an argument to another macro expansion function.  Recently
 passed cleanup issues allow it as an argument to MACRO-FUNCTION and to
 GET-SETF-METHOD.

 It is very difficult to write a code walker that can correctly handle local
 macro and function definitions, due to insufficient access to the information
 contained in environments and the inability to augment environments with local
 definitions.


Proposal (SYNTACTIC-ENVIRONMENT-ACCESS:SMALL):

 The following functions provide information about syntactic environment
 objects.  In all of these functions the argument named ENV is an environment
 of the sort received by the &ENVIRONMENT argument to a macro or as the
 environment argument for EVALHOOK.  (It is not required that implementations
 provide a distinguished representation for such objects.)  Optional "env"
 arguments default to NIL, which represents the local null lexical environment
 (containing only global definitions and proclamations that are present in the
 runtime environment).  All of these functions should signal an error of type
 TYPE-ERROR if the value of an environment argument is not a syntactic
 environment.

 The accessors VARIABLE-INFORMATION, FUNCTION-INFORMATION, and
 DECLARATION-INFORMATION retrieve information about declarations that are in
 effect in the environment.  Since implementations are permitted to ignore
 declarations (except for SPECIAL declarations and OPTIMIZE SAFETY
 declarations if they ever compile unsafe code), these accessors are required
 only to return information about declarations that were explicitly added to
 the environment using AUGMENT-ENVIRONMENT.  They might also return
 information about declarations recognized and added to the environment by the
 interpreter or the compiler, but that is optional at the discretion of the
 implementer.  Implementations are also permitted to canonicalize
 declarations, so the information returned by the accessors might not be
 identical to the information that was passed to AUGMENT-ENVIRONMENT.

 VARIABLE-INFORMATION variable &optional env            [Function]

  This function returns information about the interpretation of the symbol
  VARIABLE when it appears as a variable within the lexical environment ENV.
  The following three values are returned.

  The first value indicates the type of definition or binding which is apparent
  in ENV:

    NIL            There is no apparent definition or binding for variable.

    :SPECIAL       VARIABLE refers to a special variable, either declared 
                   or proclaimed. 

    :LEXICAL       VARIABLE refers to a lexical variable.

    :SYMBOL-MACRO  VARIABLE refers to a SYMBOL-MACROLET binding.

    :CONSTANT      VARIABLE refers to a named constant, defined by
                   DEFCONSTANT.

 [Note: If issue PROCLAIM-LEXICAL passes, then the :LEXICAL result will also
  refer to variables proclaimed lexical.]

  The second value indicates whether there is a local binding of the name.  If
  the name is locally bound, the second value is true.  Otherwise, NIL is
  returned.

  The third value is a property list containing information about declarations
  that apply to the apparent binding of the variable.  The keys in the property
  list are symbols which name declaration-specifiers, and the format of the
  corresponding values depends on the particular declaration-specifier
  involved.  The standard declaration-specifiers that might appear as keys in
  this property list are:

    DYNAMIC-EXTENT a non-NIL value indicates that the variable has been
                declared DYNAMIC-EXTENT. If the value is NIL, the property
                might be omitted.

    IGNORE      a non-NIL value indicates that the variable has been declared
                IGNORE. If the value is NIL, the property might be omitted.

    TYPE        a type specifier associated with the variable by a TYPE
                declaration or an abbreviated declaration such as (FIXNUM VAR).
                If no explicit association exists, either by PROCLAIM or
                DECLARE, then the type specifier is T.  It is permissible for
                implementations to use a type specifier that is equivalent
                to or a supertype of the one appearing in the original
                declaration.  If the value is T, the property might be
                omitted.

  If an implementation supports additional declaration-specifiers that apply to
  variable bindings, those declaration-specifiers might also appear in the
  property list.  The property list might contain multiple entries for a given
  property.  The consequences of destructively modifying the list structure of
  this property list or its elements are undefined.

  Programmers are reminded that the global binding might differ from the local
  one, and can be retrieved by calling VARIABLE-INFORMATION again with a null
  lexical environment.


 FUNCTION-INFORMATION function &optional env            [Function]

  This function returns information about the interpretation of the function
  name FUNCTION when it in a functional position within lexical environment
  ENV.  The following three values are returned.

  The first value indicates the type of definition or binding of the function
  name which is apparent in ENV:

    NIL            There is no apparent definition for FUNCTION.

    :FUNCTION      FUNCTION refers to a function.

    :MACRO         FUNCTION refers to a macro.

    :SPECIAL-FORM  FUNCTION refers to a special form.

  Some function names can refer to both a global macro and a global special
  form.  In such a case, the macro takes precedence, and :MACRO is returned as
  the first value.

  The second value specifies whether the definition is local or global.  If
  local, the second value is true, and it is false when the definition is
  global.

  The third value is a property list containing information about declarations
  that apply to the apparent binding of the function.  The keys in the property
  list are symbols which name declaration-specifiers, and the format of the
  corresponding values depends on the particular declaration-specifier
  involved.  The standard declaration-specifiers that might appear as keys in
  this property list are:

    INLINE      one of the symbols INLINE, NOTINLINE, or NIL to indicate
                whether the function name has been declared INLINE, has been
                declared NOTINLINE, or neither.  If the value is NIL, the
                property might be omitted.

    FTYPE       the type specifier associated with the function name in the
                environment, or the symbol FUNCTION if there is no functional
                type declaration or proclamation associated with the function
                name.  This value might not include all the apparent FTYPE
                declarations for the function name.  It is permissible for
                implementations to use a type specifier that is equivalent
                to or a supertype of the one that appeared in the original
                declaration.  If the value is FUNCTION, the property might be
                omitted. 

  If an implementation supports additional declaration-specifiers that apply to
  function bindings, those declaration-specifiers might also appear in the
  property list.  The property list might contain multiple entries for a given
  property.  In this case the value associated with the first entry has
  precedence.  The consequences of destructively modifying the list structure
  of this property list or its elements are undefined.

 [If issue DYNAMIC-EXTENT-FUNCTION passes, the property DYNAMIC-EXTENT will
  be added to the above table.]

  Programmers are reminded that the global binding might differ from the local
  one, and can be retrieved by calling FUNCTION-INFORMATION again with a null
  lexical environment.


 DECLARATION-INFORMATION decl-name &optional env        [Function]

  This function returns a list of declaration-specifiers whose CAR is the
  symbol DECL-NAME that are in force in the environment ENV, sorted so that the
  most recent declaration is first on the list.  Only declarations that do not
  apply to function or variable bindings (i.e., those that are "pervasive") can
  be accessed with this function.

  It is required that this function recognize OPTIMIZE and DECLARATION as
  DECL-NAMEs.  The values returned for these two cases are as follows:

    OPTIMIZE    a list whose entries are of the form (quality value), where
                "quality" is one of the optimization qualities defined by the
                standard (SPEED, SAFETY, COMPILATION-SPEED, SPACE, and DEBUG)
                or some implementation-specific optimization quality, and
                "value" is an integer in the range 0 to 3.  The returned list
                always contains an entry for each of the standard qualities and
                for each of the implementation-specific qualities.  In the
                absence of any previous declarations, the associated values are
                implementation-dependent.  The list might contain multiple
                entries for a quality, in which case the first such entry
                specifies the current value.

    DECLARATION a list of the declaration names which have been proclaimed as
                valid through the use of the DECLARATION proclamation.

  If an implementation has been extended to recognize additional
  pervasive declaration specifiers in DECLARE or PROCLAIM, it is required that
  either the DECLARATION-INFORMATION function should also recognize those
  declarations, or that the implementation provide an accessor that is
  specialized for that declaration specifier.


 AUGMENT-ENVIRONMENT env &KEY variable
                              symbol-macro
                              function
                              macro
                              declare                           [Function]

  This function returns a new environment containing the information present in
  ENV, augmented with the information provided by the keyword arguments.  It is
  intended to be used by program analyzers that perform a code walk.

  The arguments are supplied as follows:

  :VARIABLE     A list of symbols which shall be visible as bound variables in
                the new environment.  Whether each binding is to be interpreted
                as special or lexical depends on SPECIAL declarations recorded
                in the environment or provided in the :DECLARE argument list.

  :SYMBOL-MACRO A list of symbol macro definitions, specified as a list of
                (name definition) lists (that is, in the same format as the
                CADR of a SYMBOL-MACROLET special form).  The new environment
                will have local symbol-macro bindings of each symbol to the
                corresponding expansion, so that MACROEXPAND will be able to
                expand them properly.  A type declaration in the :DECLARE
                argument which refers to a name in this list implicitly
                modifies the definition associated with the name.  The effect
                is to wrap a THE form mentioning the type around the
                definition.

  :FUNCTION     A list of function names which shall be visible as local
                function bindings in the new environment.

  :MACRO        A list of local macro definitions, specified as a list of (name
                definition) lists.  Each definition must be a function of two
                arguments (a form and an environment).  The new environment
                will have local macro bindings of each name to the
                corresponding expander function, which will be returned by
                MACRO-FUNCTION and used by MACROEXPAND.

  :DECLARE      A list of decl-specs.  Information about these declarations can
                be retrieved from the resulting environment using the
                VARIABLE-INFORMATION, FUNCTION-INFORMATION, and
                DECLARATION-INFORMATION accessors.

  An error is signalled if any of the symbols naming macros in the
  :SYMBOL-MACRO alist are also included in the :VARIABLE list.  An error is
  signaled if any of the symbols naming macros in the :SYMBOL-MACRO alist are
  also included in a SPECIAL decl-spec in the :DECLARE argument.  An error is
  signalled if any of the names of macros in the :MACRO alist are also included
  in the :FUNCTION list.  The consequences of destructively modifying the list
  structure of any of the arguments to this function are undefined.

  The condition type of each of these errors is PROGRAM-ERROR.

  The extent of the returned environment is the same as the extent of the
  argument environment.  The result might share structure with the argument
  environment, but the argument environment is not modified.

  While an environment argument from EVALHOOK is permitted to be used as the
  environment argument for this function, the reverse is not true.  If an
  attempt is made to use the result of AUGMENT-ENVIRONMENT as the environment
  argument for EVALHOOK, the consequences are undefined.  The environment
  returned by AUGMENT-ENVIRONMENT can only be used for syntactic analysis, ie.
  the functions specified by this proposal and functions such as MACROEXPAND.


 DEFDECLARE decl-name lambda-list &body body                            [Macro]

  Define a handler for the named declaration.  This is the mechanism by which
  AUGMENT-ENVIRONMENT is extended to support additional declaration
  specifiers.  The function defined by this macro will be called with two
  arguments, a decl-spec whose CAR is decl-name, and the ENV argument to
  AUGMENT-ENVIRONMENT.  Two values must be returned by the function.  The
  first value must be one of the following keywords:

  :VARIABLE     the declaration applies to variable bindings.
  :FUNCTION     the declaration applies to function bindings.
  :DECLARE      the declaration is pervasive, rather than applying to bindings.

  For the case where the first value indicates the declaration applies to
  bindings, the second value is a list, the elements of which are lists of the
  form (binding-name property value).  If the corresponding information
  function (either VARIABLE-INFORMATION or FUNCTION-INFORMATION) is applied to
  the binding name and the augmented environment, the property list which is
  the third value returned by the information function will contain the value
  under the specified property.

  When the first value is :DECLARE, the second value is a cons whose CAR is a
  property and whose CDR is the associated value.  The function
  DECLARATION-INFORMATION, when applied to the property and the augmented
  environment, will return the associated value.


 PARSE-MACRO name lambda-list body &optional env        [Function]

  This function is used to process a macro definition in the same way
  as DEFMACRO and MACROLET.  It returns a lambda-expression that accepts
  two arguments (a form and an environment).  The "name", "lambda-list",
  and "body" arguments correspond to the parts of a DEFMACRO or MACROLET
  definition.

  The "lambda-list" argument can include &ENVIRONMENT and &WHOLE.  The "name"
  argument is used to enclose the "body" in an implicit BLOCK, and might also
  be used for implementation-dependent purposes (such as including the name of
  the macro in error messages if the form does not match the lambda-list).


 ENCLOSE lambda-expression &optional env                [Function]

  This function returns an object of type FUNCTION that is equivalent to what
  would be obtained by evaluating `(FUNCTION ,LAMBDA-EXPRESSION) in syntactic
  environment ENV.  The consequences are undefined if any of the local
  variable or function bindings (but not macro definitions) that are visible
  in the lexical environment represented by ENV are referenced within the
  LAMBDA-EXPRESSION.


Rationale:

  This proposal defines a minimal set of accessors (VARIABLE-INFORMATION,
  FUNCTION-INFORMATION, and DECLARATION-INFORMATION) and a constructor
  (AUGMENT-ENVIRONMENT) for environments.

  All of the standard declaration specifiers, with the exception of SPECIAL,
  can be defined fairly easily using DEFDECLARE.  It also seems to be able
  to handle most extended declarations.

  The PARSE-MACRO function is provided so that users don't have to write their
  own code to destructure macro arguments.  With the addition of
  DESTRUCTURING-BIND to the language, this function is not entirely necessary.
  However, it is probably worth including anyway, since any program-analyzing
  program is going to need to define it, and the definition isn't completely
  trivial.

  ENCLOSE is needed to allow expander functions to be defined in a non-NULL
  lexical environment, as required by DEFINING-MACROS-NON-TOP-LEVEL:ALLOW.  It
  also provides a mechanism by which the forms in an (EVAL-WHEN (COMPILE) ...)
  can be executed in the enclosing environment (see Issue
  EVAL-WHEN-NON-TOP-LEVEL).

  Making declarations from an &ENVIRONMENT or EVALHOOK environment optional
  continues to allow implementations the freedom simply to ignore all such
  declarations in the compiler or interpreter.


Examples:

#1:  This example illustrates the first two values returned by the function
     VARIABLE-INFORMATION.

  (DEFMACRO KIND-OF-VARIABLE (VAR &ENVIRONMENT ENV)
    (MULTIPLE-VALUE-BIND (KIND BINDINGP)
                         (VARIABLE-INFORMATION VAR ENV)
      `(LIST ',VAR ',KIND ',BINDINGP)))

  (DEFVAR A)

  (DEFCONSTANT B 43)

  (DEFUN TEST ()
    (LET (C)
      (LET (D)
        (DECLARE (SPECIAL D))
        (SYMBOL-MACROLET ((E ANYTHING))
          (LIST (KIND-OF-VARIABLE A)
                (KIND-OF-VARIABLE B)
                (KIND-OF-VARIABLE C)
                (KIND-OF-VARIABLE D)
                (KIND-OF-VARIABLE E)
                (KIND-OF-VARIABLE F))))))

  (TEST) -> ((A :SPECIAL NIL)
             (B :CONSTANT NIL)
             (C :LEXICAL T)
             (D :SPECIAL T)
             (E :SYMBOL-MACROLET T)
             (F NIL NIL))

      
#2:  This example illustrates the first two values returned by the function
     FUNCTION-INFORMATION.

  (DEFMACRO KIND-OF-FUNCTION (FUNCTION-NAME &ENVIRONMENT ENV)
    (MULTIPLE-VALUE-BIND (KIND BINDINGP)
                         (FUNCTION-INFORMATION FUNCTION-NAME ENV)
      `(LIST ',FUNCTION-NAME ',KIND ',BINDING)))

  (DEFUN A ())

  (DEFUN (SETF A) (V))

  (DEFMACRO B ())

  (DEFUN TEST ()
    (FLET ((C ()))
      (MACROLET ((D ()))
        (LIST (KIND-OF-FUNCTION A)
              (KIND-OF-FUNCTION B)
              (KIND-OF-FUNCTION QUOTE)
              (KIND-OF-FUNCTION (SETF A))
              (KIND-OF-FUNCTION C)
              (KIND-OF-FUNCTION D)
              (KIND-OF-FUNCTION E)))))

  (TEST) -> ((A :FUNCTION NIL)
             (B :MACRO NIL)
             (QUOTE :SPECIAL-FORM NIL)
             ((SETF A) :FUNCTION NIL)
             (C :FUNCTION T)
             (D :MACRO T)
             (E NIL NIL))


#3: This example shows how a code-walker might walk a MACROLET special form.
    It assumes that the revised MACROLET semantics described in proposal
    DEFINING-MACROS-NON-TOP-LEVEL:ALLOW are in effect. 

  (DEFUN WALK-MACROLET (FORM ENV)
    (LET ((MACROS  (MAKE-MACRO-DEFINITIONS (CADR FORM) ENV)))
      (MULTIPLE-VALUE-BIND (BODY DECLS) (PARSE-BODY (CDDR FORM))
        (WALK-IMPLICIT-PROGN
          BODY
          (AUGMENT-ENVIRONMENT ENV :MACRO MACROS :DECLARE DECLS)))))

  (DEFUN MAKE-MACRO-DEFINITIONS (DEFS ENV)
    (MAPCAR #'(LAMBDA (DEF)
                (LET ((NAME (CAR DEF)))
                  (LIST NAME
                        (ENCLOSE (PARSE-MACRO NAME (CADR DEF) (CDDR DEF) ENV)
                                 ENV))))
            DEFS))


Cost to Implementors:

 Most implementations already record some of this information in some form.
 Providing these functions should not be too difficult, but it is a more than
 trivial amount of work.

Cost to Users:

 This change is upward compatible with user code.

Current practice:

 No implementation provides all of this interface currently.  Portable Common
 Loops defines a subset of this functionality for its code walker and
 implements it on a number of diffent versions of Common Lisp.

Discussion:

 The first version of this proposal expressly did not deal with the objects
 which are used as environments by EVALHOOK.  This version is extended to
 support them in the belief that such environments share a lot of functionality
 with the syntactic environments needed by a compiler.  While the two types of
 environments might have very different implementations, there are many
 operations which are reasonable to perform on either type, including all of
 the accessor functions described by this proposal.

 There has been discussion about a macro called WITH-AUGMENTED-ENVIRONMENT,
 either in addition to or instead of AUGMENT-ENVIRONMENT.  The point of this
 would be to say that the extent of the augmented environment is the dynamic
 extent of the WITH-AUGMENTED-ENVIRONMENT form.  There was some concern that
 there might be cases where the macro was awkward to use.  Such a macro is not
 included in this proposal.  If AUGMENT-ENVIRONMENT is provided, then such a
 macro is trivially written in terms of the function.  There are places in the
 processing of sequential binding forms where using such a macro might be more
 difficult than using the specified function.

 Some people have indicated they think that the :MACRO argument (and the
 :SYMBOL-MACRO argument too?) to AUGMENT-ENVIRONMENT should be an a-list of the
 form ((name . definition)...) rather than the form ((name definition)...).

 Some people have indicated they think that implementations must never discard
 any declarations, even if they are not otherwise used by the interpreter or
 compiler.  Proposal SMALL is consistent with what CLtL says (implementations
 are free to ignore all declarations except SPECIAL declarations), but the
 DECLARATION-INFORMATION function might not be particularly useful unless it is
 guaranteed to do something.  Requiring implementations to keep track of
 declarations they'd otherwise ignore would involve some implementation cost
 and also might incur a performance penalty.

 ENCLOSE happens to subsume the extension to COERCE for converting a lambda
 expression into a function (see Issue FUNCTION-TYPE, passed in June 1988).
 Perhaps the extension to COERCE should be backed out?

∂13-Jun-89  1621	CL-Compiler-mailer 	Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (version 9)    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Jun 89  16:21:12 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA02220; Tue, 13 Jun 89 17:21:33 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA22758; Tue, 13 Jun 89 17:21:31 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906132321.AA22758@defun.utah.edu>
Date: Tue, 13 Jun 89 17:21:30 MDT
Subject: Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (version 9)
To: Kim Barrett <IIM@ECLA.USC.EDU>
Cc: CL-Compiler@sail.stanford.edu, Moon@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: Kim Barrett <IIM@ECLA.USC.EDU>, Tue, 13 Jun 89 18:22 EDT

On the whole, I like the direction this is heading.  The addition of
DEFDECLARE fixes my main problem with the version we had at the last
meeting, namely that we weren't providing any way for users to attach
miscellaneous bits of information to the contours that were added to
the environment.  One important point I would like to see clarified:
does DEFDECLARE extend the syntax of declarations recognized in
DECLARE by the normal evaluator or compiler, or is it useful only with
AUGMENT-ENVIRONMENT?  What's the relationship between DEFDECLARE and
(proclaim '(declaration ....)) -- do you need to do both?  And, since
nothing is said to the contrary, I assume this macro doesn't do any
special compiletime magic, but that probably should be stated
explicitly. 

-Sandra
-------

∂13-Jun-89  1650	CL-Compiler-mailer 	administrivia  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Jun 89  16:50:53 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA02498; Tue, 13 Jun 89 17:51:16 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA22794; Tue, 13 Jun 89 17:51:14 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906132351.AA22794@defun.utah.edu>
Date: Tue, 13 Jun 89 17:51:13 MDT
Subject: administrivia
To: cl-compiler@sail.stanford.edu

Now that we have a revised SYNTACTIC-ENVIRONMENT-ACCESS proposal, it
looks like we are in pretty good shape for the upcoming meeting.
There are no new issues this time, just leftovers from the last
meeting.  A few of them still require some minor edits to incorporate
changes we've already agreed on, but I hope to get to them in the next
day or two.  I'd like to get mailings out this week if possible, since
I suspect a number of people will be away at SIGPLAN next week.

Does anybody think we need to arrange for a subcommittee meeting?  I
haven't seen the agenda yet so I don't have any idea when we'll be on,
or when other subcommittees are meeting. 

-Sandra
-------

∂16-Jun-89  0624	CL-Compiler-mailer 	SYNTACTIC-ENVIRONMENT-ACCESS  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Jun 89  06:23:55 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA08373; Fri, 16 Jun 89 07:24:13 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA24503; Fri, 16 Jun 89 07:24:11 -0600
Resent-From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Resent-Message-Id: <8906161324.AA24503@defun.utah.edu>
Received: from cs.utah.edu by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA24164; Thu, 15 Jun 89 16:27:57 -0600
Received: from vaxa.isi.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA25526; Thu, 15 Jun 89 16:27:49 -0600
Posted-Date: Thu, 15 Jun 89 14:26:25 PST
Message-Id: <8906152226.AA16401@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.61/5.61)
	id AA16401; Thu, 15 Jun 89 15:26:28 -0700
To: Moon@stony-brook.scrc.symbolics.com, sandra%defun@cs.utah.edu
From: goldman@vaxa.isi.edu
Subject: SYNTACTIC-ENVIRONMENT-ACCESS
Cc: goldman@vaxa.isi.edu
Date: Thu, 15 Jun 89 14:26:25 PST
Sender: goldman@vaxa.isi.edu
Resent-To: cl-compiler@sail.stanford.edu
Resent-Date: Fri, 16 Jun 89 07:24:09 MDT

Someone who knew that I have been working on a portable common-lisp code walker
forwarded me a copy of this draft proposal (version 9, 6/13/89).
I don't know what the standard mechanism is for commenting on these things -- I thought 
sending my comments to you would be a good start, since your names are prominent
in the list of authors of this proposal.  I trust you will forward them to the correct
collection of people.  Thanks in advance.

neil goldman

P.S. -- It sure would have been nice for me to have had this interface in place when I 
was building my code walker.  It really simplifies many things nicely.
----------------------------------------------------------------

I believe that the specification of VARIABLE-INFORMATION is inadequate to deal with the
interaction OF SPECIAL variable bindings, which have dynamic scope, and LEXICAL
variable/symbol-macro bindings which may occur within the lexical scope of the
form that introduces the special binding.

Consider the following program fragments:
(proclaim '(special OVERUSED-NAME))

(defun THE-NEXT ()
	;expects to be called with a dynamic special binding for OVERUSED-NAME
   (1+ OVERUSED-NAME))

Now, suppose I want to perform a code walk over my program to look for
calls on THE-NEXT that do not appear to be within a dynamic environment
that will provide a special binding for OVERUSED-NAME.  Consider what happens
when I process the following function:

(defun f ()
  (let ((OVERUSED-NAME 0))
    ...
    (symbol-macrolet ((OVERUSED-NAME 'foo))
	  (THE-NEXT))))

At the point where THE-NEXT is called, 
 VARIABLE-INFORMATION(OVERUSED-NAME, env) --> :SYMBOL-MACRO, T
i.e., I will see nothing about the special variable binding of OVERUSED-NAME, a piece
of information that this particular code walking application needs.
(obviously my code walker could have recorded that in its own private
data structure when it processed the LET, but that shouldn't be necessary).
I would therefore incorrectly conclude that this call on THE-NEXT had to rely on
a special binding of OVERUSED-NAME provided by a caller of f, when in fact f provides
the needed binding.

Since VARIABLE-INFORMATION purports to give information about special bindings, I think
it should be usable to find out about special bindings in the local environment,
even where lexical access to the binding has been shadowed by a local lexical binding
or a symbol-macrolet binding.  One way to do this would be to have VARIABLE-INFORMATION
return a fourth value of T if there is a local special binding in the environment, regardless
of whether it is shadowed by a lexical variable/symbol-macro binding.
----------------------------------------------------------------
I can imagine code walk applications where it would be desirable to have functions like
VARIABLE-INFORMATION and FUNCTION-INFORMATION,  which did
not require a name argument, but instead returned the set of names for which the environment
contains a local declaration.  (or more likely a function to map over that set of names, 
rather than return it). Was that kind of access explicitly rejected, or not considered?
----------------------------------------------------------------
Another capability that code walkers should have, but is not part of common lisp as far
as I know, is the ability to expand type expressions that use types defined with 
DEFTYPE.  Is that part of any proposal?
----------------------------------------------------------------
Incidentally, I also noticed a minor typo in example#1

(TEST] -> (...
           (E :SYMBOL-MACROLET T)
           ...)

should read
(TEST] -> (...
           (E :SYMBOL-MACRO T)
           ...)


∂16-Jun-89  0712	CL-Compiler-mailer 	Re: SYNTACTIC-ENVIRONMENT-ACCESS   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Jun 89  07:12:28 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA09292; Fri, 16 Jun 89 08:12:48 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA24525; Fri, 16 Jun 89 08:12:46 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906161412.AA24525@defun.utah.edu>
Date: Fri, 16 Jun 89 08:12:44 MDT
Subject: Re: SYNTACTIC-ENVIRONMENT-ACCESS
To: goldman@vaxa.isi.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: goldman@vaxa.isi.edu, Thu, 15 Jun 89 14:26:25 PST

> From: goldman@vaxa.isi.edu
> Date: Thu, 15 Jun 89 14:26:25 PST

> Now, suppose I want to perform a code walk over my program to look for
> calls on THE-NEXT that do not appear to be within a dynamic environment
> that will provide a special binding for OVERUSED-NAME.  Consider what happens
> when I process the following function:
> 
> (defun f ()
>   (let ((OVERUSED-NAME 0))
>     ...
>     (symbol-macrolet ((OVERUSED-NAME 'foo))
>	  (THE-NEXT))))

I don't think this is an insoluble problem under the current proposal.
The key is recognizing that any calls to THE-NEXT in the body of the
LET that binds OVERUSED-NAME will see that it has a special binding.
In other words, if this is all your code walker is doing, it doesn't
even have to look at the body forms once it sees a special binding for
OVERUSED-NAME.

> Since VARIABLE-INFORMATION purports to give information about special
> bindings, I think it should be usable to find out about special
> bindings in the local environment, even where lexical access to the
> binding has been shadowed by a local lexical binding or a
> symbol-macrolet binding.

That isn't really what VARIABLE-INFORMATION purports to do.  Its purpose 
is to tell you, given a symbol appearing in a given lexical environment,
whether that symbol is interpreted as the name of a lexical variable, a
special variable, or a symbol macro, and to supply some information about
its *lexically* apparent binding in that environment.

> I can imagine code walk applications where it would be desirable to
> have functions like VARIABLE-INFORMATION and FUNCTION-INFORMATION,
> which did not require a name argument, but instead returned the set of
> names for which the environment contains a local declaration.  (or
> more likely a function to map over that set of names, rather than
> return it).  Was that kind of access explicitly rejected, or not
> considered? 

I know I've considered such an alternative, but it's never made it
into a proposal.  I don't see it as being as essential as the other
functionality that's being proposed here. 

> Another capability that code walkers should have, but is not part of
> common lisp as far as I know, is the ability to expand type
> expressions that use types defined with DEFTYPE.  Is that part of any
> proposal?

No, although again it's something we've talked about from time to
time.  It's really a separate issue.

-Sandra
-------

∂16-Jun-89  1008	CL-Compiler-mailer 	issue COMPILE-FILE-SYMBOL-HANDLING, version 4
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 16 Jun 89  10:08:23 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 16 Jun 89 01:21:04 EDT
Date: Fri, 16 Jun 89 01:19 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: issue COMPILE-FILE-SYMBOL-HANDLING, version 4
To: cl-compiler@sail.stanford.edu
In-Reply-To: <8906151613.AA23870@defun.utah.edu>
Message-Id: <19890616051934.1.BARMAR@OCCAM.THINK.COM>

    Date: Thu, 15 Jun 89 10:13:56 -0600
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

	  (b) If the first top-level form in the file is not a call to
	      IN-PACKAGE, then the value of *PACKAGE* at the time LOAD is
	      called must be a package with the same name as the package that
	      was the value of *PACKAGE* at the time COMPILE-FILE was called.

Minor nit-pick: this should probably refer to the first top-level form
which contains any symbols.  I've seen some vendors begin their files
with a top-level character string (a copyright notice, presumably to
cause a copyright notice to be put into the binary).

Also, what happens if the symbol LISP:IN-PACKAGE isn't accessible in the
loadtime *PACKAGE*?  The above seems to imply that when the first form
is an IN-PACKAGE, it doesn't matter whether the initial compiletime and
loadtime values of *PACKAGE* are the same.

                                                barmar

∂16-Jun-89  1544	CL-Compiler-mailer 	issue COMPILE-FILE-SYMBOL-HANDLING, version 4
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 Jun 89  15:43:58 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612334; 16 Jun 89 18:45:44 EDT
Date: Fri, 16 Jun 89 18:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-FILE-SYMBOL-HANDLING, version 4
To: cl-compiler@sail.stanford.edu
In-Reply-To: <8906151613.AA23870@defun.utah.edu>
Message-ID: <19890616224609.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

This is okay.

∂16-Jun-89  1552	CL-Compiler-mailer 	issue MACRO-CACHING, version 3
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 Jun 89  15:51:54 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612317; 16 Jun 89 18:23:48 EDT
Date: Fri, 16 Jun 89 18:24 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue MACRO-CACHING, version 3
To: cl-compiler@sail.stanford.edu
In-Reply-To: <8906151621.AA23878@defun.utah.edu>
Message-ID: <19890616222420.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

This is okay.

∂16-Jun-89  1552	CL-Compiler-mailer 	issue CLOS-MACRO-COMPILATION, version 4 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 Jun 89  15:52:22 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 612325; 16 Jun 89 18:29:17 EDT
Date: Fri, 16 Jun 89 18:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CLOS-MACRO-COMPILATION, version 4
To: cl-compiler@sail.stanford.edu
In-Reply-To: <8906151524.AA23848@defun.utah.edu>
Message-ID: <19890616222947.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

This is okay.

∂16-Jun-89  1552	CL-Compiler-mailer 	issue COMPILED-FUNCTION-REQUIREMENTS, version 6   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 Jun 89  15:51:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612311; 16 Jun 89 18:19:06 EDT
Date: Fri, 16 Jun 89 18:19 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILED-FUNCTION-REQUIREMENTS, version 6
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@sail.stanford.edu, Moon@STONY-BROOK.SCRC.Symbolics.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM,
    RPG@Lucid.COM
In-Reply-To: <8906151618.AA23875@defun.utah.edu>
Message-ID: <19890616221919.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

[X3J13 removed]

This proposal remains unacceptable, in my opinion.  Much of the
problem is that it's too vague.

Specific problems:

Under point 1, these bullets have nothing to do with COMPILED-FUNCTION.
ANSI CL requires all language processors to follow these rules, including
both compiler and interpreter.  Hence these bullets should be removed
from this proposal:

    - The compiler must capture declarations to determine whether
      variable bindings and references appearing lexically within 
      the function are to be treated as lexical or special.

    - Lexically nested EVAL-WHENs have been processed as stated in
      proposal EVAL-WHEN-NON-TOP-LEVEL; either the body is treated as
      an implicit PROGN or as the constant NIL.

If my notes are correct, I made this same comment before about three
bullets, and you removed one of them, but not the other two.  You
probably removed the COMPILER-LET bullet for a different reason.
I don't understand why you left these other two bullets here.

Point 3 says:

(3) Clarify when functions are defined in a file which is compiled
    with COMPILE-FILE, and the compiled file is subsequently LOADed,
    objects of type COMPILED-FUNCTION result.

I don't know what "functions defined in a file produced by COMPILE-FILE"
means; is this top-level definitions, all definitions produced at load
time, all definitions produced at run time, or something else?  Does
this include only named functions (the usual meaning of "defined"), or
does it also include anonymous LAMBDA-expressions?  This cannot be
accepted into the standard without being made specific.  One possible
answer would be "functions defined by the following forms processed as
top-level forms: ...", which would be acceptable because it uses defined
terminology ("processed" and "top-level" have been defined elsewhere),
provided the meaning of "defined" is clear from the definition of each
of the forms named.  However, that may not say what you meant.  I don't
know what you meant.

The proposal fails to clarify whether the following current practice of
Symbolics and TI is valid or invalid: a closure of a function in compiled
code is of type COMPILED-FUNCTION if there are no free lexical references
in the function, but otherwise is of type SYS:LEXICAL-CLOSURE, which is
not a subtype of COMPILED-FUNCTION.  I see no point in having a type
named COMPILED-FUNCTION at all if we can't even clarify this.

It seems to me that the above two paragraphs, combined with point 4 of
the proposal, mean that with your proposal the language contains
absolutely no way to create an object guaranteed to be of type
COMPILED-FUNCTION and contains no specification of how objects of type
COMPILED-FUNCTION differ from other objects of type FUNCTION, other than
that objects of type COMPILED-FUNCTION never contain unexpanded macros
or unresolved LOAD-TIME-VALUEs.  I think that we should either remove
the type COMPILED-FUNCTION from the language or say what it is and
provide a way to make one.  I'd rather remove it, because the problems
in defining it seem to outweigh the advantages of having it, however
the straw poll at the last meeting voted down the idea of removing it,
and that proposal has been removed from this version of the issue
writeup.

It seems to me that in this proposal you are trying to accomplish all of
the following:

1. Specify that the COMPILE-FILE function expands all invocations of
macros and symbol-macros appearing in <some unspecified places>.
This would be fine with me if you would only write an unambiguous
specification of the places.

2. Specify that LOAD-TIME-VALUE forms appearing in <some unspecified
places> are evaluated at load time, and not later, when LOAD is used on
the result of COMPILE-FILE.  The already accepted LOAD-TIME-EVAL
proposal already covers this.  It says (in both versions) "If a
LOAD-TIME-VALUE expression is seen by COMPILE-FILE"; this is less
vague than in the COMPILED-FUNCTION-REQUIREMENTS proposal, so I
see no advantage in addressing the issue again here.  I wish the
term "seen" was defined somewhere, I've already thought of several
different things that it could have meant.

3. Specify that objects of type COMPILED-FUNCTION never contain
macro or symbol-macro invocations, nor unresolved LOAD-TIME-VALUE
forms.  This is fine with me provided the type COMPILED-FUNCTION
is well-specified.  Or if the type COMPILED-FUNCTION is removed,
it won't be necessary to worry about this point.

4. Specify that there is no relationship between the type
COMPILED-FUNCTION and the function COMPILE.  This seems like a step
backwards to me.

5. Update the proposal COMPILE-ARGUMENT-PROBLEMS:CLARIFY to use the
current error terminology, without otherwise changing it.  I have no
objection to this.

I hope you find these comments constructive.

∂16-Jun-89  1554	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY, version 6  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 Jun 89  15:54:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612340; 16 Jun 89 18:56:02 EDT
Date: Fri, 16 Jun 89 18:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 6
To: cl-compiler@sail.stanford.edu, Common-Lisp-Object-System@sail.stanford.edu
In-Reply-To: <8906151608.AA23867@defun.utah.edu>
Message-ID: <19890616225632.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

This is okay (either proposal).

I believe there is no harm in requiring conforming programs to obey the
DEFCLASS restriction for now, so I don't see the advantage to
BOBS-AMENDMENT, even though in the future metaclasses might change this.

∂17-Jun-89  0906	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 6    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Jun 89  09:06:33 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA04583; Sat, 17 Jun 89 10:06:57 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA25303; Sat, 17 Jun 89 10:06:55 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906171606.AA25303@defun.utah.edu>
Date: Sat, 17 Jun 89 10:06:54 MDT
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 6
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Fri, 16 Jun 89 18:19 EDT

> Date: Fri, 16 Jun 89 18:19 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
> If my notes are correct, I made this same comment before about three
> bullets, and you removed one of them, but not the other two.  You
> probably removed the COMPILER-LET bullet for a different reason.
> I don't understand why you left these other two bullets here.

Mostly because I didn't remember your previous message when I prepared
this revision.  :-(  The paragraph about COMPILER-LET went away since
we voted to remove it from the language at the last meeting. 

> I don't know what "functions defined in a file produced by COMPILE-FILE"
> means; is this top-level definitions, all definitions produced at load
> time, all definitions produced at run time, or something else?

My intention was that this would include all function definitions,
both named and anonymous, appearing lexically within the file (but not
quoted constants that might be evaluated with EVAL at runtime to
produce a function).

> The proposal fails to clarify whether the following current practice of
> Symbolics and TI is valid or invalid: a closure of a function in compiled
> code is of type COMPILED-FUNCTION if there are no free lexical references
> in the function, but otherwise is of type SYS:LEXICAL-CLOSURE, which is
> not a subtype of COMPILED-FUNCTION.

The proposal implies that would be invalid, but doesn't address the
question explicitly because I don't recollect that anybody has ever
said it should. 

> I think that we should either remove
> the type COMPILED-FUNCTION from the language or say what it is and
> provide a way to make one.

I am in total greement with you on this.  The original intent of this
issue was actually to decide between these two alternatives, but it
seemed like neither of them were acceptable to the larger group.  Some
people have objected strongly to the idea of requiring COMPILE to make
a COMPILED-FUNCTION, and as you noted the straw vote at the last
meeting showed a substantial majority of people were opposed to
getting rid of COMPILED-FUNCTION entirely.  Hence the current proposal
which is an attempt to compromise between the two, and perhaps ends up
being too weak to be of any use. 

If we can't reach consensus in the compiler subcommitee about what
COMPILED-FUNCTION means, I think we ought to try to have it removed.
In spite of the straw vote at the last meeting, I think such a proposal
would have a reasonable chance of passing if we presented it as now
having the support of the compiler subcommittee as a whole.

Let's hear from some of the rest of you on this.  Things have been
very quiet on this issue and I can't read minds to know what you all
think about it.

-Sandra
-------

∂17-Jun-89  0908	CL-Compiler-mailer 	SYNTACTIC-ENVIRONMENT-ACCESS  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Jun 89  09:08:11 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA04648; Sat, 17 Jun 89 10:08:35 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA25315; Sat, 17 Jun 89 10:08:32 -0600
Resent-From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Resent-Message-Id: <8906171608.AA25315@defun.utah.edu>
Received: from cs.utah.edu by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA24917; Fri, 16 Jun 89 19:36:32 -0600
Received: from vaxa.isi.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA23775; Fri, 16 Jun 89 19:35:58 -0600
Posted-Date: Fri, 16 Jun 89 17:35:05 PST
Message-Id: <8906170135.AA04721@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.61/5.61)
	id AA04721; Fri, 16 Jun 89 18:35:10 -0700
To: sandra%defun@cs.utah.edu, Moon@stony-brook.scrc.symbolics.com
From: goldman@vaxa.isi.edu
Subject: SYNTACTIC-ENVIRONMENT-ACCESS
Cc: goldman@vaxa.isi.edu
Date: Fri, 16 Jun 89 17:35:05 PST
Sender: goldman@vaxa.isi.edu
Resent-To: cl-compiler@sail.stanford.edu
Resent-Date: Sat, 17 Jun 89 10:08:31 MDT

Well, I obviously didn't sway either of you, but then, you didn't
convince me either, and I want to at least explain why by responding to
your points.

   Think about what your code walker is going to do when it processes
   LET; it is going to have to understand what bindings are made by the LET in order
   to call AUGMENT-ENVIRONMENT.  So the SYNTACTIC-ENVIRONMENT-ACCESS doesn't remove
   any requirement on your program to understand special forms.

My code walker has to understand ALL the constructs that go into building up
an environment  and call AUGMENT-ENVIRONMENT properly.  I don't expect to
have that burden lifted from me.   I am only complaining
that you provide a way to read back MOST of the information I put into the
environment, but this particular fact (that a special binding has been made),
although potentially relevant,  cannot be recovered throught the interface
provided in the proposal.  


    Suppose instead that your program was
    
	(defun f ()
	  (let ((OVERUSED-NAME 0))
	    ...
	    (g)))
	...
	(defun g ()
	  (THE-NEXT))

    This is just like the previous program as far as the special bindings go, but
    nothing in the lexical environment of g says it will always be called with a
    binding in effect.  For that you have to do control path analysis and determine
    what all the call sites of g are. From this I conclude that the analysis you
    are trying to do is not really a lexical analysis at all ...

No, the question cannot be answered ABSOLUTELY by a lexical analysis.
But there are many potential code walking applications that are not in
the nature of a PROOF but a (usually conservative) heuristic user aid --
in the example you cite, I would obviously perform the analysis
recursively looking for calls on g.  Ultimately, (assuming I am given
some set of interfaces to the software from which all calls arise) I
can, solely by lexical analysis, categorize all calls on THE-NEXT as
either guaranteed-safe, guaranteed-unsafe, or suspicious.  [Excluding,
of course undetectable calls due to EVAL and APPLY].  That is still useful.

----------------------------------------------------------------
> That isn't really what VARIABLE-INFORMATION purports to do.  Its purpose 
> is to tell you, given a symbol appearing in a given lexical environment,
> whether that symbol is interpreted as the name of a lexical variable, a
> special variable, or a symbol macro, and to supply some information about
> its *lexically* apparent binding in that environment.

My apologies -- I certainly have no business claiming that the function
purports to do more that the document says it does, which is just what
you say.  (I do think SYMBOLIC-FORM-INFORMATION would be a better name
for this particular functionality, though, since uses of a symbol as a
form where the symbol is treated as a symbol-macro do not have anything
to do with VARIABLEs.  Incidentally, what does this function return for
symbols in the KEYWORD package -- :CONSTANT, NIL, NIL?  If so, I think
that should be made explicit in your proposal)

However, as I stated above, I think that LIMITING the information returned
by VARIABLE-INFORMATION to telling me how the symbol would be interpreted
if it appeared in that environment as an evaluatable form means that
this function cannot, in general, tell me about the existence of SPECIAL
bindings for that symbol in the environment, since they may be shadowed.
Since I'm able to supply that information to AUGMENT-ENVIRONMENT, it is
going to be there, and I think I should have some way to recover it.
[It needn't be through VARIABLE-INFORMATION -- that just seemed a convenient
way.]
----------------------------------------------------------------

>  [Regarding an ability to map over names in a lexical environment]
>  I don't recall this being considered.  It seems like it might be useful to add
>  additional functions to do this.  Do you have a specific proposal?

Sure.
MAP-ENVIRONMENT[fn env key]
KEY must be one of the symbols :FUNCTION, :VARIABLE, or :DECLARATION.

when key is :FUNCTION,
 for every symbol S for which (FUNCTION-INFORMATION s ENV)
 would return the values X, true, Y, for any X and Y,
 FN is applied to the arguments S, X, and Y.

when key is :VARIABLE,
 for every symbol S for which (VARIABLE-INFORMATION s ENV)
 would return the values X, true, Y, for any X and Y,
 FN is applied to the arguments S, X, and Y.

when key is :DECLARATION,
 for every symbol S for which (VARIABLE-INFORMATION s ENV)
 would return a non-nil value L
 FN is applied to the arguments S and L. 

Results are unspecified if FN destructively modifies any list previously
returned from accessors of ENV or environment from which it was
constructed, or destructively modifes any list ever provided to 
augment-environment in constructing ENV.
----------------------------------------------------------------
Unrelated to the above, I also  propose augmenting the notion of
an ENVIRONMENT object to include  the notion of lexically visible
block names, including those explicitly provided by the
BLOCK special form, the many implicit NIL block names (DO, DOLIST, PROG ...),
LOOP named <block>, and the implict blocks for bodies of
DEFUN, DEFMACRO, and DEFMETHOD,  and for bodies of functions/macros 
introduced in FLET, LABELS, and MACROLET.

To accomplish this, I would give AUGMENT-ENVIRONMENT an additional keyword
argument
:BLOCK   a symbol which shall be visible as a local block name
         in the new environment

and a new function
BLOCK-INFORMATION block &optional env
  This function returns T if BLOCK is the name of a block in the
  lexical environment ENV.


[Of course, I would allow :BLOCK as an argument to MAP-ENVIRONMENT]

∂17-Jun-89  0939	CL-Compiler-mailer 	Re: SYNTACTIC-ENVIRONMENT-ACCESS   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Jun 89  09:39:17 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA05158; Sat, 17 Jun 89 10:39:36 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA25331; Sat, 17 Jun 89 10:39:34 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906171639.AA25331@defun.utah.edu>
Date: Sat, 17 Jun 89 10:39:33 MDT
Subject: Re: SYNTACTIC-ENVIRONMENT-ACCESS
To: goldman@vaxa.isi.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: goldman@vaxa.isi.edu, Fri, 16 Jun 89 17:35:05 PST

I think the first value returned for symbols in the KEYWORD package
should indeed be :constant.  CLtL (p 175) implies that keyword symbols
are treated like DEFCONSTANTs.

The very first version of this issue did contain accessors for both
BLOCK and TAGBODY labels, but this didn't make it in to version 2.  I
don't know why it was removed; I suspect because they are not really
essential in a macroexpansion environment.

I don't know about the rest of you cl-compiler people, but I'm a
little leery about making further changes or additions to the
functionality in the current proposal at this point.  We've had this
issue kicking around for a long time and I'm glad that it's finally
stabilized.  I'm afraid that by adding more things to it at the last
minute without having adequate time to consider them, we might just
screw things up.

I have no idea what the current schedule is like (the editorial
committee seems to be completely ignoring the last CUT-OFF-DATES we
saw from them), or whether we would be permitted to continue to work
on further extensions to this proposal past the upcoming meeting.  In
any case, I'd like to see any extensions we do add between now and the
meeting be voted on separately.

-Sandra
-------

∂17-Jun-89  1217	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 6    
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 17 Jun 89  12:17:19 PDT
Received: from fred.slisp.cs.cmu.edu by FRED.SLISP.CS.CMU.EDU id aa05300;
          17 Jun 89 15:16:53 EDT
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>, 
    cl-compiler@sail.stanford.edu
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 6 
In-reply-to: Your message of Sat, 17 Jun 89 10:06:54 -0600.
             <8906171606.AA25303@defun.utah.edu> 
Date: Sat, 17 Jun 89 15:16:20 EDT
From: Rob.MacLachlan@FRED.SLISP.CS.CMU.EDU


    I favor flushing COMPILED-FUNCTION because it seems to serve no useful
purpose, and is difficult to precisely define.  Of course, it doesn't do
much *harm* either, so I didn't speak up before.

  Rob

∂19-Jun-89  1016	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 6    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Jun 89  10:15:56 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 613063; 19 Jun 89 13:17:39 EDT
Date: Mon, 19 Jun 89 13:18 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 6
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@sail.stanford.edu
In-Reply-To: <8906171606.AA25303@defun.utah.edu>
Message-ID: <19890619171815.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sat, 17 Jun 89 10:06:54 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    > Date: Fri, 16 Jun 89 18:19 EDT
    > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    > I don't know what "functions defined in a file produced by COMPILE-FILE"
    > means; is this top-level definitions, all definitions produced at load
    > time, all definitions produced at run time, or something else?

    My intention was that this would include all function definitions,
    both named and anonymous, appearing lexically within the file (but not
    quoted constants that might be evaluated with EVAL at runtime to
    produce a function).

I can guess what exactly this means, but I'm not confident my guess would
come out the same as yours.  Can you include in the proposal a specific
list of forms that this applies to, if they are "processed" by COMPILE-FILE?
Of course it also applies to macros that expand into those forms.
Don't forget to include DEFMETHOD and the other CLOS "method-defining
forms" (88-002R p.1-22 middle of page).

I'm assuming this issue or one of the others contains a satisfactory
definition of the term "processed".  I haven't actually gone and found
that definition today.  I'm assuming that the term "processed" provides
a sufficient and specific distinction between "lexically within the
file" versus "evaluated with EVAL at runtime" (note that I find both of
those terms too vague when considered as a formal specification).  That
might be too large a leap of faith: We don't want there to be gray areas
where some strange construct like
  (eval-when (load) (defvar *foo* (if *bar* #'(lambda ...) ...)))
or
  (defvar *bar* `((foo 1)
                  (bar ,(load-time-eval #,(lambda ...)))))
or something even more bizarre that I haven't thought of is left up to
the implementation to "process" or not "process".  Note that CLtL tried
to duck this issue with the mealymouth language on page 66.  I believe
part of the charter of the compiler subcommittee is to address this issue
squarely and come up with a precise specification; in fact you've already
done 90% of that.

    > The proposal fails to clarify whether the following current practice of
    > Symbolics and TI is valid or invalid: a closure of a function in compiled
    > code is of type COMPILED-FUNCTION if there are no free lexical references
    > in the function, but otherwise is of type SYS:LEXICAL-CLOSURE, which is
    > not a subtype of COMPILED-FUNCTION.

    The proposal implies that would be invalid, but doesn't address the
    question explicitly because I don't recollect that anybody has ever
    said it should. 

I believe I have on several occasions, but perhaps the mail never got to
you.  I'd like to see this addressed explicitly in the proposal, rather
than left to implication (I couldn't discover that implication myself).
Note that I want to see this not so much because of the current
practice, as because this vagueness is part of why I can't figure out
what the type COMPILED-FUNCTION is supposed to mean.

    > I think that we should either remove
    > the type COMPILED-FUNCTION from the language or say what it is and
    > provide a way to make one.

    I am in total greement with you on this.  The original intent of this
    issue was actually to decide between these two alternatives, but it
    seemed like neither of them were acceptable to the larger group.  

Yes, I wonder whether that straw poll reflects accurately how people
would have voted if they had sat down and thought about it for a long time.

								      Some
    people have objected strongly to the idea of requiring COMPILE to make
    a COMPILED-FUNCTION, and as you noted the straw vote at the last
    meeting showed a substantial majority of people were opposed to
    getting rid of COMPILED-FUNCTION entirely.  Hence the current proposal
    which is an attempt to compromise between the two, and perhaps ends up
    being too weak to be of any use. 

    If we can't reach consensus in the compiler subcommitee about what
    COMPILED-FUNCTION means, I think we ought to try to have it removed.
    In spite of the straw vote at the last meeting, I think such a proposal
    would have a reasonable chance of passing if we presented it as now
    having the support of the compiler subcommittee as a whole.

Yes, I don't think we should regard straw polls as binding if we think we
know better.  The straw poll mechanism is just supposed to be a way to
give guidance to the subcommittees, not something that's binding.

    Let's hear from some of the rest of you on this.  Things have been
    very quiet on this issue and I can't read minds to know what you all
    think about it.

Hear hear!

∂19-Jun-89  1200	CL-Compiler-mailer 	issue COMPILED-FUNCTION-REQUIREMENTS, version 6   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Jun 89  12:00:45 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA21333g; Mon, 19 Jun 89 11:54:42 PDT
Received: by bhopal id AA00962g; Mon, 19 Jun 89 11:56:30 PDT
Date: Mon, 19 Jun 89 11:56:30 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8906191856.AA00962@bhopal>
To: sandra%defun@cs.utah.edu
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Sat, 17 Jun 89 10:06:54 MDT <8906171606.AA25303@defun.utah.edu>
Subject: issue COMPILED-FUNCTION-REQUIREMENTS, version 6

Lucid supports its own version of COMPILED-FUNCTION, and it has a small
amount of usage.  But I'm not aware of any need for it to be portable.
Thus not having it in the standard probably won't raise much hue and cry.

-- JonL --

∂19-Jun-89  1407	CL-Compiler-mailer 	Issue: COMPILER-DIAGNOSTICS   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Jun 89  14:07:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 613267; 19 Jun 89 16:58:42 EDT
Date: Mon, 19 Jun 89 16:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMPILER-DIAGNOSTICS
To: CL-Compiler@sail.stanford.edu
Message-ID: <19890619205913.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

Version 11 of COMPILER-DIAGNOSTICS passed in March, but I have a
question about interpretation of the writeup, and another clarifying
amendment may be in order.  This derives from a user question
originally.

The proposal says:

  (2) Clarify that ERROR and WARNING conditions may be signalled within 
      COMPILE or COMPILE-FILE ....
  
  (3) ....If all user error
      handlers decline, the default handler may handle the condition in an
      implementation-specific way; for example, it might turn errors into
      warnings....
  
  (4) Specify that COMPILE-FILE returns two values.  The first value
      is the truename of the output file, or NIL if the file could not be
      created.  The second value is T if the file was compiled without
      errors, or NIL if errors were signalled during compilation.
  
First, point 4 only mentions COMPILE-FILE, but point 2 mentions both
COMPILE and COMPILE-FILE.  The original user question was about how to
detect whether COMPILE (not COMPILE-FILE) was completely successful.
Is it intentional that point 4 does not mention COMPILE also?  Or was
omission of COMPILE a mistake that should be rectified by amendment?

Second, where point 4 says "if errors were signalled during compilation",
when this says "errors" does it mean "ERROR" or "(OR ERROR WARNING)"?  One
would normally expect "errors" to mean "ERRORs", but from the rationale
this particular case may have been intended to include warnings also.  The
part about turning errors into warnings muddies the water further, as one
could have to know which warnings were generated internally by signalling
errors, versus which warnings were generated by calling WARN directly.
Surely the user should not have to care about that implementation detail of
the compiler.

Third (or more of the second point), point 2 of the proposal mentions
conditions of types ERROR, WARNING, and STYLE-WARNING.  I think in
different circumstances, callers of COMPILE-FILE and COMPILE would like to
know about any of these.  A handy way to address this would be to amend the
proposal to say that the second value from COMPILE and COMPILE-FILE is one
of the four symbols NIL, STYLE-WARNING, WARNING, or ERROR, indicating the
most severe type of exception that occurred during the compilation.
Alternatively a numerical severity code could be used, but this is Lisp.

Opinions?

∂19-Jun-89  1434	CL-Compiler-mailer 	Re: Issue: COMPILER-DIAGNOSTICS    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Jun 89  14:34:40 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA21699; Mon, 19 Jun 89 15:35:01 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA26815; Mon, 19 Jun 89 15:34:57 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906192134.AA26815@defun.utah.edu>
Date: Mon, 19 Jun 89 15:34:55 MDT
Subject: Re: Issue: COMPILER-DIAGNOSTICS
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 19 Jun 89 16:59 EDT

If you have something specific to propose, I won't object to reopening
this issue.  At the moment I'm feeling too lazy to do anything on it
myself, though.
  
> First, point 4 only mentions COMPILE-FILE, but point 2 mentions both
> COMPILE and COMPILE-FILE.  The original user question was about how to
> detect whether COMPILE (not COMPILE-FILE) was completely successful.
> Is it intentional that point 4 does not mention COMPILE also?  Or was
> omission of COMPILE a mistake that should be rectified by amendment?

I don't remember the details of how we arrived at this any more.  The
value returned by COMPILE is already well-specified in CLtL but if you
want to have it return a second value to indicate the error status,
that would be OK with me.

> Second, where point 4 says "if errors were signalled during compilation",
> when this says "errors" does it mean "ERROR" or "(OR ERROR WARNING)"?  One
> would normally expect "errors" to mean "ERRORs", but from the rationale
> this particular case may have been intended to include warnings also.  The
> part about turning errors into warnings muddies the water further, as one
> could have to know which warnings were generated internally by signalling
> errors, versus which warnings were generated by calling WARN directly.

In my thinking about how to implement this, I was considering that
"errors signalled during compilation" would refer to all conditions of
type ERROR that were detected by the compiler's default error handler
but not handled by a user error handler when the condition was
resignalled.  So even if the error were turned into a warning by the
default handler, it would still count as an error for this purpose.
(If the compiler didn't establish a default error handler and user
handlers declined to handle an error condition, then you wouldn't
expect COMPILE-FILE to be able to return normally anyway.) I guess
this clarification never made it into the writeup, though, and maybe
other people had other interpretations.

> Third (or more of the second point), point 2 of the proposal mentions
> conditions of types ERROR, WARNING, and STYLE-WARNING.  I think in
> different circumstances, callers of COMPILE-FILE and COMPILE would like to
> know about any of these.  A handy way to address this would be to amend the
> proposal to say that the second value from COMPILE and COMPILE-FILE is one
> of the four symbols NIL, STYLE-WARNING, WARNING, or ERROR, indicating the
> most severe type of exception that occurred during the compilation.

Sounds OK to me.

-Sandra
-------

∂19-Jun-89  1458	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 6    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Jun 89  14:58:29 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA22057; Mon, 19 Jun 89 15:58:46 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA26830; Mon, 19 Jun 89 15:58:44 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906192158.AA26830@defun.utah.edu>
Date: Mon, 19 Jun 89 15:58:43 MDT
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 6
To: cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 19 Jun 89 13:18 EDT

Judging by what I've heard so far, I think it would be worthwhile to
restore proposal FLUSH.  What I want to know is, does anyone support
proposal TIGHTEN enough to want to fix the problems with it that have
been pointed out?  I don't want to waste time on it if everybody hates
it anyway. 

-Sandra
-------

∂19-Jun-89  2014	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 6    
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 19 Jun 89  20:14:05 PDT
Received: from GANG-GANG.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 307961; 19 Jun 89 22:42:44 EDT
Date: Mon, 19 Jun 89 22:42 EDT
From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 6
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu
cc: cl-compiler@sail.stanford.edu
In-Reply-To: <19890619171815.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890620024230.3.GSB@GANG-GANG.SCRC.Symbolics.COM>

Any objection I used to have to flushing COMPILED-FUNCTION is removed by
the tightened definition of FUNCTION provided by the FUNCTION-TYPE
proposal.

For the record, the COMPILED-FUNCTION type in Symbolics CLOE is the
union of two internal types, one for lexical closures and one for
compiled functions with no free lexical references.  They are invoked
identically.  Declaring that something is COMPILED-FUNCTION permits
optimization of FUNCALL and APPLY in both safe and non-safe code.  With
the more restrictive definition of the FUNCTION type, this becomes
exactly the FUNCTION type.

∂21-Jun-89  0932	CL-Compiler-mailer 	Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (version 9)    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 21 Jun 89  09:32:33 PDT
Received: by ti.com id AA06409; Wed, 21 Jun 89 11:33:23 CDT
Received: from Kelvin by tilde id AA15200; Wed, 21 Jun 89 11:27:06 CDT
Message-Id: <2823438387-2485795@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 21 Jun 89  11:26:27 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kim Barrett <IIM@ECLA.USC.EDU>
Cc: CL-COMPILER@sail.stanford.edu, sandra%defun@cs.utah.edu,
        Moon@STONY-BROOK.SCRC.Symbolics.COM
Subject: Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (version 9)
In-Reply-To: Msg of Tue, 13 Jun 89 19:01 EDT from Kim Barrett <IIM@ECLA.USC.EDU>

Generally, this looks good.

>   This function returns information about the interpretation of the function
>   name FUNCTION when it in a functional position within lexical environment
                         ↑
                         appears ?

>  DECLARATION-INFORMATION decl-name &optional env        [Function]
> 
>   This function returns a list of declaration-specifiers whose CAR is the
>   symbol DECL-NAME that are in force in the environment ENV, sorted so that the
>   most recent declaration is first on the list.  Only declarations that do not
>   apply to function or variable bindings (i.e., those that are "pervasive") can
>   be accessed with this function.
> 
>   It is required that this function recognize OPTIMIZE and DECLARATION as
>   DECL-NAMEs.  The values returned for these two cases are as follows:
> 
>     OPTIMIZE    a list whose entries are of the form (quality value), where
>                 "quality" is one of the optimization qualities defined by the
>                 standard (SPEED, SAFETY, COMPILATION-SPEED, SPACE, and DEBUG)
>                 or some implementation-specific optimization quality, and
>                 "value" is an integer in the range 0 to 3.  The returned list
>                 always contains an entry for each of the standard qualities and
>                 for each of the implementation-specific qualities. 
...
> 
>     DECLARATION a list of the declaration names which have been proclaimed as
>                 valid through the use of the DECLARATION proclamation.

There still seems to be a little bit of confusion here; if the OPTIMIZE
list includes all of the qualities and the DECLARATION list includes
all of the user declaration names, then the statement about sorting the
declaration specifiers with most recent first seems irrelevant since
there won't be more than one of each in force.  I would suggest
amending the first sentence of the description as follows:

  This function returns a list of declaration-specifiers whose CAR is the
  symbol DECL-NAME that are in force in the environment ENV.  The list
  might contain multiple entries for a given DECL-NAME, in which case
  the first one has precedence.

>  DEFDECLARE decl-name lambda-list &body body                            [Macro]
...
>   When the first value is :DECLARE, the second value is a cons whose CAR is a
>   property and whose CDR is the associated value.  The function
>   DECLARATION-INFORMATION, when applied to the property and the augmented
>   environment, will return the associated value.

To be consistent with the description of DECLARATION-INFORMATION, this
should say "... will return a list containing that cons." Or is it the
description of DECLARATION-INFORMATION that is wrong?

∂21-Jun-89  1157	CL-Compiler-mailer 	Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (version 9)    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Jun 89  11:57:24 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA26074; Wed, 21 Jun 89 12:57:42 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA01677; Wed, 21 Jun 89 12:57:37 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906211857.AA01677@defun.utah.edu>
Date: Wed, 21 Jun 89 12:57:35 MDT
Subject: Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (version 9)
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: Kim Barrett <IIM@ECLA.USC.EDU>, CL-COMPILER@sail.stanford.edu,
        sandra%defun@cs.utah.edu, Moon@STONY-BROOK.SCRC.Symbolics.COM

> Date: Wed, 21 Jun 89  11:26:27 CDT
> From: David N Gray <Gray@DSG.csc.ti.com>
> 
> >  DEFDECLARE decl-name lambda-list &body body                            [Macro]
> ...
> >   When the first value is :DECLARE, the second value is a cons whose CAR is a
> >   property and whose CDR is the associated value.  The function
> >   DECLARATION-INFORMATION, when applied to the property and the augmented
> >   environment, will return the associated value.
> 
> To be consistent with the description of DECLARATION-INFORMATION, this
> should say "... will return a list containing that cons." Or is it the
> description of DECLARATION-INFORMATION that is wrong?

Yes, you're right that there is some confusion here -- thanks for
pointing it out.  Our original concept of DECLARATION-INFORMATION was
that it would return lists of decl-specs, but somewhere between
version 6 and version 9 the specification about OPTIMIZE and
DECLARATION was added that implies it just returns some information
about the lexically visible "value" of that declaration instead, as
well as the language in the DEFDECLARE section that carries the same
implication.  I think that not updating the first sentence of the
description of DECLARATION-INFORMATION when these other changes were
made was probably an oversight.

I will endeavor to prepare a new version of this issue within the next
day or two that addresses all the known problems with the current version.  
Nobody has yet attempted to answer the question I brought up earlier
about the relationship between DEFDECLARE, (PROCLAIM '(DECLARATION...)), 
and processing of DECLARE forms by the compiler/interpreter, though.
The way I propose to resolve this is by saying that the expansion of
DEFDECLARE effectively includes a (PROCLAIM '(DECLARATION ...)), and
that the compiler and interpreter are permitted (but not required) to
make the information about the declaration available in macroexpand or
evalhook environments.  If any of you have a problem with this, let 
me know ASAP.

-Sandra

-------

∂21-Jun-89  1507	CL-Compiler-mailer 	Re: Issue: COMPILER-DIAGNOSTICS    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89  15:06:58 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 614583; 21 Jun 89 14:44:27 EDT
Date: Wed, 21 Jun 89 14:44 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: COMPILER-DIAGNOSTICS
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: CL-Compiler@sail.stanford.edu, Moon@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8906192134.AA26815@defun.utah.edu>
Message-ID: <19890621184458.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 19 Jun 89 15:34:55 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    If you have something specific to propose, I won't object to reopening
    this issue.  At the moment I'm feeling too lazy to do anything on it
    myself, though.
  
Okay, a proposed modified writeup is in this message.  I hope I started
from the correct version.  I'll let you decide whether you want to put
this on the agenda.

Forum:          Compiler
Issue:          COMPILER-DIAGNOSTICS
References:     CLtL p. 438-439, 62, 69, 160, 161
                Condition System, Revision #18
                S:>KMP>cl-conditions.text.34
                Issue GC-MESSAGES
                Issue RETURN-VALUES-UNSPECIFIED
                Issue COMPILER-VERBOSITY
                Issue CONDITION-RESTARTS
Category:       CLARIFICATION, ENHANCEMENT
Edit History:   V1, 15 Oct 1988, Sandra Loosemore
                V2, 19 Oct 1988, Sandra Loosemore (minor fixes)
                V3, 25 Oct 1988, Sandra Loosemore (input from Pitman & Gray)
                V4, 01 Nov 1988, Sandra Loosemore (fix typos)
                V5, 15 Dec 1988, Dan L. Pierson   (new condition types)
                V6, 15 Dec 1988, Sandra Loosemore (additions, fix wording)
                V7, 16 Dec 1988, Dan L. Pierson   (minor cleanup)
                V8, 07 Jan 1989, Sandra Loosemore (expand discussion)
                V9, 26 Jan 1989, Sandra Loosemore (simplify)
                V10, 22 Mar 1989, Sandra Loosemore (error terminology)
                V11, 11 Apr 1989, Kent Pitman (changes per X3J13)
                V12, 21-Jun-89, Moon (changes to point 4 only: return a
                        status value from COMPILE also, make the status
                        value provide more detail)
Status:         Passed V11
     
Problem Description:

It is unclear whether various diagnostics issued by the compiler are 
supposed to be true errors and warnings, or merely messages.

In some implementations, COMPILE-FILE handles even serious error
situations (such as syntax errors) by printing a message and then
trying to recover and continue compiling the rest of the file, rather
than by signalling an error.  While this user interface style is just
as acceptable as invoking the debugger, it means that a normal return
from COMPILE-FILE does not necessarily imply that the file was
successfully compiled.

Many compilers issue warnings about programming style issues (such as
binding a variable that is never used but not declared IGNORE).
Sometimes these messages obscure warnings about more serious problems,
and there should be some way to differentiate between the two.  For
example, it should be possible to suppress the style warnings.

Also, neither CLtL nor issue RETURN-VALUES-UNSPECIFIED states what the 
return value from COMPILE-FILE should be.


Proposal COMPILER-DIAGNOSTICS:USE-HANDLER:

(1) Introduce a new condition type, STYLE-WARNING, which is a subtype
    of WARNING.

(2) Clarify that ERROR and WARNING conditions may be signalled within 
    COMPILE or COMPILE-FILE, including arbitrary errors which may 
    occur due to compile-time processing of (EVAL-WHEN (COMPILE) ...) 
    forms or macro expansion.

    Considering only those conditions signalled -by- the compiler (as
    opposed to -within- the compiler),

    (a) Conditions of type ERROR may be signalled by the compiler in
        situations where the compilation cannot proceed without
        intervention.

        Examples:
            file open errors
            syntax errors

    (b) Conditions of type WARNING may be signalled by the compiler in 
        situations where the standard explicitly states that a warning must,
        should, or may be signalled; and where the compiler can determine 
        that a situation with undefined consequences or that would cause
        an error to be signalled would result at runtime.

        Examples:
            violation of type declarations
            SETQ'ing or rebinding a constant defined with DEFCONSTANT
            calls to built-in Lisp functions with wrong number of arguments
                or malformed keyword argument lists
            referencing a variable declared IGNORE
            unrecognized declaration specifiers

    (c) The compiler is permitted to signal diagnostics about matters of
        programming style as conditions of type STYLE-WARNING.  Although 
        STYLE-WARNINGs -may- be signalled in these situations, no 
        implementation is -required- to do so.  However, if an 
        implementation does choose to signal a condition, that condition 
        will be of type STYLE-WARNING and will be signalled by a call to 
        the function WARN.

        Examples:
            redefinition of function with different argument list
            calls to function with wrong number of arguments
            unreferenced local variables not declared IGNORE
            declaration specifiers described in CLtL but ignored by 
                the compiler

(3) State that both COMPILE and COMPILE-FILE are allowed to establish 
    a default condition handler.  If such a condition handler is 
    established, however, it must first resignal the condition to give any
    user-established handlers a chance to handle it.  If all user error
    handlers decline, the default handler may handle the condition in an
    implementation-specific way; for example, it might turn errors into
    warnings.

(4) Specify that COMPILE and COMPILE-FILE return two values.  The
    first value from COMPILE is the compiled function.  The first value
    from COMPILE-FILE is the truename of the output file, or NIL if the
    file could not be created.  The second value is one of the following
    symbols, to indicate the success or failure of the compilation:

        ERROR if a condition of type ERROR was detected by the compiler's
              default error handler but not handled by a user error handler
              when the condition was resignalled.  So even if the error
              were turned into a warning by the default handler, it would
              still count as an error for this purpose.
        WARNING if there was no error, and a warning was issued by the
              compiler in a situation where the standard explicitly states
              that a warning must, should, or may be signalled; or where
              the compiler can determine that a situation with undefined
              consequences or that would cause an error to be signalled
              would result at runtime.
        STYLE-WARNING if there was no error or warning, but there was a
              style warning as defined in point 2c.
        NIL if there were no errors, warnings, or style warnings.

Rationale:

Introducing the STYLE-WARNING condition allows handlers to distinguish
between potentially serious problems and mere kibitzing on the part of
the compiler.

Requiring any condition handlers established by the compiler to resignal
the condition before proceeding with any implementation-specific action
gives user error handlers a chance to override the compiler's default
behavior.  For example, the user error handler could invoke a restart
such as ABORT or MUFFLE-WARNING.

Requiring the compiler to handle the ABORT restart reflects what
several implementations already do (although probably not using this
mechanism).  The intent of the wording is to allow an implementation
to abort the entire compilation if it is not feasible to abort a
smaller part.

Requiring a second success-p value to be returned from COMPILE-FILE
gives the user some indication of whether there were serious problems
encountered in compiling the file.


Test Case/Example:

Here is an example of how COMPILE-FILE might set up its condition
handlers.  It establishes an ABORT restart to abort the compilation
and a handler to take implementation-specific action on ERROR
conditions.  Note that INTERNAL-COMPILE-FILE may set up additional
ABORT restarts.

    (defvar *output-file-truename* nil)

    (defun compile-file (input-file &key output-file)
      (let ((*output-file-truename*    nil)
            (errors-detected           nil))
        (with-simple-restart (abort "Abort compilation.")
          (handler-bind ((error  #'(lambda (condition)
                                     (setq errors-detected t)
                                     (signal condition)
                                     ...)))
            (internal-compile-file input-file output-file)))
        (values *output-file-truename*
                errors-detected)))



Current Practice:

No implementation behaves exactly as specified in this proposal.

In VaxLisp, COMPILE-FILE handles most compile-time errors without
invoking the debugger.  (It gives up on that top-level form and moves on
to the next one.)  Instead of signalling errors or warnings, it simply
prints them out as messages.

In Lucid Common Lisp, COMPILE-FILE invokes the debugger when it encounters
serious problems.  COMPILE-FILE returns the pathname for the output file.

Symbolics Genera usually tries to keep compiling when it encounters errors;
so does Symbolics Cloe.

On the TI Explorer, the compiler tries to catch most errors and turn
them into warnings (except for errors on opening a file), but the user
can change special variable COMPILER:WARN-ON-ERRORS to NIL if he wants
to enter the debugger on an error signalled during reading, macro
expansion, or compile-time evaluation.  The true name of the output
file is returned as the first value.  A second value indicates whether
any errors or warnings were reported.

IIM Common Lisp's compiler handles errors using a resignalling mechanism
similar to what is described here.


Cost to implementors:

The cost to implementors is not trivial but not particularly high.  This
proposal tries to allow implementations considerable freedom in what
kinds of conditions the compiler must detect and how they are handled,
while still allowing users some reasonably portable ways to deal with
compile-time errors.


Cost to users:

This is a compatible extension.  This proposal may cause users to see
some small differences in the user interface to the compiler, but
implementations already vary quite widely in their approaches.  Some
users will probably have to make some minor changes to their code.

Adding the STYLE-WARNING type may cause conflicts with programs
already using that name.


Benefits:

Users are given a way to detect and handle compilation errors, which
would simplify the implementation of portable code-maintenance
utilities.  The behavior of the compiler in error situations is made
more uniform across implementations.


Discussion:

The issue of whether the compiler may print normal progress messages
is discussed in detail in a separate issue, COMPILER-VERBOSITY.

Explicit calls to ERROR don't really justify warnings to be signalled
at compile-time, but we assume implementors have some common sense
about when it's appropriate to do so.

Proposal CONDITION-RESTARTS:PERMIT-ASSOCIATION would make it illegal
for conditions to be resignalled.  If that proposal is accepted, the
wording here would have to be changed to indicated that the compiler's
condition handler makes a copy of the condition and signals that.

Moon says:

  I think [requiring the ABORT restart to be handled] is wrong.  The only
  documentation of the ABORT restart that I could find says
  
    The purpose of the ABORT restart is generally to allow return to the
    innermost ``command level.''
  
  I agree with this, and I believe it means that it is wrong for any
  function other than one that establishes a read-eval-print loop or
  a command-level to establish an ABORT restart.  It would be useful
  to have some restart that aborts a portion of the compilation, but
  it should be given some other name.


∂21-Jun-89  1516	CL-Compiler-mailer 	issue CLOS-MACRO-COMPILATION, version 4 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89  15:16:28 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 614791; 21 Jun 89 18:18:04 EDT
Date: Wed, 21 Jun 89 18:18 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CLOS-MACRO-COMPILATION, version 4
To: sandra%defun@cs.utah.edu
cc: cl-compiler@sail.stanford.edu, Moon@STONY-BROOK.SCRC.Symbolics.COM, RPG@Lucid.COM
In-Reply-To: <8906151524.AA23848@defun.utah.edu>
Message-ID: <19890621221801.0.KMP@BOBOLINK.SCRC.Symbolics.COM>

This is very close, but I am a little nervous about the wording
in the following two places:

    Date: Thu, 15 Jun 89 09:24:59 -0600
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    ...
    Proposal CLOS-MACRO-COMPILATION:MINIMAL:

    ...
      DEFGENERIC:
  
      * The generic function can be referenced in subsequent DEFMETHOD forms.  
      * The generic function is not callable at compile-time.
  
Surely you don't mean that DEFGENERIC will arrange for the gf not to
be callable. You simply mean that it won't arrange for it to be callable.
You say later that wrapping (EVAL-WHEN (EVAL COMPILE LOAD) ...) around
this will cause it to become fully defined, yet a strict reading of the
second bullet item contradicts this.

      DEFMETHOD:
  
      * The method is not callable at compile-time.  If there is a generic
	function with the same name at compile-time, compiling a DEFMETHOD
	will not add the method to that generic function.  

	The error-signalling behavior described in the specification of
	DEFMETHOD in CLOS chapter 2 (if the function isn't a generic function
	or if the lambda-list is not congruent) happens only when the defining
	form is executed, not at compile time.

	The forms in EQL specializers are evaluated when the defining form
	is executed.  The implementation may try to evaluate them at
	compile time, but must not depend on being able to do so.

Because of the above confusion about what DEFGENERIC, I am unable to decide
which of two intents you have. Presumably you mean one of:

 - DEFMETHOD can, but is not required to, put methods on the generic function
   at compile time.

 - DEFMETHOD may not pollute the compile time environment by augmenting
   the generic function at that time.

In either case, you want the wording to be such that it's clear that 
in compile-time-too mode, this preclusion is not in force.

---
Actually, on an unrelated point, I guess I am also slightly nervous
about the vague phrasing "may try to evaluate" (e.g., in discussion of
EQL specializers).  I think this should be defined formally as something
like "use a special evaluator which is effectively side-effect free".
The problem I have is that (IGNORE-ERRORS (EVAL x)) might be taken as a
correct implementation of "attempt to evaluate" and I don't think it's
reasonable, for example, for that to be done on forms that affect the
global environment or that do non-local transfers of control (for
example).

∂21-Jun-89  1540	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY, version 6  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89  15:40:16 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 614822; 21 Jun 89 18:41:59 EDT
Date: Wed, 21 Jun 89 18:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 6
To: sandra%defun@cs.utah.edu
cc: CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: <8906151608.AA23867@defun.utah.edu>
Message-ID: <19890621224156.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

This looks mostly ok.

I currently have no strong opinion on the BOBS-AMENDMENT part.

I have one non-preemptive comment on the wording...

    Date: Thu, 15 Jun 89 10:08:11 -0600
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    ...
    Proposal COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY:

    The process of compilation causes certain kinds of information present
    in the compiletime environment to be captured and incorporated into
    the resulting compiled code.  Other kinds of information may not be
    captured until the compiled code is actually run.  

    Specifically:

    (1) The following information *must* be present in the compiletime
    environment for the program to be compiled correctly.  This
    information need not also be present in the runtime environment.

I would feel more confident if this sentence had added to it: "except in
situations where EVAL, COMPILE, or COMPILE-FILE is used to force new
semantic analysis at runtime."

∂21-Jun-89  1548	CL-Compiler-mailer 	Re: Issue: COMPILER-DIAGNOSTICS    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Jun 89  15:48:12 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA03637; Wed, 21 Jun 89 16:48:37 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA01862; Wed, 21 Jun 89 16:48:34 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906212248.AA01862@defun.utah.edu>
Date: Wed, 21 Jun 89 16:48:33 MDT
Subject: Re: Issue: COMPILER-DIAGNOSTICS
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 21 Jun 89 14:44 EDT

This looks OK to me, except for one thing....

> (4) Specify that COMPILE and COMPILE-FILE return two values.  The
>     first value from COMPILE is the compiled function.

Do you really mean this?  CLtL says that if the <name> argument to
COMPILE is non-NIL, then the symbol is returned instead of the
function.  Or has this been changed by some issue that I've forgotten
about?

-Sandra
-------

∂21-Jun-89  1553	CL-Compiler-mailer 	Re: Issue: COMPILER-DIAGNOSTICS    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89  15:52:47 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 614842; 21 Jun 89 18:54:36 EDT
Date: Wed, 21 Jun 89 18:55 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: COMPILER-DIAGNOSTICS
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: CL-Compiler@sail.stanford.edu
In-Reply-To: <8906212248.AA01862@defun.utah.edu>
Message-ID: <19890621225517.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 21 Jun 89 16:48:33 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    This looks OK to me, except for one thing....

    > (4) Specify that COMPILE and COMPILE-FILE return two values.  The
    >     first value from COMPILE is the compiled function.

    Do you really mean this?  CLtL says that if the <name> argument to
    COMPILE is non-NIL, then the symbol is returned instead of the
    function.  Or has this been changed by some issue that I've forgotten
    about?

I didn't really mean it.  I assumed that I knew what the first value
was specified to be and didn't check it.  Maybe just change that to
"The first value from COMPILE is not changed by this proposal."

∂21-Jun-89  1557	CL-Compiler-mailer 	Re: Issue: COMPILER-DIAGNOSTICS    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Jun 89  15:57:42 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA03915; Wed, 21 Jun 89 16:57:55 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA01902; Wed, 21 Jun 89 16:57:52 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906212257.AA01902@defun.utah.edu>
Date: Wed, 21 Jun 89 16:57:51 MDT
Subject: Re: Issue: COMPILER-DIAGNOSTICS
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
        CL-Compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 21 Jun 89 18:55 EDT

Right, that's what I thought you really wanted to say.  I'll make the
tweak before sending this out. 

-Sandra
-------

∂21-Jun-89  1644	Common-Lisp-Object-System-mailer 	Re: issue CLOS-MACRO-COMPILATION, version 4   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Jun 89  16:44:02 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA05056; Wed, 21 Jun 89 17:44:24 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA01963; Wed, 21 Jun 89 17:44:21 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906212344.AA01963@defun.utah.edu>
Date: Wed, 21 Jun 89 17:44:20 MDT
Subject: Re: issue CLOS-MACRO-COMPILATION, version 4
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@sail.stanford.edu, Moon@STONY-BROOK.SCRC.Symbolics.COM,
        RPG@Lucid.COM, common-lisp-object-system@sail.stanford.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 21 Jun 89 18:18 EDT

> Date: Wed, 21 Jun 89 18:18 EDT
> From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
> 
> Surely you don't mean that DEFGENERIC will arrange for the gf not to
> be callable. You simply mean that it won't arrange for it to be callable.

Yes, you're right.  

>  - DEFMETHOD may not pollute the compile time environment by augmenting
>    the generic function at that time.

The intent is that simply *compiling* a DEFMETHOD won't pollute the
compile time environment.  I agree this could perhaps be made more 
explicit.

> Actually, on an unrelated point, I guess I am also slightly nervous
> about the vague phrasing "may try to evaluate" (e.g., in discussion of
> EQL specializers).

This wording was taken from the amendment Gregor proposed at the last
meeting.  I have not presumed to try to interpret what it means.  I
personally think we would be better off deleting this particular
sentence from the proposal, and sticking with the simple statement
that EQL specializer forms are evaluated when the DEFMETHOD form is
executed.

-Sandra
-------

∂21-Jun-89  1752	CL-Compiler-mailer 	Re: issue CLOS-MACRO-COMPILATION, version 4  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89  17:52:48 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 614933; 21 Jun 89 20:54:07 EDT
Date: Wed, 21 Jun 89 20:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue CLOS-MACRO-COMPILATION, version 4
To: sandra%defun@cs.utah.edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, cl-compiler@sail.stanford.edu, Moon@STONY-BROOK.SCRC.Symbolics.COM,
    RPG@Lucid.COM, common-lisp-object-system@sail.stanford.edu
In-Reply-To: <8906212344.AA01963@defun.utah.edu>
Message-ID: <19890622005403.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Wed, 21 Jun 89 17:44:20 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    ...
    >  - DEFMETHOD may not pollute the compile time environment by augmenting
    >    the generic function at that time.

    The intent is that simply *compiling* a DEFMETHOD won't pollute the
    compile time environment.  I agree this could perhaps be made more 
    explicit.

I guess the problem was that because the previous thing (about DEFGENERIC)
had forced me to contort the meanings of some of the words, there was a
tendency for me to wonder if there were hidden meanings in some of the others.

    > Actually, on an unrelated point, I guess I am also slightly nervous
    > about the vague phrasing "may try to evaluate" (e.g., in discussion of
    > EQL specializers).

    This wording was taken from the amendment Gregor proposed at the last
    meeting.  I have not presumed to try to interpret what it means.  I
    personally think we would be better off deleting this particular
    sentence from the proposal, and sticking with the simple statement
    that EQL specializer forms are evaluated when the DEFMETHOD form is
    executed.

Well, removing the statement would probably be fine by me. I don't think
it really adds much semantic content since, after all, any function can
attempt to evaluate just about anything as long as the effects of doing
so are not visible.  Maybe all that's really being said is that ``the
compiler can build in knowledge about what the form in an EQL
specializer will evaluate to in cases where the ultimate result can be
syntactically inferred without actually evaluating it.''  I guess that's
an interesting piece of information, but I'd prefer a presentation like
this that emphasized -not- evaluating it rather than something that said
trying evaluation was ok when clearly in the general case it is not.

∂23-Jun-89  0959	CL-Compiler-mailer 	Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 10     
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 23 Jun 89  09:59:33 PDT
Received: from fred.slisp.cs.cmu.edu by FRED.SLISP.CS.CMU.EDU id aa00982;
          23 Jun 89 12:59:14 EDT
To: cl-compiler@sail.stanford.edu
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 10 
In-reply-to: Your message of Thu, 22 Jun 89 13:50:47 -0600.
             <8906221950.AA02831@defun.utah.edu> 
Date: Fri, 23 Jun 89 12:58:52 EDT
From: Rob.MacLachlan@FRED.SLISP.CS.CMU.EDU


   ENCLOSE lambda-expression &optional env                [Function]

    This function returns an object of type FUNCTION that is equivalent to what
    would be obtained by evaluating `(FUNCTION ,LAMBDA-EXPRESSION) in syntactic
    environment ENV.  The consequences are undefined if any of the local
    variable or function bindings (but not macro definitions) that are visible
    in the lexical environment represented by ENV are referenced within the
    LAMBDA-EXPRESSION.

This should be more explicit about what sort of things can be referenced by
the lambda expression.  I assume that this is intended to cover only the
purely compile-time aspects of environment, i.e. macros and declarations.
If so, it should be made clear that GO tags and BLOCK names in the
environment can't be used either.

  Rob

∂23-Jun-89  1455	CL-Compiler-mailer 	issue COMPILER-DIAGNOSTICS, version 13  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 Jun 89  14:55:32 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 616303; 23 Jun 89 17:55:57 EDT
Date: Fri, 23 Jun 89 17:55 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-DIAGNOSTICS, version 13
To: sandra%defun@cs.utah.edu
cc: cl-compiler@sail.stanford.edu
In-Reply-To: <8906222121.AA02875@defun.utah.edu>
Message-ID: <19890623215548.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

Apologies for the lateness of this feedback.  I will have this in my
notes at the meeting and we can make an on-the-spot amendment if you
don't have time to issue a new version, but just in case...

Version 13 has these bugs:

 - The Rationale refers to the ABORT restart being handled but that's
   been (correctly) flushed from the proposal part.  That part of
   the Rationale shoudl be removed.

 - If you flush the references to ABORT in the Rationale, you can flush
   moon's comment about his dislike for it.

 - I think permitting users to have first shot at handling errors
   in COMPILE-FILE is wrong.  Compilation should not be dependent on
   external state to succeed. The only handling that makes sense is
   the handling of warnings--which is not intrinsically related to the
   compilation's progress.  I would change item #3 to just:

     (3) State that both COMPILE and COMPILE-FILE are permitted (but not
	 required) to establish a handler for ERROR.  For example, they 
         might issue a warning, and restart compilation from some 
	 implementation-dependent point in order to let the compilation
	 proceed without manual intervention.

         Rationale: The exact nature of what happens when an error is
	 signalled during compilation is an environment issue and 
	 therefore beyond the scope of this spec.

∂23-Jun-89  1517	CL-Compiler-mailer 	Re: issue COMPILER-DIAGNOSTICS, version 13   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Jun 89  15:17:29 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA05147; Fri, 23 Jun 89 16:17:47 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA03862; Fri, 23 Jun 89 16:17:45 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906232217.AA03862@defun.utah.edu>
Date: Fri, 23 Jun 89 16:17:44 MDT
Subject: Re: issue COMPILER-DIAGNOSTICS, version 13
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Fri, 23 Jun 89 17:55 EDT

> Date: Fri, 23 Jun 89 17:55 EDT
> From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
> 
> Apologies for the lateness of this feedback.  I will have this in my
> notes at the meeting and we can make an on-the-spot amendment if you
> don't have time to issue a new version, but just in case...

I do not plan to send out any more new versions before the meeting.  I
think it's gotten to the stage where nobody will have time to read
them any more, anyway.  I'm in the process of preparing an agenda that
includes a list of issues annotated with some possible amendments we
might want to offer to clear up remaining problems, that I will
distribute in hardcopy along with the current versions of all the
proposals.  I'll try to get a copy e-mailed out to cl-compiler tonight
in case any of you have anything else to add to it.

I will add your suggestions on this issue to the summary, but I'm
personally a little hesitant about the change to item 3 because I
think it represents a major change in philosophy from the version we
approved at the last meeting.  It does remove the conflict with the
CONDITION-RESTARTS proposal, though.

-Sandra
-------

∂23-Jun-89  1522	CL-Compiler-mailer 	Re: issue COMPILER-DIAGNOSTICS, version 13   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 Jun 89  15:22:33 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 616323; 23 Jun 89 18:24:25 EDT
Date: Fri, 23 Jun 89 18:24 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue COMPILER-DIAGNOSTICS, version 13
To: sandra%defun@cs.utah.edu
cc: cl-compiler@sail.stanford.edu
In-Reply-To: <8906232217.AA03862@defun.utah.edu>
Message-ID: <19890623222420.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Fri, 23 Jun 89 16:17:44 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    ... I'm personally a little hesitant about the change to item 3 because I
    think it represents a major change in philosophy from the version we
    approved at the last meeting.  It does remove the conflict with the
    CONDITION-RESTARTS proposal, though. ...

Right, and that incompatibility is really non-trivial.
I think the change in philosophy is an important improvement, but I'm willing
to discuss it at the meeting to make sure everyone buys in.

∂23-Jun-89  1610	CL-Compiler-mailer 	cl-compiler agenda  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Jun 89  16:10:24 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA06044; Fri, 23 Jun 89 17:10:41 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA03893; Fri, 23 Jun 89 17:10:39 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906232310.AA03893@defun.utah.edu>
Date: Fri, 23 Jun 89 17:10:38 MDT
Subject: cl-compiler agenda
To: cl-compiler@sail.stanford.edu

OK, here's the agenda for our presentation.  Let me know if you have
anything to add to (or remove from) this.


CLOS-MACRO-COMPILATION, version 5
  Proposal MINIMAL


COMPILE-ENVIRONMENT-CONSISTENCY, version 6
  Proposal CLARIFY
  Proposal BOBS-AMENDMENT


COMPILE-FILE-SYMBOL-HANDLING, version 4
  Proposal NEW-REQUIRE-CONSISTENCY

  There are two potential amendments:

  * In item 1b, change "first top-level form" to "first top-level form
	that contains any symbols".

  * Clarify that if the first top-level form is a call to IN-PACKAGE, the 
	symbol CL:IN-PACKAGE must be accessible in the package that 
	is the value of *PACKAGE* when LOAD is called.


COMPILED-FUNCTION-REQUIREMENTS, version 7
  Proposal FLUSH
  Proposal TIGHTEN

  I do not believe that anybody on the compiler committee supports
  proposal TIGHTEN in its current form any more.


COMPILER-DIAGNOSTICS, version 13
  Proposal USE-HANDLER

  Version 11 of this proposal was passed at the March meeting.

  We should probably defer discussion of this issue until the cleanup
  issue CONDITION-RESTARTS has been decided, since there is a direct
  conflict between the two issues.

  The following amendment would remove the conflict:

    * Change item #3 to say:

         State that both COMPILE and COMPILE-FILE are permitted (but not
	 required) to establish a handler for ERROR.  For example, they 
         might issue a warning, and restart compilation from some 
	 implementation-dependent point in order to let the compilation
	 proceed without manual intervention.

         Rationale: The exact nature of what happens when an error is
	 signalled during compilation is an environment issue and 
	 therefore beyond the scope of this spec.

  Ignore the references to ABORT restarts in the rationale and
  discussion sections.  (We forgot to remove them when we removed the
  language dealing with ABORT restarts from the proposal itself at the
  last meeting.)


CONSTANT-FUNCTION-COMPILATION, version 1
  Proposal NO

  This proposal was tabled at the March meeting to allow people time to 
  prepare alternate proposals, but none have been submitted.


MACRO-CACHING, version 3
  Proposal DISALLOW
  Proposal DEPRECATE


PROCLAIM-ETC-IN-COMPILE-FILE, version 4
  Proposal NEW-MACRO 

  Proposals YES and NO were eliminated at the March meeting.

  Amendment:  Change the name DEFPROCLAIM to DECLAIM.


SYNTACTIC-ENVIRONMENT-ACCESS, version 10

  There is a one additional amendment which is a clarification:

  * Replace the last sentence of the description of the function ENCLOSE with:
	The LAMBDA-EXPRESSION is permitted to reference only the parts
	of the environment argument ENV that are relevant to syntactic
	processing, specifically declarations and definitions of 
        macros and symbol-macros.  The consequences are undefined if
	the LAMBDA-EXPRESSION contains any references to variable or
	function bindings that are lexically visible in ENV; any GO to
	a tag that is lexically visible in the environment ENV; or any
	RETURN-FORM a block name that is lexically visible in the
	environment ENV.

  If we have time, we may wish to consider adding some of the other
  extensions listed in the discussion section.
-------

∂04-Jul-89  0910	CL-Editorial-mailer 	issue COMPILED-FUNCTION-REQUIREMENTS   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 4 Jul 89  09:10:38 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA09900; Tue, 4 Jul 89 10:11:07 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA00545; Tue, 4 Jul 89 10:11:04 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8907041611.AA00545@defun.utah.edu>
Date: Tue, 4 Jul 89 10:11:03 MDT
Subject: issue COMPILED-FUNCTION-REQUIREMENTS
To: cl-editorial@sail.stanford.edu
Cc: cl-compiler@sail.stanford.edu

I just sent out the amended version of this issue from the last
meeting to X3J13.  However, looking over my notes, it seems like there
is still some confusion over the relationship between issues
COMPILE-ARGUMENT-PROBLEMS and COMPILED-FUNCTION-REQUIREMENTS.  I hope
we can agree to resolve this through the editorial process.

COMPILE-ARGUMENT-PROBLEMS says "it is an error" to pass COMPILE a
function defined in a non-null lexical environment.
COMPILED-FUNCTION-REQUIREMENTS says COMPILE "must" produce a
COMPILED-FUNCTION.  I believe that the only interpretation of this
that is consistent with translating "is an error" to "is undefined" is
that the restriction on what COMPILE produces only applies when it is
passed a valid function to compile.  In other words, we have not
lifted or modified the restriction on user programs that was imposed
in COMPILE-ARGUMENT-PROBLEMS.  This might not be what some people
intended when we voted, but I think it's what the proposals we
actually passed said.

-Sandra
-------

∂12-Jul-89  0008	CL-Compiler-mailer 	issue COMPILED-FUNCTION-REQUIREMENTS    
Received: from arisia.Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jul 89  00:08:12 PDT
Received: from masunter.parc.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA19862; Wed, 12 Jul 89 00:07:11 -0700
Received: by masunter.parc.xerox.com
	(5.61+/IDA-1.2.8/gandalf) id AA16577; Wed, 12 Jul 89 00:08:26 PDT
Message-Id: <8907120708.AA16577@masunter.parc.xerox.com>
Date: Wed, 12 Jul 89 00:08:26 PDT
From: <masinter@arisia.Xerox.COM>
To: sandra%defun@cs.utah.edu
Cc: cl-editorial@sail.stanford.edu, cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 4 Jul 89 10:11:03 MDT <8907041611.AA00545@defun.utah.edu>
Subject: issue COMPILED-FUNCTION-REQUIREMENTS

I intended to vote on a proposal that COMPILE must produce a COMPILED-FUNCTION,
and that it isn't an error to pass COMPILE a function defined in a non-null
lexical environment.

In fact, I believe this was explicitly discussed at the meeting. 

Maybe we have to re-clarify again at another meeting, but it seems like
a not to difficult burden to all valid common lisp implementations that
their function "COMPILE" actually work on all things that are called
FUNCTION (especially since there isn't a good way, given a function object,
to decide whether it might be "defined in a non-null lexical environment".)

That is, I think the language we passed for COMPILED-FUNCTION-REQUIREMENTS
supercedes the language in COMPILE-ARGUMENT-PROBLEMS.

Larry

∂12-Jul-89  1046	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 12 Jul 89  10:46:21 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA03735; Wed, 12 Jul 89 11:46:47 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA06085; Wed, 12 Jul 89 11:46:45 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8907121746.AA06085@defun.utah.edu>
Date: Wed, 12 Jul 89 11:46:43 MDT
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS
To: <masinter@arisia.Xerox.COM>
Cc: sandra%defun@cs.utah.edu, cl-editorial@sail.stanford.edu,
        cl-compiler@sail.stanford.edu
In-Reply-To: <masinter@arisia.Xerox.COM>, Wed, 12 Jul 89 00:08:26 PDT

> Date: Wed, 12 Jul 89 00:08:26 PDT
> From: <masinter@arisia.Xerox.COM>
> 
> I intended to vote on a proposal that COMPILE must produce a COMPILED-FUNCTION,
> and that it isn't an error to pass COMPILE a function defined in a non-null
> lexical environment.
> 
> In fact, I believe this was explicitly discussed at the meeting. 

I remember that it was discussed, with lots of argumentation on both
sides, but I don't recall that a consensus was ever reached.  I
suspect that many people on both sides of the issue thought the
proposal resolved this whichever way they wanted it, but the actual
language we voted on says nothing specific.  I don't have a record
that we agreed to further "editorial" clarifications in either my
notes or Mary's minutes.

> Maybe we have to re-clarify again at another meeting, but it seems like
> a not to difficult burden to all valid common lisp implementations that
> their function "COMPILE" actually work on all things that are called
> FUNCTION (especially since there isn't a good way, given a function object,
> to decide whether it might be "defined in a non-null lexical environment".)

Yes, there is such a way.  See the cleanup issue FUNCTION-DEFINITION. 

-Sandra
-------