perm filename CLCOMP.MSG[COM,LSP]7 blob sn#864795 filedate 1988-12-02 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00349 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00049 00002	
C00050 00003	∂29-Mar-88  2234	CL-Compiler-mailer 	Eval-When -- a radical view   
C00062 00004	∂29-Mar-88  2236	CL-Compiler-mailer 	Eval-When -- a radical view   
C00065 00005	∂30-Mar-88  1055	CL-Compiler-mailer 	Eval-When -- a radical view   
C00069 00006	∂12-Apr-88  1347	CL-Compiler-mailer 	archives  
C00070 00007	∂06-May-88  1358	CL-Compiler-mailer 	nesting of EVAL-WHENs    
C00075 00008	∂07-May-88  0456	CL-Compiler-mailer 	nesting of EVAL-WHENs    
C00078 00009	∂08-May-88  1246	CL-Compiler-mailer 	Re: nesting of EVAL-WHENs
C00080 00010	∂09-May-88  0852	CL-Compiler-mailer 	proposals 
C00082 00011	∂09-May-88  0854	CL-Compiler-mailer 	issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS    
C00092 00012	∂09-May-88  0855	CL-Compiler-mailer 	issue EVAL-WHEN-NON-TOP-LEVEL 
C00103 00013	∂09-May-88  0856	CL-Compiler-mailer 	issue DEFINING-MACROS-NON-TOP-LEVEL
C00111 00014	∂10-May-88  2314	CL-Compiler-mailer 	subcommittee meeting(s)  
C00114 00015	∂12-May-88  1826	CL-Compiler-mailer 	subcommittee meeting(s)  
C00116 00016	∂16-May-88  1244	CL-Compiler-mailer 	Re: COMPILE-FILE-OF-TOP-LEVEL-FORMS
C00120 00017	∂16-May-88  2307	CL-Compiler-mailer 	issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS    
C00126 00018	∂17-May-88  0739	CL-Compiler-mailer 	Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
C00130 00019	∂17-May-88  2241	CL-Compiler-mailer 	issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS    
C00136 00020	∂18-May-88  1104	CL-Compiler-mailer 	issue EVAL-WHEN-NON-TOP-LEVEL 
C00143 00021	∂18-May-88  1152	CL-Compiler-mailer 	proposals 
C00145 00022	∂19-May-88  1012	CL-Compiler-mailer 	subcommittee meeting(s)  
C00149 00023	∂20-May-88  0825	CL-Compiler-mailer 	issue EVAL-WHEN-NON-TOP-LEVEL 
C00154 00024	∂20-May-88  1158	CL-Compiler-mailer 	Re: issue EVAL-WHEN-NON-TOP-LEVEL  
C00157 00025	∂20-May-88  1208	CL-Compiler-mailer 	Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS     
C00160 00026	∂20-May-88  1229	CL-Compiler-mailer 	Re: issue EVAL-WHEN-NON-TOP-LEVEL  
C00163 00027	∂20-May-88  1303	CL-Compiler-mailer 	Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS     
C00169 00028	∂20-May-88  1354	CL-Compiler-mailer 	Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS     
C00173 00029	∂20-May-88  1533	CL-Compiler-mailer 	Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS     
C00176 00030	∂20-May-88  1627	CL-Compiler-mailer 	Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS     
C00180 00031	∂20-May-88  1647	CL-Compiler-mailer 	Re: issue EVAL-WHEN-NON-TOP-LEVEL  
C00184 00032	∂21-May-88  0456	CL-Compiler-mailer 	issue EVAL-WHEN-NON-TOP-LEVEL 
C00187 00033	∂21-May-88  1200	CL-Compiler-mailer 	Re: issue EVAL-WHEN-NON-TOP-LEVEL  
C00191 00034	∂23-May-88  1124	CL-Compiler-mailer 	issue DEFINING-MACROS-NON-TOP-LEVEL
C00194 00035	∂24-May-88  1236	CL-Compiler-mailer 	new versions of proposals
C00196 00036	∂24-May-88  1236	CL-Compiler-mailer 	new, improved EVAL-WHEN proposal   
C00210 00037	∂24-May-88  1237	CL-Compiler-mailer 	new, improved defining macros proposal  
C00224 00038	∂24-May-88  1251	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL 
C00227 00039	∂24-May-88  1623	CL-Compiler-mailer 	new, improved defining macros proposal  
C00231 00040	∂25-May-88  0809	CL-Compiler-mailer 	Re: Issue: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS (version 5)  
C00234 00041	∂25-May-88  0926	CL-Compiler-mailer 	Re: new, improved defining macros proposal   
C00238 00042	∂27-May-88  0828	CL-Compiler-mailer 	Re: Issue: EVAL-WHEN-NON-TOP-LEVEL 
C00241 00043	∂09-Jun-88  0921	CL-Compiler-mailer 	Compiler Subcommittee meeting 
C00244 00044	∂09-Jun-88  1219	CL-Compiler-mailer 	Compiler Subcommittee meeting 
C00246 00045	∂09-Jun-88  1346	CL-Compiler-mailer 	Re: Compiler Subcommittee meeting  
C00248 00046	∂09-Jun-88  1415	CL-Compiler-mailer 	(another) revised version of the defining macros proposal   
C00262 00047	∂09-Jun-88  1414	CL-Compiler-mailer 	(another) new version of the non-top-level defining macros proposal   
C00271 00048	∂09-Jun-88  1707	CL-Compiler-mailer 	next order of business   
C00274 00049	∂10-Jun-88  0121	CL-Compiler-mailer 	Compiler Subcommittee meeting and dinner
C00277 00050	∂19-Jun-88  1717	Common-Lisp-mailer 	#, read macro  
C00279 00051	∂19-Jun-88  2355	CL-Compiler-mailer 	#, read macro  
C00281 00052	∂20-Jun-88  1006	Common-Lisp-mailer 	#, read macro  
C00285 00053	∂20-Jun-88  1237	CL-Compiler-mailer 	Re: #, read macro   
C00288 00054	∂20-Jun-88  1706	CL-Compiler-mailer 	#,   
C00290 00055	∂20-Jun-88  2022	CL-Compiler-mailer 	non-top-level DEFUN 
C00293 00056	∂20-Jun-88  2208	CL-Compiler-mailer 	#, read macro  
C00299 00057	∂21-Jun-88  0619	CL-Compiler-mailer 	Re: non-top-level DEFUN  
C00301 00058	∂21-Jun-88  0628	CL-Compiler-mailer 	Re: non-top-level DEFUN  
C00306 00059	∂21-Jun-88  0637	CL-Compiler-mailer 	Re: non-top-level DEFUN  
C00308 00060	∂21-Jun-88  0721	CL-Compiler-mailer 	Re: non-top-level DEFUN  
C00310 00061	∂21-Jun-88  0753	CL-Compiler-mailer 	#, implementation   
C00312 00062	∂21-Jun-88  0932	CL-Compiler-mailer 	re: uses of #, 
C00317 00063	∂21-Jun-88  1019	CL-Compiler-mailer 	#, implementation   
C00320 00064	∂21-Jun-88  1031	CL-Compiler-mailer 	#, implementation   
C00323 00065	∂21-Jun-88  1717	CL-Compiler-mailer 	#, implementation   
C00326 00066	∂01-Jul-88  1229	CL-Compiler-mailer 	status report  
C00328 00067	∂03-Jul-88  1154	CL-Compiler-mailer 	Handling of #, (load-time-eval)    
C00333 00068	∂05-Jul-88  1202	CL-Compiler-mailer 	mailing list   
C00334 00069	∂06-Jul-88  0719	CL-Compiler-mailer 	Handling of #, (load-time-eval)    
C00340 00070	∂07-Jul-88  0949	CL-Compiler-mailer 	Re:  Handling of #, (load-time-eval)    
C00343 00071	∂08-Jul-88  0919	CL-Compiler-mailer 	Handling of #, (load-time-eval)    
C00346 00072	∂08-Jul-88  0919	CL-Compiler-mailer 	Handling of #, (load-time-eval)    
C00351 00073	∂08-Jul-88  1322	CL-Compiler-mailer 	Re:  Handling of #, (load-time-eval)    
C00355 00074	∂08-Jul-88  1532	CL-Compiler-mailer 	Handling of #, (load-time-eval)    
C00362 00075	∂01-Aug-88  1230	CL-Compiler-mailer 	LOAD-TIME-EVAL 
C00390 00076	∂07-Aug-88  1704	CL-Compiler-mailer 	new issues
C00392 00077	∂07-Aug-88  1704	CL-Compiler-mailer 	Issues from last meeting 
C00398 00078	∂08-Aug-88  0912	CL-Compiler-mailer 	issue COMPILE-ARGUMENT-PROBLEMS    
C00404 00079	∂08-Aug-88  0919	CL-Compiler-mailer 	Re:  new issues
C00406 00080	∂12-Aug-88  0756	CL-Compiler-mailer 	issue LOAD-TIME-EVAL
C00412 00081	∂14-Aug-88  0905	CL-Compiler-mailer 	issue LOAD-TIME-EVAL
C00418 00082	∂14-Aug-88  0905	CL-Compiler-mailer 	issue LOAD-TIME-EVAL
C00424 00083	∂14-Aug-88  1254	CL-Compiler-mailer 	multiple copies
C00426 00084	∂16-Aug-88  1547	CL-Compiler-mailer 	issue LOAD-TIME-EVAL
C00436 00085	∂22-Aug-88  1520	CL-Compiler-mailer 	Re: Issues from last meeting  
C00439 00086	∂01-Sep-88  1437	CL-Compiler-mailer 	October meeting
C00443 00087	∂01-Sep-88  1436	CL-Compiler-mailer 	issue COMPILE-FILE-PACKAGE    
C00446 00088	∂02-Sep-88  1420	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY   
C00457 00089	∂02-Sep-88  1958	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY   
C00459 00090	∂03-Sep-88  0747	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
C00461 00091	∂05-Sep-88  0854	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
C00463 00092	∂05-Sep-88  1416	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
C00467 00093	∂06-Sep-88  0817	CL-Compiler-mailer 	Re:  issue COMPILE-ENVIRONMENT-CONSISTENCY   
C00471 00094	∂06-Sep-88  0844	CL-Compiler-mailer 	Re:  issue COMPILE-ENVIRONMENT-CONSISTENCY   
C00474 00095	∂06-Sep-88  0915	CL-Compiler-mailer 	Re:  issue COMPILE-ENVIRONMENT-CONSISTENCY   
C00478 00096	∂06-Sep-88  0921	CL-Compiler-mailer 	Re:  issue COMPILE-ENVIRONMENT-CONSISTENCY   
C00480 00097	∂06-Sep-88  1053	CL-Compiler-mailer 	Re:  issue COMPILE-ENVIRONMENT-CONSISTENCY   
C00482 00098	∂07-Sep-88  1018	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
C00484 00099	∂07-Sep-88  1032	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
C00487 00100	∂07-Sep-88  1211	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
C00490 00101	∂07-Sep-88  1222	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
C00493 00102	∂07-Sep-88  1354	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
C00499 00103	∂07-Sep-88  1405	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
C00502 00104	∂07-Sep-88  1454	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
C00509 00105	∂08-Sep-88  1335	CL-Compiler-mailer 	Re: LOAD-TIME-EVAL  
C00512 00106	∂08-Sep-88  1604	CL-Compiler-mailer 	Re: LOAD-TIME-EVAL  
C00526 00107	∂09-Sep-88  0734	CL-Compiler-mailer 	Re: LOAD-TIME-EVAL  
C00530 00108	∂09-Sep-88  0835	CL-Compiler-mailer 	Re: LOAD-TIME-EVAL  
C00533 00109	∂09-Sep-88  0907	CL-Compiler-mailer 	Re: LOAD-TIME-EVAL  
C00541 00110	∂09-Sep-88  0942	CL-Compiler-mailer 	Re: LOAD-TIME-EVAL  
C00545 00111	∂09-Sep-88  1220	CL-Compiler-mailer 	issue OPTIMIZE-DEBUG-INFO
C00552 00112	∂09-Sep-88  1241	CL-Compiler-mailer 	Re: issue OPTIMIZE-DEBUG-INFO 
C00555 00113	∂09-Sep-88  1306	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY, version 2  
C00569 00114	∂09-Sep-88  1329	CL-Compiler-mailer 	Re: LOAD-TIME-EVAL  
C00572 00115	∂09-Sep-88  1522	CL-Compiler-mailer 	Re: LOAD-TIME-EVAL  
C00577 00116	∂09-Sep-88  1629	CL-Compiler-mailer 	Re: LOAD-TIME-EVAL  
C00583 00117	∂12-Sep-88  0836	CL-Compiler-mailer 	Re: LOAD-TIME-EVAL  
C00587 00118	∂12-Sep-88  0856	CL-Compiler-mailer 	Re: LOAD-TIME-EVAL  
C00591 00119	∂12-Sep-88  1051	CL-Compiler-mailer 	issue LOAD-TIME-EVAL
C00594 00120	∂12-Sep-88  1459	CL-Compiler-mailer 	issue DEFINING-MACROS-NON-TOP-LEVEL, version 3    
C00604 00121	∂16-Sep-88  1525	CL-Compiler-mailer 	issue LOAD-TIME-EVAL, again   
C00611 00122	∂16-Sep-88  1850	CL-Compiler-mailer 	Issue PROCLAIM-INLINE-WHERE   
C00616 00123	∂16-Sep-88  1850	CL-Compiler-mailer 	Issue PROCLAIM-ETC-IN-COMPILE-FILE 
C00625 00124	∂17-Sep-88  0905	CL-Compiler-mailer 	Re: Issue PROCLAIM-INLINE-WHERE    
C00627 00125	∂17-Sep-88  0926	CL-Compiler-mailer 	Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE  
C00630 00126	∂19-Sep-88  0845	CL-Compiler-mailer 	Issue status for October meeting   
C00635 00127	∂19-Sep-88  0933	CL-Compiler-mailer 	Issue: LOAD-TIME-EVAL    
C00639 00128	∂19-Sep-88  1205	CL-Compiler-mailer 	Re: issue OPTIMIZE-DEBUG-INFO 
C00643 00129	∂19-Sep-88  1226	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 3
C00646 00130	∂19-Sep-88  1225	CL-Compiler-mailer 	issue OPTIMIZE-DEBUG-INFO
C00651 00131	∂19-Sep-88  1308	CL-Compiler-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM  
C00663 00132	∂19-Sep-88  1311	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 3
C00665 00133	∂19-Sep-88  1323	CL-Compiler-mailer 	issue OPTIMIZE-DEBUG-INFO
C00667 00134	∂19-Sep-88  1454	CL-Compiler-mailer 	Re: issue LOAD-TIME-EVAL, again    
C00669 00135	∂19-Sep-88  1705	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 3
C00671 00136	∂19-Sep-88  1722	CL-Compiler-mailer 	issue DEFINING-MACROS-NON-TOP-LEVEL, version 3    
C00673 00137	∂19-Sep-88  1734	CL-Compiler-mailer 	issue DEFINING-MACROS-NON-TOP-LEVEL, version 3    
C00675 00138	∂19-Sep-88  1736	CL-Compiler-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
C00678 00139	∂19-Sep-88  1736	CL-Compiler-mailer 	Re: issue OPTIMIZE-DEBUG-INFO 
C00680 00140	∂20-Sep-88  0712	CL-Compiler-mailer 	Issue: COMPILE-ARGUMENT-PROBLEMS   
C00681 00141	∂20-Sep-88  0715	CL-Compiler-mailer 	Issue: COMPILE-FILE-PACKAGE   
C00682 00142	∂20-Sep-88  0717	CL-Compiler-mailer 	Issue: PROCLAIM-INLINE-WHERE  
C00683 00143	∂20-Sep-88  0831	CL-Compiler-mailer 	Issue: EVAL-WHEN-NON-TOP-LEVEL
C00686 00144	∂20-Sep-88  0859	CL-Compiler-mailer 	Re: Issue: EVAL-WHEN-NON-TOP-LEVEL 
C00690 00145	∂20-Sep-88  0931	CL-Compiler-mailer 	Re: Issue: EVAL-WHEN-NON-TOP-LEVEL 
C00692 00146	∂20-Sep-88  0927	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
C00698 00147	∂20-Sep-88  1044	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
C00702 00148	∂20-Sep-88  1321	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 3
C00704 00149	∂20-Sep-88  1649	CL-Compiler-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM  
C00710 00150	∂20-Sep-88  1715	CL-Cleanup-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
C00712 00151	∂20-Sep-88  1746	CL-Compiler-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM  
C00715 00152	∂20-Sep-88  1836	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
C00719 00153	∂20-Sep-88  1921	CL-Cleanup-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
C00723 00154	∂20-Sep-88  1944	CL-Compiler-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM  
C00729 00155	∂20-Sep-88  1959	CL-Cleanup-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
C00731 00156	∂20-Sep-88  2004	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
C00735 00157	∂20-Sep-88  2126	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
C00739 00158	∂20-Sep-88  2132	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
C00742 00159	∂20-Sep-88  2326	CL-Cleanup-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
C00744 00160	∂21-Sep-88  0811	CL-Compiler-mailer 	Issue: PROCLAIM-ETC-IN-COMPILE-FILE
C00747 00161	∂21-Sep-88  0827	CL-Compiler-mailer 	Issues: EVAL-WHEN-NON-TOP-LEVEL, DEFINING-MACROS-NON-TOP-LEVEL   
C00750 00162	∂21-Sep-88  0834	CL-Compiler-mailer 	Issue: OPTIMIZE-DEBUG-INFO    
C00752 00163	∂21-Sep-88  0950	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
C00757 00164	∂21-Sep-88  1050	CL-Compiler-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
C00764 00165	∂21-Sep-88  1120	CL-Compiler-mailer 	Re: Issue: PROCLAIM-ETC-IN-COMPILE-FILE 
C00768 00166	∂21-Sep-88  1126	CL-Compiler-mailer 	Re: Issues: EVAL-WHEN-NON-TOP-LEVEL, DEFINING-MACROS-NON-TOP-LEVEL    
C00770 00167	∂21-Sep-88  1126	CL-Compiler-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
C00775 00168	∂21-Sep-88  1126	CL-Compiler-mailer 	Issue: COMPILE-FILE-ENVIRONMENT (Version 1)  
C00784 00169	∂21-Sep-88  1153	CL-Cleanup-mailer 	Issue: LOAD-TIME-EVAL (Version 6)   
C00793 00170	∂21-Sep-88  1300	CL-Cleanup-mailer 	Issue: LOAD-TIME-EVAL (Version 6)   
C00796 00171	∂21-Sep-88  1321	CL-Compiler-mailer 	Issue: LOAD-TIME-EVAL (Version 6)  
C00800 00172	∂21-Sep-88  1340	CL-Compiler-mailer 	Issue: LOAD-TIME-EVAL (Version 6)  
C00802 00173	∂21-Sep-88  1329	CL-Cleanup-mailer 	Issue: LOAD-TIME-EVAL (Version 6)   
C00806 00174	∂21-Sep-88  1408	CL-Compiler-mailer 	Re: Issue: LOAD-TIME-EVAL (Version 6)   
C00811 00175	∂21-Sep-88  1436	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
C00815 00176	∂21-Sep-88  1525	CL-Compiler-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
C00821 00177	∂22-Sep-88  0935	CL-Compiler-mailer 	Issue ALLOW-LOCAL-INLINE 
C00828 00178	∂22-Sep-88  0946	CL-Compiler-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
C00831 00179	∂22-Sep-88  0941	CL-Cleanup-mailer 	Issue: LOAD-TIME-EVAL (Version 6)   
C00835 00180	∂23-Sep-88  0850	CL-Compiler-mailer 	Re: Issue ALLOW-LOCAL-INLINE  
C00837 00181	∂23-Sep-88  0901	CL-Compiler-mailer 	Re: Issue: COMPILE-FILE-ENVIRONMENT (Version 1)   
C00840 00182	∂23-Sep-88  0905	CL-Compiler-mailer 	re:  COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY  
C00847 00183	∂23-Sep-88  1353	CL-Compiler-mailer 	Re: Issue: COMPILE-FILE-ENVIRONMENT (Version 1)   
C00849 00184	∂23-Sep-88  1730	CL-Compiler-mailer 	issue EVAL-WHEN-NON-TOP-LEVEL 
C00851 00185	∂23-Sep-88  1742	CL-Compiler-mailer 	**DRAFT** issue COMPILE-ENVIRONMENT-CONSISTENCY   
C00854 00186	∂23-Sep-88  2120	CL-Compiler-mailer 	Re: **DRAFT** issue COMPILE-ENVIRONMENT-CONSISTENCY    
C00856 00187	∂23-Sep-88  2149	CL-Compiler-mailer 	Issues: EVAL-WHEN-NON-TOP-LEVEL, DEFINING-MACROS-NON-TOP-LEVEL   
C00858 00188	∂24-Sep-88  1652	CL-Compiler-mailer 	issue COMPILE-FILE-PACKAGE    
C00860 00189	∂24-Sep-88  1658	CL-Compiler-mailer 	Issue: PROCLAIM-INLINE-WHERE (Version 1)
C00862 00190	∂24-Sep-88  1709	CL-Compiler-mailer 	issue OPTIMIZE-DEBUG-INFO
C00865 00191	∂24-Sep-88  1720	CL-Compiler-mailer 	Issue ALLOW-LOCAL-INLINE (Version 1)    
C00869 00192	∂24-Sep-88  1726	CL-Compiler-mailer 	issue COMPILE-ARGUMENT-PROBLEMS    
C00872 00193	∂24-Sep-88  1914	CL-Compiler-mailer 	Issue ALLOW-LOCAL-INLINE (Version 1)    
C00874 00194	∂26-Sep-88  0932	CL-Compiler-mailer 	Re: Issue ALLOW-LOCAL-INLINE (Version 1)
C00878 00195	∂26-Sep-88  0933	CL-Compiler-mailer 	DEFCONSTANT    
C00881 00196	∂26-Sep-88  0937	CL-Compiler-mailer 	Re: Issue ALLOW-LOCAL-INLINE (Version 1)
C00886 00197	∂26-Sep-88  1044	CL-Compiler-mailer 	Re: Issue ALLOW-LOCAL-INLINE (Version 1)
C00890 00198	∂26-Sep-88  1046	CL-Compiler-mailer 	Flush COMPILER-LET? 
C00891 00199	∂26-Sep-88  1130	CL-Compiler-mailer 	Re: Flush COMPILER-LET?  
C00894 00200	∂26-Sep-88  1152	CL-Compiler-mailer 	Re: Flush COMPILER-LET?  
C00896 00201	∂26-Sep-88  1158	CL-Compiler-mailer 	Re: Flush COMPILER-LET?  
C00898 00202	∂26-Sep-88  1328	CL-Compiler-mailer 	[James Rice <Rice@SUMEX-AIM.Stanford.EDU>: Re: Compiler-Let]
C00901 00203	∂26-Sep-88  1237	Common-Lisp-mailer 	COMPILER-LET   
C00905 00204	∂26-Sep-88  1351	CL-Compiler-mailer 	Re: Flush COMPILER-LET?  
C00909 00205	∂26-Sep-88  1359	CL-Compiler-mailer 	[James Rice <Rice@SUMEX-AIM.Stanford.EDU>: Re: Compiler-Let]
C00912 00206	∂26-Sep-88  1512	CL-Compiler-mailer 	Re: COMPILER-LET    
C00915 00207	∂26-Sep-88  1413	Common-Lisp-mailer 	COMPILER-LET   
C00919 00208	∂26-Sep-88  1540	CL-Compiler-mailer 	Re: COMPILER-LET    
C00923 00209	∂26-Sep-88  1800	CL-Compiler-mailer 	**DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE 
C00926 00210	∂26-Sep-88  2154	CL-Cleanup-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
C00936 00211	∂27-Sep-88  0721	CL-Compiler-mailer 	Re: Flush COMPILER-LET?  
C00940 00212	∂27-Sep-88  0821	CL-Compiler-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
C00943 00213	∂27-Sep-88  0851	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)    
C00946 00214	∂27-Sep-88  0918	CL-Compiler-mailer 	Re: Flush COMPILER-LET?  
C00954 00215	∂27-Sep-88  0937	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)    
C00959 00216	∂27-Sep-88  1030	CL-Compiler-mailer 	Re: COMPILER-LET    
C00962 00217	∂27-Sep-88  1030	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)    
C00965 00218	∂27-Sep-88  1031	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)    
C00971 00219	∂27-Sep-88  1039	CL-Compiler-mailer 	Re: COMPILER-LET    
C00974 00220	∂27-Sep-88  1148	CL-Compiler-mailer 	compiler-let, again 
C00977 00221	∂27-Sep-88  1207	CL-Compiler-mailer 	Re: Flush COMPILER-LET?  
C00981 00222	∂27-Sep-88  1221	CL-Compiler-mailer 	Re: COMPILER-LET    
C00985 00223	∂27-Sep-88  1250	CL-Compiler-mailer 	Re: Flush COMPILER-LET?  
C00991 00224	∂27-Sep-88  1307	CL-Compiler-mailer 	Re: COMPILER-LET    
C00996 00225	∂27-Sep-88  1410	CL-Compiler-mailer 	Re: COMPILER-LET    
C01003 00226	∂27-Sep-88  1502	CL-Compiler-mailer 	Re: COMPILER-LET    
C01008 00227	∂27-Sep-88  1632	CL-Compiler-mailer 	issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)   
C01011 00228	∂27-Sep-88  1926	CL-Compiler-mailer 	compiler errors (was Re: issue DEFINING-MACROS-NON-TOP-LEVEL)    
C01014 00229	∂27-Sep-88  2254	CL-Compiler-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM  
C01017 00230	∂28-Sep-88  1120	CL-Compiler-mailer 	Re: COMPILER-LET    
C01019 00231	∂28-Sep-88  1121	CL-Compiler-mailer 	Re: COMPILER-LET    
C01022 00232	∂28-Sep-88  1132	CL-Compiler-mailer 	Issue COMPILER-LET-CONFUSION, version 1 
C01040 00233	∂28-Sep-88  1154	CL-Compiler-mailer 	Issue COMPILER-LET-CONFUSION, version 1 
C01042 00234	∂28-Sep-88  1233	CL-Compiler-mailer 	Issue: DEFINE-OPTIMIZER  
C01054 00235	∂28-Sep-88  1350	CL-Compiler-mailer 	Re: Issue: DEFINE-OPTIMIZER   
C01058 00236	∂28-Sep-88  1351	CL-Compiler-mailer 	Re: Issue: DEFINE-OPTIMIZER   
C01063 00237	∂28-Sep-88  1444	CL-Compiler-mailer 	summary of issues   
C01077 00238	∂28-Sep-88  1535	CL-Compiler-mailer 	Issue: DEFINE-OPTIMIZER  
C01081 00239	∂28-Sep-88  1609	CL-Compiler-mailer 	Re: Issue: DEFINE-OPTIMIZER   
C01084 00240	∂28-Sep-88  1643	CL-Compiler-mailer 	Issue: DEFINE-OPTIMIZER  
C01087 00241	∂28-Sep-88  1646	CL-Compiler-mailer 	Issue COMPILER-LET-CONFUSION, version 1 
C01089 00242	∂28-Sep-88  1740	CL-Compiler-mailer 	Issue: DEFINE-OPTIMIZER  
C01091 00243	∂29-Sep-88  0654	CL-Compiler-mailer 	Issue: DEFINE-OPTIMIZER  
C01097 00244	∂29-Sep-88  0657	CL-Compiler-mailer 	Issue: DEFINE-OPTIMIZER  
C01099 00245	∂29-Sep-88  0712	CL-Compiler-mailer 	Re: Issue: DEFINE-OPTIMIZER   
C01102 00246	∂29-Sep-88  0731	CL-Compiler-mailer 	Re: Issue: DEFINE-OPTIMIZER   
C01106 00247	∂29-Sep-88  1513	CL-Compiler-mailer 	Issue: WITH-COMPILATION-UNIT (Version 1)
C01113 00248	∂29-Sep-88  1552	CL-Compiler-mailer 	Re: Issue: DEFINE-OPTIMIZER   
C01116 00249	∂29-Sep-88  1555	CL-Compiler-mailer 	Issue: WITH-COMPILATION-UNIT (Version 1)
C01118 00250	∂29-Sep-88  1605	CL-Compiler-mailer 	Issue DEFCONSTANT-VALUE  
C01133 00251	∂29-Sep-88  1631	CL-Compiler-mailer 	Issue DEFCONSTANT-VALUE  
C01135 00252	∂29-Sep-88  1801	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE   
C01138 00253	∂29-Sep-88  1830	CL-Compiler-mailer 	Re: Issue: WITH-COMPILATION-UNIT (Version 1) 
C01141 00254	∂29-Sep-88  2208	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE   
C01144 00255	∂30-Sep-88  0935	CL-Compiler-mailer 	Re: Issue: WITH-COMPILATION-UNIT (Version 1) 
C01150 00256	∂30-Sep-88  0958	CL-Compiler-mailer 	issue COMPILER-LET-CONFUSION  
C01156 00257	∂30-Sep-88  1212	CL-Compiler-mailer 	Issue: DEFINE-OPTIMIZER  
C01161 00258	∂30-Sep-88  1347	CL-Compiler-mailer 	Re: Issue: WITH-COMPILATION-UNIT (Version 1) 
C01164 00259	∂30-Sep-88  1435	CL-Compiler-mailer 	Re: Issue: WITH-COMPILATION-UNIT (Version 1) 
C01170 00260	∂01-Oct-88  1654	CL-Compiler-mailer 	Issue DEFCONSTANT-VALUE  
C01177 00261	∂02-Oct-88  1135	CL-Cleanup-mailer 	New Issue: SYNTACTIC-ENVIRONMENT-ACCESS  
C01197 00262	∂02-Oct-88  1159	CL-Compiler-mailer 	Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)    
C01205 00263	∂02-Oct-88  1223	CL-Compiler-mailer 	Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)    
C01207 00264	∂02-Oct-88  1257	CL-Compiler-mailer 	New Issue: SYNTACTIC-ENVIRONMENT-ACCESS 
C01214 00265	∂02-Oct-88  1346	CL-Compiler-mailer 	Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)    
C01216 00266	∂03-Oct-88  0618	CL-Compiler-mailer 	Re: Issue: WITH-COMPILATION-UNIT (Version 1) 
C01219 00267	∂03-Oct-88  0958	CL-Cleanup-mailer 	Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS   
C01224 00268	∂03-Oct-88  1737	CL-Compiler-mailer 	Re: Issue: WITH-COMPILATION-UNIT (Version 1) 
C01226 00269	∂03-Oct-88  1954	CL-Compiler-mailer 	Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS  
C01233 00270	∂03-Oct-88  1959	CL-Compiler-mailer 	New Issue: SYNTACTIC-ENVIRONMENT-ACCESS 
C01235 00271	∂03-Oct-88  2102	CL-Cleanup-mailer 	Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS   
C01241 00272	∂04-Oct-88  1234	CL-Compiler-mailer 	Issue: WITH-COMPILATION-UNIT (Version 1)
C01243 00273	∂05-Oct-88  1222	CL-Compiler-mailer 	Re: Issue COMPILER-LET-CONFUSION, version 1  
C01247 00274	∂05-Oct-88  1242	CL-Compiler-mailer 	Issue: DEFINE-OPTIMIZER  
C01262 00275	∂05-Oct-88  1351	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE   
C01267 00276	∂05-Oct-88  1453	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE   
C01271 00277	∂05-Oct-88  1503	CL-Compiler-mailer 	Re: Issue COMPILER-LET-CONFUSION, version 1  
C01276 00278	∂05-Oct-88  1533	CL-Compiler-mailer 	Re: Issue COMPILER-LET-CONFUSION, version 1  
C01279 00279	∂05-Oct-88  1539	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE   
C01285 00280	∂05-Oct-88  1539	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE   
C01288 00281	∂05-Oct-88  1558	CL-Cleanup-mailer 	New Issue: SYNTACTIC-ENVIRONMENT-ACCESS  
C01292 00282	∂05-Oct-88  1706	CL-Compiler-mailer 	Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS  
C01298 00283	∂06-Oct-88  1038	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE   
C01303 00284	∂06-Oct-88  1437	CL-Compiler-mailer 	Issue DEFCONSTANT-VALUE (V2)  
C01318 00285	∂06-Oct-88  1452	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE   
C01326 00286	∂06-Oct-88  1521	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE (V2)   
C01332 00287	∂07-Oct-88  0951	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE (V2)   
C01335 00288	∂07-Oct-88  1010	CL-Compiler-mailer 	Re: Issue: DEFINE-OPTIMIZER   
C01339 00289	∂07-Oct-88  1030	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE (V2)   
C01341 00290	∂07-Oct-88  1055	CL-Compiler-mailer 	Re: Issue: DEFINE-OPTIMIZER   
C01343 00291	∂07-Oct-88  1139	CL-Compiler-mailer 	Issue DEFCONSTANT-NOT-WIRED   
C01347 00292	∂07-Oct-88  1139	CL-Compiler-mailer 	issue COMPILER-LET-CONFUSION, version 2 
C01370 00293	∂07-Oct-88  1222	CL-Compiler-mailer 	Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS  
C01376 00294	∂07-Oct-88  1240	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED    
C01379 00295	∂07-Oct-88  1258	CL-Compiler-mailer 	Issue DEFCONSTANT-NOT-WIRED   
C01383 00296	∂07-Oct-88  1350	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED    
C01387 00297	∂07-Oct-88  1422	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED    
C01391 00298	∂07-Oct-88  1440	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE   
C01395 00299	∂07-Oct-88  1452	CL-Compiler-mailer 	Issue DEFCONSTANT-VALUE (V2)  
C01397 00300	∂07-Oct-88  1455	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED    
C01401 00301	∂07-Oct-88  1814	CL-Compiler-mailer 	Issue DEFCONSTANT-NOT-WIRED   
C01406 00302	∂09-Oct-88  0025	CL-Compiler-mailer 	Issue DEFCONSTANT-VALUE (V2)  
C01410 00303	∂09-Oct-88  0035	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED    
C01415 00304	∂09-Oct-88  0036	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE   
C01417 00305	∂09-Oct-88  0041	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED    
C01419 00306	∂10-Oct-88  1334	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED    
C01423 00307	∂11-Oct-88  1136	CL-Compiler-mailer 	Error specification 
C01425 00308	∂13-Oct-88  1137	CL-Compiler-mailer 	summary from Fairfax meeting  
C01430 00309	∂13-Oct-88  1205	CL-Compiler-mailer 	summary on issue LOAD-TIME-EVAL    
C01435 00310	∂13-Oct-88  1456	CL-Cleanup-mailer 	issue IN-PACKAGE-FUNCTIONALITY 
C01438 00311	∂13-Oct-88  1927	CL-Cleanup-mailer 	Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)    
C01440 00312	∂13-Oct-88  1940	CL-Compiler-mailer 	Re:  issue IN-PACKAGE-FUNCTIONALITY
C01442 00313	∂14-Oct-88  0857	CL-Compiler-mailer 	Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)   
C01444 00314	∂14-Oct-88  1419	CL-Compiler-mailer 	Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS  
C01448 00315	∂14-Oct-88  1505	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE (V2)   
C01451 00316	∂17-Oct-88  1203	CL-Compiler-mailer 	issue LOAD-TIME-EVAL, version 7    
C01465 00317	∂17-Oct-88  1204	CL-Compiler-mailer 	issue SHARP-COMMA-CONFUSION, version 1  
C01472 00318	∂17-Oct-88  1346	CL-Compiler-mailer 	issue SHARP-COMMA-CONFUSION, version 1  
C01474 00319	∂19-Oct-88  0850	CL-Compiler-mailer 	issue COMPILER-DIAGNOSTICS, version 2   
C01485 00320	∂20-Oct-88  1207	CL-Compiler-mailer 	issue COMPILER-DIAGNOSTICS, version 2   
C01500 00321	∂20-Oct-88  1408	CL-Compiler-mailer 	Re: issue COMPILER-DIAGNOSTICS, version 2    
C01505 00322	∂20-Oct-88  1435	CL-Compiler-mailer 	Re: issue COMPILER-DIAGNOSTICS, version 2    
C01509 00323	∂21-Oct-88  1401	CL-Compiler-mailer 	Issue: IN-SYNTAX (Version 1)  
C01513 00324	∂21-Oct-88  1415	CL-Cleanup-mailer 	Issue: IN-SYNTAX (Version 1)   
C01518 00325	∂21-Oct-88  1420	CL-Cleanup-mailer 	Issue: IN-SYNTAX (Version 1)   
C01521 00326	∂21-Oct-88  1716	CL-Compiler-mailer 	Issue DEFCONSTANT-VALUE  
C01523 00327	∂21-Oct-88  1854	CL-Compiler-mailer 	issue DEFPACKAGE    
C01529 00328	∂25-Oct-88  1331	CL-Compiler-mailer 	Re: issue COMPILER-DIAGNOSTICS, version 2    
C01534 00329	∂25-Oct-88  1557	CL-Compiler-mailer 	issue COMPILER-VERBOSITY, version 1
C01542 00330	∂26-Oct-88  1203	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY, V3    
C01557 00331	∂26-Oct-88  1212	CL-Compiler-mailer 	issue COMPILER-LET-CONFUSION  
C01559 00332	∂26-Oct-88  2011	CL-Cleanup-mailer 	issue DEFPACKAGE
C01566 00333	∂26-Oct-88  2141	CL-Compiler-mailer 	Re: issue DEFPACKAGE
C01569 00334	∂27-Oct-88  0954	CL-Cleanup-mailer 	Re: issue DEFPACKAGE 
C01573 00335	∂27-Oct-88  1349	CL-Compiler-mailer 	Issue ALLOW-LOCAL-INLINE (V2) 
C01580 00336	∂27-Oct-88  1531	CL-Compiler-mailer 	Re: Issue ALLOW-LOCAL-INLINE (V2)  
C01583 00337	∂27-Oct-88  1719	CL-Compiler-mailer 	Issue DEFCONSTANT-NOT-WIRED (V2)   
C01596 00338	∂27-Oct-88  2230	CL-Compiler-mailer 	Issue: IN-SYNTAX (Version 1)  
C01599 00339	∂28-Oct-88  0841	CL-Compiler-mailer 	Re: Issue ALLOW-LOCAL-INLINE (V2)  
C01603 00340	∂28-Oct-88  1113	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED (V2)    
C01606 00341	∂28-Oct-88  1122	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED (V2)    
C01612 00342	∂31-Oct-88  0854	CL-Compiler-mailer 	issue COMPILER-LET-CONFUSION, V3   
C01626 00343	∂31-Oct-88  1023	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED (V2)    
C01629 00344	∂31-Oct-88  1116	CL-Compiler-mailer 	Re: issue COMPILER-VERBOSITY, version 1 
C01633 00345	∂31-Oct-88  1450	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED (V2)    
C01636 00346	∂31-Oct-88  1607	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED (V2)    
C01642 00347	∂31-Oct-88  1620	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED (V2)    
C01645 00348	∂01-Nov-88  0921	CL-Compiler-mailer 	issue COMPILER-DIAGNOSTICS, version 4   
C01661 00349	∂02-Nov-88  1653	CL-Compiler-mailer 	Re: issue COMPILER-DIAGNOSTICS, version 4    
C01666 ENDMK
C⊗;
∂29-Mar-88  2234	CL-Compiler-mailer 	Eval-When -- a radical view   
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Mar 88  22:34:24 PST
Received: by labrea.Stanford.EDU; Tue, 29 Mar 88 22:32:17 PST
Received: from bhopal.lucid.com by edsel id AA12080g; Tue, 29 Mar 88 22:24:31 PST
Received: by bhopal id AA01977g; Tue, 29 Mar 88 22:24:41 PST
Date: Tue, 29 Mar 88 22:24:41 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8803300624.AA01977@bhopal.lucid.com>
To: Rob.MacLachlan@wb1.cs.cmu.edu
Cc: sandra@cs.utah.edu, cl-compiler@sail.stanford.edu
In-Reply-To: Rob.MacLachlan@WB1.CS.CMU.EDU's message of Sat, 26 Mar 88 12:38:29 EST <8803270744.AA29754@edsel.lucid.com>
Subject: Eval-When -- a radical view 

You sure put "a mouthful" in your reply!  I'm not sure that I'll be able now
to comment on all the things you've brought up, but here goes ...

re: A narrow complaint that I have is that it seems you haven't been as 
    consistent as you could be in extending the semantics described in CLTL.  
    In your version, compiling:
    (eval-when (compile)
      (eval-when (load)
	(print 'foo)))
    . . . 

You're quite right; the code I suggested for EVAL-WHEN should have the line:
	(:eval-before-compile  T)
changed to be
	(:eval-before-compile  (or (memq 'eval situations)
                                   (memq 'load situations)))
That should better reflect the semantics of what CLtL calls "compile-time-too".


re: It should also be clear that using a dynamic variable *EVAL-WHEN-STATE* is
    an implementation detail, and not part of the inherent semantics.  For one,
    requiring EVAL to bind a special prevents it from being tail-recursive.  
    What you really want to do is lexically modify the evaluation rules.  Using
    a dynamic variable bound by EVAL and COMPILE is an approximation of this, 
    but things become more confusing when there are any other ways for the 
    lexical environment to become null.  

Right again.  Mostly my use of the dynamic variable *EVAL-WHEN-STATE* is 
merely to make it easier to understand a rather simple defmacro definition 
for EVAL-WHEN.


re: Even supposing we could clearly define EVAL-WHEN in a way that extended 
    cleanly across all implementations that we want to support, EVAL-WHEN 
    would still be bad because it is too powerful: it allows users to say 
    things that aren't meaningful across all implementations -- it encourages 
    writing of programs that don't work interpreted (or compiled).

This paragraph is representative of large section of your note, basically
saying that trying to "patch up" EVAL-WHEN is a doomed process.  I disagree
mildly.  In particular, the ability to "say things that aren't meaningful"
is not focused enough to warrant tossing out eval-when.  I agree that the
willy-nilly generation of legal syntatic forms will come up with some
meaningless phrases; why, even my proposal presented an interpretation for

   (defun foo (x) 
     (mumble (eval-when (load) (bletch x))))

even though that is clearly a meaningless thing to do. [my presentation was
to view the 'load' situation as meaning that this should be incorporated
into the compiled code and only into the compiled code; Sandra's presentation
 -- at least verbally at the Friday morning meetings -- was that it could
mean something like #,  and in a way I prefer hers now]  Rather, I like the 
simplicity of EVAL-WHEN for the combinations that do make good sense.  As
you say, 

    I searched through our system sources looking for all uses of EVAL-WHEN. 
    Nearly all uses involved one of two situations lists:
     (COMPILE LOAD EVAL)
     (COMPILE EVAL)
    . . . 
    There were also quite a few uses of the (COMPILE) situation list, but 
    nearly all of these were erroneous; the code wouldn't have worked 
    interpreted.  

On the other hand, in our system, the relatively few instances of the (COMPILE)
situation are precisely for code that can't work interpreted.  I myself have
even inserted a couple of lines like
    (eval-when (eval) 
      (error "You Loser! this file can't be run interpretively"))
We have a few places in our system that are defined only by the code-generator
parts of the compiler; some of these functions have interpreter entries that
look like the classic:
    (defun car (x)
      (check-type x list)
      (car x))
but most are merely internal compiler stuff that doesn't need such an entry.
Files that reference such functions simply can't be run except when compiled.

But the whole point is that whether the number of "meaningful" situations
is 3 or 4 or 5 out of a possible 8, that is no reason to give up just
because the other few are not particularly useful.


Now, Sandra brings up another good point (which you too, Rob, mention) --

    The problem of having the same piece of code sometimes get evaluated in
    the current lexical environment and sometimes not is going to be easy to
    resolve.  There does not seem to be much disagreement that the COMPILE
    situation must do its evaluation in the null lexical environment. . . . 

Maybe I'll exercise my perogative to bring in some "disagreement".  Perhaps 
feeding an &environment argument to eval-when isn't so bad after all.  In 
terms of my trial-baloon defmacro for eval-when, the only problematical point
is how to transmit an outter environment down through the code:
        (mapc #'eval-internal code)
I'm sure that some suitable solution could be found.  Maybe even binding
the *EVAL-WHEN-STATE* to it instead of :EVAL-BEFORE-COMPILE could work?
Also Sandra's mention of a possible definition of DEFMACRO in terms of
EVAL-WHEN and SETF(MACRO-FUNCTION ...) adds weight to the need for a solution.
At any rate, I think this is indeed an important enough problem to spend
some time thinking about [looking for a consistent solution that is, not
just looking for reasons to chuck out the whole kit-and-kaboodle].


If we were to adopt some notion that each "file" is a lexical entity --  
equivalent for scoping as if there were a giant (locally ....) enclosing the 
entire file -- then it would be even more important to pass in &environment
information to eval-when.  [But of course you couldn't do this "enclosing"
literally since that would mean reading in all the forms of the file before 
processing any of them].  My proposal for a lexical-file-proclaim needs
such a notion of lexical scoping, and I believe it accurately reflects
desiderata set out by Beckerele and others about the semantics of what
a "file" is such that you can apply COMPILE-FILE to it; but this is a
topic for yet another time.


Incidentally, the example that Sandra offers

    (eval-when (eval compile load)
	(let ((x  (compute-some-value)))
	    (defmacro foo (y)
		`(+ ,x ,y))))

Could just as well have been

    (eval-when (eval compile)
	(let ((x  (compute-some-value)))
	    (defmacro foo (y)
		`(+ ,x ,y))))


That is, the proponents of this style frequently need it only in the
compiler's environment.  For an implementation that doesn't have an
interpreter, then the situation marker (eval compile) is still right,
since it means first compiling
	(let ((x  (compute-some-value)))
	    (defmacro foo (y)
		`(+ ,x ,y)))
and then immediately afterwards calling that compiled "thunk" to be executed.
The macro is now "alive" for subsequent compilations of forms found later in
the file.


-- JonL --

∂29-Mar-88  2236	CL-Compiler-mailer 	Eval-When -- a radical view   
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Mar 88  22:36:03 PST
Received: by labrea.Stanford.EDU; Tue, 29 Mar 88 22:34:23 PST
Received: from bhopal.lucid.com by edsel id AA12136g; Tue, 29 Mar 88 22:31:34 PST
Received: by bhopal id AA01993g; Tue, 29 Mar 88 22:31:44 PST
Date: Tue, 29 Mar 88 22:31:44 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8803300631.AA01993@bhopal.lucid.com>
To: jeff%aiva.edinburgh.ac.uk@nss.cs.ucl.ac.uk
Cc: cl-compiler@sail.stanford.edu, <@edsel,@labrea.stanford.edu:jonl>
In-Reply-To: Jeff Dalton's message of Mon, 28 Mar 88 17:00:29 bst <22121.8803281600@aiva.ed.ac.uk>
Subject: Eval-When -- a radical view

re: There is one subtlety that I think should be addressed, and that is:
    what should implementations that always and only compile do?  . . . 

So maybe the top-level processor that is masquarading as "top-level EVAL"
should call a private entry into the compiler that doesn't rebind
*EVAL-WHEN-STATE*?  I already had to presume such an entry to the
interpreter in the trial-balloon defmacro for EVAL-WHEN.

Even in the most minimal of implementations, I presume that LOAD differs
from COMPILE-FILE in that LOAD will successively "execute" each form 
before even reading the next one.  And COMPILE-FILE is called primarily
for the side-effect of creating a "binary" file.   So it still makes sense 
to me to have separate "situation" markers for :EVALUATING and :COMPILING,
even though serious portability questions arise about some combinations
of "situations".



-- JonL --

∂30-Mar-88  1055	CL-Compiler-mailer 	Eval-When -- a radical view   
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 30 Mar 88  10:53:00 PST
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 30 Mar 88 11:00-EST
Received: from ACORN.Gold-Hill.DialNet.Symbolics.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 85774; 30 Mar 88 10:11:55-EST
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 97736; Wed 30-Mar-88 09:13:24-EST
Date: Wed, 30 Mar 88 09:15 est
From: mike%acorn@oak.lcs.mit.edu (mike@gold-hill.com after 1-April-88)
COMMENTS: NOTE %acorn@oak... CHANGES TO @GOLD-HILL.COM ON 1-April-88
To: edsel!jonl@labrea.Stanford.EDU
Subject: Eval-When -- a radical view 
Cc: Rob.MacLachlan@wb1.cs.cmu.edu, sandra@cs.utah.edu,
    cl-compiler@sail.stanford.edu

    
        I searched through our system sources looking for all uses of 
        EVAL-WHEN. 
        Nearly all uses involved one of two situations lists:
         (COMPILE LOAD EVAL)
         (COMPILE EVAL)

In our implementation, the most common situation for eval-when is
(compile eval). This is used to exclude macros, constants, etc that
are compiled in to a delivered system. Another common one is
(load eval), which is used within expansions of macros to force loading
of runtime support: e.g.,

  (defmacro mac (....)
   `(progn
      (eval-when (load eval) (require "runtime-support"))
      ...rest of expansion here....))

This is nice because in the file header you only have to require the
module that defines the macros, via: 
(eval-when (compile eval) (require "the-macros")) You don't have to
know where the runtime support lives, or use autoloading or anything.

There are almost no uses of (compile eval load) anywhere.

I am of the opinion that we should define what EVAL-WHEN does, and
not chuck it out in favor of new constructs, like EVAL-EARLY, etc.


...mike beckerle

∂12-Apr-88  1347	CL-Compiler-mailer 	archives  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 12 Apr 88  13:47:25 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA26559; Tue, 12 Apr 88 14:47:52 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8804122047.AA26559@cs.utah.edu>
Date: Tue, 12 Apr 88 14:47:49 MDT
Subject: archives
To: cl-compiler@sail.stanford.edu

Mail sent to cl-compiler is now being archived on cs.utah.edu, in the
file /v/tmp/spool/mail/cl-compiler.  If this file grows too humungous
I'll try to split it up into smaller pieces from time to time.

-Sandra
-------

∂06-May-88  1358	CL-Compiler-mailer 	nesting of EVAL-WHENs    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 6 May 88  13:58:06 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA26103; Fri, 6 May 88 14:58:39 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8805062058.AA26103@cs.utah.edu>
Date: Fri, 6 May 88 14:58:37 MDT
Subject: nesting of EVAL-WHENs
To: cl-compiler@sail.stanford.edu

I've been trying to write up some formal proposals to firm up what we
now seem to think is the "right" way to handle defining macros and
eval-when, and I've run into a problem with the semantics of nested
EVAL-WHENs.

From our Palo Alto meeting, there seemed to be some consensus that the
following kind of code should "work":

(eval-when (eval compile load)
    (let ((x  (some-hairy-computation)))
        (defmacro foo (y)
            `(+ ,x ,y))))

Namely, the macro function FOO should be closed over X, and since the value
of X is available at compile time everything should be hunky-dory.

According to our model of how the compiler treats top-level forms,
the defmacro itself expands into another eval-when, something like

(eval-when (eval compile load)
    (let ((x  (some-hairy-computation)))
        (eval-when (eval compile load)
            (setf (macro-function 'foo)
                #'(lambda (form env)
                      (let ((y  (second form)))
                          `(+ ,x ,y))))
	    'foo)))

So, here's the problem.  As I understand our latest spec on how
EVAL-WHEN works, the compiler will first evaluate the entire LET form
that binds X in the null lexical environment, and FOO will get the
"right" macro definition as a function closed over X.  Then, the
compiler will do the processing for the LOAD part of the EVAL-WHEN.  In
doing so, it will hit that nested EVAL-WHEN, see that COMPILE is
specified among the situations, and promptly redefine the macro
definition of FOO as a function in the null lexical environment which
is not closed over X.  Which isn't what we wanted to happen.

I thought of maybe saying that LOAD or EVAL processing of the body of
the EVAL-WHEN disables COMPILE processing of nested EVAL-WHENs in
the body.  This would be incompatible with the current behavior as
specified in CLtL, however, and I'm not sure that it would be generally
the right thing to do in other situations.  Alternatively, we could keep
the current restriction on macro functions always being defined in the
null lexical environment, but that would be difficult to explain using
our model of how defining macros work.

Anybody else have thoughts on this?

-Sandra
-------

∂07-May-88  0456	CL-Compiler-mailer 	nesting of EVAL-WHENs    
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 7 May 88  04:55:55 PDT
Received: by labrea.stanford.edu; Sat, 7 May 88 04:56:02 PDT
Received: from bhopal.lucid.com by edsel id AA13890g; Sat, 7 May 88 02:13:52 PDT
Received: by bhopal id AA05540g; Sat, 7 May 88 02:16:36 PDT
Date: Sat, 7 May 88 02:16:36 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805070916.AA05540@bhopal.lucid.com>
To: sandra@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Fri, 6 May 88 14:58:37 MDT <8805062058.AA26103@cs.utah.edu>
Subject: nesting of EVAL-WHENs

I'm going to need some more time to think about this question, but vaguely
I thought the model of eval-when processing tried to make sure that subforms
only got evaluated once when there were multiple applicable situations.
For the interior eval-when(eval compile load), the first evaluation during 
compilation is because of the EVAL situation in the outter eval-when; then
the second "potential" evaluation is during the compilation of the inner
eval-when, when it notices that it has the 'compile' situaiton.  Clearly
we need to insure that the eval-when model has a state that says:
   "compiling, but have already eval'd this"

-- JonL --

∂08-May-88  1246	CL-Compiler-mailer 	Re: nesting of EVAL-WHENs
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 8 May 88  12:45:57 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA03719; Sun, 8 May 88 12:37:57 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8805081837.AA03719@cs.utah.edu>
Date: Sun, 8 May 88 12:37:54 MDT
Subject: Re: nesting of EVAL-WHENs
To: Jon L White <edsel!jonl@labrea.stanford.edu>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Jon L White <edsel!jonl@labrea.stanford.edu>, Sat, 7 May 88 02:16:36 PDT

Hmmm.  I suppose we could say that if both COMPILE and LOAD are
specified in the outer EVAL-WHEN, when the compiler is processing the
body to spit out the code to do the LOAD evaluation, it should not do
any more compile-time evaluation of nested subforms.  This could be
modeled with our view of how EVAL-WHEN might be implemented as a macro
by having (EVAL-WHEN (COMPILE LOAD) ...) expand into a MACROLET, that
shadows EVAL-WHEN with a new definition which totally ignores the
COMPILE situation.

-Sandra
-------

∂09-May-88  0852	CL-Compiler-mailer 	proposals 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 9 May 88  08:52:42 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA22751; Mon, 9 May 88 09:53:17 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8805091553.AA22751@cs.utah.edu>
Date: Mon, 9 May 88 09:53:16 MDT
Subject: proposals
To: cl-compiler@sail.stanford.edu

You should be getting three proposals from me immediately following this
message.  I would like to get these proposals (or some modified version
of them) distributed to the full X3J13 committee at the June meeting, so
that they could be voted on at the meeting after that.  (It is probably
too late to hope for getting them up for a vote at the June meeting.)

So, please read them over.  All of the proposals could use more work on
the "current practice" and "cost to implementors" sections, so if you
vendors out there want to get your names mentioned :-), send mail.
I will put together revised versions to incorporate comments/complaints.

-Sandra
-------

∂09-May-88  0854	CL-Compiler-mailer 	issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 9 May 88  08:53:57 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA22789; Mon, 9 May 88 09:54:36 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8805091554.AA22789@cs.utah.edu>
Date: Mon, 9 May 88 09:54:35 MDT
Subject: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
To: cl-compiler@sail.stanford.edu


Issue:		COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
References:	CLtL pages 66-70, 143
Category:	CLARIFICATION
Edit history:   V1, 07 Oct 1987 Sandra Loosemore
                V2, 15 Oct 1987 Sandra Loosemore
                V3, 15 Jan 1988 Sandra Loosemore
		V4, 06 May 1988 Sandra Loosemore



Problem Description:

Standard programming practices assume that, when calls to defining
macros such as DEFMACRO and DEFVAR are compiled, certain side-effects
occur that affect how the compiler processes subsequent forms.
However, these side-effects are not mentioned in CLtL, except for a
passing mention that macro definitions must be ``seen'' by the
compiler before it can compile calls to those macros correctly. 


Proposal: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY

(1) Certain defining macros, appearing within a file being processed
by COMPILE-FILE, normally have compile-time side effects which affect
how subsequent forms in the same file are compiled.  The defining macros
and their specific side effects are as follows:
 
DEFTYPE:   Type names defined via DEFTYPE must be recognized as valid in
subsequent type declarations.
 
DEFMACRO, DEFINE-MODIFY-MACRO:  Macro definitions must be stored at compile
time, so that occurences of the macro later on in the file will be expanded
correctly.  The body of the macro (but not necesarily its expansion) must 
be evaluable at compile time.
 
DEFUN:  An implementation may choose to store information about the
function for the purposes of compile-time error-checking (such as checking
the number of arguments on calls).  Portable code should not rely on DEFUN
making the function definition available at compile time.
 
DEFVAR, DEFPARAMETER:  The compiler must recognize that the variables
named by these forms have been proclaimed special.  The initial value form
must not be evaluated at compile time.
 
DEFCONSTANT:  An implementation may choose to store information about the
variable for the purposes of compile-time error-checking (such as checking
for rebinding of or assignment to the variable).  If the initial value form
is a constant, an implementation may also choose to evaluate it at compile 
time for the purposes of constant-folding.
 
DEFSETF, DEFINE-SETF-METHOD:  SETF methods must be available during the
expansion of calls to SETF later on in the file.  The body of
DEFINE-SETF-METHOD and the complex form of DEFSETF must be evaluable at
compile time.
 
DEFSTRUCT:  The structure type name must be recognized as a valid type name
in declarations, as for DEFTYPE.  The structure slot accessors must be made
known to SETF.  In addition, further DEFSTRUCT definitions should be able
to :INCLUDE a structure type defined earlier in the file being compiled.
The functions which DEFSTRUCT generates, and the #S reader syntax, may or
may not be available at compile time.

(2) A model which explains how these compile-time side-effects happen is
that each defining macro expands into one or more EVAL-WHEN forms.  The
bodies of the EVAL-WHEN forms contain code which causes the appropriate
information to be stored.  Different information may be stored at
compile-time than when the defining macros are processed interpretively
or when the compiled file is loaded.

(3) The information stored by the defining macros at compile time may
or may not be available to the interpreter (either during or after
compilation), or during subsequent calls to COMPILE or COMPILE-FILE.
For example, the following code is nonportable because it assumes that the
compiler stores the macro definition of FOO where it is available to the
interpreter:

    (defmacro foo (x) `(car ,x))
    (eval-when (eval compile load)
        (print (foo '(a b c))))

A portable way to do the same thing would be to include the macro definition
inside the EVAL-WHEN:

    (eval-when (eval compile load)
        (defmacro foo (x) `(car ,x))
        (print (foo '(a b c))))



Rationale:

The proposal reflects standard programming practices.  The primary purpose
of the proposal is to make an explicit statement that CL supports the
behavior that most programmers expect and many implementations already
provide.


Current Practice:

Many (probably most) Common Lisp implementations, including VaxLisp and
Lucid Lisp, are already largely in conformance.  
 
Kyoto Common Lisp is a notable offender.  By default, KCL evaluates *all*
top level forms as they are compiled, which is clearly in violation of the
behavior specified on p 69-70 of CLtL.  There is a flag to disable the
compile-time evaluation, but then macros such as DEFMACRO, DEFVAR, etc. do
not make their definitions available at compile-time either.


Cost to implementors:

Making the defining macros expand into EVAL-WHENs to store the required
information is a simple and recommended implementation technique.


Cost to users:

Since CLtL does not specify whether and what compile-time side-effects
happen, any user code which relies on them is, strictly speaking,
nonportable.  In practice, however, most programmers already expect
the behavior described in this proposal and will not find it to be
an incompatible change.


Benefits:

Adoption of the proposal will provide more definite guidelines on how to
write programs that will compile correctly under all CL implementations.


Discussion:

Reaction to an earlier version of this proposal on the CL mailing list was
overwhelmingly positive.

The only major criticism of this proposal I have heard is that it should
also include PROCLAIM.  However, since PROCLAIM is not a macro, its
compile-time side effects cannot be handled using the same mechanism.
A separate proposal seems more appropriate.

-------

∂09-May-88  0855	CL-Compiler-mailer 	issue EVAL-WHEN-NON-TOP-LEVEL 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 9 May 88  08:54:55 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA22855; Mon, 9 May 88 09:55:34 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8805091555.AA22855@cs.utah.edu>
Date: Mon, 9 May 88 09:55:33 MDT
Subject: issue EVAL-WHEN-NON-TOP-LEVEL
To: cl-compiler@sail.stanford.edu


Issue:		EVAL-WHEN-NON-TOP-LEVEL
References:	CLtL p. 69-70
		Issue DEFINING-MACROS-NON-TOP-LEVEL
Category:	CLARIFICATION, ENHANCEMENT
Edit History:   6-May-88, V1 by Sandra Loosemore


Problem Description:

The current description of how the compiler should handle EVAL-WHEN
only makes sense when it appears as a top-level form in the file being
compiled.  Other proposals being considered by the compiler cleanup
committee require that we clarify how the compiler should process
EVAL-WHENs appearing at non-top-level, such as within LET or FUNCTION
special forms. 


Proposal:  EVAL-WHEN-NON-TOP-LEVEL:CLARIFY

There are three possible processing situations which may be specified
in EVAL-WHEN.  The interpreter pays attention to only the EVAL
situation, while the LOAD and COMPILE situations are handled by the
compiler. 

The EVAL situation corresponds to the normal processing of the
interpreter.  If EVAL is specified, the interpreter evaluates each
form in the body of the EVAL-WHEN as an implicit PROGN, using the
current lexical environment.  If the EVAL situation is not specified,
then the interpreter must return NIL as the value of the EVAL-WHEN
form, without evaluating the body. 

The LOAD situation corresponds to the normal processing of the
compiler.  To the compiler, (EVAL-WHEN (LOAD) ...) is equivalent to a
PROGN form; the compiler simply arranges for the body to be
``evaluated'' in the lexical environment in which the EVAL-WHEN form
appears.  If the LOAD situation is not specified, the compiler
arranges for the EVAL-WHEN form to return a value of NIL without
evaluating the body forms.  (The name LOAD is something of a misnomer,
because ``evaluation'' happens not at LOAD time, but when the
EVAL-WHEN form would normally be ``evaluated''.  For example, if an
EVAL-WHEN form appears in the body of a DEFUN, it is ``evaluated''
when that function is called.)

The EVAL and LOAD situations are therefore quite similar and
correspond to normal evaluation semantics.  That is, one could
consider that each form and nested subform is implicitly wrapped with
an (EVAL-WHEN (EVAL LOAD) ...). 

The COMPILE situation indicates that the compiler itself should
evaluate the body of the EVAL-WHEN form as an implicit PROGN in the
null lexical environment.  During the evaluation, if a nested
EVAL-WHEN appears in the body, the interpreter follows its usual rule
of checking only whether or not the EVAL situation is specified to
decide whether or not the body of the nested EVAL-WHEN should be
processed. 

If both the COMPILE and LOAD situations are specified, the compiler
first performs the evaluation for the COMPILE situation.  Then, the
normal processing for the LOAD situation takes place, except that the
compile-time evaluation of nested (EVAL-WHEN (COMPILE) ...) forms in
the body is suppressed, preventing repeated evaluations of subforms.

(EVAL-WHEN (COMPILE) ...) should be used with caution in non-top-level
situations.  For example, if the following appears as a top level form
in a file being compiled

    (let ((x  (some-hairy-computation)))
        (eval-when (eval compile load) (print x)))

the variable X will be treated as special during the compile-time
evaluation, and the value printed will be its symbol-value.  To
guarantee consistency between compile-time evaluation and the normal
processing, one should wrap the entire top-level form in an EVAL-WHEN,
as follows:

    (eval-when (eval-compile load)
        (let ((x  (some-hairy-computation)))
	    (print x)))


Rationale:

The behavior of top-level EVAL-WHENs as specified in this proposal
remains almost identical to that specified in CLtL.  The major
addition is specifying the lexical environment in which non-top-level
EVAL-WHENs are processed.  It is clear that the COMPILE situation must
always be processed in the null lexical environment, since the actual
lexical environment is not available at compile time.  Having the EVAL
and LOAD situations evaluate in the proper environment leads to
differing semantics, but it appears to be the behavior that most
people expect.

Suppression of COMPILE evaluations in nested EVAL-WHENs is necessary
to achieve certain desirable behaviors, such as the macro example in
section 4 of the DEFINING-MACROS-NON-TOP-LEVEL proposal.


Current Practice:


Cost to implementors:

Probably fairly minor in most implementations.  

As an implementation technique, we suggest implementing EVAL-WHEN as a 
macro which uses a state variable (rebound by EVAL, COMPILE, and
COMPILE-FILE) to keep track of the current context.

    (defmacro eval-when (situations &body body)
        (cond ((null *compiling-p*)
               (if (member 'eval situations)
                   `(progn ,@body)
                   'nil))
              ((and (member 'compile situations) (member 'load situations))
               (eval `(progn ,@body))
               `(macrolet ((eval-when (situations &body body)
                               (if (member 'load situations)
                                   `(progn ,@body)
                                   'nil)))
                    ,@body))
              ((member 'compile situations)
               (eval `(progn ,@body))
               'nil)
              ((member 'load situations)
               `(progn ,@body))
              (t 'nil)))


Cost to users:

Since CLtL does not currently specify what the meaning of EVAL-WHEN
forms at non-top-level is, existing code which depends on their use is
already nonportable.  Preventing repeated evaluations of subforms when
EVAL-WHENs are nested is unlikely to cause any serious compatibility
problems, since the current model would already result in only a
single evaluation in the case when the code is processed
interpretively.


Benefits:

Clarifying the meaning of EVAL-WHEN allows the behavior of defining
macros such as DEFMACRO to be specified in terms of EVAL-WHEN.  As a
side effect, it would then become meaningful for defining macros to
appear at other than top-level. 


Discussion:

This proposal reflects what appears to be the consensus of the
compiler cleanup committee on this issue.

-------

∂09-May-88  0856	CL-Compiler-mailer 	issue DEFINING-MACROS-NON-TOP-LEVEL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 9 May 88  08:56:13 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA22960; Mon, 9 May 88 09:56:53 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8805091556.AA22960@cs.utah.edu>
Date: Mon, 9 May 88 09:56:50 MDT
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL
To: cl-compiler@sail.stanford.edu


Issue:		DEFINING-MACROS-NON-TOP-LEVEL
References:	CLtL p. 66-70, 143
		Issue EVAL-WHEN-NON-TOP-LEVEL
		Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Category:	CLARIFICATION, ENHANCEMENT
Edit History:   6-May-88, V1 by Sandra Loosemore


Problem Description:

CLtL leaves the interpretation of defining forms such as DEFMACRO and
DEFVAR that appear in other than top-level locations unspecified.
Resolution of other issues (EVAL-WHEN-NON-TOP-LEVEL and
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS) now allows reasonable
semantics to be assigned to defining forms which appear at
non-top-level.


Proposal: DEFINING-MACROS-NON-TOP-LEVEL:ALLOW

(1) Clarify that while defining macros normally appear at top level,
it is meaningful to place them in non-top-level contexts and that the
compiler must handle them properly in all situations.  Remove the
language on p. 66 of CLtL which states that the compiler is not
required to recognize defining macros at other than top-level.

(2) The proposal COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
defines a model for specifying how defining macros work.  To
summarize, the expansion of the macro (rather than its expander
function) is responsible for storing information about the definition.
Compile-time side effects are typically handled by including one or
more EVAL-WHEN forms in the expansion.  Although a compiler may choose
some other implementation, such as treating defining macros as
implementation-specific special forms, the semantics must remain the
same.

(3) Defining macros which define functional objects (such as DEFUN and
DEFMACRO) must ensure that the functions are defined in the lexical
environment in which the defining macro appears.  In the model
referred to above, this would normally be implemented by producing a
FUNCTION special form in the macro expansion.  For example, the
following code causes the function BAR to be closed over the variable
X:

    (let ((x  (some-hairy-computation)))
        (defun bar (y) (+ x y)))

(4) The language on p. 145 of CLtL, which states that macro functions
are defined in the null lexical environment, should be removed.
Instead, defining forms such as DEFMACRO which make a functional
definition available at the compile time use the environment must
normally appear inside an explicit (EVAL-WHEN (COMPILE) ...) to ensure
that the correct lexical environment is seen. 

An example may help clarify why this is necessary.  The code fragment

    (let ((x  (some-hairy-computation)))
        (defmacro bar-macro (y) `(+ ,x ,y)))

would macroexpand into something similar to

    (let ((x  (some-hairy-computation)))
        (eval-when (eval compile load)
            (setf (macro-function 'bar-macro) 
	          #'(lambda (form env)
		        (let ((y  (second form)))
			    `(+ ,x ,y))))
            'bar-macro))

Since the rules for (EVAL-WHEN (COMPILE) ...) state that evaluation takes
place in the null lexical environment, in this situation X would be treated
as a special variable within the macro function.  However, in the EVAL or 
LOAD situations, the lexical value of X would be used.  To ensure 
consistency, the correct definition would be:

    (eval-when (eval compile load)
        (let ((x  (some-hairy-computation)))
            (defmacro bar (y) `(+ ,x ,y))))


Rationale:

The notion of a ``top-level form'' is rather confused.  There has been
a suggestion that the notion of a top-level form should be extended to
include forms in the body of a top-level LET, to allow forms such as
DEFUN to be meaningful there.  However, we feel that a cleaner
solution is to remove the restrictions on the placement of defining
macros altogether.


Current Practice:


Cost to implementors:


Cost to users:

None.  This is a compatible extension.


Benefits:

The notion of top-level forms as being somehow special is removed from
the language.  Allowing defining macros to appear anywhere instead of
restricting them to certain positions results in a cleaner language
design.


Discussion:

-------

∂10-May-88  2314	CL-Compiler-mailer 	subcommittee meeting(s)  
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 10 May 88  23:14:11 PDT
Received: by ucbarpa.Berkeley.EDU (5.59/1.28)
	id AA11863; Tue, 10 May 88 23:14:03 PDT
Received: by franz (5.5/3.14)
	id AA13520; Tue, 10 May 88 22:29:34 PDT
Received: by feast (5.5/3.14)
	id AA01569; Wed, 11 May 88 01:20:30 EDT
Date: Wed, 11 May 88 01:20:30 EDT
From: franz!feast!smh@ucbarpa.Berkeley.EDU (Steven M. Haflich)
Message-Id: <8805110520.AA01569@feast>
To: cl-compiler@sail.stanford.edu
Subject: subcommittee meeting(s)

  Time to schedule the compiler-cleanup subcommittee for June X3J13.
Last time in Palo Alto we actually made some progress.  Now we need to
continue towards real written proposals.  Be there or be interpreted!
  Scheduling is tricky, as ever, paarticular acommodating travel for
out-of-towners.  Several of us are involved with the Definition Specs
meeting 3:00-5:30 Tuesday.  We probably need a fair amount of time to
work through details -- a single 2-3 hour meeting probably wouldn't be
enough.  So either we schedule a single long meeting, or two shorter
ones.
  I would be very happy with a Tuesday evening meeting and a Thursday
evening or Friday morning meeting.  This might be convenient for
out-of-towners.  (I *think* I would be able to find a meeting place,
assuming Symbolics might not be available outside office hours.)  The
alternative would be to start early Tuesday, but this would require an
extra night for West Coast people.
  If you have particular travel and/or time restrictions, please
respond asap so I can work out the details.  If I *don't* hear, I'll
just make an arbitrary decision.

∂12-May-88  1826	CL-Compiler-mailer 	subcommittee meeting(s)  
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 12 May 88  18:25:54 PDT
Received: by labrea.stanford.edu; Thu, 12 May 88 18:12:48 PDT
Received: from bhopal.lucid.com by edsel id AA09585g; Thu, 12 May 88 18:17:42 PDT
Received: by bhopal id AA23990g; Thu, 12 May 88 18:20:46 PDT
Date: Thu, 12 May 88 18:20:46 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805130120.AA23990@bhopal.lucid.com>
To: franz!feast!smh@ucbarpa.berkeley.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Steven M. Haflich's message of Wed, 11 May 88 01:20:30 EDT <8805110520.AA01569@feast>
Subject: subcommittee meeting(s)

Since traving West-to-East means a three-hour time shift in the "wrong"
direction, I strongly prefer late-afternoon and evening meetings to
any morning meetings.

-- JonL --

∂16-May-88  1244	CL-Compiler-mailer 	Re: COMPILE-FILE-OF-TOP-LEVEL-FORMS
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 16 May 88  12:44:39 PDT
Date: 16 May 88 15:32:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: Re: COMPILE-FILE-OF-TOP-LEVEL-FORMS
To: "cl-compiler" <cl-compiler@sail.stanford.edu>
cc: vanroggen   
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>

It's good to some of these things written down.  Here are my comments
so far...

I think the issue name is a bit too general--how about
COMPILE-FILE-OF-DEFINING-MACROS, since it just talks about
DEFxxx forms, with the "top-level" assumed.

If we don't want to address inter-file dependencies in this issue,
we should say so explicitly.

Although this is an issue that comes with PROCLAIM, it's probably
worthwhile mentioning that when COMPILE-FILE sees a DEFUN, it may
decide to keep the body of the function around due to INLINE
proclamations.  VAX LISP requires INLINE proclamations to come
before the corresponding DEFUNs, because we don't want to keep around
all the source code ever seen just in case an INLINE proclamation/declaration
might come much later.

  "If the initial value form [of a DEFCONSTANT] is a constant, an
   implementation may also choose to evaluate it at compile time for
   the purposes of constant-folding."
Firstly, if the value is a constant, it may be evaluated at any time--
so this sentence doesn't say much.  [Or is the referent of "it" the
DEFCONSTANT expression?]  Secondly, I think it's more important to state
what an implementation -cannot- do, much as was stated for DEFVAR.
I think of DEFCONSTANT and DEFPARAMETER being very similar, except that
constants can't be set or bound.  I don't see why that would suddenly
allow the compiler to evaluate the inital value form at compile time.
So we should say that the initial value form must not be evaluated at
compile time.

For DEFSETF and DEFINE-SETF-METHOD, add the comment (as is included
for DEFMACRO) that the expansion needn't be evaluable at compile time.

Question: must the expansion of a DEFTYPE be a legitimate type at compile
time?

			---Walter
------

∂16-May-88  2307	CL-Compiler-mailer 	issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS    
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 16 May 88  23:07:21 PDT
Received: by labrea.stanford.edu; Mon, 16 May 88 23:07:44 PDT
Received: from bhopal.lucid.com by edsel id AA28744g; Mon, 16 May 88 22:57:04 PDT
Received: by bhopal id AA03382g; Mon, 16 May 88 23:00:22 PDT
Date: Mon, 16 May 88 23:00:22 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805170600.AA03382@bhopal.lucid.com>
To: sandra@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 9 May 88 09:54:35 MDT <8805091554.AA22789@cs.utah.edu>
Subject: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS

One thing bothers me muchly about this proposal -- it re-inforces the old
MacLisp notion of "specially noticing" certain forms at top level without
evaluating them; in particular the MacLisp Compiler had a separate database
which held macro definitions "noticed" in the file being compiled, but
which hadn't been explicitly evaluated.

What I particularly dislike is the half-supported status of "noticed" things;
why will a macro be expandable by the compiler but not by the interpreter?  
The many ways in which things can be "noticed", and the meaning of "notice",
is very opaque.

Instead, I'd prefer the issue to be simply "To Evaluate, or Not to
Evaluate, That Is the Question".  In short, every form should fall
into one of four categories:
  (1) Function definition, in which case not only is the body compiled
      but the compiler is permitted to "remember" certain aspects of
      the function, such as argument spectrum for subsequent user-friendly
      warning messages, and such as source-code for subsequent INLINEing.
      [Macro definitions can come under this clause too; but they could
      also be listed both in (1) and (2).]
  (2) Explicitly-listed form that is implicitly eval-when(eval compile load);
      "implicitly" means, "if the user didn't wrap an eval-when around it,
      then the compiler puts the 'implicit' one in;" however, any user
      supplied eval-when overrides this implicit behaviour.  There is already
      a precedent with several of the "Seven Extremely Randoms".
  (3) An EVAL-WHEN form; explicit semantics for such toplevel forms will be 
      forthcoming; anyway, it ought to be obvious.
  (4) Any other form not in (1) through (3); such is merely compiled and 
      "shoved" out into the compiler output file.
Because of the need to treat IN-PACKAGE and possibly other "7 randoms"
this way, I don't think we could every reduce (2) to the null set.  I admit
that putting too many functions in it would confuse things (making it
harder to remember just what was there).  But for starters, why not
all the DEF... forms you listed in your proposal, except for DEFUN and
DEFVAR (and DEFPARAMETER, which is a trivial variant of DEFVAR).  This 
would mean every CLtL DEF... form (except for the exceptions) is implicitly 
evaluated during compilation; when this is undesirable, the user would have 
the burden of explicitly wrapping eval-when (eval load) around the form.

I fear that my simplified proposal is what you initially offered a long
time ago, and were beaten back on.  But I offer my support for it now,
if clarifying is what you want to do.


-- JonL --

∂17-May-88  0739	CL-Compiler-mailer 	Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 May 88  07:39:32 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA24901; Tue, 17 May 88 08:39:05 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8805171439.AA24901@cs.utah.edu>
Date: Tue, 17 May 88 08:39:04 MDT
Subject: Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
To: edsel!jonl@labrea.stanford.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Jon L White <edsel!jonl@labrea.stanford.edu>, Mon, 16 May 88 23:00:22 PDT

  Date: Mon, 16 May 88 23:00:22 PDT
  From: Jon L White <edsel!jonl@labrea.stanford.edu>

  One thing bothers me muchly about this proposal -- it re-inforces the old
  MacLisp notion of "specially noticing" certain forms at top level without
  evaluating them; in particular the MacLisp Compiler had a separate database
  which held macro definitions "noticed" in the file being compiled, but
  which hadn't been explicitly evaluated.

That situation was exactly what this proposal (actually group of
proposals) was trying to get rid of, not re-inforce.  The compiler need
not do any "special noticing" of these defining macros at all, because
the model Steve and I have proposed is that the macros expand into
EVAL-WHENs to wrap the actions that should be performed at
compile-time.  All the compiler needs to recognize is EVAL-WHEN (and the
N ugly package functions). The actions, such as storing macro
definitions, may be (but are not required to be) handled identically in
both the interpreter and the compiler.

  What I particularly dislike is the half-supported status of "noticed" things;
  why will a macro be expandable by the compiler but not by the interpreter?  

I don't understand this.  The compiler must expand all the macros it runs
across, and so must the interpreter.

The big problem I have with your simplified counterproposal is that few
(if any) implementations already work that way, and I do not believe
that the behavior it specifies is what users really want or expect to
happen.

-Sandra
-------

∂17-May-88  2241	CL-Compiler-mailer 	issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS    
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 17 May 88  22:41:40 PDT
Received: by labrea.stanford.edu; Tue, 17 May 88 22:42:08 PDT
Received: from bhopal.lucid.com by edsel id AA03485g; Tue, 17 May 88 22:30:18 PDT
Received: by bhopal id AA07755g; Tue, 17 May 88 22:33:43 PDT
Date: Tue, 17 May 88 22:33:43 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805180533.AA07755@bhopal.lucid.com>
To: sandra@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 17 May 88 08:39:04 MDT <8805171439.AA24901@cs.utah.edu>
Subject: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS

re: That situation was exactly what this proposal (actually group of
    proposals) was trying to get rid of, not re-inforce.   ...
    the model Steve and I have proposed is that the macros expand into
    EVAL-WHENs to wrap the actions that should be performed at
    compile-time.  

Gleeep!  I've completly misread the intent of your proposal.  I believe
I misread it because the first n paragraphs of your PROPOSAL: section
reads like a problem description.  Two things need to be done (so I
think) to clarify this: (1) very early mention that this is what you
want to happen -- that compiler "noticing" is merely reduced to usages
of EVAL-WHEN; (2)  be much more specific as to what gets EVALuated at
compile time -- the listing of desirable effects in the "proposal" 
section is ok, but not specific enough to believe that they are all
being accomplished via normal EVAL-WHEN(...COMPILE...).

re:     What I particularly dislike is the half-supported status of "noticed" 
        things; why will a macro be expandable by the compiler but not by the 
        interpreter?  
    I don't understand this.  The compiler must expand all the macros it runs
    across, and so must the interpreter.

Well you yourself added the phrase:

    The actions, such as storing macro definitions, may be (but are not 
    required to be) handled identically in both the interpreter and the 
    compiler.

and it is this uncertainty about "not required to be" -- about the non-
equivalence of EVAL and EVAL-WHEN(...COMPILE...) -- that bothers me.


True, no implementation operates exactly like my simplified counter.  But 
they are not far from it.  Probably most are in accord with it on DEFUN,
DEFVAR, and DEFPARAMETER; and Lucid is in accord also on DEFCONSTANT,
DEFMACRO, and DEFTYPE.  Also Lucid is "mostly" in accord on DEFSTRUCT in 
that it does exactly the same thing as evaluating the defstruct, but doesn't 
actually install anything in the symbol-function cells (i.e., it makes
the TYPE entry, makes compiler macros for the functions etc.).

The hardest "pill" to swallow is to decide to make DEFSTRUCT, DEFMACRO, 
and DEFTYPE implicitly eval-when(eval compile load) Actually, the 
"simplified counter" doesn't depend on which of the varous forms are 
promoted to the "implicit" status and which aren't -- it merely tries to 
make a uniform interpretation when interpreting and compileing forms that 
affect the compilation process.


-- JonL --

∂18-May-88  1104	CL-Compiler-mailer 	issue EVAL-WHEN-NON-TOP-LEVEL 
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 18 May 88  11:04:00 PDT
Received: by labrea.stanford.edu; Wed, 18 May 88 02:14:56 PDT
Received: from bhopal.lucid.com by edsel id AA04028g; Wed, 18 May 88 01:59:26 PDT
Received: by bhopal id AA08279g; Wed, 18 May 88 02:02:52 PDT
Date: Wed, 18 May 88 02:02:52 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805180902.AA08279@bhopal.lucid.com>
To: sandra@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 9 May 88 09:55:33 MDT <8805091555.AA22855@cs.utah.edu>
Subject: issue EVAL-WHEN-NON-TOP-LEVEL

The early part of the Proposal: section probably ought to outline our
intent in giving ordinary macro semantics to EVAL-WHEN -- it is so that 
an piece of source code will either be "processed" as if the body of the 
eval-when is there, or as if it were not there, depending on the dynamic 
state of the processor:


    Original Source    |    Situation Applies   |  Situation Doesn't Apply
-----------------------+------------------------+----------------------------
                       |                        |
  (defun foo (x)       |     (defun foo (x)     |     (defun foo (x)     
    (step1 x)          |       (step1 x)        |       (step1 x)
    (eval-when (...)   |       (step2 x)        |       nil
      (step2 x))       |       (step2 x))       |       (step3 x))
    (step3 x))         |                        |

On can infer this from a careful reading of the proposal, but the 
overwhelming simplicity of making eval-when a small macro is lost "in the 
woods".  This top-level view of the proposal ought to be said very early 
in the proposal, rather than starting out with a myriad of details about 
how the various situations are treated.

I note also that you implicitly assume a dynamic variable *compiling-p*?
This will have to be spelled out in detail, much as in my note of
25 Mar 88 23:21:23 PST "Eval-When -- a radical view";  simply being
"in the compiler" isn't enough since EVAL may have to bind this variable
to nil (or do the equivalent -- Rob points out that we don't really
want to tie down the implementation to an actual dynamic variable, but
rather to the semantics give by the example code).

I very much like the idea of shadowing eval-when with a macrolet in the
situation where there might be nested eval-when's and the outter one has 
at least a 'compile' situation.  In fact, the trial code I sent out in
the msg "Eval-When -- a radical view" doesn't work right;  the attempt
to identify this circumstance with a dynamic binding of a state variable 
(to :eval-before-compile) is wrong, since it really is a lexical effect 
that is needed, not a dynamic one.

Finally, I had a bit of trouble following all the logic in all the 
cond clauses of the sample defmacro for EVAL-WHEN.   Could I offer a 
rewrite, with effusive commentary, that breaks it down into basically
two cases: the "hard" case (presented first) and the "easy" one.

    (defmacro eval-when (situations &body body)
      (cond ((and *compiling-p*
		  (member 'compile situations))
	      ;; Situation Applies: The hard case.  Compiling, and evaluation
	      ;;  is required at compile time too.
	     (eval `(progn ,@body))
	     (if (member 'load situations)
		  ;; Allow normal processing by 'compile-form-to-file',
		  ;;  except ignore sub requests for compile-time evaluation.
		  `(macrolet ((eval-when (situations &body body)
			       (if (member 'load situations)
				   `(PROGN ,@body)
				   'NIL)))
		    ,@body)
		  ;; or skip processing by 'compile-form-to-file'
		  `NIL))
	    ((if *compiling-p*
		 (member 'load situations)
		 (member 'eval situations))
	      ;; Situation Applies: The easy case.  Just return the body code 
	      ;;  for normal processing by 'eval' or 'compile-form-to-file'.
	     `(PROGN ,@body))
	    (t 
	      ;; Hmmm, 'situation' just doesn't apply!
	     `NIL)))



-- JonL --

∂18-May-88  1152	CL-Compiler-mailer 	proposals 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 18 May 88  11:52:03 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA29255; Wed, 18 May 88 08:55:04 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8805181455.AA29255@cs.utah.edu>
Date: Wed, 18 May 88 08:55:03 MDT
Subject: proposals
To: cl-compiler@sail.stanford.edu

Unless I hear any objections Real Soon Now, I'm going to write up revised
versions of the proposals I sent out before to incorporate the suggestions
I've received and clean up the wording.  I hope to be able to get them out
by the weekend.

-Sandra
-------

∂19-May-88  1012	CL-Compiler-mailer 	subcommittee meeting(s)  
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 19 May 88  10:12:27 PDT
Received: by ucbarpa.Berkeley.EDU (5.59/1.28)
	id AA01979; Thu, 19 May 88 10:11:41 PDT
Received: by franz (3.2/3.14)
	id AA05387; Thu, 19 May 88 10:03:41 PDT
Received: by feast (5.5/3.14)
	id AA00668; Thu, 19 May 88 12:54:04 EDT
Date: Thu, 19 May 88 12:54:04 EDT
From: franz!feast!smh@ucbarpa.Berkeley.EDU (Steven M. Haflich)
Message-Id: <8805191654.AA00668@feast>
To: franz!cs.utah.edu!sandra
Cc: franz!sail.stanford.edu!cl-compiler
In-Reply-To: Sandra J Loosemore's message of Wed, 18 May 88 09:03:42 MDT <8805181503.AA29510@cs.utah.edu>
Subject: subcommittee meeting(s)

   From: fridge!ucbarpa!cs.utah.edu!sandra (Sandra J Loosemore)

   On the assumption that we will be meeting on Tuesday evening and on
   Friday, I've arranged to arrive late Tuesday afternoon.  (I will actually
   be staying until Sunday morning with the idea of spending all day Saturday
   visiting the local bookstores....)

Hereby announced.  Meetings will be Tuesday evening and Friday
morning, unless someone makes a compelling counterproposal.  I'll
further suggest that those of us who can should start Tuesday over
dinner at one of the many fine but reasonably-priced eating
establishments in Cambridge.  It would be useful to know when people
become available so we can pick exact times, but there's no urgency.

It's been overheard from the Character Subcommittee that evening
meetings at Symbolics are impossible because of security.  Therefore
I've arrange with Greenblatt to use a conference room at Gigamos.
Gigamos easy to get to -- it is within long walking distance of
Symbolics, and just steps from the Central Square subway stop.  I'll
post directions etc. later.

P.S.: Right now someone is working on franz's mailer, and it sometimes
generates bogus return addresses.  No problem -- I'll still receive
anything cc'd to cl-compiler@sail.

∂20-May-88  0825	CL-Compiler-mailer 	issue EVAL-WHEN-NON-TOP-LEVEL 
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 20 May 88  08:25:46 PDT
Date: 20 May 88 11:19:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: issue EVAL-WHEN-NON-TOP-LEVEL
To: "cl-compiler" <cl-compiler@sail.stanford.edu>
cc: vanroggen   
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>

Overall, this proposal looks pretty good, if a clarification and "compatible"
extension is what we want.

I think that in addition to specifying the environments for the different
situations, the major change in this proposal may appear to be the meaning of
the LOAD situation.  I would like to believe that the intent of the LOAD
situation has always been to make the body of the EVAL-WHEN be compiled, not
the more obvious intent (judging by the name) of EVALuating the body when the
compiled file is being LOADed.

The latter interpretation is perfectly consistent with the former as long as
the EVAL-WHEN is at top-level in the file. Since we want to assign a meaning to
EVAL-WHEN when not at top-level, the former interpretation makes more sense and
would be compatible between the old and the new semantics.

Another reason why this interpretation is necessary is that non-top-level
EVAL-WHEN's ought to work fine when COMPILE is being used to compile
functions, not just when used in files being processed by COMPILE-FILE.

I believe that explicitly stating this interpretation will make it easier
for people to understand why the LOAD situation doesn't mean what they may
think it means.  Although I believe my interpretation is what you mean to
say in
  To the compiler, (EVAL-WHEN (LOAD) ...) is equivalent to a
  PROGN form; the compiler simply arranges for the body to be
  ``evaluated'' in the lexical environment in which the EVAL-WHEN form
  appears.
it might still not be clear to some readers.  [But the macro definition
of EVAL-WHEN helps a lot.]  Perhaps a historical note about compilers
normally being file compilers will help also.

The related thing which people might be confused with is what happens
with "#,".  The reason why I suggested this proposal, which I agree with,
might not be sufficient is that it doesn't address the ability to
evaluate forms at LOAD time.  But maybe this proposal along with another
one to add a special form to do LOAD-time evaluation for side-effects
and constant-values will be acceptable.


A major nit (!?): Isn't there a cleanup proposal to disallow lexically
binding special-forms in FLET, LABELS, and MACROLET?  If so, your
EVAL-WHEN macro is doing a no-no.  You might want to change the statement
from "suggested implementation technique" to "implemented as if".

For the Current Practice section, VAX LISP implements the proposed
changes already, except that it doesn't always substitute NIL when the
situation doesn't apply.  (There are times when the whole form just
disappears rather than returning NIL.)

			---Walter
------

∂20-May-88  1158	CL-Compiler-mailer 	Re: issue EVAL-WHEN-NON-TOP-LEVEL  
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 20 May 88  11:58:12 PDT
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU; 20 May 88 14:59:54 EDT
To: sandra@cs.utah.edu (Sandra J Loosemore)
cc: cl-compiler@sail.stanford.edu
Subject: Re: issue EVAL-WHEN-NON-TOP-LEVEL 
In-reply-to: Your message of Mon, 09 May 88 09:55:33 -0600.
             <8805091555.AA22855@cs.utah.edu> 
Date: Fri, 20 May 88 14:59:13 EDT
From: Rob.MacLachlan@WB1.CS.CMU.EDU


This is a reasonable approach to making EVAL-WHEN well defined, but there
seems to be a problem when the COMPILE situation is specified without the
EVAL situation.  In this form, I believe (FOO) would never be evaluated in
any context, which is definitely an incompatible change:
    (eval-when (compile)
      (eval-when (compile)
	(foo)))

Admittedly, I have argued in the past that it is never meaningful to
specify the COMPILE situation without the EVAL situation, but if the intent
is to fix up EVAL-WHEN, then we should attempt to be as compatible as
possible.

But perhaps this is worked around by the usage of *in-the-compiler*?  It
definitely needs to be made clearer what exactly is being done with that
varaible where.  But if my above interpretation of nested uses of the
COMPILE situation is incorrect, then the text description should also be
changed, since it seems to be consistent with my interpretation.

As far as explanation of what EVAL-WHEN does, I think there should be
explicit mention of the fact that only the outermost use of the COMPILE
situation nulls the evaluation environment.  This implied by the sample
implementation, and is exploited by your DEFMACRO environment example, but
should be made more explicit.

I agree with Jonl's remarks about the presentation of the proposal.

  Rob

∂20-May-88  1208	CL-Compiler-mailer 	Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS     
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 20 May 88  12:08:19 PDT
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU; 20 May 88 15:09:55 EDT
To: sandra@cs.utah.edu (Sandra J Loosemore)
cc: cl-compiler@sail.stanford.edu
Subject: Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS 
In-reply-to: Your message of Mon, 09 May 88 09:54:35 -0600.
             <8805091554.AA22789@cs.utah.edu> 
Date: Fri, 20 May 88 15:09:45 EDT
From: Rob.MacLachlan@WB1.CS.CMU.EDU


This is a fair summary of current practice, but I would rather push through
a proposal that is more aggressive in defining the exact effects of
compiler processing.

Like Jonl, I favor saying that forms like DEFMACRO are actually truly,
honest to God evaluated by the compiler.  This could be done by an
expansion that includes an EVAL-WHEN, but it should be required that all
Common Lisp semantics of evaluation of that defining form should be present
in the compiler environment after the implicit evaluation.

It could be a bit icky actually installing the DEFSTRUCT slot accessors,
but this could be finessed by pretending that the slot accessors expand to
DEFUNs outside of the EVAL-WHEN.

I strongly, totally, completely disagree with VanRoggen's remarks about
DEFCONSTANT.  From my perspective, the reason for DEFCONSTANT is permissive
rather restrictive.  You define constants so that the compiler can use
information about that name at compile time.  I believe that DEFCONSTANT
should also be implicitly evaluated at compile time.  This means that the
value form *must always* be evaluable at compile time.  This is a slight
departure from current practice, but a sensible and useful one.

  Rob

∂20-May-88  1229	CL-Compiler-mailer 	Re: issue EVAL-WHEN-NON-TOP-LEVEL  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 May 88  12:29:53 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA05454; Fri, 20 May 88 13:29:59 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8805201929.AA05454@cs.utah.edu>
Date: Fri, 20 May 88 13:29:58 MDT
Subject: Re: issue EVAL-WHEN-NON-TOP-LEVEL 
To: Rob.MacLachlan@wb1.cs.cmu.edu
Cc: sandra@cs.utah.edu (Sandra J Loosemore), cl-compiler@sail.stanford.edu
In-Reply-To: Rob.MacLachlan@WB1.CS.CMU.EDU, Fri, 20 May 88 14:59:13 EDT

> Date: Fri, 20 May 88 14:59:13 EDT
> From: Rob.MacLachlan@WB1.CS.CMU.EDU
> 
> This is a reasonable approach to making EVAL-WHEN well defined, but there
> seems to be a problem when the COMPILE situation is specified without the
> EVAL situation.  In this form, I believe (FOO) would never be evaluated in
> any context, which is definitely an incompatible change:
>     (eval-when (compile)
>       (eval-when (compile)
> 	  (foo)))

Yes, you are correct that under the current proposal, (foo) would never
be evaluated.  I do not think it is "definitely" an incompatible change,
however.  The current wording in CLtL seems to leave this behavior
unspecified and I don't know what the original intention was.

-Sandra
-------

∂20-May-88  1303	CL-Compiler-mailer 	Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS     
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 May 88  13:03:39 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA06503; Fri, 20 May 88 14:03:57 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8805202003.AA06503@cs.utah.edu>
Date: Fri, 20 May 88 14:03:55 MDT
Subject: Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS 
To: Rob.MacLachlan@wb1.cs.cmu.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Rob.MacLachlan@WB1.CS.CMU.EDU, Fri, 20 May 88 15:09:45 EDT

> Date: Fri, 20 May 88 15:09:45 EDT
> From: Rob.MacLachlan@WB1.CS.CMU.EDU
> 
> Like Jonl, I favor saying that forms like DEFMACRO are actually truly,
> honest to God evaluated by the compiler.  This could be done by an
> expansion that includes an EVAL-WHEN, but it should be required that all
> Common Lisp semantics of evaluation of that defining form should be present
> in the compiler environment after the implicit evaluation.
> 
> It could be a bit icky actually installing the DEFSTRUCT slot accessors,
> but this could be finessed by pretending that the slot accessors expand to
> DEFUNs outside of the EVAL-WHEN.

These two paragraphs seem mutually contradictory.  If you want to make
all of the defining macros implicitly EVAL-WHEN (EVAL COMPILE LOAD), like
the N random package functions, then you're going to get the defstruct
slot accessor functions defined at compile time, too.  If you want the
defining macros to make some things available at compile time and other
things not, I think you either have to use EVAL-WHEN in the expansion
or have the compiler treat every one of these guys like a special form.

Again, the proposal as written appears to be fairly close to current
practice.  Other than KCL, I don't know of any implementation that fully
evaluates DEFUN forms at compile time, and I don't know of any
implementation that doesn't do something special with DEFMACRO and
DEFVAR.  In some implementations, the compile-time side-effects of
DEFMACRO make the macro defined in exactly the same way as if the form
had been evaluated by the interpreter, and in others the macro
definition is stored someplace where the compiler can see it but the
interpreter can't.  Some people have made a fairly strong argument that
compilation side-effects should not affect the interpreter at all.

I think it would be nice to be able to definitely specify one way or the
other, either that the side-effects must be identical in the compiler to
what they are in the interpreter, or that the side effects must not be
visible to the interpreter at all.  However, I think the diversity of
opinion on this issue might prevent us from getting the rest of the
proposal through to the full committee, and I think it is *very*
important that we do that as soon as we can.  That is why the current
proposal explicitly leaves this behavior unspecified.  If we eventually
reach agreement to tighten it up one way or the other later on, there is
nothing to prevent us from presenting another proposal to amend this
one.  I just don't see that happening in the next few weeks.

-Sandra
-------

∂20-May-88  1354	CL-Compiler-mailer 	Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS     
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 20 May 88  13:54:26 PDT
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU; 20 May 88 16:55:23 EDT
To: sandra@cs.utah.edu (Sandra J Loosemore)
cc: cl-compiler@sail.stanford.edu
Subject: Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS 
In-reply-to: Your message of Fri, 20 May 88 14:03:55 -0600.
             <8805202003.AA06503@cs.utah.edu> 
Date: Fri, 20 May 88 16:55:14 EDT
From: Rob.MacLachlan@WB1.CS.CMU.EDU


    From: sandra@cs.utah.edu (Sandra J Loosemore)
    Date: Fri, 20 May 88 14:03:55 MDT
    Subject: Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS 
    To: Rob.MacLachlan@wb1.cs.cmu.edu
    > Date: Fri, 20 May 88 15:09:45 EDT
    > From: Rob.MacLachlan@WB1.CS.CMU.EDU
    > 
    > Like Jonl, I favor saying that forms like DEFMACRO are actually truly,
    > honest to God evaluated by the compiler.
    [...] These two paragraphs seem mutually contradictory.

Well, not in my intent.  I don't include DEFUN in "forms like DEFMACRO".
The "forms like DEFMACRO" are:
    defmacro
    deftype
    defstruct
    define-setf-method
    defsetf
    defconstant

As a codification of current practice, the proposal is fine, but it doesn't
go nearly as far in specification as a good language design should.
Vagueness in specification is a powerful tool, but you shouldn't be vague
for no good reason.  The main reason that current practice is so diverse is
that this stuff was never standardized on, and for most programs *it
doesn't matter* as long as it falls within the general range you outline.
The problem with not being definite is that it encourages non-portability,
since the few programs that do care will work differently on different
implementations.

Having said that, I point out that I have no objection to this proposal
other than that it doesn't require the DEFCONSTANT value form to be
compile-time evaluable.  In all other ways it is compatible with my
compiler cleanup proposal, since its definition is so inclusive.

  Rob

∂20-May-88  1533	CL-Compiler-mailer 	Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS     
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 May 88  15:33:20 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA12692; Fri, 20 May 88 16:33:49 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8805202233.AA12692@cs.utah.edu>
Date: Fri, 20 May 88 16:33:47 MDT
Subject: Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS 
To: Rob.MacLachlan@wb1.cs.cmu.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Rob.MacLachlan@WB1.CS.CMU.EDU, Fri, 20 May 88 16:55:14 EDT

I guess I'm not sure exactly what I should be more specific about in
this proposal, and how specific you all would like it to be.  I don't
think it would be appropriate to give code examples and say things like
"DEFMACRO *must* expand into *exactly* this set of forms".  The hooks
used by DEFSETF, for example, are necessarily quite implementation-specific
and it would be pointless to try to dictate what they must be.

What I've been trying to do is lay out what users must do to ensure that
their code is portable, and what implementions must and must not do.
Walter has already pointed out some particular things he'd like
mentioned, and if anybody else has something specific to add, I'd be
happy to hear about it.  I know I've left some things out just because
I didn't happen to think of them at the time I wrote this proposal!

-Sandra
-------

∂20-May-88  1627	CL-Compiler-mailer 	Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS     
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 20 May 88  16:27:14 PDT
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU; 20 May 88 18:55:14 EDT
To: sandra@cs.utah.edu (Sandra J Loosemore)
cc: cl-compiler@sail.stanford.edu
Subject: Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS 
In-reply-to: Your message of Fri, 20 May 88 16:33:47 -0600.
             <8805202233.AA12692@cs.utah.edu> 
Date: Fri, 20 May 88 18:55:09 EDT
From: Rob.MacLachlan@WB1.CS.CMU.EDU


    From: sandra@cs.utah.edu (Sandra J Loosemore)
    Date: Fri, 20 May 88 16:33:47 MDT
    Subject: Re: issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS 
    To: Rob.MacLachlan@wb1.cs.cmu.edu
    
    I guess I'm not sure exactly what I should be more specific about in
    this proposal, and how specific you all would like it to be.

This is the "compiler environment" issue.  Your proposal allows
implementations to attempt to maintain a separate compiler namespace.  This
capability is unnecessary for non-system code, and in the absence of
first-class environments, is too complex and/or vague to reasonably
specify.

Saying that the compile-time effect of processing a defining form is
required to be equivalent to that of evaluating it is more specific, and
not compatible with the concept of a compiler pseudo-environment.  In my
proposal I do allow that the compiler environment be disjoint from the
environment that compile-file is called in, but the compiler environment
must be a "real" environment.

The fact that systems need some way to protect the running Lisp from
compilation of system definitions is not an argument against flushing the
compiler environment as a Common Lisp concept.  Any Lisp system will
provide extensions that aid in bootstrapping the system; kludgey compiler
environment facilities can be enabled by a switch.

Once again, it isn't crucial that this issue be resolved now, since all
reasonable solutions are allowed by your proposal.  The only thing I
strongly object to is the treatment of the DEFCONSTANT value form.

  Rob

∂20-May-88  1647	CL-Compiler-mailer 	Re: issue EVAL-WHEN-NON-TOP-LEVEL  
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 20 May 88  16:47:26 PDT
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU; 20 May 88 17:04:53 EDT
To: sandra@cs.utah.edu (Sandra J Loosemore)
cc: cl-compiler@sail.stanford.edu
Subject: Re: issue EVAL-WHEN-NON-TOP-LEVEL 
In-reply-to: Your message of Fri, 20 May 88 13:29:58 -0600.
             <8805201929.AA05454@cs.utah.edu> 
Date: Fri, 20 May 88 17:04:48 EDT
From: Rob.MacLachlan@WB1.CS.CMU.EDU

   From: sandra@cs.utah.edu (Sandra J Loosemore)
    Message-Id: <8805201929.AA05454@cs.utah.edu>
    Date: Fri, 20 May 88 13:29:58 MDT
    Subject: Re: issue EVAL-WHEN-NON-TOP-LEVEL 
    To: Rob.MacLachlan@wb1.cs.cmu.edu
    
    > Date: Fri, 20 May 88 14:59:13 EDT
    > From: Rob.MacLachlan@WB1.CS.CMU.EDU
    > 
    >  In this form, I believe (FOO) would never be evaluated in
    > any context, which is definitely an incompatible change:
    >     (eval-when (compile)
    >       (eval-when (compile)
    > 	      (foo)))
    
    Yes, you are correct that under the current proposal, (foo) would never
    be evaluated.  I do not think it is "definitely" an incompatible change,
    however.  The current wording in CLtL seems to leave this behavior
    unspecified and I don't know what the original intention was.
    
I guess CLTL does leave that one hanging.  But this deserves at least some
compatibility/current practice note in the proposal.  This is incompatible
with at least our implementation.

The behavior you suggest seems non-intuitive to me.  The whole theory
behind EVAL-WHEN is that there are these independently composable
situations, any combination of which may be specified.  Specifying a
particular situation has a particular effect, independently of what other
situations are present.  In particular, specifying the COMPILE situation
guarantees that the body will be evaluated at compile time.

Of course, as I have pointed out before, the theory behind EVAL-WHEN is
wrong, so it isn't clear how upset we should be about mental models of
EVAL-WHEN being violated.

  Rob

∂21-May-88  0456	CL-Compiler-mailer 	issue EVAL-WHEN-NON-TOP-LEVEL 
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 21 May 88  04:56:45 PDT
Received: by labrea.stanford.edu; Sat, 21 May 88 04:57:03 PDT
Received: from bhopal.lucid.com by edsel id AA19600g; Sat, 21 May 88 04:39:11 PDT
Received: by bhopal id AA08170g; Sat, 21 May 88 04:42:51 PDT
Date: Sat, 21 May 88 04:42:51 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805211142.AA08170@bhopal.lucid.com>
To: labrea!vanroggen%aitg.decnet@hudson.dec.com
Cc: cl-compiler@sail.stanford.edu, vanroggen@sail.stanford.edu
In-Reply-To: "AITG::VANROGGEN"'s message of 20 May 88 11:19:00 EDT <8805201736.AA15806@edsel.lucid.com>
Subject: issue EVAL-WHEN-NON-TOP-LEVEL

re: A major nit (!?): Isn't there a cleanup proposal to disallow lexically
    binding special-forms in FLET, LABELS, and MACROLET?  If so, your
    EVAL-WHEN macro is doing a no-no.  You might want to change the statement
    from "suggested implementation technique" to "implemented as if".

This proposal changes EVAL-WHEN from being a special-form into being a 
MACRO [that expands into some readily-understandable(?) code].  Thus it 
wouldn't be subject to the no-shadowing-of-special-forms rule.


-- JonL --

∂21-May-88  1200	CL-Compiler-mailer 	Re: issue EVAL-WHEN-NON-TOP-LEVEL  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 May 88  12:00:24 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA28310; Sat, 21 May 88 10:11:26 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8805211611.AA28310@cs.utah.edu>
Date: Sat, 21 May 88 10:11:25 MDT
Subject: Re: issue EVAL-WHEN-NON-TOP-LEVEL
To: Jon L White <edsel!jonl@labrea.stanford.edu>
Cc: labrea!vanroggen%aitg.decnet@hudson.dec.com, cl-compiler@sail.stanford.edu,
        vanroggen@sail.stanford.edu
In-Reply-To: Jon L White <edsel!jonl@labrea.stanford.edu>, Sat, 21 May 88 04:42:51 PDT

> Date: Sat, 21 May 88 04:42:51 PDT
> From: Jon L White <edsel!jonl@labrea.stanford.edu>
> 
> This proposal changes EVAL-WHEN from being a special-form into being a 
> MACRO [that expands into some readily-understandable(?) code].  Thus it 
> wouldn't be subject to the no-shadowing-of-special-forms rule.

Well, it doesn't go quite that far.  In the new, revised version of the
proposal, I was going to say that EVAL-WHEN behaves *as if* it were
implemented as a macro.  Changing its "official" status from special form
to macro is a somewhat larger step.  

I can think of cases where user code would still want to think of it as
a special form, particularly if we don't decide to make the *compiling-p*
variable public.  For instance, if you're trying to implement some kind
of a code-walking preprocessor, you would probably want it to leave the
EVAL-WHENs in place since the context in which the preprocessor executes
may not be the same as the context in which the code it produces is to
be processed.

I will bow to the wishes of the subcommittee on this issue.  I do think
we need to make a decision one way or the other and include the rationale
in the proposal, because somebody else is bound to bring it up later on.

-Sandra
-------

∂23-May-88  1124	CL-Compiler-mailer 	issue DEFINING-MACROS-NON-TOP-LEVEL
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 23 May 88  11:24:38 PDT
Date: 23 May 88 14:06:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL
To: "cl-compiler" <cl-compiler@sail.stanford.edu>
cc: vanroggen   
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>

This one looks pretty good too.

  Remove the
  language on p. 66 of CLtL which states that the compiler is not
  required to recognize defining macros at other than top-level.
Except this is still true:
    (let ((x (f)))
      (defmacro m (y) `(+ ,x ,y)))
    ...
    (defun g (...)
      ... (m ...) ...)
and inside G the use of M is an error because it isn't guaranteed to be
recognized as a call to a macro.  As you indicate later, using EVAL-WHEN
would provide a means of avoiding this problem.

Another example of this restriction:
    (defun f (...)
      ...
      (defstruct ship length ...)
      ... (ship-length ...) ...
      ...)
The use of SHIP-LENGTH in F is an error.

It would be worthwhile to remind readers that the names/bindings are
still global.  Thus in the defstruct example above,
there is not guaranteed to be a SHIP type until after F is called, there
might not be any SHIP-xxx functions until after F is called, and
all the names created by the DEFSTRUCT will be global.

			---Walter
------

∂24-May-88  1236	CL-Compiler-mailer 	new versions of proposals
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 24 May 88  12:35:59 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA04797; Tue, 24 May 88 13:36:10 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8805241936.AA04797@cs.utah.edu>
Date: Tue, 24 May 88 13:36:09 MDT
Subject: new versions of proposals
To: cl-compiler@sail.stanford.edu

Coming up shortly (at long last) will be the revised versions of the
eval-when and defining macro proposals.  I apologize for taking so long;
the machine I was editing them on died a horrible death Friday afternoon
and is still in pieces, sigh.  Anyway, I have tried to clean up the
language and resolve some ambiguities that had previously gone
unnoticed.

So far I have received comments only from Walter about the third
proposal (about allowing defining macros in other than top-level
locations).  Does this mean everybody else is perfectly happy with it as
it stands?

-Sandra
-------

∂24-May-88  1236	CL-Compiler-mailer 	new, improved EVAL-WHEN proposal   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 24 May 88  12:36:28 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA04812; Tue, 24 May 88 13:36:39 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8805241936.AA04812@cs.utah.edu>
Date: Tue, 24 May 88 13:36:37 MDT
Subject: new, improved EVAL-WHEN proposal
To: cl-compiler@sail.stanford.edu

Issue:		EVAL-WHEN-NON-TOP-LEVEL
References:	CLtL p. 69-70
		Issue DEFINING-MACROS-NON-TOP-LEVEL
Category:	CLARIFICATION, ENHANCEMENT
Edit History:   6-May-88, V1 by Sandra Loosemore


Problem Description:

The current description of how the compiler should handle EVAL-WHEN
only makes sense when it appears as a top-level form in the file being
compiled.  Other proposals being considered by the compiler cleanup
committee require that we clarify how the compiler should process
EVAL-WHENs appearing at non-top-level, such as within LET or FUNCTION
special forms. 


Proposal:  EVAL-WHEN-NON-TOP-LEVEL:CLARIFY

In this proposal, we view EVAL-WHEN as a macro which expands into a
PROGN containing the body of the EVAL-WHEN when the context in which it
is expanded matches one of the situations listed, or NIL otherwise.
However, it is explicitly *not* proposed that EVAL-WHEN's status as
a special form be changed.

The EVAL situation corresponds to the normal processing of the
interpreter.  If EVAL is specified, the interpreter evaluates each
form in the body of the EVAL-WHEN as an implicit PROGN, using the
current lexical environment.  If the EVAL situation is not specified,
then the interpreter must return NIL as the value of the EVAL-WHEN
form, without evaluating the body. 

The LOAD situation corresponds to the normal processing of the
compiler.  If LOAD is specified, the compiler treats the EVAL-WHEN as
a PROGN and compiles the body in the normal way in the appropriate
lexical environment.  Otherwise, the form is equivalent to specifying
a constant value of NIL.  (The name LOAD is something of a misnomer,
because ``evaluation'' of the body happens not at LOAD time, but when
the EVAL-WHEN form would normally be ``evaluated''.  For example, if
an EVAL-WHEN form appears in the body of a DEFUN, it is ``evaluated''
when that function is called.)

The COMPILE situation is a special case; it indicates that the
compiler itself should evaluate the body of the EVAL-WHEN form as an
implicit PROGN in the null lexical environment.  During the
evaluation, if a nested EVAL-WHEN appears in the body, the interpreter
follows its usual rule of checking only whether or not the EVAL
situation is specified to decide whether or not the body of the nested
EVAL-WHEN should be processed. 

If both the COMPILE and LOAD situations are specified, the compiler
first performs the evaluation for the COMPILE situation.  Then, the
normal processing for the LOAD situation takes place, except that the
compile-time evaluation of nested (EVAL-WHEN (COMPILE) ...) forms in
the body is suppressed, preventing repeated evaluations of subforms.

(EVAL-WHEN (COMPILE) ...) should be used with caution in non-top-level
situations.  For example, if the following appears as a top level form
in a file being compiled

    (let ((x  (some-hairy-computation)))
        (eval-when (eval compile load) (print x)))

the variable X will be treated as special during the compile-time
evaluation, and the value printed will be its symbol-value.  To
guarantee consistency between compile-time evaluation and the normal
processing, one should wrap the entire top-level form in an EVAL-WHEN,
as follows:

    (eval-when (eval-compile load)
        (let ((x  (some-hairy-computation)))
	    (print x)))


Rationale:

The behavior of top-level EVAL-WHENs as specified in this proposal
remains almost identical to that specified in CLtL.  The major
addition is specifying the lexical environment in which non-top-level
EVAL-WHENs are processed.  It is clear that the COMPILE situation must
always be processed in the null lexical environment, since the actual
lexical environment is not available at compile time.  Having the EVAL
and LOAD situations evaluate in the proper environment leads to
differing semantics, but it appears to be the behavior that most
people expect, and it is also the easiest to implement.

Suppression of COMPILE evaluations in nested EVAL-WHENs is necessary
to achieve certain desirable behaviors, such as the macro example in
section 4 of the DEFINING-MACROS-NON-TOP-LEVEL proposal.

Although viewing EVAL-WHEN as a macro is useful for purposes of 
explanation, user code is likely to want to continue to treat EVAL-WHEN
as a special form.  For example, a preprocessor that performs a code
walk should leave EVAL-WHENs intact, since the context in which the
preprocessor runs may not be the same as the context in which the code
it produces runs.


Current Practice:


Cost to implementors:

Probably fairly minor in most implementations.  

As an implementation technique, we suggest implementing EVAL-WHEN as a 
macro which uses a state variable to keep track of the current context.
A sample implementation might look something like:

    (defvar *compiling-p* nil "Are we compiling or interpreting?")
    
    (defmacro eval-when (situations &body body)
        (cond 
    
              ;; If the COMPILE situation applies, evaluate the body now
              ;;    and also see if we need to do the LOAD situation too.
              ;;    If so, shadow the definition of EVAL-WHEN to make it
              ;;    ignore nested compile-time evaluation requests, and
              ;;    return the body.
    
              ((and *compiling-p* (member 'compile situations))
               (eval `(progn ,@body))
               (if (member 'load situations)
                   `(macrolet ((eval-when (situations &body body)
                                 (if (member 'load situations)
                                     `(progn ,@body)
                                     'nil)))
                        ,@body)
                   'nil))
    
              ;; If either the EVAL or LOAD situation applies, return a PROGN.
    
              ((if *compiling-p*
                   (member 'load situations)
                   (member 'eval situations))
               `(progn ,@body))
    
              ;; Otherwise no situation applies, so just return NIL.
    
              (t
               'nil)))
    
    
    ;;; Eval must bind *compiling-p* to NIL.
              
    (defun eval (form)
        (let ((*compiling-p* nil))
            :
            ))
    
    
    ;;; Compile and Compile-file must bind *compiling-p* to a non-nil value.
    
    (defun compile (name &optional definition)
        (let ((*compiling-p* t))
            :
            ))
    
    (defun compile-file (input-pathname &key output-file)
        (let ((*compiling-p* t))
            :
            ))


Cost to users:

Since CLtL does not currently specify what the meaning of EVAL-WHEN
forms at non-top-level is, existing code which depends on their use is
already nonportable.  Preventing repeated evaluations of subforms when
EVAL-WHENs are nested is unlikely to cause any serious compatibility
problems, since the current model would already result in only a
single evaluation in the case when the code is processed
interpretively.

There are also some situations concerning nested top-level occurences
of EVAL-WHEN that CLtL does not completely specify, to which this
proposal does assign a specific interpretation.  For example, CLtL is
unclear on whether or not (FOO) would ever be called, while in the
current proposal it would definitely not be called:

    (eval-when (compile)
        (eval-when (compile)
	    (foo)))


Benefits:

Clarifying the meaning of EVAL-WHEN allows the behavior of defining
macros such as DEFMACRO to be specified in terms of EVAL-WHEN.  As a
side effect, it would then become meaningful for defining macros to
appear at other than top-level. 


Discussion:

This proposal reflects what appears to be the consensus of the
compiler cleanup committee on this issue.

-------

∂24-May-88  1237	CL-Compiler-mailer 	new, improved defining macros proposal  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 24 May 88  12:36:55 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA04849; Tue, 24 May 88 13:37:06 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8805241937.AA04849@cs.utah.edu>
Date: Tue, 24 May 88 13:37:06 MDT
Subject: new, improved defining macros proposal
To: cl-compiler@sail.stanford.edu

Issue:		COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
References:	CLtL pages 66-70, 143
Category:	CLARIFICATION
Edit history:   V1, 07 Oct 1987 Sandra Loosemore
                V2, 15 Oct 1987 Sandra Loosemore
                V3, 15 Jan 1988 Sandra Loosemore
		V4, 06 May 1988 Sandra Loosemore
		V5, 20 May 1988 Sandra Loosemore



Problem Description:

Standard programming practices assume that, when calls to defining
macros such as DEFMACRO and DEFVAR are processed by COMPILE-FILE,
certain side-effects occur that affect how subsequent forms in the
file are compiled.  However, these side-effects are not mentioned in
CLtL, except for a passing mention that macro definitions must be
``seen'' by the compiler before it can compile calls to those macros
correctly.  In order to write portable programs, users must know
exactly which defining macros have compile-time side-effects and what
those side-effects are. 

Inter-file compilation dependencies are distinct from, and not
addressed by, this issue. 


Proposal: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY

(1) Clarify that defining macros such as DEFMACRO or DEFVAR, appearing
within a file being processed by COMPILE-FILE, normally have
compile-time side effects which affect how subsequent forms in the
same file are compiled.  A convenient model for explaining how these
side effects happen is that the defining macro expands into one or
more EVAL-WHEN forms, and that the calls which cause the compile-time
side effects to happen appear in the body of an (EVAL-WHEN (COMPILE)
...) form.  This is also the recommended implementation technique. 

(2) The affected defining macros and their specific side effects are
as follows:
 
DEFTYPE: The body of a DEFTYPE form must be evaluable at compile time.
If the expansion of a DEFTYPE'd type specifier is also a valid type
specifier at compile time, then the DEFTYPE'd type specifier is also
considered to be fully defined at compile time and must be recognized
within subsequent type declarations. 

DEFMACRO, DEFINE-MODIFY-MACRO:  Macro definitions must be stored at compile
time, so that occurences of the macro later on in the file will be expanded
correctly.  The body of the macro (but not necesarily its expansion) must 
be evaluable at compile time.
 
DEFUN: An implementation may choose to store information about the
function for the purposes of compile-time error-checking (such as
checking the number of arguments on calls), or to enable the function
to be expanded inline.  Portable code should not rely on DEFUN making
the function definition available at compile time.
 
DEFVAR, DEFPARAMETER: The compiler must recognize that the variables
named by these forms have been proclaimed special.  The initial value
form must not be evaluated at compile time. 
 
DEFCONSTANT: An implementation may choose to store information about
the variable for the purposes of compile-time error-checking, such as
checking for rebinding of or assignment to the variable.  The initial
value form must not be evaluated at compile time.  (If the initial
value is a constant, however, an implementation is allowed to
substitute the constant value for references to the named constant
during subsequent compilation.)
 
DEFSETF, DEFINE-SETF-METHOD: SETF methods must be available during the
expansion of calls to SETF later on in the file.  The body of
DEFINE-SETF-METHOD and the complex form of DEFSETF must be evaluable
at compile time, although the expansions need not be. 
 
DEFSTRUCT:  The structure type name must be recognized as a valid type name
in declarations, as for DEFTYPE.  The structure slot accessors must be made
known to SETF.  In addition, further DEFSTRUCT definitions should be able
to :INCLUDE a structure type defined earlier in the file being compiled.
The functions which DEFSTRUCT generates, and the #S reader syntax, may or
may not be available at compile time.

(3) The compile-time side effects may cause information about the
definition to be stored differently than if the defining macro had
been processed in the "normal" way (either interpretively or by loading
the compiled file).

In particular, the information stored by the defining macros at
compile time may or may not be available to the interpreter (either
during or after compilation), or during subsequent calls to COMPILE or
COMPILE-FILE.  For example, the following code is nonportable because
it assumes that the compiler stores the macro definition of FOO where
it is available to the interpreter:

    (defmacro foo (x) `(car ,x))
    (eval-when (eval compile load)
        (print (foo '(a b c))))

A portable way to do the same thing would be to include the macro definition
inside the EVAL-WHEN:

    (eval-when (eval compile load)
        (defmacro foo (x) `(car ,x))
        (print (foo '(a b c))))



Rationale:

The proposal reflects standard programming practices.  The primary
purpose of the proposal is to make an explicit statement that CL
supports the behavior that most programmers expect and many
implementations already provide.


Current Practice:

Many (probably most) Common Lisp implementations, including VaxLisp
and Lucid Lisp, are already largely in conformance.  

In VaxLisp, macro definitions that occur as a side effect of compiling
a DEFMACRO form are available to the compiler (even on subsequent calls
to COMPILE or COMPILE-FILE), but are not available to the interpreter
(even within the file being compiled).
 
Kyoto Common Lisp is a notable offender.  By default, KCL evaluates *all*
top level forms as they are compiled, which is clearly in violation of the
behavior specified on p 69-70 of CLtL.  There is a flag to disable the
compile-time evaluation, but then macros such as DEFMACRO, DEFVAR, etc. do
not make their definitions available at compile-time either.


Cost to implementors:

Making the defining macros expand into EVAL-WHENs to store the required
information is a simple and recommended implementation technique.  The
intent of the proposal is specifically not to require the compiler to
have special knowledge about each of these macros.


Cost to users:

Since CLtL does not specify whether and what compile-time side-effects
happen, any user code which relies on them is, strictly speaking,
nonportable.  In practice, however, most programmers already expect
the behavior described in this proposal and will not find it to be
an incompatible change.


Benefits:

Adoption of the proposal will provide more definite guidelines on how to
write programs that will compile correctly under all CL implementations.


Discussion:

Reaction to an earlier version of this proposal on the CL mailing list was
overwhelmingly positive.

It has been suggested that this proposal should also include PROCLAIM.
However, since PROCLAIM is not a macro, its compile-time side effects
cannot be handled using the EVAL-WHEN mechanism.  A separate proposal
seems more appropriate. 

There has also been a suggestion that DEFCONSTANT should always
evaluate the value provided.  The behavior specified in this proposal
makes DEFCONSTANT similar to DEFVAR and DEFPARAMETER, while allowing
the user to explicitly ask for compile-time evaluation using the #. read
macro.

Item (3) allows for significant deviations between implementations.
While there is some sentiment to the effect that the compiler should
store definitions in a manner identical to that of the interpreter,
other people believe strongly that compiler side-effects should be
completely invisible to the interpreter.  The author is of the opinion
that since this is a controversial issue, further attempts to restrict
this behavior should be considered as separate proposals.

-------

∂24-May-88  1251	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 24 May 88  12:50:53 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA05361; Tue, 24 May 88 13:50:14 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8805241950.AA05361@cs.utah.edu>
Date: Tue, 24 May 88 13:50:13 MDT
Subject: Re: issue DEFINING-MACROS-NON-TOP-LEVEL
To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Cc: "cl-compiler" <cl-compiler@sail.stanford.edu>
In-Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>, 23 May 88 14:06:00 EDT

> Date: 23 May 88 14:06:00 EDT
> From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
> 
> Except this is still true:
>     (let ((x (f)))
>       (defmacro m (y) `(+ ,x ,y)))
>     ...
>     (defun g (...)
>       ... (m ...) ...)
> and inside G the use of M is an error because it isn't guaranteed to be
> recognized as a call to a macro.

I don't think this follows from our model of how the defining macros
do their thing at compile time, and how EVAL-WHEN works at
non-top-level.  The DEFMACRO presumably would expand into an (EVAL-WHEN
(COMPILE) ...) to store the macro definition for the compiler, and as
long as the compiler processes this before it runs across any calls to
the macro, this example would be OK (that is, if it were not for the
problem of the macro function getting defined in the wrong lexical
environment).

If you want the defining macros to have their compile-time side-effects
occur only if they appear at top-level, I think we have to come up with
some other model to explain how this happens (other than saying that
they expand into EVAL-WHENs).  Do we really want to do that?

-Sandra
-------

∂24-May-88  1623	CL-Compiler-mailer 	new, improved defining macros proposal  
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 May 88  16:22:56 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA19899@EDDIE.MIT.EDU>; Tue, 24 May 88 19:20:05 EDT
Received: by spt.entity.com (smail2.5); 24 May 88 18:17:07 EDT (Tue)
To: sandra@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 24 May 88 13:37:06 MDT <8805241937.AA04849@cs.utah.edu>
Subject: new, improved defining macros proposal
Message-Id: <8805241817.AA22314@spt.entity.com>
Date: 24 May 88 18:17:07 EDT (Tue)
From: gz@spt.entity.com (Gail Zacharias)

I just started receiving this mailing list, so my apologies if this has been
discussed before.

   DEFCONSTANT: 	...			(If the initial
   value is a constant, however, an implementation is allowed to
   substitute the constant value for references to the named constant
   during subsequent compilation.)

I have a problem with this.  The compiler shouldn't have licence to substitute
for the variable without fully implementing the semantics of DEFCONSTANT.
In particular, under this proposal, would the DEFCONSTANT's with constant
initial values be "evaluable at compile time" in the sense used in the
description of DEFMACRO?  I.e. would the following work?
   	(DEFCONSTANT FOO 'FOO)
	(DEFMACRO FOO () `',FOO)
	(DEFVAR *FOO* (FOO))
In addition, the distinction between constant/non-constant initial value is
artificial and potentially ambiguous in the face of differing constant-folding
capabilities.  Consider
	(DEFCONSTANT FOO 17)
	(DEFCONSTANT BAR (ASH 1 FOO))
Are compilers allowed to substitute for BAR?

I think toplevel DEFCONSTANT should either be treated like DEFMACRO (i.e.
implicitly compile-time: initial value "must be evaluable at compile time" and
the binding must be made available to other compile-time code) or like
DEFVAR/DEFPARAMETER (implicitly load-time: compiler recognizes the variable as
special, but it is not allowed to substitute the value).  I don't have a
strong preference either way (since you can always get "the other" semantics
via eval-when), but I don't like the proposed mixture of the two.

∂25-May-88  0809	CL-Compiler-mailer 	Re: Issue: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS (version 5)  
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 25 May 88  08:09:31 PDT
Date: 25 May 88 11:06:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: Re: Issue: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS (version 5)
To: "cl-compiler" <cl-compiler@sail.stanford.edu>
cc: vanroggen   
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>

I agree with the proposal in its treating the initial value form of
DEFCONSTANT just like those of DEFVAR and DEFPARAMETER in that that form
must not be evaluated at compile time.  (Of course, DEFCONSTANT, just like
the others, may macroexpand into code that evaluates at compile-time.)

However, to answer the concerns of compiler implementors not being able
to make certain optimizations, it's quite permissible for compilers to
"evaluate" constants, both literals such as 3.4 and expressions such as
(ASH 3 7) or even (ASH FOO BAR) if both FOO and BAR were previously
defined DEFCONSTANTS with constant values.  The point is that if the
constant value depends on its run-time environment in any way, the
compiler can't try to do "constant folding" too early unless it can prove
there won't be any difference.

There's a separate issue here regarding substitution of constants, I think,
in whether it's permissible for (DEFCONSTANT FOO "abc") and a later use of
FOO to "copy" the string value.  I'd change the wording about substitution
of constants to mention that that's a separate issue for clean-up.

BTW, in the next-to-last paragraph, using "#." is also the wrong time--
since read-time might well be too early.  It's best to recommend either
that or EVAL-WHEN as needed.

			---Walter
------

∂25-May-88  0926	CL-Compiler-mailer 	Re: new, improved defining macros proposal   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 May 88  09:24:41 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA04830; Wed, 25 May 88 10:24:32 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8805251624.AA04830@cs.utah.edu>
Date: Wed, 25 May 88 10:24:31 MDT
Subject: Re: new, improved defining macros proposal
To: gz@spt.entity.com (Gail Zacharias)
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: gz@spt.entity.com (Gail Zacharias), 24 May 88 18:17:07 EDT (Tue)

Sigh, this issue just won't go away.

What one would normally expect DEFCONSTANT to do is to setq the symbol
and then somehow mark it as being constant, so that it can't be setq'ed
again.  At compile-time, if the value-form is not evaluable, you
obviously can't setq it yet.  I agree it would be silly to specify
that the setq'ing happens at compile-time in some cases but not in
others, and that was certainly not what I had in mind.

The intention was that *if* the compiler does substitution of symbolic
constants with their values *and* it can determine the value of the
symbolic constant at compile-time, *then* the compiler can assume
that the value of the constant at run-time is the same as what it sees
at compile-time and go ahead and make a substitution for it.  I would
assume that if an implementation is sophisticated enough to do all of
this, it would be able to store the information about the constant value
using some other mechanism besides setq'ing the symbol at compile-time.

I can try rewording this part of the proposal yet again.  I think the
main points are:

(1) the compiler should know that the symbol is a constant so it will
not complain when it sees references to it as an unbound variable, and
possibly so it will complain when it sees attempts to setq or bind the
symbol.

(2) neither the evaluation of the value-form or the setq'ing of the
symbol may happen at compile-time (analagous to DEFVAR and DEFPARAMETER)

(3) if the value-form can be evaluated at compile-time, the compiler may
assume that the constant will have the same value at run-time.

-Sandra
-------

∂27-May-88  0828	CL-Compiler-mailer 	Re: Issue: EVAL-WHEN-NON-TOP-LEVEL 
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 27 May 88  08:28:08 PDT
Date: 27 May 88 11:15:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: Re: Issue: EVAL-WHEN-NON-TOP-LEVEL
To: "cl-compiler" <cl-compiler@sail.stanford.edu>
cc: vanroggen   
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>

There really isn't enough consideration of what happens when the
EVAL-WHEN isn't a top-level, and what following expressions may
depend on from what was inside a non-top-level EVAL-WHEN.

The problem is what order expressions may get "processed", particularly
by code-walkers such as compilers.

Here's a simple example which assumes the DEFMACRO expands into an
(EVAL-WHEN ...) to tell everyone who cares (particularly the compiler at
compile time) that M is a macro.

  (let ...
    (defmacro m ...)
    (m ...))

But the body of the LET is equivalent to

  (let ...
    (flet ((rest () (m ...)))
      (defmacro m ...)
      (rest)))

which isn't going to work.

The easiest solution is to assume that one cannot depend on the effects
of the EVAL-WHEN at compile time until the next top-level form.

			---Walter
------

∂09-Jun-88  0921	CL-Compiler-mailer 	Compiler Subcommittee meeting 
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 9 Jun 88  09:21:34 PDT
Received: by ucbarpa.Berkeley.EDU (5.59/1.28)
	id AA01037; Thu, 9 Jun 88 09:20:22 PDT
Received: by franz (3.2/3.14)
	id AA02004; Thu, 9 Jun 88 08:02:11 PDT
Received: by feast (5.5/3.14)
	id AA00828; Thu, 9 Jun 88 10:32:54 EDT
Date: Thu, 9 Jun 88 10:32:54 EDT
From: franz!feast!smh@ucbarpa.Berkeley.EDU (Steven M. Haflich)
Message-Id: <8806091432.AA00828@feast>
To: franz!sail.stanford.edu!cl-compiler
Subject: Compiler Subcommittee meeting

Owing to the difficulty in scheduling conference rooms at Symbolics in
the evening, our subcommittee will meet at:

	Tuesday, June 14, 7:30 PM

	Gigamos
	675 Massachusetts Avenue
	Cambridge MA

Gigamos is on the 7th floor of a large office building which is a mere
few steps from the MBTA Central Square Red Line stop, or about a 20
minute walk from Harvard Square, Symbolics, or MIT.  There is a
security guard who should allow you to sign in by mentioning Gigamos,
but if there is any difficulty, call Gigamos from the lobby at
876-6819 and ask for me.

Please RSVP so we can know who's coming and when it's safe to start.

If anyone would like to meet for dinner beforehand (or afterhand) that
would be just dandy.  There are a multitude of superb ethnic
establishments in the immediate neighborhood.

∂09-Jun-88  1219	CL-Compiler-mailer 	Compiler Subcommittee meeting 
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 9 Jun 88  12:19:27 PDT
Received: by ucbarpa.Berkeley.EDU (5.59/1.28)
	id AA04525; Thu, 9 Jun 88 12:18:16 PDT
Received: by franz (3.2/3.14)
	id AA02522; Thu, 9 Jun 88 11:24:12 PDT
Received: from TI.COM by ucbarpa.Berkeley.EDU (5.59/1.28)
	id AA02196; Thu, 9 Jun 88 10:29:10 PDT
Received: by ti.com id AA04276; Thu, 9 Jun 88 12:28:03 CDT
Received: from mips by tilde id AA15746; Thu, 9 Jun 88 12:25:12 CDT
Received: by mips id AA09228; Thu, 9 Jun 88 12:25:03 CDT
Date: Thu, 9 Jun 88 12:25:03 CDT
From: David Bartley <franz!ucbarpa!mips.csc.ti.com!bartley@ucbarpa.Berkeley.EDU>
Message-Id: <8806091725.AA09228@mips>
To: franz!feast!smh
Cc: franz!sail.stanford.edu!cl-compiler
In-Reply-To: "Steven M. Haflich"'s message of Thu, 9 Jun 88 10:32:54 EDT <8806091432.AA00828@feast>
Subject: Compiler Subcommittee meeting

> Please RSVP so we can know who's coming and when it's safe to start.

I expect to make it.

∂09-Jun-88  1346	CL-Compiler-mailer 	Re: Compiler Subcommittee meeting  
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Jun 88  13:41:27 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa09118; 9 Jun 88 21:31 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Thu, 9 Jun 88 21:31:12 BST
Message-Id: <17148.8806092031@aiai.ed.ac.uk>
To: cl-compiler@sail.stanford.edu
Subject: Re: Compiler Subcommittee meeting

> Please RSVP so we can know who's coming and when it's safe to start.

I'd mail to you directly, but there's just no hope of figuring
out what magic incantations are necessary to reach

	edu.berkeley.ucbarpa!franz!feast!smh

from here.

> There are a multitude of superb ethnic establishments

Good idea.

Jeff Dalton,                      JANET: J.Dalton@uk.ac.ed             
AI Applications Institute,        ARPA:  J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University.             UUCP:  ...!ukc!ed.ac.uk!J.Dalton

∂09-Jun-88  1415	CL-Compiler-mailer 	(another) revised version of the defining macros proposal   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 9 Jun 88  14:14:47 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA12037; Thu, 9 Jun 88 14:41:41 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8806092041.AA12037@cs.utah.edu>
Date: Thu, 9 Jun 88 14:41:39 MDT
Subject: (another) revised version of the defining macros proposal
To: cl-compiler@sail.stanford.edu

Here is yet another revision to the defining macros proposal.  The only
thing that has changed is the wording of the DEFCONSTANT section.  I hope
that this time I have at least managed to make the language concise enough
so that we can agree on what it says, even if we don't all agree *with*
what it says.

-Sandra


Issue:		COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
References:	CLtL pages 66-70, 143
Category:	CLARIFICATION
Edit history:   V1, 07 Oct 1987 Sandra Loosemore
                V2, 15 Oct 1987 Sandra Loosemore
                V3, 15 Jan 1988 Sandra Loosemore
		V4, 06 May 1988 Sandra Loosemore
		V5, 20 May 1988 Sandra Loosemore
		V6, 09 Jun 1988 Sandra Loosemore


Problem Description:

Standard programming practices assume that, when calls to defining
macros such as DEFMACRO and DEFVAR are processed by COMPILE-FILE,
certain side-effects occur that affect how subsequent forms in the
file are compiled.  However, these side-effects are not mentioned in
CLtL, except for a passing mention that macro definitions must be
``seen'' by the compiler before it can compile calls to those macros
correctly.  In order to write portable programs, users must know
exactly which defining macros have compile-time side-effects and what
those side-effects are. 

Inter-file compilation dependencies are distinct from, and not
addressed by, this issue. 


Proposal: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY

(1) Clarify that defining macros such as DEFMACRO or DEFVAR, appearing
within a file being processed by COMPILE-FILE, normally have
compile-time side effects which affect how subsequent forms in the
same file are compiled.  A convenient model for explaining how these
side effects happen is that the defining macro expands into one or
more EVAL-WHEN forms, and that the calls which cause the compile-time
side effects to happen appear in the body of an (EVAL-WHEN (COMPILE)
...) form.  This is also the recommended implementation technique. 

(2) The affected defining macros and their specific side effects are
as follows:
 
DEFTYPE: The body of a DEFTYPE form must be evaluable at compile time.
If the expansion of a DEFTYPE'd type specifier is also a valid type
specifier at compile time, then the DEFTYPE'd type specifier is also
considered to be fully defined at compile time and must be recognized
within subsequent type declarations. 

DEFMACRO, DEFINE-MODIFY-MACRO:  Macro definitions must be stored at compile
time, so that occurences of the macro later on in the file will be expanded
correctly.  The body of the macro (but not necesarily its expansion) must 
be evaluable at compile time.
 
DEFUN: An implementation may choose to store information about the
function for the purposes of compile-time error-checking (such as
checking the number of arguments on calls), or to enable the function
to be expanded inline.  Portable code should not rely on DEFUN making
the function definition available at compile time.
 
DEFVAR, DEFPARAMETER: The compiler must recognize that the variables
named by these forms have been proclaimed special.  The initial value
form must not be evaluated at compile time. 
 
DEFCONSTANT: The compiler must recognize the symbol as being constant
(for example, to suppress warnings about references to the symbolic
constant as an unbound variable or to enable warnings about binding or
SETQ'ing the constant in the code being compiled).  Neither evaluation
of the value-form or SETQ'ing of the symbol may occur at compile-time.
However, if the (unevaluated) value-form is CONSTANTP, the compiler is
allowed to build assumptions about the value of the constant into
programs being compiled, as described on p. 68-69 of CLtL.
 
DEFSETF, DEFINE-SETF-METHOD: SETF methods must be available during the
expansion of calls to SETF later on in the file.  The body of
DEFINE-SETF-METHOD and the complex form of DEFSETF must be evaluable
at compile time, although the expansions need not be. 
 
DEFSTRUCT:  The structure type name must be recognized as a valid type name
in declarations, as for DEFTYPE.  The structure slot accessors must be made
known to SETF.  In addition, further DEFSTRUCT definitions should be able
to :INCLUDE a structure type defined earlier in the file being compiled.
The functions which DEFSTRUCT generates, and the #S reader syntax, may or
may not be available at compile time.

(3) The compile-time side effects may cause information about the
definition to be stored differently than if the defining macro had
been processed in the "normal" way (either interpretively or by loading
the compiled file).

In particular, the information stored by the defining macros at
compile time may or may not be available to the interpreter (either
during or after compilation), or during subsequent calls to COMPILE or
COMPILE-FILE.  For example, the following code is nonportable because
it assumes that the compiler stores the macro definition of FOO where
it is available to the interpreter:

    (defmacro foo (x) `(car ,x))
    (eval-when (eval compile load)
        (print (foo '(a b c))))

A portable way to do the same thing would be to include the macro definition
inside the EVAL-WHEN:

    (eval-when (eval compile load)
        (defmacro foo (x) `(car ,x))
        (print (foo '(a b c))))



Rationale:

The proposal reflects standard programming practices.  The primary
purpose of the proposal is to make an explicit statement that CL
supports the behavior that most programmers expect and many
implementations already provide.


Current Practice:

Many (probably most) Common Lisp implementations, including VaxLisp
and Lucid Lisp, are already largely in conformance.  

In VaxLisp, macro definitions that occur as a side effect of compiling
a DEFMACRO form are available to the compiler (even on subsequent calls
to COMPILE or COMPILE-FILE), but are not available to the interpreter
(even within the file being compiled).
 
Kyoto Common Lisp is a notable offender.  By default, KCL evaluates *all*
top level forms as they are compiled, which is clearly in violation of the
behavior specified on p 69-70 of CLtL.  There is a flag to disable the
compile-time evaluation, but then macros such as DEFMACRO, DEFVAR, etc. do
not make their definitions available at compile-time either.


Cost to implementors:

Making the defining macros expand into EVAL-WHENs to store the required
information is a simple and recommended implementation technique.  The
intent of the proposal is specifically not to require the compiler to
have special knowledge about each of these macros.


Cost to users:

Since CLtL does not specify whether and what compile-time side-effects
happen, any user code which relies on them is, strictly speaking,
nonportable.  In practice, however, most programmers already expect
the behavior described in this proposal and will not find it to be
an incompatible change.


Benefits:

Adoption of the proposal will provide more definite guidelines on how to
write programs that will compile correctly under all CL implementations.


Discussion:

Reaction to an earlier version of this proposal on the CL mailing list was
overwhelmingly positive.

It has been suggested that this proposal should also include PROCLAIM.
However, since PROCLAIM is not a macro, its compile-time side effects
cannot be handled using the EVAL-WHEN mechanism.  A separate proposal
seems more appropriate. 

There has also been a suggestion that DEFCONSTANT should always
evaluate the value provided.  The behavior specified in this proposal
makes DEFCONSTANT similar to DEFVAR and DEFPARAMETER, while allowing
the user to explicitly ask for compile-time evaluation using the #. read
macro.

Item (3) allows for significant deviations between implementations.
While there is some sentiment to the effect that the compiler should
store definitions in a manner identical to that of the interpreter,
other people believe strongly that compiler side-effects should be
completely invisible to the interpreter.  The author is of the opinion
that since this is a controversial issue, further attempts to restrict
this behavior should be considered as separate proposals.

-------

∂09-Jun-88  1414	CL-Compiler-mailer 	(another) new version of the non-top-level defining macros proposal   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 9 Jun 88  14:14:37 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA12308; Thu, 9 Jun 88 14:46:03 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8806092046.AA12308@cs.utah.edu>
Date: Thu, 9 Jun 88 14:46:03 MDT
Subject: (another) new version of the non-top-level defining macros proposal
To: cl-compiler@sail.stanford.edu

Item 5 is new, from a suggestion by Walter.  I haven't gotten comments from
anyone else on the previous version of this proposal.

-Sandra



Issue:		DEFINING-MACROS-NON-TOP-LEVEL
References:	CLtL p. 66-70, 143
		Issue EVAL-WHEN-NON-TOP-LEVEL
		Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Category:	CLARIFICATION, ENHANCEMENT
Edit History:   6-May-88, V1 by Sandra Loosemore
		9-Jun-88, V2 by Sandra Loosemore


Problem Description:

CLtL leaves the interpretation of defining forms such as DEFMACRO and
DEFVAR that appear in other than top-level locations unspecified.
Resolution of other issues (EVAL-WHEN-NON-TOP-LEVEL and
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS) now allows reasonable
semantics to be assigned to defining forms which appear at
non-top-level.


Proposal: DEFINING-MACROS-NON-TOP-LEVEL:ALLOW

(1) Clarify that while defining macros normally appear at top level,
it is meaningful to place them in non-top-level contexts and that the
compiler must handle them properly in all situations.  Remove the
language on p. 66 of CLtL which states that the compiler is not
required to recognize defining macros at other than top-level.

(2) The proposal COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
defines a model for specifying how defining macros work.  To
summarize, the expansion of the macro (rather than its expander
function) is responsible for storing information about the definition.
Compile-time side effects are typically handled by including one or
more EVAL-WHEN forms in the expansion.  A compiler may choose
some other implementation, such as treating defining macros as
implementation-specific special forms, provided that the semantics
are compatible.

(3) Defining macros which define functional objects (such as DEFUN and
DEFMACRO) must ensure that the functions are defined in the lexical
environment in which the defining macro appears.  In the model
referred to above, this would normally be implemented by producing a
FUNCTION special form in the macro expansion.  For example, the
following code causes the function BAR to be closed over the variable
X:

    (let ((x  (some-hairy-computation)))
        (defun bar (y) (+ x y)))

(4) The language on p. 145 of CLtL, which states that macro functions
are defined in the null lexical environment, should be removed.
Instead, defining forms such as DEFMACRO which make a functional
definition available at the compile time use the environment must
normally appear inside an explicit (EVAL-WHEN (COMPILE) ...) to ensure
that the correct lexical environment is seen. 

An example may help clarify why this is necessary.  The code fragment

    (let ((x  (some-hairy-computation)))
        (defmacro bar-macro (y) `(+ ,x ,y)))

would macroexpand into something similar to

    (let ((x  (some-hairy-computation)))
        (eval-when (eval compile load)
            (setf (macro-function 'bar-macro) 
	          #'(lambda (form env)
		        (let ((y  (second form)))
			    `(+ ,x ,y))))
            'bar-macro))

Since the rules for (EVAL-WHEN (COMPILE) ...) state that evaluation
takes place in the null lexical environment, in this situation X would
be treated as a special variable within the macro function.  However,
in the EVAL or LOAD situations, the lexical value of X would be used.
To ensure consistency, the correct definition would be:

    (eval-when (eval compile load)
        (let ((x  (some-hairy-computation)))
            (defmacro bar (y) `(+ ,x ,y))))


(5) Clarify that ``top-level forms'' are evaluable data objects read
in from an input source (such as a keyboard or disk file) by
successive calls to the function READ.  As a special case, forms
within a top-level PROGN are also considered to be top-level forms.
Specify that top-level forms in a file being compiled are guaranteed
to be processed sequentially, but the order in which subforms of a
top-level form are processed by the compiler is explicitly left
unspecified.  It is an error for user code to depend upon the
compile-time side-effects of a defining macro within the same
top-level form in which the defining macro appears.


Rationale:

The notion of a ``top-level form'' is rather confused, since the term
is used in CLtL to refer both to a place where a form may appear (what
this proposal continues to call ``top-level''), and to instances of
forms which traditionally appear there (what this proposal calls
``defining macros'').  

There has been a suggestion that the notion of a top-level form should
be extended to include forms in the body of a top-level LET, to allow
forms such as DEFUN to be meaningful there.  However, we feel that a
cleaner solution is to remove the restrictions on the placement of
defining macros altogether. 


Current Practice:


Cost to implementors:


Cost to users:

None.  This is a compatible extension.


Benefits:

The notion of defining macros as being somehow special is removed from
the language.  Allowing defining macros to appear anywhere instead of
restricting them to certain positions results in a cleaner language
design.


Discussion:

-------

∂09-Jun-88  1707	CL-Compiler-mailer 	next order of business   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 9 Jun 88  17:07:34 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA17668; Thu, 9 Jun 88 18:06:36 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8806100006.AA17668@cs.utah.edu>
Date: Thu, 9 Jun 88 18:06:34 MDT
Subject: next order of business
To: cl-compiler@sail.stanford.edu

It seems like issues relating to the treatment of constants in compiled
code, which have been discussed on the common-lisp mailing list for the
past few weeks, should probably be the next thing we try to address.  I
believe that the main thing that has to be done here is to explicitly
state that it is an error to destructively modify structured constants
(since the current wording in CLtL allows the compiler to collapse EQUAL
structures), and to clarify exactly what kinds of destructive operations
would be forbidden.  For example, I do not believe we would want to
prohibit alteration of the "fields" of a quoted symbol such as the
property list.  There are other, more radical approaches we could
take -- such as forbidding implementations to collapse constants or put
them in read-only storage -- but I don't know if any of these would get
much support.  Comments, anyone?  I could try to sketch out a proposal
on this over the weekend and bring it to Cambridge for discussion.

-Sandra
-------

∂10-Jun-88  0121	CL-Compiler-mailer 	Compiler Subcommittee meeting and dinner
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 10 Jun 88  01:21:25 PDT
Received: by ucbarpa.Berkeley.EDU (5.59/1.28)
	id AA21348; Fri, 10 Jun 88 01:20:10 PDT
Received: by franz (3.2/3.14)
	id AA04504; Fri, 10 Jun 88 00:59:42 PDT
Received: by feast (5.5/3.14)
	id AA00493; Fri, 10 Jun 88 03:50:35 EDT
Date: Fri, 10 Jun 88 03:50:35 EDT
From: franz!feast!smh@ucbarpa.Berkeley.EDU (Steven M. Haflich)
Message-Id: <8806100750.AA00493@feast>
To: franz!sail.stanford.edu!cl-compiler
Subject: Compiler Subcommittee meeting and dinner

There have been a couple positive replies.  I propose that people who
want to go to dinner on Tuesday meet at Gigamos at 6PM.  We can wait
there until about 6:15, walk to dinner in the neighborhood, and return
to Gigamos around 7:30.  We'll try to leave word with the guard where
we go to dinner in case someone is late.

Once again, Gigamos is at Central Square Cambridge, 675 Massachusetts
Avenue, the 7th floor of the "Tofias" building.  The security guard
should allow access if you mention Gigamos, but if there is any
problem call 876-6819 and ask for me.  I'll try to leave a list of
subcommittee members with the guard.

∂19-Jun-88  1717	Common-Lisp-mailer 	#, read macro  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Jun 88  17:17:02 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA01138; Sun, 19 Jun 88 18:15:26 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8806200015.AA01138@cs.utah.edu>
Date: Sun, 19 Jun 88 18:15:25 MDT
Subject: #, read macro
To: common-lisp@sail.stanford.edu, cl-compiler@sail.stanford.edu

One of the items currently before the X3J13 compiler cleanup
subcommittee is tightening up the definition of how the #, (sharp-sign
comma) read macro should work, and where it may legitimately appear in
code to be compiled.  We are considering (among other options) removing
it from Common Lisp entirely.  Since this would clearly be an
incompatible change to the language, we would like to hear from people
who actually use #, to find out how it is being used and whether some
other technique(s) couldn't be used to solve the same problems.  

Please send replies on this subject to cl-compiler@sail.stanford.edu.

-Sandra
-------

∂19-Jun-88  2355	CL-Compiler-mailer 	#, read macro  
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 19 Jun 88  23:55:46 PDT
Received: from PELE.ACA.MCC.COM by MCC.COM with TCP/SMTP; Mon 20 Jun 88 01:53:45-CDT
Date: Mon, 20 Jun 88 01:52 CDT
From: Christopher Maeda <maeda@MCC.COM>
Subject: #, read macro
To: sandra@cs.utah.edu, common-lisp@sail.stanford.edu, cl-compiler@sail.stanford.edu
cc: bug-cyc@MCC.COM
In-Reply-To: <8806200015.AA01138@cs.utah.edu>
Message-ID: <19880620065222.1.MAEDA@PELE.ACA.MCC.COM>

We are implementing a frame system where each frame is a defstruct.  We
use a reader macro to reference case sensitive frame names, permitting
the frame namespace to be disjoint from the symbol namespace.  The
reader macro also lets us hook into a completion package that is very
handy for longer names.

I would be interested in hearing what alternatives the cleanup committee
is considering.  Being able to dispatch to an arbitrary read function is
hard to beat.

--Chris

∂20-Jun-88  1006	Common-Lisp-mailer 	#, read macro  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 20 Jun 88  10:06:29 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Mon, 20 Jun 88 13:11:08 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Mon, 20 Jun 88 13:11:05 EDT
Date: Mon, 20 Jun 88 13:03 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: #, read macro
To: Christopher Maeda <maeda@mcc.com>
Cc: sandra@cs.utah.edu, common-lisp@sail.stanford.edu,
        cl-compiler@sail.stanford.edu, bug-cyc@mcc.com
In-Reply-To: <19880620065222.1.MAEDA@PELE.ACA.MCC.COM>
Supersedes: <19880620170243.2.BARMAR@OCCAM.THINK.COM>
Message-Id: <19880620170302.3.BARMAR@OCCAM.THINK.COM>

    Date: Mon, 20 Jun 88 01:52 CDT
    From: Christopher Maeda <maeda@mcc.com>

    We are implementing a frame system where each frame is a defstruct.  We
    use a reader macro to reference case sensitive frame names, permitting
    the frame namespace to be disjoint from the symbol namespace.  The
    reader macro also lets us hook into a completion package that is very
    handy for longer names.

    I would be interested in hearing what alternatives the cleanup committee
    is considering.  Being able to dispatch to an arbitrary read function is
    hard to beat.

    --Chris

No one is talking about removing reader macros in general.  We are
considering removing the "#," reader macro.  "#," is a relatively
obscure cousin of "#."; it causes the form following it to be
evaluated at load time rather than at read time as "#." does.

To see how it currently works, put the following definition in a file:

(defun sharp-comma-example ()
  (quote #,*sharp-comma-var*))

Compile the file, type (setq *sharp-comma-var* 'a), then load the binary
file.  Then type (setq *sharp-comma-var* 'b) and (sharp-comma-example).
It should return A.


                                                barmar

∂20-Jun-88  1237	CL-Compiler-mailer 	Re: #, read macro   
Received: from gremlin.nrtc.northrop.com by SAIL.Stanford.EDU with TCP; 20 Jun 88  12:37:05 PDT
Received: from tribble by gremlin.nrtc.northrop.com id a018817;
          20 Jun 88 12:22 PDT
To: Sandra J Loosemore <sandra@cs.utah.EDU>
cc: common-lisp@sail.stanford.EDU, cl-compiler@sail.stanford.EDU, 
    jbarnett@gremlin.nrtc.northrop.COM
Subject: Re: #, read macro 
In-reply-to: Your message of Sun, 19 Jun 88 18:15:25 -0600.
             <8806200015.AA01138@cs.utah.edu> 
Date: Mon, 20 Jun 88 12:22:53 -0700
From: jbarnett@gremlin.nrtc.northrop.COM

One use of this construct is to simulate ALGOL-like OWN variables; to wit:
  (defun foo (arg ... &aux (var '#,<complex expression>))
      body that references var...)
where the <complex expression> is computed in terms of previously defined
defvars, defuns, etc., and you don't want to create yet another only-used-in
one-place special variable, e.g.,
  (defvar *foos-own* <complex expression>)
  (defun foo (args ...)
      body that reference *foos-own* insteadof var...)
By the way, there's not much use to trying to clean up the use of #, until
you do a better job of defining EVAL-WHEN (or whatever you call it now).
If you do that properly, not only will #, be easy to understand, implement, and
use, but I'd guess that several natural and useful extentions will occur.

	Jeff

∂20-Jun-88  1706	CL-Compiler-mailer 	#,   
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 20 Jun 88  17:06:24 PDT
Received: by labrea.stanford.edu; Mon, 20 Jun 88 17:04:59 PDT
Received: from atlantis.lucid.com by edsel id AA16965g; Mon, 20 Jun 88 17:00:49 PDT
Received: by atlantis id AA00092g; Mon, 20 Jun 88 17:00:08 pdt
Date: Mon, 20 Jun 88 17:00:08 pdt
From: Leonard Zubkoff <edsel!lnz@labrea.stanford.edu>
Message-Id: <8806210000.AA00092@atlantis.lucid.com>
To: cl-compiler@sail.stanford.edu
Subject: #,

The only time I've ever used #, is the following one instance:

(defconstant program-version #,(form-to-decide-what-the-version-should-be))

The reason I needed to do this is that:

(1) I wanted the version to be decided at the time I loaded the above form.
(2) The form resides in a compiled file.
(3) I wanted a constant, not a variable.

		Leonard

∂20-Jun-88  2022	CL-Compiler-mailer 	non-top-level DEFUN 
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 20 Jun 88  20:22:48 PDT
Received: by ucbarpa.Berkeley.EDU (5.59/1.28)
	id AA00876; Mon, 20 Jun 88 20:21:01 PDT
Received: by franz (3.2/3.14)
	id AA00293; Mon, 20 Jun 88 19:45:39 PDT
Received: by feast (5.5/3.14)
	id AA00094; Mon, 20 Jun 88 22:36:10 EDT
Date: Mon, 20 Jun 88 22:36:10 EDT
From: franz!feast!smh@ucbarpa.Berkeley.EDU (Steven M. Haflich)
Message-Id: <8806210236.AA00094@feast>
To: franz!sail.stanford.edu!cl-compiler
Subject: non-top-level DEFUN

Perhaps I've been on another planet, but I just realized a serious
problem with non-top-level function-defining DEF* forms.

Our interpreter will already handle the following without problem:

(let ((*foo* 3))
  (defun set-foo (x) (setq *foo* x))
  (defun get-foo (y) (cons *foo* y)))

So will our COMPILE-FILE.  The problem comes when the above forms are
entered interpreted and subsequently a (COMPILE 'GET-FOO) is executed.
Interpreted and compiled closures have entirely different
representation, and it is impossible for compiled and interpreted
functions to share a closure.  It would appear that the original CLtL
rules on closures and compilation are designed to permit this freedom,
although use of (SETF (SYMBOL-FUNCTION XXX #'(...))) can obviously
create named interpreted closure functions which subsequently one
could attempt to compile.  No one has yet complained ...

I wonder if any other implementations will suffer the same problem?
Has anyone yet thought about this?  Is the non-top-level-defun change
less compatible than we thought?  Obviously, the compiler and
interpreter could be unified, but efficiency might suffer.

∂20-Jun-88  2208	CL-Compiler-mailer 	#, read macro  
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 20 Jun 88  22:08:18 PDT
Date: Mon 20 Jun 88 13:16:31-PDT
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: #, read macro
To: cl-compiler@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12408021267.27.IIM@ECLA.USC.EDU>

    While I admit that the uses of #, are pretty esoteric, I don't think that
is sufficient reason to flush it, unless you can really convince everybody that
ALL possible uses can be handled equally well in some other way.

    The places I've seen it used where I thought it was justified have all
essentially been instances of caching.  The most common cases have involved
using #, to cache the result of the search for some special object, when the
search can't be performed at compile time.  I've also seen it used to create a
data structure once, in order to avoid consing, although this practice is
usually pretty questionable, due to multi-tasking considerations.  This kind of
usage can probably be handled about equally well by using defparameter.  There
are a couple of possible disadvantages to using defparameter though.  First, It
sort of adds to clutter, since you need to think up a name for each case of #,
(although this isn't always a bad thing), and conses up a symbol, which
requires memory.  Second, a special variable lookup might be slower than
accessing an inline constant in a given implementation; I don't thing the
reverse is very likely.  Also, using a defparameter means that someone could
change its value, though this could actually be a blessing when debugging.

    Another place where I've seen it used is to produce some unique value once
(to avoid consing), for use as the default argument to get/getf, or the eof
value for read, and similar things.  In this case it is the uniqueness of the
value (testable with EQ) that is important, which makes the defparameter
solution more likely to get broken by having someone come along and
inappropriately bash the variable.  However, it is usually (I'm reluctant to
say always) the case that this idiom can be handled using #. instead of #,.

    PCL uses a macro called load-time-eval.  It used to be the case that this
really was trying to use load-time considerations, and not just caching the
result of some computation after the first time it was done.  This macro was
supposed to be sort of an extension of #,, since the people working on PCL
considered the latter to be inadequate for what they were trying to do (which,
in fact, it is).  I believe that PCL no longer actually needs the load-time
specialness, and might in fact be better off using a caching scheme instead.  I
do know that the old PCL code in which I first saw load-time-eval was in fact
rather broken.

    Hmmm.  It seems that while I had initially intended to argue for keeping
it, while writing this I've just about convinced myself that #, can be flushed.
Well, maybe someone else can come up with an excuse for keeping it.

kab

PS. Is this list (cl-compiler) active and significantly disjoint from the main
common-lisp mailing list.  If so, I'd like to be added to it.
-------

∂21-Jun-88  0619	CL-Compiler-mailer 	Re: non-top-level DEFUN  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Jun 88  06:19:06 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA13810; Tue, 21 Jun 88 07:18:53 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8806211318.AA13810@cs.utah.edu>
Date: Tue, 21 Jun 88 07:18:52 MDT
Subject: Re: non-top-level DEFUN
To: franz!feast!smh@ucbarpa.berkeley.edu (Steven M. Haflich)
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: franz!feast!smh@ucbarpa.Berkeley.EDU (Steven M. Haflich), Mon, 20 Jun 88 22:36:10 EDT

Well, I did specifically ask about things like this for the current
practice section of the proposal....  As far as I know, there probably
isn't any implementation that is strictly in compliance with the
proposal. Some are just more broken than others -- I've heard that in
Symbolics CL DEFUN will refuse to create a closure at all, for example,
and in KCL the compiler expands a DEFUN at top level into something
completely different than a DEFUN anywhere else.  So yes, I expect
implementors are going to have to make some changes to support this, but
there's no such thing as a free lunch.

-Sandra
-------

∂21-Jun-88  0628	CL-Compiler-mailer 	Re: non-top-level DEFUN  
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 21 Jun 88  06:28:34 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA01697; Tue, 21 Jun 88 09:26:21 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA05487; Tue, 21 Jun 88 09:30:23 EDT
Message-Id: <8806211330.AA05487@mist.UUCP>
To: franz!feast!smh%ucbarpa.Berkeley.EDU@multimax (Steven M. Haflich)
Cc: cl-compiler%sail.stanford.edu@multimax.ARPA
Subject: Re: non-top-level DEFUN 
In-Reply-To: Your message of Mon, 20 Jun 88 22:36:10 -0400.
             <8806210236.AA00094@feast> 
Date: Tue, 21 Jun 88 09:30:20 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    I wonder if any other implementations will suffer the same problem?
    Has anyone yet thought about this?  Is the non-top-level-defun change
    less compatible than we thought?  Obviously, the compiler and
    interpreter could be unified, but efficiency might suffer.
    
Kent pointed this out to me at Fort Collins.  The underlying problem
is that if you wrap a closure around a set of top-level forms, you
have to treat the set as a whole for the purpose of compilation.  

I think that it's basically a development environment problem.  An
implementation that wishes to support incremental development in this
style needs to provide a lexical environment inspector.  To RE-compile
one part of a closure, you enter the closure environment and do the
recompile there.  Many Scheme systems support such an inspector,
though none that I'm aware of advertise incremental compilation
(T/ORBIT supports it undocumented, but maybe not this feature).  A
couple of caveats to this suggestion:

    1. It may still be necessary for the entire closure to be either
       compiled or interpreted because of environment representation.

    2. I am not suggesting making this part of the Common Lisp
       standard because we haven't defined what lexical environments
       are yet.  This is about a possible Common Lisp extension that a
       vendor could support; other vendors could just require you to
       redefine the entire closure at once, which probably means file
       compilation (though it would be nice to get a handle on the LET
       and some way to pass it to COMPILE).

All in all, the top level defining forms stuff provides additional
necessary support to an area that Common Lisp copied from Scheme.  The
additional support is useful but not complete; however complete
support would have to include a good deal of development environment
support which is out of our area.

∂21-Jun-88  0637	CL-Compiler-mailer 	Re: non-top-level DEFUN  
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 21 Jun 88  06:36:59 PDT
Date: 21 Jun 88 09:15:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: Re: non-top-level DEFUN
To: "cl-compiler" <cl-compiler@sail.stanford.edu>
cc: vanroggen   
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>

VAX LISP has the same restriction, for the same reason.  However,
the restriction isn't a necessary one, if one is willing to compile
references to free variables with a call to a function to find the
right binding in either the interpreted environment or the compiled
environment as necessary.

This implementation "workaround" would also require the compiler to leave
behind enough information so the interpreter could look up bindings in
the compiled environment.

			---Walter
------

∂21-Jun-88  0721	CL-Compiler-mailer 	Re: non-top-level DEFUN  
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 21 Jun 88  07:21:45 PDT
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU; 21 Jun 88 10:21:41 EDT
To: cl-compiler@sail.stanford.edu
Subject: Re: non-top-level DEFUN 
Date: Tue, 21 Jun 88 10:21:22 EDT
From: Rob.MacLachlan@WB1.CS.CMU.EDU



In the past, A contingent at Symbolics offered this as an objection to
non-top-level DEFUNs, but nobody else seemed to buy it.  Yes COMPILE will
choke on functions defined in a non-null environment.  No, this does not
prevent incremental development, since in any reasonable incremental
development environment, you will hardly ever use COMPILE.

In your example, in our environment, I would compile the entire LET
together with both DEFUNs by using the editor "Compile Defun" command.

  Rob

∂21-Jun-88  0753	CL-Compiler-mailer 	#, implementation   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Jun 88  07:53:24 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA15752; Tue, 21 Jun 88 08:53:18 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8806211453.AA15752@cs.utah.edu>
Date: Tue, 21 Jun 88 08:53:15 MDT
Subject: #, implementation
To: cl-compiler@sail.stanford.edu

The question of efficiency of referencing a constant data structure
created with #, versus referencing a special variable has been raised.
I have never really studied an implementation of #, so I don't have
much of a feel for this.  Can any of you folks comment on what happens
in your implementation?  The person who raised the issue thought that #,
would be much faster, but my gut feeling is that it would be about the
same speed.

Also, I'm curious to know:  what does your reader return for #, and how
does the compiler recognize it when it's buried inside of a QUOTE form?

-Sandra
-------

∂21-Jun-88  0932	CL-Compiler-mailer 	re: uses of #, 
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 21 Jun 88  09:32:07 PDT
Posted-Date: Tue, 21 Jun 88 09:32:41 PDT
Message-Id: <8806211632.AA03841@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
	id AA03841; Tue, 21 Jun 88 09:32:45 PDT
To: CL-COMPILER@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: re: uses of #,
Date: Tue, 21 Jun 88 09:32:41 PDT
Sender: goldman@vaxa.isi.edu

I believe that all our uses of #, would be subsumed by the following
construct, which we have implemented in various ways in each of 3
common lisp implementations, but believe cannot be implemented portably
within common lisp as it now stands:


UNVARYING   e							[Special Form]
e may be any expression.  The value of (UNVARYING e) is simply the (first)
value returned by e.  However, the programmer authorizes the implementation
to cache the value and return the cached result (or a value EQL to it) on
successive executions of the same occurrence of (UNVARYING e).
There is NO implication that the value may be computed at "compile" time,
although analysis of e may show that it is safe to do so under some
circumstances -- in particular, if e involves only constant subexpressions
and contstant, side-effect-free, stateless, functions and macros.



One implementation we have expands (UNVARYING e) into:

(let ((#:G0001 '(NIL . NIL)))
  (if (car #:G0001)
      (cdr #:G0001)
      (setf (car #:G0001) t (cdr #:G0001) e)))

[This implementation will not work, of course, on an implementation that
takes the position that a quoted CONS datum may not be smashed.]



We use this macro in many places where "#," cannot be used, because it
appears in the expansion of some other macro.  I believe that all the uses
we make of the "read-time" evaluating done by "#," could be replaced
acceptably by the "first execution time" evaluting done by UNVARYING.  

On the other hand, most of our uses of UNVARYING  COULD
be safely evaluated at "load" time, and would yield somewhat smoother
performance if evaluation were done then rather than at first execution
time.  So I'd like UNVARYING to have an optional parameter to specify
whether load-time evaluation is authorized, with the default being YES.
[Of course, this assumes that the concept of "load time", or "program
construction time", is considered to be sufficiently well defined that
language semantics can refer to it.]

The reason that compile-time evaluation won't work in most of these cases
is that it is not proper to "create" (i.e., cons)  the VALUE at 
load time, only to "find" it.  The expression e constitutes the
directions for finding the correct value.

∂21-Jun-88  1019	CL-Compiler-mailer 	#, implementation   
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 21 Jun 88  10:19:31 PDT
Received: by labrea.stanford.edu; Tue, 21 Jun 88 10:19:37 PDT
Received: from blacksox.lucid.com by edsel id AA20890g; Tue, 21 Jun 88 10:13:19 PDT
Received: by blacksox id AA00339g; Tue, 21 Jun 88 10:12:16 pdt
Date: Tue, 21 Jun 88 10:12:16 pdt
From: Eric Benson <edsel!eb@labrea.stanford.edu>
Message-Id: <8806211712.AA00339@blacksox.lucid.com>
To: sandra@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 21 Jun 88 08:53:15 MDT <8806211453.AA15752@cs.utah.edu>
Subject: #, implementation

In our implementation, a reference to a constant data structure using
#, has one less memory indirection than a reference through a special
variable.  However, it has exactly the same overhead as a reference
through a lexical variable.  For example,

(defun something-funny ()
  (do-something-with '#,(make-some-data-structure)))

and

(let ((some-data-structure (make-some-data-structure)))
  (defun something-funny ()
    (do-something-with some-data-structure)))

have exactly the same overhead for the reference to the data
structure.  In

(defparameter *some-data-structure* (make-some-data-structure))

(defun something-funny ()
  (do-something-with *some-data-structure*))

there is one more memory indirection.

∂21-Jun-88  1031	CL-Compiler-mailer 	#, implementation   
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 21 Jun 88  10:31:22 PDT
Received: by labrea.stanford.edu; Tue, 21 Jun 88 10:31:34 PDT
Received: from blacksox.lucid.com by edsel id AA20943g; Tue, 21 Jun 88 10:24:39 PDT
Received: by blacksox id AA00343g; Tue, 21 Jun 88 10:23:40 pdt
Date: Tue, 21 Jun 88 10:23:40 pdt
From: Eric Benson <edsel!eb@labrea.stanford.edu>
Message-Id: <8806211723.AA00343@blacksox.lucid.com>
To: sandra@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 21 Jun 88 08:53:15 MDT <8806211453.AA15752@cs.utah.edu>
Subject: #, implementation

   From: sandra@cs.utah.edu (Sandra J Loosemore)
   Date: Tue, 21 Jun 88 08:53:15 MDT

   Also, I'm curious to know:  what does your reader return for #, and how
   does the compiler recognize it when it's buried inside of a QUOTE form?

   -Sandra
   -------


Our reader returns an object of a certain internal type (defined by
DEFSTRUCT) containing the expression following the #, .  This is
recognized not by the compiler but by the "fasdumper," the function
that writes binary files.  When such an object is encountered while
traversing a constant data structure, the fasdumper emits a special
opcode which causes EVAL to be called at load time on the expression
contained in the object.

∂21-Jun-88  1717	CL-Compiler-mailer 	#, implementation   
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Jun 88  17:17:52 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA17582@EDDIE.MIT.EDU>; Tue, 21 Jun 88 19:59:19 EDT
Received: by spt.entity.com (smail2.5); 21 Jun 88 19:45:57 EDT (Tue)
To: sandra@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 21 Jun 88 08:53:15 MDT <8806211453.AA15752@cs.utah.edu>
Subject: #, implementation
Message-Id: <8806211945.AA25667@spt.entity.com>
Date: 21 Jun 88 19:45:57 EDT (Tue)
From: gz@spt.entity.com (Gail Zacharias)

   From: sandra@cs.utah.edu (Sandra J Loosemore)
   Date: Tue, 21 Jun 88 08:53:15 MDT

    The question of efficiency of referencing a constant data structure
   created with #, versus referencing a special variable has been raised.

Depending on the setting of optimization options, we might do boundp checks on
compiled special variable references.  There is also the space inefficiency of
having to create a symbol (and a pname string, and a slot in a package, etc)
to hold a value which is only going to be referenced once.

   Also, I'm curious to know:  what does your reader return for #, and how
   does the compiler recognize it when it's buried inside of a QUOTE form?

We return a list whose car is a unique gensym and whose cadr is the form.
When it occurs inside a quoted form, it ends up passing unnoticed through the
compiler to the fasldumper, which then handles it specially.  In addition, the
gensym has a macro definition in an arguably pointless attempt to make
unquoted #,'s do something reasonable (or at least semantically correct)
whenever possible.  We don't handle the special-form case -- as in "(LET
#,(MY-VARS) ...)" -- at all (i.e. don't even signal an error in most cases).

∂01-Jul-88  1229	CL-Compiler-mailer 	status report  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 1 Jul 88  12:27:31 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA02284; Fri, 1 Jul 88 13:27:18 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807011927.AA02284@cs.utah.edu>
Date: Fri, 1 Jul 88 13:27:17 MDT
Subject: status report
To: cl-compiler@sail.stanford.edu


It seems like the mail on #, has died down, so I'm planning to start
working on a proposal on this issue over the weekend.  Actually, I'm
thinking of sketching out two or three alternate proposals and then
taking a poll on which one to pursue further.

On a personal note, I have resigned from my job at Evans & Sutherland
and am returning to being a full-time student at the UofU.  My departure
from E&S is happening a bit faster than I had planned; the other day a
water main broke and flooded the building I worked in -- there was 4
inches of muddy water in my office and over a foot in my lab in the
basement, totally trashing all the computer equipment down there.
Anyway, my e-mail address remains the same (sandra@cs.utah.edu) and I do
plan to continue participating in X3J13.

-Sandra
-------

∂03-Jul-88  1154	CL-Compiler-mailer 	Handling of #, (load-time-eval)    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Jul 88  11:54:27 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA02737; Sun, 3 Jul 88 12:54:18 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
	id AA18432; Sun, 3 Jul 88 12:54:15 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807031854.AA18432@cdr.utah.edu>
Date: Sun, 3 Jul 88 12:54:14 MDT
Subject: Handling of #, (load-time-eval)
To: cl-compiler@sail.stanford.edu

Here are the possible alternatives for dealing with #,.  The first two
have already been written up in detail in the LOAD-TIME-EVAL issue
from the cleanup committee.  I only have a paper copy of this issue;
could somebody (Dan?) who has an electronic copy please send it around
to the rest of us?

(1) (LOAD-TIME-EVAL:QUOTED-MAGIC-TOKEN) Define a function that returns
a magic token that can appear inside quoted structures to define a
load-time constant.

(2) (LOAD-TIME-EVAL:NEW-SPECIAL-FORM) Define a new special form that
causes its argument to be evaluated once at load time and the value
cached.  Calls to the special form would have to appear in a place
where they would be evaluated, and not inside quoted structure.  #, would
be changed incompatibly.

(3) Throw out #, entirely and do not provide any other similar
functionality.

(4) Simply clarify that #, must appear inside of quoted structure and
that it's really not the same as #. in interpreted code.

(5) Like (2), but somehow graft the new functionality onto EVAL-WHEN.

To summarize briefly the responses I got to my question about #,
usage, it appears that nearly all usages of #, could be replaced by
references to a variable initialized with DEFVAR or DEFCONSTANT.  The
people who responded appeared to be well aware of this, but liked #,
syntax better because they didn't have to think of a variable name,
and thought it might be somewhat more efficient.  As far as I can
tell, #, is almost never used at other than top-level in quoted
structure (that is, people use '#,(foo) but not '(... #',(foo) ...)).

What I would like to do is get some reactions to the various
alternatives so that I'll know which one(s) to pursue further.  I
personally would favor either (2) or (3), but if there isn't any
concensus arising on this issue I think we would have to write up (4)
as the fallback position.

Finally, a subissue I think we need to touch upon: Should the object
returned by evaluating the form indicated by #, be read-only?  I'd
argue that if we go with a proposal that restricts #, to appearing in
quoted structure, and if we accept that quoted structures are
read-only, we'd have to say Yes to this question as well.

-Sandra
-------

∂05-Jul-88  1202	CL-Compiler-mailer 	mailing list   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 5 Jul 88  12:01:57 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
	id AA06621; Tue, 5 Jul 88 12:01:30 PDT
Message-Id: <8807051901.AA06621@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 5 Jul 88 15:00
To: cl-compiler@sail.stanford.edu
Subject: mailing list

Could you please add me to the cl-compiler mailing list?

Thanks,
Kathy Chapman

∂06-Jul-88  0719	CL-Compiler-mailer 	Handling of #, (load-time-eval)    
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 6 Jul 88  07:19:06 PDT
Received: from franz.UUCP by ucbarpa.Berkeley.EDU (5.59/1.28)
	id AA03419; Wed, 6 Jul 88 07:18:30 PDT
Received: by franz (3.2/3.14)
	id AA26774; Wed, 6 Jul 88 07:11:16 PDT
Received: by feast (5.5/3.14)
	id AA00607; Wed, 6 Jul 88 09:57:28 EDT
Date: Wed, 6 Jul 88 09:57:28 EDT
From: franz!feast!smh@ucbarpa.Berkeley.EDU (Steven M. Haflich)
Message-Id: <8807061357.AA00607@feast>
To: franz!sail.stanford.edu!cl-compiler
In-Reply-To: Sandra J Loosemore's message of Sun, 3 Jul 88 12:54:14 MDT <8807031854.AA18432@cdr.utah.edu>
Subject: Handling of #, (load-time-eval)

   From: franz!ucbarpa!cs.utah.edu!sandra%cdr (Sandra J Loosemore)

   (3) Throw out #, entirely and do not provide any other similar
   functionality.

But, of course, all implementations would preserve it anyway for
backward compatibility.  This is a wishy-washy choice.

   (4) Simply clarify that #, must appear inside of quoted structure and
   that it's really not the same as #. in interpreted code.

A real problem with #, is that it's mechanism is unavailable *except*
via the reader, but some functions are composed by functions other
than the reader.

   To summarize briefly the responses I got to my question about #,
   usage, it appears that nearly all usages of #, could be replaced by
   references to a variable initialized with DEFVAR or DEFCONSTANT.  The
   people who responded appeared to be well aware of this, but liked #,
   syntax better because they didn't have to think of a variable name,
   and thought it might be somewhat more efficient.

I don't remember whether this was mentioned explicitly, but one
benefit of #, is that it is *clearer* -- the load-time-eval form
appears at its point of use or inclusion, and not at some distant
DEFVAR.  This is not a minor point.

   As far as I can
   tell, #, is almost never used at other than top-level in quoted
   structure (that is, people use '#,(foo) but not '(... #',(foo) ...)).

Allegro's flavor implementation does use the #, mechanism inside
quoted structures.  However, this is also a prime example of a program
that (almost) needs access to the magic internal token, since the
forms being compiled are generated by hairy DEFFLAVOR internal macros
and not read by the reader.

   Finally, a subissue I think we need to touch upon: Should the object
   returned by evaluating the form indicated by #, be read-only?  I'd
   argue that if we go with a proposal that restricts #, to appearing in
   quoted structure, and if we accept that quoted structures are
   read-only, we'd have to say Yes to this question as well.

I think that #, should only appear inside quoted structure.  However,
as an extension, might we also permit the value returned by #, to be
any self-evaluating object?  E.g.:

  (setq foo
     (1+ #,(seventh (decode-universal-time
                      (get-universal-time)))))

The value returned by the #, expression is always an integer, which is
always self-evaluating.  The compiler could be allowed to assume that
anything returned by #, will not require further evaluation.

∂07-Jul-88  0949	CL-Compiler-mailer 	Re:  Handling of #, (load-time-eval)    
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 7 Jul 88  09:49:49 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA22842; Thu, 7 Jul 88 09:48:07 PDT
Received: from clam.sun.com by snail.sun.com (4.0/SMI-3.2)
	id AA16100; Thu, 7 Jul 88 09:43:27 PDT
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA19882; Thu, 7 Jul 88 09:51:00 PDT
Date: Thu, 7 Jul 88 09:51:00 PDT
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8807071651.AA19882@clam.sun.com>
To: cl-compiler@sail.stanford.edu, sandra%cdr@cs.utah.edu
Subject: Re:  Handling of #, (load-time-eval)

My preferences, in order, are:

Alternative (3) Throw out #, entirely.

Alternative (2) Define a new special form.

Note that in CLtL, p. 86, (QUOTE x) is defined as "simply returns x.
The object is not evaluated and may be any Lisp object whatsoever.
This construct allows any Lisp object to be written as a constant value
in a program."

I would prefer to see the simplicity of QUOTE retained rather than
complicating it to support #,.

I prefer removal of #, from the language because it is logically
impossible for it to be as described in CLtL -- just a read macro --
and even if made a self-consistent part of the language it requires
a special mechanism unique to it.  Since there are alternatives to
it, I would omit it.

It seems appropriate to me that if QUOTEd constants are permitted to
be read-only, values produced by #, would also be permitted to be
read-only.  In other words, it would be an error to attempt to modify them.

				-Cris

∂08-Jul-88  0919	CL-Compiler-mailer 	Handling of #, (load-time-eval)    
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 8 Jul 88  09:19:06 PDT
Received: from franz.UUCP by ucbarpa.Berkeley.EDU (5.59/1.28)
	id AA00573; Fri, 8 Jul 88 09:18:16 PDT
Received: by franz (3.2/3.14)
	id AA01885; Fri, 8 Jul 88 08:36:16 PDT
Received: by feast (5.5/3.14)
	id AA00581; Fri, 8 Jul 88 02:51:44 EDT
Date: Fri, 8 Jul 88 02:51:44 EDT
From: franz!feast!smh@ucbarpa.Berkeley.EDU (Steven M. Haflich)
Message-Id: <8807080651.AA00581@feast>
To: franz!sail.stanford.edu!cl-compiler
In-Reply-To: Sandra J Loosemore's message of Wed, 6 Jul 88 17:39:01 MDT <8807062339.AA20085@cdr.utah.edu>
Subject: Handling of #, (load-time-eval)

   From: franz!ucbarpa!cs.utah.edu!sandra%cdr (Sandra J Loosemore)

   I interpret your reply to mean that you would support some variant of
   the quoted magic token proposal, right? 

Yes, but failing that I would also accept dropping it from the
language entirely if no magic cookie proposal appears sufficiently
clean.  My rational for wanting to make at least a sincere effort to
salvage it is that no one feels *very* strongly either way about
dropping it, but if it can be defined cleanly, it is a useful (if not
essential) tool for some purposes.

∂08-Jul-88  0919	CL-Compiler-mailer 	Handling of #, (load-time-eval)    
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 8 Jul 88  09:19:10 PDT
Received: from franz.UUCP by ucbarpa.Berkeley.EDU (5.59/1.28)
	id AA00576; Fri, 8 Jul 88 09:18:19 PDT
Received: by franz (3.2/3.14)
	id AA01892; Fri, 8 Jul 88 08:36:28 PDT
Received: by feast (5.5/3.14)
	id AA00769; Fri, 8 Jul 88 11:21:18 EDT
Date: Fri, 8 Jul 88 11:21:18 EDT
From: franz!feast!smh@ucbarpa.Berkeley.EDU (Steven M. Haflich)
Message-Id: <8807081521.AA00769@feast>
To: franz!sail.stanford.edu!cl-compiler
In-Reply-To: Cris Perdue's message of Thu, 7 Jul 88 09:51:00 PDT <8807071651.AA19882@clam.sun.com>
Subject:  Handling of #, (load-time-eval)

   From: franz!ucbarpa!Sun.COM!cperdue (Cris Perdue)

   Note that in CLtL, p. 86, (QUOTE x) is defined as "simply returns x.
   The object is not evaluated and may be any Lisp object whatsoever.
   This construct allows any Lisp object to be written as a constant value
   in a program."

   I would prefer to see the simplicity of QUOTE retained rather than
   complicating it to support #,.

This "simple" description of QUOTE, I think, is not intended to cover
it's the effect of quoted objects during the fasl/load cycle.  There
are obvious examples of quoted objects that can't (in all
implementations) be written to a compiled file as a constant in a
program and reloaded.  PATHNAMEs and STREAMs are obvious examples.
Some implementations permit PATHNAMEs, but others cannot.  Some
implementations allow STREAMs to be written, but the STREAM is
magically closed or otherwise invalidated by load.

#, also has to do with the loading of compiled files, so this argument
based on the `simpleness' of QUOTE seems invalid.

   It seems appropriate to me that if QUOTEd constants are permitted to
   be read-only, values produced by #, would also be permitted to be
   read-only.  In other words, it would be an error to attempt to modify them.

I think it is not only reasonable but necessary to require that a #,
expression may only appear as a quoted object or inside a quoted
object.  This is almost the same as saying that #, may not be used
anywhere it could potentially be evaluated, or inside a declaration.

There might be a few warts, left like documentation strings.  The
following is clearly not legal! :-)

  (defun frobus (x)
    #,(progn (format *query-io*
               "Please enter documentation for FROBUS:")
             (read-line *query-io*))
    ...)

It would, however, be legal and perhaps plausible to use #. there.

∂08-Jul-88  1322	CL-Compiler-mailer 	Re:  Handling of #, (load-time-eval)    
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 8 Jul 88  13:22:10 PDT
Received: from franz.UUCP by ucbarpa.Berkeley.EDU (5.59/1.28)
	id AA04331; Fri, 8 Jul 88 13:21:20 PDT
Received: by franz (3.2/3.14)
	id AA02486; Fri, 8 Jul 88 12:18:56 PDT
Received: from SUN.COM by ucbarpa.Berkeley.EDU (5.59/1.28)
	id AA03167; Fri, 8 Jul 88 12:04:31 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA14178; Fri, 8 Jul 88 12:03:26 PDT
Received: from clam.sun.com by snail.sun.com (4.0/SMI-3.2)
	id AA21821; Fri, 8 Jul 88 11:58:43 PDT
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA20816; Fri, 8 Jul 88 12:06:19 PDT
Date: Fri, 8 Jul 88 12:06:19 PDT
From: franz!ucbarpa!Sun.COM!cperdue@ucbarpa.Berkeley.EDU (Cris Perdue)
Message-Id: <8807081906.AA20816@clam.sun.com>
To: franz!feast!smh, franz!sail.stanford.edu!cl-compiler
Subject: Re:  Handling of #, (load-time-eval)

>    It seems appropriate to me that if QUOTEd constants are permitted to
>    be read-only, values produced by #, would also be permitted to be
>    read-only.  In other words, it would be an error to attempt to modify them.
> 
> I think it is not only reasonable but necessary to require that a #,
> expression may only appear as a quoted object or inside a quoted
> object.  This is almost the same as saying that #, may not be used
> anywhere it could potentially be evaluated, or inside a declaration.

Steve, I missed the connection between my comment and your comment here.
Also I'm not sure what you mean about #, not being useable anywhere it
could potentially be evaluated, or inside a declaration.  I see no
reason not to allow code such as (eval '#,(what-to-eval)) if we are
to allow #, at all.

When I talk about permitting #, or its magic cookie *only inside
quoted expressions*, I mean that this situation would be required
to exist after all macro expansion.

∂08-Jul-88  1532	CL-Compiler-mailer 	Handling of #, (load-time-eval)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jul 88  15:32:41 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430781; Fri 8-Jul-88 18:32:27 EDT
Date: Fri, 8 Jul 88 18:32 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Handling of #, (load-time-eval)
To: CL-Compiler@SAIL.Stanford.EDU
Message-ID: <880708183214.4.KMP@PEWEE.SCRC.Symbolics.COM>

I'm just on my way out the door so don't have time to go into it in
detail right now, but I've been feeling guilty about not making my
position on this be heard. I'll try to write up justifications for
the following positions when I have a bit of time (maybe next week)
but just so you know...

 - I feel strongly that #, is a minimal level of functionality
   necessary in CL. It would be well to specify whether it is
   intended to work either inside of QUOTE or outside, but it must
   be there in some form.

 - I do not feel that there is anything strange or low-level about
   #, . It expresses an abstract concept which is very high-level
   and fundamentally important to certain kinds of programming.

 - I think a special form such as the LOAD-TIME-CONSTANT form I
   proposed on CL-Cleanup a while back would be an important addition.
   I have seen no technical justification for not just providing it.
   It looks to me like you guys are getting overly ambitious and trying
   to define #, in terms of a revised EVAL-WHEN. [EVAL-WHEN is not
   trivially fixable, but even it serves a purpose and should be left
   alone if no suitable improvement can be devised. In any case,
   no matter what you think of EVAL-WHEN, I would ask you to not let
   those feelings keep you from making a good #, and/or 
   LOAD-TIME-CONSTANT form.]

 - There are numerous important uses of #, and LOAD-TIME-CONSTANT.
   CLOS is one use. The Fortran-To-Lisp translator which I wrote
   as an undergrad was another. Anything that involves `linking'
   requires this.

 - It is not adequate to say that this can be handled
   by closures and/or special variables because the code modularity
   may be inappropriate for closures, and the naming of special
   variables (if not also the size of all those wasted symbols!)
   would be prohibitive. Consider, for example, that my Fortran-To-Lisp
   translator used a Maclisp SQUID expression (the #, analog for
   Maclisp) on -every- translated variable reference. That is,
   A(A+3) in Fortran program FOO translated to
   (AREF *FORTRAN-MEMORY*
         (+ #,(+ (GET-PROGRAM-OFFSET "FOO") 
	         37) ;For example, program-relative offset of REAL A(10)
		     ; known at compile time
	    (AREF *FORTRAN-MEMORY*
		  #,(+ (GET-PROGRAM-OFFSET "FOO")
		       47) ;eg, program-relative offset of B
	    3)))
   Surely you don't expect me to make a closure for every one of these
   values. Surely you don't expect me to give every one of these values
   a name via DEFCONSTANT. How would I do that? Even if I did, I'd need
   a ``Pratt Stack'' (ask a Maclisp implementor) since the macro would
   have to be generating prerequisite DEFCONSTANT definitions on the fly.

 - Even if I could use closure references, they compile too slowly in every
   implementation I know of. QUOTE is generally just one move. A closure
   reference invariably has to indirect through some environment pointer.

 - I definitely need the capability of creating this kind of constant
   without guaranteeing that it will not be modified. I just did a flavors
   implementation and having this object be write-protected or copied at
   will was enough to screw my ability to use this. I sent detailed mail
   to Common-lisp about this but will send more mail later to this list
   because it looks to me like people aren't seeing the importance of this.
   It comes down to the fact, though, that I needed to implement instance
   variables by:
	(AREF #,(SOME-ARRAY) n)
   where the (SOME-ARRAY) might return an array that would need to be 
   ADJUST-ARRAY'd later without losing EQ-ness so that updates to the
   ADJUST-ARRAY'd version were seen by the array that (SOME-ARRAY) returned.

That's all I have time for right now. I hope this info is of use to you.

∂01-Aug-88  1230	CL-Compiler-mailer 	LOAD-TIME-EVAL 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 1 Aug 88  12:29:56 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA16335; Mon, 1 Aug 88 13:29:04 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA00707; Mon, 1 Aug 88 13:28:59 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8808011928.AA00707@defun.utah.edu>
Date: Mon, 1 Aug 88 13:28:56 MDT
Subject: LOAD-TIME-EVAL
To: cl-compiler@sail.stanford.edu

Here is the writeup from the cleanup committee on the LOAD-TIME-EVAL
issue.  At this point, I'm leaning towards some variant of the
NEW-SPECIAL-FORM proposal, but I'd like to hear comments from the
rest of you before I do any real "work" on this.

-Sandra



Issue:		LOAD-TIME-EVAL
References:	#, (p. 356),  (EVAL-WHEN (LOAD) ...) (p. 69-70)
Category:	ADDITION
Edit history:	06-Jun-87, Version 1 by James Kempf
		17-Jul-87, Version 2 by James Kempf
		12-Nov-87, Version 3 by Pitman (alternate direction)
		01-Feb-88, Version 4 by Moon
		  (from version 2 w/ edits suggested by Masinter)
		06-Jun-88, Version 5 by Pitman
		  (fairly major overhaul, merging versions 3 and 4)
Status:		For internal discussion

Problem description:

 Common Lisp provides reader syntax (#,) which allows the programmer
 to designate that a particular expression within a program is to be
 evaluated early (at load time) but to later be treated as a constant.
 Unfortunately, no access to this capability is available to programs
 which construct other programs without going through the reader.
    
 Some computations can be deferred until load time by use of EVAL-WHEN,
 but since EVAL-WHEN must occur only at toplevel, and since the nesting
 behavior of EVAL-WHEN is quite unintuitive, EVAL-WHEN is not a general
 solution to the problem of load-time computation of program constants.

 Also, CLtL is vague about whether the result of this early evaluation
 is re-evaluated at runtime. The meaning of #,exp in an for-evaluation
 position is unclear. Although CLtL doesn't come out and say so explicitly,
 portable code must currently use only '#,exp to get consistent behavior
 across implementations.

 CLtL is also vague on whether the result of a #, expression may be
 treated as a read-only constant by the loader (and hence shared with
 other programs). Users probably want some both read-only and modifiable
 load-time constants, so this may not be simply an issue of deciding on
 a single "right answer".

Proposal (LOAD-TIME-EVAL:QUOTED-MAGIC-TOKEN):

 Add a function MAKE-LOAD-TIME-CONSTANT, as described here:

 MAKE-LOAD-TIME-CONSTANT form env &optional read-only-p		[Function]

   FORM is a Lisp form. ENV is an environment of the sort received
   by the &ENVIRONMENT argument to a macro.

   When MAKE-LOAD-TIME-CONSTANT is called from the interpreter or the
   COMPILE function, it simply evaluates FORM in the null lexical
   environment and returns its value.  When MAKE-LOAD-TIME-CONSTANT is
   called during a file compilation, the result is a special object
   that is recognized at load time, when it occurs inside a constant.
   At load time, FORM is evaluated and its value is substituted for
   the object.

   MAKE-LOAD-TIME-CONSTANT uses its ENV argument and/or dynamic state
   to determine whether it is being called during a file compilation.
   Until Common Lisp is modified to specify the semantics of file
   compilation more precisely, this is necessarily implementation
   dependent.

   The READ-ONLY-P argument designates whether the result can be considered
   read-only constant. If NIL, the result must be considered ordinary,
   modifiable data. If T, the result is a read-only quantity which may, as
   appropriate, be copied into read-only space and/or shared with other
   programs.

 Specify that '(... #,exp ...) is equivalent to
 #.`(... ,(MAKE-LOAD-TIME-CONSTANT exp NIL T) ...).

 Rationale:

   This approach is the most compatible with existing practice.

 Cost to Implementors:

   The cost to implementors will depend on how #, is implemented.
   In some implementations, the primitives for implementing 
   MAKE-LOAD-TIME-CONSTANT may already exist, in others, more substantial
   changes may be required.

 Cost to Users:

   This change is upward compatible with user code.

 Benefits:

   It would be possible for macros to expand into load time constants.

 Examples: 

   Case QUOTED-MAGIC-TOKEN-1:

     (defmacro print-software-version (&environment env)
       `(quote ,(make-load-time-constant
		  '(format T "~A~%" (software-version))
		  env)))

     When interpreted or processed during invocation of COMPILE, this
     macro prints the value of (software-version) at macro expansion
     time and expands into (quote nil).  When macroexpanded during a
     file compilation, printing is deferred until the compiled file is
     loaded, and the constant is still (quote nil).

   Case QUOTED-MAGIC-TOKEN-2:

     (defmacro table-of-tables (&rest predicates &environment env)
       `(quote ,(mapcar #'(lambda (predicate)
			    `(,predicate
			      ,(make-load-time-constant
				 `(make-hash-table :test ',predicate)
				 env)))
			predicates)))

     (table-of-tables eql equal) expands into
     (quote ((eql #<table :test eql>) (equal #<table :test equal>)))
     except that when macroexpanded during a file compilation,
     the tables are not created until load time.  This example
     shows that the <object> returned by make-load-time-constant is
     recognized even when it is interior to a quoted constant.

Proposal (LOAD-TIME-EVAL:NEW-SPECIAL-FORM):
    
 Add a new special form, LOAD-TIME-CONSTANT, which has the following
 contract:

   LOAD-TIME-CONSTANT form &optional read-only-p	[Special Form]

   All processing of the FORM is deferred until the expression is
   in the "runtime" environment. Once that environment is available,
   FORM is evaluated in the null lexical environment and the result
   is both returned and saved for immediate access by the program
   on subsequent evaluations.

   In the interpreter, the FORM may be evaluated during pre-processing
   (if any) or dynamically when the LOAD-TIME-CONSTANT is first seen
   (in a non-pre-processing implementation). If the same LOAD-TIME-CONSTANT
   expression is later seen again by the interpreter, the previously
   obtained result is immediately retrieved and returned as the result
   of evaluating the object; no re-evaluation occurs.
    
   If the LOAD-TIME-CONSTANT expression is seen by the file compiler
   (eg, COMPILE-FILE), the compiler arranges for all semantic processing
   of FORM (including macro expansion) to occur at load time in a null
   lexical environment (independent of whether any value has been cached
   for interpreter use). At runtime, the result of that evaluation will
   be treated as an immediate quantity; no re-evaluation occurs.
    
   If a LOAD-TIME-CONSTANT expression is seen by the runtime compiler
   (eg, COMPILE), the compiler checks for a cached value which may have
   been produced by the interpreter. If one is found, it is used. If no
   such value is found, the runtime compiler will evaluate the FORM in
   a null lexical environment and use that value.  The value used will be
   treated as an immediate quantity in the code which is produced; no
   re-evaluation occurs.   
    
   Note that since some implementations are compiled-only (that is, they
   implement their interpreter using a compiler pre-pass) and some are
   interpreted-only (that is, they implement their compiler as a null
   operation and use only an interpreter), the question of whether the
   interpreter or the compiler will end up doing the processing is left
   somewhat vague. The programmer may assume only that the given FORM
   will be evaluated only once for each time it is loaded into a runtime
   environment.
    
   Note, however, that in the case of quoted code (processed by explicit
   use of EVAL), each call to EVAL is treated like a load. Caching may not
   be implemented by having LOAD-TIME-CONSTANT displace its source level
   call. So while
     (DEFVAR *FOO* 1)
     (DEFUN FOO () (LOAD-TIME-CONSTANT (INCF *FOO*)))
   will increment *FOO* only once,
     (DEFUN FOO () (EVAL '(LOAD-TIME-CONSTANT (INCF *FOO*))))
   will increment *FOO* once each time FOO is called.

   The READ-ONLY-P argument designates whether the result can be considered
   read-only constant. If NIL, the result must be considered ordinary,
   modifiable data. If T, the result is a read-only quantity which may, as
   appropriate, be copied into read-only space and/or shared with other
   programs. (Because this is a special form, this argument is -not- evaluated
   and only the literal symbols T and NIL are permitted.)

 Make #,exp be equivalent to (LOAD-TIME-CONSTANT exp T). As such, it
 would -always- appear in a for-evaluation position, and never inside quoted
 structure.

 Rationale:
    
   By making the description of LOAD-TIME-CONSTANT defined as a special
   form, we eliminate the need for it to take an environment argument.

   By making #, agree with LOAD-TIME-CONSTANT in terms of where it may be
   used, we simplify the description of the resulting language.

   As discussed in more detail elsewhere in this proposal, the #, syntax
   is currently only reliably useful -inside- quoted structure, but this
   is unnecessarily complicated for most known uses. Since this proposal
   suggests a meaning for #, only -outside- quoted structure, it is an
   incompatible change (though not one that would necessarily require
   vendors to immediately remove support for existing code).

 Cost to Implementors:

   This is an incompatible change to the program interface.
   The cost is not trivial, but is not particularly high.
   Most of the "hard" substrate required to support this proposal
   probably already exist; in most cases, what needs to change is
   only the way in which the substrate is presented to the
   programmer.

   Some code-walkers would have to be taught about this new
   special form. Such changes would likely be trivial.

 Cost to Users:

   Very few users probably use #, right now. A very small amount of code
   might need to be rewritten (and recompiled).

   The following kinds rewrites exemplify the total amount of work needed
   in the few situations that use #, currently:
      '#,exp           => #,exp
      '(... #,exp ...) => #,`(... ,exp ...)
      `(... #,exp ...) => `(... ,#,exp ...)

   Some user-defined code-walkers would have to be taught about
   this new special form. Such changes would also be likely be trivial.

   Although change to #, is an incompatible one, vendors would be free to
   provide compatibility support for the old behavior for whatever period
   they deemed appropriate. #, is equivalent to, but not the same as,
   (LOAD-TIME-CONSTANT exp T), so it might in fact expand into
   (SYSTEM::LOAD-TIME-CONSTANT exp T) which might be both a macro that
   expanded into (LOAD-TIME-CONSTANT exp T). SYSTEM::LOAD-TIME-CONSTANT
   might be a magic token which was treated specially within quoted 
   structure as an unportable extension during a transition period.

 Benefits:

   Relatively consistent interpreter/compiler treatment of this special form
   would be possible.

   Pretty printing expressions in which LOAD-TIME-CONSTANT occurred would be
   possible.

   An expression such as `(... #,(... , ...) ...) would be meaningful.

   Manipulating expressions involving uses of LOAD-TIME-CONSTANT would be
   possible. Currently, calling READ is enough to trigger resolution of the
   constant, so a program doing file-to-file source code rewrites must
   either use a special readtable or resign itself to premature resolution
   of load time constants.

   Expressions involving quoted LOAD-TIME-CONSTANT expressions would be
   possible to quote. Currently, the #, feature is syntactic, not semantic,
   and so is not sensitive to levels of quotation. You can refer to a
   load time constant by writing '#,exp but you cannot refer in turn to that
   expression which refers to a load time constant by writing ''#,exp .
   Under this NEW-SPECIAL-FORM proposal #,exp and '#,exp and ''#,exp (and
   so on) are all usefully distinct.

   It would be possible to use , in a #, expression. For example, the
expression:

 Examples:

   Case NEW-SPECIAL-FORM-1:

     (defmacro print-load-timestamp ()
       `(print (load-time-constant
		 `(load-timestamp ,(incf *foo*) ,(get-universal-time))
		  t)))
     (defvar *foo* 0)
     (defun test-1 () (print-load-timestamp))
     (test-1)
      
     CLtL does not define this situation.
     Under this proposal, this code would print
	(LOAD-TIMESTAMP 1 <<a-universal-time>>)
     at the time the test case is loaded, whether interpreted or compiled.
     Subsequent calls to (TEST-1) should print the identical expression.
     Currently, no known implementation supports the proposed behavior.

  Case NEW-SPECIAL-FORM-2:

     (defun test-2 () (print #,'(+ 3 4)))
    
     CLtL does not adequately define this situation.
     Under this proposal, this would print (+ 3 4), whether interpreted
     or compiled.

     Currently, some compilers complain about the syntax, some arrange for
     it to print (+ 3 4), and some arrange forit to print the result of
     (+ 3 4), or 7.
    
  Case NEW-SPECIAL-FORM-3:

     (defun test-3 () (print '#,'(+ 3 4)))
    
     Under CLtL, this would print (+ 3 4).
     Under this proposal, the behavior would be undefined.
     Currently, most implementations support the proposed behavior.
    
  Case NEW-SPECIAL-FORM-4:

     (pprint '(+ x #,(sqrt x)))

     prints something re-readable like
	(+ X #,(SQRT 2)) or (+ X (LOAD-TIME-CONSTANT (SQRT 2) T))
     but not something like
	(+ X 1.4142135)
     Currently, no implementation is known to already support the
     proposed behavior, but in principle it is possible for a valid
     implementation to already do so.

   Case NEW-SPECIAL-FORM-5:

     (defmacro foo (x y)
       `(member ,x #,`(foo ,,y baz)))
     (macroexpand '(foo *bar*)) => ??

     Under CLtL, this situation is not adequately defined.
     Under this proposal, the macroexpansion would be 
     (member foo #,`(foo ,*bar* baz))
     Currently, this triggers a read error such as "comma not in backquote"
     or "SYSTEM::BACKQUOTE-COMMA undefined function" in most
     implementations.

Current practice:

 Although most implementations provide a substrate which would allow
 program-mediated access to load time evaluation in some way, the language
 only defines access to this substrate through the sharpsign read syntax.

Costs of Non-Adoption: 

 There are numerous possible uses for this facility. Among them are:
   * Version control and system building facilities.
   * The Common Lisp Object System.
   * Language translators which desire to emulate "linking".
  While every implementation of Common Lisp could certainly provide an
  implementation specific facility capable of supporting such facilities,
  portability of such facilities would suffer.
  
Benefits:

 Portability and extended language power.  The nature of each proposed
 extension is such as to enable other extensions to be added more
 gracefully. The Common Lisp Object System is a clear example.

Aesthetics:
    
 These proposals fill a hole in the spectrum of alternatives for
 deferring evaluation until a compiled file is loaded. Currently, code
 which is read by the reader can arrange for it to be done, as can
 top level code, but embedded code cannot. As such, these proposals
 clarify and regularize existing parts of the language. Also, by
 adding program-accessible entry points to facilities already provided
 in a more contrived way, it makes the language easier to use.

Discussion:
    
 There is likely to be some controversy about this proposal, since
 there is no universally agreed upon formal processing model for
 Common Lisp.
    
 The cleanup committee seems to generally approve of the idea of a
 load-time-eval capability, but a number of the details seem to need
 ironing out.
    
 Moon supported a previous draft of QUOTED-MAGIC-TOKEN. In this draft,
 KMP changed the presentation and also added the READ-ONLY-P argument
 in order to make it sit nicely with the alternate proposal, 
 NEW-SPECIAL-FORM. It's more than slightly possible that after all this
 editing, Moon will have some problems with this version and want to
 submit a refined draft.

 Pitman supports NEW-SPECIAL-FORM.

 Rees has expressed strong support for the idea of implementing #, as a 
 new special form rather than perpetuating the current state of affairs.
 He had some input into the high-level content of this proposal, though
 he hasn't reviewed any drafts. This paragraph is intended primarily to
 incite him to say something definitive one way or the other.


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

**** End of Forwarded Message ****
-------

∂07-Aug-88  1704	CL-Compiler-mailer 	new issues
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Aug 88  17:04:00 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA00985; Sun, 7 Aug 88 18:03:17 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA01290; Sun, 7 Aug 88 12:18:35 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8808071818.AA01290@defun.utah.edu>
Date: Sun, 7 Aug 88 12:18:34 MDT
Subject: new issues
To: cl-compiler@sail.stanford.edu

A reminder that we promised to have proposals on issues LOAD-TIME-EVAL
and COMPILED-CONSTANTS ready for the next meeting.  As far as
LOAD-TIME-EVAL is concerned, I support the proposal NEW-SPECIAL-FORM
that was written up by Pitman, but I haven't heard anything from any
of you on this issue since I mailed it around.  Should I assume that
nobody cares one way or the other?

-Sandra
-------

∂07-Aug-88  1704	CL-Compiler-mailer 	Issues from last meeting 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Aug 88  17:04:02 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA00989; Sun, 7 Aug 88 18:03:19 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA01282; Sun, 7 Aug 88 12:12:30 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8808071812.AA01282@defun.utah.edu>
Date: Sun, 7 Aug 88 12:12:29 MDT
Subject: Issues from last meeting
To: cl-compiler@sail.stanford.edu

Well, our suggested August 1 deadline for comments on the three
proposals that were distributed at the last meeting has come and
gone, and the only comment I'm aware of getting is the following
from Steve:

  Date: Mon, 20 Jun 88 22:36:10 EDT
  From: franz!feast!smh@ucbarpa.Berkeley.EDU (Steven M. Haflich)
  Subject: non-top-level DEFUN
  
  Perhaps I've been on another planet, but I just realized a serious
  problem with non-top-level function-defining DEF* forms.
  
  Our interpreter will already handle the following without problem:
  
  (let ((*foo* 3))
    (defun set-foo (x) (setq *foo* x))
    (defun get-foo (y) (cons *foo* y)))
  
  So will our COMPILE-FILE.  The problem comes when the above forms are
  entered interpreted and subsequently a (COMPILE 'GET-FOO) is executed.
  Interpreted and compiled closures have entirely different
  representation, and it is impossible for compiled and interpreted
  functions to share a closure.  It would appear that the original CLtL
  rules on closures and compilation are designed to permit this freedom,
  although use of (SETF (SYMBOL-FUNCTION XXX #'(...))) can obviously
  create named interpreted closure functions which subsequently one
  could attempt to compile.  No one has yet complained ...
  
  I wonder if any other implementations will suffer the same problem?
  Has anyone yet thought about this?  Is the non-top-level-defun change
  less compatible than we thought?  Obviously, the compiler and
  interpreter could be unified, but efficiency might suffer.

I agree that this is a problem.  I see three possible solutions:

(1) Require all implementations to be able to have closures shared by
    interpreted and compiled functions.

(2) State that it is an error to COMPILE a function defined in a non-null
    lexical environment.

(3) Throw out our current proposal for DEFINING-MACROS-NON-TOP-LEVEL and
    go back to the drawing board.

I believe that solution (2) is a reasonable compromise between the
other two extremes.  In fact, I think this should be a proposal
separate from DEFINING-MACROS-NON-TOP-LEVEL since the issue can come
up even without using a DEFUN inside of a LET (as by SETF'ing the
SYMBOL-FUNCTION to a function defined in a non-null environment).  The
current language in CLtL is not very clear on this issue anyway -- if
you provide a definition to COMPILE it must be a (quoted) lambda
expression, and if you don't it says the symbol's definition must be a
lambda expression.  This is already nonsensical because the
FUNCTION-TYPE proposal accepted at the last meeting states that the
SYMBOL-FUNCTION must contain a FUNCTION, not a lambda expression.
I'll sketch out a proposal on this unless somebody comes up with a
better idea in the next couple of days.

-Sandra
-------

∂08-Aug-88  0912	CL-Compiler-mailer 	issue COMPILE-ARGUMENT-PROBLEMS    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 8 Aug 88  09:11:54 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA21256; Mon, 8 Aug 88 10:11:07 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA01749; Mon, 8 Aug 88 10:11:03 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8808081611.AA01749@defun.utah.edu>
Date: Mon, 8 Aug 88 10:11:01 MDT
Subject: issue COMPILE-ARGUMENT-PROBLEMS
To: cl-compiler@sail.stanford.edu

Here's the writeup -- comments, flames, etc. are welcome....

-Sandra


Issue:		COMPILE-ARGUMENT-PROBLEMS
References:	CLtL p. 438-439
		Issue FUNCTION-TYPE
		Issue DEFINING-MACROS-NON-TOP-LEVEL
Category:	CLARIFICATION, CHANGE
Edit History:   V1, Sandra Loosemore  (8 Aug 1988)


Problem Description:

The description of what arguments can legitimately be passed to the
function COMPILE in CLtL is too vague.  There are two specific
problems:

(1) Acceptance of the FUNCTION-TYPE proposal makes it nonsensical to
speak of a lambda-expression being an interpreted function (it is not)
or to require a symbol to have a lambda-expression as its definition
(the SYMBOL-FUNCTION must be a true FUNCTION object).

(2) Many implementations cannot correctly compile functions that are
defined interpretively in a non-null lexical environment, because the
compiler and interpreter use different representations for closures.
Although this problem arose in conjunction with the
DEFINING-MACROS-NON-TOP-LEVEL proposal, the situation can also arise
if SETF is used to store a lexical closure in the SYMBOL-FUNCTION of
the symbol. 


Proposal COMPILE-ARGUMENT-PROBLEMS:CLARIFY:

If the optional "definition" argument to COMPILE is supplied, it may
be either a lambda expression (which is coerced to a function) or a
function to be compiled.  Otherwise, the SYMBOL-FUNCTION of the symbol
is extracted and compiled.  It is an error if the function to be
compiled was defined interpretively in a non-null lexical environment,
or if it is already compiled.


Rationale:

Saying "it is an error" to try to compile the wrong kind of function
allows implementations that can compile functions defined in a
non-null lexical environment to go ahead and do so. 


Current Practice:

Implementations that do not allow sharing of lexical environments
between compiled and interpreted functions include VaxLisp, Allegro
CL, and Lucid.  Lucid already accepts an interpreted function object
as the "definition" argument to COMPILE.


Cost to implementors:

Most of the changes required for this proposal are already necessary
to correctly implement the FUNCTION-TYPE proposal.  The primary addition
is that COMPILE must be extended to accept a FUNCTION object as well
as a lambda expression as the "definition" argument.


Cost to users:

None.  This is an upward-compatible change, since a lambda expression
can still be passed as an argument to COMPILE.  Also, since most
existing implementations refuse to compile a function with a non-empty
lexical environment, user code which depends on being able to do this
is already nonportable. 


Benefits:

An area of ambiguity in the language is resolved.


Discussion:

An alternative behavior when trying to COMPILE as function that is
already compiled would be to do nothing.
-------

∂08-Aug-88  0919	CL-Compiler-mailer 	Re:  new issues
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 8 Aug 88  09:19:46 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA29321; Mon, 8 Aug 88 09:17:04 PDT
Received: from clam.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA11988; Mon, 8 Aug 88 09:17:48 PDT
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA04212; Mon, 8 Aug 88 09:20:14 PDT
Date: Mon, 8 Aug 88 09:20:14 PDT
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8808081620.AA04212@clam.sun.com>
To: cl-compiler@sail.stanford.edu, sandra%defun@cs.utah.edu
Subject: Re:  new issues

In the past I have proposed eliminating "#,", but some examples
of its use and further thinking make me believe that it is valuable.

I particularly favor making it expand into a new special form
because that is such a straightforward proposal.

Basically, I now feel that the reasons for #, versus named constants
are about the same as for inline quoted constants.

				-Cris

∂12-Aug-88  0756	CL-Compiler-mailer 	issue LOAD-TIME-EVAL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 12 Aug 88  07:56:30 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA01602; Fri, 12 Aug 88 08:55:12 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA03934; Fri, 12 Aug 88 08:55:09 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8808121455.AA03934@defun.utah.edu>
Date: Fri, 12 Aug 88 08:55:08 MDT
Subject: issue LOAD-TIME-EVAL
To: cl-compiler@sail.stanford.edu
Cc: kmp@stony-brook.scrc.symbolics.com

Here are some of my thoughts on cleaning up the existing proposal for
LOAD-TIME-EVAL:NEW-SPECIAL-FORM.  I haven't yet heard anybody
objecting to discarding the QUOTED-MAGIC-TOKEN proposal on the same
issue -- speak now or forever hold your peace! 


   LOAD-TIME-CONSTANT form &optional read-only-p	[Special Form]

   All processing of the FORM is deferred until the expression is
   in the "runtime" environment. Once that environment is available,
   FORM is evaluated in the null lexical environment and the result
   is both returned and saved for immediate access by the program
   on subsequent evaluations.

   In the interpreter, the FORM may be evaluated during pre-processing
   (if any) or dynamically when the LOAD-TIME-CONSTANT is first seen
   (in a non-pre-processing implementation). If the same LOAD-TIME-CONSTANT
   expression is later seen again by the interpreter, the previously
   obtained result is immediately retrieved and returned as the result
   of evaluating the object; no re-evaluation occurs.

There is some possible confusion over what "the same LOAD-TIME-CONSTANT 
expression" means; in particular, is it the entire LOAD-TIME-CONSTANT 
form or the evaluable form inside of it that is compared?  What predicate 
is used to compare them -- EQ or EQUAL?  And, is it the *reference* to
the LOAD-TIME-CONSTANT form that is checked, or the form itself -- 
something which makes a big difference given that there may be multiple
references to the same code fragment?  In other words, is it a legitimate 
implementation technique for the interpreter to destructively bash the 
list (LOAD-TIME-EVAL <foo>) into (QUOTE <what-foo-evaluates-to>)?
    
   If the LOAD-TIME-CONSTANT expression is seen by the file compiler
   (eg, COMPILE-FILE), the compiler arranges for all semantic processing
   of FORM (including macro expansion) to occur at load time in a null
   lexical environment (independent of whether any value has been cached
   for interpreter use). At runtime, the result of that evaluation will
   be treated as an immediate quantity; no re-evaluation occurs.

Doing macro expansion in a null lexical environment makes this behave
more like (EVAL-WHEN (COMPILE) ...) than (EVAL-WHEN (LOAD) ...).  
    
   If a LOAD-TIME-CONSTANT expression is seen by the runtime compiler
   (eg, COMPILE), the compiler checks for a cached value which may have
   been produced by the interpreter. If one is found, it is used. If no
   such value is found, the runtime compiler will evaluate the FORM in
   a null lexical environment and use that value.  The value used will be
   treated as an immediate quantity in the code which is produced; no
   re-evaluation occurs.   

Is the compiler supposed to cache the value of FORM for later use by
the interpreter?  Again, this is a concern if there are multiple
references to the same expression.

-Sandra




-------

∂14-Aug-88  0905	CL-Compiler-mailer 	issue LOAD-TIME-EVAL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Aug 88  09:05:02 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA00418; Sun, 14 Aug 88 10:03:52 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA03499; Thu, 11 Aug 88 14:52:58 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8808112052.AA03499@defun.utah.edu>
Date: Thu, 11 Aug 88 14:52:56 MDT
Subject: issue LOAD-TIME-EVAL
To: cl-compiler@sail.stanford.edu
Cc: kmp@stony-brook.scrc.symbolics.com, moon@stony-brook.scrc.symbolics.com

Here are some of my thoughts on cleaning up the existing proposal for
LOAD-TIME-EVAL:NEW-SPECIAL-FORM.  I haven't yet heard anybody
objecting to discarding the QUOTED-MAGIC-TOKEN proposal on the same
issue -- speak now or forever hold your peace! 


   LOAD-TIME-CONSTANT form &optional read-only-p	[Special Form]

   All processing of the FORM is deferred until the expression is
   in the "runtime" environment. Once that environment is available,
   FORM is evaluated in the null lexical environment and the result
   is both returned and saved for immediate access by the program
   on subsequent evaluations.

   In the interpreter, the FORM may be evaluated during pre-processing
   (if any) or dynamically when the LOAD-TIME-CONSTANT is first seen
   (in a non-pre-processing implementation). If the same LOAD-TIME-CONSTANT
   expression is later seen again by the interpreter, the previously
   obtained result is immediately retrieved and returned as the result
   of evaluating the object; no re-evaluation occurs.

There is some possible confusion over what "the same LOAD-TIME-CONSTANT 
expression" means; in particular, is it the entire LOAD-TIME-CONSTANT 
form or the evaluable form inside of it that is compared?  What predicate 
is used to compare them -- EQ or EQUAL?  And, is it the *reference* to
the LOAD-TIME-CONSTANT form that is checked, or the form itself -- 
something which makes a big difference given that there may be multiple
references to the same code fragment?  In other words, is it a legitimate 
implementation technique for the interpreter to destructively bash the 
list (LOAD-TIME-EVAL <foo>) into (QUOTE <what-foo-evaluates-to>)?
    
   If the LOAD-TIME-CONSTANT expression is seen by the file compiler
   (eg, COMPILE-FILE), the compiler arranges for all semantic processing
   of FORM (including macro expansion) to occur at load time in a null
   lexical environment (independent of whether any value has been cached
   for interpreter use). At runtime, the result of that evaluation will
   be treated as an immediate quantity; no re-evaluation occurs.

Doing macro expansion in a null lexical environment makes this behave
more like (EVAL-WHEN (COMPILE) ...) than (EVAL-WHEN (LOAD) ...).  
    
   If a LOAD-TIME-CONSTANT expression is seen by the runtime compiler
   (eg, COMPILE), the compiler checks for a cached value which may have
   been produced by the interpreter. If one is found, it is used. If no
   such value is found, the runtime compiler will evaluate the FORM in
   a null lexical environment and use that value.  The value used will be
   treated as an immediate quantity in the code which is produced; no
   re-evaluation occurs.   

Is the compiler supposed to cache the value of FORM for later use by
the interpreter?  Again, this is a concern if there are multiple
references to the same expression.

-Sandra
-------

∂14-Aug-88  0905	CL-Compiler-mailer 	issue LOAD-TIME-EVAL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Aug 88  09:05:10 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA00452; Sun, 14 Aug 88 10:04:07 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA03904; Fri, 12 Aug 88 08:39:08 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8808121439.AA03904@defun.utah.edu>
Date: Fri, 12 Aug 88 08:39:07 MDT
Subject: issue LOAD-TIME-EVAL
To: cl-compiler@sail.stanford.edu
Cc: kmp@stony-brook.scrc.symbolics.com, moon@stony-brook.scrc.symbolics.com

Here are some of my thoughts on cleaning up the existing proposal for
LOAD-TIME-EVAL:NEW-SPECIAL-FORM.  I haven't yet heard anybody
objecting to discarding the QUOTED-MAGIC-TOKEN proposal on the same
issue -- speak now or forever hold your peace! 


   LOAD-TIME-CONSTANT form &optional read-only-p	[Special Form]

   All processing of the FORM is deferred until the expression is
   in the "runtime" environment. Once that environment is available,
   FORM is evaluated in the null lexical environment and the result
   is both returned and saved for immediate access by the program
   on subsequent evaluations.

   In the interpreter, the FORM may be evaluated during pre-processing
   (if any) or dynamically when the LOAD-TIME-CONSTANT is first seen
   (in a non-pre-processing implementation). If the same LOAD-TIME-CONSTANT
   expression is later seen again by the interpreter, the previously
   obtained result is immediately retrieved and returned as the result
   of evaluating the object; no re-evaluation occurs.

There is some possible confusion over what "the same LOAD-TIME-CONSTANT 
expression" means; in particular, is it the entire LOAD-TIME-CONSTANT 
form or the evaluable form inside of it that is compared?  What predicate 
is used to compare them -- EQ or EQUAL?  And, is it the *reference* to
the LOAD-TIME-CONSTANT form that is checked, or the form itself -- 
something which makes a big difference given that there may be multiple
references to the same code fragment?  In other words, is it a legitimate 
implementation technique for the interpreter to destructively bash the 
list (LOAD-TIME-EVAL <foo>) into (QUOTE <what-foo-evaluates-to>)?
    
   If the LOAD-TIME-CONSTANT expression is seen by the file compiler
   (eg, COMPILE-FILE), the compiler arranges for all semantic processing
   of FORM (including macro expansion) to occur at load time in a null
   lexical environment (independent of whether any value has been cached
   for interpreter use). At runtime, the result of that evaluation will
   be treated as an immediate quantity; no re-evaluation occurs.

Doing macro expansion in a null lexical environment makes this behave
more like (EVAL-WHEN (COMPILE) ...) than (EVAL-WHEN (LOAD) ...).  
    
   If a LOAD-TIME-CONSTANT expression is seen by the runtime compiler
   (eg, COMPILE), the compiler checks for a cached value which may have
   been produced by the interpreter. If one is found, it is used. If no
   such value is found, the runtime compiler will evaluate the FORM in
   a null lexical environment and use that value.  The value used will be
   treated as an immediate quantity in the code which is produced; no
   re-evaluation occurs.   

Is the compiler supposed to cache the value of FORM for later use by
the interpreter?  Again, this is a concern if there are multiple
references to the same expression.

-Sandra
-------

∂14-Aug-88  1254	CL-Compiler-mailer 	multiple copies
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Aug 88  12:54:10 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA06488; Sun, 14 Aug 88 13:53:23 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA05122; Sun, 14 Aug 88 13:53:20 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8808141953.AA05122@defun.utah.edu>
Date: Sun, 14 Aug 88 13:53:19 MDT
Subject: multiple copies
To: cl-compiler@sail.stanford.edu

Sorry about the multiple copies of my last message -- the mailer got
wedged when I first tried to send it and apparently it later got
unwedged.

-Sandra
-------

∂16-Aug-88  1547	CL-Compiler-mailer 	issue LOAD-TIME-EVAL
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Aug 88  15:47:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 447294; 16 Aug 88 18:02:29 EDT
Date: Tue, 16 Aug 88 18:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue LOAD-TIME-EVAL
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@SAIL.STANFORD.EDU, kmp@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8808112052.AA03499@defun.utah.edu>
Message-ID: <19880816220221.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 11 Aug 88 14:52:56 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    Here are some of my thoughts on cleaning up the existing proposal for
    LOAD-TIME-EVAL:NEW-SPECIAL-FORM.  I haven't yet heard anybody
    objecting to discarding the QUOTED-MAGIC-TOKEN proposal on the same
    issue -- speak now or forever hold your peace! 

Consider this a speech.

       LOAD-TIME-CONSTANT form &optional read-only-p	[Special Form]

       All processing of the FORM is deferred until the expression is
       in the "runtime" environment. Once that environment is available,
       FORM is evaluated in the null lexical environment and the result
       is both returned and saved for immediate access by the program
       on subsequent evaluations.

       In the interpreter, the FORM may be evaluated during pre-processing
       (if any) or dynamically when the LOAD-TIME-CONSTANT is first seen
       (in a non-pre-processing implementation). If the same LOAD-TIME-CONSTANT
       expression is later seen again by the interpreter, the previously
       obtained result is immediately retrieved and returned as the result
       of evaluating the object; no re-evaluation occurs.

I don't know what "all processing" means.  For example, does this forbid
the compiler from performing optimizations that it might perform on other
expressions in a file being compiled?  Or does it just mean evaluation?

    There is some possible confusion over what "the same LOAD-TIME-CONSTANT 
    expression" means; in particular, is it the entire LOAD-TIME-CONSTANT 
    form or the evaluable form inside of it that is compared?  What predicate 
    is used to compare them -- EQ or EQUAL?  And, is it the *reference* to
    the LOAD-TIME-CONSTANT form that is checked, or the form itself -- 
    something which makes a big difference given that there may be multiple
    references to the same code fragment?  In other words, is it a legitimate 
    implementation technique for the interpreter to destructively bash the 
    list (LOAD-TIME-EVAL <foo>) into (QUOTE <what-foo-evaluates-to>)?
    
All of these issues would be avoided by using something more compatible
with the way the #, reader syntax works.  I don't recall a quoted-magic-token
proposal (perhaps I have not read it yet), but a technique where the
primitive offered is a way to create a data object that can be used
only inside a quoted constant would avoid all these problems, as long
as we know what "the same" means for quoted constants, and I think we do.

The primitive should be a function, not a special form, and should take
two arguments, a form and an optional macroexpansion environment.  The
form is either evaluated immediately in the null lexical environment
(when not compiling to a file) and its value returned, or encapsulated
in a magic compiler/loader recognizable object (when compiling to a file)
and evaluated in the null lexical environment later when the file is loaded.
The purpose of the macroexpansion environment argument is to distinguish
whether the quoted constant being constructed is destined for the current
environment or for a compiler output file [I believe this is a pending
issue, unless it's been resolved recently.]

I don't believe in the read-only-p argument, since I believe all constants
are inherently read-only, and that anyone using constants to simulate
variables (as some Interlisp programs do) should be using variables instead.

(defmacro load-time-constant (form &environment env)
  `(quote ,(sharp-comma form env)))

       If the LOAD-TIME-CONSTANT expression is seen by the file compiler
       (eg, COMPILE-FILE), the compiler arranges for all semantic processing
       of FORM (including macro expansion) to occur at load time in a null
       lexical environment (independent of whether any value has been cached
       for interpreter use). At runtime, the result of that evaluation will
       be treated as an immediate quantity; no re-evaluation occurs.

    Doing macro expansion in a null lexical environment makes this behave
    more like (EVAL-WHEN (COMPILE) ...) than (EVAL-WHEN (LOAD) ...).  
    
       If a LOAD-TIME-CONSTANT expression is seen by the runtime compiler
       (eg, COMPILE), the compiler checks for a cached value which may have
       been produced by the interpreter. If one is found, it is used. If no
       such value is found, the runtime compiler will evaluate the FORM in
       a null lexical environment and use that value.  The value used will be
       treated as an immediate quantity in the code which is produced; no
       re-evaluation occurs.   

    Is the compiler supposed to cache the value of FORM for later use by
    the interpreter?  Again, this is a concern if there are multiple
    references to the same expression.

The above couple paragraphs seem to be examples of the confusion rampant
in Common Lisp, between two meanings of "the compiler."  One is "a program
that makes programs run faster by converting them to machine instructions",
the other is "a program that makes files load faster by converting them to
a binary format."  While these are often used together, only the second
form of compiler is relevant to #,.  I think understanding this distinction
ought to clear things up.

∂22-Aug-88  1520	CL-Compiler-mailer 	Re: Issues from last meeting  
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 22 Aug 88  15:17:32 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa05894; 22 Aug 88 22:52 BST
Date: Mon, 22 Aug 88 23:09:05 BST
Message-Id: <27472.8808222209@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issues from last meeting
To: sandra <@cs.utah.edu (Sandra J Loosemore):sandra@defun>, 
    sandra <@cs.utah.edu:sandra@defun>, cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Sun, 7 Aug 88 12:12:29 MDT

About the question of (COMPILE 'F), where F was defined in a non-null
lexical environment.  As Steve pointed out, this is already a problem
in CL because of SETF of SYMBOL-FUNCTION.  I agree with the suggestion
that it be "an error" to call COMPILE on function of this sort unless
someone can show that it is easy to compile them without requiring that
interpreted and compiled code use the same representation for closures.

The inability to compile such functions is widespread.  I just ran
into it in Lucid2.1.  What I ended up doing is this:

	(defun zz () (let (...) (defun f ...)))
	(compile 'zz)
	(zz)

which is not-very-nice and works only for cases reasonably near the
top-level.

-- Jeff

∂01-Sep-88  1437	CL-Compiler-mailer 	October meeting
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 1 Sep 88  14:37:02 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA13136; Thu, 1 Sep 88 15:36:01 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA12052; Thu, 1 Sep 88 15:35:58 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809012135.AA12052@defun.utah.edu>
Date: Thu, 1 Sep 88 15:35:57 MDT
Subject: October meeting
To: cl-compiler@sail.stanford.edu

Since the October X3J13 meeting is now less than 6 weeks away (the
week of October 10), it is time for us to start making plans.

I would like to plan on having a subcommittee meeting on Monday,
preferably in the afternoon.  I think the major constraint we have is
that it shouldn't conflict with the cleanup committee's meeting,
whenever that's going to be.

I think we are ready to call for a vote on the three issues that were
distributed last time, plus issue COMPILE-ARGUMENT-PROBLEMS.  I'm also
sending around a proposal for issue COMPILE-FILE-PACKAGE, which I hope
is noncontroversial enough that we could try to vote on it as well.
If you have anything you want incorporated into these proposals,
please let me know ASAP, since the proposals are supposed to be in the
hands of the full committee at least two weeks before voting on them.

There are also two other issues for which I would like to get draft
proposals distributed, namely LOAD-TIME-EVAL (which I'm working on),
and COMPILED-CONSTANTS (Cris Perdue).

On issue LOAD-TIME-EVAL, it seemed like of the people who responded,
most expressed a vague approval for the idea of introducing a new
special form (except for Moon, who has strong objections).  However,
there are some specific problems with the current proposal and my last
ramblings on it produced no response at all from the rest of you.  I
really need some help with this, folks!  I have no feeling whatsoever
about what the consensus is -- whether Moon's objections are shared by
others, whether I should just proceed to make some arbitrary decisions
to fix the problems in the existing proposal, or what.  Please try to
spend a few minutes on this issue....

-Sandra
-------

∂01-Sep-88  1436	CL-Compiler-mailer 	issue COMPILE-FILE-PACKAGE    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 1 Sep 88  14:36:19 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA13094; Thu, 1 Sep 88 15:35:17 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA12046; Thu, 1 Sep 88 15:35:08 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809012135.AA12046@defun.utah.edu>
Date: Thu, 1 Sep 88 15:35:07 MDT
Subject: issue COMPILE-FILE-PACKAGE
To: cl-compiler@sail.stanford.edu

Issue:		COMPILE-FILE-PACKAGE
References:	CLtL p. 182, 183
Category:	CHANGE, CLARIFICATION
Edit History:   1 Sep 1988, Sandra Loosemore (initial version)


Problem Description:

The variable *PACKAGE* is rebound by the function LOAD, so that its
old value will be restored in spite of any calls to IN-PACKAGE
appearing in the file being loaded.  Since COMPILE-FILE must evaluate
any top-level calls to IN-PACKAGE that it sees, it may also alter the
value of *PACKAGE*.  It is inconsistent to have COMPILE-FILE and LOAD
behave differently regarding the rebinding of this variable.


Proposal COMPILE-FILE-PACKAGE:REBIND:

Require COMPILE-FILE to rebind *PACKAGE* before processing the file.


Rationale:

This makes COMPILE-FILE and LOAD more consistent.  It is a more
compatible solution than either requiring LOAD not to rebind
*PACKAGE*, or removing the specialness of IN-PACKAGE and the other
package functions.


Current Practice:

Lucid Common Lisp already implements this proposal.


Cost to implementors:

Trivial.


Cost to users:

I find it hard to believe that users would consider COMPILE-FILE altering
the value of *PACKAGE* as a useful side effect.


Benefits:

The language is made more uniform.


Discussion:
-------

∂02-Sep-88  1420	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 2 Sep 88  14:20:02 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA11348; Fri, 2 Sep 88 15:19:00 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA12649; Fri, 2 Sep 88 15:18:55 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809022118.AA12649@defun.utah.edu>
Date: Fri, 2 Sep 88 15:18:53 MDT
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY
To: cl-compiler@sail.stanford.edu

Here is a draft of another proposal dealing with what the compiler may
"wire in" to the code it is compiling.  It is roughly based on a
section of RAM's well-known "Compiler Cleanup Proposal #3", with a
couple of additions and some changes in terminology.  It's my
impression that most implementations are already pretty close to this
proposal, but if I'm wrong and there's something that's going to give
you grief, speak up!

-Sandra


Issue:		COMPILE-ENVIRONMENT-CONSISTENCY
References:	CLtL p. 143, 321
		RAM's "Compiler Cleanup Proposal #3"
Category:	CLARIFICATION
Edit History:   V1, 2 Sep 1988, Sandra Loosemore (initial draft)


Problem Description:

CLtL does not clearly specify what aspects of the compiletime
environment the compiler (or other preprocessor) may "wire in" to code
being compiled.


Proposal COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY:

Common Lisp deliberately leaves unspecified the time at which certain
transformations, such as macro expansion, are performed within a
program.  While some implementations perform such transformations
concurrently with evaluation, it is also legitimate to perform
transformations during a preprocessing phase.  For example, an
implementation might choose to apply transformations at "function
promotion time" (i.e., transformations are applied once during
evaluation of a surrounding FUNCTION special form), or to completely
transform each top-level form and all of its subforms before
performing any evaluation.  User programs cannot portably depend upon
either the time of such transformations, or the number of times the
transformations are applied.

In all cases, however, compiling a program (with COMPILE or
COMPILE-FILE) provides a mechanism for forcing these transformations
to be applied and a guarantee that, once compiled, no further
transformations will be applied to that program.

In the discussion that follows, the term "compiler" is to be understood
to include other preprocessors as well.  Likewise, the "compiletime
environment" refers to the environment in which program transformations
occur, while "runtime" refers to the time the program is executed.


(1) The following information *must* be present in the compiletime
environment for the preprocessor to apply the correct transformations.
This information need not also be present in the runtime environment.

    (a) Macro definitions must be available in the compiletime environment.
	The compiler may assume that forms that are lists beginning with
	a symbol that does not name a macro or special form is a function
	call.  (This implies that SETF methods must also be available at
	compiletime.)

    (b) Special variables must be declared as such before they are bound.
	The compiler must treat any undeclared variable binding as a
	lexical binding.


(2) The compiler *may* assume that, if any of the following kinds of
information is present in the compiletime environment, the same information
will also be present in the runtime environment.  In all of these cases,
the absence of the information at compiletime is not an error, but its
presence may enable the compiler to do a better job.

    (a) The compiler may assume that functions which are defined and
	declared INLINE in the compiletime environment will retain the
	same definition in the runtime environment.

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

    (c) The compiler may assume that the signature of 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.

    (d) The compiler may assume that symbols which have been defined as
	constants (using DEFCONSTANT) in the compiletime environment
	will retain the same value in the runtime environment.

    (e) Types that are defined with DEFTYPE or DEFSTRUCT can be assumed to
	retain the same definition in the runtime environment as in the
	compiletime environment.  (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.)

    (f) The compiler may assume that type proclamations for global 
	variables and functions which are present in the compiletime
	environment will also be present in the runtime environment.



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

    (a) The compiler may not assume that functions that are defined
	in the compiletime environment that have not been declared
	INLINE, other than built-in Common Lisp functions, will retain
	either the same definition or the same signature at runtime.
	It is, however, reasonable for the compiler to emit warning 
	messages about calls to functions that are defined in at
	compiletime, but where the wrong number or type of arguments
	are supplied.

	

Rationale:

This proposal generally reflects current practice.


Current Practice:

I know of no compiler that does not implement the provisions of item (1).

For item (2), most compilers (including Lucid) optimize self-recursive
calls by default.  Most compilers also opencode data structure
accessors (such as CAR) at some level of optimization, and some code
much more complicated built-in functions inline as well.  VaxLisp, for
example, normally compiles MEMBER inline.  The Lucid compiler makes
use of type declarations to perform generic-to-specific
transformations on many arithmetic and sequence functions, which is
also a form of inlining.


Cost to implementors:

Unknown.


Cost to users:

Since most implementations appear to be largely in conformance with the
proposal, users should notice little difference.


Benefits:

The presence of a definite specification of what may happen when will
help users structure their programs so they will compile correctly in
all Common Lisp implementations.


Discussion:

Does anything need to be added to cover interaction between the compiler
and CLOS?
-------

∂02-Sep-88  1958	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY   
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Sep 88  19:58:45 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA28293@EDDIE.MIT.EDU>; Fri, 2 Sep 88 22:57:18 EDT
Received: by spt.entity.com (smail2.5); 2 Sep 88 20:58:07 EDT (Fri)
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Fri, 2 Sep 88 15:18:53 MDT <8809022118.AA12649@defun.utah.edu>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY
Message-Id: <8809022058.AA02082@spt.entity.com>
Date: 2 Sep 88 20:58:07 EDT (Fri)
From: gz@spt.entity.com (Gail Zacharias)

COMPILE-FILE should be allowed to assume that, in the absence of NOTINLINE
declarations, all functions defined in a file will retain their load-time
definitions through the life-time of any other functions defined in the same
file.  This is an extension of 2b, and should be allowed.  Otherwise, this
proposal ("anything not listed is not allowed") prohibits block compilation.

∂03-Sep-88  0747	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Sep 88  07:47:20 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA25781; Sat, 3 Sep 88 08:46:15 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA13198; Sat, 3 Sep 88 08:46:03 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809031446.AA13198@defun.utah.edu>
Date: Sat, 3 Sep 88 08:46:01 MDT
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
To: gz@spt.entity.com (Gail Zacharias)
Cc: sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu
In-Reply-To: gz@spt.entity.com (Gail Zacharias), 2 Sep 88 20:58:07 EDT (Fri)

Hmmm.  I put in 2b and 2c because they seemed like exceptions to 2a,
and because just about every implementation I know of does do that
kind of optimization unless you specifically ask for it not to with
NOTINLINE declarations.  Are there any implementations out there that
actually *do* block compilation?  Does it happen by default?

-Sandra
-------

∂05-Sep-88  0854	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 5 Sep 88  08:54:21 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA23822; Mon, 5 Sep 88 09:52:20 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA14095; Mon, 5 Sep 88 09:52:04 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809051552.AA14095@defun.utah.edu>
Date: Mon, 5 Sep 88 09:52:03 MDT
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nss.cs.ucl.ac.uk>
Cc: Gail Zacharias <gz%spt.entity.com@nss.cs.ucl.ac.uk>,
        cl-compiler@sail.stanford.edu
In-Reply-To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Mon, 5 Sep 88 15:48:03 BST

Thanks for the info.  Since there is at least one implementation that
already behaves this way, I will go ahead and add to the next version
of the proposal, unless somebody comes up with some strong argument to
the contrary. 

-Sandra
-------

∂05-Sep-88  1416	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 5 Sep 88  14:15:24 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa03668; 5 Sep 88 15:19 BST
Date: Mon, 5 Sep 88 15:48:03 BST
Message-Id: <6538.8809051448@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
To: Gail Zacharias <gz%spt.entity.com@NSS.Cs.Ucl.AC.UK>
In-Reply-To: sandra's message of Sat, 3 Sep 88 08:46:01 MDT
Cc: sandra <@cs.utah.edu:sandra@defun>, cl-compiler@sail.stanford.edu

> Are there any implementations out there that actually *do* block
> compilation?  

Yes: KCL.  As you know, KCL compiles into C.  So a Lisp procedure P
becomes a C procedure Ln that looks more or less like this:

     static L2()
     {
             ... <C initialization> ...

     TTL:;   /* self-tail label */

             ... <C code for the body of P> ...
     }

With the default optimize settings, the following optimizations are
done:

  1. Calls from P to itself are compiled as transfers to TTL rather
     than as procedure calls.

  2. Calls to P from other procedures in the same file are compiled
     as direct calls to the C procedure rather than as

        symlispcall(<ref to the symbol F>, <base>, <nargs>);

     Omitting the symlispcall is faster (one C call rather than two)
     and avoids saving any "invokation history" for backtrace.

> Does it happen by default?

Yes.

Note, however, that AKCL works differently.  It uses calls through a
link table (like translink in Franz) instead of direct calls to the
C procedure.

Jeff Dalton,                      JANET: J.Dalton@uk.ac.ed             
AI Applications Institute,        ARPA:  J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University.             UUCP:  ...!ukc!ed.ac.uk!J.Dalton


∂06-Sep-88  0817	CL-Compiler-mailer 	Re:  issue COMPILE-ENVIRONMENT-CONSISTENCY   
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 6 Sep 88  08:16:55 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA11796; Tue, 6 Sep 88 08:13:48 PDT
Received: from clam.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA00881; Tue, 6 Sep 88 08:16:35 PDT
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA17229; Mon, 5 Sep 88 15:38:42 PDT
Date: Mon, 5 Sep 88 15:38:42 PDT
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8809052238.AA17229@clam.sun.com>
To: cl-compiler@sail.stanford.edu, sandra%defun@cs.utah.edu
Subject: Re:  issue COMPILE-ENVIRONMENT-CONSISTENCY

> Here is a draft of another proposal dealing with what the compiler may
> "wire in" to the code it is compiling.
> . . . 
> -Sandra

The items under (1) make sense to me.

> (2) The compiler *may* assume that, if any of the following kinds of
> information is present in the compiletime environment, the same information
> will also be present in the runtime environment.  In all of these cases,
> the absence of the information at compiletime is not an error, but its
> presence may enable the compiler to do a better job.

For me, discussing the subject in terms of permitting the compiler
to "wire in" ("bind names", etc.) information makes more sense and
is less restrictive than permitting the ocmpiler to assume that the
same "information" will be present at runtime.

(a) and (b) relate to compile-time binding of names, and in my view
    should authorize the compiler to use the known inline definitions
    and make "direct" self-calls rather than allowing it to assume that
    the same definitions exist at runtime.  (The former point of view
    seems directly relevant to the issues and appears to meet our needs.)

(c) authorizes the compiler to make assumptions about built-in functions
and to bind the CLtL definitions at compiletime.  (This seems to address
the relevant issue directly.)

(d) relates to compile-time binding of (constant) names.  I think we want
    to license the compiler to "wire in" the compile-time values, which
    doesn't absolutely require consistency.

(e) authorizes the compiler to make assumptions.

(f) authorizes the compiler to make assumptions, but it makes more
    sense in my view to assume *validity* of assumptions made at
    compile time rather than consistency with declarations existing
    at runtime.

∂06-Sep-88  0844	CL-Compiler-mailer 	Re:  issue COMPILE-ENVIRONMENT-CONSISTENCY   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 6 Sep 88  08:44:37 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA12178; Tue, 6 Sep 88 09:43:32 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA14620; Tue, 6 Sep 88 09:43:29 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809061543.AA14620@defun.utah.edu>
Date: Tue, 6 Sep 88 09:43:28 MDT
Subject: Re:  issue COMPILE-ENVIRONMENT-CONSISTENCY
To: cperdue@sun.com (Cris Perdue)
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: cperdue@Sun.COM (Cris Perdue), Mon, 5 Sep 88 15:38:42 PDT

Date: Mon, 5 Sep 88 15:38:42 PDT
From: cperdue@Sun.COM (Cris Perdue)

> For me, discussing the subject in terms of permitting the compiler
> to "wire in" ("bind names", etc.) information makes more sense and
> is less restrictive than permitting the ocmpiler to assume that the
> same "information" will be present at runtime.

Yes, that is another way to look at it.  However, not all compilers
will actually "wire in" all the information they are permitted to, and
instead rely on the definitions of types, functions, etc. as they
exist at runtime.  In order to get the same behavior in all
implementations, it's up to the user to make sure that the same
definitions are present at run time as at compile time.  I think that
something I didn't quite make clear in my original draft is that it
"is an error" if the things listed in section 2 are not defined
consistently.

-Sandra
-------

∂06-Sep-88  0915	CL-Compiler-mailer 	Re:  issue COMPILE-ENVIRONMENT-CONSISTENCY   
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 6 Sep 88  09:15:22 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA13218; Tue, 6 Sep 88 09:12:13 PDT
Received: from clam.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA07061; Tue, 6 Sep 88 09:14:37 PDT
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA17726; Tue, 6 Sep 88 09:15:03 PDT
Date: Tue, 6 Sep 88 09:15:03 PDT
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8809061615.AA17726@clam.sun.com>
To: sandra%defun@cs.utah.edu
Subject: Re:  issue COMPILE-ENVIRONMENT-CONSISTENCY
Cc: cl-compiler@sail.stanford.edu

> Date: Mon, 5 Sep 88 15:38:42 PDT
> From: cperdue@Sun.COM (Cris Perdue)
> 
> > For me, discussing the subject in terms of permitting the compiler
> > to "wire in" ("bind names", etc.) information makes more sense and
> > is less restrictive than permitting the ocmpiler to assume that the
> > same "information" will be present at runtime.
> 
> Yes, that is another way to look at it.  However, not all compilers
> will actually "wire in" all the information they are permitted to, and
> instead rely on the definitions of types, functions, etc. as they
> exist at runtime.  In order to get the same behavior in all
> implementations, it's up to the user to make sure that the same
> definitions are present at run time as at compile time.  I think that
> something I didn't quite make clear in my original draft is that it
> "is an error" if the things listed in section 2 are not defined
> consistently.
> 
> -Sandra

Sandra's reply is quite apropos as far as I am concerned, and her
point that the compiletime and runtime environments must be consistent
to be sure of the same results in different implementations I agree
with.

I would still prefer to see implementations given a set of discrete
choices:  for certain cases the compiler is licensed to either "bind in"
or not bind in information available at compile time.  This implies
that runtime behavior may vary, but only to a certain degree.  For
various things there is no telling whether the compile-time or the
run-time binding will take precedence, but segmentation violations,
deleting all your files, etc., are not among the options.  Saying
that inconsistency "is an error" licenses implementations to
crash and burn, and that seems unnecessary here.

				-Cris

∂06-Sep-88  0921	CL-Compiler-mailer 	Re:  issue COMPILE-ENVIRONMENT-CONSISTENCY   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 6 Sep 88  09:21:40 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA14176; Tue, 6 Sep 88 10:20:32 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA14719; Tue, 6 Sep 88 10:20:28 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809061620.AA14719@defun.utah.edu>
Date: Tue, 6 Sep 88 10:20:27 MDT
Subject: Re:  issue COMPILE-ENVIRONMENT-CONSISTENCY
To: cperdue@sun.com (Cris Perdue)
Cc: sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu
In-Reply-To: cperdue@Sun.COM (Cris Perdue), Tue, 6 Sep 88 09:15:03 PDT

"Crash and burn" does seem a bit excessive.  The problem is that the
error terminology in CLtL is too vague.  We could borrow the conventions
the CLOS folks came up with and say that the behavior is "unspecified"
instead.

-Sandra
-------

∂06-Sep-88  1053	CL-Compiler-mailer 	Re:  issue COMPILE-ENVIRONMENT-CONSISTENCY   
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 6 Sep 88  10:53:11 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA15447; Tue, 6 Sep 88 10:50:06 PDT
Received: from clam.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA12680; Tue, 6 Sep 88 10:52:59 PDT
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA17903; Tue, 6 Sep 88 10:53:26 PDT
Date: Tue, 6 Sep 88 10:53:26 PDT
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8809061753.AA17903@clam.sun.com>
To: sandra%defun@cs.utah.edu
Subject: Re:  issue COMPILE-ENVIRONMENT-CONSISTENCY
Cc: cl-compiler@sail.stanford.edu

> "Crash and burn" does seem a bit excessive.  The problem is that the
> error terminology in CLtL is too vague.  We could borrow the conventions
> the CLOS folks came up with and say that the behavior is "unspecified"
> instead.
> 
> -Sandra
> -------

The CLOS "unspecified" behavior would be an acceptable specification.
All the same, where there is an obvious and small set of alternatives
(e.g. 2 possibilities), I'd personally rather see them specified as the
allowed possibilities.
				-Cris

∂07-Sep-88  1018	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 7 Sep 88  10:18:26 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA02881; Wed, 7 Sep 88 13:18:21 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA09983; Wed, 7 Sep 88 13:20:03 EDT
Message-Id: <8809071720.AA09983@mist.UUCP>
To: "sandra%defun@cs.utah.edu"@multimax (Sandra J Loosemore)
Cc: cl-compiler%sail.stanford.edu@multimax
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY 
In-Reply-To: Your message of Sat, 03 Sep 88 08:46:01 -0600.
             <8809031446.AA13198@defun.utah.edu> 
Date: Wed, 07 Sep 88 13:19:59 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

Since JonL hasn't responded yet, Lucid does block compilation under
some circumstances.

∂07-Sep-88  1032	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 7 Sep 88  10:30:04 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA02950; Wed, 7 Sep 88 13:29:56 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA10051; Wed, 7 Sep 88 13:31:37 EDT
Message-Id: <8809071731.AA10051@mist.UUCP>
To: "sandra%defun@cs.utah.edu"@multimax (Sandra J Loosemore)
Cc: cl-compiler%sail.stanford.edu@multimax
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY 
In-Reply-To: Your message of Tue, 06 Sep 88 10:20:27 -0600.
             <8809061620.AA14719@defun.utah.edu> 
Date: Wed, 07 Sep 88 13:31:34 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    "Crash and burn" does seem a bit excessive.  The problem is that the
    error terminology in CLtL is too vague.  We could borrow the conventions
    the CLOS folks came up with and say that the behavior is "unspecified"
    instead.
    
I think that we have to do that in general.  One of the things that
the whole committee really needs to decide in October is to use one of
the two new error terminologies (CLOS or Pitman) everywhere.  This
means that "we" (probably a sub-project of the editorial committee)
has to change every use of "is an error" to one of the new terms.


∂07-Sep-88  1211	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 7 Sep 88  12:11:06 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa07039; 7 Sep 88 19:33 BST
Date: Wed, 7 Sep 88 20:01:41 BST
Message-Id: <21529.8809071901@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY 
To: "Dan L. Pierson" <@multimax.arpa:pierson@mist>, 
    Sandra J Loosemore <"sandra%defun@cs.utah.edu"@multimax.arpa>
In-Reply-To: Dan L. Pierson's message of Wed, 07 Sep 88 13:31:34 EDT
Cc: cl-compiler@sail.stanford.edu

>     "Crash and burn" does seem a bit excessive.  The problem is that the
>     error terminology in CLtL is too vague.  We could borrow the conventions
>     the CLOS folks came up with and say that the behavior is "unspecified"
>     instead.
>     
> I think that we have to do that in general.  One of the things that
> the whole committee really needs to decide in October is to use one of
> the two new error terminologies (CLOS or Pitman) everywhere.

Um, unspecified is unspecified: the implementation can do whatever it
wants.  Soemthing in the C stabdard (pragmas, I think) was defined in
this way, and for a while gcc would run rogue, or gnu emacs, or, ...
-- depending on what it could find -- whenever it encountered a
pragma.

So this particular problem is not a reason to prefer "unspecified" to
"is an error" -- both allow "crash and burn".

∂07-Sep-88  1222	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 7 Sep 88  12:22:08 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA04106; Wed, 7 Sep 88 15:21:47 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA10321; Wed, 7 Sep 88 15:23:28 EDT
Message-Id: <8809071923.AA10321@mist.UUCP>
To: Jeff Dalton <"jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK"@multimax>
Cc: cl-compiler%sail.stanford.edu@Multimax
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY 
In-Reply-To: Your message of Wed, 07 Sep 88 20:01:41 -0000.
             <21529.8809071901@subnode.aiai.ed.ac.uk> 
Date: Wed, 07 Sep 88 15:23:26 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    Um, unspecified is unspecified: the implementation can do whatever it
    wants.  Soemthing in the C stabdard (pragmas, I think) was defined in
    this way, and for a while gcc would run rogue, or gnu emacs, or, ...
    -- depending on what it could find -- whenever it encountered a
    pragma.
    
    So this particular problem is not a reason to prefer "unspecified" to
    "is an error" -- both allow "crash and burn".
    
Obviously, we need a term which allows a reasonable number of
implementation options without allowing GCC-like obnoxious behavior.
This is part of what the whole committee has to consider when we
decide what our new set of error terms should be.  My claim is simply
that we badly need to break "is an error" down into some more
controlled and useful cases everywhere in the standard.

PS: In fact the CLOS spec defines "unspecified" as harmless at worst.
    There is another term, "undefined", that allows crash and burn.
    (88-002R, pp. 1-6,1-7)

∂07-Sep-88  1354	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 7 Sep 88  13:53:52 PDT
Received: by ti.com id AA14313; Wed, 7 Sep 88 15:50:09 CDT
Received: from dsg by tilde id AA22538; Wed, 7 Sep 88 15:44:36 CDT
Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Wed, 7 Sep 88  12:13:44 CDT
Message-Id: <2798644584-6949158@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 7 Sep 88  12:16:24 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Sandra J Loosemore <sandra%defun@CS.UTAH.EDU>
Cc: cl-compiler@SAIL.STANFORD.EDU
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
In-Reply-To: Sandra J Loosemore's message of Fri, 2 Sep 88 15:18:53 MDT <8809022118.AA12649@defun.utah.edu>

> Date: Fri, 2 Sep 88 15:18:53 MDT
> Issue:		COMPILE-ENVIRONMENT-CONSISTENCY
...
>   (This implies that SETF methods must also be available at
> 	compiletime.)

Should clarify that this refers to DEFSETF, not to (DEFMETHOD (SETF ...) ...)

> (2) The compiler *may* assume that, if any of the following kinds of
> information is present in the compiletime environment, the same information
> will also be present in the runtime environment. 

I agree with Perdue's comments that the issue is that the runtime
environment should not contradict the assumptions made at compile time,
without necessarily requiring the information to be present in the runtime
environment.  For example, I can visualize a run-time environment which
does not include a compiler and therefore has no use for proclamations, in
which case it is not meaningful to say that the information exists there.

>     (c) The compiler may assume that the signature of all built-in 
> 	Common Lisp functions will not change.

Is the term "signature" defined somewhere?

>     (e) Types that are defined with DEFTYPE or DEFSTRUCT can be assumed to
> 	retain the same definition in the runtime environment as in the
> 	compiletime environment.  (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.)

Rather that "reasonable", I would say that it is "desirable" for the
compiler to emit a warning, since a declaration that references an unknown
type is quite useless and therefore must not have been what the programmer
intended.

> (3) The compiler *must not* make any additional assumptions about
> consistency between the compiletime and runtime environments.  In 
> particular:
>  
>     (a) The compiler may not assume that functions that are defined
> 	in the compiletime environment that have not been declared
> 	INLINE, other than built-in Common Lisp functions, will retain
> 	either the same definition or the same signature at runtime.
> 	It is, however, reasonable for the compiler to emit warning 
> 	messages about calls to functions that are defined in at
> 	compiletime, but where the wrong number or type of arguments
> 	are supplied.

This may be a little too strong.  We shouldn't rule out the possibility of
cross-compiling for a restricted runtime environment that doesn't permit
redefinition of functions, although that would not be the default behavior
of the compiler.

> Does anything need to be added to cover interaction between the compiler
> and CLOS?

Maybe something like:  The compiler can assume that a class name defined
by DEFCLASS will also be a class name at runtime, and that class will be
an instance of the same metaclass.  There may be additional conformance
requirements imposed by the metaclass, but there are none for
STANDARD-CLASS.  [The metaclass has to match because it controls
optimization of SLOT-VALUE.]

  -- David Gray

∂07-Sep-88  1405	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 7 Sep 88  14:05:23 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA05246; Wed, 7 Sep 88 17:03:13 EDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa07984; 7 Sep 88 21:28 BST
Date: Wed, 7 Sep 88 21:56:58 BST
Message-Id: <21739.8809072056@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY 
To: Jeff Dalton <"jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK"@multimax.arpa>,
        pierson <@multimax.arpa,@multimax.arpa:pierson@mist>
Cc: cl-compiler <@multimax.arpa:cl-compiler@sail.stanford.edu>

> Obviously, we need a term which allows a reasonable number of
> implementation options without allowing GCC-like obnoxious behavior.

I am not convinced that we do.

> This is part of what the whole committee has to consider when we
> decide what our new set of error terms should be.  My claim is simply
> that we badly need to break "is an error" down into some more
> controlled and useful cases everywhere in the standard.

Agreed.

> PS: In fact the CLOS spec defines "unspecified" as harmless at worst.
>     There is another term, "undefined", that allows crash and burn.
>     (88-002R, pp. 1-6,1-7)

I would be interested to know how this distiction works in practice.
I suppose "not immediately harmful" might work.


∂07-Sep-88  1454	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Sep 88  14:53:23 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA09228; Wed, 7 Sep 88 15:52:12 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA15495; Wed, 7 Sep 88 15:52:07 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809072152.AA15495@defun.utah.edu>
Date: Wed, 7 Sep 88 15:52:06 MDT
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
To: David N Gray <Gray@dsg.csc.ti.com>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Wed, 7 Sep 88  12:16:24 CDT

> Date: Wed, 7 Sep 88  12:16:24 CDT
> From: David N Gray <Gray@DSG.csc.ti.com>

> Should clarify that this [setf method] refers to DEFSETF, not to 
> (DEFMETHOD (SETF ...) ...)

As the language is currently defined, "setf method" does refer to things
created with DEFSETF, and there is no (DEFMETHOD (SETF ...)).  If this
changes, I suppose the editorial committee will decide upon some standard
terminology to differentiate between the two.

> I agree with Perdue's comments that the issue is that the runtime
> environment should not contradict the assumptions made at compile time,
> without necessarily requiring the information to be present in the runtime
> environment.  For example, I can visualize a run-time environment which
> does not include a compiler and therefore has no use for proclamations, in
> which case it is not meaningful to say that the information exists there.

The things listed in section (2) do not affect only things that may be
safely ignored at runtime.  For example, licensing the compiler to
make assumptions about the type structure remaining the same allows it
to do things like substitute the expansion of a DEFTYPE'd type for its
name in a call to a function like TYPEP.  However, the compiler may or
may not actually do this, and the only way to guarantee that your
program will not break is to require that the user make sure the type
is defined exactly the same way at runtime.

There is nothing here to prevent you from making your implementation
look for certain kinds of information only at compiletime, and
documenting this as an extra feature of your implementation.  On the
other hand, I think it would be unreasonable to require all
implementations to do this.

> Is the term "signature" defined somewhere?

I thought it's fairly standard terminology.  Some people use
"contract" instead to mean the same thing.

> We shouldn't rule out the possibility of
> cross-compiling for a restricted runtime environment that doesn't permit
> redefinition of functions, although that would not be the default behavior
> of the compiler.

It's already been proposed that a limited form of this (block
compilation) be allowed, since some implementations already do it.
However, I don't think that a Lisp that disallowed redefining
functions entirely would be able to legitimately call itself Common
Lisp (see p 67 of CLtL).  Again, there is nothing that prevents you
from extending your implementation to have a mode where it does
disallow redefinition of functions; it's just that programs that rely
on such a feature are not portable Common Lisp programs.

> > Does anything need to be added to cover interaction between the compiler
> > and CLOS?
> 
> Maybe something like:  The compiler can assume that a class name defined
> by DEFCLASS will also be a class name at runtime, and that class will be
> an instance of the same metaclass.  There may be additional conformance
> requirements imposed by the metaclass, but there are none for
> STANDARD-CLASS.  [The metaclass has to match because it controls
> optimization of SLOT-VALUE.]

This sounds good to me, although I'm certainly no expert on CLOS.
Should we also try to address the issue of what (if anything) the
compiler can do to optimize method dispatching?

-Sandra
-------

∂08-Sep-88  1335	CL-Compiler-mailer 	Re: LOAD-TIME-EVAL  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 8 Sep 88  13:35:28 PDT
Received: by ti.com id AA22949; Thu, 8 Sep 88 15:33:51 CDT
Received: from Kelvin by tilde id AA20870; Thu, 8 Sep 88 15:22:46 CDT
Message-Id: <2798742258-12817559@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 8 Sep 88  15:24:18 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Sandra J Loosemore <sandra%defun@CS.UTAH.EDU>
Cc: cl-compiler@SAIL.STANFORD.EDU
Subject: Re: LOAD-TIME-EVAL
In-Reply-To: Msg of Mon, 1 Aug 88 13:28:56 MDT from sandra%defun@CS.UTAH.EDU

I don't like either of the proposals LOAD-TIME-EVAL:QUOTED-MAGIC-TOKEN or
LOAD-TIME-EVAL:NEW-SPECIAL-FORM, although I agree that the capability is
something desirable.  Both proposals seem unnecessarily complicated, and
the NEW-SPECIAL-FORM proposal is objectionable because it makes an
incompatible change to existing practice without any good reason.
I agree with Moon that the READ-ONLY-P argument should be dropped; if you
want data that can be modified, then that's what variables are for.

I also have a problem with this:

>    Note, however, that in the case of quoted code (processed by explicit
>    use of EVAL), each call to EVAL is treated like a load. Caching may not
>    be implemented by having LOAD-TIME-CONSTANT displace its source level
>    call. 

These seems like an unnecessary and undesirable restriction; the point is
to make this feature possible; I don't see why the the implementation
should be overly constrained.


Here is something that we have been using internally (with the name
changed to match the proposal) that seems to be quite sufficient:

   LOAD-TIME-CONSTANT form			[Special Form]

'#,form   <==>  (LOAD-TIME-CONSTANT form)
'(a ... #,form ... z)   <==>  (LOAD-TIME-CONSTANT (LIST 'a ... form ... 'z))



  -- David Gray

∂08-Sep-88  1604	CL-Compiler-mailer 	Re: LOAD-TIME-EVAL  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Sep 88  16:04:30 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 456572; Thu 8-Sep-88 18:51:40 EDT
Date: Thu, 8 Sep 88 18:51 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: LOAD-TIME-EVAL
To: Gray@DSG.csc.ti.com
cc: sandra%defun@CS.UTAH.EDU, Cl-Compiler@SAIL.Stanford.EDU,
    KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <2798742258-12817559@Kelvin>
Message-ID: <880908185105.5.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Thu, 8 Sep 88  15:24:18 CDT
    From: David N Gray <Gray@DSG.csc.ti.com>

    ... if you want data that can be modified, then that's what variables are for.

People keep saying this, but it's just not true. Consider an expression such
as X(Y+3)+2 in a function FOO which has been translated into Lisp. I might want to
implement that as:

 ... (+ (AREF *FORTRAN-VIRTUAL-MEMORY* 
	      (+ (LOAD-TIME-CONSTANT (+ (FORTRAN-VARIABLE-OFFSET 'FOO 'X) 3))
		 (AREF *FORTRAN-VIRTUAL-MEMORY*
		       (LOAD-TIME-CONSTANT (FORTRAN-VARIABLE-OFFSET 'FOO 'Y)))))
	2) ...

so that if the offset of X in fortran memory is 40 and the offset of Y is 50,
something which cannot be known until runtime, the code will behave as if I'd
written:

 ... (+ (AREF *FORTRAN-VIRTUAL-MEMORY* (+ 43 (AREF *FORTRAN-VIRTUAL-MEMORY* 50)))
        2) ...

Fortunately, since these subscripts are not modified, you aren't asking me
to write:

 (DEFVAR I-HOPE-THIS-IS-UNIQUE-0001 (+ (FORTRAN-VARIABLE-OFFSET 'FOO 'X) 3))
 (DEFVAR I-HOPE-THIS-IS-UNIQUE-0002 (FORTRAN-VARIABLE-OFFSET 'FOO 'Y))
 ... (+ (AREF *FORTRAN-VIRTUAL-MEMORY*
	      (+ I-HOPE-THIS-IS-UNIQUE-0001
		 (AREF *FORTRAN-VIRTUAL-MEMORY* I-HOPE-THIS-IS-UNIQUE-0002)))
	2) ...

Anyone who asks that #, be flushed is, in effect, asking me to write this kind
of stuff. Among other things, it forces the creation of numerous extra symbols
and it may require an indirect access to the value (through the symbol's value
cell) in some implementations where an immediate move (or even an instruction
that utilizes a constant operand) might have been possible if quote were used.
(Among other things, no compiler is going to be able to do any data flow
analysis tricks that will tell it that the value of these unique vars won't change.)

Anyway, suppose now the situation is more complicated. Suppose I'm doing something
CLOS-like. Now I don't want to translate variables to one-level indirect accesses
but rather I want two-level indirect access. That is, suppose I want to translate

(DEFUN FROB (X) 
  (WITH-SLOTS (A B C) X
    (DECLARE (TYPE FOO X))
    (+ A B)))

and let's say the WITH-SLOTS expression expands to something roughly like:

 (LET ((INSTANCE-TABLE (SLOT-TABLE-FOR-INSTANCE FOO X)))
   (SYMBOL-MACROLET ((A (INSTANCE-REF X (SVREF INSTANCE-TABLE (INSTANCE-SLOT-INDEX FOO A))))
		     (B (INSTANCE-REF X (SVREF INSTANCE-TABLE (INSTANCE-SLOT-INDEX FOO B)))))
     (+ A B)))

where

 (SLOT-TABLE-FOR-INSTANCE FOO X)
 <==> (AREF (LOAD-TIME-CONSTANT (SLOT-TABLE-FOR-CLASS 'FOO))
	    (INSTANCE-CLASS-INDEX X))

and

 (INSTANCE-SLOT-INDEX FOO A)
   <==> (LOAD-TIME-CONSTANT (INSTANCE-SLOT-INDEX-LOOKUP 'FOO 'A))

so that at runtime my FROB function behaved like:

(DEFUN FROB (X)
  (LET ((INSTANCE-TABLE (AREF (LOAD-TIME-CONSTANT (SLOT-TABLE-FOR-CLASS 'FOO))
			      (INSTANCE-CLASS-INDEX X))))
    (+ (INSTANCE-REF X (SVREF INSTANCE-TABLE
			      (LOAD-TIME-CONSTANT (INSTANCE-SLOT-INDEX-LOOKUP 'FOO 'A))))
       (INSTANCE-REF X (SVREF INSTANCE-TABLE
			      (LOAD-TIME-CONSTANT (INSTANCE-SLOT-INDEX-LOOKUP 'FOO 'B)))))))

Note that the INSTANCE-TABLE is a known value at load time but that it is easy to
imagine implementations in which it wants to be adjustable and to change over time.
Surely you won't ask me to write:

(DEFVAR I-HOPE-THIS-IS-UNIQUE-TOO-0001 (SLOT-TABLE-FOR-CLASS 'FOO))
(DEFVAR I-HOPE-THIS-IS-UNIQUE-TOO-0002 (INSTANCE-SLOT-INDEX-LOOKUP 'FOO 'A))
(DEFVAR I-HOPE-THIS-IS-UNIQUE-TOO-0003 (INSTANCE-SLOT-INDEX-LOOKUP 'FOO 'B))

(DEFUN FROB (X)
  (LET ((INSTANCE-TABLE (AREF I-HOPE-THIS-IS-UNIQUE-TOO-0001
			      (INSTANCE-CLASS-INDEX X))))
    (+ (INSTANCE-REF X (SVREF INSTANCE-TABLE I-HOPE-THIS-IS-UNIQUE-TOO-0002))
       (INSTANCE-REF X (SVREF INSTANCE-TABLE I-HOPE-THIS-IS-UNIQUE-TOO-0003)))))

If you did want me to write this, then I have the following concerns:

 - I have to be careful about assigning names to these variables.
   They must be interned or the compiler will not correctly link up the
   DEFUN with the DEFVAR, but since I'm going to generate a zillion of them,
   I have to have a really clever naming scheme.

 - These variables take up unwanted space. Not just symbol space but also
   a pname (string) and value cell.

 - I cannot expand the code for WITH-SLOTS except in a situation where I have
   some mechanism (it was called a Pratt stack in Maclisp) for getting the
   auxiliary DEFVAR definitions snuck out to toplevel so they'll get compiled
   correctly.

I cannot, for example, write:

(LET ((THIS-NEEDNT-BE-VERY-UNIQUE-0001
	(SLOT-TABLE-FOR-CLASS 'FOO))
      (THIS-NEEDNT-BE-VERY-UNIQUE-0002
	(INSTANCE-SLOT-INDEX-LOOKUP 'FOO 'A))
      (THIS-NEEDNT-BE-VERY-UNIQUE-0003
	(INSTANCE-SLOT-INDEX-LOOKUP 'FOO 'B)))
  (DEFUN FROB (X)
    (LET ((INSTANCE-TABLE (AREF THIS-NEEDNT-BE-VERY-UNIQUE-0001
				(INSTANCE-CLASS-INDEX X))))
      (+ (INSTANCE-REF X (SVREF INSTANCE-TABLE THIS-NEEDNT-BE-VERY-UNIQUE-0002))
	 (INSTANCE-REF X (SVREF INSTANCE-TABLE THIS-NEEDNT-BE-VERY-UNIQUE-0003))))))

because DEFUN is not currently allowed inside a LET.

Even if DEFUN were allowed inside a LET, though, I still couldn't win because it's
the WITH-SLOTS that would be wanting to do this, not the DEFUN. The best it could
do would be:

(DEFUN FROB (X)
  (LET ((THIS-NEEDNT-BE-VERY-UNIQUE-0001
	  (SLOT-TABLE-FOR-CLASS 'FOO))
	(THIS-NEEDNT-BE-VERY-UNIQUE-0002
	  (INSTANCE-SLOT-INDEX-LOOKUP 'FOO 'A))
	(THIS-NEEDNT-BE-VERY-UNIQUE-0003
	  (INSTANCE-SLOT-INDEX-LOOKUP 'FOO 'B)))
    (LET ((INSTANCE-TABLE (AREF THIS-NEEDNT-BE-VERY-UNIQUE-0001
				(INSTANCE-CLASS-INDEX X))))
      (+ (INSTANCE-REF X (SVREF INSTANCE-TABLE THIS-NEEDNT-BE-VERY-UNIQUE-0002))
	 (INSTANCE-REF X (SVREF INSTANCE-TABLE THIS-NEEDNT-BE-VERY-UNIQUE-0003))))))

which would still be useless unless the compiler had some way to know it could factor
the LET out of the DEFUN so it didn't have to execute it in time. And there are certainly
cases where it would not be able to do that without further clue.

Anyway, I hope this makes a reasonable case for the fact that it is possible to derive
a user application where variables are not suitable and where a LOAD-TIME-CONSTANT
facility is suitable, and where it is important to be able to distinguish between
read-only and non-read-only data.

##### VVVVV ###### NOTE WELL ##### READ THIS ##### DISCLAIMER #####

I don't want to get into ANY discussion of whether this is the right way to
implement WITH-SLOTS. I just picked WITH-SLOTS because it is the domain likely
to be most familiar to readers of this mail. The idea of doing double-indirection
of arrays is not unique to CLOS so any discussion of what you can or can't get
away with in CLOS in actual practice would be utterly irrelevant here.

########## END OF IMPORTANT TEXT ##########

    I also have a problem with this:

    >    Note, however, that in the case of quoted code (processed by explicit
    >    use of EVAL), each call to EVAL is treated like a load. Caching may not
    >    be implemented by having LOAD-TIME-CONSTANT displace its source level
    >    call. 

    These seems like an unnecessary and undesirable restriction; the point is
    to make this feature possible; I don't see why the the implementation
    should be overly constrained.

Well, I don't see why the user should be overly constrained.

Better to burden the implementors than the users on something like this.
Implementations are done only once and can easily be done carefully to
avoid bugs. Users write code repeatedly and the bugs which could result
could happen over and over again.  Displacing macros were once the rage,
but they have become less of a big deal over time as people have shifted
to less user-intrusive paradigms (single pass semantic analysis by
compilers, once-only interpreter pre-pass, and/or hashed memoization --
none of which involve displacing user code).

∂09-Sep-88  0734	CL-Compiler-mailer 	Re: LOAD-TIME-EVAL  
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Sep 88  07:30:37 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa04135; 9 Sep 88 14:45 BST
Date: Fri, 9 Sep 88 15:14:53 BST
Message-Id: <442.8809091414@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: LOAD-TIME-EVAL
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, 
    Gray%dsg.csc.ti.com@NSS.Cs.Ucl.AC.UK
Cc: sandra <@cs.utah.edu:sandra@defun>, Cl-Compiler@sail.stanford.edu

>  (DEFVAR I-HOPE-THIS-IS-UNIQUE-0001 (+ (FORTRAN-VARIABLE-OFFSET 'FOO 'X) 3))
>  (DEFVAR I-HOPE-THIS-IS-UNIQUE-0002 (FORTRAN-VARIABLE-OFFSET 'FOO 'Y))
>  ... (+ (AREF *FORTRAN-VIRTUAL-MEMORY*
> 	      (+ I-HOPE-THIS-IS-UNIQUE-0001
> 		 (AREF *FORTRAN-VIRTUAL-MEMORY* I-HOPE-THIS-IS-UNIQUE-0002)))
> 	2) ...
> 
>
> Anyone who asks that #, be flushed is, in effect, asking me to write
> this kind of stuff. Among other things, it forces the creation of
> numerous extra symbols and it may require an indirect access to the
> value (through the symbol's value cell) in some implementations where
> an immediate move (or even an instruction that utilizes a constant
> operand) might have been possible if quote were used.

Although I agree with Kent's point that load-time eval is useful and
better than many of the alternatives (especially since some of the
alternatives don't quite work), the "I hope this is unique" problem
can often be reduced.

In some other languages I can use static variables 

    int f()
    {
        static int initialized = FALSE;
        static int v1, v2, ...;
        if not(initialized)
        {
            v1 = ...;
            v2 = ...;
            ...;
        }
        ... procedure body code ...
    }

This is not ideal, of course.

Similar tricks can be done in Lisp (I think) by generating global
variables:

(defmacro eval-once (form)
  (let ((v (gensym)))
    `(locally (declare (special ,v))
       (if (boundp ',v)			;initialized?
           ,v
         (setq ,v ,form)))))

∂09-Sep-88  0835	CL-Compiler-mailer 	Re: LOAD-TIME-EVAL  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 9 Sep 88  08:35:15 PDT
Received: by ti.com id AA28830; Fri, 9 Sep 88 10:33:16 CDT
Received: from Kelvin by tilde id AA11465; Fri, 9 Sep 88 10:24:13 CDT
Message-Id: <2798810739-416955@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 9 Sep 88  10:25:39 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Cl-Compiler@SAIL.Stanford.EDU
Subject: Re: LOAD-TIME-EVAL
In-Reply-To: Msg of Thu, 8 Sep 88 18:51 EDT from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

> Anyone who asks that #, be flushed is, in effect, asking me to write this kind
> of stuff. 

Kent,
Wait a minute; I was _not_ advocating flushing #, ; I _was_ saying that the
READ-ONLY-P argument was not a good idea.  What I was objecting to was the
notion of evaluating a "constant" at load time and then destructively modifying
that value later; I don't see that any of your examples do that.  In the rare
cases where there is a valid need to do something like that, the approach
shown by Dalton seems sufficient.

>    ...  Displacing macros were once the rage,
> but they have become less of a big deal over time as people have shifted
> to less user-intrusive paradigms (single pass semantic analysis by
> compilers, once-only interpreter pre-pass, and/or hashed memoization --
> none of which involve displacing user code).

I'm obviously biased since I use an implementation that still uses displacing
macros.  I haven't noticed anywhere that CLtL outlaws this, so I didn't see
why the standard should explicitly outlaw that approach for just this one
feature.

  -- David Gray

∂09-Sep-88  0907	CL-Compiler-mailer 	Re: LOAD-TIME-EVAL  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Sep 88  09:07:12 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 456860; Fri 9-Sep-88 12:04:42 EDT
Date: Fri, 9 Sep 88 12:04 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: LOAD-TIME-EVAL
To: Gray@DSG.csc.ti.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Cl-Compiler@SAIL.Stanford.EDU
In-Reply-To: <2798810739-416955@Kelvin>
Message-ID: <880909120406.6.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Fri, 9 Sep 88  10:25:39 CDT
    From: David N Gray <Gray@DSG.csc.ti.com>

    > Anyone who asks that #, be flushed is, in effect, asking me to write this kind
    > of stuff. 

    Wait a minute; I was _not_ advocating flushing #, ;

Yes, but some people have. My reply to you was as much a reply to a lot of preceding
mail.

    I _was_ saying that the READ-ONLY-P argument was not a good idea.  What I was
    objecting to was the notion of evaluating a "constant" at load time and then
    destructively modifying that value later; I don't see that any of your examples
    do that.

The full text of the system I'm alluding to in the second example does do
side-effects. They are of two kinds:
 - ADJUST-ARRAY is done on one of the arrays which is a load time constant
   so that when new classes (or whatever) are added, it can allocate space
   in the same table to accomodate them. [This is not a problem because
   the old load-time constants never look at the new rows.]
 - If the slot mappings change, it fills the table with new values. [This
   is a major problem because if the old load-time constants have gotten
   separated from the new load-time constants, or if all load-time constants
   are read-only, I cannot update the table.

    In the rare cases where there is a valid need to do something like that,
    the approach shown by Dalton seems sufficient.

Dalton's approach is clever, but is not adequate for a number of reasons in
any serious application. Here are a few that come quickly to mind ...

 - I'm not convinced that the spec for either the compiler or GENSYM is
   written in a constrained enough way to make me believe that all compilers
   will correctly handle the writing out and re-loading of that GENSYM. Some
   compilers I've known would either intern the gensym later, or would get
   the two gensyms become un-EQ. We'd need a serious tightening up of the
   contract of the compiler to even make this plausible to me. [Especially
   if that GENSYM can occur in other functions or files and must be somehow
   linked up with others which were EQ at macro-expansion time, the problem
   seems nearly intractable to me.]

 - No serious CLOS implementation (or other class-system or large-scale
   system using zillions of these) could be built on it. I could easily imagine
   this construct occurring many thousands of times, in a large program,
   wasting tens or hundreds of thousands of bytes of space gratuitously.
   It would gratuitously waste a ton of symbol space to no good end and users
   would complain mightily. The only response would be "Well, I asked for a
   more space-efficient way to do this, but people on CL-Compiler said it
   was gratuitous and that this was the best I should be able to do."

 - It incurs runtime overhead when load-time overhead is all that's required.
   This means if the initial computation is very expensive, it can't be done
   when dumping an application prior to delivery. It must be repeatedly
   incurred at runtime.

 - It isn't adequately synchronized with the running of the program. It may
   be that running the program will violate the initial state. This is a
   general problem that interpreters have and not one you can guard against
   completely, but it's one that I think you're best to guard against where
   you can. One of the worst things is to get a function
    (DEFUN FOO (X) (IF X (LOAD-TIME-CONSTANT (Z)) (LOAD-TIME-CONSTANT (Z))))
   which can return two different answers depending on whether X is NIL or T.
   [Supposing that (Z) is a state-reader and not a state-modifier, etc.
    but that (Z) is dependent on some global state which usually doesn't
    but might change -- eg, function definitions themselves.]
   If you don't compute all these things at load time, you risk that the
   state of the system will change radically between the time the first (Z) 
   and the second (Z) are called. Doing real load-time evaluation reduces
   this sort of risk and even if it doesn't guarantee solidity, it enhances
   the chances of it.

 - It doesn't deal with issues of caching for `equal expressions', etc.
   [That's a trivial deal; it could easily be made to. But I just thought
   I'd mention it.]

∂09-Sep-88  0942	CL-Compiler-mailer 	Re: LOAD-TIME-EVAL  
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Sep 88  09:40:43 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa04135; 9 Sep 88 14:45 BST
Date: Fri, 9 Sep 88 15:14:53 BST
Message-Id: <442.8809091414@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: LOAD-TIME-EVAL
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, 
    Gray%dsg.csc.ti.com@NSS.Cs.Ucl.AC.UK
Cc: sandra <@cs.utah.edu:sandra@defun>, Cl-Compiler@sail.stanford.edu

>  (DEFVAR I-HOPE-THIS-IS-UNIQUE-0001 (+ (FORTRAN-VARIABLE-OFFSET 'FOO 'X) 3))
>  (DEFVAR I-HOPE-THIS-IS-UNIQUE-0002 (FORTRAN-VARIABLE-OFFSET 'FOO 'Y))
>  ... (+ (AREF *FORTRAN-VIRTUAL-MEMORY*
> 	      (+ I-HOPE-THIS-IS-UNIQUE-0001
> 		 (AREF *FORTRAN-VIRTUAL-MEMORY* I-HOPE-THIS-IS-UNIQUE-0002)))
> 	2) ...
> 
>
> Anyone who asks that #, be flushed is, in effect, asking me to write
> this kind of stuff. Among other things, it forces the creation of
> numerous extra symbols and it may require an indirect access to the
> value (through the symbol's value cell) in some implementations where
> an immediate move (or even an instruction that utilizes a constant
> operand) might have been possible if quote were used.

Although I agree with Kent's point that load-time eval is useful and
better than many of the alternatives (especially since some of the
alternatives don't quite work), the "I hope this is unique" problem
can often be reduced.

In some other languages I can use static variables 

    int f()
    {
        static int initialized = FALSE;
        static int v1, v2, ...;
        if not(initialized)
        {
            v1 = ...;
            v2 = ...;
            ...;
        }
        ... procedure body code ...
    }

This is not ideal, of course.

Similar tricks can be done in Lisp (I think) by generating global
variables:

(defmacro eval-once (form)
  (let ((v (gensym)))
    `(locally (declare (special ,v))
       (if (boundp ',v)			;initialized?
           ,v
         (setq ,v ,form)))))

∂09-Sep-88  1220	CL-Compiler-mailer 	issue OPTIMIZE-DEBUG-INFO
Received: from ti.com by SAIL.Stanford.EDU with TCP; 9 Sep 88  12:20:01 PDT
Received: by ti.com id AA00270; Fri, 9 Sep 88 14:18:40 CDT
Received: from Kelvin by tilde id AA16756; Fri, 9 Sep 88 14:08:26 CDT
Message-Id: <2798824199-1225652@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 9 Sep 88  14:09:59 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Compiler@SAIL.Stanford.EDU
Subject: issue OPTIMIZE-DEBUG-INFO

Here is a little problem that has been bothering me; I'd like to see what
other people think about it.  I'm offering two possible solutions; the second
is the one I prefer even though I have implemented the first as a temporary
stop-gap.

  -- David Gray

--
 
Issue:		OPTIMIZE-DEBUG-INFO
References:	CLtL p. 160
Category:	CLARIFICATION or ADDITION
Edit History:   9 Sep 1988, David Gray (initial version)
Status:		for preliminary discussion
 
Problem Description:

  The OPTIMIZE declaration provides a way to tell the compiler how important
  various qualities are in order to guide which optimizations are done.
  There is another quality, however, that is not mentioned, but is an
  important consideration for the compiler:  how much information
  should be included in the object code to facilitate debugging.  This
  includes both annotation added to enable a debugger to display more
  information to the user, and also suppression of optimizations that would
  confuse debugging by making it harder to connect the object code with the
  source code.

-- 

Proposal OPTIMIZE-DEBUG-INFO:SAFETY:  (CLARIFICATION)

  In the description of the OPTIMIZE quality SAFETY, replace "run-time error
  checking" with "run-time error checking and ease of debugging".
 
 Rationale:

  If the user is concerned about detection of errors, then he is presumably
  also interested in being able to easily debug those errors when they are
  signalled.  (However, this is not always true.)  While this is not very
  compelling reasoning, it seems to be the best interpretation that can be
  made without either extending the language or adding some
  implementation-dependent switch.
 
 Current Practice:

  This is the approach taken by the TI Explorer.
 
 Cost to implementors:

  Minimal, since it only affects implementations that choose to make use of
  it.
 
 Cost to users:

  None.
  
 Benefits:

  Facilitates consistent use of declarations by different implementations.

--

Proposal OPTIMIZE-DEBUG-INFO:NEW-QUALITY:   (ADDITION)

  In the description of the OPTIMIZE declaration, add an additional quality
  named DEBUG, described as "ease of debugging".
 
 Rationale:

  Since ease of debugging is an issue that the user will be concerned with,
  and is an issue that the compiler needs to consider, this provides a clear
  way for the user to control the amount of debugging information placed in
  the object module, with DEBUG=0 meaning none and DEBUG=3 meaning "as much
  as possible".
 
 Current Practice:

  No current implementation of this is known.
 
 Cost to implementors:

  All would have to update their handling of OPTIMIZE declarations to accept
  the new quality.
 
 Cost to users:

  One more little feature to learn.  Some problems may result from the
  addition of the symbol DEBUG to the LISP package.
  
 Benefits:

  Provides users a standard way to control the interaction between
  the compiler and debugger, and saves implementors from having to invent
  implementation-dependent solutions.

--

Costs of Non-Adoption: 

  Continued confusion about how debug information should be controlled.
 
Discussion:

  The second proposal seems to be a more ideal solution, but has a higher
  cost.  It would be more attractive if someone can find a suitable symbol
  that is already in the LISP package.  [The best I can see offhand is
  INSPECT, but (DECLARE (OPTIMIZE INSPECT)) doesn't seem as intuitively clear
  as (DECLARE (OPTIMIZE DEBUG)).]

  Concern has been raised that there is already a problem with the
  non-orthogonality of SPEED, SAFETY, and SPACE that would be made even worse
  with DEBUG added, since users are largely perplexed by the interactions of
  these qualities.  [I don't really understand what the problem is here so
  don't know how to explain it properly.]

∂09-Sep-88  1241	CL-Compiler-mailer 	Re: issue OPTIMIZE-DEBUG-INFO 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 9 Sep 88  12:41:21 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA08397; Fri, 9 Sep 88 13:40:11 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA16624; Fri, 9 Sep 88 13:40:05 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809091940.AA16624@defun.utah.edu>
Date: Fri, 9 Sep 88 13:40:04 MDT
Subject: Re: issue OPTIMIZE-DEBUG-INFO
To: David N Gray <Gray@dsg.csc.ti.com>
Cc: CL-Compiler@sail.stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Fri, 9 Sep 88  14:09:59 CDT

I like the second option better too, even though the implementation
I've been hacking on in my spare time also uses the safety parameter
to control how much inlining to do.  The problem with that approach is
that I don't really think that safety and debuggability have much to
do with each other.  (For instance, you could code accessors like CAR
inline with full type checking, but still not be able to trace them.)

I agree that the various OPTIMIZE qualities are confusing, and in fact
one of the issues on our list has been to try to put together some
suggested guidelines on what they should do.

-Sandra
-------

∂09-Sep-88  1306	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY, version 2  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 9 Sep 88  13:06:43 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA08997; Fri, 9 Sep 88 14:05:35 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA16644; Fri, 9 Sep 88 14:05:32 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809092005.AA16644@defun.utah.edu>
Date: Fri, 9 Sep 88 14:05:31 MDT
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 2
To: cl-compiler@sail.stanford.edu

Issue:		COMPILE-ENVIRONMENT-CONSISTENCY
References:	CLtL p. 68-69, 143, 321
		RAM's "Compiler Cleanup Proposal #3"
Category:	CLARIFICATION
Edit History:   V1, 2 Sep 1988, Sandra Loosemore (initial draft)
		V2, 9 Sep 1988, Sandra Loosemore (incorporate suggestions)


Problem Description:

CLtL does not clearly specify what aspects of the compiletime
environment the compiler (or other preprocessor) may "wire in" to code
being compiled.


Proposal COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY:

Common Lisp deliberately leaves unspecified the time at which certain
transformations, such as macro expansion, are performed within a
program.  While some implementations perform such transformations
concurrently with evaluation, it is also legitimate to perform
transformations during a preprocessing phase.  For example, an
implementation might choose to apply transformations at "function
promotion time" (i.e., transformations are applied once during
evaluation of a surrounding FUNCTION special form), or to completely
transform each top-level form and all of its subforms before
performing any evaluation.  User programs cannot portably depend upon
either the time of such transformations, or the number of times the
transformations are applied.

In all cases, however, compiling a program (with COMPILE or
COMPILE-FILE) provides a mechanism for forcing these transformations
to be applied and a guarantee that, once compiled, no further
transformations will be applied to that program.

In the discussion that follows, the term "compiler" is to be understood
to include other preprocessors as well.  Likewise, the "compiletime
environment" refers to the environment in which program transformations
occur, while "runtime" refers to the time the program is executed.


(1) The following information *must* be present in the compiletime
environment for the preprocessor to apply the correct transformations.
This information need not also be present in the runtime environment.

    (a) Macro definitions must be available in the compiletime environment.
	The compiler may assume that forms that are lists beginning with
	a symbol that does not name a macro or special form is a function
	call.  (This implies that SETF methods must also be available at
	compiletime.)

    (b) Special variables must be declared as such before they are bound.
	The compiler must treat any undeclared variable binding as a
	lexical binding.


(2) The compiler *may* "wire in" the following kinds of information
into the code it produces, if the information is present in the
compiletime environment.  However, since implementations are not
required to do this, user code must ensure that the information is
also defined consistently in the runtime environment.  Except as
noted, the behavior of user programs is unspecified in situations
where the information is defined differently at runtime than at
compiletime, since the user cannot depend upon which will take
precedence in a particular implementation.  In all cases, the absence
of the information at compiletime is not an error, but its presence
may enable the compiler to do a better job.

    (a) The compiler may assume that functions that are defined and
	declared INLINE in the compiletime environment will retain the
	same definitions at runtime.

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

    (c) 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 runtime.

    (d) The compiler may assume that the signature (or "contract") of
	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.

    (e) The compiler may "wire in" the values of symbolic constants
	that have been defined with DEFCONSTANT in the compiletime
	environment.

    (f) Types that are defined with DEFTYPE or DEFSTRUCT can be assumed to
	retain the same definition in the runtime environment as in the
	compiletime environment.  (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.)

    (g) The compiler may assume that a class name defined by DEFCLASS
	that is present in the compiletime environment will also be a
	class name at runtime, and that class will be an instance of the
	same metaclass.  There may be additional conformance requirements
	imposed by the metaclass, but there are none for STANDARD-CLASS.

    (h) The compiler may assume that if type declarations are present
	in the compiletime environment, the corresponding variables and 
	functions present in the runtime environment will actually be of
	those types; otherwise, the behavior of the program is undefined.


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

    (a) The compiler may not assume that functions that are defined
	in the compiletime environment will retain the either the
	same definition or the same signature at runtime, except
	in situations (2a) through (2d) above.  It is, however,
	reasonable for the compiler to emit warning messages about
	calls to functions that are defined at compiletime, but where
	the wrong number or type of arguments are supplied.

    (b) The compiler may not signal an error if it sees a call to a
	function that is not defined at compiletime, since that function
	may be provided at runtime.  Again, it is permissible to emit
	a warning in these situations.

	

Rationale:

This proposal generally reflects current practice.


Current Practice:

I know of no compiler that does not implement the provisions of item (1).

For item (2), most compilers (including Lucid) optimize self-recursive
calls by default.  Most compilers also opencode data structure
accessors (such as CAR) at some level of optimization, and some code
much more complicated built-in functions inline as well.  VaxLisp, for
example, normally compiles MEMBER inline.  The Lucid compiler makes
use of type declarations to perform generic-to-specific
transformations on many arithmetic and sequence functions, which is
also a form of inlining.  KCL performs block compilation by default,
and Lucid does so under certain conditions.


Cost to implementors:

Unknown, but probably minor.


Cost to users:

Since most implementations appear to be largely in conformance with the
proposal, users should notice little difference.


Benefits:

The presence of a definite specification of what may happen when will
help users structure their programs so they will compile correctly in
all Common Lisp implementations.


Discussion:

Most of the discussion on this issue has been centered on the
terminology describing error situations for item (2).  In most cases
where there is an inconsistency between compile-time and run-time, the
results will be unpredictable but harmless.  The major exception is
violation of type declarations, which is a "crash-and-burn" error in
many implementations.

There has also been some concern raised that item (3) would prohibit
such things as a cross-compiler that produces standalone programs in
an environment that disallows redefinition of functions.  The intent
of this proposal is not to prohibit a compiler from having a magic
switch that imposes additional restrictions on the programs it
compiles, but such a compiler would not be a compiler for Common Lisp.
-------

∂09-Sep-88  1329	CL-Compiler-mailer 	Re: LOAD-TIME-EVAL  
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Sep 88  13:28:40 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa06287; 9 Sep 88 20:53 BST
Date: Fri, 9 Sep 88 21:22:43 BST
Message-Id: <1318.8809092022@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: LOAD-TIME-EVAL
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, 
    Gray%dsg.csc.ti.com@NSS.Cs.Ucl.AC.UK
In-Reply-To: Kent M Pitman's message of Fri, 9 Sep 88 12:04 EDT
Cc: Cl-Compiler@sail.stanford.edu

> Dalton's approach is clever, but is not adequate for a number of reasons in
> any serious application. Here are a few that come quickly to mind ...
> 
>  - I'm not convinced that the spec for either the compiler or GENSYM is
>    written in a constrained enough way to make me believe that all compilers
>    will correctly handle the writing out and re-loading of that GENSYM.

I agree.  But my eval-once trick seemed the least suspect way of doing this
when I first wrote it, because then it seemed that any quoted or load-time
eval object would not be safely modifiable.  Is the current proposal to
allow modification in some cases?

Anyway, some of the potential gensym problems can be eliminated if the
gensym appears exactly once in the source.  For example:

(defmacro eval-once (form)
  `(let ((v ',(gensym)))		;the symbol persists between calls
     (if (boundp v)
	 (symbol-value v)
       (set v ,form))))

I had thought that write/re-load problems with gensym were confined to
systems like KCL that were incorrect on other grounds.  If this is not
so, cleanup issues seem in order.

-- Jeff

∂09-Sep-88  1522	CL-Compiler-mailer 	Re: LOAD-TIME-EVAL  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 9 Sep 88  15:22:42 PDT
Received: by ti.com id AA01511; Fri, 9 Sep 88 17:18:55 CDT
Received: from Kelvin by tilde id AA20981; Fri, 9 Sep 88 17:10:13 CDT
Message-Id: <2798835110-1881175@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 9 Sep 88  17:11:50 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Compiler@SAIL.Stanford.EDU
Subject: Re: LOAD-TIME-EVAL
In-Reply-To: Msg of Fri, 9 Sep 88 12:04 EDT from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

> The full text of the system I'm alluding to in the second example does do
> side-effects. They are of two kinds:
>  - ADJUST-ARRAY is done on one of the arrays 
...
>  - If the slot mappings change, it fills the table with new values.

Kent,
OK, I think I see now where you're coming from, but I don't think we really
have a conflict here.   Going back to the original proposal, it says:

   The READ-ONLY-P argument designates whether the result can be considered
   read-only constant. If NIL, the result must be considered ordinary,
   modifiable data. If T, the result is a read-only quantity which may, as
   appropriate, be copied into read-only space and/or shared with other
   programs.

What this means to me, in the context of the way we implement
write-protection of constants, is that any data structures consed up as a
result of the evaluation of the form is permitted to be done in the
write-protected area.  Thus, it would not be permissible to do something
like:

   (let ((x '#,(list ...)))
     (setf (car x) ...))

However, in your case where the effect of the evaluated form is to return a
pointer to an already existing array, that array continues to exist in
whatever memory area it was in before, so there is no prohibition against
changing its contents.  We don't actually do write-protection of #, values,
but this seems to say that it wouldn't prevent you from doing what you want
anyway.  Of course, though, if you create the array on the first reference,
then you would have a problem if it got created in the write-protected area.
Also, the description of READ-ONLY-P T goes beyond the behavior I envisioned,
since it permits copying the value, which I would have to agree doesn't sound
desirable.

That then leads me to wonder whether the semantics should be to simply always
permit modification, or whether the READ-ONLY-P option really is needed.

After being forced to think about this more deeply and re-reading the
proposal, I am now more favorably inclined towards the proposal
LOAD-TIME-EVAL:NEW-SPECIAL-FORM.  Even the change to use #, outside of ' is
beginning to make more sense.  The only serious objection I have left is that
the name LOAD-TIME-CONSTANT ought to be changed since the word "constant"
seems misleading.   Maybe something like EVAL-AT-LOAD-TIME ?

  -- David Gray

∂09-Sep-88  1629	CL-Compiler-mailer 	Re: LOAD-TIME-EVAL  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Sep 88  16:28:40 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 457108; Fri 9-Sep-88 19:25:43 EDT
Date: Fri, 9 Sep 88 19:25 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: LOAD-TIME-EVAL
To: Gray@DSG.csc.ti.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: <2798835110-1881175@Kelvin>
Message-ID: <880909192511.2.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Fri, 9 Sep 88  17:11:50 CDT
    From: David N Gray <Gray@DSG.csc.ti.com>

    ... After being forced to think about this more deeply and re-reading the
    proposal, I am now more favorably inclined towards the proposal
    LOAD-TIME-EVAL:NEW-SPECIAL-FORM. ...

Well, I'm glad I'm finally taking the time to write down some of my
thoughts on this instead of quietly fuming every time I see mail on
this that disagrees with what I'm thinking. And I very much appreciate
your taking the time to do all this extra study. 

    The only serious objection I have left is that the name LOAD-TIME-CONSTANT
    ought to be changed since the word "constant" seems misleading.   Maybe
    something like EVAL-AT-LOAD-TIME ?

My problem with anything that has "EVAL" in it is that it gets involved in
problems of quoting. I think people would expect EVAL-AT-LOAD-TIME to do 
`double evaluation' that EVAL is always accused of doing (once at argument
evaluation time, once in the function itself).

I also would prefer a name that was passive rather than active for similar
reasons and for reasons of personal stylistic preference.

How would LOAD-TIME-VALUE strike you?

An interesting issue that I don't remember if I addressed was whether 
multiple values could fall through. If you believed in such things, you
might like LOAD-TIME-VALUES.

The reason that I mention this is that maybe we should take the hint from
the people who've referred to own variables and call the form OWN-VALUE
(or OWN-VALUES). [I thought for a while about an OWN declaration on a
variable, but since the tradition in Lisp is to base things around the
objects and not the homes, it seemed to make more sense to allow anonymous
`own quantities' so I ruled out OWN declarations in favor of such a form.]

Then we could write:

 (AREF *FORTRAN-MEMORY*
       (OWN-VALUE (LOOKUP-FUNCTION-VARIABLE-OFFSET 'FOO 'X)))

Compilers would naturally do something somewhat smart with the following,
and could easily be made a lot smarter with a little work:

 (DEFUN FOO (X)
   (AREF *FORTRAN-MEMORY*
         (+ (OWN-VALUE (LOOKUP-FUNCTION-VARIABLE-OFFSET 'FOO 'X)) X)))

eg, some compilers could just rewrite this internally as

 (SETF (SYMBOL-FUNCTION 'FOO)
       (LET ((TEMP-0001 (LOOKUP-FUNCTION-VARIABLE-OFFSET 'FOO 'X)))
	 #'(LAMBDA (X)
	     (AREF *FORTRAN-MEMORY* (+ TEMP-0001 X)))))

I could even imagine some fan of own variables coming up with:

 (DEFMACRO WITH-OWN-VARIABLES (BINDINGS &BODY DECLS-AND-FORMS)
   `(LET ,(MAPCAR #'(LAMBDA (BINDING)
		      `(,(CAR BINDING) (OWN-VALUE ,(CADR BINDING))))
		  BINDINGS)
      ,@FORMS))

Thinking about this made me wonder if

 (MULTIPLE-VALUE-BIND (X Y Z) (OWN-VALUE (F)) ...)

should work, which is why I wondered if it shouldn't be OWN-VALUES.

Buy any of this?

[If not, do you at least buy my arguments for not using your proposed
name and preferring something that (a) doesn't have EVAL and (b) is
passive in structure?]

∂12-Sep-88  0836	CL-Compiler-mailer 	Re: LOAD-TIME-EVAL  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 12 Sep 88  08:36:13 PDT
Received: by ti.com id AA20467; Mon, 12 Sep 88 10:33:52 CDT
Received: from Kelvin by tilde id AA14707; Mon, 12 Sep 88 10:25:23 CDT
Message-Id: <2799070037-424555@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 12 Sep 88  10:27:17 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Compiler@SAIL.Stanford.EDU
Subject: Re: LOAD-TIME-EVAL
In-Reply-To: Msg of Fri, 9 Sep 88 19:25 EDT from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

> My problem with anything that has "EVAL" in it is that it gets involved in
> problems of quoting. I think people would expect EVAL-AT-LOAD-TIME to do 
> `double evaluation' that EVAL is always accused of doing (once at argument
> evaluation time, once in the function itself).
> 
> I also would prefer a name that was passive rather than active for similar
> reasons and for reasons of personal stylistic preference.
> 
> How would LOAD-TIME-VALUE strike you?

Kent,
That sounds fine to me.

> An interesting issue that I don't remember if I addressed was whether 
> multiple values could fall through. If you believed in such things, you
> might like LOAD-TIME-VALUES.

That sounds ugly.  Unless someone can demonstrate a compelling need for
multiple values there, I'd rather not have to support it.

> The reason that I mention this is that maybe we should take the hint from
> the people who've referred to own variables and call the form OWN-VALUE
> (or OWN-VALUES). 

Algol programmers know what "own" means, but I think the C term "static"
is more meaningful.

>...
> I could even imagine some fan of own variables coming up with:
> 
>  (DEFMACRO WITH-OWN-VARIABLES (BINDINGS &BODY DECLS-AND-FORMS)
>    `(LET ,(MAPCAR #'(LAMBDA (BINDING)
> 		      `(,(CAR BINDING) (OWN-VALUE ,(CADR BINDING))))
> 		  BINDINGS)
>       ,@FORMS))

But that's not really an "own" variable because any alteration by SETQ
is local to the current invocation of the function.

  -- David Gray

∂12-Sep-88  0856	CL-Compiler-mailer 	Re: LOAD-TIME-EVAL  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Sep 88  08:56:46 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 457638; 12 Sep 88 11:54:49 EDT
Date: Mon, 12 Sep 88 11:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: LOAD-TIME-EVAL
To: Gray@DSG.csc.ti.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: <2799070037-424555@Kelvin>
Message-ID: <880912115402.3.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Mon, 12 Sep 88  10:27:17 CDT
    From: David N Gray <Gray@DSG.csc.ti.com>

        Date: Fri, 9 Sep 88 19:25 EDT
        From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

	... How would LOAD-TIME-VALUE strike you?

    ... That sounds fine to me. ...

	The reason that I mention this is that maybe we should take
	the hint from the people who've referred to own variables
	and call the form OWN-VALUE (or OWN-VALUES). 

    Algol programmers know what "own" means, but I think the C term "static"
    is more meaningful.

Hmmm. I was originally thinking `static' might get confused with
`static variables', but as you mention below, that's a separate issue
and the uses of the word static are compatible. Perhaps STATIC-VALUE
would probably be more mnemonic to anyone not familiar with either
C or Algol. (Or perhaps just STATIC.)

        I could even imagine some fan of own variables coming up with:

          (DEFMACRO WITH-OWN-VARIABLES (BINDINGS &BODY DECLS-AND-FORMS)
    	    `(LET ,(MAPCAR #'(LAMBDA (BINDING)
     		     	       `(,(CAR BINDING)
				 (OWN-VALUE ,(CADR BINDING))))
	     		   BINDINGS)
               ,@FORMS))

    But that's not really an "own" variable because any alteration by SETQ
    is local to the current invocation of the function.

Right again. [Boy, between this and the tail recursion biz on CL-Cleanup,
I think I'm getting pretty sloppy lately. Oh well. Thanks for catching
this.]

∂12-Sep-88  1051	CL-Compiler-mailer 	issue LOAD-TIME-EVAL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 12 Sep 88  10:51:04 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA03339; Mon, 12 Sep 88 11:48:44 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA17948; Mon, 12 Sep 88 11:47:54 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809121747.AA17948@defun.utah.edu>
Date: Mon, 12 Sep 88 11:47:53 MDT
Subject: issue LOAD-TIME-EVAL
To: cl-compiler@sail.stanford.edu
Cc: gray@dsg.csc.ti.com, kmp@stony-brook.scrc.symbolics.com

Well, it looks like after all of the debate on this issue we are
pretty much back where we started with KMP's original
LOAD-TIME-EVAL:NEW-SPECIAL-FORM proposal, except with a possible
change of name from LOAD-TIME-CONSTANT to LOAD-TIME-VALUE.  (A while
back somebody else suggested calling it UNVARYING, btw.)

We still have not addressed the issue I raised some time ago.  The
proposal guarantees that each LOAD-TIME-CONSTANT "expression" is
evaluated only once.  What equality predicate is used to compare them?
Does "expression" refer to the entire LOAD-TIME-CONSTANT form or the
expression within it to be evaluated (neither of which are guaranteed
to be unique)?  I think it would help clarify things if we suggested
an implementation technique to be used in the interpreter.

Finally, how important is it that evaluation take place exactly once
in the interpreter?  Other kinds of preprocessing transformations,
notably macro expansion, are allowed to happen repeatedly in
interpreted code but compilation guarantees that no further
transformations will be performed on that piece of code.  I think it
would certainly make the language spec cleaner if we could treat this
construct in the same way, instead of having to make yet another
exception for it.

-Sandra
-------

∂12-Sep-88  1459	CL-Compiler-mailer 	issue DEFINING-MACROS-NON-TOP-LEVEL, version 3    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 12 Sep 88  14:59:45 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA12986; Mon, 12 Sep 88 15:58:34 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA18152; Mon, 12 Sep 88 15:58:31 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809122158.AA18152@defun.utah.edu>
Date: Mon, 12 Sep 88 15:58:30 MDT
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL, version 3
To: cl-compiler@sail.stanford.edu

David Gray has pointed out that the first paragraph of section (4) in
the version of this proposal that was distributed at the last meeting
was badly garbled.  Here is a corrected version.

-Sandra


Issue:		DEFINING-MACROS-NON-TOP-LEVEL
References:	CLtL p. 66-70, 143
		Issue EVAL-WHEN-NON-TOP-LEVEL
		Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Category:	CLARIFICATION, ENHANCEMENT
Edit History:   6-May-88, V1 by Sandra Loosemore
		9-Jun-88, V2 by Sandra Loosemore
		12-Sep-88, V3 by Sandra Loosemore (fix garbled section 4)


Problem Description:

CLtL leaves the interpretation of defining forms such as DEFMACRO and
DEFVAR that appear in other than top-level locations unspecified.
Resolution of other issues (EVAL-WHEN-NON-TOP-LEVEL and
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS) now allows reasonable
semantics to be assigned to defining forms which appear at
non-top-level.


Proposal: DEFINING-MACROS-NON-TOP-LEVEL:ALLOW

(1) Clarify that while defining macros normally appear at top level,
it is meaningful to place them in non-top-level contexts and that the
compiler must handle them properly in all situations.  Remove the
language on p. 66 of CLtL which states that the compiler is not
required to recognize defining macros at other than top-level.

(2) The proposal COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
defines a model for specifying how defining macros work.  To
summarize, the expansion of the macro (rather than its expander
function) is responsible for storing information about the definition.
Compile-time side effects are typically handled by including one or
more EVAL-WHEN forms in the expansion.  A compiler may choose
some other implementation, such as treating defining macros as
implementation-specific special forms, provided that the semantics
are compatible.

(3) Defining macros which define functional objects (such as DEFUN and
DEFMACRO) must ensure that the functions are defined in the lexical
environment in which the defining macro appears.  In the model
referred to above, this would normally be implemented by producing a
FUNCTION special form in the macro expansion.  For example, the
following code causes the function BAR to be closed over the variable
X:

    (let ((x  (some-hairy-computation)))
        (defun bar (y) (+ x y)))

(4) The language on p. 145 of CLtL, which states that macro functions
are always defined in the null lexical environment, should be removed.
Instead, the defining forms DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and
the complex form of DEFSETF, which make functional definitions
available at compile time, use the environment which is apparent at
the time of evaluation.  When calls to these macros appear in a
non-null lexical environment, an explicit (EVAL-WHEN (COMPILE) ...)
must normally be wrapped around the entire containing top-level form
to ensure that the correct lexical environment is seen at both compile
time and load time.

An example may help clarify why this is necessary.  The code fragment

    (let ((x  (some-hairy-computation)))
        (defmacro bar-macro (y) `(+ ,x ,y)))

would macroexpand into something similar to

    (let ((x  (some-hairy-computation)))
        (eval-when (eval compile load)
            (setf (macro-function 'bar-macro) 
	          #'(lambda (form env)
		        (let ((y  (second form)))
			    `(+ ,x ,y))))
            'bar-macro))

Since the rules for (EVAL-WHEN (COMPILE) ...) state that evaluation
takes place in the null lexical environment, in this situation X would
be treated as a special variable within the macro function.  However,
in the EVAL or LOAD situations, the lexical value of X would be used.
To ensure consistency, the correct definition would be:

    (eval-when (eval compile load)
        (let ((x  (some-hairy-computation)))
            (defmacro bar (y) `(+ ,x ,y))))


(5) Clarify that ``top-level forms'' are evaluable data objects read
in from an input source (such as a keyboard or disk file) by
successive calls to the function READ.  As a special case, forms
within a top-level PROGN are also considered to be top-level forms.
Specify that top-level forms in a file being compiled are guaranteed
to be processed sequentially, but the order in which subforms of a
top-level form are processed by the compiler is explicitly left
unspecified.  It is an error for user code to depend upon the
compile-time side-effects of a defining macro within the same
top-level form in which the defining macro appears.


Rationale:

The notion of a ``top-level form'' is rather confused, since the term
is used in CLtL to refer both to a place where a form may appear (what
this proposal continues to call ``top-level''), and to instances of
forms which traditionally appear there (what this proposal calls
``defining macros'').  

There has been a suggestion that the notion of a top-level form should
be extended to include forms in the body of a top-level LET, to allow
forms such as DEFUN to be meaningful there.  However, we feel that a
cleaner solution is to remove the restrictions on the placement of
defining macros altogether. 


Current Practice:


Cost to implementors:


Cost to users:

None.  This is a compatible extension.


Benefits:

The notion of defining macros as being somehow special is removed from
the language.  Allowing defining macros to appear anywhere instead of
restricting them to certain positions results in a cleaner language
design.


Discussion:
-------

∂16-Sep-88  1525	CL-Compiler-mailer 	issue LOAD-TIME-EVAL, again   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Sep 88  15:25:00 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA14871; Fri, 16 Sep 88 16:22:16 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19193; Wed, 14 Sep 88 14:14:16 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809142014.AA19193@defun.utah.edu>
Date: Wed, 14 Sep 88 14:14:14 MDT
Subject: issue LOAD-TIME-EVAL, again
To: cl-compiler@sail.stanford.edu
Cc: kmp@stony-brook.scrc.symbolics.com

I've been trying to sketch out a revised version of proposal 
LOAD-TIME-EVAL:NEW-SPECIAL-FORM that addresses the problems that have
been raised recently, and once again I need some feedback before I can
proceed.

I've come to the conclusion that allowing the result of the
LOAD-TIME-CONSTANT form to be modified destructively (that is, by not
forcing the value to be read-only) requires an absolute guarantee that
each reference to a (LOAD-TIME-CONSTANT ...) form results in exactly
one evaluation of the embedded form.  The problem with allowing
collapsing of multiple references to EQL (or even EQUAL) forms is
fairly obvious; each reference should get its own, freshly consed
result value to bash on.  

The other problem is with my earlier idea of allowing the interpreter
to perform multiple evaluations on the subform.  This won't work
because user code might rely on destructive modifications to the
cached value, and break if a fresh copy is returned instead.  One
possible solution would be to prohibit this by specifying that
successive evaluations of the same (LOAD-TIME-CONSTANT ...) form
return values that are semantically equivalent but not necessarily EQ.
Effectively, this would require users not to assume anything about the
contents of the object and to explicitly reinitialize it each time.

The reasons why I would like to remove the restriction on the
interpreter are both aesthetic (to make LOAD-TIME-CONSTANT processing
similar to macro expansion) and practical.  I'm very concerned that
requiring the interpreter to recognize unique references to
(LOAD-TIME-CONSTANT ...) forms so it can guarantee unique evaluation
would require some really tricky implementation techniques.
Code-bashing is the obvious way to do it, but besides being forbidden
by the current proposal, it isn't such a good thing to do on quoted
expressions passed to EVAL.  The other alternative I can think of
would be to have EVAL or FUNCTION to do a preprocessing codewalk to
take care of the LOAD-TIME-CONSTANTs.  This would be a major change
for many implementations and I think we would run into a lot of
resistance to it.

I see the following alternatives:

(1) Remove the optional READ-ONLY-P argument and require that the
    results of LOAD-TIME-CONSTANT forms be treated as read-only.  Remove
    the restriction on the interpreter evaluating the forms only once,
    and allow both the interpreter and compiler to collapse EQUAL
    (LOAD-TIME-CONSTANT ...) forms.

(2) Retain the READ-ONLY-P argument while specifying that successive 
    invocations of a given (LOAD-TIME-CONSTANT ...) form return values 
    that are semantically equivalent but not necessarily EQ, to allow  
    the interpreter to do multiple evaluations of the nested <form>.
    Collapsing of (LOAD-TIME-CONSTANT ...) forms would not be permitted.

(3) Somebody suggest a simpler implementation technique that will
    ensure that the subforms of (LOAD-TIME-CONSTANT ...) expressions 
    are only evaluated once.

(4) Somebody convince me that implementors are really willing to
    rewrite their interpreters to use a preprocessor that will ensure
    that subforms of (LOAD-TIME-CONSTANT ...) forms are only evaluated 
    once.

Comments, please?

-Sandra
-------

∂16-Sep-88  1850	CL-Compiler-mailer 	Issue PROCLAIM-INLINE-WHERE   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 16 Sep 88  18:50:04 PDT
Received: by ti.com id AA27870; Fri, 16 Sep 88 20:48:21 CDT
Received: from Kelvin by tilde id AA11645; Fri, 16 Sep 88 20:31:34 CDT
Message-Id: <2799451988-6110662@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 16 Sep 88  20:33:08 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: cl-compiler@sail.stanford.edu
Subject: Issue PROCLAIM-INLINE-WHERE

 
Issue:		PROCLAIM-INLINE-WHERE
References:	CLtL p. 156, 159
Category:	CLARIFICATION
Edit History:   16 Sept. 88 V1 by David Gray
Status:		For preliminary discussion 
 
Problem Description:

  CLtL does not specify whether a (PROCLAIM '(INLINE ...)) should come
  before or after the DEFUNs that it refers to, but in most
  implementations the compiler can't expand a function inline
  unless it knows at the time it processes the DEFUN that the definition
  needs to be saved for use in inline expansion.
 
Proposal PROCLAIM-INLINE-WHERE:BEFORE:
 
  Clarify that (PROCLAIM '(INLINE ...)) tells the compiler both that it is
  desirable to use inline expansion for calls to the functions indicated
  and that the compilation of any subsequent DEFUN of one of the functions
  should record whatever information is used for performing inline
  expansions.  Consequently, the proclamation should precede the
  definition of the functions that it names.  When compiling a function
  call, if the function has been proclaimed INLINE but the current
  definition of the function was established before the PROCLAIM was
  processed, it is implementation-dependent whether the function will
  actually be expanded inline.

 Rationale:

  This clarification brings the specification in line with current
  practice.  The only alternative would appear to be to require the
  compiler to always save the definition of every function, and that
  doesn't seem reasonable.

 Test Cases/Examples: 

  Given the following input to COMPILE-FILE, does F1 get expanded inline
  in F2?

    (defun f1 (a) (+ a 100))
    (proclaim '(inline f1))
    (defun f2 (b) (f1 b))
 
 Current Practice:
 
  The documentation for Lucid and the TI Explorer both say that INLINE
  proclamations need to precede the function definition.  Symbolics
  doesn't appear to document this, but requires it anyway.  Thus none of
  these three implementations do the inline expansion in the example
  above.

 Cost to implementors:
 
  Probably none required, although given this clarification it would be
  nice if compilers warned about an INLINE proclamation that follows the
  indicated DEFUN in the same file.

 Cost to users:
  
  None.

 Benefits:

  Users will know how to use INLINE proclamations correctly.

 Costs of Non-Adoption: 

  Continued confusion over cases such as the example above, which
  conform to CLtL but don't do what is expected.

 Discussion:

∂16-Sep-88  1850	CL-Compiler-mailer 	Issue PROCLAIM-ETC-IN-COMPILE-FILE 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 16 Sep 88  18:50:15 PDT
Received: by ti.com id AA27874; Fri, 16 Sep 88 20:48:28 CDT
Received: from Kelvin by tilde id AA11850; Fri, 16 Sep 88 20:39:50 CDT
Message-Id: <2799452504-6141654@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 16 Sep 88  20:41:44 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: cl-compiler@sail.stanford.edu
Subject: Issue PROCLAIM-ETC-IN-COMPILE-FILE

Here's a first attempt at resolving another item from the backlog of known
problem areas.

 
Issue:		PROCLAIM-ETC-IN-COMPILE-FILE
References:	CLtL p. 182 [package functions],
		  p. 156 [PROCLAIM], P. 188 [REQUIRE], 
		  p. 439 [COMPILE-FILE];
                Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Category:	CLARIFICATION
Edit History:   15 Sept. 88, V1 by David Gray
Status:		For preliminary discussion 
 
Problem Description:

  Page 182 of CLtL says that COMPILE-FILE needs to treat top-level calls
  to the following package functions as though they were wrapped in an
  (EVAL-WHEN (COMPILE LOAD EVAL) ...):

    EXPORT  IMPORT  IN-PACKAGE  MAKE-PACKAGE SHADOW
    SHADOWING-IMPORT  UNEXPORT  UNUSE-PACKAGE  USE-PACKAGE

  There are other things that need special handling by the compiler that
  are not explicitly specified by CLtL.  The proposal
  COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY addresses the part of
  the problem pertaining to macros that define things.  The following
  proposal adds PROCLAIM and REQUIRE to the list of functions needing
  special handling.
 
Proposal PROCLAIM-ETC-IN-COMPILE-FILE:CLARIFY:
 
  Clarify that when COMPILE-FILE encounters a call to one of the following
  functions at top level in a file, the form will be evaluated at compile
  time as well as at load time:

    EXPORT  IMPORT  IN-PACKAGE  MAKE-PACKAGE  PROCLAIM  REQUIRE  SHADOW
    SHADOWING-IMPORT  UNEXPORT  UNUSE-PACKAGE  USE-PACKAGE

  Note that the compile-time evaluation of these package functions can
  affect the way that the remaining top-level forms in the file are read.

  In the case of PROCLAIM, it is implementation-dependent whether the
  evaluation affects the global environment or is only recorded in data
  structures used by the compiler, and whether the effect of the
  evaluation remains in the global environment after COMPILE-FILE returns.

  (PROCLAIM '(OPTIMIZE ...)) is a special case that is evaluated only at
  compile-time and not at load time, and that affects only the current
  file being compiled.

  Note that the behavior specified here can still be altered by the
  user by wrapping an explicit EVAL-WHEN around the form.

 Rationale:

  Experience seems to have shown that this behavior best matches what
  people expect to have happen.  The examples on pages 189 and 191 of CLtL
  won't work right unless REQUIRE takes effect at compile-time.  Since
  most of the things that PROCLAIM can be used for only affect the
  compiler, it doesn't make much sense for the compiler to not take notice
  during compilation.  Optimization control is something that one usually
  wants to control locally, rather that having a proclamation in one file
  affect other unrelated files compiled later.
 
 Current Practice:

  This proposal follows what the Explorer does, except that (EVAL-WHEN
  (LOAD) (PROCLAIM '(OPTIMIZE ...))) doesn't do anything.  The Symbolics
  compiler has special top-level handling for all of these functions,
  although the details are not clear.  The Lucid documentation indicates
  that certain functions at top-level are treated as though within an
  (EVAL-WHEN (EVAL COMPILE LOAD) ...): REQUIRE, all of the package
  functions listed above, INTERN, and UNINTERN; it is not clear what
  happens with PROCLAIM.

 Cost to implementors:

  Since implementations are already required to have a mechanism for
  compile-time handling of the package functions, it should only require
  minor adjustments to add handling for PROVIDE and REQUIRE if they aren't
  handled already.  The main thing that most implementations would need to
  do is to make OPTIMIZE proclamations local to the file, but that should
  be fairly simple.

 Cost to users:

  If someone has a use of REQUIRE that they want to only be a load-time
  dependency and their implementation did not previously do REQUIRE at
  compile-time, they may want to wrap (EVAL-WHEN (EVAL LOAD) ...) around
  it.

  If someone has a use of (PROCLAIM '(OPTIMIZE ...)) that they really want
  to be global, they would need to wrap (EVAL-WHEN (EVAL COMPILE LOAD)
  ...) around it.
  
 Benefits:

  Users will know what to expect when they use PROCLAIM and REQUIRE.
  
 Costs of Non-Adoption: 

  In order to write programs that would be sure to be portable, the user
  would have to wrap an (EVAL-WHEN (EVAL COMPILE LOAD) ...) around each use
  of PROCLAIM or REQUIRE in order to be sure of what will happen.

 Aesthetics:

  Programs look cleaner if EVAL-WHEN is only needed for unusual cases
  instead of being required for the normal cases.
 
 Discussion:

  Cleanup proposal PROCLAIM-SCOPE:ADD-KEYWORD-PERVASIVE wanted to add an
  option to PROCLAIM to control whether the effect is local to the current
  file.  That may be better handled by an extension to EVAL-WHEN since
  that kind of control might be wanted for definitions as well as
  proclamations.  If the handling of OPTIMIZE specified here is taken as a
  default, that issue can be pursued separately from this one.

∂17-Sep-88  0905	CL-Compiler-mailer 	Re: Issue PROCLAIM-INLINE-WHERE    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Sep 88  09:05:35 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA28907; Sat, 17 Sep 88 10:04:18 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA20567; Sat, 17 Sep 88 10:04:05 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809171604.AA20567@defun.utah.edu>
Date: Sat, 17 Sep 88 10:04:03 MDT
Subject: Re: Issue PROCLAIM-INLINE-WHERE
To: David N Gray <Gray@dsg.csc.ti.com>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Fri, 16 Sep 88  20:33:08 CDT

This proposal looks fine to me.  I seem to recall from the verbal
discussion at the last meeting that both VaxLisp and ExCL also require
the inline proclamations to come first (somebody correct me if I'm
wrong).

-Sandra
-------

∂17-Sep-88  0926	CL-Compiler-mailer 	Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Sep 88  09:26:38 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA29158; Sat, 17 Sep 88 10:25:21 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA20581; Sat, 17 Sep 88 10:25:19 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809171625.AA20581@defun.utah.edu>
Date: Sat, 17 Sep 88 10:25:18 MDT
Subject: Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE
To: David N Gray <Gray@dsg.csc.ti.com>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Fri, 16 Sep 88  20:41:44 CDT

This proposal seems like a reasonable fallback in the event that we
are unable to decide what else to do with the N random package forms.
There was some discussion earlier on defining a DEFPROCLAIM macro.
There has also been an issue before the cleanup committee to remove or
change the meaning of REQUIRE.

For the current practice section, VaxLisp evaluates PROCLAIMs at
compile time.

One thing that might be confusing about this proposal is the use of
the adjective "top-level".  If the special form EVAL-WHEN is implemented 
as a macro (as suggested in proposal EVAL-WHEN-NON-TOP-LEVEL), then
the call to REQUIRE might also appear to be "top-level" (because the
EVAL-WHEN would expand into a PROGN):

    (eval-when (eval load)
        (require :foo))

It might bear repeating that EVAL-WHEN is a special form and that its
subforms are never "top-level".

-Sandra
-------

∂19-Sep-88  0845	CL-Compiler-mailer 	Issue status for October meeting   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Sep 88  08:44:57 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA03433; Mon, 19 Sep 88 09:43:36 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA00753; Mon, 19 Sep 88 09:43:33 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809191543.AA00753@defun.utah.edu>
Date: Mon, 19 Sep 88 09:43:32 MDT
Subject: Issue status for October meeting
To: cl-compiler@sail.stanford.edu

Here is a list of the issues we have pending currently.  I am going to
send things out to the full committee at the end of the week, so if
you have a quibble with something, complain soon....

Also, our subcommittee meeting is set for Monday the 10th from 2-5 pm.
I expect there will be some discussion of the proposals that are
currently in draft form, and hopefully we can make some progress on
the issues for which there is not a proposal yet.  We also need to
discuss what else we can realistically accomplish by January.



Issues that were distributed for comments at the last meeting:

    COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
	What are the compile-time side-effects of the various defining
	macros?

    EVAL-WHEN-NON-TOP-LEVEL
	What does EVAL-WHEN mean when it does not appear as a top-level
	form?

    DEFINING-MACROS-NON-TOP-LEVEL
	Can defining macros such as DEFUN appear in non-top-level
	locations?

        This issue provoked the only comments that were received since
	the last meeting:

	* The wording of section 4 was garbled.
	  This has been fixed in the latest version of the proposal.

	* Many implementations do not allow a lexical environment to be
	    shared between compiled and interpreted functions.
	  A new issue, COMPILE-ARGUMENT-PROBLEMS, has been written up
	    to deal with this problem.


New issues that are ready to be voted upon:

    COMPILE-ARGUMENT-PROBLEMS
	What functions can be compiled with COMPILE?

    COMPILE-FILE-PACKAGE
	COMPILE-FILE should rebind *PACKAGE*.

    OPTIMIZE-DEBUG-INFO
	What OPTIMIZE quality controls debuggability of compiled code?

    PROCLAIM-INLINE-WHERE
	INLINE proclamations should be placed before the corresponding
	DEFUN.


Issues in draft form (comments requested):

    COMPILE-ENVIRONMENT-CONSISTENCY
	What things can the compiler safely "wire in" to code being
	compiled?

    PROCLAIM-ETC-IN-COMPILE-FILE
	Add PROCLAIM, REQUIRE to list of N random package functions that
	COMPILE-FILE must eval at compile time.


Issues in progress (no proposals ready yet):

    LOAD-TIME-EVAL 
        What does #, mean?  Where can it appear?
    
    COMPILED-CONSTANTS
        Are quoted constants in compiled code read-only?  Must the compiler
        handle circular constants?  Preserve nonprintable aspects of constant
        data?
-------

∂19-Sep-88  0933	CL-Compiler-mailer 	Issue: LOAD-TIME-EVAL    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 19 Sep 88  09:32:52 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 461592; Mon 19-Sep-88 12:29:51 EDT
Date: Mon, 19 Sep 88 12:29 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL
To: sandra%defun@cs.utah.edu
cc: CL-Compiler@SAIL.Stanford.EDU, CL-Cleanup@SAIL.Stanford.EDU
References: <8809191543.AA00753@defun.utah.edu>,
            <19880918233023.5.GREGOR@PORTNOY.parc.xerox.com>,
            <880917-151515-2442@Xerox>
Message-ID: <880919122944.6.KMP@GRYPHON.SCRC.Symbolics.COM>

Fyi, the following discussion recently took place on CL-Cleanup...

 Date: 17 Sep 88 15:15 PDT
 From: masinter.pa@Xerox.COM
 To:   CL-Cleanup@SAIL.Stanford.EDU
 
 I think this is a moderately useful issue to be resolved if the compiler
 committee hasn't done so. I'm not on cl-compiler so I don't know what, if any,
 progress has been made on the numerous issues that were deferred to them. Was
 this one of them?
-----
 Date: Sat, 17 Sep 88 19:21 EDT
 From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
 To:   CL-Cleanup@SAIL.Stanford.EDU

 The CL-Compiler committee has been actively discussing this, so I think
 we can safely ignore it for the time being.

 If they fail to reach closure and submit something to X3J13 in a timely
 fashion, I will take care of reviving it here.
-----
 Date: Sun, 18 Sep 88 16:30 PDT
 From: Gregor.pa@Xerox.COM
 To:   CL-Cleanup@SAIL.Stanford.EDU

 Given the current X3J13 schedule, what does timely mean?  Is there
 reason to believe the compiler committee will arrive in Washington with
 a detailed proposal that they want the full committee to vote on?  If
 not, the cleanup committee should probably generate its own proposal
 now.

∂19-Sep-88  1205	CL-Compiler-mailer 	Re: issue OPTIMIZE-DEBUG-INFO 
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 19 Sep 88  12:05:34 PDT
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU; 19 Sep 88 15:03:01 EDT
To: David N Gray <Gray@DSG.csc.ti.com>
cc: CL-Compiler@SAIL.Stanford.EDU
Subject: Re: issue OPTIMIZE-DEBUG-INFO 
In-reply-to: Your message of Fri, 09 Sep 88 14:09:59 -0500.
             <2798824199-1225652@Kelvin> 
Date: Mon, 19 Sep 88 15:02:11 EDT
From: Rob.MacLachlan@WB1.CS.CMU.EDU


I favor OPTIMIZE-DEBUG-INFO:SAFETY with reservations.

I'm not sure how important it is that debug-info dumping be controlled in a
portable way, since the perception of debug-info "goodness" is
fundamentally dependent on using the debugger, which is implementation
dependent.

I do think that the definition of the SAFETY quality should be broadened.
This could include allowing the SAFETY quality to control debug-info at the
implementation's discretion.

To me, safety means that system integrity will be maintained, and
ill-defined operations will signal errors rather than producing meaningless
results.  The more work the system does to ensure that the program will run
in all Common Lisp implementations, the safer it is.  The current
definition of safety as "run-time error checking" is too narrow, since some
error checking can be done at compile time, but might be suppressed if
COMPILE-SPEED is important.

Debuggability means that once you are in the debugger, you will be able to
tell what the hell is going on.  This is related to safety:
 -- If system integrity is badly damaged, you may not make it into the
    debugger.
 -- If nobody checks for errors, then you will never end up in the debugger
    (modulo breakpoints, etc.)
Safe code is a pre-requisite for debuggable code, so debuggability can be
considered "additional safety".

I am opposed to requiring the system to control debug-info generation in
any particular way.  Debug-info need not be controlled by the compiler at
all: it could be conditionally GC'd away at system build time.

  Rob

∂19-Sep-88  1226	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 3
Received: from ti.com by SAIL.Stanford.EDU with TCP; 19 Sep 88  12:26:28 PDT
Received: by ti.com id AA16082; Mon, 19 Sep 88 14:23:48 CDT
Received: from dsg by tilde id AA07422; Mon, 19 Sep 88 14:14:56 CDT
Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 19 Sep 88  11:49:40 CDT
Message-Id: <2799679750-3383667@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 19 Sep 88  11:49:10 CDT
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 DEFINING-MACROS-NON-TOP-LEVEL, version 3
In-Reply-To: Msg of Mon, 12 Sep 88 15:58:30 MDT from sandra%defun@cs.utah.edu (Sandra J Loosemore)

> (5) Clarify that ``top-level forms'' are evaluable data objects read
> in from an input source (such as a keyboard or disk file) by
> successive calls to the function READ.  As a special case, forms
> within a top-level PROGN are also considered to be top-level forms.

I would like to see the last sentence above amended to say "...
top-level PROGN or COMPILER-LET ...".  Both TI and Symbolics have
inherited this behavior from the MIT Lisp Machine system, and it seems
to be the reasonable thing to do.

  -- David Gray

∂19-Sep-88  1225	CL-Compiler-mailer 	issue OPTIMIZE-DEBUG-INFO
Received: from ti.com by SAIL.Stanford.EDU with TCP; 19 Sep 88  12:25:16 PDT
Received: by ti.com id AA16070; Mon, 19 Sep 88 14:23:31 CDT
Received: from dsg by tilde id AA07398; Mon, 19 Sep 88 14:14:32 CDT
Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 19 Sep 88  11:33:05 CDT
Message-Id: <2799678750-3323601@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 19 Sep 88  11:32:30 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
Subject: issue OPTIMIZE-DEBUG-INFO
To: CL-Compiler@SAIL.Stanford.edu

Since no one has raised any objections to this idea, I hereby propose
taking a vote on this at the forthcoming meeting.
  -- David Gray

--
 
Issue:		OPTIMIZE-DEBUG-INFO
References:	CLtL p. 160
Category:	ADDITION
Edit History:   V1  9 Sep 1988, David Gray (initial version)
                V2 19 Sep 1988, David Gray (delete first alternative)
Status:		for sub-committee vote
 
Problem Description:

  The OPTIMIZE declaration provides a way to tell the compiler how important
  various qualities are in order to guide which optimizations are done.
  There is another quality, however, that is not mentioned, but is an
  important consideration for the compiler:  how much information
  should be included in the object code to facilitate debugging.  This
  includes both annotation added to enable a debugger to display more
  information to the user, and also suppression of optimizations that would
  confuse debugging by making it harder to connect the object code with the
  source code.

Proposal OPTIMIZE-DEBUG-INFO:NEW-QUALITY:

  In the description of the OPTIMIZE declaration, add an additional quality
  named DEBUG, described as "ease of debugging".
 
 Rationale:

  Since ease of debugging is an issue that the user will be concerned with,
  and is an issue that the compiler needs to consider, this provides a clear
  way for the user to control the amount of debugging information placed in
  the object module, with DEBUG=0 meaning none and DEBUG=3 meaning "as much
  as possible".
 
 Current Practice:

  No current implementation of this is known.
 
 Cost to implementors:

  All would have to update their handling of OPTIMIZE declarations to accept
  the new quality.
 
 Cost to users:

  One more little feature to learn.  Some problems may result from the
  addition of the symbol DEBUG to the LISP package.
  
 Benefits:

  Provides users a standard way to control the interaction between
  the compiler and debugger, and saves implementors from having to invent
  implementation-dependent solutions.

 Costs of Non-Adoption: 

  Continued confusion about how debug information should be controlled.
 
Discussion:

  Concern has been raised that there is already a problem with the
  non-orthogonality of SPEED, SAFETY, and SPACE that would be made even
  worse with DEBUG added, since users tend to be perplexed by the
  interactions of these qualities. 

∂19-Sep-88  1308	CL-Compiler-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Sep 88  13:07:58 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA11413; Mon, 19 Sep 88 14:06:37 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA00963; Mon, 19 Sep 88 14:06:17 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809192006.AA00963@defun.utah.edu>
Date: Mon, 19 Sep 88 14:06:15 MDT
Subject: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: cl-compiler@sail.stanford.edu, kmp@stony-brook.scrc.symbolics.com
Cc: cl-cleanup@sail.stanford.edu

Since the cleanup committee is expecting us to do something on this
issue promptly, I've gone ahead with the sketch for the new proposal
on this issue that I started on last week.  Not having heard anything
back from my last request for comments (are all of you compiler people
asleep?), I've rather arbitrarily decided upon allowing the
interpreter to perform multiple evaluations, and warning users that
they can get into trouble by performing destructive operations.

Because the writeup on this issue is already so long, I've only
included the most relevant parts here.  If I hear some favorable
feedback on what I've got so far, I'll finish it up the rest of it.
Otherwise, I will turn the issue back over to Pitman and the cleanup
committee in the hopes that they will be able to make more progress on
it than we have.

-Sandra



Proposal (LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM):
    
 Add a new special form, LOAD-TIME-VALUE, which has the following
 contract:

   LOAD-TIME-VALUE form &optional read-only-p	[Special Form]

   All processing of the <form> is deferred until the expression is
   in the "runtime" environment. Once that environment is available,
   <form> is evaluated in the null lexical environment and the result
   is returned; the result may also be saved for immediate access by 
   the program on subsequent evaluations.

   LOAD-TIME-VALUE is, in effect, a promise by the user that multiple
   evaluations of <form> will return values that are semantically 
   equivalent (although not necessary EQ).

   In the interpreter, (LOAD-TIME-VALUE <form>) is equivalent to
   (VALUES (EVAL (QUOTE <form>))).  However, it is permissible for
   an implementation to perform the evaluation of <form> only once for
   each reference to the surrounding LOAD-TIME-VALUE expression and to
   cache that value for subsequent use; this may be done by a 
   preprocessor, for example.

   If a LOAD-TIME-VALUE expression appears within a function compiled
   with COMPILE, the compiler may either evaluate the <form> or use
   a previously cached value.  It is guaranteed that the <form> will
   not be evaluated again at runtime; instead, the result of the
   compile-time evaluation is treated as an immediate quantity in the
   compiled code.

   If a LOAD-TIME-VALUE expression is seen by COMPILE-FILE, the compiler
   arranges for all semantic processing of <form> (including macro
   expansion) to occur at load time in a null lexical environment.  It
   is guaranteed that the evaluation of <form> will take place only once
   when the file is loaded, but the order of evaluation with respect to
   the "evaluation" of top-level forms in the file is unspecified.

   Note that, in interpreted code, there is no guarantee as to when
   evaluation of <form> will take place, or the number of times the
   evaluation will be performed.  This is intentionally similar to the
   freedom which implementations are given for when macros are expanded
   in interpreted code.

   Implementations must guarantee that each reference to a LOAD-TIME-VALUE 
   expression within a form to be evaluated results in at least one 
   evaluation of <form>.  It is not permissible to "collapse" either 
   multiple references to the same (EQ) LOAD-TIME-VALUE expression or 
   EQUAL expressions.  Note that, in the case of a LOAD-TIME-VALUE form
   appearing in a quoted expression passed to EVAL, each call to EVAL must 
   result in a new evaluation of <form>.  For example,
     (DEFVAR X 0)
     (DEFUN FOO () (EVAL '(LOAD-TIME-VALUE (INCF X))))
   is guaranteed to increment X each time FOO is called, while
     (DEFUN FOO () (LOAD-TIME-VALUE (INCF X)))
   may cause X to be evaluated only once.

   The READ-ONLY-P argument designates whether the result can be considered
   read-only constant. If NIL, the result must be considered ordinary,
   modifiable data. If T, the result is a read-only quantity which may, as
   appropriate, be copied into read-only space and/or shared with other
   programs. (Because this is a special form, this argument is -not- evaluated
   and only the literal symbols T and NIL are permitted.)

   Note that, since successive evaluations of the same LOAD-TIME-VALUE
   expression may or may not result in an evaluation which returns a 
   "fresh" object, users cannot rely upon either the persistence or
   absence of destructive side-effects.  In such cases, it is safest to
   explicitly initialize the object returned by LOAD-TIME-VALUE.

 Make #,exp be equivalent to (LOAD-TIME-VALUE exp T). As such, it
 would -always- appear in a for-evaluation position, and never inside quoted
 structure.

 Rationale:
    
   By making the description of LOAD-TIME-VALUE defined as a special
   form, we eliminate the need for it to take an environment argument.

   By making #, agree with LOAD-TIME-VALUE in terms of where it may be
   used, we simplify the description of the resulting language.

   As discussed in more detail elsewhere in this proposal, the #, syntax
   is currently only reliably useful -inside- quoted structure, but this
   is unnecessarily complicated for most known uses. Since this proposal
   suggests a meaning for #, only -outside- quoted structure, it is an
   incompatible change (though not one that would necessarily require
   vendors to immediately remove support for existing code).

   Allowing the same LOAD-TIME-VALUE to cause its nested <form> to be
   evaluated more than once makes it much simpler to implement in
   interpreters which do not perform a preprocessing code walk.  It also
   makes the rules for the time of its processing analogous to those
   for macro expansion.

   The prohibition against collapsing of shared or EQUAL LOAD-TIME-VALUE
   expressions prevents problems that could result by performing destructive
   side-effects on a value that is referenced in more than one place.


 Cost to Implementors:

   This is an incompatible change to the program interface.
   The cost is not trivial, but is not particularly high.
   Most of the "hard" substrate required to support this proposal
   probably already exist; in most cases, what needs to change is
   only the way in which the substrate is presented to the
   programmer.

   Some code-walkers would have to be taught about this new
   special form. Such changes would likely be trivial.

   For implementations that do not use a preprocessor in the interpreter,
   the simplest technique for implementing LOAD-TIME-VALUE would be to
   always evaluate <form> without caching the value.  Implementations
   that do use a preprocessing code walk could be extended to do the
   evaluation at the same time they do macro expansion.

-------

∂19-Sep-88  1311	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 3
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Sep 88  13:11:20 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA11512; Mon, 19 Sep 88 14:09:58 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA00974; Mon, 19 Sep 88 14:09:56 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809192009.AA00974@defun.utah.edu>
Date: Mon, 19 Sep 88 14:09:55 MDT
Subject: Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 3
To: David N Gray <Gray@dsg.csc.ti.com>
Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore),
        cl-compiler@sail.stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Mon, 19 Sep 88  11:49:10 CDT

Do any non-LispM implementations treat forms within a COMPILER-LET as
top-level?

-Sandra
-------

∂19-Sep-88  1323	CL-Compiler-mailer 	issue OPTIMIZE-DEBUG-INFO
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 19 Sep 88  13:19:39 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 461799; Mon 19-Sep-88 16:18:21 EDT
Date: Mon, 19 Sep 88 16:17 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue OPTIMIZE-DEBUG-INFO
To: Gray@DSG.csc.ti.com
cc: CL-Compiler@SAIL.Stanford.edu
In-Reply-To: <2799678750-3323601@Kelvin>
Message-ID: <880919161756.7.KMP@GRYPHON.SCRC.Symbolics.COM>

Fyi, the Cloe group at Symbolics would like to see the new DEBUG quality
added.

To cite an actual example, we had a user who was surprised because he
assumed that SAFETY 3 would assure him of full backtrace information in
the debugger. We don't want to make the presence of that info contingent
on high SAFETY. We can imagine low-safety applications where lots of
debugging info is needed, and high-saftey applications where little
debugging info is desired.

∂19-Sep-88  1454	CL-Compiler-mailer 	Re: issue LOAD-TIME-EVAL, again    
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 19 Sep 88  14:54:06 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA03429; Mon, 19 Sep 88 17:53:57 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA09116; Mon, 19 Sep 88 17:55:35 EDT
Message-Id: <8809192155.AA09116@mist.UUCP>
To: "sandra%defun@cs.utah.edu"@multimax (Sandra J Loosemore)
Cc: cl-compiler%sail.stanford.edu@multimax
Subject: Re: issue LOAD-TIME-EVAL, again 
In-Reply-To: Your message of Wed, 14 Sep 88 14:14:14 -0600.
             <8809142014.AA19193@defun.utah.edu> 
Date: Mon, 19 Sep 88 17:55:29 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

While I'm personally in favor of requiring LOAD-TIME-CONSTANTS to be
truly constant, i.e. read-only, it seems that too many people object
to make that option feasible.  If so, you make a very good case for
your second option.  I don't believe that we should make the
difficulty of implementing a correct Common Lisp interpreter
arbitrarily high.

∂19-Sep-88  1705	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 3
Received: from ti.com by SAIL.Stanford.EDU with TCP; 19 Sep 88  17:05:47 PDT
Received: by ti.com id AA18207; Mon, 19 Sep 88 19:03:38 CDT
Received: from Kelvin by tilde id AA14050; Mon, 19 Sep 88 18:50:43 CDT
Message-Id: <2799705118-4907812@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 19 Sep 88  18:51:58 CDT
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 DEFINING-MACROS-NON-TOP-LEVEL, version 3
In-Reply-To: Msg of Mon, 19 Sep 88 14:09:55 MDT from sandra%defun@cs.utah.edu (Sandra J Loosemore)

> Do any non-LispM implementations treat forms within a COMPILER-LET as
> top-level?

I don't know.

∂19-Sep-88  1722	CL-Compiler-mailer 	issue DEFINING-MACROS-NON-TOP-LEVEL, version 3    
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Sep 88  17:22:11 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA02649@EDDIE.MIT.EDU>; Mon, 19 Sep 88 20:03:39 EDT
Received: by spt.entity.com (smail2.5); 19 Sep 88 19:37:05 EDT (Mon)
To: sandra%defun@cs.utah.edu
Cc: Gray@dsg.csc.ti.com, cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 19 Sep 88 14:09:55 MDT <8809192009.AA00974@defun.utah.edu>
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL, version 3
Message-Id: <8809191937.AA22216@spt.entity.com>
Date: 19 Sep 88 19:37:05 EDT (Mon)
From: gz@spt.entity.com (Gail Zacharias)

   From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
   Date: Mon, 19 Sep 88 14:09:55 MDT
   Do any non-LispM implementations treat forms within a COMPILER-LET as
   top-level?

Coral does.

∂19-Sep-88  1734	CL-Compiler-mailer 	issue DEFINING-MACROS-NON-TOP-LEVEL, version 3    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Sep 88  17:34:49 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA03801g; Mon, 19 Sep 88 16:32:59 PST
Received: by blacksox id AA00923g; Mon, 19 Sep 88 17:30:37 pdt
Date: Mon, 19 Sep 88 17:30:37 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809200030.AA00923@blacksox>
To: sandra%defun@cs.utah.edu
Cc: Gray@dsg.csc.ti.com, sandra%defun@cs.utah.edu,
        cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 19 Sep 88 14:09:55 MDT <8809192009.AA00974@defun.utah.edu>
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL, version 3

   From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
   Date: Mon, 19 Sep 88 14:09:55 MDT

   Do any non-LispM implementations treat forms within a COMPILER-LET as
   top-level?

   -Sandra
   -------


Lucid does.

∂19-Sep-88  1736	CL-Compiler-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 19 Sep 88  17:36:17 PDT
Received: by ti.com id AA18463; Mon, 19 Sep 88 19:34:03 CDT
Received: from Kelvin by tilde id AA14662; Mon, 19 Sep 88 19:20:13 CDT
Message-Id: <2799706877-5013516@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 19 Sep 88  19:21:17 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Cc: cl-compiler@sail.stanford.edu, kmp@stony-brook.scrc.symbolics.com
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
In-Reply-To: Msg of Mon, 19 Sep 88 14:06:15 MDT from sandra%defun@cs.utah.edu (Sandra J Loosemore)

>     If I hear some favorable
> feedback on what I've got so far, I'll finish it up the rest of it.

It looks good to me.

>    Implementations must guarantee that each reference to a LOAD-TIME-VALUE 
>    expression within a form to be evaluated results in at least one 
>    evaluation of <form>.  It is not permissible to "collapse" either 
>    multiple references to the same (EQ) LOAD-TIME-VALUE expression or 
>    EQUAL expressions. 
...
>    The prohibition against collapsing of shared or EQUAL LOAD-TIME-VALUE
>    expressions prevents problems that could result by performing destructive
>    side-effects on a value that is referenced in more than one place.

So maybe collapsing needs to be prohibited only when the read-only-p
argument is NIL?

∂19-Sep-88  1736	CL-Compiler-mailer 	Re: issue OPTIMIZE-DEBUG-INFO 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 19 Sep 88  17:36:22 PDT
Received: by ti.com id AA18471; Mon, 19 Sep 88 19:34:08 CDT
Received: from Kelvin by tilde id AA14758; Mon, 19 Sep 88 19:28:48 CDT
Message-Id: <2799707403-5045117@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 19 Sep 88  19:30:03 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Rob.MacLachlan@WB1.CS.CMU.EDU
Cc: CL-Compiler@SAIL.Stanford.EDU
Subject: Re: issue OPTIMIZE-DEBUG-INFO 
In-Reply-To: Msg of Mon, 19 Sep 88 15:02:11 EDT from Rob.MacLachlan@WB1.CS.CMU.EDU

> I am opposed to requiring the system to control debug-info generation in
> any particular way.  Debug-info need not be controlled by the compiler at
> all: it could be conditionally GC'd away at system build time.

An implementation would be free to ignore (OPTIMIZE (DEBUG ...))
declarations if they were not considered relevant to its way of doing
things.  While additional information added for debugging could be
cleaned away by some system utility later, there is also the issue that
if DEBUG is more important than SPEED or SPACE, then you may want to
suppress some optimizations that could confuse the user.

  -- David Gray

∂20-Sep-88  0712	CL-Compiler-mailer 	Issue: COMPILE-ARGUMENT-PROBLEMS   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Sep 88  07:12:25 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA07091; Tue, 20 Sep 88 07:11:05 PDT
Date: Tue, 20 Sep 88 07:11:05 PDT
Message-Id: <8809201411.AA07091@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-compiler@sail.stanford.edu
Subject: Issue: COMPILE-ARGUMENT-PROBLEMS

Well, I'm starting to catch up on yet another mailing list...

VAX LISP also already accepts functions as the second arg to COMPILE.

			---Walter

∂20-Sep-88  0715	CL-Compiler-mailer 	Issue: COMPILE-FILE-PACKAGE   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Sep 88  07:15:20 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA07239; Tue, 20 Sep 88 07:13:59 PDT
Date: Tue, 20 Sep 88 07:13:59 PDT
Message-Id: <8809201413.AA07239@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-compiler@sail.stanford.edu
Subject: Issue: COMPILE-FILE-PACKAGE

You can see I'm addressing the easy issues first...

VAX LISP also already binds *PACKAGE* to itself when doing a COMPILE-FILE.

∂20-Sep-88  0717	CL-Compiler-mailer 	Issue: PROCLAIM-INLINE-WHERE  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Sep 88  07:17:38 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA07321; Tue, 20 Sep 88 07:16:19 PDT
Date: Tue, 20 Sep 88 07:16:19 PDT
Message-Id: <8809201416.AA07321@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-compiler@sail.stanford.edu
Subject: Issue: PROCLAIM-INLINE-WHERE

VAX LISP also already requires INLINE proclamations before definitions.

∂20-Sep-88  0831	CL-Compiler-mailer 	Issue: EVAL-WHEN-NON-TOP-LEVEL
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Sep 88  08:31:01 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA10180; Tue, 20 Sep 88 08:29:38 PDT
Date: Tue, 20 Sep 88 08:29:38 PDT
Message-Id: <8809201529.AA10180@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-compiler@sail.stanford.edu
Subject: Issue: EVAL-WHEN-NON-TOP-LEVEL

I think there's still a serious flaw with EVAL-WHEN-NON-TOP-LEVEL.  I
had sent mail about this before, but I don't think it received enough
consideration.

The problem concerns the order of evaluation of forms that are inside an
(EVAL-WHEN (COMPILE ...) ...) with respect to each other and their effects
on other code to be "processed".

Let's assume DEFMACRO expands into something that includes an EVAL-WHEN
(COMPILE) that tells the compiler that the macro is a macro and what it
should expand into.

  (LET ...
    (DEFMACRO M ...)
    (M ...))

But this code should be exactly equivalent to:

  (LET ...
    (FLET ((REST-OF-BODY () (M ...)))
      (DEFMACRO M ...)
      (REST-OF-BODY)))

Yet the latter code won't have M be treated as a macro in the definition
of REST-OF-BODY.  Since this transformation is fairly fundamental, it seems
to me we can't make the former piece of code allow the DEFMACRO to define
M for use in the rest of the body.

One can make these examples more complicated, of course.  I think the best
solution would be to make the time and ordering of evaluations of forms
inside EVAL-WHEN COMPILE's to be indeterminate, although all must precede
processing of the next top-level form.

			---Walter

∂20-Sep-88  0859	CL-Compiler-mailer 	Re: Issue: EVAL-WHEN-NON-TOP-LEVEL 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Sep 88  08:58:57 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA02055; Tue, 20 Sep 88 09:57:28 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA00332; Tue, 20 Sep 88 09:57:05 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809201557.AA00332@defun.utah.edu>
Date: Tue, 20 Sep 88 09:57:03 MDT
Subject: Re: Issue: EVAL-WHEN-NON-TOP-LEVEL
To: vanroggen%aitg.DEC@decwrl.dec.com
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: vanroggen%aitg.DEC@decwrl.dec.com, Tue, 20 Sep 88 08:29:38 PDT

> Date: Tue, 20 Sep 88 08:29:38 PDT
> From: vanroggen%aitg.DEC@decwrl.dec.com
> 
> I think there's still a serious flaw with EVAL-WHEN-NON-TOP-LEVEL.  I
> had sent mail about this before, but I don't think it received enough
> consideration.
> 
> The problem concerns the order of evaluation of forms that are inside an
> (EVAL-WHEN (COMPILE ...) ...) with respect to each other and their effects
> on other code to be "processed".
> 
> Let's assume DEFMACRO expands into something that includes an EVAL-WHEN
> (COMPILE) that tells the compiler that the macro is a macro and what it
> should expand into.
> 
>   (LET ...
>     (DEFMACRO M ...)
>     (M ...))
> 
> But this code should be exactly equivalent to:
> 
>   (LET ...
>     (FLET ((REST-OF-BODY () (M ...)))
>       (DEFMACRO M ...)
>       (REST-OF-BODY)))
> 
> Yet the latter code won't have M be treated as a macro in the definition
> of REST-OF-BODY.  Since this transformation is fairly fundamental, it seems
> to me we can't make the former piece of code allow the DEFMACRO to define
> M for use in the rest of the body.

I'm not sure what the problem is.  Section (5) of the proposal
explicitly says that you can't depend upon the DEFMACRO being
processed before the reference to the macro it defines, since they
both appear in the same top-level form.  I remember putting this in
when you brought up this issue before.  If I've misunderstood the
problem, can you please be more specific about what you would like to
have changed in the proposal? 

-Sandra
-------

∂20-Sep-88  0931	CL-Compiler-mailer 	Re: Issue: EVAL-WHEN-NON-TOP-LEVEL 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Sep 88  09:31:12 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA14452; Tue, 20 Sep 88 09:29:23 PDT
Date: Tue, 20 Sep 88 09:29:23 PDT
Message-Id: <8809201629.AA14452@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: sandra%defun@cs.utah.edu
Subject: Re: Issue: EVAL-WHEN-NON-TOP-LEVEL

Hmmm.  I only have a copy of the proposal from May/June.  Either I didn't
get a later copy, or I misfiled it.  Could you send it out again, please?

Sorry about that...
			---Walter
PS actually, maybe sending out the latest versions of all of these would
be appropriate, perhaps just to me if not to the mailing list.

∂20-Sep-88  0927	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Sep 88  09:27:30 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA03013; Tue, 20 Sep 88 10:26:06 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA00355; Tue, 20 Sep 88 10:26:01 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809201626.AA00355@defun.utah.edu>
Date: Tue, 20 Sep 88 10:25:59 MDT
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nss.cs.ucl.ac.uk>
Cc: sandra <sandra%defun@cs.utah.edu>, cl-compiler@sail.stanford.edu,
        kmp@scrc-stony-brook.arpa, cl-cleanup@sail.stanford.edu
In-Reply-To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Tue, 20 Sep 88 16:19:42 BST

> Date: Tue, 20 Sep 88 16:19:42 BST
> From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
> 
> I am less hapy with the exception that allows the interpreter to
> multiply evaluate the expression to produce a new value each time.

This argument would bear a lot more weight with me if you could
suggest some implementation technique that guarantees only a single
evaluation in the interpreter that doesn't require the intepreter to
perform a preprocessing code walk, and still provides reasonable
semantics.  I thought about this for a long time and was unable to
come up with any other way to implement the semantics in KMP's
proposal.  I think it is unreasonable to force implementations that
don't use a preprocessor to rewrite their interpreter just to support
this new special form.

> While the exception is consistent with the rules for macros, I
> do not think the two cases are really analogous.  LOAD-TIME-VALUE
> results in an object, so it matters if the object is a different
> one each time.

Macros can construct and return (quoted) objects as well.  I don't
think that allowing multiple evaluations of LOAD-TIME-VALUE is really
all that much more confusing than allowing macros to be expanded more
than once. 

> I suspect it will be a pain to write code that can take advantage
> of the COMPILE-FILE guarantee but nonetheless still work if the
> form is multiply evaluated.

I agree, this is something that is likely to confuse users, but it's the
best I could come up with.  If you can suggest some other compromise 
that will accomodate both destructive operations and those implementations
that don't use a preprocessor in the interpreter, by all means do so.

> > If a LOAD-TIME-VALUE expression appears within a function compiled
> > with COMPILE, the compiler may either evaluate the <form> or use
> > a previously cached value.
> 
> I'm not sure what this means.  Does it mean that different code
> compiled at different times can nonetheless end up using the same
> value?  (I hope not....)

No, what it means is that if you compile an interpreted function that
has already gone through some preprocessing to evaluate a LOAD-TIME-VALUE
expression in the body, the compiler can reuse that value instead of
having to reconstruct the source code and evaluate it again.  The
wording should probably be more specific about this.

-Sandra
-------

∂20-Sep-88  1044	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 20 Sep 88  10:42:19 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa05475; 20 Sep 88 15:44 BST
Date: Tue, 20 Sep 88 16:19:42 BST
Message-Id: <1342.8809201519@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: sandra <@cs.utah.edu:sandra@defun>, cl-compiler@sail.stanford.edu, 
    kmp@scrc-stony-brook.arpa
In-Reply-To: sandra's message of Mon, 19 Sep 88 14:06:15 MDT
Cc: cl-cleanup@sail.stanford.edu

I am more or less in favor of the proposal.  LOAD-TIME-VALUE is
a much better name than LOAD-TIME-CONSTANT if we are going to
allow the value to be a reliably modifiable object.  And I
agree with KMP's arguments that it should be modifiable.

I am less hapy with the exception that allows the interpreter to
multiply evaluate the expression to produce a new value each time.
While the exception is consistent with the rules for macros, I
do not think the two cases are really analogous.  LOAD-TIME-VALUE
results in an object, so it matters if the object is a different
one each time.

> LOAD-TIME-VALUE is, in effect, a promise by the user that multiple
> evaluations of <form> will return values that are semantically 
> equivalent (although not necessary EQ).

What this means, in part, is that the programmer can't mean EQ by
"semantically equivalent" in interpreted code but can in compiled.
I suspect it will be a pain to write code that can take advantage
of the COMPILE-FILE guarantee but nonetheless still work if the
form is multiply evaluated.

> If a LOAD-TIME-VALUE expression is seen by COMPILE-FILE, [...] It
> is guaranteed that the evaluation of <form> will take place only once
> when the file is loaded

To me, the value of this guarantee is much less when it does not
apply when interpreting.

> If a LOAD-TIME-VALUE expression appears within a function compiled
> with COMPILE, the compiler may either evaluate the <form> or use
> a previously cached value.

I'm not sure what this means.  Does it mean that different code
compiled at different times can nonetheless end up using the same
value?  (I hope not....)

-- Jeff

∂20-Sep-88  1321	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 3
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Sep 88  13:21:23 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA10837; Tue, 20 Sep 88 14:19:49 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA00510; Tue, 20 Sep 88 14:19:12 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809202019.AA00510@defun.utah.edu>
Date: Tue, 20 Sep 88 14:19:11 MDT
Subject: Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 3
To: David N Gray <Gray@dsg.csc.ti.com>
Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore),
        cl-compiler@sail.stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Mon, 19 Sep 88  11:49:10 CDT

Since there are a couple of other implementations that treat COMPILER-LET
like PROGN here, I'll go ahead and change the proposal.

I've also noticed another oversight here: the expansion of a macro call
that appears as a top-level form should also be a top-level form.  Does
anybody wish to dispute that?

-Sandra
-------

∂20-Sep-88  1649	CL-Compiler-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Sep 88  16:49:07 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 462806; Tue 20-Sep-88 19:46:13 EDT
Date: Tue, 20 Sep 88 19:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@sail.stanford.edu, kmp@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: <8809192006.AA00963@defun.utah.edu>
Message-ID: <19880920234609.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

I am highly opposed to your whole approach here.  I know KMP doesn't
agree with me, so this is just my personal opinion.  Let me see if I can
explain without getting long-winded.  I've deleted about half of what I
started to say, which was really irrelevant.

You could simply have made the mechanism underlying #, available.
Instead, you chose to design a new mechanism that works a different way.
This requires either having two ways to do load-time evaluation, or
incompatibly changing #, to work the new way.  You chose the latter
course.  This makes #, incompatible both with #. and with its previous
definition.

The new mechanism has all sorts of problems with multiple evaluation
that #, did not have.  The semantics of #, were very clear, if somewhat
off the wall.

The new mechanism tempts you to introduce a new concept of non-read-only
constants, since now you have a place to put options.  This further
complicates the multiple evaluation issue by raising the issue of
side-effects and object sharing.  It also requires a complicated rule
about when the compiler can collapse apparently equal constants.  It's
also harder to implement than you think; any implementation that
formerly treated all constants as read-only now needs a way to label
each constant as read-only or writable.

The rationale claims that replacing #, with LOAD-TIME-VALUE simplifies
the description of Common Lisp, but this is clearly false.  Even a
rigorous description of #, would be much less verbose than this proposal.

So what makes #, simpler than LOAD-TIME-VALUE?  Since #, can only be used
inside quoted constants, we don't need any new rules about how the result
can be used.  Since #, is a feature of LOAD rather than of EVAL, we don't
need any new rules about what happens if you evaluate it twice.  Since
#, is a feature of LOAD rather than of EVAL, there is no issue of
semantic incompatibility between the compiler and the interpreter.

How to make the mechanism underlying #, available?  This would be a
function that receives a form and returns an object (I'd use the term
"magic cookie" if I didn't hate it) which can be placed inside a quoted
constant; by the time the program is loaded, that position in the quoted
constant will contain the result of evaluating the form in the null
lexical environment.  It is only useful to call this function from
macros.  This function needs a way to tell whether a COMPILE-FILE is in
progress or not (as does CLOS); I hope that the compiler committee is
going to propose that the environment argument to macros can be used for
this purpose.  Symbolics Genera currently uses a special variable to
convey this information, which has all the bugs that dynamic scoping
always has.

∂20-Sep-88  1715	CL-Cleanup-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Sep 88  17:14:51 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA04854g; Tue, 20 Sep 88 16:12:30 PST
Received: by blacksox id AA01124g; Tue, 20 Sep 88 17:10:12 pdt
Date: Tue, 20 Sep 88 17:10:12 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809210010.AA01124@blacksox>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu,
        kmp@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 20 Sep 88 19:46 EDT <19880920234609.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM

I agree completely with Moon's criticism of this proposal.  I would
prefer to remove #, and its functionality altogether from the
language.  It just isn't that important.  I have yet to see any use for
#, which could not have been achieved by other means.

∂20-Sep-88  1746	CL-Compiler-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Sep 88  17:46:21 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 462833; Tue 20-Sep-88 20:43:28 EDT
Date: Tue, 20 Sep 88 20:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: eb@lucid.com
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu,
    cl-compiler@sail.stanford.edu, kmp@STONY-BROOK.SCRC.Symbolics.COM,
    cl-cleanup@sail.stanford.edu
In-Reply-To: <8809210010.AA01124@blacksox>
Message-ID: <880920204310.3.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Tue, 20 Sep 88 17:10:12 pdt
    From: Eric Benson <eb@lucid.com>

    ... I would prefer to remove #, and its functionality altogether from
    the language.  It just isn't that important.  I have yet to see any
    use for #, which could not have been achieved by other means.

Sigh. I simply don't believe this claim.  We had this whole discussion
on CL-Compiler because CL-Cleanup yielded up responsibility for it.
There were several people making the same claim as you who are now
sounding swayed by the discussion. If necessary, I will send you and the
others copies of the mail dealing with this topic so you can pick up
where that discussion left off without our needlessly duplicating the
work we've already been through on this.

∂20-Sep-88  1836	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Sep 88  18:36:02 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 20 SEP 88 18:24:46 PDT
Date: Tue, 20 Sep 88 18:24 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: Eric Benson <eb@lucid.com>
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu,
 cl-compiler@sail.stanford.edu, kmp@STONY-BROOK.SCRC.Symbolics.COM,
 cl-cleanup@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <8809210010.AA01124@blacksox>
Message-ID: <19880921012425.2.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no

    Date: Tue, 20 Sep 88 17:10:12 pdt
    From: Eric Benson <eb@lucid.com>

    I agree completely with Moon's criticism of this proposal.  

I also agree with Moon's criticism.  I think a simpler mechanism for
this should be easy to discover.
								
								I would
    prefer to remove #, and its functionality altogether from the
    language.  It just isn't that important.  I have yet to see any use for
    #, which could not have been achieved by other means.

But this last statement just isn't true.  Here is an example:

I want to be able to define a function, and have one of the function's
"quoted constants" be a little table, lets say an array.  I need to
compute the array at load time, using my own special code, because I
need to arrange for some of the functions to share arrays.  Now, if I
was just writing a defun, I could say:

(defun a-little-function (x)
  (aref #,(get-table-for 'a-little-function '(x))
        x))

But, of course #, doesn't work inside of macros.

Before proposing that I use a gensym, and somehow arrange to set
its value to the right thing, consider that portable efficiency
of the resulting code is almost guaranteed to be an issue whenever
anyone wants to do something like this.
-------

∂20-Sep-88  1921	CL-Cleanup-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Sep 88  19:21:25 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA05011g; Tue, 20 Sep 88 18:19:33 PST
Received: by bhopal id AA20490g; Tue, 20 Sep 88 19:19:01 PDT
Date: Tue, 20 Sep 88 19:19:01 PDT
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8809210219.AA20490@bhopal>
To: Gregor.pa@Xerox.COM
Cc: eb@SAIL.Stanford.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM,
        sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu,
        kmp@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: Gregor.pa@Xerox.COM's message of Tue, 20 Sep 88 18:24 PDT <19880921012425.2.GREGOR@PORTNOY.parc.xerox.com>
Subject: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM

								
								I would
    prefer to remove #, and its functionality altogether from the
    language.  It just isn't that important.  I have yet to see any use for
    #, which could not have been achieved by other means.


  Sigh. I simply don't believe this claim.  ...

  But this last statement just isn't true.  Here is an example:

Excuse me for being pedantic, but how can either of you claim to know
what EB has seen?  If *you* have seen such uses, that's interesting,
but doesn't invalidate his observation, which is (I think) intended to
lend support to the argument that such uses are very rare or
non-existant. 

  ... I could say:

  (defun a-little-function (x)
    (aref #,(get-table-for 'a-little-function '(x))
          x))

But would you, or has anyone?  That's the real question.  The last
time I looked, there were exactly two uses of #, in Lucid's product--
both to setup something like *software-version* (I forget the exact
details).  Surely #, is overkill for such uses.

We can provide lots of efficiency hooks that no one will ever use.
I think the burden of proof here is for someone to show some *real*
examples of where #, is a clear win.

  jlm

∂20-Sep-88  1944	CL-Compiler-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Sep 88  19:44:46 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 462890; 20 Sep 88 22:41:36 EDT
Date: Tue, 20 Sep 88 22:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: jlm@lucid.com
cc: Gregor.pa@Xerox.COM, eb@SAIL.Stanford.EDU,
    Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu,
    cl-compiler@sail.stanford.edu, kmp@STONY-BROOK.SCRC.Symbolics.COM,
    cl-cleanup@sail.stanford.edu
In-Reply-To: <8809210219.AA20490@bhopal>
Message-ID: <880920224119.6.KMP@GRYPHON.SCRC.Symbolics.COM>

It doesn't make any sense to talk about the number of uses that a primitive has.
PROGV isn't used that much either -- many users never use it. Yet it's generally
acknowledged to be a good thing just for those few places where it's needed.

The situations Gregor and I are talking about are rare by one metric: lines of
code. Maybe #, will occur only once in a portable implementation of CLOS. (Though
my guess is much higher -- perhaps even 2 or 3 times. :-) But without it, it may
be hard to make such a portable implementation.

I also needed the feature for my Fortran->Lisp translator, 10 years ago in Maclisp.
It allows one to emulate ``linking.'' If I wrote the program again today in
Common Lisp, I couldn't do as well because at least the Maclisp facility provided
for an interface to macros.

Are you going to count the number of lines of code (fewer than 10, probably),
the number of programs that write DEFMETHOD or Fortran SUBROUTINE (probably in
the thousands), or the number of times those programs are called (conservatively
in the hundreds of thousands) when you count the frequency of use?

If #, is not used a lot, it's not because it's some low-level grungy that only a
few people have the poor taste to use. It's because the language designers haven't
gotten their act together enough to give it a portable definition that people can
write about.

Currently, #, is defined in a non-portable way that makes it a low-level grungy
thing, but in fact it is an abstract concept that I think should be fundamental
to everyone's knowledge of programming.

Programming is about decision-making. Some decisions are delayed longer than others.
One key to making decisions at the right time is having access to being able to
name the times at which decisions might be made. It's ludicrous to think that only
at toplevel would there be decisions that need to be postponed until runtime and
that EVAL-WHEN should suffice. It's ludicrous to say that every postponed decision
should need a first-class name. Some decisions in the middle of a program body
need to be postponed without sacrificing anonymity.  #, provides a natural 
mechanism for, at any point in a programming, saying "I won't know what goes here
at compilation time, but the instant I get ahold of the runtime environment I can
tell you the object I'm talking about." There's nothing low-level or shameful about
that.

∂20-Sep-88  1959	CL-Cleanup-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Sep 88  19:59:52 PDT
Received: from rainbow-warrior ([192.9.200.16]) by heavens-gate.lucid.com id AA05065g; Tue, 20 Sep 88 18:57:50 PST
Received: by rainbow-warrior id AA19086g; Tue, 20 Sep 88 19:56:11 PDT
Date: Tue, 20 Sep 88 19:56:11 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8809210256.AA19086@rainbow-warrior>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu,
        kmp@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 20 Sep 88 19:46 EDT <19880920234609.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM

I completely agree with Moon on this topic. We don't need the complication
intoduced by this new proposal.
I also agree that the cleanup committee needs to come up with a proposal for
an environment argument, able to distinguish between compile-file and  core
processing. 

Patrick.

∂20-Sep-88  2004	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Sep 88  20:04:50 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 20 SEP 88 19:42:12 PDT
Date: Tue, 20 Sep 88 19:41 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: Jim McDonald <jlm@lucid.com>
cc: eb@SAIL.Stanford.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM,
 sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu,
 kmp@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <8809210219.AA20490@bhopal>
Message-ID: <19880921024150.5.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no

    Date: Tue, 20 Sep 88 19:19:01 PDT
    From: Jim McDonald <jlm@lucid.com>

    Excuse me for being pedantic, but how can either of you claim to know
    what EB has seen?  If *you* have seen such uses, that's interesting,
    but doesn't invalidate his observation, which is (I think) intended to
    lend support to the argument that such uses are very rare or
    non-existant. 

Actually, I can know that EB has seen this case.  I have talked with him
about it before.

      ... I could say:

      (defun a-little-function (x)
	(aref #,(get-table-for 'a-little-function '(x))
	      x))

    But would you, or has anyone?  That's the real question.  

Yes, I would if only I could.  In writing PCL, the fact that there
isn't a load-time-eval facility in the language has caused me a great
deal of pain.  The little code fragment above is the distillation of
what I have wanted to do in several places.  As an example, one way to
implement permutation vectors is to have the PV cache just be in the
method functions that need them, this requires load time eval facility.
As another example, one way to provide certain kinds of programming
environment hook is to have method functions point back at the method
object they are associated with, load-time-eval can help arrange this.
							      
							      The last
    time I looked, there were exactly two uses of #, in Lucid's product--
    both to setup something like *software-version* (I forget the exact
    details).  Surely #, is overkill for such uses.

I must admit that this datapoint doesn't mean too much too me, since #,
doesn't work in Lucid Lisp.
-------

∂20-Sep-88  2126	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Sep 88  21:26:24 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA20720; Tue, 20 Sep 88 22:24:53 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA00814; Tue, 20 Sep 88 22:24:37 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809210424.AA00814@defun.utah.edu>
Date: Tue, 20 Sep 88 22:24:35 MDT
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
        cl-compiler@sail.stanford.edu, kmp@stony-brook.scrc.symbolics.com,
        cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 20 Sep 88 19:46 EDT

Sigh -- it seems like we've already been through this whole debate
at least a half dozen times on the cl-compiler mailing list, and now
we're back right where we started.

To sum up, we started with four options:

    (1) Get rid of #, entirely.

    (2) Keep #, as currently defined but do not make the hook user-visible.

    (3) Some variant of Moon's original proposal.

    (4) Some variant of Pitman's original proposal.

A number of us (including myself) prefer option (1), but others
indicated that they thought removing #, from the language would be
unacceptable.  The next most popular option was (4), defining a new
special form.  However, Pitman's proposal had some serious problems;
it did not clearly define what would happen in the presence of shared
code, for example.  Even more importantly, nobody has suggested how to
implement the semantics it proposes other than by requiring the
interpreter to do a preprocessing codewalk, which would be a very
major change for some implementations.  Hence my revised proposal to
address those problems.

So now we still have people expressing support for options (1), (3),
and (4); and each of these alternatives has also invoked vehement
disapproval.  There remains alternative (2), which is the compiler
committee's fallback position.  If we are unable to reach some
consensus and compromise about either removing #, or extending its
functionality, at the very least we need to clarify the status quo by
explicitly stating that #, must appear in a QUOTEd expression and that
it isn't really just like #..

-Sandra
-------

∂20-Sep-88  2132	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Sep 88  21:32:09 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA20745; Tue, 20 Sep 88 22:30:43 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA00829; Tue, 20 Sep 88 22:30:40 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809210430.AA00829@defun.utah.edu>
Date: Tue, 20 Sep 88 22:30:38 MDT
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
        cl-compiler@sail.stanford.edu, kmp@stony-brook.scrc.symbolics.com,
        cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 20 Sep 88 19:46 EDT


> Date: Tue, 20 Sep 88 19:46 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
> This function needs a way to tell whether a COMPILE-FILE is in
> progress or not (as does CLOS); I hope that the compiler committee is
> going to propose that the environment argument to macros can be used for
> this purpose.  Symbolics Genera currently uses a special variable to
> convey this information, which has all the bugs that dynamic scoping
> always has.

This is not on our list of pending issues, but feel free to submit a
proposal if you have something specific in mind.  The same goes for
anybody else who has a nit to pick relating to compilation issues,
that we haven't gotten around to yet.  Unfortunately, I'm not a mind
reader.  :-(

-Sandra
-------

∂20-Sep-88  2326	CL-Cleanup-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Sep 88  23:26:26 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA05164g; Tue, 20 Sep 88 22:24:46 PST
Received: by blacksox id AA01147g; Tue, 20 Sep 88 23:22:29 pdt
Date: Tue, 20 Sep 88 23:22:29 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809210622.AA01147@blacksox>
To: cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Gregor.pa@Xerox.COM's message of Tue, 20 Sep 88 19:41 PDT <19880921024150.5.GREGOR@PORTNOY.parc.xerox.com>
Subject: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM

Oh dear.  I guess I should have just said that I support Moon's
criticism and left it at that.  I will support a proposal that
formalizes the current expected behavior of #, and provides functional
access as well (the magic cookie cutter).  I just think we could do
without it.

∂21-Sep-88  0811	CL-Compiler-mailer 	Issue: PROCLAIM-ETC-IN-COMPILE-FILE
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Sep 88  08:11:05 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA13056; Wed, 21 Sep 88 08:09:45 PDT
Date: Wed, 21 Sep 88 08:09:45 PDT
Message-Id: <8809211509.AA13056@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-compiler@sail.stanford.edu
Subject: Issue: PROCLAIM-ETC-IN-COMPILE-FILE

Several comments:

If DEFPACKAGE is adopted, would we want to remove the package related
functions from this list of specially treated top-level forms?

I think if we want to allow implementations the freedom of whether PROCLAIM
affects either the compilation environment or the compiler's run-time
environment, we should allow implementations to affect both as well.

I really don't think PROCLAIM '(OPTIMIZE ...) should be a special case.
It's much simpler to think of PROCLAIM always affecting global information.
Also, how would one cause the PROCLAIM '(OPTIMIZE ...) to be evaluated
at load time?  Is it assumed to be wrapped in an EVAL-WHEN (COMPILE EVAL)
if the argument is (QUOTE (OPTIMIZE ...)) but in an EVAL-WHEN (COMPILE LOAD
EVAL) otherwise?  What if the argument isn't quite of that format?  And
how would a user get the behavior, if the default behavior is to just
affect the compilation environment, to get both that and have it be
executed at load-time?

BTW, for the current practice section, we do evaluate the argument to
PROCLAIM, but we don't call the normal PROCLAIM--instead we record
information differently than would happen with (EVAL-WHEN (COMPILE)
(PROCLAIM ...)).

			---Walter

∂21-Sep-88  0827	CL-Compiler-mailer 	Issues: EVAL-WHEN-NON-TOP-LEVEL, DEFINING-MACROS-NON-TOP-LEVEL   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Sep 88  08:27:15 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA14884; Wed, 21 Sep 88 08:25:53 PDT
Date: Wed, 21 Sep 88 08:25:53 PDT
Message-Id: <8809211525.AA14884@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-compiler@sail.stanford.edu
Subject: Issues: EVAL-WHEN-NON-TOP-LEVEL, DEFINING-MACROS-NON-TOP-LEVEL

Regarding my previous mail about undetermined ordering of EVAL-WHEN
(... COMPILE ...) bodies, I was talking about the issue
EVAL-WHEN-NON-TOP-LEVEL, not just about the special case DEFINING-MACROS-
NON-TOP-LEVEL.  So, although it's good there's point (5) in the latter
proposal, it really belongs in the former proposal.

Point (5) probably should put less emphasis on I/O considerations in
defining what "top-level" means, but I'm not sure how to say it better.
It would be useful to say right there (again) that "top-level" means
a null lexical environment.

BTW, VAX LISP does not treat COMPILER-LET bodies as being at top-level.
It's OK with me if we do add this functionality, though frankly I'd
prefer we deleted COMPILER-LET from the language.  But that's another
issue.

			---Walter

∂21-Sep-88  0834	CL-Compiler-mailer 	Issue: OPTIMIZE-DEBUG-INFO    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Sep 88  08:33:58 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA15715; Wed, 21 Sep 88 08:32:35 PDT
Date: Wed, 21 Sep 88 08:32:35 PDT
Message-Id: <8809211532.AA15715@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-compiler@sail.stanford.edu
Subject: Issue: OPTIMIZE-DEBUG-INFO

I also think having a new DEBUG qualifier is a good idea.

This proposal reminds me of an old and a new issue: the meaning of the
different values for OPTIMIZE qualifiers, and whether all implementations
should have the value 1 as the default for all the qualifiers.

			---Walter

∂21-Sep-88  0950	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 21 Sep 88  09:50:42 PDT
Received: by ti.com id AA02980; Wed, 21 Sep 88 11:48:10 CDT
Received: from Kelvin by tilde id AA27381; Wed, 21 Sep 88 11:35:57 CDT
Message-Id: <2799851831-13818993@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 21 Sep 88  11:37:11 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-compiler@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
In-Reply-To: Msg of Tue, 20 Sep 88 19:46 EDT from "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>

> The new mechanism has all sorts of problems with multiple evaluation
> that #, did not have.  The semantics of #, were very clear, if somewhat
> off the wall.

Since neither the MIT Lisp Machine manual nor CLtL correctly document how
to use #, it would hardly seem that the semantics are "very clear".  The
question of multiple evaluation applies to #, also, it just hasn't ever
been spelled out before.

>  ...  any implementation that
> formerly treated all constants as read-only now needs a way to label
> each constant as read-only or writable.

But #, never could be treated quite the same as other constants, since it
is constructed at load time instead of compile-time.  The Explorer
write-protects ordinary constants, but not when #, is used.

>  ... Since #, is a feature of LOAD rather than of EVAL, we don't
> need any new rules about what happens if you evaluate it twice.  Since
> #, is a feature of LOAD rather than of EVAL, there is no issue of
> semantic incompatibility between the compiler and the interpreter.

#, is a feature of the reader that needs to cause both the loader
and evaluator to do something appropriate with it.  Are you suggesting
that it is only permissible to use #, within an input file to
COMPILE-FILE?

> How to make the mechanism underlying #, available?  This would be a
> function that receives a form and returns an object (I'd use the term
> "magic cookie" if I didn't hate it) which can be placed inside a quoted
> constant; by the time the program is loaded, that position in the quoted
> constant will contain the result of evaluating the form in the null
> lexical environment.  It is only useful to call this function from
> macros.  

Although this approach follows the way we happen to implement #, I don't
care for it because it seems to be institutionalizing an implementation
technique rather than focusing on the functionality to be provided.

I also had a negative initial reaction to the new-special-form proposal,
but my attempts to come up with something simpler only led me appreciate
it.  There is still a valid question though of whether we want

    #,exp  <==>  (LOAD-TIME-VALUE exp T)
or
    '#,exp  <==>  (LOAD-TIME-VALUE exp T)
    '(... #,exp ...)  <==>  (LOAD-TIME-VALUE (LIST ... exp ...) T)

I could go either way on that; the first way (as proposed) is much
simpler, but the second is consistent with current practice.

∂21-Sep-88  1050	CL-Compiler-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Sep 88  10:50:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 463291; Wed 21-Sep-88 13:48:18 EDT
Date: Wed, 21 Sep 88 13:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: David N Gray <Gray@DSG.csc.ti.com>
cc: cl-compiler@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <2799851831-13818993@Kelvin>
Message-ID: <19880921174821.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 21 Sep 88  11:37:11 CDT
    From: David N Gray <Gray@DSG.csc.ti.com>

    > The new mechanism has all sorts of problems with multiple evaluation
    > that #, did not have.  The semantics of #, were very clear, if somewhat
    > off the wall.

    Since neither the MIT Lisp Machine manual nor CLtL correctly document how
    to use #, it would hardly seem that the semantics are "very clear".  The
    question of multiple evaluation applies to #, also, it just hasn't ever
    been spelled out before.

Since the evaluation happens at load time, how can it happen more than
once?  If you load the same file again, you create a new object, you
don't "load the same object again."  It's true that #, has always been
poorly documented, which is how we got into this mess in the first place.

    >  ...  any implementation that
    > formerly treated all constants as read-only now needs a way to label
    > each constant as read-only or writable.

    But #, never could be treated quite the same as other constants, since it
    is constructed at load time instead of compile-time.  

All constants are created at load time.  Think about it; the output file
from COMPILE-FILE doesn't contain objects, it contains instructions to
the loader telling it how to create objects.

    >  ... Since #, is a feature of LOAD rather than of EVAL, we don't
    > need any new rules about what happens if you evaluate it twice.  Since
    > #, is a feature of LOAD rather than of EVAL, there is no issue of
    > semantic incompatibility between the compiler and the interpreter.

    #, is a feature of the reader that needs to cause both the loader
    and evaluator to do something appropriate with it.  Are you suggesting
    that it is only permissible to use #, within an input file to
    COMPILE-FILE?

No, of course not.  I'm saying that #, is a feature of the reader that
needs to cause the loader to do something appropriate with it.  #, never
affects the evaluator, EVAL and COMPILE never see anything different when
#, is used than they would see normally.

    > How to make the mechanism underlying #, available?  This would be a
    > function that receives a form and returns an object (I'd use the term
    > "magic cookie" if I didn't hate it) which can be placed inside a quoted
    > constant; by the time the program is loaded, that position in the quoted
    > constant will contain the result of evaluating the form in the null
    > lexical environment.  It is only useful to call this function from
    > macros.  

    Although this approach follows the way we happen to implement #, I don't
    care for it because it seems to be institutionalizing an implementation
    technique rather than focusing on the functionality to be provided.

That's exactly the opposite of what I thought I was doing, so I guess we're
not communicating very well.

    I also had a negative initial reaction to the new-special-form proposal,
    but my attempts to come up with something simpler only led me appreciate
    it.

I sure can't understand why this issue is so hard.

∂21-Sep-88  1120	CL-Compiler-mailer 	Re: Issue: PROCLAIM-ETC-IN-COMPILE-FILE 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Sep 88  11:20:21 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA04141; Wed, 21 Sep 88 12:19:01 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA01174; Wed, 21 Sep 88 12:18:58 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809211818.AA01174@defun.utah.edu>
Date: Wed, 21 Sep 88 12:18:57 MDT
Subject: Re: Issue: PROCLAIM-ETC-IN-COMPILE-FILE
To: vanroggen%aitg.DEC@decwrl.dec.com
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: vanroggen%aitg.DEC@decwrl.dec.com, Wed, 21 Sep 88 08:09:45 PDT

> Date: Wed, 21 Sep 88 08:09:45 PDT
> From: vanroggen%aitg.DEC@decwrl.dec.com
> 
> If DEFPACKAGE is adopted, would we want to remove the package related
> functions from this list of specially treated top-level forms?

I think we should at least consider doing so.  The main reason why I
do not think we should try to put this issue up for a vote just yet is
so we can see what happens to DEFPACKAGE first, and what the sentiment
is about making an incompatible change to the language.  Assuming
DEFPACKAGE is accepted, do people view it as a replacement for the
magical behavior of the package functions, or just as another way to
do the same thing?

> I really don't think PROCLAIM '(OPTIMIZE ...) should be a special case.
> It's much simpler to think of PROCLAIM always affecting global information.
> Also, how would one cause the PROCLAIM '(OPTIMIZE ...) to be evaluated
> at load time?  Is it assumed to be wrapped in an EVAL-WHEN (COMPILE EVAL)
> if the argument is (QUOTE (OPTIMIZE ...)) but in an EVAL-WHEN (COMPILE LOAD
> EVAL) otherwise?  What if the argument isn't quite of that format?  And
> how would a user get the behavior, if the default behavior is to just
> affect the compilation environment, to get both that and have it be
> executed at load-time?

This is also my biggest complaint about the proposal as it stands.  I'm all
for getting rid of exceptions and special cases.

-Sandra
-------

∂21-Sep-88  1126	CL-Compiler-mailer 	Re: Issues: EVAL-WHEN-NON-TOP-LEVEL, DEFINING-MACROS-NON-TOP-LEVEL    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Sep 88  11:26:43 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA04249; Wed, 21 Sep 88 12:25:19 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA01192; Wed, 21 Sep 88 12:25:16 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809211825.AA01192@defun.utah.edu>
Date: Wed, 21 Sep 88 12:25:15 MDT
Subject: Re: Issues: EVAL-WHEN-NON-TOP-LEVEL, DEFINING-MACROS-NON-TOP-LEVEL
To: vanroggen%aitg.DEC@decwrl.dec.com
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: vanroggen%aitg.DEC@decwrl.dec.com, Wed, 21 Sep 88 08:25:53 PDT

I'm still confused as to exactly what you want to change about the
proposal(s).  EVAL-WHEN-NON-TOP-LEVEL:CLARIFY states that the
compile-time evaluation of the body of an (EVAL-WHEN (COMPILE LOAD)
...) must take place before the normal compiler processing of the
body; would you like this removed and the order left explicitly vague
instead?

-Sandra
-------

∂21-Sep-88  1126	CL-Compiler-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Sep 88  11:25:58 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 463326; Wed 21-Sep-88 14:23:26 EDT
Date: Wed, 21 Sep 88 14:23 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: Gray@DSG.csc.ti.com, CL-Compiler@SAIL.Stanford.EDU,
    CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19880921174821.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880921142327.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Wed, 21 Sep 88 13:48 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    
    ... All constants are created at load time.  Think about it; the output
    file from COMPILE-FILE doesn't contain objects, it contains instructions
    to the loader telling it how to create objects. ...

Not just how to create objects -- also to -find- objects. This is at the root
of my concern about whether #,(form) returns a modifiable object.

If you just write '(2 3 4) the compiler must figure out how to do the
construction from your declarative reference to the conjured structure.
It can't tell if you wrote:  '#.(LOOP FOR X FROM 2 TO 4 COLLECT X) or
'#.(CDR FOUR-THINGS) or '(2 3 4) so it just does the best it can based
on the final result.

On the other hand, the #, facility provides you with a way to advise the
compiler about the actual code to be used in procuring the object. The
compiler can tell if sharing, modifiability, circularity, etc. is 
important to you because it can blindly follow the instructions which you
have carefully written to express your exact requirements.

#, is not about constants. It is simply about delayed decision-making. 
If I delay a decision until runtime, I don't have to return an immutable
object from a function. Why should I have to return an immutable object
if I can make the decision a little earlier (at load time)?

Indeed, the only reason that decisions made in the compiler can be construed
to be constants is exactly this unfortunate artifact of file compilation
which you address. If the compiler shared a huge address space with all
Lisps for all time, it could output pointers to actual objects and then
decisions about mutable objects could be made in the compiler. We accept
the file-model of a compiler as a limitation of existing systems and allow
anything done on the `compiler side' to be subject of funny restrictions
needed to allow you to represent your program to a file and have it 
reconstructed, but since #, is not done on the compiler side, it should not
be subject to these restrictions.

    I sure can't understand why this issue is so hard.

Me either. It seems crystal clear to me. :-)

∂21-Sep-88  1126	CL-Compiler-mailer 	Issue: COMPILE-FILE-ENVIRONMENT (Version 1)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Sep 88  11:26:34 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 463328; Wed 21-Sep-88 14:23:47 EDT
Date: Wed, 21 Sep 88 14:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMPILE-FILE-ENVIRONMENT (Version 1)
To: cl-cleanup@sail.stanford.edu
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Gregor.pa@Xerox.com, cl-compiler@sail.stanford.edu
In-Reply-To: <8809210430.AA00829@defun.utah.edu>
Message-ID: <19880921182349.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: Tue, 20 Sep 88 22:30:38 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    > Date: Tue, 20 Sep 88 19:46 EDT
    > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    > 
    > This function needs a way to tell whether a COMPILE-FILE is in
    > progress or not (as does CLOS); I hope that the compiler committee is
    > going to propose that the environment argument to macros can be used for
    > this purpose.

    This is not on our list of pending issues, but feel free to submit a
    proposal if you have something specific in mind.

Further examination shows that no proposal is necessary!  X3J13 has already
voted to adopt 88-002R into the language, and pages 2-47 and 2-48 of 88-002R
already specify that this exists.  However to avoid accusations of sneaking
things into the language behind the committee's back, I'll submit a clarification.


Issue:         COMPILE-FILE-ENVIRONMENT

References:    88-002R pages 2-47 and 2-48

Category:      CLARIFICATION

Edit history:  Version 1, 21-Sep-1988, Moon

Problem description:

It may not be clear to everyone that as of the adoption of 88-002R in June,
there is an additional requirement on the semantics of the environment
argument to macro expander functions.

Proposal (COMPILE-FILE-ENVIRONMENT:CLARIFY):
	  
Clarify that when COMPILE-FILE expands a macro invoked from the code
being compiled, the environment argument to the expander function
contains information that indicates that the macro expansion will be
used in the run-time environment, not in the compile-time environment.
This information is used by the FIND-CLASS and ENSURE-GENERIC-FUNCTION
functions, for example.

Clarify that when interpreted code is executed during COMPILE-FILE (this
might be the body of a macro expansion function, or might be the body of
an EVAL-WHEN COMPILE, or might be an interpreted function called from
one of those places), and a macro invocation in that interpreted code is
expanded, the environment argument to the expander function contains
information that indicates that the macro expansion will be used in the
compile-time environment, not in the run-time environment.

Terminology: The compile-time environment is the Lisp in which the
function COMPILE-FILE was called.  The run-time environment is the
Lisp(s) in which the LOAD function will be called to load the file
output by COMPILE-FILE.

Test Cases/Examples:

A test case cannot be written without using CLOS meta objects or other
extensions to Common Lisp.  Here is an example:

(defmacro defclass (name ... &environment e)
  `(setf (find-class ',name ',e) ...))

Rationale:

CLOS requires this.

Current practice:

Something resembling this already exists in almost all Common Lisp
implementations for internal use by the compiler.  Symbolics Genera
currently uses a special variable instead of the macro expansion
environment, which of course is wrong and produces incorrect
behavior in some cases.  I don't know about other implementations.

Cost to Implementors:

The cost of including the information in the environment argument to an
expander function is probably trivial, unless the representation of
macro expansion environments is completely non-extensible.  The main
cost is making sure that the information is propagated from
COMPILE-FILE, through the compiler, to all places where the compiler
calls MACROEXPAND or MACROEXPAND-1.

Cost to Users:

None.

Cost of non-adoption:

The proposal was already adopted in June, this is just a clarification
of what it entails.

Benefits:

This clarification should save a few implementors some false steps.

Esthetics:

Common Lisp's existing concept of environment seems like the right
mechanism to say things about environments.

Discussion:

The CLOS meta-object facility is probably going to need an addition to
the language, to make SYMBOL-FUNCTION support the environment argument
in the same way that FIND-CLASS and ENSURE-GENERIC-FUNCTION do.  However,
since I'm not sure if that's needed, and since that would be an addition
rather than a clarification, I'll ignore it for the moment.  Similarly,
it would be a useful to have a predicate that can be applied to a macro
expansion environment and tells you whether it refers to the run-time
environment or the compile-time environment.  I'm not proposing that now.

The terms "run-time" and "compile-time" are somewhat confusing.  Perhaps
better terms, such as the "deferred environment" and the "immediate
environment" or the "future environment" and the "present environemnt"
could be adopted.  In this proposal I have used the terms that became
official when X3J13 voted for 88-002R.

∂21-Sep-88  1153	CL-Cleanup-mailer 	Issue: LOAD-TIME-EVAL (Version 6)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Sep 88  11:53:28 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 463370; Wed 21-Sep-88 14:50:44 EDT
Date: Wed, 21 Sep 88 14:50 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 6)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Gregor.pa@Xerox.COM,
    Patrick Dussud <dussud@lucid.com>, Sandra J Loosemore <sandra%defun@cs.utah.edu>,
    Eric Benson <eb@lucid.com>
cc: CL-Cleanup@SAIL.STANFORD.EDU, cl-compiler@sail.stanford.edu
In-Reply-To: <880608165454.0.KMP@PEWEE.SCRC.Symbolics.COM>,
             <19880921012425.2.GREGOR@PORTNOY.parc.xerox.com>,
             <8809210256.AA19086@rainbow-warrior>,
             <8809210424.AA00814@defun.utah.edu>,
             <8809210622.AA01147@blacksox>
Message-ID: <19880921185047.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

For the purposes of discussion, here's a copy of KMP's last writeup
stripped down to just what I personally think are the essentials.
I don't mean to supersede Kent's writeup, just to give people
something short enough to read.  Kent's writeup also included
the new-special-form version and compared and constrasted the
two versions.

Issue:          LOAD-TIME-EVAL
References:     #, (p. 356),  (EVAL-WHEN (LOAD) ...) (p. 69-70)
Category:       ADDITION
Edit history:   06-Jun-87, Version 1 by James Kempf
                17-Jul-87, Version 2 by James Kempf
                12-Nov-87, Version 3 by Pitman (alternate direction)
                01-Feb-88, Version 4 by Moon
                  (from version 2 w/ edits suggested by Masinter)
                06-Jun-88, Version 5 by Pitman
                  (fairly major overhaul, merging versions 3 and 4)
                21-Sep-88, Version 6 by Moon (stripped down)
Status:         For internal discussion

Problem description:

 Common Lisp provides reader syntax (#,) which allows the programmer
 to designate that a particular expression within a program is to be
 evaluated early (at load time) but to later be treated as a constant.
 Unfortunately, no access to this capability is available to programs
 which construct other programs without going through the reader.
    
 Some computations can be deferred until load time by use of EVAL-WHEN,
 but since EVAL-WHEN must occur only at toplevel, and since the nesting
 behavior of EVAL-WHEN is quite unintuitive, EVAL-WHEN is not a general
 solution to the problem of load-time computation of program constants.

 Also, CLtL is vague about the meaning of #,exp as a form (rather than
 inside a quoted constant).

Proposal (LOAD-TIME-EVAL:QUOTED-MAGIC-TOKEN):

 Add a function MAKE-LOAD-TIME-CONSTANT, as described here:

 MAKE-LOAD-TIME-CONSTANT form env                       [Function]

   FORM is a Lisp form. ENV is an environment of the sort received
   by the &ENVIRONMENT argument to a macro.

   When MAKE-LOAD-TIME-CONSTANT is called from the interpreter or the
   COMPILE function, it simply evaluates FORM in the null lexical
   environment and returns its value.  When MAKE-LOAD-TIME-CONSTANT is
   called during a file compilation, the result is a special object
   that is recognized at load time, when it occurs inside a constant.
   At load time, FORM is evaluated and its value is substituted for
   the object.

   MAKE-LOAD-TIME-CONSTANT uses its ENV argument to determine whether it
   is being called during a file compilation.

 Specify that '(... #,exp ...) is equivalent to
 '(... #.(MAKE-LOAD-TIME-CONSTANT 'exp env) ...)
 with the "right" value of env.

 Specify that anything Common Lisp says about destructive operations
 on constants also applies to values returned by forms used as
 arguments to MAKE-LOAD-TIME-CONSTANT.

 Clarify that #,exp as a form is an error and that load-time constants
 can only be used inside the QUOTE special form.

Rationale:

   This approach is the most compatible with existing practice.

Cost to Implementors:

   The cost to implementors will depend on how #, is implemented.
   In some implementations, the primitives for implementing 
   MAKE-LOAD-TIME-CONSTANT may already exist, in others, more substantial
   changes may be required.

Cost to Users:

   This change is upward compatible with user code.

Benefits:

   It would be possible for macros to expand into load time constants.

Example: 

;; This is a stripped down version of something from CLOS
(defmacro deffoo (name attribute &environment e)
  `(defun ,name (x)
     (aref x (aref ',(make-load-time-constant
		       `(get-table-for ',attribute)
		       e)
		   ',(get-index-for ',attribute)))))

Current practice:

 Although most implementations provide a substrate which would allow
 program-mediated access to load time evaluation in some way, the language
 only defines access to this substrate through the sharpsign read syntax.

∂21-Sep-88  1300	CL-Cleanup-mailer 	Issue: LOAD-TIME-EVAL (Version 6)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Sep 88  13:00:38 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 463431; Wed 21-Sep-88 15:58:16 EDT
Date: Wed, 21 Sep 88 15:58 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 6)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Gregor.pa@Xerox.COM,
    dussud@lucid.com, sandra%defun@cs.utah.edu, eb@lucid.com,
    CL-Cleanup@SAIL.STANFORD.EDU, cl-compiler@sail.stanford.edu
In-Reply-To: <19880921185047.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880921155806.5.KMP@GRYPHON.SCRC.Symbolics.COM>

Well, let me say up front that this description is absolutely unacceptable
to me because of the verbiage about destructive modification.

Also, I am concerned about how the "right thing" can be done with the
env argument in the case of

 (EVAL-WHEN (EVAL COMPILE LOAD)
   (DEFUN FOO (X) '(X #,(SQRT 3))))

In a file compiler, the #, must read in a way that is acceptable to the
compiler's runtime environment (compile to core) and the compiler's file
environment (compile to file). And this decision must be made at
readtime.

If instead you wrote:

 (EVAL-WHEN (EVAL COMPILE LOAD)
   (DEFUN FOO (X) #,`(X ,(SQRT 3))))

and #, expanded into a LOAD-TIME-VALUE expression, then the compile to
core operation could treat the LOAD-TIME-VALUE special form in one way
and the file compiler could treat the LOAD-TIME-VALUE special form
another way and things would work nicely as a natural result of the
accessibility of the lexical environment from the special form.

∂21-Sep-88  1321	CL-Compiler-mailer 	Issue: LOAD-TIME-EVAL (Version 6)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Sep 88  13:21:33 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA05781g; Wed, 21 Sep 88 12:18:41 PST
Received: by blacksox id AA01201g; Wed, 21 Sep 88 13:16:24 pdt
Date: Wed, 21 Sep 88 13:16:24 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809212016.AA01201@blacksox>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM,
        Gregor.pa@Xerox.COM, dussud@STONY-BROOK.SCRC.Symbolics.COM,
        sandra%defun@cs.utah.edu, CL-Cleanup@SAIL.STANFORD.EDU,
        cl-compiler@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Wed, 21 Sep 88 15:58 EDT <880921155806.5.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 6)

   Date: Wed, 21 Sep 88 15:58 EDT
   From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

   Also, I am concerned about how the "right thing" can be done with the
   env argument in the case of

    (EVAL-WHEN (EVAL COMPILE LOAD)
      (DEFUN FOO (X) '(X #,(SQRT 3))))

   In a file compiler, the #, must read in a way that is acceptable to the
   compiler's runtime environment (compile to core) and the compiler's file
   environment (compile to file). And this decision must be made at
   readtime.

   If instead you wrote:

    (EVAL-WHEN (EVAL COMPILE LOAD)
      (DEFUN FOO (X) #,`(X ,(SQRT 3))))

   and #, expanded into a LOAD-TIME-VALUE expression, then the compile to
   core operation could treat the LOAD-TIME-VALUE special form in one way
   and the file compiler could treat the LOAD-TIME-VALUE special form
   another way and things would work nicely as a natural result of the
   accessibility of the lexical environment from the special form.

This should work:

 (EVAL-WHEN (EVAL COMPILE LOAD)
   (DEFMACRO LIST-FOR-FOO (&ENVIRONMENT ENV)
     `(X ,(MAKE-LOAD-TIME-CONSTANT '(SQRT 3) ENV)))
   (DEFUN FOO (X) (LIST-FOR-FOO)))

∂21-Sep-88  1340	CL-Compiler-mailer 	Issue: LOAD-TIME-EVAL (Version 6)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Sep 88  13:40:08 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA05821g; Wed, 21 Sep 88 12:37:17 PST
Received: by blacksox id AA01222g; Wed, 21 Sep 88 13:34:57 pdt
Date: Wed, 21 Sep 88 13:34:57 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809212034.AA01222@blacksox>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM,
        Gregor.pa@Xerox.COM, dussud@STONY-BROOK.SCRC.Symbolics.COM,
        sandra%defun@cs.utah.edu, CL-Cleanup@SAIL.STANFORD.EDU,
        cl-compiler@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Wed, 21 Sep 88 16:25 EDT <880921162559.7.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 6)

By the way, I forgot a ' in that example.  Here's the fixed version:

 (EVAL-WHEN (EVAL COMPILE LOAD)
   (DEFMACRO LIST-FOR-FOO (&ENVIRONMENT ENV)
     `'(X ,(MAKE-LOAD-TIME-CONSTANT '(SQRT 3) ENV)))
   (DEFUN FOO (X) (LIST-FOR-FOO)))

∂21-Sep-88  1329	CL-Cleanup-mailer 	Issue: LOAD-TIME-EVAL (Version 6)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Sep 88  13:28:54 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 463467; 21 Sep 88 16:26:11 EDT
Date: Wed, 21 Sep 88 16:25 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 6)
To: eb@lucid.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM,
    Moon@STONY-BROOK.SCRC.Symbolics.COM, Gregor.pa@Xerox.COM,
    dussud@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu,
    CL-Cleanup@SAIL.STANFORD.EDU, cl-compiler@sail.stanford.edu
In-Reply-To: <8809212016.AA01201@blacksox>
Message-ID: <880921162559.7.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Wed, 21 Sep 88 13:16:24 pdt
    From: Eric Benson <eb@lucid.com>

       Date: Wed, 21 Sep 88 15:58 EDT
       From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

       Also, I am concerned about how the "right thing" can be done with the
       env argument in the case of

	(EVAL-WHEN (EVAL COMPILE LOAD)
	  (DEFUN FOO (X) '(X #,(SQRT 3))))

    ... This should work:

     (EVAL-WHEN (EVAL COMPILE LOAD)
       (DEFMACRO LIST-FOR-FOO (&ENVIRONMENT ENV)
	 `(X ,(MAKE-LOAD-TIME-CONSTANT '(SQRT 3) ENV)))
       (DEFUN FOO (X) (LIST-FOR-FOO)))

I'm not concerned that there is no way to get the right thing, I'm
concerned that the DWIM alluded to in Moon's stripped down proposal
is not possible to really guarantee. I'm concerned that if #, is
described as just "doing the right thing"  environment-wise, then
it will lose randomly because that can't always be satisfied. Then
people will think of it as something yucky to be avoided rather than
something clean and graceful. [Btw, this is a case that was only
recently shown to me -- not something I knew when I wrote the 
predecessor to his proposal.]

If instead LOAD-TIME-VALUE were a special form and #, could expand
into it (outside of QUOTE), there would be no such yuckiness for 
people to get burnt by, so #, would not have to become something
that people avoided out of paranoia because they didn't understand it.

∂21-Sep-88  1408	CL-Compiler-mailer 	Re: Issue: LOAD-TIME-EVAL (Version 6)   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Sep 88  14:08:10 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA08853; Wed, 21 Sep 88 15:05:39 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA01411; Wed, 21 Sep 88 15:05:29 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809212105.AA01411@defun.utah.edu>
Date: Wed, 21 Sep 88 15:05:28 MDT
Subject: Re: Issue: LOAD-TIME-EVAL (Version 6)
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>, Gregor.pa@xerox.com,
        Patrick Dussud <dussud@lucid.com>,
        Sandra J Loosemore <sandra%defun@cs.utah.edu>,
        Eric Benson <eb@lucid.com>, CL-Cleanup@sail.stanford.edu,
        cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 21 Sep 88 14:50 EDT

I have two problems with this proposal.  The first is a big one: there
a more situations in which code is processed than simply
interpretation and compilation.  It is not an either/or situation.  A
person here at the UofU, for example, has been working on a portable
type inference preprocessor.  It reads in code, decorates it with lots
of type declarations, and writes it out to another file which may then
either be loaded interpretively or compiled with COMPILE-FILE.  Under
this proposal, such a tool would essentially have to redefine
MAKE-LOAD-TIME-CONSTANT (a no-no) to always force evaluation to be
delayed, i.e.

    (defun make-load-time-constant (form env)
        `(make-load-time-constant ',form ',env))

That's why I believe that providing this functionality by defining it
as a special form is a superior alternative.

The other quibble is with the environment argument.  As I've already
pointed out to Moon, the environment object returned by &ENVIRONMENT,
as currently defined, may return an incomplete environment that
contains information only about MACROLET constructs in the surrounding
lexical environment.  I gather that this proposal depends on
&ENVIRONMENT being redefined to include information about whether or
not compilation is in progress, and that would be the only part of the
environment object that is used by MAKE-LOAD-TIME-CONSTANT, right?  (I
also understand that CLOS depends on maintaining some other
information in environment objects so I think a proposal to clarify
what they must really contain is in order.)

All things considered, I could live with this proposal, since it would
certainly not be any worse than the status quo.  On the other hand, I
would definitely prefer to either remove #, entirely or provide the
functionality as a special form.

-Sandra
-------

∂21-Sep-88  1436	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 21 Sep 88  14:36:31 PDT
Received: by ti.com id AA04913; Wed, 21 Sep 88 16:33:40 CDT
Received: from Kelvin by tilde id AA03344; Wed, 21 Sep 88 16:17:59 CDT
Message-Id: <2799868740-14879380@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 21 Sep 88  16:19:00 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
In-Reply-To: Msg of Wed, 21 Sep 88 13:48 EDT from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

> No, of course not.  I'm saying that #, is a feature of the reader that
> needs to cause the loader to do something appropriate with it.  #, never
> affects the evaluator, EVAL and COMPILE never see anything different when
> #, is used than they would see normally.

I was forgetting that in the old scenario, in evaluated code, the
expression following #, is executed by the reader instead of the
evaluator.  I guess the basic issue is:  if you generate one of these
load-time values in a macro expansion within the evaluator, should
the expression get evaluated as part of the macro expansion, or should
it be done directly by the evaluator?  Certainly tying the evaluation to
the macro expansion simplifies things greatly since the question of how
many times it gets evaluated is the same as the question of how many
times the macro gets expanded.  Maybe we could get the best of both
proposals by saying that LOAD-TIME-VALUE is a macro instead of a special
form, and it is defined something like this:

(DEFMACRO LOAD-TIME-VALUE (EXP)
  (IF (compiling-p)
      `(some-special-thing-only-the-compiler-cares-about ',EXP)
    `(QUOTE ,(EVAL EXP))))

As for the assumption that a QUOTE form containing a "magic cookie" passes
through the compiler just like any other QUOTE form, that unfortunately is
not quite true.  In our implementation the compiler actually has to scan
QUOTE forms looking to see if it contains a "magic cookie" for two
reasons:  to suppress optimizations based on the value of the constant,
and to prevent merging EQUAL forms that use load-time evaluation.  That's
why I think this approach is ugly -- it uses the syntax of a constant for
something that isn't really a constant.

∂21-Sep-88  1525	CL-Compiler-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Sep 88  15:25:01 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 463583; Wed 21-Sep-88 18:22:36 EDT
Date: Wed, 21 Sep 88 18:22 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: Gray@DSG.csc.ti.com
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Compiler@SAIL.STANFORD.EDU,
    CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <2799868740-14879380@Kelvin>
Message-ID: <880921182223.8.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Wed, 21 Sep 88  16:19:00 CDT
    From: David N Gray <Gray@DSG.csc.ti.com>
    ...
    (DEFMACRO LOAD-TIME-VALUE (EXP)
      (IF (compiling-p)
	  `(some-special-thing-only-the-compiler-cares-about ',EXP)
	`(QUOTE ,(EVAL EXP))))
    ...

This still makes the programmer's intent opaque to code analysis tools.
I insist that there is nothing odd about a LOAD-TIME-VALUE expression
and that code walkers should be able to expect it and do reasonable
things with it.

For example, I once got a warning from a compiler about something like:
 (* (THE FLOAT '#,(SQRT PI)) ...)
because '(#:MAGIC-MARKER SQRT PI) was a quoted value (and hence subject
to compiler scrutiny) and the constant was not a FLOAT. This was obviously
just a bug because the compiler should expect whatever magic it uses
internally to make #, work, but it can happen to users, too.
If the special thing that only the compiler knows about is going to be
the result of
 (MACROEXPAND '(LOAD-TIME-VALUE (SQRT PI))
then I cannot trivially write code-analysis tools which will be able to
call MACROEXPAND and say of the result: "Oh, this is a value that will
not be known until runtime. I can (a) defer further analysis to runtime,
or (b) try to infer things about what the result of a SQRT call might
be, or ... (*) give up knowing I did the best I could."
Instead it will say ``Gosh, here is a special form I never heard of''
or ``Gosh, here's an undefined function I should warn the user about''
or whatever.

There is no reason for every implementation to use a gratuitously
different marker, or a gratuitously different convention about whether
it's (marker . form) or (marker form). We might as well document that
LIST is how it's composed and we might as well make a standard variable
that holds the marker because it can only improve portability to do so
and because there is no runtime overhead in not doing so. But then we'd
be doing
 (EQ (CAR FORM) COMPILER:*SHARP-COMMA-MARKER*)
rather than
 (EQ (CAR FORM) 'LOAD-TIME-VALUE)
and I don't see the point. It's not like either of them is genuinely
inaccessible so it could still get into places you didn't want it.
Better to just define the marker (an interned symbol comes to mind),
define places where it makes sense (the car of a form in a
for-evaluation position comes to mind) -- in effect, to define it to
be the special form that it obviously is. We keep using the word "magic"
-- all other magic in the language is accomplished by special forms.
Let's just be uniform and call this a special form, too.

∂22-Sep-88  0935	CL-Compiler-mailer 	Issue ALLOW-LOCAL-INLINE 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 22 Sep 88  09:35:33 PDT
Received: by ti.com id AA11543; Thu, 22 Sep 88 11:33:38 CDT
Received: from Kelvin by tilde id AA17942; Thu, 22 Sep 88 11:19:05 CDT
Message-Id: <2799937206-2477835@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 22 Sep 88  11:20:06 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Compiler@SAIL.Stanford.edu
Subject: Issue ALLOW-LOCAL-INLINE

 
Issue:		ALLOW-LOCAL-INLINE
References:	CLtL p. 156, 159;
		Issue PROCLAIM-INLINE-WHERE
Category:	ADDITION
Edit History:   22 Sept. 88, V1 by David Gray
Status:		For preliminary discussion 
 
Problem Description:

  The proposal PROCLAIM-INLINE-WHERE:BEFORE clarifies the use of
  INLINE proclamations, but there remains a similar problem with the use
  of a local (DECLARE (INLINE ...)):  how can the compiler expand the
  function inline if it didn't know that the necessary information should
  have been saved when the function was compiled?
 
Proposal ALLOW-LOCAL-INLINE:PROCLAIM-ALLOW-INLINE
 
  Add a new declaration, ALLOW-INLINE, which can only be used in a
  PROCLAIM.  (PROCLAIM '(ALLOW-INLINE {function-name}+)) means that when
  the compiler compiles a subsequent definition of a function whose name
  is listed here, it should record whatever information it would need in
  order to obey a local (DECLARE (INLINE ...)) for that function.
  (An implementation that ignores INLINE declarations can also ignore
  ALLOW-INLINE proclamations.)  A NOTINLINE proclamation cancels the
  effect of an ALLOW-INLINE proclamation.

  If there is a local INLINE declaration for a function which was compiled
  without either an INLINE or ALLOW-INLINE proclamation in effect, then it
  is implementation-dependent whether inline expansion is actually done.

 Rationale:

  Local INLINE declarations are of little use without this capability.
  A compiler could just save the definitions of all functions if memory
  space wasn't a problem, but it usually is.  Or, a compiler could use
  some heuristic to save the definitions of functions that are short
  enough to look like good candidates for inline expansion, but then the
  user is never sure what to expect.

 Test Cases/Examples: 

  Given the following input to COMPILE-FILE, does F1 get expanded inline
  in F2?

    (defun f1 (a) (+ a 100))
    (defun f2 (b) (declare (inline f1)) (f1 b))
 
 Current Practice:
 
  There is no known implementation of this proposal.  The Explorer has an
  undocumented proclamation used internally that is similar to this, and
  remembers trivially short functions when SPEED is greater than SAFETY.

  In the example above, inline expansion is not done on Explorer,
  Symbolics, or Lucid, although they all do support inline expansion
  when proclaimed globally.

 Cost to implementors:
 
  Trivial.

 Cost to users:
  
  None.

 Benefits:

  Users will be able to use (DECLARE (INLINE ...)) and have more
  confidence that it will really do something.

 Costs of Non-Adoption: 

  Inability to reliably request inline expansion on a local basis.

 Discussion:

  The name ALLOW-INLINE was suggested by Rob MacLachlan back on March 2,
  1987.

  It could be said that since implementations are free to ignore INLINE
  declarations, it is unimportant whether a particular inline
  declaration really has any effect.  However if a user added the inline
  declaration because he is trying to speed up some time-critical code,
  and he knows that his compiler supports inline expansion, he would
  like to be able to know that it really is going to happen when he
  wants it to.  There may be other reasons why the compiler decides that
  inline expansion is not appropriate in a particular case, but this
  proposal would eliminate the biggest uncertainty factor.

∂22-Sep-88  0946	CL-Compiler-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Sep 88  09:45:51 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 463987; Thu 22-Sep-88 12:41:59 EDT
Date: Thu, 22 Sep 88 12:42 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Eric Benson <eb@lucid.com>,
    Sandra J Loosemore <sandra%defun@cs.utah.edu>, David N Gray <Gray@DSG.csc.ti.com>
cc: Gregor.pa@Xerox.COM, Patrick Dussud <dussud@lucid.com>, CL-Compiler@SAIL.Stanford.EDU,
    CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <880921142327.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
             <19880921185047.9.MOON@EUPHRATES.SCRC.Symbolics.COM>,
             <880921155806.5.KMP@GRYPHON.SCRC.Symbolics.COM>,
             <8809212016.AA01201@blacksox>,
             <880921162559.7.KMP@GRYPHON.SCRC.Symbolics.COM>,
             <8809212034.AA01222@blacksox>,
             <8809212105.AA01411@defun.utah.edu>,
             <2799868740-14879380@Kelvin>,
             <880921182223.8.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19880922164200.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

I will have nothing further to say on this issue.

∂22-Sep-88  0941	CL-Cleanup-mailer 	Issue: LOAD-TIME-EVAL (Version 6)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Sep 88  09:41:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 463981; Thu 22-Sep-88 12:37:15 EDT
Date: Thu, 22 Sep 88 12:37 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 6)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Gregor.pa@Xerox.COM, dussud@lucid.com, sandra%defun@cs.utah.edu, eb@lucid.com,
    CL-Cleanup@SAIL.STANFORD.EDU, cl-compiler@sail.stanford.edu
In-Reply-To: <880921155806.5.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19880922163716.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: Wed, 21 Sep 88 15:58 EDT
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

    Well, let me say up front that this description is absolutely unacceptable
    to me because of the verbiage about destructive modification.

    Also, I am concerned about how the "right thing" can be done with the
    env argument in the case of

     (EVAL-WHEN (EVAL COMPILE LOAD)
       (DEFUN FOO (X) '(X #,(SQRT 3))))

    In a file compiler, the #, must read in a way that is acceptable to the
    compiler's runtime environment (compile to core) and the compiler's file
    environment (compile to file). And this decision must be made at
    readtime.

Of course this doesn't work and has never worked.

    If instead you wrote:

     (EVAL-WHEN (EVAL COMPILE LOAD)
       (DEFUN FOO (X) #,`(X ,(SQRT 3))))

    and #, expanded into a LOAD-TIME-VALUE expression, then the compile to
    core operation could treat the LOAD-TIME-VALUE special form in one way
    and the file compiler could treat the LOAD-TIME-VALUE special form
    another way and things would work nicely as a natural result of the
    accessibility of the lexical environment from the special form.

You should be more explicit that what you are actually arguing for is
the removal of #, from the language.  You're also proposing to add a
new feature with very complicated but useful semantics, LOAD-TIME-VALUE,
to the language.  Pretending that you're fixing #, only obscures the issues.

∂23-Sep-88  0850	CL-Compiler-mailer 	Re: Issue ALLOW-LOCAL-INLINE  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88  08:50:17 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA24414; Fri, 23 Sep 88 09:48:21 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA02359; Fri, 23 Sep 88 09:47:49 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231547.AA02359@defun.utah.edu>
Date: Fri, 23 Sep 88 09:47:47 MDT
Subject: Re: Issue ALLOW-LOCAL-INLINE
To: David N Gray <Gray@dsg.csc.ti.com>
Cc: CL-Compiler@sail.stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Thu, 22 Sep 88  11:20:06 CDT

I'm not sure we really need this proposal; after all, issue
PROCLAIM-INLINE-WHERE addresses the same problem and is a
clarification to the language rather than an addition.  Since
PROCLAIM-INLINE-WHERE is on the list of issues to be voted on,
I'm going to put ALLOW-LOCAL-INLINE "on hold" until after the
coming meeting.

-Sandra
-------

∂23-Sep-88  0901	CL-Compiler-mailer 	Re: Issue: COMPILE-FILE-ENVIRONMENT (Version 1)   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88  09:01:08 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA24818; Fri, 23 Sep 88 09:59:42 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA02377; Fri, 23 Sep 88 09:59:14 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231559.AA02377@defun.utah.edu>
Date: Fri, 23 Sep 88 09:59:12 MDT
Subject: Re: Issue: COMPILE-FILE-ENVIRONMENT (Version 1)
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: cl-cleanup@sail.stanford.edu,
        Sandra J Loosemore <sandra%defun@cs.utah.edu>, Gregor.pa@xerox.com,
        cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 21 Sep 88 14:23 EDT

I'd like to put this issue on hold for the time being.  Since it
appears that CLOS depends on storing some other information in
environment objects besides the information about MACROLETs in the
surrounding lexical environment (the only thing that CLtL requires), I
think a more general proposal to clarify what goes in environment
objects is in order.  And, I don't think that really falls into the
domain of the compiler committee.

-Sandra
-------

∂23-Sep-88  0905	CL-Compiler-mailer 	re:  COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 23 Sep 88  09:05:24 PDT
Received: by ti.com id AA20118; Fri, 23 Sep 88 11:03:28 CDT
Received: from Kelvin by tilde id AA14887; Fri, 23 Sep 88 10:48:13 CDT
Message-Id: <2800021756-7557750@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 23 Sep 88  10:49:16 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Compiler@SAIL.Stanford.edu
Subject: re:  COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY

I have some concerns about the treatment of DEFCONSTANT in the proposal
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY (I'm looking at version
6, June 9, 1988).  I realize that I have missed the previous discussion of
this topic, so I apologize if you have heard all of this before.

The assumption behind the proposal is that DEFCONSTANT should be as much
like DEFVAR and DEFPARAMETER as possible, but I think a more useful
model would be constant declarations in other languages.

Pascal has constant declarations that look like this:

  const MaxIndex = 100;
        MaxCount = 101;

Since there are often cases where the value of one constant depends on
another, many Pascal implementations extend this to permit the value to
be an expression that depends on previous constants:

  const MaxIndex = 100;
        MaxCount = MaxIndex+1;

This extension has been carried over into Modula and Ada.  
Now the obvious equivalent in Common Lisp would be 

  (defconstant max-index 100)
  (defconstant max-count (1+ max-index))

But, according to the proposal at hand, this is not really the same
because, while the first one declares a compile-time constant, the
second does not.  To get the desired effect, the proposal suggests
doing: 

  (defconstant max-index 100)
  (defconstant max-count #.(1+ max-index))

Besides being ugly, this won't work because there is nothing that
specifies that constants defined earlier in the file are made available
to the reader for use in evaluating #. expressions.  So maybe then the
answer is:

  (eval-when (eval compile load)
    (defconstant max-index 100)
    (defconstant max-count (1+ max-index)))

This will work, but seems unnecessarily verbose.  Note that both forms
need to be included in the EVAL-WHEN because otherwise there is no
guarantee that the first constant will be available to the compile-time
evaluation of the second.

It might be said that if you just write it the straight-forward way

  (defconstant max-index 100)
  (defconstant max-count (1+ max-index))

then a good compiler would be able to optimize this by recognizing that
the value expression in the second line involves only constants and go
ahead and fold it.  However, the proposal as written seems to
explicitly forbid this; it would be necessary to weasel around it by
saying that we can do the optimization so long as it is done in such a
way that the user can't tell the difference.  And this is not as easy as
it sounds.  Not only would you have to make sure that all variable names
referenced in the expression are DEFCONSTANTs, but they would have to be
defined earlier in the same file (else their value might change before
the current file is loaded), and their value must also have been folded.
All of this seems to me to lessen the usefulness of the DEFCONSTANT
feature.

I would prefer the standard to adopt the approach that we have taken on
the Explorer, namely that the value expression of a DEFCONSTANT is
always evaluated at compile time, and has access to other constants and
macros defined earlier in the file.  (However, because CLtL does not
specify this behavior, if there is an error during the evaluation, our
compiler just issues a warning message and causes evaluation to be
re-tried at load time.)

∂23-Sep-88  1353	CL-Compiler-mailer 	Re: Issue: COMPILE-FILE-ENVIRONMENT (Version 1)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Sep 88  13:53:19 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 SEP 88 13:34:27 PDT
Date: 23 Sep 88 13:34 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: COMPILE-FILE-ENVIRONMENT (Version 1)
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of Fri, 23
 Sep 88 09:59:12 MDT
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
cc: cl-compiler@sail.stanford.edu
Message-ID: <880923-133427-1906@Xerox>

"And, I don't think that really falls into the
domain of the compiler committee..."

Well, we can't spawn a commitee for everything. I'd like the compiler committee
to take everything that says "compile" in its name, unless you explicitly hand
it back to cleanup. Are you doing that with this one?

∂23-Sep-88  1730	CL-Compiler-mailer 	issue EVAL-WHEN-NON-TOP-LEVEL 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 23 Sep 88  17:30:28 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA08093g; Fri, 23 Sep 88 16:28:37 PST
Received: by blacksox id AA01618g; Fri, 23 Sep 88 17:26:23 pdt
Date: Fri, 23 Sep 88 17:26:23 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809240026.AA01618@blacksox>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Fri, 23 Sep 88 11:53:07 MDT <8809231753.AA02502@defun.utah.edu>
Subject: issue EVAL-WHEN-NON-TOP-LEVEL

I CC'ed this to cl-compiler instead of x3j13.

Your sample implementation of EVAL-WHEN as a macro has some of the
usual bugs caused by relying on binding special variables.  This is
alleviated somewhat in this instance by having EVAL bind *COMPILING-P*
to NIL, but that causes the rather bizarre behavior of breaking
completely if the EVAL-WHEN macro itself, or any part of the compiler
surrounding the macro processing, is run interpretively.  The real
cure for this is COMPILE-FILE-ENVIRONMENT.  The EVAL-WHEN macro should
look at its environment to determine whether it is in the interpreter
or the compiler.

∂23-Sep-88  1742	CL-Compiler-mailer 	**DRAFT** issue COMPILE-ENVIRONMENT-CONSISTENCY   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 23 Sep 88  17:42:15 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA08105g; Fri, 23 Sep 88 16:40:25 PST
Received: by blacksox id AA01622g; Fri, 23 Sep 88 17:38:11 pdt
Date: Fri, 23 Sep 88 17:38:11 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809240038.AA01622@blacksox>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Fri, 23 Sep 88 11:56:22 MDT <8809231756.AA02532@defun.utah.edu>
Subject: **DRAFT** issue COMPILE-ENVIRONMENT-CONSISTENCY

[CC'ed to cl-compiler instead of x3j13.]

Do you want to allow the compiler to make assumptions based on FTYPE
proclamations or declarations, even if the function whose type is
being declared is not declared INLINE, not a built-in Common Lisp
function, and not defined in the same file as the call to the
function?  I think this is sensible and it reflects current practice.
You could add another condition in section (2), e.g.

    (i) The compiler may assume that the signature (or "contract") of
	functions with FTYPE information available will not change.

This should really go between (d) and (e) instead of after (h).

∂23-Sep-88  2120	CL-Compiler-mailer 	Re: **DRAFT** issue COMPILE-ENVIRONMENT-CONSISTENCY    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88  21:19:53 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA12820; Fri, 23 Sep 88 22:18:29 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA03284; Fri, 23 Sep 88 22:18:26 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809240418.AA03284@defun.utah.edu>
Date: Fri, 23 Sep 88 22:18:25 MDT
Subject: Re: **DRAFT** issue COMPILE-ENVIRONMENT-CONSISTENCY
To: Eric Benson <eb@lucid.com>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Eric Benson <eb@lucid.com>, Fri, 23 Sep 88 17:38:11 pdt

Sounds like a reasonable suggestion.  On the same topic, I seem to
remember that once upon a time Masinter volunteered to write a
proposal to clarify exactly what an FTYPE declaration means.  There
was some confusion about whether it referred to the actual definition
of the function, or simply to calls to the function within the scope
of the declaration.  For example, is it legal to declare + as taking
only two integer arguments, if that is how you are calling it?

-Sandra
-------

∂23-Sep-88  2149	CL-Compiler-mailer 	Issues: EVAL-WHEN-NON-TOP-LEVEL, DEFINING-MACROS-NON-TOP-LEVEL   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 23 Sep 88  21:49:05 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA08226g; Fri, 23 Sep 88 20:47:15 PST
Received: by bhopal id AA11839g; Fri, 23 Sep 88 21:46:45 PDT
Date: Fri, 23 Sep 88 21:46:45 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809240446.AA11839@bhopal>
To: vanroggen%aitg.DEC@decwrl.dec.com
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: vanroggen%aitg.DEC@decwrl.dec.com's message of Wed, 21 Sep 88 08:25:53 PDT <8809211525.AA14884@decwrl.dec.com>
Subject: Issues: EVAL-WHEN-NON-TOP-LEVEL, DEFINING-MACROS-NON-TOP-LEVEL

re: It would be useful to say right there (again) that "top-level" means
    a null lexical environment.

You know, that's not a bad answer to one of the most unanswerable questions
in lisp history.  I like it.


re: BTW, VAX LISP does not treat COMPILER-LET bodies as being at top-level.
    It's OK with me if we do add this functionality, though frankly I'd
    prefer we deleted COMPILER-LET from the language.  But that's another
    issue.

Flush it!  Go for it!


-- JonL --

∂24-Sep-88  1652	CL-Compiler-mailer 	issue COMPILE-FILE-PACKAGE    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Sep 88  16:52:27 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 465104; Sat 24-Sep-88 19:50:43 EDT
Date: Sat, 24 Sep 88 19:50 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-FILE-PACKAGE
To: sandra%defun@cs.utah.edu
cc: CL-Compiler@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8809231754.AA02517@defun.utah.edu>
Message-ID: <880924195035.7.KMP@GRYPHON.SCRC.Symbolics.COM>

I support the proposal COMPILE-FILE-PACKAGE:REBIND, but would
like to see the wording of the proposal changed from 

  to rebind *PACKAGE*

to

  to rebind *PACKAGE* to its current value

for clarity.

∂24-Sep-88  1658	CL-Compiler-mailer 	Issue: PROCLAIM-INLINE-WHERE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Sep 88  16:58:30 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 465109; Sat 24-Sep-88 19:57:07 EDT
Date: Sat, 24 Sep 88 19:57 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-INLINE-WHERE (Version 1)
To: sandra%defun@cs.utah.edu
cc: CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: <8809231755.AA02527@defun.utah.edu>
Message-ID: <880924195704.8.KMP@GRYPHON.SCRC.Symbolics.COM>

Deja vu. I'd swear I had written something exactly like this for
CL-Cleanup but I cannot find any record of it. Maybe David got it
out of the CL archives.

Anyway, I support PROCLAIM-INLINE-WHERE:BEFORE.

∂24-Sep-88  1709	CL-Compiler-mailer 	issue OPTIMIZE-DEBUG-INFO
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Sep 88  17:09:23 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 465112; Sat 24-Sep-88 20:07:48 EDT
Date: Sat, 24 Sep 88 20:07 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue OPTIMIZE-DEBUG-INFO
To: sandra%defun@cs.utah.edu
cc: CL-Compiler@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8809231755.AA02522@defun.utah.edu>
Message-ID: <880924200745.9.KMP@GRYPHON.SCRC.Symbolics.COM>

I would prefer if discussions of OPTIMIZE qualities avoided references
to absolute magnitudes of those qualities pending discussion of whether
it is absolute magnitude or relative value compared to other qualities
that is significant.

However, since that terminological quibbling doesn't affect the actual
proposal part of your writeup, I support OPTIMIZE-DEBUG-INFO:NEW-QUALITY.

By the way, in stripping down the writeup, you forgot to remove some
indentation. You might want to fix that for the hardcopy version since
it makes it a little harder to read -- I had to flip back and forth a
bit at one point to make sure there weren't two proposals contained, of
which I was reading only one.

∂24-Sep-88  1720	CL-Compiler-mailer 	Issue ALLOW-LOCAL-INLINE (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Sep 88  17:20:07 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 465118; Sat 24-Sep-88 20:17:48 EDT
Date: Sat, 24 Sep 88 20:17 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue ALLOW-LOCAL-INLINE (Version 1)
To: Gray@DSG.csc.ti.com
cc: CL-Compiler@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <2799937206-2477835@Kelvin>
Message-ID: <880924201739.0.KMP@GRYPHON.SCRC.Symbolics.COM>

In the Symbolics implementation, at least, you can achieve most
of the ALLOW-INLINE effect by doing:

 (PROCLAIM '(INLINE FOO))
 (DEFUN FOO (X) (+ X 7))
 (PROCLAIM '(NOTINLINE FOO))
 (DEFUN BAR (X) (DECLARE (INLINE FOO)) (FOO X))
 (DEFUN BAZ (X) (FOO X))

BAR will get FOO inlined, but BAZ will not. I say "most of"
the effect because you proposed that NOTINLINE turn off ALLOW-INLINE,
and obviously in the above example, NOTINLINE does something very
different.

I sort of assumed that this behavior was portable. If it's not, that
might make your proposal more interesting -- or it might make for an
interesting proposal of its own.

Personally, I'm bothered by the following more significant problem:

 --- File a.lisp ---
 (PROCLAIM '(INLINE FOO))
 (DEFUN FOO (X) ...)
 -------------------

 (load "a.lisp")

Then later, after editing the out the (PROCLAIM '(INLINE FOO)),

 (load "a.lisp")

does not leave me with A not being inline. It used to be in Symbolics
implementations that you wrote

 (DEFSUBST FOO ...)

to get an inlined definition and if you changed it to DEFUN you would
get it notinlined. But with the advent of CL, DEFSUBST was changed to
do
 (PROGN (PROCLAIM '(INLINE FOO))
        (DEFUN FOO ...))
which means that a later change to DEFUN cannot tell that you've changed
from DEFSUBST to DEFUN and so cannot remove the INLINE-ness. Pity.

Personally, I think CL should just flush the INLINE proclamation and
support DEFSUBST instead because it would make this incremental
development situation easier.

∂24-Sep-88  1726	CL-Compiler-mailer 	issue COMPILE-ARGUMENT-PROBLEMS    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Sep 88  17:26:51 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 465120; Sat 24-Sep-88 20:25:24 EDT
Date: Sat, 24 Sep 88 20:25 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-ARGUMENT-PROBLEMS
To: sandra%defun@cs.utah.edu
cc: CL-Compiler@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8809231754.AA02512@defun.utah.edu>
Message-ID: <880924202520.1.KMP@GRYPHON.SCRC.Symbolics.COM>

This issue has been on my hit list so I'm glad you took care of
writing it up, but I would prefer not to vote for the proposal
you suggest.

The presence of interpreted-only and compiled-only implementations
leads me to believe that it is ludicrous for us to be saying it's
an error if the function is already compiled and to also say that
it's ok to pass a non-compiled function.

I would prefer to simply define that the optional definition argument,
if supplied, will be compiled if it is a LAMBDA expression and that
otherwise the operation is permitted to be a no-op but is allowed to
do [further] compilation if that is feasible in the given implementation.

∂24-Sep-88  1914	CL-Compiler-mailer 	Issue ALLOW-LOCAL-INLINE (Version 1)    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 24 Sep 88  19:14:43 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA08532g; Sat, 24 Sep 88 18:12:37 PST
Received: by blacksox id AA01650g; Sat, 24 Sep 88 19:10:23 pdt
Date: Sat, 24 Sep 88 19:10:23 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809250210.AA01650@blacksox>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: Gray@DSG.csc.ti.com, CL-Compiler@SAIL.Stanford.EDU,
        KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: Kent M Pitman's message of Sat, 24 Sep 88 20:17 EDT <880924201739.0.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue ALLOW-LOCAL-INLINE (Version 1)

   Date: Sat, 24 Sep 88 20:17 EDT
   From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

   In the Symbolics implementation, at least, you can achieve most
   of the ALLOW-INLINE effect by doing:

    (PROCLAIM '(INLINE FOO))
    (DEFUN FOO (X) (+ X 7))
    (PROCLAIM '(NOTINLINE FOO))
    (DEFUN BAR (X) (DECLARE (INLINE FOO)) (FOO X))
    (DEFUN BAZ (X) (FOO X))

This is also true in Lucid's implementation.

∂26-Sep-88  0932	CL-Compiler-mailer 	Re: Issue ALLOW-LOCAL-INLINE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88  09:31:14 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 465234; Sun 25-Sep-88 15:21:51 EDT
Date: Sun, 25 Sep 88 15:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue ALLOW-LOCAL-INLINE (Version 1)
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM,
    Gray%dsg.csc.ti.com@NSS.Cs.Ucl.AC.UK, CL-Compiler@sail.stanford.edu
In-Reply-To: <16990.8809251829@subnode.aiai.ed.ac.uk>
Message-ID: <880925152143.5.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Sun, 25 Sep 88 19:29:47 BST
    From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>

    I'm surprised that implementations actually require this "advance
    notice" for INLINE declarations.

That's the point of these proposals -- to make things less surprising.
If it makes you feel any better, it came as a surprise to me, too.
But all the compiler guys I know say my surprise surprises them.

    I don't really like this proposal because it makes it more likely
    that INLINE declarations will do nothing unless the proclamation
    is in effect.

C'est la vie. Status quo. As it was presented to me, the amount of storage
that would have to be written to compiler output files, saved at runtime,
etc. just in case someone later did (PROCLAIM '(INLINE ...)) would be
prohibitive. Saying the info was retained only for the remainder of the
file would give files a somewhat arbitrary place in the world of scoping.

    Are there implementations that can't do inlining without the advance
    notice?

Sure: Symbolics Genera, Symbolics Cloe, and VAXLISP. At this point,
I imagine most do others as well.

    ...
    > Personally, I think CL should just flush the INLINE proclamation and
    > support DEFSUBST instead because it would make this incremental
    > development situation easier.

    What about locally in-line functions as in E.B.'s substitute for
    SYMBOL-MACRO-FLET?

Well, I don't have any opposition to INLINE declarations for local
functions. And my remark was unrealistic for other reasons. Asking for
DEFSUBST means asking for DEFGENERICSUBST, DEFMETHODSUBST, FLETSUBST,
LABELSSUBST, etc. and causes a real namespace explosion. I was mostly
just thinking wishfully.

∂26-Sep-88  0933	CL-Compiler-mailer 	DEFCONSTANT    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 26 Sep 88  09:32:48 PDT
Received: by ti.com id AA11616; Mon, 26 Sep 88 11:04:10 CDT
Received: from Kelvin by tilde id AA16939; Mon, 26 Sep 88 10:58:50 CDT
Message-Id: <2800281594-6674835@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 26 Sep 88  10:59:54 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Compiler@SAIL.Stanford.edu
Subject: DEFCONSTANT

I've had a further thought about what I said about DEFCONSTANT -- my
example 

  (eval-when (eval compile load)
    (defconstant max-index 100)
    (defconstant max-count (1+ max-index)))

assumes that the compiler will do the optimization which the specification
at most permits but does not encourage.  So in order for this to be
portable without loss of efficiency, the correct answer would be:

  (eval-when (eval compile load)
    (defconstant max-index 100))
  (defconstant max-count #.(1+ max-index))

Although if the second constant were to be used in another constant
definition, then it would need to be 

  (eval-when (eval compile load)
    (defconstant max-index 100))
  (eval-when (eval compile load)
    (defconstant max-count #.(1+ max-index)))

Note that separate EVAL-WHENs are needed in order for the #. to work
right.

Come on; do we really expect users to be able to understand this?

Sandra has suggested that instead of holding up voting on proposal
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY that I submit a separate
proposal to amend the definition of DEFCONSTANT; I will plan to do that.

∂26-Sep-88  0937	CL-Compiler-mailer 	Re: Issue ALLOW-LOCAL-INLINE (Version 1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 26 Sep 88  09:37:09 PDT
Received: by ti.com id AA11823; Mon, 26 Sep 88 11:33:38 CDT
Received: from Kelvin by tilde id AA17775; Mon, 26 Sep 88 11:28:02 CDT
Message-Id: <2800283345-6780031@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 26 Sep 88  11:29:05 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Compiler@SAIL.Stanford.EDU
Subject: Re: Issue ALLOW-LOCAL-INLINE (Version 1)
In-Reply-To: Msg of Sat, 24 Sep 88 20:17 EDT from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

> In the Symbolics implementation, at least, you can achieve most
> of the ALLOW-INLINE effect by doing:
> 
>  (PROCLAIM '(INLINE FOO))
>  (DEFUN FOO (X) (+ X 7))
>  (PROCLAIM '(NOTINLINE FOO))
>  (DEFUN BAR (X) (DECLARE (INLINE FOO)) (FOO X))
>  (DEFUN BAZ (X) (FOO X))
> 
> BAR will get FOO inlined, but BAZ will not. I say "most of"
> the effect because you proposed that NOTINLINE turn off ALLOW-INLINE,
> and obviously in the above example, NOTINLINE does something very
> different.
> 
> I sort of assumed that this behavior was portable. If it's not, that
> might make your proposal more interesting -- or it might make for an
> interesting proposal of its own.

Very good point.  Maybe instead of a new proclamation we just need a
clarification to point out that this is the proper way to do local
inlining.

> Personally, I'm bothered by the following more significant problem:
> 
>  --- File a.lisp ---
>  (PROCLAIM '(INLINE FOO))
>  (DEFUN FOO (X) ...)
>  -------------------
> 
>  (load "a.lisp")
> 
> Then later, after editing the out the (PROCLAIM '(INLINE FOO)),
> 
>  (load "a.lisp")
> 
> does not leave me with A not being inline.

Yes, that's not too nice, but a least you can do a (PROCLAIM '(NOTINLINE
FOO)) at the time you edit out the INLINE.  A worse problem is
(PROCLAIM '(SPECIAL ...)) which doesn't have any standard way to undo it.

>    It used to be in Symbolics
> implementations that you wrote
> 
>  (DEFSUBST FOO ...)
> 
> to get an inlined definition and if you changed it to DEFUN you would
> get it notinlined. But with the advent of CL, DEFSUBST was changed to
> do
>  (PROGN (PROCLAIM '(INLINE FOO))
>         (DEFUN FOO ...))
> which means that a later change to DEFUN cannot tell that you've changed
> from DEFSUBST to DEFUN and so cannot remove the INLINE-ness. Pity.
> 
> Personally, I think CL should just flush the INLINE proclamation and
> support DEFSUBST instead because it would make this incremental
> development situation easier.

But Symbolics has redefined DEFSUBST to be equivalent to a Common Lisp
INLINE function; the original meaning of DEFSUBST in Zetalisp was not
quite the same, so I imagine that's why Common Lisp avoided using that
name.  On the Explorer, DEFSUBST still has the old meaning (but is
considered obsolete).

∂26-Sep-88  1044	CL-Compiler-mailer 	Re: Issue ALLOW-LOCAL-INLINE (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 26 Sep 88  10:43:40 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa04207; 25 Sep 88 18:51 BST
Date: Sun, 25 Sep 88 19:29:47 BST
Message-Id: <16990.8809251829@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue ALLOW-LOCAL-INLINE (Version 1)
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, 
    Gray%dsg.csc.ti.com@NSS.Cs.Ucl.AC.UK
In-Reply-To: Kent M Pitman's message of Sat, 24 Sep 88 20:17 EDT
Cc: CL-Compiler@sail.stanford.edu

> In the Symbolics implementation, at least, you can achieve most
> of the ALLOW-INLINE effect by doing:
> 
>  (PROCLAIM '(INLINE FOO))
>  (DEFUN FOO (X) (+ X 7))
>  (PROCLAIM '(NOTINLINE FOO))

I'm surprised that implementations actually require this "advance
notice" for INLINE declarations.

I don't really like this proposal because it makes it more likely
that INLINE declarations will do nothing unless the proclamation
is in effect.

Are there implementations that can't do inlining without the advance
notice?

> It used to be in Symbolics implementations that you wrote
> 
>  (DEFSUBST FOO ...)
> 
> to get an inlined definition and if you changed it to DEFUN you would
> get it notinlined. But with the advent of CL, DEFSUBST was changed to
> do
>  (PROGN (PROCLAIM '(INLINE FOO))
>         (DEFUN FOO ...))
> which means that a later change to DEFUN cannot tell that you've changed
> from DEFSUBST to DEFUN and so cannot remove the INLINE-ness. Pity.
> 
> Personally, I think CL should just flush the INLINE proclamation and
> support DEFSUBST instead because it would make this incremental
> development situation easier.

What about locally in-line functions as in E.B.'s substitute for
SYMBOL-MACRO-FLET?


∂26-Sep-88  1046	CL-Compiler-mailer 	Flush COMPILER-LET? 
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 26 Sep 88  10:44:35 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa04255; 25 Sep 88 19:12 BST
Date: Sun, 25 Sep 88 19:51:06 BST
Message-Id: <17042.8809251851@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Flush COMPILER-LET?
To: cl-compiler@sail.stanford.edu

Someone recently mentioned flushing COMPILER-LET.  That might be a
good idea.  What is it used for that need only dynamic scope?

-- Jeff

∂26-Sep-88  1130	CL-Compiler-mailer 	Re: Flush COMPILER-LET?  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 26 Sep 88  11:30:09 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA22700; Mon, 26 Sep 88 12:28:16 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA05299; Mon, 26 Sep 88 12:27:38 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809261827.AA05299@defun.utah.edu>
Date: Mon, 26 Sep 88 12:27:37 MDT
Subject: Re: Flush COMPILER-LET?
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nss.cs.ucl.ac.uk>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Sun, 25 Sep 88 19:51:06 BST

I could live with getting rid of COMPILER-LET.  It is supposed to be
used for communication between complicated macros; i.e., the bindings
it makes at compile time are available during the expansion of macro
calls in the body.  It does seem like you could get most of the same
effect using MACROLET.

In other words, suppose I have something like:

    (eval-when (eval compile)
        (defvar *foo* nil))

    (defmacro foo-macro (x)
        (compute-foo-expansion x))

Then, I could replace

    (compiler-let ((*foo* t))
        ... (foo-macro ...))

with

    (macrolet ((foo-macro (x)
    	           (let ((*foo* t))
		       (compute-foo-expansion x))))
        ... (foo-macro ...))

    
I actually use COMPILER-LET in one place in the compiler I've been
hacking on.  It appears in the expansion of a source-to-source
transformation on UNWIND-PROTECT, to rebind a variable internal to the
first pass of the compiler.  That is hardly what I would consider a
typical use, though, and I can think of a couple other ways to do the
same thing.

-Sandra
-------

∂26-Sep-88  1152	CL-Compiler-mailer 	Re: Flush COMPILER-LET?  
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 26 Sep 88  11:52:18 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA02885; Mon, 26 Sep 88 11:48:43 PDT
Received: from clam.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA21272; Mon, 26 Sep 88 11:51:38 PDT
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA21051; Mon, 26 Sep 88 11:52:12 PDT
Date: Mon, 26 Sep 88 11:52:12 PDT
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8809261852.AA21051@clam.sun.com>
To: cl-compiler@sail.stanford.edu
Subject: Re: Flush COMPILER-LET?

It appears to be time for the users who care about COMPILER-LET
to say why it is important to them.  Interpreted-code
closures that get returned from a COMPILER-LET or passed
around are liable not to see the variable values set up in
the COMPILER-LET, and that is a major defect.

I would certainly be in the camp proposing to remove
COMPILER-LET if the reasons for keeping it aren't compelling.

				-Cris

∂26-Sep-88  1158	CL-Compiler-mailer 	Re: Flush COMPILER-LET?  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 26 Sep 88  11:57:21 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA23509; Mon, 26 Sep 88 12:55:57 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA05330; Mon, 26 Sep 88 12:55:54 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809261855.AA05330@defun.utah.edu>
Date: Mon, 26 Sep 88 12:55:53 MDT
Subject: Re: Flush COMPILER-LET?
To: cperdue@sun.com (Cris Perdue)
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: cperdue@Sun.COM (Cris Perdue), Mon, 26 Sep 88 11:52:12 PDT

OK, I will send a message to the common-lisp mailing list asking for
comments about this.

-Sandra
-------

∂26-Sep-88  1328	CL-Compiler-mailer 	[James Rice <Rice@SUMEX-AIM.Stanford.EDU>: Re: Compiler-Let]
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 26 Sep 88  13:28:43 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA26587; Mon, 26 Sep 88 14:27:19 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA05417; Mon, 26 Sep 88 14:27:17 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809262027.AA05417@defun.utah.edu>
Date: Mon, 26 Sep 88 14:27:16 MDT
Subject: [James Rice <Rice@SUMEX-AIM.Stanford.EDU>: Re: Compiler-Let]
To: cl-compiler@sail.stanford.edu


**** Forwarded Message Follows ****
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA05409; Mon, 26 Sep 88 14:24:01 MDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA26536; Mon, 26 Sep 88 14:23:52 MDT
Date: Mon, 26 Sep 88 13:18:22 PDT
From: James Rice <Rice@SUMEX-AIM.Stanford.EDU>
Subject: Re: Compiler-Let
To: Sandra@cs
Message-Id: <12433711717.59.RICE@SUMEX-AIM.Stanford.EDU>


Hello,
I just thought I'd mention the only time that I've ever been
inclined to use Compiler-Let (I hate it), which was so as to
be able to get compile time evaluation of code during the
inlining of a subst.  For example:

(Defsubst dbg ()
 ;;; Make dbg like it is on Symbolics.
  (compiler-let ((*dummy-I-don't-really-use-this*
		    (compiler:warn .....)))
	(cerror "Proceed from breakpoint" "Debugger breakpoint")))

Horrible isn't it?
Anyway, I con't help thinking that some sort of mechanism for
the compile-time evaluation of code which is being substed/inlined
is a good idea.  Maybe the cleanups for Eval-When will give us
non-top-level evaluation.  I haven't been tracking that issue.

Hope this was of some use,


Rice.
-------

**** End of Forwarded Message ****
-------

∂26-Sep-88  1237	Common-Lisp-mailer 	COMPILER-LET   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 26 Sep 88  12:37:27 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA25080; Mon, 26 Sep 88 13:36:05 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA05384; Mon, 26 Sep 88 13:36:02 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809261936.AA05384@defun.utah.edu>
Date: Mon, 26 Sep 88 13:36:01 MDT
Subject: COMPILER-LET
To: common-lisp@sail.stanford.edu
Cc: cl-compiler@sail.stanford.edu

The ANSI X3J13 (Common Lisp Standardization) compiler cleanup committee
is contemplating a proposal to remove COMPILER-LET from the language.
If you have some code that uses COMPILER-LET and you don't think that
it could be rewritten to use some other construct, the compiler
committee (cl-compiler@sail.stanford.edu) would like to hear about it.

Reasons for flushing COMPILER-LET include:

* COMPILER-LET is ugly and confusing.  The dynamic extent of the variable
  bindings in interpreted code can lead to subtle bugs.  In compiled code,
  the variable bindings are only visible to macros within the lexical scope
  of the COMPILER-LET.

* COMPILER-LET appears to be rarely used. 

* Most (all?) instances of using COMPILER-LET for the purpose suggested
  in CLtL ("communication among complicated macros") can be handled
  just as well using MACROLET.  Using MACROLET for this purpose also makes
  it more clear that the expansion of certain macros depends upon the
  lexical context in which they appear.

  For example, suppose I have something like:

    (eval-when (eval compile)
        (defvar *foo* nil))

    (defmacro foo-macro (x)
        (compute-foo-expansion x))

  Then, I could replace

    (compiler-let ((*foo* t))
        ... (foo-macro ...))

  with

    (macrolet ((foo-macro (x)
    	           (let ((*foo* t))
		       (compute-foo-expansion x))))
        ... (foo-macro ...))

-Sandra Loosemore (sandra@cs.utah.edu)
-------

∂26-Sep-88  1351	CL-Compiler-mailer 	Re: Flush COMPILER-LET?  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88  13:51:12 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 465796; Mon 26-Sep-88 16:48:19 EDT
Date: Mon, 26 Sep 88 16:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Flush COMPILER-LET?
To: sandra%defun@cs.utah.edu
cc: jeff%aiai.edinburgh.ac.uk@nss.cs.ucl.ac.uk,
    cl-compiler@sail.stanford.edu
In-Reply-To: <8809261827.AA05299@defun.utah.edu>
Message-ID: <880926164809.7.KMP@GRYPHON.SCRC.Symbolics.COM>

I think the intended use is slightly different from the example you gave.
Here's what I think of as a prototypical example...

 (DEFVAR *LOCAL-TYPE-DECLARATIONS* '())
 
 (DEFMACRO LOCAL-TYPE-DECLARE (DECLARATIONS &BODY FORMS)
   `(COMPILER-LET ((*LOCAL-TYPE-DECLARATIONS* 
		     (APPEND ',DECLARATIONS *LOCAL-TYPE-DECLARATIONS*)))
      ,@FORMS))
 
 (DEFMACRO TYPED-VAR (VAR)
   (LET ((TYPE (ASSOC VAR *LOCAL-TYPE-DECLARATIONS*)))
     (IF TYPE `(THE ,(CADR TYPE) ,VAR) VAR)))
 
 (DEFUN F (X Y)
   (LOCAL-TYPE-DECLARE ((X FIXNUM) (Y FLOAT))
     (+ (TYPED-VAR X) (TYPED-VAR Y))))
 
is equivalent to

 (DEFUN F (X Y) (+ (THE FIXNUM X) (THE FIXNUM Y)))

You can do the same thing with MACROLET, but it feels quite awkward.

 (DEFMACRO LOCAL-TYPE-DECLARATIONS () '())
 
 (DEFMACRO LOCAL-TYPE-DECLARE (DECLARATIONS &BODY FORMS &ENVIRONMENT ENV)
   `(MACROLET ((LOCAL-TYPE-DECLARATIONS ()
		 ',(APPEND DECLARATIONS 
			   (MACROEXPAND '(LOCAL-TYPE-DECLARATIONS) ENV))))
      ,@FORMS))
 
 (DEFMACRO TYPED-VAR (VAR &ENVIRONMENT ENV)
   (LET ((TYPE (ASSOC VAR (MACROEXPAND '(LOCAL-TYPE-DECLARATIONS) ENV))))
     (IF TYPE `(THE ,(CADR TYPE) ,VAR) VAR)))
 
 (DEFUN F (X Y)
   (LOCAL-TYPE-DECLARE ((X FIXNUM) (Y FLOAT))
     (+ (TYPED-VAR X) (TYPED-VAR Y))))
 
In my opinion, the only thing that makes COMPILER-LET feel bad is the
stubborn refusal for interpreted-only implementations to do a semantic
prepass. This is what forces you to do a special-bind at runtime. If
COMPILER-LET did a special-bind only at conceptual compile time (i.e.,
semantic pre-pass for interpreted code), it would not seem nearly so
nasty because it wouldn't interfere unpredictably with runtime bindings.

∂26-Sep-88  1359	CL-Compiler-mailer 	[James Rice <Rice@SUMEX-AIM.Stanford.EDU>: Re: Compiler-Let]
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Sep 88  13:59:50 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA09410g; Mon, 26 Sep 88 12:57:52 PST
Received: by blacksox id AA00144g; Mon, 26 Sep 88 13:55:20 pdt
Date: Mon, 26 Sep 88 13:55:20 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809262055.AA00144@blacksox>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu, Rice@SUMEX-AIM.Stanford.EDU
In-Reply-To: Sandra J Loosemore's message of Mon, 26 Sep 88 14:27:16 MDT <8809262027.AA05417@defun.utah.edu>
Subject: [James Rice <Rice@SUMEX-AIM.Stanford.EDU>: Re: Compiler-Let]

   From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
   Date: Mon, 26 Sep 88 14:27:16 MDT

   (Defsubst dbg ()
    ;;; Make dbg like it is on Symbolics.
     (compiler-let ((*dummy-I-don't-really-use-this*
		       (compiler:warn .....)))
	   (cerror "Proceed from breakpoint" "Debugger breakpoint")))

Notice this is trivially converted from COMPILER-LET to MACROLET as
follows:

(Defsubst dbg ()
 ;;; Make dbg like it is on Symbolics.
  (macrolet ((not-used ()
		(compiler:warn .....)))
        (not-used)
	(cerror "Proceed from breakpoint" "Debugger breakpoint")))


(Ignoring the fact that DEFSUBST and COMPILER:WARN aren't Common Lisp.)

∂26-Sep-88  1512	CL-Compiler-mailer 	Re: COMPILER-LET    
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 26 Sep 88  15:12:33 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA00355; Mon, 26 Sep 88 18:12:14 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA18417; Mon, 26 Sep 88 18:13:58 EDT
Message-Id: <8809262213.AA18417@mist.UUCP>
To: Kent M Pitman <KMP%STONY-BROOK.SCRC.Symbolics.COM@multimax>
Cc: cl-compiler%sail.stanford.edu@multimax
Subject: Re: COMPILER-LET 
In-Reply-To: Your message of Mon, 26 Sep 88 17:11:00 -0400.
Date: Mon, 26 Sep 88 18:13:54 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    In my opinion, the real problem is that interpreted-only
    implementations are not required to make a semantic-prepass. This
    means that macro expansion and COMPILER-LET handling may happen all at
    once or at any known time, so it must risk interfering with runtime
    variable bindings. If interpreters were required to do the pre-pass
    (effectively, a mini-compile just doing macro expansion, etc), not
    only would COMPILER-LET seem ok, but other problem spots in the
    language (like EVAL-WHEN) would be easier to tackle as well.
    
This may be too advanced for this late date, but...    

Would this (and other) problems be reduced if we defined a
code-walking primitive and required it in the language?  Would this
reduce Sandra's objection to forcing all interpreters to do a pre-pass?

∂26-Sep-88  1413	Common-Lisp-mailer 	COMPILER-LET   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88  14:12:56 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 465834; Mon 26-Sep-88 17:11:24 EDT
Date: Mon, 26 Sep 88 17:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: COMPILER-LET
To: sandra%defun@cs.utah.edu
cc: common-lisp@sail.stanford.edu, cl-compiler@sail.stanford.edu
In-Reply-To: <8809261936.AA05384@defun.utah.edu>
Message-ID: <880926171117.9.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Mon, 26 Sep 88 13:36:01 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    ... COMPILER-LET is ugly and confusing.  The dynamic extent of the variable
    bindings in interpreted code can lead to subtle bugs.  In compiled code,
    the variable bindings are only visible to macros within the lexical scope
    of the COMPILER-LET. ...

The whole purpose of COMPILER-LET is to allow communication between textually
unrelated macros, so of course it's only visible within the lexical scope of
the COMPILER-LET in the compiler.

In my opinion, the real problem is that interpreted-only implementations are not
required to make a semantic-prepass. This means that macro expansion and 
COMPILER-LET handling may happen all at once or at any known time, so it must
risk interfering with runtime variable bindings. If interpreters were required
to do the pre-pass (effectively, a mini-compile just doing macro expansion, etc),
not only would COMPILER-LET seem ok, but other problem spots in the language
(like EVAL-WHEN) would be easier to tackle as well.

I've sent more detailed comments to CL-Compiler, and will carry on a complete
technical discussion there, but I wanted to make this reply to all of Common-Lisp
since many people will not see that discussion so that they know that this is
not as one-sided an issue as you have painted it.

End of opposition viewpoint.

∂26-Sep-88  1540	CL-Compiler-mailer 	Re: COMPILER-LET    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 26 Sep 88  15:39:48 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA01697; Mon, 26 Sep 88 16:38:10 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA05584; Mon, 26 Sep 88 16:37:56 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809262237.AA05584@defun.utah.edu>
Date: Mon, 26 Sep 88 16:37:55 MDT
Subject: Re: COMPILER-LET 
To: Dan L. Pierson <pierson%mist@MULTIMAX.ENCORE.COM>
Cc: KMP@stony-brook.scrc.symbolics.com, cl-compiler@sail.stanford.edu

[Sigh, the mailer barfed the first time I tried sending this...]

> Date: Mon, 26 Sep 88 18:13:54 EDT
> From: Dan L. Pierson <pierson%mist@multimax.ARPA>
> 
> Would this (and other) problems be reduced if we defined a
> code-walking primitive and required it in the language?  Would this
> reduce Sandra's objection to forcing all interpreters to do a pre-pass?

My experience with code-walking primitives is that they don't work.  I
wrote one a few years ago that had all sorts of hooks in it to be as
general as possible.  I was actually using it for a while to implement
something similar to WITH-SLOTS.  Shortly afterwards, a group of us
here at Utah had a need for a code walker to do various kinds of
source-to-source transformations for PCLS.  Turns out my codewalker
was useless and they ended up writing specialized processors for each
pass.  Another person here tried again later with the same results.
Of course, I'd be much less skeptical if you came up with a specific
proposal and I found that I could actually use it for some of the
things I'm doing a code walk for now.

Also, it really isn't "my" objection to forcing interpreters to do a
pre-pass; I'm willing to go along with it if everybody else is.  I've
merely stated that it would be an incompatible change to the language
and a substantial change for implementations that don't already do
things that way.  Also, I know that some users (including a number of
people here at Utah) really hate implementations that do a pre-pass.

-Sandra
-------

∂26-Sep-88  1800	CL-Compiler-mailer 	**DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Sep 88  18:00:39 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA09655g; Mon, 26 Sep 88 16:58:43 PST
Received: by bhopal id AA02587g; Mon, 26 Sep 88 17:58:15 PDT
Date: Mon, 26 Sep 88 17:58:15 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809270058.AA02587@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Fri, 23 Sep 88 11:56:59 MDT <8809231757.AA02537@defun.utah.edu>
Subject: **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE

re:  Current Practice:
     . . . 
     The Lucid documentation indicates
     that certain functions at top-level are treated as though within an
     (EVAL-WHEN (EVAL COMPILE LOAD) ...): REQUIRE, all of the package
     functions listed above, INTERN, and UNINTERN; it is not clear what
     happens with PROCLAIM.

Two things should be clarified here [just in case anyone raises the
issue in the future]:

(1) The forms documented by Lucid as being implicitly wrapped within
    an eval-when do not include toplevel EVAL-WHEN forms;  as can be seen
    from the proposal regarding non-top-level eval-when's, the semantics
    of the situation (EVAL COMPILE LOAD) cannot be fully "undone" by 
    embedded eval-when's.
(2) Lucid does not currently include PROCLAIM, but no doubt would be
    quite happy to do so.


-- JonL --


P.S. Note that I cc'd this comment only to cl-compiler -- not to x3j13.

∂26-Sep-88  2154	CL-Cleanup-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Sep 88  21:54:38 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00202g; Mon, 26 Sep 88 20:52:37 PST
Received: by bhopal id AA03126g; Mon, 26 Sep 88 21:52:09 PDT
Date: Mon, 26 Sep 88 21:52:09 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809270452.AA03126@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 19 Sep 88 14:06:15 MDT <8809192006.AA00963@defun.utah.edu>
Subject: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM

Of the numerous proposals of this ilk, this one seems to me to be the one
most workable.

Following our charter, we should look to Interlisp and see how experience 
has fared with its function LOADTIMECONSTANT [maybe never documented?].
Its semantics were, coincidentally, essentially the same as those you have
spelled out for LOAD-TIME-EVAL.  [By the way, shouldn't the Interlisp 
precedent bias us towards the name LOAD-TIME-CONSTANT rather than towards 
LOAD-TIME--EVAL?].

However, a more serious issue seems to have gotten lost in all the flaming.
At Lucid, we all seem to favor flushing #,.  Who really wants it?  At best,
when someone previously suggested flushing #,  I remember an efficiency 
argument being invoked,  but not being _demonstrated_.

There is a serious flaw in the design of #, and for this reason alone
it should be flushed [explication of the "flaw" is further below.] The 
burden of _proof_ to show that any reasonable program is seriously 
hampered without it is on those who invoke the argument.  As Gabriel 
would say of benchmarking, no raw numbers without theory to explain why, 
and certainly no speculation without hard numbers.

Where are the numbers which prove an inefficiency so grave as to cause
us to tolerate this inherently flawed and misleading construct #,?


The "grave flaw" centers around the common misconception that you
are either:

	(1) reading the source code, for interpretation  -- EVAL situation
        (2) reading it for compilation to a file         -- COMPILE situation
        (3) loading the compiled version of the file     -- LOAD situation

that is, one and only one of the three situations applies.  But as Kent's
little trivial example showed:
     (EVAL-WHEN (EVAL COMPILE LOAD)
       (DEFUN FOO (X) #,`(X ,(SQRT 3))))
you may be reading a piece of code for *** two *** of the situations at 
one time.  You are both EVAL'ing and COMPILE'ing a single solitary form 
at essentially "one and the same time".  [Early versions of PCL tried to 
use some such trick, and lost badly.]

The whole idea of the "magic token" is that at read-time you can somehow
inspect either the dynamic or lexical environment, and decide with of the 
three situations is relevant.  But you can't; you can only know which 
situation is relevant at actual processing time -- not at read time (and 
of course a special form has access to the lexical environment).  Sandra 
put it quite well when countering a proposal to make the LOAD-TIME-EVAL 
thing be a function instead of a special form:

    Date: Wed, 21 Sep 88 15:05:28 MDT
    Subject: Re: Issue: LOAD-TIME-EVAL (Version 6)
    . . . 
    there a[re] more situations in which code is processed than simply
    interpretation and compilation.  It is not an either/or situation.  A
    person here at the UofU, for example, has been working on a portable
    type inference preprocessor.  It reads in code, decorates it with lots
    of type declarations, and writes it out to another file which may then
    either be loaded interpretively or compiled with COMPILE-FILE.  . . . 


The implications of these theoretical arguments are not always easy to
follow, so I have reproduced an example file below that helps one see 
just how the screw-up occurs.  Every implementation I've tried this file
in,  when the source is loaded,  "does the right thing".  But when it is
compiled, they all leave the "magic tokens" in the source code for the 
function 'expose'; so  the value of 'foo', after compilation, has these 
tokens in it rather than the desired structure ((COMPILE A) (COMPILE B)). 
Correspondingly, the value of 'bar'  -- the 'exposure-normality' of 'foo' 
-- is ABNORMAL.

Worse yet, because the definition of 'normally-exposed-p' is a macro that 
gets "snapped" at compile time, the error is propagated to the runtime 
setting of 'bar'.  Namely, when the compiled file is loaded, 'foo'  has 
the right value --  ((LOAD A) (LOAD B)) -- but 'bar' wrongly says that 
the 'exposure-normality' state is ABNORMAL.  [Well, one implementation
got the value of 'foo' wrong too, but, hey, what the heck.]


Take this example and try it.  Look at FOO and BAR after each pass.
You'll dislike it!  Flush #,.



-- JonL --



;;;--------------------------------------------------------------------------

(in-package "USER")

;;; Clean the slate, in case this isn't "first time" processing

(eval-when (eval compile load)
 (fmakunbound 'expose)
 (fmakunbound 'exposure-normality)
 (proclaim '(special markers))
)


;;; Use different marker depending on which situation is relevant.

(eval-when (eval)
  (setq markers '((eval a) (eval b) (eval c)))
)
(eval-when (compile)
  (setq markers '((compile a) (compile b) (compile c)))
)
(eval-when (load)
  (setq markers '((load a) (load b) (load c)))
)


(eval-when (eval compile load)
  (defun expose ()
     `(#,(pop markers) #,(pop markers)))
  (defmacro exposure-normality ()
    (if (member (car (expose)) 
		'((eval a) (compile a) (load a))
		:test #'equal)
	`'normal
	`'abnormal))
)




(eval-when (eval compile load)

(defparameter foo (expose))
(defparameter bar (exposure-normality))

)
;;;--------------------------------------------------------------------------

∂27-Sep-88  0721	CL-Compiler-mailer 	Re: Flush COMPILER-LET?  
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 27 Sep 88  07:21:06 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa04559; 27 Sep 88 14:32 BST
Date: Tue, 27 Sep 88 15:12:02 BST
Message-Id: <26711.8809271412@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Flush COMPILER-LET?
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, 
    sandra <@cs.utah.edu:sandra@defun>
In-Reply-To: Kent M Pitman's message of Mon, 26 Sep 88 16:48 EDT
Cc: cl-compiler@sail.stanford.edu

> I think the intended use is slightly different from the example you gave.
> Here's what I think of as a prototypical example...
> 
>  (DEFVAR *LOCAL-TYPE-DECLARATIONS* '())
>  
>  (DEFMACRO LOCAL-TYPE-DECLARE (DECLARATIONS &BODY FORMS)
>    `(COMPILER-LET ((*LOCAL-TYPE-DECLARATIONS* 
> 		     (APPEND ',DECLARATIONS *LOCAL-TYPE-DECLARATIONS*)))
>       ,@FORMS))
>  
>  (DEFMACRO TYPED-VAR (VAR)
>    (LET ((TYPE (ASSOC VAR *LOCAL-TYPE-DECLARATIONS*)))
>      (IF TYPE `(THE ,(CADR TYPE) ,VAR) VAR)))
>  
>  (DEFUN F (X Y)
>    (LOCAL-TYPE-DECLARE ((X FIXNUM) (Y FLOAT))
>      (+ (TYPED-VAR X) (TYPED-VAR Y))))
>  
> is equivalent to
> 
>  (DEFUN F (X Y) (+ (THE FIXNUM X) (THE FIXNUM Y)))

How about something like this:

   (defun f (z)
     (local-type-declare ((z fixnum))
       #'(lambda () (typed-var z))))

If I then evaluate (F 10), I may get something like this:

   #<%closure ((z 10)) ... more envs ... () (typed-var z)>

(TYPED-VAR Z) won't be expanded until I finally call this closure,
but by then the COMPILER-LET bindings have long since gone.

I think it was Cris Perdue who brought up this case in one of the
CL-Compiler meetings.

> You can do the same thing with MACROLET, but it feels quite awkward.

But it works.

> In my opinion, the only thing that makes COMPILER-LET feel bad is the
> stubborn refusal for interpreted-only implementations to do a semantic
> prepass. This is what forces you to do a special-bind at runtime. If
> COMPILER-LET did a special-bind only at conceptual compile time (i.e.,
> semantic pre-pass for interpreted code), it would not seem nearly so
> nasty because it wouldn't interfere unpredictably with runtime bindings.

What's required for the example above is for every interperter (not
just interpreter-only implementations) to do a semantic prepass.

-- Jeff

∂27-Sep-88  0821	CL-Compiler-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 27 Sep 88  08:21:19 PDT
Received: by ti.com id AA19764; Tue, 27 Sep 88 10:18:18 CDT
Received: from Kelvin by tilde id AA11319; Tue, 27 Sep 88 10:02:38 CDT
Message-Id: <2800364526-11661307@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 27 Sep 88  10:02:06 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@LUCID.COM>
Cc: sandra%defun@CS.UTAH.EDU, cl-compiler@SAIL.STANFORD.EDU
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
In-Reply-To: Msg of Mon, 26 Sep 88 21:52:09 PDT from Jon L White <jonl@LUCID.COM>

>    [By the way, shouldn't the Interlisp 
> precedent bias us towards the name LOAD-TIME-CONSTANT rather than towards 
> LOAD-TIME--EVAL?].

That's LOAD-TIME-VALUE; we don't want the word "constant" in it because
they aren't really constants.

> However, a more serious issue seems to have gotten lost in all the flaming.
> At Lucid, we all seem to favor flushing #,.  Who really wants it? 

I do for one.  We are using an equivalent of LOAD-TIME-VALUE in our
implementation of CLOS, and I see no reason to not make that feature
available to users. 

> There is a serious flaw in the design of #, and for this reason alone
> it should be flushed

The problem that you describe seems to be an argument against proposal
LOAD-TIME-EVAL:QUOTED-MAGIC-TOKEN and in favor of proposal
LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM, since I believe that the latter
proposal corrects your problem.

>    The 
> burden of _proof_ to show that any reasonable program is seriously 
> hampered without it is on those who invoke the argument. 

I thought that Pitman already did a good job of showing why #, is needed.

  -- David Gray

∂27-Sep-88  0851	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 27 Sep 88  08:51:03 PDT
Received: by ti.com id AA19943; Tue, 27 Sep 88 10:47:59 CDT
Received: from Kelvin by tilde id AA12095; Tue, 27 Sep 88 10:35:51 CDT
Message-Id: <2800366544-11782552@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 27 Sep 88  10:35:44 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: sandra%defun@cs.utah.edu, CL-Compiler@SAIL.Stanford.edu
Subject: Re: issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)
In-Reply-To: Msg of Sun, 25 Sep 88 16:58 EDT from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

>  * For the most part, it doesn't make any sense to do 
>     (DEFUN ... (DEFUN ...)) so it seems strange to encourage it.

I don't think it was the purpose of this proposal to encourage this.  It
is made possible as a side effect of permitting more interesting things
such as (LET (...) (DEFUN ...)).  The Explorer supports non-top-level
DEFUNs but issues a style warning on a DEFUN within a DEFUN saying that
"either there is a right parenthesis missing or you should be using FLET
instead."  In other words, legal, but not encouraged.

∂27-Sep-88  0918	CL-Compiler-mailer 	Re: Flush COMPILER-LET?  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Sep 88  09:18:34 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 466337; Tue 27-Sep-88 12:15:41 EDT
Date: Tue, 27 Sep 88 12:15 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Flush COMPILER-LET?
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu,
    CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: <26711.8809271412@subnode.aiai.ed.ac.uk>
Message-ID: <880927121530.9.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Tue, 27 Sep 88 15:12:02 BST
    From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>

    How about something like this:

       (defun f (z)
	 (local-type-declare ((z fixnum))
	   #'(lambda () (typed-var z))))

    If I then evaluate (F 10), I may get something like this:

       #<%closure ((z 10)) ... more envs ... () (typed-var z)>

    (TYPED-VAR Z) won't be expanded until I finally call this closure,
    but by then the COMPILER-LET bindings have long since gone.

    I think it was Cris Perdue who brought up this case in one of the
    CL-Compiler meetings.

Only happens in interpreted-only implementations which have no
semantic pre-pass. Why am I not surprised? Sigh...
This case is certainly interesting, but I have a different reading
on what should be done about it.

A very major failing of COMPILER-LET is that it was described operationally
not intentionally, and no good examples of an intended use were given. My
reading of the mail recently is that different people have focussed on
different aspects of its operational definition and regard the aspects they
don't care about as peculiar. If I agreed with the purposes which some have
inferred, I too would be lobbying to have it flushed.

Instead, however, I think we should examine it for its purpose -- which is
to provide convenient cooperation between macros. Given that purpose, I think
it would be interesting to look at how we might fix the operational description
in order to let the example work. One way would be to require such
implementations to close over COMPILER-LET bindings which are lexically visible
to the closure [other COMPILER-LET bindings may be dynamically visible, but are
spurious]. I haven't done a detailed study of that to see if it would work
in complex recursive situations, and I also don't know how hard it would be
to implement that in practice.

    > You can do the same thing with MACROLET, but it feels quite awkward.

    But it works. ...

If you can think of it. I guess I think it's such a radical trick that
average programmers will never think of. 

Issues of caching and side-effects aside, it's like telling programmers they
don't need lexical variables because they can always use FLET....

 (let ((x (cons 3 x))) ...x...) => (flet ((x () (cons 3 (x)))) ...(x)...)

It's yucky because it doesn't let you say what you really mean. You get so 
caught up in mechanism that you lose the expressional abstraction a variable
provides. Further, it's harder than this example because of the need to use
explicit MACROEXPAND and an ENV argument.

It's not that I think average programming problems should need this facility,
but I do think that an average programmer given an unusual programming problem
requiring it should be able to come up with the solution. Assuming COMPILER-LET
was made to work reliably (including the situation described above) and a
reasonable example was provided, I think that an avarage programmer could
think it out. Perhaps I have a dim view of programmers, but in my experience
the average programmer has a hard time with &ENVIRONMENT even in
straightforward situations, much less obscure ones like the example I provided.

Also, the MACROLET version doesn't deal with the issue of side-effects. Offhand
I see now way to use MACROLET to simulate a situation which uses COMPILER-LET
and where a compiler-let variable is re-assigned (by SETQ) in a contained macro
call. The kind of macro where you'd do that would be 

 (WITH-MY-STICKY-DECLARATIONS
   (+ (MY-THE FIXNUM X) (MY-SQRT X)))

where MY-THE might be like THE, but it could push onto a list of declarations
maintained by WITH-MY-STICKY-DECLARATIONS so that MY-SQRT could be a macro that
knew X was a FIXNUM.

∂27-Sep-88  0937	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Sep 88  09:37:18 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 466349; Tue 27-Sep-88 12:34:58 EDT
Date: Tue, 27 Sep 88 12:34 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)
To: Gray@DSG.csc.ti.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu,
    CL-Compiler@SAIL.Stanford.edu
In-Reply-To: <2800366544-11782552@Kelvin>
Message-ID: <880927123446.1.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Tue, 27 Sep 88  10:35:44 CDT
    From: David N Gray <Gray@DSG.csc.ti.com>

    >  * For the most part, it doesn't make any sense to do 
    >     (DEFUN ... (DEFUN ...)) so it seems strange to encourage it.

    I don't think it was the purpose of this proposal to encourage this.  It
    is made possible as a side effect of permitting more interesting things
    such as (LET (...) (DEFUN ...)).  The Explorer supports non-top-level
    DEFUNs but issues a style warning on a DEFUN within a DEFUN saying that
    "either there is a right parenthesis missing or you should be using FLET
    instead."  In other words, legal, but not encouraged.

I'm down on the idea of adding new functionality and then suggesting
people don't use it. I'm especially down on the idea of interesting new
code without intent to encourage it and without telling people that fact.
If it's not encouraged, the proposal should state that fact clearly.
And it should give a clear metric of exactly where the boundary is and why.

Nothing bugs me more than warnings about valid code. I often find myself
irritated even by "bound but not used" warnings. Although the IGNORE
declaration is present, nothing I know about in CLtL suggests that if
I fail to use it, I should be forced to endure such warnings. Some 
implementations also warn about usages that are fine for portable CL
but are incompatible with local cultural norms. That bugs me, too, but
it seems to be so widespread that I can't make a credible case for it
being a bug.

I write something in one implementation and it works fine, but then move to
another and though it still works fine, it's unpleasant to compile because
I can't see the -real- warnings the compiler might have issued through
all the gratuitous ones. This was a serious problem when I was doing
Macsyma ports a while back.

∂27-Sep-88  1030	CL-Compiler-mailer 	Re: COMPILER-LET    
Received: from gremlin.nrtc.northrop.com by SAIL.Stanford.EDU with TCP; 27 Sep 88  10:29:58 PDT
Received: from tribble by gremlin.nrtc.northrop.com id aa03839;
          27 Sep 88 10:27 PDT
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: common-lisp@sail.stanford.edu, cl-compiler@sail.stanford.edu,
    jbarnett@gremlin.nrtc.northrop.com
Subject: Re: COMPILER-LET 
In-reply-to: Your message of Mon, 26 Sep 88 13:36:01 -0600.
             <8809261936.AA05384@defun.utah.edu> 
Date: Tue, 27 Sep 88 10:27:47 -0700
From: jbarnett@gremlin.nrtc.northrop.com


I want to reply to your comments that COMPILER-LET is (1) ugly and confusing,
(2) rarely used, and (3) can be replaced with MACRO-LET.  The second point is
probably true.  As to the other points I wish to disagree.  As to the first
point: I was delighted to see COMPILER-LET in the language because it was the
obvious clean LISPish way to gain a lot of useful capability for compilers and
extentions layered on top of LISP.

The method that you showed of using MACRO-LET doesn't really work very well.
There is a strategy that will work but it is a real croc:  A macro that was
going to output the COMPILER-LET wrapper outputs a MACRO-LET that includes a
local macro that produces the quoted of the value that would have been bound to
the special variable.  A macro that wishes to consume that value must pass a
form like (LOCAL-MACRO-NAME) to EVAL along with an environment pointer.

∂27-Sep-88  1030	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)    
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 27 Sep 88  10:30:00 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA02046; Tue, 27 Sep 88 13:29:45 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA19468; Tue, 27 Sep 88 13:31:31 EDT
Message-Id: <8809271731.AA19468@mist.UUCP>
To: Kent M Pitman <KMP%STONY-BROOK.SCRC.Symbolics.COM@multimax>
Cc: CL-Compiler%SAIL.Stanford.edu@Multimax
Subject: Re: issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4) 
In-Reply-To: Your message of Tue, 27 Sep 88 12:34:00 -0400.
             <880927123446.1.KMP@GRYPHON.SCRC.Symbolics.COM> 
Date: Tue, 27 Sep 88 13:31:28 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    I write something in one implementation and it works fine, but then move to
    another and though it still works fine, it's unpleasant to compile because
    I can't see the -real- warnings the compiler might have issued through
    all the gratuitous ones. This was a serious problem when I was doing
    Macsyma ports a while back.
    
I agree, in all languages I've programmed in there are many warnings
which almost always point to a real bug.  Compilers that insist on
emitting a large mass of irrelevant warnings either obscure the
important warnings or, worse yet, lead people to compiling with
warnings disabled (and _that_ leads to really expensive later
debugging). 

As the original inciter of this topic, I will be very disappointed if
my original desire to have DEFUN, DEFVAR, etc. explicitly allowed
inside of LET is rejected because it was made part of a more
elaborate (and I think better overall) proposal that was shot down.

∂27-Sep-88  1031	CL-Compiler-mailer 	Re: issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)    
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 27 Sep 88  10:28:48 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa05336; 27 Sep 88 16:06 BST
Date: Tue, 27 Sep 88 16:45:48 BST
Message-Id: <27184.8809271545@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, 
    sandra <@cs.utah.edu:sandra@defun>
In-Reply-To: Kent M Pitman's message of Sun, 25 Sep 88 16:58 EDT
Cc: cl-compiler@sail.stanford.edu

Kent -- according to my mailer here, your message went to X3J13
instead of Cl-Compiler.

> Since this proposal is apparently (although not explicitly) dependent on
> your EVAL-WHEN-NON-TOP-LEVEL:CLARIFY, and since I don't support that
> proposal, it shouldn't come as a surprise that I can't support this one.

>  * For the most part, it doesn't make any sense to do 
>     (DEFUN ... (DEFUN ...)) so it seems strange to encourage it.
>    The only practical reason I can think of for doing this is to do
>    some sort of module facility where you selectively activate definitions
>    that you need by calling the outer function. I think this is what
>    LOAD and packages are already in CL for, and although I don't think they
>    are the answer to all the world's problems, they are better than
>    doing nested defuns.

While it is true that (DEFUN ... (DEFUN ...)) is strange, and doesn't
do anything that anyone is likely to want (i.e., selectively activate
definitions), DEFUN inside LET, FLET, or LABELS is less strange and is
(I think) useful.  Indeed, page 67 says what DEFUN means in non-null
lexical environments.

[LABLES inside DEFUN defines one global function with several locals;
DEFUN inside LABELS defines more than one global function with the
same locals.  I'm inclined to think that if the first is reasonable
the second is too.]

Of course, you might define "top level" to mean "not inside a defining
form".  That would more or less rule out the cases you dislike while
leaving the more useful ones.

But there would still be a consistency problem, namely that macros
and functions can be defined inside defining forms by doing a SETF
of SYMBOL-FUNCTION or MACRO-FUNCTION.  So the question is: why let
people do this only "by hand"?  Why not let them use DEFUN and friends?

BTW, one reason to do a DEFUN inside a DEFUN is to get a DEFUN inside
some other forms and make sure the whole thing is compiled properly.
The outer DEFUN is then called once to set everything up.  If
implementations could be relied on to take non-top-level DEFUN
seriously (i.e., if the 2nd paragraph of section 5.2 (page 66) 
were changed), this peculiar technique would probably vanish
from the world.

>  * The Scheme language attaches a very different meaning to 
>     (DEFUN FOO (X)
>       (DEFUN BAR (X) ...) ... (BAR ...) ...)

True.  Interesting enough, I asked the CL list about this a few
years ago.  I wondered why CL didn't do the same thing as Scheme.
(After all, most languages that allow local procedures use the
same defining syntax that they do for top-level procedures.)
The answer was that DEFUN (to define a global function) inside
LET was useful, much used, etc.

> I would prefer that defining forms just be restricted to toplevel
> because we don't have time in the next three months to do any better
> than that.

Well, for DEFUN we can favor page 67 over page 66.  That conflict
should be resolved in any case.

That's how we got into this, isn't it?  Fix DEFUN.  Then: why not
DEFMACRO too?

-- Jeff

∂27-Sep-88  1039	CL-Compiler-mailer 	Re: COMPILER-LET    
Received: from gremlin.nrtc.northrop.com by SAIL.Stanford.EDU with TCP; 27 Sep 88  10:38:58 PDT
Received: from tribble by gremlin.nrtc.northrop.com id aa03860;
          27 Sep 88 10:37 PDT
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: common-lisp@sail.stanford.edu, cl-compiler@sail.stanford.edu,
    jbarnett@gremlin.nrtc.northrop.com
Subject: Re: COMPILER-LET 
In-reply-to: Your message of Mon, 26 Sep 88 13:36:01 -0600.
             <8809261936.AA05384@defun.utah.edu> 
Date: Tue, 27 Sep 88 10:37:09 -0700
From: jbarnett@gremlin.nrtc.northrop.com


Sorry, the mailer and I weren't coordinated and the first half of this slipped
away.

The point of the first half is that if you wanted to COMPILER-LET several 
variables that were consumed by the same macro, the combinatorics of your
solution would be bad news.  Further, in your solution, the scope is wrong.
In general, COMPILER-LET and MACRO-LET, will appear semi-independently and if
both are used the nesting order is critical.

In any event, I hope that COMPILER-LET remains in the language. I have found it
an easy and natural construct to use for implementing various language 
extentions.  In addition, it seems that it should be trivial to make EVALed
forms enjoy the same semantics that the compiler proffers.

∂27-Sep-88  1148	CL-Compiler-mailer 	compiler-let, again 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 27 Sep 88  11:48:26 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA16943; Tue, 27 Sep 88 12:46:54 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA06101; Tue, 27 Sep 88 12:46:48 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809271846.AA06101@defun.utah.edu>
Date: Tue, 27 Sep 88 12:46:46 MDT
Subject: compiler-let, again
To: cl-compiler@sail.stanford.edu
Cc: kmp@stony-brook.scrc.symbolics.com

Here is an alternate way to handle Pitman's COMPILER-LET example using
MACROLET.  It is somewhat cleaner than the solution Pitman suggested
because it doesn't need to pass environments around or do explicit
macroexpansion. 

(defmacro local-type-declare (declarations &body forms)
    (local-type-declare-aux declarations forms))

(eval-when (eval compile load)
    (defun local-type-declare-aux (declarations forms)
	`(macrolet ((typed-var (var)
			(let ((type  (assoc var ',declarations)))
			    (if type `(the ,(cadr type) ,var) var)))
		    (local-type-declare (new-declarations &body new-forms)
			(local-type-declare-aux
			    (append new-declarations ',declarations)
			    new-forms)))
	     ,@forms)))

I could have avoided the EVAL-WHEN and the helper function by using
LABELS instead.

-Sandra
-------

∂27-Sep-88  1207	CL-Compiler-mailer 	Re: Flush COMPILER-LET?  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 27 Sep 88  12:07:04 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA17373; Tue, 27 Sep 88 13:04:42 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA06116; Tue, 27 Sep 88 13:04:39 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809271904.AA06116@defun.utah.edu>
Date: Tue, 27 Sep 88 13:04:38 MDT
Subject: Re: Flush COMPILER-LET?
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: jeff%aiai.edinburgh.ac.uk@nss.cs.ucl.ac.uk,
        KMP@stony-brook.scrc.symbolics.com, sandra%defun@cs.utah.edu,
        CL-Compiler@sail.stanford.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 27 Sep 88 12:15 EDT

> Date: Tue, 27 Sep 88 12:15 EDT
> From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
> 
> 
> Also, the MACROLET version doesn't deal with the issue of
> side-effects. Offhand I see now way to use MACROLET to simulate a
> situation which uses COMPILER-LET and where a compiler-let variable is
> re-assigned (by SETQ) in a contained macro call. The kind of macro
> where you'd do that would be
> 
>  (WITH-MY-STICKY-DECLARATIONS
>    (+ (MY-THE FIXNUM X) (MY-SQRT X)))
> 
> where MY-THE might be like THE, but it could push onto a list of
> declarations maintained by WITH-MY-STICKY-DECLARATIONS so that MY-SQRT
> could be a macro that knew X was a FIXNUM.

This may or may not work anyway, even if COMPILER-LET is used.  Our
proposal for DEFINING-MACROS-NON-TOP-LEVEL explicitly states that you
can't depend on subforms being processed in the same order they appear
textually.  (This is to allow the compiler to perform certain kinds of
source-to-source transformations.) You can't rely on the MY-THE being
expanded before the MY-SQRT unless you have WITH-MY-STICKY-DECLARATIONS 
do its own code walk. 

-Sandra
-------

∂27-Sep-88  1221	CL-Compiler-mailer 	Re: COMPILER-LET    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 27 Sep 88  12:20:57 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA17953; Tue, 27 Sep 88 13:19:31 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA06137; Tue, 27 Sep 88 13:19:22 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809271919.AA06137@defun.utah.edu>
Date: Tue, 27 Sep 88 13:19:20 MDT
Subject: Re: COMPILER-LET 
To: jbarnett@gremlin.nrtc.northrop.com
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
        common-lisp@sail.stanford.edu, cl-compiler@sail.stanford.edu,
        jbarnett@gremlin.nrtc.northrop.com
In-Reply-To: jbarnett@gremlin.nrtc.northrop.com, Tue, 27 Sep 88 10:37:09 -0700

> Date: Tue, 27 Sep 88 10:37:09 -0700
> From: jbarnett@gremlin.nrtc.northrop.com
> 
> if you wanted to COMPILER-LET several 
> variables that were consumed by the same macro, the combinatorics of your
> solution would be bad news.  

I don't think so.  The problem comes in when you have several variables
that are used by several macros.

> Further, in your solution, the scope is wrong.

Could you please explain why you think the scoping is "wrong"?  

> In any event, I hope that COMPILER-LET remains in the language. I have found it
> an easy and natural construct to use for implementing various language 
> extentions.

I would like to see some actual examples of how you've been using it in
real code.  All the ones we've dealt with so far have been artificially 
contrived.

> In addition, it seems that it should be trivial to make EVALed
> forms enjoy the same semantics that the compiler proffers.

Actually not.  As we've already discussed on the cl-compiler mailing
list, it would require all implementations to have their interpreters
do a code-walking prepass to perform macroexpansion, instead of
allowing macroexpansion to be performed in parallel with evaluation.
Some implementations do work that way already, but the change for the
rest would hardly be "trivial".

-Sandra
-------

∂27-Sep-88  1250	CL-Compiler-mailer 	Re: Flush COMPILER-LET?  
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 27 Sep 88  12:48:29 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa06411; 27 Sep 88 18:27 BST
Date: Tue, 27 Sep 88 19:06:00 BST
Message-Id: <27418.8809271806@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Flush COMPILER-LET?
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>
Cc: sandra <@cs.utah.edu:sandra@defun>, CL-Compiler@sail.stanford.edu

>     (TYPED-VAR Z) won't be expanded until I finally call this closure,
>     but by then the COMPILER-LET bindings have long since gone.
> 
> Only happens in interpreted-only implementations which have no
> semantic pre-pass. Why am I not surprised? Sigh...

I agree with you there (that a pre-pass eliminates the problem).  I'm
not sure why you say "interpreted-only implementations", though.  Lisps
that have a compiler can still have this problem in their interpreter.

>   > You can do the same thing with MACROLET, but it feels quite awkward.
> 
>   But it works. ...
> 
> If you can think of it. I guess I think it's such a radical trick that
> average programmers will never think of.

Well, I had to do something like this recently.  I wrote it with
COMPILER-LET and, since the Lisp I used lacked a pre-pass in its
interpreter, it didn't work.  So I tried MACROLET in various ways.
The COMPILER-LET solution was certainly easier to discover.

> It's yucky because it doesn't let you say what you really mean. You get so 
> caught up in mechanism that you lose the expressional abstraction a variable
> provides. Further, it's harder than this example because of the need to use
> explicit MACROEXPAND and an ENV argument.

That's what I did too (use MACROEXPAND and &ENVIRONMENT).  But I decided
it was too yucky and eventually hit on the following variation:

 (defmacro local-type-declare (declarations &body forms)
   (expand-local-type-declare '() declarations forms))

 (defmacro typed-var (var)
   (error "TYPED-VAR [of ~S] must be in a LOCAL-TYPE-DECLARE." var))

 (defun expand-local-type-declare (nest declarations forms)
   (let ((nested-declarations (append declarations nest)))
     `(macrolet
	  ((local-type-declare (declarations &body forms)
             (expand-local-type-declare 
               ',nested-declarations declarations forms))
           (typed-var (var)
             (let ((type (assoc var ',nested-declarations)))
               (if type `(the ,(cadr type) ,var) var))))
        ,@forms)))

> Assuming COMPILER-LET was made to work reliably (including the situation
> described above) and a reasonable example was provided,

I wouldn't want to flush it if it could be made to work reliably.
But what if it can't?

> Also, the MACROLET version doesn't deal with the issue of side-effects.
> Offhand I see no way to use MACROLET to simulate a situation which uses
> COMPILER-LET and where a compiler-let variable is re-assigned (by SETQ)
> in a contained macro call. The kind of macro where you'd do that would be 
> 
>  (WITH-MY-STICKY-DECLARATIONS
>    (+ (MY-THE FIXNUM X) (MY-SQRT X)))
> 
> where MY-THE might be like THE, but it could push onto a list of
> declarations maintained by WITH-MY-STICKY-DECLARATIONS so that MY-SQRT
> could be a macro that knew X was a FIXNUM.

Would something like the following suffice?

 (defmacro with-my-sticky-declarations (&body forms)
   (let ((place (gensym)))
     `(macrolet
	  ((my-the (type var)
	     (push (list var type) ,place)
	     `(the ,type ,var))
	   (my-sqrt (form)
	     (if (symbolp form)
		 (let ((type (assoc form ,place)))
		   ...)
	       ...)))
	,@forms)))

-- Jeff

∂27-Sep-88  1307	CL-Compiler-mailer 	Re: COMPILER-LET    
Received: from gremlin.nrtc.northrop.com by SAIL.Stanford.EDU with TCP; 27 Sep 88  13:07:46 PDT
Received: from tribble by gremlin.nrtc.northrop.com id aa04128;
          27 Sep 88 13:05 PDT
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: jbarnett@gremlin.nrtc.northrop.com, common-lisp@sail.stanford.edu,
    cl-compiler@sail.stanford.edu
Subject: Re: COMPILER-LET 
In-reply-to: Your message of Tue, 27 Sep 88 13:19:20 -0600.
             <8809271919.AA06137@defun.utah.edu> 
Date: Tue, 27 Sep 88 13:05:46 -0700
From: jbarnett@gremlin.nrtc.northrop.com

Here's an example were COMPILER-LET helps and replacing it with a
MACRO-LET seems rather unnatural.  It is simplified from the
implementation of CLOCKS, a shell that supports multiple distributd
agents, each with its own blackboard.  There is a general language form,
that for the current discussion, we will say looks like
	(VAL THING PNAME)
where THING is either a hypothesis on an agent's blackboard or a
representation of an agent -- some specialized knowledge sources can be
scoped into multiple agents.  The VAL form can be either an odd or even
numbered arg to SETF and either refers to the PNAME property of a
hypothesis or that property on the header of THING's blackboard.  The
access in each case is quite different.  The VAL macro has an
implementation that resembles
(DEFMACRO VAL (THING PNAME)
  (IF (MEMBER THING *SCOPED-AGENTS*)
      (EXPAND-FOR-AGENT THING PNAME)
      (EXPAND-FOR-HYPOTHESIS THING PNAME)))
Further, there is a language form that enables specialized knowledge
sources' accesses to multiple agents:
(DEFMACRO WITH-SCOPED-AGENT (AGENT &BODY BODY)
  `(COMPILER-LET((*SCOPED-AGENTS* (CONS ',AGENT *SCOPED-AGENTS*)))
     ,@BODY))
Of course there is a top-level definition like
(DEFVAR *SCOPED-AGENTS* NIL)
There doesn't seem to be anything unclear or arcane about the above.
Further, if the expansion of VAL depends upon other things that are
context dependent (it does), it is hard to think of a cleaner
implementation tool that is independent of the implementation of the
underlying LISP compiler.

As to the question of making EVAL and the compiler compatible, I must
admit that I haven't written a CL system so I may be wrong in saying
that it is easy but two approaches immediately suggest themselves:  The
first is that EVAL should just compile its argument, execute it and mark
it for the GC.  This is what I always did in the LISPs that I
implemeneted and the gain in compatibility was a joy.  The second
approach is for those who find the first suggestion fatuous.

In point of fact, an EVAL function for CL must keep around an
environment object -- else how can it know which variables are lexical
and know which operators are really lexical macros?  Why not just put
the COMPILER-LETed special variables in the environemnt object--marked
as such--then PROGV or PROGW them exactly around EVAL's macro expansion
activity.  How could this possibly be a large change to current
implementations?

∂27-Sep-88  1410	CL-Compiler-mailer 	Re: COMPILER-LET    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 27 Sep 88  14:10:49 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA21638; Tue, 27 Sep 88 15:09:25 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA06243; Tue, 27 Sep 88 15:09:18 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809272109.AA06243@defun.utah.edu>
Date: Tue, 27 Sep 88 15:09:17 MDT
Subject: Re: COMPILER-LET 
To: jbarnett@gremlin.nrtc.northrop.com
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
        jbarnett@gremlin.nrtc.northrop.com, cl-compiler@sail.stanford.edu
In-Reply-To: jbarnett@gremlin.nrtc.northrop.com, Tue, 27 Sep 88 13:05:46 -0700

[I've dropped common-lisp from the distribution.]

The example you give is not much different from the contrived example
in my original posting.  Here is one possible way to rewrite it:

(defmacro val (thing pname)
    (val-aux thing pname))

(eval-when (eval compile load)
    (defun val-aux (thing pname)
	(if (member thing *scoped-agents*)
	    (expand-for-agent thing pname)
	    (expand-for-hypothesis thing pname))))

(defmacro with-scoped-agent (agent &body body)
    (labels ((with-scoped-agent-aux (agent body)
		 `(macrolet ((val (thing pname)
				  (let ((*scoped-agents*
					     (cons ',agent *scoped-agents*)))
				      (val-aux thing pname)))
			     (with-scoped-agent (new-agent &body body)
				  (let ((*scoped-agents*
					     (cons ',agent *scoped-agents*)))
				      (with-scoped-agent-aux new-agent body))))
		      ,@body)))
        (with-scoped-agent-aux agent body)))


Alternatively, you can do the same thing without binding up a special
variable at all:

(defmacro val (thing pname)
    (val-aux thing pname nil))

(eval-when (eval compile load)
    (defun val-aux (thing pname scoped-agents)
	(if (member thing scoped-agents)
	    (expand-for-agent thing pname)
	    (expand-for-hypothesis thing pname))))

(defmacro with-scoped-agent (agent &body body)
    (labels ((with-scoped-agent-aux (scoped-agents body)
		 `(macrolet ((val (thing pname)
				  (val-aux thing pname ',scoped-agents))
			     (with-scoped-agent (new-agent &body body)
				  (with-scoped-agent-aux
				      (cons new-agent ',scoped-agents)
				      body)))
		      ,@body)))
        (with-scoped-agent-aux (list agent) body))


> In point of fact, an EVAL function for CL must keep around an
> environment object -- else how can it know which variables are lexical
> and know which operators are really lexical macros?  Why not just put
> the COMPILER-LETed special variables in the environemnt object--marked
> as such--then PROGV or PROGW them exactly around EVAL's macro expansion
> activity.  How could this possibly be a large change to current
> implementations?

That's a very interesting idea.  To put it more formally, you're
suggesting something along the lines of having COMPILER-LET evaluate
the value forms and store the values and variables in the environment
object, and having MACROEXPAND use the information in its environment
argument to actually bind the variables to the values, right?  That
sounds like a reasonable alternative to throwing out COMPILER-LET
entirely, but I do see a couple "gotchas" that would have to be
resolved:

* A nested COMPILER-LET should probably make sure that any bindings
established by an outer COMPILER-LET are available during the evaluation
of its value forms.

* Should the bindings made by COMPILER-LET be seen by any nested EVAL-WHENs?
What should this piece of code do in each of the eval-when situations?

(eval-when (eval compile load)
    (defvar *foo* "outside"))

(compiler-let ((*foo* "inside"))
    (eval-when (eval compile load)
        (print *foo*)))
  
-Sandra
-------

∂27-Sep-88  1502	CL-Compiler-mailer 	Re: COMPILER-LET    
Received: from gremlin.nrtc.northrop.com by SAIL.Stanford.EDU with TCP; 27 Sep 88  15:02:03 PDT
Received: from tribble by gremlin.nrtc.northrop.com id aa04424;
          27 Sep 88 15:00 PDT
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: jbarnett@gremlin.nrtc.northrop.com, cl-compiler@sail.stanford.edu
Subject: Re: COMPILER-LET 
In-reply-to: Your message of Tue, 27 Sep 88 15:09:17 -0600.
             <8809272109.AA06243@defun.utah.edu> 
Date: Tue, 27 Sep 88 14:59:55 -0700
From: jbarnett@gremlin.nrtc.northrop.com

I looked through your ideas about how to get around the use of
COMPILER-LET.  I think and hope that you'll admit that the use of
COMPILER-LET is spectacularly simple compared to your rewrites.  In fact
I had difficulty following them for a while.  Once again, if there is
more than one environment control that must be multiplex in the
expansion of VAL, I think you will have turned a trivial coding task
into one that is horrendous.

In re
	* Should the bindings made by COMPILER-LET be seen by any nested EVAL-WHENs?
	What should this piece of code do in each of the eval-when situations?

	(eval-when (eval compile load)
	(defvar *foo* "outside"))

	(compiler-let ((*foo* "inside"))
	(eval-when (eval compile load)
		(print *foo*)))

My opinion is that "outside" should always be printed.  By the way,
my answer to this is independent of the comments I make below --
its my answer given the current wisdom.  Your point about one
COMPILER-LET's initialization seeing another's is spot on--it should.

There is and has been massive confusion in the community about what
EVAL-WHEN and its arguments should mean.  A (long) while ago, JonL ask
me to write an article on macros for POINTERS, I haven't had the time.
However, when thinking it through, I, at least to my own satisfaction,
decided what all of these things should be.  I simply haven't had time
to write any of it up in a way that would be comprehensible to anyone
but me.  

Some points of interest were that the times were READ, COMPILE, LOAD,
and EXECUTE.  The model assumed that there would be three
transformations, in order, between these four times,  Further, the
EVAL-WHEN form could be meaningfully nested.  Note, to get things right,
EVAL had to mimick this behavior.  In other words something like
``digesting'' lambdas MUST (really must) be done by eval as its compile
pass.  When I said before that EVAL should compile, execute and mark for
GC, I had this in mind.

I don't think that COMPILER-LET is the real problem, it's thinks like
EVAL-WHEN and everybody getting used to lexical scoping.  I want to make
a bet -- those implementors that are having trouble with COMPILER-LET
are (1) having trouble with other scoping issues and (2) have compilers
and interpretors that are incompatible in other ways.  This is just a
bet, I don't know it for a fact.  If you do, let me know if I win or
lose.

∂27-Sep-88  1632	CL-Compiler-mailer 	issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Sep 88  16:32:37 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00501g; Tue, 27 Sep 88 15:29:50 PST
Received: by bhopal id AA05602g; Tue, 27 Sep 88 16:29:22 PDT
Date: Tue, 27 Sep 88 16:29:22 PDT
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8809272329.AA05602@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: Gray@DSG.csc.ti.com, KMP@STONY-BROOK.SCRC.Symbolics.COM,
        sandra%defun@cs.utah.edu, CL-Compiler@SAIL.Stanford.edu
In-Reply-To: Kent M Pitman's message of Tue, 27 Sep 88 12:34 EDT <880927123446.1.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL (Version 4)

    Nothing bugs me more than warnings about valid code. ...
    I can't see the -real- warnings the compiler might have issued through
    all the gratuitous ones. ...

From time to time (daily?) I've wanted a function I mentally call
NOTE, which is similar to WARN but separately controllable, to be used
for presenting benign commentary.  Then observations about cultural
conventions, dead code, useless declarations, failed optimizations,
etc. could all be shunted to a separate stream from those about
variables being free, symbols used previously as functions being
defined as macros, etc.    

I could also then ask for *break-on-warnings* separately from 
*break-on-notes*, and not have to endure 20 spurious breaks to 
get to the real problems...

  jlm

∂27-Sep-88  1926	CL-Compiler-mailer 	compiler errors (was Re: issue DEFINING-MACROS-NON-TOP-LEVEL)    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 27 Sep 88  19:24:35 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA29309; Tue, 27 Sep 88 20:22:51 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA06388; Tue, 27 Sep 88 20:22:44 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809280222.AA06388@defun.utah.edu>
Date: Tue, 27 Sep 88 20:22:43 MDT
Subject: compiler errors (was Re: issue DEFINING-MACROS-NON-TOP-LEVEL)
To: Jim McDonald <jlm@lucid.com>
Cc: KMP@stony-brook.scrc.symbolics.com, Gray@dsg.csc.ti.com,
        CL-Compiler@sail.stanford.edu
In-Reply-To: Jim McDonald <jlm@lucid.com>, Tue, 27 Sep 88 16:29:22 PDT

The status of compiler diagnostics is, in fact, right near the top of
our list of outstanding issues, and something I've been planning to
bring up at our next subcommittee meeting.

The approach I've been thinking of is to define a condition distinct
from warning to be used for compiler diagnostics, now that we have a
condition handling spec.  We also need to consider whether things like
syntax errors, which already have conditions defined that are real
errors and not harmless diagnostics, are still real errors when
they're detected by the compiler and not the interpreter.  I think we
at least need to distinguish between cases where the compiler wasn't
able to compile the function or file, and cases where the compiler is
just complaining about your programming style.

-Sandra
-------

∂27-Sep-88  2254	CL-Compiler-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Sep 88  22:54:03 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00603g; Tue, 27 Sep 88 21:51:53 PST
Received: by bhopal id AA06439g; Tue, 27 Sep 88 22:51:26 PDT
Date: Tue, 27 Sep 88 22:51:26 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809280551.AA06439@bhopal>
To: Gray@DSG.csc.ti.com
Cc: sandra%defun@CS.UTAH.EDU, cl-compiler@SAIL.STANFORD.EDU
In-Reply-To: David N Gray's message of Tue, 27 Sep 88  10:02:06 CDT <2800364526-11661307@Kelvin>
Subject: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM

re:     At Lucid, we all seem to favor flushing #,.  Who really wants it? 
    I do for one.  We are using an equivalent of LOAD-TIME-VALUE in our
    implementation of CLOS, and I see no reason to not make that feature
    available to users. 

You misunderstand.  I was railing against #, -- not at all against the
"new-special-form" proposal, which I supported in a veiled way.


re: I thought that Pitman already did a good job of showing why #, is needed.

and I thought not; certainly the MacLisp experience with "squids" is
irrelevant to any modern Lisp.


-- JonL --

∂28-Sep-88  1120	CL-Compiler-mailer 	Re: COMPILER-LET    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 28 Sep 88  11:19:53 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA16839; Wed, 28 Sep 88 12:18:21 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA06738; Wed, 28 Sep 88 12:17:44 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809281817.AA06738@defun.utah.edu>
Date: Wed, 28 Sep 88 12:17:43 MDT
Subject: Re: COMPILER-LET 
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nss.cs.ucl.ac.uk>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
        cl-compiler@sail.stanford.edu, jbarnett@gremlin.nrtc.northrop.com
In-Reply-To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Wed, 28 Sep 88 19:02:17 BST

I may be confused about LABELS myself.  I didn't actually try to run
that example.

I'm working on a writeup for the COMPILER-LET issue that includes a formal
proposal based on jbarnett's suggestion (along with 3 other proposals).
Stay tuned....

-Sandra
-------

∂28-Sep-88  1121	CL-Compiler-mailer 	Re: COMPILER-LET    
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 28 Sep 88  11:17:06 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa05613; 28 Sep 88 18:22 BST
Date: Wed, 28 Sep 88 19:02:17 BST
Message-Id: <29190.8809281802@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: COMPILER-LET 
To: Sandra J Loosemore <@cs.utah.edu:sandra@defun>
Cc: cl-compiler@sail.stanford.edu, jbarnett@gremlin.nrtc.northrop.com

> (defmacro with-scoped-agent (agent &body body)
>     (labels ((with-scoped-agent-aux (scoped-agents body)
> 		 `(macrolet ((val (thing pname)
> 				  (val-aux thing pname ',scoped-agents))
> 			     (with-scoped-agent (new-agent &body body)
> 				  (with-scoped-agent-aux
> 				      (cons new-agent ',scoped-agents)
> 				      body)))
> 		      ,@body)))
>         (with-scoped-agent-aux (list agent) body))

Um, maybe it's just me, but is this use of LABELS supposed to work?
When I try it here (KCL, Lucid), calls to the local macro die because
the local "-aux" function isn't defined.

> > In point of fact, an EVAL function for CL must keep around an
> > environment object -- else how can it know which variables are lexical
> > and know which operators are really lexical macros?  Why not just put
> > the COMPILER-LETed special variables in the environemnt object--marked
> > as such--then PROGV or PROGW them exactly around EVAL's macro expansion
> > activity.  How could this possibly be a large change to current
> > implementations?

I would like a description in terms of scope and extent.

-- Jeff

∂28-Sep-88  1132	CL-Compiler-mailer 	Issue COMPILER-LET-CONFUSION, version 1 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 28 Sep 88  11:32:20 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA17107; Wed, 28 Sep 88 12:29:58 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA06757; Wed, 28 Sep 88 12:29:42 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809281829.AA06757@defun.utah.edu>
Date: Wed, 28 Sep 88 12:29:41 MDT
Subject: Issue COMPILER-LET-CONFUSION, version 1
To: cl-compiler@sail.stanford.edu
Cc: jbarnett@gremlin.nrtc.northrop.com, kmp@stony-brook.scrc.symbolics.com

Here is a first pass at a writeup for this issue.  I've included four
different proposals which I hope cover all the possibilities.  (I also
hope my writeup is unbiased enough to live up to KMP's exacting
standards!)

As usual, comments and complaints are welcome.

-Sandra



Issue:		COMPILER-LET-CONFUSION
References:	CLtL p. 112
Category:	CHANGE/CLARIFICATION
Edit History:   V1, 27 Sept 1988, Sandra Loosemore (initial version)
Status:		**DRAFT**


Problem Description:

The description of the COMPILER-LET special form in CLtL is confusing
to many people.  There are no examples provided to make it clear how it
is supposed to be used.

The description of how COMPILER-LET works in the interpreter only
makes sense for implementations which perform macroexpansion in
parallel with evaluation.  In an implementation which performs macro
expansion in a prepass and follows CLtL literally in making
COMPILER-LET behave "exactly like LET with all the variable bindings
implicitly declared SPECIAL", it would not work at all for its stated
purpose, "communication among complicated macros".

Subtle bugs can be introduced because of the different handling of the
variable bindings in the interpreter and the compiler.  In compiled
code, the bindings are only lexically visible during the expansion of
macros at compile time, while in interpreted code the bindings have
dynamic scope and may also be seen during ordinary evaluation if
evaluation and macroexpansion happen concurrently.

Further compatibility problems can result from the value forms being
evaluated in a null lexical environment in the compiler and the
ordinary lexical environment in the interpreter.



Proposal COMPILER-LET-CONFUSION:CLARIFY-STATUS-QUO:

  Change the documentation of COMPILER-LET to include more discussion of
  its intended purpose, including examples.
  
  Change the description of COMPILER-LET's behavior in the interpreter
  to indicate that it is not "exactly like LET with all the variable
  bindings implicitly declared SPECIAL".  Instead, clarify that
  processing of COMPILER-LET by the interpreter happens at the same time
  as macroexpansion; the value forms are evaluated sequentially
  in a null lexical environment, bound to the special variables, and
  that these bindings are available during the expansion of macro calls
  in the body.
  
  Mention that there may be compatibility problems between compiled and
  interpreted code if the interpreter performs macroexpansion in
  parallel with evaluation.

  
  Rationale:

  This proposal formalizes what appears to be the behavior of most
  implementations.
  

  Current Practice:
  
  COMPILER-LET is rarely used.
  
  
  Cost to implementors:

  Minimal.

  
  Cost to users:
  
  None.  Any code that would break under the new rules for the interpreted
  behavior of COMPILER-LET would already be broken when compiled.


  Benefits:
  
  The description of COMPILER-LET would make more sense for implementations
  that perform macroexpansion during a prepass in the interpreter.  Some of
  the compatibility problems between interpreted and compiled code would be
  removed.



Proposal COMPILER-LET-CONFUSION:REQUIRE-PREPASS:

  Disallow interpreters from performing macroexpansion concurrently with
  evaluation.  Macroexpansion must be performed in a preprocessing
  codewalk.

  Clarify that COMPILER-LET is processed by the interpreter or compiler
  (the "processor") at the same time that macros are expanded.  The
  processor sequentially evaluates each of the value forms in a null
  lexical environment, and the special variables are bound to these values
  during the expansion of any macro calls in the body.
  

  Rationale:
  
  This proposal forces the interpreter to treat both macroexpansion and
  COMPILER-LET in the same way that the compiler does.
  
  
  Current Practice:
  
  COMPILER-LET is rarely used.
  
  
  Cost to implementors:
  
  For implementations that do not implement their interpreters using a
  prepass, this would be a fairly substantial change.
  
  
  Cost to users:
  
  Strictly speaking, this is a compatible change to the language.  Since
  CLtL makes no guarantees about the time of macroexpansion, any user
  code that depends upon macroexpansion happening concurrently with
  evaluation is nonportable.  Some users, however, dislike
  implementations with preprocessing interpreters, and want to be able
  to freely redefine macros as well as functions.

  
  Benefits:
  
  An area of incompatibility between compiled and interpreted code is
  eliminated.  This proposal would also address some other compatibility
  problems beyond those relating to COMPILER-LET (such as issue
  LOAD-TIME-EVAL).


Proposal COMPILER-LET-CONFUSION:ELIMINATE:

  Remove COMPILER-LET from the language.
  
  
  Rationale:
  
  Some people think that COMPILER-LET is ugly.  Removing it from the
  language is a much simpler solution than an elaborate proposal to
  assign it consistent semantics in the interpreter and compiler.
  
  
  Current Practice:
  
  COMPILER-LET is rarely used.  
  
  
  Cost to implementors:
  
  Minimal.  Implementations could continue to support COMPILER-LET as
  an extension.
  
  
  Cost to users:
  
  People who use COMPILER-LET would have to rewrite their programs to use
  some other construct.  Most uses of COMPILER-LET for communication between
  macros can be handled using MACROLET instead.
  
  I have been able to do this quite easily for all of the examples which I
  have seen so far.  For example:
  
    (defvar *local-type-declarations* '())
     
    (defmacro local-type-declare (declarations &body forms)
      `(compiler-let ((*local-type-declarations* 
                        (append ',declarations *local-type-declarations*)))
         ,@forms))
     
    (defmacro typed-var (var)
       (let ((type (assoc var *local-type-declarations*)))
         (if type `(the ,(cadr type) ,var) var)))
     
    (defun f (x y)
      (local-type-declare ((x fixnum) (y float))
        (+ (typed-var x) (typed-var y))))
     
    
  can be rewritten as:
  
    (defmacro local-type-declare (declarations &body forms)
        (local-type-declare-aux declarations forms))
    
    (eval-when (eval compile load)
        (defun local-type-declare-aux (declarations forms)
    	`(macrolet ((typed-var (var)
    			(let ((type  (assoc var ',declarations)))
    			    (if type `(the ,(cadr type) ,var) var)))
    		    (local-type-declare (new-declarations &body new-forms)
    			(local-type-declare-aux
    			    (append new-declarations ',declarations)
    			    new-forms)))
    	     ,@forms)))
    
    
  The MACROLET versions are usually somewhat more complicated than the
  COMPILER-LET versions, but not substantially so unless there are a large
  number of macros involved.
  
  
  Benefits:
  
  Having one less special form would simplify the language.  An area of
  incompatibility between compiled and interpreted code would be
  eliminated.



Proposal COMPILER-LET-CONFUSION:REDEFINE:

  Clarify the description of COMPILER-LET to emphasize that it is used to
  make bindings of special variables available when macro calls appearing in
  the body are expanded.
  
  Clarify that COMPILER-LET is processed by the interpreter or compiler
  (the "processor") at the same time that macros are expanded.  The
  processor sequentially evaluates each of the value forms in a null
  lexical environment, storing the variable/value pairs in the
  environment.
  
  Extend the description of environment objects captured with &ENVIRONMENT 
  to state that they also contain information about bindings indicated with 
  COMPILER-LET.
  
  Clarify that MACROEXPAND and MACROEXPAND-1 use the information stored in
  the environment argument to actually perform the special bindings of
  the variables to the values.
  
  Clarify that the special bindings indicated by COMPILER-LET are also
  visible during the evaluation of value forms of lexically nested 
  COMPILER-LET constructs.  The special bindings are not present during
  any other compile-time evaluation of the body, such as evaluation of
  (EVAL-WHEN (COMPILE) ...) forms.
  
  
  Rationale:
  
  This proposal provides consistent semantics for COMPILER-LET in both the
  compiler and interpreter.  It will work just as well in interpreters that
  perform macroexpansion in parallel with execution, as in those that perform
  macroexpansion in a prepass.
  
  
  Current Practice:
  
  COMPILER-LET is rarely used.
  
  
  Cost to implementors:
  
  Implementors will have to change their interpreters and compilers to
  have COMPILER-LET store things in the environment.  The representation
  of environment objects may need to change slightly.  Implementations
  in which &ENVIRONMENT does not return a complete environment object
  will have to be changed.  MACROEXPAND and MACROEXPAND-1 will have to
  be changed to rebind the variables from the environment.
  
  
  Cost to users:
  
  User programs that perform code walks may have to be changed; the
  changes would roughly parallel those listed above.

  
  Benefits:
  
  The treatment of this special form by the interpreter is made consistent
  with its treatment by the compiler.




Discussion:

Can any of you implementors who have an interpreter that perform
macroexpansion in a preprocessing phase comment on how you handle
COMPILER-LET?

Proposal COMPILER-LET-CONFUSION:CLARIFY-STATUS-QUO is the alternative
which is the most consistent with current practice and requires the
least change for both implementors and users.  However, it addresses only
some of the problems which can lead to incompatibility between compiled
and interpreted code.

Proposal COMPILER-LET-CONFUSION:REQUIRE-PREPASS would ensure
consistent semantics for macroexpansion as well as processing of
COMPILER-LET.  On the negative side, it is a substantial change for
some implementations.

Proposal COMPILER-LET-CONFUSION:ELIMINATE is by far the simplest
alternative, but it would also has the greatest impact on users.

Proposal COMPILER-LET-CONFUSION:REDEFINE also guarantees consistent
semantics for COMPILER-LET between the interpreter and compiler.  The
disadvantages of this proposal are that COMPILER-LET remains
complicated and potentially confusing, and it requires changes in both
user and system code.
-------

∂28-Sep-88  1154	CL-Compiler-mailer 	Issue COMPILER-LET-CONFUSION, version 1 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Sep 88  11:54:10 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA00865g; Wed, 28 Sep 88 10:51:48 PST
Received: by blacksox id AA00253g; Wed, 28 Sep 88 11:49:17 pdt
Date: Wed, 28 Sep 88 11:49:17 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809281849.AA00253@blacksox>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu, jbarnett@gremlin.nrtc.northrop.com,
        kmp@stony-brook.scrc.symbolics.com
In-Reply-To: Sandra J Loosemore's message of Wed, 28 Sep 88 12:29:41 MDT <8809281829.AA06757@defun.utah.edu>
Subject: Issue COMPILER-LET-CONFUSION, version 1

COMPILER-LET-CONFUSION:REDEFINE can be subverted by a program that
funcalls a macro-function rather than calling MACROEXPAND or
MACROEXPAND-1.  Some restriction would have to be made on calling
macro-functions as part of this proposal.

∂28-Sep-88  1233	CL-Compiler-mailer 	Issue: DEFINE-OPTIMIZER  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Sep 88  12:32:56 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 467194; Wed 28-Sep-88 15:31:39 EDT
Date: Wed, 28 Sep 88 15:31 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFINE-OPTIMIZER
To: CL-Compiler@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <880928153119.0.KMP@GRYPHON.SCRC.Symbolics.COM>

Issue:        DEFINE-OPTIMIZER
References:   None
Category:     ADDITION
Edit history: 28-Sep-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  Often a general functional interface could be bypassed given explicit
  knowledge of the arguments passed. This may happen when the arguments
  are constant (or otherwise inferrable), an argument type is known (eg,
  due to use of THE or DECLARE), or when some particular pattern of
  optional, rest or keyword arguments is apparent.

  Most implementations provide internally for optimization of generalized
  function call interfaces to more specialized ones, but such an
  optimization facility is not provided to Common Lisp users.

  The absence of this facility in a portable fashion means that some
  CL programs run slower than they need to in some implementations.

Proposal (DEFINE-OPTIMIZER:NEW-FACILITY):

  Introduce a facility for declaring compiler optimizations.

  DEFINE-OPTIMIZER name arglist &body forms

   Defines a compiler optimizer for a function named NAME. The arglist
   is treated exactly like the arglist to DEFMACRO, and may include
   &ENVIRONMENT and &WHOLE.

   When the optimizer is invoked, the forms are executed in the context
   of bindings specified by the arglist, and two values are yielded,
   RESULT and VALID-P. (If either of the first or second return value
   is non-NIL, then the first return value is considered valid).

   If the result is valid, it is a form which is preferrable to evaluate
   instead of the indicated call.

  OPTIMIZE-EXPRESSION-1 form env

   Similar to MACROEXPAND-1. Invokes the optimizers for the top level of
   FORM, but does not iterate on the result. Returns two values:
   RESULT and CHANGED-P. 

   Note: If an optimizer returns a result which is not valid,
    OPTIMIZE-EXPRESSION-1 hides the fact by returning FORM,NIL
    rather than NIL,NIL.

  OPTIMIZE-EXPRESSION form env

   Iterates calling OPTIMIZE-EXPRESSION-1 until the CHANGED-P result
   is NIL.

  An implementation must save optimizer definitions created by
  DEFINE-OPTIMIZER in case OPTIMIZE-EXPRESSION is attempted, but is
  not actually required to call OPTIMIZE-EXPRESSION itself. Interpreters,
  for example, may choose to just call the unoptimized form.

Example:

  (PROCLAIM '(INLINE STRING-APPEND-REAL-STRINGS))
  (DEFUN STRING-APPEND-REAL-STRINGS (STRING1 STRING2)
    (CONCATENATE 'STRING (THE STRING STRING1) (THE STRING STRING2)))

  (DEFUN STRING-APPEND (NAME1 NAME2)
    (STRING-APPEND-REAL-STRINGS (STRING NAME2) (STRING NAME2)))

  (DEFUN DECLARED-TYPEP (THING TYPE)
    (AND (NOT (ATOM THING))
	 (EQ (CAR  THING) 'THE)
	 (EQ (CADR THING) TYPE)))

  (DEFUN QUOTED-TYPEP (THING TYPE)
    (AND (NOT (ATOM THING))
	 (EQ (CAR THING) 'QUOTE)
	 (TYPEP (CADR THING) TYPE)))

  (DEFINE-OPTIMIZER STRING-APPEND (NAME1 NAME2)
    (LET ((OPTIMIZE NIL))
      (FLET ((OPTIMIZE-ARGUMENT (ARG)
	       (COND ((OR (TYPEP ARG 'STRING)
			  (DECLARED-TYPEP ARG 'STRING))
		      (SETQ OPTIMIZE T)
		      ARG)
		     ((QUOTED-TYPEP ARG 'STRING)
		      (SETQ OPTIMIZE T)
		      (EVAL ARG))
		     ((DECLARED-TYPEP ARG 'SYMBOL)
		      (SETQ OPTIMIZE T)
		      `(SYMBOL-NAME ,ARG))
		     ((QUOTED-TYPEP ARG 'SYMBOL)
		      (SETQ OPTIMIZE T)
		      (STRING (EVAL ARG)))
		     (T
		      `(STRING ,ARG)))))
	(LET ((ARG1 (OPTIMIZE-ARGUMENT NAME1))
	      (ARG2 (OPTIMIZE-ARGUMENT NAME2)))
	  (WHEN OPTIMIZE
	    (IF (AND (STRINGP ARG1) (STRINGP ARG2))
		(STRING-APPEND-REAL-STRINGS ARG1 ARG2)
		`(STRING-APPEND-REAL-STRINGS ,ARG1 ,ARG2)))))))

  (STRING-APPEND 'FOO 'BAR) => "FOOBAR"

  (LET ((X 'FOO) (Y 'FOO))
    (STRING-APPEND (THE SYMBOL X) (THE SYMBOL Y)))
   => "FOOBAR"

  (OPTIMIZE-EXPRESSION '(STRING-APPEND 'FOO 'BAR))
   => "FOOBAR"

  (OPTIMIZE-EXPRESSION '(STRING-APPEND (THE SYMBOL X) 'BAR))
   => (STRING-APPEND-REAL-STRINGS (SYMBOL-NAME (THE SYMBOL X)) "BAR")

Rationale:

  Many large portable applications expect such a facility on an 
  implementation-specific basis. Others would use one if available.

  Even if implementations don't use the provided optimizers primitively,
  user macros and code-walkers can invoke them, so the facility wouldn't
  be completely useless even in those implementations.

Current Practice:

  Symbolics Genera provides an optimizer facility which is more elaborate
  but not fundamentally incompatible with this facility.

  Many (if not most) serious implementations provide a similar facility.

Cost to Implementors:

  Since the implementation is not required to use this facility, the
  cost of providing the proposed support is very small.

Cost to Users:

  None. This change is upward compatible.

Cost of Non-Adoption:

  Portable code would be slower than necessary in some situations.

Benefits:

  Some existing non-portable code could become portable.

Aesthetics:

  Providing a separate optimizer definition from a main function definition
  makes a possibility that the optimizer and main function could drift out
  of synch. However, most places where this gets used in the first place
  are places where speed is of paramount importance and the programmer is
  willing to invest effort in maintaining things correctly and to accept the
  risk of lossage if s/he fails.

  This is a fairly clean and simple extension which adds significant
  power to the compiler.

Discussion:

  Information about argument type can come from two different sources:
  THE and declarations (via PROCLAIM or DECLARE). The former information
  is portably accessible, the latter is not. While a separate proposal
  for allowing program access to type declarations would be make this
  facility more useful, it is still quite useful without it.

  Some implementations provide a way to provide more than one optimizer
  for the same function. A multiple optimizer facility can be written
  in terms of this simpler facility and vice versa, so the simpler of
  the two facilities is proposed here.

  [Some compilers provide other optimization facilities which allow
  direct optimization to assembly code or machine instructions. I hope
  this wouldn't conflict with that but since I'm not familiar with the
  details of those implementations, I'm not 100% sure. If anyone familiar
  with such systems wants to comment on that, I'd be interested. -kmp]

  Pitman supports this proposal.

∂28-Sep-88  1350	CL-Compiler-mailer 	Re: Issue: DEFINE-OPTIMIZER   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 28 Sep 88  13:50:14 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA21658; Wed, 28 Sep 88 14:48:51 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA06832; Wed, 28 Sep 88 14:48:41 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809282048.AA06832@defun.utah.edu>
Date: Wed, 28 Sep 88 14:48:40 MDT
Subject: Re: Issue: DEFINE-OPTIMIZER
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: CL-Compiler@sail.stanford.edu, KMP@stony-brook.scrc.symbolics.com
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 28 Sep 88 15:31 EDT

I don't have any strong objections to the basic idea here, except that
it makes the language bigger and more complicated (which nobody seems
to care much about anymore).

Some specific comments on the proposal:

* Presumably you want COMPILE-FILE to treat DEFINE-OPTIMIZER like DEFMACRO
  as far as compile-time side effects are concerned.

* Can DEFINE-OPTIMIZER be used to define an alternate expansion for a macro
  as well as a function call?

* I assume that the arglist to DEFINE-OPTIMIZER must be compatible with
  that of the corresponding function; for example, I couldn't do something
  like

      (defun foo (x &rest more-args) ...)
      (define-optimizer foo (x y) ...)

  The proposal should explicitly state that the optimizer must be able
  to parse the argument list of every valid call to its associated function.

* I think there should be stronger wording to emphasize that neither the
  interpreter nor compiler is required to make use of transformations
  defined with DEFINE-OPTIMIZER.

* The example seems unnecessarily complicated.  I think something less
  hairy would serve to explain the construct better.

* I think there should be stronger wording to warn users about invalid
  "optimizations", and that the use of DEFINE-OPTIMIZER can lead to
  semantic differences between compiled and interpreted code.

* Can implementations provide some built-in optimizations for standard
  Common Lisp functions?  If I haven't defined any of my own optimizations,
  am I guaranteed that OPTIMIZE-EXPRESSION is the identity function on
  its argument?

* Is it legal for users to define optimizers for standard Common Lisp
  functions?

-Sandra
-------

∂28-Sep-88  1351	CL-Compiler-mailer 	Re: Issue: DEFINE-OPTIMIZER   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 28 Sep 88  13:51:15 PDT
Received: by ti.com id AA29986; Wed, 28 Sep 88 15:48:25 CDT
Received: from Kelvin by tilde id AA12188; Wed, 28 Sep 88 15:43:09 CDT
Message-Id: <2800471381-1566229@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 28 Sep 88  15:43:01 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Compiler@SAIL.Stanford.EDU
Subject: Re: Issue: DEFINE-OPTIMIZER
In-Reply-To: Msg of Wed, 28 Sep 88 15:31 EDT from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

> Proposal (DEFINE-OPTIMIZER:NEW-FACILITY):
> 
>   Introduce a facility for declaring compiler optimizations.
> 
>   DEFINE-OPTIMIZER name arglist &body forms

I assume you meant to say that this is a macro rather than a function.

> Current Practice:
...
> Cost to Implementors:

The Explorer's optimization facility is close enough to this that I could
implement the DEFINE-OPTIMIZER macro without having to make any changes to
the compiler.

>   Information about argument type can come from two different sources:
>   THE and declarations (via PROCLAIM or DECLARE).

There is a third source -- certain functions are known to always return a
particular type.  For example, the result of SYMBOL-NAME is always a
string.  Or maybe you intended that to be included in declarations of
functions?

>        While a separate proposal
>   for allowing program access to type declarations would be make this
>   facility more useful, it is still quite useful without it.

The problem with accessing type information from a user-written optimizer
is that it is much easier for the compiler to recognize the type of a form
after it has done certain processing on it (including macro expansion,
source-level optimization, value propagation, and constant folding) than
when looking at raw source.  Consequently, optimizations that depend on
the types of the arguments are most effectively done in a bottom-up
manner.  An optimizer working at that level can't be portable because it
is dealing with the peculiarities of partially compiled code.
Consequently, rather than provide a way for user-written optimizers to
access type declarations, we have a macro which will cause bottom-up
optimization to do simple transformations based on the types of the
arguments.  For example, part of your example can be done by
  (COMPILER:OPTIMIZE-PATTERN (STRING-APPEND STRING STRING)
                             (STRING-APPEND-REAL-STRINGS 1 2))
which says to replace a call to STRING-APPEND with two arguments which are
both known to be strings with a call to STRING-APPEND-REAL-STRINGS using
the same arguments.  I'm not suggesting this for standardization, but I
think this approach could be more reliably portable than a programmatic
interface to type declarations.

∂28-Sep-88  1444	CL-Compiler-mailer 	summary of issues   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 28 Sep 88  14:44:09 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA24089; Wed, 28 Sep 88 15:42:47 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA06870; Wed, 28 Sep 88 15:42:43 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809282142.AA06870@defun.utah.edu>
Date: Wed, 28 Sep 88 15:42:42 MDT
Subject: summary of issues
To: cl-compiler@sail.stanford.edu

In case any of you have gotten buried under all the mail that's been
flying back and forth within the past week or so, here is a revised
summary of our pending issues.  I hope I have not misrepresented or
totally forgotten about anybody's comments.

-Sandra



X3J13 Compiler Cleanup Status as of 28 Sep 1988:
================================================


Old issues (distributed for comments at the June meeting), ready to be
voted upon:

    COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
	What are the compile-time side-effects of the various defining
	macros?

        Comments received after the proposal was distributed again for
        a vote at the October meeting:

        * Gray raised more concerns about handling of DEFCONSTANT.
          He has volunteered to write this up as a separate issue.

	* Pitman raised numerous objections to the wording of the
	    proposal.
          We expect to work with the editorial committee to resolve
	    this.


    EVAL-WHEN-NON-TOP-LEVEL
	What does EVAL-WHEN mean when it does not appear as a top-level
	form?

        Comments received after the proposal was distributed again for
        a vote at the October meeting:

        * Benson pointed out that the sample implementation for
            EVAL-WHEN won't work if the EVAL-WHEN macro is run 
	    interpretively; instead of using the special variable
	    *COMPILING-P*, the information should be stored in the 
            environment instead.
          See issue COMPILE-FILE-ENVIRONMENT below.  We can work with
	    the editorial committee on the wording in the standard.

	* What does EVAL-WHEN do in a compiled-only implementation?
	  This issue needs to be addressed but I think it is largely
	    orthogonal to the issue of where EVAL-WHEN can appear.  I
	    think it could be handled by a separate proposal.

        * Pitman raised objections to the wording of the proposal.
	  We can address this with the help of the editorial committee.

	* Pitman and Kempf raised general objections to allowing
	    EVAL-WHEN in non-top-level places.  



    DEFINING-MACROS-NON-TOP-LEVEL
	Can defining macros such as DEFUN appear in non-top-level
	locations?

        This issue provoked the only comments that were received since
	the last meeting:

	* The wording of section 4 was garbled.
	  This has been fixed in the latest version of the proposal.

	* Many implementations do not allow a lexical environment to be
	    shared between compiled and interpreted functions.
	  A new issue, COMPILE-ARGUMENT-PROBLEMS, has been written up
	    to deal with this problem.

	* Forms within a COMPILER-LET and the expansion of a top-level
	    macro should also be considered top-level.
	  This has been fixed.

        Comments received after the proposal was distributed again for
        a vote at the October meeting:

	* The motivation for Section 5 of the proposal was unclear to
	    some people.
	  This section was added to allow compilers to perform certain
	    kinds of source-to-source transformations that rearrange
	    subforms.  We will provide some examples to the editorial
	    committee.

	* Pitman says that it is inconsistent for (DEFUN FOO ...
	    (DEFMACRO BAR ...)) to make the definition of BAR available
	    immediately at compile time, but only after FOO is called
	    at runtime.
	  That's life.  People expect macro definitions made with DEFMACRO
	    to be available at compile time; it would be just as inconsistent
	    to make them available some times but not others.

	* Pitman says that this proposal would encourage people to try
	    using DEFUNs nested inside of other DEFUNs, thinking that the
	    nested DEFUNs will create local functions (as in Scheme), and
	    end up getting very confused.  He would prefer to restrict
	    defining macros to appearing only at top-level.
	  We will work with the editorial committee to make sure that the
	    standards document emphasizes that DEFUN always establishes
	    a global function definition, no matter where it appears.



New issues that are ready to be voted upon:

    COMPILE-ARGUMENT-PROBLEMS
	What functions can be compiled with COMPILE?

	* Pitman thinks it should not be an error to try to compile a
	    function that is already compiled, particularly since an
	    implementation might compile all functions.
	  We need to revise the error terminology anyway to make it
	    conform to what the editorial committee is using.  Would
	    it be acceptable to state that the behavior is "unspecified"
            (unpredictable but harmless)?


    COMPILE-FILE-PACKAGE
	COMPILE-FILE should rebind *PACKAGE*.

	* Pitman supports this proposal but would like to change the 
	    wording to state that *PACKAGE* is rebound to its current
	    value.


    OPTIMIZE-DEBUG-INFO
	What OPTIMIZE quality controls debuggability of compiled code?

	* Pitman suggests leaving out references to absolute magnitudes
	    of OPTIMIZE qualities, pending discussion of whether it is
	    absolute magnitude or relative value compared to other qualities
	    that is significant.
	  This issue has been on our list but no one has volunteered to
	    write a proposal on it yet.


    PROCLAIM-INLINE-WHERE
	INLINE proclamations should be placed before the corresponding
	DEFUN.

	* Pitman expressed support for this proposal.


Issues in draft form (comments requested):

    COMPILE-ENVIRONMENT-CONSISTENCY (Loosemore)
	What things can the compiler safely "wire in" to code being
	compiled?

        * Benson suggests adding a condition to explicitly allow the
	    compiler to make assumptions based on FTYPE declarations.
	  This is a good idea, but I'm not aware if we've ever resolved
	    whether an FTYPE declaration must match exactly the definition
	    of the function, or whether it only needs to match calls to
	    the function within the scope of the declaration.  For example,
	    is it legal to declare + as taking two FIXNUM arguments?
	

    PROCLAIM-ETC-IN-COMPILE-FILE (Gray)
	Add PROCLAIM, REQUIRE to list of N random package functions that
	COMPILE-FILE must eval at compile time.

	If DEFPACKAGE is accepted, we may want to take a different
	approach on this issue.  How would people feel about
	eliminating the special behavior of these functions entirely?


    ALLOW-LOCAL-INLINE  (Gray)
        Define a LOCAL-INLINE declaration to control inlining of
	functions.

        Tabled until PROCLAIM-INLINE-WHERE is resolved.


    COMPILE-FILE-ENVIRONMENT (Moon)
	Clarify that environment objects captured with &ENVIRONMENT
	contain information about whether the macro is being expanded
	in the context of the compiler or interpreter.

	Apparently CLOS also needs to store some additional information
	in environment objects.  How about somebody writing up a
	proposal that takes care of that as well?


    COMPILER-LET-CONFUSION (Loosemore)
	The description of COMPILER-LET in CLtL is confusing, and doesn't
	make sense for implementations that do not perform macroexpansion
	in parallel with evaluation in the interpreter.

	Proposal is in the draft stage.

	    
    DEFINE-OPTIMIZER (Pitman)
	Provide a way to define and access "compiler macros".  

	Proposal is in the draft stage.



Issues in progress (no proposals ready yet):

    LOAD-TIME-EVAL (Loosemore)
        What does #, mean?  Where can it appear?

	Lots of discussion but no consensus on this issue yet.

    
    COMPILED-CONSTANTS (Perdue)
        Are quoted constants in compiled code read-only?  Must the compiler
        handle circular constants?  Preserve nonprintable aspects of constant
        data?

    COMPILER-DIAGNOSTICS (Need volunteer)
	Are warnings issued by the compiler really warnings?

	We might define a separate condition for compiler diagnostics.
-------

∂28-Sep-88  1535	CL-Compiler-mailer 	Issue: DEFINE-OPTIMIZER  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Sep 88  15:35:16 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01154g; Wed, 28 Sep 88 14:32:49 PST
Received: by bhopal id AA10022g; Wed, 28 Sep 88 15:32:23 PDT
Date: Wed, 28 Sep 88 15:32:23 PDT
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8809282232.AA10022@bhopal>
To: Gray@DSG.csc.ti.com
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: David N Gray's message of Wed, 28 Sep 88  15:43:01 CDT <2800471381-1566229@Kelvin>
Subject: Issue: DEFINE-OPTIMIZER

I would prefer to see a rule-based approach, at least as the normal
way of declaring optimizations.  A more programmable approach would
be used only when the rule processor is inadequate.

E.g., I find it much easier to read rules of the form:

 ((<arg-type>*) <result-type> <rewrite-pattern>)
 or
 ((<arg-type>*) (<result-type>*) <rewrite-pattern>)

as in:

 '(((fixnum fixnum) fixnum (fixnum-+ arg-0 arg-1))
   ((float float)   float  (float-+  arg-0 arg-1))
   )

More importantly, a rule-based approach makes it easier to augment a
previous set of rules by avoiding the need to advise old optimizers.

The drawback (and this may apply to the programmatic approach as well)
is that some sets of rules are best expressed as sequential attempts.
A simple bad case to consider is the pair of rules:

   ((fixnum integer) integer (foo arg-0 arg-1))
   ((integer fixnum) integer (baz arg-0 arg-1))
  
Depending upon which is entered first, unpredictable results are
possible.  You can partially resolve the issue with more cumbersome
rules, e.g.:

   ((fixnum (and integer (not fixnum))) integer (foo arg-0 arg-1))
   ((integer fixnum) integer (baz arg-0 arg-1))

But even this doesn't solve the problem when you're adding both
types and rules, since the old rules won't discriminate wrt the new
types. 

All of these issues apply to the programmatic approach as well,
since adding one new case or type could easily require rewriting the
old optimizer (or adding advice that amounts to the same).

I guess its obvious that I think one should be able to incrementally
extend the optimizations, modulo probably inevitable pathological
situations. 

  jlm

P.S.  My preferences may be biased by having gotten used to adding
      rules to Lucid's compiler, which works something like what
      I'm suggesting.

∂28-Sep-88  1609	CL-Compiler-mailer 	Re: Issue: DEFINE-OPTIMIZER   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 28 Sep 88  16:09:40 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA27050; Wed, 28 Sep 88 17:07:38 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA06910; Wed, 28 Sep 88 17:07:22 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809282307.AA06910@defun.utah.edu>
Date: Wed, 28 Sep 88 17:07:21 MDT
Subject: Re: Issue: DEFINE-OPTIMIZER
To: Jim McDonald <jlm@lucid.com>
Cc: Gray@dsg.csc.ti.com, KMP@stony-brook.scrc.symbolics.com,
        CL-Compiler@sail.stanford.edu
In-Reply-To: Jim McDonald <jlm@lucid.com>, Wed, 28 Sep 88 15:32:23 PDT

One of the nice things about Pitman's proposal is that it is general
enough so that you could use it to implement the kind of rule-based
approach you describe.  I tend to agree with Pitman that this is an
advanced feature, and that people who use it will be willing and able
to do that kind of thing.

I suppose we could make this like DEFSETF and provide 10 different
ways of specifying the same transformation, but that really seems like
needless complexity.  Also, while I think that just about all
compilers do some kind of pattern-matching transformations, everybody
seems to use a different technique and syntax for specifying them, and
we'd probably get into religious wars if we tried to standardize one
or another of them.  (I know of at least a half-dozen different ones
that have been used in the various compilers developed here at Utah
within the past 2 or 3 years!)

-Sandra
-------

∂28-Sep-88  1643	CL-Compiler-mailer 	Issue: DEFINE-OPTIMIZER  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Sep 88  16:43:43 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01239g; Wed, 28 Sep 88 15:41:06 PST
Received: by bhopal id AA10285g; Wed, 28 Sep 88 16:40:39 PDT
Date: Wed, 28 Sep 88 16:40:39 PDT
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8809282340.AA10285@bhopal>
To: sandra%defun@cs.utah.edu
Cc: Gray@dsg.csc.ti.com, KMP@stony-brook.scrc.symbolics.com,
        CL-Compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Wed, 28 Sep 88 17:07:21 MDT <8809282307.AA06910@defun.utah.edu>
Subject: Issue: DEFINE-OPTIMIZER

    One of the nice things about Pitman's proposal is that it is general
    enough so that you could use it to implement the kind of rule-based
    approach you describe.  I tend to agree with Pitman that this is an
    advanced feature, and that people who use it will be willing and able
    to do that kind of thing.

Does this mean it is fair to assume that if users want to use the
feature across several ports, they will be willing to modify the
(presumably incompatible) optimization routines supplied by different
vendors, and that vendors will be encouraged to release the source
code for their optimizers?   (Otherwise optimizers are likely to be
quiet pessimizers, bypassing internal tricks.)

I see nothing inherently wrong with that, but would like it to be clear
that the level of portability may be very low, with parallel
maintenance required for every vendor you port to, and that effective
use will require a moderate amount of documention from the vendors.

  jlm

∂28-Sep-88  1646	CL-Compiler-mailer 	Issue COMPILER-LET-CONFUSION, version 1 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Sep 88  16:46:18 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01251g; Wed, 28 Sep 88 15:44:08 PST
Received: by bhopal id AA10298g; Wed, 28 Sep 88 16:43:39 PDT
Date: Wed, 28 Sep 88 16:43:39 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809282343.AA10298@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu, jbarnett@gremlin.nrtc.northrop.com,
        kmp@stony-brook.scrc.symbolics.com
In-Reply-To: Sandra J Loosemore's message of Wed, 28 Sep 88 12:29:41 MDT <8809281829.AA06757@defun.utah.edu>
Subject: Issue COMPILER-LET-CONFUSION, version 1

We at Lucid support the proposal COMPILER-LET-CONFUSION:ELIMINATE.

Since this is an incompatible change, some of the Lucid technical
staff feel that a substantial effort should be made to help users
convert old code; in particular, lots of illustrative examples
should be included.


-- JonL --

∂28-Sep-88  1740	CL-Compiler-mailer 	Issue: DEFINE-OPTIMIZER  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Sep 88  17:40:20 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01308g; Wed, 28 Sep 88 16:37:24 PST
Received: by bhopal id AA10488g; Wed, 28 Sep 88 17:36:57 PDT
Date: Wed, 28 Sep 88 17:36:57 PDT
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8809290036.AA10488@bhopal>
To: jlm@lucid.com
Cc: sandra%defun@cs.utah.edu, Gray@dsg.csc.ti.com,
        KMP@stony-brook.scrc.symbolics.com, CL-Compiler@sail.stanford.edu
In-Reply-To: Jim McDonald's message of Wed, 28 Sep 88 16:40:39 PDT <8809282340.AA10285@bhopal>
Subject: Issue: DEFINE-OPTIMIZER

On reflection, most of my arguments probably evaporate for optimizers
of routines not provided by vendors.  I was misled a bit by the use of
STRING-APPEND in the example, which happens to be in Lucid's SYSTEM
package, and which I mistakenly thought was standard Common Lisp. 

  jlm

∂29-Sep-88  0654	CL-Compiler-mailer 	Issue: DEFINE-OPTIMIZER  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Sep 88  06:50:17 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 467615; Thu 29-Sep-88 11:20:49 EDT
Date: Thu, 29 Sep 88 11:20 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFINE-OPTIMIZER
To: jlm@lucid.com
cc: sandra%defun@cs.utah.edu, Gray@dsg.csc.ti.com,
    KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Compiler@sail.stanford.edu
In-Reply-To: <8809282340.AA10285@bhopal>
Message-ID: <880929112027.8.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Wed, 28 Sep 88 16:40:39 PDT
    From: Jim McDonald <jlm@lucid.com>

	One of the nice things about Pitman's proposal is that it is general
	enough so that you could use it to implement the kind of rule-based
	approach you describe.  I tend to agree with Pitman that this is an
	advanced feature, and that people who use it will be willing and able
	to do that kind of thing.

    Does this mean it is fair to assume that if users want to use the
    feature across several ports, they will be willing to modify the
    (presumably incompatible) optimization routines supplied by different
    vendors, and that vendors will be encouraged to release the source
    code for their optimizers?   (Otherwise optimizers are likely to be
    quiet pessimizers, bypassing internal tricks.)

I think the way Symbolics does its optimizers (I haven't looked recently) is
to allow multiple optimizers on a function and to give each a name, so that
you can selectively redefine each. In effect, it defines

 INTERNAL-DEFINE-OPTIMIZER function optimizer-name bvl &BODY forms

so that (effectively) you could define DEFINE-OPTIMIZER as 

 (DEFMACRO DEFINE-OPTIMIZER (NAME BVL &BODY FORMS)
   `(INTERNAL-DEFINE-OPTIMIZER ,NAME ANSI-CL-INTERFACE ,BVL ,@FORMS))

If you have a pattern-driven optimization facility, you could either extend
it so each pattern gets a name and multiple optimizations on the same type
are possible to try (in case one has no effect) or else you could define
that the most specific of several optimizers hit. So DEFINE-OPTIMIZER could
define a pattern that matched anything and then you could define 
implementation-specific optimizers that did better.

I guess what I'm saying is that just because this appears to Common Lisp
users as a low-level substrate doesn't mean that it has to be implemented
underneath your optimization facility. It can still sit on top. So you
don't have to publish info about how your internal facility works. The
biggest risk is that people with portable optimizers might extend the
facility unnecessarily in some cases because they don't realize you have
more stuff around they could have linked into.

    I see nothing inherently wrong with that, but would like it to be clear
    that the level of portability may be very low,
    with parallel maintenance required for every vendor you port to,
    and that effective use will require a moderate amount of documention
    from the vendors.

I totally disagree. You certainly have not made any convincing case for
this at all.

∂29-Sep-88  0657	CL-Compiler-mailer 	Issue: DEFINE-OPTIMIZER  
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 29 Sep 88  06:52:43 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 323360; Thu 29-Sep-88 11:23:17 EDT
Date: Thu, 29 Sep 88 11:23 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFINE-OPTIMIZER
To: jlm@lucid.com
cc: sandra%defun@cs.utah.edu, Gray@dsg.csc.ti.com,
    CL-Compiler@sail.stanford.edu, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <880929112027.8.KMP@GRYPHON.SCRC.Symbolics.COM>,
             <8809282340.AA10285@bhopal>
Message-ID: <880929112313.9.KMP@GRYPHON.SCRC.Symbolics.COM>

Addendum ...

 If all you're saying is that people shouldn't write optimizers
 on functions they didn't write, I'm happy to stipulate that.
 I don't want this facility so that people can optimize 
 STRING-APPEND. I want it so that I can write a window system
 with functions that take hairy keyword arguments and I can
 still optimize those functions (which I wrote, and for which
 the system will have no conflicting operators anyway) efficiently.

∂29-Sep-88  0712	CL-Compiler-mailer 	Re: Issue: DEFINE-OPTIMIZER   
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 29 Sep 88  07:12:30 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA08506; Thu, 29 Sep 88 11:46:08 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA21852; Thu, 29 Sep 88 11:47:56 EDT
Message-Id: <8809291547.AA21852@mist.UUCP>
To: Kent M Pitman <KMP%STONY-BROOK.SCRC.Symbolics.COM@Multimax>
Cc: CL-Compiler%sail.stanford.edu@multimax
Subject: Re: Issue: DEFINE-OPTIMIZER 
In-Reply-To: Your message of Thu, 29 Sep 88 11:23:00 -0400.
             <880929112313.9.KMP@GRYPHON.SCRC.Symbolics.COM> 
Date: Thu, 29 Sep 88 11:47:53 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    Addendum ...
    
     If all you're saying is that people shouldn't write optimizers
     on functions they didn't write, I'm happy to stipulate that.
     I don't want this facility so that people can optimize 
     STRING-APPEND. I want it so that I can write a window system
     with functions that take hairy keyword arguments and I can
     still optimize those functions (which I wrote, and for which
     the system will have no conflicting operators anyway) efficiently.
    
I'm not sure I agree; the following is from a rather old version of
the UMass Amherst GBB sources:

;;; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
;;;
;;;  Compiler optimizers to change some sequence functions that use keyword
;;;  arguments to version that don't.  GBB calls these functions quite a bit
;;;  and runtime analysis of the keywords was taking 25% of the runtime.
;;;
;;;  05-27-86 File Created.  (GALLAGHER)
------------------------------------------------------------------------------

There follows what I think is Explorer-specific code to optimize FIND,
POSITION, and ASSOC.

∂29-Sep-88  0731	CL-Compiler-mailer 	Re: Issue: DEFINE-OPTIMIZER   
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 29 Sep 88  07:31:11 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA09029; Thu, 29 Sep 88 12:04:23 EDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 467672; Thu 29-Sep-88 12:03:10 EDT
Date: Thu, 29 Sep 88 12:02 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DEFINE-OPTIMIZER 
To: pierson%mist@MULTIMAX.ARPA
Cc: KMP%STONY-BROOK.SCRC.Symbolics.COM@MULTIMAX.ARPA,
        CL-Compiler%sail.stanford.edu@MULTIMAX.ARPA
In-Reply-To: <8809291547.AA21852@mist.UUCP>
Message-Id: <880929120250.0.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Thu, 29 Sep 88 11:47:53 EDT
    From: Dan L. Pierson <pierson%mist@multimax.ARPA>

	Addendum ...
    
I finally got around to JLM's follow up message which clarified that this
was what he meant. Oh well...

	 If all you're saying is that people shouldn't write optimizers
	 on functions they didn't write, I'm happy to stipulate that.
	 I don't want this facility so that ...
    
    I'm not sure I agree; the following is from a rather old version of
    the UMass Amherst GBB sources:

Since I assume you're not disagreeing with my statement of what I want
the facility for. I guess you're saying others might want it for something
else.

I was talking more about adding a style warning saying that the effects
of writing optimizers on functions that you didn't implement may not be
good because optimizers may already exist which you're defeating.

This would leave it in the "unspecified but `harmless'" territory of the
new error terminology Kathy Chapman has been circulating. I'd rather have
it that way than "is an error" so that implementations wouldn't signal
gratuitous errors when you were dissatisfied with their performance and
willing to take your chances with your own optimizations such as in the
code you forwarded.

∂29-Sep-88  1513	CL-Compiler-mailer 	Issue: WITH-COMPILATION-UNIT (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Sep 88  15:13:41 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 467976; Thu 29-Sep-88 18:12:25 EDT
Date: Thu, 29 Sep 88 18:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: WITH-COMPILATION-UNIT (Version 1)
To: CL-Compiler@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <880929181138.2.KMP@GRYPHON.SCRC.Symbolics.COM>

Issue:        WITH-COMPILATION-UNIT
References:   None
Category:     ADDITION
Edit history: 29-Sep-88, Version 1 by Pitman
Status:	      For Internal Discussion

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 &BODY forms				[Macro]

   Executes forms from left to right. Within the dynamic context
   of this form, actions 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).

  It follows that the functions COMPILE and COMPILE-FILE should
  provide the effect of WITH-COMPILATION-UNIT around their code.

  Note that if nested, either lexically or dynamically, only the
  outer call to WITH-COMPILATION-UNIT has any effect.

  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:

  Symbolics Genera does something similar to this internally, allowing
  programs that compile whole systems of files to defer warnings until
  the end.

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.

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:

  One could imagine a further extension which allowed user-code to be added
  to the list of things done at the end of a compilation-unit. Probably
  best to deal first with this issue and then with potentially more
  controversial extensions.

  Pitman supports this addition.

∂29-Sep-88  1552	CL-Compiler-mailer 	Re: Issue: DEFINE-OPTIMIZER   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 29 Sep 88  15:52:24 PDT
Received: by ti.com id AA08694; Thu, 29 Sep 88 17:48:53 CDT
Received: from Kelvin by tilde id AA08980; Thu, 29 Sep 88 17:31:08 CDT
Message-Id: <2800564262-7146681@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 29 Sep 88  17:31:02 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: "Dan L. Pierson" <pierson%mist@multimax.ARPA>
Cc: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>,
        CL-Compiler@sail.stanford.edu
Subject: Re: Issue: DEFINE-OPTIMIZER 
In-Reply-To: Msg of Thu, 29 Sep 88 11:47:53 EDT from Dan L. Pierson <pierson%mist@multimax.ARPA>

> I'm not sure I agree; the following is from a rather old version of
> the UMass Amherst GBB sources:
> 
> ;;; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> ;;;
> ;;;  Compiler optimizers to change some sequence functions that use keyword
> ;;;  arguments to version that don't.  GBB calls these functions quite a bit
> ;;;  and runtime analysis of the keywords was taking 25% of the runtime.
> ;;;
> ;;;  05-27-86 File Created.  (GALLAGHER)
> ------------------------------------------------------------------------------
> 
> There follows what I think is Explorer-specific code to optimize FIND,
> POSITION, and ASSOC.

If so, that code became obsolete with release 3.0 (in 1987) since the
compiler now takes care of optimizing those.  Thus this serves to
illustrate the risk of user-optimization of system functions.

∂29-Sep-88  1555	CL-Compiler-mailer 	Issue: WITH-COMPILATION-UNIT (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Sep 88  15:55:31 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA00274g; Thu, 29 Sep 88 14:53:13 PST
Received: by blacksox id AA00427g; Thu, 29 Sep 88 15:50:43 pdt
Date: Thu, 29 Sep 88 15:50:43 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809292250.AA00427@blacksox>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Compiler@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: Kent M Pitman's message of Thu, 29 Sep 88 18:11 EDT <880929181138.2.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: WITH-COMPILATION-UNIT (Version 1)

  Note that if nested, either lexically or dynamically, only the
  outer call to WITH-COMPILATION-UNIT has any effect.

Lexical nesting doesn't matter, only dynamic.  Any example of
lexical nesting without dynamic nesting would be utterly bizarre
anyway.

  (DEFUN COMPILE-FILES (&REST FILES)
    (WITH-COMPILATION-UNIT ()
      (MAPCAR #'(LAMBDA (FILE) (COMPILE-FILE FILE)) FILES)))

I don't think you meant to put () in there.

Lucid implements this in 3.0, as WITH-DEFERRED-WARNINGS.  I support
this proposal.

∂29-Sep-88  1605	CL-Compiler-mailer 	Issue DEFCONSTANT-VALUE  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 29 Sep 88  16:05:35 PDT
Received: by ti.com id AA08820; Thu, 29 Sep 88 18:03:29 CDT
Received: from Kelvin by tilde id AA09393; Thu, 29 Sep 88 17:57:33 CDT
Message-Id: <2800565843-7241698@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 29 Sep 88  17:57:23 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Compiler@SAIL.Stanford.edu
Subject: Issue DEFCONSTANT-VALUE

Assuming that the proposal
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY is approved, the
following is a first draft of a follow-up proposal to amend the
specification of DEFCONSTANT.  I don't know what the proper procedure
for doing this is, so at this point I'm just offering it for comments.
I'm sorry that this is so long, but it seemed necessary in order to
clarify the issues involved.

 
Issue:		DEFCONSTANT-VALUE
References:	Proposal COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
                  section (2)
Category:	CHANGE to previous proposal; CLARIFICATION to CLtL
Edit History:   29 Sept 1988, V1 by David Gray
Status:		For preliminary discussion 
 
Problem Description:

  CLtL does not specify when the value form of a DEFCONSTANT is evaluated;
  this is clarified in COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
  but in an unacceptable way.
  
  The DEFCONSTANT macro does two things beyond what DEFPARAMETER does:

    1. It makes it possible for the compiler to replaces references with
       the value at compile time instead of at run time. 

    2. It causes the compiler to complain if the user attempts to SETQ
       or re-bind the constant name.

  These two things give rise to two different views of what the purpose
  of DEFCONSTANT is:

    1. The purpose of DEFCONSTANT is to facilitate compile-time
       substitution of the values of named constants.  A consequence of
       this is that alteration by SETQ or binding should not be
       permitted.
  or 
    2. The purpose of DEFCONSTANT is to declare that the value must not
       be changed at run time.  A side-effect of this is that, under
       certain circumstances, the compiler may be able to substitute the
       value for the reference at compile time.

  The specification of DEFCONSTANT in proposal
  COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY seems to assume the
  second purpose above, which has the effect of severely limiting its
  usefulness for the first purpose.  I contend that this is a mistaken
  viewpoint and that the definition of DEFCONSTANT should be guided by
  the first purpose above.  

  The concept of named constants was introduced into programming
  languages largely to avoid having "magic numbers" scattered throughout
  the code.  By giving the value a meaningful name and defining it in
  just one place, the code is easier to understand and it is much easier
  to change the value if necessary.  In order to encourage this
  programming style of using named constants, it has always been assumed
  that there should be no loss of efficiency from "doing it the right
  way".  Thus, the compiler should substitute the value for each
  reference and the resulting object code will be just as efficient as
  if the number had been used directly.

  For example, Pascal has constant declarations that look like this:

    const MaxIndex = 100;
          MaxCount = 101;

  Since there are often cases where the value of one constant depends on
  another, many Pascal implementations extend this to permit the value
  to be an expression that depends on previous constants and is
  evaluated at compile time:

    const MaxIndex = 100;
          MaxCount = MaxIndex+1;

  This extension has been carried over into Modula and Ada, and even
  FORTRAN 77 has this functionality in its PARAMETER statement.  (On the
  other hand I don't know of any language that has functionality that
  says to compute a name's value at load time but don't permit it to be
  changed at run time.)  Now the obvious equivalent in Common Lisp would
  be:

    (defconstant max-index 100)
    (defconstant max-count (1+ max-index))

  But, according to the specification of DEFCONSTANT in proposal
  COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY, in order to get the
  same effect (i.e. ensuring compile-time substitution of the value),
  the user would have to write:

    (eval-when (eval compile load)
      (defconstant max-index 100))
    (defconstant max-count #.(1+ max-index))

  The #. is needed to cause the value to be evaluated at compile time
  and the EVAL-WHEN is needed to ensure that the first constant will be
  defined for use by #. .  However, if the second constant were going
  to be referenced by another constant definition later, then it would
  need to be:

    (eval-when (eval compile load)
      (defconstant max-index 100))
    (eval-when (eval compile load)
      (defconstant max-count #.(1+ max-index)))

  Note that separate EVAL-WHEN forms are required in order for the #. to
  work right.  I contend that this is getting much too complicated for
  something that started out as a simple and very typical example.

  It is true that a smart compiler would be able to optimize the simpler
  example (without EVAL-WHEN and #.) in certain limited cases, but if
  the user can't rely on this, then the effect would be to either
  discourage the use of named constants or to encourage frequent use of
  EVAL-WHEN and #. .

Proposal DEFCONSTANT-VALUE:COMPILE-TIME:
 
  Replace the paragraph describing DEFCONSTANT in proposal
  COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY with the following.
  
  DEFCONSTANT: The compiler must recognize the symbol as being constant
  (for example, to suppress warnings about references to the symbolic
  constant as an unbound variable or to enable warnings about binding or
  SETQ'ing the constant in the code being compiled).  The value form
  will be evaluated at compile-time, with the resulting value being used
  to SETQ the symbol at load time, and being available for the compiler
  to substitute in when compiling references to the constant name (as
  described on pages 68-69 of CLtL) and when evaluating the value forms of
  subsequent DEFCONSTANTs.  It is implementation dependent whether or
  not the symbol value is actually set at compile time or whether
  COMPILE-FILE temporarily remembers the value in some other way.

 Rationale:
 
  This makes the semantics of DEFCONSTANT consistent with constant
  declarations in other languages; thus this is a tried and proven
  approach and will reduce confusion for programmers moving from one
  language to another.  

  Run-time efficiency of compiled code seems a more important
  consideration than the ability to protect a load-time value from
  re-assignment at run-time.
 
 Current Practice:

  The Explorer has done it this way since release 3.0 and we have not
  received any complaints saying that this was a mistake.  Before then,
  the heuristic used to decide whether it was safe to compute and
  propagate the value at compile time led to inconsistent and confusing
  behavior.  In order to minimize incompatibility, if there is an error
  during evaluation of the value form, the error is reported as a
  compiler warning and the compiler causes the evaluation to be tried
  again at load time, so missing information at compile time is not a
  fatal error.
 
 Cost to implementors:

  The simple approach of just having DEFCONSTANT expand to (EVAL-WHEN
  (EVAL COMPILE LOAD) ...) would be trivial to implement.  A little more
  work in the compiler would be needed if the value were to be remembered
  temporarily during COMPILE-FILE, but this would be less effort than it
  would take to implement the optimizations permitted by the previous
  proposal.
 
 Cost to users:

  Some changes to user's code are likely to be required, such as wrapping
  an EVAL-WHEN around a DEFUN that is used later in the same file to
  compute the value of a DEFCONSTANT.  For the most part these changes
  will be obvious enough from the errors reported from attempting to
  evaluate the value form.  In some cases, the user may decide that using
  DEFPARAMETER is more appropriate.  There might be more subtle
  differences in behavior in cases where the compile-time and load-time
  values of the constant differ, but they are likely to be a problem
  regardless of which direction the issue is clarified.
  
 Benefits:

  The use of DEFCONSTANT will be simplified since efficient code can be
  generated without requiring the user to explicitly specify what needs
  to be done when.

 Costs of Non-Adoption: 

  Letting COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY stand will mean
  that it will be difficult for users to understand how to use DEFCONSTANT
  to get it to do what they want.

 Aesthetics:
 
  Are improved since the need to use EVAL-WHEN and #. is minimized.
 
 Discussion:

  [Would someone like to summarize the previous discussion that I missed?]

∂29-Sep-88  1631	CL-Compiler-mailer 	Issue DEFCONSTANT-VALUE  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Sep 88  16:31:07 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA00325g; Thu, 29 Sep 88 15:28:55 PST
Received: by blacksox id AA00434g; Thu, 29 Sep 88 16:26:24 pdt
Date: Thu, 29 Sep 88 16:26:24 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809292326.AA00434@blacksox>
To: Gray@DSG.csc.ti.com
Cc: CL-Compiler@SAIL.Stanford.edu
In-Reply-To: David N Gray's message of Thu, 29 Sep 88  17:57:23 CDT <2800565843-7241698@Kelvin>
Subject: Issue DEFCONSTANT-VALUE

Lucid Common Lisp implements DEFCONSTANT-VALUE:COMPILE-TIME.  I
support this proposal.

∂29-Sep-88  1801	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 29 Sep 88  18:01:15 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA00938; Thu, 29 Sep 88 18:59:49 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA07728; Thu, 29 Sep 88 18:59:44 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809300059.AA07728@defun.utah.edu>
Date: Thu, 29 Sep 88 18:59:43 MDT
Subject: Re: Issue DEFCONSTANT-VALUE
To: David N Gray <Gray@dsg.csc.ti.com>
Cc: CL-Compiler@sail.stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Thu, 29 Sep 88  17:57:23 CDT

I would like to see some mention in this proposal of what users are
supposed to do if the constant value truly cannot be computed at
compile time and you do want nasty things to happen if the user
rebinds or SETQs the variable.  (For example, perhaps the constant
holds some value that is specific to the particular machine the Lisp
is running on, such as the amount of physical memory.)

Using #, is one possibility, but the idea really makes me retch,
particularly given the current discord on that issue.  We have not yet
entirely ruled out getting rid of #, entirely. 

If you want to suggest using DEFPARAMETER for that purpose, perhaps you
should extend the proposal to clarify or extend the definition of
DEFPARAMETER's semantics as well.  My reading of CLtL's description
of DEFPARAMETER doesn't leave me with the impression that that's what
it's supposed to be for.

-Sandra
-------

∂29-Sep-88  1830	CL-Compiler-mailer 	Re: Issue: WITH-COMPILATION-UNIT (Version 1) 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 29 Sep 88  18:29:59 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA02052; Thu, 29 Sep 88 19:28:34 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA07746; Thu, 29 Sep 88 19:28:27 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809300128.AA07746@defun.utah.edu>
Date: Thu, 29 Sep 88 19:28:25 MDT
Subject: Re: Issue: WITH-COMPILATION-UNIT (Version 1)
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: CL-Compiler@sail.stanford.edu, KMP@stony-brook.scrc.symbolics.com
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 29 Sep 88 18:11 EDT

This issue strikes me as a special case of "block compilation" across
multiple files.  As an alternative to introducing a new construct,
couldn't we just extend COMPILE-FILE to take a list of files (instead
of a single pathname) as an argument?

A specific comment about the wording of the proposal: the description
of the "actions" that are performed at the end of compilation is much
too vague.  For instance, my implementation of COMPILE-FILE writes out
out the binary file and closes its stream at the end of compilation. :-)

In general, the issue as presented does not strike me as being
particularly critical.  I don't know anybody who gets really upset
about the compiler printing out messages at various stages along the
way, or expects to see exactly the same messages from every compiler.
On the other hand, if the proposal were reworked to address more general
block compilation issues, I think it would be worthwhile to pursue.

-Sandra
-------

∂29-Sep-88  2208	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 29 Sep 88  22:07:57 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA05057; Thu, 29 Sep 88 23:06:26 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA07828; Thu, 29 Sep 88 23:06:21 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809300506.AA07828@defun.utah.edu>
Date: Thu, 29 Sep 88 23:06:20 MDT
Subject: Re: Issue DEFCONSTANT-VALUE
To: David N Gray <Gray@dsg.csc.ti.com>
Cc: CL-Compiler@sail.stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Thu, 29 Sep 88  17:57:23 CDT

I've just thought of another problem with this proposal: it does not
address the issue of what environment the constant value gets
evaluated in.  Presumably this must be the null lexical environment at
compile time; so it should be the null lexical environment at run time
also.  That would make DEFCONSTANT even more incompatible with
DEFPARAMETER and DEFVAR.

I'd like to suggest a compromise on this issue.  How about dropping
this proposal if I add an item to my proposal for issue
COMPILE-ENVIRONMENT-CONSISTENCY, to the effect that the compiler can
wire in the values of constants that have been defined with
DEFCONSTANT in the compilation environment?  (I suspect that most
implementations do so already; I just plain forgot to put it on the
list before.)

That would allow your hairy example with lots of EVAL-WHENs and #.:

    (eval-when (eval compile load)
      (defconstant max-index 100))
    (eval-when (eval compile load)
      (defconstant max-count #.(1+ max-index)))

to be written using a single EVAL-WHEN:

    (eval-when (eval compile load)
      (defconstant max-index 100)
      (defconstant max-count (1+ max-index)))

-Sandra
-------

∂30-Sep-88  0935	CL-Compiler-mailer 	Re: Issue: WITH-COMPILATION-UNIT (Version 1) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Sep 88  09:35:48 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 468336; Fri 30-Sep-88 12:34:30 EDT
Date: Fri, 30 Sep 88 12:34 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: WITH-COMPILATION-UNIT (Version 1)
To: sandra%defun@cs.utah.edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Compiler@sail.stanford.edu
In-Reply-To: <8809300128.AA07746@defun.utah.edu>
Message-ID: <880930123416.5.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Thu, 29 Sep 88 19:28:25 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    This issue strikes me as a special case of "block compilation" across
    multiple files.

This issue has nothing to do with block-compilation, although we could
extend the syntax to permit an options list before the body so that 
implementations could provide options like that if they wanted.

    As an alternative to introducing a new construct, we just extend
    COMPILE-FILE to take a list of files (instead of a single pathname)
    as an argument?

No. The example is oversimplified. In even the most simple real cases
you need to do things like intertwine compiling and loading so
it's not really an issue of COMPILE-FILE. It doesn't take much work
to come up with situations where various evaluations or other things
want to come between the file compilations. [That happens in the Symbolics
source control tool, for example.]

Further, changing COMPILE-FILE wouldn't address the same problem in
in-core compilation (the COMPILE function).

    A specific comment about the wording of the proposal: the description
    of the "actions" that are performed at the end of compilation is much
    too vague.  For instance, my implementation of COMPILE-FILE writes out
    out the binary file and closes its stream at the end of compilation. :-)

Well, it's intended to be liberally interpretable by implementations... but
I wouldn't want implementations to feel accidentally constrained in strange
ways. I'll see about tightening it up a bit.

    In general, the issue as presented does not strike me as being
    particularly critical.  I don't know anybody who gets really upset
    about the compiler printing out messages at various stages along the
    way, or expects to see exactly the same messages from every compiler.
    On the other hand, if the proposal were reworked to address more general
    block compilation issues, I think it would be worthwhile to pursue.

I personally think this is a major deal.  Porting Macsyma was made
massively more difficult by the millions of undefined function warnings
that we got at the end of compiling each of the nearly 200 files. Not
all files get used in every implementation, so there were legitimate
undefined function warnings and it was not possible to just ignore every
such warning. Speaking from experience in having had to stare at
zillions of pages of compiler warnings, I know this facility would have
saved me tons of time -- as I recall, several vendors who didn't offer
the capability expressed a willingness to provide it if only they knew
how the interface should look.

∂30-Sep-88  0958	CL-Compiler-mailer 	issue COMPILER-LET-CONFUSION  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 30 Sep 88  09:58:14 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA00566; Fri, 30 Sep 88 10:55:57 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA08126; Fri, 30 Sep 88 10:54:41 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809301654.AA08126@defun.utah.edu>
Date: Fri, 30 Sep 88 10:54:40 MDT
Subject: issue COMPILER-LET-CONFUSION
To: cl-compiler@sail.stanford.edu
Cc: jonl@lucid.com, jbarnett@gremlin.nrtc.northrop.com,
        kmp@stony-brook.scrc.symbolics.com

I agree with JonL's suggestion that, should we decide to adopt proposal
COMPILER-LET-CONFUSION:ELIMINATE, we should also provide users with a lot
of suggestions for converting old code.

After thinking about it for a while, I've come up with what ought to
be a fairly painless solution that should take care of just about all
cases where COMPILER-LET is currently used.  I've hacked together a
macro called FAKE-COMPILER-LET that is like COMPILER-LET but with
another argument, the list of macros which are supposed to see the
special variable bindings.  The semantics are fairly close to those of
COMPILER-LET-CONFUSION:REDEFINE, the exception being that it only
works if the macros are defined with DEFMACRO and not MACROLET.  I did
think about getting this to handle MACROLET'ed macros by passing
environments around, but it was apparent that the code would get much
hairier (reducing its value as an example) and it still wouldn't
handle all cases (like a nested MACROLET that shadows one of the
listed macros). 

;;; Imitation COMPILER-LET.  Second argument is a list of macros which
;;;    are to see the special bindings; these must have been defined using
;;;    DEFMACRO, not MACROLET (because expansion takes place in null
;;;    lexical environment).

(defmacro fake-compiler-let (binding-forms macros &body body)
    (expand-fake-compiler-let binding-forms macros body))

(eval-when (eval compile load)
    (defun expand-fake-compiler-let (binding-forms macros body)
	(let* ((vars    (mapcar #'(lambda (b)
				      (if (consp b) (car b) b))
				binding-forms))
	       (vals    (mapcar #'(lambda (b)
				      (if (consp b) (eval (cadr b)) nil))
				binding-forms))
	       (binders (mapcar #'(lambda (var val)
				      `(,var ',val))
				vars vals))
	       (defs    (mapcar #'(lambda (m)
				      `(,m (&whole w)
					   (let ,binders
					       (declare (special ,@vars))
					       (macroexpand-1 w))))
				macros)))
	    `(macrolet ((fake-compiler-let (binding-forms macros &body body)
			    (let ,binders
				(declare (special ,@vars))
				(expand-fake-compiler-let
				    binding-forms macros body)))
			,@defs)
	         ,@body)))
    )


;;; Example to illustrate nesting behavior

(eval-when (eval compile)
    (defvar *depth* 0)
    (defmacro current-depth ()
	*depth*)
    )

(fake-compiler-let ((*depth* (1+ *depth*)))
	           (current-depth)
    (format t "First value = ~s~%" (current-depth))
    (fake-compiler-let ((*depth* (1+ *depth*)))
		       (current-depth)
        (format t "Second value = ~s~%" (current-depth))))


How does this strike those of you who have been arguing against
removing COMPILER-LET from the language?

-Sandra
-------

∂30-Sep-88  1212	CL-Compiler-mailer 	Issue: DEFINE-OPTIMIZER  
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 30 Sep 88  12:12:33 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA09890; Fri, 30 Sep 88 15:11:46 EDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00764g; Fri, 30 Sep 88 11:09:05 PST
Received: by bhopal id AA01035g; Fri, 30 Sep 88 12:07:09 PDT
Date: Fri, 30 Sep 88 12:07:09 PDT
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8809301907.AA01035@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: pierson%mist@MULTIMAX.ARPA,
        KMP%STONY-BROOK.SCRC.Symbolics.COM@MULTIMAX.ARPA,
        CL-Compiler%sail.stanford.edu@MULTIMAX.ARPA
In-Reply-To: Kent M Pitman's message of Thu, 29 Sep 88 12:02 EDT <880929120250.0.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: DEFINE-OPTIMIZER 

    If all you're saying is that people shouldn't write optimizers
    on functions they didn't write, I'm happy to stipulate that.

That's the sentiment I want to express, but at the same time, I
wouldn't want to discourage the use of optimizers such as:

(dotimes (i n) (incf sum i)) => (incf sum (truncate (* i (1- i) 2)))

Optimizers such as this are likely to be too specific to be worth
including in a vendors general development environment, yet could
help tremendously in particular cases.  

Perhaps one can only say this is an advanced feature and point out
some potential pitfalls... 

I should note that Lucid's compiler-macro facility allows one to
define a symbol to be treated as a function at eval-time but a macro 
at compile-time.  One obvious use of compiler-macros is to implement
optimizers.  The drawback is the one I alluded to earlier -- there is
just one compiler-macro for a symbol, so you run the risk of a
brain-dead dotimes if you try to optimize it as in my example above.

(I'd be tempted to suggest a compiler-macro-time analog to defadvice,
 but that seems too hairy, too dependent on the whole idea of
 compiler-macros, and too fraught with the dangers I railed against
 earlier.)

Overall, I think the proposal is a good idea if it is viewed as
a pre-pass before normal compiler optimizations, and if people are
discouraged from tampering with forms unless they understand all
the implications.  It should be clearer about its interaction with
macros.

I think there is room for a second, more controversial, proposal
that would provide a facility for advising the compiler with
optimization rules to be used internally, since compiler-macros,
beta-transforms, constant-folding etc. could reveal forms suitable for
user-defined optimizations.  

  jlm

∂30-Sep-88  1347	CL-Compiler-mailer 	Re: Issue: WITH-COMPILATION-UNIT (Version 1) 
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 30 Sep 88  13:47:04 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa06942; 30 Sep 88 20:54 BST
Date: Fri, 30 Sep 88 21:35:14 BST
Message-Id: <3039.8809302035@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: WITH-COMPILATION-UNIT (Version 1)
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, 
    sandra <@cs.utah.edu:sandra@defun>
In-Reply-To: Kent M Pitman's message of Fri, 30 Sep 88 12:34 EDT
Cc: CL-Compiler@sail.stanford.edu

>     Date: Thu, 29 Sep 88 19:28:25 MDT
>     From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> 
>     This issue strikes me as a special case of "block compilation" across
>     multiple files.
> 
> This issue has nothing to do with block-compilation, although we could
> extend the syntax to permit an options list before the body so that 
> implementations could provide options like that if they wanted.

There seem to be a number of issues regarding compilation units.
There is this proposal and the one to limit the scope of
proclamations.  There may be some interest in providing a license
for block compilation (well, there's INLINE, but (among other things)
it's not refelected in the interpreter semantics).

Can we tie these together somehow rather than have a number of
separate proposals, each using different mechanisms?

BTW, INCLUDE (as in "insert this file here") could be used to make
a file compilation treat several files as a unit.

-- Jeff

∂30-Sep-88  1435	CL-Compiler-mailer 	Re: Issue: WITH-COMPILATION-UNIT (Version 1) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Sep 88  14:34:55 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 468578; Fri 30-Sep-88 17:31:47 EDT
Date: Fri, 30 Sep 88 17:31 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: WITH-COMPILATION-UNIT (Version 1)
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu,
    CL-Compiler@sail.stanford.edu
In-Reply-To: <3039.8809302035@subnode.aiai.ed.ac.uk>
Message-ID: <880930173120.3.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Fri, 30 Sep 88 21:35:14 BST
    From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>

    There seem to be a number of issues regarding compilation units.
    There is this proposal and the one to limit the scope of
    proclamations.  There may be some interest in providing a license
    for block compilation (well, there's INLINE, but (among other things)
    it's not refelected in the interpreter semantics).

    Can we tie these together somehow rather than have a number of
    separate proposals, each using different mechanisms?

This is a good idea iff it can be done in the time we have left.

I have tried very hard in all my proposals not to risk getting nothing
done through an attempt to over-generalize. Nothing keeps us from
first passing a simpler issue and then running through a dependent
issue that extends the basic non-controversial functionality. I would
really prefer to do that.

If we end up not passing this issue only because someone introduces
something that makes it less palatable, I'll be quite upset.

    BTW, INCLUDE (as in "insert this file here") could be used to make
    a file compilation treat several files as a unit.

Only in a very limited way. It only works in a file, for example.
There is no analog for cases like:

 (EVAL '(PROGN (COMPILE ...) (INCLUDE ...) (COMPILE ...)))

How would this know to defer the warnings until the end of the file.
The effect of what you're saying is that files are the compilation unit
and you want to establish a smaller unit. I'm saying that there's some
potentially larger unit of which files are a smaller unit.

Also, INCLUDE defeats incremental compilation strategies.

Among things I'd like to do are:

 (WITH-COMPILATION-UNIT (MAPCAR #'COMPILE DEFINITIONS))

and

 (DEFVAR *INITIALIZATION-LIST*)

 (DEFUN ADD-INITIALIZATION (FORM) (PUSH FORM *INITIALIZATION-LIST*))

 (DEFUN PROCESS-FILES (INPUTS-AND-OUTPUTS)
   (WITH-COMPILATION-UNIT
     (LET ((*INITIALIZATION-LIST* '()))
       (DOLIST (INPUT-AND-OUTPUT INPUTS-AND-OUTPUTS)
         (IF (some-test (FIRST INPUT-AND-OUTPUT))
             (COMPILE-FILE (FIRST INPUT-AND-OUTPUT)))
       (LOAD (SECOND INPUT-AND-OUTPUT))))
     (MAPCAR #'EVAL *INITIALIZATION-LIST*)
     T))

Consider a case where the result of evaluating one of the initializations
is what causes some functions to become defined that I don't want to be
warned about.

∂01-Oct-88  1654	CL-Compiler-mailer 	Issue DEFCONSTANT-VALUE  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Oct 88  16:54:48 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01442g; Sat, 1 Oct 88 15:52:32 PST
Received: by bhopal id AA08490g; Sat, 1 Oct 88 16:52:06 PDT
Date: Sat, 1 Oct 88 16:52:06 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810012352.AA08490@bhopal>
To: Gray@DSG.csc.ti.com
Cc: CL-Compiler@SAIL.Stanford.edu
In-Reply-To: David N Gray's message of Thu, 29 Sep 88  17:57:23 CDT <2800565843-7241698@Kelvin>
Subject: Issue DEFCONSTANT-VALUE

re: Proposal DEFCONSTANT-VALUE:COMPILE-TIME:
    . . . 
    DEFCONSTANT: The compiler must recognize the symbol as being constant
    (for example, to suppress warnings about references to the symbolic
    constant as an unbound variable or to enable warnings about binding or
    SETQ'ing the constant in the code being compiled).  The value form
    will be evaluated at compile-time, with the resulting value being used
    to SETQ the symbol at load time, and being available for the compiler
    to substitute in when compiling references to the constant name (as
    described on pages 68-69 of CLtL) and when evaluating the value forms of
    subsequent DEFCONSTANTs.  It is implementation dependent whether or
    not the symbol value is actually set at compile time or whether
    COMPILE-FILE temporarily remembers the value in some other way.

   Rationale:

    This makes the semantics of DEFCONSTANT consistent with constant
    declarations in other languages; thus this is a tried and proven
    approach and will reduce confusion for programmers moving from one
    language to another.  

   . . . 

After careful reconsideration of this proposal, this is *not* 
what Lucid does.  See especially the discussion further below
concerning the "second part".

First, let me say that I share your concern about the weird 
semantics of DEFCONSTANT in the existing proposal -- that it's 
decision to evaluate at compile time is based on "examination" 
of the form to be evaluated.  Long ago I expressed a desire for 
it to be a simpler decision making process.  Either let the 
default be implicitly eval-when(eval compile load) just like 
the "7 extremely randoms", or let it be like any other toplevel 
form.  To me, this really isn't such a big issue, because no
matter what the decision, there will be a significant number of
defconstant usages that need it the other way.  In the Lucid
system sources, there are scores, if not hundreds, of eval-whens
to alter the default evaluation timings for defconstants and
defmacros.

So in one sense, the default state -- to eval-at-compile or not
to eval-at-compile -- is an arbitray and voteable question.
Lucid does in fact treat both defconstant and defmacro just
like the "7 Randoms" -- those at top-level **without a user
supplied eval-when** are implicitly eval-when(eval compile load).
This kind of simplicity is one of the two things you are calling 
for, right?


But the second part of your proposal, while laudable in my
opinion, is not at all what Lucid does:
    . . . The value form
    will be evaluated at compile-time, with the resulting value being 
    used to SETQ the symbol at load time, ... 
Several other vendors I've looked at seem to do no constant folding 
whatsoever; Lucid does some constant folding, but gives absolutely 
no guarantee just what things will be folded and under what 
circumstances.  For constants that are not "folded", the SETQ 
performed at runtime does a completely fresh re-calculation at
load-time.  


If you are really serious about this counter proposal, then I'd
certainly like to see it broken up into two parts:

  (1) DEFCONSTANT is implicitly eval-when(eval compile load),
      just like a bunch of the other randoms

  (2) The load-time SETQ for a DEFCONSTANT is to the object
      obtained by the compile-time evaluation.  In effect,
      compiling a defconstant treats:
	(defconstant mumble (do-my-evaluation))
      as if it were:
        (defconstant mumble '#.(do-my-evaluation))

I suspect that this latter point is what you are stressing in
the Rationale part when you say:
    
    This makes the semantics of DEFCONSTANT consistent with constant
    declarations in other [conventional??] languages;  ...




-- JonL --

∂02-Oct-88  1135	CL-Cleanup-mailer 	New Issue: SYNTACTIC-ENVIRONMENT-ACCESS  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 2 Oct 88  11:35:23 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA01597g; Sun, 2 Oct 88 10:33:05 PST
Received: by blacksox id AA00623g; Sun, 2 Oct 88 11:30:37 pdt
Date: Sun, 2 Oct 88 11:30:37 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8810021830.AA00623@blacksox>
To: cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
Subject: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS

Issue:          SYNTACTIC-ENVIRONMENT-ACCESS
References:     CLtL Chapter 8: Macros,
		Issue MACRO-FUNCTION-ENVIRONMENT,
		Issue GET-SETF-METHOD-ENVIRONMENT,
		Issue COMPILE-FILE-ENVIRONMENT,
		Issue LOAD-TIME-EVAL
Category:       ADDITION
Edit history:	Version 1, 2-Oct-88, Eric Benson
Status:         For internal discussion

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.

 Implementing the FIND-CLASS and ENSURE-GENERIC-FUNCTION functions of
 CLOS requires the ability to distinguish between environments used
 for compiling to a file from those used for processing in-core, such
 as by EVAL or COMPILE.  Resolution of the LOAD-TIME-EVAL issue may
 also require this information.  This problem has been addressed by
 the recent cleanup issue COMPILE-FILE-ENVIRONMENT.  Also, it has
 proven impossible to write a portable code walker in Common Lisp, due
 to insufficient access to the information contained in environments
 and the inability to augment environments with local function
 definitions.

Proposal (SYNACTIC-ENVIRONMENT-ACCESS:ADD-FUNCTIONAL-INTERFACE):

 The following functions provide information about syntactic
 environment objects.  In all of the functions the argument named ENV
 is a environment, of the sort received by the &ENVIRONMENT argument
 to a macro.  In all cases it is an error to supply an argument which
 is not a syntactic environment.

 Note that we have used the term "syntactic environment" here.  This
 is to distinguish these environments from the environment arguments
 of EVALHOOK and APPLYHOOK.  EVALHOOK-type environments must include a
 mapping from names to values (run-time) as well as the simple
 presence-or-absence information (compile-time) needed for
 MACROEXPAND-type environments.  We consider these to be two entirely
 different kinds of objects and will not deal with EVALHOOK-type
 environments at all in this proposal.

 ENVIRONMENT-TARGET env				[Function]

  This function returns one of the three symbols EVAL, COMPILE or
  COMPILE-FILE, depending on whether the environment is from the
  interpreter, the in-core compiler, or the file compiler.  If
  MACROEXPAND or MACROEXPAND-1 is called directly without supplying
  the environment argument, the environment passed to any expander
  functions will have target EVAL.

 ENVIRONMENT-VARIABLE-KIND variable env		[Function]

  VARIABLE is a symbol.  This function returns one of the following
  values:
	NIL, if the symbol has no visible definition, declaration or
	  binding as a variable.
	PROCLAIM, if the symbol has been proclaimed special.
	DECLARE, if the symbol has been declared special.
	SYMBOL-MACROLET, if the symbol names a symbol macro.
	T, if the symbol has an ordinary lexical binding.

 [Note: these alternatives may have to be changed depending on the
 outcome of the PROCLAIM-LEXICAL issue.]

 Example:

  (DEFMACRO KIND-OF-VARIABLE (VAR &ENVIRONMENT ENV)
    `',(ENVIRONMENT-VARIABLE-KIND 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) -> (PROCLAIM T DECLARE SYMBOL-MACROLET NIL)
      

 ENVIRONMENT-FUNCTION-KIND function env		[Function]

  FUNCTION is a symbol.  This function returns one of the following
  values:
	NIL, if the symbol has no visible function definition or
	  function binding.
	DEFUN, if the symbol names a global function not overridden by a
	  local binding.
	DEFMACRO, if the symbol names a global macro not overridden by a
	  local binding.
	SPECIAL-FORM-P, if the symbol names a special form.
	FLET, if the symbol has a local function binding, such as
	  created by FLET or LABELS.
	MACROLET, if the symbol has a local macro binding, such as
	  created by MACROLET.

 Example:

  (DEFMACRO KIND-OF-FUNCTION (FUNCTION-NAME &ENVIRONMENT ENV)
    `',(ENVIRONMENT-FUNCTION-KIND FUNCTION-NAME ENV))

  (DEFUN A ())

  (DEFMACRO B ())

  (DEFUN TEST ()
    (FLET ((C ()))
      (MACROLET ((D ()))
	(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) -> (DEFUN DEFMACRO SPECIAL-FORM-P FLET MACROLET NIL)

 ENVIRONMENT-BLOCK-P block-name env		[Function]

  BLOCK-NAME is a symbol.  This function returns T if there is a block
  with that name in the environment, otherwise it returns NIL.

 Example:

  (DEFMACRO IS-A-BLOCK (NAME &ENVIRONMENT ENV)
    `',(ENVIRONMENT-BLOCK-P NAME ENV))

  (DEFUN TEST ()
    (LOOP (RETURN (LIST (IS-A-BLOCK TEST)
			(IS-A-BLOCK NIL)
			(IS-A-BLOCK NOT-HERE)))))

  (TEST) -> (T T NIL)
	
 ENVIRONMENT-TAG-P tag-name env		[Function]

  TAG-NAME is a symbol or an integer.  This function returns T if
  there is a tag with that name in the environment, otherwise it
  returns NIL.

 Example:

  (DEFMACRO IS-A-TAG (TAG-NAME &ENVIRONMENT ENV)
    `',(ENVIRONMENT-TAG-P TAG-NAME ENV))

  (DEFUN TEST ()
    (PROG ()
      A
      (RETURN (LIST (IS-A-TAG A)
		    (IS-A-TAG I-HOPE-NOT)))))

  (TEST) -> (T NIL)

 ENVIRONMENT-VARIABLE-TYPE variable env		[Function]

  VARIABLE is a symbol.  This function returns the type specifier
  associated with the variable named by the symbol in the environment,
  or NIL if there is none.  (This is in spite of the fact that NIL is
  a legal type specifier, since NIL has no meaning as a type specifier
  for a variable.)

 Example:

  (DEFMACRO VARTYPE (VAR &ENVIRONMENT ENV)
    `',(ENVIRONMENT-VARIABLE-TYPE VAR ENV))

  (DEFVAR A 1)

  (PROCLAIM '(FIXNUM A))

  (DEFUN TEST ()
    (LET ((B (AREF "X" 0))
	  (C 3))
      (DECLARE (STRING-CHAR B))
      (LIST (VARTYPE A) (VARTYPE B) (VARTYPE C))))

  (TEST) -> (FIXNUM STRING-CHAR NIL)

 ENVIRONMENT-FTYPE function env			[Function]

  FUNCTION is a symbol.  This function returns the type specifier
  associated with the function named by the symbol in the environment,
  or NIL if there is none.

 Example:

  (DEFMACRO FUNTYPE (FUN &ENVIRONMENT ENV)
    `',(ENVIRONMENT-FTYPE FUN ENV))

  (DEFUN A-FUNCTION (X)
    (+ X 3))

  (PROCLAIM '(FTYPE (FUNCTION (FIXNUM) FIXNUM) A-FUNCTION))

  (DEFUN TEST ()
    (FLET ((ANOTHER-FUNCTION (X)
	     (+ X 2)))
      (DECLARE (FTYPE (FUNCTION (INTEGER) INTEGER) ANOTHER-FUNCTION))
      (LIST (FUNTYPE A-FUNCTION) (FUNTYPE ANOTHER-FUNCTION))))

  (TEST) -> ((FUNCTION (FIXNUM) FIXNUM) (FUNCTION (INTEGER) INTEGER))

 ENVIRONMENT-INLINE function env		[Function]

  FUNCTION is a symbol.  This function returns INLINE, NOTINLINE or
  NIL, depending on whether the function named by FUNCTION is declared
  or proclaimed INLINE, declared or proclaimed NOTINLINE, or if no
  such declaration or proclamation has been made.

 Example:

  (DEFMACRO INLINENESS (FUN &ENVIRONMENT ENV)
    `',(ENVIRONMENT-INLINE FUN ENV))

  (PROCLAIM '(INLINE A-SHORT-FUNCTION))
  (DEFUN A-SHORT-FUNCTION () 'SHORT)

  (PROCLAIM '(NOTINLINE Y))
  (DEFUN Y (F)
    ((LAMBDA (G)
       #'(LAMBDA (X)
	   (FUNCALL (FUNCALL F
			     (FUNCALL G G))
		    X)))
     #'(LAMBDA (H)
         #'(LAMBDA (Z)
	     (FUNCALL (FUNCALL F
			       (FUNCALL H H))
		      Z)))))

  (DEFUN A-FUNCTION ())

  (DEFUN TEST ()
    (FLET ((A-LOCAL-FUNCTION ()))
      (DECLARE (INLINE A-LOCAL-FUNCTION)
	       (NOTINLINE A-SHORT-FUNCTION))
      (LIST (INLINENESS A-SHORT-FUNCTION)
	    (INLINENESS Y)
	    (INLINENESS A-LOCAL-FUNCTION)
	    (INLINENESS A-FUNCTION)))

  (TEST) -> (NOTINLINE NOTINLINE INLINE NIL)

 ENVIRONMENT-OPTIMIZE-LEVEL attribute env	[Function]

  ATTRIBUTE is one of the symbols SPEED, SPACE, SAFETY or
  COMPILATION-SPEED.  This function returns an integer between 0 and
  3, which reflects the current settings of the OPTIMIZE proclamation
  or declaration.

 Example:

  (DEFMACRO OPTIMIZE-LEVEL (PROPERTY &ENVIRONMENT ENV)
    `',(ENVIRONMENT-OPTIMIZE PROPERTY ENV))

  (PROCLAIM '(OPTIMIZE (SPEED 3)
		       (SAFETY 0)
		       (SPACE 0)
		       (COMPILATION-SPEED 0)))

  (DEFUN TEST ()
    (LIST (LIST (OPTIMIZE-LEVEL SPEED)
		(OPTIMIZE-LEVEL SAFETY)
		(OPTIMIZE-LEVEL SPACE)
		(OPTIMIZE-LEVEL COMPILATION-SPEED))
	  (LOCALLY (DECLARE (OPTIMIZE (SAFETY 3)
				      (SPEED 0)
				      (COMPILATION-SPEED 3)
				      (SPACE 3)))
	    (LIST (OPTIMIZE-LEVEL SPEED)
		  (OPTIMIZE-LEVEL SAFETY)
		  (OPTIMIZE-LEVEL SPACE)
		  (OPTIMIZE-LEVEL COMPILATION-SPEED)))))

  (TEST) -> ((3 0 0 0) (0 3 3 3))

 The following function provides the ability to create a new
 syntactic environment based on an existing environment:

 AUGMENT-ENVIRONMENT env &KEY variables
			      specials
			      functions
			      macros
			      blocks
			      tags
			      types
			      ftypes
			      inlines
			      optimize		[Function]

  This function returns a new environment augmented with the
  information provided by the keyword arguments.  The arguments are
  supplied as follows:
	VARIABLES is a list of symbols, which shall be visible as
  ordinary lexical variables in the new environment.
	SPECIALS is a list of symbols, which shall be visible as
  special declarations in the new environment.
	FUNCTIONS is a list of symbols, which shall be visible as
  local function bindings in the new environment.
	MACROS is an a-list of symbols and macroexpansion functions.
  The new environment will have local macro bindings of each symbol to
  the corresponding expander function, so that MACRO-FUNCTION or
  MACROEXPAND when given that symbol will use the new expander
  function.
	BLOCKS is a list of symbols, which shall be visible as block
  names in the new environment.
	TAGS is a list of symbols and integers, which shall be visible
  as TAGBODY tags in the new environment.
	TYPES is an a-list of symbols and type specifiers.  The new
  environment will have the type specifier associated with the
  corresponding symbol, as if a type declaration were visible.
	FTYPES is an a-list of symbols and function type specifiers.
  This is analogous to TYPES, except operating in the function
  namespace.
	INLINES is a a-list of symbols and either the symbol INLINE or
  NOTINLINE.  This causes an INLINE or NOTINLINE declaration to be
  visible in the new environment.
	OPTIMIZE is an a-list of any of the symbols SPEED, SAFETY,
  SPACE or COMPILATION-SPEED with integers between 0 and 3.  These
  settings will be returned by the ENVIRONMENT-OPTIMIZE-LEVEL
  function for the new environment.

Rationale:

 This proposal provides a portable interface to environment
 information which must otherwise be obtained by
 implementation-dependent means.  The ENSURE-GENERIC-FUNCTION and
 FIND-CLASS functions of CLOS require the ENVIRONMENT-TARGET function.  A
 useful code walker requires the capability of adding local function
 definitions to an environment.

Cost to Implementors:

 Most implementations already store 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 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.

∂02-Oct-88  1159	CL-Compiler-mailer 	Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Oct 88  11:59:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 02 OCT 88 11:57:55 PDT
Date: 2 Oct 88 11:57 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)
In-reply-to: Eric Benson <eb@lucid.com>'s message of Sun, 2 Oct 88 11:30:37
 pdt
To: Eric Benson <eb@lucid.com>
cc: cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
Message-ID: <881002-115755-2604@Xerox>

would you say this supercedes:

-----
Issue:        SPECIAL-VARIABLE-TEST
References:   Declaring Global Variables and Named Constants (pp68-69),
	      Declaration Specifiers (p157)
Category:     ADDITION
Edit history: 07-Mar-88, Version 1 by Pitman
	      21-May-88, Version 2 by Pitman (correct test case, add discussion)
Status:	      For Internal Discussion

Problem Description:

  CLtL does not define a way to test to see if a variable has been
  proclaimed special (for the purposes of either binding or reference).

  Programs such as macros, code-walkers, and program-generating programs
  may need such information from time to time in order to do certain kinds
  of reasoning about code-motion, unused variables, etc.

Proposal (SPECIAL-VARIABLE-TEST:SPECIAL-VARIABLE-P)

  Add a function SPECIAL-VARIABLE-P by analogy with SPECIAL-FORM-P
  which is defined as:

  SPECIAL-VARIABLE-P symbol &optional environment	[Function]

  Returns T iff -symbol- names a variable which is SPECIAL in the
  indicated lexical -environment-. Otherwise, it returns NIL.
  It is an error if -symbol- is not a symbol. If not supplied, the
  -environment- defaults to NIL, meaning the null lexical environment.

  This function will be useful in determining whether a reference to
  the variable named by SYMBOL in the indicated ENVIRONMENT will be
  a special reference.

  Note: Since special variable proclamations are pervasive and
  declarations are not, the technique for determining whether binding
  the variable named by SYMBOL is not dependent on the surrounding
  lexical environment. It is instead dependent only on the global
  environment and on the declarations of the form which would accomplish
  the binding. Whether the variable has been globally proclaimed special
  can be determined by doing (SPECIAL-VARIABLE-P 'symbol). Whether the
  variable is locally declared SPECIAL can be checked only by parsing
  the declarations looking for (DECLARE ... (SPECIAL ... symbol ...)).

Test Case:

  (PROCLAIM '(SPECIAL SPECIAL-FOO))
  (MACROLET ((TEST (NAME &ENVIRONMENT ENV)
	       `'(,NAME ,(SPECIAL-VARIABLE-P NAME ENV)) ))
    (LIST* (TEST SPECIAL-FOO)				        ;0
	   (TEST FOO)
	   (LET ((SPECIAL-FOO 1) (FOO 1))
	     (LIST* (TEST SPECIAL-FOO)				;1
		    (TEST FOO)
		    (LET ((SPECIAL-FOO 2) (FOO 2))
		      (DECLARE (SPECIAL FOO))
		      (LIST* (TEST SPECIAL-FOO)			;2
			     (TEST FOO)
			     (LET ((SPECIAL-FOO 3) (FOO 3))
			       (LIST (TEST SPECIAL-FOO)		;3
				     (TEST FOO)))))))))
  => ((SPECIAL-FOO T) (FOO NIL)			;0
      (SPECIAL-FOO T) (FOO NIL)			;1
      (SPECIAL-FOO T) (FOO T)			;2
      (SPECIAL-FOO T) (FOO NIL))		;3

Rationale:

  This would allow programs that reason about other programs to obtain
  important information about SPECIAL declarations and proclamations.

Current Practice:

  Interpreters and compilers must, of necessity, have a way to do this
  internally.

  In some implementations, information about special variable proclamations
  is kept on a symbol's plist, and users eventually "figure out" how to take
  advantage of that.

  In most implementations, getting information about special declarations
  is neither documented nor easy to "figure out".

  Symbolics Genera has undocumented internal function which does this.

Cost to Implementors:

  By necessity, compilers and interpreters must have a way to get the
  information returned by this facility. In general, it should just be
  a matter of providing a program interface to that facility.

Cost to Users:

  None. This is an upward-compatible extension.

Cost of Non-Adoption:

  Some code-walkers, macros, etc. would continue be hard to write in a
  portable way.

Benefits:

  The cost of non-adoption would be avoided.

Aesthetics:

  Although SPECIAL variables provide some benefit to Common Lisp, that 
  benefit has not been without price. It's difficult to do proper code
  analysis if lexical and special variables look the same. The presence
  of this operator makes it easier to write code which reasons clearly
  and correctly about other programs, and so will probably tend to
  improve the aesthetics of such programs.

Discussion:

  This proposal came to the Cleanup committee from the Japanese community.
  Pitman wrote it up formally.

  Pitman and Moon support SPECIAL-VARIABLE-TEST:SPECIAL-VARIABLE-P.




∂02-Oct-88  1223	CL-Compiler-mailer 	Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Oct 88  12:23:41 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 469078; Sun 2-Oct-88 15:21:37 EDT
Date: Sun, 2 Oct 88 15:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)
To: masinter.pa@Xerox.COM
cc: eb@lucid.com, cl-compiler@sail.stanford.edu,
    cl-cleanup@sail.stanford.edu
In-Reply-To: <881002-115755-2604@Xerox>
Message-ID: <881002152101.4.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: 2 Oct 88 11:57 PDT
    From: masinter.pa@Xerox.COM

    would you say this supercedes:

"supersedes"

    Issue:        SPECIAL-VARIABLE-TEST

Since EB's proposal is more elaborate and might not get past X3J13, I
would prefer if both were presented and the committee could decide.
I don't want to see the failure of this proposal to pass leave us with
nothing to show.

∂02-Oct-88  1257	CL-Compiler-mailer 	New Issue: SYNTACTIC-ENVIRONMENT-ACCESS 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Oct 88  12:57:01 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 469083; Sun 2-Oct-88 15:55:26 EDT
Date: Sun, 2 Oct 88 15:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
To: eb@lucid.com
cc: cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: <8810021830.AA00623@blacksox>
Message-ID: <881002155456.5.KMP@GRYPHON.SCRC.Symbolics.COM>

The return values of ENVIRONMENT-VARIABLE-KIND in this  proposal clashes
with PROCLAIM-LEXICAL in a bad way. I would prefer if it returned at least
two values:

 Value 1 (KIND):
   NIL       = No declared semantics
   LEXICAL   = Lexical variable
   SPECIAL   = Special variable
   MACRO     = Symbol macro

 Value 2 (WHERE-DECLARED):
   GLOBAL    = Globally declared
   LOCAL     = Locally declared
   NIL	     = Not declared

A third value you might consider returning is CONSTANT-P, so that a
variable declared by DEFCONSTANT could be distinguished. You could deal
with this by a separate function, though, similar to ENVIRONMENT-INLINE.

In fact, I also think the returned values (other than T and NIL) should
be keywords because
 - keywords are easier to deal with
 - keywords are safe here (the set is non-extensible)
 - it would be more consistent with other inquiry functions
   like FIND-SYMBOL, which return status info in keyword package.

Your suggested values would map as follows:

 KMP suggestion		EB suggestion

 NIL,     NIL		NIL
 SPECIAL, GLOBAL	PROCLAIM
 SPECIAL, LOCAL		DECLARE
 LEXICAL, LOCAL		T
 MACRO,   LOCAL		SYMBOL-MACROLET

My proposal leaves a few meaningless combinations, but has the virtue of
being extensible for other situations possibly yet to come, such as:

 MACRO,   GLOBAL	Symbol macros (Symbolics Genera has them)
 LEXICAL, GLOBAL	Global lexicals (see issue PROCLAIM-LEXICAL) 

The following other case which exists now but which you didn't address
might be worth considering, too:

 NIL,     GLOBAL      	Reserved words (eg, &FROBOZZ)

I'd also be curious to know why you want ENVIRONMENT-VARIABLE-TYPE to
return NIL in the case where something's undeclared. I propose it return
T (the default type, after all), and perhaps offer a second return value
which says whether the information was declared or defaulted. Actually,
come to think of it, the second return value could be NIL, LEXICAL, or
GLOBAL for consistency with my suggestion above.

Perhaps also ENVIRONMENT-INLINE could return as many as three values:
INLINE-P, INLINE-INFO-AVAILABLE-P, and WHERE-DECLARED
so that you could distinguish global from local information, etc.

The reason I suggest these is that a lot of kind of reasoning could 
be done by looking only at the first value. The way you have all your
functions structured, you have to case for a lot more things than you
might really want to know. eg, if your only interest is to determine
if a variable is going to do a special reference, you have to look 
for two markers (DECLARE and PROCLAIM) under your scheme, but a binary
value under mine. Similarly, if you want to know the type of something,
you have to special-case NIL under your scheme but can just use the
return value directly under mine. Only advanced applications where
more info is needed would need to pick up the additional values. Further,
the additional information is richer than the information provided in
your proposal.

I'll have to talk to our compiler people about the feasibility of some
of your suggestions. I may have more comments on that later.

∂02-Oct-88  1346	CL-Compiler-mailer 	Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Oct 88  13:46:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 02 OCT 88 13:44:53 PDT
Date: 2 Oct 88 13:44 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Sun, 2 Oct 88 15:21 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: masinter.pa@Xerox.COM, eb@lucid.com, cl-compiler@sail.stanford.edu,
 cl-cleanup@sail.stanford.edu
Message-ID: <881002-134453-2675@Xerox>

Kent: You've always superceded me at speling.

I'm game for presenting both, if there are no squawkers here.

I'm wary of mail that goes to cl-compiler and cl-cleanup. Lets try to
decide who has an issue and pass it back if it doesn't fit. 

I'm afraid we'll have more work in January that we originally expected, the
rate things are going.

∂03-Oct-88  0618	CL-Compiler-mailer 	Re: Issue: WITH-COMPILATION-UNIT (Version 1) 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 3 Oct 88  06:18:47 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA00660; Mon, 3 Oct 88 06:15:03 PDT
Received: from clam.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA02292; Mon, 3 Oct 88 06:17:29 PDT
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA28897; Sun, 2 Oct 88 15:29:46 PDT
Date: Sun, 2 Oct 88 15:29:46 PDT
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8810022229.AA28897@clam.sun.com>
To: KMP@stony-brook.scrc.symbolics.com, sandra%defun@cs.utah.edu
Subject: Re: Issue: WITH-COMPILATION-UNIT (Version 1)
Cc: CL-Compiler@sail.stanford.edu

> This issue strikes me as a special case of "block compilation" across
> multiple files.  As an alternative to introducing a new construct,
> couldn't we just extend COMPILE-FILE to take a list of files (instead
> of a single pathname) as an argument?

This seems like a logical basic idea to me.  Why don't we just
extend compile-file to accept a stream argument as an alternative
to the file name argument.  On the immediate issue, this could be
used along with make-concatenated-stream  to compile multiple
files.

Permitting a stream in place of the filename would also make it possible
to compile *to* a file without compiling *from* a file, a capability
that I and others I know would certainly use, and something not
possible now.

Note that compile-file already accepts an :output-file argument, which
I propose would be required except when an implementation can determine
the name of the input filename/stream.

				-Cris

∂03-Oct-88  0958	CL-Cleanup-mailer 	Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Oct 88  09:58:00 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA03601; Mon, 3 Oct 88 10:56:28 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA13415; Mon, 3 Oct 88 10:56:22 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810031656.AA13415@defun.utah.edu>
Date: Mon, 3 Oct 88 10:56:21 MDT
Subject: Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
To: Eric Benson <eb@lucid.com>
Cc: cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Eric Benson <eb@lucid.com>, Sun, 2 Oct 88 11:30:37 pdt

> Date: Sun, 2 Oct 88 11:30:37 pdt
> From: Eric Benson <eb@lucid.com>
> 
>  ENVIRONMENT-TARGET env				[Function]
> 
>   This function returns one of the three symbols EVAL, COMPILE or
>   COMPILE-FILE, depending on whether the environment is from the
>   interpreter, the in-core compiler, or the file compiler.  If
>   MACROEXPAND or MACROEXPAND-1 is called directly without supplying
>   the environment argument, the environment passed to any expander
>   functions will have target EVAL.

I really dislike this part of the proposal.  I hate to have to keep
repeating myself, but there are other situations besides the three
listed here in which code may be processed.  The example I've cited
before is a filter that reads in code from a file, performs some
preprocessing to decorate the code with lots of type declarations, and
writes it out to another file.  I contend that anything that needs to
know whether the code is being processed by the interpreter or
compiler ought to be a special form (this includes EVAL-WHEN and
whatever we decide to do about LOAD-TIME-EVAL) and should be left
strictly alone by code walkers.

As to the claim that CLOS needs this information, my understanding
from reading 88-002R is that what CLOS really needs to store in the
environment is information about the class hierarchy and which
functions are generic functions.  (I'm guessing that the current
implementation does not do this, and instead stores the information
externally to the environment in different places depending on whether
it's for the compiler or interpreter.)

On the whole, I'm rather lukewarm about this proposal.  I hate to add
this much more complexity to the language but I think it's probably
necessary.  When local macro definitions were the only thing that the
environment was used for, you could hack out a code walker by defining
your own representation for environment objects and your own
MACROEXPAND-like function that understands that representation.  I
don't think that's possible any more if we are going to start
requiring that other information (i.e., for CLOS) be stored in the
environment.  Also, you really do need access to proclamations (and
not just SPECIAL proclamations).

A minor quibble:  on all of the functions in this proposal that return 
symbols, how about making them keywords, please?

-Sandra
-------

∂03-Oct-88  1737	CL-Compiler-mailer 	Re: Issue: WITH-COMPILATION-UNIT (Version 1) 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 3 Oct 88  17:35:51 PDT
Received: by ti.com id AA26344; Mon, 3 Oct 88 19:34:07 CDT
Received: from Kelvin by tilde id AA14314; Mon, 3 Oct 88 19:28:37 CDT
Message-Id: <2800916976-11819042@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 3 Oct 88  19:29:36 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Compiler@SAIL.Stanford.EDU
Subject: Re: Issue: WITH-COMPILATION-UNIT (Version 1)
In-Reply-To: Msg of Thu, 29 Sep 88 18:11 EDT from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

> Proposal (WITH-COMPILATION-UNIT:NEW-MACRO):
> 
>   Add the following new macro:
> 
>    WITH-COMPILATION-UNIT &BODY forms				[Macro]
...
> Current Practice:
> 
>   Symbolics Genera does something similar to this internally, allowing
>   programs that compile whole systems of files to defer warnings until
>   the end.

The Explorer has an undocumented macro called
COMPILER:COMPILER-WARNINGS-CONTEXT-BIND which does just what you
propose.

∂03-Oct-88  1954	CL-Compiler-mailer 	Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Oct 88  19:54:50 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 469980; Mon 3-Oct-88 22:52:07 EDT
Date: Mon, 3 Oct 88 22:51 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Eric Benson <eb@lucid.com>
cc: cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: <8810031656.AA13415@defun.utah.edu>
Message-ID: <19881004025148.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    >  ENVIRONMENT-TARGET env				[Function]
    > 
    >   This function returns one of the three symbols EVAL, COMPILE or
    >   COMPILE-FILE, depending on whether the environment is from the
    >   interpreter, the in-core compiler, or the file compiler.  If
    >   MACROEXPAND or MACROEXPAND-1 is called directly without supplying
    >   the environment argument, the environment passed to any expander
    >   functions will have target EVAL.

    I really dislike this part of the proposal.  I hate to have to keep
    repeating myself, but there are other situations besides the three
    listed here in which code may be processed.  The example I've cited
    before is a filter that reads in code from a file, performs some
    preprocessing to decorate the code with lots of type declarations, and
    writes it out to another file.  I contend that anything that needs to
    know whether the code is being processed by the interpreter or
    compiler ought to be a special form (this includes EVAL-WHEN and
    whatever we decide to do about LOAD-TIME-EVAL) and should be left
    strictly alone by code walkers.

I think we have some confusion here between interpreter versus compiler
on the one hand, and operating in the local Lisp world versus outputting
to a file to be loaded later on the other hand.  I feel that it is
completely inappropriate to add something that distinguishes between
the compiler and the interpreter.  I'd like to see that part of the
proposal dropped.

The important distinction is between what I will call local environments
and remote environments.  A defining form (DEFUN, DEFVAR, DEFCLASS, etc.)
evaluated in a local environment affects the current Lisp world, but in
a remote environment it does not affect the current Lisp world, however
its effects still need to be remembered in a model of the Lisp world
that will be created later.  Both COMPILE-FILE and your example program
annotating program work with remote environments.  I defy you to come up
with an example where the local/remote environment distinction doesn't
make sense and a third type is needed.  Thus I think ENVIRONMENT-TARGET
would better be named ENVIRONMENT-REMOTE-P.


    As to the claim that CLOS needs this information, my understanding
    from reading 88-002R is that what CLOS really needs to store in the
    environment is information about the class hierarchy and which
    functions are generic functions.  (I'm guessing that the current
    implementation does not do this, and instead stores the information
    externally to the environment in different places depending on whether
    it's for the compiler or interpreter.)

Does (setf (gethash a ht) b) mean that b is a part of a?

Again the compiler/interpreter distinction is a red herring and CLOS has
no reason to care about that distinction.  The important distinction
is local/remote.  CLOS needs to know whether a DEFCLASS form changes the
behavior of objects of that class in the current world, or only affects
a future ("remote") world.  Whether this information is "inside" the
environment or "associated with" the environment is a red herring too,
I think; it's a matter of implementation, but has no effect on the
functional interface that the user sees.  I think it's better only to
standardize the one thing that has to be standardized, the local/remote
distinction, and leave the rest (the actual name<->object mapping) to
the discretion of individual implementations.  That way we'll get this
business over with quicker.

∂03-Oct-88  1959	CL-Compiler-mailer 	New Issue: SYNTACTIC-ENVIRONMENT-ACCESS 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Oct 88  19:58:45 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 469981; Mon 3-Oct-88 22:57:10 EDT
Date: Mon, 3 Oct 88 22:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, eb@lucid.com
cc: cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: <881002155456.5.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19881004025653.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

I agree with the general tenor of Kent's comments.  I'd like to see
an alternate version of the proposal written up that way, so we can
see the ramifications.

I also wonder about having separate accessors for scope, type, and
(for functions) inlinitude.  Would it be more or less elegant to
have a single accessor that returns all this information as multiple
values?  I'd say more elegant, although I'm not sure what happens
if the type was proclaimed but the inlinitude was declared.

∂03-Oct-88  2102	CL-Cleanup-mailer 	Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Oct 88  21:02:20 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA23101; Mon, 3 Oct 88 22:00:33 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA13928; Mon, 3 Oct 88 22:00:25 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810040400.AA13928@defun.utah.edu>
Date: Mon, 3 Oct 88 22:00:24 MDT
Subject: Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: Eric Benson <eb@lucid.com>, cl-compiler@sail.stanford.edu,
        cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 3 Oct 88 22:51 EDT

> Date: Mon, 3 Oct 88 22:51 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
> The important distinction is between what I will call local environments
> and remote environments.  A defining form (DEFUN, DEFVAR, DEFCLASS, etc.)
> evaluated in a local environment affects the current Lisp world, but in
> a remote environment it does not affect the current Lisp world, however
> its effects still need to be remembered in a model of the Lisp world
> that will be created later.  Both COMPILE-FILE and your example program
> annotating program work with remote environments.  I defy you to come up
> with an example where the local/remote environment distinction doesn't
> make sense and a third type is needed.  Thus I think ENVIRONMENT-TARGET
> would better be named ENVIRONMENT-REMOTE-P.

That's a very nice way to put it.  Rather than trying to introduce
*more* kinds of environments, I would actually go in the other
direction and say that code walkers shouldn't even need to know the
distinction between local and remote environments.  An implementation
ought to be free to use different representations for the two, but as
long as the accessors return the correct information, is there any
reason why you would need to know where it came from?

> Again the compiler/interpreter distinction is a red herring and CLOS has
> no reason to care about that distinction.  The important distinction
> is local/remote.  CLOS needs to know whether a DEFCLASS form changes the
> behavior of objects of that class in the current world, or only affects
> a future ("remote") world.

That's pretty much what I was trying to say: CLOS doesn't really need
to know whether the information is needed by the compiler or
interpreter or something else, as long as it finds the right
information. 

If the local/remote environment model is adopted (or even if we don't
provide any way to tell the difference between the two), some way
would have to be provided for a code walker to create a remote
environment.  The existing proposal assumes that everything the
compiler doesn't create must be an EVAL (that is, local) environment. 

One other thing I would like clarified.  It makes sense to be able to
have more than one distinct remote environment around at any given
time; for example, if COMPILE-FILE is called recursively it ought to
create a new remote environment for each file.  Does it make any sense
to have more than one distinct local environment around, or is there
only one?  I can imagine that a Lisp running on a non-shared-memory
parallel machine might want to maintain separate local environments on
each processor, for instance.  Would doing so automatically make that
Lisp not be Common Lisp? 

-Sandra
-------

∂04-Oct-88  1234	CL-Compiler-mailer 	Issue: WITH-COMPILATION-UNIT (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Oct 88  12:34:35 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA01381g; Tue, 4 Oct 88 11:32:02 PST
Received: by blacksox id AA00160g; Tue, 4 Oct 88 12:29:28 pdt
Date: Tue, 4 Oct 88 12:29:28 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8810041929.AA00160@blacksox>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Compiler@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: Kent M Pitman's message of Thu, 29 Sep 88 18:11 EDT <880929181138.2.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: WITH-COMPILATION-UNIT (Version 1)

Do you think there should be a way to "override" an existing
WITH-COMPILATION-UNIT, i.e. a way to start a new compilation unit
context?

∂05-Oct-88  1222	CL-Compiler-mailer 	Re: Issue COMPILER-LET-CONFUSION, version 1  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 5 Oct 88  12:21:53 PDT
Received: by ti.com id AA10998; Wed, 5 Oct 88 14:19:54 CDT
Received: from Kelvin by tilde id AA27285; Wed, 5 Oct 88 14:06:40 CDT
Message-Id: <2801070458-4525384@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 5 Oct 88  14:07:38 CDT
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 COMPILER-LET-CONFUSION, version 1
In-Reply-To: Msg of Wed, 28 Sep 88 12:29:41 MDT from sandra%defun@cs.utah.edu (Sandra J Loosemore)

> Proposal COMPILER-LET-CONFUSION:CLARIFY-STATUS-QUO:
...
>   Mention that there may be compatibility problems between compiled and
>   interpreted code if the interpreter performs macroexpansion in
>   parallel with evaluation.

This alternative might appear more attractive if it were clarified that
the "compatibility problems" only apply to macros used within function
definitions contained in the body since they are not executed during
execution of the COMPILER-LET.  For example, if MOO is a macro, then in

  (COMPILER-LET ((*MOO-FLAG* T))
    (MOO ...)
    (DEFUN FOO (...)
      (MOO ...)) )

the macro expansion of the first use of MOO will be able to access the
binding of *MOO-FLAG* on any implementation, but the second use of MOO
cannot portably depend on *MOO-FLAG*.

> Proposal COMPILER-LET-CONFUSION:REQUIRE-PREPASS:
> 
>   Disallow interpreters from performing macroexpansion concurrently with
>   evaluation.  Macroexpansion must be performed in a preprocessing
>   codewalk.

I'm leaning in favor of a variation of this approach that would say that
if an implementation does not normally do a preprocessing code walk, then
the evaluator's implementation of COMPILER-LET needs to do a macro
expansion code walk on its body forms before evaluating them.  We
currently do macro expansion as needed during evaluation, yet it would be
a trivial change to have COMPILER-LET invoke MACROEXPAND-ALL on its body.
This should only be a hardship for any implementation that doesn't do a
pre-pass and doesn't already have a MACROEXPAND-ALL.

∂05-Oct-88  1242	CL-Compiler-mailer 	Issue: DEFINE-OPTIMIZER  
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 5 Oct 88  12:41:50 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA02898; Wed, 5 Oct 88 12:35:41 PDT
Received: from lukasiewicz.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA15109; Wed, 5 Oct 88 12:38:05 PDT
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
	id AA09635; Wed, 5 Oct 88 11:31:32 PDT
Date: Wed, 5 Oct 88 11:31:32 PDT
From: jrose@Sun.COM (John Rose)
Message-Id: <8810051831.AA09635@lukasiewicz.sun.com>
To: jlm@lucid.com
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, pierson%mist@MULTIMAX.ARPA
Cc: sandra%defun@cs.utah.edu
Cc: CL-Compiler@sail.stanford.edu, common-lisp-object-system@sail.stanford.edu
In-Reply-To: Jim McDonald's message of Fri, 30 Sep 88 12:07:09 PDT <8809301907.AA01035@bhopal>
Subject: Issue: DEFINE-OPTIMIZER 

   Date: Wed, 28 Sep 88 15:32:23 PDT
   From: Jim McDonald <jlm@lucid.com>

   I would prefer to see a rule-based approach, at least as the normal
   way of declaring optimizations.  A more programmable approach would
   be used only when the rule processor is inadequate.

   E.g., I find it much easier to read rules of the form:

    ((<arg-type>*) <result-type> <rewrite-pattern>)
    or
    ((<arg-type>*) (<result-type>*) <rewrite-pattern>)

  ....
Hear, hear.  (See below.)


   Date: Wed, 28 Sep 88 17:07:21 MDT
   From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

   ...while I think that just about all
   compilers do some kind of pattern-matching transformations, everybody
   seems to use a different technique and syntax for specifying them, and
   we'd probably get into religious wars if we tried to standardize one
   or another of them.  (I know of at least a half-dozen different ones
   that have been used in the various compilers developed here at Utah
   within the past 2 or 3 years!)
Perhaps CLOS can eventually supply a partial consensus on how to organize
these things.  (See below.)

   Date: Thu, 29 Sep 88 11:20 EDT
   From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

   I think the way Symbolics does its optimizers (I haven't looked recently) is
   to allow multiple optimizers on a function and to give each a name, so that
   you can selectively redefine each. In effect, it defines

    INTERNAL-DEFINE-OPTIMIZER function optimizer-name bvl &BODY forms

   so that (effectively) you could define DEFINE-OPTIMIZER as 

    (DEFMACRO DEFINE-OPTIMIZER (NAME BVL &BODY FORMS)
      `(INTERNAL-DEFINE-OPTIMIZER ,NAME ANSI-CL-INTERFACE ,BVL ,@FORMS))

  ....
CLOS has a mechanism for named function parts; see below.


   Date: Fri, 30 Sep 88 12:07:09 PDT
   From: Jim McDonald <jlm@lucid.com>
  ...

   I should note that Lucid's compiler-macro facility allows one to
   define a symbol to be treated as a function at eval-time but a macro 
   at compile-time.  One obvious use of compiler-macros is to implement
   optimizers.  The drawback is the one I alluded to earlier -- there is
   just one compiler-macro for a symbol, so you run the risk of a
   brain-dead dotimes if you try to optimize it as in my example above.

   (I'd be tempted to suggest a compiler-macro-time analog to defadvice,
    but that seems too hairy, too dependent on the whole idea of
    compiler-macros, and too fraught with the dangers I railed against
    earlier.)
Yes it's hairy, but maybe we can lean on CLOS.

  ....

Attaching multiple transformation rules on one function seems superior
to having to express all the logic in a monolithic optimizer function.
After all, some Lisp functions will be complex enough to admit several
independent optimization strategies, each encodable by a different rule.
Perhaps two vendors or programmers want to add strategies to the same
function; it's unclear how to do this through a monolithic optimizer.

One might object that only the function's author should get to optimize
it, but that's not the case when the function is well-known and the
occasion for optimizing it arises when some specialized __argument__
appears for it.  E.g., (SQRT (MY-EXPONENTIAL X)) => (MY-EXPONENTIAL (/ X
2)), or perhaps something like (SEARCH WORD (MY-INDEXED-STRING X)) =>
(MY-INDEXED-SEARCH WORD X).

Even if it's agreed that we want multiple optimization rules on a single
function, there is still the problem of (1) arranging for the separate
compilation and eventual combination of the rules, and (2) specifying
the language(s) used to write the  patterns which guard the rules.

I believe CLOS supplies excellent answers to (1), and eventually will
enable an answer to (2).

It seems to me that, in the interests of economy, whenever there is a
situation in Common Lisp where multiple, separately compilable program
fragments are being combined into single functions (e.g., DEFADVICE,
optimizer rules), that service should be if at all possible supplied
by CLOS.  Using CLOS has a number of advantages:

 * Implementors have less work, since they use CLOS method combination
   machinery.  In some cases, they may only need to write a
   DEFINE-METHOD-COMBINATION which organizes the program fragments
   the way they want.

 * Users have a standard interface for defining, undefining, and
   querying for program fragments.

 * Any CLOS program management tools (e.g., browsers) are immediately
   applicable.

To summarize, you get the usual advantages of integration.

Classes per se needn't enter the picture at all.  I'm thinking of
something like this, for starters:

	(defmethod compiler:transform sqrt-exp ((fn (eql 'sqrt)) &rest args)
	  (backquote-case args
	    (`((my-exp ,x)) `(my-exp (/ ,x 2)))
	    (otherwise (call-next-method))))

(In place of the hypothetical BACKQUOTE-CASE, put your own favorite
pattern matcher.)  The key is using the method qualifier syntax
(SQRT-EXP, here) for differentiating fragments of code.  If the CLOS
specializer syntax is usable ((EQL 'SQRT), here), that's great, but
unspecialized methods are perfectly valid too.

[Parenthetical Note:  To implement advice this way, you'd probably want
 to introduce a new function specifier syntax, analogous (SETF FOO):
	(defmethod (advise foo) :before ensure-open-foo-files (&rest ignore)
	  (declare (ignore ignore))
	  (unless (foo-files-open-p) (open-foo-files)))
 Note that use of two method qualifiers.  That's OK, and the abstraction's
 DEFINE-METHOD-COMBINATION declaration gets to assign the appropriate
 meaning to them.]

That should show how CLOS addresses problem (1), of managing code
fragments.

Problem (2), the construction of rule guard patterns, may be partially
addressible in CLOS, some day.  The key is realizing that your favorite
pattern language for Lisp forms probably has enough structure to impose a
type/subtype structure on the universe of Lisp forms.  In other words,
it makes sense to pretend that patterns in your language (e.g.,
`((my-exp ,x)) above) define form types, and that there is an inclusion
structure on these types, with less specific patterns being supertypes.
(When talking about these issues to the CLOS people, I have referred to
such a system of patterns or predicates as a "description language".)

If CLOS provides enough extensibility of specializer syntax (and that's
a big if, actually), it will be possible to express optimizer rules
even more cleanly, using CLOS.  Here's a final example, in which
a form-discriminating specializer is used (with a syntax pulled
out of a hat, I admit):

	(defmethod compiler:transform ((:form `(sqrt (my-exp ,x))))
	  `(my-exp (/ ,x 2)))

Note that since the specializers suffice to differentiate the rules,
there is less need for qualifiers (e.g., the symbol SQRT-EXP above).

The CLOS spec. does not discuss extensibility of specializers, yet.
For this, we await the famous but mysterious third chapter of the spec,
the Meta-Object Protocol.

By the way, a useful second argument to COMPILER:OPTIMIZE
would be an environment, to allow for type checking or macroexpansion.

I've used list structure patterns in the examples above, but I
could equally well have used patterns which discriminated things
like declared type, if I understood enough about Lisp compiler
type inference to construct a plausible example.

As Sandra says, there are any number of pattern languages out there.
I'm certainly not suggesting it's easy to settle on one, but I am
saying that using CLOS would help us settle some of the simpler issues
(like separate compilation of rules), allowing us to devote more energy
to the hard ones (like pattern languages).  In fact, I don't see why
several pattern languages couldn't be used in the same Lisp.  After all,
EQL and class specializers co-exist now, and they could be viewed as two
different languages.

The bottom line is that CLOS has a lot of services to offer, and Common
Lisp should take advantage of them where possible.

				-- John

∂05-Oct-88  1351	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 5 Oct 88  13:50:59 PDT
Received: by ti.com id AA11630; Wed, 5 Oct 88 15:49:07 CDT
Received: from Kelvin by tilde id AA29656; Wed, 5 Oct 88 15:36:10 CDT
Message-Id: <2801075825-4847880@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 5 Oct 88  15:37:05 CDT
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 DEFCONSTANT-VALUE
In-Reply-To: Msg of Thu, 29 Sep 88 18:59:43 MDT from sandra%defun@cs.utah.edu (Sandra J Loosemore)

> I would like to see some mention in this proposal of what users are
> supposed to do if the constant value truly cannot be computed at
> compile time and you do want nasty things to happen if the user
> rebinds or SETQs the variable.  (For example, perhaps the constant
> holds some value that is specific to the particular machine the Lisp
> is running on, such as the amount of physical memory.)

Well, let's see.   You've got something like

  (DEFCONSTANT MEMORY-SIZE (DETERMINE-MEMORY-SIZE))

and you want the value computed at load time, which means that references
to MEMORY-SIZE later in the same file will need to be compiled like a
special variable access.  So you compile the file and load the object, at
which time MEMORY-SIZE is given a value.  Now, when someone compiles
another file which uses MEMORY-SIZE, they will be prevented from altering
it as you wish.  However, since the value is presumably a number, there is
nothing to prevent the value from being wired in to their compiled code,
which means that their object file won't work right if loaded on another
machine with a different amount of memory.  So it doesn't appear that this
example will work meaningfully with any of the current proposals for
DEFCONSTANT.

What you probably want is a new construct midway between DEFCONSTANT and
DEFPARAMETER which has the feature of preventing run-time alteration, but
never permits the compiler to wire in the value.  It happens that the
Explorer has such a capability that is used internally for system
quantities where run-time alteration could crash the system, but we don't
want the value wired into object files in order to avoid incompatibilities
between software releases.  I haven't heard any one before desiring to
have that capability available to users, but I wouldn't object to the
idea.  Now, if we can just think of a word similar to "constant" but less
so ... anyone have a thesaurus handy?

∂05-Oct-88  1453	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 5 Oct 88  14:53:06 PDT
Received: by ti.com id AA12029; Wed, 5 Oct 88 16:51:40 CDT
Received: from Kelvin by tilde id AA00156; Wed, 5 Oct 88 15:57:05 CDT
Message-Id: <2801077081-4923289@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 5 Oct 88  15:58:01 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@lucid.com>
Cc: CL-Compiler@SAIL.Stanford.edu
Subject: Re: Issue DEFCONSTANT-VALUE
In-Reply-To: Msg of Sat, 1 Oct 88 16:52:06 PDT from Jon L White <jonl@lucid.com>

> But the second part of your proposal, while laudable in my
> opinion, is not at all what Lucid does:
>     . . . The value form
>     will be evaluated at compile-time, with the resulting value being 
>     used to SETQ the symbol at load time, ... 
> Several other vendors I've looked at seem to do no constant folding 
> whatsoever; Lucid does some constant folding, but gives absolutely 
> no guarantee just what things will be folded and under what 
> circumstances.  For constants that are not "folded", the SETQ 
> performed at runtime does a completely fresh re-calculation at
> load-time.  

I agree that this part is not as clear-cut and I don't have strong
feelings about it.  Since my implementation does do extensive constant
folding, it seemed that consistency would be maximized by ensuring that
the constant didn't end up with a value different from what was wired in
to the code in the same file.  Maybe we should just leave this unspecified
in accordance with proposal COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY, which
says:

  Except as noted, the behavior of user programs is unspecified in
  situations where the information is defined differently at runtime than
  at compiletime, since the user cannot depend upon which will take
  precedence in a particular implementation.

In other words, if the value is the same either way, then it doesn't
matter, and if there is a difference, then that is an error.

∂05-Oct-88  1503	CL-Compiler-mailer 	Re: Issue COMPILER-LET-CONFUSION, version 1  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 5 Oct 88  15:03:44 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA23416; Wed, 5 Oct 88 16:02:13 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA14907; Wed, 5 Oct 88 16:02:11 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810052202.AA14907@defun.utah.edu>
Date: Wed, 5 Oct 88 16:02:10 MDT
Subject: Re: Issue COMPILER-LET-CONFUSION, version 1
To: David N Gray <Gray@dsg.csc.ti.com>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Wed, 5 Oct 88  14:07:38 CDT

> Date: Wed, 5 Oct 88  14:07:38 CDT
> From: David N Gray <Gray@DSG.csc.ti.com>
> 
> > Proposal COMPILER-LET-CONFUSION:CLARIFY-STATUS-QUO:
> 
> This alternative might appear more attractive if it were clarified that
> the "compatibility problems" only apply to macros used within function
> definitions contained in the body since they are not executed during
> execution of the COMPILER-LET.

No, there are other cases as well.  Consider this one:

    (eval-when (eval compile load)
        (defvar *silly* nil)
        (defmacro silly-macro () `(quote ,*silly*)))

    (let ((*silly*  (cons 'let *silly)))
        (compiler-let ((*silly* (cons 'compiler-let *silly*)))
	    (silly-macro)))

If the interpreter performs evaluation in parallel with macro expansion, 
then SILLY-MACRO will see the value of *SILLY* as (COMPILER-LET LET),
but in the compiler (or a preprocessing interpreter) it will only see it
as (COMPILER-LET).  Of course, similar problems can occur when macros
rely the values of special variables, even when COMPILER-LET is not
involved.

You're right, though -- the writeup should go into more detail on this.


> > Proposal COMPILER-LET-CONFUSION:REQUIRE-PREPASS:
> 
> I'm leaning in favor of a variation of this approach that would say that
> if an implementation does not normally do a preprocessing code walk, then
> the evaluator's implementation of COMPILER-LET needs to do a macro
> expansion code walk on its body forms before evaluating them.  We
> currently do macro expansion as needed during evaluation, yet it would be
> a trivial change to have COMPILER-LET invoke MACROEXPAND-ALL on its body.
> This should only be a hardship for any implementation that doesn't do a
> pre-pass and doesn't already have a MACROEXPAND-ALL.

I suspect that most implementations that don't do a code-walking prepass
in the interpreter don't have anything like MACROEXPAND-ALL, either, so
this may not really buy anything.  I suppose this could be presented as
yet another alternative in the next iteration of the writeup on this
issue.  Does anybody else like this idea?

-Sandra
-------

∂05-Oct-88  1533	CL-Compiler-mailer 	Re: Issue COMPILER-LET-CONFUSION, version 1  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Oct 88  15:33:11 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 471332; Wed 5-Oct-88 18:29:29 EDT
Date: Wed, 5 Oct 88 18:29 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue COMPILER-LET-CONFUSION, version 1
To: sandra%defun@cs.utah.edu
cc: Gray@dsg.csc.ti.com, cl-compiler@sail.stanford.edu
In-Reply-To: <8810052202.AA14907@defun.utah.edu>
Message-ID: <881005182914.0.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Wed, 5 Oct 88 16:02:10 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    ...
    > > Proposal COMPILER-LET-CONFUSION:REQUIRE-PREPASS:
    > 
    > I'm leaning in favor of a variation of this approach that would say that
    > if an implementation does not normally do a preprocessing code walk, then
    > the evaluator's implementation of COMPILER-LET needs to do a macro
    > expansion code walk on its body forms before evaluating them.  We
    > currently do macro expansion as needed during evaluation, yet it would be
    > a trivial change to have COMPILER-LET invoke MACROEXPAND-ALL on its body.
    > This should only be a hardship for any implementation that doesn't do a
    > pre-pass and doesn't already have a MACROEXPAND-ALL.

    I suspect that most implementations that don't do a code-walking prepass
    in the interpreter don't have anything like MACROEXPAND-ALL, either, so
    this may not really buy anything.  I suppose this could be presented as
    yet another alternative in the next iteration of the writeup on this
    issue.  Does anybody else like this idea?

If you mean REQUIRE-PREPASS -- yes, I certainly do.

∂05-Oct-88  1539	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 5 Oct 88  15:39:00 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA25066; Wed, 5 Oct 88 16:37:30 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA14938; Wed, 5 Oct 88 16:37:25 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810052237.AA14938@defun.utah.edu>
Date: Wed, 5 Oct 88 16:37:24 MDT
Subject: Re: Issue DEFCONSTANT-VALUE
To: David N Gray <Gray@dsg.csc.ti.com>
Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore),
        CL-Compiler@sail.stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Wed, 5 Oct 88  15:37:05 CDT

> Date: Wed, 5 Oct 88  15:37:05 CDT
> From: David N Gray <Gray@DSG.csc.ti.com>
> 
> Well, let's see.   You've got something like
> 
>   (DEFCONSTANT MEMORY-SIZE (DETERMINE-MEMORY-SIZE))
> 
> and you want the value computed at load time, which means that references
> to MEMORY-SIZE later in the same file will need to be compiled like a
> special variable access.  So you compile the file and load the object, at
> which time MEMORY-SIZE is given a value.  Now, when someone compiles
> another file which uses MEMORY-SIZE, they will be prevented from altering
> it as you wish.  However, since the value is presumably a number, there is
> nothing to prevent the value from being wired in to their compiled code,
> which means that their object file won't work right if loaded on another
> machine with a different amount of memory.  So it doesn't appear that this
> example will work meaningfully with any of the current proposals for
> DEFCONSTANT.

Sigh, you're right.  The conclusion we appear to be heading towards is
that constants must really be constant -- in order to allow the compiler
to "wire in" values, the value form passed to DEFCONSTANT must always 
evaluate to EQL values.  In theory, this means that putting something like

    (defconstant foo '(a b c))

in a file is wrong, because the value the compiler sees at compile time
is almost certainly not going to be EQL to the value asssigned to FOO if you
then immediately load the compiled file!

I don't know if dealing with cross-compilation issues fall within our
charter, but a number of the built-in constants like
SINGLE-FLOAT-EPSILON violate this rule.  The value the cross-compiler
is allowed to "wire in" to the code is the value for the target
machine, which may not even be representable on machine where the
compilation is taking place....

> What you probably want is a new construct midway between DEFCONSTANT and
> DEFPARAMETER which has the feature of preventing run-time alteration, but
> never permits the compiler to wire in the value.

Alternatively, we might either change DEFCONSTANT to not allow the
compiler to "wire in" the values of constants, or change the
definition of DEFPARAMETER to say that it should signal a warning (to
use the new error terminology) if the symbol is rebound or SETQ'd.

In any case, I think this issue is more or less independent of whether or
not DEFCONSTANT evaluates its value form at compile time.  It would be
nice if we could get one coherent proposal that takes care of all the
issues, though.  

-Sandra
-------

∂05-Oct-88  1539	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE   
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.Stanford.EDU with TCP; 5 Oct 88  15:39:19 PDT
Received: from DOUGHNUT.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 59468; Wed 5-Oct-88 18:26:22 EDT
Date: Wed, 5 Oct 88 18:27 EDT
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: Re: Issue DEFCONSTANT-VALUE
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Sandra J Loosemore <sandra%defun@CS.UTAH.EDU>, CL-Compiler@SAIL.STANFORD.EDU
In-Reply-To: <2801075825-4847880@Kelvin>
Message-ID: <19881005222758.8.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Sender: miller@CS.ROCHESTER.EDU
Reply-To: miller@CS.ROCHESTER.EDU
Organization: University of Rochester, Department of Computer Science
Postal-address: 610 CS Building, Comp Sci Dept., U. Rochester, Rochester NY 14627
Phone: 716-275-1118

    Date: Wed, 5 Oct 88  15:37:05 CDT
    From: David N Gray <Gray@DSG.csc.ti.com>

    What you probably want is a new construct midway between DEFCONSTANT and
    DEFPARAMETER which has the feature of preventing run-time alteration, but
    never permits the compiler to wire in the value.  It happens that the
    Explorer has such a capability that is used internally for system
    quantities where run-time alteration could crash the system, but we don't
    want the value wired into object files in order to avoid incompatibilities
    between software releases.  I haven't heard any one before desiring to
    have that capability available to users, but I wouldn't object to the
    idea.  Now, if we can just think of a word similar to "constant" but less
    so ... anyone have a thesaurus handy?

How about a generalization which I would find tremendously useful: single
assignment variables!!
----
Brad Miller		U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}

∂05-Oct-88  1558	CL-Cleanup-mailer 	New Issue: SYNTACTIC-ENVIRONMENT-ACCESS  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 5 Oct 88  15:58:06 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03107g; Wed, 5 Oct 88 14:55:15 PST
Received: by bhopal id AA02053g; Wed, 5 Oct 88 15:54:49 PDT
Date: Wed, 5 Oct 88 15:54:49 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810052254.AA02053@bhopal>
To: sandra%defun@cs.utah.edu
Cc: Moon@stony-brook.scrc.symbolics.com, eb@SAIL.Stanford.EDU,
        cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 3 Oct 88 22:00:24 MDT <8810040400.AA13928@defun.utah.edu>
Subject: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS

re:  It makes sense to be able to have more than one distinct remote 
     environment around at any given  time; ...
     Does it make any sense to have more than one distinct local 
     environment around, or is there only one?  

Lucid's "retargetable" compiler indeed contains, potentially, dozens 
of encapsulations of "remote environments" as so-called "compiler
machines".  The idea is to cross-compile from an image running on, say,
a Sun3 to targets as diverse as the SPARC and 80386 at essentially
"the same time".  See our paper in the 1986 Lisp Conferences on a
Dynamically Retargetable Compiler.

I had imagined that "local" environment meant the purely syntatic
information directly visible in the s-expression being viewed as
code; e.g., what names appear in a lambda or let binding, what
names appear in declare forms, etc.  Is that more limiting that 
what you had in mind?

I've given eb (Eric Benson) extensive comments on this proposal
verbally, and will not repeat them here.  He is preparing a new
version incorporating the various ideas that have arisen during
the past couple days, and will mail that out shortly.


-- JonL --

∂05-Oct-88  1706	CL-Compiler-mailer 	Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 5 Oct 88  17:06:34 PDT
Received: by ti.com id AA13132; Wed, 5 Oct 88 19:04:59 CDT
Received: from Kelvin by tilde id AA03728; Wed, 5 Oct 88 18:57:47 CDT
Message-Id: <2801087917-5574358@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 5 Oct 88  18:58:37 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Eric Benson <eb@lucid.com>
Cc: cl-compiler@sail.stanford.edu, masinter.pa@Xerox.COM
Subject: Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
In-Reply-To: Msg of Sun, 2 Oct 88 11:30:37 pdt from Eric Benson <eb@lucid.com>

>     Also, it has
>  proven impossible to write a portable code walker in Common Lisp, due
>  to insufficient access to the information contained in environments
>  and the inability to augment environments with local function
>  definitions.

I can see how writing a code walker is easier if you can augment the
local macro information, but I don't see what all the rest of this stuff
is needed for.

> Proposal (SYNACTIC-ENVIRONMENT-ACCESS:ADD-FUNCTIONAL-INTERFACE):
> 
>  The following functions provide information about syntactic
>  environment objects.  In all of the functions the argument named ENV
>  is a environment, of the sort received by the &ENVIRONMENT argument
>  to a macro.  In all cases it is an error to supply an argument which
>  is not a syntactic environment.

I would like to add that it is an error to use an environment object
outside of the dynamic extent of the macro expander invocation which
received it as an &ENVIRONMENT argument.  This proposal would be much
easier to implement if the implementation of these accessors were
permitted to, for example, recognize that the environment is a compilation
environment and then fetch the information from wherever the compiler
keeps it, than if the compiler's data structures had to be redesigned to
actually store all of the information in environment objects having
indefinite extent.

>  ENVIRONMENT-TARGET env				[Function]
> 
>   This function returns one of the three symbols EVAL, COMPILE or
>   COMPILE-FILE, depending on whether the environment is from the
>   interpreter, the in-core compiler, or the file compiler. 

I agree with Moon's comments that the real issue is local versus remote.

>  ENVIRONMENT-OPTIMIZE-LEVEL attribute env	[Function]
> 
>   ATTRIBUTE is one of the symbols SPEED, SPACE, SAFETY or
>   COMPILATION-SPEED.  This function returns an integer between 0 and
>   3, which reflects the current settings of the OPTIMIZE proclamation
>   or declaration.

I hope this doesn't require an evaluator to keep track of OPTIMIZE
declarations even though it has no use for them itself.

> Rationale:
> 
>  This proposal provides a portable interface to environment
>  information which must otherwise be obtained by
>  implementation-dependent means.  The ENSURE-GENERIC-FUNCTION and
>  FIND-CLASS functions of CLOS require the ENVIRONMENT-TARGET function. 

Yes, but I'm not sure that there is anything that can be portably done
with that information.  Just because the implementation needs to do
something is not sufficient justification for making it available to
users.  In this case, I suspect that CLOS is going to need more than
ENVIRONMENT-TARGET to do everything it needs to do.

>    A
>  useful code walker requires the capability of adding local function
>  definitions to an environment.

So who requires the other capabilities?

∂06-Oct-88  1038	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 6 Oct 88  10:38:35 PDT
Received: by ti.com id AA19035; Thu, 6 Oct 88 12:36:09 CDT
Received: from Kelvin by tilde id AA20490; Thu, 6 Oct 88 11:50:24 CDT
Message-Id: <2801148659-9223820@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 6 Oct 88  11:50:59 CDT
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 DEFCONSTANT-VALUE
In-Reply-To: Msg of Wed, 5 Oct 88 16:37:24 MDT from sandra%defun@cs.utah.edu (Sandra J Loosemore)

>   The conclusion we appear to be heading towards is
> that constants must really be constant -- in order to allow the compiler
> to "wire in" values, the value form passed to DEFCONSTANT must always 
> evaluate to EQL values.  In theory, this means that putting something like
> 
>     (defconstant foo '(a b c))
> 
> in a file is wrong, because the value the compiler sees at compile time
> is almost certainly not going to be EQL to the value asssigned to FOO if you
> then immediately load the compiled file!

I wouldn't say that this is wrong; even though the compiler can't in
general wire in the value, that doesn't affect the programmer's intent.
The compiler can take some advantage of the constant declaration, though.
For example, if it sees the form
  (IF (MEMBER 'B FOO) 'YES 'NO)
it could fold this to 'YES since that doesn't depend on EQL-ness of the
list.  Similarly, the form (POSITION X FOO) could be optimized to use some
internal function like POSITION-IN-LIST-EQ since FOO is known to be a list
of symbols.

This has a parallel in conventional languages, where, for example, a named
string constant may end up getting compiled into the same object code as
if it had been declared as a static variable with an initial value, but
the programmer doesn't need to be aware of that.

> I don't know if dealing with cross-compilation issues fall within our
> charter, but a number of the built-in constants like
> SINGLE-FLOAT-EPSILON violate this rule.  The value the cross-compiler
> is allowed to "wire in" to the code is the value for the target
> machine, which may not even be representable on machine where the
> compilation is taking place....

Cross-compilation requires a global target environment which can shadow
the current running global environment, so you could define
SINGLE-FLOAT-EPSILON however you wanted in the target environment.  But
this is beyond what we intend the standard to deal with.

∂06-Oct-88  1437	CL-Compiler-mailer 	Issue DEFCONSTANT-VALUE (V2)  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 6 Oct 88  14:36:42 PDT
Received: by ti.com id AA20699; Thu, 6 Oct 88 16:35:24 CDT
Received: from Kelvin by tilde id AA26335; Thu, 6 Oct 88 16:23:58 CDT
Message-Id: <2801165093-10211223@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 6 Oct 88  16:24:53 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Compiler@SAIL.Stanford.edu
Subject: Issue DEFCONSTANT-VALUE (V2)

I have updated the "proposal" and "current practice" sections of this in
response to comments received.  A companion proposal to address the
issue of constants computed at load-time will follow in a separate
message.
 

Issue:		DEFCONSTANT-VALUE
References:	Proposal COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
		  section (2)
Category:	CHANGE to previous proposal; CLARIFICATION to CLtL
Edit History:	29 Sept 1988, V1 by David Gray
		 6 Oct  1988, V2 by David Gray - Update proposal to remove
			prohibition against re-evaluating at load time, and
			specify null environment.  Add Lucid to current
			practice.

Status:		For internal discussion 
 
Problem Description:

  CLtL does not specify when the value form of a DEFCONSTANT is evaluated;
  this is clarified in COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
  but in an unacceptable way.
  
  The DEFCONSTANT macro does two things beyond what DEFPARAMETER does:

    1. It makes it possible for the compiler to replaces references with
       the value at compile time instead of at run time. 

    2. It causes the compiler to complain if the user attempts to SETQ
       or re-bind the constant name.

  These two things give rise to two different views of what the purpose
  of DEFCONSTANT is:

    1. The purpose of DEFCONSTANT is to facilitate compile-time
       substitution of the values of named constants.  A consequence of
       this is that alteration by SETQ or binding should not be
       permitted.
  or 
    2. The purpose of DEFCONSTANT is to declare that the value must not
       be changed at run time.  A side-effect of this is that, under
       certain circumstances, the compiler may be able to substitute the
       value for the reference at compile time.

  The specification of DEFCONSTANT in proposal
  COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY seems to assume the
  second purpose above, which has the effect of severely limiting its
  usefulness for the first purpose.  I contend that this is a mistaken
  viewpoint and that the definition of DEFCONSTANT should be guided by
  the first purpose above.  

  The concept of named constants was introduced into programming
  languages largely to avoid having "magic numbers" scattered throughout
  the code.  By giving the value a meaningful name and defining it in
  just one place, the code is easier to understand and it is much easier
  to change the value if necessary.  In order to encourage this
  programming style of using named constants, it has always been assumed
  that there should be no loss of efficiency from "doing it the right
  way".  Thus, the compiler should substitute the value for each
  reference and the resulting object code will be just as efficient as
  if the number had been used directly.

  For example, Pascal has constant declarations that look like this:

    const MaxIndex = 100;
	  MaxCount = 101;

  Since there are often cases where the value of one constant depends on
  another, many Pascal implementations extend this to permit the value
  to be an expression that depends on previous constants and is
  evaluated at compile time:

    const MaxIndex = 100;
	  MaxCount = MaxIndex+1;

  This extension has been carried over into Modula and Ada, and even
  FORTRAN 77 has this functionality in its PARAMETER statement.  (On the
  other hand I don't know of any language that has functionality that
  says to compute a name's value at load time but don't permit it to be
  changed at run time.)  Now the obvious equivalent in Common Lisp would
  be:

    (defconstant max-index 100)
    (defconstant max-count (1+ max-index))

  But, according to the specification of DEFCONSTANT in proposal
  COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY, in order to get the
  same effect (i.e. ensuring compile-time substitution of the value),
  the user would have to write:

    (eval-when (eval compile load)
      (defconstant max-index 100))
    (defconstant max-count #.(1+ max-index))

  The #. is needed to cause the value to be evaluated at compile time
  and the EVAL-WHEN is needed to ensure that the first constant will be
  defined for use by #. .  However, if the second constant were going
  to be referenced by another constant definition later, then it would
  need to be:

    (eval-when (eval compile load)
      (defconstant max-index 100))
    (eval-when (eval compile load)
      (defconstant max-count #.(1+ max-index)))

  Note that separate EVAL-WHEN forms are required in order for the #. to
  work right.  I contend that this is getting much too complicated for
  something that started out as a simple and very typical example.

  It is true that a smart compiler would be able to optimize the simpler
  example (without EVAL-WHEN and #.) in certain limited cases, but if
  the user can't rely on this, then the effect would be to either
  discourage the use of named constants or to encourage frequent use of
  EVAL-WHEN and #. .

Proposal DEFCONSTANT-VALUE:COMPILE-TIME:
 
  Replace the paragraph describing DEFCONSTANT in proposal
  COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY with the following.
  
  DEFCONSTANT: The compiler must recognize the symbol as being constant
  (for example, to suppress warnings about references to the symbolic
  constant as an unbound variable or to enable warnings about binding or
  SETQ'ing the constant in the code being compiled).  The value form may
  be evaluated at compile-time in the null lexical environment in order to
  be be available for the compiler to substitute in when compiling
  references to the constant name (as described on pages 68-69 of CLtL)
  and when evaluating the value forms of subsequent DEFCONSTANTs.  (The
  value may also be useful to guide optimization even in cases where value
  substitution is not permitted.)  It is implementation dependent whether
  or not the symbol value is actually set at compile time or whether
  COMPILE-FILE temporarily remembers the value in some other way.  It is
  an error for the value expression to have a different value at load time
  than it had at compile-time, so it is implementation-dependent whether
  the expression is re-evaluated at load time or loads the compile-time
  value.

 Rationale:
 
  This makes the semantics of DEFCONSTANT consistent with constant
  declarations in other languages; thus this is a tried and proven
  approach and will reduce confusion for programmers moving from one
  language to another.  

  Run-time efficiency of compiled code seems a more important
  consideration than the ability to protect a load-time value from
  re-assignment at run-time.
 
 Current Practice:

  The Explorer has done it this way since release 3.0 and we have not
  received any complaints saying that this was a mistake.  Before then,
  the heuristic used to decide whether it was safe to compute and
  propagate the value at compile time led to inconsistent and confusing
  behavior.  In order to minimize incompatibility, if there is an error
  during evaluation of the value form, the error is reported as a
  compiler warning and the compiler causes the evaluation to be tried
  again at load time, so missing information at compile time is not a
  fatal error.

  Lucid also conforms to this proposal.
 
 Cost to implementors:

  The simple approach of just having DEFCONSTANT expand to (EVAL-WHEN
  (EVAL COMPILE LOAD) ...) would be trivial to implement.  A little more
  work in the compiler would be needed if the value were to be remembered
  temporarily during COMPILE-FILE, but this would be less effort than it
  would take to implement the optimizations permitted by the previous
  proposal.
 
 Cost to users:

  Some changes to user's code are likely to be required, such as wrapping
  an EVAL-WHEN around a DEFUN that is used later in the same file to
  compute the value of a DEFCONSTANT.  For the most part these changes
  will be obvious enough from the errors reported from attempting to
  evaluate the value form.  In some cases, the user may decide that using
  DEFPARAMETER is more appropriate.  There might be more subtle
  differences in behavior in cases where the compile-time and load-time
  values of the constant differ, but they are likely to be a problem
  regardless of which direction the issue is clarified.
  
 Benefits:

  The use of DEFCONSTANT will be simplified since efficient code can be
  generated without requiring the user to explicitly specify what needs
  to be done when.

 Costs of Non-Adoption: 

  Letting COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY stand will mean
  that it will be difficult for users to understand how to use DEFCONSTANT
  to get it to do what they want.

 Aesthetics:
 
  Are improved since the need to use EVAL-WHEN and #. is minimized.
 
 Discussion:

∂06-Oct-88  1452	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 6 Oct 88  14:51:37 PDT
Received: by ti.com id AA20804; Thu, 6 Oct 88 16:49:33 CDT
Received: from Kelvin by tilde id AA26575; Thu, 6 Oct 88 16:31:15 CDT
Message-Id: <2801165525-10237139@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 6 Oct 88  16:32:05 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore),
        CL-Compiler@SAIL.Stanford.edu
Subject: Re: Issue DEFCONSTANT-VALUE
In-Reply-To: Msg of Wed, 5 Oct 88 16:37:24 MDT from sandra%defun@cs.utah.edu (Sandra J Loosemore)

> > What you probably want is a new construct midway between DEFCONSTANT and
> > DEFPARAMETER which has the feature of preventing run-time alteration, but
> > never permits the compiler to wire in the value.
> 
> Alternatively, we might either change DEFCONSTANT to not allow the
> compiler to "wire in" the values of constants, or change the
> definition of DEFPARAMETER to say that it should signal a warning (to
> use the new error terminology) if the symbol is rebound or SETQ'd.
> 
> In any case, I think this issue is more or less independent of whether or
> not DEFCONSTANT evaluates its value form at compile time.  It would be
> nice if we could get one coherent proposal that takes care of all the
> issues, though.  

Following is a hasty draft of a proposal for a new form in between
DEFPARAMETER and DEFCONSTANT.  I'm calling it DEFPARAMETER-UNALTERABLE
here, but don't especially like that name and invite any suggestions for
a better name.



Issue:	       DEFCONSTANT-NOT-WIRED

References:    CLtL pages 68-69
	       
Related issues: Proposals DEFCONSTANT-VALUE:COMPILE-TIME and
	       COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY

Category:      ADDITION

Edit history:  6 Oct 1988, V1 by David Gray

Problem description:

  As discussed in issue DEFCONSTANT-VALUE, there are two possible views
  of what the purpose of DEFCONSTANT is.  Proposal
  DEFCONSTANT-VALUE:COMPILE-TIME resolves the controversy in favor of
  maximizing opportunities for the compiler to substitute the value for
  references to the constant.

  There may, however, still be cases where one would like to have the
  functionality of prohibiting run-time alteration of a value (like
  DEFCONSTANT), but have the value computed at load time and not be
  wired in (like DEFPARAMETER).  

Proposal DEFCONSTANT-NOT-WIRED:NEW-MACRO

  Add a new macro to the language:

    DEFPARAMETER-UNALTERABLE name value [documentation]

  which is like DEFPARAMETER except that, like DEFCONSTANT, any further
  assignment to or binding of that special variable is an error.  Unlike
  DEFCONSTANT, the compiler is not licensed to build assumptions about
  the value into programs being compiled.

 Examples:

  (DEFPARAMETER-UNALTERABLE MEMORY-SIZE (DETERMINE-MEMORY-SIZE))

  computes at load-time the value of parameter MEMORY-SIZE, which can
  then be used in subsequent initialization to control the allocation of
  data structures for an application.  Once these structures are
  created, changing this parameter would make no sense and might even
  break the program.  A DEFCONSTANT is not appropriate because the value
  needs to be computed at load time and because the value must not be
  wired in to any files compiled later or else those object files could
  not be used on another machine with a different memory size.

 Rationale:

  This provides the functionality desired by those who are reluctant to
  see DEFCONSTANT defined to compute the value at compile time.

 Current practice:
  
  The Explorer has an equivalent capability which is used internally for
  various system parameters, since changing them could crash the system,
  but the value should not be wired in to object files in order to
  maintain object compatibility between software releases.

 Cost to Implementors:

  This should be easy to add since it is just a different combination of
  functionality which is already present for DEFPARAMETER and
  DEFCONSTANT.

 Cost to Users:

  None, since this is an upward-compatible compatible addition.

 Cost of non-adoption:

  Continued confusion from the desire to use DEFCONSTANT for situations
  that it isn't quite right for.

 Performance impact:  None.

 Benefits:

  Provides a more complete set of options to the user.

 Esthetics:
 
  Complicates the language by adding one more form, but having this as a
  separate feature facilitates giving a clear and simple definition to
  DEFCONSTANT.

Discussion:

∂06-Oct-88  1521	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE (V2)   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 6 Oct 88  15:21:08 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA07343; Thu, 6 Oct 88 16:19:30 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA15555; Thu, 6 Oct 88 16:19:27 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810062219.AA15555@defun.utah.edu>
Date: Thu, 6 Oct 88 16:19:26 MDT
Subject: Re: Issue DEFCONSTANT-VALUE (V2)
To: David N Gray <Gray@dsg.csc.ti.com>
Cc: CL-Compiler@sail.stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Thu, 6 Oct 88  16:24:53 CDT

I still have a couple of nits to pick with this proposal.

  The value form may
  be evaluated at compile-time in the null lexical environment [...]
  It is
  an error for the value expression to have a different value at load time
  than it had at compile-time [...]

I'm still not clear on whether you want the run-time evaluation of the
value form to happen in a null lexical environment as well.  If not, I
think the proposal should include some strong warnings about it, since
that would be a likely source of getting different values at load time
than at compile time.

  Lucid also conforms to this proposal.

My understanding of JonL's comments on this were that Lucid only does
compile-time evaluation of the value form when the DEFCONSTANT appears
at top-level.

 
 Cost to implementors:

  The simple approach of just having DEFCONSTANT expand to (EVAL-WHEN
  (EVAL COMPILE LOAD) ...) would be trivial to implement.  A little more
  work in the compiler would be needed if the value were to be remembered
  temporarily during COMPILE-FILE, but this would be less effort than it
  would take to implement the optimizations permitted by the previous
  proposal.

I think this is a red herring.  If you're going to go through the work
of implementing a way to temporarily remember values of constants
seen by the compiler, is one call to CONSTANTP going to make any
difference?

Here is one way of implementing DEFCONSTANT that is consistent with
your proposal:

(defmacro defconstant (name initial-value &optional documentation-string)
    `(progn
	 (eval-when (compile)
	     (make-symbol-constant-in-compiler ',name)
	     (remember-constant-in-compiler ',name ,initial-value))
	 (make-symbol-constant ',name)
	 (setq ,name ,initial-value)
	 (setf (documentation ',name 'variable) ',documentation-strng)
	 ',name))


And here is one way of implementing DEFCONSTANT that is consistent with
my original proposal:

(defmacro defconstant (name initial-value &optional documentation-string)
    `(progn
	 (eval-when (compile)
	     (make-symbol-constant-in-compiler ',name)
	     ,(if (constantp initial-value)
		  `(remember-constant-in-compiler ',name ,initial-value)))
	 (make-symbol-constant ',name)
	 (setq ,name ,initial-value)
	 (setf (documentation ',name 'variable) ',documentation-strng)
	 ',name))

Not much difference between the two, hmmm?  Seeing as though it only took
me about 5 minutes to compose both alternatives, I think we can pretty
much say that *anything* we decide to do with DEFCONSTANT is going to
be trivial to implement.

-Sandra
-------

∂07-Oct-88  0951	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE (V2)   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 7 Oct 88  09:50:49 PDT
Received: by ti.com id AA27757; Fri, 7 Oct 88 11:48:46 CDT
Received: from Kelvin by tilde id AA18328; Fri, 7 Oct 88 11:32:54 CDT
Message-Id: <2801233987-366058@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 7 Oct 88  11:33:07 CDT
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 DEFCONSTANT-VALUE (V2)
In-Reply-To: Msg of Thu, 6 Oct 88 16:19:26 MDT from sandra%defun@cs.utah.edu (Sandra J Loosemore)

> I'm still not clear on whether you want the run-time evaluation of the
> value form to happen in a null lexical environment as well.

I was assuming that, but that could be awkward to implement now that I
think about it.

>    If not, I
> think the proposal should include some strong warnings about it, since
> that would be a likely source of getting different values at load time
> than at compile time.

Agreed.

>   Lucid also conforms to this proposal.
> 
> My understanding of JonL's comments on this were that Lucid only does
> compile-time evaluation of the value form when the DEFCONSTANT appears
> at top-level.

That was my intent, even if it didn't come out that way.

>   If you're going to go through the work
> of implementing a way to temporarily remember values of constants
> seen by the compiler, is one call to CONSTANTP going to make any
> difference?

But to really do it well, it wouldn't be just a call to CONSTANTP, it
would be a code walk of the expression to see if all of the functions are
known to be safe and all of the terms are constants.

∂07-Oct-88  1010	CL-Compiler-mailer 	Re: Issue: DEFINE-OPTIMIZER   
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 7 Oct 88  10:09:11 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA01302; Fri, 7 Oct 88 13:08:30 EDT
Message-Id: <8810071708.AA01302@multimax.ARPA>
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU;  7 Oct 88 13:04:11 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: pierson%mist@MULTIMAX.ARPA,
        KMP%STONY-BROOK.SCRC.Symbolics.COM@MULTIMAX.ARPA,
        CL-Compiler%sail.stanford.edu@MULTIMAX.ARPA
Subject: Re: Issue: DEFINE-OPTIMIZER 
In-Reply-To: Your message of Thu, 29 Sep 88 12:02:00 -0400.
             <880929120250.0.KMP@GRYPHON.SCRC.Symbolics.COM> 
Date: Fri, 07 Oct 88 13:03:41 EDT
From: Rob.MacLachlan@WB1.CS.CMU.EDU

   Date: Thu, 29 Sep 88 12:02 EDT
   From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
   Subject: Re: Issue: DEFINE-OPTIMIZER 
   To: pierson%mist@MULTIMAX.ARPA

   [...]
   I was talking more about adding a style warning saying that the effects
   of writing optimizers on functions that you didn't implement may not be
   good because optimizers may already exist which you're defeating.

   This would leave it in the "unspecified but `harmless'" territory of the
   new error terminology Kathy Chapman has been circulating. I'd rather
   have it that way than "is an error" so that implementations wouldn't
   signal gratuitous errors when you were dissatisfied with their
   performance [...]

I'm afraid that it may be hard to guarantee that it is "harmless" to add
source transforms that potentially interact with existing (unknown builtin)
transforms.  The biggest snare that I see is the possibility for an "infinite
optimization loop" at compile time.  If your opimtizer decides to
left-associate +, and a builtin optimizer decides to right-associate, then
they are going to fight forever.

Consider also an implementation that transforms (1+ x) to the canonical
form (+ x 1), and a user "optimizer" that transforms (+ x 1) to 
(1+ x).

I think that it is perfectly reasonable to consider the addition of
transforms to builtin functions to fall in the same category as
redefinition of builtin functions: something not done by portable programs
(result undefined).

  Rob

∂07-Oct-88  1030	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE (V2)   
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 7 Oct 88  10:28:42 PDT
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU;  7 Oct 88 13:26:29 EDT
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
cc: David N Gray <Gray@dsg.csc.ti.com>, CL-Compiler@sail.stanford.edu
Subject: Re: Issue DEFCONSTANT-VALUE (V2) 
In-reply-to: Your message of Thu, 06 Oct 88 16:19:26 -0600.
             <8810062219.AA15555@defun.utah.edu> 
Date: Fri, 07 Oct 88 13:26:13 EDT
From: Rob.MacLachlan@WB1.CS.CMU.EDU


(+ const 3) is not constantp.  I strongly favor compile-time evaluation of
the defconstant value form because it is easy to understand and explain.
If we always evaluate, then there is no need to define the concept of a
"compile time constant form".

I agree that the evaluation should always be done in the null environment
(or the environment should be determined by some implicit-eval-when model.)

  Rob

∂07-Oct-88  1055	CL-Compiler-mailer 	Re: Issue: DEFINE-OPTIMIZER   
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 7 Oct 88  10:55:24 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA01600; Fri, 7 Oct 88 13:54:55 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA02815; Fri, 7 Oct 88 13:56:42 EDT
Message-Id: <8810071756.AA02815@mist.UUCP>
To: Rob.MacLachlan%WB1.CS.CMU.EDU@multimax
Cc: cl-compiler%sail.stanford.edu@Multimax
Subject: Re: Issue: DEFINE-OPTIMIZER 
In-Reply-To: Your message of Fri, 07 Oct 88 13:03:41 -0400.
             <8810071706.AA01283@multimax.ARPA> 
Date: Fri, 07 Oct 88 13:56:39 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    Consider also an implementation that transforms (1+ x) to the canonical
    form (+ x 1), and a user "optimizer" that transforms (+ x 1) to 
    (1+ x).
    
This problem goes away if we're willing to accept the restriction that
user-defined optimzers are a strict prepass to compiler optimzers.
This seems reasonable to me; it still lets me do almost anything that
I can think about portably.  Of course it may lose if I transform the
code to make superior implementation optimization impossible, but that
can be covered by a warning.

∂07-Oct-88  1139	CL-Compiler-mailer 	Issue DEFCONSTANT-NOT-WIRED   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Oct 88  11:39:04 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA02808; Fri, 7 Oct 88 12:37:13 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA16113; Fri, 7 Oct 88 10:59:49 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810071659.AA16113@defun.utah.edu>
Date: Fri, 7 Oct 88 10:59:46 MDT
Subject: Issue DEFCONSTANT-NOT-WIRED
To: David N Gray <Gray@dsg.csc.ti.com>
Cc: CL-Compiler@sail.stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Thu, 6 Oct 88  16:32:05 CDT

Unless anybody is really strongly in favor of this proposal, I would
like to try to resolve this issue without introducing another defining
macro by having the description of DEFPARAMETER in the standard make
it clear that it's supposed to be used in the situations described in
the "problem description" part of the proposal.

Note that CLtL says only that "it is an error" to SETQ or rebind a symbol
which has been declared with DEFCONSTANT.  It does not say "an error is
signalled".

CLtL says that a change to a DEFPARAMETER'ed variable should be
considered a change to the program.  There are lots of other
situations where making a change to the program might cause situations
that "are an error", such as redefining a function as a macro.
Although CLtL does not explicitly allow or disallow it, some (many?)
implementations choose to issue warnings in such cases.  Therefore I
think it is legitimate both for users to use DEFPARAMETER for
situations where an error may result if the variable is changed, and
for implementations to be allowed (but not required) to issue warnings
about changing the values of DEFPARAMETER'ed variables.

If anybody believes it is important to write this up as a formal
proposal so that we can vote on it, I'm willing to do so, but I think
it would expedite matters if we could just pass this on directly to
the editorial committee. 

-Sandra
-------

∂07-Oct-88  1139	CL-Compiler-mailer 	issue COMPILER-LET-CONFUSION, version 2 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Oct 88  11:39:05 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA02812; Fri, 7 Oct 88 12:37:17 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA16133; Fri, 7 Oct 88 11:18:57 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810071718.AA16133@defun.utah.edu>
Date: Fri, 7 Oct 88 11:18:56 MDT
Subject: issue COMPILER-LET-CONFUSION, version 2
To: cl-compiler@sail.stanford.edu

Here is a slightly revised writeup on this issue.


Issue:		COMPILER-LET-CONFUSION
References:	CLtL p. 112
Category:	CHANGE/CLARIFICATION
Edit History:   V1, 27 Sep 1988, Sandra Loosemore (initial version)
                V2, 04 Oct 1988, Sandra Loosemore (add another example)
Status:		**DRAFT**


Problem Description:

The description of the COMPILER-LET special form in CLtL is confusing
to many people.  There are no examples provided to make it clear how it
is supposed to be used.

The description of how COMPILER-LET works in the interpreter only
makes sense for implementations which perform macroexpansion in
parallel with evaluation.  In an implementation which performs macro
expansion in a prepass and follows CLtL literally in making
COMPILER-LET behave "exactly like LET with all the variable bindings
implicitly declared SPECIAL", it would not work at all for its stated
purpose, "communication among complicated macros".

Subtle bugs can be introduced because of the different handling of the
variable bindings in the interpreter and the compiler.  In compiled
code, the bindings are only lexically visible during the expansion of
macros at compile time, while in interpreted code the bindings have
dynamic scope and may also be seen during ordinary evaluation if
evaluation and macroexpansion happen concurrently.

Further compatibility problems can result from the value forms being
evaluated in a null lexical environment in the compiler and the
ordinary lexical environment in the interpreter.



Proposal COMPILER-LET-CONFUSION:CLARIFY-STATUS-QUO:

  Change the documentation of COMPILER-LET to include more discussion of
  its intended purpose, including examples.
  
  Change the description of COMPILER-LET's behavior in the interpreter
  to indicate that it is not "exactly like LET with all the variable
  bindings implicitly declared SPECIAL".  Instead, clarify that
  processing of COMPILER-LET by the interpreter happens at the same time
  as macroexpansion; the value forms are evaluated sequentially
  in a null lexical environment, bound to the special variables, and
  that these bindings are available during the expansion of macro calls
  in the body.
  
  Mention that there may be compatibility problems between compiled and
  interpreted code if the interpreter performs macroexpansion in
  parallel with evaluation.

  
  Rationale:

  This proposal formalizes what appears to be the behavior of most
  implementations.
  

  Current Practice:
  
  COMPILER-LET is rarely used.
  
  
  Cost to implementors:

  Minimal.

  
  Cost to users:
  
  None.  Any code that would break under the new rules for the interpreted
  behavior of COMPILER-LET would already be broken when compiled.


  Benefits:
  
  The description of COMPILER-LET would make more sense for implementations
  that perform macroexpansion during a prepass in the interpreter.  Some of
  the compatibility problems between interpreted and compiled code would be
  removed.



Proposal COMPILER-LET-CONFUSION:REQUIRE-PREPASS:

  Disallow interpreters from performing macroexpansion concurrently with
  evaluation.  Macroexpansion must be performed in a preprocessing
  codewalk.

  Clarify that COMPILER-LET is processed by the interpreter or compiler
  (the "processor") at the same time that macros are expanded.  The
  processor sequentially evaluates each of the value forms in a null
  lexical environment, and the special variables are bound to these values
  during the expansion of any macro calls in the body.
  

  Rationale:
  
  This proposal forces the interpreter to treat both macroexpansion and
  COMPILER-LET in the same way that the compiler does.
  
  
  Current Practice:
  
  COMPILER-LET is rarely used.
  
  
  Cost to implementors:
  
  For implementations that do not implement their interpreters using a
  prepass, this would be a fairly substantial change.
  
  
  Cost to users:
  
  Strictly speaking, this is a compatible change to the language.  Since
  CLtL makes no guarantees about the time of macroexpansion, any user
  code that depends upon macroexpansion happening concurrently with
  evaluation is nonportable.  Some users, however, dislike
  implementations with preprocessing interpreters, and want to be able
  to freely redefine macros as well as functions.

  
  Benefits:
  
  An area of incompatibility between compiled and interpreted code is
  eliminated.  This proposal would also address some other compatibility
  problems beyond those relating to COMPILER-LET (such as issue
  LOAD-TIME-EVAL).


Proposal COMPILER-LET-CONFUSION:ELIMINATE:

  Remove COMPILER-LET from the language.
  
  
  Rationale:
  
  Some people think that COMPILER-LET is ugly.  Removing it from the
  language is a much simpler solution than an elaborate proposal to
  assign it consistent semantics in the interpreter and compiler.
  
  
  Current Practice:
  
  COMPILER-LET is rarely used.  
  
  
  Cost to implementors:
  
  Minimal.  Implementations could continue to support COMPILER-LET as
  an extension.
  
  
  Cost to users:
  
  People who use COMPILER-LET would have to rewrite their programs to use
  some other construct.  Most uses of COMPILER-LET for communication between
  macros can be handled using MACROLET instead.
  
  I have been able to do this quite easily for all of the examples which I
  have seen so far.  For example:
  
    (defvar *local-type-declarations* '())
     
    (defmacro local-type-declare (declarations &body forms)
      `(compiler-let ((*local-type-declarations* 
                        (append ',declarations *local-type-declarations*)))
         ,@forms))
     
    (defmacro typed-var (var)
       (let ((type (assoc var *local-type-declarations*)))
         (if type `(the ,(cadr type) ,var) var)))
     
    (defun f (x y)
      (local-type-declare ((x fixnum) (y float))
        (+ (typed-var x) (typed-var y))))
     
    
  can be rewritten as:
  
    (defmacro local-type-declare (declarations &body forms)
        (local-type-declare-aux declarations forms))
    
    (eval-when (eval compile load)
        (defun local-type-declare-aux (declarations forms)
    	`(macrolet ((typed-var (var)
    			(let ((type  (assoc var ',declarations)))
    			    (if type `(the ,(cadr type) ,var) var)))
    		    (local-type-declare (new-declarations &body new-forms)
    			(local-type-declare-aux
    			    (append new-declarations ',declarations)
    			    new-forms)))
    	     ,@forms)))
    
    
  The MACROLET versions are usually somewhat more complicated than the
  COMPILER-LET versions, but not substantially so unless there are a large
  number of macros involved.

  Another approach for converting old code is to define a
  COMPILER-LET-like macro to explicitly make the special variable
  bindings available during the expansion of a specified set of macros.
  The following macro FAKE-COMPILER-LET provides semantics fairly close
  to those of proposal COMPILER-LET-CONFUSION:REDEFINE (below), the
  exception being that it handles only macros defined with DEFMACRO and
  not MACROLET.

    ;;; Imitation COMPILER-LET.  Second argument is a list of macros which
    ;;;    are to see the special bindings; these must have been defined using
    ;;;    DEFMACRO, not MACROLET (because expansion takes place in null
    ;;;    lexical environment).
    
    (defmacro fake-compiler-let (binding-forms macros &body body)
        (expand-fake-compiler-let binding-forms macros body))
    
    (eval-when (eval compile load)
        (defun expand-fake-compiler-let (binding-forms macros body)
            (let* ((vars    (mapcar #'(lambda (b)
                                          (if (consp b) (car b) b))
                                    binding-forms))
                   (vals    (mapcar #'(lambda (b)
                                          (if (consp b) (eval (cadr b)) nil))
                                    binding-forms))
                   (binders (mapcar #'(lambda (var val)
                                          `(,var ',val))
                                    vars vals))
                   (defs    (mapcar #'(lambda (m)
                                          `(,m (&whole w)
                                               (let ,binders
                                                   (declare (special ,@vars))
                                                   (macroexpand-1 w))))
                                    macros)))
                `(macrolet ((fake-compiler-let (binding-forms macros
						    &body body)
                                (let ,binders
                                    (declare (special ,@vars))
                                    (expand-fake-compiler-let
                                        binding-forms macros body)))
                            ,@defs)
                     ,@body)))
        )
    
    
    ;;; Example to illustrate nesting behavior
    
    (eval-when (eval compile)
        (defvar *depth* 0)
        (defmacro current-depth ()
            *depth*)
        )
    
    (fake-compiler-let ((*depth* (1+ *depth*)))
                       (current-depth)
        (format t "First value = ~s~%" (current-depth))
        (fake-compiler-let ((*depth* (1+ *depth*)))
                           (current-depth)
            (format t "Second value = ~s~%" (current-depth))))
  

  Benefits:
  
  Having one less special form would simplify the language.  An area of
  incompatibility between compiled and interpreted code would be
  eliminated.



Proposal COMPILER-LET-CONFUSION:REDEFINE:

  Clarify the description of COMPILER-LET to emphasize that it is used to
  make bindings of special variables available when macro calls appearing in
  the body are expanded.
  
  Clarify that COMPILER-LET is processed by the interpreter or compiler
  (the "processor") at the same time that macros are expanded.  The
  processor sequentially evaluates each of the value forms in a null
  lexical environment, storing the variable/value pairs in the
  environment.
  
  Extend the description of environment objects captured with &ENVIRONMENT 
  to state that they also contain information about bindings indicated with 
  COMPILER-LET.
  
  Clarify that MACROEXPAND and MACROEXPAND-1 use the information stored in
  the environment argument to actually perform the special bindings of
  the variables to the values.  Clarify that calling a macro-function
  directly may result in incorrect behavior.
  
  Clarify that the special bindings indicated by COMPILER-LET are also
  visible during the evaluation of value forms of lexically nested 
  COMPILER-LET constructs.  The special bindings are not present during
  any other compile-time evaluation of the body, such as evaluation of
  (EVAL-WHEN (COMPILE) ...) forms.
  
  
  Rationale:
  
  This proposal provides consistent semantics for COMPILER-LET in both the
  compiler and interpreter.  It will work just as well in interpreters that
  perform macroexpansion in parallel with execution, as in those that perform
  macroexpansion in a prepass.
  
  
  Current Practice:
  
  COMPILER-LET is rarely used.
  
  
  Cost to implementors:
  
  Implementors will have to change their interpreters and compilers to
  have COMPILER-LET store things in the environment.  The representation
  of environment objects may need to change slightly.  Implementations
  in which &ENVIRONMENT does not return a complete environment object
  will have to be changed.  MACROEXPAND and MACROEXPAND-1 will have to
  be changed to rebind the variables from the environment.
  
  
  Cost to users:
  
  User programs that perform code walks may have to be changed; the
  changes would roughly parallel those listed above.

  
  Benefits:
  
  The treatment of this special form by the interpreter is made consistent
  with its treatment by the compiler.




Discussion:

Can any of you implementors who have an interpreter that perform
macroexpansion in a preprocessing phase comment on how you handle
COMPILER-LET?

Proposal COMPILER-LET-CONFUSION:CLARIFY-STATUS-QUO is the alternative
which is the most consistent with current practice and requires the
least change for both implementors and users.  However, it addresses only
some of the problems which can lead to incompatibility between compiled
and interpreted code.

Proposal COMPILER-LET-CONFUSION:REQUIRE-PREPASS would ensure
consistent semantics for macroexpansion as well as processing of
COMPILER-LET.  On the negative side, it is a substantial change for
some implementations.

Proposal COMPILER-LET-CONFUSION:ELIMINATE is by far the simplest
alternative, but it would also has the greatest impact on users.

Proposal COMPILER-LET-CONFUSION:REDEFINE also guarantees consistent
semantics for COMPILER-LET between the interpreter and compiler.  The
disadvantages of this proposal are that COMPILER-LET remains
complicated and potentially confusing, and it requires changes in both
user and system code.

Proposal COMPILER-LET-CONFUSION:ELIMINATE appears to have the most
support among members of the compiler committee; JonL (and others at
Lucid), Loosemore, Van Roggen, Dalton, and Perdue have all expressed
support for the idea of getting rid of COMPILER-LET.  Since this is an
incompatible change, it is felt that a substantial effort should be
made to help users convert old code.

COMPILER-LET-CONFUSION:REQUIRE-PREPASS was suggested by Pitman and
COMPILER-LET-CONFUSION:REDEFINE by JBarnett.
-------

∂07-Oct-88  1222	CL-Compiler-mailer 	Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Oct 88  12:22:17 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472680; Fri 7-Oct-88 15:16:45 EDT
Date: Fri, 7 Oct 88 15:16 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: Eric Benson <eb@lucid.com>, cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: <8810040400.AA13928@defun.utah.edu>
Message-ID: <19881007191607.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 3 Oct 88 22:00:24 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    ....
    If the local/remote environment model is adopted (or even if we don't
    provide any way to tell the difference between the two), some way
    would have to be provided for a code walker to create a remote
    environment.

Yes, in EB's proposal AUGMENT-ENVIRONMENT needs a :REMOTE argument
which defaults to the remoteness of the ENV argument and specifies
the remoteness of the returned environment.

    One other thing I would like clarified.  It makes sense to be able to
    have more than one distinct remote environment around at any given
    time; for example, if COMPILE-FILE is called recursively it ought to
    create a new remote environment for each file.  

That's true, although I was refraining from proposing anything that
complicated.  If we get into that, then we also will have to make
environments extensible as I think I mentioned before.  But if we
confine ourselves to just putting in a way to tell whether this is a
remote environment or not, that will be enough to get CLOS off the
ground.

						    Does it make any sense
    to have more than one distinct local environment around, or is there
    only one?  

There is only one local global environment (gnashing of teeth in the
background over the terminology) in Common Lisp, but there can be more
than one in some dialects of Scheme (they're called "locales").
Multiple local global environments seem like a sound approach to solving
the same problems that packages were invented to solve.

On the terminology, this shows that "remote" is an okay word, but we
shouldn't use "local" as the antonym of "remote", since "local" is already
used as the antonym of "global".  How about "running"?

	       I can imagine that a Lisp running on a non-shared-memory
    parallel machine might want to maintain separate local environments on
    each processor, for instance.

No, I think you're confused here.  Environments have to do with the
mapping of names to objects (and to conceptual objects such as BLOCKs
and GO tags).  I don't think this has anything to do with addressing
memory, local or global, shared or non-shared.  I'm not sure what your
vision of a Lisp on a non-shared-memory parallel machine is, but I
suspect I would call it several independent Lisps talking to each other
through some communication medium.  In that sense there are multiple
local environments, since each Lisp has its own, but since the Lisps
don't share objects, this isn't an interesting distinction in the way
that the local/remote environment distinction in COMPILE-FILE is
interesting.

∂07-Oct-88  1240	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 7 Oct 88  12:40:14 PDT
Received: by ti.com id AA28917; Fri, 7 Oct 88 14:36:55 CDT
Received: from Kelvin by tilde id AA21469; Fri, 7 Oct 88 14:19:20 CDT
Message-Id: <2801243978-966312@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 7 Oct 88  14:19:38 CDT
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 DEFCONSTANT-NOT-WIRED
In-Reply-To: Msg of Fri, 7 Oct 88 10:59:46 MDT from sandra%defun@cs.utah.edu (Sandra J Loosemore)

> CLtL says that a change to a DEFPARAMETER'ed variable should be
> considered a change to the program.  There are lots of other
> situations where making a change to the program might cause situations
> that "are an error", such as redefining a function as a macro.
> Although CLtL does not explicitly allow or disallow it, some (many?)
> implementations choose to issue warnings in such cases.  Therefore I
> think it is legitimate both for users to use DEFPARAMETER for
> situations where an error may result if the variable is changed, and
> for implementations to be allowed (but not required) to issue warnings
> about changing the values of DEFPARAMETER'ed variables.

One might construe CLtL to mean that, but it is too big of an
incompatible change from current practice to be seriously considered. 

∂07-Oct-88  1258	CL-Compiler-mailer 	Issue DEFCONSTANT-NOT-WIRED   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Oct 88  12:58:34 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA00471g; Fri, 7 Oct 88 12:56:22 PDT
Received: by blacksox id AA00510g; Fri, 7 Oct 88 12:52:34 pdt
Date: Fri, 7 Oct 88 12:52:34 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8810071952.AA00510@blacksox>
To: Gray@DSG.csc.ti.com
Cc: sandra%defun@cs.utah.edu, CL-Compiler@sail.stanford.edu
In-Reply-To: David N Gray's message of Fri, 7 Oct 88  14:19:38 CDT <2801243978-966312@Kelvin>
Subject: Issue DEFCONSTANT-NOT-WIRED

   Sender: GRAY@Kelvin.csc.ti.com
   Date: Fri, 7 Oct 88  14:19:38 CDT
   From: David N Gray <Gray@DSG.csc.ti.com>

   > CLtL says that a change to a DEFPARAMETER'ed variable should be
   > considered a change to the program.  There are lots of other
   > situations where making a change to the program might cause situations
   > that "are an error", such as redefining a function as a macro.
   > Although CLtL does not explicitly allow or disallow it, some (many?)
   > implementations choose to issue warnings in such cases.  Therefore I
   > think it is legitimate both for users to use DEFPARAMETER for
   > situations where an error may result if the variable is changed, and
   > for implementations to be allowed (but not required) to issue warnings
   > about changing the values of DEFPARAMETER'ed variables.

   One might construe CLtL to mean that, but it is too big of an
   incompatible change from current practice to be seriously considered. 


I disagree.  You may not remember, but DEFPARAMETER was defined to be
equivalent to Zetalisp's DEFCONST.  DEFCONST was always used to denote
values that would "never" change, even though the compiler was not
licensed to substitute their values.  After the Common Lisp version of
DEFCONSTANT was accepted, DEFPARAMETER was proposed to be used in
place of DEFCONST in cases where DEFCONSTANT isn't desirable.  As it
turns out, most uses of DEFCONST have been converted to DEFCONSTANT,
so DEFPARAMETER has been a bit neglected.

∂07-Oct-88  1350	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Oct 88  13:50:35 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA07331; Fri, 7 Oct 88 14:06:21 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA16321; Fri, 7 Oct 88 14:06:11 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810072006.AA16321@defun.utah.edu>
Date: Fri, 7 Oct 88 14:06:10 MDT
Subject: Re: Issue DEFCONSTANT-NOT-WIRED
To: David N Gray <Gray@dsg.csc.ti.com>
Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore),
        CL-Compiler@sail.stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Fri, 7 Oct 88  14:19:38 CDT

> Date: Fri, 7 Oct 88  14:19:38 CDT
> From: David N Gray <Gray@DSG.csc.ti.com>
> 
> > Therefore I
> > think it is legitimate both for users to use DEFPARAMETER for
> > situations where an error may result if the variable is changed, and
> > for implementations to be allowed (but not required) to issue warnings
> > about changing the values of DEFPARAMETER'ed variables.
> 
> One might construe CLtL to mean that, but it is too big of an
> incompatible change from current practice to be seriously considered.

Which aspect do you think is incompatible with current practice?

It's my impression that users already do use DEFPARAMETER in
situations where changing it "is an error".  The thing that convinced
me of this was looking through the sources for a large, portable
Common Lisp application which I didn't write myself, namely CLX.  It
uses DEFPARAMETER all over the place for things that could certainly
cause things to break very badly if the values were changed -- for
example, it's used to define the X protocol version which it
implements (which eventually gets sent to the server), the base
address of the TCP port, and the like. 

I think an implementation would be justified in issuing a warning.
That doesn't forbid users from changing the value of a DEFPARAMETER'ed
variable, just indicates that users need to be very careful about
doing so.  Moreover, since I'm not suggesting that implementations be
*required* to issue a warning, it's certainly not an incompatible change
for implementors.

-Sandra
-------

∂07-Oct-88  1422	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 7 Oct 88  14:22:13 PDT
Received: by ti.com id AA29591; Fri, 7 Oct 88 16:19:24 CDT
Received: from Kelvin by tilde id AA23736; Fri, 7 Oct 88 16:07:21 CDT
Message-Id: <2801250453-1355374@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 7 Oct 88  16:07:33 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Eric Benson <eb@lucid.com>
Cc: sandra%defun@cs.utah.edu, CL-Compiler@sail.stanford.edu
Subject: Re: Issue DEFCONSTANT-NOT-WIRED
In-Reply-To: Msg of Fri, 7 Oct 88 12:52:34 pdt from Eric Benson <eb@lucid.com>

> I disagree.  You may not remember, but DEFPARAMETER was defined to be
> equivalent to Zetalisp's DEFCONST.  DEFCONST was always used to denote
> values that would "never" change, even though the compiler was not
> licensed to substitute their values. 

Well, that's the way DEFCONST is described in the "MIT Lisp Machine
Manual", but the system code we received from MIT did not use it that
way.  It was very common for something that really was used as a
variable to be defined by DEFCONST simply because it was desired to
re-initialize it whenever the file was reloaded.  Thus, in practical
terms, the only difference between DEFVAR and DEFCONST was whether they
preserved a previous value of the variable.  I always thought that that
was the reason for changing the name to DEFPARAMETER because the name
DEFCONST was misleading.  But then CLtL kept the old way of describing
it, so the confusion continues.

>   After the Common Lisp version of
> DEFCONSTANT was accepted, DEFPARAMETER was proposed to be used in
> place of DEFCONST in cases where DEFCONSTANT isn't desirable.  As it
> turns out, most uses of DEFCONST have been converted to DEFCONSTANT,
> so DEFPARAMETER has been a bit neglected.

When we converted our system from Zetalisp to Common Lisp, DEFCONST was
translated to DEFPARAMETER since they were implemented exactly the same.
Some uses have been changed by hand to DEFCONSTANT where appropriate,
so our experience seems to be the reverse of yours.

∂07-Oct-88  1440	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Oct 88  14:40:02 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00645g; Fri, 7 Oct 88 14:38:48 PDT
Received: by bhopal id AA01651g; Fri, 7 Oct 88 14:37:09 PDT
Date: Fri, 7 Oct 88 14:37:09 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810072137.AA01651@bhopal>
To: GRAY@Kelvin.csc.ti.com
Cc: CL-Compiler@SAIL.Stanford.edu
In-Reply-To: Msg of Wed, 5 Oct 88  15:58:01 CDT from David N Gray 
Subject: Re: Issue DEFCONSTANT-VALUE

I may still be a bit confused about the purpose of this proposal.  The
version you subsequently sent out did reduce the "Pascal" requirement 
that all constants be folded, and the phrase:
      It is an error for the value expression to have a different value at 
      load time than it had at compile-time, so it is implementation-dependent
      whether the expression is re-evaluated at load time or loads the 
      compile-time value.
makes it compatible with what Lucid does.  In fact, it may even cover what 
several other vendors do, even though they vary somewhat from Lucid.

However, the proposal seems far too long simply to be saying that
DEFCONSTANT is implicitly eval-when(eval compile load); and I don't
really see the need to say much more than that, as an alternative
to the peculiar semantics of the previous top-level definers proposal.
Perhaps a more agressive "campaign" would allow coalescing of constants
based on EQUAL rather than merely EQL [and even more agressive would
go for and equivalence that also descended pointer structures].

Let me mention again that I *did* like your first wording that required 
the semantics of defconstant to be the same as if it were always folded.
This would make the runtime value of the symbol irrelevant, and could
open the way for file-specific constants (which of course is what you
have in some more conventional computer languages).  As a user, I would 
feel much more comfortable knowing that compile-time constants are
always folded, rather than having to worry about hidden heuristics that
fold some but turn others into global symbol references.


-- JonL --

∂07-Oct-88  1452	CL-Compiler-mailer 	Issue DEFCONSTANT-VALUE (V2)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Oct 88  14:51:56 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00678g; Fri, 7 Oct 88 14:50:28 PDT
Received: by bhopal id AA01696g; Fri, 7 Oct 88 14:48:48 PDT
Date: Fri, 7 Oct 88 14:48:48 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810072148.AA01696@bhopal>
To: sandra%defun@cs.utah.edu
Cc: Gray@dsg.csc.ti.com, CL-Compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Thu, 6 Oct 88 16:19:26 MDT <8810062219.AA15555@defun.utah.edu>
Subject: Issue DEFCONSTANT-VALUE (V2)

re: My understanding of JonL's comments on this were that Lucid only does
    compile-time evaluation of the value form when the DEFCONSTANT appears
    at top-level.

No, this isn't correct.  Lucid's DEFCONSTANT is implemented as a very
ordinary macro which expands into an eval-when(eval compile load); so
the non-top-level behaviour depends on the treatment of eval-when at
non-top-level.  Lucid's current behaviour for eval-when is not too far 
off from the cl-compiler proposal, but of course it doesn't match
exactly.

-- JonL --

∂07-Oct-88  1455	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED    
Received: from cayuga.cs.rochester.edu (CS.ROCHESTER.EDU) by SAIL.Stanford.EDU with TCP; 7 Oct 88  14:55:01 PDT
Received: from doughnut.cs.rochester.edu by cayuga.cs.rochester.edu (5.59/k) id AA04582; Fri, 7 Oct 88 17:50:35 EDT
Date: Fri, 7 Oct 88 17:41 EDT
From: Brad Miller <miller@CS.ROCHESTER.EDU>
Subject: Re: Issue DEFCONSTANT-NOT-WIRED
To: Eric Benson <eb@LUCID.COM>
Cc: Gray@DSG.csc.ti.com, sandra%defun@CS.UTAH.EDU,
        CL-Compiler@SAIL.STANFORD.EDU
In-Reply-To: <8810071952.AA00510@blacksox>
Message-Id: <19881007214126.9.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Sender: miller@CS.ROCHESTER.EDU
Reply-To: miller@CS.ROCHESTER.EDU
Organization: University of Rochester, Department of Computer Science
Postal-Address: 610 CS Building, Comp Sci Dept., U. Rochester, Rochester NY 14627
Phone: 716-275-1118

    Date: Fri, 7 Oct 88 12:52:34 pdt
    From: Eric Benson <eb@lucid.com>

    I disagree.  You may not remember, but DEFPARAMETER was defined to be
    equivalent to Zetalisp's DEFCONST.  DEFCONST was always used to denote
    values that would "never" change, even though the compiler was not
    licensed to substitute their values.  After the Common Lisp version of
    DEFCONSTANT was accepted, DEFPARAMETER was proposed to be used in
    place of DEFCONST in cases where DEFCONSTANT isn't desirable.  As it
    turns out, most uses of DEFCONST have been converted to DEFCONSTANT,
    so DEFPARAMETER has been a bit neglected.

I use DEFCONSTANT for symbols whose definitions will never change (or at
least, I am willing to recompile all references, as if I change a macro) but
DEFPARAMETER for cases where the definitions will not change *over a
particular execution of the program* but may change *between executions of
the program* and thus the compiler must treat it as a variable, so I don't
have to recompile references.

Have I missed something? Am I misusing DEFPARAMETER?
----
Brad Miller		U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}

∂07-Oct-88  1814	CL-Compiler-mailer 	Issue DEFCONSTANT-NOT-WIRED   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Oct 88  18:13:58 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA01019g; Fri, 7 Oct 88 18:12:14 PDT
Received: by blacksox id AA00560g; Fri, 7 Oct 88 18:08:23 pdt
Date: Fri, 7 Oct 88 18:08:23 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8810080108.AA00560@blacksox>
To: miller@CS.ROCHESTER.EDU
Cc: Gray@DSG.csc.ti.com, sandra%defun@CS.UTAH.EDU,
        CL-Compiler@SAIL.STANFORD.EDU
In-Reply-To: Brad Miller's message of Fri, 7 Oct 88 17:41 EDT <19881007214126.9.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Subject: Issue DEFCONSTANT-NOT-WIRED

   Date: Fri, 7 Oct 88 17:41 EDT
   From: Brad Miller <miller@CS.ROCHESTER.EDU>
   Sender: miller@CS.ROCHESTER.EDU
   Reply-To: miller@CS.ROCHESTER.EDU
   Organization: University of Rochester, Department of Computer Science
   Postal-Address: 610 CS Building, Comp Sci Dept., U. Rochester, Rochester NY 14627
   Phone: 716-275-1118

       Date: Fri, 7 Oct 88 12:52:34 pdt
       From: Eric Benson <eb@lucid.com>

       I disagree.  You may not remember, but DEFPARAMETER was defined to be
       equivalent to Zetalisp's DEFCONST.  DEFCONST was always used to denote
       values that would "never" change, even though the compiler was not
       licensed to substitute their values.  After the Common Lisp version of
       DEFCONSTANT was accepted, DEFPARAMETER was proposed to be used in
       place of DEFCONST in cases where DEFCONSTANT isn't desirable.  As it
       turns out, most uses of DEFCONST have been converted to DEFCONSTANT,
       so DEFPARAMETER has been a bit neglected.

   I use DEFCONSTANT for symbols whose definitions will never change (or at
   least, I am willing to recompile all references, as if I change a macro) but
   DEFPARAMETER for cases where the definitions will not change *over a
   particular execution of the program* but may change *between executions of
   the program* and thus the compiler must treat it as a variable, so I don't
   have to recompile references.

   Have I missed something? Am I misusing DEFPARAMETER?

Perhaps.  Do you consider this "a change *to* the program" as stated
in CLtL?  If you only ever change it at the top level, for example,
you're probably working in the spirit of DEFPARAMETER.  Would you need
to change your program to use DEFVAR instead of DEFPARAMETER if a
warning was signalled every time a variable defined with DEFPARAMETER
is SETQed (as opposed to re-evaluating the DEFPARAMETER form with a
different initial value)?

∂09-Oct-88  0025	CL-Compiler-mailer 	Issue DEFCONSTANT-VALUE (V2)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Oct 88  00:25:27 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 473528; Sun 9-Oct-88 03:23:37 EDT
Date: Sun, 9 Oct 88 03:23 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue DEFCONSTANT-VALUE (V2)
To: Gray@DSG.csc.ti.com
cc: CL-Compiler@SAIL.Stanford.edu
In-Reply-To: <2801165093-10211223@Kelvin>
Message-ID: <881009032322.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Thu, 6 Oct 88  16:24:53 CDT
    From: David N Gray <Gray@DSG.csc.ti.com>
    ...
    Issue:		DEFCONSTANT-VALUE
    ...
    Proposal DEFCONSTANT-VALUE:COMPILE-TIME:
    ...

I certainly favor a compile-time evaluation option.

    It is implementation dependent whether or not the symbol value is
    actually set at compile time or whether COMPILE-FILE temporarily
    remembers the value in some other way.
    ...

However, I a couple of major problems with this...

It implies that you can't use the variable FOO in either
a macro or an (EVAL-WHEN (COMPILE) ...). That seems unfortunate.

Not only is it sad, but it is sad for no apparent good reason.
There's no efficiency reason that I can think of for not pinning
this down and just saying it will be available at compile time.
Interpreted-only implementations (the usual exception case in 
compiler discussions) have no trouble treating this as an assignment.
And there's no other reason I can think of why you couldn't want
this available.

For reasons both of flexible coding style and principle of least
surprise in portability, I would prefer that we just require this
to assign the variable at compile time (for at least the duration
of the file -- if someone needs it beyond the end of the file, they
can load the file).

∂09-Oct-88  0035	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Oct 88  00:35:07 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 473531; Sun 9-Oct-88 03:33:03 EDT
Date: Sun, 9 Oct 88 03:32 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue DEFCONSTANT-NOT-WIRED
To: Gray@DSG.csc.ti.com
cc: sandra%defun@cs.utah.edu, CL-Compiler@sail.stanford.edu
In-Reply-To: <2801243978-966312@Kelvin>
Message-ID: <881009033248.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Fri, 7 Oct 88  14:19:38 CDT
    From: David N Gray <Gray@DSG.csc.ti.com>

    > CLtL says that a change to a DEFPARAMETER'ed variable should be
    > considered a change to the program.  There are lots of other
    > situations where making a change to the program might cause situations
    > that "are an error", such as redefining a function as a macro.
    > Although CLtL does not explicitly allow or disallow it, some (many?)
    > implementations choose to issue warnings in such cases.  Therefore I
    > think it is legitimate both for users to use DEFPARAMETER for
    > situations where an error may result if the variable is changed, and
    > for implementations to be allowed (but not required) to issue warnings
    > about changing the values of DEFPARAMETER'ed variables.

    One might construe CLtL to mean that, but it is too big of an
    incompatible change from current practice to be seriously considered. 

Indeed. Since there's been mail following yours contesting this statement,
let me put in my two bits worth of reinforcement of this statement.

In my experience -- looking at quite a lot of Common Lisp code
by a number of authors -- people select between DEFPARAMETER and DEFVAR
primarily on the basis only of SETQ-IF-UNBOUND behavior.

I, and most other people I know, write DEFPARAMETER if re-loading the
same file should reset the value and DEFVAR otherwise. Consider:

 -----File A-----
 (DEFVAR *FOO* '())
 (DEFPARAMETER *BAR* '())
 ----------------

 -----File B-----
 (PUSH 'X *FOO*)
 (PUSH 'X *BAR*)
 ----------------

If you load A, then B, then A, you clobber *BAR*, but not *FOO*.
So I always DEFVAR things like lists of objects, etc. that act
as a database. But I always DEFPARAMETER things like global option
variables that would want to be re-initialized if the system was
re-loaded. Some people might not even DEFPARAMETER option variables,
figuring people who had set them would want their values retained.
But always, that decision is made on the basis of whether SETQ
or SETQ-IF-UNBOUND is done -- not on any mythical abstract useless
notion of what a "variable" vs "parameter" is.

∂09-Oct-88  0036	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Oct 88  00:36:31 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 473532; Sun 9-Oct-88 03:34:44 EDT
Date: Sun, 9 Oct 88 03:34 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue DEFCONSTANT-VALUE
To: Gray@DSG.csc.ti.com
cc: sandra%defun@cs.utah.edu, CL-Compiler@SAIL.Stanford.edu
In-Reply-To: <2801165525-10237139@Kelvin>
Message-ID: <881009033429.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

If any kind of feature like this were added, I'd want to first
see a declaration (useful with both DECLARE and PROCLAIM) before
I thought about any macro encapsulation. I'd like to be able
to explain any DEFPARAMETER-xxx macro in terms of more primitive
functionality.

∂09-Oct-88  0041	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Oct 88  00:41:49 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 473535; Sun 9-Oct-88 03:40:09 EDT
Date: Sun, 9 Oct 88 03:39 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue DEFCONSTANT-NOT-WIRED
To: Gray@DSG.csc.ti.com
cc: sandra%defun@cs.utah.edu, CL-Compiler@SAIL.Stanford.edu
In-Reply-To: <2801165525-10237139@Kelvin>
Supersedes: <881009033429.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <881009033954.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

[Sorry, an earlier version of this same message picked up
 the wrong subject line. This is about DEFCONSTANT-NOT-WIRED,
 not DEFCONSTANT-VALUE.]

If any kind of feature like this were added, I'd want to first
see a declaration (useful with both DECLARE and PROCLAIM) before
I thought about any macro encapsulation. I'd like to be able
to explain any DEFPARAMETER-xxx macro in terms of more primitive
functionality.

∂10-Oct-88  1334	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED    
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.Stanford.EDU with TCP; 10 Oct 88  13:34:49 PDT
Received: from DOUGHNUT.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 59921; Mon 10-Oct-88 16:22:49 EDT
Date: Mon, 10 Oct 88 16:22 EDT
From: Brad Miller <miller@CS.ROCHESTER.EDU>
Subject: Re: Issue DEFCONSTANT-NOT-WIRED
To: Eric Benson <eb@LUCID.COM>
cc: Gray@DSG.csc.ti.com, sandra%defun@CS.UTAH.EDU, CL-Compiler@SAIL.STANFORD.EDU
In-Reply-To: <8810080108.AA00560@blacksox>
Message-ID: <19881010202240.9.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Sender: miller@CS.ROCHESTER.EDU
Reply-To: miller@CS.ROCHESTER.EDU
Organization: University of Rochester, Department of Computer Science
Postal-address: 610 CS Building, Comp Sci Dept., U. Rochester, Rochester NY 14627
Phone: 716-275-1118

    Date: Fri, 7 Oct 88 18:08:23 pdt
    From: Eric Benson <eb@lucid.com>

    Perhaps.  Do you consider this "a change *to* the program" as stated
    in CLtL?  If you only ever change it at the top level, for example,
    you're probably working in the spirit of DEFPARAMETER.  Would you need
    to change your program to use DEFVAR instead of DEFPARAMETER if a
    warning was signalled every time a variable defined with DEFPARAMETER
    is SETQed (as opposed to re-evaluating the DEFPARAMETER form with a
    different initial value)?

I have no problem with getting a warning; if I change it, it is usually in a
patch file (where such warnings are turned off anyway). I am just concerned
about making a semantic difference between having the compiler assume that a
defparameter will never change but not folding, vs. assuming it may change,
but not during execution. The model that essentially folds defparameter into
a special kind of defvar, for example, works. Making it any kind of
defconstant probably doesn't. Consider when the type of the the
defparameter changes, for example. If the compiler doesn't fold the
reference but does assume that the reference doesn't change, it may make
assumptions about the type of the object that aren't going to be valid
across (what I have been assuming are) valid redefinitions of the parameter.

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

∂11-Oct-88  1136	CL-Compiler-mailer 	Error specification 
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 11 Oct 88  11:36:01 PDT
Received: from relay2.cs.net by RELAY.CS.NET id am08595; 11 Oct 88 13:14 EDT
Received: from draper.com by RELAY.CS.NET id aa04796; 11 Oct 88 12:50 EDT
Date: Tue, 11 Oct 88 07:51 EDT
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Error specification
To: cl-compiler@SAIL.STANFORD.EDU
X-VMS-To: CL-COMPILER,SEB1525

I'm a late/newcomer to this list.  Could someone send me a copy of the
"new error specification" so I know what it's all about?  Thanks.
  
Actually, if there is a way for me to get hold of the current state of
the CL compiler proposals, I'd really like to see that.  But since that
would probably overload me at this time, I'd be satisfied just to see the
error proposal.  Send to seb1525@draper.com.
 

∂13-Oct-88  1137	CL-Compiler-mailer 	summary from Fairfax meeting  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Oct 88  11:36:58 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA15010; Thu, 13 Oct 88 12:35:22 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19770; Thu, 13 Oct 88 12:35:20 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810131835.AA19770@defun.utah.edu>
Date: Thu, 13 Oct 88 12:35:18 MDT
Subject: summary from Fairfax meeting
To: cl-compiler@sail.stanford.edu

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

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

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

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

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

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

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

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

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

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

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

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

-Sandra
-------

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

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

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

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

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

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

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

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

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

-Sandra
-------

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

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

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

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

-Sandra
-------

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

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

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

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

				-Cris

∂14-Oct-88  0857	CL-Compiler-mailer 	Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Oct 88  08:57:04 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 476456; Fri 14-Oct-88 11:57:14 EDT
Date: Fri, 14 Oct 88 11:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)
To: CL-Compiler@SAIL.Stanford.EDU
cc: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
In-Reply-To: <881013192927.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881014155652.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

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

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

Sounds good.  As a favor, could you cc me on that discussion?  I'm not
on CL-Compiler, but I have an interest in this particular issue.

∂14-Oct-88  1419	CL-Compiler-mailer 	Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 14 Oct 88  14:19:30 PDT
Received: by ti.com id AA25030; Fri, 14 Oct 88 16:18:52 CDT
Received: from Kelvin by tilde id AA22372; Fri, 14 Oct 88 16:08:14 CDT
Message-Id: <2801855399-4664990@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 14 Oct 88  16:09:59 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Eric Benson <eb@LUCID.COM>
Cc: CL-Compiler@SAIL.Stanford.edu,
        "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
In-Reply-To: Msg of Fri, 7 Oct 88 17:59:47 pdt from Eric Benson <eb@LUCID.COM>

> I would like to combine all of these aspects into returned values from
> ENVIRONMENT-VARIABLE-KIND and ENVIRONMENT-FUNCTION-KIND (and probably
> change those names).  That's going to mean a lot of returned values,
> though.  Does anyone think that's a bad idea?

That's going to make it slower by collecting more information than you
probably need at any one time; is that a concern for what you want to
use this for?

> "All the rest of this stuff" is useful to code walkers for the same
> reason it's useful to compilers.

Useful for it's own bookkeeping yes, but does the code walker really
need to have the compiler use the same data structures so that the code
walker can access what the compiler knows?

> The extent of environment objects has been discussed before.  I don't
> remember whether that became a full-fledged cleanup issue, but I think
> it is orthogonal to this issue. 

It might be orthogonal in theory, but in practical terms it makes a big
difference to whether this proposal is feasible to implement as an
addition to existing compilers.

>      In this case, I suspect that CLOS is going to need more than
>    ENVIRONMENT-TARGET to do everything it needs to do.
> 
> What is your suspicion based on?

On preliminary thinking about how environments need to be handled in our
CLOS implementation; hopefully in a couple of weeks I will have
developed a clearer idea about this.

∂14-Oct-88  1505	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-VALUE (V2)   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 14 Oct 88  15:05:40 PDT
Received: by ti.com id AA25342; Fri, 14 Oct 88 17:04:11 CDT
Received: from Kelvin by tilde id AA23256; Fri, 14 Oct 88 16:51:18 CDT
Message-Id: <2801857997-4821074@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 14 Oct 88  16:53:17 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Compiler@SAIL.Stanford.edu
Subject: Re: Issue DEFCONSTANT-VALUE (V2)
In-Reply-To: Msg of Sun, 9 Oct 88 03:23 EDT from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

>     It is implementation dependent whether or not the symbol value is
>     actually set at compile time or whether COMPILE-FILE temporarily
>     remembers the value in some other way.
>     ...
> 
> However, I a couple of major problems with this...
> 
> It implies that you can't use the variable FOO in either
> a macro or an (EVAL-WHEN (COMPILE) ...). That seems unfortunate.
> 
> Not only is it sad, but it is sad for no apparent good reason.
> There's no efficiency reason that I can think of for not pinning
> this down and just saying it will be available at compile time.

I fully intend it to be available at compile time.  I just want to
permit implementations to make it available on a temporary basis during
COMPILE-FILE instead of as a permanent side-effect.  Setting the
symbol's value cell is just one possible implementation technique.
Evidently some clearer wording is needed.

∂17-Oct-88  1203	CL-Compiler-mailer 	issue LOAD-TIME-EVAL, version 7    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Oct 88  12:02:58 PDT
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA05358; Mon, 17 Oct 88 13:02:50 MDT
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA22253; Mon, 17 Oct 88 13:02:47 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810171902.AA22253@defun.utah.edu>
Date: Mon, 17 Oct 88 13:02:46 MDT
Subject: issue LOAD-TIME-EVAL, version 7
To: cl-compiler@sail.stanford.edu

Here is my new writeup on this issue.  The proposal is pretty much the same
as the draft REVISED-NEW-SPECIAL-FORM I distributed earlier (with some
changes in wording), that does not tie LOAD-TIME-VALUE to #,.

-Sandra


Issue:          LOAD-TIME-EVAL
References:     #, (p. 356),  (EVAL-WHEN (LOAD) ...) (p. 69-70)
		issue SHARP-COMMA-CONFUSION
Category:       ADDITION
Edit history:   06-Jun-87, Version 1 by James Kempf
                17-Jul-87, Version 2 by James Kempf
                12-Nov-87, Version 3 by Pitman (alternate direction)
                01-Feb-88, Version 4 by Moon
                  (from version 2 w/ edits suggested by Masinter)
                06-Jun-88, Version 5 by Pitman
                  (fairly major overhaul, merging versions 3 and 4)
                21-Sep-88, Version 6 by Moon (stripped down)
		17-Oct-88, Version 7 by Loosemore (change direction again)
Status:         For internal discussion

Problem description:

 Common Lisp provides reader syntax (#,) which allows the programmer
 to designate that a particular expression within a program is to be
 evaluated early (at load time) but to later be treated as a constant.
 Unfortunately, no access to this capability is available to programs
 which construct other programs without going through the reader.
    
 Some computations can be deferred until load time by use of EVAL-WHEN,
 but since EVAL-WHEN must occur only at toplevel, and since the nesting
 behavior of EVAL-WHEN is quite unintuitive, EVAL-WHEN is not a general
 solution to the problem of load-time computation of program constants.


Proposal (LOAD-TIME-EVAL:R**2-NEW-SPECIAL-FORM):
    
 Add a new special form, LOAD-TIME-VALUE, which has the following
 contract:

   LOAD-TIME-VALUE form &optional read-only-p	[Special Form]


   LOAD-TIME-VALUE provides a mechanism for delaying evaluation of <form>
   until the expression is in the "runtime" environment.  

   If a LOAD-TIME-VALUE expression is seen by COMPILE-FILE, the compiler
   arranges for all semantic processing of <form> (including macro
   expansion) to occur at load time in a null lexical environment.  It
   is guaranteed that the evaluation of <form> will take place only once
   when the file is loaded, but the order of evaluation with respect to
   the "evaluation" of top-level forms in the file is unspecified.

   If a LOAD-TIME-VALUE expression appears within a function compiled
   with COMPILE, the <form> is evaluated at compile time in a null lexical
   environment.  The result of this compile-time evaluation is treated as 
   an immediate quantity in the compiled code.  

   In interpreted code, (LOAD-TIME-VALUE <form>) is equivalent to (VALUES
   (EVAL (QUOTE <form>))).  Implementations which implicitly compile
   (or partially compile) expressions passed to EVAL may evaluate the 
   <form> only once, at the time this compilation is performed.  This is
   intentionally similar to the freedom which implementations are given
   for the time of expanding macros in interpreted code.

   Note that, in interpreted code, there is no guarantee as to when
   evaluation of <form> will take place, or the number of times the
   evaluation will be performed.  Since successive evaluations of the
   same LOAD-TIME-VALUE expression may or may not result in an evaluation
   which returns a "fresh" object, destructive side-effects to the
   resulting object may or may not persist from one evaluation to the
   next.  It is safest to explicitly initialize the object returned by
   LOAD-TIME-VALUE, if it is later modified destructively.

   Implementations must guarantee that each reference to a
   LOAD-TIME-VALUE expression results in at least one evaluation of its
   nested <form>.  It is not permissible to "collapse" either multiple
   references to the same (EQ) LOAD-TIME-VALUE expression, or EQUAL
   expressions.  In the case of a LOAD-TIME-VALUE form appearing in a
   quoted expression passed to EVAL, each call to EVAL must result in a
   new evaluation of <form>.  For example,
     (DEFVAR X 0)
     (DEFUN FOO () (EVAL '(LOAD-TIME-VALUE (INCF X))))
   is guaranteed to increment X each time FOO is called, while
     (DEFUN FOO () (LOAD-TIME-VALUE (INCF X)))
   may cause X to be evaluated only once.

   The READ-ONLY-P argument designates whether the result can be considered
   read-only constant. If NIL (the default), the result must be considered 
   ordinary, modifiable data. If T, the result is a read-only quantity
   which may, as appropriate, be copied into read-only space and/or shared
   with other programs. (Because this is a special form, this argument is
   -not- evaluated and only the literal symbols T and NIL are permitted.)


Rationale:

   LOAD-TIME-VALUE is a special form rather than a function or macro 
   because it requires special handling by the compiler.
    
   Allowing the same LOAD-TIME-VALUE to cause its nested <form> to be
   evaluated more than once makes simplifies its implementation in
   interpreters which do not perform a preprocessing code walk.  It also
   makes the rules for the time of its processing analogous to those
   for macro expansion.

   This proposal explicitly does -not- tie LOAD-TIME-VALUE to the #,
   read macro.  Doing so would be an incompatible change to the definition
   of #, (which is reliably useful only -inside- quoted structure,
   while LOAD-TIME-VALUE must appear -outside- quoted structure in a
   for-evaluation position).

   The prohibition against collapsing of shared or EQUAL LOAD-TIME-VALUE
   expressions prevents problems that could result by performing destructive
   side-effects on a value that is referenced in more than one place.


Current Practice:

   This is an addition to the language and has not yet been implemented.


Cost to Implementors:

   In compiled code, (LOAD-TIME-VALUE <form>) is equivalent to '#,<form>.
   Most implementations can probably make use of the same mechanism they
   use to handle #, to handle LOAD-TIME-VALUE.

   Implementing LOAD-TIME-VALUE in the interpreter should be fairly
   straightforward, since one simply needs to evaluate the <form> in the
   null lexical environment.  Implementations that use a preprocessing
   code walk in the interpreter to perform macro expansion could process
   LOAD-TIME-VALUE forms at that time.

   Some code-walkers would have to be taught about this new
   special form. Such changes would likely be trivial.


Cost to Users:

   Some code-walkers would have to be taught about this new
   special form. Such changes would likely be trivial.


Benefits:

   Users are given a mechanism that to force evaluation to be delayed 
   until load time that does not rely on a feature of the reader.


Discussion:

   The semantics of LOAD-TIME-VALUE would be simplified considerably if
   the READ-ONLY-P argument were removed and destructive operations on
   the result of evaluating <form> prohibited.  However, some people feel
   that the ability to destructively modify the value is an important
   feature to include.

   "Collapsing" of equivalent LOAD-TIME-VALUE expressions could be
   allowed for read-only situations, but it seems like it would be more
   confusing to make it legal in some situations and not in others.

   A number of other alternatives have been considered on this issue, 
   including:

   - A proposal for a new special form that would force evaluation of
     the <form> to happen only once.  This was rejected because of
     implementation difficulties.

   - A proposal to add a function making the "magic cookie" used by #,
     available to user code.  The current proposal does not prevent such
     a function from being added, but this approach appeared to have
     less support than making the hook available as a new special form.

   - A proposal to remove #, entirely (issue SHARP-COMMA-CONFUSION).

   - A suggestion to change the behavior of (EVAL-WHEN (LOAD) ...).  Note
     that the current proposal forces -all- processing of the <form> to
     be delayed until load-time, while the body of an (EVAL-WHEN (LOAD) ...)
     is compiled normally.
-------

∂17-Oct-88  1204	CL-Compiler-mailer 	issue SHARP-COMMA-CONFUSION, version 1  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Oct 88  12:03:50 PDT
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA05365; Mon, 17 Oct 88 13:03:41 MDT
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA22260; Mon, 17 Oct 88 13:03:39 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810171903.AA22260@defun.utah.edu>
Date: Mon, 17 Oct 88 13:03:38 MDT
Subject: issue SHARP-COMMA-CONFUSION, version 1
To: cl-compiler@sail.stanford.edu

This is a new issue, split off from LOAD-TIME-EVAL.

-Sandra


Issue:		SHARP-COMMA-CONFUSION
References:	CLtL p. 356
		Issue LOAD-TIME-EVAL
Category:	CHANGE
Edit History:   V1, 17 Oct 1988, Sandra Loosemore


Problem Description:

The way the read macro #, is defined in CLtL does not make it clear
that it can only appear inside of (implicitly) quoted structure to
guarantee consistent handling between the interpreter and the
compiler.  Examples of inconsistent uses would be #, forms appearing
outside of a QUOTE that expand into list or symbol forms that could be
interpreted as code, or strings that could be interpreted as
documentation strings.  Users are even more likely to be confused
because the wording in CLtL compares the behavior of #, to the special
form EVAL-WHEN, which must appear in a for-evaluation position.

#, also presents a serious problem to program-analyzing programs
because evaluation is tied to the reader, rather than the interpreter
or compiler.  In theory, this could be handled by altering the read table
to have #, construct a "magic cookie" instead of performing read-time
evaluation and having the code walker examine quoted structures, but I've
never seen this actually done in practice.


Proposal SHARP-COMMA-CONFUSION:REMOVE:

Remove the #, read macro from the language.


Rationale:

Removing #, is simpler than trying to redefine it.  Removing it from
the standard, rather than redefining it to mean something else (see
issue LOAD-TIME-EVAL), would all implementations to continue to
provide it as an extension.  (Although CLtL does not appear to
explicitly address the question of whether implementations may extend
the reader syntax, some implementations already provide sharp-sign
read macros other than those described in CLtL, such as #P syntax for
pathnames.)


Current Practice:

#, is not used very frequently.  

PSL/PCLS has never bothered to implement #, correctly (it's treated
just like #.), and nobody has ever complained about it being broken.


Cost to implementors:

None.


Cost to users:

Because #, is used so infrequently, most users would probably not even
notice its absence.

In the few places where #, is currently used, some other language
construct such as DEFPARAMETER would have to be used instead.  For
example,

    ...  '#,(compute-the-value)  ...

could be rewritten as

    (defparameter result (compute-the-value))
    ... result ...

or

    (defparameter result (eval '(compute-the-value)))
    ... result ...

Issue LOAD-TIME-EVAL proposes to add a special form that would provide
a somewhat cleaner mechanism for doing the same thing (users wouldn't have
to think of a variable name).


Benefits:

The language specification is simplified by removing a peculiar
feature of the language that is accessible only through the reader.

Removing #, may also allow simpler strategies for implementing
compiled file loaders to be used.


Discussion:

If this proposal is rejected, the definition of #, in the standard will
still need to be clarified to indicate that #, can only appear in
quoted structure.  It should probably also include some mention of the
problems that #, can cause code walkers.
-------

∂17-Oct-88  1346	CL-Compiler-mailer 	issue SHARP-COMMA-CONFUSION, version 1  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Oct 88  13:46:49 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA05132g; Mon, 17 Oct 88 13:46:36 PDT
Received: by bhopal id AA03395g; Mon, 17 Oct 88 13:45:02 PDT
Date: Mon, 17 Oct 88 13:45:02 PDT
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8810172045.AA03395@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 17 Oct 88 13:03:38 MDT <8810171903.AA22260@defun.utah.edu>
Subject: issue SHARP-COMMA-CONFUSION, version 1

If you want a simple nasty example to support the case for flushing
#, consider what it would mean to compile a file containing just:

(defun peculiar #,(some-vars)
   #,(some-code))

 jlm

∂19-Oct-88  0850	CL-Compiler-mailer 	issue COMPILER-DIAGNOSTICS, version 2   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Oct 88  08:50:30 PDT
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA18557; Wed, 19 Oct 88 09:50:24 MDT
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA23503; Wed, 19 Oct 88 09:50:20 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810191550.AA23503@defun.utah.edu>
Date: Wed, 19 Oct 88 09:50:19 MDT
Subject: issue COMPILER-DIAGNOSTICS, version 2
To: cl-compiler@sail.stanford.edu

Version 1 of this issue went only to Dan Pierson, who is working on
the related issue GC-MESSAGES (which is going to include the NOTICE
condition type).  There are some unresolved questions mentioned in the
discussion section, and comments are solicited....

-Sandra



Issue:		COMPILER-DIAGNOSTICS
References:	CLtL p. 438-439
		Condition System, Revision #18
		S:>KMP>cl-conditions.text.34
		Issue GC-MESSAGES
Category:	CLARIFICATION, ENHANCEMENT
Edit History:   V1, 15 Oct 1988, Sandra Loosemore
		V2, 19 Oct 1988, Sandra Loosemore (minor fixes)


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, CLtL does not specify what the return value from COMPILE-FILE
should be.


Proposal COMPILER-DIAGNOSTICS:USE-HANDLER:

(1) Clarify that COMPILE-FILE is allowed to print messages indicating the
    normal progress of the compilation.

(2) Clarify that both ERROR and WARNING conditions may be signalled within
    COMPILE or COMPILE-FILE.  Except for arbitrary errors which may occur
    due to compile-time processing of (EVAL-WHEN (COMPILE) ...) forms or
    macro expansion, ERRORs and WARNINGs may be signalled by the compiler
    only in situations which are clearly documented in the standard.  An
    implementation may signal additional ERRORs and WARNINGs only in
    conjunction with processing of nonstandard special forms supported as
    an extension to Common Lisp by that implementation.  All other
    implementation-specific programming style diagnostics issued by
    the compiler should be signalled as conditions of type NOTICE.

(3) Add a :HANDLER keyword argument to COMPILE-FILE, which is a condition
    handler function which is to be used during compilation.  If NIL or
    not supplied, COMPILE-FILE is allowed to establish its own
    implementation-specific condition handler, which may or may not cause
    the debugger to be entered when errors occur.  It is permissible for
    the default error handler to attempt to recover from the error and
    continue compiling the file.

(4) Specify that COMPILE-FILE returns the pathname for the output file if
    it was able to successfully compile the input file.  However, if
    ERRORs occur and the compiler is able to recover and return normally,
    it should return NIL to indicate unsuccessful completion.

(5) Clarify that COMPILE does not establish a condition handler.  Instead,
    it uses whatever condition handler has been established in the environment
    from which it is called.


Rationale:

(1) This reflects current practice.

(2) Conditions such as syntax errors which are errors in the interpreter
    remain errors in the compiler.  Restricting implementations from
    having their compilers signal random errors and warnings allows user
    error handlers to know what kinds of conditions to expect.

(3) It is reasonable for the default handling of compiler errors not to
    cause the debugger to be invoked.  However, any error handler 
    established by COMPILE-FILE would override handlers established by the
    user in the surrounding environment.

(4) This allows users to determine whether or not COMPILE-FILE is able to
    actually compile the file successfully.

(5) This is to reflect the use of COMPILE-FILE as being more "batch"-oriented
    and COMPILE as being more interactive.  There is less motivation to have
    COMPILE try to recover from errors without user interaction.


Current Practice:

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

In Lucid Common Lisp, COMPILE-FILE invokes the debugger when it encounters
serious problems.  COMPILE-FILE returns the pathname for the output file.

Both VaxLisp and Lucid normally print out a lot of informational messages
during compilation, including names of files, names of each function
compiled, etc.


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.


Benefits:

Users are given a way to detect and handle compilation errors.


Discussion:

Pierson has suggested removing item (1) of the proposal and instead
requiring the compiler not to print out any random informational
messages.  We could define another kind of non-serious condition
(INFO?) to take care of trivia like file names and progress messages.
What do you implementors think about this?

This proposal, as it stands, doesn't propose to add any new conditions
specific to the compiler.  We might consider introducing a 
COMPILER-CONDITION that can be used in mixins with the other condition
types, so that error handlers can distinguish between errors signalled
by the compiler itself and errors signalled during macroexpansion or
EVAL-WHEN processing.

The warnings and errors which can potentially be signalled during the
processing of standard special forms and macros need to be spelled out
in detail.
-------

∂20-Oct-88  1207	CL-Compiler-mailer 	issue COMPILER-DIAGNOSTICS, version 2   
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 20 Oct 88  12:07:32 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 289182; Thu 20-Oct-88 15:06:03 EDT
Date: Thu, 20 Oct 88 15:05 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-DIAGNOSTICS, version 2
To: sandra%defun@cs.utah.edu
cc: cl-compiler@sail.stanford.edu
In-Reply-To: <8810191550.AA23503@defun.utah.edu>
Message-ID: <881020150558.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

The problem description seems well-stated.

I wonder: is it really true that COMPILE-FILE's return value is not
well-defined and that it is not covered in Cleanup issue
ARGUMENTS-UNDERSPECIFIED? That's a small point, of course.

    Proposal COMPILER-DIAGNOSTICS:USE-HANDLER:

    (1) Clarify that COMPILE-FILE is allowed to print messages indicating the
	normal progress of the compilation.

I would prefer that we started to control this more tightly. On some systems,
the compiler types out info about each function as it is compiled. On others,
it tells only that it is compiling the file. I would like a way to control
this behavior. Even the :VERBOSE option to LOAD has the problem that no some
systems it makes the function either print out information like  ``Loading...''
while on other systems it prints out information about each function. As such,
some systems think typing out `just' ``Loading ...'' is not verbose and others
think it is verbose. I don't want to see the same fate befall COMPILE-FILE,
yet I think it's important to think about. I would prefer something like
 :VERBOSE = T, :BRIEF, NIL (or :DETAILED, T, NIL -- depending on what you
			       think T should mean)
or maybe COMPILE-FILE should have a PRINT option.

This is a major hassle for Macsyma, by the way, which autoloads files in the
middle of running user applications and needs to be able to offer a similar
level of typeout independent of the host environment.

    (2) Clarify that both ERROR and WARNING conditions may be signalled within
	COMPILE or COMPILE-FILE.  Except for arbitrary errors which may occur
	due to compile-time processing of (EVAL-WHEN (COMPILE) ...) forms or
	macro expansion, ERRORs and WARNINGs may be signalled by the compiler
	only in situations which are clearly documented in the standard.  An
	implementation may signal additional ERRORs and WARNINGs only in
	conjunction with processing of nonstandard special forms supported as
	an extension to Common Lisp by that implementation.  All other
	implementation-specific programming style diagnostics issued by
	the compiler should be signalled as conditions of type NOTICE.

I think this goes at things from the wrong angle. I would prefer to see any
kinds of conditions be permitted to be signalled, but have the compiler required
to handle unhandled errors by turning them to warnings and aborting some
part of the compilation.

I think the restriction about what kinds of errors might be signalled is
very arbitrary and I doubt anyone will buy into it. As long as COMPILE-FILE
will trap the errors that the user handler (mentioned below) doesn't, the
user program is not going to break. If you say that other errors cannot be
signalled, you are saying that you have studied the language so well that
you believe there is no possible way for there to be a fatal error other
than those the CL committee has thought of. I just plain don't believe we're
that thorough and/or gifted with foresight. We must leave what the compiler
detects as open-ended, so I think the only answer is to expect that 
COMPILE-FILE will, in some cases, trap the errors we don't expect, and so
will tell us that the compilation has failed.

You'd have to be a lot more detailed about this NOTICE condition, where it
lives in the type hierarchy, whether there's a function that signals it,
whether it has any slots, what default handlers will exist for it, etc. to
make it believable, I think. I don't really recommend this.

    (3) Add a :HANDLER keyword argument to COMPILE-FILE, which is a condition
	handler function which is to be used during compilation.  If NIL or
	not supplied, COMPILE-FILE is allowed to establish its own
	implementation-specific condition handler, which may or may not cause
	the debugger to be entered when errors occur.  It is permissible for
	the default error handler to attempt to recover from the error and
	continue compiling the file.

This is an ok idea. But COMPILE-FILE should establish its handlers
unconditionally in case the user-supplied handler declines. Also, you probably
want to define that the ABORT restart will be handled and abort the smallest
feasible part of the compilation.

I see no reason to permit the compiler to enter the debugger at all. If
we need that, we should offer a keyword option. Systems can provide
other ways of entering the file compiler than COMPILE-FILE if they need
to offer such a capability.  COMPILE-FILE is a portable interface and
should behave as portably as possible.  To me, that means it should
always be required to enter the debugger on unhandled errors or always
forbidden. I prefer the latter.

    (4) Specify that COMPILE-FILE returns the pathname for the output file if
	it was able to successfully compile the input file.  However, if
	ERRORs occur and the compiler is able to recover and return normally,
	it should return NIL to indicate unsuccessful completion.

In some cases, the implementors may want to create a file even if it's bad.
As such, I think you should say it returns the pathname of a file if one was
created, and it always returns a second value saying whether the file is
believed `ok' (ie, no fatal errors seen).

    (5) Clarify that COMPILE does not establish a condition handler.  Instead,
	it uses whatever condition handler has been established in the environment
	from which it is called.

This sounds ok.

    Rationale:

I had to go back and re-write all my replies to this because I didn't realize
your rationales were point by point. I assumed all five of these points factored
over all five of the points above. Say something to indicate that you're doing
piecewise rationalization.

    (1) This reflects current practice.

Compilers vary quite a lot and it's quite irritating. See above.

    ...
    Current Practice:

Symbolics Genera usually tries to keep compiling when it encounters errors.
Symbolics Cloe ...

Regarding the other problem I mentioned above about progress/verbosity,
Symbolics Genera does not type out the name of each function as it is being
compiled; Symbolics Cloe (Runtime) does type out the name of each function
as it is being compiled.

    ...
    Cost to users:

    This is a compatible extension...

Make it clearer that although it's compatible, user code (which is probably
used to the randomized behavior now) would almost certainly need to change
in subtle ways. Usually such changes would be simplifications, but unlike
some functions which aren't well-defined portably it's hard to argue that
no one uses COMPILE or COMPILE-FILE in spite of disparate behavior, so we
have to acknowledge that this is, in practice, gonna break `portable' code.

    ...
    Benefits:

    Users are given a way to detect and handle compilation errors.

Say something here about uniformity/portability.

    Discussion:

    Pierson has suggested removing item (1) of the proposal and instead
    requiring the compiler not to print out any random informational
    messages.  We could define another kind of non-serious condition
    (INFO?) to take care of trivia like file names and progress messages.
    What do you implementors think about this?

I would prefer to see the interfaces to LOAD made more specific about what
kinds of options each of the keywords are supposed to control, and then as
symmetric as possible a set of options provided for COMPILE/COMPILE-FILE.

    The warnings and errors which can potentially be signalled during the
    processing of standard special forms and macros need to be spelled out
    in detail.

I strongly disagree. The -only- kinds of errors we should spell out are
the ones which we want to encourage people to handle portably. The
intricacies of how special forms, etc. are handled in each system means
there's unlikely to be any portable kind of fix you can make. Put another
way (suggested to me by Moon), do we want to encourage a `portable programming
style' which calls COMPILE-FILE with a handler for some UNSEEN-GO-TAG  
condition that somehow magically tries to correct it or do we want to just
say it signals a SYNTAX-ERROR and that the person should edit his code to
not reference non-existent go tags. It seems clear to me that the latter
is true.

We have very limited resources for spelling out condition meanings and those
resources should be directed toward things like common pathname errors
(no such directory, link to non-existent file, etc.) which we can reasonably
expect to feel good about handling in portable code.

∂20-Oct-88  1408	CL-Compiler-mailer 	Re: issue COMPILER-DIAGNOSTICS, version 2    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Oct 88  14:05:36 PDT
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA25128; Thu, 20 Oct 88 15:01:20 MDT
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA25278; Thu, 20 Oct 88 14:59:17 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810202059.AA25278@defun.utah.edu>
Date: Thu, 20 Oct 88 14:59:14 MDT
Subject: Re: issue COMPILER-DIAGNOSTICS, version 2
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>, Thu, 20 Oct 88 15:05 EDT

> Date: Thu, 20 Oct 88 15:05 EDT
> From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
> 
> I wonder: is it really true that COMPILE-FILE's return value is not
> well-defined and that it is not covered in Cleanup issue
> ARGUMENTS-UNDERSPECIFIED? That's a small point, of course.

I suspect the issue you're thinking of is RETURN-VALUES-UNSPECIFIED,
and no, it doesn't say anything about COMPILE-FILE.

> I think this goes at things from the wrong angle. I would prefer to see any
> kinds of conditions be permitted to be signalled, but have the compiler required
> to handle unhandled errors by turning them to warnings and aborting some
> part of the compilation.
> 
> I think the restriction about what kinds of errors might be signalled is
> very arbitrary and I doubt anyone will buy into it. As long as COMPILE-FILE
> will trap the errors that the user handler (mentioned below) doesn't, the
> user program is not going to break. 
> 
> But COMPILE-FILE should establish its handlers
> unconditionally in case the user-supplied handler declines. Also, you probably
> want to define that the ABORT restart will be handled and abort the smallest
> feasible part of the compilation.

You make a good argument for this.  I'll give this some more thought
and see if I can come up with a revised proposal along the lines you
suggest.  I'm not sure that we want to -require- the compiler's error
handler to turn errors into warnings, but certainly they should be
-allowed- to do so.  And, I still think it's important for a user
error handler to be able to distinguish between serious compilation
problems and mere kibbitzing.

> I would prefer to see the interfaces to LOAD made more specific about what
> kinds of options each of the keywords are supposed to control, and then as
> symmetric as possible a set of options provided for COMPILE/COMPILE-FILE.

I thought of this earlier, as well.  Would we also want to add a
*COMPILE-VERBOSE* variable?  Is there any reason why this shouldn't be
split off as a separate issue?  (One could argue that what the
compiler prints out during its normal operation has nothing at all to
do with what it does with errors.)

Your other comments are all very useful.  Thank you.

-Sandra
-------

∂20-Oct-88  1435	CL-Compiler-mailer 	Re: issue COMPILER-DIAGNOSTICS, version 2    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Oct 88  14:35:38 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 479595; Thu 20-Oct-88 17:35:47 EDT
Date: Thu, 20 Oct 88 17:35 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue COMPILER-DIAGNOSTICS, version 2
To: sandra%defun@cs.utah.edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, cl-compiler@sail.stanford.edu
In-Reply-To: <8810202059.AA25278@defun.utah.edu>
Message-ID: <881020173539.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

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

    ... I'm not sure that we want to -require- the compiler's error
    handler to turn errors into warnings, but certainly they should be
    -allowed- to do so.  And, I still think it's important for a user
    error handler to be able to distinguish between serious compilation
    problems and mere kibbitzing.

It's important to note that we're not forcing a compiler to behave a
specific way, only forcing COMPILE-FILE. Suppose an implementation's
primitive file-compiler is called COMPILER:COMPILE-FILE and suppose
that function lets errors show through. Nothing keeps the implementors
from building LISP:COMPILE-FILE atop that function in a way that is
compatible. eg,

 (DEFUN COMPILE-FILE (FILE &REST ARGUMENTS &KEY HANDLER)
   (FLET ((DO-IT () 
	    (APPLY #'COMPILER:COMPILE-FILE FILE :ALLOW-OTHER-KEYS T ARGUMENTS)))
     (HANDLER-BIND ((ERROR #'ABORT-INNERMOST-COMPILATION-HANDLER))
       (IF HANDLER
	   (HANDLER-BIND ((ERROR HANDLER)) (DO-IT))
	   (DO-IT)))))

    ...  Would we also want to add a *COMPILE-VERBOSE* variable?  Is
    there any reason why this shouldn't be split off as a separate issue?
    (One could argue that what the compiler prints out during its normal
    operation has nothing at all to do with what it does with errors.)

Since this has nothing to do with conditions and will presumably raise a
completely different set of issues, I think separating it is a very good idea.

∂21-Oct-88  1401	CL-Compiler-mailer 	Issue: IN-SYNTAX (Version 1)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Oct 88  14:01:13 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00405g; Fri, 21 Oct 88 14:00:49 PDT
Received: by bhopal id AA11541g; Fri, 21 Oct 88 13:59:17 PDT
Date: Fri, 21 Oct 88 13:59:17 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810212059.AA11541@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU, CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Fri, 21 Oct 88 14:01 EDT <881021140158.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: IN-SYNTAX (Version 1)

This issue is far too narrowly focused right now.  For example,

-- I would *strongly* favor the name IN-READTABLE over IN-SYNTAX; the
   analogy is that IN-PACKAGE sets *PACKAGE*.  Alternatively, IN-SYNTAX
   would have to jointly handle *READ-BASE* and *PACKAGE* as well as
   *READTABLE*.

-- The change suggested for IN-PACKAGE in the IN-SYNTAX:NEW-MACRO proposal 
   presumes:
    (1) acceptance of the more radical IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
        proposal, or at least eliminating the :use and :nicknames arguments;
    (2) acceptance of the Cl-compiler's EVAL-WHEN-NON-TOP-LEVEL proposal.
   While I favor both of these pivotal proposals, one might not want to
   get this issued hung up over them.

-- The rebindings of syntax parameters like *PACKAGE* and *READ-TABLE* by 
   LOAD and COMPILE-FILE are currently directed towards the perpetuation of 
   a horrible loophole; binding to "the current" values encourages the kind
   of viewpoint mistakes that occur frequently even to fairly compotent 
   programmers.


In short, we would all be better off if LOAD and COMPILE-FILE started out 
in a ***known*** configuration.  I would suggest binding *READ-BASE* to 10,
*PACKAGE* to USER, and *READTABLE* to a value like (copy-readtable nil).


The MIMIMAL proposal -- assuming the name change -- is nearly 
uncontroversial, and wouldn't preclude subsequent embellishments.
How about adding *READ-BASE* to it, and considering more standard
default values?


-- JonL --

∂21-Oct-88  1415	CL-Cleanup-mailer 	Issue: IN-SYNTAX (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Oct 88  14:15:17 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 480205; Fri 21-Oct-88 17:13:31 EDT
Date: Fri, 21 Oct 88 17:13 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: IN-SYNTAX (Version 1)
To: jonl@lucid.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU,
    CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: <8810212059.AA11541@bhopal>
Message-ID: <881021171320.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Fri, 21 Oct 88 13:59:17 PDT
    From: Jon L White <jonl@lucid.com>

    This issue is far too narrowly focused right now.  For example,

[Reasonable comments ommitted for now.]

    In short, we would all be better off if LOAD and COMPILE-FILE started out 
    in a ***known*** configuration.  I would suggest binding *READ-BASE* to 10,
    *PACKAGE* to USER, and *READTABLE* to a value like (copy-readtable nil).

I'm worried about this because:

   - LISP is unsuitable because you don't know what's in it.
   - USER is unsuitable because
     - it may contain implementation-dependent stuff, including
       shadowed definitions of standard common lisp things.
     - its express purpose is for users to muck around in, so even
       if it starts off clean, it won't stay that way. as such, either
       it will be unreliable to load anything once you've been fooling
       around awhile or you'll have to know not to do some things that
       might screw up loading. either of these is unacceptable.
   - SYSTEM is unsuitable because you can't know what's in it.
   - KEYWORD is unsuitable because it has no functions in it and you'd
     have to use package prefixes anyway.

    ...
    The MIMIMAL proposal -- assuming the name change -- is nearly 
    uncontroversial, and wouldn't preclude subsequent embellishments.
    How about adding *READ-BASE* to it, and considering more standard
    default values?

Something I just thought of (a result of thinking about your message):
In spite of my hesitation about using USER, I have to say that it might
be kinda nice if LOAD could rebind everything to its `standard value' if
we could adopt the STANDARD-VALUE proposal. If that were true, then
people could do LET-STANDARD to affect the value if they really wanted
to, yet not only *PACKAGE*, but also *READTABLE*, *PRINT-BASE*, etc.
could be handled in a reason which was intuitively nice and didn't have
to pick some arbitrary set of variables to bind. Maybe if we did that,
I wouldn't feel a need to push this issue. When you've had a chance to
review that proposal, let me know how you feel about this idea.

∂21-Oct-88  1420	CL-Cleanup-mailer 	Issue: IN-SYNTAX (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Oct 88  14:20:11 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 480211; Fri 21-Oct-88 17:20:02 EDT
Date: Fri, 21 Oct 88 17:19 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: IN-SYNTAX (Version 1)
To: jonl@lucid.com
cc: CL-Cleanup@SAIL.Stanford.EDU, CL-Compiler@SAIL.Stanford.EDU
References: <881021171320.4.KMP@BOBOLINK.SCRC.Symbolics.COM>,
            <8810212059.AA11541@bhopal>
Message-ID: <881021171949.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

I noticed too late that you had added CL-Compiler. 
I would -really- prefer if you didn't cc CL-Compiler in
further debate and if CL-Compiler would just pretend for now
that they hadn't seen those two pieces of mail.
My reasoning:

 - The discussion style of the two lists is very different.

 - It's a pain for those of us who are on both lists to get
   two or three copies.

 - It isn't wise to have people involved in only half of a
   discussion.  They don't know what conversation has gone
   before and so are likely to duplicate points already made.
   Or else they may comment out of paranoia about what might
   have gone before rather than from an informed standpoint.

If and when we deem it appropriate to pass this off to CL-Compiler
for review, we should do so in some form of organized presentation
rather than in the form of random cc's of occassional messages.

∂21-Oct-88  1716	CL-Compiler-mailer 	Issue DEFCONSTANT-VALUE  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Oct 88  17:16:03 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00633g; Fri, 21 Oct 88 17:14:49 PDT
Received: by bhopal id AA12270g; Fri, 21 Oct 88 17:13:12 PDT
Date: Fri, 21 Oct 88 17:13:12 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810220013.AA12270@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: Gray@DSG.csc.ti.com, sandra%defun@cs.utah.edu,
        CL-Compiler@SAIL.Stanford.edu
In-Reply-To: Kent M Pitman's message of Sun, 9 Oct 88 03:34 EDT <881009033429.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue DEFCONSTANT-VALUE

re: If any kind of feature like this were added, I'd want to first
    see a declaration (useful with both DECLARE and PROCLAIM) before
    I thought about any macro encapsulation. 

This harkens back to the some (non?) cleanup proposal about LET-CONSTANT;
remember it?  I too like the idea of a declaration called CONSTANT.

-- JonL --

∂21-Oct-88  1854	CL-Compiler-mailer 	issue DEFPACKAGE    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Oct 88  18:54:47 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00712g; Fri, 21 Oct 88 18:54:30 PDT
Received: by bhopal id AA12710g; Fri, 21 Oct 88 18:52:57 PDT
Date: Fri, 21 Oct 88 18:52:57 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810220152.AA12710@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-cleanup@sail.stanford.edu, cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Thu, 13 Oct 88 14:34:04 MDT <8810132034.AA19839@defun.utah.edu>
Subject: issue DEFPACKAGE

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

This should be covered the "normal" way, like any other defining form, by 
the cl-compiler issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS.  I think
it should be implicitly eval-when(eval compile load).

Incidentally, echoing my previous sentiment, it seems simpler and hence
preferable to force the issue on COMPIL-FILE -- simply say that certain
toplevel forms are defaultly eval-when(eval compile load), unless the user 
explicitly wraps some other eval-when around them.  It's far too confusing 
to worry about when COMPILE-FILE retracts definitions that were in effect
"for the duration" of the compilation.  KMP also expressed this sentiment
when replying about the options for DEFCONSTANT-HARD-WIRED (or whatever).



re: I would also like to see more detail on the order that the various things
    are supposed to happen in, in the expansion of the macro.  I'm guessing 
    that it's supposed to be the same as "Put In Seven Extremely Random ..." 
    but I think the description needs to be more explicit.

The proposal does say something about this, and the only time ordering 
dependencies that are important (I think) are:
  (1) the package must be created, with it's :use links all set up, before
      any symbols are placed into it
  (2) most of the symbol creators/importers have to be disjoint, so it
      doesn't matter what order they are performed in.  The exception is
      :EXPORT.  The relevant wording from the proposal is:
	The collection of symbol-name arguments given to the options :SHADOW,
	:INTERNAL, :IMPORT-FROM, and :SHADOWING-IMPORT-FROM must all be
	disjoint; an error is signalled otherwise.  The :EXPORT option can
	be thought of as occuring after all the other options have been
	executed, since it may reference names found in "used" packages, 
	or found in the argument lists to a :SHADOW, :INTERNAL, :IMPORT-FROM, 
	or :SHADOWING-IMPORT-FROM option.

Perhaps a line or two like (1) and (2) could be added for clarity?


re: Finally, what is the motivation for not having DEFPACKAGE setq *PACKAGE*?

Defining forms usually just establish a name-to-object mapping; there is
little precedent for them also modifying global context state.  The one
form that is currently "confused" this way is the subject of an important
cleanup issue IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY to restore simplicity.

Note that if DEFPACKAGE also did an IN-PACKAGE, then the following 
reasonable file would become somewhat jumbled, because it wouldn't all 
be in on package:
   (in-package "USER")
   (defpackage "PHLOGISTON" (:use "LISP")             (:export "FIRE"))
   (defpackage "ALCHEMY"    (:use "LISP" "PHLOGISTON) (:export "GOLD"))



-- JonL --

∂25-Oct-88  1331	CL-Compiler-mailer 	Re: issue COMPILER-DIAGNOSTICS, version 2    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 25 Oct 88  13:31:48 PDT
Received: by ti.com id AA01183; Mon, 24 Oct 88 19:19:10 CDT
Received: from Kelvin by tilde id AA29176; Mon, 24 Oct 88 19:09:17 CDT
Message-Id: <2802730270-1319148@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 24 Oct 88  19:11:10 CDT
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 COMPILER-DIAGNOSTICS, version 2
In-Reply-To: Msg of Wed, 19 Oct 88 09:50:19 MDT from sandra%defun@cs.utah.edu (Sandra J Loosemore)

> Proposal COMPILER-DIAGNOSTICS:USE-HANDLER:
> 
> (1) Clarify that COMPILE-FILE is allowed to print messages indicating the
>     normal progress of the compilation.

Print them where?  Maybe these should go somewhere like *TERMINAL-IO*
instead of *STANDARD-OUTPUT* because you wouldn't normally want them in
a dribble file.

> (4) Specify that COMPILE-FILE returns the pathname for the output file if
>     it was able to successfully compile the input file. 

Could we specify that it returns the TRUENAME of the output file?

>        However, if
>     ERRORs occur and the compiler is able to recover and return normally,
>     it should return NIL to indicate unsuccessful completion.

There are actually more than two possibilities:
  1. No problems.
  2. Warnings.  The program can be loaded and run, but may not do what
     the programmer intended.
  3. Errors were detected that will cause a runtime error upon
     attempting to execute the faulty expression.
  4. Errors were detected that caused no code to be generated for one or
     more top-level forms.  Thus there may be whole functions simply
     missing from the object file.
  5. No object file could be written, or what was written can't be
     loaded.

Clearly it should return NIL for case 5, maybe for case 4, probably not
for case 3.

There is one more possibility, that either the input file or output
file could not be opened, but I don't think it is desirable for
COMPILE-FILE to catch that error.

> Current Practice:

On the Explorer, COMPILE-FILE displays the name of the function being
compiled when the option :VERBOSE T is given or special variable
COMPILER:COMPILER-VERBOSE is true.  It 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.

∂25-Oct-88  1557	CL-Compiler-mailer 	issue COMPILER-VERBOSITY, version 1
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 Oct 88  15:56:52 PDT
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA09849; Tue, 25 Oct 88 16:56:34 MDT
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA28942; Tue, 25 Oct 88 16:56:28 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810252256.AA28942@defun.utah.edu>
Date: Tue, 25 Oct 88 16:56:26 MDT
Subject: issue COMPILER-VERBOSITY, version 1
To: cl-compiler@sail.stanford.edu

Here is the first draft on this issue, which has been split off from
COMPILER-DIAGNOSTICS.  As usual, flames (or even suggestions) are
welcome. 

-Sandra


Issue:		COMPILER-VERBOSITY
References:	CLtL p. 438-329; 426
		issue COMPILER-DIAGNOSTICS
Category:	CHANGE/CLARIFICATION/ENHANCEMENT
Edit History:   V1, 25 Oct 1988, Sandra Loosemore


Problem Description:

Implementations vary widely in the amount of information that is printed
out by COMPILE-FILE.  In some situations, it would be useful to control
how much information is printed.


Proposal COMPILER-VERBOSITY:LIKE-LOAD:

Introduce a special variable, *COMPILE-VERBOSE*, with an implementation-
dependent initial value.

Add :VERBOSE and :PRINT keyword arguments to the function COMPILE-FILE,
analogous to those for the function LOAD.

The :VERBOSE argument (which defaults to the value of *COMPILE-VERBOSE*),
if true, permits COMPILE-FILE to print a message in the form of a comment
to *STANDARD-OUTPUT* indicating what file is being compiled and other
useful information.

The :PRINT argument (which defaults to NIL), if true, causes
information about top-level forms in the file being compiled to be
printed to *STANDARD-OUTPUT*.  Exactly what is printed will vary from
implementation to implementation, but nevertheless some information
will be printed.


Rationale:

This proposal makes COMPILE-FILE behave like LOAD.  There is already
some precedent for doing this (for example, issue COMPILE-FILE-PACKAGE,
which makes COMPILE-FILE as well as LOAD rebind *PACKAGE*).


Current Practice:

Lucid provides a :MESSAGES keyword argument to COMPILE-FILE, which can
either be a stream to send progress messages to, or NIL to suppress messages.
The default value is T, which sends messages to "the standard terminal
device".

On the TI Explorer, COMPILE-FILE displays the name of the function being
compiled when the option :VERBOSE T is given or special variable
COMPILER:COMPILER-VERBOSE is true.  (In other words, they use :VERBOSE
to mean what this proposal says to use :PRINT for.)


Cost to implementors:

This is an incompatible change for some implementations, but the changes
required should be fairly simple.  At least two implementations already
provide some similar mechanism for suppressing messages.


Cost to users:

Some (non-portable) user code may break in implementations where this is
an incompatible change.

Specifying that the :PRINT argument defaults to NIL is consistent with
LOAD, but in most implementations the default now is to print out a
lot of information about each function or top-level form.  Some users
may find it irritating to have to type in :print t to get the same
amount of information they're used to seeing.


Benefits:

Users are given a portable way to control how much information is printed
by COMPILE-FILE.


Discussion:

Rather than just treating :PRINT and :VERBOSE as boolean values, it
might be useful to have them convey more information.  For example,
Pitman has suggested using keyword values like :BRIEF or :DETAILED to
allow varying amounts of information of each type to be printed.
Alternatively, it might be reasonable to follow Lucid's precedent to
allow the values of :PRINT and :VERBOSE to be streams to allow
messages to be directed somewhere other than *STANDARD-OUTPUT*.
Either of these suggestions could reasonably be made to apply to LOAD
as well, but the intent of this proposal is to make COMPILE-FILE
behave like LOAD, not to change the specification of LOAD.

Pierson has suggested an entirely different approach -- introducing
one or more new condition types for informational messages.  This
could be presented as an alternative proposal on this issue, if he
cares enough about it to write it up.  Loosemore believes that using
conditions for this purpose is not appropriate, because this issue
deals with messages indicating the normal progress of the compiler and
conditions are supposed to be used to signal exceptional
(non-ordinary) situations.
-------

∂26-Oct-88  1203	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY, V3    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 26 Oct 88  12:02:38 PDT
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA08359; Wed, 26 Oct 88 13:02:19 MDT
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA29479; Wed, 26 Oct 88 13:02:13 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810261902.AA29479@defun.utah.edu>
Date: Wed, 26 Oct 88 13:02:12 MDT
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, V3
To: cl-compiler@sail.stanford.edu

This issue was distributed in draft form before the October meeting.  I've
incorporated the one suggestion I've received on it since then.  This is one
of the issues I'd like to send out on a mail ballot in about a month, so
if you have any serious problems with the writeup, please say so ASAP.

JonL, since you volunteered to act as a go-between with the CLOS people,
could you make sure that section 2h says the right things?

-Sandra



Issue:		COMPILE-ENVIRONMENT-CONSISTENCY
References:	CLtL p. 68-69, 143, 321
		RAM's "Compiler Cleanup Proposal #3"
Category:	CLARIFICATION
Edit History:   V1, 2 Sep 1988, Sandra Loosemore (initial draft)
		V2, 9 Sep 1988, Sandra Loosemore (incorporate suggestions)
		V3, 26 Oct 1988, Sandra Loosemore (add suggestion from Benson)


Problem Description:

CLtL does not clearly specify what aspects of the compiletime
environment the compiler (or other preprocessor) may "wire in" to code
being compiled.


Proposal COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY:

Common Lisp deliberately leaves unspecified the time at which certain
transformations, such as macro expansion, are performed within a
program.  While some implementations perform such transformations
concurrently with evaluation, it is also legitimate to perform
transformations during a preprocessing phase.  For example, an
implementation might choose to apply transformations at "function
promotion time" (i.e., transformations are applied once during
evaluation of a surrounding FUNCTION special form), or to completely
transform each top-level form and all of its subforms before
performing any evaluation.  User programs cannot portably depend upon
either the time of such transformations, or the number of times the
transformations are applied.

In all cases, however, compiling a program (with COMPILE or
COMPILE-FILE) provides a mechanism for forcing these transformations
to be applied and a guarantee that, once compiled, no further
transformations will be applied to that program.

In the discussion that follows, the term "compiler" is to be understood
to include other preprocessors as well.  Likewise, the "compiletime
environment" refers to the environment in which program transformations
occur, while "runtime" refers to the time the program is executed.


(1) The following information *must* be present in the compiletime
environment for the preprocessor to apply the correct transformations.
This information need not also be present in the runtime environment.

    (a) Macro definitions must be available in the compiletime environment.
	The compiler may assume that forms that are lists beginning with
	a symbol that does not name a macro or special form is a function
	call.  (This implies that SETF methods must also be available at
	compiletime.)

    (b) Special variables must be declared as such before they are bound.
	The compiler must treat any undeclared variable binding as a
	lexical binding.


(2) The compiler *may* "wire in" the following kinds of information
into the code it produces, if the information is present in the
compiletime environment.  However, since implementations are not
required to do this, user code must ensure that the information is
also defined consistently in the runtime environment.  Except as
noted, the behavior of user programs is unspecified in situations
where the information is defined differently at runtime than at
compiletime, since the user cannot depend upon which will take
precedence in a particular implementation.  In all cases, the absence
of the information at compiletime is not an error, but its presence
may enable the compiler to do a better job.

    (a) The compiler may assume that functions that are defined and
	declared INLINE in the compiletime environment will retain the
	same definitions at runtime.

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

    (c) 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 runtime.

    (d) The compiler may assume that the signature (or "contract") of
	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.

    (e) The compile may assume that the signature (or "contract") of
	functions with FTYPE information available will not change.  (See
	issue FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS.)

    (f) The compiler may "wire in" the values of symbolic constants
	that have been defined with DEFCONSTANT in the compiletime
	environment.

    (g) Types that are defined with DEFTYPE or DEFSTRUCT can be assumed to
	retain the same definition in the runtime environment as in the
	compiletime environment.  (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.)

    (h) The compiler may assume that a class name defined by DEFCLASS
	that is present in the compiletime environment will also be a
	class name at runtime, and that class will be an instance of the
	same metaclass.  There may be additional conformance requirements
	imposed by the metaclass, but there are none for STANDARD-CLASS.

    (i) The compiler may assume that if type declarations are present
	in the compiletime environment, the corresponding variables and 
	functions present in the runtime environment will actually be of
	those types; otherwise, the behavior of the program is undefined.


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

    (a) The compiler may not assume that functions that are defined
	in the compiletime environment will retain the either the
	same definition or the same signature at runtime, except
	in situations (2a) through (2e) above.  It is, however,
	reasonable for the compiler to emit warning messages about
	calls to functions that are defined at compiletime, but where
	the wrong number or type of arguments are supplied.

    (b) The compiler may not signal an error if it sees a call to a
	function that is not defined at compiletime, since that function
	may be provided at runtime.  Again, it is permissible to emit
	a warning in these situations.

	

Rationale:

This proposal generally reflects current practice.


Current Practice:

I know of no compiler that does not implement the provisions of item (1).

For item (2), most compilers (including Lucid) optimize self-recursive
calls by default.  Most compilers also opencode data structure
accessors (such as CAR) at some level of optimization, and some code
much more complicated built-in functions inline as well.  VaxLisp, for
example, normally compiles MEMBER inline.  The Lucid compiler makes
use of type declarations to perform generic-to-specific
transformations on many arithmetic and sequence functions, which is
also a form of inlining.  KCL performs block compilation by default,
and Lucid does so under certain conditions.


Cost to implementors:

Unknown, but probably minor.


Cost to users:

Since most implementations appear to be largely in conformance with the
proposal, users should notice little difference.


Benefits:

The presence of a definite specification of what may happen when will
help users structure their programs so they will compile correctly in
all Common Lisp implementations.


Discussion:

Most of the discussion on this issue has been centered on the
terminology describing error situations for item (2).  In most cases
where there is an inconsistency between compile-time and run-time, the
results will be unpredictable but harmless.  The major exception is
violation of type declarations, which is a "crash-and-burn" error in
many implementations.

There has also been some concern raised that item (3) would prohibit
such things as a cross-compiler that produces standalone programs in
an environment that disallows redefinition of functions.  The intent
of this proposal is not to prohibit a compiler from having a magic
switch that imposes additional restrictions on the programs it
compiles, but such a compiler would not be a compiler for Common Lisp.
-------

∂26-Oct-88  1212	CL-Compiler-mailer 	issue COMPILER-LET-CONFUSION  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 26 Oct 88  12:12:18 PDT
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA09180; Wed, 26 Oct 88 13:12:04 MDT
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA29493; Wed, 26 Oct 88 13:12:00 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810261912.AA29493@defun.utah.edu>
Date: Wed, 26 Oct 88 13:11:59 MDT
Subject: issue COMPILER-LET-CONFUSION
To: cl-compiler@sail.stanford.edu

When we last left this issue, it still had four proposals.  Unless
somebody complains loudly, I'm going to remove all but the ELIMINATE
option, and add a mention to the discussion that voting against
ELIMINATE is the same as voting for CLARIFY-STATUS-QUO.  My perception is
that neither of the other two alternatives (REQUIRE-PREPASS or REDEFINE)
have many supporters.

-Sandra
-------

∂26-Oct-88  2011	CL-Cleanup-mailer 	issue DEFPACKAGE
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Oct 88  20:11:42 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 482749; Wed 26-Oct-88 23:11:16 EDT
Date: Wed, 26 Oct 88 23:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DEFPACKAGE
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>, peck@Sun.COM, Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu, cl-compiler@sail.stanford.edu
In-Reply-To: <8810132034.AA19839@defun.utah.edu>,
             <8810180019.AA06479@denali.sun.com>,
             <8810220152.AA12710@bhopal>,
             <8810220210.AA12781@bhopal>
Message-ID: <19881027031103.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

Comments on comments received.  I'll keep it as brief as I can.

    Date: Thu, 13 Oct 88 14:34:04 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    A question was raised at the meeting about having macros signalling
    errors during expansion at compile time.  Macro expansion time is the
    obvious time for signalling a syntax error for an unrecognized option
    and I think that should be made clear in the standard.

Sure, but I hope we don't have to address this separately for each and
every macro.

    I presume it's the intention of the proposal that the expansion of
    DEFPACKAGE should be wrapped with an (EVAL-WHEN (EVAL COMPILE LOAD)

I don't know about mandating that specific implementation, especially
when the definition of EVAL-WHEN is in flux, but certainly the idea is
that writing a DEFPACKAGE form at top level is sufficient to inform
the compiler of what you mean.  It's usually good practice to put
DEFPACKAGE forms into separate files, in which case the issue does
not arise, but I don't think we need to forbid putting a DEFPACKAGE
form in the same file as a program.

    Finally, what is the motivation for not having DEFPACKAGE setq *PACKAGE*?

What is the motivation for not having DEFUN call the function?
That's not a joke, my point is that the two operations of defining
a package and switching the current package have little to do with
each other and are rarely done together.

    Date: Mon, 17 Oct 88 17:19:14 -0700
    From: peck@Sun.COM

    I suggest that the :INTERNAL option be renamed :INTERN.

Right, that was a mistake on my part.  :INTERN is right.

     Please verify for me that if there is no :USE clause, whether
    the created package will use....

The default for DEFPACKAGE is the same as for MAKE-PACKAGE, and is
the subject of a separate cleanup issue.

    Clarify that the order of the clauses in the source code has no effect.

Right, good point.

    Date: Fri, 21 Oct 88 18:52:57 PDT
    From: Jon L White <jonl@lucid.com>

    re: I presume it's the intention of the proposal that the expansion of
	DEFPACKAGE should be wrapped with an (EVAL-WHEN (EVAL COMPILE LOAD)

    This should be covered the "normal" way, like any other defining form

Right.

    Date: Fri, 21 Oct 88 19:10:42 PDT
    From: Jon L White <jonl@lucid.com>

    I'd prefere to see the :EXPORT option renamed to
    be :EXTERNAL rather than introduce a gratuitously new keyword [note
    that symbols present in a package must be either :INTERNAL or :EXTERNAL.]

I strongly object to removing the analogy between the names of these
options and the already existing package functions.  :INTERNAL instead
of :INTERN was a typographical error on my part.

    re:                                            . . . Like all USE'ing
	this should be deferred until after the shadowing is done, no?

    Ooops, I guess you're right.  Shadowing that creates new symbols isn't
    important; but shadowing that in effect "blocks" the inheritance of two 
    different symbols with the same name must be done before the "using".

That's correct.  It's not hard to figure out in what order the options
should be processed, but part of the idea of having DEFPACKAGE is that
only implementors have to figure that out.

    I guess the more clear way to say what was intended here is that the
    evaluation of a DEFPACKAGE form does not change the value of *package*.

Right.

∂26-Oct-88  2141	CL-Compiler-mailer 	Re: issue DEFPACKAGE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 26 Oct 88  21:39:40 PDT
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA00225; Wed, 26 Oct 88 22:30:28 MDT
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA29800; Wed, 26 Oct 88 22:28:19 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810270428.AA29800@defun.utah.edu>
Date: Wed, 26 Oct 88 22:28:17 MDT
Subject: Re: issue DEFPACKAGE
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs>, peck@Sun.COM,
        Jon L White <jonl@lucid.com>, cl-cleanup@sail.stanford.edu,
        cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 26 Oct 88 23:11 EDT

> Date: Wed, 26 Oct 88 23:11 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
>     Finally, what is the motivation for not having DEFPACKAGE setq *PACKAGE*?
> 
> What is the motivation for not having DEFUN call the function?
> That's not a joke, my point is that the two operations of defining
> a package and switching the current package have little to do with
> each other and are rarely done together.

My original impression of what this proposal was for was to introduce
a somewhat cleaner mechanism to do what one currently uses the Seven
Extremely Randoms for.  IN-PACKAGE is one of those.  If one follows
the style set forth in CLtL, then defining a package and switching the
current package -are- usually done together.  I don't have any problem
with DEFPACKAGE not setq'ing *PACKAGE*, I just think the proposal
should make it more clear why it doesn't, and emphasize that
DEFPACKAGE really isn't supposed to be used the same way as the Seven
Extremely Randoms.  I was confused and maybe other people are too.

-Sandra
-------

∂27-Oct-88  0954	CL-Cleanup-mailer 	Re: issue DEFPACKAGE 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Oct 88  09:53:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 482989; Thu 27-Oct-88 12:53:29 EDT
Date: Thu, 27 Oct 88 12:53 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue DEFPACKAGE
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: peck@Sun.COM, Jon L White <jonl@lucid.com>, cl-cleanup@sail.stanford.edu,
    cl-compiler@sail.stanford.edu
In-Reply-To: <8810270428.AA29800@defun.utah.edu>
Message-ID: <19881027165315.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 26 Oct 88 22:28:17 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    > Date: Wed, 26 Oct 88 23:11 EDT
    > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    > 
    >     Finally, what is the motivation for not having DEFPACKAGE setq *PACKAGE*?
    > 
    > What is the motivation for not having DEFUN call the function?
    > That's not a joke, my point is that the two operations of defining
    > a package and switching the current package have little to do with
    > each other and are rarely done together.

    My original impression of what this proposal was for was to introduce
    a somewhat cleaner mechanism to do what one currently uses the Seven
    Extremely Randoms for.  IN-PACKAGE is one of those.  If one follows
    the style set forth in CLtL, then defining a package and switching the
    current package -are- usually done together.  

I see.  But the thing is, part of the reason for introducing DEFPACKAGE,
and for removing the ability of IN-PACKAGE to create packages, is that
the style set forth in CLtL is broken and doesn't work.  I guess I've been
saying that for so long now (about five years) that I've forgotten it isn't
intuitively evident.

						  I don't have any problem
    with DEFPACKAGE not setq'ing *PACKAGE*, I just think the proposal
    should make it more clear why it doesn't, and emphasize that
    DEFPACKAGE really isn't supposed to be used the same way as the Seven
    Extremely Randoms.  I was confused and maybe other people are too.

    -Sandra
    -------

∂27-Oct-88  1349	CL-Compiler-mailer 	Issue ALLOW-LOCAL-INLINE (V2) 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 27 Oct 88  13:49:31 PDT
Received: by ti.com id AA19203; Thu, 27 Oct 88 15:49:51 CDT
Received: from Kelvin by tilde id AA17073; Thu, 27 Oct 88 15:34:29 CDT
Message-Id: <2802976433-717947@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 27 Oct 88  15:33:53 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Compiler@SAIL.Stanford.edu
Subject: Issue ALLOW-LOCAL-INLINE (V2)

In accordance with Pitman's suggestion of 9/24, I withdraw proposal
ALLOW-LOCAL-INLINE:PROCLAIM-ALLOW-INLINE and offer the following in
its place.


Issue:		ALLOW-LOCAL-INLINE
References:	CLtL p. 156, 159;
		Issue PROCLAIM-INLINE-WHERE
Category:	CLARIFICATION
Edit History:   21 Sept. 88 V1 by David Gray
                27 Oct.  88 V2 by David Gray - new proposal
Status:		For preliminary discussion 
 
Problem Description:

  The proposal PROCLAIM-INLINE-WHERE:BEFORE (which was accepted by X3J13
  on 10/12/88) clarifies the use of INLINE proclamations, but there
  remains a similar problem with the use of a local (DECLARE (INLINE
  ...)): how can the compiler expand the function inline if it didn't
  know that the necessary information should have been saved when the
  function was compiled?
 
Proposal ALLOW-LOCAL-INLINE:INLINE-NOTINLINE

  Clarify that if a local (DECLARE (INLINE foo)) is to be used to expand
  a function inline in only certain places, then the function should be
  defined like this:
    
   (PROCLAIM '(INLINE foo))
   (DEFUN foo ...)
   (PROCLAIM '(NOTINLINE foo))

  The INLINE proclamation preceding the DEFUN ensures that compiler will
  save the information necessary for inline expansion, and the NOTINLINE
  proclamation following the DEFUN prevents it from being expanded
  inline everywhere.  

  Note that while implementations are never required to perform inline
  expansion of function calls, many implementations that do support
  inline expansion will not be able to respond to local INLINE requests
  if this technique is not followed.

 Rationale:

  Local INLINE declarations are of little use without some way of
  alerting the compiler to the possibility of inline expansion before
  the function is compiled.  This seems the simplest solution since it
  just clarifies existing practice instead of adding a new feature to
  the language.

  A compiler could use some heuristic to save the definitions of functions
  that are short enough to look like good candidates for inline expansion,
  but then the user is never sure what to expect.  It is possible that a
  compiler could simply save all definitions (assuming availability
  of adequate storage space) but we shouldn't require that.

 Test Cases/Examples: 

  Given the following input to COMPILE-FILE, does F1 get expanded inline
  in F2, and does F3 get expanded inline in F4?

    (defun f1 (a) (+ a 100))
    (defun f2 (b) (declare (inline f1)) (f1 b))
    (proclaim '(inline f3))
    (defun f3 (a) (+ a 100))
    (proclaim '(notinline f3))
    (defun f4 (b) (declare (inline f3)) (f3 b))
 
 Current Practice:
 
  In the example above, using Symbolics, Lucid, or Explorer, F1 is not
  expanded in F2, but F3 is expanded in F4.

 Cost to implementors:
 
  None, since this is a clarification in accordance with current
  practice.

 Cost to users:
  
  None.

 Benefits:

  Users will be able to use (DECLARE (INLINE ...)) with greater assurance
  that it will really do something.

 Costs of Non-Adoption: 

  Users will not know how to reliably request inline expansion on a
  local basis.  This technique is not obvious, and even the need
  for it likely to be apparent only to people who understand something
  about how the compiler does inline expansion.

 Discussion:

  Version 1 of this issue proposed an addition to the language:
    (PROCLAIM '(ALLOW-INLINE foo))
  This was met with a lack of enthusiasm since it was pointed out that
  the same effect could be obtained by using a combination of INLINE and
  NOTINLINE.

∂27-Oct-88  1531	CL-Compiler-mailer 	Re: Issue ALLOW-LOCAL-INLINE (V2)  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 27 Oct 88  15:31:32 PDT
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA08085; Thu, 27 Oct 88 16:31:10 MDT
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA00396; Thu, 27 Oct 88 16:31:02 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810272231.AA00396@defun.utah.edu>
Date: Thu, 27 Oct 88 16:31:01 MDT
Subject: Re: Issue ALLOW-LOCAL-INLINE (V2)
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: CL-Compiler@SAIL.Stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Thu, 27 Oct 88  15:33:53 CDT

I like the general direction here, but I have a minor gripe about the
writeup.  Namely, the problem description section doesn't really seem
to be describing the problem the proposal addresses.  As I understand it,
the problem is really that INLINE does two things:

    (1) It tells the compiler to do extra things when it sees the
        function -definition-, to make it possible to code the function
	inline.

    (2) It tells the compiler to code -calls- to the function inline.

and you want to clarify how to get the first behavior without the second.

-Sandra
-------

∂27-Oct-88  1719	CL-Compiler-mailer 	Issue DEFCONSTANT-NOT-WIRED (V2)   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 27 Oct 88  17:19:31 PDT
Received: by ti.com id AA20542; Thu, 27 Oct 88 19:19:50 CDT
Received: from Kelvin by tilde id AA21267; Thu, 27 Oct 88 19:15:50 CDT
Message-Id: <2802989729-1516801@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 27 Oct 88  19:15:29 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Compiler@SAIL.Stanford.edu
Subject: Issue DEFCONSTANT-NOT-WIRED (V2)

Since no one really liked the proposal DEFCONSTANT-NOT-WIRED:NEW-MACRO,
here is a different approach to the problem that was inspired by
comments from Kent Pitman and Jon L White.


Issue:         DEFCONSTANT-NOT-WIRED

References:    CLtL pages 68-69
               
Related issues: Proposals DEFCONSTANT-VALUE:COMPILE-TIME and
               COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY

Category:      ADDITION

Edit history:  9 Oct 1988, V1 by David Gray
              27 Oct 1988, V2 by David Gray (new proposal)

Problem description:

  As discussed in issue DEFCONSTANT-VALUE, there are two possible views
  of what the purpose of DEFCONSTANT is.  Proposal
  DEFCONSTANT-VALUE:COMPILE-TIME resolves the controversy in favor of
  maximizing opportunities for the compiler to substitute the value for
  references to the constant.

  There may, however, still be cases where one would like to have the
  functionality of prohibiting run-time alteration of a value (like
  DEFCONSTANT), but have the value computed at load time and not be
  wired in (like DEFPARAMETER).  

  Some people think that this is what DEFPARAMETER should do, but that
  would be an incompatible change for other users who have a different
  understanding of the meaning of DEFPARAMETER.

Proposal DEFCONSTANT-NOT-WIRED:NEW-DECLARATION

  Add a new declaration to the language:

    (CONSTANT {varname}+)

  This can be used in either PROCLAIM or DECLARE.  It specifies that the
  variables named are to be treated as constants after their initial
  value is established.  

  For lexical variables, this means that the variable is not permitted
  as the destination of a SETQ.  (Knowing in advance that the value
  won't be altered by a SETQ makes it easier for compilers to perform
  certain optimizations.)  Implementations are not required to signal an
  error if they don't depend on this information.

  For special variables, (PROCLAIM '(CONSTANT varname)) means that an
  error will be signalled if the variable is used as the destination of
  a SETQ or an attempt is made to re-bind it.  [Editorial note: this
  error behavior is intended to be the same as for DEFCONSTANT, so may
  need to be re-worded accordingly.]  However, the compiler is not
  authorized to "wire in" the value like it does with DEFCONSTANT.  This
  attribute of the variable is canceled by a DEFVAR or DEFPARAMETER for
  the same name, so the PROCLAIM should be executed after the DEFVAR or
  DEFPARAMETER that initializes it.  An error should be signalled if the
  name has not been previously declared to be a special variable.  This
  proclamation has no effect on a variable declared by DEFCONSTANT
  (since it is a subset of what DEFCONSTANT already does).

  For a binding of a special variable, an associated declaration
  (DECLARE (CONSTANT varname)) declares the programmer's intent that
  there be no alteration of the value within the dynamic scope of the
  binding.  Since it is not practical to detect alteration in compiled
  code that is not within the lexical scope of the declaration, this
  information is not of much use to a compiler, and signalling of an
  error is optional.

  [Editorial note: the association of variable names with variables and
  the scope of the declaration is intended to be consistent with the
  resolution of issue DECLARE-TYPE-FREE, so the wording may need to be
  clarified accordingly.]

 Examples:

  (DEFPARAMETER MEMORY-SIZE (DETERMINE-MEMORY-SIZE))
  (PROCLAIM '(CONSTANT MEMORY-SIZE))

  computes at load-time the value of parameter MEMORY-SIZE, which can
  then be used in subsequent initialization to control the allocation of
  data structures for an application.  Once these structures are
  created, changing this parameter would make no sense and might even
  break the program.  A DEFCONSTANT is not appropriate because the value
  needs to be computed at load time and because the value must not be
  wired in to any files compiled later or else those object files could
  not be used on another machine with a different memory size.

  (LET ((SHORT-PI (COERCE PI 'SHORT-FLOAT)))
    (DECLARE (CONSTANT SHORT-PI))
    ...)

  Here the declaration assists a human reader of the program in
  recognizing how SHORT-PI is being used, and encourages the compiler to
  substitute the value where it is used.  (This optimization could be
  done without the declaration, but is complicated by the possibility of
  alteration within loops or closures.)

 Rationale:

  This provides the functionality desired by those who are reluctant to
  see DEFCONSTANT defined to compute the value at compile time.

  This seems to be a cleaner approach than adding an additional defining
  macro, and has additional usefulness with lexical variables.

  For the purposes that motivated this proposal, it would be simpler to
  just support (PROCLAIM '(CONSTANT ...)), but allowing local CONSTANT
  declarations seems like such a natural extension that it would seem an
  artificial restriction to not permit it.

  The error signalling behavior has been specified in such a way as to
  minimize the cost to implementors and to avoid slowing down
  interpreters with additional bookkeeping.

 Current practice:
  
  No implementation of this proposal is known.

  The Explorer has a capability equivalent to (PROCLAIM '(CONSTANT ...))
  which is used internally for various system parameters, since changing
  them could crash the system, but the value should not be wired in to
  object files in order to maintain object compatibility between
  software releases.

 Cost to Implementors:

  The minimum requirements are to permit the CONSTANT declaration
  (trivial), and to prevent alteration of special variables that have
  been PROCLAIMed constant, which should be easy since the mechanism
  should already exist for DEFCONSTANTs.

  More work would be needed for a compiler to record lexical constant
  declarations and report errors for violations.  This is not trivial,
  but not difficult either.

 Cost to Users:
  
  One more little feature to learn.  Some user code may need to be
  modified as a result of the addition of the symbol CONSTANT to the
  LISP package.

 Cost of non-adoption:

  Continued confusion from the desire to use DEFCONSTANT for situations
  that it isn't quite right for, or from expecting DEFPARAMETER to do
  more than it does.

 Performance impact:  

  Could help run-time speed by making it easier for compilers to support
  value propagation.

 Benefits:

  Provides a more complete set of options to the user.

 Esthetics:
 
  Complicates the language by adding one more declaration, but having
  this as a separate feature facilitates giving a clear and simple
  definition to DEFCONSTANT and avoids a battle over what DEFPARAMETER
  means.

  This seems like an elegant solution -- simple syntax with an obvious
  meaning.

Discussion:

  Version 1 of this issue proposed adding a new macro called 
  DEFPARAMETER-UNALTERABLE, but no one seemed to like it.  (It would
  have been equivalent to DEFPARAMETER followed by PROCLAIM CONSTANT.)

  It may be desirable to have stricter requirements for signalling
  errors if this idea is popular enough for implementors to accept the
  cost.

∂27-Oct-88  2230	CL-Compiler-mailer 	Issue: IN-SYNTAX (Version 1)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Oct 88  22:30:29 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01747g; Thu, 27 Oct 88 22:29:53 PDT
Received: by bhopal id AA13376g; Thu, 27 Oct 88 22:28:24 PDT
Date: Thu, 27 Oct 88 22:28:24 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810280528.AA13376@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU, CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Fri, 21 Oct 88 17:19 EDT <881021171949.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: IN-SYNTAX (Version 1)

re: I noticed too late that you had added CL-Compiler.  . . . 

Because of the extensive implications for the CL-Compiler issue 
EVAL-WHEN-NON-TOP-LEVEL, and because of the (hasty) acceptance of
re-binding *package* to the "current" value by COMPILE-FILE.

I can appreciate your concern about double cc'ing, and will take
the issue only to CL-Cleanup now.  Anyone on CL-Compiler who isn't
also on CL-CLeanup, but would like to hear about the issue of
default bindings for *package*/*readtable*/*read-base* during
LOAD or COMPILE-FILE, please contact me privately, and I will add 
you individually to the cc list.


-- JonL --

∂28-Oct-88  0841	CL-Compiler-mailer 	Re: Issue ALLOW-LOCAL-INLINE (V2)  
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 28 Oct 88  08:41:30 PDT
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU; 28 Oct 88 11:40:21 EDT
To: David N Gray <Gray@DSG.csc.ti.com>
cc: CL-Compiler@SAIL.Stanford.edu
Subject: Re: Issue ALLOW-LOCAL-INLINE (V2) 
In-reply-to: Your message of Thu, 27 Oct 88 15:33:53 -0500.
             <2802976433-717947@Kelvin> 
Date: Fri, 28 Oct 88 11:39:42 EDT
From: Rob.MacLachlan@WB1.CS.CMU.EDU


One problem with the inline-notinline idiom is that NOTINLINE has evolved
in the direction of a declaration that tells the compiler "assume nothing
about this function".

NOTINLINE would certainly suppress block-compiled call, and would probably
suppress compiler warnings about the argument signature used in calls, etc.
A programmer who just wants to note the inline expansion and not use it
right away shouldn't be forced to suppress standard compilation on the
calls that aren't inline-expanded.

In fact, I think that there is a reasonable argument that NOTINLINE should
cause the compiler to *forget* any recorded inline expansion.  Assuming
that a previously seen definition is in fact the correct definition seems
to be making a pretty strong assumption about that function.

It is because of of this continuum of levels of "assumption about a
function" that I proposed the INTEGRATION-LEVEL declaration to subsume
INLINE and NOTINLINE.  The idea was that NOTINLINE = 0 and INLINE = 3, and
any value > 0 allowed the compiler to assume that any seen definition is
the true definition, but what use it made of this information was up to it.
For example,
    (proclaim '(integration-level 2 foo))

could cause the expansion to be recorded without causing inline expansion
to be done.

To go along with this, there was the notion of the default integration
level, which was initially 1 and could be modified by a proclamation.

This isn't exactly what I proposed before, and I think that this proposal
might also benfit from modification.  In particular, it isn't clear that it
is really appropriate or useful to use integers to represent the
integration level (although it does make sense to have an ordering on the
values).  An alternative would be to use some small set of keywords such as
:NEVER, :DEFAULT, :RECORD and :INLINE.

  Rob

∂28-Oct-88  1113	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED (V2)    
Received: from PECAN.CS.ROCHESTER.EDU by SAIL.Stanford.EDU with TCP; 28 Oct 88  11:12:57 PDT
Received: from DOUGHNUT.CS.ROCHESTER.EDU by PECAN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 4707; Fri 28-Oct-88 14:04:34 EDT
Date: Fri, 28 Oct 88 14:04 EDT
From: Brad Miller <miller@CS.ROCHESTER.EDU>
Subject: Re: Issue DEFCONSTANT-NOT-WIRED (V2)
To: David N Gray <Gray@DSG.csc.ti.com>
cc: CL-Compiler@SAIL.STANFORD.EDU
In-Reply-To: <2802989729-1516801@Kelvin>
Message-ID: <19881028180427.8.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Sender: miller@CS.ROCHESTER.EDU
Reply-To: miller@CS.ROCHESTER.EDU
Organization: University of Rochester, Department of Computer Science
Postal-address: 610 CS Building, Comp Sci Dept., U. Rochester, Rochester NY 14627
Phone: 716-275-1118

    Date: Thu, 27 Oct 88  19:15:29 CDT
    From: David N Gray <Gray@DSG.csc.ti.com>

    Issue:         DEFCONSTANT-NOT-WIRED

    References:    CLtL pages 68-69
               
    Related issues: Proposals DEFCONSTANT-VALUE:COMPILE-TIME and
		   COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY

Does this mean I can do:

(defvar *mumble*)
(defun foo ()
	(setq *mumble* :bar)
	(proclaim '(constant *mumble*)))
(defun bar ()
	(setq *mumble* :foo))

then
(foo)
:bar
(bar)
ERROR...

vs.
(bar)
:foo
(foo)
:bar
(foo)
ERROR...


??? If so, I don't buy it; the compiler shouldn't have to hook setq.

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

∂28-Oct-88  1122	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED (V2)    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 28 Oct 88  11:22:49 PDT
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA06711; Fri, 28 Oct 88 12:22:37 MDT
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA00942; Fri, 28 Oct 88 12:22:26 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810281822.AA00942@defun.utah.edu>
Date: Fri, 28 Oct 88 12:22:24 MDT
Subject: Re: Issue DEFCONSTANT-NOT-WIRED (V2)
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: CL-Compiler@SAIL.Stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Thu, 27 Oct 88  19:15:29 CDT

> Date: Thu, 27 Oct 88  19:15:29 CDT
> From: David N Gray <Gray@DSG.csc.ti.com>
> 
> Proposal DEFCONSTANT-NOT-WIRED:NEW-DECLARATION
> 
>   Add a new declaration to the language:
> 
>     (CONSTANT {varname}+)
>

I have two problems with this proposal:

(1) The behavior for all the cases of special and lexical variables seems
    too complicated and confusing, and I'm not even sure that it covers
    all the cases.  For example, does it make sense to have a "free"
    CONSTANT declaration?

(2) I don't think we should require SETQ'ing the variable to signal an error
    under any circumstances, since DEFCONSTANT doesn't require it.

A possible solution for the first problem is to make the CONSTANT
declaration force a lexical binding.  This is very similar to
something that Dalton and I were suggesting a couple of weeks ago to
cl-cleanup on issue PROCLAIM-LEXICAL.  To summarize, the idea was to
introduce a declaration called LEXICAL or something like that, that
does the same thing about rebinding as DEFCONSTANT does.  (Some people
seem to think that DEFCONSTANT is supposed to proclaim the variable
SPECIAL, but my reading of p. 69 of CLtL is that it is exactly the
opposite: DEFCONSTANT disallows special binding of the variable but
-does- allow it to be rebound lexically.)

I'd suggest making the CONSTANT declaration work the same way, except
also have it include DEFCONSTANT's prohibition against SETQ'ing.  It
should also parallel the SPECIAL declaration's scoping behavior.

That is, for a CONSTANT proclamation:

    References to the variable are treated as references to the
    symbol's global value.

    It is an error if there are any special bindings of the variable.
    Any further binding of that special variable is an error.

    It is an error to SETQ the symbol's global value.

    A compiler may also choose to issue warnings about bindings of the
    lexical variable of the same name.


For a "free" CONSTANT declaration:

    References to the variable are treated as lexical references.

    It is an error to SETQ the named lexical variable within the scope
    of the declaration.


For a "bound" CONSTANT declaration:

    The CONSTANT declaration forces the variable to be bound lexically.
    (The interpreter would not be able to ignore CONSTANT declarations,
    for exactly the same reasons that it cannot ignore SPECIAL
    declarations.)

    It is an error to SETQ the named lexical variable within the scope
    of the declaration.

    A compiler may also choose to issue warnings about bindings of the
    lexical or special variable of the same name, within the lexical
    scope of the declaration.

How does this sound as an alternative?

-Sandra

-------

∂31-Oct-88  0854	CL-Compiler-mailer 	issue COMPILER-LET-CONFUSION, V3   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 31 Oct 88  08:54:24 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA22783; Mon, 31 Oct 88 09:54:05 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA02513; Mon, 31 Oct 88 09:54:00 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810311654.AA02513@defun.utah.edu>
Date: Mon, 31 Oct 88 09:53:57 MST
Subject: issue COMPILER-LET-CONFUSION, V3
To: cl-compiler@sail.stanford.edu

Here is the latest version.  As I said I would do earlier, all but
proposal ELIMINATE have been removed.  This is another issue I would
like to put on a mail ballot in December, so please say something soon
if you have problems with the writeup. 

-Sandra



Issue:		COMPILER-LET-CONFUSION
References:	CLtL p. 112
Category:	CHANGE
Edit History:   V1, 27 Sep 1988, Sandra Loosemore (initial version)
                V2, 04 Oct 1988, Sandra Loosemore (add another example)
		V3, 31 Oct 1988, Sandra Loosemore (only proposal ELIMINATE)


Problem Description:

The description of the COMPILER-LET special form in CLtL is confusing
to many people.  There are no examples provided to make it clear how it
is supposed to be used.

The description of how COMPILER-LET works in the interpreter only
makes sense for implementations which perform macroexpansion in
parallel with evaluation.  In an implementation which performs macro
expansion in a prepass and follows CLtL literally in making
COMPILER-LET behave "exactly like LET with all the variable bindings
implicitly declared SPECIAL", it would not work at all for its stated
purpose, "communication among complicated macros".

Subtle bugs can be introduced because of the different handling of the
variable bindings in the interpreter and the compiler.  In compiled
code, the bindings are only lexically visible during the expansion of
macros at compile time, while in interpreted code the bindings have
dynamic scope and may also be seen during ordinary evaluation if
evaluation and macroexpansion happen concurrently.

Further compatibility problems can result from the value forms being
evaluated in a null lexical environment in the compiler and the
ordinary lexical environment in the interpreter.



Proposal COMPILER-LET-CONFUSION:ELIMINATE:

  Remove COMPILER-LET from the language.
  
  
  Rationale:
  
  Some people think that COMPILER-LET is ugly.  Removing it from the
  language is a much simpler solution than an elaborate proposal to
  assign it consistent semantics in the interpreter and compiler.
  
  
  Current Practice:
  
  COMPILER-LET is rarely used.  
  
  
  Cost to implementors:
  
  Minimal.  Implementations could continue to support COMPILER-LET as
  an extension.
  
  
  Cost to users:
  
  People who use COMPILER-LET would have to rewrite their programs to use
  some other construct.  Most uses of COMPILER-LET for communication between
  macros can be handled using MACROLET instead.
  
  I have been able to do this quite easily for all of the examples which I
  have seen so far.  For example:
  
    (defvar *local-type-declarations* '())
     
    (defmacro local-type-declare (declarations &body forms)
      `(compiler-let ((*local-type-declarations* 
                        (append ',declarations *local-type-declarations*)))
         ,@forms))
     
    (defmacro typed-var (var)
       (let ((type (assoc var *local-type-declarations*)))
         (if type `(the ,(cadr type) ,var) var)))
     
    (defun f (x y)
      (local-type-declare ((x fixnum) (y float))
        (+ (typed-var x) (typed-var y))))
     
    
  can be rewritten as:
  
    (defmacro local-type-declare (declarations &body forms)
        (local-type-declare-aux declarations forms))
    
    (eval-when (eval compile load)
        (defun local-type-declare-aux (declarations forms)
    	`(macrolet ((typed-var (var)
    			(let ((type  (assoc var ',declarations)))
    			    (if type `(the ,(cadr type) ,var) var)))
    		    (local-type-declare (new-declarations &body new-forms)
    			(local-type-declare-aux
    			    (append new-declarations ',declarations)
    			    new-forms)))
    	     ,@forms)))
    
    
  The MACROLET versions are usually somewhat more complicated than the
  COMPILER-LET versions, but not substantially so unless there are a large
  number of macros involved.

  Another approach for converting old code is to define a
  COMPILER-LET-like macro to explicitly make the special variable
  bindings available during the expansion of a specified set of macros.
  The following macro FAKE-COMPILER-LET makes the special variable
  bindings visible during the expansion of the named macros, and during
  the evaluation of nested FAKE-COMPILER-LETs.

    ;;; Imitation COMPILER-LET.  Second argument is a list of macros which
    ;;;    are to see the special bindings; these must have been defined using
    ;;;    DEFMACRO, not MACROLET (because expansion takes place in null
    ;;;    lexical environment).
    
    (defmacro fake-compiler-let (binding-forms macros &body body)
        (expand-fake-compiler-let binding-forms macros body))
    
    (eval-when (eval compile load)
        (defun expand-fake-compiler-let (binding-forms macros body)
            (let* ((vars    (mapcar #'(lambda (b)
                                          (if (consp b) (car b) b))
                                    binding-forms))
                   (vals    (mapcar #'(lambda (b)
                                          (if (consp b) (eval (cadr b)) nil))
                                    binding-forms))
                   (binders (mapcar #'(lambda (var val)
                                          `(,var ',val))
                                    vars vals))
                   (defs    (mapcar #'(lambda (m)
                                          `(,m (&whole w)
                                               (let ,binders
                                                   (declare (special ,@vars))
                                                   (macroexpand-1 w))))
                                    macros)))
                `(macrolet ((fake-compiler-let (binding-forms macros
						    &body body)
                                (let ,binders
                                    (declare (special ,@vars))
                                    (expand-fake-compiler-let
                                        binding-forms macros body)))
                            ,@defs)
                     ,@body)))
        )
    
    
    ;;; Example to illustrate nesting behavior
    
    (eval-when (eval compile)
        (defvar *depth* 0)
        (defmacro current-depth ()
            *depth*)
        )
    
    (fake-compiler-let ((*depth* (1+ *depth*)))
                       (current-depth)
        (format t "First value = ~s~%" (current-depth))
        (fake-compiler-let ((*depth* (1+ *depth*)))
                           (current-depth)
            (format t "Second value = ~s~%" (current-depth))))
  

  Benefits:
  
  Having one less special form would simplify the language.  An area of
  incompatibility between compiled and interpreted code would be
  eliminated.



Discussion:

Three other proposals on this issue were also considered.  One of
these, CLARIFY-STATUS-QUO, becomes the default if proposal ELIMINATE
is rejected.  Essentially, it would clarify that processing of
COMPILER-LET by the interpreter happens at the same time as
macroexpansion; the value forms are evaluated sequentially in a null
lexical environment, bound to the special variables, and that these
bindings are available during the expansion of macro calls in the
body.  Some mention should also be made in the standard of the
compatibility problems between compiled and interpreted code.

The other two proposals were REQUIRE-PREPASS (to require all intepreters
to perform macroexpansion and processing of COMPILER-LETs in a code-walking
prepass) and REDEFINE (to assign somewhat different semantics to
COMPILER-LET).  Neither of these proposals appeared to have very much
support.

Proposal COMPILER-LET-CONFUSION:ELIMINATE appears to have the most
support among members of the compiler committee; JonL (and others at
Lucid), Loosemore, Van Roggen, Dalton, and Perdue have all expressed
support for the idea of getting rid of COMPILER-LET.  Since this is an
incompatible change, it is felt that a substantial effort should be
made to help users convert old code.
-------

∂31-Oct-88  1023	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED (V2)    
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 31 Oct 88  10:23:45 PST
Received:  by multimax.ARPA (5.51/25-eef)
	id AA29889; Mon, 31 Oct 88 13:22:32 EST
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA28539; Mon, 31 Oct 88 13:26:26 EST
Message-Id: <8810311826.AA28539@mist.UUCP>
To: David N Gray <Gray%DSG.csc.ti.com@multimax>
Cc: CL-Compiler%SAIL.Stanford.edu@multimax
Subject: Re: Issue DEFCONSTANT-NOT-WIRED (V2) 
In-Reply-To: Your message of Thu, 27 Oct 88 19:15:29 -0500.
             <2802989729-1516801@Kelvin> 
Date: Mon, 31 Oct 88 13:26:20 EST
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

The last time this issue came up, it go bogged down in an argument
about how to define DEFCONSTANT in terms of a CONSTANT proclamation.
While the bogging down was unfortunate, I believe that the strong
connection between DEFCONSTANT and any CONSTANT declaration is obvious
and correct.  Therefore I oppose any CONSTANT declaration which
doesn't duplicate the semantics of DEFCONSTANT (and I'd really like to
see DEFCONSTANT defined in terms of such a declaration).

On the other hand, if you want to rename your proposed new
declaration, I might be willing to support it.

∂31-Oct-88  1116	CL-Compiler-mailer 	Re: issue COMPILER-VERBOSITY, version 1 
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 31 Oct 88  11:16:24 PST
Received:  by multimax.ARPA (5.51/25-eef)
	id AA01959; Mon, 31 Oct 88 14:15:25 EST
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA28699; Mon, 31 Oct 88 14:19:20 EST
Message-Id: <8810311919.AA28699@mist.UUCP>
To: "sandra%defun@cs.utah.edu"@multimax (Sandra J Loosemore)
Cc: cl-compiler%sail.stanford.edu@multimax
Subject: Re: issue COMPILER-VERBOSITY, version 1 
In-Reply-To: Your message of Tue, 25 Oct 88 16:56:26 -0600.
             <8810252256.AA28942@defun.utah.edu> 
Date: Mon, 31 Oct 88 14:19:18 EST
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    Pierson has suggested an entirely different approach -- introducing
    one or more new condition types for informational messages.  This
    could be presented as an alternative proposal on this issue, if he
    cares enough about it to write it up.  Loosemore believes that using
    conditions for this purpose is not appropriate, because this issue
    deals with messages indicating the normal progress of the compiler and
    conditions are supposed to be used to signal exceptional
    (non-ordinary) situations.

On the other hand, conditions are a simple, uniform mechanism with
a well defined interface for users to override the default behavior.
I would like to see Common Lisp start to use mechanisms like
conditions and generic functions instead of yet more ad-hoc special
variables with random, non-user-controllable effects.  This is an area
where we can shrink the complexity of the language while increasing
it's power.

I'll try to get a writeup on my approach out if anyone else is
interested.  It basically consists of a new condition type, call it
INFO, and the statement that the default handler just writes the
message to the same stream as the rest of the compiler output.

All of ERROR, WARNING, NOTICE, and INFO really want to be condition
mixins, but that requires full CLOSification of the Condition System.

∂31-Oct-88  1450	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED (V2)    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 31 Oct 88  14:50:28 PST
Received: by ti.com id AA20404; Mon, 31 Oct 88 16:49:44 CST
Received: from Kelvin by tilde id AA22348; Mon, 31 Oct 88 16:36:59 CST
Message-Id: <2803329342-938510@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 31 Oct 88  16:35:42 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: miller@CS.ROCHESTER.EDU
Cc: CL-Compiler@SAIL.STANFORD.EDU
Subject: Re: Issue DEFCONSTANT-NOT-WIRED (V2)
In-Reply-To: Msg of Fri, 28 Oct 88 14:04 EDT from Brad Miller <miller@CS.ROCHESTER.EDU>

> Does this mean I can do:
> 
> (defvar *mumble*)
> (defun foo ()
> 	(setq *mumble* :bar)
> 	(proclaim '(constant *mumble*)))
> (defun bar ()
> 	(setq *mumble* :foo))
> 
> then
> (foo)
> :bar
> (bar)
> ERROR...
> 
> vs.
> (bar)
> :foo
> (foo)
> :bar
> (foo)
> ERROR...

Evaluated code might behave this way, but there would be no error in
compiled code because the PROCLAIM was not executed until after both
functions were compiled.  This isn't any different from embedding any
other kind of PROCLAIM in a function.  Maybe the proposal needs to make
clear that the error on a SETQ is expected to be reported by the
compiler, not at run time.

∂31-Oct-88  1607	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED (V2)    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 31 Oct 88  16:06:57 PST
Received: by ti.com id AA20828; Mon, 31 Oct 88 18:04:16 CST
Received: from Kelvin by tilde id AA23727; Mon, 31 Oct 88 17:51:02 CST
Message-Id: <2803333811-1206984@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 31 Oct 88  17:50:11 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 DEFCONSTANT-NOT-WIRED (V2)
In-Reply-To: Msg of Fri, 28 Oct 88 12:22:24 MDT from sandra%defun@cs.utah.edu (Sandra J Loosemore)

>	 does it make sense to have a "free"
>     CONSTANT declaration?

It could.  That was the reason for the reference to the
DECLARE-TYPE-FREE issue -- I would want it to be consistent with
whatever behavior is finally decided for TYPE declarations.

> (2) I don't think we should require SETQ'ing the variable to signal an error
>     under any circumstances, since DEFCONSTANT doesn't require it.

Page 69 of CLtL uses the "is an error" terminology, which will need to
be changed.  In the new condition terminology, the phrase "an error is
signalled" seemed more appropriate than any of the alternatives, but
maybe I should have just stuck with "is an error" for now.

> A possible solution for the first problem is to make the CONSTANT
> declaration force a lexical binding.  This is very similar to
> something that Dalton and I were suggesting a couple of weeks ago to
> cl-cleanup on issue PROCLAIM-LEXICAL.  To summarize, the idea was to
> introduce a declaration called LEXICAL or something like that, that
> does the same thing about rebinding as DEFCONSTANT does.

The PROCLAIM-LEXICAL proposal is interesting, but appears premature for
standardization, so I don't want to tie this proposal to it.

>    (Some people
> seem to think that DEFCONSTANT is supposed to proclaim the variable
> SPECIAL, but my reading of p. 69 of CLtL is that it is exactly the
> opposite: DEFCONSTANT disallows special binding of the variable but
> -does- allow it to be rebound lexically.)

But then why does it say "binding of that special variable is an error"
instead of "binding of the special variable with the same name ..."?  
My interpretation of that paragraph is that it is inconsistent.

> I'd suggest making the CONSTANT declaration work the same way, except
> also have it include DEFCONSTANT's prohibition against SETQ'ing.  It
> should also parallel the SPECIAL declaration's scoping behavior.
...
> How does this sound as an alternative?

It appears that the effect is the same except for a case like this:

  (defvar capacity 1000)
  (defun f1 ()
    (let ((capacity 500))
      (declare (constant capacity))
      (f2)))
  (defun f2 ()
    capacity)

Function F1 would return 500 according to my proposal, or 1000 according
to your way.  The question then becomes which result is less surprising.
I think now that it would be safest to just disallow a local CONSTANT
declaration for a special variable, since this situation is potentially
confusing and not very useful.

∂31-Oct-88  1620	CL-Compiler-mailer 	Re: Issue DEFCONSTANT-NOT-WIRED (V2)    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 31 Oct 88  16:20:00 PST
Received: by ti.com id AA20918; Mon, 31 Oct 88 18:19:40 CST
Received: from Kelvin by tilde id AA24060; Mon, 31 Oct 88 18:15:58 CST
Message-Id: <2803335308-1296967@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 31 Oct 88  18:15:08 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "Dan L. Pierson" <pierson%mist@multimax.ARPA>
Cc: CL-Compiler@SAIL.Stanford.edu
Subject: Re: Issue DEFCONSTANT-NOT-WIRED (V2) 
In-Reply-To: Msg of Mon, 31 Oct 88 13:26:20 EST from Dan L. Pierson <pierson%mist@multimax.ARPA>

> While the bogging down was unfortunate, I believe that the strong
> connection between DEFCONSTANT and any CONSTANT declaration is obvious
> and correct.  Therefore I oppose any CONSTANT declaration which
> doesn't duplicate the semantics of DEFCONSTANT (and I'd really like to
> see DEFCONSTANT defined in terms of such a declaration).

But the whole point is that this isn't completely the same as a
DEFCONSTANT.  DEFCONSTANT could be defined in terms of a CONSTANT
proclamation plus some other proclamation that authorized the compiler
to wire-in the value.  I don't see a need to standardize a
user interface to that other piece.

> On the other hand, if you want to rename your proposed new
> declaration, I might be willing to support it.

I'm open to suggestions of a better name.

∂01-Nov-88  0921	CL-Compiler-mailer 	issue COMPILER-DIAGNOSTICS, version 4   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 1 Nov 88  09:21:30 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA29245; Tue, 1 Nov 88 10:21:14 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA03443; Tue, 1 Nov 88 10:21:10 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811011721.AA03443@defun.utah.edu>
Date: Tue, 1 Nov 88 10:21:08 MST
Subject: issue COMPILER-DIAGNOSTICS, version 4
To: cl-compiler@sail.stanford.edu

Here is a new version of the writeup on this issue which incorporates
suggestions from Pitman and Gray.  I am not yet entirely happy with
section 2 of the proposal (see the discussion section) but I wanted to
get some feedback on the general direction this is going in, before
doing more work on it.

-Sandra



Issue:		COMPILER-DIAGNOSTICS
References:	CLtL p. 438-439
		Condition System, Revision #18
		S:>KMP>cl-conditions.text.34
		Issue GC-MESSAGES
		Issue RETURN-VALUES-UNSPECIFIED
		Issue COMPILER-VERBOSITY
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)


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) Clarify that COMPILE-FILE is allowed to print messages to
    *STANDARD-OUTPUT* indicating the normal progress of the compilation.
    (See issue COMPILER-VERBOSITY.)

(2) Clarify that both 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:
	    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 that "is an error" would result at runtime.

	Examples:
	    violation of type declarations
	    SETQ'ing a constant defined with DEFCONSTANT
	    calls to built-in Lisp functions with wrong number of arguments
	    referencing a variable declared IGNORE

    (c) All other diagnostics issued by the compiler should be conditions
	of type NOTICE.  In particular, this category includes all
	diagnostics about matters of programming style.  Although
	conditions of type NOTICE -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 NOTICE.

	Examples:
	    redefinition of function with different argument list
	    unreferenced local variables not declared IGNORE

(3) Require COMPILE-FILE to establish an error handler.  Add a :HANDLER
    keyword argument to COMPILE-FILE, which is a user condition
    handler function which is to be used during compilation.  If the
    user error handler is not supplied or declines to handle a condition,
    then the compiler's error handler will be invoked.  Require the
    compiler's error handler to handle the ABORT restart by aborting
    the smallest feasible part of the compilation.

(4) Specify that COMPILE-FILE returns three values.  The first value is the
    truename of the output file, or NIL if the file could not be created.
    The second value is non-NIL if errors were signalled during compilation
    (indicating that the output file is almost certainly unusable).  The
    third value is non-NIL if warnings were signalled during compilation
    (indicating that the output file may or may not be usable).

(5) Clarify that COMPILE does not establish a condition handler.  Instead,
    it uses whatever condition handler has been established in the environment
    from which it is called.


Rationale:

Point by point,

(1) This reflects current practice.

(2) Conditions such as syntax errors which are errors in the interpreter
    remain errors in the compiler.  The division of other conditions
    into WARNINGs and NOTICEs allows potentially serious problems to be
    distinguished from mere kibbitzing on the part of the compiler.

(3) It is reasonable for the default handling of compiler errors not to
    cause the debugger to be invoked.  However, any error handler 
    established by COMPILE-FILE would override handlers established by the
    user in the surrounding environment.

    Requiring the compiler's error handler 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 file compilation if it is not 
    feasible to abort a smaller part.

(4) This allows users to determine whether or not COMPILE-FILE is able to
    actually compile the file successfully.  Returning several values is
    is more useful than a single success/failure value because there are
    several degrees of failure.

(5) This is to reflect the use of COMPILE-FILE as being more "batch"-oriented
    and COMPILE as being more interactive.  There is less motivation to have
    COMPILE try to recover from errors without user interaction.


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.


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.


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 normal progress messages from the compiler is discussed
in more detail in a separate issue, COMPILER-VERBOSITY.

Pitman says that he would like to require COMPILE-FILE's error handler
never to invoke the debugger.  I have left that out of this proposal
because it seems like an unnecessary restriction; if users want to ensure
that kind of behavior it is possible to do so by supplying a user error 
handler.  (Of course, the converse is also true.)

Sections 2b and 2c need more work.  In CLtL, everything has been lumped
together as warnings, but there seems to be general agreement that
some things (like complaints about unused variables) should really be
notices instead.  Basically we need to go through and find every place
where CLtL says that the compiler might issue a warning and decide what
category it belongs in, and list it here.

This proposal, as it stands, doesn't propose to add any new conditions
specific to the compiler.  We might consider introducing a 
COMPILER-CONDITION that can be used in mixins with the other condition
types, so that error handlers can distinguish between errors signalled
by the compiler itself and errors signalled during macroexpansion or
EVAL-WHEN processing.

Gray would like to exclude errors resulting from failure to open the
input and output files from the compiler's error handling.  The
proposal should probably be specific about this, one way or the other.

-------

∂02-Nov-88  1653	CL-Compiler-mailer 	Re: issue COMPILER-DIAGNOSTICS, version 4    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 2 Nov 88  16:52:50 PST
Received: by ti.com id AA07604; Wed, 2 Nov 88 18:52:02 CST
Received: from Kelvin by tilde id AA20470; Wed, 2 Nov 88 18:33:23 CST
Message-Id: <2803509313-11740557@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 2 Nov 88  18:35:13 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, McCreary@DSG.csc.ti.com
Subject: Re: issue COMPILER-DIAGNOSTICS, version 4
In-Reply-To: Msg of Tue, 1 Nov 88 10:21:08 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)

>     (c) All other diagnostics issued by the compiler should be conditions
> 	of type NOTICE.

I couldn't find a NOTICE condition in the Condition System document; is
this intended to be a new condition, or where is it defined?

> (3) Require COMPILE-FILE to establish an error handler.  Add a :HANDLER
>     keyword argument to COMPILE-FILE, which is a user condition
>     handler function which is to be used during compilation.  If the
>     user error handler is not supplied or declines to handle a condition,
>     then the compiler's error handler will be invoked. 

To make sure I understand this, does this mean that COMPILE-FILE will look
something like the following?

 (DEFUN COMPILE-FILE (INPUT-FILE &KEY OUTPUT-FILE HANDLER)
   (FLET ((compilers-handler (condition)
 		(issue-message ...) ; should this call WARN?
 		(ABORT)))
     (IF (NULL HANDLER)
 	 (HANDLER-BIND ((ERROR #'compilers-handler))
 	   (internal-compile-file input-file output-file))
       (HANDLER-BIND ((ERROR #'compilers-handler))
 	 (HANDLER-BIND ((ERROR HANDLER))
 	   (internal-compile-file input-file output-file))))))
 
So that if the user wants to enter the debugger he can do:
 
 (compile-file "foo" :handler #'(lambda (c) (invoke-debugger c)))

I wonder if the argument shouldn't be called :ERROR-HANDLER instead of
just :HANDLER in order to be clearer about how it is used?

>    We might consider introducing a 
> COMPILER-CONDITION that can be used in mixins with the other condition
> types, so that error handlers can distinguish between errors signalled
> by the compiler itself and errors signalled during macroexpansion or
> EVAL-WHEN processing.

I think that we do want to be able to distinguish compiler-generated
conditions, but it looks like it will depend on the outcome of issue
CLOS-CONDITIONS whether this can be handled by a mixin or whether we would
need conditions COMPILER-ERROR and COMPILER-WARNING.

∂07-Nov-88  1337	CL-Compiler-mailer 	issues dealing with compiling constants 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Nov 88  13:36:58 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA24498; Mon, 7 Nov 88 13:51:52 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA03842; Mon, 7 Nov 88 13:50:50 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811072050.AA03842@defun.utah.edu>
Date: Mon, 7 Nov 88 13:50:48 MST
Subject: issues dealing with compiling constants
To: cl-compiler@sail.stanford.edu

Coming out shortly are draft proposals on 5 issues relating to
compiling constants.  (I decided to write them up separately instead
of trying to lump them all together.)

All of the issues are in very rough form, and they all need more
feedback for the "current practice" section.  On most of these I was
only able to say things about the implementations I've worked on
myself, which don't really represent the mainstream of commercial Lisp
development.  Please take some time to consider how these issues
affect you.

-Sandra
-------

∂07-Nov-88  1339	CL-Compiler-mailer 	issue CONSTANT-ARRAY-ATTRIBUTES, version 1   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Nov 88  13:39:00 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA24591; Mon, 7 Nov 88 13:54:11 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA03854; Mon, 7 Nov 88 13:53:08 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811072053.AA03854@defun.utah.edu>
Date: Mon, 7 Nov 88 13:53:07 MST
Subject: issue CONSTANT-ARRAY-ATTRIBUTES, version 1
To: cl-compiler@sail.stanford.edu

Issue:		CONSTANT-ARRAY-ATTRIBUTES
References:	CLtL p. 369
		Issue CONSTANT-COMPILABLE-TYPES
Category:	CLARIFICATION
Edit History:   V1, 07 Nov 1988, Sandra Loosemore
Status:		*DRAFT*


Problem Description:

Must the compiler preserve nonprintable aspects of arrays appearing
as constants, such as the element type or fill pointer?


Proposal CONSTANT-ARRAY-ATTRIBUTES:PRESERVED:

State that the compiler must preserve the :ELEMENT-TYPE, :ADJUSTABLE,
:FILL-POINTER, :DISPLACED-TO, and :DISPLACED-INDEX-OFFSET attributes
of arrays which appear as constants.


Rationale:

There's no need to propagate the brokenness of the printer to the
compiler.


Current Practice:

Does any implementation -not- implement this proposal?


Cost to implementors:

The primary implication of this proposal is that COMPILE-FILE cannot
use the built-in printer to write out constant data structures in its
output file.  Any implementation that writes out constants as text
rather than in some binary format would have to use some other
mechanism for arrays, such as #,(MAKE-ARRAY ...) syntax.


Cost to users:

None.


Benefits:

An area of ambiguity in the language is removed.


Discussion:

It would be nice if there were some flag to force the printer to print
arrays out in #,(MAKE-ARRAY ...) syntax for other purposes.
-------

∂07-Nov-88  1339	CL-Compiler-mailer 	issue CONSTANT-MODIFICATION, version 1  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Nov 88  13:39:46 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA24544; Mon, 7 Nov 88 13:53:22 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA03848; Mon, 7 Nov 88 13:52:19 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811072052.AA03848@defun.utah.edu>
Date: Mon, 7 Nov 88 13:52:15 MST
Subject: issue CONSTANT-MODIFICATION, version 1
To: cl-compiler@sail.stanford.edu

Issue:		CONSTANT-MODIFICATION
References:	CLtL p. 78, 87
		Issue CONSTANT-COLLAPSING
Category:	CLARIFICATION
Edit History:   V1, 07 Nov 1988, Sandra Loosemore
Status		*DRAFT*


Problem Description:

CLtL states that an implementation is permitted to "collapse"
constants appearing in code to be compiled if they are EQUAL.  This
implicit sharing of compiled data structures may result in
unpredictable behavior if destructive operations are performed.
However, CLtL does not explicitly allow or disallow destructive
operations on constants.  


Proposal CONSTANT-MODIFICATION:DISALLOW:

Clarify that it is an error to destructively modify objects which are 
self-evaluating forms or which appear inside of a QUOTE special form.

Clarify that QUOTE may (recursively) copy its argument and return the
copy.


Rationale:

Disallowing modification of constants consistently in all situations,
rather than just in compiled code, is proposed because in some
compiled-only situations it may be difficult to distinguish between
"compiled" and "interpreted" code.


Current Practice:

Many implementations "collapse" compiled constants.

Many implementations treat compiled constants as read-only.  In
PSL/PCLS, for example, quoted data structures in compiled code are
copied into a part of memory that is not scanned by the garbage
collector.


Cost to implementors:

None.


Cost to users:

User programs which perform destructive operations on constants are
already nonportable.


Benefits:

Many novice programmers do not realize that modifying quoted data
structures is an error in many implementations.  Including an explicit
statement in the standard that doing so is a bad idea will reduce
confusion.


Discussion:
-------

∂07-Nov-88  1340	CL-Compiler-mailer 	issue CONSTANT-CIRCULAR-COMPILATION, version 1    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Nov 88  13:40:00 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA24652; Mon, 7 Nov 88 13:55:15 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA03866; Mon, 7 Nov 88 13:54:13 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811072054.AA03866@defun.utah.edu>
Date: Mon, 7 Nov 88 13:54:12 MST
Subject: issue CONSTANT-CIRCULAR-COMPILATION, version 1
To: cl-compiler@sail.stanford.edu

Issue:		CONSTANT-CIRCULAR-COMPILATION
References:	Issue CONSTANT-COLLAPSING
		Issue CONSTANT-MODIFICATION
Category:	CLARIFICATION
Edit History:   V1, 07 Nov 1988, Sandra Loosemore
Status:		*DRAFT*


Problem Description:

CLtL does not specify whether constants containing circular references
may be compiled, or whether the compiler must preserve sharing of EQ
substructures.


Proposal CONSTANT-CIRCULAR-COMPILATION:NO

State that it is an error for an object containing a circular reference to
appear as a constant to be compiled.  State that the compiler is not
required to preserve EQness of substructures.


Rationale:

In general, COMPILE-FILE/LOAD results in a copy of the original object
instead of an object that is EQL to the original.  Issue
CONSTANT-MODIFICATION allows QUOTE to recursively copy its argument,
which is not guaranteed to preserve EQness of substructures.  It is
more consistent to permit copying in all situations instead of in some
but not others.

Disallowing portable programs from containing circular constants
allows compiled file loaders to use somewhat simpler implementation
strategies (for example, to build constants in a strict bottom-up
fashion).


Current Practice:

A-Lisp preserves EQness of substructures (since it makes an effort to
collapse isomorphic structures) but signals an error if an attempt is
made to compile a circular constant.  


Cost to implementors:

None.  This proposal restricts the behavior of valid programs, not of
valid implementations.


Cost to users:

Programs which depend upon circularity or sharing of substructure
being preserved by the compiler are already nonportable.  This
proposal simply formalizes the status quo.


Benefits:

An area of ambiguity in the language is removed.


Discussion:
-------

∂07-Nov-88  1340	CL-Compiler-mailer 	issue CONSTANT-COLLAPSING, version 1    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Nov 88  13:40:23 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA24562; Mon, 7 Nov 88 13:53:43 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA03851; Mon, 7 Nov 88 13:52:40 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811072052.AA03851@defun.utah.edu>
Date: Mon, 7 Nov 88 13:52:38 MST
Subject: issue CONSTANT-COLLAPSING, version 1
To: cl-compiler@sail.stanford.edu

Issue:		CONSTANT-COLLAPSING
References:	CLtL p. 78, 87
		Issue CONSTANT-MODIFICATION
		Issue EQUAL-STRUCTURE
Category:	CHANGE
Edit History:   V1, 07 Nov 1988, Sandra Loosemore
Status:		*DRAFT*


Problem Description:

CLtL states that an implementation is permitted to "collapse"
constants appearing in code to be compiled if they are EQUAL.  This
does not permit "collapsing" of more general isomorphic data
structures, such as arrays and structures, which is often desirable.


Proposal CONSTANT-COLLAPSING:GENERALIZE:

State the an implementation is permitted to "collapse" constants
appearing in code to be compiled if they are isomorphic.

Objects are isomorphic if they are EQL, if they are pathnames that are
EQUAL, or if they are structured objects of the same type and the
corresponding components are isomorphic.  Arrays are isomorphic if and
only if they could be constructed by identical calls to MAKE-ARRAY
(with isomorphic :INITIAL-CONTENTS arguments).


Rationale:

There is little reason why implementations should not be allowed to
perform more general collapsing of structures, since the arguments
against doing so also apply to collapsing of EQUAL structures, which
is already permitted.


Current Practice:

Both PSL/PCLS and A-Lisp collapse isomorphic arrays and structures,
and certain other data types that are defined internally as structures
(RANDOM-STATEs, for example).


Cost to implementors:

None.  This extends the range of permitted behavior for
implementations but does not require any implementation to change.


Cost to users:

It is hard to imagine a program that would break under this proposal.
The EQL-ness or uniqueness of composite structures in compiled code
cannot be guaranteed in any event, since the combination of
COMPILE-FILE and LOAD generally results in a copy of the original
structure.


Benefits:

Collapsing of isomorphic arrays and structures may lead to significant
memory savings in some applications.


Discussion:

Some people believe that the definition of "isomorphic" given here
should really be the definition of EQUAL (or possibly EQUALP).
-------

∂07-Nov-88  1340	CL-Compiler-mailer 	issue CONSTANT-COMPILABLE-TYPES, version 1   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Nov 88  13:40:38 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA24634; Mon, 7 Nov 88 13:54:41 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA03859; Mon, 7 Nov 88 13:53:38 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811072053.AA03859@defun.utah.edu>
Date: Mon, 7 Nov 88 13:53:37 MST
Subject: issue CONSTANT-COMPILABLE-TYPES, version 1
To: cl-compiler@sail.stanford.edu

Issue:		CONSTANT-COMPILABLE-TYPES
References:	CLtL p. 370
		Issue EVAL-OTHER
		Issue HASH-TABLE-PRINTED-REPRESENTATION
Category:	CLARIFICATION
Edit History:   V1, 07 Nov 1988, Sandra Loosemore
Status:		*DRAFT*


Problem Description:

CLtL does not address this issue of what kinds of objects may appear as
constants in code to be compiled.  For example, what should COMPILE-FILE
do with an open stream that appears as a constant?


Proposal CONSTANT-COMPILABLE-TYPES:LIKE-PRINT:

Clarify that it is valid for an object to appear as a constant to be
compiled if it is also required to have a printed representation that
can be read back in by the function READ.

State that implementations may extend the set of datatypes that it knows
how to compile, but that an error will be signalled by the compiler if 
it encounters an uncompilable object.

Clarify that structures defined with DEFSTRUCT can always appear as
compiled constants, regardless of whether or not they have a
:PRINT-FUNCTION defined.


Rationale:

The list of types that are explicitly not required to have readable
printed representations (currently) includes HASH-TABLE, READTABLE,
PACKAGE, STREAM, and FUNCTION.

Compiling HASH-TABLEs may result in problems due to the "collapsing"
of isomorphic data structures.  For example, it is possible that there
may be two distinct but EQUAL keys in an EQL hash table that the compiler
collapses together.

It makes little sense to compile objects of type PACKAGE and STREAM,
because they reflect the internal state of the compiletime
environment.  Constant FUNCTIONs cannot generally be treated as
constants; for example, what would COMPILE-FILE do with a constant
compiled function when it is compiling for a different target machine?

The arguments for not allowing READTABLEs to appear as constants in
compiled code are less compelling, but they are included in the list
for consistency with the READ/PRINT rules.


Current Practice:

Lucid Common Lisp appears to compile constant open streams into NIL,
without signalling a warning or error.  It appears to compile constant
packages, functions, and readtables correctly.  It compiles
hash-tables without complaint but it is not clear whether it collapses
isomorphic keys.


Cost to implementors:

This proposal is fairly conservative and should not require any
implementation to add or remove support for compiling various kinds of
constant objects.  It does require that an error should be signalled
in cases where an object cannot be compiled correctly, which should be
a very minor change.


Cost to users:

Unknown.


Benefits:

An area of ambiguity in the language is removed.


Discussion:

-------

∂07-Nov-88  1538	CL-Compiler-mailer 	Re: issue CONSTANT-ARRAY-ATTRIBUTES, version 1    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 7 Nov 88  15:37:53 PST
Received: by ti.com id AA28579; Mon, 7 Nov 88 17:36:10 CST
Received: from Kelvin by tilde id AA26608; Mon, 7 Nov 88 17:17:41 CST
Message-Id: <2803936724-1273455@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 7 Nov 88  17:18:44 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 CONSTANT-ARRAY-ATTRIBUTES, version 1
In-Reply-To: Msg of Mon, 7 Nov 88 13:53:07 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)

> Proposal CONSTANT-ARRAY-ATTRIBUTES:PRESERVED:
> 
> State that the compiler must preserve the :ELEMENT-TYPE, :ADJUSTABLE,
> :FILL-POINTER, :DISPLACED-TO, and :DISPLACED-INDEX-OFFSET attributes
> of arrays which appear as constants.

Preserving :ELEMENT-TYPE, :ADJUSTABLE, and :FILL-POINTER is good, but
I'm not so sure about trying to preserve displacement.  To do that would
mean also writing to the object file the array it is displaced to, but
that could mean duplication of the array when the file is loaded, which
could defeat the reason the user was using displacement.  I would
suggest making it an error to use a displaced array as a constant since
there is no way to be certain of what the user wants to happen.
Disallowing it would also seem to be consistent with proposal
CONSTANT-CIRCULAR-COMPILATION:NO.

You might want to re-word this to clarify that what is preserved is the
value returned by the functions ARRAY-ELEMENT-TYPE and
ADJUSTABLE-ARRAY-P, since this may not be the same as the values of the
:ELEMENT-TYPE and :ADJUSTABLE options in the MAKE-ARRAY call that
originally created the array.

> Current Practice:
> 
> Does any implementation -not- implement this proposal?

The Explorer does not preserve the :DISPLACED-TO and
:DISPLACED-INDEX-OFFSET attributes.

∂07-Nov-88  1551	CL-Compiler-mailer 	Re: issue CONSTANT-CIRCULAR-COMPILATION, version 1
Received: from ti.com by SAIL.Stanford.EDU with TCP; 7 Nov 88  15:50:51 PST
Received: by ti.com id AA28687; Mon, 7 Nov 88 17:49:56 CST
Received: from Kelvin by tilde id AA27066; Mon, 7 Nov 88 17:34:38 CST
Message-Id: <2803937762-1335815@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 7 Nov 88  17:36:02 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 CONSTANT-CIRCULAR-COMPILATION, version 1
In-Reply-To: Msg of Mon, 7 Nov 88 13:54:12 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)

> Proposal CONSTANT-CIRCULAR-COMPILATION:NO
> 
> State that it is an error for an object containing a circular reference to
> appear as a constant to be compiled.  State that the compiler is not
> required to preserve EQness of substructures.

Good, but the term "circular reference" could be unclear since it
invokes the image of a circular list, while I assume you intend this
restriction to apply to recursive lists also.

> Current Practice:

The Explorer compiler is able to reproduce recursive lists and arrays,
but currently hangs in a loop on a circular list.

∂07-Nov-88  1954	CL-Compiler-mailer 	issue CONSTANT-COLLAPSING, version 1    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Nov 88  19:54:03 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01288g; Mon, 7 Nov 88 19:52:58 PST
Received: by bhopal id AA07700g; Mon, 7 Nov 88 19:51:36 PST
Date: Mon, 7 Nov 88 19:51:36 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811080351.AA07700@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 7 Nov 88 13:52:38 MST <8811072052.AA03851@defun.utah.edu>
Subject: issue CONSTANT-COLLAPSING, version 1

The definition of "isomorphic" cannot be EQUALP, since it does the
terribly foolish thing of ignoring alphabeticv case in strings.
Had the more reasonable proposal to extend EQUAL been accepted by
the cleanup committee, then EQUAL would have been satisfactory.
As it stands now, you may just have to explicitly spell out what
"coalesciblep" means.

-- JonL --

P.S.  As you can tell, I favor the term "coalescing" to
"collapsing".

∂07-Nov-88  1958	CL-Compiler-mailer 	issue CONSTANT-COMPILABLE-TYPES, version 1   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Nov 88  19:58:09 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01292g; Mon, 7 Nov 88 19:57:06 PST
Received: by bhopal id AA07703g; Mon, 7 Nov 88 19:55:45 PST
Date: Mon, 7 Nov 88 19:55:45 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811080355.AA07703@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 7 Nov 88 13:53:37 MST <8811072053.AA03859@defun.utah.edu>
Subject: issue CONSTANT-COMPILABLE-TYPES, version 1

I don't believe that the catch pharase "like print" is good enough.
Lucid's 3.0 release "compiles" most structure-like data except for
sepcial treatment of hash-tables and packages:
  (1) hash-tables must be indexed by the key entries, rather than
      by the fixnum indices of the array holding the entries
  (2) packages must be referenced by name, rather than by components
      (much the same way that symbols are referenced).

-- JonL --

∂07-Nov-88  2007	CL-Compiler-mailer 	issue CONSTANT-CIRCULAR-COMPILATION, version 1    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Nov 88  20:07:30 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01307g; Mon, 7 Nov 88 20:06:26 PST
Received: by bhopal id AA07746g; Mon, 7 Nov 88 20:05:05 PST
Date: Mon, 7 Nov 88 20:05:05 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811080405.AA07746@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 7 Nov 88 13:54:12 MST <8811072054.AA03866@defun.utah.edu>
Subject: issue CONSTANT-CIRCULAR-COMPILATION, version 1

re: State that it is an error for an object containing a circular reference to
    appear as a constant to be compiled.  State that the compiler is not
    required to preserve EQness of substructures.

Both of these constraints appear to me to be a violation of the
already acknowledge desire to have the compiled code act just like
the interpreted code.  What is the motivation for them? I don't see
any performance justification; and even if there were, I'd look at
it with a very jaundiced eye, favoring interpreter/compiler
consistency over nickle-and-dime issues of compiler speed.

Furthermore, the phraseology about DEFCONSTANT (CLtL, p69)
explicitly requires preservation ofEQLness of constants, which
themselves can be parts of substructures.  So I wouldn't go for a
constraint against "EQness of substructures" unless "substructures"
is spelled out much more explicitly.


-- JonL -

∂07-Nov-88  2009	CL-Compiler-mailer 	issue CONSTANT-MODIFICATION, version 1  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Nov 88  20:09:05 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01310g; Mon, 7 Nov 88 20:07:59 PST
Received: by bhopal id AA07765g; Mon, 7 Nov 88 20:06:39 PST
Date: Mon, 7 Nov 88 20:06:39 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811080406.AA07765@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: Sandra J Loosemore's message of Mon, 7 Nov 88 13:52:15 MST <8811072052.AA03848@defun.utah.edu>
Subject: issue CONSTANT-MODIFICATION, version 1

This issue really isn't just a compiler issue -- it clarifies the
whole semantics of QUOTE.  I think it ought to be raised in the
Cleanup committee (and in fact, Larry has been expecting/hoping for
some such issue to arise there).

-- JonL --

∂07-Nov-88  2040	CL-Compiler-mailer 	Issue CONSTANT-COMPILABLE-TYPES    
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 7 Nov 88  20:40:30 PST
Received: from snail.Sun.COM by Sun.COM (4.0/SMI-4.0)
	id AA05072; Mon, 7 Nov 88 20:37:33 PST
Received: from clam.sun.com by snail.Sun.COM (4.0/SMI-4.0)
	id AA08523; Mon, 7 Nov 88 20:40:27 PST
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA05593; Mon, 7 Nov 88 20:40:57 PST
Date: Mon, 7 Nov 88 20:40:57 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8811080440.AA05593@clam.sun.com>
To: cl-compiler@sail.stanford.edu
Subject: Issue CONSTANT-COMPILABLE-TYPES

Synchronic city, I guess, plus an extra burst of motivation due
to Sandra's released proposals:

Issue:		CONSTANT-COMPILABLE-TYPES
References:	CLtL pp. 56, 77-80, 324
		Issue CONSTANT-MODIFICATION
		Issue CONSTANT-CIRCULAR-COMPILATION
		Issue CONSTANT-ARRAY-ATTRIBUTES
Category:	CLARIFICATION, ADDITION
Edit history:	Cris Perdue 11/7/88
Status:		DRAFT

Problem description:

A Common Lisp compiler must record information about constants so that
a "corresponding" constant can be created at load-time.  This is
fundamentally a problem of file-compilation.  For in-core compilation
it appears to be acceptable to use the constants appearing in the
interpreted code exactly as-is, though this is not required.  We
assume that compiled constants may be stored (i.e. on disk) in an
implementation-dependent manner.

Proposal:  CONSTANT-COMPILABLE-TYPES

- References to symbols are left for load-time resolution.
- Aggregate objects are traversed and their components are also
  recorded.
- Numbers and characters, i.e. objects that must be compared with EQL
  rather than EQ, are not aggregate in the sense being discussed here.
  They may appear in constants, and numbers and characters appearing
  in constants have the same requirements on their behavior as numbers
  and characters in any other context.

For aggregate objects there must be some policy on supporting
circular structures and otherwise shared structures.  That is not
specified here.

Aggregate objects have certain Basic Individual Attributes (B.A.'s?)
These are recorded as the constant is compiled and they are also
traversed.

Symbol	     No symbol is a constant in the sense considered here, but
	     references to symbols are permitted in any constant.

Cons	     CAR, CDR

Array	     All elements, fill pointer existence,
	     fill pointer value if present,
	     dimensions, element-type, adjustable-array-p, displaced-to,
	     displaced-index-offset

Structure    Slot values, name of structure type

Hash-table   Keys and values

Readtable    Function for each key, mappings for dispatch macros

Pathname     Each pathname component

Package, Stream, Random-state
             It is an error for a package, stream, or random state
	     to appear ina compiled constant, but the language may be
	     extended in the future to support certain cases.

Function     Functions are permitted in compiled constants, and are
	     handled to the same degree and in the same way as the
	     definitions of compiled functions defined by DEFUN.

Generic-function, Method
	     Help is needed from the CLOS committee to determine what

Rationale:

This proposal appears to reflect user demand and appears not to exceed
the capabilities of most implementations of the language.

Current practice:

This appears to be a reasonable approximation to what is done by the
Franz and Lucid implementations.  I believe that the Symbolics and
Explorer handle at least this many cases.  

Adoption cost:

Not known.  Probably moderate.  

Benefits:

Users would be able to use aggregate objects in constants with
confidence about the behavior of their code.

Conversion cost:

Nil.  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 would subsume isse CONSTANT-ARRAY-ATTRIBUTES if accepted.

∂07-Nov-88  2138	CL-Compiler-mailer 	Re:  issue CONSTANT-CIRCULAR-COMPILATION, version 1    
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 7 Nov 88  21:38:23 PST
Received: from snail.Sun.COM by Sun.COM (4.0/SMI-4.0)
	id AA05635; Mon, 7 Nov 88 21:35:22 PST
Received: from clam.sun.com by snail.Sun.COM (4.0/SMI-4.0)
	id AA09303; Mon, 7 Nov 88 21:38:00 PST
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA05650; Mon, 7 Nov 88 21:38:38 PST
Date: Mon, 7 Nov 88 21:38:38 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8811080538.AA05650@clam.sun.com>
To: jonl@lucid.com, sandra%defun@cs.utah.edu
Subject: Re:  issue CONSTANT-CIRCULAR-COMPILATION, version 1
Cc: cl-compiler@sail.stanford.edu

> re: State that it is an error for an object containing a circular reference to
>     appear as a constant to be compiled.  State that the compiler is not
>     required to preserve EQness of substructures.
> 
> Both of these constraints appear to me to be a violation of the
> already acknowledge desire to have the compiled code act just like
> the interpreted code.  What is the motivation for them? I don't see
> any performance justification; and even if there were, I'd look at
> it with a very jaundiced eye, favoring interpreter/compiler
> consistency over nickle-and-dime issues of compiler speed.
> 
The proposal CONSTANT-COMPILABLE-TYPES:SPECIFY (just sent out),
is explicit about what types can exist in compiled constants and
what attributes accompany each.  I think that users want to be
able to compile any object they can make, though this does raise
implementation issues.  Let's consider allowing circularity.
By the way, Steve Haflich says that the Franz implementation
supports circularity when an appropriate flag is turned on.

> Furthermore, the phraseology about DEFCONSTANT (CLtL, p69)
> explicitly requires preservation ofEQLness of constants, which
> themselves can be parts of substructures.  So I wouldn't go for a
> constraint against "EQness of substructures" unless "substructures"
> is spelled out much more explicitly.
> 
The language on p69 does not seem sensible to me.  For one thing,
if we compile a file containing:

(defun afoo ()
  '(and a foo))

then load the binary, then do:

(setf (symbol-function 'bfoo) (symbol-function 'afoo))

then reload the binary containing afoo, (eq (afoo) (bfoo)) is NIL in
Lucid's implementation.

I also tried out
compilation of the following in Lucid's implementation (in a file).

(defconstant fooey
  '(poo bar bletch))
  
(defun yecko ()
  fooey)
  
To my surprise, after loading the binary, (eq fooey (yecko))
returned T.  So I redefined fooey as per p56, using defconstant,
and reloaded the binary.  At this point, (eq fooey (yecko)) was
still T, but the value of fooey was set back to the compiletime
value.  This preserved EQLness, but the use of the constant redefined
it.

My expectation has always been that compiling a named constant
fooey would be equivalent to compiling a macro invocation, such
as (uck), where:

(defmacro uck ()
  `',fooey)

In other words, the value of the named constant would be treated
the same as a quoted expression containing the compiletime value
of the constant.

Do others share this conception, or do you just consider it
my mistake, or what?

∂08-Nov-88  0727	CL-Compiler-mailer 	Re:  issue CONSTANT-CIRCULAR-COMPILATION, version 1    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 8 Nov 88  07:27:12 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA19060; Tue, 8 Nov 88 08:26:19 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA04523; Tue, 8 Nov 88 08:26:12 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811081526.AA04523@defun.utah.edu>
Date: Tue, 8 Nov 88 08:26:10 MST
Subject: Re:  issue CONSTANT-CIRCULAR-COMPILATION, version 1
To: cperdue@Sun.COM (Cris Perdue)
Cc: jonl@lucid.com, sandra%defun@cs, cl-compiler@sail.stanford.edu
In-Reply-To: cperdue@Sun.COM (Cris Perdue), Mon, 7 Nov 88 21:38:38 PST

Re EQLness of DEFCONSTANTS.  I've always thought that this feature was
"broken" and it isn't just because of the compiler.  Suppose I put

    (defconstant broken '(a b c))

in a file, and load the file twice.  Since the reader constructs a
new, non-EQL list for the value each time, a number of implementations
signal an error or warning about changing the value of the constant.
I've concluded that one shouldn't use structured objects as
defconstant values. 

I wonder how many programs would break if we only required
defconstants always to be isomorphic, instead of EQL?

-Sandra
-------

∂08-Nov-88  0807	CL-Compiler-mailer 	Re: issue CONSTANT-CIRCULAR-COMPILATION, version 1
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 8 Nov 88  08:07:07 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA20377; Tue, 8 Nov 88 09:06:44 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA04552; Tue, 8 Nov 88 09:06:41 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811081606.AA04552@defun.utah.edu>
Date: Tue, 8 Nov 88 09:06:39 MST
Subject: Re: issue CONSTANT-CIRCULAR-COMPILATION, version 1
To: Jon L White <jonl@lucid.com>
Cc: sandra%defun@cs, cl-compiler@sail.stanford.edu
In-Reply-To: Jon L White <jonl@lucid.com>, Mon, 7 Nov 88 20:05:05 PST

> Date: Mon, 7 Nov 88 20:05:05 PST
> From: Jon L White <jonl@lucid.com>
> 
> re: State that it is an error for an object containing a circular reference to
>     appear as a constant to be compiled.  State that the compiler is not
>     required to preserve EQness of substructures.
> 
> Both of these constraints appear to me to be a violation of the
> already acknowledge desire to have the compiled code act just like
> the interpreted code.  What is the motivation for them? I don't see
> any performance justification; and even if there were, I'd look at
> it with a very jaundiced eye, favoring interpreter/compiler
> consistency over nickle-and-dime issues of compiler speed.

The reason why I suggested not allowing circular constants is because
a number of implementations currently don't handle them correctly.
The argument for me is not so much compiler speed as size and
complexity of the loader and the compiler/loader interface.  I'd guess
that the loader I wrote for A-Lisp would be at least two or three
times as big as it is now if I had to extend it to handle circular
structures, and it would have to use a great deal more memory for
temporary storage as well.

Not requiring EQness of substructures to be preserved is a possible
consequence of allowing QUOTE to copy its argument.  Now that you
mention it, it seems that this is not strictly a property of the
compiler -- it's a property of QUOTE that needs to be clarified
further.

Also, since the compiler is allowed to collapse isomorphic but non-EQL
structures, you can already end up with EQness of substructure
happening where you didn't expect it, and it seems symmetric to say
that you can't depend on -either- EQness or non-EQness of substructure
being preserved. 

-Sandra
-------

∂08-Nov-88  0851	CL-Compiler-mailer 	Re: issue CONSTANT-CIRCULAR-COMPILATION, version 1
Received: from ti.com by SAIL.Stanford.EDU with TCP; 8 Nov 88  08:51:13 PST
Received: by ti.com id AA03995; Tue, 8 Nov 88 10:50:19 CST
Received: from Kelvin by tilde id AA16309; Tue, 8 Nov 88 10:41:55 CST
Message-Id: <2803999396-5038883@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 8 Nov 88  10:43:16 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@lucid.com>
Cc: sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu
Subject: Re: issue CONSTANT-CIRCULAR-COMPILATION, version 1
In-Reply-To: Msg of Mon, 7 Nov 88 20:05:05 PST from Jon L White <jonl@lucid.com>

> Furthermore, the phraseology about DEFCONSTANT (CLtL, p69)
> explicitly requires preservation ofEQLness of constants,

But that is talking about DEFCONSTANT values and really has nothing to do
with QUOTE forms.  Since several people seem confused about this point,
let me offer my understanding of what CLtL means there.

Given 

  (DEFPARAMETER V '(A B C))
  (DEFUN F1 () V)
  (DEFUN F2 () V) 

then you would expect that (EQL (F1) (F2)) => T.
Now if this is changed to use DEFCONSTANT instead:

  (DEFCONSTANT V '(A B C))
  (DEFUN F1 () V)
  (DEFUN F2 () V) 

then (EQL (F1) (F2)) should still be true because the substitution of the
value for the reference is considered an optimization that shouldn't
change this aspect of the semantics.  (In practice, this generally means
that value substitution can not be done if the value is a list.)  But of
course, re-executing the DEFCONSTANT form can produce a new value that is
not EQ to the old value, just like re-executing DEFPARAMETER can.  To
emphasize that this is a separate issue from the treatment of QUOTE forms,
note that what I have said above still applies if the example is changed
to

  (DEFCONSTANT V (LIST (FOO) (BAR)))

I think this is a good rule because producing multiple copies of lists or
arrays would generally be counter-productive anyway.

∂08-Nov-88  1036	CL-Compiler-mailer 	Issue: CONSTANT-COMPILABLE-TYPES   
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 8 Nov 88  10:36:04 PST
Received: from snail.Sun.COM by Sun.COM (4.0/SMI-4.0)
	id AA13823; Tue, 8 Nov 88 10:32:59 PST
Received: from clam.sun.com by snail.Sun.COM (4.0/SMI-4.0)
	id AA24720; Tue, 8 Nov 88 10:34:34 PST
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA06112; Tue, 8 Nov 88 10:35:12 PST
Date: Tue, 8 Nov 88 10:35:12 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8811081835.AA06112@clam.sun.com>
To: cl-compiler@sail.stanford.edu
Subject: Issue: CONSTANT-COMPILABLE-TYPES

It looks like my proposal, CONSTANT-COMPILABLE-TYPES:SPECIFY,
went out without the word SPECIFY in the name.  Also, references
to "compiled constant" should read just "constant", though
erring operations would probably actually work on interpreted
constants.
				-Cris

∂08-Nov-88  1105	CL-Compiler-mailer 	issue CONSTANT-CIRCULAR-COMPILATION, version 1    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 8 Nov 88  11:05:30 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01616g; Tue, 8 Nov 88 11:04:11 PST
Received: by bhopal id AA01386g; Tue, 8 Nov 88 11:02:49 PST
Date: Tue, 8 Nov 88 11:02:49 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8811081902.AA01386@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cperdue@Sun.COM, jonl@lucid.com, sandra%defun@cs,
        cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 8 Nov 88 08:26:10 MST <8811081526.AA04523@defun.utah.edu>
Subject:  issue CONSTANT-CIRCULAR-COMPILATION, version 1

Perhaps there are multiple notions of constancy that should be
separated:

(defconstant foo '(a (b c) d) "doc" :list-structure) 

  This indicates there is a unique constant list structure, but the
  atoms at the leaves can be altered.
    legal:  (setf (car foo) 1)
  illegal:  (setf (cdr foo) '(x y)), (setf (cadr foo) '(x y))

  Given (defun foo1 () foo) and (defun foo2 () foo),
  (eq (foo1) (foo2)) must be true.

(defconstant foo '(a (b c) d) "doc" :atoms)

  This indicates that EQ properties of the list structure are
  irrelevant, as long as the atoms are retrieved as specified.
    illegal: (setf (car foo) 1)
    
  Given (defun foo1 () foo) and (defun foo2 () foo),
  (eq (foo1) (foo2)) may or may not be true.

etc.  

[The precise syntax is entirely ad hoc, and largely irrelevant.]


To me, this approach seems to have the same problems discussed earlier
wrt equality, but perhaps someone else can see how to separate the
notions of constant structure vs. constant components.

For example, maybe it makes sense to define a class of objects that
yield the composition/access/modification rules for other objects, and
to make EQUAL, DEFCONSTANT, etc. accept such template-defining
objects as arguments to be used to extract the rules for building
objects, recurring through them, and/or modifying them. 

In fact, maybe such objects could be included as part of the
evaluation and compilation environments.  Minor issues would deal with
the lossage anticipated if someone, e.g., altered the methods for
decomposition of CONS cells.  The cental issue is whether such rules 
for data structures form a natural kind that doesn't introduce
imponderable gray areas wrt composition of objects, classes, methods,
etc. 

  jlm


∂08-Nov-88  1125	CL-Compiler-mailer 	Re: issue CONSTANT-CIRCULAR-COMPILATION, version 1
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 8 Nov 88  11:25:36 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA28323; Tue, 8 Nov 88 12:24:14 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA04696; Tue, 8 Nov 88 12:24:07 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811081924.AA04696@defun.utah.edu>
Date: Tue, 8 Nov 88 12:24:06 MST
Subject: Re: issue CONSTANT-CIRCULAR-COMPILATION, version 1
To: Jim McDonald <jlm@lucid.com>
Cc: sandra%defun@cs, cperdue@Sun.COM, jonl@lucid.com, sandra%defun@cs,
        cl-compiler@sail.stanford.edu
In-Reply-To: Jim McDonald <jlm@lucid.com>, Tue, 8 Nov 88 11:02:49 PST

All this discussion on DEFCONSTANT is getting off the track and may be
confusing people about what the basic problems are.  The issues I sent
out yesterday are intended to deal with quoted or self-evaluating
objects, and I think it's more important to deal with this in general
than to just address the one special case of symbolic constants.

-Sandra
-------

∂08-Nov-88  1217	CL-Compiler-mailer 	Re:  issue CONSTANT-CIRCULAR-COMPILATION, version 1    
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 8 Nov 88  12:16:54 PST
Received: from snail.Sun.COM by Sun.COM (4.0/SMI-4.0)
	id AA15766; Tue, 8 Nov 88 12:13:49 PST
Received: from clam.sun.com by snail.Sun.COM (4.0/SMI-4.0)
	id AA28273; Tue, 8 Nov 88 12:15:54 PST
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA06258; Tue, 8 Nov 88 11:42:54 PST
Date: Tue, 8 Nov 88 11:42:54 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8811081942.AA06258@clam.sun.com>
To: cl-compiler@sail.stanford.edu, jlm@lucid.com
Subject: Re:  issue CONSTANT-CIRCULAR-COMPILATION, version 1

> Perhaps there are multiple notions of constancy that should be
> separated:

The idea that some construct "does license the compiler to build
assumptions about the value of into programs being compiled" (in
the discussion pp.68-69 on DEFCONSTANT),
appears to imply that the contents of it don't change.  Constant
folding and some other optimizations rely on this.  An example
that comes up in my practice is:

(defconstant kids '(bob cindy))

(defun relationship (x)
  . . .
  (if (member x kids) . . . )
  . . .
  )
  
One may wish to optimize this as though it were (or (eq x 'bob) (eq x 'cindy)).

For objects that may be changed, DEFPARAMETER has a whole set of
virtues:

o There is no implication that the compiler can build in assumptions,
  and no concern I know of that the data might be made readonly.
o There is no possible issue whether all references are guaranteed
  to be EQ.  They are definitely all EQ.
o It is possible for the value of a parameter to contain parts that
  are constants, and without extending the language the programmer
  has complete control over which parts are constant, by using QUOTE
  or references to named constants in the initialization form.

∂08-Nov-88  1246	CL-Compiler-mailer 	pending issue status
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 8 Nov 88  12:46:36 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA02006; Tue, 8 Nov 88 13:46:18 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA04751; Tue, 8 Nov 88 13:46:15 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811082046.AA04751@defun.utah.edu>
Date: Tue, 8 Nov 88 13:46:14 MST
Subject: pending issue status
To: cl-compiler@sail.stanford.edu

Here is a list of all (I think) pending compiler issues.  The ones
I've marked "ready for release" are the ones that didn't provoke any
discussion when the latest proposals were sent around.

Most of the others are waiting for somebody to submit revised
proposals.  If your name is on here, I'm expecting you to do something,
or at least tell me that you're not going to do anything.

I would still like to get a mail ballot out in December, but at this
point there are only four issues ready and I don't know whether it's
worth the trouble unless we can get a few more finished up within the
next week or so.

-Sandra



ALLOW-LOCAL-INLINE
    Almost ready, but need minor revisions to current writeup (Gray)

COMPILE-ENVIRONMENT-CONSISTENCY
    Ready for release?

COMPILE-FILE-ENVIRONMENT
    Superseded by issue SYNTACTIC-ENVIRONMENT-ACCESS?

COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
    Waiting for alternate proposal (Pierson, Haflich, Barrett, and Perdue)

COMPILER-DIAGNOSTICS
    Draft, waiting for comments from Pitman (Loosemore)

COMPILER-LET-CONFUSION
    Ready for release?

COMPILER-VERBOSITY
    Draft, waiting for alternate proposal from Pierson (Loosemore)

CONSTANT-ARRAY-ATTRIBUTES
    Draft

CONSTANT-CIRCULAR-COMPILATION
    Draft

CONSTANT-COLLAPSING
    Draft

CONSTANT-COMPILABLE-TYPES
    Draft

CONSTANT-MODIFICATION
    Draft

DEFCONSTANT-NOT-WIRED
    Waiting for revisions (Gray)

DEFCONSTANT-VALUE
    Waiting for resolution of issue DEFINING-MACROS-NON-TOP-LEVEL

DEFINE-OPTIMIZER
    Waiting for revisions (Pitman)

DEFINING-MACROS-NON-TOP-LEVEL
    Waiting for alternate proposal (Pierson, Haflich, Barrett, and Perdue)

EVAL-WHEN-NON-TOP-LEVEL
    Waiting for alternate proposal (Pierson, Haflich, Barrett, and Perdue)

LOAD-TIME-EVAL
    Ready for release?

PROCLAIM-ETC-IN-COMPILE-FILE
    Waiting for resolution of related cleanup issues (DEFPACKAGE,
    IN-PACKAGE-FUNCTIONALITY)

SHARP-COMMA-CONFUSION
    Ready for release?

SYNTACTIC-ENVIRONMENT-ACCESS
    Waiting for new writeup (Benson)

WITH-COMPILATION-UNIT
    Waiting for revisions to existing proposal (Pitman)

-------

∂08-Nov-88  1416	CL-Compiler-mailer 	Issue CONSTANT-COMPILABLE-TYPES    
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 8 Nov 88  14:16:29 PST
Received: from snail.Sun.COM by Sun.COM (4.0/SMI-4.0)
	id AA18494; Tue, 8 Nov 88 14:13:05 PST
Received: from lukasiewicz.sun.com by snail.Sun.COM (4.0/SMI-4.0)
	id AA03760; Tue, 8 Nov 88 14:15:41 PST
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
	id AA02581; Tue, 8 Nov 88 13:08:30 PST
Date: Tue, 8 Nov 88 13:08:30 PST
From: jrose@Sun.COM (John Rose)
Message-Id: <8811082108.AA02581@lukasiewicz.sun.com>
To: cperdue@Sun.COM
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Cris Perdue's message of Mon, 7 Nov 88 20:40:57 PST <8811080440.AA05593@clam.sun.com>
Subject: Issue CONSTANT-COMPILABLE-TYPES

Go Cris.  One observation:

   Package, Stream, Random-state
		It is an error for a package, stream, or random state
		to appear ina compiled constant, but the language may be
		extended in the future to support certain cases.

Random-states should be supported by the loader, because they must
be printed readably in any CL implementation.

I would say that there a serious design flaw in an object file format
whose encoding capability is not a strict superset of the reader's.
That is, if you can print something readably, you should also
be able to dump it loadably.  Does anyone see any problems with
this principle?

(Should there be a *DUMP-CIRCLE* mode variable?  Something to consider.)

				-- John

∂08-Nov-88  1447	CL-Compiler-mailer 	Issue CONSTANT-COMPILABLE-TYPES    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 8 Nov 88  14:47:51 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01829g; Tue, 8 Nov 88 14:46:43 PST
Received: by bhopal id AA02259g; Tue, 8 Nov 88 14:45:24 PST
Date: Tue, 8 Nov 88 14:45:24 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811082245.AA02259@bhopal>
To: cperdue@Sun.COM
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Cris Perdue's message of Mon, 7 Nov 88 20:40:57 PST <8811080440.AA05593@clam.sun.com>
Subject: Issue CONSTANT-COMPILABLE-TYPES

This seems like a step in the right direction to "codify existing
practice" for COMPILE-FILE's treatment of constants.  Since there is
still the issue of interpreter/compiler consistency, and since this
issue is long and historic, then the final issue should be passed
through the cleanup committee.

As I mentioned before, in response to Sandra's msg, I would strongly urge
  (1) the acceptability of every data type that can reasonable be
      re-created -- meaning just about everything except streams and
      possibly "weird" class instances;  
  (2) full inclusion of all hashtable attributes -- not just the keys
      and values -- or, at least rehash-threshold and rehash-size;
  (3) an explicit statement that circularity is ok;
  (4) a statement that symbols and packages are referred to "by name",
      and that no components are put into the compiled file (at least,
      not merely for a "constant" reference.)

Some implementations can even re-create streams ok; Interlisp-D,
when used with capable file-servers _could_ do that -- namely, it
could re-open access to a file, providing the same version still
existed.  Thus the proposal ought to say that "it is undefined"
rather than "it is an error" on these types, so that agressive
implementations can extend here.

You almost said point (4) for symbols; I think it should also be said
for packages.  I know that this is just a bit beyond the widespread
practice (packages, hashtables, and circular structures), but Lucid's
3.0 release does them all, and it wouldn't be surprising to find out
that some other implementation does some of them.  It's not that hard.


-- JonL --

∂08-Nov-88  1453	CL-Compiler-mailer 	Re: Issue CONSTANT-COMPILABLE-TYPES
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 8 Nov 88  14:52:51 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA06488; Tue, 8 Nov 88 15:52:07 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA04879; Tue, 8 Nov 88 15:51:58 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811082251.AA04879@defun.utah.edu>
Date: Tue, 8 Nov 88 15:51:57 MST
Subject: Re: Issue CONSTANT-COMPILABLE-TYPES
To: jrose@Sun.COM (John Rose)
Cc: cperdue@Sun.COM, cl-compiler@sail.stanford.edu
In-Reply-To: jrose@Sun.COM (John Rose), Tue, 8 Nov 88 13:08:30 PST

> Date: Tue, 8 Nov 88 13:08:30 PST
> From: jrose@Sun.COM (John Rose)
> 
> Random-states should be supported by the loader, because they must
> be printed readably in any CL implementation.
> 
> I would say that there a serious design flaw in an object file format
> whose encoding capability is not a strict superset of the reader's.
> That is, if you can print something readably, you should also
> be able to dump it loadably.  Does anyone see any problems with
> this principle?

That's pretty much what I was trying to establish in my original
proposal.  Most of the problems with compiling constants are specific
to COMPILE-FILE, which is a file transducer.  I like to think of the
simplest possible file compiler as something that reads in code, does
a code walk to perform macroexpansion and possibly some other kinds of
processing, and prints out the resulting forms to the output file.
(Obviously, it isn't quite practical to use PRINT because of the
problems with printing arrays, but it's still a useful model.)

-Sandra
-------

∂08-Nov-88  1503	CL-Compiler-mailer 	issue CONSTANT-CIRCULAR-COMPILATION, version 1    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 8 Nov 88  15:03:11 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01843g; Tue, 8 Nov 88 15:01:45 PST
Received: by bhopal id AA02312g; Tue, 8 Nov 88 15:00:26 PST
Date: Tue, 8 Nov 88 15:00:26 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811082300.AA02312@bhopal>
To: cperdue@Sun.COM
Cc: sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu
In-Reply-To: Cris Perdue's message of Mon, 7 Nov 88 21:38:38 PST <8811080538.AA05650@clam.sun.com>
Subject:  issue CONSTANT-CIRCULAR-COMPILATION, version 1

re: My expectation has always been that compiling a named constant
    fooey would be equivalent to compiling a macro invocation, such
    as (uck), where:

    (defmacro uck ()
      `',fooey)

    In other words, the value of the named constant would be treated
    the same as a quoted expression containing the compiletime value
    of the constant.

    Do others share this conception, or do you just consider it
    my mistake, or what?


Indeed, you have a misconception about what CLtL requires of symbolic
constants; but it's one that many other share, and quite naturally so
I think.  CLtL p.68 is rather explicit about DEFCONSTANT being like
defparameter, but providing some hidden assertion to the compiler
about constancy; and most implementations I've looked at simply compile
a reference to the constant as a symbol-value fetch.  Lucid's one
wrinkle is that it "folds" some constants depending on the datatype
of the constant value.

In my replies to David Gray's proposals about constants ("wired" or
not -- I don't remember) I pointed out that I dislike the current
implementations (Lucid's included), and would prefer that the next
standard make it clear that constant values are "snapped" at compile
time rather than indirecting through the symbol-value cell at runtime.
I know this provides yet another little wedge between interpreted code
and compiled code, but the common semantics of "compile time constants"
in other computer languages seems preferable.  It is those semantics
that most people assume; hence the 'misconception'.


-- JonL --

∂08-Nov-88  1525	CL-Compiler-mailer 	Re: Issue CONSTANT-COMPILABLE-TYPES
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 8 Nov 88  15:25:45 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA07504; Tue, 8 Nov 88 16:24:43 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA04944; Tue, 8 Nov 88 16:24:36 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811082324.AA04944@defun.utah.edu>
Date: Tue, 8 Nov 88 16:24:34 MST
Subject: Re: Issue CONSTANT-COMPILABLE-TYPES
To: Jon L White <jonl@lucid.com>
Cc: cperdue@Sun.COM, cl-compiler@sail.stanford.edu
In-Reply-To: Jon L White <jonl@lucid.com>, Tue, 8 Nov 88 14:45:24 PST

> Date: Tue, 8 Nov 88 14:45:24 PST
> From: Jon L White <jonl@lucid.com>
> 
> This seems like a step in the right direction to "codify existing
> practice" for COMPILE-FILE's treatment of constants.
> 
> 
> As I mentioned before, in response to Sandra's msg, I would strongly urge
>   (1) the acceptability of every data type that can reasonable be
>       re-created -- meaning just about everything except streams and
>       possibly "weird" class instances;  
>   (2) full inclusion of all hashtable attributes -- not just the keys
>       and values -- or, at least rehash-threshold and rehash-size;
>   (3) an explicit statement that circularity is ok;
>   (4) a statement that symbols and packages are referred to "by name",
>       and that no components are put into the compiled file (at least,
>       not merely for a "constant" reference.)

Unfortunately, I'm not convinced that this really represents "existing
practice".  Lucid may try to do all of this, but other implementations
apparently do not.  The cost to implementors cannot be ignored here,
because the changes may require substantial modifications to the
compiler/loader interface.

The idea of compiling constant package objects "by name" is not
particularly objectionable to me, but it needs to be made more
specific.  Would it be necessary for the compiler to preserve
attributes such as the use-list, even if it doesn't preserve all the
symbols that are in the package? 

How would you deal with the problem of collapsing EQUAL keys in EQ and
EQL hash tables that I mentioned in my original proposal?

And, I'm not sure that compiling constant function objects could be
made to work properly in every implementation.  Besides the problem of
cross-compilation I mentioned before, some implementations can't
un-load compiled functions -- for example, because the relocation
information has been thrown away, or because the functions were
written in C or machine language in the first place.

-Sandra
-------

∂08-Nov-88  1534	CL-Compiler-mailer 	issue CONSTANT-CIRCULAR-COMPILATION, version 1    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 8 Nov 88  15:34:12 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01889g; Tue, 8 Nov 88 15:32:56 PST
Received: by bhopal id AA02428g; Tue, 8 Nov 88 15:31:36 PST
Date: Tue, 8 Nov 88 15:31:36 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811082331.AA02428@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cperdue@Sun.COM, sandra%defun@cs, cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 8 Nov 88 08:26:10 MST <8811081526.AA04523@defun.utah.edu>
Subject:  issue CONSTANT-CIRCULAR-COMPILATION, version 1

re: I wonder how many programs would break if we only required
    defconstants always to be isomorphic, instead of EQL?

About the same number that would be broken if we defined QUOTE as per
my "unifying" proposal -- namely that any evaluation of a QUOTE form
is allowed to return an "equivalent" copy of the datum.

-- JonL --

P.S.: The "unifying" refers to unifying the treatment of constants by
      both compiler and interpreter.

∂08-Nov-88  1537	CL-Compiler-mailer 	Print/Read and the compiler   
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Nov 88  15:37:01 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Tue, 8 Nov 88 15:30:19 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 293252; Tue 8-Nov-88 18:36:43 EST
Date: Tue, 8 Nov 88 18:36 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: Print/Read and the compiler
To: CL-Compiler@sail.stanford.edu
Message-Id: <881108183643.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

I wish to register my very strong objection to the notion that we start
limiting what can be QUOTE'd or COMPILE'd based on what can be written
to files.

I'm not looking at any particular proposal as I write this -- this is
just stream of consciousness response to a bunch of mail I saw in the
last few days that I've not had time to attend to in detail. But I have
a lot of other things to attend to and I don't want anyone saying that
just because I haven't replied more specifically that no one has
objected to this stuff in concept.

The issue of file compilation is inherently limited in some obvious ways
that it's good we try to make clear. However, the function COMPILE is
not thusly limited and I have written a substantial number of useful
programs in which COMPILE is done on quoted constants which are circular,
or are odd data types for which there is no print/read capability. In all
cases, these are (a) serious applications and (b) applications for which
it is not important to me to be able to get file compilation.

As such, I don't mind the file compiler getting these restrictions -- I
even encourage it, but I absolutely do not want COMPILE to be similarly
restricted.

Further, I think such a change will introduce serious incompatibility
and should be labeled as such. There is currently nothing even the slightest
bit illegal about doing
 (FUNCALL (COMPILE NIL '(LAMBDA () ',ANYTHING)))
You're proposing to change that, and I assert that there are programs
which will be broken by the capricious nature of the change.

I'm also worried that this is yet another fundamental change in the 
character of the language with consequences that reach beyond the simple
fact of the change. It's a move away from the idea of the `object'
being king, and toward the idea that the printed representation of the
object is all that counts. This is a very bad trend in that it involves
the elimination of yet another feature which makes Lisp interestingly
unique.

Finally, there is a relationship between all of this issue of print/read
and the issue which we just voted in about self-evaluation. It is currently
permissible to do 
  (EVAL `(DEFUN FOO () ,(MAKE-RANDOM-STATE)))
yet you are saying that it will not be legal to do 
  (EVAL `(DEFUN FOO () ',(MAKE-RANDOM-STATE)))
This is exceedingly random, so you need to reconsider the consistency
issue. The primary stated purpose of QUOTE is to inhibit evaluation, so
yet another constraint you need to consider is that you must be able to
QUOTE anything you can EVAL.

Further, you are severely limiting the effectiveness of #. and #n=.
Consider that '#1=(A . #1#) will be pretty useless as read syntax
since you won't be premitted to use it, except in calls to READ.
Apparently it's permitted for output, but near useless for input
(except in data files) since neither circular forms nor circular
quoted expressions are to be permitted. If we're going to make #n=
near-useless, we might as well buckle in to those like Dick Waters
who think that the lookahead for #1= is a pain in printing and would
prefer we just notate the item when we actually run across the
repeat ... that makes it a pain for the reader, but since we're making
the reader's facility nearly useless, that doesn't seem so bad...

I didn't see discussion of #, in all this. Is '(#,X) excepted from
the QUOTE rules? Again this is easy to explain if you distinguish
between file compilation and other environments, but it's not so easy
otherwise. Perhaps you've written off #, already, but since that
issues not been voted in, you're making a dangerous relationship there.

You're also, curiously, talking about destroying the relationship
between unevaluted read and EVAL of quoted read. It will no longer be
true, in general, that
 (PRINT (READ)) is equivalent to (PRINT (EVAL `',(READ)))
for example, since the there are holes in the latter. I think people
think of (EVAL (QUOTE x)) == x as a sort of fundamental identity, so
I think that's a non-trivial change.

And you're not addressing the issue of that in compiled-only 
implementations, (COMPILE NIL '(LAMBDA () x)) == (EVAL x), so any
constraint on COMPILE is an effective constraint on EVAL.

Bottom line: Start distinguishing between file compilation and in-core
compilation on these issues, or brace yourself for a very major fight.

∂08-Nov-88  1540	CL-Compiler-mailer 	issue CONSTANT-CIRCULAR-COMPILATION, version 1    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 8 Nov 88  15:40:10 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01897g; Tue, 8 Nov 88 15:38:51 PST
Received: by bhopal id AA02459g; Tue, 8 Nov 88 15:37:27 PST
Date: Tue, 8 Nov 88 15:37:27 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811082337.AA02459@bhopal>
To: Gray@DSG.csc.ti.com
Cc: sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu
In-Reply-To: David N Gray's message of Tue, 8 Nov 88  10:43:16 CST <2803999396-5038883@Kelvin>
Subject: issue CONSTANT-CIRCULAR-COMPILATION, version 1

re: > Furthermore, the phraseology about DEFCONSTANT (CLtL, p69)
    > explicitly requires preservation ofEQLness of constants,

    But that is talking about DEFCONSTANT values and really has nothing to do
    with QUOTE forms.  

While that is true, it is indeed bizarre that "constants" produced
by QUOTE have one semantics, and those produced by "symbolic constants"
have another.  I hope we can reduce it to a single statement.  Specifying
that "symbolic constants" should act like "compile-time constants" of other
languages means that your test case:

  (DEFCONSTANT V (LIST (FOO) (BAR)))

would be treated more-or-less as if it had been written:

  (DEFCONSTANT V '#.(LIST (FOO) (BAR)))

[but #. is not quite the right evaluation time, of course].

-- JonL --

∂08-Nov-88  2301	CL-Compiler-mailer 	Issue CONSTANT-COMPILABLE-TYPES    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 8 Nov 88  23:01:16 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02205g; Tue, 8 Nov 88 23:00:01 PST
Received: by bhopal id AA03462g; Tue, 8 Nov 88 22:58:41 PST
Date: Tue, 8 Nov 88 22:58:41 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811090658.AA03462@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cperdue@Sun.COM, cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 8 Nov 88 16:24:34 MST <8811082324.AA04944@defun.utah.edu>
Subject: Issue CONSTANT-COMPILABLE-TYPES

re: ["fasdmp" should handle just about all datatypes] ...  Unfortunately, 
    I'm not convinced that this really represents "existing practice".  

Agreed.  But I think many implementors would like to see all
datatypes handled, and have only omitted the full development for
lack of certainty that this is a worthy problem.  As John Rose put
it, the file-compiler shouldn't be less featureful than the PRINTer!


re: The idea of compiling constant package objects "by name" is not
    particularly objectionable to me, but it needs to be made more
    specific. 

My proposal, as stated before, is that _nothing_ be output except
the name, by which to reference the package.  After all, compiling
(QUOTE FOO) doesn't try to restore the property list of FOO.


re: How would you deal with the problem of collapsing EQUAL keys in EQ and
    EQL hash tables that I mentioned in my original proposal?

Frankly, I hadn't thought about this lossage.  Thanks for bringing it
up.  Two responses come to mind: 
       (1) "it is an error"; maybe compile-file could even signal
           an error when it detects this situation.
       (2) declare it a feature -- that the re-created hash-table may
           have fewer entries due to constant coalescing.


re: And, I'm not sure that compiling constant function objects could be
    made to work properly in every implementation.  

Well then, what the heck does DEFUN require?  doesn't the compiler 
produce a "constant function" for the faslout process to put in the
compiled file? ["constant function" in our sense, not in that of Chris 
Eliot in his proposal for more compiler declarations.]  


re: . . . some implementations can't
    un-load compiled functions -- for example, because the relocation
    information has been thrown away, or because the functions were
    written in C or machine language in the first place.

So, VAX/NIL couldn't "unload" anything.  You only GC when you have
to, and many implementations have found that GC'ing compiled functions
isn't high on their priority queue.  At any rate, you only create
"garbage" in constants space when you redefine some named "constant" --
for example, redefining (DEFUN FOO () (BAR "ABZ")) _may_ cause the string
"ABZ" to become garbage, along with the old code vector for #'FOO.


-- JonL --


P.S.: Regarding GC'ing only when you have to, see the "GC Considered Harmful"
      article in Lisp Pointers, Vol 1 No 3, Aug 1987.

∂09-Nov-88  0930	CL-Compiler-mailer 	Re: Issue CONSTANT-COMPILABLE-TYPES
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 9 Nov 88  09:30:48 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA25347; Wed, 9 Nov 88 10:29:37 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA05479; Wed, 9 Nov 88 10:29:32 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811091729.AA05479@defun.utah.edu>
Date: Wed, 9 Nov 88 10:29:31 MST
Subject: Re: Issue CONSTANT-COMPILABLE-TYPES
To: Jon L White <jonl@lucid.com>
Cc: sandra%defun@cs, cperdue@Sun.COM, cl-compiler@sail.stanford.edu
In-Reply-To: Jon L White <jonl@lucid.com>, Tue, 8 Nov 88 22:58:41 PST


> Date: Tue, 8 Nov 88 22:58:41 PST
> From: Jon L White <jonl@lucid.com>
> 
> re: . . . some implementations can't
>     un-load compiled functions -- for example, because the relocation
>     information has been thrown away, or because the functions were
>     written in C or machine language in the first place.
> 
> So, VAX/NIL couldn't "unload" anything.  You only GC when you have
> to, and many implementations have found that GC'ing compiled functions
> isn't high on their priority queue. [...]

I think you've misunderstood my use of the term "un-load".  I was
using it in the sense of "the opposite of what the loader does", which
is only vaguely related to garbage collection issues.  The point I was
trying to make is that some implementations view compiled functions
which exist in the current runtime environment as just a bunch of bits
(whose length may not even be known), and it may not be possible to
write them out to the FASL file in such a way that the loader can
correctly reconstruct the function when the FASL file is loaded.  To
me, the issue of what COMPILE-FILE does with a quoted function
constant is distinct from what it does with the FUNCTION special form. 

-Sandra
-------

∂09-Nov-88  0947	CL-Compiler-mailer 	Re: Print/Read and the compiler    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 9 Nov 88  09:46:53 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA26109; Wed, 9 Nov 88 10:46:30 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA05501; Wed, 9 Nov 88 10:46:10 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811091746.AA05501@defun.utah.edu>
Date: Wed, 9 Nov 88 10:46:09 MST
Subject: Re: Print/Read and the compiler
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, 8 Nov 88 18:36 EST

> Date: Tue, 8 Nov 88 18:36 EST
> From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
> 
> Bottom line: Start distinguishing between file compilation and in-core
> compilation on these issues, or brace yourself for a very major fight.

I don't think that the distinction is as clear-cut as you would make
it.  I know of at least one implementation (KCL) in which COMPILE is
implemented using COMPILE-FILE.  (It prints out the definition of the
function you want to COMPILE to a temporary file, runs the file
through COMPILE-FILE, and loads the result.)  To me, this seems like a
perfectly legitimate implementation technique; are you proposing that
it be disallowed?

There is obviously tremendous variation between what implementations
do with compiled constants.  The intent of my original set of
proposals was to try to legitimize existing practice, rather than to
start religious wars about the "right" way for a compiler to behave.
While I agree that it would be nice to offer users more promises about
what kinds of constant objects can be compiled portably, doing so
would require some implementations to rethink their entire compilation
strategy. 

-Sandra
-------

∂09-Nov-88  1005	CL-Compiler-mailer 	Re: issue CONSTANT-COMPILABLE-TYPES, version 1    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 9 Nov 88  10:04:54 PST
Received: by ti.com id AA12209; Wed, 9 Nov 88 12:04:27 CST
Received: from Kelvin by tilde id AA16263; Wed, 9 Nov 88 11:57:09 CST
Message-Id: <2804090353-186829@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 9 Nov 88  11:59:13 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 CONSTANT-COMPILABLE-TYPES, version 1
In-Reply-To: Msg of Mon, 7 Nov 88 13:53:37 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)

> Proposal CONSTANT-COMPILABLE-TYPES:LIKE-PRINT:
>
> Clarify that it is valid for an object to appear as a constant to be
> compiled if it is also required to have a printed representation that
> can be read back in by the function READ.

Good, but I agree with Pitman that this should specify that it is only
talking about COMPILE-FILE, not COMPILE.

> Rationale:
> 
> The list of types that are explicitly not required to have readable
> printed representations (currently) includes HASH-TABLE, READTABLE,
> PACKAGE, STREAM, and FUNCTION.

Also STANDARD-OBJECT.  I wonder if it would be useful to specify a
generic function for which users could write methods that would define
how to re-construct the object when the file is loaded?  We currently
have a capability like that for flavors.

> Current Practice:

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.

∂09-Nov-88  1241	CL-Compiler-mailer 	Re: Print/Read and the compiler    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Nov 88  12:41:18 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 489984; Wed 9-Nov-88 15:41:11 EST
Date: Wed, 9 Nov 88 15:40 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Print/Read and the compiler
To: sandra%defun@cs.utah.edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Compiler@sail.stanford.edu
In-Reply-To: <8811091746.AA05501@defun.utah.edu>
Message-ID: <881109154050.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

KCL could still use the same technique but with some slight modifications:

 (1) Do macroexpansion in-core, before writing the request file for the
     file compiler. Maybe they do that anyway; I can't imagine how else
     they could get the file compiler's macroexpansion environment correct.

 (2) Do a trivial code-walk of the fully macroexpanded code to find 
     (QUOTE ...) and cache the objects being quoted in a special array,
     and convert (QUOTE ...) to (LOAD-TIME-VALUE (AREF SI:*QUOTE-ARRAY* n)).

 (3) See to it that SI:*QUOTE-ARRAY* is bound properly during the call to
     LOAD of the file compiler's output.

The point is that the special case of file-compile for the sake of COMPILE
has the additional useful constraint that every object which was present in
the environment at the time the file is compiled will be present and findable
at LOAD time.

The problem that makes file-compile intractable in the general case which
your proposals seem to address is that you may have to `re-link' the object
code in an environment (read: process / job / fork / core image) which is
in fact not the same one as was active when the file compilation was done.
So, for example, the bindings of variables/etc may have changed, some objects
may have been moved, some objects may have been modified, or some objects
may not exist. COMPILE, regardless of whether it is implemented with 
compile-file because it can take advantage of the inherent relaxation of such
constraints.

∂09-Nov-88  1355	CL-Compiler-mailer 	Issue CONSTANT-COMPILABLE-TYPES    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 9 Nov 88  13:55:14 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02705g; Wed, 9 Nov 88 13:53:55 PST
Received: by bhopal id AA04612g; Wed, 9 Nov 88 13:52:34 PST
Date: Wed, 9 Nov 88 13:52:34 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811092152.AA04612@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cperdue@Sun.COM, cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Wed, 9 Nov 88 10:29:31 MST <8811091729.AA05479@defun.utah.edu>
Subject: Issue CONSTANT-COMPILABLE-TYPES

re: ... that some implementations view compiled functions
    which exist in the current runtime environment as just a bunch of bits
    (whose length may not even be known), and it may not be possible to
    write them out to the FASL file in such a way that the loader can
    correctly reconstruct the function when the FASL file is loaded.  To
    me, the issue of what COMPILE-FILE does with a quoted function
    constant is distinct from what it does with the FUNCTION special form. 

Ooops, I did misunderstand you (I must have been "jumping" to the other 
well-known problem involved in re-loading compiled files).  So I see
your point.  At least by "Rose's Rule", we could elide functions since
there isn't a specified print format for them.

Incidentally, LISP/370 did have a full print format for compiled funtions; 
they worked harder than most to ensure that interpreted and compiled 
execution worked the same.  Lucid doesn't have a PRINT format for functions,
but has no trouble "fasdmping" them.  I suspect that it wouldn't really be 
that hard to write the "fasdmping" code for most CL implementations today.

Two points can be made in support of giving functions full "first class"
status, even when cross-compiling and "cross" loading:
  (1) there is no inherent problem of machine-instruction mismatch, since 
      merely loading something does not mean that it will be executed; a 
      program may "manipulate" it just like any other datum;
  (2) some implementations have considered a machine-independent "byte-code"
      as a reasonable format for "functions"; in fact, Xerox/Envos Common
      Lisp still uses the byte-code  originally developed for the Dorado, 
      even on the 68020 and SPARC Sun workstations.


-- JonL --

∂09-Nov-88  1410	CL-Compiler-mailer 	Re: Issue CONSTANT-COMPILABLE-TYPES
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 9 Nov 88  14:08:21 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA05989; Wed, 9 Nov 88 15:03:42 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA05715; Wed, 9 Nov 88 15:03:27 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811092203.AA05715@defun.utah.edu>
Date: Wed, 9 Nov 88 15:03:25 MST
Subject: Re: Issue CONSTANT-COMPILABLE-TYPES
To: Jon L White <jonl@lucid.com>
Cc: sandra%defun@cs, cperdue@Sun.COM, cl-compiler@sail.stanford.edu
In-Reply-To: Jon L White <jonl@lucid.com>, Wed, 9 Nov 88 13:52:34 PST

I don't want to prohibit implementations from correctly compiling quoted
functions and other such objects, if they know how to do so correctly.  I
just think we should recognize that some implementations cannot do so.

-Sandra
-------

∂09-Nov-88  1418	CL-Compiler-mailer 	Re: Print/Read and the compiler    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 9 Nov 88  14:18:32 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA06302; Wed, 9 Nov 88 15:17:52 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA05736; Wed, 9 Nov 88 15:17:28 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811092217.AA05736@defun.utah.edu>
Date: Wed, 9 Nov 88 15:17:27 MST
Subject: Re: Print/Read and the compiler
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: sandra%defun@cs, KMP@STONY-BROOK.SCRC.Symbolics.COM,
        CL-Compiler@sail.stanford.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 9 Nov 88 15:40 EST

> Date: Wed, 9 Nov 88 15:40 EST
> From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
> 
>  (1) Do macroexpansion in-core, before writing the request file for the
>      file compiler. Maybe they do that anyway; I can't imagine how else
>      they could get the file compiler's macroexpansion environment correct.

I believe KCL (like a number of other implementations) has the file
compiler inherit macro definitions present in the runtime environment
from which it is invoked, and that it does not do a code walk before
writing out the function.  I don't have KCL installed here so I can't be
100% positive about this, though.

Incidentally, in PSL/PCLS, COMPILE always copies quoted constants to
read-only memory, even though it is not implemented using COMPILE-FILE.

-Sandra
-------

∂09-Nov-88  1508	CL-Compiler-mailer 	Re: Print/Read and the compiler    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 9 Nov 88  15:08:30 PST
Received: by ti.com id AA14388; Wed, 9 Nov 88 17:07:11 CST
Received: from Kelvin by tilde id AA23227; Wed, 9 Nov 88 16:49:17 CST
Message-Id: <2804107894-1240732@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 9 Nov 88  16:51:34 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: CL-Compiler@sail.stanford.edu
Subject: Re: Print/Read and the compiler
In-Reply-To: Msg of Tue, 8 Nov 88 18:36 EST from Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>

> Further, you are severely limiting the effectiveness of #. and #n=.
> Consider that '#1=(A . #1#) will be pretty useless as read syntax
> since you won't be premitted to use it, except in calls to READ.
> Apparently it's permitted for output, but near useless for input
> (except in data files) ...

I would have thought that it was data files that the #n= notation was
primarily useful for.  I can't recall seeing anyone use it in source
code.

> I didn't see discussion of #, in all this. Is '(#,X) excepted from
> the QUOTE rules? Again this is easy to explain if you distinguish
> between file compilation and other environments, but it's not so easy
> otherwise. Perhaps you've written off #, already, but since that
> issues not been voted in, you're making a dangerous relationship there.

Hopefully we'll adopt proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
so that #, will no longer be connected with QUOTE.  Otherwise, yes, we
would have to point out that QUOTE forms containing #, are not really
constants.

∂09-Nov-88  1521	CL-Compiler-mailer 	Re: Issue CONSTANT-COMPILABLE-TYPES
Received: from ti.com by SAIL.Stanford.EDU with TCP; 9 Nov 88  15:20:49 PST
Received: by ti.com id AA14460; Wed, 9 Nov 88 17:19:19 CST
Received: from Kelvin by tilde id AA23554; Wed, 9 Nov 88 17:08:46 CST
Message-Id: <2804109064-1311014@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 9 Nov 88  17:11:04 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@lucid.com>
Cc: sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu
Subject: Re: Issue CONSTANT-COMPILABLE-TYPES
In-Reply-To: Msg of Tue, 8 Nov 88 22:58:41 PST from Jon L White <jonl@lucid.com>

> Well then, what the heck does DEFUN require?  doesn't the compiler 
> produce a "constant function" for the faslout process to put in the
> compiled file?

Not necessarily.  While our compiler _can_ dump function objects, the
normal processing of DEFUN by COMPILE-FILE writes the code directly to
the object file without ever materializing the function object in
memory.

∂09-Nov-88  1538	CL-Compiler-mailer 	Re: issue CONSTANT-CIRCULAR-COMPILATION, version 1
Received: from ti.com by SAIL.Stanford.EDU with TCP; 9 Nov 88  15:38:38 PST
Received: by ti.com id AA14571; Wed, 9 Nov 88 17:34:49 CST
Received: from Kelvin by tilde id AA24047; Wed, 9 Nov 88 17:30:18 CST
Message-Id: <2804110351-1388307@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 9 Nov 88  17:32:31 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@lucid.com>
Cc: sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu
Subject: Re: issue CONSTANT-CIRCULAR-COMPILATION, version 1
In-Reply-To: Msg of Tue, 8 Nov 88 15:37:27 PST from Jon L White <jonl@lucid.com>

> Date: Tue, 8 Nov 88 15:37:27 PST
> From: Jon L White <jonl@lucid.com>
> Subject: issue CONSTANT-CIRCULAR-COMPILATION, version 1
> 
> re: > Furthermore, the phraseology about DEFCONSTANT (CLtL, p69)
>     > explicitly requires preservation ofEQLness of constants,
> 
>     But that is talking about DEFCONSTANT values and really has nothing to do
>     with QUOTE forms.  
> 
> While that is true, it is indeed bizarre that "constants" produced
> by QUOTE have one semantics, and those produced by "symbolic constants"
> have another.  I hope we can reduce it to a single statement. 

I guess I'm confused about what your point is.  The statement at the top
of page 69 is saying that two uses of a constant name should return the
same (ie EQL) object.  But ordinary QUOTE forms don't have names, so
they can't be referenced more than once anyway.  If anything, this goes
along with the permission to coalesce EQUAL constants by saying that it
is not permissible to do the opposite -- that is, to make duplicate
copies of the same constant.

I do agree that the same rules about not mutating constants should apply
to both QUOTE forms and DEFCONSTANT values.

∂09-Nov-88  1549	CL-Compiler-mailer 	Re: Print/Read and the compiler    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 9 Nov 88  15:48:51 PST
Received: by ti.com id AA14562; Wed, 9 Nov 88 17:34:37 CST
Received: from Kelvin by tilde id AA23850; Wed, 9 Nov 88 17:21:20 CST
Message-Id: <2804109815-1356120@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 9 Nov 88  17:23:35 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Cc: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>,
        CL-Compiler@sail.stanford.edu
Subject: Re: Print/Read and the compiler
In-Reply-To: Msg of Wed, 9 Nov 88 10:46:09 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)

> I don't think that the distinction is as clear-cut as you would make
> it.  I know of at least one implementation (KCL) in which COMPILE is
> implemented using COMPILE-FILE.  (It prints out the definition of the
> function you want to COMPILE to a temporary file, runs the file
> through COMPILE-FILE, and loads the result.)  To me, this seems like a
> perfectly legitimate implementation technique; are you proposing that
> it be disallowed?

This may just be my prejudice, but just off hand, this strikes me as
being an implementation short-cut that would not be used anyway on a
serious commercial implementation.  I would imagine that an
implementation that used a short-cut like this would probably not be
fully standard-conforming in many other ways.

∂09-Nov-88  1649	CL-Compiler-mailer 	Re: Issue ALLOW-LOCAL-INLINE (V2)  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 9 Nov 88  16:49:41 PST
Received: by ti.com id AA15053; Wed, 9 Nov 88 18:49:24 CST
Received: from Kelvin by tilde id AA25235; Wed, 9 Nov 88 18:33:07 CST
Message-Id: <2804114112-1614282@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 9 Nov 88  18:35:12 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Rob.MacLachlan@WB1.CS.CMU.EDU
Cc: CL-Compiler@SAIL.Stanford.edu
Subject: Re: Issue ALLOW-LOCAL-INLINE (V2) 
In-Reply-To: Msg of Fri, 28 Oct 88 11:39:42 EDT from Rob.MacLachlan@WB1.CS.CMU.EDU

> One problem with the inline-notinline idiom is that NOTINLINE has evolved
> in the direction of a declaration that tells the compiler "assume nothing
> about this function".

Yes, this is a very good point, that NOTINLINE might be doing more than
undoing an INLINE.

> NOTINLINE would certainly suppress block-compiled call, and would probably
> suppress compiler warnings about the argument signature used in calls, etc.

CLtL doesn't say anything about this; I wonder if the specification of
NOTINLINE needs some clarification?

> A programmer who just wants to note the inline expansion and not use it
> right away shouldn't be forced to suppress standard compilation on the
> calls that aren't inline-expanded.

Right.

> In fact, I think that there is a reasonable argument that NOTINLINE should
> cause the compiler to *forget* any recorded inline expansion.

But that would mean that NOTINLINE would be totally pervasive and could
not be shadowed by a local INLINE, which would seem inconsistent with
other kinds of declarations.

>    Assuming
> that a previously seen definition is in fact the correct definition seems
> to be making a pretty strong assumption about that function.

Yes, but if the user says (DECLARE (INLINE ...)), isn't that what he
wants?

> It is because of of this continuum of levels of "assumption about a
> function" that I proposed the INTEGRATION-LEVEL declaration to subsume
> INLINE and NOTINLINE.  The idea was that NOTINLINE = 0 and INLINE = 3, and
> any value > 0 allowed the compiler to assume that any seen definition is
> the true definition, but what use it made of this information was up to it.
> For example,
>     (proclaim '(integration-level 2 foo))
> 
> could cause the expansion to be recorded without causing inline expansion
> to be done.
> 
> To go along with this, there was the notion of the default integration
> level, which was initially 1 and could be modified by a proclamation.
> 
> This isn't exactly what I proposed before, and I think that this proposal
> might also benfit from modification.  In particular, it isn't clear that it
> is really appropriate or useful to use integers to represent the
> integration level (although it does make sense to have an ordering on the
> values).  An alternative would be to use some small set of keywords such as
> :NEVER, :DEFAULT, :RECORD and :INLINE.

I could go for something along these lines, but I'm afraid it is a
little too late to get it in the standard now.

∂09-Nov-88  1705	CL-Compiler-mailer 	Issue ALLOW-LOCAL-INLINE (V3) 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 9 Nov 88  17:05:04 PST
Received: by ti.com id AA15155; Wed, 9 Nov 88 19:05:12 CST
Received: from Kelvin by tilde id AA25655; Wed, 9 Nov 88 18:49:45 CST
Message-Id: <2804115121-1674908@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 9 Nov 88  18:52:01 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Compiler@SAIL.Stanford.edu
Subject: Issue ALLOW-LOCAL-INLINE (V3)

This proposal is the same as last time, but I have added some text from
Sandra to the problem description and extended the discussion section
with a summary of the points raised by Rob.  His comments could justify
reviving the ALLOW-LOCAL-INLINE:PROCLAIM-ALLOW-INLINE proposal; I'd
like to hear if those who didn't like it have changed their minds.  In
the meantime, I'm sticking with the minimal proposal.


Issue:		ALLOW-LOCAL-INLINE
References:	CLtL p. 156, 159
Related issues: PROCLAIM-INLINE-WHERE
Category:	CLARIFICATION
Edit History:   21 Sept. 88 V1 by David Gray
                27 Oct.  88 V2 by David Gray - new proposal
		 9 Nov.  88 V3 by David Gray - expanded problem
			description and discussion sections.
 
Problem Description:

  The proposal PROCLAIM-INLINE-WHERE:BEFORE (which was accepted by X3J13
  on 10/12/88) clarifies the use of INLINE proclamations, but there
  remains a similar problem with the use of a local (DECLARE (INLINE
  ...)):  how can the compiler expand the function inline if it didn't
  know that the necessary information should have been saved when the
  function was compiled?

  Note that an INLINE proclamation does two things:

    (1) It tells the compiler to do extra things when it sees the
        function -definition-, to make it possible to code the function
	inline.

    (2) It tells the compiler to code -calls- to the function inline.

  In order for local INLINE declarations to be useful, we need part 1
  without part 2.
 
Proposal ALLOW-LOCAL-INLINE:INLINE-NOTINLINE

  Clarify that if a local (DECLARE (INLINE foo)) is to be used to expand
  a function inline in only certain places, then the function should be
  defined like this:
    
   (PROCLAIM '(INLINE foo))
   (DEFUN foo ...)
   (PROCLAIM '(NOTINLINE foo))

  The INLINE proclamation preceding the DEFUN ensures that compiler will
  save the information necessary for inline expansion, and the NOTINLINE
  proclamation following the DEFUN prevents it from being expanded
  inline everywhere.  

  Note that while implementations are never required to perform inline
  expansion of function calls, many implementations that do support
  inline expansion will not be able to respond to local INLINE requests
  if this technique is not followed.

 Rationale:

  Local INLINE declarations are of little use without some way of
  alerting the compiler to the possibility of inline expansion before
  the function is compiled.  This seems the simplest solution since it
  just clarifies existing practice instead of adding a new feature to
  the language.

  A compiler could use some heuristic to save the definitions of functions
  that are short enough to look like good candidates for inline expansion,
  but then the user is never sure what to expect.  It is possible that a
  compiler could simply save all definitions (assuming availability
  of adequate storage space) but we shouldn't require that.

 Test Cases/Examples: 

  Given the following input to COMPILE-FILE, does F1 get expanded inline
  in F2, and does F3 get expanded inline in F4?

    (defun f1 (a) (+ a 100))
    (defun f2 (b) (declare (inline f1)) (f1 b))
    (proclaim '(inline f3))
    (defun f3 (a) (+ a 100))
    (proclaim '(notinline f3))
    (defun f4 (b) (declare (inline f3)) (f3 b))
 
 Current Practice:
 
  In the example above, using Symbolics, Lucid, or Explorer, F1 is not
  expanded in F2, but F3 is expanded in F4.

 Cost to implementors:
 
  None, since this is a clarification in accordance with current
  practice.

 Cost to users:
  
  None.

 Benefits:

  Users will be able to use (DECLARE (INLINE ...)) with greater assurance
  that it will really do something.

 Costs of Non-Adoption: 

  Users will not know how to reliably request inline expansion on a
  local basis.  This technique is not obvious, and even the need
  for it likely to be apparent only to people who understand something
  about how the compiler does inline expansion.

 Discussion:

  Version 1 of this issue included proposal
  ALLOW-LOCAL-INLINE:PROCLAIM-ALLOW-INLINE to make an addition to the
  language:
    (PROCLAIM '(ALLOW-INLINE foo))
  This was met with a lack of enthusiasm since it was pointed out that
  the same effect could be obtained by using a combination of INLINE and
  NOTINLINE.

  This is may not be completely true, however, since people's thinking
  about NOTINLINE has evolved in the direction of a declaration that
  tells the compiler "assume nothing about this function".  Thus, a
  NOTINLINE proclamation might suppress some optimizations that would
  have occurred if there had never been an INLINE and NOTINLINE.

  Ideally, it would be nice to have multiple levels of control instead
  of just INLINE or NOTINLINE -- something like:
    * always inline
    * maybe inline (let the compiler decide)
    * just save the definition for possible local inline
    * default
    * never inline

∂10-Nov-88  0456	CL-Compiler-mailer 	Re: Print/Read and the compiler    
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 10 Nov 88  04:55:26 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa05508; 9 Nov 88 15:41 GMT
Date: Wed, 9 Nov 88 16:02:10 GMT
Message-Id: <3162.8811091602@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Print/Read and the compiler
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, KMP@scrc-stony-brook.arpa, 
    CL-Compiler@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Tue, 8 Nov 88 18:36 EST

> I wish to register my very strong objection to the notion that we start
> limiting what can be QUOTE'd or COMPILE'd based on what can be written
> to files.

For what it's worth, I agree with Kent.  To a large extent, file
compilation is a programming environment issue.  We should not
build files and printed representations into the semantics of
QUOTE.

-- Jeff

∂10-Nov-88  1116	CL-Compiler-mailer 	issue CONSTANT-CIRCULAR-COMPILATION, version 1    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Nov 88  11:15:58 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03408g; Thu, 10 Nov 88 11:14:26 PST
Received: by bhopal id AA05978g; Thu, 10 Nov 88 11:13:07 PST
Date: Thu, 10 Nov 88 11:13:07 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811101913.AA05978@bhopal>
To: Gray@DSG.csc.ti.com
Cc: sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu
In-Reply-To: David N Gray's message of Wed, 9 Nov 88  17:32:31 CST <2804110351-1388307@Kelvin>
Subject: issue CONSTANT-CIRCULAR-COMPILATION, version 1

re: [differing semantics between DEFCONSTANT and QUOTE]
    ... But ordinary QUOTE forms don't have names, so they can't be  
    referenced more than once anyway.  If anything, this goes along with 
    the permission to coalesce EQUAL constants by saying that it
    is not permissible to do the opposite -- that is, to make duplicate
    copies of the same constant.

Not really; in compiled files, Lucid (and many others) coalesce QUOTE'd 
constants to a very high degree.  So even though they are "anonymous", 
they are "found out" by the coalescer; and a random (QUOTE (A B C)) can
in fact be refernced more than once, although not by explicit intent
of the programmer.  However, the constraint of CLtL p.69 -- preserve EQL -- 
prevents symbolic constants like:
    (DEFCONSTANT LOTSA-A (MAKE-ARRAY :ELEMENT-TYPE 'STRING-CHAR 
                                     :INITIAL-ELEMENT #\A))
from being coalesced.

For years now, I've been lobbying for a meaning for program constants 
that is compatible with the notion that QUOTE is allowed to return any
"equivalent" copy of the constant, in particular read-only copies.  For
symbolic constants to have the same semantics, the EQL would have to be
changed into something much more coalescing than even EQUAL.


-- JonL --

∂10-Nov-88  1145	CL-Compiler-mailer 	Print/Read and the compiler   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Nov 88  11:45:35 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03472g; Thu, 10 Nov 88 11:43:46 PST
Received: by bhopal id AA06277g; Thu, 10 Nov 88 11:42:27 PST
Date: Thu, 10 Nov 88 11:42:27 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811101942.AA06277@bhopal>
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
Cc: KMP@scrc-stony-brook.arpa, KMP@scrc-stony-brook.arpa,
        CL-Compiler@sail.stanford.edu
In-Reply-To: Jeff Dalton's message of Wed, 9 Nov 88 16:02:10 GMT <3162.8811091602@subnode.aiai.ed.ac.uk>
Subject: Print/Read and the compiler

re: . . . We should not build files and printed representations into 
    the semantics of QUOTE.

I didn't think that was the issue Kent was addressing;  I saw him as
lobbying for the full inclusion of every CL datatype as being 
"QUOTE"'able in compiled files.

In fact, we are (I hope) willing to consider specifying some of the
semantics of QUOTE based upon reasonable and desirable expectations
about COMPILE-FILE.  We have successfully discarded the notion that
QUOTE'd forms are a good way to implement "own" storage -- at least 
I think that's what the ascendency of the issue LOAD-TIME-VALUE means. 
With no inherent theoretical constraints binding us, we can exercise a 
measure of pragmatism in our choices of issues that have been spurred 
by file compilation questions -- can constants be read-only?  can they 
be copies? and so on.


-- JonL --

∂10-Nov-88  1245	CL-Compiler-mailer 	Re: Print/Read and the compiler    
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 10 Nov 88  12:44:30 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa08229; 10 Nov 88 19:10 GMT
Date: Thu, 10 Nov 88 19:30:43 GMT
Message-Id: <6160.8811101930@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Print/Read and the compiler
To: sandra <@cs.utah.edu:sandra@defun>, 
    Kent M Pitman <KMP@scrc-stony-brook.arpa>
In-Reply-To: sandra's message of Wed, 9 Nov 88 15:17:27 MST
Cc: CL-Compiler@sail.stanford.edu

> I believe KCL (like a number of other implementations) has the file
> compiler inherit macro definitions present in the runtime environment
> from which it is invoked,

Right.

> and that it does not do a code walk before writing out the function.
> I don't have KCL installed here so I can't be 100% positive about this,
> though.

KCL doesn't write out the function (any more).

-- Jeff

∂10-Nov-88  1250	CL-Compiler-mailer 	Re: issue CONSTANT-CIRCULAR-COMPILATION, version 1
Received: from ti.com by SAIL.Stanford.EDU with TCP; 10 Nov 88  12:50:47 PST
Received: by ti.com id AA21704; Thu, 10 Nov 88 14:50:00 CST
Received: from Kelvin by tilde id AA17178; Thu, 10 Nov 88 14:35:08 CST
Message-Id: <2804186240-4230584@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 10 Nov 88  14:37:20 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@lucid.com>
Cc: sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu
Subject: Re: issue CONSTANT-CIRCULAR-COMPILATION, version 1
In-Reply-To: Msg of Thu, 10 Nov 88 11:13:07 PST from Jon L White <jonl@lucid.com>

>     However, the constraint of CLtL p.69 -- preserve EQL -- 
> prevents symbolic constants like:
>     (DEFCONSTANT LOTSA-A (MAKE-ARRAY :ELEMENT-TYPE 'STRING-CHAR 
>                                      :INITIAL-ELEMENT #\A))
> from being coalesced.

The way I read page 69, it simply says that all references to LOTSA-A
must be EQL to each other; it does not say that they cannot be EQL to
some other constant.  So I still don't see what this has to do with
coalescing constants.

∂10-Nov-88  1249	CL-Compiler-mailer 	Re: Print/Read and the compiler    
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 10 Nov 88  12:46:03 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa08233; 10 Nov 88 19:12 GMT
Date: Thu, 10 Nov 88 19:34:05 GMT
Message-Id: <6175.8811101934@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Print/Read and the compiler
To: David N Gray <Gray%dsg.csc.ti.com@NSS.Cs.Ucl.AC.UK>, 
    sandra <@cs.utah.edu:sandra@defun>
In-Reply-To: David N Gray's message of Wed, 9 Nov 88  17:23:35 CST
Cc: Kent M Pitman <KMP@scrc-stony-brook.arpa>, CL-Compiler@sail.stanford.edu

> This may just be my prejudice, but just off hand, this strikes me as
> being an implementation short-cut that would not be used anyway on a
> serious commercial implementation.

Um, I do not think one of the design goals for a standard should be
that it can be met only by serious commerical implementations.  And
so considerations that are supposedly irrelevant to SCIs may still
be relevant to the standard.  I happen to think Kent is right about
the COMPILE semantics for constants, but I disagree with this reason.

Common Lisp as currently defined allows a range of implementation
strategies.  It does not, for example, require an interpreter, not
does it require that the compiler perform any particular degree of
compilation.  The range used by SCIs may be much narrower, but that
is not in itself a reason for restricting the range in the standard.

> I would imagine that an implementation that used a short-cut like
> this would probably not be fully standard-conforming in many other
> ways.

Maybe so.  But it *could* be fully standard-conforming except for
its implementation of COMPILE.

-- Jeff

∂10-Nov-88  1308	CL-Compiler-mailer 	Print/Read and the compiler   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Nov 88  13:08:18 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 490627; Thu 10-Nov-88 16:07:59 EST
Date: Thu, 10 Nov 88 16:07 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Print/Read and the compiler
To: jonl@lucid.com
cc: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK,
    KMP@STONY-BROOK.SCRC.Symbolics.COM,
    KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Compiler@sail.stanford.edu
In-Reply-To: <8811101942.AA06277@bhopal>
Message-ID: <881110160744.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

I think Jeff had it right. What I would prefer to see is:

Describe that EVAL and COMPILE match, and that their semantics for QUOTE is
as if QUOTE did no copying:

 ;; This example would not be safe in shared memory, multi-tasking environments
 ;; or environments with asynchronous interrupts. Please ignore that timing
 ;; window, though, for sake of conciseness of this example. -kmp

 (SETQ *QUOTE-ARRAY* (MAKE-ARRAY 0 :FILL-POINTER 0 :ADJUSTABLE T))

 (DEFMACRO QUOTE (X)
   (VECTOR-PUSH-EXTEND X *QUOTE-ARRAY*)
   `(AREF *QUOTE-ARRAY* ,(- (FILL-POINTER *QUOTE-ARRAY*) 1)))

Describe that COMPILE-FILE is more restricted (per recent proposals), and explain
that this is because an external representation of the data (in the output file)
is forced, and because there is no reliably externalizable description of certain
kinds of objects.

As such, the part of CL which could be file-compiled would be a subset of that
part of CL which could be executed in core, but we wouldn't lose the ability to
do the myriad useful things that could be done with in-core quoted constants of
arbitrary nature.

Further, my description above does not make for an asymmetry between
COMPILE and EVAL -- if you need an analog of COMPILE-FILE with similar
restrictions, we could introduce a function called MACROEXPAND-FILE
which had the same restrictions as COMPILE-FILE because the
macroexpanded program text would have to be externally represented. I'm
not seriously suggesting such a function, I'm just identifying what is
in the missing place for those symmetry-enthusiasts trying to figure out
what the relation is between COMPILE and EVAL here.

Note further that since *PRINT-CIRCLE* could, in principle, be used by
MACROEXPAND-FILE, there's no a priori reason that it couldn't be used in
COMPILE-FILE. I guess whoever suggested *DUMP-CIRCLE* was getting at
this same point.

The issue that people are raising about whether it is appropriate to copy
quoted things into a compiled constants area may, by my example above, be
dealt with orthogonally from the issue of what arguments are permitted without
resulting in a skew between evaluation and compilation. Any of the following
scenarios would provide consistent compiler/interpreter behavior:
 1- Only COMPILE/EVAL copies constants to another area.
 2- Both COMPILE/EVAL and COMPILE-FILE/MACROEXPAND-FILE copy constants to
    another area.
 3- Only COMPILE-FILE/MACROEXPAND-FILE copies constants to another area.

Option 1 is technically possible but useless.
Options 2 and 3 are the ones for which a credible case can be built.

My strong preference is for Option 3 since it does not needlessly
restrict the set of data types which I may quote, and since it does not
disrupt very valuable EQL-relations which I may have established among
data structures.

While I do not think that it is appropriate for one to write the following
in a file to be compiled:

 (DEFUN FOO (TEST) (EQL TEST '#.*SOMETHING*))

because EQL-ness over files cannot be guaranteed due to the information
which is potentially lost by externalizing the definition and later
re-reading in a hostile environment. I do, however, think it appropriate
for us to permit people to write:

 (COMPILE NIL `(LAMBDA (TEST) (EQL TEST ',*SOMETHING*)))

Consider a case where I needed to pass a function off to another routine
(for something like SORT where the function would get called a lot -- so
much, perhaps, that a call to COMPILE would be lost in the noise -- yet
I did not know the value of some parameter until runtime):

 #'(LAMBDA (TEST) (EQL THING *SOMETHING*))

 ((LAMBDA (THING) #'(LAMBDA (TEST) (EQL TEST THING))) *SOMETHING*)

 (COMPILE NIL `(LAMBDA (TEST) (EQL TEST ',*SOMETHING*)))

You could always contrive a suitably poor instruction set so that the 
function resulting from any of the above ran at the same speed as any
other, but really I'd be surprised if the third didn't beat the other
two in speed in many (if not most) systems. [I'm not asserting that this
works now semantically in such systems. It just seems to me that it might
easily be made to work, and that the consequences could be useful.]

If nothing else, of special vs lexical variable access, which is faster 
may vary from implementation to implementation. Yet even so, I'd expect
QUOTE to be consistent with the faster of the two, so I'm happier using
QUOTE in cases like this than I am in putting the value in one or the
other kind of variable and hoping it will be equally fast in all implementations.

By the way, as an afterthought, I will mention something about LOAD-TIME-VALUE.
It's true that this widens the space of possibilities to include

 (COMPILE NIL `(LAMBDA (TEST) (EQL TEST (LOAD-TIME-VALUE *SOMETHING*))))

but again in the case of LOAD-TIME-VALUE it turns out that (at least, drawing
on my understanding of SQUID from Maclisp), this is not sufficient to get a
MOVEI instruction instead of a MOVE on the PDP10 because you'd have to go back
and modify the function at load time. This used to hit me all the time with
my Fortran->Lisp translator and bugged me a lot.

The problem is that the compiler will need to generate half an
instruction and at load time the LOAD-TIME-EVAL facility will have to
bash back the other half of the instruction. If I can put the item in
QUOTE, then the quantity is known already at compile time and the
compiler can generate the whole instruction and be done with it. I'm
confident that a compiler can do the QUOTE case with best efficiency;
I'm not confident that a compiler can do the LOAD-TIME-EVAL case with
best efficiency, especially if pointers and/or instructions may vary in
length.

All of the above case for COMPILE is true of:
    (DEFVAR *FOO*  (CIRCULAR-LIST 'A 'B 'C))
    (DEFVAR *N*    '(1 2 3 4))

    (DEFVAR *FORM* '(MAPCAR #'CONS *N* *FOO*))
 vs (DEFVAR *FORM* `(MAPCAR #'CONS *N* ',*FOO*))

and then later doing (EVAL *FORM*) a lot of times where you knew *FOO*
was going to not change value.  The version that uses the quoted circular
list is going to be faster, and I see no reason to require the code writer
to do something slower.

As such, I don't think it is appropriate to say that if you have some
datatype outside of a certain set, that you must stuff it in a variable
and access it from there because you're asking for a performance penalty
in some situations -- particularly the situation where I've been willing
to defer compilation until runtime in order to take advantage of the
additional constraint relaxations I made noise about in my previous message.

The main point of this message is that the troublemaker is xxx-FILE and
not the in-core primitives. I think the issue of copying and restriction
can be interestingly and usefully defined for files without trying to
penalize COMPILE for a problem it didn't cause.

∂10-Nov-88  1337	CL-Compiler-mailer 	issue CONSTANT-CIRCULAR-COMPILATION, version 1    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Nov 88  13:37:28 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03624g; Thu, 10 Nov 88 13:35:27 PST
Received: by bhopal id AA06731g; Thu, 10 Nov 88 13:34:08 PST
Date: Thu, 10 Nov 88 13:34:08 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8811102134.AA06731@bhopal>
To: Gray@DSG.csc.ti.com
Cc: sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu
In-Reply-To: David N Gray's message of Thu, 10 Nov 88  14:37:20 CST <2804186240-4230584@Kelvin>
Subject: issue CONSTANT-CIRCULAR-COMPILATION, version 1

re: The way I read page 69, it simply says that all references to LOTSA-A
    must be EQL to each other; it does not say that they cannot be EQL to
    some other constant.  So I still don't see what this has to do with
    coalescing constants.

It implies that they must be EQL to what's in the symbol-value cell of
LOTSA-A, and that prevents coalescing because it (seemingly) requires
every implementation to implement symbolic constants by indirecting
through the value-cell.  If this point were clarified (in the more
permissive direction) then there would be no problem; but every
implementation I've looked at in fact does the indirection thing
rather than the compile-time folding thing.


-- JonL --

∂10-Nov-88  1505	CL-Compiler-mailer 	Re: issue CONSTANT-CIRCULAR-COMPILATION, version 1
Received: from ti.com by SAIL.Stanford.EDU with TCP; 10 Nov 88  15:05:36 PST
Received: by ti.com id AA22567; Thu, 10 Nov 88 17:04:49 CST
Received: from Kelvin by tilde id AA20218; Thu, 10 Nov 88 16:46:53 CST
Message-Id: <2804194141-4705264@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 10 Nov 88  16:49:01 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@lucid.com>
Cc: sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu
Subject: Re: issue CONSTANT-CIRCULAR-COMPILATION, version 1
In-Reply-To: Msg of Thu, 10 Nov 88 13:34:08 PST from Jon L White <jonl@lucid.com>

> It implies that they must be EQL to what's in the symbol-value cell of
> LOTSA-A, and that prevents coalescing because it (seemingly) requires
> every implementation to implement symbolic constants by indirecting
> through the value-cell.  If this point were clarified (in the more
> permissive direction) then there would be no problem; but every
> implementation I've looked at in fact does the indirection thing
> rather than the compile-time folding thing.

Let's get a specific example to look at:

  (DEFCONSTANT CA '(A B C))
  (DEFCONSTANT CB '(A B C))
  (DEFUN F1 () CA)
  (DEFUN F2 () CA)

I take it that you want to optimize the functions to

  (DEFUN F1 () '(A B C))
  (DEFUN F2 () '(A B C)) 

and are concerned that the EQL rule doesn't permit you to do that since
the functions might be in different files and hence the constants might
not get coalesced back together.  However, I don't see this as being a
desirable transformation anyway because I don't want to waste memory by
having two or three copies of the same object when only one would do.
(This example is a short list, but it could just as well be an enormous
array.)  It seems like the indirection could be eliminated just as well
by optimizing to the equivalent of
  (DEFUN F1 () (LOAD-TIME-VALUE CA))
which should be able to be just as efficient while still preserving
EQL-ness.

Usually the advantage of substituting the value at compile time is to
enable other optimizations, but that is