perm filename CLOOPS.MSG[COM,LSP]20 blob sn#876201 filedate 1989-08-21 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00244 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00039 00002	
C00040 00003	∂16-May-88  1139	Common-Lisp-Object-System-mailer 	CLOS document numbers for June meeting   
C00042 00004	∂16-May-88  1524	Common-Lisp-Object-System-mailer 	Chapter 2  
C00043 00005	∂17-May-88  1340	Common-Lisp-Object-System-mailer 	Re: check-keyword-arguments    
C00045 00006	∂18-May-88  1101	Common-Lisp-Object-System-mailer   
C00047 00007	∂18-May-88  1818	Common-Lisp-Object-System-mailer 	Comments on new draft chapter 1 (dated May 13 20:53)    
C00051 00008	∂18-May-88  2007	Common-Lisp-Object-System-mailer 	Comments on new draft chapter 2 (dated May 16 15:09)    
C00058 00009	∂19-May-88  1613	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
C00066 00010	∂20-May-88  1508	Common-Lisp-Object-System-mailer 	Comments on new draft chapter 1 (dated May 13 20:53)    
C00087 00011	∂20-May-88  1703	Common-Lisp-Object-System-mailer 	Comments on new draft chapter 1 (dated May 13 20:53)    
C00098 00012	∂20-May-88  2010	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
C00103 00013	∂20-May-88  2206	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
C00105 00014	∂21-May-88  0017	Common-Lisp-Object-System-mailer 	Mlynarik's comments  
C00117 00015	∂21-May-88  0651	Common-Lisp-Object-System-mailer 	Comments on current state of Initialization.  
C00124 00016	∂21-May-88  1602	Common-Lisp-Object-System-mailer 	define-method-combination 
C00131 00017	∂21-May-88  1605	Common-Lisp-Object-System-mailer 	Comments on current state of Initialization.  
C00134 00018	∂21-May-88  1923	Common-Lisp-Object-System-mailer 	define-method-combination 
C00143 00019	∂23-May-88  0644	Common-Lisp-Object-System-mailer 	Re: check-keyword-arguments    
C00148 00020	∂23-May-88  0842	Common-Lisp-Object-System-mailer 	Re: define-method-combination  
C00156 00021	∂23-May-88  0948	Common-Lisp-Object-System-mailer 	Re: check-keyword-arguments    
C00158 00022	∂23-May-88  1047	Common-Lisp-Object-System-mailer 	More Check-Keyword-Arguments   
C00159 00023	∂23-May-88  1055	Common-Lisp-Object-System-mailer 	define-method-combination 
C00168 00024	∂23-May-88  1105	Common-Lisp-Object-System-mailer 	Re: define-method-combination  
C00171 00025	∂23-May-88  1211	Common-Lisp-Object-System-mailer 	Define-Method-Combination 
C00173 00026	∂23-May-88  1234	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
C00174 00027	∂23-May-88  1537	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
C00176 00028	∂23-May-88  1539	Common-Lisp-Object-System-mailer 	Comments on current state of Initialization.  
C00179 00029	∂23-May-88  1600	Common-Lisp-Object-System-mailer 	check-keyword-arguments etc.   
C00181 00030	∂23-May-88  1633	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
C00182 00031	∂23-May-88  1649	Common-Lisp-Object-System-mailer 	Re: Mlynarik's comments   
C00185 00032	∂23-May-88  1659	Common-Lisp-Object-System-mailer 	Chapter 1  
C00186 00033	∂23-May-88  2332	Common-Lisp-Object-System-mailer 	Method Objects are not Functions    
C00187 00034	∂24-May-88  1044	Common-Lisp-Object-System-mailer 	Re: Method Objects are not Functions     
C00189 00035	∂24-May-88  1105	Common-Lisp-Object-System-mailer 	Callable Methods
C00191 00036	∂26-May-88  1055	Common-Lisp-Object-System-mailer 	with-added-methods   
C00195 00037	∂02-Jun-88  1329	Common-Lisp-Object-System-mailer 	[David N Gray <Gray@DSG>:  making structures] 
C00197 00038	∂20-Jun-88  1330	Common-Lisp-Object-System-mailer 	Compile-file environment  
C00204 00039	∂22-Jun-88  1448	Common-Lisp-Object-System-mailer 	SYMBOL-MACROLET-UTILITY   
C00210 00040	∂24-Jun-88  1225	Common-Lisp-Object-System-mailer 	which functions should be generic?  
C00212 00041	∂24-Jun-88  1332	Common-Lisp-Object-System-mailer 	Re: which functions should be generic?   
C00214 00042	∂24-Jun-88  1545	Common-Lisp-Object-System-mailer 	which functions should be generic?  
C00217 00043	∂24-Jun-88  1648	Common-Lisp-Object-System-mailer 	Re: which functions should be generic?   
C00222 00044	∂25-Jun-88  1204	Common-Lisp-Object-System-mailer 	Re: which functions should be generic?   
C00227 00045	∂03-Jul-88  1051	RPG 	The Law of Demeter  
C00231 00046	∂11-Jul-88  1111	CL-Object-Oriented-Programming-mailer 	CLOS Workshop   
C00235 00047	∂15-Jul-88  1304	Common-Lisp-Object-System-mailer 	putting CLOS objects in binfiles    
C00241 00048	∂15-Jul-88  1408	Common-Lisp-Object-System-mailer 	putting CLOS objects in binfiles    
C00248 00049	∂15-Jul-88  1719	Common-Lisp-Object-System-mailer 	Re: putting CLOS objects in binfiles
C00253 00050	∂18-Jul-88  0808	Common-Lisp-Object-System-mailer 	Re: putting CLOS objects in binfiles     
C00256 00051	∂18-Jul-88  1307	Common-Lisp-Object-System-mailer 	putting CLOS objects in binfiles    
C00267 00052	∂26-Jul-88  0847	Common-Lisp-Object-System-mailer 	where I'm going, etc.
C00272 00053	∂02-Aug-88  1412	Common-Lisp-Object-System-mailer 	declare in with-slots
C00275 00054	∂03-Aug-88  0712	Common-Lisp-Object-System-mailer 	RE: decalre in with-slots 
C00279 00055	∂03-Aug-88  0852	Common-Lisp-Object-System-mailer 	RE: declare in with-slots 
C00281 00056	∂03-Aug-88  1024	Common-Lisp-Object-System-mailer 	declare in with-slots
C00285 00057	∂03-Aug-88  1150	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
C00288 00058	∂03-Aug-88  1504	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
C00291 00059	∂03-Aug-88  1538	Common-Lisp-Object-System-mailer 	declare in with-slots
C00293 00060	∂04-Aug-88  0828	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
C00297 00061	∂04-Aug-88  1134	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
C00299 00062	∂05-Aug-88  1331	Common-Lisp-Object-System-mailer 	description language classes & the Meta-Object Protocol 
C00317 00063	∂05-Aug-88  1833	Common-Lisp-Object-System-mailer 	Re: description language classes & the Meta-Object Protocol  
C00319 00064	∂08-Aug-88  1020	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
C00325 00065	∂10-Aug-88  0952	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
C00332 00066	∂11-Aug-88  0810	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
C00338 00067	∂11-Aug-88  1021	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
C00346 00068	∂07-Sep-88  2004	Common-Lisp-Object-System-mailer 	symbol-macrolet-semantics, symbol-macrolet-utility 
C00350 00069	∂09-Sep-88  1203	RPG 	first part of mop   
C00354 00070	∂10-Sep-88  1150	RPG 	Re: first part of mop    
C00359 00071	∂12-Sep-88  1102	Common-Lisp-Object-System-mailer 	Fairfax Meeting 
C00361 00072	∂12-Sep-88  1747	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-DECLARE (version 1)    
C00366 00073	∂13-Sep-88  0708	Common-Lisp-Object-System-mailer 	RE: Issue: SYMBOL-MACROLET-DECLARE (version 1)
C00369 00074	∂13-Sep-88  1145	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-DECLARE (version 1)    
C00373 00075	∂14-Sep-88  1817	Common-Lisp-Object-System-mailer 	call-next-method and arguments to :before and :after methods 
C00381 00076	∂15-Sep-88  1304	Common-Lisp-Object-System-mailer 	call-next-method and arguments to :before and :after methods 
C00384 00077	∂15-Sep-88  1331	Common-Lisp-Object-System-mailer 	Re: call-next-method and arguments to :before and :after methods  
C00387 00078	∂20-Sep-88  1817	Common-Lisp-Object-System-mailer 	Re: Issue: SYMBOL-MACROLET-DECLARE (version 1)
C00389 00079	∂20-Sep-88  2008	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-DECLARE (version 1)    
C00392 00080	∂21-Sep-88  1423	Common-Lisp-Object-System-mailer 	metaobject protocol (description languages)   
C00396 00081	∂05-Oct-88  1242	CL-Compiler-mailer 	Issue: DEFINE-OPTIMIZER  
C00411 00082	∂05-Oct-88  1503	Common-Lisp-Object-System-mailer 	Q about CLOS    
C00413 00083	∂05-Oct-88  1934	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
C00418 00084	∂05-Oct-88  2312	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
C00421 00085	∂06-Oct-88  1034	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
C00428 00086	∂06-Oct-88  1156	Common-Lisp-Object-System-mailer 	Re: Q about CLOS
C00430 00087	∂10-Oct-88  1352	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
C00434 00088	∂14-Oct-88  1510	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
C00437 00089	∂16-Oct-88  1316	Common-Lisp-Object-System-mailer 	CLOS analogue to TYPEP and SUBTYPEP 
C00439 00090	∂16-Oct-88  1545	Common-Lisp-Object-System-mailer 	Re: CLOS analogue to TYPEP and SUBTYPEP  
C00442 00091	∂20-Oct-88  1719	CL-Cleanup-mailer 	Issue: EVAL-OTHER (Version 2)  
C00446 00092	∂24-Oct-88  1816	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
C00452 00093	∂31-Oct-88  1843	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
C00454 00094	∂25-Nov-88  0907	Common-Lisp-Object-System-mailer 	specification request [plain text]  
C00456 00095	∂15-Dec-88  0935	Common-Lisp-Object-System-mailer 	CLOS lambda-list congruence    
C00459 00096	∂15-Dec-88  0953	Common-Lisp-Object-System-mailer 	Re: CLOS lambda-list congruence     
C00463 00097	∂15-Dec-88  1117	Common-Lisp-Object-System-mailer 	Re: CLOS lambda-list congruence     
C00466 00098	∂15-Dec-88  1119	Common-Lisp-Object-System-mailer 	Re: CLOS lambda-list congruence     
C00468 00099	∂16-Dec-88  1505	Common-Lisp-Object-System-mailer 	Re: CLOS lambda-list congruence     
C00471 00100	∂16-Dec-88  1618	Common-Lisp-Object-System-mailer 	Re: CLOS lambda-list congruence     
C00473 00101	∂28-Dec-88  1700	Common-Lisp-Object-System-mailer 	Suggestion Sent to CommonLoops List 
C00475 00102	∂29-Dec-88  0500	Common-Lisp-Object-System-mailer 	Compilation implications  
C00483 00103	∂29-Dec-88  1001	Common-Lisp-Object-System-mailer 	Compilation implications  
C00493 00104	∂30-Dec-88  0400	CL-Compiler-mailer 	Compilation implications 
C00496 00105	∂30-Dec-88  1128	CL-Compiler-mailer 	Re: Compilation implications  
C00504 00106	∂30-Dec-88  2008	CL-Compiler-mailer 	Compilation implications 
C00509 00107	∂02-Jan-89  1328	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 1)
C00519 00108	∂03-Jan-89  0932	CL-Compiler-mailer 	Re: Compilation implications  
C00522 00109	∂03-Jan-89  0959	Common-Lisp-Object-System-mailer 	Re: Compilation implications   
C00526 00110	∂03-Jan-89  1838	CL-Compiler-mailer 	Re: Compilation implications  
C00529 00111	∂05-Jan-89  1005	CL-Compiler-mailer 	Re: Compilation implications  
C00540 00112	∂05-Jan-89  1336	Common-Lisp-Object-System-mailer 	Re: Compilation implications   
C00544 00113	∂05-Jan-89  1342	Common-Lisp-Object-System-mailer 	Re: Compilation implications   
C00548 00114	∂05-Jan-89  1451	CL-Compiler-mailer 	Re: Compilation implications  
C00551 00115	∂05-Jan-89  1547	Common-Lisp-Object-System-mailer 	Re: Compilation implications   
C00557 00116	∂05-Jan-89  1721	CL-Compiler-mailer 	Re: Compilation implications  
C00561 00117	∂06-Jan-89  0033	Common-Lisp-Object-System-mailer 	Compilation implications  
C00566 00118	∂06-Jan-89  0936	Common-Lisp-Object-System-mailer 	Re: Compilation implications   
C00570 00119	∂06-Jan-89  1520	Common-Lisp-Object-System-mailer 	Compilation implications  
C00580 00120	∂06-Jan-89  1539	Common-Lisp-Object-System-mailer 	Compilation implications  
C00587 00121	∂06-Jan-89  2109	Common-Lisp-Object-System-mailer 	Compilation implications  
C00593 00122	∂06-Jan-89  2207	Common-Lisp-Object-System-mailer 	Re: Compilation implications   
C00597 00123	∂06-Jan-89  2246	CL-Compiler-mailer 	Compilation implications 
C00602 00124	∂10-Jan-89  1904	Common-Lisp-Object-System-mailer 	MAKE-LOAD-FORM can handle circularities [was Compilation implications] 
C00612 00125	∂10-Jan-89  2058	Common-Lisp-Object-System-mailer 	MAKE-LOAD-FORM can handle circularities [was Compilation implications] 
C00622 00126	∂11-Jan-89  1421	Common-Lisp-Object-System-mailer 	Re: MAKE-LOAD-FORM can handle circularities [was Compilation implications]  
C00627 00127	∂11-Jan-89  1431	Common-Lisp-Object-System-mailer 	MAKE-LOAD-FORM can handle circularities [was Compilation implications] 
C00630 00128	∂11-Jan-89  1431	Common-Lisp-Object-System-mailer 	Re: MAKE-LOAD-FORM can handle circularities [was Compilation implications]  
C00634 00129	∂11-Jan-89  1432	CL-Compiler-mailer 	Re: MAKE-LOAD-FORM can handle circularities [was Compilation implications] 
C00637 00130	∂11-Jan-89  1433	CL-Compiler-mailer 	MAKE-LOAD-FORM can handle circularities [was Compilation implications]
C00639 00131	∂11-Jan-89  1458	CL-Compiler-mailer 	Re: MAKE-LOAD-FORM can handle circularities [was Compilation implications] 
C00641 00132	∂11-Jan-89  1515	CL-Compiler-mailer 	MAKE-LOAD-FORM can handle circularities [was Compilation implications]
C00644 00133	∂13-Jan-89  1454	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 2)
C00664 00134	∂13-Jan-89  1602	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 2)
C00667 00135	∂13-Jan-89  1936	CL-Compiler-mailer 	Re: Issue: LOAD-OBJECTS (Version 2)
C00671 00136	∂13-Jan-89  2058	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 2)
C00679 00137	∂23-Jan-89  1152	CL-Compiler-mailer 	DEFMETHOD compile-time processing  
C00682 00138	∂24-Jan-89  0928	CL-Compiler-mailer 	DEFMETHOD compile-time processing  
C00689 00139	∂24-Jan-89  1415	Common-Lisp-Object-System-mailer 	DEFMETHOD compile-time processing   
C00702 00140	∂24-Jan-89  1746	CL-Compiler-mailer 	Re: DEFMETHOD compile-time processing   
C00707 00141	∂25-Jan-89  0840	CL-Compiler-mailer 	DEFMETHOD compile-time processing  
C00713 00142	∂26-Jan-89  1653	CL-Compiler-mailer 	Re: DEFMETHOD compile-time processing   
C00721 00143	∂27-Jan-89  1950	CL-Cleanup-mailer 	Issue: FUNCTION-NAME (Version 1)    
C00746 00144	∂29-Jan-89  1325	Common-Lisp-Object-System-mailer 	Re: Issue: FUNCTION-NAME (Version 1)
C00749 00145	∂30-Jan-89  0720	CL-Cleanup-mailer 	Issue: FUNCTION-NAME (Version 1)    
C00751 00146	∂30-Jan-89  1003	Common-Lisp-Object-System-mailer 	Issue: FUNCTION-NAME (Version 1)    
C00753 00147	∂01-Feb-89  1034	Common-Lisp-Object-System-mailer 	editorial comments on chapter 3
C00765 00148	∂01-Feb-89  1149	Common-Lisp-Object-System-mailer 	classes and environments  
C00770 00149	∂01-Feb-89  1204	Common-Lisp-Object-System-mailer 	chapter 3 comments   
C00783 00150	∂02-Feb-89  1239	CL-Cleanup-mailer 	Issue: FUNCTION-NAME (Version 1)    
C00795 00151	∂06-Feb-89  1307	Common-Lisp-Object-System-mailer 	issue SYMBOL-MACROLET-SEMANTICS
C00797 00152	∂06-Feb-89  1316	CL-Cleanup-mailer 	issue SYMBOL-MACROLET-SEMANTICS
C00799 00153	∂07-Feb-89  0819	CL-Windows-mailer 	I/O generic functions     
C00813 00154	∂07-Feb-89  1016	Common-Lisp-Object-System-mailer 	Re: I/O generic functions 
C00815 00155	∂07-Feb-89  1033	Common-Lisp-Object-System-mailer 	Re: I/O generic functions 
C00819 00156	∂07-Feb-89  1341	Common-Lisp-Object-System-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY    
C00821 00157	∂07-Feb-89  2005	CL-Cleanup-mailer 	I/O generic functions     
C00825 00158	∂08-Feb-89  1249	Common-Lisp-Object-System-mailer 	omissions from chapter 3  
C00829 00159	∂09-Feb-89  1304	Common-Lisp-Object-System-mailer 	local generic functions   
C00831 00160	∂10-Feb-89  1257	Common-Lisp-Object-System-mailer 	Re: issue MACRO-ENVIRONMENT-EXTENT, version 1 
C00835 00161	∂10-Feb-89  1449	CL-Compiler-mailer 	Re: issue MACRO-ENVIRONMENT-EXTENT, version 1
C00840 00162	∂12-Feb-89  1827	Common-Lisp-Object-System-mailer 	Re: issue MACRO-ENVIRONMENT-EXTENT, version 1 
C00843 00163	∂14-Feb-89  2314	Common-Lisp-Object-System-mailer 	CLOS Mailing List    
C00845 00164	∂16-Feb-89  1203	Common-Lisp-Object-System-mailer 	effective methods question
C00847 00165	∂16-Feb-89  1249	Common-Lisp-Object-System-mailer 	DEFSTRUCT and DEFCLASS    
C00852 00166	∂16-Feb-89  1348	Common-Lisp-Object-System-mailer 	CLOS questions  
C00858 00167	∂16-Feb-89  1614	Common-Lisp-Object-System-mailer 	effective methods question
C00860 00168	∂16-Feb-89  2219	Common-Lisp-Object-System-mailer 	Comments on metaobject draft 10
C00870 00169	∂21-Feb-89  1053	Common-Lisp-Object-System-mailer 	CLOS questions  
C00875 00170	∂21-Feb-89  1501	Common-Lisp-Object-System-mailer 	Issue MACRO-ENVIRONMENT-EXTENT 
C00881 00171	∂21-Feb-89  1501	Common-Lisp-Object-System-mailer 	Issue CONSTANT-COMPILABLE-TYPES
C00889 00172	∂23-Feb-89  1316	Common-Lisp-Object-System-mailer 	CLOS defining macros & compilation  
C00896 00173	∂23-Feb-89  1519	Common-Lisp-Object-System-mailer 	Re: CLOS defining macros & compilation   
C00899 00174	∂23-Feb-89  1532	Common-Lisp-Object-System-mailer 	CLOS defining macros & compilation  
C00902 00175	∂23-Feb-89  1546	Common-Lisp-Object-System-mailer 	Re: CLOS defining macros & compilation   
C00905 00176	∂23-Feb-89  1550	Common-Lisp-Object-System-mailer 	Re: CLOS defining macros & compilation   
C00908 00177	∂23-Feb-89  1558	Common-Lisp-Object-System-mailer 	Re: CLOS defining macros & compilation   
C00912 00178	∂23-Feb-89  1607	Common-Lisp-Object-System-mailer 	Re: CLOS defining macros & compilation   
C00916 00179	∂23-Feb-89  1650	CL-Compiler-mailer 	remote environments 
C00923 00180	∂23-Feb-89  1746	CL-Compiler-mailer 	Re: remote environments  
C00929 00181	∂23-Feb-89  2103	Common-Lisp-Object-System-mailer 	CLOS defining macros & compilation  
C00934 00182	∂24-Feb-89  0157	Common-Lisp-Object-System-mailer 	Issue CONSTANT-COMPILABLE-TYPES
C00938 00183	∂24-Feb-89  0754	Common-Lisp-Object-System-mailer 	Re: CLOS defining macros & compilation   
C00943 00184	∂27-Feb-89  0854	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY   
C00947 00185	∂27-Feb-89  0949	Common-Lisp-Object-System-mailer 	Re: Comments on metaobject draft 10 
C00949 00186	∂27-Feb-89  0950	Common-Lisp-Object-System-mailer 	Re: Comments on metaobject draft 10 
C00951 00187	∂06-Mar-89  1345	Common-Lisp-Object-System-mailer 	Re: CLOS questions   
C00954 00188	∂06-Mar-89  1356	Common-Lisp-Object-System-mailer 	CLOS questions  
C00957 00189	∂06-Mar-89  1840	Common-Lisp-Object-System-mailer 	remote environments  
C00971 00190	∂07-Mar-89  1546	Common-Lisp-Object-System-mailer 	Re: remote environments   
C00974 00191	∂08-Mar-89  1722	Common-Lisp-Object-System-mailer 	macroexpansions of the user interface macros  
C00977 00192	∂09-Mar-89  0802	Common-Lisp-Object-System-mailer 	macroexpansions of the user interface macros  
C00980 00193	∂09-Mar-89  1102	CL-Compiler-mailer 	Issue MACRO-ENVIRONMENT-EXTENT
C00984 00194	∂09-Mar-89  1301	Common-Lisp-Object-System-mailer 	Re: Issue: LOAD-OBJECTS (Version 2) 
C00989 00195	∂09-Mar-89  1325	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 2)
C00993 00196	∂09-Mar-89  1329	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 3)
C01016 00197	∂09-Mar-89  1619	Common-Lisp-Object-System-mailer 	issue CLOS-MACRO-COMPILATION   
C01018 00198	∂09-Mar-89  1708	CL-Compiler-mailer 	issue CLOS-MACRO-COMPILATION  
C01021 00199	∂10-Mar-89  1258	Common-Lisp-Object-System-mailer 	issue CLOS-MACRO-COMPILATION, version 1  
C01031 00200	∂10-Mar-89  1609	Common-Lisp-Object-System-mailer 	class FUNCTION etc.  
C01033 00201	∂10-Mar-89  1615	Common-Lisp-Object-System-mailer 	Re: remote environments   
C01036 00202	∂11-Mar-89  0126	Common-Lisp-Object-System-mailer 	Re: issue CLOS-MACRO-COMPILATION, version 1   
C01040 00203	∂11-Mar-89  0130	Common-Lisp-Object-System-mailer 	Re: remote environments   
C01045 00204	∂11-Mar-89  0150	Common-Lisp-Object-System-mailer 	Re: Issue MACRO-ENVIRONMENT-EXTENT  
C01049 00205	∂11-Mar-89  0818	Common-Lisp-Object-System-mailer 	Re: issue CLOS-MACRO-COMPILATION, version 1   
C01054 00206	∂11-Mar-89  1220	Common-Lisp-Object-System-mailer 	Re: issue CLOS-MACRO-COMPILATION, version 1   
C01058 00207	∂11-Mar-89  1439	Common-Lisp-Object-System-mailer 	Re: remote environments   
C01060 00208	∂11-Mar-89  1506	Common-Lisp-Object-System-mailer 	Re: remote environments   
C01063 00209	∂11-Mar-89  1502	CL-Compiler-mailer 	Re: issue CLOS-MACRO-COMPILATION, version 1  
C01068 00210	∂11-Mar-89  1548	Common-Lisp-Object-System-mailer 	Re: remote environments   
C01072 00211	∂11-Mar-89  1658	Common-Lisp-Object-System-mailer 	Issue: LOAD-OBJECTS (Version 3)
C01080 00212	∂11-Mar-89  1745	Common-Lisp-Object-System-mailer 	Re: Issue: LOAD-OBJECTS (Version 3) 
C01083 00213	∂12-Mar-89  1032	Common-Lisp-Object-System-mailer 	Issue: LOAD-OBJECTS (Version 3)
C01085 00214	∂12-Mar-89  2014	Common-Lisp-Object-System-mailer 	Re: remote environments   
C01097 00215	∂13-Mar-89  0653	Common-Lisp-Object-System-mailer 	Re: remote environments   
C01103 00216	∂13-Mar-89  1034	Common-Lisp-Object-System-mailer 	Re: remote environments   
C01108 00217	∂13-Mar-89  1039	Common-Lisp-Object-System-mailer 	Re: remote environments   
C01111 00218	∂13-Mar-89  1054	Common-Lisp-Object-System-mailer 	Re: remote environments   
C01117 00219	∂13-Mar-89  1151	Common-Lisp-Object-System-mailer 	Re: remote environments   
C01122 00220	∂13-Mar-89  1352	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 3)
C01129 00221	∂15-Mar-89  1207	Common-Lisp-Object-System-mailer 	Understanding Method Combination.   
C01134 00222	∂17-Mar-89  2254	CL-Cleanup-mailer 	Re: Issue: LOAD-OBJECTS (Version 3) 
C01140 00223	∂19-Mar-89  1811	Common-Lisp-Object-System-mailer 	Re: Understanding Method Combination.    
C01145 00224	∂20-Mar-89  1305	Common-Lisp-Object-System-mailer 	Re: Understanding Method Combination.    
C01148 00225	∂20-Mar-89  1325	CL-Cleanup-mailer 	Re: Issue: LOAD-OBJECTS (Version 3) 
C01150 00226	∂20-Mar-89  1427	CL-Cleanup-mailer 	Re: Issue: LOAD-OBJECTS (Version 3) 
C01152 00227	∂20-Mar-89  1536	Common-Lisp-Object-System-mailer 	Re: Understanding Method Combination.    
C01155 00228	∂20-Mar-89  1818	Common-Lisp-Object-System-mailer 	Re: Understanding Method Combination.    
C01158 00229	∂21-Mar-89  0843	Common-Lisp-Object-System-mailer 	Compile Time Class Creation (was: remote environments)  
C01163 00230	∂23-Mar-89  0915	CL-Windows-mailer 	Issue STREAM-DEFINITION-BY-USER (V1)
C01206 00231	∂23-Mar-89  1503	CL-Windows-mailer 	Issue STREAM-DEFINITION-BY-USER (V1)
C01249 00232	∂02-Apr-89  1536	RPG 	Implementation of CLOS   
C01251 00233	∂03-Apr-89  1421	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY   
C01255 00234	∂03-Apr-89  1453	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY   
C01259 00235	∂03-Apr-89  1510	Common-Lisp-Object-System-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY    
C01265 00236	∂03-Apr-89  1603	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
C01270 00237	∂04-Apr-89  0909	Common-Lisp-Object-System-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
C01272 00238	∂06-Apr-89  1715	Common-Lisp-Object-System-mailer 	[kempf%Sun:COM:Xerox: CLOS Slot Subclassing Rule Violates    
C01277 00239	∂07-Apr-89  0835	Common-Lisp-Object-System-mailer 	[kempf%Sun:COM:Xerox: CLOS Slot Subclassing Rule Violates    
C01279 00240	∂09-Apr-89  1420	Common-Lisp-Object-System-mailer 	Re: [kempf%Sun:COM:Xerox: CLOS Slot Subclassing Rule Violates Contravariance]    
C01284 00241	∂10-Apr-89  1326	Common-Lisp-Object-System-mailer 	Re: [kempf%Sun:COM:Xerox: CLOS Slot Subclassing Rule Violates
C01287 00242	∂11-Apr-89  2331	Common-Lisp-Object-System-mailer 	Chap 3 question: Class of allocated instances.
C01290 00243	∂12-Apr-89  0814	Common-Lisp-Object-System-mailer 	Chap 3 question: Class of allocated instances.
C01293 00244	∂12-Apr-89  0950	Common-Lisp-Object-System-mailer 	Chap 3 question: Class of allocated instances.
C01296 ENDMK
C⊗;
∂16-May-88  1139	Common-Lisp-Object-System-mailer 	CLOS document numbers for June meeting   
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 16 May 88  11:37:59 PDT
Received: by labrea.stanford.edu; Mon, 16 May 88 11:37:44 PDT
Received: from sunvalleymall.lucid.com by edsel id AA25773g; Mon, 16 May 88 11:13:24 PDT
Received: by sunvalleymall id AA28381g; Mon, 16 May 88 11:16:26 PDT
Date: Mon, 16 May 88 11:16:26 PDT
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8805161816.AA28381@sunvalleymall.lucid.com>
To: common-lisp-object-system@sail.stanford.edu
Subject: CLOS document numbers for June meeting

CLOS chapters 1&2:	88-002R
CLOS chapters 3:	88-003R

∂16-May-88  1524	Common-Lisp-Object-System-mailer 	Chapter 2  
To:   common-lisp-object-system@SAIL.Stanford.EDU    
From: Linda DeMichiel <LGD@SAIL.Stanford.EDU>


New Chapter 2 files are now available as functi.*[cls,lsp] on sail.
This material should now be up-to-date except for whatever we decide
to do with check-keyword-arguments.

Please send comments and corrections to me by Thursday morning.

-lgd

∂17-May-88  1340	Common-Lisp-Object-System-mailer 	Re: check-keyword-arguments    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 May 88  13:40:43 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 MAY 88 13:38:44 PDT
Date: 17 May 88 13:38 PDT
Sender: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: check-keyword-arguments   
In-reply-to: Dick Gabriel <RPG@SAIL.Stanford.EDU>'s message of 15 May 88 13:56
 PDT
To: RPG@SAIL.Stanford.EDU
cc: common-lisp-object-system@SAIL.Stanford.EDU
Message-ID: <880517-133844-2742@Xerox>

    I have no worries that someone who is writing his own version
    of make-instance could look in chapter 3 or 4 to find out how to do
    error checking. Therefore, only a check-keyword-arguments that is
    more generally useful justifies going beyond specifying a
    procedural definition of make-instance that is reasonable only for
    correct invocations of it.

I am now satisfied that your more general version of check-keyword-arguments can
be useful.  It would be good to have this last issue for chapter 2
(check-keyword-arguments) settled, and am happy to have it as last specified.   

∂18-May-88  1101	Common-Lisp-Object-System-mailer   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 18 May 88  11:01:24 PDT
Received: by ti.com id AA20889; Wed, 18 May 88 07:13:51 CDT
Received: from Jenner by tilde id AA06761; Wed, 18 May 88 07:12:44 CDT
Message-Id: <2788949394-1458237@Jenner>
Date: Wed, 18 May 88  07:09:54 CDT
From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
To: common-lisp-object-system@SAIL.STANFORD.EDU

Subject: Re: check-keyword-arguments   
In-Reply-To: Msg of 17 May 88 13:38 PDT from Danny Bobrow <Bobrow.pa@XEROX.COM>

     
     I am now satisfied that your more general version of check-keyword-arguments can
     be useful.  It would be good to have this last issue for chapter 2
     (check-keyword-arguments) settled, and am happy to have it as last specified.   

I agree.

Patrick.

∂18-May-88  1818	Common-Lisp-Object-System-mailer 	Comments on new draft chapter 1 (dated May 13 20:53)    
Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 May 88  18:18:27 PDT
Date: Wed, 18 May 88 21:22:40 EDT
From: "David A. Moon" <MOON@AI.AI.MIT.EDU>
Subject: Comments on new draft chapter 1 (dated May 13 20:53)
To: Common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <380679.880518.MOON@AI.AI.MIT.EDU>

1-12 fourth bullet: typos "an :documentation", "documentation documentation"

1-30 first bullet, also second dash bullet: These say an error is
signalled if call-next-method is called when there is no next method.
I thought we changed that to call a generic function whose name escapes
me at the moment, whose default method signals an error.

1-31 last bullet: ditto

1-35: Should the four simple mechanisms listed be augmented with
shared-initialize as a fifth bullet?

1-38 4th paragraph: maybe this should be "initialize-instance or
shared-initialize methods should be used instead."

1-39 penultimate paragraph: shared-initialize does not take three
arguments, it takes two required arguments plus a set of &key arguments.
The initialization arguments are passed as separate arguments, not as a list.

1-40 first paragraph after first three bullets: should be "whose first
parameter specializer is the class standard-object".

1-41 1st paragraph: same comment as 1-39.

1-41 last line: the parameter name is instance, not class, and the
parameter specializer is standard-object, not standard-class.

1-43 4th paragraph: There is a stray sentence fragment "the value
of the shared slot in the old class."  

1-43 6th paragraph: I think this should mention that the process can
also be triggered by an explicit call to the function make-instances-obsolete.

1-44 6th paragraph: Rather than saying update-instance-for-redefined-class
takes an &rest argument which is a list of initialization arguments, I
believe it is more correct terminology to say that it takes &key arguments
which are the initialization arguments.  The default method may receive these
with an &rest parameter, but the generic function's lambda-list says &key,
not &rest.

1-44 last paragraph: same comment as 1-39.

1-46 penultimate paragraph: same comment as 1-44 6th.

1-47 last paragraph: same comment as 1-39.

1-48 3rd paragraph: same comment as 1-44 6th.

1-48 last paragraph: same comment as 1-39.

∂18-May-88  2007	Common-Lisp-Object-System-mailer 	Comments on new draft chapter 2 (dated May 16 15:09)    
Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 May 88  20:06:58 PDT
Date: Wed, 18 May 88 23:11:11 EDT
From: "David A. Moon" <MOON@AI.AI.MIT.EDU>
Subject: Comments on new draft chapter 2 (dated May 16 15:09)
To: Common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <380731.880518.MOON@AI.AI.MIT.EDU>

There is also one comment on chapter 1 in here.

2-6 first paragraph: I'm not sure what is meant by behavior intrinsic to a
generic function itself.  I think this probably means a contract that all
methods must obey (as distinguished from idiosyncratic behavior of one
particular method).

2-12: This says call-next-method signals an error, but I thought we
changed it to call a generic function whose default method signals an error.

2-15: In the defmethod, change "&rest initargs" to "&key" for better style,
since this method doesn't use or define any initargs, it should have an
empty set of &key parameters.  Also this method should be a :before method;
not a :after method, because we want to initialize the slots ourselves,
not let the primary method initialize them from initforms then reinitialize
them ourselves.  I think 1-44 and 1-47 should be modified to reflect this
valid use of :before methods for the two update- functions; they differ
in this respect from initialize-instance and reinitialize-instance.

2-17: The method signatures imply that only standard classes have names,
but I believe the intent was that all classes have names.  Certainly
built-in and structure classes do have names.

2-21 3rd paragraph: Someone complained that "The slot-name argument is
a symbol that can be used as a Common Lisp variable name." was ambiguous.
What we mean is that the symbol is syntactically valid for use as a
variable name, what we don't mean is that referencing a variable with
this name will access the slot.  This should be rephrased if possible.

2-33 last paragraph: The value returned by define-method-combination
should be the method combination meta object (now that we have them),
not the name.

2-37 2nd paragraph: I don't understand what this paragraph is doing
here.  Keyword options to what?  Did this paragraph drift in from
somewhere earlier in the define-method-combination section perhaps?

2-43: There is documentation for slot descriptor objects now too.
Since only chapter 3 describes those, I don't know whether slot
documentation should be documented in the normal way, or just
mentioned as a remark.  I think I prefer the former.

2-45 4th paragraph: Because of the way rule 4 for lambda-list
congruence is defined, I think this has to speak not of the old
and new lambda-lists for the generic function being congruent,
but of the new lambda-list for the generic function being congruent
with the lambda-lists of all existing methods.  If an implementation
can sometimes optimize this into a comparison with the old lambda
list for the generic function, that's merely an optimization.

2-55 2nd paragraph: I don't think the system supplied primary
method for initialize-instance checks the validity of the arguments,
since chapter 1 says make-instance takes care of that.  Unlike
reinitialize-instance, initialize-instance is not meant to be
called by the user.

2-55 Remarks field: This is not really accurate, as the generic
functions for which methods can be defined varies.  Chapter 1
describes this better, maybe the description should not be
repeated here.  It would be useful to have a remark that the programmer
is intended to define :after methods for initialize-instance.

2-58: Formatting of method signatures is particularly ugly here.
How about right-justifying "[Primary Method]" throughout this chapter?

2-74,5,6: Are you sure slot-boundp, slot-exists-p, and slot-makunbound
are generic?  slot-value isn't.  I guess Gregor has final say on this point.

2-85: Same comments as for 2-15.

2-90 first remarks paragraph: same comment as for 2-45.

2-92: with-slots should cross-reference with-accessors

∂19-May-88  1613	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
To:   common-lisp-object-system@SAIL.Stanford.EDU    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


I want to present one more alternative to the initargs checking
problem. This alternative was the result of a couple of hours'
discussion with Guy Steele tuesday night. There are two parts to
it. One is the real technical proposal, and the remainder is the
packaging for chapter 1.

We could introduce a new generic function called valid-keywords, which
takes an object; if it is something with keywords (like a generic
function, a method, or a function), valid-keywords returns two values: a
list of the explicitly named keywords and a boolean which states whether
&allow-other-keys had been specified in the definition.

Then we could write make-instance like this:

(defmethod make-instance ((class standard-class) &rest initargs)
  (setq initargs (default-initargs class initargs))
  (let* ((proto (class-prototype class))
         (methods 
           (union
	     (compute-applicable-methods #'allocate-instance `(,class))
	     (union
	       (compute-applicable-methods #'initialize-instance `(,proto nil))
	       (compute-applicable-methods #'shared-initialize `(,proto))))))
	(unless
	 (subsetp
	  (let ((keys '()))
	       (do ((plist initargs (cddr plist)))
		   ((null plist) keys)
		   (push (car plist) keys)))
	  (union 
	    (class-slot-initargs class)
	    (reduce #'union (mapcar #'valid-keywords methods))))
	(error ...)))
  (let ((instance (apply #'allocate-instance class initargs)))
    (apply #'initialize-instance instance initargs)
    instance))

Or something like this: the details of the code are not important
for chapters 1 and 2.

This is not a very simple piece of code to present in chapter 1. So
the proposal requires a sample of how to explain this:

\beginsubSection{Definitions of Make-Instance and Initialize-Instance}

The generic function {\bf make-instance} behaves as if it were defined as
follows, except that certain optimizations are permitted:

\screen!

(defmethod make-instance ((class standard-class) &rest initargs)
  (setq initargs (default-initargs class initargs))
  ...
  (let ((instance (apply #'allocate-instance class initargs)))
    (apply #'initialize-instance instance initargs)
    instance))

(defmethod make-instance ((class-name symbol) &rest initargs)
  (apply #'make-instance (find-class class-name) initargs))

\endscreen!

The elided code in the definition of {\bf make-instance} checks the
supplied initialization arguments to determine whether an initialization
argument was supplied that neither filled a slot nor supplied an argument
to an applicable method. This check could be implemented using the generic
functions {\bf class-prototype}, {\bf compute-applicable-methods}, {\bf
valid-keywords}, and {\bf class-slot-initargs}. See Chapter~3 for a
description of this initialization argument check.

The generic function {\bf initialize-instance} behaves as if it were
defined as follows, except that certain optimizations are permitted:

\screen!

(defmethod initialize-instance ((class standard-class) &rest initargs)
  (apply #'shared-initialize instance t initargs)))
 
\endscreen!

These procedures can be customized at either the Programmer Interface level,
the meta-object level, or both.  

Customizing at the Programmer Interface level includes using the {\bf
:initform}, {\bf :initarg}, and {\bf :default-initargs} options to
{\bf defclass}, as well as defining methods for {\bf make-instance}
and {\bf initialize-instance}.  It is also possible to define
methods for {\bf shared-initialize}, which would be invoked by the
generic functions {\bf reinitialize-instance}, {\bf
update-instance-for-redefined-class}, {\bf
update-instance-for-different-class}, and {\bf
initialize-instance}.  The meta-object level supports additional
customization by allowing methods to be defined on {\bf
make-instance}, {\bf default-initargs}, and {\bf
allocate-instance}.  Chapters~2 and~3 document each of these generic
functions and the system-supplied primary methods.

Implementations are permitted to make certain optimizations to {\bf
initialize-instance} and {\bf shared-initialize}.  The
description of {\bf shared-initialize} in Chapter~2 mentions the
possible optimizations.

Because of optimization, the check for valid initialization arguments
might not be implemented using the generic functions {\bf
class-prototype}, {\bf compute-applicable-methods}, {\bf valid-keywords},
and {\bf class-slot-initargs}. In addition, methods for the generic
function {\bf default-initargs}, and the system-supplied primary methods
for {\bf allocate-instance}, {\bf initialize-instance}, and {\bf
shared-initialize} may not be called on every call to {\bf make-instance}
or may not receive exactly the arguments that would be expected.

\endsubSection%{Definitions of MAKE-INSTANCE and Initialize-Instance}

∂20-May-88  1508	Common-Lisp-Object-System-mailer 	Comments on new draft chapter 1 (dated May 13 20:53)    
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 May 88  15:08:46 PDT
Received: from PERON.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 20 May 88 17:32-EDT
Date: Fri, 20 May 88 17:35 EDT
From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
Subject: Comments on new draft chapter 1 (dated May 13 20:53)
To: common-lisp-object-system@sail.stanford.edu
Message-ID: <19880520213530.4.MLY@PERON.AI.MIT.EDU>

These comments come from someone who has been keeping an eye on the
cl-o-o-p mail, but hasn't been reading the specs regularly and closely.
I'm omitting remarks which would overlap those in
<380679.880518.MOON@AI.AI.MIT.EDU>

A general remark on all of the documents -- as a non-American and as
something of a pedant I feel my blood-pressure rising every time I
encounter ``congruent with'' or ``different than'' in the documents (as
opposed to ``congruent to'' and ``different from'' respectively.)  Is
this really Standard American English?

Another general remark is that Chapter 1 and Chapter 2 do not stand very
well apart from Chapter 3 -- there are too many functions mentioned in
passing which are never defined in any further fashion (or even
mentioned again!)  This certainly makes for rather hard reading and
comprehension.




1-22 2nd PP in `Intro to methods':  The first and second sentences
seem to be too directly contradictory.  I would change the first to
``A method object is not NECESSARILY a function an IN GENERAL cannot be
invoked as a function.''

1-25 To this reader, the statement in the 4th enumerated PP that ``The
checking of the validity of keyword names is done in the generic
function, not in each method'' seems inconsistent with the second PP on
1-26 ``If a method is passed a keyword argument is does not accept, an
error is signaled.''  Is the indent to draw some distinction between &key
args from DEFGENERIC and those which come from random DEFMETHODs?  If
so, this should be made a lot clearer.

1-31 2nd PP.  ``to the :method-combination option to defgeneric or TO
THE :METHOD-COMBINATION OPTION TO any of the other forms that specify
generic function options.''  The uppercase text seems redundant.

1-31 5th PP.  I would replace this with ``The simple build-in method
combination types COULD HAVE BEEN defined...''

1-32 <foo>

1-33 Penultimate PP.  I am probably just plain confused on this point,
but is it possible that ``and instances of the classes standard-method,
...''  should read just ``the classes standard-method, ...''?  The
reference to standard-method in the following bulleted PP reinforces my
probably-mistaken belief.

1-39 3rd PP.  I question the use of the word ``captured'' (which occurs
in other places in both Chapters 1 and 2.)  ``Inherited'' seems more
straight-forward to me.  This is probably just a personal preference.

1-39 Table.  The last line would seem to imply that the defaulted
initlist must always be '(a 1 a 2 b 2), ruling out the `optimization'
(a 1 b 2).  Is this the intent?  It seems to unnecessarily constrain the
behaviour of default-initargs methods.

1-39 The section `Shared-Initialize' The introduction of this section at
this point seems very unmotivated.  Nowhere above (except by implication
of the `--'-bulleted PPs on 1-37) is it made clear that
shared-initialize is an `underlying' method called by all the various
(re)initialization methods.  Some small preamble at the beginning of
this section would make a first-time reading of the the spec somewhat
easier.

     At this point I suppose I might as well express my misgivings about
the name `shared-initialize' -- it seems to imply to me something to do
with `shared' (ie class-allocated) slots or something like that.  For
what it's worth, I'll state that the names `initialize-slots,'
`basic-initialize' and even `common-initialize' (or even
`initialize'!) appeal to me more than `shared-initialize.'

1-39 Last PP.  I would write ``The second argument to shared-initialize
may be one of the following:''

1-40 First (bulleted) PP.  What if the instance doesn't have a slot with
named by one of the elements of the list?  Is it ``an error?''  Is
slot-missing called?

1-40 4th bulleted PP.  It should be noted that ``This happens regardless
of whether or not the slot is specified by the second argument.''  or
something along those lines -- make it completely clear that this first
step in initialization depends only on the &key initarg, not on the
slot-name-specification arg.  I'd also like to see a similar comment in
the Chapter 2 doc for shared-initialize.

1-41 `Definitions of make-instance and initialize-instance'
I think that it would make the manual a lot easier to read if similar
sample definitions were provided for the other initializations methods
(reinitialize-instance, update-instance-for-xxx, ...)  I think that
moving this section of sample definitions forward in the manual (perhaps
before the `shared-initialize' section, perhaps even very early in
`Objection Creation and Initialization') would provide much better
understanding of what the various generic functions do.
     This would also somewhat alleviate my above-mentioned problems with
the unmotivated appearance of `shared-initialize.'
     When I started reading from `Object Creation and Initialization' I
encountered a whole slew of names of generic functions on which I would
define methods, but no real reason for why I should want to do so for
around 7 more pages.
     I personally find it much easier to be presented with an overall
framework of code and then later `fill in the blanks' by reading what
the purpose of the various functions are than to wade though pages of
passing references to lots of functions before discovering how they fit
together and how they are supposed to be useful.

1-41 Definition of make-instance.  Is nobody else bothered by the fact
that the use DEFAULT-INITARGS may be a consful operation in the presence
of :default-initargs?  It would be very easy for the evaluation of
DEFAULT-INITARGS to consume more storage (to construct a merged initargs
list) than that of ALLOCATE-INSTANCE does in creation of the instance
itself! 

     My first reaction to this is to suggest a definition like:
    (defmethod make-instance ((class standard-class) &rest initargs)
      (apply #'with-defaulted-initargs
             (lambda (&rest defaulted-initargs)
               ...initarg error-checking code...
               (let ((instance (apply #'allocate-instance
                                      class defaulted-initargs)))
                 (apply #'initialize-instance instance defaulted-initargs)
                 instance))
             class initargs))
[where any implementation worth its salt would provide some way to
declare the dynamic extent of the INITARGS argument and the
LAMBDA-expression.]
     Of course there are other ways to do this sort of thing.

     I don't believe that the permissible optimizations mentioned are
sufficient to stop me worrying about this point.

     So, has nobody else considered this issue, or does nobody else
consider it an issue?

1-41 Last PP.  What ``certain optimizations are permitted.''  Nothing is
mentioned here or in the Chapter 2 description of initialize-instance to
explain what these might be, any how they might affect writers of
methods on initialize-instance or shared-initialize.  The Chapter 2
description of shared-initialize explains this -- there should be some
xref.

1-42 Last PP.  I found this hard to read.  Suggestion:
``As a result of various optimizations, not all of the functions and
methods involved in initialization need necessarily be called on every
call to {\bf make-instance} and, if called, they may not receive exactly
the arguments that one would expect based on the sample implementation
above.''
     The example of a permitted optimization is bogus, because
check-keyword-arguments is not a method, and so the user has no business
redefining it, and so user methods have no way of telling whether it has
already been called or not (since it is stated that it won't signal an
error.)
     My feeling is that the vagueness in this section is very
unpleasant, and quite inconsistent with the general precision in the
rest of the document.  I have some ideas on how to improve this, if
there is any interest in re-opening this issue and in listening to them.

1-43 6th PP.  The aside ``This two-step process ...'' disrupts the
description of what the process is.  Is should be moved below, after the
sentence ``... and other user-defined actions.''

1-44 6th PP, 1-46 last PP, 1-48 4th PP.
I find these incredibly disjointed.  For starters, only half of the
contract of the ``system-supplied primary method'' is mentioned -- the
other half is to be found two paragraphs down -- in a different section!
Secondly, I don't think much would be lost be replacing each occurrence
of the intrusively-long

  Initialization arguments are declared as valid by using the {\bf
  :initarg} option to {\bf defclass} or by defining methods for {\bf
  <method-name>} or for {\bf shared-initialize}.  See the section
  ``Declaring the Validity of Initialization Arguments'' for more information.

with simply:

  (See the section ``Declaring the Validity of Initialization Arguments''
  for more information.)

Here's a suggested rewrite (I'd find code easier to read than this
turgid techno-English any day...):
  There is a system-supplied primary method for {\bf
  update-instance-for-redefined-class} whose parameter specializer for
  its instance argument is the class {\bf standard-object}.   This
  method first checks the validity of initialization arguments and
  signals an error if an initialization argument is supplied that is not
  declared as valid.  (See the section ``Declaring the Validity of
  Initialization Arguments'' for more information.)  Then it calls the
  generic function {\bf shared-initialize} with arguments of the
  instance, a list of names of the newly added slots, and the
  initialization arguments it received.

The now-redundant second half of the descriptions of these methods (with
appear in the ``Customizing foo'' sections) could be replaced by just

  Methods for {\bf shared-initialize} may be defined to customize class
  redefinition.  See the section ``Shared-Initialize'' for more
  information.





Finally, just to be contentious (I'm not inviting replies):

* I'm still convinced (after two years (even after reading all the
archived mail on the subject)) that optionals should be defaulted in the
generic function rather than the methods.... Oh well.

* I think it is a real loss that there is no way of specifying an
`interface function' such as New Flavors has.  The mess with the stupid
optional arg for DOCUMENTATION methods in chapter 2 is an example of
this.

* I'm aware of the problems they entail -- however I still find it a
pity that there is no provision for `private' methods and slots.

* I find the omission of defclass :constructors to be a significant
loss, based on past experience with implementing this sort of thing.

* I rely upon and heavily use New Flavors defun-in-method.  I don't see
how I could get equivalent performance via the use of WITH-SLOTS (since
I don't believe (the equivalent of) usage of a mapping table will be done
outside of method bodies.)

* I think that the use of STANDARD method combination for the various
initialization methods is a mistake.  It is too easy (for a ready
example, see the mistake Moon pointed out in <380731.880518.MOON@AI.AI.MIT.EDU>
about 2-15) to bash the useful system-defined method.  It is not at all
clear to me that it is ever useful to do this deliberately -- the only
thing it could do (which could not be done by defining an `auxiliary'
method on it or on shared-initialize) is inhibit error-checking.
  I hold that the `two-pass' method-combination used in Flavors for
initialize-instance is the right sort of thing: initialize-instance and
reinitialize-instance should use `progn-with-:after' method combination,
and update-instance-for-redefined-class and
update-instance-for-different-class should use `progn-with-:before'
method combination (I can't think of a use for :after methods on these
gf's.)
  Besides, use of non-STANDARD method-combination would actually show
readers that all this method-combination hair is actually good for
anything!

* I find the `evalness' of define-method-combination very disturbing.
It seems to me that a full lisp compiler or evaluator will need to be
present in any world into are loaded methods on generic functions which
use user-defined method-combination.  I would -very- much like to be
convinced that this isn't the case.

* IWBNI GET and (SETF GET) were made generic, though I suppose the same
sort of argument could be made for dozens of other CLtL functions.

∂20-May-88  1703	Common-Lisp-Object-System-mailer 	Comments on new draft chapter 1 (dated May 13 20:53)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 May 88  17:03:03 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 408054; 20 May 88 20:02:25 EDT
Date: Fri, 20 May 88 20:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Comments on new draft chapter 1 (dated May 13 20:53)
To: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <19880520213530.4.MLY@PERON.AI.MIT.EDU>
Message-ID: <19880521000213.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 20 May 88 17:35 EDT
    From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>

Comments on a subset of your comments, not to imply that the remainder
should be ignored.  In general I agree with them.

    1-25 To this reader, the statement in the 4th enumerated PP that ``The
    checking of the validity of keyword names is done in the generic
    function, not in each method'' seems inconsistent with the second PP on
    1-26 ``If a method is passed a keyword argument is does not accept, an
    error is signaled.''  Is the indent to draw some distinction between &key
    args from DEFGENERIC and those which come from random DEFMETHODs?  If
    so, this should be made a lot clearer.

I missed this one in my recent review of the document.
I believe the word "method" in the 2nd pp on 1-26 is a typo and should
be "generic function."  Clearer would be "If a generic function is passed
a keyword argument that no applicable method accepts, an error is signaled."
Also, for consistency with the last paragraph on CLtL p.62, it should be
"an error should be signaled" rather than "an error is signaled."  Not
that I am a fan of implementations that allow you to turn off error checking.

    1-32 <foo>

I don't follow.

    1-33 Penultimate PP.  I am probably just plain confused on this point,
    but is it possible that ``and instances of the classes standard-method,
    ...''  should read just ``the classes standard-method, ...''?  The
    reference to standard-method in the following bulleted PP reinforces my
    probably-mistaken belief.

No, the text is correct as it stands.  Everything involving meta objects is
inherently confusing because it's difficult to keep the two levels straight.

    1-39 3rd PP.  I question the use of the word ``captured'' (which occurs
    in other places in both Chapters 1 and 2.)  ``Inherited'' seems more
    straight-forward to me.  This is probably just a personal preference.

"Captured" refers to lexical capturing, not class inheritance.  I'm not
sure it's necessary to repeat "captured" periodically; we could just leave
it to the explanation on 1-10 and again on 1-35.

    1-39 Table.  The last line would seem to imply that the defaulted
    initlist must always be '(a 1 a 2 b 2), ruling out the `optimization'
    (a 1 b 2).  Is this the intent?  It seems to unnecessarily constrain the
    behaviour of default-initargs methods.

"a 2" was not put in by defaulting, it was supplied explicitly by the caller.
Given that, I don't think we want to change the table.

    1-39 The section `Shared-Initialize' The introduction of this section at
    this point seems very unmotivated.  Nowhere above (except by implication
    of the `--'-bulleted PPs on 1-37) is it made clear that
    shared-initialize is an `underlying' method called by all the various
    (re)initialization methods.  Some small preamble at the beginning of
    this section would make a first-time reading of the the spec somewhat
    easier.

The spec is deliberately made difficult to read to discourage people from
making implementations without reading it slowly and carefully :-)

	 At this point I suppose I might as well express my misgivings about
    the name `shared-initialize' -- it seems to imply to me something to do
    with `shared' (ie class-allocated) slots or something like that.  For
    what it's worth, I'll state that the names `initialize-slots,'
    `basic-initialize' and even `common-initialize' (or even
    `initialize'!) appeal to me more than `shared-initialize.'

The false connotation of shared slots is the same comment I had.  However,
all four of your suggested alternatives have problems, and we spent so much
time trying to find a better name that I think we should go with the one
we have for this round of the document, and let X3J13 instruct us to change
it if they so desire.

    1-40 First (bulleted) PP.  What if the instance doesn't have a slot with
    named by one of the elements of the list?  Is it ``an error?''  Is
    slot-missing called?

You're right, we need to specify this.  Let's make it "the results are
unspecified."

    1-41 Definition of make-instance.  Is nobody else bothered by the fact
    that the use DEFAULT-INITARGS may be a consful operation in the presence
    of :default-initargs?  It would be very easy for the evaluation of
    DEFAULT-INITARGS to consume more storage (to construct a merged initargs
    list) than that of ALLOCATE-INSTANCE does in creation of the instance
    itself! 

Of course.  But the spec defines the semantics of the language, not how
to do semantics-preserving implementation-dependent optimizations.  I
don't think complicating the specification to make it slightly more
obvious how to optimizations is a good tradeoff.  Also, with reasonable
garbage collectors, which are starting to emerge even on traditional
hardware, consing is not such a burden.

    Finally, just to be contentious (I'm not inviting replies):

Yes, CLOS definitely has that design-by-committee aroma.

    * I find the `evalness' of define-method-combination very disturbing.
    It seems to me that a full lisp compiler or evaluator will need to be
    present in any world into are loaded methods on generic functions which
    use user-defined method-combination.  I would -very- much like to be
    convinced that this isn't the case.

I don't understand your point.  How is define-method-combination different
from defmacro in this respect?  Perhaps you've been misled by the way the
spec describes everything as if it was interpreted into thinking that it
cannot be compiled?

∂20-May-88  2010	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 20 May 88  20:09:12 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191392; Fri 20-May-88 23:08:50 EDT
Date: Fri, 20 May 88 23:08 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: check-keyword-arguments   
To: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: The message of 19 May 88 19:13 EDT from Dick Gabriel <RPG@SAIL.Stanford.EDU>
Message-ID: <19880521030857.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 19 May 88  1613 PDT
    From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

    I want to present one more alternative to the initargs checking
    problem.

[Getting rid of check-initargs & successors, writing the code inline,
and putting it in chapter 3.]

This sounds good to me, with a couple modifications suggested below.
Let's go with it.

    We could introduce a new generic function called valid-keywords, which
    takes an object; if it is something with keywords (like a generic
    function, a method, or a function), valid-keywords returns two values: a
    list of the explicitly named keywords and a boolean which states whether
    &allow-other-keys had been specified in the definition.

function-keywords would be a better name.  Otherwise okay.
I have no quarrel with the dual return values.
[Yes, I know (subtypep 'method 'function) => nil t.  Nonetheless,
in this context the method is used in a functionesque way.]

I assume method-applicable-keywords, p.27 of the most recent draft
of ch.3 that I've seen (the one handed out at X3J13 in March), would
go away.

    Then we could write make-instance like this:

    (defmethod make-instance ((class standard-class) &rest initargs)
      (setq initargs (default-initargs class initargs))
      (let* ((proto (class-prototype class))
	     (methods 
	       (union
		 (compute-applicable-methods #'allocate-instance `(,class))
		 (union
		   (compute-applicable-methods #'initialize-instance `(,proto nil))
		   (compute-applicable-methods #'shared-initialize `(,proto))))))

I think you want append rather than union, since there won't be any
methods in common between distinct generic functions.  Also the args for
initialize-instance and shared-initialize have accidentally gotten
interchanged.

	    (unless
	     (subsetp
	      (let ((keys '()))
		   (do ((plist initargs (cddr plist)))
		       ((null plist) keys)
		       (push (car plist) keys)))
	      (union 
		(class-slot-initargs class)
		(reduce #'union (mapcar #'valid-keywords methods))))
	    (error ...)))
      (let ((instance (apply #'allocate-instance class initargs)))
	(apply #'initialize-instance instance initargs)
	instance))

∂20-May-88  2206	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
To:   common-lisp-object-system@SAIL.Stanford.EDU    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


I think Moon's suggestion for the name FUNCTION-KEYWORD is acceptable.
Here is the corrected code (Having Moon around to read code is
almost as good as having a computer. In fact, it's better because
sometimes he cracks a joke.):

(defmethod make-instance ((class standard-class) &rest initargs)
  (setq initargs (default-initargs class initargs))
  (let* ((proto (class-prototype class))
         (methods 
           (append
	     (compute-applicable-methods #'allocate-instance `(,class))
	     (compute-applicable-methods #'initialize-instance `(,proto))
	     (compute-applicable-methods #'shared-initialize `(,proto nil)))))
	(unless
	  (subsetp
	    (let ((keys '()))
	      (do ((plist initargs (cddr plist)))
		  ((null plist) keys)
		(push (car plist) keys)))
	    (union 
	      (class-slot-initargs class)
	      (reduce #'union (mapcar #'function-keywords methods))))
	  (error ...)))
  (let ((instance (apply #'allocate-instance class initargs)))
    (apply #'initialize-instance instance initargs)
    instance))

∂21-May-88  0017	Common-Lisp-Object-System-mailer 	Mlynarik's comments  
To:   common-lisp-object-system@SAIL.Stanford.EDU    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


First I'll address the general grammatical comments. As far as I can tell
by reading the OED, ``congruent with'' is standard British English.  Using
Webster's Second Unabridged - the most prescriptive American English
dictionary - I find ``congruent with'' used in general contexts and in
most mathematical contexts.  My perusal of math texts seems to indicate
``congruent to'' is acceptable when discussing number theory. I cannot
find explicit grammatical justification for ``congruent to'' in any
context. Because we are not talking about number theory, I don't believe
any changes are necessary.

It is currently correct to use the following rules for ``different'':  The
phrase ``different from'' is used when introducing a phrase while
``different than'' is used when introducing a clause. My references claim
``different from'' and ``different than'' have both appeared for the
last 300 years. British usage admits ``different to.''

Note there is no use of ``different than'' (or ``different from'')
in chapter 1.

To comment further on the grammar in chapters 1 and 2. Linda and I are
both relatively careful writers in terms of grammar, and I can assure you
that we have not dashed off this piece.  Furthermore, we have engaged copy
editors to proofread major drafts of these chapters before they are sent
out. The style of writing might be academic, but I believe it corresponds
to acceptable Amercian English in all cases, and even the editors of the
OED now accept American usage as standard.

The remainder of this message is a response to Richard's comments. I have left
out specific comments to which Moon responded with remarks with which I
agree.

Richard writes:

``1-22 2nd PP in `Intro to methods':  The first and second sentences
seem to be too directly contradictory.  I would change the first to
``A method object is not NECESSARILY a function an IN GENERAL cannot be
invoked as a function.'' ''

The sentences in question are:

``A method object is not a function and cannot be invoked as a function.  An
implementation may extend the \OS\ so that method objects are functions.''

The reason it is stated this way is that no one writing portable code can
take them to be functions, but we do not require them to not be functions
in all implementations.  If we wrote it your way then someone could
legitimately understand that within a single implementation a particular
method object may or may not be a function. 

The style we use consistently throughout is to state a constraint
and then allow extensions.

Richard writes:

``1-25 To this reader, the statement in the 4th enumerated PP that ``The
checking of the validity of keyword names is done in the generic
function, not in each method'' seems inconsistent with the second PP on
1-26 ``If a method is passed a keyword argument is does not accept, an
error is signaled.''  Is the indent to draw some distinction between &key
args from DEFGENERIC and those which come from random DEFMETHODs?  If
so, this should be made a lot clearer.''

Moon's remark is correct and the passage has been repaired.

Richard writes:

``1-31 2nd PP.  ``to the :method-combination option to defgeneric or TO
THE :METHOD-COMBINATION OPTION TO any of the other forms that specify
generic function options.''  The uppercase text seems redundant.''

It is redundant and intentionally so: You cannot possibly misread
the current version. A misreading would be

``To specify that a generic function is to use one of these method
combination types, the name of the method combination type is given as the
argument ... to any of the other forms that specify generic function
options.''

Richard writes:

``1-31 5th PP.  I would replace this with ``The simple build-in method
combination types COULD HAVE BEEN defined...'' ''

``Could have been'' but weren't? Your rewrite talks about an implementation
choice that may or may not be relevant, whereas the current language
discusses semantics.

Richard writes:

``1-32 <foo>''

I agree with Richard on the weirdness of this description, but
I could not (and still cannot) think of a more precise approach to
describing this. I have spent weeks on the bulleted item over the
last 2 years.

Richard writes:

``1-39 Last PP.  I would write ``The second argument to shared-initialize
may be one of the following:''  ''

Right.

Richard writes:

``1-39 The section `Shared-Initialize' The introduction of this section at
this point seems very unmotivated.  Nowhere above (except by implication
of the `--'-bulleted PPs on 1-37) is it made clear that
shared-initialize is an `underlying' method called by all the various
(re)initialization methods.  Some small preamble at the beginning of
this section would make a first-time reading of the the spec somewhat
easier.''

Right. I added such an introduction to shared-initialize early
in the section.

Richard writes:

``1-40 4th bulleted PP.  It should be noted that ``This happens regardless
of whether or not the slot is specified by the second argument.''  or
something along those lines -- make it completely clear that this first
step in initialization depends only on the &key initarg, not on the
slot-name-specification arg.  I'd also like to see a similar comment in
the Chapter 2 doc for shared-initialize.''

Right.

Richard writes:

``1-41 Last PP.  What ``certain optimizations are permitted.''  Nothing is
mentioned here or in the Chapter 2 description of initialize-instance to
explain what these might be, any how they might affect writers of
methods on initialize-instance or shared-initialize.  The Chapter 2
description of shared-initialize explains this -- there should be some
xref.''

I thought it already cross-references to shared-initialize.

Richard writes:

``1-42 Last PP.  I found this hard to read.  Suggestion....''

This paragraph has been rewritten based on the newthink on the
check-initargs problem.

Richard writes:

``     My feeling is that the vagueness in this section is very
unpleasant, and quite inconsistent with the general precision in the
rest of the document.  I have some ideas on how to improve this, if
there is any interest in re-opening this issue and in listening to them.''

Yes, I would like to hear your ideas.

Richard writes:

``1-43 6th PP.  The aside ``This two-step process ...'' disrupts the
description of what the process is.  Is should be moved below, after the
sentence ``... and other user-defined actions.'' ''

This paragraph is now different enough that this comment isn't as valid.
In particular, other circumstances have been added in which the process
can start up, and the discussion of when it can happen is the current
focus of the paragraph.

Richard writes:

``1-44 6th PP, 1-46 last PP, 1-48 4th PP.
I find these incredibly disjointed.  For starters, only half of the
contract of the ``system-supplied primary method'' is mentioned -- the
other half is to be found two paragraphs down -- in a different section!
....''

Good idea. I've so modified the sections.

			-rpg-

∂21-May-88  0651	Common-Lisp-Object-System-mailer 	Comments on current state of Initialization.  
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 21 May 88  06:51:05 PDT
Received: by labrea.stanford.edu; Sat, 21 May 88 06:51:30 PDT
Received: from bhopal.lucid.com by edsel id AA20037g; Sat, 21 May 88 06:40:47 PDT
Received: by bhopal id AA08392g; Sat, 21 May 88 06:44:29 PDT
Date: Sat, 21 May 88 06:44:29 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805211344.AA08392@bhopal.lucid.com>
To: common-lisp-object-system@sail.stanford.edu
Subject: Comments on current state of Initialization.

Why should there still  be three initialization protocls: "shared-initialize",
"initialize-instance",  and "reinitialize-instance" (sp?).  

Why not just "initialize-instance" with a keyword argument for whether or 
not it is a first-time initialization?  In each case, the specialization
needed is over the instance, and not over the slots-for-initforms argument,
or the initargs argument, or any other arugment.  And so _most_ of the 
processing will be the same regardless of whether the caller is make-instance
or one of the update-instance-for-<munged>-class functions (i.e., whether 
initializing afresh or whether re-initializing).  In fact, for many classes 
I would guess that the particular list given as the 'slots-for-initforms' 
argument would adequately cover any necessary distinctions between fresh 
allocation and "update-instance-for-<munged>-class".  Direct user calls, if
any, could pass this keyword argument, rather than decide between two 
differently named functions.

I presume that the main primary method is the one whose chief purpose is to
set slots, first from the initargs and then from the initforms, and that this
wouldn't need to be modified by the user.  [In fact, letting the user change
this primary method is probably a mistake.]  Again, I would guess that most
user :after methods wouln't be concerned with the distinction between
"fixing up" the initialization of a fresh instance, and that of "fixing up"
the re-setting of slots on an "old" instance; in each case, the more 
important information is in the 'slots-for-initforms' argument.


In short, what I fail to see is any justification for hairing up the
protocol to inject a generic function that seems to have no particular
user benefit: reinitialize-instance.  Looking over back mail, I find
this one comment from Danny:

    Date: 8 Apr 88 15:37 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>
    Subject: Re: (re)initialization revisited 
    In-Reply-To: kempf@Sun.COM's message of Thu, 07 Apr 88 12:13:45 -0700
    To: kempf@Sun.COM
    Cc: common-lisp-object-system@SAIL.STANFORD.EDU

    Jim proposes removing some functions in the spec.  I sympathize with this 
    as a general goal.  But in this case I think it is misguided.  There are 
    really four concepts
    1) initializate (make a brand new instance have the right state)
    2) reinitialize (make an old instance have a "standard" starting state)
    3) class-changed (make a change from one form of current instance to another)
    4) update-instance-structure (make an appropriate current instance from an
    outdated instance.

    Because there are four concepts, there must be four entries so that users 
    can change what is done for each.  Collapsing concepts into a commonly 
    named fn just causes confusion.

    . . . 

    Reinititializing must potentially take into account old values on slots.
    Initialization never has to.  We introduced the general concept because we
    had two examples in CLOS itself that require it: instances of 
    standard-class, and instances of standard-generic-function.  Both must 
    take into account previous state of the objects to be changed.

But still, this is not justification for imposing a complexity that
will almost never be used by the end user, and for which there is an
adequate alternative: keyword argument to initialize-instance.  Note
that there is no need to split off re-initialization due to a difference
in the ways in which it might be specialized.


-- JonL --

∂21-May-88  1602	Common-Lisp-Object-System-mailer 	define-method-combination 
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 21 May 88  16:02:23 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191452; Sat 21-May-88 19:01:56 EDT
Date: Sat, 21 May 88 19:01 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: define-method-combination
To: Richard MlYNarIk <Mly@AI.AI.MIT.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <19880521191828.5.MLY@PERON.AI.MIT.EDU>
Message-ID: <19880521230158.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sat, 21 May 88 15:18 EDT
    From: Richard MlynBaOrik <Mly@AI.AI.MIT.EDU>

    [common-lisp-object-system@SAIL.STANFORD.EDU removed]

[Added back since I thought it was useful for the whole list to see
the reply.  I don't expect I'm embarrassing you.]

	Date: Fri, 20 May 88 20:02 EDT
	From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	    * I find the `evalness' of define-method-combination very disturbing.
	    It seems to me that a full lisp compiler or evaluator will need to be
	    present in any world into are loaded methods on generic functions which
	    use user-defined method-combination.  I would -very- much like to be
	    convinced that this isn't the case.

	I don't understand your point.  How is define-method-combination different
	from defmacro in this respect?  Perhaps you've been misled by the way the
	spec describes everything as if it was interpreted into thinking that it
	cannot be compiled?

    I'm wondering how add-method works.

    If one does a random add-method to a generic function (say by loading a
    file containing a defmethod form) then whenever the combined
    (`effective') method is created (at instance instantiation time or
    whenever) something has got to look at the lisp code produced by the
    `macroexpansion' of a define-method-combination form.  This
    macroexpasion can't be performed any earlier, because it depends on the
    applicable methods.

That's quite a reasonable concern to have, however we've thought of it.

The compiler can anticipate what add-method calls are going to be
produced by forms the compiler has seen, such as defmethod forms.  The
code resulting from method-combination can be predicted at compile time
and compiled then, with a simple mechanism to make sure at load time
that that pregenerated code gets used.  This is how it works in Flavors,
so that's an existence proof.

Of course if a program calls add-method at run time in a way the compiler
can't anticipate, such techniques can't win.  But I'd say that kind of
program, which changes its structure at run time, should not be surprised
to depend on having a compiler at run time.

    As I see it, either the lisp evaluator is used whenever the combined
    method is called or else the lisp code produced by
    define-method-combination has to be turned into something executable by
    `the machine.'

It's also true that an evaluator different from the Lisp evaluator can
be used.  For example, the form returned by the method combination
function can be recognized as an instance of a pattern and the effective
method can be a closure of a preexisting function that knows how to
"evaluate" such forms; the enclosed variables typically have methods or
lists of methods as their values.  The preexisting functions can even be
generated automatically when the system is compiled, from declarative
specifications (arrange for x type of method combination to work with n
applicable methods in role z).  Some types of method combination work
this way in Flavors in 7.2 [oh, I see you know that], and I'm told PCL
also works this way.  I assume that CLOS can work this way, too, using
the world's simplest pattern matcher to recognize forms returned by
method combination functions.

∂21-May-88  1605	Common-Lisp-Object-System-mailer 	Comments on current state of Initialization.  
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 21 May 88  16:04:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191453; Sat 21-May-88 19:04:12 EDT
Date: Sat, 21 May 88 19:04 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Comments on current state of Initialization.
To: Jon L White <edsel!jonl@labrea.stanford.edu>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <8805211344.AA08392@bhopal.lucid.com>
Message-ID: <19880521230422.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sat, 21 May 88 06:44:29 PDT
    From: Jon L White <edsel!jonl@labrea.stanford.edu>

    Why should there still  be three initialization protocls: "shared-initialize",
    "initialize-instance",  and "reinitialize-instance"?

    [Summary: replace reinitialize-instance with a keyword argument to
    initialize-instance --Moon]

Two reasons come immediately to mind: shared-initialize is also used when a
class is redefined or change-class is called; reinitialize-instance is to be
called directly by the user, but initialize-instance cannot be (review how
the keyword arguments get validated).

∂21-May-88  1923	Common-Lisp-Object-System-mailer 	define-method-combination 
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 May 88  19:23:33 PDT
Received: from PERON.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 21 May 88 22:24-EDT
Date: Sat, 21 May 88 22:27 EDT
From: Richarrd MLYnaRIk <Mly@AI.AI.MIT.EDU>
Subject: define-method-combination
To: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <19880521230158.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19880522022721.6.MLY@PERON.AI.MIT.EDU>

Before I launch into the usual tirade, I'd like to make a suggestion
which might have some hope of being considered:

define-method-combination should accept an option
  (:generic-function <symbol>)
and bind <symbol> to the relevant generic function.
This has much the same flavour as the existing :arguments option.
I think that this is a nicer solution than binding
a magic variable named `generic-function'.

======================================================================

I only partially believe what Moon says about define-method-combination.

On the whole, I find his arguments unfortunate sorts of thing to have to
claim, especially when there are another ways of declaring method
combination this which avoids this sort of problem.  (By constructing
closures rather than s-expressions.)

I do believe his arguments as applied to system-predefined
method-combination -- after all, and as he says, we have Flavors as an
existence proof.

On the other hand, as long as I've been using lisp machines (up to this
very day) I've encountered combined methods which weren't caught at
compile-time.  So I suppose we should say that we would have Flavors as
existence proof in principle...


I very much doubt that a user will in fact be able to declare enough to
the system to generate the same quality of code as the specially-
recognised predefined system method combination types -- let
alone that s/he would be able to declare this is any portable way!

I realize that CLOS is only specifying semantics, but why make things
harder than they need be, so hard they they need a Sufficiently Smart
Compiler Sufficiently Useful Magic-Unspecified-Declarations/
Sufficiently Powerful Magic-Unspecified-Pattern-Matching-Language/ etc?
(For years there has been talk about sufficiently smart compilers taking
all of my troubles away, but I've yet to see evidence of such things.)

My overall fear is that this sort of approach will create two classes of
programs -- those which use the system's predefined method combination
types and standard method definition (such as defmethod with
:method-class standard-method) and those which use anything else.  The
first class of programs can expect a much higher level of support than
the latter, because the compiler has been taught special tricks.  I like
to think that one of the aims of CLOS in general (though Chapter 3-style
specifications) is to expose as much of the underlying works as is
necessary to allow non-`standard' classes/method-combination/etc to be
able to expect a level of support which is at least of the same order of
magnitude as that provided by the system.  This certainly does not seem
to be the case with user-defined method-combination types.

(I know there are limits to this argument -- for example I doubt that J.
Random Generic-function Metaclass could expect the same performance as
implementation-tuned standard-generic-function.)

However, if user-defined method combination is to be a toy which works
1/1000th as well as system-defined method combination (because it has to
call out to the evaluator or otherwise do a bunch of unnecessary hair at
run time or require the presence of a full lisp compiler) then why
bother specifying it at all?  I'm sure most people will be happy with a
few standard method combination types -- why clutter up the world and
raise people's expectations with something which can't be guaranteed to
work very well?   Especially, why clutter the world so much the EVAL
becomes required (when nothing else in CLtL except for the section on
the evaluator seems to require such a horrible thing)?



BTW I've looked at the pattern-matchers (by no means ``the world's
simplest'' -- PCL's uses a real code-walker) in both PCL and Flavors and
still doubt that they can do enough before they become full lisp
compilers.  (When Flavor's pattern-matcher punts, it ends up calling
compile.)

I don't believe Moon's argument that something less than a full lisp
evaluator will do to interpret user-defined effective methods -- it is
trivial to define a method combination type (and not even a particularly
contrived one) which will defeat this.



I guess Scheme has gone badly to my brain -- the mere hint of run-time
evaluation/compilation makes me feel ill (the symptoms are flames coming
from the mouth.)  There is another reason, though:  I have recently had
very bad experiences with a very large piece of software which suffered
and suffered (and made me suffer) because of the way it called out to
the evaluator. 



Anyway, this whole issue was originally filed under the
``Just to be contentious'' label -- I didn't expect and still do not
expect to convince anybody.

I am not going to continue to flame about this.

∂23-May-88  0644	Common-Lisp-Object-System-mailer 	Re: check-keyword-arguments    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 23 May 88  06:44:34 PDT
Received: by ti.com id AA26663; Mon, 23 May 88 08:43:54 CDT
Received: from Jenner by tilde id AA28453; Mon, 23 May 88 08:31:19 CDT
Message-Id: <2789386229-306446@Jenner>
Date: Mon, 23 May 88  08:30:29 CDT
From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Cc: common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Re: check-keyword-arguments   
In-Reply-To: Msg of 20 May 88  2206 PDT from Dick Gabriel <RPG@SAIL.STANFORD.EDU>

     Date: 20 May 88  2206 PDT
     From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
     Subject: check-keyword-arguments   
     
     
     (defmethod make-instance ((class standard-class) &rest initargs)
       (setq initargs (default-initargs class initargs))
       (let* ((proto (class-prototype class))
              (methods 
                (append
     	     (compute-applicable-methods #'allocate-instance `(,class))
     	     (compute-applicable-methods #'initialize-instance `(,proto))
     	     (compute-applicable-methods #'shared-initialize `(,proto nil)))))
     	(unless
     	  (subsetp
     	    (let ((keys '()))
     	      (do ((plist initargs (cddr plist)))
     		  ((null plist) keys)
     		(push (car plist) keys)))
     	    (union 
     	      (class-slot-initargs class)
     	      (reduce #'union (mapcar #'function-keywords methods))))
     	  (error ...)))
       (let ((instance (apply #'allocate-instance class initargs)))
         (apply #'initialize-instance instance initargs)
         instance))

I agree, expect that the second value returned by function-keywords needs
to be looked at. Something like this would work (I think):

(defmethod make-instance ((class standard-class) &rest initargs)
  (setq initargs (default-initargs class initargs))
  (let* ((proto (class-prototype class))
	 (methods 
	   (append
     	     (compute-applicable-methods #'allocate-instance `(,class))
     	     (compute-applicable-methods #'initialize-instance `(,proto))
     	     (compute-applicable-methods #'shared-initialize `(,proto nil)))))
    (unless
      (block check-keys
	(let ((valid-keys (class-slot-initargs class)))
	  (dolist (method methods)
	    (multiple-value-bind (keys allow-other-keys-p)
		(function-keywords method)
	      (if  allow-other-keys-p
		   (return-from check-keys t)
		   (setf valid-keys (union keys valid-keys)))))
	  (subsetp
	    (let ((keys '()))
	      (do ((plist initargs (cddr plist)))
		  ((null plist) keys)
		(push (car plist) keys)))
	    valid-keys)))
     	  (error ...)))
      (let ((instance (apply #'allocate-instance class initargs)))
	(apply #'initialize-instance instance initargs)
	instance))

Patrick.

∂23-May-88  0842	Common-Lisp-Object-System-mailer 	Re: define-method-combination  
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 23 May 88  08:42:19 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA04663; Mon, 23 May 88 08:41:00 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-3.2)
	id AA15995; Mon, 23 May 88 08:38:27 PDT
Received: from localhost by suntana.sun.com (3.2/SMI-3.2)
	id AA04572; Mon, 23 May 88 08:33:04 PDT
Message-Id: <8805231533.AA04572@suntana.sun.com>
To: Richarrd MLYnaRIk <Mly@AI.AI.MIT.EDU>
Cc: common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Re: define-method-combination 
In-Reply-To: Your message of Sat, 21 May 88 22:27:00 -0400.
             <19880522022721.6.MLY@PERON.AI.MIT.EDU> 
Date: Mon, 23 May 88 08:33:01 -0700
From: kempf@Sun.COM


>On the other hand, as long as I've been using lisp machines (up to this
>very day) I've encountered combined methods which weren't caught at
>compile-time.  So I suppose we should say that we would have Flavors as
>existence proof in principle...

Unfortunately, I suspect that you may be right about this. However, I don't
necessarily believe that this makes user defined method combination types
useless. Certainly, for prototype or experimental code, where performance
is not as critical, they should be useful. And CLOS has been designed
with the needs of experimentalists in mind. There may even be some
applications which don't mind having a full evaluator or compiler around.
In fact, how many Lisp applications run today *without* a full evaluator
or compiler around (rhetorical question, very few I suspect).

>I realize that CLOS is only specifying semantics, but why make things
>harder than they need be, so hard they they need a Sufficiently Smart
>Compiler Sufficiently Useful Magic-Unspecified-Declarations/
>Sufficiently Powerful Magic-Unspecified-Pattern-Matching-Language/ etc?
>(For years there has been talk about sufficiently smart compilers taking
>all of my troubles away, but I've yet to see evidence of such things.)

When somebody manages to convince a funding agency like DARPA that 
research on advanced Lisp compilers is important, it will happen. 
Until then, forget it. Lots of people have plenty of ideas about 
how to make Lisp compilers Sufficiently Smart, unfortunately, maintenance
of existing compilers, addition of features (like multiprocessing) and
environmental support have taken precedence in the commercial field,
because that is what customers are asking for. The way things are 
currently going, we should be happy if a product quality CLOS is
available within a reasonable amount of time, and I'm not talking about
the technical side of implementing it.

>My overall fear is that this sort of approach will create two classes of
>programs -- those which use the system's predefined method combination
>types and standard method definition (such as defmethod with
>:method-class standard-method) and those which use anything else.  The
>first class of programs can expect a much higher level of support than
>the latter, because the compiler has been taught special tricks.  I like
>to think that one of the aims of CLOS in general (though Chapter 3-style
>specifications) is to expose as much of the underlying works as is
>necessary to allow non-`standard' classes/method-combination/etc to be
>able to expect a level of support which is at least of the same order of
>magnitude as that provided by the system.  This certainly does not seem
>to be the case with user-defined method-combination types.

This is a goal, however, there is a real question of how much the
underlying works can be exposed without constraining the implementation
so much that the standard system defined generic functions and method
combinations can't be compiled efficiently. Unless someone does an
existence proof, it is unlikely that we will really know, because a
paper specification might miss something important. After having tuned
up PCL, I know that the level of metaobject support in PCL can be implemented
very efficiently on stock hardware, however, the version of PCL I used
didn't have method combination, much less user defined method combination.
Of course, any attempt to add additional features invalidates the existence
proof.

>I guess Scheme has gone badly to my brain -- the mere hint of run-time
>evaluation/compilation makes me feel ill (the symptoms are flames coming

More importantly for commercial purposes, C++. That's the competition.
While it is unlikely that we will be able to get performance comparible
to C++ on the first round, given your Sufficiently Smart compiler, it
should be possible to approach it. Whether a Sufficiently Smart CLOS
compiler happens, however, is again a question of priorities. 


		jak

∂23-May-88  0948	Common-Lisp-Object-System-mailer 	Re: check-keyword-arguments    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 May 88  09:48:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAY 88 09:47:58 PDT
Date: 23 May 88 09:46 PDT
Sender: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: check-keyword-arguments   
In-reply-to: Dick Gabriel <RPG@SAIL.Stanford.EDU>'s message of 20 May 88 22:06
 PDT
To: RPG@SAIL.Stanford.EDU
cc: common-lisp-object-system@SAIL.Stanford.EDU
Message-ID: <880523-094758-4593@Xerox>

I am happy to see this version of make-instance PROVIDED we put
compute-applicable-methods and function-keywords in chapter 2.   I think both
provide features which are useful to programmers working with CLOS as it stands
rather than with possibly extending the system.  compute-applicable-methods is
parallel to find-method, and function-keywords is similar to method-qualifiers,
both of which are in chapter 2.  I mildly prefer the name  method-keywords since
its argument is a method.I would also suggest find-applicable-methods to
parallel find-method. 
  

∂23-May-88  1047	Common-Lisp-Object-System-mailer 	More Check-Keyword-Arguments   
To:   common-lisp-object-system@SAIL.Stanford.EDU    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


I have no problems with compute-applicable-methods and function-keywords
being in chapter 2, except that we are on top of the two-week rule
and have to blast out to make it. Function-keywords is a good name because
it is a generic function, and some Common Lisps might extend it to CL functions.
I preferred valid-keywords because it did not talk about either functions or
methods.

			-rpg-

∂23-May-88  1055	Common-Lisp-Object-System-mailer 	define-method-combination 
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 23 May 88  10:55:02 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191675; Mon 23-May-88 13:54:24 EDT
Date: Mon, 23 May 88 13:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: define-method-combination
To: Richarrd MLYnaRIk <Mly@AI.AI.MIT.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <19880522022721.6.MLY@PERON.AI.MIT.EDU>
Message-ID: <19880523175424.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sat, 21 May 88 22:27 EDT
    From: Richarrd MLYnaRIk <Mly@AI.AI.MIT.EDU>

    Before I launch into the usual tirade, I'd like to make a suggestion
    which might have some hope of being considered:

    define-method-combination should accept an option
      (:generic-function <symbol>)
    and bind <symbol> to the relevant generic function.
    This has much the same flavour as the existing :arguments option.
    I think that this is a nicer solution than binding
    a magic variable named `generic-function'.

I agree.  I think this just got overlooked when :arguments was added,
because before that there wasn't any agreed-upon syntax for saying
things like this.  Group: Is there still time to change this?

    ....
    On the other hand, as long as I've been using lisp machines (up to this
    very day) I've encountered combined methods which weren't caught at
    compile-time.

And as long as I've been using Lisp, I've encountered files that use a macro
that has been changed, but no one remembered to recompile the file, so the
caller of the macro was not updated.  Few people propose to remove macros
from Lisp for that reason.  I just don't think your argument is relevant.

    ....
    My overall fear is that this sort of approach will create two classes of
    programs -- those which use the system's predefined method combination
    types and standard method definition (such as defmethod with
    :method-class standard-method) and those which use anything else.  The
    first class of programs can expect a much higher level of support than
    the latter, because the compiler has been taught special tricks.  

I agree that that could happen, but I see no reason why it must.

								      I like
    to think that one of the aims of CLOS in general (though Chapter 3-style
    specifications) is to expose as much of the underlying works as is
    necessary to allow non-`standard' classes/method-combination/etc to be
    able to expect a level of support which is at least of the same order of
    magnitude as that provided by the system.  This certainly does not seem
    to be the case with user-defined method-combination types.

I agree with your first sentence, but don't see why you think
user-defined method-combination types are any different from anything
else.  Also, you've changed your argument.  First you said user-defined
method combination types require the existence of a compiler at load
time (and implicitly you assumed that all Lisps are like most of today's
(but not the 1950's!) Lisps, in that if you have a compiler at load
time, you cannot get rid of it at run time).  Now you're saying that
user-defined method combination won't compile as efficiently as standard
method combination, an entirely different argument.  I think your new
argument is analogous to saying that it's better to use DO than LOOP,
not because you like the syntax better, but because DO as a built-in
macro is likely to compile more efficient code than LOOP, as a
user-defined macro.  That's even true to some extent with some
compilers, but few people change their whole programming style on the
basis of that kind of consideration, and in all the arguments against
LOOP I've heard over the years, I don't recall ever hearing that one.
I really believe that method combination is just like a macro.

    However, if user-defined method combination is to be a toy which works
    1/1000th as well as system-defined method combination (because it has to
    call out to the evaluator or otherwise do a bunch of unnecessary hair at
    run time or require the presence of a full lisp compiler)

Please, please, please do not be confused by the interpreter-oriented
presentation, any more than you would be confused by a Lisp textbook which
explained the language in interpretive terms and only introduced the compiler
in a late chapter.  Semantics are easier to explain interpretively, but no
one proposes calling out to the evaluator in any real implementation.

    then why
    bother specifying it at all?  I'm sure most people will be happy with a
    few standard method combination types -- why clutter up the world and
    raise people's expectations with something which can't be guaranteed to
    work very well?

Change "method combination type" to "macro" and read your argument again.
Of course, there are people in the Scheme community who believe that argument.
I think Common Lisp is way past aspiring to that level of purity, though.

    I don't believe Moon's argument that something less than a full lisp
    evaluator will do to interpret user-defined effective methods -- it is
    trivial to define a method combination type (and not even a particularly
    contrived one) which will defeat this.

Of course.  It's also trivial to write a program that cannot be compiled.
In practice, people who care about the issue you're concerned with don't
do those things.

∂23-May-88  1105	Common-Lisp-Object-System-mailer 	Re: define-method-combination  
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 23 May 88  11:05:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191680; Mon 23-May-88 14:05:18 EDT
Date: Mon, 23 May 88 14:05 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: define-method-combination 
To: kempf@Sun.COM
cc: Richarrd MLYnaRIk <Mly@AI.AI.MIT.EDU>, common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <8805231533.AA04572@suntana.sun.com>
Message-ID: <19880523180527.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 23 May 88 08:33:01 -0700
    From: kempf@Sun.COM

    More importantly for commercial purposes, C++. That's the competition.
    While it is unlikely that we will be able to get performance comparible
    to C++ on the first round, given your Sufficiently Smart compiler, it
    should be possible to approach it. Whether a Sufficiently Smart CLOS
    compiler happens, however, is again a question of priorities. 

I agree with you, but would like to point out that I don't think the
existence of method combination has any bearing on the issue.  I think
multiple inheritance and slot access are the areas that cause more
performance impact compared to C++.  Furthermore I think the real
performance issues are entirely outside of CLOS, in areas such as
garbage collection and other things that Lisp does for you but C++
does not, and in the fact that the performance comparison is likely
to be on C's "home turf", hardware that is highly adapted for C and
less well adapted for Lisp.

∂23-May-88  1211	Common-Lisp-Object-System-mailer 	Define-Method-Combination 
To:   common-lisp-object-system@SAIL.Stanford.EDU    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


I basically agree with Moon's replies to Richard's concerns.
On the topic of the added option to define-method-combination:

	   define-method-combination should accept an option
	   (:generic-function <symbol>) and bind <symbol> to the relevant
	   generic function.

I don't like the name ``:generic-function'' but I cannot think of a
better one. We're moving compute-applicable-methods and function-keywords
into chapter 2 today, so this wrinkle is minor.

			-rpg-

∂23-May-88  1234	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
To:   common-lisp-object-system@SAIL.Stanford.EDU    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


The two functions, compute-applicable-methods and function-arguments,
will appear in chapter 2. The inline code for make-instance will
appear in chapter 3.

			-rpg-

∂23-May-88  1537	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 May 88  15:37:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 409032; Mon 23-May-88 18:37:03 EDT
Date: Mon, 23 May 88 18:36 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: check-keyword-arguments   
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: The message of 23 May 88 15:34 EDT from Dick Gabriel <RPG@SAIL.Stanford.EDU>
Message-ID: <19880523223659.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 23 May 88  1234 PDT
    From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

    The two functions, compute-applicable-methods and function-arguments,
    will appear in chapter 2. The inline code for make-instance will
    appear in chapter 3.

Is the name function-arguments a typo?

∂23-May-88  1539	Common-Lisp-Object-System-mailer 	Comments on current state of Initialization.  
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 23 May 88  15:37:56 PDT
Received: by labrea.stanford.edu; Mon, 23 May 88 15:37:54 PDT
Received: from bhopal.lucid.com by edsel id AA01958g; Mon, 23 May 88 15:29:01 PDT
Received: by bhopal id AA01677g; Mon, 23 May 88 15:32:51 PDT
Date: Mon, 23 May 88 15:32:51 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805232232.AA01677@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: common-lisp-object-system@sail.stanford.edu
In-Reply-To: David A. Moon's message of Sat, 21 May 88 19:04 EDT <19880521230422.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Comments on current state of Initialization.

re:     Date: Sat, 21 May 88 06:44:29 PDT
        From: Jon L White <edsel!jonl@labrea.stanford.edu>

        Why should there still  be three initialization protocls: "shared-
        initialize", "initialize-instance",  and "reinitialize-instance"?

        [Summary: replace reinitialize-instance with a keyword argument to
        initialize-instance --Moon]

    Two reasons come immediately to mind: shared-initialize is also used when a
    class is redefined or change-class is called; . . . 

It seemed obvious to me that the "internal" callers from change-class etc. 
could just as easily use a simpilifed definition of initialize-instance with 
keyword argument.


-- JonL --

∂23-May-88  1600	Common-Lisp-Object-System-mailer 	check-keyword-arguments etc.   
To:   moon@STONY-BROOK.SCRC.SYMBOLICS.COM,
      common-lisp-object-system@SAIL.Stanford.EDU
From: Linda DeMichiel <LGD@SAIL.Stanford.EDU>


  From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
  Subject: check-keyword-arguments   

    Date: 23 May 88  1234 PDT
    From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

    The two functions, compute-applicable-methods and function-arguments,
    will appear in chapter 2. The inline code for make-instance will
    appear in chapter 3.

 Is the name function-arguments a typo?

Yes.  It is called function-keywords in the draft that just went out
to the printers.

There are new chapter 2 files out on sail with these additions.
There is also a new macros file that should fix the [Primary Method]
formatting bug.

-lgd

∂23-May-88  1633	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
To:   common-lisp-object-system@SAIL.Stanford.EDU    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


function-arguments is a typo for function-keywords. That's what I get
for talking on the phone while typing mail.

			-rpg-

∂23-May-88  1649	Common-Lisp-Object-System-mailer 	Re: Mlynarik's comments   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 May 88  16:49:04 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAY 88 16:46:23 PDT
Date: Mon, 23 May 88 16:46 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Mlynarik's comments  
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: common-lisp-object-system@SAIL.Stanford.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-2.text.newest
In-Reply-To: The message of 21 May 88 00:17 PDT from Dick Gabriel
 <RPG@SAIL.Stanford.EDU>
Message-ID: <19880523234612.1.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no

    Date: 21 May 88 00:17 PDT
    From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

    Richard writes:

    ``1-22 2nd PP in `Intro to methods':  The first and second sentences
    seem to be too directly contradictory.  I would change the first to
    ``A method object is not NECESSARILY a function an IN GENERAL cannot be
    invoked as a function.'' ''

    The sentences in question are:

    ``A method object is not a function and cannot be invoked as a function.  An
    implementation may extend the \OS\ so that method objects are functions.''

    The reason it is stated this way is that no one writing portable code can
    take them to be functions, but we do not require them to not be functions
    in all implementations.  

Actually, the second sentence is wrong.  We do prohibit them from being
functions in all implementations.  Chapter 3 is very clear on this
issue.  Methods are instances of the class standard-method which itself
is an instance of standard-class.  We should delete the second sentence.
-------

∂23-May-88  1659	Common-Lisp-Object-System-mailer 	Chapter 1  
To:   common-lisp-object-system@SAIL.Stanford.EDU    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


The versions of Chapter 1 that are being sent to X3J13 are now
on [cls,lsp] on SAIL. You know what it is; you know what to do.

			-rpg-

∂23-May-88  2332	Common-Lisp-Object-System-mailer 	Method Objects are not Functions    
To:   common-lisp-object-system@SAIL.Stanford.EDU    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


I don't understand the reasoning that would argue that a method
object a priori cannot be a function.

			-rpg-

∂24-May-88  1044	Common-Lisp-Object-System-mailer 	Re: Method Objects are not Functions     
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 24 May 88  10:44:23 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 24 MAY 88 10:43:29 PDT
Date: Tue, 24 May 88 10:43 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Method Objects are not Functions    
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: common-lisp-object-system@SAIL.Stanford.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-2.text.newest
In-Reply-To: The message of 23 May 88 23:32 PDT from Dick Gabriel
 <RPG@SAIL.Stanford.EDU>
Message-ID: <19880524174313.4.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no

    Date: 23 May 88 23:32 PDT
    From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

    I don't understand the reasoning that would argue that a method
    object a priori cannot be a function.

The metaclass of a method object is standard-class.  Standard-class does
not support the behavior which allows its metainstances to be
funcallable objects.  Only funcallable-standard-class does that.

I suppose that some implementation could extend standard-class to do
that, but I don't see that as a freedom we really need to allow.
-------

∂24-May-88  1105	Common-Lisp-Object-System-mailer 	Callable Methods
To:   common-lisp-object-system@SAIL.Stanford.EDU    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


I am aware of the proposed ontology of method objects, but I think we need
to carefully think about how much of the hierarchy to uniquely specify in
Ch3.  That is, method objects are things that on the surface could be
callable. Therefore, maybe the metaclass should be something distinct from
from standard-class, but with the proviso that it is acceptable to either
identify this metaclass with standard-class or to hang it under
funcallable-standard-class.

			-rpg-

∂26-May-88  1055	Common-Lisp-Object-System-mailer 	with-added-methods   
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 May 88  10:54:57 PDT
Received: from PERON.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 26 May 88 13:55-EDT
Date: Thu, 26 May 88 13:58 EDT
From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
Subject: with-added-methods
To: common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <19880526175838.6.MLY@PERON.AI.MIT.EDU>

[Apologies if I am rehashing an issue which has been previously discussed
-- the local CLOS archives are presently inaccessible.]

with-added-methods seems incompatible with the restriction (mentioned in
the doc for add-method) that a method can only be added to one generic
function at a time.

The doc for with-added-methods says:
  Each generic function is created by adding the set of methods
  specified by its method definitions to a copy of the lexically visible
  generic function of the same name and its methods.
That for add-method says:
  If the method object is a method object of another generic function,
  an error is signaled.

I would think that the new generic function created by
with-added-methods must share all all the methods which were defined on
the original generic function.

I suppose that an alternate reading of the first piece of documentation
is ``to a copy of the lexically visible generic function of the same
name and TO A COPY OF its methods'' -- I'd like to think that this isn't
what was intended, since it would seem to introduce far more problems
than it solves.

Some passing remarks about with-added-methods:
 * Does it really need to be a special form rather than a macro?
   I -believe- I could define it in terms of generic-flet -- however,'
   I haven't thought this through very thoroughly.
 * Is there sufficient Chapter 3 support to enable this kind of thing to
   be `portably' implemented?  Apart from the above-mentioned lossage
   involving methods added to more than one generic function, there are
   problems brushed under the rug by ``A COPY OF the lexically
   visible generic function.''  Presumably there needs to be some
   cloning method for generic functions.
 * I guess I'll never actually use with-added-methods in any case
   because of inefficiencies due what I perceive as the fatal problem
   with method-combination...

∂02-Jun-88  1329	Common-Lisp-Object-System-mailer 	[David N Gray <Gray@DSG>:  making structures] 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 2 Jun 88  13:29:15 PDT
Received: by ti.com id AA14212; Thu, 2 Jun 88 15:28:26 CDT
Received: from Jenner by tilde id AA23256; Thu, 2 Jun 88 15:26:36 CDT
Message-Id: <2790274788-645613@Jenner>
Date: Thu, 2 Jun 88  15:19:48 CDT
From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
To: Common-lisp-object-system@sail.stanford.edu
Subject: [David N Gray <Gray@DSG>:  making structures]

I thought I'd pass this along. There is no need to include Gray in the 
reply since he is out of town for two month.

------- Forwarded Message


Patrick,
The May 23 draft of the CLOS spec still has the following text on page
1-15:  "Calling MAKE-INSTANCE to create an instance of STRUCTURE-CLASS
signals an error."  This still seems like an undesirable and unnecessary
limitation to me.
  -- David Gray

------- End of Forwarded Message

∂20-Jun-88  1330	Common-Lisp-Object-System-mailer 	Compile-file environment  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 20 Jun 88  13:30:19 PDT
Received: by ti.com id AA24079; Mon, 20 Jun 88 15:27:31 CDT
Received: from Jenner by tilde id AA06995; Mon, 20 Jun 88 15:17:37 CDT
Message-Id: <2791829681-8355429@Jenner>
Date: Mon, 20 Jun 88  15:14:41 CDT
From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
To: common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Compile-file environment


In order to compile in advance (compile-file time ) some implementation
aspects of CLOS metaobjects, there must be some clos metaobjects
residing in an implementation dependent environment, that do not visibly
side effect the runtime environment.  The visible entry points to this
environment come from name to object mapping (FIND-CLASS and
ENSURE-GENERIC-FUNCTION).  I propose that a runtime environment CLOS
object cannot visibly point to a compile-file environment object(No
visible cross environment links).  I think that makes metaclass
programming a lot easier.

Environment Capture
When compiling CLOS DEF..  forms, a evaluation must take place that
affects the compile-file environment, and this evaluation must be a
similar to what happens when the forms are evaluated. 
I propose that the standard expansion of the DEF... macro be:

(defclass foo () ())
 =>
(eval-when (load eval compile)
  (add-named-class (class-prototype (find-class "STANDARD-CLASS"
                                                (name-environment env)))
	                 :name 'foo
                         :environment (name-environment env)))

Where name-environment take the value of a macroexpand environment and
returns the right environment for the right situation.  The value
returned by name-environment can be passed as the environment argument
to all CLOS functions that accept and environment argument.

Presumably, when evaluated in the EVAL and COMPILE-TO-CORE situation,
this name-environment returns NIL (the runtime environment).  When
evaluated in the COMPILE-FILE environment, it returns the compile-file
environment.  When evaluated in LOAD situation, it returns the runtime
environment.  Since the compiler and the evaluator have to treat this
function differently, Logically, this is a special form.


Environments behavior
The compiler should be responsible for implementing the inheritance and
shadowing  of objects in different environments.  However, find-class
should not return a runtime object when the environment argument points
to a compile-file environment.  This avoids cross references across
environments.  I don't think this is a good idea for FIND-CLASS to
return a created class object when an inheritance has to happen.  I
think that should be explicitly done by calling MAKE-DEFAULT-METAOBJECT.

MAKE-DEFAULT-METAOBJECT metaobject-prototype name &optional environment.  Generic-function

The default method on standard-class returns
a forwarded-class when the environment is a runtime environment, and
does the implementation dependent environment inheritance or
forwarded-class creation if the environment is a compile-file
environment. 

Inside of ADD-NAMED-CLASS, MAKE-DEFAULT-METAOBJECT is called when (find-class
class-name nil environment) returns NIL.

Inside of ADD-NAMED-METHOD (or something like that), during the
normalization of the specializers,MAKE-DEFAULT-METAOBJECT needs to be
called if (find-class class-name nil environment) returns NIL when the
environment is a compile-file environment.

Inside of ENSURE-GENERIC-FUNCTION, we need to have the same mechanism.
Either we extend FBOUNDP to accept an environment argument, or we come
up with an equivalent of FIND-CLASS, does not matter much.

MAKE-DEFAULT-METAOBJECT is specialized on standard-generic-function and
returns the appropriate generic function object.

Patrick.

∂22-Jun-88  1448	Common-Lisp-Object-System-mailer 	SYMBOL-MACROLET-UTILITY   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 22 Jun 88  14:46:14 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
	id AA21530; Wed, 22 Jun 88 14:46:01 PDT
Message-Id: <8806222146.AA21530@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
Date: 22 Jun 88 17:38
To: Common-Lisp-Object-System@sail.stanford.edu
Subject: SYMBOL-MACROLET-UTILITY

I'm getting to ready to submit this as a cleanup proposal; I thought I'd run
it by here first.  My intent in submitting the proposal for cleanup is to open
the discussion of whether SYMBOL-MACROLET is really a desirable language
feature.  If it is resolved that SYMBOL-MACROLET is worth keeping, I have a
follow-up proposal to at least make it a special form.

/JEP
===============================================================================
Status:		DRAFT
Issue:		SYMBOL-MACROLET-UTILITY
References:	X3J13 document 88-002R, Chapter 2, pp. 2-81f., 2-88f., 2-92f.
Category:	DELETION
Edit history:	21-Jun-88, Version 1 by Piazza

Problem Description:

    Anything expressible with SYMBOL-MACROLET could also be written with
    regular MACROLET, except that the macro symbol could not stand alone as an
    expression; it would have to be enclosed in parentheses.  The cost
    associated with implementing and maintaining the SYMBOL-MACROLET feature
    exceeds this incremental utility.

Proposal (SYMBOL-MACROLET:FLUSH):

    Remove SYMBOL-MACROLET (and WITH-ACCESSORS and WITH-SLOTS) from 88-002R.

Rationale:

    Flushing SYMBOL-MACROLET eliminates the cost of implementing and
    maintaining this feature, while MACROLET still provides most of
    SYMBOL-MACROLET's expressive power.

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

Current Practice:

    Portable Common Loops provides a code-walking implementation of
    SYMBOL-MACROLET as specified in 88-002R.

Cost to Implementors:

    Presumably few implementors have implemented SYMBOL-MACROLET, excepting
    the implementation provided by PCL.  If it is flushed from the language,
    no one will incur any implementation cost.

Cost to Users:

    Users will lose the expressive ability provided by SYMBOL-MACROLET,
    WITH-ACCESSORS, and WITH-SLOTS, and will have to make do with MACROLET.

Cost of Non-Adoption:

    Implementors must implement significant new functionality, adding to
    system size and language complexity.  (A separate proposal,
    SYMBOL-MACROLET-SEMANTICS, addresses problems with the currently
    specified semantics of SYMBOL-MACROLET.)

Benefits:

    SYMBOL-MACROLET:FLUSH reduces the implementation and maintenance costs for
    a Common Lisp implementation.  It also simplifies the language by
    eliminating the concept of a "symbol macro."

Aesthetics:

    There seem to be mixed feelings as to the desirability of SYMBOL-MACROLET
    as a construct in the language.  Some feel it hairs up the language while
    offering only trivial benefit beyond what is already provided through
    normal macros.  Others herald it as a important new language feature.

Discussion:

    As it was adopted by X3J13 as part of CLOS, there has been no formal
    discussion on the pros and cons SYMBOL-MACROLET on its own.

∂24-Jun-88  1225	Common-Lisp-Object-System-mailer 	which functions should be generic?  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 24 Jun 88  12:25:16 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 JUN 88 12:20:08 PDT
Date: 24 Jun 88 12:19 PDT
From: Masinter.pa@Xerox.COM
Subject: which functions should be generic?
To: common-lisp-object-system@sail.stanford.edu
Message-ID: <880624-122008-5902@Xerox>


Mr. Ida asks (relative to COERCE-INCOMPLETE):

"Will Coerce function be a (standard) generic function ?"


I'd like to generalize this: Now that CLOS is part of the standard, which
functions in CL should be generic?

∂24-Jun-88  1332	Common-Lisp-Object-System-mailer 	Re: which functions should be generic?   
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 24 Jun 88  13:31:53 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA28747; Fri, 24 Jun 88 13:30:10 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-3.2)
	id AA18466; Fri, 24 Jun 88 13:26:07 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA07800; Fri, 24 Jun 88 13:30:29 PDT
Message-Id: <8806242030.AA07800@suntana.sun.com>
To: Masinter.pa@Xerox.COM
Cc: common-lisp-object-system@sail.stanford.edu
Subject: Re: which functions should be generic? 
In-Reply-To: Your message of 24 Jun 88 12:19:00 -0700.
             <880624-122008-5902@Xerox> 
Date: Fri, 24 Jun 88 13:30:26 -0700
From: kempf@Sun.COM


1) All the sequence functions (Chapter 14)

2) Stream functions and output functions which use streams
(Chapters 21 & 22). Even though, or perhaps because, extensible
streams are not yet part of the CLOS draft, generic output
functions would be useful.

		jak


		

∂24-Jun-88  1545	Common-Lisp-Object-System-mailer 	which functions should be generic?  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Jun 88  15:44:57 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 424437; Fri 24-Jun-88 18:44:06 EDT
Date: Fri, 24 Jun 88 18:43 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: which functions should be generic?
To: Masinter.pa@Xerox.COM
cc: common-lisp-object-system@sail.stanford.edu
In-Reply-To: <880624-122008-5902@Xerox>
Message-ID: <19880624224355.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 24 Jun 88 12:19 PDT
    From: Masinter.pa@Xerox.COM

    Mr. Ida asks (relative to COERCE-INCOMPLETE):

    "Will Coerce function be a (standard) generic function ?"

It's difficult to implement COERCE's dispatch in terms of generic
function dispatch since equivalence of type specifiers is not done
in an object-oriented way.  There is no way to write a method that
is applicable both for (coerce '(#\a) 'string) and for
(coerce '(#\a) '(vector string-char)), even though both of those
forms mean the same thing.

    I'd like to generalize this: Now that CLOS is part of the standard, which
    functions in CL should be generic?

I think this is the wrong mailing list to discuss changes that X3J13, or
anyone else, might want to make to the language in order to take advantage
of CLOS.

∂24-Jun-88  1648	Common-Lisp-Object-System-mailer 	Re: which functions should be generic?   
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Jun 88  16:48:51 PDT
Received: from hplabs.HP.COM by SCORE.STANFORD.EDU with TCP; Fri 24 Jun 88 16:50:28-PDT
Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Fri, 24 Jun 88 15:39:09 PST
Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.HP.COM; Fri, 24 Jun 88 16:38:46 pdt
Received: from hplwhh by hplwhh.HPL.HP.COM; Fri, 24 Jun 88 16:37:05 pdt
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: common-lisp-object-system@sail.stanford.edu
Subject: Re: which functions should be generic? 
X-Mailer: mh6.5
In-Reply-To: Your message of Fri, 24 Jun 88 18:43:00 -0400.
             <19880624224355.3.MOON@EUPHRATES.SCRC.Symbolics.COM> 
Date: Fri, 24 Jun 88 16:37:03 PDT
Message-Id: <6353.583198623@hplwhh>
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>

> It's difficult to implement COERCE's dispatch in terms of generic
> function dispatch since equivalence of type specifiers is not done
> in an object-oriented way. 

This could be handled in the same way as the PRINT-OBJECT generic function.
Implementations are required to call it from within their print system.
One could supply a COERCE-OBJECT generic function which the COERCE function
would ultimately call if the coercion argument named a class.  

I realize that one could probably find a large number of candidates in CLtL
to be made generic.  Ideally EQUAL should be generic too.  It already
depends on the type of objects you give it, looking inside of vectors, etc.
Why not allow it to look inside of objects in an object dependent way?

At some point the argument boils down to an efficiency consideration.  I
don't think anyone would be happy if EQ was required to be generic.  There
should be a strong rational for which functions are to be made generic and
which are not.  (For example:  how should the average user know when to use
ELT instead of SVREF?)  Perhaps a generic layer of CL is in order.  CL
already kind of does this with its sequence operations.  I can think of three
generic protocols off hand:

	- sequences which access subcomponents by position

	- objects and structures which access subcomponents by name

	- math functions which operate on generic "numbers"

It would be nice if CL had facilities for formally specifying the protocols
for abstract classes like NUMBER, SEQUENCE, or OBJECT (i.e. first class
protocol objects, or an abstract-class metaclass), and allow individual
classes to implement a protocol.  This way the user can write code that
meets a protocol without regard to the specifics of its implementation.

∂25-Jun-88  1204	Common-Lisp-Object-System-mailer 	Re: which functions should be generic?   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 25 Jun 88  12:04:03 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 424648; Sat 25-Jun-88 15:01:44 EDT
Date: Sat, 25 Jun 88 15:01 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: which functions should be generic? 
To: Warren Harris <harris%hplwhh@hplabs.HP.COM>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <6353.583198623@hplwhh>
Message-ID: <19880625190143.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 24 Jun 88 16:37:03 PDT
    From: Warren Harris <harris%hplwhh@hplabs.HP.COM>

    > It's difficult to implement COERCE's dispatch in terms of generic
    > function dispatch since equivalence of type specifiers is not done
    > in an object-oriented way. 

    This could be handled in the same way as the PRINT-OBJECT generic function.
    Implementations are required to call it from within their print system.
    One could supply a COERCE-OBJECT generic function which the COERCE function
    would ultimately call if the coercion argument named a class.  

But it's meaningful for COERCE's second argument to be a type specifier that
does not name a class.  CLtL gives as an example (vector (complex short-float)).
It would be inconsistent to do some coercions with classes and others through
some other mechanism.  I don't think your idea will work without a larger
recasting of Common Lisp in object-oriented terms.  While that's an interesting
project for investigation, I suspect it would quickly go way beyond the
proper charter of a standardization effort.

    It would be nice if CL had facilities for formally specifying the protocols
    for abstract classes like NUMBER, SEQUENCE, or OBJECT (i.e. first class
    protocol objects, or an abstract-class metaclass), and allow individual
    classes to implement a protocol.  This way the user can write code that
    meets a protocol without regard to the specifics of its implementation.

While I strongly agree with this, and have thought so for several years, again
I feel this is beyond the proper charter of a standardization effort.  There
does not appear to be any current practice at all, let alone a concensus from
which to build a standard.

Some of the directions in which I feel Lisp ought to evolve in the 1990s
include enormously better tools for modularity and program packaging,
like what such languages as Ada have but better conceived and (as always
in Lisp) more flexible (the "locales" found in some dialects in Scheme
might be a good place to start); formal notions of protocols and
machine-understandable interface specifications; complete integration of
database concepts into the language; and development tools that
"understand" both Lisp programming concepts and the dynamics of large
development teams.  None of this is X3J13's business, which is to
stabilize the Lisp of the 1980s so people can use it.

∂03-Jul-88  1051	RPG 	The Law of Demeter  
 ∂28-Jun-88  2050	Owners-commonloops.pa@xerox.com 	The Law of Demeter    
Received: from parcvax (PARCVAX.XEROX.COM) by SAIL.Stanford.EDU with TCP; 28 Jun 88  20:50:43 PDT
Received: by parcvax (5.54/1.15) 
	id AA11667; Tue, 28 Jun 88 20:11:04 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 28 JUN 88 20:07:53 PDT
Return-Path: <RPG@SAIL.Stanford.EDU>
Redistributed: commonloops.pa
Received: from SAIL.Stanford.EDU ([10.0.0.11]) by Xerox.COM ; 28 JUN 88 20:06:52
 PDT
Message-Id: <uqAwE@SAIL.Stanford.EDU>
Date: 28 Jun 88 20:06 PDT
From: Dick Gabriel <RPG@sail.stanford.edu>
Subject: The Law of Demeter  
To: commonloops.pa@xerox.com

I just wrote a poem that helps explain the Law of Demeter (apologies
to Wallace Stevens):

Thirteen Ways of Looking at the Law of Demeter

	I
Among twenty snowy mountains,
The only moving thing
Was the Speaker of the Law.

	II
I was of three minds,
Like a program
In which there are three violations.

	III
The Sheet of the Law whirled in the autumn winds.
It was a small part of the pantomime.

	IV
A message and an argument
Are one.
A message and an argument and the Law
Are one.

	V
I do not know which to prefer,
The beauty of inflections
Or the beauty of innuendos,
The Law speaking
Or just after.

	VI
Icicles filled the long window
With barbaric glass.
The shadow of the Speaker
Crossed it to and fro.
The mood
Traced in the shadow
An indecipherable cause.

	VII
O thin men of Haddam,
Why do you imagine golden birds?
Do you not see how the Law
Walks around the feet
Of the programs about you?

	VIII
I know noble accents
And lucid, inescapable rhythms;
But I know, too,
That the Law is involved
In what I know.

	IX
When the Law disappeared from sight,
It marked the edge
Of one of many circles.

	X
At the sight of the Law
Working in green light,
Even the bawds of euphony
Would cry out sharply.

	XI
He rode over Connecticut
In a glass coach.
Once, a fear pierced him,
In that he mistook
The shadow of his equipage
For a violation.

	XII
The river is moving.
The Law must be working.

	XIII
It was evening all afternoon.
It was snowing.
And it was going to snow.
The Law sat 
On a sheet of paper.

∂11-Jul-88  1111	CL-Object-Oriented-Programming-mailer 	CLOS Workshop   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jul 88  11:11:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUL 88 11:06:55 PDT
Date: Mon, 11 Jul 88 11:02 PDT
From: Gregor.pa@Xerox.COM
Reply-To: Gregor@GRAPEVINE.parc.xerox.com
Subject: CLOS Workshop
To: Common-Lisp@Sail.Stanford.edu, common-lisp-object-system@sail.stanford.edu,
 CL-Object-Oriented-Programming@Sail.Stanford.edu, CommonLoops.pa@Xerox.COM
Fcc: BD:>Gregor>mail>outgoing-mail-2.text.newest
Message-ID: <19880711180221.8.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no



       Workshop for CLOS Users and Implementors

                October 3rd and 4th

                    Xerox PARC

               Palo Alto, California


We have been excited by the extent to which CLOS is already being
used, and the ways in which it is being extended.  The purpose of
this workshop is to provide an opportunity for the members of the
CLOS community to get together and share their experience.

To provide a good start for the interchange, we are requesting that
participants supply a short position paper (1-3 pages) describing
work related to CLOS.  Some topics of interest are:

      Applications
      Programming Techniques
      Implementation
      Programming Environment Tools
      Extensions of CLOS
      Techniques for Converting to CLOS
      Meta Object Techniques and Theory
      Critiques

We will try to support demonstrations or videotapes of applications,
programming environments, implementations or other relevant systems.

If you are planning to attend, please let us know by August 15th.
This will help us with planning and allow us to arrange a discount
rate at a local hotel.

Position papers should reach us by September 9th so that we can
organize a program and arrange for duplication of the papers.

Position papers, notice to attend, and other correspondence should
be sent to: 

     Gregor Kiczales
     3333 Coyote Hill Rd.
     Palo Alto, CA 94304

or by Internet mail to:
  
     Gregor.pa@Xerox.com
-------

∂15-Jul-88  1304	Common-Lisp-Object-System-mailer 	putting CLOS objects in binfiles    
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 15 Jul 88  13:04:09 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA27189; Fri, 15 Jul 88 13:02:05 PDT
Received: from lukasiewicz.sun.com by snail.sun.com (4.0/SMI-3.2)
	id AA05872; Fri, 15 Jul 88 13:02:42 PDT
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
	id AA07423; Fri, 15 Jul 88 12:42:03 PDT
Date: Fri, 15 Jul 88 12:42:03 PDT
From: jrose@Sun.COM (John Rose)
Message-Id: <8807151942.AA07423@lukasiewicz.sun.com>
To: common-lisp-object-system@sail.stanford.edu
Subject: putting CLOS objects in binfiles

It's a shame that there's no provision in CLOS for
saving objects in binfiles.  It's going to blow up
in our faces when CLOS gets ubiquitous enough for
people to use CLOS objects without being aware of it.
(I.e., when lower layers of layered products use
CLOS without advertising the fact.)

The reason is that the default object fasdumper
does a GC-style walk over the object, dumping not
only the object but also its class hierarchy.
Saving one object got me a binary file of over 100Kb.
(In Lucid 3.0.)

People expect to use binary files to store data in!
If CLOS objects can't be dumped, it will effectively
mean that you can't store data in Common Lisp binary files.

It's like that ancient MIT story about Lisp packages:
The first time they tried to fasdump a package object,
much of the Lisp world went along with it.  This kind
of behavior has to be fixed in real systems.  (As
with our future unaware user of CLOS, the MIT package
fasdump meltdown happened unexpectedly.  A bare "FOO:"
used to mean the FOO package object, instead of its present
meaning.)

Can a fix for this get sneaked into Chapter 3 of
the CLOS spec?

Here's essentially what's needed:  A generic function
(called, say, RECONSTRUCTOR-FORM) which returns a
Lisp form to evaluate to reconstruct any given
object.  It can return NIL, which means to do
some system default, like a GC-style walk.
The reconstructor form would be stored in
lieu of the real object into the binary file,
adorned with #, for evaluation at load time.

A different way to factor things would be to
have a function RECONSTRUCTOR-INITS which
computes at dump time a class name and keyword/value
plist, and a function RECONSTRUCT-INSTANCE analogous
to and equivalent by default to MAKE-INSTANCE,
which is called at load time on the saved data.

The fasdumper (and other utilities, like an object
migrator) could use protocols like these to handle
user-defined types correctly.

Using #, is not a solution:  A fasdumper needs to
correctly handle CLOS objects wherever they occur
in the data structures being dumped.

Here's my immediate problem:  I want to build objects
which represent predicates in a special purpose query
language, and I want them to be uniquified, like pathnames
on the Lisp Machine.  (They cache things like compiled Lisp
code, so it's expensive to build new copies.)  Such things
do not dump properly, and even if a simple patch were to
be applied (say, to dump a class symbol instead of a class),
a simple-minded load routine would not uniquify them.

			-- John

∂15-Jul-88  1408	Common-Lisp-Object-System-mailer 	putting CLOS objects in binfiles    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Jul 88  14:08:45 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 434003; Fri 15-Jul-88 17:07:46 EDT
Date: Fri, 15 Jul 88 17:07 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: putting CLOS objects in binfiles
To: John Rose <jrose@Sun.COM>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <8807151942.AA07423@lukasiewicz.sun.com>
Message-ID: <19880715210732.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 15 Jul 88 12:42:03 PDT
    From: jrose@Sun.COM (John Rose)

    It's a shame that there's no provision in CLOS for
    saving objects in binfiles.

CLOS doesn't address this because Common Lisp doesn't.
Note that CL provides no way to write a "binfile" other than
COMPILE-FILE.  Of course you can trick COMPILE-FILE into
doing anything, using macros, so that's no real limitation.

    The reason is that the default object fasdumper
    does a GC-style walk over the object, dumping not
    only the object but also its class hierarchy.

That's a statement about some particular implementation,
not about Common Lisp.

    Can a fix for this get sneaked into Chapter 3 of
    the CLOS spec?

Chapter 3 would be the wrong place.  This is logically
a Chapter 2 facility, in the same vein as PRINT-OBJECT.

The status of CLOS is that it has been accepted by X3J13
into the same status as CLtL.  This means that it is open to
cleaning up and improvement through the normal X3J13
mechanisms, and I think your suggestion makes a great deal
of sense and should be done through those mechanisms.  Do
you want to make the proposal (I don't know if you're
familiar with X3J13), or do want to ask someone on the
CLOS committee to do it?

    Here's essentially what's needed:  A generic function
    (called, say, RECONSTRUCTOR-FORM) which returns a
    Lisp form to evaluate to reconstruct any given
    object.  

This is fine.  It's how Flavors does it, so there is some
precedent.  The only problem with this technique is that it
doesn't cope well with circular structures, which can only
be handled by separating creation of the objects from filling
them in (and even that doesn't work in general, for reasons
too complicated to get into here).

	     It can return NIL, which means to do
    some system default, like a GC-style walk.

I think this is a really bad idea.  My experience is that there is no
default that is right for all objects and any attempt to offer a default
does users more harm than good, because the default gets used for cases
where it can't work any causes hard to understand problems.
Furthermore, if there was a default, it should be implemented by a
default method for the generic function, not by special-casing NIL.  I'd
prefer that there be no default and hence if the user has not defined a
method, an error is signalled.

    Here's my immediate problem:  I want to build objects
    which represent predicates in a special purpose query
    language, and I want them to be uniquified, like pathnames
    on the Lisp Machine.  (They cache things like compiled Lisp
    code, so it's expensive to build new copies.)  Such things
    do not dump properly, and even if a simple patch were to
    be applied (say, to dump a class symbol instead of a class),
    a simple-minded load routine would not uniquify them.

I'm not sure that anything in Common Lisp requires that multiple
references to a single object, in a file being compiled, do not
turn into multiple objects when the file is loaded.  You might have
to address this in an implementation-dependent way unless the
definition of Common Lisp were changed to require this explicitly.
I think most implementations do guarantee object identity within
a single COMPILE-FILE, even though they're not required to.
This is not a CLOS issue, it applies to all objects for which EQ
is defined.

∂15-Jul-88  1719	Common-Lisp-Object-System-mailer 	Re: putting CLOS objects in binfiles
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Jul 88  17:19:05 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 JUL 88 17:08:30 PDT
Date: 15 Jul 88 17:08 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: putting CLOS objects in binfiles
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of
 Fri, 15 Jul 88 17:07 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: jrose@Sun.COM, common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <880715-170830-1592@Xerox>

   Here's my immediate problem:  I want to build objects
    which represent predicates in a special purpose query
    language, and I want them to be uniquified, like pathnames
    on the Lisp Machine.  (They cache things like compiled Lisp
    code, so it's expensive to build new copies.)  Such things
    do not dump properly, and even if a simple patch were to
    be applied (say, to dump a class symbol instead of a class),
    a simple-minded load routine would not uniquify them.

"I'm not sure that anything in Common Lisp requires that multiple
references to a single object, in a file being compiled, do not
turn into multiple objects when the file is loaded.  You might have
to address this in an implementation-dependent way unless the
definition of Common Lisp were changed to require this explicitly."

In Loops, the way we solved this problem was to provide each savable object a
unique identifier.  This UID was constructed from some representation of the
machine of ceation and the time of creation.  An object knows its UID, and from
the UID one can find the object.  For any object, the form that was dumped
includes its UID, as well as its contents.  References from a dumped object to
another object contain a form which reconstructs the pointer to object referred
to, but does not try to reconstruct its contents.  

Suppose we had an objects O1 and O2, of classes FOO and FIE respectively, each
with one slot named OTHER pointing to the other object.  Then  dumping them to a
file might create expressions like:

#,(reconstruct-object uid1 FOO OTHER #.(pointer-to-object uid2 FIE))

#,(reconstruct-object uid2 FOO OTHER #.(pointer-to-object uid1 FOO))

The result of evaluating (pointer-to-object uid2 FIE) is to create an
uninitialized object of class FIE, and make it be the value of the slot OTHER of
O1.  O1 is the object created by the first reconstruct-object form, with UID
uid1.  Evaluating the second reconstruct-object form changes the contents of the
uninititialized object.  Evaluating the form (pointer-to-object uid1 FOO) finds
the first object created.

As far as tracing through objects, we found it was better to separate out the
process of finding all objects that you want dumped (a user defined trace that
creates a list).  One then dumps each of the listed objects.  Stan Lanning
implemented a preliminary CLOS version that we have been experimenting with.
 

∂18-Jul-88  0808	Common-Lisp-Object-System-mailer 	Re: putting CLOS objects in binfiles     
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 18 Jul 88  08:08:54 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA22842; Mon, 18 Jul 88 08:06:28 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA15584; Mon, 18 Jul 88 08:07:04 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA18158; Mon, 18 Jul 88 08:06:20 PDT
Message-Id: <8807181506.AA18158@suntana.sun.com>
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: John Rose <jrose@Sun.COM>, common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Re: putting CLOS objects in binfiles 
In-Reply-To: Your message of Fri, 15 Jul 88 17:07:00 -0400.
             <19880715210732.7.MOON@EUPHRATES.SCRC.Symbolics.COM> 
Date: Mon, 18 Jul 88 08:06:17 -0700
From: kempf@Sun.COM

>I'm not sure that anything in Common Lisp requires that multiple
>references to a single object, in a file being compiled, do not
>turn into multiple objects when the file is loaded.  You might have

Yes, in fact, there is one Common Lisp implementation in which references
to vectors are not EQ after loading. After looking through selected sections
of CLtL, no guarantees seem to be made about preserving EQness between compile
time and run time.

			jak

∂18-Jul-88  1307	Common-Lisp-Object-System-mailer 	putting CLOS objects in binfiles    
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 18 Jul 88  13:07:13 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA29734; Mon, 18 Jul 88 13:04:21 PDT
Received: from lukasiewicz.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA29199; Mon, 18 Jul 88 13:04:51 PDT
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
	id AA18995; Mon, 18 Jul 88 13:06:16 PDT
Date: Mon, 18 Jul 88 13:06:16 PDT
From: jrose@Sun.COM (John Rose)
Message-Id: <8807182006.AA18995@lukasiewicz.sun.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, Bobrow.pa@Xerox.COM
Cc: common-lisp-object-system@SAIL.STANFORD.EDU
Cc: jrose@Sun.COM
In-Reply-To: David A. Moon's message of Fri, 15 Jul 88 17:07 EDT <19880715210732.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: putting CLOS objects in binfiles

   Date: Fri, 15 Jul 88 17:07 EDT
   From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

       Date: Fri, 15 Jul 88 12:42:03 PDT
       From: jrose@Sun.COM (John Rose)

       It's a shame that there's no provision in CLOS for
       saving objects in binfiles.
     ...
       Here's essentially what's needed:  A generic function
       (called, say, RECONSTRUCTOR-FORM) which returns a
       Lisp form to evaluate to reconstruct any given
       object.  

   This is fine.  It's how Flavors does it, so there is some
   precedent.  The only problem with this technique is that it
   doesn't cope well with circular structures, which can only
   be handled by separating creation of the objects from filling
   them in (and even that doesn't work in general, for reasons
   too complicated to get into here).
  ...
OK, I'd like to create a proposal.  I understand my hallmate
Cris Perdue is thinking about binfiles, so I'll talk with him
some first.

To deal with circularities, one can separate the object creation
protocol into two passes, one to create a reference to an uninitialized
object (which can be used to plug into other structures), and a second
pass to initialize the object itself.  You say there are in
general problems here, and I imagine you are referring to
the window between the two passes, when the object can be
referenced, but might not yet contain valid data.  Do you
think this problem can be addressed adequately as follows:

  At dump time, if circularities are detected, the target
  of a back-arc (which will need to be created in two passes
  at load time) is passed to a generic function (named, e.g.,
  CIRCULAR-RECONSTRUCTOR-FORMS) which either generates parameters
  for the two load time passes, or signals an error at dump time.

This would allow a class to disallow all or some circularities,
or handle them in a class-specific manner, by gaining some control
over the window between the two load time passes.  An object
in the inter-pass window could even have a different class; pass 2
could perform a CHANGE-CLASS.

Also, let me make another stab at a default behavior for dumping:
Use the PRINT-OBJECT printer, and save the string the binary file.
Proper use of a *PRINT-READABLY* flag would be required to detect errors,
and recursive calls to PRINT-OBJECT would have to transfer
control to the binary dumper (leaving a #<n># or similar
notation in the object's string).  The advantage of this
default is that the class writer need only code a readable
PRINT-OBJECT representation, and not worry about binary files
explicitly.

       Here's my immediate problem:  I want to build objects
       which represent predicates in a special purpose query
       language, and I want them to be uniquified, like pathnames
       on the Lisp Machine.  (They cache things like compiled Lisp
       code, so it's expensive to build new copies.)  Such things
       do not dump properly, and even if a simple patch were to
       be applied (say, to dump a class symbol instead of a class),
       a simple-minded load routine would not uniquify them.

   I'm not sure that anything in Common Lisp requires that multiple
   references to a single object, in a file being compiled, do not
   turn into multiple objects when the file is loaded.

Symbols load as single objects.  And on the Lisp Machine (last
time I looked) pathnames were interned in the same way.
I think this is done because symbols and pathnames are
used as names, or references for other objects, and making
them EQ makes for fast comparison, and allows referencing
parties to make shared annotations on the name object.
					       		You might have
   to address this in an implementation-dependent way unless the
   definition of Common Lisp were changed to require this explicitly.
   I think most implementations do guarantee object identity within
   a single COMPILE-FILE, even though they're not required to.
   This is not a CLOS issue, it applies to all objects for which EQ
   is defined.

I'm willing to guarantee object identity myself, if I can only
get control whenever the system thinks it wants to cons one of
my objects, and intern it.  Something like this:
	(LET ((TABLE (MAKE-HASH-TABLE :TEST 'EQUAL)))
	  (DEFMETHOD MAKE-INSTANCE ((EQL 'MYCLASS) &KEY X Y)
	    (LET ((PARAMS (LIST X Y)))
	      (OR (GETHASH PARAMS TABLE)
		  (SETF (GETHASH PARAMS TABLE)
			(CALL-NEXT-METHOD))))))



   Date: 15 Jul 88 17:08 PDT
   From: Bobrow.pa@Xerox.COM

   In Loops, the way we solved this problem was to provide each savable object a
   unique identifier.  This UID was constructed from some representation of the
   machine of ceation and the time of creation.  An object knows its UID, and from
   the UID one can find the object.  For any object, the form that was dumped
   includes its UID, as well as its contents.  References from a dumped object to
   another object contain a form which reconstructs the pointer to object referred
   to, but does not try to reconstruct its contents.  

Wow!  That's neat stuff.  It shows how far we've come that solutions
to the problem of object identity within a single Lisp session are taken
for granted (reread the CLtL chapter on packages if you think it's
no problem) and the current research is into defining and maintaining
uniqueness across much wider domains, such as all machines and times
in some space.

But all I wanted (this time) was uniqueness across a session, and
some sort of transportable printed representation, like symbols or LispM
pathnames.

					-- John

∂26-Jul-88  0847	Common-Lisp-Object-System-mailer 	where I'm going, etc.
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Jul 88  08:47:37 PDT
Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 438595; Tue 26-Jul-88 11:47:05 EDT
Date: Tue, 26 Jul 88 11:46 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: where I'm going, etc.
To: common-lisp-object-system@sail.stanford.edu
Message-ID: <19880726154638.0.SKEENE@JUNCO.SCRC.Symbolics.COM>


I will be leaving Symbolics this Friday, and my new job is not
Lisp-related or CLOS-related.    I'm sorry to say that this means I
won't be able to continue going to meetings at X3J13, or keeping up with
the rest of the CLOS work.    I hope to be able to stay on the CLOS
mailing list at my new company, and maybe help out with editing of the
Meta-object chapter now and then.

I did finish writing my book, about one day after we voted to accept
CLOS.  The book will be available within a couple of weeks.  It's called
"Object-Oriented Programming in Common Lisp:   A Programmer's Guide to
CLOS", and it is being published by Addison-Wesley and Symbolics Press.
I hope everyone will read and enjoy it. 

I have many mixed feelings about leaving this community, especially when
my book is just about to be published, and while there is still much
work to be done on the Meta-object protocol and on the Common Lisp
specification itself.    Certainly, working with the CLOS group has been
a great honor, a wonderful learning experience, and a lot of fun over
the last two years.   

My new job will be a real departure, although it is still in the
computer software field.   The company is called "ITP boston" and they
do factory-automation software.    They are spinning off a company to
develop and market a product, and I'll be leading the documentation 
effort of the new spinoff.

I looked for a job that would allow me to continue my CLOS and Lisp
work, but I didn't find anything that really felt right.   Maybe
something will eventually turn up in that field for me, and you'll see 
me at meetings again.   

In any case, if you're in Boston and want to meet me for lunch or 
dinner, GIVE ME A CALL!  I'd very much like to keep in touch.  If the
phone numbers below change for any reason, ask David Moon where I am.

My home phone is:   617-648-4323 (Arlington, Mass.) 
On August 8, my work phone will be:   617-499-4200 (Cambridge)


∂02-Aug-88  1412	Common-Lisp-Object-System-mailer 	declare in with-slots
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Aug 88  14:09:01 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 02 AUG 88 13:53:08 PDT
Date: Tue, 2 Aug 88 13:51 PDT
From: Gregor.pa@Xerox.COM
Subject: declare in with-slots
To: common-lisp-object-system@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest
Message-ID: <19880802205147.3.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no


We never discussed how people could use declare inside of with-slots.  I
don't think we ever thought of it.  But to at least one of my users,
this is a serious bug.  Here is an idea for how to fix this.  I am not
enough of a declaration expert to know if this can work.

All of what I say here also applies to with-accessors.

Allow declarartions to appear in front of the with-slots body.  These
declarations affect the pseudo-bindings performed by the with slots.
They talk about the value which will be returned by evaluating one of the
pseudo variables and the values which will be stored in the pseudo
variables.  The SPECIAL declaration is, of course, now allowed.

So, for example:

(with-slots (x y z) <instance>
  (declare (fixnum x y z))
  (setq z (* x y)))

Becomes:

(progn
   (setf (the fixnum (slot-value <instance> 'z))
         (* (the fixnum (slot-value <instance> 'x))
	    (the fixnum (slot-value <instance> 'x)))))

If this makes sense, a cleanup proposal should do the trick.

Note that I didn't layer this directly into symbol-macrolet.  We could
of course put it there, but it seemed to me that it was more appropriate
for this to be something which the caller of symbol-macrolet handles.  I
could pretty easily be convinced that I am wrong about this.
-------

∂03-Aug-88  0712	Common-Lisp-Object-System-mailer 	RE: decalre in with-slots 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 Aug 88  07:12:15 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA03551; Wed, 3 Aug 88 07:10:42 PDT
Date: Wed, 3 Aug 88 07:10:42 PDT
Message-Id: <8808031410.AA03551@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
To: Gregor.pa@xerox.com
Subject: RE: decalre in with-slots

> We never discussed how people could use declare inside of with-slots.  I
> don't think we ever thought of it. 

My problem all along with with-slots and symbol-macrolet has been that they
haven't been thought through.  It's not simple to mount this charade that slots
are "just like" variables.  I've come in too late on this work to have said
this earlier, but I will predict now that you will find still other problems
with symbol-macrolet as time goes by.


As to the suggested patch:  No, it won't really work.  Declare's are pretty
much the province of special forms, and with-slots et al won't, in general, be
able to parse the declare's, let alone interpret them correctly.  For example,
a common extension to declare allows:

(deftype t-terminated-list () '(or cons (member t)))

(with-slots (x y z) <instance>
  (declare (t-terminated-list y))
  ...)

In Common Lisp, you can't tell that t-terminated-list is a type, and, even if
you could, you couldn't be sure that this meant 
(declare (type t-terminated-list y)).  (It might mean (declare (ftype ...)), 
which would have nothing at all to do with the _variable_ y.)

While you're thinking about this, consider what would happen if Common Lisp
were extended to allow:

(with-slots (x y z) <instance>
  ...
  (locally (declare (fixnum y))
    ...)
  ...)

[CL doesn't currently allow this, but there's some sentiment to make this
extension.]  Now with-slots would have to parse the entire body to get this
right. 
 
> Note that I didn't layer this directly into symbol-macrolet.  We could
> of course put it there, but it seemed to me that it was more appropriate
> for this to be something which the caller of symbol-macrolet handles.  I
> could pretty easily be convinced that I am wrong about this.
 
What's the point of symbol-macrolet, then, if not to be the form which says
"pretend foo is a variable, even though it's not"?  You're suggesting that only
with-slots wants to play "let's pretend," and that there's some different roles
that symbol-macrolet fills?  I doubt it...

/JEP

∂03-Aug-88  0852	Common-Lisp-Object-System-mailer 	RE: declare in with-slots 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 3 Aug 88  08:52:40 PDT
Received: by ti.com id AA05029; Wed, 3 Aug 88 10:50:48 CDT
Received: from Kelvin by tilde id AA28918; Wed, 3 Aug 88 10:35:22 CDT
Message-Id: <2795614606-3753982@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 3 Aug 88  10:36:46 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jeffrey Piazza <piazza%lisp.DEC@decwrl.dec.com>
Cc: Common-Lisp-Object-System@SAIL.Stanford.Edu
Subject: RE: declare in with-slots
In-Reply-To: Msg of Wed, 3 Aug 88 07:10:42 PDT from Jeffrey Piazza <piazza%lisp.DEC@decwrl.dec.com>

I agree with Piazza's sentiment that it is not reasonable to expect
macros to comprehend the semantics of declarations.  This appears to be
another reason why SYMBOL-MACROLET ought to be a special form; then it
could accept declarations, and WITH-SLOTS could just pass them through.
(But I'm not necessarily endorsing the notion that type declarations
need to be supported here.)

  -- David Gray

∂03-Aug-88  1024	Common-Lisp-Object-System-mailer 	declare in with-slots
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 3 Aug 88  10:24:28 PDT
Received: by labrea.stanford.edu; Wed, 3 Aug 88 10:22:44 PDT
Received: from rainbow-warrior.lucid.com by edsel id AA01559g; Wed, 3 Aug 88 10:18:11 PDT
Received: by rainbow-warrior id AA12130g; Wed, 3 Aug 88 10:19:32 PDT
Date: Wed, 3 Aug 88 10:19:32 PDT
From: Patrick Dussud <edsel!dussud@labrea.stanford.edu>
Message-Id: <8808031719.AA12130@rainbow-warrior.lucid.com>
To: Gregor.pa@xerox.com
Cc: common-lisp-object-system@sail.stanford.edu
In-Reply-To: Gregor.pa@Xerox.COM's message of Tue, 2 Aug 88 13:51 PDT <19880802205147.3.GREGOR@PORTNOY.parc.xerox.com>
Subject: declare in with-slots

   Date: Tue, 2 Aug 88 13:51 PDT
   From: Gregor.pa@Xerox.COM
   Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest
   Line-Fold: no


   We never discussed how people could use declare inside of with-slots.  I
   don't think we ever thought of it.  But to at least one of my users,
   this is a serious bug.  Here is an idea for how to fix this.  I am not
   enough of a declaration expert to know if this can work.

   All of what I say here also applies to with-accessors.

   Allow declarartions to appear in front of the with-slots body.  These
   declarations affect the pseudo-bindings performed by the with slots.
   They talk about the value which will be returned by evaluating one of the
   pseudo variables and the values which will be stored in the pseudo
   variables.  The SPECIAL declaration is, of course, now allowed.

   So, for example:

   (with-slots (x y z) <instance>
     (declare (fixnum x y z))
     (setq z (* x y)))

The syntax makes sense.

   Note that I didn't layer this directly into symbol-macrolet.  We could
   of course put it there, but it seemed to me that it was more appropriate
   for this to be something which the caller of symbol-macrolet handles.  I
   could pretty easily be convinced that I am wrong about this.
   -------
I think that it has to be put in symbol-macrolet as well. If not, the work
that has to be done in with-slot is beig enough so the layering is totally
useless. Maybe making with-slots and with-accessors special forms and forget
about symbol-macrolet is a good solution. The context is narrower that we
originally proposed, so the semantics issue will be easier to nail down.

Patrick.

∂03-Aug-88  1150	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 3 Aug 88  11:50:09 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA28905; Wed, 3 Aug 88 11:47:53 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA12009; Wed, 3 Aug 88 11:48:33 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA18770; Wed, 3 Aug 88 11:47:24 PDT
Message-Id: <8808031847.AA18770@suntana.sun.com>
To: common-lisp-object-system@sail.stanford.edu
Subject: Re: declare in with-slots 
In-Reply-To: Your message of Wed, 03 Aug 88 10:19:32 -0700.
             <8808031719.AA12130@rainbow-warrior.lucid.com> 
Date: Wed, 03 Aug 88 11:47:10 -0700
From: kempf@Sun.COM


I'm not sure I understand what all the fuss is about. Currently in
Common Lisp, the following is not allowed;

	(multiple-value-bind (x y z)
	  (declare (fixnum x y z))
	  (multiple-return-value-function a b c)

	  ...
	)

Seems to me with-slots and with-accessors falls into the same category.
It would, of course, be nice to be able to do the above, just as it
would for with-slots, but the following also works in at least one
CL I've used:

	(multiple-value-bind (x y z)
	  (multiple-return-value-function a b c)

	  (locally 
	    (declare (fixnum x y z))

		...
	  )
	)

As to people not liking with-slots because it is Yet Another Scoping
Mechanism, I feel the same about the multiple value constructs, but
some people like them. 

		jak




∂03-Aug-88  1504	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 3 Aug 88  15:04:50 PDT
Received: by ti.com id AA02329; Wed, 3 Aug 88 17:03:57 CDT
Received: from Kelvin by tilde id AA08593; Wed, 3 Aug 88 16:48:23 CDT
Message-Id: <2795636967-5097451@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 3 Aug 88  16:49:27 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: kempf@SUN.COM
Cc: common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Re: declare in with-slots 
In-Reply-To: Msg of Wed, 03 Aug 88 11:47:10 -0700 from kempf@SUN.COM

> I'm not sure I understand what all the fuss is about. Currently in
> Common Lisp, the following is not allowed;
> 
> 	(multiple-value-bind (x y z)
> 	  (declare (fixnum x y z))
> 	  (multiple-return-value-function a b c)
> 
> 	  ...
> 	)

The correct syntax is:

	(multiple-value-bind (x y z)
	    (multiple-return-value-function a b c)
	  (declare (fixnum x y z))

	  ...
	)

> It would, of course, be nice to be able to do the above, just as it
> would for with-slots, but the following also works in at least one
> CL I've used:
> 
> 	(multiple-value-bind (x y z)
> 	  (multiple-return-value-function a b c)
> 
> 	  (locally 
> 	    (declare (fixnum x y z))
> 
> 		...
> 	  )
> 	)

It may be allowed, but it doesn't seem very useful because it doesn't
change the fact that tagged value slots have to be used.

  -- David Gray

∂03-Aug-88  1538	Common-Lisp-Object-System-mailer 	declare in with-slots
Received: from SPAR-20.SPAR.SLB.COM by SAIL.Stanford.EDU with TCP; 3 Aug 88  15:37:54 PDT
Date: Wed, 3 Aug 1988  15:37 PDT
Message-ID: <GAK.12419581321.BABYL@SPAR-20.SPAR.SLB.COM>
From: Glenn Andrew Kramer <GAK@SPAR-20.SPAR.SLB.COM>
To:   Gregor.pa@XEROX.COM
Cc:   common-lisp-object-system@SAIL.STANFORD.EDU
Subject: declare in with-slots
In-reply-to: Msg of 2 Aug 1988  13:51-PDT from Gregor.pa at Xerox.COM


One other point to be made with respect to declarations and with-slots is that
the types of the slots may already be declared in the class definition. If a
slot is declared to be fixnum in the defclass, then it should automatically be
treated as such in the body of a with-slots, without having to place another
explicit declaration.

∂04-Aug-88  0828	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 4 Aug 88  08:28:30 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA12267; Thu, 4 Aug 88 08:25:58 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA27693; Thu, 4 Aug 88 08:26:39 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA20536; Thu, 4 Aug 88 08:25:33 PDT
Message-Id: <8808041525.AA20536@suntana.sun.com>
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Re: declare in with-slots 
In-Reply-To: Your message of Wed, 03 Aug 88 16:49:27 -0500.
             <2795636967-5097451@Kelvin> 
Date: Thu, 04 Aug 88 08:25:30 -0700
From: kempf@Sun.COM


>The correct syntax is:
>
>	(multiple-value-bind (x y z)
>	    (multiple-return-value-function a b c)
>	  (declare (fixnum x y z))
>
>	  ...
>	)


OK, so how about:

	(with-slots (x y z) obj
	  (declare (fixnum x y z))

	   ...
	)

though, as Glenn Kramer has pointed out, the declaration is actually
redundent because the types can be deduced from the class definition.
Other declarations, like compilation optimization and special declarations,
cannot, however. There is a question of whether those should be allowed.

The expansion of with-slots would be something like:

	(symbol-macrolet
	  ( (x (the fixnum (slot-value 'x obj)))
	    (y (the fixnum (slot-value 'y obj)))
	    (z (the fixnum (slot-value 'z obj)))
	  )
	  (locally
	    <any other declarations>

	    ...
	  )
	)

so the expansion would, indeed, have to check for type declarations on the
pseudovariables. symbol-macrolet does not, however.

If type declarations are allowed, then the question of what to do should
a conflict between the declaration of types in the class and the local
declaration occurs. There are a number of options here, everything from
leaving it up to the implementation to decide to checking if the local
declaration is wider than the declaration in the class (e.g. a local
declaration of number when the class declared the slot to be fixnum)
and signalling an error. Having a narrower declaration (e.g. a
local declaration of fixnum when the class declared the slot to be
number) could have important uses in some cases.

		jak



∂04-Aug-88  1134	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 4 Aug 88  11:34:31 PDT
Received: by ti.com id AA10039; Thu, 4 Aug 88 13:33:30 CDT
Received: from Kelvin by tilde id AA02949; Thu, 4 Aug 88 13:23:04 CDT
Message-Id: <2795711083-4281424@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 4 Aug 88  13:24:43 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: kempf@Sun.COM
Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
Subject: Re: declare in with-slots 
In-Reply-To: Msg of Thu, 04 Aug 88 08:25:30 -0700 from kempf@Sun.COM

> though, as Glenn Kramer has pointed out, the declaration is actually
> redundent because the types can be deduced from the class definition.

That assumes that you know the class of the object expression; the
compiler might know, but a macro would not.  The type lookup could be done
at either the WITH-SLOTS or SYMBOL-MACROLET level, but whichever one does
it would have to be a special form.

  -- David Gray

∂05-Aug-88  1331	Common-Lisp-Object-System-mailer 	description language classes & the Meta-Object Protocol 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 5 Aug 88  13:31:42 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA04593; Fri, 5 Aug 88 13:29:18 PDT
Received: from lukasiewicz.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA09117; Fri, 5 Aug 88 13:29:59 PDT
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
	id AA05986; Fri, 5 Aug 88 12:25:14 PDT
Date: Fri, 5 Aug 88 12:25:14 PDT
From: jrose@Sun.COM (John Rose)
Message-Id: <8808051925.AA05986@lukasiewicz.sun.com>
To: common-lisp-object-system@sail.stanford.edu
Subject: description language classes & the Meta-Object Protocol

[This is a message which I sent a week and a half ago to the commonloops
mailing list.  I have since learned that this is a more appropriate list
to mail such discussions to, so I'm reposting.  If you've already
seen this, sorry for the redundancy.  I've changed nothing in the message.
				-- John

Original header:
Date: Mon, 25 Jul 88 16:12:16 PDT
To: commonloops.pa@xerox.com]

I'm going to describe a way I'd like to use the Meta-Object Protocol.
Hopefully, readers of this list will either tell me why it's a
misuse, or assure me that the Meta-Object Protocol will support
what I have in mind.

Start with a description language L.  That is, terms in L denote
predicates over some universe U; they describe objects in U.
(You could also call L a pattern language.)  There is some efficient
Lisp function L-APPLY which applies an L-term to a U-object and returns
T or NIL, depending on whether the term describes the object.

There is one other property of L:  There is a Lisp function L-LESSP
which takes any two L-terms t1, t2 and compares them, returning T or NIL,
depending on whether t1 entails t2 for all U-objects.  This is
a partial order on the description language.  Think of it this
way:  Less specific terms are greater than more specific ones.

Finally, define *L-TOP* to be the L-term which is greater than
all other L-terms (the least specific element).

(It is possible and useful to make L into a lattice by adding Lisp
functions L-MEET and L-JOIN, but I don't think that is necessary for
this discussion.)

I'd like to define a Meta-Class L-CLASS which models L.  In particular,
each L-term would correspond to an L-CLASS.  An L-term's L-CLASS would
have as instances all U-objects which match the L-term.  Note that
an L-CLASS does not necessarily support MAKE-INSTANCE:  As befits
a description language, the L-CLASSes merely impose structure on
a pre-existing space of U-objects.

Methods arguments can be specialized with L-CLASS specializers;
such arguments are assumed to be U-objects, and the method
is applied only to arguments that match the specializer.
That is, the L-CLASS protocol wraps the method body with code
which uses L-APPLY to filter out U-objects which don't match
the specializer.  This is just like STANDARD-CLASS dispatching,
except that L-APPLY can interpret L-terms using any algorithm
whatsoever.

If a generic is applied to a U-object, there will in general
be several methods which apply; they must be ordered most
specific first.  The computation of this ordering is done
with the L-LESSP predicate.  This works much like STANDARD-CLASS
method ordering.  When the specializers of applicable methods
are not linearly ordered (this case corresponds to class multiple
inheritance) , the L-CLASS must specify some sort of linearization,
so that CALL-NEXT-METHOD will be useful.

In any case, when a U-object is handed to a generic function
with L-CLASS specializers, only methods with specializers
that correctly describe the U-object are invoked, and then
in a reasonable order determined by description specificity.

You know, object oriented languages supply two very distinct services
that are often confused:  Representation management, and argument
dispatching.  Abstract types can be built from concrete representations,
often drawn from a rich set of possibilities (e.g., C++).  Abstract
functions can be built, piece by piece, from methods, each applicable
to a limited set of arguments; the OOL supplies the glue logic which
makes sure that each method gets the right kinds of arguments.
The distinction between the two services is based on this observation:
It is not necessary that the set of representations be identical
with the set of dispatchable types.  (In practice, it's often useful
to tightly coordinate the two services, since the OOL system can
then optimize representations for fast dispatch.)

Description language classes supply the argument dispatch service
only.  (By contrast, facilities like DEFSTRUCT construct representations
without dispatch services.)

For concreteness, I'll give several examples of description languages
that could be usefully treated as meta-classes:

  * Common Lisp types
    The Common Lisp type system is a description language.
    L-APPLY is TYPEP, and L-LESSP is SUBTYPEP, although the
    SUBTYPEP relation is not as rich as the corresponding
    mathematical subtyping relation.

  * standard classes
    If you forget about slots and consing, you can treat standard
    classes as predicates over their objects.  This example is
    just a special case of the previous.

  * object identity
    The EQL specializers support a trivial description language,
    where all classes are singletons (except *L-TOP*, which is the type T).
    Here, L-APPLY is only EQL (apart from *L-TOP*) and so is L-LESSP.

  * Lisp structure patterns
    Someone from the functional programming community wanted to
    have specializers which were structure templates.  Often
    the pattern matching incorporates the binding of variables
    to matched substructures for later access.  This sort of thing
    is extremely useful.  (For example, Lisp compilers seem always
    to have some a destructuring case macro, with which they
    analyze program syntax.)

    Interestingly, L-LESSP is straightforward to define for
    destructuring patterns; it roughly consists of applying
    the second pattern to the first.

  * user-interface event patterns
    This is the application which I've been recently thinking about,
    which triggered this note.  User-interface modules often want to
    filter the events they see to some small set of "interesting"
    events.  This can be done with an event pattern.  Suppose a key
    event has three attributes: 1. key making the transition, 2. type of
    transition (e.g., up, down, click), and 3. modifier key state.
    Then an event pattern would specify a value for each attribute,
    or specify a wildcard of some sort.

    Clearly this is a description language.  (In fact, it is a
    product language, made from three languages, one for each
    attribute.)  It is easy to define L-APPLY and L-LESSP.

    If a module wanted to handle a class of events, it could define
    a method on an appropriate generic function, specialized to the
    desired event pattern.  The event-pattern meta-class would have
    the responsibility of building the glue logic to dispatch
    incoming events to the correct handler.  It's good to centralize
    this logic, because it can then be optimized more readily,
    and redundant tests eliminated.

    CLOS double dispatch would help here too:  Event handlers could be
    specialized both to consumer-object mixins and event types.

  * string regular expressions
    The theory of regular languages is well understood, and regular
    expressions are useful in a wide variety of settings.  A regular
    expression meta-class could be used to define complex string handling
    functions in a modular fashion.  Regular languages can be compared
    for specificity, so an L-LESSP predicate can be defined.  Also,
    efficient methods are known for matching several regular
    expressions at once to a single string; the meta-class would
    use these methods to build efficient dispatch ("glue") logic,
    as in the previous example.

  * knowledge base queries
    Pick your favorite database query language.  It certainly supports
    an L-APPLY operation, and probably also supports an L-LESSP.
    Now, with the right L-CLASS, you can define generic functions over
    database entries.  (It may be more useful to manipulate __sets__
    of entries, so U would then be a power set of some sort.
    This does not hinder the applicability of CLOS.)

I hope I have shown that (1) description languages are common and
useful, that (2) a general class of description languages are
amenable to treatment within the CLOS generic function framework,
and that (3) descriptions are very useful as defmethod
specializers.  The conclusion is that the designers of the
Meta-Object protocol should be sure to provide for arbitrary
description languages (of the L-APPLY/L-LESSP sort).

Finally, here are some smaller open questions about description
language classes, along with some possible answers:

  * How should the L-CLASS specify a linearization of a partially
    ordered set of applicable methods?

    [It is sometimes useful to signal an error if there is not a linear
    ordering available.  This could the default, with a hook for other
    more permissive behavior.]

  * What if the L-LESSP relation is not always effectively computable?
    (E.g., LISP:SUBTYPEP gives up sometimes.)

    [Allow the L-LESSP relation to give up, and treat this outcome like
    incomparability.  It should be possible to signal an error here,
    while still doing something permissive on true incomparability.]

  * If the L-term has "wildcards" in it, how should the L-CLASS mediate
    the binding of the corresponding U-object subparts to names for
    use in method bodies?

    [I believe the current protocol (e.g., DEFINE-METHOD-COMBINATION)
    provides enough hooks for this.  The hook which asks a meta-class
    for dispatch code should also accept LET-bindings, which would
    be constructed along with the dispatch code, and wrapped around
    the affected method body.]

  * What sort of syntax should L-CLASS specializers have?

    [The (EQL ...) syntax should be extended, I think.  The basic
    idea is that EQL is a meta-class name, and the arguments to
    it are handed to the meta-class constructor, which then
    builds the appropriate class object.  This is probably already
    the intention of the CLOS designers, but I want to affirm
    that choice.]

Let me close with a suggestive example:

	(DEFMETHOD EVAL ((X (FORM `(,F . ,A))))
	  (APPLY (EVAL `#',F) (MAPCAR #'EVAL A)))

	(DEFMETHOD EVAL ((X (FORM `(IF ,P ,A ,B))))
	  (IF (EVAL P) (EVAL A) (EVAL B)))

This example uses a hypthetical description language called FORM,
whose terms are backquoted constructors, interpreted in reverse.
(Or, if you like, declaratively as opposed to imperatively.)
Note that the specificity ordering ensures that IF forms will
not get passed to the first method, even though they match
its specializer.

				-- John


∂05-Aug-88  1833	Common-Lisp-Object-System-mailer 	Re: description language classes & the Meta-Object Protocol  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Aug 88  18:33:11 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 05 AUG 88 18:23:27 PDT
Date: Fri, 5 Aug 88 18:21 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: description language classes & the Meta-Object Protocol
To: John Rose <jrose@Sun.COM>
cc: common-lisp-object-system@sail.stanford.edu, CommonLoops.pa@Xerox.COM
Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest
In-Reply-To: <8808051925.AA05986@lukasiewicz.sun.com>
Message-ID: <19880806012130.5.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no

    Date: Fri, 5 Aug 88 12:25:14 PDT
    From: jrose@Sun.COM (John Rose)

    I'm going to describe a way I'd like to use the Meta-Object Protocol.
    Hopefully, readers of this list will either tell me why it's a
    misuse, or assure me that the Meta-Object Protocol will support
    what I have in mind.

Danny and I spent some time talking about this, and I plan to send a
message about this next week once I finish the current round of hacking.
-------

∂08-Aug-88  1020	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Aug 88  10:20:22 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 AUG 88 10:19:22 PDT
Date: Mon, 8 Aug 88 10:18 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: declare in with-slots
To: Jeffrey Piazza <piazza%lisp.DEC@decwrl.dec.com>, Glenn Andrew Kramer
 <GAK@SPAR-20.SPAR.SLB.COM>, kempf@Sun.COM, David N Gray <Gray@DSG.csc.ti.com>
cc: common-lisp-object-system@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest
In-Reply-To: <19880802205147.3.GREGOR@PORTNOY.parc.xerox.com>,
              <8808031410.AA03551@decwrl.dec.com>,
              <GAK.12419581321.BABYL@SPAR-20.SPAR.SLB.COM>,
              <8808041525.AA20536@suntana.sun.com>,
              <2795711083-4281424@Kelvin>
Message-ID: <19880808171852.6.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no


    Date: Wed, 3 Aug 88 07:10:42 PDT
    From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)

    As to the suggested patch:  No, it won't really work.  Declare's are pretty
    much the province of special forms, and with-slots et al won't, in general, be
    able to parse the declare's, let alone interpret them correctly.  For example,
    a common extension to declare allows:

    (deftype t-terminated-list () '(or cons (member t)))

    (with-slots (x y z) <instance>
      (declare (t-terminated-list y))
      ...)

This declaration is clearly illegal according to CLtL.  Page 158,
paragraph 4 says:

  (<type> <var1> ...) is an abbreciation for (TYPE <type> <var1> ...)
  provided <type> is one of the types appearing in Table 4-1.

The reason this extension is a bad idea transcends with-slots and
friends of course.  No portable program analyzing program can analyze
code that uses this extension.

But, if a given implementation does in fact make this extension, it
could just smarten up its with-slots (or symbol-macrolet) implementation
to understand this case.

    While you're thinking about this, consider what would happen if Common Lisp
    were extended to allow:

    (with-slots (x y z) <instance>
      ...
      (locally (declare (fixnum y))
	...)
      ...)

    [CL doesn't currently allow this, but there's some sentiment to make this
    extension.]  Now with-slots would have to parse the entire body to get this
    right.

As would a large number of other forms that could be affected by this
change.  Putting the declare mechanism inside of symbol-macrolet, might
be percieved to "solve" this problem.  It seems to me that the real
problem with this case would be profusion of declaration hair though.
 
    What's the point of symbol-macrolet, then, if not to be the form which says
    "pretend foo is a variable, even though it's not"?  You're suggesting that only
    with-slots wants to play "let's pretend," and that there's some different roles
    that symbol-macrolet fills?  I doubt it...

This code from Jim Kempf shows how I was intending to have with-slots
expand, and shows clearly why I didn't think symbol-macrolet was the
place to support this.  Of course it is just as easy to put this in
symbol-macrolet as far as I am concerned.

    The expansion of with-slots would be something like:

	    (symbol-macrolet
	      ( (x (the fixnum (slot-value 'x obj)))
		(y (the fixnum (slot-value 'y obj)))
		(z (the fixnum (slot-value 'z obj)))
	      )
	      (locally
		<any other declarations>

		...
	      )
	    
-------

∂10-Aug-88  0952	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 10 Aug 88  09:51:58 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA24519; Wed, 10 Aug 88 09:50:50 PDT
Date: Wed, 10 Aug 88 09:50:50 PDT
Message-Id: <8808101650.AA24519@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
To: Gregor.pa@xerox.com
Subject: Re: declare in with-slots

    From:	DECWRL::"Gregor.pa@Xerox.COM"  "8-Aug-88 1018 PDT"  8-AUG-1988 
    To:	Jeffrey Piazza <lisp::piazza>, Glenn Andrew Kramer <GAK@SPAR-20.SPAR.SL
    CC:	
    Subj:	Re: declare in with-slots

    Cc: common-lisp-object-system@sail.stanford.edu


	Date: Wed, 3 Aug 88 07:10:42 PDT
	From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)

	...  For example,
	a common extension to declare allows:

	(deftype t-terminated-list () '(or cons (member t)))

	(with-slots (x y z) <instance>
	  (declare (t-terminated-list y))
	  ...)

    This declaration is clearly illegal according to CLtL.  

That's why I said "extension".

							    Page 158,
    paragraph 4 says:

      (<type> <var1> ...) is an abbreciation for (TYPE <type> <var1> ...)
      provided <type> is one of the types appearing in Table 4-1.

    The reason this extension is a bad idea transcends with-slots and
    friends of course.  No portable program analyzing program can analyze
    code that uses this extension.

I believe that's false.  A portable PAP can't use the declaration information,
that's all.  Of course, that might be a big lose, but declarations (except
SPECIAL) aren't supposed to affect semantics.  It would depend on what your
PAP was trying to find out.

    But, if a given implementation does in fact make this extension, it
    could just smarten up its with-slots (or symbol-macrolet) implementation
    to understand this case.

That's true.  I was thinking in terms of a portable implementation, which
would be impossible.  

	While you're thinking about this, consider what would happen if Common Lisp
	were extended to allow:

	(with-slots (x y z) <instance>
	  ...
	  (locally (declare (fixnum y))
	    ...)
	  ...)

	[CL doesn't currently allow this, but there's some sentiment to make this
	extension.]  Now with-slots would have to parse the entire body to get this
	right.

    As would a large number of other forms that could be affected by this
    change.  Putting the declare mechanism inside of symbol-macrolet, might
    be percieved to "solve" this problem.  It seems to me that the real
    problem with this case would be profusion of declaration hair though.



	What's the point of symbol-macrolet, then, if not to be the form which says
	"pretend foo is a variable, even though it's not"?  You're suggesting that only
	with-slots wants to play "let's pretend," and that there's some different roles
	that symbol-macrolet fills?  I doubt it...

    This code from Jim Kempf shows how I was intending to have with-slots
    expand, and shows clearly why I didn't think symbol-macrolet was the
    place to support this.  

Just because the expansion is relatively simple doesn't, of course, mean that
it's really the "right" thing to do.

What if I, a random user, wish to write e.g. my own "with-file-attributes"
macro, that lets me access things like the read and write dates for a file as
symbol-macrolet "variables".  Not being an implementor, I don't have access to
the system declaration-parsing stuff, so I can't support declarations in the
way you're proposing for with-slots and with-accessors.  I cry "no fair".

I am aware of no other macro which has to parse declarations -- they just get
pushed off to some special form or other.  I think that, for what you're
trying to do, you have to make symbol-macrolet be a special form, and do
declaration processing there.

/JEP

PS on a slight tangent:  What's the meaning of:


(with-slots (x y z) <instance>
  ...
  (locally (declare (special y))
    ...y...)
  ...)

Is the y inside the locally the special variable or the slot?  I believe the
current definition would make it the slot.  I also believe that's anomolous.

∂11-Aug-88  0810	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 11 Aug 88  08:10:33 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA24336; Thu, 11 Aug 88 08:07:26 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA02372; Thu, 11 Aug 88 08:07:44 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA11766; Thu, 11 Aug 88 08:06:24 PDT
Message-Id: <8808111506.AA11766@suntana.sun.com>
To: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
Cc: common-lisp-object-system@sail.stanford.edu
Subject: Re: declare in with-slots 
In-Reply-To: Your message of Wed, 10 Aug 88 09:50:50 -0700.
             <8808101650.AA24519@decwrl.dec.com> 
Date: Thu, 11 Aug 88 08:06:21 -0700
From: kempf@Sun.COM


>Just because the expansion is relatively simple doesn't, of course, mean that
>it's really the "right" thing to do.

Are we talking religion or engineering? If the former, then count me in
as a lang-nostic. :-)

Seriously, there is rarely ever a single "right" way to engineer anything.
There are usually pros and cons on both sides. The "pro" of this solution
is that it is simple, the "con" is that it treats type declarations for
pseudo variables differently from those for lexical variables or other
declarations.

>What if I, a random user, wish to write e.g. my own "with-file-attributes"
>macro, that lets me access things like the read and write dates for a file as
>symbol-macrolet "variables".  Not being an implementor, I don't have access to
>the system declaration-parsing stuff, so I can't support declarations in the
>way you're proposing for with-slots and with-accessors.  I cry "no fair".

This is a valid point, but I wonder if it isn't in the same category as
generalized code walkers.

>I am aware of no other macro which has to parse declarations -- they just get
>pushed off to some special form or other.  I think that, for what you're
>trying to do, you have to make symbol-macrolet be a special form, and do
>declaration processing there.

Two points here. First, though I've got no objection either way on making
symbol-macrolet be a special form, the goal of Common Lisp was (and I
think still is) to limit the number of special forms. Second, I think
it would be a mistake to confuse general declaration parsing with parsing
of declarations for pseudovariables. Symbol-macrolet will have to do declaration
parsing for pseudovariable declarations in any event. While there are no
macros which currently do declaration parsing, there are plenty which
do parsing (like defstruct). 

As a point of reference, HP Lisp had a special form called let-pseudo
whose semantics were identical to symbol-macrolet, and were used for
a similar purpose, namely to provide lexical scopes in which 
slot names could be used as pseudovariables for slot access. Type
declarations included in the class definition were included in 
the substitution form for the pseudovariable. I don't recall if 
declarations for pseudovariables were parsed (perhaps someone still
having access to HP Lisp could check), but I wouldn't be suprised
if they were.

		jak



∂11-Aug-88  1021	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 11 Aug 88  10:21:25 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA08505; Thu, 11 Aug 88 10:20:18 PDT
Date: Thu, 11 Aug 88 10:20:18 PDT
Message-Id: <8808111720.AA08505@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
To: kempf@sun.com
Subject: Re: declare in with-slots 

    From:	DECWRL::"kempf@Sun.COM"  "11-Aug-88 0806 PDT" 11-AUG-1988 11:09:28.36

    >Just because the expansion is relatively simple doesn't, of course, mean that
    >it's really the "right" thing to do.

    Are we talking religion or engineering? If the former, then count me in
    as a lang-nostic. :-)

Sometimes it's hard to tell the difference.

    Seriously, there is rarely ever a single "right" way to engineer anything.
    There are usually pros and cons on both sides. The "pro" of this solution
    is that it is simple, the "con" is that it treats type declarations for
    pseudo variables differently from those for lexical variables or other
    declarations.

I tend to believe that in engineering as elsewhere, "separate but
equal" facilities are never really "equal".  Declarations are
ultimately handled by the interpreter/compiler (even if you change a
"declare" into a "the"), and I anticipate lossage if macros try to
intercept them beforehand.  I'm just not confident that declarations
are understood well enough for this to be well-behaved.

    >What if I, a random user, wish to write e.g. my own "with-file-attributes"
    >macro, that lets me access things like the read and write dates for a file as
    >symbol-macrolet "variables".  Not being an implementor, I don't have access to
    >the system declaration-parsing stuff, so I can't support declarations in the
    >way you're proposing for with-slots and with-accessors.  I cry "no fair".

    This is a valid point, but I wonder if it isn't in the same category as
    generalized code walkers.

When I write a generalized code walker, I expect this level of hair,
while with-file-attributes seems like it should be simple to write.

    >I am aware of no other macro which has to parse declarations -- they just get
    >pushed off to some special form or other.  I think that, for what you're
    >trying to do, you have to make symbol-macrolet be a special form, and do
    >declaration processing there.

    Two points here. First, though I've got no objection either way on making
    symbol-macrolet be a special form, the goal of Common Lisp was (and I
    think still is) to limit the number of special forms.  

Well, we could give up, say, GO, and that would make for fewer special
forms :-).  I think that "pseudovariables" represent a real change in
the language semantics, and require a special form.  (As you probably
know, my personal preference would be to remove symbol-macrolet
altogether, rather than introduce a new special form.  But if you keep
the feature, I think you have to pay the price of a special form to
realize it.)

							   Second, I think
    it would be a mistake to confuse general declaration parsing with parsing
    of declarations for pseudovariables. Symbol-macrolet will have to do declaration
    parsing for pseudovariable declarations in any event. 

If symbol-macrolet were a special form, it would be the interpreter/
compiler that parsed out the declarations, just as it does for real
variables.  I think it would be a mistake NOT to unify declarations
for pseudovariables with declarations for real variables.

							  While there are no
    macros which currently do declaration parsing, there are plenty which
    do parsing (like defstruct). 

Defstruct gets to define the syntax it's parsing, which makes it
altogether different.  We're talking about having with-slots "skim"
some declaration text, extract the bits it thinks it's interested in,
and then put back what's left, so the interpreter or compiler can see
it.

    As a point of reference, HP Lisp had a special form called let-pseudo
    whose semantics were identical to symbol-macrolet, and were used for
    a similar purpose, namely to provide lexical scopes in which 
    slot names could be used as pseudovariables for slot access. Type
    declarations included in the class definition were included in 
    the substitution form for the pseudovariable. I don't recall if 
    declarations for pseudovariables were parsed (perhaps someone still
    having access to HP Lisp could check), but I wouldn't be suprised
    if they were.

If let-pseudo is really symbol-macrolet in disguise, then it's not
exactly independent evidence.  Also, if let-pseudo is/was a special
form, then it doesn't really apply to the question of macros that
parse declarations.  You can put all kinds of declarations in a
special form; it won't make me unhappy.

/JEP

∂07-Sep-88  2004	Common-Lisp-Object-System-mailer 	symbol-macrolet-semantics, symbol-macrolet-utility 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88  20:04:15 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 456000; Wed 7-Sep-88 23:03:21 EDT
Date: Wed, 7 Sep 88 23:03 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: symbol-macrolet-semantics, symbol-macrolet-utility
To: Gregor.pa@Xerox.COM, Jeffrey Piazza <piazza%lisp.DEC@decwrl.dec.com>,
    Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Dan L. Pierson <pierson%mist@MULTIMAX.ARPA>,
    Barry Margolin <barmar@Think.COM>, cl-cleanup%sail.stanford.edu@MULTIMAX.ARPA
cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU,
    Jeffrey Piazza <"piazza%lisp.DEC@decwrl.dec.com"@MULTIMAX.ARPA>
In-Reply-To: <871123130424.8.GREGOR@SPIFF.parc.xerox.com>,
             <8806222146.AA21530@decwrl.dec.com>,
             <8806281758.AA10391@decwrl.dec.com>,
             <880628165306.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
             <8806291818.AA11107@mist.UUCP>,
             <19880629204455.4.GREGOR@PORTNOY.parc.xerox.com>,
             <19880729021542.8.BARMAR@OCCAM.THINK.COM>,
             <8807292109.AA03546@decwrl.dec.com>,
             <880801135717.1.KMP@PEWEE.SCRC.Symbolics.COM>
Message-ID: <19880908030301.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

I thought it was already well-established that symbol-macrolet has to
be a special form, not a macro, and has to affect the behavior of
macroexpand.  10 months ago I argued that symbol-macrolet didn't
have to be a special form, but I was quite wrong.

I favor the proposal SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM except
for the part about forbidding use of symbol macros with SETQ
(and macros such as MULTIPLE-VALUE-SETQ and PSETQ that presumably
expand into SETQ), which I think is an unnecessary incompatible
change.

∂09-Sep-88  1203	RPG 	first part of mop   
 ∂09-Sep-88  1031	dussud@lucid.com 	first part of mop
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 9 Sep 88  10:31:08 PDT
Received: from kent-state ([192.9.200.24]) by heavens-gate.lucid.com id AA00784g; Fri, 9 Sep 88 09:29:19 PST
Received: by kent-state id AA07276g; Fri, 9 Sep 88 10:28:02 PDT
Date: Fri, 9 Sep 88 10:28:02 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8809091728.AA07276@kent-state>
To: Gregor.pa@Xerox.COM
Cc: Moon@Stony-Brook.SCRC.Symbolics.com, RPG@Sail.Stanford.edu,
        Bobrow.PA@Xerox.COM, dussud@lucid.com
In-Reply-To: Gregor.pa@Xerox.COM's message of Tue, 6 Sep 88 22:31 PDT <19880907053113.0.GREGOR@PORTNOY.parc.xerox.com>
Subject: first part of mop


I find the general contents quite good. I have few comments:

Do you intent to keep the description of the metaobjects like this, and then
present the accessors, in alphabetic order, one per page, or do you intend to
list them right were you describe the metaobjects?
Personally, I lean toward the latter approach:
-All of the accessors have several properties in common: The user cannot alter
the information returned by the accessors (lists of objects). The users cannot
rely on when and how may times, the system will call these accessors, and so
on.
-Their semantics are trivial. they just return some data from the objects. We
don't need a whole page each time to say that.

I was surprised by the principle 8 (pg 3-8). Since we say that slots for these
objects are internal business, I don't see why we should restrict the domain
of their names. The user shouldn't even try to find out their names.

I agree with the principles exposed here. Maybe you should emphasize the
distinction between the protocol specification, and the standard
implementation of the metaobject protocol, by saying that they will belong in
different parts of chapter 3.

Patrick.

∂10-Sep-88  1150	RPG 	Re: first part of mop    
 ∂09-Sep-88  1626	Gregor.pa@Xerox.COM 	Re: first part of mop   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Sep 88  16:26:02 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 09 SEP 88 15:37:34 PDT
Date: Fri, 9 Sep 88 15:37 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: first part of mop
To: Patrick Dussud <dussud@lucid.com>
cc: Moon@Stony-Brook.SCRC.Symbolics.com, RPG@Sail.Stanford.edu,
 Bobrow.PA@Xerox.COM
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <8809091728.AA07276@kent-state>
Message-ID: <19880909223720.5.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no

    Date: Fri, 9 Sep 88 10:28:02 PDT
    From: Patrick Dussud <dussud@lucid.com>

    I find the general contents quite good. I have few comments:

Thank you, I am glad to hear it.

    Do you intent to keep the description of the metaobjects like this, and then
    present the accessors, in alphabetic order, one per page, or do you intend to
    list them right were you describe the metaobjects?
    Personally, I lean toward the latter approach:

    -All of the accessors have several properties in common: The user cannot alter
    the information returned by the accessors (lists of objects). The users cannot
    rely on when and how may times, the system will call these accessors, and so
    on.
    -Their semantics are trivial. they just return some data from the objects. We
    don't need a whole page each time to say that.

I plan to do something like this, and for precisely the reasons you
mention.  I plan to put the protocol specification and the standard
protocol implementation specification in different places.  I plan to
group related methods like these to make it simple to talk about
properties they have in common.  For example, there is a principle that
says (something like) you can't override less than all of a set of
methods which share memory.

I do plan to leave the overview stuff where it is up front.  I realize
that this is just a specification, but I feel that the 2.5 pages it
takes up are worth it to provide that kind of summary of the
interconnections among metaobjects.

    I was surprised by the principle 8 (pg 3-8). Since we say that slots for these
    objects are internal business, I don't see why we should restrict the domain
    of their names. The user shouldn't even try to find out their names.

This principle may need debugging, but its reason for existing is to let
me know that the following code is sure to work in any implementation:

(in-package 'user)

(defclass foo (standard-class) (foo bar baz))

A reasonable question to ask is should we also make this code legal:

(in-package 'user)

(defclass bar (standard-class) (list car +))

    I agree with the principles exposed here. Maybe you should emphasize the
    distinction between the protocol specification, and the standard
    implementation of the metaobject protocol, by saying that they will belong in
    different parts of chapter 3.

Yes, this is what I plan.
-------

∂12-Sep-88  1102	Common-Lisp-Object-System-mailer 	Fairfax Meeting 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 12 Sep 88  11:01:26 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA10872; Mon, 12 Sep 88 10:58:11 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA15636; Mon, 12 Sep 88 11:01:05 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA00397; Mon, 12 Sep 88 11:00:54 PDT
Message-Id: <8809121800.AA00397@suntana.sun.com>
To: common-lisp-object-system@sail.stanford.edu
Subject: Fairfax Meeting
Date: Mon, 12 Sep 88 11:00:50 PDT
From: kempf@Sun.COM



	Is there any need or plan for a subcommittee meeting?

		jak

∂12-Sep-88  1747	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-DECLARE (version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Sep 88  17:47:38 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458005; Mon 12-Sep-88 20:43:49 EDT
Date: Mon, 12 Sep 88 20:42 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SYMBOL-MACROLET-DECLARE (version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Gregor.pa@Xerox.COM, David N Gray <Gray@DSG.csc.ti.com>, Patrick Dussud <edsel!dussud@labrea.stanford.edu>,
    kempf@Sun.COM, Glenn Andrew Kramer <GAK@SPAR-20.SPAR.SLB.COM>, common-lisp-object-system@SAIL.STANFORD.EDU,
    Jeffrey Piazza <piazza%lisp.DEC@decwrl.dec.com>
In-Reply-To: <19880802205147.3.GREGOR@PORTNOY.parc.xerox.com>,
             <2795614606-3753982@Kelvin>,
             <8808031719.AA12130@rainbow-warrior.lucid.com>,
             <8808031847.AA18770@suntana.sun.com>,
             <2795636967-5097451@Kelvin>,
             <GAK.12419581321.BABYL@SPAR-20.SPAR.SLB.COM>,
             <8808041525.AA20536@suntana.sun.com>,
             <2795711083-4281424@Kelvin>,
             <19880808171852.6.GREGOR@PORTNOY.parc.xerox.com>,
             <8808111506.AA11766@suntana.sun.com>
Message-ID: <19880913004248.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

Issue:         SYMBOL-MACROLET-DECLARE

References:    SYMBOL-MACROLET (88-002R page 2-81)
               WITH-ACCESSORS (88-002R page 2-88)
               WITH-SLOTS (88-002R page 2-92)

Category:      ADDITION

Edit history:  Version 1, 12-Sep-88, Moon

Problem description:

It would be both natural and nice to be able to write

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

Proposal (SYMBOL-MACROLET-DECLARE:ALLOW):
	  
Allow declarations at the head of the body of SYMBOL-MACROLET, and hence
in WITH-ACCESSORS and WITH-SLOTS.  Exactly the same declarations are
allowed as for LET, with one exception: SYMBOL-MACROLET signals an error
if a SPECIAL declaration names one of the symbols being defined as a
symbol-macrolet.  A type declaration of one of these symbols is equivalent
to wrapping a THE expression around the expansion of that symbol.

Test Cases/Examples:

See problem description.

Rationale:

If SYMBOL-MACROLET is intended to resemble LET in syntax, it ought to
allow declarations.  When writing a SYMBOL-MACROLET directly, the user
could just as easily write a THE expression instead of a type
declaration.  However, when invoking a macro such as WITH-SLOTS that
expands into SYMBOL-MACROLET, the user does not have this option since
the expansion is not supplied explicitly by the user.

Current practice:

SYMBOL-MACROLET was only tentatively added to Common Lisp 3 months ago.

Cost to Implementors:

Less than one man-hour.

Cost to Users:

None.

Cost of non-adoption:

Minor wart in the language.

Benefits:

More consistent language definition.

Esthetics:

More consistent language definition.

Discussion:

None.

∂13-Sep-88  0708	Common-Lisp-Object-System-mailer 	RE: Issue: SYMBOL-MACROLET-DECLARE (version 1)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88  07:08:47 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA24481; Tue, 13 Sep 88 07:06:10 PDT
Date: Tue, 13 Sep 88 07:06:10 PDT
Message-Id: <8809131406.AA24481@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
To: Moon@stony-brook.scrc.symbolics.com
Subject: RE: Issue: SYMBOL-MACROLET-DECLARE (version 1)

This seems like a reasonable proposal and does make SYMBOL-MACROLET more
consistent with LET.

This may be a separate issue, but somewhere we should nail down the
interpretation of e.g.

	(symbol-macrolet ((foo bar))
	  ...
	  (locally (declare (special foo))
	    ...foo...))

As currently specified, only a new binding for FOO can turn off its
interpretation as a symbol macro.  I'd like to see some language that said that
a SPECIAL declaration also shadows the symbol macro scope.

The limit case, which your proposal makes "an error", might then reasonably
have a null semantics:

	(symbol-macrolet ((foo bar))
	  (declare (special foo))
	  ...)

might be interpreted as

	(locally (declare (special foo))
	  ...)

I don't have strong feelings one way or the other about this part--it doesn't
seem possible to bring SYMBOL-MACROLET into complete consistency with LET here.

/JEP

∂13-Sep-88  1145	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-DECLARE (version 1)    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Sep 88  11:45:49 PDT
Received: from rainbow-warrior ([192.9.200.16]) by heavens-gate.lucid.com id AA00217g; Tue, 13 Sep 88 10:43:38 PST
Received: by rainbow-warrior id AA03013g; Tue, 13 Sep 88 11:41:59 PDT
Date: Tue, 13 Sep 88 11:41:59 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8809131841.AA03013@rainbow-warrior>
To: piazza%lisp.DEC@decwrl.dec.com
Cc: Moon@stony-brook.scrc.symbolics.com,
        Common-Lisp-Object-System@SAIL.STANFORD.EDU,
        cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: Jeffrey Piazza's message of Tue, 13 Sep 88 07:06:10 PDT <8809131406.AA24481@decwrl.dec.com>
Subject: Issue: SYMBOL-MACROLET-DECLARE (version 1)

   Date: Tue, 13 Sep 88 07:06:10 PDT
   From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)

   This seems like a reasonable proposal and does make SYMBOL-MACROLET more
   consistent with LET.

   This may be a separate issue, but somewhere we should nail down the
   interpretation of e.g.

	   (symbol-macrolet ((foo bar))
	     ...
	     (locally (declare (special foo))
	       ...foo...))

   As currently specified, only a new binding for FOO can turn off its
   interpretation as a symbol macro.  I'd like to see some language that said that
   a SPECIAL declaration also shadows the symbol macro scope.

That seems reasonable.

   The limit case, which your proposal makes "an error", might then reasonably
   have a null semantics:

	   (symbol-macrolet ((foo bar))
	     (declare (special foo))
	     ...)

   might be interpreted as

	   (locally (declare (special foo))
	     ...)

This would be a very bad idea, it would be very inconsistent with LET, and
would introduce a bizarre semantics: Throw away what I just said in the
binding list. I think that it should be an error.

Patrick.




∂14-Sep-88  1817	Common-Lisp-Object-System-mailer 	call-next-method and arguments to :before and :after methods 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88  18:17:25 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA22171; Wed, 14 Sep 88 18:13:51 PDT
Received: from lukasiewicz.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA05670; Wed, 14 Sep 88 18:16:43 PDT
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
	id AA00310; Wed, 14 Sep 88 17:10:07 PDT
Date: Wed, 14 Sep 88 17:10:07 PDT
From: jrose@Sun.COM (John Rose)
Message-Id: <8809150010.AA00310@lukasiewicz.sun.com>
To: halasz%sw.MCC.COM@MCC.COM
Cc: common-lisp-object-system@sail.stanford.edu
In-Reply-To: Frank Halasz's message of Wed, 14 Sep 88 18:48:41 CDT <8809142348.AA11205@oryan.sw.mcc.com>
Subject:  call-next-method and arguments to :before and :after methods

[In response to Frank Halasz's query, I sent him a pointer to the definition of
standard method combination in the manual pages for DEFINE-METHOD-COMBINATION.
Here's the subsequent conversation.  I think the whole exchange may
point up an omission in the CLOS documentation.]

   Date: Wed, 14 Sep 88 18:48:41 CDT
   From: Frank Halasz <halasz%sw.MCC.COM@MCC.COM>

   Thanks, the code under DEFINE-METHOD-COMBINATION helps.  But its still seems
   a bit ambiguous due to the interpretation of the make-method clause
   in call-method.  Specifically, call-method passes on the "arguments that
   were supplied to the effective method form containing the invocation
   of call-method."  The effective method form in the example code boils
   down to the following:

   `(call-method ,(first around)
		 (,@(rest around)
		  (make-method 
		    (multiple-value-prog1
		      (progn ,@(call-methods before)
			     (call-method ,(first primary)
					  ,(rest primary)))
		      ,@(call-methods (reverse after))))))

   The issue is whether the call-method invocations inside the make-method
   are part of the (outer) effective method form.  Alternatively, make-method
   could be considered as bounding a "new" inner effective method form.
   The current PCL effectively takes the latter alternative.  It seems to
   me that the spec takes the former reading, in which case :before and :after
   methods ought to get the arguments passed down to the original call to
   the genric function.

   -- Frank

The "alternative" that CALL-METHODs are lexically scoped to the
innermost MAKE-METHOD seems to be the only viable alternative.
If, as you suggest, scoping were to the outer effective method
body, there would be in fact no way to deliver arguments as adjusted
by CALL-NEXT-METHOD to any method other than those created
implicitly by the system; any method you make with MAKE-METHOD
would be powerless to access the adjusted arguments, because
when it tried to use CALL-METHOD (as it must), the adjusted arguments
would be rebound to their original values.  So what you're suggesting
would probably be a serious design flaw.

While your suggested semantics would be unable to simulate the
current (and historically correct; see next paragraph) semantics,
the reverse is not the case.  In order to simulate your suggested
semantics, say for a special-purpose method combination type,
FLET bindings could be used to capture code at the outer scoping level,
which could then be invoked from a MAKE-METHOD at any level:
	`(flet ((do-before-around ()
	          ,@(call-methods before-around)))
	   (call-method ,(first around)
			(,@(rest around)
			 (make-method
			   (multiple-value-prog1
			     (progn (do-before-around)
				    ...))))))

By the way, I find it totally natural that :AROUND methods surround
primary, :BEFORE, and :AFTER methods, and are thus able to adjust
their actual arguments.  This is the way it worked in Flavors,
which is where this method combination stuff comes from, and
I've never heard anyone question it before.  The grouping is this:
	AROUND( BEFORE PRIMARY AFTER )
rather than this:
	BEFORE AROUND( PRIMARY ) AFTER

(Now, I don't find CLOS standard method combination as a whole very
natural, for larger reasons, and I wish that the Flavors influence
were less strong here, but that's a separate issue.)

It is perhaps a documentation bug that the scoping of CALL-METHOD
is not better spelled out.  Does it really say "arguments that were
supplied to the effective method form containing the invocation
of call-method"?  I can't find any statement one way or the other in my
version of the spec, which is an old version.  I would have expected
words like "innermost effective method or MAKE-METHOD form" instead of
"effective method form".

(This bug report is the reason for the CC to the Powers That Be.)

				-- John

∂15-Sep-88  1304	Common-Lisp-Object-System-mailer 	call-next-method and arguments to :before and :after methods 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Sep 88  13:03:38 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 459910; Thu 15-Sep-88 16:00:52 EDT
Date: Thu, 15 Sep 88 16:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: call-next-method and arguments to :before and :after methods
To: John Rose <jrose@Sun.COM>, halasz%sw.MCC.COM@MCC.COM
cc: common-lisp-object-system@sail.stanford.edu
In-Reply-To: <8809150010.AA00310@lukasiewicz.sun.com>
Message-ID: <19880915200041.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

It's true that when call-next-method was given the ability to change
the arguments, not all of the places in the CLOS specification that
should have been updated were.  Thus some pages don't discuss what
happens in this case.  Page 2-11 of 88-002R (describing call-method)
ought to make it clear that when an invocation of call-method is
nested inside an invocation of make-method, the arguments passed
along by call-method are the arguments that were supplied to the
make-method, not the arguments supplied to the original generic
function call.  Thus call-next-method in a :around method can
alter the arguments seen by :before and :after methods.

I'll send something about this to the Cleanup committee, after
waiting a few days for comments.

∂15-Sep-88  1331	Common-Lisp-Object-System-mailer 	Re: call-next-method and arguments to :before and :after methods  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Sep 88  13:31:35 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 88 13:24:01 PDT
Date: 15 Sep 88 13:23 PDT
From: masinter.pa@Xerox.COM
Subject: Re: call-next-method and arguments to :before and :after methods
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of
 Thu, 15 Sep 88 16:00 EDT
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: John Rose <jrose@Sun.COM>, halasz%sw.MCC.COM@MCC.COM,
 common-lisp-object-system@sail.stanford.edu
Message-ID: <880915-132401-3007@Xerox>

If there are editorial problems in the CLOS specification where some items are
only explained in one place and not in others, I don't think we need to have
full-fledged cleanup issues associated with them. There's some judgement
involved, but the primary motivation for the rather extensive debates we have on
cl-cleanup is to make sure that the issues of costs and benefits-- especially
for incompatible changes-- are fully addressed.

So: I think symbol-macrolet deserves to be debated as a "cleanup", but  if there
is general agreement of the CLOS committee that the document does not reflect
the intent, I think you should just handle them as editorial amendments.


∂20-Sep-88  1817	Common-Lisp-Object-System-mailer 	Re: Issue: SYMBOL-MACROLET-DECLARE (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Sep 88  18:17:10 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 20 SEP 88 18:02:57 PDT
Date: 20 Sep 88 18:02 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SYMBOL-MACROLET-DECLARE (version 1)
In-reply-to: Patrick Dussud <dussud@lucid.com>'s message of Tue, 13 Sep 88
 11:41:59 PDT
To: Patrick Dussud <dussud@lucid.com>
cc: piazza%lisp.DEC@decwrl.dec.com, Moon@stony-brook.scrc.symbolics.com,
 Common-Lisp-Object-System@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <880920-180257-5257@Xerox>

We need to get this cleaned up in time to present to X3J13. 

I think it is at least consistent with LET semantics to say that 

(LOCALLY (DECLARE (SPECIAL X)) ...) introduces a new scope for X. Its consistent
with
(LET((X 4)) (DECLARE (SPECIAL X))
(LET ((X 3))
 (LOCALLY (DECLARE (SPECIAL X)) X)))

returning 4.

I.e., add to the proposal something like:


Clarify that, within a SYMBOL-MACROLET, a nested LOCALLY with a DECLARE SPECIAL
introduces a new scope for the variable(s) declared special, and will override
within its scope any SYMBOL-MACROLET.

∂20-Sep-88  2008	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-DECLARE (version 1)    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Sep 88  20:08:49 PDT
Received: from rainbow-warrior ([192.9.200.16]) by heavens-gate.lucid.com id AA05077g; Tue, 20 Sep 88 19:06:13 PST
Received: by rainbow-warrior id AA19120g; Tue, 20 Sep 88 20:04:34 PDT
Date: Tue, 20 Sep 88 20:04:34 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8809210304.AA19120@rainbow-warrior>
To: masinter.pa@Xerox.COM
Cc: piazza%lisp.DEC@decwrl.dec.com, Moon@stony-brook.scrc.symbolics.com,
        Common-Lisp-Object-System@SAIL.STANFORD.EDU,
        cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 20 Sep 88 18:02 PDT <880920-180257-5257@Xerox>
Subject: Issue: SYMBOL-MACROLET-DECLARE (version 1)

   Date: 20 Sep 88 18:02 PDT
   From: masinter.pa@Xerox.COM

   We need to get this cleaned up in time to present to X3J13. 

   Clarify that, within a SYMBOL-MACROLET, a nested LOCALLY with a DECLARE SPECIAL
   introduces a new scope for the variable(s) declared special, and will override
   within its scope any SYMBOL-MACROLET.

I agree with this. We should also specify that  SPECIAL  shouldn't be used in
the declaration part of a symbol-macrolet. Locally special declaration are
fine. 
Patrick.

∂21-Sep-88  1423	Common-Lisp-Object-System-mailer 	metaobject protocol (description languages)   
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 21 Sep 88  14:23:13 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA06488; Wed, 21 Sep 88 14:18:19 PDT
Received: from lukasiewicz.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA07789; Wed, 21 Sep 88 14:20:58 PDT
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
	id AA15464; Wed, 21 Sep 88 13:14:22 PDT
Date: Wed, 21 Sep 88 13:14:22 PDT
From: jrose@Sun.COM (John Rose)
Message-Id: <8809212014.AA15464@lukasiewicz.sun.com>
To: K311770@AEARN.BITNET
To: Gregor.pa@Xerox.COM, common-lisp-object-system@sail.stanford.edu
In-Reply-To: Hubert Hofbauer's message of Wed, 21 Sep 88 15:29:23 EDT <880921-091549-596@Xerox>
Subject: metaobject protocol (description languages)

   At RISC Linz we are currently evaluating PCL as a basis for our symbolic
   computation library. An important issue in this field are parameterized types
   - families of classes - such as zmod N, polynomial over A-FIELD in VARS,
   matrix DIMS of DOMAIN,... , where N, A-FIELD, VARS, DIMS, and DOMAIN are
   parameters for type zmod, polynomial, and matrix.
   We would like something like (DEFCLASS (ZMOD N) ...) and
   (DEFMETHOD xxx ((Z (ZMOD N))... )... ).

Given the ability to make reasonably general user-definable
specializers, you could fake parametrized types, by putting
the parametrization info into a slot, and defining a specializer
type which dispatched on that slot's value.  Something like this:
	(DEFCLASS ZMOD ((N) ...) ...)
	(DEFDESCRIPTION ZMOD
	    ((N :KEY #'(LAMBDA (X) (SLOT-VALUE X 'N))))
	  (:SUPER (ZMOD)))
	(DEFMETHOD # ((Z (ZMOD N)) ...) ...)

The fictitious DEFDESCRIPTION form would give meaning to specializers
of the form (ZMOD #).  The effect would be to enrich the standard
"description language" of specializers, which consists only of
class names and EQL constructs.  A certain amount of structure
is needed to relate new descriptions to the existing ones;
this has been discussed in previous messages from me.

I believe that many uses of the meta class protocol will center
around the extension of the specializer syntax and semantics
(hence, of the generic function dispatch mechanisms), rather
than around finding new ways to implement slotted structures.

				-- John

∂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  1503	Common-Lisp-Object-System-mailer 	Q about CLOS    
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.Stanford.EDU with TCP; 5 Oct 88  15:03:16 PDT
Received: from DOUGHNUT.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 59461; 5 Oct 88 17:50:52 EDT
Date: Wed, 5 Oct 88 17:52 EDT
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: Q about CLOS
To: common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <19881005215228.4.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

None of the doc I've scrounged for CLOS answers this simple question, so
anyone who can enlighten me, thanks...

is EVAL a generic function (message)?

is APPLY?

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

∂05-Oct-88  1934	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.Stanford.EDU with TCP; 5 Oct 88  19:34:00 PDT
Received: from DOUGHNUT.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 59502; 5 Oct 88 22:21:29 EDT
Date: Wed, 5 Oct 88 22:23 EDT
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: Re: Issue: EVAL-OTHER (Version 2)
To: common-lisp-object-system@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <881005-152958-1624@Xerox>
Message-ID: <19881006022307.0.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

I'd like to propose an alternative (or rather elaboration) to
EVAL-OTHER:SELF-EVALUATE,  currently...

    Proposal (EVAL-OTHER:SELF-EVALUATE):

      Standard data types (those mentioned by CLtL) other than those for which
      a more explicit evaluation rule exists would be defined to self-evaluate.
      Such data types include, for example, structures, arrays, vectors, and
      pathnames.

      Structure types defined by users using DEFSTRUCT should also self-evaluate
      unless an explicit implementation type for the structure is given in the
      DEFSTRUCT, in which case the rule for evaluation of that type should be
      used. (This is important in the case of type LIST.)

I would suggest that the DEFSTRUCT (or DEFFLAVOR) have an option that
explicitly specifies the eval behavior.

Rational:

When using lisp to build an embedded language, one can already define via a
DEFSTRUCT option what the printer for the object should be. One can also,
via character macros define a specific parse behavior. One cannot, however,
currently define an EVAL behavior.  For example, I can define #\[ and #\] to
denote the beginning and end of information for consing a structure FOO via
character macros which will print the same way.

e.g. [A FOO] may really be internally #S(FOO SLOT1: A SLOT2: FOO SLOT3: NIL)

what I may want to define is that (cons [A FOO] [B FOO]) return (A B)
because the EVAL option on foo returned the value of SLOT1.

In general, one could define that instances and structure objects (the
latter are probably instances given CLOS) all handle an EVAL message which
the user can use to explicitly define the behavior. The default handler
returns the object itself, which is compatible with the
EVAL-OTHER:SELF-EVALUATE proposal already made.

Similar arguments to the above can be made for APPLY. The ultimate idea is
that user created objects can be treated as first class objects, just like
symbols.

Comments?

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

∂05-Oct-88  2312	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Oct 88  23:12:15 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 471537; Thu 6-Oct-88 02:10:54 EDT
Date: Thu, 6 Oct 88 02:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: EVAL-OTHER (Version 2)
To: miller@CS.Rochester.EDU
cc: Common-Lisp-Object-System@SAIL.Stanford.EDU,
    CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19881006022307.0.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Message-ID: <881006021043.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Wed, 5 Oct 88 22:23 EDT
    From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>

    ... I would suggest that the DEFSTRUCT (or DEFFLAVOR) have an option that
    explicitly specifies the eval behavior. ...

The problem to this is that it's the same as allowing fexprs.  This is
something we've worked hard to eliminate from CL because it is opaque
to compilation.

You could argue that MACROEXPAND-1 should be a generic function I suppose.
I have no strong feeling on that subject right now, but I'm biased against
it because we are very close to casting this stuff in concrete and I don't
feel totally comfortable that I understand the consequences of doing so.

One minor procedural matter: You're more likely to get this considered if
you write up the proposal in full rather than just as a little fragment.
I count 194 cleanup topics that have been raised, and it's getting harder
and harder to `maintain' them. Some are destined to fall through the cracks
for lack of time and anything that people have a minor bias against can be
very easily pocket-veto'd if it doesn't come in in a form that we can
directly vote on...

∂06-Oct-88  1034	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
Received: from hplms2.hpl.hp.com by SAIL.Stanford.EDU with TCP; 6 Oct 88  10:34:39 PDT
Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Thu, 6 Oct 88 10:30:30 pdt
Received: from loopback by hplwhh.HPL.HP.COM; Thu, 6 Oct 88 10:30:06 pdt
Full-Name: Warren Harris
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>,
        miller@CS.Rochester.EDU
Cc: Common-Lisp-Object-System@SAIL.Stanford.EDU, CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: EVAL-OTHER (Version 2) 
In-Reply-To: Your message of "Thu, 06 Oct 88 02:10:00 EDT."
             <881006021043.8.KMP@BOBOLINK.SCRC.Symbolics.COM> 
Date: Thu, 06 Oct 88 10:30:02 PDT
Message-Id: <8592.592162202@hplwhh>
From: Warren Harris <harris%hplwhh@hplabs.hp.com>

I don't know about making EVAL a generic function due to the ramifications
this has on the compiler, but there are several other places in CL in which
functions should be required to be generic. 

One example might be in the equality area.  Common Lisp seems to have a
wealth of equality predicates, EQ, EQL, EQUAL, EQUALP, =, STRING=, CHAR=
... and you kind of pick and choose based on what you know about the
application.  It would be nice to have at least one version of equality
which did the right thing based on what it was comparing.  Perhaps this is
EQUALP.  EQUALP already looks inside both cons cells and arrays, why not
extend it to look inside objects too.  I suggest the following definition
of EQUALP:

	(defmethod equalp ((x t) (y t))
	  (eq x y))

        (defmethod equalp ((x character) (y character))
	  (char-equal x y))

        (defmethod equalp ((x number) (y number))
	  (= x y))

        (defmethod equalp ((x cons) (y cons))
	  (or (eq x y)
	      (and (equalp (car x) (car y))
		   (equalp (cdr x) (cdr y)))))

        (defmethod equalp ((x object) (y object))
	  (let ((cx (class-of x))
		(cy (class-of y)))
	    (or (eq x y)
		(and (eq cx cy)
		     (every #'(lambda (slotd)
				(let ((name (slotd-name slotd)))
				  (equalp (slot-value-using-class cx
								  x
								  name)
					  (slot-value-using-class cx
								  y
								  name))))
			    (class-slots cx))))))

        (defmethod equalp ((x array) (y array))
	  ...)

COERCE is another good candidate for being made generic.  Like the print
system which is required to go through the PRINT-OBJECT method, COERCE
could ultimately invoke a generic layer:

	(defun coerce (thing type)
	  (case type
	    <old coerce code ...>
	    (t
	     (coerce-object thing (find-class type)))))

	(defmethod coerce-object ((thing t) (c class))
	  (error "~S cannot be coerced to type ~S."
		 thing (class-name c)))

This would allow the user to write class specific coercion routines.  One
objection has been raised to this proposal by Moon:

> But it's meaningful for COERCE's second argument to be a type specifier that
> does not name a class.  CLtL gives as an example (vector (complex short-float)).
> It would be inconsistent to do some coercions with classes and others through
> some other mechanism.  I don't think your idea will work without a larger
> recasting of Common Lisp in object-oriented terms.  While that's an interesting
> project for investigation, I suspect it would quickly go way beyond the
> proper charter of a standardization effort.

I think the above code demonstrates how this can indeed work given CL's
non-class type specifiers.  COERCE itself is not required to be generic, it
is simplied required to ultimately call COERCE-OBJECT.  This is exactly the
requirement placed on PRINT. 

> One minor procedural matter: You're more likely to get this considered if
> you write up the proposal in full rather than just as a little fragment.

How do I do this?  How does it look, and who do I send it to?

Warren Harris
HP Labs

∂06-Oct-88  1156	Common-Lisp-Object-System-mailer 	Re: Q about CLOS
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88  11:56:44 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 11:22:48 PDT
Date: Thu, 6 Oct 88 11:22 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Q about CLOS
To: miller@CS.ROCHESTER.EDU
cc: common-lisp-object-system@SAIL.STANFORD.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <19881005215228.4.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Message-ID: <19881006182238.0.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no

    Date: Wed, 5 Oct 88 17:52 EDT
    From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>

    None of the doc I've scrounged for CLOS answers this simple question, so
    anyone who can enlighten me, thanks...

    is EVAL a generic function (message)?

    is APPLY?

Neither of these is a generic-function.
-------

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

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

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

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

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

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

Asbestos suit on.

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

∂14-Oct-88  1510	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Oct 88  15:10:23 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 14 OCT 88 14:50:43 PDT
Date: 14 Oct 88 14:50 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EVAL-OTHER (Version 2) 
In-reply-to: Brad Miller <miller@CS.ROCHESTER.EDU>'s message of Mon, 10 Oct
 88 16:41 EDT
To: miller@CS.ROCHESTER.EDU
cc: common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <881014-145043-7455@Xerox>

My impression from hearing about current applications of CLOS is that your
assertion "w/o generic EVAL or APPLY, CLOS is just a bag on the side of CL"
is not true.

CLOS claim to integration in CL comes both from the integration of method
invocation with function call and the integration of the class hierarchy
with the previous Common Lisp type hierarchy. Both of those allow for
treating CLOS as the language and CLtL as the previous subset. CLOS and CL
are consistent in treating the type hierarchy as the mechanism of
dispatching on varying forms of behavior, but not relying too heavily on
the function-as-object style which is popular in Scheme.

The notion of making APPLY (or  FUNCALL) generic is possibly quite
interesting, although it implies a different model of "object oriented"
than the one currently embodied in Common Lisp and CLOS.

∂16-Oct-88  1316	Common-Lisp-Object-System-mailer 	CLOS analogue to TYPEP and SUBTYPEP 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Oct 88  13:16:48 PDT
Received: from blacksox ([192.9.201.39]) by LUCID.COM id AA04291g; Sun, 16 Oct 88 13:16:40 PDT
Received: by blacksox id AA00239g; Sun, 16 Oct 88 13:12:45 pdt
Date: Sun, 16 Oct 88 13:12:45 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8810162012.AA00239@blacksox>
To: common-lisp-object-system@sail.stanford.edu
Subject: CLOS analogue to TYPEP and SUBTYPEP

I am looking for a function analogous to TYPEP or SUBTYPEP in CLOS.
Given two class objects, I need to know whether one is a superclass of
the other.  I can't seem to find such a function in Chapter 2.  Have I
missed something, is this relegated to Chapter 3, or is there
something inherently bogus about what I'm trying to do?  It seems like
a rather ordinary thing, not terribly metaclassy.  This came up while
writing a program using CLOS that is intended to be a simple example.

∂16-Oct-88  1545	Common-Lisp-Object-System-mailer 	Re: CLOS analogue to TYPEP and SUBTYPEP  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Oct 88  15:45:20 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 16 OCT 88 15:45:05 PDT
Date: Sun, 16 Oct 88 15:44 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: CLOS analogue to TYPEP and SUBTYPEP
To: Eric Benson <eb@lucid.com>
cc: common-lisp-object-system@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <8810162012.AA00239@blacksox>
Message-ID: <19881016224404.9.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no

    Date: Sun, 16 Oct 88 13:12:45 pdt
    From: Eric Benson <eb@lucid.com>

    I am looking for a function analogous to TYPEP or SUBTYPEP in CLOS.
    Given two class objects, I need to know whether one is a superclass of
    the other.  I can't seem to find such a function in Chapter 2.  Have I
    missed something, is this relegated to Chapter 3, or is there
    something inherently bogus about what I'm trying to do?  It seems like
    a rather ordinary thing, not terribly metaclassy.  This came up while
    writing a program using CLOS that is intended to be a simple example.

According to CLOS, you should be able to pass class objects or class
names to subtypep and typep.  PCL hasn't yet arranged for this to work
for obvious reasons.

I believe there is a function in PCL called sub-class-p or subclassp
which does what you want.  I would check, but that isn't so easy just
now.
-------

∂20-Oct-88  1719	CL-Cleanup-mailer 	Issue: EVAL-OTHER (Version 2)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Oct 88  17:19:53 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA08318g; Thu, 20 Oct 88 17:19:26 PDT
Received: by bhopal id AA06100g; Thu, 20 Oct 88 17:17:51 PDT
Date: Thu, 20 Oct 88 17:17:51 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810210017.AA06100@bhopal>
To: miller@CS.ROCHESTER.EDU
Cc: masinter.pa@XEROX.COM, common-lisp-object-system@SAIL.STANFORD.EDU,
        cl-cleanup@SAIL.STANFORD.EDU, harris%hplwhh@HPLABS.HP.COM
In-Reply-To: Brad Miller's message of Mon, 10 Oct 88 16:41 EDT <19881010204134.1.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Subject: Issue: EVAL-OTHER (Version 2) 

re: w/o generic EVAL or APPLY, CLOS is just a bag on the side of CL. 

I can't agree with this at all.  CL is an extremely useful programming
language, and with CLOS added it is incredibly more  useful.  EVAL
is a boringly obscure operation to apply to any piece of data -- it
merely decodes the syntatic means by which programs are written.  Writing
programs encoded as strings rather than lists and symbols, or encoded in 
*any* other random datatype, is hardly a great step forward.

While that last sentence might be open to continuing theoretical debate,
there is the practical observation that MacLisp/NIL *did* make such an
extension (using the object-oriented system called EXTEND), and there
were virtually no meaningful uses of it.  [I'm not 100% sure but I think
Glenn Burke may have used it somehow in the Layered System Building
project.  Apologies, if that use was "meaningful".]

In fact, the EVAL-related extension that really has some vocal supporters
behind it is to *increase* the level on standardization in the coding of 
EVAL, so that research projects into the likes of debuggers and window 
systems can put more "hooks" into the interpreter.  See Henry Lieberman's
"Common Eval" proposal.


-- JonL --



∂24-Oct-88  1816	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
Received: from PECAN.CS.ROCHESTER.EDU ([192.5.53.206]) by SAIL.Stanford.EDU with TCP; 24 Oct 88  18:16:16 PDT
Received: from DOUGHNUT.CS.ROCHESTER.EDU by PECAN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 4702; Mon 24-Oct-88 21:07:30 EDT
Date: Mon, 24 Oct 88 21:06 EDT
From: Brad Miller <miller@CS.ROCHESTER.EDU>
Subject: Re: Issue: EVAL-OTHER (Version 2) 
To: Jon L White <jonl@LUCID.COM>
cc: masinter.pa@XEROX.COM, common-lisp-object-system@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8810210017.AA06100@bhopal>
Message-ID: <19881025010655.7.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Sender: miller@CS.ROCHESTER.EDU
Reply-To: miller@CS.ROCHESTER.EDU
Organization: University of Rochester, Department of Computer Science
Postal-address: 610 CS Building, Comp Sci Dept., U. Rochester, Rochester NY 14627
Phone: 716-275-1118

    Date: Thu, 20 Oct 88 17:17:51 PDT
    From: Jon L White <jonl@lucid.com>

    re: w/o generic EVAL or APPLY, CLOS is just a bag on the side of CL. 

    I can't agree with this at all.  CL is an extremely useful programming
    language, and with CLOS added it is incredibly more  useful.  EVAL
    is a boringly obscure operation to apply to any piece of data -- it
    merely decodes the syntatic means by which programs are written.  Writing
    programs encoded as strings rather than lists and symbols, or encoded in 
    *any* other random datatype, is hardly a great step forward.

    While that last sentence might be open to continuing theoretical debate,
    there is the practical observation that MacLisp/NIL *did* make such an
    extension (using the object-oriented system called EXTEND), and there
    were virtually no meaningful uses of it.  [I'm not 100% sure but I think
    Glenn Burke may have used it somehow in the Layered System Building
    project.  Apologies, if that use was "meaningful".]

    In fact, the EVAL-related extension that really has some vocal supporters
    behind it is to *increase* the level on standardization in the coding of 
    EVAL, so that research projects into the likes of debuggers and window 
    systems can put more "hooks" into the interpreter.  See Henry Lieberman's
    "Common Eval" proposal.


    -- JonL --

I plan on writing you a response to this, but I'm currently swamped;
just to let you know that my silence isn't agreement. I suspect the
fault was mostly mine: I only gave a trivial example of such use, and
I can give much better ones from my work on the RHET project.

The short cleanup is that while theoretically a full-blown generic
EVAL is "interesting", I certainly *don't* consider it practical. I'm
simply trying to allow the user to specify an eval-function for user
created types, rather than having them always self-eval. Generating
code for these types as (EVAL-YOURSELF <instance>) rather than
<instance> doesn't seem to be a particularly difficult implementation
problem, nor do I think it has a particular bad effect on debuggers.
Appropriate method combination for EVAL-YOURSELF should allow for a
debugger hook (though I've not thought this through carefully).

Thanks for your response.

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

∂31-Oct-88  1843	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 31 Oct 88  18:43:19 PST
Received: from Semillon.ms by ArpaGateway.ms ; 31 OCT 88 11:51:25 PST
Date: 31 Oct 88 11:51 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EVAL-OTHER (Version 2) 
In-reply-to: Brad Miller <miller@CS.ROCHESTER.EDU>'s message of Mon, 24 Oct
 88 21:06 EDT
To: miller@CS.ROCHESTER.EDU
cc: common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <881031-115125-6109@Xerox>

The proposal EVAL-OTHER:SELF-EVALUATE in Issue: EVAL-OTHER (Version 2) was
voted on at the October 1988 X3J13 meeting and accepted. This does not
preclude a subsequent proposal to make the "self-evaluation" of objects be
a standard generic function where only the default method is the identity
function, but might change the wording in which you would couch such a
proposal. If you were to use the "cleanup" committee's proposal format, you
should use a different issue name, e.g., EVAL-GENERIC.

If you (or anyone) wants to see the guidelines for cleanup proposals, let
me know.


∂25-Nov-88  0907	Common-Lisp-Object-System-mailer 	specification request [plain text]  
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 25 Nov 88  09:06:24 PST
Received: from cs.qmc.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa03986; 25 Nov 88 14:47 GMT
Received: from sequent by csvax.cs.qmc.ac.uk id a021929; 25 Nov 88 14:51 GMT
Date:     Fri, 25 Nov 88 14:46:28 WET
From:     Flash Sheridan <flash%cs.qmc.ac.uk@NSS.Cs.Ucl.AC.UK>
To:       common-lisp-object-system <@NSS.Cs.Ucl.AC.UK:common-lisp-object-system@sail.stanford.edu>
cc:       common-lisp-object-system-specification-request <@NSS.Cs.Ucl.AC.UK:common-lisp-object-system-specification-request@sail.stanford.edu>
Subject:  specification request [plain text]
Reply-To: sheridan@NSS.Cs.Ucl.AC.UK
Message-ID:  <8811251448.a025197@sequent.cs.qmc.ac.uk>

I'd like to get an electronic copy of the CLOS spec [including the MetaClass
chapter].  I'd also appreciate any other info.  I'm running AAAI-88 PCL
on Coral Common Lisp.
From: flash@cs.qmc.ac.uk (Flash Sheridan)
Reply-To: sheridan@nss.cs.ucl.ac.uk
Portal,MacNet: FlashsMom

∂15-Dec-88  0935	Common-Lisp-Object-System-mailer 	CLOS lambda-list congruence    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 15 Dec 88  09:35:09 PST
Received: by ti.com id AA15075; Thu, 15 Dec 88 11:33:56 CST
Received: from Kelvin by tilde id AA07810; Thu, 15 Dec 88 11:23:07 CST
Message-Id: <2807198566-13859327@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 15 Dec 88  11:22:46 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Common-Lisp-Object-System@SAIL.Stanford.edu
Subject: CLOS lambda-list congruence

I have a question for the CLOS gurus; I hope this is the appropriate
mailing list.

In testing a program we are writing for automatically translating source
code from Flavors to CLOS, I found that by far the biggest problem with
the automatically translated code is non-congruence of method
parameters.  When writing flavors, I often had a method with parameters
like
  (a b &optional x y)
but would then write a :BEFORE or :AFTER method with parameters like
  (a b &rest ignore)
which worked fine with flavors, but CLOS considers these lambda lists to
not be equivalent.  Can someone explain why this particular restriction
is necessary?

Although the above example is merely a nuisance, a more troubling case
is a method which translates to: 

(DEFMETHOD PRINT-DESCRIPTION ((SELF TRANSPORTER) &REST ARGS)
  (WITH-SLOTS (POSITION) SELF
    (APPLY #'PRINT-DESCRIPTION POSITION ARGS))) 

Here I don't want to enumerate the optional arguments because I want to
let the function (or in this case, method) being called do the
defaulting.  I don't see why the implementation couldn't permit this.

∂15-Dec-88  0953	Common-Lisp-Object-System-mailer 	Re: CLOS lambda-list congruence     
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 15 Dec 88  09:53:10 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA12937; Thu, 15 Dec 88 09:55:06 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA01535; Thu, 15 Dec 88 09:51:41 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA07455; Thu, 15 Dec 88 09:52:16 PST
Message-Id: <8812151752.AA07455@suntana.sun.com>
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu
Subject: Re: CLOS lambda-list congruence 
In-Reply-To: Your message of Thu, 15 Dec 88 11:22:46 -0600.
             <2807198566-13859327@Kelvin> 
Date: Thu, 15 Dec 88 09:52:13 PST
From: kempf@Sun.COM


The lambda list congruence rules are designed to re-enforce the generic
function as an interface mechanism. In this design, the lambda list
is the interface to a distributed implementation, namely the methods.
The congruence rules match the generic function interface to the
implementation. This is a fundamentally different design from old Flavors 
(but similar to new Flavors, see Moon's paper in the 1986 OOPSLA Proceedings). 
Therefore, a simple syntactic transformation may be insufficient to handle
the translation.

I ran into a similar problem doing CommonObjects on CommonLoops. CommonObjects
allows methods defined on different classes to have the same name but 
differing lambda lists. In CommonObjects, methods are defined on classes
as in old Flavors or Smalltalk, so classes form individual namespaces
for methods. This is semantically distinct from generic functions, where
the package system is used to form namespaces.

If you want to preserve the old semantics, and alternative is to implement
your own generic function type using the metaobject protocol, which 
relaxes the restriction on lambda list congruence. 

		jak

∂15-Dec-88  1117	Common-Lisp-Object-System-mailer 	Re: CLOS lambda-list congruence     
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Dec 88  11:17:32 PST
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 509134; 15 Dec 88 14:15:31 EST
Date: Thu, 15 Dec 88 14:19 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: CLOS lambda-list congruence 
To: kempf@Sun.COM
cc: David N Gray <Gray@DSG.csc.ti.com>, Common-Lisp-Object-System@SAIL.Stanford.edu
In-Reply-To: <8812151752.AA07455@suntana.sun.com>
Message-ID: <19881215191956.1.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>

    Date: Thu, 15 Dec 88 09:52:13 PST
    From: kempf@Sun.COM

    This is a fundamentally different design from old Flavors 
    (but similar to new Flavors, see Moon's paper in the 1986 OOPSLA Proceedings). 

Just to set the record straight, the lambda list congruence rules in CLOS
are not based on New Flavors.  They are a new design that as far as I
know was not previously implemented.  I think they are correct, though.

It's true that there are legitimate applications for relaxing these
rules to require only that the number of required arguments be equal,
and making a new class of method would be one good way to do that.
Another possibility would be to invent an implementation-dependent
decoration of the lambda-list and an extension of the congruence rules
implemented by the standard classes of generic function and method
to take that decoration into account.

∂15-Dec-88  1119	Common-Lisp-Object-System-mailer 	Re: CLOS lambda-list congruence     
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 15 Dec 88  11:19:47 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA15046; Thu, 15 Dec 88 11:21:26 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA05899; Thu, 15 Dec 88 11:17:36 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA07629; Thu, 15 Dec 88 11:17:58 PST
Message-Id: <8812151917.AA07629@suntana.sun.com>
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: kempf@Sun.COM, David N Gray <Gray@DSG.csc.ti.com>,
        Common-Lisp-Object-System@SAIL.Stanford.edu
Subject: Re: CLOS lambda-list congruence 
In-Reply-To: Your message of Thu, 15 Dec 88 14:19:00 -0500.
             <19881215191956.1.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> 
Date: Thu, 15 Dec 88 11:17:52 PST
From: kempf@Sun.COM


>Just to set the record straight, the lambda list congruence rules in CLOS
>are not based on New Flavors.  They are a new design that as far as I

I stand corrected. Thank you.

		jak

∂16-Dec-88  1505	Common-Lisp-Object-System-mailer 	Re: CLOS lambda-list congruence     
Received: from ti.com by SAIL.Stanford.EDU with TCP; 16 Dec 88  15:05:36 PST
Received: by ti.com id AA20847; Fri, 16 Dec 88 17:04:19 CST
Received: from Kelvin by tilde id AA10157; Fri, 16 Dec 88 16:52:03 CST
Message-Id: <2807304730-3722733@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 16 Dec 88  16:52:10 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: kempf@Sun.COM
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu
Subject: Re: CLOS lambda-list congruence 
In-Reply-To: Msg of Thu, 15 Dec 88 09:52:13 PST from kempf@Sun.COM

> The lambda list congruence rules are designed to re-enforce the generic
> function as an interface mechanism. In this design, the lambda list
> is the interface to a distributed implementation, namely the methods.
> The congruence rules match the generic function interface to the
> implementation.

OK, but I don't see how the examples I cited are inconsistent with this
philosophy.

> If you want to preserve the old semantics, and alternative is to implement
> your own generic function type using the metaobject protocol, which 
> relaxes the restriction on lambda list congruence. 

Looking at document 88-003, I can't find any provision for being
able to do that.  Is that a new feature in the forthcoming draft?

∂16-Dec-88  1618	Common-Lisp-Object-System-mailer 	Re: CLOS lambda-list congruence     
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 16 Dec 88  16:18:02 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA04559; Fri, 16 Dec 88 16:20:08 PST
Received: from suntana.sun.com ([129.144.42.122]) by snail.Sun.COM (4.1/SMI-4.0)
	id AA21443; Fri, 16 Dec 88 15:35:33 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA10428; Fri, 16 Dec 88 15:34:37 PST
Message-Id: <8812162334.AA10428@suntana.sun.com>
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: kempf@Sun.COM, Common-Lisp-Object-System@SAIL.Stanford.edu
Subject: Re: CLOS lambda-list congruence 
In-Reply-To: Your message of Fri, 16 Dec 88 16:52:10 -0600.
             <2807304730-3722733@Kelvin> 
Date: Fri, 16 Dec 88 15:34:31 PST
From: kempf@Sun.COM


>Looking at document 88-003, I can't find any provision for being
>able to do that.  Is that a new feature in the forthcoming draft?


As I have not yet received a copy of 88-003, I can't say.

		jak


∂28-Dec-88  1700	Common-Lisp-Object-System-mailer 	Suggestion Sent to CommonLoops List 
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Dec 88  16:58:42 PST
Received: from hplabs.HP.COM by SCORE.STANFORD.EDU with TCP; Wed 28 Dec 88 16:57:45-PST
Received: from hpldew.HP.COM ([15.255.32.26]) by hplabs.HP.COM with SMTP ; Wed, 28 Dec 88 16:58:05 PST
Received: from hpldew by hpldew.HP.COM; Wed, 28 Dec 88 16:57:12 pst
Return-Path: <wallace@hpldew>
Message-Id: <8812290057.AA15755@hpldew.HP.COM>
To: Common-Lisp-Object-System%Sail.Stanford.edu%hplabs@hplabs.HP.COM
Subject: Suggestion Sent to CommonLoops List
Date: Wed, 28 Dec 88 16:57:10 PST
From: David E. Wallace <wallace@hpldew>

Last week I sent a design suggestion about being able to find "non-applicable"
methods to the CommonLoops list, since I couldn't find the name of this
list.  I assume that everyone on this list also reads the CommonLoops list
and so has seen my note - if this isn't true, let me know and I'll repost it.

Dave Wallace

∂29-Dec-88  0500	Common-Lisp-Object-System-mailer 	Compilation implications  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Dec 88  04:54:06 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00911g; Thu, 29 Dec 88 04:50:36 PST
Received: by bhopal id AA10083g; Thu, 29 Dec 88 04:52:47 PST
Date: Thu, 29 Dec 88 04:52:47 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812291252.AA10083@bhopal>
To: Common-Lisp-Object-System@Sail.Stanford.edu
Cc: CL-Compiler@Sail.Stanford.edu
Subject: Compilation implications

This somewhat long msg has questions aobut two issues in it:
    (A) "Reconstructor" functions for instances
    (B) References to classes "by name"
Partly I would like an answer to them to aid in development at Lucid,
and partly to help resolve lingering issues in the CL-Compiler's work
on quoted constants.


              (A) "Reconstructor" functions for instances

We at Lucid are getting more and more requests for a coherent "Reconstructor"
protocol (well, they are usually couched in ill-advised terms about making
FASLOUT user-extensible, but we've already seen this issue before).  Does 
anyone have any plans to work on this problem?  Didn't someone recently
say that Symbolics has some possibly-private Reconstructor capability?
What is the feeling about the Symbolics facility  (I don't know anything
about it).

One might ask, "How do ``instances'' come to the attention of FASLOUT?"
They can appear as a quoted constant; hence, Cris Perdue's query:
    Date: Mon, 14 Nov 88 11:54:29 PST
    From: cperdue@Sun.COM (Cris Perdue)
    To: cl-object-oriented-programming@sail.stanford.edu
    Subject: Standard-objects in quoted constants
to which Moon replied later that day about the need for a reconstructor
protocol.  I should think it rare for quoted instances to appear directly
in code files.  But there are some important exceptions that, indirectly,
introduce "constants" into a file; for example, the use of #. to emulate 
a FASDMP facility; and also macro-generated code that produces otherwise
unREADable forms.  If the semantics of DEFCONSTANT were more "hard-wired",
then it too would be such an exception.  ["hard-wired" means that the value
at run time is that obtained by evaluating the defconstant form at compile 
time, rather than by evaluating the form at load time; it would mean that
(defconstant foo (bar)) is similar to (defconstant foo (quote #.(bar))).]


Possibly, EQL specializers could raise this question.  Upon re-reading, 
the language of 88-002R now seems a bit vague to me, and possibly open 
to misinterpretation, as to just when an EQL parameter specializer form 
is evaluated.  Consider the similarity with DEFCONSTANT.  The language 
in CLtL about DEFCONSTANT seems to imply, to most people, that the runtime 
environment ought to have a special variable that holds the "constant" 
value  (references to which are allowed to be "snapped" in compiled code);
and that the value of this variable is set at load time, when the defining 
form's "form" is evaluated, just like it would be for defparameter.  [Hence 
DEFCONSTANT doesn't define a compile-time constant in the same way that 
conventional language compilers do.]  The various implementations I've 
looked at so far seem to do it this way -- they do an evaluation at load 
time (typically, by executing a "thunk") to produce the constant's value. 

The language of 88-002R doesn't seem to rule out either way of obtaining 
the "object"-- producing a thunk or producing a compile-time constant.
The only relevant difference is that it prescribed the evaluation to be 
done in the lexical environment of the defining form, which for 
COMPILE-FILE simply means that the "thunk" is compiled in that lexical 
environment.  But has anyone wanted the more "hardwired" version?



             (B) References to classes "by name"

The analogy between FIND-PACKAGE and FIND-CLASS suggests that class 
objects are in the same "database" category as packages.  Shouldn't
they be referenced "by name" in compiled file?   Lucid has been fasl'ing 
out packages for some time merely "by reference"; the culmination of the 
CL-Compiler's deliberations on "quoted constants in compiled files" seems 
to be that this is the only reasonable meaning for reference to a "quoted
package".  Are there any other implementations that do otherwise for
"quoted" classes?  

I realize this may pose some ordering constraints on the executions in a 
file, if the compiled version is to operate correctly -- i.e., classes might
have to be defined before the use of any constant that "names" that class.  
Such constraints may not be as feasible as they are in the package world 
(Indeed, some folks even dislike the package ordering constraints!).  Can 
a forward-reference, "placeholder" be substituted for a class that hasn't
yet been defined, but is referenced by a quoted constant?



-- JonL --

∂29-Dec-88  1001	Common-Lisp-Object-System-mailer 	Compilation implications  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Dec 88  10:01:43 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513111; Thu 29-Dec-88 12:59:40 EST
Date: Thu, 29 Dec 88 12:59 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Compilation implications
To: Jon L White <jonl@lucid.com>
cc: Common-Lisp-Object-System@Sail.Stanford.edu, CL-Compiler@Sail.Stanford.edu
In-Reply-To: <8812291252.AA10083@bhopal>
Message-ID: <19881229175913.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

[Responding to only one portion of your message]

    Date: Thu, 29 Dec 88 04:52:47 PST
    From: Jon L White <jonl@lucid.com>

		  (A) "Reconstructor" functions for instances

    We at Lucid are getting more and more requests for a coherent "Reconstructor"
    protocol (well, they are usually couched in ill-advised terms about making
    FASLOUT user-extensible, but we've already seen this issue before).  Does 
    anyone have any plans to work on this problem?  Didn't someone recently
    say that Symbolics has some possibly-private Reconstructor capability?
    What is the feeling about the Symbolics facility  (I don't know anything
    about it).

It's very simple and effective.  There is a generic function (never mind its
name, the current stupid name was chosen about a dozen years ago) that is
applied to one argument and returns a Lisp form.  The intent is that when
that form is evaluated at some later time, it should return an object that
is equivalent to the argument.  Using EVAL provides full generality.  Of
course the compiler/fasdumper/fasloader is allowed to optimize special-case
forms that it recognizes, rather than always calling EVAL at load time.
This generic function is supported for standard-object and structure-object
(using CLOS terminology).  A good name would be MAKE-RECONSTRUCTION-FORM or
perhaps MAKE-LOAD-FORM (why introduce a new word "reconstruct" when we
already have the word "load" which really means the same thing?).

In addition, there is a level of protocol built on top of this that some
things use.  There is a mixin flavor that provides a method for the
first generic function; it returns a form that calls MAKE-INSTANCE with
(TYPE-OF SELF) as the first argument, and the remaining arguments
obtained by calling another generic function whose methods' results are
usually combined with APPEND.  This provides a convenient way for
multiple classes to contribute to the reconstruction of an object;
each class supplies the initargs that are relevant to that class.
I'd suggest MAKE-LOAD-INITARGS for the name of this generic function
and LOAD-USING-INITARGS-MIXIN for the name of the class.  I haven't put
a great deal of thought into these names.

There is also a method that uses the simple-minded reconstruction
technique of just looking at the slots that have :INITARGs and calling
MAKE-INSTANCE with the reconstructed values of those slots.

An important thing to realize is that the default for a standard-object
is to signal an error; there is no default method on standard-object
for either of these generic functions.  That's important because no
default reconstruction method can be correct for all objects, and we
feel it's better to make the programmer pick a method explicitly than
to supply a default that might just make trouble.

I don't remember why the CLOS committee didn't put anything like this
into the proposed standard.  Maybe we thought it was the Compiler
committee's business, maybe we had some disagreement, or maybe we
just ran out of time.

    One might ask, "How do ``instances'' come to the attention of FASLOUT?"
    They can appear as a quoted constant; hence, Cris Perdue's query:
	Date: Mon, 14 Nov 88 11:54:29 PST
	From: cperdue@Sun.COM (Cris Perdue)
	To: cl-object-oriented-programming@sail.stanford.edu
	Subject: Standard-objects in quoted constants
    to which Moon replied later that day about the need for a reconstructor
    protocol.  I should think it rare for quoted instances to appear directly
    in code files.  But there are some important exceptions that, indirectly,
    introduce "constants" into a file; for example, the use of #. to emulate 
    a FASDMP facility; and also macro-generated code that produces otherwise
    unREADable forms.

Rare, but not unheard of.  Note also two other common sources of non-built-in
type objects in compiled-code files:  1. Any type that has a read syntax is
likely to appear as a quoted constant or inside a quoted constant.  Pathnames
are one example, user programs often define others.  2. Symbolics has a
facility for creating a compiled-code file full of data (rather than compiled
Lisp programs), which is convenient because it's an efficient binary file
that you can load with LOAD instead of having to write your own loader.
(This can be simulated in any Common Lisp implementation by creating a dummy
file that consists of just one call to a special macro, defining the macro
to expand into forms to put the data where you want it, then using COMPILE-FILE
on that dummy file).

Most of the rest of your message concerns the metaobject protocol and I can't
answer it.  I'll just note that in Flavors we generate metaobjects at compile
time, but we never put them (to speak loosely) into the compiled-code file;
instead macros like DEFFLAVOR and DEFMETHOD expand into Lisp code that obtains
new metaobjects at load time, based on the class name and generic function name.
I don't see how any other way could work, actually, since two distinct compiled
files that refer to a class by the same name must end up referring to the
same metaobject after loading.  In Flavors we don't have anonymous classes nor
anonymous generic functions, so we don't have to solve those issues.

∂30-Dec-88  0400	CL-Compiler-mailer 	Compilation implications 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 30 Dec 88  03:48:39 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01516g; Fri, 30 Dec 88 03:44:28 PST
Received: by bhopal id AA13748g; Fri, 30 Dec 88 03:46:40 PST
Date: Fri, 30 Dec 88 03:46:40 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812301146.AA13748@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: Common-Lisp-Object-System@Sail.Stanford.edu, CL-Compiler@Sail.Stanford.edu
In-Reply-To: David A. Moon's message of Thu, 29 Dec 88 12:59 EST <19881229175913.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Compilation implications

Thanks for your many comments, Dave.  I'm sure they will be useful.

re: ["Reconstructor" forms and mixins]
    I don't remember why the CLOS committee didn't put anything like this
    into the proposed standard.  Maybe we thought it was the Compiler
    committee's business, maybe we had some disagreement, or maybe we
    just ran out of time.

There is a blend of problems here -- partly object-oriented and partly
semantics of compilation.  It could be that the buck is getting shuffled
back and forth and nothing being done.  Maybe the time just wasn't ripe
for specifying this protocol -- maybe more experience is needed --  but
sooner or later the user-community will be "push coming to shove" and 
the lack of a portable interface could be damaging.


re: [fasling out classes "by name"]
    I don't see how any other way could work, actually, since two distinct 
    compiled files that refer to a class by the same name must end up 
    referring to the same metaobject after loading.  

Right.  Separate compilation seems to be the clinching argument.


-- JonL --

∂30-Dec-88  1128	CL-Compiler-mailer 	Re: Compilation implications  
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 30 Dec 88  11:28:17 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA17613; Fri, 30 Dec 88 11:30:11 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA28437; Fri, 30 Dec 88 11:26:52 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA09230; Fri, 30 Dec 88 11:27:29 PST
Message-Id: <8812301927.AA09230@suntana.sun.com>
To: Jon L White <jonl@lucid.com>
Cc: Common-Lisp-Object-System@Sail.Stanford.edu, CL-Compiler@Sail.Stanford.edu,
        cperdue%suntana@Sun.COM
Subject: Re: Compilation implications 
In-Reply-To: Your message of Thu, 29 Dec 88 04:52:47 -0800.
             <8812291252.AA10083@bhopal> 
Date: Fri, 30 Dec 88 11:27:27 PST
From: kempf@Sun.COM


A couple comments on the original and Moon's followup.

1) I proposed as a strawman awhile back that a read macro be introduced
similar to #S for DEFSTRUCTSs so that CLOS objects could be stored in
readable ASCII form and also so that they could be made persistent. 
There was some discussion on the issue but it eventually died out without
a proposal.

2) I think Moon's solution of a constructor form which gets executed using
EVAL at load time is the only possible solution to this problem. In particular,
the semantics of quoted constants implied by CLtL is that only symbols can
be expected to be EQ across a FASDUMP, and only characters and numbers can
additionally be expected to be EQL. This has interesting implications 
for EQL specializers. Since the only objects which can be 
expected to survive a FASDUMP and remain EQL are symbols, 
numbers, and characters, these are the
only objects which make sense to have in a DEFMETHOD form with an EQL
specialized parameter. This makes it important that machinery
be available to add methods to a generic function through a functional
interface, since some of the things one wants to do with EQL methods require
other objects. Part of that machinery is already in Chapter 2 
(ADD-METHOD, MAKE-INSTANCE) but part of it is not 
(how to make a method function, for example). 

3) With regard to using name equivalence for classes across FASDUMP, again,
I largely agree with Moon on this issue, however I'll take the liberty of
extending his comment somewhat, since I think that slot structure needs
to be taken into account. The problem is basically one of how to handle
class or type equivalence of two CLOS objects in FASL files. When the
two objects are FASLed back in, when will their classes be the same? 
Because of the restrictions on EQ and EQL, the class objects, themselves,
cannot be FASLed out because they are not guaranteed to be EQL when 
FASLed back in. This solution is impractical in any case, since it implies
FASLing out the entire metaobject structure at compile time just to save
a single object. Also, name equivalence only (i.e. the names of the
classes are the same) may not be sufficient, because the number and names of
slots might be changed, and, in order to FASL the object in, there must
be at least as many slots as their were when it was FASLed out. Having
the same slot names is probably also necessary, since it allows a logical
mapping between the slot contents in the FASL file and the object in memory,
as well as the physical constraint of having enough slots to handle the
slot contents. Note that, again, EQLness of slot descriptor objects, or
any other solution not involving symbols won't work. Requiring the same
class precedence list, or that the inheritance of slots match strikes
me as too restrictive, though I could see arguments why it would be desirable.
Alternatively, the class redefinition protocol could be put to good use to 
allow the object to redefine its class if the number and names of slots didn't
match. In that case, name equivalence of classes is the only requirement.
Note that this solution handles anonymous classes fine, but not instances
of anonymous classes. In particular, two instances of the same anonymous
class which are FASLed out then in cannot ever have a class object which is EQ
or EQL, since the FASL in code will create two separate instances of the 
anonymous class. The only way around this problem is to either change the
semantics of EQ and EQL for CLOS objects or to treat CLOS classes separately
during FASDUMP. Using class and slot name equivalence or just class name
equivalence with the redefinition protocol coming into play when there is
a mismatch between the slot structures seems like an easier solution.

				jak

∂30-Dec-88  2008	CL-Compiler-mailer 	Compilation implications 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 30 Dec 88  20:08:34 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02064g; Fri, 30 Dec 88 20:05:01 PST
Received: by bhopal id AA16126g; Fri, 30 Dec 88 20:07:12 PST
Date: Fri, 30 Dec 88 20:07:12 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812310407.AA16126@bhopal>
To: kempf@Sun.COM
Cc: Common-Lisp-Object-System@Sail.Stanford.edu, CL-Compiler@Sail.Stanford.edu,
        cperdue%suntana@Sun.COM
In-Reply-To: kempf@Sun.COM's message of Fri, 30 Dec 88 11:27:27 PST <8812301927.AA09230@suntana.sun.com>
Subject: Compilation implications 

I'll address only the comments you have under item (3).

re:  name equivalence only (i.e. the names of the
    classes are the same) may not be sufficient, because the number and names 
    of slots might be changed, and, in order to FASL the object in, there must
    be at least as many slots as their were when it was FASLed out. Having
    the same slot names is probably also necessary, since it allows a logical
    mapping between the slot contents in the FASL file and the object in 
    memory, as well as the physical constraint of having enough slots to 
    handle the slot contents. 

Well, at load time you could just assuming that a compile-time reference 
to a class named FOO is not inconsistent with the class named FOO existing 
at load time. [I was more worried about forward references in the compiled 
file, that weren't "forward" when the compile-time environment was built -- 
happens e.g. when you load things out of order].

Part of what you are suggesting could be compared, by analogy, to the
package case.  Lucid currently only dumps the name reference; but you
are saying for example that it could also dump the names of all "used" 
packages just as a consistency check.  Unfortunately, I don't see how 
to evaluate the myriads of consistency checks that could conceivable be 
placed in a "dumped" class; would they be worth the effort?


re: In particular, two instances of the same anonymous
    class which are FASLed out then in cannot ever have a class object which 
    is EQ or EQL, since the FASL in code will create two separate instances 
    of the  anonymous class. 

This is not a problem in Lucid Common Lisp [by the bye, I'm assuming a 
single COMPILE-FILE -- I'm not talking about the problem of separate file 
compilations]  LCL file-compilation arranges to preserve EQLness over the 
data objects in a single compile-file.

At one time, some implementations didn't even preserve EQLness over
uninternd gensyms (over a single compile-file); but PCL dependended
so heavily on this working, that those implementations at least made
that case work.


-- JonL --

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

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

Issue:         LOAD-OBJECTS

References:    none

Related issues: none

Category:      ADDITION

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

Problem description:

  Common Lisp doesn't provide any way to use an object of a user-defined
  type (defined with DEFCLASS or DEFSTRUCT) as a constant in a program
  compiled with COMPILE-FILE.  The problem is that LOAD has to be able
  to "reconstruct" an equivalent object when the compiled-code file is
  loaded, but the programmer has no way to tell LOAD how to do that.

Proposal (LOAD-OBJECTS:MAKE-LOAD-FORM):
          
  Define a new generic function named MAKE-LOAD-FORM, which takes one
  argument and returns one value.  The value is a form which, when
  evaluated at some later time, should return an object that is
  equivalent to the argument.  The exact meaning of "equivalent"
  depends on the type of object and is up to the programmer who
  defines a method for MAKE-LOAD-FORM.

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

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

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

Example:

  (defclass my-class ()
     ((a :initarg :a :reader my-a)
      (b :initarg :b :reader my-b)
      (c :accessor my-c)))
  (defmethod shared-initialize ((self my-class) ignore &rest ignore)
    (unless (slot-boundp self 'c)
      (setf (my-c self) (some-computation (my-a self) (my-b self)))))
  (defmethod make-load-form ((self my-class))
    `(make-instance ',(class-name (class-of self))
                    :a ',(my-a self) :b ',(my-b self)))

  In this example, an equivalent instance of my-class is reconstructed
  by using the values of two of its slots.  The value of the third slot
  is derived from those two values.

  (defclass my-frob ()
     ((name :initarg :name :reader my-name)))
  (defmethod make-load-form ((self my-frob))
    `(find-my-frob ',(my-name self) :if-does-not-exist :create))

  In this example, instances of my-frob are "interned" in some way.
  An equivalent instance is reconstructed by using the value of the
  name slot as a key for searching existing objects.  In this case
  the programmer has chosen to create a new object if no existing
  object is found; alternatively she could have chosen to signal an
  error in that case.

Rationale:

  Only the programmer who designed a class can know the correct
  way to reconstruct objects of that class at load time, therefore
  the reconstruction should be controlled by a generic function.
  Using EVAL as the interface for telling LOAD what to do provides
  full generality.

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

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

Current practice:

  Symbolics Flavors has something like this, but under a different name.
  The name Symbolics uses is not suitable for standardization.

  JonL reports that Lucid is getting more and more requests for this.

Cost to Implementors:

  This seems like only a few one-line changes in the compiled-code
  file writer and reader.

Cost to Users:

  None.

Cost of non-adoption:

  Serious impairment of the ability to use extended-type objects.  Each
  implementation will probably make up its own version of this as an
  extension.

Performance impact:

  None.

Benefits:

  See Cost of non-adoption.

Esthetics:

  No significant positive or negative impact.

Discussion:

  It would be possible to define an additional level of protocol that
  allows multiple classes to contribute to the reconstruction of an
  object, combining initialization arguments contributed by each class.
  Since a user can easily define that in terms of MAKE-LOAD-FORM without
  modifying the Lisp system, it is not being proposed now.

  Any type that has a read syntax is likely to appear as a quoted
  constant or inside a quoted constant.  Pathnames are one example, user
  programs often define others.  Also many implementations provide a way
  to create a compiled-code file full of data (rather than compiled Lisp
  programs), and such data probably include extended-type objects.

  Moon supports this.

∂03-Jan-89  0932	CL-Compiler-mailer 	Re: Compilation implications  
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 3 Jan 89  09:32:02 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA25364; Tue, 3 Jan 89 09:33:49 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA00274; Tue, 3 Jan 89 09:30:28 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA11579; Tue, 3 Jan 89 09:31:04 PST
Message-Id: <8901031731.AA11579@suntana.sun.com>
To: Jon L White <jonl@lucid.com>
Cc: kempf@Sun.COM, Common-Lisp-Object-System@Sail.Stanford.edu,
        CL-Compiler@Sail.Stanford.edu, cperdue%suntana@Sun.COM
Subject: Re: Compilation implications 
In-Reply-To: Your message of Fri, 30 Dec 88 20:07:12 -0800.
             <8812310407.AA16126@bhopal> 
Date: Tue, 03 Jan 89 09:31:00 PST
From: kempf@Sun.COM


>packages just as a consistency check.  Unfortunately, I don't see how 
>to evaluate the myriads of consistency checks that could conceivable be 
>placed in a "dumped" class; would they be worth the effort?

The class redefinition protocol is probably the right way to go here.
If there is a difference between the instance structure in the file
and in memory, it could be called to update the instance.

>This is not a problem in Lucid Common Lisp [by the bye, I'm assuming a 
>single COMPILE-FILE -- I'm not talking about the problem of separate file 

Sorry, I should have said "in a portable way." There are some Lisps
(maybe all of them now) which maintain EQLness over FASL for things
other than characters, symbols, and numbers. But the language spec 
in CLtL doesn't require it.

			jak

∂03-Jan-89  0959	Common-Lisp-Object-System-mailer 	Re: Compilation implications   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Jan 89  09:59:35 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 514403; Tue 3-Jan-89 12:57:30 EST
Date: Tue, 3 Jan 89 12:56 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Compilation implications 
To: kempf@Sun.COM
cc: Jon L White <jonl@lucid.com>, Common-Lisp-Object-System@Sail.Stanford.edu,
    CL-Compiler@Sail.Stanford.edu, cperdue%suntana@Sun.COM
In-Reply-To: <8901031731.AA11579@suntana.sun.com>
Message-ID: <19890103175655.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 03 Jan 89 09:31:00 PST
    From: kempf@Sun.COM

    >packages just as a consistency check.  Unfortunately, I don't see how 
    >to evaluate the myriads of consistency checks that could conceivable be 
    >placed in a "dumped" class; would they be worth the effort?

    The class redefinition protocol is probably the right way to go here.
    If there is a difference between the instance structure in the file
    and in memory, it could be called to update the instance.

I thought you said you agreed with my proposal that the way to load an
instance of a standard-class from a compiled file is for a method of the
instance to return a form which is then evaluated at load time.  Once
this is adopted, there is no such thing as "the instance structure in
the file" and no issue of making that structure consistent with some
other structure.  The semantics of loading an instance of a standard-class
from a compiled file can be entirely understood in terms of MAKE-INSTANCE
or whatever other function is called by the form returned by MAKE-LOAD-FORM;
no new concepts need be introduced.  If the programmer of a given class
wants to use the class redefinition protocol, that class's MAKE-LOAD-FORM
method can output something that uses that protocol, and if he doesn't,
it can output something that doesn't.

∂03-Jan-89  1838	CL-Compiler-mailer 	Re: Compilation implications  
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 3 Jan 89  18:38:08 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA01222; Tue, 3 Jan 89 18:39:10 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA23845; Tue, 3 Jan 89 18:35:50 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA11798; Tue, 3 Jan 89 18:36:27 PST
Message-Id: <8901040236.AA11798@suntana.sun.com>
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: kempf@Sun.COM, Jon L White <jonl@lucid.com>,
        Common-Lisp-Object-System@Sail.Stanford.edu,
        CL-Compiler@Sail.Stanford.edu, cperdue%suntana@Sun.COM
Subject: Re: Compilation implications 
In-Reply-To: Your message of Tue, 03 Jan 89 12:56:00 -0500.
             <19890103175655.8.MOON@EUPHRATES.SCRC.Symbolics.COM> 
Date: Tue, 03 Jan 89 18:36:24 PST
From: kempf@Sun.COM


>thought you said you agreed with my proposal that the way to load an
>instance of a standard-class from a compiled file is for a method of the
>instance to return a form which is then evaluated at load time.  Once
>this is adopted, there is no such thing as "the instance structure in
>the file" and no issue of making that structure consistent with some
>other structure.  The semantics of loading an instance of a standard-class

Right. In general, this will be the case, but remember that your proposal
leaves open a programmer hook which may, in specific instances, require
the class redefinition protocol to be run. However, they will probably
be rare, so we can disregard them for now.

			jak

∂05-Jan-89  1005	CL-Compiler-mailer 	Re: Compilation implications  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 5 Jan 89  10:05:06 PST
Received: by ti.com id AA27755; Thu, 5 Jan 89 12:03:51 CST
Received: from Kelvin by tilde id AA05297; Thu, 5 Jan 89 11:49:50 CST
Message-Id: <2809014625-3421425@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 5 Jan 89  11:50:25 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@lucid.com>
Cc: Common-Lisp-Object-System@Sail.Stanford.edu, CL-Compiler@Sail.Stanford.edu
Subject: Re: Compilation implications
In-Reply-To: Msg of Thu, 29 Dec 88 04:52:47 PST from Jon L White <jonl@lucid.com>

>               (A) "Reconstructor" functions for instances

I've been giving this a little thought.  I have modified our compiler to
call the generic function RECONSTRUCTION-FORM when it needs to dump an
object that is not one of the primitive types it knows how to handle
directly.  It takes the object as its argument and returns a form to be
evaluated to reconstruct the object (or else you get a "no applicable
method" error).  With that hook, it then becomes possible to define a
general-purpose object dumper in portable CLOS code, which I hereby donate
to the public domain:

(defclass fasdump-mixin () ()
  (:documentation "Including this class allows instances to be dumped to object files."))
(defmacro push-key-and-value (key value list)
  `(setf ,list (list* ,key ,value ,list)))
(defmethod reconstruction-form ((object fasdump-mixin))
  (let ((plist '())
	(class-name (type-of object))
	(unbound-slots '())
	(allocation-args '()))
    (dolist (slot (class-slots (class-of object)))
      (let ((name (slot-description-name slot)))
	(when (eq (slot-description-allocation slot) ':instance)
	  (if (slot-boundp object name)
	      (push-key-and-value name (slot-value object name) plist)
	    (push name unbound-slots)))))
    (if (and (null unbound-slots) (null allocation-args))
	`(remake-object ',class-name ',plist)
      `(remake-object ',class-name ',plist ',unbound-slots ',allocation-args))))

(defun remake-object (class-name &optional slots-and-values unbound-slots allocation-args)
  (let* ((class1 (find-class class-name))
	 (object (progn (unless (class-finalized-p class1)
			  (finalize-inheritance class1))
			(apply #'allocate-instance class1 allocation-args)))
	 (class (class-of object))
	 (deleted-slots '())
	 (plist '())
	 (added-slots '())
	 (default '#,(cons nil nil)))
    (do ((tail slots-and-values (cddr tail)))
	((atom tail))
      (let ((slot-name (first tail)))
	(if (slot-exists-p-using-class class object slot-name)
	    (setf (slot-value-using-class class object slot-name)
		  (second tail))
	  (progn (push slot-name deleted-slots)
		 (push-key-and-value slot-name (second tail) plist)))))
    (dolist (slot (class-slots class))
      (let ((slot-name (slot-description-name slot)))
	(when (and (eq (slot-description-allocation slot) ':instance)
		   (eq (getf slots-and-values slot-name default) default)
		   (not (member slot-name unbound-slots :test #'eq)))
	    (push slot-name added-slots))))
    (when (or deleted-slots added-slots)
      (update-instance-for-redefined-class object added-slots deleted-slots plist))
    object))

Note that this does not require the slots to have initargs, and note the
use of UPDATE-INSTANCE-FOR-REDEFINED-CLASS at the end to take account of
any changes in the class definition between compilation and loading.  If
any slot values are themselves class instances, then the compiler will
invoke RECONSTRUCTION-FORM on them in the process of writing out the form
returned by the first call.

While this works, I don't think this is an ideal solution because it
doesn't handle the case of recursive data structures.  A better solution
might be something along the lines of having the generic function return
four values:
  1. The class name.
  2. A list of additional arguments for ALLOCATE-INSTANCE.
  3. The name of an initialization function.
  4. Initialization arguments.
The loader would then first do 
  (APPLY #'ALLOCATE-INSTANCE (FIND-CLASS class-name) other-allocate-args)
to create the object before it begins reading the next two items, and then
finally do 
  (APPLY (SYMBOL-FUNCTION init-function) the-object initialization-args)
to fill in the slots.


> Possibly, EQL specializers could raise this question.  Upon re-reading, 
> the language of 88-002R now seems a bit vague to me, and possibly open 
> to misinterpretation, as to just when an EQL parameter specializer form 
> is evaluated.

Yes, I ran into this when I wrote a method that looked something like
this:  
 (DEFMETHOD MAKE-INSTANCE ((CLASS (EQL (FIND-CLASS 'MY-CLASS))) ...) ...)
which wouldn't work without doing something like this:

(defmethod reconstruction-form ((object class))
  (let ((class-name (class-name object)))
    (if (and (symbolp class-name)
	     (eq (find-class class-name nil) object))
	`(find-class ',class-name)
      (error "Can't dump ~S to object file because it doesn't have a proper name." object))))

but I'm not sure if this is what the designers of CLOS had in mind.


>              (B) References to classes "by name"
> 
> The analogy between FIND-PACKAGE and FIND-CLASS suggests that class 
> objects are in the same "database" category as packages.  Shouldn't
> they be referenced "by name" in compiled file? 

That sounds right to me.

> I realize this may pose some ordering constraints on the executions in a 
> file, if the compiled version is to operate correctly -- i.e., classes might
> have to be defined before the use of any constant that "names" that class.  
> Such constraints may not be as feasible as they are in the package world 
> (Indeed, some folks even dislike the package ordering constraints!).  Can 
> a forward-reference, "placeholder" be substituted for a class that hasn't
> yet been defined, but is referenced by a quoted constant?

We ran into this problem where we optimize calls to TYPEP to specialized
code using the class object, which might not be defined yet when the code
is loaded, so at that point the loader constructs a dummy class definition
and trusts it to be redefined correctly later.  So far, that seems to be
working ok, but, again, I'm not sure if that is really considered proper.

∂05-Jan-89  1336	Common-Lisp-Object-System-mailer 	Re: Compilation implications   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Jan 89  13:35:47 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 516094; Thu 5-Jan-89 16:32:43 EST
Date: Thu, 5 Jan 89 16:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Compilation implications
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Jon L White <jonl@lucid.com>, Common-Lisp-Object-System@Sail.Stanford.edu,
    CL-Compiler@Sail.Stanford.edu
In-Reply-To: <2809014625-3421425@Kelvin>
Message-ID: <19890105213202.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 5 Jan 89  11:50:25 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    > Possibly, EQL specializers could raise this question.  Upon re-reading, 
    > the language of 88-002R now seems a bit vague to me, and possibly open 
    > to misinterpretation, as to just when an EQL parameter specializer form 
    > is evaluated.

    Yes, I ran into this when I wrote a method that looked something like
    this:  
     (DEFMETHOD MAKE-INSTANCE ((CLASS (EQL (FIND-CLASS 'MY-CLASS))) ...) ...)
    which wouldn't work without doing something like this:

    (defmethod reconstruction-form ((object class))
      (let ((class-name (class-name object)))
	(if (and (symbolp class-name)
		 (eq (find-class class-name nil) object))
	    `(find-class ',class-name)
	  (error "Can't dump ~S to object file because it doesn't have a proper name." object))))

    but I'm not sure if this is what the designers of CLOS had in mind.

The macroexpansion of defmethod must be wrong.  The form inside the EQL
parameter specializer name should be evaluated at load time, not at
compile time.  That's my opinion anyway; 88-002R doesn't say as far as
I can see.

∂05-Jan-89  1342	Common-Lisp-Object-System-mailer 	Re: Compilation implications   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Jan 89  13:42:11 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 516101; Thu 5-Jan-89 16:39:43 EST
Date: Thu, 5 Jan 89 16:39 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Compilation implications
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Jon L White <jonl@lucid.com>, Common-Lisp-Object-System@Sail.Stanford.edu,
    CL-Compiler@Sail.Stanford.edu
In-Reply-To: <2809014625-3421425@Kelvin>
Message-ID: <19890105213908.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 5 Jan 89  11:50:25 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    (defclass fasdump-mixin ....

    While this works, 

For classes where simply saving the values of the slots is enough to save
all relevant state of the object, and where simply restoring equivalent
values into the slots and not calling make-instance, initialize-instance,
nor shared-initialize is enough to create an equivalent object.  Such
classes do exist, so this is worth telling people how to do so they can
use it with such classes.

		      I don't think this is an ideal solution because it
    doesn't handle the case of recursive data structures.  A better solution
    might be something along the lines of having the generic function return
    four values:
      1. The class name.
      2. A list of additional arguments for ALLOCATE-INSTANCE.
      3. The name of an initialization function.
      4. Initialization arguments.
    The loader would then first do 
      (APPLY #'ALLOCATE-INSTANCE (FIND-CLASS class-name) other-allocate-args)
    to create the object before it begins reading the next two items, and then
    finally do 
      (APPLY (SYMBOL-FUNCTION init-function) the-object initialization-args)
    to fill in the slots.

You can make your REMAKE-OBJECT technique do this without modifying the loader
(you have to put in a special variable that allows you to detect recursive
calls).  Or did you want to do the final step at some later time than when
the outermost in a set of nested objects is created?  I don't think deferring
the final step until the end of loading the file would work in many cases.

∂05-Jan-89  1451	CL-Compiler-mailer 	Re: Compilation implications  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 5 Jan 89  14:50:58 PST
Received: by ti.com id AA29024; Thu, 5 Jan 89 16:49:03 CST
Received: from Kelvin by tilde id AA11935; Thu, 5 Jan 89 16:40:27 CST
Message-Id: <2809032076-4469910@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 5 Jan 89  16:41:16 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Jon L White <jonl@lucid.com>, Common-Lisp-Object-System@Sail.Stanford.edu,
        CL-Compiler@Sail.Stanford.edu
Subject: Re: Compilation implications
In-Reply-To: Msg of Thu, 5 Jan 89 16:39 EST from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

> You can make your REMAKE-OBJECT technique do this without modifying the loader
> (you have to put in a special variable that allows you to detect recursive
> calls).

The problem with the approach of reading one form and then evaluating it
is that the slot values have already been read and constructed before
allocating the object they go in.  I suppose it would be possible to add
special handling for recursive references that would maintain a list of
these so that the loader can go back and fill them in later, but the
approach of allocating the object before reading its contents is much
simpler.  That's what we already do for lists and arrays.

∂05-Jan-89  1547	Common-Lisp-Object-System-mailer 	Re: Compilation implications   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Jan 89  15:47:11 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 516198; Thu 5-Jan-89 18:44:15 EST
Date: Thu, 5 Jan 89 18:43 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Compilation implications
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Jon L White <jonl@lucid.com>, Common-Lisp-Object-System@Sail.Stanford.edu,
    CL-Compiler@Sail.Stanford.edu
In-Reply-To: <2809032076-4469910@Kelvin>
Message-ID: <19890105234343.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 5 Jan 89  16:41:16 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    > You can make your REMAKE-OBJECT technique do this without modifying the loader
    > (you have to put in a special variable that allows you to detect recursive
    > calls).

    The problem with the approach of reading one form and then evaluating it
    is that the slot values have already been read and constructed before
    allocating the object they go in.  I suppose it would be possible to add
    special handling for recursive references that would maintain a list of
    these so that the loader can go back and fill them in later, but the
    approach of allocating the object before reading its contents is much
    simpler.  That's what we already do for lists and arrays.

Apparently my message wasn't clear.  What I meant to say was that you can
make the form returned by your MAKE-LOAD-FORM method do just that, allocate
the object and then fill in its contents.  Then you can detect nested
objects and move all the allocation forms to the front.

Oh, I'm sorry.  This all depends on the assumption that when the form is
(PROGN form1 form2), the loader evaluates form1 before reading form2.  I
had not realized that that might not be true of all loaders.  Should we
make special-case treatment of PROGN a requirement?

Probably it would be a better idea for MAKE-LOAD-FORM to return two
values, where the first value is a form that will create the object and
the second value is a form that will further initialize the object?
This way the order of evaluation requirement is more explicit.  It's
upward compatible since the second value can be NIL if you don't need
it.  Also this gives the opportunity to communicate between the forms
without using a special variable; suppose we plug the object returned by
the first form into the second form and do (schematically):

   ;; This part happens at compile time
   (MULTIPLE-VALUE-BIND (form1.1 form1.2)
       (MAKE-LOAD-FORM object1)
     (MULTIPLE-VALUE-BIND (form2.1 form2.2)
         (MAKE-LOAD-FORM object2)
       
       ;; This part happens at load time
       (LET ((x1 (EVAL form1.1))
             (x2 (EVAL form2.1)))
         (WHEN form1.2
           (EVAL (APPEND form1.2 (LIST (LIST 'QUOTE x1)))))
         (WHEN form2.2
           (EVAL (APPEND form2.2 (LIST (LIST 'QUOTE x2))))))))

Should I evolve the proposal I sent out the other day along these lines?

It's still the case that only the programmer of the class knows whether
this is an appropriate protocol, so it has to be under the control of the
programmer, not built-in.  Consider, for example, any class whose objects
are interned.  Calling ALLOCATE-INSTANCE unconditionally is not going to
work.  That's why I prefer to see an interface in terms of forms rather
than in terms of functions, since forms are the simplest way to do
something that is completely general.

∂05-Jan-89  1721	CL-Compiler-mailer 	Re: Compilation implications  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 5 Jan 89  17:20:51 PST
Received: by ti.com id AA29934; Thu, 5 Jan 89 19:19:00 CST
Received: from Kelvin by tilde id AA15060; Thu, 5 Jan 89 19:05:11 CST
Message-Id: <2809040762-4991819@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 5 Jan 89  19:06:02 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Jon L White <jonl@lucid.com>, Common-Lisp-Object-System@Sail.Stanford.edu,
        CL-Compiler@Sail.Stanford.edu
Subject: Re: Compilation implications
In-Reply-To: Msg of Thu, 5 Jan 89 18:43 EST from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

> Probably it would be a better idea for MAKE-LOAD-FORM to return two
> values, where the first value is a form that will create the object and
> the second value is a form that will further initialize the object?
> This way the order of evaluation requirement is more explicit.  It's
> upward compatible since the second value can be NIL if you don't need
> it. 

Yes, that sounds good except for the problem of how to pass the object to
the second form.

>  ...  suppose we plug the object returned by
> the first form into the second form and do (schematically):
...
>          (WHEN form1.2
>            (EVAL (APPEND form1.2 (LIST (LIST 'QUOTE x1)))))
...

This reduces generality because the second form can't use optional
arguments, and it seems a little strange to say that the second value is a
form minus its last argument.  I wonder if it wouldn't look nicer to just
designate a variable name to indicate where the object is to be plugged in?

For example, we might do:

  (defmethod make-load-form ((object my-class))
    (values `(allocate-mine ...)
            `(init-mine * ...)))

where it is understood that the loader will bind * to the result of the
first form while evaluating the second.  This follows the convention that
* is the result of the previous evaluation, so doesn't introduce a new
name to remember.  Now that I think about it, I like this better than my
previous 4-value suggestion.

> Should I evolve the proposal I sent out the other day along these lines?

Yes, I would like to see that.

∂06-Jan-89  0033	Common-Lisp-Object-System-mailer 	Compilation implications  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Jan 89  00:33:36 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA06806g; Fri, 6 Jan 89 00:29:23 PST
Received: by bhopal id AA07509g; Fri, 6 Jan 89 00:31:37 PST
Date: Fri, 6 Jan 89 00:31:37 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901060831.AA07509@bhopal>
To: Gray@DSG.csc.ti.com
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM,
        Common-Lisp-Object-System@Sail.Stanford.edu
In-Reply-To: David N Gray's message of Thu, 5 Jan 89  11:50:25 CST <2809014625-3421425@Kelvin>
Subject: Compilation implications

And thanks to you too, David, for putting some time into this.
[Note that I've dropped cl-compiler off the cc list.]

Some Questions.

-- Your code for the 'reconstruction-form' method never adds anything 
   to the 'allocation-args' -- did you excise some TI-specific parts? 
   or what is this ever supposed to be besides nil?

-- What is 'finalize-inheritance'?  is it to fix up "stubs" that had
   been created as "placeholder" classes merely so that some type
   dispatch could make reference to the class?

-- Why do you use 'slot-exists-p-using-class' instead of 'slot-exists-p'?
   The class argument you are passing in for 'object' is simply the 
   value obtained from (class-of object) anyway?

-- When you ran into some trouble with  the form:

    (DEFMETHOD MAKE-INSTANCE ((CLASS (EQL (FIND-CLASS 'MY-CLASS))) ...) ...)

   was it because your DEFMETHOD treats this form essentially the same as

    (DEFMETHOD MAKE-INSTANCE ((CLASS (EQL '#.(FIND-CLASS 'MY-CLASS))) ...) ...)

   Does your macro expander for DEFMETHOD call EVAL to get the object,
   rather than returning a form to be evaluated later?


I agree with you very much that the reasonable way to handle potentially
circular data is to allocate an object first (and "register" it in the 
corresponding compiler or binary-loader table) and _then_ create the 
several components.  As Moon points out, there may be some classes of
objects for which this componentwise protocol is unsatisfactory -- 
objects which must, for example, be "massaged" after creation by one or
the other initialization protocol (or both).  For these, circularities 
could be an intractable problem; but for classes for which the fasdmp-
mixin is suitable, there should be no problem.  I hope it's true that 
the vast majority of cases can be handled by fasdmp-mixin.



-- JonL --

∂06-Jan-89  0936	Common-Lisp-Object-System-mailer 	Re: Compilation implications   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 6 Jan 89  09:36:05 PST
Received: by ti.com id AA02335; Fri, 6 Jan 89 11:34:06 CST
Received: from Kelvin by tilde id AA00655; Fri, 6 Jan 89 11:16:52 CST
Message-Id: <2809099069-8494933@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 6 Jan 89  11:17:49 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@lucid.com>
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM,
        Common-Lisp-Object-System@Sail.Stanford.edu
Subject: Re: Compilation implications
In-Reply-To: Msg of Fri, 6 Jan 89 00:31:37 PST from Jon L White <jonl@lucid.com>

> -- Your code for the 'reconstruction-form' method never adds anything 
>    to the 'allocation-args' -- did you excise some TI-specific parts? 
>    or what is this ever supposed to be besides nil?

My version uses an implementation-dependent argument for the memory area;
I omitted that from the portable version I mailed out.

> -- What is 'finalize-inheritance'?  is it to fix up "stubs" that had
>    been created as "placeholder" classes merely so that some type
>    dispatch could make reference to the class?

It's defined in CLOS chapter 3; my intent was to perform any bookkeeping
needed if the class had not been instantiated before (such as computing
the class precedence list and effective slot list).  I haven't yet had a
chance to study the December edition of chapter 3 to make sure that's the
right way to do it.

> -- Why do you use 'slot-exists-p-using-class' instead of 'slot-exists-p'?
>    The class argument you are passing in for 'object' is simply the 
>    value obtained from (class-of object) anyway?

For efficiency -- since I already have the class object, I might as well
call SLOT-EXISTS-P-USING-CLASS directly instead of having SLOT-EXISTS-P do
it.  This has the effect of moving the call to CLASS-OF outside the loop.

> -- When you ran into some trouble with  the form:
> 
>     (DEFMETHOD MAKE-INSTANCE ((CLASS (EQL (FIND-CLASS 'MY-CLASS))) ...) ...)
> 
>    was it because your DEFMETHOD treats this form essentially the same as
> 
>     (DEFMETHOD MAKE-INSTANCE ((CLASS (EQL '#.(FIND-CLASS 'MY-CLASS))) ...) ...)
> 
>    Does your macro expander for DEFMETHOD call EVAL to get the object,
>    rather than returning a form to be evaluated later?

Yes, the evaluation is being done at macro expansion time.  If that's not
right, I'll need to change it.

∂06-Jan-89  1520	Common-Lisp-Object-System-mailer 	Compilation implications  
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  15:18:46 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA27087; Fri, 6 Jan 89 15:19:58 PST
Received: from lukasiewicz.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA07702; Fri, 6 Jan 89 15:16:36 PST
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
	id AA00547; Fri, 6 Jan 89 15:19:04 PST
Date: Fri, 6 Jan 89 15:19:04 PST
From: jrose@Sun.COM (John Rose)
Message-Id: <8901062319.AA00547@lukasiewicz.sun.com>
To: jonl@lucid.com
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM,
        Common-Lisp-Object-System@Sail.Stanford.edu,
        CL-Compiler@Sail.Stanford.edu
In-Reply-To: Jon L White's message of Fri, 30 Dec 88 03:46:40 PST <8812301146.AA13748@bhopal>
Subject: Compilation implications

   Date: Fri, 30 Dec 88 03:46:40 PST
   From: Jon L White <jonl@lucid.com>

   Thanks for your many comments, Dave.  I'm sure they will be useful.

   re: ["Reconstructor" forms and mixins]
       I don't remember why the CLOS committee didn't put anything like this
       into the proposed standard.  Maybe we thought it was the Compiler
       committee's business, maybe we had some disagreement, or maybe we
       just ran out of time.

   There is a blend of problems here -- partly object-oriented and partly
   semantics of compilation.  It could be that the buck is getting shuffled
   back and forth and nothing being done.  Maybe the time just wasn't ripe
   for specifying this protocol -- maybe more experience is needed --  but
   sooner or later the user-community will be "push coming to shove" and 
   the lack of a portable interface could be damaging.


   re: [fasling out classes "by name"]
       I don't see how any other way could work, actually, since two distinct 
       compiled files that refer to a class by the same name must end up 
       referring to the same metaobject after loading.  

   Right.  Separate compilation seems to be the clinching argument.

Wait.  Fasling out classes by name is not always the right thing
to do, and any institutionalization of JonL's and Moon's comments
will probably be a mistake.

In recent proposals, fasl-ing out of classes is not specially addressed
by the proposed STANDARD-OBJECT fasdumping protocol, so it's not so
important that we get this ironed out immediately.  Still, I think the
following points need to be made:

1. If anything like a "mixin manager" is being used to create classes
   on the fly, such classes should be dumped not as names, but as
   mixture specifications, perhaps lists of names.

2. In general, dynamic class creation may result in classes which
   are nameless, have gensyms for names, or have names which do not
   fully reflect their nature (such as the mixins of #1).  Yet such
   classes may well have a sensible meaning which is independent
   of the current Lisp instance, and which can be transported across
   load boundaries; such classes need a way to encode this meaning
   in a non-symbol form.

2a. An interesting example of dynamic class creation which shows up less
    in dynamically typed languages is the construction of parametrized
    types.  After instantiating a PT, you compile its methods (or
    whatever you call the code is associated with it) with formal type
    parameters filled in with actuals.  This means that the methods can
    be efficiently compiled for the PT instantiation, using any extra
    information that the actual type parameters give.  For example,
    "stack of character" can use character arrays internally, while
    "stack of bit" can use bit arrays.  These considerations apply
    to any language with PTs.  Some languages can't even begin to
    compile a PT unless it's fully instantiated.

    In Lisp, you can program generic stacks using T-arrays, but at a
    loss of storage efficiency if you're going to use them for bits.
    One solution is to supply a FOO-STACK type for every
    implementationally significant sequence element type FOO.  A better
    solution is to define a class-valued function which takes the
    element type as a parameter, and finds or creates a CLOS class with
    the appropriate efficient code and data structures.  So PTs can have
    a place in CLOS, and give another example where symbols don't work
    well as class names.

    Even better than a class-valued function would be the ability to
    give parameters to class names, just as DEFTYPE names accept
    parameters.  I hope the Meta Object Protocol can be used to do
    this.  In that case, something like '(STACK CHARACTER) might
    make a good fasdumpable class name.

3. This point is concerned less with fasloading from files, but shows
   another way that simple symbols are insufficient to refer to classes.

   An acid test of an object-oriented system is whether objects of
   new classes can be introduced into a running system without breaking it,
   and can take participate in existing protocols.  Often, such
   objects of new class are introduced by loading new modules into
   Lisp, so we can assume that whenever an object is loaded, its class
   is loaded too.

   But what if an object enters a Lisp system alone, perhaps in the
   process of IPC, or from an OODB, and it has a class not seen before?
   It may then be desirable not only for the class to have a name, but
   some indication of where its definition is to be sought, so that it
   may be loaded.  Such autoloading of classes would be necessary in
   systems featuring transfer of objects between Lisps and a large or
   growing space of classes.

So, be careful!  Mere symbols make good class names only for systems of
limited size, and a fixed class population.

   -- JonL --

				-- John

∂06-Jan-89  1539	Common-Lisp-Object-System-mailer 	Compilation implications  
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  15:38:27 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA27525; Fri, 6 Jan 89 15:40:07 PST
Received: from lukasiewicz.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA08599; Fri, 6 Jan 89 15:36:42 PST
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
	id AA00581; Fri, 6 Jan 89 15:39:08 PST
Date: Fri, 6 Jan 89 15:39:08 PST
From: jrose@Sun.COM (John Rose)
Message-Id: <8901062339.AA00581@lukasiewicz.sun.com>
To: kempf@Sun.COM
Cc: jonl@lucid.com, Common-Lisp-Object-System@Sail.Stanford.edu,
        CL-Compiler@Sail.Stanford.edu, cperdue%suntana@Sun.COM
In-Reply-To: kempf@sun.com's message of Fri, 30 Dec 88 11:27:27 PST <8812301927.AA09230@suntana.sun.com>
Subject: Compilation implications 

   Date: Fri, 30 Dec 88 11:27:27 PST
   From: kempf@sun.com


   A couple comments on the original and Moon's followup.

  ...

   2) I think Moon's solution of a constructor form which gets executed using
   EVAL at load time is the only possible solution to this problem. In particular,
   the semantics of quoted constants implied by CLtL is that only symbols can
   be expected to be EQ across a FASDUMP, and only characters and numbers can
   additionally be expected to be EQL. This has interesting implications 
   for EQL specializers. Since the only objects which can be 
   expected to survive a FASDUMP and remain EQL are symbols, 
   numbers, and characters, these are the
   only objects which make sense to have in a DEFMETHOD form with an EQL

That's only true for non-CLOS types.  I'm quite pleased that Moon's
solution allows the programmer to define new STANDARD-OBJEcT types
which, like symbols, characters, and numbers, preserve EQL-ness across
dumps.  (For example, two Symbolics pathnames are EQL iff they have
equivalent components, thus allowing them to be compared efficiently
and to have well-defined property lists.)  This is done by having
a object being fasloaded into a Lisp "look around" in the Lisp for
a pre-existing "equivalent" object, and, if it's found, return that
pre-existing object's reference.  The definition of "look around"
and "equivalent" is type-dependent, but the technique is general.
(For symbols, "look around" is FIND-SYMBOL and "equivalent" is
"same print name and package".)

You might call any such type an "EQL-preserving" or "interning" type.

So, EQL specializers can usefully apply to symbols, numbers, characters,
and selected STANDARD-OBJECT classes.  Interestingly, STANDARD-CLASS
must be EQL-preserving, since the MAKE-INSTANCE protocol relies on
EQL specializers which point to all the classes.

In my previous message, I argued that mere symbols are not always sufficient
for class names.  In the terms of present message, this means that the
implementation of the interning behavior of classes cannot be simply
"dump the class name symbol, and do a FIND-CLASS when loading".  In fact,
it may be necessary on occasion to create the class on the fly, when
the name is first seen, just as symbols are created when first seen.

   specialized parameter. This makes it important that machinery
   be available to add methods to a generic function through a functional
   interface, since some of the things one wants to do with EQL methods require
   other objects. Part of that machinery is already in Chapter 2 
   (ADD-METHOD, MAKE-INSTANCE) but part of it is not 
   (how to make a method function, for example). 

These are important points too.  But it seems to me that method
definition is essentially an "off-line" activity, like compilation.  Or
do the CLOS people envision fast dispatch __and__ fast generic function
redefinition?  I assume that fast dispatch is being paid for partly by
heavy crunching at generic function definition time.  Or is it all in
the cache action?

  ...
				   jak

					-- John

∂06-Jan-89  2109	Common-Lisp-Object-System-mailer 	Compilation implications  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Jan 89  21:07:56 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 516877; Sat 7-Jan-89 00:06:25 EST
Date: Sat, 7 Jan 89 00:05 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Compilation implications 
To: John Rose <jrose@Sun.COM>
cc: kempf@Sun.COM, jonl@lucid.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU,
    CL-Compiler@SAIL.STANFORD.EDU, cperdue%suntana@Sun.COM
In-Reply-To: <8901062339.AA00581@lukasiewicz.sun.com>
Message-ID: <19890107050551.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 6 Jan 89 15:39:08 PST
    From: jrose@Sun.COM (John Rose)

    So, EQL specializers can usefully apply to symbols, numbers, characters,
    and selected STANDARD-OBJECT classes.  Interestingly, STANDARD-CLASS
    must be EQL-preserving, since the MAKE-INSTANCE protocol relies on
    EQL specializers which point to all the classes.

As I pointed out in an earlier message, translation of parameter specializer
names to parameter specializers occurs at load time, not at compile time.
Thus the available space of EQL specializers is not affected by the behavior
of COMPILE-FILE and LOAD.

Now you understand why CLOS uses (EQL <form>) where CommonLoops used
(QUOTE <object>). 

    In my previous message, I argued that mere symbols are not always sufficient
    for class names.  In the terms of present message, this means that the
    implementation of the interning behavior of classes cannot be simply
    "dump the class name symbol, and do a FIND-CLASS when loading".  In fact,
    it may be necessary on occasion to create the class on the fly, when
    the name is first seen, just as symbols are created when first seen.

As far as I know, nothing in CLOS, not even in metaobjects, requires the
ability to dump classes with COMPILE-FILE and load them with LOAD.  The
programmer writing a particular MAKE-LOAD-FORM method might indeed
implement the behavior you describe, or some other behavior, for their
particular class, but I don't think the core CLOS language requires
this.

       specialized parameter. This makes it important that machinery
       be available to add methods to a generic function through a functional
       interface, since some of the things one wants to do with EQL methods require
       other objects. Part of that machinery is already in Chapter 2 
       (ADD-METHOD, MAKE-INSTANCE) but part of it is not 
       (how to make a method function, for example). 

This is chapter 3 (metaobject) business.  It's probably just an accident
that a few bits of it leaked into chapter 2.

    These are important points too.  But it seems to me that method
    definition is essentially an "off-line" activity, like compilation.  Or
    do the CLOS people envision fast dispatch __and__ fast generic function
    redefinition?  I assume that fast dispatch is being paid for partly by
    heavy crunching at generic function definition time.  Or is it all in
    the cache action?

CLOS is a language, not an implementation.  The CLOS language does not
specify the speed of particular operations.  That's a matter for
implementations to decide based on their own tradeoffs.

∂06-Jan-89  2207	Common-Lisp-Object-System-mailer 	Re: Compilation implications   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Jan 89  22:07:07 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 516917; Sat 7-Jan-89 01:04:36 EST
Date: Sat, 7 Jan 89 01:04 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Compilation implications
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Jon L White <jonl@lucid.com>, Common-Lisp-Object-System@SAIL.STANFORD.EDU,
    CL-Compiler@SAIL.STANFORD.EDU
In-Reply-To: <2809040762-4991819@Kelvin>
Message-ID: <19890107060409.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 5 Jan 89  19:06:02 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    > Probably it would be a better idea for MAKE-LOAD-FORM to return two
    > values, where the first value is a form that will create the object and
    > the second value is a form that will further initialize the object?
    > This way the order of evaluation requirement is more explicit.  It's
    > upward compatible since the second value can be NIL if you don't need
    > it. 

    Yes, that sounds good except for the problem of how to pass the object to
    the second form.

    >  ...  suppose we plug the object returned by
    > the first form into the second form and do (schematically):
    ...
    >          (WHEN form1.2
    >            (EVAL (APPEND form1.2 (LIST (LIST 'QUOTE x1)))))
    ...

    This reduces generality because the second form can't use optional
    arguments, and it seems a little strange to say that the second value is a
    form minus its last argument.  

What I had in mind was ((LAMBDA (object) ...code...)).  But I like your
suggestion of evaluating the form in an environment where * is bound to the
object better.  Other people should check me on this, it might just be that
you appealed to my sense of hackish kludgery.

It would be nicer if we could just use a function, but the last proposal I
saw for what you could use as constants in COMPILE-FILE said you could not
use functions.  We could use a LAMBDA expression, I suppose.

    > Should I evolve the proposal I sent out the other day along these lines?

    Yes, I would like to see that.

I'll update it based on all the received comments as early as I can next week.

∂06-Jan-89  2246	CL-Compiler-mailer 	Compilation implications 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Jan 89  22:45:28 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate id AA08230g; Fri, 6 Jan 89 22:40:51 PST
Received: by bhopal id AA02511g; Fri, 6 Jan 89 22:43:05 PST
Date: Fri, 6 Jan 89 22:43:05 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901070643.AA02511@bhopal>
To: Gray@DSG.csc.ti.com
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, jrose@Sun.COM,
        Common-Lisp-Object-System@Sail.Stanford.edu,
        Cl-compiler@Sail.Stanford.edu
In-Reply-To: David N Gray's message of Fri, 6 Jan 89  11:17:49 CST <2809099069-8494933@Kelvin>
Subject: Compilation implications

re: [CLOS Chapter 3 stuff]

Hmm, well maybe portable code won't want to be using that just yet.


re: >    Does your macro expander for DEFMETHOD call EVAL to get the object,
    >    rather than returning a form to be evaluated later?

    Yes, the evaluation is being done at macro expansion time.  If that's not
    right, I'll need to change it.

A few things weigh against the evaluation being done at macroexpansion time:

  -- Lucid's DEFSTRUCT implementation does some of the work of the
     defstruct definition at macro-expansion time, and the rest at
     the subsequent evaluation time (when that macro-expanded form
     is finally evaluated).  This has caused numerous headaches, such
     as in trying to fully macroexpand a form like:
         (progn
            (defstruct foo a b c)
            (defstruct (bar (:include foo)) d e)
         )
     [The bug is that the second defstruct cannot be macroexpanded,
     because it cannot :include the first one until the first defstruct
     has been truly evaluated.]  Were it not for other constraints, we 
     probably would have fixed this long ago.  In summary, always have a 
     macroexpander return a "simple" program rather than "part program, 
     and part (constant) data containing pre-calculated evaluations."

  -- Treated as a program, the (FOO) in a specializer (EQL (FOO)) poses
     no special problems in cross-compiling; but treating it as a kind
     of constant designator (implying object creation at compile time)
     requires a tremendous amount more of the runtime class hierarchy
     to be "present and accounted for" in the cross-compiling environment.

  -- In PCL, Gregor took the "program" approach rather than the "data" one;
     Moon has gone on record favoring it too.  And although I dislike the
     approach taken for DEFCONSTANT by most implentations, it too favors
     the "program" approach.  It sure would be nice for eql specializers
     not to have to fall into the horrible controversy surrounding
     compiled constants (i.e., those other than DEFCONSTANT constants).


-- JonL --


P.S. This part of the discussion seemed relevant to the cl-compiler group
     also;  messages dealing primarly with CLASS semantics, however,  
     probably don't need to be cc'd there.

∂10-Jan-89  1904	Common-Lisp-Object-System-mailer 	MAKE-LOAD-FORM can handle circularities [was Compilation implications] 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89  19:03:59 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA17216; Tue, 10 Jan 89 19:04:42 PST
Received: from lukasiewicz.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA16547; Tue, 10 Jan 89 19:01:19 PST
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
	id AA10509; Tue, 10 Jan 89 19:03:49 PST
Date: Tue, 10 Jan 89 19:03:49 PST
From: jrose@Sun.COM (John Rose)
Message-Id: <8901110303.AA10509@lukasiewicz.sun.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: Gray@DSG.csc.ti.com, jonl@lucid.com,
        Common-Lisp-Object-System@SAIL.STANFORD.EDU,
        CL-Compiler@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Sat, 7 Jan 89 01:04 EST <19890107060409.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: MAKE-LOAD-FORM can handle circularities [was Compilation implications]

   Date: Sat, 7 Jan 89 01:04 EST
   From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

       Date: Thu, 5 Jan 89  19:06:02 CST
       From: David N Gray <Gray@DSG.csc.ti.com>

       > Probably it would be a better idea for MAKE-LOAD-FORM to return two
       > values, where the first value is a form that will create the object and
       > the second value is a form that will further initialize the object?
       > This way the order of evaluation requirement is more explicit.  It's
       > upward compatible since the second value can be NIL if you don't need
       > it. 

       Yes, that sounds good except for the problem of how to pass the object to
       the second form.
    ...

   What I had in mind was ((LAMBDA (object) ...code...)).  But I like your
   suggestion of evaluating the form in an environment where * is bound to the
   object better.  Other people should check me on this, it might just be that
   you appealed to my sense of hackish kludgery.

There's a less kludgey way to get this taken care of:

Simply allow the second form to contain a reference to the object
being dumped.

Neat, yes?  File-level EQ preservation works to restore the embedded
object reference "for free".

And, while we're at it, give the programmer a break, and let the second
form be optional.

Here's a more complete description of these ideas:

Define a generic function MAKE-LOAD-FORM which takes one argument and
returns one or two values.  This function is called whenever
COMPILE-FILE needs to dump an object whose class is of type
STANDARD-CLASS or STRUCTURE-CLASS.  (Call these types "user defined".)
It returns one or two Lisp forms, which when passed at load time to EVAL
will construct an object which is, in some class-specific sense,
"equivalent" to the original object.

Call the first form returned by MAKE-LOAD-FORM the "allocator", and the
second form the "initializer".

The allocator must wholly or partially build the reconstructed object,
and return an ordinary Lisp reference to it.  The initializer, if
supplied and non-null, must finish any initialization required by the
object's class.  It is an error if the result of this second form is not
EQ to the result of the first.

Both the allocator and initializer are dumped to and restored from the
binary file by COMPILE-FILE, by the usual means.  It is expected that
they will consist of list structure, possibly with object of user-defined
type at the fringe.

The allocator must be dumpable without reference to the original object.
That is, in the process of dumping the original object, the dumper must
not be called upon to output the original object again until the allocator
has been completely dumped.

The initializer may contain references to arbitrary objects.  In
particular, it will typically contain a reference to the original
object.  Because all references to a given object in a compiled file
remain EQ across load, this can be reliably ensured simply by having
MAKE-LOAD-FORM return a reference to the original object embedded in
its second argument.

While the initializer form is being read in, the reconstructed object is
possibly in an uninitialized state, analogous to the state of an object
between the time its reference has been created by ALLOCATE-INSTANCE
and it has been processed fully by INITIALIZE-INSTANCE.  Implementors
must take care in manipulating objects referenced by allocator and
initializer forms, as they would in manipulating partially initialized
objects inside INITIALIZE-INSTANCE.

(Think of the allocator as creating a reference to a chunk of storage,
which stands in for the object until such time as the initializer can
really create it.  Meanwhile, the reference can be stored in other data
structure, and such stored references will become fully valid when the
object is finally initialized.)

Note that it is possible for uninitialized objects to appear in either
of the allocator or initializer forms, but when the loading process
completes, all initalizers will have been run.

A programmer of a certain class may elect to return a null initializer,
and perform all initialization in the allocator (which could then be a
simple call to MAKE-INSTANCE).  In this case, some circular data
structures involving that class will not be dumpable.  However, such
"simply dumped" classes may take part in circularities, as long as any
such a circularity includes at least one object which returns two values
for MAKE-LOAD-FORM, and whose allocator form breaks the circularity by
omitting all references to the next object in the circle.  Therefore,
not all classes need support the two-phase dumping protocol.

(Roughly speaking, in order to win, you need to have "enough" classes
with "small" allocator forms.)

Example:
	(defclass tree-with-parent () (parent children))
	(defmethod make-load-form ((x tree-with-parent))
	  (values
	    `(allocate-instance (class-of x) :children ',(slot-value x 'children))
	    `(initialize-instance ',x :parent ',(slot-value x 'parent))))

∂10-Jan-89  2058	Common-Lisp-Object-System-mailer 	MAKE-LOAD-FORM can handle circularities [was Compilation implications] 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Jan 89  20:58:02 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 519020; 10 Jan 89 23:55:07 EST
Date: Tue, 10 Jan 89 23:54 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: MAKE-LOAD-FORM can handle circularities [was Compilation implications]
To: John Rose <jrose@Sun.COM>
cc: Gray@DSG.csc.ti.com, jonl@lucid.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU,
    CL-Compiler@SAIL.STANFORD.EDU
In-Reply-To: <8901110303.AA10509@lukasiewicz.sun.com>
Message-ID: <19890111045446.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 10 Jan 89 19:03:49 PST
    From: jrose@Sun.COM (John Rose)

    Simply allow the second form to contain a reference to the object
    being dumped.

    Neat, yes?  File-level EQ preservation works to restore the embedded
    object reference "for free".

Right.  You are so smart!

    And, while we're at it, give the programmer a break, and let the second
    form be optional.

That was always the intention.  Complex capabilities shouldn't make doing
simple things harder.

    Here's a more complete description of these ideas:

I pretty much agree with your description.  I still hope to find time
to write a second version of the proposal, which will incorporate what
you said, except that I will try to write it in less implementation
oriented terms and more language oriented terms.

    Define a generic function MAKE-LOAD-FORM which takes one argument and
    returns one or two values.  This function is called whenever
    COMPILE-FILE needs to dump an object whose class is of type
    STANDARD-CLASS or STRUCTURE-CLASS.  (Call these types "user defined".)
    It returns one or two Lisp forms, which when passed at load time to EVAL
    will construct an object which is, in some class-specific sense,
    "equivalent" to the original object.

    Call the first form returned by MAKE-LOAD-FORM the "allocator", and the
    second form the "initializer".

    The allocator must wholly or partially build the reconstructed object,
    and return an ordinary Lisp reference to it.  The initializer, if
    supplied and non-null, must finish any initialization required by the
    object's class.  It is an error if the result of this second form is not
    EQ to the result of the first.

If you remove this seemingly useless error check, you don't have to special
case NIL as a second value.  (EVAL NIL) never hurts.

    Both the allocator and initializer are dumped to and restored from the
    binary file by COMPILE-FILE, by the usual means.  It is expected that
    they will consist of list structure, possibly with object of user-defined
    type at the fringe.

    The allocator must be dumpable without reference to the original object.
    That is, in the process of dumping the original object, the dumper must
    not be called upon to output the original object again until the allocator
    has been completely dumped.

    The initializer may contain references to arbitrary objects.  In
    particular, it will typically contain a reference to the original
    object.  Because all references to a given object in a compiled file
    remain EQ across load, this can be reliably ensured simply by having
    MAKE-LOAD-FORM return a reference to the original object embedded in
    its second argument.

    While the initializer form is being read in, the reconstructed object is
    possibly in an uninitialized state, analogous to the state of an object
    between the time its reference has been created by ALLOCATE-INSTANCE
    and it has been processed fully by INITIALIZE-INSTANCE.  Implementors
    must take care in manipulating objects referenced by allocator and
    initializer forms, as they would in manipulating partially initialized
    objects inside INITIALIZE-INSTANCE.

    (Think of the allocator as creating a reference to a chunk of storage,
    which stands in for the object until such time as the initializer can
    really create it.  Meanwhile, the reference can be stored in other data
    structure, and such stored references will become fully valid when the
    object is finally initialized.)

    Note that it is possible for uninitialized objects to appear in either
    of the allocator or initializer forms, but when the loading process
    completes, all initalizers will have been run.

    A programmer of a certain class may elect to return a null initializer,
    and perform all initialization in the allocator (which could then be a
    simple call to MAKE-INSTANCE).  In this case, some circular data
    structures involving that class will not be dumpable.  However, such
    "simply dumped" classes may take part in circularities, as long as any
    such a circularity includes at least one object which returns two values
    for MAKE-LOAD-FORM, and whose allocator form breaks the circularity by
    omitting all references to the next object in the circle.  Therefore,
    not all classes need support the two-phase dumping protocol.

    (Roughly speaking, in order to win, you need to have "enough" classes
    with "small" allocator forms.)

    Example:
	    (defclass tree-with-parent () (parent children))
	    (defmethod make-load-form ((x tree-with-parent))
	      (values
		`(allocate-instance (class-of x) :children ',(slot-value x 'children))
		`(initialize-instance ',x :parent ',(slot-value x 'parent))))

The example needs some debugging.

∂11-Jan-89  1421	Common-Lisp-Object-System-mailer 	Re: MAKE-LOAD-FORM can handle circularities [was Compilation implications]  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 11 Jan 89  12:18:09 PST
Received: by ti.com id AA10250; Wed, 11 Jan 89 11:50:52 CST
Received: from Kelvin by tilde id AA26201; Wed, 11 Jan 89 11:36:49 CST
Message-Id: <2809532336-3923292@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 11 Jan 89  11:38:56 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: jrose@Sun.COM (John Rose)
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, jonl@lucid.com,
        Common-Lisp-Object-System@SAIL.STANFORD.EDU
Subject: Re: MAKE-LOAD-FORM can handle circularities [was Compilation implications]
In-Reply-To: Msg of Tue, 10 Jan 89 19:03:49 PST from jrose@Sun.COM (John Rose)

> Simply allow the second form to contain a reference to the object
> being dumped.
> 
> Neat, yes?  File-level EQ preservation works to restore the embedded
> object reference "for free".

Yes.

> Define a generic function MAKE-LOAD-FORM which takes one argument and
> returns one or two values.  This function is called whenever
> COMPILE-FILE needs to dump an object whose class is of type
> STANDARD-CLASS or STRUCTURE-CLASS. 

Or if its class is a user-defined metaclass, even if not a subclass of
STANDARD-CLASS.  Maybe it would be best to say anything whose metaclass is
not BUILT-IN-CLASS.

> The allocator must wholly or partially build the reconstructed object,
> and return an ordinary Lisp reference to it.  The initializer, if
> supplied and non-null, must finish any initialization required by the
> object's class.  It is an error if the result of this second form is not
> EQ to the result of the first.

It would be a convenient convention for the second form to return the
object, but the value returned by the second form would not actually be
used for anything, so it doesn't need to be constrained.  Or maybe you
just want to verify that it did what it was intended to?

> Example:
> 	(defclass tree-with-parent () (parent children))
> 	(defmethod make-load-form ((x tree-with-parent))
> 	  (values
> 	    `(allocate-instance (class-of x) :children ',(slot-value x 'children))
> 	    `(initialize-instance ',x :parent ',(slot-value x 'parent))))

This isn't quite right because ALLOCATE-INSTANCE doesn't fill in any slot
values.  Maybe what you want is something like

(defclass tree-with-parent () ((parent :accessor tree-parent)
			       (children :initarg :children)))
(defmethod make-load-form ((x tree-with-parent))
  (values
    `(make-instance ',(class-of x) :children ',(slot-value x 'children))
    `(setf (tree-parent ',x) ',(slot-value x 'parent))))

∂11-Jan-89  1431	Common-Lisp-Object-System-mailer 	MAKE-LOAD-FORM can handle circularities [was Compilation implications] 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Jan 89  12:25:28 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 519263; Wed 11-Jan-89 12:37:35 EST
Date: Wed, 11 Jan 89 12:37 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: MAKE-LOAD-FORM can handle circularities [was Compilation implications]
To: Eric Benson <eb@lucid.com>
cc: jrose@Sun.COM, Gray@DSG.csc.ti.com, jonl@lucid.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU,
    CL-Compiler@SAIL.STANFORD.EDU
In-Reply-To: <8901111659.AA01229@blacksox>
Message-ID: <19890111173731.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 11 Jan 89 08:59:40 pst
    From: Eric Benson <eb@lucid.com>

    The dumper should be allowed to compile the forms returned by
    MAKE-LOAD-FORM.  That would be a way of trading increased dumping time
    for decreased loading time.  If the file is to be loaded many times
    that would be a desirable trade-off.  Also, it is then possible to
    load it into a Lisp that has no EVAL.

I agree.  Didn't the version 1 writeup say that?

∂11-Jan-89  1431	Common-Lisp-Object-System-mailer 	Re: MAKE-LOAD-FORM can handle circularities [was Compilation implications]  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Jan 89  12:25:38 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 519270; Wed 11-Jan-89 12:53:09 EST
Date: Wed, 11 Jan 89 12:53 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: MAKE-LOAD-FORM can handle circularities [was Compilation implications]
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: John Rose <jrose@Sun.COM>, Gray@DSG.csc.ti.com, jonl@lucid.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU,
    CL-Compiler@SAIL.STANFORD.EDU
In-Reply-To: <8901111611.AA12297@defun.utah.edu>
Message-ID: <19890111175308.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 11 Jan 89 09:11:57 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    Just to set the record straight:

    > Date: Tue, 10 Jan 89 19:03:49 PST
    > From: jrose@Sun.COM (John Rose)
    > 
    > File-level EQ preservation works to restore the embedded
    > object reference "for free".

    Unfortunately, we don't know yet if file-level EQ preservation works;
    see issue CONSTANT-CIRCULAR-COMPILATION.  KCL is one implementation
    where COMPILE-FILE/LOAD does not now preserve EQness of structures. 

If file-level EQ preservation is punted, MAKE-LOAD-FORM only returns one
value, and this whole discussion is punted.  So it doesn't actually
matter that we don't know yet (except that we might be wasting our
time).

Personally, I think file-level EQ preservation is important and would
hate to see it excluded from the language specification.

To throw a digression into the discussion, the only thing I know of
that's hard about file-level EQ preservation is EQness of CDRs in
implementations with cdr-coding of lists.  Even that's only "hard" in
the sense that it is difficult to convince implementors to do EQness
checking by treating each individual cons as a separate object, rather
than treating the whole list as a single object, because it seems (and
in fact is) less efficient.  Symbolics Genera 7.x gets this wrong.  What
about the TI Explorer?

∂11-Jan-89  1432	CL-Compiler-mailer 	Re: MAKE-LOAD-FORM can handle circularities [was Compilation implications] 
Received: from cs.utah.edu ([128.110.4.21]) by SAIL.Stanford.EDU with TCP; 11 Jan 89  12:26:15 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
	id AA04433; Wed, 11 Jan 89 09:12:22 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA12297; Wed, 11 Jan 89 09:11:58 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901111611.AA12297@defun.utah.edu>
Date: Wed, 11 Jan 89 09:11:57 MST
Subject: Re: MAKE-LOAD-FORM can handle circularities [was Compilation implications]
To: jrose@Sun.COM (John Rose)
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, Gray@DSG.csc.ti.com, jonl@lucid.com,
        Common-Lisp-Object-System@SAIL.STANFORD.EDU,
        CL-Compiler@SAIL.STANFORD.EDU
In-Reply-To: jrose@Sun.COM (John Rose), Tue, 10 Jan 89 19:03:49 PST

Just to set the record straight:

> Date: Tue, 10 Jan 89 19:03:49 PST
> From: jrose@Sun.COM (John Rose)
> 
> File-level EQ preservation works to restore the embedded
> object reference "for free".

Unfortunately, we don't know yet if file-level EQ preservation works;
see issue CONSTANT-CIRCULAR-COMPILATION.  KCL is one implementation
where COMPILE-FILE/LOAD does not now preserve EQness of structures. 

-Sandra
-------

∂11-Jan-89  1433	CL-Compiler-mailer 	MAKE-LOAD-FORM can handle circularities [was Compilation implications]
Received: from lucid.com ([192.26.25.1]) by SAIL.Stanford.EDU with TCP; 11 Jan 89  12:33:14 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA03444g; Wed, 11 Jan 89 08:57:15 PST
Received: by blacksox id AA01229g; Wed, 11 Jan 89 08:59:40 pst
Date: Wed, 11 Jan 89 08:59:40 pst
From: Eric Benson <eb@lucid.com>
Message-Id: <8901111659.AA01229@blacksox>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: jrose@Sun.COM, Gray@DSG.csc.ti.com, jonl@lucid.com,
        Common-Lisp-Object-System@SAIL.STANFORD.EDU,
        CL-Compiler@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Tue, 10 Jan 89 23:54 EST <19890111045446.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: MAKE-LOAD-FORM can handle circularities [was Compilation implications]

The dumper should be allowed to compile the forms returned by
MAKE-LOAD-FORM.  That would be a way of trading increased dumping time
for decreased loading time.  If the file is to be loaded many times
that would be a desirable trade-off.  Also, it is then possible to
load it into a Lisp that has no EVAL.

∂11-Jan-89  1458	CL-Compiler-mailer 	Re: MAKE-LOAD-FORM can handle circularities [was Compilation implications] 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 11 Jan 89  14:47:27 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
	id AA17453; Wed, 11 Jan 89 15:44:43 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA12661; Wed, 11 Jan 89 15:44:31 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901112244.AA12661@defun.utah.edu>
Date: Wed, 11 Jan 89 15:44:29 MST
Subject: Re: MAKE-LOAD-FORM can handle circularities [was Compilation implications]
To: Eric Benson <eb@lucid.com>
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, jrose@Sun.COM, Gray@DSG.csc.ti.com,
        jonl@lucid.com, Common-Lisp-Object-System@SAIL.STANFORD.EDU,
        CL-Compiler@SAIL.STANFORD.EDU
In-Reply-To: Eric Benson <eb@lucid.com>, Wed, 11 Jan 89 08:59:40 pst

> The dumper should be allowed to compile the forms returned by
> MAKE-LOAD-FORM.

This sounds like a good use for the proposed new LOAD-TIME-VALUE
special form.

-Sandra
-------

∂11-Jan-89  1515	CL-Compiler-mailer 	MAKE-LOAD-FORM can handle circularities [was Compilation implications]
Received: from lucid.com ([192.26.25.1]) by SAIL.Stanford.EDU with TCP; 11 Jan 89  12:59:51 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA03707g; Wed, 11 Jan 89 12:55:13 PST
Received: by blacksox id AA01277g; Wed, 11 Jan 89 12:57:38 pst
Date: Wed, 11 Jan 89 12:57:38 pst
From: Eric Benson <eb@lucid.com>
Message-Id: <8901112057.AA01277@blacksox>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: jrose@Sun.COM, Gray@DSG.csc.ti.com, jonl@lucid.com,
        Common-Lisp-Object-System@SAIL.STANFORD.EDU,
        CL-Compiler@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Wed, 11 Jan 89 12:37 EST <19890111173731.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: MAKE-LOAD-FORM can handle circularities [was Compilation implications]

   Date: Wed, 11 Jan 89 12:37 EST
   From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

       Date: Wed, 11 Jan 89 08:59:40 pst
       From: Eric Benson <eb@lucid.com>

       The dumper should be allowed to compile the forms returned by
       MAKE-LOAD-FORM.  That would be a way of trading increased dumping time
       for decreased loading time.  If the file is to be loaded many times
       that would be a desirable trade-off.  Also, it is then possible to
       load it into a Lisp that has no EVAL.

   I agree.  Didn't the version 1 writeup say that?

Maybe it did.  Some CL mail has gotten lost on its way here, due to
lossage at SAIL.  Or I might have just overlooked it.

∂13-Jan-89  1454	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Jan 89  14:53:53 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 521325; Fri 13-Jan-89 17:52:09 EST
Date: Fri, 13 Jan 89 17:52 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-OBJECTS (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU
Message-ID: <19890113225201.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

Here is the updated version of this.  Sorry it took so long.
I will bring a few copies of this with me to the meeting.

Issue:         LOAD-OBJECTS

References:    none

Related issues: LOAD-TIME-EVAL,
                CONSTANT-COMPILABLE-TYPES,
                CONSTANT-CIRCULAR-COMPILATION

Category:      ADDITION

Forum:         Cleanup

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

Problem description:

  Common Lisp doesn't provide any way to use an object of a user-defined
  type (defined with DEFCLASS or DEFSTRUCT) as a constant in a program
  compiled with COMPILE-FILE.  The problem is that LOAD has to be able
  to "reconstruct" an equivalent object when the compiled-code file is
  loaded, but the programmer has no way to tell LOAD how to do that.


Proposal (LOAD-OBJECTS:MAKE-LOAD-FORM):
          
  Define a new generic function named MAKE-LOAD-FORM, which takes one
  argument and returns two values.  The argument is an object that is
  referenced as a constant or as a self-evaluating form in a file being
  compiled by COMPILE-FILE.  The objective is to enable LOAD to
  construct an equivalent object.

  The first value, called the "creation form," is a form that, when
  evaluated at load time, should return an object that is equivalent to
  the argument.  The exact meaning of "equivalent" depends on the type
  of object and is up to the programmer who defines a method for
  MAKE-LOAD-FORM.  This is the same type of equivalence discussed
  in issue CONSTANT-COMPILABLE-TYPES.

  The second value, called the "initialization form," is a form that,
  when evaluated at load time, should perform further initialization of
  the object.  The value returned by the initialization form is ignored.
  If the MAKE-LOAD-FORM method returns only one value, the
  initialization form is NIL, which has no effect.  If the object used
  as the argument to MAKE-LOAD-FORM appears as a constant in the
  initialization form, at load time it will be replaced by the
  equivalent object constructed by the creation form; this is how the
  further initialization gains access to the object.

  Both the creation form and the initialization form can contain
  references to objects of user-defined types (defined precisely below).
  However, there must not be any circular dependencies in creation forms.
  An example of a circular dependency is when the creation form for the
  object X contains a reference to the object Y, and the creation form
  for the object Y contains a reference to the object X.  A simpler
  example would be when the creation form for the object X contains
  a reference to X itself.  Initialization forms are not subject to
  any restriction against circular dependencies, which is the entire
  reason that initialization forms exist.  See the example of circular
  data structures below.

  The creation form for an object is always evaluated before the
  initialization form for that object.  When either the creation form or
  the initialization form references other objects of user-defined types
  that have not been referenced earlier in the COMPILE-FILE, the
  compiler collects all of the creation forms together and collects all
  of the initialization forms together.  All of the creation forms are
  evaluated before any of the initialization forms.  The order of
  evaluation of the creation forms is unspecified except when the
  ordering is forced by data dependencies.  The order of evaluation of
  the initialization forms is unspecified.

  While these creation and initialization forms are being evaluated, the
  objects are possibly in an uninitialized state, analogous to the state
  of an object between the time it has been created by ALLOCATE-INSTANCE
  and it has been processed fully by INITIALIZE-INSTANCE.  Programmers
  writing methods for MAKE-LOAD-FORM must take care in manipulating
  objects not to depend on slots that have not yet been initialized.

  It is unspecified whether LOAD calls EVAL on the forms or does some
  other operation that has an equivalent effect.  For example, the
  forms might be translated into different but equivalent forms and
  then evaluated, they might be compiled and the resulting functions
  called by LOAD, or they might be interpreted by a special-purpose
  interpreter different from EVAL.  All that is required is that the
  effect be equivalent to evaluating the forms.

  COMPILE-FILE calls MAKE-LOAD-FORM on any object that is referenced as
  a constant or as a self-evaluating form, if the object's metaclass is
  STANDARD-CLASS, STRUCTURE-CLASS, any user-defined metaclass (not a
  subclass of BUILT-IN-CLASS), or any of a possibly-empty
  implementation-defined list of other metaclasses.  COMPILE-FILE will
  only call MAKE-LOAD-FORM once for any given object (compared with EQ)
  within a single file.

  It is valid for user programs to call MAKE-LOAD-FORM in other
  circumstances.

  The function MAKE-LOAD-FORM-USING-SLOTS can be useful in user-written
  MAKE-LOAD-FORM methods.  Its first argument is the object.  Its
  optional second argument is a list of the names of the slots to
  preserve; it defaults to all of the local slots.
  MAKE-LOAD-FORM-USING-SLOTS returns forms that construct an equivalent
  object using MAKE-INSTANCE and SETF of SLOT-VALUE for slots with
  values, or SLOT-MAKUNBOUND for slots without values, or using other
  functions of equivalent effect.  MAKE-LOAD-FORM-USING-SLOTS returns
  two values, thus it can deal with circular structures.

  The default MAKE-LOAD-FORM method for STANDARD-OBJECT signals an
  error.

  The default MAKE-LOAD-FORM method for STRUCTURE-OBJECT returns forms
  that construct an equivalent structure based on the structure name and
  the slot values.  This might be written using
  MAKE-LOAD-FORM-USING-SLOTS, but that is not required.


Examples:

  ;; Example 1
  (defclass my-class ()
     ((a :initarg :a :reader my-a)
      (b :initarg :b :reader my-b)
      (c :accessor my-c)))
  (defmethod shared-initialize ((self my-class) ignore &rest ignore)
    (unless (slot-boundp self 'c)
      (setf (my-c self) (some-computation (my-a self) (my-b self)))))
  (defmethod make-load-form ((self my-class))
    `(make-instance ',(class-name (class-of self))
                    :a ',(my-a self) :b ',(my-b self)))

  In this example, an equivalent instance of my-class is reconstructed
  by using the values of two of its slots.  The value of the third slot
  is derived from those two values.

  Another way to write the last form in the above example would have been

  (defmethod make-load-form ((self my-class))
     (make-load-form-using-slots self '(a b)))

  ;; Example 2
  (defclass my-frob ()
     ((name :initarg :name :reader my-name)))
  (defmethod make-load-form ((self my-frob))
    `(find-my-frob ',(my-name self) :if-does-not-exist :create))

  In this example, instances of my-frob are "interned" in some way.
  An equivalent instance is reconstructed by using the value of the
  name slot as a key for searching existing objects.  In this case
  the programmer has chosen to create a new object if no existing
  object is found; alternatively she could have chosen to signal an
  error in that case.

  ;; Example 3
  (defclass tree-with-parent () ((parent :accessor tree-parent)
                                 (children :initarg :children)))
  (defmethod make-load-form ((x tree-with-parent))
    (values
      ;; creation form
      `(make-instance ',(class-of x) :children ',(slot-value x 'children))
      ;; initialization form
      `(setf (tree-parent ',x) ',(slot-value x 'parent))))

  In this example, the data structure to be dumped is circular, because
  each parent has a list of its children and each child has a reference
  back to its parent.  Suppose make-load-form is called on one object in
  such a structure.  The creation form creates an equivalent object and
  fills in the children slot, which forces creation of equivalent
  objects for all of its children, grandchildren, etc.  At this point
  none of the parent slots have been filled in.  The initialization form
  fills in the parent slot, which forces creation of an equivalent
  object for the parent if it was not already created.  Thus the entire
  tree is recreated at load time.  At compile time, MAKE-LOAD-FORM is
  called once for each object in the true.  All of the creation forms
  are evaluated, in unspecified order, and then all of the
  initialization forms are evaluated, also in unspecified order.


Rationale:

  Only the programmer who designed a class can know the correct
  way to reconstruct objects of that class at load time, therefore
  the reconstruction should be controlled by a generic function.
  Using EVAL as the interface for telling LOAD what to do provides
  full generality.

  MAKE-LOAD-FORM returns two values so that circular structures can
  be handled.  If CONSTANT-CIRCULAR-COMPILATION is rejected,
  MAKE-LOAD-FORM will only return one value, although implementations
  that make an extension to support circular constants will probably
  also make the extension to accept two values from MAKE-LOAD-FORM.

  A default method, such as one that makes an object whose class has the
  same name and whose slots have equivalent contents, is not supplied
  for DEFCLASS-defined objects, because this is inappropriate for many
  objects and because it is easy to write for those objects where it is
  appropriate.  The function MAKE-LOAD-FORM-USING-SLOTS makes it even
  easier to write.

  MAKE-LOAD-FORM has a natural resemblance to PRINT-OBJECT, as a hook
  for the programmer to control the system's actions.

Current practice:

  Symbolics Flavors has something like this, but under a different name.
  The name Symbolics uses is not suitable for standardization.

  JonL reports that Lucid is getting more and more requests for this.

Cost to Implementors:

  This seems like only a few one-line changes in the compiled-code
  file writer and reader.  MAKE-LOAD-FORM-USING-SLOTS is a couple
  dozen lines of code, assuming the presence of the CLOS metaobject
  protocol or an implementation-dependent equivalent.

Cost to Users:

  None.

Cost of non-adoption:

  Serious impairment of the ability to use extended-type objects.  Each
  implementation will probably make up its own version of this as an
  extension.

Performance impact:

  None.

Benefits:

  See Cost of non-adoption.

Esthetics:

  No significant positive or negative impact.

Discussion:

  It would be possible to define an additional level of protocol that
  allows multiple classes to contribute to the reconstruction of an
  object, combining initialization arguments contributed by each class.
  Since a user can easily define that in terms of MAKE-LOAD-FORM without
  modifying the Lisp system, it is not being proposed now.

  Any type that has a read syntax is likely to appear as a quoted
  constant or inside a quoted constant.  Pathnames are one example, user
  programs often define others.  Also many implementations provide a way
  to create a compiled-code file full of data (rather than compiled Lisp
  programs), and such data probably include extended-type objects.

  Moon supports this.  David Gray and John Rose made major contributions
  to the discussion that produced this improved version 2 proposal.

∂13-Jan-89  1602	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Jan 89  16:02:32 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 521384; Fri 13-Jan-89 19:00:48 EST
Date: Fri, 13 Jan 89 19:00 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-OBJECTS (Version 2)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU,
    Common-Lisp-Object-System@SAIL.STANFORD.EDU,
    CL-Compiler@SAIL.STANFORD.EDU
In-Reply-To: <19890113225201.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <890113190027.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

This looks mostly very good, but ...

I'd like to see a name attached to the default function for making
structure load forms, since you're requiring it to exist anyway,
and also since there might be reason to need to revert to using it
in some structure class for which the method is shadowed by a 
superior class that was not `thinking ahead.'
[I call this problem the `DESCRIBE problem,' since the analagous
 problem comes up there, too.]

I also think there needs to be a rationale given to making these
functions not be the default. My personal feeling is that if it's
undefined for structures, it should be undefined for instances, and vice
versa. In my mind, they serve the same conceptual purpose, and differ
only in degree of efficiency and syntax of interface. For me, they do
not differ in weird ways like whether EQUAL or EQUALP should treat them
differently, or whether MAKE-LOAD-FORM should know how to dump them.
I think the argument you give for not having a default instance-dumping
strategy applies equally to struct-dumping, so if you're going to make
them differ, you need to say what your reasoning is.

∂13-Jan-89  1936	CL-Compiler-mailer 	Re: Issue: LOAD-OBJECTS (Version 2)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 13 Jan 89  19:36:04 PST
Received: by ti.com id AA21295; Fri, 13 Jan 89 19:07:05 CST
Received: from Kelvin by tilde id AA00249; Fri, 13 Jan 89 18:52:39 CST
Message-Id: <2809731258-5200907@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 13 Jan 89  18:54:18 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU
Subject: Re: Issue: LOAD-OBJECTS (Version 2)
In-Reply-To: Msg of Fri, 13 Jan 89 17:52 EST from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

This looks good.  The only thing I have doubts about is:

>   The function MAKE-LOAD-FORM-USING-SLOTS can be useful in user-written
>   MAKE-LOAD-FORM methods.  Its first argument is the object.  Its
>   optional second argument is a list of the names of the slots to
>   preserve; it defaults to all of the local slots.
>   MAKE-LOAD-FORM-USING-SLOTS returns forms that construct an equivalent
>   object using MAKE-INSTANCE and SETF of SLOT-VALUE for slots with
>   values, or SLOT-MAKUNBOUND for slots without values, or using other
>   functions of equivalent effect. 

Rather than having the second argument default to a list of all instance
slots, it might be better to consider two separate cases:

  1. If a second argument is supplied, then MAKE-INSTANCE will be used to
     create the object, (using INITIALIZE-INSTANCE to default the slot
     values), and then the designated slots will be forced to
     have the proper value.

  2. Without a second argument, ALLOCATE-INSTANCE will be used to create
     the object (without invoking INITIALIZE-INSTANCE or
     SHARED-INITIALIZE), and then all the slots will be filled in.

If you are going to specify all of the slot values, then there shouldn't
be a need to compute default values, and it may be undesirable to invoke
INITIALIZE-INSTANCE -- for example, it might complain about missing
required arguments or perform undesired side-effects.

>   The default MAKE-LOAD-FORM method for STANDARD-OBJECT signals an
>   error.

Wouldn't it be permissible to just not have a default method, so that a
"no applicable method" error is signalled?

∂13-Jan-89  2058	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 2)
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 13 Jan 89  20:58:12 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA04397; Fri, 13 Jan 89 20:59:34 PST
Received: from lukasiewicz.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA22496; Fri, 13 Jan 89 20:56:15 PST
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
	id AA18401; Fri, 13 Jan 89 20:58:49 PST
Date: Fri, 13 Jan 89 20:58:49 PST
From: jrose@Sun.COM (John Rose)
Message-Id: <8901140458.AA18401@lukasiewicz.sun.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU,
        CL-Compiler@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Fri, 13 Jan 89 17:52 EST <19890113225201.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: LOAD-OBJECTS (Version 2)

  ...
     The creation form for an object is always evaluated before the
     initialization form for that object.  When either the creation form or
     the initialization form references other objects of user-defined types
     that have not been referenced earlier in the COMPILE-FILE, the
     compiler collects all of the creation forms together and collects all
     of the initialization forms together.  All of the creation forms are
     evaluated before any of the initialization forms.  The order of
     evaluation of the creation forms is unspecified except when the
     ordering is forced by data dependencies.  The order of evaluation of
     the initialization forms is unspecified.
  ...
Why does the proposal restrict the evaluation initialization forms to
such a late time?  Data dependencies would allow an object X's
initialization form to be executed any time after X's creation form had
finished.  Is there a reason to be more strict?  I can't think of one,
but if there is one, it should be stated on the rationale.

Actually, it would be better (and no more difficult, it seems to me) to
be strict in the other direction: Objects should be initialized as early
as possible, and hence at a deterministic time.  This would allow nodes
in non-circular structures to be built out of fully initialized subparts,
which is clearly something an application could need.

Here's what your paragraph would look like, given that point:

  The creation form for an object X is always fully evaluated before the
  initialization form for that object.  This evaluation includes the
  evaluation of the creation form of any user-defined object Y contained
  in X's creation form, and will also include the evaluation of Y's
  initialization form, if X and Y are not part of a circular chain of
  initialization forms.  Any circular substructures of X will be fully
  initialized.  Initialization forms of circular structures are
  evaluated in an implementation-defined order, subject to the previous
  restrictions.  These rules are intended to ensure that initialization
  follows creation as quickly as possible, subject to data flow.

Under these rules, noncircular data structures will be treated as if
all the initialization forms will immediately follow the creation
forms this way:
	(eval `(let ((obj ,<creation-form>))
	         ,(subst 'obj <original-object> <initialization-form>)
		 obj))
Furthermore, circular sub-structures will not impair the timely
initialization of non-circular containing structures.  Such guarantees
will give programmers a sense of security in breaking out as much
processing as possible into the initialization form.

If this point of view is not adopted, a laissez-faire position is probably
better, and I think your paragraph above could be deleted, or rewritten thus:

  The creation form for an object is always fully evaluated before the
  initialization form for that object.  This evaluation includes the
  evaluation of creation forms of any user-defined objects contained in
  the creation form, and may or may not include the evaluation of
  initialization forms.  However, when a "top-level object" is loaded,
  all creation and initialization forms of that object must be fully
  evaluated before any further loading actions are taken.  These rules
  are intended to allow implementations a high degree of freedom in
  ordering the evaluation of creation and initialization forms, subject
  to the requirements of data flow.

This paragraph needs to define the the specially-treated "top-level object",
which seems to be a concept implicit in your original paragraph.  But I'd
rather see my first point adopted, and be done with top-level objects.

				-- John

∂23-Jan-89  1152	CL-Compiler-mailer 	DEFMETHOD compile-time processing  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 23 Jan 89  11:52:44 PST
Received: by ti.com id AA28832; Mon, 23 Jan 89 13:52:14 CST
Received: from dsg by tilde id AA23248; Mon, 23 Jan 89 13:38:15 CST
Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 23 Jan 89  11:15:29 CST
Message-Id: <2810567730-15432385@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 23 Jan 89  11:15:30 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Common-Lisp-Object-System@SAIL.Stanford.edu
Cc: CL-Compiler@SAIL.Stanford.edu
Subject: DEFMETHOD compile-time processing

In the Meta Object Protocol draft number 10 [89-003], on page 3-16 it says
that 
  "At compile time: ... (5) The method function is computed by
  evaluating the special form (FUNCTION <lambda>) in the lexical
  environment of the DEFMETHOD.  ...  (7) The function ADD-METHOD is
  called ..."

This isn't going to work.  You can install the function at load
time in its lexical environment, or you can install it at compile time in
the null lexical environment, but you can't evaluate something at
compile-time in its run-time lexical environment.

Possible remedies include:

 * Do the compile-time call to ADD-METHOD only if the DEFMETHOD appears at
   top-level in a null lexical environment.  This would be consistent with
   the treatment of DEFMACRO in proposal DEFINING-MACROS-NON-TOP-LEVEL.

 * Don't ever do a compile-time call to ADD-METHOD.  I haven't seen a
   reason why methods would need to be installed in the compile-time
   environment.  Apparently at least some information about generic
   function definitions needs to be remembered for use when invoking
   MAKE-METHOD-LAMBDA, but that wouldn't require being able to actually
   call the generic function at compile-time.

∂24-Jan-89  0928	CL-Compiler-mailer 	DEFMETHOD compile-time processing  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 24 Jan 89  09:28:47 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01394g; Tue, 24 Jan 89 09:23:52 PST
Received: by challenger id AA18054g; Tue, 24 Jan 89 09:19:45 PST
Date: Tue, 24 Jan 89 09:19:45 PST
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8901241719.AA18054@challenger>
To: Gray@DSG.csc.ti.com
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Compiler@SAIL.Stanford.edu
In-Reply-To: David N Gray's message of Mon, 23 Jan 89  11:15:30 CST <2810567730-15432385@Kelvin>
Subject: DEFMETHOD compile-time processing

   Sender: GRAY@Kelvin.csc.ti.com
   Date: Mon, 23 Jan 89  11:15:30 CST
   From: David N Gray <Gray@DSG.csc.ti.com>

   In the Meta Object Protocol draft number 10 [89-003], on page 3-16 it says
   that 
     "At compile time: ... (5) The method function is computed by
     evaluating the special form (FUNCTION <lambda>) in the lexical
     environment of the DEFMETHOD.  ...  (7) The function ADD-METHOD is
     called ..."

   This isn't going to work.  You can install the function at load
   time in its lexical environment, or you can install it at compile time in
   the null lexical environment, but you can't evaluate something at
   compile-time in its run-time lexical environment.

you're right. 


The general issue that we try to address is that it should be possible for
some implementations to precompute a certain number of characteristic of CLOS
programs at compile-file time. These precomputation involve metaobjects
(looking at user class definitions, method object, generic functions) in a
state that should be close enough to their state when the program is loaded in
the remote environment. It is not generally possible to simulate the remote
environment as far as running remote code. Therefore, precomputation at
compile time, by doing metaprogramming on remote environment objects is more
restrictive that doing metaprogramming on local environment objects. However,
we don't want to introduce two distinct metaprogrammings. Chapter 3 is trying
to unify remote and local metaprogramming. All the side effect that are done
when the program is loaded, is simulated in the remote environment(
Add-method, ensure-class...). As Gray noticed, it does not always work. In
particular, we should acknowledge the difference as far as function objects
are concerned: Local function object can be executed, remote functions can
only be looked at.


   Possible remedies include:

    * Do the compile-time call to ADD-METHOD only if the DEFMETHOD appears at
      top-level in a null lexical environment.  This would be consistent with
      the treatment of DEFMACRO in proposal DEFINING-MACROS-NON-TOP-LEVEL.

I don't consider this solution very satisfying, because it hides the problem.
It is possible to represent functions for the remote environment by normal
functions if the lexical environment is null, but still, they can't be
executed. The problem remains. 

    * Don't ever do a compile-time call to ADD-METHOD.  I haven't seen a
      reason why methods would need to be installed in the compile-time
      environment.  Apparently at least some information about generic
      function definitions needs to be remembered for use when invoking
      MAKE-METHOD-LAMBDA, but that wouldn't require being able to actually
      call the generic function at compile-time.

This will lead to two different metaprogramming styles. Note that this is more
or less what Flavors does. It is workable, but not pretty. Maybe a better
solution is to standardize a representation for objects in the remote
environment, and have the compile-file time expansion create them. Add-method
and such work as before, function slots don't always contain real functions.

Patrick.

∂24-Jan-89  1415	Common-Lisp-Object-System-mailer 	DEFMETHOD compile-time processing   
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 24 Jan 89  14:15:08 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA20353; Tue, 24 Jan 89 14:16:20 PST
Received: from lukasiewicz.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA14503; Tue, 24 Jan 89 14:12:36 PST
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
	id AA03288; Tue, 24 Jan 89 14:15:11 PST
Date: Tue, 24 Jan 89 14:15:11 PST
From: jrose@Sun.COM (John Rose)
Message-Id: <8901242215.AA03288@lukasiewicz.sun.com>
To: dussud@lucid.com
Cc: Gray@DSG.csc.ti.com, Common-Lisp-Object-System@SAIL.Stanford.edu,
        CL-Compiler@SAIL.Stanford.edu
In-Reply-To: Patrick Dussud's message of Tue, 24 Jan 89 09:19:45 PST <8901241719.AA18054@challenger>
Subject: DEFMETHOD compile-time processing

   Date: Tue, 24 Jan 89 09:19:45 PST
   From: Patrick Dussud <dussud@lucid.com>

      Sender: GRAY@Kelvin.csc.ti.com
      Date: Mon, 23 Jan 89  11:15:30 CST
      From: David N Gray <Gray@DSG.csc.ti.com>

      In the Meta Object Protocol draft number 10 [89-003], on page 3-16 it says
      that 
	"At compile time: ... (5) The method function is computed by
	evaluating the special form (FUNCTION <lambda>) in the lexical
	environment of the DEFMETHOD.  ...  (7) The function ADD-METHOD is
	called ..."

      This isn't going to work.  You can install the function at load
      time in its lexical environment, or you can install it at compile time in
      the null lexical environment, but you can't evaluate something at
      compile-time in its run-time lexical environment.

   you're right. 

[A paraphase of your next paragraph:  At compile time, a "remote
environment" data structure must be set up to model the eventual state
of the "local environment" which results from loading the compiled code.
A design goal of CLOS is to make these two kinds of environments as similar
as possible, having the same programmatic interface if possible.  Yet, there
are objects which cannot be represented completely in a remote environment,
such as pieces of compiled code.]
  ...

      Possible remedies include:

       * Do the compile-time call to ADD-METHOD only if the DEFMETHOD appears at
	 top-level in a null lexical environment.  This would be consistent with
	 the treatment of DEFMACRO in proposal DEFINING-MACROS-NON-TOP-LEVEL.

   I don't consider this solution very satisfying, because it hides the problem.
   It is possible to represent functions for the remote environment by normal
   functions if the lexical environment is null, but still, they can't be
   executed. The problem remains. 

       * Don't ever do a compile-time call to ADD-METHOD.  I haven't seen a
	 reason why methods would need to be installed in the compile-time
	 environment.  Apparently at least some information about generic
	 function definitions needs to be remembered for use when invoking
	 MAKE-METHOD-LAMBDA, but that wouldn't require being able to actually
	 call the generic function at compile-time.

   This will lead to two different metaprogramming styles. Note that this is more
   or less what Flavors does. It is workable, but not pretty. Maybe a better
   solution is to standardize a representation for objects in the remote
   environment, and have the compile-file time expansion create them. Add-method
   and such work as before, function slots don't always contain real functions.

   Patrick.

In Lisp, remote function objects are usually represented by their names.
For example, if we want at compile time to get hold of a function FOO to
insert it into code or data structure (in the course of macroexpansion,
say), we naturally don't attempt to grab hold of the function object
itself, or any compile-time representation of it; we use the name FOO
itself as a reference to the function.  At compile time, the name may
not be defined, but we assume that it will be at load time.  Lisp's
dynamic linking will ensure that we will access the code we want.

I'd like to present some generalizations of this which apply to CLOS.

Interestingly, Lisp already unifies the treatment of remote functions
(i.e., their names) and local ones (compiled code objects), in the
following way: All operations which work on compiled code objects also
work on their names __if__ those names are bound in the local
environment.  For example, you can funcall or disassemble an FBOUNDP
symbol as easily as its binding, if it's bound.  A remote reference
is coerced to a local one, for local operations.

This is a principle of unity which can address the problem at hand.

The proposals for non-symbolic function names (some of which are
motivated by CLOS work) generalize the set of names you can give to
functions.  So, for example, if (SETF <name>) might be a valid function
name, so it can occur syntactically wherever a symbolic function name
might.

The semantics of non-symbolic function names (I contend) should tend to
preserve the unification between remote and local objects described
above.  For example, a list like (SETF <name>) should support the
programmatic operations common to symbols and code objects:
DISASSEMBLE, SYMBOL-FUNCTION, FBOUNDP and (yes) FUNCALL.

Did you hear me suggest allowing FBOUNDP and FUNCALL on lists?
You did.

Consider this: Common Lisp already allows FUNCALL on lists, in what
turns out to be another case of remote-to-local coercion.  If you
FUNCALL a list whose car is LAMBDA, the list is coerced to (or
interpreted as, which amounts to the same thing) the function it
specifies.  In other word, the cons tree which names a function remotely
can serve as that function's.  (By the way, an "anonymous" lambda is
really named by its cons tree.)  The reference is validated late, at the
point of call: Just as symbols are checked for fboundp-ness, lambda
forms are walked by the interpreter when called, and not earlier.
Nevertheless, the reference, once validated, is equivalent to the
object itself.

Given function specifiers for method code, and given the unification
supplied by remote-to-local coercion of all function specifiers,
we can then store remote function specifiers in method objects,
to refer to code, and both local and remote operations will work
on them.

The paragraph David Gray mentioned above would then look something
like this:

   At compile time: ... (5) The method function is set to the name of
   the method, e.g., (METHOD <gfspec> <quals> <specs>).  (This name may
   or may not be FBOUNDP at compile time.)  The form (DEFUN
   <method-name> <args> <body>) is compiled in the lexical environment
   of the DEFMETHOD.  ...  (7) The function ADD-METHOD is called ..."

   ... At load time, the DEFUN form for the method causes the method's
   name to become bound to the specified code.

At both compile and load time, the method's function would be the name
of the actual function, which would be reliably FBOUNDP at load time.
Doing something like (FUNCALL (METHOD-FUNCTION M) X Y Z) would work
whenever reasonable, and cause an unbound function error at other times.

Note: As I've said before, nonsymbolic names can be useful for referring
to other things than functions.  For example, mixture classes are
usefully named by cons trees of some sort.  Consider extending the type
constructor AND to classes: (AND MY-VIEWPORT-CLASS BORDERS-MIXIN
CANVAS-STREAM-MIXIN).  This could be implemented by extending
SYMBOL-CLASS to accept non-symbolic names, with a mixin manager which
builds and caches an otherwise-anonymous class for each mixture it sees.

Note also that a user-defined function specifier facility, with the
remote-to-local coercion rule, lets you build lambda-macros.
(Remember those?)

					-- John

∂24-Jan-89  1746	CL-Compiler-mailer 	Re: DEFMETHOD compile-time processing   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 24 Jan 89  17:46:47 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
	id AA21651; Tue, 24 Jan 89 18:43:37 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA20013; Tue, 24 Jan 89 18:43:23 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901250143.AA20013@defun.utah.edu>
Date: Tue, 24 Jan 89 18:43:21 MST
Subject: Re: DEFMETHOD compile-time processing
To: dussud@lucid.com
Cc: jrose@Sun.COM (John Rose), Gray@DSG.csc.ti.com,
        Common-Lisp-Object-System@SAIL.Stanford.edu,
        CL-Compiler@SAIL.Stanford.edu
In-Reply-To: jrose@Sun.COM (John Rose), Tue, 24 Jan 89 14:15:11 PST

>     * Do the compile-time call to ADD-METHOD only if the DEFMETHOD appears at
>       top-level in a null lexical environment.  This would be consistent with
>       the treatment of DEFMACRO in proposal DEFINING-MACROS-NON-TOP-LEVEL.
> 
> I don't consider this solution very satisfying, because it hides the problem.
> It is possible to represent functions for the remote environment by normal
> functions if the lexical environment is null, but still, they can't be
> executed. The problem remains. 

This may not be very satisfying, but it is probably the only practical
solution.  We have already had a lot of debate on this regarding
DEFMACRO and the other defining macros.  A number of people raised
very strong objections to things like DEFMACRO causing the definition
to appear in the compile-time environment when buried inside a control
construct such as IF, or inside a DEFUN.  I don't see any reason why
those same arguments are not just as applicable to the CLOS defining
macros. 

It seems exceedingly unlikely that we compiler people would be able to
agree on any major reversal of the current proposal on issue
DEFINING-MACROS-NON-TOP-LEVEL in the 6 weeks or so we have remaining.
It also seems unlikely that you CLOS people are going to have the time
to work out any alternative semantics before then.  Even if we did
have more time to work out alternatives, to me it seems that
restricting the compile-time magic to top-level situations is the
simplest solution for all of us.  I don't see that it would affect
other parts of CLOS, and it would just allow us to take the description
of the compile-time behavior of DEFMETHOD directly from the MOP
document. 

Incidentally, I notice that the same considerations also affect
DEFCLASS and DEFGENERIC, both of which also want to create functional
objects.  The MOP document doesn't seem to say anything about
DEFINE-METHOD-COMBINATION -- does anyone care to take a shot at
specifying its expansion?  What does PCL do with it? 

-Sandra
-------

∂25-Jan-89  0840	CL-Compiler-mailer 	DEFMETHOD compile-time processing  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 Jan 89  08:40:16 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA02375g; Wed, 25 Jan 89 08:35:13 PST
Received: by challenger id AA19066g; Wed, 25 Jan 89 08:31:05 PST
Date: Wed, 25 Jan 89 08:31:05 PST
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8901251631.AA19066@challenger>
To: sandra%defun@cs.utah.edu
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Compiler@SAIL.Stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 24 Jan 89 18:43:21 MST <8901250143.AA20013@defun.utah.edu>
Subject: DEFMETHOD compile-time processing

   From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
   Date: Tue, 24 Jan 89 18:43:21 MST

   >     * Do the compile-time call to ADD-METHOD only if the DEFMETHOD appears at
   >       top-level in a null lexical environment.  This would be consistent with
   >       the treatment of DEFMACRO in proposal DEFINING-MACROS-NON-TOP-LEVEL.
   > 
   > I don't consider this solution very satisfying, because it hides the problem.
   > It is possible to represent functions for the remote environment by normal
   > functions if the lexical environment is null, but still, they can't be
   > executed. The problem remains. 

   This may not be very satisfying, but it is probably the only practical
   solution.  We have already had a lot of debate on this regarding
   DEFMACRO and the other defining macros.  A number of people raised
   very strong objections to things like DEFMACRO causing the definition
   to appear in the compile-time environment when buried inside a control
   construct such as IF, or inside a DEFUN.  I don't see any reason why
   those same arguments are not just as applicable to the CLOS defining
   macros. 


   It seems exceedingly unlikely that we compiler people would be able to
   agree on any major reversal of the current proposal on issue
   DEFINING-MACROS-NON-TOP-LEVEL in the 6 weeks or so we have remaining.
   It also seems unlikely that you CLOS people are going to have the time
   to work out any alternative semantics before then.  Even if we did
   have more time to work out alternatives, to me it seems that
   restricting the compile-time magic to top-level situations is the
   simplest solution for all of us.  I don't see that it would affect
   other parts of CLOS, and it would just allow us to take the description
   of the compile-time behavior of DEFMETHOD directly from the MOP
   document. 

Even if we decide to take this stand, the problem won't be entirely solved.
Metaprogrammers won't be able to blindly get their paws on a method object,
and do something that will cause the method-function to be called. If the
method-function is a remote environment function, it may not be able to run in
the local environment. I consider the semantics of the macros and the
representation of remote environment objects being two distincts issues. My
objections were not directed at the semantics issue, but at the representation
issue. I expect that other CLOS members will give opinions on the semantics
issue. 

   Incidentally, I notice that the same considerations also affect
   DEFCLASS and DEFGENERIC, both of which also want to create functional
   objects.  The MOP document doesn't seem to say anything about
   DEFINE-METHOD-COMBINATION -- does anyone care to take a shot at
   specifying its expansion?  What does PCL do with it? 

That's right, all those macros create functional object, therefore are subject
to the ruling concerning macros in non null lexical environment.

Patrick.


∂26-Jan-89  1653	CL-Compiler-mailer 	Re: DEFMETHOD compile-time processing   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 26 Jan 89  16:53:20 PST
Received: by ti.com id AA14157; Thu, 26 Jan 89 18:47:38 CST
Received: from Kelvin by tilde id AA23034; Thu, 26 Jan 89 18:38:20 CST
Message-Id: <2810853419-16115524@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 26 Jan 89  18:36:59 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Patrick Dussud <dussud@lucid.com>
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Compiler@SAIL.Stanford.edu
Subject: Re: DEFMETHOD compile-time processing
In-Reply-To: Msg of Tue, 24 Jan 89 09:19:45 PST from Patrick Dussud <dussud@lucid.com>

> The general issue that we try to address is that it should be possible for
> some implementations to precompute a certain number of characteristic of CLOS
> programs at compile-file time. These precomputation involve metaobjects
> (looking at user class definitions, method object, generic functions) in a
> state that should be close enough to their state when the program is loaded in
> the remote environment. It is not generally possible to simulate the remote
> environment as far as running remote code. Therefore, precomputation at
> compile time, by doing metaprogramming on remote environment objects is more
> restrictive that doing metaprogramming on local environment objects. However,
> we don't want to introduce two distinct metaprogrammings. Chapter 3 is trying
> to unify remote and local metaprogramming. All the side effect that are done
> when the program is loaded, is simulated in the remote environment(
> Add-method, ensure-class...).

I think I see the principle you're presenting here, but I'm still not
clear on how it applies to this case.  The calls to MAKE-METHOD-LAMBDA and
ADD-METHOD are done by the implementation of the DEFMETHOD macro or its
expansion, and the Meta-Object Protocol doesn't specify any intermediate
points at which the user can get involved.  Under what circumstances would
the user know or care whether the compiler called ADD-METHOD?  Sure, I
suppose that a macro could use ENSURE-GENERIC-FUNCTION to look up the
compile-time definition, invoke FIND-METHOD or GENERIC-FUNCTION-METHODS,
and then look at the method objects, but is there really any reason to
want to do that?  Given the precedent that certain operations are not
valid on uninitialized objects or un-finalized classes, who would be hurt
if we said that FIND-METHOD and GENERIC-FUNCTION-METHODS were not valid on
generic functions in the remote environment?

Looking some more at pages 3-16 and 3-17, I think it's interesting that it
doesn't really say anything about compilation, just about the side effects
of what the compiler does.  Presumably the lambda expression computed at
compile time by MAKE-METHOD-LAMBDA is compiled, and the resulting compiled
function is what is actually used in the run-time call to MAKE-INSTANCE
for the method.

There appears to be an additional problem, though, in that the
compile-time call to MAKE-METHOD-LAMBDA depends on the result of
GENERIC-FUNCTION-METHOD-CLASS, yet it is specified that
GENERIC-FUNCTION-METHOD-CLASS is called again at load time.  If we can't
assume that the value will be the same, then what does that say about the
validity of the compiled method function?  It looks like either you don't
want to do it again at load time, or else you do it again in order to
signal an error if it doesn't match the compile-time value.

Also aside from the question of lexical environments is the issue of
control flow context.  There has been discussion in the compiler committee
that seems to have come to the conclusion that we don't want things like
DEFMACRO side-effecting the compile-time environment if they are embedded
in a function or conditional such that they really happen at some
indeterminate run time rather than when the file is loaded.  The same
consideration would apply to DEFCLASS, DEFGENERIC, and DEFMETHOD.  This
requires being able to conceptually separate the actions needed to compile
the run-time code from the actions simulating what happens at load time.

And yet another issue:  if the user says

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

because he really does want to call that generic function from one of his
macros, does that mean that the compile-time ADD-METHOD in this case needs
to be to the resident installed definition instead of the remote
environment?  Or is this not legal?

∂27-Jan-89  1950	CL-Cleanup-mailer 	Issue: FUNCTION-NAME (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Jan 89  19:49:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 528674; Fri 27-Jan-89 22:47:46 EST
Date: Fri, 27 Jan 89 22:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-NAME (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU
Message-ID: <19890128034814.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

Here is the new proposal for the SETF issue that I put up on slides at
the X3J13 meeting.  It's been refined a bit, according to the
suggestions various people made.

Assuming this remains in the Cleanup subcommittee, perhaps Larry should
put this on the forthcoming letter ballot so we don't necessarily have
to wait until March to deal with it.

Issue:         FUNCTION-NAME

References:    SETF rules for what -place- can be (pp.94-7)
               FBOUNDP function (p.90)
               FMAKUNBOUND function (p.92)
               FUNCTION special form (p.87)
               SYMBOL-FUNCTION and setf of symbol-function (p.90)
               88-002R pages 1-21, 2-21, 2-26, 2-39, 2-44, 2-46, 2-51, and 2-55
               (There are additional references for the MEDIUM and LARGE
                proposals, but they are not listed here.  They're obvious.)

Related issues: SETF-FUNCTION-VS-MACRO, SETF-PLACES (both subsumed by this)

Category:      ADDITION

Edit history:  Version 1, 23-Jan-89, by Moon 
                              (based on discussion at X3J13 meeting)


Problem description:

The Common Lisp Object System needs a well-defined way to relate the name
and arguments of a writer function to those of a reader function, because
both functions can be generic and can have user-defined methods.  The way
that was adopted into Common Lisp when X3J13 voted to accept document
88-002R was to use a list (SETF reader) as the name of the writer function.

Some changes to the non-object-oriented portion of Common Lisp are required
in order to support this.

This issue has three proposals.


Proposal (FUNCTION-NAME:SMALL):
          
  Add a new concept "function-name" (called "function-specifier" in
  88-002R).  A function-name is either a symbol or a 2-element list whose
  first element is the symbol SETF and whose second element is a symbol.
  Implementations are free to extend the syntax of function-names to
  include lists beginning with additional symbols other than SETF.

  Add a new function (FDEFINITION function-name), which returns the
  current global function definition named by function-name, or signals
  an error if there is no global function definition.  This follows all
  the same rules listed for SYMBOL-FUNCTION in CLtL p.90.

  Add SETF of FDEFINITION to change the current global function definition
  named by a function-name.  This follows all the same rules listed for
  SETF of SYMBOL-FUNCTION in CLtL p.90.

  Change the FBOUNDP and FMAKUNBOUND functions, and the FUNCTION special
  form, to accept function-names in place of symbols.  Implementation
  defined extensions to the syntax of function-names cannot use the
  symbol LAMBDA, since FUNCTION already uses that symbol.

  Change the rules for SETF places (CLtL pp.94-7) by adding the following
  clause after all the existing clauses:

   - Any other list whose first element is a symbol, call it reader.
     In this case, SETF expands into a call to the function named by the
     list (SETF reader).  The first argument is the new value and the
     remaining arguments are the values of the remaining elements of
     -place-.  This expansion occurs regardless of whether reader or
     (SETF reader) is defined as a function locally, globally, or not at
     all.  For example,
         (SETF (reader arg1 arg2...) new-value)
     expands into a form with the same effect and value as
         (LET ((#:temp-1 arg1)          ;force correct order of evaluation
               (#:temp-2 arg2)
               ...
               (#:temp-0 new-value))
           (FUNCALL (FUNCTION (SETF reader)) #:temp-0 #:temp-1 #:temp-2...)).

  Change the functions GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE
  to implement the above change to the rules.
         
  Document that a function named (SETF reader) should return its first
  argument as its only value, in order to preserve the semantics of SETF.

  Change the macro DEFGENERIC and the function ENSURE-GENERIC-FUNCTION to
  refer to the function FDEFINITION where they now refer to the function
  SYMBOL-FUNCTION.

  Change the macros DEFCLASS, DEFGENERIC, and DEFMETHOD, the special forms
  GENERIC-FLET and GENERIC-LABELS, and the functions DOCUMENTATION and
  ENSURE-GENERIC-FUNCTION to use the term "function-name" where they now
  use the term "function-specifier" or "function specifier".


Rationale for FUNCTION-NAME:SMALL:

  This is the minimum change to Common Lisp needed to do what 88-002R says
  about (SETF reader).  Giving implementations freedom to extend the syntax
  of function-names allows for current practice.  Changing the name from
  "function-specifier" to "function-name" avoids confusion and improves
  consistency with the rest of the language, at the cost of a few small
  changes to 88-002R.


Proposal (FUNCTION-NAME:MEDIUM):

  Everything in FUNCTION-NAME:SMALL, and in addition:

  Change the DEFUN macro to accept a function-name for its name argument,
  instead of only accepting a symbol.  If function-name is (SETF sym),
  the body is surrounded by an implicit block named sym.


Rationale for FUNCTION-NAME:MEDIUM:

  Keeping DEFUN consistent with DEFMETHOD is a good idea.  Also 88-002R
  says "The name of a generic function, like the name of an ordinary
  function, can be either a symbol or a two-element list whose...", which
  implies this change to DEFUN.


Proposal (FUNCTION-NAME:LARGE):

  Everything in FUNCTION-NAME:MEDIUM, and in addition the following
  numbered points, each of which could be adopted independently,
  except where explicitly noted:

  1. Change the function COMPILE to accept a function-name as its name
  argument.

  2. Change the function DISASSEMBLE to accept a function-name as its name
  argument.

  3. Change the FTYPE, INLINE, and NOTINLINE declarations and proclamations
  to accept function-names, not just symbols, as function names.

  4. Change the FLET and LABELS special forms to accept a function-name in
  the name position, not just a symbol.

  5. Change the TRACE and UNTRACE macros to accept function-names, not just
  symbols, in the function name positions.

  6. Change the ED function to accept (ED function-name) in place of
  (ED symbol).

  7. Change the syntax of a function call to allow a function-name as the
  first element of the list, rather than allowing only a symbol.

  8. Change the DEFMACRO macro and the MACROLET special form to accept a
  function-name in the name position, not just a symbol.  Change the
  MACRO-FUNCTION function to accept function-names, not just symbols.
  Change the last rule for SETF places to use
    ((SETF reader) #:temp-0 #:temp-1 #:temp-2...)
  in place of
    (FUNCALL (FUNCTION (SETF reader)) #:temp-0 #:temp-1 #:temp-2...)
  so that (SETF reader) can be defined as a macro.  This depends on item
  7.  If item 4 is rejected, MACROLET should be stricken from this item.

  9. Add an optional environment argument to FDEFINITION, SETF of
  FDEFINITION, FBOUNDP, and FMAKUNBOUND.  This is the same as the
  &environment argument to a macroexpander.  This argument can be used to
  access local function definitions, to access function definitions in the
  compile-time remote environment, and to modify function definitions in
  the compile-time remote environment.

  10. Change the second, third, fourth, fifth, seventh, and ninth rules for
  SETF places so that they only apply when the function-name refers to the
  global function definition, rather than a locally defined function or
  macro.  (The ninth rule is the one that refers to DEFSETF and
  DEFINE-SETF-METHOD; the other rules listed are the ones that list
  specific built-in functions).  The effect of this change is that SETF
  methods defined for global functions are ignored when there is a local
  function binding; instead, the function named (SETF reader), which may
  have a local function binding, is called.  This change is most useful
  in connection with item 4, but does not actually depend on it.

  11. Clarify that the eighth rule for SETF places (the one for macros)
  uses MACROEXPAND-1, not MACROEXPAND.

Rationale for FUNCTION-NAME:LARGE:

  This extends the new feature throughout the language, in order to make
  things generally more consistent and powerful.  Point by point:

  1,2,3 - one should be able to compile, examine, and make declarations
  about functions regardless of whether they are named with symbols or
  with lists.

  4 - locally defined non-generic SETF functions are a logical companion
  to locally defined generic SETF functions, which can be defined with
  GENERIC-FLET or GENERIC-LABELS.  They make sense on their own, since one
  might define a local reader function and want a local writer function
  to go with it.

  5,6 - one should be able to apply development tools to functions
  regardless of how they are named.  The function DOCUMENTATION was already
  updated to work for function-names by 88-002R.  There might be some
  difficulty with implementation-dependent syntax extensions to TRACE and
  UNTRACE conflicting with this new syntax.

  7 - this restores consistency between the FUNCTION special form and the
  first element of a function call form.

  8 - it seems more consistent to allow macros to be named the same way
  that ordinary functions are named.  However, this might be considered
  redundant with DEFSETF.

  9 - this is not needed by the "chapter 1 and 2" level of CLOS, but might
  be used by the metaobject based implementation of ENSURE-GENERIC-FUNCTION.

  10 - this change was in SETF-FUNCTION-VS-MACRO and makes item 4 more useful.

  11 - this change was in SETF-FUNCTION-VS-MACRO and is a good idea, but
  actually is independent of everything else being proposed here.


Examples:

;This is an example of the sort of syntax 88-002R allows
(defmethod (setf child) (new-value (parent some-class))
  (setf (slot-value 'child parent) new-value)
  (update-dependencies parent)
  new-value)
(setf (child foo) bar)

;If SETF of SUBSEQ was not already built into Common Lisp,
;it could have been defined like this, if the MEDIUM or LARGE
;proposal is adopted.
(defun (setf subseq) (new-value sequence start &optional end)
  (unless end (setq end (length sequence)))
  (setq end (min end (+ start (length new-value))))
  (do ((i start (1+ i))
       (j 0 (1+ j)))
      ((= i end) new-value)
    (setf (elt sequence i) (elt new-value j))))

;The preceding example would have to be defined like this
;if only the SMALL proposal is adopted.  This is a method
;all of whose parameter specializer names are T.
(defmethod (setf subseq) (new-value sequence start &optional end)
  (unless end (setq end (length sequence)))
  (setq end (min end (+ start (length new-value))))
  (do ((i start (1+ i))
       (j 0 (1+ j)))
      ((= i end) new-value)
    (setf (elt sequence i) (elt new-value j))))

;Another example, showing a locally defined setf function
(defun frobulate (mumble)
  (let ((table (mumble-table mumble)))
    (flet ((foo (x)
             (gethash x table))
           ((setf foo) (new x)
             (setf (gethash x table) new)))
      ..
      (foo a)
      ..
      (setf (foo a) b))))

;get-setf-method could implement setf functions by calling
;this function when the earlier rules do not apply
(defun get-setf-method-for-setf-function (form)
  (let ((new-value (gensym))
	(temp-vars (do ((a (cdr form) (cdr a))
			(v nil (cons (gensym) v)))
		       ((null a) v))))
    (values temp-vars
	    (cdr form)
	    (list new-value)
	    `(funcall #'(setf ,(car form)) ,new-value ,@temp-vars)
	    `(,(car form) ,@temp-vars))))


Current practice:

  No implementation supports exactly what is proposed.  Symbolics Genera
  and the TI Explorer support something close to the MEDIUM proposal, but
  differing in a number of details.  Symbolics Genera supports items 1, 2,
  3, 6, and 11, and modified forms of items 5 and 8, of the LARGE proposal.
  Moon considers this proposal's variations from Symbolics current practice
  to be an improvement, although incompatible in some cases.
  
  Many implementations currently support only symbols as function names.

  Symbolics Genera and the TI Explorer have some additional function-name
  syntaxes.

Cost to Implementors:

  The SMALL and MEDIUM proposals are estimated to be no more than 50 lines
  of code and require no changes to the "guts" of the interpreter and
  compiler.  Most of the code for this can be written portably and was
  shown on two slides at the X3J13 meeting.

  Some of the changes in the LARGE proposal are trivial, some require
  the compiler to use EQUAL instead of EQ to compare function names, and
  items 4, 7, and 8 might require a more substantial implementation
  effort.  Even that effort is estimated to be negligible compared to
  the effort required to implement CLOS.

Cost to Users:

  No cost to users, other than program-understanding programs, since this
  is an upward compatible addition.

  As with any language extension, some program-understanding programs may
  need to be enhanced.  A particular issue here is programs that assume
  that all function names are symbols.  They may use GET to access
  properties of a function name or use EQ or EQL (perhaps via MEMBER or
  ASSOC) to compare function names for equality.  Such programs will need
  improvement before they can understand programs that use the new feature,
  but otherwise they will still work.

Cost of non-adoption:

  We would have to make some other language change since the language
  became inconsistent when 88-002R was adopted.

Performance impact:

  This has no effect on performance of compiled code.  It might slow
  down the compiler and interpreter but not by very much.

Benefits:

  CLOS will work as designed.

Esthetics:

  Some people dislike using anything but symbols to name functions.
  Other people would prefer that if the change is to be made at all,
  the LARGE proposal be adopted so that the language is uniform in its
  treatment of the new extended function names.  Other proposals for
  how to deal with SETF in CLOS were considerably less esthetic,
  especially when package problems are taken into account.
  
  SETF would be more esthetic, but less powerful, if it had only the
  proposed setf functions and did not have setf macros.  Such a major
  incompatible change is of course out of the question; however, if setf
  functions are stressed over setf macros, SETF will be much easier to
  teach.

Discussion:

  Moon supports at least FUNCTION-NAME:MEDIUM.  He does not necessarily
  approve of all parts of FUNCTION-NAME:LARGE.

∂29-Jan-89  1325	Common-Lisp-Object-System-mailer 	Re: Issue: FUNCTION-NAME (Version 1)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 29 Jan 89  13:24:54 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
	id AA22781; Sun, 29 Jan 89 14:23:25 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA23486; Sun, 29 Jan 89 14:22:46 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901292122.AA23486@defun.utah.edu>
Date: Sun, 29 Jan 89 14:22:45 MST
Subject: Re: Issue: FUNCTION-NAME (Version 1)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Fri, 27 Jan 89 22:48 EST

On the whole, I like this presentation much better than either of the
other two writeups that were circulated previously.  I suspect that it
might be necessary to vote on each of the items in the LARGE proposal
individually, though.  I think I would support items 1, 2, and 11, and
don't have any particular objections to 3, 5, and 6.  For item 4, if
consistency with GENERIC-FLET and GENERIC-LABELS is an object, another
alternative is to change those two special forms to be like ordinary
FLET and LABELS, instead of vice versa.

-Sandra
-------

∂30-Jan-89  0720	CL-Cleanup-mailer 	Issue: FUNCTION-NAME (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Jan 89  07:20:34 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 529874; Mon 30-Jan-89 10:18:34 EST
Date: Mon, 30 Jan 89 10:18 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-NAME (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU,
    Common-Lisp-Object-System@SAIL.STANFORD.EDU
In-Reply-To: <19890128034814.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <890130101826.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

I'm still thinking about this, but while I am I wanted point out that
MEDIUM is unacceptable to me because I don't think FLET and DEFUN should
disagree on what they permit as defined names. If FLET were added to
MEDIUM, I suspect I'd think it was an internally consistent position.

LARGE has an appeal to me in general, but I'm still mulling over 
the specifics.

I'll reply in more detail later.

∂30-Jan-89  1003	Common-Lisp-Object-System-mailer 	Issue: FUNCTION-NAME (Version 1)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Jan 89  10:03:07 PST
Received: from Semillon.ms by ArpaGateway.ms ; 30 JAN 89 10:00:38 PST
Date: Mon, 30 Jan 89 10:00 PST
From: Gregor.pa@Xerox.COM
Subject: Issue: FUNCTION-NAME (Version 1)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU,
 Common-Lisp-Object-System@SAIL.STANFORD.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <19890128034814.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890130180031.2.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no

I support FUNCTION-NAME:MEDIUM and may support LARGE once I think about
it some more.

As I explained in Hawaii, support for either of these is based on the
:conc-name bugs being removed from the condition system.  Of course, I
believe the best way to do that is to CLOSify it.
-------

∂01-Feb-89  1034	Common-Lisp-Object-System-mailer 	editorial comments on chapter 3
Received: from ti.com by SAIL.Stanford.EDU with TCP; 1 Feb 89  10:34:04 PST
Received: by ti.com id AA05320; Wed, 1 Feb 89 12:32:56 CST
Received: from Kelvin by tilde id AA23091; Wed, 1 Feb 89 12:19:06 CST
Message-Id: <2811349106-616742@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 1 Feb 89  12:18:26 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Gregor.pa@Xerox.COM
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu
Subject: editorial comments on chapter 3

Following are some questions, comments, and suggestions about Meta Object
Protocol draft 10 [document 89-003 dated 12/15/88].  This message is limited to
comments on the document itself; questions about the protocol design will be
raised in separate messages to follow.


page 3-9 -- class METAOBJECT is shown as a subclass of FUNCTION; that must
be a mistake since it would imply that class objects and slot definitions
are funcallable.

p. 3-16 and 3-17 - don't the calls to ENSURE-GENERIC-FUNCTION require a
:LAMBDA-LIST argument?

Generic function EFFECTIVE-SLOT-DEFINITION-CLASS is mentioned on pages
3-24, 3-45, and 3-47, but it is not included in the individual function
specifications.

On page 3-24, it appears that "class finalization protocol" and "instance
structure protocol" ought to be section headings.

Bottom of page 3-25 "location must be a positive integer" -- does that
mean not negative or greater than zero?

Page 3-26 mentions functions STANDARD-INSTANCE-ACCESS,
FUNCALLABLE-STANDARD-INSTANCE-ACCESS, and STRUCTURE-INSTANCE-ACCESS,
which are not detailed later.

p. 3-26, SET-FUNCALLABLE-INSTANCE --> SET-FUNCALLABLE-INSTANCE-FUNCTION

p. 3-27 -- FUNCALLABLE-STANDARD-CLASS is mentioned in several places, but
there is still no definition of just what it is.

p. 3-33 - Shouldn't ADD-METHOD be specified to alter the method object by
storing the value to be returned by METHOD-GENERIC-FUNCTION?  I assume
that "if the method object is a method object of another generic function
..." means to check the value returned by METHOD-GENERIC-FUNCTION before
storing the new value?

p. 3-33 not clear what "... readers of the method object are expected to
be invariant ..." means; is this talking about the definition of the
accessor methods or the values that they access?  Or both?

p. 3-35 - Description of ALLOCATE-INSTANCE should mention that it is
called by MAKE-INSTANCE.  (not shown on graph either; the only place this
appears is page 1-41.)

p. 3-41 mentions function UPDATE-DISCRIMINATING-FUNCTION in the "purpose"
section and UPDATE-DISCRIMINATOR-CODE in the "remarks" section; neither of
these is included in the function specifications.  The graph shows
UPDATE-DISCRIMINATING-FUNCTION.  Page 3-67 says that
"UPDATE-DISMCRINATING-FUNCTION" [sic] is called by the SHARED-INITIALIZE
method, but that call isn't shown on the graph.

p. 3-43 COMPUTE-EFFECTIVE-METHOD - doesn't specify the value returned;
presumably a method object.  Is it a STANDARD-METHOD or should there be a
subclass for effective methods?

p. 3-45, 2nd line from bottom, "options is follows" -> "options follows"

p 3-46, the top six lines are a duplicate of material on the previous
page.

p 3-47, COMPUTE-SLOTS -- it isn't clear where the result of this is.  Does
it return a list of effective slots, or does it store the list in the
class object?

p. 3-60 mentions function SLOT-ACCESSES-TO-DEOPTIMIZE which isn't defined
elsewhere.

p. 3-62 "No method applicable to class objects is specified for the
INITIALIZE-INSTANCE generic function."  -- Don't you mean no method more
specific than the one for STANDARD-OBJECT specified on page 2-57?  Surely
that method is applicable.  Likewise on pages 3-65, 3-68, and 3-71.

p. 3-63, fourth bullet, reference to "REMOVE-DIRECT-SUPERCLASS" should be
"REMOVE-DIRECT-SUBCLASS".

p. 3-69 -- the boxed table has the wrong set of function names [should be
METHOD-QUALIFIERS, etc.] and does not list all of the relevant arguments.

p. 3-70 -- the reference to MAP-DEPENDENTS here appears to be bogus since
page 3-22 says that "method combination objects cannot be redefined" and "the
REINITIALIZE-INSTANCE generic function signals an error ...".

p. 3-72 mentions function SLOT-DEFINITION-DOCUMENTATION, which is not listed
among the slot readers on page 3-90; shouldn't that just be DOCUMENTATION ?

p. 3-75, MAKE-METHOD-LAMBDA, says "The generic function and method the method
function will be used with are not required to be the specified ones."  In
fact, the method can not be the actual one since it can't be created until
after MAKE-METHOD-LAMBDA has been used to construct a value for the :FUNCTION
initarg [p. 3-68].  It would be clearer to say that the second argument of
MAKE-METHOD-LAMBDA is a prototype that is only used for dispatching to the
right method.

p. 3-86 mentions a method for (SETF GENERIC-FUNCTION-NAME), but that isn't
listed with the generic functions on page 3-85.  Is it correct to assume that
this is the only one of these accessors which is SETF-able?

p. 3-88 - Does METHOD-GENERIC-FUNCTION return NIL if no ADD-METHOD has
been done?

p. 3-89 -- A number of details yet to be filled in here, like what does
METHOD-COMBINATION-OPTIONS return -- a P-list, or an A-list, or what?

p. 3-90 says that generic function SLOT-DEFINITION-NAME can return "any
object", but page 3-72 says that initialization of a slot signals an
error if the name "is not a symbol which can be used as a variable
name."  So how can the name get to be anything other than a symbol?

p. 3-91 SLOT-DEFINITION-INITARGS -- I assume this returns a list of
symbols?

p. 3-91, 1st line under "Methods", "functions has a" -> "functions have a"

p. 3-91 under the heading "Direct Slot Definition Objects", there are methods
specified for class SLOT-DEFINITION; that should be DIRECT-SLOT-DEFINITION to
be consistent with page 3-73.  Or should it be
STANDARD-DIRECT-SLOT-DEFINITION ? 

The graph shows that REMOVE-DIRECT-METHOD is called by REMOVE-METHOD,
but neither page 3-94 or page 3-97 says that.

p. 99 needs some more words.

p. 3-102 DIRECT-SLOT-DEFINITION-CLASS -- what is this doing in this
place in the document?  It should either be placed in alphabetical order
between pages 47 and 48, or included with the class accessors starting
on page 79.

p. 3-102 -- I assume that DIRECT-SLOT-DEFINITION-CLASS is supposed to
have a specified method for class STANDARD-CLASS that returns class
STANDARD-DIRECT-SLOT-DEFINITION ?

p. 3-109 is unfinished.

The spec doesn't say who calls FINALIZE-INHERITANCE, although the graph shows
it called by ALLOCATE-INSTANCE.  (I'm talking here about finalizing the class
being allocated, not the special cases described in class initialization.)
Presumably ALLOCATE-INSTANCE also calls CLASS-FINALIZED-P, although that is
not shown on the graph.

The organization of this document in a semi-alphabetical order is rather
awkward.  I think it would be better to have the material grouped by subject
and add an index.

∂01-Feb-89  1149	Common-Lisp-Object-System-mailer 	classes and environments  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 1 Feb 89  11:49:15 PST
Received: by ti.com id AA05669; Wed, 1 Feb 89 13:48:24 CST
Received: from Kelvin by tilde id AA25360; Wed, 1 Feb 89 13:36:09 CST
Message-Id: <2811353741-895226@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 1 Feb 89  13:35:41 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Common-Lisp-Object-System@SAIL.Stanford.edu
Subject: classes and environments

Page 3-48 of document 89-003, regarding ENSURE-CLASS, says 
  "If the class name _name_ names a class in the environment :ENVIRONMENT
  use that class."
Need to clarify that this doesn't just mean calling 
  (FIND-CLASS NAME NIL ENVIRONMENT)
because for a remote environment you don't want to use any definition
inherited from the resident environment.  Maybe something like:

(defun ensure-class (name &rest args &key environment &allow-other-keys)
  (let ((class (find-class name nil environment)))
    (apply #'ensure-class-using-class
	   (and (not (null class))
		(not (and (environment-remote-p environment)
			  (eq class (find-class name nil nil))))
		class)
	   name args)))

However, this shadowing of class definitions raises a host of questions that
don't seem to be addressed in this document.  For example, suppose the
resident environment contains the following:

  (defclass plant () ...)
  (defclass tree (plant) ...)
  (defclass oak (tree) ...)

and then I compile a file that contains new definitions for PLANT and OAK,
with the same class inheritance but different slot options; does the
remote definition of OAK inherit from both the resident definition of TREE
and the remote definition of PLANT?  How do you keep track of the fact that
TREE has two different definitions of its superclass?  Our current
implementation handles that by having each class know the _names_ of its
direct supers and the environment in which it is defined, but 3-50 says
that the environment is not to be passed to MAKE-INSTANCE.

Similar questions arise about shadowing of generic function definitions.
When COMPILE-FILE processes a DEFMETHOD for a generic function which is
defined in the resident environment, but not yet shadowed in the remote
environment, does it use the attributes of the resident definition, or does
it create a shadowing definition in the remote environment?  I think you
probably want to use the resident definition, but that would mean that the
:ENVIRONMENT argument of ENSURE-GENERIC-FUNCTION isn't used quite the same
way as it is in ENSURE-CLASS.

∂01-Feb-89  1204	Common-Lisp-Object-System-mailer 	chapter 3 comments   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 1 Feb 89  12:04:02 PST
Received: by ti.com id AA05760; Wed, 1 Feb 89 14:03:15 CST
Received: from Kelvin by tilde id AA25807; Wed, 1 Feb 89 13:53:43 CST
Message-Id: <2811354795-958597@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 1 Feb 89  13:53:15 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Common-Lisp-Object-System@SAIL.Stanford.edu
Subject: chapter 3 comments

Here are some more assorted questions, comments, and suggestions regarding
the Meta Object Protocol, with reference to draft 10 [document 89-003
dated 12/15/88].


Page 3-9 says the "metaclass of every class shown is STANDARD-CLASS ..."
-- shouldn't STRUCTURE-OBJECT be of metaclass BUILT-IN-CLASS or
STRUCTURE-CLASS ?

p. 3-16 - why is the doc string a separate argument to making a method
instead of being included in the function lambda expression?

p 3-19,20 in canonicalized initial-method, can't the :QUALIFIERS entry be
omitted when the value is NIL?

Function STANDARD-INSTANCE-ACCESS appears to have been redefined
incompatibly from the March 1988 draft.  Isn't some primitive function
still needed for access by name?

Regarding ADD-DIRECT-METHOD and SPECIALIZER-DIRECT-METHODS; do we really
have to do that when the specializer is class T?  That seems like it
would be just a waste of space.

I wonder about the methods on ADD-DIRECT-METHOD, REMOVE-DIRECT-METHOD,
SPECIALIZER-DIRECT-METHODS, and SPECIALIZER-DIRECT-GENERIC-FUNCTIONS for
class T; since they apparently exist only to support use of (EQL object)
specializers, wouldn't it be better for those methods to specialize on
class CONS ?

P. 3-36 - APPLY-METHOD-FUNCTION "is called whenever a method function must be
applied to arguments."  -- it surely must be permissible for an implementation
to bypass this for the sake of efficiency.  [Otherwise, how would you invoke
the methods for APPLY-METHOD-FUNCTION ?]

The reason isn't apparent for wanting to separate
UPDATE-DISCRIMINATING-FUNCTION from COMPUTE-DISCRIMINATING-FUNCTION; it seems
like the question of whether the function needs to be recomputed would be
inseparably connected to the nature of the code generated.

How come MAKE-METHOD-LAMBDA returns a lambda expression but
COMPUTE-DISCRIMINATING-FUNCTION returns a function?  Is the assumption
that the code for a generic function will always be computed at run time
rather than compile time?  This isn't true since GENERIC-FLET and
GENERIC-LABELS can often be optimized to fully build the generic
function at compile time when it can be seen that the methods are not
changing at run time.  It seems like COMPUTE-DISCRIMINATING-FUNCTION
should instead return a lambda expression and be called something like
COMPUTE-DISCRIMINATING-LAMBDA.

p. 3.43 - How is COMPUTE-EFFECTIVE-METHOD going to know what value to store
for METHOD-SPECIALIZERS ?  Looks like that needs to be an additional argument.

p. 3-58 EXTRACT-LAMBDA-LIST and p. 3-59 EXTRACT-SPECIALIZER-NAMES - "If the
specialized-lambda-list argument does not have legal syntax, an error is
signalled." -- it isn't clear what amount of error checking is required here.
Is it just expected to report an error if it happens to come across one while
stripping out the specializers, or is it supposed to scan all of the optional
arguments for valid syntax according to page 60 of CLtL?

p. 3-61 FIND-METHOD-COMBINATION - I don't understand this.
DEFINE-METHOD-COMBINATION returns a method combination object which was
created without reference to any particular generic function or argument
values.  Does FIND-METHOD-COMBINATION return something different from that,
or why does it depend on the generic function?

Pages 3-62 and 3-65 specify :AFTER methods on REINITIALIZE-INSTANCE for
classes CLASS and GENERIC-FUNCTION that don't do anything but call
MAP-DEPENDENTS.  Couldn't both cases be handled by a single method on class
DEPENDEE-MIXIN ?

p. 3-62 SHARED-INITIALIZE method - "If class has not previously been
initialized ..." -- How does it determine that?  The March draft had a
CLASS-INITIALIZED-P function which doesn't seem to be here anymore.
Shouldn't any behavior that depends on whether the object is previously
initialized be handled by separate methods for INITIALIZE-INSTANCE and
REINITIALIZE-INSTANCE ?  Also, it seems a little odd to specify using an
:AFTER method on SHARED-INITIALIZE when the primary method won't have
anything to do.  Likewise for GENERIC-FUNCTIONs on page 3-65.

p. 3-66, 3rd bullet: "The :DECLARATIONS argument is a list of declarations.
An error is signalled otherwise." -- The SHARED-INITIALIZE method could make
sure this is a list, but wouldn't it be better to let
COMPUTE-DISCRIMINATING-FUNCTION decide whether the declarations are
meaningful?  A portable SHARED-INITIALIZE method doesn't have any way to know
what declarations the implementation will permit.

p. 3-68 -- since REINITIALIZE-INSTANCE is not permitted for methods, wouldn't
it be simpler to initialize them with an INITIALIZE-INSTANCE method instead
of using SHARED-INITIALIZE?  Likewise for slots on page 3-71.

p. 3-75, the arguments shown for generic function MAKE-METHOD-LAMBDA and its
primary method are not consistent.  One shows <lambda-expression> and the
other shows <lambda-list> and <body>.  Which is right?

p. 3-80, shouldn't the blank space at the bottom of the page contain something
to the effect that the next three functions [CLASS-PRECEDENCE-LIST,
CLASS-PROTOTYPE, and CLASS-SLOTS] signal an error if the class is not
finalized?  Shouldn't that also apply to CLASS-DEFAULT-INITARGS [currently on
page 3-79]?

P. 3-83 specifies a CLASS-PROTOTYPE method for BUILT-IN-CLASS -- is that
really useful?  Is it even meaningful?  Sure, a meaningful prototype could be
returned for a representation class such as FIXNUM or SYMBOL, but what would
be a meaningful prototype for an abstract class such as NUMBER, SEQUENCE,
STREAM, or FUNCTION ?  What should (CLASS-PROTOTYPE (FIND-CLASS 'T)) return?

p. 3-83 says that CLASS-PROTOTYPE returns a value which is maintained by
FINALIZE-INHERITANCE.  The March draft said that the prototype instance did
not have to be allocated until the first time CLASS-PROTOTYPE is called,
which seems like the way it should be.  It is not uncommon to define a class
which will only have one large instance and for which the prototype will
never be needed.  Or maybe page 83 just means that FINALIZE-INHERITANCE
ensures that CLASS-PROTOTYPE won't return an obsolete value?

Regarding SLOT-DEFINITION-INITFORM, since it appears that it would only
be used for debugging or informational purposes, I wonder if it shouldn't
have the same implementation freedom as in proposal FUNCTION-DEFINITION
to not always have to save the source form.

p. 3-117 VALIDATE-SUPERCLASS, reference to whether "the superclass has no
slots" -- does this mean forcing the superclass to be finalized, or is a
traversal of its supers intended?

It seems a little odd that the March draft had a function named
VALID-SUPERCLASS-P which signalled an error, while this draft has a predicate
named VALIDATE-SUPERCLASS; seems like those names are interchanged.

p. 3-35, 3-107 methods for BUILT-IN-CLASS -- "this method signals an
error" - is it permissible for that method to simply not be defined,
resulting in a "no applicable method" error, or does that method actually
have to be defined in a conforming implementation?  Perhaps the real point
is that users should not be permitted to define those methods?

Is the concept of initial methods useful for local generic functions?  The
only use of GENERIC-FUNCTION-INITIAL-METHODS appears to be for
redefinition of named generic functions, which is not applicable to the
anonymous generic functions created by the forms GENERIC-FUNCTION,
GENERIC-FLET, and GENERIC-LABELS.

∂02-Feb-89  1239	CL-Cleanup-mailer 	Issue: FUNCTION-NAME (Version 1)    
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 2 Feb 89  12:39:51 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA12354; Thu, 2 Feb 89 12:39:31 PST
Received: from lukasiewicz.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA28202; Thu, 2 Feb 89 12:36:18 PST
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
	id AA00560; Thu, 2 Feb 89 12:39:12 PST
Date: Thu, 2 Feb 89 12:39:12 PST
From: jrose@Sun.COM (John Rose)
Message-Id: <8902022039.AA00560@lukasiewicz.sun.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU,
        Common-Lisp-Object-System@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Fri, 27 Jan 89 22:48 EST <19890128034814.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-NAME (Version 1)

I favor the FUNCTION-NAME:LARGE proposal, because it defines a single,
useful notion of what a function name is.  The other proposals have
the flaw that there are two kinds of function names:  symbols, and
extended names, with only some of the Lisp primitives accepting the
latter.  This may be convenient for some implementations, for the
short term, but it fragments the language.

I have two other comments on the proposal.


A. Reducing the Cost to Implementors

One observation you could put in the Cost To Implementors section is
that none of the SMALL, MEDIUM, or LARGE proposals require changes to
the "guts" of the interpreter and compiler.  This is because an
implementation is free to use plain symbols internally to name
functions, and use a hack like JonL's SETF:|3.FOO.BAR| mapping to
convert non-symbol names to symbols.  This conversion would be done as a
part of parsing the handful of forms which accept function names, and
then all other passes of the interpreter and compiler (the "guts") would
just see symbols.  (By "parsing" I mean ensuring the right number and
type of syntactic subforms.  You can see that this is a very early and
simple stage of processing.)  Or, Lisp compilers with an "alphatization"
phase could perform function name symbolization at that phase.


B. Finishing the Job of Regularization

I'd like to suggest two additions to your smorgasbord of options in the
FUNCTION-NAME:LARGE section of the proposal.  One addition would
regularize a major special case of functions--lambda expressions.  The
other addition would reaffirm an unstated regularity in the language,
that function names can stand in for functions under FUNCALL and APPLY.
Not only can the treatment of symbolic and setf-list function names be
regularized, but lambda too can be treated in a consistent manner.

If these two points are added to your proposal, the language as a whole
would have a completely uniform treatment of functions and function
names.  Here they are:

13. Declare that any function name is a suitable argument to FUNCALL and
    APPLY.  In such a case, the function name is passed to FDEFINITION,
    and the result (which may in turn be a function name) is called.
    That is, the following two expressions are equivalent, when fname
    is a function name:
	(FUNCALL fname x y)
	  <==>
	(FUNCALL (FDEFINITION fname) x y)
    Note that the definition is sought in the global environment.
    Compare with the rule which applies to a function name occurs,
    syntactically, as the car of a list in code:
	(fname x y)
	  <==>
	(FUNCALL (FUNCTION fname) x y)
	  <==> (under proposal item 9)
	(FUNCALL (FDEFINITION fname <local-environment>) x y)

12. Declare that any lamba expression (i.e., a list whose car is LAMBDA and
    whose cdr is a well-formed lambda argument list and body) is a function
    name.  The effects of the function name accessors on lambda expressions
    are as follows.  FDEFINITION returns an implementation-defined value which
    is the function specified the lambda expression, closed in the global
    environment.  This FDEFINITION value cannot be changed by SETF.
    FBOUNDP always returns T, and MAKUNBOUND is an error.

Esthetics:

The effect of items 11 and 12 is to complete the regularization of
Common Lisp's treatment of functions and function names.  The total
effect of proposal items 1 through 12 is that Lisp has just two notions
for referencing function objects: FUNCTIONS, which are Lisp objects that
directly represent executable code, and FUNCTION NAMES, which can denote
functions.  Symbols, SETF function names, and lambda expressions are all
examples of the latter notion.  The former notion is highly
implementation dependent.  Function names can occur as syntactic
entities in code.  FUNCALL and APPLY work uniformly on both functions
and function names, with a consistent semantics.

Lambda expressions are often thought to denote "anonymous" functions, so
it may seem paradoxical to treat them as names.  The paradox is only
apparent, since the expression itself has the properties of a Lisp
function name: It is (typically) a cons tree which can be read, printed,
and stored in source files, and it denotes a well-defined Lisp function.

Benefit to Users:

Function names are useful for representing objects in remote
environments, because they need not be bound at all times to the same
function, or to any function, and because they are typically stable in
meaning across reads and prints, where plain functions are not.
Programs which deal simultaneously with remote and local environments,
such as CLOS, can probably be simplified, since function names
can be used uniformly, rather than an ad-hoc mixture of functions
and function names.

The language as a whole become more uniform from these additions and
clarifications, making it easier to learn and use.  (See Esthetics.)

Cost to Implementors:

Interpreters which currently have a special case check for application
of lambda expressions would need to modify this check to call
FDEFINITION when a list of any sort is encountered.  Note that all
Common Lisps already must perform some such check, since lambda
expressions can be funcalled (and this is currently a very special case,
the only standard case of a list being funcalled).  This means that
every Lisp already has a place to insert the required call to
FDEFINITION.

In some implementations, FDEFINITION of a lambda expression could be that
lambda-expression itself.  In others featuring a pre-eval codewalk, the
walk would be done by FDEFINITION, which would return an appropriate
closure.

Cost of Non-adoption:

Rather than two notions for function references (functions and function
names), there would be several notions, each corresponding to the valid
inputs for particular group of primitives.  APPLY and FUNCALL would
accept functions, symbolic names, and lambda expressions, but not setf
function names.  FDEFINITION and its kind would accept symbols and setf
function names but not lambda expressions.  If the :LARGE proposal is
not adopted, this fragmentation would also apply to the various syntaxes
involving function names; some names would be acceptable to DEFUN
but not to FLET, etc.

					-- John

∂06-Feb-89  1307	Common-Lisp-Object-System-mailer 	issue SYMBOL-MACROLET-SEMANTICS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 6 Feb 89  13:07:28 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA20453; Mon, 6 Feb 89 14:05:56 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA00450; Mon, 6 Feb 89 14:05:54 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8902062105.AA00450@defun.utah.edu>
Date: Mon, 6 Feb 89 14:05:52 MST
Subject: issue SYMBOL-MACROLET-SEMANTICS
To: cl-cleanup@sail.stanford.edu, common-lisp-object-system@sail.stanford.edu

This proposal, which passed at the January meeting, contains the
phrase: "Specify that the expansion of a symbol macro IS subject to
further macro expansion in the same lexical environment as the symbol
macro invocation." Just to clarify this, does this mean that the
second example from p 2-81 of 88-002R is now incorrect?

-Sandra
-------

∂06-Feb-89  1316	CL-Cleanup-mailer 	issue SYMBOL-MACROLET-SEMANTICS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Feb 89  13:16:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 534374; Mon 6-Feb-89 16:13:53 EST
Date: Mon, 6 Feb 89 16:14 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue SYMBOL-MACROLET-SEMANTICS
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-cleanup@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <8902062105.AA00450@defun.utah.edu>
Message-ID: <19890206211426.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 6 Feb 89 14:05:52 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    This proposal, which passed at the January meeting, contains the
    phrase: "Specify that the expansion of a symbol macro IS subject to
    further macro expansion in the same lexical environment as the symbol
    macro invocation." Just to clarify this, does this mean that the
    second example from p 2-81 of 88-002R is now incorrect?

Yes.

∂07-Feb-89  0819	CL-Windows-mailer 	I/O generic functions     
Received: from ti.com by SAIL.Stanford.EDU with TCP; 7 Feb 89  08:19:17 PST
Received: by ti.com id AA26003; Tue, 7 Feb 89 10:18:11 CST
Received: from Kelvin by tilde id AA12256; Tue, 7 Feb 89 10:04:42 CST
Message-Id: <2811859381-15005799@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 7 Feb 89  10:03:01 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Cleanup@SAIL.Stanford.edu
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Windows@SAIL.Stanford.edu,
        Kimbrough@DSG.csc.ti.com, Bartley@MIPS.csc.ti.com
Subject: I/O generic functions 

It would be nice if the Common Lisp input and output functions could be
defined in terms of primitives which are generic functions so that users
would have a portable way to create their own streams by defining classes
and methods and have those streams be acceptable to the standard I/O
functions.  This would be especially valuable for supporting the
development of window systems for Common Lisp.
 
It may be too late to include this in the standard, but it would be useful
to at least establish some common practice guidelines to avoid unnecessary
incompatibilities between implementations that will want to do something
like this anyway.  In order to get some discussion started, following is a
preliminary outline showing what might be done.
 
Shown below are a few primitive generic functions which would need to have
methods defined for each stream class, and a few more which the user could
either define himself, or use a default method provided by an included
class.  [This does not yet include non-character streams.] Finally, it
shows how the I/O functions of CLtL could be implemented using these
generic functions.  Note that the Common Lisp I/O functions themselves
cannot be made into generic functions because in nearly every case the
stream argument is optional and thus can't be specialized.  Note also that
the existing generic function PRINT-OBJECT is a higher-level operation
since even when the first argument is just a character or string, it still
needs to format the output in accordance with *PRINT-ESCAPE*.


;;;;	Implementation of Common Lisp I/O routines using generic functions

;;;  Generic functions for primitive input operations that must be defined for each stream.

(defgeneric STREAM-READ-CHAR (stream &optional eof-error-p eof-value))
(defgeneric STREAM-UNREAD-CHAR (stream character))
(defgeneric STREAM-LISTEN (stream))

;;;  Other input operations which can be defaulted by including the following class.

(defclass DEFAULT-INPUT-STREAM (stream) ())
(defgeneric STREAM-READ-CHAR-NO-HANG (stream &optional eof-error-p eof-value)
   (:method ((stream default-input-stream) &optional eof-error-p eof-value)
	     (stream-read-char stream eof-error-p eof-value)))
(defgeneric STREAM-PEEK-CHAR (stream &optional eof-error-p eof-value)
  (:method ((stream default-input-stream) &optional (eof-error-p t) eof-value)
	     (let ((character (stream-read-char stream eof-error-p eof-value)))
		 (unless (eql character eof-value)
		   (stream-unread-char stream character))
		 character)))
(defgeneric STREAM-READ-LINE (stream &optional eof-error-p eof-value)
  (:method ((stream default-input-stream) &optional eof-error-p eof-value)
	     (let ((line (make-array 60 :element-type 'string-char :fill-pointer 0)))
		 (loop (let ((character (stream-read-char stream eof-error-p eof-value)))
			   (if (eql character eof-value)
				 (return (values line eof-value))
			     (if (eql character #\newline)
				   (return (values line nil))
				 (vector-push-extend character line))))))))
(defgeneric STREAM-CLEAR-INPUT (stream)
  (:method ((stream default-input-stream)) nil))
(defgeneric STREAM-CLOSE (stream))
(defmethod STREAM-CLOSE ((stream default-input-stream)) nil) ; or is it T?


;;;  Generic functions for primitive output operations that must be defined for each stream.

(defgeneric STREAM-WRITE-CHAR (stream character))
(defgeneric STREAM-START-LINE-P (stream)) ; returns true if positioned at beginning of line.
(defgeneric STREAM-LINE-COLUMN (stream)) ; returns current column number if meaningful, else nil

;;;  Other output operations which can be defaulted by including the following class.

(defclass DEFAULT-OUTPUT-STREAM (stream) ())

(defgeneric STREAM-WRITE-STRING (stream string &optional start end)
  (:method ((stream default-output-stream) string &optional (start 0) end)
	     (let ((limit (or end (length string))))
		 (do ((i start (1+ i)))
		     ((< i limit))
		   (stream-write-char stream (char string i))))
	     string))
(defgeneric STREAM-TERPRI (stream)
  (:method ((stream default-output-stream))
	     (stream-write-char stream #\newline)
	     nil))
(defgeneric STREAM-FRESH-LINE (stream)
   (:method ((stream default-output-stream))
	       (if (stream-start-line-p stream)
		   nil
		 (progn (stream-terpri stream) t))))

(defgeneric STREAM-FINISH-OUTPUT (stream)
  (:method ((stream default-output-stream)) nil))
(defgeneric STREAM-FORCE-OUTPUT (stream)
  (:method ((stream default-output-stream)) nil))
(defgeneric STREAM-CLEAR-OUTPUT (stream)
  (:method ((stream default-output-stream)) nil))

;; useful for pprint and format ~T
(defgeneric STREAM-ADVANCE-TO-COLUMN (stream column) 
   (:method ((stream default-output-stream) column)
	       (let ((current (stream-line-column stream)))
		  (unless (null current)
		     (dotimes (i (- current column))
		        (stream-write-char stream #\space))
		     t))))
	     
(defmethod STREAM-CLOSE ((stream default-output-stream)) nil)

;;;  Internal helper functions [not intended to be standardized]

(proclaim '(inline decode-read-arg))
(defun decode-read-arg (arg)
  (cond ((null arg) *standard-input*)
	((eq arg t) *terminal-io*)
	(t arg)))

(proclaim '(inline decode-print-arg))
(defun decode-print-arg (arg)
  (cond ((null arg) *standard-output*)
	((eq arg t) *terminal-io*)
	(t arg)))


;;;  Common Lisp query functions

(defgeneric INPUT-STREAM-P (stream)
  (:method ((stream default-input-stream)) t)
  (:method ((stream default-output-stream)) nil))

(defgeneric OUTPUT-STREAM-P (stream)
  (:method ((stream default-output-stream)) t)
  (:method ((stream default-input-stream)) nil))

(defgeneric STREAM-ELEMENT-TYPE (stream)
  (:method ((stream default-output-stream)) 'character)
  (:method ((stream default-input-stream)) 'character))


;;;  Common Lisp input functions

(defun READ-CHAR (&optional input-stream (eof-errorp t) eof-value recursive-p)
  (declare (ignore recursive-p)) ; This appears to have been a mistake in CLtL.
  (stream-read-char (decode-read-arg input-stream) eof-errorp eof-value))

(defun PEEK-CHAR (&optional peek-type input-stream (eof-errorp t) eof-value recursive-p)
  (declare (ignore recursive-p))
  (let ((stream (decode-read-arg input-stream)))
    (if (null peek-type)
	(stream-peek-char stream eof-errorp eof-value)
      ...)))

(defun UNREAD-CHAR (character &optional input-stream)
  (stream-unread-char (decode-read-arg input-stream) character))

(defun LISTEN (&optional input-stream)
  (stream-listen (decode-read-arg input-stream)))

(defun READ-LINE (&optional input-stream (eof-error-p t) eof-value recursive-p)
  (declare (ignore recursive-p))
  (stream-read-line (decode-read-arg input-stream) eof-error-p eof-value))

(defun CLEAR-INPUT (&optional input-stream)
  (stream-clear-input (decode-read-arg input-stream)))

(defun READ-CHAR-NO-HANG (&optional input-stream (eof-errorp t) eof-value recursive-p)
  (declare (ignore recursive-p))
  (stream-read-char-no-hang (decode-read-arg input-stream) eof-errorp eof-value))


;;;  Common Lisp output functions

(defun WRITE-CHAR (character &optional output-stream)
   (stream-write-char (decode-print-arg output-stream) character))

(defun FRESH-LINE (&optional output-stream)
  (stream-fresh-line (decode-print-arg output-stream)))

(defun WRITE-STRING (string &optional output-stream &key (start 0) end)
  (stream-write-string (decode-print-arg output-stream) string start end))

(defun WRITE-LINE (string &optional output-stream &key (start 0) end)
  (let ((stream (decode-print-arg output-stream)))
    (stream-write-string stream string start end)
    (stream-terpri stream)
    string))

(defun FORCE-OUTPUT (&optional stream)
  (stream-force-output (decode-print-arg stream)))

(defun FINISH-OUTPUT (&optional stream)
  (stream-finish-output (decode-print-arg stream)))

(defun CLEAR-OUTPUT (&optional stream)
  (stream-clear-output (decode-print-arg stream)))

∂07-Feb-89  1016	Common-Lisp-Object-System-mailer 	Re: I/O generic functions 
Received: from hplms2.hpl.hp.com by SAIL.Stanford.EDU with TCP; 7 Feb 89  10:15:49 PST
Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Tue, 7 Feb 89 10:14:20 pst
Received: from loopback by hplwhh.HPL.HP.COM; Tue, 7 Feb 89 10:13:10 pst
Full-Name: Warren Harris
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Windows@SAIL.Stanford.edu,
        Kimbrough@DSG.csc.ti.com, Bartley@MIPS.csc.ti.com,
        CL-Cleanup@SAIL.Stanford.edu
Subject: Re: I/O generic functions 
In-Reply-To: Your message of "Tue, 07 Feb 89 10:03:01 CST."
             <2811859381-15005799@Kelvin> 
Date: Tue, 07 Feb 89 10:13:06 PST
Message-Id: <26670.602878386@hplwhh>
From: Warren Harris <harris%hplwhh@hplabs.hp.com>

I just wanted to point out that there is an entire section of Sonya Keene's
book "Object Oriented Programming in Common Lisp" dedicated to an
implementation of streams as objects.  Perhaps this implementation would be
a good starting point for a formal proposal on generic i/o routines.  Can
anyone summarize what might be missing in a "real" implementation?

Warren

∂07-Feb-89  1033	Common-Lisp-Object-System-mailer 	Re: I/O generic functions 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Feb 89  10:33:15 PST
Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 534937; Tue 7-Feb-89 13:29:52 EST
Date: Tue, 7 Feb 89 13:28 EST
From: Sonya Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: I/O generic functions 
To: harris%hplwhh@hplabs.hp.com
cc: Gray@DSG.csc.ti.com, Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Windows@SAIL.Stanford.edu,
    Kimbrough@DSG.csc.ti.com, Bartley@MIPS.csc.ti.com, CL-Cleanup@SAIL.Stanford.edu
In-Reply-To: <26670.602878386@hplwhh>
Message-ID: <19890207182849.1.SKEENE@JUNCO.SCRC.Symbolics.COM>

    Date: Tue, 07 Feb 89 10:13:06 PST
    From: Warren Harris <harris%hplwhh@hplabs.hp.com>

    I just wanted to point out that there is an entire section of Sonya Keene's
    book "Object Oriented Programming in Common Lisp" dedicated to an
    implementation of streams as objects.  Perhaps this implementation would be
    a good starting point for a formal proposal on generic i/o routines.  Can
    anyone summarize what might be missing in a "real" implementation?

    Warren

I'd like to recommend against this idea!   My goals in developing that
example for my book were very different from your goals in designing a
real stream implementation.    I wanted to keep the example as simple as
possible, while illustrating a lot of the sharing that can happen when
streams are done in an object-oriented way.   My main interest was not
in doing streams the right way, but just to find something that could
illustrate good modularity and inheritance.   

I agree that streams are ripe for an object-oriented design, but your
design should probably start from scratch.   Actually, there are some
object-oriented streams implementations out there (Symbolics has one,
and there must be others), and you could look into those as a starting
point.  

Sonya 

∂07-Feb-89  1341	Common-Lisp-Object-System-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Feb 89  13:41:39 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA05101; Tue, 7 Feb 89 14:39:59 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA00904; Tue, 7 Feb 89 14:39:57 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8902072139.AA00904@defun.utah.edu>
Date: Tue, 7 Feb 89 14:39:55 MST
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY
To: Common-Lisp-Object-System@SAIL.Stanford.edu
Cc: CL-Compiler@SAIL.Stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Thu, 26 Jan 89  18:36:59 CST

Just a reminder -- at last month's meeting there was a comment that the
part of this proposal dealing with CLOS is "wrong".  Can somebody please
supply more specifics about the complaint and/or suggest some alternate
wording?  If I don't hear from anybody, the existing wording will remain.

-Sandra
-------

∂07-Feb-89  2005	CL-Cleanup-mailer 	I/O generic functions     
Received: from PORSCHE.SCRC.Symbolics.COM ([128.81.41.69]) by SAIL.Stanford.EDU with TCP; 7 Feb 89  19:39:53 PST
Received: from OWL.SCRC.Symbolics.COM by PORSCHE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 230; Tue 7-Feb-89 22:03:09 EST
Date: Tue, 7 Feb 89 22:02 EST
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: I/O generic functions 
To: David N Gray <Gray@DSG.csc.ti.com>
cc: CL-Cleanup@SAIL.Stanford.edu, Common-Lisp-Object-System@SAIL.Stanford.edu,
    CL-Windows@SAIL.Stanford.edu, Kimbrough@DSG.csc.ti.com, Bartley@MIPS.csc.ti.com
In-Reply-To: <2811859381-15005799@Kelvin>
Message-ID: <19890208030248.1.MMCM@OWL.SCRC.Symbolics.COM>

This is the right sort of start.  I have a few observations which are
not meant to be comprehensive.  They might help stimulate further
careful design.

STREAM-LISTEN is actually not mandatory: you can implement it using
READ-CHAR-NO-HANG and UNREAD-CHAR.

If people are going to start defining well behaved streams, some
protocols need to be firmed up.  For instance, if LISTEN is true, must
READ-CHAR-NO-HANG return a character?  Or is it only that
READ-CHAR-NO-HANG returns a character or clears the LISTEN condition?
You can see the difference in the behavior of an encapsulated stream
with escape characters.  In the one case, LISTEN can just do LISTEN on
the inside stream, which is presumably fast (e.g. checks some network
buffer pointers).  If the buffer contains only the start of an escape
sequence, READ-CHAR-NO-HANG will still not return a character.  In the
other case, LISTEN must run the entire decoding machinery right away and
unread any character it produces.  The key decision is whether you want
LISTEN to be complete or efficient.

Wouldn't it be better to have just one centralized implementation of
eof-error-p eof-value handling?  The internal stream methods could obey
just one protocol for returning EOF which the outer would process
independently.

∂08-Feb-89  1249	Common-Lisp-Object-System-mailer 	omissions from chapter 3  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 8 Feb 89  12:49:36 PST
Received: by ti.com id AA02394; Wed, 8 Feb 89 14:48:22 CST
Received: from Kelvin by tilde id AA18494; Wed, 8 Feb 89 14:39:33 CST
Message-Id: <2811962330-5851625@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 8 Feb 89  14:38:50 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Gregor.pa@Xerox.COM
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu
Subject: omissions from chapter 3

I'm puzzled by some of the things that were in document 88-003 [the
March draft of the MOP] but disappeared in document 89-003 [December].

CHECK-INITARGS and DEFAULT-INITARGS [88-003 p. 3-12] have disappeared.
OK, maybe these don't need to be standardized, but note that pages 1-41
and 42 will need to be updated -- it mentions DEFAULT-INITARGS and
CLASS-SLOT-INITARGS, which has also disappeared.

Also gone are CLASS-DIRECT-SLOT-INITARGS [p. 3-17], CLASS-SLOT-INITARGS,
CLASS-DIRECT-INITARGS, and CLASS-INITARGS [p. 3-18]; is that
intentional?

Generic functions VALID-CLASS-OPTION-P, VALID-SLOT-DESCRIPTION-P, and
VALID-SLOT-OPTION-P [all on page 3-15 of 88-003] are gone.  The new
document doesn't discuss how extensions to the options are to be
handled.  Is the idea that all class and slot options appearing in a
DEFCLASS will simply be passed on to MAKE-INSTANCE and it will decide
what is legal?  If so, does that mean that MAKE-INSTANCE of a class will
see
    :DOCUMENTATION '"string"
or
    :DOCUMENTATION '("string")
?

Starting on page 3-43 of 88-003 is a three page discussion of the
expansion of DEFINE-METHOD-COMBINATION, while document 89-003 has
nothing.  Should I assume from this that you have decided that the old
description was wrong, but don't yet know what the right answer is?

The "instance access optimization protocol" [88-003 p. 56] has
disappeared.  We had already implemented
DEFINE-INSTANCE-ACCESS-OPTIMIZATION, OPTIMIZE-SLOT-VALUE,
OPTIMIZE-SETF-SLOT-VALUE, STANDARD-INSTANCE-ACCESS, and 
(SETF STANDARD-INSTANCE-ACCESS), and it all seemed to be working quite
nicely.  This seems like a significant loss in functionality for the
metaclass writer.

∂09-Feb-89  1304	Common-Lisp-Object-System-mailer 	local generic functions   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 9 Feb 89  13:04:44 PST
Received: by ti.com id AA06876; Thu, 9 Feb 89 15:03:34 CST
Received: from Kelvin by tilde id AA17405; Thu, 9 Feb 89 14:46:33 CST
Message-Id: <2812049147-11196035@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 9 Feb 89  14:45:47 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Common-Lisp-Object-System@SAIL.Stanford.edu
Subject: local generic functions

Is the list returned by SPECIALIZER-DIRECT-GENERIC-FUNCTIONS supposed to
include local functions defined by GENERIC-FLET or anonymous functions
created by the GENERIC-FUNCTION macro?  I haven't seen anything that says
they are an exception, but if they need to be recorded here, then there
would be no way to ever garbage-collect them once created.

∂10-Feb-89  1257	Common-Lisp-Object-System-mailer 	Re: issue MACRO-ENVIRONMENT-EXTENT, version 1 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 10 Feb 89  12:57:19 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA25181; Fri, 10 Feb 89 13:55:39 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA01721; Fri, 10 Feb 89 13:55:37 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8902102055.AA01721@defun.utah.edu>
Date: Fri, 10 Feb 89 13:55:36 MST
Subject: Re: issue MACRO-ENVIRONMENT-EXTENT, version 1
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore),
        cl-compiler@sail.stanford.edu,
        common-lisp-object-system@sail.stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Fri, 13 Jan 89  17:33:28 CST

> Date: Fri, 13 Jan 89  17:33:28 CST
> From: David N Gray <Gray@DSG.csc.ti.com>
> 
> > Proposal MACRO-ENVIRONMENT-EXTENT:INDEFINITE:
> > 
> > State that macro environment objects received with the &ENVIRONMENT
> > argument of a macro function have indefinite extent.
> 
> That's fine for macro definitions, but this will not work for environments
> containing class definitions.  The compiler needs to be able to know when
> those compile-time class definitions are no longer needed so that they can
> be unlinked from the class data structures.
> 
> This issue has a strong relationship with issue
> SYNTACTIC-ENVIRONMENT-ACCESS since it proposes extending the use of
> environments in ways that would make anything other than
> MACRO-ENVIRONMENT-EXTENT:DYNAMIC difficult to retro-fit to existing
> implementations.

I am still trying to understand all of the implications of what CLOS
wants to do with macro expansion environments.  To me, it seems like this
whole business would be difficult to retro-fit to existing implementations,
regardless of what we decide to do about the extent of macro environments.

My current mental picture of how this is supposed to work is that
compile-time environment objects are supposed to contain a pointer to
a database of all the class definitions.  I don't see why the compiler
would need to unlink anything; when there are no longer any pointers
to the database, it would get "unlinked" automatically during garbage
collection, just like any other object, right?

-Sandra
-------

∂10-Feb-89  1449	CL-Compiler-mailer 	Re: issue MACRO-ENVIRONMENT-EXTENT, version 1
Received: from PORSCHE.SCRC.Symbolics.COM ([128.81.41.69]) by SAIL.Stanford.EDU with TCP; 10 Feb 89  14:49:27 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by PORSCHE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 868; Fri 10-Feb-89 17:12:57 EST
Date: Fri, 10 Feb 89 17:13 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue MACRO-ENVIRONMENT-EXTENT, version 1
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: David N Gray <Gray@DSG.csc.ti.com>, cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <8902102055.AA01721@defun.utah.edu>
Message-ID: <19890210221326.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 10 Feb 89 13:55:36 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    I am still trying to understand all of the implications of what CLOS
    wants to do with macro expansion environments.  

Resolving that is dependent on resolving EVAL-WHEN.  You either already
have the Symbolics proposal for EVAL-WHEN, or will have it soon (I'm not
sure if Kent sent it yet).  I think only Sandra will see this draft, the
mailing lists should see it shortly afterwards.

						    To me, it seems like this
    whole business would be difficult to retro-fit to existing implementations,
    regardless of what we decide to do about the extent of macro environments.

My opinion is that anything in CLOS that seems to depend on indefinite
extent for macro environments is broken and needs to be fixed.  It's not
broken because of the environment extent, but for other reasons.

Thus I believe in dynamic extent for environments.

    > Date: Fri, 13 Jan 89  17:33:28 CST
    > From: David N Gray <Gray@DSG.csc.ti.com>
    > That's fine for macro definitions, but this will not work for environments
    > containing class definitions.  The compiler needs to be able to know when
    > those compile-time class definitions are no longer needed so that they can
    > be unlinked from the class data structures.

    My current mental picture of how this is supposed to work is that
    compile-time environment objects are supposed to contain a pointer to
    a database of all the class definitions.  

"pointer" is a key word that usually means you are thinking at too low
a level of abstraction.  Also that mental picture may or may not be wrong,
depending on how we resolve how CLOS metaobjects work at compile time,
which depends on resolving EVAL-WHEN first.

					      I don't see why the compiler
    would need to unlink anything; when there are no longer any pointers
    to the database, it would get "unlinked" automatically during garbage
    collection, just like any other object, right?

When Gray said "unlink" he was referring to the links between subclasses
and superclasses, not the links between names and objects.

∂12-Feb-89  1827	Common-Lisp-Object-System-mailer 	Re: issue MACRO-ENVIRONMENT-EXTENT, version 1 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 12 Feb 89  18:26:21 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA03819; Sun, 12 Feb 89 19:21:55 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA02883; Sun, 12 Feb 89 19:20:31 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8902130220.AA02883@defun.utah.edu>
Date: Sun, 12 Feb 89 19:20:29 MST
Subject: Re: issue MACRO-ENVIRONMENT-EXTENT, version 1
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
        David N Gray <Gray@DSG.csc.ti.com>, cl-compiler@SAIL.STANFORD.EDU,
        common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Fri, 10 Feb 89 17:13 EST

Having seen the new proposal for EVAL-WHEN, I still don't have any idea
why the extent of macro environment objects depends on it.  Can you
explain the connection?

Also, I don't think anybody is arguing for requiring environments to
have indefinite extent on the grounds that CLOS requires it.  (The
argument is that it's generally useful and for general symmetry with
every other kind of Lisp data object having indefinite extent.) Just
the opposite -- David Gray's question was whether that requirement
would complicate the implementation of CLOS. 

At the January meeting, Gregor made a verbal suggestion that perhaps
implementations ought to be allowed to support only dynamic extent, but
that we should add a function to make a copy of the environment object
which would have indefinite extent.  If the problem is indeed that
certain things must be "unlinked" at the end of compilation, it
doesn't seem like this would solve the problem.

-Sandra
-------

∂14-Feb-89  2314	Common-Lisp-Object-System-mailer 	CLOS Mailing List    
Received: from a.cs.uiuc.edu by SAIL.Stanford.EDU with TCP; 14 Feb 89  23:14:35 PST
Received: from p.cs.uiuc.edu by a.cs.uiuc.edu with SMTP
	(5.61+/IDA-1.2.8) id AA07752; Wed, 15 Feb 89 01:12:50 -0600
Received: by p.cs.uiuc.edu (UIUC-5.52/9.7)
	id AA07620; Wed, 15 Feb 89 01:05:50 CST
Date: Wed, 15 Feb 89 01:05:50 CST
From: foote@p.cs.uiuc.edu (Brian Foote)
Message-Id: <8902150705.AA07620@p.cs.uiuc.edu>
To: common-lisp-object-system@sail.stanford.edu
Subject: CLOS Mailing List

Please add my name to your mailing list.
foote@p.cs.uiuc.edu
Brian Foote, Dept. of CS, U. of Illinois, Urbana, IL  61801
(217) 333-3411

∂16-Feb-89  1203	Common-Lisp-Object-System-mailer 	effective methods question
Received: from ti.com by SAIL.Stanford.EDU with TCP; 16 Feb 89  12:03:49 PST
Received: by ti.com id AA04355; Thu, 16 Feb 89 14:02:29 CST
Received: from Kelvin by tilde id AA14786; Thu, 16 Feb 89 13:48:07 CST
Message-Id: <2812650462-8421010@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 16 Feb 89  13:47:42 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Common-Lisp-Object-System@SAIL.Stanford.edu
Subject: effective methods question

Is the list returned by functions SPECIALIZER-DIRECT-METHODS and
GENERIC-FUNCTION-METHODS intended to include effective methods, or just
the explicitly defined methods?

∂16-Feb-89  1249	Common-Lisp-Object-System-mailer 	DEFSTRUCT and DEFCLASS    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 16 Feb 89  12:49:30 PST
Received: by ti.com id AA04642; Thu, 16 Feb 89 14:48:08 CST
Received: from Kelvin by tilde id AA16733; Thu, 16 Feb 89 14:41:31 CST
Message-Id: <2812653665-8613469@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 16 Feb 89  14:41:05 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Common-Lisp-Object-System@SAIL.Stanford.edu
Cc: masinter.pa@Xerox.COM
Subject: DEFSTRUCT and DEFCLASS

I'm confused about the use of metaclass STRUCTURE-CLASS; a cleanup
proposal to clarify this is needed.  In X3J13 correspondence, I've seen
mentions of using DEFCLASS instead of DEFSTRUCT to create structures,
but document 88-002R does not say that you can do that.  On the other
hand, it doesn't say that you can't either.  Basically the question is
whether
  (DEFSTRUCT ... (:METACLASS STRUCTURE-CLASS))
is legal and, if so, just what it means.

What the document _does_ say on page 1-15:

  "Calling MAKE-INSTANCE to create an instance of a built-in class
  signals an error.  Calling SLOT-VALUE on an instance of a built-in
  class signals an error."

No such error is specified for STRUCTURE-CLASS; is that intended to
imply that SLOT-VALUE of a structure _is_ legal?  Page 2-80 does not
shed any light on this.  It isn't until page 3-107 of document 89-003
that we see that, yes, it is supposed to be supported.

Also on page 1-15:

  "Calling MAKE-INSTANCE to create an instance of STRUCTURE-CLASS
  signals an error."

I had always thought that this meant that MAKE-INSTANCE couldn't be used
to create an instance of a structure type, but looking at it again now,
it looks like it just means that you can't create the structure type by
(MAKE-INSTANCE 'STRUCTURE-CLASS); perhaps a clarification of the wording
would be in order.  But since DEFCLASS uses ENSURE-CLASS which uses
MAKE-INSTANCE, does that imply that DEFCLASS can't be used either?

Page 3-35 of 89-003 does specify an ALLOCATE-INSTANCE method for
STRUCTURE-CLASS, which would imply that MAKE-INSTANCE _can_ be used to
create instances of structure types.

But if chapter 3 is not going to make it into the standard, then it is
even more important to clarify this in chapters 1 and 2  -- is the use
of DEFCLASS, MAKE-INSTANCE, SLOT-VALUE etc. for structures

  * Required to be supported?   or

  * Required to signal an error?  or

  * A permissible extension?

Also, if (DEFSTRUCT ... (:METACLASS STRUCTURE-CLASS)) is permitted, what
limitations or extensions apply to the slot and class options?  Does it
create a MAKE-... function?  Does it accept a :CONSTRUCTOR class option?
What kind of accessors does it create -- inline functions like
DEFSTRUCT, or generic function methods like STANDARD-CLASS?  
Is :ALLOCATION :CLASS permitted?

∂16-Feb-89  1348	Common-Lisp-Object-System-mailer 	CLOS questions  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 16 Feb 89  13:48:40 PST
Received: by ti.com id AA04891; Thu, 16 Feb 89 15:47:16 CST
Received: from Kelvin by tilde id AA18131; Thu, 16 Feb 89 15:31:24 CST
Message-Id: <2812656663-8793592@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 16 Feb 89  15:31:03 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Common-Lisp-Object-System@SAIL.Stanford.edu
Subject: CLOS questions

I have still more questions, this time about chapters 1 and 2.


Page 1-15 of 88-002R says that 

  "Each class that corresponds to a predefined Common Lisp type
  specifier can be implemented in one of three ways ...  a standard
  class ..., a structure class ..., or a built-in class ..."

Shouldn't this also permit the possibility of other
implementation-specific metaclasses?  For example, in our current
implementation the class PATHNAME is an instance of metaclass
FLAVOR-CLASS.


Page 1-27 says that the default argument precedence order is left to
right, but I wonder if in the case of (SETF ...) functions it wouldn't
make more sense for the default order to put the new-value argument last
instead of first?  This wouldn't normally change the semantics, but it
could affect efficiency.


I'm a little confused by the way that SLOT-BOUNDP [p. 2-75],
SLOT-EXISTS-P [p. 2-76], and SLOT-MAKUNBOUND [p. 2-77] are specified as
generic functions with a primary method on class STANDARD-OBJECT which
just invokes a SLOT-...-USING-CLASS generic function.  Do these really
need to be generic at both levels?  According to the specification,
SLOT-BOUNDP, for example, should be implemented as

  (defgeneric slot-boundp (instance slot-name))
  (defmethod slot-boundp ((instance STANDARD-OBJECT) slot-name)
    (slot-boundp-using-class (class-of instance) instance slot-name))

but it seems like it would make more sense to do either 

  (defgeneric slot-boundp (instance slot-name))
  (defmethod slot-boundp ((instance T) slot-name)
    (slot-boundp-using-class (class-of instance) instance slot-name))

or just
  
  (DEFUN slot-boundp (instance slot-name)
    (slot-boundp-using-class (class-of instance) instance slot-name))

Note that the latter parallels the way that SLOT-VALUE is specified.


The syntax template for WITH-ADDED-METHODS [p. 2-90] differs from
GENERIC-LABELS [p. 2-55] by defining exactly one function instead of an
arbitrary number of functions.  This is not mentioned anywhere in the
text, which makes me wonder if that is intentional or if it might be just
a typographical error?


For functions INVALID-METHOD-ERROR and and METHOD-COMBINATION-ERROR to
be fully portable, it would be helpful to have some sort of guideline on
message formats.  For example, should it be a phrase, or a complete
sentence?  Otherwise, a message that looks elegant on one implementation
could look bad on another because it is displayed in a different
context.


Page 2-19 should be updated to show COMPUTE-APPLICABLE-METHODS being a
generic function to match page 3-38.


Is someone planning to specify exactly which conditions are supposed to be
signalled for the various "signals an error" situations?


What package are these symbols in?  Also, given the emphasis on having
the standard package contain exactly the standard set of symbols, it
would be helpful to have an official list of the exported CLOS symbols.
For example, I had trouble deciding whether STANDARD was supposed to be
a defined symbol [until I found the reference on page 1-31].

∂16-Feb-89  1614	Common-Lisp-Object-System-mailer 	effective methods question
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Feb 89  16:14:32 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03690g; Thu, 16 Feb 89 15:51:20 PST
Site: 
Received: by challenger id AA06638g; Thu, 16 Feb 89 15:46:56 PST
Date: Thu, 16 Feb 89 15:46:56 PST
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8902162346.AA06638@challenger>
To: Gray@DSG.csc.ti.com
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu
In-Reply-To: David N Gray's message of Thu, 16 Feb 89  13:47:42 CST <2812650462-8421010@Kelvin>
Subject: effective methods question


   Sender: GRAY@Kelvin.csc.ti.com
   Date: Thu, 16 Feb 89  13:47:42 CST
   From: David N Gray <Gray@DSG.csc.ti.com>

   Is the list returned by functions SPECIALIZER-DIRECT-METHODS and
   GENERIC-FUNCTION-METHODS intended to include effective methods, or just
   the explicitly defined methods?


It should return only the explicitly defined methods, since it is not
specified what an effective method is, or if it should exist. 

Patrick.

∂16-Feb-89  2219	Common-Lisp-Object-System-mailer 	Comments on metaobject draft 10
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Feb 89  22:19:47 PST
Received: from PEGASUS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 541002; Fri 17-Feb-89 01:17:42 EST
Received: by Pegasus.SCRC.Symbolics.COM id AA23272; Fri, 17 Feb 89 01:05:53 est
Date: Fri, 17 Feb 89 01:05:53 est
From: David Moon <moon@scrc-pegasus>
To: Common-Lisp-Object-System@sail.stanford.edu
Subject: Comments on metaobject draft 10

Comments from Moon on 89-003 MOP draft number 10

I didn't make it all the way through the document, but here are
the comments I was able to come up with.  This is a big advance
over the previous draft I read, some time in early fall.

3-6..8: A few attributes of metaobjects seem to be missing here.
Names for classes and generic functions, documentation strings
for classes, generic functions, and methods.  Is this just an
oversight or does it represent some kind of modularity decision
where there is a level that does not have these attributes?

3-7: How come direct slot definitions have names of generic
functions in them, rather than generic function objects?

3-9: Some problems with the inheritance structure table:
It claims metaobject is a subclass of function, which is
surely untrue.  What is the metaclass of structure-object?
The caption implies standard-class, but I would expect that
it is really structure-class.  Also I would really expect
the metaclass of t to be a special metaclass just for t,
rather than built-in-class; is it allowed to be a subclass of
built-in-class?  I don't like the name "dependee-mixin", I
think "redefinable" might be a better word than "dependee."

3-10: "The default class of method combination objects is
not specified."  This seems inconsistent, I wonder if we
want to change it.  The short form and the long form of
define-method-combination would likely use different classes.

3-11: I think rule 3 doesn't work, for the same reason I
complained about last time.  I haven't rechecked this.

3-11: Rule 5 says implementations can define unspecified
:before and :after methods, what about :around?

3-11: Rule 8 is slightly wrong, see the cleanup issue PACKAGE-CLUTTER.
The way you say that slot names can't be in packages the user knows
about is more complex.  It would be better if ANSI Common Lisp just had
a word for it so we didn't have to keep saying it over and over.  This
issue also arises in the section on expansion of the user interface
macros.

3-13ff: The whole section on expansion of the user interface macros
is totally screwed up, as I think you know.  Straightening out the
Common Lisp issues with EVAL-WHEN and lexical environments is a
prerecquisite for fixing this.  The biggest problem is deciding what
happens at macro expansion time versus what happens when the macro
expansion is evaluated.  These days I believe that nothing "essential"
should happen at macro expansion time.  I think compile-time method
and slot-description metaobjects should have their function slots
unbound -- except since the MOP doesn't define them to be slots, this
has to be said differently.  But it is an error to access the function.

A more difficult problem (I think this has been discussed inconclusively
in the mail) is the relation of the local and remote metaobjects in
compile-file; ideally creating a remote class should create remote
objects for all its superclasses and subclasses, so there are no
cross-environment links, but that would copy the entire meta-object
world, which would be too slow.  Hence you either have to indirect
through names, as Flavors does, or use a virtual-copy mechanism of
some sort.  I don't know whether a virtual copy mechanism will require
some kind of change of protocol, with some more user interface
functions taking an environment argument; indirecting through names
avoids that issue since the indirection is a name-to-object translation
that -always- requires an environment argument.  Comments?

3-17: Still on the user interface macros: there is something fundamentally
wrong with specifying load time and eval time separately.  What they do
should be equivalent at the level of abstraction used in the spec.

3-22: I believe the expansion of define-method-combination was
pretty well outlined in 88-002, unless that was only in our mail
discussions and did not get into the final document.

3-25: The whole slot-definition-elide-access-method-p (and relatives)
mechanism seems inconsistent with the rest of CLOS.  I would have
expected this to be handled by making the slot-descriptor and argument
to functions at the level of slot-value-using-class, then the class
of the slot descriptor contributes to selecting the applicable methods
and the optimization can be performed if and only if the built-in
method is the only applicable method.

3-26: The restriction mentioned against using an obsolete instance
that has not yet been updated may be unimplementable, or even
meaningless, in multiprocess systems (where a class can be redefined
at any instant that user code can be running).

3-29: The first object to add-dependent shouldn't be specified to
be a metaobject, since not all metaobjects work and some non-metaobjects
work.  It should be an object that you call "dependee" or I call
"redefinable".

3-32: This says add-direct-subclass is called when a class is redefined.
Is it also called when a class is initially defined?

3-33: For functions like add-method that appear in both chapter 2 and
chapter 3, should Common Lisp be amended to delete the chapter 2 version?
Or is it really intended to have two probably non-identical definitions
of these functions?

3-50: The ensure-class-using-class generic function should not have
&allow-other-keys in its arglist.  Recall that this means that there
should never be any argument checking on calls to this generic function,
which seems unlikely to be what you want.

I guess that's as far as I have gotten so far.  I suppose it would be
more useful for me to think about the expansion of the user interface
macros than to try to plow through the rest of the document (yet more
function descriptions).

∂21-Feb-89  1053	Common-Lisp-Object-System-mailer 	CLOS questions  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Feb 89  10:53:40 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA07349g; Tue, 21 Feb 89 10:47:29 PST
Received: by challenger id AA05756g; Tue, 21 Feb 89 10:43:04 PST
Date: Tue, 21 Feb 89 10:43:04 PST
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8902211843.AA05756@challenger>
To: Gray@DSG.csc.ti.com
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu
In-Reply-To: David N Gray's message of Thu, 16 Feb 89  15:31:03 CST <2812656663-8793592@Kelvin>
Subject: CLOS questions

   Sender: GRAY@Kelvin.csc.ti.com
   Date: Thu, 16 Feb 89  15:31:03 CST
   From: David N Gray <Gray@DSG.csc.ti.com>


   Page 1-15 of 88-002R says that 

     "Each class that corresponds to a predefined Common Lisp type
     specifier can be implemented in one of three ways ...  a standard
     class ..., a structure class ..., or a built-in class ..."

   Shouldn't this also permit the possibility of other
   implementation-specific metaclasses?  For example, in our current
   implementation the class PATHNAME is an instance of metaclass
   FLAVOR-CLASS.

There is a compatibility question that needs to be answered. Right now,
pathname is not supposed to be a class, so the question is mute, but when it
will be, its metaclass has to be compatible with standard-class, so a portable
program can inherit from it, and specialize some methods on it, as if it were a
standard-class instance. 

   Page 1-27 says that the default argument precedence order is left to
   right, but I wonder if in the case of (SETF ...) functions it wouldn't
   make more sense for the default order to put the new-value argument last
   instead of first?  This wouldn't normally change the semantics, but it
   could affect efficiency.

Maybe it does affect efficiency in some implementations, but I don't think it
has to.  I think that the user would be confused if we establish different
default rules for setf generic functions. I except user changing the default
procedence order if they know that the value is not significant for
discrimination.

   I'm a little confused by the way that SLOT-BOUNDP [p. 2-75],
   SLOT-EXISTS-P [p. 2-76], and SLOT-MAKUNBOUND [p. 2-77] are specified as
   generic functions with a primary method on class STANDARD-OBJECT which
   just invokes a SLOT-...-USING-CLASS generic function.  Do these really
   need to be generic at both levels?  According to the specification,
   SLOT-BOUNDP, for example, should be implemented as
   Note that the latter parallels the way that SLOT-VALUE is specified.

I think we said that was a bug. They all should be functions like slot-value.

∂21-Feb-89  1501	Common-Lisp-Object-System-mailer 	Issue MACRO-ENVIRONMENT-EXTENT 
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89  15:01:07 PST
Date: Sun 19 Feb 89 15:54:36-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue MACRO-ENVIRONMENT-EXTENT
To: sandra%defun@CS.UTAH.EDU
cc: Moon@SCRC-STONY-BROOK.ARPA, iim%ECLA@ECLC.USC.EDU,
    cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <12472024104.5.IIM@ECLA.USC.EDU>

> From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Date: Sun, 12 Feb 89 19:20:29 MST
>
> Having seen the new proposal for EVAL-WHEN, I still don't have any idea why
> the extent of macro environment objects depends on it.  Can you explain the
> connection? 
>
> Also, I don't think anybody is arguing for requiring environments to have
> indefinite extent on the grounds that CLOS requires it.  (The argument is
> that it's generally useful and for general symmetry with every other kind of
> Lisp data object having indefinite extent.) Just the opposite -- David Gray's
> question was whether that requirement would complicate the implementation of
> CLOS. 

The extent of macro environment objects is related to EVAL-WHEN because macro
expanders may wish to return forms which contain environments as quoted
constants.  For example:

(defclass position (graphics-object)
    ((x :accessor position-x :initform 0 :type integer)
     (y :accessor position-y :initform 0 :type integer)
     (pen-color :allocation :class))
  (:default-initargs :screen *position-screen*))

=>

`(progn
  (eval-when (compile)
    (ensure-class 'position
      :metaclass (find-class 'standard-class)
      :superclasses (list (find-class 'graphics-object t ',<env>)) ; <= ***
      :direct-slots
         (list (make-instance 'standard-direct-slot
                      :name 'x
                      :initform '0
                      :readers '(position-x)
                      :writers '((setf position-x))
                      :type 'integer)
                   ...
               )
      :default-initargs
         (list (list ':screen '*position-screen* nil))
      :environment ',<env>)					   ; <= ***
    )
  (ensure-class 'position
    :metaclass (find-class 'standard-class)
    :superclasses (list (find-class 'graphics-object))
    :direct-slots
       (list (make-instance 'standard-direct-slot
                    :name 'x
                    :initform '0
                    :initfunction #'(lambda () 0)
                    :readers '(position-x)
                    :writers '((setf position-x))
                    :type 'integer)
                 ...
             )
    :default-initargs
       (list (list ':screen '*position-screen*
                   #'(lambda () *position-screen*))))
  )

Not saying anything about their extent may make such an expansion invalid,
because the expansion might be returned from the dynamic extent of the
environment it points to.  Requiring environments to have indefinite extent has
problems for CLOS because at compile-time it wants to create remote metaobjects
and link them into the right places, but then flush those links when the
compilation is over.  This is what I am trying to address with my recent
comments about WITH-COMPILATION-UNIT.

kab
-------

∂21-Feb-89  1501	Common-Lisp-Object-System-mailer 	Issue CONSTANT-COMPILABLE-TYPES
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89  15:01:51 PST
Date: Sun 19 Feb 89 15:48:59-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue CONSTANT-COMPILABLE-TYPES
To: JonL@LUCID.COM, sandra%defun@CS.UTAH.EDU
cc: Moon@SCRC-STONY-BROOK.ARPA, iim%ECLA@ECLC.USC.EDU,
    cl-cleanup@SAIL.STANFORD.EDU, cl-compiler@SAIL.STANFORD.EDU,
    common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <12472023082.5.IIM@ECLA.USC.EDU>

The message that prompted this response was sent only to cl-compiler.  Since my
response touches on issues of more general interest, I've included cl-cleanup
and common-lisp-object-system as well.  Appologies in advance -- this turned
out to be a bit of a tirade. 

> Date: Tue, 31 Jan 89 05:05:58 PST
> From: Jon L White <jonl@lucid.com>
>
> > I disagree with the idea of changing the handling for structures.  
> > Introducing the LOAD-OBJECTS protocol for standard-class instances is fine,
> > but structures have been part of the language for a while already and I
> > don't see any need to change their handling in an incompatible way.  If
> > people find that the default handling of structures is not sufficient for
> > their needs, that's probably a sign that they really need to use the more
> > complex protocol for standard-class objects instead.
>
> I very much agree with what you say here.  Unfortunately, not enough
> people objected at the right time -- when the vote on 88-002R was being
> taken -- and this "trojan horse" sneaked in to destroy the defstruct
> house. [in fact, I wonder how many people actualy read 88-002R before
> voting on it?]  It's possible that changing the default defstructs to be 
> CLOS instances will make it smoother for PCL transition; but I don't see
> how the incompatible changes to the :PRINT-FUNCTION, :COPIER, and 
> EQUALP treatment on defstructs helps anyone.
> 
> ...
> 
> Unfortunately, the EQUAL-STRUCTURE amendment that passed at the Hawaii
> meeting retracted this very useful action of EQUALP on defstructs, and 
> rendered it useless again.  Hopefully, the final version of the LOAD-
> OBJECTS proposal will specify a more useful default behaviour (e.g., 
> "just like the old CLtL behaviour"?), but note it this will have to 
> amend the already-passed EQUAL-STRUCTURE proposal.
> 
> -- JonL --

I wish to strongly disagree with almost everything said above.  There is a
fundamental assumption being made, namely that structures are second-class
citizens in the CLOS world.  This is most clearly expressed by the statement

  "If people find that the default handling of structures is not sufficient for
   their needs, that's probably a sign that they really need to use the more
   complex protocol for standard-class objects instead."

This is terrible!  Awful!  Totally wrong!

Structures have certain restrictions (single inheritance, don't support
CHANGE-CLASS, ...) in exchange for potentially very efficient access.  When
deciding whether to implement a data structure using STRUCTURE-CLASS vs
STANDARD-CLASS, the question a programmer should be asking is "does this class
need multiple inheritance ...", not "am I ever going to need to dump one of
these things, or compare two of them using EQUALP, or ...".

Moon keeps pointing out that only the programmers who define/use a class can
know how to properly copy, dump, test for equality (whatever equality means),
&etc.  Unfortunately, under strong pressure from some people he occasionally
sounds like he is willing to cave in on this point in the case of structures.
Well I won't.  Removing structure objects from these kinds of protocols and
instead giving them trivial component-wise functionality is utter nonsense.  By
all means we should give the programmer mechanisms to help him specify that
kind of behavior if that is what he wants.  But it must be a concious decision,
not a default behavior!  (As an aside, if it were up to me, the default copier
option for defstruct would be Nil.)

With regard to the EQUAL-STRUCTURE amendment that passed at the Hawaii meeting,
I insisted on EQ for structures because I firmly believe that is the right
default.  I would still like to see a proposal to make EQUALP a generic
function; unfortunately, the group who said they would make such a proposal
have not done so.  I was thinking about making such a proposal myself, but I've
been having trouble with the specification of the hash function, due to some
ideas I've been working on with regard to hash-table implementations.

kab
-------

∂23-Feb-89  1316	Common-Lisp-Object-System-mailer 	CLOS defining macros & compilation  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Feb 89  13:15:57 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA23821; Thu, 23 Feb 89 14:14:01 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA10372; Thu, 23 Feb 89 14:13:59 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8902232113.AA10372@defun.utah.edu>
Date: Thu, 23 Feb 89 14:13:57 MST
Subject: CLOS defining macros & compilation
To: cl-compiler@sail.stanford.edu, common-lisp-object-system@sail.stanford.edu

This is an attempt to summarize the problems that have been raised so
far about the compilation semantics of the various CLOS defining
macros.

  The descriptions of the expansions of the DEFCLASS, DEFMETHOD, and
  DEFGENERIC macros in the meta-object protocol document specify that
  subforms be evaluated at compile-time in the lexical environment in
  which the defining macro appears, which is not fully defined until
  run-time.  The obvious solution to this problem is to say that the
  compile-time evaluation happens only when the defining macro call
  appears at top-level, the same as for all the other defining macros.
  However, some people have questioned whether compile-time evaluation
  is even necessary at all, especially in the case of DEFMETHOD and
  DEFGENERIC.
  
  The meta-object protocol does not say anything about whether
  DEFINE-METHOD-COMBINATION has compile-time side-effects.
  
  The CLOS spec assumes that compile-time class and method definitions
  are made available through a remote lexical environment object.  The
  full implications of this are not well-understood and we have little
  or no experience with actual implementation.
  
  The descriptions of the expansions of the DEFCLASS, DEFMETHOD, and
  DEFGENERIC macros in the meta-object protocol document assume that
  lexical environment objects received with &ENVIRONMENT have indefinite
  extent.  Some people have argued that it ought to be legal for
  environment objects to have only dynamic extent (issue
  MACRO-ENVIRONMENT-EXTENT).  There have also been concerns expressed
  about how COMPILE-FILE should "clean up" the class structure to remove
  definitions made during compilation.

Now, as to what I suggest we do about all of this.

I believe that there are enough serious problems with the compilation
semantics presented in the meta-object protocol document distributed
before the January meeting that it would be a mistake to try to
standardize that behavior.  It does not appear that any alternate
proposal is forthcoming from the CLOS committee in time for us to make
the March 15th deadline (that's less than 3 weeks away, folks).

To me it appears that the only practical solution for the near term is
a minimal proposal that leaves many aspects of the behavior explicitly
vague.  (Basically, that DEFCLASS makes the class name recognizable as
a valid type name in subsequent declarations, but leaving unspecified
whether or not real class, method, etc. objects are fully defined at
compile-time.)  It may well happen that at some point the MOP
compilation semantics will be fixed and the behavior can be specified
more tightly, but I don't see any sign of that happening within the
next couple of weeks.

I think that one of the things we must leave explicitly vague is the
use of remote lexical environment objects to contain compile-time
definitions.  Proposal COMPILE-TIME-HANDLING-OF-TOP-LEVEL-FORMS allows
implementations considerable freedom in how other kinds of definitions
(DEFMACRO, DEFSTRUCT, etc.) are made available to the compiler; it
says only that such definitions *are* made available.  Why not do the
same thing for the CLOS defining macros?  I certainly don't want to
discourage people from continuing to pursue the issues involved, but
the work seems too experimental yet at the stage to fall into the
domain of a standards committee.

-Sandra
-------

∂23-Feb-89  1519	Common-Lisp-Object-System-mailer 	Re: CLOS defining macros & compilation   
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 23 Feb 89  15:19:44 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA04040; Thu, 23 Feb 89 15:20:06 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA03709; Thu, 23 Feb 89 15:16:36 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA18092; Thu, 23 Feb 89 15:17:04 PST
Message-Id: <8902232317.AA18092@suntana.sun.com>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Cc: cl-compiler@sail.stanford.edu, common-lisp-object-system@sail.stanford.edu
Subject: Re: CLOS defining macros & compilation 
In-Reply-To: Your message of Thu, 23 Feb 89 14:13:57 -0700.
             <8902232113.AA10372@defun.utah.edu> 
Date: Thu, 23 Feb 89 15:16:58 PST
From: kempf@Sun.COM


>vague.  (Basically, that DEFCLASS makes the class name recognizable as
>a valid type name in subsequent declarations, but leaving unspecified
>whether or not real class, method, etc. objects are fully defined at
>compile-time.)  It may well happen that at some point the MOP

This is going to put a crimp in the usual style of OO programming, namely
to define classes at the top of a file, then the methods applicable to
them thereafter. What you're saying is that this style would be
potentially nonportable.

		jak

∂23-Feb-89  1532	Common-Lisp-Object-System-mailer 	CLOS defining macros & compilation  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 23 Feb 89  15:32:22 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00718g; Thu, 23 Feb 89 15:25:39 PST
Received: by challenger id AA09808g; Thu, 23 Feb 89 15:21:13 PST
Date: Thu, 23 Feb 89 15:21:13 PST
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8902232321.AA09808@challenger>
To: kempf@Sun.COM
Cc: sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu,
        common-lisp-object-system@sail.stanford.edu
In-Reply-To: kempf@Sun.COM's message of Thu, 23 Feb 89 15:16:58 PST <8902232317.AA18092@suntana.sun.com>
Subject: CLOS defining macros & compilation 


   Date: Thu, 23 Feb 89 15:16:58 PST
   From: kempf@Sun.COM


   >vague.  (Basically, that DEFCLASS makes the class name recognizable as
   >a valid type name in subsequent declarations, but leaving unspecified
   >whether or not real class, method, etc. objects are fully defined at
   >compile-time.)  It may well happen that at some point the MOP

   This is going to put a crimp in the usual style of OO programming, namely
   to define classes at the top of a file, then the methods applicable to
   them thereafter. What you're saying is that this style would be
   potentially nonportable.

		   jak

Not necessarily. Flavors classes do not get fully defined at compile time. The
compiler notices so much about them so methods can be added to them, and method
combination can be executed. The style that we all use and love can me made
portable, but what happens in the brain of the compiler, and the CLOS
interpreter during a compile-file might not be specified. 
I think that's what Sandra is proposing.

Patrick.

∂23-Feb-89  1546	Common-Lisp-Object-System-mailer 	Re: CLOS defining macros & compilation   
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 23 Feb 89  15:46:19 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA05145; Thu, 23 Feb 89 15:46:48 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA04970; Thu, 23 Feb 89 15:43:18 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA18162; Thu, 23 Feb 89 15:43:40 PST
Message-Id: <8902232343.AA18162@suntana.sun.com>
To: Patrick Dussud <dussud@lucid.com>
Cc: kempf@Sun.COM, sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu,
        common-lisp-object-system@sail.stanford.edu
Subject: Re: CLOS defining macros & compilation 
In-Reply-To: Your message of Thu, 23 Feb 89 15:21:13 -0800.
             <8902232321.AA09808@challenger> 
Date: Thu, 23 Feb 89 15:43:37 PST
From: kempf@Sun.COM


>Not necessarily. Flavors classes do not get fully defined at compile time. The
>compiler notices so much about them so methods can be added to them, and method
>combination can be executed. The style that we all use and love can me made
>portable, but what happens in the brain of the compiler, and the CLOS
>interpreter during a compile-file might not be specified. 
>I think that's what Sandra is proposing.

I guess defining the type at compile time would be OK, but I think the
spec will have to be changed to allow method definition on the type
rather than the class. Technically, the compiler should only need
the type and not the class anyway. This might have ramifications, however,
so it's best to think it over.

		jak



∂23-Feb-89  1550	Common-Lisp-Object-System-mailer 	Re: CLOS defining macros & compilation   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 23 Feb 89  15:50:12 PST
Received: by ti.com id AA10726; Thu, 23 Feb 89 17:49:15 CST
Received: from Kelvin by tilde id AA21083; Thu, 23 Feb 89 17:43:00 CST
Message-Id: <2813269367-7648607@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 23 Feb 89  17:42:47 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, common-lisp-object-system@sail.stanford.edu
Subject: Re: CLOS defining macros & compilation
In-Reply-To: Msg of Thu, 23 Feb 89 14:13:57 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)

>   The descriptions of the expansions of the DEFCLASS, DEFMETHOD, and
>   DEFGENERIC macros in the meta-object protocol document assume that
>   lexical environment objects received with &ENVIRONMENT have indefinite
>   extent.

Not really, unless you've noticed something I missed.  Some objects in
the environment (class definitions in particular) have an extent
corresponding to the duration of the invocation of COMPILE-FILE, but the
environment objects themselves, as received by a macro, do not need to
be used outside the extent of that macro invocation.

∂23-Feb-89  1558	Common-Lisp-Object-System-mailer 	Re: CLOS defining macros & compilation   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Feb 89  15:57:52 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA28812; Thu, 23 Feb 89 16:55:49 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA10511; Thu, 23 Feb 89 16:55:46 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8902232355.AA10511@defun.utah.edu>
Date: Thu, 23 Feb 89 16:55:45 MST
Subject: Re: CLOS defining macros & compilation 
To: kempf@Sun.COM
Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore),
        cl-compiler@sail.stanford.edu,
        common-lisp-object-system@sail.stanford.edu
In-Reply-To: kempf@Sun.COM, Thu, 23 Feb 89 15:16:58 PST

> Date: Thu, 23 Feb 89 15:16:58 PST
> From: kempf@Sun.COM
> 
> This is going to put a crimp in the usual style of OO programming, namely
> to define classes at the top of a file, then the methods applicable to
> them thereafter. What you're saying is that this style would be
> potentially nonportable.

That certainly isn't my intent -- I want to legitimize current
programming practice while glossing over the details of how it's
actually implemented.

I can't find any reference in 88-002R to whether classes named as
parameter specializers in a DEFMETHOD must be defined before the
DEFMETHOD is "evaluated", much less in advance of when the DEFMETHOD
is macroexpanded.  (It says a parameter specializer is a symbol that
names a class.) The MOP document does seem to imply that there must be
real class objects defined at compile time, but only so it can create
a real method object at compile time.  We could put in an explicit
statement that classes that appear as DEFMETHOD's parameter
specializers must be known at compile time and that compiling a
DEFCLASS will make the class name known to the compiler for this
purpose.  We probably need to say something similar about class names
defined by DEFSTRUCT as well, right? 

We could also put in a statement that DEFCLASS makes the class name
known to the compiler so it can appear as a superclass in another
DEFCLASS, analogous to the language about the DEFSTRUCT :INCLUDE
option in proposal COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS.  But
88-002R already says that superclasses don't need to be defined at all
if the metaclass is STANDARD-CLASS, so this might be unnecessary. 

-Sandra
-------

∂23-Feb-89  1607	Common-Lisp-Object-System-mailer 	Re: CLOS defining macros & compilation   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Feb 89  16:07:39 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA29059; Thu, 23 Feb 89 17:05:38 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA10531; Thu, 23 Feb 89 17:05:36 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8902240005.AA10531@defun.utah.edu>
Date: Thu, 23 Feb 89 17:05:35 MST
Subject: Re: CLOS defining macros & compilation
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore),
        cl-compiler@sail.stanford.edu,
        common-lisp-object-system@sail.stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Thu, 23 Feb 89  17:42:47 CST

> Date: Thu, 23 Feb 89  17:42:47 CST
> From: David N Gray <Gray@DSG.csc.ti.com>
> 
> >   The descriptions of the expansions of the DEFCLASS, DEFMETHOD, and
> >   DEFGENERIC macros in the meta-object protocol document assume that
> >   lexical environment objects received with &ENVIRONMENT have indefinite
> >   extent.
> 
> Not really, unless you've noticed something I missed.  Some objects in
> the environment (class definitions in particular) have an extent
> corresponding to the duration of the invocation of COMPILE-FILE, but the
> environment objects themselves, as received by a macro, do not need to
> be used outside the extent of that macro invocation.

We all seem to be converging on the idea that compile-time
side-effects from macros should be handled by having the macro expand
into an (EVAL-WHEN (COMPILE) ...).  The MOP document specifies that
the environment object be passed as an argument to calls to FIND-CLASS
(or whatever) that happen as a compile-time side-effect.  This implies
that the environment object would have to appear as a quoted constant
in the macro expansion.  The proposal to give macro environment
objects dynamic scope would give them dynamic scope *within the macro
function*, which means it would not be legitimate for them to appear
at all in the expansion returned from the macro. 

-Sandra
-------

∂23-Feb-89  1650	CL-Compiler-mailer 	remote environments 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 23 Feb 89  16:48:49 PST
Received: by ti.com id AA11038; Thu, 23 Feb 89 18:48:24 CST
Received: from Kelvin by tilde id AA22434; Thu, 23 Feb 89 18:38:13 CST
Message-Id: <2813272681-7847725@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 23 Feb 89  18:38:01 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Common-Lisp-Object-System@SAIL.Stanford.edu
Cc: CL-Compiler@SAIL.Stanford.edu
Subject: remote environments

I think it might help to focus the discussion about remote environments
and meta object programming if we had a clearer picture of what the
goals are.  The basic question is what kinds of things can be defined and
then used during compilation of the same file that defines them, and
what restrictions might apply.

DEFCLASS 
  * Can the class be used as a superclass of a later DEFCLASS?  [clearly yes]
  * Can it be used as a specializer in a DEFMETHOD?  [clearly yes]
  * Can a MAKE-INSTANCE be done by a macro expander, DEFCONSTANT, or "#."?
     - If so, do initforms have access to macros and constants defined
       earlier in the file?
  * Can the class be used as the :METACLASS option of a later DEFCLASS?
     - Can that second class be instantiated?
  * Can it be used as the :GENERIC-FUNCTION-CLASS option of a
    DEFGENERIC, GENERIC-FUNCTION, GENERIC-FLET, or GENERIC-LABELS?
  * Can it be used as the :METHOD-CLASS option of a DEFGENERIC etc.?
     - Can DEFMETHODs then be done for that generic function?

DEFGENERIC
  * Referenced by later DEFMETHOD? [clearly yes]
  * Is the function defined such that it can be called at compile time?

DEFMETHOD
  * Can it be invoked at compile-time?
  * In particular, will methods added to standard generic functions be
    invoked by the system at compile time?

DEFINE-METHOD-COMBINATION
  * Used in a later DEFGENERIC?
     - Callable at compile-time?

Are there other interactions that need to be considered?

I think that the standard could take a simple, minimal, approach that
would still satisfy the most common usages.  Suppose we said:

DEFCLASS
  If it appears at top-level, then the class name is defined for use as
  a type specifier or method specializer.  It can also be used as a
  superclass of a later DEFCLASS since they don't have to be defined
  before being referenced anyway.  The class object can be obtained by
  calling FIND-CLASS with an environment argument, but it can only be
  used in ways that do not require the class to be finalized.  For
  example, one could ask for its CLASS-DIRECT-SUPERCLASSES, but not its
  CLASS-PRECEDENCE-LIST.  Other uses, which could involve the need to
  instantiate the class, could not be portably done in the same file
  without wrapping an (EVAL-WHEN (EVAL COMPILE LOAD) ...) around the
  DEFCLASS.  Implementations would be free to support compile-time
  instantiation as an extension.  One way to look at this would be to
  say that it is implementation-dependent whether FINALIZE-INHERITANCE
  works or signals an error when given a class defined in the
  compile-time environment.

DEFGENERIC
  The attributes of the generic function that affect DEFMETHOD will be
  recorded for use by definitions of methods for that generic function
  later in the file.  This includes the lambda-list and method class.
  It is implementation-dependent whether this is actually put in the
  form of a generic function object and whether other operations on that
  generic function are possible at compile-time.

DEFMETHOD
  Method definitions are not required to have any compile-time
  side-effects, but the compiler may warn about things like undefined
  specializer classes or non-congruent lambda-lists.  ADD-METHOD is not
  invoked at compile-time unless forced by using EVAL-WHEN.

DEFINE-METHOD-COMBINATION
  No compile-time side-effect is required.  The new combination can
  still be referenced in DEFGENERICs and DEFMETHODs later in the file
  since the definition is not really needed until the generic function
  is called and an effective method needs to be computed.  A compiler
  could, however, notice what combination names have been defined and
  issue a warning on a DEFGENERIC with an undefined combination
  or a DEFMETHOD using an undefined qualifier.

∂23-Feb-89  1746	CL-Compiler-mailer 	Re: remote environments  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Feb 89  17:46:12 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA01793; Thu, 23 Feb 89 18:44:16 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA10622; Thu, 23 Feb 89 18:44:12 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8902240144.AA10622@defun.utah.edu>
Date: Thu, 23 Feb 89 18:44:11 MST
Subject: Re: remote environments
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Compiler@SAIL.Stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Thu, 23 Feb 89  18:38:01 CST

Thanks for putting together a list of all the questions involved.  I
can't claim to be an expert on the subject, but perhaps my answers
would be useful as a representation of the expectations of a naive
user with few preconceived notions.

> DEFCLASS 
>   * Can the class be used as a superclass of a later DEFCLASS?  [clearly yes]
>   * Can it be used as a specializer in a DEFMETHOD?  [clearly yes]

So far, so good.

>   * Can a MAKE-INSTANCE be done by a macro expander, DEFCONSTANT, or "#."?

Probably not.  We allow other kinds of definitions seen by the
compiler (macros, for example), to be hidden somewhere where they are
not visible in these circumstances.  If you really want the class to
be fully defined at compile time, you should wrap the definition in an
(EVAL-WHEN (EVAL COMPILE LOAD)...). 

>   * Can the class be used as the :METACLASS option of a later DEFCLASS?
>      - Can that second class be instantiated?

I'm not sure on this one.  I'm inclined to think that users would put
the metaclass definition and all its methods off in a separate file
anyway, so I don't see any compelling reason to -require- that a class
be usable as a metaclass in the same file it is defined in.

>   * Can it be used as the :GENERIC-FUNCTION-CLASS option of a
>     DEFGENERIC, GENERIC-FUNCTION, GENERIC-FLET, or GENERIC-LABELS?
>   * Can it be used as the :METHOD-CLASS option of a DEFGENERIC etc.?
>      - Can DEFMETHODs then be done for that generic function?

I don't know enough about the issues involved here.

> DEFGENERIC
>   * Referenced by later DEFMETHOD? [clearly yes]

Right.

>   * Is the function defined such that it can be called at compile time?

I'd have to say no.  DEFGENERIC is analagous to DEFUN, and DEFUN only makes
the function definition available at load time.

> DEFMETHOD
>   * Can it be invoked at compile-time?
>   * In particular, will methods added to standard generic functions be
>     invoked by the system at compile time?

No to both questions.  

> DEFINE-METHOD-COMBINATION
>   * Used in a later DEFGENERIC?
>      - Callable at compile-time?

I'm not quite sure what all the issues involved are here.  I think
that I would expect a method combination to be usable later on in the
file.  To me they seem kind of similar to SETF methods (but maybe
that's just a random coincidence). 

> Are there other interactions that need to be considered?

Yes.  How about specifying when checks for lambda-list congruence are
made for DEFMETHOD?  In particular, suppose I have a generic function
FOO fully defined in the compilation environment, but a file I'm
compiling has a method for FOO with a lambda list that is not
congruent.  (Maybe I just fixed the file and I want to recompile and
reload it.)  I think it is reasonable for the compiler to issue a
warning but I don't think this is an error or that an error should be
signalled -- that should happen only at run time.  This would be in
keeping with the general philosophy of allowing functions to be freely
redefined. 

-Sandra
-------

∂23-Feb-89  2103	Common-Lisp-Object-System-mailer 	CLOS defining macros & compilation  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Feb 89  21:03:45 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 FEB 89 20:23:23 PST
Date: Thu, 23 Feb 89 20:23 PST
From: Gregor.pa@Xerox.COM
Subject: CLOS defining macros & compilation
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@sail.stanford.edu,
 common-lisp-object-system@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <8902232113.AA10372@defun.utah.edu>
Message-ID: <19890224042316.2.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no

    Date: Thu, 23 Feb 89 14:13:57 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    I believe that there are enough serious problems with the compilation
    semantics presented in the meta-object protocol document distributed
    before the January meeting that it would be a mistake to try to
    standardize that behavior.  It does not appear that any alternate
    proposal is forthcoming from the CLOS committee in time for us to make
    the March 15th deadline (that's less than 3 weeks away, folks).

No one believes that what is written in draft 10 of the MOP is valid.  I
am certainly sorry if that wasn't communicated to you clearly.

A couple of weeks ago I sent a summary analysis to a small group of
people familiar with this problem.  My message outlines three courses of
action to take.  Among these is a proposal which, while it is minimal in
certain metaobject programming respects, does not restrict ordinary
programming.

My belief is that resolution of this issue cannot proceed until the
EVAL-WHEN issue has been resolved.  I have been waiting to see what the
resolution would be on the Symbolics EVAL-WHEN proposal.  I haven't said
anything about it before, but that proposal looks right to me.  I
believe it has what it would take to implement any of the CLOS behaviors
I outlined to the CLOS group.  I don't understand how to provide
reasonable CLOS semantics with the previous propsal.

Once the status of EVAL-WHEN is clear, and I get some more feedback
about the message I sent, I will be able to rewrite the relevant part of
Chapter 3.  That rewrite will cover more than what we want to put in the
standard just now, but it will make it clear exactly what the behavior
should be.  It will give us a precise model with which to decide exactly
what how much to put in the standard.  Then it should be easy to reduce
it to what the compiler committee report should say.
-------

∂24-Feb-89  0157	Common-Lisp-Object-System-mailer 	Issue CONSTANT-COMPILABLE-TYPES
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 24 Feb 89  01:57:23 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01286g; Fri, 24 Feb 89 01:43:50 PST
Received: by bhopal id AA19679g; Fri, 24 Feb 89 01:46:12 PST
Date: Fri, 24 Feb 89 01:46:12 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8902240946.AA19679@bhopal>
To: IIM%ECLA@ECLC.USC.EDU
Cc: sandra%defun@CS.UTAH.EDU, Moon@SCRC-STONY-BROOK.ARPA,
        iim%ECLA@ECLC.USC.EDU, cl-cleanup@SAIL.STANFORD.EDU,
        cl-compiler@SAIL.STANFORD.EDU,
        common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: Kim A. Barrett's message of Sun 19 Feb 89 15:48:59-PST <12472023082.5.IIM@ECLA.USC.EDU>
Subject: Issue CONSTANT-COMPILABLE-TYPES

re: ... only the programmers who define/use a class can
    know how to properly copy, dump, test for equality (whatever equality 
    means), &etc.  ... Removing structure objects from these kinds of 
    protocols and instead giving them trivial component-wise functionality 
    is utter nonsense.  By all means we should give the programmer mechanisms 
    to help him specify that kind of behavior if that is what he wants.  But 
    it must be a concious decision, not a default behavior!  (As an aside, if 
    it were up to me, the default copier option for defstruct would be Nil.)


Kim, don't you have something turned around here?   Previous mail
referred to CLtL p81 to show that defstruct instances should be
descended componentwise by EQUALP.  This is not a statement about
classes in general -- just about structure-class, and its historic
meaning under EQUALP.  Thus the Hawaii amendment was an *incompatible* 
change (which has already raised some question in Lucid's customer land!).
This incompatible change unfortunately does nothing at all towards 
supplying the "mechanisms" you call for, and in fact breaks some existing 
code (in a very inscrutable way).

Given the failure to make EQUALP generic, wouldn't it be far better
to leave it alone and not make backwards-incompatible changes which
do no one any good?


-- JonL --


∂24-Feb-89  0754	Common-Lisp-Object-System-mailer 	Re: CLOS defining macros & compilation   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 24 Feb 89  07:54:50 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA12042; Fri, 24 Feb 89 08:52:52 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA11101; Fri, 24 Feb 89 08:52:49 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8902241552.AA11101@defun.utah.edu>
Date: Fri, 24 Feb 89 08:52:48 MST
Subject: Re: CLOS defining macros & compilation
To: Gregor.pa@Xerox.COM
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
        cl-compiler@sail.stanford.edu,
        common-lisp-object-system@sail.stanford.edu
In-Reply-To: Gregor.pa@Xerox.COM, Thu, 23 Feb 89 20:23 PST

> Date: Thu, 23 Feb 89 20:23 PST
> From: Gregor.pa@Xerox.COM
> 
> My belief is that resolution of this issue cannot proceed until the
> EVAL-WHEN issue has been resolved.  I have been waiting to see what the
> resolution would be on the Symbolics EVAL-WHEN proposal.  I haven't said
> anything about it before, but that proposal looks right to me.  I
> believe it has what it would take to implement any of the CLOS behaviors
> I outlined to the CLOS group.  I don't understand how to provide
> reasonable CLOS semantics with the previous propsal.
> 
> Once the status of EVAL-WHEN is clear, and I get some more feedback
> about the message I sent, I will be able to rewrite the relevant part of
> Chapter 3.  That rewrite will cover more than what we want to put in the
> standard just now, but it will make it clear exactly what the behavior
> should be.  It will give us a precise model with which to decide exactly
> what how much to put in the standard.  Then it should be easy to reduce
> it to what the compiler committee report should say.

I think you should go ahead and assume that the Symbolics EVAL-WHEN
proposal, or something very much like it, will be accepted.  I believe
we are all pretty much in agreement with the goals Kent set out.  I
may still put together an alternate proposal but the changes would be
more in the way it's presented than in the semantics. 

Do you have any idea how long it will take you to do this revision to
Chapter 3?  My understanding is that it will require truly exceptional
circumstances to get anything into the standard after the upcoming
meeting.  We may need to do this all in parallel instead of series to
get things done in time.

Thanks for keeping us updated on this.

-Sandra
-------

∂27-Feb-89  0854	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 27 Feb 89  08:53:57 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA20033; Mon, 27 Feb 89 09:52:01 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA00761; Mon, 27 Feb 89 09:51:58 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8902271651.AA00761@defun.utah.edu>
Date: Mon, 27 Feb 89 09:51:57 MST
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY
To: cl-compiler@sail.stanford.edu
Cc: common-lisp-object-system@sail.stanford.edu

I have a new version of this proposal in the works.  I've consulted
with Kathy Chapman on how to handle the wording problems that were
brought up earlier.  But, there is still the paragraph that deals with
CLOS that some people indicated there were problems with.

This is the way it reads now:

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

Would anyone like to suggest some alternate wording?

A problem with the existing language that occurs to me is that the
previous paragraph of the proposal says that type specifiers
introduced with DEFTYPE or DEFCLASS must be defined the same at
runtime as at compiletime.  The idea is that, if the compiler is
allowed to "wire in" type information (by making use of declarations,
for example), those types have to fit into the type hierarchy in the
same way at runtime as at compiletime.  To me it seems like these same
considerations must also apply to types introduced by DEFCLASS,
regardless of the metaclass involved. 

-Sandra
-------

∂27-Feb-89  0949	Common-Lisp-Object-System-mailer 	Re: Comments on metaobject draft 10 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 27 Feb 89  09:49:36 PST
Received: by ti.com id AA22922; Mon, 27 Feb 89 11:49:05 CST
Received: from Kelvin by tilde id AA12476; Mon, 27 Feb 89 11:39:29 CST
Message-Id: <2813593142-13589117@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 27 Feb 89  11:39:02 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: David Moon <moon@scrc-pegasus>
Cc: Common-Lisp-Object-System@sail.stanford.edu
Subject: Re: Comments on metaobject draft 10
In-Reply-To: Msg of Fri, 17 Feb 89 01:05:53 est from David Moon <moon@scrc-pegasus>

> 3-50: The ensure-class-using-class generic function should not have
> &allow-other-keys in its arglist.  Recall that this means that there
> should never be any argument checking on calls to this generic function,
> which seems unlikely to be what you want.

I was assuming that it shouldn't do argument checking at that level in
order to permit user-defined metaclasses to extend the set of valid class
options.  Presumably the SHARED-INITIALIZE method [p. 3-62] will do the
necessary error checking, but it would help to have that pointed out on
page 3-50.

∂27-Feb-89  0950	Common-Lisp-Object-System-mailer 	Re: Comments on metaobject draft 10 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 27 Feb 89  09:50:26 PST
Received: by ti.com id AA22940; Mon, 27 Feb 89 11:49:30 CST
Received: from Kelvin by tilde id AA12539; Mon, 27 Feb 89 11:41:02 CST
Message-Id: <2813593245-13595305@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 27 Feb 89  11:40:45 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: David Moon <moon@PEGASUS.SCRC.Symbolics.COM>
Cc: Common-Lisp-Object-System@sail.stanford.edu
Subject: Re: Comments on metaobject draft 10
In-Reply-To: Msg of Fri, 17 Feb 89 01:05:53 est from David Moon <moon@scrc-pegasus>

> 3-50: The ensure-class-using-class generic function should not have
> &allow-other-keys in its arglist.  Recall that this means that there
> should never be any argument checking on calls to this generic function,
> which seems unlikely to be what you want.

I was assuming that it shouldn't do argument checking at that level in
order to permit user-defined metaclasses to extend the set of valid class
options.  Presumably the SHARED-INITIALIZE method [p. 3-62] will do the
necessary error checking, but it would help to have that pointed out on
page 3-50.

∂06-Mar-89  1345	Common-Lisp-Object-System-mailer 	Re: CLOS questions   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 6 Mar 89  13:45:34 PST
Received: by ti.com id AA02960; Mon, 6 Mar 89 11:50:02 CST
Received: from Kelvin by tilde id AA04365; Mon, 6 Mar 89 11:36:08 CST
Message-Id: <2814197751-13712027@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 6 Mar 89  11:35:51 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Patrick Dussud <dussud@lucid.com>
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu, masinter.pa@Xerox.COM
Subject: Re: CLOS questions
In-Reply-To: Msg of Tue, 21 Feb 89 10:43:04 PST from Patrick Dussud <dussud@lucid.com>

>    I'm a little confused by the way that SLOT-BOUNDP [p. 2-75],
>    SLOT-EXISTS-P [p. 2-76], and SLOT-MAKUNBOUND [p. 2-77] are specified as
>    generic functions with a primary method on class STANDARD-OBJECT which
>    just invokes a SLOT-...-USING-CLASS generic function.  Do these really
>    need to be generic at both levels?  According to the specification,
>    SLOT-BOUNDP, for example, should be implemented as   ...
>    Note that the latter parallels the way that SLOT-VALUE is specified.
> 
> I think we said that was a bug. They all should be functions like slot-value.

Fine, but then shouldn't there be a cleanup proposal to correct this?  I
don't think I've seen one.

∂06-Mar-89  1356	Common-Lisp-Object-System-mailer 	CLOS questions  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Mar 89  13:56:43 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA02312g; Mon, 6 Mar 89 13:48:46 PST
Received: by challenger id AA25817g; Mon, 6 Mar 89 13:44:12 PST
Date: Mon, 6 Mar 89 13:44:12 PST
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8903062144.AA25817@challenger>
To: Gray@DSG.csc.ti.com
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu, masinter.pa@Xerox.COM
In-Reply-To: David N Gray's message of Mon, 6 Mar 89  11:35:51 CST <2814197751-13712027@Kelvin>
Subject: CLOS questions


   Sender: GRAY@Kelvin.csc.ti.com
   Date: Mon, 6 Mar 89  11:35:51 CST
   From: David N Gray <Gray@DSG.csc.ti.com>

   >    I'm a little confused by the way that SLOT-BOUNDP [p. 2-75],
   >    SLOT-EXISTS-P [p. 2-76], and SLOT-MAKUNBOUND [p. 2-77] are specified as
   >    generic functions with a primary method on class STANDARD-OBJECT which
   >    just invokes a SLOT-...-USING-CLASS generic function.  Do these really
   >    need to be generic at both levels?  According to the specification,
   >    SLOT-BOUNDP, for example, should be implemented as   ...
   >    Note that the latter parallels the way that SLOT-VALUE is specified.
   > 
   > I think we said that was a bug. They all should be functions like slot-value.

   Fine, but then shouldn't there be a cleanup proposal to correct this?  I
   don't think I've seen one.


I don't think that we need a cleanup item for this. I think an editorial
change suffices. 

Patrick.

∂06-Mar-89  1840	Common-Lisp-Object-System-mailer 	remote environments  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89  18:39:50 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551871; Mon 6-Mar-89 21:37:29 EST
Date: Mon, 6 Mar 89 21:37 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: remote environments
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Compiler@SAIL.Stanford.edu
In-Reply-To: <2813272681-7847725@Kelvin>
Message-ID: <19890307023706.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 23 Feb 89  18:38:01 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    I think it might help to focus the discussion about remote environments
    and meta object programming if we had a clearer picture of what the
    goals are.  The basic question is what kinds of things can be defined and
    then used during compilation of the same file that defines them, and
    what restrictions might apply.

I think you're right.  Let me offer my opinions on the set of issues
you have articulated.

    DEFCLASS 
      * Can the class be used as a superclass of a later DEFCLASS?  [clearly yes]
      * Can it be used as a specializer in a DEFMETHOD?  [clearly yes]
Agreed.
      * Can a MAKE-INSTANCE be done by a macro expander, DEFCONSTANT, or "#."?

I have two answers to this, both based on current practice but
contradictory.  One is that I have some users who really need to be able
to instantiate such classes in macro expanders.  They have an embedded
language which has an object-oriented representation for programs;
therefore macro expansions include instances of classes defined earlier
in the same file.  The second is that Flavors does not support
instantiation of compile-time classes in the Symbolics implementation,
consequently the users I mentioned are currently operating with a kludge.

I think it would be much nicer if we could make compile-time classes
instantiable.  However, I agree that it would not ruin the language to
omit that feature if we can't figure out how to do it.

	 - If so, do initforms have access to macros and constants defined
	   earlier in the file?

Initforms certainly have access to those things since they are included
in the initforms' environment.  I think 88-002R implies this.

      * Can the class be used as the :METACLASS option of a later DEFCLASS?
	 - Can that second class be instantiated?
      * Can it be used as the :GENERIC-FUNCTION-CLASS option of a
	DEFGENERIC, GENERIC-FUNCTION, GENERIC-FLET, or GENERIC-LABELS?
      * Can it be used as the :METHOD-CLASS option of a DEFGENERIC etc.?
	 - Can DEFMETHODs then be done for that generic function?

The answers to these three should be the same and should depend just on
whether a remote (aka compile-time) class can be instantiated.  If yes,
then the subsidiary questions are clearly also yes.

    DEFGENERIC
      * Referenced by later DEFMETHOD? [clearly yes]
      * Is the function defined such that it can be called at compile time?

Clearly not, since a DEFUN is not.  Here I think we should defer to the
definition of how COMPILE-FILE deals with DEFUN and not try to propose
something "better" that is just for CLOS.  In fact I do have something
better in mind, in which COMPILE-FILE would be less different from
normal Lisp evaluation.  But I don't think it would be appropriate to
propose something so radical for Common Lisp at its current life stage.

    DEFMETHOD
      * Can it be invoked at compile-time?
      * In particular, will methods added to standard generic functions be
	invoked by the system at compile time?

No, and no, for the same reason.

When you compile-file a DEFMETHOD, a method metaobject is created but it
is not added to the generic-function metaobject in the local environment.
Instead it is added to a different generic-function metaobject created
in the remote environment.  That's my model of what has to happen.  Note
that this should be completely consistent with the way that compile-file
of a DEFCLASS, with a direct superclass whose name is defined in the 
local environment and not in the remote environment, does not add the
new class metaobject to the direct subclasses of the local superclass,
but rather to a different object.  (I realize we haven't agreed on what
this paragraph says, or even seen a coherent proposal, yet.  I'm just
telling you my model.)

    DEFINE-METHOD-COMBINATION
      * Used in a later DEFGENERIC?
	 - Callable at compile-time?

I believe this should be yes to both, although if I'm not mistaken
Flavors does not allow it.  I think that's a bad design choice in
Flavors.

    Are there other interactions that need to be considered?

I can make a few other points.  Assuming remote classes can be
instantiated, remote methods specialized to a remote class of course
cannot be executed.  However, nothing stops us from making a local
method specialized to a remote class.  There happens not to be a
defmethod syntax for doing that [although in fact one could imagine
such an extension], but it should be easy to do with the interface
at the next level down.  That's a benefit from the clear separation
between names and objects for which CLOS is striving.

In the past there has been some controversy about whether the remote
environment can inherit from the local environment.  I think this is
crystal clear: since some user-defined classes have STANDARD-OBJECT
as a direct superclass, and STANDARD-OBJECT is not defined in the same
file, the remote environment is clearly inheriting from the local
environment.  Different implementations might want to address the
details of this differently, but I think it's clear that there has to
be provision for it in the metaobject model.  It makes things more
complicated, but that's unavoidable.

    I think that the standard could take a simple, minimal, approach that
    would still satisfy the most common usages.  Suppose we said:

    DEFCLASS
      If it appears at top-level, then the class name is defined for use as
      a type specifier or method specializer.  It can also be used as a
      superclass of a later DEFCLASS since they don't have to be defined
      before being referenced anyway.  The class object can be obtained by
      calling FIND-CLASS with an environment argument, but it can only be
      used in ways that do not require the class to be finalized.  For
      example, one could ask for its CLASS-DIRECT-SUPERCLASSES, but not its
      CLASS-PRECEDENCE-LIST.  Other uses, which could involve the need to
      instantiate the class, could not be portably done in the same file
      without wrapping an (EVAL-WHEN (EVAL COMPILE LOAD) ...) around the
      DEFCLASS.  Implementations would be free to support compile-time
      instantiation as an extension.  One way to look at this would be to
      say that it is implementation-dependent whether FINALIZE-INHERITANCE
      works or signals an error when given a class defined in the
      compile-time environment.

    [And no compile-time generic-function or method objects at all]

This is an interesting idea, but I think it's too restrictive.  Here's a
plausible and many-times proposed application for metaobjects which
would not be possible if we adopted this idea.  Suppose you made an
optimizing compiler that is allowed to assume that no class
redefinitions, no method redefinitions, and no newly-defined subclasses
will be created at run time.  The compiler is to take advantage of this
constraint on the program to generate more efficient code by doing type
propagation and constant-folding out many method lookups and slot
lookups.  One should expect many CLOS programs compiled this way to have
the same efficiency as C++ without suffering the same restrictions
during development.  Now, the natural way to organize the datastructures
in this compiler is as metaobjects.  CLOS (chapter 3 at least) already
defines how to access the information the compiler needs.  The
constraint against run-time redefinition means the compiler can assume
certain functions of metaobjects return the same result at compile time
as they must at run time.  For this to work all the metaobjects must
exist and finalization must possible.  It doesn't appear that
instantiation is required, assuming the program being compiled doesn't
define any metaclasses.

I hope to keep thinking in this direction.

∂07-Mar-89  1546	Common-Lisp-Object-System-mailer 	Re: remote environments   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Mar 89  15:46:17 PST
Received: from Semillon.ms by ArpaGateway.ms ; 07 MAR 89 15:39:49 PST
Date: 7 Mar 89 15:39 PST
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: remote environments
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Mon, 6 Mar 89 21:37 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: David N Gray <Gray@DSG.csc.ti.com>,
 Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Compiler@SAIL.Stanford.edu
Message-ID: <890307-153949-8334@Xerox>

I agree with Gray and you.  There is further internal evidence in your
message that we will have to allow instances of classes defined in the file
being compiled to be instantiated.  You answer for:
      DEFINE-METHOD-COMBINATION
        * Used in a later DEFGENERIC?
	   - Callable at compile-time?

    Moon: I believe this should be yes to both, although if I'm not
    mistaken Flavors does not allow it.  I think that's a bad design
    choice in Flavors.

I agree.  And the metaobject protocol specifies that this
definition can define a new method-combination class.
An instance of this class is used in the DEFGENERIC to effect the
method combination.  This implies an ability to instantiate
a newly defined class at compile time to implement this capability.
Another reason to answer the instntiation question YES.

∂08-Mar-89  1722	Common-Lisp-Object-System-mailer 	macroexpansions of the user interface macros  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Mar 89  17:22:48 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 553444; Wed 8-Mar-89 20:20:16 EST
Date: Wed, 8 Mar 89 20:20 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: macroexpansions of the user interface macros
To: Gregor.pa@xerox.com
cc: Common-Lisp-Object-System@sail.stanford.edu
Message-ID: <19890309012005.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

I think I made some substantial progress in figuring out the
macroexpansions of the user interface macros, although I don't
have anything to show yet.  I am currently up against a roadblock
and I wonder if you can shed any light on it.  The briefest
description of the problem is that your metaobject document seems
confused about where the name-to-object translations happen.
For defclass, is it inside of ensure-class or outside of it?
The most problematic name-to-object translation is the one from
the surface syntax of slot definitions to the direct-slot-definition
objects.

Don't debug the document right now, just tell me whether your philosophy
is to put it inside or outside of ensure-class.

∂09-Mar-89  0802	Common-Lisp-Object-System-mailer 	macroexpansions of the user interface macros  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89  08:02:07 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 553668; Thu 9-Mar-89 10:59:28 EST
Date: Thu, 9 Mar 89 10:59 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: macroexpansions of the user interface macros
To: Gregor.pa@xerox.com
cc: Common-Lisp-Object-System@sail.stanford.edu
In-Reply-To: <19890309012005.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890309155907.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

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

    I am currently up against a roadblock
    and I wonder if you can shed any light on it.  The briefest
    description of the problem is that your metaobject document seems
    confused about where the name-to-object translations happen.
    For defclass, is it inside of ensure-class or outside of it?
    The most problematic name-to-object translation is the one from
    the surface syntax of slot definitions to the direct-slot-definition
    objects.

Never mind.  I figured out that your philosophy is that the
programmer interface macros only do parsing, not name-to-object
translation.  All the name-to-object translation is inside
of ensure-class.  That's okay with me, I'll proceed that way.

∂09-Mar-89  1102	CL-Compiler-mailer 	Issue MACRO-ENVIRONMENT-EXTENT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89  11:02:43 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 553814; Thu 9-Mar-89 13:59:24 EST
Date: Thu, 9 Mar 89 13:59 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue MACRO-ENVIRONMENT-EXTENT
To: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>, sandra%defun@CS.UTAH.EDU
cc: cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <12472024104.5.IIM@ECLA.USC.EDU>
Message-ID: <19890309185905.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sun 19 Feb 89 15:54:36-PST
    From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>

    The extent of macro environment objects is related to EVAL-WHEN because macro
    expanders may wish to return forms which contain environments as quoted
    constants.  

I am convinced that this should be ruled out, and that CLOS made a mistake
here.  (Incidentally the part of CLOS that says this is in chapter 3, the
accepted part of CLOS does not say anything about the expansion of the
macros is.)

    ....
    Requiring environments to have indefinite extent has
    problems for CLOS because at compile-time it wants to create remote metaobjects
    and link them into the right places, but then flush those links when the
    compilation is over.  

This depends on whether you think the environment actually contains the
table that relates names to objects, or just contains a boolean flag
that tells functions such as FIND-CLASS which of two tables to look in.
Under the latter model, nothing about the environment prevents the
COMPILE-FILE table from being reset at any time.  This is one reason
why I think the second model is right.

As far as MACRO-ENVIRONMENT-EXTENT itself goes, I am convinced it should
be dynamic extent.  I'm also convinced that the decision on this issue
does not affect CLOS.

∂09-Mar-89  1301	Common-Lisp-Object-System-mailer 	Re: Issue: LOAD-OBJECTS (Version 2) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89  13:01:40 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554005; Thu 9-Mar-89 15:58:57 EST
Date: Thu, 9 Mar 89 15:58 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: LOAD-OBJECTS (Version 2)
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU
In-Reply-To: <2809731258-5200907@Kelvin>
Message-ID: <19890309205844.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 13 Jan 89  18:54:18 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    This looks good.  The only thing I have doubts about is:

    >   The function MAKE-LOAD-FORM-USING-SLOTS can be useful in user-written
    >   MAKE-LOAD-FORM methods.  Its first argument is the object.  Its
    >   optional second argument is a list of the names of the slots to
    >   preserve; it defaults to all of the local slots.
    >   MAKE-LOAD-FORM-USING-SLOTS returns forms that construct an equivalent
    >   object using MAKE-INSTANCE and SETF of SLOT-VALUE for slots with
    >   values, or SLOT-MAKUNBOUND for slots without values, or using other
    >   functions of equivalent effect. 

    Rather than having the second argument default to a list of all instance
    slots, it might be better to consider two separate cases:

      1. If a second argument is supplied, then MAKE-INSTANCE will be used to
	 create the object, (using INITIALIZE-INSTANCE to default the slot
	 values), and then the designated slots will be forced to
	 have the proper value.

      2. Without a second argument, ALLOCATE-INSTANCE will be used to create
	 the object (without invoking INITIALIZE-INSTANCE or
	 SHARED-INITIALIZE), and then all the slots will be filled in.

    If you are going to specify all of the slot values, then there shouldn't
    be a need to compute default values, and it may be undesirable to invoke
    INITIALIZE-INSTANCE -- for example, it might complain about missing
    required arguments or perform undesired side-effects.

I don't think it's a good idea to have such a large deviation in behavior
based on whether an optional argument is present or not.  What if the
argument is present but its value is a list of all the slots?

I personally cannot figure out whether calling INITIALIZE-INSTANCE when
it's not wanted, or failing to call it when it is wanted, would cause
more unexpected behavior.  I have to resolve that by keeping it simple
so the programmer can figure it out on his own.  So I think it should
always create the object with MAKE-INSTANCE.

    >   The default MAKE-LOAD-FORM method for STANDARD-OBJECT signals an
    >   error.

    Wouldn't it be permissible to just not have a default method, so that a
    "no applicable method" error is signalled?

Agreed.

∂09-Mar-89  1325	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89  13:25:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554041; Thu 9-Mar-89 16:22:52 EST
Date: Thu, 9 Mar 89 16:22 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-OBJECTS (Version 2)
To: John Rose <jrose@Sun.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU,
    CL-Compiler@SAIL.STANFORD.EDU
In-Reply-To: <8901140458.AA18401@lukasiewicz.sun.com>
Message-ID: <19890309212238.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 13 Jan 89 20:58:49 PST
    From: jrose@Sun.COM (John Rose)

      ...
	 The creation form for an object is always evaluated before the
	 initialization form for that object.  When either the creation form or
	 the initialization form references other objects of user-defined types
	 that have not been referenced earlier in the COMPILE-FILE, the
	 compiler collects all of the creation forms together and collects all
	 of the initialization forms together.  All of the creation forms are
	 evaluated before any of the initialization forms.  The order of
	 evaluation of the creation forms is unspecified except when the
	 ordering is forced by data dependencies.  The order of evaluation of
	 the initialization forms is unspecified.
      ...
    Why does the proposal restrict the evaluation initialization forms to
    such a late time?  Data dependencies would allow an object X's
    initialization form to be executed any time after X's creation form had
    finished.

    Actually, it would be better (and no more difficult, it seems to me) to
    be strict in the other direction: Objects should be initialized as early
    as possible, and hence at a deterministic time.  This would allow nodes
    in non-circular structures to be built out of fully initialized subparts,
    which is clearly something an application could need.

Good point.  I've modified the proposal accordingly, although I did not use
your exact wording.  Of course the time is not fully determinstic, but
it's more deterministic than in version 2 of the proposal.

∂09-Mar-89  1329	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89  13:29:07 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554052; Thu 9-Mar-89 16:26:35 EST
Date: Thu, 9 Mar 89 16:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-OBJECTS (Version 3)
To: CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu, Common-Lisp-Object-System@sail.stanford.edu
Message-ID: <19890309212623.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

At Kauai I was asked to keep working on this and come up with a modified
version based on comments received.  Here it is.  I hope this is ready
for voting so we can clear it out of the way.

Issue:         LOAD-OBJECTS

References:    none

Related issues: LOAD-TIME-EVAL,
                CONSTANT-COMPILABLE-TYPES,
                CONSTANT-CIRCULAR-COMPILATION

Category:      ADDITION

Forum:         Cleanup

Edit history:  Version 1, 2-Jan-89, by Moon (for discussion)
               Version 2, 13-Jan-89, by Moon (draft updated from discussion)
               Version 3,  9-Mar-89, by Moon (changes suggested by discussion)

Problem description:

  Common Lisp doesn't provide any way to use an object of a user-defined
  type (defined with DEFCLASS or DEFSTRUCT) as a constant in a program
  compiled with COMPILE-FILE.  The problem is that LOAD has to be able
  to "reconstruct" an equivalent object when the compiled-code file is
  loaded, but the programmer has no way to tell LOAD how to do that.


Proposal (LOAD-OBJECTS:MAKE-LOAD-FORM):
          
  Define a new generic function named MAKE-LOAD-FORM, which takes one
  argument and returns two values.  The argument is an object that is
  referenced as a constant or as a self-evaluating form in a file being
  compiled by COMPILE-FILE.  The objective is to enable LOAD to
  construct an equivalent object.

  The first value, called the "creation form," is a form that, when
  evaluated at load time, should return an object that is equivalent to
  the argument.  The exact meaning of "equivalent" depends on the type
  of object and is up to the programmer who defines a method for
  MAKE-LOAD-FORM.  This is the same type of equivalence discussed
  in issue CONSTANT-COMPILABLE-TYPES.

  The second value, called the "initialization form," is a form that,
  when evaluated at load time, should perform further initialization of
  the object.  The value returned by the initialization form is ignored.
  If the MAKE-LOAD-FORM method returns only one value, the
  initialization form is NIL, which has no effect.  If the object used
  as the argument to MAKE-LOAD-FORM appears as a constant in the
  initialization form, at load time it will be replaced by the
  equivalent object constructed by the creation form; this is how the
  further initialization gains access to the object.

  Both the creation form and the initialization form can contain
  references to objects of user-defined types (defined precisely below).
  However, there must not be any circular dependencies in creation forms.
  An example of a circular dependency is when the creation form for the
  object X contains a reference to the object Y, and the creation form
  for the object Y contains a reference to the object X.  A simpler
  example would be when the creation form for the object X contains
  a reference to X itself.  Initialization forms are not subject to
  any restriction against circular dependencies, which is the entire
  reason that initialization forms exist.  See the example of circular
  data structures below.

  The creation form for an object is always evaluated before the
  initialization form for that object.  When either the creation form or
  the initialization form references other objects of user-defined types
  that have not been referenced earlier in the COMPILE-FILE, the
  compiler collects all of the creation and initialization forms.  Each
  initialization form is evaluated as soon as possible after its
  creation form, as determined by data flow.  If the initialization form
  for an object does not reference any other objects of user-defined
  types that have not been referenced earlier in the COMPILE-FILE, the
  initialization form is evaluated immediately after the creation form.
  If a creation or initialization form F references other objects of
  user-defined types that have not been referenced earlier in the
  COMPILE-FILE, the creation forms for those other objects are evaluated
  before F, and the initialization forms for those other objects are
  also evaluated before F whenever they do not depend on the object
  created or initialized by F.  Where the above rules do not uniquely
  determine an order of evaluation, which of the possible orders of
  evaluation is chosen is unspecified.

  While these creation and initialization forms are being evaluated, the
  objects are possibly in an uninitialized state, analogous to the state
  of an object between the time it has been created by ALLOCATE-INSTANCE
  and it has been processed fully by INITIALIZE-INSTANCE.  Programmers
  writing methods for MAKE-LOAD-FORM must take care in manipulating
  objects not to depend on slots that have not yet been initialized.

  It is unspecified whether LOAD calls EVAL on the forms or does some
  other operation that has an equivalent effect.  For example, the
  forms might be translated into different but equivalent forms and
  then evaluated, they might be compiled and the resulting functions
  called by LOAD, or they might be interpreted by a special-purpose
  interpreter different from EVAL.  All that is required is that the
  effect be equivalent to evaluating the forms.

  COMPILE-FILE calls MAKE-LOAD-FORM on any object that is referenced as
  a constant or as a self-evaluating form, if the object's metaclass is
  STANDARD-CLASS, STRUCTURE-CLASS, any user-defined metaclass (not a
  subclass of BUILT-IN-CLASS), or any of a possibly-empty
  implementation-defined list of other metaclasses.  COMPILE-FILE will
  only call MAKE-LOAD-FORM once for any given object (compared with EQ)
  within a single file.

  It is valid for user programs to call MAKE-LOAD-FORM in other
  circumstances, providing the argument's metaclass is not BUILT-IN-CLASS
  or a subclass of BUILT-IN-CLASS.

  Define a new function named MAKE-LOAD-FORM-USING-SLOTS, which takes
  one required argument and one optional argument and returns two
  values.  This can be useful in user-written MAKE-LOAD-FORM methods.
  The first argument is the object.  The optional second argument is a
  list of the names of the slots to preserve; it defaults to all of the
  local slots.  MAKE-LOAD-FORM-USING-SLOTS returns forms that construct
  an equivalent object using MAKE-INSTANCE and SETF of SLOT-VALUE for
  slots with values, or SLOT-MAKUNBOUND for slots without values, or
  using other functions of equivalent effect.
  MAKE-LOAD-FORM-USING-SLOTS returns two values, thus it can deal with
  circular structures.  MAKE-LOAD-FORM-USING-SLOTS works for any object
  of metaclass STANDARD-CLASS or STRUCTURE-CLASS.  Whether the result is
  useful in an application depends on whether the object's type and slot
  contents fully capture the application's idea of the object's state.

  MAKE-LOAD-FORM of an object of metaclass STANDARD-CLASS or
  STRUCTURE-CLASS for which no user-defined method is applicable signals
  an error.  It is valid to implement this either by defining default
  methods on STANDARD-OBJECT and STRUCTURE-OBJECT that signal an error
  or by having no applicable method for those classes.


Examples:

  ;; Example 1
  (defclass my-class ()
     ((a :initarg :a :reader my-a)
      (b :initarg :b :reader my-b)
      (c :accessor my-c)))
  (defmethod shared-initialize ((self my-class) ignore &rest ignore)
    (unless (slot-boundp self 'c)
      (setf (my-c self) (some-computation (my-a self) (my-b self)))))
  (defmethod make-load-form ((self my-class))
    `(make-instance ',(class-name (class-of self))
                    :a ',(my-a self) :b ',(my-b self)))

  In this example, an equivalent instance of my-class is reconstructed
  by using the values of two of its slots.  The value of the third slot
  is derived from those two values.

  Another way to write the last form in the above example would have been

  (defmethod make-load-form ((self my-class))
     (make-load-form-using-slots self '(a b)))

  ;; Example 2
  (defclass my-frob ()
     ((name :initarg :name :reader my-name)))
  (defmethod make-load-form ((self my-frob))
    `(find-my-frob ',(my-name self) :if-does-not-exist :create))

  In this example, instances of my-frob are "interned" in some way.
  An equivalent instance is reconstructed by using the value of the
  name slot as a key for searching existing objects.  In this case
  the programmer has chosen to create a new object if no existing
  object is found; alternatively she could have chosen to signal an
  error in that case.

  ;; Example 3
  (defclass tree-with-parent () ((parent :accessor tree-parent)
                                 (children :initarg :children)))
  (defmethod make-load-form ((x tree-with-parent))
    (values
      ;; creation form
      `(make-instance ',(class-of x) :children ',(slot-value x 'children))
      ;; initialization form
      `(setf (tree-parent ',x) ',(slot-value x 'parent))))

  In this example, the data structure to be dumped is circular, because
  each parent has a list of its children and each child has a reference
  back to its parent.  Suppose make-load-form is called on one object in
  such a structure.  The creation form creates an equivalent object and
  fills in the children slot, which forces creation of equivalent
  objects for all of its children, grandchildren, etc.  At this point
  none of the parent slots have been filled in.  The initialization form
  fills in the parent slot, which forces creation of an equivalent
  object for the parent if it was not already created.  Thus the entire
  tree is recreated at load time.  At compile time, MAKE-LOAD-FORM is
  called once for each object in the true.  All of the creation forms
  are evaluated, in unspecified order, and then all of the
  initialization forms are evaluated, also in unspecified order.

  ;; Example 4
  (defstruct my-struct a b c)
  (defmethod make-load-form ((s my-struct))
     (make-load-form-using-slots s))

  In this example, the data structure to be dumped has no special
  properties and an equivalent structure can be reconstructed
  simply by reconstructing the slots' contents.


Rationale:

  Only the programmer who designed a class can know the correct
  way to reconstruct objects of that class at load time, therefore
  the reconstruction should be controlled by a generic function.
  Using EVAL as the interface for telling LOAD what to do provides
  full generality.

  MAKE-LOAD-FORM returns two values so that circular structures can
  be handled.  If CONSTANT-CIRCULAR-COMPILATION is rejected,
  MAKE-LOAD-FORM will only return one value, although implementations
  that make an extension to support circular constants will probably
  also make the extension to accept two values from MAKE-LOAD-FORM.

  The default for class objects and structures is to signal an error,
  rather than picking some particular object reconstruction technique,
  because no reconstruction technique is appropriate for all objects.
  It only takes two lines of code, as in example 4, to instruct the
  compiler to use the technique that most often has been suggested
  as the default.

  MAKE-LOAD-FORM has a natural resemblance to PRINT-OBJECT, as a hook
  for the programmer to control the system's actions.

  The order of evaluation rules for creation and initialization forms
  eliminate the possibility of partially initialized objects in the
  absence of circular structures, and reduce it to the minimum possible
  in the presence of circular structures.  This allows nodes in
  non-circular structures to be built out of fully initialized subparts.


Current practice:

  Symbolics Flavors has something like this, but under a different name.
  The name Symbolics uses is not suitable for standardization.

  JonL reports that Lucid is getting more and more requests for this.

Cost to Implementors:

  This seems like only a few one-line changes in the compiled-code
  file writer and reader.  MAKE-LOAD-FORM-USING-SLOTS is a couple
  dozen lines of code, assuming the presence of the CLOS metaobject
  protocol or an implementation-dependent equivalent.

Cost to Users:

  None.

Cost of non-adoption:

  Serious impairment of the ability to use extended-type objects.  Each
  implementation will probably make up its own version of this as an
  extension.

Performance impact:

  None.

Benefits:

  See Cost of non-adoption.

Esthetics:

  No significant positive or negative impact.

Discussion:

  It would be possible to define an additional level of protocol that
  allows multiple classes to contribute to the reconstruction of an
  object, combining initialization arguments contributed by each class.
  Since a user can easily define that in terms of MAKE-LOAD-FORM without
  modifying the Lisp system, it is not being proposed now.

  Any type that has a read syntax is likely to appear as a quoted
  constant or inside a quoted constant.  Pathnames are one example, user
  programs often define others.  Also many implementations provide a way
  to create a compiled-code file full of data (rather than compiled Lisp
  programs), and such data probably include extended-type objects.

  Moon supports this.  David Gray and John Rose made major contributions
  to the discussion that produced this improved version 2 proposal.

∂09-Mar-89  1619	Common-Lisp-Object-System-mailer 	issue CLOS-MACRO-COMPILATION   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 9 Mar 89  16:19:35 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA06189; Thu, 9 Mar 89 17:17:27 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA10108; Thu, 9 Mar 89 17:17:24 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903100017.AA10108@defun.utah.edu>
Date: Thu, 9 Mar 89 17:17:22 MST
Subject: issue CLOS-MACRO-COMPILATION
To: Gregor.pa@Xerox.COM
Cc: cl-compiler@sail.stanford.edu, common-lisp-object-system@sail.stanford.edu
In-Reply-To: Gregor.pa@Xerox.COM, Thu, 23 Feb 89 20:23 PST

Have you made any progress yet on settling on your new model of how
the CLOS defining macros work?  I have opened a new cl-compiler issue,
CLOS-MACRO-COMPILATION, for this, but I don't yet have a proposal.
(Or even a problem statement written down, for that matter.)  I am 
planning to distribute the rest of our issues to X3J13 early next 
week and would like to have at least a draft ready by then.  If you
don't think that's possible, I will have to say in our report that
we need an extension to get this issue resolved.

-Sandra
-------

∂09-Mar-89  1708	CL-Compiler-mailer 	issue CLOS-MACRO-COMPILATION  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89  17:08:20 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554334; Thu 9-Mar-89 20:05:08 EST
Date: Thu, 9 Mar 89 20:04 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CLOS-MACRO-COMPILATION
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: Gregor.pa@Xerox.COM, cl-compiler@sail.stanford.edu, common-lisp-object-system@sail.stanford.edu
In-Reply-To: <8903100017.AA10108@defun.utah.edu>
Message-ID: <19890310010446.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: Thu, 9 Mar 89 17:17:22 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    Have you made any progress yet on settling on your new model of how
    the CLOS defining macros work?  

I didn't get a chance to talk with Gregor when he was here a couple
days ago, but I have made some progress on this myself.  However, it's
not ready to show to anyone yet.

				    I have opened a new cl-compiler issue,
    CLOS-MACRO-COMPILATION, for this, but I don't yet have a proposal.
    (Or even a problem statement written down, for that matter.)  I am 
    planning to distribute the rest of our issues to X3J13 early next 
    week and would like to have at least a draft ready by then.  If you
    don't think that's possible, I will have to say in our report that
    we need an extension to get this issue resolved.

What I'm doing won't be ready to show to X3J13 that soon.  However,
assuming that eval-when is settled now, I don't think what I'm doing
will have any effect on X3J13 as it should be all at the metaobject
level.  I guess I won't know that for sure until I'm done.

∂10-Mar-89  1258	Common-Lisp-Object-System-mailer 	issue CLOS-MACRO-COMPILATION, version 1  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 10 Mar 89  12:58:24 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA03202; Fri, 10 Mar 89 13:56:09 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA10809; Fri, 10 Mar 89 13:56:06 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903102056.AA10809@defun.utah.edu>
Date: Fri, 10 Mar 89 13:56:05 MST
Subject: issue CLOS-MACRO-COMPILATION, version 1
To: cl-compiler@sail.stanford.edu, common-lisp-object-system@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 9 Mar 89 20:04 EST

Here is a first cut at getting something written down on this issue.
This is mostly extracted from David Gray's list of questions and
Moon's responses.  To me it seems like the question where there is the
most disagreement is whether or not classes are required to be
instantiable at compile-time, so I have made two proposals.  MINIMAL
leaves this unspecified, and NOT-SO-MINIMAL requires them to be
instantiable.

Forum:		Compiler
Issue:		CLOS-MACRO-COMPILATION
References:	CLOS chapters 1 & 2 (88-002R)
		CLOS chapter 3 (89-003)
		Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
		Issue DEFINING-MACROS-NON-TOP-LEVEL
Category:	CLARIFICATION
Edit History:   V1, 10 Mar 1989, Sandra Loosemore
Status:		**DRAFT**


Problem Description:

Do the CLOS defining macros (DEFCLASS, DEFMETHOD, DEFGENERIC, and
DEFINE-METHOD-COMBINATION) have compile-time side-effects similar
to those for DEFSTRUCT or DEFMACRO?

A part of the problem is that we do not currently have a full
understanding of all the issues involved.  In particular, work on
defining the CLOS meta-object protocol is still in progress.  The goal
is to say enough about the behavior of these macros in the standard so
that users can use them portably in compiled code, but to leave as
much of the behavior as possible unspecified to avoid placing undue
restrictions on the meta-object protocol.

There are two proposals, MINIMAL and NOT-SO-MINIMAL.


Proposal CLOS-MACRO-COMPILATION:MINIMAL:

 State that top-level calls to the CLOS defining macros have the
 following compile-time side-effects.  Any other compile-time behavior
 is explicitly left unspecified.

  DEFCLASS:
  
  * The class name becomes a type specifier which may appear in 
    subsequent type declarations.
  
  * The class name can be used to name a superclass in a subsequent
    DEFCLASS.
  
  * The class name can be used as a specializer in a subsequent 
    DEFMETHOD.
  
  DEFGENERIC:
  
  * The generic function can be referenced in a subsequent DEFMETHOD.  

  * The generic function is not callable at compile-time.
  
  DEFMETHOD:
  
  * The method is not callable at compile-time.  If there is a generic
    function with the same name at compile-time, compiling a DEFMETHOD
    will not add the method to that generic function.  

    [This also seems to imply that tests for existence of the generic 
    function, lambda-list congruence, etc. must not happen until 
    load time.]
  
  DEFINE-METHOD-COMBINATION:
  
  * The method combination can be used in a subsequent DEFGENERIC.  If it
    is referenced, the body of a long form of method combination must be 
    evaluable at compile-time.

 Rationale:

  The compile-time behavior of DEFCLASS is similar to DEFSTRUCT or
  DEFTYPE.  DEFGENERIC and DEFMETHOD are similar to DEFUN.
  DEFINE-METHOD-COMBINATION is similar to DEFMACRO or DEFSETF.

Proposal CLOS-MACRO-COMPILATION:NOT-SO-MINIMAL:

 This is the same as proposal MINIMAL, except under DEFCLASS add:

  * The class may be instantiated at compile-time.  Provided the 
    appropriate methods are also defined at compile-time, this implies:
    - The class can be used as the :METACLASS option of a later DEFCLASS.
    - It can be used as the :GENERIC-FUNCTION-CLASS or :METHOD-CLASS option
      of a DEFGENERIC, GENERIC-FUNCTION, GENERIC-FLET, or GENERIC-LABELS.

 Rationale:

  Being able to instantiate a class at compile-time is somewhat more 
  convenient for users.


Current Practice:

  The items listed under DEFCLASS in proposal MINIMAL are fairly standard
  programming style.

  Flavors does not support compile-time instantiation of classes.  It
  does not make method combinations available at compile-time either, but
  Moon considers that to be a bad design choice.

Cost to implementors:

  Unknown.

Cost to users:

  Unknown, but probably fairly small.

  Note that for proposal NOT-SO-MINIMAL, users still have to ensure that
  any methods on the class which may be invoked at compile-time are 
  fully defined.  This includes the INITIALIZE-INSTANCE and 
  SHARED-INITIALIZE methods that are invoked by MAKE-INSTANCE.

  Wrapping an (EVAL-WHEN (EVAL COMPILE LOAD) ...) around the appropriate
  definitions will make sure they are fully defined at compile-time.
  Alternatively, the definitions could be placed in a separate file,
  which is loaded before compiling the file that depends on those
  definitions.

Benefits:

  Programmers can rely on programs that use the CLOS defining macros 
  being able to compile correctly in all implementations, without having
  to wrap explicit EVAL-WHENs around every macro call.

Discussion:

  Loosemore says:

    Although I admit I don't understand all of the issues involved with
    the meta-object protocol, I support proposal MINIMAL.  I don't think
    leaving the issue of whether or not classes can be instantiated at
    compile-time unspecified places an undue burden on users, and it does
    leave more freedom for the meta-object protocol to decide what the
    right behavior really is.

-------

∂10-Mar-89  1609	Common-Lisp-Object-System-mailer 	class FUNCTION etc.  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 10 Mar 89  16:09:25 PST
Received: by ti.com id AA05516; Fri, 10 Mar 89 17:20:30 CST
Received: from Kelvin by tilde id AA26271; Fri, 10 Mar 89 17:10:23 CST
Message-Id: <2814563376-4811635@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 10 Mar 89  17:09:36 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Common-Lisp-Object-System@SAIL.Stanford.edu
Subject: class FUNCTION etc.

Can someone shed some light on why the pre-defined classes listed on
page 1-17 of document 88-002R are not included in Figure 2-1 on page
2-13 of the Feb 21 standard draft from the editorial committee?  In
particular, since proposal FUNCTION-TYPE has already been passed so that
FUNCTION could be a class, how come it isn't one already?

∂10-Mar-89  1615	Common-Lisp-Object-System-mailer 	Re: remote environments   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 10 Mar 89  16:13:48 PST
Received: by ti.com id AA05503; Fri, 10 Mar 89 17:20:12 CST
Received: from Kelvin by tilde id AA25887; Fri, 10 Mar 89 17:03:00 CST
Message-Id: <2814562938-4785295@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 10 Mar 89  17:02:18 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Danny Bobrow <Bobrow.pa@Xerox.COM>
Cc: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
        Common-Lisp-Object-System@SAIL.Stanford.edu
Subject: Re: remote environments
In-Reply-To: Msg of 7 Mar 89 15:39 PST from Danny Bobrow <Bobrow.pa@Xerox.COM>

> I agree.  And the metaobject protocol specifies that this
> definition can define a new method-combination class.
> An instance of this class is used in the DEFGENERIC to effect the
> method combination.  This implies an ability to instantiate
> a newly defined class at compile time to implement this capability.
> Another reason to answer the instntiation question YES.

I don't see where DEFINE-METHOD-COMBINATION has any option for
specifying the class of the method combination; doesn't it always
produce an instance of the pre-defined class METHOD-COMBINATION ?

∂11-Mar-89  0126	Common-Lisp-Object-System-mailer 	Re: issue CLOS-MACRO-COMPILATION, version 1   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 11 Mar 89  01:25:50 PST
Received: by ti.com id AA05982; Fri, 10 Mar 89 18:21:46 CST
Received: from Kelvin by tilde id AA27610; Fri, 10 Mar 89 18:07:29 CST
Message-Id: <2814566813-5018117@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 10 Mar 89  18:06:53 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, common-lisp-object-system@sail.stanford.edu
Subject: Re: issue CLOS-MACRO-COMPILATION, version 1
In-Reply-To: Msg of Fri, 10 Mar 89 13:56:05 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)

> Proposal CLOS-MACRO-COMPILATION:MINIMAL:
...
>   DEFMETHOD:
>   
>   * The method is not callable at compile-time.  If there is a generic
>     function with the same name at compile-time, compiling a DEFMETHOD
>     will not add the method to that generic function.  
> 
>     [This also seems to imply that tests for existence of the generic 
>     function, lambda-list congruence, etc. must not happen until 
>     load time.]

No, an implementation should be permitted to check for lambda-list
congruence between methods defined in the same file; this doesn't
require any reference to the resident generic function definition.  If
the file doesn't include a DEFGENERIC, then the first DEFMETHOD defines
the compile-time generic function attributes, and subsequent methods can
be checked against that.

>   DEFINE-METHOD-COMBINATION:
>   
>   * The method combination can be used in a subsequent DEFGENERIC.  If it
>     is referenced, the body of a long form of method combination must be 
>     evaluable at compile-time.

But if methods are not installed at compile time and generic functions
are not callable at compile time, then I don't think there is any
situation in which the method combination body could be executed at
compile-time.

∂11-Mar-89  0130	Common-Lisp-Object-System-mailer 	Re: remote environments   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 11 Mar 89  01:29:36 PST
Received: by ti.com id AA05380; Fri, 10 Mar 89 17:04:35 CST
Received: from Kelvin by tilde id AA25717; Fri, 10 Mar 89 16:51:06 CST
Message-Id: <2814562184-4740019@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 10 Mar 89  16:49:44 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu
Subject: Re: remote environments
In-Reply-To: Msg of Mon, 6 Mar 89 21:37 EST from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

> I think it would be much nicer if we could make compile-time classes
> instantiable.  However, I agree that it would not ruin the language to
> omit that feature if we can't figure out how to do it.

I agree that it would be nice, and intend to support it in our
implementation (it's already implemented but has a few problems to be
worked out).  It's just a question of whether it can be specified in a
way that everyone can live with.

> 	 - If so, do initforms have access to macros and constants defined
> 	   earlier in the file?
> 
> Initforms certainly have access to those things since they are included
> in the initforms' environment.  I think 88-002R implies this.

I intend to implement it that way since it is a reasonable thing to
expect.  However, I'm not aware of any language in 88-002R that requires
this ("implies" isn't good enough).  In fact, proposal
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS explicitly says that macro
definitions are _not_ necessarily available to the evaluator during
compile-time evaluations.

>     I think that the standard could take a simple, minimal, approach that
>     would still satisfy the most common usages.  Suppose we said:
> 
>     DEFCLASS
...
>		 One way to look at this would be to
>       say that it is implementation-dependent whether FINALIZE-INHERITANCE
>       works or signals an error when given a class defined in the
>       compile-time environment.
> 
>     [And no compile-time generic-function or method objects at all]
> 
> This is an interesting idea, but I think it's too restrictive.  Here's a
> plausible and many-times proposed application for metaobjects which
> would not be possible if we adopted this idea.  Suppose you made an
> optimizing compiler that is allowed to assume that no class
> redefinitions, no method redefinitions, and no newly-defined subclasses
> will be created at run time.  The compiler is to take advantage of this
...

I certainly don't want to prevent any implementation from doing that.
The real issue is what is the minimal functionality that all
implementations must support.

∂11-Mar-89  0150	Common-Lisp-Object-System-mailer 	Re: Issue MACRO-ENVIRONMENT-EXTENT  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 11 Mar 89  01:48:49 PST
Received: by ti.com id AA04514; Fri, 10 Mar 89 11:03:22 CST
Received: from Kelvin by tilde id AA17547; Fri, 10 Mar 89 10:49:22 CST
Message-Id: <2814540528-3314903@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 10 Mar 89  10:48:48 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: "Kim A. Barrett" <IIM%ECLA@ECLC.USC.EDU>, sandra%defun@CS.UTAH.EDU,
        cl-compiler@SAIL.STANFORD.EDU,
        common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Re: Issue MACRO-ENVIRONMENT-EXTENT
In-Reply-To: Msg of Thu, 9 Mar 89 13:59 EST from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

>     The extent of macro environment objects is related to EVAL-WHEN because macro
>     expanders may wish to return forms which contain environments as quoted
>     constants.  
> 
> I am convinced that this should be ruled out, and that CLOS made a mistake
> here.  (Incidentally the part of CLOS that says this is in chapter 3, the
> accepted part of CLOS does not say anything about the expansion of the
> macros is.)

Except for ENSURE-GENERIC-FUNCTION, which is defined in chapter 2 with an
:ENVIRONMENT argument, and referenced on page 2-28 as part of the
semantics of DEFGENERIC.  Maybe this function should have been in chapter
3 instead?  Should it be removed from the standard?

>     Requiring environments to have indefinite extent has
>     problems for CLOS because at compile-time it wants to create remote metaobjects
>     and link them into the right places, but then flush those links when the
>     compilation is over.  
> 
> This depends on whether you think the environment actually contains the
> table that relates names to objects, or just contains a boolean flag
> that tells functions such as FIND-CLASS which of two tables to look in.
> Under the latter model, nothing about the environment prevents the
> COMPILE-FILE table from being reset at any time.  This is one reason
> why I think the second model is right.

But if you reset the table, then a FIND-CLASS on that environment will no
longer be meaningful, which has the same effect as being outside the valid
extent of the environment.

∂11-Mar-89  0818	Common-Lisp-Object-System-mailer 	Re: issue CLOS-MACRO-COMPILATION, version 1   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 11 Mar 89  08:17:53 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA03974; Sat, 11 Mar 89 09:15:41 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA00548; Sat, 11 Mar 89 09:15:39 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903111615.AA00548@defun.utah.edu>
Date: Sat, 11 Mar 89 09:15:37 MST
Subject: Re: issue CLOS-MACRO-COMPILATION, version 1
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore),
        cl-compiler@sail.stanford.edu,
        common-lisp-object-system@sail.stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Fri, 10 Mar 89  18:06:53 CST

> Date: Fri, 10 Mar 89  18:06:53 CST
> From: David N Gray <Gray@DSG.csc.ti.com>
> 
> >     [This also seems to imply that tests for existence of the generic 
> >     function, lambda-list congruence, etc. must not happen until 
> >     load time.]
> 
> No, an implementation should be permitted to check for lambda-list
> congruence between methods defined in the same file; this doesn't
> require any reference to the resident generic function definition.  If
> the file doesn't include a DEFGENERIC, then the first DEFMETHOD defines
> the compile-time generic function attributes, and subsequent methods can
> be checked against that.

The description of DEFMETHOD in CLOS chapter 2 talks about calling
FBOUNDP and signalling an error if the function is not a generic
function, or if it is a generic function but the lambda list of the
method is not congruent.  Clearly this shouldn't happen at
compile-time.  I agree that the behavior you suggest makes more sense. 

> 
> >   DEFINE-METHOD-COMBINATION:
> >   
> >   * The method combination can be used in a subsequent DEFGENERIC.  If it
> >     is referenced, the body of a long form of method combination must be 
> >     evaluable at compile-time.
> 
> But if methods are not installed at compile time and generic functions
> are not callable at compile time, then I don't think there is any
> situation in which the method combination body could be executed at
> compile-time.

This is something I couldn't quite figure out from reading chapters 1
& 2.  At what time does the method combination become "integrated"
into the DEFGENERIC?  Does the process of expanding the DEFGENERIC
macro capture the method combination definition, in the same way that
expanding a SETF macro captures the setf method?  Or does this happen
when you actually execute the DEFGENERIC macro?

-Sandra
-------

∂11-Mar-89  1220	Common-Lisp-Object-System-mailer 	Re: issue CLOS-MACRO-COMPILATION, version 1   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 11 Mar 89  12:19:38 PST
Received: by ti.com id AA10411; Sat, 11 Mar 89 14:18:09 CST
Received: from Kelvin by tilde id AA14567; Sat, 11 Mar 89 14:14:39 CST
Message-Id: <2814639239-9369595@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Sat, 11 Mar 89  14:13:59 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Cc: cl-compiler@sail.stanford.edu, common-lisp-object-system@sail.stanford.edu
Subject: Re: issue CLOS-MACRO-COMPILATION, version 1
In-Reply-To: Msg of Sat, 11 Mar 89 09:15:37 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)

> The description of DEFMETHOD in CLOS chapter 2 talks about calling
> FBOUNDP and signalling an error if the function is not a generic
> function, or if it is a generic function but the lambda list of the
> method is not congruent.  Clearly this shouldn't happen at
> compile-time. 

Right, unless it is viewed as doing the FBOUNDP in the compile-time
environment without inheritance from the resident environment.

> > But if methods are not installed at compile time and generic functions
> > are not callable at compile time, then I don't think there is any
> > situation in which the method combination body could be executed at
> > compile-time.
> 
> This is something I couldn't quite figure out from reading chapters 1
> & 2.  At what time does the method combination become "integrated"
> into the DEFGENERIC?  Does the process of expanding the DEFGENERIC
> macro capture the method combination definition, in the same way that
> expanding a SETF macro captures the setf method?  Or does this happen
> when you actually execute the DEFGENERIC macro?

This is only in chapter 3, and not very clear there even.  My
understanding of it is that the method combination body would be invoked
from COMPUTE-EFFECTIVE-METHOD, which, depending on the implementation,
could be invoked as soon as a call to ADD-METHOD, or as late as a call
to the generic function which actually needs that particular
combination.  Since it operates on a list of applicable methods, it
couldn't be invoked from DEFGENERIC.  The generic function object would
just have a pointer to the method combination object for future use.

∂11-Mar-89  1439	Common-Lisp-Object-System-mailer 	Re: remote environments   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Mar 89  14:39:22 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 555170; Sat 11-Mar-89 17:36:09 EST
Date: Sat, 11 Mar 89 17:36 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: remote environments
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Danny Bobrow <Bobrow.pa@Xerox.COM>, Common-Lisp-Object-System@SAIL.Stanford.edu
In-Reply-To: <2814562938-4785295@Kelvin>
Message-ID: <19890311223604.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: Fri, 10 Mar 89  17:02:18 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    I don't see where DEFINE-METHOD-COMBINATION has any option for
    specifying the class of the method combination; doesn't it always
    produce an instance of the pre-defined class METHOD-COMBINATION ?

88-002R p. 1-34 says it can make a subclass of METHOD-COMBINATION.
88-002R doesn't specify the implementation of DEFINE-METHOD-COMBINATION,
but it might create a new class for each method combination type.

∂11-Mar-89  1506	Common-Lisp-Object-System-mailer 	Re: remote environments   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Mar 89  15:05:55 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 555182; Sat 11-Mar-89 18:03:02 EST
Date: Sat, 11 Mar 89 18:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: remote environments
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Common-Lisp-Object-System@SAIL.Stanford.edu
In-Reply-To: <2814562184-4740019@Kelvin>
Message-ID: <19890311230257.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 10 Mar 89  16:49:44 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    > 	 - If so, do initforms have access to macros and constants defined
    > 	   earlier in the file?
    > 
    > Initforms certainly have access to those things since they are included
    > in the initforms' environment.  I think 88-002R implies this.

    I intend to implement it that way since it is a reasonable thing to
    expect.  However, I'm not aware of any language in 88-002R that requires
    this ("implies" isn't good enough).  In fact, proposal
    COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS explicitly says that macro
    definitions are _not_ necessarily available to the evaluator during
    compile-time evaluations.

That is what COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS says, but I think
that may show that that proposal was incorrect and needs to be amended.

∂11-Mar-89  1502	CL-Compiler-mailer 	Re: issue CLOS-MACRO-COMPILATION, version 1  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Mar 89  15:02:28 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 555181; Sat 11-Mar-89 17:58:31 EST
Date: Sat, 11 Mar 89 17:58 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue CLOS-MACRO-COMPILATION, version 1
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, cl-compiler@sail.stanford.edu,
    common-lisp-object-system@sail.stanford.edu
In-Reply-To: <2814566813-5018117@Kelvin>
Message-ID: <19890311225826.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 10 Mar 89  18:06:53 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    > Proposal CLOS-MACRO-COMPILATION:MINIMAL:
    ...
    >   DEFMETHOD:
    >   
    >   * The method is not callable at compile-time.  If there is a generic
    >     function with the same name at compile-time, compiling a DEFMETHOD
    >     will not add the method to that generic function.  
    > 
    >     [This also seems to imply that tests for existence of the generic 
    >     function, lambda-list congruence, etc. must not happen until 
    >     load time.]

    No, an implementation should be permitted to check for lambda-list
    congruence between methods defined in the same file; this doesn't
    require any reference to the resident generic function definition.  If
    the file doesn't include a DEFGENERIC, then the first DEFMETHOD defines
    the compile-time generic function attributes, and subsequent methods can
    be checked against that.

Agreed.  I would phrase it differently: all the DEFGENERICs and DEFMETHODS
for a given generic function name in a given compilation unit can be checked
against each other for lambda-list congruence.

    >   DEFINE-METHOD-COMBINATION:
    >   
    >   * The method combination can be used in a subsequent DEFGENERIC.  If it
    >     is referenced, the body of a long form of method combination must be 
    >     evaluable at compile-time.

    But if methods are not installed at compile time and generic functions
    are not callable at compile time, then I don't think there is any
    situation in which the method combination body could be executed at
    compile-time.

Some implementations compose and compile effective methods at compile
time, which of course requires evaluating the body of the
define-method-combination at compile time.

I haven't read Sandra's proposal yet.

∂11-Mar-89  1548	Common-Lisp-Object-System-mailer 	Re: remote environments   
Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by SAIL.Stanford.EDU with TCP; 11 Mar 89  15:47:44 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 437088; Sat 11-Mar-89 18:02:32 EST
Date: Sat, 11 Mar 89 18:01 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: remote environments
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Common-Lisp-Object-System@SAIL.Stanford.edu
In-Reply-To: <2814562184-4740019@Kelvin>
Message-ID: <19890311230120.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 10 Mar 89  16:49:44 CST
    From: David N Gray <Gray@DSG.csc.ti.com>
    >		 One way to look at this would be to
    >       say that it is implementation-dependent whether FINALIZE-INHERITANCE
    >       works or signals an error when given a class defined in the
    >       compile-time environment.
    > 
    >     [And no compile-time generic-function or method objects at all]
    > 
    > This is an interesting idea, but I think it's too restrictive.  Here's a
    > plausible and many-times proposed application for metaobjects which
    > would not be possible if we adopted this idea.  Suppose you made an
    > optimizing compiler that is allowed to assume that no class
    > redefinitions, no method redefinitions, and no newly-defined subclasses
    > will be created at run time.  The compiler is to take advantage of this
    ...

    I certainly don't want to prevent any implementation from doing that.

Note that I didn't say an implementation was doing that.  Such a compiler
might be a portable program, that's how some people have proposed writing
it.

    The real issue is what is the minimal functionality that all
    implementations must support.

Agreed.  Obviously if the minimal functionality does not make it possible
to write such a program portably, then it won't be portable, but it might
still exist in some implementations.  Still I think I came up with a plausible
example of how the existence of metaobjects at compile time could be useful
to some portable programs.

∂11-Mar-89  1658	Common-Lisp-Object-System-mailer 	Issue: LOAD-OBJECTS (Version 3)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 11 Mar 89  16:58:32 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01066g; Sat, 11 Mar 89 16:51:27 PST
Received: by challenger id AA05936g; Sat, 11 Mar 89 16:46:51 PST
Date: Sat, 11 Mar 89 16:46:51 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903120046.AA05936@challenger>
To: CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu,
        Common-Lisp-Object-System@sail.stanford.edu
Subject: Issue: LOAD-OBJECTS (Version 3)


I was a little surprised to see that this proposal talks about load
forms instead of load functions (which goes to show how much I've been
paying attention). After some thought and consultation with Moon, I
realized that part of it was that compiled functions could not be
compiled constants. If we were to allow such constants, I would propose
we consider the alternative of load functions.

The model would be that when objects are being either prepared for
dumping or are being dumped, at certain points the generic function
MAKE-LOAD-FUNCTION would be invoked on objects that needed to be
re-created later.  It would return either one or two functions. The
first is a function of 0 arguments that does the initial creation, and
the second is (if present) a function of 1 argument, which is the
initializer. If present it is applied to the created instance. This
simplifies the naming problem in the current proposal, which, while
clever, is a little unpalatable. In particular, it introduces yet
another way to think about variables.

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

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

Here are the examples in the macro proposal:

  ;; Example 1
  (defclass my-class ()
     ((a :initarg :a :reader my-a)
      (b :initarg :b :reader my-b)
      (c :accessor my-c)))
  (defmethod shared-initialize ((self my-class) ignore &rest ignore)
    (unless (slot-boundp self 'c)
      (setf (my-c self) (some-computation (my-a self) (my-b self)))))
  (defmethod make-load-function ((self my-class))
    (let ((name (class-name (class-of self)))
	  (a (my-a self))
	  (b (my-b self)))
      #'(lambda () (make-instance name :a a :b b))))

Here the computations of NAME, A, and B must be outside the function
#'(lambda ...) so that they get evaluated in the right environment to
avoid a circular (self-referential) structure. For this to work, the
faslout of #'(lambda ...) must also notice any constants or such
things that need similar treatment, which will get NAME, A, and B, if
needed. 

  ;; Example 2
  (defclass my-frob ()
     ((name :initarg :name :reader my-name)))
  (defmethod make-load-function ((self my-frob))
    (let ((name (my-name self)))
      #'(lambda () (find-my-frob name :if-does-not-exist :create))))

Maybe NAME is not something to worry about, but SELF cannot appear in
the #'(lambda ...).

  ;; Example 3 (expanded to do a hairy thing that cannot be easily done
  ;; in the macro approach).
  (defclass tree-with-parent () ((parent :accessor tree-parent)
				 (curious-facts :accessor tree-foma)
                                 (children :initarg :children)))
  (defmethod make-load-function ((x tree-with-parent))
    (let ((class (class-of x))
	  (children (slot-value x 'children))
	  (random-info-at-dump-time (compute-random-info x))
	  (more-random-info-at-creation-time ())
	  (parent (slot-value x 'parent)))
      (flet ((initialize (x)
	       (setf (tree-foma x)
		     (combine-info random-info-at-dump-time
				   random-info-at-creation-time))
	       (setf (tree-parent x) parent)))
	(values
	  ;; creation 
	  #`(lambda ()
	      (setq more-random-info-at-creation-time	      
		    (compute-more-random-info))
	      (make-instance class :children children))
	  ;; initialization
	  #'initialize))))

One can imagine the shared lexical environment of the creator and initializer
being a high-bandwidth channel for information, such as the important
information passed in the above example.

Finally, I wouldn't use the name MAKE-LOAD-FUNCTION-USING-SLOTS,
because the structure of the name ...-USING-SLOTS is like
...-USING-CLASS, which is named that way to inform the programmer that
he can discriminate on the metaclass. Maybe,
MAKE-LOAD-FUNCTION-PRESERVING-SLOTS?

				-rpg-

∂11-Mar-89  1745	Common-Lisp-Object-System-mailer 	Re: Issue: LOAD-OBJECTS (Version 3) 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 11 Mar 89  17:45:12 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA13023; Sat, 11 Mar 89 18:43:00 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA00878; Sat, 11 Mar 89 18:42:57 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903120142.AA00878@defun.utah.edu>
Date: Sat, 11 Mar 89 18:42:56 MST
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
To: Richard P. Gabriel <rpg@lucid.com>
Cc: CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu,
        Common-Lisp-Object-System@sail.stanford.edu
In-Reply-To: Richard P. Gabriel <rpg@lucid.com>, Sat, 11 Mar 89 16:46:51 PST

I haven't been paying too much attention to this issue either -- I've
been trusting Moon to do the right thing on the assumption that he
knew more about it than I did.  I think his latest proposal does look
reasonable.  However, if there is disagreement about it, I might as
well suggest yet another alternative:

Have two generic functions, not one.  The first would get called by
compile-file and it would return a list of components (or whatever)
that are required to reconstruct the object.  The compiler would dump
this list of objects in its usual way.  The loader would apply the
second generic function to this list to reconstruct the object.  It
avoids the nasty syntax you object to, doesn't require functions to be
dumpable, doesn't require any special support for circular constants,
and ought to be real easy to add to the compiler/loader.  (You could
essentially convert the constant into a LOAD-TIME-VALUE expression.)

-Sandra
-------

∂12-Mar-89  1032	Common-Lisp-Object-System-mailer 	Issue: LOAD-OBJECTS (Version 3)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 12 Mar 89  10:32:40 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01322g; Sun, 12 Mar 89 10:25:36 PST
Received: by challenger id AA06637g; Sun, 12 Mar 89 10:20:59 PST
Date: Sun, 12 Mar 89 10:20:59 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903121820.AA06637@challenger>
To: sandra%defun@cs.utah.edu
Cc: CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu,
        Common-Lisp-Object-System@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Sat, 11 Mar 89 18:42:56 MST <8903120142.AA00878@defun.utah.edu>
Subject: Issue: LOAD-OBJECTS (Version 3)



Sandra's idea of two generic functions, one producing components and the
other doing construction/further initialization has some merits aside
from the question of dumping functions. I think we should consider it.

			-rpg-

∂12-Mar-89  2014	Common-Lisp-Object-System-mailer 	Re: remote environments   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Mar 89  20:13:58 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 MAR 89 20:00:24 PST
Date: Sun, 12 Mar 89 20:00 PST
From: Gregor.pa@Xerox.COM
Subject: Re: remote environments
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Sandra J Loosemore
 <sandra%defun@cs.utah.edu>, David N Gray <Gray@DSG.csc.ti.com>, Patrick
 Dussud <dussud@lucid.com>
cc: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>, cl-compiler@sail.stanford.edu,
 common-lisp-object-system@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <19890307023706.3.MOON@EUPHRATES.SCRC.Symbolics.COM>,
              <19890309185905.3.MOON@EUPHRATES.SCRC.Symbolics.COM>,
              <8903100017.AA10108@defun.utah.edu>,
              <2814540528-3314903@Kelvin>,
              <19890310174955.3.MOON@EUPHRATES.SCRC.Symbolics.COM>,
              <8903101804.AA10718@defun.utah.edu>,
              <8903101807.AA03577@challenger>,
              <19890310194038.9.MOON@EUPHRATES.SCRC.Symbolics.COM>,
              <8903101949.AA10788@defun.utah.edu>,
              <8903102056.AA10809@defun.utah.edu>,
              <8903102240.AA03941@challenger>,
              <2814562184-4740019@Kelvin>,
              <8903111615.AA00548@defun.utah.edu>,
              <2814639239-9369595@Kelvin>,
              <19890311223604.9.MOON@EUPHRATES.SCRC.Symbolics.COM>,
              <19890311225826.2.MOON@EUPHRATES.SCRC.Symbolics.COM>,
              <19890311230120.3.MOON@EUPHRATES.SCRC.Symbolics.COM>,
              <19890311230257.4.MOON@EUPHRATES.SCRC.Symbolics.COM>,
              <19890311232009.6.MOON@EUPHRATES.SCRC.Symbolics.COM>,
              <19890311232035.7.MOON@EUPHRATES.SCRC.Symbolics.COM>,
              <8903120019.AA00810@defun.utah.edu>
Message-ID: <19890313040005.0.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no


In this message I question, once again, the existence of remote
metaobjects.  I may be behind the times here, but since no one answered
the long message I sent about why we could do without remote metaobjects
I am still stuck at that point.


    Date: Thu, 23 Feb 89  18:38:01 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

     * Can a MAKE-INSTANCE be done by a macro expander, DEFCONSTANT, or "#."? 

    Date: Mon, 6 Mar 89 21:37 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    I think it would be much nicer if we could make compile-time classes
    instantiable.  However, I agree that it would not ruin the language to
    omit that feature if we can't figure out how to do it.


    Date: Fri, 10 Mar 89 16:49:44 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    >		 One way to look at this would be to
    >       say that it is implementation-dependent whether FINALIZE-INHERITANCE
    >       works or signals an error when given a class defined in the
    >       compile-time environment.


I don't understand these comments.  It seems to me that the only real
questions are "is there a remote class object?" and "if so, how are
remote functions represented?".

If there is a remote class object then we must solve what I previously
previously called the `splicing' problem.  That remote class object must
have pointers to other class objects which represent its superclasses.
If that is the case, then to some extent that remote class will be
instantiable.  Any class that has direct supers can be finalized
provided that none of the supers are forward referenced.  Since it can
be finalized, allocate-instance can be called.  So, the only real
question is whether the initfunctions can be called.  From the user's
point of view, that translates into whether make-instance can be called.


    Date: Mon, 6 Mar 89 21:37 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    When you compile-file a DEFMETHOD, a method metaobject is created but it
    is not added to the generic-function metaobject in the local environment.
    Instead it is added to a different generic-function metaobject created
    in the remote environment.  That's my model of what has to happen.  Note
    that this should be completely consistent with the way that compile-file
    of a DEFCLASS, with a direct superclass whose name is defined in the 
    local environment and not in the remote environment, does not add the
    new class metaobject to the direct subclasses of the local superclass,
    but rather to a different object.  (I realize we haven't agreed on what
    this paragraph says, or even seen a coherent proposal, yet.  I'm just
    telling you my model.)

Yes, this is the `splicing' problem which must be solved to have remote
metaobjects.

    In the past there has been some controversy about whether the remote
    environment can inherit from the local environment.  I think this is
    crystal clear: since some user-defined classes have STANDARD-OBJECT
    as a direct superclass, and STANDARD-OBJECT is not defined in the same
    file, the remote environment is clearly inheriting from the local
    environment.  Different implementations might want to address the
    details of this differently, but I think it's clear that there has to
    be provision for it in the metaobject model.  It makes things more
    complicated, but that's unavoidable.

More splicing problems.


    Date: Fri, 10 Mar 89 16:49:44 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    > This is an interesting idea, but I think it's too restrictive.  Here's a
    > plausible and many-times proposed application for metaobjects which
    > would not be possible if we adopted this idea.  Suppose you made an
    > optimizing compiler that is allowed to assume that no class
    > redefinitions, no method redefinitions, and no newly-defined subclasses
    > will be created at run time.  The compiler is to take advantage of this

    I certainly don't want to prevent any implementation from doing that.
    The real issue is what is the minimal functionality that all
    implementations must support.

As Moon says in a later message, the issue here is not what the
implementation can do, its what portable programs can do.  It needs to
be the case that one can write a portable, metaobject `compiler'.  Many
people have wanted to do this.  People currently do this with PCL which
surely has no remote metaobjects.

But, do we need remote metaobjects to do this?  I have argued before
that we don't.  I believe it would be a reasonable restriction on
such portable programs that the program they are `compiling' be loaded
before it can be compiled.  No one has shown me why that isn't the case.

But, what I know wonder is whether it would be a reasonable restriction
on implementors.  Because, with this metaobject stuff, we can specify
minimal behavior, but we can't specify minimally.  If we specify that
there are no remote metaobjects, then implementations are going to have
to prevent themselves from ever instantiating remote versions of
portable metaobjects.  Moreover they will have to be certain that user's
can't get their hands on remote metaobjects.  This will make life more
complicated for implementations, I don't know how much more complicated.
On the other hand, solving the splicing problem will also be complicated
for implementations, and for the specification as well.
-------

∂13-Mar-89  0653	Common-Lisp-Object-System-mailer 	Re: remote environments   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89  06:53:16 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA15174; Mon, 13 Mar 89 07:44:33 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA02017; Mon, 13 Mar 89 07:44:17 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131444.AA02017@defun.utah.edu>
Date: Mon, 13 Mar 89 07:44:15 MST
Subject: Re: remote environments
To: Gregor.pa@Xerox.COM
Cc: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
        Sandra.J.Loosemore%defun@cs.utah.edu, <sandra%defun@cs.utah.edu>,
        David N Gray <Gray@DSG.csc.ti.com>, Patrick%defun@cs.utah.edu,
        Dussud <dussud@lucid.com>, Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>,
        cl-compiler@sail.stanford.edu,
        common-lisp-object-system@sail.stanford.edu
In-Reply-To: Gregor.pa@Xerox.COM, Sun, 12 Mar 89 20:00 PST

> Date: Sun, 12 Mar 89 20:00 PST
> From: Gregor.pa@Xerox.COM
> 
> If there is a remote class object then we must solve what I previously
> previously called the `splicing' problem.  That remote class object must
> have pointers to other class objects which represent its superclasses.
> If that is the case, then to some extent that remote class will be
> instantiable.  Any class that has direct supers can be finalized
> provided that none of the supers are forward referenced.  Since it can
> be finalized, allocate-instance can be called.  So, the only real
> question is whether the initfunctions can be called.  From the user's
> point of view, that translates into whether make-instance can be called.

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

Of course, if you really those methods to be callable at compile time,
you can always wrap an explicit (EVAL-WHEN (EVAL COMPILE LOAD) ...)
around both the class and method definitions.  Alternatively, you'd
probably put the definitions in another file and load it before
compiling the file that wants to instantiate that class at compile
time. 

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

> But, do we need remote metaobjects to do this?  I have argued before
> that we don't.  I believe it would be a reasonable restriction on
> such portable programs that the program they are `compiling' be loaded
> before it can be compiled.  No one has shown me why that isn't the case.

I guess this is pretty much the same thing as I was saying above.  The
one reservation I have (that others have also expressed) is that the
common practice of a file containing a class definition followed by
method definitions on that class should compile properly without
having to do any magic with pre-loading the file or wrapping
EVAL-WHENs around everything.  Would that cause problems for the
meta-object protocol?

-Sandra
-------

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

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

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

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

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

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

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

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

-------

∂13-Mar-89  1039	Common-Lisp-Object-System-mailer 	Re: remote environments   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 13 Mar 89  10:38:41 PST
Received: by ti.com id AA16905; Mon, 13 Mar 89 12:36:37 CST
Received: from Kelvin by tilde id AA26674; Mon, 13 Mar 89 12:18:59 CST
Message-Id: <2814805078-2868476@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 13 Mar 89  12:17:58 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: David N Gray <Gray@DSG.csc.ti.com>, Danny Bobrow <Bobrow.pa@Xerox.COM>,
        Common-Lisp-Object-System@SAIL.Stanford.edu
Subject: Re: remote environments
In-Reply-To: Msg of Sat, 11 Mar 89 17:36 EST from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

>     I don't see where DEFINE-METHOD-COMBINATION has any option for
>     specifying the class of the method combination; doesn't it always
>     produce an instance of the pre-defined class METHOD-COMBINATION ?
> 
> 88-002R p. 1-34 says it can make a subclass of METHOD-COMBINATION.
> 88-002R doesn't specify the implementation of DEFINE-METHOD-COMBINATION,
> but it might create a new class for each method combination type.

OK, but that's still a class created by the implementation; it isn't
instantiating a class that the user could have defined with a DEFCLASS
earlier in the file.

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

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

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

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

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

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

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

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

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

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

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

-Sandra

-------

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

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

Two objections here:



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

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

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



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

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

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

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

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

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

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

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


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

∂15-Mar-89  1207	Common-Lisp-Object-System-mailer 	Understanding Method Combination.   
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 15 Mar 89  12:03:54 PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
	id AA14537; Wed, 15 Mar 89 12:02:48 PST
Date: Wed, 15 Mar 1989 12:02:44 PST
From: James Rice <rice@sumex-aim.stanford.edu>
To: Common-Lisp-Object-System@sail.stanford.edu
Subject: Understanding Method Combination.
Message-Id: <CMM.0.88.605995364.rice@sumex-aim.stanford.edu>

As far as I know the MOP doesn't provide a way for a tool to find out
about combined methods in a way in which the user/environment tools
might be interested.  Method call sequence/behaviour is very important
to being able to understand what's happening in a program.  What I'd
like to propose is the following MOP function (I don't care what its
name is, the functionality is what counts):

Combined-Method-Pseudo-Code (GF &rest specializers)		[Function]

This function is passed a generic function and a collection of
classes that denote the classes of the arguments that are to be
passed to the generic function.  It returns the lisp code for the
combined method's body but with the actual code that invokes the
actual methods replaced by the method objects themselves.  Thus
in the following example:

(defclass container () ())

(defclass bottle (container) ())

(defclass sauce () ())

(defclass ketchup (sauce) ())

(defmethod fill ((me container) with) ...) ;;; vanilla primary method.

(defmethod fill ((me bottle) (with sauce)) ...) ;;; New primary method.

(defmethod fill :after ((me container) t) ...) ;;; Make sure we don't overflow.

(defmethod fill :before ((me container) t) ...) ;;; Make sure lid's open.

(defmethod fill :after ((me bottle) (with ketchup) ...) ;;; 57 varieties.

(defmethod fill :before ((me bottle) (with sauce)) ...)
   ;;; Make sure we're upright.


...

(Combined-Method-Pseudo-Code #'fill (find-class 'bottle) (find-class 'ketchup))


->

  (progn #<Standard-Method (method fill :before (bottle sauce))>
         #<Standard-Method (method fill :before (container t))>
         (multiple-value-prog1
           #<Standard-Method (method fill (bottle sauce))>
           #<Standard-Method (method fill :after (container t))>
           #<Standard-Method (method fill :after (bottle ketchup))>))

I've implemented this sort of functionality once already and it works
just fine, but it's horrible stuff.  This is the sort of thing that an
implementor could do easily and a user currently cannot do in any
system independent way.  It clearly doesn't matter that the code body
for the combined method could contain system dependent forms, since
all we want to be able to do is understand what's going on.

Does this sound reasonable?



Rice.

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

There are a couple of small changes that seem warranted:

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

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

On the subject of this proposed alternative:

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

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

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

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

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

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

∂19-Mar-89  1811	Common-Lisp-Object-System-mailer 	Re: Understanding Method Combination.    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Mar 89  18:11:19 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 MAR 89 18:10:23 PST
Date: Sun, 19 Mar 89 04:19 PST
From: Gregor.pa@Xerox.COM
Subject: Re: Understanding Method Combination.
To: James Rice <rice@sumex-aim.stanford.edu>
cc: CommonLoops.PA@Xerox.COM, Common-Lisp-Object-System@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <CMM.0.88.605995364.rice@sumex-aim.stanford.edu>
Message-ID: <19890319121941.4.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no

    Date: Wed, 15 Mar 89 12:02:44 PST
    From: James Rice <rice@sumex-aim.stanford.edu>

    As far as I know the MOP doesn't provide a way for a tool to find out
    about combined methods in a way in which the user/environment tools
    might be interested.

The MOP provides this behavior, and PCL implements a version of it.  In
fact, much of this is specified in chapters 1 and 2.

COMPUTE-APPLICABLE-METHODS (generic-function args)

  This accepts a generic function and a list of arguments and
  returns the ordered list of methods applicable to those arguments.

COMPUTE-EFFECTIVE-METHOD-BODY (generic-function methods)

  This takes a generic function and a list of methods and returns
  the `effective method body' of the effective method.  So, this
  does the actual method combination.  Note that the arguments to
  this will change slightly in a future release.


For example:

(defclass c1 () ())
(defclass c2 () ())
(defclass c3 (c1 c2) ())

(defmethod foo ((o c1)) ())
(defmethod foo :before ((o c2)) ())
(defmethod foo :before ((o c3)) ())
(defmethod foo :after  ((o c1)) ())

(compute-applicable-methods #'foo (list (*make-instance 'c3)))
==> (#<Standard-Method FOO :BEFORE (C3) 200020005> 
     #<Standard-Method FOO :AFTER (C1) 101000761>
     #<Standard-Method FOO (C1) 200020043>
     #<Standard-Method FOO :BEFORE (C2) 200020017>)

(compute-effective-method-body #'foo *)
==> (PROGN (CALL-METHOD #<Standard-Method FOO :BEFORE (C3) 200020005> NIL)
           (CALL-METHOD #<Standard-Method FOO :BEFORE (C2) 200020017> NIL)
           (MULTIPLE-VALUE-PROG1 (CALL-METHOD #<Standard-Method FOO (C1) 200020043> NIL)
                                 (CALL-METHOD #<Standard-Method FOO :AFTER (C1) 101000761> NIL)))

Which I believe is what you are asking for.

NOTE:
   In typing this message I discovered that there is a slight bug in 
   COMPUTE-APPLICABLE-METHODS.  You have to actually call the generic
   function once before COMPUTE-APPLICABLE-METHODS will work properly.
   This is now on my to fix list.
-------

∂20-Mar-89  1305	Common-Lisp-Object-System-mailer 	Re: Understanding Method Combination.    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 20 Mar 89  13:05:03 PST
Received: by ti.com id AA21308; Mon, 20 Mar 89 10:18:35 CST
Received: from Kelvin by tilde id AA20446; Mon, 20 Mar 89 10:05:33 CST
Message-Id: <2815401819-2255364@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 20 Mar 89  10:03:39 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Gregor.pa@Xerox.COM
Cc: James Rice <rice@sumex-aim.stanford.edu>,
        Common-Lisp-Object-System@sail.stanford.edu
Subject: Re: Understanding Method Combination.
In-Reply-To: Msg of Sun, 19 Mar 89 04:19 PST from Gregor.pa@Xerox.COM

> The MOP provides this behavior, and PCL implements a version of it.  In
> fact, much of this is specified in chapters 1 and 2.
> 
> COMPUTE-APPLICABLE-METHODS (generic-function args)
> 
>   This accepts a generic function and a list of arguments and
>   returns the ordered list of methods applicable to those arguments.
> 
> COMPUTE-EFFECTIVE-METHOD-BODY (generic-function methods)
> 
>   This takes a generic function and a list of methods and returns
>   the `effective method body' of the effective method.  So, this
>   does the actual method combination.  Note that the arguments to
>   this will change slightly in a future release.

This may work in PCL, but there isn't any COMPUTE-EFFECTIVE-METHOD-BODY
in chapter 3 of the CLOS specs.  There is only COMPUTE-EFFECTIVE-METHOD,
which returns the complete method object rather than a form.

∂20-Mar-89  1325	CL-Cleanup-mailer 	Re: Issue: LOAD-OBJECTS (Version 3) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89  13:24:54 PST
Received: from Semillon.ms by ArpaGateway.ms ; 20 MAR 89 13:17:33 PST
Date: 20 Mar 89 13:16 PST
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Sat, 18 Mar 89 01:50 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Richard P. Gabriel
 <rpg@lucid.com>, CL-Cleanup@sail.stanford.edu,
 CL-Compiler@sail.stanford.edu, Common-Lisp-Object-System@sail.stanford.edu
Message-ID: <890320-131733-6488@Xerox>

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

How about MAKE-LOAD-FORM-SAVING-SLOTS

  danny

∂20-Mar-89  1427	CL-Cleanup-mailer 	Re: Issue: LOAD-OBJECTS (Version 3) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89  14:27:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561368; Mon 20-Mar-89 17:23:27 EST
Date: Mon, 20 Mar 89 17:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
To: Danny Bobrow <Bobrow.pa@XEROX.COM>
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Richard P. Gabriel <rpg@lucid.com>,
    CL-Cleanup@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU
In-Reply-To: <890320-131733-6488@Xerox>
Message-ID: <19890320222313.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 20 Mar 89 13:16 PST
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

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

    How about MAKE-LOAD-FORM-SAVING-SLOTS

I like that name.

∂20-Mar-89  1536	Common-Lisp-Object-System-mailer 	Re: Understanding Method Combination.    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89  15:36:08 PST
Received: from Semillon.ms by ArpaGateway.ms ; 20 MAR 89 15:03:20 PST
Date: Mon, 20 Mar 89 15:03 PST
From: Gregor.pa@Xerox.COM
Subject: Re: Understanding Method Combination.
To: David N Gray <Gray@DSG.csc.ti.com>
cc: James Rice <rice@sumex-aim.stanford.edu>,
 Common-Lisp-Object-System@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <2815401819-2255364@Kelvin>
Message-ID: <19890320230314.2.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no

    Date: Mon, 20 Mar 89 10:03:39 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    This may work in PCL, but there isn't any COMPUTE-EFFECTIVE-METHOD-BODY
    in chapter 3 of the CLOS specs.  There is only COMPUTE-EFFECTIVE-METHOD,
    which returns the complete method object rather than a form.

I mistyped, the generic function is indeed called COMPUTE-EFFECTIVE-METHOD.
It is mentioned in chapter 1.  As it is documented in chapter 3, it returns
an effective method which is a lisp form that could be thought of as the
body of a lambda.  Inside the forms are invocations of the call-method
macro.  This macro arranges to pass the arguments to the method to the
actual method objects.  So, the rest of my message was basically correct
wrt the specification.
-------

∂20-Mar-89  1818	Common-Lisp-Object-System-mailer 	Re: Understanding Method Combination.    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 20 Mar 89  18:18:09 PST
Received: by ti.com id AA02140; Mon, 20 Mar 89 20:18:28 CST
Received: from Kelvin by tilde id AA04354; Mon, 20 Mar 89 20:07:16 CST
Message-Id: <2815437931-4425034@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 20 Mar 89  20:05:31 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Gregor.pa@Xerox.COM
Cc: James Rice <rice@sumex-aim.stanford.edu>,
        Common-Lisp-Object-System@sail.stanford.edu
Subject: Re: Understanding Method Combination.
In-Reply-To: Msg of Mon, 20 Mar 89 15:03 PST from Gregor.pa@Xerox.COM

> I mistyped, the generic function is indeed called COMPUTE-EFFECTIVE-METHOD.
> It is mentioned in chapter 1.  As it is documented in chapter 3, it returns
> an effective method which is a lisp form that could be thought of as the
> body of a lambda.  Inside the forms are invocations of the call-method
> macro.  This macro arranges to pass the arguments to the method to the
> actual method objects.  So, the rest of my message was basically correct
> wrt the specification.

OK, that makes sense, but the spec doesn't say that.  Page 3-43 says that
it is "called to determine the effective method", but does not ever
specify what the returned value is.  I apparently made an invalid
assumption about what was intended.  I see now that page 1-28 says that it
"returns a Lisp form that defines the effective method", but it doesn't
say anything about what it can be expected to look like.

∂21-Mar-89  0843	Common-Lisp-Object-System-mailer 	Compile Time Class Creation (was: remote environments)  
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 21 Mar 89  08:42:47 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
	id AA28027; Tue, 21 Mar 89 08:44:46 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.1)
	id AA28469; Tue, 21 Mar 89 08:40:55 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA01870; Tue, 21 Mar 89 08:42:58 PST
Message-Id: <8903211642.AA01870@suntana.sun.com>
To: cl-compiler@sail.stanford.edu, common-lisp-object-system@sail.stanford.edu
Subject: Compile Time Class Creation (was: remote environments)
Date: Tue, 21 Mar 89 08:42:55 PST
From: kempf@Sun.COM


I've just had time to plough through the X3 mail on CLOS and there was
a point lurking in the correspondence on this topic that I think was
never clearly articulated. That point has to do with the role of
class objects in type checking and inference.

If the goal is to enable compiler implementors and extenders to write
type checking and inference code in an object-oriented way, then some
kind of object representing the class must be created at compile time.
The entire class need not be defined. For example, the slot accessor
method certainly don't need to be defined. 

I think the minimum amount of information which needs to be there is the
following:

	-class precedence list-Because the class precedence list is used
	 in subtyping, it must be available to the type checker.

	-slot location (instance, class)-The compiler might be able to
	 optimize slot access based on this.

	-slot type-Again, potentially necessary for slot access.

	-metaclass-Needed for slot access, possibly to optimize instance
	 creation and initialization.

	-interface information for slot access functions-So they can
	 be optimized.

Most compilers currently use list structures for their type checkers, and
it certainly would be possible to disallow compile time creation of
classes for standard-class objects, to simplify things. But to do so
for the metaobject protocol would limit the metaobject protocol in
a way that would be crippling, since the point of the metaobject protocol
is to allow extensibility in the language processing software. 

There are a number of possible decisions. It could be left either 
unintentionally or deliberately ambiguous. It could be specified that
standard-class objects either are created, are partially created, or
are not created at compile time, while leaving open the question for
other metaclasses (since the MOP will probably not be a part of the
official ANSI Common Lisp '89 standard anyway). However, it is important
to understand the effect of these decisions on future evolution and
user extensibility.

		jak



∂23-Mar-89  0915	CL-Windows-mailer 	Issue STREAM-DEFINITION-BY-USER (V1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 23 Mar 89  09:08:32 PST
Received: by ti.com id AA12307; Wed, 22 Mar 89 21:38:08 CST
Received: from Kelvin by tilde id AA27213; Wed, 22 Mar 89 21:21:09 CST
Message-Id: <2815615116-2334006@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 22 Mar 89  21:18:36 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Cleanup@SAIL.Stanford.edu
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Windows@SAIL.Stanford.edu,
        Bartley@MIPS.csc.ti.com, Waldrum@Tilde.csc.ti.com, salem@Think.COM
Subject: Issue STREAM-DEFINITION-BY-USER (V1)

Following is a more detailed write-up of the idea of a generic function
I/O interface that allows users to create their own streams.  I have put
this in the format of a cleanup proposal because that seems like a good
way of presenting the information, but I realize that the timing isn't
right for including this in the standard now.  Hopefully, though, this
can be used as a guideline for implementors to avoid unnecessarily
coming up with different names for the same thing, and after some
experience has been gained, this feature could be considered for
inclusion in a revision of the standard.  I wanted to get this in your
hands before the X3J13 meeting in case anyone was interested in
discussing it, but I don't expect any official action to be taken.



Issue:		STREAM-DEFINITION-BY-USER

References:	CLtL pages 329-332, 378-381, and 384-385.

Related issues:	STREAM-INFO, CLOSED-STREAM-FUNCTIONS, STREAM-ACCESS,
		STREAM-CAPABILITIES

Category:	ADDITION

Edit history:	Version 1, 22-Mar-89 by David N. Gray
  
Status:		For discussion and evaluation; not proposed for
		inclusion in the standard at this time.

Problem description:

  Common Lisp does not provide a standard way for users to define their
  own streams for use by the standard I/O functions.  This impedes the
  development of window systems for Common Lisp because, while there are
  standard Common Lisp I/O functions and there are beginning to be
  standard window systems, there is no portable way to connect them
  together to make a portable Common Lisp window system.

  There are also many applications where users might want to define
  their own filter streams for doing things like printer device control,
  report formatting, character code translation, or
  encryption/decryption.

Proposal STREAM-DEFINITION-BY-USER:GENERIC-FUNCTIONS

 Overview:

  Define a set of generic functions for performing I/O.  These functions
  will have methods that specialize on the stream argument; they would
  be used by the existing I/O functions.  Users could write additional
  methods for them in order to support their own stream classes.

  Define a set of classes to be used as the superclass of a stream class
  in order to provide some default methods.

 Classes:

  The following classes are to be used as super classes of user-defined
  stream classes.  They are not intended to be directly instantiated; they
  just provide places to hang default methods.

  FUNDAMENTAL-STREAM				[Class]

    This class is a subclass of STREAM and of STANDARD-OBJECT.  STREAMP
    will return true for an instance of any class that includes this.  (It
    may return true for some other things also.)

  FUNDAMENTAL-INPUT-STREAM			[Class]

    A subclass of FUNDAMENTAL-STREAM.  Its inclusion causes INPUT-STREAM-P
    to return true.

  FUNDAMENTAL-OUTPUT-STREAM			[Class]

    A subclass of FUNDAMENTAL-STREAM.  Its inclusion causes OUTPUT-STREAM-P
    to return true.  Bi-direction streams may be formed by including both
    FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-INPUT-STREAM.

  FUNDAMENTAL-CHARACTER-STREAM			[Class]

    A subclass of FUNDAMENTAL-STREAM.  It provides a method for
    STREAM-ELEMENT-TYPE which returns CHARACTER.

  FUNDAMENTAL-BINARY-STREAM			[Class]
    
    A subclass of FUNDAMENTAL-STREAM.  Any instantiable class that
    includes this needs to define a method for STREAM-ELEMENT-TYPE.

  FUNDAMENTAL-CHARACTER-INPUT-STREAM		[Class]

    Includes FUNDAMENTAL-INPUT-STREAM and FUNDAMENTAL-CHARACTER-STREAM.
    It provides default methods for several generic functions used for
    character input.

  FUNDAMENTAL-CHARACTER-OUTPUT-STREAM		[Class]

    Includes FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-CHARACTER-STREAM.
    It provides default methods for several generic functions used for
    character output.

  FUNDAMENTAL-BINARY-INPUT-STREAM		[Class]

    Includes FUNDAMENTAL-INPUT-STREAM and FUNDAMENTAL-BINARY-STREAM.

  FUNDAMENTAL-BINARY-OUTPUT-STREAM		[Class]

    Includes FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-BINARY-STREAM.


 Character input:

  A character input stream can be created by defining a class that
  includes FUNDAMENTAL-CHARACTER-INPUT-STREAM and defining methods for the
  generic functions below.

  STREAM-READ-CHAR  stream			[Generic Function]

    This reads one character from the stream.  It returns either a
    character object, or the symbol :EOF if the stream is at end-of-file.
    Every subclass of FUNDAMENTAL-CHARACTER-INPUT-STREAM must define a
    method for this function.

    Note that for all of these generic functions, the stream argument
    must be a stream object, not T or NIL.

  STREAM-UNREAD-CHAR  stream  character		[Generic Function]

    Un-does the last call to STREAM-READ-CHAR, as in UNREAD-CHAR.  Returns
    NIL.  Every subclass of FUNDAMENTAL-CHARACTER-INPUT-STREAM must define
    a method for this function.

  STREAM-READ-CHAR-NO-HANG  stream		[Generic Function]

    This is used to implement READ-CHAR-NO-HANG.  It returns either a
    character, or NIL if no input is currently available, or :EOF if
    end-of-file is reached.  The default method provided by
    FUNDAMENTAL-CHARACTER-INPUT-STREAM simply calls STREAM-READ-CHAR; this
    is sufficient for file streams, but interactive streams should define
    their own method.
  
  STREAM-PEEK-CHAR  stream			[Generic Function]

    Used to implement PEEK-CHAR; this corresponds to peek-type of NIL.
    It returns either a character or :EOF.  The default method
    calls STREAM-READ-CHAR and STREAM-UNREAD-CHAR.

  STREAM-LISTEN  stream				[Generic Function]

    Used by LISTEN.  Returns true or false.  The default method uses
    STREAM-READ-CHAR-NO-HANG and STREAM-UNREAD-CHAR.  Most streams should 
    define their own method since it will usually be trivial and will
    always be more efficient than the default method.

  STREAM-READ-LINE  stream			[Generic Function]

    Used by READ-LINE.  A string is returned as the first value.  The
    second value is true if the string was terminated by end-of-file
    instead of the end of a line.  The default method uses repeated
    calls to STREAM-READ-CHAR.

  STREAM-CLEAR-INPUT  stream			[Generic Function]

    Implements CLEAR-INPUT for the stream, returning NIL.  The default
    method does nothing.


 Character output:

  A character output stream can be created by defining a class that
  includes FUNDAMENTAL-CHARACTER-OUTPUT-STREAM and defining methods for the
  generic functions below.

  STREAM-WRITE-CHAR  stream character		[Generic Function]

    Writes character to the stream and returns the character.  Every
    subclass of FUNDAMENTAL-CHARACTER-OUTPUT-STREAM must have a method
    defined for this function.

  STREAM-LINE-COLUMN  stream			[Generic Function]

    This function returns the column number where the next character
    will be written, or NIL if that is not meaningful for this stream.
    The first column on a line is numbered 0.  This function is used in
    the implementation of PPRINT and the FORMAT ~T directive.  For every
    character output stream class that is defined, a method must be
    defined for this function, although it is permissible for it to
    always return NIL.

  STREAM-START-LINE-P  stream			[Generic Function]

    This is a predicate which returns T if the stream is positioned at the
    beginning of a line, else NIL.  It is permissible to always return
    NIL.  This is used in the implementation of FRESH-LINE.  Note that
    while a value of 0 from STREAM-LINE-COLUMN also indicates the
    beginning of a line, there are cases where STREAM-START-LINE-P can be
    meaningfully implemented although STREAM-LINE-COLUMN can't be.  For
    example, for a window using variable-width characters, the column
    number isn't very meaningful, but the beginning of the line does have
    a clear meaning.  The default method for STREAM-START-LINE-P on class
    FUNDAMENTAL-CHARACTER-OUTPUT-STREAM uses STREAM-LINE-COLUMN, so if
    that is defined to return NIL, then a method should be provided for
    either STREAM-START-LINE-P or STREAM-FRESH-LINE.

  STREAM-WRITE-STRING stream string &optional start end [Generic Function]

    This is used by WRITE-STRING.  It writes the string to the stream,
    optionally delimited by start and end, which default to 0 and NIL.
    The string argument is returned.  The default method provided by
    FUNDAMENTAL-CHARACTER-OUTPUT-STREAM uses repeated calls to
    STREAM-WRITE-CHAR.

  STREAM-TERPRI  stream				[Generic Function]

    Writes an end of line, as for TERPRI.  Returns NIL.  The default
    method does (STREAM-WRITE-CHAR stream #\NEWLINE).

  STREAM-FRESH-LINE  stream			[Generic Function]

    Used by FRESH-LINE.  The default method uses STREAM-START-LINE-P and
    STREAM-TERPRI.

  STREAM-FINISH-OUTPUT  stream			[Generic Function]

    Implements FINISH-OUTPUT.  The default method does nothing.

  STREAM-FORCE-OUTPUT  stream			[Generic Function]

    Implements FORCE-OUTPUT.  The default method does nothing.

  STREAM-CLEAR-OUTPUT  stream			[Generic Function]

    Implements CLEAR-OUTPUT.  The default method does nothing.

  STREAM-ADVANCE-TO-COLUMN  stream column	[Generic Function]

    Writes enough blank space so that the next character will be written
    at the specified column.  Returns true if the operation is
    successful, or NIL if it is not supported for this stream.    
    This is intended for use by by PPRINT and FORMAT ~T.  The default
    method uses STREAM-LINE-COLUMN and repeated calls to
    STREAM-WRITE-CHAR with a #\SPACE character; it returns NIL if
    STREAM-LINE-COLUMN returns NIL.


 Other functions:
 
  CLOSE  stream &key abort			[Generic Function]

    The existing function CLOSE is redefined to be a generic function, but
    otherwise behaves the same.  The default method provided by class
    FUNDAMENTAL-STREAM sets a flag for OPEN-STREAM-P.  The value returned
    by CLOSE will be as specified by the issue CLOSED-STREAM-OPERATIONS.

  OPEN-STREAM-P stream				[Generic Function]

    This function [from proposal STREAM-ACCESS] is made generic.  A
    default method is provided by class FUNDAMENTAL-STREAM which returns
    true if CLOSE has not been called on the stream.

  STREAMP  object				[Generic Function]
  INPUT-STREAM-P  stream			[Generic Function]
  OUTPUT-STREAM-P  stream			[Generic Function]

    These three existing predicates may optionally be implemented as
    generic functions for implementations that want to permit users to
    define streams that are not STANDARD-OBJECTs.  Normally, the default
    methods provided by classes FUNDAMENTAL-INPUT-STREAM and
    FUNDAMENTAL-OUTPUT-STREAM are sufficient.  Note that, for example,
    (INPUT-STREAM-P x) is not equivalent to (TYPEP x
    'FUNDAMENTAL-INPUT-STREAM) because implementations may have
    additional ways of defining their own streams even if they don't
    make that visible by making these predicates generic.

  STREAM-ELEMENT-TYPE  stream			[Generic Function]

    This existing function is made generic, but otherwise behaves the
    same.  Class FUNDAMENTAL-CHARACTER-STREAM provides a default method
    which returns CHARACTER.

  PATHNAME and TRUENAME are also permitted to be implemented as generic
  functions.  There is no default method since these are not valid for
  all streams.


 Binary streams:

    Binary streams can be created by defining a class that includes either
    FUNDAMENTAL-BINARY-INPUT-STREAM or FUNDAMENTAL-BINARY-OUTPUT-STREAM
    (or both) and defining a method for STREAM-ELEMENT-TYPE and for one or
    both of the following generic functions.

  STREAM-READ-BYTE  stream			[Generic Function]

    Used by READ-BYTE; returns either an integer, or the symbol :EOF if the
    stream is at end-of-file.

  STREAM-WRITE-BYTE stream integer		[Generic Function]

    Implements WRITE-BYTE; writes the integer to the stream and returns
    the integer as the result.


Rationale:

  The existing I/O functions cannot be made generic because, in nearly
  every case, the stream argument is optional, and therefore cannot be
  specialized.  Therefore, it is necessary to define a lower-level
  generic function to be used by the existing function.  It also isn't
  appropriate to specialize on the second argument of PRINT-OBJECT because
  it is a higher-level function -- even when the first argument is a
  character or a string, it needs to format it in accordance with
  *PRINT-ESCAPE*.

  In order to make the meaning as obvious as possible, the names of the
  generic functions have been formed by prefixing "STREAM-" to the
  corresponding non-generic function.

  Having the generic input functions just return :EOF at end-of-file, with
  the higher-level functions handling the eof-error-p and eof-value
  arguments, simplifies the generic function interface and makes it more
  efficient by not needing to pass through those arguments.  Note that the
  functions that use this convention can only return a character or
  integer as a stream element, so there is no possibility of ambiguity.

  Functions STREAM-LINE-COLUMN, STREAM-START-LINE-P, and
  STREAM-ADVANCE-TO-COLUMN may appear to be a reincarnation of the
  defeated proposal STREAM-INFO, but the motivation here is different.
  This interface needs to be defined if user-defined streams are to be
  able to be used by PPRINT and FORMAT ~T, which could be viewed as a
  separate question from whether the user can call then on
  system-defined streams.

Current practice:

  No one currently supports exactly this proposal, but this is very
  similar to the stream interface used in CLUE.

  On descendants of the MIT Lisp Machine, streams can be implemented
  by users as either flavors, with methods to accept the various
  messages corresponding to the I/O operations, or as functions, which
  take a message keyword as their first argument.

Examples:

  ;;;; Here is an example of how the default methods could be
  ;;;; implemented (omitting the most trivial ones):

  (defmethod STREAM-PEEK-CHAR ((stream fundamental-character-input-stream))
    (let ((character (stream-read-char stream)))
      (unless (eq character :eof)
	(stream-unread-char stream character))
      character))

  (defmethod STREAM-LISTEN ((stream fundamental-character-input-stream))
    (let ((char (stream-read-char-no-hang stream)))
      (and (not (null char))
	   (not (eq char :eof))
	   (progn (stream-unread-char stream char) t))))

  (defmethod STREAM-READ-LINE ((stream fundamental-character-input-stream))
    (let ((line (make-array 64 :element-type 'string-char 
			    :fill-pointer 0 :adjustable t)))
      (loop (let ((character (stream-read-char stream)))
	      (if (eq character :eof)
		  (return (values line t))
		(if (eql character #\newline)
		    (return (values line nil))
		  (vector-push-extend character line)))))))

  (defmethod STREAM-START-LINE-P ((stream fundamental-character-output-stream))
    (equal (stream-line-column stream) 0))

  (defmethod STREAM-WRITE-STRING ((stream fundamental-character-output-stream)
				  string &optional (start 0) 
				  (end (length string)))
    (do ((i start (1+ i)))
	((>= i end) string)
      (stream-write-char stream (char string i))))

  (defmethod STREAM-TERPRI ((stream fundamental-character-output-stream))
    (stream-write-char stream #\newline)
    nil)

  (defmethod STREAM-FRESH-LINE ((stream fundamental-character-output-stream))
    (if (stream-start-line-p stream)
	nil
      (progn (stream-terpri stream) t)))

  (defmethod STREAM-ADVANCE-TO-COLUMN ((stream fundamental-character-output-stream) 
				       column)
    (let ((current (stream-line-column stream)))
      (unless (null current)
	(dotimes (i (- current column) t)
	  (stream-write-char stream #\space)))))

  (defmethod INPUT-STREAM-P ((stream fundamental-input-stream)) t)
  (defmethod INPUT-STREAM-P ((stream fundamental-output-stream))
    ;; allow the two classes to be mixed in either order
    (typep stream 'fundamental-input-stream))
  (defmethod OUTPUT-STREAM-P ((stream fundamental-output-stream)) t)
  (defmethod OUTPUT-STREAM-P ((stream fundamental-input-stream))
    (typep stream 'fundamental-output-stream))

  ;;;; Following is an example of how the existing I/O functions could
  ;;;; be implemented using standard Common Lisp and the generic
  ;;;; functions specified above.  The standard functions being defined
  ;;;; are in upper case.

  ;;  Internal helper functions

  (proclaim '(inline decode-read-arg decode-print-arg check-for-eof))
  (defun decode-read-arg (arg)
    (cond ((null arg) *standard-input*)
	  ((eq arg t) *terminal-io*)
	  (t arg)))
  
  (defun decode-print-arg (arg)
    (cond ((null arg) *standard-output*)
	  ((eq arg t) *terminal-io*)
	  (t arg)))
  
  (defun check-for-eof (value stream eof-errorp eof-value)
    (if (eq value :eof)
	(report-eof stream eof-errorp eof-value)
      value))
  
  (defun report-eof (stream eof-errorp eof-value)
    (if eof-errorp
	(error 'end-of-file :stream stream)
      eof-value))
  
  ;;;  Common Lisp input functions
  
  (defun READ-CHAR (&optional input-stream (eof-errorp t) eof-value recursive-p)
    (declare (ignore recursive-p)) ; a mistake in CLtL?
    (let ((stream (decode-read-arg input-stream)))
      (check-for-eof (stream-read-char stream) stream eof-errorp eof-value)))
  
  (defun PEEK-CHAR (&optional peek-type input-stream (eof-errorp t) 
			eof-value recursive-p)
    (declare (ignore recursive-p))
    (let ((stream (decode-read-arg input-stream)))
      (if (null peek-type)
	  (check-for-eof (stream-peek-char stream) stream eof-errorp eof-value)
        (loop
	  (let ((value (stream-peek-char stream)))
	    (if (eq value :eof)
		(return (report-eof stream eof-errorp eof-value))
	      (if (if (eq peek-type t)
		      (not (member value '(#\space #\tab #\newline
					   #\page #\return #\linefeed)))
		    (char= peek-type value))
		  (return value)
		(stream-read-char stream))))))))
  
  (defun UNREAD-CHAR (character &optional input-stream)
    (stream-unread-char (decode-read-arg input-stream) character))
  
  (defun LISTEN (&optional input-stream)
    (stream-listen (decode-read-arg input-stream)))
  
  (defun READ-LINE (&optional input-stream (eof-error-p t) 
			eof-value recursive-p)
    (declare (ignore recursive-p))
    (let ((stream (decode-read-arg input-stream)))
      (multiple-value-bind (string eofp)
	  (stream-read-line stream)
	(if eofp
	    (if (= (length string) 0)
		(report-eof stream eof-error-p eof-value)
	      (values string t))
	  (values string nil)))))
  
  (defun CLEAR-INPUT (&optional input-stream)
    (stream-clear-input (decode-read-arg input-stream)))
  
  (defun READ-CHAR-NO-HANG (&optional input-stream (eof-errorp t) 
				eof-value recursive-p)
    (declare (ignore recursive-p))
    (let ((stream (decode-read-arg input-stream)))
      (check-for-eof (stream-read-char-no-hang stream)
		     stream eof-errorp eof-value)))
  
  ;;;  Common Lisp output functions
  
  (defun WRITE-CHAR (character &optional output-stream)
     (stream-write-char (decode-print-arg output-stream) character))
  
  (defun FRESH-LINE (&optional output-stream)
    (stream-fresh-line (decode-print-arg output-stream)))
  
  (defun TERPRI (&optional output-stream)
    (stream-terpri (decode-print-arg output-stream)))
  
  (defun WRITE-STRING (string &optional output-stream &key (start 0) end)
    (stream-write-string (decode-print-arg output-stream) string start end))
  
  (defun WRITE-LINE (string &optional output-stream &key (start 0) end)
    (let ((stream (decode-print-arg output-stream)))
      (stream-write-string stream string start end)
      (stream-terpri stream)
      string))
  
  (defun FORCE-OUTPUT (&optional stream)
    (stream-force-output (decode-print-arg stream)))
  
  (defun FINISH-OUTPUT (&optional stream)
    (stream-finish-output (decode-print-arg stream)))
  
  (defun CLEAR-OUTPUT (&optional stream)
    (stream-clear-output (decode-print-arg stream)))
  
  ;;;  Binary streams

  (defun READ-BYTE (binary-input-stream &optional (eof-errorp t) eof-value)
    (check-for-eof (stream-read-byte binary-input-stream) 
		   binary-input-stream eof-errorp eof-value))
  
  (defun WRITE-BYTE (integer binary-output-stream)
    (stream-write-byte binary-output-stream integer))

  ;;;  String streams
  
  (defclass string-input-stream (fundamental-character-input-stream)
    ((string :initarg :string :type string)
     (index :initarg :start :type fixnum)
     (end :initarg :end :type fixnum)
     ))
  
  (defun MAKE-STRING-INPUT-STREAM (string &optional (start 0) end)
    (make-instance 'string-input-stream :string string 
		   :start start :end (or end (length string))))
  
  (defmethod stream-read-char ((stream string-input-stream))
    (with-slots (index end string) stream
      (if (>= index end)
	  :eof
	(prog1 (char string index)
	       (incf index)))))
  
  (defmethod stream-unread-char ((stream string-input-stream) character)
    (with-slots (index end string) stream
      (decf index)
      (assert (eql (char string index) character))
      nil))
  
  (defmethod stream-read-line ((stream string-input-stream))
    (with-slots (index end string) stream
      (let* ((endline (position #\newline string :start index :end end))
	     (line (subseq string index endline)))
	(if endline
	    (progn (setq index (1+ endline))
		   (values line nil))
	  (progn (setq index end)
		 (values line t))))))
  
  (defclass string-output-stream (fundamental-character-output-stream)
    ((string :initform nil :initarg :string)))

  (defun MAKE-STRING-OUTPUT-STREAM ()
    (make-instance 'string-output-stream))

  (defun GET-OUTPUT-STREAM-STRING (stream)
    (with-slots (string) stream
      (if (null string)
	  ""
	(prog1 string (setq string nil)))))
  
  (defmethod stream-write-char ((stream string-output-stream) character)
    (with-slots (string) stream
      (when (null string)
	(setq string (make-array 64. :element-type 'string-char 
				 :fill-pointer 0 :adjustable t)))
      (vector-push-extend character string)
      character))
  
  (defmethod stream-line-column ((stream string-output-stream))
    (with-slots (string) stream
      (if (null string)
	  0
	(let ((nx (position #\newline string :from-end t)))
	  (if (null nx)
	      (length string)
	    (- (length string) nx 1))
	  ))))

Cost to Implementors:

  Given that CLOS is supported, adding the above generic functions and
  methods is easy, since most of the code is included in the examples
  above.  The hard part would be re-writing existing I/O functionality in
  terms of methods on these new generic functions.  That could be
  simplified if methods can be defined to forward the operations to the
  old representation of streams.  For a new implementation, the cost could
  be zero since an approach similar to this would likely be used anyway.

Cost to Users:

  None; this is an upward-compatible addition.   Users won't even
  need to know anything about this unless they actually need this feature.

Cost of non-adoption:

  Development of portable I/O extensions will be discouraged.

Performance impact:

  This shouldn't affect performance of new implementations (assuming an
  efficient CLOS implementation), but it could slow down I/O if it were
  clumsily grafted on top of an existing implementation.

Benefits:

  A broader domain of programs that can be written portably.

Esthetics:

  This seems to be a simple, straight-forward approach.

Discussion:

  This proposal incorporates suggestions made by several people in
  response to an earlier outline.  So far, no one has expressed opposition
  to the concept.  There are some differences of opinion about whether
  certain operations should have default methods or required methods:
  STREAM-LISTEN, STREAM-READ-CHAR-NO-HANG, STREAM-LINE-COLUMN,
  and STREAM-START-LINE-P.

  An experimental prototype of this has been successfully implemented on
  the Explorer.

  This proposal does not provide sufficient capability to implement
  forwarding streams such as for MAKE-SYNONYM-STREAM,
  MAKE-BROADCAST-STREAM, MAKE-CONCATENATED-STREAM, MAKE-TWO-WAY-STREAM, or
  MAKE-ECHO-STREAM.  The generic function approach does not lend itself as
  well to that as a message passing model where the intermediary does not
  need to know what all the possible messages are.  A possible way of
  extending it for that would be to define a class 

    (defclass stream-generic-function (standard-generic-function) ())

  to be used as the :generic-function-class option for all of the I/O
  generic functions.  This would then permit doing something like

  (defmethod no-applicable-method ((gfun stream-generic-function) &rest args) 
    (if (streamp (first args))
	(apply #'stream-operation-not-handled (first args) gfun (rest args))
      (call-next-method)))

  where stream-operation-not-handled is a generic function whose default
  method signals an error, but forwarding streams can define methods that
  will create a method to handle the unexpected operation.  (Perhaps
  NO-APPLICABLE-METHOD should be changed to take two required arguments
  since all generic functions need at least one required argument, and
  that would make it unnecessary to define a new generic function class
  just to be able to write this one method.)

  Another thing that is not addressed here is a way to cause an instance
  of a user-defined stream class to be created from a call to the OPEN
  function.  That should be part of a separate issue for generic functions
  on pathnames.  If that capability were available, then PATHNAME and
  TRUENAME should be required to be generic functions.

  An earlier draft defined just two classes, FUNDAMENTAL-INPUT-STREAM and
  FUNDAMENTAL-OUTPUT-STREAM, that were used for both character and binary
  streams.  It isn't clear whether that simple approach is sufficient or
  whether the larger set of classes is really needed.

∂23-Mar-89  1503	CL-Windows-mailer 	Issue STREAM-DEFINITION-BY-USER (V1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 23 Mar 89  09:08:32 PST
Received: by ti.com id AA12307; Wed, 22 Mar 89 21:38:08 CST
Received: from Kelvin by tilde id AA27213; Wed, 22 Mar 89 21:21:09 CST
Message-Id: <2815615116-2334006@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 22 Mar 89  21:18:36 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Cleanup@SAIL.Stanford.edu
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Windows@SAIL.Stanford.edu,
        Bartley@MIPS.csc.ti.com, Waldrum@Tilde.csc.ti.com, salem@Think.COM
Subject: Issue STREAM-DEFINITION-BY-USER (V1)

Following is a more detailed write-up of the idea of a generic function
I/O interface that allows users to create their own streams.  I have put
this in the format of a cleanup proposal because that seems like a good
way of presenting the information, but I realize that the timing isn't
right for including this in the standard now.  Hopefully, though, this
can be used as a guideline for implementors to avoid unnecessarily
coming up with different names for the same thing, and after some
experience has been gained, this feature could be considered for
inclusion in a revision of the standard.  I wanted to get this in your
hands before the X3J13 meeting in case anyone was interested in
discussing it, but I don't expect any official action to be taken.



Issue:		STREAM-DEFINITION-BY-USER

References:	CLtL pages 329-332, 378-381, and 384-385.

Related issues:	STREAM-INFO, CLOSED-STREAM-FUNCTIONS, STREAM-ACCESS,
		STREAM-CAPABILITIES

Category:	ADDITION

Edit history:	Version 1, 22-Mar-89 by David N. Gray
  
Status:		For discussion and evaluation; not proposed for
		inclusion in the standard at this time.

Problem description:

  Common Lisp does not provide a standard way for users to define their
  own streams for use by the standard I/O functions.  This impedes the
  development of window systems for Common Lisp because, while there are
  standard Common Lisp I/O functions and there are beginning to be
  standard window systems, there is no portable way to connect them
  together to make a portable Common Lisp window system.

  There are also many applications where users might want to define
  their own filter streams for doing things like printer device control,
  report formatting, character code translation, or
  encryption/decryption.

Proposal STREAM-DEFINITION-BY-USER:GENERIC-FUNCTIONS

 Overview:

  Define a set of generic functions for performing I/O.  These functions
  will have methods that specialize on the stream argument; they would
  be used by the existing I/O functions.  Users could write additional
  methods for them in order to support their own stream classes.

  Define a set of classes to be used as the superclass of a stream class
  in order to provide some default methods.

 Classes:

  The following classes are to be used as super classes of user-defined
  stream classes.  They are not intended to be directly instantiated; they
  just provide places to hang default methods.

  FUNDAMENTAL-STREAM				[Class]

    This class is a subclass of STREAM and of STANDARD-OBJECT.  STREAMP
    will return true for an instance of any class that includes this.  (It
    may return true for some other things also.)

  FUNDAMENTAL-INPUT-STREAM			[Class]

    A subclass of FUNDAMENTAL-STREAM.  Its inclusion causes INPUT-STREAM-P
    to return true.

  FUNDAMENTAL-OUTPUT-STREAM			[Class]

    A subclass of FUNDAMENTAL-STREAM.  Its inclusion causes OUTPUT-STREAM-P
    to return true.  Bi-direction streams may be formed by including both
    FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-INPUT-STREAM.

  FUNDAMENTAL-CHARACTER-STREAM			[Class]

    A subclass of FUNDAMENTAL-STREAM.  It provides a method for
    STREAM-ELEMENT-TYPE which returns CHARACTER.

  FUNDAMENTAL-BINARY-STREAM			[Class]
    
    A subclass of FUNDAMENTAL-STREAM.  Any instantiable class that
    includes this needs to define a method for STREAM-ELEMENT-TYPE.

  FUNDAMENTAL-CHARACTER-INPUT-STREAM		[Class]

    Includes FUNDAMENTAL-INPUT-STREAM and FUNDAMENTAL-CHARACTER-STREAM.
    It provides default methods for several generic functions used for
    character input.

  FUNDAMENTAL-CHARACTER-OUTPUT-STREAM		[Class]

    Includes FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-CHARACTER-STREAM.
    It provides default methods for several generic functions used for
    character output.

  FUNDAMENTAL-BINARY-INPUT-STREAM		[Class]

    Includes FUNDAMENTAL-INPUT-STREAM and FUNDAMENTAL-BINARY-STREAM.

  FUNDAMENTAL-BINARY-OUTPUT-STREAM		[Class]

    Includes FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-BINARY-STREAM.


 Character input:

  A character input stream can be created by defining a class that
  includes FUNDAMENTAL-CHARACTER-INPUT-STREAM and defining methods for the
  generic functions below.

  STREAM-READ-CHAR  stream			[Generic Function]

    This reads one character from the stream.  It returns either a
    character object, or the symbol :EOF if the stream is at end-of-file.
    Every subclass of FUNDAMENTAL-CHARACTER-INPUT-STREAM must define a
    method for this function.

    Note that for all of these generic functions, the stream argument
    must be a stream object, not T or NIL.

  STREAM-UNREAD-CHAR  stream  character		[Generic Function]

    Un-does the last call to STREAM-READ-CHAR, as in UNREAD-CHAR.  Returns
    NIL.  Every subclass of FUNDAMENTAL-CHARACTER-INPUT-STREAM must define
    a method for this function.

  STREAM-READ-CHAR-NO-HANG  stream		[Generic Function]

    This is used to implement READ-CHAR-NO-HANG.  It returns either a
    character, or NIL if no input is currently available, or :EOF if
    end-of-file is reached.  The default method provided by
    FUNDAMENTAL-CHARACTER-INPUT-STREAM simply calls STREAM-READ-CHAR; this
    is sufficient for file streams, but interactive streams should define
    their own method.
  
  STREAM-PEEK-CHAR  stream			[Generic Function]

    Used to implement PEEK-CHAR; this corresponds to peek-type of NIL.
    It returns either a character or :EOF.  The default method
    calls STREAM-READ-CHAR and STREAM-UNREAD-CHAR.

  STREAM-LISTEN  stream				[Generic Function]

    Used by LISTEN.  Returns true or false.  The default method uses
    STREAM-READ-CHAR-NO-HANG and STREAM-UNREAD-CHAR.  Most streams should 
    define their own method since it will usually be trivial and will
    always be more efficient than the default method.

  STREAM-READ-LINE  stream			[Generic Function]

    Used by READ-LINE.  A string is returned as the first value.  The
    second value is true if the string was terminated by end-of-file
    instead of the end of a line.  The default method uses repeated
    calls to STREAM-READ-CHAR.

  STREAM-CLEAR-INPUT  stream			[Generic Function]

    Implements CLEAR-INPUT for the stream, returning NIL.  The default
    method does nothing.


 Character output:

  A character output stream can be created by defining a class that
  includes FUNDAMENTAL-CHARACTER-OUTPUT-STREAM and defining methods for the
  generic functions below.

  STREAM-WRITE-CHAR  stream character		[Generic Function]

    Writes character to the stream and returns the character.  Every
    subclass of FUNDAMENTAL-CHARACTER-OUTPUT-STREAM must have a method
    defined for this function.

  STREAM-LINE-COLUMN  stream			[Generic Function]

    This function returns the column number where the next character
    will be written, or NIL if that is not meaningful for this stream.
    The first column on a line is numbered 0.  This function is used in
    the implementation of PPRINT and the FORMAT ~T directive.  For every
    character output stream class that is defined, a method must be
    defined for this function, although it is permissible for it to
    always return NIL.

  STREAM-START-LINE-P  stream			[Generic Function]

    This is a predicate which returns T if the stream is positioned at the
    beginning of a line, else NIL.  It is permissible to always return
    NIL.  This is used in the implementation of FRESH-LINE.  Note that
    while a value of 0 from STREAM-LINE-COLUMN also indicates the
    beginning of a line, there are cases where STREAM-START-LINE-P can be
    meaningfully implemented although STREAM-LINE-COLUMN can't be.  For
    example, for a window using variable-width characters, the column
    number isn't very meaningful, but the beginning of the line does have
    a clear meaning.  The default method for STREAM-START-LINE-P on class
    FUNDAMENTAL-CHARACTER-OUTPUT-STREAM uses STREAM-LINE-COLUMN, so if
    that is defined to return NIL, then a method should be provided for
    either STREAM-START-LINE-P or STREAM-FRESH-LINE.

  STREAM-WRITE-STRING stream string &optional start end [Generic Function]

    This is used by WRITE-STRING.  It writes the string to the stream,
    optionally delimited by start and end, which default to 0 and NIL.
    The string argument is returned.  The default method provided by
    FUNDAMENTAL-CHARACTER-OUTPUT-STREAM uses repeated calls to
    STREAM-WRITE-CHAR.

  STREAM-TERPRI  stream				[Generic Function]

    Writes an end of line, as for TERPRI.  Returns NIL.  The default
    method does (STREAM-WRITE-CHAR stream #\NEWLINE).

  STREAM-FRESH-LINE  stream			[Generic Function]

    Used by FRESH-LINE.  The default method uses STREAM-START-LINE-P and
    STREAM-TERPRI.

  STREAM-FINISH-OUTPUT  stream			[Generic Function]

    Implements FINISH-OUTPUT.  The default method does nothing.

  STREAM-FORCE-OUTPUT  stream			[Generic Function]

    Implements FORCE-OUTPUT.  The default method does nothing.

  STREAM-CLEAR-OUTPUT  stream			[Generic Function]

    Implements CLEAR-OUTPUT.  The default method does nothing.

  STREAM-ADVANCE-TO-COLUMN  stream column	[Generic Function]

    Writes enough blank space so that the next character will be written
    at the specified column.  Returns true if the operation is
    successful, or NIL if it is not supported for this stream.    
    This is intended for use by by PPRINT and FORMAT ~T.  The default
    method uses STREAM-LINE-COLUMN and repeated calls to
    STREAM-WRITE-CHAR with a #\SPACE character; it returns NIL if
    STREAM-LINE-COLUMN returns NIL.


 Other functions:
 
  CLOSE  stream &key abort			[Generic Function]

    The existing function CLOSE is redefined to be a generic function, but
    otherwise behaves the same.  The default method provided by class
    FUNDAMENTAL-STREAM sets a flag for OPEN-STREAM-P.  The value returned
    by CLOSE will be as specified by the issue CLOSED-STREAM-OPERATIONS.

  OPEN-STREAM-P stream				[Generic Function]

    This function [from proposal STREAM-ACCESS] is made generic.  A
    default method is provided by class FUNDAMENTAL-STREAM which returns
    true if CLOSE has not been called on the stream.

  STREAMP  object				[Generic Function]
  INPUT-STREAM-P  stream			[Generic Function]
  OUTPUT-STREAM-P  stream			[Generic Function]

    These three existing predicates may optionally be implemented as
    generic functions for implementations that want to permit users to
    define streams that are not STANDARD-OBJECTs.  Normally, the default
    methods provided by classes FUNDAMENTAL-INPUT-STREAM and
    FUNDAMENTAL-OUTPUT-STREAM are sufficient.  Note that, for example,
    (INPUT-STREAM-P x) is not equivalent to (TYPEP x
    'FUNDAMENTAL-INPUT-STREAM) because implementations may have
    additional ways of defining their own streams even if they don't
    make that visible by making these predicates generic.

  STREAM-ELEMENT-TYPE  stream			[Generic Function]

    This existing function is made generic, but otherwise behaves the
    same.  Class FUNDAMENTAL-CHARACTER-STREAM provides a default method
    which returns CHARACTER.

  PATHNAME and TRUENAME are also permitted to be implemented as generic
  functions.  There is no default method since these are not valid for
  all streams.


 Binary streams:

    Binary streams can be created by defining a class that includes either
    FUNDAMENTAL-BINARY-INPUT-STREAM or FUNDAMENTAL-BINARY-OUTPUT-STREAM
    (or both) and defining a method for STREAM-ELEMENT-TYPE and for one or
    both of the following generic functions.

  STREAM-READ-BYTE  stream			[Generic Function]

    Used by READ-BYTE; returns either an integer, or the symbol :EOF if the
    stream is at end-of-file.

  STREAM-WRITE-BYTE stream integer		[Generic Function]

    Implements WRITE-BYTE; writes the integer to the stream and returns
    the integer as the result.


Rationale:

  The existing I/O functions cannot be made generic because, in nearly
  every case, the stream argument is optional, and therefore cannot be
  specialized.  Therefore, it is necessary to define a lower-level
  generic function to be used by the existing function.  It also isn't
  appropriate to specialize on the second argument of PRINT-OBJECT because
  it is a higher-level function -- even when the first argument is a
  character or a string, it needs to format it in accordance with
  *PRINT-ESCAPE*.

  In order to make the meaning as obvious as possible, the names of the
  generic functions have been formed by prefixing "STREAM-" to the
  corresponding non-generic function.

  Having the generic input functions just return :EOF at end-of-file, with
  the higher-level functions handling the eof-error-p and eof-value
  arguments, simplifies the generic function interface and makes it more
  efficient by not needing to pass through those arguments.  Note that the
  functions that use this convention can only return a character or
  integer as a stream element, so there is no possibility of ambiguity.

  Functions STREAM-LINE-COLUMN, STREAM-START-LINE-P, and
  STREAM-ADVANCE-TO-COLUMN may appear to be a reincarnation of the
  defeated proposal STREAM-INFO, but the motivation here is different.
  This interface needs to be defined if user-defined streams are to be
  able to be used by PPRINT and FORMAT ~T, which could be viewed as a
  separate question from whether the user can call then on
  system-defined streams.

Current practice:

  No one currently supports exactly this proposal, but this is very
  similar to the stream interface used in CLUE.

  On descendants of the MIT Lisp Machine, streams can be implemented
  by users as either flavors, with methods to accept the various
  messages corresponding to the I/O operations, or as functions, which
  take a message keyword as their first argument.

Examples:

  ;;;; Here is an example of how the default methods could be
  ;;;; implemented (omitting the most trivial ones):

  (defmethod STREAM-PEEK-CHAR ((stream fundamental-character-input-stream))
    (let ((character (stream-read-char stream)))
      (unless (eq character :eof)
	(stream-unread-char stream character))
      character))

  (defmethod STREAM-LISTEN ((stream fundamental-character-input-stream))
    (let ((char (stream-read-char-no-hang stream)))
      (and (not (null char))
	   (not (eq char :eof))
	   (progn (stream-unread-char stream char) t))))

  (defmethod STREAM-READ-LINE ((stream fundamental-character-input-stream))
    (let ((line (make-array 64 :element-type 'string-char 
			    :fill-pointer 0 :adjustable t)))
      (loop (let ((character (stream-read-char stream)))
	      (if (eq character :eof)
		  (return (values line t))
		(if (eql character #\newline)
		    (return (values line nil))
		  (vector-push-extend character line)))))))

  (defmethod STREAM-START-LINE-P ((stream fundamental-character-output-stream))
    (equal (stream-line-column stream) 0))

  (defmethod STREAM-WRITE-STRING ((stream fundamental-character-output-stream)
				  string &optional (start 0) 
				  (end (length string)))
    (do ((i start (1+ i)))
	((>= i end) string)
      (stream-write-char stream (char string i))))

  (defmethod STREAM-TERPRI ((stream fundamental-character-output-stream))
    (stream-write-char stream #\newline)
    nil)

  (defmethod STREAM-FRESH-LINE ((stream fundamental-character-output-stream))
    (if (stream-start-line-p stream)
	nil
      (progn (stream-terpri stream) t)))

  (defmethod STREAM-ADVANCE-TO-COLUMN ((stream fundamental-character-output-stream) 
				       column)
    (let ((current (stream-line-column stream)))
      (unless (null current)
	(dotimes (i (- current column) t)
	  (stream-write-char stream #\space)))))

  (defmethod INPUT-STREAM-P ((stream fundamental-input-stream)) t)
  (defmethod INPUT-STREAM-P ((stream fundamental-output-stream))
    ;; allow the two classes to be mixed in either order
    (typep stream 'fundamental-input-stream))
  (defmethod OUTPUT-STREAM-P ((stream fundamental-output-stream)) t)
  (defmethod OUTPUT-STREAM-P ((stream fundamental-input-stream))
    (typep stream 'fundamental-output-stream))

  ;;;; Following is an example of how the existing I/O functions could
  ;;;; be implemented using standard Common Lisp and the generic
  ;;;; functions specified above.  The standard functions being defined
  ;;;; are in upper case.

  ;;  Internal helper functions

  (proclaim '(inline decode-read-arg decode-print-arg check-for-eof))
  (defun decode-read-arg (arg)
    (cond ((null arg) *standard-input*)
	  ((eq arg t) *terminal-io*)
	  (t arg)))
  
  (defun decode-print-arg (arg)
    (cond ((null arg) *standard-output*)
	  ((eq arg t) *terminal-io*)
	  (t arg)))
  
  (defun check-for-eof (value stream eof-errorp eof-value)
    (if (eq value :eof)
	(report-eof stream eof-errorp eof-value)
      value))
  
  (defun report-eof (stream eof-errorp eof-value)
    (if eof-errorp
	(error 'end-of-file :stream stream)
      eof-value))
  
  ;;;  Common Lisp input functions
  
  (defun READ-CHAR (&optional input-stream (eof-errorp t) eof-value recursive-p)
    (declare (ignore recursive-p)) ; a mistake in CLtL?
    (let ((stream (decode-read-arg input-stream)))
      (check-for-eof (stream-read-char stream) stream eof-errorp eof-value)))
  
  (defun PEEK-CHAR (&optional peek-type input-stream (eof-errorp t) 
			eof-value recursive-p)
    (declare (ignore recursive-p))
    (let ((stream (decode-read-arg input-stream)))
      (if (null peek-type)
	  (check-for-eof (stream-peek-char stream) stream eof-errorp eof-value)
        (loop
	  (let ((value (stream-peek-char stream)))
	    (if (eq value :eof)
		(return (report-eof stream eof-errorp eof-value))
	      (if (if (eq peek-type t)
		      (not (member value '(#\space #\tab #\newline
					   #\page #\return #\linefeed)))
		    (char= peek-type value))
		  (return value)
		(stream-read-char stream))))))))
  
  (defun UNREAD-CHAR (character &optional input-stream)
    (stream-unread-char (decode-read-arg input-stream) character))
  
  (defun LISTEN (&optional input-stream)
    (stream-listen (decode-read-arg input-stream)))
  
  (defun READ-LINE (&optional input-stream (eof-error-p t) 
			eof-value recursive-p)
    (declare (ignore recursive-p))
    (let ((stream (decode-read-arg input-stream)))
      (multiple-value-bind (string eofp)
	  (stream-read-line stream)
	(if eofp
	    (if (= (length string) 0)
		(report-eof stream eof-error-p eof-value)
	      (values string t))
	  (values string nil)))))
  
  (defun CLEAR-INPUT (&optional input-stream)
    (stream-clear-input (decode-read-arg input-stream)))
  
  (defun READ-CHAR-NO-HANG (&optional input-stream (eof-errorp t) 
				eof-value recursive-p)
    (declare (ignore recursive-p))
    (let ((stream (decode-read-arg input-stream)))
      (check-for-eof (stream-read-char-no-hang stream)
		     stream eof-errorp eof-value)))
  
  ;;;  Common Lisp output functions
  
  (defun WRITE-CHAR (character &optional output-stream)
     (stream-write-char (decode-print-arg output-stream) character))
  
  (defun FRESH-LINE (&optional output-stream)
    (stream-fresh-line (decode-print-arg output-stream)))
  
  (defun TERPRI (&optional output-stream)
    (stream-terpri (decode-print-arg output-stream)))
  
  (defun WRITE-STRING (string &optional output-stream &key (start 0) end)
    (stream-write-string (decode-print-arg output-stream) string start end))
  
  (defun WRITE-LINE (string &optional output-stream &key (start 0) end)
    (let ((stream (decode-print-arg output-stream)))
      (stream-write-string stream string start end)
      (stream-terpri stream)
      string))
  
  (defun FORCE-OUTPUT (&optional stream)
    (stream-force-output (decode-print-arg stream)))
  
  (defun FINISH-OUTPUT (&optional stream)
    (stream-finish-output (decode-print-arg stream)))
  
  (defun CLEAR-OUTPUT (&optional stream)
    (stream-clear-output (decode-print-arg stream)))
  
  ;;;  Binary streams

  (defun READ-BYTE (binary-input-stream &optional (eof-errorp t) eof-value)
    (check-for-eof (stream-read-byte binary-input-stream) 
		   binary-input-stream eof-errorp eof-value))
  
  (defun WRITE-BYTE (integer binary-output-stream)
    (stream-write-byte binary-output-stream integer))

  ;;;  String streams
  
  (defclass string-input-stream (fundamental-character-input-stream)
    ((string :initarg :string :type string)
     (index :initarg :start :type fixnum)
     (end :initarg :end :type fixnum)
     ))
  
  (defun MAKE-STRING-INPUT-STREAM (string &optional (start 0) end)
    (make-instance 'string-input-stream :string string 
		   :start start :end (or end (length string))))
  
  (defmethod stream-read-char ((stream string-input-stream))
    (with-slots (index end string) stream
      (if (>= index end)
	  :eof
	(prog1 (char string index)
	       (incf index)))))
  
  (defmethod stream-unread-char ((stream string-input-stream) character)
    (with-slots (index end string) stream
      (decf index)
      (assert (eql (char string index) character))
      nil))
  
  (defmethod stream-read-line ((stream string-input-stream))
    (with-slots (index end string) stream
      (let* ((endline (position #\newline string :start index :end end))
	     (line (subseq string index endline)))
	(if endline
	    (progn (setq index (1+ endline))
		   (values line nil))
	  (progn (setq index end)
		 (values line t))))))
  
  (defclass string-output-stream (fundamental-character-output-stream)
    ((string :initform nil :initarg :string)))

  (defun MAKE-STRING-OUTPUT-STREAM ()
    (make-instance 'string-output-stream))

  (defun GET-OUTPUT-STREAM-STRING (stream)
    (with-slots (string) stream
      (if (null string)
	  ""
	(prog1 string (setq string nil)))))
  
  (defmethod stream-write-char ((stream string-output-stream) character)
    (with-slots (string) stream
      (when (null string)
	(setq string (make-array 64. :element-type 'string-char 
				 :fill-pointer 0 :adjustable t)))
      (vector-push-extend character string)
      character))
  
  (defmethod stream-line-column ((stream string-output-stream))
    (with-slots (string) stream
      (if (null string)
	  0
	(let ((nx (position #\newline string :from-end t)))
	  (if (null nx)
	      (length string)
	    (- (length string) nx 1))
	  ))))

Cost to Implementors:

  Given that CLOS is supported, adding the above generic functions and
  methods is easy, since most of the code is included in the examples
  above.  The hard part would be re-writing existing I/O functionality in
  terms of methods on these new generic functions.  That could be
  simplified if methods can be defined to forward the operations to the
  old representation of streams.  For a new implementation, the cost could
  be zero since an approach similar to this would likely be used anyway.

Cost to Users:

  None; this is an upward-compatible addition.   Users won't even
  need to know anything about this unless they actually need this feature.

Cost of non-adoption:

  Development of portable I/O extensions will be discouraged.

Performance impact:

  This shouldn't affect performance of new implementations (assuming an
  efficient CLOS implementation), but it could slow down I/O if it were
  clumsily grafted on top of an existing implementation.

Benefits:

  A broader domain of programs that can be written portably.

Esthetics:

  This seems to be a simple, straight-forward approach.

Discussion:

  This proposal incorporates suggestions made by several people in
  response to an earlier outline.  So far, no one has expressed opposition
  to the concept.  There are some differences of opinion about whether
  certain operations should have default methods or required methods:
  STREAM-LISTEN, STREAM-READ-CHAR-NO-HANG, STREAM-LINE-COLUMN,
  and STREAM-START-LINE-P.

  An experimental prototype of this has been successfully implemented on
  the Explorer.

  This proposal does not provide sufficient capability to implement
  forwarding streams such as for MAKE-SYNONYM-STREAM,
  MAKE-BROADCAST-STREAM, MAKE-CONCATENATED-STREAM, MAKE-TWO-WAY-STREAM, or
  MAKE-ECHO-STREAM.  The generic function approach does not lend itself as
  well to that as a message passing model where the intermediary does not
  need to know what all the possible messages are.  A possible way of
  extending it for that would be to define a class 

    (defclass stream-generic-function (standard-generic-function) ())

  to be used as the :generic-function-class option for all of the I/O
  generic functions.  This would then permit doing something like

  (defmethod no-applicable-method ((gfun stream-generic-function) &rest args) 
    (if (streamp (first args))
	(apply #'stream-operation-not-handled (first args) gfun (rest args))
      (call-next-method)))

  where stream-operation-not-handled is a generic function whose default
  method signals an error, but forwarding streams can define methods that
  will create a method to handle the unexpected operation.  (Perhaps
  NO-APPLICABLE-METHOD should be changed to take two required arguments
  since all generic functions need at least one required argument, and
  that would make it unnecessary to define a new generic function class
  just to be able to write this one method.)

  Another thing that is not addressed here is a way to cause an instance
  of a user-defined stream class to be created from a call to the OPEN
  function.  That should be part of a separate issue for generic functions
  on pathnames.  If that capability were available, then PATHNAME and
  TRUENAME should be required to be generic functions.

  An earlier draft defined just two classes, FUNDAMENTAL-INPUT-STREAM and
  FUNDAMENTAL-OUTPUT-STREAM, that were used for both character and binary
  streams.  It isn't clear whether that simple approach is sufficient or
  whether the larger set of classes is really needed.

∂02-Apr-89  1536	RPG 	Implementation of CLOS   
 ∂29-Mar-89  0522	BRANDIMARTE%ITOPOLI1.BITNET@Forsythe.Stanford.EDU 	Implementation of CLOS  
Received: from Forsythe.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Mar 89  05:21:15 PST
Received: by Forsythe.Stanford.EDU; Wed, 29 Mar 89 05:21:15 PST
Date: Wed, 29 Mar 89 12:06 GMT+1
From: BRANDIMARTE%ITOPOLI1.BITNET@Forsythe.Stanford.EDU
Subject: Implementation of CLOS
To: common-lisp-object-system-specification-request@sail.STANFORD.EDU
X-VMS-To: IN%"common-lisp-object-system-specification-request@sail.stanford.edu"


Gentlemen,

        I send this message to ask You informations about the implementation
state of the Common Lisp Object System. Do You think a commercial
implementation will be available in the short term ?

        Regards.

        Paolo Brandimarte
        Dipartimento di Automatica e Informatica
        Politecnico di Torino
        Corso Duca degli Abruzzi 24
        10129 Torino Italy

        e-mail brandimarte@itolpoli.bitnet

∂03-Apr-89  1421	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Apr 89  14:21:20 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA24104; Mon, 3 Apr 89 15:21:15 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA18470; Mon, 3 Apr 89 15:21:13 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904032121.AA18470@defun.utah.edu>
Date: Mon, 3 Apr 89 15:21:11 MDT
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY
To: cl-compiler@sail.stanford.edu
Cc: common-lisp-object-system@sail.stanford.edu

At the meeting, an amendment was proposed to this issue to replace all of
the current item (g) with:

  The compiler can assume that type definitions made with DEFTYPE or
  DEFSTRUCT in the compiletime environment will retain the same
  definition in the runtime environment.  This implies that
  subtype/supertype relationships of type specifiers defined by DEFTYPE
  or DEFSTRUCT will not change between compiletime and runtime.  (Note
  that it is not an error for an unknown type to appear in a declaration
  at compiletime, although it is reasonable for the compiler to emit a
  warning in such a case.)

The proposal was tabled with this amendment pending (it was not
officially seconded or voted on).  

Having had time to think about this for a while, to me it seems like
this amendment is going to cause trouble.  I've been thinking about
our canonical example of a type-inferencing preprocessor.  Such a
preprocessor could conceivably be written so as not make use of
information about certain type relationships, provided that it is
possible to test whether a type specifier is one of the ones that it
can't make assumptions about.  That's the real problem: given a type
specifier, how do you know whether it was defined with DEFTYPE or
DEFSTRUCT, or some other way?

Also, one might want to define a metaclass that does license the
compiler to make assumptions about the type hierarchy of its instance
classes not changing.  (In fact, I think this would be a rather common
extension.)

I wouldn't object to rewording the amendment so that the compiler is
permitted to make assumptions about all type specifiers except those
that name classes whose metaclass is (a subclass of) STANDARD-CLASS.
It's at least possible (although a little convoluted) to test for that.

What do the rest of you think about this?

-Sandra
-------

∂03-Apr-89  1453	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Apr 89  14:53:10 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570544; Mon 3-Apr-89 17:52:13 EDT
Date: Mon, 3 Apr 89 17:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@sail.stanford.edu, common-lisp-object-system@sail.stanford.edu
In-Reply-To: <8904032121.AA18470@defun.utah.edu>
Message-ID: <19890403215202.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

  What do the rest of you think about this?

I think you're pointing in the right direction, however there is a
problem.  Any specification in terms of the metaclass requires that
class objects be created at compile time by COMPILE-FILE, or there
is no reasonable way to find out at compile time what the metaclass
is.  CLOS-MACRO-COMPILATION (which you wrote) seems to be trying to
avoid requiring any compile-time objects to be created.  So we have
a conflict between two proposals.  In fact it's possible that the
metaclass is the wrong way to say "this class will not be redefined
later" and instead that should be said by the way that the program
is compiled, not by anything in the program, making it an environment
issue rather than a language issue.

An interesting question is whether this type-inferencing preprocessor
is supposed to be able to accept all conforming programs, or only
a subset of conforming programs subject to additional restrictions,
for example that class definitions in the program are not changed
between preprocess time and run time.  Saying that we have two languages,
the full language and the type-inferencing preprocessable subset,
might eliminate the conflict here (although it will likely make
Gabriel sound off).

∂03-Apr-89  1510	Common-Lisp-Object-System-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Apr 89  15:10:36 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA15372g; Mon, 3 Apr 89 15:04:47 PDT
Received: by challenger id AA05980g; Mon, 3 Apr 89 14:59:57 PDT
Date: Mon, 3 Apr 89 14:59:57 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8904032159.AA05980@challenger>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu, common-lisp-object-system@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 3 Apr 89 15:21:11 MDT <8904032121.AA18470@defun.utah.edu>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY

   From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
   Date: Mon, 3 Apr 89 15:21:11 MDT

   At the meeting, an amendment was proposed to this issue to replace all of
   the current item (g) with:

     The compiler can assume that type definitions made with DEFTYPE or
     DEFSTRUCT in the compiletime environment will retain the same
     definition in the runtime environment.  This implies that
     subtype/supertype relationships of type specifiers defined by DEFTYPE
     or DEFSTRUCT will not change between compiletime and runtime.  (Note
     that it is not an error for an unknown type to appear in a declaration
     at compiletime, although it is reasonable for the compiler to emit a
     warning in such a case.)

   The proposal was tabled with this amendment pending (it was not
   officially seconded or voted on).  

   Also, one might want to define a metaclass that does license the
   compiler to make assumptions about the type hierarchy of its instance
   classes not changing.  (In fact, I think this would be a rather common
   extension.)

   I wouldn't object to rewording the amendment so that the compiler is
   permitted to make assumptions about all type specifiers except those
   that name classes whose metaclass is (a subclass of) STANDARD-CLASS.
   It's at least possible (although a little convoluted) to test for that.

   What do the rest of you think about this?

When we drafted the amendment, I was thinking of specifying the behavior of
conforming programs. Precisely, I think that it provides an answer to the
following question:
 What kinds of consistency should the programmer preserve, from compile-file
to load? with the understanding that these constraints of consistency are
dictated by the compiler.
What we are proposing, is that in the general case, the user is free to
redefine the class between compile-file and load. 

In this sense, the situation you describe has little bearing. I your case, the
kind of consistency that the programmer has to maintain is dictated by the
metaclass, not by the compiler. If compile-file can take advantage of this
restriction, fine. I don't think that an implementation doing just that would
violate the proposal as amended.


Your first question about type-inference preprocessor touches more on
compile-time meta-object creation, or syntatic-environment access. I
understand the problem, I don't know what is the best solution. I personally
lean towards extending the syntactic environment access, because we don't want
to specify that metaobject should be instantiated at compile time.

Patrick.

∂03-Apr-89  1603	CL-Compiler-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Apr 89  16:03:05 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA00322; Mon, 3 Apr 89 17:03:00 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA18576; Mon, 3 Apr 89 17:02:54 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904032302.AA18576@defun.utah.edu>
Date: Mon, 3 Apr 89 17:02:53 MDT
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
To: cl-compiler@sail.stanford.edu
Cc: common-lisp-object-system@sail.stanford.edu

> Date: Mon, 3 Apr 89 17:52 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
> CLOS-MACRO-COMPILATION (which you wrote) seems to be trying to
> avoid requiring any compile-time objects to be created.  So we have
> a conflict between two proposals.

Right.  In fact, I had such potential conflicts in the back of my mind
when I decided to keep CLOS-MACRO-COMPILATION on hold until we got a
better handle on how to resolve this issue.

> Date: Mon, 3 Apr 89 14:59:57 PDT
> From: Patrick Dussud <dussud@lucid.com>
> 
> Your first question about type-inference preprocessor touches more on
> compile-time meta-object creation, or syntatic-environment access. I
> understand the problem, I don't know what is the best solution. I personally
> lean towards extending the syntactic environment access, because we don't want
> to specify that metaobject should be instantiated at compile time.

The idea behind such a preprocessor is that it would preserve the
semantics of the code it examines.  It shouldn't make any assumptions
about types that the compiler itself would not be able to make.

I agree that extending SYNTACTIC-ENVIRONMENT-ACCESS would be a
reasonable solution to the problem.  In particular, I remember hearing
suggestions in the past to add TYPE-EXPAND and TYPE-EXPAND-1
functions, that would at least take care of the problems relating to
DEFTYPE.  (The interesting thing about DEFTYPE as it relates to this
problem is not determinining whether a type specifier has been defined
with DEFTYPE, but rather what that DEFTYPE expands into.)

I don't think that not having a metaclass for a STANDARD-CLASS object
defined at compile-time is a serious problem.  If there's no metaclass
around, that would just indicate that you can't make any assumptions
about the type, the same as if it were not defined at all.  (In fact,
I think it would be consistent if DEFCLASS didn't make the
corresponding type specifier defined at compile-time either.)

Is it unreasonable to require that DEFSTRUCT make the metaclass be
defined at compile-time?

-Sandra
-------

∂04-Apr-89  0909	Common-Lisp-Object-System-mailer 	Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  09:09:32 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 APR 89 08:57:37 PDT
Date: Tue, 4 Apr 89 08:54 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
 cl-compiler@sail.stanford.edu, common-lisp-object-system@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <19890403215202.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890404155429.5.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no

I won't be able to respond to this until Friday as I am about to go out
of town.

In fact, the only reason I am here now is that 4 different airlines
cancelled their morning flights to Boston.
-------

∂06-Apr-89  1715	Common-Lisp-Object-System-mailer 	[kempf%Sun:COM:Xerox: CLOS Slot Subclassing Rule Violates    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Apr 89  17:15:33 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 06 APR 89 16:55:14 PDT
Date: 6 Apr 89 16:54 PDT
From: masinter.pa@Xerox.COM
Subject: [kempf%Sun:COM:Xerox: CLOS Slot Subclassing Rule Violates
 Contravariance]
To: common-lisp-object-system@sail.stanford.edu
Message-ID: <890406-165514-7021@Xerox>

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

Date: 31 Mar 89 13:53 PST
From: kempf%Sun:COM:Xerox
Subject: CLOS Slot Subclassing Rule Violates Contravariance
To: masinter:PA:Xerox


Larry:

The CLOS rules for subtyping a slot violate contravariance. This means
that it is possible to type check a slot access and still end up getting
a no matching method message at run time.

I personally believe that this should be fixed, however, I am not prepared
to invest any time in it, because I suspect there are a number of
people on the committee (perhaps you among them?) who don't particularly
care whether this is a problem, since Common Lisp is by nature untyped.
This argument would maintain that no matching methods at run time are
OK, even if the compiler tries to get rid of them.

I'm prepared to submit a proposal, but, I don't plan to get into
a fruitless argument about whether types are good or bad. The proposal
would have the following suggestions to eliminate the problem:

1) Slot typing be removed from CLOS. All slots are therefore untyped.

2) The typing rules be tightened up so that contravariance is
respected.

The upshot is that slot subtyping either be done right or it not be done
at all.

Incidently, something similar can happen with methods, but I think 
the argument for dynamic binding is stronger because the need for
optimization is less critical.

		jak




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

Date:  3 Apr 89 14:10 PDT
From: masinter:PARC:Xerox
Subject: Re: CLOS Slot Subclassing Rule Violates Contravariance
In-Reply-to: kempf%Sun:COM's message of Friday, March 31, 1989  1:53 pm
To: kempf%Sun:COM:Xerox

I think the goal was to make it compatible with :TYPE in defstruct. 

Xerox Common Lisp used :TYPE in defstruct to allow for compact structures.

I don't understand how the CLOS rules for subtyping a slot violates
contravariance and how this could mean that it is possible to type check a
slot access and still end up getting a no matching method message at run
time. I thought the goal of slot typing was to allow for specialized
storage for some kinds of types. Maybe you're trying to optimize a
different goal?

In any case, whether you have a formal proposal or an informal one, you
should discuss this on the common-lisp-object-system mailing list and see
if you can get a couple of other people to agree with you.

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

∂07-Apr-89  0835	Common-Lisp-Object-System-mailer 	[kempf%Sun:COM:Xerox: CLOS Slot Subclassing Rule Violates    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 7 Apr 89  08:35:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 573337; Fri 7-Apr-89 11:34:59 EDT
Date: Fri, 7 Apr 89 11:34 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [kempf%Sun:COM:Xerox: CLOS Slot Subclassing Rule Violates
         Contravariance]
To: masinter.pa@Xerox.COM, Kempf@sun.com
cc: common-lisp-object-system@sail.stanford.edu
In-Reply-To: <890406-165514-7021@Xerox>
Message-ID: <19890407153450.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

Since I don't know what you mean by contravariance and since you
didn't supply an example exhibiting the problem, I can only ignore
this message.

∂09-Apr-89  1420	Common-Lisp-Object-System-mailer 	Re: [kempf%Sun:COM:Xerox: CLOS Slot Subclassing Rule Violates Contravariance]    
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 9 Apr 89  14:19:59 PDT
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
	id AA17178; Sun, 9 Apr 89 14:22:27 PDT
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.1)
	id AA20487; Sun, 9 Apr 89 14:18:22 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA03467; Sun, 9 Apr 89 14:20:21 PDT
Message-Id: <8904092120.AA03467@suntana.sun.com>
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: masinter.pa@xerox.com, common-lisp-object-system@sail.stanford.edu
Subject: Re: [kempf%Sun:COM:Xerox: CLOS Slot Subclassing Rule Violates Contravariance] 
In-Reply-To: Your message of Fri, 07 Apr 89 11:34:00 -0400.
             <19890407153450.1.MOON@EUPHRATES.SCRC.Symbolics.COM> 
Date: Sun, 09 Apr 89 14:20:19 PDT
From: kempf@Sun.COM


The following is a CLOS example which illustrates contravariance violation.

(defclass super ()
  ( (sl :type number :accessor s1) )
)

(defclass sub (super)
  ( (s1 :type integer :accessor s1) )
)

(defun do-bad ()
  (let ( (subi (make-instance 'super))
	 (sup NIL))
	 (declare (type super sup) (type sub subi))

	(setf sup subi)
	(setf (s1 sup) 1.2)))

The compiler type checks the function body OK, because the assignment
of subtyped identifier to a supertyped one is OK. Subclass objects
should be usable wherever their less specialized superclass objects
are. The type of the slot accessor new value argument for sub is 
(and integer number), effectively just integer, since that is the most 
restrictive type. The type of the new value argument for the super
slot accessor is number, so the setf checks OK. However, at run time,
there is no method matching, since the slot accessor for sub cannot
take a new value float.

Like I said, I don't want to get into a religious argument about whether
static typing is good or bad. But the very least one would expect from
the type system in an object-oriented language is that it would enable
you to write code that didn't get a no matching method message at run time.
You might also want to use it to get better performance in some way.
Incidently, the Eiffel programming language, which is fully statically type
checked and supposedly type safe, also has this problem.

My original message was sent only to Larry to inform him of the problem as
Cleanup Chair. I did not intend to have it redistributed, because X3J has
enough on its hands right now, and one could make a legitimate argument
that, since typing is "optional" in Common Lisp anyway, the problem was
not particularly serious. However, now that the issue has been broached,
we might as well discuss it.


		jak

∂10-Apr-89  1326	Common-Lisp-Object-System-mailer 	Re: [kempf%Sun:COM:Xerox: CLOS Slot Subclassing Rule Violates
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Apr 89  13:26:28 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 APR 89 13:10:02 PDT
Date: 10 Apr 89 13:09 PDT
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: [kempf%Sun:COM:Xerox: CLOS Slot Subclassing Rule Violates
 Contravariance] 
In-reply-to: kempf@Sun.COM's message of Sun, 09 Apr 89 14:20:19 PDT
To: kempf@Sun.COM
cc: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
 masinter.pa@Xerox.COM, common-lisp-object-system@sail.stanford.edu
Message-ID: <890410-131002-4883@Xerox>

    But the very least one would expect from the type system in an
    object-oriented language is that it would enable you to write code
    that didn't get a no matching method message at run time.

In our original discussion of accessors and types, I remember that the
model proposed was that:

(defclass foo ()
  ((bar :type baz :accessor foo-bar)))

would, if type checking were to be enforced in the accessors,  generate a
method equivalent to:

(defmethod (setf foo-bar) (new-value (inst foo))
   (check-type inst 'baz)
   (setf (slot-value inst bar) new-value))

This would give the expected error message.

There is a general confusion in the use of CLOS about whether
specialization of arguments should be used for type checking.  My take is
that these discrimination and type checking should be separated.  But it is
convenient to have type declarations in the header.  However, is easy to
make a special defining form, e.g.

(define-checked-method ((:check new-value baz) (inst foo))
      (setf (slot-value inst bar) new-value))

that expands into the definition above.  One might use the checking syntax
in optionals and keyword positions as well.
    

∂11-Apr-89  2331	Common-Lisp-Object-System-mailer 	Chap 3 question: Class of allocated instances.
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 11 Apr 89  23:31:45 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate.lucid.com id AA03025g; Tue, 11 Apr 89 23:31:59 PDT
Received: by bhopal id AA19866g; Tue, 11 Apr 89 23:31:52 PDT
Date: Tue, 11 Apr 89 23:31:52 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8904120631.AA19866@bhopal>
To: common-lisp-object-system@sail.stanford.edu
Subject: Chap 3 question: Class of allocated instances.

I'm wondering why one can't count on the following being true:

   (eq (find-class 'foo)  (class-of (allocate-instance 'foo)))

Presumably, if a programmer defined a method on 'allocate-instance'
he could have it return any old sort of widget (rather than a "foo").  
Is this useful?  Is it still useful if the constraint is added that

   (subtype (class-of (allocate-instance 'foo)) 'foo)

Without some such constraint, it might be possible for 

    (typep (allocate-instance 'foo) 'foo)

to be false.    It was similar such problems that led to the
"cleanup" proposal ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS -- that often
one could have the following turn out false:

    (typep (make-array <n> :element-type '(array <some-type>))
           '(array <some-type>))


-- JonL --

∂12-Apr-89  0814	Common-Lisp-Object-System-mailer 	Chap 3 question: Class of allocated instances.
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 12 Apr 89  08:14:09 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 575831; Wed 12-Apr-89 11:13:39 EDT
Date: Wed, 12 Apr 89 11:13 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Chap 3 question: Class of allocated instances.
To: Jon L White <jonl@lucid.com>
cc: common-lisp-object-system@sail.stanford.edu
In-Reply-To: <8904120631.AA19866@bhopal>
Message-ID: <19890412151329.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 11 Apr 89 23:31:52 PDT
    From: Jon L White <jonl@lucid.com>

    I'm wondering why one can't count on the following being true:

       (eq (find-class 'foo)  (class-of (allocate-instance 'foo)))

    Presumably, if a programmer defined a method on 'allocate-instance'
    he could have it return any old sort of widget (rather than a "foo").  
    Is this useful?  

Flavors has such a feature, which is used quite a bit.

		     Is it still useful if the constraint is added that

       (subtype (class-of (allocate-instance 'foo)) 'foo)

The Flavors feature satisfies this constraint.

    Without some such constraint, it might be possible for 

	(typep (allocate-instance 'foo) 'foo)

    to be false.    

I don't really see any reason for CLOS to prohibit users from creating
classes or metaclasses that behave this way, violating that constraint.
That might not be good style, and it might be the case that those classes
will not work with some programs.  But I don't see any reason to forbid
it outright.

∂12-Apr-89  0950	Common-Lisp-Object-System-mailer 	Chap 3 question: Class of allocated instances.
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 12 Apr 89  09:49:31 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03426g; Wed, 12 Apr 89 09:49:43 PDT
Received: by challenger id AA06224g; Wed, 12 Apr 89 09:49:33 PDT
Date: Wed, 12 Apr 89 09:49:33 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8904121649.AA06224@challenger>
To: jonl@lucid.com
Cc: common-lisp-object-system@sail.stanford.edu
In-Reply-To: Jon L White's message of Tue, 11 Apr 89 23:31:52 PDT <8904120631.AA19866@bhopal>
Subject: Chap 3 question: Class of allocated instances.


   Date: Tue, 11 Apr 89 23:31:52 PDT
   From: Jon L White <jonl>

   I'm wondering why one can't count on the following being true:

      (eq (find-class 'foo)  (class-of (allocate-instance 'foo)))
This is too restrictive, I think. Flavors defines some mechanisms where this
wouldn't be true. I know these machanisms are used in customer code.

   Presumably, if a programmer defined a method on 'allocate-instance'
   he could have it return any old sort of widget (rather than a "foo").  
   Is this useful?  Is it still useful if the constraint is added that

      (subtype (class-of (allocate-instance 'foo)) 'foo)
This looks more reasonnable. However I don't know if it gives  a tremendous
performance leverage for implementation to impose this restriction on all
metaclasses. I would like to see an argumentation before putting this
restriction (consistency of meta concepts, performance optimizations....,
flexibility of extension, less built-in assumptions....)
 
Patrick.

∂14-Apr-89  0932	Common-Lisp-Object-System-mailer 	Re: DEFSTRUCT and DEFCLASS
Received: from ti.com ([128.247.159.141]) by SAIL.Stanford.EDU with TCP; 14 Apr 89  09:32:03 PDT
Received: by ti.com id AA13419; Fri, 14 Apr 89 11:33:09 CDT
Received: from Kelvin by tilde id AA17618; Fri, 14 Apr 89 11:21:13 CDT
Message-Id: <2817562858-10264048@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 14 Apr 89  11:20:58 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@lucid.com>
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu
Subject: Re: DEFSTRUCT and DEFCLASS
In-Reply-To: Msg of Fri, 14 Apr 89 00:36:22 PDT from Jon L White <jonl@lucid.com>

>     whether
>       (DEFSTRUCT ... (:METACLASS STRUCTURE-CLASS))
>     is legal and, if so, just what it means.
> 
> Did anyone ever give satisfactory answers to your question about this?

No one ever responded to that message, but I did discuss it with Patrick
-- he felt that this didn't need to be supported until the metaclass
protocol was better defined.  I did notice since then, though, that the
working draft standard, March 21, page 2-5, says that "The :METACLASS
option is reserved for future use; an implementation can be extended to
make use of the :metaclass option."  That seems to answer the question as
far as the standard is concerned, but I feel uneasy about having that
sneaked in without discussion.

∂21-Apr-89  0020	Common-Lisp-Object-System-mailer 	DELPHI CLOS
Received: from Forsythe.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Apr 89  00:20:05 PDT
Received: by Forsythe.Stanford.EDU; Fri, 21 Apr 89 00:19:18 PDT
Received: by AEARN (Mailer X1.25) id 2553; Fri, 21 Apr 89 09:19:53 EDT
Date:         Fri, 21 Apr 89 09:14:41 EDT
From:         Wilhelm Burger <K320440%AEARN.BITNET@Forsythe.Stanford.EDU>
Subject:      DELPHI CLOS
To:           common-lisp-object-system@sail.stanford.edu

DELPHI (Italy) claims that they have a full implementation of CLOS? Has anybody
made experiences with that software?

W.Burger
Johannes Kepler University
Linz, Austria

∂27-Apr-89  1108	Common-Lisp-Object-System-mailer 	joining mailing list 
Received: from uunet.uu.net by SAIL.Stanford.EDU with TCP; 27 Apr 89  11:08:02 PDT
Received: from unido.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA06747; Thu, 27 Apr 89 14:06:26 -0400
Received: from slpfs1.uucp 
	by unido.irb.informatik.uni-dortmund.de with uucp via EUnet
	for uunet
	id AS06621; Thu, 27 Apr 89 18:28:53 +0100
Received: from tartaros.slpfs1.com by slpfs1.slpfs1.com (3.2/SMI-3.2)
	id AA02871; Thu, 27 Apr 89 14:02:01 +0200
Received: by tartaros.slpfs1.com (4.0/SMI-3.2)
	id AA00657; Thu, 27 Apr 89 14:03:14 +0200
Date: Thu, 27 Apr 89 14:03:14 +0200
From: unido!slpfs1!tartaros!sz@uunet.UU.NET (Peter Szabo)
Message-Id: <8904271203.AA00657@tartaros.slpfs1.com>
To: Common-Lisp-Object-System@Sail.Stanford.edu
Subject: joining mailing list


Please put me on your mailing list concerning CLOS news.
We are working with symbolics and are currently moving from flavors
to PCL and hopefully soon to CLOS. In Germany there are no relevant
information sources about CLOS/PCL. We would be happy to get at least
the file cloops.text

	Thank you

∂02-May-89  1042	Common-Lisp-Object-System-mailer 	CLOS Workshop   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 May 89  10:42:02 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 02 MAY 89 10:31:51 PDT
Date: Tue, 2 May 89 10:22 PDT
From: Gregor.pa@Xerox.COM
Subject: CLOS Workshop
To: CommonLoops.PA@Xerox.COM, common-lisp-object-system@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest
Message-ID: <19890502172212.4.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no


I have received a number of questions about this, so I thought this
might be generally useful information.

The second CLOS Users and Implementors workshop will be help at the
OOPSLA conference this year.  The date is not yet set but will probably
be October 2nd.  There will be a modest fee, in addition to the OOPSLA
registration fee, for attending the workshop.

This year's workshop will have a somewhat different format than last
year.  In particular, attendance at this year's workshop will be more
limited.  This will make it possible to have a more intensive workshop
which we feel is more appropriate at this stage in the growth of the
CLOS community.  The papers that are submitted will be reviewed by a
panel of CLOS experts, and workshop participants will be selected on
this basis.

What follows it the formal announcement to be included in the advance
publicity for OOPSLA:


  The Second Annual CLOS Users and Implementors Workshop

This workshop is for persons with substantial experience with the Common
Lisp Object System.  The purpose of this workshop is to bring together a
wide range of CLOS expertise in a setting which promotes substantive
interaction among the participants.   The workshop will address current
issues in the use, development and implementation of CLOS.  

In order to promote intensive interaction among workshop participants,
attendance will be limited to 30 people.  Persons who would like to
attend should submit five copies of a short (5 - 10 page) paper
describing their work with CLOS.  This can include more general work in
OO systems as it relates to CLOS.  It is permissible for this to be a
paper which will be presented in the main track of the conference.

Papers must be received by August 1 1989 and should be sent to:

Gregor Kiczales
Xerox PARC
3333 Coyote Hill Rd.
Palo Alto, CA 94304
-------

∂08-May-89  1949	Common-Lisp-Object-System-mailer 	DEFINE-METHOD-COMBINATION issues    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 8 May 89  19:48:53 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 591903; 8 May 89 22:49:23 EDT
Date: Mon, 8 May 89 22:49 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DEFINE-METHOD-COMBINATION issues 
To: Common-Lisp-Object-System@sail.stanford.edu
cc: Scott Cyphers <Cyphers@JASPER.SCRC.Symbolics.COM>, SKeene@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <19890508210229.5.CYPHERS@SEAR.SCRC.Symbolics.COM>
Message-ID: <19890509024926.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

Here are some questions about unclarities in 88-002R revolving around
method combination, along with my suggested answers.  Any comments?
I think I will try to use the eventual resolution of this to improve
the writeup in the ANSI Common Lisp draft specification.

    Can CALL-NEXT-METHOD be called lexically within a MAKE-METHOD?

p.2-12 says CALL-NEXT-METHOD can be used in the body of a method defined
by a method-defining form, and 1-22 defines "method-defining form" and
does not include MAKE-METHOD, so I think that CALL-NEXT-METHOD is not
specified to work in MAKE-METHOD.  The 2-12 text may have been meant to
exclude methods created with the chapter 3 function MAKE-METHOD-LAMBDA,
but in fact it's clear from the draft of chapter 3 that CALL-NEXT-METHOD
does work in such methods.  So I don't really know what the intent of
2-12 was, but I think it would be safe to assume that CALL-NEXT-METHOD
need not be supported in MAKE-METHOD.  Example:

(call-method (make-method (or (frob) (call-next-method)))
             ,remaining-methods)

could be rewritten:

(or (frob) (call-method ,(first remaining-methods)
                        ,(rest remaining-methods)))

See additional discussion below.

    Does CALL-METHOD use the arguments of the effective method, or does it
    use the arguments of the MAKE-METHOD that it was a part of?  For
    example,
    
       (DEFMETHOD CHANGE :AROUND (X &OPTIONAL (N 1))
         (CALL-NEXT-METHOD X (MIN N 0)))
       
       (DEFMETHOD CHANGE (X &OPTIONAL (N 2))
         N)
    
    What does (CHANGE T 5) return?  A strict reading of the spec says 5,
    but my intuition says 0, and 0 is a lot easier to implement.

If this is standard method combination, and there are no other methods,
the effective method is

  (call-method <:around method>
               ((make-method (call-method <primary method>))))

and the target of the CALL-NEXT-METHOD is the MAKE-METHOD.
p.2-11: "The arguments are the arguments that were supplied to the
effective method form containing the invocation of CALL-METHOD."
But this is ambiguous, does "the effective method form" mean the whole
thing, or just the part containing the invocation of CALL-METHOD?  If it
had meant the whole thing, I think it would have said "the arguments
that were supplied to the generic function".  Also it makes more sense
that once call-next-method changes the arguments, they don't "randomly"
change back to the original arguments.  So I think the example returns
0.  I propose to change the text on p.2-11 to say "The arguments are the
arguments that were supplied to the innermost MAKE-METHOD-created
method enclosing the invocation of CALL-METHOD, or if there is no
MAKE-METHOD, the arguments that were supplied to the generic function."
I'd like to say this in fewer words, but couldn't think of a way.

    Is the effective method code a real Lisp form, i.e. can it contain
    forms which require closures, like:
    
       (BLOCK TOO-DEEP
         (CALL-METHOD ,(FIRST PRE-METHODS)
                      (,@(REST PRE-METHODS)
                       (MAKE-METHOD (RETURN-FROM TOO-DEEP NIL))))
         (CALL-METHOD ,(FIRST POST-METHODS)
                      (,@(REST POST-METHODS)
                       (MAKE-METHOD T))))

Nothing in chapter 1 or 2 mentions any restrictions on what the
effective method form can do, so the answer should be yes.  The
problem is that the description of MAKE-METHOD (p.2-11) fails to
specify the lexical environment of the form its given.  Nor does
anything specify the lexical environment of the overall effective
method form.  After thinking about it a bit, I believe the intention
was that both of these forms are in the null lexical environment.
Thus the answer is that this example code is not valid.

Unless there are further comments, I propose to change the ANSI
Common Lisp specification to say both effective method forms and
MAKE-METHOD forms are in the null lexical environment.  Note that
this implies no CALL-NEXT-METHOD inside of MAKE-METHOD.  And no
CONTINUE-WHOPPER inside of a DEFWRAPPER, to translate back to
Flavors terminology.

    In 12/15/88 MOP Draft number 10, some places seem to think that a
    METHOD-COMBINATION object consists of the information supplied to
    DEFGENERIC (with a mysterious "Documentation" slot), and other places
    seem to think that it consists of the information supplied to
    DEFINE-METHOD-COMBINATION, but the slots only make sense for the short
    form.

The MOP draft is not part of the spec.  The relevant text from 89-002R is
  
  A method for {\bf compute-effective-method} can be defined directly by
  using {\bf defmethod} or indirectly by using {\bf
  define-method-combination}.  A {\bit method combination object} is an
  object that encapsulates the method combination type and options
  specified by the {\bf :method-combination} option to forms that
  specify generic function options.
  
  \item{\bull} Every method combination object is an instance of a
  subclass of the class {\bf method-combination}.

  The {\bf :method-combination} argument [to ensure-generic-function] is a
  method combination object.

  The first argument of {\bf documentation} is either a symbol, a
  function specifier list of the form {\tt (setf {\it symbol\/})}, a
  method object, a class object, a generic function object, a method
  combination object, or a slot description object.

  The form {\tt (documentation {\it symbol\/} 'method-combination)} returns the
  documentation string of the method combination type named by the
  symbol.  
  
Note: method combination type, not method combination object.

I think this makes it clear that the role of a method combination object
is to hold the information obtained by parsing the :METHOD-COMBINATION
option to DEFGENERIC.  The division of labor between slots in the method
combination object, methods for compute-effective-method applicable to
the method combination object, and methods for other generic functions
applicable to the method combination object, is not specified in 88-002R.
It might be specified in chapter 3 (but probably won't be).

The documentation mentioned on p.3-8 is the same documentation you would
get by first extracting the method combination type symbol and then
calling the function DOCUMENTATION with two arguments, that symbol and
the symbol METHOD-COMBINATION.  Chapter 3 is not supposed to specify
the existence of any slots for any meta objects.  I couldn't find 
anything about slots of method combination objects, but I didn't look
real hard since the MOP draft is not part of the language specification.

I'm not sure that any documentation change is required to clarify this.

    If a method gets redefined, do the effective methods get destructively
    modified or do new ones get created to take their place?  For example,
    
       (DEFMETHOD STRANGE (X)
         (LOOP (CALL-NEXT-METHOD) (REMOVE-METHOD ..some strange method..)))
    
    does the CALL-NEXT-METHOD continue to see the next methods as they were
    when strange was entered, or does each time around the loop see
    something different, or is this undefined?

Common Lisp rarely specifies what happens if programs modify themselves.
I think the results should be undefined.  I would expect that most
implementations would capture the next methods at the time the generic
function was called, so modifications would not be seen, but some
implementations might let the modifications be seen, either because they
are not optimized at all, or because they are highly optimized and
reuse some storage.

I'm not sure that any documentation change is required to clarify this.

    When the :ARGUMENTS option is used with DEFINE-METHOD-COMBINATION,
    how do the arguments get matched up with the actual arguments of the
    generic function?

The issue here is that p.2-34 says "If lambda-list is not congruent to
the generic function's lambda-list, additional ignored parameters are
automatically inserted until it is congruent", but this doesn't say
where they are inserted nor what happens if inserting additional
parameters can't make it congruent (e.g. too many required parameters
to begin with).  Are they inserted at the end?  At the end of each
group (required, optional, keyword)?  At the beginning??

We thought about simplifying this to just require the two lambda-lists
to be congruent, but that doesn't work well since a single method
combination type should be useable with many different generic functions
with different lambda-lists.

I think the best answer is to delete the stuff about congruence (the
last two sentences of the first paragraph on p.2-34) and simply say what
happens if the arguments supplied to the generic function don't match
the lambda-list: if there are too few arguments, NIL is assumed for
missing arguments.  If there are too many arguments, the extra arguments
are ignored.  If there are unhandled keyword arguments, they are
ignored.  Supplied-p parameters work in the normal fashion.  Default
value forms are evaluated in the null lexical environment (except for
bindings of :ARGUMENTS parameters to their left, of course).  This is
more or less what the equivalent Flavors feature does.  Any objections?

Also, what happens if the effective method form returned by your
body forms includes (setq ,variable ...) or (setf ,variable ...),
where variable is one of the :ARGUMENTS parameters?  I think
the consequences should be undefined.

                                Does CALL-METHOD take the original
    arguments, the way CALL-NEXT-METHOD with no arguments does, or does the
    method combiner get a chance to change things around, perhaps supplying
    a default for an optional or something?

CALL-METHOD uses the original arguments, as clearly documented.  The
extension to CALL-METHOD to allow specifying arguments, as in
CALL-NEXT-METHOD, was rejected by the committee, I don't remember if it
was for a good reason.  No way is provided for the effective method form
to change the original arguments.  Perhaps the first paragraph in the
arguments section of CALL-NEXT-METHOD, which says you can't change the
original arguments, should be repeated under CALL-METHOD or under
DEFINE-METHOD-COMBINATION.

∂10-May-89  1016	Common-Lisp-Object-System-mailer 	editorial correction to CLOS stuff  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 May 89  10:16:47 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 592824; 10 May 89 13:16:51 EDT
Date: Wed, 10 May 89 13:17 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: editorial correction to CLOS stuff
To: chapman%aitg.dec@decwrl.dec.com
cc: common-lisp-object-system@sail.stanford.edu
Message-ID: <19890510171702.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

I think this is small enough that it doesn't need to go through the
X3J13 cleanup process.  If anyone disagrees please let me know.
Kathy: I assume this text migrated into the X3J13 draft specification,
although I didn't find it in an excessively quick look through the
parts that happened to be in my office.  If no one objects, could you
update it?

Page 1-15 of 88-002R says

  Each class that corresponds to a predefined Common Lisp type specifier
  can be implemented in one of three ways, at the discretion of each
  implementation.  It can be a {\bit standard class\/} (of the kind
  defined by {\bf defclass}), a {\bit structure class\/} (defined
  by {\bf defstruct}), or a {\bit built-in class\/} (implemented in
  a special, non-extensible way).

This can be interpreted to mean that the metaclass of an object of a
predefined Common Lisp type can only be one of standard-class,
structure-class, or built-in-class, and no others.  I don't think
that was intended.  I don't think it was even intended that the
metaclass must be a subclass of one of those classes.  One example
where this came up is an implementation with Flavors, that implements
some predefined Common Lisp types using Flavors.  The metaclass of
a Flavors instance is certainly not any of those three.  I would
change that paragraph to read

  Each class that corresponds to a predefined Common Lisp type specifier
  can be implemented in one of four ways, at the discretion of each
  implementation.  It can be a {\bit standard class\/} (of the kind
  defined by {\bf defclass}), a {\bit structure class\/} (defined
  by {\bf defstruct}), a {\bit built-in class\/} (implemented in
  a special, non-extensible way), or some other implementation-defined
  class.

The paragraphs after it don't need to be changed.

∂10-May-89  1030	Common-Lisp-Object-System-mailer 	editorial correction to CLOS stuff  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 May 89  10:30:52 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 592837; 10 May 89 13:31:11 EDT
Date: Wed, 10 May 89 13:31 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: editorial correction to CLOS stuff
To: chapman%aitg.dec@decwrl.dec.com
cc: common-lisp-object-system@sail.stanford.edu
Supersedes: <19890510171702.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: Changed the wording after thinking about it over lunch
Message-ID: <19890510173122.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

I think this is small enough that it doesn't need to go through the
X3J13 cleanup process.  If anyone disagrees please let me know.
Kathy: I assume this text migrated into the X3J13 draft specification,
although I didn't find it in an excessively quick look through the
parts that happened to be in my office.  If no one objects, could you
update it?

Page 1-15 of 88-002R says

  Each class that corresponds to a predefined Common Lisp type specifier
  can be implemented in one of three ways, at the discretion of each
  implementation.  It can be a {\bit standard class\/} (of the kind
  defined by {\bf defclass}), a {\bit structure class\/} (defined
  by {\bf defstruct}), or a {\bit built-in class\/} (implemented in
  a special, non-extensible way).

This can be interpreted to mean that the metaclass of an object of a
predefined Common Lisp type can only be one of standard-class,
structure-class, or built-in-class, and no others.  I don't think
that was intended.  I don't think it was even intended that the
metaclass must be a subclass of one of those classes.  One example
where this came up is an implementation with Flavors, that implements
some predefined Common Lisp types using Flavors.  The metaclass of
a Flavors instance is certainly not any of those three.  I would
change that paragraph to read

  Each class that corresponds to a predefined Common Lisp type specifier
  can be implemented in one of four ways, at the discretion of each
  implementation.  It can be a {\bit standard class\/} (of the kind
  defined by {\bf defclass}), a {\bit structure class\/} (defined
  by {\bf defstruct}), a {\bit built-in class\/} (implemented in
  a special, non-extensible way), or any other implementation-defined
  class that is no more restrictive than a {\bit built-in class\/}.

The paragraphs after it don't need to be changed.

∂10-May-89  1131	Common-Lisp-Object-System-mailer 	Re: editorial correction to CLOS stuff   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 May 89  11:31:13 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 10 MAY 89 11:30:15 PDT
Date: Wed, 10 May 89 11:29 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: editorial correction to CLOS stuff
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: chapman%aitg.dec@decwrl.dec.com,
 common-lisp-object-system@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest
In-Reply-To: <19890510171702.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890510182921.0.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no

I agree this change is fine and should just be put in.
-------

∂10-May-89  1543	Common-Lisp-Object-System-mailer 	DEFINE-METHOD-COMBINATION issues    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 May 89  15:43:23 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA02737g; Wed, 10 May 89 15:42:36 PDT
Received: by challenger id AA01373g; Wed, 10 May 89 15:42:18 PDT
Date: Wed, 10 May 89 15:42:18 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8905102242.AA01373@challenger>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: Common-Lisp-Object-System@sail.stanford.edu,
        Cyphers@JASPER.SCRC.Symbolics.COM,
        SKeene@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: David A. Moon's message of Mon, 8 May 89 22:49 EDT <19890509024926.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: DEFINE-METHOD-COMBINATION issues 

   Date: Mon, 8 May 89 22:49 EDT
   From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

   Here are some questions about unclarities in 88-002R revolving around
   method combination, along with my suggested answers.  Any comments?
   I think I will try to use the eventual resolution of this to improve
   the writeup in the ANSI Common Lisp draft specification.

       Can CALL-NEXT-METHOD be called lexically within a MAKE-METHOD?

   p.2-12 says CALL-NEXT-METHOD can be used in the body of a method defined
   by a method-defining form, and 1-22 defines "method-defining form" and
   does not include MAKE-METHOD, so I think that CALL-NEXT-METHOD is not
   specified to work in MAKE-METHOD.  The 2-12 text may have been meant to
   exclude methods created with the chapter 3 function MAKE-METHOD-LAMBDA,
   but in fact it's clear from the draft of chapter 3 that CALL-NEXT-METHOD
   does work in such methods.  So I don't really know what the intent of
   2-12 was, but I think it would be safe to assume that CALL-NEXT-METHOD
   need not be supported in MAKE-METHOD.  Example:

   (call-method (make-method (or (frob) (call-next-method)))
		,remaining-methods)

   could be rewritten:

   (or (frob) (call-method ,(first remaining-methods)
			   ,(rest remaining-methods)))

   See additional discussion below.

       Does CALL-METHOD use the arguments of the effective method, or does it
       use the arguments of the MAKE-METHOD that it was a part of?  For
       example,

	  (DEFMETHOD CHANGE :AROUND (X &OPTIONAL (N 1))
	    (CALL-NEXT-METHOD X (MIN N 0)))

	  (DEFMETHOD CHANGE (X &OPTIONAL (N 2))
	    N)

       What does (CHANGE T 5) return?  A strict reading of the spec says 5,
       but my intuition says 0, and 0 is a lot easier to implement.

   If this is standard method combination, and there are no other methods,
   the effective method is

     (call-method <:around method>
		  ((make-method (call-method <primary method>))))

   and the target of the CALL-NEXT-METHOD is the MAKE-METHOD.
   p.2-11: "The arguments are the arguments that were supplied to the
   effective method form containing the invocation of CALL-METHOD."
   But this is ambiguous, does "the effective method form" mean the whole
   thing, or just the part containing the invocation of CALL-METHOD?  If it
   had meant the whole thing, I think it would have said "the arguments
   that were supplied to the generic function".  Also it makes more sense
   that once call-next-method changes the arguments, they don't "randomly"
   change back to the original arguments.  So I think the example returns
   0.  I propose to change the text on p.2-11 to say "The arguments are the
   arguments that were supplied to the innermost MAKE-METHOD-created
   method enclosing the invocation of CALL-METHOD, or if there is no
   MAKE-METHOD, the arguments that were supplied to the generic function."
   I'd like to say this in fewer words, but couldn't think of a way.

I makes sense. I think  that is the right thing to do.

       Is the effective method code a real Lisp form, i.e. can it contain
       forms which require closures, like:

	  (BLOCK TOO-DEEP
	    (CALL-METHOD ,(FIRST PRE-METHODS)
			 (,@(REST PRE-METHODS)
			  (MAKE-METHOD (RETURN-FROM TOO-DEEP NIL))))
	    (CALL-METHOD ,(FIRST POST-METHODS)
			 (,@(REST POST-METHODS)
			  (MAKE-METHOD T))))

   Nothing in chapter 1 or 2 mentions any restrictions on what the
   effective method form can do, so the answer should be yes.  The
   problem is that the description of MAKE-METHOD (p.2-11) fails to
   specify the lexical environment of the form its given.  Nor does
   anything specify the lexical environment of the overall effective
   method form.  After thinking about it a bit, I believe the intention
   was that both of these forms are in the null lexical environment.
   Thus the answer is that this example code is not valid.

   Unless there are further comments, I propose to change the ANSI
   Common Lisp specification to say both effective method forms and
   MAKE-METHOD forms are in the null lexical environment.  Note that
   this implies no CALL-NEXT-METHOD inside of MAKE-METHOD.  And no
   CONTINUE-WHOPPER inside of a DEFWRAPPER, to translate back to
   Flavors terminology.

The only comment I have is that I don't know if it is going to be seen as a
drastic constraint or not. I'd like to see others opinion on this.

       In 12/15/88 MOP Draft number 10, some places seem to think that a
       METHOD-COMBINATION object consists of the information supplied to
       DEFGENERIC (with a mysterious "Documentation" slot), and other places
       seem to think that it consists of the information supplied to
       DEFINE-METHOD-COMBINATION, but the slots only make sense for the short
       form.

I agree with what was said and I don't think we need to change the document.

   The issue here is that p.2-34 says "If lambda-list is not congruent to
   the generic function's lambda-list, additional ignored parameters are
   automatically inserted until it is congruent", but this doesn't say
   where they are inserted nor what happens if inserting additional
   parameters can't make it congruent (e.g. too many required parameters
   to begin with).  Are they inserted at the end?  At the end of each
   group (required, optional, keyword)?  At the beginning??

   We thought about simplifying this to just require the two lambda-lists
   to be congruent, but that doesn't work well since a single method
   combination type should be useable with many different generic functions
   with different lambda-lists.

   I think the best answer is to delete the stuff about congruence (the
   last two sentences of the first paragraph on p.2-34) and simply say what
   happens if the arguments supplied to the generic function don't match
   the lambda-list: if there are too few arguments, NIL is assumed for
   missing arguments.  If there are too many arguments, the extra arguments
   are ignored.  If there are unhandled keyword arguments, they are
   ignored.  Supplied-p parameters work in the normal fashion.  Default
   value forms are evaluated in the null lexical environment (except for
   bindings of :ARGUMENTS parameters to their left, of course).  This is
   more or less what the equivalent Flavors feature does.  Any objections?

   Also, what happens if the effective method form returned by your
   body forms includes (setq ,variable ...) or (setf ,variable ...),
   where variable is one of the :ARGUMENTS parameters?  I think
   the consequences should be undefined.


All of this sound good.


∂11-May-89  0630	Common-Lisp-Object-System-mailer 	Random metaclasses for CL types
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 11 May 89  06:30:07 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate.lucid.com id AA03361g; Thu, 11 May 89 06:29:07 PDT
Received: by bhopal id AA04911g; Thu, 11 May 89 06:28:56 PDT
Date: Thu, 11 May 89 06:28:56 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8905111328.AA04911@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: chapman%aitg.dec@decwrl.dec.com,
        common-lisp-object-system@sail.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 10 May 89 13:31 EDT <19890510173122.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Random metaclasses for CL types

re: . . . or any other implementation-defined
    class that is no more restrictive than a {\bit built-in class\/}.

I liked your first version better -- I don't remember  88-002R having
a well-ordered scale for "restrictiveness" of metaclasses, so this
phrase (for me) causes much more confusion than it clears up.  But
it's not a big point.

On a related theme -- I was wondering if everyone agrees that the
following is also permitted by "Integrating Types And Classes" section.
An implementation may have a subset of some built-in class being 
implemented by a different meta-class than the rest of the set.  For 
example, in most implementations we probably have:

   (class-name (class-of (find-class 'integer))) --> BUILT-IN-CLASS

But some implementation might also have a FIXNUM class such that:

   (class-name (class-of (find-class 'fixnum))) --> FAST-ARITH-CLASS

where FAST-ARITH-CLASS is not a subclass of BUILT-IN-CLASS.  Of course, 
the FIXNUM class is a still a subclass of INTEGER.

[don't take this example too seriously -- I'm more concerned about
subclasses of the FUNCTION class.]

Assuming that this is legit, then I guess the point you are trying to 
clear up is whether or not it is valid for the subset to be the
whole set -- i.e., some CL type is wholly implemented by a moderately
random metaclass.


-- JonL --

∂12-May-89  1533	Common-Lisp-Object-System-mailer 	Random metaclasses for CL types
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 12 May 89  15:33:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 594309; 12 May 89 16:16:02 EDT
Date: Fri, 12 May 89 16:16 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Random metaclasses for CL types
To: Jon L White <jonl@lucid.com>
cc: chapman%aitg.dec@decwrl.dec.com, common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <8905111328.AA04911@bhopal>
Message-ID: <19890512201615.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 11 May 89 06:28:56 PDT
    From: Jon L White <jonl@lucid.com>

    re: . . . or any other implementation-defined
	class that is no more restrictive than a {\bit built-in class\/}.

    I liked your first version better -- I don't remember  88-002R having
    a well-ordered scale for "restrictiveness" of metaclasses, so this
    phrase (for me) causes much more confusion than it clears up.  But
    it's not a big point.

"restrictive" refers to the immediately following paragraph in 88-002R,
which documents the restrictions of built-in-class.  The idea is that
if a user program assumes it might be a built-in-class, an implementation
can't screw the user over by coming with an implementation-defined class 
that's even worse (can't appear as the cdr of a cons or something).

How about changing "is no more restrictive" to "has no more restrictions"?
Kathy?

    On a related theme -- I was wondering if everyone agrees that the
    following is also permitted by "Integrating Types And Classes" section.
    An implementation may have a subset of some built-in class being 
    implemented by a different meta-class than the rest of the set.

1-16 says additional type specifiers can have classes, so I think
everyone agrees that the built-in classes can have implementation-defined
subclasses.  I assume the metaclass of those can be anything that works.

    For example, in most implementations we probably have:

       (class-name (class-of (find-class 'integer))) --> BUILT-IN-CLASS

    But some implementation might also have a FIXNUM class such that:

       (class-name (class-of (find-class 'fixnum))) --> FAST-ARITH-CLASS

    where FAST-ARITH-CLASS is not a subclass of BUILT-IN-CLASS.  Of course, 
    the FIXNUM class is a still a subclass of INTEGER.

I can't understand why FAST-ARITH-CLASS wouldn't be a subclass of
BUILT-IN-CLASS.  Maybe the example you really meant was

       (class-name (class-of (find-class 'integer))) --> SLOW-ARITH-CLASS
       (class-name (class-of (find-class 'fixnum))) --> FAST-ARITH-CLASS

where SLOW-ARITH-CLASS and FAST-ARITH-CLASS are disjoint subclasses
of BUILT-IN-CLASS?

    [don't take this example too seriously -- I'm more concerned about
    subclasses of the FUNCTION class.]

Or maybe you really meant that 
       (class-name (class-of (find-class 'function))) --> BUILT-IN-CLASS
but
       (class-name (class-of (find-class 'generic-function))) --> FUNCALLABLE-STANDARD-CLASS
and
       (subclassp 'FUNCALLABLE-STANDARD-CLASS 'BUILT-IN-CLASS) --> NIL
which is specified either by 88-002R or the draft metaobject protocol,
I forget which.  Anyway this example shows that you don't have to worry.

∂13-May-89  1811	Common-Lisp-Object-System-mailer 	Random metaclasses for CL types
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 May 89  18:11:24 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA01974g; Sat, 13 May 89 18:10:42 PDT
Received: by bhopal id AA18947g; Sat, 13 May 89 18:10:29 PDT
Date: Sat, 13 May 89 18:10:29 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8905140110.AA18947@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, Gray@DSG.csc.ti.com
Cc: common-lisp-object-system@SAIL.STANFORD.EDU,
        chapman%aitg.dec@decwrl.dec.com
In-Reply-To: David A. Moon's message of Fri, 12 May 89 16:16 EDT <19890512201615.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Random metaclasses for CL types

re: . . .  The idea is that
    if a user program assumes it might be a built-in-class, an implementation
    can't screw the user over by coming with an implementation-defined class 
    that's even worse (can't appear as the cdr of a cons or something).

Maybe a positive way to say this is that such instances must be "first-class"
-- i.e, can be passed as arguments to functions, can be cons'd into list 
structure, can be specialized upon by generic functions, don't crash the
system if you try to print them, etc.   Better to know where the alligator 
*is* than where he isn't.


re: Or maybe you really meant that 
	   (class-name (class-of (find-class 'function))) --> BUILT-IN-CLASS
    but
	   (class-name (class-of (find-class 'generic-function))) --> FUNCALLABLE-STANDARD-CLASS
    and
	   (subclassp 'FUNCALLABLE-STANDARD-CLASS 'BUILT-IN-CLASS) --> NIL
    which is specified either by 88-002R or the draft metaobject protocol,
    I forget which.  Anyway this example shows that you don't have to worry.

Why, yes, as a matter of fact, that's precisely what I was hinting at.

However I don't see any particular consequence of requiring
FUNCALLABLE-STANDARD-CLASS to be a subclass of STANDARD-CLASS rather
than of BUILT-IN-CLASS.  It's certainly possible for one subclass of
STANDARD-CLASS to paint a totally different picture of its instances 
than some other random subclass of STANDARD-CLASS does.

Also, I don't feel strongly that non-FUNCALLABLE-STANDARD-CLASS function 
classes should have a separate name from FUNCTION -- to form a partition 
as you were suggesting in:
    "... where SLOW-ARITH-CLASS and FAST-ARITH-CLASS are disjoint 
     subclasses of BUILT-IN-CLASS?"
[presumably you also meant also that the union of SLOW-ARITH-CLASS and 
FAST-ARITH-CLASS would conver the INTEGER class].  Rather,  I would like 
to see a clear picture as follows, where the dots show metaclass links, 
and the slashes show subclass links:

	      FUNCTION . . . . . . . . . . . . . . . . BUILT-IN-CLASS
	     /        \
	    /          \
	   /            \
	  ??   STANDARD-FUNCTION-OBJECT  . . . . . . . STANDARD-FUNCTION-CLASS
		/                 \
	       /                   \
	      /                     \           GENERIC-FUNCTION
	     /                       \              /
	    /                         \            /
  {PCL's "constructors"}      STANDARD-GENERIC-FUNCTION

The advantage of using the name STANDARD-FUNCTION-CLASS rather than
FUNCALLABLE-STANDARD-CLASS is that it continues the parallels already
established between the nomenclatures of certain other meta objects:

   STANDARD-OBJECT             --  STANDARD-CLASS
   STRUCTURE-OBJECT            --  STRUCTURE-CLASS
   {BUILT-IN-OBJECT}           --  BUILT-IN-CLASS
   {STANDARD-FUNCTION-OBJECT}  --  STANDARD-FUNCTION-CLASS

[The names in {}'s show classes that aren't specified in the standard,
but which people informally talk about using various names].  The ?? 
class under FUNCTION above would be left for implementation-specific 
functions, which don't have the regular structure about them that allows 
easy (perhaps "portable") manipulation of subcomponents.  This is what
STANDARD-FUNCTION-CLASS would represent -- regular, accessible structure
of the functions.  I'd be particularly curious as to how you two Daves 
feel about this.


-- JonL --

∂15-May-89  0907	Common-Lisp-Object-System-mailer 	Random metaclasses for CL types
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 May 89  09:07:06 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA03746g; Mon, 15 May 89 09:04:36 PDT
Received: by challenger id AA08623g; Mon, 15 May 89 09:04:13 PDT
Date: Mon, 15 May 89 09:04:13 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8905151604.AA08623@challenger>
To: jonl@lucid.com
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, Gray@DSG.csc.ti.com,
        common-lisp-object-system@SAIL.STANFORD.EDU,
        chapman%aitg.dec@decwrl.dec.com
In-Reply-To: Jon L White's message of Sat, 13 May 89 18:10:29 PDT <8905140110.AA18947@bhopal>
Subject: Random metaclasses for CL types


   However I don't see any particular consequence of requiring
   FUNCALLABLE-STANDARD-CLASS to be a subclass of STANDARD-CLASS rather
   than of BUILT-IN-CLASS.  It's certainly possible for one subclass of
   STANDARD-CLASS to paint a totally different picture of its instances 
   than some other random subclass of STANDARD-CLASS does.

I coudn't parse that, so excuse me if what I say is totally obvious to you. I
think that funcallable-standard-class shouldn't be a subclass of
built-in-class. That would break the intuitive concept of specializations: the
specialization refines the behavior of its superclass.

   Rather,  I would like 
   to see a clear picture as follows, where the dots show metaclass links, 
   and the slashes show subclass links:

		 FUNCTION . . . . . . . . . . . . . . . . BUILT-IN-CLASS
		/        \
	       /          \
	      /            \
	     ??   STANDARD-FUNCTION-OBJECT  . . . . . . . STANDARD-FUNCTION-CLASS
		   /                 \
		  /                   \
		 /                     \           GENERIC-FUNCTION
		/                       \              /
	       /                         \            /
     {PCL's "constructors"}      STANDARD-GENERIC-FUNCTION

Are you suggesting to add STANDARD-FUNCTION-OBJECT in the standard? I don't
have anything against it. It's just I am not clear on what you want. 

   The advantage of using the name STANDARD-FUNCTION-CLASS rather than
   FUNCALLABLE-STANDARD-CLASS is that it continues the parallels already
   established between the nomenclatures of certain other meta objects:

      STANDARD-OBJECT             --  STANDARD-CLASS
      STRUCTURE-OBJECT            --  STRUCTURE-CLASS
      {BUILT-IN-OBJECT}           --  BUILT-IN-CLASS
      {STANDARD-FUNCTION-OBJECT}  --  STANDARD-FUNCTION-CLASS

The names STANDARD-FUNCTION-OBJECT and STANDARD-FUNCTION-CLASS are misleading.
One can think that Common Lisp functions are standard-function objects. I
agree that the current name FUNCALLABLE-STANDARD-CLASS doesn't fit well in the
nomenclature, but it is strange enough so it does not have the wrong
connotation. 

Patrick.

∂15-May-89  1830	Common-Lisp-Object-System-mailer 	Random metaclasses for CL types
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 May 89  18:30:26 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA04774g; Mon, 15 May 89 18:29:08 PDT
Received: by bhopal id AA24714g; Mon, 15 May 89 18:28:52 PDT
Date: Mon, 15 May 89 18:28:52 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8905160128.AA24714@bhopal>
To: dussud@lucid.com
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, Gray@DSG.csc.ti.com,
        common-lisp-object-system@SAIL.STANFORD.EDU,
        chapman%aitg.dec@decwrl.dec.com
In-Reply-To: Patrick Dussud's message of Mon, 15 May 89 09:04:13 PDT <8905151604.AA08623@challenger>
Subject: Random metaclasses for CL types

re:  I think that funcallable-standard-class shouldn't be a subclass of
     built-in-class. That would break the intuitive concept of 
     specializations: the specialization refines the behavior of its 
     superclass.

My note didn't suggest that FUNCALLABLE-STANDARD-CLASS be a subclass of
BUILT-IN-CLASS -- I only remarked that there is no reason why it _can't_
be a subclass of STANDARD-CLASS.  In the reverse direction -- whether
STANDARD-FUNCTION-OBJECTs can have a metaclass that is a subclass of
BUILT-IN-CLASS -- well this is probably an implementational issue,
isn't it?

But on the other hand, I don't see how the "rule of refinement" applies
here.  Suppose the class B-OBJECT is a "refinement" of A-OBJECT; my
message was to elucidate that this does not imply that that the
metaclass for B-OBJECT must be a subclass of the metaclasss for 
A-OBJECT.  That is, the subclassing relations between metaclasses
are more concerned with _how_ the metaclasses describe the details of
their end-products than with _what_ the shape of each end-product is.



re: The names STANDARD-FUNCTION-OBJECT and STANDARD-FUNCTION-CLASS are 
    misleading.  One can think that Common Lisp functions are 
    standard-function objects. I agree that the current name 
    FUNCALLABLE-STANDARD-CLASS doesn't fit well in the nomenclature, but 
    it is strange enough so it does not have the wrong connotation. 

I don't follow the reasoning here either.  Why would anyone ever think 
that a class named STANDARD-FUNCTION-OBJECT covers Common Lisp (non-
generic) functions?   Does anyone ever jump to the conclusion that Common 
Lisp data types are elements of STANDARD-OBJECT just because of the name?


-- JonL --

∂18-May-89  1214	Common-Lisp-Object-System-mailer 	Random metaclasses for CL types
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 18 May 89  12:12:40 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 597188; 18 May 89 15:06:17 EDT
Date: Thu, 18 May 89 15:06 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Random metaclasses for CL types
To: Jon L White <jonl@lucid.com>
cc: Gray@DSG.csc.ti.com, common-lisp-object-system@SAIL.STANFORD.EDU, chapman%aitg.dec@decwrl.dec.com
In-Reply-To: <8905140110.AA18947@bhopal>
Message-ID: <19890518190611.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sat, 13 May 89 18:10:29 PDT
    From: Jon L White <jonl@lucid.com>

    re: . . .  The idea is that
	if a user program assumes it might be a built-in-class, an implementation
	can't screw the user over by coming with an implementation-defined class 
	that's even worse (can't appear as the cdr of a cons or something).

    Maybe a positive way to say this is that such instances must be "first-class"
    -- i.e, can be passed as arguments to functions, can be cons'd into list 
    structure, can be specialized upon by generic functions, don't crash the
    system if you try to print them, etc.   Better to know where the alligator 
    *is* than where he isn't.

I completely disagree.  I do not want to define this in terms of a possibly
incomplete list of things you can do with these objects.  I want to define it
so that a program that assumes that all specified types are of metaclass
BUILT-IN-CLASS is a conforming program and will work in all implementations
regardless of what the actual metaclass is.  Can we come up with a wording
that clearly and unambiguously expresses that idea?

    re: Or maybe you really meant that 
	       (class-name (class-of (find-class 'function))) --> BUILT-IN-CLASS
	but
	       (class-name (class-of (find-class 'generic-function))) --> FUNCALLABLE-STANDARD-CLASS
	and
	       (subclassp 'FUNCALLABLE-STANDARD-CLASS 'BUILT-IN-CLASS) --> NIL
	which is specified either by 88-002R or the draft metaobject protocol,
	I forget which.  Anyway this example shows that you don't have to worry.

    Why, yes, as a matter of fact, that's precisely what I was hinting at.

    However I don't see any particular consequence of requiring
    FUNCALLABLE-STANDARD-CLASS to be a subclass of STANDARD-CLASS rather
    than of BUILT-IN-CLASS.  It's certainly possible for one subclass of
    STANDARD-CLASS to paint a totally different picture of its instances 
    than some other random subclass of STANDARD-CLASS does.

Since FUNCALLABLE-STANDARD-CLASS is purely chapter 3, I don't want to
digress into discussing it now.
    ....
    This is what
    STANDARD-FUNCTION-CLASS would represent -- regular, accessible structure
    of the functions.  I'd be particularly curious as to how you two Daves 
    feel about this.

FUNCALLABLE-STANDARD-CLASS is a bad name, but STANDARD-FUNCTION-CLASS is
worse.  I'm not sure that name needs to be defined in chapter 3, though;
I think it might suffice to say that the implementation provides 
GENERIC-FUNCTION with an appropriate metaclass without naming that
metaclass, particularly since chapter 3 no longer specifies the action
of the SLOT-VALUE function on any metaobject.  FUNCALLABLE-STANDARD-CLASS
may just be an artifact of the implementation used in PCL.

Now you know how this Dave feels about it.

    ....
    Why would anyone ever think 
    that a class named STANDARD-FUNCTION-OBJECT covers Common Lisp (non-
    generic) functions?   Does anyone ever jump to the conclusion that Common 
    Lisp data types are elements of STANDARD-OBJECT just because of the name?

Yes.  The name STANDARD-OBJECT is definitely a problem for that reason.
It's a bit late in the day to change it, though, and I don't recall ever
hearing a suggested name I liked better, even though this has been
discussed on several occasions in the past.

∂19-May-89  0728	Common-Lisp-Object-System-mailer 	Random metaclasses for CL types
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 May 89  07:28:26 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA24181g; Fri, 19 May 89 07:24:44 PDT
Received: by bhopal id AA04129g; Fri, 19 May 89 07:23:58 PDT
Date: Fri, 19 May 89 07:23:58 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8905191423.AA04129@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: Gray@DSG.csc.ti.com, common-lisp-object-system@SAIL.STANFORD.EDU,
        chapman%aitg.dec@decwrl.dec.com
In-Reply-To: David A. Moon's message of Thu, 18 May 89 15:06 EDT <19890518190611.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Random metaclasses for CL types

re: [The "holy" types of 88-002R, pages 1-16 and 1-17] I want to define it 
    so that a  program that assumes that all specified types are of metaclass 
    BUILT-IN-CLASS is a conforming program and will work in all implementations
    regardless of what the actual metaclass is.  Can we come up with a wording
    that clearly and unambiguously expresses that idea?

Well, foo, this loosely worded specification implies that the metaclasses
of the "holy" types are in fact subclasses of BUILT-IN-CLASS.  And that's
precisely what I thought you were trying to avoid prescribing.

The example discussed in previous mail --  STANDARD-FUNCTION-CLASS (?) --
wasn't shown as a subclass of BUILT-IN-CLASS precisely because Chap 3
requires it to be a direct sublcass of STANDARD-CLASS instead.  I wouldn't
be against changing this and simply saying, quite up-front, that all
implementation-specific metaclasses covering the "holy" types must
be subclasses of BUILT-IN-CLASS (i.e. those which are not of metaclass
STANDARD-CLASS or STRUCTURE-CLASS).

Perhaps we could investigate the possibilities of having a broad enough 
definition for BUILT-IN-CLASS so that your flavor-implemented types could 
be covered?  I don't see much in 88-002R that overly constrains built-in
classes.


re: FUNCALLABLE-STANDARD-CLASS is a bad name, but STANDARD-FUNCTION-CLASS is
    worse.  I'm not sure that name needs to be defined in chapter 3, though;
    I think it might suffice to say that the implementation provides 
    GENERIC-FUNCTION with an appropriate metaclass without naming that
    metaclass, particularly since chapter 3 no longer specifies the action
    of the SLOT-VALUE function on any metaobject.  FUNCALLABLE-STANDARD-CLASS
    may just be an artifact of the implementation used in PCL.

The point of STANDARD-FUNCTION-CLASS is *not* that it is the metaclass of
GENERIC-FUNCTION, but rather of an orthogonal set of functions that have 
"standard" structure.   PCL uses it to make "constructors", which are 
functions but not generic-functions.  You're right that this is probably a
PCL-inspired artifact; but it's not completely senseless.  It's justifiable
in Chap 3 only to the extent that someone else might want to do something
like PCL's constructors.  I'll leave it to Gregor to defend them.  But if
you think it's unlikely that Chap 3 will have a serious impact, then
perhaps it isn't worth discussing yet.


Since no one objected to the subclass links in my earlier mail , I take it 
that the following subclass graph is obvious [regardless of the metaclass 
links]?

                      FUNCTION
                     /   |    \
                    /    |     \
                   /     |      \
                  /      |       \
                 /       |        \
                /        |         \
               /         |          \
   GENERIC-FUNCTION  {OtherFuns}  {STANDARD-FUNCTION}
              \                      /     |    \
               \                    /      |     \
                \                  /       |      \
                 \                /        |       \
                  \              /         |        \
                   \            /          |         \
                    \          /           |          \
             STANDARD-GENERIC-FUNCTION  {Hunoz?}  {PCL-Constructors}



-- JonL --

∂19-May-89  0844	Common-Lisp-Object-System-mailer 	Random metaclasses for CL types
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 May 89  08:43:51 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA24497g; Fri, 19 May 89 08:38:06 PDT
Received: by challenger id AA03510g; Fri, 19 May 89 08:36:55 PDT
Date: Fri, 19 May 89 08:36:55 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8905191536.AA03510@challenger>
To: jonl@lucid.com
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, Gray@DSG.csc.ti.com,
        common-lisp-object-system@SAIL.STANFORD.EDU,
        chapman%aitg.dec@decwrl.dec.com
In-Reply-To: Jon L White's message of Fri, 19 May 89 07:23:58 PDT <8905191423.AA04129@bhopal>
Subject: Random metaclasses for CL types

   Date: Fri, 19 May 89 07:23:58 PDT
   From: Jon L White <jonl>

   re: [The "holy" types of 88-002R, pages 1-16 and 1-17] I want to define it 
       so that a  program that assumes that all specified types are of metaclass 
       BUILT-IN-CLASS is a conforming program and will work in all implementations
       regardless of what the actual metaclass is.  Can we come up with a wording
       that clearly and unambiguously expresses that idea?

   Well, foo, this loosely worded specification implies that the metaclasses
   of the "holy" types are in fact subclasses of BUILT-IN-CLASS.  And that's
   precisely what I thought you were trying to avoid prescribing.

I disagree. It means that the external protocol supported by the
implementation dependent metaclass needs to cover the capabilities
BUILT-IN-CLASS. This can be achieved independently of the taxinomy of
metaclasses. I don't think we want the users to rely on the taxinomy of
metaclasses at this point. 

   The example discussed in previous mail --  STANDARD-FUNCTION-CLASS (?) --
   wasn't shown as a subclass of BUILT-IN-CLASS precisely because Chap 3
   requires it to be a direct sublcass of STANDARD-CLASS instead.  I wouldn't
   be against changing this and simply saying, quite up-front, that all
   implementation-specific metaclasses covering the "holy" types must
   be subclasses of BUILT-IN-CLASS (i.e. those which are not of metaclass
   STANDARD-CLASS or STRUCTURE-CLASS).
I would be against it. 

   Perhaps we could investigate the possibilities of having a broad enough 
   definition for BUILT-IN-CLASS so that your flavor-implemented types could 
   be covered?  I don't see much in 88-002R that overly constrains built-in
   classes.

I would be against having Flavor's metaclass be a subclass of BUILT-IN-CLASS.
Flavors are much closer to STANDARD-CLASS than they are from BUILT-IN-CLASS. 

   Since no one objected to the subclass links in my earlier mail , I take it 
   that the following subclass graph is obvious [regardless of the metaclass 
   links]?

			 FUNCTION
			/   |    \
		       /    |     \
		      /     |      \
		     /      |       \
		    /       |        \
		   /        |         \
		  /         |          \
      GENERIC-FUNCTION  {OtherFuns}  {STANDARD-FUNCTION}
		 \                      /     |    \
		  \                    /      |     \
		   \                  /       |      \
		    \                /        |       \
		     \              /         |        \
		      \            /          |         \
		       \          /           |          \
		STANDARD-GENERIC-FUNCTION  {Hunoz?}  {PCL-Constructors}


As far as the standard is concrned, we are interested only in:


                      function 
                         |
                  generic function
                         |
              standard-generic-function

and that's OK with me. 

∂22-May-89  1838	Common-Lisp-Object-System-mailer 	Random metaclasses for CL types
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 22 May 89  18:38:32 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA03791g; Fri, 19 May 89 21:09:03 PDT
Received: by bhopal id AA05273g; Fri, 19 May 89 21:07:17 PDT
Date: Fri, 19 May 89 21:07:17 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8905200407.AA05273@bhopal>
To: dussud@lucid.com, Gray@DSG.csc.ti.com
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM,
        common-lisp-object-system@SAIL.STANFORD.EDU,
        chapman%aitg.dec@decwrl.dec.com
In-Reply-To: Patrick Dussud's message of Fri, 19 May 89 08:36:55 PDT <8905191536.AA03510@challenger>
Subject: Random metaclasses for CL types

re: . . . It means that the external protocol supported by the
    implementation dependent metaclass needs to cover the capabilities
    BUILT-IN-CLASS. This can be achieved independently of the taxinomy of
    metaclasses. I don't think we want the users to rely on the taxinomy of
    metaclasses at this point. 

On the first two  points, we are quite in agreement.  But the taxonomy 
*is* user-visible; and for any flavor-implemented "holy" type, it wouldn't 
satisfy all the BUILT-IN-CLASS capabilities unless it had a similar
hierarchy.  Unless Moon wants to be more explicit on what he wants
out of portability of BUILT-IN-CLASS, I would have to assume that it
includes taxonomy.

Now, as Gray says, flavor-implemented classes **in general** have some 
structural features that BUILT-IN-CLASS types don't have.  But this isn't 
an argument against using a particlar one to support a BUILT-IN-CLASS 
element, because a sufficiently-restrictive set of methods on that
flavor-implemented class will strip it of its apparent slots.   On the
other hand, why shouldn't some limited set of BUILT-IN-CLASS elements
respond to, say, SLOT-VALUE?  The question is, How do you view the
limitations of BUILT-IN-CLASS -- as merely a limit on what is guaranteed
to be available, or as an absolute prohibition on what shall not be
available?

If anything, the trouble we seem to be having in pinpointing the problem 
is that BUILT-IN-CLASS is a purely synthetic concept that agglomerates 
numerous totally-independent structures [e.g., how is FLOAT, say, related
to SYMBOL?].  The only thing that relates them together -- regardless of 
their inner details (e.g "standard" slots or not) is their opacity in
the class system.  I.e., you can specialize on their type, but you can't 
generally do any other structural operations such as "make an instance", 
expose a "slot", etc.


Now, in the FUNCTION domain, it's true that the standard so far has 
only spoken about:

                      function 
                         |
                  generic function
                         |
              standard-generic-function

Except for Chap 3, it hasn't even spoken about what relationship,
*** if any **, there is between the metaclass of FUNCTION and that of 
STANDARD-GENERIC-FUNCTION.  Have we finally agreed even if FUNCTION 
is implemented as BUILT-IN-CLASS, this places no particluar constraint 
on what the class of STANDARD-GENERIC-FUNCTION is?  including whether or 
not it is BUILT-IN-CLASS or STANDARD-CLASS?

What I was trying to illustrate with the bifurcated tree:

                      function 
                       /     \
                     /         \
                   /             \
                 /                 \
          generic-function    standard-function
                 \                 /
                   \             /
                     \         /
                       \     /
              standard-generic-function


is that we could have somewhat random metaclasses for GENERIC-FUNCTION 
and STANDARD-FUNCTION; hence, even though STANDARD-GENERIC-FUNCTION is
a subclass of both, it could have a totally different metaclass.  The 
constraints needed for metaclass "compatibility" don't seem to be
encompassed by subclass relationships.

In fact, GENERIC-FUNCTION seems almost worthless.  What might show
a truer picture is a GENERIC mixin, which when combined with
STANDARD-FUNCTION yields STANDARD-GENERIC-FUNCTION.  But I must confess
that the GENERIC mixin probably wouldn't be of use anywhere else.


One last point -- as Gray mentions, there isn't an obvious meaning
for STANDARD-FUNCTION.  I've abstracted that from what Gregor calls
"funcallable instances" in PCL.  The trouble with the latter term
is that *all* functions are "funcallable instances" in some sense,
in that you can FUNCALL them.  The crucial difference is in a little
protocol puts two "slots" into an othewise vanilla funtion; this is
what makes them "standard" in my view.  

Mostly I'm raising these issues about subclasses and metaclasse of  
FUNCTION as a Chap 3 point, since it is there where substructure of 
FUNCTION can be exposed.  And I think it is a good thing to do so,
since expert Lisp users have *always* wanted to know the structure
of functions and tinker with them in some superficial but tremendously
useful way.  PCL's "fins" are a prime example of this, and I don't 
suspect that they'll be the last.



-- JonL --

∂23-May-89  1047	Common-Lisp-Object-System-mailer 	re: Random metaclasses for CL types 
To:   jonl@LUCID.COM, dussud@LUCID.COM, Gray@DSG.CSC.TI.COM
CC:   Moon@STONY-BROOK.SCRC.SYMBOLICS.COM,
      common-lisp-object-system@SAIL.Stanford.EDU,
      chapman%aitg.dec@decwrl.dec.com    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

[In reply to message from jonl@lucid.com sent Fri, 19 May 89 21:07:17 PDT.]

I haven't been following this debate too closely, but on discussing
it with Dussud and Jonl, I am not sure why the metaclass taxonomy cannot
look like this:

		class
                  |
       ---------------------------------------------------
       |               |                 |               |
built-in-class basic-flavor-class structure-class standard-class
       |               |
       |     --------------------------------
       |     |                              |
flavor-implemented-built-in-class ordinary-flavor-class

where basic-flavor has just enough structure to support the
flavor-implemented builtins, and just enough ontology to represent flavors
(as usual, I don't endorse these names). PATHNAME and STREAM are instances
of flavor-implemented-built-in-class and user-defined or other flavors are
instances of ordinary-flavor-class.

The other alternative is to flush built-in-class and let imlementations 
decide their own metaclass hierarchy. Maybe that way we would see some
implementors doing some innovative design.

			-rpg-

∂24-May-89  0805	Common-Lisp-Object-System-mailer 	Random metaclasses for CL types     
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 24 May 89  08:05:08 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA06665g; Wed, 24 May 89 08:02:07 PDT
Received: by challenger id AA02782g; Wed, 24 May 89 08:01:27 PDT
Date: Wed, 24 May 89 08:01:27 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8905241501.AA02782@challenger>
To: RPG@SAIL.Stanford.EDU
Cc: jonl@lucid.com, Gray@DSG.CSC.TI.COM, Moon@STONY-BROOK.SCRC.SYMBOLICS.COM,
        common-lisp-object-system@SAIL.Stanford.EDU,
        chapman%aitg.dec@decwrl.dec.com
In-Reply-To: Dick Gabriel's message of 23 May 89  1047 PDT <11c9OI@SAIL.Stanford.EDU>
Subject: Random metaclasses for CL types 

   Date: 23 May 89  1047 PDT
   From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

   [In reply to message from jonl@lucid.com sent Fri, 19 May 89 21:07:17 PDT.]

   I haven't been following this debate too closely, but on discussing
   it with Dussud and Jonl, I am not sure why the metaclass taxonomy cannot
   look like this:

		   class
		     |
	  ---------------------------------------------------
	  |               |                 |               |
   built-in-class basic-flavor-class structure-class standard-class
	  |               |
	  |     --------------------------------
	  |     |                              |
   flavor-implemented-built-in-class ordinary-flavor-class

   where basic-flavor has just enough structure to support the
   flavor-implemented builtins, and just enough ontology to represent flavors
   (as usual, I don't endorse these names). PATHNAME and STREAM are instances
   of flavor-implemented-built-in-class and user-defined or other flavors are
   instances of ordinary-flavor-class.

I think this would work. There are some issues that need to be ironed
out: Can the implementation allow subclasses of
flavor-implemented-built-in-class? If yes, then does 
flavor-implemented-built-in-class needs to expose its slots? or merely allow
subclasses to have slots and treat the superclasses like blackboxes?


   The other alternative is to flush built-in-class and let imlementations 
   decide their own metaclass hierarchy. Maybe that way we would see some
   implementors doing some innovative design.
I prefer this one, just because it leaves more options open to the
implementation. 

Patrick.

∂24-May-89  0806	Common-Lisp-Object-System-mailer 	Random metaclasses for CL types     
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 24 May 89  08:06:45 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA06671g; Wed, 24 May 89 08:03:38 PDT
Received: by bhopal id AA13037g; Wed, 24 May 89 08:03:20 PDT
Date: Wed, 24 May 89 08:03:20 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8905241503.AA13037@bhopal>
To: RPG@SAIL.Stanford.EDU
Cc: dussud@lucid.com, Gray@DSG.CSC.TI.COM, Moon@STONY-BROOK.SCRC.SYMBOLICS.COM,
        common-lisp-object-system@SAIL.Stanford.EDU,
        chapman%aitg.dec@decwrl.dec.com
In-Reply-To: Dick Gabriel's message of 23 May 89  1047 PDT <11c9OI@SAIL.Stanford.EDU>
Subject: Random metaclasses for CL types 

re: The other alternative is to flush built-in-class and let imlementations 
    decide their own metaclass hierarchy. Maybe that way we would see some
    implementors doing some innovative design.

Before doing that, we should reflect on why BUILT-IN-CLASS is in the
standard, and why 88-002R specifies that the "holy" Common Lisp types
should be of metaclass either BUILT-IN-CLASS, STRUCTURE-CLASS, or
STANDARD-CLASS.  After all, our present problem is determining how to 
say the intent that Moon wants to add to 88-002R, page 1-15, about 
"restrictions" on implementation-dependent metaclasses.

After talking it over with you (RPG), I think we have been overly
concerned  with the aphorism "The Metaclass implements the structure
of the instances".  In fact, this just isn't true of all Metaclasses;
the fact that it is a concise description of the structure of
STANDARD-CLASS has fooled us into thinking it to be more widely true.

I see BUILT-IN-CLASS as a series of "fronts" for objects that exist
in a Common Lisp implementation's extended type hiearchy.  The structure
of these "instances" __is not__ implemented by any facility whatsoever
in the Common Lisp Object System, but by all of "the ususal suspects",
such as microcode, machine-language assembly code, Lisp functions, 
compiler tricks, etc.  The sole raison d'etre of BUILT-IN-CLASS is so 
that generic functions may discriminate on these "holy" types (but 
probably not on lots of other types about which no one cares).

Viewed in this light, there is no reason at all why the flavor-implemented
types shouldn't simply be represented by a place-holder class that is either
an instance of BUILT-IN-CLASS, or some implementation-dependent subclass
thereof.

The question should arise: Why not require all "holy" types to be of
metaclass BUILT-IN-CLASS (or implementation-dependent subclass thereof)?
The answer comes from the fact that CLOS _does not_ provide for true
information/structure hiding such as, say, Common Objects has.  Thus if 
some implementation should support a "holy" type by using a STANDARD-CLASS,
this would be visible to the end user.  Furthermore, any attempt to apply 
some restrictions to such a metaclass (such as by providing overrides for 
SLOT-VALUE-ABUSING-CLASS to make it look to the user like these classes 
don't have slots) would also apply to the implementor, thereby totally 
nullifying the advantage or using a STANDARD-CLASS in the first place.

Thus, because of the openess of CLOS, STRUCTURE-CLASS and STANDARD-CLASS
must be allowed explicitly; but _any_ other implementational technique
needs only BUILT-IN-CLASS as a "front", regardless of whether it is by
microcode, by flavors classes, or by YetAnotherObjectSystem.


-- JonL --

∂24-May-89  0854	Common-Lisp-Object-System-mailer 	re: Random metaclasses for CL types 
To:   jonl@LUCID.COM, RPG@SAIL.Stanford.EDU
CC:   dussud@LUCID.COM, Gray@DSG.CSC.TI.COM, Moon@STONY-BROOK.SCRC.SYMBOLICS.COM,
      common-lisp-object-system@SAIL.Stanford.EDU,
      chapman%aitg.dec@decwrl.dec.com 
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

[In reply to message from jonl@lucid.com sent Wed, 24 May 89 08:03:20 PDT.]

I think the aphorism is ``the metaclass determines the representation of
instances of its instances.'' This is because MAKE-INSTANCE as a function
depends on the metaclass. So, any operation whose operation takes a class
depends on the metaclass. Representation creation is the most important or
visible of those operations. (Another use is to reify other aspects of an
object, such as the interpreter to use to execute code associated with a
class. This is sort of what Maes (1988) and Gabriel (1980) do with
metaobjects.)

Of course, there is nothing to prevent one from having MAKE-INSTANCE
select a metaclass to use that corresponds to a subclass of the original
class.  MAKE-ARRAY is such a pseudo-constructor. BUILT-IN-CLASS seems to
me to be a metaclass for things that you cannot MAKE-INSTANCE of. In that
sense it might represent the metaclass for things with no metaclass at all.

I think this is consistent with what you're saying.

One reason to flush BUILT-IN-CLASS is to allow implementations to experiment
with real metaclasses for Common Lisp types. Possibly such a system would be
only of educational interest.

			-rpg-

∂24-May-89  1115	Common-Lisp-Object-System-mailer 	re: Random metaclasses for CL types 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 24 May 89  11:14:39 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 600026; 24 May 89 13:43:12 EDT
Date: Wed, 24 May 89 13:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: re: Random metaclasses for CL types 
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>, Patrick Dussud <dussud@lucid.com>,
    Jon L White <jonl@lucid.com>
cc: Gray@DSG.CSC.TI.COM, common-lisp-object-system@SAIL.Stanford.EDU, chapman%aitg.dec@decwrl.dec.com
In-Reply-To: <11c9OI@SAIL.Stanford.EDU>,
             <8905241501.AA02782@challenger>,
             <8905241503.AA13037@bhopal>,
             <11cWdx@SAIL.Stanford.EDU>
Message-ID: <19890524174658.5.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>

I wish we could bring this conversation back down to earth.  All I want
to know is what one-line change to make to the draft ANSI Common Lisp
spec where it says what a conforming program can assume about the
behavior of objects of the built-in types.

∂24-May-89  1144	Common-Lisp-Object-System-mailer 	re: Random metaclasses for CL types 
To:   Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, RPG@SAIL.Stanford.EDU,
      dussud@LUCID.COM, jonl@LUCID.COM
CC:   Gray@DSG.CSC.TI.COM,
      common-lisp-object-system@SAIL.Stanford.EDU,
      chapman%aitg.dec@decwrl.dec.com    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

[In reply to message from Moon@STONY-BROOK.SCRC.Symbolics.COM sent Wed, 24 May 89 13:46 EDT.]

Gabriel to Earth. Now hear this. My suggestion is to delete the
following paragraph from the specification:

``Each class that corresponds to a predefined Common Lisp type specifier
can be implemented in one of three ways, at the discretion of each
implementation.  It can be a {\bit standard class\/} (of the kind
defined by {\bf defclass}), a {\bit structure class\/} (defined
by {\bf defstruct}), or a {\bit built-in class\/} (implemented in
a special, non-extensible way).''

And change this one:

``It is possible to determine whether a class is a built-in class by
checking the metaclass.  A standard class is an instance of {\bf
standard-class}, a built-in class is an instance of {\bf
built-in-class}, and a structure class is an instance of {\bf
structure-class}.''

to this:

``A standard class is an instance of {\bf standard-class} and a structure
class is an instance of {\bf structure-class}.''

			-rpg-

∂24-May-89  1730	Common-Lisp-Object-System-mailer 	re: Random metaclasses for CL types 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 24 May 89  17:18:25 PDT
Received: by ti.com id AA12879; Wed, 24 May 89 19:18:41 CDT
Received: from dsg by tilde id AA00396; Wed, 24 May 89 19:07:09 CDT
Received: From Kelvin By dsg Via TCP With SMTP; Wed, 24 May 89  16:22:56 CDT
Message-Id: <2821036952-6570488@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 24 May 89  16:22:32 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Cc: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, dussud@LUCID.COM, jonl@LUCID.COM,
        common-lisp-object-system@SAIL.Stanford.EDU
Subject: re: Random metaclasses for CL types 
In-Reply-To: Msg of 24 May 89  1144 PDT from Dick Gabriel <RPG@SAIL.Stanford.EDU>

> Gabriel to Earth. Now hear this. My suggestion is to delete the
> following paragraph from the specification:
...

In other, words, delete the use of BUILT-IN-CLASS?  I don't think that's a
good idea, because BUILT-IN-CLASS does serve a useful purpose:  it serves
notice that there may exist some classes for which MAKE-INSTANCE and
SLOT-VALUE are not legal, and it provides a way to test whether a given
class has those restrictions.  Thus, while the result of, for example,

  (CLASS-OF (FIND-CLASS 'READTABLE))

should be permitted to be implementation-dependent, it should be
meaningful for portable code to test for

  (TYPEP (FIND-CLASS 'READTABLE) 'BUILT-IN-CLASS)

in order to find out if READTABLEs can have slots in the current
implementation.

∂24-May-89  1730	Common-Lisp-Object-System-mailer 	re: Random metaclasses for CL types 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 24 May 89  17:18:44 PDT
Received: by ti.com id AA12886; Wed, 24 May 89 19:18:47 CDT
Received: from dsg by tilde id AA00406; Wed, 24 May 89 19:07:26 CDT
Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Wed, 24 May 89  16:39:54 CDT
Message-Id: <2821038061-6637127@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 24 May 89  16:41:01 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Dick Gabriel <RPG@SAIL.Stanford.EDU>, Patrick Dussud <dussud@lucid.com>,
        Jon L White <jonl@lucid.com>,
        common-lisp-object-system@SAIL.Stanford.EDU
Subject: re: Random metaclasses for CL types 
In-Reply-To: Msg of Wed, 24 May 89 13:46 EDT from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

> I wish we could bring this conversation back down to earth.  All I want
> to know is what one-line change to make to the draft ANSI Common Lisp
> spec where it says what a conforming program can assume about the
> behavior of objects of the built-in types.

I thought your proposed wording of May 10 was sufficient:

  Each class that corresponds to a predefined Common Lisp type specifier
  can be implemented in one of four ways, at the discretion of each
  implementation.  It can be a {\bit standard class\/} (of the kind
  defined by {\bf defclass}), a {\bit structure class\/} (defined
  by {\bf defstruct}), a {\bit built-in class\/} (implemented in
  a special, non-extensible way), or any other implementation-defined
  class that is no more restrictive than a {\bit built-in class\/}.

I think that the question about what "no more restrictive" means is not a
problem when this paragraph is viewed together with the paragraph that
follows it in the draft.

I'm a little concerned, though, about the following paragraph:

  It is possible to determine whether a class is a built-in class by
  checking the metaclass.  A standard class is an instance of {\bf
  standard-class}, a built-in class is an instance of {\bf
  built-in-class}, and a structure class is an instance of {\bf
  structure-class}.

I wouldn't want this to be interpreted in a way that would rule out
subclasses of BUILT-IN-CLASS.  Suppose it said:

  It is possible to determine whether a class is a built-in class by
  checking the metaclass.  A standard class is one for which (TYPEP
  class 'STANDARD-CLASS) is true, a built-in class is one for which
  (TYPEP class 'BUILT-IN-CLASS) is true, and a structure class is one
  for which (TYPEP class 'STRUCTURE-CLASS) is true.

Also, I just remembered that I don't think that the class CLASS is
mentioned prior to chapter 3.  It would be helpful for the standard to
specify that BUILT-IN-CLASS, STANDARD-CLASS, STRUCTURE-CLASS, and any
other implementation-defined metaclasses are all subclasses of CLASS.
Probably this belongs on page 1-33.

∂24-May-89  1730	Common-Lisp-Object-System-mailer 	Re: Random metaclasses for CL types 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 24 May 89  17:19:32 PDT
Received: by ti.com id AA12894; Wed, 24 May 89 19:18:59 CDT
Received: from dsg by tilde id AA00434; Wed, 24 May 89 19:07:55 CDT
Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Wed, 24 May 89  17:34:46 CDT
Message-Id: <2821041333-6833702@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 24 May 89  17:35:33 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@lucid.com>
Cc: dussud@lucid.com, Moon@STONY-BROOK.SCRC.Symbolics.COM,
        common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Re: Random metaclasses for CL types
In-Reply-To: Msg of Fri, 19 May 89 21:07:17 PDT from Jon L White <jonl@lucid.com>

> Except for Chap 3, it hasn't even spoken about what relationship,
> *** if any **, there is between the metaclass of FUNCTION and that of 
> STANDARD-GENERIC-FUNCTION.  Have we finally agreed even if FUNCTION 
> is implemented as BUILT-IN-CLASS, this places no particluar constraint 
> on what the class of STANDARD-GENERIC-FUNCTION is?  including whether or 
> not it is BUILT-IN-CLASS or STANDARD-CLASS?

I would say:
  (TYPEP (FIND-CLASS 'FUNCTION) 'BUILT-IN-CLASS) => <implementation-dependent>
  (TYPEP (FIND-CLASS 'STANDARD-GENERIC-FUNCTION) 'BUILT-IN-CLASS) => NIL  
  (TYPEP (FIND-CLASS 'STANDARD-GENERIC-FUNCTION) 'STANDARD-CLASS) => T

because if STANDARD-GENERIC-FUNCTION were a BUILT-IN-CLASS, then users
would not be able to define subclasses of it and those subclasses
couldn't define slots.

> What I was trying to illustrate with the bifurcated tree:
> 
>                       function 
>                        /     \
>                      /         \
>                    /             \
>                  /                 \
>           generic-function    standard-function
>                  \                 /
>                    \             /
>                      \         /
>                        \     /
>               standard-generic-function
> 
> 
> is that we could have somewhat random metaclasses for GENERIC-FUNCTION 
> and STANDARD-FUNCTION; hence, even though STANDARD-GENERIC-FUNCTION is
> a subclass of both, it could have a totally different metaclass.  The 
> constraints needed for metaclass "compatibility" don't seem to be
> encompassed by subclass relationships.

OK; the real issue is that if users are to be permitted to define
subclasses of GENERIC-FUNCTION or STANDARD-FUNCTION, then they just need
to know what to use for the :METACLASS option for their class in order
for the inheritance to be permitted.

> In fact, GENERIC-FUNCTION seems almost worthless.  What might show
> a truer picture is a GENERIC mixin, which when combined with
> STANDARD-FUNCTION yields STANDARD-GENERIC-FUNCTION.  But I must confess
> that the GENERIC mixin probably wouldn't be of use anywhere else.

I don't see the difference.  Isn't GENERIC-FUNCTION already understood
to be a class that is not directly instantiated?

∂24-May-89  1730	Common-Lisp-Object-System-mailer 	Re: Random metaclasses for CL types 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 24 May 89  17:19:22 PDT
Received: by ti.com id AA12901; Wed, 24 May 89 19:19:06 CDT
Received: from dsg by tilde id AA00499; Wed, 24 May 89 19:08:56 CDT
Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Wed, 24 May 89  18:34:00 CDT
Message-Id: <2821044883-7046991@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 24 May 89  18:34:43 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@lucid.com>
Cc: RPG@SAIL.Stanford.EDU, dussud@lucid.com,
        Moon@STONY-BROOK.SCRC.SYMBOLICS.COM,
        common-lisp-object-system@SAIL.Stanford.EDU
Subject: Re: Random metaclasses for CL types 
In-Reply-To: Msg of Wed, 24 May 89 08:03:20 PDT from Jon L White <jonl@lucid.com>

> I see BUILT-IN-CLASS as a series of "fronts" for objects that exist
> in a Common Lisp implementation's extended type hiearchy.
...
> Viewed in this light, there is no reason at all why the flavor-implemented
> types shouldn't simply be represented by a place-holder class that is either
> an instance of BUILT-IN-CLASS, or some implementation-dependent subclass
> thereof.
> 
> The question should arise: Why not require all "holy" types to be of
> metaclass BUILT-IN-CLASS (or implementation-dependent subclass thereof)?
> The answer comes from the fact that CLOS _does not_ provide for true
> information/structure hiding such as, say, Common Objects has.  Thus if 
> some implementation should support a "holy" type by using a STANDARD-CLASS,
> this would be visible to the end user.  Furthermore, any attempt to apply 
> some restrictions to such a metaclass (such as by providing overrides for 
> SLOT-VALUE-ABUSING-CLASS to make it look to the user like these classes 
> don't have slots) would also apply to the implementor, thereby totally 
> nullifying the advantage or using a STANDARD-CLASS in the first place.
> 
> Thus, because of the openess of CLOS, STRUCTURE-CLASS and STANDARD-CLASS
> must be allowed explicitly; but _any_ other implementational technique
> needs only BUILT-IN-CLASS as a "front", regardless of whether it is by
> microcode, by flavors classes, or by YetAnotherObjectSystem.

I don't see why flavor classes are any different from standard classes
in this regard.  Our implementation provides for writing CLOS methods
that specialize on flavors and use SLOT-VALUE to access their instance
variables.  True, flavors does have another way of writing methods that
can be used instead, but that wouldn't necessarily be true of all
implementation-defined metaclasses.

If you want to expose the slots as an implementation extension, fine, I
think that should be permitted.  If you want to hide them, I think that
can still be done with a standard class.  (Remember, we're talking about
an implementation here, not portable CLOS code.)  For example:

(defclass hidden-class (standard-class) 
   ((visible-class :accessor visible-class)))

(defmethod validate-superclass ((class hidden-class) (super standard-class)) t)

(defclass internal-pathname (standard-object) ( ... )
  (:metaclass hidden-class))

; [implementation magic equivalent to:]
(defclass pathname (internal-pathname) () (:metaclass built-in-class))

(setf (visible-class (find-class 'internal-pathname))
      (find-class 'pathname))

(defmethod initialize-instance :after ((instance hidden-class) &rest ignore)
  ; [implementation magic equivalent to:]
  (setf (class-of instance)
	(visible-class (class-of instance))))

Then the class PATHNAME appears opaque to users, but the system can use
methods on INTERNAL-PATHNAME.  SLOT-VALUE would work in those methods
because they expect an INTERNAL-PATHNAME, which is a STANDARD-CLASS.
There would be an inconsistency in that a non-optimized call to
SLOT-VALUE would not work, but the system programmers who would be
affected by that should be able to understand that and work around it.
I don't think that this technique is much different from what would be
needed to create a built-in "front class" for an internal flavor class.

∂24-May-89  1829	Common-Lisp-Object-System-mailer 	Re: Random metaclasses for CL types 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 24 May 89  18:29:51 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 24 MAY 89 18:28:00 PDT
Date: Wed, 24 May 89 18:27 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Random metaclasses for CL types 
To: Jon L White <jonl@lucid.com>
cc: RPG@SAIL.Stanford.EDU, dussud@lucid.com, Gray@DSG.CSC.TI.COM,
 Moon@STONY-BROOK.SCRC.SYMBOLICS.COM,
 common-lisp-object-system@SAIL.Stanford.EDU,
 chapman%aitg.dec@decwrl.dec.com
Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest
In-Reply-To: <8905241503.AA13037@bhopal>
Message-ID: <19890525012747.4.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no

I am working on it now, and hope to send out a message about this all
tomorrow.  I think the power is off in this building Friday.
-------

∂24-May-89  1901	Common-Lisp-Object-System-mailer 	re: Random metaclasses for CL types 
To:   Gray@DSG.CSC.TI.COM, RPG@SAIL.Stanford.EDU
CC:   Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, dussud@LUCID.COM, jonl@LUCID.COM,
      common-lisp-object-system@SAIL.Stanford.EDU 
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

[In reply to message from Gray@DSG.csc.ti.com sent Wed, 24 May 89 16:22:32 CDT.]

I actually made a mistake. I meant to also delete the requirement of the
existence of BUILT-IN-CLASS as well, but not the concept of built-in
class.  However, I'm not certain that this is the right way to address
what I think is the real concern, which is that it's possibly the
restrictions on built-in classes that we might wish to loosen. In the
following paragraph we state that errors are signaled:

``A built-in class is one whose instances have restricted capabilities or
special representations.  Attempting to use {\bf defclass} to define 
subclasses of a built-in class signals an error.  Calling {\bf
make-instance} to create an instance of a built-in class signals an error.
Calling {\bf slot-value} on an instance of a built-in class signals an
error.  Redefining a built-in class or using {\bf change-class} to change
the class of an instance to or from a built-in class signals an error.
However, built-in classes can be used as parameter specializers in
methods.''

I think the real concern is that some implementations might wish to allow
even the holy types to respond to these protocols. I think we don't want
to prevent it. Maybe this is a point at which we wish to consider such
things as ``implementations are free to extend the \OS\ to allow {\bf
defclass} to define subclasses of a built-in class,'' and the same
for the other protocols.

In trying to translate Moon's proposal into something I can more
easily understand, I came up with this; is it a fair copy?

  Each class that corresponds to a predefined Common Lisp type specifier
  can be implemented in one of four ways, at the discretion of each
  implementation.  It can be a {\bit standard class\/} (of the kind
  defined by {\bf defclass}), a {\bit structure class\/} (defined
  by {\bf defstruct}), a {\bit built-in class\/} (implemented in
  a special, non-extensible way), or any other implementation-defined
  class that allows it to be used as a parameter specializer in a method.

In Gray's example of the use of BUILT-IN-CLASS, I can't imagine that someone
writing a portable program couldn't devise a more portable solution to the
problem, especially if there is alternative that is used if the

  (TYPEP (FIND-CLASS 'READTABLE) 'BUILT-IN-CLASS)

returns T.

Are you thinking of a portable programming environment?

			-rpg-

∂24-May-89  2131	Common-Lisp-Object-System-mailer 	Re: Random metaclasses for CL types 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 24 May 89  21:31:24 PDT
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
	id AA09723; Wed, 24 May 89 21:31:30 PDT
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.1)
	id AA06439; Wed, 24 May 89 21:30:05 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA05656; Wed, 24 May 89 21:31:35 PDT
Message-Id: <8905250431.AA05656@suntana.sun.com>
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: Dick Gabriel <RPG@SAIL.Stanford.EDU>, Moon@STONY-BROOK.SCRC.SYMBOLICS.COM,
        dussud@LUCID.COM, jonl@LUCID.COM,
        common-lisp-object-system@SAIL.Stanford.EDU
Subject: Re: Random metaclasses for CL types 
In-Reply-To: Your message of Wed, 24 May 89 16:22:32 -0500.
             <2821036952-6570488@Kelvin> 
Date: Wed, 24 May 89 21:31:32 PDT
From: kempf@Sun.COM

>> Gabriel to Earth. Now hear this. My suggestion is to delete the
>> following paragraph from the specification:
>...
>
>In other, words, delete the use of BUILT-IN-CLASS?  I don't think that's a
>good idea, because BUILT-IN-CLASS does serve a useful purpose:  it serves

I agree.

		jak

∂25-May-89  0907	Common-Lisp-Object-System-mailer 	Random metaclasses for CL types     
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 May 89  09:07:42 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA05703g; Thu, 25 May 89 09:06:31 PDT
Received: by bhopal id AA15693g; Thu, 25 May 89 09:04:42 PDT
Date: Thu, 25 May 89 09:04:42 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8905251604.AA15693@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: RPG@SAIL.Stanford.EDU, dussud@lucid.com, Gray@DSG.CSC.TI.COM,
        common-lisp-object-system@SAIL.Stanford.EDU,
        chapman%aitg.dec@decwrl.dec.com
In-Reply-To: David A. Moon's message of Wed, 24 May 89 13:46 EDT <19890524174658.5.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Subject: Random metaclasses for CL types 

re: . . .  what one-line change to make to the draft ANSI Common Lisp
    spec where it says what a conforming program can assume about the
    behavior of objects of the built-in types.

I fear it won't be one-line change.  Would you be happy if we could all
agree to a two-dozen line change?

If so, then I think I could go for Gabriel's plan to flush BUILT-IN-CLASS
as a required class, providing that we add an implementation-revealing
defconstant -- say, BUILT-IN-CLASSES  -- which is just a list of all the 
classes supporting "built in" types.  The "holy" types of pages 1-16 and 
1-17 would be required to have representatives  on this list, and an 
implementation would be free to add as many others as necessary to 
provide reasonable support so that CLASS-OF is a total function.

As I've previously argued, the only utility of BUILT-IN-CLASS is taxonomic;
and this capability can just as easily and naturally be provided by a list 
of all such classes.  [By the bye, "holy" because they are set apart for a 
transcendent purpose.]  A list is better than a predicate BUILT-IN-CLASS-P
since one might never know to look for the very implementation-specific
classes.


Secondly, I still tend to think that the notion of "restriction" isn't
clear enough.  One man thinks it means no use of SLOT-VALUE; another
sees it as no MAKE-INSTANCE; yet a third is concerned that it might 
even mean "can't appear in the cdr of a list".  By letting all the
"holy" types have metaclasses of unspecified nature (but of course
every metaclass itself is a very standard object), implementations
are free to let "built-in" classes respond to any protocol whatsoever. 
However, the standard will not specify any CLOS operations on the "holy"
types, so that portable code can depend only on existence of such
classes (for use as specializer names).

Thus I would also agree with Gabriel that we could get along nicely 
without specifying any restrictions on built-in classes.  I'm not
happy with the idea of end-users defining subclasses of INTEGER and
VECTOR, but . . . well, this really is an implementational matter;
after all, I probably wouldn't have thought of wanting to have my
own subclasses of PATHNAME either.


-- JonL --

∂25-May-89  0941	Common-Lisp-Object-System-mailer 	Random metaclasses for CL types
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 May 89  09:41:00 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA05828g; Thu, 25 May 89 09:38:22 PDT
Received: by bhopal id AA15726g; Thu, 25 May 89 09:36:33 PDT
Date: Thu, 25 May 89 09:36:33 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8905251636.AA15726@bhopal>
To: Gray@DSG.csc.ti.com
Cc: dussud@lucid.com, Moon@STONY-BROOK.SCRC.Symbolics.COM,
        common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: David N Gray's message of Wed, 24 May 89  17:35:33 CDT <2821041333-6833702@Kelvin>
Subject: Random metaclasses for CL types

re: Date: Wed, 24 May 89  17:35:33 CDT
    From: David N Gray <Gray@DSG.csc.ti.com>
    . . . 
    [... jonl's  inheritance diagram for FUNCTION, STANDARD-FUNCTION, etc]
    . . . 
    OK; the real issue is that if users are to be permitted to define
    subclasses of GENERIC-FUNCTION or STANDARD-FUNCTION, then they just need
    to know what to use for the :METACLASS option for their class in order
    for the inheritance to be permitted.

Right.  And I don't see any particular reason to require it to be
STANDARD-CLASS.  But even if it were to be STANDARD-CLASS, that's not 
nearly so important as the recognition that subclass relations in the 
base classes -- such as FUNCTION, STANDARD-FUNCTION, and 
STANDARD-GENERIC-FUNCTION -- don't imply any particular subclass relations 
in their metaclasses.  I think you seem to be agreeing with me on that.



re: Date: Wed, 24 May 89  18:34:43 CDT
    From: David N Gray <Gray@DSG.csc.ti.com>
    . . . 
    [suggestion that specification for the "holy" types must explicitly
     allow for STANDARD-CLASS and STRUCTURE-CLASS because of the
     openness of CLOS]
    . . . 
    I don't see why flavor classes are any different from standard classes
    in this regard.  Our implementation provides for writing CLOS methods
    that specialize on flavors and use SLOT-VALUE to access their instance
    variables.  True, flavors does have another way of writing methods that
    can be used instead, but that wouldn't necessarily be true of all
    implementation-defined metaclasses.

With respect to STANDARD-CLASS, that's precisely the point -- that there
are _no_ ways other than SLOT-VALUE, etc.  [I presume you meant "all
implementation-defined metaclasses" for built-in classes?]  But you're 
clever trick for pathnames -- letting it be implemented by a kind 
of standard class ("hidden-class") but represented by a kind of built-in
class (the "visible-class") -- shows that we could even forgo the 
special dispensation for STANDARD-CLASS and STRUCTURE-CLASS.

However, if the Gabriel plan of flushing BUILT-IN-CLASS succeeds, it
will all be moot.



-- JonL --

∂25-May-89  1457	Common-Lisp-Object-System-mailer 	re: Random metaclasses for CL types 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 25 May 89  14:56:54 PDT
Received: by ti.com id AA20862; Thu, 25 May 89 16:57:06 CDT
Received: from dsg by tilde id AA04103; Thu, 25 May 89 16:38:21 CDT
Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 25 May 89  11:48:46 CDT
Message-Id: <2821106973-10777481@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 25 May 89  11:49:33 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Cc: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, dussud@LUCID.COM, jonl@LUCID.COM,
        common-lisp-object-system@SAIL.Stanford.EDU
Subject: re: Random metaclasses for CL types 
In-Reply-To: Msg of 24 May 89  1901 PDT from Dick Gabriel <RPG@SAIL.Stanford.EDU>

> I think the real concern is that some implementations might wish to allow
> even the holy types to respond to these protocols. I think we don't want
> to prevent it.

But that is easily handled by allowing the implementation the freedom to
decide which classes are BUILT-IN-CLASSes; we don't need to change the
definition of BUILT-IN-CLASS.

> In Gray's example of the use of BUILT-IN-CLASS, I can't imagine that someone
> writing a portable program couldn't devise a more portable solution to the
> problem, especially if there is alternative that is used if the
> 
>   (TYPEP (FIND-CLASS 'READTABLE) 'BUILT-IN-CLASS)
> 
> returns T.
> 
> Are you thinking of a portable programming environment?

Suppose I were trying to write a portable inspector.  If an object is an
instance of a built-in class, then probably all I can do with it is to
invoke the implementation-supplied DESCRIBE-OBJECT method, but if it is a
STANDARD-CLASS, then I can do interesting things with its CLASS-SLOTS
list.  According to page 3-81 of document 89-003, CLASS-SLOTS simply
returns NIL for a BUILT-IN-CLASS, so how else would I know the difference
between a standard object that has no slots versus an object implemented
in some way that I can't look inside of?

∂25-May-89  1514	Common-Lisp-Object-System-mailer 	Re: Random metaclasses for CL types 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 25 May 89  15:14:27 PDT
Received: by ti.com id AA21021; Thu, 25 May 89 17:13:25 CDT
Received: from dsg by tilde id AA04628; Thu, 25 May 89 16:49:16 CDT
Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 25 May 89  16:25:08 CDT
Message-Id: <2821123544-11773066@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 25 May 89  16:25:44 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@lucid.com>
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, RPG@SAIL.Stanford.EDU,
        dussud@lucid.com, common-lisp-object-system@SAIL.Stanford.EDU
Subject: Re: Random metaclasses for CL types 
In-Reply-To: Msg of Thu, 25 May 89 09:04:42 PDT from Jon L White <jonl@lucid.com>

> As I've previously argued, the only utility of BUILT-IN-CLASS is taxonomic;
> and this capability can just as easily and naturally be provided by a list 
> of all such classes.

No, having a list doesn't give you the ability to write methods
specialized on that group of things.

∂26-May-89  0849	Common-Lisp-Object-System-mailer 	Random metaclasses for CL types     
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 May 89  08:48:56 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA06358g; Fri, 26 May 89 08:47:37 PDT
Received: by bhopal id AA17257g; Fri, 26 May 89 08:47:17 PDT
Date: Fri, 26 May 89 08:47:17 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8905261547.AA17257@bhopal>
To: Gray@DSG.csc.ti.com
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, RPG@SAIL.Stanford.EDU,
        dussud@lucid.com, common-lisp-object-system@SAIL.Stanford.EDU
In-Reply-To: David N Gray's message of Thu, 25 May 89  16:25:44 CDT <2821123544-11773066@Kelvin>
Subject: Random metaclasses for CL types 


re: > As I've previously argued, the only utility of BUILT-IN-CLASS is 
    > taxonomic and this capability can just as easily and naturally be 
    > provided by a list  of all such classes.

    No, having a list doesn't give you the ability to write methods
    specialized on that group of things.

Hey, did you forget we are talking about BUILT-IN-CLASS (and not about
any particular built-in class such as INTEGER or VECTOR)?   User's can't 
write methods for BUILT-IN-CLASS.  Since my previous arguments about the 
artificial similarities among the built-in classes haven't been rebutted, 
then I don't see much to be gained by trying to let them write methods for 
such an ad-hoc construct.  

In your "portable INSPECTOR" project, for example, you need to make a 
decision as to whether to call the built-in DESCRIBE-OBJECT, or to fall 
into some code written in CLOS.  I claim there is no conceptual
disadvantage to making that decision by doing a MEMBER down a system
supplied list.   Furthermore I claim that creating an abstract metaclass 
for some totally disconnected set of classes has the _disadvantage_ of 
adding confusion, because the observer of the abstraction must think 
that there is an underlying similarity in the base elements.  [The 
offending abstraction is BUILT-IN-CLASS because it's only portable
use is taxonomic.]



-- JonL --

∂26-May-89  1035	Common-Lisp-Object-System-mailer 	Re: Random metaclasses for CL types 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 26 May 89  10:35:04 PDT
Received: by ti.com id AA28451; Fri, 26 May 89 12:33:20 CDT
Received: from Kelvin by tilde id AA09755; Fri, 26 May 89 12:30:34 CDT
Message-Id: <2821195790-16113736@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 26 May 89  12:29:50 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@lucid.com>
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, RPG@SAIL.Stanford.EDU,
        common-lisp-object-system@SAIL.Stanford.EDU
Subject: Re: Random metaclasses for CL types 
In-Reply-To: Msg of Fri, 26 May 89 08:47:17 PDT from Jon L White <jonl@lucid.com>

> Hey, did you forget we are talking about BUILT-IN-CLASS (and not about
> any particular built-in class such as INTEGER or VECTOR)?  

No.

>	 User's can't 
> write methods for BUILT-IN-CLASS. 

Sure they can.

(defmethod frob ((class built-in-class))
  (punt class))
(frob (class-of 3))

There, I just did it.  The only thing you aren't supposed to do is to
replace the BUILT-IN-CLASS methods specified by the standard.  Admittedly,
the usefulness of this may be limited.

>    Since my previous arguments about the 
> artificial similarities among the built-in classes haven't been rebutted, 
> then I don't see much to be gained by trying to let them write methods for 
> such an ad-hoc construct.  

I don't see anything to be gained by not allowing it.

> In your "portable INSPECTOR" project, for example, you need to make a 
> decision as to whether to call the built-in DESCRIBE-OBJECT, or to fall 
> into some code written in CLOS.  I claim there is no conceptual
> disadvantage to making that decision by doing a MEMBER down a system
> supplied list. 

Then what do we need object-oriented programming for?  Sure, there's
always another way it could be done.

>    Furthermore I claim that creating an abstract metaclass 
> for some totally disconnected set of classes has the _disadvantage_ of 
> adding confusion, because the observer of the abstraction must think 
> that there is an underlying similarity in the base elements.

There _is_ an underlying similarity:  they share the same methods for
MAKE-INSTANCE, SLOT-VALUE-USING-CLASS, SLOT-BOUNDP-USING-CLASS,
SLOT-EXISTS-P-USING-CLASS, SLOT-MAKUNBOUND-USING-CLASS, CLASS-SLOTS,
CLASS-DEFAULT-INITARGS, CLASS-DIRECT-DEFAULT-INITARGS, CLASS-DIRECT-SLOTS,
CLASS-FINALIZED-P, as specified in chapter 3.

The only way I might accept dropping BUILT-IN-CLASS from the standard
would be if the standard included the class CLASS (which should be done
anyway), so I could do

(defmethod frob ((class class))
  (punt class))

as a catch-all for any unexpected metaclass.  But since BUILT-IN-CLASS or
some equivalent needs to exist in each implementation for the meta-object
protocol, why not standardize the name of it?  It could be argued, though,
that it only belongs in chapter 3.

∂27-May-89  1357	Common-Lisp-Object-System-mailer 	Random metaclasses for CL types     
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 May 89  13:57:17 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA04783g; Sat, 27 May 89 13:54:32 PDT
Received: by bhopal id AA18885g; Sat, 27 May 89 13:54:10 PDT
Date: Sat, 27 May 89 13:54:10 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8905272054.AA18885@bhopal>
To: Gray@DSG.csc.ti.com
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, RPG@SAIL.Stanford.EDU,
        common-lisp-object-system@SAIL.Stanford.EDU
In-Reply-To: David N Gray's message of Fri, 26 May 89  12:29:50 CDT <2821195790-16113736@Kelvin>
Subject: Random metaclasses for CL types 

re: [using MEMBER on a list of built-in classes]
    Then what do we need object-oriented programming for?  Sure, there's
    always another way it could be done.

That's not the point at all; rather the entire issue is whether or not
BUILT-IN-CLASS has enough commonality among its elements such that 
writing methods on it makes sense (your example method certainly didn't 
make any sense to me).  The flip side of the comment "Sure, there's 
always another way it could be done" is, "Sure, every random collection 
of things can be made into a class".

I am certainly not arguing against someone implementing built-in classes 
this way -- using a common meta-class to simplify coding -- rather, I am 
supporting Gabriel's call to remove this piece of non-portable, internal 
implementation from the end-user's view.


re: There _is_ an underlying similarity:  they share the same methods for
    MAKE-INSTANCE, ... CLASS-FINALIZED-P, as specified in chapter 3.

I.e., they are "similar" because someone decided make a random collection
of types, and then list all the methods that could be applied to class
objects?  Isn't that circular reasoning?  [By the bye, Chap 3 *isn't*
part of the standard, and we are talking about a change to the elementary
part of Chap 1.]  

Also, as I would have it, built-in classes couldn't be defined by the 
user, subclassed by the user, dynamically altered by the user, etc;  
under these restrictions, many parts of the metaobject protocol wouldn't 
be interesting for random collections of built-in classes, including the 
whole such collection.

In fact, _almost_ any method that one would need to support the 
implementation of built-in types is not specific to BUILT-IN-CLASS,
but is the default at the top of the class heirarchy.  The restrictions
on BUILT-IN-CLASS are typically just "You can't do that", which is
what you need for any otherwise unembellished metaclass.


re: The only way I might accept dropping BUILT-IN-CLASS from the standard
    would be if the standard included the class CLASS (which should be done
    anyway),  . . . 

Gleep, I don't recall how we managed to vote in Chap 1 without class CLASS.
Can someone add a quickie cleanup to straighten this out?



-- JonL --

∂01-Jun-89  0852	CL-Compiler-mailer 	issue CLOS-MACRO-COMPILATION  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 1 Jun 89  08:52:51 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA25231; Thu, 1 Jun 89 09:53:09 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA14532; Thu, 1 Jun 89 09:53:06 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906011553.AA14532@defun.utah.edu>
Date: Thu, 1 Jun 89 09:53:05 MDT
Subject: issue CLOS-MACRO-COMPILATION
To: cl-compiler@sail.stanford.edu
Cc: common-lisp-object-system@sail.stanford.edu

I'm in the process of revising the writeup on this issue to
incorporate the amendment Gregor proposed at the last meeting, and I
have a question.

The amendment uses the term "load time" to describe the time at which
certain things happen.  I think is not really what we want, since it's
possible that the defining macro in question might not appear at top
level.  I'd suggest saying something like "the time at which the macro
is normally executed" instead. 

However, to me this doesn't really make sense in the context of the
amendment to the DEFINE-METHOD-COMBINATION language: "clarify that the
bodies of such forms are evaluated no earlier than load time".  Does
this really mean "no earlier than the time at which the
DEFINE-METHOD-COMBINATION macro is executed"?  I've been under the
impression that DEFINE-METHOD-COMBINATION defines a functional object
and that its body could be evaluated no earlier than the time that
function is invoked, which would be (at the earliest) when a
DEFGENERIC form that references it is executed.  Or am I confused
again? 

-Sandra
-------

∂14-Jun-89  0105	Common-Lisp-Object-System-mailer 	FLAVOR-CLASS, and Random metaclasses for CL types  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 14 Jun 89  01:05:43 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA09613g; Wed, 14 Jun 89 01:03:50 PDT
Received: by bhopal id AA17033g; Wed, 14 Jun 89 01:06:07 PDT
Date: Wed, 14 Jun 89 01:06:07 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8906140806.AA17033@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: common-lisp-object-system@sail.stanford.edu, Gray@DSG.csc.ti.com
Subject: FLAVOR-CLASS, and Random metaclasses for CL types 

I don't think we ever came to any resolution about your original
query of Date: Wed, 10 May 89 13:31 EDT -- namely how to rewrite
the paragraph on page 1-15 of 88-002R which spells out how the "holy"
types can be implemented.

However, I remember it being sparked by a desire to assure that
flavors-implemented types could be used as the underlying implementation
of some of the "holy" types; and this led to the discussion of how
such a class might relate to BUILT-IN-CLASS.

But I see that several vendors are planning to offer a FLAVOR-CLASS
as a tie-in with their native (or optional) flavors products (and Gregor
mentioned he is working on a similar "hook" for PCL too).  That is, a 
meta-class somewhat like STRUCTURE-CLASS that ensures that flavor types 
(which are integrated with CL types in those products) also have 
appropriately named CLOS classes behind them so that they can be 
specialized upon.

Why not mention this directly in the standard?  either as one possibility
for implementation of the "holy" types, or simply as an example of
an implementation-specific meta-class being used to supply one of the
"holy" types.  I don't think it would be necessary to "flesh out"
FLAVOR-CLASS anymore than STRUCTURE-CLASS is currently specified.

FLAVOR-CLASS indeed has a good deal to recommend it, in an implementation
that supports flavors -- much more than, say, BUILT-IN-CLASS (see my
previous critique of the inutility of making a class for the random,
small collection of "left over" CL types).  Don't you think a short 
statement like the above would give the kind of assurance you wanted for 
Symbolic's implementation of pathnames?


-- JonL --

∂16-Jun-89  1554	CL-Compiler-mailer 	issue COMPILE-ENVIRONMENT-CONSISTENCY, version 6  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 Jun 89  15:54:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612340; 16 Jun 89 18:56:02 EDT
Date: Fri, 16 Jun 89 18:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 6
To: cl-compiler@sail.stanford.edu, Common-Lisp-Object-System@sail.stanford.edu
In-Reply-To: <8906151608.AA23867@defun.utah.edu>
Message-ID: <19890616225632.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

This is okay (either proposal).

I believe there is no harm in requiring conforming programs to obey the
DEFCLASS restriction for now, so I don't see the advantage to
BOBS-AMENDMENT, even though in the future metaclasses might change this.

∂16-Jun-89  1635	Common-Lisp-Object-System-mailer 	FLAVOR-CLASS, and Random metaclasses for CL types  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 16 Jun 89  16:35:43 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 612385; 16 Jun 89 19:37:01 EDT
Date: Fri, 16 Jun 89 19:37 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FLAVOR-CLASS, and Random metaclasses for CL types 
To: Jon L White <jonl@lucid.com>
cc: common-lisp-object-system@sail.stanford.edu, Gray@DSG.csc.ti.com
In-Reply-To: <8906140806.AA17033@bhopal>
Message-ID: <19890616233725.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 14 Jun 89 01:06:07 PDT
    From: Jon L White <jonl@lucid.com>

    I don't think we ever came to any resolution about your original
    query of Date: Wed, 10 May 89 13:31 EDT -- namely how to rewrite
    the paragraph on page 1-15 of 88-002R which spells out how the "holy"
    types can be implemented.

I'm not sure.  I have 20 messages saved on the topic and don't have time
to review them right now.

    But I see that several vendors are planning to offer a FLAVOR-CLASS
    as a tie-in with their native (or optional) flavors products (and Gregor
    mentioned he is working on a similar "hook" for PCL too).  That is, a 
    meta-class somewhat like STRUCTURE-CLASS that ensures that flavor types 
    (which are integrated with CL types in those products) also have 
    appropriately named CLOS classes behind them so that they can be 
    specialized upon.

    Why not mention this directly in the standard?  

I don't think it's at all appropriate to include the name FLAVOR-CLASS
in the standard.  What I do want to do to the standard is to make sure
that it doesn't accidentally contain language that would make it impossible
for an implementation to add FLAVOR-CLASS, OBJECT-LISP-CLASS, PCL-CLASS,
or any of several others.  I think this should be easy to do.

∂19-Jun-89  0957	Common-Lisp-Object-System-mailer 	FLAVOR-CLASS, and Random metaclasses for CL types  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Jun 89  09:56:51 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA20643g; Mon, 19 Jun 89 09:54:16 PDT
Received: by bhopal id AA00425g; Mon, 19 Jun 89 09:56:07 PDT
Date: Mon, 19 Jun 89 09:56:07 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8906191656.AA00425@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: common-lisp-object-system@sail.stanford.edu, Gray@DSG.csc.ti.com
In-Reply-To: David A. Moon's message of Fri, 16 Jun 89 19:37 EDT <19890616233725.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: FLAVOR-CLASS, and Random metaclasses for CL types 

re:     Why not mention this directly in the standard?  

    I don't think it's at all appropriate to include the name FLAVOR-CLASS
    in the standard.  What I do want to do to the standard is to make sure
    that it doesn't accidentally contain language that would make it impossible
    for an implementation to add FLAVOR-CLASS, OBJECT-LISP-CLASS, PCL-CLASS,
    or any of several others.  I think this should be easy to do.

Uh, wrong referent on the "mention this" -- it wasn't to include FLAVOR-CLASS
in the standard.  The rest of the paragraph you excerpted was:
     . . .  either as one possibility
    for implementation of the "holy" types, or simply as an example of
    an implementation-specific meta-class being used to supply one of the
    "holy" types.  

The point is simply that any "implementation-specific meta-class" which
preserves the properties of the "holy" types should be satisfactory,
regardless of whether it is called a BUILT-IN-CLASS or not.  The advantage
of using FLAVOR-CLASS as an example is that, like STRUCTURE-CLASS, it
is already tied into the type system of those implementations that have
it.  Thus all that is lacking from CLOS's point of view is a (CLOS)
class definition stub, so that such instances may be specialized upon.


-- JonL --

∂21-Jun-89  1644	Common-Lisp-Object-System-mailer 	Re: issue CLOS-MACRO-COMPILATION, version 4   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Jun 89  16:44:02 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA05056; Wed, 21 Jun 89 17:44:24 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA01963; Wed, 21 Jun 89 17:44:21 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906212344.AA01963@defun.utah.edu>
Date: Wed, 21 Jun 89 17:44:20 MDT
Subject: Re: issue CLOS-MACRO-COMPILATION, version 4
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@sail.stanford.edu, Moon@STONY-BROOK.SCRC.Symbolics.COM,
        RPG@Lucid.COM, common-lisp-object-system@sail.stanford.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 21 Jun 89 18:18 EDT

> Date: Wed, 21 Jun 89 18:18 EDT
> From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
> 
> Surely you don't mean that DEFGENERIC will arrange for the gf not to
> be callable. You simply mean that it won't arrange for it to be callable.

Yes, you're right.  

>  - DEFMETHOD may not pollute the compile time environment by augmenting
>    the generic function at that time.

The intent is that simply *compiling* a DEFMETHOD won't pollute the
compile time environment.  I agree this could perhaps be made more 
explicit.

> Actually, on an unrelated point, I guess I am also slightly nervous
> about the vague phrasing "may try to evaluate" (e.g., in discussion of
> EQL specializers).

This wording was taken from the amendment Gregor proposed at the last
meeting.  I have not presumed to try to interpret what it means.  I
personally think we would be better off deleting this particular
sentence from the proposal, and sticking with the simple statement
that EQL specializer forms are evaluated when the DEFMETHOD form is
executed.

-Sandra
-------

∂21-Jun-89  1752	CL-Compiler-mailer 	Re: issue CLOS-MACRO-COMPILATION, version 4  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 21 Jun 89  17:52:48 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 614933; 21 Jun 89 20:54:07 EDT
Date: Wed, 21 Jun 89 20:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue CLOS-MACRO-COMPILATION, version 4
To: sandra%defun@cs.utah.edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, cl-compiler@sail.stanford.edu, Moon@STONY-BROOK.SCRC.Symbolics.COM,
    RPG@Lucid.COM, common-lisp-object-system@sail.stanford.edu
In-Reply-To: <8906212344.AA01963@defun.utah.edu>
Message-ID: <19890622005403.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Wed, 21 Jun 89 17:44:20 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    ...
    >  - DEFMETHOD may not pollute the compile time environment by augmenting
    >    the generic function at that time.

    The intent is that simply *compiling* a DEFMETHOD won't pollute the
    compile time environment.  I agree this could perhaps be made more 
    explicit.

I guess the problem was that because the previous thing (about DEFGENERIC)
had forced me to contort the meanings of some of the words, there was a
tendency for me to wonder if there were hidden meanings in some of the others.

    > Actually, on an unrelated point, I guess I am also slightly nervous
    > about the vague phrasing "may try to evaluate" (e.g., in discussion of
    > EQL specializers).

    This wording was taken from the amendment Gregor proposed at the last
    meeting.  I have not presumed to try to interpret what it means.  I
    personally think we would be better off deleting this particular
    sentence from the proposal, and sticking with the simple statement
    that EQL specializer forms are evaluated when the DEFMETHOD form is
    executed.

Well, removing the statement would probably be fine by me. I don't think
it really adds much semantic content since, after all, any function can
attempt to evaluate just about anything as long as the effects of doing
so are not visible.  Maybe all that's really being said is that ``the
compiler can build in knowledge about what the form in an EQL
specializer will evaluate to in cases where the ultimate result can be
syntactically inferred without actually evaluating it.''  I guess that's
an interesting piece of information, but I'd prefer a presentation like
this that emphasized -not- evaluating it rather than something that said
trying evaluation was ok when clearly in the general case it is not.

∂14-Jul-89  1835	Common-Lisp-Object-System-mailer 	2nd CLOS Workshop    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Jul 89  18:35:49 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 14 JUL 89 17:42:35 PDT
Date: Fri, 14 Jul 89 17:39 PDT
From: Gregor.pa@Xerox.COM
Subject: 2nd CLOS Workshop
To: common-lisp-object-system@sail.stanford.edu, CommonLoops.pa@Xerox.COM
Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest
Message-ID: <19890715003916.7.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no


This message is a reminder about the second CLOS workshop.  The workshop
will be held at the OOPSLA conference which will be in New Orleans this
year.  The dates for OOPSLA are October 2 - 6.

This year's workshop is targeted to persons with significant experience
with the Common Lisp Object System.  The purpose of this workshop is to
bring together a wide range of CLOS expertise in a setting which
promotes substantive interaction among the participants.  The workshop
will address current issues in the use, development and implementation
of CLOS.

In order to promote intensive interaction among workshop participants,
attendance will be limited to 30 people.  Persons who would like to
attend should submit five copies of a short (5 - 10 page) paper
describing their work with CLOS.  It is permissible for this to be a
paper which will be presented in the main track of the conference.
Papers will be reviewed by a committee, workshop participants will be
selected from the submitted papers.

Papers must be received by August 1 1989 and should be sent to:

Gregor Kiczales
Xerox PARC
3333 Coyote Hill Rd.
Palo Alto, CA 94304
-------

∂17-Jul-89  2257	Common-Lisp-Object-System-mailer 	DEFMETHOD with no required args?    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 17 Jul 89  22:57:35 PDT
Received: by ti.com id AA20759; Mon, 17 Jul 89 12:33:14 CDT
Received: from Kelvin by tilde id AA12698; Mon, 17 Jul 89 12:18:06 CDT
Message-Id: <2825687758-15679445@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 17 Jul 89  12:15:58 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Common-Lisp-Object-System@SAIL.Stanford.edu
Cc: john@linus.MITRE.ORG (John D. Burger)
Subject: DEFMETHOD with no required args?
In-Reply-To: Msg of Thu, 13 Jul 89 18:32:16 EDT from john@linus.MITRE.ORG (John D. Burger)

> Date: Thu, 13 Jul 89 18:32:16 EDT
> From: john@linus.MITRE.ORG (John D. Burger)
> To:   CommonLoops.pa@Xerox.COM
> Subject: Re: Singleton, default DEFMETHOD now as fast as a DEFUN?
> 
> ihlpf!lgm (Lawrence G Mayka) says:
> 
> >The two hitches are (a) functions taking no arguments cannot be
> >DEFMETHODs, ...
> 
> Is this specified in the CLOS standard?  From an empirical point of
> view, it's false, since I just did the following in Victoria Day PCL:
> 
>   (defmethod say-hello-gracie () "Hello, Gracie")
> 
> This sort of definition is admittedly very uninteresting,
> but it does appear to be supported.

My immediate reaction was "of course that isn't supposed to work", but I
can't find anywhere that 88-002R actually says that.  In particular, the
specialized lambda list syntax uses {...}* instead of {...}+ which
implies that there could be no required arguments.  Is this really
supposed to be permitted, or is it an oversight that it is not
explicitly prohibited?

∂18-Jul-89  0342	Common-Lisp-Object-System-mailer 	re: DEFMETHOD with no required args?
To:   Gray@DSG.CSC.TI.COM,
      Common-Lisp-Object-System@SAIL.Stanford.EDU
CC:   john@LINUS.MITRE.ORG   
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

[In reply to message from Gray@DSG.csc.ti.com sent Mon, 17 Jul 89 12:15:58 CDT.]

David Gray writes:

``My immediate reaction was "of course that isn't supposed to work", but I
can't find anywhere that 88-002R actually says that.  In particular, the
specialized lambda list syntax uses {...}* instead of {...}+ which
implies that there could be no required arguments.  Is this really
supposed to be permitted, or is it an oversight that it is not
explicitly prohibited?''

As one of the primary authors of 88-002R, it is not an oversight that
generic functions of 0 required arguments is permitted, and one reason
is that it strikes me that ``of course that is supposed to work.''

The question appears to hinge on a judgement of the form that unless some
particular feature has some ``reasonable use'' in a language, why permit
the feature?  A generic function of 0 arguments is primarily useful for
writing a program with a simple control structure based on the method
combination type specified.

The counter to the judgement is that regularity or consistency is also
important. For example, we do not prohibit addition of 0, even though
there is no use for it (coercion or normalization aside). So why make a
special case of 0 arguments?

Another approach to the problem is to maintain the belief that methods
are somehow attached to classes, and since a method on 0 arguments has
no classes for attachment, there can be no method. Already we need to
attach methods to sets of classes rather than individual classes,
so the empty set need not be a special case.

Finally, there may be an implementation reason to prohibit generic
functions of 0 arguments, but this reason is not interesting.

			-rpg-

∂18-Jul-89  1021	Common-Lisp-Object-System-mailer 	re: DEFMETHOD with no required args?
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 18 Jul 89  10:21:49 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 18 JUL 89 09:58:15 PDT
Date: Tue, 18 Jul 89 09:58 PDT
From: Gregor.pa@Xerox.COM
Subject: re: DEFMETHOD with no required args?
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: Gray@DSG.CSC.TI.COM, Common-Lisp-Object-System@SAIL.Stanford.EDU,
 john@LINUS.MITRE.ORG
Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest
In-Reply-To: <tuSvG@SAIL.Stanford.EDU>
Message-ID: <19890718165805.0.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no

    Date: 18 Jul 89 03:42 PDT
    From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

    The question appears to hinge on a judgement of the form that unless some
    particular feature has some ``reasonable use'' in a language, why permit
    the feature?  A generic function of 0 arguments is primarily useful for
    writing a program with a simple control structure based on the method
    combination type specified.

It seems pathological to me to have a generic function of zero required
arguments.  I would never have guessed that the spec would allow this.
It requires a degenerate case of the first stage of generic function
invocation, namely determining the ordered set of applicable methods.

The only use for this is, as you say, to get access to the method
combination facility without the method lookup facility.  I guess this
will make it easier for people to demonstrate how CLOS makes it possible
to write gratuitously confusing programs!
-------

∂18-Jul-89  1506	Common-Lisp-Object-System-mailer 	call-next-method incoherency   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 18 Jul 89  15:06:10 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 627408; 18 Jul 89 18:08:03 EDT
Date: Tue, 18 Jul 89 18:08 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: call-next-method incoherency
To: Common-Lisp-Object-System@sail.stanford.edu
Message-ID: <19890718220816.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

There is a problem in the specification of call-next-method which I
need some help to fix.

The current draft of the ANSI Common lisp specification says:
 
  If there is no next method, the generic function 
  no-next-method is called.

  If call-next-method is used in a method
  whose method combination does not support it,
  an error of type control-error is signalled.
 
In 88-002R, it said just "an error is signaled" rather than specifying
control-error.  The problem I need help with is not the inconsistent
spelling of "signaled" and is not exactly the particular condition type
to be signaled.  The problem is with the definition of what it means for
a method combination type to not support call-next-method.
Define-method-combination does not contain any way to specify whether
call-next-method is supported.  All you can do is call a method with
call-method and either supply a next-method-list or not supply one; but
there is no way to distinguish between a next-method-list that happens
to be empty (in which case call-next-method should call no-next-method)
and a situation where a next-method-list is not allowed.

I see four possible approaches:

1. Change "an error of type control-error is signalled" to
   "the generic function no-next-method is called."  Assume
   that an applicable method for no-next-method signals the error.

2. Change call-method to accept a second argument of :error,
   in place of a next-method-list, which tells call-next-method
   to signal an error.

3. Change call-method to make next-method-list optional.  If it
   is not supplied, that tells call-next-method to signal an error.

4. Add a long-form-option to define-method-combination to specify
   whether methods in this method group support call-next-method.

None of these approaches makes it particularly easy to report the
misuse-of-call-next-method error at compile time, but that's not
vitally important.  Approach 1 is the only one that makes reporting
the error at compile time impossible.

I need some help deciding which of these approaches is right.  We
can't just stick with the status quo, because it's inconsistent.
The approach I prefer is #3, as the least change to the language.

∂18-Jul-89  1517	Common-Lisp-Object-System-mailer 	re: call-next-method incoherency    
To:   Moon@STONY-BROOK.SCRC.SYMBOLICS.COM,
      Common-Lisp-Object-System@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

[In reply to message from Moon@STONY-BROOK.SCRC.Symbolics.COM sent Tue, 18 Jul 89 18:08 EDT.]

I prefer #1 and ``signaled''.

			-rpg-

∂18-Jul-89  1626	Common-Lisp-Object-System-mailer 	Re: call-next-method incoherency    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 18 Jul 89  16:22:46 PDT
Received: by ti.com id AA12267; Tue, 18 Jul 89 18:19:04 CDT
Received: from Kelvin by tilde id AA17463; Tue, 18 Jul 89 18:02:50 CDT
Message-Id: <2825794999-5597375@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 18 Jul 89  18:03:19 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Common-Lisp-Object-System@sail.stanford.edu
Subject: Re: call-next-method incoherency
In-Reply-To: Msg of Tue, 18 Jul 89 18:08 EDT from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

I prefer approach #1 since it is the simplest to implement, and no need
for a more complicated approach has been demonstrated.

∂18-Jul-89  1820	Common-Lisp-Object-System-mailer 	Re: call-next-method incoherency    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 18 Jul 89  18:20:20 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 18 JUL 89 18:14:42 PDT
Date: Tue, 18 Jul 89 18:12 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: call-next-method incoherency
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Common-Lisp-Object-System@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest
In-Reply-To: <19890718220816.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890719011208.6.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no

I believe I prefer #1.
-------

∂18-Jul-89  1845	Common-Lisp-Object-System-mailer 	Re: call-next-method incoherency    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 18 Jul 89  18:45:08 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 18 JUL 89 18:41:59 PDT
Date: 18 Jul 89 18:41 PDT
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: call-next-method incoherency
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Tue, 18 Jul 89 18:08 EDT
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Common-Lisp-Object-System@sail.stanford.edu
Message-ID: <890718-184159-11318@Xerox>

I prefer #1

  danny

∂20-Jul-89  1430	Common-Lisp-Object-System-mailer 	call-next-method incoherency   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 20 Jul 89  14:30:41 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 628909; 20 Jul 89 17:32:37 EDT
Date: Thu, 20 Jul 89 17:32 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: call-next-method incoherency
To: Common-Lisp-Object-System@sail.stanford.edu
In-Reply-To: <19890718220816.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890720213255.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

Here are some arguments from JonL which I find quite persuasive.
Before I saw these I was just going to go with #1 since that's
what all the respondents had said, but now I am reconfirmed in my
belief that #3 is the best option.  Did the people who suggested
#1 base their suggestion on careful thought, or just pick that one
because it seemed easiest or was first on the list?  If there are
good arguments for #1 I'd like to hear them.

#1 smacks of overloading a communication channel.  Some lusers out there
   will come to depend on finding out the method-combination mismatch
   error by placing obscure methods on NO-NEXT-METHOD, so we will never
   be able to correct this wort once it gets in.

#4 smacks of overkill; a piece of syntax at the same level as everything
   else in method combination  to cover an incredibly obscure problem that 
   almost no one will run into.  Why clutter up the spec.  Besides, whole
   method groups might be too coarse a sieve to strain out the contexts
   under which you want to proscribe CALL-NEXT-METHOD.

#3 is a very logical extension of the meaning of CALL-METHOD as spelled
   out in 88-002R p.2-11.  CALL-METHOD should bear the burden, since it 
   is the interface between method-combination and CALL-NEXT-METHOD.  I 
   suspect some existing implementations (e.g. PCL) would require more of 
   a change to do it this way than by #1, but not a radical change.

#2 is just a variant of #3, but the syntax is more "special case", rather
   than the "natural extesion" of #3.  Providing a null list for the
   next-methods argument is a fine way to say "any use of CALL-NEXT-METHOD 
   will simply call NO-NEXT-METHD";  the natural way to differentiate this
   case from a control-error case is to _not_ provide the next-methods
   argument at all.  Thus #3 is preferable.

The argument would be compelling if you could show a way to model the 
prohibitions in standard-method-combination using this #3 approach 
(i.e., can't use CALL-NEXT-METHOD in :before or :after methods, but can 
use it in primary and :around).

That's the end of the quotation from JonL, the rest is my response:

From the documentation examples, here is the existing definition of
standard method combination:

;The default method-combination technique
(define-method-combination standard ()
	((around (:around))
	 (before (:before))
	 (primary () :required t)
	 (after (:after)))
  (flet ((call-methods (methods)
	   (mapcar #'(lambda (method)
		       `(call-method ,method ()))
		   methods)))
    (let ((form (if (or before after (rest primary))
		    `(multiple-value-prog1
		       (progn ,@(call-methods before)
			      (call-method ,(first primary)
					   ,(rest primary)))
		       ,@(call-methods (reverse after)))
		    `(call-method ,(first primary) ()))))
      (if around
	  `(call-method ,(first around)
			(,@(rest around)
			 (make-method ,form)))
	  form))))

and here is the compelling modified version for the #3 approach:

;The default method-combination technique
(define-method-combination standard ()
	((around (:around))
	 (before (:before))
	 (primary () :required t)
	 (after (:after)))
  (flet ((call-methods (methods)
	   (mapcar #'(lambda (method)
		       `(call-method ,method))
		   methods)))
    (let ((form (if (or before after (rest primary))
		    `(multiple-value-prog1
		       (progn ,@(call-methods before)
			      (call-method ,(first primary)
					   ,(rest primary)))
		       ,@(call-methods (reverse after)))
		    `(call-method ,(first primary) ()))))
      (if around
	  `(call-method ,(first around)
			(,@(rest around)
			 (make-method ,form)))
	  form))))

Only one line is changed.

∂21-Jul-89  0944	Common-Lisp-Object-System-mailer 	Re: call-next-method incoherency    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Jul 89  09:44:34 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUL 89 09:39:23 PDT
Date: Fri, 21 Jul 89 09:36 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: call-next-method incoherency
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Common-Lisp-Object-System@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest
In-Reply-To: <19890720213255.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890721163640.5.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no

Sure, I'll go for number 3, what the hell.
-------

∂25-Jul-89  0745	Common-Lisp-Object-System-mailer 	call-next-method incoherency   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 25 Jul 89  07:45:18 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 631021; 25 Jul 89 10:46:55 EDT
Date: Tue, 25 Jul 89 10:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: call-next-method incoherency
To: Common-Lisp-Object-System@sail.stanford.edu
In-Reply-To: <19890718220816.2.MOON@EUPHRATES.SCRC.Symbolics.COM>,
             <12uyLq@SAIL.Stanford.EDU>,
             <2825794999-5597375@Kelvin>,
             <19890719011208.6.GREGOR@SPIFF.parc.xerox.com>,
             <890718-184159-11318@Xerox>,
             <8907200126.AA28307@bhopal>,
             <19890720182310.5.MOON@EUPHRATES.SCRC.Symbolics.COM>,
             <8907202020.AA11750@challenger>,
             <19890720213255.6.MOON@EUPHRATES.SCRC.Symbolics.COM>,
             <8907202329.AA12019@challenger>,
             <19890721163640.5.GREGOR@SPIFF.parc.xerox.com>
Message-ID: <19890725144640.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

Okay, #3 it is.  The next-method-list argument to call-method is
optional.

∂26-Jul-89  0944	Common-Lisp-Object-System-mailer 	DOCUMENTATION and DEFCLASS
Received: from ti.com by SAIL.Stanford.EDU with TCP; 26 Jul 89  09:44:34 PDT
Received: by ti.com id AA20965; Wed, 26 Jul 89 11:36:09 CDT
Received: from Kelvin by tilde id AA05507; Wed, 26 Jul 89 11:28:34 CDT
Message-Id: <2826458950-15178582@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 26 Jul 89  11:29:10 EDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Common-Lisp-Object-System@SAIL.Stanford.edu
Cc: chapman@aitg.enet.dec.com
Subject: DOCUMENTATION and DEFCLASS

CLOS gurus,

I think I've found a small mistake in 88-002R while reviewing Kathy's
draft of the DEFCLASS description.  Page 2-24 says 

  The :DOCUMENTATION class option causes a documentation string to be
  attached to the class name.

I believe that should say "... to the class object".  Note that page
2-44 says 

  The form (DOCUMENTATION symbol 'TYPE) returns the documentation string
  of the class object named by the symbol ...

Test case:

  (DEFCLASS QQ () () (:DOCUMENTATION "Hello"))
  (SETF (FIND-CLASS 'ZZ) (FIND-CLASS 'QQ))
  (SETF (CLASS-NAME (FIND-CLASS 'ZZ)) 'ZZ)
  (DOCUMENTATION 'ZZ 'TYPE)  =>  "Hello"

Any objection to making an editorial correction?

∂26-Jul-89  1038	Common-Lisp-Object-System-mailer 	method combination objects
Received: from ti.com by SAIL.Stanford.EDU with TCP; 26 Jul 89  10:38:24 PDT
Received: by ti.com id AA21449; Wed, 26 Jul 89 12:34:21 CDT
Received: from Kelvin by tilde id AA07039; Wed, 26 Jul 89 12:24:21 CDT
Message-Id: <2826462298-15379727@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 26 Jul 89  12:24:58 EDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: Common-Lisp-Object-System@sail.stanford.edu
Subject: method combination objects

From the draft for DEFINE-METHOD-COMBINATION:

> \label Values:
>  
> % 88-002R p.2-34 said this, but it's wrong, method-combination objects
> % are created by the defgeneric :method-combination option.
> % See 88-002R p.1-28. --Moon
> % New method combination object.
>  
> % Added by Moon to replace wrong specification above:
>  
> {\arg Name\/}.

Oh, OK.  Can I also assume then that function FIND-METHOD-COMBINATION in
89-003 is also a mistake and that all we need is
GENERIC-FUNCTION-METHOD-COMBINATION ?

∂26-Jul-89  1059	Common-Lisp-Object-System-mailer 	method combination objects
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 26 Jul 89  10:59:12 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 631873; 26 Jul 89 13:59:42 EDT
Date: Wed, 26 Jul 89 13:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: method combination objects
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Common-Lisp-Object-System@sail.stanford.edu
In-Reply-To: <2826462298-15379727@Kelvin>
Message-ID: <19890726175943.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 26 Jul 89  12:24:58 EDT
    From: David N Gray <Gray@DSG.csc.ti.com>

    From the draft for DEFINE-METHOD-COMBINATION:

    > \label Values:
    >  
    > % 88-002R p.2-34 said this, but it's wrong, method-combination objects
    > % are created by the defgeneric :method-combination option.
    > % See 88-002R p.1-28. --Moon
    > % New method combination object.
    >  
    > % Added by Moon to replace wrong specification above:
    >  
    > {\arg Name\/}.

    Oh, OK.  Can I also assume then that function FIND-METHOD-COMBINATION in
    89-003 is also a mistake and that all we need is
    GENERIC-FUNCTION-METHOD-COMBINATION ?

89-003 is so full of errors that I don't generally find it useful to
comment on it.  However, the macro expansion of DEFGENERIC has to have
some way to convert the :METHOD-COMBINATION option from a list into
an object of type METHOD-COMBINATION.  I don't see anything wrong
with the writeup on 89-003 p.3-61, unless maybe it needs an environment
argument, so I don't think it's a mistake.

∂26-Jul-89  1145	Common-Lisp-Object-System-mailer 	DOCUMENTATION and DEFCLASS
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 26 Jul 89  11:45:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 631909; 26 Jul 89 14:45:26 EDT
Date: Wed, 26 Jul 89 14:45 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DOCUMENTATION and DEFCLASS
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Common-Lisp-Object-System@SAIL.Stanford.edu, chapman@aitg.enet.dec.com
In-Reply-To: <2826458950-15178582@Kelvin>
Message-ID: <19890726184525.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 26 Jul 89  11:29:10 EDT
    From: David N Gray <Gray@DSG.csc.ti.com>

    I think I've found a small mistake in 88-002R while reviewing Kathy's
    draft of the DEFCLASS description.  Page 2-24 says 

      The :DOCUMENTATION class option causes a documentation string to be
      attached to the class name.

    I believe that should say "... to the class object".  

I think you're right.  Perhaps the way the DOCUMENTATION function works
was changed at some point after this had been written.  As far as I'm
concerned Kathy can go ahead and change "name" to "object" or to "".

∂26-Jul-89  1241	Common-Lisp-Object-System-mailer 	Re: method combination objects 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 26 Jul 89  12:41:39 PDT
Received: by ti.com id AA22669; Wed, 26 Jul 89 14:37:05 CDT
Received: from Kelvin by tilde id AA09903; Wed, 26 Jul 89 14:16:58 CDT
Message-Id: <2826469058-15785914@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 26 Jul 89  14:17:38 EDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Common-Lisp-Object-System@sail.stanford.edu
Subject: Re: method combination objects
In-Reply-To: Msg of Wed, 26 Jul 89 13:59 EDT from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

> 89-003 is so full of errors that I don't generally find it useful to
> comment on it. 

Yes, but then what _are_ we going to do with it?  :-)

>	...   However, the macro expansion of DEFGENERIC has to have
> some way to convert the :METHOD-COMBINATION option from a list into
> an object of type METHOD-COMBINATION.  I don't see anything wrong
> with the writeup on 89-003 p.3-61, unless maybe it needs an environment
> argument, so I don't think it's a mistake.

Sounds then like it should be MAKE-METHOD-COMBINATION instead of
FIND-METHOD-COMBINATION.

∂26-Jul-89  1342	Common-Lisp-Object-System-mailer 	Re: method combination objects 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 26 Jul 89  13:42:10 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 632047; 26 Jul 89 16:43:53 EDT
Date: Wed, 26 Jul 89 16:43 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: method combination objects
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Common-Lisp-Object-System@sail.stanford.edu
In-Reply-To: <2826469058-15785914@Kelvin>
Message-ID: <19890726204352.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 26 Jul 89  14:17:38 EDT
    From: David N Gray <Gray@DSG.csc.ti.com>

    > 89-003 is so full of errors that I don't generally find it useful to
    > comment on it. 

    Yes, but then what _are_ we going to do with it?  :-)

    >	...   However, the macro expansion of DEFGENERIC has to have
    > some way to convert the :METHOD-COMBINATION option from a list into
    > an object of type METHOD-COMBINATION.  I don't see anything wrong
    > with the writeup on 89-003 p.3-61, unless maybe it needs an environment
    > argument, so I don't think it's a mistake.

    Sounds then like it should be MAKE-METHOD-COMBINATION instead of
    FIND-METHOD-COMBINATION.

I think the idea was that since it doesn't necessarily cons a fresh object
every time you call it, it should be named like the other FIND- functions.

∂26-Jul-89  2112	Common-Lisp-Object-System-mailer 	call-next-method
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Jul 89  21:12:12 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA27541@EDDIE.MIT.EDU>; Thu, 27 Jul 89 00:12:41 EDT
Received: by spt.entity.com (smail2.5); 27 Jul 89 00:09:50 EDT (Thu)
Date: Thu, 27 Jul 1989 0:09:50 EDT
From: Gail Zacharias <gz@spt.entity.com>
To: common-lisp-object-system@sail.stanford.edu
Subject: call-next-method
Message-Id: <CMM.0.88.617515790.gz@spt.entity.com>

Can call-next-method be used in init forms of optional/keyword arguments?
How about &aux inits?

∂27-Jul-89  0904	Common-Lisp-Object-System-mailer 	call-next-method
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 27 Jul 89  09:04:37 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 632522; 27 Jul 89 12:06:36 EDT
Date: Thu, 27 Jul 89 12:06 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: call-next-method
To: Gail Zacharias <gz@spt.entity.com>
cc: common-lisp-object-system@sail.stanford.edu
In-Reply-To: <CMM.0.88.617515790.gz@spt.entity.com>
Message-ID: <19890727160635.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 27 Jul 1989 0:09:50 EDT
    From: Gail Zacharias <gz@spt.entity.com>

    Can call-next-method be used in init forms of optional/keyword arguments?
    How about &aux inits?

The documentation everywhere says "in the body of a method", which
presumably excludes forms contained in the lambda-list, since "body of
the method" is explicitly defined in the documentation of DEFMETHOD.
Personally I think that was a poor design decision.

Current practice:  PCL appears to allow call-next-method in forms in the
lambda-list.  Flavors doesn't allow continue-whopper in forms in the
lambda-list, although there is no reason why it couldn't.

∂28-Jul-89  1202	Common-Lisp-Object-System-mailer 	Re: call-next-method 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Jul 89  12:02:26 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 28 JUL 89 11:50:19 PDT
Date: Fri, 28 Jul 89 11:47 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: call-next-method
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Gail Zacharias <gz@spt.entity.com>,
 common-lisp-object-system@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest
In-Reply-To: <19890727160635.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890728184745.0.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no

    Date: Thu, 27 Jul 89 12:06 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    The documentation everywhere says "in the body of a method", which
    presumably excludes forms contained in the lambda-list, since "body of
    the method" is explicitly defined in the documentation of DEFMETHOD.
    Personally I think that was a poor design decision.

    Current practice:  PCL appears to allow call-next-method in forms in the
    lambda-list.  Flavors doesn't allow continue-whopper in forms in the
    lambda-list, although there is no reason why it couldn't.

I rewrote PCL to allow this because I remembered us having a long
discussion during which we decided this was the desired behavior. 
So, I am surprised to see that the spec doesn't say this is right.
-------

∂03-Aug-89  1115	Common-Lisp-Object-System-mailer 	Re: call-next-method incoherency    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Aug 89  11:15:31 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 03 AUG 89 10:58:53 PDT
Date: Thu, 3 Aug 89 10:56 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: call-next-method incoherency
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Common-Lisp-Object-System@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-7.text.newest
In-Reply-To: <19890725144640.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890803175625.3.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no

It would be nice to have a one or two page list of all the changes that
have been made to CLOS since we voted 88-002R.  Something that collects
up, in one place, everything that will be different about what appears
in the draft standard from 88-002R.

Does one of us already have such a list?
-------

∂03-Aug-89  1134	Common-Lisp-Object-System-mailer 	Re: call-next-method incoherency    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 3 Aug 89  11:34:25 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 635936; 3 Aug 89 14:36:20 EDT
Date: Thu, 3 Aug 89 14:36 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: call-next-method incoherency
To: Common-Lisp-Object-System@sail.stanford.edu
In-Reply-To: <19890803175625.3.GREGOR@SPIFF.parc.xerox.com>
Message-ID: <19890803183629.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 3 Aug 89 10:56 PDT
    From: Gregor.pa@Xerox.COM

    It would be nice to have a one or two page list of all the changes that
    have been made to CLOS since we voted 88-002R.  Something that collects
    up, in one place, everything that will be different about what appears
    in the draft standard from 88-002R.

    Does one of us already have such a list?

I don't, although I did make a list of all the cleanup issues that appear
to affect CLOS, which is enclosed below.  I believe changes like this are
supposed to be flagged in the draft of the Common Lisp specification, so
a list could be constructed that way.  The one or two that I did were
mailed to this mailing list.

This is the list of X3J13 issues I found that affect CLOS.  I can't
prove that I didn't miss any.

There should be one saying that FUNCTION, HASH-TABLE, etc. have been made
into classes, but I couldn't find it.  Maybe they forgot to do that.
However, the draft ANSI CL spec does have these as classes.

CLOS-MACRO-COMPILATION  should be no impact, but be careful about DEFINE-METHOD-COMBINATION
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS  the CLOS part was removed by amendment, so ignore this
DATA-TYPES-HIERARCHY-UNDERSPECIFIED, FUNCTION-TYPE -- just background
DESCRIBE-UNDERSPECIFIED
FUNCTION-NAME  probably does not contradict 88-002R, but check it
LOAD-OBJECTS
REAL-NUMBER-TYPE
SYMBOL-MACROLET-DECLARE
SYMBOL-MACROLET-SEMANTICS
SYNTACTIC-ENVIRONMENT-ACCESS -- as it relates to SYMBOL-MACROLET
TYPE-OF-UNDERCONSTRAINED
UNDEFINED-VARIABLES-AND-FUNCTIONS

∂03-Aug-89  1333	Common-Lisp-Object-System-mailer 	CLOS changes    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 3 Aug 89  13:33:45 PDT
Received: by ti.com id AA08210; Thu, 3 Aug 89 15:34:10 CDT
Received: from Kelvin by tilde id AA24773; Thu, 3 Aug 89 15:26:08 CDT
Message-Id: <2827164387-5553656@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 3 Aug 89  15:26:27 EDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Gregor.pa@Xerox.COM
Cc: Common-Lisp-Object-System@sail.stanford.edu
Subject: CLOS changes
In-Reply-To: Msg of Thu, 3 Aug 89 10:56 PDT from Gregor.pa@Xerox.COM

> It would be nice to have a one or two page list of all the changes that
> have been made to CLOS since we voted 88-002R.  Something that collects
> up, in one place, everything that will be different about what appears
> in the draft standard from 88-002R.
> 
> Does one of us already have such a list?
> -------

Here's what I had written for our users:


  This section lists changes to the specification that have been adopted by the ANSI
  Common Lisp committee since the June 1988 edition of the CLOS specification.

  The forms symbol-macrolet, with-slots, and with-accessors will accept
  declarations at the beginning of the body.  In particular, type declarations may be
  given for the variables being defined.  For example,
        (with-slots (n) object (declare (integer n)) (foo n))
  is equivalent to:  (foo (the integer (slot-value object 'n))) .

  Within the body of symbol-macrolet, with-slots, and with-accessors, the variables 
  defined can be altered by psetq and multiple-value-setq besides setq and setf.

  When the compiler encounters an instance or structure that needs to be written to the
  object file as a constant, it calls the generic function make-load-form to find out
  what to do.  make-load-form is called with the object as its argument; it is expected
  to return a form which is to be written to the file and evaluated by the loader to
  create the object.  In order to handle recursive data structures, two values may be
  returned, the first being a form to be evaluated to allocate the object and the second
  value being a form to be evaluated to finish initializing the object.  The first form
  should return the object created; the second form can refer to the object as one of its
  arguments; the value returned by the second form is not used.  Users can write
  methods for make-load-form to enable writing instances of their classes.
  
  Function symbol-function will continue to work only for symbols; to reference the
  definition of a (setf ...) function, use function fdefinition.

  Functions named (setf symbol) can be defined by defun, flet and labels as well as
  by defgeneric, generic-flet and generic-labels.

  Instead of making describe a generic function, describe will call the generic
  function describe-object with two arguments -- the object and the output stream.
  Users can then write methods for describe-object.  Note that this parallels the
  relationship between print and print-object.

  symbol-macrolet has been changed from a macro to a special form.  When this
  change is made, the second example on page 2-81 will no longer be valid because
  macroexpand will expand a symbol defined by symbol-macrolet.

∂03-Aug-89  1732	Common-Lisp-Object-System-mailer 	MOP slot definition questions  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 3 Aug 89  17:32:40 PDT
Received: by ti.com id AA09991; Thu, 3 Aug 89 19:33:32 CDT
Received: from Kelvin by tilde id AA29408; Thu, 3 Aug 89 19:17:19 CDT
Message-Id: <2827178271-777909@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 3 Aug 89  19:17:51 EDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Gregor.pa@Xerox.COM
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu
Subject: MOP slot definition questions

A couple more problems with document 89-003:

Page 3-91 says that methods should be defined for generic functions
SLOT-DEFINITION-NAME, SLOT-DEFINITION-INITFORM, etc.  on class
SLOT-DEFINITION, but page 3-71 says that these items are initialized by
a SHARED-INITIALIZE method on class STANDARD-SLOT-DEFINITION.  This is
inconsistent.  I believe that page 3-91 should specify that these
methods are on class STANDARD-SLOT-DEFINITION.  Likewise, the primary
methods for SLOT-DEFINITION-READERS and SLOT-DEFINITION-WRITERS at the
bottom of the page should be on class STANDARD-DIRECT-SLOT-DEFINITION.

In the implementation of DEFCLASS, page 3-15 says that ENSURE-CLASS will
be called with the :SLOTS argument being a list of "canonicalized slot
definitions", which are lists, as described on page 3-14.  The description
of ENSURE-CLASS on page 3-48 doesn't mention :SLOTS; presumably they are
passed through unchanged to ENSURE-CLASS-USING-CLASS.  The description of
ENSURE-CLASS-USING-CLASS does not explicitly mention :SLOTS, but says on
page 3-51 that "All other keyword arguments are included directly in the
initialization arguments." Page 3-62 says that INITIALIZE-INSTANCE doesn't
do anything special for classes.  Page 3-63 says that the :SLOTS argument
for the SHARED-INITIALIZE method "is a list of direct slot definition
objects.  ...  An error is signalled if ...  any element of this argument
is not of type DIRECT-SLOT-DEFINITION." So this chain of events is begun
by passing in a list, and we expect to receive an object at the end, but
nobody is specified to perform that conversion.  The call graph shows
SHARED-INITIALIZE calling something called DIRECT-SLOT-DEFINITION-CLASS,
which suggests that the call to MAKE-INSTANCE should be done at that
level, although I can't find any reference to DIRECT-SLOT-DEFINITION-CLASS
in the document.  Doing it in SHARED-INITIALIZE would make sense, but that
would mean that page 3-63 is wrong.  Can someone enlighten me on what
the intent was?

∂03-Aug-89  1732	Common-Lisp-Object-System-mailer 	MOP slot definition questions  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 3 Aug 89  17:32:37 PDT
Received: by ti.com id AA09990; Thu, 3 Aug 89 19:33:32 CDT
Received: from Kelvin by tilde id AA29408; Thu, 3 Aug 89 19:17:19 CDT
Message-Id: <2827178271-777909@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 3 Aug 89  19:17:51 EDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Gregor.pa@Xerox.COM
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu
Subject: MOP slot definition questions

A couple more problems with document 89-003:

Page 3-91 says that methods should be defined for generic functions
SLOT-DEFINITION-NAME, SLOT-DEFINITION-INITFORM, etc.  on class
SLOT-DEFINITION, but page 3-71 says that these items are initialized by
a SHARED-INITIALIZE method on class STANDARD-SLOT-DEFINITION.  This is
inconsistent.  I believe that page 3-91 should specify that these
methods are on class STANDARD-SLOT-DEFINITION.  Likewise, the primary
methods for SLOT-DEFINITION-READERS and SLOT-DEFINITION-WRITERS at the
bottom of the page should be on class STANDARD-DIRECT-SLOT-DEFINITION.

In the implementation of DEFCLASS, page 3-15 says that ENSURE-CLASS will
be called with the :SLOTS argument being a list of "canonicalized slot
definitions", which are lists, as described on page 3-14.  The description
of ENSURE-CLASS on page 3-48 doesn't mention :SLOTS; presumably they are
passed through unchanged to ENSURE-CLASS-USING-CLASS.  The description of
ENSURE-CLASS-USING-CLASS does not explicitly mention :SLOTS, but says on
page 3-51 that "All other keyword arguments are included directly in the
initialization arguments." Page 3-62 says that INITIALIZE-INSTANCE doesn't
do anything special for classes.  Page 3-63 says that the :SLOTS argument
for the SHARED-INITIALIZE method "is a list of direct slot definition
objects.  ...  An error is signalled if ...  any element of this argument
is not of type DIRECT-SLOT-DEFINITION." So this chain of events is begun
by passing in a list, and we expect to receive an object at the end, but
nobody is specified to perform that conversion.  The call graph shows
SHARED-INITIALIZE calling something called DIRECT-SLOT-DEFINITION-CLASS,
which suggests that the call to MAKE-INSTANCE should be done at that
level, although I can't find any reference to DIRECT-SLOT-DEFINITION-CLASS
in the document.  Doing it in SHARED-INITIALIZE would make sense, but that
would mean that page 3-63 is wrong.  Can someone enlighten me on what
the intent was?

∂04-Aug-89  0906	Common-Lisp-Object-System-mailer 	CLOS changes    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Aug 89  09:06:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 636580; 4 Aug 89 12:08:23 EDT
Date: Fri, 4 Aug 89 12:08 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: CLOS changes
To: Common-Lisp-Object-System@sail.stanford.edu
In-Reply-To: <19890803183629.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890804160840.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 3 Aug 89 14:36 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	Date: Thu, 3 Aug 89 10:56 PDT
	From: Gregor.pa@Xerox.COM

	It would be nice to have a one or two page list of all the changes that
	have been made to CLOS since we voted 88-002R.

    I believe changes like this are
    supposed to be flagged in the draft of the Common Lisp specification, so
    a list could be constructed that way.  The one or two that I did were
    mailed to this mailing list.

Here is a summary of the changes that I made while reviewing some of the
CLOS function pages (other than strictly grammatical type improvements).
I might have made some changes while reviewing the Types section (2.2)
but it's too long ago to remember.  Those would have been only changes
to make it reflect cleanup issues that had been passed.

Clarify that the arguments to CALL-METHOD are not evaluated.

If the invocation of call-method is lexically inside of a make-method,
the arguments are those that were supplied to that method.  Otherwise
the arguments are those that were supplied to the generic function.

Clarify where MAKE-METHOD can be used.

The form used with make-method is evaluated in the null lexical
environment augmented with a local macro definition for call-method and
with bindings named by symbols not accessible from the common-lisp-user
package.

The second argument to CALL-METHOD is now optional.

Changed the value returned by DEFINE-METHOD-COMBINATION from a method
combination object [which doesn't make any sense] to the name argument.

In DEFINE-METHOD-COMBINATION:
The effective method is evaluated in the null lexical environment
augmented with a local macro definition for call-method and with
bindings named by symbols not accessible from the common-lisp-user
package.

Rewrote the description of the :ARGUMENTS option to
DEFINE-METHOD-COMBINATION to clarify how mismatch between these
arguments and the generic function's arguments is handled, and
to forbid modifying the arguments.

∂11-Aug-89  1037	Common-Lisp-Object-System-mailer 	Re: call-next-method 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 11 Aug 89  10:37:31 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 640350; 11 Aug 89 13:39:21 EDT
Date: Fri, 11 Aug 89 13:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: call-next-method
To: Gregor.pa@Xerox.COM
cc: Gail Zacharias <gz@spt.entity.com>, common-lisp-object-system@sail.stanford.edu
In-Reply-To: <19890728184745.0.GREGOR@SPIFF.parc.xerox.com>
Message-ID: <19890811173950.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: Fri, 28 Jul 89 11:47 PDT
    From: Gregor.pa@Xerox.COM

	Date: Thu, 27 Jul 89 12:06 EDT
	From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	The documentation everywhere says "in the body of a method", which
	presumably excludes forms contained in the lambda-list, since "body of
	the method" is explicitly defined in the documentation of DEFMETHOD.
	Personally I think that was a poor design decision.

	Current practice:  PCL appears to allow call-next-method in forms in the
	lambda-list.  Flavors doesn't allow continue-whopper in forms in the
	lambda-list, although there is no reason why it couldn't.

    I rewrote PCL to allow this because I remembered us having a long
    discussion during which we decided this was the desired behavior. 
    So, I am surprised to see that the spec doesn't say this is right.

Tentatively, Symbolics' review comments on the draft that has not yet
been distributed for X3J13 review will say that this ought to be changed.

∂18-Aug-89  1338	Common-Lisp-Object-System-mailer 	define-method-combination examples  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 18 Aug 89  13:38:24 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.2-cs)
	id AA22033; Fri, 18 Aug 89 14:39:08 -0600
Received: by defun.utah.edu (5.61/utah-2.2-leaf)
	id AA02387; Fri, 18 Aug 89 14:39:05 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8908182039.AA02387@defun.utah.edu>
Date: Fri, 18 Aug 89 14:39:03 MDT
Subject: define-method-combination examples
To: common-lisp-object-system@sail.stanford.edu

I have been trying to figure out how the long form of
DEFINE-METHOD-COMBINATION works.  The examples in the spec use a
function called MAKE-METHOD, which does not seem to be defined
anywhere.  Was this an oversight?  Can somebody supply a definition
for this function, or rewritten examples that don't rely on it? 

-Sandra
-------

∂18-Aug-89  1346	Common-Lisp-Object-System-mailer 	define-method-combination examples  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 18 Aug 89  13:46:45 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA08276g; Fri, 18 Aug 89 13:47:10 PDT
Received: by challenger id AA05606g; Fri, 18 Aug 89 13:44:19 PDT
Date: Fri, 18 Aug 89 13:44:19 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8908182044.AA05606@challenger>
To: sandra%defun@cs.utah.edu
Cc: common-lisp-object-system@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Fri, 18 Aug 89 14:39:03 MDT <8908182039.AA02387@defun.utah.edu>
Subject: define-method-combination examples


   From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
   Date: Fri, 18 Aug 89 14:39:03 MDT

   I have been trying to figure out how the long form of
   DEFINE-METHOD-COMBINATION works.  The examples in the spec use a
   function called MAKE-METHOD, which does not seem to be defined
   anywhere.  Was this an oversight?  Can somebody supply a definition
   for this function, or rewritten examples that don't rely on it? 

   -Sandra
   -------


make-method is not a function, but a special marker in the list given to
call-method. Look at the definition of call-method(2-11) for more detail.

Patrick.

∂21-Aug-89  1733	Common-Lisp-Object-System-mailer 	ENSURE-CLASS-USING-CLASS  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 21 Aug 89  17:33:00 PDT
Received: by ti.com id AA14899; Mon, 21 Aug 89 19:34:28 CDT
Received: from dsg by tilde id AA12587; Mon, 21 Aug 89 19:16:57 CDT
Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 21 Aug 89  19:16:39 CDT
Message-Id: <2828736971-10348264@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 21 Aug 89  19:16:11 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Common-Lisp-Object-System@SAIL.Stanford.edu
Subject: ENSURE-CLASS-USING-CLASS

CLOS folks,

I've got another problem with the Meta Object Protocol.  In 89-003, the
description of ENSURE-CLASS-USING-CLASS and initialization of class objects
says that the class name argument of ENSURE-CLASS-USING-CLASS is not
passed to MAKE-INSTANCE.  An anonymous class object is created, and then
ENSURE-CLASS-USING-CLASS uses (SETF CLASS-NAME) and (SETF FIND-CLASS) to
give it a name and install it.  I had wondered why not just include a
:NAME argument in the initialization arguments for MAKE-INSTANCE, but I
didn't find any reason why the initialization code would have to have the
name.  However, that's only for creating an instance of STANDARD-CLASS.
For other metaclasses, the name may be required.

The example that I have run into is trying to use the meta object protocol
to define classes which are really old flavors.  The SHARED-INITIALIZE
method is supposed to install the new class in the class hierarchy, but
since old flavors has no concept of anonymous flavors, it is impossible to
do the equivalent of ADD-DIRECT-SUBCLASS without knowing the name of the
flavor.

Therefore, I believe that the present model is not general enough and a
:NAME argument needs to be added to the class initialization arguments.

Another advantage of this change is that if function
(SETF CLASS-NAME) is not needed by ENSURE-CLASS-USING-CLASS, then a call
to (SETF CLASS-NAME) is a change rather than an initialization, and it
becomes possible for certain metaclasses to disallow this.  For example, I
want to signal an error if a user tries to change the name of a flavor
class.