perm filename CLOOPS.2[COM,LSP] blob sn#838777 filedate 1987-04-16 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00784 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00110 00002	∂04-Sep-86  2153	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Whoppers and run-super
C00132 00003	∂04-Sep-86  2226	Owners-commonloopscore↑.pa@Xerox.COM 	Varia       
C00138 00004	∂05-Sep-86  1637	Bobrow.pa@Xerox.COM 	Re: Defmethod syntax proposal
C00143 00005	∂05-Sep-86  1637	Owners-commonloopscore↑.pa@Xerox.COM 	Varia    [what a useless subject!]   
C00151 00006	∂05-Sep-86  1637	Bobrow.pa@Xerox.COM 	Re: Message selection, continued  
C00159 00007	∂05-Sep-86  1638	Owners-commonloopscore↑.pa@Xerox.COM 	Re: Varia    [what a useless subject!]    
C00162 00008	∂05-Sep-86  1836	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Re: Defmethod syntax proposal   
C00167 00009	∂05-Sep-86  1836	Owners-commonloopscore↑.pa@Xerox.COM 	Terminology: instances
C00170 00010	∂05-Sep-86  1902	Bobrow.pa@Xerox.COM 	[Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>:   
C00193 00011	∂05-Sep-86  1955	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Methods Selected by Predications More General Than Classes    
C00203 00012	∂08-Sep-86  1458	RPG   	Re: Defmethod syntax proposal    
C00207 00013	∂08-Sep-86  1500	RPG   	Re: Defmethod syntax proposal    
C00212 00014	∂08-Sep-86  1500	RPG   	Class versus Type System    
C00218 00015	∂08-Sep-86  1529	RPG   	Re: Methods Selected by Predications More General Than Classes 
C00223 00016	∂08-Sep-86  1533	RPG   	Class versus Type System    
C00228 00017	∂08-Sep-86  1535	RPG   	Generic Functions Defined by Defmethod     
C00234 00018	∂08-Sep-86  1537	RPG   	Re: Defmethod syntax proposal    
C00238 00019	∂08-Sep-86  1654	RPG   	Re: Defmethod syntax proposal    
C00241 00020	∂08-Sep-86  1654	RPG   	Generic Functions Defined by Defmethod     
C00244 00021	∂08-Sep-86  1727	RPG   	Re: Defmethod syntax proposal    
C00248 00022	∂08-Sep-86  1728	RPG   	Class versus Type System    
C00253 00023	∂09-Sep-86  2035	RPG   	Re: Subtypep 
C00255 00024	∂09-Sep-86  2244	RPG   	Re: Summary of features we all agree on    
C00285 00025	∂09-Sep-86  2244	RPG   	lack of word from the west coast 
C00287 00026	∂09-Sep-86  2324	RPG   	Class-of Versus Type-of     
C00290 00027	∂09-Sep-86  2336	RPG   	Things on which we agree    
C00295 00028	∂10-Sep-86  0837	RPG   	Re: [Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>:   
C00298 00029	∂10-Sep-86  0837	RPG   	Re: Subtypep 
C00300 00030	∂10-Sep-86  1730	RPG   	Getting together to work    
C00302 00031	∂11-Sep-86  1057	RPG   	Things on which we agree    
C00311 00032	∂11-Sep-86  1100	RPG   	Re: Things on which we agree
C00316 00033	∂11-Sep-86  1103	RPG   	Re: Things on which we agree
C00321 00034	∂11-Sep-86  1532	RPG   	Whoppers and Ontology       
C00326 00035	∂11-Sep-86  1610	RPG   	Re: Things on which we agree
C00332 00036	∂12-Sep-86  0805	RPG   	specifying metaclass etc.   
C00334 00037	∂12-Sep-86  0812	RPG   	Re: Defmethod syntax proposal    
C00341 00038	∂12-Sep-86  1106	RPG   	Defmethod Syntax       
C00345 00039	∂12-Sep-86  1108	RPG   	Re: Defmethod syntax proposal    
C00349 00040	∂12-Sep-86  1245	RPG   	Re: Defmethod syntax proposal    
C00358 00041	∂12-Sep-86  1248	RPG   	Whoppers and Phenomenology  
C00367 00042	∂12-Sep-86  1545	RPG   	ordering of defclasses 
C00371 00043	∂12-Sep-86  1657	RPG   	Re: Defmethod syntax proposal    
C00378 00044	∂12-Sep-86  1752	RPG   	ordering of defclasses 
C00382 00045	∂12-Sep-86  1756	RPG   	Getting together to work    
C00387 00046	∂13-Sep-86  2051	RPG   	Defmethod syntax  
C00397 00047	∂13-Sep-86  2100	RPG   	abbreviated form of WITH    
C00401 00048	∂13-Sep-86  2101	RPG   	Re: Defmethod syntax   
C00403 00049	∂14-Sep-86  1112	Gregor.pa@Xerox.COM 	Re: Getting together to work 
C00405 00050	∂14-Sep-86  1118	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: ordering of defclasses 
C00408 00051	∂14-Sep-86  1622	Gregor.pa@Xerox.COM 	Method Naming and Identity Proposal    
C00410 00052	∂14-Sep-86  1817	Gregor.pa@Xerox.COM 	default optional arguments to a generic function 
C00416 00053	∂14-Sep-86  1837	Owners-commonloopscore↑.pa@Xerox.COM 	Method Identification      
C00418 00054	∂15-Sep-86  1152	Owners-commonloopscore↑.pa@Xerox.COM 	Method Identification      
C00421 00055	∂15-Sep-86  1152	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Re: Defmethod syntax  
C00424 00056	∂15-Sep-86  1152	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Method Naming and Identity Proposal  
C00429 00057	∂15-Sep-86  1437	Owners-CommonLoopsCore↑.pa@Xerox.COM 	default optional arguments to a generic function    
C00442 00058	∂15-Sep-86  1436	Masinter.pa@Xerox.COM 	Re: Defmethod syntax  
C00445 00059	∂15-Sep-86  1436	Owners-commonloopscore↑.pa@Xerox.COM 	Goals of the Specification      
C00448 00060	∂15-Sep-86  1615	Owners-commonloopscore↑.pa@Xerox.COM 	Goals of the Specification      
C00453 00061	∂15-Sep-86  1743	Masinter.pa@Xerox.COM 	Re: Goals of the Specification       
C00456 00062	∂15-Sep-86  2005	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Defmethod syntax 
C00458 00063	∂15-Sep-86  2101	Owners-CommonLoopsCore↑.pa@Xerox.COM 	default optional arguments to a generic function    
C00469 00064	∂16-Sep-86  0626	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Proposed Goals (Statement for OOPSLA)
C00481 00065	/sub
C00493 00066	∂16-Sep-86  0630	Owners-commonloopscore↑.pa@Xerox.COM 	Re: Goals of the Specification       
C00497 00067	∂16-Sep-86  1128	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: default optional arguments to a generic function
C00502 00068	∂16-Sep-86  1413	Gregor.pa@Xerox.COM 	the kinds of method lookup people claim they want
C00508 00069	∂16-Sep-86  1841	Owners-CommonLoopsCore↑.pa@Xerox.COM 	run-super   
C00524 00070	∂16-Sep-86  1841	Owners-CommonLoopsCore↑.PA@Xerox.COM 	What we should agree on before OOPSLA
C00529 00071	∂17-Sep-86  0856	Bobrow.pa@Xerox.COM 	Re: run-super 
C00535 00072	∂17-Sep-86  1036	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: default optional arguments to a generic function
C00543 00073	∂17-Sep-86  1037	Kahn.pa@Xerox.COM 	Re: run-super   
C00546 00074	∂17-Sep-86  1037	Kahn.pa@Xerox.COM 	DEFCLASS should replace DEFSTRUCT   
C00550 00075	∂17-Sep-86  1632	Gregor.pa@Xerox.COM 	Re: What we should agree on before OOPSLA   
C00553 00076	∂17-Sep-86  1636	Gregor.pa@Xerox.COM 	The name of WITH   
C00554 00077	∂17-Sep-86  1637	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: Getting together to work    
C00557 00078	∂17-Sep-86  1636	Bobrow.pa@Xerox.COM 	Proposed Goals (Statement for OOPSLA)  
C00569 00079	∂17-Sep-86  1636	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: default optional arguments to a generic function
C00586 00080	∂17-Sep-86  1636	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: run-super, whoppers, wrappers    
C00604 00081	∂17-Sep-86  1636	Gregor.pa@Xerox.COM 	required-xxx options to defclass  
C00607 00082	∂17-Sep-86  2028	Owners-CommonLoopsCore↑.pa@Xerox.COM 	DEFCLASS should replace DEFSTRUCT    
C00610 00083	∂17-Sep-86  2029	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: run-super    
C00615 00084	∂17-Sep-86  2029	Masinter.pa@Xerox.COM 	Re: DEFCLASS should replace DEFSTRUCT
C00620 00085	∂17-Sep-86  2031	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Proposed Goals (Statement for OOPSLA)
C00624 00086	∂17-Sep-86  2224	Owners-CommonLoopsCore↑.pa@Xerox.COM 	The name of WITH 
C00626 00087	∂17-Sep-86  2224	Owners-CommonLoopsCore↑.pa@Xerox.COM 	required-xxx options to defclass
C00629 00088	∂18-Sep-86  0625	Owners-CommonLoopsCore↑.pa@Xerox.COM 	The name of WITH 
C00632 00089	∂18-Sep-86  0811	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Proposed Goals (Statement for OOPSLA)
C00650 00090	∂18-Sep-86  0900	Bobrow.pa@Xerox.COM 	Re: The name of WITH    
C00656 00091	∂18-Sep-86  0900	Bobrow.pa@Xerox.COM 	Re: DEFCLASS should replace DEFSTRUCT  
C00659 00092	∂18-Sep-86  1100	Owners-commonloopscore↑.pa@Xerox.COM 	DEFCLASS should replace DEFSTRUCT    
C00662 00093	∂18-Sep-86  1100	Owners-commonloopscore↑.pa@Xerox.COM 	Proposed Goals (Statement for OOPSLA)     
C00666 00094	∂18-Sep-86  1100	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: The name of WITH  
C00671 00095	∂18-Sep-86  1306	Owners-CommonLoopsCore↑.pa@Xerox.COM 	WITH-SLOTS  
C00675 00096	∂18-Sep-86  1306	Owners-CommonLoops.pa@Xerox.COM 	common loops for franz
C00677 00097	∂18-Sep-86  1724	RPG   	Proposed Goals (Statement for OOPSLA)      
C00681 00098	∂18-Sep-86  1724	RPG   	DEFCLASS should replace DEFSTRUCT     
C00684 00099	∂18-Sep-86  2312	Masinter.pa@Xerox.COM 	Re: The name of WITH  
C00686 00100	∂18-Sep-86  2312	Owners-CommonLoops.pa@Xerox.COM 	FTP problems.    
C00689 00101	∂18-Sep-86  2312	Masinter.pa@Xerox.COM 	Re: DEFCLASS should replace DEFSTRUCT     
C00693 00102	∂18-Sep-86  2313	Owners-CommonLoops.pa@Xerox.COM 	Re: common loops for franz 
C00695 00103	∂18-Sep-86  2313	Masinter.pa@Xerox.COM 	Re: FTP problems.
C00696 00104	∂18-Sep-86  2313	Bobrow.pa@Xerox.COM 	Re: Proposed Goals (Statement for OOPSLA)   
C00698 00105	∂19-Sep-86  0806	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Re: Summary of features we all agree on   
C00705 00106	∂19-Sep-86  0944	Bobrow.pa@Xerox.COM 	Re: Summary of features we all agree on
C00708 00107	∂19-Sep-86  1132	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Re: Summary of features we all agree on   
C00714 00108	∂19-Sep-86  1132	Kahn.pa@Xerox.COM 	Short names like MAKE
C00717 00109	∂20-Sep-86  1132	Owners-commonloopscore↑.pa@Xerox.COM 	Short Names      
C00720 00110	∂21-Sep-86  1230	masinter.PA@Xerox.COM 	mutable vs immutable generic functions    
C00724 00111	∂21-Sep-86  1355	Bobrow.pa@Xerox.COM 	Syntax of DEFCLASS 
C00727 00112	∂21-Sep-86  1433	Owners-CommonLoopsCore↑.PA@Xerox.COM 	mutable vs immutable generic functions    
C00736 00113	∂21-Sep-86  1529	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Syntax of DEFCLASS    
C00746 00114	∂21-Sep-86  1537	MASINTER.PA@Xerox.COM 	(change-class x y) => (setf (class-of x) y)?   
C00748 00115	∂21-Sep-86  1540	Bobrow.pa@Xerox.COM 	Generic Function Objects
C00752 00116	∂21-Sep-86  1553	MASINTER.PA@Xerox.COM 	make vs make-instance 
C00754 00117	∂21-Sep-86  1615	Bobrow.pa@Xerox.COM 	Re: (change-class x y) => (setf (class-of x) y)? 
C00756 00118	∂21-Sep-86  1638	Kahn.pa@Xerox.COM 	Re: Short Names      
C00758 00119	∂21-Sep-86  1717	Kahn.pa@Xerox.COM 	Re: (change-class x y) => (setf (class-of x) y)?   
C00761 00120	∂21-Sep-86  1725	Kahn.pa@Xerox.COM 	Re: default optional arguments to a generic function    
C00765 00121	∂21-Sep-86  1812	Bobrow.pa@Xerox.COM 	default optional arguments to a generic function 
C00773 00122	∂21-Sep-86  1925	Bobrow.pa@Xerox.COM 	Class Precedence List   
C00776 00123	∂21-Sep-86  2233	MASINTER.PA@Xerox.COM 	initial class lattice 
C00780 00124	∂22-Sep-86  0123	MASINTER.PA@Xerox.COM 	another name for "run-super"    
C00781 00125	∂22-Sep-86  0829	Owners-commonloopscore↑.PA@Xerox.COM 	another name for "run-super"    
C00784 00126	∂22-Sep-86  0916	Owners-commonloopscore↑.PA@Xerox.COM 	initial class lattice 
C00798 00127	∂22-Sep-86  1024	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Class Precedence List 
C00806 00128	∂22-Sep-86  1025	Bobrow.pa@Xerox.COM 	Re: Class Precedence List    
C00810 00129	∂22-Sep-86  1130	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Generic Function Objects   
C00816 00130	∂22-Sep-86  1132	Gregor.pa@Xerox.COM 	Re: Class Precedence List    
C00818 00131	∂22-Sep-86  1300	Gregor.pa@Xerox.COM 	Re: Generic Function Objects 
C00820 00132	∂22-Sep-86  1410	masinter.pa@Xerox.COM 	Re: initial class lattice  
C00825 00133	∂22-Sep-86  1410	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: Class Precedence List  
C00829 00134	∂22-Sep-86  1510	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: Generic Function Objects    
C00833 00135	∂22-Sep-86  1511	masinter.pa@Xerox.COM 	Re: Syntax of DEFCLASS
C00840 00136	∂22-Sep-86  1628	Owners-commonloopscore↑.PA@Xerox.COM 	Re: initial class lattice  
C00844 00137	∂22-Sep-86  1757	Owners-CommonLoopsCore↑.pa@Xerox.COM 	default optional arguments to a generic function    
C00855 00138	∂22-Sep-86  1814	masinter.pa@Xerox.COM 	Re: default optional arguments to a generic function
C00860 00139	∂22-Sep-86  2229	MASINTER.pa@Xerox.COM 	class-of compiled objects  
C00862 00140	∂22-Sep-86  2236	MASINTER.pa@Xerox.COM 	generic function objects   
C00864 00141	∂23-Sep-86  0859	Owners-commonloopscore↑.pa@Xerox.COM 	class-of compiled objects  
C00867 00142	∂23-Sep-86  0902	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Name of RUN-SUPER
C00870 00143	∂23-Sep-86  1354	Owners-commonloopscore↑.PA@Xerox.COM 	Re: initial class lattice  
C00874 00144	∂24-Sep-86  2021	Owners-commonloopscore↑.PA@Xerox.COM 	Re: (change-class x y) => (setf (class-of x) y)?    
C00878 00145	∂24-Sep-86  2037	Owners-commonloopscore↑.PA@Xerox.COM 	Re: (change-class x y) => (setf (class-of x) y)?    
C00880 00146	∂25-Sep-86  0809	Bobrow.pa@Xerox.COM 	Re: Class Precedence List    
C00882 00147	∂25-Sep-86  0810	Bobrow.pa@Xerox.COM 	[Guy Steele <gls@Think.COM>: Syntax of defstruct  versus   
C00886 00148	∂25-Sep-86  1229	masinter.pa@Xerox.COM 	Re: (change-class x y) => (setf (class-of x) y)?    
C00889 00149	∂25-Sep-86  1229	masinter.pa@Xerox.COM 	Re: initial class lattice  
C00893 00150	∂25-Sep-86  1358	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: Class Precedence List  
C00897 00151	∂26-Sep-86  0954	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: Class Precedence List  
C00900 00152	∂26-Sep-86  1330	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: Class Precedence List  
C00906 00153	∂26-Sep-86  1635	Gregor.pa@Xerox.COM 	missing excl-low file   
C00908 00154	∂29-Sep-86  1328	Owners-commonloops.pa@Xerox.COM 	getting connected
C00909 00155	∂29-Sep-86  1816	Hostrop.PA@Xerox.COM 	{eris}<Lispcore>...    
C00911 00156	∂30-Sep-86  1701	Owners-CommonLoops.PA@Xerox.COM 	Anybody know how objects are represented in PCL?    
C00913 00157	∂06-Oct-86  1525	Bobrow.pa@Xerox.COM 	Taking the politics out of Standardization  
C00916 00158	∂06-Oct-86  1658	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Taking the politics out of Standardization
C00919 00159	∂06-Oct-86  2038	Owners-CommonLoops.PA@Xerox.COM 	Change of Address
C00921 00160	∂06-Oct-86  2144	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Method Combinations   
C00923 00161	∂07-Oct-86  0245	Owners-CommonLoops.PA@Xerox.COM 	missing excl-low file 
C00925 00162	∂07-Oct-86  0245	Owners-CommonLoops.PA@Xerox.COM 	Anybody know how objects are represented in PCL?    
C00928 00163	∂07-Oct-86  0244	Owners-commonloops.pa@Xerox.COM 	getting connected
C00930 00164	∂07-Oct-86  1626	Gregor.pa@Xerox.COM 	Re: Anybody know how objects are represented in PCL?  
C00933 00165	∂07-Oct-86  1920	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Computing the class precedence list  
C00945 00166	∂08-Oct-86  1514	Bobrow.pa@Xerox.COM 	Re: Method Combinations 
C00947 00167	∂08-Oct-86  1559	Bobrow.pa@Xerox.COM 	Summary of Object Standard Discussions 
C00968 00168	∂08-Oct-86  1817	Owners-commonloopscore↑.pa@Xerox.COM 	new files on CLS,LSP on SAIL    
C00972 00169	∂09-Oct-86  1505	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Summary of Object Standard Discussions    
C00987 00170	∂09-Oct-86  1544	Owners-commonloopscore↑.pa@Xerox.COM 	Summary of Object Standard Discussions    
C00992 00171	∂09-Oct-86  1615	Owners-commonloopscore↑.pa@Xerox.COM 	"Classes" Document and Agreements Summary 
C01005 00172	∂09-Oct-86  1637	RPG   	Summary of Object Standard Discussions
C01020 00173	∂09-Oct-86  1709	Bobrow.pa@Xerox.COM 	Re: Summary of Object Standard Discussions  
C01030 00174	∂09-Oct-86  1811	Owners-CommonLoopsCore↑.PA@Xerox.COM 	"Classes" Document and Agreements Summary 
C01043 00175	∂10-Oct-86  1601	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Classes document available on SAIL   
C01046 00176	∂10-Oct-86  1601	Bobrow.pa@Xerox.COM 	Computing the class precedence list    
C01049 00177	∂10-Oct-86  1601	Gregor.pa@Xerox.COM 	yaccpla (yet another compute class precedence list algorithm)   
C01055 00178	∂13-Oct-86  1823	RPG  	Greetings
C01056 00179	∂13-Oct-86  1832	Bobrow.pa@Xerox.COM 	Re: Summary of Object Standard Discussions (Repeat of last 
C01066 00180	∂13-Oct-86  2206	LGD  	new object system spec files 
C01067 00181	∂13-Oct-86  2333	Owners-CommonLoopsInternal↑.x@Xerox.COM 	Mailing list addition   
C01069 00182	∂14-Oct-86  0754	skeene@STONY-BROOK.SCRC.Symbolics.COM 	Re: Summary of Object Standard Discussions (Repeat of last   
C01075 00183	∂14-Oct-86  1659	RPG  	Anonymous Generic Function Proposal    
C01080 00184	∂14-Oct-86  1849	Gregor.pa@Xerox.COM 	Re: Anonymous Generic Function Proposal     
C01083 00185	∂15-Oct-86  0751	RPG  	Anonymous Generic Functions  
C01085 00186	∂15-Oct-86  1312	@MC.LCS.MIT.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COM 	"Classes" Document and Agreements Summary 
C01089 00187	∂15-Oct-86  1503	Bobrow.pa@Xerox.COM 	Method Combination 
C01098 00188	∂15-Oct-86  1602	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re: Anonymous Generic Function Proposal        
C01100 00189	∂15-Oct-86  1602	DLW@ALDERAAN.SCRC.Symbolics.COM 	Anonymous Generic Functions     
C01104 00190	∂15-Oct-86  1635	Masinter.pa@Xerox.COM 	Re: Anonymous Generic Functions      
C01106 00191	∂15-Oct-86  2018	kempf%hplabsc@hplabs.HP.COM 	Re: Anonymous Generic Functions
C01108 00192	∂15-Oct-86  2136	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Method combination -- writeup for revised syntax
C01136 00193	∂16-Oct-86  1118	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Anonymous Generic Function Proposal        
C01139 00194	∂16-Oct-86  1837	Gregor.pa@Xerox.COM 	Anonymous Generic Function Proposal    
C01143 00195	∂16-Oct-86  1922	Masinter.pa@Xerox.COM 	Re: Summary of Object Standard Discussions
C01145 00196	∂16-Oct-86  2044	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Anonymous Generic Function Proposal        
C01148 00197	∂16-Oct-86  2114	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Method Combination
C01169 00198	∂16-Oct-86  2220	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Dispatching on optional/keyword arguments  
C01178 00199	∂17-Oct-86  0515	DLW@ALDERAAN.SCRC.Symbolics.COM 	Anonymous Generic Function Proposal  
C01182 00200	∂17-Oct-86  0948	masinter.PA@Xerox.COM 	Re: Dispatching on optional/keyword arguments  
C01184 00201	∂17-Oct-86  1037	Bobrow.pa@Xerox.COM 	Re: Anonymous Generic Function Proposal
C01187 00202	∂17-Oct-86  1037	Bobrow.pa@Xerox.COM 	Re: Anonymous Generic Function Proposal     
C01191 00203	∂17-Oct-86  1237	kempf%hplabsc@hplabs.HP.COM 	Re: Method Combination    
C01194 00204	∂17-Oct-86  1430	RPG   	Re: Anonymous Generic Function Proposal    
C01196 00205	∂17-Oct-86  1652	Masinter.pa@Xerox.COM 	Re: Dispatching on optional/keyword arguments  
C01198 00206	∂17-Oct-86  1845	@MC.LCS.MIT.EDU:Moon@VALLECITO.SCRC.Symbolics.COM 	"Classes" Document and Agreements Summary   
C01214 00207	∂17-Oct-86  2146	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Computing the class precedence list   
C01221 00208	∂17-Oct-86  2155	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Clarification of declaration requested
C01223 00209	∂17-Oct-86  2157	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Anonymous Generic Function Proposal    
C01225 00210	∂17-Oct-86  2159	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Summary of Object Standard Discussions     
C01231 00211	∂17-Oct-86  2201	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Summary of Object Standard Discussions 
C01236 00212	∂19-Oct-86  1632	Masinter.pa@Xerox.COM 	Re: Summary of Object Standard Discussions     
C01238 00213	∂20-Oct-86  0805	Bobrow.pa@Xerox.COM 	Re: "Classes" Document and Agreements Summary    
C01247 00214	∂20-Oct-86  0921	Bobrow.pa@Xerox.COM 	Re: Computing the class precedence list
C01255 00215	∂20-Oct-86  0928	Bobrow.pa@Xerox.COM 	Re: Summary of Object Standard Discussions  
C01258 00216	∂20-Oct-86  1345	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Dispatching on optional/keyword arguments   
C01261 00217	∂20-Oct-86  1408	Bobrow.pa@Xerox.COM 	Re: Summary of Object Standard Discussions  
C01266 00218	∂20-Oct-86  1455	RPG  	Remarks on Generic Functions 
C01289 00219	∂20-Oct-86  1522	RPG  	Re: Summary of Object Standard Discussions  
C01294 00220	∂20-Oct-86  1759	Bobrow.pa@Xerox.COM 	Re: Method combination -- writeup for revised syntax  
C01305 00221	∂20-Oct-86  1923	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Instance transformation protocol proposal  
C01314 00222	∂21-Oct-86  0703	DLW@ALDERAAN.SCRC.Symbolics.COM 	Instance transformation protocol proposal 
C01317 00223	∂21-Oct-86  0711	RPG   	Re: Remarks on Generic Functions 
C01322 00224	∂21-Oct-86  0928	kempf%hplabsc@hplabs.HP.COM 	Re: Remarks on Generic Functions    
C01329 00225	∂21-Oct-86  1049	Gregor.pa@Xerox.COM 	Instance transformation protocol proposal   
C01333 00226	∂21-Oct-86  1111	DLW@ALDERAAN.SCRC.Symbolics.COM 	Remarks on Generic Functions    
C01337 00227	∂21-Oct-86  1130	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Computing the class precedence list    
C01340 00228	∂21-Oct-86  1220	RPG   	Re: Remarks on Generic Functions      
C01342 00229	∂21-Oct-86  1320	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Summary of Object Standard Discussions 
C01345 00230	∂21-Oct-86  1601	Bobrow.pa@Xerox.COM 	Re: Computing the class precedence list
C01347 00231	∂21-Oct-86  1602	Bobrow.pa@Xerox.COM 	Re: Remarks on Generic Functions  
C01354 00232	∂21-Oct-86  1604	Gregor.pa@Xerox.COM 	Re: Summary of Object Standard Discussions  
C01357 00233	∂21-Oct-86  2302	DUSSUD%Jenner%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: Summary of Object Standard Discussions   
C01360 00234	∂22-Oct-86  1407	RPG  	DEF-GENERIC-OPTIONS
C01367 00235	∂22-Oct-86  1513	Bobrow.pa@Xerox.COM 	Re: DEF-GENERIC-OPTIONS 
C01370 00236	∂23-Oct-86  1835	Masinter.pa@Xerox.COM 	Re: Dispatching on optional/keyword arguments  
C01374 00237	∂23-Oct-86  1836	Masinter.pa@Xerox.COM 	:TYPE in DEFCLASS?    
C01375 00238	∂23-Oct-86  2337	RPG   	Re: DEF-GENERIC-OPTIONS
C01381 00239	∂24-Oct-86  1321	Masinter.pa@Xerox.COM 	Re: Dispatching on optional/keyword arguments  
C01383 00240	∂26-Oct-86  2029	Kahn.pa@Xerox.COM 	Re: Instance transformation protocol proposal 
C01385 00241	∂26-Oct-86  2029	Kahn.pa@Xerox.COM 	Re: Remarks on Generic Functions    
C01388 00242	∂26-Oct-86  2029	Kahn.pa@Xerox.COM 	Re: Anonymous Generic Function Proposal       
C01390 00243	∂26-Oct-86  2029	Kahn.pa@Xerox.COM 	Re: DEF-GENERIC-OPTIONS   
C01393 00244	∂27-Oct-86  1216	Bobrow.pa@Xerox.COM 	Re: Anonymous Generic Function Proposal     
C01396 00245	∂27-Oct-86  1415	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Instance transformation protocol proposal   
C01399 00246	∂27-Oct-86  1510	edsel!bhopal!jonl@navajo.stanford.edu 	Remarks on Generic Functions   
C01409 00247	∂27-Oct-86  1920	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Remarks on Generic Functions     
C01413 00248	∂27-Oct-86  1936	LGD  	new files on [CLS,LSP]  
C01414 00249	∂27-Oct-86  2034	RPG  	Re: Remarks on Generic Functions       
C01419 00250	∂27-Oct-86  2151	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Remarks on Generic Functions           
C01429 00251	∂28-Oct-86  0631	edsel!bhopal!jonl@navajo.stanford.edu 	Remarks on Generic Functions   
C01434 00252	∂28-Oct-86  0631	edsel!bhopal!jonl@navajo.stanford.edu 	Lexical GFLABELS versus "dynamic" GFLABELS    
C01438 00253	∂28-Oct-86  0753	RPG  	GLFET    
C01442 00254	∂28-Oct-86  1112	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Lexical GFLABELS versus "dynamic" GFLABELS 
C01445 00255	∂28-Oct-86  1459	Pavel.pa@xerox.com 	Re: Lexical GFLABELS versus "dynamic" GFLABELS    
C01448 00256	∂28-Oct-86  1931	Moon@STONY-BROOK.SCRC.Symbolics.COM 	new files on [CLS,LSP]      
C01450 00257	∂28-Oct-86  2004	LGD  	printing files
C01452 00258	∂29-Oct-86  0214	DUSSUD@martha 	Re: Instance transformation pr
C01455 00259	∂29-Oct-86  0510	edsel!bhopal!jonl@navajo.stanford.edu 	Lexical GFLABELS versus "dynamic" GFLABELS    
C01460 00260	∂29-Oct-86  0919	kempf%hplabsc@hplabs.HP.COM 	Re:  printing files  
C01462 00261	∂29-Oct-86  1035	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Instance transformation pr   
C01465 00262	∂29-Oct-86  1615	kempf%hplabsc@hplabs.HP.COM 	Re: Local Lexical Generic Functions 
C01467 00263	∂29-Oct-86  1755	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Dispatching on optional/keyword arguments   
C01470 00264	∂30-Oct-86  1333	Moon@STONY-BROOK.SCRC.Symbolics.COM 	new files on [CLS,LSP]      
C01476 00265	∂30-Oct-86  1452	DUSSUD%Jenner%ti-csl.csnet@CSNET-RELAY.ARPA  
C01479 00266	∂30-Oct-86  1728	LGD  	stripped down versions of files   
C01480 00267	∂31-Oct-86  1603	DUSSUD%Jenner%ti-csl.csnet@CSNET-RELAY.ARPA 	A proposal for a finer grained method combination selection.
C01488 00268	∂05-Nov-86  0850	hpfclp!robert@hplabs.HP.COM 	discussion wanted    
C01496 00269	∂05-Nov-86  1255	RPG  	Next Step     
C01497 00270	∂05-Nov-86  2129	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Next Step         
C01501 00271	∂05-Nov-86  2235	Moon@STONY-BROOK.SCRC.Symbolics.COM 	stripped down versions of files       
C01504 00272	∂06-Nov-86  0700	Masinter.pa@Xerox.COM 	Re: discussion wanted 
C01514 00273	∂06-Nov-86  1227	Kahn.pa@Xerox.COM 	Re: discussion wanted
C01517 00274	∂06-Nov-86  1700	masinter.PA@Xerox.COM 	Re: discussion wanted 
C01519 00275	∂08-Nov-86  1319	RPG  	Clarification 
C01521 00276	∂08-Nov-86  1442	kempf%hplabsc@hplabs.HP.COM 	Re:  Clarification   
C01523 00277	∂09-Nov-86  1900	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Clarification     
C01528 00278	∂10-Nov-86  1003	Gregor.pa@Xerox.COM 	Re: Clarification  
C01532 00279	∂10-Nov-86  1224	Bobrow.pa@Xerox.COM 	Re: Clarification  
C01536 00280	∂10-Nov-86  1301	Bobrow.pa@Xerox.COM 	Re: Clarification  
C01538 00281	∂10-Nov-86  1801	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: Clarification  
C01542 00282	∂11-Nov-86  1132	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Draft Comments Part II  
C01547 00283	∂11-Nov-86  1311	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: Method combination -- writeup for revised syntax  
C01550 00284	∂12-Nov-86  0811	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Draft Comments Part I   
C01555 00285	∂12-Nov-86  0820	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Draft Comments
C01558 00286	∂12-Nov-86  1225	Moon@ALDERAAN.SCRC.Symbolics.COM 	Comments on the function chapter    
C01570 00287	∂12-Nov-86  1256	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: Next Step 
C01574 00288	∂12-Nov-86  2241	@MC.LCS.MIT.EDU:MOON%ML.AI.MIT.EDU@MC.LCS.MIT.EDU 	Second installment of comments on Functions chapter   
C01592 00289	∂13-Nov-86  1217	RPG  	ARGUMENT-PRECEDENCE-ORDER    
C01593 00290	∂13-Nov-86  1438	Moon@STONY-BROOK.SCRC.Symbolics.COM 	ARGUMENT-PRECEDENCE-ORDER        
C01596 00291	∂13-Nov-86  1514	masinter.pa@Xerox.COM 	Re: ARGUMENT-PRECEDENCE-ORDER        
C01598 00292	∂14-Nov-86  0047	RPG  	Altering Generic Functions   
C01603 00293	∂14-Nov-86  0951	Gregor.pa@Xerox.COM 	Re: Altering Generic Functions    
C01606 00294	∂14-Nov-86  0951	Gregor.pa@Xerox.COM 	Re: Altering Generic Functions    
C01608 00295	∂14-Nov-86  0950	MASINTER.PA@Xerox.COM 	Re: Altering Generic Functions  
C01610 00296	∂14-Nov-86  1114	masinter.pa@Xerox.COM 	Re: Altering Generic Functions       
C01613 00297	∂14-Nov-86  1626	Bobrow.pa@Xerox.COM 	Re: Altering Generic Functions    
C01616 00298	∂14-Nov-86  1746	RPG  	Altering Things    
C01620 00299	∂14-Nov-86  1806	Gregor.pa@Xerox.COM 	Re: Second installment of comments on Functions chapter    
C01626 00300	∂14-Nov-86  1816	RPG  	Remarks on Moon's Comments   
C01628 00301	∂14-Nov-86  1906	Bobrow.pa@Xerox.COM 	Re: Altering Generic Functions    
C01630 00302	∂14-Nov-86  1906	Bobrow.pa@Xerox.COM 	Re: Altering Things     
C01634 00303	∂14-Nov-86  1906	Gregor.pa@Xerox.COM 	Meeting at X3J13   
C01636 00304	∂14-Nov-86  1906	Bobrow.pa@Xerox.COM 	Re: Remarks on Moon's Comments    
C01638 00305	∂14-Nov-86  2030	Bobrow.pa@Xerox.COM 	Re: Meeting at X3J13    
C01640 00306	∂14-Nov-86  2105	RPG  	Meeting at X3J13   
C01641 00307	∂15-Nov-86  1213	kempf%hplabsc@hplabs.HP.COM 	Re: Meeting at X3J13 
C01643 00308	∂15-Nov-86  1353	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: discussion wanted   
C01648 00309	∂16-Nov-86  1020	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: Meeting at X3J13    
C01650 00310	∂17-Nov-86  1100	Bobrow.pa@Xerox.COM 	Re: Meeting at X3J13    
C01652 00311	∂17-Nov-86  1807	Bobrow.pa@Xerox.COM 	Options of defclass
C01655 00312	∂17-Nov-86  1807	Gregor.pa@Xerox.COM 	change class protocol   
C01662 00313	∂17-Nov-86  1809	Gregor.pa@Xerox.COM 	portable interface to code walker 
C01665 00314	∂18-Nov-86  0738	kempf%hplabsc@hplabs.HP.COM 	Re:  change class protocol
C01667 00315	∂18-Nov-86  0804	kempf%hplabsc@hplabs.HP.COM 	Re:  portable interface to code walker   
C01672 00316	∂18-Nov-86  1026	Gregor.pa@Xerox.COM 	Re:  change class protocol   
C01674 00317	∂18-Nov-86  1026	kahn.pa@Xerox.COM 	Re:  change class protocol
C01676 00318	∂18-Nov-86  1710	kahn.pa@Xerox.COM 	Re: Second installment of comments on Functions chapter 
C01679 00319	∂21-Nov-86  2027	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Options of defclass    
C01685 00320	∂21-Nov-86  2122	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Class precedence list, underconstrained method ordering   
C01695 00321	∂22-Nov-86  1048	RPG  	Options of Defclass
C01697 00322	∂24-Nov-86  1810	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Meeting at X3J13   
C01699 00323	∂25-Nov-86  1339	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: portable interface to code walker  
C01702 00324	∂25-Nov-86  1445	Gregor.pa@Xerox.COM 	:accessor-prefix questions   
C01707 00325	∂26-Nov-86  0819	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: portable interface to code walker  
C01710 00326	∂26-Nov-86  0857	Bobrow.pa@Xerox.COM 	Re: :accessor-prefix questions    
C01713 00327	∂26-Nov-86  0910	Bobrow.pa@Xerox.COM 	"Do it using the meta-object protocol" 
C01715 00328	∂26-Nov-86  0913	Bobrow.pa@Xerox.COM 	Re: Options of defclass 
C01717 00329	∂28-Nov-86  1609	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: portable interface to code walker 
C01721 00330	∂28-Nov-86  1619	Moon@STONY-BROOK.SCRC.Symbolics.COM 	:accessor-prefix questions  
C01730 00331	∂30-Nov-86  1238	Masinter.pa@Xerox.COM 	Re: :accessor-prefix questions  
C01734 00332	∂30-Nov-86  1402	Gregor.pa@Xerox.COM 	Re: :accessor-prefix questions    
C01740 00333	∂30-Nov-86  1737	Gregor.pa@Xerox.COM 	Re: portable interface to code walker  
C01750 00334	∂30-Nov-86  1759	Gregor.pa@Xerox.COM 	initialization protocol strawman  
C01758 00335	∂30-Nov-86  2126	LGD  	new functions.* files on SAIL
C01759 00336	∂01-Dec-86  1100	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: :accessor-prefix questions   
C01765 00337	∂01-Dec-86  1136	edsel!bhopal!jonl@navajo.stanford.edu 	:accessor-prefix questions
C01770 00338	∂01-Dec-86  1326	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: portable interface to code walker 
C01773 00339	∂01-Dec-86  1613	Gregor.pa@Xerox.COM 	Re: portable interface to code walker  
C01777 00340	∂01-Dec-86  1850	Bobrow.pa@Xerox.COM 	Re: Class precedence list, underconstrained method ordering
C01784 00341	∂02-Dec-86  1316	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: portable interface to code walker  
C01786 00342	∂02-Dec-86  1338	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: portable interface to code walker 
C01789 00343	∂02-Dec-86  1631	Gregor.pa@Xerox.COM 	code for compute-class-precedence-list 
C01800 00344	∂02-Dec-86  1921	Bobrow.pa@Xerox.COM 	Re: :accessor-prefix questions    
C01804 00345	∂03-Dec-86  2126	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Comments on the revised function chapter   
C01835 00346	∂05-Dec-86  1035	Gregor.pa@Xerox.COM 	&key &allow-other-keys  
C01837 00347	∂06-Dec-86  0732	masinter.pa@Xerox.COM 	Re: :accessor-prefix questions  
C01841 00348	∂09-Dec-86  1722	Gregor.pa@Xerox.COM 	Re: Comments on the revised function chapter
C01863 00349	∂12-Dec-86  1450	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: :accessor-prefix questions    
C01866 00350	∂12-Dec-86  1911	Bobrow.pa@Xerox.COM 	Re: Comments on the revised function chapter
C01876 00351	∂13-Dec-86  0915	skeene@STONY-BROOK.SCRC.Symbolics.COM 	restrictions on change-class   
C01884 00352	∂16-Dec-86  1206	RPG  	My remarks on Moon's comments etc.
C01888 00353	∂16-Dec-86  1422	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Gabriel's remarks on Moon's comments etc.  
C01893 00354	∂16-Dec-86  1453	RPG  	Argument Precedence Order    
C01895 00355	∂16-Dec-86  1509	RPG  	Onward ... Soldiers
C01897 00356	∂16-Dec-86  1642	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Onward ... Soldiers    
C01899 00357	∂16-Dec-86  1657	RPG  	Planning 
C01901 00358	∂17-Dec-86  0729	skeene@STONY-BROOK.SCRC.Symbolics.COM 	My remarks on Moon's comments etc.  
C01905 00359	∂17-Dec-86  1234	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Comments on the revised function chapter    
C01907 00360	∂17-Dec-86  1246	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Comments on the revised function chapter    
C01909 00361	∂17-Dec-86  1510	RPG  	Rephrasing    
C01911 00362	∂17-Dec-86  1524	Moon@RIVERSIDE.SCRC.Symbolics.COM 	Re: Comments on the revised function chapter 
C01915 00363	∂17-Dec-86  1533	Moon@RIVERSIDE.SCRC.Symbolics.COM 	Implementation-supplied methods for DESCRIBE and PRINT-OBJECT    
C01918 00364	∂17-Dec-86  1542	RPG  	Implementation-supplied etc  
C01919 00365	∂17-Dec-86  1631	Gregor.pa@Xerox.COM 	Re: Comments on the revised function chapter
C01925 00366	∂17-Dec-86  1634	Moon@STONY-BROOK.SCRC.Symbolics.COM 	specializers list 
C01931 00367	∂17-Dec-86  1702	Gregor.pa@Xerox.COM 	Re: specializers list   
C01935 00368	∂17-Dec-86  2033	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Uninitialized slots    
C01939 00369	∂17-Dec-86  2110	RPG  	Uninitialized Slots
C01943 00370	∂17-Dec-86  2120	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Relationship between accessors and methods 
C01947 00371	∂18-Dec-86  0846	skeene@STONY-BROOK.SCRC.Symbolics.COM 	Changes made to the document   
C01972 00372	∂18-Dec-86  0848	skeene@STONY-BROOK.SCRC.Symbolics.COM 	List of open issues  
C01985 00373	∂18-Dec-86  0849	skeene@STONY-BROOK.SCRC.Symbolics.COM 	formatting changes needed 
C01989 00374	∂18-Dec-86  1229	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Comments on the revised function chapter    
C01998 00375	∂18-Dec-86  1345	Gregor.pa@Xerox.COM 	Re: Implementation-supplied etc   
C02000 00376	∂19-Dec-86  2055	Moon@STONY-BROOK.SCRC.Symbolics.COM 	DECLARE option to DEFGENERIC(-OPTIONS)
C02008 00377	∂19-Dec-86  2106	Moon@STONY-BROOK.SCRC.Symbolics.COM 	with-slots & interning of constructed symbols   
C02012 00378	∂20-Dec-86  1243	RPG  	DECLARE option to DEFGENERIC(-OPTIONS) 
C02016 00379	∂20-Dec-86  2333	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Comments on the revised function chapter    
C02020 00380	∂21-Dec-86  1657	masinter.PA@Xerox.COM 	with-slots  
C02023 00381	∂22-Dec-86  1211	Bobrow.pa@Xerox.COM 	Re: DECLARE option to DEFGENERIC(-OPTIONS)  
C02027 00382	∂22-Dec-86  1211	Bobrow.pa@Xerox.COM 	Re: with-slots & interning of constructed symbols
C02029 00383	∂22-Dec-86  1218	Moon@STONY-BROOK.SCRC.Symbolics.COM 	DECLARE option to DEFGENERIC(-OPTIONS)     
C02033 00384	∂22-Dec-86  1310	RPG  	DECLARE option to DEFGENERIC(-OPTIONS) 
C02035 00385	∂22-Dec-86  1348	Bobrow.pa@Xerox.COM 	Re: DECLARE option to DEFGENERIC(-OPTIONS)  
C02037 00386	∂22-Dec-86  1358	Bobrow.pa@Xerox.COM 	Re: Comments on the revised function chapter
C02041 00387	∂22-Dec-86  1745	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: with-slots & interning of constructed symbols    
C02044 00388	∂22-Dec-86  1931	Moon@STONY-BROOK.SCRC.Symbolics.COM 	DECLARE option to DEFGENERIC(-OPTIONS)
C02050 00389	∂22-Dec-86  2259	masinter.pa@Xerox.COM 	Re: with-slots & interning of constructed symbols   
C02053 00390	∂23-Dec-86  0031	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Comments on the revised function chapter    
C02057 00391	∂23-Dec-86  1018	Bobrow.pa@Xerox.COM 	Re: with-slots & interning of constructed symbols
C02060 00392	∂23-Dec-86  1310	skeene@STONY-BROOK.SCRC.Symbolics.COM 	documentation revised
C02064 00393	∂23-Dec-86  1327	Gregor.pa@Xerox.COM 	Re: Uninitialized Slots 
C02067 00394	∂23-Dec-86  1429	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: Relationship between accessors and methods   
C02074 00395	∂23-Dec-86  1451	Gregor.pa@Xerox.COM 	Re: DECLARE option to DEFGENERIC(-OPTIONS)  
C02076 00396	∂23-Dec-86  1457	Gregor.pa@Xerox.COM 	Re: Comments on the revised function chapter
C02080 00397	∂23-Dec-86  1729	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Relationship between accessors and methods  
C02084 00398	∂24-Dec-86  1502	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: Comments on the revised function chapter
C02089 00399	∂24-Dec-86  1504	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: DECLARE option to DEFGENERIC(-OPTIONS)  
C02092 00400	∂24-Dec-86  1506	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: Comments on the revised function chapter
C02097 00401	∂24-Dec-86  1504	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: specializers list   
C02102 00402	∂28-Dec-86  1358	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: DECLARE option to DEFGENERIC(-OPTIONS) 
C02106 00403	∂28-Dec-86  1419	Moon@STONY-BROOK.SCRC.Symbolics.COM 	make-method issue 
C02110 00404	∂28-Dec-86  1426	Moon@STONY-BROOK.SCRC.Symbolics.COM 	:method-class option to DEFGENERIC-OPTIONS 
C02113 00405	∂28-Dec-86  1557	Moon@STONY-BROOK.SCRC.Symbolics.COM 	terminology confusion  
C02125 00406	∂28-Dec-86  1618	Moon@STONY-BROOK.SCRC.Symbolics.COM 	MAKE-METHOD arguments discussion 
C02131 00407	∂28-Dec-86  1656	RPG  	Question about MAKE-METHOD Arguments   
C02133 00408	∂28-Dec-86  1807	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Question about MAKE-METHOD Arguments       
C02137 00409	∂28-Dec-86  2040	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Note to go into the Concepts chapter  
C02141 00410	∂28-Dec-86  2112	Moon@STONY-BROOK.SCRC.Symbolics.COM 	:allocation slot-option issues   
C02149 00411	∂29-Dec-86  1129	RPG  	Terminology   
C02150 00412	∂29-Dec-86  1201	RPG  	Standard-type-class
C02152 00413	∂29-Dec-86  1218	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issues in Concepts chapter  
C02156 00414	∂29-Dec-86  1302	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Standard-type-class    
C02161 00415	∂29-Dec-86  1333	RPG  	STANDARD-TYPE-CLASS
C02163 00416	∂29-Dec-86  1829	Bobrow.pa@Xerox.COM 	Re: :method-class option to DEFGENERIC-OPTIONS   
C02167 00417	∂29-Dec-86  1829	Bobrow.pa@Xerox.COM 	Re: terminology confusion - component/dependent  
C02171 00418	∂29-Dec-86  1830	Bobrow.pa@Xerox.COM 	Re: terminology confusion:  Specifying Builtin classes
C02174 00419	∂29-Dec-86  1832	Bobrow.pa@Xerox.COM 	Re: terminology confusion    
C02179 00420	∂29-Dec-86  1830	Bobrow.pa@Xerox.COM 	Re: terminology confusion STRUCTURE-CLASS as a BUILT-IN-CLASS?  
C02182 00421	∂29-Dec-86  2111	RPG  	Terminology   
C02185 00422	∂29-Dec-86  2157	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: terminology confusion   
C02190 00423	∂29-Dec-86  2207	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: terminology confusion:  Specifying Builtin classes    
C02195 00424	∂29-Dec-86  2220	Masinter.pa@Xerox.COM 	Comments on various comments    
C02201 00425	∂29-Dec-86  2226	RPG   	Re: Terminology   
C02203 00426	∂30-Dec-86  1033	Bobrow.pa@Xerox.COM 	Re: Comments on various comments  
C02209 00427	∂30-Dec-86  1033	Bobrow.pa@Xerox.COM 	Re: terminology confusion    
C02211 00428	∂30-Dec-86  1035	RPG   	Re: Terminology   
C02213 00429	∂30-Dec-86  1034	Bobrow.pa@Xerox.COM 	Re: Terminology    
C02215 00430	∂30-Dec-86  1034	Bobrow.pa@Xerox.COM 	Re: Issues in Concepts chapter    
C02217 00431	∂30-Dec-86  1037	RPG   	Re: Terminology   
C02219 00432	∂30-Dec-86  1036	RPG   	Re: Terminology   
C02221 00433	∂30-Dec-86  1033	Bobrow.pa@Xerox.COM 	Re: terminology confusion:  Specifying Builtin classes
C02224 00434	∂30-Dec-86  1126	RPG  	Terminology (sort of): A New Question  
C02225 00435	∂30-Dec-86  1139	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Terminology: default value form  
C02227 00436	∂30-Dec-86  1215	Masinter.pa@Xerox.COM 	Re: Terminology  
C02229 00437	∂30-Dec-86  1214	Masinter.pa@Xerox.COM 	Re: Comments on various comments
C02235 00438	∂30-Dec-86  1236	RPG  	Clarfication on ``superclass''    
C02236 00439	∂30-Dec-86  1332	Bobrow.pa@Xerox.COM 	Re: Terminology: default value form    
C02239 00440	∂30-Dec-86  1332	Bobrow.pa@Xerox.COM 	Re: Clarfication on ``superclass''     
C02241 00441	∂30-Dec-86  1620	Dussud%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: Terminology (sort of): A New Question   
C02243 00442	∂30-Dec-86  2149	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Terminology: default value form   
C02246 00443	∂30-Dec-86  2152	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Terminology: default value form   
C02250 00444	∂30-Dec-86  2204	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Comments on various comments 
C02254 00445	∂31-Dec-86  1514	RPG  	STANDARD-TYPE-CLASS
C02259 00446	∂31-Dec-86  1529	Bobrow.pa@Xerox.COM 	Re: make-method issue   
C02261 00447	∂31-Dec-86  1529	Bobrow.pa@Xerox.COM 	Re: :allocation slot-option issues
C02267 00448	∂31-Dec-86  1529	Bobrow.pa@Xerox.COM 	Re: :allocation slot-option issues
C02273 00449	∂31-Dec-86  1726	Bobrow.pa@Xerox.COM 	Method Combination Proposal  
C02296 00450	∂02-Jan-87  2231	RPG  	Class Precedence List   
C02309 00451	∂03-Jan-87  1529	Moon@STONY-BROOK.SCRC.Symbolics.COM 	STANDARD-TYPE-CLASS    
C02311 00452	∂03-Jan-87  1537	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Terminology: lattice   
C02313 00453	∂03-Jan-87  1600	Moon@STONY-BROOK.SCRC.Symbolics.COM 	terminology confusion: subclass, superclass
C02327 00454	∂03-Jan-87  1749	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: :allocation slot-option issues    
C02337 00455	∂03-Jan-87  1835	RPG  	Terminology   
C02339 00456	∂04-Jan-87  1251	RPG  	Very Dull Message About Class Precedence Lists   
C02347 00457	∂05-Jan-87  0857	Bobrow.pa@Xerox.COM 	Re: terminology confusion: subclass, superclass  
C02350 00458	∂05-Jan-87  0956	Bobrow.pa@Xerox.COM 	Re: Class Precedence List    
C02353 00459	∂05-Jan-87  0957	Bobrow.pa@Xerox.COM 	Re: STANDARD-TYPE-CLASS 
C02356 00460	∂05-Jan-87  1150	Bobrow.pa@Xerox.COM 	Re: :allocation slot-option issues
C02363 00461	∂05-Jan-87  1151	Gregor.pa@Xerox.COM 	Re: STANDARD-TYPE-CLASS 
C02366 00462	∂05-Jan-87  1150	Bobrow.pa@Xerox.COM 	Some invariants    
C02369 00463	∂05-Jan-87  1216	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re: Class Precedence List       
C02372 00464	∂05-Jan-87  1233	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Method Combination Proposal 
C02394 00465	∂05-Jan-87  1237	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Method Combination Proposal 
C02417 00466	∂05-Jan-87  1246	Gregor.pa@Xerox.COM 	Re: Question about MAKE-METHOD Arguments    
C02420 00467	∂05-Jan-87  1326	Gregor.pa@Xerox.COM 	Re: Terminology: default value form    
C02423 00468	∂05-Jan-87  1326	Gregor.pa@Xerox.COM 	Re: MAKE-METHOD arguments discussion   
C02426 00469	∂05-Jan-87  1351	Gregor.pa@Xerox.COM 	Re: Comments on various comments  
C02430 00470	∂05-Jan-87  1359	Gregor.pa@Xerox.COM 	Re: STANDARD-TYPE-CLASS 
C02434 00471	∂05-Jan-87  2034	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: MAKE-METHOD arguments discussion  
C02438 00472	∂05-Jan-87  2129	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: :allocation slot-option issues    
C02440 00473	∂05-Jan-87  2154	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Class Precedence List       
C02448 00474	∂06-Jan-87  0141	Bobrow.pa@Xerox.COM 	Re: :allocation slot-option issues
C02451 00475	∂06-Jan-87  0156	Bobrow.pa@Xerox.COM 	Re: Class Precedence List    
C02468 00476	∂06-Jan-87  0250	Bobrow.pa@Xerox.COM 	Re: Method Combination Proposal   
C02477 00477	∂06-Jan-87  0822	Dussud%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: Some invariants
C02480 00478	∂06-Jan-87  1123	Moon@RIVERSIDE.SCRC.Symbolics.COM 	Re: :allocation slot-option issues 
C02483 00479	∂06-Jan-87  1435	Gregor.pa@Xerox.COM 	Re: MAKE-METHOD arguments discussion   
C02490 00480	∂06-Jan-87  1900	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Method Combination Proposal  
C02509 00481	∂07-Jan-87  1737	Gregor.pa@Xerox.COM 	Re: Method Combination Proposal   
C02514 00482	∂07-Jan-87  1737	Masinter.pa@Xerox.COM 	Re: Some invariants   
C02516 00483	∂07-Jan-87  1737	Masinter.pa@Xerox.COM 	Re: Some invariants   
C02518 00484	∂07-Jan-87  1758	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Some invariants    
C02520 00485	∂07-Jan-87  1841	Masinter.pa@Xerox.COM 	Re: Some invariants   
C02523 00486	∂07-Jan-87  1928	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Some invariants    
C02526 00487	∂07-Jan-87  2134	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Method Combination Proposal  
C02539 00488	∂08-Jan-87  1701	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Lexical environment of slot default initial value forms   
C02543 00489	∂08-Jan-87  1714	RPG  	What's left to do  
C02544 00490	∂08-Jan-87  1952	Moon@STONY-BROOK.SCRC.Symbolics.COM 	What's left to do      
C02547 00491	∂08-Jan-87  2001	RPG  	Class Precedence List   
C02561 00492	∂08-Jan-87  2028	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issues for the CLOS committee to start focussing on  
C02568 00493	∂08-Jan-87  2057	Dussud%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: MAKE-METHOD arguments discussion   
C02574 00494	∂08-Jan-87  2132	Bobrow.pa@Xerox.COM 	Re: What's left to do   
C02576 00495	∂08-Jan-87  2321	Bobrow.pa@Xerox.COM 	Re: Method Combination Proposal   
C02589 00496	∂08-Jan-87  2341	Bobrow.pa@Xerox.COM 	Re: Class Precedence List    
C02593 00497	∂08-Jan-87  2342	Bobrow.pa@Xerox.COM 	Re: Lexical environment of slot default initial value forms
C02595 00498	∂08-Jan-87  2349	Bobrow.pa@Xerox.COM 	Re: Issues for the CLOS committee to start focussing on    
C02598 00499	∂09-Jan-87  0612	skeene@STONY-BROOK.SCRC.Symbolics.COM 	Re: Issues for the CLOS committee to start focussing on 
C02600 00500	∂09-Jan-87  1154	RPG  	Class Precedence List: Rebuttal to Danny    
C02611 00501	∂09-Jan-87  1349	Moon@RIVERSIDE.SCRC.Symbolics.COM 	Re: What's left to do    
C02614 00502	∂09-Jan-87  1359	skeene@RIVERSIDE.SCRC.Symbolics.COM 	new version of concepts chapter  
C02616 00503	∂09-Jan-87  1744	Bobrow.pa@Xerox.COM 	Re: Class Precedence List: Rebuttal to Danny     
C02625 00504	∂10-Jan-87  2101	RPG  	For the Record
C02628 00505	∂11-Jan-87  1207	RPG  	Issues for the CLOS committee to start focussing on   
C02633 00506	∂11-Jan-87  1208	RPG  	Environment for initial value form
C02634 00507	∂11-Jan-87  2230	Bobrow.pa@Xerox.COM 	Re: Issues for the CLOS committee to start focussing on    
C02637 00508	∂11-Jan-87  2240	Bobrow.pa@Xerox.COM 	Re: For the Record 
C02640 00509	∂11-Jan-87  2323	RPG  	CPL Algorithm 
C02644 00510	∂12-Jan-87  0028	Bobrow.pa@Xerox.COM 	Re: CPL Algorithm  
C02646 00511	∂12-Jan-87  1531	Moon@RIVERSIDE.SCRC.Symbolics.COM 	Documents updated for method combination
C02649 00512	∂12-Jan-87  1547	Moon@RIVERSIDE.SCRC.Symbolics.COM 	Re: Method Combination Proposal    
C02667 00513	∂12-Jan-87  1828	Moon@STONY-BROOK.SCRC.Symbolics.COM 	For the Record    
C02670 00514	∂12-Jan-87  1836	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Environment for initial value form    
C02672 00515	∂12-Jan-87  1945	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Issues for the CLOS committee to start focussing on   
C02674 00516	∂12-Jan-87  1950	Moon@STONY-BROOK.SCRC.Symbolics.COM 	For the Record    
C02676 00517	∂13-Jan-87  1045	Bobrow.pa@Xerox.COM 	Re: Issues for the CLOS committee to start focussing on    
C02679 00518	∂13-Jan-87  2046	skeene@RIVERSIDE.SCRC.Symbolics.COM 	Re: Issues for the CLOS committee to start focussing on   
C02682 00519	∂15-Jan-87  0837	skeene@STONY-BROOK.SCRC.Symbolics.COM 	draft on inheritance of slots and defclass options 
C02697 00520	∂15-Jan-87  1514	Gregor.pa@Xerox.COM 	Re: Issues for the CLOS committee to start focussing on    
C02699 00521	∂15-Jan-87  1713	Masinter.pa@Xerox.COM 	Re: draft on inheritance of slots and defclass options   
C02702 00522	∂16-Jan-87  0748	skeene@STONY-BROOK.SCRC.Symbolics.COM 	Re: draft on inheritance of slots and defclass options  
C02707 00523	∂16-Jan-87  0821	skeene@STONY-BROOK.SCRC.Symbolics.COM 	new versions of files
C02710 00524	∂19-Jan-87  2142	Moon@MEAD.SCRC.Symbolics.COM 	change-class and class redefinition
C02730 00525	∂20-Jan-87  1010	DLW@ALDERAAN.SCRC.Symbolics.COM 	change-class and class redefinition  
C02734 00526	∂20-Jan-87  1224	Bobrow.pa@Xerox.COM 	New version of define-method-combination    
C02758 00527	∂20-Jan-87  1429	Gregor.pa@Xerox.COM 	Re: New version of define-method-combination
C02764 00528	∂21-Jan-87  1421	RPG  	standard-type-classes   
C02768 00529	∂21-Jan-87  1632	kempf%hplabsc@hplabs.HP.COM 	Re:  standard-type-classes
C02770 00530	∂21-Jan-87  1755	Gregor.pa@Xerox.COM 	Re: change-class and class redefinition
C02774 00531	∂21-Jan-87  1755	Bobrow.pa@Xerox.COM 	Small additional suggestion wrt Method-combination    
C02776 00532	∂21-Jan-87  2010	RPG  	Inheritance of Methods  
C02778 00533	∂21-Jan-87  2200	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: change-class and class redefinition    
C02787 00534	∂21-Jan-87  2248	masinter.pa@Xerox.COM 	Re: standard-type-classes  
C02791 00535	∂22-Jan-87  0810	skeene@STONY-BROOK.SCRC.Symbolics.COM 	Inheritance of Methods    
C02795 00536	∂22-Jan-87  1140	Masinter.pa@Xerox.COM 	[Masinter.pa: Handling Common Lisp built in types]  
C02803 00537	∂22-Jan-87  1140	Masinter.pa@Xerox.COM 	Re: Inheritance of Methods      
C02805 00538	∂22-Jan-87  1527	Bobrow.pa@Xerox.COM 	Re: Inheritance of Methods   
C02807 00539	∂22-Jan-87  1527	Bobrow.pa@Xerox.COM 	Re: standard-type-classes    
C02810 00540	∂22-Jan-87  1527	Bobrow.pa@Xerox.COM 	Re: change-class and class redefinition
C02816 00541	∂22-Jan-87  1527	Bobrow.pa@Xerox.COM 	[Gregor Kiczales <Gregor.pa>: Re: STANDARD-TYPE-CLASS]
C02820 00542	∂22-Jan-87  1556	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: standard-type-classes   
C02823 00543	∂22-Jan-87  1603	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Inheritance of Methods  
C02825 00544	∂22-Jan-87  1603	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: change-class and class redefinition    
C02831 00545	∂22-Jan-87  1610	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Inheritance of Methods  
C02834 00546	∂22-Jan-87  1642	Masinter.pa@Xerox.COM 	Re: Inheritance of Methods      
C02836 00547	∂22-Jan-87  1654	Bobrow.pa@Xerox.COM 	Re: standard-type-classes    
C02839 00548	∂22-Jan-87  1700	Bobrow.pa@Xerox.COM 	Re: change-class and class redefinition
C02842 00549	∂22-Jan-87  1701	RPG  	Inheritance of Methods  
C02844 00550	∂22-Jan-87  2201	Masinter.pa@Xerox.COM 	Re: standard-type-classes       
C02847 00551	∂23-Jan-87  1123	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: standard-type-classes   
C02851 00552	∂23-Jan-87  1125	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Inheritance of Methods  
C02853 00553	∂23-Jan-87  1131	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: change-class and class redefinition    
C02856 00554	∂23-Jan-87  1141	Gregor.pa@Xerox.COM 	Re: standard-type-classes    
C02859 00555	∂23-Jan-87  1142	Gregor.pa@Xerox.COM 	Re: change-class and class redefinition
C02862 00556	∂23-Jan-87  1204	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: change-class and class redefinition    
C02865 00557	∂23-Jan-87  1236	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: standard-type-classes   
C02867 00558	∂23-Jan-87  1241	RPG  	Strenuously   
C02868 00559	∂23-Jan-87  1350	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Symbolics design review
C02874 00560	∂23-Jan-87  2139	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 
C02883 00561	∂24-Jan-87  1528	RPG  	Alternatives  
C02885 00562	∂25-Jan-87  1530	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Comments on Concepts chapter 1/23/87  
C02911 00563	∂25-Jan-87  1652	RPG  	Moon's comments    
C02918 00564	∂25-Jan-87  1840	Moon@RIVERSIDE.SCRC.Symbolics.COM 	Gabriel's comments                                                                                       
C02930 00565	∂25-Jan-87  2157	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Class-precedence-list computation
C02938 00566	∂26-Jan-87  1413	Gregor.pa@Xerox.COM 	symbols are not generic functions 
C02941 00567	∂26-Jan-87  1413	Bobrow.pa@Xerox.COM 	Re: ---  
C02945 00568	∂26-Jan-87  1605	kahn.pa@Xerox.COM 	:allocation :none    
C02948 00569	∂26-Jan-87  2056	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Class-precedence-list computation
C02952 00570	∂26-Jan-87  2127	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: change-class and class redefinition    
C02955 00571	∂27-Jan-87  0027	RPG  	CPL Update    
C02957 00572	∂27-Jan-87  0927	Bobrow.pa@Xerox.COM 	Re: CPL Update     
C02962 00573	∂27-Jan-87  1112	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: ---  
C02968 00574	∂27-Jan-87  1207	RPG  	CPL Computation    
C02981 00575	∂27-Jan-87  1430	Bobrow.pa@Xerox.COM 	Re: CPL Computation     
C02985 00576	∂27-Jan-87  1432	Bobrow.pa@Xerox.COM 	Re: ---  
C02989 00577	∂27-Jan-87  1752	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: --- 
C02993 00578	∂27-Jan-87  1801	RPG  	Elaboration on the Non-intuitiveness of New Flavors Algorithm...
C02999 00579	∂27-Jan-87  1805	Bobrow.pa@Xerox.COM 	Re: CPL Update
C03004 00580	∂27-Jan-87  1854	Bobrow.pa@Xerox.COM 	Re: ---  
C03007 00581	∂27-Jan-87  1857	Bobrow.pa@Xerox.COM 	Re: Elaboration on the Non-intuitiveness of New Flavors    
C03009 00582	∂27-Jan-87  1914	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: ---  
C03014 00583	∂27-Jan-87  2003	Moon@RIVERSIDE.SCRC.Symbolics.COM 	:allocation :none   
C03018 00584	∂27-Jan-87  2011	Moon@RIVERSIDE.SCRC.Symbolics.COM 	symbols are not generic functions  
C03023 00585	∂27-Jan-87  2116	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Danny's new version of define-method-combination
C03043 00586	∂27-Jan-87  2117	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: --- 
C03047 00587	∂27-Jan-87  2222	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: CPL Update    
C03050 00588	∂27-Jan-87  2234	Moon@STONY-BROOK.SCRC.Symbolics.COM 	CPL Computation        
C03053 00589	∂28-Jan-87  0713	DLW@ALDERAAN.SCRC.Symbolics.COM 	:allocation :none
C03057 00590	∂28-Jan-87  1005	RPG  	Complexity of Topological Sort + single-pass treewalk tiebreaker
C03058 00591	∂28-Jan-87  1754	Bobrow.pa@Xerox.COM 	Re: Method Combination  
C03077 00592	∂28-Jan-87  1922	RPG  	Last-Visited Preorder   
C03079 00593	∂28-Jan-87  1932	RPG  	Progress is Our Most Important Problem 
C03082 00594	∂28-Jan-87  2216	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Elaboration on the Non-intuitiveness of New Flavors Algorithm...    
C03087 00595	∂29-Jan-87  0206	RPG  	CPL Tiebreaker
C03092 00596	∂29-Jan-87  0702	skeene@STONY-BROOK.SCRC.Symbolics.COM 	Progress is Our Most Important Problem   
C03099 00597	∂29-Jan-87  1047	Bobrow.pa@Xerox.COM 	Re: Last-Visited Preorder    
C03102 00598	∂29-Jan-87  1048	Bobrow.pa@Xerox.COM 	Re: Progress is Our Most Important Problem  
C03107 00599	∂29-Jan-87  1402	skeene@STONY-BROOK.SCRC.Symbolics.COM 	changes made to documentation  
C03110 00600	∂29-Jan-87  1652	RPG  	The Real Deadline  
C03112 00601	∂29-Jan-87  1708	"Patrick H Dussud %Jenner%ti-csl.csnet"@RELAY.CS.NET 	Re: Method Combination    
C03120 00602	∂29-Jan-87  1713	Gregor.pa@Xerox.COM 	Re: Progress is Our Most Important Problem -- Method  
C03123 00603	∂29-Jan-87  1722	RPG   	Re: Algorithms    
C03126 00604	∂29-Jan-87  1713	Gregor.pa@Xerox.COM 	My comments on some things   
C03134 00605	∂29-Jan-87  1713	Gregor.pa@Xerox.COM 	Re: symbols are not generic functions  
C03138 00606	∂29-Jan-87  1930	Moon@STONY-BROOK.SCRC.Symbolics.COM 	CPL Tiebreaker    
C03145 00607	∂29-Jan-87  2003	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Gregor's comments on some things 
C03154 00608	∂29-Jan-87  2154	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Minor things noticed while proofreading documents    
C03157 00609	∂30-Jan-87  2218	RPG  	CPL etc  
C03165 00610	∂31-Jan-87  0923	RPG  	Common Lisp Types  
C03169 00611	∂31-Jan-87  1156	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: symbols are not generic functions  
C03177 00612	∂31-Jan-87  2054	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Moon/Bobrow phone conversation   
C03180 00613	∂31-Jan-87  2127	Moon@STONY-BROOK.SCRC.Symbolics.COM 	CPL etc      
C03187 00614	∂01-Feb-87  1410	RPG  	CPL Varia
C03190 00615	∂01-Feb-87  2257	edsel!bhopal!jonl@navajo.stanford.edu 	CPL anxieties   
C03197 00616	∂02-Feb-87  0854	RPG   	Re: --- 
C03200 00617	∂02-Feb-87  1617	Bobrow.pa@Xerox.COM 	Re: Method Combination  
C03206 00618	∂02-Feb-87  1621	Gregor.pa@Xerox.COM 	Some other open issues  
C03208 00619	∂02-Feb-87  1624	Bobrow.pa@Xerox.COM 	Re: Minor things noticed while proofreading documents 
C03212 00620	∂02-Feb-87  1634	Bobrow.pa@Xerox.COM 	Re: Gregor's comments on some things   
C03218 00621	∂02-Feb-87  1636	Gregor.pa@Xerox.COM 	Some other open issues  
C03220 00622	∂02-Feb-87  1645	RPG  	Various of Danny's Comments  
C03222 00623	∂02-Feb-87  1636	Gregor.pa@Xerox.COM 	Some other open issues  
C03224 00624	∂02-Feb-87  1920	Bobrow.pa@Xerox.COM 	Re: Various of Danny's Comments   
C03228 00625	∂02-Feb-87  1920	Bobrow.pa@Xerox.COM 	Re: CPL Varia 
C03230 00626	∂02-Feb-87  1925	masinter.PA@Xerox.COM 	Re: Common Lisp Types 
C03231 00627	∂02-Feb-87  1925	Masinter.pa@Xerox.COM 	Re: Common Lisp Types      
C03236 00628	∂02-Feb-87  1927	Bobrow.pa@Xerox.COM 	Re: Common Lisp Types   
C03241 00629	∂02-Feb-87  1935	Masinter.pa@Xerox.COM 	Re: symbols are not generic functions
C03243 00630	∂02-Feb-87  1952	Bobrow.pa@Xerox.COM 	Re: CPL anxieties  
C03248 00631	∂02-Feb-87  2053	RPG  	Common Lisp Types  
C03251 00632	∂02-Feb-87  2224	edsel!bhopal!jonl@navajo.stanford.edu 	CPL anxieties   
C03256 00633	∂03-Feb-87  1203	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: Moon/Bobrow phone conversation
C03259 00634	∂03-Feb-87  1354	RPG  	Clarification 
C03261 00635	∂03-Feb-87  1431	Gregor.pa@Xerox.COM 	Re: Clarification  
C03264 00636	∂03-Feb-87  1555	Bobrow.pa@Xerox.COM 	Re: Clarification  
C03268 00637	∂03-Feb-87  1945	kempf%hplabsc@hplabs.HP.COM 	Re:  Some other open issues    
C03271 00638	∂04-Feb-87  0810	kempf%hplabsc@hplabs.HP.COM 	Re: Common Lisp Types
C03273 00639	∂04-Feb-87  0953	DLW@RIVERSIDE.SCRC.Symbolics.COM 	initializing class slots  
C03275 00640	∂04-Feb-87  0956	Bobrow.pa@Xerox.COM 	Re: Common Lisp Types   
C03278 00641	∂04-Feb-87  1004	RPG  	Inheritance of Slot Options  
C03281 00642	∂04-Feb-87  1138	RPG  	Addendum to ``Inheritance of Slot Options'' 
C03282 00643	∂04-Feb-87  1415	Gregor.pa@Xerox.COM 	class-named   
C03284 00644	∂04-Feb-87  1504	Gregor.pa@Xerox.COM 	my comments on 2/2/87 draft of functi  
C03296 00645	∂04-Feb-87  1718	Moon@STONY-BROOK.SCRC.Symbolics.COM 	More feedback from Symbolics reviewers
C03299 00646	∂04-Feb-87  2012	Gregor.pa@Xerox.COM 	initialization protocol 
C03308 00647	∂04-Feb-87  2107	Bobrow.pa@Xerox.COM 	Re: initializing class slots 
C03310 00648	∂04-Feb-87  2113	Bobrow.pa@Xerox.COM 	Re: Inheritance of Slot Options   
C03312 00649	∂04-Feb-87  2119	Bobrow.pa@Xerox.COM 	Re: Addendum to ``Inheritance of Slot Options''  
C03314 00650	∂04-Feb-87  2133	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Clarification 
C03317 00651	∂04-Feb-87  2134	RPG  	CL Types 
C03318 00652	∂04-Feb-87  2141	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Various of Danny's Comments      
C03320 00653	∂04-Feb-87  2146	RPG  	CALL-NEXT-METHOD   
C03321 00654	∂04-Feb-87  2149	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Discussion at X3J13    
C03324 00655	∂04-Feb-87  2218	RPG  	Clarification Clarification  
C03325 00656	∂04-Feb-87  2226	Moon@STONY-BROOK.SCRC.Symbolics.COM 	call-next-method: More feedback from Symbolics reviewers  
C03329 00657	∂04-Feb-87  2142	Moon@STONY-BROOK.SCRC.Symbolics.COM 	CPL Varia    
C03333 00658	∂04-Feb-87  2141	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Inheritance of Slot Options      
C03339 00659	∂04-Feb-87  2141	Bobrow.pa@Xerox.COM 	Re: More feedback from Symbolics reviewers  
C03342 00660	∂04-Feb-87  2352	RPG  	CPL Varia
C03343 00661	∂04-Feb-87  2349	RPG  	Inheritance of Slots    
C03347 00662	∂05-Feb-87  0938	RPG  	X3J13 Discussion   
C03348 00663	∂05-Feb-87  0955	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re: initializing class slots    
C03351 00664	∂05-Feb-87  1205	Bobrow.pa@Xerox.COM 	Re: Various of Danny's Comments   
C03353 00665	∂05-Feb-87  1211	Lanning.pa@Xerox.COM 	Comments on Chapter 1  
C03357 00666	∂05-Feb-87  1227	Masinter.pa@Xerox.COM 	call-next-method is not a function   
C03359 00667	∂05-Feb-87  1312	RPG  	Stan's Comments    
C03362 00668	∂05-Feb-87  1321	RPG  	Functions
C03364 00669	∂05-Feb-87  2100	Moon@STONY-BROOK.SCRC.Symbolics.COM 	call-next-method is not a function    
C03366 00670	∂06-Feb-87  0901	Gregor.pa@Xerox.COM 	Re: Functions 
C03367 00671	∂06-Feb-87  1240	Gregor.pa@Xerox.COM 	ensure-generic-function 
C03370 00672	∂06-Feb-87  1350	Masinter.pa@Xerox.COM 	Re: call-next-method is not a function    
C03373 00673	∂06-Feb-87  1350	Masinter.pa@Xerox.COM 	Re: Functions    
C03375 00674	∂06-Feb-87  1703	Bobrow.pa@Xerox.COM 	List of generic functions    
C03384 00675	∂06-Feb-87  1830	Bobrow.pa@Xerox.COM 	LONG MESSAGE -- Draft of meta-object protocol    
C03433 00676	∂06-Feb-87  2030	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: call-next-method is not a function
C03437 00677	∂06-Feb-87  2124	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Gregor's comments on 2/2/87 draft of functi
C03454 00678	∂06-Feb-87  2137	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Inheritance of Slots        
C03461 00679	∂06-Feb-87  2218	RPG  	Semantic difficulties   
C03462 00680	∂06-Feb-87  2301	RPG  	Inheritance of Slots    
C03465 00681	∂09-Feb-87  0802	Bobrow.pa@Xerox.COM 	Re: Stan's Comments     
C03467 00682	∂09-Feb-87  0814	Bobrow.pa@Xerox.COM 	Re: Discussion at X3J13 
C03470 00683	∂09-Feb-87  1046	Gregor.pa@Xerox.COM 	Re: Inheritance of Slots     
C03473 00684	∂09-Feb-87  1841	MOON@AI.AI.MIT.EDU 	X3J13 version of document
C03475 00685	∂09-Feb-87  2044	RPG  	Document 
C03477 00686	∂10-Feb-87  0245	RPG  	State of the world 
C03483 00687	∂10-Feb-87  0936	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Inheritance of Slots        
C03493 00688	∂10-Feb-87  0943	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Document     
C03497 00689	∂10-Feb-87  0946	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Semantic difficulties       
C03499 00690	∂10-Feb-87  1106	Bobrow.pa@Xerox.COM 	Re: Inheritance of Slots     
C03501 00691	∂10-Feb-87  1211	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Inheritance of Slots    
C03505 00692	∂10-Feb-87  1330	Bobrow.pa@Xerox.COM 	Re: Inheritance of Slots     
C03511 00693	∂10-Feb-87  1330	Bobrow.pa@Xerox.COM 	Meta-object protocol    
C03515 00694	∂10-Feb-87  1438	RPG  	Inheritance of Slots    
C03517 00695	∂10-Feb-87  2229	RPG  	Documents
C03520 00696	∂11-Feb-87  0857	kempf%hplabsc@hplabs.HP.COM 	Re:  Meta-object protocol 
C03522 00697	∂12-Feb-87  1816	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: ensure-generic-function  
C03527 00698	∂12-Feb-87  1838	LGD  	Documents
C03528 00699	∂18-Feb-87  1437	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: ensure-generic-function  
C03533 00700	∂18-Feb-87  1438	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Things we should do to prepare for the March meeting 
C03536 00701	∂18-Feb-87  1502	Gregor.pa@Xerox.COM 	Re: ensure-generic-function  
C03539 00702	∂18-Feb-87  2139	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Errata for 87-002 
C03558 00703	∂19-Feb-87  1323	RPG  	CLOS Response 
C03563 00704	∂19-Feb-87  1422	RPG  	Comments On Moon's Errata  (Chapter 1 only) 
C03573 00705	∂19-Feb-87  1524	DLW@ALDERAAN.SCRC.Symbolics.COM 	CLOS Response    
C03577 00706	∂19-Feb-87  1743	Moon@STONY-BROOK.SCRC.Symbolics.COM 	CLOS Response     
C03584 00707	∂19-Feb-87  1752	RPG  	Consistency   
C03587 00708	∂20-Feb-87  0928	DLW@ALDERAAN.SCRC.Symbolics.COM 	Consistency      
C03592 00709	∂20-Feb-87  2237	RPG   	CLOS    
C03595 00710	∂20-Feb-87  2237	RPG   	CLOS    
C03601 00711	∂20-Feb-87  2242	RPG  	Meeting  
C03602 00712	∂20-Feb-87  2255	RPG  	CPL 
C03605 00713	∂22-Feb-87  1054	RPG  	Away
C03606 00714	∂23-Feb-87  1008	DLW@ALDERAAN.SCRC.Symbolics.COM 	CPL    
C03609 00715	∂23-Feb-87  1041	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Errata  
C03610 00716	∂23-Feb-87  1938	Moon@STONY-BROOK.SCRC.Symbolics.COM 	CPL     
C03617 00717	∂23-Feb-87  1941	Moon@STONY-BROOK.SCRC.Symbolics.COM 	errata sheet 
C03620 00718	∂23-Feb-87  2206	edsel!bhopal!jonl@navajo.stanford.edu 	Relations to window standardization 
C03627 00719	∂25-Feb-87  1205	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Proposed revision of "Inheritance of Slots and Slot Options" section
C03637 00720	∂25-Feb-87  1458	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Comments On Moon's Errata  (Chapter 1 only)     
C03655 00721	∂25-Feb-87  1944	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: Meeting   
C03657 00722	∂27-Feb-87  1626	Bobrow.pa@Xerox.COM 	Re: Proposed revision of "Inheritance of Slots and Slot    
C03661 00723	∂27-Feb-87  1824	RPG  	CPL 
C03662 00724	∂27-Feb-87  1833	Bobrow.pa@Xerox.COM 	Re: CPL  
C03665 00725	∂27-Feb-87  2258	RPG  	Inheritance of Slots and Slot Options  
C03671 00726	∂28-Feb-87  0012	RPG  	Moon's Comments on RPG's Comments on Moon's Errata    
C03681 00727	∂28-Feb-87  0118	RPG  	Moon's Errata for Chapter 2  
C03688 00728	∂28-Feb-87  0127	RPG  	All is Not Lost (?)
C03689 00729	∂02-Mar-87  2234	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Moon's comments on RPG's comments on Moon's Errata for Chapter 2    
C03698 00730	∂03-Mar-87  0006	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Moon's Comments on RPG's Comments on Moon's Errata        
C03711 00731	∂04-Mar-87  1502	Bobrow.pa@Xerox.COM 	Chapter 3
C03713 00732	∂04-Mar-87  1608	kempf%hplabsc@hplabs.HP.COM 	Re: Meeting
C03715 00733	∂04-Mar-87  1622	RPG  	Errata etc.   
C03716 00734	∂04-Mar-87  1631	RPG  	Meeting Monday
C03717 00735	∂04-Mar-87  1703	kempf%hplabsc@hplabs.HP.COM 	Comments on 87-002, Chapter 1  
C03740 00736	∂04-Mar-87  1803	Bobrow.pa@Xerox.COM 	Re: Meeting Monday 
C03742 00737	∂04-Mar-87  1928	kempf%hplabsc@hplabs.HP.COM 	Re:  Chapter 3  
C03754 00738	∂05-Mar-87  0058	RPG  	Agenda   
C03755 00739	∂05-Mar-87  0740	kempf%hplabsc@hplabs.HP.COM 	Re: Meeting Monday   
C03757 00740	∂05-Mar-87  1158	kempf%hplabsc@hplabs.HP.COM 	87-003 MetaObject Protocol
C03768 00741	∂05-Mar-87  2311	RPG  	Kempf's Remarks    
C03778 00742	∂06-Mar-87  1902	Bobrow.pa@Xerox.COM 	Quote of the day   
C03780 00743	∂07-Mar-87  0114	a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET 	Questions on CLOS specification
C03792 00744	∂08-Mar-87  0253	kempf%hplabsc@hplabs.HP.COM 	Re: Consistency 
C03798 00745	∂08-Mar-87  0342	kempf%hplabsc@hplabs.HP.COM 	Comments on CLOS specification 
C03800 00746	∂09-Mar-87  1122	RPG  	Meeting  
C03801 00747	∂10-Mar-87  1114	DLW@ALDERAAN.SCRC.Symbolics.COM 	Meeting     
C03803 00748	∂10-Mar-87  2001	Bobrow.pa@Xerox.COM 	Re: Meeting   
C03804 00749	∂10-Mar-87  2116	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Inheritance of Slots and Slot Options      
C03813 00750	∂10-Mar-87  2137	Moon@STONY-BROOK.SCRC.Symbolics.COM 	87-002 errata
C03842 00751	∂10-Mar-87  2116	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Proposed revision of "Inheritance of Slots and Slot   
C03846 00752	∂11-Mar-87  0006	kempf%hplabsc@hplabs.HP.COM 	Re: Gabriel's Comments    
C03852 00753	∂11-Mar-87  0701	Bobrow.pa@Xerox.COM 	Re: Inheritance of Slots and Slot Options   
C03855 00754	∂11-Mar-87  0800	Bobrow.pa@Xerox.COM 	Re: Gabriel's Comments  
C03860 00755	∂11-Mar-87  0913	RPG  	Inheritance of Slots    
C03861 00756	∂11-Mar-87  0939	RPG  	Staticizing   
C03862 00757	∂11-Mar-87  1306	skeene@STONY-BROOK.SCRC.Symbolics.COM 	Glossary (enclosed)  
C03890 00758	∂11-Mar-87  2204	kempf%hplabsc@hplabs.HP.COM 	Re:  Staticizing
C03892 00759	∂11-Mar-87  2326	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Gabriel's Comments 
C03902 00760	∂11-Mar-87  2328	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Comments on 87-002, Chapter 1    
C03908 00761	∂12-Mar-87  0002	kempf%hplabsc@hplabs.HP.COM 	Re: Gabriel's Comments    
C03915 00762	∂12-Mar-87  0911	RPG  	Errata and Glossary
C03918 00763	∂12-Mar-87  0924	Bobrow.pa@Xerox.COM 	Re: Inheritance of Slots     
C03921 00764	∂12-Mar-87  1217	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: Meeting   
C03923 00765	∂12-Mar-87  1325	skeene@STONY-BROOK.SCRC.Symbolics.COM 	Errata and Glossary  
C03925 00766	∂12-Mar-87  1448	LGD  	errata and glossary files    
C03926 00767	∂12-Mar-87  2125	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Errata and Glossary    
C03930 00768	∂12-Mar-87  2232	RPG  	Here We Go Again   
C03932 00769	∂15-Mar-87  1054	kempf%hplabsc@hplabs.HP.COM 	Re:  Inheritance of Slots 
C03933 00770	∂16-Mar-87  0144	kempf%hplabsc@hplabs.HP.COM 	Re: Moon's Comments  
C03936 00771	∂16-Mar-87  1132	kempf%hplabsc@hplabs.HP.COM 	Re:  is of type...   
C03939 00772	∂30-Mar-87  1541	LGD  	clos files on [cls,lsp] 
C03940 00773	∂15-Apr-87  1554	Gregor.pa@Xerox.COM 	defclass options   
C03942 00774	∂15-Apr-87  1921	Gregor.pa@Xerox.COM 	:accessor-prefix and :reader-prefix same?   
C03944 00775	∂15-Apr-87  1929	Moon@STONY-BROOK.SCRC.Symbolics.COM 	defclass options  
C03946 00776	∂15-Apr-87  2004	Moon@ALDERAAN.SCRC.Symbolics.COM 	:accessor-prefix and :reader-prefix same?
C03949 00777	∂15-Apr-87  2034	Gregor.pa@Xerox.COM 	Re: :accessor-prefix and :reader-prefix same?    
C03951 00778	∂15-Apr-87  2123	Moon@ALDERAAN.SCRC.Symbolics.COM 	Object creation discussion (at last!)    
C03971 00779	∂16-Apr-87  0920	DLW@ALDERAAN.SCRC.Symbolics.COM 	Object creation discussion (at last!)
C03974 00780	∂16-Apr-87  0948	RPG  	defclass options   
C03975 00781	∂16-Apr-87  1219	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Object creation discussion (at last!) 
C03980 00782	∂16-Apr-87  1629	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: Object creation discussion (at last!)   
C03985 00783	∂16-Apr-87  1845	kempf%hplabsc@hplabs.HP.COM 	CLOS Declaration Proposal 
C03987 00784	∂16-Apr-87  1939	kempf%hplabsc@hplabs.HP.COM 	(long) CLOS Declaration Proposal Text    
C04006 ENDMK
C⊗;
∂04-Sep-86  2153	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Whoppers and run-super
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Sep 86  21:50:35 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 04 SEP 86 21:48:11 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 04 SEP 86 21:47:42 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 74741;
 Fri 5-Sep-86 00:46:12 EDT
Date: Fri, 5 Sep 86 00:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Whoppers and run-super
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860902-183338-1341@Xerox>
Message-ID: <860905004612.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 2 Sep 86 18:33 PDT
    From: Bobrow.pa@Xerox.COM

Sorry about the slow response; I spent a lot of time thinking about this
instead of sending some sort of knee-jerk instant response.

    There seems to be a lot in common between whoppers and the Loops use of
    run-super. I have been trying to work out the appropriate relation
    between run-super and daemon method combination with whoppers.
    Whoppers are not expressible in the method combination language.

This is not completely true.  They could easily be done in the method
combination language.  We chose to do them instead as a separate layer
for the following reasons:

(1) We wanted the behavior of whoppers and wrappers to be constant,
independent of the method-combination type.

(2) We found that in old flavors having to worry about whoppers and
wrappers greatly complicated the definition of each method-combination
type.  It seemed better to do it in a central place and get it out
of the way of the user who wants to define his own method combination.

(3) Whoppers and wrappers seem to us to be fundamentally different
from ordinary methods; in particular, they receive different arguments.
Wrappers, being macros, receive forms as arguments rather than receiving
the arguments of a generic function call.  Less obviously, whoppers
receive different arguments; the continuation used by CONTINUE-WHOPPER
is passed to the whopper as two additional arguments that are added to
the lambda-list by defwhopper (never mind why it's two arguments instead
of one, that's a minor implementation detail.)  There are efficiency
issues, discussed much later in this message, that make us wish to keep
whoppers separate from ordinary methods so as not to slow down ordinary
methods.

(4) I don't like :around methods for the irrelevant reason that Stallman's
flavor system has them and he misimplemented them in a way that appears
especially ugly to the user.  Too much of the implementation mechanism
shows through.

None of these reasons is ineluctably compelling, and we could instead
have chosen to make DEFINE-METHOD-COMBINATION insert into the body a call
to a function to take care of the wrappers and whoppers, and then have
provided an option to turn this off and let the method-combination type
take direct control.  I don't see a lot of benefit from this; what would
be accomplished by taking direct control other than surprising the user
by making wrappers and whoppers behave in an unexpected way?  Maybe there
is something that I am not seeing.

    Neither is run-super.  I believe both could be fixed by adding a new
    standard form corresponding to call-component-methods.

    call-first-with-continuations <list-of-methods>

    calls the first on the list, and makes available the list for the called
    method.  If run-super is invoked in the method, it does:

    (call-first-with-continuations (cdr list-of-methods))


    If continue-whopper we spell "run-super", and whopper as ":around", then
    super-daemon method combination (allowing run-super in primary methods)
    is  defined by something like

    (define-method-combination :super-daemon
      ((around "around" :every :base-flavor-last (:around))
       (before "before" :every :base-flavor-last (:before))
       (primary "primary" :every :base-flavor-last (:primary))
       (after "after" :every :base-flavor-first (:after)))
    (call-first-with-continuations 
       '(,. around
	  (multiple-value-prog2 
	     (call-component-methods , before)
	     (call-first-with-continuations ',primary)
	     (call-component-methods ,after)))

    This makes run-super be a feature of method-combination with
    call-first-with-continuations only.  It has the same model as it has in
    Loops and Smalltalk, and computable at method-definition time.

Don't forget that continue-whopper allows changing the arguments that
are passed on to the continuation, whereas run-super does not.  This can
be important sometimes.  I think that's orthogonal to the rest of the
discussion, however.

    I have not thought through a best implementation.  An obvious one is to
    bind the continuation list of functions in a special variable.

    Does this make sense?  It seems to provide a single coherent story. 

There is no question that something along these lines, with the typos
and bugs taken out, could work.  For example, the following code works
in New Flavors (more comments follow the code):


(DEFVAR *SUPERCLASS-CONTINUATIONS*)

(DEFUN RUN-SUPER ()
  (FUNCALL (POP *SUPERCLASS-CONTINUATIONS*)))

(DEFUN CALL-FIRST-WITH-CONTINUATIONS (FORMS)
  (IF (REST FORMS)
      `(STACK-LET ((*SUPERCLASS-CONTINUATIONS*
		     (LIST ,@(MAPCAR (LAMBDA (FORM)
				       `(LAMBDA ()
					  (DECLARE (SYS:DOWNWARD-FUNCTION))
					  ,FORM))
				     (REST FORMS)))))
	 ,(FIRST FORMS))
      (FIRST FORMS)))

(DEFINE-METHOD-COMBINATION :SUPER-DAEMON ()
     ((AROUND "around" :EVERY :MOST-SPECIFIC-FIRST (:AROUND))
      (BEFORE "before" :EVERY :MOST-SPECIFIC-FIRST (:BEFORE))
      (PRIMARY "primary" :EVERY :MOST-SPECIFIC-FIRST () :DEFAULT)
      (AFTER "after" :EVERY :MOST-SPECIFIC-LAST (:AFTER)))
  (CALL-FIRST-WITH-CONTINUATIONS
    (NCONC (MAPCAR #'CALL-COMPONENT-METHOD AROUND)
	   `((MULTIPLE-VALUE-PROG2
	       ,(CALL-COMPONENT-METHODS BEFORE)
	       ,(CALL-FIRST-WITH-CONTINUATIONS
		  (MAPCAR #'CALL-COMPONENT-METHOD PRIMARY))
	       ,(CALL-COMPONENT-METHODS AFTER))))))

(DEFGENERIC SDTEST (X Y)
  (:METHOD-COMBINATION :SUPER-DAEMON))

(DEFFLAVOR SDTEST1 () ())
(DEFFLAVOR SDTEST2 () (SDTEST1))
(DEFFLAVOR SDTEST3 () (SDTEST2))

(DEFMETHOD (SDTEST SDTEST1) (X)
  (LIST 1 X))

(DEFMETHOD (SDTEST SDTEST2) (X)
  (DECLARE (IGNORE X))
  (CONS 2 (RUN-SUPER)))

(DEFMETHOD (SDTEST SDTEST3) (X)
  (DECLARE (IGNORE X))
  (CONS 3 (RUN-SUPER)))

(DEFMETHOD (SDTEST SDTEST2 :AROUND) (X)
  (LIST "[" (RUN-SUPER) "|" X "]"))

(SDTEST (MAKE-INSTANCE 'SDTEST3) 105)
; => ("[" (3 2 1 105) "|" 105 "]")


This implementation could use some additional error checking.  More importantly,
it contains a serious bug.  The dynamic scoping of *SUPERCLASS-CONTINUATIONS*
means that incorrect results can occur when closures from two different generic
function invocations are calling each other.  To get correct operation, the
continuation must be lexically scoped.  If this sounds esoteric, consider the
following example, which has been taken from a real-life program:

(defmethod print-object :around ((object italicized-object) stream)
  (with-character-face (:italic stream)
    (run-super))

which makes any object of class italicized-object print itself in italics.
With-character-face is just a macro that makes output to the given stream
appear in the given face while executing its body.

This looks fine until you expand the with-character-face macro, which
expands into [the following is simplified from what it actually expands
into in Genera]
  (with-style-internal stream ':italic
		       (lambda (stream) (run-super)))
where with-style-internal is a generic function handled by
a stream method that sets up for italic characters and calls
back into the lambda.  If the handling of with-style-internal
also involves :around methods, *SUPERCLASS-CONTINUATIONS* will
be bound and the run-super inside the lambda will call a
with-style-internal method instead of a print-object method.
No good.

Lexically scoping the continuation is possible in New Flavors also.
An extra argument has to be inserted into the arglist of any method
that uses run-super, to receive the continuation, since it can no
longer be passed behind the lambda-list's back in a special variable,
and this code transformation makes everything a little more complicated.
Here is the working, tested code (more comments after the code):


(DEFUN RUN-SUPER ()
  (ERROR "RUN-SUPER not called from a proper lexical environment."))

;;; Call a method, passing the continuation before the regular arguments
(DEFUN CALL-COMPONENT-METHOD-WITH-CONTINUATION (METHOD CONTINUATION-FORM ARGS)
  (CALL-COMPONENT-METHOD METHOD
			 :ARGLIST (LIST `(LAMBDA ()
					   (DECLARE (SYS:DOWNWARD-FUNCTION))
					   ,CONTINUATION-FORM)
					ARGS)
			 :APPLY T))

;;; Call a sequence of methods, each with a continuation that calls the next
;;; method.  The continuation of the last method is the second argument.
(DEFUN CALL-COMPONENT-METHODS-WITH-CONTINUATION (METHODS CONTINUATION-FORM ARGS)
  (IF METHODS
      (CALL-COMPONENT-METHOD-WITH-CONTINUATION
	(FIRST METHODS)
	(CALL-COMPONENT-METHODS-WITH-CONTINUATION
	  (REST METHODS) CONTINUATION-FORM ARGS)
	ARGS)
      CONTINUATION-FORM))

(DEFINE-METHOD-COMBINATION :SUPER-DAEMON-2 ()
     ((AROUND "around" :EVERY :MOST-SPECIFIC-FIRST (:AROUND))
      (BEFORE "before" :EVERY :MOST-SPECIFIC-FIRST (:BEFORE))
      (PRIMARY "primary" :EVERY :MOST-SPECIFIC-FIRST () :DEFAULT)
      (AFTER "after" :EVERY :MOST-SPECIFIC-LAST (:AFTER)))
     (:METHOD-TRANSFORMER
       ;; Insert continuation argument into methods that can call RUN-SUPER
       (:METHOD-ARGLIST
	 (IF (MEMBER (METHOD-OPTIONS FUNCTION-SPEC)
		     '((:AROUND) () (:DEFAULT))
		     :TEST #'EQUAL)
	     (CONS 'RUN-SUPER-CONTINUATION METHOD-ARGLIST)
	     METHOD-ARGLIST))
       ;; Change arglist used for error-checking correspondingly
       (:GENERIC-METHOD-ARGLIST
	 (IF (MEMBER (METHOD-OPTIONS FUNCTION-SPEC)
		     '((:AROUND) () (:DEFAULT))
		     :TEST #'EQUAL)
	     (LIST* (FIRST GENERIC-METHOD-ARGLIST)
		    'RUN-SUPER-CONTINUATION
		    (REST GENERIC-METHOD-ARGLIST))
	     GENERIC-METHOD-ARGLIST))
       ;; Define RUN-SUPER macro locally in the body of such methods
       (:METHOD-BODY
	 (IF (MEMBER (METHOD-OPTIONS FUNCTION-SPEC)
		     '((:AROUND) () (:DEFAULT))
		     :TEST #'EQUAL)
	     (MULTIPLE-VALUE-BIND (DECLARATIONS BODY)
		 (SI:FIND-BODY-DECLARATIONS METHOD-BODY NIL)
	       `(,@DECLARATIONS
		 (IGNORE RUN-SUPER-CONTINUATION)
		 (MACROLET ((RUN-SUPER ()
			      `(FUNCALL RUN-SUPER-CONTINUATION)))
		   ,@BODY)))
	     METHOD-BODY)))
     (:ARGLIST IGNORE &REST ARGS)
  (CALL-COMPONENT-METHODS-WITH-CONTINUATION
    AROUND
    `(MULTIPLE-VALUE-PROG2
       ,(CALL-COMPONENT-METHODS BEFORE)
       ,(CALL-COMPONENT-METHODS-WITH-CONTINUATION
	  PRIMARY
	  `(ERROR "RUN-SUPER past the least-specific method")
	  ARGS)
       ,(CALL-COMPONENT-METHODS AFTER))
    ARGS))

(DEFGENERIC SDTEST-2 (X Y)
  (:METHOD-COMBINATION :SUPER-DAEMON-2))

(DEFFLAVOR SDTEST1 () ())
(DEFFLAVOR SDTEST2 () (SDTEST1))
(DEFFLAVOR SDTEST3 () (SDTEST2))

(DEFMETHOD (SDTEST-2 SDTEST1) (X)
  (LIST 1 X))

(DEFMETHOD (SDTEST-2 SDTEST2) (X)
  (DECLARE (IGNORE X))
  (CONS 2 (RUN-SUPER)))

(DEFMETHOD (SDTEST-2 SDTEST3) (X)
  (DECLARE (IGNORE X))
  (CONS 3.0 (RUN-SUPER)))

(DEFMETHOD (SDTEST-2 SDTEST2 :AROUND) (X)
  (LIST "[" (RUN-SUPER) "|" X "]"))

(SDTEST-2 (MAKE-INSTANCE 'SDTEST3) 105)
; => ("[" (3.0 2 1 105) "|" 105 "]")



I wouldn't want to make either of these the default, because of the
efficiency cost of all this extra mechanism.  This is based on my
prejudice that "normal" programs won't use run-super and shouldn't have
to pay the cost of keeping around the information needed for run-super
to work.  With modest amounts of additional hair in the
:method-transformer, it should be possible to scan the body of the
method for calls to run-super, and generate different code if it is not
present.  It's midnight, though, so I'm going to stop here.

In conclusion: yes, it's possible to do run-super this way, and
presumably it works about as well as any other way of doing run-super.
Yes, it's possible to do whoppers this way, and they work about as well
as any other way of doing whoppers.  You can't do wrappers exactly this
way, since they are macros rather than functions, but there is certainly
no inherent reason that code for wrappers couldn't be written into a
define-method-combination, too.  The big difference between doing these
things this way and doing them the way New Flavors does it now is
primarily that the expensive continuation-passing mechanisms needed to
make whoppers/run-super work are invoked explicitly by using a different
special form to define a whopper than to define a method, instead of
implicitly by calling run-super somewhere in the body of the method, and
secondarily that the hair for wrappers and whoppers is kept hidden from
the user who just wants to define a new type of method-combination
without having to worry about anything complicated.

∂04-Sep-86  2226	Owners-commonloopscore↑.pa@Xerox.COM 	Varia       
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Sep 86  22:26:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 04 SEP 86 22:25:31 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 04 SEP 86
 22:25:18 PDT
Date: 04 Sep 86 22:25 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Varia    
To: commonloopscore↑.pa@Xerox.COM 
Message-ID: <860904-222531-1191@Xerox>


We want to distinguish the type hierarchy from the class lattice.
Therefore, in messages where I say `argument specifier,' I am
not, as Moon suggests, making a typo for `type specifier.'

`Instance of a class' is different from `instance of a flavor' or
`instance of a defstruct.' We've made a parallel class lattice
corresponding to the type hierarchy in CLtL. We decided (today) to flush
ATOM and COMMON from that lattice (vector is an atom). Therefore, a cons
cell is an instance of the CONS class. Because the metaclass of a CONS
cell is not the class CLASS (but is BUILT-IN-CLASS or some such) its
interpretation as an instance is different from that of an instance
meta-class is CLASS. Everything in Common Lisp is an instance of some
class.

Danny and I go around daily on the disposition of method selection.
We now have yet another proposal for it. In this one this example
does what DLW expects:

	(let ((*standard-output* <instance of hairy-display-hardware>))
	     (print foo))

Because the generic function PRINT has as function parameters:

	(object &optional (stream *standard-output*))

Defmethods cannot default unsupplied arguments. Danny's message will
present this new version. (I'm too burned to do it.)

I'm fresh enough, though, to present why I don't like defmethods
creating generic functions. In my view, a generic function is 
something that responds T to (typep <gf> 'function). It has other
information within itself. It has no name but can be associated with
a name, just as in

	(defun foo (x) ...)

the thing in the symbol-function cell has no name but is associated with
the name `FOO.' The parts of the generic function are the discriminating
function, the methods, the function parameters, various class pointers,
and etc. Usually the methods are stored as part of the method object.

Defmethod adds another method to a generic function. That is, it adds a
new subpart to an existing thing. It seems odd to me that adding a new
subpart should create the thing of which it is to become a part. There is
a dimension whose extremity is absolute insanity, and the current proposal
to allow defmethod to create the superpart has a non-zero component of that
dimension. An example of the insanity at the extreme in this dimension is
a possible proposal that

	(setf (car x) 7)

does this

	(progn
	 (unless (and (boundp 'x) (typep x 'cons)) (setq x (cons () ())))
	 (setf (car x) 7))

(Note that Lisp/VM does the equivalent of this

	(setf (symbol-value <symbol>) <symbol>)

when the symbol <symbol> is interned.)

I grant we are not very far down this dimension, but why head that way?

I will be away until monday, so enjoy.

			-rpg-

∂05-Sep-86  1637	Bobrow.pa@Xerox.COM 	Re: Defmethod syntax proposal
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Sep 86  16:36:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 SEP 86 14:49:56 PDT
Date: 5 Sep 86 10:52 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Defmethod syntax proposal
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Thu, 4 Sep 86 18:01 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860905-144956-1108@Xerox>

 Will (defmethod generic option... lambda-list body...) be okay with
you,
  or do we need to keep searching for a suitable syntax?  A more real
  example of the syntax would be
    (defmethod turn-off-valve :before ((v master-valve))
      (unless (check-with-safety-engineer v 'off)
        (unsafe-operator-action "Don't do that!  It will explode")))


    Since all the options for method combination are either keywords or
    numbers and type is not, one can distinguish the cases. 
    If this is not the case, 
    we could insist that there always be such a keyword to start.

  They aren't keywords.  You got fooled by looking at existing examples
where
  by coincidence they were always keywords, but in general it's not
going to
  work to restrict the options attached to a method to be always
keywords.
  There are applications where these are names of things and the names
can
  be any symbol (I think we can safely exclude nil, I hope I'm not
wrong).
 
  Will (defmethod generic option... lambda-list body...) be okay with
you,
  or do we need to keep searching for a suitable syntax?


I don't like having to put an additional item between the generic name
and the lambda-list, especially since I expect most methods to not have
any options declaration.

An alternative syntaxsuggestion:
 
(defmethod name-or-name-and-options lambda-list ...)

where
 name-or-name-and-options = name|
   (name :combination {combine-options}*)|
   (name class-name {combine-options}*)

This makes it somewhat more difficult for CommonLoops type users to use
method combination.  Alternatively, Flavors type use could be made
slightly more difficult by using

 name-or-name-and-options = name|
   (name {combine-options}*)|
   (name (:class class-name) {combine-options}*)
 
I prefer the latter.  Method combination code could process the
 (:class class-name) option and change the method definition as
specified by you.

An arguments for the former is to preserve old Flavors code.
-- danny

∂05-Sep-86  1637	Owners-commonloopscore↑.pa@Xerox.COM 	Varia    [what a useless subject!]   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Sep 86  16:37:19 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 SEP 86 14:53:05 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 05 SEP 86 14:46:41 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75195;
 Fri 5-Sep-86 16:24:21 EDT
Date: Fri, 5 Sep 86 16:24 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Varia    [what a useless subject!]
To: commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860904-222531-1191@Xerox>
Message-ID: <860905162420.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 04 Sep 86 22:25 PDT
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

    We want to distinguish the type hierarchy from the class lattice.

I thought one of the big points of this whole affair was to do just
the opposite, i.e. to unify the type lattice and the class lattice.

    Therefore, in messages where I say `argument specifier,' I am
    not, as Moon suggests, making a typo for `type specifier.'

    `Instance of a class' is different from `instance of a flavor' or
    `instance of a defstruct.' We've made a parallel class lattice
    corresponding to the type hierarchy in CLtL. We decided (today) to flush
    ATOM and COMMON from that lattice (vector is an atom). Therefore, a cons
    cell is an instance of the CONS class. Because the metaclass of a CONS
    cell is not the class CLASS (but is BUILT-IN-CLASS or some such) its
    interpretation as an instance is different from that of an instance
    meta-class is CLASS. Everything in Common Lisp is an instance of some
    class.

Fine, but this doesn't seem to address the terminological dilemma I was
asking about.  What do we call the objects that aren't primitive, when we
need to distinguish them from the object that are primitive?

    Danny and I go around daily on the disposition of method selection.

I've noticed.

    We now have yet another proposal for it. In this one this example
    does what DLW expects:

	    (let ((*standard-output* <instance of hairy-display-hardware>))
		 (print foo))

    Because the generic function PRINT has as function parameters:

	    (object &optional (stream *standard-output*))

    Defmethods cannot default unsupplied arguments. Danny's message will
    present this new version. (I'm too burned to do it.)

I look forward to seeing it.

    I'm fresh enough, though, to present why I don't like defmethods
    creating generic functions. In my view, a generic function is 
    something that responds T to (typep <gf> 'function). It has other
    information within itself. It has no name but can be associated with
    a name, just as in

	    (defun foo (x) ...)

    the thing in the symbol-function cell has no name but is associated with
    the name `FOO.' The parts of the generic function are the discriminating
    function, the methods, the function parameters, various class pointers,
    and etc. Usually the methods are stored as part of the method object.

    Defmethod adds another method to a generic function. That is, it adds a
    new subpart to an existing thing. It seems odd to me that adding a new
    subpart should create the thing of which it is to become a part. There is
    a dimension whose extremity is absolute insanity, and the current proposal
    to allow defmethod to create the superpart has a non-zero component of that
    dimension. An example of the insanity at the extreme in this dimension is
    a possible proposal that

	    (setf (car x) 7)

    does this

	    (progn
	     (unless (and (boundp 'x) (typep x 'cons)) (setq x (cons () ())))
	     (setf (car x) 7))

    (Note that Lisp/VM does the equivalent of this

	    (setf (symbol-value <symbol>) <symbol>)

    when the symbol <symbol> is interned.)

    I grant we are not very far down this dimension, but why head that way?

I understand everything you said above, but none of this talk about
implementation addresses my point, which was concerned with the concepts
that the user thinks about.  Thinking about the implementation first is
not a good way to design something that is easy to use and to
understand, in my opinion.

∂05-Sep-86  1637	Bobrow.pa@Xerox.COM 	Re: Message selection, continued  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Sep 86  16:37:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 SEP 86 15:56:41 PDT
Date: 5 Sep 86 15:56 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Message selection, continued 
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Thu, 4 Sep 86 16:15 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860905-155641-1385@Xerox>

  May I assume that everywhere you say "argument specifier" this is a
typo
  for "type specifier"?  Or are you really introducing a new term here?

Yes "argument specifier" is more general term than type specifier or
class specifier.  It can specify, for example, that the argument must
match a particular individual.  Any extensions people want to make about
specification of arguments would go here.  


In yesterday's round with Gabriel and Co. we came up with the following
proposed new set of rules for message selection. 

1)  All uses of defmethod must be preceded by a defgeneric (but see
discussion *1 below), and the defgeneric and the defmethods must all
have congruent lambda-lists.  defmethods can provide argument-specifiers
on optional arguments (but see 6 below).

2) Defgeneric can have an arbitrary lambda-list. 

3) All default values for optional arguments are provided computed from
forms in the defgeneric.

4) When a generic function is called, it computes and fills in values
for any unsupplied arguments.

5) Discrimination is done on the basis of all provided and filled
values. All methods of the generic function that match are considered.
The most specific method is chosen (rules not given here).  
All provided and filled in values are passed to the method.

6)  Since defmethod argument list cannot have default value forms for
optionals, we make the syntax for defmethod lambda-list be: 

defmethod-lambda-list:= ({required-arg}* [&optional {optional-arg}*])

optional-arg:=
	var-name|
	(var-name arg-specifier)
	(var-name arg-specifier supplied-p-name)

The third form is provided to allow a user to supply a local name for
the supplied-p. This supplied-p is computed by the generic function, and
passed in to the method.  It can then be used locally to allow the
program to override the default value provided from defgeneric.  If only
a supplied-p-name is wanted, he arg-specifier T can be used to match any
argument.

*1) RPG and DLW (I believe) support the minimalist position of insisting
that the user always write the defgeneric themselves, and have it
evaluated before the defmethod.  There are several increasingly
DWIM-like positions that back away from this stricture by allowing
defmethod to call defgeneric if no generic function exists. 

a)  If the defmethod specifies no optional arguments, then a defgenric
form is invoked with the stripped lambda list. 

b) Allow the defmethod to specify optional arguments as above, and
create a stripped lambda list for the constructed defgeneric that has
only var-names for the optional arguments; that is, NIL will be provided
for the values of the optional arguments.  The supplied-p portion of the
optional-arg apecification allows internal resetting of the value of the
arg if desired.  If default values other than NIL are wanted, a
defgeneric form must be used.

c) Return to our previous syntax of defmethod, with 
optional-arg:=
	var-name|
	(var-name [default-value-form [supplied-p-name]])
	((var-name arg-specifier) [default-value-form [supplied-p-name]])
Construct a defgeneric from the defmethod simply stripping out the
arg-specifiers.  An error is signalled if any defmethod has a
default-value-form not equal to the one found in the defgeneric. This
provides a syntactic rather than a semantic check on identity of default
values, as proposed by Moon.  Again, as opposed to Moon's suggestion,
the default-values are all computed in the discriminating function, and
passed to the methods.  supplied-p parameters can also be passed to the
methods from the generic function.

Proposal c also implies that every method must contain the same default
value forms, which violates some modularity.  A possible fix for this is
reinterpret the naked var-name to mean unspecified default-value, or to
specify a funny value :no-default-form that can be used in that place
for optionals.

I like either (b) or (c).  An argument for (c) given to me by Ken Kahn
is that users should move from defun to defmethod as a standard way to
program, even when not providing any argument specifiers.  This means
that all their functions are specializable.  This implies allowing a
defmethod syntax that is identical to defun, with no preceding
declaration.  
	

-- danny

∂05-Sep-86  1638	Owners-commonloopscore↑.pa@Xerox.COM 	Re: Varia    [what a useless subject!]    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Sep 86  16:37:48 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 SEP 86 16:14:38 PDT
Redistributed: commonloopscore↑.pa
Received: from Cabernet.ms by ArpaGateway.ms ; 05 SEP 86 16:13:56 PDT
Date: 5 Sep 86 16:12 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Varia    [what a useless subject!]
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Fri, 5 Sep 86 16:24 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: commonloopscore↑.pa@Xerox.COM
Message-ID: <860905-161438-1438@Xerox>

   We want to distinguish the type hierarchy from the class lattice.

 I thought one of the big points of this whole affair was to do just
 the opposite, i.e. to unify the type lattice and the class lattice.

Right.  RPG was just misguided.  The Common Lisp type lattice is mapped
into the class lattice.  Missing from the class lattice are uses of the
type system that are really predications.  In this category we put the
type atom = (SATISFIES (NOT (CONSP X))
and common (a non-inherited feature) = (SATISFIES (MEMQ X '(CONS ...))

Why do you want to distinguish "primitive" instances from non-primitive
ones.  I thought of the ugly term "non-slotted instances".  Numbers have
no slots.  But one can create objects with no slots using defclass.  One
can also think of CONS cells as having two slots with accessors car and
cdr.  Is there any thing we need to say about these items aside from
their history as Common Lisp types?   


-- danny

∂05-Sep-86  1836	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Re: Defmethod syntax proposal   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Sep 86  18:36:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 SEP 86 17:57:09 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 05 SEP 86 17:52:25 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75306;
 Fri 5-Sep-86 20:51:17 EDT
Date: Fri, 5 Sep 86 20:51 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Defmethod syntax proposal
To: CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860905-144956-1108@Xerox>
Message-ID: <860905205118.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 5 Sep 86 10:52 PDT
    From: Bobrow.pa@Xerox.COM
 
      Will (defmethod generic option... lambda-list body...) be okay with you,
      or do we need to keep searching for a suitable syntax?

    I don't like having to put an additional item between the generic name
    and the lambda-list, especially since I expect most methods to not have
    any options declaration.

I think my syntax description was not clear enough.  I am not proposing
that there be anything between the generic name and the lambda-list when
no options are specified.  Let me give some more examples (just the
first line of each):

(defmethod turn-off-valve ((v valve))

(defmethod turn-off-valve :before ((v master-valve))

(defmethod great-scott piece environmental-impact ((x foo) (y bar))

(defmethod (turn-off-valve valve) ()

(defmethod (turn-off-valve master-valve :before) ()

(defmethod (great-scott foo piece environmental-impact) ((y bar))

    An alternative syntaxsuggestion:
 
    (defmethod name-or-name-and-options lambda-list ...)

    where
     name-or-name-and-options = name|
       (name :combination {combine-options}*)|
       (name class-name {combine-options}*)

    or

     name-or-name-and-options = name|
       (name {combine-options}*)|
       (name (:class class-name) {combine-options}*)
 
    I prefer the latter.  
    
Neither of these turns me on.  I think whichever one involves the
"extra" word (:combination or :class) is going to discourage users
from using that style.  I would rather either use the syntax
exemplified above or use different macros for defining classical
methods and general methods.

    An argument for the former is to preserve old Flavors code.

Yes, one criterion I would like to preserve is that a mechanical
translation program can look at a piece of source text and reliably
classify it into CommonLoops, Flavors, or the new Common Lisp standard.
Mechanical translation tools work more smoothly for users if they
operate correctly on their own output; this makes incremental conversion
of programs a lot easier.

∂05-Sep-86  1836	Owners-commonloopscore↑.pa@Xerox.COM 	Terminology: instances
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Sep 86  18:36:35 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 SEP 86 17:58:00 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 05 SEP 86 17:57:20 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75307;
 Fri 5-Sep-86 20:56:10 EDT
Date: Fri, 5 Sep 86 20:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Terminology: instances
To: commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860905-161438-1438@Xerox>
Message-ID: <860905205611.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 5 Sep 86 16:12 PDT
    From: Bobrow.pa@Xerox.COM

    Why do you want to distinguish "primitive" instances from non-primitive
    ones.  I thought of the ugly term "non-slotted instances".  Numbers have
    no slots.  But one can create objects with no slots using defclass.  One
    can also think of CONS cells as having two slots with accessors car and
    cdr.  Is there any thing we need to say about these items aside from
    their history as Common Lisp types?   

See the discussion on 2-3 September about the awkwardness in Sonya's glossary
that resulted from trying to avoid making this distinction.

∂05-Sep-86  1902	Bobrow.pa@Xerox.COM 	[Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>:   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Sep 86  19:01:42 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 SEP 86 18:49:12 PDT
Date: 5 Sep 86 18:49 PDT
From: Bobrow.pa@Xerox.COM
Subject: [Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>:
 Summary of features we all agree on ]
To: CommonLoopsCore↑.PA@Xerox.COM
cc: Bobrow.pa@Xerox.COM
Message-ID: <860905-184912-1633@Xerox>


     Part I describes the basic tools for defining classes, methods,
generic
     functions, and method combination types, and for making instances
of
     classes.

     DEFINING CLASSES
     
     (DEFCLASS class-name (slot-spec...) (super-class-name...)
option...)

Not quite.  We have the opposite order for (super-class-name...) and
(slot-spec...).

(DEFCLASS class-name (super-class-name...) (slot-spec...) option...)


     class-name is a non-null symbol that names the class being defined.
If a
     class is already defined with this name, this definition replaces
the
     old  definition.  The default meta-class ensures that when the
definition of
     aclass changes, each existing instance of the class is updated to
the new
     format the next time it is accessed.


      Each slot-spec is one of:

       slot-name       a non-null symbol.

        (slot-name initial-value-form)


       (slot-name slot-option...)
         Each slot-option is an option name followed by its value.
         The defined slot-options and their arguments are:

        = initial-value-form
                This an alternate way for providing a default initial
value form.
How is this form distinguished from the previous.  By having more than
two elements???  How do you not give an init value form. 
       :accessor generic-function-name
                     Specifies that a function named
generic-function-name
                     be automatically generated, to read the value of
this
                     slot.  SETF may be used with generic-function name
to
                     write the value of the slot.
OK.  If generic-function-name is NIL then this is a NOOP.  Specified so
programs can generate these.
                :reader generic-function-name
                     Specifies that a function named
generic-function-name
                     be automatically generated, to read the value of
this
                     slot.
We have called this :read-accessor.  We specify that if this is given,
then SETF may NOT be used with this accessor. If generic-function-name
is NIL then this is a NOOP. 
                :initable keyword
                     Specifies a keyword to be used to specify an
initial
                     value of this slot, when a new instance is being
made.
I think this is OK.  Should allow value of NIL.  Default is T
                :allocation
 
:allocation can have values
 :instance (allocated in the instance),
 :class (storage allocated in the class and shared by all instances),
 :dynamic (storage allocated in the instance on first use
    (like Flavors Proplist mixin)
 :none  expect accessor methods for this to be defined for this slot
   in this class
                
:initialize-only flag

If flag = T, then this slot cannot be changed after initialization (a
better name for :read-only).  flag=T implies no accessors are generated.
default is NIL.  

     If no initial value is specified either in the DEFCLASS or the MAKE
form,
     the initial value of the slot is undefined and it is an error to
     reference
     it.  This is the same behavior as a DEFVAR with no
initial-value-form.
We hate these "it is an error" statements.  We haven't discussed this
particular issue.

     Each super-class-name is a non-null symbol.
     
     Each option is one of:
     
         option-name
         (option-name argument...)
     
     Each option-name is a keyword that names an option; the arguments
depend
     on
     the option.

OK
   The set of defined options and their arguments is:
     
    (:accessor-prefix prefix slot-name...)
    (:reader-prefix prefix slot-name...)
    (:default-init-plist keyword-argument...)
    (:initable-slots slot-name...)
    (:init-keywords keyword...)
The only one of these that we have agreed to is:

 (:accessors-with-prefix string-or-symbol)

which causes accessors to be generated with the given prefix for ALL
slots that do not have local specification of any of :accessor,
:read-accessor, or :initialize-only.  If this form does not appear, then
no accessors for slots are generated.

Note they we have made this be a single default that applies uniformly.
No specific slots can be mentioned, and this option can appear only
once.  The arguments for this way of doing business are:
1) Anything not uniform is local to a slot description
2) There are no redundant, possibly inconsistent, declarations

    (:documentation string)

OK   

    (:meta-class class-name)
No, we think this should be done using the meta-object protocol, since
the parsing of the defclass is not under the control of the meta-class.
However, I think we could be convinced otherwise.

    (:required-classes class-name...)
    (:required-init-keywords keyword...)
    (:required-slots slot-name...)
    (:required-methods generic-function-name...)

No.  These seem like environmental features, and should not be part of
the spec.  We should make some comment about how additional options may
be supported by the standard class in particular implementations, and
ones not understood will either be ignored, or have warnings issued.
 
    (:constructor function-name lambda-list)
We have allowed the full generality of the defstruct syntax for this
one.  Do you think it should be restricted to this boa-constructor

     For the :ACCESSOR-PREFIX, :READER-PREFIX, and :INITABLE-SLOTS
options,
     you can omit slot-names to indicate that the option applies for all
slots of
     this class.
See above

     It is legal to specify more than one accessor and reader for a
single
     slot.
We argued about this, and decided we didn't like it.  Why is it good?


     DEFINING METHODS AND SETF METHODS
     
     The general syntax for defining a method is:
     
     (DEFMETHOD generic-function-name method-option...
       method-lambda-list
        body...)

No.  See my earlier message. 
      (DEFMETHOD name-and-options
       method-lambda-list
        body...)


   generic-function-name is a non-null symbol.

name-and-options is a non-null symbol or (name . method-options)

See my earlier message.

     Each method-option is a non-null atom that describes the type of
this
     method.  Some examples of method-options are:  :BEFORE and :AFTER.

     method-lambda-list is a lambda-list with one difference.  Where a
     lambda-list allows only a variable and not a list, a
type-qualified-
     variable may be used.  However, type-qualified-variables cannot be
used
     for
     &aux variables, supplied-p parameters, or &rest parameters.  A
     type-qualified-variable is a list such as:  (variable-name
     type-specifier).
     Note that the use of &optional is still under discussion.

     type-specifier ---tbd---


type-specifer and its uses should be replaced by argument-specifier.
This will include class-names (class-specifiers) and individuals.  The
meaning of argument-specifier may be extended by users who build their
own discriminators.

     For convenience in defining a classical method, the following
syntax is
     provided:
     
     (DEFMETHOD (generic-function-name first-arg-type method-option...)
       method-lambda-list
       body...)
     
     The classical syntax is equivalent to the following expression in
the
     general syntax:
     
     (DEFMETHOD generic-function-name method-option...
       ((self first-type-arg) method-lambda-list...)
       (with (self)
    body...))

See other message

     The general syntax for defining a SETF method is:
     
     (DEFMETHOD-SETF generic-function-name method-option...
       method-lambda-list setf-lambda-list
       body...)
     
     The classical syntax for defining a SETF method is:
     
     (DEFMETHOD-SETF (generic-function-name first-arg-type
method-option...)
       method-lambda-list setf-lambda-list
       body...)
     
     generic-function-name and method-option are the same as for
DEFMETHOD.
     
     setf-lambda-list is a lambda-list containing exactly one required
     parameter, which may be type-qualified.  In other words,
     setf-lambda-list
     is one of:

    (variable-name)
    ((variable-name type-specifier))

Same problem with this syntax.  But we agree that DEFMETHOD-SETF is a
better name.  If you liked my other syntax suggestions, then this one
follows.  Again type-specifier -> argument-specifier.  Are we not
allowing multiple values to be stored.  In the silver book it talks
about extensions to the corresponding list of store variables.  I have
no problem with the restriction.  

     DEFINING GENERIC FUNCTIONS
     
     (DEFGENERIC generic-function-name lambda-list option...)
     
     (DEFGENERIC-SETF generic-function-name lambda-list setf-lambda-list
     option.
     
     generic-function-name is a non-null symbol.
     
     lambda-list is an ordinary lambda-list except no &aux variables are
     allowed.

     setf-lambda-list is (variable-name).

Yes, except that we allow a documentation string before the options.
What do you think???

     Each option is one of:

         option-name
         (option-name argument...)

     Each option-name is a keyword that names an option; the arguments
depend
     on the option.
OK

     The set of defined options and their arguments is:
     
     [--Should declarations and doc strings be allowed?--]
     
              (:documentation string)
See above.
              (:optimize spec...)
Is this for all methods, or just the discriminating function. This seems
weird to me 
              (:method-combination name argument...)
What is the argument in this form?
              (:generic-function-class class-name)
              (:method-class class-name)
              (:order parameter-name...)
We have been using :dispatch-order for the keyword :order.  It should
really be 
:argument-precedence-order.  
                  [more?]

Additional options should be allowed, as in defclass.

            WITH
     
         We have agreed that WITH should exist, but we haven't decided
anything
         more specific about it yet.
Right; we haven't decided anything yet.  There are two different
proposals under discussion.  One turns names in calls on the accessors
(we call that one WITH).  The other turns them into primitive slot
accesses (we call that one %WITH).


     DEFINING NEW TYPES OF METHOD COMBINATION
     
     (DEFINE-SIMPLE-METHOD-COMBINATION name operator-name
                                       [single-arg-is-value]
                                       [pretty-name])
     
     This function defines a new type of method combination in which all
the
     methods are called and their values are passed to the operator
specified
     by
     operator-name.
     
     name is a non-null symbol, often a keyword, that is the name of the
type
     of method combination being defined.

     operator-name can be a symbol or a lambda-expression,
     the name of a function, a macro, or a special form.

     single-arg-is-value is t or nil; by default it is nil.
     
     pretty-name is a string.  It defaults to the lower case version of
the
     supplied name.

We haven't agreed to this at all yet.  super-daemon method combination
we believe in. But this simple case seems strange to me, and if it can
be defined with the stronger DEFINE-METHOD-COMBINATION, then let's not
put it in the spec.  

I didn't see whoppers described in daemon combination section of the
Flavors manual -- at least not in the early section.  Does this mean
that it is not a feature of daemon combination?

We believe that at least on the west coast, run-super will be used much
more than daemon combination.  Hence my attempt to unify them.  An
answer to Moons answer next week.  

     (DEFINE-METHOD-COMBINATION method-combination-type-name
                                lambda-list
                                (method-pattern...) option... body...)
     
     This function behaves the same way as in Flavors.  See the Flavors
     documentation for details.

We believe that a simple version of this should be in the spec.  I don't
know yet what simple means.  At least powerful enough to define the
extended features, but not including the full library of standardly
available combinations types.

     Making a New Instance
     
     (MAKE class-name keyword-argument...)
     
     MAKE is the function that makes and initializes an instance of a
class.
     The allowed keyword-arguments depend on the DEFCLASS form.  Any
keyword
     specified with the :INITABLE, :INITABLE-SLOTS, or :INIT-KEYWORDS
option
     is allowed.

     If a keyword-argument is given to MAKE, it overrides any default
that is
     given in the DEFCLASS form, such as the :DEFAULT-INIT-PLIST option,
or
     the initial-value-form syntax.

Modulo isssues on keywords and specification of initable, this is
basically correct.


     OTHER FUNCTIONS
     
     Other functions of interest to the general programmer [---tbd---].
     
     This list came from the 8 August meeting; it can serve as a
starting
     agenda
     for this section:
     
         find-flavor / class-named
Yes class-named
         typep
classp is the right name
         type-of
         class-of
Yes on class-of
         operation-handled-p ??
Something like this is needed
         remove-class
	    remove-method
	    change-class
Yes


-- danny

∂05-Sep-86  1955	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Methods Selected by Predications More General Than Classes    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Sep 86  19:55:26 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 SEP 86 19:53:35 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 05 SEP 86 19:53:11 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75331;
 Fri 5-Sep-86 22:52:05 EDT
Date: Fri, 5 Sep 86 22:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Methods Selected by Predications More General Than Classes
To: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860905225205.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

The following message appears to have been lost in the network.
At least, it's not in the archive, and Danny's messages indicate
that he obviously hasn't read it.  Maybe what really happened is
that I forgot to send it, but just edited it into my own file.
In any case, here it is.


CommonLoops allows method selection by classes and by one kind of
predication, equality to a constant (EQL, I presume).  If we're going to
go more general than classes, we should allow the full generality of
Common Lisp types, i.e. arbitrary predications.  The problem with that
is that there can be predications that have objects in common, but do
not have a subtype/supertype relationship.  Thus if methods are defined
for both predications, it is not clear which method has precedence.

I think the answer is that actually encountering such a method ambiguity
signals an error, but that should not stop you from defining a method on
one predication, only from defining methods on two overlapping
predications.  Note that by shadowing the ambiguous method pair with a
method on a more specific class you can prevent the error from being
signalled (I say a more specific class rather than a more specific
predication because the specificness of course has to be computable--see
below).

I strongly believe that it would be a mistake for the type specifiers
in methods to be a whole different type system from the regular Common
Lisp type system.  Methods should either allow their arguments to be
qualified with any Common Lisp type specifier, or should restrict the
allowable type specifiers to a certain subset, but there absolutely
should not be extensions to the Common Lisp type system that only work
in method argument lists.  That would be too confusing.  This means that
the way CommonLoops does methods on individuals now is out.  If we're
going to include methods on individuals in the standard, they have to
be done with MEMBER, not with QUOTE.  I believe that in fact methods
on arbitrary predications can be implemented, allowing the whole Common
Lisp type system to be supported, and the remainder of this message
is a sketch of one way to implement that.


Any predication can be converted to the canonical form

  (OR (AND class1 test1)
      (AND class2 test2)...)

where each test is any Common Lisp type expression, and the classes are
all distinct.  Any Common Lisp type expression specifies a set of
objects that all belong to some class, even if it's T, along with a
restriction to a subset of the total membership of that class.  OR is
introduced essentially as a performance optimization for method
dispatching, to cut down the frequency of resorting to T as the class
for Common Lisp's OR type specifiers.  Some kind of rule is required to
decide between minimizing the number of terms in the OR and using the
least general classes.  It would also be convenient, but not essential,
to have rules for canonical ordering of the OR terms and canonical
formation of the test type expressions.  Some examples:

  class-name = (OR (AND class-name T))

  (UNSIGNED-BYTE 8) = (OR (AND FIXNUM (INTEGER 0 255)))
    ;assuming FIXNUM is a class on its own, rather than just having INTEGER

  (NOT FLOAT) = (OR (AND T (NOT FLOAT)))

Any two predications can be compared.  In fact SUBTYPEP could be used,
but it's easier to think about in terms of the canonical form.  I could
write down the rules for how to compare canonical forms in terms of
class precedence and SUBTYPEP on the tests.  The result can be a
definite ordering of the predications <, =, >, or disjoint; the latter
means that it is definitely known that no object can satisfy both
predications.  The result can also be that the ordering is uncomputable;
this happens when the same class has two different tests and the
ordering of the tests is uncomputable, e.g. SATISFIES of two different
functions.  When the ordering is uncomputable, all this means is that
less optimization of the discriminating function is possible; at run time
both predications must be evaluated, and if both are true an error must
be signalled.  The discriminating function would exploit the class portion
of the canonical form to avoid evaluating predications when it can prove
from the class that they must be false.

Aside: I don't know whether it's in general safe to trust every
implementation's SUBTYPEP function to work.  It would be a pity if the
portable OOP system had to duplicate that functionality.

Aside: I believe the type COMMON is a predication, not a class.
I think so not only because it's so ill-defined, but also because
I can see how you might conceivably define methods on COMMON but
I don't see the point to having a class inherit from COMMON.

As for NULL and VECTOR, we get to decide whether these types are classes
or predications.  I think it's clear that VECTOR should be a class,
and we just have to choose some precedence order of ARRAY and SEQUENCE.
The advantage of making NULL a predication rather than a class is that
method clashes between the SYMBOL and LIST classes are guaranteed to
signal an error, instead of using whichever non-obvious precedence order
we happened to choose.

∂08-Sep-86  1458	RPG   	Re: Defmethod syntax proposal    
 ∂08-Sep-86  0945	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Re: Defmethod syntax proposal   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 86  09:45:22 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 SEP 86 09:12:45 PDT
Redistributed: CommonLoopsCore↑.PA
Received: from Cabernet.ms by ArpaGateway.ms ; 08 SEP 86 09:11:09 PDT
Date: 8 Sep 86 09:10 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Defmethod syntax proposal
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Fri, 5 Sep 86 20:51 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860908-091245-2678@Xerox>

In thinking about it over the weekend, I realized that the syntax we proposed

(defmethod name-or-name-and-options lambda-list ...)

where  name-or-name-and-options = name|
       (name {combine-options}*)|
       (name  class-name {combine-options}*)

is completely unambiguous whether one is using "classical" syntax and general syntax.
In "classical" syntax, no argument of lambda-list can be type specified.
In general syntax at least one must be specifed if you are using
method combination options.

<classical-method-def>:=(demethod (generic-name type .{combine-options}*)
   unqualified-lambda-list body)
<general-method-def>:=(defmethod name qual-or-unqualified-lambda-list body)|
    (defmethod (name . {combine-options}*) qualified-lambda-list body)


I do not like having two syntax's as part of the standard.  The difference
in typing is only four characters (self) and the general syntax makes it clear what
variable is being used.  With compatibility assured, certain implementations
could support the "classical" syntax as a convenience
or a backwards compatibility feature.

In this case I guess I take a minimimalist position.  


-- danny

∂08-Sep-86  1500	RPG   	Re: Defmethod syntax proposal    
 ∂08-Sep-86  1043	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Re: Defmethod syntax proposal   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 86  10:42:47 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 SEP 86 10:02:36 PDT
Return-Path: <Moon@YUKON.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA@XEROX.ARPA
Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by Xerox.COM ;
 08 SEP 86 10:00:04 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM
 via CHAOS with CHAOS-MAIL id 81811; Mon 8-Sep-86 12:57:58 EDT
Date: Mon, 8 Sep 86 12:58 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Defmethod syntax proposal
To: CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860908-091245-2678@Xerox>
Message-ID: <860908125848.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 8 Sep 86 09:10 PDT
    From: Bobrow.pa@Xerox.COM

    In thinking about it over the weekend, I realized that the syntax we proposed

    (defmethod name-or-name-and-options lambda-list ...)

    where  name-or-name-and-options = name|
	   (name {combine-options}*)|
	   (name  class-name {combine-options}*)

    is completely unambiguous whether one is using "classical" syntax and general syntax.
    In "classical" syntax, no argument of lambda-list can be type specified.
    In general syntax at least one must be specifed if you are using
    method combination options.

    <classical-method-def>:=(demethod (generic-name type .{combine-options}*)
       unqualified-lambda-list body)
    <general-method-def>:=(defmethod name qual-or-unqualified-lambda-list body)|
	(defmethod (name . {combine-options}*) qualified-lambda-list body)

That was my original proposal, which foundered on the CommonLoops "default
method" feature, which allows defining a "general" method with no type
specifiers.  I don't see why method combination options would be
disallowed for default methods.  If it doesn't make sense to allow such
options for default methods, then we can go back to that proposal.  I'd be
willing to give up the feature of type qualifying additional arguments
while still using classical syntax, for the sake of agreement.

    I do not like having two syntax's as part of the standard.  The difference
    in typing is only four characters (self) and the general syntax makes it clear what
    variable is being used.  

No, the important difference is that in the classical syntax you don't have to
say "with" explicitly.

			     With compatibility assured, certain implementations
    could support the "classical" syntax as a convenience
    or a backwards compatibility feature.

    In this case I guess I take a minimimalist position.  

I wasn't able to figure out what this means.

∂08-Sep-86  1500	RPG   	Class versus Type System    
 ∂08-Sep-86  1043	Owners-commonloopscore↑.pa@Xerox.COM 	Class versus Type System   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 86  10:43:08 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 SEP 86 10:26:33 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 08 SEP 86
 10:26:19 PDT
Date: 08 Sep 86 10:25 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Class versus Type System
To: commonloopscore↑.pa@Xerox.COM 
Message-ID: <860908-102633-2759@Xerox>


For those who have problems with English, I'll rephrase my remark
and add a few more.

Rephrased remark:

We, the people who are designing the new specification of the Common Lisp
Object System, must take into consideration the fact that, as it currently
stands, there is a distinction between the Common Lisp type system and the
proposed Common Lisp Object System class system.  In order for us to keep
our own terminology straight, I have proposed the term `argument
specifier,' which, loosely speaking, is equivalent to the term `type
specifier' that Moon uses.

Further remarks:

(1) I believe that the Common Lisp type, COMMON, is well-defined. However,
it is possible that people do not have a good model of what it comprises;
also it is possible that COMMON would not be a particularly useful class
within the context of the Common Lisp Object System class system.

(2) Extending the Common Lisp Object System class system to include the
sorts of type predications that the Common Lisp type system admits strikes
me as misguided. First, considering implemenations, SUBTYPEP does not, I
believe, behave uniformly over all Common Lisp implementations; that is, I
believe, although I have no examples at hand, that are two Common Lisp
implementations and two type specifiers, S1 and S2, such that one
implementation returns the values NIL NIL when it evaluates the expression
(subtypep s1 s2) whereas the second implementation returns NIL T when it
evaluates the same expression: it is possible that worse discrepancies
exist. Second, considering implementation technology, the Common Lisp
implementations that supply a SUBTYPEP that behaves in such a way that
most observers would conclude that those Common Lisp systems supply a
SUBTYPEP that produces the most consistently accurate results over a set
of test cases for SUBTYPEP, where the observers are considering most of
the available Common Lisp systems, are Common Lisp systems in which the
implementation of SUBTYPEP is more inefficient than those that are judged
to be less accurate.  The implication of this observation is that generic
function invocation is likely to be an expensive operation if SUBTYPEP is
used as part of the basic method selection implementation.  The
implication of the first observation is that it is likely that it will be
required of the implementors of the basic method selection functions to
use a common implementation (at some level of abstraction), or else the
behavior of the basic method selection functions will need to be specified
in great detail. My third remark is based on hearsay: I know three
mathematicians who regard the Common Lisp type system and SUBTYPEP
in particular with extreme disdain. If any reader of this wishes, I will
interview these individuals to learn their reasons for disdain and 
report those reasons.

			-rpg-

∂08-Sep-86  1529	RPG   	Re: Methods Selected by Predications More General Than Classes 
 ∂08-Sep-86  1147	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Re: Methods Selected by Predications More General Than Classes
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 86  11:47:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 SEP 86 10:51:10 PDT
Redistributed: CommonLoopsCore↑.PA
Received: from Cabernet.ms by ArpaGateway.ms ; 08 SEP 86 10:50:46 PDT
Date: 8 Sep 86 10:50 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Methods Selected by Predications More General Than Classes
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Fri, 5 Sep 86 22:52 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860908-105110-2796@Xerox>

     The following message (about arg specification) appears to have
been lost in the network...  
I had not seen it.

  I strongly believe that it would be a mistake for the type specifiers in
  methods to be a whole different type system from the regular Common Lisp
  type system.  Methods should either allow their arguments to be qualified
  with any Common Lisp type specifier, or should restrict the allowable type
  specifiers to a certain subset, but there absolutely should not be
  extensions to the Common Lisp type system that only work in method
  argument lists.  That would be too confusing.

I disagree.  I think the set of specifiers for methods need not overlap
the Common Lisp type system. Therefore I do not feel at all
uncomfortable with having a different set of specifications based on
classes and individuals.   

HOWEVER, after rereading Moon's message, I felt that he has proposed a
reasonable extension to the current specification mechanism.  Subtypep
must be extended to include

(subtypep class-name1 class-name2) 
  if (subclassp (class-named class-name1) (class-named  class-name2))

I would want to extend the type system to deal with
  (QUOTE inst) as a short hand for
  (SATISFIES (MEMBER '(inst))
since individuals are so useful in type specification.

This imlies the following which is peculiar but OK.
(typep x ''inst) = (eql x 'inst) 


We can think of methods for a generic function as specifying a (nested)
set of guarded clauses. The nesting is determined by subtypep
relationships.  


I think we must trust every implementations subtypep, despite Moon's
worry.  Having two different but similar features in the language is
exactly what we are trying to avoid extending the argument specification
to the full type system.

Since the implementation for classes and individuals as specifiers will
clearly be both the most efficient, and most useful, we might postpone
the description of this to the advanced chapter.

Moon's OR hack should be in implementation notes.


-- danny

∂08-Sep-86  1533	RPG   	Class versus Type System    
 ∂08-Sep-86  1147	Owners-commonloopscore↑.pa@Xerox.COM 	Class versus Type System   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 86  11:47:42 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 SEP 86 11:39:07 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 08 SEP 86 11:38:43 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 76448;
 Mon 8-Sep-86 14:13:18 EDT
Date: Mon, 8 Sep 86 14:13 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Class versus Type System
To: commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860908-102633-2759@Xerox>
Message-ID: <860908141318.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 08 Sep 86 10:25 PDT
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
    ....The implication of this observation is that generic
    function invocation is likely to be an expensive operation if SUBTYPEP is
    used as part of the basic method selection implementation.

Since method selection operates (conceptually; I'm not talking about
implementations, which no doubt will all use techniques that are more
optimal than this, but provide the same semantics) by doing a series
of TYPEP tests where the first argument is an argument to the generic
function and the second argument is a type specifier from the lambda list
of a method, I fail to see how the expense of SUBTYPEP could affect the
expense of generic function invocation, since even conceptually SUBTYPEP
is not called during generic function invocation.

The thing SUBTYPEP is useful for is deciding in what order to do those
TYPEP tests.  This happens when constructing the discriminator, not
every time a generic function is invoked.

It's all the same to me if we decide that for practical or other reasons
we don't want to generalize to allow arbitrary Common Lisp type
specifiers to qualify method arguments, but instead decide to limit
these to some subset, even as small a subset as just class names.  Even
though I think it's quite clear how to do the full generalization, I am
always opposed to premature standardization on ideas that have not been
tested in the field.  As I've said before, the one thing we must not do
is to develop yet another type system that is not just a subset of the
regular type system.

    ....The
    implication of the first observation is that it is likely that it will be
    required of the implementors of the basic method selection functions to
    use a common implementation (at some level of abstraction), or else the
    behavior of the basic method selection functions will need to be specified
    in great detail.

Surely it will be a disaster if the specification of this standard is so poor
that users can't figure out what it specifies, except by experimenting with
a particular implementation that is said to implement the standard.  I hope I
misunderstood you.

∂08-Sep-86  1535	RPG   	Generic Functions Defined by Defmethod     
 ∂08-Sep-86  1245	Owners-commonloopscore↑.pa@Xerox.COM 	Generic Functions Defined by Defmethod    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 86  12:45:05 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 08 SEP 86 11:54:23 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 08 SEP 86
 11:53:50 PDT
Date: 08 Sep 86 10:53 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Generic Functions Defined by Defmethod 
To: commonloopscore↑.pa@Xerox.COM 
Message-ID: <860908-115423-2902@Xerox>


My comments regarding the situation in which DEFMETHOD creates
a generic function in case there is not already one is based on
my belief of the model that users will develop for generic functions
rather than on implementation considerations, which considerations Moon
believes that I have in mind when I make such remarks.

Let me be more precise. Consider the combination

	(defmethod gf ...)

and let us suppose that there is no generic function already
associated with the name, `gf.' Should the defmethod expression
above create a generic function and associate it with the name,
`gf'? My belief of the model that most users of the Common Lisp
Object System will develop is that of a generic function being an
object, some of whose parts comprise the methods defined or specified
by the various defmethod forms which are evaluated and which 
specify the same name with which the generic function in question
is associated. Given the belief that generic functions are primary,
will users be confused by the fact that defmethod, a special form
or macro that is used to define a subpart of an object, creates the
object of which it is a subpart if the object does not already exist?
I believe that they will be confused.

There are two techniques we can use to define defmethod in such a
way that defmethod will create the generic function in case it does
not already exist:

	(1). we can define a generic function as an abstract data type
	     whose signature (the operations that can be used on instances
	     of the abstract data type) includes defmethod along with the
	     functionality of creating generic functions.

	     One possible concern with this approach is that the signature
	     requires possibly confusing-to-the-user behavior from such
	     functions as SYMBOL-FUNCTION. I have not explored this behavior
	     in detail.

	(2). we can state that when the Common Lisp Object System is loaded,
	     every symbol has (or can be considered to have) a generic function
	     associated with it such that this default generic function has no
	     methods associated with it and such that the other properties of
	     the generic function have such default values as we may define.

	     In this way, DEFMETHOD can be crisply defined to operate on
	     the subparts of a generic function while still retaining
	     the functionality Bobrow desires.

I apologize to Moon for the fact that my explanation of my belief of the
model that users will develop for generic functions included an analogy
which was presented using a piece of code, which presentation in terms of
code apparently caused him to believe that my concern was for the
implementation details of generic functions rather than for the user model
of the situation.

			-rpg-

∂08-Sep-86  1537	RPG   	Re: Defmethod syntax proposal    
 ∂08-Sep-86  1413	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Re: Defmethod syntax proposal   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 86  14:13:15 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 08 SEP 86 13:13:17 PDT
Redistributed: CommonLoopsCore↑.PA
Received: from Cabernet.ms by ArpaGateway.ms ; 08 SEP 86 13:13:06 PDT
Date: 8 Sep 86 13:13 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Defmethod syntax proposal
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Mon, 8 Sep 86 12:58 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860908-131317-2999@Xerox>


     I don't see why method combination options would be disallowed for
     default methods.  If it doesn't make sense to allow such options
     for default methods, then we can go back to that proposal. 

I think of defmeth with no argument specification as basically a defun
followed by a make-specializable.  If one wants to provide combination
for all methods, than a class specifier of T would allow use of method
combination with full scope. 

     No, the important difference is that in the classical syntax you
don't
     have to say "with" explicitly.

I think it might be a good idea to provide a simple syntax for WITH in
the type specification; for example, ((X class-foo :with-vars)  in the
arglist.

	    With compatibility assured, certain implementations
         could support the "classical" syntax as a convenience
         or a backwards compatibility feature.
     
         In this case I guess I take a minimimalist position.  
     
    I wasn't able to figure out what this means.

I meant that I propose that we not describe classical syntax as part of
the standard.  It would simply be a backwards compatibility feature for
Flavors users.  


-- danny

∂08-Sep-86  1654	RPG   	Re: Defmethod syntax proposal    
 ∂08-Sep-86  1614	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Re: Defmethod syntax proposal   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 86  16:10:29 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 08 SEP 86 15:50:27 PDT
Return-Path: <DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 08 SEP 86 15:50:12 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 76801;
 Mon 8-Sep-86 18:39:41 EDT
Date: Mon, 8 Sep 86 18:41 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: Defmethod syntax proposal
To: Bobrow.pa@Xerox.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860908-131317-2999@Xerox>
Message-ID: <860908184131.4.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: 8 Sep 86 13:13 PDT
    From: Bobrow.pa@Xerox.COM

    I meant that I propose that we not describe classical syntax as part of
    the standard.  It would simply be a backwards compatibility feature for
    Flavors users.  

It's really more than that; it provides conceptual compatibility for
people who are familiar with most any of the other existing
object-oriented programming languages, particularly Smalltalk-80.
It provides the familiar concepts of instance variables and "self".
Because of the widespread establishment of these concepts, I think
it's worth putting this into the standard for everyone, despite the
minor inelegance of having two syntaxes when only one is logically
necessary.

∂08-Sep-86  1654	RPG   	Generic Functions Defined by Defmethod     
 ∂08-Sep-86  1614	Owners-commonloopscore↑.pa@Xerox.COM 	Generic Functions Defined by Defmethod    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 86  16:10:22 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 08 SEP 86 15:29:40 PDT
Return-Path: <DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 08 SEP 86 15:29:22 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 76792;
 Mon 8-Sep-86 18:28:03 EDT
Date: Mon, 8 Sep 86 18:29 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Generic Functions Defined by Defmethod 
To: RPG@SAIL.STANFORD.EDU, commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860908-115423-2902@Xerox>
Message-ID: <860908182948.3.DLW@CHICOPEE.SCRC.Symbolics.COM>

I understand the point you're making.  As I've said, I'm undecided on
this issue personally, but since I believe I understand the other side
of the argument, I'll speak for it.  I think the answer to your point is
as follows:

The analogy you presented with cons cells, is, as you said, extreme.
The opposite extreme analogy might be to insist that, in Lisp, one
explicitly create each symbol before using it, by calling intern on a
string, or something.  After all, the appearance of a symbol means that
it should be looked up in a table; isn't it confusing that sometimes it
should create a symbol rather than looking one up?

Or, to abandon extreme analogies and speak more plainly, the proposed
conceptual model for why defmethod should create a generic function is
that "it's like intern"; the first mention causes an automatic creation,
to save you the trouble of doing one manually.

∂08-Sep-86  1727	RPG   	Re: Defmethod syntax proposal    
 ∂08-Sep-86  1705	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Re: Defmethod syntax proposal   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 86  17:05:04 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 08 SEP 86 16:13:56 PDT
Redistributed: CommonLoopsCore↑.PA
Received: from Cabernet.ms by ArpaGateway.ms ; 08 SEP 86 16:13:39 PDT
Date: 8 Sep 86 16:13 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Defmethod syntax proposal
In-reply-to: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>'s
 message of Mon, 8 Sep 86 18:41 EDT
To: DLW@ALDERAAN.SCRC.Symbolics.COM
cc: Bobrow.pa@Xerox.COM, CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860908-161356-3282@Xerox>

       Date: 8 Sep 86 13:13 PDT
         From: Bobrow.pa@Xerox.COM
     
         I meant that I propose that we not describe classical syntax as
part
         of the standard.  It would simply be a backwards compatibility
feature  
         for Flavors users.  
     
     It's really more than that; it provides conceptual compatibility
for
     people who are familiar with most any of the other existing
     object-oriented programming languages, particularly Smalltalk-80.
     It provides the familiar concepts of instance variables and "self".
     Because of the widespread establishment of these concepts, I think
     it's worth putting this into the standard for everyone, despite the
     minor inelegance of having two syntaxes when only one is logically
     necessary.

(defmethod foo ((self class-name) ...) provides self as a cliche, and
allows those users the optioning of providing a more mnemonic name for
self.  Instance variables (or slots as we are calling them) are
available in either case.  Using the general syntax also encourages
users to remmber that this is a generic function and others may define
extensions (new defmethods) that specialize more than one argument.  I
think that separate syntax will cause mind bugs of the sort -- 'well I
did a "classical" defmethod so now I can't specialize other args.'



-- danny

∂08-Sep-86  1728	RPG   	Class versus Type System    
 ∂08-Sep-86  1707	Owners-commonloopscore↑.pa@Xerox.COM 	Class versus Type System   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Sep 86  17:05:20 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 08 SEP 86 16:21:02 PDT
Return-Path: <DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 08 SEP 86 16:20:48 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 76812;
 Mon 8-Sep-86 19:19:38 EDT
Date: Mon, 8 Sep 86 19:21 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Class versus Type System
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860908141318.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860908192128.5.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Mon, 8 Sep 86 14:13 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    Surely it will be a disaster if the specification of this standard is so poor
    that users can't figure out what it specifies, except by experimenting with
    a particular implementation that is said to implement the standard.  I hope I
    misunderstood you.

Well, I think RPG is probably right about SUBTYPEP being inconsistent
from one implementation to the next.  As I see it, SUBTYPEP is answering
the following question: "Is it the case that for all objects X, such
that X is of type T1, it is necessarily true that X is of type T2"?  The
problem is that there are two interpretations of this question.  One
interpretation asks "... for all objects X where X is any object that
can exist in this particular superset of Common Lisp ...", and the other
interpretation asks "... for all objects X where X is any object that
can exist in every Lisp that is a subset of Common Lisp ...".  If two
implementations both use the first interpretation, it's easy to see how
they might be inconsistent.

I think that specific cases of this problem have been discussed on
Common-Lisp, but I don't remember the details.  I could be wrong about
this.  They have to do with areas in which the implementor is given
latitude, such as the decision of how to implement instances of
defstructs and things like that.  An easy example might be
  (subtypep 'single-float 'short-float)
in an implementation in which they are the same thing.  This
form returns T T in our implementation.

∂09-Sep-86  2035	RPG   	Re: Subtypep 
 ∂09-Sep-86  1947	Bobrow.pa@Xerox.COM 	Re: Subtypep  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Sep 86  19:47:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 SEP 86 17:52:00 PDT
Date: 9 Sep 86 17:46 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Subtypep 
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 08 Sep 86
 17:35 PDT
To: RPG@SAIL.STANFORD.EDU
cc: commonloopscore↑.pa@Xerox.COM
Message-ID: <860909-175200-1153@Xerox>

     CLASS-OF will be as poorly defined as the current TYPE-OF.

Why is this ill-defined?  It is not TYPE-OF.  It returns the most
specific class for the instance.


-- danny

∂09-Sep-86  2244	RPG   	Re: Summary of features we all agree on    
 ∂09-Sep-86  2158	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Re: Summary of features we all agree on   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Sep 86  21:58:11 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 09 SEP 86 21:41:34 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA@XEROX.ARPA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 09 SEP 86 21:40:45 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 99736; Wed
 10-Sep-86 00:39:48 EDT
Date: Wed, 10 Sep 86 00:39 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: Summary of features we all agree on
To: CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860905-184912-1633@Xerox>
Message-ID: <860910003916.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

  Date: 5 Sep 86 18:49 PDT
  From: Bobrow.pa@Xerox.COM
  
    (DEFCLASS class-name (slot-spec...) (super-class-name...)
       option...)
  
  Not quite.  We have the opposite order for (super-class-name...)
  and (slot-spec...).
  
  (DEFCLASS class-name (super-class-name...) (slot-spec...)
  option...)

We can probably go along with this, but it ought to be
discussed.  What was the motivation for changing the order?

    class-name is a non-null symbol that names the class being
    defined.  If a class is already defined with this name, this
    definition replaces the old definition.  The default
    meta-class ensures that when the definition of a class
    changes, each existing instance of the class is updated to the
    new format the next time it is accessed.
  
     Each slot-spec is one of:
  
      slot-name       a non-null symbol.
  
       (slot-name initial-value-form)
  
  
      (slot-name slot-option...)
	Each slot-option is an option name followed by its value.
	The defined slot-options and their arguments are:
  
       = initial-value-form
	       This an alternate way for providing a default
	       initial value form.
  
  How is this form distinguished from the previous.  By having more than
  two elements???  

Yes.  (slot-name initial-value-form) is a convenient
abbreviation for (slot-name = initial-value-form).

		   How do you not give an init value form. 

The way you omit the initial value form when giving slot-options
is to omit the = slot-option.  I thought this was discussed in
the mail a while back but I could be misremembering.

By the way I'm not wedded to the name "=".  I couldn't think of
a clearer name when I tried for a few minutes, but perhaps
someone else can.

      :accessor generic-function-name
	    Specifies that a function named generic-function-name
	    be automatically generated, to read the value of this
	    slot.  SETF may be used with generic-function name to
	    write the value of the slot.
  
  OK.  If generic-function-name is NIL then this is a NOOP.
  Specified so programs can generate these.
  
      :reader generic-function-name
	    Specifies that a function named generic-function-name
	    be automatically generated, to read the value of this
	    slot.
  
  We have called this :read-accessor.  

I think users would find the distinction between :read-accessor
and :accessor confusing.  Perhaps we need some more opinions
here, it's a difficult judgement.

				       We specify that if this is
  given, then SETF may NOT be used with this accessor. If
  generic-function-name is NIL then this is a NOOP.
  
Agreed.

      :initable keyword
	    Specifies a keyword to be used to specify an
	    initial value of this slot, when a new instance is
	    being made.
  
  I think this is OK.  Should allow value of NIL.  Default is T

I don't think you meant it when you said "default is T", since
the argument is a keyword.  If you meant that unless the
programmer specifies otherwise, all slots can be initialized by
MAKE with keywords chosen by default, I don't think that is good
data abstraction.  I don't think slots should be visible from
outside of the module that owns a class unless the definer of
the class explicitly makes them visible.  We can provide a
defclass option that makes it very easy to make all the slots
initializable, but the default should be that features like this
are turned off until the programmer turns them on.  This is the
same argument as the one that made us all decide that slot
accessors are not created unless the programmer asks for them.

      :allocation
   
  :allocation can have values
   :instance (allocated in the instance),
   :class (storage allocated in the class and shared by all
	   instances),
   :dynamic (storage allocated in the instance on first use
      (like Flavors Proplist mixin)
   :none  expect accessor methods for this to be defined for
     this slot in this class

We need to discuss which of these allocation options belong in
the standard.  Maybe only a subset of them.

  :initialize-only flag
  
  If flag = T, then this slot cannot be changed after
  initialization (a better name for :read-only).  flag=T implies
  no accessors are generated.  default is NIL.
  
Do we really need this feature?  Why not just leave out the
:accessor if we don't want people to be able to setf the slot?

    If no initial value is specified either in the DEFCLASS or the
    MAKE form, the initial value of the slot is undefined and it
    is an error to reference it.  This is the same behavior as a
    DEFVAR with no initial-value-form.
  
  We hate these "it is an error" statements.  We haven't discussed
  this particular issue.

I don't think the object-oriented programming standard should
try to be the error-handling standard, too!  Let's just say that
referencing an uninitialized slot has the same error
characteristics as referencing an uninitialized special
variable, and leave it to the rest of the language to define
just what that is.

    Each super-class-name is a non-null symbol.
    
    Each option is one of:
    
	option-name
	(option-name argument...)
    
    Each option-name is a keyword that names an option; the
    arguments depend on the option.
  
  OK
  
    The set of defined options and their arguments is:
      
     (:accessor-prefix prefix slot-name...)
     (:reader-prefix prefix slot-name...)
     (:default-init-plist keyword-argument...)
     (:initable-slots slot-name...)
     (:init-keywords keyword...)
  
  The only one of these that we have agreed to is:
  
   (:accessors-with-prefix string-or-symbol)
  
  which causes accessors to be generated with the given prefix for
  ALL slots that do not have local specification of any of
  :accessor, :read-accessor, or :initialize-only.  If this form
  does not appear, then no accessors for slots are generated.

  Note they we have made this be a single default that applies
  uniformly.  No specific slots can be mentioned, and this option
  can appear only once.  The arguments for this way of doing
  business are:
  1) Anything not uniform is local to a slot description
  2) There are no redundant, possibly inconsistent,
  declarations

:accessors-with-prefix is certainly nice and simple, but it is
not the same as the last thing that was discussed in the mail.
And the other options were listed because they appeared in
"things we basically agree on" in the minutes of that meeting we
had at MIT, so we need to keep discussing this until we converge.
  
    (:documentation string)
  
  OK   
  
    (:meta-class class-name)
  
  No, we think this should be done using the meta-object protocol,
  since the parsing of the defclass is not under the control of
  the meta-class.  However, I think we could be convinced
  otherwise.

You're the meta-class experts, but I think the idea of this
option was supposed to be to control the class of the class that
gets instantiated, but not to affect anything about the parsing
of the defclass.

    (:required-classes class-name...)
    (:required-init-keywords keyword...)
    (:required-slots slot-name...)
    (:required-methods generic-function-name...)
  
  No.  These seem like environmental features, and should not be
  part of the spec.  

I think you're wrong here, for two reasons.  One is that I don't
agree that these are environmental; I see them as a necessary
part of defining a class and its relationships with other
classes.  We've found these options to be heavily used when
setting up complex families of classes.

The second reason is that these aren't just error-checking.
:required-slots and :required-classes can make additional slot
names available as variables inside a WITH.  This is necessary
to be able to write methods for abstract classes, and especially
for mixins, when part of the inter-component-class interface
takes the form of slots.

If we disagree we need to keep discussing this.

		     We should make some comment about how
  additional options may be supported by the standard class in
  particular implementations, and ones not understood will either
  be ignored, or have warnings issued. 
   
I don't think having defclass options quietly ignored in some
implementations is going to enhance portability.

    (:constructor function-name lambda-list)
  
  We have allowed the full generality of the defstruct syntax for
  this one.  Do you think it should be restricted to this
  boa-constructor

No, I agree.  Specifically, the lambda-list should be optional,
and default to (&key ...) where the ... is filled in according
to the :initable and :initable-slots (or whatever those options
end up being called) in the obvious way.

    For the :ACCESSOR-PREFIX, :READER-PREFIX, and :INITABLE-SLOTS
    options, you can omit slot-names to indicate that the option
    applies for all slots of this class.
  
  See above
  
    It is legal to specify more than one accessor and reader for a
    single slot.
  
  We argued about this, and decided we didn't like it.  Why is it good?

I think I pointed out in an earlier piece of mail that you might
want to have both an accessor and a reader, where the accessor
is used inside of a module while the reader is a public
interface.  The idea is that you can't change the contents of
the slot using the public interface.  I don't know of
applications for two accessors or two readers, but I don't see
any advantage to adding a special error-check to disallow that.
Why is it bad?

    DEFINING METHODS AND SETF METHODS
    
    The general syntax for defining a method is:
    
    (DEFMETHOD generic-function-name method-option...
      method-lambda-list
       body...)
  
  No.  See my earlier message. 
  
At the time Sonya and I put together this list of things that
we thought had been agreed upon, we didn't know that there was
still disagreement on the syntax of defmethod, since we had not
heard from you.  As it turns out defmethod isn't ready to be
included yet.  We need to keep working on it until we converge.

  ...But we agree that DEFMETHOD-SETF
  is a better name....  Are we not allowing multiple values to be
  stored?  In the silver book it talks about extensions to the
  corresponding list of store variables.  I have no problem with
  the restriction.
  
The extension mentioned on CLtL p.103 hasn't been incorporated
into Common Lisp yet, so I don't think it should be allowed to
sneak in through the object-oriented programming extension.
We should leave syntactic space for it, though, so having the
store-variable in a separate lambda-list is good.

    DEFINING GENERIC FUNCTIONS
    
    (DEFGENERIC generic-function-name lambda-list option...)
    
    (DEFGENERIC-SETF generic-function-name lambda-list
    setf-lambda-list option.
    
    generic-function-name is a non-null symbol.
    
    lambda-list is an ordinary lambda-list except no &aux
    variables are allowed.
  
    setf-lambda-list is (variable-name).
  
  Yes, except that we allow a documentation string before the
  options.  What do you think???

Flavors allows a "naked" documentation string also, but I'm not
sure that ought to be in the standard.  It's a matter of whether
you think it's more important to have the options in a uniform
format or to have defgeneric syntax be more analogous to defun
syntax.

    Each option is one of:
  
	option-name
	(option-name argument...)
  
    Each option-name is a keyword that names an option; the
    arguments depend on the option.
  
  OK
  
    The set of defined options and their arguments is:
    
    [--Should declarations and doc strings be allowed?--]
    
	     (:documentation string)
  
  See above.
  
	     (:optimize spec...)
  
  Is this for all methods, or just the discriminating function.
  This seems weird to me

The question seems weird to me.  I guess the problem is caused
by us including only the syntax and not the semantics so as to
get something out quickly for discussion, which meant that we
completely failed to communicate what this was all about.

The idea of the :optimize option to defgeneric in Flavors is
that there are a variety of possible ways of doing
discrimination, and in order for the system to choose among them
intelligently the user should be able to express his needs.  In
the Common Lisp objected-oriented programming facility I presume
it would be a method of the discriminator, rather than
"the system", that is guided by this option, but otherwise the
concept of the :optimize option seems to carry over directly and
does not seem to be at all specific to Flavors.  I believe it's
more portable for the user's needs to be expressed in terms of
which quality (speed or space) is more important, rather than
directly specifying the exact technique to be used.

	     (:method-combination name argument...)
  
  What is the argument in this form?
  
Optional arguments received by parameters in the
define-method-combination.  See the Flavors documentation.

	     (:generic-function-class class-name)
	     (:method-class class-name)
	     (:order parameter-name...)
  
  We have been using :dispatch-order for the keyword :order.  It
  should really be :argument-precedence-order.

:argument-precedence-order is the best name I've heard for this
yet.

		 [more?]
  
  Additional options should be allowed, as in defclass.

	      WITH
    
    We have agreed that WITH should exist, but we haven't decided
    anything more specific about it yet.
  
  Right; we haven't decided anything yet.  There are two different
  proposals under discussion.  One turns names in calls on the
  accessors (we call that one WITH).  The other turns them into
  primitive slot accesses (we call that one %WITH).
  
No proposal is "under discussion" if the people on the east coast
haven't seen it.  Send them along and we'll be happy to discuss
them.
  
    DEFINING NEW TYPES OF METHOD COMBINATION
    
    (DEFINE-SIMPLE-METHOD-COMBINATION name operator-name
				      [single-arg-is-value]
				      [pretty-name])
    
    This function defines a new type of method combination in
    which all the methods are called and their values are passed
    to the operator specified by operator-name.
    
    name is a non-null symbol, often a keyword, that is the name
    of the type of method combination being defined.
  
    operator-name can be a symbol or a lambda-expression, the name
    of a function, a macro, or a special form.
  
    single-arg-is-value is t or nil; by default it is nil.
    
    pretty-name is a string.  It defaults to the lower case
    version of the supplied name.
  
  We haven't agreed to this at all yet.  super-daemon method
  combination we believe in. But this simple case seems strange to
  me, and if it can be defined with the stronger
  DEFINE-METHOD-COMBINATION, then let's not put it in the spec.

It's a convenient abbreviation for people who don't want to have
to understand the full define-method-combination to do something
simple.  What are you going to tell the user whose program is
non-portable because you decided to leave this out?

  I didn't see whoppers described in daemon combination section of
  the Flavors manual -- at least not in the early section.  Does
  this mean that it is not a feature of daemon combination?

Whoppers are described in their own section.  They are not a
feature of daemon combination or any other particular type of
combination.

  We believe that at least on the west coast, run-super will be
  used much more than daemon combination.  Hence my attempt to
  unify them.  An answer to Moons answer next week.
  
    (DEFINE-METHOD-COMBINATION method-combination-type-name
			       lambda-list
			       (method-pattern...) 
			       option...
       body...)
    
    This function behaves the same way as in Flavors.  See the
    Flavors documentation for details.
  
  We believe that a simple version of this should be in the spec.
  I don't know yet what simple means.  At least powerful enough to
  define the extended features, but not including the full library
  of standardly available combinations types.
  
    Making a New Instance
    
    (MAKE class-name keyword-argument...)
    
    MAKE is the function that makes and initializes an instance of
    a class.  The allowed keyword-arguments depend on the DEFCLASS
    form.  Any keyword specified with the :INITABLE,
    :INITABLE-SLOTS, or :INIT-KEYWORDS option is allowed.
  
    If a keyword-argument is given to MAKE, it overrides any
    default that is given in the DEFCLASS form, such as the
    :DEFAULT-INIT-PLIST option, or the initial-value-form syntax.
  
  Modulo isssues on keywords and specification of initable, this
  is basically correct.
  
  
    OTHER FUNCTIONS
    
    Other functions of interest to the general programmer
    [---tbd---].
    
    This list came from the 8 August meeting; it can serve as a
    starting agenda for this section:
    
	find-flavor / class-named
  
  Yes class-named
  
	typep
  
  classp is the right name

The name TYPEP is already specified by Common Lisp, we can't
change it to something else.  The issue here is what is to be
changed in the documentation of typep when the object-oriented
programming extension is added to the Common Lisp specification.

	type-of
	class-of
  
  Yes on class-of
  
	operation-handled-p ??
  
  Something like this is needed
  
	remove-class
	   remove-method
	   change-class
  
  Yes


If we can discuss and reach agreement upon the few points of
disagreement above, we should be able to send out a revised
version of "Summary of features we all agree on" in a couple
of days and then move on to deeper issues.

∂09-Sep-86  2244	RPG   	lack of word from the west coast 
 ∂09-Sep-86  2158	Owners-CommonLoopsCore↑.PA@Xerox.COM 	lack of word from the west coast
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Sep 86  21:58:03 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 09 SEP 86 21:35:06 PDT
Return-Path: <Moon@ALDERAAN.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA@XEROX.ARPA
Received: from ALDERAAN.SCRC.Symbolics.COM ([192.10.41.109]) by
 Xerox.COM ; 09 SEP 86 21:34:51 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3422; Wed
 10-Sep-86 00:33:50 EDT
Date: Wed, 10 Sep 86 00:33 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: lack of word from the west coast
To: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860910003335.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

The draft document outlining what has been learned so far
in the Xerox/Lucid meetings, which you said you would send
by the end of last week, has not yet arrived.  I think you
had better send it again.

∂09-Sep-86  2324	RPG   	Class-of Versus Type-of     
 ∂09-Sep-86  2258	Owners-commonloopscore↑.pa@Xerox.COM 	Class-of Versus Type-of    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Sep 86  22:57:36 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 09 SEP 86 22:53:12 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 09 SEP 86
 22:53:02 PDT
Date: 09 Sep 86 22:52 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Class-of Versus Type-of 
To: commonloopscore↑.pa@Xerox.COM 
Message-ID: <860909-225312-1464@Xerox>


Danny asked what I meant when I said that class-of might be ill-defined
in some situation. The situation I thought I was discussing was
the one in which the Common Lisp type system is subsumed by the
class system, and class-of is possibly expected to return `the
most specific class' in the presence of type specifiers which correspond
to classes and in the presence of types/classes that do not exist in
every Common Lisp (like simple- objects). Class-of is perfectly
well-defined in the current proposal in which the Common Lisp standard
type specifiers (minus atom and common) have (builtin) classes.
(Danny, I'm referring to the current West Coast proposal).

			-rpg-

∂09-Sep-86  2336	RPG   	Things on which we agree    
 ∂09-Sep-86  2326	Owners-commonloopscore↑.pa@Xerox.COM 	Things on which we agree   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Sep 86  23:26:33 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 09 SEP 86 23:24:49 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 09 SEP 86
 23:24:40 PDT
Date: 09 Sep 86 23:24 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Things on which we agree
To: commonloopscore↑.pa@Xerox.COM 
Message-ID: <860909-232449-1480@Xerox>


Some of the West Coast people prefer MAKE-INSTANCE to MAKE.
The motivation is to leave good names alone when reasonably
short, reasonably descriptive names are available.

********************************************************************

When I read something like:

      :accessor generic-function-name
	    Specifies that a function named generic-function-name
	    be automatically generated, to read the value of this
	    slot.  SETF may be used with generic-function name to
	    write the value of the slot.
  
Should I take it to mean the same as


      :accessor generic-function-name
	    Specifies that a generic function named generic-function-name
	    be automatically generated, to read the value of this
	    slot.  SETF may be used with generic-function-name to
	    write the value of the slot.

********************************************************************

On this topic:

	  :initialize-only flag
  
	Do we really need this feature?  Why not just leave out the
	:accessor if we don't want people to be able to setf the slot?

Presumably the :accessor option indicates that a setfable accessor is
made, while its absence still leaves (setf (get-slot ...) ...) available?
Or is GET-SLOT not `agreed to?' If GET-SLOT exists and leaves the slot
setfable, then :initialize-only has a role. 

********************************************************************

Danny said: ``There are two different are proposals under discussion.''

He was misguided in saying this. He meant that the West Coast discussion
group was discussing this issue and would probably propose an alternative
that mentions WITH and %WITH (or some such names). We usually discuss
things like this out here to try to filter out bad ideas from the set of
ideas we ship to the Hub.

********************************************************************

Is the name of the type of method combination a symbol for some deep
reason or just to keep it a simple name as in other named things?

*********************************************************************

Are whoppers thought of as being in a different ontological category
from other method combination types? The continue-whopper `feature'
seems to hint so. 

			-rpg-

∂10-Sep-86  0837	RPG   	Re: [Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>:   
 ∂09-Sep-86  1947	Bobrow.pa@Xerox.COM 	Re: [Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>:    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Sep 86  19:47:32 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 SEP 86 18:34:49 PDT
Date: 9 Sep 86 18:34 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: [Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>:
 Summary of features we all agree on ]
In-reply-to: Kahn.pa's message of 8 Sep 86 14:07 PDT
To: Kahn.pa@Xerox.COM
cc: Bobrow.pa@Xerox.COM, CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860909-183449-1216@Xerox>

          :initialize-only flag
     
     
     We need to be clear what "after initialization" means.  Can one
send an
     "initialize-with-plist" message to an "already initialized"
instance?  

I think so (How can we stop it?)  But that is different than using a
SETF to change the value.  Users can almost always get around read-only
declarations not protected by hardware.  I prefer the name
:initialize-only to :read-only despite history. 

        (:meta-class class-name)
     There are different uses of meta-classes.  There are those that
just
     make performance trade-offs and need not be concerned with "the
parsing
     of the defclass".  It would be reasonable to be able to use the
     :meta-class at least in such cases. 
I agree.

          (MAKE class-name keyword-argument...)

     I would prefer that the first argument to MAKE is either a
class-name or
     a class.

I agree.


-- danny
     

∂10-Sep-86  0837	RPG   	Re: Subtypep 
 ∂09-Sep-86  1947	Bobrow.pa@Xerox.COM 	Re: Subtypep  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Sep 86  19:47:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 SEP 86 17:52:00 PDT
Date: 9 Sep 86 17:46 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Subtypep 
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 08 Sep 86
 17:35 PDT
To: RPG@SAIL.STANFORD.EDU
cc: commonloopscore↑.pa@Xerox.COM
Message-ID: <860909-175200-1153@Xerox>

     CLASS-OF will be as poorly defined as the current TYPE-OF.

Why is this ill-defined?  It is not TYPE-OF.  It returns the most
specific class for the instance.


-- danny

∂10-Sep-86  1730	RPG   	Getting together to work    
 ∂10-Sep-86  1633	Gregor.pa@Xerox.COM 	Getting together to work
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Sep 86  16:33:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 SEP 86 15:43:08 PDT
Date: 10 Sep 86 15:42 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Getting together to work
To: CommonLoopsCore↑.pa@Xerox.COM
cc: Gregor.pa@Xerox.COM
Message-ID: <860910-154308-2286@Xerox>

My messages for the next little while are likely to be more curt than
usual, I can only type with one hand.

We had made a plan to get together monday moring at OOPSLA and work on
the spec.  I believe that we will have more work to do than can be done
in three hours.

Instead, I propose that we get together Friday and Saturday after OOPSLA
in Palo Alto.  This will give us enough time to actually get some work
done, and takes advantage of existing travel to get a lot of people in
the same place.

I propose that we use the Monday morning at OOPSLA time to have a more
open meeting with people from LMI and HP.

∂11-Sep-86  1057	RPG   	Things on which we agree    
 ∂10-Sep-86  1919	Owners-commonloopscore↑.pa@Xerox.COM 	Things on which we agree   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Sep 86  19:19:33 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 10 SEP 86 19:01:23 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 10 SEP 86 19:01:07 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 78603;
 Wed 10-Sep-86 21:59:43 EDT
Date: Wed, 10 Sep 86 21:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Things on which we agree
To: commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860909-232449-1480@Xerox>
Message-ID: <860910215951.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 09 Sep 86 23:24 PDT
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

    Some of the West Coast people prefer MAKE-INSTANCE to MAKE.
    The motivation is to leave good names alone when reasonably
    short, reasonably descriptive names are available.

Either name is fine with me.

    ********************************************************************

    When I read something like:

	  :accessor generic-function-name
		Specifies that a function named generic-function-name
		be automatically generated, to read the value of this
		slot.  SETF may be used with generic-function name to
		write the value of the slot.
  
    Should I take it to mean the same as


	  :accessor generic-function-name
		Specifies that a generic function named generic-function-name
		be automatically generated, to read the value of this
		slot.  SETF may be used with generic-function-name to
		write the value of the slot.

I think so.  The omission of "generic" before "function" in 1 out of 4
places was probably not intended to mean anything.  It should be rephrased
to be consistent.

    ********************************************************************

    On this topic:

	      :initialize-only flag
  
	    Do we really need this feature?  Why not just leave out the
	    :accessor if we don't want people to be able to setf the slot?

    Presumably the :accessor option indicates that a setfable accessor is
    made, while its absence still leaves (setf (get-slot ...) ...) available?
    Or is GET-SLOT not `agreed to?' If GET-SLOT exists and leaves the slot
    setfable, then :initialize-only has a role. 

Hmm, if you really think get-slot should be customizable this way, then
yes, there should be a slot-option to customize it.  Never in a million years
would I have figured out from the name of the slot-option that this is what
it controls, so I think a better name should be found.  Except for that,
I'm amenable to putting this in if someone thinks it's important.

I think of get-slot as a subprimitive for getting around the normal
accessor mechanism, so I don't see any point to the extra complexity of
providing ways to turn off get-slot reading and writing.  I see even less
point when I think about it harder and suspect that then you would need
a %get-slot, which is the same as get-slot except that it can't be turned
off, as part of the semantics of WITH.

Perhaps other people think of get-slot as something the user would use
all the time, if so that's a bit of a surprise to me.  I do think we
agreed that there should be something that does get-slot (called
symbol-value-in-instance in Flavors; I don't much care for either name).

    ********************************************************************

    Danny said: ``There are two different are proposals under discussion.''

    He was misguided in saying this. He meant that the West Coast discussion
    group was discussing this issue and would probably propose an alternative
    that mentions WITH and %WITH (or some such names). We usually discuss
    things like this out here to try to filter out bad ideas from the set of
    ideas we ship to the Hub.

I haven't been to the Hub in weeks.

    ********************************************************************

    Is the name of the type of method combination a symbol for some deep
    reason or just to keep it a simple name as in other named things?

The latter.

    *********************************************************************

    Are whoppers thought of as being in a different ontological category
    from other method combination types? The continue-whopper `feature'
    seems to hint so. 

Whoppers aren't a method-combination type, they are a kind of method.  I
don't know what an ontological category is, but the dictionary
definition of ontological suggests that deleting the word won't change
the meaning of your question.  Whoppers (and wrappers) are different
from regular methods because they themselves control the way they get
combined, instead of being controlled by a method-combination routine
defined with define-method-combination.

I should point out again that I don't like whoppers, but I support them
for the standard because I have to admit that my users have found them
very useful.  I might not always be the best source of information about
why whoppers are the way they are, for this reason.

∂11-Sep-86  1100	RPG   	Re: Things on which we agree
 ∂11-Sep-86  1020	Owners-commonloopscore↑.pa@Xerox.COM 	Re: Things on which we agree    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Sep 86  10:20:13 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 SEP 86 10:03:25 PDT
Redistributed: commonloopscore↑.pa
Received: from Cabernet.ms by ArpaGateway.ms ; 11 SEP 86 10:03:12 PDT
Date: 11 Sep 86 10:03 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Things on which we agree
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Wed, 10 Sep 86 21:59 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: commonloopscore↑.pa@Xerox.COM
Message-ID: <860911-100325-2906@Xerox>

         On this topic:

     	      :initialize-only flag
    	    Do we really need this feature?       Why not just leave out
the
 	    :accessor if we don't want people to be able to setf the slot?

         Presumably the :accessor option indicates that a setfable
accessor
         is made, while its absence still leaves (setf (get-slot ...)
         ...) available? Or is GET-SLOT not `agreed to?' If GET-SLOT
         exists and leaves the slot setfable, then :initialize-only has
a
         role. 
     Hmm, if you really think get-slot should be customizable this way,
then
     yes, there should be a slot-option to customize it.  Never in a
million
     years would I have figured out from the name of the slot-option
that
     this is what it controls, so I think a better name should be found.
     Except for that, I'm amenable to putting this in if someone thinks
it's
     important.
What does ":read-only"  mean in Flavors on a slot?  It was my
understanding that it meant that after initialization, one couldn't set
an instance variable in  a method.  :initialize-only was put in as a
better name (I thought) for :read-only.  Perhaps we should drop it as a
mechanism that must be supported by the system.


     Whoppers (and wrappers) are different from regular methods because
they
     themselves control the way they get combined, instead of being
     controlled by a method-combination routine defined with
     define-method-combination.
This of course is how we have always done method combination in Loops,
and it has proven most useful to us.  We never allowed super classes to
dictate what a subclass would do.  Hence the similarity that I saw
between run-super and continue-whopper.  If we have run-super in primary
methods should we have :around methods  -- and if so, do you prefer the
name :full-shadow for this type.  Ontologically this name is much
sounder, of course, if you like that kind of ontology.





-- danny

∂11-Sep-86  1103	RPG   	Re: Things on which we agree
 ∂11-Sep-86  1020	Owners-commonloopscore↑.pa@Xerox.COM 	Re: Things on which we agree    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Sep 86  10:20:13 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 SEP 86 10:03:25 PDT
Redistributed: commonloopscore↑.pa
Received: from Cabernet.ms by ArpaGateway.ms ; 11 SEP 86 10:03:12 PDT
Date: 11 Sep 86 10:03 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Things on which we agree
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Wed, 10 Sep 86 21:59 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: commonloopscore↑.pa@Xerox.COM
Message-ID: <860911-100325-2906@Xerox>

         On this topic:

     	      :initialize-only flag
    	    Do we really need this feature?       Why not just leave out
the
 	    :accessor if we don't want people to be able to setf the slot?

         Presumably the :accessor option indicates that a setfable
accessor
         is made, while its absence still leaves (setf (get-slot ...)
         ...) available? Or is GET-SLOT not `agreed to?' If GET-SLOT
         exists and leaves the slot setfable, then :initialize-only has
a
         role. 
     Hmm, if you really think get-slot should be customizable this way,
then
     yes, there should be a slot-option to customize it.  Never in a
million
     years would I have figured out from the name of the slot-option
that
     this is what it controls, so I think a better name should be found.
     Except for that, I'm amenable to putting this in if someone thinks
it's
     important.
What does ":read-only"  mean in Flavors on a slot?  It was my
understanding that it meant that after initialization, one couldn't set
an instance variable in  a method.  :initialize-only was put in as a
better name (I thought) for :read-only.  Perhaps we should drop it as a
mechanism that must be supported by the system.


     Whoppers (and wrappers) are different from regular methods because
they
     themselves control the way they get combined, instead of being
     controlled by a method-combination routine defined with
     define-method-combination.
This of course is how we have always done method combination in Loops,
and it has proven most useful to us.  We never allowed super classes to
dictate what a subclass would do.  Hence the similarity that I saw
between run-super and continue-whopper.  If we have run-super in primary
methods should we have :around methods  -- and if so, do you prefer the
name :full-shadow for this type.  Ontologically this name is much
sounder, of course, if you like that kind of ontology.





-- danny

∂11-Sep-86  1532	RPG   	Whoppers and Ontology       
 ∂11-Sep-86  1210	Owners-commonloopscore↑.pa@Xerox.COM 	Whoppers and Ontology      
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Sep 86  12:10:00 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 SEP 86 11:43:14 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 11 SEP 86
 11:42:51 PDT
Date: 11 Sep 86 11:42 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Whoppers and Ontology   
To: commonloopscore↑.pa@Xerox.COM 
Message-ID: <860911-114314-3067@Xerox>


Dictionaries are not usually in the business of explaining
philosophical traditions, so I'm not surprised you didn't
find a meaning you could use for `ontological.'

I have the following understanding of whoppers (what I'm about to
explain is a sketch rather than a representation of everything I understand
about them).

Suppose we have a lattice with F1 as the most general (or most basic)
flavor and F2 and F3 increasingly specific. In the flavors documentation
pictorial style, F3 would be at the top of the tree and F1 at the bottom.
In the CommonLoops pictorial style, F1 is at the bottom and F3 at the
top. Consider classical methods only, and suppose there is a whopper
defined on F1 and primary methods on F2 and F3. Suppose that the
whopper does something inconsequential and then does a continue-whopper.

Suppose that the generic function in question is applied to an instance of
F3, then I think the order of execution is the whopper first, then the
method for F3. Is this right?  If I am right then Danny's comment that
whoppers are like Loops method combination and continue-whopper is like
run-super is not exactly correct, I think. Aren't whoppers and
continue-whopper like Loops method combination and run-super within the
whopper domain (if there are whoppers in the lattice, then
continue-whopper runs them in most-specific-first order), but that in the
overall order of execution, whoppers get done first then other method
types?

Moon: Is it possible in New Flavors or desirable in the Object System to
mess with the order of execution via method combination defintion (in
Flavors) or changing the disciminating function (in the Object System) so
that the user can define whopper-whoppers, which execute before whoppers?
In other words, are whoppers definable in New Flavors with whoppers
removed? 

Gregor: Can you fix the Xerox re-mailer so that lines are not
broken in a funny way? 

			-rpg-

∂11-Sep-86  1610	RPG   	Re: Things on which we agree
 ∂11-Sep-86  1534	Owners-commonloopscore↑.pa@Xerox.COM 	Re: Things on which we agree    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Sep 86  15:34:49 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 SEP 86 14:50:50 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 11 SEP 86 14:50:22 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79135;
 Thu 11-Sep-86 17:25:02 EDT
Date: Thu, 11 Sep 86 17:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Things on which we agree
To: commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860911-100325-2906@Xerox>
Message-ID: <860911172500.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

[message reformatted to 70-column width to try to avoid linefolding]

    Date: 11 Sep 86 10:03 PDT
    From: Bobrow.pa@Xerox.COM

	     On this topic:

		  :initialize-only flag
		Do we really need this feature? Why not just leave out
		the :accessor if we don't want people to be able to
		setf the slot? [Moon]
	     Presumably the :accessor option indicates that a setfable
	     accessor is made, while its absence still leaves (setf
	     (get-slot ...)  ...) available? Or is GET-SLOT not
	     `agreed to?' If GET-SLOT exists and leaves the slot
	     setfable, then :initialize-only has a role. [RPG]
	 Hmm, if you really think get-slot should be customizable this
	 way, then yes, there should be a slot-option to customize it.
	 Never in a million years would I have figured out from the
	 name of the slot-option that this is what it controls, so I
	 think a better name should be found.  Except for that, I'm
	 amenable to putting this in if someone thinks it's important.
         [Moon]
    What does ":read-only" mean in Flavors on a slot?  It was my
    understanding that it meant that after initialization, one
    couldn't set an instance variable in a method.  :initialize-only
    was put in as a better name (I thought) for :read-only.  Perhaps
    we should drop it as a mechanism that must be supported by the
    system. [Bobrow]

There is no ":read-only" feature in Flavors.  There is one in
defstruct, but it doesn't tell us much since defstruct is so much
simpler.  Let's drop the whole thing unless someone thinks it's
an inportant feature to have.

	 Whoppers (and wrappers) are different from regular methods
	 because they themselves control the way they get combined,
	 instead of being controlled by a method-combination routine
	 defined with define-method-combination.
    This of course is how we have always done method combination in
    Loops, and it has proven most useful to us.  We never allowed
    super classes to dictate what a subclass would do.  Hence the
    similarity that I saw between run-super and continue-whopper.  

I'm not sure this is accurate, but I don't have anything to add beyond
what was in the other message I sent a few minutes ago.

    If we have run-super in primary methods should we have :around
    methods -- and if so, do you prefer the name :full-shadow for this
    type.  Ontologically this name is much sounder, of course, if you
    like that kind of ontology.

The name :full-shadow doesn't convey much meaning to my ear.
Beyond that, I don't have much to say because I can't figure
out what the specific proposal is.

∂12-Sep-86  0805	RPG   	specifying metaclass etc.   
 ∂11-Sep-86  1826	Gregor.pa@Xerox.COM 	specifying metaclass etc.    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Sep 86  18:26:02 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 SEP 86 18:19:01 PDT
Date: 11 Sep 86 18:18 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: specifying metaclass etc.
To: CommonLoopsCore↑.pa@Xerox.COM
cc: Gregor.pa@Xerox.COM
Line-fold: NO
Message-ID: <860911-181901-3531@Xerox>

I was wrong.  It does make sense to be able to specify the class
of a class, the class of a generic-function and the class of methods
on that generic-function.  For reasons which are complicated, doing
this doesn't buy as much power as it does in PCL, but it still buys
enough power to be worth doing.  SO:

add a :class option to defclass
add a :class (or :generic-function-class) option to make-generic and
   defgeneric
add a :method-class option to defgeneric and make-generic

∂12-Sep-86  0812	RPG   	Re: Defmethod syntax proposal    
 ∂11-Sep-86  2205	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Re: Defmethod syntax proposal   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Sep 86  22:05:24 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 SEP 86 22:03:45 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 11 SEP 86 22:03:31 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79317;
 Fri 12-Sep-86 01:02:26 EDT
Date: Fri, 12 Sep 86 01:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Defmethod syntax proposal
To: CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860911150805.2.GREGOR@AVALON.XEROX-PARC>
Message-ID: <860912010224.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 11 Sep 86 15:08 PDT
    From: Gregor.pa@Xerox.COM

	Date: Mon, 8 Sep 86 18:41 EDT
	From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
    
	    Date: 8 Sep 86 13:13 PDT
	    From: Bobrow.pa@Xerox.COM
    
	    I meant that I propose that we not describe classical syntax
	    as part of the standard.  It would simply be a backwards
	    compatibility feature for Flavors users.
    
	It's really more than that; it provides conceptual compatibility for
	people who are familiar with most any of the other existing
	object-oriented programming languages, particularly Smalltalk-80.
	It provides the familiar concepts of instance variables and "self".
	Because of the widespread establishment of these concepts, I think
	it's worth putting this into the standard for everyone, despite the
	minor inelegance of having two syntaxes when only one is logically
	necessary.

    Yes, it does provide conceptual compatibility with the other existing
    "object-oriented" programming languages.  But I place that conceptual
    compatibility in the same category as "message passing".  Namely that it
    is not the model we want to be emphasing to users.  This new standard is
    generic functions.  It isn't message passing.  Self and "auto-with" on
    self are "message-passing" concepts not generic function concepts.

    I don't think we want to be providing support in the standard for
    thinking about generic functions as something that they aren't, namely
    flavors/smalltalk style "message passing". 

I don't agree with the idea that self and "auto-with" have something to
do with message-passing and are therefore obsolete.

Aside from that, I think we are in serious danger of falling into the
trap of trying to make a standard that contains the latest ideas that we
just thought of recently, rather than the stodgy old ideas that are
known to work but aren't any fun any more.  Putting in the latest ideas
always sounds good, even to me, but historically it has almost always
resulted in bad standards or standards that aren't widely accepted or
both.  Think about the things that everyone hates the most about Common
Lisp, for instance.  Some of them are due to trying to be compatible
with older languages, but most of them are due to putting in new things
that seemed well thought out at the time, but in fact were not as well
thought out as we thought.  Making a successful standard always includes
making compromises between desire and practice.

If we really think that only the latest ideas are any good, and everything
else should be removed from the standard, then what we are really saying
is that this is the wrong time to make a standard.

    For now, the best I can come up with is to propose that it might be
    enough to come up with heuristics to tell the two kinds of defmeths
    apart instead of just rules.  If the heuristics fail to identify the
    defmeth for sure than an error would be generated or something.

I don't think anything based on heuristics is going to be acceptable as
a standard.  If we have to resort to heuristics then we will be very
much better off using two different names for the two kinds of
method-defining forms.

∂12-Sep-86  1106	RPG   	Defmethod Syntax       
 ∂12-Sep-86  0842	Owners-commonloopscore↑.pa@Xerox.COM 	Defmethod Syntax      
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Sep 86  08:42:35 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 12 SEP 86 08:40:17 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 12 SEP 86
 08:29:28 PDT
Date: 12 Sep 86 08:29 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Defmethod Syntax   
To: commonloopscore↑.pa@Xerox.COM 
Message-ID: <860912-084017-4039@Xerox>


Moon makes two points. The first is that `self' and `auto-with'
form part of a larger, older tradition of OOP, and we shouldn't
ignore that tradition in order to get the `latest, most final'
ideas in the proposal. He also mentioned that he didn't think
these concepts were inextricably linked to message-passing and are
therefore obsolete.

I believe that these concepts are linked to message-passing, but
not absolutely linked. I think we ought to concentrate on finding
the right abstractions and specifying them; I don't think we should
gratuitously add features that users can implement with our abstractions
simply because `users find them useful.' On the other hand, Moon is
right that it is a mistake to opt for the latest, greatest at the
expense of well-understood concepts. We ought to consider `self'
and `auto-with' more carefully in this light. In other words,
I believe that `self' and `auto-with' are linked to message-passing,
and, even so, they might not be obsolete.

The second point is about distinguishing two forms of defmethod.
I feel it is imperative to find clear rules of distinguishing the
forms rather than invent another defmethod-like form. Only if
the possible syntactic means of distinguishing them are horrendous
should we consider proliferating functions/special forms/macros.

			-rpg-

∂12-Sep-86  1108	RPG   	Re: Defmethod syntax proposal    
 ∂12-Sep-86  0940	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Re: Defmethod syntax proposal   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Sep 86  09:40:26 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 12 SEP 86 09:39:22 PDT
Return-Path: <DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 12 SEP 86 09:08:47 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79520;
 Fri 12-Sep-86 11:56:53 EDT
Date: Fri, 12 Sep 86 11:59 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: Defmethod syntax proposal
To: CommonLoopsCore↑.PA@Xerox.COM
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <860912010224.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860912115905.1.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Fri, 12 Sep 86 01:02 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    I don't agree with the idea that self and "auto-with" have something to
    do with message-passing and are therefore obsolete.

Yes.  The idea of New Flavors was to get rid of "message passing" and
instead go to "generic functions".  We did that, and New Flavors still
has "self" and "auto-with" even though it has "generic functions"
instead of "message passing".  Rather, "self" and "auto-with" are
associated with having generic functions with only one argument that's
discriminated on.  What makes them go away is not "generic functions",
but "multimethods".

It seems to me that you folks are worried that providing the
"traditional" syntax will discourage users from taking advantage of the
greater power provided by the multimethod capability of the new spec.  I
believe that we can take care of this by the organization and phrasing
of the documentation of the spec.  We can make it clear that the
"traditional" syntax is stricly weaker than the "modern" syntax, and has
no additional capabilities, and is being provided because the style is
well-known and traditional, rather than because it's considered to be
"better" in any interesting sense.

∂12-Sep-86  1245	RPG   	Re: Defmethod syntax proposal    
 ∂11-Sep-86  1535	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Re: Defmethod syntax proposal   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Sep 86  15:35:13 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 SEP 86 15:10:52 PDT
Redistributed: CommonLoopsCore↑.PA@XEROX.ARPA
Received: from Semillon.ms by ArpaGateway.ms ; 11 SEP 86 15:10:18 PDT
Date: Thu, 11 Sep 86 15:08 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Defmethod syntax proposal
To: DLW@ALDERAAN.SCRC.Symbolics.COM, Bobrow.pa@Xerox.COM,
 Moon@STONY-BROOK.SCRC.Symbolics.COM, CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860908223153.1.DLW@CHICOPEE.SCRC.Symbolics.COM>,
              The message of 8 Sep 86 16:13-PDT from Bobrow.pa,
              <860908184131.4.DLW@CHICOPEE.SCRC.Symbolics.COM>,
              The message of 8 Sep 86 13:13-PDT from Bobrow.pa,
              <860908125848.1.MOON@EUPHRATES.SCRC.Symbolics.COM>,
              The message of 8 Sep 86 09:10-PDT from Bobrow.pa,
              <860905205118.7.MOON@EUPHRATES.SCRC.Symbolics.COM>,
              <860904180145.6.MOON@EUPHRATES.SCRC.Symbolics.COM>,
              The message of 5 Sep 86 10:52-PDT from Bobrow.pa,
              The message of 4 Sep 86 13:38-PDT from Bobrow.pa,
              <860904150145.7.MOON@EUPHRATES.SCRC.Symbolics.COM>,
              The message of 3 Sep 86 18:03-PDT from Bobrow.pa,
              <860902235003.8.MOON@EUPHRATES.SCRC.Symbolics.COM>,
              <860903004049.0.DLW@CHICOPEE.SCRC.Symbolics.COM>,
              <860903004113.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860911150805.2.GREGOR@AVALON.XEROX-PARC>
Line-fold: no


I think I have digested all the mail on this topic.

    Date:  3 Sep 86 18:03 PDT
    From: Bobrow.pa


    3) :discriminator-class (now called :generic-function-class) and
    :method-class are not options of defmethod.  They are (advanced)
    options of defgeneric.

:discriminator-class and :method-class are not features of defgeneric.
For the same reasons that the :class argument to defclass no longer
exists, these no longer exist.

    Date:  8 Sep 86 09:10 PDT
    From: Bobrow.pa

    In "classical" syntax, no argument of lambda-list can be type
    specified.  In general syntax at least one must be specifed if
    you are using method combination options.

    Date: Mon, 8 Sep 86 12:58 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    I don't see why method combination options would be disallowed
    for default methods.  If it doesn't make sense to allow such
    options for default methods, then we can go back to that proposal.

I think it makes perfect sense to have method combination options on
default methods.  A :around default method is the canonical example.


    Date: Mon, 8 Sep 86 18:41 EDT
    From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
    
        Date: 8 Sep 86 13:13 PDT
        From: Bobrow.pa@Xerox.COM
    
        I meant that I propose that we not describe classical syntax
        as part of the standard.  It would simply be a backwards
        compatibility feature for Flavors users.
    
    It's really more than that; it provides conceptual compatibility for
    people who are familiar with most any of the other existing
    object-oriented programming languages, particularly Smalltalk-80.
    It provides the familiar concepts of instance variables and "self".
    Because of the widespread establishment of these concepts, I think
    it's worth putting this into the standard for everyone, despite the
    minor inelegance of having two syntaxes when only one is logically
    necessary.

Yes, it does provide conceptual compatibility with the other existing
"object-oriented" programming languages.  But I place that conceptual
compatibility in the same category as "message passing".  Namely that it
is not the model we want to be emphasing to users.  This new standard is
generic functions.  It isn't message passing.  Self and "auto-with" on
self are "message-passing" concepts not generic function concepts.

I don't think we want to be providing support in the standard for
thinking about generic functions as something that they aren't, namely
flavors/smalltalk style "message passing". 

I do think we should be providing support in the standard so that an
environment which supports flavors as well as the standard can only have
one defmethod symbol and can unamiguosly determine whether or or not the
defmethod is a flavors defmethod or a CLOS defmethod.   I used to think
that was easy until I realized that this also had to work for the kinds
of defmethods that people are going to write using release 7 too.

For now, the best I can come up with is to propose that it might be
enough to come up with heuristics to tell the two kinds of defmeths
apart instead of just rules.  If the heuristics fail to identify the
defmeth for sure than an error would be generated or something.  Because
I can't figure out how often the heuristics I had in mind might fail I
thought I would send them out to get your all's opinion:

use the name-and-options-syntax:

(defmethod name-and-options args . body)

and used the heuristics:

 1. name-and-options is a symbol  --> its CLOS for sure
 2. one or more of the "required" args is a list --> CLOS for sure
 3. cadr of name-and-options is name of a flavor --> probably Flavors

 there might be other good rules too.
-------

∂12-Sep-86  1248	RPG   	Whoppers and Phenomenology  
 ∂11-Sep-86  1534	Owners-commonloopscore↑.pa@Xerox.COM 	Whoppers and Phenomenology 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Sep 86  15:34:39 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 SEP 86 14:40:41 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 11 SEP 86 14:40:16 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79120;
 Thu 11-Sep-86 17:14:47 EDT
Date: Thu, 11 Sep 86 17:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Whoppers and Phenomenology
To: commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860911-114314-3067@Xerox>
Message-ID: <860911171444.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 11 Sep 86 11:42 PDT
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

    I have the following understanding of whoppers (what I'm about to
    explain is a sketch rather than a representation of everything I understand
    about them).

    Suppose we have a lattice with F1 as the most general (or most basic)
    flavor and F2 and F3 increasingly specific. In the flavors documentation
    pictorial style, F3 would be at the top of the tree and F1 at the bottom.
    In the CommonLoops pictorial style, F1 is at the bottom and F3 at the
    top. Consider classical methods only, and suppose there is a whopper
    defined on F1 and primary methods on F2 and F3. Suppose that the
    whopper does something inconsequential and then does a continue-whopper.

    Suppose that the generic function in question is applied to an instance of
    F3, then I think the order of execution is the whopper first, then the
    method for F3. Is this right?  

Right.

				   If I am right then Danny's comment that
    whoppers are like Loops method combination and continue-whopper is like
    run-super is not exactly correct, I think. Aren't whoppers and
    continue-whopper like Loops method combination and run-super within the
    whopper domain (if there are whoppers in the lattice, then
    continue-whopper runs them in most-specific-first order), but that in the
    overall order of execution, whoppers get done first then other method
    types?

That's right.  If you use only whoppers then you can use continue-whopper
and get the same control structure as if you had used only Loops methods
and used run-super.

If on the other hand you have both whoppers and ordinary methods (of
whatever type, primary, :before, or whatever), then all the whoppers get
control before any of the ordinary methods.  Another way of saying the
same thing is that in any given whopper all of the ordinary methods,
regardless of how specific the flavor they are attached to, are "inside
of" continue-whopper (along with the whoppers on less specific flavors).

    Moon: Is it possible in New Flavors or desirable in the Object System to
    mess with the order of execution via method combination defintion (in
    Flavors) or changing the disciminating function (in the Object System) so
    that the user can define whopper-whoppers, which execute before whoppers?
    In other words, are whoppers definable in New Flavors with whoppers
    removed? 

I think these are two (no, three, maybe four) different questions.  Let
me try to answer them separately.

I assume that in Common Lisp with objects the discriminator has control
at some level over whoppers and the user could replace or augment them
by redefining a few methods.  I think the discriminator class operates
at a different level of modularity than the method-combination type,
and that it's good for both of these features to exist.

In Flavors, define-method-combination has no control whatsoever over
defwhoppers; they're handled separately.

In Flavors, the user could define a method-combination type that
understood methods with a particular method-option to behave just like
whoppers, or similarly to whoppers but with some modification such as
whopper-whoppers.  These couldn't be defined with the existing
defwhopper macro, since define-method-combination has no control over
those.  To make those neo-whoppers work with every method-combination
would require modifying every define-method-combination to know about
them.  Other than that it's extremely easy.

It's been proposed several times over the years to extend Flavors
whoppers to give the programmer more control over their ordering than
just having the most-specific ones first.  None of the proposals ever
got implemented.

Interfaces exist by which the user of New Flavors could define
whopper-whoppers, which execute before regular whoppers, without having
to replace regular whoppers with neo-whoppers.  The implementation of
whoppers is in fact table-driven or object-oriented or whatever you want
to call it.  However, these interfaces aren't documented and are likely
to change as a result of the project we are currently all engaged in.

∂12-Sep-86  1545	RPG   	ordering of defclasses 
 ∂12-Sep-86  1416	Gregor.pa@Xerox.COM 	ordering of defclasses  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Sep 86  14:14:40 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 12 SEP 86 13:11:48 PDT
Date: Fri, 12 Sep 86 13:09 PDT
From: Gregor.pa@Xerox.COM
Subject: ordering of defclasses
To: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860912130952.1.GREGOR@AVALON.XEROX-PARC>
Line-fold: no


In seperate messages, I am going to send out some general comments about
the current draft of the West Coast spec.  I am sending these to the
entire list even though I realize that the east coast people haven't
seen this spec, and that they aren't happy about this.

I have been assured that the legal problems with sending the spec to the
east coast have now all been fixed.  They weren't big problems, no-one
questions that the spec should be distributed, its just that someone far
from here had to be reminded why they should sign the release ("in my
left hand you see the release form, in my right hand you see a
Louisville Slugger... pick a hand, any hand").

-- Currently the spec makes no statement about when all the included
classes of a class must be defined:

  1. They must be defined before the defclass is evaluated.  PCL does
this now.  I don't like this it makes it harder to order loading of
files for no good reason.

  2. They must be defined before an instance of the class is created.
This is what flavors does now and is what I think we should do.  It
takes only a very little bit of implementation overhead and provides the
user with nice convenience.

So, these two rules should be added to the spec:

All the classes in the included classes tree of a class must be defined
before it is legal to make an instance of the class.

A class must be defined before it can be mentioned as an argument
specifier in a defmethod.

-------

∂12-Sep-86  1657	RPG   	Re: Defmethod syntax proposal    
 ∂12-Sep-86  1309	Gregor.pa@Xerox.COM 	Re: Defmethod syntax proposal
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Sep 86  13:08:57 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 SEP 86 12:50:49 PDT
Date: 12 Sep 86 12:48 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: Defmethod syntax proposal
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Fri, 12 Sep 86 01:02 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860912-125049-4322@Xerox>

     Date: Fri, 12 Sep 86 01:02 EDT
     From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
     
     Aside from that, I think we are in serious danger of falling into the
     trap of trying to make a standard that contains the latest ideas that we
     just thought of recently, rather than the stodgy old ideas that are
     known to work but aren't any fun any more ...
     ...  Think about the things that everyone hates the most about Common
     Lisp, for instance.

I agree.

     If we really think that only the latest ideas are any good, and
     everything else should be removed from the standard.

We don't.


      I don't think anything based on heuristics is going to be acceptable as
      a standard.

Of course, but I wasn't suggesting it as part of the standard.  Because I believe
that the classical defmethod has no place in the standard, I was only suggesting
that we should craft the standard in such that in your environment, it should be
possible to distinguish a flavors defmethod from a standard one.

     Date: 12 Sep 86 08:29 PDT
     From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
     
     I think we ought to concentrate on finding
     the right abstractions and specifying them

I claim that we have.  One abstraction is defining a method;  that is done with
defmethod.  Another abstraction is defining a lexical context in which the slots
of an object can be accessed as if they were variables; that is done with with.

     Date: Fri, 12 Sep 86 11:59 EDT
     From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>

     Yes.  The idea of New Flavors was to get rid of "message passing" and
     instead go to "generic functions".  We did that, and New Flavors still
     has "self" and "auto-with" even though it has "generic functions"
     instead of "message passing".

Frankly, I claim that is an inelegance in the design of new flavors.

     What makes them go away is not "generic functions",
     but "multimethods".

No, I think that generic functions makes them go away.  What multimethods
do is make it clear that generic functions should make self and auto-with go
away.  Multimethods, being the general case of generic functions make it
clear that it is wrong to think of any single distinguished argument to a
generic function as somehow having a greater status than the others.

     It seems to me that you folks are worried that providing the
     "traditional" syntax will discourage users from taking advantage of the
     greater power provided by the multimethod capability of the new spec.  I
     believe that we can take care of this by the organization and phrasing
     of the documentation of the spec.

I agree that documentation can go a long way towards making it clear that
classical defmethod syntax is an abbreviation for a defmethod and a with.
But I don't think we are worried about what you suggest we are.  I frankly
think that extending the behavior of the standard defmeth so that it does
auto-with is conceptually in-elegant.

But I agree that it provides a convenience that many people have grown
used to.  So, given appropriate documentation, and a design for arguments
to defmethod which is nice, I might be willing to concede on this issue.  But
I suspect that we are going to have to go to having to seperate names for
these things, which is where we were two weeks ago (but they were the
wrong names).

∂12-Sep-86  1752	RPG   	ordering of defclasses 
 ∂12-Sep-86  1701	Owners-CommonLoopsCore↑.pa@Xerox.COM 	ordering of defclasses
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Sep 86  17:01:03 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 12 SEP 86 14:35:40 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa@XEROX.ARPA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 12 SEP 86 14:23:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 102194; Fri
 12-Sep-86 17:22:45 EDT
Date: Fri, 12 Sep 86 17:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ordering of defclasses
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860912130952.1.GREGOR@AVALON.XEROX-PARC>
Message-ID: <860912172209.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 12 Sep 86 13:09 PDT
    From: Gregor.pa@Xerox.COM

    Currently the spec makes no statement about when all the included
    classes of a class must be defined:

      1. They must be defined before the defclass is evaluated.  PCL does
    this now.  I don't like this it makes it harder to order loading of
    files for no good reason.

      2. They must be defined before an instance of the class is created.
    This is what flavors does now and is what I think we should do.  It
    takes only a very little bit of implementation overhead and provides the
    user with nice convenience.

    So, these two rules should be added to the spec:

    All the classes in the included classes tree of a class must be defined
    before it is legal to make an instance of the class.

    A class must be defined before it can be mentioned as an argument
    specifier in a defmethod.

Flavors in fact requires that all of the component flavors must be
defined before you can do a defmethod.  I believe the reason for this
applies to Common Lisp Classes as well, and would translate into a third
rule:

  All the classes in the included classes tree of a class must be
  defined (known to the compiler) before it is legal to
  evaluate (compile) a WITH.

With this addition, I agree.

∂12-Sep-86  1756	RPG   	Getting together to work    
 ∂12-Sep-86  1701	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Getting together to work   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Sep 86  17:00:00 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 12 SEP 86 13:31:52 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 12 SEP 86 13:06:28 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79640;
 Fri 12-Sep-86 14:34:31 EDT
Date: Fri, 12 Sep 86 14:34 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Getting together to work
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860910-154308-2286@Xerox>
Message-ID: <860912143428.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 10 Sep 86 15:42 PDT
    From: Gregor Kiczales <Gregor.pa@Xerox.COM>

    We had made a plan to get together monday moring at OOPSLA and work on
    the spec.  I believe that we will have more work to do than can be done
    in three hours.

    Instead, I propose that we get together Friday and Saturday after OOPSLA
    in Palo Alto.  This will give us enough time to actually get some work
    done, and takes advantage of existing travel to get a lot of people in
    the same place.

I talked about this with Dan and Sonya.  We agree that we need a face to face
meeting, but we're not sure about the timing.  We all think it would be better
to have the meeting before OOPSLA rather than after, so that at OOPSLA we are
all telling the same story to people we talk to.  Also we promised at the Lisp
conference that we would hand something out at OOPSLA showing our progress,
and it seems like a good idea to have a face to face meeting to finalize what
goes into that document.

If we're going to meet before OOPSLA there are some constraints.  Dan is not
available until the 24th.  Dan and I are not available on the 26th.  Sonya
can't really spend a whole week away from the office.  There seem to be several
possibilities:

Meet on the weekend Sep 27-28, or just Sep 28, either in Palo Alto or in
Portland.  It's probably possible for us to fly out Friday night, but
obviously a one-day meeting would be a little easier logistically than a
two-day meeting.  I don't know if one day is enough.

Meet on Thursday Sep 25 either in Cambridge or in Washington (this is the day
after the X3J13 meeting).

We also need to start talking through the mail about what excatly we're going
to have ready to hand out to the public at OOPSLA.

    I propose that we use the Monday morning at OOPSLA time to have a more
    open meeting with people from LMI and HP.

This sounds good.

∂13-Sep-86  2051	RPG   	Defmethod syntax  
 ∂12-Sep-86  2126	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Defmethod syntax 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Sep 86  21:26:06 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 12 SEP 86 21:24:12 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 12 SEP 86 21:23:51 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79829;
 Sat 13-Sep-86 00:22:32 EDT
Date: Sat, 13 Sep 86 00:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Defmethod syntax
To: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860913002227.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

I've read all the mail on this again and I'd like to try to converge
on something that we can all agree on.  This message is an attempt to
lay out all the issues without including any advocacy.

I think we can decide on the syntax of defmethod independent of issues
of discriminating on optional arguments, whether defgeneric is required
or optional, the abbreviated form of WITH that Danny Bobrow mentioned
(discussed in a separate message), and whether the syntax for classical
methods is a required or optional part of the standard.  (The syntax for
classical methods has to be provided for in some form in order to meet
the goal of migration through mechanical translation that we set for
ourselves last month, as you recall.)

I see three viable proposals.  I will give each proposal in the BNF
variant explained on page 8 of Common Lisp: the Language, except that
lowercase means italics and uppercase means roman, along with six
examples (the first lines of the same six methods for each).  The six
examples are: a multimethod without options; a multimethod with an
option; a default method without options; a default method with an
option; a classical method without options; and a classical method with
an option.

Each proposal actually comes in (a) and (b) forms, depending on what we
do about SETF.  That's discussed after the basic proposals.  Definitions
of nonterminal symbols are at the end of this message, so they don't
get in the way.


THREE VIABLE PROPOSALS:

(1) Unparenthesized Options

General syntax:
  (DEFMETHOD generic-function {option}*
             {lambda-list | qualified-lambda-list}
    {declaration | doc-string}*
    {form}*)

Classical syntax:
  (DEFMETHOD (generic-function self-class {option}*)
             {lambda-list | qualified-lambda-list}
    {declaration | doc-string}*
    {form}*)

(defmethod foo ((a c1) (b c2))
(defmethod foo :before ((a c1) (b c2))
(defmethod foo (a b)
(defmethod foo :before (a b)
(defmethod (foo c1) (b)
(defmethod (foo c1 :before) (b)


(2) Untyped Arglist

General syntax:
  (DEFMETHOD generic-function
             {lambda-list | qualified-lambda-list}
    {declaration | doc-string}*
    {form}*)
and
  (DEFMETHOD (generic-function {option}*)
             qualified-lambda-list
    {declaration | doc-string}*
    {form}*)

Classical syntax:
  (DEFMETHOD (generic-function self-class {option}*)
             lambda-list
    {declaration | doc-string}*
    {form}*)

(defmethod foo ((a c1) (b c2))
(defmethod (foo :before) ((a c1) (b c2))
(defmethod foo (a b)
(defmethod (foo :before) ((a t) b)
(defmethod (foo c1) (b)
(defmethod (foo c1 :before) (b)


(3) Two Names

General syntax:
  (DEFINE-METHOD generic-function
                 {lambda-list | qualified-lambda-list}
    {declaration | doc-string}*
    {form}*)
and
  (DEFINE-METHOD (generic-function {option}*)
                 {lambda-list | qualified-lambda-list}
    {declaration | doc-string}*
    {form}*)

Classical syntax:
  (DEFMETHOD (generic-function self-class {option}*)
             {lambda-list | qualified-lambda-list}
    {declaration | doc-string}*
    {form}*)

(define-method foo ((a c1) (b c2))
(define-method (foo :before) ((a c1) (b c2))
(define-method foo (a b)
(define-method (foo :before) (a b)
(defmethod (foo c1) (b)
(defmethod (foo c1 :before) (b)


SETF VARIANTS:

There are two different ways to add the ability to define methods for
SETF of a generic function to each proposal:

(a) Tack -SETF onto the special form name.

(b) Replace generic-function with (SETF generic-function).

In both variants, a setf-lambda-list is inserted between the regular
lambda-list and the {declaration | doc-string}* that begins the body.


DRAWBACKS OF EACH PROPOSAL:

(1) lambda-list is not always the second subform of DEFMETHOD.

(2) In general syntax, you cannot use options without having a
qualified-lambda-list rather than a plain lambda-list.  In other
words, a default daemon method has to have an extra t in it.
Classical syntax cannot be used to write multi-methods.
Classical syntax is a bit harder to identify at a glance,
although it's not syntactically ambiguous.

(3) Twice as many special forms.

(a) Twice as many special forms.  Need DEFGENERIC-SETF, too.

(b) Funny syntax, SETF in the car of a list means something different
from other symbols in the car of a list, i.e. the cdr of the list is not
{option}*.  Also SETF in the generic function changes the parsing of the
rest of the defmethod.


NONTERMINALS:

  generic-function -- a symbol that names the generic function
                      being specialized.
  self-class -- a symbol that names the class of the first argument.
  option -- a non-nil symbol or a number, used by method
            combination to identify the method.
  lambda-list -- as defined in CLtL p.60.
  qualified-lambda-list -- a lambda-list with at least one
            variable replaced by a type-qualified variable
            so that discrimination occurs on that argument.
  setf-lambda-list -- {lambda-list | qualified-lambda-list}
            except that for now there can be only one parameter.
  declaration, doc-string, form -- as defined in CLtL.

∂13-Sep-86  2100	RPG   	abbreviated form of WITH    
 ∂12-Sep-86  2131	Owners-CommonLoopsCore↑.PA@Xerox.COM 	abbreviated form of WITH   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Sep 86  21:31:41 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 12 SEP 86 21:30:40 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 12 SEP 86 21:30:21 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79830;
 Sat 13-Sep-86 00:28:43 EDT
Date: Sat, 13 Sep 86 00:28 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: abbreviated form of WITH
To: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860913002840.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

Elaborating on something Danny Bobrow mentioned, it would be possible
to extend the syntax of argument qualifications to provide an automatic
WITH.  The optional prefix-name and type-name arguments to WITH should
be optionally specifiable.  This syntax can be used on more than one
argument, but the program is invalid if there are any name conflicts,
just as in LET and just as in WITH with more one name-specification.

This seems like a good idea.  There are several ways it could be done,
let me try and propose some.  The syntax is the syntax for a
discriminating parameter specifier, in the BNF variant explained on page
8 of Common Lisp: the Language, except that lowercase means italics and
uppercase means roman.

(1) (variable class :WITH-VARS [prefix-name [type-name]])

(2) (variable :INSIDE class [prefix-name [type-name]])

(3) (variable class :WITH T [:PREFIX prefix-name] [:CLASS type-name])

(4) (variable :CLASS class :WITH T [:PREFIX prefix-name])

In all of these, the meaning of (variable class) is not changed.

You who are reading this will probably come up with some better ideas.

∂13-Sep-86  2101	RPG   	Re: Defmethod syntax   
 ∂13-Sep-86  1550	Masinter.pa@Xerox.COM 	Re: Defmethod syntax  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Sep 86  15:50:29 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 SEP 86 10:50:44 PDT
Date: 13 Sep 86 10:51 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Defmethod syntax
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Sat, 13 Sep 86 00:22 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860913-105044-4936@Xerox>

(4) two other names:

General syntax:
  (DEFMETHOD {generic-function | (generic-function {option}*)}
             {lambda-list | qualified-lambda-list}
    {declaration | doc-string}*
    {form}*)


(This combines the forms of your (2), and is upward compatible with DEFUN) 

and 

Classical syntax:
  (DEFINE-CLASSICAL-METHOD (generic-function self-class {option}*)
             lambda-list
    {declaration | doc-string}*
    {form}*)



∂14-Sep-86  1112	Gregor.pa@Xerox.COM 	Re: Getting together to work 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Sep 86  11:12:35 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 14 SEP 86 11:11:21 PDT
Date: 14 Sep 86 11:11 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: Getting together to work
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Fri, 12 Sep 86 14:34 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860914-111121-5339@Xerox>

Danny can't make it anytime between Washington and Oopsla.

DLW can't make it until the 24th.

During Washington or OOPSLA there isn't enough time (or peace and quiet).

In your message, you say "Sonya can't really spend a whole week away
from the office."  Does this mean that Sonya can't make it after OOPSLA
(because she is going to OOPSLA)?

If in fact Sonya can't make it right after OOPSLA then I don't see any way
that we are going to be able to take advantage of the travel we are going to
be making anyways to get together.  But I do think we should get together
real soon.  Would you all be interested in coming out here the week after
OOPSLA?

∂14-Sep-86  1118	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: ordering of defclasses 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Sep 86  11:18:26 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 14 SEP 86 11:14:41 PDT
Redistributed: CommonLoopsCore↑.pa
Received: from Cabernet.ms by ArpaGateway.ms ; 14 SEP 86 11:14:27 PDT
Date: 14 Sep 86 11:14 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: ordering of defclasses
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Fri, 12 Sep 86 17:22 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860914-111441-5341@Xerox>

     Date: Fri, 12 Sep 86 17:22 EDT
     From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
     
     
     Flavors in fact requires that all of the component flavors must be
     defined before you can do a defmethod.  I believe the reason for this
     applies to Common Lisp Classes as well, and would translate into a third
     rule:
     
       All the classes in the included classes tree of a class must be
       defined (known to the compiler) before it is legal to
       evaluate (compile) a WITH.
     
     With this addition, I agree.

Right.

∂14-Sep-86  1622	Gregor.pa@Xerox.COM 	Method Naming and Identity Proposal    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Sep 86  16:22:34 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 14 SEP 86 16:11:31 PDT
Date: Sun, 14 Sep 86 16:10 PDT
From: Gregor.pa@Xerox.COM
Subject: Method Naming and Identity Proposal
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860902233747.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860914161007.3.GREGOR@AVALON.XEROX-PARC>
Line-fold: no

I am not sure what you mean by making the concept of the names and
identities of methods precise.  Or what it is about the identities of
methods you want to specify.

Is this just for portable environment features like TRACE?  If so then I
agree that we need to specify a way to tell trace to trace a particular
method, but I don't believe we need to specify the kind of functionality
that comes to mind when I think of method names.
-------

∂14-Sep-86  1817	Gregor.pa@Xerox.COM 	default optional arguments to a generic function 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Sep 86  18:16:59 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 14 SEP 86 18:06:04 PDT
Date: Sun, 14 Sep 86 18:04 PDT
From: Gregor.pa@Xerox.COM
Subject: default optional arguments to a generic function
To: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860914180428.4.GREGOR@AVALON.XEROX-PARC>
Line-fold: no


For clarity, this message assumes that you have to do a defgeneric
before a defmethod.  I don't want to make up my mind about having to do
a defgeneric before a defmethod until I understand this issue of
defaulting optional arguments.

I have tried to process all the preceding mail on this subject.  Forgive
me if I have just re-iterated an existing position.

As terminology:

  GENERIC FUNCTION DEFAULTING is when the generic function proper
  provides default values for optional arguments to the generic
  function.  In the kind of generic function defaulting I am talking
  about, the defaulted values are used as part of the method lookup
  and passed on to whichever method is invoked.

  METHOD DEFAULTING is when a particular method provides default
  values for some of its arguments.

In this variant of generic function defaulting, it signals an error to
attempt to define a method on a generic function which accepts less than
the number of arguments that the generic function defaulting can
produce.  Here is an example:

(defgeneric draw (thing place &optional (clip-mask *clip-mask*)) ..)

This defmethod is legal:

(defgeneric draw ((thing block) (place window) clip-mask) ..)

But this defmethod is not:

(defgeneric draw ((thing block) (place window)) ..)

Moon's variant of generic function defaulting, in which the defaulted
values are dropped on the floor after method lookup does not have this
problem.  Each method must accept only as many required arguments as the
generic function proper.


So, I see two different schemes for generic function defaulting:

GFD #1. the defaults from the defgeneric are used only for method
        lookup. This is the kind I described above.  

GFD #2. the defaults from the defgeneric are used for method lookup
        and also passed to the method.

There is a fundamental conceptual difference here.  I am not sure which
I prefer, but I am leaning towards number 1.  Because...

    Date: Thu, 4 Sep 86 16:15 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    
    (make-specializable 'print)

This is the same as:    

(defgeneric print (object &optional stream))

    
    (defmethod print (x &optional ((stream gee-whiz-display))) ...)
    
    But (let ((*standard-output* <instance of the gee-whiz-display>))
	  (print <lisp-object>))
    calls the wrong method!  This is what I have been complaining about all
    along.  This is the key issue.

I agree that this is the key issue.  Using GFD #1, there is no problem.
You would have to specify a default value for the second argument to the
PRINT generic function as a whole:

(defgeneric print (object &optional (stream *standard-output*))

Then the example:

(let ((*standard-output* <instance of the gee-whiz-display>))
  (print <lisp-object>))

would get the right method.
-------

∂14-Sep-86  1837	Owners-commonloopscore↑.pa@Xerox.COM 	Method Identification      
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Sep 86  18:37:23 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 14 SEP 86 18:32:19 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 14 SEP 86
 18:32:09 PDT
Date: 14 Sep 86 18:31 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Method Identification   
To: commonloopscore↑.pa@Xerox.COM 
Message-ID: <860914-183219-5434@Xerox>

Presumably a method is identified by the pair of its generic function
and its argument signature (the classes of the arguments). Also,
presumably, the function FIND-METHOD uses this pair.
			-rpg-

------- End undelivered message -------

∂15-Sep-86  1152	Owners-commonloopscore↑.pa@Xerox.COM 	Method Identification      
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 86  11:52:02 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 86 10:38:36 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 15 SEP 86 10:37:26 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 80351;
 Mon 15-Sep-86 13:34:06 EDT
Date: Mon, 15 Sep 86 13:34 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Method Identification   
To: commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860914-183219-5434@Xerox>
Message-ID: <860915133401.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 14 Sep 86 18:31 PDT
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

    Presumably a method is identified by the pair of its generic function
    and its argument signature (the classes of the arguments). Also,
    presumably, the function FIND-METHOD uses this pair.

You forgot some things, such as the method-options.  This was discussed
extensively in my message of 2 Sep 86, message ID
<860902233747.7.MOON@EUPHRATES.SCRC.Symbolics.COM>.

∂15-Sep-86  1152	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Re: Defmethod syntax  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 86  11:52:11 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 86 10:42:43 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 15 SEP 86 10:38:41 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 80355;
 Mon 15-Sep-86 13:37:12 EDT
Date: Mon, 15 Sep 86 13:37 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Defmethod syntax
To: CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860913-105044-4936@Xerox>
Message-ID: <860915133708.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 13 Sep 86 10:51 PDT
    From: Masinter.pa@Xerox.COM

    (4) two other names:

    General syntax:
      (DEFMETHOD {generic-function | (generic-function {option}*)}
		 {lambda-list | qualified-lambda-list}
	{declaration | doc-string}*
	{form}*)


    (This combines the forms of your (2), and is upward compatible with DEFUN) 

    and 

    Classical syntax:
      (DEFINE-CLASSICAL-METHOD (generic-function self-class {option}*)
		 lambda-list
	{declaration | doc-string}*
	{form}*)

This would be fine except that it violates the goal we set for ourselves
last month of providing smooth migration paths for existing users of
Flavors and Portable Common Loops.  Since you can't tell a new-style
DEFMETHOD from a Flavors DEFMETHOD, it would be impossible to provide
incremental mechanical translation.  I don't think we should contemplate
abandoning that goal without a more compelling reason than merely liking
the spelling DEFMETHOD more than any other.

∂15-Sep-86  1152	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Method Naming and Identity Proposal  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 86  11:52:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 86 10:48:48 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 15 SEP 86 10:44:48 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 80362;
 Mon 15-Sep-86 13:43:29 EDT
Date: Mon, 15 Sep 86 13:43 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Method Naming and Identity Proposal
To: CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860914161007.3.GREGOR@AVALON.XEROX-PARC>
Message-ID: <860915134324.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: Sun, 14 Sep 86 16:10 PDT
    From: Gregor.pa@Xerox.COM

    I am not sure what you mean by making the concept of the names and
    identities of methods precise.  Or what it is about the identities of
    methods you want to specify.

To quote from my message of 2 Sep, which your message is a reply to:
"The key property of these names is that when two defmethod forms with the same
name (according to the EQUAL function) are evaluated, the second defmethod
replaces the method defined by the first defmethod, rather than defining a
second method."

    Is this just for portable environment features like TRACE?  

What would be needed for TRACE is a further extension, not merely making the
concept of method identity precise, but also reifying it as a Lisp
object that can be used as the method's name in the arguments to TRACE.
I wasn't proposing that, since it seems to be leaving the area of object
oriented programming and getting into other parts of the Common Lisp
specification.  To quote again from my message:
"In an implementation that has function-specs, these lists can be used as
function-specs to access the method's definition, trace it, and so forth.
In other implementations I guess there is no way to perform those operations."

In other words, I'm not proposing to require every implementation to have
function-specs (I would certainly like to, but not as part of the
object-oriented programming proposal).

I think I should have been clearer about what I meant by an identity and
what I meant by a name.  If the above hasn't clarified it, let me know and
I'll work harder on it.

								If so then I
    agree that we need to specify a way to tell trace to trace a particular
    method, but I don't believe we need to specify the kind of functionality
    that comes to mind when I think of method names.

What functionality is that?

∂15-Sep-86  1437	Owners-CommonLoopsCore↑.pa@Xerox.COM 	default optional arguments to a generic function    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 86  14:34:39 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 86 12:26:13 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 15 SEP 86 12:25:35 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 80419;
 Mon 15-Sep-86 15:24:38 EDT
Date: Mon, 15 Sep 86 15:24 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: default optional arguments to a generic function
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860914180428.4.GREGOR@AVALON.XEROX-PARC>
Message-ID: <860915152433.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: Sun, 14 Sep 86 18:04 PDT
    From: Gregor.pa@Xerox.COM

    For clarity, this message assumes that you have to do a defgeneric
    before a defmethod.  I don't want to make up my mind about having to do
    a defgeneric before a defmethod until I understand this issue of
    defaulting optional arguments.

    I have tried to process all the preceding mail on this subject.  Forgive
    me if I have just re-iterated an existing position.

    As terminology:

      GENERIC FUNCTION DEFAULTING is when the generic function proper
      provides default values for optional arguments to the generic
      function.  In the kind of generic function defaulting I am talking
      about, the defaulted values are used as part of the method lookup
      and passed on to whichever method is invoked.

      METHOD DEFAULTING is when a particular method provides default
      values for some of its arguments.

    In this variant of generic function defaulting, it signals an error to
    attempt to define a method on a generic function which accepts less than
    the number of arguments that the generic function defaulting can
    produce.  Here is an example:

    (defgeneric draw (thing place &optional (clip-mask *clip-mask*)) ..)

    This defmethod is legal:

    (defgeneric draw ((thing block) (place window) clip-mask) ..)

    But this defmethod is not:

    (defgeneric draw ((thing block) (place window)) ..)

    Moon's variant of generic function defaulting, in which the defaulted
    values are dropped on the floor after method lookup does not have this
    problem.  Each method must accept only as many required arguments as the
    generic function proper.

In my proposal of 2 September I had intended to require that each method
must accept the same number of arguments as the generic function.  My
proposal could be read otherwise if you believe that "is an error" means
the programmer can do it anyway, but I hadn't intended to propose that.
I think we all agree that requiring that the minimum number of arguments,
maximum number of arguments, and keyword parameter keywords be consistent
between all methods and the generic function is acceptable, at least I
don't recall anyone arguing against it and several people have proposed it.

    So, I see two different schemes for generic function defaulting:

    GFD #1. the defaults from the defgeneric are used only for method
	    lookup. This is the kind I described above.  

    GFD #2. the defaults from the defgeneric are used for method lookup
	    and also passed to the method.

Actually, the kind you described above seems to me to be GFD #2.
But that's not important, unless it means that I have completely
misunderstood what you're saying.  I think the breakdown into GFD #1
and GFD #2 really clarifies what's going on here.

    There is a fundamental conceptual difference here.  I am not sure which
    I prefer, but I am leaning towards number 1.  Because...

My proposal of 2 September was intended to eliminate the distinction
between these by declaring invalid any program that can tell the difference.
I guess that was not very clear in the proposal.  Does anyone have reasons
why programs that can tell the difference between GFD #1 and GFD #2 should
be allowed?  This would mean that the optional argument would be defaulted
to one value for method selection and then be defaulted to a different value
in the actual method, or else not accepted as an argument at all if we
didn't require the defmethod and defgeneric arguments to be consistent.

If there is no reason to allow programs that can tell the difference between
GFD #1 and GFD #2, then I think we should forbid them, since obviously this
leads to confusion.

	Date: Thu, 4 Sep 86 16:15 EDT
	From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    
	(make-specializable 'print)

    This is the same as:    

    (defgeneric print (object &optional stream))
    
	(defmethod print (x &optional ((stream gee-whiz-display))) ...)
    
	But (let ((*standard-output* <instance of the gee-whiz-display>))
	      (print <lisp-object>))
	calls the wrong method!  This is what I have been complaining about all
	along.  This is the key issue.

    I agree that this is the key issue.  Using GFD #1, there is no problem.
    You would have to specify a default value for the second argument to the
    PRINT generic function as a whole:

    (defgeneric print (object &optional (stream *standard-output*))

    Then the example:

    (let ((*standard-output* <instance of the gee-whiz-display>))
      (print <lisp-object>))

    would get the right method.
    -------

This example is obscured by the unclarity of the definition of
PRINT in the Common Lisp manual, which makes it unclear exactly where the
substitution of the value of *standard-output* for an unsupplied second
argument happens.  I in fact thought when I sent that message that
(make-specializable 'print) would be the same as (defgeneric print
(object &optional (stream *standard-output*)), but I hadn't read CLtL
carefully enough to realize that PRINT accepts NIL as a stream argument.

Of course we don't really want to specialize PRINT anyway, since it's
the function that outputs a carriage return before the object and a
space after.  What we really want to specialize is the internal
function, not named by CLtL, that is called by all of PRINT, PRIN1,
PRINC, PPRINT, WRITE, FORMAT ~S, PRIN1-TO-STRING, etc.  But that ruins
the example, since surely that internal function has the stream as
a required argument, not an optional one.

- - -

I think that we are actually in complete agreement here.  For an optional
argument to be used for discrimination, the defaulting has to be in the
defgeneric.  Now we can decide whether, when you do a defmethod without
first doing a defgeneric, it signals an error or generates an implied
defgeneric according to well-defined rules.

I think we also agree that the arglists of generic functions and methods
must be consistent; we need to define precisely what that means, but
intuitively I think it means that they are equal except for the names of
the arguments and the type qualifications in the methods.  Seeing the
confusion that can arise from subtle inconsistencies, e.g. different
default values for optional arguments, I now favor requiring stronger
consistency than mere agreement of number of arguments.  This needs to
be refined to a more precise specification; if people agree with the
intuitive specification I will volunteer to produce a precise
specification for consideration.

Does anyone disagree that we agree?

∂15-Sep-86  1436	Masinter.pa@Xerox.COM 	Re: Defmethod syntax  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 86  14:34:48 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 86 14:20:18 PDT
Date: 15 Sep 86 14:22 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Defmethod syntax
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Mon, 15 Sep 86 13:37 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860915-142018-6089@Xerox>

sorry... I was off the mailing list for a while, and missed the earlier
discussion.

I'm happy with spelling the new way of defining methods  some other way
than "defmethod". I don't care what the name is exactly, but I'd like it
to be short & simple to remember; I thought define-method was too long.
(I originally long ago proposed spelling it "defun".) 

Here's some more names

defpartial	(defines a partial function)
defmeth	(shorter than define-method, but otherwise an unfortunate
abbrev)
deffunction	(I know this is longer, but it emphasizes the "function"
nature
		of the beast well enough that I include it)
deffn		even shorter than defun, defines "partial functions" (don't
groan)
		I like this one the most. You can make a function into a method
		with a single character delete.




∂15-Sep-86  1436	Owners-commonloopscore↑.pa@Xerox.COM 	Goals of the Specification      
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 86  14:34:30 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 86 12:20:39 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 15 SEP 86
 12:20:21 PDT
Date: 15 Sep 86 12:20 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Goals of the Specification   
To: commonloopscore↑.pa@Xerox.COM 
Message-ID: <860915-122039-5943@Xerox>


It is difficult to design for a set of goals set in a meeting
that hardly anyone attened. Masinter did not attend it; neither
did I.  You cannot blame us for tryin to use only good design criteria
rather than these hidden goals.

I would say that the goals of backwards compatibility are admirable
as long as they don't imply a poorer design. We will probably have
to live with the new specification longer than the switchover period.
One can claim that Common Lisp itself is a poorer language because
it had to be compatible with MacLisp and like other existing Lisps.

I have few problems with requiring additional Common Lispage as part
of the CommonLos spec.

			-rpg-

∂15-Sep-86  1615	Owners-commonloopscore↑.pa@Xerox.COM 	Goals of the Specification      
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 86  16:15:47 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 86 15:58:51 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 15 SEP 86 15:58:13 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 80550;
 Mon 15-Sep-86 18:44:05 EDT
Date: Mon, 15 Sep 86 18:44 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Goals of the Specification   
To: commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860915-122039-5943@Xerox>
Message-ID: <860915184400.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 15 Sep 86 12:20 PDT
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

    It is difficult to design for a set of goals set in a meeting
    that hardly anyone attened. Masinter did not attend it; neither
    did I.  You cannot blame us for tryin to use only good design criteria
    rather than these hidden goals.

The goals weren't set in that four-person meeting at MIT on Friday after
the Lisp conference, but in earlier discussion that I thought you were
involved in (but I might be remembering wrong).  There was a policy
statement that we decided we weren't ready to hand out during the Lisp
Conference (or the object-oriented programming committee meeting that
coincided with the Lisp conference) which contained the goals.  I agree
that I erred in assuming that everyone on this mailing list had already
bought into a particular list of goals (in fact I have no idea who is
the complete population of this mailing list).

In any case, if we don't even agree on the goals of this project, we'd
better bring that out into the open and agree on some goals as soon as
possible.  Having heard almost nothing from you, I can only go on what
I have.  We Symbolics people are about to net-mail out a proposed
statement of goals, which can serve as a starting point for discussion.
Maybe that will help.

    I would say that the goals of backwards compatibility are admirable
    as long as they don't imply a poorer design. We will probably have
    to live with the new specification longer than the switchover period.
    One can claim that Common Lisp itself is a poorer language because
    it had to be compatible with MacLisp and like other existing Lisps.

One has.

    I have few problems with requiring additional Common Lispage as part
    of the CommonLos spec.

Again this is a question of goals.  Is it more important to make it easy
for every Common Lisp implementation to implement this spec, or to make
the spec include all the good ideas we might have thought of?  The only
statement of goals for this project I have ever seen speaks of simplicity
and implementability.

∂15-Sep-86  1743	Masinter.pa@Xerox.COM 	Re: Goals of the Specification       
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 86  17:43:34 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 86 16:17:58 PDT
Date: 15 Sep 86 16:15 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Goals of the Specification   
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Mon, 15 Sep 86 18:44 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: commonloopscore↑.pa@Xerox.COM
Message-ID: <860915-161758-6228@Xerox>

The current list contents of commonloopscore↑.pa@xerox.com is:

Bobrow.pa Common-Lisp-Class-archive@Stony-Brook.SCRC.Symbolics.COM
COMMON-LISP-OBJECT-SYSTEM@SU-AI.ARPA
CommonLoops-Spec-Archive@AI.AI.MIT.EDU DLW@QUABBIN.SCRC.Symbolics.COM
edsel!lgd@navajo.stanford.edu Gregor.pa Kahn.pa Lanning.pa
LGD@SU-AI.arpa Masinter.pa Moon@STONY-BROOK.SCRC.Symbolics.COM
SKeene@STONY-BROOK.SCRC.Symbolics.COM

I assume RPG gets the mail via COMMON-LISP-OBJECT-SYSTEM@SU-AI.ARPA,
although I don't know who else does. I'm not sure who LDG is (I assume
someone at Lucid) or SKeene@STONY-BROOK.SCRC.Symbolics.COM.


I don't think I object to what I've heard of the goals, I just didn't
see the list. Avoiding obvious name conflicts with Flavors and allowing
mechanical translation of Flavors, while a bow to backward
compatibility, is not an onerous one.


 

∂15-Sep-86  2005	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Defmethod syntax 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 86  20:04:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 86 19:22:39 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 15 SEP 86 19:22:24 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 80612;
 Mon 15-Sep-86 22:20:24 EDT
Date: Mon, 15 Sep 86 22:20 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Defmethod syntax
To: CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860913002227.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860915222018.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

I prefer (1b), with (1a) a close second.  (2) has too many funny
restrictions and (3) has too many special form names.

∂15-Sep-86  2101	Owners-CommonLoopsCore↑.pa@Xerox.COM 	default optional arguments to a generic function    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Sep 86  21:01:37 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 86 20:59:04 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa@XEROX.ARPA
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 15 SEP 86 20:58:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 80635;
 Mon 15-Sep-86 23:57:49 EDT
Date: Mon, 15 Sep 86 23:57 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: default optional arguments to a generic function
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860915152433.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860915235743.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: Mon, 15 Sep 86 15:24 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

I have a bit more to say on this topic.  I'll try to keep it short.

	Date: Sun, 14 Sep 86 18:04 PDT
	From: Gregor.pa@Xerox.COM

	...So, I see two different schemes for generic function defaulting:

	GFD #1. the defaults from the defgeneric are used only for method
		lookup. This is the kind I described above.  

	GFD #2. the defaults from the defgeneric are used for method lookup
		and also passed to the method.

	There is a fundamental conceptual difference here.  I am not sure which
	I prefer, but I am leaning towards number 1.

A good reason to prefer GFD #1 is that it doesn't interfere with
supplied-p parameters in the methods.  This is particularly important
for people who want to program with defmethod instead of defun, and
hence require that defmethod supports all the features of defun.  Ken
Kahn's suggestion of an alternate method-defining macro that does both
the defgeneric and the defmethod could take care of this, but it would
be nice to avoid introducing that extra special form if it isn't really
necessary.

A bad reason to prefer GFD #2 is that it is easier to implement the
discriminating function in straight Common Lisp, because methods are
always called with the same number of arguments.

    If there is no reason to allow programs that can tell the difference
    between GFD #1 and GFD #2, then I think we should forbid them, since
    obviously this leads to confusion.

Because of supplied-p parameters, I have to back off on this.  I think
we should go with GFD #1, same as Gregor leans toward.

    I think we also agree that the arglists of generic functions and methods
    must be consistent....

I have an anecdote that might illuminate the issue of whether two
methods for the same generic function should be allowed to have
different default-value forms for an optional argument, even when the
argument is not used for discrimination.  We have a stream operation
called read-cursorpos.  It takes an optional argument which is the units
in which the position is to be measured (pixels or characters).  The
default value for that argument is supposed to be pixels, but one or two
of the methods defaulted it to characters instead.  This caused bugs,
especially when streams are nested and one stream applies read-cursorpos
to another stream.  Because Flavors only requires that methods have
consistent numbers of arguments, and doesn't check consistency of
default-value forms, these bugs had to be found the hard way.  I tried
to think of an example where the freedom to have different default values
for an optional argument in different methods would be useful, but
could not come up with one.

Here is a proposed precise definition for arglist consistency.  It's a
bit longwinded, but I found that was necessary to make it precise and
cover all the cases.  Comments and amendments are invited.  Terminology
follows CLtL p.60.

The lambda-lists of all methods for a given generic function must be
consistent with each other and with the lambda-list in the defgeneric
[if defgeneric is optional, add "if present"].  Attempting to define a
method with an inconsistent lambda-list signals an error; a program
development environment might offer to modify the conflicting
lambda-lists to make them all consistent.

To compare two lambda-lists for consistency, use the following rules:

(1) The numbers of required parameters must be equal.

(2) The numbers of optional parameters must be equal.  In addition, the
initforms for corresponding optional parameters must be equal (using the
Lisp function EQUAL); an omitted initform is the same as NIL.

(3) If one lambda-list contains &rest or &key, so must the other
lambda-list.  It is valid for one lambda-list to have &rest and the
other to have &key.

(4) If both lambda-lists contain &key, the sets of keywords must be the
same, except that it is valid for a keyword to appear only in one
lambda-list if the other lambda-list contains &allow-other-keys.

(5) Keyword parameters with equal keywords that appear in both
lambda-lists must have equal initforms (using the Lisp function EQUAL);
an omitted initform is the same as NIL.

(6) Keyword parameters of a method, whose keywords are not among the
generic function's keyword parameters' keywords, cannot be type
qualified (i.e. cannot be used for discrimination).

(7) If an initform that appears in both lambda-lists references an
earlier parameter, that parameter must have the same name in both
lambda-lists and in the case of keyword parameters the parameter
specifiers must appear in the same order.  This ensures that variable
names in initforms have the same meaning everywhere the initform
appears.  [If defmethod is allowed inside a non-top-level lexical
context, add appropriate additional language about captured free
variables.]

(8) Ignore &aux and everything after it.

Note that parameter names, type qualifiers, and the names and presence
of supplied-p parameters have no effect on lambda-list consistency.
Lambda-list consistency in more abstract terms is: the minimum number of
arguments must be equal; the maximum number of arguments must be equal;
default values for optional and keyword parameters must be consistent;
the set of keyword parameter keywords must be consistent; the defgeneric
must contain all argument-defaulting information required for
discrimination.

These rules are stricter than necessary in the sense that initforms are
compared with EQUAL, rather than a predicate that determines whether the
result of evaluating them would be EQUAL.  Thus "foo" and (quote "foo")
would not be considered consistent initforms.  Furthermore, if an
initform references a parameter earlier in the lambda-list, the name of
the parameter matters.  I don't think the stricter rules hurt anything,
and they are simpler to explain than the minimal rules would be.

∂16-Sep-86  0626	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Proposed Goals (Statement for OOPSLA)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Sep 86  06:26:24 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 SEP 86 06:24:50 PDT
Return-Path: <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 16 SEP 86 06:24:34 PDT
Received: from JUNCO.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 104483; Tue
 16-Sep-86 09:16:58 EDT
Date: Tue, 16 Sep 86 09:16 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposed Goals (Statement for OOPSLA)
To: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860916091654.1.SKEENE@JUNCO.SCRC.Symbolics.COM>




I think it's important for us to start thinking about OOPSLA in regards to
this standardization effort.  It would be best to pass out something
written, because that way we can all agree before-hand on the written
statement, and after the meeting there won't be any confusion about what
was said.

I've put together a draft statement that could either stand alone, or be
the preface to some more specific documentation (if we have that in time).

Please let me know what you think about this Statement, and also your
thoughts on any other documentation that we could prepare (and get
consensus on) in time for the conference.

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

       TOWARD A COMMON LISP STANDARD FOR OBJECT-ORIENTED PROGRAMMING

This brief paper summarizes the work that is now going on toward defining a
new Common Lisp standard for object-oriented programming.

HISTORY AND MOTIVATION

Many people in the Common Lisp community see a need for defining a standard
for object-oriented programming that would be part of Common Lisp.  The
primary benefit of such a standard would be the ability to write portable
Common Lisp code in an object-oriented style.

At the Common Lisp committee meeting in Boston in December 1985, many
vendors of application software made it clear how important such a standard
is to them.  Again at the ACM Lisp Conference in Cambridge in August 1986,
the same point was made.

After the ACM Lisp Conference, there was a meeting of the Common Lisp
Object-oriented Programming Committee.  A clear consensus was reached that
we should begin work immediately to define a standard.  Representatives
from Xerox, Lucid, Symbolics, LMI, HP, Sun, and the Japanese CommonLisp
committee supported this consensus.

A working group composed of representatives from Xerox and Symbolics met
after the ACM Lisp Conference.  At that meeting we reached agreement on
several general goals.

In brief, the standard will be based on the meta-object framework of
CommonLoops, which allows experimentation with different philosophies of
object-oriented programming.  The standard will also take advantage of the
years of experience of Flavors, and include Flavors features such as
declarative method combination.  The standard will not be CommonLoops, nor
will it be Flavors; however it will incorporate the most useful features
from both.

PROGRESS IN AUGUST AND SEPTEMBER

During August and September, representatives from Xerox, Symbolics, and
Lucid began work on a draft specification of the standard.  We started with
the basic programmer interface for defining new classes and writing methods
and generic functions.  This work is ongoing, but it has not yet reached a
state where documentation is available.  [We hope that this sentence turns
out to be false, but for the moment it is true.]

GOALS FOR THE STANDARD

Some high-level goals were stated and agreed-upon:

Sound basis     The standard will include the aspects of object-oriented
                programming that are well-understood at this time.  The
                standard will omit ideas that are still subjects for
                research.

Flexibility     The meta-object protocol of the standard will offer a
                flexible framework for other designers to implement
                different schemes.  This encourages exploration of
                different styles of object-oriented programming.

Power           The standard will offer the basic tools for writing
                programs in an object-oriented style, and will be powerful
                enough that it meets the needs of most programs.  It should
                not be necessary for programmers to extend the system to do
                straightforward object-oriented programming.

Simplicity      The standard will specify just the language, not the
                programming tools and interactive development environment.

Compatibility   It should be a convenient and simple procedure to translate
                programs written in CommonLoops or Flavors to the new
                standard.  We intend to provide tools that will perform the
                translation automatically.

Implementation  The standard will allow efficient implementation on stock
                hardware as well as specialized machines.
                                                                        
FEATURES TO BE INCLUDED IN THE STANDARD

We are planning on including the following features.  This is not an
exhaustive list, but is intended to communicate some of the areas of
agreement that have been reached.

Generic functions
                The standard will use the normal Lisp function-calling
                syntax.

Class and Type Space Merging
                Every object in the Lisp system has a class and hence can
                be used to select methods.

Dispatching     The standard will allow for several types of dispatching,
                including classical methods (which dispatch on a single
                object) and multi-methods (which dispatch on more than one
                object).

Multiple inheritance
                Modules of behavior can be combined together freely; they
                need not fit into a rigid hierarchy.

Meta-objects    The standard defines objects for the major implementation
                entities of the system to allow for extensibility.
                Classes, methods, and generic functions all have
                corresponding objects, organized by well-defined,
                documented protocols.

Declarative Method Combination
                Method selection and combination are controlled
                declaratively, making it easier to construct programs from
                a collection of modules.  Users can easily define new
                method combination paradigms.

FUTURE PLANS

The working group intends to develop a draft specification for the
standard.  We will continue to involve the community in the feedback
process.

We will produce a portable implementation by evolving Portable Common Loops
to track the new specification.  The portable implementation will enable
the community to experiment with the ideas, gain a deeper understanding of
the ideas than is possible with only a specification, and ensure that the
new object-oriented programming language receives adequate real-life
testing before its adoption as a standard.


/sub
gregor.pa@xerox,bobrow.pa@xerox
My Version of Sonya's Blurb

I spent 10 minutes revising Sonya's note - hers turned out to be
fairly good. I've laid the groundwork to call the thing CommonLoops,
but I've spiced the description with some amount of flavor.

			-rpg-

ps. Oh yeah, here it is:

       TOWARD A COMMON LISP STANDARD FOR OBJECT-ORIENTED PROGRAMMING

This brief paper summarizes the work that is now going on toward defining a
new Common Lisp standard for object-oriented programming.

HISTORY AND MOTIVATION

There is currently substantial experience with object-oriented
programming paradigms within a variety of contexts. The two groups
have have the most experience in this area are Symbolics and Xerox.

Flavors, an important object-oriented programming extension to Lisp,
has been in use for more than 5 years. Over that period many valuable lessons
have been learned about object-oriented programming in Lisp. In 1985,
Symbolics took these lessons to heart and designed New Flavors, which
is a compatible extension to Flavors.

Xerox has had more than 10 years of experience with object-oriented
programming, both within the Lisp tradition and within the Smalltalk
tradition.  Over that period many lessons were learned, and in 1985 Xerox
began to design a new object-oriented programming extension to Common
Lisp, called CommonLoops.

In mid-1985 these two groups became aware of each other, and a significant
cross-fertilization occurred: CommonLoops absorbed some of the ideas
in New Flavors that weren't already in CommonLoops. The remarkable point,
though, was how similar these two object-oriented extensions to Lisp were.

Many people in the Common Lisp community now see a need for defining a
standard for object-oriented programming that would be part of Common
Lisp.  The primary benefit of such a standard would be the ability to
write portable Common Lisp code in an object-oriented style.

At the Common Lisp committee meeting in Boston in December 1985, many
vendors of application software made it clear how important such a
standard is to them.  Again at the ACM Conference on Lisp and Functional
Programming in Cambridge in August 1986, the same point was made.

After the ACM Conference there was a meeting of the Common Lisp
Object-oriented Programming Committee.  A clear consensus was reached that
work should begin immediately to define a standard.  Representatives
from Xerox, Lucid, Symbolics, LMI, HP, Sun, and the Japanese CommonLisp
committee supported this consensus.

A working group composed of representatives from Xerox and Symbolics met
after the ACM Conference; at the meeting this working group reached
agreement on several general goals.

In brief, the standard will be based on the meta-object framework of
CommonLoops, which allows experimentation with different philosophies of
object-oriented programming.  Additional features from New Flavors will be
added to CommonLoops to flesh out the programmer interface; in particular,
a declarative method combination facility and a classical method
definition syntax patterned after those features in New Flavors will be
added to CommonLoops to create an extension to Common Lisp that represents
the best features of both systems seamlessly merged.

PROGRESS IN AUGUST AND SEPTEMBER

During August and September, representatives from Xerox, Symbolics, and
Lucid began work on a draft specification of the standard.  This working
group started with the basic programmer interface for defining new classes
and writing methods and generic functions.  This work is ongoing, but a
draft of the programmer interface is available - the meta-object protocol
specification will be available soon.

GOALS FOR THE STANDARD

Some high-level goals were stated and agreed-upon:

Sound basis     The standard will include the aspects of object-oriented
                programming that are well-understood at this time.  The
                standard will omit ideas that are still subjects for
                research.

Flexibility     The meta-object protocol of the standard will offer a
                flexible framework for other designers to implement
                different schemes.  This encourages exploration of
                different styles of object-oriented programming.

Power           The standard will offer the basic tools for writing
                programs in an object-oriented style, and will be powerful
                enough that it meets the needs of most programs.  It should
                not be necessary for programmers to extend the system to do
                straightforward object-oriented programming.

Simplicity      The standard will specify just the language, not the
                programming tools and interactive development environment.

Compatibility   It should be a convenient and simple procedure to translate
                programs written in CommonLoops or New Flavors to the new
                standard.  We intend to provide tools that will perform the
                translation automatically.

Implementation  The standard will allow efficient implementation on stock
                hardware as well as specialized machines.
                                                                        
FEATURES TO BE INCLUDED IN THE STANDARD

The following features wil be included in the standard..  This is not an
exhaustive list, but is intended to communicate some of the areas of
agreement that have been reached.

Generic functions
                The standard will use the normal Lisp function-calling
                syntax.

Class and Type Space Merging
                Every object in the Lisp system has a class and hence can
                be used to select methods.

Dispatching     The standard will allow for several types of dispatching,
                including classical methods (which dispatch on a single
                object) and multi-methods (which dispatch on more than one
                object).

Multiple inheritance
                Modules of behavior can be combined together freely; they
                need not fit into a rigid hierarchy.

Meta-objects    The standard defines objects for the major implementation
                entities of the system to allow for extensibility.
                Classes, methods, and generic functions all have
                corresponding objects, organized by well-defined,
                documented protocols.

Declarative Method Combination
                Method selection and combination are controlled
                declaratively, making it easier to construct programs from
                a collection of modules.  Users can easily define new
                method combination paradigms.

FUTURE PLANS

The working group intends to develop a draft specification for the
standard.  The specification process will involve the community in the
feedback process.

There will be a portable implementation based on Portable Common Loops,
which will evolve to to track the new specification.  The portable
implementation will enable the community to experiment with the ideas,
gain a deeper understanding of the ideas than is possible with only a
specification, and ensure that the new object-oriented programming
language receives adequate real-life testing before its adoption as a
standard.


∂16-Sep-86  0630	Owners-commonloopscore↑.pa@Xerox.COM 	Re: Goals of the Specification       
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Sep 86  06:30:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 SEP 86 06:29:26 PDT
Return-Path: <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 16 SEP 86 06:28:46 PDT
Received: from JUNCO.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 104492; Tue
 16-Sep-86 09:25:51 EDT
Date: Tue, 16 Sep 86 09:25 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Goals of the Specification   
To: Masinter.pa@Xerox.COM
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860915-161758-6228@Xerox>
Message-ID: <860916092549.2.SKEENE@JUNCO.SCRC.Symbolics.COM>

    Date: 15 Sep 86 16:15 PDT
    From: Masinter.pa@Xerox.COM

    The current list contents of commonloopscore↑.pa@xerox.com is:

    Bobrow.pa Common-Lisp-Class-archive@Stony-Brook.SCRC.Symbolics.COM
    COMMON-LISP-OBJECT-SYSTEM@SU-AI.ARPA
    CommonLoops-Spec-Archive@AI.AI.MIT.EDU DLW@QUABBIN.SCRC.Symbolics.COM
    edsel!lgd@navajo.stanford.edu Gregor.pa Kahn.pa Lanning.pa
    LGD@SU-AI.arpa Masinter.pa Moon@STONY-BROOK.SCRC.Symbolics.COM
    SKeene@STONY-BROOK.SCRC.Symbolics.COM

    I assume RPG gets the mail via COMMON-LISP-OBJECT-SYSTEM@SU-AI.ARPA,
    although I don't know who else does. I'm not sure who LDG is (I assume
    someone at Lucid) or SKeene@STONY-BROOK.SCRC.Symbolics.COM.

I'm a writer at Symbolics.  -- Sonya Keene 


    I don't think I object to what I've heard of the goals, I just didn't
    see the list. Avoiding obvious name conflicts with Flavors and allowing
    mechanical translation of Flavors, while a bow to backward
    compatibility, is not an onerous one.


 

∂16-Sep-86  1128	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: default optional arguments to a generic function
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Sep 86  11:28:28 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 16 SEP 86 10:39:58 PDT
Redistributed: CommonLoopsCore↑.pa
Received: from Cabernet.ms by ArpaGateway.ms ; 16 SEP 86 10:38:19 PDT
Date: 16 Sep 86 10:37 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: default optional arguments to a generic function
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Mon, 15 Sep 86 23:57 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860916-103958-6836@Xerox>

    GFD #1. the defaults from the defgeneric are used only for method
	    lookup. This is the kind I described above.  

    GFD #2. the defaults from the defgeneric are used for method lookup
	    and also passed to the method.

There is a fundamental conceptual difference.  I think the notion of
supplying defaults is part of the contract between the generic function
and the world.  This is an argument for GFD #1.  We all seem to agree
that defmethods, if they specify optionals, must agree with the generic
function.  If the EQUALS rule is used for defaults (I support this),
then I see no reason for the default forms to be evaluated twice.  If
methods can have exactly the same supplied-p args as specified in the
generic function (no more, no less - just local renaming allowed) then
there is no penalty for passing supplied-p args to each method as
"required args".  The calling sequence is uniform.

Given:
(defgeneric foo (x &optional y (z *v1* supplied-z)) ...)
then the following is legal
(defmethod foo ((x c1) &optional ((y c2)) (z *v1* my-supplied-z))) ..)
and the following are illegal
(defmethod foo ((x c1) &optional (y NIL supplied-y)(z *v1*
my-supplied-z))) ..)
(defmethod foo ((x c1) &optional y (z *v1* ))) ..)


One issue to be addressed is the following.  If we insist on the EQUALS
rule, then if the default value form changes in the defgeneric, it must
be changed in all methods.  This redundancy is bad design.  To allow
arg-specification and supplied-p specification, I suggest another
keyword &optional-spec.  Following &optional-spec can be 
 {varName|(varName arg-specifier [supplied-p-var])}*
where the interpretation is the obvious one, given in my message of last
week.  The rule of supplied-p correspondence still holds, but no default
value form need be specified.



-- danny

∂16-Sep-86  1413	Gregor.pa@Xerox.COM 	the kinds of method lookup people claim they want
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Sep 86  14:12:58 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 16 SEP 86 14:00:48 PDT
Date: Tue, 16 Sep 86 13:59 PDT
From: Gregor.pa@Xerox.COM
Subject: the kinds of method lookup people claim they want
To: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860916135909.5.GREGOR@AVALON.XEROX-PARC>
Line-fold: no


I spent lunch today listening to people talk about the kinds of method
lookup which they would like to have CommonLoops support.  I was struck
by the variety of things which people claimed would be natural or
convenient or even essential.  By the end of lunch I was very confused
about what we should do about discriminating on optional arguments.

In the interest of confusing the rest of you, I thought I would collect a
list of all the cases of method definition people thought they would
want.  Please add any other examples or potential screw cases.

NOTE:  In each of these examples I have used some syntax and some
defining forms which I intend only to express the example.  Do not
regard the syntax I have used as a proposal for how we should do
anything.

Case 1a.  "draw-line"

draw-line takes an optional, the width of the line in device dependent
units.  Because they are device dependent units, each individual method
would like to default this argument on its own.

(defmethod draw-line ((dev printer) p1 p2 &optional (width 7))
  ...)

(defmethod draw-line ((dev window) p1 p2 &optional (width 1))
  ...)

Case 1b.

Within case 1, some methods may want to take an extra argument.  Also
see case 3 which is similar.

(defmethod draw-line ((d gray-display) p1 p2
		                       &optional (width 3)
						 (gray *gray1*))
  ..)

Case 2.  "draw (GFD#2)"

The generic function takes an optional argument.  For all the methods,
the optional argument should default to the same value.  In addition,
method lookup should be based on the value of the optional argument
(after defaulting) and the defaulted value should be passed in.  This
corresponds to what I previously called GFD#2.

(defgeneric draw (thing &optional (place *draw-window*))
  "Draw thing on place.")

(defmethod draw ((thing line) (place raster-display)) ...)

(defmethod draw ((thing line) (place vector-display)) ...)

People have also said that within the individual methods they would like
to have access to the supplied-p information for the optional argument.

Case 3.  "move"

A generic function (e.g. move) has only classical methods.  Some of the
methods want to accept more arguments than others.  For example: move
when then first argument is a block takes a position to move to, but
move when the first argument is a rabbit takes no extra arguments (the
rabbit will jump up and down).

(defmethod move ((b block) to-x to-y) ..)

(defmethod move ((r rabbit)) ..)

Case 4.  "Guy's proposal"

In this porposal, method lookup checks argument specifiers for only the
supplied arguments.  When there are two arguments supplied, the most
specific of the two argument methods is called.

  (defmethod foo (a b &optional (c x) (d y)) body)

  is simply an abbreviation for

  (defmethod foo (a b) (let ((c x) (d y)) body))
  (defmethod foo (a b c) (let ((d y)) body))
  (defmethod foo (a b c d) body)

So that:

(defmethod gls ((a boat) &optional ((p plane) *default*)) ..)
(defmethod gls ((a speed-boat)) ...)

(foo <a speed-boat>)           ;runs method 2
(foo <a speed-boat> <a plane>) ;runs method 1
-------

∂16-Sep-86  1841	Owners-CommonLoopsCore↑.pa@Xerox.COM 	run-super   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Sep 86  18:41:07 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 16 SEP 86 16:24:56 PDT
Return-Path: <Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41]) by
 Xerox.COM ; 16 SEP 86 16:23:57 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 81031;
 Tue 16-Sep-86 17:10:40 EDT
Date: Tue, 16 Sep 86 17:10 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: run-super
To: CommonLoopsCore↑.pa@Xerox.COM
References: <860905004612.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860916171027.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

The referenced message, from 5 September, contains two implementations
of RUN-SUPER in Flavors.  This message contains a third implementation
that eliminates some problems with the other two implementations, which
were discussed in that message.  All three of these implementations have
been tested and work.  To simply things, I removed :AROUND methods from
this version, but it would only take a few lines of code to put them
back in if we wished to do so.

I see no reason why this couldn't be the default method-combination type
in Common Lisp Classes.  Compilation will be a little slower than in
Flavors, but not much slower, and code that doesn't use run-super will
not pay any efficiency cost, while code that does use run-super will be
quite efficient.

Of course this exact implementation could not be used, because it uses
Flavors interfaces in place of meta-object protocols, uses Symbolics'
code-walker rather than one that can be assumed to be present in every
implementation, and contains machine-dependencies, especially connected
with the way method dispatching works in our system.  That's not
important, the important thing is the semantics of how RUN-SUPER and
method-combination fit together, which is:
  all the :BEFORE methods are executed, most-specific first
  the most specific primary method is executed, and supplies the
value(s)
    if it uses RUN-SUPER, that calls the next primary method, and so on
    if RUN-SUPER exhausts the supply of primary methods, it signals an
error
  all the :AFTER methods are executed, least-specific first

Shall we make this the default method-combination type, or does anyone
object?  (Myself, I object to the name RUN-SUPER, and maybe we can think
of a more expressive name.  If not, I can live with that one.)

Most of the hair in this code is connected with optimizations so that if
run-super is not used, the compiled code is exactly the same as in
Flavors
:daemon method-combination (no extra overhead for run-super).

;;;; Dynamically plus lexically scoped version, avoids problems of both
the above.
;;;; This scheme uses more machine-dependencies to avoid an extra level
of
;;;; lambda in the continuations.
;;;; I removed :AROUND methods but they could easily be added back in.

;;; List of alternating methods and self-mapping-tables, used by
RUN-SUPER
(DEFVAR *SUPERCLASS-CONTINUATIONS*)

;;; Shadowed by a MACROLET
(DEFUN RUN-SUPER ()
  (ERROR "RUN-SUPER not called from a proper lexical environment.
RUN-SUPER is only valid in a primary method with :SUPER-DAEMON
method-combination."))

;;; Appears at the tail of *SUPERCLASS-CONTINUATIONS*
;;; Change this to a function that just returns NIL if you prefer that
semantics
(DEFUN RUN-SUPER-EXHAUSTED (&REST IGNORE)
  (ERROR "RUN-SUPER called from the least specific method; no more
methods are available."))

(DEFINE-METHOD-COMBINATION :SUPER-DAEMON ()
     ((BEFORE "before" :EVERY :MOST-SPECIFIC-FIRST (:BEFORE))
      (PRIMARY "primary" :EVERY :MOST-SPECIFIC-FIRST () :DEFAULT)
      (AFTER "after" :EVERY :MOST-SPECIFIC-LAST (:AFTER)))
     (:METHOD-TRANSFORMER
       ;; Deal with run-super by transforming the method's arglist and
body
       (:METHOD-ARGLIST
	 (MULTIPLE-VALUE-SETQ (METHOD-ARGLIST METHOD-BODY)
	   (TRANSFORM-SUPER-DAEMON-METHOD FUNCTION-SPEC METHOD-ARGLIST
METHOD-BODY)))
       (:METHOD-BODY METHOD-BODY))
  ;; Remove from dependencies the primary methods that cannot be reached
by RUN-SUPER
  (SETQ PRIMARY (LOOP FOR METHOD IN PRIMARY
		      COLLECT METHOD
		      WHILE (METHOD-USES-RUN-SUPER METHOD)))
  ;; Return appropriate method combining form
  `(MULTIPLE-VALUE-PROG2
     ,(CALL-COMPONENT-METHODS BEFORE)
     ,(COND ((NULL PRIMARY) `NIL)
	    ((AND (NULL (REST PRIMARY))
		  (NOT (METHOD-USES-RUN-SUPER (FIRST PRIMARY))))
	     (CALL-COMPONENT-METHOD (FIRST PRIMARY)))	;Optimize single-method
case
	    (T
	     ;; Stash the machine-dependent information needed for run-super,
	     ;; then call the first primary method, which will call the rest of
them.
	     `(STACK-LET ((*SUPERCLASS-CONTINUATIONS*
			    (LIST ,@(LOOP FOR METHOD IN (REST PRIMARY)
					  COLLECT `(FUNCTION ,METHOD)
					  COLLECT `(GET-FLAVOR-MAPPING-TABLE-FOR-INSTANCE
						     SELF ',(METHOD-FLAVOR METHOD)))
				  #'RUN-SUPER-EXHAUSTED)))
		,(CALL-COMPONENT-METHOD (FIRST PRIMARY)))))
     ,(CALL-COMPONENT-METHODS AFTER)))

;;; Determine whether this method needs a binding of
*SUPERCLASS-CONTINUATIONS*
;;; This works by calling a machine-dependent facility
(DEFUN METHOD-USES-RUN-SUPER (FUNCTION-SPEC)
  (MULTIPLE-VALUE-BIND (VALUE FOUND)
      (COMPILER:FILE-DECLARATION FUNCTION-SPEC 'USES-RUN-SUPER)
    (IF FOUND VALUE (SI:FUNCTION-SPEC-GET FUNCTION-SPEC
'USES-RUN-SUPER))))

;;; Arrange for NOTE-WHETHER-METHOD-USES-RUN-SUPER to be called when
this method
;;; is defined, via the USES-RUN-SUPER declaration.  It would be better
to do this
;;; with meta-object protocols, when we have them.
(PUSHNEW '(USES-RUN-SUPER ADD-NOTE-WHETHER-METHOD-USES-RUN-SUPER)
	*DEFMETHOD-DECLARATIONS* :TEST #'EQUAL)

(DEFUN ADD-NOTE-WHETHER-METHOD-USES-RUN-SUPER (FUNCTION-SPEC DECLARATION
IGNORE)
  `((NOTE-WHETHER-METHOD-USES-RUN-SUPER ',FUNCTION-SPEC ',(SECOND
DECLARATION))))

;;; Called when a primary method with :SUPER-DAEMON method combination
is defined
(DEFUN NOTE-WHETHER-METHOD-USES-RUN-SUPER (FUNCTION-SPEC USES-RUN-SUPER)
  (LET ((CHANGED (AND (FDEFINEDP FUNCTION-SPEC)
		      (NOT (EQ (SI:FUNCTION-SPEC-GET FUNCTION-SPEC 'USES-RUN-SUPER)
			       USES-RUN-SUPER)))))
    ;; Record the information where METHOD-USES-RUN-SUPER can find it.
    (IF USES-RUN-SUPER
	(SI:FUNCTION-SPEC-PUTPROP FUNCTION-SPEC T 'USES-RUN-SUPER)
	(SI:FUNCTION-SPEC-REMPROP FUNCTION-SPEC 'USES-RUN-SUPER))
    ;; If combined methods have to call a different set of primary
methods now, update them.
    (WHEN CHANGED
      (RECOMPILE-FLAVOR (METHOD-FLAVOR FUNCTION-SPEC)
			:GENERIC (METHOD-GENERIC FUNCTION-SPEC)
			:IGNORE-EXISTING-METHODS T))))

;;; Expand any RUN-SUPER in the body of this method into the appropriate
code
;;; to call the next method on the continuation list and rebind that
list to its tail.
;;; This works by calling some machine-dependent facilities.
(DEFUN TRANSFORM-SUPER-DAEMON-METHOD (FUNCTION-SPEC METHOD-ARGLIST
METHOD-BODY)	 
  (DECLARE (VALUES METHOD-ARGLIST METHOD-BODY))
  ;; This is for primary methods only
  (UNLESS (OR (NULL (METHOD-OPTIONS FUNCTION-SPEC))
	      (EQUAL (METHOD-OPTIONS FUNCTION-SPEC) '(:DEFAULT)))
    (RETURN-FROM TRANSFORM-SUPER-DAEMON-METHOD (VALUES METHOD-ARGLIST
METHOD-BODY)))
  ;; Check whether the method actually uses RUN-SUPER
  (MULTIPLE-VALUE-BIND (DECLARATIONS BODY)
      (SI:FIND-BODY-DECLARATIONS METHOD-BODY NIL)
    (COND ((LT:MAPFORMS (LAMBDA (SUBFORM KIND USAGE RUN-SUPER-USED)
			  (IGNORE USAGE)
			  (COND (RUN-SUPER-USED
				 (VALUES T T))		;No need to look any further
				((AND (LISTP KIND) (EQUAL SUBFORM '(RUN-SUPER)))
				 (VALUES T T))		;RUN-SUPER called as a function
				(T (VALUES NIL NIL))))	;else keep looking
			(CONS 'PROGN BODY))
	   ;; This method contains a call to RUN-SUPER.
	   ;; Record that for the benefit of METHOD-USES-RUN-SUPER.
	   (WHEN COMPILER:UNDO-DECLARATIONS-FLAG
	     (COMPILER:FILE-DECLARE FUNCTION-SPEC 'USES-RUN-SUPER T))
	   ;; Adjust the arglist so we can pass the arguments on to the next
method.
	   (MULTIPLE-VALUE-BIND (ARGUMENTS APPLY NEW-METHOD-ARGLIST)
	       (LT:LAMBDA-LIST-ARGUMENTS METHOD-ARGLIST)
	     (VALUES
	       NEW-METHOD-ARGLIST
	       ;; Make the body copy the continuations from the special
variable
	       ;; into a lexical variable so that it gets scoped properly if
this method
	       ;; contains RUN-SUPER inside a LAMBDA, and so that if RUN-SUPER
is done
	       ;; twice the same method gets called each time, and put a
MACROLET
	       ;; of RUN-SUPER around the body.
	       `(,@DECLARATIONS
		 (DECLARE (USES-RUN-SUPER T))
		 (LET ((.SUPERCLASS-CONTINUATIONS. *SUPERCLASS-CONTINUATIONS*))
		   (MACROLET
		     ((RUN-SUPER ()
			`(LET ((*SUPERCLASS-CONTINUATIONS* .SUPERCLASS-CONTINUATIONS.))
			   ;; Machine-dependent call similar to CALL-COMPONENT-METHOD
			   (,',(IF APPLY 'APPLY 'FUNCALL)
			    (POP *SUPERCLASS-CONTINUATIONS*)	;Method
			    SELF
			    (POP *SUPERCLASS-CONTINUATIONS*)	;Mapping-table
			    .GENERIC.
			    ,',@ARGUMENTS))))
		     ,@BODY))))))
	  (T
	   ;; Ordinary method that doesn't use RUN-SUPER.  Record that fact for
	   ;; the benefit of METHOD-USES-RUN-SUPER, and return original arglist
and body
	   ;; with a declaration added saying it doesn't use run-super.
	   (WHEN COMPILER:UNDO-DECLARATIONS-FLAG
	     (COMPILER:FILE-DECLARE FUNCTION-SPEC 'USES-RUN-SUPER NIL))
	   (VALUES METHOD-ARGLIST
		   `(,@DECLARATIONS
		     (DECLARE (USES-RUN-SUPER NIL))
		     ,@BODY))))))


(DEFGENERIC SDTEST (X Y)
  (:METHOD-COMBINATION :SUPER-DAEMON))

(DEFFLAVOR SDTEST1 () ())
(DEFFLAVOR SDTEST2 () (SDTEST1))
(DEFFLAVOR SDTEST3 () (SDTEST2))

(DEFMETHOD (SDTEST SDTEST1) (X)
  (LIST 1 X))

(DEFMETHOD (SDTEST SDTEST2) (X)
  (CONS 2 (RUN-SUPER)))

(DEFMETHOD (SDTEST SDTEST3) (X)
  (CONS 3 (RUN-SUPER)))

(SDTEST (MAKE-INSTANCE 'SDTEST3) 105)
; => (3 2 1 105)

∂16-Sep-86  1841	Owners-CommonLoopsCore↑.PA@Xerox.COM 	What we should agree on before OOPSLA
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Sep 86  18:41:19 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 16 SEP 86 17:51:41 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 16 SEP 86 17:51:14 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 105361; Tue
 16-Sep-86 20:48:21 EDT
Date: Tue, 16 Sep 86 20:50 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: What we should agree on before OOPSLA
To: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860916205006.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

Here is what I would like us to try to agree on, in time to write it up
and distribute it to whoever is interested at OOPSLA.  I have pared this
list down to what I think is possible if we focus on this.  I think it's
important to come up with something real, if we take seriously the
promise we made to the community in August.

 - A statement of the goals and general character of this project.  This
   could be based on what SKeene mailed out this morning (Tuesday), with
   modifications resulting from other people's review of it.
   
 - The syntax of the most basic language facilities, with very brief
   discussions of their semantics and a statement that additional
   facilities are still being discussed.  See proposed list below.
   
 - A statement that meta-object protocols will exist and be precisely
   defined, but currently they are not ready to go into the document
   (assuming there isn't enough time left for this).


Basic language facilities that I think we can agree on by the end of
next week:
  DEFCLASS
    overall syntax
    some of the options
    some or all of the slot-options
    class precedence rules
  DEFGENERIC
    overall syntax
    some or all of the options
    setf syntax
  DEFMETHOD
    "general" syntax, with space left for "classical" syntax
    discrimination on required arguments
    discrimination by classes
    setf syntax
  WITH
    the only problem here is the name, which is too short
  MAKE-INSTANCE
    interface seen by the caller
    we may have to defer the protocol for initialization methods
  CLASS-OF
  PRINT-OBJECT
  DESCRIBE-OBJECT (can we name this DESCRIBE?)
  DEFINE-METHOD-COMBINATION
    we may have to postpone the details of this if we
    have trouble agreeing

This leaves out a great deal, but should be enough to give people
a good idea of what is coming.  At this point I think we should
leave out anything that we are having trouble converging on and
deal with it later.  There will be a face to face meeting after
OOPSLA.

I'd like some feedback on this!

∂17-Sep-86  0856	Bobrow.pa@Xerox.COM 	Re: run-super 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86  08:56:34 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 SEP 86 08:28:14 PDT
Date: 17 Sep 86 08:29 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: run-super
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Tue, 16 Sep 86 17:10 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860917-082814-7626@Xerox>

     To simplify things, I removed :AROUND methods from this version, but
     it would only take a few lines of code to put them back in if we wished
     to do so.

I would like to see the addition for :around. (What do you think
changing ":around" to ":full-shadow"?)  The particular feature I am interested
in is how you express the transformation of a form to a method. Is
this what your were referring to in:
     ;;;; This scheme uses more machine-dependencies to avoid
     ;;;; an extra level of lambda in the continuations.
 
That is, would you please fix up the following rough form of
the body of whopper-super-daemon combination. 
What would it look like in Common Lisp?  Thanks.  

(STACK-LET ((*SUPERCLASS-CONTINUATIONS*
			    (LIST ,@(LOOP FOR METHOD IN (REST AROUND)
					  COLLECT `(FUNCTION ,METHOD)
					  COLLECT `(GET-FLAVOR-MAPPING-TABLE-FOR-INSTANCE
						     SELF ',(METHOD-FLAVOR METHOD)))
				  (make-method-from-form `(MULTIPLE-VALUE-PROG2 ...))
;;; the (MULTIPLE-VALUE-PROG2 ...) is the body found in the referenced message.
;;; this last form transforms that expression appropriately 
                     )))
		,(CALL-COMPONENT-METHOD (FIRST AROUND)))))    


---
     The important thing is the semantics of how RUN-SUPER and
     method-combination fit together, which is:
       all the :BEFORE methods are executed, most-specific first the
       most specific primary method is executed, and supplies the value(s)
         if it uses RUN-SUPER, that calls the next primary method,
         and so on if RUN-SUPER exhausts the supply of primary methods, it
         signals an error
       all the :AFTER methods are executed, least-specific first

     Shall we make this the default method-combination type, or does
     anyone object?  (Myself, I object to the name RUN-SUPER, and maybe we
     can think of a more expressive name.  If not, I can live with that one.)

I am happy with this as the default. I have no better name than run-super.
run-continuation is not semantically correct, and super has a history people
can relate to.  I don't like the name "super-daemon" or even "daemon",
although history rgues for each of those. How about "simple-nested". or just
"nested" sincer the primary is nested in befores and afters, and run-super
does dynamically controlled nesting.

I would want to describe super-daemon in the spec in pieces.
The first would describe the specifcation of run-super alone as in Loops.  Then
I would describe standar declarative method combination, and the interaction.
Finally, I would want to describe the method combination language that allows 
these to be defined.



∂17-Sep-86  1036	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: default optional arguments to a generic function
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86  10:36:19 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 17 SEP 86 09:24:58 PDT
Redistributed: CommonLoopsCore↑.pa
Received: from Cabernet.ms by ArpaGateway.ms ; 17 SEP 86 09:24:43 PDT
Date: 17 Sep 86 09:21 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: default optional arguments to a generic function
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Mon, 15 Sep 86 23:57 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860917-092458-7674@Xerox>

Unfortunately, the most important typo in my GFD#1 and GFD#2 message is
that I said I was leaning towards GFD#1.  In fact, I lean towards #2.

	GFD #1. the defaults from the defgeneric are used only for method
		lookup. This is the kind I described above.  

	GFD #2. the defaults from the defgeneric are used for method lookup
		and also passed to the method.

Doesn't your anecdote, which provides a good example of why two methods
should not be allowed to have different default value forms also support
GFD#2?

     Date: Mon, 15 Sep 86 23:57 EDT
     From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
     
     Because of supplied-p parameters, I have to back off on this.

Supplied-p parameters are what confuse me too.  Let me recap my thinking
on this.

I think of the arguments that the generic function accepts as being part
of its contract with the world.  I think of any argument defaulting done
on those arguments as being part of that same contract (I lean towards
GFD#2).

But supplied-p information doesn't have anything to do with the
generic's contract with the world.  Instead, supplied-p information
seems to me to be part of the generic functions contract with its
methods.

For me, the question about supplied-p arguments comes down to deciding
if these two contracts (generic---world, generic---methods) are the
*same*.  In other words, the lambda list which appears in the defgeneric
clearly specifies the generic-world contract, the question is to what
extent does it also specify the generic-methods contract.

If we make the defgeneric completely specify both contracts, then the
defgeneric must say which arguments the methods can (and must) get
supplied-p information for.

If the defgeneric does not specify which arguments supplied-p
information is available for, but rather methods can ask for this
information on a per-method basis, I get confused.


     To compare two lambda-lists for consistency, use the following
rules:

I want to try to re-write these rules to get rid of this EQUAL rule
about optional argument default value forms.  In order to do that, I am
going to ignore the issue of supplied-p arguments (by not allowing
methods to get their hands on that information), and I am going to
assume that defgenerics are required.  Note that my rules compare
defgeneric lambda lists to defmethod lambda lists.

1. The method must accept as required arguments the sum of the generic's
   required optional and rest arguments.

2. &optional may not appear in a defmethod lambda list (an extension
would
   allow this in the case where the defgeneric lambda list has neither
&key
   nor &rest).

3. The method must accept the same keywords as the generic;
   OR it can accept a subset of the ones in the defgeneric if it has
   &allow-other-keys;
   OR it can accept a superset of the ones in the defgeneric if the
   defgeneric has &allow-other-keys.

4. &aux is not allowed in defgenerics, it is allowed in defmethods with
the
   usual meaning.

Here are some examples:

(defgeneric draw (thing &optional (place *drawing-place*)))

(defmethod draw ((thing box) (place window)) ...)
(defmethod draw ((thing box) (place printer)) ...)


(defgeneric save (file &rest things))

(defmethod save ((file fancy-file) things) ...)


(defgeneric shape (thing &optional &key width height &allow-other-keys))

(defmethod shape ((r rectangle) &key width height) ...)
(defmethod shape ((c circle) &key radius) ...)


I another message, I will send a minimal proposal about defmethod
arguments which I think provides all the functionality we really
understand, and could be extended to any optional argument scheme we
eventually work out.  If, by friday, we have settled on a scheme that
works for optional arguments I suggest we put this minimal proposal in
the spec to take to DC and OOPSLA.

∂17-Sep-86  1037	Kahn.pa@Xerox.COM 	Re: run-super   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86  10:36:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 SEP 86 09:30:11 PDT
Date: 17 Sep 86 09:29 PDT
Sender: Kahn.pa@Xerox.COM
Subject: Re: run-super
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Tue, 16 Sep 86 17:10 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
From: Kahn.pa@Xerox.COM, Bobrow.pa@Xerox.COM
Message-ID: <860917-093011-7680@Xerox>

Regarding your code

(DEFINE-METHOD-COMBINATION :SUPER-DAEMON ()
     ...
  ;; Remove from dependencies the primary methods that cannot be reached
by RUN-SUPER
  (SETQ PRIMARY (LOOP FOR METHOD IN PRIMARY
		      COLLECT METHOD
		      WHILE (METHOD-USES-RUN-SUPER METHOD)))
  ;; Return appropriate method combining form
  ...)

The last method in the primary list should be the first one that does
not use run-super.  Only if all primary methods use run-super,
#'RUN-SUPER-EXHAUSTED must be inserted at the end of the list.  It is
not an error for all primary methods to call run-super since in some
contexts the last primary method may be in another position in the
*SUPERCLASS-CONTINUATIONS* list.  We might also then define run-super?
that returns NIL if the next continuation  is #'RUN-SUPER-EXHAUSTED.


----- ken and danny

∂17-Sep-86  1037	Kahn.pa@Xerox.COM 	DEFCLASS should replace DEFSTRUCT   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86  10:37:05 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 SEP 86 10:14:41 PDT
Date: 17 Sep 86 10:14 PDT
Sender: Kahn.pa@Xerox.COM
Subject: DEFCLASS should replace DEFSTRUCT
To: CommonLoopsCore↑.pa@Xerox.COM
cc: Kahn.pa@Xerox.COM
From: Ken Kahn <Kahn.pa@Xerox.COM>
Message-ID: <860917-101441-7733@Xerox>

A few months ago we believed that CommonLoops could just extend
DEFSTRUCT to deal with multiple inheritance and metaclasses.  Then there
was this idea that DEFSTRUCT did some things poorly and we could do them
better in DEFCLASS.  I am willing to agree to this if the spec proposes
that we flush DEFSTRUCT from Common Lisp and provide a DEFSTRUCT macro
for backwards compatibility that is mostly implemented in CommonLoops.
Why should anyone use DEFSTRUCT anymore?  CommonLoops can provide a
STRUCTURE-CLASS metaclass that provides the same performance/capability
trade-offs as current DEFSTRUCT.  The :TYPE option is weird but it could
still be supported, so that instances and "structures" built out of
lists and vectors can be made and accessed in a uniform manner
(MAKE-INSTANCE, GET-SLOT...).  CLASS-OF won't work on them so one can't
put methods on them but that's the case in any case.  16 pages of the
Silver Book could go away if DEFSTRUCT is flushed.  It would be a shame
if Common Lisp had to have two ways of defining structured objects, one
of which subsumes the other.

In Sonya's message about goals she states:

    Simplicity      The standard will specify just the language, not the
                    programming tools and interactive development
environment.

I think a more important aspect of Simplicity is that the language
specified not be unduely complex.  Adding DEFCLASS and not removing
DEFSTRUCT clearly does add unneccessary complexity.

----- ken

∂17-Sep-86  1632	Gregor.pa@Xerox.COM 	Re: What we should agree on before OOPSLA   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86  16:31:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 SEP 86 11:51:57 PDT
Date: 17 Sep 86 11:47 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: What we should agree on before OOPSLA
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Tue, 16 Sep 86 20:50 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860917-115157-7842@Xerox>

This list looks pretty good to me.

I believe that Sonya's message is a good start for Part 1.  I know that
we have some small changes we want to make to it.  These will be in a
separate message.

I believe that the spec we are working on will satisfy Part 2, once we
work out the basic language facilities to be covered.  I agree that we
can work out all the basic language details you included at the end of
your message.  In addition, we may be able to come to some agreement on
optional arguments, I am not quite ready to quit on this.  

You may be right that we should not include what we have so far for
meta-object protocols.  You are certainly right that we don't have time
to tighten this up.

As I said yesterday, I hope to FEDx a spec to you by the end of the day
today.

In addition, I will try to send messages giving our current status for:

some defclass options which are unresolved,
with
describe-object
define-method-combination

I think these (except define-method-combination) should be easy to
resolve and can they be put in the spec easily.


∂17-Sep-86  1636	Gregor.pa@Xerox.COM 	The name of WITH   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86  16:32:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 SEP 86 13:12:52 PDT
Date: 17 Sep 86 13:12 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: The name of WITH
To: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860917-131252-7924@Xerox>

If people really think the name WITH is too short, then the name
WITH-SLOTS seems like the obvious best name to me.

∂17-Sep-86  1637	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: Getting together to work    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86  16:33:14 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 17 SEP 86 14:54:07 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 17 SEP 86 14:53:56 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106466; Wed
 17-Sep-86 17:41:42 EDT
Date: Wed, 17 Sep 86 17:41 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Getting together to work
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860914-111121-5339@Xerox>
Message-ID: <860917174139.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 14 Sep 86 11:11 PDT
    From: Gregor Kiczales <Gregor.pa@Xerox.COM>
    ....

The conclusion, after various discussions, is that Sonya Keene, Dave
Moon, and Dan Weinreb will be in Palo Alto from Thursday October 2
through Sunday October 5.  Exact times to be figured out later, but
basically all of Friday and Saturday will be available, possibly late
Thursday, and probably none of Sunday.  I'll send mail with exact times
when we know the flight times.

This what Gregor proposed originally.  I would have liked to have met
before OOPSLA instead, but it proved to be impossible.  I assume we'll
have intense working sessions on the details of the standard for these
two days, with people from Lucid, Symbolics, and Xerox.  Gregor, you're
going to arrange a meeting room and make sure people show up and stuff
like that, right?

∂17-Sep-86  1636	Bobrow.pa@Xerox.COM 	Proposed Goals (Statement for OOPSLA)  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86  16:32:14 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 SEP 86 11:32:16 PDT
Date: 17 Sep 86 11:33 PDT
From: Bobrow.pa@Xerox.COM
Subject: Proposed Goals (Statement for OOPSLA)
To: CommonLoopsCore↑.pa@Xerox.COM
cc: Bobrow.pa@Xerox.COM
Message-ID: <860917-113216-7821@Xerox>

Dick edited Sonya's version, then Danny and Gregor edited his to produce
this.


       TOWARD A COMMON LISP STANDARD FOR OBJECT-ORIENTED PROGRAMMING

This brief paper summarizes the work that is now going on toward defining
a new Common Lisp standard for object-oriented programming.

HISTORY AND MOTIVATION

There is currently substantial experience with object-oriented programming
paradigms within a variety of contexts. The two groups have have the most
experience in this area are Symbolics and Xerox.

Flavors, an important object-oriented programming extension to Lisp, has
been in use for more than 7 years. Over that period many valuable lessons
have been learned about object-oriented programming in Lisp. In 1985,
Symbolics took these lessons to heart and designed New Flavors, which is a
compatible extension to Flavors.

Xerox has had more than 10 years of experience with object-oriented
programming, both within the Lisp tradition and within the Smalltalk
tradition.  Over that period many lessons were learned, and in 1985 Xerox
began to design a new object-oriented programming extension to Common
Lisp, called CommonLoops.

In mid-1985 these two groups became aware of each other.  These two
object-oriented extensions to Lisp had important similarities.
CommonLoops evolved to include some of the ideas in new Flavors.

Many people in the Common Lisp community now see a need for defining a
standard for object-oriented programming that would be part of Common
Lisp.  The primary benefit of such a standard would be the ability to
write portable Common Lisp code in an object-oriented style.

At the Common Lisp committee meeting in Boston in December 1985, many
vendors of application software made it clear how important such a
standard is to them.  Again at the ACM Conference on Lisp and Functional
Programming in Cambridge in August 1986, the same point was made.

After the ACM Conference there was a meeting of the Common Lisp
Object-oriented Programming Committee.  A clear consensus was reached that
work should begin immediately to define a standard.  Representatives from
Xerox, Lucid, Symbolics, LMI, HP, Sun, and the Japanese CommonLisp
committee supported this consensus.

A working group composed of representatives from Xerox and Symbolics met
after the ACM Conference; at the meeting this working group reached
agreement on several general goals.

In brief, the standard will be based on the meta-object framework of
CommonLoops, which allows experimentation with different philosophies of
object-oriented programming.  Additional features from new Flavors will be
added to CommonLoops to flesh out the programmer interface; in particular,
a declarative method combination facility patterned after that in new
Flavors has been added to CommonLoops to create an extension to Common
Lisp that represents the best features of both systems.

PROGRESS IN AUGUST AND SEPTEMBER

During August and September, representatives from Xerox, Symbolics, and
Lucid began work on a draft specification of the standard.  This working
group started with the basic programmer interface for defining new classes
and writing methods and generic functions.  This work is ongoing, but a
draft of the programmer interface is available - the meta-object protocol
specification will be available soon.

GOALS FOR THE STANDARD

Some high-level goals were stated and agreed-upon:

Sound basis     The standard will include the aspects of object-oriented
                programming that are well-understood at this time.  The
                standard will omit ideas that are still subjects for
                research.

Flexibility     The meta-object protocol of the standard will offer a
                flexible framework for other designers to implement
                different schemes.  This encourages exploration of
                different styles of object-oriented programming.

Power           The standard will offer the basic tools for writing
                programs in an object-oriented style, and will be powerful
                enough that it meets the needs of most programs.  It should
                not be necessary for programmers to extend the system to do
                straightforward object-oriented programming.

Simplicity      The standard will specify just the language, not the
                programming tools and interactive development environment.

Compatibility   It should be a convenient and simple procedure to translate
                programs written in CommonLoops or New Flavors to the new
                standard.  We intend to provide tools that will perform the
                translation automatically.

Implementation  The standard will allow efficient implementation on stock
                hardware as well as specialized machines.
                                                                        
FEATURES TO BE INCLUDED IN THE STANDARD

The following features wil be included in the standard..  This is not an
exhaustive list, but is intended to communicate some of the areas of
agreement that have been reached.

Generic functions
                The standard will use the normal Lisp function-calling
                syntax.

Class and Type Space Merging
                Every object in the Lisp system has a class and hence can
                be used to select methods.

Dispatching     The standard will allow dispatching on the class of one
                (classical methods) or more (multi-methods) arguments.

Multiple inheritance
                Classes can be combined together freely; they
                need not fit into a rigid hierarchy.

Meta-objects    The standard defines objects for the major implementation
                entities of the system to allow for extensibility.
                Classes, methods, and generic functions all have
                corresponding objects, organized by well-defined,
                documented protocols.

Declarative Method Combination
                Method selection and combination can be controlled
                declaratively.  Users can define new
                method combination paradigms.

FUTURE PLANS

The working group is developing a draft specification for the standard.
The specification process will involve the community in the feedback
process.

Portable Common Loops will evolve to to track the new specification.  This
portable implementation will enable the community to experiment with and
gain a deeper understanding of the ideas than is possible with only a
specification.
∂17-Sep-86  1636	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: default optional arguments to a generic function
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86  16:32:45 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 17 SEP 86 13:18:15 PDT
Return-Path: <Moon@ALDERAAN.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from ALDERAAN.SCRC.Symbolics.COM ([192.10.41.109]) by
 Xerox.COM ; 17 SEP 86 13:17:57 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 5208; Wed
 17-Sep-86 16:14:22 EDT
Date: Wed, 17 Sep 86 16:15 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: default optional arguments to a generic function
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To:
 <860916-103819-6832@Xerox>,<860916135909.5.GREGOR@AVALON.XEROX-PARC>
Message-ID: <860917161551.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 16 Sep 86 10:37 PDT
    From: Bobrow.pa@Xerox.COM

	GFD #1. the defaults from the defgeneric are used only for method
		lookup. This is the kind I described above.  

	GFD #2. the defaults from the defgeneric are used for method lookup
		and also passed to the method.

    There is a fundamental conceptual difference.  I think the notion of
    supplying defaults is part of the contract between the generic function
    and the world.  

I agree.

		    This is an argument for GFD #1.  We all seem to agree
    that defmethods, if they specify optionals, must agree with the generic
    function.  If the EQUALS rule is used for defaults (I support this),
    then I see no reason for the default forms to be evaluated twice.  

This is an argument for GFD #2, I assume.  In GFD #1 I don't see how to
avoid evaluating the default forms twice.

								       If
    methods can have exactly the same supplied-p args as specified in the
    generic function (no more, no less - just local renaming allowed) then
    there is no penalty for passing supplied-p args to each method as
    "required args".  The calling sequence is uniform.

Supplied-p parameters are -not- part of the contract between the generic
function and the world, so requiring them to be the same in all methods
is a bit strange.  It's possible that this is the price we have to pay
to make everything work, but it's ugly.

    Given:
    (defgeneric foo (x &optional y (z *v1* supplied-z)) ...)
    then the following is legal
    (defmethod foo ((x c1) &optional ((y c2)) (z *v1* my-supplied-z))) ..)
    and the following are illegal
    (defmethod foo ((x c1) &optional (y NIL supplied-y)(z *v1*
    my-supplied-z))) ..)
    (defmethod foo ((x c1) &optional y (z *v1* ))) ..)

    One issue to be addressed is the following.  If we insist on the EQUALS
    rule, then if the default value form changes in the defgeneric, it must
    be changed in all methods.  This redundancy is bad design.  

On the other hand, not having the default value lexically visible in the
method could be argued by some people as bad design.  It's a difficult
situation.

								To allow
    arg-specification and supplied-p specification, I suggest another
    keyword &optional-spec.  Following &optional-spec can be 
     {varName|(varName arg-specifier [supplied-p-var])}*
    where the interpretation is the obvious one, given in my message of last
    week.  The rule of supplied-p correspondence still holds, but no default
    value form need be specified.

I think we need a better name than &optional-spec, but otherwise this
sounds reasonable, assuming that we want a way to do this.  The message
from Gregor below raises questions about whether discriminating on
optional arguments is going to fly at all.

    Date: Tue, 16 Sep 86 13:59 PDT
    From: Gregor.pa@Xerox.COM
    Subject: the kinds of method lookup people claim they want
    
    I spent lunch today listening to people talk about the kinds of method
    lookup which they would like to have CommonLoops support.  I was struck
    by the variety of things which people claimed would be natural or
    convenient or even essential.  By the end of lunch I was very confused
    about what we should do about discriminating on optional arguments.
    
    In the interest of confusing the rest of you, I thought I would collect a
    list of all the cases of method definition people thought they would
    want.  Please add any other examples or potential screw cases.
    
    NOTE:  In each of these examples I have used some syntax and some
    defining forms which I intend only to express the example.  Do not
    regard the syntax I have used as a proposal for how we should do
    anything.
    
    Case 1a.  "draw-line"
    
    draw-line takes an optional, the width of the line in device dependent
    units.  Because they are device dependent units, each individual method
    would like to default this argument on its own.

    (defmethod draw-line ((dev printer) p1 p2 &optional (width 7))
      ...)
    
    (defmethod draw-line ((dev window) p1 p2 &optional (width 1))
      ...)
    
    Case 1b.
    
    Within case 1, some methods may want to take an extra argument.  Also
    see case 3 which is similar.
    
    (defmethod draw-line ((d gray-display) p1 p2
					   &optional (width 3)
						     (gray *gray1*))
      ..)

The problem here is that the generic function doesn't have a consistent
contract.  The meaning, or even the existence, of one argument depends
on the class of another argument.  I don't see how a caller of draw-line
could operate without knowing the exact method that was going to be called.
From experience I know it's possible to have all sorts of arguments about
whether this is good or bad programming practice.  In New Flavors, these
arguments were resolved in favor of consistency of contracts, rather than
the increased flexibility of different contracts for different methods,
but not everyone was happy.

The rules I proposed earlier for consistency of defgeneric and defmethod
lambda-lists, which Danny seems to agree with, would rule out both 1a and
1b.  I don't know what to say about this; it may be impossible to please
all of the people all of the time.

    Case 2.  "draw (GFD#2)"
    
    The generic function takes an optional argument.  For all the methods,
    the optional argument should default to the same value.  In addition,
    method lookup should be based on the value of the optional argument
    (after defaulting) and the defaulted value should be passed in.  This
    corresponds to what I previously called GFD#2.
    
    (defgeneric draw (thing &optional (place *draw-window*))
      "Draw thing on place.")
    
    (defmethod draw ((thing line) (place raster-display)) ...)
    
    (defmethod draw ((thing line) (place vector-display)) ...)
    
    People have also said that within the individual methods they would like
    to have access to the supplied-p information for the optional argument.
    
Current ideas seem to be able to satisfy this one.

    Case 3.  "move"
    
    A generic function (e.g. move) has only classical methods.  Some of the
    methods want to accept more arguments than others.  For example: move
    when then first argument is a block takes a position to move to, but
    move when the first argument is a rabbit takes no extra arguments (the
    rabbit will jump up and down).
    
    (defmethod move ((b block) to-x to-y) ..)
    
    (defmethod move ((r rabbit)) ..)
    
This is another case where the function isn't really generic, because
it can only be meaningfully called by someone who knows exactly which
method is being called.

    Case 4.  "Guy's proposal"
    
    In this porposal, method lookup checks argument specifiers for only the
    supplied arguments.  When there are two arguments supplied, the most
    specific of the two argument methods is called.
    
      (defmethod foo (a b &optional (c x) (d y)) body)
    
      is simply an abbreviation for
    
      (defmethod foo (a b) (let ((c x) (d y)) body))
      (defmethod foo (a b c) (let ((d y)) body))
      (defmethod foo (a b c d) body)
    
    So that:
    
    (defmethod gls ((a boat) &optional ((p plane) *default*)) ..)
    (defmethod gls ((a speed-boat)) ...)
    
    (foo <a speed-boat>)           ;runs method 2
    (foo <a speed-boat> <a plane>) ;runs method 1

I hope this one has already been discredited as so confusing that no
one can cope with it.

-+-+-+-

Seeing all these different, and maybe not even mutually compatible,
things that people would like us to do, it is possible that we are
going to have to take the conservative approach and say that for now
we are only going to support discrimination on required arguments,
because discrimination on optional and keyword arguments is not yet
well-understood and there is not yet a concensus among users on which
to base a standard.  GFD #2 can be achieved within this framework
by the expedient of defining an "interface function" that defaults
the arguments, for instance:

(defun draw (thing &optional (place *draw-window* place-supplied-p))
  "Draw thing on place."
  (draw-internal thing place place-supplied-p))
    
(defmethod draw-internal ((thing line) (place raster-display) place-supplied-p) ...)
    
(defmethod draw-internal ((thing line) (place vector-display) place-supplied-p) ...)

Flavors provides the feature that you don't have to make
up the auxiliary name draw-internal, which is confusing because
the externally visible interface is named draw but you put methods
on draw-internal.  You do this by (translating out of the present
Flavors syntax, which is too biased against multimethods):

(defgeneric draw (thing &optional (place *draw-window* place-supplied-p))
  "Draw thing on place."
  (:method-arguments thing place place-supplied-p)
  (:function
    (funcall (generic draw) thing place place-supplied-p)))
    
(defmethod draw ((thing line) (place raster-display) place-supplied-p) ...)
    
(defmethod draw ((thing line) (place vector-display) place-supplied-p) ...)

∂17-Sep-86  1636	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: run-super, whoppers, wrappers    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86  16:32:30 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 17 SEP 86 13:18:01 PDT
Return-Path: <Moon@ALDERAAN.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from ALDERAAN.SCRC.Symbolics.COM ([192.10.41.109]) by
 Xerox.COM ; 17 SEP 86 13:17:41 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 5189; Wed
 17-Sep-86 15:42:59 EDT
Date: Wed, 17 Sep 86 15:44 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: run-super, whoppers, wrappers
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860917-082814-7626@Xerox>
Message-ID: <860917154410.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 17 Sep 86 08:29 PDT
    From: Bobrow.pa@Xerox.COM

	 To simplify things, I removed :AROUND methods from this version, but
	 it would only take a few lines of code to put them back in if we wished
	 to do so.

    I would like to see the addition for :around. (What do you think
    changing ":around" to ":full-shadow"?)  

The same as I thought on 11 September
(Message-ID: <860911172500.4.MOON@EUPHRATES.SCRC.Symbolics.COM>):
The name :full-shadow doesn't convey much meaning to my ear.

I'm not at all attached to the name "around".  I was just using it in
the absence of anything better, since it was the name someone else (I
forget who) mentioned.  Actually "around" seems to fit with "before" and
"after" better than "full-shadow".  I'd say that "around" is a somewhat
clearer name than "full-shadow", which is miles better than "whopper".
If we can find a clearer name than any of these, I'm all for it.

I should mention again that these "around" methods are different from
whoppers, in that they are implemented by a particular type of method
combination, rather than being available automatically to all types of
method combination.  If the standard said that all types of method
combination should support "around" methods, then either life would be
more difficult for a user wanting to define his own type of method
combination or we would have to subroutinize things so that it was
trivially easy for that user to include "around" support.  I assume
that subroutinization is possible, but I haven't thought out the details.

I may not have made it clear that I don't care whether whoppers per se
are in the standard as long as there is something with equivalent
functionality in the standard.  "Around" methods would suffice, I think.

Wrappers appear to be more powerful than "around" methods, at least in
terms of efficiency (eliminating function calls), but perhaps that can
be licked with an INLINE proclamation; I ought to think about this more.
For purposes of agreement before OOPSLA you don't need to think about
wrappers at all; I'll bring them up later if I don't convince myself
they aren't needed.

					    The particular feature I am interested
    in is how you express the transformation of a form to a method. 

The same way you always convert a form to a function, with lambda.  The
code is at the end of this message.

								    Is
    this what your were referring to in:
	 ;;;; This scheme uses more machine-dependencies to avoid
	 ;;;; an extra level of lambda in the continuations.

Not exactly.  The two earlier implementations of run-super required an
extra lambda for every method called by run-super, for no good reason.
The body of the lambda was just a call-component-method of the method, I
think.  This version eliminates those and calls the methods directly.
The cost of this efficiency improvement is that the RUN-SUPER macrolet
put into methods by TRANSFORM-SUPER-DAEMON-METHOD has to contain
additional hair to pass the arguments along, instead of just funcalling
the continuation with no arguments, and hence more of the Flavors
implementation is visible instead of abstracted out of sight; more about
this below.

	 The important thing is the semantics of how RUN-SUPER and
	 method-combination fit together, which is:
	   all the :BEFORE methods are executed, most-specific first the
	   most specific primary method is executed, and supplies the value(s)
	     if it uses RUN-SUPER, that calls the next primary method,
	     and so on if RUN-SUPER exhausts the supply of primary methods, it
	     signals an error
	   all the :AFTER methods are executed, least-specific first

	 Shall we make this the default method-combination type, or does
	 anyone object?  (Myself, I object to the name RUN-SUPER, and maybe we
	 can think of a more expressive name.  If not, I can live with that one.)

    I am happy with this as the default. I have no better name than run-super.
    run-continuation is not semantically correct, and super has a history people
    can relate to.  

Agreed.

		    I don't like the name "super-daemon" or even "daemon",
    although history rgues for each of those. How about "simple-nested". or just
    "nested" sincer the primary is nested in befores and afters, and run-super
    does dynamically controlled nesting.

"super-daemon" was just a name I was using in the absence of a suggested
name and wasn't a proposal for the standard.  I needed a name so I could
debug my code without clobbering the existing Flavors code.  In the
standard there would be no need to have two distinct method-combination
types, one that does daemons but not run-super, and another that does
daemons and run-super, so fewer names would be required.  "Nested"
doesn't convey any meaning to my ear.  The way to really wimp out would
be to call this type of method-combination "default", since it will be
the default type.  I'd rather have a more descriptive name, though.  Any
ideas?  My default assumption for right now is that it will be named
"daemon", but I'm not attached to that name.  We don't actually need a
name for this in order to reach agreement on the list of things I
proposed last night as a reasonable agenda for the document to be handed
out at OOPSLA.

    I would want to describe super-daemon in the spec in pieces.
    The first would describe the specifcation of run-super alone as in Loops.  Then
    I would describe standar declarative method combination, and the interaction.
    Finally, I would want to describe the method combination language that allows 
    these to be defined.

This sounds good.  This is an extension of the way we do it now:
First we describe solitary methods so there is no combination issue.
Then we describe having one primary method shadow another.  Here you
add run-super.  Then we describe :before, :after, and now :around methods.
Then we describe other built-in types of method-combination.  Then we
describe how to make your own types of method-combination.

Here is the revised code for the method-combination type.  The only
other change is to make TRANSFORM-SUPER-DAEMON-METHOD treat around
methods the same as primary methods.  Note that if I was going to
install this code I would first want to define some more abstractions,
similar to CALL-COMPONENT-METHOD, to hide the messy and
machine-dependent details of the method calling sequences.  I didn't do
that in this version because I wanted to make it work first and then
think about what the appropriate abstractions would be.  Another thing I
would want to do is to redo the STACK-LET since those lists are actually
constant, changing only when a change to the class structure occurs or a
method is redefined.  For this version I construct the continuation list
every time, and then use STACK-LET instead of LET to eliminate the
consing, but it would be better to construct the list once and arrange
for it to be updated when the class structure changes.  This is the sort
of place where I start wishing for meta-object protocols.  I don't want
to spend time thinking about this until after OOPSLA, but for now I'm
assuming that the Common Lisp Classes version of this
DEFINE-METHOD-COMBINATION would be much less ugly, because it would be
built on top of those abstractions and protocols.

(DEFINE-METHOD-COMBINATION :SUPER-DAEMON ()
     ((AROUND "around" :EVERY :MOST-SPECIFIC-FIRST (:AROUND))
      (BEFORE "before" :EVERY :MOST-SPECIFIC-FIRST (:BEFORE))
      (PRIMARY "primary" :EVERY :MOST-SPECIFIC-FIRST () :DEFAULT)
      (AFTER "after" :EVERY :MOST-SPECIFIC-LAST (:AFTER)))
     (:ARGLIST IGNORE &REST ARGS)
     (:METHOD-TRANSFORMER
       ;; Deal with run-super by transforming the method's arglist and body
       (:METHOD-ARGLIST
	 (MULTIPLE-VALUE-SETQ (METHOD-ARGLIST METHOD-BODY)
	   (TRANSFORM-SUPER-DAEMON-METHOD FUNCTION-SPEC METHOD-ARGLIST METHOD-BODY)))
       (:METHOD-BODY METHOD-BODY))
  ;; If there are no daemons, the code produced can be optimized
  (UNLESS (OR BEFORE AFTER)
    (SETQ PRIMARY (NCONC AROUND PRIMARY)
	  AROUND NIL))
  ;; Remove from dependencies the primary methods that cannot be reached by RUN-SUPER
  (SETQ PRIMARY (LOOP FOR METHOD IN PRIMARY
		      COLLECT METHOD
		      WHILE (METHOD-USES-RUN-SUPER METHOD)))
  ;; Return appropriate method combining form
  (IF (NULL AROUND)
      `(MULTIPLE-VALUE-PROG2
	 ,(CALL-COMPONENT-METHODS BEFORE)
	 ,(COND ((NULL PRIMARY) `NIL)
		((AND (NULL (REST PRIMARY))
		      (NOT (METHOD-USES-RUN-SUPER (FIRST PRIMARY))))
		 (CALL-COMPONENT-METHOD (FIRST PRIMARY)))	;Optimize single-method case
		(T
		 ;; Stash the machine-dependent information needed for run-super,
		 ;; then call the first primary method, which will call the rest of them.
		 `(STACK-LET ((*SUPERCLASS-CONTINUATIONS*
				(LIST ,@(LOOP FOR METHOD IN (REST PRIMARY)
					      COLLECT `(FUNCTION ,METHOD)
					      COLLECT `(GET-FLAVOR-MAPPING-TABLE-FOR-INSTANCE
							 SELF ',(METHOD-FLAVOR METHOD)))
				      #'RUN-SUPER-EXHAUSTED)))
		    ,(CALL-COMPONENT-METHOD (FIRST PRIMARY)))))
	 ,(CALL-COMPONENT-METHODS AFTER))
      ;; With both AROUND methods and daemons, need an internal method to call the daemons
      ;; and *SUPERCLASS-CONTINUATIONS* has to be bound around the whole thing
      `(STACK-LET ((*SUPERCLASS-CONTINUATIONS*
		     (LIST ,@(LOOP FOR METHOD IN (REST AROUND)
				   COLLECT `(FUNCTION ,METHOD)
				   COLLECT `(GET-FLAVOR-MAPPING-TABLE-FOR-INSTANCE
					      SELF ',(METHOD-FLAVOR METHOD)))
			   ;;--- The arglist of this lambda should be hidden by an
			   ;;--- abstraction, which would also allow it to not need
			   ;;--- to use &REST all the time
			   #'(LAMBDA (SELF SELF-MAPPING-TABLE .GENERIC. &REST ,ARGS)
			       (MULTIPLE-VALUE-PROG2
				 ,(CALL-COMPONENT-METHODS BEFORE)
				 ,(CALL-COMPONENT-METHOD (FIRST PRIMARY))
				 ,(CALL-COMPONENT-METHODS AFTER)))
			   SELF-MAPPING-TABLE
			   ,@(LOOP FOR METHOD IN (REST PRIMARY)
				   COLLECT `(FUNCTION ,METHOD)
				   COLLECT `(GET-FLAVOR-MAPPING-TABLE-FOR-INSTANCE
					      SELF ',(METHOD-FLAVOR METHOD))))))
	 ,(CALL-COMPONENT-METHOD (FIRST AROUND)))))

∂17-Sep-86  1636	Gregor.pa@Xerox.COM 	required-xxx options to defclass  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86  16:32:57 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 SEP 86 13:26:58 PDT
Date: 17 Sep 86 13:26 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: required-xxx options to defclass
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860917-132658-7944@Xerox>

This seems to be an issue that remains to be worked out about defclass.

Until yesterday, I was the only west coast supporter of the
:required-methods etc. options to defclass.  But I have finally given in
and conceded that maybe these should not be in the standard.

I had been able to convince people that these options were not, in fact,
merely a programming environment feature.  But I finally succumbed to
the argument that:

These options are just hack implementations of something which
*protocols* would do right.  Given that we don't have protocols, and we
don't want to clutter the spec with hacks, we should not include these
options.  Then, when we do figure out how to do protocols "right", there
won't be these old, obsolete required-xxx options hanging around.

How do you feel about not having :required-xxx options in the standard?

∂17-Sep-86  2028	Owners-CommonLoopsCore↑.pa@Xerox.COM 	DEFCLASS should replace DEFSTRUCT    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86  20:28:46 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 17 SEP 86 16:51:18 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 17 SEP 86 16:50:58 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106567; Wed
 17-Sep-86 19:49:30 EDT
Date: Wed, 17 Sep 86 19:49 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DEFCLASS should replace DEFSTRUCT
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860917-101441-7733@Xerox>
Message-ID: <860917194955.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 17 Sep 86 10:14 PDT
    From: Ken Kahn <Kahn.pa@Xerox.COM>

    A few months ago we believed that CommonLoops could just extend
    DEFSTRUCT to deal with multiple inheritance and metaclasses.  Then there
    was this idea that DEFSTRUCT did some things poorly and we could do them
    better in DEFCLASS.  I am willing to agree to this if the spec proposes
    that we flush DEFSTRUCT from Common Lisp and provide a DEFSTRUCT macro
    for backwards compatibility that is mostly implemented in CommonLoops.
    Why should anyone use DEFSTRUCT anymore?

I believe this should be proposed as a separate standardization item.
I don't think the object-oriented programming standard should stand or
fall on the basis of irrelevant considerations such as whether someone
out there is particularly attached to DEFSTRUCT.

∂17-Sep-86  2029	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: run-super    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86  20:28:52 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 17 SEP 86 17:02:09 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 17 SEP 86 17:01:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106573; Wed
 17-Sep-86 20:00:05 EDT
Date: Wed, 17 Sep 86 20:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: run-super
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860917-093011-7680@Xerox>
Message-ID: <860917200030.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 17 Sep 86 09:29 PDT
    From: Kahn.pa@Xerox.COM, Bobrow.pa@Xerox.COM

    Regarding your code

    (DEFINE-METHOD-COMBINATION :SUPER-DAEMON ()
	 ...
      ;; Remove from dependencies the primary methods that cannot be reached
    by RUN-SUPER
      (SETQ PRIMARY (LOOP FOR METHOD IN PRIMARY
			  COLLECT METHOD
			  WHILE (METHOD-USES-RUN-SUPER METHOD)))
      ;; Return appropriate method combining form
      ...)

    The last method in the primary list should be the first one that does
    not use run-super.  

That's exactly what that code does.  You may have been misled by thinking
that LOOP executes its clauses out of order, the way Interlisp FOR does.
The above LOOP stops -after- collecting the method for which
METHOD-USES-RUN-SUPER is false.

			Only if all primary methods use run-super,
    #'RUN-SUPER-EXHAUSTED must be inserted at the end of the list.  

That's true, the list could be shortened by one element in the case
where the last element is unreachable.  I'll put a comment in my copy of
that program saying that it should be optimized.  Also, I forgot to
include #'RUN-SUPER-EXHAUSTED at the end of the list in the
around-method case, in the revised version of the code I mailed out
earlier today.

								    It is
    not an error for all primary methods to call run-super since in some
    contexts the last primary method may be in another position in the
    *SUPERCLASS-CONTINUATIONS* list.  

That's a good point.  That sinks my idea of detecting the
RUN-SUPER-EXHAUSTED at compile time instead of at run time; good, I can
stop worrying about that.

				      We might also then define run-super?
    that returns NIL if the next continuation  is #'RUN-SUPER-EXHAUSTED.

Yes, we could do that.  Note that standard Common Lisp functions aren't
allowed to have question marks in their names, but I'm sure we could think
of a better name.

∂17-Sep-86  2029	Masinter.pa@Xerox.COM 	Re: DEFCLASS should replace DEFSTRUCT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86  20:28:58 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 SEP 86 19:52:38 PDT
Date: 17 Sep 86 19:50 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: DEFCLASS should replace DEFSTRUCT
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Wed, 17 Sep 86 19:49 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860917-195238-8313@Xerox>

I disagree (rather violently). I think that the reason that CommonLoops
was originally acceptable to a large class of people was that it did not
add substantially to the complexity of the Language. The acceptability
of CommonLoops partially on that principle, and any movement away from
it risks losing it.

It is certainly not a separable consideration. 

Similarly, a syntax where DEFUN was syntactically compatible with
DEFMETHOD (or whatever its method alias is called) is another important
simplification of Common Lisp. Making a large number of alternative
forms, adding DEFGENERIC, and number of the other proposed extentions
which have been added by this negotiating group are a potentially
drastic movement away from the simplicity in the original proposal. 

I had been misled into believing the discussions on CommonLoopsCore↑ was
an attempt to do some minor tuning on the way that metaclasses were set
up and initialization. Into the conversation for a couple of days, I've
found that things have drifted radically away from what we and many
others have agreed to support.

/sub
"commonloopscore↑.pa"@xerox
DEFCLASS should replace DEFSTRUCT

I bow to those who use mailers that sort mail according to subject:
My message is responsive to the discussion which has gone on under
this subject line, but the contents of my remarks and of the remarks
to which I reply bear no semantic relationship to the subject line.

There indeed was a simplicity in the early CommonLoops proposal, but the
simplicity was the simplicity of a naive proposal. In particular, the
use of Defmethod as a vague replacement for Defun to create a cloud of
functions that are invoked variously misses the goal of a clearly understood
construct. What precisely is the contract between this cloud and the outside
world? How does this cloud relate to Lisp functions? If you can FUNCALL this
cloud, can you affect it by affecting the thing that sits in the symbol-function
cell of a symbol? Simply stated, is the cloud a first-class object, or is it
like the heap?

The `negotiating' group is doing more than negotiating: It is attempting to
bring some design sense into the picture. The early CommonLoops proposal
was more like a slogan than a well-designed system.

			-rpg-
∂17-Sep-86  2031	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Proposed Goals (Statement for OOPSLA)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86  20:29:10 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 17 SEP 86 19:54:42 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 17 SEP 86 19:53:16 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106633; Wed
 17-Sep-86 22:51:47 EDT
Date: Wed, 17 Sep 86 22:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposed Goals (Statement for OOPSLA)
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860917-113216-7821@Xerox>
Message-ID: <860917225211.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 17 Sep 86 11:33 PDT
    From: Bobrow.pa@Xerox.COM

    Dick edited Sonya's version, then Danny and Gregor edited his to produce
    this.

All of the changes are okay with me, except that I have problems with the
style of this one:

    In brief, the standard will be based on the meta-object framework of
    CommonLoops, which allows experimentation with different philosophies of
    object-oriented programming.  Additional features from new Flavors will
    be added to CommonLoops to flesh out the programmer interface; in
    particular, a declarative method combination facility patterned after
    that in new Flavors has been added to CommonLoops to create an extension
    to Common Lisp that represents the best features of both systems.   

This confuses what has been done to CommonLoops so far, adding some
Flavors ideas, with the definition of the standard.  Those are two
different things.  I think I understand what you're trying to get at
with this improvement of the earlier version of this paragraph, and I'd
like to propose this revision:

In brief, the standard will be based on the meta-object framework of
CommonLoops, which allows experimentation with different philosophies of
object-oriented programming.  The programmer interface on top of this
framework will combine the most useful features of CommonLoops and New
Flavors, such as multimethods from CommonLoops and declarative method
combination from Flavors.  The standard will be an extension to Common
Lisp that incorporates the best features of both systems.

∂17-Sep-86  2224	Owners-CommonLoopsCore↑.pa@Xerox.COM 	The name of WITH 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86  22:24:06 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 17 SEP 86 20:37:55 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 17 SEP 86 20:37:44 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106656; Wed
 17-Sep-86 23:34:14 EDT
Date: Wed, 17 Sep 86 23:34 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: The name of WITH
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860917-131252-7924@Xerox>
Message-ID: <860917233439.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 17 Sep 86 13:12 PDT
    From: Gregor Kiczales <Gregor.pa@Xerox.COM>

    If people really think the name WITH is too short, then the name
    WITH-SLOTS seems like the obvious best name to me.

That sounds good to me too.

∂17-Sep-86  2224	Owners-CommonLoopsCore↑.pa@Xerox.COM 	required-xxx options to defclass
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Sep 86  22:24:14 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 17 SEP 86 20:55:02 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 17 SEP 86 20:54:52 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106667; Wed
 17-Sep-86 23:52:13 EDT
Date: Wed, 17 Sep 86 23:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: required-xxx options to defclass
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860917-132658-7944@Xerox>
Message-ID: <860917235226.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 17 Sep 86 13:26 PDT
    From: Gregor Kiczales <Gregor.pa@Xerox.COM>

    These options are just hack implementations of something which
    *protocols* would do right.  Given that we don't have protocols, and we
    don't want to clutter the spec with hacks, we should not include these
    options.  Then, when we do figure out how to do protocols "right", there
    won't be these old, obsolete required-xxx options hanging around.

    How do you feel about not having :required-xxx options in the standard?

I'm not convinced that protocols will eliminate the :required-xxx
options.  However, I agree that the "sound basis" item in our professed
statement of goals requires that things we suspect, after sufficient
discussion, are not well understood should not be included.

The question, then, is whether these are sufficiently indispensable to
users to justify including them anyway (the "power" and "compatibility"
goals).  In this case I think the answer is no.  So let's leave these
out of the standard for now.

∂18-Sep-86  0625	Owners-CommonLoopsCore↑.pa@Xerox.COM 	The name of WITH 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86  06:25:36 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 18 SEP 86 05:29:12 PDT
Return-Path: <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 18 SEP 86 05:29:01 PDT
Received: from JUNCO.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106773; Thu
 18-Sep-86 08:19:01 EDT
Date: Thu, 18 Sep 86 08:17 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: The name of WITH
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860917233439.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860918081727.4.SKEENE@JUNCO.SCRC.Symbolics.COM>
Line-fold: No

    Date: Wed, 17 Sep 86 23:34 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	Date: 17 Sep 86 13:12 PDT
	From: Gregor Kiczales <Gregor.pa@Xerox.COM>

	If people really think the name WITH is too short, then the name
	WITH-SLOTS seems like the obvious best name to me.

    That sounds good to me too.

Does WITH-SLOTS only give you variables for each slot, or does it also
give you a "SELF" variable for the object itself?    If it also provides 
a variable for the object, maybe WITH-INSTANCE would be a better name. 


∂18-Sep-86  0811	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Proposed Goals (Statement for OOPSLA)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86  08:11:33 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 18 SEP 86 07:43:05 PDT
Return-Path: <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 18 SEP 86 07:42:09 PDT
Received: from JUNCO.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106864; Thu
 18-Sep-86 10:34:54 EDT
Date: Thu, 18 Sep 86 10:33 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposed Goals (Statement for OOPSLA)
To: Bobrow.pa@Xerox.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860917-113216-7821@Xerox>
Message-ID: <860918103320.8.SKEENE@JUNCO.SCRC.Symbolics.COM>
Line-fold: No

    Date: 17 Sep 86 11:33 PDT
    From: Bobrow.pa@Xerox.COM

    Dick edited Sonya's version, then Danny and Gregor edited his to produce
    this.

Thanks for your quick response on this.   I've revised the text of this
statement to include your changes (except for one paragraph), and I also
corrected a few typos in your version.   Anything that I changed from 
your version is enclosed in *asterisks* below.    

Moon has sent another version of the paragraph in question for you to
comment on.   It's also included here.  

    HISTORY AND MOTIVATION

    There is currently substantial experience with object-oriented
    programming paradigms within a variety of contexts. The two groups
    *have have* the most experience in this area are Symbolics and Xerox.

Only one "have"

    Flavors, an important object-oriented programming extension to Lisp,
    has been in use for more than 7 years. Over that period many valuable
    lessons
    have been learned about object-oriented programming in Lisp. In 1985,
    Symbolics took these lessons to heart and designed New Flavors, which
    is a compatible extension to Flavors.

    Xerox has had more than 10 years of experience with object-oriented
    programming, both within the Lisp tradition and within the Smalltalk
    tradition.  Over that period many lessons were learned, and in 1985
    Xerox
    began to design a new object-oriented programming extension to Common
    Lisp, called CommonLoops.

    In mid-1985 these two groups became aware of each other.  These 
    two object-oriented extensions to Lisp had important similarities.
    CommonLoops evolved to include some of the ideas in *new Flavors*.

Capitalize "New Flavors". 

    Many people in the Common Lisp community now see a need for defining a
    standard for object-oriented programming that would be part of Common
    Lisp.  The primary benefit of such a standard would be the ability to
    write portable Common Lisp code in an object-oriented style.

    At the Common Lisp committee meeting in Boston in December 1985, many
    vendors of application software made it clear how important such a
    standard is to them.  Again at the ACM Conference on Lisp and Functional
    Programming in Cambridge in August 1986, the same point was made.

    After the ACM Conference there was a meeting of the Common Lisp
    Object-oriented Programming Committee.  A clear consensus was reached
    that
    work should begin immediately to define a standard.  Representatives
    from Xerox, Lucid, Symbolics, LMI, HP, Sun, and the Japanese CommonLisp
    committee supported this consensus.

    A working group composed of representatives from Xerox and Symbolics met
    after the ACM Conference; at the meeting this working group reached
    agreement on several general goals.

    *In brief, the standard will be based on the meta-object framework of
    CommonLoops, which allows experimentation with different philosophies of
    object-oriented programming.  Additional features from new Flavors will
    be added to CommonLoops to flesh out the programmer interface; in
    particular, a declarative method combination facility patterned after
    that in new Flavors has been added to CommonLoops to create an extension
    to Common Lisp that represents the best features of both systems.*

We prefer the paragraph below, because it makes it clear that the new
thing isn't CommonLoops:   

"In brief, the standard will be based on the meta-object framework of
CommonLoops, which allows experimentation with different philosophies of
object-oriented programming.  The programmer interface on top of this
framework will combine the most useful features of CommonLoops and New
Flavors, such as multimethods from CommonLoops and declarative method
combination from Flavors.  The standard will be an extension to Common
Lisp that incorporates the best features of both systems." 

    PROGRESS IN AUGUST AND SEPTEMBER

    During August and September, representatives from Xerox, Symbolics, and
    Lucid began work on a draft specification of the standard.  This working
    group started with the basic programmer interface for defining new
    classes
    and writing methods and generic functions.  *This work is ongoing, but a
    draft of the programmer interface is available - the meta-object
    protocol specification will be available soon.*

Let's make that two complete sentences:   "This work is ongoing, but a
draft of the programmer interface is available.   The meta-object
protocol specification will be available soon."


    GOALS FOR THE STANDARD

    Some high-level goals were stated and agreed-upon:

    Sound basis     The standard will include the aspects of object-oriented
		    programming that are well-understood at this time.  The
		    standard will omit ideas that are still subjects for
		    research.

    Flexibility     The meta-object protocol of the standard will offer a
		    flexible framework for other designers to implement
		    different schemes.  This encourages exploration of
		    different styles of object-oriented programming.

    Power           The standard will offer the basic tools for writing
		    programs in an object-oriented style, and will be
    powerful
		    enough that it meets the needs of most programs.  It
    should
		    not be necessary for programmers to extend the system to
    do
		    straightforward object-oriented programming.

    Simplicity      The standard will specify just the language, not the
		    programming tools and interactive development
    environment.

    Compatibility   It should be a convenient and simple procedure to
    translate
		    programs written in CommonLoops or New Flavors to the
    new
		    standard.  We intend to provide tools that will perform
    the
		    translation automatically.

    Implementation  The standard will allow efficient implementation on
    stock
		    hardware as well as specialized machines.
                                                                        
    FEATURES TO BE INCLUDED IN THE STANDARD

    The following features *wil be* included in the standard..  This is not an

"will be"

    exhaustive list, but is intended to communicate some of the areas of
    agreement that have been reached.

    Generic functions
		    The standard will use the normal Lisp function-calling
		    syntax.

    Class and Type Space Merging
		    Every object in the Lisp system has a class and hence
    can
		    be used to select methods.

    Dispatching     The standard will allow dispatching on the class of one
		    (classical methods) or more (multi-methods) arguments.

    Multiple inheritance
		    Classes can be combined together freely; they
		    need not fit into a rigid hierarchy.

    Meta-objects    The standard defines objects for the major
    implementation
		    entities of the system to allow for extensibility.
		    Classes, methods, and generic functions all have
		    corresponding objects, organized by well-defined,
		    documented protocols.

    Declarative Method Combination
		    Method selection and combination can be controlled
		    declaratively.  Users can define new
		    method combination paradigms.

    FUTURE PLANS

    The working group is developing a draft specification for the
    standard.  The specification process will involve the community in the
    feedback process.

    *Portable Common Loops will evolve to to track the new specification.
    This portable implementation will enable the community to experiment
    with and
    gain a deeper understanding of the ideas than is possible with only a
    specification.*

A. Only one "to". 

B. I prefer my original text "We wil produce a portable implementation
by evolving Portable Common Loops..." instead of your "Portable Common
Loops will evolve..."   PCL isn't going to evolve spontaneously.  
How about saying "Xerox will update Portable Common Loops to track the
new specification?" 

C. Let's recast that last sentence to take the distracting clause out of the
middle. 

That paragraph turns into: 

"Xerox will update Portable Common Loops to track the new specification.
By experimenting with the portable implementation, the community can
gain a deeper understanding of the ideas than would be possible by
reading the specification alone."



  


/sub
"commonloopscore↑.pa"@xerox
Proposed Goals (Statement for OOPSLA)

Sonya's improvements are generally good. I changed her original
sentence

``We will produce a portable implementation by evolving Portable
Common Loops...''

because it can parse in a funny way if you use a slightly less primary
definition of `evolve' than `to exhibit or produce through evolution.'
The definition is `to emit' as in `to evolve gases.'  I parsed it as
it would appear in this sentence:

``Danny Bobrow ate a large plate of refried beans last night, went
back to PARC, and accidentally evolved Portable Common Loops.  He
apologized profusely for his bad manners.''

Your rephrasing is better than mine, but it does commit Xerox to doing
the work of updating PCL, which they may elect not to do.

One reason for the phrasing of the pedigree paragraph is to emphasize
that the influence of New Flavors on CommonLoops has been going on for
over a year, and that the proposed standard will be more nearly along
the line of evolution, if you will, of CommonLoops as influenced by
New Flavors than a fresh merging of the two systems off the lines of
either.  That is, the proposed standard will not be especially like
the CommonLoops of a year ago, but it will be very much like the
CommonLoops of today, because a movement towards New Flavors has
already taken place.

The reason for wanting to reason this way is to give the community
some sense of continuity over the past year. People will possibly rest
more comfortably if they believe that the ideas have developed over a
year's time rather than over a month's time.

The proposed standard will be what it will be, and its pedigree will
be of interest only to historians, and those historians will be able
to see the family lines accurately.

			-rpg-

∂18-Sep-86  0900	Bobrow.pa@Xerox.COM 	Re: The name of WITH    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86  08:59:51 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 18 SEP 86 08:26:50 PDT
Date: 18 Sep 86 08:28 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: The name of WITH
In-reply-to: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Thu, 18 Sep 86 08:17 EDT
To: skeene@STONY-BROOK.SCRC.Symbolics.COM
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860918-082650-8617@Xerox>

     Does WITH-SLOTS only give you variables for each slot, or does it
     also give you a "SELF" variable for the object itself?    If it
also
     provides  a variable for the object, maybe WITH-INSTANCE would be a
     better name. 

In the standard syntax for methods, there is no special name self.  The
user chooses the name for an object.  WITH-SLOTS allows you access slots
using a variable name.  For example,

(defclass point () ((x 0) (y 0)) (accessors-with-prefix point-))

(defmethod move ((p point) dx dy)
  (with-slots (p)  ;; p is known to be a point from the method-signature
     (setq x (+ x dx) y (+ y dy))))

In this example, p could have been used to refer to the point itself.
 (+ x dx) expands to 
 (+ (point-x p) dx) etc.

Using %with-slots

(%with-slots (p) (setq x (+ x dx) y (+ y dy)))) 

 (+ x dx) expands to 
 (+ (get-slot p x) dx)


The syntax of with-slots is:

(with-slots ({var-name|(var-name var-prefix [class-name]}*) . body)

In the simple case, where only a var-name is used, it is assumed that
the class of the named variable can be determined from the method
signature.  Slot-names from the class can be used to access slots of the
object bound to var-name.  This is illustrated above.

If two or more var-names are given, then they must have disjoint sets of
names for slots  to avoid ambiguity of reference. (but see var-prefix
below). In such a case an error is signalled.

If var-prefix is provided, then references to any slot <slot1> can be
made using the symbol (concat var-prefix <slot1>).  This allows easy
reference to two objects of the same class.  For example,

(defmethod make-same-height ((p1 point) (p2 point))
;;; set the y coord of p1 to the y of p2, its reference.
;;; slots of p1 are accessed using the slot names
;;; slots of p2 are accessed using ref-<slot-name>
   (with-slots (p1 (p2 ref-)) (setq y ref-y)))

Under some circumstances, the class of an object will not be computable
from the method signature, but can be specified by the user.

For example, 
  (defmethod make-horizontal ((l line))
     (let((left (left-point l)) (right (right-point l)))
       (with-slots ((left left- point)(right right- point))
          (setq left-y right-y))))

These last examples are silly in that one would not go to this trouble
to reference a single variable.  But with-slots is very convenient if
you want to do many references.

The scope of these names is lexical (as is obvious from their
trranslation).

%with-slots is identical to with, except that 
with-slots expands slot references to access functions and
%with-slots expands slot references to direct accesses
  


-- danny

∂18-Sep-86  0900	Bobrow.pa@Xerox.COM 	Re: DEFCLASS should replace DEFSTRUCT  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86  08:59:59 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 18 SEP 86 08:36:41 PDT
Date: 18 Sep 86 08:38 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: DEFCLASS should replace DEFSTRUCT
In-reply-to: Masinter.pa's message of 17 Sep 86 19:50 PDT
To: Masinter.pa@Xerox.COM
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860918-083641-8627@Xerox>

     I think that the reason that CommonLoops was originally acceptable
     to a large class of people was that it did not add substantially to
     the complexity of the Language. The acceptability of CommonLoops
     partially on that principle, and any movement away from it
     risks losing it.
I think simplifying Common Lisp is an admirable goal, and when this
standard is agreed on, I think the Common Lips community can take on
itself the task of redefining old features on top of the new.  Not only
do I think that defstruct should go away, but the sequence functions
should be made methods, errors should use objects, the type system
should be described in terms of predications, classes, etc.  This
layering of Common Lisp would make a lot cleaner language.  Let us put
these items on our agenda.

BUT we have not yet got an object standard!!!!  We should keep those
goals in the back of our mind, and try to enable such folding.  The job
in front of us at the moment is to ensure we have a useful object
standard. 


-- danny

∂18-Sep-86  1100	Owners-commonloopscore↑.pa@Xerox.COM 	DEFCLASS should replace DEFSTRUCT    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86  10:59:08 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 18 SEP 86 10:16:46 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 18 SEP 86
 10:16:32 PDT
Date: 18 Sep 86 10:16 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: DEFCLASS should replace DEFSTRUCT 
To: commonloopscore↑.pa@Xerox.COM 
Message-ID: <860918-101646-8740@Xerox>


I bow to those who use mailers that sort mail according to subject:
My message is responsive to the discussion which has gone on under
this subject line, but the contents of my remarks and of the remarks
to which I reply bear no semantic relationship to the subject line.

There indeed was a simplicity in the early CommonLoops proposal, but the
simplicity was the simplicity of a naive proposal. In particular, the
use of Defmethod as a vague replacement for Defun to create a cloud of
functions that are invoked variously misses the goal of a clearly understood
construct. What precisely is the contract between this cloud and the outside
world? How does this cloud relate to Lisp functions? If you can FUNCALL this
cloud, can you affect it by affecting the thing that sits in the symbol-function
cell of a symbol? Simply stated, is the cloud a first-class object, or is it
like the heap?

The `negotiating' group is doing more than negotiating: It is attempting to
bring some design sense into the picture. The early CommonLoops proposal
was more like a slogan than a well-designed system.

			-rpg-

∂18-Sep-86  1100	Owners-commonloopscore↑.pa@Xerox.COM 	Proposed Goals (Statement for OOPSLA)     
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86  10:59:02 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 18 SEP 86 10:02:49 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 18 SEP 86
 10:02:32 PDT
Date: 18 Sep 86 10:01 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Proposed Goals (Statement for OOPSLA)  
To: commonloopscore↑.pa@Xerox.COM 
Message-ID: <860918-100249-8718@Xerox>


Sonya's improvements are generally good. I changed her original
sentence

``We will produce a portable implementation by evolving Portable
Common Loops...''

because it can parse in a funny way if you use a slightly less primary
definition of `evolve' than `to exhibit or produce through evolution.'
The definition is `to emit' as in `to evolve gases.'  I parsed it as
it would appear in this sentence:

``Danny Bobrow ate a large plate of refried beans last night, went
back to PARC, and accidentally evolved Portable Common Loops.  He
apologized profusely for his bad manners.''

Your rephrasing is better than mine, but it does commit Xerox to doing
the work of updating PCL, which they may elect not to do.

One reason for the phrasing of the pedigree paragraph is to emphasize
that the influence of New Flavors on CommonLoops has been going on for
over a year, and that the proposed standard will be more nearly along
the line of evolution, if you will, of CommonLoops as influenced by
New Flavors than a fresh merging of the two systems off the lines of
either.  That is, the proposed standard will not be especially like
the CommonLoops of a year ago, but it will be very much like the
CommonLoops of today, because a movement towards New Flavors has
already taken place.

The reason for wanting to reason this way is to give the community
some sense of continuity over the past year. People will possibly rest
more comfortably if they believe that the ideas have developed over a
year's time rather than over a month's time.

The proposed standard will be what it will be, and its pedigree will
be of interest only to historians, and those historians will be able
to see the family lines accurately.

			-rpg-

∂18-Sep-86  1100	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: The name of WITH  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86  10:59:16 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 18 SEP 86 10:57:33 PDT
Return-Path: <skeene@ALDERAAN.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from ALDERAAN.SCRC.Symbolics.COM ([192.10.41.109]) by
 Xerox.COM ; 18 SEP 86 10:57:06 PDT
Received: from JUNCO.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM
 via CHAOS with CHAOS-MAIL id 5379; Thu 18-Sep-86 13:52:29 EDT
Date: Thu, 18 Sep 86 13:51 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: The name of WITH
To: Bobrow.pa@Xerox.COM
cc: skeene@STONY-BROOK.SCRC.Symbolics.COM,
 Moon@STONY-BROOK.SCRC.Symbolics.COM, CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860918-082650-8617@Xerox>
Message-ID: <860918135152.0.SKEENE@JUNCO.SCRC.Symbolics.COM>
Line-fold: No

    Date: 18 Sep 86 08:28 PDT
    From: Bobrow.pa@Xerox.COM

Thanks for the information on WITH-SLOTS.   I have two questions. 
 
	 Does WITH-SLOTS only give you variables for each slot, or does it
	 also give you a "SELF" variable for the object itself?    If it
    also
	 provides  a variable for the object, maybe WITH-INSTANCE would be a
	 better name. 

    In the standard syntax for methods, there is no special name self.  The
    user chooses the name for an object.  WITH-SLOTS allows you access slots
    using a variable name.  For example,

    (defclass point () ((x 0) (y 0)) (accessors-with-prefix point-))

If the class of point had been defined without specifying the
:accessors-with-prefix option, what happens when you define (or run?)
the method below?

    (defmethod move ((p point) dx dy)
      (with-slots (p)  ;; p is known to be a point from the method-signature
	 (setq x (+ x dx) y (+ y dy))))

    In this example, p could have been used to refer to the point itself.
     (+ x dx) expands to 
     (+ (point-x p) dx) etc.

    Using %with-slots

    (%with-slots (p) (setq x (+ x dx) y (+ y dy)))) 

     (+ x dx) expands to 
     (+ (get-slot p x) dx)

[text deleted here on syntax of WITH-SLOTS]  

    %with-slots is identical to with, except that 
    with-slots expands slot references to access functions and
    %with-slots expands slot references to direct accesses


So, I guess the idea is this:  You would use %WITH-SLOTS if you really
wanted full access to the slots whether or not they were declared to be
accessible in the DEFCLASS.    You would use WITH-SLOTS if you wanted
the system to prevent you from accessing a slot that was not declared
accessible in the DEFCLASS.   Another reason to use WITH-SLOTS is to 
ensure that the accessor generic function is run -- which might include
some :before or :after methods.  



∂18-Sep-86  1306	Owners-CommonLoopsCore↑.pa@Xerox.COM 	WITH-SLOTS  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86  13:06:10 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 18 SEP 86 11:02:27 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 18 SEP 86 11:02:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 107073; Thu
 18-Sep-86 13:58:43 EDT
Date: Thu, 18 Sep 86 13:58 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: WITH-SLOTS
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860918-082650-8617@Xerox>
Message-ID: <860918135841.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 18 Sep 86 08:28 PDT
    From: Bobrow.pa@Xerox.COM

    WITH-SLOTS allows you access slots using a variable name.  For example...

    The syntax of with-slots is:

    (with-slots ({var-name|(var-name var-prefix [class-name]}*) . body)

It's nice to see a concrete specification of something.  I have some
syntactic suggestions: I think it would be clearer to use keyword arguments
rather than a mixture of positional arguments and multiple operator names.
I would suggest these three keywords:
  :class class-name -- the class, or a super class, of the instance.
  :prefix string -- prefixed to the slot names (can be a symbol or a string).
  :direct boolean -- t means access slots directly, nil means call the
	accessor functions, which might invoke methods.

Thus the syntax would become

  (with-slots ({var-name|(var-name &key class prefix direct) . body)

and your examples would become

  (defclass point () ((x 0) (y 0)) (:accessors-with-prefix point-))

  (defmethod move ((p point) dx dy)
    (with-slots (p)  ;; p is known to be a point from the method-signature
       (setq x (+ x dx) y (+ y dy))))

  (with-slots ((p :direct t)) (setq x (+ x dx) y (+ y dy)))) 

  (defmethod make-same-height ((p1 point) (p2 point))
  ;;; set the y coord of p1 to the y of p2, its reference.
  ;;; slots of p1 are accessed using the slot names
  ;;; slots of p2 are accessed using ref-<slot-name>
     (with-slots (p1 (p2 :prefix ref-)) (setq y ref-y)))

  (defmethod make-horizontal ((l line))
     (let ((left (left-point l)) (right (right-point l)))
       (with-slots ((left  :class point :prefix left-)
		    (right :class point :prefix right-))
	 (setq left-y right-y))))

∂18-Sep-86  1306	Owners-CommonLoops.pa@Xerox.COM 	common loops for franz
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86  13:06:52 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 18 SEP 86 11:41:26 PDT
Return-Path: <frodo@faraday.ECE.CMU.EDU>
Received: from faraday.ECE.CMU.EDU by Xerox.COM ; 18 SEP 86 11:36:26 PDT
Received: by faraday.ECE.CMU.EDU (4.12/4.7)
 	id <AA04222 frodo>; Thu, 18 Sep 86 14:24:16 edt;
Date: Thu, 18 Sep 86 14:24:16 edt
From: Ted Kowalski <frodo@faraday.ECE.CMU.EDU>
Message-Id: <8609181824.AA04222@faraday.ECE.CMU.EDU>
To: CommonLoops.pa@Xerox.COM
Subject: common loops for franz
Cc: Gregor.pa@Xerox.COM

the readme.tx file mentions a excl, but I didn't find one in /pub/pcl
does it exist?
thanks

∂18-Sep-86  1724	RPG   	Proposed Goals (Statement for OOPSLA)      
 ∂18-Sep-86  1100	Owners-commonloopscore↑.pa@Xerox.COM 	Proposed Goals (Statement for OOPSLA)     
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86  10:59:02 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 18 SEP 86 10:02:49 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 18 SEP 86
 10:02:32 PDT
Date: 18 Sep 86 10:01 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Proposed Goals (Statement for OOPSLA)  
To: commonloopscore↑.pa@Xerox.COM 
Message-ID: <860918-100249-8718@Xerox>


Sonya's improvements are generally good. I changed her original
sentence

``We will produce a portable implementation by evolving Portable
Common Loops...''

because it can parse in a funny way if you use a slightly less primary
definition of `evolve' than `to exhibit or produce through evolution.'
The definition is `to emit' as in `to evolve gases.'  I parsed it as
it would appear in this sentence:

``Danny Bobrow ate a large plate of refried beans last night, went
back to PARC, and accidentally evolved Portable Common Loops.  He
apologized profusely for his bad manners.''

Your rephrasing is better than mine, but it does commit Xerox to doing
the work of updating PCL, which they may elect not to do.

One reason for the phrasing of the pedigree paragraph is to emphasize
that the influence of New Flavors on CommonLoops has been going on for
over a year, and that the proposed standard will be more nearly along
the line of evolution, if you will, of CommonLoops as influenced by
New Flavors than a fresh merging of the two systems off the lines of
either.  That is, the proposed standard will not be especially like
the CommonLoops of a year ago, but it will be very much like the
CommonLoops of today, because a movement towards New Flavors has
already taken place.

The reason for wanting to reason this way is to give the community
some sense of continuity over the past year. People will possibly rest
more comfortably if they believe that the ideas have developed over a
year's time rather than over a month's time.

The proposed standard will be what it will be, and its pedigree will
be of interest only to historians, and those historians will be able
to see the family lines accurately.

			-rpg-

∂18-Sep-86  1724	RPG   	DEFCLASS should replace DEFSTRUCT     
 ∂18-Sep-86  1100	Owners-commonloopscore↑.pa@Xerox.COM 	DEFCLASS should replace DEFSTRUCT    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86  10:59:08 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 18 SEP 86 10:16:46 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 18 SEP 86
 10:16:32 PDT
Date: 18 Sep 86 10:16 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: DEFCLASS should replace DEFSTRUCT 
To: commonloopscore↑.pa@Xerox.COM 
Message-ID: <860918-101646-8740@Xerox>


I bow to those who use mailers that sort mail according to subject:
My message is responsive to the discussion which has gone on under
this subject line, but the contents of my remarks and of the remarks
to which I reply bear no semantic relationship to the subject line.

There indeed was a simplicity in the early CommonLoops proposal, but the
simplicity was the simplicity of a naive proposal. In particular, the
use of Defmethod as a vague replacement for Defun to create a cloud of
functions that are invoked variously misses the goal of a clearly understood
construct. What precisely is the contract between this cloud and the outside
world? How does this cloud relate to Lisp functions? If you can FUNCALL this
cloud, can you affect it by affecting the thing that sits in the symbol-function
cell of a symbol? Simply stated, is the cloud a first-class object, or is it
like the heap?

The `negotiating' group is doing more than negotiating: It is attempting to
bring some design sense into the picture. The early CommonLoops proposal
was more like a slogan than a well-designed system.

			-rpg-

∂18-Sep-86  2312	Masinter.pa@Xerox.COM 	Re: The name of WITH  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86  23:12:08 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 18 SEP 86 13:25:33 PDT
Date: 18 Sep 86 13:23 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: The name of WITH
In-reply-to: Bobrow.pa's message of 18 Sep 86 08:28 PDT
To: Bobrow.pa@Xerox.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860918-132533-897@Xerox>

I think that under a with/with-slots/with-instances that programmers
should be encouraged (required?) to use SETF instead of SETQ to modify
slots.

(defmumble move-to ((p point) new-x new-y)
   (with-slots (p)
	(setf x new-x)
	(setf y new-y)))

even though setq will "do".


I think the "prefix" option was added as a "fix" to the possibility of
conflicting slot names, and that the cure is worse than the disease. If
there's conflict, use the accessor functions instead.
  
(defmumble move-to-point ((p point) (p2 point))
    (with-slots (p)
	(setf x (point-x p2))
	(setf y (point-y p2))))



∂18-Sep-86  2312	Owners-CommonLoops.pa@Xerox.COM 	FTP problems.    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86  23:12:21 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 18 SEP 86 13:44:38 PDT
Return-Path: <ALarson.SoftTech@HI-MULTICS.ARPA>
Received: from HI-MULTICS.ARPA by Xerox.COM ; 18 SEP 86 13:42:04 PDT
Date: Thu, 18 Sep 86 15:31 CDT
From: ALarson@HI-MULTICS.ARPA
Subject:  FTP problems.
To: CommonLoops.pa@Xerox.COM
Message-ID:  <860918203156.583664@HI-MULTICS.ARPA>

I recently attempted to FTP the PCL software from PARCVAX.xerox.com, and
had much difficulty.  Specifically the last 500-2K bytes of most of the
files were not transferred (at least not received).  The system
administration people at my site (A large Multics) say no one else has
experienced the same trouble and suggested that I find out if anyone
else trying to get the software was having difficulty.  So, did anyone
else have any trouble FTPing the code?

The following is a partial transcript of the FTP session:
The first line below is a DIR, the next two are GETs (of course the first
one worked correctly as predicted by Murphy).

Aaron.
----------------------------------------

user←ftp:   -rw-r--r--  1 270      41          10366 May 30 11:01 defsys.l

user←ftp:  150 Opening data connection for defsys.l (10.1.0.94,62250) (10366 bytes).

226 Transfer complete.

Total elapsed time:  27.6 seconds.
10366 bytes transferred in 24.4 seconds (3343 bits/sec).

user←ftp:  

user←ftp:  150 Opening data connection for defsys.l (10.1.0.94,43178) (10366 bytes).

226 Transfer complete.

Total elapsed time:  30.7 seconds.
10224 bytes transferred in 25.5 seconds (3150 bits/sec).

user←ftp:

∂18-Sep-86  2312	Masinter.pa@Xerox.COM 	Re: DEFCLASS should replace DEFSTRUCT     
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86  23:12:34 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 18 SEP 86 13:48:55 PDT
Date: 18 Sep 86 13:47 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: DEFCLASS should replace DEFSTRUCT 
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 18 Sep 86
 10:16 PDT
To: RPG@SAIL.STANFORD.EDU
cc: commonloopscore↑.pa@Xerox.COM
Message-ID: <860918-134855-900@Xerox>

Having missed the early discussions of what ambiguity lies in the
original specification, I am forced to repeat the questions and hope
that you will have the patience to repeat the replies. If it is any
consolation, I think you will have to repeat this with others who might
have liked the spec, and suggest, if you have not done so, save your
replies.

To address your particular concerns:

"In particular, the use of Defmethod as a vague replacement for Defun to
create a cloud of
functions that are invoked variously misses the goal of a clearly
understood construct. What precisely is the contract between this cloud
and the outside world? "

What precisely is the contract between an ordinary function and the
outside world? 

The specification of the behavior of a set of methods is no less defined
than the specification of what functions, macros and special forms do in
Common Lisp.

"How does this cloud relate to Lisp functions?"
It is different from any lisp function.

"If you can FUNCALL this cloud, can you affect it by affecting the thing
that sits in the symbol-function cell of a symbol? "

You cannot FUNCALL a cloud. You can FUNCALL a symbol and a function
object. A set of methods is neither. Perhaps you are asking the more
precise question:

"After (defmethod move ((x point) dx dy) ...), what does
(symbol-function 'move) return?"

I would answer that the answer belongs in the standard as much as the
question

"After (defmacro mood (x dx dy) ...), what does (symbol-function 'mood)
return?"

on which Common Lisp the Language is silent.

I think that your characterization of the early CommonLoops proposal as
"more like a slogan than a well-designed system." is incorrect, and even
more perjorative than the characterization of Common Lisp as "more like
a treaty than a specification."



∂18-Sep-86  2313	Owners-CommonLoops.pa@Xerox.COM 	Re: common loops for franz 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86  23:13:29 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 18 SEP 86 15:35:09 PDT
Return-Path: <dcmartin@ingres.Berkeley.EDU>
Received: from ingres.Berkeley.EDU ([128.32.156.105]) by Xerox.COM ; 18
 SEP 86 15:32:59 PDT
Received: by ingres.Berkeley.EDU (5.53/1.2)
 	id AA28636; Thu, 18 Sep 86 14:38:01 PDT
Message-Id: <8609182138.AA28636@ingres.Berkeley.EDU>
From: "David C. Martin" <dcmartin@ingres.Berkeley.EDU>
Office: 440 Evans - x2-9585
Home: 2441 Haste St #37, Berkeley, CA 94704 - (415) 843-6470
Fortran: is not backward, NARTROF is backwards.
To: Ted Kowalski <frodo@faraday.ece.cmu.edu>
Cc: CommonLoops.pa@Xerox.COM, Gregor.pa@Xerox.COM
Precedence: priority-mail
In-Reply-To: Your message of Thu, 18 Sep 86 14:24:16 edt
Subject: Re: common loops for franz
Date: 18 Sep 86 14:37:58 PDT (Thu)
Sender: dcmartin@ingres.Berkeley.EDU

Yeah, there should be... I am running it w/ Franz ExCl and I last updated
on 8/28 from parcvax.  If you would like, I can make it publically ftp'able
from my VAX.  We have also added the make-specializable feature to the
Franz implementation.

dcm

∂18-Sep-86  2313	Masinter.pa@Xerox.COM 	Re: FTP problems.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86  23:13:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 18 SEP 86 15:00:48 PDT
Date: 18 Sep 86 14:56 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: FTP problems.
In-reply-to: ALarson@HI-MULTICS.ARPA's message of Thu, 18 Sep 86 15:31
 CDT
To: ALarson@HI-MULTICS.ARPA
cc: CommonLoops.pa@Xerox.COM, VaxcSystem↑.pa@Xerox.COM
Message-ID: <860918-150048-907@Xerox>

parcvax has been having hiccups with a new version of Unix. I'm not sure
they've been resolved yet, will keep you posted. 

∂18-Sep-86  2313	Bobrow.pa@Xerox.COM 	Re: Proposed Goals (Statement for OOPSLA)   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86  23:12:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 18 SEP 86 14:11:59 PDT
Date: 18 Sep 86 14:13 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Proposed Goals (Statement for OOPSLA)
To: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860918-141159-904@Xerox>

In reading over these messages, I realized that what we were doing was
not describing technical goals and history, but setting up marketing
positions for corporations.  I (and Gregor) are not in any position to
negotiate statements that have that kind of implication, and this
discussion is not appropriate for this list. Instead, let's continue
discussions of the important technical issues we need to resolve.     


-- danny

∂19-Sep-86  0806	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Re: Summary of features we all agree on   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 Sep 86  08:06:27 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 19 SEP 86 08:04:35 PDT
Return-Path: <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 19 SEP 86 08:03:52 PDT
Received: from JUNCO.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 107881; Fri
 19-Sep-86 10:57:38 EDT
Date: Fri, 19 Sep 86 10:55 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Summary of features we all agree on
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860910003916.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860919105557.2.SKEENE@JUNCO.SCRC.Symbolics.COM>
Line-fold: No

    Date: Wed, 10 Sep 86 00:39 EDT
    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>

      Date: 5 Sep 86 18:49 PDT
      From: Bobrow.pa@Xerox.COM

	class-name is a non-null symbol that names the class being
	defined.  If a class is already defined with this name, this
	definition replaces the old definition.  The default
	meta-class ensures that when the definition of a class
	changes, each existing instance of the class is updated to the
	new format the next time it is accessed.
  
	 Each slot-spec is one of:
  
	  slot-name       a non-null symbol.
  
	   (slot-name initial-value-form)
  
  
	  (slot-name slot-option...)
	    Each slot-option is an option name followed by its value.
	    The defined slot-options and their arguments are:
  
	   = initial-value-form
		   This an alternate way for providing a default
		   initial value form.

    By the way I'm not wedded to the name "=".  I couldn't think of
    a clearer name when I tried for a few minutes, but perhaps
    someone else can.

The name "=" seems inappropriate here. 

How about :initial-value?   Other possibilities:  :default-value, 
:default-initial-value, :initial-contents.  

	  :accessor generic-function-name
		Specifies that a function named generic-function-name
		be automatically generated, to read the value of this
		slot.  SETF may be used with generic-function name to
		write the value of the slot.
   
      OK.  If generic-function-name is NIL then this is a NOOP.
      Specified so programs can generate these.
  
	  :reader generic-function-name
		Specifies that a function named generic-function-name
		be automatically generated, to read the value of this
		slot.
  
      We have called this :read-accessor.  

    I think users would find the distinction between :read-accessor
    and :accessor confusing.  Perhaps we need some more opinions
    here, it's a difficult judgement.

The important distinction that these names have to imply is that one
generic function can read and write, while the other can only read.

The name :read-accessor is confusing.  It implies that the generic
function is capable of both reading and accessing.

The names :accessor and :read-accessor do not go together well.  If
we are going to use :reader-accessor, the appropriate companion option
should be named :read-and-write-accessor.    That way the user
understands that :read-and-write-accessor does more than :read-accessor.  

I prefer the names :accessor and :reader because they really describe
what the generic function can do.   The one generated by :ACCESSOR has
the capability of ACCESSING (both reading and being used with SETF).
The one generated by :READER has the capability of READING.

					   We specify that if this is
      given, then SETF may NOT be used with this accessor. If
      generic-function-name is NIL then this is a NOOP.
  
    Agreed.



∂19-Sep-86  0944	Bobrow.pa@Xerox.COM 	Re: Summary of features we all agree on
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 Sep 86  09:44:08 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 SEP 86 09:37:30 PDT
Date: 19 Sep 86 09:37 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Summary of features we all agree on
In-reply-to: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Fri, 19 Sep 86 10:55 EDT
To: skeene@STONY-BROOK.SCRC.Symbolics.COM
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CommonLoopsCore↑.PA@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <860919-093730-1229@Xerox>

    The important distinction that these names have to imply is
    that one generic function can read and write, while the other can
    only read.

    The name :read-accessor is confusing.  It implies that the
    generic function is capable of both reading and accessing.

    The names :accessor and :read-accessor do not go together well.
     If we are going to use :reader-accessor, the appropriate companion
    option should be named :read-and-write-accessor.    That way the
    user understands that :read-and-write-accessor does more than
    :read-accessor.  

    I prefer the names :accessor and :reader because they really
    describe what the generic function can do.   The one generated by
    :ACCESSOR has the capability of ACCESSING (both reading and being
    used with SETF). The one generated by :READER has the capability of
    READING.


I like this choice of names, :accessor and :reader.


-- danny

∂19-Sep-86  1132	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Re: Summary of features we all agree on   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 Sep 86  11:31:55 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 19 SEP 86 10:42:24 PDT
Return-Path: <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 19 SEP 86 10:42:02 PDT
Received: from JUNCO.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 108123; Fri
 19-Sep-86 13:40:40 EDT
Date: Fri, 19 Sep 86 13:38 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Summary of features we all agree on
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, bobrow.pa@Xerox.COM
cc: CommonLoopsCore↑.PA@Xerox.COM
In-Reply-To: <860910003916.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860919133856.4.SKEENE@JUNCO.SCRC.Symbolics.COM>
Line-fold: No

    Date: Wed, 10 Sep 86 00:39 EDT
    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>

      Date: 5 Sep 86 18:49 PDT
      From: Bobrow.pa@Xerox.COM

This is from the section on DEFCLASS slot-options.

	  :allocation 
   
      :allocation can have values
       :instance (allocated in the instance),
       :class (storage allocated in the class and shared by all
	       instances),
       :dynamic (storage allocated in the instance on first use
	  (like Flavors Proplist mixin)
       :none  expect accessor methods for this to be defined for
	 this slot in this class
 
    We need to discuss which of these allocation options belong in
    the standard.  Maybe only a subset of them.

This is the last I've heard (read) of :allocation.  Maybe it's time to
start discussing the :allocation options again.  I've elaborated on
Danny's write-up above with some information from the CommonLoops paper,
and added one thing.    For :dynamic, I assume that if you initialize
the slot with a keyword argument to MAKE-INSTANCE, the slot gets
allocated right then.   True?

Also, would you clarify what you meant by:  

       :none  expect accessor methods for this to be defined for
	 this slot in this class

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

	
:allocation keyword    

    Specifies where storage is allocated for this slot.  The keyword can
    be one of these: 

    :instance     Storage is allocated in the instance itself;  each
                  instance has its separate value for this slot.  This
                  is the default.   

    :class        Storage is allocated in the class.   Thus a single
                  value for this slot is shared by all instances. 

    :dynamic      Storage is allocated in the instance at the time of
                  the first use of the slot.  If the slot is initialized
                  with a keyword argument to MAKE-INSTANCE, the slot is
                  allocated then.   If the first access is a read, then
                  storage is allocated and the default value declared
                  in the DEFCLASS, if any, is stored in the slot and
                  returned.  If the first access is a SETF, then storage
                  is allocated and the value is stored in the slot and
                  returned.  This option allows infrequently-used slots
                  to take storage only when necessary. 

    :none         No storage is to be allocated; the slot should not
                  exist in instances of this class.  This is used to
                  override inheritance of slots defined by a
                  super-class.   

∂19-Sep-86  1132	Kahn.pa@Xerox.COM 	Short names like MAKE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 Sep 86  11:32:02 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 SEP 86 10:45:24 PDT
Date: 19 Sep 86 10:37 PDT
Sender: Kahn.pa@Xerox.COM
Subject: Short names like MAKE
To: CommonLoopsCore↑.pa@Xerox.COM
cc: Kahn.pa@Xerox.COM
From: Ken Kahn <Kahn.pa@Xerox.COM>
Message-ID: <860919-104524-1315@Xerox>

I've hesitated to bring this up since it seems that everyone is happy
with the change from MAKE to MAKE-INSTANCE.  I'm not.

I think short names are appropriate when something is used frequently
enough.  I'm glad LET isn't called LET-VARIABLES, CONS isn't called
MAKE-CONS etc.  My expectation is that all user defined data structures
will be created by MAKE(-INSTANCE) and that programs frequently do
create structures.  To put it more extremely than I really believe --
The only things that programs will make will be made by MAKE or by
existing primitive type creation functions (CONS, MAKE-ARRAY...) 

I feel less strongly about WITH vs WITH-INSTANCE since I don't really
know how often people will be using it explictly.(Btw, I like Moon's
WITH keyword syntax for dealing with prefix, class etc. though I also
share Larry's concern that the cases where they will be used are rare
enough that the added complexity isn't worth it.)


----- ken

∂20-Sep-86  1132	Owners-commonloopscore↑.pa@Xerox.COM 	Short Names      
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Sep 86  11:31:59 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 20 SEP 86 10:36:38 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 20 SEP 86
 10:36:27 PDT
Date: 20 Sep 86 10:36 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Short Names   
To: commonloopscore↑.pa@Xerox.COM 
Message-ID: <860920-103638-2050@Xerox>


It is tempting to want to use short names for things that are imagined to
be used frequently. People designing an object-oriented programming
language feel that the primitives they define will be the ones frequently
used. Recall that in the overall age of Lisp, CommonLoops has hardly
any history. Moreover, because the designer of it feels that his primitives
are the right ones, perhaps a second-generation CommonLoops hacker
will feel that some different primitives are right.

In Common Lisp we decided to not use up many of the `good' names
or characters so that users could have them. Exceptions are time-honored
Lisp names, such as LET and CONS. 

If you choose a long name for MAKE-INSTANCE, then the user can
macro-ify it to a short name. If you choose a short, nice name
like MAKE, no one else can use it. That is, the long name is
the safe choice.

Also, do you suppose that your choice of the meaning of an
English word like MAKE for a technical operation is better than
what a real programmer would want to choose as the meaning?

I strongly object to using names that are likely to be of use to
programmers to name operations that are meaningful in his application.

			-rpg-

∂21-Sep-86  1230	masinter.PA@Xerox.COM 	mutable vs immutable generic functions    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86  12:30:09 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 12:27:06 PDT
From: masinter.PA@Xerox.COM
Date: 21 Sep 86 12:26:49 PDT
Subject: mutable vs immutable generic functions
To: commonloopscore↑.pa@Xerox.COM, pavel.PA@Xerox.COM,
 nuyens.PA@Xerox.COM, sybalsky.PA@Xerox.COM
Message-ID: <860921-122706-1235@Xerox>

(This note came out of a design review meeting with some of the Common
Lisp implementors here. )


This is very condensed form of the arguments:

The question is: are Generic Functions mutable or immutable objects? 

Example:
(defmethod foo ((a widget)) .1.)
(setq foofn #'foo)
(defmethod foo ((a warble)) .2.)
(funcall foofn (make-warble) ...)

Mutable:

defmethod, add-method, remove-method, etc.  destructively modify the
generic function to include the new method. In the example, the funcall
will get definition .2..

Immutable:

Generic functions are still objects that can be passed around, sent to
FUNCALL, etc. However, they are immutable. add-method, remove-method
merely return a {it new} generic function with the specified method
added or removed. In the example, the funcall will get a generic
function which does *not* see the defmethod. 

defmethod merely replaces symbol-function with a new generic function.

Unspecified:

The standard doesn't say. Implementations are free to choose. It is an
error to rely upon what happens.  

Pro & Cons:

mutable vs immutable:
mutable better than immutable:
Mutable is a powerful feature. It is consistent with the current
implementation of PCL. (This is what's written in the documentation that
I have.) Mutable allows more efficient method-definition than immutable.


Immutable is better than mutable:
Mutable is too powerful a feature. It allows programs to do things they
shouldn't be able to do). Mutable is inconsistent with the use of
functions elsewhere in Common Lisp.  (A program could, when handed a
function, remove all of its methods and insert a "default
implementation" of its own choosing).

Unspecified vs specified:
spec it: Programs that depend on one behavior vs the other will be
difficult to port if left unspecified.
don't spec it: Many programs won't care, and leaving it unspecified will
allow greater implementation freedom. If we can't agree, we will have to
leave it unspecified.


∂21-Sep-86  1355	Bobrow.pa@Xerox.COM 	Syntax of DEFCLASS 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86  13:55:11 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 13:51:48 PDT
Date: 21 Sep 86 13:51 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Syntax of DEFCLASS
To: CommonLoopsCore↑.pa@Xerox.COM
cc: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <860921-135148-1298@Xerox>

In an internal design review at Xerox of the current state of the
specification, strong arguments were presented why defclass should have
a syntax parallel to that of defstruct.  These were:

1) Learnability -- Currently people know that syntax.  Simple variations
ae easier to learn than extensive ones.

2) Documentation -- Current documentation of defstruct could be used in
large part to document defclass.  This makes the book stay smaller.  It
makes all books written about Common Lisp have to say less. 

3) Elimination of defstruct from the language -- If the syntax is
similar, and the transformation from defstruct to defclass forms is
straightforward, it will be easier to argue for the removal of
defstruct.  (Creation of structures and use of :type might be replaced
by use of the :metaclass option.)
  

The major problem with using defstruct synatx for defclass seems to be
figuring out how to avoid having two conflicting sets of options
depending on the :metaclass.

In particular, the current :accessors-with-prefix defclass option is
different than the :conc-name option.  

Other, less significant options which cause problems are
:initable-slots, :initialize-only vs. :read-only and :init-keywords.


-- danny

∂21-Sep-86  1433	Owners-CommonLoopsCore↑.PA@Xerox.COM 	mutable vs immutable generic functions    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86  14:33:07 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 21 SEP 86 14:32:30 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 21 SEP 86 14:32:05 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 109234; Sun
 21-Sep-86 17:30:25 EDT
Date: Sun, 21 Sep 86 17:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: mutable vs immutable generic functions
To: CommonLoopsCore↑.PA@Xerox.COM
cc: masinter.PA@Xerox.COM, pavel.PA@Xerox.COM, nuyens.PA@Xerox.COM,
 sybalsky.PA@Xerox.COM
In-Reply-To: <860921-122706-1235@Xerox>
Message-ID: <860921172940.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 21 Sep 86 12:26:49 PDT
    From: masinter.PA@Xerox.COM

    The question is: are Generic Functions mutable or immutable objects? 

    Example:
    (defmethod foo ((a widget)) .1.)
    (setq foofn #'foo)
    (defmethod foo ((a warble)) .2.)
    (funcall foofn (make-warble) ...)

    Mutable:

    defmethod, add-method, remove-method, etc.  destructively modify the
    generic function to include the new method. In the example, the funcall
    will get definition .2..

    Immutable:

    Generic functions are still objects that can be passed around, sent to
    FUNCALL, etc. However, they are immutable. add-method, remove-method
    merely return a {it new} generic function with the specified method
    added or removed. In the example, the funcall will get a generic
    function which does *not* see the defmethod. 

    defmethod merely replaces symbol-function with a new generic function.

    Unspecified:

    The standard doesn't say. Implementations are free to choose. It is an
    error to rely upon what happens.  

    Pro & Cons:

    mutable vs immutable:
    mutable better than immutable:
    Mutable is a powerful feature. It is consistent with the current
    implementation of PCL. (This is what's written in the documentation that
    I have.) Mutable allows more efficient method-definition than immutable.

    Immutable is better than mutable:
    Mutable is too powerful a feature. It allows programs to do things they
    shouldn't be able to do). Mutable is inconsistent with the use of
    functions elsewhere in Common Lisp.  (A program could, when handed a
    function, remove all of its methods and insert a "default
    implementation" of its own choosing).

    Unspecified vs specified:
    spec it: Programs that depend on one behavior vs the other will be
    difficult to port if left unspecified.
    don't spec it: Many programs won't care, and leaving it unspecified will
    allow greater implementation freedom. If we can't agree, we will have to
    leave it unspecified.

Your arguments make sense to me, and I firmly believe that it should be
unspecified.  Here's why:

In New Flavors the interaction between doing #'foo and adding or
removing a method of foo varies depending on factors that the user might
not be able to predict easily.  This is because there are multiple
implementations of what PCL calls discriminating functions, and
depending on which implementation Flavors happens to choose the result
of #'foo might capture some or all of the current set of methods or
might be independent of the current set of methods.  I imagine that on
stock-hardware this implementation freedom would be even more important,
if high performance was a goal.  In your terminology, generic functions
in New Flavors are sometimes mutable, sometimes immutable, and sometimes
partially mutable.

This has not bothered any programmers, as far as I know, in the 9 or 10
months that New Flavors has been in use.  This shouldn't surprise us,
since ordinary functions behave similarly.  Consider these examples:

[1] (defun foo (...)
      ...
      (foo-1...))
    (defun foo-1 (...)
      ...)

[2] (defun foo (...)
      (flet ((foo-1 (...) ...))
	...
	(foo-1...)))

Suppose someone does #'foo and saves it away, and then a second someone
redefines foo-1, an internal function of foo whose existence is not known
to the first someone.  In example 1, the behavior of the saved-away foo
changes, in example 2 it stays the same, yet as far as the contract of
the function foo is concerned these two ways of implementing its
internal function are equivalent.

Depending on one's taste, one could say this shows that Common Lisp does
not have a well-defined semantics, or one could say that this is just an
example of the way that, in Lisp, copying the value of a variable
doesn't copy the object, just the reference to the object.  Either way,
I think it makes sense for generic functions to have the same freedom of
behavior when their internal subroutines are changed that ordinary
functions enjoy.

∂21-Sep-86  1529	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Syntax of DEFCLASS    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86  15:29:14 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 21 SEP 86 15:22:58 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 21 SEP 86 15:22:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 109241; Sun
 21-Sep-86 18:21:05 EDT
Date: Sun, 21 Sep 86 18:20 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Syntax of DEFCLASS
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860921-135148-1298@Xerox>
Message-ID: <860921182022.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 21 Sep 86 13:51 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

    In an internal design review at Xerox of the current state of the
    specification, strong arguments were presented why defclass should have
    a syntax parallel to that of defstruct.  These were:

I thought we had been through this already.  I'll see if I can reconstruct
the arguments that lead to the decision not to use the defstruct syntax.

    1) Learnability -- Currently people know that syntax.  Simple variations
    ae easier to learn than extensive ones.

This is true, but on the other hand the syntax of defstruct is not
consistent with the syntax of anything else.  In any case this is hardly
likely to be the part that newcomers to object-oriented programming find
the most difficult to learn.

    2) Documentation -- Current documentation of defstruct could be used in
    large part to document defclass.  This makes the book stay smaller.  It
    makes all books written about Common Lisp have to say less. 

This is true, but the percentage decrease in the description of
object-oriented programming would be quite small.

    3) Elimination of defstruct from the language -- If the syntax is
    similar, and the transformation from defstruct to defclass forms is
    straightforward, it will be easier to argue for the removal of
    defstruct.  (Creation of structures and use of :type might be replaced
    by use of the :metaclass option.)
  
This is true, but not compelling.  Defstruct could be removed from the
language regardless of whether the syntax is similar, as long as a given
defstruct form can be mechanically translated into an equivalent defclass
form.

    The major problem with using defstruct synatx for defclass seems to be
    figuring out how to avoid having two conflicting sets of options
    depending on the :metaclass.

    In particular, the current :accessors-with-prefix defclass option is
    different than the :conc-name option.  

    Other, less significant options which cause problems are
    :initable-slots, :initialize-only vs. :read-only and :init-keywords.

I don't think these are the main problems at all.  The real problem with
defstruct is that it was designed nine years ago, is not consistent with
current ideas of easy-to-understand syntax for defining forms, and is
a gross kludge.  Rather than perpetuate this wart on the language, we
ought to be replacing it with something better.  Requiring compatibility
with defstruct is requiring compatibility with the mistakes of the past,
and in my opinion would seriously impair the understandability and
usability of the object-oriented programming facility for only small
gains.  All of the arguments above are true, but I think they are much
too weak to outweigh the problems of defstruct.  Here are some specifics:

The original syntax of defstruct didn't allow for options, so they had
to be added by a kludge -- replacing the name with a list of the name
and options.  The original syntax of defstruct didn't allow for
documentation, so it had to be added by another kludge -- using a string
instead of a slot name.  Slot-options had to be added by yet a third
kludge, which requires that an initialization form be specified whether
or not it is desired in order to specify slot-options.  The format of
slot-options is not consistent with the format of regular options
(admittedly the currently proposed DEFCLASS has the same problem, and it
appears to be difficult to fix).  The format of the :INCLUDE option does
not admit straightforward extension to multiple superclasses; one kludge
or another is required to get around this.

Defstruct contains violations of abstraction or modularity; it has no
concept of a separation between the implementation of a structure (or
class) and clients of that structure or class.  For example, all slots
can be initialized to arbitrary values when constructing a structure;
this ought to be under the control of the implementation of the
structure.  Similarly, the ability of the implementation of a structure
to modify a slot is not separated from the ability of the clients to do
so.

The default values for the :CONC-NAME, :CONSTRUCTOR, :COPIER, and
:PREDICATE options are inappropriate.  (Perhaps not everyone agrees that
all of these are inappropriate, but the existence of controversy is
sufficient reason by itself to reconsider these defaults.)  If the
object-oriented facility is an extension of DEFSTRUCT, it would be
forced to make the same inappropriate choices for the sake of
compatibility.

Given all of these problems, a clean break with the past is a better
choice than trying to maintain compatibility with a kludge.  Of course
defstruct cannot be removed immediately, because one does not make
sudden incompatible changes to a language that thousands of people are
using, but the long-term plan should be to phase out defstruct once
a replacement has been accepted as a standard.

∂21-Sep-86  1537	MASINTER.PA@Xerox.COM 	(change-class x y) => (setf (class-of x) y)?   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86  15:37:30 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 15:35:27 PDT
From: MASINTER.PA@Xerox.COM
Date: 21 Sep 86 15:34:29 PDT
Subject: (change-class x y) => (setf (class-of x) y)?
To: commonloopscore↑.PA@Xerox.COM
cc: nuyens.PA@Xerox.COM, sybalsky.PA@Xerox.COM, pavel.PA@Xerox.COM
Message-ID: <860921-153527-1339@Xerox>

There doesn't seem to be any apparent reason to make change-class a
separate "thing", rather than a notation that class-of is setf-able for
some kinds of objects.

Opinions?

∂21-Sep-86  1540	Bobrow.pa@Xerox.COM 	Generic Function Objects
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86  15:39:59 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 15:39:30 PDT
Date: 21 Sep 86 15:39 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Generic Function Objects
To: CommonLoopsCore↑.pa@Xerox.COM
cc: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Message-ID: <860921-153930-1345@Xerox>


In the existing CommonLoops papers and code, there is an object called
the discriminator and piece of code called the discriminating function.
The discriminating function was stored inside the discriminator, and
when the discriminator was "named", was also stored in the
symbol-function cell of the symbol which named the discriminator.  The
discriminating-function was the thing you funcalled, the discriminator
was the thing that you passed to add-method.

A potentially better design combines the discriminator and the
discriminating function into a single, closure-like, object called the
generic function.  The generic function is funcallable; funcalling it
causes method lookup to happen.  Accessors which used to work on the
discriminator work directly on the generic function.  In particular,
generic-function-methods returns a list of all the methods defined on a
generic function. 

Generic functions are mutable, and are side-effected by add-method and
remove-method. An alternative proposal makes them immutable, add-method
and remove-method return new generic-functions, see Masinter's message
of 21-Sep-86 12:26:49 PDT.

We spent a fair amount of time discussing the implementation
implications of this.  We believe that this does not cause serious
implementation problems.  At least the mutable case can even be
implemented fairly efficiently in PCL.

This new scheme has not yet been discussed on this list though.  This
message is intended to spark that discussion.


-- danny, Gregor

∂21-Sep-86  1553	MASINTER.PA@Xerox.COM 	make vs make-instance 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86  15:53:15 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 15:51:01 PDT
From: MASINTER.PA@Xerox.COM
Date: 21 Sep 86 15:50:46 PDT
Subject: make vs make-instance
To: commonLoopsCore↑.PA@Xerox.COM
Message-ID: <860921-155101-1347@Xerox>

The CommonLoops paper used only two short names, viz "make" and "with". 

"make" was chosen, not so much because it is frequently typed and thus
needs to be short, but rather in conformance with the Common Lisp style
in defstruct, namely that

(make-ship :a 3 :b 17)

seemed like a simple step away from

(make 'ship :a 3 :b 17)

and is further away from

(make-instance 'ship :a 3 :b 17).

If it is any help, make-instance is also incompatible with having a
structure named "instance", which seems as likely to me at the moment as
the user having a function or macro named "make".

∂21-Sep-86  1615	Bobrow.pa@Xerox.COM 	Re: (change-class x y) => (setf (class-of x) y)? 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86  16:08:24 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 16:05:03 PDT
Date: 21 Sep 86 16:03 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: (change-class x y) => (setf (class-of x) y)?
In-reply-to: MASINTER.PA's message of 21-Sep-86 15:34:29 PDT
To: MASINTER.PA@Xerox.COM
cc: commonloopscore↑.PA@Xerox.COM, nuyens.PA@Xerox.COM,
 sybalsky.PA@Xerox.COM, pavel.PA@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <860921-160503-1357@Xerox>

    (change-class x y) => (setf (class-of x) y)?
    There doesn't seem to be any apparent reason to make
    change-class a separate "thing", rather than a notation that
    class-of is setf-able for some kinds of objects.


change-class is a sufficiently serious operation that having a separate
name is important.  It does significantly more than simply set a field,
so (setf (class-of x) y) would be misleading to a user.


-- danny

∂21-Sep-86  1638	Kahn.pa@Xerox.COM 	Re: Short Names      
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86  16:38:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 16:34:16 PDT
Date: 21 Sep 86 16:34 PDT
Sender: Kahn.pa@Xerox.COM
Subject: Re: Short Names   
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 20 Sep 86
 10:36 PDT
To: RPG@SAIL.STANFORD.EDU
cc: commonloopscore↑.pa@Xerox.COM
From: Ken Kahn <Kahn.pa@Xerox.COM>
Message-ID: <860921-163416-1364@Xerox>

    In Common Lisp we decided to not use up many of the `good' names
    or characters so that users could have them. Exceptions are
    time-honored Lisp names, such as LET and CONS.


Skimming the index of the Silver book reveals the following short names
which to my knowledge were not "time-honored Lisp names":

bit, block, byte, close, character, complex, count, describe, elt,
every, export, find, import, keyword, loop, merge, ...

----- ken

∂21-Sep-86  1717	Kahn.pa@Xerox.COM 	Re: (change-class x y) => (setf (class-of x) y)?   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86  17:17:03 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 17:15:50 PDT
Date: 21 Sep 86 17:15 PDT
Sender: Kahn.pa@Xerox.COM
Subject: Re: (change-class x y) => (setf (class-of x) y)?
In-reply-to: Danny Bobrow <Bobrow.pa>'s message of 21 Sep 86 16:03 PDT
To: Bobrow.pa@Xerox.COM
cc: MASINTER.PA@Xerox.COM, commonloopscore↑.PA@Xerox.COM,
 nuyens.PA@Xerox.COM, sybalsky.PA@Xerox.COM, pavel.PA@Xerox.COM
From: Ken Kahn <Kahn.pa@Xerox.COM>
Message-ID: <860921-171550-1381@Xerox>

I like Larry's suggestion for the same reasons that most people like
SETF -- fewer names to deal with.

    change-class is a sufficiently serious operation that having a
    separate name is important.  It does significantly more than simply
    set a field, so (setf (class-of x) y) would be misleading to a
    user.

Its true that the implementation would do "significantly more than
simply set a field" but I fail to see why that misleads the user.
Consider in Common Lisp (SETF (MACRO-FUNCTION ...) ...) which in some
implementations causes a macro expansion cache to become invalidated
causing some hash tables to be cleared.  How is the user "mislead" here?
Do you mean that in the two cases the user is likely to have a mistaken
performance model by using SETF?   But (SETF (GET-SLOT ...) ..)
may cause arbitrary computation too.

----- ken

∂21-Sep-86  1725	Kahn.pa@Xerox.COM 	Re: default optional arguments to a generic function    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86  17:25:08 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 17:23:57 PDT
Date: 21 Sep 86 17:23 PDT
Sender: Kahn.pa@Xerox.COM
Subject: Re: default optional arguments to a generic function
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Wed, 17 Sep 86 16:15 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
From: Ken Kahn <Kahn.pa@Xerox.COM>
Message-ID: <860921-172357-1384@Xerox>


    (defun draw (thing &optional (place *draw-window*
    place-supplied-p))
      "Draw thing on place."
      (draw-internal thing place place-supplied-p))
        
    (defmethod draw-internal ((thing line) (place raster-display)
    place-supplied-p) ...)
        
    (defmethod draw-internal ((thing line) (place vector-display)
    place-supplied-p) ...)
    
    Flavors provides the feature that you don't have to make
    up the auxiliary name draw-internal, which is confusing because
    the externally visible interface is named draw but you put methods
    on draw-internal.  You do this by (translating out of the present
    Flavors syntax, which is too biased against multimethods):
    
    (defgeneric draw (thing &optional (place *draw-window*
    place-supplied-p))
      "Draw thing on place."
      (:method-arguments thing place place-supplied-p)
      (:function
        (funcall (generic draw) thing place place-supplied-p)))
        
    (defmethod draw ((thing line) (place raster-display)
    place-supplied-p) ...)
        
    (defmethod draw ((thing line) (place vector-display)
    place-supplied-p) ...)

I liked your proposal until I started to imagine myself writing DRAW
methods and having to keep in my head that someone can call DRAW with 1
or 2 arguments but my methods have 3 required arguments.  I find this
less confusing than the alternative of using DRAW-INTERNAL where "the
externally visible interface is named draw but you put methods on
draw-internal".



----- ken

∂21-Sep-86  1812	Bobrow.pa@Xerox.COM 	default optional arguments to a generic function 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86  18:12:35 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 18:06:17 PDT
Date: 21 Sep 86 18:06 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: default optional arguments to a generic function
To: CommonLoopsCore↑.pa@Xerox.COM
cc: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <860921-180617-1396@Xerox>

The following principles seem to be ones we have agreed to with respect
to generic functions and methods.

1) Methods should be able to take any Common Lisp lambda-list.  In
particular the default defmethod must be able to look like a defun.

2) defgeneric should be optional, unless special options are used, such
as :generic-function-class.

3) The contract of the generic function should be true for all methods,
and that contract should be computable from a defmethod form.

This seems to lead to two competing proposals (Gregor says I am
oversimplifying)

Proposal a) The generic function specifies the full argument list, and
all methods must have congruent argument lists.  This leads to the
problem of defining congruence (Moon proposed some rules, but as
Masinter pointed out, they had a problem with renaming of variables used
in default value forms).  It also leads to redundancy in the methods --
making it difficult to change a default value form in a single place.
However, Gregor favors this scheme as later extendible by removing
restrictions.  He would allow methods to take extra keywrod args if
&allow-other-keys appears in the defgeneric.

Proposal b) The generic function specifies only the required arguments,
and methods discriminate only on those arguments.  However, methods can
have arbitrary argument list beyond the required  arguments.  From any
method, the generic contract can be computed.  All methods must have the
same number of min-args.

This allows cases 1a) and 1b)

    Case 1a.  "draw-line"

        draw-line takes an optional, the width of the line in
        device dependent units.  Because they are device dependent
        units, each individual method would like to default this
        argument on its own.

        (defmethod draw-line ((dev printer) p1 p2
                                 &optional (width 7)) ...)

        (defmethod draw-line ((dev window) p1 p2
                                 &optional (width 1)) ...)

        Case 1b.

        Within case 1, some methods may want to take an extra
        argument.  Also see case 3 which is similar.

        (defmethod draw-line ((d gray-display) p1 p2
                                 &optional (width 3) 
  						            (gray *gray1*))

      ..)

    Date: Wed, 17 Sep 86 16:15 EDT
    From: David A. Moon 
    The problem here is that the generic function doesn't have a
    consistent contract.  The meaning, or even the existence, of one
    argument depends on the class of another argument.  I don't see how
    a caller of draw-line could operate without knowing the exact
    method that was going to be called. From experience I know it's
    possible to have all sorts of arguments about whether this is good
    or bad programming practice.  In New Flavors, these arguments were
    resolved in favor of consistency of contracts, rather than the
    increased flexibility of different contracts for different methods,
    but not everyone was happy. 


I think it is possible to know that a method is coming from a particular
part of the class lattice (without knowing the exact method) and  hence
know the local contract.  Consistency of generic contract is only in the
required argument set.

To take care of GFD#2, I propose that we allow the generic to specify
optionals that it fills in.  The contract between the generic and the
methods is to always supply these required method arguments.  I claim it
should not be part of the contract between the generic and the method to
provide that information.  I propose a lambda list keyword option
&generic-optional in the generic function.  Optional argument
specifications after this provide only argument names and default value
forms, but cannot have a supplied-p variable. 

For example:
(defgeneric draw (thing &generic-optional (place *draw-window*))
            "Draw thing on place.") 

(defmethod draw ((thing line) (place raster-display)) ...)
    
(defmethod draw ((thing line) (place vector-display)) ...)
 
Methods must have required arguments where generic-optionals are
provided.  Optionals in methods cannot be discriminated on.

Case 3 "move" is outlawed by this proposal, because the number of
required arguments differ.

∂21-Sep-86  1925	Bobrow.pa@Xerox.COM 	Class Precedence List   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86  19:25:29 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 19:19:28 PDT
Date: 21 Sep 86 19:19 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Class Precedence List
To: CommonLoopsCore↑.pa@Xerox.COM
cc: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>, Kahn.pa@Xerox.COM
Message-ID: <860921-191928-1425@Xerox>

A recursive rule that computes class precedence lists locally.

1) A class c1 cannot be given any super that has c1 in its
class-precedence list.

2) If c1 has one superclass c2, then the class precedence list of c1 is
(cons c1 (c-p-l c2))

3) If c1 has two superclasses, c2 and c3, then use
  (cons c1 (merge-pls (c-p-l c2) (c-p-l c3))

where (merge-pls first second)
takes the prefix of first until it finds an element in common with
second.
If there is none, then use all of first.  Follow by the prefix of second
up to the common element. If this has any element in common with the
rest of first, signal an error.  Insert the common element.  Repeat
until first is empty, then append the rest of second.

4) If there are more than 2, then merge the pairs in an associative
manner




The claim is that this algorithm produces lists that obey all of Moon's
rules, is local and one pass.

"Proof"

A class with no super obeys Moon's rules

Proceed by induction.  

Clearly (1) Each class precedes it own supers

(2) Local ordering is preserved, since no ordering in the individual
lists is changed by the merge. And the first element of each sublist
(the local supers) have their order preserved.

(3) Duplicate elimination always puts things as early as they can go.


Several minutes thought has shown no problem with this.???

danny and ken   


∂21-Sep-86  2233	MASINTER.PA@Xerox.COM 	initial class lattice 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Sep 86  22:33:48 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 86 22:24:30 PDT
From: MASINTER.PA@Xerox.COM
Date: 21 Sep 86 22:24:10 PDT
Subject: initial class lattice
To: commonloopscore↑.PA@Xerox.COM
Message-ID: <860921-222430-1479@Xerox>

I had some questions about the initial class lattice for Common Lisp
types.

First, since Common Lisp doesn't require "compiled-function" or
"function" to be first-class, they can't be classes in the initial
hierarchy. (Recall that a compiled function is allowed to be a vector,
for example.)

Second, while "standard-char" is well defined, I don't think it should
be a class; I imagine it would otherwise be difficult to make (class-of
#\a) return something other than (class-of #\page). 

Third, I don't think that bit, fixnum and bignum should be defined to be
part of the required class lattice, because they correspond conceptually
to "range" types.

Finally, for those items that have multiple superclasses, we need to
either defince an order or else remove one of the superclasses.

I like having "list" as a class, but the precidence for NIL needs to be
defined. I'd say that NIL was a symbol first and a list second, on the
basis that "list" is an abstraction but "symbol" is quite concrete, and,
at least when I write 'em, I tend to put the concrete classes before the
abstract ones.

As for simple-vector, simple-bit-vector, simple-string, my inclination
is that "simple" isn't a particularly interesting dimension to
discriminate on; removing "simple-array" would do most of the cleanup,
and saying that a "vector" is first an array and secondly a sequence
would finish it off. 

(I'm typing this at a stupid dial-in mailer which doesn't allow me to
edit, so I'll add as an afterthought):

On further examination, there are no requirements that stream,
hash-table, readtable, package, pathname or random-state be distinct
from other types (p 33), and my belief is that these cannot then be
required to be "first class" classes, in that (class-of (make-hash-table
...)) might return the same as (class-of (make-array ...)) for suitable
arguments.

Perhaps this can be stated in the subjunctive, e.g. "if these are
distinct types in your Common Lisp implementation, they'll probably be
distinct classes in any implementation of this spec".

∂22-Sep-86  0123	MASINTER.PA@Xerox.COM 	another name for "run-super"    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86  01:22:58 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 86 01:22:36 PDT
From: MASINTER.PA@Xerox.COM
Date: 22 Sep 86 1:22:20 PDT
Subject: another name for "run-super"
To: commonloopscore↑.PA@Xerox.COM
Message-ID: <860922-012236-1523@Xerox>

names matter, I guess.

There's no "run" in Common Lisp, and no "super" in CommonLoops. How about

call-next-method. (Or, if you want, apply-next-method). 


∂22-Sep-86  0829	Owners-commonloopscore↑.PA@Xerox.COM 	another name for "run-super"    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86  08:29:42 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 SEP 86 08:19:44 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.PA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 22 SEP 86 08:19:13 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 109619; Mon
 22-Sep-86 11:17:24 EDT
Date: Mon, 22 Sep 86 11:16 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: another name for "run-super"
To: MASINTER.PA@Xerox.COM
cc: commonloopscore↑.PA@Xerox.COM
In-Reply-To: <860922-012236-1523@Xerox>
Message-ID: <860922111626.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 22 Sep 86 1:22:20 PDT
    From: MASINTER.PA@Xerox.COM

    call-next-method. (Or, if you want, apply-next-method). 

Call-next-method is a better suggestion than mine: next-method.
If we were to add an extension to allow different arguments to be
substituted when calling the next method, both call-next-method
and apply-next-method would be necessary (one is like funcall,
the other is like apply), so I think these are good names.

∂22-Sep-86  0916	Owners-commonloopscore↑.PA@Xerox.COM 	initial class lattice 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86  09:15:20 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 SEP 86 09:08:43 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.PA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 22 SEP 86 09:04:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 109670; Mon
 22-Sep-86 12:01:47 EDT
Date: Mon, 22 Sep 86 12:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: initial class lattice
To: commonloopscore↑.PA@Xerox.COM
In-Reply-To: <860921-222430-1479@Xerox>
Message-ID: <860922120053.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 21 Sep 86 22:24:10 PDT
    From: MASINTER.PA@Xerox.COM

    I had some questions about the initial class lattice for Common Lisp
    types.

I've been thinking about this also, but wasn't quite ready to mail out
my complete list yet.  I'll give some comments now, though.  In most
cases I agree with you.

    First, since Common Lisp doesn't require "compiled-function" or
    "function" to be first-class, they can't be classes in the initial
    hierarchy. (Recall that a compiled function is allowed to be a vector,
    for example.)

COMPILED-FUNCTION is allowed to inherit from VECTOR [does it say this in
CLtL someplace?], but it's still meaningful to ask "is this object a
compiled-function", so it should be meaningful to define a method that
applies if one of its arguments is a compiled-function.  On the other
hand, the definition of the FUNCTION type (CLtL p.32) is so vague that
even though there is a FUNCTIONP function, I hesitate to say that it
should be meaningful to define a method that applies if one of its
arguments is a function.  So I agree with you about FUNCTION, but
disagree on COMPILED-FUNCTION.

It is an interesting point that, although we can identify some classes
for the built-in Common Lisp types, we can't identify all the subclass
relationships among these classes, which in fact are implementation-dependent.
One could say that there are standardized subclass relationships, which
are different from the implementation-dependent subtype relationships,
but I think that approach would be confusing and cause problems.  I think
it's better for the subclass relationships to reflect reality, even when
that makes them implementation-dependent.  My intuition is that this will
not introduce any new portability problems that were not already present.

Alternatively, these built-in types could be allowed as specifiers in
methods, but not be considered classes.  After all, they already do not
participate in the full class protocol.  Built-in types are not acceptable
to MAKE-INSTANCE and are not acceptable as superclasses in DEFCLASS.
That way, there wouldn't be any issue of possible inconsistency between
SUBTYPEP and sub-class relationships.  On the other hand, this could just
be ducking the issue, since one still must ask what methods are inherited
by a given object.

Perhaps what it comes down to is: what is the CLASS-OF function good for?

Any thoughts on this?

    Second, while "standard-char" is well defined, I don't think it should
    be a class; I imagine it would otherwise be difficult to make (class-of
    #\a) return something other than (class-of #\page). 

I agree with you that STANDARD-CHAR shouldn't be a class, i.e. shouldn't
be something that can have methods defined.  My reason would be that it
is too specific, that is, it doesn't seem useful to have a different
method for STANDARD-CHAR than for CHARACTER for any generic function I
can think of.  Thus I wouldn't allow STANDARD-CHAR until I was allowing
all of the other Common Lisp type-specifiers that are really
predications rather than classes.  On the other hand, it would only take
one example of a generic function that had different methods for
STANDARD-CHAR and CHARACTER to change my mind on this one.

I don't see why there would be any special implementation problems in
CLASS-OF, though.

    Third, I don't think that bit, fixnum and bignum should be defined to be
    part of the required class lattice, because they correspond conceptually
    to "range" types.

I agree with you here.  BIT is in the same category as STANDARD-CHAR.
KEYWORD and STRING-CHAR are also in this category.

FIXNUM and BIGNUM are implementation characteristics of integers; they
don't change the behavior (given a definition of behavior abstract enough
to rule out performance differences).  Thus I don't think it makes sense
for methods to make a distinction between FIXNUM and BIGNUM.  This is
different from my reason for excluding BIT.

    Finally, for those items that have multiple superclasses, we need to
    either define an order or else remove one of the superclasses.

I agree.

    I like having "list" as a class, but the precidence for NIL needs to be
    defined. I'd say that NIL was a symbol first and a list second, on the
    basis that "list" is an abstraction but "symbol" is quite concrete, and,
    at least when I write 'em, I tend to put the concrete classes before the
    abstract ones.

That was my reasoning also.  Converting a partial ordering to a total
ordering for the sake of brevity, I would rank classes in order from
most specific to most general:
  RATIONAL FLOAT NUMBER SYMBOL LIST VECTOR ARRAY SEQUENCE
These are all the built-in classes that definitely have subclasses.

    As for simple-vector, simple-bit-vector, simple-string, my inclination
    is that "simple" isn't a particularly interesting dimension to
    discriminate on; removing "simple-array" would do most of the cleanup,
    and saying that a "vector" is first an array and secondly a sequence
    would finish it off. 

I think this is similar to the fixnum/bignum situation.  Simpleness of an
array is an implementation characteristic, not a behavior characteristic.
I agree with both of your points here (don't have classes for simple-xxx;
array is more specific than sequence).

    On further examination, there are no requirements that stream,
    hash-table, readtable, package, pathname or random-state be distinct
    from other types (p 33), and my belief is that these cannot then be
    required to be "first class" classes, in that (class-of (make-hash-table
    ...)) might return the same as (class-of (make-array ...)) for suitable
    arguments.

    Perhaps this can be stated in the subjunctive, e.g. "if these are
    distinct types in your Common Lisp implementation, they'll probably be
    distinct classes in any implementation of this spec".

The language in CLtL pp.33-5 wasn't written with the concept of
inheritance in mind, it seems.  However, there are predicates defined to
test for all of these types, and they are required to be distinct from
each other (third bullet on p.35), so I don't think an implementation
could have them totally indistinguishable from other types.  I.e.
(class-of (make-hash-table ...))  might return the same as (class-of
(make-array ...)) for suitable arguments, but not for -all- arguments.
Given this, it just means that (SUBTYPEP 'HASH-TABLE 'ARRAY) is
implementation-dependent, which doesn't seem fatal to the idea of
HASH-TABLE being a class.  My thinking was to allow methods to
discriminate on all of the types you mentioned, except STREAM.  I
exclude STREAM for the same reason as FUNCTION; its definition is too
vague (but see below).

My reasons for excluding other built-in types listed in CLtL Table 4-1:
    ATOM		this is (NOT CONS), and we're not doing NOT yet
			[see McAllester and Zabih Boolean Classes paper
			at OOPSLA for some thoughts on why NOT is hard].
    COMMON		specification is too vague
    NIL			no object can be an instance of this type

Another way of looking at these choices is that if there is a MAKE-xxx
function, or something equivalent, I have included the type, but if there
isn't, I have excluded it.  Since there aren't separate functions for
making BITs, FIXNUMs, and BIGNUMs, they're excluded.  FUNCTION is excluded
because there is no function to make functions, but COMPILED-FUNCTION
is included because COMPILE exists.  STREAM is excluded because there
isn't one function to make streams, and in fact many different types
of objects can be streams.  This line of reasoning isn't watertight,
but it's a pretty good heuristic.

∂22-Sep-86  1024	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Class Precedence List 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86  10:23:52 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 SEP 86 09:51:36 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 22 SEP 86 09:40:08 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 109702; Mon
 22-Sep-86 12:38:18 EDT
Date: Mon, 22 Sep 86 12:37 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Class Precedence List
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860921-191928-1425@Xerox>
Message-ID: <860922123733.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 21 Sep 86 19:19 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>, Kahn.pa@Xerox.COM

    A recursive rule that computes class precedence lists locally.

    1) A class c1 cannot be given any super that has c1 in its
    class-precedence list.

    2) If c1 has one superclass c2, then the class precedence list of c1 is
    (cons c1 (c-p-l c2))

    3) If c1 has two superclasses, c2 and c3, then use
      (cons c1 (merge-pls (c-p-l c2) (c-p-l c3))

    where (merge-pls first second)
    takes the prefix of first until it finds an element in common with
    second.
    If there is none, then use all of first.  Follow by the prefix of second
    up to the common element. If this has any element in common with the
    rest of first, signal an error.  Insert the common element.  Repeat
    until first is empty, then append the rest of second.

    4) If there are more than 2, then merge the pairs in an associative
    manner

This requires that the class-precedence-list of every class be available
explicitly.  In our implementation we compute and store only the
precedence list of classes that are instantiated, or are going to be
instantiated.  For example, in the world I am running right now there
are 2668 classes, of which 1736 (65%) have class-precedence-lists and
932 (35%) don't.  Only 643 (24%) of the classes have actually been
instantiated, so an implementation that wasn't as concerned about
preparing things in advance of instantiation would have a higher cost
for precomputing the class-precedence-list of every class.  I checked a
world that was booted this morning, rather than a fortnight ago, and
hasn't been used for program development, and the percentages are not
significantly different.

    The claim is that this algorithm produces lists that obey all of Moon's
    rules, is local and one pass.

    "Proof"

    A class with no super obeys Moon's rules

    Proceed by induction.  

    Clearly (1) Each class precedes it own supers

    (2) Local ordering is preserved, since no ordering in the individual
    lists is changed by the merge. And the first element of each sublist
    (the local supers) have their order preserved.

    (3) Duplicate elimination always puts things as early as they can go.


    Several minutes thought has shown no problem with this.???

This algorithm might be okay, but I'm having trouble understanding your
description with enough precision to be sure what it does.  I can't be
sure that using the class-precedence-lists of the superclasses does the
same thing as looking directly at the constraints in each class, since
the class-precedence-list is a total ordering, and therefore contains
spurious orderings that are not implied by the partial ordering that the
programmer specified.

If you translate your algorithm to Lisp code and send it to me, I'll be
happy to check it against my algorithm, by eye and by running a thousand
test cases that I happen to have lying around.  (Unfortunately I don't
have a comprehensive set of test cases that are supposed to signal errors,
but I'll try two or three).

You have the Lisp code for my algorithm, don't you?  I think I sent it
to Gregor a long time ago.  We are making all of the New Flavors source
code publically available, subject only to the requirement that people
who copy it don't remove our copyright, so if you don't have the code
let me know and I'll send it to you.  I can send you just the class
precedence functions through the mail, or with more delay I could send
everything on some medium (maybe I have to have a signed agreement not
to yank off the copyright before I can send everything).

∂22-Sep-86  1025	Bobrow.pa@Xerox.COM 	Re: Class Precedence List    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86  10:24:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 86 10:12:03 PDT
Date: 22 Sep 86 10:11 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Class Precedence List
In-reply-to: Danny Bobrow <Bobrow.pa>, Kahn's message of 21 Sep 86 19:19
 PDT
To: Bobrow.pa@Xerox.COM, Kahn.pa@Xerox.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <860922-101203-1764@Xerox>

    A recursive rule that computes class precedence lists locally.

    1) A class c1 cannot be given any super that has c1 in its
    class-precedence list.

    2) If c1 has one superclass c2, then the class precedence list
    of c1 is (cons c1 (c-p-l c2))

    3) If c1 has two superclasses, c2 and c3, then use (cons c1
      (merge-pls (c-p-l c2) (c-p-l c3))

    where (merge-pls first second) takes the prefix of first until
    it finds an element in common with second. If there is none, then
    use all of first.  Follow by the prefix of second up to the common
    element. If this has any element in common with the rest of first,
    signal an error.  Insert the common element.  Repeat until first is
    empty, then append the rest of second.

    4) If there are more than 2, then merge the pairs in an
    associative manner


    The claim is that this algorithm produces lists that obey all
    of Moon's rules, is local and one pass.


Some more thought has shown that although this is true, it gives an
error in cases where Moon's multipass algorithm is claimed to work.
Consider classes with supers

class	    Supers    Precedence Lists
F1       B C          F1 B C Object
F2       A C          F2 A C Object
F3       A B          F3 A B Object
G        F1 F2        G F1 B F2 A C Object
     (The legal Moon list computed by Moon's algortihm and ours)
H        G F3         Error!!! by our algorithm

But a legal Moon precedence list for H is

H G F1 F2 F3 A B C Object


Notice that the order of A and B are in opposite orders in precedence
lists for G and H.  Is this freedom desirable?  If not, then our
algorithm is good.  If so, then ???


-- danny and ken

∂22-Sep-86  1130	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Generic Function Objects   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86  11:30:37 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 22 SEP 86 11:00:26 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 22 SEP 86 10:59:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 109808; Mon
 22-Sep-86 13:58:00 EDT
Date: Mon, 22 Sep 86 13:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Generic Function Objects
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860921-153930-1345@Xerox>
Message-ID: <860922135659.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 21 Sep 86 15:39 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>
    From: Gregor Kiczales <Gregor.pa@Xerox.COM>

    In the existing CommonLoops papers and code, there is an object called
    the discriminator and piece of code called the discriminating function.
    The discriminating function was stored inside the discriminator, and
    when the discriminator was "named", was also stored in the
    symbol-function cell of the symbol which named the discriminator.  The
    discriminating-function was the thing you funcalled, the discriminator
    was the thing that you passed to add-method.

    A potentially better design combines the discriminator and the
    discriminating function into a single, closure-like, object called the
    generic function.  The generic function is funcallable; funcalling it
    causes method lookup to happen.  Accessors which used to work on the
    discriminator work directly on the generic function.  In particular,
    generic-function-methods returns a list of all the methods defined on a
    generic function. 

    Generic functions are mutable, and are side-effected by add-method and
    remove-method. An alternative proposal makes them immutable, add-method
    and remove-method return new generic-functions, see Masinter's message
    of 21-Sep-86 12:26:49 PDT.

    We spent a fair amount of time discussing the implementation
    implications of this.  We believe that this does not cause serious
    implementation problems.  At least the mutable case can even be
    implemented fairly efficiently in PCL.

    This new scheme has not yet been discussed on this list though.  This
    message is intended to spark that discussion.

Well, Dick brought this up on 29 August, and I discussed it on 3 Sep
(see Message-ID: <860903155437.5.MOON@EUPHRATES.SCRC.Symbolics.COM>),
and Dick replied with some vague answers ("I think we have a cleaner design than
what you suggest."), (see Message-ID: <860903-150632-1329@Xerox>),
but it seems to have been dropped after that.

I still believe what I said back then:
  The primary reason for keeping them separate is to gain the freedom
  to perform implementation-dependent optimizations of the time-critical
  operation of calling a generic function.  In our implementation we could
  rather easily make the function definition of the name of a generic
  function be an acceptable argument to the other operations on generic
  functions, as a synonym for the generic function meta-object itself,
  but I'm not sure if all implementations could do this, since Common Lisp
  defines very little of the characteristics of a compiled-function as an
  object.

∂22-Sep-86  1132	Gregor.pa@Xerox.COM 	Re: Class Precedence List    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86  11:31:51 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 86 11:31:13 PDT
Date: 22 Sep 86 11:19 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: Class Precedence List
In-reply-to: Danny Bobrow <Bobrow.pa>, Kahn's message of 21 Sep 86 19:19
 PDT
To: Bobrow.pa@Xerox.COM, Kahn.pa@Xerox.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860922-113113-1887@Xerox>

One problem with this algorithm is that compute-class-precedence-list is
required to be a function of the local-supers tree.  It is specifically
not allowed to just snarf the CPL of a class that it comes across, but
rather must recompute it.  I have not yet figured out what the
implications are, in this particular case, of violating this rule. 

Another problem with this algortihm is that it doesn't, at least from
the explanation you give, seem any easier to explain than Moon's rules.

∂22-Sep-86  1300	Gregor.pa@Xerox.COM 	Re: Generic Function Objects 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86  13:00:16 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 86 11:33:54 PDT
Date: 22 Sep 86 11:27 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: Generic Function Objects
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Mon, 22 Sep 86 13:56 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860922-113354-189@Xerox>

It is my belief (actually, I am pretty sure Danny and Dick agree), that
this reduces to the problem of fast funcall for compiled, indefinite
extent lexical closure fast.  We assumed that most Common Lisps had
tackled that problem, and could re-use the same technology.

∂22-Sep-86  1410	masinter.pa@Xerox.COM 	Re: initial class lattice  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86  14:05:20 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 86 13:48:03 PDT
Date: 22 Sep 86 13:42 PDT
From: masinter.pa@Xerox.COM
Subject: Re: initial class lattice
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Mon, 22 Sep 86 12:00 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: commonloopscore↑.PA@Xerox.COM
Message-ID: <860922-134803-1141@Xerox>

The objective is to allow class-of to be fast even in implementations
where some other predicates (e.g., compiled-function-p) are slow.  Any
meta-operation needs to first get the class so that it can participate
in discrimination, and meta-operations are performance critical; e.g.,
there are a number of operations (e.g., get-slot) which are defined in
terms of the meta-class rather than the class, and which might compile
inline as a method-invocation on class-of. For that reason, the leaves
of the initial class hierarchy should be restricted to be those items
which are known to be immediately computable from the object and from
its type tags.

For newly defined classes, we can insure that class-of can be executed
quickly. However, for the built-in classes, we need to integrate over
the range of Lisp implementations so as not to invalidate what would
otherwise be a good implementation technique (read: hack). If
compiled-function is allowed to inherit from vector, then it must be
that for any vector, (class-of ...) needs to ask compiled-function-p,
which could be relatively expensive. It is much preferable to "leave it
out".... certainly it can be added in for those that keep it separate.
There were reasons before to not make requirements on the implementation
of compiled functions, and they remain.

It is unacceptable to define arbitrary subclass relationships, because
the type predicates would disagree with the class predicates. (vectorp
x) but (class-of x) isn't a subclass of vector.

The major problem with "type specifiers" which are not class in
discrimination is avoiding ambiguity and insuring portability. 

- - - - - - -

Another thing CLASS-OF is good for is a more principled approach to what
type-of attempts and fails at. TYPE-OF is hopelessly underspecified,
and, as such, is not useful in portable code.

CLASS-OF, however, is reasonably well specified (once the bugs in the
initial class lattice are worked out), and then an implementation 

(defun type-of (x) (class-name (class-of x)))

would be a reasonable way of "cleaning up" what is otherwise a mess.

CLASS-OF allows meta-class discrimination, e.g., (mapcar #'(lambda
(slot) (get-slot x slot) (class-slots (class-of x)))).

- - - - - - - -
We should be explicit about allowable extensions to the class lattice
(e.g., for all vectors, it is only required that class-of return a
subclass of class vector, and it is possible to add intermediate classes
as well).


∂22-Sep-86  1410	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: Class Precedence List  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86  14:05:27 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 SEP 86 14:02:42 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 22 SEP 86 13:39:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110024; Mon
 22-Sep-86 16:37:51 EDT
Date: Mon, 22 Sep 86 16:36 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Class Precedence List
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860922-101203-1764@Xerox>
Message-ID: <860922163653.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 22 Sep 86 10:11 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>, Ken Kahn
    ....Notice that the order of A and B are in opposite orders in precedence
    lists for G and H.  Is this freedom desirable?  

I don't see why not.  It seems to me that if there is no constraint on
the ordering of those classes, you are not doing the user a favor by
complaining that H is illegal when it doesn't violate any local ordering
constraints.  You're just harrassing the user.

I wrote a little program that searched the world on my machine for pairs
of flavors that don't always appear in the same order.  It found 1830
pairs.  I think this is some sort of evidence that this freedom is, in
fact, desirable.  I looked at a few pairs and they generally seem to be
flavors whose ordering doesn't matter because they have orthogonal
behavior (i.e. no methods in common).

						    If not, then our
    algorithm is good.  If so, then ???

I think this must be an example of the problem I suspected in my
previous message where your algorithm, by using a total ordering as a
standin for a partial ordering, generates spurious ordering constraints
which then get you into trouble.  What are the reasons for not using the
partial ordering instead?

∂22-Sep-86  1510	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: Generic Function Objects    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86  15:10:37 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 SEP 86 14:06:06 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 22 SEP 86 13:56:16 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110053; Mon
 22-Sep-86 16:53:37 EDT
Date: Mon, 22 Sep 86 16:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Generic Function Objects
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860922-113354-189@Xerox>
Message-ID: <860922165254.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 22 Sep 86 11:27 PDT
    From: Gregor Kiczales <Gregor.pa@Xerox.COM>

    It is my belief (actually, I am pretty sure Danny and Dick agree), that
    this reduces to the problem of fast funcall for compiled, indefinite
    extent lexical closure fast.  We assumed that most Common Lisps had
    tackled that problem, and could re-use the same technology.

Personally I think it's important for the wide acceptance of this standard
for it to avoid features that could cause unnecessary efficiency problems
on some implementations.  No matter how fast funcalling a closure is, it's
going to be a little slower than calling something that isn't a closure.
If every microsecond counts, this could be a problem.

As I said, Symbolics has no problem with this, but I think that before
putting something into the standard that might cause problems for some
implementations we should either get wider input so we can be sure that
it won't cause problems, or we should reexamine the benefits of putting
it into the standard to make sure the benefits outweigh the costs.

No one has ever answered my question of what are the benefits, unless I
missed the answer.  As far as I can tell, the sole benefit is that you
can say #'FOO instead of (GENERIC-FUNCTION-NAMED 'FOO).  Perhaps there
is something else that I am missing.  So far no one has ever answered
this question.

∂22-Sep-86  1511	masinter.pa@Xerox.COM 	Re: Syntax of DEFCLASS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86  15:10:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 86 14:44:21 PDT
Date: 22 Sep 86 14:30 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Syntax of DEFCLASS
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Sun, 21 Sep 86 18:20 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
line-fold: no
cc: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860922-144421-1211@Xerox>

Many of your arguments are historical ("The real problem with defstruct is that it was designed nine years ago...") I thought I would check the historical record. I've scanned the Common Lisp mail for the last 4 years and found only the following. The lack of any proposals to change defstruct, while there've been proposals galore to do lots of violence, leads me to believe that the syntax, while not the "best", is certainly adequate. And, now that there are thousands of users of Common Lisp and at least 8 textbooks and numerous courses and etc, I think we're best off living with it. I don't think a proposal to change it will fly. 
 
Date: 1 October 1982 04:06-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject:  DEFSTRUCT options syntax
To: Common-Lisp at SU-AI

From the last meeting:

  17. Can we standardize on keywords always being used as
      name-value pairs?  The worst current deviants are
      WITH-OPEN-FILE and DEFSTRUCT options.  

          Yes.  The Lisp Machine LISP group will make a
          proposal soon for OPEN, WITH-OPEN-FILE, and
          DEFSTRUCT.

While everyone agrees that OPEN and WITH-OPEN-FILE should be fixed (and they already have been fixed on the Lisp Machine), the case for DEFSTRUCT is not as clear.  In my opinion the change is gratuitous since the options list in a defstruct is NOT a function call.  Furthermore it is more than a non-trivial incompatible change since each option has to be re-thought in light of the fact that it can now be given only one argument rather than any number.  (Note that the :CONSTRUCTOR and :INCLUDE options take advantage of this multiple-argument ability.)

I asked Moon and DLW if they agreed with me on this subject.  Moon replied:

    Date: Thursday, 30 September 1982  00:44-EDT
    From: MOON at SCRC-TENEX
    To:   DLW at SCRC-TENEX
    cc:   Alan
    Re:   gratuitous change to defstruct syntax.

    I've changed my mind about this since August, and am now in agreement with
    Alan.  Partly this was caused by thinking about what it would mean to
    change DEFFLAVOR to use alternating keywords and values; it seems very
    clear that it would make it much worse.  Thinking about this more made me
    decide that some special forms have syntax that looks something like a
    function call, but many are totally unrelated to function calls and trying
    to wedge them into the same mold is just confused (and confusing).
    Certainly the way OPEN used to be was wrong, and fixing it was a big win.
    But I think DEFSTRUCT should stay with "option" or "(option args...)"
    syntax, as should DEFFLAVOR, DEFSYSTEM, DEFSITE, and who knows what else.
    It probably is not a coincidence that these are all "defining" forms.

DLW is also in agreement with me on this.  How about it folks, can we keep DEFSTRUCT parsing its options the way it is now?



02-Oct-82  0939	Guy.Steele at CMU-10A 	keyword pairs and DEFSTRUCT
Date:  2 October 1982 1240-EDT (Saturday)
From: Guy.Steele at CMU-10A
To: common-lisp at SU-AI
Subject: keyword pairs and DEFSTRUCT

I am in sympathy with leaving DEFSTRUCT as is.  Indeed, there may be something odd about DEF-forms.  OPEN was the biggest thorn, to my mind.


13-Oct-82  1309	STEELE at CMU-20C 	Ballot results  
Date: 13 Oct 1982 1608-EDT
From: STEELE at CMU-20C
Subject: Ballot results
To: common-lisp at SU-AI


...

27.  Shall DEFMACRO, DEFSTRUCT, and other defining forms also be allowed to take documentation strings as possible and appropriate?
	(y) yes   (n) no

Issue 27: *** Y *** Hedrick: Y	Wholey: Y	Fahlman: Y	Weinreb: Y	Killian: Y Zubkoff: Y	Moon: Y		van Roggen: Y	Masinter: Y	RMS: Y Dyer: Y		Bawden: Y	Feinberg: Y	Ginder: Y	Burke et al.: Y Brooks: Y	Gabriel: Y	DECLISP: Y	Steele: Y	Dill: X Scherlis: Y	Pitman: Y	Anderson: Y

∂22-Sep-86  1628	Owners-commonloopscore↑.PA@Xerox.COM 	Re: initial class lattice  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86  16:28:14 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 SEP 86 15:32:37 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.PA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 22 SEP 86 15:31:30 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110144; Mon
 22-Sep-86 18:03:58 EDT
Date: Mon, 22 Sep 86 18:03 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: initial class lattice
To: commonloopscore↑.PA@Xerox.COM
In-Reply-To: <860922-134803-1141@Xerox>
Message-ID: <860922180312.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 22 Sep 86 13:42 PDT
    From: masinter.pa@Xerox.COM

    The objective is to allow class-of to be fast even in implementations
    where some other predicates (e.g., compiled-function-p) are slow....
    For that reason, the leaves
    of the initial class hierarchy should be restricted to be those items
    which are known to be immediately computable from the object and from
    its type tags.
    ....
    Another thing CLASS-OF is good for is a more principled approach to what
    type-of attempts and fails at. TYPE-OF is hopelessly underspecified,
    and, as such, is not useful in portable code.

    CLASS-OF, however, is reasonably well specified (once the bugs in the
    initial class lattice are worked out), and then an implementation 

    (defun type-of (x) (class-name (class-of x)))

    would be a reasonable way of "cleaning up" what is otherwise a mess.

So TYPE-OF a compiled function would be VECTOR.  Sorry, I can't agree
that this constitutes cleaning up the mess!  This is independent of the
other issues in your message and shouldn't be allowed to cast doubt
on them.

∂22-Sep-86  1757	Owners-CommonLoopsCore↑.pa@Xerox.COM 	default optional arguments to a generic function    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86  17:57:38 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 SEP 86 17:50:04 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 22 SEP 86 17:45:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110252; Mon
 22-Sep-86 20:37:50 EDT
Date: Mon, 22 Sep 86 20:37 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: default optional arguments to a generic function
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860921-180617-1396@Xerox>
Message-ID: <860922203704.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 21 Sep 86 18:06 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

    The following principles seem to be ones we have agreed to with respect
    to generic functions and methods.

    1) Methods should be able to take any Common Lisp lambda-list.  In
    particular the default defmethod must be able to look like a defun.

    2) defgeneric should be optional, unless special options are used, such
    as :generic-function-class.

    3) The contract of the generic function should be true for all methods,
    and that contract should be computable from a defmethod form.

Agreed.

    This seems to lead to two competing proposals (Gregor says I am
    oversimplifying)

    Proposal a) The generic function specifies the full argument list, and
    all methods must have congruent argument lists.  This leads to the
    problem of defining congruence (Moon proposed some rules, but as
    Masinter pointed out, they had a problem with renaming of variables used
    in default value forms).  It also leads to redundancy in the methods --
    making it difficult to change a default value form in a single place.
    However, Gregor favors this scheme as later extendible by removing
    restrictions.  He would allow methods to take extra keywrod args if
    &allow-other-keys appears in the defgeneric.

    Proposal b) The generic function specifies only the required arguments,
    and methods discriminate only on those arguments.  However, methods can
    have arbitrary argument list beyond the required  arguments.  From any
    method, the generic contract can be computed.  All methods must have the
    same number of min-args.

I'm not sure these are the only possible proposals.  However, proposal
(a) certainly sounds less kludgy as described here.  Note that all of
the nonsense with default-value-form congruence is only necessary if use
of optional and keyword arguments for method selection is permitted.  At
this point it seems clear to me that there is no way our "sound basis"
goal will allow us to standardize on any form of that at this time,
since anything we come up with is going to be new and untried.  I favor
standardizing on a minimal design that does not preclude adding more
features as extensions later, when we understand their implications.
My understanding of the user community's desires is that they would
rather see a smaller standard that is published sooner, rather than a
hairier standard that takes longer to start benefiting them.

    This allows cases 1a) and 1b)

	Case 1a.  "draw-line"

	    draw-line takes an optional, the width of the line in
	    device dependent units.  Because they are device dependent
	    units, each individual method would like to default this
	    argument on its own.

	    (defmethod draw-line ((dev printer) p1 p2
				     &optional (width 7)) ...)

	    (defmethod draw-line ((dev window) p1 p2
				     &optional (width 1)) ...)

	    Case 1b.

	    Within case 1, some methods may want to take an extra
	    argument.  Also see case 3 which is similar.

	    (defmethod draw-line ((d gray-display) p1 p2
				     &optional (width 3) 
								(gray *gray1*))

	  ..)

	Date: Wed, 17 Sep 86 16:15 EDT
	From: David A. Moon 
	The problem here is that the generic function doesn't have a
	consistent contract.  The meaning, or even the existence, of one
	argument depends on the class of another argument.  I don't see how
	a caller of draw-line could operate without knowing the exact
	method that was going to be called. From experience I know it's
	possible to have all sorts of arguments about whether this is good
	or bad programming practice.  In New Flavors, these arguments were
	resolved in favor of consistency of contracts, rather than the
	increased flexibility of different contracts for different methods,
	but not everyone was happy. 

    I think it is possible to know that a method is coming from a particular
    part of the class lattice (without knowing the exact method) and  hence
    know the local contract.  Consistency of generic contract is only in the
    required argument set.

As I said, it's possible to have all kinds of arguments about this, and
everyone has their own idea of what they would like to see.  I don't
even disagree with what you just said.  However, the way we are going
around and around on this doesn't sound to me like something that is
ready for standardization.  We should tread carefully in this area.

    To take care of GFD#2, I propose that we allow the generic to specify
    optionals that it fills in.  The contract between the generic and the
    methods is to always supply these required method arguments.  I claim it
    should not be part of the contract between the generic and the method to
    provide that information.  

I can't figure out what the last two sentences, taken as a whole, are saying.

			       I propose a lambda list keyword option
    &generic-optional in the generic function.  Optional argument
    specifications after this provide only argument names and default value
    forms, but cannot have a supplied-p variable. 

    For example:
    (defgeneric draw (thing &generic-optional (place *draw-window*))
		"Draw thing on place.") 

    (defmethod draw ((thing line) (place raster-display)) ...)
    
    (defmethod draw ((thing line) (place vector-display)) ...)
 
    Methods must have required arguments where generic-optionals are
    provided.  Optionals in methods cannot be discriminated on.

This is fine as a proposal, but I don't think it belongs in a standard.
Next week, or next month, there might be a different idea that seems
better.

    Case 3 "move" is outlawed by this proposal, because the number of
    required arguments differ.

OK.

∂22-Sep-86  1814	masinter.pa@Xerox.COM 	Re: default optional arguments to a generic function
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86  18:14:00 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 86 18:04:16 PDT
Date: 22 Sep 86 17:58 PDT
From: masinter.pa@Xerox.COM
Subject: Re: default optional arguments to a generic function
To: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <860922-180416-1453@Xerox>

I think the causes of differences here are twofold: first, whether the
default argument behavior of a function is part of its "external"
contract or something internal, and secondarily, whether language
constructs should be added to enforce contracts.

I do not believe that the argument limits (minimum, maximum, optional,
keyword) are part of the "external contract" of a function. That is,
from the point of view of the caller, there is no difference between a
&rest argument that explicitly checks if too many arguments are supplied
and a &optional argument. While there have been a number of proposals to
add such information to Common Lisp, they have foundered partly on the
objections that such information is not part of the external interface.

If argument behavior is not part of the "external" contract, then of
course methods can simply *differ* on the number of arguments supplied.
Of course, if you get to a method with too many or too few arguments,
you will get an error, just like if you call a function with the wrong
number of arguments.

While this might be "bad programming style" in some cases, it is
legitimate in others (Kahn's arguments about local vs global
consistency). 

Environment tools can help detect inconsistent use of arguments in a
method, just as they can help detect a disparity between the number of
arguments supplied and the number expected in static code.


Finally, I object to language constructs in Lisp whose primary function
is to enforce contracts between the caller and callee. While adding the
notion of functional interfaces to Lisp is an interesting research
topic, and matching the interface specification to the various
implementations of that interface a useful construct in modular
programming languages, it does not belong attached to the "object
oriented" part of the language.

Perhaps we want a construct:

(define-function-interface name argument-shape values-shape
documentation) 

which asserts that "name" will take arguments described by
argument-shape (which includes both extentional and intentional type
descriptions) and returns values described by values-shape, and has the
following documentation string, and then build some environment tools
that allow programs to be compiled in such a manner that any
disagreement between the function-interface and a defintion or use is
signalled by the compiler/checker. This would be an interesting
facility. It sort of looks like DEFGENERIC. But it doesn't belong here.

Larry

 


∂22-Sep-86  2229	MASINTER.pa@Xerox.COM 	class-of compiled objects  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86  22:29:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 86 22:27:08 PDT
From: MASINTER.pa@Xerox.COM
Date: 22 Sep 86 22:26:48 PDT
Subject: class-of compiled objects
To: (moon)
cc: commonloopscore↑.pa@Xerox.COM
Message-ID: <860922-222708-1576@Xerox>

In those implementations where compiled-function is a subtype of vector,
the only alternative would be to allow (class-name (class-of (make-array
...))) to return 'compiled-function for some unspecified arguments to
make-array, even if the results were not intended to be treated as a
compiled function.

∂22-Sep-86  2236	MASINTER.pa@Xerox.COM 	generic function objects   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 86  22:35:55 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 86 22:35:07 PDT
From: MASINTER.pa@Xerox.COM
Date: 22 Sep 86 22:34:47 PDT
Subject: generic function objects
To: commonloopscore↑.pa@Xerox.COM
Message-ID: <860922-223507-1578@Xerox>

(For  reference, the question is, is installing a generic function done
with

(setf (symbol-function 'foo) (make-generic-function ...))

or with

(setf (symbol-generic-function 'foo) ...)



I've been meditating on "class-named" and came up with "find-class"
instead, in keeping with "find-package". Another alternative would be
"symbol-class" but that is pretty hopeless, and the class isn't a
property of the symbol, the symbol is just a name for the class.

∂23-Sep-86  0859	Owners-commonloopscore↑.pa@Xerox.COM 	class-of compiled objects  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Sep 86  08:47:15 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 SEP 86 08:45:12 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.pa@XEROX.ARPA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 23 SEP 86 08:44:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110609; Tue
 23-Sep-86 11:41:09 EDT
Date: Tue, 23 Sep 86 11:41 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: class-of compiled objects
To: commonloopscore↑.pa@Xerox.COM
In-Reply-To: <860922-222708-1576@Xerox>
Message-ID: <860923114122.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 22 Sep 86 22:26:48 PDT
    From: MASINTER.pa@Xerox.COM

    In those implementations where compiled-function is a subtype of vector,
    the only alternative would be to allow (class-name (class-of (make-array
    ...))) to return 'compiled-function for some unspecified arguments to
    make-array, even if the results were not intended to be treated as a
    compiled function.

Sure, but why is that a problem?  Surely that object is indistinguishable
from a compiled-function in every other way, unless an intelligent algorithm
checked the machine instructions in it for plausibility as output from the
compiler, so why not make the class structure consistent with the rest of
the implementation in calling it a compiled-function?

∂23-Sep-86  0902	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Name of RUN-SUPER
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Sep 86  09:02:06 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 SEP 86 08:58:55 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA@XEROX.ARPA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 23 SEP 86 08:58:39 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110635; Tue
 23-Sep-86 11:53:08 EDT
Date: Tue, 23 Sep 86 11:53 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Name of RUN-SUPER
To: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <860923115320.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

[This was sent last Saturday but apparently did not go through.
In resending it I changed the suggestion from NEXT-METHOD to
CALL-NEXT-METHOD.]

There is a problem with the name of RUN-SUPER.  With the introduction
of multimethods, it can no longer be said that RUN-SUPER runs the method
of the superclass.  It might use the next argument to choose a method,
and in fact get that method from a class much more specific than the class
from which the current method came.  Similarly, the introduction of around
methods mean that RUN-SUPER could be running a more specific method, if
the next method is a primary method rather than another around method.
In both cases, RUN-SUPER is running the next method, not necessarily a
method from a superior class.

For these reasons, I feel that a more appropriate name for this
primitive would be CALL-NEXT-METHOD.

∂23-Sep-86  1354	Owners-commonloopscore↑.PA@Xerox.COM 	Re: initial class lattice  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Sep 86  13:54:05 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 SEP 86 13:50:39 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.PA@XEROX.ARPA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 23 SEP 86 13:50:24 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 111046; Tue
 23-Sep-86 16:48:02 EDT
Date: Tue, 23 Sep 86 16:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: initial class lattice
To: commonloopscore↑.PA@Xerox.COM
In-Reply-To: <860922-134803-1141@Xerox>
Message-ID: <860923164810.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 22 Sep 86 13:42 PDT
    From: masinter.pa@Xerox.COM

    The objective is to allow class-of to be fast even in implementations
    where some other predicates (e.g., compiled-function-p) are slow.  Any
    meta-operation needs to first get the class so that it can participate
    in discrimination, and meta-operations are performance critical; e.g.,
    there are a number of operations (e.g., get-slot) which are defined in
    terms of the meta-class rather than the class, and which might compile
    inline as a method-invocation on class-of. For that reason, the leaves
    of the initial class hierarchy should be restricted to be those items
    which are known to be immediately computable from the object and from
    its type tags.

It might pay to examine this a little more closely.  To continue with
the example of a compiled-function that is also a vector, the time to do
get-slot of a vector doesn't matter, as long as it doesn't slow down the
time to do get-slot of other types of objects.  After all, vectors don't
have slots.  Are there examples of other operations that are performance
critical for primitive objects and depend on class-of?  I can't imagine
any.  So the question is really whether the implementor is smart enough
to implement class-of in such a way that the exception cases, where a
complicated test is required to determine the class, don't slow down the
normal case.  This seems a low enough level of issue that it shouldn't
be allowed to dictate the semantics of the language.

∂24-Sep-86  2021	Owners-commonloopscore↑.PA@Xerox.COM 	Re: (change-class x y) => (setf (class-of x) y)?    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 24 Sep 86  20:20:12 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 24 SEP 86 20:17:09 PDT
Return-Path: <DLW@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: commonloopscore↑.PA@XEROX.ARPA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 24 SEP 86 20:16:44 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 112892; Wed
 24-Sep-86 23:09:39 EDT
Date: Wed, 24 Sep 86 23:14 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: (change-class x y) => (setf (class-of x) y)?
To: Kahn.pa@Xerox.COM
cc: commonloopscore↑.PA@Xerox.COM
In-Reply-To: <860921-171550-1381@Xerox>
Message-ID: <860924231419.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
Line-fold: No

    Date: 21 Sep 86 17:15 PDT
    From: Ken Kahn <Kahn.pa@Xerox.COM>

    I like Larry's suggestion for the same reasons that most people like
    SETF -- fewer names to deal with.

Minimizing the number of names does not mean that things are necessarily
clearer, simpler, and/or easier to understand.

SETF is a construct that deals with a concept that we usually call a
"generalized variable".  A generalized variable is, conceptually, a
place to put something.  Evaluating the generalized variable returns the
contents of the place.  Using SETF on the generalized variable stores
something into the place.  That's what SETF is basically about, and
that's how you'd explain SETF in a Lisp course.

Within this conceptual framework, (CLASS-OF ...) does not constitute
a "generalized variable".

In this case, you are attempting to minimize the number of names by
overloading one name with two different functions.  This does not make
things simpler or easier to learn.

P.S. Consider that it would never make sense to do (PUSH X (CLASS-OF Y)).

P.P.S.  Consider that we do not grow a vector by doing (SETF (LENGTH X) 10).

∂24-Sep-86  2037	Owners-commonloopscore↑.PA@Xerox.COM 	Re: (change-class x y) => (setf (class-of x) y)?    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 24 Sep 86  20:37:04 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 24 SEP 86 20:33:49 PDT
Redistributed: commonloopscore↑.PA@XEROX.ARPA
Received: from Cabernet.ms by ArpaGateway.ms ; 24 SEP 86 20:33:34 PDT
From: masinter.PA@Xerox.COM
Date: 24 Sep 86 20:33:16 PDT
Subject: Re: (change-class x y) => (setf (class-of x) y)?
In-reply-to: DLW@ALDERAAN.SCRC.Symbolics.COM's message of Wed, 24 Sep 86
 23:14 EDT, <860924231419.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
To: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
cc: Kahn.pa@Xerox.COM, commonloopscore↑.PA@Xerox.COM
Message-ID: <860924-203349-3799@Xerox>

All other things being equal, fewer odd names are better. Are you
claiming you like "(change-class x y)" better than "(setf (class-of x)
y)"? If not, do you have a better proposal?

P.S. Consider that it never makes sense to do (PUSH X (SYMBOL-FUNCTION
Y)) either.

P.P.S. Consider that we do shrink adjustable arrays by DECFing their
FILL-POINTER.

∂25-Sep-86  0809	Bobrow.pa@Xerox.COM 	Re: Class Precedence List    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 25 Sep 86  08:08:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 25 SEP 86 08:00:01 PDT
Date: 25 Sep 86 07:59 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Class Precedence List
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Mon, 22 Sep 86 16:36 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <860925-080001-4023@Xerox>


The search I would be interested in is not the one where there are
differences of order only, but ones in which a subclass has the classes
in a different order than a super.  This could lead to strangeness for a
user who tests an operation on a superclass, and finds then happening
differently in a subclass.

However, the partial order is probably the best we can do.  I have not
yet seen your code.  Haven't asked Gregor.
-- danny

∂25-Sep-86  0810	Bobrow.pa@Xerox.COM 	[Guy Steele <gls@Think.COM>: Syntax of defstruct  versus   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 25 Sep 86  08:09:05 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 25 SEP 86 08:02:33 PDT
Date: 25 Sep 86 08:02 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: [Guy Steele <gls@Think.COM>: Syntax of defstruct  versus
 DEFCLASS]
To: CommonLoopsCore↑.pa@Xerox.COM
cc: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <860925-080233-4027@Xerox>

I asked Guy his opinion about this issue.

Here is his response.


From: Guy Steele <gls@Think.COM>
Subject: Syntax of defstruct  versus DEFCLASS
To: Bobrow.pa
Cc: gls@AQUINAS.ARPA
In-Reply-To: <860921-160133-1351@Xerox>
Message-Id: <860922161225.1.GLS@DESCARTES.THINK.COM>

Danny,
  I haven't seen all of the discussion that led up to this,
of course.  Moon's technical criticism of DEFSTRUCT syntax
is well taken for the most part.  It has also bothered me
that the option syntax is not like other uses of keywords
in the language (namely keyword-value pairs), and that you
cannot have slot-options without specifying a value.

  If DEFCLASS is to solve some of the modularity problems
such as the distinction between implementation access and
client access, then it is sufficiently different that it is
appropriate to make a clean break and design a good syntax.
If the aim is to be a semantically minimal extension of
DEFSTRUCT, then it should also be a syntactically minimal
extension of DEFSTRUCT.  (How is that for waffling?  I have
no strong absolute feelings about the issue; I can only
express an opinion on how it should be done relative to a
set of goals.)

  As for :conc-name, I think that is really stupid.  Why not
let there simply be a default way of making names, and the
default can be overridden for each slot with a slot-option?

--Guy


 

∂25-Sep-86  1229	masinter.pa@Xerox.COM 	Re: (change-class x y) => (setf (class-of x) y)?    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 25 Sep 86  12:29:28 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 25 SEP 86 11:29:36 PDT
Date: 25 Sep 86 11:21 PDT
From: masinter.pa@Xerox.COM
Subject: Re: (change-class x y) => (setf (class-of x) y)?
In-reply-to: masinter.PA's message of 24-Sep-86 20:33:16 PDT
To: commonloopscore↑.PA@Xerox.COM
Message-ID: <860925-112936-4275@Xerox>

Let me give a less "off-the-cuff" reply:

For those objects whose class is mutable, the "class-of" the object is
as much of a "generalized variable" as many of the other Common Lisp
constructs which are changed using SETF. The general direction has been
to use SETF whenver possible as the principle way in which objects are
modified; few excepts were made in Common Lisp even where tradition
would have chosen different names. 

The notion that some objects have a mutable class may seem strange, but
it seems no more or less strange if the operation is called
"set-class-of" or "change-class" or "setf (class-of". 

In any case, the name "change-class" is awkward; there is no other
modify-operation in Common Lisp that is called "change", although
"set-class" or "set-class-of" might be reasonable.




∂25-Sep-86  1229	masinter.pa@Xerox.COM 	Re: initial class lattice  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 25 Sep 86  12:29:36 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 25 SEP 86 12:20:31 PDT
Date: 25 Sep 86 12:12 PDT
From: masinter.pa@Xerox.COM
Subject: Re: initial class lattice
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Tue, 23 Sep 86 16:48 EDT
To: commonloopscore↑.PA@Xerox.COM
Message-ID: <860925-122031-4341@Xerox>

Masinter:   The objective is to allow class-of to be fast even in
implementations...

Moon:

It might pay to examine this a little more closely.  To continue with
the example of a compiled-function that is also a vector, the time to do
get-slot of a vector doesn't matter, as long as it doesn't slow down the
time to do get-slot of other types of objects.  After all, vectors don't
have slots.  Are there examples of other operations that are performance
critical for primitive objects and depend on class-of?  I can't imagine
any.  So the question is really whether the implementor is smart enough
to implement class-of in such a way that the exception cases, where a
complicated test is required to determine the class, don't slow down the
normal case.  This seems a low enough level of issue that it shouldn't
be allowed to dictate the semantics of the language.

Masinter:

Your point is well taken. I agree now that the performance issue is not
critical.
However, the issue remains: which types in CLtL are intrinsic and which
are extrinsic? Clearly (satisfies evenp) is an extrinsic type -- it
depends on a view of the data rather than on the data itself. The
current type system is muddy enough that it allows some implementations
to treat compiled-function-p and hash-table-p and read-table-p as if
they were testing extrinsic properties rather than intrinsic ones, and
thus, the types would not correspond directly to classes.

I think this is one of those awful, picky issues that are irrelevant to
the whole proposal but that standards are made of. The tradeoff is
between power (they're classes, which means you can write discriminators
on them) and portability (some implementations might treat
compiled-function as a sublcass of vector, and others not) and the
constraint of not changing drastically the implementation requirements
of the system. Which would you rather give up? 

∂25-Sep-86  1358	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: Class Precedence List  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 25 Sep 86  13:57:54 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 25 SEP 86 12:53:27 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa@XEROX.ARPA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 25 SEP 86 12:52:57 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 114016; Thu
 25-Sep-86 14:58:46 EDT
Date: Thu, 25 Sep 86 14:58 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Class Precedence List
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860925-080001-4023@Xerox>
Message-ID: <860925145850.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 25 Sep 86 07:59 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

    The search I would be interested in is not the one where there are
    differences of order only, but ones in which a subclass has the classes
    in a different order than a super.  This could lead to strangeness for a
    user who tests an operation on a superclass, and finds then happening
    differently in a subclass.

That is exactly what the New Flavors ordering rules, as compared with either
breadth-first or depth-first search, are intended to avoid.  It might be that
there are cases where they don't avoid this problem, but I'd have to see
a specific example.  The proposed extension, which I kind of like but have
neither implemented nor evaluated its effect on real programs, deals more
stringently with this issue by examining all pairs of component classes whose
order is unconstrained and determining whether exchanging them would alter
any inherited methods; if not, their order doesn't matter, because it doesn't
affect behavior.  If so, signal an error.  This extension would ensure that
no matter which of the possible total orderings consistent with the partial
ordering is chosen, the behavior is the same.

Even though I like this idea (due to KMP originally I believe) I can't
support putting it into a standard, since it hasn't been tried in the
real world.

∂26-Sep-86  0954	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: Class Precedence List  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Sep 86  09:54:11 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 26 SEP 86 09:50:47 PDT
Redistributed: CommonLoopsCore↑.pa
Received: from Cabernet.ms by ArpaGateway.ms ; 26 SEP 86 09:50:28 PDT
Date: 26 Sep 86 09:45 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Class Precedence List
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Thu, 25 Sep 86 14:58 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CommonLoopsCore↑.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <860926-095047-5234@Xerox>

        The search I would be interested in is not the one
        where there are differences of order only, but ones in which a
        subclass has the classes in a different order than a super. 
        This could lead to strangeness for a user who tests an
        operation on a superclass, and finds then happening differently
        in a subclass.

    That is exactly what the New Flavors ordering rules, as
    compared with either breadth-first or depth-first search, are
    intended to avoid.  It might be that there are cases where they
    don't avoid this problem, but I'd have to see a specific example. 

What are the class precedence list for the following
classes (flavors)

class	    Supers
F1       B C          
F2       A C          
F3       A B
F4       B A
          
G        F1 F2             
H        G F3
K        G F4         

In particular, what are the lists for G, H and K.

H and K must have A nd B in opposite orders.  Both have G as a super.
G doesn't care but must have some order.
 


-- danny

∂26-Sep-86  1330	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Re: Class Precedence List  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Sep 86  13:26:41 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 26 SEP 86 12:39:22 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa@XEROX.ARPA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 26 SEP 86 12:38:48 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 115970; Fri
 26-Sep-86 15:27:09 EDT
Date: Fri, 26 Sep 86 15:27 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Class Precedence List
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <860926-095028-5231@Xerox>
Message-ID: <860926152702.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 26 Sep 86 09:45 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

            The search I would be interested in is not the one
            where there are differences of order only, but ones in which a
            subclass has the classes in a different order than a super. 
            This could lead to strangeness for a user who tests an
            operation on a superclass, and finds then happening differently
            in a subclass.

        That is exactly what the New Flavors ordering rules, as
        compared with either breadth-first or depth-first search, are
        intended to avoid.  It might be that there are cases where they
        don't avoid this problem, but I'd have to see a specific example. 

    What are the class precedence list for the following
    classes (flavors)

    class    Supers     Components
    F1       B C        (F1 B C)
    F2       A C        (F2 A C)
    F3       A B        (F3 A B)
    F4       B A        (F4 B A)
          
    G        F1 F2      (G F1 B F2 A C)
    H        G F3       (H G F1 F2 F3 A B C)
    K        G F4       (K G F1 F2 F4 B A C)

    In particular, what are the lists for G, H and K.

I filled them into your message above, using a program of course.

I see; now I see what you meant by testing an operation on a
superclass and happening differently on a subclass.  G is the
superclass and H is the subclass.

    H and K must have A and B in opposite orders.  Both have G as a super.
    G doesn't care but must have some order.

That's right.  If the relative ordering of A and B matters, it
should have been declared explicitly, possibly using the
:component-order option (remember, that's one of the defflavor
options whose usefulness you couldn't see).  In fact in the very
many real cases where this happens that I enumerated the other
day, the relative ordering of A and B does not matter.  In this
particular specific example, the programmer who wrote F3 and F4
seems to have declared explicitly that the relative ordering of
A and B is immaterial.

The proposed extension from (I think) KMP that I mentioned the
other day is intended to provide automatic detection of whether
or not the relative ordering of A and B matters, instead of
making it the responsibility of the programmer to say whether
it matters.  My comments on that extension from the other day
still stand.

∂26-Sep-86  1635	Gregor.pa@Xerox.COM 	missing excl-low file   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Sep 86  16:34:57 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 26 SEP 86 13:43:17 PDT
Date: Fri, 26 Sep 86 13:36 PDT
From: Gregor.pa@Xerox.COM
Subject: missing excl-low file
To: CommonLoops.PA@Xerox.COM
Message-ID: <860926133653.2.GREGOR@AVALON.XEROX-PARC>
Line-fold: no


For some reason, the file excl-low.l was missing from the /pub/pcl
directory on parcvax.xerox.com.  That file now exists on that directory
so people who want to use PCL in Franz Common Lisp (ExCL) should have no
problems.

Gregor
-------

∂29-Sep-86  1328	Owners-commonloops.pa@Xerox.COM 	getting connected
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Sep 86  13:28:19 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 29 SEP 86 11:25:38 PDT
Return-Path: <DALY@IBM.COM>
Received: from IBM.COM ([192.5.58.7]) by Xerox.COM ; 29 SEP 86 11:15:57
 PDT
Date: 29 September 1986, 13:08:34 EDT
From: "Timothy P. Daly" <DALY@ibm.com>
To: commonloops.pa@Xerox.COM
Message-Id: <092986.130835.daly@ibm.com>
Subject: getting connected

Please add my name to the list of people receiving the common loops
discussions:

DALY@IBM.COM

Thanks.

∂29-Sep-86  1816	Hostrop.PA@Xerox.COM 	{eris}<Lispcore>...    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Sep 86  18:16:30 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 29 SEP 86 18:02:04 PDT
Date: 29 Sep 86 17:58:55 PDT (Monday)
From: Hostrop.PA@Xerox.COM
Subject: {eris}<Lispcore>...
To: Lispcore↑.pa@Xerox.COM, CommonLoopsCore↑.pa@Xerox.COM,
 AISTest↑.x@Xerox.COM
cc: , Hostrop.PA@Xerox.COM
Reply-To: Hostrop.PA@Xerox.COM
Message-ID: <860929-180204-1109@Xerox>


...has but 3664 pgs left - Those of you writing to this directory are
encouraged to pare out obsolete versions wherever it makes sense. Your
cooperation is greatly appreciated by all patrons of {eris}<Lispcore>.

∂30-Sep-86  1701	Owners-CommonLoops.PA@Xerox.COM 	Anybody know how objects are represented in PCL?    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Sep 86  17:00:59 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 30 SEP 86 16:53:49 PDT
Return-Path: <luis@ingres.Berkeley.EDU>
Received: from ingres.Berkeley.EDU ([128.32.156.105]) by Xerox.COM ; 30
 SEP 86 16:48:55 PDT
Received: by ingres.Berkeley.EDU (5.53/1.14)
 	id AA00872; Tue, 30 Sep 86 16:23:54 PDT
Date: Tue, 30 Sep 86 16:23:54 PDT
From: luis@ingres.Berkeley.EDU (Luis Miguel)
Message-Id: <8609302323.AA00872@ingres.Berkeley.EDU>
To: CommonLoops.PA@Xerox.COM
Subject: Anybody know how objects are represented in PCL?


	Is there an "object table" of some kind? (like the class
hash table). 
	
	What we want to do is to be able to "swap" objects in and out
of the system as they are needed (to an object database), and need to
know what the appropriate conversions need to be.

	Luis Miguel
	luis@ingres.Berkeley.EDU

∂06-Oct-86  1525	Bobrow.pa@Xerox.COM 	Taking the politics out of Standardization  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Oct 86  15:25:05 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 06 OCT 86 14:44:52 PDT
Date: 6 Oct 86 14:44 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Taking the politics out of Standardization
To: CommonLoopsCore↑.pa@Xerox.COM
cc: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861006-144452-4065@Xerox>

As we agreed on Friday, we will create a single document:

"       DRAFT

   A Proposed Specification
of a Common Lisp Object Standard"

   by (in alphabetical order)

D. Bobrow, L. DeMichiel, D. Gabriel, K. Kahn, S. Keene, G. Kiczales, L.
Masinter, D. Moon, D. Weinreb 

from (perhaps with footnote connections)
Lucid, Symbolics, Xerox

The document will be stored on SAIL (sail.stanford.edu)
on the area
   CLS,LST
   password: MIXIN
It will consist of merged and rewritten parts of both documents modified
to reflect our most recent technical decisions.    

The specification document will contain no history or explicit statement
of goals, but will provide a detailed technical description of the
current state of our understanding of the specification.  We hope to
have a version of this document available for the next ANSI X3J13
meeting, currently scheduled for December.  This implies having the
document ready for distribution to committee members in mid to late
November.

We would also like to have (at some time) a separate document describing
the rationale(s) for various decisions, and alternatives considered.


∂06-Oct-86  1658	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Taking the politics out of Standardization
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Oct 86  16:58:07 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 06 OCT 86 16:54:20 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 06 OCT 86 16:52:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 126666; Mon
 6-Oct-86 19:48:49 EDT
Date: Mon, 6 Oct 86 19:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Taking the politics out of Standardization
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <861006-144452-4065@Xerox>
Message-ID: <861006194832.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 6 Oct 86 14:44 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

    The document will be stored on SAIL (sail.stanford.edu)
    on the area
       CLS,LST
       password: MIXIN

I think the actual directory is CLS,LSP (not LST).

Symbolics people: SU-AI:name.type[CLS,LSP].  name is six characters,
type is three.  When it asks you to log in type CLS,LSP including
the comma.  We don't parse SU-AI pathnames, so you need to type
the .type every time you type a pathname or it will disappear.  The
directory disappears, too, but that's okay because you are logged in
to it.

∂06-Oct-86  2038	Owners-CommonLoops.PA@Xerox.COM 	Change of Address
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Oct 86  20:37:57 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 06 OCT 86 18:38:06 PDT
Return-Path: <Swenson.Multics@MIT-MULTICS.ARPA>
Received: from MIT-MULTICS.ARPA by Xerox.COM ; 06 OCT 86 18:32:11 PDT
Acknowledge-To:  "Eric J. Swenson" <Swenson@MIT-MULTICS.ARPA>
Date: Mon, 6 Oct 86 21:27 EDT
From: "Eric J. Swenson" <Swenson@MIT-MULTICS.ARPA>
Subject:  Change of Address
To: CommonLoops.PA@Xerox.COM
Message-ID:  <861007012741.131505@MIT-MULTICS.ARPA>

Would you please change my address from Swenson@multics.mit.edu to
ejs%acorn@live-oak.mit.edu?  Thank you.  (Sorry I sent this to this
address but mail to CommonLoops-Request failed.

∂06-Oct-86  2144	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Method Combinations   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Oct 86  21:44:02 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 06 OCT 86 21:27:00 PDT
Return-Path:
 <@MC.LCS.MIT.EDU:DUSSUD%Jenner%ti-csl.csnet@CSNET-RELAY.ARPA>
Redistributed: CommonLoopsCore↑.PA
Received: from MC.LCS.MIT.EDU by Xerox.COM ; 06 OCT 86 21:25:38 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  7 Oct 86 00:13:28 EDT
Received: from ti-csl by csnet-relay.csnet id ac01434; 6 Oct 86 18:51
 EDT
Received: from Jenner (jenner.ARPA) by tilde id AA01820; Mon, 6 Oct 86
 16:26:53 cdt
To:
 Common-Lisp-Classes-discussion%mc.lcs.mit.edu%csnet-relay.arpa@RELAY.CS.NET
Cc: 
Subject:        Method Combinations
Date: 6 Oct 86 16:24:33
From: DUSSUD%Jenner%ti-csl.CSNet@CSNet-Relay.ARPA
Message-Id:     <DUSSUD.2738006671@Jenner>

Dave,

I noticed that the method combination declaration (:method-combination)
is an option for DEFGENERIC and not for DEFCLASS.

What's the rationale?

Thanks,
Patrick.


∂07-Oct-86  0245	Owners-CommonLoops.PA@Xerox.COM 	missing excl-low file 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 7 Oct 86  02:44:57 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 07 OCT 86 01:29:52 PDT
Return-Path: <sob%soma.UUCP@rice.edu>
Received: from dione.rice.edu ([128.42.1.1]) by Xerox.COM ; 07 OCT 86
 01:26:10 PDT
Received: by dione.rice.edu (AA00874); Tue, 7 Oct 86 03:23:31 CDT
Received: by soma.BCM.TMC.EDU (4.13/sob/Gateway/09-22-86)
 	id AA01452; Tue, 7 Oct 86 03:13:24 CDT
Received: by seismo.CSS.GOV (5.54/1.14)
 	id AA07283; Fri, 26 Sep 86 19:44:05 EDT
Received: by beno.CSS.GOV (5.54/5.17)
 	id AA17460; Fri, 26 Sep 86 19:16:00 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 26 SEP 86 13:43:17 PDT
Date: Fri, 26 Sep 86 13:36 PDT
From: Xerox.COM!Gregor.pa%soma.UUCP@rice.edu
Subject: missing excl-low file
To: CommonLoops.PA@Xerox.COM
Message-Id: <860926133653.2.GREGOR@AVALON.XEROX-PARC>
Line-Fold: no


For some reason, the file excl-low.l was missing from the /pub/pcl
directory on parcvax.xerox.com.  That file now exists on that directory
so people who want to use PCL in Franz Common Lisp (ExCL) should have no
problems.

Gregor
-------

∂07-Oct-86  0245	Owners-CommonLoops.PA@Xerox.COM 	Anybody know how objects are represented in PCL?    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 7 Oct 86  02:45:06 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 07 OCT 86 01:37:47 PDT
Return-Path: <sob%soma.UUCP@rice.edu>
Received: from dione.rice.edu ([128.42.1.1]) by Xerox.COM ; 07 OCT 86
 01:36:21 PDT
Received: by dione.rice.edu (AA00973); Tue, 7 Oct 86 03:28:18 CDT
Received: by soma.BCM.TMC.EDU (4.13/sob/Gateway/09-22-86)
 	id AA01558; Tue, 7 Oct 86 03:14:47 CDT
Received: by beno.CSS.GOV (5.54/5.17)
 	id AA00830; Tue, 30 Sep 86 22:11:07 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 30 SEP 86 16:53:49 PDT
Return-Path: <luis@ingres.Berkeley.EDU>
Received: from ingres.Berkeley.EDU ([128.32.156.105]) by Xerox.COM ; 30
  SEP 86 16:48:55 PDT
Received: by ingres.Berkeley.EDU (5.53/1.14)
  	id AA00872; Tue, 30 Sep 86 16:23:54 PDT
Date: Tue, 30 Sep 86 16:23:54 PDT
From: ingres.Berkeley.EDU!luis%soma.UUCP@rice.edu (Luis Miguel)
Message-Id: <8609302323.AA00872@ingres.Berkeley.EDU>
To: CommonLoops.PA@Xerox.COM
Subject: Anybody know how objects are represented in PCL?


	Is there an "object table" of some kind? (like the class
hash table). 
	
	What we want to do is to be able to "swap" objects in and out
of the system as they are needed (to an object database), and need to
know what the appropriate conversions need to be.

	Luis Miguel
	luis@ingres.Berkeley.EDU

∂07-Oct-86  0244	Owners-commonloops.pa@Xerox.COM 	getting connected
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 7 Oct 86  02:44:46 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 07 OCT 86 01:27:56 PDT
Return-Path: <sob%soma.UUCP@rice.edu>
Received: from dione.rice.edu ([128.42.1.1]) by Xerox.COM ; 07 OCT 86
 01:25:47 PDT
Received: by dione.rice.edu (AA00885); Tue, 7 Oct 86 03:23:53 CDT
Received: by soma.BCM.TMC.EDU (4.13/sob/Gateway/09-22-86)
 	id AA01488; Tue, 7 Oct 86 03:13:50 CDT
Received: by seismo.CSS.GOV (5.54/1.14)
 	id AA06834; Mon, 29 Sep 86 16:10:30 EDT
Received: by beno.CSS.GOV (5.54/5.17)
 	id AA10940; Mon, 29 Sep 86 16:10:10 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 29 SEP 86 11:25:38 PDT
Return-Path: <DALY@IBM.COM>
Received: from IBM.COM ([192.5.58.7]) by Xerox.COM ; 29 SEP 86 11:15:57
  PDT
Date: 29 September 1986, 13:08:34 EDT
From: "Timothy P. Daly" <ibm.com!DALY%soma.UUCP@rice.edu>
To: commonloops.pa@Xerox.COM
Message-Id: <092986.130835.daly@ibm.com>
Subject: getting connected

Please add my name to the list of people receiving the common loops
discussions:

DALY@IBM.COM

Thanks.

∂07-Oct-86  1626	Gregor.pa@Xerox.COM 	Re: Anybody know how objects are represented in PCL?  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 7 Oct 86  16:26:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 OCT 86 13:38:37 PDT
Date: 7 Oct 86 13:32 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: Anybody know how objects are represented in PCL?
In-reply-to: ingres.Berkeley.EDU!luis%soma.UUCP@rice.edu (Luis Miguel)'s
 message of Tue, 30 Sep 86 16:23:54 PDT
To: ingres.Berkeley.EDU!luis%soma.UUCP@rice.edu
cc: CommonLoops.PA@Xerox.COM
Message-ID: <861007-133837-5205@Xerox>

    Date: Tue, 30 Sep 86 16:23:54 PDT
    From: ingres.Berkeley.EDU!luis%soma.UUCP@rice.edu (Luis Miguel)

    Is there an "object table" of some kind? (like the class
    hash table).

I am not sure what you mean by object table, but if you mean: "is there
a table which has each object which was ever created in it?".  The
answer is no.

    What we want to do is to be able to "swap" objects in and out
    of the system as they are needed (to an object database), and need
to
    know what the appropriate conversions need to be.

I am also not sure what you are asking here.  I get the impression that
you are trying to build some sort of permanent objects system, and that
you need to be able to dump and restore objects.  What I don't know is
why you need to know the internal representation of the instances to do
this.  If you want to look at the internal representation, you can look
in the file called low, but you should keep in mind that this
representation changes from release to release and that it is likely to
change across ports of PCL as well.

∂07-Oct-86  1920	Owners-CommonLoopsCore↑.PA@Xerox.COM 	Computing the class precedence list  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 7 Oct 86  19:20:46 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 07 OCT 86 18:38:42 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.PA@XEROX.ARPA
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 07 OCT 86 18:37:48 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 128089; Tue
 7-Oct-86 21:35:55 EDT
Date: Tue, 7 Oct 86 21:35 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Computing the class precedence list
To: CommonLoopsCore↑.PA@Xerox.COM
Message-ID: <861007213525.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

As promised on Friday, this message contains the algorithm used to
compute the precedence list in New Flavors, stripped down to make it
easier to read by removing irrelevant features and arguments, and
adjusted so that it should run in any Common Lisp implementation.  I
tried the one case given at the end, which returns the right answer, but
I haven't exhaustively tested for possible errors in transcription from
the algorithm we actually use.  I seriously doubt that there are any
transcription errors, though.

Summary of the functions contained:

  DEFCLASS1 -- fake version of DEFCLASS for testing purposes
  MAP-COMPONENTS-DEPTH-FIRST -- iteration driving function (also
	used by other parts of our system).  The full reasons for
	having this might not be obvious in the stripped down version.
  MAKE-PRECEDENCE-ALIST -- convert local constraints to the
	partial order, expressed as an alist
  COMPOSE-FLAVOR-COMPONENTS -- convert partial order to total order
  EXPLAIN-COMPONENT-ORDERING-ERROR -- auxiliary function, not included
	here, that contains a lot of hair for explaining precise
	details of conflicting constraints


(DEFMACRO DEFCLASS1 (NAME SUPERCLASSES)
  `(SETF (GET ',NAME 'CLASS-COMPONENTS) ',(REVERSE (CONS NAME SUPERCLASSES))))

;;; Iteration driver
;;; This calls FUNCTION for each component of FLAVOR-NAME at least once.  The arguments
;;; to FUNCTION are the name of the component flavor, the depth of recursion, a list
;;; of the names of all flavors that must locally precede this one (-not- a transitive
;;; closure of the precedence relations!).
;;; If FUNCTION returns NIL, iteration terminates without looking at components to right.
;;; If FUNCTION returns DONT-RECURSE, do younger brothers but not sons.
;;; Undefined components do not cause an error unless FUNCTION does not like them.
;;; The values returned by MAP-COMPONENTS-DEPTH-FIRST are meaningless to the outside caller.
(DEFUN MAP-COMPONENTS-DEPTH-FIRST (FUNCTION FLAVOR-NAME
				   &OPTIONAL (DEPTH 0) (PRECEDENCE NIL) (TRAIL NIL))
  (LET ((CONTINUE (FUNCALL FUNCTION FLAVOR-NAME DEPTH PRECEDENCE))
	(COMPONENTS (GET FLAVOR-NAME 'CLASS-COMPONENTS)))
    (UNLESS (OR (MEMBER CONTINUE '(NIL DONT-RECURSE))
		(MEMBER FLAVOR-NAME TRAIL))	;Break infinite recursion
      (LET ((TRAIL (CONS FLAVOR-NAME TRAIL)))
	;; Use recursion to iterate backwards through list
	(BLOCK RECURSE
	  (LABELS ((ITERATE (COMPONENTS)
		     (WHEN COMPONENTS
		       (LET ((COMPONENT (CAR COMPONENTS)))
			 (UNLESS (EQ COMPONENT FLAVOR-NAME)
			   (ITERATE (CDR COMPONENTS))
			   (UNLESS (MAP-COMPONENTS-DEPTH-FIRST FUNCTION
							       COMPONENT
							       (1+ DEPTH)
							       (CDR COMPONENTS)
							       TRAIL)
			     (RETURN-FROM RECURSE)))))))
	    (ITERATE COMPONENTS)))))
    CONTINUE))

;;; Make alist from component flavor to the components that must be to its left
;;; due to local constraints.  This is -not- the transitive closure of
;;; FLAVOR-LOCAL-COMPONENT-PRECEDENCE, but only the union of it; it's necessary
;;; not to compute the transitive closure here in order for the error reporting
;;; to be able to find cyclic constraints.
(DEFUN MAKE-PRECEDENCE-ALIST (FLAVOR-NAME)
  (LET ((ALIST NIL))
    (MAP-COMPONENTS-DEPTH-FIRST #'(LAMBDA (FLAVOR-NAME DEPTH PRECEDENCE)
				    (DECLARE (IGNORE DEPTH))
				    ;; Construct the union of everything preceding this flavor
				    (LET ((ELEM (ASSOC FLAVOR-NAME ALIST)))
				      (IF ELEM
					  (SETF (CDR ELEM) (UNION (CDR ELEM) PRECEDENCE))
					  (PUSH (CONS FLAVOR-NAME PRECEDENCE) ALIST)))
				    T)
				FLAVOR-NAME)
    (NREVERSE ALIST)))

;;; Compute the FLAVOR-ALL-COMPONENTS list, in the appropriate order.
;;; Check for and explain circular dependencies.
;;; Missing required-flavors and undefined component flavors are detected elsewhere.
(DEFUN COMPOSE-FLAVOR-COMPONENTS (FLAVOR-NAME)
  ;; First combine all the local ordering constraints.
  (LET ((ALIST (MAKE-PRECEDENCE-ALIST FLAVOR-NAME))
	(COMPONENTS NIL) CHANGED SLOW)
    ;; Start with a null components list; the given flavor will always be the first
    ;; component, because it will be the first one encountered by MAP-COMPONENTS-DEPTH-FIRST.
    ;; If there are circular constraints such that the given flavor has to have something
    ;; to its left, this will be detected, because no other flavor is unconstrained.
    ;; Using the local ordering constraints, build an ordered list of components by
    ;; repeated depth-first tree walk until all components have been incorporated that can be.
    ;; The tree walk is done in such an order as to minimize the number of iterations
    ;; through this loop required to come up with the answer.
    ;; SLOW = NIL is an optimization to cut off probably unreachable branches of the tree.
     (SETQ SLOW NIL)
     (LOOP
      (SETQ CHANGED NIL SLOW NIL)
      (MAP-COMPONENTS-DEPTH-FIRST
	#'(LAMBDA (FLAVOR-NAME DEPTH PRECEDENCE)
	    (DECLARE (IGNORE DEPTH PRECEDENCE))
	    (COND ((MEMBER FLAVOR-NAME COMPONENTS) T)	;Already a component, continue
		  ((NOT (ASSOC FLAVOR-NAME ALIST)) 'DONT-RECURSE)  ;Not really a component
		  ((EVERY #'(LAMBDA (PREDECESSOR) (MEMBER PREDECESSOR COMPONENTS))
			  (CDR (ASSOC FLAVOR-NAME ALIST)))
		   ;; This one can go in now, put it in and return T.
		   (PUSH FLAVOR-NAME COMPONENTS)
		   (SETQ CHANGED T))
		  ;; If above LOOP fails, return NIL since everything to right will fail too.
		  ;; But in SLOW mode, disable that optimization.
		  (T SLOW)))
	FLAVOR-NAME)
      (WHEN (NOT CHANGED)
	;; We seem to be done; make sure all components really got incorporated.
	(WHEN (= (LENGTH COMPONENTS) (LENGTH ALIST))
	  (RETURN))
	;; Some components didn't get incorporated.  Either there is an ordering
	;; conflict, or the speedup didn't work.  The speedup fails after recovery
	;; from a conflict, because the constraints are no longer transitive.  It
	;; also fails in the face of partial ordering among the components of a flavor.
	(IF SLOW
	    ;; Already slow: there must be an ordering conflict.
	    ;; Explain it nicely and recover by making an arbitrary choice.
	    (SETQ COMPONENTS (NRECONC (EXPLAIN-COMPONENT-ORDERING-ERROR FLAVOR-NAME ALIST
									COMPONENTS)
				      COMPONENTS))
	    ;; Try again without the speedup.
	    (SETQ SLOW T))))
    ;; Put list of components into normal order
    (NREVERSE COMPONENTS)))


;;;; Example

(DEFCLASS1 C1 ())
(DEFCLASS1 C2 ())
(DEFCLASS1 C3 ())
(DEFCLASS1 C4 (C1 C2))
(DEFCLASS1 C5 (C3 C2))
(DEFCLASS1 C6 (C4 C5))

(COMPOSE-FLAVOR-COMPONENTS 'C6)

∂08-Oct-86  1514	Bobrow.pa@Xerox.COM 	Re: Method Combinations 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Oct 86  15:14:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 86 14:54:02 PDT
Date: 8 Oct 86 14:53 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Method Combinations
In-reply-to: DUSSUD%Jenner@ti-csl.CSNET's message of 6 Oct 86 16:24:33
To: DUSSUD%Jenner%ti-csl.CSNet@CSNet-Relay.ARPA
cc: CommonLoopsCore↑.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861008-145402-6443@Xerox>

    I noticed that the method combination declaration
    (:method-combination) is an option for DEFGENERIC and not for
    DEFCLASS.

    What's the rationale?

method-combination is a property of the generic function.  It must be
uniform for all methods for a particular selector.  It is independent of
the class of any arguments used for method specification.   



-- danny

∂08-Oct-86  1559	Bobrow.pa@Xerox.COM 	Summary of Object Standard Discussions 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Oct 86  15:59:01 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 86 15:51:25 PDT
Date: 8 Oct 86 15:50 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Summary of Object Standard Discussions
In-reply-to: Bobrow.pa's message of 8 Oct 86 13:50 PDT
To: CommonLoopsCore↑.pa@Xerox.COM
From: Bobrow.pa@Xerox.COM, Gregor.pa@Xerox.COM
Message-ID: <861008-155125-6521@Xerox>

This is an impression of the basic structure of the agreements we
reached (and didn't) at the design review meetings in Oregon and Palo
Alto.  Please provide corrections.  The full details should appear in
the documents on Sail of course (and will be hashed out some more).
   

DEFSTRUCT and DEFCLASS

We agreed that DEFSTRUCT in CommonLisp was overloaded. It should be
replaced in Common Lisp by a DEFCLASS and DEFRECORD (name not agreed
on).
DEFCLASS defines classes of objects.  DEFRECORD defines
ways of using named accessors to fetch elements of lists, vectors, and
blocks of memory, and specialized ways of creating such items.

We agreed to recommend that DEFSTRUCT be eliminated from Common
Lisp and replaced with DEFCLASS and DEFRECORD  (most implementations
would continue to provide DEFSTRUCT for backwards compatibility).

---

DEFCLASS SYNTAX

(defclass <class-name> ({<super-name>}*)
   ({<slot-spec>}*)
   {(<option-name> {<option-argument>}*)}*)

<slot-spec> = <slot-name> | 
            (<slot-name> <init-value-form> 
              {<slot-option> <option-value>}*)

 
SLOT OPTIONS

slot-options include
:accessor <generic-fn-name>
:reader   <generic-fn-name>
   any number of readers and/or accessors can be specified
   Readers define no setf - 
  This contrasts with defining an error setf 
  Users can roll their own with defmethod-setf
   
:initable <key or nil> 
   if NIL then not initable
   Note that we we didn't resolve instance initialization protocol
   so the real meaning of this option was not determined.

:allocation  <one of :instance, :class, :dynamic, :none>

NOT AGREED (not discussed) Whether a slot can be specified with options
but no init-value-form

Declared :dynamic slots were discussed.  It was felt this was a
declaration of a time space tradeoff, and hence might not belong.

Undeclared :dynamic slots were discussed, and it was felt that making
the Common Lisp function GET be generic might provide a useful way of
getting and setting undeclared slots.  GET should also find declared
slots if they exist.  No agreement was reached on this.
 

DEFCLASS OPTIONS

(:metaclass class-name)
(:documentation doc-string)

(:accessors-with-prefix symbol-or-string)
(:readers-with-prefix symbol-or-string)

:accessors-with-prefix and :readers-with-prefix are independent of
slot-option specification.  Any number of any of these can be provided
-- a slot can
be given multiple accessors using this option.

Note that accessors are not generated by default.  One of the accessor
generating options (:accessors-with-prefix, :readers-with-prefix,
:accessor, :reader) must be specified for accessors to be generated.

(:constructor ...)
Like the constructor option in defstruct.  Precise behavior still to be
spec'd as part of specing initialization protocol

NOT AGREED
(:default-init-plist {<key> <value>}*)
  This is tied up with the initialization protocol.

REJECTED
  :initable-slots, (can be done using :initable slot-option only)
  :init-keywords (a declaration - not appropriate)

----
MAKE-INSTANCE

(make-instance <class> &rest keys-and-values)
(initialize <instance> &rest)

As mentioned above, we didn't specify the instance intialization
protcol.
A detailed proposal for when the default value forms are run, when the
:initable slots are done and what gets passed to initialize needs to be
sent
out.

---
SLOT-VALUE

We agreed to change the name of get-slot to slot-value.

----
DEFMETHOD

SYNTAX for DEFMETHOD is

(defmethod <generic-function-name> {name-qualifier}*
   <specialized-lambda-list> <decl-and-or-doc> form*)
(defmethod-setf <generic-function-name> {name-qualifier}*
   <specialized-lambda-list> <specialized-setf-vars> ...) 

name-qualifier is a non-null atom (or non-null symbol - NOT AGREED) used
in method-combination.  It is expected that most forms will have 0 or 1
of these name-qualifiers.

CLASSICAL SYNTAX
There will be no "classical method" syntax specified in the standard.

SPECIALIZED LAMBDA LIST
A specialized-lambda-list is a Common Lisp lambda-list where any
REQUIRED argument may be replaced by (arg-name arg-specializer).

An arg-specializer is intended to specify the type of the argument.
The generic function ensures that the method is only called if the
argument is of that type, or some subtype.

An arg-specializer is either a symbol or an expression 'datum.  The
symbol is interpreted as a class name.  We agreed to consider later
the extensions of arg-qualifiers to the entire CL type system (along
lines proposed by Moon in an earlier message).  

INDIVIDUAL METHODS
The form 'datum means that the argument must be bound to datum
for the method to be applicable.  (This is the syntax for "individual
methods") We recommend that the Common Lisp type system to be extended
to allow 'X to mean the same as (SATISFIES (MEMBER arg '(X)).

Individual type specifers are more specific than any other matching
type specifier for a datum.

METHOD ARGUMENT LIST CONGRUENCE
All methods of a generic function must have congruent argument lists.
Congruency is our word to imply that the system can tell whether a call
is syntactically correct.  The rules are:

1) Have the same number of required and optional arguments
2) Allow exactly the same keywords, or use &allow-other-keys
appropriately.
3) All have an &rest or not.


---
GENERIC FUNCTION Objects

There should be one object that is both funcallable and carries the
state that describes the generic function (e.g. the list of all the
method objects for this gf).  This object is side-effected by
generic-functions to add and remove methods, and its data and/or code
will change to reflect any operations.

---
DEFGENERIC

AGREED: 

- DEFGENERIC is NOT required before a method is defined on the
  generic function.

NOT AGREED:
 
- The name DEFGENERIC.


DEFGENERIC is intended to provide information about the contract of the
generic function, and can be evaluated any number of times.  It does not
affect existing methods on the generic function.  To make FOO undefined,
one evals
    (SETF (SYMBOL-FUNCTION 'FOO) NIL).
If a DEFGENERIC specifies a contract that is not congruent with the
current contract, it signals an error.  

A DEFMETHOD will create a generic function if one does not exist,
thus doing a DEFGENERIC with defaults. 

Syntax:
(defgeneric <gen-fn-name> <gen-fn-lambda-list> {<gf-option>}*)

(defgeneric-setf <gen-fn-name> <gen-fn-lambda-list>
   <setf-lambda-list> {<gf-option>}*)

The <gen-fn-lambda-list> is like an ordinary Common Lisp lambda-list
EXCEPT that 
1) optionals may not have default-forms or supplied-p
   and hence the symbol does not mean a default value
   of NIL.  Note that optionals in the methods can have
   default forms and supplied-p's.
2) key-args may not have default-forms or supplied-p
3) No aux variables

Note that the defgeneric passes to the methods exactly the arguments
it receives.  Thus the lambda list in the defgeneric is primarily for
specifying the "shape" of the generic function arguments with which
all the methods must be congruent.

&GENERIC-OPTIONAL

We discussed whether to allow this new keyword in the generic function
argument list.  It must appear before any other &key-words.  Arguemnts
appearing after it are required arguments for the methods.
&GENERIC-OPTIONAL allow specification of default-value forms to be
provided by the generic function before discriminating on the arguments.
No agreement was reached on this issue.  

GF-OPTIONS

(:documentation doc-string>)|string
(:argument-precedence-order <param-name>+)
   This is a permutation of the required args of gf-lambda-list.
(:generic-function-class class-name)
(:method-class class-name)

METHOD COMBINATION SPECIFICATION
We agreed that the method combination would be specified as a specific
option in the defgeneric, but the precise syntax of that option was not
decided.  

We discussed the general issue of the interaction of features specified
by options and the specification of the generic-function-class.  One
possibility is to make :generic-function-class argument be
(:generic-function-class class-name+) and interpret this as mixins with
GENERIC-FUNCTION class.  Specifically, method combination might be
specified as a mixin to the generic function class.


---
DYNAMIC CLASSES

Some support was evinced for a feature that would allow creation of
"dynamic classes", that is classes specified only by their supers.
Using
'(FOO FIE)  instead of a class-name would get or create a class defined
exactly by the mixins FOO and FIE.

No agreement was reached on this.

---
WITH-SLOTS
  We will have only one WITH-SLOTS form.

(with-slots ({car-name}|(var-name (keyword arg)*)) form*)

keywords are
:class class-name
:prefix string-or-symbol
:use-slot-value flag

Is it an error to have conflict of names?
Doing a SETF on var-name is not deemed to effect the meanings of the
slots.

We agreed to use SETF not SETQ in the specification to promote the style
of using setf.

---
INTERNAL MECHANISM OF WITH-SLOTS

We agreed to provide an interface to the code walker used by with-slots
so that people can define their own with-type macros (for encapsulation
or whatever).  A proposal for this needs to be sent out.

---
SETF on qualified variables.

We discussed whether the variables which were the specialized arguments
to the method should be considered as the "same bindings" which caused
the method lookup to call this method or a rebinding.

Less esoterically, the questions are:

Is is legal to setf the specialized arguments to a method.

If so, does this affect call-next-method.

AGREED:
  It is legal to setf the specialized arguments of a method.

  This does not affect call-next-method.


---

DEFINE-METHOD-COMBINATION

We agreed to continue working to simplify and learn how best to explain
declarative method combination.

Moon presented a simplification of define-method-combination which also
allows the implementation of call-next-method.  He will send that to the
entire list.

AGREED: The default type of method combination will allow  primary,
call-next-method and :before and :after methods.

NOT AGREED whether :around methods are in the default, and whether they
are provided for all method-combination types.  


 

"commonloopscore↑.pa"@xerox/su
Summary of Object Standard Discussions 

About DEFGENERIC.

I certainly did not agree that a defgeneric was not required before any
DEFMETHODs. What I agreed to, and what I carefully restated every time
someone tried to tranform my statement into an agreement statement, was
that the first step in convincing me to not require a defining statement
for a generic function to appear before any DEFMETHODs is to rename
DEFGENERIC to something else. That is, if we are not going to require such
a defining statement, we should not have an operator with a name that says
``I, sir, am the very defining statement you might think you have to make,
but actually do not.''

Moon said this in his message:

``If you make the generic function FOO f-unbound and then do a DEFMETHOD
  or DEFGENERIC for FOO, you get a new generic-function object that
  doesn't know about any of the methods for the old FOO.  Those methods
  are gone ... so the data structure would be inconsistent....  There
  could be other inconsistencies too.''

If generic functions are first-class, and if we've decided that this
first-class object (which comprises the generic function along with the
methods on it) is stored in the function cell, then FMAKUNBOUNDing it
is what you do when your intention is to `get a new generic-function
object that doesn't know about any of the <old> methods.''

I think this means that Moon did not understand what we agreed to. A
first-class generic function is the thing that you funcall to get the
generic behavior and that has the methods logically inside it. When you
drop the last pointer to the generic function object, the garbage
collector can grab it away. When you do n DEFMETHODs on FOO, the function
cell for FOO is the only thing that logically has a pointer to the generic
function associated with the name FOO. If FMAKUNBOUND does not flush every
old method, and data structures end up inconsistent, then there is a bug
in your implementation.

			-rpg-
∂08-Oct-86  1817	Owners-commonloopscore↑.pa@Xerox.COM 	new files on CLS,LSP on SAIL    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Oct 86  18:17:04 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 08 OCT 86 18:15:22 PDT
Return-Path: <LGD@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 08 OCT 86
 18:15:03 PDT
Date: 08 Oct 86 18:14 PDT
From: Linda DeMichiel <LGD@SAIL.STANFORD.EDU>
Subject: new files on CLS,LSP on SAIL 
To: commonloopscore↑.pa@Xerox.COM 
Message-ID: <861008-181522-6748@Xerox>


I have placed the following files out on CLS,LSP:

concepts.tex, concepts.dvi
functions.tex, functions.dvi
impact.tex, impact.dvi
glossary.tex, glossary.dvi
design.tex, design.dvi
template.tex
macros.tex
various .toc and .tc files

The concepts.* files contain the contents of the first half of
the spec that Danny, Gregor, Dick and I drafted.
The functions.* files contain the second half; they also include some
of the changes we agreed upon last weekend.  Template.tex is
an outline for an individual function page that can be spliced into
functions.tex.

Impact.tex is an empty template for the discussion of how our
specification affects existing Common Lisp functions and how it
may influence modification of Common Lisp.

Glossary.tex is an empty template for our glossary.

Design.tex is an empty template for a discussion of the design
rationale behind the specification.

Macros.tex is the macros file used by TEX.

The concepts, functions, impact, glossary, and design files
are currently set up to generate five chapters of a document
called the "Common Lisp Object System Specification."  As we
discussed, we will probably want to make separate documents
for the presentation of the design rationale and meta-object
protocol.  I have set the files up the current way primarily so
that they can be easy to work with for now and easy to shuffle
into or out of other documents later on.

The .toc and .tc files are used by TEX to generate individual
tables of contents.  If you are concerned about up-to-the-minute
accuracy of the table of contents pages of file foo, then you
should tex foo, copy foo.toc to foo.tc, and tex foo again;
if you don't care, just ignore these files.  The .idx and .fig
files can also be ignored.

Linda

∂09-Oct-86  1505	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Summary of Object Standard Discussions    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Oct 86  15:05:22 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 09 OCT 86 14:28:05 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 09 OCT 86 14:27:42 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 130440; Thu
 9-Oct-86 17:26:13 EDT
Date: Thu, 9 Oct 86 17:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Summary of Object Standard Discussions
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <861008-155125-6521@Xerox>
Message-ID: <861009172529.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 8 Oct 86 15:50 PDT
    From: Bobrow.pa@Xerox.COM, Gregor.pa@Xerox.COM

    This is an impression of the basic structure of the agreements we
    reached (and didn't) at the design review meetings in Oregon and Palo
    Alto.  Please provide corrections.

I cross-checked this against my notes.  For brevity, I've deleted portions
of your message where I had nothing to add.

    DEFCLASS SYNTAX

    (defclass <class-name> ({<super-name>}*)
       ({<slot-spec>}*)
       {(<option-name> {<option-argument>}*)}*)

    <slot-spec> = <slot-name> | 
		(<slot-name> <init-value-form> 
		  {<slot-option> <option-value>}*)

We forgot to discuss whether the syntax for <slot-spec>
is that one or the following, which I think is cleaner:
<slot-spec> = <slot-name> | 
              (<slot-name> <init-value-form>) |
              (<slot-name> {<slot-option> <option-value>}*)
with a :default-value <slot-option>.  Any objections?

    SLOT OPTIONS
    ...   
    :initable <key or nil> 
       if NIL then not initable

We did not discuss allowing NIL here.  I don't see any reason
for it; none of the other slot options allow NIL.  As with the
accessors the default should be that it's not initable unless
you say something to make it initable.

       Note that we we didn't resolve instance initialization protocol
       so the real meaning of this option was not determined.

True.

    DEFCLASS OPTIONS
    ....
    (:accessors-with-prefix symbol-or-string)
    (:readers-with-prefix symbol-or-string)

I think you mean :accessor-prefix and :reader-prefix, don't you?
Except for the names this agrees with my notes.

    REJECTED
      :initable-slots, (can be done using :initable slot-option only)

It doesn't say in my notes that this is rejected, only that giving it
with a list of slot names is rejected.  My notes also say that we
rejected the idea that the environment should have an editor command to
automatically put in the :initable slot-options.  So I'm not sure what
we decided about this.  I take it the problem is that you don't want to
build in the convention that keyword symbols (same as Common Lisp
defstruct) rather than slot names (same as Zetalisp defstruct) are used
to initialize the slots?

      :init-keywords (a declaration - not appropriate)

I don't know what you mean by "a declaration", but this will fall
out of resolving instance initialization.

The initialization protocol has to be worked out carefully in the
light of the method argument list congruence rules for &key arguments.
Or vice versa.

    SYNTAX for DEFMETHOD is

    (defmethod <generic-function-name> {name-qualifier}*
       <specialized-lambda-list> <decl-and-or-doc> form*)
    (defmethod-setf <generic-function-name> {name-qualifier}*
       <specialized-lambda-list> <specialized-setf-vars> ...) 

I don't like the term "name-qualifier"; the word "name" here is just a
noise word.  My notes just say "qualifier".  Plain "qualifier", with
"method qualifier" used when method context is not obvious, would be
better than "name-qualifier".

    SPECIALIZED LAMBDA LIST
    A specialized-lambda-list is a Common Lisp lambda-list where any
    REQUIRED argument may be replaced by (arg-name arg-specializer).

We need to be careful to be consistent with CLtL in the use of the
words "argument", "arg", and "parameter".

    INDIVIDUAL METHODS
    The form 'datum means that the argument must be bound to datum
    for the method to be applicable.  (This is the syntax for "individual
    methods") We recommend that the Common Lisp type system to be extended
    to allow 'X to mean the same as (SATISFIES (MEMBER arg '(X)).

I think we have to require that, not recommend it, otherwise parameter
specializers would not be a subset of type specifiers.

(SATISFIES (MEMBER arg '(X)) is not a valid CL type specifier;
you meant to say (MEMBER x).

My notes say we agreed that the funny Common Loops exception to the
normal argument-precedence-order for methods on individuals won't fly.

The method argument list congruence rules have to be stated very
precisely, especially the parts involving &key.  I guess I can
take another try at that later this week if no one else has.

    DEFGENERIC
    To make FOO undefined, one evals
	(SETF (SYMBOL-FUNCTION 'FOO) NIL).
No, you mean (FMAKUNBOUND 'FOO).  I don't think we discussed this enough.

If you make the generic function FOO f-unbound and then do a DEFMETHOD
or DEFGENERIC for FOO, you get a new generic-function object that
doesn't know about any of the methods for the old FOO.  Those methods
are gone (except in the PCL meta-object protocol class-direct-methods
would still know about those methods, so the data structure would be
inconsistent).  There could be other inconsistencies too.  In New
Flavors currently you get the same generic-function object back again,
to avoid inconsistencies similar to these.  Perhaps making f-unbound a
generic function should not be a defined operation in the standard?

    If a DEFGENERIC specifies a contract that is not congruent with the
    current contract, it signals an error.  

We didn't discuss this, if my notes are complete.  I assume you mean it
only signals an error if there are methods whose parameters are not
congruent with the new defgeneric's parameters.  That's okay; at this
point the program development environment comes into play, so we
shouldn't say any more.

My notes say "we need to write up clearly the about four ways thought up
so far to extend this to discriminating on optional/keyword arguments",
but don't say that any particular person took responsibility.

    (:argument-precedence-order <param-name>+)
       This is a permutation of the required args of gf-lambda-list.

RPG said JonL has a proposal for a better way to do this, but I don't
think any of us have seen it yet.  It should be written up and sent to
the mailing list.

    WITH-SLOTS
    (with-slots ({car-name}|(var-name (keyword arg)*)) form*)

Change <var-name> to <instance>, an expression that evaluates to an
instance.  No reason to limit the possible expressions to variables.
The expression is evaluated exactly once.  According to my notes we
agreed on that.

    We agreed to use SETF not SETQ in the specification to promote the style
    of using setf.

My notes don't say that.  They say we agreed after discussing this and
other similar topics that we weren't writing a prescriptive style manual
for Common Lisp.

I actually think it would be better to do the opposite; if SETQ works inside
of WITH-SLOTS it should be used in examples, otherwise people who half-understand
how it is implemented will think that SETQ doesn't work and only SETF can be used
to set the slot pseudovariables that WITH-SLOTS creates.

Other things in my notes:

We agreed that calling CHANGE-CLASS inside of a method or inside of a
WITH-SLOTS can cause semantic problems and also implementation problems.
Semantic problems if the methods or slots you're already working with
are no longer applicable.  Implementation problems if the slots move
around in the memory layout of the instance.  We left it that we need to
work over the mail on the detailed description of when CHANGE-CLASS is
and is not valid.

We will recommend but not require that compiling a file containing
defclass, defgeneric, and defmethod forms does not side-effect the
Lisp world in which the compiler is running.

We agreed that in the default type of method combination, if there
are :before, :after, or :around methods, but no primary method, that
signals an error instead of assuming a primary method that returns NIL.

According to my notes we agreed that defmethod puts in type declarations
for the specialized parameters.  I don't remember agreeing on that,
but why not.

We need better terminology for:
  "argument specifier" -- looks like we settled on "parameter specializer"
  "standard-type-class" or "primitive class" or "builtin class"

The proliferation of -setf functions (e.g. remove-method-setf) is getting
disturbing and maybe we need an explicit notion of the generic function
objects that do setfs.

I'm working on writing up the current state of the define-method-combination
syntax discussion, but I don't know if I'll finish that today.

∂09-Oct-86  1544	Owners-commonloopscore↑.pa@Xerox.COM 	Summary of Object Standard Discussions    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Oct 86  15:44:29 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 OCT 86 15:41:11 PDT
Return-Path: <RPG@SAIL.STANFORD.EDU>
Redistributed: commonloopscore↑.pa
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 09 OCT 86
 15:40:53 PDT
Date: 09 Oct 86 15:40 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Summary of Object Standard Discussions 
To: commonloopscore↑.pa@Xerox.COM 
Message-ID: <861009-154111-1088@Xerox>


About DEFGENERIC.

I certainly did not agree that a defgeneric was not required before any
DEFMETHODs. What I agreed to, and what I carefully restated every time
someone tried to tranform my statement into an agreement statement, was
that the first step in convincing me to not require a defining statement
for a generic function to appear before any DEFMETHODs is to rename
DEFGENERIC to something else. That is, if we are not going to require such
a defining statement, we should not have an operator with a name that says
``I, sir, am the very defining statement you might think you have to make,
but actually do not.''

Moon said this in his message:

``If you make the generic function FOO f-unbound and then do a DEFMETHOD
  or DEFGENERIC for FOO, you get a new generic-function object that
  doesn't know about any of the methods for the old FOO.  Those methods
  are gone ... so the data structure would be inconsistent....  There
  could be other inconsistencies too.''

If generic functions are first-class, and if we've decided that this
first-class object (which comprises the generic function along with the
methods on it) is stored in the function cell, then FMAKUNBOUNDing them
is what you do when your intention is to `get a new generic-function
object that doesn't know about any of the <old> methods.''

I think this means that Moon did not understand what we agreed to. A
first-class generic function is the thing that you funcall to get the
generic behavior and that has the methods logically inside it. When you
drop the last pointer to the generic function object, the garbage
collector can grab it away. When you do n DEFMETHODs on FOO, the function
cell for FOO is the only thing that logically has a pointer to the generic
function associated with the name FOO. If FMAKUNBOUND does not flush every
old method, and data structures end up inconsistent, then there is a bug
in your implementation.

			-rpg-

∂09-Oct-86  1615	Owners-commonloopscore↑.pa@Xerox.COM 	"Classes" Document and Agreements Summary 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Oct 86  16:14:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 OCT 86 16:09:05 PDT
Return-Path: <kempf%hplabsc@hplabs.HP.COM>
Redistributed: commonloopscore↑.pa
Received: from hplabs.HP.COM ([192.5.58.10]) by Xerox.COM ; 09 OCT 86
 16:02:53 PDT
Received: from hplabsc by hplabs.HP.COM ; Thu, 9 Oct 86 15:56:54 pdt
Received: by hplabsc ; Thu, 9 Oct 86 15:55:24 pdt
Date: Thu, 9 Oct 86 15:55:24 pdt
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8610092255.AA05179@hplabsc>
To: common-lisp-classes-discussion@mc.lcs.mit.edu,
 commonloopscore↑.pa@Xerox.COM
Subject: "Classes" Document and Agreements Summary
Cc: snyder%hplabsc@hplabs.HP.COM

I read through the "Classes" document in detail, and the executive
summary posted by Danny on Oct. 8. Below is a list of detailed
questions, comments, and corrections which I noticed. There are
several meta-comments, however, which I've summarized at the top
to remove them from the chaff. I plan to get the updated documents
off of Sail and will post any additional comments, as needed.
I hope you'll keep us posted about progress, we've got a lot of
applications people here who are interested in the result. I'll
also post comments on the MetaObject Protocol in the Xerox document
as I get a chance to read through it. I hope these comments can
be of some help. It looks like the standard is starting to shape
up. 
	Jim Kempf		kempf@hplabs

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

METACOMMENTS

*"Classes" sounds like an excellent name! 

*With reference to pgs. 9  and 39 in the "Classes" document, 
it would seem that there may be some cases where a user-defined
class might want to inherit from a built-in class. The canonical
example is the class STREAM which one might want to have as the
parent for the class WINDOW in an object-oriented window system.
This would also be a reason to have a class for STREAM, instead
of excluding it, as on pg. 39. Has anyone given thought to how
this would fit in with the proposed CommonWindows standard?

*Does method combination go through the generic function or
through the method itself? If the former, then couldn't method
combination be done using macros? If the latter, then obviously
not. What is the relation between method combination and
DEFGENERIC? Couldn't the :INTERFACE keyword argument to DEFGENERIC
be used to achieve the same effect with somewhat less cognitive 
complexity? In general, I support an effort to make method
combination easier to use and understand. There seems to be
a good deal of power in the idea, but it needs to be better 
integrated with generic functions. See also the comments below
about defining a new class of generic functions.

*The convention for including documentation strings in this
document seems to deviate from the CLtL standard. Is this
a good idea?

*The user-accessable hook to the code walker looks like a
good idea. We'll be interested in seeing the result, though
it might be more appropriate as part of the MetaObject
protocol, since its primary use would seem to be in defining
new metaclasses.

COMMENTS (page numbers reference the "Classes" document)

pg. 5-CLASS-OF/TYPE-OF relationship needs some clarification
for instance objects. What will TYPE-OF return when applied
to an instance object? See comment below on TYPEP

pg. 5-:CLASS option-Is this for class slots? If so, it seems
to be a retraction of some earlier discussion about doing
this in the metaclass. What about inheritance of class
slots? Are seperate copies of class state maintained in
the super and subclass objects or not?

pg. 7-Presumably (TYPE-OF <object>) -> <class-name> for
TYPEP to work correctly?

pg. 7-How is automatic updating of instances done when it is
redefined? Are there any hooks for user defined transformation
of instance state? For class state (re. :CLASS option above)?
Is there some way for a user to override this? Consider the
case of developing extensions to a programming environment
while using the environment. One might not want old instances
of a redefined class to be updated, if the behavior of the
redefined class was not yet solid; otherwise, the environment
might break.

pg. 9-Couldn't :DYNAMIC be done with a subobject. That is, couldn't
one have a slot into which an object with the necessary state was
inserted when required, rather than have the extra slots added
to the object (basically, an Occam's Razor argument)?

pg. 10-The defaults for these options are listed at the end of the
paper. Shouldn't they be here? In particular, for the access 
functions.

pg. 12-MAKE-INSTANCE as a generic function could potentially conflict
with the lambda list congruency test, unless initialization is 
done by a seperate, class specific function (ie. with the class
name as the prefix).

pg. 14-The term "setf-lambda-list" appears to be used differently in
the middle and at the end of the page. In the middle, the term means
a qualified list, at the end, not.

pg. 15-DECLARE should be :DECLARE, and "affect" should be "effect"
(nit-picky English).

pg. 15-For the :ARGUMENT-PRECEDENCE-ORDER, what happens if not
all the parameters are included?

pg. 16-How is :GENERIC-FUNCTION-CLASS different from :INTERFACE?
That is, why would anyone what to define a different generic
function class rather than simply use a different interface definition?
Same comment goes for method combination (as mentioned in the
METACOMMENTS section).

pg. 17-I presume the :CLASS option was included so that lambda
list parameters which were not qualified could be opened up using
the WITH-SLOTS special form. If so, then why allow super class names
as well? Isn't it rather more appropriate to have the name following
:CLASS designate a class or any subclass, as with the class qualifiers
in the lambda list? And what if the parameter isn't of that class
at runtime?

pg. 18-Does CALL-NEXT-METHOD do the same thing as the current
RUN-SUPER in PCL?

pg. 19-Why not have PRINT simply be a generic function? Also, why
not have EQUALP (and perhaps EQUAL, and EQL as well) be generic
functions? This would allow programmers to define their own
notions of equality for two instances, and could come in handy
when objects have circularity.

pg. 21-Need some overview about what method combination is
and some simple examples of when it would come in handy.
Also, a simple glossery of terms, as at the beginning
of the document. Such terms as "primary method" are used
without definition.

pg. 21-What is :PRETTY-NAME used for?

pg. 21-To what extend does the parameter list differ
from DEFMACRO?

pg. 23-24-Some explanation of how these examples work
would be helpful. Also, aren't keywords self evaluating?
If so, then why quote them in the examples?

pg. 24-LOOP is not (yet) standard CL. Should probably
be replaced by something that is.

pg. 26-Must a generic function be defined before 
DEFINE-METHOD-COMBINATION is evaluated? Must all
the mentioned methods? Any of them?

pg. 27-What are the internal arguments mentioned in
the paragraph after the CALL-COMPONENT-METHOD syntax
description?

pg. 32-There is a typo at the top of the page. The
second instance of (PIE CINNAMON APPLE) should be
(PASTRY CINNAMON APPLE).

pg. 37-The default info. here is good, but should
be moved up to where the options are defined.

pg. 39-STREAM might want to have a class associated
with it, for reasons cited in the METACOMMENTS
section.

∂09-Oct-86  1637	RPG   	Summary of Object Standard Discussions
 ∂09-Oct-86  1505	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Summary of Object Standard Discussions    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Oct 86  15:05:22 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 09 OCT 86 14:28:05 PDT
Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 09 OCT 86 14:27:42 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 130440; Thu
 9-Oct-86 17:26:13 EDT
Date: Thu, 9 Oct 86 17:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Summary of Object Standard Discussions
To: CommonLoopsCore↑.pa@Xerox.COM
In-Reply-To: <861008-155125-6521@Xerox>
Message-ID: <861009172529.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 8 Oct 86 15:50 PDT
    From: Bobrow.pa@Xerox.COM, Gregor.pa@Xerox.COM

    This is an impression of the basic structure of the agreements we
    reached (and didn't) at the design review meetings in Oregon and Palo
    Alto.  Please provide corrections.

I cross-checked this against my notes.  For brevity, I've deleted portions
of your message where I had nothing to add.

    DEFCLASS SYNTAX

    (defclass <class-name> ({<super-name>}*)
       ({<slot-spec>}*)
       {(<option-name> {<option-argument>}*)}*)

    <slot-spec> = <slot-name> | 
		(<slot-name> <init-value-form> 
		  {<slot-option> <option-value>}*)

We forgot to discuss whether the syntax for <slot-spec>
is that one or the following, which I think is cleaner:
<slot-spec> = <slot-name> | 
              (<slot-name> <init-value-form>) |
              (<slot-name> {<slot-option> <option-value>}*)
with a :default-value <slot-option>.  Any objections?

    SLOT OPTIONS
    ...   
    :initable <key or nil> 
       if NIL then not initable

We did not discuss allowing NIL here.  I don't see any reason
for it; none of the other slot options allow NIL.  As with the
accessors the default should be that it's not initable unless
you say something to make it initable.

       Note that we we didn't resolve instance initialization protocol
       so the real meaning of this option was not determined.

True.

    DEFCLASS OPTIONS
    ....
    (:accessors-with-prefix symbol-or-string)
    (:readers-with-prefix symbol-or-string)

I think you mean :accessor-prefix and :reader-prefix, don't you?
Except for the names this agrees with my notes.

    REJECTED
      :initable-slots, (can be done using :initable slot-option only)

It doesn't say in my notes that this is rejected, only that giving it
with a list of slot names is rejected.  My notes also say that we
rejected the idea that the environment should have an editor command to
automatically put in the :initable slot-options.  So I'm not sure what
we decided about this.  I take it the problem is that you don't want to
build in the convention that keyword symbols (same as Common Lisp
defstruct) rather than slot names (same as Zetalisp defstruct) are used
to initialize the slots?

      :init-keywords (a declaration - not appropriate)

I don't know what you mean by "a declaration", but this will fall
out of resolving instance initialization.

The initialization protocol has to be worked out carefully in the
light of the method argument list congruence rules for &key arguments.
Or vice versa.

    SYNTAX for DEFMETHOD is

    (defmethod <generic-function-name> {name-qualifier}*
       <specialized-lambda-list> <decl-and-or-doc> form*)
    (defmethod-setf <generic-function-name> {name-qualifier}*
       <specialized-lambda-list> <specialized-setf-vars> ...) 

I don't like the term "name-qualifier"; the word "name" here is just a
noise word.  My notes just say "qualifier".  Plain "qualifier", with
"method qualifier" used when method context is not obvious, would be
better than "name-qualifier".

    SPECIALIZED LAMBDA LIST
    A specialized-lambda-list is a Common Lisp lambda-list where any
    REQUIRED argument may be replaced by (arg-name arg-specializer).

We need to be careful to be consistent with CLtL in the use of the
words "argument", "arg", and "parameter".

    INDIVIDUAL METHODS
    The form 'datum means that the argument must be bound to datum
    for the method to be applicable.  (This is the syntax for "individual
    methods") We recommend that the Common Lisp type system to be extended
    to allow 'X to mean the same as (SATISFIES (MEMBER arg '(X)).

I think we have to require that, not recommend it, otherwise parameter
specializers would not be a subset of type specifiers.

(SATISFIES (MEMBER arg '(X)) is not a valid CL type specifier;
you meant to say (MEMBER x).

My notes say we agreed that the funny Common Loops exception to the
normal argument-precedence-order for methods on individuals won't fly.

The method argument list congruence rules have to be stated very
precisely, especially the parts involving &key.  I guess I can
take another try at that later this week if no one else has.

    DEFGENERIC
    To make FOO undefined, one evals
	(SETF (SYMBOL-FUNCTION 'FOO) NIL).
No, you mean (FMAKUNBOUND 'FOO).  I don't think we discussed this enough.

If you make the generic function FOO f-unbound and then do a DEFMETHOD
or DEFGENERIC for FOO, you get a new generic-function object that
doesn't know about any of the methods for the old FOO.  Those methods
are gone (except in the PCL meta-object protocol class-direct-methods
would still know about those methods, so the data structure would be
inconsistent).  There could be other inconsistencies too.  In New
Flavors currently you get the same generic-function object back again,
to avoid inconsistencies similar to these.  Perhaps making f-unbound a
generic function should not be a defined operation in the standard?

    If a DEFGENERIC specifies a contract that is not congruent with the
    current contract, it signals an error.  

We didn't discuss this, if my notes are complete.  I assume you mean it
only signals an error if there are methods whose parameters are not
congruent with the new defgeneric's parameters.  That's okay; at this
point the program development environment comes into play, so we
shouldn't say any more.

My notes say "we need to write up clearly the about four ways thought up
so far to extend this to discriminating on optional/keyword arguments",
but don't say that any particular person took responsibility.

    (:argument-precedence-order <param-name>+)
       This is a permutation of the required args of gf-lambda-list.

RPG said JonL has a proposal for a better way to do this, but I don't
think any of us have seen it yet.  It should be written up and sent to
the mailing list.

    WITH-SLOTS
    (with-slots ({car-name}|(var-name (keyword arg)*)) form*)

Change <var-name> to <instance>, an expression that evaluates to an
instance.  No reason to limit the possible expressions to variables.
The expression is evaluated exactly once.  According to my notes we
agreed on that.

    We agreed to use SETF not SETQ in the specification to promote the style
    of using setf.

My notes don't say that.  They say we agreed after discussing this and
other similar topics that we weren't writing a prescriptive style manual
for Common Lisp.

I actually think it would be better to do the opposite; if SETQ works inside
of WITH-SLOTS it should be used in examples, otherwise people who half-understand
how it is implemented will think that SETQ doesn't work and only SETF can be used
to set the slot pseudovariables that WITH-SLOTS creates.

Other things in my notes:

We agreed that calling CHANGE-CLASS inside of a method or inside of a
WITH-SLOTS can cause semantic problems and also implementation problems.
Semantic problems if the methods or slots you're already working with
are no longer applicable.  Implementation problems if the slots move
around in the memory layout of the instance.  We left it that we need to
work over the mail on the detailed description of when CHANGE-CLASS is
and is not valid.

We will recommend but not require that compiling a file containing
defclass, defgeneric, and defmethod forms does not side-effect the
Lisp world in which the compiler is running.

We agreed that in the default type of method combination, if there
are :before, :after, or :around methods, but no primary method, that
signals an error instead of assuming a primary method that returns NIL.

According to my notes we agreed that defmethod puts in type declarations
for the specialized parameters.  I don't remember agreeing on that,
but why not.

We need better terminology for:
  "argument specifier" -- looks like we settled on "parameter specializer"
  "standard-type-class" or "primitive class" or "builtin class"

The proliferation of -setf functions (e.g. remove-method-setf) is getting
disturbing and maybe we need an explicit notion of the generic function
objects that do setfs.

I'm working on writing up the current state of the define-method-combination
syntax discussion, but I don't know if I'll finish that today.

∂09-Oct-86  1709	Bobrow.pa@Xerox.COM 	Re: Summary of Object Standard Discussions  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Oct 86  17:08:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 OCT 86 17:04:35 PDT
Date: 9 Oct 86 17:04 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Summary of Object Standard Discussions 
To: commonloopscore↑.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861009-170435-1178@Xerox>

(Response to RPG)
    About DEFGENERIC.

    I certainly did not agree that a defgeneric was not required
    before any DEFMETHODs. What I agreed to, and what I carefully
    restated every time someone tried to tranform my statement into an
    agreement statement, was that the first step in convincing me to
    not require a defining statement for a generic function to appear
    before any DEFMETHODs is to rename DEFGENERIC to something else.

We certainly agreed to disagree about the name of this.  How about
the name DESCRIBE-GENERIC.  If all the things said about DEFGENERIC 
in my note had DESCRIBE-GENERIC for DEFGENERIC, then would you agree
DESCRIBE-GENERIC was done implicily by each DEFMETHOD, and the user 
could give a DESCRIBE-GENERIC to obtain a non-default generic function?

(Response to Moon)
    If you make the generic function FOO f-unbound and then do a
    DEFMETHOD or DEFGENERIC for FOO, you get a new generic-function
    object that doesn't know about any of the methods for the old FOO. 
    Those methods are gone (except in the PCL meta-object protocol
    class-direct-methods would still know about those methods, so the
    data structure would be inconsistent).

What data structure is inconsistent.  If one did
(DEFMETHOD FOO ((X c1))...)
(DEFMETHOD FOO ((X c2))...)
(SETQ ZZ (SYMBOL-FUNCTION FOO))
(SETF (SYMBOL-FUNCTION 'FOO) NIL) 
   or (FMAKUNBOUND 'FOO)  ;; I don't understand the difference
Then ZZ is bound to a funcallable object (a generic function) that will
indeed call the first method on an instance of c1. It is also be the
case that a "name" generated for the user for the first method may be
confusing. Doing the two DEFMETHODS again will indeed create a new
generic-function object stored in the symbol function cell of FOO.
The methods will be different, and both stored in the
class-direct-methods of the class c1. This implies perhaps that we need
some protocol for destroying generic-function objects that removes
things from class-direct-methods.

    My notes don't say that.  They say we agreed after discussing
    this and other similar topics that we weren't writing a
    prescriptive style manual for Common Lisp.

My memory was that although we were not writing a prescriptive style
manual we agreed that SETQ was a bad historical holdover, and that by
example we were going to encourage the other style.

     <slot-spec> = <slot-name> | 
                  (<slot-name> <init-value-form>) | (<slot-name>
                  {<slot-option> <option-value>}*)
    with a :default-value <slot-option>.  Any objections?

I don't like those nasty four words (it is an error) about
non-initialized variables.  If we want uninitialized variables, then
this syntax is fine with me.

        :initable <key or nil>  if NIL then not initable

    We did not discuss allowing NIL here.  I don't see any reason
    for it; none of the other slot options allow NIL.  As with the
    accessors the default should be that it's not initable unless you
    say something to make it initable.

How about programs generating structures.  For them, a NIL might be
appropriate. But the initialization protocol should be worked out.  I
prefer slot names to be used as keys rather than keywords in any event
if we have any default.

    I don't like the term "name-qualifier"; the word "name" here is
    just a noise word.  My notes just say "qualifier".  Plain
    "qualifier", with "method qualifier" used when method context is
    not obvious, would be better than "name-qualifier".

"qualifier" is fine -- both are better than "option"

    My notes say we agreed that the funny Common Loops exception to
    the normal argument-precedence-order for methods on individuals
    won't fly.

Agreed.

        If a DEFGENERIC specifies a contract that is not
        congruent with the current contract, it signals an error.  

    We didn't discuss this, if my notes are complete.  I assume you
    mean it only signals an error if there are methods whose parameters
    are not congruent with the new defgeneric's parameters.  That's
    okay; at this point the program development environment comes into
    play, so we shouldn't say any more.
There may be other problems between DESCRIBE-GENERICs.  Should users be
able to change method-combination or generic-function class?  Perhaps.

        WITH-SLOTS
        (with-slots ({var-name}|
                 (var-name (keyword arg)*)) form*)

    Change <var-name> to <instance>, an expression that evaluates
    to an instance.  No reason to limit the possible expressions to
    variables. The expression is evaluated exactly once.  According to
    my notes we agreed on that.

I remember thinking that this was consistent, but that we had not yet
agreed to this extension.  It is OK with me.  Of course it makes sense
only if :class is specified explicitly, and that would have to be said.
No type inference machinery except for variable-names declared in the
method lambda-list.  

    According to my notes we agreed that defmethod puts in type
    declarations for the specialized parameters.  I don't remember
    agreeing on that, but why not.

I don't know what this means?

    The proliferation of -setf functions (e.g. remove-method-setf)
    is getting disturbing and maybe we need an explicit notion of the
    generic function objects that do setfs.

Should we go back to
  (defmethod (:setf foo) ...)
since qualifiers are not around the name.


DOCUMENTATION
  When are pieces of the Symbolics document appearing on SAIL?  Can
someone summarize for me what agreements on writing and combining were
reached.

-- danny

∂09-Oct-86  1811	Owners-CommonLoopsCore↑.PA@Xerox.COM 	"Classes" Document and Agreements Summary 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Oct 86  18:11:38 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 OCT 86 18:09:39 PDT
Return-Path: <@MC.LCS.MIT.EDU:kempf%hplabsc@hplabs.HP.COM>
Redistributed: CommonLoopsCore↑.PA
Received: from MC.LCS.MIT.EDU by Xerox.COM ; 09 OCT 86 18:09:09 PDT
Received: from hplabs.HP.COM by MC.LCS.MIT.EDU  9 Oct 86 21:08:50 EDT
Received: from hplabsc by hplabs.HP.COM ; Thu, 9 Oct 86 15:56:54 pdt
Received: by hplabsc ; Thu, 9 Oct 86 15:55:24 pdt
Date: Thu, 9 Oct 86 15:55:24 pdt
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8610092255.AA05179@hplabsc>
To: common-lisp-classes-discussion@mc.lcs.mit.edu,
 commonloopscore↑.pa@Xerox.COM
Subject: "Classes" Document and Agreements Summary
Cc: snyder%hplabsc@hplabs.HP.COM

I read through the "Classes" document in detail, and the executive
summary posted by Danny on Oct. 8. Below is a list of detailed
questions, comments, and corrections which I noticed. There are
several meta-comments, however, which I've summarized at the top
to remove them from the chaff. I plan to get the updated documents
off of Sail and will post any additional comments, as needed.
I hope you'll keep us posted about progress, we've got a lot of
applications people here who are interested in the result. I'll
also post comments on the MetaObject Protocol in the Xerox document
as I get a chance to read through it. I hope these comments can
be of some help. It looks like the standard is starting to shape
up. 
	Jim Kempf		kempf@hplabs

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

METACOMMENTS

*"Classes" sounds like an excellent name! 

*With reference to pgs. 9  and 39 in the "Classes" document, 
it would seem that there may be some cases where a user-defined
class might want to inherit from a built-in class. The canonical
example is the class STREAM which one might want to have as the
parent for the class WINDOW in an object-oriented window system.
This would also be a reason to have a class for STREAM, instead
of excluding it, as on pg. 39. Has anyone given thought to how
this would fit in with the proposed CommonWindows standard?

*Does method combination go through the generic function or
through the method itself? If the former, then couldn't method
combination be done using macros? If the latter, then obviously
not. What is the relation between method combination and
DEFGENERIC? Couldn't the :INTERFACE keyword argument to DEFGENERIC
be used to achieve the same effect with somewhat less cognitive 
complexity? In general, I support an effort to make method
combination easier to use and understand. There seems to be
a good deal of power in the idea, but it needs to be better 
integrated with generic functions. See also the comments below
about defining a new class of generic functions.

*The convention for including documentation strings in this
document seems to deviate from the CLtL standard. Is this
a good idea?

*The user-accessable hook to the code walker looks like a
good idea. We'll be interested in seeing the result, though
it might be more appropriate as part of the MetaObject
protocol, since its primary use would seem to be in defining
new metaclasses.

COMMENTS (page numbers reference the "Classes" document)

pg. 5-CLASS-OF/TYPE-OF relationship needs some clarification
for instance objects. What will TYPE-OF return when applied
to an instance object? See comment below on TYPEP

pg. 5-:CLASS option-Is this for class slots? If so, it seems
to be a retraction of some earlier discussion about doing
this in the metaclass. What about inheritance of class
slots? Are seperate copies of class state maintained in
the super and subclass objects or not?

pg. 7-Presumably (TYPE-OF <object>) -> <class-name> for
TYPEP to work correctly?

pg. 7-How is automatic updating of instances done when it is
redefined? Are there any hooks for user defined transformation
of instance state? For class state (re. :CLASS option above)?
Is there some way for a user to override this? Consider the
case of developing extensions to a programming environment
while using the environment. One might not want old instances
of a redefined class to be updated, if the behavior of the
redefined class was not yet solid; otherwise, the environment
might break.

pg. 9-Couldn't :DYNAMIC be done with a subobject. That is, couldn't
one have a slot into which an object with the necessary state was
inserted when required, rather than have the extra slots added
to the object (basically, an Occam's Razor argument)?

pg. 10-The defaults for these options are listed at the end of the
paper. Shouldn't they be here? In particular, for the access 
functions.

pg. 12-MAKE-INSTANCE as a generic function could potentially conflict
with the lambda list congruency test, unless initialization is 
done by a seperate, class specific function (ie. with the class
name as the prefix).

pg. 14-The term "setf-lambda-list" appears to be used differently in
the middle and at the end of the page. In the middle, the term means
a qualified list, at the end, not.

pg. 15-DECLARE should be :DECLARE, and "affect" should be "effect"
(nit-picky English).

pg. 15-For the :ARGUMENT-PRECEDENCE-ORDER, what happens if not
all the parameters are included?

pg. 16-How is :GENERIC-FUNCTION-CLASS different from :INTERFACE?
That is, why would anyone what to define a different generic
function class rather than simply use a different interface definition?
Same comment goes for method combination (as mentioned in the
METACOMMENTS section).

pg. 17-I presume the :CLASS option was included so that lambda
list parameters which were not qualified could be opened up using
the WITH-SLOTS special form. If so, then why allow super class names
as well? Isn't it rather more appropriate to have the name following
:CLASS designate a class or any subclass, as with the class qualifiers
in the lambda list? And what if the parameter isn't of that class
at runtime?

pg. 18-Does CALL-NEXT-METHOD do the same thing as the current
RUN-SUPER in PCL?

pg. 19-Why not have PRINT simply be a generic function? Also, why
not have EQUALP (and perhaps EQUAL, and EQL as well) be generic
functions? This would allow programmers to define their own
notions of equality for two instances, and could come in handy
when objects have circularity.

pg. 21-Need some overview about what method combination is
and some simple examples of when it would come in handy.
Also, a simple glossery of terms, as at the beginning
of the document. Such terms as "primary method" are used
without definition.

pg. 21-What is :PRETTY-NAME used for?

pg. 21-To what extend does the parameter list differ
from DEFMACRO?

pg. 23-24-Some explanation of how these examples work
would be helpful. Also, aren't keywords self evaluating?
If so, then why quote them in the examples?

pg. 24-LOOP is not (yet) standard CL. Should probably
be replaced by something that is.

pg. 26-Must a generic function be defined before 
DEFINE-METHOD-COMBINATION is evaluated? Must all
the mentioned methods? Any of them?

pg. 27-What are the internal arguments mentioned in
the paragraph after the CALL-COMPONENT-METHOD syntax
description?

pg. 32-There is a typo at the top of the page. The
second instance of (PIE CINNAMON APPLE) should be
(PASTRY CINNAMON APPLE).

pg. 37-The default info. here is good, but should
be moved up to where the options are defined.

pg. 39-STREAM might want to have a class associated
with it, for reasons cited in the METACOMMENTS
section.

∂10-Oct-86  1601	Owners-CommonLoopsCore↑.pa@Xerox.COM 	Classes document available on SAIL   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Oct 86  16:01:26 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 10 OCT 86 15:25:59 PDT
Return-Path: <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Redistributed: CommonLoopsCore↑.pa
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
 Xerox.COM ; 10 OCT 86 15:25:27 PDT
Received: from JUNCO.SCRC.Symbolics.COM by
 STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 131545; Fri
 10-Oct-86 18:14:24 EDT
Date: Fri, 10 Oct 86 18:13 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Classes document available on SAIL
To: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <861010181313.1.SKEENE@JUNCO.SCRC.Symbolics.COM>
Line-fold: No


I transferred the file containing the Classes document over to
"classes.txt" on the CLS,LSP directory at SAIL.    It's in a format that
should be easy for you all to read, although the page breaks are
probably wrong for printers.  

I expect to get to work on Tuesday to start merging my pieces of the
Classes document into the files that Linda set up.    This has been a
busy week for us here, and I haven't had a chance to get started on it
yet.    


∂10-Oct-86  1601	Bobrow.pa@Xerox.COM 	Computing the class precedence list    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Oct 86  16:01:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 OCT 86 15:51:00 PDT
Date: 10 Oct 86 15:51 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Computing the class precedence list
To: CommonLoopsCore↑.pa@Xerox.COM
cc: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861010-155100-1243@Xerox>

Another way of explaining class precedence list.

The class precedence list is a left to right, depth first linearization
of the transitive closure of inheritance from the local super classes of
a class.  It satisfies three constraints:

Constraint-0) A class appears only once in the list
Constraint-1) A class always precedes in the list all its local super
classes
Constraint-2) The order of the local supers is preserved

Stating C1 and C2 slightly differently:

C-1-2) A class must follow any class it is a direct super of,
         or any class it follows in a local-supers list. 

The class precedence can be constructed in three steps.

1) Walk the inheritance tree in left to right depth first order,
recording all super classes in the order visited.

2) Remove duplicates, preserving the last occurrence of any class.
  (This can actually be combined with step 1 without extra consing.).

3) Traverse the resluting list from left to right. If for any class c1,
there is a class to its right that c1 should follow (by C-1-2), move c1
to the right of the rightmost such class.

If any class needs to be moved a second time, it means there is a loops
of constraints that cannot be satisfied.  

∂10-Oct-86  1601	Gregor.pa@Xerox.COM 	yaccpla (yet another compute class precedence list algorithm)   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Oct 86  16:01:39 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 10 OCT 86 15:59:10 PDT
Date: Fri, 10 Oct 86 15:58 PDT
From: Gregor.pa@Xerox.COM
Subject: yaccpla (yet another compute class precedence list algorithm)
To: CommonLoopsCore↑.pa@Xerox.COM
Message-ID: <861010155847.2.GREGOR@AVALON.XEROX-PARC>
Line-fold: no


This code implements a compute-class-precedence-list algorithm the many
and varied features of which Danny will describe in a separate message.

Using this changed defclass1 macro you can try it on all the same
examples as the other algorithm.

(DEFMACRO DEFCLASS1 (NAME SUPERCLASSES)
  `(progn (SETF (GET ',NAME 'CLASS-COMPONENTS) ',(REVERSE (CONS NAME SUPERCLASSES)))
	  (setf (get ',name 'supers) ',superclasses)))


(defun compute-class-precedence-list (class)
  (let ((cpl ())
	(must-precede-alist ()))
    ;; We start by computing two values.
    ;;   CPL
    ;;     The depth-first left-to-right up to joins walk of the supers tree.
    ;;   MUST-PRECEDE-ALIST
    ;;     An alist of the must-precede relations. The car of each element of the
    ;;;    must-precede-alist is a class, the cdr is all the classes which must
    ;;     precede that class in the CPL.
    ;;
    ;; Note that the actual walk is breadth-first, right-to-left.
    ;;
    (labels ((walk-supers (class &optional precedence)
	       (format t "~% ~S ~S" class precedence)
	       (let ((elem (assoc class must-precede-alist)))
		 (if elem
		     (setf (cdr elem) (nunion (cdr elem) precedence))
		     (push (cons class precedence) must-precede-alist)))
	       (let* ((rsupers (reverse (cons class (get class 'supers))))
		      (precedence (cdr rsupers)))
		 (do ((sup rsupers (cdr sup))
		      (pre precedence (cdr pre)))
		     ((null pre))
		   (walk-supers (car sup) pre)))
	       (unless (member class cpl) (push class cpl))))
      (walk-supers class)
      ;; For each class in the cpl, make sure that there are no classes after it which
      ;; should be before it.  We do this by cdring down the list, making sure that for
      ;; each element of the list, none of its must-precedes come after it in the list.
      ;; We use a hand-coded loop so that we can splice things in and out of the CPL as
      ;; we go.
      (let ((tail cpl)
	    (element nil)
	    (move nil)
	    (moves nil))
	(loop (when (null tail) (return))
	      (setq element (car tail)
		    move nil)
	      (dolist (must-precede (cdr (assoc element must-precede-alist)))
		;; This hairy setq does the following:
		;;   The outer OR means if you have already found a MOVE, don't drop it
		;;   unless you find another move.
		;;   The inner OR means once you have found a move, only look for another
		;;   move that comes after it.
		;; The result is that we look for the farthest possible move.
		(setq move (or (member must-precede (or move
							(cdr tail)))
			       move)))
	      (when move
		(when (member element moves)
		  (EXPLAIN-class-ORDERING-ERROR class MUST-PRECEDE-ALIST cpl))
		(push element moves)
		(setf (cdr move) (cons element (cdr move)))
		(setf (car tail) (cadr tail))	;OK to use Interlisp delete trick since it
		(setf (cdr tail) (cddr tail)))	;will never be the last element of the list.
	      (setq tail (cdr tail)))
	(copy-list cpl)))))
-------

∂13-Oct-86  1823	RPG  	Greetings
To:   common-lisp-object-system@SAIL.STANFORD.EDU    

This mailing list is the replacement for

commonloopscore↑.pa@xerox.com

You can mail to it using the address

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

The request address is

common-lisp-object-system-request@sail.stanford.edu

				-rpg-

∂13-Oct-86  1832	Bobrow.pa@Xerox.COM 	Re: Summary of Object Standard Discussions (Repeat of last 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Oct 86  18:31:49 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 OCT 86 18:30:34 PDT
Date: 13 Oct 86 18:31 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Summary of Object Standard Discussions (Repeat of last
 week) 
To: common-lisp-object-system@SAIL.STANFORD.EDU
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861013-183034-1785@Xerox>

(Response to RPG)
    About DEFGENERIC.

    I certainly did not agree that a defgeneric was not required
    before any DEFMETHODs. What I agreed to, and what I carefully
    restated every time someone tried to tranform my statement into an
    agreement statement, was that the first step in convincing me to
    not require a defining statement for a generic function to appear
    before any DEFMETHODs is to rename DEFGENERIC to something else.

We certainly agreed to disagree about the name of this.  How about
the name DESCRIBE-GENERIC.  If all the things said about DEFGENERIC 
in my note had DESCRIBE-GENERIC for DEFGENERIC, then would you agree
DESCRIBE-GENERIC was done implicily by each DEFMETHOD, and the user 
could give a DESCRIBE-GENERIC to obtain a non-default generic function?

(Response to Moon)
    If you make the generic function FOO f-unbound and then do a
    DEFMETHOD or DEFGENERIC for FOO, you get a new generic-function
    object that doesn't know about any of the methods for the old FOO. 
    Those methods are gone (except in the PCL meta-object protocol
    class-direct-methods would still know about those methods, so the
    data structure would be inconsistent).

What data structure is inconsistent.  If one did
(DEFMETHOD FOO ((X c1))...)
(DEFMETHOD FOO ((X c2))...)
(SETQ ZZ (SYMBOL-FUNCTION FOO))
(SETF (SYMBOL-FUNCTION 'FOO) NIL) 
   or (FMAKUNBOUND 'FOO)  ;; I don't understand the difference
Then ZZ is bound to a funcallable object (a generic function) that will
indeed call the first method on an instance of c1. It is also be the
case that a "name" generated for the user for the first method may be
confusing. Doing the two DEFMETHODS again will indeed create a new
generic-function object stored in the symbol function cell of FOO.
The methods will be different, and both stored in the
class-direct-methods of the class c1. This implies perhaps that we need
some protocol for destroying generic-function objects that removes
things from class-direct-methods.

    My notes don't say that.  They say we agreed after discussing
    this and other similar topics that we weren't writing a
    prescriptive style manual for Common Lisp.

My memory was that although we were not writing a prescriptive style
manual we agreed that SETQ was a bad historical holdover, and that by
example we were going to encourage the other style.

     <slot-spec> = <slot-name> | 
                  (<slot-name> <init-value-form>) | (<slot-name>
                  {<slot-option> <option-value>}*)
    with a :default-value <slot-option>.  Any objections?

I don't like those nasty four words (it is an error) about
non-initialized variables.  If we want uninitialized variables, then
this syntax is fine with me.

        :initable <key or nil>  if NIL then not initable

    We did not discuss allowing NIL here.  I don't see any reason
    for it; none of the other slot options allow NIL.  As with the
    accessors the default should be that it's not initable unless you
    say something to make it initable.

How about programs generating structures.  For them, a NIL might be
appropriate. But the initialization protocol should be worked out.  I
prefer slot names to be used as keys rather than keywords in any event
if we have any default.

    I don't like the term "name-qualifier"; the word "name" here is
    just a noise word.  My notes just say "qualifier".  Plain
    "qualifier", with "method qualifier" used when method context is
    not obvious, would be better than "name-qualifier".

"qualifier" is fine -- both are better than "option"

    My notes say we agreed that the funny Common Loops exception to
    the normal argument-precedence-order for methods on individuals
    won't fly.

Agreed.

        If a DEFGENERIC specifies a contract that is not
        congruent with the current contract, it signals an error.  

    We didn't discuss this, if my notes are complete.  I assume you
    mean it only signals an error if there are methods whose parameters
    are not congruent with the new defgeneric's parameters.  That's
    okay; at this point the program development environment comes into
    play, so we shouldn't say any more.
There may be other problems between DESCRIBE-GENERICs.  Should users be
able to change method-combination or generic-function class?  Perhaps.

        WITH-SLOTS
        (with-slots ({var-name}|
                 (var-name (keyword arg)*)) form*)

    Change <var-name> to <instance>, an expression that evaluates
    to an instance.  No reason to limit the possible expressions to
    variables. The expression is evaluated exactly once.  According to
    my notes we agreed on that.

I remember thinking that this was consistent, but that we had not yet
agreed to this extension.  It is OK with me.  Of course it makes sense
only if :class is specified explicitly, and that would have to be said.
No type inference machinery except for variable-names declared in the
method lambda-list.  

    According to my notes we agreed that defmethod puts in type
    declarations for the specialized parameters.  I don't remember
    agreeing on that, but why not.

I don't know what this means?

    The proliferation of -setf functions (e.g. remove-method-setf)
    is getting disturbing and maybe we need an explicit notion of the
    generic function objects that do setfs.

Should we go back to
  (defmethod (:setf foo) ...)
since qualifiers are not around the name.


DOCUMENTATION
  When are pieces of the Symbolics document appearing on SAIL?  Can
someone summarize for me what agreements on writing and combining were
reached.

-- danny

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


-- danny

∂13-Oct-86  2206	LGD  	new object system spec files 
To:   common-lisp-object-system@SAIL.STANFORD.EDU    
There is a new version of functi.tex and all files derived from it on
[CLS,LSP] on SAIL. The old tex source file has been renamed to functi.1.  

Linda

∂13-Oct-86  2333	Owners-CommonLoopsInternal↑.x@Xerox.COM 	Mailing list addition   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Oct 86  23:33:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 OCT 86 23:29:27 PDT
Return-Path: <@SAIL.STANFORD.EDU:SMITCHELL@USC-ECL.ARPA>
Redistributed: CommonLoopsInternal↑.x
Received: from SAIL.STANFORD.EDU (SU-AI.ARPA) by Xerox.COM ; 13 OCT 86
 23:28:22 PDT
Received: from USC-ECL.ARPA by SAIL.STANFORD.EDU with TCP; 13 Oct 86
 23:09:23 PDT
Date: Mon, 13 Oct 86 23:08:58 PDT
From: "Steve Mitchell" <SMITCHELL@USC-ECL.ARPA>
Subject: Mailing list addition
To: cl-object-oriented-programming@SU-AI.ARPA
cc: ailist-request@SRI-STRIPE.ARPA, nl-kr-request@ROCHESTER.ARPA,
 smitchell@USC-ECL.ARPA
Message-ID: <12246648417.53.SMITCHELL@USC-ECL.ARPA>


Please add me to your mailing list.  Thanks in advance!

Steven Mitchell
smitchell@usc-ecl.arpa
-------

∂14-Oct-86  0754	skeene@STONY-BROOK.SCRC.Symbolics.COM 	Re: Summary of Object Standard Discussions (Repeat of last   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 Oct 86  07:53:39 PDT
Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 132678; Tue 14-Oct-86 10:17:10 EDT
Date: Tue, 14 Oct 86 10:15 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Summary of Object Standard Discussions (Repeat of last
         week) 
To: Bobrow.pa@Xerox.COM
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <861013-183034-1785@Xerox>
Message-ID: <861014101523.7.SKEENE@JUNCO.SCRC.Symbolics.COM>
Line-fold: No

    Date: 13 Oct 86 18:31 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

    DOCUMENTATION
      When are pieces of the Symbolics document appearing on SAIL?   Can 
    someone summarize for me what agreements on writing and combining were
    reached.

    -- danny

Sure.   Here's a summary of what we decided will happen with the 
documentation.   There will be 3 documents that will go together.  The
title and authors are as you noted in an earlier message.  The outline
of the first document follows, and you'll see that the writing is split 
up more or less evenly between Lucid (L) and Symbolics (S).  

Part I:  Progammer's Interface 

Part II:  Meta Object Protocol
  
   We see this as a separate document.   We have not yet discussed
   anything specific about this document, except that it needs to be
   written.  

Part III:  Design Rationale

   This is another separate document.  It will include the reasons
   underlying certain design decisions.   

   We will all be adding to this document as we go along.   To start,
   I'm going to put in sections from the "Classes" document.

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

Part I:  Progammer's Interface 

	  1  Introduction (brief, no history) (L)
	  2  Concepts
		Classes (L)
		  -Defining classes
		  -Structure of class objects (slots)
		  -Creating instances
		  -Superclasses
		  -Inheritance
		  -Class precedence (brief)
		  -Accessing slots
		  -Types and Classes
		Generic Functions and Methods (S)
		  -Compare g-f's and ordinary functions
		  -Defining generic functions
		  -Defining methods
		Method Selection (S)
		Method Combination (S)
		Class Precedence List (S)
		Meta Objects (L)
		   -Metaclass
		   -Method class
		   -Generic function class

	   3  Alphabetic List of Functions 
		
[Each function page has the following fields:  Purpose, Syntax,
Arguments, Example, Remarks, See Also] 
 
[We are going to merge existing documentation from both the Lucid
and the Symbolics documents.   Some of the documentation must be revised
according to the discussions we had.] 

		add-method (L)
		argument-precedence-order (L)
		call-next-method (S)
		change-class (L)
		class-of (L)
		defclass (S)
		defgeneric (S)
		defgeneric-setf (S)
		define-method-combination (S) (and related functions)
		defmethod (S)
		defmethod-setf (S)
		function-parameters (L)
		generic-function-p (L)
		get-method (L)
		lambda-list-argument-specifiers (L)
		make-generic (L)	
		make-instance (L)
		method-combination (L)
		remove-class (L) [under discussion]
		remove-method (L)
		remove-setf-method (L)
		slot-value (L) 
		with-slots (S)

	   4  Existing CL Functions that Need to Change 

		describe (S)
		documentation (L)
		print-object (S)
		
	   5  Glossary 


∂14-Oct-86  1659	RPG  	Anonymous Generic Function Proposal    
To:   common-lisp-object-system@SAIL.STANFORD.EDU    

Here are a series of proposals for making anonymous generic functions
in a pleasant way. There are three sorts of non-named-by-symbol generic
function forms we need to define: pure anonymous, LABELS equivalent, and
FLET equivalent. There is probably only one reasonable way to define
anonymous generic functions:

#'(generic-lambda <method-spec>*)

where <method-spec> is

	(<qualified lambda list> . <body>)

For example:

#'(generic-lambda
   (((x1 c1)(x2 c2)) (foo x1 x2))
   (((x1 c3) (x2 c4)) (baz x1 x2)))

The two remaining cases are for LABELS and FLET equivalents.
GENERIC-FUNCTION-LABELS corresponds to LABELS and GENERIC-FLET corresponds
to FLET. These names are negotiable.

For each of GENERIC-FUNCTION-LABELS and GENERIC-FLET there are two
possible styles, called the modular and the distributed styles. In the
modular style:

(generic-function-labels (<generic-function-spec>*) . <body>)

where <generic-function-spec> is

(<generic-function-name> <method-spec>*)

where the <method-spec> is as above. Here is an example:

(generic-function-labels
 ((gf1
   ;;; First method on gf1
   (((x1 c1) (x2 c2)) (when (recursivep x1) (gf1 (f1 x1) (f2 x2))))
   ;;; Second method on gf1
   (((x1 c3) (x2 c3)) (when (recursivep x1) (gf2 (f3 x1) (f4 x2)))))
  (gf2
   ;;; First method on gf2
   (((x1 c4)(x2 c5)) (gf1 (f5 x1) (f6 x2)))
   ;;; Second method on gf2
   (((x1 c6)(x2 c7)) (gf2 (f7 x1)(f8 x2)))))
 ;;; Now we use these guys
 (gf1 x1 y1) ... (gf2 xn yn))

The distributed style looks like this:

(generic-function-labels (<named-method-spec>*) . <body>)

where <named-method-spec> is

(<generic-function-name> <method-spec>)

Here is an example:

(generic-function-labels
 ;;; First method on gf1
 ((gf1 ((x1 c1) (x2 c2)) (when (recursivep x1) (gf1 (f1 x1) (f2 x2))))
  ;;; Second method on gf1
  (gf1 ((x1 c3) (x2 c3)) (when (recursivep x1) (gf2 (f3 x1) (f4 x2))))
  ;;; First method on gf2
  (gf2 ((x1 c4)(x2 c5)) (gf1 (f5 x1) (f6 x2)))
  ;;; Second method on gf2
  (gf2 ((x1 c6)(x2 c7)) (gf2 (f7 x1)(f8 x2))))
 ;;; Now we use these guys
 (gf1 x1 y1) ... (gf2 xn yn))

The GENERIC-FLET admits both modular and distributed styles, which
I won't show.

I'm not sure which I favor. Of course, one can ADD-METHOD to any of
these generic functions.

I made an assumption when devising these, which was that it is not
possible for a method to call another method without the intervention
of a generic function.  In this case, a hairier reference scheme is
needed.

			-rpg-

∂14-Oct-86  1849	Gregor.pa@Xerox.COM 	Re: Anonymous Generic Function Proposal     
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Oct 86  18:49:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 14 OCT 86 17:29:17 PDT
Date: 14 Oct 86 17:29 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: Anonymous Generic Function Proposal    
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 14 Oct 86
 16:59 PDT
To: RPG@SAIL.STANFORD.EDU
cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
Message-ID: <861014-172917-2958@Xerox>

For some reason, your message had no "To:" field on it when it got to
me.  I assume it was to this list.

These are interesting syntaxes for making anonymous generic functions.

But this doesn't address what I think is an important issue.  Namely,
what does generic-function-lables really mean?

Clearly, it defines a lexical scope in which the symbol "names" a
generic function with the given method.  But what does it mean if at the
time that scope is entered dynamically, the global function cell of the
symbol has a generic function in it?

 1. Should the global generic function have the lexical methods added to
it within the lexical scope?

 2. Or should there just be a whole new generic function within that
lexical scope?  This generic function just has the methods specified in
the gf-labels form.

Clearly #2 is much easier to implement, but is it the semantics we want?

Given the names you chose (as opposed to mlet and mlabels) I would
**guess** that you implicitly favor #2.

I had always thought that we would do something like #1, but I haven't
thought about it hard enough to know if it makes sense.

∂15-Oct-86  0751	RPG  	Anonymous Generic Functions  
To:   common-lisp-object-system@SAIL.STANFORD.EDU    

Having 3 minutes until I rush to the airport, let me elaborate slightly
on my proposal.

The reason for anonymous generic functions is the same reason for
anonymous functions. The user wants to define a locally known
generic function without the possibility of other methods
leaking in. The compiler can optimize it better because it can
see everything, etc, etc. It gives a complete unit with name
references entirely local to the definition. 

Early on, the small minds didn't think FLET and LABELS would be useful,
but I see lots of user code, and lots of implementor code, using them
everywhere.

The generic-function-labels construct builds a generic function
which has nothing to do with any symbols. The methods are in the generic
function object. Presumably the construct logically does a MAKE-GENERIC and
some ADD-METHODS. It behaves with respect to symbol-function cells the
way that DEFUN and LABELS behave:

(defmethod foo (x)(format t "Hm, the global definition?~%"))

(generic-function-labels
 ((foo (x) (format t "Hah, the right thing!~%")))
 (foo 7))

=> Hah, the right thing!


			-rpg-

∂15-Oct-86  1312	@MC.LCS.MIT.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COM 	"Classes" Document and Agreements Summary 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Oct 86  13:12:26 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM by MC.LCS.MIT.EDU 15 Oct 86 14:43:11 EDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 134062; Wed 15-Oct-86 14:37:11 EDT
Date: Wed, 15 Oct 86 14:35 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: "Classes" Document and Agreements Summary
To: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
cc: common-lisp-classes-discussion@mc.lcs.mit.edu,
    snyder%hplabsc@hplabs.HP.COM
In-Reply-To: <8610092255.AA05179@hplabsc>
Message-ID: <861015143540.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 9 Oct 86 15:55:24 pdt
    From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>

    *With reference to pgs. 9  and 39 in the "Classes" document, 
    it would seem that there may be some cases where a user-defined
    class might want to inherit from a built-in class. The canonical
    example is the class STREAM which one might want to have as the
    parent for the class WINDOW in an object-oriented window system.
    This would also be a reason to have a class for STREAM, instead
    of excluding it, as on pg. 39. Has anyone given thought to how
    this would fit in with the proposed CommonWindows standard?

The short answer is that we are limiting this project to proposing
a standard for object-oriented programming, and we are specifically
refraining from redesigning the rest of Common Lisp.  I'm sure that
once there is a standard for object-oriented programming there will
be a movement to make some changes to Common Lisp to take advantage
of that, and probably streams will be one of the areas affected.

A slightly longer answer is that the built-in data types are implemented
in different ways in different Common Lisp implementations.  Thus some
implementations do streams in such a way that subclassing would be
possible, while others do them in a non-extensible way.  We don't want
to limit the ability of those latter implementations to adopt the
standard.  Implementations that have windows and have extensible streams
can certainly make their window class inherit from their stream class;
nothing in the proposed standard is intended to forbid that.  It's just
that it isn't portable to every implementation.


∂15-Oct-86  1503	Bobrow.pa@Xerox.COM 	Method Combination 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Oct 86  15:02:50 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 OCT 86 14:41:04 PDT
Date: 15 Oct 86 14:39 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Method Combination
To: Common-Lisp-Object-system@sail.stanford.edu
cc: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>,gregor.pa@Xerox.COM
Message-ID: <861015-144104-3961@Xerox>

This message contains a proposal for some primitives that we claim allow
simplification of the defining form for method combination.  With these
primitives, we then define some standard method combination types for
examination and comment.

 1) Finding the methods with appropriate qualifiers.  Use of this
primitive would replace the current 3rd argument to
define-method-combination. 

Methods of a generic function have a list of qualifiers consisting of
all the items <qualifier> in the defining form:

(defmethod <generic-function> {<qualifier>}* ... ) 

The primary method has qualifier list ().  find-methods uses a filter
argument that is a list. In matching, the qualifier list must be equal
to the filter list, except that * in the filter list matches any item in
the qualifier list. 

(find-methods generic-function
                    &optional (filter ())
                              (order :most-specific-first))
  Selects methods of the generic function that match
  filter. Returns a list of such methods ordered
  by specificity determined by order.

filter  = ({<qualifier>|*}*)
order = :most-specific-first | :most-specific-last

examples:
 (find-methods generic-function)  ;; primary methods in usual order
 (find-methods generic-function (:before))
 (find-methods generic-function (:after) :most-specific-last)


2) Primitives for constructing method combination forms.  These are
designed to be used in the expression that constructs the body of a
combined method.

(make-method-call method-object) 
     Constructs a lisp form that calls
     method-function of method-object 

(make-call-first-method method-list)
     Constructs a call of first method on method-list
     with remainder of method-list
     accessible to call-next-method.

(method-from-form lisp-form)
      Constructs a method from a Lisp form for a particular generic
function. 

----
We can now compare the current syntax for method combination with this
new style using the primitives given:

**Current style:

(define-method-combination1 :daemon ()
    ((before :every :most-specific-first (:before))
     (primary :every :most-specific-first ())
     (after :every :most-specific-last (:after)))
  `(multiple-value-prog2
     (call-component-methods before)
     (call-component-method (car primary) (cdr primary))
     (call-component-methods after)))


----
**New style (without supporting additional macros)
  
 (define-method-combination2 :daemon (generic-function)
   `(multiple-value-prog2
      (progn ,@(mapcar #'(lambda (m) (make-method-call m))
                       (find-methods generic-function (:before))))
     ,(make-call-first-method (find-methods generic-function)))
     (progn ,@(mapcar #'(lambda (m) (make-method-call m))
                      (find-methods generic-function
                                    (:after)
                                    :most-specific-last)))

(define-method-combination2 :around+daemon (generic-function)
   (make-call-first-method
     (append
       (find-methods generic-function (:around))
       (list
         (make-method-from-form
           `(multiple-value-prog2
              (progn ,@(mapcar #'(lambda (m) (make-method-call m))
                               (find-methods generic-function
(:before))))
             ,(make-call-first-method (find-methods generic-function)))
              (progn ,@(mapcar #'(lambda (m) (make-method-call m))
                               (find-methods generic-function
                                             (:after)
                                             :most-specific-last))))))))

3) Additional Supporting macros
We also propose to provide several macros useful in many common cases
that provide an interface to these primitives.


(call-all-methods &optional (filter ())
                                       (order :most-specific first)
                                       (operation 'progn))
  constructs a call to all methods specified combined by operation given

(call-first-method &optional(filter ())
                                       (order :most-specific first)
                                       form-for-last-method)
  constructs a call-first-method of selected list.  Selected list are
those methods matching filter, followed by a method constructed from
form-for-last-method, if the latter is non-nil

----
**New style (with supporting additional macros)
 

(define-method-combination2 :daemon (generic-function)
  `(multiple-value-prog2
     (call-all-methods  (:before))
     (call-first-method)
     (call-all-methods (:after) :most-specific-last)))


(define-method-combination2 :around+daemon (generic-function)
  `(call-first-method (:around)
     (multiple-value-prog2
       (call-all-methods  (:before))
       (call-first-method)
       (call-all-methods (:after) :most-specific-last)))
 
(define-method-combination2 :and (generic-function)
  '(call-all-methods  (*) :most-specific-first and))

∂15-Oct-86  1602	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re: Anonymous Generic Function Proposal        
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 15 Oct 86  16:01:56 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 11712; Wed 15-Oct-86 18:21:12 EDT
Date: Wed, 15 Oct 86 18:27 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: Anonymous Generic Function Proposal    
To: Gregor.pa@XEROX.ARPA
cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
In-Reply-To: <861014-172917-2958@Xerox>
Message-ID: <861015182712.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
Line-fold: No

Given RPG's proposal, it seems to me that your alternative #2 is the
only one that can possibly be right.  It's well-established elsewhere
that the meaning of a "form that does a lexical binding" is that the
form establishes an entirely new Lisp variable, completely masking any
outer use of that variable name.  That is, the new variable created by
the lexical-binding form is totally unrelated to its outer namesake.
Extrapolation of this principle leads to alternative #2.  If the forms
are named as proposed, they must do normal Lisp lexical binding in the
same way that flet and labels do.

∂15-Oct-86  1602	DLW@ALDERAAN.SCRC.Symbolics.COM 	Anonymous Generic Functions     
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 15 Oct 86  16:02:33 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 11714; Wed 15-Oct-86 18:27:41 EDT
Date: Wed, 15 Oct 86 18:33 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Anonymous Generic Functions  
To: RPG@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: The message of 15 Oct 86 10:51 EDT from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Message-ID: <861015183350.3.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: 15 Oct 86  0751 PDT
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

    The reason for anonymous generic functions is the same reason for
    anonymous functions. The user wants to define a locally known
    generic function without the possibility of other methods
    leaking in. 

I'm not sure what you mean by this.  Consider the following example:

(defun a ()
   (generic-function-labels
      ((foo ((x c1)) ...))
    ...
    (b #'foo)
    ...
    (foo ...)))

(defun b (gf)
  (add-method gf ...))

This appears to be a case in which other methods have leaked in.

Perhaps you meant that the compiler can sometimes prove that no methods
have leaked in.  To do so, the compiler must show that no outside
functions are called that can possibly get their paws on the generic
function object.

(The term "anonymous generic function" is a little strange in this case,
since the generic function seems be named "foo".)

    Early on, the small minds didn't think FLET and LABELS would be useful,
    but I see lots of user code, and lots of implementor code, using them
    everywhere.

But that would be a very different justification for
generic-function-labels, namely that it's useful to have methods that
can access the lexical variables of an outer contour.  Is that part of
the justification?

I'm still not wholly convinced that this is really useful.  It's hard to
go into a complete description, but basically the way I've seen generic
functions used, they are mainly employeed as a modularity technique for
organizing large systems, whereas this kind of micro-use is not for that
purpose.  Or something like that; I'm not explaining it well.  I concede
that, as you point out, it's hard to know for sure what will turn out to
be useful.  But this one's hard to evaluate.

∂15-Oct-86  1635	Masinter.pa@Xerox.COM 	Re: Anonymous Generic Functions      
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Oct 86  16:34:57 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 OCT 86 16:21:20 PDT
Date: 15 Oct 86 16:21 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Anonymous Generic Functions  
In-reply-to: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>'s
 message of Wed, 15 Oct 86 18:33 EDT
To: DLW@ALDERAAN.SCRC.Symbolics.COM
cc: common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <861015-162120-4109@Xerox>

"I'm still not wholly convinced that this is really useful.  It's hard
to
go into a complete description, but basically the way I've seen generic
functions used, they are mainly employeed as a modularity technique for
organizing large systems, whereas this kind of micro-use is not for that
purpose.  "

I was in the middle of composing a similar message. I agree; I think
your words explain it OK. 

∂15-Oct-86  2018	kempf%hplabsc@hplabs.HP.COM 	Re: Anonymous Generic Functions
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 15 Oct 86  20:18:25 PDT
Received: from hplabsc by hplabs.HP.COM ; Wed, 15 Oct 86 19:35:13 pdt
Received: by hplabsc ; Wed, 15 Oct 86 19:35:02 pdt
Date: Wed, 15 Oct 86 19:35:02 pdt
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8610160235.AA15608@hplabsc>
To: common-lisp-object-system@sail.stanford.edu
Subject: Re: Anonymous Generic Functions


RPG's proposal certainly does tend toward conceptual unity, in that,
you could do exactly the same things with generic 
functions as with regular functions
but I tend to favor the point raised by Dan and Larry. I've
typically seen object-oriented programming used for "programming in
the medium" (as opposed to programming in the large or in the small).
Packages provide modularity on a larger scale, functions on a smaller.
In languages like Scheme, where the only unit of modularity is the
function, the conceptual unity would become more important.

		Jim Kempf	kempf@hplabs

∂15-Oct-86  2136	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Method combination -- writeup for revised syntax
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Oct 86  21:34:39 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 134636; Wed 15-Oct-86 23:40:46 EDT
Date: Wed, 15 Oct 86 23:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Method combination -- writeup for revised syntax
To: common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <861015233940.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

Here is the current status of the new syntax for
define-method-combination.  This is a first draft and I will likely send
some corrections tomorrow after I have implemented and tested it, and
after I have digested Danny's message on the same topic, which arrived
this evening.  It also will not shock me if this evolves a little as a
result of discussion.

This differs a little from what we said in Palo Alto on Saturday,
because it turned out, on reflection, that some of the things we said
then could not actually work.  I apologize for the long delay in sending
this out; part of the problem was that I was ill, and part of the problem
was that just transcribing what we said on Saturday turned out not to be
useful.


>>> CONTEXT:

When a generic function is called with particular arguments, it must decide
which method or methods to call, in which order to call them if there is
more than one, and from where to get the value(s) to return.  In addition,
if CALL-NEXT-METHOD is used someone must decide which method is next.
These requirements are handled by the following 4-step procedure:

1.  Select the set of available methods. 

The set of available methods consists of all methods for that generic function
whose specialized parameters match their corresponding arguments.

2.  Sort the available methods into a precedence order. 

To compare the precedence of two methods, examine their parameter
specializers in order from left to right.  An unspecialized parameter has a
default parameter specializer of T.  The first pair of parameter
specializers that are not equal determine the precedence.  Method X is more
specific than method Y if method X's parameter specializer is earlier than
method Y's parameter specializer in the class precedence list of the class
of the argument.  Since the methods are available for this argument, it is
guaranteed that their parameter specializers are present in the class
precedence list of the class of the argument. 

T is implied at the very end of each class precedence list, so it is less
specific than any other class.  (QUOTE individual) is more specific than
any class.

The resulting list of available methods is sorted with the most specific
method first and the least specific method at the end.

3.  Apply method combination.

The method combination technique specified for the generic function receives
the sorted list of available methods and returns a Lisp form.  This form
contains calls to some or all of the methods, defines the value(s) to be 
returned by the generic function, and optionally makes some of the methods
reachable via CALL-NEXT-METHOD, rather than calling them directly.

4.  Consider the resulting Lisp form.

In the simplest implementation, the generic function simply evaluates the
form.  In practice, this is too inefficient and most implementations do not
execute this entire procedure every time a generic function is called.
Instead they employ a variety of optimizations such as precomputation into
tables, compilation, and/or caching to speed things up.  Some illustrative
examples (not exhaustive):

  - Use a hash table keyed by the class of the arguments.
  - Compile the Lisp form and save the resulting compiled-function.
  - Recognize the Lisp form as an instance of a pattern of control structure
    and substitute a closure of a function that implements that structure.

The Lisp form serves as a more general interface.  For example, a tool that
determines which methods are called and presents them to the user works by
going through the above procedure and then analyzing the form to determine
which methods it calls, instead of evaluating it.

The define-method-combination facility described below allows the programmer
to customize step 3 of the above procedure without having to worry about
what happens in the other steps.  The other steps of the procedure can be
customized by a more advanced programmer, using meta-objects.

The meaning of the qualifiers of a method is defined entirely by step 3 of
the above procedure.  These qualifiers give the method combination
procedure a way to distinguish between methods.  Because
define-method-combination controls the meaning of these qualifiers, it also
is the place to control human-readable descriptions of these qualifiers.
These descriptions are printed by tools in the programming environment,
which are not specified by this standard and are not likely to be portable,
but the descriptions themselves are easily portable and are related to the
programmer's intent in using define-method-combination, not to the
programming environment tools.  A description is a format string, used by
(APPLY #'FORMAT stream description (METHOD-QUALIFIERS method)).  In most
cases the description will not contain any format directives.  If no
description is specified, a default description is chosen.


>>> NOTE:

This does not yet incorporate anything from Bobrow's message of 15 October.


>>> SHORT FORM:

(DEFINE-METHOD-COMBINATION name operator {keyword argument}*)
Keywords are:
  :DESCRIPTION format-string
  :DOCUMENTATION string

This produces a Lisp form (operator method-call method-call...).
Name and operator must be non-nil symbols.  Operator can be the name of a
function, the name of a macro, or the name of a special form.
Nothing in this define-method-combination form is evaluated.

This method-combination type recognizes primary methods (methods with no
qualifiers), methods with one qualifier equal to <name>, and methods with
one qualifier equal to :around.  Primary methods and <name> methods are
interchangeable.  :around methods behave as in the default type of method
combination.

A method-combination type defined this way always takes one optional
argument, order, defaulting to :most-specific-first.  It doesn't seem
worthwhile to add a keyword to control this or turn it off, even though it
is only useful with some operators.


PROCLAIM-IDENTITY-WITH-ONE-ARGUMENT symbol

Tells the object system that a form (symbol form1) can be optimized to just
form1.  (PROCLAIM-IDENTITY-WITH-ONE-ARGUMENT 'PROGN) is done automatically.
Note that if symbol is a function (rather than a special operator) the
optimization is only strictly valid if form1 returns exactly one value.
This is not checked.  PROCLAIM-IDENTITY-WITH-ONE-ARGUMENT might affect the
compiler in addition to the object system, but this is implementation
dependent.

[If this never affects the compiler, then perhaps it should be changed back
to a keyword word argument to the short form and to make-method-call.]


>>> LONG FORM (BASIC FACILITIES):

(DEFINE-METHOD-COMBINATION name lambda-list ({method-selection}+) 
  {declaration | doc-string}* 
  {form}+)

name -- a non-null symbol
lambda-list -- receives the arguments in the :method-combination option to defgeneric.
method-selection -- (variable {qualifier-pattern}+ {keyword argument}*)
  variable -- a non-constant symbol, which gets bound to a list of the methods
	      whose qualifiers match at least one of the qualifier-patterns.
	      (The list is possibly modified by the keywords).
  qualifier-pattern -- The symbol *, which matches all methods, or a list.
		Each list element is *, which matches any qualifier, or an atom,
		which matches a qualifier EQL to it.  The list can end in
		a dotted pair whose cdr is *, which matches any number of
		additional qualifiers; otherwise the number of qualifiers
		must be the same as the length of the pattern.  The empty
		list () matches methods with no qualifiers, of course.
  Keywords are:
    :ORDER a form evaluating to :MOST-SPECIFIC-FIRST or :MOST-SPECIFIC-LAST.
    :DESCRIPTION format-string
    additional keywords mentioned under "Advanced Facilities"

The first qualifier-pattern to match a method "consumes" that method,
and later qualifier-patterns are not tested.  Thus if there is more than
one method-selection, each method appears in the binding of at most one
method-selection variable.

If a method is available but matches none of the qualifier-patterns, the
fact that the method is not valid with this type of method combination is
automatically reported as an error or as a warning as appropriate.

Declarations concerning bindings can be applied to the variables in the
lambda-list but not to the variables in the method-selections.  If a
doc-string is present, it documents the method-combination type.  The value
of the last form in the body is the Lisp form that specifies how the
methods are combined, as discussed above.


Related functions:

MAKE-METHOD-CALL method-list &key :operator :around

Returns a form whose car is operator (default is progn) and whose cdr is
forms that call the methods.  If proclaim-identity-with-one-argument of the
operator has been done, and the length of method-list is 1, returns just a
form that calls the one method.  If method-list is nil, returns nil.

If around is true (default is false), returns a form that calls the first
method and arranges for call-next-method to reach the rest of the methods,
in the order they appear in method-list.  In this case :operator cannot be
specified.

There are additional keywords mentioned under "Advanced Facilities".


MAKE-METHOD-FROM-FORM form

Returns an object that acts like a method whose body is the form.  Informally
and imprecisely this could be described as "the method version of lambda".


METHOD-QUALIFIERS method

Returns a list of the method's qualifiers.  This is particularly useful
when the qualifier-pattern contains *s, to find what they matched.


METHOD-COMBINATION-ERROR format-string &rest args

Either signals an error or prints a warning, depending on context.  Adds
contextual information to the message.  This should be used instead of
ERROR or WARN to signal errors, such as too many or too few methods
defined, because the type of error message appropriate in a given situation
is a function of the programming environment.  Using this abstraction
ensures portability.

    
>>> LONG FORM (ADVANCED FACILITIES):

These have been separated from the basic facilities because they are not
needed in order to understand the basic idea.  I am proposing that each of
these should be included in the standard, but we can decide about them on a
case by case basis.


WRAP-AROUND-METHODS around-methods form

A combination of make-method-call and make-method-from-form that puts
:around methods around a form.  This only exists for convenience, to
encourage programmers of new method-combination types to support :around
methods.

(defun wrap-around-methods (around-methods form)
  (if around-methods
      (make-method-call (append around-methods
				(list (make-method-from-form form)))
			:around t)
      form))


Additional keywords for method-selections in define-method-combination:

:INCLUDE-DEFAULT-METHODS boolean

If :include-default-methods is true, then this method-selection receives
the additional qualifier-pattern (:DEFAULT), but methods that match that
pattern are discarded unless no methods match any of the other
qualifier-patterns of this method-selection.  This is a way to have
methods that are less specific than all other methods, regardless of
the class precedence order.

:SELECT one of :FIRST, :LAST, :EVERY, or :REMOVE-DUPLICATES

Discards some of the methods that match the qualifier-patterns.  The
default is :every, which retains all of the methods.  :First and :last
discard all but the first or last method.  :Remove-duplicates identifies
methods that have equal qualifiers and discards all but the first method in
each group.  :Select is an abbreviation for code that could be written less
concisely, as follows:

  :first -- (setq var (and var (list (first var))))
  :last -- (setq var (last var))
  :remove-duplicates -- 
     (setq var (remove-duplicates var :from-end t
				      :key #'method-qualifiers
				      :test #'equal))


Make-method-call with just a method object instead of a list of one
element would be a convenience sometimes and appears to be harmless.


Additional keywords for make-method-call:

:ARGLIST list of forms
Uses the specified forms as the arguments to each method instead of
using the arguments to the generic function.

:APPLY list of forms
Same as :arglist except that the last form in the list evaluates to
a list of arguments and the call is made with apply rather than funcall.
You must not specify both :arglist and :apply.

This is a bit more complicated than it seems at first, because there are
three potentially different argument lists involved.  (1) The arguments
supplied to the generic function.  (2) The arguments passed from the
generic function to the methods.  (3) The arguments actually received by a
method.  (2) differs from (1) in certain proposals for discrimination on
optional arguments, such as the &generic-optional one and the :interface
one.  (3) differs from (2) in implememtations that have a special calling
sequence for methods.  The :arglist/:apply keywords for make-method-call
allow you to change the (2) arguments; any implementation-dependent
transformation from (2) to (3) still applies.

It is not a good idea to change arguments that are used for discrimination,
since this could cause a method to be called with an argument that does
not match its parameter specializer.


(WITH-METHOD-ARGUMENT-ACCESSORS lambda-list &body body)

This macro is convenient when changing the arguments passed to the methods.
Each parameter in lambda-list is bound to a form that accesses the
corresponding method argument, and then body is executed.  These accessor
forms come from the hidden information mentioned above.  Lambda-list must
match the (2) arguments mentioned above.


>>> PRIMITIVE FUNCTIONS:

[Not yet written, this section would define primitive functions that are
used in the expansion of the above convenience macros.  This is probably
really part of the meta-object protocol.  For example, define-method-combination
might expand into a defclass and two defmethods, one for the combining and
the other for the qualifier descriptions.]


>>> DESIGN RATIONALE:

The functions make-method-call and make-method-from-form exist not only for
convenience, but to conceal the implementation-dependent method calling
sequence details.  This gives implementations the freedom to do special
optimizations, which may depend on the argument list of the generic
function and on the particular set of available methods.  This will become
especially important if in the future we allow discrimination on optional
arguments.

The functions make-method-call and make-method-from-form can only be called
from the body forms of define-method-combination.  Their operation depends
on hidden state variables that contain the implementation-dependent calling
sequence details.  It seems cleaner to hide this stuff completely, by
passing it around the user's method-combination routine in dynamic
variables, rather than making it visible as an argument to the user's
method-combination routine.

Why package everything into make-method-call, rather than providing several
functions?  It seemed cleaner to put it all into one, and use keyword
arguments to provide variations, rather than making up a lot of different
names, but this is not an essential point.

Why have a :around keyword to make-method-call, instead of using
:operator with a macro that does the call-next-method stuff?  The
latter technique is not as flexible because it doesn't have access
to the method meta-objects, only to the Lisp forms that invoke the
method functions.  Note that we have avoided specifying anything
about those Lisp forms; they are completely implementation-dependent
to allow maximum freedom for optimization.


>>> EXAMPLES:

(define-method-combination :daemon (&optional (order ':most-specific-first))
        ((around (:around))
	 (before (:before))
	 (primary () :order order)
	 (after (:after) :order :most-specific-last))
  ;; Must have a primary method
  (unless primary
    (method-combination-error "A primary method is required."))
  (wrap-around-methods around
		       `(multiple-value-prog2
			  ,(make-method-call before)
			  ,(make-method-call primary :around t)
			  ,(make-method-call after))))

(define-method-combination :inverse-list ()
	((around (:around))
	 (methods () (:inverse-list)))
  (with-method-argument-accessors (instance list)
    (wrap-around-methods around
      (cons 'progn
	(loop for (method . rest) on methods
	  collect (make-method-call method :arglist (list instance list))
	  when rest collect `(pop ,list))))))

(define-method-combination :simplified-case ()
	((around (:around))
	 (methods (*) :select :remove-duplicates))
  (with-method-argument-accessors (instance subtype &rest args)
    (wrap-around-methods around
      `(ecase ,subtype
	 ,@(mapcar #'(lambda (method)
		       (list (method-qualifiers method)
			     (make-method-call method :apply (list instance args))))
		   methods)))))

∂16-Oct-86  1118	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Anonymous Generic Function Proposal        
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Oct 86  11:17:42 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 135071; Thu 16-Oct-86 12:54:20 EDT
Date: Thu, 16 Oct 86 12:53 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Anonymous Generic Function Proposal    
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: The message of 14 Oct 86 19:59 EDT from Dick Gabriel <RPG@SAIL.STANFORD.EDU>,
             <861014-172917-2958@Xerox>,
             The message of 15 Oct 86 10:51 EDT from Dick Gabriel <RPG@SAIL.STANFORD.EDU>,
             <861015182712.2.DLW@CHICOPEE.SCRC.Symbolics.COM>,
             <861015183350.3.DLW@CHICOPEE.SCRC.Symbolics.COM>,
             <861015-162120-4109@Xerox>,
             <8610160235.AA15608@hplabsc>
Message-ID: <861016125310.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

This seems like a great idea to experiment with.  Is this an entirely
new idea, or is it based on experience in a real system (not necessarily
a Common Lisp system)?  If there isn't some real basis in experience,
I think it would be highly premature to cast it in concrete in a standard.
Is there anything in the current proposed standard that would make it
difficult to add this feature?

∂16-Oct-86  1837	Gregor.pa@Xerox.COM 	Anonymous Generic Function Proposal    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Oct 86  18:37:30 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 16 OCT 86 18:37:13 PDT
Date: Thu, 16 Oct 86 18:37 PDT
From: Gregor.pa@Xerox.COM
Subject: Anonymous Generic Function Proposal
To: Common-Lisp-Object-System@Sail.stanford.edu
Message-ID: <861016183705.2.GREGOR@AVALON.isl.parc.xerox.com>
Line-fold: no


I wasn't questioning the usefulness of generic-function-labels.  Rather
I was pointing out that there were two different kinds of binding of
generic functions (or their parts) that were useful.

One kind of binding, the one which I called #2 and which I will now call
GFLABELS, says that within the scope of the GFLABELS the symbol names a
generic function with only the set of methods given in the GFLABELS.
This one gets its name because it binds an entire generic function.


Given GENERIC-LAMBDA, it is straightforward to implement GFLABELS and
GFLET as macros which expand into labels and flet.

(gflabels ((foo ((x boat) <boat body>)
		((x plane) <plane body>)))
  body)

(labels ((foo (x) (funcall
		    #'(generic-lambda ((x boat) <boat body>)
				      ((x plane) <boat body>))
		    x)))
  body)



The other kind of binding, the one I called #1 and which I will now call
MLABELS, says that within the scope of the MLABELS there should be some
extra methods on the generic function which existed outside the scope of
the MLABELS.  This one gets its name because it binds methods on a
generic function.

On the whiteboard, Danny and I have convinced ourselves that
implementing MLABELS is not hard, but it isn't quite as easy as
gflabels.

But working it out brought up some interesting questions, including a
questions about what mlabels should do in the following case.

(defmethod move ((b boat)) 'outer-boat)

(defun make-special-mover ()
  (mlabels ((move ((b boat))  'inner-boat))
    #'(lambda (o) (move o))))

(setq special-mover (make-special-mover))

Now:
 
 (funcall special-mover (make 'fast-boat))

clearly returns inner-boat.

But if I do:
  (defmethod move ((fb fast-boat)) 'outer-fast-boat)

should (funcall foo (make 'fast-boat)) return outer-fast-boat?
-------

∂16-Oct-86  1922	Masinter.pa@Xerox.COM 	Re: Summary of Object Standard Discussions
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Oct 86  19:19:21 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 OCT 86 19:19:19 PDT
Date: 16 Oct 86 19:19 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Summary of Object Standard Discussions
In-reply-to: Bobrow, Gregor's message of 8 Oct 86 15:50 PDT
To: COMMON-LISP-OBJECT-SYSTEM@SAIL.STANFORD.EDU
Message-ID: <861016-191919-5358@Xerox>

I know you've been over this, but I'm still bothered by a few things in
the defclass syntax. 

In DEFCLASS syntax, isn't it a bit odd to have the :DOCUMENTATION down
at the bottom of the form after all of the superclass and all of the
slots and everything?



(DEFCLASS FOO (A B C)
	(SLOT1 12)
	(SLOT2 13)

	:DOCUMENTATION "This is the class for FOO's"

)


Wouldn't it be more like the rest of Common Lisp (DEFUN DEFMACRO DEFTYPE
DEFVAR DEFPARAMETER DEFCONSTANT) to allow the documentation as a string
without a keyword up at the top somewhere, like

(DEFCLASS FOO (A B C) "Here's the documentation string"
	...)

∂16-Oct-86  2044	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Anonymous Generic Function Proposal        
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Oct 86  20:43:48 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 135071; Thu 16-Oct-86 12:54:20 EDT
Date: Thu, 16 Oct 86 12:53 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Anonymous Generic Function Proposal    
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: The message of 14 Oct 86 19:59 EDT from Dick Gabriel <RPG@SAIL.STANFORD.EDU>,
             <861014-172917-2958@Xerox>,
             The message of 15 Oct 86 10:51 EDT from Dick Gabriel <RPG@SAIL.STANFORD.EDU>,
             <861015182712.2.DLW@CHICOPEE.SCRC.Symbolics.COM>,
             <861015183350.3.DLW@CHICOPEE.SCRC.Symbolics.COM>,
             <861015-162120-4109@Xerox>,
             <8610160235.AA15608@hplabsc>
Message-ID: <861016125310.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

This seems like a great idea to experiment with.  Is this an entirely
new idea, or is it based on experience in a real system (not necessarily
a Common Lisp system)?  If there isn't some real basis in experience,
I think it would be highly premature to cast it in concrete in a standard.
Is there anything in the current proposed standard that would make it
difficult to add this feature?

∂16-Oct-86  2114	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Method Combination
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Oct 86  21:12:51 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 135160; Thu 16-Oct-86 14:23:02 EDT
Date: Thu, 16 Oct 86 14:21 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Method Combination
To: Common-Lisp-Object-system@SAIL.STANFORD.EDU
In-Reply-To: <861015-144104-3961@Xerox>
Message-ID: <861016142151.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 15 Oct 86 14:39 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>,gregor.pa@Xerox.COM

    This message contains a proposal for some primitives that we claim allow
    simplification of the defining form for method combination.  With these
    primitives, we then define some standard method combination types for
    examination and comment.

This will be a long reply, both because I don't want to delete any of your
original and because there are several different issues raised here.

     1) Finding the methods with appropriate qualifiers.  Use of this
    primitive would replace the current 3rd argument to
    define-method-combination. 

    Methods of a generic function have a list of qualifiers consisting of
    all the items <qualifier> in the defining form:

    (defmethod <generic-function> {<qualifier>}* ... ) 

    The primary method has qualifier list ().  find-methods uses a filter
    argument that is a list. In matching, the qualifier list must be equal
    to the filter list, except that * in the filter list matches any item in
    the qualifier list. 

    (find-methods generic-function
			&optional (filter ())
				  (order :most-specific-first))
      Selects methods of the generic function that match
      filter. Returns a list of such methods ordered
      by specificity determined by order.

    filter  = ({<qualifier>|*}*)
    order = :most-specific-first | :most-specific-last

    examples:
     (find-methods generic-function)  ;; primary methods in usual order
     (find-methods generic-function (:before))
     (find-methods generic-function (:after) :most-specific-last)

I don't understand why this takes a generic-function as an argument,
since the set of methods that should be searched is not all the methods
defined for the generic function, but the "available methods" as defined
in the context part of the writeup I sent yesterday (which was based on
the discussion we had in Palo Alto about where method combination fits
into the scheme of things).  Also, later in your proposal that argument
to find-methods seems to fade away, so I'm not sure what it's about.

The set of available methods could be passed to the method-combination
function as an explicit argument and then passed to find-methods.
That's really what happens in the primitives underlying the syntactic
sugar of Flavors' define-method-combination and my proposed new one that
I mailed out yesterday.  I'm not sure what is the advantage of making
this visible to the user.  Could you comment on this?

There is another problem with this find-methods function, though.
This is the problem of methods with qualifiers that don't match any
pattern (or filter in the terminology you used just above).  It's
important to signal an error for such methods, rather than just dropping
them on the floor, or users will have hard-to-find bugs.  Consider
the typo (defmethod blatz :bfeore ((x c1) &optional y) ...).

It looks like it would be awkward to detect and signal such an error in
your proposal, because the set of possible qualifier patterns is not
enumerated in any one place.  This is reminiscent of problems we had
with the Old Flavors way of doing define-method-combination.  Possibly
some code analysis of the method-combination function could find all the
calls to the find-methods function, but I'd like to see a specific
proposal before believing that that could work, and anyway this does not
seem in the spirit of your proposal.  You didn't give any rationale, but
I assume the reason for proposing a find-methods function rather than
using subforms of a special form is to allow the user to do find-methods
in subroutines called from a method-combination function.  Have I correctly
guessed what you had in mind?  Could you comment on the reasons for
part 1 of your proposal?

Another problem is that you haven't provided a way to find methods based
on the "OR" of two or more filters (patterns).  If it is necessary to do
this, it would have to be done by making separate calls to find-methods
and then merging the resulting lists to get the methods back into
precedence order, but you haven't provided the necessary primitive to
compute the precedence order.  "OR"ing of patterns is fairly common
in Flavors programs.

A less serious problem is that this imperative style, rather than the
Flavors declarative style, of selecting from among the available methods
doesn't provide any place to hang additional information about the sets
of methods, such as the :description.  A separate facility would have
to be developed for that, which would be awkward but certainly not
impossible.

I think a lot of what's going on with part 1 of your proposal, which I
think may be separate from the other two parts, is a difference in
style.  You prefer to provide imperative interfaces so the programmer
can feel the bits between his toes.  I prefer to provide declarative
interfaces so the programmer can't overlook the little details that make
things work, like error checking.  Is this a fair characterization of
what's going on?

    2) Primitives for constructing method combination forms.  These are
    designed to be used in the expression that constructs the body of a
    combined method.

    (make-method-call method-object) 
	 Constructs a lisp form that calls
	 method-function of method-object 

    (make-call-first-method method-list)
	 Constructs a call of first method on method-list
	 with remainder of method-list
	 accessible to call-next-method.

    (method-from-form lisp-form)
	  Constructs a method from a Lisp form for a particular generic
    function. 

Except for syntactic issues such as spellings of names and whether
make-method-call and make-call-first-method are two different functions
or one function with a keyword argument, these are the same as what I
am proposing.  I am not at all sure that the syntax of what I am proposing
is best, so I'd like to see a discussion of the pros and cons of the
syntactic issues.  To start it off, here are some questions:

1. Do we need a function for calling a single method, as in this
proposal and in Flavors, or do we only need a function that takes
a list of methods, as in my proposal?

2. Should the function that knows how call-next-method works be a
separate function or should it be combined with another function?

3. What's the best naming convention to make it clear that we are
constructing forms that call methods, rather than directly calling
methods?

4. Is it better to say (make-method-calls method-list) or
(cons 'progn (mapcar #'make-method-call method-list))?

    ----
    We can now compare the current syntax for method combination with this
    new style using the primitives given:

    **Current style:

    (define-method-combination1 :daemon ()
	((before :every :most-specific-first (:before))
	 (primary :every :most-specific-first ())
	 (after :every :most-specific-last (:after)))
      `(multiple-value-prog2
	 (call-component-methods before)
	 (call-component-method (car primary) (cdr primary))
	 (call-component-methods after)))

For some value of current.  This is neither what I am proposing
nor what New Flavors has.

    ----
    **New style (without supporting additional macros)
  
     (define-method-combination2 :daemon (generic-function)
       `(multiple-value-prog2
	  (progn ,@(mapcar #'(lambda (m) (make-method-call m))
			   (find-methods generic-function (:before))))
	 ,(make-call-first-method (find-methods generic-function)))
	 (progn ,@(mapcar #'(lambda (m) (make-method-call m))
			  (find-methods generic-function
					(:after)
					:most-specific-last)))

    (define-method-combination2 :around+daemon (generic-function)
       (make-call-first-method
	 (append
	   (find-methods generic-function (:around))
	   (list
	     (make-method-from-form
	       `(multiple-value-prog2
		  (progn ,@(mapcar #'(lambda (m) (make-method-call m))
				   (find-methods generic-function
    (:before))))
		 ,(make-call-first-method (find-methods generic-function)))
		  (progn ,@(mapcar #'(lambda (m) (make-method-call m))
				   (find-methods generic-function
						 (:after)
						 :most-specific-last))))))))

    3) Additional Supporting macros
    We also propose to provide several macros useful in many common cases
    that provide an interface to these primitives.


    (call-all-methods &optional (filter ())
				(order :most-specific first)
				(operation 'progn))
      constructs a call to all methods specified combined by operation given

    (call-first-method &optional(filter ())
				(order :most-specific first)
				form-for-last-method)
      constructs a call-first-method of selected list.  Selected list are
    those methods matching filter, followed by a method constructed from
    form-for-last-method, if the latter is non-nil

    ----
    **New style (with supporting additional macros)
 

    (define-method-combination2 :daemon (generic-function)
      `(multiple-value-prog2
	 (call-all-methods  (:before))
	 (call-first-method)
	 (call-all-methods (:after) :most-specific-last)))


    (define-method-combination2 :around+daemon (generic-function)
      `(call-first-method (:around)
	 (multiple-value-prog2
	   (call-all-methods  (:before))
	   (call-first-method)
	   (call-all-methods (:after) :most-specific-last)))
 
    (define-method-combination2 :and (generic-function)
      '(call-all-methods  (*) :most-specific-first and))

This is an admirable attempt at brevity, but I'm having some trouble
understanding it because there aren't any commas in these backquotes.
The big advantage here seems to be elimination of the intermediate
variables used to hold lists of methods, which increases the
conciseness.  On the other hand, the last example suffers a bit from
using positional arguments rather than keyword arguments, and also I'm
not sure what that asterisk is doing there.  Maybe it's attempting to
paper over the lack of "OR" patterns?

For comparison, here is how the proposal I sent yesterday would
implement the same functionality (as far as I can figure out the
functionality you're implementing):

(define-method-combination :daemon ()
        ((before (:before))
	 (primary ())
	 (after (:after) :order :most-specific-last))
  ;; Must have a primary method [does your proposal do this?]
  (unless primary
    (method-combination-error "A primary method is required."))
  `(multiple-value-prog2
     ,(make-method-call before)
     ,(make-method-call primary :around t)
     ,(make-method-call after)))

(define-method-combination :around+daemon ()
        ((around (:around))
	 (before (:before))
	 (primary ())
	 (after (:after) :order :most-specific-last))
  ;; Must have a primary method
  (unless primary
    (method-combination-error "A primary method is required."))
  (wrap-around-methods around
    `(multiple-value-prog2
       ,(make-method-call before)
       ,(make-method-call primary :around t)
       ,(make-method-call after))))
 
(define-method-combination :and ()
        ((methods (*)))
  (make-method-call methods :operator 'and))

Removing the intermediate variables definitely makes the syntax more
concise, in the cases where the additional supporting macros you
propose apply.  I'm having trouble judging whether it's more understandable,
and there are the issues of whether it can be made to work that I
brought up in part 1.  Right now I still feel that the variables are
necessary, but we can keep discussing this.

I added this section to the proposal I mailed out yesterday.  Is this
an accurate summary of the issues?


>>> ISSUES:

Brought up by Bobrow's message of 15 October and Moon's message of 16 October.

(1) Should there be a declarative thing that binds variables to lists
of methods, or should that be done imperatively?  (Moon's message lists
some problems with the imperative approach).
(2) Can the method-selections and the forms be combined into a template
(built up from macros?) that puts the method-selections right where
the method-calls will go in the result?
(3) Naming and syntax of functions such as make-method-call.
(4) "OR" qualifier-patterns.

∂16-Oct-86  2220	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Dispatching on optional/keyword arguments  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Oct 86  22:18:52 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 135694; Fri 17-Oct-86 00:49:34 EDT
Date: Fri, 17 Oct 86 00:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Dispatching on optional/keyword arguments
To: MMcM@STONY-BROOK.SCRC.Symbolics.COM,
    Common-Lisp-Object-System@SAIL.STANFORD.EDU
Message-ID: <861017004826.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

MMcM asked me what was so hard about dispatching on optional and keyword
arguments (i.e. allowing methods to specify classes for such arguments).
I went back through the mail and found eight proposals for coping with
this that have been mentioned so far; this message is an attempt to
classify them.  I included proposals that seemed to have been rejected
already, since the idea was to summarize all the thinking that has
gone on.

There were also a bunch of mutually inconsistent requests from different
users for what the semantics should be, which Gregor collected, but I'm
not going to repeat those here.  Ask me, Mike, if you want to see them.

The problems all have to do with what happens when an optional argument
is not supplied by the caller of the generic function, but one or more
methods exist that are selected by the class of that argument.

Matrix of proposal characteristics:

Proposal #                             1   2   3   4   5   6   7   8

can discriminate on optionals          yes yes yes yes yes yes no  sort-of

can discriminate on keyword args       yes yes ?   yes y?  yes no  ?

methods can tell which args were       no  no  yes no  no  yes yes yes
supplied using supplied-p parameters
(among args used for discrimination)

defgeneric has to specify which args   *   yes yes no  no  no  n/a no
are used for discrimination
(* auxiliary function specifies it)

default forms appear in defmethod      no  no  no  no  yes yes n/a yes
for args used for discrimination

default forms appear in defmethod      yes yes y?  no  yes yes yes yes
for args not used for discrimination

defaults specified in more than one    no  no  no  no  yes yes no  no
place, so can be inconsistent or
consistency has to be defined and
enforced (defining it is harder than
we thought at first)

default value forms can be evaluated   no  no  no  no  no  yes no  no
twice, so must not have side effects,
even when only one method gets called

all methods have consistent number     yes yes yes yes yes yes no  no?
of required & optional arguments

all methods have to have the same      no  no  yes n/a no  no  no  no
supplied-p parameters

new lambda-list syntax introduced      no  no  yes no  no  no  no  no

peculiar semantics                     no  no  no  no  yes no  no  yes

arglist supplied by caller differs     yes yes no  no  no  no  no  no
from arglist written in defmethod

number of user-visible function names  2   1   1   1   1   1   1   1

all programs can be written with       yes yes yes no  yes yes yes yes
defmethod instead of defun (creating
a default method) because defmethod
supports all the same lambda-list
features that defun supports

The proposals, briefly:

1. Do nothing.  User has to define an auxiliary function that receives the
optional arguments, defaults them, and calls the generic function, which
receives them as required arguments.  This is what is, in effect, in the
draft standard proposal today.

2. Generic function receives and defaults the optional arguments, then
passes them to the methods as required arguments.  The :method-arguments
option to defgeneric specifies what arguments get passed to the methods,
possibly including defaulted optionals and supplied-p parameters.
(Same as #1 except there is only one function name.)

3. Generic function receives and defaults the optional arguments, then
passes them to the methods as required arguments.  This is enabled by using
&generic-optional instead of &optional in the defgeneric and defmethod
lambda-lists.  In defgeneric it specifies a default form, in defmethod it
specifies no default form.

4. Generic function receives and defaults the optional arguments, then
passes them to the methods.  Defmethod lambda-list isn't allowed to use
default forms or supplied-p parameters in its optionals.

5. Generic function defaults however many arguments are needed to
discriminate, depending on the particular methods that exist, and passes
those along to the methods.

6. Generic function defaults however many arguments are needed to
discriminate, depending on the particular methods that exist, but
passes only the originally supplied arguments to the methods.

7. Defgeneric specifies only the required arguments.  Each method can
have different optional arguments, but they can't be used for
discrimination.

8. Discrimination only looks at the supplied arguments.  If a method
specifies a class for an optional argument, that method is never called
unless that argument is supplied.

∂17-Oct-86  0515	DLW@ALDERAAN.SCRC.Symbolics.COM 	Anonymous Generic Function Proposal  
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 17 Oct 86  05:15:02 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12101; Fri 17-Oct-86 08:13:38 EDT
Date: Fri, 17 Oct 86 08:19 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Anonymous Generic Function Proposal
To: Gregor.pa@XEROX.ARPA, Common-Lisp-Object-System@Sail.stanford.edu
In-Reply-To: <861016183705.2.GREGOR@AVALON.isl.parc.xerox.com>
Message-ID: <861017081952.1.DLW@CHICOPEE.SCRC.Symbolics.COM>
Line-fold: No

    Date: Thu, 16 Oct 86 18:37 PDT
    From: Gregor.pa@Xerox.COM

    The other kind of binding, the one I called #1 and which I will now call
    MLABELS, says that within the scope of the MLABELS there should be some
    extra methods on the generic function which existed outside the scope of
    the MLABELS.  This one gets its name because it binds methods on a
    generic function.

Note that this one is dynamic in scope, whereas GFLABELS is lexical in
scope.  In fact, your MLABELS resembles dynamic variable binding more
than anything else.  You would presumably want to to be defined that
THROWing out of an MLABELS undoes the changes to the generic function,
as if there were an UNWIND-PROTECT handler, right?

It seems that you could implement such a thing out of existing
primitives, as a macro, using ADD-METHOD and REMOVE-METHOD and
UNWIND-PROTECT, except that you'd have to keep track of all
the shadowing manually which would be a bit of a drag.

On the other hand, your example indicates that you expect a closure to
close over the changes made to the generic function.  This looks like a
weird combination of lexical and dynamic behavior.  When a closure is
called, normally it just reinstantiates a binding environment; it
doesn't go around doing things like side-effecting generic function
objects.

However, if you really were to imagine things working this way, then I
think your example has to return outer-fast-boat, on the grounds that
the closure invocation provides a new handler for "move" on "boat", but
it still gets shadowed by "fast-boat"'s handler, in the usual way.

∂17-Oct-86  0948	masinter.PA@Xerox.COM 	Re: Dispatching on optional/keyword arguments  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Oct 86  09:47:55 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 17 OCT 86 09:20:47 PDT
From: masinter.PA@Xerox.COM
Date: 17 Oct 86 9:20:00 PDT
Subject: Re: Dispatching on optional/keyword arguments
In-reply-to: Moon@STONY-BROOK.SCRC.Symbolics.COM's message of Fri, 17
 Oct 86 00:48 EDT, <861017004826.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: MMcM@STONY-BROOK.SCRC.Symbolics.COM,
 Common-Lisp-Object-System@SAIL.STANFORD.EDU
Message-ID: <861017-092047-5784@Xerox>

Thank you for the summary. The only "characteristic" which seems dubious
is "peculiar semantics" -- it is hardly objective.

We might want to see how much agreement there is on which
characteristics are positive and which are negative. For example, I
think that it is positive if methods are not required to have congruent
argument lists unnecessarily -- it encourages modularity if you need not
know much about the other methods before writing a new one.

Others clearly disagree.

∂17-Oct-86  1037	Bobrow.pa@Xerox.COM 	Re: Anonymous Generic Function Proposal
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Oct 86  10:37:29 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 OCT 86 09:58:06 PDT
Date: 17 Oct 86 09:57 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Anonymous Generic Function Proposal
In-reply-to: Gregor.pa's message of Thu, 16 Oct 86 18:37 PDT
To: Gregor.pa@Xerox.COM
cc: Common-Lisp-Object-System@Sail.stanford.edu
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861017-095806-5846@Xerox>

    But working it out brought up some interesting questions,
    including a questions about what mlabels should do in the following
    case.

    (defmethod move ((b boat)) 'outer-boat)

    (defun make-special-mover () (mlabels ((move ((b boat)) 
      'inner-boat))
        #'(lambda (o) (move o))))

    (setq special-mover (make-special-mover))

    Now:

     (funcall special-mover (make 'fast-boat))

    clearly returns inner-boat.

    But if I do: (defmethod move ((fb fast-boat))
      'outer-fast-boat)

    should (funcall foo (make 'fast-boat)) return outer-fast-boat?

I believe the semantics of MLET ought to be that on entry to the lexical
scope, the outer generic function is copied, and a new generic function
with the added methods is created.  It is this new generic function that
is lexically bound to the mlet variable (move in this case).  Thus, for
Gregor's example, (funcall foo (make 'fast-boat)) should still return
inner-boat.  But reentering the lexical scope above should create a new
special-mover that does return outer-fast-boat.

-- danny

∂17-Oct-86  1037	Bobrow.pa@Xerox.COM 	Re: Anonymous Generic Function Proposal     
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Oct 86  10:37:43 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 OCT 86 10:34:58 PDT
Date: 17 Oct 86 10:34 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Anonymous Generic Function Proposal    
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Thu, 16 Oct 86 12:53 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: RPG@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861017-103458-5895@Xerox>

    This seems like a great idea to experiment with.  Is this an
    entirely new idea, or is it based on experience in a real system
    (not necessarily a Common Lisp system)?  If there isn't some real
    basis in experience, I think it would be highly premature to cast
    it in concrete in a standard. Is there anything in the current
    proposed standard that would make it difficult to add this feature?

The semantics of anonymous generic functions are clearly available in
the new standard.  One creates such a generic-function object, and does
add-methods. The question is whether we provide a simple syntax for this
use.  It seems to me that we should at least consider such a syntax.  I
think the feature would be as useful as flet and labels, with which we
have had significant experience. 

An alternative syntax would oveload flet and flabels with a keyword as
shown in the following examples.  It allows mixing of different kinds of
function.  Its principal disadvantage compared to gflabels etc is that
it must be recognized at a diffeent level rather than be a macro that is
expanded.   

(defun foo ()
  (flet ((bar :generic                ;bar is a generic function
	     (((x plane) (y boat)) bar-method-1)
	     (((x boat) (y plane)) bar-method-2))
	   (baz (x y) ..)                ; baz is an ordinary function
        (zed :methods                 ; locally adds methods to global
zed
           ((q truck)) zed-method-1)  ; to define a local zed
           ((r cycle)) zed-method-2)))
      
    ...))

(defun foo ()
  (labels ((bar :generic
	     ((x plane) (y boat) method-1)
	     ((x boat) (y plane) method-2))
	   (baz (x y) ..))
...
    ))

∂17-Oct-86  1237	kempf%hplabsc@hplabs.HP.COM 	Re: Method Combination    
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 17 Oct 86  12:37:16 PDT
Received: from hplabsc by hplabs.HP.COM ; Fri, 17 Oct 86 09:11:02 pdt
Received: by hplabsc ; Fri, 17 Oct 86 09:09:27 pdt
Date: Fri, 17 Oct 86 09:09:27 pdt
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8610171609.AA05574@hplabsc>
To: common-lisp-object-system@sail.stanford.edu
Subject: Re: Method Combination

I looked over both Dave and Danny's proposals and thought I'd
throw out some comments. Not having ever used Flavors and the
old style method combination, these comments are definitely from
a naive user, so if only comments from experts are desired, please
ignore the rest of this message.

The CONTEXT: section of Dave's proposal was particularly helpful
in clarifying what exactly is going on when a method is called.
In particular, I like the idea of method combination being a
way of customizing method invocation without having to hack the
metaobject protocol. The relationship with the :INTERFACE option
to DEFGENERIC still needs clarification, however. Perhaps the
:INTERFACE option, method combination, and creation of customized
generic function metaclasses could be seen as ways of declaratively
modifying method invocation which demand increasing sophistication
on the part of the programmer.

In general, I think that Danny's proposed syntax is somewhat cleaner,
though, not being an expert, there may be fine points which I'm missing.
I particularly like the functional approach in which FIND-METHOD
avoids introduction of identifiers, and the further simplification
which the additional macros provide.

		Jim Kempf	hplabs!kempf



∂17-Oct-86  1430	RPG   	Re: Anonymous Generic Function Proposal    
 ∂14-Oct-86  1849	Masinter.pa@Xerox.COM 	Re: Anonymous Generic Function Proposal        
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Oct 86  18:48:57 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 14 OCT 86 17:26:06 PDT
Date: 14 Oct 86 17:25 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Anonymous Generic Function Proposal    
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 14 Oct 86
 16:59 PDT
To: RPG@SAIL.STANFORD.EDU
Message-ID: <861014-172606-2956@Xerox>

Howcum no TO in your proposal?

Can you motivate this? I see absolutely no need for it, beside some
small-minded notion of "completion". 

Just because we could extend generic functions to a LABELS equivalent
doesn't mean we should.


∂17-Oct-86  1652	Masinter.pa@Xerox.COM 	Re: Dispatching on optional/keyword arguments  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Oct 86  16:52:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 OCT 86 16:35:50 PDT
Date: 17 Oct 86 16:35 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Dispatching on optional/keyword arguments
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Fri, 17 Oct 86 00:48 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: MMcM@STONY-BROOK.SCRC.Symbolics.COM,
 Common-Lisp-Object-System@SAIL.STANFORD.EDU
Message-ID: <861017-163550-6338@Xerox>

Since I favor proposal 8, I checked your chart just for that column.

I think the answers are

yes yes yes no no yes yes no no no no no no 1 yes

Your chart gave

sort-of ? yes no yes yes no no no? no no yes no 1 yes


I haven't checked the other columns, however.


∂17-Oct-86  1845	@MC.LCS.MIT.EDU:Moon@VALLECITO.SCRC.Symbolics.COM 	"Classes" Document and Agreements Summary   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Oct 86  18:45:18 PDT
Received: from VALLECITO.SCRC.Symbolics.COM by MC.LCS.MIT.EDU 17 Oct 86 21:24:38 EDT
Received: from EUPHRATES.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 59948; Fri 17-Oct-86 17:45:12 EDT
Date: Fri, 17 Oct 86 17:45 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: "Classes" Document and Agreements Summary
To: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
cc: common-lisp-classes-discussion@mc.lcs.mit.edu,
    snyder%hplabsc@hplabs.HP.COM
In-Reply-To: <8610092255.AA05179@hplabsc>
Message-ID: <861017174507.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 9 Oct 86 15:55:24 pdt
    From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>

    I read through the "Classes" document in detail, and the executive
    summary posted by Danny on Oct. 8. Below is a list of detailed
    questions, comments, and corrections which I noticed.

I was hoping to see some discussion stimulated by this.  However, it's
been a week and nothing has happened.  Maybe if I make a few replies and
provocative comments I can start something off.  Also your comments
should be pretty helpful to us in refining the new document now being
developed.

I'm going to delete some parts of your message where I have nothing
useful to say, as some sort of minimal gesture toward brevity.
You'll probably get two copies of this message, because I'm sending it
to you directly just on the off-chance that you're not on the mailing
list yet.

    *Does method combination go through the generic function or
    through the method itself? If the former, then couldn't method
    combination be done using macros? If the latter, then obviously
    not.

I couldn't get anything out of this other than the message that you are
confused by the document.  The next version of the document should be
much less confusing, so let's defer this until then.

    COMMENTS (page numbers reference the "Classes" document)

    pg. 5-CLASS-OF/TYPE-OF relationship needs some clarification
    for instance objects. What will TYPE-OF return when applied
    to an instance object? See comment below on TYPEP

Every object is an instance.  If you mean what does TYPE-OF return
when given an object created by (MAKE-INSTANCE class-name), it
returns class-name.  CLASS-OF returns the actual class object.

    pg. 5-:CLASS option-Is this for class slots? If so, it seems
    to be a retraction of some earlier discussion about doing
    this in the metaclass. What about inheritance of class
    slots? Are seperate copies of class state maintained in
    the super and subclass objects or not?

We need either to resolve the unclarities in the :ALLOCATION
slot option or to remove that option from the standard for
the time being; implementations can always add it as an
extension for experimentation purposes.

    pg. 7-Presumably (TYPE-OF <object>) -> <class-name> for
    TYPEP to work correctly?

I never heard of an implementation of TYPEP that worked by
calling TYPE-OF.  However, I think we are specifying that TYPE-OF
returns that value.

    pg. 7-How is automatic updating of instances done when it is
    redefined? Are there any hooks for user defined transformation
    of instance state? For class state (re. :CLASS option above)?
    Is there some way for a user to override this? 

The working group hasn't discussed this yet, but we ought to.
One thing to look at (except for class variables) is the way
Flavors does it.  There is a hook for user defined transformation.
Somewhere I have a collection of user comments on its deficiencies,
which we should look at.

						   Consider the
    case of developing extensions to a programming environment
    while using the environment. One might not want old instances
    of a redefined class to be updated, if the behavior of the
    redefined class was not yet solid; otherwise, the environment
    might break.

I think if you want to redefine a class without redefining it you should
give it a different name, perhaps using packages.  In Old Flavors we
found lots of subtle reasons why just detaching the old instances from
the class structure and letting them continue to use the old class
doesn't really work (mainly having to do with whether redefining a
method should replace the old definition).

    pg. 14-The term "setf-lambda-list" appears to be used differently in
    the middle and at the end of the page. In the middle, the term means
    a qualified list, at the end, not.

The middle of the page is talking about defmethod and the end of the page
is talking about defgeneric.  I think it's customary for these syntactic
meta-variables to be local to the description of one function.  Maybe in
this case the reuse of the name is confusing and one of the names should
be changed--but that might be confusing, too, since they are closely
related.

    pg. 15-DECLARE should be :DECLARE

No, this is the same DECLARE as in DEFUN.

    pg. 15-For the :ARGUMENT-PRECEDENCE-ORDER, what happens if not
    all the parameters are included?

The latest version says each required parameter should be included.
I assume that means it signals an error if you leave one out.

    pg. 17-I presume the :CLASS option was included so that lambda
    list parameters which were not qualified could be opened up using
    the WITH-SLOTS special form. If so, then why allow super class names
    as well? Isn't it rather more appropriate to have the name following
    :CLASS designate a class or any subclass, as with the class qualifiers
    in the lambda list? 

I think you exchanged sub- and super-class somewhere along the way.
I find that terminology confusing, too.  Both in WITH-SLOTS :CLASS and
in DEFMETHOD parameter specializers, (TYPEP object class) is true;
in other words, class can be a superclass of (CLASS-OF object).

			And what if the parameter isn't of that class
    at runtime?

I guess the document ought to say something about this, although it can
be inferred.  In :use-accessors t mode, it calls the accessor, which
is a generic function, and if object has no method for that generic
function you get the usual method-not-found error, whatever that is
specified to be.  In :use-accessors nil mode, it does whatever
slot-value does, presumably signals an error if there is no slot with
the specified name.

    pg. 18-Does CALL-NEXT-METHOD do the same thing as the current
    RUN-SUPER in PCL?

I can't figure out -precisely- what RUN-SUPER in PCL does, but yes
they are the same concept.

    pg. 19-Why not have PRINT simply be a generic function? 

You mean pg 20?  I'd have to see a more specific proposal, but I
think as soon as you started to write one you'd realize why PRINT,
already defined by Common Lisp, isn't the function that you want
to make generic.

							    Also, why
    not have EQUALP (and perhaps EQUAL, and EQL as well) be generic
    functions? This would allow programmers to define their own
    notions of equality for two instances, and could come in handy
    when objects have circularity.

I think this is something we ought to think about, although one tends
to be discouraged by the fact that equality is one area of Common Lisp
that is particularly poorly thought-out.  I don't think EQL should
be made generic, though, because of efficiency considerations, and
because that would only really make sense if we made + and = generic,
which is definitely beyond the scope of what we're trying to do
in this particular proposal.

    Aren't keywords self evaluating?
    If so, then why quote them in the examples?

It's a matter of programming style.  The style that we at Symbolics
use (some of us, anyway) is not to rely on the self-evaluation of
keywords in syntactic positions that admit any form and just happen
to have a keyword in them.  Thus if (defun foo (&key a b) ...),
we would write (foo :a ':blatz :b ':bar) because the first and
third arguments are syntactically keywords (even though any form
would work) while the second and fourth arguments are only
keywords by coincidence.  We find this less confusing than trying
to bum out quote marks from every possible place where they aren't
needed.

    pg. 26-Must a generic function be defined before 
    DEFINE-METHOD-COMBINATION is evaluated? Must all
    the mentioned methods? Any of them?

This doesn't make sense, so we need to improve the document so
it doesn't lead to this confusion.  Evaluating DEFINE-METHOD-COMBINATION
does not depend on any particular generic function or methods.  The
dependency, if any, is in the other direction.

    pg. 27-What are the internal arguments mentioned in
    the paragraph after the CALL-COMPONENT-METHOD syntax
    description?

It's highly implementation-dependent, and in some implementations there
might not even be any.

    pg. 32-There is a typo at the top of the page. The
    second instance of (PIE CINNAMON APPLE) should be
    (PASTRY CINNAMON APPLE).

Oops.  I wonder how that slipped by.

    pg. 37-The default info. here is good, but should
    be moved up to where the options are defined.

We thought it was a better structure for the document to keep the
rationale behind various decisions separate from the expository material
that just tells it how it is without discussing rejected alternatives.

If you have more comments on places where the document is confusing,
or suggestions for how to make it better, I'd certainly like to hear
them.


∂17-Oct-86  2146	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Computing the class precedence list   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Oct 86  21:45:31 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 136230; Fri 17-Oct-86 14:52:10 EDT
Date: Fri, 17 Oct 86 14:50 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Computing the class precedence list
To: Common-Lisp-Object-System@SAIL.STANFORD.EDU
In-Reply-To: <861010-155100-124@Xerox>,
             <861010155847.2.GREGOR@AVALON.XEROX-PARC>
Message-ID: <861017145051.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 10 Oct 86 15:51 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

    Another way of explaining class precedence list.

    The class precedence list is a left to right, depth first linearization
    of the transitive closure of inheritance from the local super classes of
    a class.  It satisfies three constraints:

    Constraint-0) A class appears only once in the list
    Constraint-1) A class always precedes in the list all its local super
    classes
    Constraint-2) The order of the local supers is preserved

    Stating C1 and C2 slightly differently:

    C-1-2) A class must follow any class it is a direct super of,
	     or any class it follows in a local-supers list. 

This is the same as what we have now, right?

    The class precedence can be constructed in three steps.

    1) Walk the inheritance tree in left to right depth first order,
    recording all super classes in the order visited.

    2) Remove duplicates, preserving the last occurrence of any class.
      (This can actually be combined with step 1 without extra consing.).

    3) Traverse the resluting list from left to right. If for any class c1,
    there is a class to its right that c1 should follow (by C-1-2), move c1
    to the right of the rightmost such class.

    If any class needs to be moved a second time, it means there is a loops
    of constraints that cannot be satisfied.  

    Date: Fri, 10 Oct 86 15:58 PDT
    From: Gregor.pa@Xerox.COM

    This code implements a compute-class-precedence-list algorithm the many
    and varied features of which Danny will describe in a separate message.
    [code deleted]

I have to admire your efficient algorithm design.  After I removed the
format statement and the misuse of nunion on shared data, your algorithm
was 2.6 times faster than mine and only consed 78% as much, on the C6
example.  The ratios were 1.6 and 84% on another example.

The bad news is, your algorithm doesn't always return the right answer.
Here are two examples I found:

(DEFCLASS1 C1 ())
(DEFCLASS1 C2 ())
(DEFCLASS1 C3 ())
(DEFCLASS1 D4 (C3 C2))
(DEFCLASS1 D5 (C2))
(DEFCLASS1 D6 (C3 C2 D5 D4))

(compute-class-precedence-list 'D6) => (D6 D4 C3 D5 C2)

which is incorrect, violating the constraint that D5 should precede D4.
The correct action is to signal an error, because C2 (and C3) is
constrained to be both before and after D4.

(DEFCLASS1 E1 (C1))
(DEFCLASS1 E2 (C2))
(DEFCLASS1 E3 (C3))
(DEFCLASS1 E4 (E3 E2 E1))
(DEFCLASS1 E5 (C1 C2))
(DEFCLASS1 E6 (C2 C3))
(DEFCLASS1 E7 (E5 E6 E4))

(compute-class-precedence-list 'E7) => (E7 E5 E6 E4 E3 E2 C3 E1 C1 C2)

which is incorrect, violating the constraint that C2 should precede C3.
The correct answer is (E7 E5 E6 E4 E3 E2 E1 C1 C2 C3).

While checking this out I discovered a transcription error in the code
I mailed out on 7 Oct.  In COMPOSE-FLAVOR-COMPONENTS, there should not
be a SETQ of SLOW to NIL at the top of the loop; this defeats the SETQ
of SLOW to T at the bottom of the loop.  The SETQ should be before the
loop.  This was an error in conversion from the real version of LOOP
to the stripped down Common Lisp version of LOOP.

∂17-Oct-86  2155	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Clarification of declaration requested
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Oct 86  21:55:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 136322; Fri 17-Oct-86 15:55:01 EDT
Date: Fri, 17 Oct 86 15:53 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Clarification of declaration requested
To: Common-Lisp-Object-System@SAIL.STANFORD.EDU
Message-ID: <861017155332.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

In trying to figure out an issue about defgeneric, I need to ask
for clarification of Common Lisp.  Does

        (defun foo (x)
           (declare (single-float x))
           ...)

imply

        (proclaim '(ftype (function (single-float) t) foo)) ?

I guess Gabriel would be the best one to answer this.

∂17-Oct-86  2157	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Anonymous Generic Function Proposal    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Oct 86  21:56:58 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 136355; Fri 17-Oct-86 16:14:50 EDT
Date: Fri, 17 Oct 86 16:13 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Anonymous Generic Function Proposal    
To: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <861017-103458-5895@Xerox>
Message-ID: <861017161335.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 17 Oct 86 10:34 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

        If there isn't some real
	basis in experience, I think it would be highly premature to cast
	it in concrete in a standard.

    I think the feature would be as useful as flet and labels, with which we
    have had significant experience. 

Danny, if you don't agree that this reasoning is fallacious, then let's
discuss it.  I'm going to assume that you do agree, so I'll say no more
unless I hear from you.

∂17-Oct-86  2159	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Summary of Object Standard Discussions     
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Oct 86  21:59:41 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 136383; Fri 17-Oct-86 16:33:18 EDT
Date: Fri, 17 Oct 86 16:31 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Summary of Object Standard Discussions 
To: Common-Lisp-Object-System@SAIL.STANFORD.EDU
In-Reply-To: <861009-154111-1088@Xerox>
Message-ID: <861017163159.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 09 Oct 86 15:40 PDT
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

    ....Moon said this in his message:

    ``If you make the generic function FOO f-unbound and then do a DEFMETHOD
      or DEFGENERIC for FOO, you get a new generic-function object that
      doesn't know about any of the methods for the old FOO.  Those methods
      are gone ... so the data structure would be inconsistent....  There
      could be other inconsistencies too.''

    If generic functions are first-class, and if we've decided that this
    first-class object (which comprises the generic function along with the
    methods on it) is stored in the function cell, then FMAKUNBOUNDing them
    is what you do when your intention is to `get a new generic-function
    object that doesn't know about any of the <old> methods.''

    I think this means that Moon did not understand what we agreed to. 

I don't think so.  I'm trying to clarify imprecise language.  Putting back
the sentence of mine that you excerpted:

  Those methods
  are gone (except in the PCL meta-object protocol class-direct-methods
  would still know about those methods, so the data structure would be
  inconsistent).

								       A
    first-class generic function is the thing that you funcall to get the
    generic behavior and that has the methods logically inside it. When you
    drop the last pointer to the generic function object, the garbage
    collector can grab it away. 

Except in the PCL meta-object protocol the class would still refer to
the methods and the methods would still refer to the generic function
so the garbage collector can't grab anything away.  This is the inconsistency
I'm trying to clarify.

The other thing that needs to be clarified is exactly when (in the
course of macroexpanding, compiling, and loading/evaluating a DEFMETHOD
form, and calling the resulting method function) the mapping from name
of generic function to generic-function object happens.  Also exactly
when the mapping from name of class (in a specialized parameter) to
class object happens.  If we're going to include undefining and
redefining of these name-to-object mappings in the language, rather than
treating them as write-once relations, we have to be more precise about
when the lookups in these mappings happen.  This is probably not very
hard.

				When you do n DEFMETHODs on FOO, the function
    cell for FOO is the only thing that logically has a pointer to the generic
    function associated with the name FOO. If FMAKUNBOUND does not flush every
    old method, and data structures end up inconsistent, then there is a bug
    in your implementation.

So what this really means is that the linkage from class to methods used in
PCL is a bug, and the meta-object protocol for the standard (which we have
not yet begun to discuss in any serious way) cannot have the same sort of
linkage?  What do people think about this, especially in the context of
browsers?

∂17-Oct-86  2201	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Summary of Object Standard Discussions 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Oct 86  22:01:17 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 136406; Fri 17-Oct-86 16:48:05 EDT
Date: Fri, 17 Oct 86 16:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Summary of Object Standard Discussions 
To: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <861013-183034-1785@Xerox>
Message-ID: <861017164650.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 13 Oct 86 18:31 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

	From: Moon
	The proliferation of -setf functions (e.g. remove-method-setf)
	is getting disturbing and maybe we need an explicit notion of the
	generic function objects that do setfs.

    Should we go back to
      (defmethod (:setf foo) ...)
    since qualifiers are not around the name.

    [discussion of other issues deleted for now]

No, because the real point of defmethod-setf was to have two separate
lambda-lists.  That way the system gets to decide how to glue the two
lambda-lists together, and it can be implementation-dependent and
dependent on whether there are optional/rest/key arguments.  My guess
is the setf-lambda-list goes at the end if there are only required
arguments, but goes at the front if there are any optional/rest/key.

You didn't like my proposal that defmethod, when it saw its first
subform was a list, would change its syntax to have two lambda-lists, as
I recall.  I'm certainly willing to propose that again if you want.

Nit: it should be SETF, not :SETF.  There's no reason to introduce
a new symbol here.

But what might be three reasonable proposals for the problem of the
proliferation of -setf functions would be to keep defmethod-setf
and defgeneric-setf, for the sake of the two lambda-lists, but
do one of the following:

(1) Functions that take an argument that can be either a generic
function object or the name of a generic function (remove-method
and method-combination-type are examples) will accept a list
(SETF foo) as the name of the generic function that gets defined
when you do (DEFGENERIC-SETF foo ...).

or

(2) A new function is introduced that translates from a generic
function object or its name to another generic function object,
the -setf one.

or

(3) Common Lisp is extended to expose the primitives underlying
DEFSETF, one of which is essentially the function proposed in (2).

∂19-Oct-86  1632	Masinter.pa@Xerox.COM 	Re: Summary of Object Standard Discussions     
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 Oct 86  16:32:46 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 OCT 86 16:32:50 PDT
Date: 19 Oct 86 08:20 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Summary of Object Standard Discussions 
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Fri, 17 Oct 86 16:46 EDT
To: common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <861019-163250-1023@Xerox>

defmethod-setf would be easier to explain if there were a defun-setf
which defined a setf function.


∂20-Oct-86  0805	Bobrow.pa@Xerox.COM 	Re: "Classes" Document and Agreements Summary    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Oct 86  08:05:14 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 OCT 86 08:01:19 PDT
Date: 20 Oct 86 08:01 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: "Classes" Document and Agreements Summary
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Fri, 17 Oct 86 17:45 EDT
To: common-lisp-object-system@sail.stanford.edu
cc: kempf%hplabsc@hplabs.HP.COM, snyder%hplabsc@hplabs.HP.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861020-080119-1375@Xerox>

This is an abbreviated response to the Kemp-Moon exchange, deleting the
parts I have nothing to say about.

        pg. 5-:CLASS option-Is this for class slots? If so, it
        seems to be a retraction of some earlier discussion about doing
        this in the metaclass.
    We need either to resolve the unclarities in the :ALLOCATION
    slot option or to remove that option from the standard for the time
    being; implementations can always add it as an extension for
    experimentation purposes.

My understanding of our agreement, and at least the CommonLoops intent
is as follows.  If the :class option is used for a slot, then the slot
is stored with the class.  The implication of this is that all instances
share the same value.  Determining whether a slot should be stored in an
instance or in its class is the responsibility of the class because the
ordinary user knows what semantics is wanted.  The determination of how
instances themselves are represented (e.g. a list, block, with
indirection etc.) is the responsibility of the metaclass.

        What about inheritance of class slots?
        Are seperate copies of class state maintained in the super and
        subclass objects or not?
Descriptions of class slots, just as despcriptions of other slots are
inherited unless overridden in a subclass.  The state associated with a
class slot is stored only where it is explicitly specified in the class.
If a local description of a slot is provided, it completely overrides an
inherited description in a super class.

        pg. 7-How is automatic updating of instances done when
        it is redefined? Are there any hooks for user defined
        transformation of instance state? For class state (re. :CLASS
        option above)? Is there some way for a user to override this? 

    The working group hasn't discussed this yet, but we ought to.
    One thing to look at (except for class variables) is the way
    Flavors does it.  There is a hook for user defined transformation.
    Somewhere I have a collection of user comments on its deficiencies,
    which we should look at.

The hook in CommonLoops for handling updating of obsolete instances is a
generic function that has as arguments the old (obsolete) instance, an
instance of the changed class, the old (obsolete) class and the new
(changed) class.  The first two arguments allow users to write code
directly that updates the instances (the states of the two instances
will be switched at the end).  The last two arguments allow
specialization depending on the meta-classes of the objects.  I agree
that we should discuss this in more detail and look how Flavors does it.



    				Consider the case of developing extensions to a
        programming environment while using the environment. One might
        not want old instances of a redefined class to be updated, if
        the behavior of the redefined class was not yet solid;
        otherwise, the environment might break.

    I think if you want to redefine a class without redefining it
    you should give it a different name, perhaps using packages.  In
    Old Flavors we found lots of subtle reasons why just detaching the
    old instances from the class structure and letting them continue to
    use the old class doesn't really work (mainly having to do with
    whether redefining a method should replace the old definition).


I agree with Moon.

    			And what if the parameter isn't of that class at runtime?

    I guess the document ought to say something about this,
    although it can be inferred.  In :use-accessors t mode, it calls
    the accessor, which is a generic function, and if object has no
    method for that generic function you get the usual method-not-found
    error, whatever that is specified to be.  In :use-accessors nil
    mode, it does whatever slot-value does, presumably signals an error
    if there is no slot with the specified name.

I think if inference can't be done, then an explicit check ought to be
compiled into the code.

        pg. 18-Does CALL-NEXT-METHOD do the same thing as the
        current RUN-SUPER in PCL?

    I can't figure out -precisely- what RUN-SUPER in PCL does, but
    yes they are the same concept.

CALL-NEXT-METHOD is a generalization of RUN-SUPER that fits into the
declarative method-combination  framework.  RUN-SUPER in PCL is
implemented with a run-time search of the applicable methods.  We
believe CALL-NEXT-METHOD can be implemented using method-combination
tecnology.  



Thank you both for pushing the discussion forward.

∂20-Oct-86  0921	Bobrow.pa@Xerox.COM 	Re: Computing the class precedence list
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Oct 86  09:21:48 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 OCT 86 09:21:13 PDT
Date: 20 Oct 86 09:21 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Computing the class precedence list
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Fri, 17 Oct 86 14:50 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861020-092113-1436@Xerox>

        The class precedence list is a left to right, depth
        first linearization of the transitive closure of inheritance
        from the local super classes of a class.  It satisfies three
        constraints:

        Constraint-0) A class appears only once in the list
        Constraint-1) A class always precedes in the list all its local
        super classes Constraint-2) The order of the local supers is
        preserved

        Stating C1 and C2 slightly differently:

        C-1-2) A class must follow any class it is a direct super
     	   of, or any class it follows in a local-supers list. 

    This is the same as what we have now, right?

Yes the constraints are meant to be the same.

        The class precedence can be constructed in three steps.

        1) Walk the inheritance tree in left to right depth
        first order, recording all super classes in the order visited.

        2) Remove duplicates, preserving the last occurrence
          of any class. (This can actually be combined with step 1
          without extra consing.).

        3) Traverse the resluting list from left to right. If
        for any class c1, there is a class to its right that c1 should
        follow (by C-1-2), move c1 to the right of the rightmost such
        class.

        If any class needs to be moved a second time, it means
        there is a loops of constraints that cannot be satisfied.  


Your example works on the first example according to my description of
the algorithm.


    (DEFCLASS1 C1 ())
    (DEFCLASS1 C2 ())
    (DEFCLASS1 C3 ())
    (DEFCLASS1 D4 (C3 C2))
    (DEFCLASS1 D5 (C2))
    (DEFCLASS1 D6 (C3 C2 D5 D4))

Steps in this computation are
First compute left to right depth first up to joins (steps 1 and 2):

(D6 D5 D4 C3 C2)  ;; and now start the fix ups.
-->  ;check  where the ↑ is shown
(↑ D6 D5 D4 C3 C2) 
-->
(D6 ↑ D5 D4 C3 C2) 
--> 
(D6 ↑ D4 C3 C2 D5)  
-->
(D6 ↑ C3 C2 D5 D4)
-->
(D6 ↑ C2 D5 D4 C3)
-->
(D6 ↑ D5 D4 C3 C2)
-->
  Error: D5 needs to be moved again!!

If the code didn't work like this, we will fix it.


For the example:
 
    (DEFCLASS1 E1 (C1))
    (DEFCLASS1 E2 (C2))
    (DEFCLASS1 E3 (C3))
    (DEFCLASS1 E4 (E3 E2 E1))
    (DEFCLASS1 E5 (C1 C2))
    (DEFCLASS1 E6 (C2 C3))
    (DEFCLASS1 E7 (E5 E6 E4))

Start with
(E7 E5 E6 E4 E3 C3 E2 C2 E1 C1)
-->
(↑ E7 E5 E6 E4 E3 C3 E2 C2 E1 C1)
-->
(E7 ↑ E5 E6 E4 E3 C3 E2 C2 E1 C1)
-->
(E7 E5 ↑ E6 E4 E3 C3 E2 C2 E1 C1)
-->
(E7 E5 E6 ↑ E4 E3 C3 E2 C2 E1 C1)
-->
(E7 E5 E6 E4 ↑ E3 C3 E2 C2 E1 C1)
-->
(E7 E5 E6 E4 E3 ↑ C3 E2 C2 E1 C1)
-->
(E7 E5 E6 E4 E3 ↑ E2 C2 C3 E1 C1)
-->
(E7 E5 E6 E4 E3 E2 ↑ C2 C3 E1 C1)
-->
(E7 E5 E6 E4 E3 E2 ↑ C3 E1 C1 C2)
    UH OH!!!
    C3 needs to be moved again impying an error.

The algorithm is too conservative.
This is because we have not computed the usually unneeded recursive
dependencies. The algorithm can be fixed.

One possible fix is to say:
    "If any class needs to be moved a second time,there *MAY BE* a
    loops of constraints that cannot be satisfied."
Either we can check for the error each time, or the list of dependencies
of the classes involved can be expanded recursively. Then these classes
will be moved far enough to the right on the next time they are moved.
In the usual case, (what I think is the usual case), this (MODIFIED)
algorithm should be faster. 

An alternative fix is to check theposition of any class (in this case
C2) that causes a class (in this case C3) to move.  In this case, C2
would be immediately moved past C1, and C3 past C2 after.  There would
be no problem.  We will send more code.  

Did you actually run Gregor's code over all of the Flavors system to
find these bugs, or did you just think.  If the former, are there any
cases actually in your system that the code does not work for?


-- danny

∂20-Oct-86  0928	Bobrow.pa@Xerox.COM 	Re: Summary of Object Standard Discussions  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Oct 86  09:28:34 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 OCT 86 09:28:46 PDT
Date: 20 Oct 86 09:28 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Summary of Object Standard Discussions 
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Fri, 17 Oct 86 16:46 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: common-lisp-object-system@SAIL.STANFORD.EDU
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861020-092846-1454@Xerox>

    (1) Functions that take an argument that can be either a
    generic function object or the name of a generic function
    (remove-method and method-combination-type are examples) will
    accept a list (SETF foo) as the name of the generic function that
    gets defined when you do (DEFGENERIC-SETF foo ...).

    or

    (2) A new function is introduced that translates from a generic
    function object or its name to another generic function object, the
    -setf one.

    or

    (3) Common Lisp is extended to expose the primitives underlying
    DEFSETF, one of which is essentially the function proposed in (2).

I am happy with 1, and like 3 as well.  It seems that 2 without 3 is an
inappropriate extension.  Let us push for 3 in the larger committee.

-- danny

∂20-Oct-86  1345	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Dispatching on optional/keyword arguments   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 Oct 86  13:45:19 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 138083; Mon 20-Oct-86 14:08:23 EDT
Date: Mon, 20 Oct 86 14:07 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Dispatching on optional/keyword arguments
To: Masinter.pa@XEROX.COM
cc: MMcM@STONY-BROOK.SCRC.Symbolics.COM,
    Common-Lisp-Object-System@SAIL.STANFORD.EDU
In-Reply-To: <861017-163550-6338@Xerox>
Message-ID: <861020140752.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 17 Oct 86 16:35 PDT
    From: Masinter.pa@Xerox.COM

    Since I favor proposal 8, I checked your chart just for that column.

    I think the answers are

    yes yes yes no no yes yes no no no no no no 1 yes

    Your chart gave

    sort-of ? yes no yes yes no no no? no no yes no 1 yes

I guess you're working from a different version of that proposal
from the one that I saw in the mail, or what I interpreted of
what I saw in the mail.  The one I'm working from is the one where
defmethod uses the same syntax as defun, but the methods selected
when an optional argument is specialized depend on whether the
optional argument was supplied or defaulted, even if the supplied
value is the same as the default value.

If we wanted to pursue this further we would need to have much more
precise specifications of each of the proposals.  The purpose of
my message was to provide a general framework and summary of the
situation as currently understood, so I'm not surprised if it doesn't
contain all the details of every proposal that people have in mind.

∂20-Oct-86  1408	Bobrow.pa@Xerox.COM 	Re: Summary of Object Standard Discussions  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Oct 86  14:07:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 OCT 86 10:52:08 PDT
Date: 20 Oct 86 10:49 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Summary of Object Standard Discussions 
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Fri, 17 Oct 86 16:31 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861020-105208-1536@Xerox>

      Those methods are gone (except in the PCL meta-object
      protocol  class-direct-methods would still know about those
      methods, so the data structure would be inconsistent).

    	   A first-class generic function is the thing
        that you funcall to get the generic behavior and that has the
        methods logically inside it. When you drop the last pointer to
        the generic function object, the garbage collector can grab it
        away. 

    Except in the PCL meta-object protocol the class would still
    refer to the methods and the methods would still refer to the
    generic function so the garbage collector can't grab anything away.
     This is the inconsistency I'm trying to clarify.

This is a general weakness of most garbage collectors.  What we need in
Lisp is a combination of system pointers (not traced by the garbage
collector), and finalization on collection (so the system can get rid of
the system pointers).   This does appear in the Cedar garbage collector.
Without something like that, then something like the PCL sticky
meta-object protocol will cause such potential garbage to stay around.
In my model of the world, this is not much stuff, so I am not worried
(should I be?). 


    The other thing that needs to be clarified is exactly when (in
    the course of macroexpanding, compiling, and loading/evaluating a
    DEFMETHOD form, and calling the resulting method function) the
    mapping from name of generic function to generic-function object
    happens.  Also exactly when the mapping from name of class (in a
    specialized parameter) to class object happens.  If we're going to
    include undefining and redefining of these name-to-object mappings
    in the language, rather than treating them as write-once relations,
    we have to be more precise about when the lookups in these mappings
    happen.  This is probably not very hard.

Yes we need to do this.

-- danny

∂20-Oct-86  1455	RPG  	Remarks on Generic Functions 
To:   common-lisp-object-system@SAIL.STANFORD.EDU    

This long note contains some remarks addressed to the comments made
regarding generic functions. I think that people on this list do not share
the same ultimate view of what generic functions are and how they can be
used.

To me there are 3 things that the concept of generic functions buys us:

	1. The ability to spread the definition of a generic function
	   among the places where the partial definitions make the most
	   sense.  This is accomplished by placing DEFMETHODs in the
	   places where the relevant classes are defined, for example.

	2. The ability to abstract the definition of a generic function
	   into parts (methods) that are conceptually independent.  This
	   is accomplished by splitting the definition of a generic
	   function into independent parts where each part is the partial
	   function definition for a particular set of classes - each part
	   is a method.  This leads to a new modularization technique.

	3. The separation of the inheritance of behavior from placement of
	   code. Generic functions select methods based on the structure
	   of the class lattice, but the generic functions are not
	   constrained to be stored within that lattice.

Up until now I've seen a deep appreciation of only the first point by
members of this working group. I think this is natural because the only
experience that members of this working group have had is with
DEFMETHOD-like generic function definition.

Here is a summary of what I take to be our understanding of the nature of
generic functions.

There is a new type of first-class object, called a `generic function.'
It can be FUNCALLed and APPLYed exactly as Common Lisp functions can be.
When the function cell of a symbol contains a generic function, we say
that the symbol, call it S, `names' the generic function and that the
generic function is associated with the name, S. [This is exactly as
things are in Common Lisp with respect to functions.] Using MAKE-GENERIC
it is possible to create a generic function not associated with any
symbol.

Generic functions have internal structure. This internal structure
includes the argument list, the argument precedence order, method
combination information, and `methods.'  Not required in that internal
structure is a `name' for the generic function.  A generic function, in
some implementations, might have a name as part of itself but only as an
informational device for use by programming environment tools. The correct
functioning of generic function cannot depend on that name.  When a
generic function is invoked, it invokes and combines some subset of the
methods. Which methods are invoked and how their results are combined
depends on the classes of the arguments supplied to the generic function
and on the method combination type of the generic function.

Methods are objects with, possibly, some internal structure - this has not
yet, I believe, been decided.  Methods include a function, called the
`method function,' and possibly some other user-visible information.  One
such possible part of the internal structure might be a pointer back to
the generic function of which the method is part.  The term `method' is
commonly used to refer to method objects.

Methods are associated with generic functions, but are not associated
directly with any names except in an informational sense - the correct
functioning of a method cannot depend on its name.  If a method is part of
a generic function which is associated with a symbol, S, we say that the
method is `defined for S.'  ADD-METHOD and GET-METHOD add methods to and
retrieve method objects from, respectively, generic functions. DEFMETHOD
adds a method to the generic function associated with the symbol that is
the first argument of DEFMETHOD.

Methods are possibly applicable objects - I don't believe this has been
decided yet.

(typep <generic-function> 'function) 

returns T, and possibly 

(typep <method-object> 'function)

does too. It is certainly possible to write the following code:

(labels ((f (x) ...g...)  ;calls g
	 (g (x) ...h...)  ;calls h
	 (h (x) ...f...)) ;calls f
 (add-method <gf> '((x c1)) #'f)
 (add-method <gg> '((x c2)) #'g)
 (add-method <gh> '((x c3)) #'h))

where <gf>, <gg>, and <gh> are generic functions. This defines
a set of methods whose method functions are mutually referential.
This does not imply that methods are directly invocable.

Generic functions are self-contained objects.  The parts of generic
functions are not spread out in the heap, in tables, or in the class
lattice: The parts are contained in the generic function. Pointers to
generic functions might appear in various places for the proper function
of tools.  One place is the class lattice, which defines the inheritance
structure on which the operation of generic functions depends. [Note:
an implementation is free to spread the definition wherever it likes
as long as it maintains the illusion of generic functions as first-class
objects.]

For example, environmental tools for associating methods with classes are
desirable.  These tools will enable us to browse through a class lattice
and display all methods that operate on instances of the classes being
browsed.  To do this, the tool must be able to determine for each class
the generic functions that operate on that class.  In the case where a
generic function is associated with a symbol, it is nice to display that
symbol as the name of the generic function (that is, as the operator).

FMAKUNBOUND can disrupt the correct functioning of this tool.
FMAKUNBOUND, when applied to a symbol with which a generic function is
associated, removes the generic function definition from the function cell
of the symbol.  FMAKUNBOUND cannot cause generic functions to behave
inconsistently with respect to their invocation semantics. 
[(SETF (SYMBOL-FUNCTION ...) ...) also cannot disrupt invocation semantics.]

Let's look at an example. Suppose the user writes

(DEFMETHOD FOO ((X C)) ...)

The tool that displays generic functions for the class C will undoubtedly
display FOO by name. What does the class C store? It can store only the
symbol, FOO, or it can store not only the symbol, FOO, but also the
generic function stored in FOO's function cell.  If the user does
(FMAKUNBOUND 'FOO) and the symbol alone is stored with the class, the tool
might display the wrong thing; if the user then does a second DEFMETHOD on
FOO, then the tool will very likely display the wrong thing. If the class
stores the symbol and the generic function, the tool can, after the
FMAKUNBOUND, display the anonymous generic function without the associated
name, FOO - assuming mutability of generic functions.

Possibly implementations that support tools like the one above will need a
function whose name could be REMOVE-GENERIC-FUNCTION-FROM-CLASS-LATTICE,
which removes from the class lattice all references to this generic
function. The primary client of this function will be the environment
tools.

Here is an example of some behavior I'd expect to see:

(DEFMETHOD FOO ((X C)) (FORMAT T "FOO, version 1, called on ~S~%" X))

<request to show the methods on C displays #<GENERIC-FUNCTION FOO>
and #<METHOD-OBJECT FOO> or something like that>
 
(FOO X) ;X an instance of C

causes

FOO, version 1, called on <X>

to be printed.

(SETQ BAZ #'FOO)

(FMAKUNBOUND 'FOO)

<request to show the methods on C displays #<GENERIC-FUNCTION 7128161>
and #<METHOD-OBJECT 86018603> or something like that>
 
(FOO X) ;X an instance of C

signals an error.

(DEFMETHOD FOO ((X C)) (FORMAT T "FOO, version 2, called on ~S~%" X))

<request to show the methods on C displays #<GENERIC-FUNCTION 7128161>
and #<METHOD-OBJECT 86018603> or something like that, and
#<GENERIC-FUNCTION FOO> and #<METHOD-OBJECT FOO> or something like that>

(FOO X) ;X an instance of C

causes 

FOO, version 2, called on <X>

and nothing else, to be printed.

(FUNCALL BAZ X) ;same X

causes

FOO, version 1, called on <X>

(SETQ BAZ NIL)

results in a situation in which the tool displays things that might
confuse the user. At this point the user might like to clean up the
environment

Now let's turn our attention to naming. Suppose someone writes:

;;; Define a recursive generic function
(DEFMETHOD FOO ((X C)) 
 ;; Do something useful
 (MUNCH X)
 ;; Do something related on a related class.
 (FOO (SOME-OTHER-CLASS X)))

(SETF (SYMBOL-FUNCTION 'BAZ) #'FOO)

(DEFMETHOD FOO ((X C1)) ...)

Oh dear, (BAZ <c, an instance of C>) might lose because the recursive call
in FOO refers to some other generic function than the one supposedly
intended when the code for the first DEFMETHOD on FOO was written.  Well,
we face the same problem with normal functions, and LABELS is used to
solve that:

(DEFUN FACT (N)
 (LABELS ((FACT (N) (IF (ZEROP N) 1 (* N (FACT (1- N))))))
  (FACT N)))

(FACT 47)
258623241511168180642964355153611979969197632389120000000000 

(SETF (SYMBOL-FUNCTION 'BAZ) #'FACT)

(DEFUN FACT (X)
 (FORMAT T "Adding ~S as a fact to the database!~% X)
 (ADD-FACT X)
 T)

(BAZ 47)
258623241511168180642964355153611979969197632389120000000000 

We should be able to define generic functions and methods that have this
degree of insulation from the accidents of naming.  Unless we define
something like GENERIC-FUNCTION-LABELS, the definition of such
self-contained generic functions will be ugly, containing FUNCALLs.

Some people have questioned whether it is a reasonable style to
write methods locally when it is clear that the intended purpose
of the standard is to let people write DEFMETHODs all over the place.

At the start of this message I mentioned several important things that
generic functions buy us. I will now paraphrase and expand on point number
2 above:


	   The concept of generic functions gives us the ability to
	   formulate the definition of a generic function as the
	   accumulation of methods, each modularly defined and each
	   specifically applicable to a set of classes. This enables the
	   programmer to formulate his code in natural pieces and to have
	   them assembled by the generic-function-calling mechanism.

The point behind my `lexically defined generic function' proposal is to
recognize and promulgate this programming methodology.  If it is a good
methodology to define generic functions that are associated with symbols
using this modular approach, then it should be a good methodology to
define anonymous generic functions the same way.  Using MAKE-GENERIC and
ADD-METHOD it is possible to do this, but at the expense of unreadable
code.

There is a second sort of `local' definition of methods that could make
sense - it is the one to which Gregor alluded in his message about my
anonymous generic function proposal. Suppose that a set of methods on the
symbol, FOO, has been defined. In a dynamic context the user might want
to temporarily extend FOO. I will use the name DFLET-METHOD; the user can
write:

(DFLET-METHOD ((FOO ((X C)) ...)) <form>)

and temporarily extend the generic function FOO to have this new method
associated with it during the execution of <form>. This, also, is a
reasonable programming methodology. I was curious about why Gregor thought
I meant something like DFLET-METHOD in my lexical generic function
proposal, even though I think my proposal was relatively clear on my
intention. I believe it is because Gregor thinks in terms of methods and
not in terms of generic functions.  In this long message I have used the
term `generic function' relentlessly, and I have made the distinction
between generic functions and methods clear.

Moon raised the objection that because no one has experience with lexical
generic functions they should not be considered for inclusion as part
of the standard. People have had experience with DEFMETHOD, and people
have had experience with FLET/LABELS. Therefore the combination of them is
not a far-out concept. No one has had experience with meta-objects and
method combination in one system, so should we invoke Moon's design
principle to exclude from consideration a system that has both?

In writing a standard, one tries to take well-known programming language
constructs and methodology and from them make reasonable improvements and
meldings.  Certainly when Common Lisp was being defined some risks were
taken in terms of adopting constructs that few people had experience with.
FLET/LABELS was familiar mostly to Steele and myself; the style of
multiple values adopted was sufficiently unlike others to be considered a
radical departure. The sequence functions were relatively unknown.

Let me relate the tale of TEX. Don Knuth designed TEX in 1977, and TEX78
contained one or two very powerful ideas for typesetting. The power of
these ideas captured the attention of people who care about typesetting
and beautiful manuscripts, to the extent that these people made a major
effort to convert their old documents to TEX.

Over a period of 4 years TEX was in heavy use, and people found that some
of the things they wanted to do were nearly impossible; people also found
that there were various TEX parameters that they wanted to control in
their macros. As with most non-Lisp-like languages, the macro facilities
were horrible.

Because Knuth adopted the design principle of retaining the existing
structure of TEX78 while taking strong consideration of the comments of
his loyal users, he decided to simply re-write TEX *adding* every facility
that was requested. There were approximately 200 of these facilities
added.  Rather than sitting back and thinking about what these critiques
meant - all suggestions for improvements are really critiques - and
re-designing TEX, he just added them to TEX with minimal structural
changes. In fact, the structural changes were mostly those needed to
accomodate the facilities the users requested.

When I hear people state that the overriding design consideration for the
object system is the needs that existing users express or that it is
important to retain a familiar structure while adding a few new facilities,
I am reminded of TEX84, the worst (but most powerful) typesetting language
in existence by far. Yes, we should keep the past firmly in mind, but
not blindly in mind.

∂20-Oct-86  1522	RPG  	Re: Summary of Object Standard Discussions  
To:   Common-lisp-object-system@SAIL.STANFORD.EDU    

Someone writes:

    The other thing that needs to be clarified is exactly when (in
    the course of macroexpanding, compiling, and loading/evaluating a
    DEFMETHOD form, and calling the resulting method function) the
    mapping from name of generic function to generic-function object
    happens.  Also exactly when the mapping from name of class (in a
    specialized parameter) to class object happens.  If we're going to
    include undefining and redefining of these name-to-object mappings
    in the language, rather than treating them as write-once relations,
    we have to be more precise about when the lookups in these mappings
    happen.  This is probably not very hard.

The mapping from generic function name to generic-function object
happens precisely at the same time that the mapping from function name
to function object happens in Common Lisp. Presumably DEFMETHOD acts like
DEFUN in its timing behavior. DEFMETHOD, I guess, acts like this:

	   (let ((gf (symbol-function <the symbol in question>)))
	    (unless (generic-function-p gf)
		    (setf (symbol-function <the symbol in question>)
			  (make-generic ...)))
	    (add-method gf <a right thing> <another right thing>)
	    <the symbol in question>)

This answer to the `mapping time' question reveals one of the beauties
of making generic functions first-class objects which are also functions:
The user does not need to learn anything new about how to treat calling
generic functions - they act exactly like Common Lisp functions.

The quote above includes the following:

	...calling the resulting method function...

I don't believe our agreed-upon specification mentions whether it is
possible to directly call a method function except by having a pointer to
it before it became incorporated into a generic function.

	;;; Define a function
	(flet ((foo (x) ...))
	 ;; make it a method for gf
         (add-method gf '((x c)) #'foo)
	 ;; call the method function just added
	 (foo <instance of c>)
	 ;; call the generic function, gf, which causes the
	 ;; method function just added to be called
	 (gf <instance of c>)

We have not decided whether

	(funcall (get-method ...) ...)

is valid.

I'll let the rest of you discuss the class-name to class-object mapping
question.

By the way, the `tools' problem I mention in the long `remarks' message
and the problem of the system retaining `stale' pointers to generic
functions can both be solved by weak pointers, as Danny mentions. I think
there is no particular problem with weak pointers for stock hardware.

			-rpg-

∂20-Oct-86  1759	Bobrow.pa@Xerox.COM 	Re: Method combination -- writeup for revised syntax  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Oct 86  17:59:38 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 OCT 86 17:13:20 PDT
Date: 20 Oct 86 17:11 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Method combination -- writeup for revised syntax
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Wed, 15 Oct 86 23:39 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: common-lisp-object-system@SAIL.STANFORD.EDU
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861020-171320-1149@Xerox>

Mostly I agree with the description provided of the CONTEXT so I will
only comment on small pieces.

    To compare the precedence of two methods, examine their
    parameter specializers in order from left to right.

This needs to be modified to take into account
:argument-precedence-order. 

How about:


    To compare the precedence of two methods, examine their
    parameter specializers in order specified by their generic
    function.  This is by default, left to right.

Also, I don't like the term "parameter specializers".  After your
description of how to extend the implementation of method selection to
all types, I think I would almost be happy going back to calling these
things "type-specifiers".

------

Method-combination -- Details

Rationale:

  I would like the facilities used in define-method-combination to be
the same as those used by people using the meta-object protocol.
Hence, I want a more imperative format.  However, I do like to supress
details from that users need not see.   

I also would rather have one simpler version of
define-method-combination.  Here is my next attempt, taking into account
your set of suggestions.

(DEFINE-METHOD-COMBINATION name ({method-option-keyword argument}*)
{form}+)

method-option-keywords include
  :DESCRIPTION format-string
  :DOCUMENTATION doc-string
  :QUALIFIER-SET ({qualifier}*) 
   a list of qualifiers such that at least one must appear in every
non-null qualifier set.  This is my solution to your checking problem.
It causes an error to be signalled for a method that does not satisfy.

NOTE: I have purposely omitted the lambda-list since the only place
where I saw it used was to allow a parameterized ordering, and thw added
complication did not seem worth it.  If it is, then perhaps it can be
put in the options.  
---
The form argument can involve the following primitives, most of which
are the same as those documented in your message.  Those I only mention
without comment, I am implicitly agreeing with.  Selecting methods is
described below.


MAKE-METHOD-CALL method-list &key :operator :around
  It is fine with me to combine MAKE-METHOD-CALL to take an around
argument.  
I think it is fine for make-method-call to take just a method object
instead of a list of one element
  
MAKE-METHOD-FROM-FORM form

METHOD-QUALIFIERS method

METHOD-COMBINATION-ERROR format-string &rest args

WRAP-AROUND-METHODS around-methods form



** Selecting Methods**

Methods are selected from the generic function from those applicable
using these forms.  This allows the user to define their own bindings if
that is a preferred style, or to put them in-line.  I propose two
primitives FIND-METHODS and SORT-METHODS.  Both seem to be required in
the general case.

The version that has the mimimum number of arguments is
  (FIND-METHODS &optional filter) 
 returns a list of args satisfying the simple filter

Then one uses:
 (SORT-METHODS order method-list) 
where order is one of :MOST-SPECIFIC-FIRST or :MOST-SPECIFIC-LAST 

SORT-METHODS could allow merging
 (SORT-METHODS order method-list-1 &rest method-lists) 


It may be better for coding simple cases to extend FIND-METHODS.
 
  (FIND-METHODS &optional filter order)
and not require a SORT-METHODS in most cases.

I think it would be useful to allow the filter to be written in a simple
boolean language with special forms:
 
(filter-and {qualifier-form}+)
(filter-or {qualifier-form}+)
(filter-not qualifier-form)
(filter-test <function>)     ; applies to the method-qualifier list
({non-key-atoms})  ;  Any list of atoms not starting with
                   ; one of the four reserved words 
                   ; filter-and filter-or filter-not filter-test.
                   ; As usual * matches anything.
atom               ; same as (atom)

I am not attached to the details of this pattern language.
 
*****
Additional Keywords

   :INCLUDE-DEFAULT-METHODS boolean

I argue against this on grounds that one should be explicit in labelling
methods.

   :SELECT one of :FIRST, :LAST, :EVERY, or :REMOVE-DUPLICATES
Why shouldn't this be done in Lisp. 

:ARGLIST list of forms

   Is this important?  I can't really evaluate this.

 


*****
To summarize where I stand today on the issues at the end of your last
message:

    (1) Should there be a declarative thing that binds variables to
    lists of methods, or should that be done imperatively?  (Moon's
    message lists some problems with the imperative approach).


No since I believe the problems you mention can be taken care of by a a
method-combination-option

    (2) Can the method-selections and the forms be combined into a
    template (built up from macros?) that puts the method-selections
    right where the method-calls will go in the result?

Sure; we could use 
  (CALL-ALL-METHODS filter order operator around)
with the obvious interpretation (loosely speaking)
  (MAKE-METHOD-CALL (FIND-METHODS filter order) operator around)
It is OK with me if we make CALL-ALL-METHODS have keyword syntax; I have
no religious beliefs on this subject.

    (3) Naming and syntax of functions such as make-method-call.

I am reasonably happy with your name and description.

   (4) "OR" qualifier-patterns.

Uses a filter-pattern language.

*****
Examples:

(define-method-combination :around+daemon
   (:description "Default combination")
   (wrap-around-methods (find-methods (:around))
    `(multiple-value-prog2
       ,(call-all-methods :before)
       ,(make-method-call :around t
         (or (find-methods)
             (method-combination-error "A primary method is required.")
)
       ,(call-all-methods :after :most-specific-last))))

(define-method-combination :and (:description "and combination)
    (call-all-methods (filter-or (:and) nil) :most-specific-first 'and)









 
 

∂20-Oct-86  1923	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Instance transformation protocol proposal  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 Oct 86  19:22:11 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 138575; Mon 20-Oct-86 22:20:53 EDT
Date: Mon, 20 Oct 86 22:20 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Instance transformation protocol proposal
To: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <861020-080119-1375@Xerox>
Message-ID: <861020222040.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 20 Oct 86 08:01 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

	[Kempf]
	pg. 7-How is automatic updating of instances done when
	it is redefined? Are there any hooks for user defined
	transformation of instance state? For class state (re. :CLASS
	option above)? Is there some way for a user to override this? 

I don't know about CommonLoops, but in Flavors the same interface is used for
both ways that an instance can be transformed: (1) Redoing a DEFFLAVOR (aka
DEFCLASS) with different attributes such that the stored representation of
instances is changed; (2) CHANGE-INSTANCE-FLAVOR (aka CHANGE-CLASS).  I'll
assume we're talking about both of these.

An apparently separate issue is whether the user has a hook invoked when
class variables are added or deleted.  The easiest way to do this would be
as a metaclass method?  I'm going to ignore this for now.

    The hook in CommonLoops for handling updating of obsolete instances is a
    generic function that has as arguments the old (obsolete) instance, an
    instance of the changed class, the old (obsolete) class and the new
    (changed) class.  The first two arguments allow users to write code
    directly that updates the instances (the states of the two instances
    will be switched at the end).  The last two arguments allow
    specialization depending on the meta-classes of the objects.  I agree
    that we should discuss this in more detail and look how Flavors does it.

This assumes that the old and new instance are distinct objects.  In some
implementations the instance can be updated in place, which gives better
performance by not messing up data structure locality.  More importantly, I
don't see how slot accessors can be applied to the old instance, since any
attempt to access it is supposed to update it, in case (1) above.  Also, I'm
not sure what you mean by "the states of the two instances will be switched at
the end."

To try to answer these questions, I went to the PCL source, but the version on
parcvax:/pub/pcl/class-prot.l doesn't seem to work anything like the way you
describe (perhaps it's an old version).  It wasn't obvious which generic
function associated with change-class is the one that the user is supposed to
specialize with her own methods.  Anyway, as far as I can tell the slot
contents of the old instance are passed around in the form of a property list
and there isn't an "old instance" object.

Right now Flavors provides a minimal interface; methods for the generic
function flavor:transform-instance receive only the instance as their
argument.  Slots with the same name in the new and old flavors retain their
contents; other slots of the new flavor are initialized to their default
values, if any.  If a slot is deleted the method has no way to find out what
its value used to be.  User suggestions that I have recorded:
(a) Pass the old slots' values to the method as &key arguments.
(b) Pass an alist or property list of slot names and values to the method;
this could either be all of the old slots, or just the deleted slots.  The
latter would be more efficient but would require something like
  (getf deleted-slots slot-name (slot-value instance slot-name))
to get the old value of a slot.
(c) Pass a list of names of newly-introduced slots to the method.
(d) Allow the default value for newly-introduced slots of old instances
to be different from the default value for freshly-created instances.
(e) Pass the old and new flavor objects as arguments to the methods.
Similarities to the PCL implementation are evident.

My comments on the above suggestions:
(a) Bad idea, it uses up all the argument positions in the argument list.
(b) Pass a property list of just the deleted slots.
(c) Provide a function to compute this from (e).
(d) This can be simulated, using (c), by writing a method, except for
preventing the normal default value form from being evaluated.  Unless
we can think of a non-complicated way for the user to exert closer
control, simulating it is probably good enough.
(e) Good idea.

THUS I PROPOSE:

(defgeneric transform-instance
	    (instance		;already transformed to new class
	     deleted-slots	;plist of slot names and values
	     new-class
	     old-class))

(defun new-slot-names (new-class old-class)
  (set-difference (class-slot-names new-class) (class-slot-names old-class)))

When a method for transform-instance receives control, all system actions for
transforming the instance have already taken place.  This is necessary to
avoid infinite recursion when applying slot accessors to the instance.
Transform-instance is only called if there are applicable methods
(equivalently, there is a default method that does nothing).

When a slot with no value is deleted, its entry in deleted-slots has nil as
the value.

∂21-Oct-86  0703	DLW@ALDERAAN.SCRC.Symbolics.COM 	Instance transformation protocol proposal 
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 21 Oct 86  07:02:57 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12850; Tue 21-Oct-86 10:01:49 EDT
Date: Tue, 21 Oct 86 10:08 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Instance transformation protocol proposal
To: Moon@STONY-BROOK.SCRC.Symbolics.COM,
    common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <861020222040.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <861021100835.6.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Mon, 20 Oct 86 22:20 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    This assumes that the old and new instance are distinct objects.  In some
    implementations the instance can be updated in place, which gives better
    performance by not messing up data structure locality.

If by "locality" you mean "locality of reference" in the sense of demand
paging, I don't think this is the real issue.  Much more important is
the semantic issue.  When you change the class definition, and you have
in your Lisp world a bunch of existing data structure, you'd like all of
the instances contained in that structure to automatically behave in
accordance with the new class definition.  This is valuable for
incremental program development.  Old flavors could not do this, and we
received complaints from many quarters about the lack.  I know you know
this but I wanted to make sure that the point was made explicit in this
discussion.

∂21-Oct-86  0711	RPG   	Re: Remarks on Generic Functions 
 ∂20-Oct-86  1923	Masinter.pa@Xerox.COM 	Re: Remarks on Generic Functions     
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Oct 86  19:20:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 OCT 86 18:29:21 PDT
Date: 20 Oct 86 18:28 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Remarks on Generic Functions 
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 20 Oct 86
 14:55 PDT
To: RPG@SAIL.STANFORD.EDU
cc: masinter.pa@Xerox.COM
Message-ID: <861020-182921-1269@Xerox>

I think your message did well at explaining the role of generic
functions for purposes other than program modularity.

I think the arguments against including it in the standard at this time
rest more the belief that, while this is probably a reasonable
extension, there is no reason it couldn't be simply added in later. (It
is not possible, for example, to add "meta-objects" later to an
implementation that didn't use them.)

Do you believe there anything intrinsic about a GENERIC-FUNCTION-LABELS
that would prevent it from being added later?

If so, this should in itself give us pause, as we've not alloted a lot
of time for serious implementation design work. 

If not, then we can happily defer this important capability to a later
deliberation, with the comfort that we will not be caught in a "TeX84"
situation.

Masinter.pa@xerox/su
Re: Remarks on Generic Functions

Larry, something like GENERIC-FUNCTION-LABELS could be added later.
Perhaps that would be a good idea, because the syntax possibilities are
not totally satisfying. However, I'm interested in pressing the argument
in order to press an examination of the ramifications of the idea on the
nature of generic functions. That is, I think that the funny syntaxes I
proposed are the best available, and the funniness of them, plus the
behavior of the resulting lexical generic functions, might point to
weaknesses with the concept of generic functions, which we need to explore
now.

Similarly, the pieces of code I sent in which methods are made out of
existing complexes of LABELS-defined functions points out some funny
corners. Even if we don't include lexical generic functions, these
problems should be explored to some depth.

One other solution I've looked at, but not proposed, is an extension to
Common Lisp itself, which is:

	(function-let ((f (make-generic)))...)

which lets people bind lexical variables to things that must evaluate to
functions and to then use them as operators:

	(function-let ((f (car l))
		       (g (aref foo 7 8)))
         (+ (f 1 2) (g 3 4)))

This is a useful construct for Common Lisp even without Commonloops.
With it we can simply use ADD-METHOD to extend the generic function
and to name the generic functions reasonably.

			-rpg-

∂21-Oct-86  0928	kempf%hplabsc@hplabs.HP.COM 	Re: Remarks on Generic Functions    
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 21 Oct 86  09:28:29 PDT
Received: from hplabsc by hplabs.HP.COM ; Tue, 21 Oct 86 09:27:31 pdt
Received: by hplabsc ; Tue, 21 Oct 86 09:27:26 pdt
Date: Tue, 21 Oct 86 09:27:26 pdt
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8610211627.AA23114@hplabsc>
To: common-lisp-object-system@sail.stanford.edu
Subject: Re: Remarks on Generic Functions

RPG's note on generic functions seems to clarify the proposal for
anonomyous generic functions. However, there seemed to be two 
contradictory lines of thinking with regard to the relationship
between methods (particularly *multi*methods) and classes.

Under the 3 advantages of generic functions was listed:

>	3. The separation of the inheritance of behavior from placement of
>	   code. Generic functions select methods based on the structure
>	   of the class lattice, but the generic functions are not
>	   constrained to be stored within that lattice.

However, later on in the note when the relationship between generic
function objects and names is being clarified, the following example
is presented:

>The tool that displays generic functions for the class C will undoubtedly
>display FOO by name. What does the class C store? It can store only the
>symbol, FOO, or it can store not only the symbol, FOO, but also the
>generic function stored in FOO's function cell.  If the user does
>(FMAKUNBOUND 'FOO) and the symbol alone is stored with the class, the tool
>might display the wrong thing; if the user then does a second DEFMETHOD on
>FOO, then the tool will very likely display the wrong thing. If the class
>stores the symbol and the generic function, the tool can, after the
>FMAKUNBOUND, display the anonymous generic function without the associated
>name, FOO - assuming mutability of generic functions.

In fact, with multimethods, the association is not between a class and
a generic function but rather between the typed lambda list and the
generic function. That is, it would be possible to have two methods
defined as:

(DEFMETHOD FOO ((X C1) (Y C2))
  <code to do FOO>
)

(DEFMETHOD FOO ((X C1) (Y C3))
  <code to do FOO>
)

and in neither case could one say that the method was associated with
a particular class, as would be the case with classical methods.

The implications of this need some thought. In particular, the idea
of operation inheritence, as it is "traditionally" seen in object
oriented systems, can no longer, I think, be relied upon to structure
tools, etc. which deal with generic functions and multimethods.
The lack of a distinguished argument provides no "hook" through which
operation inheritence can work.

A notion from algebraic typing theory which may be of interest in 
this regard is "type conformity", which is used in some of the
statically typed object oriented languages (Trellis/Owl, Emerald).
Without specifying the exact algorithm, a class C conforms to
another class D if C provides at least the operations of D. In
addition, the results of C's operations must conform with those of
D, and the types of the arguments must conform in the opposite direction,
i.e., the arguments of D's operations must conform to those of C.
Since the current standard has no notion of a type (or class) signature,
in which a type declares it's abstract interface, it is not clear
how this notion could be formally fit into Classes.
Further modifications for Lisp (i.e., leaving out the typing of results)
would be needed; however, this is a pretty radical departure from
most existing notions of inheritence, and so would probably be best
left out of the standard. But it might be useful for structuring
thinking, particularly about tools which need to deal with multimethods
and classes.

As far as the rest of RPG's proposal goes, I think the justification
for anonomyous generics is now clearer. In particular, the (re)naming
semantics need further clarification, modulo Moon's comments, perhaps
the proposed local scoping constructs would help.

		Jim Kempf		kempf@hplabs

∂21-Oct-86  1049	Gregor.pa@Xerox.COM 	Instance transformation protocol proposal   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Oct 86  10:49:07 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 21 OCT 86 10:33:23 PDT
Date: Tue, 21 Oct 86 10:32 PDT
From: Gregor.pa@Xerox.COM
Subject: Instance transformation protocol proposal
To: Moon@StonyBrook.SCRC.Symbolics.com
cc: Common-Lisp-Object-System@Sail.Stanford.edu
Message-ID: <861021103246.4.GREGOR@AVALON.isl.parc.xerox.com>
Line-fold: no


In CommonLoops, the same interface is used for both ways that an
instance can be transformed also.

In CommonLoops, the entrypoint function is change-class.  It takes an
instance, and a class to change that instance's class to.  Their is a
documented, internal function which takes the old instance and a new
"temporary instance" as arguments.  The user can supply specific methods
for the internal function to convert instances from one class to
instances of another class.

For example:

(defclass point () ())
(defclass x-y-point (point) (x y))
(defclass rho-theta-point (point) (rho theta))

(defmethod change-class-internal ((x-y x-y-point) (r-t rho-theta-point))
  (with-slots (x-y r-t)
    (multiple-value-setq (rho theta) (convert-to-r-t x y))))

(defmethod change-class-internal ((r-t rho-theta-point) (x-y x-y-point))
  (with-slots (x-y r-t)
    (multiple-value-setq (x y) (convert-to-x-y rho theta))))


As Moon pointed out, the code in the version of PCL currently on vaxc
doesn't work this way.  The correct code (which will soon be on vaxc) is:

(defmeth change-class ((object object) new-class)
  (let ((old-class (class-of object)))
    (let ((new-object (make new-class)))
      (change-class-internal object new-object)
      (setf (iwmc-class-class-wrapper object) (wrapper-of new-class)
	    (iwmc-class-static-slots object) (iwmc-class-static-slots new-object)
	    (iwmc-class-dynamic-slots object)  (iwmc-class-dynamic-slots new-object))
      object)))

(defmeth change-class-internal ((old object) (new object))
  (let ((all-slots (all-slots old)))
    (iterate ((name in all-slots by cddr)
              (value in (cdr all-slots) by cddr))
      (put-slot-always new name value))))
-------

∂21-Oct-86  1111	DLW@ALDERAAN.SCRC.Symbolics.COM 	Remarks on Generic Functions    
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 21 Oct 86  11:11:02 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12957; Tue 21-Oct-86 14:09:16 EDT
Date: Tue, 21 Oct 86 14:16 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Remarks on Generic Functions 
To: RPG@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: The message of 20 Oct 86 17:55 EDT from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Message-ID: <861021141601.3.DLW@CHICOPEE.SCRC.Symbolics.COM>

I read your long note.  I don't disagree with anything in it.  The
principles all make sense.  My reservation about the lexical generic
function feature is only that I still have yet to see a realistic
example in which it's genuinely useful.  This, by itself, still isn't
much of an objection.  However, I'm afraid of getting a reaction from
the users and the other implementors, saying "this is all too big and
complicated, what's all this extraneous stuff for, don't these losers
have any appreciation for simplicity" and so on.  I used to scoff at
that sort of complaint, but I've been getting more sensitive to it as
time goes on.  These days I can often answer it with "Well, there were a
few users who really needed this ability, and the only way to make you
happy would be to make it so these users could not get their job done."
In this case, I don't think I'd be able to use that defense.  The best
defense of the "extra" feature is symmetry and completeness.  However,
if Common Lisp were fixed to be a lot more symmetrical and complete than
it is now, it would get significantly larger, and people already complain
that it's too large.  I think this comes down to a question of engineering
judgement, and I don't think the answer is obvious.

∂21-Oct-86  1130	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Computing the class precedence list    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Oct 86  11:30:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 139162; Tue 21-Oct-86 14:28:42 EDT
Date: Tue, 21 Oct 86 14:28 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Computing the class precedence list
To: Common-Lisp-Object-System@SAIL.STANFORD.EDU
In-Reply-To: <861020-092113-1436@Xerox>
Message-ID: <861021142829.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 20 Oct 86 09:21 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>
    ....
    Did you actually run Gregor's code over all of the Flavors system to
    find these bugs, or did you just think.  If the former, are there any
    cases actually in your system that the code does not work for?

I just thought.  I can't easily run that code over all flavors defined in
my machine because the c-l-o-s ordering is weaker than Flavors ordering,
because you made us take out the :component-order option.  Probably I can
figure out how to add that to your code, but it was too much for me the
other day.  If you send me an algorithm that works on easy examples, I'll
see if I can work up the energy to run it over all flavors on my machine.

Stepping back a bit, I'm not sure why you're spending so much time and
energy trying to find a new algorithm to implement the constraint
satisfaction when there is already an algorithm that works.  I'd rather
be spending my time on getting a draft document out by early December.

∂21-Oct-86  1220	RPG   	Re: Remarks on Generic Functions      
 ∂21-Oct-86  1121	masinter.pa@Xerox.COM 	Re: Remarks on Generic Functions     
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Oct 86  11:21:40 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 OCT 86 10:50:42 PDT
Date: 21 Oct 86 10:50 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Remarks on Generic Functions  
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 21 Oct 86
 07:11 PDT
To: RPG@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <861021-105042-1775@Xerox>

why not rename your proposed "GENERIC-FUNCTION-LABELS" to be "LABELS"?
(Its upward compatible, no?)

masinter.pa@xerox/su
``GENERIC-FUNCTION-LABELS'' => ``LABELS''
The second syntax is compatible. The second syntax is probably easier
to read than the first.
			-rpg-

∂21-Oct-86  1320	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Summary of Object Standard Discussions 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Oct 86  13:19:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 139282; Tue 21-Oct-86 16:11:35 EDT
Date: Tue, 21 Oct 86 16:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Summary of Object Standard Discussions 
To: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <861020-092846-1454@Xerox>
Message-ID: <861021161112.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 20 Oct 86 09:28 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

	(1) Functions that take an argument that can be either a
	generic function object or the name of a generic function
	(remove-method and method-combination-type are examples) will
	accept a list (SETF foo) as the name of the generic function that
	gets defined when you do (DEFGENERIC-SETF foo ...).

	or

	(2) A new function is introduced that translates from a generic
	function object or its name to another generic function object, the
	-setf one.

	or

	(3) Common Lisp is extended to expose the primitives underlying
	DEFSETF, one of which is essentially the function proposed in (2).

    I am happy with 1, and like 3 as well.  It seems that 2 without 3 is an
    inappropriate extension.  Let us push for 3 in the larger committee.

OK, let's go with with (1) in the document.  This affects all functions
that accept either a generic function object or the name of a generic
function as an argument.  We can make a note to suggest someone look
into (3) separately.

∂21-Oct-86  1601	Bobrow.pa@Xerox.COM 	Re: Computing the class precedence list
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Oct 86  16:01:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 OCT 86 14:15:52 PDT
Date: 21 Oct 86 12:01 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Computing the class precedence list
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Tue, 21 Oct 86 14:28 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861021-141552-1089@Xerox>

    Stepping back a bit, I'm not sure why you're spending so much
    time and energy trying to find a new algorithm to implement the
    constraint satisfaction when there is already an algorithm that
    works.  I'd rather be spending my time on getting a draft document
    out by early December.

We are not spending much time, but I like having a single pass algorithm
I can understand, and explain.  Onward and upward.


-- danny

∂21-Oct-86  1602	Bobrow.pa@Xerox.COM 	Re: Remarks on Generic Functions  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Oct 86  16:01:49 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 OCT 86 14:21:35 PDT
Date: 21 Oct 86 13:13 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Remarks on Generic Functions
In-reply-to: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>'s message of Tue,
 21 Oct 86 09:27:26 pdt
To: kempf%hplabsc@hplabs.HP.COM
cc: common-lisp-object-system@sail.stanford.edu
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861021-142135-1106@Xerox>

        The tool that displays generic functions for the class
        C will undoubtedly display FOO by name. What does the class C
        store? It can store only the symbol, FOO, or it can store not
        only the symbol, FOO, but also the generic function stored in
        FOO's function cell.  If the user does (FMAKUNBOUND 'FOO) and
        the symbol alone is stored with the class, the tool might
        display the wrong thing; if the user then does a second
        DEFMETHOD on FOO, then the tool will very likely display the
        wrong thing. If the class stores the symbol and the generic
        function, the tool can, after the FMAKUNBOUND, display the
        anonymous generic function without the associated name, FOO -
        assuming mutability of generic functions.

    In fact, with multimethods, the association is not between a
    class and a generic function but rather between the typed lambda
    list and the generic function. That is, it would be possible to
    have two methods defined as:

    (DEFMETHOD FOO ((X C1) (Y C2)) <code to do FOO>
    )

    (DEFMETHOD FOO ((X C1) (Y C3)) <code to do FOO>
    )

    and in neither case could one say that the method was
    associated with a particular class, as would be the case with
    classical methods.

    The implications of this need some thought. In particular, the
    idea of operation inheritence, as it is "traditionally" seen in
    object oriented systems, can no longer, I think, be relied upon to
    structure tools, etc. which deal with generic functions and
    multimethods. The lack of a distinguished argument provides no
    "hook" through which operation inheritence can work.

With respect to multimethods, one way to think about signatures is as
follows.  Every method takes a tuple of required arguments of some
specified type.  If no type is specified, then that is equivalent to
specifying the type T.  We can think of the tuple of k-types as defining
a type lattice or order k.  The tuple <boat, position> is a 2-type. 

We define k-type-1 to be a subtype of k-type-2 iff each of the elements
of the k-type-1 are a (not necessarily proper) subtype of the
corresponding element of k-type-2.  Thus, <submarine,position> is a
subtype of <boat, position>, but   <boat, position> and <submarine, T>
are incomparable. 

Tools usually do not keep track of these tuple-types.  They usually keep
track of classes, and each class participates in any number of such
types or the multimethods defined on those types.  One would expect that
C1 would have associated with it (somehow) the two methods defined
above, for the types <C1 C2> and <C1 C3>.  By associated here I mean
accessible and distinguishable say for a browser of classes.  

In the environment we built for CommonLoops, asking a class for methods
associated with it produced a list of signatures that identified the
methods
 e.g. ((FOO C1 C2) (FOO C1 C3) (BAR C1)(BAZ T C1) ...)
For methods of anonymous generic functions, one might expect signatures
such as 
(#<generic 1261524> C1 C7>).

If the classes are to show only named generics, then only the names need
be stored, and the conversion to appropriate method signatures can be
done by search at request time.  Anonymous generics would then not be
seen in the environment, thought they would still work.      

∂21-Oct-86  1604	Gregor.pa@Xerox.COM 	Re: Summary of Object Standard Discussions  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Oct 86  16:02:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 OCT 86 14:56:11 PDT
Date: 21 Oct 86 14:56 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: Summary of Object Standard Discussions 
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Tue, 21 Oct 86 16:11 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <861021-145611-1163@Xerox>

I probably should have answered this before, sorry.

	From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
	Subject: Re: Summary of Object Standard Discussions 

	(1) Functions that take an argument that can be either a
	generic function object or the name of a generic function
	(remove-method and method-combination-type are examples) will
	accept a list (SETF foo) as the name of the generic function that
	gets defined when you do (DEFGENERIC-SETF foo ...).

	or

	(2) A new function is introduced that translates from a generic
	function object or its name to another generic function object, the
	-setf one.

	or

	(3) Common Lisp is extended to expose the primitives underlying
	DEFSETF, one of which is essentially the function proposed in (2).


I think we are going to have to have #2 in order for people to be able
to write many simple meta-object extensions.  I think #1 is a nice
interface to this for some functions.  I think Common Lisp should do #3,
as well as fix some of the existing bugs with setf.

So, for now I think we should do 1 and 2.

∂21-Oct-86  2302	DUSSUD%Jenner%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: Summary of Object Standard Discussions   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 21 Oct 86  23:01:58 PDT
Received: from ti-csl by csnet-relay.csnet id ab09207; 21 Oct 86 18:21 EDT
Received: from Jenner (jenner.ARPA) by tilde id AA21829; Tue, 21 Oct 86 16:08:30 cdt
To: common-lisp-object-system%su-ai.arpa@csnet-relay.ARPA
Subject:        Re: Summary of Object Standard Discussions
Date:           21-Oct-86 14:06:16
From: DUSSUD%Jenner@ti-csl.CSNET
Message-Id:     <DUSSUD.2739294376@Jenner>


    (1) Functions that take an argument that can be either a
    generic function object or the name of a generic function
    (remove-method and method-combination-type are examples) will
    accept a list (SETF foo) as the name of the generic function that
    gets defined when you do (DEFGENERIC-SETF foo ...).

    or

    (2) A new function is introduced that translates from a generic
    function object or its name to another generic function object, the
    -setf one.

    or

    (3) Common Lisp is extended to expose the primitives underlying
    DEFSETF, one of which is essentially the function proposed in (2).


I think that 3 is not practical because setf forms are not always, or
required to be implemented using DEFSETF. Practically, it is not possible
to get "the" function responsible for implementing the SETF of a form unless
we have the whole setf expression.
Our context is more restrictive. Since we don't need the whole setf expression to figure out
what generic function to use, 2 makes sense.

I would vote for 1 or 2 and reject 3 (we would just ask for trouble pushing for 3).

Patrick.

∂22-Oct-86  1407	RPG  	DEF-GENERIC-OPTIONS
To:   common-lisp-object-system@SAIL.STANFORD.EDU    

My message - entitled ``Remarks on Generic Functions'' - points out the
primacy of generic functions in this standard. With that in mind, it is
time to discuss the nature of DEFGENERIC. Currently the description of 
DEFGENERIC in the draft document reads:


	   The macro DEFGENERIC defines a generic function and stores it
	   in the symbol function cell of the symbol that is its name.
	   The new generic function object is returned as the result.
	   DEFGENERIC allows you to specify options and declarations that
	   pertain to the generic function as a whole.

The question is whether a DEFGENERIC form on a symbol must be evaluated
before any DEFMETHOD forms can be evaluated on that same symbol.

Here are some reasons why it ought to be required. I will follow that with
some reasons why it ought not be required.

	1. Consider the case of anonymous generic functions. It makes no
	   sense to add methods to a generic function that does not exist.
	   Therefore, a generic function must be created with
	   MAKE-GENERIC (or with a GENERIC-FUNCTION-LABELS) before an
	   ADD-METHOD can be performed on it.  Requiring the evaluation of
	   a DEFGENERIC form before the evaluation of any DEFMETHOD forms
	   creates a parallel situation between the symbol-based generic
	   function case and the anonymous generic function case.

	2. A possible mental model for generic functions and methods is
	   that they are like structures and slots.  It does not make
	   sense to create slots for a structure before a structure is
	   created - it is an absurdity. It makes sense to create the
	   values for those slots, but not the slots themselves.
	   Similarly, with anonymous generic functions it makes sense to
	   create the method functions before the generic function is
	   created, but evaluating the ADD-METHOD forms (or their
	   equivalent) must be done later.

	3. Requiring the evaluation of a DEFGENERIC form before the
	   evaluation of any DEFMETHOD forms enforces a programming style
	   in which important objects - generic functions - are defined
	   before they are modified and used.

Here are reasons why evaluating a DEFGENERIC form before the evaluation of
any DEFMETHOD forms should not be required.

	4. The effect of a series of DEFMETHOD forms followed by a
	   DEFGENERIC form is unambiguous. DEFGENERIC merely modifies some
	   of the options and declarations of the generic function, while
	   generic function creation is a separate event that happens when
	   the first DEFMETHOD form on a particular symbol is evaluated.
	   It is only the case of a DEFGENERIC form being evaluated on a
	   symbol for which there is no existing generic function that is
	   in question; in that case DEFGENERIC creates a generic function
	   first.

	5. The programming style of spreading DEFMETHOD forms throughout
	   various file is encouraged. There is no requirement of loading
	   a `declarations' file full of DEFGENERIC forms. There are no
	   issues to decide regarding the re-loading of the declarartions
	   file.

	6. The case of generic functions and methods is analogous to the
	   case of symbols: There is no requirement to define a symbol
	   before it can be used - simply mentioning the print name of a
	   new symbol will cause that symbol to be created and placed in an
	   appropriate package.

	7. There is nothing to prevent programmers from using a more
	   modular style, putting all DEFGENERIC forms ahead of all
	   DEFMETHOD forms.

If we decide that 4 - 7 prevail, I suggest renaming DEFGENERIC, because
the primary function of DEFGENERIC is to specify options rather than 
to define. I propose DEF-GENERIC-OPTIONS, and the first paragraph
of its specification should read:


	   The macro DEF-GENERIC-OPTIONS allows you to specify options and
	   declarations that pertain to a generic function as a whole.  If
	   there is no generic function associated with the symbol
	   function cell of the symbol that is the name of the generic
	   function, a new generic function object is created and stored
	   in the symbol function cell.  The generic function object is
	   returned as the result.

					-rpg-

∂22-Oct-86  1513	Bobrow.pa@Xerox.COM 	Re: DEF-GENERIC-OPTIONS 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Oct 86  15:11:17 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 OCT 86 14:27:54 PDT
Date: 22 Oct 86 14:28 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: DEF-GENERIC-OPTIONS
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 22 Oct 86
 14:07 PDT
To: RPG@SAIL.STANFORD.EDU
cc: common-lisp-object-system@SAIL.STANFORD.EDU
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861022-142754-2255@Xerox>

I believe that 4-7 should hold, and have no trouble with the name
DEF-GENERIC-OPTIONS (except to question the hyphenation -- is it
according to rules).  
	   The macro DEF-GENERIC-OPTIONS allows you to specify options and
	   declarations that pertain to a generic function as a whole.  If
	   there is no generic function associated with the symbol
	   function cell of the symbol that is the name of the generic
	   function, a new generic function object is created and stored
	   in the symbol function cell.  The generic function object is
	   returned as the result.

The second paragraph should read:

            The macro DEFMETHOD will expand into a call to
    DEF-GENERIC-OPTIONS, with only the argument list filled in
    (computed from the DEFMETHOD form).  The rest of the options are
    not specified.  Evaluating DEF-GENERIC-OPTIONS several times is
    allowed, provided specified information does not conflict with
    previously stored information.  If there is a conflict, an error
    is signalled.  Conflicts are:

    1) changing the class of the generic-function causes an error
    (inconsistent metaclasses).

    2) the number of required arguments of the generic function is
    changed. 

    3) other inconsistent changes in the argument list 

Is this complete? correct?
-- danny

∂23-Oct-86  1835	Masinter.pa@Xerox.COM 	Re: Dispatching on optional/keyword arguments  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Oct 86  18:35:22 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 OCT 86 16:07:55 PDT
Date: 23 Oct 86 16:01 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Dispatching on optional/keyword arguments
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Mon, 20 Oct 86 14:07 EDT
To: Common-Lisp-Object-System@SAIL.STANFORD.EDU
Message-ID: <861023-160755-1667@Xerox>

I realize that I was thinking of a different proposal than the one you
had in mind for proposal 8. Call this proposal 9. (Do you think it is
the same as some of the others?)

The proposal I had in mind is as follows.

Methods can only discriminate on arguments that they require.
Discrimination happens only on arguments supplied, based on the method
signatures. 

Different methods need not have conformal argument lists. If, using the
method signatures, a method is selected which requires more arguments
than are supplied, or which allows fewer arguments than are supplied, an
error is signalled.   (The "argument signature" of the generic function
for a combination of methods is derived from the argument signatures of
the methods using a small algebra of argument signatures that I can
write up but for now leave unspecified. The space of argument signatures
includes a "no consistent set of arguments can be specified")

(This specification is not complete, but I hope I've described it well
enough to disambiguate it from other proposals for discriminating on
optionals.)

For example,

(defmethod foo ((a boat) &optional b) ..1..)

(defmethod foo ((a boat) (b number)) ..2..)

will get
..1.. with (foo (make-boat)) 
..2.. with (foo (make-boat) 3) 
..1.. with (foo (make-boat) t)

adding

(defmethod foo ((a boat) (b integer) c) ..3..)

then

..2.. with (foo (make-boat) 3.0)
error with (foo (make-boat) 3)


∂23-Oct-86  1836	Masinter.pa@Xerox.COM 	:TYPE in DEFCLASS?    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Oct 86  18:36:02 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 OCT 86 18:21:35 PDT
Date: 23 Oct 86 18:15 PDT
From: Masinter.pa@Xerox.COM
Subject: :TYPE in DEFCLASS?
To: common-lisp-object-system@sail.stanford.edu
Message-ID: <861023-182135-1785@Xerox>

This was probably just an oversight, but the current document leaves out
the :type slot option. 

It may be that many implementations would just ignore the :type
slot-option, but leaving it out would make it harder to remove
defstruct.

∂23-Oct-86  2337	RPG   	Re: DEF-GENERIC-OPTIONS
 ∂23-Oct-86  1835	Masinter.pa@Xerox.COM 	Re: DEF-GENERIC-OPTIONS    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Oct 86  18:34:58 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 OCT 86 15:51:44 PDT
Date: 23 Oct 86 15:45 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: DEF-GENERIC-OPTIONS
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 22 Oct 86
 14:07 PDT
To: RPG@SAIL.STANFORD.EDU
cc: bobrow.pa@Xerox.COM, masinter.pa@Xerox.COM
Message-ID: <861023-155144-1650@Xerox>

Maybe this is beating a dead horse, so I won't send it out to the whole
list.

Your argument (1) "It makes no sense to add methods to a generic
function that does not exist. Therefore, a generic function must be
created with MAKE-GENERIC (or with a GENERIC-FUNCTION-LABELS) before an
ADD-METHOD can be performed on it."

is an argument for making generic functions immutable, and have
ADD-METHOD return a new generic function rather than modify the old.

Your argument (2) suggests that the mental model for generic functions
and methods as being like structures and slots is inappropriate.  I
suggest a mental model of a property or association list, which can
intially start out empty and have elements attached to it.

Your argument (3) is a strong argument against requiring defgeneric,
since it states that we are enforcing a programming style, but this
style is inconsistent with the current programming style in Loops,
Flavors and Smalltalk and other object-oriented programming languages,
which do not require defining the (equivalent of) the generic function
before modifying it.


- - - - - - 

In your writup of the spec, you don't say what happens if there IS a
generic function already exists for the symbol when DEF-GENERIC-OPTIONS
is called:

	   The macro DEF-GENERIC-OPTIONS allows you to specify options and
	   declarations that pertain to a generic function as a whole.  If
	   there is no generic function associated with the symbol
	   function cell of the symbol that is the name of the generic
	   function, a new generic function object is created and stored
	   in the symbol function cell.  The generic function object is
	   returned as the result.

/sub
masinter.pa@parc
DEF-GENERIC-OPTIONS
1. If ADD-METHOD creates new generic functions all the time (which means that
you cannot build tools to display methods associated with classes and keep
data structures consistent), does this mean that (MAKE-GENERIC) is defined
to be (ADD-METHOD () () ())? Or (ADD-METHOD)?

2. My (2) does not suggest that the structure/slot model is inappropriate,
you do. My (2) reminds you of your belief.

3.  This is the only argument I'm willing to buy.

I thought my description of DEF-GENERIC-OPTIONS fairly clearly, but not
crystal clearly, hinted that DEF-GENERIC-OPTIONS mostly modifies an
existing generic function and that in special cases it creates a new one.

Danny is right in that inconsistencies specified by DEF-GENERIC-OPTIONS
or DEFMETHOD will signal errors.

I am actually somewhat neutral on whether DEFGENERIC should be required. I
would have liked to have seen a complete symmetry between
DEFGENERIC/DEFMETHOD and MAKE-GENERIC/ADD-METHOD, but I guess tradition
will win out over rationality.  I also makes my `critique' paper easier
to write.
			-rpg-

∂24-Oct-86  1321	Masinter.pa@Xerox.COM 	Re: Dispatching on optional/keyword arguments  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 24 Oct 86  13:21:19 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 OCT 86 10:39:30 PDT
Date: 23 Oct 86 18:59 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Dispatching on optional/keyword arguments
In-reply-to: Masinter.pa's message of 23 Oct 86 16:01 PDT
To: Masinter.pa@Xerox.COM
cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
Message-ID: <861024-103930-1108@Xerox>

On review, I may have been describing your option (7), although I think
what threw me was "Can dispatch on optional arguments -- no"; it allows
dispatching on arguments that are optional in *other* methods, e.g.

(defmethod foo ((a boat) &optional b) ..1..)
(defmethod foo ((a boat) (b integer)) ..2..)

(foo (make-boat)) gets ..1..
(foo (make-boat) t) gets ..1..
(foo (make-boat) 3) gets ..2..


∂26-Oct-86  2029	Kahn.pa@Xerox.COM 	Re: Instance transformation protocol proposal 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 86  20:28:56 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 OCT 86 20:03:51 PST
Date: 26 Oct 86 20:03 PST
Sender: Kahn.pa@Xerox.COM
Subject: Re: Instance transformation protocol proposal
In-reply-to: Gregor.pa's message of Tue, 21 Oct 86 10:32 PDT
To: Gregor.pa@Xerox.COM
cc: Moon@StonyBrook.SCRC.Symbolics.com,
 Common-Lisp-Object-System@Sail.Stanford.edu
From: Ken Kahn <Kahn.pa@Xerox.COM>
LineFold: No
Message-ID: <861026-200351-2549@Xerox>

I noticed you used multiple-value-setq inside a with-slots.  As in:

(defmethod change-class-internal ((x-y x-y-point) (r-t rho-theta-point))
  (with-slots (x-y r-t)
    (multiple-value-setq (rho theta) (convert-to-r-t x y))))

I think that is perfectly reasonable but to be consistent shouldn't one add to 
Common Lisp a multiple-value-setf?  In other words, why should this work only 
inside of a with-slots?

----- ken

∂26-Oct-86  2029	Kahn.pa@Xerox.COM 	Re: Remarks on Generic Functions    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 86  20:29:10 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 OCT 86 20:22:05 PST
Date: 26 Oct 86 20:22 PST
Sender: Kahn.pa@Xerox.COM
Subject: Re: Remarks on Generic Functions 
In-reply-to: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>'s
 message of Tue, 21 Oct 86 14:16 EDT
To: DLW@ALDERAAN.SCRC.Symbolics.COM
cc: RPG@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU
From: Ken Kahn <Kahn.pa@Xerox.COM>
Message-ID: <861026-202205-2557@Xerox>

    The best defense of the "extra" feature is symmetry and
    completeness.  However, if Common Lisp were fixed to be a lot more
    symmetrical and complete than it is now, it would get significantly
    larger, and people already complain that it's too large.

I agree that Common Lisp would be larger but in some important sense it
would become simpler.  If one didn't go along with Dick's proposal then
one has to explain generic functions by saying that they are like
functions except that you can't create them in ways analogous to LABELS,
FLET, etc.
In other words, the language becomes more complex because one needs to
remember exceptions.

----- ken

∂26-Oct-86  2029	Kahn.pa@Xerox.COM 	Re: Anonymous Generic Function Proposal       
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 86  20:29:23 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 OCT 86 20:27:14 PST
Date: 26 Oct 86 20:27 PST
Sender: Kahn.pa@Xerox.COM
Subject: Re: Anonymous Generic Function Proposal    
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 14 Oct 86
 16:59 PDT
To: RPG@SAIL.STANFORD.EDU
CC: common-lisp-object-system@SAIL.STANFORD.EDU
From: Ken Kahn <Kahn.pa@Xerox.COM>
Message-ID: <861026-202714-2558@Xerox>

    There is probably only one reasonable way to define anonymous
    generic functions:

    #'(generic-lambda <method-spec>*)

    where <method-spec> is

    	(<qualified lambda list> . <body>)


I would like to see someplace to add generic function options to specify
the generic function class, method combination, argument precedence
lists, etc.  




----- ken

∂26-Oct-86  2029	Kahn.pa@Xerox.COM 	Re: DEF-GENERIC-OPTIONS   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Oct 86  20:29:03 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 OCT 86 20:08:15 PST
Date: 26 Oct 86 20:08 PST
Sender: Kahn.pa@Xerox.COM
Subject: Re: DEF-GENERIC-OPTIONS
In-reply-to: Danny Bobrow <Bobrow.pa>'s message of 22 Oct 86 14:28 PDT
To: Bobrow.pa@Xerox.COM
cc: RPG@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU
From: Ken Kahn <Kahn.pa@Xerox.COM>
Message-ID: <861026-200815-2552@Xerox>

  The macro DEFMETHOD will expand into a call to
    DEF-GENERIC-OPTIONS, with only the argument list filled in
    (computed from the DEFMETHOD form).  The rest of the options are
    not specified.  Evaluating DEF-GENERIC-OPTIONS several times is
    allowed, provided specified information does not conflict with
    previously stored information.  If there is a conflict, an error
    is signalled.  Conflicts are:

    1) changing the class of the generic-function causes an error
    (inconsistent metaclasses).

    2) the number of required arguments of the generic function is
    changed. 

    3) other inconsistent changes in the argument list 

    Is this complete? correct? -- danny

I think 1) is too strict.  Just as there is (or at least was) a protocol
about compatible-metaclass-p in PCL there aught to be some such here.
One may, for example, change the class of the generic function to a
subclass with a little extra functionality.  By the way didn't you mean
"inconsistent meta-objects"?

----- ken

∂27-Oct-86  1216	Bobrow.pa@Xerox.COM 	Re: Anonymous Generic Function Proposal     
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Oct 86  12:15:58 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 27 OCT 86 11:00:17 PST
Date: 27 Oct 86 10:59 PST
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Anonymous Generic Function Proposal    
In-reply-to: Ken Kahn <Kahn.pa>'s message of 26 Oct 86 20:27 PST
To: Kahn.pa@Xerox.COM
cc: RPG@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861027-110017-3052@Xerox>

       There is probably only one reasonable way to define
        anonymous generic functions:

        #'(generic-lambda <method-spec>*)

        where <method-spec> is

        	(<qualified lambda list> . <body>)


    I would like to see someplace to add generic function options
    to specify the generic function class, method combination, argument
    precedence lists, etc.  

Clearly one could do
  (let ((gf (make-instance <generic-function-class>)))
       ... stuff to set method combination, argument precedence lists,
etc
       (add-method gf <method-spec1>) ...)

Syntactic sugar is useful for the most common cases, and the payoff for
adding syntax must be proved.

With this caveat, I would suggest the following possible syntax:

#'(generic-lambda {(:generic-options
<options-from-def-generic-options>)}
        <method-spec>*)


-- danny

∂27-Oct-86  1415	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Instance transformation protocol proposal   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 27 Oct 86  14:15:07 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 143724; Mon 27-Oct-86 17:14:52 EST
Date: Mon, 27 Oct 86 17:13 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Instance transformation protocol proposal
To: Ken Kahn <Kahn.pa@XEROX.COM>
cc: Common-Lisp-Object-System@SU-AI.ARPA
In-Reply-To: <861026-200351-2549@Xerox>
Message-ID: <861027171337.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 26 Oct 86 20:03 PST
    From: Ken Kahn <Kahn.pa@Xerox.COM>

    I noticed you used multiple-value-setq inside a with-slots.  As in:

    (defmethod change-class-internal ((x-y x-y-point) (r-t rho-theta-point))
      (with-slots (x-y r-t)
	(multiple-value-setq (rho theta) (convert-to-r-t x y))))

    I think that is perfectly reasonable but to be consistent shouldn't one add to 
    Common Lisp a multiple-value-setf?  In other words, why should this work only 
    inside of a with-slots?

A proposed, but rejected, extension to Common Lisp was

  (setf (values (point-rho p) (point-theta p))
	(convert-to-r-t x y))

I forget why this was rejected.  Probably the majority of the Common Lisp
committee couldn't see in 1983 any applications for it.

This seems like the appropriate syntax for such a feature, rather than
adding a new special form.

By the way it's trivial to implement, but not in a portable way.  What I
mean is that it is trivial to add to most setf substrates.

∂27-Oct-86  1510	edsel!bhopal!jonl@navajo.stanford.edu 	Remarks on Generic Functions   
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 86  15:10:21 PST
Received: by navajo.stanford.edu; Mon, 27 Oct 86 15:08:43 PST
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
	id AA01704; Sat, 25 Oct 86 01:02:16 pdt
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
	id AA18072; Sat, 25 Oct 86 01:01:29 PDT
Date: Sat, 25 Oct 86 01:01:29 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8610250801.AA18072@bhopal.edsel.uucp>
To: navajo!RPG%SAIL.STANFORD.EDU@navajo.stanford.edu,
        navajo!common-lisp-object-system%SAIL.STANFORD.EDU@navajo.stanford.edu
In-Reply-To: Daniel L. Weinreb's message of Tue, 21 Oct 86 14:16 EDT
Subject: Remarks on Generic Functions 


Date: Fri, 24 Oct 86 23:51:53 PDT
From: jonl (Jon L White)
To: navajo!DLW%ALDERAAN.SCRC.Symbolics.COM
In-Reply-To: Daniel L. Weinreb's message of Tue, 21 Oct 86 14:16 EDT
Subject: Remarks on Generic Functions 


I see two still-open issues about "lexical generics" in your note:
  1)  Does their addition to the language move it more towards the judgement
      "this is all too big and complicated, what's all this extraneous stuff 
      for, don't these losers have any appreciation for simplicity" and so on. 
  2)  Will there ever be any useful scenarios where they will be used.   Who 
      will want to use them.  Could they find another way to "do it" without 
      requiring "lexical generics" .

What seems obvious to some people, and not so obvious to others, is that
the language will be more complex **without** lexical generics than with
them.  The reason is, quite simply, that once generic functions become
first-class in the way they have, then the more syntactic differences
there are between their usage and normal function usage, the more complex
it will be to understand them.  

The "lexical" notion applies to the syntactical meaning of program 
identifiers, rather than to any deep-seated meaning about the values 
they identify.   [What is surprising to me is why there aren't more people 
clamoring down the Common Lisp door for "lexical defstructs"; there have 
been some already, I know].   I think Gregor suggested a similar thing in 
a note last week about how to implement "lexical generics" as syntactic sugar
on top of pre-existing "anonymous generic function" capability.  


With regard to (2), I might say that the whole thrust of "lexicality" in
Common Lisp has not necessarily been a unanimous blessing.   Sure, everyone
applauds the unification of the compiler and interpreter on the treatment
of local variables, but not everyone cares even on whit about FLET and
LABELS.  One could argue that Lisp got along for 20 years without such
constructs and didn't need them (and may still doesn't?); on the other hand
even if one doesn't use them himself, he might recognize that it's a
programming style that's coming of age now, and not just in Lisp.  

It would appear that "packages" in some strongly-typed languages are in fact 
the means of achiving lexical modularity therein -- which may be why so
many Lisp users have been confused about the differences between local
variables and "packages" in Lisp  [this isn't the place for extending the
"packages" discussion, but it certainly is a worthwile one].  Suffice it
to say that Lisp's unit of lexical modularity is something smaller than the
"module"; and that Lisp's introspective nature -- program is data, data
is program -- means that lexicality won't necessarily give 100% isolation.

By the way, I`m not one of the nay-sayers on lexicality (although I will 
ocasionally rise to defend dynamic scoping -- Common Lisp is *both* lexically 
scoped and dynamically scoped).

Let me take an example of one of the minor uses I've found for FLET over the 
past year and extend it into the realm of generic functions;  then let me ask 
you if you don't agree that the similarity between them is very striking.
[actual examples changed for illustrative purposes].

;;minor modification of a pre-existing function, for local context:
(flet ((sqrt (x &optional tolerance)
         (let ((sys::*sqrt-tolerance* (* .1 (or tolerance 
						sys::*sqrt-tolerance*))))
           (sqrt x))))
   . . .
   ;; here's a section with more critical accuracy needs
   (setq y (sqrt x))
   . . . 
   ;; here's another section with more critical accuracy needs
   (setq z (sqrt x .01))
   . . .
   )

Now, in place of SQRT, substitute PRINT, and in place of *SQRT-TOLERANCE*,
substitute *PRINT-STRUCTURE*; finally, consider the need to throw in
a "method" to this locally redefined PRINT that handles some instances
differently.

(gflet (((print (x &optional (stream *standard-output*))
	    ;; default method just goes back to global print definition
            (let ((*print-structure* nil))
	      (print x stream)))
         (print ((x foo) &optional (stream *standard-output*))
            ;; 'foo' instances need more visibility
            (let ((*print-structure* t))
	      (print x t)))))
   . . .
   (maybe-modify-generic-function #'print)
   . . .
   (print z)
   . . .
   )

Not only does lexicality shield the "(print z)" from using the global print, 
but the call to 'maybe-modify-generic-function' is with a different object 
than would be found in the symbol-function cell of PRINT.  Even though there 
may be side-effects upon the generic function, the lexical naming provides 
a way of locally insulating these effects from the global environment.


Incidentally, it would appear as though defining GFLET by extending FLET 
would work well enough, except that it forces the issue of modifying
existing systems even before the clos proposal becomes a standard.  The
examples seem to say that the only difference between them is the extra
layer of parentheses; but if some other syntax is to be adopted, then I'm
sure that it too will differ just enough from current FLET so that the
use can unambiguously specify whether he means a generic lexical function, 
or an ordinary lexical function.



-- JonL --






∂27-Oct-86  1920	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Remarks on Generic Functions     
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 27 Oct 86  19:20:04 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 143925; Mon 27-Oct-86 21:26:37 EST
Date: Mon, 27 Oct 86 21:25 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Remarks on Generic Functions 
To: common-lisp-object-system@SU-AI.ARPA
In-Reply-To: <8610250801.AA18072@bhopal.edsel.uucp>
Message-ID: <861027212521.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sat, 25 Oct 86 01:01:29 PDT
    From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
    ....
    Now, in place of SQRT, substitute PRINT, and in place of *SQRT-TOLERANCE*,
    substitute *PRINT-STRUCTURE*; finally, consider the need to throw in
    a "method" to this locally redefined PRINT that handles some instances
    differently.

    (gflet (((print (x &optional (stream *standard-output*))
		;; default method just goes back to global print definition
		(let ((*print-structure* nil))
		  (print x stream)))
	     (print ((x foo) &optional (stream *standard-output*))
		;; 'foo' instances need more visibility
		(let ((*print-structure* t))
		  (print x t)))))
       (print z))

    Not only does lexicality shield the "(print z)" from using the global print...

Yes, but what happens if Z is a list of FOOs?  I don't think the print
method for LIST is going to call back to the version of the print generic
function that calls your special print method for FOO.

This is just poking nits in a specific example.  However, I don't think
it's meaningless on that account.  It's things like this that lead to my
claim that these ideas are not well thought out and will not be well
thought out until they have been used in real applications, and until
then it is inappropriate to standardize them.  That's not to say there
is anything wrong with these ideas; I think that the same phenomenon
happens with all ideas.

Instead of standardizing these ideas, we should make sure that the
standard does not rule out the implementation of these ideas, and then
provide some implementations in an unstandardized way.  Perhaps not
everyone agrees, but I feel that once you standardize something you are
committed not to change it in any big way, so it had better be right.

∂27-Oct-86  1936	LGD  	new files on [CLS,LSP]  
To:   common-lisp-object-system@SAIL.STANFORD.EDU    

I have edited the files that Sonya placed out on CLS,LSP earlier today so
that they can be run through TEX and printed.

These files are working versions.  While they can be run through TEX
they are not yet in TEX format.

The new files are functi.tex, functi.dvi, concep.tex, and concep.dvi.

Linda

∂27-Oct-86  2034	RPG  	Re: Remarks on Generic Functions       
To:   common-lisp-object-system@SAIL.STANFORD.EDU    
Moon writes:

``Yes, but what happens if Z is a list of FOOs?  I don't think the print
method for LIST is going to call back to the version of the print generic
function that calls your special print method for FOO.''

If PRINT calls itself recursively on the components of the list, then it
certainly will call the further-specialized version of PRINT that
specializes on FOOs. There are two possible points Moon can be making
here:

	1. He might think that GFLET modifies a generic function
	   associated with a symbol by copying the contents of the
	   function cell, so that the system-supplied PRINT will call
	   itself (as if it were defined using LABELS rather than DEFUN)
	   directly rather than through the function cell.  If this is
	   what he believes then he is stating merely that PRINT is a poor
	   example to use, because the user cannot specialize on it.

	2. He might believe that PRINT is a poor function to use as an
	   example because it will call PRIN1 internally, and therefore
	   the user cannot specialize on PRINT to get the results he
	   expects.

In either event he is stating merely that PRINT is a poor example, because
one ought not to specialize on code whose internal structure is unknown
unless that code was written with specialization in mind.  Let's use another
example:

(DEFMETHOD COUNT-CONSTITUENTS (L)
 (COND ((NOT (CONSP L)) 1)
       (T (+ (COUNT-CONSTITUENTS (CAR L))
	     (COUNT-CONSTITUENTS (CDR L))))))

(GLFET ((COUNT-CONSTITUENTS ((L BAZOLA))
         (+ JILLION-SKILLION (MAP-BAZOLA #'COUNT-CONSTITUENTS BAZOLA))))
 (COUNT-CONSTITUENTS <some interesting thing>))

This will do the expected thing.  The recursive calls to
COUNT-CONSTITUENTS in the first DEFMETHOD will invoke the specialized
version of COUNT-CONSTITUENTS, precisely because those recursive calls
pass through the function cell of the symbol COUNT-CONSTITUENTS.

This all falls out of the description of generic functions in my
`remarks' message. If Moon doesn't think that the recursive call to
COUNT-CONSTITUENTS in the GFLET will call the global (function cell)
definition of COUNT-CONSTITUENTS, then he doesn't understand the concepts
in my message.

Perhaps it is best to wait until these ideas are put into use before
putting them in the standard, but we must take care to not accidentally
preclude them from being implemented because they violate something in the
specification.  Therefore, we should, at least, be considering these
possible extensions.

Certainly it is not the case that we are restricted to some combination of
ideas already implemented for inclusion in the standard - we are allowed
to think about them and refine them first.

			-rpg-

∂27-Oct-86  2151	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Remarks on Generic Functions           
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 27 Oct 86  21:51:27 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 143968; Tue 28-Oct-86 00:51:27 EST
Date: Tue, 28 Oct 86 00:50 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Remarks on Generic Functions       
To: Dick Gabriel <RPG@SU-AI.ARPA>
cc: common-lisp-object-system@SU-AI.ARPA
In-Reply-To: The message of 27 Oct 86 23:34 EST from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Message-ID: <861028005001.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 27 Oct 86  2034 PST
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

    Let's use another example:

Sure, PRINT brings in too many red herrings.

    (DEFMETHOD COUNT-CONSTITUENTS (L)
     (COND ((NOT (CONSP L)) 1)
	   (T (+ (COUNT-CONSTITUENTS (CAR L))
		 (COUNT-CONSTITUENTS (CDR L))))))

    (GFLET ((COUNT-CONSTITUENTS ((L BAZOLA))
	     (+ JILLION-SKILLION (MAP-BAZOLA #'COUNT-CONSTITUENTS BAZOLA))))
     (COUNT-CONSTITUENTS <some interesting thing>))

    This will do the expected thing.  The recursive calls to
    COUNT-CONSTITUENTS in the first DEFMETHOD will invoke the specialized
    version of COUNT-CONSTITUENTS, precisely because those recursive calls
    pass through the function cell of the symbol COUNT-CONSTITUENTS.

    This all falls out of the description of generic functions in my
    `remarks' message. If Moon doesn't think that the recursive call to
    COUNT-CONSTITUENTS in the GFLET will call the global (function cell)
    definition of COUNT-CONSTITUENTS, then he doesn't understand the concepts
    in my message.

Well, if I did, I certainly don't now!  I'm quite confused.  It doesn't
help that there are no messages from you in the archive containing the
string "GFLET" (nor "GLFET"), so I don't really know for sure what you
mean when you say GFLET.  See below.

Is it true or is it false that (GFLET ((COUNT-CONSTITUENTS ...
makes the generic function that is the value of
(SYMBOL-FUNCTION 'COUNT-CONSTITUENTS) be one that calls the
specialized method, for the duration of its body?  I think you're saying
above that it is true; that's why the recursive calls in the default
method can reach the specialized method.  If the answer is "true", a
further refinement is, does the value of (SYMBOL-FUNCTION 'COUNT-CONSTITUENTS)
change to a different generic-function object, or is the original
generic-function object temporarily modified?

I had understood your previous messages to say the answer is "false",
and that a lexically defined generic function is a new generic function
object that is accessible through a lexically scoped name and is
isolated from the other generic function object accessible through a
global name.

I consulted the only two previous messages in the archive containing
the word GFLET.  The one of 16 Oct from Gregor contrasts GFLABELS and
GFLET, which make an entirely new generic function lexically bound
to the name, with MLABELS, which dynamically adds methods to an existing
generic function.  The one of 24 Oct from JonL says

  Not only does lexicality shield the "(print z)" from using the global print, 
  but the call to 'maybe-modify-generic-function' is with a different object 
  than would be found in the symbol-function cell of PRINT.  Even though there 
  may be side-effects upon the generic function, the lexical naming provides 
  a way of locally insulating these effects from the global environment.

Both of these seem to me to contradict what you're saying; that's okay,
they're not from you.  Going back to your "remarks" message, which up until
today I thought I understood and agreed with, there is no direct discussion
of GFLET, but you do say

  There is a second sort of `local' definition of methods that could make
  sense - it is the one to which Gregor alluded in his message about my
  anonymous generic function proposal. Suppose that a set of methods on the
  symbol, FOO, has been defined. In a dynamic context the user might want
  to temporarily extend FOO. I will use the name DFLET-METHOD; the user can
  write:
  
  (DFLET-METHOD ((FOO ((X C)) ...)) <form>)
  
  and temporarily extend the generic function FOO to have this new method
  associated with it during the execution of <form>. This, also, is a
  reasonable programming methodology. I was curious about why Gregor thought
  I meant something like DFLET-METHOD in my lexical generic function
  proposal, even though I think my proposal was relatively clear on my
  intention.

DFLET-METHOD seems to me to be the same as what you are calling
GFLET in the COUNT-CONSTITUENTS example above.

So I went back to your anonymous generic function proposal messages of
14 Oct and 15 Oct.  They're mostly about syntax, but there is one
paragraph that bears on the issue at hand:  
  The generic-function-labels construct builds a generic function
  which has nothing to do with any symbols. The methods are in the generic
  function object. Presumably the construct logically does a MAKE-GENERIC and
  some ADD-METHODS. It behaves with respect to symbol-function cells the
  way that DEFUN and LABELS behave:
Is this the same as GFLET?  This doesn't directly answer the question,
does the generic function that is the value of (SYMBOL-FUNCTION
'COUNT-CONSTITUENTS) change?  But it seems to me that it implies
the answer is no, since LABELS has no effect on the value of
SYMBOL-FUNCTION.

At this point I am completely confused and have no idea what exactly
you are proposing.


    Perhaps it is best to wait until these ideas are put into use before
    putting them in the standard, but we must take care to not accidentally
    preclude them from being implemented because they violate something in the
    specification.  Therefore, we should, at least, be considering these
    possible extensions.

    Certainly it is not the case that we are restricted to some combination of
    ideas already implemented for inclusion in the standard - we are allowed
    to think about them and refine them first.

I completely agree with these sentiments, by the way.


∂28-Oct-86  0631	edsel!bhopal!jonl@navajo.stanford.edu 	Remarks on Generic Functions   
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 86  06:31:21 PST
Received: by navajo.stanford.edu; Tue, 28 Oct 86 06:30:27 PST
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
	id AA06452; Tue, 28 Oct 86 05:58:31 pst
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
	id AA23319; Tue, 28 Oct 86 05:57:43 PST
Date: Tue, 28 Oct 86 05:57:43 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8610281357.AA23319@bhopal.edsel.uucp>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!common-lisp-object-system%SU-AI.ARPA@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Mon, 27 Oct 86 21:25 EST
Subject: Remarks on Generic Functions 


Is your question one to be answered:
    "Yes, but what happens if Z is a list of FOOs?"
If so, then the answer is very clear -- the global definition is called on 
the list of FOOs.  Not a very interesting case, is it (especially since
Z in that code is only ever bound to FOOs and numbers)?

But I'm sure you could have figured that out yourself; so if you are trying 
to say that the very nature of the second example -- the wrinkle on PRINT -- 
is such to make it so fundamentally different from the first -- the wrinkle 
on SQRT -- that we may infer *nothing* from the amazing structural similarity 
of the two programs, then I think you are dead wrong  [it would help, Dave, 
if you could be more direct when you want to say something like this, if 
indeed this is what you were trying to say?]

Examples are perforce smaller than realistic applications (sad to say, 
one of my "realistic applications" of LABELS goes on for pages; at least 
it is circumscribed by the lexical context!).  So imagine that, instead of 
deferring to the global PRINT immediately, this wrinkle were to use GFLABELS
so that "PRINT" in the local code would recursively refer to the lexical 
definition; and further imagine that the example is fleshed out using PRIN1
and/or PRINC on atomic data, so that there is no longer a question of 
recursivity.

If you can believe that the "fleshed out" example has no more nits to pick
on it, then you should be able to comment on the alleged "amazing structural
similarity".  In particular, is my interpretation of what lexicality should 
mean for generic functions something around which we can, after discussion, 
agree upon, or does it [rather than the simplified example illustrating it]
have fundamental flaws and gaps in it.

I know there are other interpretations for generic lexicality;  that is not 
any reason at all to give up on standardization in this area.  Rather, the 
whole point of discussion, such as occurred on Common Lisp, was to reduce 
the number of options to something that was either consensually agreed upon,
or that at least had the support of a large majority.

Surely the only premature decision is one which concludes that no such 
agreement can possibly be reached in the forseeable future.


-- JonL --

∂28-Oct-86  0631	edsel!bhopal!jonl@navajo.stanford.edu 	Lexical GFLABELS versus "dynamic" GFLABELS    
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 86  06:31:53 PST
Received: by navajo.stanford.edu; Tue, 28 Oct 86 06:31:09 PST
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
	id AA06557; Tue, 28 Oct 86 06:28:09 pst
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
	id AA23325; Tue, 28 Oct 86 06:27:23 PST
Date: Tue, 28 Oct 86 06:27:23 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8610281427.AA23325@bhopal.edsel.uucp>
To: navajo!common-lisp-object-system%SU-AI.ARPA@navajo.stanford.edu
Subject: Lexical GFLABELS versus "dynamic" GFLABELS


It appears to me that RPG slipped up in his COUNT-CONSTITUENTS example
in that the globally-appearing DEFMETHOD should have been one of the
clauses in the lexically-local definition.  The reason I say "slipped
up" is that in subsequent remarks he invokes the case of "dynamic" GFLET
(which temporarily modifies the symbol-function cell of COUNT-CONSTITUENTS)
as a different paradigm.  Moon commented upon this at length.

Either way, an interesting question pops up.  Suppose we use GFLABELS
rather than GFLET in that example -- then what does the #'COUNT-CONSTITUENTS 
refer to?
    (GFLABELS ((COUNT-CONSTITUENTS ((L BAZOLA))
	       (+ JILLION-SKILLION (MAP-BAZOLA #'COUNT-CONSTITUENTS BAZOLA))))
     (COUNT-CONSTITUENTS <some interesting thing>))
Should it be interpreted as (SYMBOL-FUNCTION 'COUNT-CONSTITUENTS) -- i.e.,
the global definition -- or should it be specially interpreted to mean the 
lexically-local definition?  I believe the same question was asked of the 
Common Lisp mailing list not too long ago, and I don't remember if there was 
a clear consensus.  

It is clear that #'FOO ==> (FUNCTION FOO), and page 87 of CLtL seems to
imply that (FUNCTION FOO) ==> (SYMBOL-FUNCTION 'FOO);  but that may just
be an oversight.  

Regardless of the "genericity" question, it would be a shame if one couldn't
specify the "current, lexical definition" as a functional argument somehow. 
And of course, the answer ought to be exactly the same for lexical generic 
functions as it is for lexical "ordinary" functions.


-- JonL --


P.S. It would appear that examples that are somehow recursive are bad 
     examples to illustrate anything about FLET/GFLET; at the very least, 
     one may find himself being driven to LABELS/GFLABELS.

∂28-Oct-86  0753	RPG  	GLFET    
To:   common-lisp-object-system@SAIL.STANFORD.EDU    

Hm. When I glanced at Jonl's message about GFLET and saw the
PRINT example, I thought he was talking about what I had called
DFLET-METHOD. I see that he isn't. So, Moon's comment about
this code:

(generic-function-let 
(((print (x &optional (stream *standard-output*))
	 ;; default method just goes back to global print definition
	 (let ((*print-structure* nil))
	      (PRINT x stream)))  ;Escape about of GF-land
  (print ((x foo) &optional (stream *standard-output*))
	 ;; 'foo' instances need more visibility
	 (let ((*print-structure* t))
	      (print x t)))))
   . . .
   (maybe-modify-generic-function #'print)
   . . .
   (print z)
   . . .
   )

is right.  Once the PRINT in capital letters is invoked, we cannot come
back into the world defined by the GENERIC-FUNCTION-LET. Using DFLET-METHOD,
one could write:

(let ((*print-structure* nil))
     (declare (special *print-structure*))
     (DFLET-METHOD
      ((print ((x foo) &optional (stream *standard-output*))
	      ;; 'foo' instances need more visibility
	      (let ((*print-structure* t))
		   (print x t)))))
     . . .
     (print z)
     . . .
     )

to get approximately the behavior Jonl discusses. 

To emphasize:

	1. Generic-function-let creates a new generic function, unrelated
	   to any other that is associated with a symbol whose print name
	   is the same as the identifier name in the generic-function-let
	   form.  The same remark holds for generic-function-labels.

	2. DFLET-METHOD temporarily modifies a generic function associated
	   with a symbol (or adds a new generic function to a symbol which
	   does not have one).

The code for COUNT-CONSTITUENTS should read:

(DEFMETHOD COUNT-CONSTITUENTS (L)
 (COND ((NOT (CONSP L)) 1)
       (T (+ (COUNT-CONSTITUENTS (CAR L))
	     (COUNT-CONSTITUENTS (CDR L))))))

(DFLET-METHOD ((COUNT-CONSTITUENTS ((L BAZOLA))
	        (+ JILLION-SKILLION (MAP-BAZOLA #'COUNT-CONSTITUENTS BAZOLA))))
	      (COUNT-CONSTITUENTS <some interesting thing>))

I apologize for thinking that GFLET was *not* the same GENERIC-FUNCTION-LET
and that GFLET was the same as DFLET-METHOD; the example using PRINT
threw me off.

			-rpg-

∂28-Oct-86  1112	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Lexical GFLABELS versus "dynamic" GFLABELS 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Oct 86  11:12:27 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 144476; Tue 28-Oct-86 14:05:02 EST
Date: Tue, 28 Oct 86 14:03 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Lexical GFLABELS versus "dynamic" GFLABELS
To: common-lisp-object-system@SU-AI.ARPA
In-Reply-To: <8610281427.AA23325@bhopal.edsel.uucp>
Message-ID: <861028140344.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 28 Oct 86 06:27:23 PST
    From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
    
    [main text of message deleted]

    P.S. It would appear that examples that are somehow recursive are bad 
	 examples to illustrate anything about FLET/GFLET; at the very least, 
	 one may find himself being driven to LABELS/GFLABELS.

No, I think they are excellent examples, because they tend to highlight
the difference between regular functions and generic functions.  Regular
functions are defined in one place, so it's obvious how to shadow one
definition with another.  Generic functions are defined in many places
(with methods), so all these additional issues arise about exactly what
it means to shadow one definition with another.  Recursive examples help
bring out the issues.

∂28-Oct-86  1459	Pavel.pa@xerox.com 	Re: Lexical GFLABELS versus "dynamic" GFLABELS    
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 86  14:59:34 PST
Received: from XEROX.COM by navajo.stanford.edu with TCP; Tue, 28 Oct 86 14:16:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 28 OCT 86 12:33:58 PST
Date: 28 Oct 86 12:32 PST
From: Pavel.pa@xerox.com
Subject: Re: Lexical GFLABELS versus "dynamic" GFLABELS
In-Reply-To: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)'s
 message of Tue, 28 Oct 86 06:27:23 PST
To: edsel!bhopal!jonl@navajo.stanford.edu
Cc: navajo!common-lisp-object-system%SU-AI.ARPA@navajo.stanford.edu
Message-Id: <861028-123358-4378@Xerox>

    Date: Tue, 28 Oct 86 06:27:23 PST From:
    edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)

    It is clear that #'FOO ==> (FUNCTION FOO), and page 87 of CLtL
    seems to imply that (FUNCTION FOO) ==> (SYMBOL-FUNCTION 'FOO);  but
    that may just be an oversight.  

Actually, Guy's list of typo's contains a correction for the paragraph
in question on page 87.  The new text reads:

	``In particular, if FN is a symbol, the functional definition of that
name is returned, which is that established by the innermost
lexically-enclosing FLET, LABELS, or MACROLET construct, if there is
one, or else the global functional definition of the symbol (see
SYMBOL-FUNCTION).''

This probably also wants a note about it being an error to use #'foo
when inside an unshadowed MACROLET definition of foo,but at least it's
clear on the meaning of #' inside lexical-function binding forms.

	Pavel

∂28-Oct-86  1931	Moon@STONY-BROOK.SCRC.Symbolics.COM 	new files on [CLS,LSP]      
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Oct 86  19:30:26 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 144969; Tue 28-Oct-86 22:30:33 EST
Date: Tue, 28 Oct 86 22:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: new files on [CLS,LSP]  
To: Linda DeMichiel <LGD@SU-AI.ARPA>
cc: common-lisp-object-system@SU-AI.ARPA
In-Reply-To: The message of 27 Oct 86 22:36 EST from Linda DeMichiel <LGD@SAIL.STANFORD.EDU>
Message-ID: <861028222914.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 27 Oct 86  1936 PST
    From: Linda DeMichiel <LGD@SAIL.STANFORD.EDU>

    The new files are functi.tex, functi.dvi, concep.tex, and concep.dvi.

We still can't print these DVI files (I only tried concep.dvi this time).
They make our postscript printers run out of memory and crash.
This TEX-based document production technique is not working very well so far.

∂28-Oct-86  2004	LGD  	printing files
To:   moon@SCRC-STONY-BROOK.ARPA
CC:   common-lisp-object-system@SAIL.STANFORD.EDU

Perhaps you should have your facilities people check into your memory
problems (or possible problems with PostScript), since you were
running out of memory even on the files we produced with stripped-down
fonts.
I have successfully printed the .dvi files on [CLS,LSP] on both the
Imagen and Dover printers at Stanford as well as on our Imagen at
Lucid.  At Lucid we've printed even more complex documentation files
without any problems using our Laserwriter and PostScript.  
If you have access to printers at MIT, as I think you mentioned, that
might be a workaround.  Otherwise, we can arrange to send hardcopy.

∂29-Oct-86  0214	DUSSUD@martha 	Re: Instance transformation pr
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 29 Oct 86  02:14:21 PST
Received: from ti-csl by csnet-relay.csnet id am00384; 28 Oct 86 13:23 EST
Received: from Martha (p-lorre.ARPA) by tilde id AA18124; Tue, 28 Oct 86 10:06:57 cst
From: DUSSUD%TILDE%ti-csl.csnet@CSNET-RELAY.ARPA
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp-Object-System@SU-AI.ARPA
Subject:        Re: Instance transformation pr
Date:           28-Oct-86 10:02:12
Sender: DUSSUD@martha
Message-Id:     <DUSSUD.2739888129@Martha>

Dave,


	     A proposed, but rejected, extension to Common Lisp was
	     
	       (setf (values (point-rho p) (point-theta p))
		     (convert-to-r-t x y))
	     
	     I forget why this was rejected.  Probably the majority of the Common Lisp
	     committee couldn't see in 1983 any applications for it.
	     
	     This seems like the appropriate syntax for such a feature, rather than
	     adding a new special form.
	     
	     By the way it's trivial to implement, but not in a portable way.  What I
	     mean is that it is trivial to add to most setf substrates.


I think we can implement it in a portable way, it may not be the best implementation 
for some architecture though.

(define-setf-method values (&rest places)
  (if (every #'symbolp places )
      (let ((g (gensym)))
	(values nil nil (list g)
		`(multiple-value-setq ,places ,g)
		g))
      (let ((g (gensym))
	    (ltemp (mapcar #'(lambda (ignore )
	                        (declare (ignore ignore))
                                (gensym)) 
                           places)))
	(values nil nil (list g)
		`(multiple-value-bind ,ltemp ,g
		   ,@(mapcar #'(lambda (x y) `(setf ,x ,y)) places ltemp))
		g))))

Patrick.

∂29-Oct-86  0510	edsel!bhopal!jonl@navajo.stanford.edu 	Lexical GFLABELS versus "dynamic" GFLABELS    
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Oct 86  05:10:45 PST
Received: by navajo.stanford.edu; Wed, 29 Oct 86 05:10:00 PST
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
	id AA01454; Wed, 29 Oct 86 04:33:56 pst
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
	id AA26023; Wed, 29 Oct 86 04:32:59 PST
Date: Wed, 29 Oct 86 04:32:59 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8610291232.AA26023@bhopal.edsel.uucp>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!common-lisp-object-system%SU-AI.ARPA@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 28 Oct 86 14:03 EST
Subject: Lexical GFLABELS versus "dynamic" GFLABELS


    Date: Tue, 28 Oct 86 14:03 EST
    From: David A. Moon <navajo!Moon@STONY-BROOK.SCRC.Symbolics.COM>
	Date: Tue, 28 Oct 86 06:27:23 PST
	From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
	. . . 
	P.S. It would appear that examples that are somehow recursive are bad 
	     examples to illustrate anything about FLET/GFLET; at the very 
	     least, one may find himself being driven to LABELS/GFLABELS.
    No, I think they are excellent examples, because they tend to highlight
    the difference between regular functions and generic functions.  . . .

Well, I'm glad you now think they are excellent examples, but I'm not 
so sure of the analysis which follows in your note.  The fact that one 
may want to write one of them as a recursive definition (e.g., the 
modified  "print", but extended to cover more cases) highlights the 
defined difference between FLET and LABELS -- it doesn't really say 
anything about the distribution of defmethods.

Distributing the source code across non-lexical scope is entirely a
separate matter.  The whole point of the sqrt/print examples was to 
provide some evidence, based on real experience with lexical functions,
to rebut the thesis: "One would never want to use generic functions 
without breaking the lexical barrier".  I think a desire to define two 
different methods for the same generic function, but in two different 
lexical locales,  would probably have very little to do with whether or
not the function is recursive; do you have some example in mind where
the recursiveness is the key?

I fully agree that many, if not most, uses of generic functions will find 
their defmethods widely distributed (i.e., not suitable for making a lexical 
function); but then again, looking at a lot of recent Common Lisp code, I see 
that most functions aren't defined using FLET or LABELS either.


-- JonL --

∂29-Oct-86  0919	kempf%hplabsc@hplabs.HP.COM 	Re:  printing files  
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 29 Oct 86  09:19:19 PST
Received: from hplabsc by hplabs.HP.COM ; Wed, 29 Oct 86 09:14:16 pst
Received: by hplabsc ; Wed, 29 Oct 86 08:44:05 pst
Date: Wed, 29 Oct 86 08:44:05 pst
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8610291644.AA08223@hplabsc>
To: LGD@SAIL.STANFORD.EDU, moon@SCRC-STONY-BROOK.ARPA
Subject: Re:  printing files
Cc: common-lisp-object-system@SAIL.STANFORD.EDU

I have also been unable to print DVI files obtained off of SAIL.
I haven't tried the latest, but the previous batch wouldn't work.
The tex people here said we probably didn't have the right fonts.
I have, however, been able to re-tex the .tex files using LaTex,
and thereby produce hardcopy.
	Jim Kempf	kempf@hplabs

∂29-Oct-86  1035	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Instance transformation pr   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Oct 86  10:34:47 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 145401; Wed 29-Oct-86 12:46:59 EST
Date: Wed, 29 Oct 86 12:45 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Instance transformation pr
To: DUSSUD%TILDE%ti-csl.csnet@CSNET-RELAY.ARPA
cc: Common-Lisp-Object-System@SU-AI.ARPA
In-Reply-To: <DUSSUD.2739888129@Martha>
Message-ID: <861029124535.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date:           28-Oct-86 10:02:12
    From: DUSSUD%TILDE%ti-csl.csnet@CSNET-RELAY.ARPA

		 A proposed, but rejected, extension to Common Lisp was
	     
		   (setf (values (point-rho p) (point-theta p))
			 (convert-to-r-t x y))
	     
    I think we can implement it in a portable way, it may not be the best implementation 
    for some architecture though.

    (define-setf-method values (&rest places)
      (if (every #'symbolp places )
	  (let ((g (gensym)))
	    (values nil nil (list g)
		    `(multiple-value-setq ,places ,g)
		    g))
	  (let ((g (gensym))
		(ltemp (mapcar #'(lambda (ignore )
				    (declare (ignore ignore))
				    (gensym)) 
			       places)))
	    (values nil nil (list g)
		    `(multiple-value-bind ,ltemp ,g
		       ,@(mapcar #'(lambda (x y) `(setf ,x ,y)) places ltemp))
		    g))))

I don't think this works.  At least in some implementations you will
end up with code looking like

   (let ((#:g0001 (foo x y)))
     (multiple-value-bind (#:g0002 #:g0003) #:g0001
       (setf (bar a) #:g0002)
       (setf (baz b) #:g0003)
       #:g0001))

for (setf (values (bar a) (baz b)) (foo x y)), which of course
sets (baz b) to nil.

∂29-Oct-86  1615	kempf%hplabsc@hplabs.HP.COM 	Re: Local Lexical Generic Functions 
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 29 Oct 86  16:14:50 PST
Received: from hplabsc by hplabs.HP.COM ; Wed, 29 Oct 86 16:13:56 pst
Received: by hplabsc ; Wed, 29 Oct 86 16:12:25 pst
Date: Wed, 29 Oct 86 16:12:25 pst
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8610300012.AA20272@hplabsc>
To: common-lisp-object-system@sail.stanford.edu
Subject: Re: Local Lexical Generic Functions


As an additional data point, we have a CommonLoops user here
who wanted to use MLET, but it isn't in our version of CommonLoops.
His application is a window system, and he wanted it to do some
customized window initialization.

		Jim Kempf	kempf@hplabs
PS: Is MLET in the currently on parcvax version of CommonLoops?
If so, then we may be able to get some user reaction to local
lexical generics.

∂29-Oct-86  1755	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Dispatching on optional/keyword arguments   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Oct 86  17:54:52 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 145870; Wed 29-Oct-86 20:54:27 EST
Date: Wed, 29 Oct 86 20:52 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Dispatching on optional/keyword arguments
To: Masinter.pa@XEROX.COM
cc: Common-Lisp-Object-System@SU-AI.ARPA
In-Reply-To: The message of 23 Oct 86 19:01 EDT from Masinter.pa@Xerox.COM,
             <861023-160755-1667@Xerox>,
             The message of 23 Oct 86 21:59 EDT from Masinter.pa@Xerox.COM,
             <861024-103930-1108@Xerox>
Message-ID: <861029205259.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

Yes, I think your proposal is a ninth proposal, not completely identical
to any of the eight I had dredged out of the mail.  I archived it together
with my message for the benefit of any future attempt to deal with the
problem of dispatching on optional/keyword arguments.

The thing that I don't like about your proposal can be expressed very
succinctly, I think:  It doesn't really provide the ability to specialize
on optional arguments from the caller's point of view.  Suppose I have
a generic function BLATZ and I can call it with either one or two
arguments.  I'd like to be able to say that the second argument to BLATZ
is optional and defaults to the value of *STANDARD-OUTPUT*.  In your
proposal, if there any methods that specialize on the second argument,
the two forms (BLATZ X) and (BLATZ X *STANDARD-OUTPUT*) don't behave
identically.  Thus I don't think you can really say that the second
argument is optional; in order to get the full behavior the caller
has to supply that argument.

∂30-Oct-86  1333	Moon@STONY-BROOK.SCRC.Symbolics.COM 	new files on [CLS,LSP]      
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 30 Oct 86  13:33:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 146685; Thu 30-Oct-86 16:31:47 EST
Date: Thu, 30 Oct 86 16:30 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: new files on [CLS,LSP]  
To: Linda DeMichiel <LGD@SU-AI.ARPA>
cc: common-lisp-object-system@SU-AI.ARPA
In-Reply-To: <861028222914.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <861030163005.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 28 Oct 86 22:29 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	Date: 27 Oct 86  1936 PST
	From: Linda DeMichiel <LGD@SAIL.STANFORD.EDU>

	The new files are functi.tex, functi.dvi, concep.tex, and concep.dvi.

    We still can't print these DVI files (I only tried concep.dvi this time).
    They make our postscript printers run out of memory and crash.
    This TEX-based document production technique is not working very well so far.

By applying a postscript expert, a patch to the 68000 software in the
Laserwriter that makes it (sometimes) give an explanation of what
happened when something goes wrong instead of just wiping itself out and
crashing, and a lot of experiments, we have made a little progress on this.
We also found that when the printer claims to have run out of memory,
sometimes it is lying and sometimes it is telling the truth.

We found a problem, caused by the way you do ligatures, that was making
our printers crash.  This was really a bug in our printer driver and after
fixing it we can print some of your files.  For example, we can print
the symfun.dvi file you made a while ago that uses only 8 fonts instead
of 12.

We still can't print concep.dvi.  This may really be a memory problem.
It requires 185,772 bytes of bitmap fonts, and I'm told there is only
240K bytes memory available in total.  Perhaps the other overhead takes
more than 55K bytes.  I don't understand why the amount of memory designed
into the printer is so small.  I also don't understand why you need to
use 12 different fonts in this document.  We also can't print functi.dvi,
which requires 151,108 bytes of bitmap fonts.

Experimentation shows that the amount of fonts that can be loaded
without crashing the printer is in the range of 90K to 140K bytes.  Part
of the problem with concep.dvi, however, seems to have something to do
with the illustration on page 5 taking a lot of memory.  I don't really
understand what's going on here yet, but a useful experiment would be
possible if you make versions of concep and functi with fewer fonts,
similar to symfun.  If those versions will print, perhaps we can stick
with the smaller number of fonts and avoid all this pain.

I was able to get a complete listing of concep.dvi by piecing together
the output from all of my experiments, which means that every page is
printable individually (printing portions of the document, rather than
printing it all at once, tends to work better because a portion of
the document usually uses fewer characters than the whole document,
so the memory occupied by fonts is smaller).

On another front, it took me most of the week to get SAIL to disgorge
an uncorrupted copy of functi.dvi.  The Arpanet is really going down
the toilet these days.

∂30-Oct-86  1452	DUSSUD%Jenner%ti-csl.csnet@CSNET-RELAY.ARPA  
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 30 Oct 86  14:52:44 PST
Received: from ti-csl by csnet-relay.csnet id af02666; 30 Oct 86 12:36 EST
Received: from Jenner (jenner.ARPA) by tilde id AA02018; Thu, 30 Oct 86 10:51:30 cst
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp-Object-System@SU-AI.ARPA
Date:           30-Oct-86 10:42:31
From: DUSSUD%Jenner%ti-csl.csnet@CSNET-RELAY.ARPA
Message-Id:     <DUSSUD.2740063349@Jenner>

	    (define-setf-method values (&rest places)
	      (if (every #'symbolp places )
		  (let ((g (gensym)))
		    (values nil nil (list g)
			    `(multiple-value-setq ,places ,g)
			    g))
		  (let ((g (gensym))
			(ltemp (mapcar #'(lambda (ignore )
					    (declare (ignore ignore))
					    (gensym)) 
				       places)))
		    (values nil nil (list g)
			    `(multiple-value-bind ,ltemp ,g
			       ,@(mapcar #'(lambda (x y) `(setf ,x ,y)) places ltemp))
			    g))))
	
	I don't think this works.  At least in some implementations you will
	end up with code looking like
	
	   (let ((#:g0001 (foo x y)))
	     (multiple-value-bind (#:g0002 #:g0003) #:g0001
	       (setf (bar a) #:g0002)
	       (setf (baz b) #:g0003)
	       #:g0001))
	
	for (setf (values (bar a) (baz b)) (foo x y)), which of course
	sets (baz b) to nil.

OOPS, you're right!
Sorry about that.
Patrick.

∂30-Oct-86  1728	LGD  	stripped down versions of files   
To:   moon@SCRC-STONY-BROOK.ARPA
CC:   common-lisp-object-system@SAIL.STANFORD.EDU
I've hacked up stripped-down versions of the concepts and functions files
using fewer fonts.  These versions also lack the type diagram, but are
otherwise identical to the current versions of functi.tex and concep.tex.
The new files are symfun.dvi and symcon.dvi.

Linda

∂31-Oct-86  1603	DUSSUD%Jenner%ti-csl.csnet@CSNET-RELAY.ARPA 	A proposal for a finer grained method combination selection.
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 31 Oct 86  16:03:10 PST
Received: from ti-csl by csnet-relay.csnet id ag10983; 31 Oct 86 17:50 EST
Received: from Jenner (jenner.ARPA) by tilde id AA18545; Fri, 31 Oct 86 16:22:10 cst
To: common-lisp-object-system@SU-AI.ARPA
Cc:  
Subject:        A proposal for a finer grained method combination selection.
Date:           31-Oct-86 16:12:26
From: DUSSUD%Jenner%ti-csl.csnet@CSNET-RELAY.ARPA
Message-Id:     <DUSSUD.2740169545@Jenner>


A proposal for a finer grained method combination selection.

In Dave's revised write-up on method combination, the method combination
technique is attached to the generic function. I see two reasons for
proposing an alternative:

1. A generic function implements a contract between the object 
implementation and its callers. However method combination is a contract
between methods within a method precedence list (referred as "sorted list of 
the available method" by Dave in Step 2 of his procedure for method combination).

2. When a generic function implements functionality for orthogonal sets of 
classes, it may be that these sets need different method combinations.


Proposal:
- It is possible to specialize the method combination for a given method precedence list.
Since a method precedence list is determined by a generic function and a number of type
specifiers equal to the length of the qualified argument list of the generic function,
I propose to add the following function:

(add-method-combination method-combination generic-function &rest type-specifiers )
will define the method combination to use for the method precedence list 
defined by the generic-function and the type-specifiers. The type-specifiers must be
acceptable as argument specifiers for a method on the generic function.
(I am sure somebody can think of a better name for it).

- I propose to change the procedure that Dave describes in his proposal for method combination,
as follows:

2.  Sort the available methods into a precedence order. 

	To compare the precedence of two methods, examine their parameter
	specializers in order from left to right.  An unspecialized parameter has a
	default parameter specializer of T.  The first pair of parameter
	specializers that are not equal determine the precedence.  Method X is more
	specific than method Y if method X's parameter specializer is earlier than
	method Y's parameter specializer in the class precedence list of the class
	of the argument.  Since the methods are available for this argument, it is
	guaranteed that their parameter specializers are present in the class
	precedence list of the class of the argument. 
	
	T is implied at the very end of each class precedence list, so it is less
	specific than any other class.  (QUOTE individual) is more specific than
	any class.
	
	The resulting list of available methods is sorted with the most specific
	method first and the least specific method at the end.

2.1 Sort the available method combinations into a precedence order

    They are sorted the same way methods are sorted.

3.  Apply method combination.

--The first sentence:
<The method combination technique specified for the generic function receives
the sorted list of available methods and returns a Lisp form.> 

--would be replaced by:

<The first method combination technique in the method combination precedence list
receives the sorted list of available methods and returns a Lisp form.>

                                                                       This form
contains calls to some or all of the methods, defines the value(s) to be 
returned by the generic function, and optionally makes some of the methods
reachable via CALL-NEXT-METHOD, rather than calling them directly.




Open issues:

As Dave says in his proposal, for the method cobination technique:
"If a method is available but matches none of the qualifier-patterns, the
fact that the method is not valid with this type of method combination is
automatically reported as an error or as a warning as appropriate."
According to this proposal we could pick up some method suitable for another
method combination style because this method can appear in two method 
precedence lists having incompatible method combinations.
Should that be considered as an error?

Patrick.


∂05-Nov-86  0850	hpfclp!robert@hplabs.HP.COM 	discussion wanted    
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 5 Nov 86  08:50:17 PST
Received: by hplabs.HP.COM ; Wed, 5 Nov 86 08:48:35 pst
From: hpfclp!robert@hplabs.HP.COM
Received: by hpfclp; Wed, 5 Nov 86 09:32:26 mst
Date: Wed, 5 Nov 86 09:32:26 mst
Return-Path: <hpfclp!robert>
Received: from hpfcnml.UUCP; Wed, 5 Nov 86 09:31:45
To: common-lisp-object-system@sail.stanford.edu
Subject: discussion wanted

I am Robert Heckendorn with Hewlett-Packard in Fort Collins, Colorado.
It is here that Hewlett-Packard's version of CommonLisp was developed.

I have been following this discussion with much interest since I was
included on the mailing list at OOPSLA.  My experience with object
oriented programming has been limited; so, though I am tempted, I will
try not to become an extra cook in the kitchen.


It seems the view of people that I deal with in the LISP community
generally may be different from what you may believe is their view.
Here is what many I have talked to have been saying:

"There is a new standard for object oriented programming called
CommonLoops that has been defined.  It would nice to use it to do our
code because it is a standard.  We won't find our objects code becoming
obsolete for that reason."

I even get flack for not already having this standard!  Just thought you
would want to know, if you didn't already.





There are several things that worry me about this ever-growing standard.
I am not trying to change the standard.  I just want to examine the
rationale and tradeoffs.

This standard is immense.  I am worried that even though the proposal is
going to be well thought out, its usability is threatened by its size.
As pointed out by practically the entire OOPSLA panel on learnability,
one of the major contributors to the learnability of an object oriented
language is simplicity.  Give them too many options and they balk or get
mired in details.  I am worried about our users.  I have to ask is all
this really necessary for the standard or is it just a good thing to
have on a rainy day?

People need a model.  My thanks to Dick for his short monograph on his
model for generic functions.  The programmer on the street needs a good
model for this new way of looking at things.  I would like to see some
more discussion such as Dick's.  How do we tell these folks to think
about all this method combination, generic functions and the
relationship between a lattice of types and selection of methods?

Another big point that came out of OOPSLA was that there is little known
about the area of methodology for object oriented programming.  This
dearth of knowledge is for, what has been referred to as, the "classical
object", that is only one argument being used for the discrimination of
method.  Is it appropriate to advance as a standard a scheme that
involves multimethods where even less is known about how to use this
"feature"?  What do we know about methodologies for this model of object
oriented programming?

I have been asked by several in an annoyed tone, "Why are they throwing
out the classical way of doing objects?"  What can I say to them?  Has
it been shown more useful?  I'm not saying that it isn't useful.  People
want to know that many people have already found it useful by using it.
Is there a paper or bit of research that will make both them and me feel
better about this decision?  The rationale for selecting multimethods
should be discussed so that at least it can be written up nicely and put
in the "Design Rationale" chapter.

One of the biggest complaints about Objects is speed.  I hear the
complaints from our users.  I see that PPI makes speed one of their big
selling points, recognizing it is a dragon that must be slain.  I have
seen some talk about speed on this notes group but not much.  The
standard has to be one that not only gives features but allows speed or
people just won't use it.  Speed must be thought of during design or it
will be a hack.  What kind of assumptions can the compiler make about
staticness of class and generic function definitions?  What kind of
declarations can be used to increase the knowledge that interpretors and
compilers will have?  What is not allowed to be known before run time?

I know it isn't as fun to talk about some of the above areas, but they
do need more air time in this group.




Here are some general questions that I have or have been asked and
really could not answer knowledgeably.

Is there going to be a portable implementation of Classes for Common
Lisp?

What is the future of CommonLoops?

When do you think the public will see the "final document"?  People want
to know when can I start using the new standard.  What do I tell them?

What is the process that you must go through to make this officially
part of a standard?



		thanks,
		    Robert Heckendorn 
		    robert%hpfclp@hplabs.HP.COM


∂05-Nov-86  1255	RPG  	Next Step     
To:   common-lisp-object-system@SAIL.STANFORD.EDU    

Because it appears that FUNCTION.TEX is essentially stable and because the
deadline for sending it to X3J13 approaches, Linda and I are going to
start going over it to

1. make it read like a specification (dull but precise);
2. make sure exactly the decisions we reached are discussed; and
3. turn it into TEX.

If there are major comments about the contents of FUNCTION.TEX,
you should send them soon.

			-rpg-

∂05-Nov-86  2129	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Next Step         
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 5 Nov 86  21:28:55 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 151510; Wed 5-Nov-86 22:40:00 EST
Date: Wed, 5 Nov 86 22:39 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Next Step     
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: The message of 5 Nov 86 15:55 EST from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Message-ID: <861105223946.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 05 Nov 86  1255 PST
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

    Because it appears that FUNCTION.TEX is essentially stable and because the
    deadline for sending it to X3J13 approaches, Linda and I are going to
    start going over it to

    1. make it read like a specification (dull but precise);
    2. make sure exactly the decisions we reached are discussed; and
    3. turn it into TEX.

    If there are major comments about the contents of FUNCTION.TEX,
    you should send them soon.

Well, bear in mind that I have -never- seen the contents of that file,
so if you haven't heard comments on it from me it doesn't mean that I
agree with what it says.  I don't even know what it says.  I guess
Linda sent Sonya a hardcopy of it and I can try to get a copy of that.
If you don't hear from me please assume that you haven't heard from me.

The supposed ability for us to print copies of these files and stay
in constant communication hasn't worked very well, partly because the
Arpanet has been almost continuously down (or at least SU-AI hasn't
been communicating) for the past several weeks.  Mail seems to get
through with a delay of a day or so.  This is not caused by anything
local to Symbolics, the same effect is observed from other hosts.

I'm not sure it's a good idea to send incomplete drafts to the X3J13
committee.  Sending out the list of functions without any conceptual
background explaining what they do seems to me to serve no purpose,
other than perhaps to demonstrate that we haven't been sitting on our
hands.

∂05-Nov-86  2235	Moon@STONY-BROOK.SCRC.Symbolics.COM 	stripped down versions of files       
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 5 Nov 86  22:34:48 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 151571; Thu 6-Nov-86 01:33:01 EST
Date: Thu, 6 Nov 86 01:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: stripped down versions of files   
To: Linda DeMichiel <LGD@SAIL.STANFORD.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: The message of 30 Oct 86 20:28 EST from Linda DeMichiel <LGD@SAIL.STANFORD.EDU>
Message-ID: <861106013249.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 30 Oct 86  1728 PST
    From: Linda DeMichiel <LGD@SAIL.STANFORD.EDU>

    I've hacked up stripped-down versions of the concepts and functions files
    using fewer fonts.  These versions also lack the type diagram, but are
    otherwise identical to the current versions of functi.tex and concep.tex.
    The new files are symfun.dvi and symcon.dvi.

Thanks.  I finally was able to get those files over here, and print them
out.  I hope I'll be able to start reading them tomorrow.  I'll
coordinate any corrections through Sonya (with mail where I think issues
need general discussion).  Please use the same fewer-fonts mode for
future drafts, since that will make it much easier for us (always
assuming that whoever is responsible for maintaining the Arpanet fixes
the Arpanet problems).

I think the type diagram could safely be put back in, although that may
not be worthwhile since I believe the diagram as it stands (I have a
copy dated Oct 27 18:17) is completely different from what we agreed to
and will have to be redrawn.

∂06-Nov-86  0700	Masinter.pa@Xerox.COM 	Re: discussion wanted 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Nov 86  07:00:18 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 06 NOV 86 06:34:45 PST
Date: 6 Nov 86 04:23 PST
From: Masinter.pa@Xerox.COM
Subject: Re: discussion wanted
In-reply-to: hpfclp!robert@hplabs.HP.COM's message of Wed, 5 Nov 86
 09:32:26 mst
To: hpfclp!robert@hplabs.HP.COM
cc: common-lisp-object-system@sail.stanford.edu
Message-ID: <861106-063445-1053@Xerox>

This is a colloquial reply to your question -- a lot of this has been
written before, but I thought I'd give you a direct reply....

re size of standard: the document looks big, but its mainly because a
lot of words were used to describe simple things.... probably the thing
can get smaller before it gets to be a standard.. Multimethods actually
makes Common Lisp plus this smaller than not having them, since you'd
have to explain why they're not there. 

Here's a simple model that I've found effective in telling people about
it:

Preface: Common Lisp already has functions & types. You define new
functions with defun, new types with defstruct. The types already form a
lattice.

In the object system, there's a way of defining functions in pieces;
each piece is a method, which only applies when the arguments match. You
get to it the same way you get to anything in Lisp, by doing function
call -- its just that what you get to might be some pieces that somehow
decide which one applies rather than a single function. Its nice and
simple that you can talk about matching any of the arguments rather than
just one.

In the object system, you define new types pretty much as before, except
that you use defclass instead of defstruct, mainly because the defstruct
syntax just wasn't extensible and had the defaults wrong; defclass has a
few more options than defstruct.

Classes kind of are a way of cleaning up what a "type" is; there's two
ways of explaining it: one is that you say: well, there are classes, and
then there are some other kinds of type descriptions which aren't them,
things like (satisfies primep). The other way to explain it is that you
take what COmmon Lisp calls "types" and split 'em up. (The only
difference between the two descriptions is where you start.) What's
important here is that all of the datatypes of common lisp, things like
numbers & strings and the like, are classes too.

Finally, and this adds a bit to the size of the standard but isn't too
important for most beginning users, a lot of how the object system works
inside is actually modifiable in a controlled way using "meta-objects",
i.e., a class is an object and a generic function is an object too, and
you can define new kinds of them. A lot of the words in the standard
have to do with allowing that; maybe a users guide would put it in an
appendix.

As for performance, it was a central issue in the design of CommonLoops
that it run reasonably on machines like yours. Its just been our
experience that you get nearly as much out of caching as you do out of
trying to hack declarations: there are some cases where declarations get
you more, but there are lots of cases where they get you less. So the
performance emphasis was on caching techniques rather than on
compilation techniques, for which we have mainly handwaves (= reasonable
arguments that compiler optimization of method lookup is feasible with a
moderate amount of work, basic approaches, etc.)

Nobody's throwing out the classical way of doing objects -- its just
that embedding it in functions & function call and types  makes lisp +
objects simpler than "Doing Objects" using methods that aren't functions
and types that aren't like classes.

One thing that people relate to is that there's a natural equivalence
between a typical Common Lisp style:

(defun entryfn (arg1 arg2)
    (check-type arg1 number)
    (check-type arg2 string)
    ...)

and the single implementation methods

(defmethod entryfn ((arg1 number) (arg2 string)) ...)

and between the style of

(defun showem (arg1 arg2)
	 (typecase arg1
		(star (print-star arg1))
		(triangle (typecase arg2 
				(laser-printer (print-direct arg1 arg2))
				(t (print-triangle-with-lines arg1 arg2))))...

and 

(defmethod showem ((arg1 star) arg2) (print-star arg1 arg2))

(defmethod showem ((arg1 triangle) arg2) 
	(print-triangle-with-lines arg1 arg2))

(defmethod showem ((arg1 triangle) (arg2 laser-printer))
	(print-direct arg1 arg2))


My typical demo is

(defmethod sum (x y) `(+ ,x ,y))

(sum 1 2)
(sum 'a 'b)
(sum * **)

(defmethod sum ((x number) (y number)) (+ x y))

(sum 1 2)
(sum 'a 'b)
(sum * **)


(defmethod sum (x (y list))
	(if (eq (car y) '+) `(+ x ,@(cdr y)) (call-next-method)))


(sum 1 2)
(sum 'a 'b)
(sum * **)

it shows incremental buildup of methods, shows off multi-methods, the
natural calling style, the use of standard lisp types as classes.

Demoing meta-objects is hard, you do that by showing how you can run
Loops & Flavors &etc code; but that really fits in that meta-objects are
mainly there for the system programmers who want to do things like use
object-oriented programming to either do backward compatibility things
or to implement new kinds of reasoning systems or otherwise hack the
system. Its important to put it in the standard because we think that it
allows what was otherwise going to be a divergence in the community sit
on a common base, and allows for future growth. 

re "methodologies for object-oriented programming", that's an awfully
big word for someone who wants simplicity. This is just another way of
writing functions & structures; , the methodology is pretty much the
same. You can make it lots more complicated than that and invent all
kinds of methodologies and papers and strategies, but you can also do
without 'em, just as we've done for Lisp.



∂06-Nov-86  1227	Kahn.pa@Xerox.COM 	Re: discussion wanted
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Nov 86  12:27:48 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 06 NOV 86 11:56:37 PST
Date: 6 Nov 86 11:56 PST
Sender: Kahn.pa@Xerox.COM
Subject: Re: discussion wanted
In-reply-to: Masinter.pa's message of 6 Nov 86 04:23 PST
To: Masinter.pa@Xerox.COM
cc: hpfclp!robert@hplabs.HP.COM,
 common-lisp-object-system@sail.stanford.edu
From: Ken Kahn <Kahn.pa@Xerox.COM>
Message-ID: <861106-115637-1190@Xerox>

I like your answer and your "user model" and examples.  The only
disagreement I have is with


    re "methodologies for object-oriented programming", that's an
    awfully big word for someone who wants simplicity. This is just
    another way of writing functions & structures; , the methodology is
    pretty much the same. You can make it lots more complicated than
    that and invent all kinds of methodologies and papers and
    strategies, but you can also do without 'em, just as we've done for
    Lisp.

I think there are lots of methodology issues that come up that most Lisp
programmers are not familiar with. Just as an example, consider the
issue of whether to subclass vs adding more slots to a class.  One would
like to present a methodology that says that if the subclasses differ
from the super in only trivial ways then it probably was a mistake to
make those subclasses.  E.g. 

(defclass ball (color ...) ...)

vs

(defclass ball ...)
(defclass red-ball ... (ball))
(defclass green-ball ... (ball))
...

I think this is just the tip of the iceberg.


∂06-Nov-86  1700	masinter.PA@Xerox.COM 	Re: discussion wanted 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Nov 86  17:00:13 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 06 NOV 86 15:30:02 PST
From: masinter.PA@Xerox.COM
Date: 6 Nov 86 15:28:51 PST
Subject: Re: discussion wanted
In-reply-to: Kahn's message of 6 Nov 86 11:56 PST
To: Kahn.PA@Xerox.COM
cc: Masinter.PA@Xerox.COM, hpfclp!robert@hplabs.HP.COM,
 common-lisp-object-system@sail.stanford.edu
Message-ID: <861106-153002-1463@Xerox>

Sorry, I think I typed too fast. I agree there are lots of methodology
issues. I just don't think there are a lot more *new* methodology issues
in Common Lisp + objects as there aready in Common Lisp without objects.

Your example is as true for structures as it is for classes. People
programming in Interlisp have always gone back and forth over how to lay
out records, whether something new should be a new record, etc. too.
This is an issue in Pascal or Mesa or Modula, about whether you define
new types or overload old ones, etc.

∂08-Nov-86  1319	RPG  	Clarification 
To:   common-lisp-object-system@SAIL.STANFORD.EDU    
Regarding DEFCLASS, did we really decide that there were two ways to
specify default values for a slot?

(deflcass foo (baz)
  (random-slot 3)
  (another-random-slot :default-value 3))

I'm sure we can find a millionsusers who want one and another million
who want the other, and I'm sure the simple case is useful in simple cases
and the verbose case in verbose cases, but do we really need to complicate
the thing specification with multiple ways of doing the same thing?

Regarding DEF-GENERIC-OPTIONS, did we agree to include INTERFACE and
METHOD-ARGUMENTS? It seems that this is excessive generality. I presume
one can accomplish all of this with meta-objects (GENERIC-FUNCTION-CLASS
and METHOD-CLASS). Do we need 2 ways to do this?

			-rpg-

∂08-Nov-86  1442	kempf%hplabsc@hplabs.HP.COM 	Re:  Clarification   
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 8 Nov 86  14:41:56 PST
Received: from hplabsc by hplabs.HP.COM ; Sat, 8 Nov 86 14:38:36 pst
Received: by hplabsc ; Sat, 8 Nov 86 14:38:38 pst
Date: Sat, 8 Nov 86 14:38:38 pst
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8611082238.AA29539@hplabsc>
To: RPG@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Re:  Clarification

>Regarding DEF-GENERIC-OPTIONS, did we agree to include INTERFACE and
>METHOD-ARGUMENTS? It seems that this is excessive generality. I presume
>one can accomplish all of this with meta-objects (GENERIC-FUNCTION-CLASS
>and METHOD-CLASS). Do we need 2 ways to do this?

I agree. This functionality would probably be best left to the meta-object
protocol.

		Jim Kempf	kempf@hplabs

∂09-Nov-86  1900	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Clarification     
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Nov 86  19:00:14 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 154097; Sun 9-Nov-86 21:58:46 EST
Date: Sun, 9 Nov 86 21:58 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Clarification 
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: The message of 8 Nov 86 16:19 EST from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Message-ID: <861109215812.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 08 Nov 86  1319 PST
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

    Regarding DEFCLASS, did we really decide that there were two ways to
    specify default values for a slot?

    (deflcass foo (baz)
      (random-slot 3)
      (another-random-slot :default-value 3))

    I'm sure we can find a million users who want one and another million
    who want the other, and I'm sure the simple case is useful in simple cases
    and the verbose case in verbose cases, but do we really need to complicate
    the thing specification with multiple ways of doing the same thing?

We did decide to do this, according to my notes.  The design rationale
was to make it possible to have slot options without specifying an
initial value, and at the same time to have an initial value without
having to resort to the more complex syntax of slot options.

If you want to re-open the issue, you should propose a specific alternative.

By the way, if we've decided to cut the specification down to something
simple, because it's too big and complicated looking, I have a lot of
suggestions!  However, I think Masinter made a fairly good case for it
not being quite as complicated as it looks.

    Regarding DEF-GENERIC-OPTIONS, did we agree to include INTERFACE and
    METHOD-ARGUMENTS? It seems that this is excessive generality. I presume
    one can accomplish all of this with meta-objects (GENERIC-FUNCTION-CLASS
    and METHOD-CLASS). Do we need 2 ways to do this?

This is still being discussed.  Obviously anything can be done with
meta-objects, so the fact that something can be done with meta-objects
cannot be grounds for not providing any other way to do it, or the
standard would consist of nothing but meta-objects.  The real basis for
deciding whether or not to put something into the programmer interface
is whether or not it will be heavily used by the type of programmers who
should not need to resort to meta-objects.

∂10-Nov-86  1003	Gregor.pa@Xerox.COM 	Re: Clarification  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Nov 86  10:03:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 NOV 86 09:58:11 PST
Date: 10 Nov 86 09:58 PST
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: Clarification 
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Sun, 9 Nov 86 21:58 EST
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: RPG@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <861110-095811-1075@Xerox>

    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

        From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

        Regarding DEFCLASS, did we really decide that there
        were two ways to specify default values for a slot?

    We did decide to do this, according to my notes.  The design
    rationale was to make it possible to have slot options without
    specifying an initial value, and at the same time to have an
    initial value without having to resort to the more complex syntax
    of slot options.

    If you want to re-open the issue, you should propose a specific
    alternative.

I remember us deciding this too.  But I don't remember us saying
explicitly that attempting to access a slot, whose value has not yet
been set (initialized) signalled an error.  Unless we specify that
accessing a slot whose value has not yet been initialized is an error, I
don't see that it is necessary to have a syntax which allows the use of
options without specifying an initial value.

To go even further, I don't see that having unitialized slots signal an
error is necessary, so I would propose the following syntax for slots in
defclass:

(defclass foo ()
  slot-1                           ;just slot name is legal
  (slot-2 nil)                     ;or name and default value
  (slot-3 nil :accessor bazola))   ;or name, default and options

∂10-Nov-86  1224	Bobrow.pa@Xerox.COM 	Re: Clarification  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Nov 86  12:23:48 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 NOV 86 11:36:50 PST
Date: 10 Nov 86 11:33 PST
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Clarification 
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 08 Nov 86
 13:19 PST
To: RPG@SAIL.STANFORD.EDU
cc: common-lisp-object-system@SAIL.STANFORD.EDU
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861110-113650-1243@Xerox>

    Regarding DEFCLASS, did we really decide that there were 
    two ways to specify default values for a slot?

    (defclass foo ()((baz) (random-slot 3) (another-random-slot
      :default-value 3))

My memory is that we didn't discuss this.  The issue seems to me whether
we should be able to specify a slot without specifying an initial value.
I spoke to Steele about this, and he felt that was a gap.   There are
two arguments for this
  1) there may be some cost to initializing storage that will always be
stored in first before access. Question, is this significant?  I thought
the Flavors trick of BLTing a dummy instance full of storage. 
  2) More important specifying an initial value when none is intended
could be misleading or wrong e.g. if :type is specified does the user
have to provide some form that evaluates to that kind.  This could be
hard if the type is not yet defined (or if it is hard to cons up one, or
if storing one could cause other side effects).  But we have not yet
agreed to support :type.  I think we ought to at least allow it. 

If we accept this, then what is the meaning of a slot description with
(baz) or just baz.  Are these legal?  The first I guess must mean no
default value, the second ???

An alternative syntax is to provide a special symbol e.g.
:no-default-value that means , and insist the user type that in.  This
simplifies the common case of extending the slot description from
(baz (baz-form)) to 
(baz (baz-form) :accessor zed) '

rather than having to insert :default-value.
  


-- danny

∂10-Nov-86  1301	Bobrow.pa@Xerox.COM 	Re: Clarification  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Nov 86  13:01:48 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 NOV 86 12:48:41 PST
Date: 10 Nov 86 12:48 PST
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Clarification 
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 08 Nov 86
 13:19 PST
To: RPG@SAIL.STANFORD.EDU
cc: common-lisp-object-system@SAIL.STANFORD.EDU
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861110-124841-1370@Xerox>

    Regarding DEF-GENERIC-OPTIONS, did we agree to include
    INTERFACE and METHOD-ARGUMENTS? It seems that this is excessive
    generality. I presume one can accomplish all of this with
    meta-objects (GENERIC-FUNCTION-CLASS and METHOD-CLASS). Do we need
    2 ways to do this?


I agree that this would be easily done in the metaobject protocol.  The
ease of writing code there would be enhanced by the kind of
functionality (functions and macros) I suggested in my simplified
version of define-method-combination.  I have seen no comments on my
last proposal (message of Oct 20).   Dave, what is your reaction? 


-- danny

∂10-Nov-86  1801	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: Clarification  
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 10 Nov 86  17:51:39 PST
Received: from ti-csl by csnet-relay.csnet id bt14349; 10 Nov 86 19:45 EST
Received: from Jenner (jenner.ARPA) by tilde id AA04705; Mon, 10 Nov 86 16:55:23 cst
To: Gregor Kiczales <Gregor.pa@XEROX.COM>
Cc: common-lisp-object-system@SU-AI.ARPA
Subject:        Re: Clarification
Date:           10-Nov-86 16:50:44
From: DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET
Message-Id:     <DUSSUD.2741035841@Jenner>


	    I remember us deciding this too.  But I don't remember us saying
	    explicitly that attempting to access a slot, whose value has not yet
	    been set (initialized) signalled an error.  Unless we specify that
	    accessing a slot whose value has not yet been initialized is an error, I
	    don't see that it is necessary to have a syntax which allows the use of
	    options without specifying an initial value.
	    
	    To go even further, I don't see that having unitialized slots signal an
	    error is necessary, so I would propose the following syntax for slots in
	    defclass:
	    
	    (defclass foo ()
	      slot-1                           ;just slot name is legal
	      (slot-2 nil)                     ;or name and default value
	      (slot-3 nil :accessor bazola))   ;or name, default and options
	   
	   

The problem with that reasoning is the initial values can come from
some other source: like make-instance or being set in a method (written,
not necessary read).


(defclass foo ()
	(slot-1 :accessor foo-1))

(make-instance 'foo :slot-1 1)  should be legal,

and that too:
(setf ob (make-instance 'foo)
(foo-1 ob 1)

The accessor option makes sense even without any default value.

I think we should keep the two ways to provide a default value, it's
not that heavy in the implementation, or documentation and reduces 
user frustration.

Patrick.

∂11-Nov-86  1132	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Draft Comments Part II  
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 11 Nov 86  11:32:45 PST
Received: from ti-csl by csnet-relay.csnet id ak04751; 11 Nov 86 13:27 EST
Received: from Jenner (jenner.ARPA) by tilde id AA16521; Tue, 11 Nov 86 09:47:16 cst
To: common-lisp-object-system@SU-AI.ARPA
Cc:  
Subject:        Draft Comments Part II
Date:           11-Nov-86 09:41:56
From: DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET
Message-Id:     <DUSSUD.2741096514@Jenner>

Page 2-26,Documentation:
The text seems to imply that the doc-type argument is meaningless
when the first argument is an object, a generic-function 
a class object or a method. Should it be optional then?

Page 2-27, Function-parameters:
If default values and supplied-p arguments are removed, 
do the &aux args make sense in there or should they be removed as well?
What does (Function-parameters 'foo ) returns?
 (Where foo is (defun foo (a n &key ((:start first-index))) ...))
The text should specify what happens when someone uses SETF 
with FUNCTION-PARAMETERS (I am not sure what it means anyway).

Page 2-28, generic-function-method-combination
I think the text should say method-combination-type instead of
method-combination.

Page 2-30, Get-method, 2-37 remove-method
The specializers argument should be consistent between those functions.
If the number of specializers is greater than what the generic function 
defines, should an error be signalled? (I would say yes).

There are some terminology inconsistencies throughout the document:
Built-in Class is used for Standard-Type-Class.
Dispatch and Method Selection are used in different places (Concept
and glossary).

One thing that needs to be decided for the document to be consistent
is what a method is, quoting RPG,
	"Methods are objects with, possibly, some internal structure - this has not
	yet, I believe, been decided.  Methods include a function, called the
	`method function,' and possibly some other user-visible information.  One
	such possible part of the internal structure might be a pointer back to
	the generic function of which the method is part.  The term `method' is
	commonly used to refer to method objects."
Right now the document is very vague about methods. get-method return a method-object 
but the only function in the document that will accept method object is DOCUMENTATION.
If they are first class objects, then we must be able to get some information out of them 
(arglist, qualifier, function...).



Patrick.

∂11-Nov-86  1311	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: Method combination -- writeup for revised syntax  
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 11 Nov 86  13:10:43 PST
Received: from ti-csl by csnet-relay.csnet id aa05418; 11 Nov 86 14:35 EST
Received: from Jenner (jenner.ARPA) by tilde id AA22690; Tue, 11 Nov 86 12:20:38 cst
To: Danny Bobrow <Bobrow.pa@XEROX.COM>
Cc: Moon@SCRC-STONY-BROOK.ARPA, common-lisp-object-system@SU-AI.ARPA
Subject:        Re: Method combination -- writeup for revised syntax
Date:           11-Nov-86 12:15:08
From: DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET
Message-Id:     <DUSSUD.2741105702@Jenner>

Danny,

If I read your new proposal correctly, the only significant differences
you have with what Moon proposes are:
- FIND-ALL-METHODS replaces the method-selection part of DEFINE-METHOD-COMBINATION.
As I see it, it still does not solve the point raised by Moon 
about signalling an error if there are extra methods that have not 
been matched. 

- The filter language of FIND-ALL-METHODS. This language can be integrated into
the method-selection option of Moon's DEFINE-METHOD-COMBINATION.

- Having a SORT-METHODS that can merge several method lists. This one can be useful.

I would be in flavor of keeping Moon's proposal, integrating the filter language
in the method-selection is somebody convinces me that it should be included, and
add the SORT-METHODS function.

PS. Has anybody thought about my proposal for method combination selection?

Patrick.

∂12-Nov-86  0811	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Draft Comments Part I   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 12 Nov 86  08:10:51 PST
Received: from ti-csl by csnet-relay.csnet id aa18603; 12 Nov 86 10:24 EST
Received: from Jenner (jenner.ARPA) by tilde id AA17196; Wed, 12 Nov 86 07:23:07 cst
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: common-lisp-object-system@SU-AI.ARPA
Subject:        Draft Comments Part I
Date:           12-Nov-86 07:16:51
From: DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET
Message-Id:     <DUSSUD.2741174208@Jenner>


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

RETURN-PATH:    <>
TO:             DUSSUD@Jenner
DATE:           9-Nov-86 14:50:57
FROM:           Mailer@Jenner
MESSAGE-ID:     <Mailer.2740942256@Jenner>

Mail not sent to the following people:

  common-lisp-object-system@su-ai.arpa
  Dick Gabriel <RPG@su-ai.arpa>

Because: The OPEN operation timed out before the connection became ESTABLISHED
Retrying until 11/12/86 14:31:45

TO:             Dick Gabriel <RPG@su-ai.arpa>
CC:             common-lisp-object-system@su-ai.arpa
SUBJECT:        Draft Comments Part I
DATE:           7-Nov-86 14:31:48
FROM:           DUSSUD@Jenner
MESSAGE-ID:     <DUSSUD.2740768305@Jenner>

Here are some comments about the TEX files that Linda sent me:


Pages 1-6 and 1-19, structure-class is mentioned, I was under the 
impression that we agreed to subsume the type-producing version 
of DEFSTRUCT under the regular defclass mechanism. It will happen that
DEFSTRUCT will produce classes having at most one class-component
but I don't see a need for a separate metaclass.

I have trouble understanding the rationale for the type/class 
diagram on page 1-7. If it says that the user can rely on it to 
define methods, I think it's not quite right.
Some types listed as separate can be collapsed together (long-float 
and double-float).

Method Selection and Method Combination is placed before Class Precedence
even though method combination makes use of the Class Precedence List concept.

From the Basic User Interface Functions:

Page 2-15: "this is the same behavior as a DEFVAR with no initial value form"
I don't think so, DEFVAR with no value merely proclaims the variable to be 
special. The variable can be bound before the DEFVAR evaluation and if so the user is 
free to reference it. In the case of an instance slot, we know that it was 
never initialized before.

Page 2-18: "the new generic function object is returned as the results"
It seems inconsistent with the rest of DEF... which return the name of their
objects. Also, I found "If a DEFGENERIC form is evaluated when a generic function 
of the same name is already defined, the new definition replaces the old one",
which is (or isn't?) different from "The existing generic-function object is modified"
found in page 1-8.

More later...

Patrick.





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



∂12-Nov-86  0820	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Draft Comments
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 12 Nov 86  08:19:54 PST
Received: from ti-csl by csnet-relay.csnet id ab18603; 12 Nov 86 10:27 EST
Received: from Jenner (jenner.ARPA) by tilde id AA17274; Wed, 12 Nov 86 07:24:20 cst
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: common-lisp-object-system@SU-AI.ARPA
Subject:        Draft Comments
Date:           12-Nov-86 07:18:06
From: DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET
Message-Id:     <DUSSUD.2741174284@Jenner>


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

RETURN-PATH:    <>
TO:             DUSSUD@Jenner
DATE:           9-Nov-86 16:23:50
FROM:           Mailer@Jenner
MESSAGE-ID:     <Mailer.2740947829@Jenner>

Mail not sent to the following people:

  common-lisp-object-system@su-ai.arpa
  Dick Gabriel <RPG@su-ai.arpa>

Because: The OPEN operation timed out before the connection became ESTABLISHED
Retrying until 11/12/86 16:11:37

TO:             Dick Gabriel <RPG@su-ai.arpa>
CC:             common-lisp-object-system@su-ai.arpa
SUBJECT:        Draft Comments
DATE:           7-Nov-86 16:11:40
FROM:           DUSSUD@Jenner
MESSAGE-ID:     <DUSSUD.2740774297@Jenner>

There is an inconsistency between the Concept and Design Rationale
sections concerning built-in classes:
In the Design Rationale section, there is a bunch of CL types
that don't have any associated class. In the Concept section, 
only Atom and Common don't have associated class.

Patrick.





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



∂12-Nov-86  1225	Moon@ALDERAAN.SCRC.Symbolics.COM 	Comments on the function chapter    
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 12 Nov 86  12:25:27 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 19674; Wed 12-Nov-86 15:23:12 EST
Date: Wed, 12 Nov 86 15:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Comments on the function chapter
To: Common-Lisp-Object-System@SU-AI.ARPA
Message-ID: <861112152312.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

I haven't gone carefully through the Concepts chapter yet, but here is the
first installment of my comments on the 30 October version of the Functions
chapter (which seems to be the most recent version).

GENERAL COMMENTS:

The term "user interface" is used all over, yet the proposed standard does
not in any way specify a user interface.  A user interface is something for
end-users, typically involving display screens, keyboards, etc.  The title
should be changed to "programmer interface".

-------

This spec throws a bewildering variety of functions at the reader.  I would
like to see a more layered presentation.  There are two ways to do this;
one is to have a separate alphabetized dictionary of functions for each
layer.  The other is to have an introductory section organized by layers,
containing one-line descriptions of the functions in each layer, followed
by a single alphabetized dictionary of everything.  I don't care which we
do, but I don't think the Concepts chapter can substitute for that
introductory section.  I suggest the following four layers:
(1) Basic programming language facilities that all programmers need to understand
(2) Define-method-combination and its support functions
(3) Primitive functions that implement the macros in (1) and can be used to build tools
(4) Meta-objects

Some might argue that this type of layered presentation is only necessary
in a user manual and not in a standards specification.  I don't believe
that.  Anything we can do to make it easier for the X3J13 committee and
others to understand this proposed standards specification will be to the
good.

I would categorize the existing functions in the Functions chapter as follows:
(1) call-next-method, change-class, defclass, defgeneric, defgeneric-setf,
    defmethod, defmethod-setf, describe, make-instance, print-object,
    with-slots
(2) define-method-combination
(3) add-method, class-of(*), documentation, get-method(+),
    lambda-list-specializers(+), make-generic-function, remove-class,
    remove-method, remove-setf-method, slot-value(*)
(4) argument-precedence-order, function-parameters,
    generic-function-method-combination, generic-function-p
(*) means maybe this belongs in category 1 instead
(+) means maybe this belongs in category 4 instead

-------

A format needs to be designed for documenting specializable generic
functions (that is, functions that are already defined for which the
programmer is expected to define methods).  The current descriptions of
these functions (describe, print-object, and possibly change-class) does
not work very well, because they don't fit the function-description format
being used.

-------

Several functions (add-method, get-method, remove-method) take an argument
that is a generic-function or the name of a generic-function.  We have to
decide how to deal with the not obviously named generic-functions involved
with defmethod-setf and defgeneric-setf.  We discussed this around 21 Oct
and there didn't seem to be total agreement, but my reading is that we have
to do two things:
(1) There is a new function get-setf-generic-function, which takes as its
argument a generic function or the name of a function, and returns the
associated setf-generic-function.
(2) The functions that accept the name of a generic function also accept
a list (SETF f), where f is the name of a function; this is a synonym for
(get-setf-generic-function f).  Note well: f doesn't have to be a generic
function, it can be an ordinary function.

My reading is that we can't do the third thing discussed then, which was to
make Common Lisp standardize more of the insides of setf.

None of this would be necessary if Common Lisp had function-specs (see any
Zetalisp manual), but since it doesn't, we have to do something.

We need to hear from RPG about whether this is consistent with his
anonymous generic function ideas, or would somehow preclude them.

-------

Several functions (add-method, get-method, remove-method) use the phrase
"the qualifiers argument specifies the method combination options".  I
don't believe this is correct terminology.  The word "options" should
certainly not be used, and the way this is phrased would make the reader
think that this is the same thing as the :method-combination clause of
defgeneric.

Instead it should say "The qualifiers argument is a possibly-empty list of
method qualifiers" and cross-reference to the section explaining what
method qualifiers are (right now this is only a brief paragraph on
page 1-8).

-------

Several functions (add-method, get-method, lambda-list-specializers,
remove-method) refer to lists of argument specializers.  An easy problem
is the reference to giving lists of argument specializers to defmethod;
defmethod doesn't take any such argument.  Another easy problem is
that these are called parameter specializers, not argument specializers;
see the defmethod writeup.

More difficult is that I can't find any definition of what is in these
lists.  Three issues:

(1) Is an argument specializer, as seen at this level, a class object
or a Common Lisp type specifier?

(2) How are the various specializers combined into a list?  Don't overlook
the possibility of future extention to specialization of keyword arguments.
Quite a long time ago I made a proposal about this, but I don't know what
its status is; we haven't discussed it recently.  Briefly, the proposal
was that a method's list of argument specializers would take the form

  ((pos type) ...)

where pos is one of:
  a non-negative integer, for required and optional arguments
  a symbol, for keyword arguments
  something else, for &rest arguments, if it made sense to specialize them

Furthermore the list would be sorted into a canonical order, with the
positional arguments in numerical order followed by the keyword arguments
in alphabetical order [need some resolution of identically named symbols
in different packages].

(3) Are unspecialized argument specializers (i.e. the symbol T) removed
from the list?

-------

TYPEP and TYPE-OF need to be mentioned in the Functions chapter, since
their CLtL behavior is modified by the proposal.  Each writeup for a
function that is already defined by Common Lisp should note that fact
in its remarks field (or in a special field employed for this purpose).

-------

I don't like the use of a single italicized word to stand for a pair
of list elements (as in defclass and with-slots).  This is standard
practice in BNF, but in Lisp it makes it all too easy for the reader
to get confused about where the parentheses go.  I looked through CLtL
and could not find any instances of this practice.  Unless CLtL uses
this practice, I think we should avoid it.

-------

COMMENTS ON SPECIFIC FUNCTIONS:

This will have to wait for another day.  I'm out of time, and this message
is already pretty long.

∂12-Nov-86  1256	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: Next Step 
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 12 Nov 86  12:54:59 PST
Received: from ti-csl by csnet-relay.csnet id ah21201; 12 Nov 86 14:59 EST
Received: from Jenner (jenner.ARPA) by tilde id AA17062; Wed, 12 Nov 86 07:21:35 cst
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: common-lisp-object-system@SU-AI.ARPA
Subject:        Re: Next Step
Date:           12-Nov-86 07:15:17
From: DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET
Message-Id:     <DUSSUD.2741174113@Jenner>

   ------------------
I apologize I you get this message twice, we had trouble getting to Arpanet.

TO:             Dick Gabriel <RPG@su-ai.arpa>
CC:             common-lisp-object-system@su-ai.arpa
SUBJECT:        Re: Next Step
DATE:           7-Nov-86 13:53:10
FROM:           DUSSUD@Jenner
MESSAGE-ID:     <DUSSUD.2740765987@Jenner>

	    Because it appears that FUNCTION.TEX is essentially stable and because the
	    deadline for sending it to X3J13 approaches, Linda and I are going to
	    start going over it to
	    
	    1. make it read like a specification (dull but precise);
	    2. make sure exactly the decisions we reached are discussed; and
	    3. turn it into TEX.
	    
	    If there are major comments about the contents of FUNCTION.TEX,
	    you should send them soon.
	    
				    -rpg-

Dick,
Basically, I agree with Moon concerning the sending of the 
draft to X3J13. I guess the message we got from Robert Heckendorn is 
typical of what's waiting for us if we send something which is not 
complete and/or not completely agreed upon.

The Common Loops presentation given by Danny at the last 
meeting is close enough to what has been defined/agreed upon so far. 
We wouldn't bring that much to the X3J13 members.

I guess if any preparation needs to be done for December 10, 
it should be towards getting intelligent replies to concerns
such as those Robert Heckendorn has.

Patrick.

P.S Are we going to meet again in Dallas?






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



∂12-Nov-86  2241	@MC.LCS.MIT.EDU:MOON%ML.AI.MIT.EDU@MC.LCS.MIT.EDU 	Second installment of comments on Functions chapter   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Nov 86  22:40:58 PST
Received: from ML.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 13 NOV 86  01:42:52 EST
Date: Thu, 13 Nov 86 01:40:21 EST
From: "David A. Moon" <MOON%ML.AI.MIT.EDU@MC.LCS.MIT.EDU>
Subject:  Second installment of comments on Functions chapter
To: Common-Lisp-Object-System@SU-AI.ARPA
Message-ID: <[ML.AI.MIT.EDU].1835.861113.MOON>

I'm omitting all comments on TeX errors, formatting, and vestiges of
previous versions that weren't deleted.  I comment on a few typos that
might be easy to miss, but otherwise concentrate on content issues.

ADD-METHOD:

Doesn't say whether the result ("the modified generic function")
is the same generic function that was supplied as an argument,
or is a freshly-created generic function object that is similar
to the argument but has a method added to it.  I believe the answer
is that it is the same object.  Fix this in both "purposes" and
"values".

The function argument is not described.  What are the requirements on this
function as to what arguments it receives, what values it returns, what
dynamic environment it runs in, what it can do, etc.?  I would like
implementations to be free to have different argument lists on their method
functions than the arguments of the generic function; this permits some
important optimizations.  There are also requirements for CALL-NEXT-METHOD.
The best way, I think, would be to require that the function argument to
add-method be a function that has been transformed by a method on the
generic function before being compiled.

ARGUMENT-PRECEDENCE-ORDER:

I don't understand why this function exists.  Is it just for completeness,
so that all slots of a generic-function object have accessors?

CHANGE-CLASS:

In the first line, "the new class" should be "a new class".

The instance argument should not be required to have a metaclass of
class, since other metaclasses might also support change-class.
This is really trying to say that not all metaclasses support
change-class, but the metaclass you get by default is required to
support it.

Can the new-class argument be the name of a class?

We discussed (in Menlo Park) restrictions on when change-class can
be called; they need to go into the document.

Is change-class a generic function that can be specialized by the user?

CLASS-OF:

Values field missing, it's a class object (stress not a class name).

The first sentence of Remarks is misleading since make-instance allows the
name of a class as its class argument.  It also would not be true in
systems, such as Flavors, that have an extension such that make-instance
can be given a more general class and then instantiate a more specific
class chosen according to the init options specified.  This whole sentence
is pretty useless, actually.  It's trying to be a definition of "most
specific class" which is pretty hard to define if it isn't self-explanatory.

DEFCLASS:

I think some or all of the :allocation options are complex and unnecessary
and should be removed.  Certainly :dynamic and :none should go away.

(:instantiable nil) is kind of a double negative.  In general, options that
are turned on by default are confusing.  I think it would be better to use
a positive wording, e.g. :abstract, so it can be off by default.  Actually
the same arguments for eliminating :required-methods apply to this option.

We didn't discuss or agree on :predicate.  It seems to me that typep serves
this function adequately, since the class and type systems are integrated.

If a class with the specified name is already defined, does this make a new
class object, or modify the existing one?  I think it should modify.

Is it really true that a slot-name can be any non-null symbol?  Because
of with-slots, I think the real restriction is that a slot-name must be
a symbol that is legal to use as a variable.  For instance, keywords would
be illegal.  Opinions?

Is the note under :allocation :class saying that a local slot description
completely overrides an inherited one really true?  This would imply that
you could turn off :default-value or :accessor by giving another slot
description without those options, and I think in Menlo Park we decided
against this.  Perhaps the note applies only to :allocation?

The description of :reader says non-null-symbol in a couple of places
where it means to say generic-function-name.

With :accessor-prefix and :reader-prefix, how does one specify that the
accessor name is to be the same as the slot name?  A prefix of "" won't
work, since that re-interns the accessor name in the current package.  Do
we need two more options for this?  Should we treat the symbol NIL as a
special case?  I think two more options would be more tasteful.

The description of :constructor will have to be expanded when we
finalize the initialization protocol.  Actually, :constructor is
only an efficiency optimization, so it could be removed from the
standard and people could just write functions that call make-instance.

I believe :initable-slots should be marked "still under discussion."

The Values field says the name of the class is returned but the Purpose
field four pages earlier says the class object is returned.  Returning
the object is more consistent with other functions.

In Remarks: "argument specifier" -> "parameter specializer".  When it says
a class can override an inherited option, "override" needs to be defined
more precisely; some of the options are additive, others truly override.

DEFGENERIC:

Purpose field: in "symbol function cell of the symbol", don't say "symbol"
twice.  If the symbol already has a function definition, what happens?
I think the answer is if the definition is a generic function, it is
modified (rather than replaced with a new generic function object).
The second paragraph of the Remarks field seems to contradict this,
but I believe that was not our intent.  If a new generic-function object
is made, does it receive the methods of the old generic-function or
does it start life with no methods?

If the prior definition is an ordinary function, is it turned into a
default method or discarded?

The syntax of :argument-precedence-order is described but not what it does.
Just say that arguments are considered in the order listed, or words to
that effect.

The discussion of declare is self-contradictory.  I would rewrite the whole
paragraph as follows:
(declare declaration+) Declarations that could appear at the beginning of
the body of a defun with the same name and lambda-list are permitted.  Type
declarations of the parameters are used by some Common Lisp implementations
when compiling calls to the generic function.  The optimize declaration can
be used to control whether method selection is optimized for speed or for
space.  An implementation should treat any declaration it does not
recognize the same as it would if it appeared in defun (see Common Lisp the
Language page 161).  Declarations in defgeneric are not automatically
incorporated into the bodies of methods.

DEFGENERIC-SETF:

Note that the first subform does not have to be a generic function name.
It can be an ordinary function name.

DEFMETHOD:

If a method for the same generic function, with the same qualifiers
and specializers, already exists, does defmethod update the existing
method object or create a new one?  I think it should update.

DEFMETHOD-SETF:

Same comments as in defgeneric-setf and defmethod.

DOCUMENTATION:

This seems to be unsure whether it is the Common Lisp documentation
function, which takes two arguments that together are the name of
an entity, or the Zetalisp documentation function, which takes one
argument.  Is the intent to allow documentation to be applied to
meta-objects as well as to names?  Some systems do not store the
documentation strings inside the objects, but instead associate
them with the names, so that doesn't seem to fit.  I suggest refraining
from extending this function beyond Common Lisp.  The issue here is
that Common Lisp doesn't have function-specs, so methods can't have names.
There is no problem with classes, generic functions, and method-combination
types.

FUNCTION-PARAMETERS:

I don't understand what relation this has to object-oriented programming.
I think it should be removed from this proposal.

GENERIC-FUNCTION-METHOD-COMBINATION:

I don't understand what the value returned by this is.  Is it the
cdr of a :method-combination defgeneric clause?  Also I don't think
this function is needed, except at the meta-object level.

GENERIC-FUNCTION-P:

This function is unnecessary, use TYPEP.

GET-METHOD:

What happens if a function whose name is given by the first argument
exists, but it is not generic?  Does this return NIL or signal an error?

LAMBDA-LIST-SPECIALIZERS:

I don't understand why this function needs to be documented.

MAKE-GENERIC-FUNCTION:

This has a lot of little inconsistencies with defgeneric.  It's not clear
which arguments are required and which are optional.  This is best settled
after defgeneric has stabilized.

PRINT-OBJECT:

The writeup is just some mail I sent and needs to be translated into English
and probably to be shortened.

REMOVE-SETF-METHOD:

This should not exist, since there is no add-setf-method nor get-setf-method.

SLOT-VALUE:

This mentions the read-only slot feature, which has been removed.

What happens if there is no slot with the given name?
I think it should signal an error.

Do primitive (aka built-in) (aka standard-type) objects have slots?
I think there should be no slots defined by the standard, but the
possibility of implementation-defined slots should be allowed.

Do defstructs have slots that slot-value can access?
I can't figure out what I think.

WITH-SLOTS:

Is the first subform really allowed to be empty?  I.e. (with-slots () body...)

The :prefix option needs to describe interning in the current package,
same as in the :accessor-prefix option of defclass.

The make-horizontal example should be modified to reflect the fact
that the instance can be any expression, not just a variable.  Remove
the let.

The second paragraph under Remarks is a bit mixed up.  The first sentence
should say "signals an error."  The second sentence is probably not
about inferring the class at all; I think what this really means to say
is that with-slots signals an error if two of the pseudo-variables have
the same name.  This can happen when more than one instance clause is
given, and can also happen with one instance when :prefix is given and
there are two slot names with the same name but in different packages..

∂13-Nov-86  1217	RPG  	ARGUMENT-PRECEDENCE-ORDER    
To:   common-lisp-object-system@SAIL.STANFORD.EDU    

I presume this and the other facet accessors for generic functions are
here because they are SETFable. If they are not SETFable, then possibly
they don't need to be in the specification.  Also, if these facets are not
SETFable, then any anonymous generic function facility will be
extraordinarily ugly.

FUNCTION-PARAMETERS is possibly included due to an oversight.

			-rpg-

∂13-Nov-86  1438	Moon@STONY-BROOK.SCRC.Symbolics.COM 	ARGUMENT-PRECEDENCE-ORDER        
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 13 Nov 86  14:37:53 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 158819; Thu 13-Nov-86 15:34:20 EST
Date: Thu, 13 Nov 86 15:33 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ARGUMENT-PRECEDENCE-ORDER    
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: The message of 13 Nov 86 15:17 EST from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Message-ID: <861113153339.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 13 Nov 86  1217 PST
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>


    I presume this and the other facet accessors for generic functions are
    here because they are SETFable. If they are not SETFable, then possibly
    they don't need to be in the specification.  Also, if these facets are not
    SETFable, then any anonymous generic function facility will be
    extraordinarily ugly.

That's a good point.  Either these should be SETFable, or
MAKE-GENERIC-FUNCTION should accept a keyword argument that is a generic
function to be updated from the other arguments, or there should be a
function MODIFY-GENERIC-FUNCTION which takes a required generic function
argument followed by the same keyword arguments that MAKE-GENERIC-FUNCTION
accepts.  I prefer the last of these three alternatives, but any of them
seems acceptable.

∂13-Nov-86  1514	masinter.pa@Xerox.COM 	Re: ARGUMENT-PRECEDENCE-ORDER        
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Nov 86  15:13:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 NOV 86 15:10:55 PST
Date: 13 Nov 86 15:10 PST
From: masinter.pa@Xerox.COM
Subject: Re: ARGUMENT-PRECEDENCE-ORDER    
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Thu, 13 Nov 86 15:33 EST
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: RPG@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <861113-151055-1494@Xerox>

If the spec just says "there's a class generic-function which has slots
... ... and conc-name "generic-function", then you get
make-generic-function and all of the accessors and the fact that they
are setfable as well.

There's this nice construct we've invented called defclass; it allows
programmers, with a single defclass, to define all kinds of
constructors, accessors, setf methods and the like. It lets you say a
lot of things tersely. 

Why can't we use it in the spec, too?


∂14-Nov-86  0047	RPG  	Altering Generic Functions   
To:   common-lisp-object-system@SAIL.STANFORD.EDU    

It seems there are three proposals for the primitives used for modifying
generic functions. I will refer to the parts of generic functions as
`facets.'  Assuming that all of the facets discussed in the current draft
specification are accepted, the modifiable facets are:
argument-precedence-order, generic-function-class, interface,
method-arguments, method-class, and method-combination-type.  Here are the
proposals:

1. There is a series of facet accessors, each accessor naming a SETFable
place.

2. There is a function named MODIFY-GENERIC-FUNCTION that takes a required
generic function argument followed by the same keyword arguments that
MAKE-GENERIC-FUNCTION accepts.  Furthermore, there is a function, possibly
named GENERIC-FUNCTION-FACETS, that returns six values, one for each
modifiable facet.

3. MAKE-GENERIC-FUNCTION accepts a keyword argument that is a generic
function to be updated from the other arguments. In addition there is
function, possibly named GENERIC-FUNCTION-FACETS, that returns six values,
one for each modifiable facet.

Here are the advantages and disadvantages of each, as I see them.

1. There are six new function names, one for each modifiable facet.
Because these functions simply are accessors to parts of some larger
object, this requires knowing about many function names. Changing the
facets, though, only requires knowing that the accessors are SETFable.

2. One new function is added, but with six keywords to remember. These
keywords are the same as the keywords for MAKE-GENERIC-FUNCTION, so the
additional cognitive overhead is low. There is a new function that returns
six values, and the order of the values will be difficult or impossible to
remember.

3. This option is very much like number 2, but the name of the function is
misleading - one is not making a generic function, one is altering some of
its characteristics.

Contrasting option 1 with options 2 and 3, the choices we face are similar
to those faced earlier with the sequence functions in Common Lisp.  The
two basic choices were: a large series of independent functions or a
smaller series with a set of keyword arguments. The Common Lisp designers
chose the keyword route.

The analogy breaks down here because we require a complex informational
function, GENERIC-FUNCTION-FACETS, which is needed to find out the current
facets of a generic function. Without it, it is not possible to modify
programmatically some facets of one generic function to be the same as
those of another.

Therefore, I favor option 1.

Larry Masinter suggsted something interesting. Generic functions could be
defined to be instances of a generic-function class. Therefore, these six
facets are simply `slots' defined by the generic-function class; instances
have these `slots,' and they are naturally SETFable.

			-rpg-

∂14-Nov-86  0951	Gregor.pa@Xerox.COM 	Re: Altering Generic Functions    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Nov 86  09:50:55 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 NOV 86 09:38:39 PST
Date: 14 Nov 86 09:38 PST
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: Altering Generic Functions   
In-reply-to: Larry Masinter <Masinter.pa@Xerox.com>'s message of 13 Nov
 86 15:10 PST
To: Masinter.pa@Xerox.COM
cc: common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <861114-093839-2174@Xerox>

The original version of the spec I wrote, had defclass forms in it and
said things like: "Generic functions behave as if they were defined by
the following defclass".

The problem with doing things like that of course is that you have to
say explicitly that SETFing one of the accessors not only changes the
value of the slot, but also has the "desired effect" on the generic
function as a whole.

Otherwise, the reader doesn't know whether setf an accessor will do
"what they want" or just make the internal datastructure of the generic
function inconsistent.

Having to make this explicit reflects a common design decision when
defining a class, namely: "should setf of a slot accessor be the
complete interface for changing the value in a slot, or should their be
some higher-level function which is called to change the value in the
slot as well as change any other information that must stay in sync with
that value."

This kind of situation is common enough and important enough that it
should be brought up explicitly in the spec.

∂14-Nov-86  0951	Gregor.pa@Xerox.COM 	Re: Altering Generic Functions    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Nov 86  09:51:13 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 NOV 86 09:41:15 PST
Date: 14 Nov 86 09:41 PST
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: Altering Generic Functions   
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 14 Nov 86
 00:47 PST
To: RPG@SAIL.STANFORD.EDU
cc: common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <861114-094115-2179@Xerox>

    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
    Subject: Altering Generic Functions
    To: common-lisp-object-system@SAIL.STANFORD.EDU 


    It seems there are three proposals for the primitives used for
    modifying generic functions.

There is also the obvious combination of proposals 1 and 2, call it
proposal 4.

4. There is a series of facet accessors, they are not setfable; there is
a function named modify-generic-function that takes a required generic
function argument followed by the same keyword arguments that
MAKE-GENERIC-FUNCTION accepts.

∂14-Nov-86  0950	MASINTER.PA@Xerox.COM 	Re: Altering Generic Functions  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Nov 86  09:50:49 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 14 NOV 86 08:45:43 PST
From: MASINTER.PA@Xerox.COM
Date: 14 Nov 86 8:44:28 PST
Subject: Re: Altering Generic Functions
In-reply-to: RPG@SAIL.STANFORD.EDU's message of 14 Nov 86 00:47 PST
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <861114-084543-2087@Xerox>

Yes, if you are going to vote, I think my suggestion should be listed as
a separate option. Call it option 4. I think you summarized it
adequately, although I will add that whether the facets are SETF-able of
course depends on whether they are declared as such in the class, and
that it is possible to disallow SETFing of one of the facets simply. 

I will add in favor of Option 4 that it allows a natural explaination of
how one might build specialized kinds of generic functions.

∂14-Nov-86  1114	masinter.pa@Xerox.COM 	Re: Altering Generic Functions       
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Nov 86  11:13:48 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 NOV 86 10:35:32 PST
Date: 14 Nov 86 10:34 PST
From: masinter.pa@Xerox.COM
Subject: Re: Altering Generic Functions   
In-reply-to: Gregor Kiczales <Gregor.pa>'s message of 14 Nov 86 09:38
 PST
To: Gregor.pa@Xerox.COM
cc: common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <861114-103532-2286@Xerox>

Giving a prototypical defclass for generic-function  and then saying
"explicitly that SETFing one of the accessors not only changes the value
of the slot, but also has the "desired effect" on the generic function
as a whole. "

is a natural, simple, easy to explain, consistent and unambiguous
interface to generic function objects.

I agree that there is a common design decision of which this is an
instance, and it is not universally true that one always wants to make
"setf of a slot accessor be the complete interface for changing the
value in a slot". The most important consideration in this common design
decision is whether it frequently necessary to SETF several slots
independently before making the object consistent.

An extension to the current spec which would make this design decision
moot in many more cases would be a generic MODIFY operation, briefly:

(modify object :slot value :slot value :slot value ...)

which setfs the respective slots; for those objects which have global
consisitency requirements, the modifications could be done "in parallel"
and the consistency computed at the end.

∂14-Nov-86  1626	Bobrow.pa@Xerox.COM 	Re: Altering Generic Functions    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Nov 86  16:25:27 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 NOV 86 13:52:48 PST
Date: 14 Nov 86 13:52 PST
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Altering Generic Functions   
To: common-lisp-object-system@SAIL.STANFORD.EDU
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861114-135248-2568@Xerox>

   Larry said:
  An extension to the current spec which would make this design
    decision moot in many more cases would be a generic MODIFY
    operation, briefly:

    (modify object :slot value :slot value :slot value ...)

    which setfs the respective slots; for those objects which have
    global consisitency requirements, the modifications could be done
    "in parallel" and the consistency computed at the end.


I think this is appropriate, though I would  like to avoid having
keywords and to use the real slot-names.  I propose we also provide the
dual function
  (slot-values slot-name1 slot-name2 ...)
which would return, in the order specified, the values of slot-name1
slot-name2 ....

With this, one would not need to define accessors.

If this proposal is not accepted in general, then at least we should
provide a dual for
(modify-generic-funtion  generic-function :key1 value :key2 value ...)

that is
(aspects-of-generic-function :key1, :key2 ...) 
that returns this set of values.

I this answers a previous objection of having to leearn both a set of
slot names and a set of access funetions.


-- danny

∂14-Nov-86  1746	RPG  	Altering Things    
To:   common-lisp-object-system@SAIL.STANFORD.EDU    

Larry's comments bring up the issue of how far we want to take the
meta-class concept in this specification. The standard-type-classes have a
different meta-class from those of DEFCLASS. DEFCLASS is somewhat like
DEFSTRUCT in that it defines an instance structure with slots in which
values may be stored.

As Larry points out, generic functions can made instances of a generic
function class whose meta-class directs the creation of `slot accessors
and updators' that modify facets of the precise sort thing that generic
functions happen to be in some implementation.

Thinking of these facets as slots is quaint, in the same way that one can
think of the `mantissa' and `exponent' as slots in a floating-point number.
Of course, with meta-objects this can done. I say this is `quaint' because
it is promulgating a misnomer of sorts, the misnomer of referring to the
subparts of eveything as `slots.' 

It is the class of CLASS that defines `slots.' It would be the class of
FLOATING-POINT-CLASS that would define `mantissa' and `exponent.' We would
be taking the terminolgy specific to DEFCLASS-style classes and misapplying
it in talking about floating-point numbers.

We will recommend to X3J13 that they split DEFSTRUCT into DEFCLASS and
DEFRECORD, which makes sense. When we try to think of floating-point
numbers as instances of classes, and when we break floating-point numbers
into mantissas and exponents, we are making the classes into
record-structure-defining objects. Similarly, thinking of generic functions
as objects whose `slots' are SETFable, we are using the DEFCLASS terminology
to impose some record structure on top of generic functions.

Smalltalk takes seriously the approach I'm hinting at, and possibly we
want to take it seriously as well. The simple class CLASS approach we in
fact take is a simplfication of the whole-hog, Smalltalk approach.

			-rpg-

∂14-Nov-86  1806	Gregor.pa@Xerox.COM 	Re: Second installment of comments on Functions chapter    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Nov 86  18:05:43 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 NOV 86 17:24:09 PST
Date: 14 Nov 86 17:21 PST
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: Second installment of comments on Functions chapter
In-reply-to: "David A. Moon" <MOON%ML.AI.MIT.EDU@MC.LCS.MIT.EDU>'s
 message of Thu, 13 Nov 86 01:40:21 EST
To: MOON%ML.AI.MIT.EDU@MC.LCS.MIT.EDU
cc: Common-Lisp-Object-System@SU-AI.ARPA
Message-ID: <861114-172409-2772@Xerox>

    Date: Thu, 13 Nov 86 01:40:21 EST
    From: "David A. Moon"

    ADD-METHOD:

    The function argument is not described.  What are the
    requirements on this function as to what arguments it receives,
    what values it returns, what dynamic environment it runs in, what
    it can do, etc.?  I would like implementations to be free to have
    different argument lists on their method functions than the
    arguments of the generic function; this permits some important
    optimizations.

I don't see that there should be any restrictions on the function
argument other than that it should have an argument list which is
"congruent" with the generic function in the same way that multiple
defmethods must have congruent argument lists.

I don't see any problems with implementing this "looser" restriction on
the function argument in a way that does not incur a performance
penalty.

In addition, Danny and I spent some time talking about add-method today.
We would like to introduce a new function make-method, and change
add-method as follows (please remember that I may make a mistake
transcribing this, or may for some other reason misrepresent Danny's
opinion):

MAKE-METHOD type-specifiers function

  makes a method object of class method.  Invoking the method will call
function.

Note that methods are funcallable entities in the same way generic
functions are.  In particular, it is legal to say:

(funcall (make-method '(symbol) #'(lambda (x) (list 'symbol x))) 'foo)

Also note that there is no accessor for the function "field" of a
method.  The function that a method calls when it is invoked is an
immutable property of the method.

ADD-METHOD generic function method

  adds the method to the generic function.  Otherwise, is like the old
add method.


(defmethod foo ((x plane)) ...) ==>

(add-method (symbol-function 'foo)
            #'(method-lambda ((x plane)) ...))

  
Additionally, we propose a new macro called method-lambda which the user
can use when building methods which are going to be added to the default
kind of generic function.  Method-lambda provides a documented way for
the user to cons up methods which have the same kind of performance
optimizations defmethod has.

METHOD-LAMBDA specialized-lambda-list . body

returns a new method object.  the correspondence with make-method is:

(make-method '(plane) #'(lambda (p) p))  =

#'(method-lambda ((p plane)) p)

The only difference is that the method created with method-lambda may be
more efficient.

Given method-lambda, defmethod expands into something like:

(defmethod foo ((p plane)) ...)

(add-method (or (symbol-function 'foo)
                (make-generic-function))
            #'(method-lambda ((p plane)) ...))


Given method-lambda and generic-function-lambda We see no need to
include any of the variants of labels or flet we have been talking
about.  It is easy to implement any of them using method-lambda and
generic-function-lambda.

∂14-Nov-86  1816	RPG  	Remarks on Moon's Comments   
To:   common-lisp-object-system@SAIL.STANFORD.EDU    

On the :allocation options:

I thought we agreed to what was written.

On :instantiable:

Again, I thought we had agreed to what is in there. If we don't like
T as a default, we can name it :uninstantiable. `Abstract' is a word
I would prefer we not use because it seems like a word users would
want to use.

On DEFMETHOD updating:

Because we have not settled precisely what a method object is,
it is difficult to say whether DEFMETHOD should update or replace
with a copy the method object in a generic function. 

If GET-METHOD returns something that can be invoked, and if we decide
DEFMETHOD updates, then we'll need a copier for methods objects, otherwise
users will not be able to get a method out of a generic function and know
it will never be side-effected.  Possibly we should have a generic
function copier also.

			-rpg-

∂14-Nov-86  1906	Bobrow.pa@Xerox.COM 	Re: Altering Generic Functions    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Nov 86  19:05:58 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 NOV 86 18:17:32 PST
Date: 14 Nov 86 18:17 PST
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Altering Generic Functions   
In-reply-to: Danny Bobrow <Bobrow.pa>'s message of 14 Nov 86 13:52 PST
To: common-lisp-object-system@SAIL.STANFORD.EDU
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861114-181732-2842@Xerox>

Obvious typos in my previous message

  (slot-values slot-name1 slot-name2 ...)

should be

(slot-values object slot-name1 slot-name2 ...)

and 
(aspects-of-generic-function :key1, :key2 ...)

should be

(aspects-of-generic-function generic-function :key1, :key2 ...)


-- danny

∂14-Nov-86  1906	Bobrow.pa@Xerox.COM 	Re: Altering Things     
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Nov 86  19:06:23 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 NOV 86 18:59:37 PST
Date: 14 Nov 86 18:59 PST
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Altering Things    
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 14 Nov 86
 17:46 PST
To: RPG@SAIL.STANFORD.EDU
cc: common-lisp-object-system@SAIL.STANFORD.EDU
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861114-185937-2865@Xerox>

    Thinking of these facets as slots is quaint, in the same way
    that one can think of the `mantissa' and `exponent' as slots in a
    floating-point number. Of course, with meta-objects this can done.
    I say this is `quaint' because it is promulgating a misnomer of
    sorts, the misnomer of referring to the subparts of eveything as
    `slots.' 
Quaintness is not the issue, but there is a serious concern here.  It is
often useful to provide users an interface that makes it look as though
there is a "field" of some type in a data structure, because that is a
useful way to think.  For example, points may provide a rho, theta
"field" interface, even though the underlying implementation is x,y.
This is usually most useful when these facets can be changed
independently.

This emphaiszes the difference between the user view and the
implementation view, and it is as true of Smalltalk as it is of
CommonLoops.  Even with a single underlying implementation of classes,
they provide some pseudo field messages.  

So it is important for us to distinguish user and implementation
descriptions in our writeup.  Gregor had a comment in the code that wrt
the user view, generic-function acted as if it were defined by a
defclass (but ...).  Without the (but ...) it is a fine explanation,
especially if we put ACTED AS in capital letters.

I agree that we will recommend to X3J13 that they split DEFSTRUCT into
DEFCLASS and DEFRECORD.  Several people said they would send me their
versions of DEFRECORD so I could put them together for an initial
proposal.  Those of you who have them please do respond.  


-- danny

∂14-Nov-86  1906	Gregor.pa@Xerox.COM 	Meeting at X3J13   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Nov 86  19:06:15 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 NOV 86 18:58:37 PST
Date: 14 Nov 86 18:58 PST
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Meeting at X3J13
To: common-lisp-object-system@SAIL.STANFORD.EDU
cc: Gregor.pa@Xerox.COM, Bobrow.pa@Xerox.COM
Message-ID: <861114-185837-2864@Xerox>

I think that someone, in some message suggested that we all get together
at X3J13.  Danny and I both think that is a good idea.

We propose that we get together the evening of the first day at X3J13.

Comments?

∂14-Nov-86  1906	Bobrow.pa@Xerox.COM 	Re: Remarks on Moon's Comments    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Nov 86  19:06:09 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 NOV 86 18:52:41 PST
Date: 14 Nov 86 18:52 PST
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Remarks on Moon's Comments   
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 14 Nov 86
 18:16 PST
To: RPG@SAIL.STANFORD.EDU
cc: common-lisp-object-system@SAIL.STANFORD.EDU
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861114-185241-2858@Xerox>

    On :instantiable:

I prefer :uninstantiable too (I prefer Moon's default, but this name).
Perhaps because it is hard to spell, the feature should be called
:no-instances

COPIERS
I believe we need copiers for both generic-function objects and
method-objects.  These are necessary as long as these objects are not
immutable.  With these, and the facilities that Gregor and I talked
about
 (see Re: Second installment of comments on Functions chapter 14 Nov 86
17:21 PST)   
we can define GLABELS and other of my favorite perversities on top of
rather than within the standard (in a library so we get to try them).


-- danny

∂14-Nov-86  2030	Bobrow.pa@Xerox.COM 	Re: Meeting at X3J13    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Nov 86  20:30:46 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 NOV 86 19:07:28 PST
Date: 14 Nov 86 19:06 PST
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Meeting at X3J13
In-reply-to: Gregor Kiczales <Gregor.pa>'s message of 14 Nov 86 18:58
 PST
To: Gregor.pa@Xerox.COM
cc: common-lisp-object-system@SAIL.STANFORD.EDU, Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861114-190728-2901@Xerox>

To be more specific, we propose getting together at dinner and after on
Wednesday Decmember 10.  To be continued on Thursday  evening if
desired.


-- danny

∂14-Nov-86  2105	RPG  	Meeting at X3J13   
To:   common-lisp-object-system@SAIL.STANFORD.EDU    
It's possible for me, but I think that the function cell discussion
will be at the center this meeting.
			-rpg-

∂15-Nov-86  1213	kempf%hplabsc@hplabs.HP.COM 	Re: Meeting at X3J13 
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 15 Nov 86  12:13:40 PST
Received: from hplabsc by hplabs.HP.COM ; Sat, 15 Nov 86 12:12:25 pst
Received: by hplabsc ; Sat, 15 Nov 86 12:11:57 pst
Date: Sat, 15 Nov 86 12:11:57 pst
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8611152011.AA21017@hplabsc>
To: common-lisp-object-system@sail.stanford.edu
Subject: Re: Meeting at X3J13


I will be on vacation for Dec. and therefore will be unable to
attend. However, I'll find out who from HP is going to attend
and make sure they have the latest draft of the standard from
SAIL.

Incidently, I hope the problems encountered during the development
of PCL are presented to the X3J13 committee and that the committee
takes them seriously, even to the point of changing the current
informal standard to resolve ambiguities. The Lisp community has
nothing to lose and everything to gain by strengthening CL
as a portable language. It will certainly help the objects standard
effort.

	Jim Kempf	kempf@hplabs

∂15-Nov-86  1353	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: discussion wanted   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 15 Nov 86  13:53:17 PST
Received: from ti-csl by csnet-relay.csnet id af11375; 15 Nov 86 2:32 EST
Received: from Jenner (jenner.ARPA) by tilde id AA00515; Thu, 13 Nov 86 17:00:54 cst
To: hpfclp!robert@HPLABS.HP.COM
Cc: common-lisp-object-system@SU-AI.ARPA
Subject:        Re: discussion wanted
Date:           13-Nov-86 16:57:07
From: DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET
Message-Id:     <DUSSUD.2741295423@Jenner>

	   This standard is immense.  I am worried that even though the proposal is
	   going to be well thought out, its usability is threatened by its size.
	   As pointed out by practically the entire OOPSLA panel on learnability,
	   one of the major contributors to the learnability of an object oriented
	   language is simplicity.  Give them too many options and they balk or get
	   mired in details.  I am worried about our users.  I have to ask is all
	   this really necessary for the standard or is it just a good thing to
	   have on a rainy day?

There are several aspects related to the "size" of a standard.
First of all, a standard can be extensive without being complicated. You don' t 
have to learn about the whole thing before being able to use it. Common Lisp 
is a good example of such a standard. Only the first chapters of the book are 
essential. If someone does not care about hash tables, he can skip the chapter and 
go on. 

Another aspect is that size and usefulness are related. If a standard is too small,
it might fall short for lots of applications, and there would be a lot of non portable,
incompatible extensions. An example of this is the call-out mechanism for the stock 
hardware implementations of Common Lisp.

A third aspect of the size is: if a standard is large, its design phase is going to 
be long because there are more chances to be inconsistent or incorrect.

I think that these aspects, even if not formally discussed in the mail, were in our
minds when we started.   One of the tradeoffs we consider often is: do we want to 
add this feature at the user interface level or leave it buried in the underlying 
metaclass protocol. If we add the option at the user interface level, the standard 
is growing but the user can take advantage of it without bothering with 
meta objects, which are pretty esoteric for the programmer on the street.

I would consider the standard being extensive but I don't 
consider it complicated. One can start working with objects by using only 
DEFCLASS and  DEFMETHOD, the default values options produce 
reasonable results. Then one can refine his application when he is more 
familiar with the standard.

The first two aspects should be considered most important when deciding tradeoffs.
The third should be considered a result of the first two. We will have to review
the drafts carefully.

Patrick.



∂16-Nov-86  1020	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: Meeting at X3J13    
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 16 Nov 86  10:20:38 PST
Received: from ti-csl by csnet-relay.csnet id aa01862; 16 Nov 86 13:09 EST
Received: from Jenner (jenner.ARPA) by tilde id AA15065; Sun, 16 Nov 86 11:54:12 cst
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: common-lisp-object-system@SU-AI.ARPA
Subject:        Re: Meeting at X3J13
Date:           16-Nov-86 10:22:41
From: DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET
Message-Id:     <DUSSUD.2741530958@Jenner>


	   It's possible for me, but I think that the function cell discussion
	   will be at the center this meeting.
				   -rpg-


Dick,

I you think we will be too short on time, we could meet the day before (Tuesday)
at TI in Dallas, I can get a small conference room reserved and the assurance that
nobody will disturb us.

Patrick.

∂17-Nov-86  1100	Bobrow.pa@Xerox.COM 	Re: Meeting at X3J13    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Nov 86  11:00:02 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 17 NOV 86 09:28:14 PST
Date: 17 Nov 86 09:27 PST
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Meeting at X3J13
In-reply-to: DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET's message of 16 Nov
 86 10:22:41
To: DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET
cc: RPG@SU-AI.ARPA, common-lisp-object-system@SU-AI.ARPA
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861117-092814-3939@Xerox>

    	   It's possible for me, but I think that the function cell
    discussion 	   will be at the center this meeting.
 				   -rpg-


    Dick,

    I you think we will be too short on time, we could meet the day
    before (Tuesday) at TI in Dallas, I can get a small conference room
    reserved and the assurance that nobody will disturb us.

    Patrick.

I can't get there the day before.  I was hoing that we could have this
despite other business (not with the whole committee).  

-- danny

∂17-Nov-86  1807	Bobrow.pa@Xerox.COM 	Options of defclass
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Nov 86  18:07:20 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 17 NOV 86 14:34:22 PST
Date: 17 Nov 86 14:33 PST
Sender: Bobrow.pa@Xerox.COM
Subject: Options of defclass
To: Common-Lisp-Object-System@Sail.stanford.edu
cc: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861117-143422-434@Xerox>

BAD NAME
  :default-value is a bad name for this feature.  It leads a user to
believe that the value found in the class is used for initialization (or
worse, is found on access as in Loops).  I propose we rename this option
to be 
  :initform initial-value-form

OMISSION
  :type type-expression
should be allowed as it is in DEFSTRUCT.  No requirements on its use
should be in the standard.

EXTENSION
  :properties <any>
This allows users to attach their own properties to slots in a class.
It is uninterpreted by by the system.  This allows user extensions to
information about slots to be done in a portable way.  We found such
properties on slots to be most useful in Loops.  
  class-properties <class> <slot-name>
is a setf-able method that allows access to these properties.
An alternative name would be :user-data.

 

-- danny

∂17-Nov-86  1807	Gregor.pa@Xerox.COM 	change class protocol   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Nov 86  18:07:49 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 NOV 86 15:43:19 PST
Date: Mon, 17 Nov 86 15:39 PST
From: Gregor.pa@Xerox.COM
Subject: change class protocol
To: Common-Lisp-Object-System@Sail.stanford.edu
Message-ID: <861117153938.3.GREGOR@AVALON.isl.parc.xerox.com>
Line-fold: no


This message outlines the change-class protocol currently in PCL, and
some issues which need to be worked out.

Here is an example of using the change-class protocol currently in PCL:


(defclass position () ())

(defclass x-y-position (position)
  ((x 0)
   (y 0))
  (:accessor-prefix position-))

(defclass rho-theta-position (position)
  ((rho 0)
   (theta 0))
  (:accessor-prefix position-))

(defmethod change-class-internal ((old x-y-position)
				  (new rho-theta-position))
  ;; Copy the position information from old to new to make new
  ;; be a rho-theta-position at the same position as old.
  (let ((x (position-x old))
	(y (position-y old)))
    (setf (position-rho new) (atan y x)
	  (position-theta new) (sqrt (+ (* x x) (* y y))))))

(defmethod change-class-internal ((old rho-theta-position)
				  (new x-y-position))
  ...)


Now, the user can take an instance of the class x-y-position, like:

(setq p1 (make-instance 'x-y-position :x 2 :y 0))

and change it to an instance of the class rho-theta-position by saying:

(change-class p1 'rho-theta-position)

Note that the p1 instance itself will have its class changed.

To see how this works, here is the code for change-class:

(defun change-class (object new-class)
  (let* ((old-class (class-of object))
	 (new-object (make new-class)))
    ;; Call change-class-internal so that a user-defined method
    ;; (or the default method) can copy the information from the
    ;; old instance to the dummy instance of the new class.
    (change-class-internal object new-object)
    ;; Now that the dummy new-object has the right information,
    ;; move all that stuff into the old-instance.
    (setf (iwmc-class-class-wrapper object)
	  (wrapper-of new-class))
    (setf (iwmc-class-static-slots object)
	  (iwmc-class-static-slots new-object))
    (setf (iwmc-class-dynamic-slots object)
	  (iwmc-class-dynamic-slots new-object))
    object))

;;;
;;; The default implementation of change-class-internal just copies
;;; over all the slots, making new dynamic slots for slots that don't
;;; exist in the new class.
;;;
(defmeth change-class-internal ((old object) (new object))
  (let ((all-slots (all-slots old)))
    (iterate ((name in all-slots by cddr)
              (value in (cdr all-slots) by cddr))
      (put-slot-always new name value))))


Here are some issues which need to be resolved:

1. Is change-class a function or a generic-function?

Currently, it is a function.  This means that the change-class protocol
is "hardwired".  Should we make it a generic function so that the
protocol could be different for different meta-classes?  If we want that
functionality, we may want to do something like (with different names of
course).

(defun change-class (object new-class)
  (change-class-using-class (class-of object) new-class object))

(defmethod change-class-using-class ((old-class class)
				     (new-class class)
				     object)
  .. this does what the current change class does ..
  .. including call something like the current    ..
  .. change-class-internal                        ..
  )

A related issue is that we have to spec out how the programming
environment calls change-class.


2. Is this internal protocol appropriate?  I believe that it is
conceptually clear, but there is no doubt that it is not the most
efficient for all hardwares.  Is it possible to come up with a protocol
which is simple and allows the most efficient implementation across
hardwares?  Is it even possible to come up with a protocol which allows
the most efficient implementation across hardwares?
-------

∂17-Nov-86  1809	Gregor.pa@Xerox.COM 	portable interface to code walker 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Nov 86  18:08:05 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 NOV 86 16:10:52 PST
Date: Mon, 17 Nov 86 16:10 PST
From: Gregor.pa@Xerox.COM
Subject: portable interface to code walker
To: Common-Lisp-Object-System@Sail.stanford.edu
Message-ID: <861117161022.4.GREGOR@AVALON.isl.parc.xerox.com>
Line-fold: no


During the last discussion of with-slots, we agreed that we would
specify a portable, "programmatic" interface to the code walker which
people could use to write portable variants of with.  This message
contains a first stab at that.

WALK-VARIABLES form environment function

walks over form, doing macroexpansions etc.

Each time the walk encounters a symbol which is going to be evaluated,
it calls function with two arguments.  The first argument is the symbol.
The second argument is T if that symbol has been bound during the walk
to this place, nil otherwise.  Whatever function returns is used in
place of the symbol.


Each time the walk encounters a symbol which is going to be set, it
calls function with two arguments.  The first argument is a form like
(SETQ <symbol> <form>) the second argument is as described above.
Whatever function returns is used in place of the setq form.


This protocol seems to be sufficient for writing new kinds of
with-slots.  But somehow, it is tempting to define some sort of more
general walker so that people can use it for other things too.  Maybe it
would be enough to fix Common Lisp so that it is in fact possible to
write a truly portable code walker and then let people use that?
-------

∂18-Nov-86  0738	kempf%hplabsc@hplabs.HP.COM 	Re:  change class protocol
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 18 Nov 86  07:38:02 PST
Received: from hplabsc by hplabs.HP.COM ; Tue, 18 Nov 86 07:36:11 pst
Received: by hplabsc ; Tue, 18 Nov 86 07:35:38 pst
Date: Tue, 18 Nov 86 07:35:38 pst
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8611181535.AA17978@hplabsc>
To: Common-Lisp-Object-System@Sail.stanford.edu, Gregor.pa@Xerox.COM
Subject: Re:  change class protocol

I think that change-class would be most appropriate as a generic
function, to allow different metaclasses the option of implementing
their own protocol.
		Jim Kempf	kempf@hplabs

∂18-Nov-86  0804	kempf%hplabsc@hplabs.HP.COM 	Re:  portable interface to code walker   
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 18 Nov 86  07:57:20 PST
Received: from hplabsc by hplabs.HP.COM ; Tue, 18 Nov 86 07:55:58 pst
Received: by hplabsc ; Tue, 18 Nov 86 07:55:25 pst
Date: Tue, 18 Nov 86 07:55:25 pst
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8611181555.AA18071@hplabsc>
To: Common-Lisp-Object-System@Sail.stanford.edu, Gregor.pa@Xerox.COM
Subject: Re:  portable interface to code walker


>WALK-VARIABLES form environment function
>
>walks over form, doing macroexpansions etc.
>
>Each time the walk encounters a symbol which is going to be evaluated,
>it calls function with two arguments.  The first argument is the symbol.
>The second argument is T if that symbol has been bound during the walk
>to this place, nil otherwise.  Whatever function returns is used in
>place of the symbol.


I'm not quite sure what you mean by "evaluated". Do you mean
"evaluated in the context of the code walk?" Or "evaluated by
Common Lisp EVAL?" And what is "this place"? The symbol? Assuming
"yes" and that you mean "evaluated in the context of the code walk",
then this looks much like the LET-PSEUDO with which we've extended
Common Lisp (hidden from the user) to do something similar. The 
difference is that LET-PSEUDO is a sort of "symbol-macro" facility
which always does the substitution of a form for a symbol at
macroexpansion time, while WALK-VARIABLES would give the programmer
control over when to do the substitution.


>Each time the walk encounters a symbol which is going to be set, it
>calls function with two arguments.  The first argument is a form like
>(SETQ <symbol> <form>) the second argument is as described above.
>Whatever function returns is used in place of the setq form.

>
>This protocol seems to be sufficient for writing new kinds of
>with-slots.  But somehow, it is tempting to define some sort of more
>general walker so that people can use it for other things too.  Maybe it
>would be enough to fix Common Lisp so that it is in fact possible to
>write a truly portable code walker and then let people use that?


This latter point is the most important, I think. If the X3J committe
is receptive and the proposal is specific enough, hooks into Common Lisp
to allow people to do portable code walkers would certainly be more
desirable. In fact, the kind of thing WITH needs to have done is,
at some level, part of every compiler implementation. The portable hooks
would expose this functionality to embedded language developers,
in the same manner as macros do for developing s-expression oriented syntax.

		Jim Kempf	kempf@hplabs

∂18-Nov-86  1026	Gregor.pa@Xerox.COM 	Re:  change class protocol   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Nov 86  10:26:25 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 18 NOV 86 10:11:55 PST
Date: 18 Nov 86 10:11 PST
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re:  change class protocol
In-reply-to: Ken kahn <kahn.pa>'s message of 18 Nov 86 09:38 PST
To: kahn.pa@Xerox.COM
cc: kempf%hplabsc@hplabs.HP.COM,
 Common-Lisp-Object-System@Sail.stanford.edu, Gregor.pa@Xerox.COM
Message-ID: <861118-101155-1879@Xerox>

Yes, there is a bug in the code, it won't accept the name of a class.
But it is supposed to.  So the second argument to change-class can be
either a class or the name of a class.

∂18-Nov-86  1026	kahn.pa@Xerox.COM 	Re:  change class protocol
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Nov 86  10:26:20 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 18 NOV 86 09:38:31 PST
Date: 18 Nov 86 09:38 PST
Sender: kahn.pa@Xerox.COM
Subject: Re:  change class protocol
In-reply-to: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>'s message of Tue,
 18 Nov 86 07:35:38 pst
To: kempf%hplabsc@hplabs.HP.COM
cc: Common-Lisp-Object-System@Sail.stanford.edu, Gregor.pa@Xerox.COM
From: Ken kahn <kahn.pa@Xerox.COM>
Message-ID: <861118-093831-1834@Xerox>

I agree with Jim that there should be a change-class-using-class.

Also the example

(change-class p1 'rho-theta-position)

uses the name of a class instead of the class.  The code does things
like 
(wrapper-of new-class).  MAKE-INSTANCE accepts either a class or the
name of a class, why shouldn't that be the general rule.



----- ken

∂18-Nov-86  1710	kahn.pa@Xerox.COM 	Re: Second installment of comments on Functions chapter 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Nov 86  17:09:52 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 18 NOV 86 16:55:12 PST
Date: 18 Nov 86 16:55 PST
Sender: kahn.pa@Xerox.COM
Subject: Re: Second installment of comments on Functions chapter
In-reply-to: Gregor Kiczales <Gregor.pa>'s message of 14 Nov 86 17:21
 PST
To: Gregor.pa@Xerox.COM
cc: MOON%ML.AI.MIT.EDU@MC.LCS.MIT.EDU,
 Common-Lisp-Object-System@SU-AI.ARPA
From: Ken kahn <kahn.pa@Xerox.COM>
Message-ID: <861118-165512-2491@Xerox>

I like the method-lambda macro.  It should be noted that along with
generic-function-lambda that they can only sometimes be used where a
LAMBDA can be.
E.g. (funcall #'(method-lambda ...) ...) works while ((method-lambda
...) ...) doesn't.  Given that its unclear whether it would be better if
such macros expanded to (FUNCTION (LAMBDA ...)) so that one would write
(funcall (method-lambda ...) ...) instead.  For symmetry one could write
a LAMBDA macro that expanded into (FUNCTION (LAMBDA ...)). 

Maybe I'm being dense but I don't see how

    Given method-lambda and generic-function-lambda We see no need
    to include any of the variants of labels or flet we have been
    talking about.  It is easy to implement any of them using
    method-lambda and generic-function-lambda.

Would a GFLET, for example, expand to a FLET that used the CDR of the
expansion of a generic-function-lambda?


----- ken

∂21-Nov-86  2027	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Options of defclass    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Nov 86  20:27:43 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 7307; Fri 21-Nov-86 23:08:23 EST
Date: Fri, 21 Nov 86 23:08 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Options of defclass
To: Common-Lisp-Object-System@Sail.stanford.edu
In-Reply-To: <861117-143422-434@Xerox>
Message-ID: <861121230816.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 17 Nov 86 14:33 PST
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

    BAD NAME
      :default-value is a bad name for this feature.  It leads a user to
    believe that the value found in the class is used for initialization (or
    worse, is found on access as in Loops).  

Is the issue here to make it clear to the user that the argument to
:default-value is a form to be evaluated, not a constant object to be
stored directly into the slot?  In other words, is the problem with
the word "value" or with the word "default" or both?

    I propose we rename this option to be 
      :initform initial-value-form

I'm not too happy with this name, since it is not English.  Its only
virtue is that it is used in a few places (lambda-lists) in CLtL (but
not in the Common Lisp language itself, only in the description of the
language), so it isn't an entirely new piece of jargon.  On the other
hand, in another part of CLtL (defstruct) these are called default-inits
instead of init-forms, and in yet another part (defvar) they are called
initial-values.

I'm not too happy with the name :default-value either.  Anyone have
a better idea?

Remind me why we didn't like using = as the name of this slot-option.

    OMISSION
      :type type-expression
    should be allowed as it is in DEFSTRUCT.  No requirements on its use
    should be in the standard.

I don't see what use this could be, but I don't see how it could hurt,
other than by making the language larger.  Let's go ahead and put it in.

    EXTENSION
      :properties <any>
    This allows users to attach their own properties to slots in a class.
    It is uninterpreted by by the system.  This allows user extensions to
    information about slots to be done in a portable way.  We found such
    properties on slots to be most useful in Loops.  
      class-properties <class> <slot-name>
    is a setf-able method that allows access to these properties.
    An alternative name would be :user-data.

If I had suggested :properties you would have told me to do it with
meta-objects instead of cluttering up the syntax.  I don't think this
belongs here.

If we want to allow users to extend the syntax of defclass, rather than
making their own macro, we certainly should make the user-defined
extensions have a syntax consistent with the built-in features, rather
than requiring a prefix :properties on user-defined slot-options.  It's
always a mistake to draw lines between "the user" and "the system"; in
Lisp, things are built up in layers and one man's user is another man's
system.

∂21-Nov-86  2122	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Class precedence list, underconstrained method ordering   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Nov 86  21:22:22 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 7334; Sat 22-Nov-86 00:20:39 EST
Date: Sat, 22 Nov 86 00:20 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Class precedence list, underconstrained method ordering
To: Common-Lisp-Object-System@SU-AI.ARPA
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <860925145850.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <861122002029.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

I have been investigating the proposed extension described in mail included
below, using some tools I wrote for the purpose.  It turns out that the
proposed extension would signal an error for many quite legitimate looking
programs.  So far I have not thought of any weakened form of the proposed
extension that I would wish to propose for inclusion in the standard.

I found a few cases where the order of the methods really doesn't matter,
and I found a few cases that are really bugs in the programs I was
analyzing, but the preponderance of the cases I found are like this:

(defclass stuff (class-1 class-2) ())
(defclass class-1 (class-1-internal) ())
(defclass class-2 (class-2-internal) ())
(defmethod funk ((x class-1-internal) ...) ...)
(defmethod funk ((x class-2-internal) ...) ...)

where the programmer definitely expected the first method to shadow
the second method.  The problem here is that the local ordering rules
(rules 1 and 2 on p.1-14 of our draft document) do not specify any
constraint on the ordering of class-1-internal and class-2-internal.
Nevertheless, the programmer was clearly thinking that class-1-internal
is part of class-1, and class-2-internal is part of class-2, and
since class-1 goes before class-2 then class-1-internal must go before
class-2-internal.  This is faulty as logic but good as intuition.

The problem is this: programmers use component classes in two different
ways, and the language does not provide any way to record the programmer's
intent.  (1) The components of a class are its own business and the internal
structure of that class should not be affected by mixing it with other
classes.  (2) A class is a selection from a pool of available, publicly
known mixins, and the particular set selected is part of the interface of
that class.  I don't know whether it is worth adding to the language a way
for programmers to distinguish between these two uses of superclasses.  The
advantage would be that the class system would be able to tell a programmer
that he was breaking a class designed according to (1) by treating it
according to (2), i.e. mixing it with another class built from some of the
same superclasses.  I'll think about this more.

The reason these programs work, in spite of their apparently
underconstrained ordering, is that Flavors doesn't just follow local
ordering rules 1 and 2.  It also has a rule, whose importance I didn't fully
grasp until now, that when class-1 and class-2 are mixed together, all of
the components of class-1 must precede all of the components of class-2,
provided there are no intersections.  This is what rule 3 and the
tree-walking discussion on p.1-14 are both about.  We should have this
somewhat nonlocal rule in the Common Lisp object standard but I think we
need a more easily understood formulation of the rule than has yet been
offered.  What's in the draft document on p.1-14 is quite precise, but its
implication that class-1's components are guaranteed to precede class-2's
components is a little hard to grasp.

Also, the remark on p.1-15 about well-conceived programs needs to be
modified in light of the discovery (at least to me it's a discovery) that
relying only on the strictly local ordering rules isn't going to work in the
real world.  The (pie apple fruit cinnamon spice) ordering is guaranteed by
rule 3, but if you did (defclass humble-pie (pie spice fruit) ()), its
components would be (humble-pie pie apple cinnamon spice fruit), so if the
ordering of spice and fruit matters to the correct functioning of pie, and
pie is going to be used as a building-block, you should make that constraint
explicit.  Or if had a way for programmers to distinguish, the definers of
apple and cinnamon could declare that these were type (1) classes.  Either
way the attempt to define humble-pie would signal an error, saying that
fruit must precede spice.

I suspect this issue may be what some of Danny's class precedence
suggestions were really about, although he didn't phrase them this way.

    Date: Thu, 25 Sep 86 14:58 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	Date: 25 Sep 86 07:59 PDT
	From: Danny Bobrow <Bobrow.pa@Xerox.COM>

	The search I would be interested in is not the one where there are
	differences of order only, but ones in which a subclass has the classes
	in a different order than a super.  This could lead to strangeness for a
	user who tests an operation on a superclass, and finds then happening
	differently in a subclass.

    That is exactly what the New Flavors ordering rules, as compared with either
    breadth-first or depth-first search, are intended to avoid.  It might be that
    there are cases where they don't avoid this problem, but I'd have to see
    a specific example.  The proposed extension, which I kind of like but have
    neither implemented nor evaluated its effect on real programs, deals more
    stringently with this issue by examining all pairs of component classes whose
    order is unconstrained and determining whether exchanging them would alter
    any inherited methods; if not, their order doesn't matter, because it doesn't
    affect behavior.  If so, signal an error.  This extension would ensure that
    no matter which of the possible total orderings consistent with the partial
    ordering is chosen, the behavior is the same.

    Even though I like this idea (due to KMP originally I believe) I can't
    support putting it into a standard, since it hasn't been tried in the
    real world.


∂22-Nov-86  1048	RPG  	Options of Defclass
To:   common-lisp-object-system@SAIL.STANFORD.EDU    
``Remind me why we didn't like using = as the name of this slot-option.''

If you write

(defclass foo (baz) (ztesch :initable t = nil))

it looks funny. If you insist that the `=' appear immediately after the
slot name, you've possibly imposed unnecessary syntax and non-Lispiness on
the construct.

``      :type type-expression
    should be allowed as it is in DEFSTRUCT.  No requirements on its use
    should be in the standard.

I don't see what use this could be, but I don't see how it could hurt,''

Sometimes a compiler will be able to optimize things a little given some
information like this.  It might not be that the storage or its direct
handling will improve or change, but, perhaps, some other operation can be
slightly improved - such a being able to emit the machine addition
instruction with only overflow checking - when the slot, directly, is 
involved in an arithmetic expression.

``If I had suggested :properties you would have told me to do it with
meta-objects instead of cluttering up the syntax.  I don't think this
belongs here.''

I said this myself, but acceded.

			-rpg-

∂24-Nov-86  1810	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Meeting at X3J13   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 24 Nov 86  18:09:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 8973; Mon 24-Nov-86 21:07:42 EST
Date: Mon, 24 Nov 86 21:07 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Meeting at X3J13
To: common-lisp-object-system@SU-AI.ARPA
Message-ID: <861124210743.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

I'm not going to attend the Dallas X3J13 meeting.  This is partly
because I'm trying to cut down on travel, and partly because I have an
excessively low tolerance for exercises in futility.  I'll try to make
it to the next X3J13 meeting, especially if the object-oriented
programming standard is going to be discussed in a serious way at that
meeting.

As far as I know Sonya isn't going to Dallas either.  Thus I don't think
it will be possible to use Dallas for a face to face meeting of the whole
object-oriented programming working group.  I believe we can continue to
make progress over the network if we concentrate on the important issues.

∂25-Nov-86  1339	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: portable interface to code walker  
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Nov 86  13:38:44 PST
Received: from ti-csl by csnet-relay.csnet id at04601; 25 Nov 86 16:21 EST
Received: from Jenner (jenner.ARPA) by tilde id AA04661; Fri, 21 Nov 86 14:57:42 cst
To: Gregor.pa@XEROX.COM
Cc: Common-Lisp-Object-System@SU-AI.ARPA
Subject:        Re: portable interface to code walker
Date:           21-Nov-86 15:01:10
From: DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET
Message-Id:     <DUSSUD.2741979667@Jenner>


Gregor,

There might be problems with a code walker that figures out substitutions
for symbols after macroexpanding forms.

Consider this example:
(with object 
  (pushnew item l)				;l is a slot of object.	
....)

Well, (pushnew item l) will expand into
	(if (member item l)
	    l
	    (setq l (cons item l)))

The fact that l is referred to twice is a problem. 
It is so because PUSHNEW optimized the general expression
(let ((tmp l) (tmp1 item))
  (if (member item tmp)
      tmp
      (setf l (cons tmp1 tmp))))
based on the fact that l and item are symbols.

Those assumptions would be wrong if the symbol is substituted after the macroexpansion.

Something like Jim Kempf was suggesting would be more appropriate.

Macroexpand would try to substitute symbols based on the macroexpand environment 
set up by a special form like SYMBOL-LET.

(with object 
  (pushnew item l)
  .....)

could expand into 

 (SYMBOL-LET ((l (l object)))
   (pushnew item l)
   ....)

PUSHNEW would macroexpand L and ITEM and produce:

(let ((tmp (l object)))
  (if (member item tmp)
      tmp 
      (setf (l object) (cons item tmp))))
  


Patrick.

∂25-Nov-86  1445	Gregor.pa@Xerox.COM 	:accessor-prefix questions   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 25 Nov 86  14:44:47 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 25 NOV 86 13:25:29 PST
Date: 25 Nov 86 13:23 PST
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: :accessor-prefix questions
To: Common-Lisp-Object-System@Sail.Stanford.edu
cc: Gregor.pa@Xerox.COM
Message-ID: <861125-132529-2940@Xerox>

I have some questions about the :accessor-prefix option to defclass (all
of these questions also apply to :reader-prefix).  

1. Is there a special way to tell :accessor-prefix to make the names of
the accessors just be the names of the slots?  In other words, is there
a special flag which says, don't call symbol-name or intern at all.

Assuming the answer is yes, and the special flag is NIL, the following
behavior would result:

(defclass foo ()                    (defclass foo ()
  (tv:x                               (tv:x
   tv:y                                tv:y
   a                                   a
   b)                                  b)
  (:accessor-prefix "")               (:accessor-prefix nil)) 

Would define methods on the         Would define methods on the
generic functions:                  generic functions:
X, Y, A and B                       TV:X, TV:Y, A and B


1a. If there is such a special flag, what is it?  NIL, "" something
else?

2. Whether there is or isn't such a special flag, what do we do in the
following case:

(defclass foo ()
  (tv:x
   si:x)
  (:accessor-prefix foo-))

3. Do we really want to allow strings as an argument to
:accessor-prefix?  Is it enough to just allow symbols?

4. Should we allow a second argument to :accessor-prefix which would be
the package to intern the generated names in.


Obviously, for each of these questions there will be cases where the
programmers could use the extra power provided.  For each question, how
do we reconcile our answer with simplicity in understanding the behavior
of defclass?

My current set of answers is:

1. No special flag to say don't call intern.  People can use :accessor
for this case.
1a. doesn't apply

2. defclass must signal an error when it defines two accessors with the
same name which access different slots.

3. Allowing strings is OK, but not necessary.  People who want
lower-case characters in the print names of the symbols generated could
deal with having to type |foo-| quite easily I think.

4. A package argument to :accessor-prefix is not necessary given the
existence of :accessor, but it might be a good idea to have it anyways.
I remember discussions about having a package argument to :conc-name,
but I forget what the issues were.

∂26-Nov-86  0819	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: portable interface to code walker  
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 26 Nov 86  08:16:22 PST
Received: from ti-csl by csnet-relay.csnet id aa13185; 26 Nov 86 10:39 EST
Received: from Jenner (jenner.ARPA) by tilde id AA01612; Wed, 26 Nov 86 07:59:18 cst
To: Gregor.pa@XEROX.COM
Cc: Common-Lisp-Object-System@SU-AI.ARPA
Subject:        Re: portable interface to code walker
Date:           26-Nov-86 07:59:21
From: DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET
Message-Id:     <DUSSUD.2742386358@Jenner>


Gregor,

There might be problems with a code walker that figures out substitutions
for symbols after macroexpanding forms.

Consider this example:
(with object 
  (pushnew item l)				;l is a slot of object.	
....)

Well, (pushnew item l) will expand into
	(if (member item l)
	    l
	    (setq l (cons item l)))

The fact that l is referred to twice is a problem. 
It is so because PUSHNEW optimized the general expression
(let ((tmp l) (tmp1 item))
  (if (member item tmp)
      tmp
      (setf l (cons tmp1 tmp))))
based on the fact that l and item are symbols.

Those assumptions would be wrong if the symbol is substituted after the macroexpansion.

Something like Jim Kempf was suggesting would be more appropriate.

Macroexpand would try to substitute symbols based on the macroexpand environment 
set up by a special form like SYMBOL-LET.

(with object 
  (pushnew item l)
  .....)

could expand into 

 (SYMBOL-LET ((l (l object)))
   (pushnew item l)
   ....)

PUSHNEW would macroexpand L and ITEM and produce:

(let ((tmp (l object)))
  (if (member item tmp)
      tmp 
      (setf (l object) (cons item tmp))))
  


Patrick.

∂26-Nov-86  0857	Bobrow.pa@Xerox.COM 	Re: :accessor-prefix questions    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Nov 86  08:57:36 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 NOV 86 08:50:01 PST
Date: 26 Nov 86 08:50 PST
Sender: Bobrow.pa@Xerox.COM
Subject: Re: :accessor-prefix questions
In-reply-to: Gregor Kiczales <Gregor.pa>'s message of 25 Nov 86 13:23
 PST
To: Gregor.pa@Xerox.COM
cc: Common-Lisp-Object-System@Sail.Stanford.edu
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861126-085001-3808@Xerox>

    My current set of answers is:

    1. No special flag to say don't call intern.  People can use
    :accessor for this case. 1a. doesn't apply
I agree.

    2. defclass must signal an error when it defines two accessors
    with the same name which access different slots.
I agree

    3. Allowing strings is OK, but not necessary.  People who want
    lower-case characters in the print names of the symbols generated
    could deal with having to type |foo-| quite easily I think.
I don't agree.  If there is no special flag, then allowing strings or
symbols is no cost.  The symbol NIL doesn't mean no prefix.  Only the
string "" does.

    4. A package argument to :accessor-prefix is not necessary
    given the existence of :accessor, but it might be a good idea to
    have it anyways. I remember discussions about having a package
    argument to :conc-name, but I forget what the issues were.
I don't agree.  In this unusual case, either  use the :accessor option,
or do explicit defmethods in the desired package.


-- danny

∂26-Nov-86  0910	Bobrow.pa@Xerox.COM 	"Do it using the meta-object protocol" 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Nov 86  09:09:22 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 NOV 86 09:08:28 PST
Date: 26 Nov 86 09:05 PST
Sender: Bobrow.pa@Xerox.COM
Subject: "Do it using the meta-object protocol"
To: Common-Lisp-Object-System@Sail.Stanford.edu
cc: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861126-090828-3847@Xerox>

Moon says:
    If I had suggested :properties you would have told me to do it
    with meta-objects instead of cluttering up the syntax.  I don't
    think this belongs here.
Since I believe this argument and was about to make it for two more
"feature" that have been in the writeup for a while, I guess I give in.

The two features I use that argument for are from method combination:
:method-arguments
:interface

I know they have been useful in complex combination forms in Flavors,
but can be implemented, if really necessary, in the methods that compute
the code for the method combination by a specialized class.


-- danny

∂26-Nov-86  0913	Bobrow.pa@Xerox.COM 	Re: Options of defclass 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Nov 86  09:13:16 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 NOV 86 09:13:12 PST
Date: 26 Nov 86 09:13 PST
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Options of defclass
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Fri, 21 Nov 86 23:08 EST
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: Common-Lisp-Object-System@Sail.stanford.edu
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861126-091312-3868@Xerox>

Moon says:
  I'm not too happy with this name [:initform], since it is not
  English...I'm not too happy with the name :default-value either. 

Would you prefer the longer :initialize-with, :initialization-form or
perhaps :default-value-form.  Maybe :default-form would work. My problem
with :default-value is that Loops had them -- and they were values not
forms to evaluate.


-- danny

∂28-Nov-86  1609	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: portable interface to code walker 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Nov 86  16:09:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 11089; Fri 28-Nov-86 18:54:42 EST
Date: Fri, 28 Nov 86 18:54 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: portable interface to code walker
To: Common-Lisp-Object-System@Sail.stanford.edu
In-Reply-To: <DUSSUD.2742386358@Jenner>,
             <8611181555.AA18071@hplabsc>,
             <861117161022.4.GREGOR@AVALON.isl.parc.xerox.com>
Message-ID: <861128185424.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

I prefer Jim Kempf's suggestion that the documented interface be in
terms of a macro over Gregor Kiczales' suggestion that the documented
interface be in terms of a code-walking function.  The implementation of
the macro can use a code walker or any other technique appropriate to
the particular implementatation.  Documenting just the macro is more
abstract and leaves more freedom to the implementation, without any
decrease in power as far as I can see.  It also makes the documentation
a lot simpler, since as Gregor noted there is the temptation to include
an elaborate code-walking facility.

I've thought about Patrick Dussud's argument that the substitution for
symbols should not be done simply by expanding all macros and then
substituting, and I believe it.  If it were safe to assume that reading
a slot cannot have side effects, then the issue would be only one of
efficiency, not correctness.  I don't think that assumption is safe,
however, since reading a slot can invoke a method, and the method might
implement so-called "active values."  Thus I believe it is necessary for
the expansion of macros inside with-slots to be aware that the lexical
environment defines the meanings of the slot names, i.e. for the
macroexpansion and substitution to be done in one pass instead of two.

The names let-pseudo and symbol-let don't appeal to me; somehow they
don't seem to convey the semantics clearly.  Symbolics Common Lisp has
something similar, called "symbol-macros", so the name "symbol-macrolet"
is my suggestion.  This conveys the idea that it is similar to macrolet
but substitutes for symbols rather than for macro invoking lists.

∂28-Nov-86  1619	Moon@STONY-BROOK.SCRC.Symbolics.COM 	:accessor-prefix questions  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Nov 86  16:18:59 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 11096; Fri 28-Nov-86 19:17:15 EST
Date: Fri, 28 Nov 86 19:16 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: :accessor-prefix questions
To: Common-Lisp-Object-System@SU-AI.ARPA
In-Reply-To: <[ML.AI.MIT.EDU].1835.861113.MOON>,
             <861125-132529-2940@Xerox>,
             <861126-085001-3808@Xerox>
Message-ID: <861128191658.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 13 Nov 86 01:40:21 EST
    From: "David A. Moon" <MOON%ML.AI.MIT.EDU@MC.LCS.MIT.EDU>

    With :accessor-prefix and :reader-prefix, how does one specify that the
    accessor name is to be the same as the slot name?  A prefix of "" won't
    work, since that re-interns the accessor name in the current package.  Do
    we need two more options for this?  Should we treat the symbol NIL as a
    special case?  I think two more options would be more tasteful.

I still think additional options would be more tasteful than treating
NIL, or anything else, as a special case.

Executive summary: I think issues 2, 3, and 4 are clear; issue 1 requires
more discussion before making a decision.

    Date: 25 Nov 86 13:23 PST
    From: Gregor Kiczales <Gregor.pa@Xerox.COM>

    I have some questions about the :accessor-prefix option to defclass (all
    of these questions also apply to :reader-prefix).  

    1. Is there a special way to tell :accessor-prefix to make the names of
    the accessors just be the names of the slots?  In other words, is there
    a special flag which says, don't call symbol-name or intern at all.

    Assuming the answer is yes, and the special flag is NIL, the following
    behavior would result:

    (defclass foo ()                    (defclass foo ()
      (tv:x                               (tv:x
       tv:y                                tv:y
       a                                   a
       b)                                  b)
      (:accessor-prefix "")               (:accessor-prefix nil)) 

    Would define methods on the         Would define methods on the
    generic functions:                  generic functions:
    X, Y, A and B                       TV:X, TV:Y, A and B


    1a. If there is such a special flag, what is it?  NIL, "" something
    else?

    My current set of answers is:

    1. No special flag to say don't call intern.  People can use :accessor
    for this case.
    1a. doesn't apply

    Date: 26 Nov 86 08:50 PST
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

    I agree.

I am surprised, since I thought you were an advocate of the accessors
having the same names as the slots.  If you aren't, we should hear from
someone who advocates that position before making it difficult to do.  I
assume that an advocate of that position would not want to have to write
(foo :accessor foo) for every slot and would not be happy with the
accessor having almost the same name as the slot, but in a different
package.

By the way, advocates of that position are necessarily opposed to
combining the function cell and value cell, right?

    [Gregor again]
    2. Whether there is or isn't such a special flag, what do we do in the
    following case:

    (defclass foo ()
      (tv:x
       si:x)
      (:accessor-prefix foo-))

    2. defclass must signal an error when it defines two accessors with the
    same name which access different slots.

    [Danny again]

    I agree

So do I.

    [Gregor again]
    3. Do we really want to allow strings as an argument to
    :accessor-prefix?  Is it enough to just allow symbols?

    3. Allowing strings is OK, but not necessary.  People who want
    lower-case characters in the print names of the symbols generated could
    deal with having to type |foo-| quite easily I think.

    [Danny again]
    I don't agree.  If there is no special flag, then allowing strings or
    symbols is no cost.  The symbol NIL doesn't mean no prefix.  Only the
    string "" does.

I shamefacedly admit that I never realized that allowing strings would
introduce a problem with alphabetic case.  Consider the plight of people
who write their source code in lower case; they would have to upper-case
the string.  Danny notwithstanding, I think this makes it clear that strings
should not be allowed here.  Even the null string should have to be written
|| rather than "".

    [Gregor again]
    4. Should we allow a second argument to :accessor-prefix which would be
    the package to intern the generated names in.

    4. A package argument to :accessor-prefix is not necessary given the
    existence of :accessor, but it might be a good idea to have it anyways.
    I remember discussions about having a package argument to :conc-name,
    but I forget what the issues were.

    [Danny again]
    I don't agree.  In this unusual case, either  use the :accessor option,
    or do explicit defmethods in the desired package.

I agree with Danny, the package argument is unnecessary complexity.

∂30-Nov-86  1238	Masinter.pa@Xerox.COM 	Re: :accessor-prefix questions  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Nov 86  12:38:22 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 30 NOV 86 12:38:21 PST
Date: 30 Nov 86 12:38 PST
From: Masinter.pa@Xerox.COM
Subject: Re: :accessor-prefix questions
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Fri, 28 Nov 86 19:16 EST
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: Common-Lisp-Object-System@SU-AI.ARPA
Message-ID: <861130-123821-5477@Xerox>

"... I am surprised, since I thought you were an advocate of the
accessors
having the same names as the slots.  If you aren't, we should hear from
someone who advocates that position before making it difficult to do.  "

I want to advocate a requirement, but the requirement isn't exactly as
stated. The  requirement is that the packages of the accessors depend
only upon information explicitly available within the defining form once
the defining form has been read. With current DEFSTRUCT, the package of
generated accessors depends on the value of *package* at the time the
DEFSTRUCT is evaluated, rather than at the time the DEFSTRUCT is read.
However, for every other definitional form in Common Lisp, the only
dependence on *package* (and other read-environment variables such as
*read-base*) is only on the value at read time.


This requirement can be satisfied either by making the accessor names
the same as the slot names, or by making the accessor names be interned
into the *same* package as the slots.

This is required, for example, in residential environments where the
time of evaluation of a definitional form might be different than the
time that form was READ. It is good programming language design to keep
to a minimum the amount that the semantics of a given form depends upon
the dynamic environment and to separate out syntactic features from
semantic ones; *package* describes a syntactic feature rather than a
semantic one.





∂30-Nov-86  1402	Gregor.pa@Xerox.COM 	Re: :accessor-prefix questions    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Nov 86  14:02:02 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 30 NOV 86 14:02:02 PST
Date: 30 Nov 86 14:01 PST
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: :accessor-prefix questions
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Fri, 28 Nov 86 19:16 EST
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: Common-Lisp-Object-System@SU-AI.ARPA
Message-ID: <861130-140202-5512@Xerox>

This message answers David Moon's comments about :accessor-prefix and
has some changes to my original position on these questions.

The major point of this message is that we could use "" as a special
flag to :accessor-prefix to mean don't re-intern the symbols, just use
the symbol which names the slot as the accessor.

Question # 1 was:
Should there be a special flag to say don't call intern.  Previously, I
had said that I thought we did not need such a flag.  But as you point
out,

    Date: Fri, 28 Nov 86 19:16 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    (this was actually to Danny, but Danny and I were advocating
     the same position)
    I am surprised, since I thought you were an advocate of the
    accessors having the same names as the slots.  If you aren't, we
    should hear from someone who advocates that position before making
    it difficult to do.

I had missed the point that not having such a flag would make it
difficult to have accessors have the same names as slots.  I now realize
that a flag like this is necessary.


Question # 3 was:

Do we want to allow strings as an argument to :accessor-prefix?  Is it
enough to just allow symbols?

    I shamefacedly admit that I never realized that allowing
    strings would introduce a problem with alphabetic case.  Consider
    the plight of people who write their source code in lower case;
    they would have to upper-case the string.  Danny notwithstanding, I
    think this makes it clear that strings should not be allowed here. 
    Even the null string should have to be written || rather than "".

Good, that means that we can outlaw strings here.  Given that we do need
some mechanism for specifying that the accessors should just be symbols
which name the slots, I propose that we use "" as a special argument to
:accessor-prefix and :reader-prefix to have this meaning.  I agree that
this is a little hackish, but I would rather do that than introduce two
whole new options for this purpose.


Question #4 was:
Should we allow a second argument to :accessor-prefix which would be the
package to intern the generated names in.

Previously, I said this might be a good idea.  Danny said it would not,
and Moon agreed with Danny by saying:

    I agree with Danny, the package argument is unnecessary
    complexity.

Since then I remembered previous discussions about adding such a package
argument to :conc-name and remembered the problems why it would be a bad
idea.  Specifically, having an explicit package argument would make
changing the in-package statement for a file not affect the accessors
created by defclass.  It would mean that moving a program to another
package would require a lot more than just editing a few in-package
statements.  So I now think that an explicit package argument is an
extremely bad idea. 

∂30-Nov-86  1737	Gregor.pa@Xerox.COM 	Re: portable interface to code walker  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Nov 86  17:37:42 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 30 NOV 86 17:35:51 PST
Date: 30 Nov 86 17:35 PST
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: portable interface to code walker
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Fri, 28 Nov 86 18:54 EST
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: Common-Lisp-Object-System@Sail.stanford.edu
Message-ID: <861130-173551-1018@Xerox>

I have been thinking about Patrick's message for some time.  I don't
believe the argument he is presenting about symbol-macros.

    Date: 21 Nov 86 15:01:10
    From: DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET
    
    (note: I have edited the example Patrick gave slightly, to
    correct simple problems like not using gensyms where
    appropriate and not using the correct syntax for with-slots)
    
    There might be problems with a code walker that figures out
    substitutions for symbols after macroexpanding forms.

    Consider this example:
      (with-slots  (object)
        (pushnew item l)				;l is a slot of object.	
        ....)
    
    Well, (pushnew item l) will expand into
    
    	(if (member item l)
    	    l
    	    (setq l (cons item l)))
    
    The fact that l is referred to twice is a problem. 
    It is because PUSHNEW optimized the general expression
    
    (let ((#:g0001 l)
          (#:g0002 item))
      (if (member #:g0002 #:g0001)
          #:g0001
          (setf l (cons #:g0002 #:g0001))))
    
    based on the fact that l and item are symbols.
    
    Those assumptions would be wrong if the symbol is substituted
    after the macroexpansion.

    Date: Fri, 28 Nov 86 18:54 EST
    From: David A. Moon

    I've thought about Patrick Dussud's argument that the
    substitution for symbols should not be done simply by expanding all
    macros and then substituting, and I believe it.  If it were safe to
    assume that reading a slot cannot have side effects, then the issue
    would be only one of efficiency, not correctness.  I don't think
    that assumption is safe, however, since reading a slot can invoke a
    method, and the method might implement so-called "active values." 
    Thus I believe it is necessary for the expansion of macros inside
    with-slots to be aware that the lexical environment defines the
    meanings of the slot names, i.e. for the macroexpansion and
    substitution to be done in one pass instead of two.

When you say "If it were safe to assume that reading a slot cannot have
side effects, then the issue would be only one of efficiency, not
correctness", you touch on the source of my disagreement with the
argument you and Patrick are presenting.

Basically, I think that it is bad design for the implementor of a macro
to blurr efficiency and correctness this way.  In particular, I believe
it is bad design for a macro to expand differently based on whether or
not evaluating some of its argumenst can have side effects.  I believe
that:

  (pushnew <item> <list>)

Should expand to:

    (let ((#:g0001 <list>)
          (#:g0002 <item>))
      (if (member #:g0002 #:g0001)
          #:g0001
          (setf <list> (cons #:g0002 #:g0001))))

or, maybe (setf <list> (adjoin <item> <list>))

regardless of the value of <item> and <list>.  It is the job of the
compiler, not the pushnew macro, to perform transformations on this code
which preserve semantics but improve efficiency.

This may sound like naive folly, but look at the consequences of
implementing macros the way you and Patrick suggest using the very
change that you and Patrick are proposing we make to the language.

Any macro which does optimizations like the one Patrick presents is
going to have to be changed in order to add with-slots to the language.
Either these macros will have to be changed to respect symbol macros as
you and Patrick suggest, or they will have to be changed to expand the
way I suggest so that a simple code walker can be used to implement
with-slots.

The fact that adding with-slots to the language breaks macros which do
the kind of side-effect analysis in Patrick's example seems to me to be
convincing evidence that is a questionable style, but there are other
reasons to question it.  What does writing macros that way really buy
you?  The macro can only do the most simple kinds of side-effect
analysis,  it certainly can't do anywhere near as good a job as the
compiler;  especially if the macro is intended to be portable.

The change you are proposing we make entrenches this bad style.  It will
require implementors and users to edit each of their macros which does
the kind of optimization Patrick presents to respect symbol macros.

The change I am proposing is that we declare that macros should expand
without attempting to do any kind of optimizations based on side-effect
analysis.  (Specifically that with-slot may be implemented in terms of a
simple code-walker).  This will require editing the exact same set of
macros as the change you propose, but I believe it is a better solution
because:

 1. It is more elegant.  As I have said, I think it is bad style to
    for macros do do optimizations based on side-effect analysis.

 2. It is a simpler change to the language.  Adding symbol macros to
    the language as you suggest is a large and no doubt controversial
    change.

 3. People can start fixing their code right away.  We can say right
    now, getting the X3J13 committee to agree of course, that it is
    bad style to implement macros which try to do this kind of side
    effect analysis.  Users and implementors can start fixing their
    code right away, they don't need to wait until we spec out symbol
    macros and get them added to the language, and all the
    implementations.

∂30-Nov-86  1759	Gregor.pa@Xerox.COM 	initialization protocol strawman  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Nov 86  17:59:48 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 30 NOV 86 17:59:50 PST
Date: 30 Nov 86 17:57 PST
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: initialization protocol strawman
To: Common-Lisp-Object-System@Sail.Stanford.edu
cc: Gregor.pa@Xerox.COM
Message-ID: <861130-175950-1032@Xerox>

Here is an initialization protocol proposal for people to shoot at.  The
major characteristic of this protocol is its simplicity.  This protocol
does not have support for automatic processing of make-instance keyword
arguments, this means that options like :initable-slots, :init-keywords
and :default-init-plist are not present in this proposal.  Later in this
message I discuss why I think those are not needed.

make-instance <class> &rest <options>           [generic function]

make instance is a generic function which has two "standard defined"
methods.  Those methods look like:

(defmethod make-instance ((class-name symbol) &rest options)
  (apply 'make-instance (class-named class-name) options))

(defmethod make-instance ((class class) &rest options)
  (let ((instance (make-instance-internal class)))
    .. code to initialize the slots from  ..
    .. the initforms (or whatever) in the ..
    .. defclass form                      ..
    (apply 'initialize instance options)
    instance))


initialize <instance> &rest <options>           [generic-function]

initialize is also a generic function, it has one "standard defined"
method.  That method looks like:

;;
;; Notice the little idiom in the argument list here.  You aren't
;; allowed to say &allow-other-keys unless you have said &key, but
;; you don't want to add some new keyword like :ignore or something.
;; So you say (&key allow-other-keys &allow-other-keys)
;;
(defmethod initialize ((o object) &key allow-other-keys
&allow-other-keys)
  (declare (ignore allow-other-keys))
  o)


So, make-instance can be used with a class which is an instance of class
or a subclass of class to make instances and call initialize as shown.

Initialize receives the newly created instance with its slots
initialized to the values supplied in the initforms given in the
defclass.  Initialize can process the keywords and values it receives to
change the values of some of these slots, initialize slots whose values
were not specified in the defclass form, or do any other required
initialization.

In order for all initialize methods to have congruent lambda lists, they
must all have a required first argument, then possibly an &rest
argument, then keyword arguments.  They must all specify
&allow-other-keys.  The following are examples of legal initialize
methods:

(defmethod initialize ((b boat) &key speed
                                &allow-other-keys)
  ..)

(defmethod initialize ((b boat) &key allow-other-keys
                                &allow-other-keys)
  (declare (ignore allow-other-keys))
  (register b))

(defmethod initialize ((b boat) &rest options
                                &key speed
                                &allow-other-keys)
  ..)


 
Why is :initable-slots not needed?

Initable-slots provides the user with an automatic mechanism for
initializing the values of some of the slots from keyword-value pairs
supplied to make instance rather than the initforms in the defclass.

This is convenient in some cases, but it ends up with a multiplicity of
functionality which is not really needed, and which ends up being
complicated.  Specifically, it means that when the user calls
make-instance, the value of the slots of the instance can come from one
of 4 places:
  the initform in the defclass
  a keyword-value pair in the call to make-instance
  a keyword-value pair in the :default-init-plist
  the user-defined initialize method
   
It is easy enough for the definer of a particular class to define an
initialize method which will take care of initializing slot values from
the &rest argument to make-instance that I see no need for the automatic
mechanism provided by :initable-slots.


:init-keywords is not needed because it is just an accessory to
:initable-slots


Why is :default-init-plist not needed?
If we have :around (or whopper) methods in the standard, as we plan to,
users can implement a similar behavior themselves.

∂30-Nov-86  2126	LGD  	new functions.* files on SAIL
To:   common-lisp-object-system@SAIL.STANFORD.EDU    

I have placed our new versions of the Functions section out on [CLS,LSP].
Files are functi.tex, functi.dvi, etc.  There is a version with stripped
down fonts, symfun.dvi, to placate Symbolics' printers.

This part of the spec incorporates the results of our recent discussions
here on the west coast and our understanding of recent exchanges on this
mailing list.

Linda

∂01-Dec-86  1100	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: :accessor-prefix questions   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 86  11:00:49 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12120; Mon 1-Dec-86 13:58:26 EST
Date: Mon, 1 Dec 86 13:58 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: :accessor-prefix questions
To: Common-Lisp-Object-System@SU-AI.ARPA
In-Reply-To: <861130-123821-5477@Xerox>
Message-ID: <861201135811.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 30 Nov 86 12:38 PST
    From: Masinter.pa@Xerox.COM

    I want to advocate a requirement, but the requirement isn't exactly as
    stated. The  requirement is that the packages of the accessors depend
    only upon information explicitly available within the defining form once
    the defining form has been read. With current DEFSTRUCT, the package of
    generated accessors depends on the value of *package* at the time the
    DEFSTRUCT is evaluated, rather than at the time the DEFSTRUCT is read.
    However, for every other definitional form in Common Lisp, the only
    dependence on *package* (and other read-environment variables such as
    *read-base*) is only on the value at read time.


    This requirement can be satisfied either by making the accessor names
    the same as the slot names, or by making the accessor names be interned
    into the *same* package as the slots.

The latter was tried and found not to work.  In retrospect it should have
been obvious.  What if you have a slot named STRING?  The accessor, say
FOO-STRING, can't go into the LISP package, because either it's exported from
LISP and thus causes all symbols named FOO-STRING unexpectedly to share with
each other, or it isn't exported from LISP and so the program that defined
it can't get at it.

The only way that I know of that works, assuming no changes to the package
feature as Common Lisp currently defines it, is for

  (defclass foo () (string) (:accessor-prefix foo-))

to be defined to be equivalent to

  (defclass foo () ((string :accessor foo-string)))

at the level of printed representations (rather than objects).

    This is required, for example, in residential environments where the
    time of evaluation of a definitional form might be different than the
    time that form was READ. 

I don't see how residential environments and file-based environments are
any different in this respect.  All this means is that when you evaluate
something from program source, you have to evaluate it in the proper
context in which the program author put it.  Maybe you didn't realize until
now that *package* is one of the variables that defines that context, but
surely it is easy to add.

			     It is good programming language design to keep
    to a minimum the amount that the semantics of a given form depends upon
    the dynamic environment and to separate out syntactic features from
    semantic ones; *package* describes a syntactic feature rather than a
    semantic one.

I agree with your comment on good programming language design, and I think
this reflects poorly on the design of Common Lisp packages.  That shouldn't
be a surprise to anyone.  In Common Lisp, *package* really is somewhat of
a semantic feature; it's not only syntactic.

∂01-Dec-86  1136	edsel!bhopal!jonl@navajo.stanford.edu 	:accessor-prefix questions
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 86  11:36:19 PST
Received: by navajo.stanford.edu; Mon, 1 Dec 86 11:34:00 PST
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
	id AA03993; Mon, 1 Dec 86 11:28:56 pst
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
	id AA02053; Mon, 1 Dec 86 11:25:13 PST
Date: Mon, 1 Dec 86 11:25:13 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8612011925.AA02053@bhopal.edsel.uucp>
To: navajo!Gregor.pa%Xerox.COM@navajo.stanford.edu
Cc: navajo!Common-Lisp-Object-System%SU-AI.ARPA@navajo.stanford.edu
In-Reply-To: Gregor Kiczales's message of 30 Nov 86 14:01 PST
Subject: :accessor-prefix questions


While I agree with your analysis about the inadvisibility of adding a 
package argument to :conc-name, there is still an outstanding unsolved 
problem (summed up yesterday by Masinter).

Namely, if the time of creation of the accessor symbols isn't the same as 
the time of reading in the defining form, and the slot names, then how can 
you insure that the accessors are "accessible from the same package" as was 
current at read time?  Unfortunately, Larry's suggestion
   This requirement can be satisfied . . . by making the accessor names be 
   interned into the *same* package as the slots.
makes the very common error of assuming that a symbol is "interned" in
only one package ("THE *same* package").  If that were true, then one 
would only have to find out what package the slot names are "interned" in  
to find out what second argument to give to INTERN when constucting the 
accessor symbols.

To illustrate the difficulty: Let FOO be "homed" in package BAR; also let 
FOO be present and external in packages BAZ and BLETCH, both of which are
"used" by package CLASS-WORLD.  Then some file which is IN-PACKAGE'd into 
CLASS-WORLD will inherit (at read time!) the slot name FOO from BAZ and/or 
BLETCH, *** neither of which is found in the symbol-package cell of FOO ***.
Furthermore, because of the possibility of shadowing, and of differing 
inheritance links, it is entirely possible that even if <prefix>-FOO is 
entered into the BAR package (the one in which FOO is "homed"), it will 
still not be accessible when the current package is CLASS-WORLD.  This would 
certainly be counter to the intent of binding the package information in at 
read time rather than at macro-expansion time.

Can Larry's requirement be met?  Should it be?  I think it can if a package 
"slot" is  maintained -- not one which the user could arbitrarily specify, 
but one which reflects the "read time" binding of *package*.


-- JonL --

∂01-Dec-86  1326	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: portable interface to code walker 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 86  13:26:16 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12339; Mon 1-Dec-86 16:20:04 EST
Date: Mon, 1 Dec 86 16:19 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: portable interface to code walker
To: Common-Lisp-Object-System@Sail.stanford.edu
In-Reply-To: <861130-173551-1018@Xerox>
Message-ID: <861201161950.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sun, 30 Nov 86 20:35 EST
    From: Gregor Kiczales <Gregor.pa@Xerox>
    
    I have been thinking about Patrick's message for some time.  I don't
    believe the argument he is presenting about symbol-macros.
    ....
    The change I am proposing is that we declare that macros should expand
    without attempting to do any kind of optimizations based on side-effect
    analysis.

I could give a long answer but I think a short one would be better.  I don't
think is really an issue of optimizations.  How do you propose that the
macro invocation (pushnew item (aref array (incf i))) should expand?

(If I've missed the point of what you're trying to say, please let me know.)

∂01-Dec-86  1613	Gregor.pa@Xerox.COM 	Re: portable interface to code walker  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 1 Dec 86  16:13:33 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 01 DEC 86 15:55:58 PST
Date: 1 Dec 86 15:55 PST
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: portable interface to code walker
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Mon, 1 Dec 86 16:19 EST
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: Common-Lisp-Object-System@Sail.stanford.edu
Message-ID: <861201-155558-2029@Xerox>

    Date: Mon, 1 Dec 86 16:19 EST
    From: David A. Moon

    I could give a long answer but I think a short one would be
    better.  I don't think is really an issue of optimizations.  How do
    you propose that the macro invocation:
       (pushnew item (aref array (incf i)))
    should expand?

(let ((#:g01 item)
      (#:g02 array)
      (#:g03 (incf i)))
  (aset (adjoin #:g01 (aref #:g02 #:g03)) #:g02 #:g03)))

Which seems to me to be the simplest way it could possibly expand.  The
pushnew just assumes that evaluating the arguments to the <place> form
has side-effects so it makes certain to only evaluate them once.  The
same way it assumes that evaluating the <item> form has side-effects and
only evaluates it once.

    (If I've missed the point of what you're trying to say, please
    let me know.)

I think you may have, but maybe the answer to your above question
clarifies it.  Basically, my general point is that macros and compiler
optimizers should be kept separate.  In this specific case, because some
macro definitions (pushnew in Patrick's example) try to optimize their
expansion based on side-effect analysis they will have to be re-written
to work with with-slots.

This is not to say that the implementation of a macro must not consider
the possibilityt of side effects.  Of course it must to implement its
semantics properly.  Its just that macros should leave optimization to
the compiler.

∂01-Dec-86  1850	Bobrow.pa@Xerox.COM 	Re: Class precedence list, underconstrained method ordering
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 1 Dec 86  18:50:43 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 01 DEC 86 18:50:29 PST
Date: 1 Dec 86 18:50 PST
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Class precedence list, underconstrained method ordering
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Sat, 22 Nov 86 00:20 EST
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: Common-Lisp-Object-System@SU-AI.ARPA,
 KMP@STONY-BROOK.SCRC.Symbolics.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861201-185029-2210@Xerox>


    I suspect this issue may be what some of Danny's class
    precedence suggestions were really about, although he didn't phrase
    them this way.
Yes, I was trying to avoid underconstraint.  To restate the rules I
think are appropriate, they are (slightly edited from my message of 20
October):

The class precedence list is a left to right, depth first linearization
of the transitive closure of inheritance from the local super classes of
a class.  It satisfies three constraints:

C-1) A class appears only once on the list.
C-2) The order of classes in a local supers list is preserved
C-3) A class always precedes all classes in its local supers list

It can be thought of as constructed as follows:
       1) Walk the inheritance tree in left to right depth
        first order, recording all super classes in the order visited.

        2) Remove duplicates, preserving the last occurrence
          of any class. This can be combined with step 1
          without extra consing.  This ensures that C-1 is satisfied.
In
          most cases C-2 and C-3 will also be satisfied.  This is true
for
          all the examples in the Concepts document.

        3) Traverse the resulting list from left to right. If
        for any class c1, there is a class to its right that c1 should
        follow, move c1 to the right of the rightmost such class.
        This righmost class must be computed by recursive application of
        rules C-2 and C-3.  In computing this recursive dependency,
        a dependency loop may be discovered, indicating an error.

This algorithm gives a well defined order in which all internal
superclasses of class-1 will precede all internal superclasses of
class-2 if there is no intersection.  I propose we substitute the above
description for the one currently in CONCEP.  

I don't think we want to deal with the following more global case.

(DEFCLASS american-apple-pie (apple pie))
(DEFCLASS french-apple-pie (pie apple))

I take it that this is what Moon's humble pie example is about.

Examples:

No intersection

    (DEFCLASS1 C1 ())
    (DEFCLASS1 C2 ())
    (DEFCLASS1 D1 (C1))
    (DEFCLASS1 D2 (C2))
    (DEFCLASS1 E1 (D1 D2))
After Steps 1 and 2
(E1 D1 C1 D2 C2)

Simple Intersection:
    (DEFCLASS1 C1 (OBJECT))
    (DEFCLASS1 C2 (OBJECT))
    (DEFCLASS1 D1 (C1))
    (DEFCLASS1 D2 (C2))
    (DEFCLASS1 E1 (D1 D2))
After Steps 1 and 2
(E1 D1 C1 D2 C2 OBJECT)

Moving Required:
    (DEFCLASS1 C1 ())
    (DEFCLASS1 C2 ())
    (DEFCLASS1 C3 ())
    (DEFCLASS1 D1 (C1 C2))
    (DEFCLASS1 D2 (C1 C3))
    (DEFCLASS1 E1 (D1 D2))
After Steps 1 and 2
(E1 D1 C2 D2 C1 C3)
In step 3, C2 must be moved after C1.
resulting in
(E1 D1 D2 C1 C2 C3)

Simple Error:

    (DEFCLASS1 C2 ())
    (DEFCLASS1 C3 ())
    (DEFCLASS1 D4 (C3 C2))
    (DEFCLASS1 D5 (C2))
    (DEFCLASS1 D6 (C3 C2 D5 D4))


After steps 1 and 2:

(D6 D5 D4 C3 C2) 

Now D5 needs to after C2 from D6 defintion.  Computing the recursive
closure of the constraints on D5, we see that C2 must be after D4 from
D4, and D4 must be after D5 from D6!!! Error.  

Complex Constraint

    (DEFCLASS1 E1 (C1))
    (DEFCLASS1 E2 (C2))
    (DEFCLASS1 E3 (C3))
    (DEFCLASS1 E4 (E3 E2 E1))
    (DEFCLASS1 E5 (C1 C2))
    (DEFCLASS1 E6 (C2 C3))
    (DEFCLASS1 E7 (E5 E6 E4))

After Steps 1 and 2

(E7 E5 E6 E4 E3 C3 E2 C2 E1 C1)
In Step 3
  C3 has to be after C2 from E6, and hence after C1 from E5, giving
(E7 E5 E6 E4 E3 E2 C2 E1 C1 C3)
Now C2 is next in the list and it moves past C1 from E5, giving
(E7 E5 E6 E4 E3 E2 E1 C1 C2 C3).










-- danny

∂02-Dec-86  1316	DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET 	Re: portable interface to code walker  
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 2 Dec 86  13:16:46 PST
Received: from ti-csl by csnet-relay.csnet id bk26924; 2 Dec 86 15:26 EST
Received: from Jenner (jenner.ARPA) by tilde id AA08409; Tue, 2 Dec 86 08:16:09 cst
To: David A Moon <Moon@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp-Object-System@SU-AI.ARPA
Subject:        Re: portable interface to code walker
Date:           2-Dec-86 08:23:05
From: DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET
Message-Id:     <DUSSUD.2742906182@Jenner>


	 The names let-pseudo and symbol-let don't appeal to me; somehow they
	 don't seem to convey the semantics clearly.  Symbolics Common Lisp has
	 something similar, called "symbol-macros", so the name "symbol-macrolet"
	 is my suggestion.  This conveys the idea that it is similar to macrolet
	 but substitutes for symbols rather than for macro invoking lists.


I don't have any problem with the name "symbol-macrolet".

Do you want to propose symbol-macros (If I understand correctly, it is 
a global version of symbol-macrolet) along with symbol-macrolet as an
extension to Common Lisp?

Patrick.

∂02-Dec-86  1338	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: portable interface to code walker 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 2 Dec 86  13:36:16 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 13648; Tue 2-Dec-86 16:33:24 EST
Date: Tue, 2 Dec 86 16:33 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: portable interface to code walker
To: DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET
cc: Common-Lisp-Object-System@SU-AI.ARPA
In-Reply-To: <DUSSUD.2742906182@Jenner>
Message-ID: <861202163307.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date:           2-Dec-86 08:23:05
    From: DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET


	     The names let-pseudo and symbol-let don't appeal to me; somehow they
	     don't seem to convey the semantics clearly.  Symbolics Common Lisp has
	     something similar, called "symbol-macros", so the name "symbol-macrolet"
	     is my suggestion.  This conveys the idea that it is similar to macrolet
	     but substitutes for symbols rather than for macro invoking lists.


    I don't have any problem with the name "symbol-macrolet".

    Do you want to propose symbol-macros (If I understand correctly, it is 
    a global version of symbol-macrolet) along with symbol-macrolet as an
    extension to Common Lisp?

I do not.  Symbol-macrolet can be implemented by a code-walker, with no
changes to the interpreter and compiler, but define-symbol-macro has
to be implemented directly, since Common Lisp doesn't provide a way for
the user to supply a function that walks over every piece of code everywhere.
Define-symbol-macro is also less useful.

∂02-Dec-86  1631	Gregor.pa@Xerox.COM 	code for compute-class-precedence-list 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 86  16:28:18 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 DEC 86 16:12:05 PST
Date: Tue, 2 Dec 86 16:11 PST
From: Gregor.pa@Xerox.COM
Subject: code for compute-class-precedence-list
To: Common-Lisp-Object-System@Sail.Stanford.edu
Message-ID: <861202161119.4.GREGOR@AVALON.isl.parc.xerox.com>
Line-fold: no


Here is the code and some examples for the latest version of
compute-class-precedence-list as described by Danny yesterday.

At the end are some examples.

(DEFMACRO DEFCLASS1 (NAME SUPERCLASSES)
  `(progn (setf (get ',name 'supers) ',superclasses)))

(defun compute-class-precedence-list (root)
  (let ((cpl ())
	(must-precede-alist ()))
    ;; We start by computing two values.
    ;;   CPL
    ;;     The depth-first left-to-right up to joins walk of the supers tree.
    ;;   MUST-PRECEDE-ALIST
    ;;     An alist of the must-precede relations. The car of each element of the
    ;;;    must-precede-alist is a class, the cdr is all the classes which must
    ;;     precede that class in the CPL.
    ;;
    ;; Note that the actual walk is breadth-first, right-to-left.
    ;;
    (labels ((walk-supers (class &optional precedence)
	       (let ((elem (assoc class must-precede-alist)))
		 (if elem
		     (setf (cdr elem) (union (cdr elem) precedence))
		     (push (cons class precedence) must-precede-alist)))
	       (let* ((rsupers (reverse (cons class (get class 'supers))))
		      (precedence (cdr rsupers)))
		 (do ((sup rsupers (cdr sup))
		      (pre precedence (cdr pre)))
		     ((null pre))
		   (walk-supers (car sup) pre)))
	       (unless (member class cpl) (push class cpl)))
	     (must-move-p (element list &aux move)
	       (dolist (must-precede (cdr (assoc element must-precede-alist)))
		 (when (setq move (member must-precede (cdr list)))
		   (return move))))
	     (find-farthest-move (element move)
	       (let ((closure (compute-must-precedes-closure element)))
		 (dolist (must-precede closure)
		   (setq move (or (member must-precede move) move)))
		 move))
	     (compute-must-precedes-closure (class)
	       (let ((closure ()))
		 (labels ((walk (element path)
			    (when (member element path)
			      (class-ordering-error
				root element path must-precede-alist))
			    (dolist (precede (cdr (assoc element must-precede-alist)))
			      (pushnew precede closure)
			      (walk precede (cons element path)))))
		   (walk class nil)
		   closure))))
      (walk-supers root)			;Do the walk
      ;; For each class in the cpl, make sure that there are no classes after it which
      ;; should be before it.  We do this by cdring down the list, making sure that for
      ;; each element of the list, none of its must-precedes come after it in the list.
      ;; If we find one, we use the transitive closure of the must-precedes (using
      ;; find-farthest-move) to see where the class must really be moved. We use a
      ;; hand-coded loop so that we can splice things in and out of the CPL as we go.
      (let ((tail cpl)
	    (element nil)
	    (move nil))
	(loop (when (null tail) (return))
	      (setq element (car tail)
		    move (must-move-p element tail))
	      (cond (move
		     (setq move (find-farthest-move element move))
		     (setf (cdr move) (cons element (cdr move)))
		     (setf (car tail) (cadr tail));OK to use Interlisp delete trick since it
		     (setf (cdr tail) (cddr tail));will never be the last element of the list.
		     )
		    (t
		     (setq tail (cdr tail)))))
	(copy-list cpl)))))

(defun class-ordering-error (root element path must-precede-alist)
  (declare (ignore root))
  (setq path (cons element (reverse (member element (reverse path)))))
  (let ((explanations ()))
    (do ((tail path (cdr tail)))
	((null (cdr tail)))
      (let ((after (cadr tail))
	    (before (car tail)))
	(if (member after (get before 'supers))
	    (push (format nil "~% ~A must precede ~A -- ~A is in the local supers of ~A."
			  before after after before)
		  explanations)
	    (dolist (common-precede (intersection
				      (cdr (assoc after must-precede-alist))
				      (cdr (assoc before must-precede-alist))))
	      (when (member after (member before (get common-precede 'supers)))
		(push (format nil "~% ~A must precede ~A -- ~A has local supers ~S."
			      before after
			      common-precede
			      (get common-precede 'supers))
		      explanations))))))
    (error "While computing the class-precedence-list for the class ~A:~%~
             There is a circular constraint through the classes:~{ ~A~}.~%~
             This arises because:~{~A~}"
	   root path (reverse explanations))))



;;;; Examples
(defclass1 o ())
(defclass1 b1 (o))
(defclass1 b2 (o))
(defclass1 b3 (o))
(defclass1 b4 (o))
(defclass1 ex1-1 (b1 b3 b4))
(defclass1 ex1-2 (b2 b3))
(defclass1 example-1 (ex1-1 ex1-2))

(equal (compute-class-precedence-list 'example-1)
       '(EXAMPLE-1 EX1-1 B1 EX1-2 B2 B3 B4 O))

(defclass1 o ())
(defclass1 b1 (o))
(defclass1 b2 (o))
(defclass1 b3 (o))
(defclass1 ex2-1 (b1))
(defclass1 ex2-2 (b2))
(defclass1 ex2-3 (b3))
(defclass1 example-2 (ex2-1 ex2-2 ex2-3))

(equal (compute-class-precedence-list 'example-2)
       '(EXAMPLE-2 EX2-1 b1 EX2-2 b2 EX2-3 b3 O))


(DEFCLASS1 C1 ())
(DEFCLASS1 C2 ())
(DEFCLASS1 C3 ())
(DEFCLASS1 C4 (C1 C2))
(DEFCLASS1 C5 (C3 C2))
(DEFCLASS1 C6 (C4 C5))

(equal (compute-class-precedence-list 'c6)
       '(C6 C4 C1 C5 C3 C2))

(DEFCLASS1 E1 (c1))
(DEFCLASS1 E2 (c2))
(DEFCLASS1 E3 (c3))
(DEFCLASS1 E4 (E3 E2 E1))
(DEFCLASS1 E5 (c1 c2))
(DEFCLASS1 E6 (c2 c3))
(DEFCLASS1 E7 (E5 E6 E4))

(equal (compute-class-precedence-list 'e7)
       '(e7 e5 e6 e4 e3 e2 e1 c1 c2 c3))


(defclass1 d0 ())
(defclass1 d1 ())
(defclass1 d2 ())
(defclass1 d3 ())
(defclass1 e (d0 d1))
(defclass1 f (d1 d2 d3))
(defclass1 g (d1 d2))
(defclass1 h (d0))
(defclass1 foo (e f g h))

(equal (compute-class-precedence-list 'foo)
       '(foo e f g h d0 d1 d2 d3))


(DEFCLASS1 D1 ())
(DEFCLASS1 D2 ())
(DEFCLASS1 D3 ())
(DEFCLASS1 D4 (D3 D2))
(DEFCLASS1 D5 (D2))
(DEFCLASS1 D6 (D3 D2 D5 D4))

(COMPUTE-CLASS-PRECEDENCE-LIST 'D6)		;should error



(defclass1 g1 ())
(defclass1 g2 ())
(defclass1 g3 ())
(defclass1 g4 ())
(defclass1 g5 (g1 g2))
(defclass1 g6 (g2 g3))
(defclass1 g7 (g3 g4))
(defclass1 g8 (g4 g5 g6 g7))

(compute-class-precedence-list 'g8)		;should error
-------

∂02-Dec-86  1921	Bobrow.pa@Xerox.COM 	Re: :accessor-prefix questions    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 86  19:21:28 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 02 DEC 86 18:38:48 PST
Date: 2 Dec 86 18:39 PST
Sender: Bobrow.pa@Xerox.COM
Subject: Re: :accessor-prefix questions
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Fri, 28 Nov 86 19:16 EST
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: Common-Lisp-Object-System@SU-AI.ARPA
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861202-183848-3396@Xerox>

        With :accessor-prefix and :reader-prefix, how does one
        specify that the accessor name is to be the same as the slot
        name?  A prefix of "" won't work, since that re-interns the
        accessor name in the current package.  Do we need two more
        options for this?  Should we treat the symbol NIL as a special
        case?  I think two more options would be more tasteful.

    I still think additional options would be more tasteful than
    treating NIL, or anything else, as a special case.

I prefer allowing either:
 (:accessor-prefix)  with no prefix specified
or
  :accessor-prefix  with no parens
to mean use the same symbol for the accessor as for the slot-name.  I
find the first more "mnemonic" but could be argued out of it.

    I shamefacedly admit that I never realized that allowing
    strings would introduce a problem with alphabetic case.  Consider
    the plight of people who write their source code in lower case;
    they would have to upper-case the string.  Danny notwithstanding, I
    think this makes it clear that strings should not be allowed here. 
    Even the null string should have to be written || rather than "".
With this new realization, I agree.  But with the option specified
above, || would mean to reintern in the current package.

With this, I think an appropriate summary of the current allowed syntax
is:
(:accessor-prefix {symbol})
(:reader-prefix  {symbol})
where if symbol is omitted, no new interning is done. 

-- danny

∂03-Dec-86  2126	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Comments on the revised function chapter   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Dec 86  21:25:41 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 14942; Thu 4-Dec-86 00:24:01 EST
Date: Thu, 4 Dec 86 00:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Comments on the revised function chapter
To: Common-Lisp-Object-System@SU-AI.ARPA
Message-ID: <861204002343.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

These comments apply to the draft dated Nov 30, 1986 21:10.

The chapter title still calls it a user interface, even though what it
is actually documenting is a programmer interface.

The introduction section needs to be written (right now it only contains
one sentence).  It should explain how the functions described in this
chapter fit into the overall scheme of things, including the relation
between the basic programmer interface and the meta-objects.

The functions ARGUMENT-PRECEDENCE-ORDER, GENERIC-FUNCTION-LAMBDA-LIST,
GENERIC-FUNCTION-METHOD-COMBINATION-TYPE, and LAMBDA-LIST-SPECIALIZERS are
unnecessary and should be removed.  Perhaps they are really part of the
meta-object interface, but they aren't useful by themselves.

ADD-METHOD, DOCUMENTATION, GENERIC-FUNCTION-LAMBDA-LIST,
GENERIC-FUNCTION-METHOD-COMBINATION-TYPE, GET-METHOD, and REMOVE-METHOD
accept an argument that can be "a generic function or a symbol that names a
generic function."  I thought we agreed in October that these functions
would also accept a list (SETF symbol) as a name of a setf generic
function.  Looking back through the mail, I see Gregor agreeing on 21
Oct, Bobrow agreeing on 20 Oct, and me proposing it on 17 Oct.  I didn't
see any other discussion; did I miss some mail?

The new term "method combination identifiers" was introduced for what
we used to call "method qualifiers" without any discussion.  I'm not sure
and it's an improvement and I think there ought to be some discussion.

I don't like the presentation of options with a bullet followed by a
sentence containing somewhere the option name.  People want the option
name to be first, and exdented to the left margin, so they can easily
find the description of an option.  Also, the textual description of
options often refers to the arguments of an option with italicized words,
but these arguments are not defined locally; you have to go back to the
syntax section to find them.  This is particularly bad in defclass, because
its writeup is so big.  The previous version, which repeated the syntax
pattern of an option as a header on its textual description, was better.

Why do we have make-generic-function, make-instance, and make-method, but
no make-class?


Comments on specific functions:

ADD-METHOD:

Typo: 2nd para under arguments says "or with the lambda" when it means
"and with the lambda".

Typo: "argument specializers" should be "parameter specializers."

The values description is awkward.  There has to be a simpler way to
phrase such a simple concept as side-effecting an object passed as
an argument and returning the same object.

Add-method was changed to signal an error if an equivalent method already
exists, instead of replacing it.  There doesn't appear to be a way any more
to replace a method.  I also don't see a way to update the definition of a
method while keeping the same method object.  In the absence of such
facilities it's not very useful to document add-method.

CALL-NEXT-METHOD:

Typo: "may to be used" in 6th para under purpose.

Typo: first sentence in remarks is missing a comma before "affects".
This sentence would be clearer if it was amplified by adding a second
sentence: "Call-next-method passes the current method's original arguments
along to the next method."  This was already said under purpose, so what
we are really seeing here is the bad effect of the decision to split the
presentation of information arbitrarily among "purpose", "arguments", and
"remarks" sections.  In many cases this document is unnecessarily difficult
to read because sentences that should be in the same paragraph have been
moved into separate sections.  I assume this can be improved in future drafts.

Inconsistent language: we say it "is used", "may be used", is "called from",
is "done in", and is "called with".  The verb "used" seems the most
appropriate and should be used consistently.

CHANGE-CLASS:

Typo: first sentence says "the new class" when it means "a new class".

This seems to imply that the second argument is not allowed to be the
name of a class.  Why not?

The remarks should clarify that not all objects will allow change-class.
For example, an implementation is not required to support change-class on
any built-in object.  (I don't think implementations should be prohibited
from supporting it; some built-in classes in some implementations might be
implemented using the Class system rather than being implemented in a
primitive way.)

In Menlo Park we discussed restrictions on when change-class could be
called.  They belong here.  My notes from that meeting indicate that we
agreed on the general idea of the restrictions, but couldn't come up with a
good way of explaining it in the meeting, and said we should work on that
over the mail.  The general idea was that if execution is inside of a
context in which the class of an object is declared lexically, e.g. inside
a method or inside a with-slots, then changing the class of that object
leaves the activation record of that context in "a wierd state", because of
early binding by compilers.  The exact details of what "a wierd state"
means weren't worked out; one idea is that it is illegal to access a slot
of the object in that context after its class has been changed.  When a
particular generic function invocation invokes multiple methods because of
method combination or because of call-next-method, all methods after the
one that changed the class are in "a wierd state"; this is necessary
because changing the class of an argument can change the set of available
methods, but implementations need to be free to bind that set at generic
dispatch time.  In Flavors we have a more specific description of what the
user can rely on which might serve as a model.

DEFCLASS:

Clarification: Last sentence under Purpose should make it clear that
the object can be directly an instance of the new class or can be
directly an instance of a subclass of the new class.  It's important
to be explicit since people tend to get confused easily on this point.

slot-name is not defined in the syntax figure.

We have not agreed on the name :initform yet; this needs discussion.

Something called :initialize-only was added without discussion.  This
seems to be unnecessary and should be removed, although I'll be happy
to listen to reasons why it is useful and should stay if there are
some.

The :dynamic and :none allocation-types are hacks and should be removed.
In Menlo Park we spent a long time talking about the weirdness of
dynamic allocation, and my conclusion from that is that it doesn't
belong in the standard.  I have no problems with :instance and :class
allocation.

The option :uninstantiable, formerly :instantiable, formerly :abstract is
of the same category as :required-flavors and does not belong in the
standard if the criterion is to omit merely protocol-enforcing options.  It
should be removed (a good thing, since we still haven't found a decent
name for it!).

In the syntax for boa-arglists, supplied-p parameters should be allowed
since they can be used in initforms of later parameters.  The description
of defstruct b.o.a. constructors in CLtL is too vague, but seems to imply
that supplied-p parameters are disallowed.  CLtL doesn't allow &key and
&allow-other-keys in boa-arglists, but of course it should.  They should
be allowed in defclass unless someone can present a good argument against
them.  We have found them useful.

Under arguments, 2nd para, I don't think the remark about built-in classes
belongs here.

Typo: "the a generic" under :reader.

The description of :allocation :instance slot-option refers to storing the
variable in the class instance.  To me this sounds the same as :allocation
:class.  In general, when the terms "class object" and "class instance" are
thrown around it's very difficult to keep track of which is which.

Typo: "slot (storage)" under :allocation :class.

You forgot to say whether the :initialize-only and :type slot-options can
be given more than once.

Typo: "on generic function" under :accessor-prefix and :reader-prefix.

The vague word "processed" is used in the description of :accessor-prefix
and :reader-prefix.  Use a more specific word.  Do you mean evaluated or
macro-expanded?  When compiling, do you mean compile time or load time?
I could go with either.

Some of the details of :accessor-prefix and :reader-prefix, especially
how you get it to use the slot names as the accessor names, are still
under discussion and what's in the document may change.

I couldn't think of a more confusing way to describe the :metaclass option
than the way it's described here.  Maybe the concept is inherently
confusing, but I think we could do better.  One suggestion is always and
consistently to use the word "metaclass" to refer to a class that is the
class of a class, and reserve the word "class" entirely for the set of
classes that are not metaclasses.

Remarks section: on redefining classes: I assume it is not permitted to
redefine a built-in class.  Why is the temporary copy of class object
created when it is redefined given a name at all?  Since when are we
redefining the Common Lisp EQUAL function?  The fourth bullet would be
less confusing if it were rephrased in the singular.

The remark about slots that have not been initialized was weakened from the
previous version.  You went too far; as written this would prohibit all
implementations from signalling an error when an uninitialized slot is
referenced, because legal programs could read the slot and discard its
value.  Like it or not, we have to say "is an error" here.

The last sentence under remarks implies that the :allocation slot-option
can only be used in one slot-description in a defclass.  This is not
what you meant to say!  I would break this into two sentences:  "No other
class option may appear more than once in a single defclass form.  No
other slot-option may appear more than once in a single slot-description."

The relationship between accessors (methods created with :accessor, :reader,
:accessor-prefix, and :reader-prefix) and regular methods (created with
defmethod) needs to be discussed.  One issue is how they combine, e.g.
(defmethod-setf foo-slot :after ((object foo)) (new-value) ...).
Another is what happens if you define a conflicting regular method, e.g.
(defmethod-setf foo-slot ((object foo)) (new-value) ...) when
(defclass foo () ((slot :accessor foo-slot))) has been done.

DEFGENERIC-OPTIONS:

I still think this choice of name reflects a fundamental misunderstanding,
but it won't be the first poorly chosen name in Common Lisp so I suppose
we can live with it if we have to.  Having gotten that bit of steam off
my chest I can go on to substantive comments.

:argument-precedence-order should be changed back to the way it was in
the previous version.  These positional numbers don't add any expressive
power and do add new ways to mess up.

declare option: the optimize declaration seems to have gotten lost in
editing.  I would expect this to be the most useful declaration in most
implementations, except for very simple ones that won't do anything with
the advice because they have only one form of generic dispatching.  The
reference to the FTYPE declaration doesn't make any sense; probably it is a
typo for TYPE declarations of parameters.  If FTYPE was really intended,
I'm confused and some explanation and an example should be added.

DEFGENERIC-OPTIONS-SETF:

Typo: The second sentence under purpose says "generic-function-name" but
should say "name" to be consistent with the rest of the page.

The last sentence under arguments, about the setf-lambda-list, isn't really
true since no variables are getting bound here.  The variable name is
really just documentation.  I'd say this text was accidentally copied from
defmethod-setf, except that it doesn't appear there.  Move it to there.

DEFMETHOD:

What happens if "name" currently names a non-generic function?  For consistency
with defgeneric-options, defmethod should signal an error.

In the second para under purpose, the list of attributes for creating a
generic function is somewhat garbled.  G.f.'s don't have parameter specializers.
Lambda-list and method-combination need to be mentioned.

In the last line under syntax, I would prefer (QUOTE datum) rather than 'datum.
Being explicit is always a good idea.

Typo: under arguments, "arguments, have t" should be "arguments have t".

The value returned by defmethod was changed from a method object, in the
previous version, to a rather hokey list.  This was not discussed over the
mail unless I missed some mail.  I think this should be changed back.

DEFMETHOD-SETF:

Typo: an asterisk in the syntax for specialized-setf-lambda-list
should be a right parenthesis.

Typo: The phrase "stuff?]" mysteriously appears under arguments.

I still don't like returning a hokey list instead of an object as the value.

DESCRIBE:

One method is enough, change "classes t and object" to "class t".

DOCUMENTATION:

In the first sentence under purpose, why does it say "class object"
but not "method object"?  This is very confusing.

Why is documentation said to be generic?  Are users supposed to write
methods for it?

I'm grossed out by the schizophrenia between documentation of symbols
and documentation of objects.  Saying that if the first argument is
not a symbol, the second argument must be unsupplied would help a
little.  It's still going to add new inconsistencies to Common Lisp;
consider that (DOCUMENTATION (SYMBOL-FUNCTION foo)) will work if
foo is the name of a generic function, but not if foo is the name of
a regular function.  I would prefer for DOCUMENTATION to be left the
way it is, as an operation on names rather than an operation on objects.
If I do (SETF (SYMBOL-FUNCTION 'BAR) (SYMBOL-FUNCTION 'FOO)), do
occurrences of the string FOO in examples in the documentation
automatically get changed to BAR?  I assume the reason someone is
proposing to change documentation to be object-oriented is because
Common Lisp is defective and doesn't have any names for methods, because
only symbols can be used as names.  We could fix that.

GET-METHOD:

What happens if you ask for a default method when the symbol given as
the first argument names a non-generic function?  Does it signal an error
or return a method object representing that function?  The former would
seem to be more consistent with some other functions in this version of
the spec.

I've argued against this form of the specializers list before, so I won't
bore you by repeating my claims that doing it this way won't work well.
Please reread the mail.

MAKE-GENERIC-FUNCTION:

Under remarks it says this is the programmatic interface to defgeneric-options,
but in fact this function does not do the same thing.  Defgeneric-options
can update an existing generic function.

I think some of the keyword arguments must be required.  Which ones?

MAKE-INSTANCE:

Typo: "instance of class" should be "instance of a class"

Typo: :instantiable option was renamed (but I say it should be removed).

MAKE-METHOD:

I would think a method object would want to know what generic-function it
was for; another argument should be added.  It at least wants to know this
for purpose of printing out.

What are the requirements on the function: arguments, results, and environment
for call-next-method?  I prefer that only functions that have been blessed
by the generic-function meta-object before being compiled be allowed.  I
suppose we could allow any function here with naive arguments, but then
we just have to have MAKE-METHOD-REAL, which is the one DEFMETHOD really
uses.

PRINT-OBJECT:

One method is enough, change "classes t and object" to "class t".

The arguments are an object and a stream; same as PRIN1 except that
the stream is not optional and cannot be T or NIL.

The value is the first argument (the object).

REMOVE-METHOD:

Typo: A sentence about argument list congruency was inadvertently
copied from add-method.

Value should be described the same way as add-method (after add-method's
value description is rewritten in English).

SLOT-VALUE:

What if no slot with that name exists?  Does it signal an error, "is" an
error, or return something?

Do built-in objects have slots?

Can slot-value access defstruct slots?

WITH-SLOTS:

In the last sentence under purpose, "unless the value of the :use-accessors
argument is nil" should be "unless the :use-accessors argument is nil",
since this argument is not evaluated.  In general it should be clarified
that none of the options in this special form are evaluated.

The first sentence under arguments doesn't make sense since everything
is an instance of a class.

Second para under arguments: "instance" in italics should be
"instance-form".  What happens if the restriction discussed is
violated?  Signal an error?

First bullet under arguments:  Typo: "method form" should be
"method body". 

Second bullet under arguments: hyphens at the end of the prefix
are used inconsistently.  The vague word "processed" appears again
(see defclass).

There is a serious bug in WITH-SLOTS.  Unlike DEFCLASS, which is
always used at top level and therefore is macroexpanded with a
predictable value of *PACKAGE*, interpreters that do not fully
macroexpand at the time DEFUN is evaluated, which CLtL permits,
will macroexpand WITH-SLOTS in an unpredictable dynamic environment
and therefore with an unpredictable value of *PACKAGE*.  I have
two suggestions for fixing this, both fairly distasteful.  One
is to document the bug and say that WITH-SLOTS with :PREFIX should
only be used in compiled code.  The other is to eliminate the
:PREFIX option and say that cases that are so complicated should
just call the accessors explicitly.

Under examples, comments contrasting the two move methods that were
lost in earlier editing are still missing.  The let should be removed
from the make-horizontal method since instance-forms can be any form,
and the indentation of this method should be corrected.

Some remarks that were present in the previous version seem to have
been lost in editing, unless the printer I used loses text from
the last page (nothing would surprise me!).  The remarks were that
setq is allowed as well as setf, that it signals an error if the
class is not specified or implied, and that it signals an error if
pseudo-variable names clash.

Thank you for reading all 400 lines.

∂05-Dec-86  1035	Gregor.pa@Xerox.COM 	&key &allow-other-keys  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Dec 86  10:35:04 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 05 DEC 86 10:12:57 PST
Date: 5 Dec 86 10:12 PST
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: &key &allow-other-keys
To: Common-Lisp-Object-System@Sail.Stanford.edu
Message-ID: <861205-101257-6043@Xerox>

When I sent out the initialization protocol the other day, I didn't
realize that you could have (&key &allow-others-keys) in a lambda list,
I thought you always had to have at least one keyword, this the idiom
(&key allow-other-keys &allow-other-keys).  It seemed like a bug, but it
was the wat I interpreted it.

Anyways, everyplace where I put

(&key allow-other-keys &allow-other-keys)

should be (&key &allow-other-keys)

Any other comments on that proposed protocol?

∂06-Dec-86  0732	masinter.pa@Xerox.COM 	Re: :accessor-prefix questions  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Dec 86  07:32:28 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 06 DEC 86 07:29:31 PST
Date: 6 Dec 86 07:29 PST
From: masinter.pa@Xerox.COM
Subject: Re: :accessor-prefix questions
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Mon, 1 Dec 86 13:58 EST
To: Common-Lisp-Object-System@SU-AI.ARPA
Message-ID: <861206-072931-1250@Xerox>

This proposal takes a bit of getting used to. Think about it a bit
before responding.
 

MOTIVATION: 

Why do we want :accessor-prefix? Because it is a useful and interesting
shorthand to the more verbose and less ambiguous  form of explicitly
giving the accessors.

(defclass foo () (string vector) (:accessor-prefix foo-)) 

Is clearly less verbose than

(defclass foo () ((string :accessor foo-string) (vector :accessor
vector-string)))

PROBLEM: (not repeated here)

PROPOSAL:

Here's an alternative that is not much more verbose, but reduces the
problem of the package of the accessors. Obser