perm filename CLOBOR.MSG[COM,LSP] blob sn#875213 filedate 1989-07-10 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00169 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00024 00002	Introduction
C00028 00003	∂23-Sep-84  1607	RPG  	Introduction  
C00032 00004	∂27-Sep-84  0737	DUGGAN@UTAH-20.ARPA 	Please add me ty your group  
C00033 00005	∂02-Oct-84  1310	RPG  	Chairman 
C00034 00006	∂11-Oct-84  1024	Stefik.pa@Xerox.ARPA 	Re: Introduction  
C00035 00007	∂13-Oct-84  1439	RPG  	Chairman 
C00036 00008	∂24-Oct-84  1926	HANDERSON@CMU-CS-C.ARPA 	Project description 
C00039 00009	∂27-Oct-84  2145	RPG  	Hello folks   
C00043 00010	∂30-Oct-84  1128	Kahn.pa@Xerox.ARPA 	Issues in object oriented programming in Common Lisp   
C00053 00011	∂30-Oct-84  1545	HANDERSON@CMU-CS-C.ARPA 	Different systems, variables  
C00057 00012	∂31-Oct-84  0920	DDYER@USC-ISIB.ARPA 	Instance variables 
C00059 00013	∂31-Oct-84  0948	DDYER@USC-ISIB.ARPA 	Fundamental Flavors
C00062 00014	∂31-Oct-84  1112	STICKLEN@RUTGERS.ARPA 	Re: Instance variables
C00064 00015	∂31-Oct-84  1300	HANDERSON@CMU-CS-C.ARPA 	Instance variables  
C00067 00016	∂31-Oct-84  1431	Kahn.pa@Xerox.ARPA 	Re: Instance variables   
C00071 00017	∂31-Oct-84  1441	AS%hp-hulk.csnet@csnet-relay.arpa 	Goals and Major Design Principles  
C00080 00018	∂31-Oct-84  1606	HANDERSON%cmu-cs-c.arpa@csnet-relay.arpa 	Goals and Major Design Principles (violent reply)    
C00085 00019	∂31-Oct-84  2123	FAHLMAN@CMU-CS-C.ARPA 	Goals  
C00093 00020	∂31-Oct-84  2212	Moon@SCRC-QUABBIN.ARPA 	What are we talking about?
C00100 00021	∂01-Nov-84  0704	FAHLMAN@CMU-CS-C.ARPA 	Goals  
C00105 00022	∂01-Nov-84  0927	GRISS%hp-hulk.csnet@csnet-relay.arpa 	Re: What are we talking about?  
C00107 00023	∂01-Nov-84  1136	FAHLMAN@CMU-CS-C.ARPA 	What are we talking about? 
C00111 00024	∂01-Nov-84  1209	HANDERSON@CMU-CS-C.ARPA 	Begging the question
C00112 00025	∂01-Nov-84  1736	STICKLEN@RUTGERS.ARPA 	Goals? 
C00115 00026	∂01-Nov-84  2135	Kahn.pa@Xerox.ARPA 	Re: What are we talking about?
C00118 00027	∂02-Nov-84  1654	RWK@SCRC-STONY-BROOK.ARPA 	Goals and Major Design Principles (violent reply)    
C00126 00028	∂02-Nov-84  1907	Moon@SCRC-STONY-BROOK.ARPA 	active values    
C00129 00029	∂09-Nov-84  1337	Kahn.pa@Xerox.ARPA 	Re: Status Of CL Object Oriented Group? 
C00133 00030	∂09-Nov-84  2006	HANDERSON@CMU-CS-C.ARPA 	Various thoughts and opinions 
C00139 00031	∂16-Nov-84  1255	DLW@SCRC-STONY-BROOK.ARPA 	Instance variables
C00147 00032	∂19-Nov-84  1012	"Kahn.pa"@Xerox.ARPA 	Re: Instance variables 
C00150 00033	∂19-Nov-84  1418	Moon@SCRC-STONY-BROOK.ARPA 	Re: Instance variables
C00154 00034	∂19-Nov-84  1557	RPG  
C00158 00035	∂19-Nov-84  1617	HANDERSON@CMU-CS-C.ARPA 	Instance variables  
C00163 00036	∂19-Nov-84  1826	Moon@SCRC-STONY-BROOK.ARPA 	Re: Instance variables
C00169 00037	∂03-Dec-84  1649	HANDERSON@CMU-CS-C.ARPA 	Internals Proposal  
C00179 00038	∂03-Dec-84  2229	HANDERSON@CMU-CS-C.ARPA 	Internals Proposal  
C00183 00039	∂05-Dec-84  1330	Bobrow.pa@Xerox.ARPA 	Re: Internals Proposal 
C00188 00040	∂07-Dec-84  1523	hpatlS!post%hplabs.csnet@csnet-relay.arpa 	hooks vs. subset (last try)
C00205 00041	∂08-Dec-84  1555	HANDERSON@CMU-CS-C.ARPA 	Bobrow's message, Snyder's message, Flavors kernel
C00210 00042	∂08-Dec-84  2039	FAHLMAN@CMU-CS-C.ARPA 	hooks vs. subset (last try)
C00215 00043	∂11-Dec-84  1955	BYLANDER@RUTGERS.ARPA 	Re: hooks vs. subset (last try) 
C00220 00044	∂13-Dec-84  1455	hpatlS!post%hplabs.csnet@csnet-relay.arpa 	de facto standards    
C00225 00045	∂13-Dec-84  1736	STICKLEN@RUTGERS.ARPA 	Clarificaiton Needed  
C00229 00046	∂15-Dec-84  1128	HANDERSON@CMU-CS-C.ARPA 	Standardization (ugh)    
C00234 00047	∂15-Dec-84  1923	FAHLMAN@CMU-CS-C.ARPA 	Standardization (ugh) 
C00238 00048	∂18-Dec-84  1537	KMP@MIT-MC 	protocols/syntax, semantics of SEND, genericity 
C00244 00049	∂18-Dec-84  1542	KMP@MIT-MC 	Keywords as messages   
C00248 00050	∂18-Dec-84  2103	@MIT-MC:Henry%MIT-OZ@SCRC-STONY-BROOK 	Messages as objects  
C00253 00051	∂19-Dec-84  1700	HANDERSON@CMU-CS-C.ARPA 	Fahlman's mail, syntax and T operations, standard send 
C00257 00052	∂19-Dec-84  1746	HANDERSON@CMU-CS-C.ARPA 	CAR sending a message, Liebermann's message  
C00261 00053	∂20-Dec-84  1239	JAR@MIT-MC 	Messages as objects    
C00264 00054	∂20-Dec-84  1647	Kahn.pa@Xerox.ARPA 	What are we up to?  
C00268 00055	∂21-Dec-84  1206	@MIT-MC:HENRY@MIT-OZ 	Messages as objects    
C00269 00056	∂21-Dec-84  2019	@MIT-MC:Henry%MIT-OZ@SCRC-STONY-BROOK 	Messages as objects  
C00271 00057	∂22-Dec-84  0054	@MIT-MC:Henry%MIT-OZ@SCRC-STONY-BROOK 	What are we up to?   
C00276 00058	∂22-Dec-84  1152	FAHLMAN@CMU-CS-C.ARPA 	What are we up to?    
C00282 00059	∂22-Dec-84  1410	HANDERSON@CMU-CS-C.ARPA 	What are we up to?  
C00289 00060	∂22-Dec-84  1653	Bobrow.pa@Xerox.ARPA 	Instance Variable Access    
C00292 00061	∂23-Dec-84  1517	@MIT-MC:Henry%MIT-OZ@SCRC-STONY-BROOK 	What are we up to?   
C00295 00062	∂09-Jan-85  1420	@MIT-MC:Henry%MIT-OZ@SCRC-RIVERSIDE 	Silence breaker   
C00298 00063	∂13-Jan-85  1713	HANDERSON@CMU-CS-C.ARPA 	Compiling iv references efficiently, making CL object-oriented   
C00304 00064	∂19-Feb-85  0955	DDYER@USC-ISIB.ARPA 	flavors  
C00309 00065	∂05-Mar-85  0508	STICKLEN@RUTGERS.ARPA 	Whats Up?   
C00310 00066	∂15-Mar-85  1555	Kahn.pa@Xerox.ARPA 	Re: Whats Up?  
C00313 00067	∂26-Mar-85  1725	hplabs!Snyder%hplabs.csnet@csnet-relay.arpa 	proposal  
C00317 00068	∂02-Apr-85  1609	HANDERSON@CMU-CS-C.ARPA 	Query
C00318 00069	∂02-Apr-85  1827	Moon@SCRC-STONY-BROOK.ARPA 	QLOGO  
C00319 00070	∂02-Apr-85  1937	GJC@MIT-MC 	QLOGO?  
C00322 00071	∂07-Apr-85  0953	fischer@ru-opal 	MI reference 
C00323 00072	∂22-Apr-85  1736	Kahn.pa@Xerox.ARPA 	Synder's proposal   
C00328 00073	∂08-May-85  1648	hplabs!Snyder%hplabs.csnet@csnet-relay.arpa 	Re: Snyder's proposal    
C00332 00074	∂11-Jul-85  2148	Kahn.pa@Xerox.ARPA 	Object-oriented programming & Common Lisp meeting 
C00335 00075	∂12-Jul-85  1014	AS%hp-hulk.csnet@csnet-relay.arpa 	Re: Object-oriented programming & Common Lisp meeting  
C00337 00076	∂12-Jul-85  1044	Moon@SCRC-STONY-BROOK.ARPA 	Object-oriented programming & Common Lisp meeting   
C00339 00077	∂12-Jul-85  1223	DDYER@SCRC-STONY-BROOK.ARPA 	Object-oriented programming & Common Lisp meeting  
C00342 00078	∂12-Jul-85  2136	Kahn.pa@Xerox.ARPA 	Written proposals   
C00344 00079	∂13-Jul-85  1853	HIC@SCRC-STONY-BROOK.ARPA 	Object-oriented programming & Common Lisp meeting    
C00348 00080	∂29-Jul-85  1906	Stefik.pa@Xerox.ARPA 	Xerox proposal to be mailed 
C00350 00081	∂30-Jul-85  1233	janel%tekchips%tektronix.csnet@csnet-relay.arpa 	Re: Xerox proposal to be mailed
C00352 00082	∂05-Aug-85  1602	Kahn.pa@Xerox.ARPA 	IJCAI meeting (time and place)
C00353 00083	∂12-Aug-85  1519	Masinter.pa@Xerox.ARPA 	CommonLoops paper mailed  
C00355 00084	∂14-Aug-85  0859	gls@THINK-AQUINAS.ARPA 	Common LOOPS    
C00361 00085	∂14-Aug-85  1316	Gregor.pa@Xerox.ARPA 	Type specification of &optional arguments. 
C00364 00086	∂14-Aug-85  1339	kessler%utah-orion@utah-cs.arpa 	CommonLoops 
C00367 00087	∂14-Aug-85  1605	Gregor.pa@Xerox.ARPA 	Re: CommonLoops   
C00371 00088	∂15-Aug-85  0710	FAHLMAN@CMU-CS-C.ARPA 	CommonLoops 
C00375 00089	∂15-Aug-85  1332	Kahn.pa@Xerox.ARPA 	[GLD%MIT-OZ@MIT-MC.ARPA: ObjectLisp]    
C00482 00090	∂15-Aug-85  1341	gls@THINK-AQUINAS.ARPA 	Sincere apologies    
C00486 00091	∂16-Aug-85  1537	JAR@MIT-MC.ARPA 	Common LOOPS questions 
C00489 00092	∂18-Aug-85  0025	Masinter.pa@Xerox.ARPA 	Re: Common LOOPS questions
C00492 00093	∂18-Aug-85  0139	masinter.PA@Xerox.ARPA 	correction on mlet & mlabels   
C00494 00094	∂18-Aug-85  0932	Moon@SCRC-STONY-BROOK.ARPA 	correction on mlet & mlabels    
C00498 00095	∂18-Aug-85  1130	masinter.PA@Xerox.ARPA 	Re: correction on mlet & mlabels    
C00502 00096	∂24-Aug-85  1141	RPG  	Mlet & Mlabels
C00504 00097	∂25-Aug-85  1931	FAHLMAN@CMU-CS-C.ARPA 	Meeting at IJCAI 
C00505 00098	∂30-Aug-85  1302	Kahn.pa@Xerox.ARPA 	Response to Masinter's multi-slot idea  
C00510 00099	∂30-Aug-85  1407	Kahn.pa@Xerox.ARPA 	Re: Response to Masinter's multi-slot idea   
C00512 00100	∂02-Sep-85  2315	FAHLMAN@CMU-CS-C.ARPA 	Questions about Commonloops
C00529 00101	∂03-Sep-85  1353	Gregor.pa@Xerox.ARPA 	CommonLoops discussion.
C00531 00102	∂03-Sep-85  1412	Gregor.pa@Xerox.ARPA 	Re: Questions about Commonloops  
C00533 00103	∂03-Sep-85  1528	Gregor.pa@Xerox.ARPA 	the :allocation slot option 
C00535 00104	∂03-Sep-85  1544	Tribble.pa@Xerox.ARPA 	Re: CommonLoops discussion.
C00536 00105	∂03-Sep-85  2016	FAHLMAN@CMU-CS-C.ARPA 	Questions about Commonloops
C00542 00106	∂04-Sep-85  1409	Masinter.pa@Xerox.ARPA 	Re: LISP has both pure and reference data types    
C00546 00107	∂13-Sep-85  1541	Bobrow.pa@Xerox.ARPA 	[Masinter.pa: Re: Questions about Commonloops]  
C00568 00108	∂15-Sep-85  1627	Bobrow.pa@Xerox.ARPA
C00589 00109	∂17-Sep-85  2101	FAHLMAN@C.CS.CMU.EDU
C00593 00110	∂18-Sep-85  0140	Bobrow.pa@Xerox.ARPA 	Notes IJCAI mewtting of Common Lisp Object Committee 
C00616 00111	∂18-Sep-85  0811	Moon@SCRC-STONY-BROOK.ARPA 	Name conflicts for names of instance variables 
C00620 00112	∂18-Sep-85  1558	DT50@A.CS.CMU.EDU 	slot shadowing  
C00629 00113	∂18-Sep-85  1709	Moon@SCRC-STONY-BROOK.ARPA 	slot shadowing   
C00640 00114	∂19-Sep-85  1758	bobrow.pa@Xerox.ARPA 	Arguments and values to get.
C00642 00115	∂19-Sep-85  1819	FAHLMAN@C.CS.CMU.EDU 	Arguments and values to get.
C00645 00116	∂20-Sep-85  0709	KMP@SCRC-STONY-BROOK.ARPA 	Arguments and values to get.
C00649 00117	∂22-Sep-85  1828	masinter.pa@Xerox.ARPA 	A reply and some more thoughts on specializing built-in 
C00654 00118	∂22-Sep-85  1835	masinter.pa@Xerox.ARPA 	Re: EQUAL isn't really correct, I agree  
C00656 00119	∂22-Sep-85  1943	FAHLMAN@C.CS.CMU.EDU 	A reply and some more thoughts on specializing built-in   
C00661 00120	∂22-Sep-85  2242	DT50@A.CS.CMU.EDU 	reply to Moon on slot shadowing
C00665 00121	∂23-Sep-85  1127	Bobrow.pa@Xerox.ARPA 	Re: A reply and some more thoughts on specializing built-in    
C00667 00122	∂23-Sep-85  1204	DLW@SCRC-VALLECITO.ARPA 	CommonLoops    
C00671 00123	∂23-Sep-85  1535	DT50@A.CS.CMU.EDU 	SPECIALIZABLE(-)P    
C00672 00124	∂23-Sep-85  1927	FAHLMAN@C.CS.CMU.EDU 	CommonLoops  
C00693 00125	∂23-Sep-85  1943	FAHLMAN@C.CS.CMU.EDU 	A reply and some more thoughts on specializing built-in   
C00695 00126	∂23-Sep-85  2144	DDYER@SCRC-QUABBIN.ARPA 	CommonLoops & Flavors' complexity  
C00698 00127	∂24-Sep-85  0009	RWK@SCRC-STONY-BROOK.ARPA 	CommonLoops  
C00713 00128	∂24-Sep-85  1300	Bobrow.pa@Xerox.ARPA
C00717 00129	∂24-Sep-85  1705	AS%hp-hulk.csnet@CSNET-RELAY.ARPA  
C00720 00130	∂24-Sep-85  1910	FAHLMAN@C.CS.CMU.EDU 	Complexity, yet again  
C00729 00131	∂24-Sep-85  1955	Moon@SCRC-QUABBIN.ARPA 	Complexity, yet again
C00736 00132	∂24-Sep-85  2026	FAHLMAN@C.CS.CMU.EDU 	Complexity, yet again  
C00741 00133	∂24-Sep-85  2112	Moon@SCRC-STONY-BROOK.ARPA 	Complexity, yet again 
C00746 00134	∂25-Sep-85  0425	FAHLMAN@C.CS.CMU.EDU 	Complexity, yet again  
C00750 00135	∂25-Sep-85  0918	Bobrow.pa@Xerox.ARPA 	Re: --- 
C00753 00136	∂26-Sep-85  0432	AS%hp-hulk.csnet@CSNET-RELAY.ARPA 	Re: ---   
C00755 00137	∂01-Oct-85  0214	hplabs!snyder%hplabs.csnet@CSNET-RELAY.ARPA 	Re: slot shadowing  
C00765 00138	∂03-Oct-85  1436	DCP@SCRC-QUABBIN.ARPA 	Arguments and values to get.    
C00767 00139	∂09-Nov-85  1944	sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA 	addn to the mailing list.	   
C00768 00140	∂15-Dec-85  1702	RPG  	Call for Papers OOPSLA86     
C00774 00141	∂03-Jan-86  1756	Gregor.pa@Xerox.ARPA 	CommonLoops meets Object Lisp    
C00779 00142	∂03-Apr-86  1600	masinter.pa@Xerox.COM 	March 24, 1986 Electronic Engineering Times article 
C00787 00143	∂04-Apr-86  0945	kempf%hplabsc@hplabs.ARPA 	Re:  March 24, 1986 Electronic Engineering Times article  
C00789 00144	∂04-Apr-86  1102	Masinter.pa@Xerox.COM 	Re:  March 24, 1986 Electronic Engineering Times article 
C00791 00145	∂03-Jul-86  1112	snyder%hplsny@hplabs.HP.COM 	two questions about New Flavors
C00793 00146	∂03-Jul-86  1708	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	two questions about New Flavors    
C00799 00147	∂18-Jul-86  1343	snyder%hplsny@hplabs.HP.COM 	accessor functions   
C00801 00148	∂18-Jul-86  1442	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	accessor functions  
C00803 00149	∂21-Jul-86  1253	Gregor.pa@Xerox.COM 	Re: accessor functions  
C00805 00150	∂23-Jul-86  1217	snyder%hplsny@hplabs.HP.COM 	Re: accessor functions    
C00809 00151	∂23-Jul-86  1333	Gregor.pa@Xerox.COM 	Re: accessor functions  
C00813 00152	∂24-Jul-86  1157	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Re: accessor functions   
C00816 00153	∂24-Jul-86  1244	snyder%hplsny@hplabs.HP.COM 	Re: accessor functions    
C00820 00154	∂24-Jul-86  2046	Carnese@SRI-KL.ARPA 	Re: accessor functions  
C00825 00155	∂25-Jul-86  0843	@SRI-KL.ARPA:DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Re: accessor functions 
C00832 00156	∂25-Jul-86  0922	DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Re: accessor functions    
C00837 00157	∂25-Jul-86  1222	snyder%hplsny@hplabs.HP.COM 	Re: accessor functions    
C00844 00158	∂26-Jul-86  1048	DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Re: accessor functions    
C00851 00159	∂26-Jul-86  1551	Gregor.pa@Xerox.COM 	Re: accessor functions  
C00853 00160	∂28-Jul-86  1535	Carnese@SRI-KL.ARPA 
C00859 00161	∂29-Jul-86  1550	Gregor.pa@Xerox.COM 	Re: ---  
C00862 00162	∂30-Jul-86  1719	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Re: accessor functions   
C00867 00163	∂30-Jul-86  1915	FAHLMAN@C.CS.CMU.EDU 	accessor functions
C00871 00164	∂31-Jul-86  0842	CARNESE@SRI-KL.ARPA 	operation naming conventions 
C00876 00165	∂31-Jul-86  1133	Gregor.pa@Xerox.COM 	Re: operation naming conventions  
C00879 00166	∂01-Aug-86  1338	Carnese@SRI-KL.ARPA 	Re: operation naming conventions  
C00883 00167	∂02-Aug-86  1428	DLW@QUABBIN.SCRC.Symbolics.COM 	Re: operation naming conventions 
C00892 00168	∂13-Aug-86  1109	Kahn.pa@Xerox.COM 	Summary of CL OOP Meeting on August 6    
C00895 00169	∂14-Aug-86  1335	Gregor.pa@Xerox.COM 	Portable CommonLoops Export Status
C00899 ENDMK
C⊗;
Introduction
Welcome to the Common Lisp Object-Oriented Programming Subgroup.
In order to mail to this group, send to the address:

		CL-Object-Oriented-Programming@su-ai.arpa

Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:

			   CLOBOR.MSG[COM,LSP]

You can read this file or FTP it away without logging in to SAIL.

To communicate with the moderator, send to the address:

		CL-Object-Oriented-Programming-request@su-ai.arpa

Here is a list of the people who are currently on the mailing list:

Person			Affiliation	Net Address

Richard Greenblatt	LMI		"rg%oz"@mc
Scott Fahlman		CMU		fahlman@cmuc
Eric Schoen		Stanford	schoen@sumex
Gordon Novak		Univ. of Texas	novak@utexas-20
Kent Pitman		MIT		kmp@mc
Dick Gabriel		Stanford/Lucid	rpg@sail
David Wile		ISI		Wile@ISI-VAXA
Martin Griss		HP		griss.hplabs@csnet-relay (I hope)
Walter VanRoggen	DEC		wvanroggen@dec-marlboro
Richard Zippel		MIT		rz@mc
Dan Oldman		Data General	not established
Larry Stabile		Apollo		not established
Bob Kessler		Univ. of Utah	kessler@utah-20
Steve Krueger		TI		krueger.ti-csl@csnet-relay
Carl Hewitt		MIT		hewitt-common-objects@mc
Alan Snyder		HP		snyder.hplabs@csnet-relay
Jerry Barber		Gold Hill	jerryb@mc
Bob Kerns		Symbolics	rwk@mc
Don Allen		BBN		allen@bbnf
David Moon		Symbolics	moon@scrc-stonybrook
Glenn Burke		MIT		GSB@mc
Tom Bylander		Ohio State	bylander@rutgers
Richard Soley		MIT		Soley@mc
Dan Weinreb		Symbolics	DLW@scrc-stonybrook
Guy Steele		Tartan		steele@tl-20a
Jim Meehan		Cognitive Sys.	meehan@yale
Chris Reisbeck		Yale		riesbeck@yale

The first order of business is for each of us to ask people we know who may
be interested in this subgroup if they would like to be added to this list.

Next, we ought to consider who might wish to be the chairman of this subgroup.
Before this happens, I think we ought to wait until the list is more nearly
complete. For example, there are no representatives of Xerox, and I think we
agree that LOOPS should be studied before we make any decisions.

∂23-Sep-84  1607	RPG  	Introduction  
To:   cl-object-oriented-programming@SU-AI.ARPA 
Welcome to the Common Lisp Object-Oriented Programming Subgroup.
In order to mail to this group, send to the address:

		CL-Object-Oriented-Programming@su-ai.arpa

Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:

			   CLOBOR.MSG[COM,LSP]

You can read this file or FTP it away without logging in to SAIL.

To communicate with the moderator, send to the address:

		CL-Object-Oriented-Programming-request@su-ai.arpa

Here is a list of the people who are currently on the mailing list:

Person			Affiliation	Net Address

Richard Greenblatt	LMI		"rg%oz"@mc
Scott Fahlman		CMU		fahlman@cmuc
Eric Schoen		Stanford	schoen@sumex
Gordon Novak		Univ. of Texas	novak@utexas-20
Kent Pitman		MIT		kmp@mc
Dick Gabriel		Stanford/Lucid	rpg@sail
David Wile		ISI		Wile@ISI-VAXA
Martin Griss		HP		griss.hplabs@csnet-relay (I hope)
Walter VanRoggen	DEC		wvanroggen@dec-marlboro
Richard Zippel		MIT		rz@mc
Dan Oldman		Data General	not established
Larry Stabile		Apollo		not established
Bob Kessler		Univ. of Utah	kessler@utah-20
Steve Krueger		TI		krueger.ti-csl@csnet-relay
Carl Hewitt		MIT		hewitt-common-objects@mc
Alan Snyder		HP		snyder.hplabs@csnet-relay
Jerry Barber		Gold Hill	jerryb@mc
Bob Kerns		Symbolics	rwk@mc
Don Allen		BBN		allen@bbnf
David Moon		Symbolics	moon@scrc-stonybrook
Glenn Burke		MIT		GSB@mc
Tom Bylander		Ohio State	bylander@rutgers
Richard Soley		MIT		Soley@mc
Dan Weinreb		Symbolics	DLW@scrc-stonybrook
Guy Steele		Tartan		steele@tl-20a
Jim Meehan		Cognitive Sys.	meehan@yale
Chris Reisbeck		Yale		riesbeck@yale

The first order of business is for each of us to ask people we know who may
be interested in this subgroup if they would like to be added to this list.

Next, we ought to consider who might wish to be the chairman of this subgroup.
Before this happens, I think we ought to wait until the list is more nearly
complete. For example, there are no representatives of Xerox, and I think we
agree that LOOPS should be studied before we make any decisions.

∂27-Sep-84  0737	DUGGAN@UTAH-20.ARPA 	Please add me ty your group  
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 27 Sep 84  07:37:16 PDT
Date: Thu 27 Sep 84 08:39:01-MDT
From: Jerry Duggan <duggan@UTAH-20.ARPA>
Subject: Please add me ty your group
To: cl-object-oriented-programming@SU-AI.ARPA, cl-subsets@SU-AI.ARPA

I work with Bob Kessler at the University of Utah.

Jerry Duggan
-------

∂02-Oct-84  1310	RPG  	Chairman 
To:   cl-object-oriented-programming@SU-AI.ARPA 
Now that we've basically got most everyone who is interested on the mailing
list, let's pick a chairman. I suggest that people volunteer for chairman.

The duties are to keep the discussion going, to gather proposals and review
them, and to otherwise administer the needs of the mailing list. I will
retain the duties of maintaining the list itself and the archives, but
otherwise the chairman will be running the show. 

Any takers?
			-rpg-

∂11-Oct-84  1024	Stefik.pa@Xerox.ARPA 	Re: Introduction  
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 11 Oct 84  10:16:52 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 11 OCT 84 10:14:39 PDT
Date: 11 Oct 84 10:06 PDT
From: Stefik.pa@XEROX.ARPA
Subject: Re: Introduction  
In-reply-to: Dick Gabriel <RPG@SU-AI.ARPA>'s message of 23 Sep 84 16:07
 PDT
To: RPG@SU-AI.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA

Richard -- I would also like to join the discussion.  Mark

∂13-Oct-84  1439	RPG  	Chairman 
To:   cl-object-oriented-programming@SU-AI.ARPA 

Jonathon Rees has been nominated as chairman of the Object-oriented
subgroup.  If he is willing, and no one else volunteers, he will
become chairman. Please respond by October 24. At the end of this month
I want to see some ideas and proposals coming in on this mailing list.
			-rpg-

∂24-Oct-84  1926	HANDERSON@CMU-CS-C.ARPA 	Project description 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Oct 84  19:26:37 PDT
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Wed 24 Oct 84 22:26:58-EDT
Date: Wed, 24 Oct 1984  22:26 EDT
Message-ID: <HANDERSON.12058126458.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   cl-object-oriented-programming@SU-AI.ARPA
Subject: Project description
In-reply-to: Msg of 13 Oct 1984  17:39-EDT from Dick Gabriel <RPG at SU-AI.ARPA>


We might as well start by saying what various projects are in the works.
I've heard of a Loops project going on somewhere - maybe somebody
involved in that can say how it's going.

I'm currently working with Moon to try to develop a (hopefully small)
kernel to implement Flavors in.  This might also be good for applications
that construct functions that call component operations ("combined
methods" they're called) and has the Flavor-like notion of instance
variables (i.e. those with the same name are the same).  We're currently
trying to use abstraction to come up with something neat and clean.

I will be pushing for a notion of methods that puts the defmethod in the
lexical environment (like defun) and the instance variables with the
lexical variables (allowing you to close over them).  I have a prototype
that does this using a form of symbol macros, but this could be added
specially.  Also, if instance variables are like lexical variables, then
if the instance variables of the flavor changes, the method can become
invalid [as if (let ((a 3)) a) suddenly became just a].  I will push for
a kernel that can throw out methods if it thinks it needs to (as long as
it notifies the user).  The rest is just trying to keep the kernel
clean.

∂27-Oct-84  2145	RPG  	Hello folks   
To:   cl-object-oriented-programming@SU-AI.ARPA 

We now have a chairman of the object-oriented programming subgroup:
Ken Kahn of Xerox Parc. I think he will make an excellent chairman
because he has extensive experience with both the MacLisp/ZetaLisp
style of doing things, Prolog, and LOOPS and InterLisp. For your information
I am including the current members of the mailing list.

I will now let Ken Kahn take over responsibility for the discussion.

David Matthews		HP		"hpfclp!objects%hplabs"@csnet-relay
Ken Sinclair		LMI		"khs%mit-oz"@mit-mc
Neil Goldman		ISI		GOLDMAN@ISI
Mark Stefik		Xerox		Stefik.pa@XEROX
John Foderaro		Berkeley	jkf@ucbmike.arpa
Jon Sticklen		Ohio State	Sticklen@rutgers
Danny Bobrow		Xerox		bobrow.pa@xerox
Jonathon Rees		MIT		jar@mc
Howard Cannon		Symbolics 	"hic%scrc"@mc
Jerry Duggan		Univ of Utah	duggan@utah-20
Dave Dyer		Symbolics	ddyer@isib
Christopher Stacy	MIT		cstacy@mc
Richard Greenblatt	LMI		"rg%oz"@mc
Scott Fahlman		CMU		fahlman@cmuc
Eric Schoen		Stanford	schoen@sumex
Gordon Novak		Univ. of Texas	novak@utexas-20
Kent Pitman		MIT		kmp@mc
Steve Handerson		CMU		handerson@cmuc
Dick Gabriel		Stanford/Lucid	rpg@sail
David Wile		ISI		Wile@ISI-VAXA
Martin Griss		HP		griss.hplabs@csnet-relay (I hope)
Walter VanRoggen	DEC		wvanroggen@dec-marlboro
Richard Zippel		MIT		rz@mc
Dan Oldman		Data General	not established
Larry Stabile		Apollo		not established
Bob Kessler		Univ. of Utah	kessler@utah-20
Steve Krueger		TI		krueger.ti-csl@csnet-relay
Carl Hewitt		MIT		hewitt-common-objects@mc
Alan Snyder		HP		snyder.hplabs@csnet-relay
Jerry Barber		Gold Hill	jerryb@mc
Bob Kerns		Symbolics	rwk@mc
Don Allen		BBN		allen@bbnf
David Moon		Symbolics	moon@scrc-stonybrook
Glenn Burke		MIT		GSB@mc
Tom Bylander		Ohio State	bylander@rutgers
Richard Soley		MIT		Soley@mc
Dan Weinreb		Symbolics	DLW@scrc-stonybrook
Guy Steele		Tartan		steele@tl-20a
Jim Meehan		Cognitive Sys.	meehan@yale
Chris Reisbeck		Yale		riesbeck@yale
Ron Fischer		Rutgers		fischer@rutgers
Jonl White		Xerox		jonl@xerox
Neal Feinberg		Symbolics	feinberg@scrc-stony-brook
Ken Kahn		Xerox		kahn@xerox

∂30-Oct-84  1128	Kahn.pa@Xerox.ARPA 	Issues in object oriented programming in Common Lisp   
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 30 Oct 84  11:27:55 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 30 OCT 84 11:25:04 PST
Date: 30 Oct 84 11:25 PST
From: Kahn.pa@XEROX.ARPA
Subject: Issues in object oriented programming in Common Lisp
To: cl-object-oriented-programming@SU-AI.ARPA
cc: Kahn.pa@XEROX.ARPA, Henry@MIT-MC.ARPA, Mittal.pa@XEROX.ARPA

To different people object oriented programming in Common Lisp means
very different things.  I think the first thing we should do is discuss
what people want done.  I assume most people feel the tension between
some kind of standard (that will help portability, provide an
opportunity to clean up and rationalize existing systems, promote
communication of ideas, etc.) and the dangers of premature
standardization.   

Some of the questions going through my head are:
(1) Is there some small kernel for objects that is adequate for building
multiple inheritance, method specialization, method demons, and whatever
else that people want?
(2) Where do most people stand on some the rather basic issues of
object-oriented systems such as
  (a) Should there be a distinction between classes and instances?  I.e.
should one be able to add methods to instances?
  (b) How private should instance variables be?  Need one send messages
to access them?  To access other's instance variables?  What should be
encouraged vs. enforced?
  (c) Should message passing be based upon selectors or more general
pattern matching?
  (d) Should there be class variables?
  (e) What is a reasonable set of initial classes or flavors?  What
methods should they have?
  (f)  How should "self" be treated?
  (g) How should multiple inheritence work?
  (h) Should there be meta classes?  
  (i) How should objects interface with Lisp?  What should happen if a
Lisp primitive is applied to an object?  Should SETF etc. work on
message sending?  Should objects be functional objects ala ZetaLisp?
  (j) Are methods themselves objects?  Are classes? ...
  (k) Should the system support the notion of protocols that are
collections of behaviors?
(3) Terminology.  Maybe before doing much else we should come to some
consensus about what terminology to use.  Do people think that "flavor"
is better than "class"?   Do people like "subflavor", "abstract flavor",
etc. ?   There seems to be at least three different ways of talking
about objects the Flavors way, the SmallTalk/Loops way, and Hewitt's
actors.  What do people prefer?
(4) Syntax.  What should a method definition look like?  What about a
message transmission?  A flavor definition?

I'm sure that there are a lot more issues that I'm just not thinking
of.   So feel free to add your own.


Instead of 40 people trying to discuss 20 issues simoultaneously, I
propose that we serialize the discussion.  To get things rolling I'll
pick one of the issues above, describe the alternatives, and try to
bring out the arguments pro and con.

(2) (b) Instance variables.
There are several ways in which instance variables are treated in
different object-oriented programming languages.  Flavors takes the
position that the instance variables of "self" can be accessed and set
just as ordinary Lisp variables within a method.  Instance variables of
others are accessed or set via message passing.  To make this easier the
appropriate methods can be generated automatically.  In a language I did
several years ago called Director all instance variable access and
update were done by message sending.   In Loops one refers to instance
variables by function call.  There are macros so that this is as consise
as possible. Lets call these instance variable schemes "Lisp variables
for self", "message passing", and "function call".

Lisp variables for self:  Consise  and potentially very efficient when
refering to self's instance variables; clean, modular,  relatively
inefficient  and verbose when refering to others, nearly impossible to
implement  in Lisp (one must change the kernel to treat specially
variables that it recognizes are instance variables)

Message passing: Very modular, verbose, difficult to optimize, easy to
implement active values (demons on variable access and update) by method
demons or specialization, different name space for Lisp variables and
instance variables.

Function call:  Easy to abuse (e.g. depend upon the internal
representation of other objects), easy to implement active values
(though via a seperate mechanism from method demons), different name
space for Lisp variables and instance variables.

One can make arguments about the arguments:  A different name space is
good because it makes visually clear what is Lisp and what is object.
Modularity is important to maintain the ideal that an object is defined
behaviourally and its internal representation is hidden to the world.
Active values are very useful.  One needs less mechanism if active
values can be supported by method specialization (demons). Etc. 

Don't vote on these issues, instead add your own arguments.

I know that various groups have a lot invested in existing
object-oriented systems in Lisp (Flavors, Loops, KEE, ...).  Perhaps its
too late to re-think some of these fundamental issues.  I see several
possible outcomes from this Common Lisp subgroup's discussions.  Perhaps
a new language will be designed, perhaps some common ground will be
identified, perhaps some existing sublanguage will be accepted by the
community as a standard, perhaps we'll come to understand the issues
better, perhaps nothing will happen.  Its up to us, so please
participate.
Send in your 2 cents worth. 

∂30-Oct-84  1545	HANDERSON@CMU-CS-C.ARPA 	Different systems, variables  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 30 Oct 84  15:45:28 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Tue 30 Oct 84 18:45:18-EST
Date: Tue, 30 Oct 1984  18:45 EST
Message-ID: <HANDERSON.12059669889.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   cl-object-oriented-programming@SU-AI.ARPA
Subject: Different systems, variables
In-reply-to: Msg of 28 Oct 1984  00:45-EDT from Dick Gabriel <RPG at SU-AI.ARPA>


Ken,

My own impression is that nobody knows how to do object oriented programming
(multiple inheritance in particular) "right," if there is indeed a right way;
instead, there are just a bunch of different ways of dealing with similar
problems.  I would favor working backwards from existing systems- that would
give those of us familiar with only one system a chance to learn about others.
We might be able to come up with some commonalities, but I doubt they would
mean much in and of themselves.

Flavors people want instance variables to look like variables; this pretty much
requires that they act like them with respect to locality.  If the semantics of
a method syntax depend on other than the target Flavor, changing those might
require many methods to be recompiled - painful, and currently impossible for
methods that have closed over something.  Tagging the references with @! or
something lets the system nonambiguously associate references with the
operation, which it can then use in whatever way it wishes.

I'm partial to the "lisp variables for self", since it leads to an efficient
representation.  It was difficult to implement, but not impossible; Symbolics
and I do it two different ways.  I also think active values could be added to
Flavors - it's just a question of working out the specifics of a proposal.  [If
someone familiar with these is interested in working out a proposal, I'd be
willing to put some time into it.]

I believe that one of the whole points of object-oriented programming is that
an object (and no one else) is responsible for its own integrity (behavioural).
Some instance variables might represent individual pieces of state; others
might be related in some complex way.  Those that are related probably want to
be private- not accessible from anything but the class itself.  If Flavors had
a :private-instance-variables option that would disallow inheriting those
instance variables, that would cover it.

-- Steve

∂31-Oct-84  0920	DDYER@USC-ISIB.ARPA 	Instance variables 
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 31 Oct 84  09:20:47 PST
Date: 31 Oct 1984 09:17:08 PST
Subject: Instance variables
From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
To: cl-object-oriented-programming@SU-AI.ARPA


 I also strongly favor the proposal that instance variables of
self be accessed as variables.  I like it because they look
like variables, so you can know there is no funny business
going on when you get or set one.

 Active values ought to be implemented as message protocols rather
than as instance variables with hidden behavior.

 :PRIVATE-INSTANCE-VARIABLES ought to be available, and maybe
should be the default for instance variables unless they are
:GETTABLE or :SETTABLE.
-------

∂31-Oct-84  0948	DDYER@USC-ISIB.ARPA 	Fundamental Flavors
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 31 Oct 84  09:47:55 PST
Date: 31 Oct 1984 09:45:46 PST
Subject: Fundamental Flavors
From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
To: cl-object-oriented-programming@SU-AI.ARPA


 I strongly agree with the statement that no one knows how to
do multiple inheritence "right".  There is no one "right"
way.  If CL-objects expect to gain adherents, they will have
to accomodate many different styles, on this and other issues
of fundamental design.

 What should really be specified is a basic architecture for
message passing, method definition, flavor definition, and
local storage, in which it is possible to define symbolics'
current flavors as a special case.

 To be a little more specific;


 The underlying machinery has to deal efficiently with
two principal problems;  Locating the correct method
to invoke in a message pass, and locating the correct
instance variable to use for local variable references.
Except that it makes no provision for class variables,
I would propose that Symbolics' primitives for these
are adequately robust and effecient, and so can serve
as a starting point for the "primitives" discussion.

 The algorithms which (at "flavor construction" time)
determine which methods will be found, and which instance
variables will be accessed by these effecient primitives,
should be modifiable rather than wired in.   The obvious
way to do this is to make them methods of a flavor. 
We would predefine a "really basic flavor constructor"
flavor, which would itself allow no daemons or inheretance,
but which would have methods to construct flavors
of the more complex varieties, which would in turn
be used to construct the instances  we ordinarily use.

-------

∂31-Oct-84  1112	STICKLEN@RUTGERS.ARPA 	Re: Instance variables
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 31 Oct 84  11:11:51 PST
Date: 31 Oct 84 14:10:33 EST
From: Jon Sticklen <STICKLEN@RUTGERS.ARPA>
Subject: Re: Instance variables
To: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: Message from "Dave Dyer       <DDYER@USC-ISIB.ARPA>" of 31 Oct 84 12:17:08 EST

is seems as if dave is confusing two issues: 
	1) whether or not IVs of self should be references as
	   simple variables
	2) how active values should be implemented

suppose there were no AVs (or that dave's suggestion for AVs was
adopted). then there would be no "funny business" whether we accessed
an IV as a variable or by a function. 

i'll save my coments on AVs until that discussion comes up.

not being familiar with FLAVORS, maybe someone could fill me in on
a base level: by going with referencing IVs of self as variables, isn't
the potential present of having a local var in a method with the same
name as a local IV? in FLAVORS, how is the name conflict problem
resolved?

	---jon---
-------

∂31-Oct-84  1300	HANDERSON@CMU-CS-C.ARPA 	Instance variables  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 31 Oct 84  13:00:01 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Wed 31 Oct 84 15:59:09-EST
Date: Wed, 31 Oct 1984  15:58 EST
Message-ID: <HANDERSON.12059901710.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   Jon Sticklen <STICKLEN@RUTGERS.ARPA>
Cc:   cl-object-oriented-programming@SU-AI.ARPA
Subject: Instance variables
In-reply-to: Msg of 31 Oct 1984  14:10-EST from Jon Sticklen <STICKLEN at RUTGERS.ARPA>


The way to think of it is that the defmethod form wraps the method code with
something that "binds" the instance variables.  If you bind something of the
same name, it shadows the instance-variable binding, as always.  I've probably
said this too many times already, but it is my strong opinion and belief that
instance variables are naturally lexical (accessible only inside methods).  If
so, I see no reason why they can't act just like Common Lisp lexical variables
and get closed over, etc.  The result is very Common Lispy.

An illustration of closure:

(Defflavor my-flavor (a b) () :settable-instance-variables)
(defmethod (my-flavor :closure) ()
  #'(lambda () a))
(funcall (send (make-instance 'my-flavor) :closure)) --> 3.

If this is not the case, the semantics of that reference have changed, probably
from being an instance variable to being something else.  This is gross and
confusing. 

-- Steve

∂31-Oct-84  1431	Kahn.pa@Xerox.ARPA 	Re: Instance variables   
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 31 Oct 84  14:30:10 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 31 OCT 84 14:20:44 PST
Date: 31 Oct 84 14:17 PST
From: Kahn.pa@XEROX.ARPA
Subject: Re: Instance variables
In-reply-to: Steven <Handerson@CMU-CS-C.ARPA>'s message of Wed, 31 Oct
 84 15:58 EST
To: Handerson@CMU-CS-C.ARPA
cc: STICKLEN@RUTGERS.ARPA, cl-object-oriented-programming@SU-AI.ARPA

I think you left out a 3 somewhere but I see the point.
I like the notion of thinking of a DEFMETHOD as something that expands
to a giant LET binding the instance variables to their values.  The
problem then is with SETQ and the like.
Flavors sort of takes the view that an object is a functional closure
and that DEFMETHOD "edits" the definition of the function.

The reason I brought up active values at the same time as instance
variables is that they depend upon how  instance variables are treated.
A message protocol can capture active values but it requires that
messages always be sent to access and update instance variables even
those of "self".

What I would like (and I think many would) is a message passing
semantics for access and update of instance variables with the
consiseness and efficiency of Flavors.  Perhaps they are not
incompatible (I can imagine a compiler that compiles
(setq foo x) inside a method where foo is an instance variable to
something like (send self ':set-foo x).  But could this be made
efficient?  And is it really desirable to have something that looks like
a setq really be a send?).  Perhaps compromises are necessary.  

I like the idea of private instance variables.  What is a little odd
about them is that they prevent  methods of subflavors from seeing or
changing certain instance variables even though they are instance
variables of the instances of those subflavors.
Or was something else being proposed?

∂31-Oct-84  1441	AS%hp-hulk.csnet@csnet-relay.arpa 	Goals and Major Design Principles  
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 31 Oct 84  14:40:32 PST
Received: from hplabs by csnet-relay.csnet id ah01171; 31 Oct 84 17:30 EST
Received: by HP-VENUS id AA23331; Wed, 31 Oct 84 12:49:50 pst
Message-Id: <8410312049.AA23331@HP-VENUS>
Date: 31 Oct 1984 1250-PST
From: AS%hplabs.csnet@csnet-relay.arpa
Subject: Goals and Major Design Principles
To: cl-object-oriented-programming%su-ai.arpa@csnet-relay.arpa
Source-Info:  From (or Sender) name not authenticated.

Rather than immediately getting bogged down in technical design details
like how instance variables are accessed, I think we should try to
reach agreement on the goals of this effort and major design principles.
Here are some issues that I think are important:

* Hooks vs. Subset

One strategy that has been frequently mentioned is to define a collection of
primitive hooks upon which various objects systems can be implemented.  From
the designers point of view, this is a wonderful idea, as it allows each
designer to do his own thing while we delay making any decisions.  However,
this strategy fails to satisfy the need of Common Lisp USERS for a standard
definition they can USE to write code.  So, while I support the (possibly
unrealistic) idea of a standard implementation base for objects, I think it is
more important that we attempt to come up with a usable "common subset" (in the
Common Lisp tradition) that is agreeable to the largest number of people.

* Start Simple

Because of the number of technical issues where substantial disagreement
appears to exist, we may have to restrict our definition severely to reach
agreement in a reasonable period of time.  Given a choice between a severely
restricted definition (a "common subset") that appears soon versus a complete
and widely endorsed design that takes years to hammer out, I would recommend
the former as the more valuable.  Certainly, it is easier to add new features
later than to change or remove features once they get into the definition.

* Multiple Objects Systems

The strategy of providing standard primitive hooks allows for the possibility
of supporting multiple coexisting objects systems.  While there is merit in
this idea, I think our primary goal should be the definition of a single,
standard system.

* Efficiency

The Common Lisp objects system should be chosen to be efficient, particularly
on stock hardware, and usable on "small" machines.  The efficiency goal argues
against including nonessential features in the standard that penalize all
message passing, regardless of whether the feature is used or not.  (For
example, some features may require additional "hidden" arguments to method
functions.)  The "small" machine goal argues against definitions that require
large run-time (as opposed to compile-time) data structures or on-the-fly
compilation.  For example, one must be careful not to promise too much support
for incremental redefinition.  A development system can always provide more
support than the definition requires.

* Avoid Exposing Implementation Details

To allow the most freedom to the implementor, and to allow future extensions
to the language, the objects system should avoid exposing implementation
details.  In particular, it should avoid exposing the nature of any "hidden"
arguments to method functions, as these can vary based on the implementation
strategy and the features supported.  This goal may preclude the definition of
a useful set of publicly-available primitive hooks.

* Relation to Defstruct

Unfortunately, any object system is likely to have a significant overlap with
Defstruct.  We must consider reducing the redundancy, either by defining the
object system as a variant/extension of defstruct (ugh), or by flushing
defstruct (hard).

* Messages to Non-Instances

It is desirable that messages can be sent to any Lisp object, not just
instances.  Problems might arise if we attempt to allow users to define
methods for non-instances, particularly if we intend to support multiple
coexisting objects systems.  Certainly, we would have to clearly define the
type hierarchy for the primitive types.

* Retroactive Changes

Once message passing exists in Common Lisp, many things could be redefined to
take advantage of it.  For example, the stream functions could be defined in
terms of message passing, allowing users to define new stream types.  How much
redefinition should be done?

* Encapsulation

In my opinion, a major design issue is encapsulation, meaning the ability to
separate the implementation of a "class" from its external interface, allowing
implementation changes that do not change the external interface to be
relatively transparent to users.  Although encapsulation is claimed to be one
of the important features of object-oriented programming, the objects
languages that I have seen all fail to support encapsulation in their
definitions of inheritance.  I am working on a proposal that fully supports
encapsulation, but in its present form I know it will be unacceptable to those
who take advantage of some of the less disciplined features of other systems.
This area is one where I would prefer to start with a conservative definition
(that does not destroy encapsulation) rather than immediately endorsing the
more powerful but less disciplined features.
-------

∂31-Oct-84  1606	HANDERSON%cmu-cs-c.arpa@csnet-relay.arpa 	Goals and Major Design Principles (violent reply)    
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 31 Oct 84  16:06:12 PST
Received: from cmu-cs-c.arpa by csnet-relay.arpa id a001449; 31 Oct 84 18:47 EST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Wed 31 Oct 84 18:45:43-EST
Date: Wed, 31 Oct 1984  18:45 EST
Message-ID: <HANDERSON.12059932109.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson%cmu-cs-c.arpa@csnet-relay.arpa>
To:   AS%hplabs.csnet%csnet-relay.arpa@csnet-relay.arpa
Cc:   cl-object-oriented-programming%su-ai.arpa%csnet-relay.arpa@csnet-relay.arpa
Subject: Goals and Major Design Principles (violent reply)
In-reply-to: Msg of 31 Oct 1984  15:50-EST from AS%hplabs.csnet at csnet-relay.arpa


You standardize a language in order to write (MANY) portable programs - you do
NOT standardize everything written in it.  I sincerely doubt that any single
object system can reflect even the few views that have been presented so far.
I am a user, and I would like to be able to use LOOPs, Flavors, and anything
else that comes along in the comfortableness and cleanliness of my own Common
Lisp.  I am not qualified to say "This is good, this is bad."  

"Advantage comes from what is; usefulness comes from what is not."  [The Tao]

As for small machines, let's not design for obsolescence, huh?  Very fast,
cheap and REAL machines are beginning to become available.  Let's plan for it,
instead of against it.  Real things should be done on real machines.

Re: defstruct.  Defstruct is single-inheritance; Flavors is multiple.  Very
different.  There are different tools for different uses.  You don't open a
paint can with a sharp knife.  It's always possible that someone will invent a
sharp-knife/paint-can-opener in one, but you don't waste your time trying to
figure one out.  There are entire catalogs of bogus tools that nobody uses [I
guess if you buy one, you're apt to buy many].

Trying to redefine everything to use message passing is a good way to create a
blob of string that nobody can separate, as well as to slow otherwise fast
things down.  We have an editor that is more powerful and faster than the Lisp
Machine's, mostly BECAUSE it was written without Flavors (it's also fairly
portable). 

We DO need standardization to do things like have the lisp system be able to
talk to different object systems.  Once we have this, then we can worry about
defining streams and such.  I'm not sure how possible this is, or even if it's
especially desirable.  [Yeah, it's fun, but...]  It could be that all we need
to do is standardize on there being a message name and arguments, and then have
some system SEND operation that various object systems can interface to.  [Like
have it dispatch on the name of the instance's object system to get the sending
function] This has possiblities.

-- Steve

∂31-Oct-84  2123	FAHLMAN@CMU-CS-C.ARPA 	Goals  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 31 Oct 84  21:22:58 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 1 Nov 84 00:23:00-EST
Date: Thu, 1 Nov 1984  00:22 EST
Message-ID: <FAHLMAN.12059993508.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   cl-object-oriented-programming@SU-AI.ARPA
Subject: Goals


I guess I'll toss in my thoughts about what we might want to accomplish.

First, there is a lot of demand among potential Common Lisp users for a
Flavor system that is either compatible with the current Lisp Machine
system, or is a slight improvement in ways that the various Lisp Machine
companies will fully support.  Some of these users actually seem to
think that Flavors is the right thing.  Some of them have no idea what
the issues are and are using the term "flavors" generically.  Most,
however, have existing code developed on 3600's that they want to port
to other systems, or plan to move back and forth across this boundary in
the future.  If we don't met this need, we end up splitting the Common
Lisp community into those who use flavors and those who don't, with no
code-sharing between them.

The way flavors are used by Lisp machine people, they have to be quite
efficient, and that means a small amount of low-level,
machine-dependent, non-portable support.  Given this low-level support
in some standard form, it is possible to keep most of the flavor system
code fully portable.  So if we define the portable flavor system in two
parts, each implementation that wants flavors will be able to implement
a very small implementation-dependent kernel, grab the file of portable
public-domain flavor code, and they've got it.

A separate question is whether this standardized flavor-support kernel
should go into the white pages.  Should something be allowed to call
itself a Common Lisp if no flavor system is available, or should we
require this support machinery so that code using flavors is guaranteed
to be portable?  Maybe the issue would go away if we could provide a
file of code that implements the low-level flavor support entirely in
portable Common Lisp.  The resulting flavor system would be slow, and
perhaps not too useful because of that, but it would be legal.
Implementations that wanted a FAST flavor system would have a clear and
finite set of things to improve.

So much for Flavors.  A different but related issue is what a really
good object-oriented system might look like.  I was among those who
opposed including flavors or any other object-oriented system in the
first pass of the Common Lisp definition because I don't think anyone
has got it right yet.  Without going into a lot of flames about what is
wrong with flavors, I think that a lot of people see the flavor system
as being much too complex.  This results from wanting the system to have
completely flexible multiple inheritance, late binding, and still have
everything compiled as tensely as possible.  I think that those are
basically incompatible goals, and if you push a little too hard on them
you get exponential growth in complexity for very little gain.  Maybe
after we've all had as much experience with these things as the Lisp
Machine people, we'll all come around to their point of view; then
again, maybe they're wedged.  In any event, the only way that a
consensus is going to emerge on this is for people to play with a
variety of object-oriented styles, flavors included.  The idea of making
controversial mechansims spend some time in the yellow pages to see if
people like them seems especially appropriate here.

So what can we do?  Some users feel that they need a portable flavor
system, with low-level support that does not give away ANY performance
for generality.  I was hopeful that the same set of non-portable
mechanisms that we need for implementing a portable flavor system would
also be a good substrate for exploration of other object-oriented
systems.  If we can come up with such a common kernel for objects, that
would be the best answer, whether or not we put it in the white pages.
But if this is impossible, maybe we will have to have one very
specialized, very tense kernel for flavors, and a more general kernel
for experimentation with other object-oriented paradigms.

Then again, maybe there's enough horsepower in this group for someone to
come up with an object oriented system that we will all love at first
sight.

-- Scott

∂31-Oct-84  2212	Moon@SCRC-QUABBIN.ARPA 	What are we talking about?
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 31 Oct 84  22:11:09 PST
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 97920; Wed 31-Oct-84 23:15:59-EST
Date: Wed, 31 Oct 84 23:18 EST
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Reply-To: cl-object-oriented-programming@SU-AI.ARPA
Subject: What are we talking about?
To: cl-object-oriented-programming@SU-AI.ARPA
Message-ID: <841031231806.9.MOON@EUPHRATES.SCRC.Symbolics>

Perhaps we should be talking about the charter of the object oriented
programming interest group, rather than about details.

I believe that Common Lisp is not a complete programming system in itself, and
was not intended to be.  I believe Common Lisp is a substrate-building tool and
a method for enhancing portability.  It is a language, not a programming system.

My belief is that Common Lisp should not specify a particular method of
object-oriented programming, any more than it should specify a particular
AI knowledge representation system or a particular display terminal.
I believe that the Common Lisp white pages should be augmented with the
necessary facilities to make it possible to write a variety of efficient,
portable, yellow-pages object-oriented programming systems.  Multiple
object-oriented programming systems should be able to coexist simultaneously
in the same Lisp environment.  People building applications should be able
to select whichever object-oriented programming system(s) they prefer
for the particular task; there should be a marketplace of ideas.

The charter of this group should be to specify those white-pages facilities
required for the building of object-oriented programming systems, to see that
they are implemneted in our respective implementations, and to encourage the
production of several object-oriented programming systems.  The first systems to
be implemented should probably be Common Lisp versions of systems such as
Flavors and Loops that are already popular.

What are the criteria for inclusion of some feature in these white-pages
facilities, which might be called the object-oriented programming kernel?
The fundamental criterion is that a feature is included if it is necessary
or desirable for it to be implemented in an implementation-dependent way
rather than a portable way.  The two reasons I can think of for this are
(1) efficiency, and (2) close interaction with implementation-dependent
mechanisms such as function-calling, variable-accessing, or the compiler.

What are the criteria for -not- including some feature in the object-oriented
programming kernel?  Anything that can be implemented in portable Common Lisp
code, even if every implementation of every object-oriented programming system
ends up using the same code, should not be included.  Anything that involves
controversial issues should not be included, because people will not agree
and because it would be wrong (for Common Lisp) to try to force them to agree.
I'm sure it will not be possible to attain a perfect separation between
kernel features and controversial issues, but that is what we should aim for.

To sum up: Mechanisms should be in the kernel.  Policies should be outside.

Howard Cannon wrote an (incomplete) proposal for how to do this two or three
years ago.  It was geared to the kernel features necessary to implement flavors,
but that appears to subsume what most other Lisp-based object-oriented
programming systems require.  Steve Handerson has an implementation on the
PERQ of something resembling this proposal.  These might be good places
to start.  I've had enough experience with both of these to know that it won't
be easy; making these mechanisms both efficient and portable to our wide
range of architectures isn't easy.

By the way, if this is all too vague for you, and you want to hear something
concrete, I'll just mention that Flavors have active values already and have
always had them.

∂01-Nov-84  0704	FAHLMAN@CMU-CS-C.ARPA 	Goals  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 1 Nov 84  07:01:36 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 1 Nov 84 10:01:31-EST
Date: Thu, 1 Nov 1984  10:01 EST
Message-ID: <FAHLMAN.12060098826.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   cl-object-oriented-programming@SU-AI.ARPA
Subject: Goals


I basically agree with Moon's views on what level of stuff should go
into the white pages (or some semi-standard: you don't have to do this,
but if you do you should do it this way), and therefore what this group
needs ultimately to decide.  My somewhat rambling message of last night
was meant only to indicate that even this is not an easy problem for
several reasons:

1. There is great demand for the best possible substrate for a flavor
system.  Many of the Lisp Machine people understandably oppose a
mechanism that would slow down flavors even a little bit in the interest
of generality, or that would not support some of the more complex
features of flavors.

2. Any kernel needs some sort of method-lookup support that can handle
multiple strands of inheritance, some sort of mechanism for accessing
instance variables from methods, probably a separate instance data type
for cleanliness (instances could in principle be built as structures,
but we probably want them to print differently, etc.), and maybe some
sort of low-level mechanism for efficient implementation of active values.

3. Even in that small set of mechanisms there is some difficulty.  For
example do instance variables look to a method writer like lexical
variables, special variables, or something else?  To what lengths do we
want to go to support late binding: methods referencing instance
variables when the instance-defining flavors or classes have not yet
been defined or might change?  And so on.

Anyway, my point is that even if we want to confine our final output to
a single set of low-level non-portable mechanisms, we may need to
discuss the higher-level issues in order to understand the range of
things that need to be supported, and to see if a consensus exists on
any of this stuff.  If everyone agrees that instance variables in self
should look like lexical variables bound at the time of a send, then
we've got a useful constraint; if someone deeply believes that these
things should look some other way, then we have to think about whether
we can accommodate both views.

Probably the best way to make progress (after the initial goal-setting
period) is to begin circulating proposals for the low-level stuff and to
see where the sticking points really are.  A specific proposal tends to
crystallize the argument in a way that a more general discussion will
not.

-- Scott

∂01-Nov-84  0927	GRISS%hp-hulk.csnet@csnet-relay.arpa 	Re: What are we talking about?  
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 1 Nov 84  09:26:47 PST
Received: from hplabs by csnet-relay.csnet id a005632; 1 Nov 84 12:22 EST
Received: by HP-VENUS id AA13670; Thu, 1 Nov 84 04:40:31 pst
Message-Id: <8411011240.AA13670@HP-VENUS>
Date: Thu 1 Nov 84 04:41:06-PST
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Re: What are we talking about?
To: cl-object-oriented-programming%su-ai.arpa@csnet-relay.arpa
Cc: GRISS@hplabs.CSNET
In-Reply-To: Message from ""David A. Moon" <Moon@SCRC-STONY-BROOK@HP-VENUS>" of Thu 1 Nov 84 00:18:16-PST
Source-Info:  From (or Sender) name not authenticated.

I appreciate the minimality sentiments expressed; I actually think
these are the same sentiments that should also direct the design of a subset
... ie, are there generally useful things ALREADY in Common LISP
that can be easily and effectively expressed in a portable way in
terms of a subset; if so, is it fair game to discuss their removel to
"blue" pages for an approved subset.

M
-------

∂01-Nov-84  1136	FAHLMAN@CMU-CS-C.ARPA 	What are we talking about? 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 1 Nov 84  11:36:23 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 1 Nov 84 14:35:30-EST
Date: Thu, 1 Nov 1984  14:35 EST
Message-ID: <FAHLMAN.12060148702.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Martin <GRISS%hplabs.csnet@CSNET-RELAY.ARPA>
Cc:   cl-object-oriented-programming@SU-AI.ARPA
Subject: What are we talking about?
In-reply-to: Msg of 1 Nov 1984  07:41-EST from Martin <GRISS%hplabs.csnet at csnet-relay.arpa>


Martin,

I think the situations are very different.  In the object-oriented game,
we as a group (and some of us as individuals) don't really know what we
want yet.  The idea of putting in a minimal and general set of hooks is
to let a thousand flowers bloom, so that we can all get some experience
with the different possibilities and then, maybe, someday, reach a
consensus on what we all like.

Subsets are different.  In the language as currently defined in the
white pages, we deliberately put in a lot of high-level stuff that could
have been defined in terms of more primitive constructs precisely
because we did not want a thousand flowers to bloom.  Things made it
into the white pages whenever we felt confident that a large number of
users would want them and that we understood these things well enough to
know that the facility as provided is about as good as any other way of
doing it.  In these cases, leaving the decision unbound would just
promote incompatibility, not useful diversity.

Of course, anyone implementing a Common Lisp would be foolish to ignore
the fact that some of these things can be defined in terms of others.
In fact, we provide public-domain code for an awful lot of these things,
and any very tiny system could either auto-load just what it needs or
could purge whatever it doesn't need at system-delivery time.  Very
little has to be implemented by hand as the lowest-level support.  

-- Scott

∂01-Nov-84  1209	HANDERSON@CMU-CS-C.ARPA 	Begging the question
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 1 Nov 84  12:09:43 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Thu 1 Nov 84 15:09:36-EST
Date: Thu, 1 Nov 1984  15:09 EST
Message-ID: <HANDERSON.12060154903.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   cl-object-oriented-programming@SU-AI.ARPA
Subject: Begging the question
In-reply-to: Msg of 1 Nov 1984  14:35-EST from Scott E. Fahlman <Fahlman>


Ok, Dave, what kind of active values are already present in Flavors?

-- Steve

∂01-Nov-84  1736	STICKLEN@RUTGERS.ARPA 	Goals? 
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 1 Nov 84  17:36:12 PST
Date: 1 Nov 84 20:34:56 EST
From: Jon Sticklen <STICKLEN@RUTGERS.ARPA>
Subject: Goals?
To: cl-object-oriented-programming@SU-AI.ARPA

i  feel a bit uneasy about some of the messages in this forum. 
what ARE the purposes here? if the purposes are to define a
"kernel" as per moon's suggestion (which on the surface seems
reasonable to me) then the participation in this discussion can be
drastically limited to people like danny bobrow and mark stefik (on
the LOOPS side), danny weinreb and david moon (on the FLAVORS side)
and of course others. the point is that if a core is to be constructed
that will allow the various object oriented languages to be built on
top of it, then the right people to carry on the discussion are the
IMPLEMENTORS of the various extant systems. IF on the other hand the
goal is to set out what is desired in a uniform object oriented
language for CommonLisp, then there is still a place for USERS (like
me).

so it would seem to me that the FIRST order of business is decide what
this discussion is to be about.

one recent message seemed to be suggesting that because some folks
have a lot invested in FLAVORS based software, that therefore the
resultant standard should look a lot like FLAVORS. 

if you take the time to look around a bit, you'll discover that others
have a lot invested in LOOPS based software.

but the real issue is that these concern over who has how much
invested in what should  @b<@u(NOT)> be the driving concern for
setting this standard, at least i don't think so.

if, as someone suggested, noone knows the right way to do object
oriented systems yet, then moon's suggestion takes on even greater
weight. 

	---jon---
-------

∂01-Nov-84  2135	Kahn.pa@Xerox.ARPA 	Re: What are we talking about?
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 1 Nov 84  21:35:06 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 01 NOV 84 21:34:49 PST
Date: 1 Nov 84 11:36 PST
From: Kahn.pa@XEROX.ARPA
Subject: Re: What are we talking about?
In-reply-to: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>'s message of
 Wed, 31 Oct 84 23:18 EST
To: cl-object-oriented-programming@SU-AI.ARPA
cc: Kahn.pa@XEROX.ARPA

I too like the idea of minimality, of a minimal kernel for building
different object oriented systems on top of.  What is a little odd is
that Loops as far as I know requires nothing that Common Lisp doesn't
already provide.  The reasons for this are that 
(1) objects are not functional objects so Funcall, etc. doesn't work on
them
(2)  instance variables are wrapped in a macro call so that neither the
compiler nor interpreter need distinguish instance variables from other
Lisp variables. 
(3) self is just passed as an argument so it doesn't need to be set by
any micro-code.

Active values. 
How does flavors have active values?  Its true that if one sends message
':foo and ':set-foo then via method combination one can do all that
active values do.  But its not normal practice to send those messages to
self.
Or do you mean that one can use ZetaLisp's monitor-variable to capture
activeness on updating.  If so then what about access?

Defstruct vs Defflavor.  I agree with Alan Synder that there is
significant overlap here.  I find that too often I start with a
defstruct only to reach some limitation and re-write it as a defflavor.
At least the syntax of the two forms should be as similar as possible to
make it easier to convert.  More ambitious merging of the two is
probably very hard.

∂02-Nov-84  1654	RWK@SCRC-STONY-BROOK.ARPA 	Goals and Major Design Principles (violent reply)    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 Nov 84  16:51:33 PST
Received: from SCRC-HUDSON by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 119875; Fri 2-Nov-84 10:25:05-EST
Date: Fri, 2 Nov 84 10:24 EST
From: "Robert W. Kerns" <RWK@SCRC-STONY-BROOK.ARPA>
Subject: Goals and Major Design Principles (violent reply)
To: Steven <Handerson@CMU-CS-C.ARPA>
cc: AS%hplabs.csnet@CSNET-RELAY.ARPA,
    cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: <HANDERSON.12059932109.BABYL@CMU-CS-C.ARPA>
Message-ID: <841102102453.9.RWK@HUDSON.SCRC.Symbolics.COM>

    Date: Wed, 31 Oct 1984  18:45 EST
    From: Steven <Handerson%cmu-cs-c.arpa@csnet-relay.arpa>
    Re: defstruct.  Defstruct is single-inheritance; Flavors is multiple.  Very
    different.  There are different tools for different uses.  You don't open a
    paint can with a sharp knife.  It's always possible that someone will invent a
    sharp-knife/paint-can-opener in one, but you don't waste your time trying to
    figure one out.  There are entire catalogs of bogus tools that nobody uses [I
    guess if you buy one, you're apt to buy many].

On the other hand, you could go broke (run out of space, fill up your
bookshelf, confuse yourself) buying lots and lots of single-purpose
tools.  A 2x4 cutter.  An interior-grade-plywood cutter.  A masonite
cutter.  Or you could buy a table saw.

I have found that flavors have replaced about 90% of my usage of
DEFSTRUCT, and I find it difficult to justify much of the remaining
10%.  Instead of writing lots of (MY-STRUCT-FOO STRUCT)'s, I use a
lot of FOO's, and I probably gain as much efficiency from using
instance variables as I give up in calling the methods.  I think
a lot of people think in terms of replacing every (MY-STRUCT-FOO STRUCT)
with a message-pass.  This is not the way you use a message-passing
system!  Much of the code that you used to write "outside" the
DEFSTRUCT you'll write "inside" the object, and access the instance
variables directly.

    Trying to redefine everything to use message passing is a good way to create a
    blob of string that nobody can separate, as well as to slow otherwise fast
    things down.  

I didn't see him say that everything has to use message passing!  It is
quite possible to have objects that you don't manipulate via message
passing, but are still "objects", and also SUPPORT message passing.

For example, I firmly believe the integer 6 should support the
:PRINT-SELF message.  That doesn't mean I believe the + operator should
be implemented using message-passing, at least in the INTEGER+INTEGER
case!  DEFSTRUCT accessors don't have to send messages, either, even if
named-structures are build using instances of some object-system.

		  We have an editor that is more powerful and faster than the Lisp
    Machine's, mostly BECAUSE it was written without Flavors (it's also fairly
    portable). 

This is nonsense!  The Lisp Machine editor was written without flavors
as well, since it was done before flavors!  Even today, for most structures
it doesn't use flavors.  Where it does use them, it doesn't use message
passing for the commonly-accessed instance variables, so it's probably
FASTER than using DEFSTRUCTs, on our system at least.

If you've got a faster editor (faster doing what?), it's either because
you're comparing it against the old LM-2/CADR architecture, or you're
running without a reasonable amount of memory, or because you've done a
truly outstanding job on your Lisp, your editor system.

    We DO need standardization to do things like have the lisp system be able to
    talk to different object systems.  Once we have this, then we can worry about
    defining streams and such.  I'm not sure how possible this is, or even if it's
    especially desirable.  

I think it's possible, and desirable.  I think it's important to
standardize on certain message-passing PROTOCOLS.  This is quite
independent of what object-system you implement.  The stream protocol is
one example; if I have an editor stream, written using flavors, I should
be able to bring it (and flavors) to a system using something else, and
be able to print to my stream.  Similarly, I should be able to take a
pretty-printer that talks to LOOPS-based streams to a flavor-system and
use it there.

I don't think we're ready to try to do any of this yet.  (Nor do we yet
have to agree that it's the right thing).  I think this is way down on
the agenda.


∂02-Nov-84  1907	Moon@SCRC-STONY-BROOK.ARPA 	active values    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 Nov 84  19:06:55 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 120516; Fri 2-Nov-84 22:04:45-EST
Date: Fri, 2 Nov 84 22:04 EST
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: active values
To: Kahn.pa@XEROX.ARPA, Steven <Handerson@CMU-CS-C.ARPA>
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: The message of 1 Nov 84 14:36-EST from Kahn.pa@XEROX.ARPA,
             <HANDERSON.12060154903.BABYL@CMU-CS-C.ARPA>
Message-ID: <841102220427.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 1 Nov 1984  15:09 EST
    From: Steven <Handerson@CMU-CS-C.ARPA>

    Ok, Dave, what kind of active values are already present in Flavors?

    Date: 1 Nov 84 11:36 PST
    From: Kahn.pa@XEROX.ARPA

    How does flavors have active values?  Its true that if one sends message
    ':foo and ':set-foo then via method combination one can do all that
    active values do.  

Exactly.

    But its not normal practice to send those messages to self.

Not so.  It depends on the particular programming style employed.  Many
people use messages to access logical values that happen to be stored
directly as instance variables, especially people who use active values.

∂09-Nov-84  1337	Kahn.pa@Xerox.ARPA 	Re: Status Of CL Object Oriented Group? 
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 9 Nov 84  13:37:02 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 09 NOV 84 13:27:40 PST
Date: 9 Nov 84 13:28 PST
From: Kahn.pa@XEROX.ARPA
Subject:Re: Status Of CL Object Oriented Group?
To: cl-object-oriented-programming@SU-AI.ARPA

The group has been quiet for about a week.  Maybe people don't have much
more to say about instance variables.  I'll try to summarize soon what I
think people did say about it.

A new issue we can discuss is the interface between Lisp and objects.
Some of the issues here need to be answered even if we take the approach
of specifying what hooks and primitives need to be in Common Lisp so
everyone can implement their favorite object system.

** How should Lisp send a message?  **
Should this be standardized?  If so should the selector be quoted?  Do
people like the idea of a macro named "send"?

** What should happen if a message is sent to a Lisp datatype? **
Should this be an error?  Should there be a way to define methods for
Lisp datatypes?  If so, should they be associated with the name of the
data type or what?  
(Loops is in the process of experimenting with this now and we are
finding it very useful.  It also permits one to write functions that
work equally well on objects as lists, etc. )
If the overhead of the send to a Lisp datatype can be compiled away
then perhaps lots of system code should send messages even when by
default the objects are just lists or arrays.  I/O streams and windows
are examples where this probably makes sense.

** What should happen if a Lisp primitive is called with an object as an
argument?  Should car and cdr send messages to their args in such a
case?  What about plus? print?  This issue is important because one
sometimes writes objects to implement some exotic kind of number or list
and wants these objects to integrate well with existing code.  What
should type-of of an object return?  What should eval of an object do?


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

∂09-Nov-84  2006	HANDERSON@CMU-CS-C.ARPA 	Various thoughts and opinions 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 9 Nov 84  20:06:35 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Fri 9 Nov 84 23:00:40-EST
Date: Fri, 9 Nov 1984  22:54 EST
Message-ID: <HANDERSON.12062336722.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   cl-object-oriented-programming@SU-AI.ARPA
Subject: Various thoughts and opinions
In-reply-to: Msg of 9 Nov 1984  16:28-EST from Kahn.pa at XEROX.ARPA


The only reason we would want to standardize *anything* is if Common Lisp has
to talk to an object system, as is the case with CAR of an object.  We don't
even have a kernel for Flavors yet, so I don't think there's much point in
discussing a general kernel.  Assuming the kernels are well-designed and easy
to implement, it won't kill to have two or three.  There's not really much
point in standardizing send if you don't get any primitives out of it.

If the sending operation is a macro or defsubst or something, it can look at
the send to see if the operation is a constant (for inline expansion or
whatever).  One of the major differences between send and a function call is
that the operation can be a computed quantity.  Is that what you meant by
quoting the selector?

If we don't standardize sending, then we shouldn't standardize how to send to
non-instances.  We could make up a list of suggested operation names and
arguments, though.  Some are obvious, like 'LISP:CAR and 'LISP:PRINT, but more
complicated operations might be a problem.  I haven't thought about this too
much.

I feel pretty strongly that if you know something is a list, you should use CL
functions instead of sending messages.  Code analysis tools (like compilers)
will then know what you're talking about.  On the other hand, changing the
behavior of lisp primitives is something entirely different and possibly very
fruitful.  This would allow you to (fairly efficiently) use the same operation
(lisp functions and functions written with them) for instances and
non-instances.  Still, you want to do the "normal" thing fast, and then have
exception handling for the unusual thing, not vice-versa.

If each instance has an object-system-name as part of its known structure, and
if we associate a sending function (with agreed-upon arguments) with each
object-system-name, then CL primitives could simply find the appropriate
sending function and invoke it.  The arguments would probably be something like
(object operation-name . arguments), where the operation-names are
standardized.  Flavors (and LOOPS, I think) should be able to just put their
sending functions in as the interface.  Since there are going to be a finite
number of known operations, the sending function could itself do the
dispatching if necessary.  These operations probably want their own package.

Typing such objects is a problem, one I'm not really qualified to talk about.
Presumably you want the system to use typep wherever possible, so that the
object can decide if it wants to be a cons or not.  Typep for "simple" types
could and should be fast, but for objects it should send a message using the
above interface.

-- Steve

∂16-Nov-84  1255	DLW@SCRC-STONY-BROOK.ARPA 	Instance variables
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Nov 84  12:54:54 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 128489; Fri 16-Nov-84 13:03:54-EST
Date: Fri, 16 Nov 84 13:03 EST
From: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Subject: Instance variables
To: Handerson@CMU-CS-C.ARPA, Kahn.pa@XEROX.ARPA, Fahlman@CMU-CS-C.ARPA,
    cl-object-oriented-programming@SU-AI.ARPA, STICKLEN@RUTGERS.ARPA
Message-ID: <841116130318.9.DLW@CHICOPEE.SCRC.Symbolics.COM>

Sorry for the late replies; I just got around to reading all of my
Common Lisp mail.  This is mostly about the meta-issue of what we should
be discussing.

I also strongly agree that we should be trying to discover a set of
primitive hooks that every implementation can provide, so that several
message-passing systems can be provided in a yellow pages library.  For
us to try to design a single message passing system and try to impose it
on all the users would be a mistake.  Therefore, there's no need for us
to send mail saying which way message passing should work; rather we
should try to assemble a list of requirements that will drive the
definition of the primitive hooks.

Those of us who are familiar with existing systems such as flavors or
loops can contribute by making sure that the primitive hooks will be
sufficient to produce a reasonably efficient implementation of that
system.  We'll have to work together on this, since probably nobody is
familiar with the requirements of all systems.

If we can agree on this strategy, then we can keep this discussion more
focussed and useful.  For example, the issue of "but isn't defstruct
sort of similar" should be postponed, since it is very unlikely to
affect the design of the primitive hooks.

As Scott Fahlman says, we will have to discuss some of the higher-level
issues (how should variables work, how should inheritance work), but we
need not get agreement on all of them.  If we all agree about some
issue, then we can feel free to make the primitive hooks support the
agreed answer; if it seems clear that we do not agree about some issue,
then rather than argue it to death, we can just try to design the
primitive hooks to support various different answers.

I'd like to reply to one thing that Scott said:

    Date: Thursday, 1 November 1984, 10:01-EST
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

    1. There is great demand for the best possible substrate for a flavor
    system.  Many of the Lisp Machine people understandably oppose a
    mechanism that would slow down flavors even a little bit in the interest
    of generality, or that would not support some of the more complex
    features of flavors.

Well, actually, if there's some big conflict here, it need not cause a
breakdown in cooperation.  Just because there is a set of primitives
that each implementation must implement, and there is a yellow-pages
implementation of flavors, does not mean that we are required to use
that implementation; we could provide the hooks, but keep using our
existing implementation that doesn't use those hooks.  Of course, it
would be better to avoid such a situation, but if worse comes to worst,
we could do it.

I'd also like to reply regarding one specific technical point, namely,
the "lexical" behavior of instance variables:

    Date: Wednesday, 31 October 1984, 15:58-EST
    From: Steven <Handerson@CMU-CS-C.ARPA>
				      but it is my strong opinion and belief that
    instance variables are naturally lexical (accessible only inside methods).

In the implementation of Flavors that will be included in our next
software release (Rel 6.0), this is exactly how it works.  A lambda
expression that is closed inside a method can refer to the instance
variables of the instance, as a natural extension of the meaning of
lexical scoping.

    Date: Wednesday, 31 October 1984, 17:17-EST
    From: Kahn.pa@XEROX.ARPA
    I like the notion of thinking of a DEFMETHOD as something that expands
    to a giant LET binding the instance variables to their values.  The
    problem then is with SETQ and the like.
    Flavors sort of takes the view that an object is a functional closure
    and that DEFMETHOD "edits" the definition of the function.

I don't understand this; what's the problem with SETQ?  An internal
function of a method can SETQ the instance variables just fine, even if
it's returned (i.e. even if it is an "upward funarg").

∂19-Nov-84  1012	"Kahn.pa"@Xerox.ARPA 	Re: Instance variables 
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 19 Nov 84  10:12:18 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 19 NOV 84 10:09:42 PST
Date: 19 Nov 84 09:39 PST
From: Kahn.pa@XEROX.ARPA
Subject: Re: Instance variables
In-reply-to: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>'s message of
 Fri, 16 Nov 84 13:03 EST
To: cl-object-oriented-programming@SU-AI.ARPA
cc: Kahn.pa@XEROX.ARPA

I'm seeing a consensus that we should concentrate first on defining
hooks into Common Lisp for implementing Flavors, Loops, and the like.
If there are people out there that think that this is a mistake but have
been too busy or shy to contribute to this discussion, now's the time to
put forth an alternative.

Regarding my comment about SETQ of instance variables.
Of course there is no problem if you view methods  (or objects) as
closures.  What I was referring to is the idea that a method is an
ordinary function with an implicit (LET ((var-1 (GetValue var-1 ..)) ...
(var-n (GetValue var-n ..))) ...) around it.

I have question for Flavors people.  "self" is treated specially by the
micro-code rather than being a special variable.  Do you think it
reasonable for Common Lisp to hack "self" or would you be happy with
just send and give up on funcall for message passing?  Loops passes
"self" around as the first argument and its just an ordinary lambda
variable which can have any name.  Does flavors require "self" to be
treated specially and if so what do you propose Common Lisp do about it?

>>Message<<

∂19-Nov-84  1418	Moon@SCRC-STONY-BROOK.ARPA 	Re: Instance variables
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 19 Nov 84  14:17:56 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 129953; Mon 19-Nov-84 17:19:53-EST
Date: Mon, 19 Nov 84 17:18 EST
From: "David A. Moon" <Moon@SCRC-QUABBIN.ARPA>
Subject: Re: Instance variables
To: Kahn.pa@XEROX.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: The message of 19 Nov 84 12:39-EST from Kahn.pa@XEROX.ARPA
Message-ID: <841119171810.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 19 Nov 84 09:39 PST
    From: Kahn.pa@XEROX.ARPA

    I have question for Flavors people.  "self" is treated specially by the
    micro-code rather than being a special variable.  Do you think it
    reasonable for Common Lisp to hack "self" or would you be happy with
    just send and give up on funcall for message passing?  Loops passes
    "self" around as the first argument and its just an ordinary lambda
    variable which can have any name.  Does flavors require "self" to be
    treated specially and if so what do you propose Common Lisp do about it?

I sure can't understand a word of this question.  Which, if any, of the
following possible interpretation of your question is what you meant?

  - Would Flavors people please discourse upon the difference between the
    3600 and CADR implementations of flavors, with respect to the point that
    in the CADR the variable SELF is special but in the 3600 it is lexical.

  - Do we want instances of flavors to be usable as functions, with FUNCALL
    and APPLY, or do we want them only to be invocable with SEND?

  - What should the Common Lisp ARGLIST function return when given a method
    as its argument?

  - What parts of the mechanism for accessing instance variables supplied
    by the proposed Common Lisp object-oriented-programming kernel should
    be hidden, and what parts should be exposed to the portable programmer?

  - Would Flavors people please discourse upon the virtues and/or uglinesses
    of their DEFUN-METHOD feature.

∂19-Nov-84  1557	RPG  
To:   moon%scrc@MIT-MC.ARPA
CC:   kahn@XEROX.ARPA,
      cl-object-oriented-programming@SU-AI.ARPA   
Instance Variables Re-transmission
Sorry, I was hacking on the mailing list when this message was 
sent, and so it probably went to no one. This is a re-transmission:

 ∂19-Nov-84  1517	Kahn.pa@Xerox.ARPA 	Re: Instance variables   
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 19 Nov 84  15:16:34 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 19 NOV 84 14:32:54 PST
Date: 19 Nov 84 14:35 PST
From: Kahn.pa@XEROX.ARPA
Subject: Re: Instance variables
In-reply-to: "David A. Moon" <Moon@SCRC-QUABBIN.ARPA>'s message of Mon,
 19 Nov 84 17:18 EST
To: Moon@SCRC-QUABBIN.ARPA
cc: Kahn.pa@XEROX.ARPA, cl-object-oriented-programming@SU-AI.ARPA

Sorry I wasn't too clear.


  [- Would Flavors people please discourse upon the difference between
the
    3600 and CADR implementations of flavors, with respect to the point
that
    in the CADR the variable SELF is special but in the 3600 it is
lexical.]
 --- I didn't know that self was lexical on the 3600.  The question is
how could one implement "self" without hooks into Common Lisp.  Is
"self" a hidden instance variable?  Can one bind it or set it explictly?
(This may be useful for explicit delagation or forwarding of messsages.)


 [ - Do we want instances of flavors to be usable as functions, with
FUNCALL
    and APPLY, or do we want them only to be invocable with SEND?]
--- This is related to the qustion of implementation.  Isn't it the case
that on a 3600 FUNCALL and APPLY bind "self" or is this no longer the
case?  If it is then perhaps Common Lisp needs a hook to accomplish
this.

 
  [- What parts of the mechanism for accessing instance variables
supplied
    by the proposed Common Lisp object-oriented-programming kernel
should
    be hidden, and what parts should be exposed to the portable
programmer?]
---This is an interesting question though I wasn't asking it.

  [- Would Flavors people please discourse upon the virtues and/or
uglinesses
    of their DEFUN-METHOD feature.]
---This more related to what I was asking a couple of weeks ago.
Should instance variables look like Common Lisp variables and what's
involved in making that work?  


∂19-Nov-84  1617	HANDERSON@CMU-CS-C.ARPA 	Instance variables  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Nov 84  16:14:28 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Mon 19 Nov 84 19:13:10-EST
Date: Mon, 19 Nov 1984  19:13 EST
Message-ID: <HANDERSON.12064917836.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   Kahn.pa@XEROX.ARPA
Cc:   cl-object-oriented-programming@SU-AI.ARPA
Subject: Instance variables
In-reply-to: Msg of 19 Nov 1984  12:39-EST from Kahn.pa at XEROX.ARPA


   From: Kahn.pa at XEROX.ARPA
   To:   cl-object-oriented-programming at SU-AI.ARPA
   Re:   Instance variables

   I'm seeing a consensus that we should concentrate first on defining
   hooks into Common Lisp for implementing Flavors, Loops, and the like.

I'm worried about the words "for implementing."  There will probably have to be
more than one substrate used by different object systems, and quite possibly
every major object system will have its own.  Face it, LOOPS and Flavors aren't
that similar.  There is a way we could have portable Flavors (using "symbol
macros"), but I guess Moon thought it was gross.  We won't make it part of the
specs, but interested implementors can still use it to implement the eventual
kernel.  [It doesn't have to be standard to be used.]

Methods are *implemented with* functions.  Specifying the extra arguments is
like specifying an implementation - you could ruin a perfectly wonderful
implementation that way.  Moon has pointed out that Symbolics has had three
implementations of Flavors, and each of them did message passing a different
way.  LOOPS operations ARE functions, but only because there's nothing special
about them; instance variables aren't lexical and you can't compile instance
variables into fast code.  This wins for things that change a lot, but not for
something fairly static like Flavors (which better be fast, or they won't get
used). 

What I was suggesting is that we see what kind of hooks are necessary to allow
objects of all forms to do various useful things in the system.  Some of these
would be analogous to things already accepted, like (print instance stream)
doing a (lisp::send instance 'print stream).  Others might allow objects to
masquerade as other types, such as (CAR instance) doing a (lisp::send instance
'CAR).  As I've said before, if we standardize (1) the functionality of this
lisp::send (meaning what messages and message arguments it gets used with), (2)
the way we tell objects from different systems apart, and (3) the way that
object systems provide translations of these messages into their own sends,
then that takes care of system hooks.

∂19-Nov-84  1826	Moon@SCRC-STONY-BROOK.ARPA 	Re: Instance variables
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 19 Nov 84  18:25:53 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 130100; Mon 19-Nov-84 21:27:50-EST
Date: Mon, 19 Nov 84 21:26 EST
From: "David A. Moon" <Moon@SCRC-QUABBIN.ARPA>
Subject: Re: Instance variables
To: Kahn.pa@XEROX.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: The message of 19 Nov 84 17:35-EST from Kahn.pa at XEROX
Message-ID: <841119212603.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 19 Nov 84 14:35 PST
    From: Kahn.pa@XEROX.ARPA

    Sorry I wasn't too clear.

Okay, let's try again.

      [- Would Flavors people please discourse upon the difference between
    the
	3600 and CADR implementations of flavors, with respect to the point
    that
	in the CADR the variable SELF is special but in the 3600 it is
    lexical.]
     --- I didn't know that self was lexical on the 3600.  The question is
    how could one implement "self" without hooks into Common Lisp.  Is
    "self" a hidden instance variable?  Can one bind it or set it explictly?
    (This may be useful for explicit delagation or forwarding of messsages.)

SELF is just an ordinary variable on the 3600.

     [ - Do we want instances of flavors to be usable as functions, with
    FUNCALL
	and APPLY, or do we want them only to be invocable with SEND?]
    --- This is related to the qustion of implementation.  Isn't it the case
    that on a 3600 FUNCALL and APPLY bind "self" or is this no longer the
    case?  If it is then perhaps Common Lisp needs a hook to accomplish
    this.

SELF is just an ordinary variable on the 3600.
 
      [- What parts of the mechanism for accessing instance variables
    supplied
	by the proposed Common Lisp object-oriented-programming kernel
    should
	be hidden, and what parts should be exposed to the portable
    programmer?]
    ---This is an interesting question though I wasn't asking it.

I think you should be, especially since your other questions seem to
presuppose a particular implementation of Flavors.  There are many ways
to implement Flavors, and which one is appropriate for a particular
machine depends on characteristics of that machine and on what the
implementors want to do.  That's why I believe the proposed Common Lisp
object-oriented-programming kernel should be at a higher level of
abstraction and should not commit itself to a particular mechanism, such
as binding a special variable named SELF or anything else.  It should be
possible to implement that kernel in different ways on different
systems.

I'm afraid this discussion is pretty vacuous since it's not focussed on
a specific proposal.  I wish I had time to write a treatise on the different
ways to implement Flavors, with four or five case studies, but I don't.

      [- Would Flavors people please discourse upon the virtues and/or
    uglinesses
	of their DEFUN-METHOD feature.]
    ---This more related to what I was asking a couple of weeks ago.
    Should instance variables look like Common Lisp variables and what's
    involved in making that work?  

It isn't Flavors if they don't.  Handerson's proposal discusses what
is involved in making that work.

∂03-Dec-84  1649	HANDERSON@CMU-CS-C.ARPA 	Internals Proposal  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Dec 84  16:48:40 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Mon 3 Dec 84 19:47:17-EST
Date: Mon, 3 Dec 1984  19:47 EST
Message-ID: <HANDERSON.12068594031.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   cl-object-oriented-programming@SU-AI.ARPA
Subject: Internals Proposal
In-reply-to: Msg of 19 Nov 1984  19:13-EST from Steven <Handerson>


Here is my proposal for the interface to the non-portable common part of object
systems.  This basically solves the problem of how the object can specify how
it is to be printed, etc.  This works well with standard object systems, and
can be made to work with nonstandard object systems, although not as easily.
It's mostly words, because so much of the internal stuff is
implementation-dependent; what I'm advocating is more of an approach.

DEFINITIONS

@i(Object system): any programming system with objects that are manipulated via
message passing.  I claim the standard for Common Lisp is that a message
consists of an atomic message name or key, and some message arguments (not
unlike function arguments).  An object system primitive is used to send
messages to an object.

@i(instance): an object belonging to a message system.  This term has been
appropriated to refer to objects of the instance datatype, which implements
instances of all object systems that want access to the facility this paper
describes.

@i(Sending function): a function of the instance, message name, and arguments
(in that order) that sends a message to an instance belonging to a particular
object system.  Althouigh it is fully intended that standard object systems can
use their primitive send as their sending function, this is not necessarily so.
The sending function could perform some translation of the message, and it need
not send a message to the object at all.  [This is the case if you want to hack
up an object that acts like a list and a vector, for instance.]

LISP:SEND default-handler instance message-key . message-args [FUNCTION]

I decided to snarf the name in spite of its popularity; object systems that
want to call their sending primitive SEND will have to shadow it.  Basically
this determines the sending function of the object system of the instance, and
calls it with the instance, message name and arguments.  This is primarily
intended for the lisp system to communicate with instances from arbitrary
object systems, but other applications may have need for such a facility
(especially those that would be considered language extensions, such as error
systems).  If the message is unhandled (see the section after the next), a
non-nil default handler is called with all arguments; otherwise, an error is
signalled. 

THE INSTANCE DATATYPE

All objects are implemented with the same data type, which I call @i(instance).
The internal structure of this is up to the implementation; it may vary with
the particular object systems supported by the implementation, and with how
much effort the implementors want to put into it.  Besides determining the
operations available on the object, the structure must of course eventually
point to the object system's sending function.  Since everything here is
implementation-dependent, the best that can be done is to point out which
function in an object system is the sending function, so that it can be dealt
with appropriately by the implementation.

STANDARD MESSAGES AND LISP:UNHANDLED

The lisp system communicates with objects through a standard set of messages.
This set may be pretty large, though, and probably only a few will be relevant
to a given application.  Also, if LISP::SEND comes to be used for other
applications, they will need to be able to determine whether the given object
handles the appropriate messages.

Some object systems have some seperate operation that examines the object to
see if it will handle a given message; this is not possible where most of the
"object" is a piece of code that dispatches off the message key.  Also, some
applications (or at least Lisp) have some default behavior for a give object;
it's silly to expect all objects to know what this is, especially if that
information is duplicated over multiple object systems.  I propose that the
sending function (and hence handlers) be allowed to return LISP:UNHANDLED,
which tells LISP:SEND that the message went unhandled and allows the default
action to take place.  This certainly simplifies the task of writing sending
functions that allow objects to perform in arbitrary ways to lisp primitives,
and should also simplify the task of interfacing to a nonstandard object
system.

MUCKING WITH LISP TYPES

I think it would be neat to allow objects to masquerade as primitive types.
Basically instead of signalling a wrong-type-argument error, you do a send if
it's an object, with the default action being to go ahead and signal the error.
I think some experimentation or additional thought is called for, since this
could do horrible things to the notion of the type of an object, and probably
isn't appropriate to standard architectures.  If this does happen, LISP::SEND
would be the way to do it.

EXAMPLES

Although the system was designed with making flavors:send be Flavors's sending
function, this probably won't be the case.  Best would probably be to have
flavors signal a condition when a message was unhandled - the sending function
would be something that bound that condition and then did a send (the send
would probably be inline).

Some standard messages will be:
PRIN1 stream
TYPEP type
DESCRIBE
DUMPING-FORM
  Returns a form that should create a like-behaving instance.  Used by the
  compiler to dump an instance.

∂03-Dec-84  2229	HANDERSON@CMU-CS-C.ARPA 	Internals Proposal  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Dec 84  22:29:36 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Tue 4 Dec 84 01:28:18-EST
Date: Tue, 4 Dec 1984  01:28 EST
Message-ID: <HANDERSON.12068656149.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   cl-object-oriented-programming@SU-AI.ARPA
Subject: Internals Proposal
In-reply-to: Msg of 3 Dec 1984  19:47-EST from Steven <Handerson>


I'd like to make clear that the proposal I made in the previous post only
solves the problem of how applications (and lisp itself) communicate with
arbitrary instances, assuming they subscribe to this view.  All that is needed
is to define the messages that must be understood by the instances.  For
standard object systems, the translation (done by the sending function) from
these standard messages to object system messages will be minimal; other
applications may want to use an eq hashtable somehow (which should be fast).

Applications that only deal with one kind of object should of course use the
sending primitive, rather than lisp:send.  If speed is not important and there
is a chance the code might want to be applied to objects of other systems, you
might consider using lisp:send.

Other proposals will have to deal with the separate issues of instance
variables, fast handler lookup, etc. As for whether such things are suitable
for white-pageness, I'm not sure.  The Flavors kernel (being written) deals
with instance variables, but has to tie these up with all sorts of other things
(instance environments, method inheritance and hence method dependencies, etc).
It's sort of strange in that some basic language functions are being altered by
non-white-pages forms (e.g. (setq instance-variable 3) works inside a
defmethod), but everything's hunky dory if you think of the defining forms
(e.g. defmethod) as macros that torture the code.

∂05-Dec-84  1330	Bobrow.pa@Xerox.ARPA 	Re: Internals Proposal 
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 5 Dec 84  13:29:35 PST
Received: from Riesling.ms by ArpaGateway.ms ; 05 DEC 84 13:30:11 PST
Date: 5 Dec 84 13:29 PST
From: Bobrow.pa@XEROX.ARPA
Subject: Re: Internals Proposal
In-reply-to: Steven <Handerson@CMU-CS-C.ARPA>'s message of Mon, 3 Dec 84
 19:47 EST
To: Handerson@CMU-CS-C.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA, Masinter.pa@XEROX.ARPA,
 VanMelle.pa@XEROX.ARPA,Bobrow.pa@XEROX.ARPA

Here is an alternative internal design for an object kernel, not
incompatible with that proposed by Steven Handerson.

The important difference between this design and that proposed by
Handerson is that it allows any datatype to act as a message receiver.
The LISP::SEND [[or ← as we spell it in Loops]] uses a unique identifier
of the datatype, DTID.  [[In Interlisp-D/Loops this is an 8 bit
number.]]  From DTID, one finds a class indicator [[Loops indexes into
an array]] and a MethodApplyFn, used to find and apply the function
which implements the method [[Loops encodes this in the class indicator
table]].  The functions LISP::CLASS and LISP::METHODAPPLYFN are user
handles on these two properties of a datatype. 

The class indicator is one of 
	a) a class  -- for datatypes which have the same class for all
instances
	b) T, a well known value which means that the class is found in 
	 in the first field of the datatype (a pointer field).
	c) Another atom, FN, which is a function to be applied to the object to
find its class. 
	d) NIL meaning not a receiver -- ERROR 

[[Loops uses  (e) a dotted pair, (methodApplyFn . classIndicator), if
the standard built into ← is not to be used.]]

LISP::SEND then calls the MethodApplyFn function with the class,
selector,  instance and the rest of the arguments.  It finds the method
from the class associated with the selector, and if it exists, applies
the function to the arguments (in our case including  the instance as
the first argument).  If no such method exists then the message 

MessageNotUnderstood <object><selector> <argList>
	is sent to the object.  All classes are guaranteed to have 
	some response to this message.

[[In Loops we ensure that all objects have a class, with the default
class (we call it Tofu, since it has no flavor) handling the two
messages 
	Understands <selector> 
		which standardly returns T if the class can 
		handle (understand) a message with that <selector>
	MessageNotUnderstood which fields any message not understood.  
		This causes an ERROR or BREAK if no further behavior
		is specified in a class.
	Print <stream> ... which provides a default way of printing anything]]

For instance variable lookup, the class of any method is sent a message
CompileGetValue;  the class should know how to compile instance variable
lookup code.  

For interpretation of GetValue, the class of an object is sent a
message:
	GetValue <object><ivName> ...
The class is an object itself, and it is responsible for knowing the
internal structure of instances of its type well enough to implement the
GetValue message.

∂07-Dec-84  1523	hpatlS!post%hplabs.csnet@csnet-relay.arpa 	hooks vs. subset (last try)
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 7 Dec 84  15:23:37 PST
Received: from hplabs by csnet-relay.csnet id ai14885; 7 Dec 84 18:08 EST
Received: by HP-VENUS id AA13611; Fri, 7 Dec 84 13:20:46 pst
Message-Id: <8412072120.AA13611@HP-VENUS>
Date:  7-Dec-84 13:19:18
To: cl-object-oriented-programming@su-ai.ARPA
Subject: hooks vs. subset (last try)
From: Snyder%hplabs.csnet@csnet-relay.arpa
Source-Info:  From (or Sender) name not authenticated.

[If you have already seen this message, I apologize.  Since I never received
it back from the mailing list, I am assuming it got lost somewhere along
the way and am sending it again.]

I would like to argue against the proposal that we concentrate on "defining
hooks into Common Lisp for implementing Flavors, Loops, and the like".
Although this is a worthy activity, I believe it would be more appropriate for
this group to attempt to define an extension to Common Lisp that can be used
by Common Lisp programmers who wish to program in an object-oriented style.

The charter of this group is to propose extensions to Common Lisp to support
object oriented programming.  This group was created at the Monterey meeting
because the attendees felt that the area of object-oriented programming was
the most important area in which extensions to Common Lisp are required.  (The
other popular areas were error handling, foreign function call, window
systems, and graphics.)  The attendees did not state specifically why they
thought that extending Common Lisp to support object-oriented programming was
so important.  In deciding which approach to follow, we should consider what
their (and our) desires are.  We should also attempt to consider the desires
of the larger Common Lisp community, i.e., the potential users of Common Lisp,
not just the designers and implementers.

Here are a number of possible paraphrases for the statement "I believe that
Common Lisp should be extended to support object-oriented programming".  Which
do you agree with?  How strongly?  Which do you believe the implementors of
Common Lisp agree with?  Which do you believe the Common Lisp user community
would agree with?

1. I have one or more programs written using Zetalisp flavors and I want them
   to run on any Common Lisp implementation.  (Questions: Do the programs use
   other features of Zetalisp that are not in Common Lisp?  Can such features
   be implemented using portable Common Lisp code?  How will users of your
   programs ensure that those features are supported in their systems?  Do you
   care how efficient the implementation of Zetalisp flavors is on any
   particular Common Lisp?)

2. There exist one or more programs written using Zetalisp flavors that
   I want to run on my Common Lisp.  (Questions: same as previous.)

3. I like using Zetalisp flavors and want to be able to use it when I write
   Common Lisp code.  (Questions: Do you care how efficient the implementation
   of Zetalisp flavors is on the Common Lisp you are using?  Do you care
   whether the Common Lisp programming environment you are using knows
   anything about Zetalisp flavors?)

4. I don't know much about Zetalisp flavors, but I would like to experiment
   using it on my Common Lisp system.

5. I have one or more programs written using LOOPS and I want them to run on
   any Common Lisp implementation.  (Questions: Do the programs use other
   features of Interlisp that are not in Common Lisp?  Can such features be
   implemented using portable Common Lisp code?  How will users of your
   programs ensure that those features are supported in their systems?  Do you
   care how efficient the implementation of LOOPS is on any particular Common
   Lisp?)

6. There exist one or more programs written using LOOPS that I want to run on
   my Common Lisp.  (Questions: same as previous.)

7. I like using LOOPS and want to be able to use it when I write Common Lisp
   code.  (Questions: Do you care how efficient the implementation of LOOPS is
   on the Common Lisp you are using?  Do you care whether the Common Lisp
   programming environment you are using knows anything about LOOPS?)

8. I don't know much about LOOPS, but I would like to experiment using it on
   my Common Lisp system.

9. (Similar questions for any other object-oriented Lisp extension.)

10. I want to use an object-oriented style of programming, but recognize
    that there is no consensus on the details of object-oriented programming
    constructs.  Therefore, I want to be able to use various (existing or not
    yet invented) objects systems in Common Lisp to help determine what the
    "right" one is.  Since each programmer individually chooses which objects
    system to use, it is necessary that all objects systems run concurrently
    in the same system to allow sharing of code written by others.

11. I have my own favorite objects system, but other people have different
    ideas.  The best way to get my favorite objects system to run in Common
    Lisp is to ensure that the necessary hooks are a standard feature of every
    Common Lisp implementation.

I am sure that for each of the above statements, there is some fraction of the
Common Lisp community that strongly agrees with the statement.  I agree with
some of them, too, but I don't consider them top priority.

Below is my paraphrase of the above statement. I believe this statement is one
that many (potential) users of Common Lisp would agree with, but unfortunately
they are not "here" to express an opinion.  I also speculate that many of the
attendees at the Monterey meeting that supported the creation of this
committee did so for this reason.  (How many of said people are listening to
this discussion?  I would like to know if you agree or disagree.  Perhaps we
should raise this issue in the larger Common-Lisp mailing list, or by USmail
to the Monterey attendees.)

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

12. I believe that object-oriented programming is "standard practice" for a
    large part of the programming performed by myself and my colleagues.  It
    is as fundamental in my programming as functions are in traditional Lisp
    programming.  I wouldn't want to write code any other way.  I believe that
    the object-oriented style of programming is valid and useful for both low
    level systems coding (such as implementing I/O or a window system) and
    high level applications.  For these reasons, I believe that no general
    purpose programming language (including Common Lisp) is acceptable unless
    it allows me to program in the object-oriented style.

    As a user of Common Lisp, I therefore expect to find object-oriented
    programming constructs available to me.  I expect these constructs to be
    sufficiently efficient that I am not dissuaded from using them because of
    poor performance.  I expect these constructs to be understood and
    supported by the programming environment (the Common Lisp editor and
    debugger) provided as part of my Common Lisp development system.  I expect
    these constructs to be documented in the documentation that comes with my
    Common Lisp system.  I expect any book on Common Lisp to teach me how to
    use them.  I expect the manufacturer of my Common Lisp system to
    understand these constructs; if I have a problem, I expect the
    manufacturer's representative to be able to help me.  I want any
    proficient Common Lisp programmer to be able to understand and maintain
    code written using these constructs.

    Although I have used various object-oriented languages, I understand that
    Common Lisp may not use my favorite syntax or provide my favorite feature,
    just as it differs from other Lisps in its syntax and feature set.  I
    accept these limitations in a desire to have a "common" Lisp used and
    understood by many people.

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

Thus, I do not consider object-oriented programming to be in the same category
as AI knowledge representation systems (Moon's example) or logic programming,
or any of a number of ideas that cannot yet be considered "standard practice"
for a wide range of programming tasks.  Here the Monterey attendees apparently
agree with me, as they did not endorse an immediate need for Common Lisp
extensions to support AI knowledge representation systems, logic programming,
or even multiprogramming.  (I was impressed with the ability of that large
group to focus on a small number of areas where extensions are urgently
required.)

I strongly doubt that defining only a set of hooks as a standard part of
Common Lisp will achieve the objectives of efficiency and support listed
above.  Given the finite resources available to any manufacturer (or author,
for that matter), we cannot expect a manufacturer to support a nonstandard
objects system unless it becomes a de facto standard because of widespread
demand in the market.  We certainly cannot expect manufacturers to support
multiple competing objects systems.  If Common Lisp is to have a supported
objects system, agreement must be reached on a single standard.  If we cannot
agree, who can?

Furthermore, it has yet to be shown that a set of portable low-level hooks
exists that can efficiently implement any one of the existing objects systems
on all Common Lisp implementations, much less all of them.  I also doubt very
much that multiple coexisting objects systems can be efficiently supported.
Others have expressed similar doubts: Moon: "I've had enough experience with
both of these to know that it won't be easy ..." Fahlman: "... even this is
not an easy problem for several reasons".  Handerson: "There will probably
have to be more than one substrate used by different objects systems, and
quite possibly every major object system will have its own."

Obviously there is a conflict between my claim that the object oriented style
of programming is "standard practice" and the widespread belief that years of
further experimentation will be required before the "right" object system is
designed.  My belief is that there is a common kernel that we can all agree to
(probably roughly equivalent to Smalltalk) and that defining such a kernel as
a standard component of Common Lisp is most beneficial to the Common Lisp
community at large.  If we think we can agree to a set of hooks, could we not
also agree on a set of constructs that are based on those hooks?

  -- Alan Snyder
-------

∂08-Dec-84  1555	HANDERSON@CMU-CS-C.ARPA 	Bobrow's message, Snyder's message, Flavors kernel
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Dec 84  15:55:16 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Sat 8 Dec 84 18:55:55-EST
Date: Sat, 8 Dec 1984  18:55 EST
Message-ID: <HANDERSON.12069895439.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   cl-object-oriented-programming@SU-AI.ARPA
Subject: Bobrow's message, Snyder's message, Flavors kernel
In-reply-to: Msg of 7 Dec 1984  13:19-EST from Snyder%hplabs.csnet at csnet-relay.arpa


My immediate reaction to Bobrow's message is that I'd like to keep Lisp:send
simple, and in particular not have it look like an object system (his looks
like LOOPS).  Remember that LOOPS's sending function can resend
MessageNotUnderstood to the object if it wants (etc.).

I'd prefer, for sending to lisp types, a way to select a function based on the
lisp type, which would be separate from lisp:send.  You'd do (if (instancep x)
(lisp:send x 'foo) (lisp-send x handler-object 'foo)), maybe as a macro.  I
suppose lisp:send could do this automatically if it took a handler-object, but
you might want to send to an instance and treat it like a lisp type (isn't this
great?  Yum).  Basically the handler-object acts as the "type-type" or object
system of the lisp object, so that a cons interpreted as a Flavor can act
differently from a cons interpreted as a LOOPS object.  I think this is
important, but maybe somebody else could explain why.  Somebody who knows
something about the type system can design this.

My immediate reaction to Snyder's message is that object systems (especially
the part doing inheritance) are programs written in Common Lisp, and so if you
want to supply a real object-oriented programming *environment*, you're
basically reinventing the wheel.  Yeah, maybe it's time to reexamine the
existing systems, but if we provide the necessary hooks to implement object
systems, we don't need to rush into anything.  People can use Flavors in the
present form if they can stand it.

Standardizing on some unproven system might be a mistake. I think Flavors has
survived in its present form for the same reason that Fortran (which CL hopes
to replace) has survived (cost of rewriting, people getting used to it), and we
could easily make some similar mistake with another bogus system, although I
doubt we'd come up with anything as hairy.  I feel sort of bad for propogating
a system like Flavors, but I think some of the basic concepts (NOT inheritance)
might be worth something.

Hence, my kernel tries to capture the ESSENCE of Flavors without the specifics
of inheritance, and packages the non-portable aspects of mapping tables and 
instance variables.  Anybody who's serious about this can look in
[CMU-CS-C]<HANDERSON.PUBLIC>FLAVORS-KERNEL.TXT.  Please address all specific
comments and suggestions to me, and I'll get back to you (probably next year).

∂08-Dec-84  2039	FAHLMAN@CMU-CS-C.ARPA 	hooks vs. subset (last try)
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Dec 84  20:39:27 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 8 Dec 84 23:39:44-EST
Date: Sat, 8 Dec 1984  23:39 EST
Message-ID: <FAHLMAN.12069947103.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Snyder%hplabs.csnet@CSNET-RELAY.ARPA
Cc:   cl-object-oriented-programming@SU-AI.ARPA
Subject: hooks vs. subset (last try)
In-reply-to: Msg of 7 Dec 1984  13:19-EST from Snyder%hplabs.csnet at csnet-relay.arpa


If someone could come up with a comprehensive proposal for
object-oriented programming in Common Lisp that everyone likes well
enough to adopt, that would be great.  We've got a lot of smart people
in this subgroup, most of whom have a lot of experience in
object-oriented hackery, and it is possible that such a high-level
object-oriented could emerge from our discussions.  So it's probably
worth kicking around some ideas at this level, and seeing if there's any
common ground.  It may be that we're all closer together than we think.

Then again, there are tradeoffs to be made in any object-oriented
system: efficiency vs. late binding vs. ease of implemenation vs.
presenting the user with an elegant and understandable model.  It may be
that we have irreconcilable differences in how these tradeoffs should be
made.  Perhaps there is a set of tradeoffs out there that we could all
accept, perhaps not.  My own view, admittedly based on rather limited
experience, is that flavors goes overboard on the first two of these
issues, and that elegance is butchered for very modest gains in
efficiency.  I would hate to see flavors, in its current form, become
the official standard for Common Lisp or even a de facto standard
because it is the only object-oriented system available in most
implementations.

So, while I think that we should discuss what a standard object-oriented
system for Common Lisp might be like, and that we should move toward
such a standard if possible, I think that this is a long shot.  We had
better hedge our bets by trying to come up with hooks that will support
a variety of object-oriented systems.

So much for my own view.  I should add that the second most-frequent
question (*) that people ask me about Common Lisp is what our plans are
for supporting flavors -- not object-oriented programming, but Flavors
by name.  There seem to be a lot of current and soon-to-be Zetalisp
users out there, and they see the lack of flavors as the principal
difficulty in moving between Symbolics, LMI, and (someday) TI systems
and other Common Lisp implementations.

-- Scott

* In case you are wondering, the MOST frequently asked question about
the status of Common Lisp is when there will be an implementation for
Vax/Unix.  Don't ask me, ask DEC.

∂11-Dec-84  1955	BYLANDER@RUTGERS.ARPA 	Re: hooks vs. subset (last try) 
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 11 Dec 84  19:54:47 PST
Date: 11 Dec 84 22:54:32 EST
From: Tom Bylander at Ohio State <BYLANDER@RUTGERS.ARPA>
Subject: Re: hooks vs. subset (last try)
To: Snyder%hplabs.csnet@CSNET-RELAY.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: Message from "Snyder%hplabs.csnet@csnet-relay.arpa" of 7 Dec 84 13:19:18 EST

It seems to me that there is a goal conflict corresponding to the
type of programming that people want to use an object-oriented
language/environment for.

1) System programming.  As I understand it, a major use of Flavors is
for programming of essential data types, e.g., the window system.
Such a use demands efficiency (even "modest gains" -- enough modest
gains and sooner or later they all add up to big gains) with perhaps
some cost in understandability, elegance, ease of use, and the like.

2) Research programming.  People (like me) use an object-oriented
system to gain leverage on understanding a system which represents and
perhaps eventually solves difficult problems.  This use demands
understandability, etc. since it is hard enough to thoroughly
understand the problem without the programming system getting in the
way.  This becomes especially important when more than one person is
involved in coding.

3) No programming.  Many people already have large, complex programs
in current object-oriented languages.

Example: When active values were discussed, I was amazed to hear
someone say that Flavors had active values.  Just access the variables
indirectly by message passing instead of directly by name.  From an
elegance viewpoint this is awful.  Besides being able to accidently or
malevolently bypass any intended active values, this means that in
general, the two ways of accessing a variable can have completely
different semantics.  From an efficiency viewpoint, this may be viewed
as a necessary evil because the addition of true active values would
slow down access, and involve very hairy programming in order to gain
reasonable speed.  From the no programming viewpoint, some currently
built programs probably depend on this "feature", and would have to
completely overhauled.

Can one object-oriented language satisfy both system and research
programmers? (satisfying all three views is an overconstrained
problem)

Rather than starting with a already complex system like Flavors,
Loops, or some other comprehensive proposal, I suggest that we start
from scratch, and attempt to build a consensus one piece at a time.
Any comprehensive proposal will have too many implicit assumptions and
too many features to make for a reasonable discussion.  We need to
start with something simple so that the efficiency vs. elegance issue
can be tractably approached.  I like the suggestion of starting with
something similar to Smalltalk, and when (and if) we agree on the
basics, we can move ahead to other issues.

							Tom
-------

∂13-Dec-84  1455	hpatlS!post%hplabs.csnet@csnet-relay.arpa 	de facto standards    
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 13 Dec 84  14:54:57 PST
Received: from hplabs by csnet-relay.csnet id af11777; 13 Dec 84 17:34 EST
Received: by HP-VENUS id AA14200; Thu, 13 Dec 84 10:55:19 pst
Message-Id: <8412131855.AA14200@HP-VENUS>
Date: 13-Dec-84 10:51:49
To: fahlman@cmu-cs-c.ARPA
Cc: cl-object-oriented-programming@su-ai.ARPA
Subject: de facto standards
From: Snyder%hplabs.csnet@csnet-relay.arpa
Source-Info:  From (or Sender) name not authenticated.

Scott,

I agree with you that Flavors has significant technical shortcomings, and that
it would be unfortunate if Flavors should become a de facto standard in its
present form.

However, if the demand for Flavors is as great as your message suggests, then
I fear it will be difficult to prevent Flavors from becoming a de facto
standard, despite its technical problems.  It should be clear from history
that technical merit plays a relatively minor role in the adoption of language
standards.  Fortran, for example, prospered even though its creator disowned
it and worked actively to promote an alternative.

To prevent Flavors from becoming a de facto standard, there must be an
alternative.  Simply extending Common Lisp to support alternative objects
systems (the "hooks" approach) does not by itself provide an alternative, but
merely makes it possible for an alternative to arise.

An informal process of developing and evaluating alternative objects systems
is unlikely to produce a viable alternative to Flavors in time.  While this
development and evaluation is taking place, usage of Flavors will continue to
increase.  By the time an alternative objects system could arise and gather
enough support from the Common Lisp community to be declared the "winner", it
seems quite likely that Flavors will be too well entrenched to dislodge.
Although it would be nice if there were indeed a "free marketplace of ideas"
where alternative objects systems could compete on their technical merits,
there are factors other than technical merit at work in the marketplace.

As I said before, manufacturers will not want to support multiple objects
systems.  If Flavors becomes a de facto standard, then other objects systems
will not achieve universal support, even if a set of hooks has been
standardized.  Also, if the "portable implementation" of Flavors using hooks
turns out to be inadequate (e.g., not efficient enough), then manufacturers
will be forced by market demand to provide customized implementations of
Flavors; they may well perceive this task to be more important than supporting
the standard hooks.

The best way to avoid the adoption of an inferior standard is for this
committee to develop and endorse a superior alternative.  Obviously, it is
very valuable (if not essential) for this alternative to be endorsed by the
Flavors people as well.  Such endorsement does not guarantee success, however
(witness Fortran).

  Alan
-------

∂13-Dec-84  1736	STICKLEN@RUTGERS.ARPA 	Clarificaiton Needed  
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 13 Dec 84  17:36:19 PST
Date: 13 Dec 84 20:37:29 EST
From: Jon Sticklen <STICKLEN@RUTGERS.ARPA>
Subject: Clarificaiton Needed
To: cl-object-oriented-programming@SU-AI.ARPA

Because of several recent messages in this forum, I feel that some
clarrification is needed. Alan Synder's message and Scott Fahlman's
that preceded it both seem to indicate that there is a large demand
for FLAVORS in the world, hence it may be unavoidable that the CL 
standard simply mirror what currently is FLAVORS. [Fahlman's
note argues against it, but Synder's note is what the
following is really aimed at.]

As the message from Tom Bylander tried to say, it is important that
the use of FLAVORS be factored into at least 
	a) FLAVORS used for internal system work in the ZETA LISP
	   environment and
	b) FLAVORS used for exploratory AI system building.

If it is seriously considered that this body accept FLAVORS as THE
CL object oriented programming standard, then I think it very important
that there be some documentation to support the notion that demand for
FLAVORS is overwhelming for use (b) above. Use (a) seems to me to be
important only for those in the ZETA LISP environment. [Of course, if
it is being suggested that the CL object oriented programming standard
should be made to support the ZETA LISP world, that would be another 
matter. But if that is the reason, then it should be made clear.]

The reason I raise this issue is that I'm not sure personally that there
in fact is overwhelming demand for FLAVORS for use (b). At the Austin AAAI,
for example, I visited the KNOBS (sp?) demo at the SYMBOLICS booth. There
I found that KNOBS was build in a local version of FRL, not FLAVORS as I
expected. Further, on visiting a demo of a chemical plant designing system
(whose name I don't remember) at the LMI booth, again I found that the system
was not build in FLAVORS (by that time I expected it). There were other 
similar examples.

My question then (based on just what I saw at AAAI): could it be that the
demand for FLAVORS is based on use (a) almost totally, and that use (b)
is in fact rather small? If the answer to that question is "Yes", then
the even deeper question (the one I asked myself) is "Why is that true?".

	---jon---
-------

∂15-Dec-84  1128	HANDERSON@CMU-CS-C.ARPA 	Standardization (ugh)    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 15 Dec 84  11:27:57 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Sat 15 Dec 84 14:28:34-EST
Date: Sat, 15 Dec 1984  14:28 EST
Message-ID: <HANDERSON.12071681777.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   cl-object-oriented-programming@SU-AI.ARPA
Subject: Standardization (ugh)
In-reply-to: Msg of 13 Dec 1984  20:37-EST from Jon Sticklen <STICKLEN at RUTGERS.ARPA>


Basically, I think people are going overboard with regard to standardization.
There are only two good reasons to standardize: so that people on different
machines can run the same code (as fast as reasonably possible on a given
architecture), and so that you don't waste space with 100 functions or programs
that all do the same thing.  I think that the first is the only thing we really
have to worry about; the more complicated the thing, the fewer people are going
to invent their own way of doing it.  If the number of object systems does get
to be a problem, THEN we should sit down and standardize on one, NOT BEFORE
[there will probably only be about two or three major systems in use].
Hey, why don't we standardize on silicon as the material that CL machines
should be made with?  It's certainly used a lot...

On the flip side, a REAL programming system makes it easy for you to do REAL
THINGS.  One such thing is writing your own object system if you need to,
rather than trying to force your neat abstraction into some inappropriate
scheme.  There's always the chance that a programmer will do something silly,
but all you can do is give him the best tools and examples you can and hope he
learns.  An object kernel (such as mine) satisfies reason 1 for standardization
(machine compatibility) without prematurely standardizing.

Of course, there can (and should be) a "standard Flavors" that programs can
use, so that if an implementation has the hooks (and, for worst case, I believe
the hooks can be implemented entirely in CL), then you just see that Flavors is
loaded (which sees that the hooks are?), and your program works fine.

De facto standards are different from standards frozen into the language; at
best, losing standards are ignored - at worst, they are used.  I partially feel
that programs written with losing tools probably deserve to lose, although if
nothing better is available, I suppose the authors have no choice.  I intend to
give them a choice.  

What I've put into the kernel is all the basic stuff that I think a GOOD object
system will have in common with Flavors.  The difference is mainly in how types
are "mixed" - I have no idea what the "correct" way of doing this is, but I'd
sure like to see it.  Again, my current proposal for the kernel is in

[cmu-cs-c]<handerson.public>flavors-kernel.txt

Maybe this should start being considered as a proposal for a standard.

∂15-Dec-84  1923	FAHLMAN@CMU-CS-C.ARPA 	Standardization (ugh) 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 15 Dec 84  19:23:16 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 15 Dec 84 22:23:50-EST
Date: Sat, 15 Dec 1984  22:23 EST
Message-ID: <FAHLMAN.12071768294.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   cl-object-oriented-programming@SU-AI.ARPA
Subject: Standardization (ugh)
In-reply-to: Msg of 15 Dec 1984  14:28-EST from Steven <Handerson>


I think Handerson misses the most important reasons for standardization:
stability and sharing of code across the largest possible community.  I
want to learn *ONE* object-oriented system to the point where I can use
it well, write a lot of code in it, and I want that system to be the one
that all my friends use so that I can borrow their code and they can
borrow mine.  I want this one system to be efficient enough for systems
programming (though that DOES NOT mean that I'm willing to sacrifice a
lot of elegance for that last 10%) and I want it to be clean enough so
that I don't get mad every time I use it.  I don't want to invest a lot
of effort in a system whose users don't really like it; such a system is
likely to go away as soon as something good comes along.

I think the optimal plan for this group is the following:

(1) Define a minimal set of low-level hooks that can support a
variety of object-oriented systems.

(2) Implement a portable Flavor system -- there's a demand for this,
even if we eventually move to something else as a standard.  However, we
should try not to let Flavors creep into other essential parts of the
system.

(3) Try to come up with a system that we all like better than Flavors.
This group is the right set of people to work on that, and the longer we
wait, the harder it will be to get people to switch.

(4) Implement this new system in a protable way so that we can play with
it and refine it.

(5) Maybe someday, if the new system becomes popular, accept it as a
white-pages standard.

-- Scott

∂18-Dec-84  1537	KMP@MIT-MC 	protocols/syntax, semantics of SEND, genericity 
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Dec 84  15:37:05 PST
Date: 18 December 1984 18:19-EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject:  protocols/syntax, semantics of SEND, genericity
To: CL-Object-Oriented-Programming @ SU-AI

I just got caught up on my reading of these object discussions.
I have the following immediate comments on a variety of topics
that have been discussed.

* Protocols

  I strongly agree with the suggestion made earlier that even if a particular
  message passing style (LOOPS vs FLAVORS vs ...) is not standardized upon,
  that at least a syntax should be standardized upon so that users of 
  object systems are not burdened with knowing how those systems were 
  implemented. Some of my other comments will come back to this issue.

* Syntax: SEND should be internal

  Yale Scheme (aka T) has message passing without using the SEND syntax.
  Instead, message sending uses the same syntax as function calling. eg,

   (SEND window :X-POS)       could be written (WINDOW-X-POS window)
   (SEND window :SET-X-POS 3) could be written (SETF (WINDOW-X-POS window) 3)

  This is more abstract since the user can't tell from the call how window
  is implemented.

  This is more flexible since standard utilities like ARGLIST and SETF 
  are naturally appropriate without the addition of special mechanism.

  As an accidental (but fortunate) consequence, people are discouraged from
  "recycling" message names. Lots of objects might want to handle a FOO
  message, but they should all agree that the same abstract operation is 
  being performed. It is common to see LispM programmers recycle names for
  different meanings, and later incidences of (SEND X :FOO) may be confusing
  if you don't know the type of X. In the functional situation, people are
  not as inclined to do this (partially because the compiler does number of
  argument checking, partially because the debugging info associated with
  ARGLIST would get clobbered), so if you see (FOO X), you have a better
  idea what is going on even if you don't know what X is.

* SEND = FUNCALL ?

  I believe it to have been a real mistake that (FUNCALL instance . args)
  is the same as (SEND instance . args) on the LispM. I would like to see
  instances in general not be funcallable.

  The fact that these two are confused means you can't define message 
  handlers for other lisp objects (particularly functions, since
  (SEND #'CAR ':NAME) is otherwise ambiguous with (FUNCALL #'CAR ':NAME),
  which would be an error).

* (SEND non-instance ...)

  I would like to see non-instances be able to handle messages.
  I am not so fussy about whether those messages are extensible; I just
  don't want sending a message to the thing to be an error.

  Mostly I would be happy if they answered only primitive operations like
  OPERATION-HANDLED-P, DESCRIBE, and so on.

* (primitive instance)

  I don't see any reason to make CAR send a CAR message unless we want to
  go the route of changing CL to a pure message-passing language, which
  seems a bit intense.

  Also, there are severe efficiency issues.

  But in any case, someone can always write a MESSAGE-PASSING package
  where MP:CAR called LISP:CAR on primitive lists and otherwise sent a
  message. Anyone that wanted message-passing CAR could shadow CAR with
  MP:CAR, etc. and get the effect at no cost to code that didn't want it.
  The same applies to MP:+, etc.

∂18-Dec-84  1542	KMP@MIT-MC 	Keywords as messages   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Dec 84  15:42:06 PST
Date: 18 December 1984 18:33-EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject:  Keywords as messages
To: CL-Object-Oriented-Programming @ SU-AI

Thus far, no one has suggested that message keys be keywords.  In fact,
people have been using packaged message names, which pleases me.

I wish to explicitly suggest that we encourage that message keys not be
keywords (ie, symbols on the keyword package).

If you agree with me that message sends should be syntactically
indistinguishable from function calls, then it should be obvious that
keywords would be a bad idea for messages, since I imagine people
wouldn't be happy with notation like (:CLEAR-SCREEN w).

Another reason, though, is that you cannot know at the time you make an
abstract type what whether it will ever parent other types and whether
such parentage will result in name collisions. Name collisions should
occur only when the two names are methods implementing the same protocol
(in which case, generally, both methods are doing roughly the same thing
and it matters a lot less that one of the methods is shadowed).
Keywords have no potential for scoping, so if code on two modules want
to produce flavors which handle messages named FOO, they can't both call
them :FOO without colliding for fear someone will mix the two flavors
and be able to access only one of the two methods.  I recommend that we
actively encourage that they be called JOE:FOO, BILL:FOO, etc.
In general, keywords should not be used in any context where the 
space of identifiers is not fixed and non-extensible.

Current custom in LispM and NIL flavors is to use keywords as 
message names. In some cases (particularly with generated message
names for reading/setting variables), the semantics of the provided
primitives is such that using non-keywords is likely to lead to
trouble. This is a problem that should be cleaned up before any
flavors package is adopted for CL distribution.
-kmp

∂18-Dec-84  2103	@MIT-MC:Henry%MIT-OZ@SCRC-STONY-BROOK 	Messages as objects  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Dec 84  21:03:22 PST
Received: from MIT-APIARY-5 by MIT-OZ via Chaosnet; 18 Dec 84 23:48-EST
Date: Tue, 18 Dec 84 23:48 EST
From: Henry Lieberman <Henry%MIT-OZ@SCRC-STONY-BROOK.ARPA>
Subject: Messages as objects
To: Kent M Pitman <KMP@MIT-MC.ARPA>
Cc: CL-Object-Oriented-Programming@SU-AI.ARPA
In-reply-to: The message of 18 Dec 84 18:33-EST from Kent M Pitman <KMP at MIT-MC>


This may be too radical for some of you guys, but I would like to suggest
that messages should be objects [and not just symbols]! 
So far, none of the Lisp-embedded object systems permit this, although fully
object-oriented systems like Smalltalk and Actors do. But it is worth thinking
about making sure this can eventually be done. Here are some reasons 
why [I've got more if anyone wants to discuss it]:

- Implementing "local messages", as Kent suggests, is possible this way, 
without relying on packages, keywords, etc.

- Inheritance can be used for messages, just like objects. The user might
want a message that's "just like the print message, except ..." which clearly
calls for inheritance. This makes a nice duality between messages and 
objects which receive messages.

- Sometimes, the user would like to implement one handler to handle a 
group of related message "keywords", without having to define a separate method
for each keyword. Example: An object might want to say,  "Send all messages
having to do with graphics to the graphics-manager object" where these might
include :DRAW, :ERASE, etc. One would also like to avoid burning in a specific
list of these, possibly having a procedural test as to whether a message was
a graphics message or not.

- Implementing "default behavior" for messages. Often, the behavior of
object systems is extended by introducing new messages to which every object
should have a response. Examples are :PRINT [everything should print], 
:EQUAL [everything should say whether it is equal to something else].
Traditionally, these are done by defining methods on the root of the 
inheritance hierarchy [OBJECT in Smalltalk/Loops, VANILLA-FLAVOR in Flavors]. 

The problem is that as these proliferate, the root becomes a bottleneck,
accumulating large numbers of methods. The obvious solution if messages 
are themselves objects is to give each message object a :DEFAULT method
which can be used to respond if the object does not have an idiosyncratic 
response. If an object does not have a :PRINT method, OBJECT turns around and
sends the :PRINT message a :DEFAULT message to print the object.
This is probably the most important practical reason to allow messages
to be objects.


∂19-Dec-84  1700	HANDERSON@CMU-CS-C.ARPA 	Fahlman's mail, syntax and T operations, standard send 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Dec 84  17:00:02 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Wed 19 Dec 84 19:38:43-EST
Date: Wed, 19 Dec 1984  19:37 EST
Message-ID: <HANDERSON.12072786625.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   CL-Object-Oriented-Programming@SU-AI.ARPA
Subject: Fahlman's mail, syntax and T operations, standard send
In-reply-to: Msg of 18 Dec 1984  18:19-EST from Kent M Pitman <KMP at MIT-MC>


In response to Fahlman, I feel that most object systems will represent a
small body of code (Flavors sans kernel should be one small to midsize file)
that any CL can run (with the benefit of a kernel), and that there will
typically be only three or four major ones at the most.  Xerox could support
LOOPS, Symbolics would support Flavors, etc.  It shouldn't be hard and
shouldn't cost anything to the users.

In response to KMP's mail:

What do you mean about syntax?  There are a number of ways that the
semantics can change and force the syntax to change - changing the number or
kind of parameters to something, for example.  I've suggested a common
syntax for sends - (send object message-name . message-arguments) - but all
I had to assume (phew) was that all messages have a unique identifying
(atomic) name (like a function name) and some arguments.  I'm not sure how
much you want to assume about how inheritance is done, since if we have
original Flavors AND something else, I would DEMAND that inheritance be done
differently.  Flavors is a complete and utter kludge.  Doing things the same
so that everybody can understand them would have left us in the Dark Ages.

Operations (defined with DEFOPERATION, even in T) can be macros that expand
into a send of the operation name.  An optional send function can be
supplied (to DEFOPERATION) instead of lisp:send, so you can make use of any
macroexpansions or defsubsts of the more specific sending function.

The only problem with the scheme that I've been proposing for a "standard
send" is that it may cost a function call in order to support the various
sending functions.  Still, there could be some way of representing one or more
"standard" sending functions so that no extra function call is made - indeed,
if lisp:send is an instruction, that instruction performs the standard send.
Thus the "standard" thing can be done fast without ruling out the
alternatives.  [See next message.]

∂19-Dec-84  1746	HANDERSON@CMU-CS-C.ARPA 	CAR sending a message, Liebermann's message  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Dec 84  17:46:32 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Wed 19 Dec 84 20:47:09-EST
Date: Wed, 19 Dec 1984  20:47 EST
Message-ID: <HANDERSON.12072799274.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   CL-Object-Oriented-Programming@SU-AI.ARPA
Subject: CAR sending a message, Liebermann's message


KMP: The compiler probably replaces calls to CAR with instructions, so you
want to catch the operation before it errors (at "bugout" time for
microprogrammed machines, but what about standard architectures?).  Anyway,
I think all this stuff will have to be implementation-dependent, unless
anybody can show it has some use.  I don't really see much use for sending
to primitive types, but I've proposed a way to handle it.

Henry: The model I'm operating under is that sending a message is like a
function call, but the function that gets called depends on the type of the
receiver.  It's simple and pretty common.  Anything else probably takes
longer and is probably different enough to warrant a totally different
mechanism if it's useful (like production systems).

A basic idea in Flavors is that it constructs and compiles a function that
calls the methods in some sequence, so the only speed issues are function
calls and the time it takes to recompute the "combined method" when
something changes.  Yeah, if you add something to Vanilla-flavor it has to
be added to EVERYTHING, which may take a while.

"Just like the print message, except..." usually calls for intelligence;
generalized inheritance does not exist.  Flavors doesn't go far enough in
trying to get around this- you can't even define new ways of combining
methods (and new method types).  I hope this group is open enough to change
that somebody can do it right sometime; mixing could be made much more
complex with no change in runtime speed.

∂20-Dec-84  1239	JAR@MIT-MC 	Messages as objects    
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 20 Dec 84  12:39:00 PST
Date: 20 December 1984 15:22-EST
From: Jonathan A Rees <JAR @ MIT-MC>
Subject:  Messages as objects
To: Henry @ MIT-OZ
cc: CL-Object-Oriented-Programming @ SU-AI
In-reply-to: Msg of Tue 18 Dec 84 23:48 EST from Henry Lieberman <Henry%MIT-OZ at SCRC-STONY-BROOK.ARPA>

    Date: Tue, 18 Dec 84 23:48 EST
    From: Henry Lieberman <Henry%MIT-OZ at SCRC-STONY-BROOK.ARPA>

    This may be too radical for some of you guys, but I would like to suggest
    that messages should be objects [and not just symbols]! 
    So far, none of the Lisp-embedded object systems permit this, although fully
    object-oriented systems like Smalltalk and Actors do.

None?  T's object system does exactly what you suggest, with many of the
benefits you point out (e.g.  defaults are handled pretty much as you
say).  Messages (a.k.a. "keys" or "operations") are objects which can
themselves answer messages.  There is a form which evaluates to an
anonymous message, much in the same way that a LAMBDA form evaluates to
an anonymous functions.  The usual convention is to assign them to
global variables (functions), but that's not necessary.

Jonathan

∂20-Dec-84  1647	Kahn.pa@Xerox.ARPA 	What are we up to?  
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 20 Dec 84  16:47:04 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 20 DEC 84 16:47:52 PST
Date: 20 Dec 84 16:52 PST
From: Kahn.pa@XEROX.ARPA
Subject: What are we up to?
To: CL-Object-Oriented-Programming@SU-AI.ARPA

As many have said, we can do either specify what hooks Common Lisp
should have to implement object systems, try to find a consensus on a
object  sub-language, or both.  My feeling is that it would be great if
we could come to some consensus and define a better language.  I am
pretty pesimistic however.  As we have seen recently people have rather
different ideas about pretty basic things.  I don't see a consensus on
(1) instance variables 
   -- special syntax vs. ordinary symbols
   -- semantics, when are defaults (if ever) copied down, active values,
access of IVs of other than self,...
(2) method combination
   Flavors is a both a language for describing methods and a language
for describing method combination.  I think most people that dislike
Flavors dislike the method combination language.  Handerson has proposed
generalizing method combination but will that make things better.
SmallTalk has a notion of sending a message on along to the super of the
class in which the calling method is defined.  Loops generalizes this
for multiple supers.  This clearly is very general and is easier to use
and can be as efficient.  What do people think?
(3) Name spaces
  -- should selectors share a name space with Lisp functions?
 -- should selectors be in the keyword package?

and so on.

I think we can try a little longer and see if there is some consensus on
some of these issues.  If there is then maybe we really can design some
language that improves upon Flavors, Loops, and SmallTalk.  If there
isn't then we should go back to the question of what hooks do we want.

Btw.  Objects in T is new to me.  Does someone have pointers to
references?  

∂21-Dec-84  1206	@MIT-MC:HENRY@MIT-OZ 	Messages as objects    
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 Dec 84  12:06:32 PST
Date: Fri, 21 Dec 1984  15:06 EST
Message-ID: <HENRY.12073261556.BABYL@MIT-OZ>
From: HENRY%MIT-OZ@MIT-MC.ARPA
To:   Jonathan A Rees <JAR@MIT-MC>
Cc:   CL-Object-Oriented-Programming@SU-AI.ARPA
Subject: Messages as objects
In-reply-to: Msg of 20 Dec 1984  15:22-EST from Jonathan A Rees <JAR at MIT-MC>


∂21-Dec-84  2019	@MIT-MC:Henry%MIT-OZ@SCRC-STONY-BROOK 	Messages as objects  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 Dec 84  20:19:46 PST
Received: from MIT-APIARY-9 by MIT-OZ via Chaosnet; 21 Dec 84 23:19-EST
Date: Fri, 21 Dec 84 23:20 EST
From: Henry Lieberman <Henry%MIT-OZ@SCRC-STONY-BROOK.ARPA>
Subject: Messages as objects
To: Jonathan A Rees <JAR@MIT-MC.ARPA>
Cc: Cl-Object-Oriented-programming@SU-AI.ARPA
In-reply-to: The message of 20 Dec 84 15:22-EST from Jonathan A Rees <JAR at MIT-MC>


Thank you, I stand corrected. T's approach on this issue seems much better
than the other Lisp-embedded object langauges. 


∂22-Dec-84  0054	@MIT-MC:Henry%MIT-OZ@SCRC-STONY-BROOK 	What are we up to?   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Dec 84  00:53:58 PST
Received: from MIT-APIARY-9 by MIT-OZ via Chaosnet; 21 Dec 84 23:45-EST
Date: Fri, 21 Dec 84 23:46 EST
From: Henry Lieberman <Henry%MIT-OZ@SCRC-STONY-BROOK.ARPA>
Subject: What are we up to?
To: Kahn.pa@XEROX.ARPA
Cc: CL-Object-Oriented-Programming@SU-AI.ARPA
In-reply-to: The message of 20 Dec 84 19:52-EST from Kahn.pa@XEROX.ARPA


    (1) instance variables 
       -- special syntax vs. ordinary symbols
       -- semantics, when are defaults (if ever) copied down, active values,
    access of IVs of other than self,...

I propose that the standard require that a method access its instance variables
using messages. The most important reason for this is that 
using messages hides the implementation details -- a compiler could optimize
it using variable access, but maybe another implementation could do it differently. 
Since deciding whether a property of an object is implemented by an
instance-variable or a method is often a time-space tradeoff, it's very helpful
to be able to change that decision without changing all the callers.

I use a macro (MY :VARIABLE) => (SEND SELF :VARIABLE), which looks nice, as in

(DEFOBJECT TURTLE (X Y PEN))

(DEFMETHOD (TURTLE :MOVE-TO) (NEW-X NEW-Y)
           (DRAW-LINE (MY :X) (MY :Y) NEW-X NEW-Y (MY :PEN)))

    (2) method combination
       Flavors is a both a language for describing methods and a language
    for describing method combination.  I think most people that dislike
    Flavors dislike the method combination language.  Handerson has proposed
    generalizing method combination but will that make things better.
    SmallTalk has a notion of sending a message on along to the super of the
    class in which the calling method is defined.  Loops generalizes this
    for multiple supers.  This clearly is very general and is easier to use
    and can be as efficient.  What do people think?

I agree wholeheartedly that one of the major problems with Flavors is method
combination, and strongly urge that the standard not require method combination.
Multiple supers is much better, and should be provided for. 
I think the standard should also require a mechanism called delegation, the
idea of one object forwarding a message to another object to reply in its stead.
This is subtly different from ordinary message sending, but allows you to 
combine objects in place of combining methods.
I'll wait for discussion of inheritance mechanisms to explain the details
of delegation, which is discussed in some of the actor literature, 
but I believe that delegation [along with multiple supers]
replace all plausible uses for method combination. 


∂22-Dec-84  1152	FAHLMAN@CMU-CS-C.ARPA 	What are we up to?    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 22 Dec 84  11:52:18 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 22 Dec 84 14:22:51-EST
Date: Sat, 22 Dec 1984  11:41 EST
Message-ID: <FAHLMAN.12073486289.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Henry Lieberman <Henry%MIT-OZ@MIT-MC.ARPA>
Cc:   CL-Object-Oriented-Programming@SU-AI.ARPA
Subject: What are we up to?
In-reply-to: Msg of 21 Dec 1984  23:46-EST from Henry Lieberman <Henry%MIT-OZ at SCRC-STONY-BROOK.ARPA>


Henry,

Could you expand a bit on how, and under what conditions, this use of
messages to access variables can be made efficient by the compiler?
Would we have to require that the decision about whether the slot is a
variable or method be frozen before anything referencing these slots is
compiled?  If so, the flexibility you speak of seems a bit marginal.  I
can't imagine that this idea will sell (at least for tense applications)
if it makes the inefficient form of access a near-universal default, so
getting the compiler to smash most of the cases most of the time would
seem to be crucial.

There certainly seems to be a lot of flexibility here if the efficiency
problem is not too bad.  Would this sort of thing provide "active
values" in all of the senses that people care about?  Looks to me like
it would, but I may be missing something.

If (MY :VARIABLE) turns into (SEND SELF :VARIABLE), what would SETF of
(MY :VARIABLE) turn into?  And do we really want these varaible names to
be keywords?

I personally have no strong opinion about whether access to instance
variables has to look like access to regular variables or whether there
can be some special syntax for it.  I mildly favor a special syntax, but
since my experience as a user of these systems is limited, I can't
really be sure that I would not find this to be a drag in the long run.
A special syntax would allow all sorts of things to be done with many
fewer hooks into the rest of the language, and would probably make it
much easier for mildly different object-oriented systems to co-exist.
On the other hand, I can see where people who are used to referencing
instance variables just like all other variables would view a special
syntax for this as a great leap backward, and one which they are
unwilling to take.

Perhaps if references to instance variables are only allowed within
certain lexical contexts (the bodies of certain macros and special
forms), and if the instance variables are known at the time of entry to
these forms, then the only hook we need is a "symbol macro" construct
that substitutes an arbitrary form for a symbol when it is seen within
some lexical form.  Thus, within a defmethod for the flavor BAR we can
turn any reference to instance variable FOO into (MY FOO) or whatever.
Given that single hook, we could allow some systems to use special
syntax while others continue to use (or appear to use) variable-like
sytnax.  (This is an idea that Steve Handerson has been pushing.)  Of
course there still remains the problem of what the surface-level default
should be for an object-oriented system that we can all love.

-- Scott

∂22-Dec-84  1410	HANDERSON@CMU-CS-C.ARPA 	What are we up to?  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 22 Dec 84  14:10:14 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Sat 22 Dec 84 17:10:21-EST
Date: Sat, 22 Dec 1984  17:10 EST
Message-ID: <HANDERSON.12073546233.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   Henry Lieberman <Henry%MIT-OZ@SCRC-STONY-BROOK.ARPA>
Cc:   CL-Object-Oriented-Programming@SU-AI.ARPA
Subject: What are we up to?
In-reply-to: Msg of 21 Dec 1984  23:46-EST from Henry Lieberman <Henry%MIT-OZ at SCRC-STONY-BROOK.ARPA>


There seems to be a general lack of attention to the tradeoffs of various
systems.  It sounds like T- or LOOPS- like things that do things at runtime are
generally slower than things like Flavors, since Flavors tries to do all it can
at compile time.  Also, instance variable references in Flavors are an
indirection through a mapping table; probably faster than a hashtable
reference.  Hence Flavors is preferable for low-level system programming and
apparently for all manner of hackish things, whereas higher-level programmers
probably need LOOPS or something to maintain their sanity.  Then again it's
possible that the overhead is deemed negligible, and we might as well do stuff
at runtime.  I'm not sure.

Also, the syntax of Flavors (etc.) reflects the semantics.  Since we don't want
to often change what are and aren't instance variables (so that we CAN do
things at compile time), the instance variables are made to look like normal
variables.  It's also been decided it would be neat if they acted like lexical
variables, and can be closed over.

I think it's obvious that there should be at least two major object systems;
one that does stuff at runtime (and is therefore more flexible) and another
that does stuff at compile time (and is therefore more efficient).
Furthermore, I think making an object system is more of an art than a science,
for the same reason that mathematics is; they're intellectual tools.  I
wouldn't want to force someone to use my tools, but I don't think I should be
forced to use Flavors all the time either.  I propose that we have a kernel
that supports diverse object systems, but that we continue trying to develop a
good standard (set of) systems.

RUNTIME OBJECT SYSTEM

The ability to trade off instance-variable vs. message should be user-visible,
not part of the compiler or object system.  Active values can use this.  You
can do this by remembering method code and recompiling anything referring to
that instance variable, but I'd rather there be a primitive that did it, even
if it cost some time.  This would allow methods to close over lexical variables
without making the closure-handling code worse, besides improving user response
time.

KERNELS

My kernel could be expanded to support runtime systems by adding "methods" that
would set and get an instance variable (without having to call a function).
Everything could send a message, and some messages would be (fairly) quickly
converted to instance-variable references, without the need to recompile
anything.  This would also speed up accessing instance variables of other
objects.

The object system would have to standardize the names of the messages; I'd
suggest just the iv name and the iv name prepended with SET-, interned in the
same package.

METHOD COMBINATION

My current impression is that everything regarding multiple inheritance is a
kludge, and you can't justify one kludge as compared with another except in
terms of efficiency or ease of use.  In the first, Flavors wins, and the second
depends upon who you ask.  You seem to be ignoring the fact that, although just
as POWERFUL, method-combination is "automatic" - the system, not the
programmer, writes the code.  I think it's currently done wrong, but somebody
might figure out some better way.

If we assume the best, when we combine types an artificially intelligent
machine goes and figures out what order etc. to call the methods in.  This may
take a while, and is best done at compile-time.  If you don't like that, how
about something that asks the programmer how to solve conflicts?  You want to
do that at runtime?

ENDING PLEA

Would someone please give me a reference (net address, anything) to find out
more about T's object system?  A manual would be nice.

∂22-Dec-84  1653	Bobrow.pa@Xerox.ARPA 	Instance Variable Access    
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 22 Dec 84  16:53:07 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 22 DEC 84 16:53:57 PST
Date: 22 Dec 84 16:58 PST
From: Bobrow.pa@XEROX.ARPA
Subject: Instance Variable Access
To: CL-Object-Oriented-Programming@SU-AI.ARPA
cc: Kahn.pa@XEROX.ARPA, Bobrow.pa@XEROX.ARPA 

(1) instance variables 
       -- special syntax vs. ordinary symbols
       -- semantics, when are defaults (if ever) copied down, active
values,
    access of IVs of other than self,...

It is clear to me if we are going to be able to allow different
experiments with how instance variables are implemented, then it is good
to make some syntactic distinction in their access form.  Even Henry,
who uniformly prefers message call, uses a macro to hide that;clearly
 (SEND self V1) looks uglier than (MY: V1).  
Symbol macros automatically generated from lexical scope do the same
thing, but I think lose when trying to read the code.  But surely that
can be another level of user option.

In terms of implementation, how an access is compiled (interpreted)
might be left to the class of the method.  A computed macro for (MY: V1)
could simply do (SEND: (Class self) CompileGet 'V1),  and
 (SEND: (Class self) CompilePut 'V1 valueExpression) 
for the (SETF  (MY: V1) valueExpression).  This allows not only
arbitrary experimentation between systems, but even mixing within a
single system.  It would even allow for optimization by inclusion of a
mixin class for the class, etc.

One thing that is implicit in this description is that the class of an
object better be an object as well, prepared to receive at least
CompilePut, ... messages.  This is not now true for classes in some of
the systems being discussed.  Is this important? 

∂23-Dec-84  1517	@MIT-MC:Henry%MIT-OZ@SCRC-STONY-BROOK 	What are we up to?   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 23 Dec 84  15:17:15 PST
Received: from MIT-APIARY-4 by MIT-OZ via Chaosnet; 23 Dec 84 18:17-EST
Date: Sun, 23 Dec 84 18:15 EST
From: Henry Lieberman <Henry%MIT-OZ@SCRC-STONY-BROOK.ARPA>
Subject: What are we up to?
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Cc: CL-Object-Oriented-Programming@SU-AI.ARPA
In-reply-to: <FAHLMAN.12073486289.BABYL@CMU-CS-C.ARPA>


    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

    Could you expand a bit on how, and under what conditions, this use of
    messages to access variables can be made efficient by the compiler?
    Would we have to require that the decision about whether the slot is a
    variable or method be frozen before anything referencing these slots is
    compiled?  

No, of course not. The idea is that at compile time, a reference 
(MY :VARIABLE) is compiled to a direct variable access, providing that
the class whose method this is in has a variable named :VARIABLE and
no other method named :VARIABLE. Otherwise it compiles (SEND SELF :VARIABLE).
It is possible that after this compilation the user could define a 
method with that name, making obsolete that compilation. The defining 
forms check for this and force recompilation or revert to interpreted version
for that reference. Flavors must do dynamic recompilation anyway for certain
sorts of definitional changes.

    If (MY :VARIABLE) turns into (SEND SELF :VARIABLE), what would SETF of
    (MY :VARIABLE) turn into?  

In ZetaLisp, (SETF (MY :VARIABLE) NEW-VALUE) does exactly what you would
expect, sets the value of the instance variable to NEW-VALUE.


∂09-Jan-85  1420	@MIT-MC:Henry%MIT-OZ@SCRC-RIVERSIDE 	Silence breaker   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 9 Jan 85  14:19:18 PST
Received: from MIT-APIARY-3 by MIT-OZ via Chaosnet; 9 Jan 85 17:17-EST
Date: Wed, 9 Jan 85 17:17 EST
From: Henry Lieberman <Henry%MIT-OZ@SCRC-RIVERSIDE.ARPA>
Subject: Silence breaker
To: Cl-Windows@SU-AI.ARPA, Cl-Object-Oriented-Programming@SU-AI.ARPA,
    Cl-Graphics@SU-AI.ARPA


As some of you may know, I am working on a kit for building menu-driven
graphical interfaces [such as document illustrators, circuit diagrammers,
etc.] called EzWin. The kit provides protocols for representing menu commands as
objects, mouse sensitivity and selection of graphical objects. It also tries to 
separate the functionality of commands from the interface techniques and allow
alternative interaction styles. It is at a level considerably above the "just
bits on the screen" one at which Boetje@Dec's proposal is aimed, but would be
complementary to such proposals. A wide range of interesting graphical interfaces
is easily specifiable using this approach. I hadn't designed it with a "language
standard" in mind, but perhaps standardizing things at this level as well might
productive, promoting portability of interfaces. 

I am currently preparing a paper on it for SigGraph '85. Interested people can
send me a message with US Mail address for a copy. It is too long for
transmission on this list and has many pictures.


∂13-Jan-85  1713	HANDERSON@CMU-CS-C.ARPA 	Compiling iv references efficiently, making CL object-oriented   
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 13 Jan 85  17:13:38 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Sun 13 Jan 85 20:14:34-EST
Date: Sun, 13 Jan 1985  20:14 EST
Message-ID: <HANDERSON.12079346905.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   CL-Object-Oriented-Programming@SU-AI.ARPA
Subject: Compiling iv references efficiently, making CL object-oriented


Recompiling methods could be tricky.  You don't want the lisp code for every
method hanging around- I doubt any system wastes space that freely.  What might
work is to have the method code segmented and analyzed so that the system knows
what it needs to load and compile in order to recompile the method.  This still
loses if any method was defined at runtime and closed over anything.  This is
almost what I meant by "object system" - that a given approach may imply things
beyond just a set of forms.  This particular system might imply such code
analysis and no runtime definition of methods.

Actually, this isn't so silly as it might sound.  Who's going to compile their
code inefficiently, just so some Joe Schmoe can define his own form of cons?
Who can say with assurance that you'd never want to do such a thing?  This sort
of thing allows the system (in the extreme form) to recompile parts of itself
to satisfy everyone.  This is hard to do, though, and would substantial
rewriting. 

Less extreme: I think microcoded systems could (in theory) easily change
primitive functions like CAR to first see if the object was the appropriate
lisp primitive (which they probably check already) and if not, to see if it's
an instance masquerading as a lisp primitive, and send a message if so.  Other
functions (like sort) might first see if the object responded to the LISP:SORT
message, and if so send it, but otherwise go ahead with its code and have the
primitives send messages.  The test would cost very little; the work would be
harder to justify.  The advantage is that there is one copy of code, which
either does normal lispy things or sends messages (depending), all fairly
efficiently, and nobody needs to treat any code specially.

Side note: this is why I'm for the SEND syntax in general, since you can use a
name for both an operation and a function.  In the case where the basic
operation is the function, why make up another name?  

What other messages should an operation respond to?  Why not just write
(SEND 'operation 'default-fn-name object ...)
perhaps packaged into a macro for you generic-function fans?

Clarification of a previous idea:

A good middle ground is to have the send microcode (if any) identify the method
as a SET or GET method, and do it in microcode.  [To do the SET in microcode,
you need to have the new value, which implies a system that pushes the args and
then invokes a function, like a LispM, and unlike a Perq.  The Perq would also
need something that told the call-frame-building microcode not to do anything.]
This way the system can redefine the message as a real message and we don't
have to recompile anything, and we save a function call over doing it like
other messages.  Of course, this still costs a hashtable reference over doing
it the old-fashioned way, but you wouldn't have to do everything this way.

∂19-Feb-85  0955	DDYER@USC-ISIB.ARPA 	flavors  
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 19 Feb 85  09:55:29 PST
Return-Path: <@USC-ISI.ARPA,@utah-20.arpa:hakanson%oregon-state.csnet@csnet-relay.arpa>
Received: FROM USC-ISI.ARPA BY USC-ISIB.ARPA WITH TCP ; 19 Feb 85 07:55:49 PST
Received: FROM utah-cs BY USC-ISI.ARPA WITH TCP ; 19 Feb 85 03:05:01 EST
Received: from utah-orion.ARPA by utah-cs.ARPA (4.42/4.40.2)
	id AA21355; Tue, 19 Feb 85 01:01:25 MST
Received: from UTAH-20.ARPA by utah-orion.ARPA (4.42/4.40.2)
	id AA01381; Tue, 19 Feb 85 01:00:58 MST
Message-Id: <8502190800.AA01381@utah-orion.ARPA>
Received: from csnet-relay by UTAH-20.ARPA with TCP; Tue 19 Feb 85 01:04:37-MST
Received: from oregon-state by csnet-relay.csnet id a003865; 19 Feb 85 2:54 EST
Date: Mon, 18 Feb 85 20:21:55 pst
From: Marion Hakanson <hakanson%oregon-state.csnet@csnet-relay.arpa>
Received: by Oregon-State id AA05267; Mon, 18 Feb 85 20:21:55 pst
To: psl-forum%utah-20@csnet-relay.arpa
Subject: flavors
ReSent-Date: 19 Feb 1985 09:24:24 PST
ReSent-From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
ReSent-To: cl-object-oriented-programming@SU-AI.ARPA

For my graduate project, I am considering the implementation of
a flavors package for PSL.  We currently have PSL 3.2 and I am
aware of the OBJECTS package that came with the distribution.  From
various sources I have ascertained that the existing OBJECTS package
was "thrown together" in order to facilitate development of the
EMODE editor -- it is efficient and fast, but is not a complete
implementation of flavors (it does not support inheritance, for
example).

We are about to take delivery of HP's RL1 (I think that's what
it's called) and PSL 3.3 for the HP9836, and it is my understanding
that there is something included with that system which is closer
to flavors than OBJECTS is, but that it is still not "full flavors,"
if there is such a thing.

So, that is what I've found out so far as to the availability of
flavors for PSL.  I plan to start the project by looking over the MIT
flavors package for franzlisp (part of our 4.2bsd distribution), and
by investigating the functionality of the Maryland implementation for
franzlisp as well.  I also intend to aim for compatibility with the
existing OBJECTS package.

If anyone out there has additional information that might be helpful
in this project, I'd appreciate receiving it.  I would also welcome
information about tools (or strategies) for converting other dialects
of LISP to PSL.  Has someone already done this?  Is anybody in the
process of doing it?

Now, here's a related question:  Does anyone have suggestions for
doing this project in a manner that would be compatible with future
Common LISP implementations?  How about for making it easy to convert
to Common LISP?

Well, that's enough questions, I'm sure.  As should be obvious, I am
trying to avoid reinventing anything.  And, as usual, thanks in advance.

Marion Hakanson         CSnet:  hakanson%oregon-state@csnet-relay
                        UUCP :  {hp-pcd,tektronix,tekchips}!orstcs!hakanson

∂05-Mar-85  0508	STICKLEN@RUTGERS.ARPA 	Whats Up?   
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 5 Mar 85  05:08:33 PST
Date: 5 Mar 85 08:08:00 EST
From: Jon Sticklen <STICKLEN@RUTGERS.ARPA>
Subject: Whats Up?
To: CL-Object-Oriented-Programming@SU-AI.ARPA

Has the CommonLispObjectOrientingProgrammingGroup broken into
smaller working groups of some sort? Or is there simply no current
activity? Its been many weeks since I've seen any messages in this
bboard. In short, whats up?

	---jon---
-------

∂15-Mar-85  1555	Kahn.pa@Xerox.ARPA 	Re: Whats Up?  
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 15 Mar 85  15:55:14 PST
Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 85 15:12:50 PST
Date: 15 Mar 85 15:12 PST
From: Kahn.pa@XEROX.ARPA
Subject: Re: Whats Up?
In-reply-to: Jon Sticklen <STICKLEN@RUTGERS.ARPA>'s message of 5 Mar 85
 08:08:00 EST
To: STICKLEN@RUTGERS.ARPA
cc: CL-Object-Oriented-Programming@SU-AI.ARPA

The mailing list is alive and well though perhaps sleeping.
Basically I think that there are two suggestions that are currently
active.   
(1)  Define hooks that implementors of something like Flavors or Loops
would be satisfied with,
(2)  Define a new (and presumable better) object system.

I suggest that concerned parties make some concrete proposals along
either line and we'll discuss them on this mailing list.
(The Loops group hopes to have some proposal but soon but its too
premature to send it out yet.)

I don't mean to restrict discussion to the above, if someone wants to
raise technical issues, say about multiple inheritance or active values
or something feel free to do so.  Also the discussion about what this
group should be doing is not closed, its just I suspect that most people
have already put in their 2 cents worth on that issue.

∂26-Mar-85  1725	hplabs!Snyder%hplabs.csnet@csnet-relay.arpa 	proposal  
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 26 Mar 85  17:24:57 PST
Received: from hplabs by csnet-relay.csnet id at18283; 26 Mar 85 18:05 EST
Received: by HP-VENUS id AA06465; Tue, 26 Mar 85 13:58:41 pst
Message-Id: <8503262158.AA06465@HP-VENUS>
Date: 26-Mar-85 13:56:02
To: cl-object-oriented-programming@su-ai.ARPA
Subject: proposal
From: Snyder%hplabs.csnet@csnet-relay.arpa
Source-Info:  From (or Sender) name not authenticated.

In a message to this group last October, I mentioned that I was working on a
proposal for an objects facility that supports encapsulation.  I now have a
document that describes this proposal, and I am prepared to distribute copies
of it.  The document is written in the form of an annotated language
definition, and I would like to offer it as a concrete proposal for
consideration as an extension to Common Lisp.

As I stated in the original message, this proposal will not fully satisfy
everyone's needs (not even mine!). I consider it to be a conservative design
that provides useful functionality (including multiple inheritance) without
compromising encapsulation (which is, in my opinion, one of the fundamental
principles of object oriented programming).  It is my belief that if we can
agree on *some* object-oriented extension to Common Lisp, even one that
doesn't do everything, it will be of great benefit to the Common Lisp
community.  The alternatives are the chaos of competition or the adoption of a
defacto standard with serious problems.

What I would like to find out is whether people could live with this proposal
as a starting point, or whether there are serious problems that would need to
be fixed.  Since this proposal does not attempt to be a "complete" solution, I
am not terribly interested in criticisms of the form "this proposal doesn't
let me do X", unless X is "anything useful".  However, I would be interested
in criticisms of the form "this proposal could never be extended to allow me
to do X, because of the following flaw".

To receive a copy of the proposal, send me your USmail address and I will
mail you a copy.

  Alan Snyder
  snyder%hplabs@csnet-relay
  snyder@hplabs.csnet
-------

∂02-Apr-85  1609	HANDERSON@CMU-CS-C.ARPA 	Query
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Apr 85  16:09:04 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Tue 2 Apr 85 19:08:56-EST
Date: Tue, 2 Apr 1985  19:08 EST
Message-ID: <HANDERSON.12100044361.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   cl-object-oriented-programming@SU-AI.ARPA
Subject: Query


Has anyone heard of a language called QLOGO?  Someone claimed that it has an
elegant approach to multiple inheritance.  I for one would be interested in
seeing a manual.

-- Steve

∂02-Apr-85  1827	Moon@SCRC-STONY-BROOK.ARPA 	QLOGO  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 Apr 85  18:27:31 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 207783; Tue 2-Apr-85 21:11:59-EST
Date: Tue, 2 Apr 85 21:12 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: QLOGO
To: Steven <Handerson@CMU-CS-C.ARPA>
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: <HANDERSON.12100044361.BABYL@CMU-CS-C.ARPA>
Message-ID: <850402211243.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

Contact GLD%MIT-OZ@MIT-MC.

∂02-Apr-85  1937	GJC@MIT-MC 	QLOGO?  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Apr 85  19:35:01 PST
Date: 2 April 1985 22:29-EST
From: George J. Carrette <GJC @ MIT-MC>
Subject: QLOGO?
To: cl-object-oriented-programming @ SU-AI

Sigh, I suppose its about time for me to take the plunge and get onto
CL-OBJECT-ORIENTED-PROGRAMMING. QLOGO is an object oriented extension
to LOGO, in the sense that it comes from a
Papert/Mit/LogoLab[defunct]/Atari-Cambridge-Research[defunct] school
of thought.  Related ideas are embodied in an OBLISP implementation
now in the polishing stage. A key thing here is a view of the variable
lookup mechanism, or rather that you can get "message passing" effects
simply by generalizing the variable binding and lookup mechanism in
certain directions, without the need to introduce an orthogonal notion
of TYPEness explicitely, nor of a message-namespace (which ends up
being rather flat in usage of extant flavor implementations).

Maybe after a couple weeks on this mailing list I can get enough
of an idea of what the scope and purpose of the discussions are
to give a more detailed answer that isnt too detailed
(in the sense that it would either be boring or give away too
many useful unpublished tricks).

-gjc

∂07-Apr-85  0953	fischer@ru-opal 	MI reference 
Received: from OPAL.ARPA by SU-AI.ARPA with TCP; 7 Apr 85  09:53:03 PST
Received: by ru-opal.ARPA; Sun, 7 Apr 85 13:26:08 est
Date: Sun, 7 Apr 85 13:26:08 est
From: fischer@ru-opal (Ron Fischer)
Message-Id: <8504071826.AA16944@ru-opal.ARPA>
To: cl-object-oriented-programming@su-ai
Subject: MI reference

Touretzky, D. S. "The Mathematics of Inheritance Systems" Doctoral
dissertation, Computer Science Department, Carnegie Mellon University,
Pittsburgh, PA, 1984.

(ron)

∂22-Apr-85  1736	Kahn.pa@Xerox.ARPA 	Synder's proposal   
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 22 Apr 85  17:35:44 PST
Received: from Semillon.ms by ArpaGateway.ms ; 22 APR 85 17:28:34 PST
Date: 22 Apr 85 17:28 PST
From: Kahn.pa@Xerox.ARPA
Subject: Synder's proposal
To:cl-object-oriented-programming@SU-AI.ARPA


We've been too quiet lately.  Alan Snyder almost a month ago made
available his "Object-Oriented Programming for Common Lisp" report and
there has been no discussion.  If people are serious about objects in
Common Lisp then we should carefully read and discuss detailed
well-written proposals such as this one.

I'll try to start off a discussion with some of my comments.

The most unique part of  the proposal is the idea that a  method of a
type (aka class or flavor) can directly access only its own instance
variables and methods and must do something special to get inheritance.
This is motivated by "encapsulation" which I understand as making
class/type/flavor definitions more independent of their supers.
This view does not appeal to me because I find myself frequently moving
ivs and methods up and down the hierarchy as I discover that the method
or iv is more or less general than I  originally thought.  I don't think
of subclasses as being so indpendent of their supers.  In some sense the
use of "call-method" and "apply-method" which explictly name the class
where the system should find a method to make subclasses even more
dependent upon the details of the supers.  One must know which class
will be fielding the  equivalent of "send super" while Loops/SmallTalk
discovers that at run time and Flavors discovers that at compile time.
I think  Synder's scheme makes it hard to write a  module which
specialises some classes such that those classes can be independently
re-structured (e.g.  methods moved up or down the hierarchy, or a class
broken up into a few supers/mixins).  

One thing in favor of Synder's system (which he fails to mention) is
that  IV lookups can be compiled very efficiently without the use of
permutation tables as in Flavors.   

I think of Synder's scheme as a system that gives lots of support for
implementing inheritance by sending messages to implicit parts which
correspond to instances of each immediate super.  For example, take his
example of a "child" class with "parent1", "parent2", and "parent3"
supers.  One can rephrase the example in SmallTalk/Loops/Flavor terms as
child having 3 "hidden" ivs initialized as initialized instances of
"parent1", "parent2" and "parent3".   Then certain messages are received
by a "child" which in turn forward the messages to the appropriate
hidden iv.  Is this a reasonable way to view the proposal?

Comments?
  -ken kahn

∂08-May-85  1648	hplabs!Snyder%hplabs.csnet@csnet-relay.arpa 	Re: Snyder's proposal    
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 8 May 85  16:48:07 PDT
Received: from hplabs by csnet-relay.csnet id ab17411; 8 May 85 19:39 EDT
Received: by HP-VENUS id AA03731; Wed, 8 May 85 14:37:01 pdt
Message-Id: <8505082137.AA03731@HP-VENUS>
Date:  8-May-85 14:32:18
To: cl-object-oriented-programming@su-ai.ARPA
Subject: Re: Snyder's proposal
From: Snyder%hplabs.csnet@csnet-relay.arpa
Source-Info:  From (or Sender) name not authenticated.

> We've been too quiet lately.

I agree.  We still are.

> In some sense the
> use of "call-method" and "apply-method" which explictly name the class
> where the system should find a method to make subclasses even more
> dependent upon the details of the supers.  One must know which class
> will be fielding the  equivalent of "send super" while Loops/SmallTalk
> discovers that at run time and Flavors discovers that at compile time.

One possibility is to allow the name of the superclass to be omitted, and
allow the system to figure out which superclass's method to invoke.  To be
consistent with the rest of the proposal, I would make this determination at
the time the subclass is defined.  (The general philosophy is that the
language definition does not bend over backwards to support incremental
development, but of course a "programming environment" is free to do so.)

> One thing in favor of Snyder's system (which he fails to mention) is
> that  IV lookups can be compiled very efficiently without the use of
> permutation tables as in Flavors.   

That is correct.

> I think of Snyder's scheme as a system that gives lots of support for
> implementing inheritance by sending messages to implicit parts which
> correspond to instances of each immediate super.  For example, take his
> example of a "child" class with "parent1", "parent2", and "parent3"
> supers.  One can rephrase the example in SmallTalk/Loops/Flavor terms as
> child having 3 "hidden" ivs initialized as initialized instances of
> "parent1", "parent2" and "parent3".   Then certain messages are received
> by a "child" which in turn forward the messages to the appropriate
> hidden iv.  Is this a reasonable way to view the proposal?

That is an accurate model.
-------

∂11-Jul-85  2148	Kahn.pa@Xerox.ARPA 	Object-oriented programming & Common Lisp meeting 
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 11 Jul 85  21:48:04 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 11 JUL 85 21:48:44 PDT
Date: 11 Jul 85 21:49 PDT
From: Kahn.pa@Xerox.ARPA
Subject: Object-oriented programming & Common Lisp meeting
To: cl-object-oriented-programming@su-ai.ARPA
cc: Kahn.pa@Xerox.ARPA
Message-ID: <850711-214844-2019@Xerox>

It has been suggested that those of us that are at IJCAI next month meet
to talk about various proposals for object-oriented programming in
Common Lisp that are forming.  LMI expressed interest in talking about
Object Lisp, Xerox plans to have a proposal public by then, HP I would
guess would like to argue for their proposal, and rumor has it that
Symbolics is working on something.   Perhaps there are others.   I have
contacted IJCAI about getting a room on Thursday afternoon (free on the
schedule) and details are forthcoming.  I suggest that we plan on having
short 5-15 minute presentations per proposal and spend most of the time
talking about them.  Those who want to talk about a proposal should
contact me at the latest the week before IJCAI.  I think we should keep
this an open meeting.  The purpose is the bat around ideas -- not to
decide anything.

Does this sound reasonable?  Any objections?

∂12-Jul-85  1014	AS%hp-hulk.csnet@csnet-relay.arpa 	Re: Object-oriented programming & Common Lisp meeting  
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 12 Jul 85  10:14:18 PDT
Received: from hplabs by csnet-relay.csnet id ba05363; 12 Jul 85 13:05 EDT
Received: by HP-VENUS id AA26548; Fri, 12 Jul 85 08:18:15 pdt
Message-Id: <8507121518.AA26548@HP-VENUS>
Date: Fri 12 Jul 85 08:19:19-PDT
From: Alan Snyder <AS%hplabs.csnet@csnet-relay.arpa>
Subject: Re: Object-oriented programming & Common Lisp meeting
To: cl-object-oriented-programming@su-ai.ARPA
In-Reply-To: Message from "Kahn.pa@XEROX@HP-VENUS" of Thu 11 Jul 85 21:49:00-PDT
Source-Info:  From (or Sender) name not authenticated.

Sounds like a good idea.  Would it be possible to distribute
other proposals before IJCAI so that we could read them ahead of
time?
  Alan
-------

∂12-Jul-85  1044	Moon@SCRC-STONY-BROOK.ARPA 	Object-oriented programming & Common Lisp meeting   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 12 Jul 85  10:44:37 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 273999; Fri 12-Jul-85 13:41:39-EDT
Date: Fri, 12 Jul 85 13:41 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Object-oriented programming & Common Lisp meeting
To: Kahn.pa@XEROX.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: <850711-214844-2019@Xerox>
Message-ID: <850712134153.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 11 Jul 85 21:49 PDT
    From: Kahn.pa@Xerox.ARPA

    It has been suggested that those of us that are at IJCAI next month meet
    to talk about various proposals for object-oriented programming in
    Common Lisp that are forming.

It's fine with me if you want to have a meeting, but I will not be attending
IJCAI this year.  I don't know whether anyone else at Symbolics with an
interest in object-oriented programming will be doing so; I'll ask.

∂12-Jul-85  1223	DDYER@SCRC-STONY-BROOK.ARPA 	Object-oriented programming & Common Lisp meeting  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 12 Jul 85  12:22:50 PDT
Received: from WHITE.SWW.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 274157; Fri 12-Jul-85 15:21:38-EDT
Received: from SWW-PURPLE by SWW-WHITE via CHAOS with CHAOS-MAIL id 123506; Fri 12-Jul-85 12:26:09-PDT
Date: Fri, 12 Jul 85 12:24 PDT
From: DDYER@SCRC-RIVERSIDE.ARPA
Subject: Object-oriented programming & Common Lisp meeting
To: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>, Kahn.pa@XEROX.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA
Fcc: W:>ddyer>mail.sent
In-Reply-To: <850712134153.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <850712122426.2.DDYER@PURPLE.SWW.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI

    Date: Fri, 12 Jul 85 13:41 EDT
    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>

	Date: 11 Jul 85 21:49 PDT
	From: Kahn.pa@Xerox.ARPA

	It has been suggested that those of us that are at IJCAI next month meet
	to talk about various proposals for object-oriented programming in
	Common Lisp that are forming.

    It's fine with me if you want to have a meeting, but I will not be attending
    IJCAI this year.  I don't know whether anyone else at Symbolics with an
    interest in object-oriented programming will be doing so; I'll ask.

I'm definitely interested.

∂12-Jul-85  2136	Kahn.pa@Xerox.ARPA 	Written proposals   
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 12 Jul 85  21:36:35 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 12 JUL 85 20:46:37 PDT
Date: 12 Jul 85 20:46 PDT
From: Kahn.pa@Xerox.ARPA
Subject:Written proposals
To: cl-object-oriented-programming@su-ai.ARPA
Message-ID: <850712-204637-1201@Xerox>

I've gotten pretty positive responses to the idea of meeting at IJCAI.
I've been asked about distribution of written proposals.  I think that
the simpliest way to take care of that is for those with written
proposals to advertise the fact on this mailing list and send out copies
to those responding.  I would also recommend such people bring extra
copies to IJCAI.

Here at Xerox we have a draft that we had hoped would be ready this
week.  Will send out a message when its ready.
     ----- End Forwarded Messages -----

∂13-Jul-85  1853	HIC@SCRC-STONY-BROOK.ARPA 	Object-oriented programming & Common Lisp meeting    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Jul 85  18:53:12 PDT
Received: from DEERFIELD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 274734; Sat 13-Jul-85 21:51:58-EDT
Date: Sat, 13 Jul 85 21:53 EDT
From: Howard I. Cannon <HIC@SCRC-STONY-BROOK.ARPA>
Subject: Object-oriented programming & Common Lisp meeting
To: DDYER@SCRC-RIVERSIDE.ARPA, Moon@SCRC-STONY-BROOK.ARPA,
    Kahn.pa@XEROX.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: <850712122426.2.DDYER@PURPLE.SWW.Symbolics.COM>
Message-ID: <850713215333.7.HIC@DEERFIELD.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI

    Received: from SCRC-STONY-BROOK by SWW-WHITE via CHAOS with CHAOS-MAIL id 123513; Fri 12-Jul-85 12:36:13-PDT
    Received: from MIT-MC.ARPA by SCRC-STONY-BROOK.ARPA via INTERNET with SMTP id 274171; 12 Jul 85 15:31:32-EDT
    Received: from SU-AI.ARPA by MIT-MC.ARPA.ARPA; 12 Jul 85 15:31:15 EDT
    Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 12 Jul 85  12:22:50 PDT
    Received: from WHITE.SWW.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 274157; Fri 12-Jul-85 15:21:38-EDT
    Received: from SWW-PURPLE by SWW-WHITE via CHAOS with CHAOS-MAIL id 123506; Fri 12-Jul-85 12:26:09-PDT
    Date: Fri, 12 Jul 85 12:24 PDT
    From: DDYER@SCRC-RIVERSIDE.ARPA
    Subject: Object-oriented programming & Common Lisp meeting
    To: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>, Kahn.pa@XEROX.ARPA
    cc: cl-object-oriented-programming@SU-AI.ARPA
    Fcc: W:>ddyer>mail.sent
    In-Reply-To: <850712134153.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
    Message-ID: <850712122426.2.DDYER@PURPLE.SWW.Symbolics.COM>
    Fonts: CPTFONT, CPTFONTB, CPTFONTI

	Date: Fri, 12 Jul 85 13:41 EDT
	From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>

	    Date: 11 Jul 85 21:49 PDT
	    From: Kahn.pa@Xerox.ARPA

	    It has been suggested that those of us that are at IJCAI next month meet
	    to talk about various proposals for object-oriented programming in
	    Common Lisp that are forming.

	It's fine with me if you want to have a meeting, but I will not be attending
	IJCAI this year.  I don't know whether anyone else at Symbolics with an
	interest in object-oriented programming will be doing so; I'll ask.

    I'm definitely interested.

I would try to make a meeting, but I have many prior commitments during
that time.

∂29-Jul-85  1906	Stefik.pa@Xerox.ARPA 	Xerox proposal to be mailed 
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 29 Jul 85  19:06:46 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 29 JUL 85 19:07:32 PDT
Date: 29 Jul 85 19:07 PDT
From: Stefik.pa@Xerox.ARPA
Subject: Xerox proposal to be mailed
To: CL-Object-Oriented-Programming@SU-AI.ARPA
cc: Bobrow.pa@Xerox.ARPA, Gregor.pa@Xerox.ARPA, Kahn.pa@Xerox.ARPA,
 Masinter.pa@Xerox.ARPA, Stefik.pa@Xerox.ARPA
Message-ID: <850729-190732-3151@Xerox>

In keeping with Ken's suggestion, we are preparing a proposal for an
objects standard for presentation and discussion at the informal meeting
at IJCAI. It's being called "Common Loops" for "Common Lisp
Object-Oriented Programming System."

We will bring copies of the proposal to IJCAI.  We will also mail out
copies on about August 8 to anyone who sends us their U.S. Mail address.

Mark

PS.  No definite time/location yet for the IJCAI meeting.  In Ken's
absence I've been in contact withPhyllis O'Neal, but she was behind in
completing her arrangements as of Friday.


∂30-Jul-85  1233	janel%tekchips%tektronix.csnet@csnet-relay.arpa 	Re: Xerox proposal to be mailed
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 30 Jul 85  12:31:13 PDT
Received: from tektronix by csnet-relay.csnet id ad17458; 30 Jul 85 15:15 EDT
From: Jane Laursen <janel%tekchips%tektronix.csnet@csnet-relay.arpa>
To: tektronix!stefik.pa%xerox.arpa@SU-AI.ARPA
Cc: CL-Object-Oriented-Programming@SU-AI.ARPA, Bobrow.pa@XEROX.ARPA, 
    Gregor.pa@XEROX.ARPA, Kahn.pa@XEROX.ARPA
Received: from tekchips by tektronix with smtp ; 30 Jul 85 08:44:48 PDT
Date: Tuesday, 30 Jul 85 08:37:25 PDT
Subject: Re: Xerox proposal to be mailed
In-reply-to: Your message of 29 Jul 85 19:07 PDT.,             <850729-190732-3151@Xerox>


Would you please send me a copy of the Common Loops proposal?

                                    Thanks,

                                    Jane Laursen
                                    Tektronix Inc.
				    Del. St. 63-393
   				    P.O. Box 1000
                                    Wilsonville, OR  97070





∂05-Aug-85  1602	Kahn.pa@Xerox.ARPA 	IJCAI meeting (time and place)
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 5 Aug 85  16:01:40 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 05 AUG 85 14:50:15 PDT
Date: 5 Aug 85 14:46 PDT
From: Kahn.pa@Xerox.ARPA
Subject: IJCAI meeting (time and place)
To: cl-object-oriented-programming@su-ai.ARPA
Message-ID: <850805-145015-1282@Xerox>

We have the Math Sciences auditorium booked from 4 to 6pm on Thursday.
Those that want to present proposals should get in touch with me.  See
you all there.

∂12-Aug-85  1519	Masinter.pa@Xerox.ARPA 	CommonLoops paper mailed  
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 12 Aug 85  15:19:02 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 12 AUG 85 15:20:16 PDT
Date: 12 Aug 85 15:21 PDT
From: Masinter.pa@Xerox.ARPA
Subject: CommonLoops paper mailed
To: CL-Object-Oriented-Programming@SU-AI.ARPA
cc: MGardner.PA@Xerox.ARPA
Reply-to: MGardner.PA@Xerox.ARPA
Message-ID: <850812-152016-3307@Xerox>

The CommonLoops paper has been sent, express mail, to those of you who
sent your address. If you have not, and would like a copy, please send
your complete name and mailing address to Mimi Gardner
(MGardner.PA@Xerox).  Copies will be sent express mail to those who need
a chance to read it before IJCAI. 

∂14-Aug-85  0859	gls@THINK-AQUINAS.ARPA 	Common LOOPS    
Received: from THINK.COM by SU-AI.ARPA with TCP; 14 Aug 85  08:58:49 PDT
Received: from quentin by GODOT.THINK.COM via CHAOS; Wed, 14 Aug 85 11:59:06 edt
Date: Wed, 14 Aug 85 11:59 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Common LOOPS
To: cl-object-oriented-programming@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <850814115912.8.GLS@QUENTIN.THINK.COM>

I am delighted to learn that there will be a meeting during IJCAI-85 to discuss
object-oriented programming in Common Lisp.  I am not planning to attend IJCAI,
but I trust that those who do attend will have a productive meeting.

Yesterday I received in the mail a draft specification of Common LOOPS, by
Bobrow, Kahn, Kiczales, Masinter, Stefik, and Zdybel.  This is, as far as I
know, the first major polished proposal to result from any of the subcommittees
formed last year at Monterey.  We should all be grateful to these authors for
the work they have obviously put into preparing this proposal, including doing
an implementation up front and comparing it to other object-oriented Lisp
programming systems.  This is not to say that I endorse every detail of the
entire proposal in its current drafty state (for I am not sure I yet understand
all of the implications), but it is very encouraging that there will be a
concrete, demonstrably implementable proposal to discuss at the IJCAI meeting.


I have a couple of specific technical comments that you may want to take into
account:

(1) Section I.G mentions the waffling of the Common Lisp manual on the question
of exactly what TYPE-OF returns.  The motivation for the waffling was primarily
to avoid the question of whether TYPE-OF should return implementation-dependent
or extremely specialized subtypes.  Should (TYPE-OF 3) be INTEGER?  FIXNUM?
(INTEGER 3 3)?  (INTEGER 0 NIL)?  I couldn't get a consensus of what the
correct thing to do was, so I took the easy way out there by being
noncommittal.  Perhaps this was not a good thing for me to have done.


(2) Section II.I presents an example that purports to be an anomalous case, but
I find it quite clear-cut.  The second method for FOO clearly cannot accept
three arguments under any circumstances, and therefore is not eligible to
handle a three-argument call.

I think that the semantics of &optional and &rest parameters are easily dealt
with by viewing them as an abbreviation mechanism for multiple methods.

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

Similarly,

	(defmethod foo (x &rest y) body)

is simply an abbreviation for

	(defmethod foo (x) (let ((y (list))) body))
	(defmethod foo (x y1) (let ((y (list y1))) body))
	(defmethod foo (x y1 y2) (let ((y (list y1 y2))) body))
	(defmethod foo (x y1 y2 y3) (let ((y (list y1 y2 y3))) body))
	...

I would suggest that a type specifier attached to a &rest parameter
be construed as applying to EACH of the arguments encompassed by that
parameter.

Keyword parameters can be handled in much the same manner, although
the question of which is to the left of another in multiple definitions
(for purposes of establishing method precedence) is problematical.

--Guy

∂14-Aug-85  1316	Gregor.pa@Xerox.ARPA 	Type specification of &optional arguments. 
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 14 Aug 85  13:15:53 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 14 AUG 85 13:16:21 PDT
Date: 14 Aug 85 13:16 PDT
From: Gregor.pa@Xerox.ARPA
Subject: Type specification of &optional arguments.
In-reply-to: Guy Steele <gls@THINK-AQUINAS.ARPA>'s message of Wed, 14
 Aug 85 11:59 EDT
To: gls@THINK-AQUINAS.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA
Message-ID: <850814-131621-5356@Xerox>

The main problem with specialization by number of arguments is that it
adds complexity to the method-lookup rules. We shied away from more
complicated method-lookup rules in the kernel because we weren't sure
what it would be like to program with them.  In particular,  we haven't
actually programmed with type specification of &optional arguments so we
can't say how hard it is (for the programmer) to figure out which
methods get inherited and how.

There are no problems implementing type specification of &optional
arguments.  Once we have a little more experience programming with type
specification of &optional arguments and can say what its like with more
assurance I think we will suggest that the kernel be extended to include
it.

∂14-Aug-85  1339	kessler%utah-orion@utah-cs.arpa 	CommonLoops 
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 14 Aug 85  13:38:05 PDT
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
	id AA14723; Wed, 14 Aug 85 14:40:15 MDT
Received: by utah-orion.ARPA (5.5/4.40.2)
	id AA10188; Wed, 14 Aug 85 14:40:09 MDT
Date: Wed, 14 Aug 85 14:40:09 MDT
From: kessler%utah-orion@utah-cs.arpa (Robert Kessler)
Message-Id: <8508142040.AA10188@utah-orion.ARPA>
To: cl-object-oriented-programming@su-ai.arpa
Subject: CommonLoops

My biggest concern with the proposal is that its trying to be all things
to all people.  It tries to support Loops, Flavors and everything else,
all in one standard.  Sure, if I were a Flavors person I could implement
something that looks like Flavors and would be perfectly happy.  However,
when I (or someone else) tries to port my software to another machine, I
have to bring along all of the baggage that defines my particular version
of the flavors.  It seems like there could be conflicts trying to
incorporate two different software packages that used different "extensions".
One of the nice things about Common Lisp is that everything and the kitchen
sink is present and thus a user knows what to expect as far as functionality,
argument order, etc. (of course its also a pain for those of us who want small,
tight Lisps, but that's a different story).  I think that it would be better
to stick to one version, whether its Loops, Flavors or some derivative (like
the HP proposal).

Bob.

∂14-Aug-85  1605	Gregor.pa@Xerox.ARPA 	Re: CommonLoops   
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 14 Aug 85  16:04:48 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 14 AUG 85 15:43:41 PDT
Date: 14 Aug 85 15:43 PDT
From: Gregor.pa@Xerox.ARPA
Subject: Re: CommonLoops
In-reply-to: kessler%utah-orion@utah-cs.arpa (Robert Kessler)'s message
 of Wed, 14 Aug 85 14:40:09 MDT
To: kessler%utah-orion@utah-cs.arpa
cc: cl-object-oriented-programming@su-ai.arpa
Message-ID: <850814-154341-5563@Xerox>

The point that you are raising is a good one, its one that we have
worried about and one for which I think we have an answer.  The answer
is in 3 parts.

1.
Most people would do all of their programming using kernel CommonLoops
and the "class" metaclass.  The kernel and the "class" metaclass are
designed to merge the best aspects of exisiting  object-oriented
languages into a single coherent framework.  With some community
discussion the kernel and "class" metaclass should become even more
"what is needed almost all the time".

2.
Because CommonLoops provides support for implementing different object
languages it would be easier for a large group of people to try out new
experimental ideas.

3.
The compatability metaclasses (loops, flavor etc.) would be more for
supporting old code than they would be for writing new code.  But
someone who really needed a different object paradigm to implement a
system they were distributing could implement it using CommonLoops as a
base and be confident that their system would run fast in another Common
Lisp implementation.

In summary, there wouldn't be a morass of different flavor classes
floating around, nor would there be a morass of different code styles
floating around.  Most people would program in kernel CommonLoops.  But
for the few people who need to use a different paradigm, and for the
support of exisiting code, CommonLoops provides a base for implementing
different object systems.

∂15-Aug-85  0710	FAHLMAN@CMU-CS-C.ARPA 	CommonLoops 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 15 Aug 85  07:10:48 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 15 Aug 85 10:12:05-EDT
Date: Thu, 15 Aug 1985  10:11 EDT
Message-ID: <FAHLMAN.12135325145.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   kessler%utah-orion@λutah-cs.arpa (Robert Kessler)λ
Cc:   cl-object-oriented-programming@SU-AI.ARPA
Subject: CommonLoops
In-reply-to: Msg of 14 Aug 1985  16:40-EDT from kessler%utah-orion at utah-cs.arpa (Robert Kessler)


I don't see the CommonLoops proposal as trying to be all things to all
people.  The basic CommonLoops langauge, with some of the proposed
extensions, looks to me (as a relative novice in this game) like just
the right level for most of the things I want to do.  It's clean and
easy to understand, and it has the property that you don't run into any
of the complexity until and unless you need it.  The lack of this
property was the biggest problem with Flavors, in my opinion.  I could
easily imagine doing almost all my work in base-level CommonLoops and
using it as the teaching vehicle for students new to Lisp and objects.

If we went mostly with the CommonLoops proposal, then the fact that it
has the hooks to accomodate the existence of other existing paradigms
(or ones as yet uninvented) looks to me like a pure benefit.  I grant
you that if people use the extension hooks to implement a dozen
different object-oriented paradigms, and if these are all in heavy use
by the community at the same time, then we've got a very confusing
situation (though no worse than if there are a dozen completely separate
paradigms implemented by totally separate mechanisms on separate
machines).  But I suspect that very quickly we will see a world in which
most of the community is using basic CommonLoops, a few groups are
sticking with Flavors, and there are one or two small groups
experimenting with new extensions.  That looks to me like about as
monolithic a world as we can hope for in this rather unsettled area, and
achieving that much order would be a big step forward.

-- Scott

∂15-Aug-85  1332	Kahn.pa@Xerox.ARPA 	[GLD%MIT-OZ@MIT-MC.ARPA: ObjectLisp]    
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 15 Aug 85  13:25:40 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 15 AUG 85 13:26:43 PDT
Date: 15 Aug 85 13:26 PDT
From: Kahn.pa@Xerox.ARPA
Subject: [GLD%MIT-OZ@MIT-MC.ARPA: ObjectLisp]
To: cl-object-oriented-programming@su-ai.ARPA
Message-ID: <850815-132643-6425@Xerox>


I just received the following message from Gary Drescher.
It seems that there will be three proposals to discuss on the meeting on
Thursday (Math Sciences auditorium from 4 to 6pm).  HP, Xerox, and the
following one (LMI):

     ----- Begin Forwarded Messages -----

Return-Path: <@MIT-MC.ARPA:GLD@MIT-OZ>
Received: from MIT-MC.ARPA by Xerox.ARPA ; 15 AUG 85 12:54:01 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 15 AUG 85  15:51:03
EDT
Date: Thu, 15 Aug 85 15:52 EDT
Message-ID: <GLD.12135387162.BABYL@MIT-OZ>
From: GLD%MIT-OZ@MIT-MC.ARPA
To: Kahn.pa
Subject: ObjectLisp
In-reply-to: Msg of 15 Aug 1985  13:22-EDT from GLD


Hi Ken.  The folks at LMI tell me I should send my current ObjectLisp
Manual
to the appropriate CommonLisp mailing list, whose name I've
unfortunately
misplaced.  So I'm mailing it to you instead; could you be so kind as to
forward it to the list?

I'll be at IJCAI on the 21st & 22nd; see you then.

Thanks,
Gary

mit-oz:<gld.obl>manual.tex   (LaTex format)

%       -*- Mode:Text -*-
\documentstyle[draft]{article}
\setlength{\textheight}{9in}
\setlength{\textwidth}{6.5in}
\setlength{\topmargin}{-0.25in}
\setlength{\oddsidemargin}{0in}
\setlength{\evensidemargin}{0in}

\newcommand{\code}[1]{\mbox{\tt #1}}
\newcommand{\argd}[1]{{\normalsize \sl #1}}
\newcommand{\deff}[2]{\bigskip \noindent
  \makebox[\textwidth]{\code{#1} \hfill {\it #2}}}
\newcommand{\OBL}{{\sc ObjectLisp\/}}
\newcommand{\LISP}{{\sc Lisp\/}}

\begin{document}

{\centering \Large \OBL{} Manual\\[2ex] \large Gary L. Drescher\\}

\noindent \makebox[\textwidth]{Copyright \copyright Gary L. Drescher
1985
 \hfill Draft of \today}

\section{Introduction: Objects and \OBL}

\OBL{} is a dialect of \LISP{} that facilitates object-oriented
programming.\footnote{The Flavors system is another such facility.  This
document introduces only \OBL{}; but there are occasional footnotes
addressed
to Flavors users, explaining how some common applications of Flavors can
be
mimicked using \OBL.} Object-oriented programming involves the creation
of
various {\em classes} (kinds or categories) of things, and {\em
instances}
(individuals, examples) of those classes.  For example, there might be a
class
of ``automobiles'', and ``the car I just bought'' might be an instance
of that
class.  The classes often form a hierarchy\footnotemark--
\footnotetext{More
generally, the classes form a {\em lattice}.  The difference is that in
a
hierarchy, each class is a specialization of just one other class; in a
lattice, more than one class can be combined when making a subclass.}
you can
make a new class by saying that it is a {\em specialization}, a more
specific
version, of another class; for example, ``convertible'' is a
specialization of
``automobile''.  In \OBL, both classes and instances are implemented by
what
are simply called {\em objects}.  \footnote{The word {\em object} is
traditionally used to refer to any kind of datum in \LISP-- a list, a
symbol, a
fixnum, etc.  In this document, however, {\em object} refers only to the
object-entities provided by \OBL for object-oriented programming.}

In \OBL, an object has a collection of bindings of variables and
functions,
which determine the object's properties and behavior.  A {\em variable
binding}
can be thought of as a distinct version of some variable, with its own
separate
value for that variable; for example, one object might have a binding of
the
symbol \code{x} to the value 3, while another binds \code{x} to 4.  The
ordinary \LISP{} environment is considered \OBL's {\em global object},
and
symbols are bound there to their ordinary \LISP{} global values.  A {\it
function binding} is similar to a variable binding, but it associates a
symbol
with a definition, rather than a value.  Ordinary use of \code{defun}
creates a
global function binding.

A {\em specialization} of an existing object is a new object that can be
given
its own variable and function bindings; in addition, it {\em inherits}
all the
bindings of the previous object, except for symbols whose bindings the
new
object replaces (this is called {\em shadowing}) with bindings of its
own.  By
making a specialization of a class object, you can make a new class that
is
just like the old one, except for the differences you specify.

Similarly, an instance of a class inherits bindings from that class, and
can be
given exceptions and contributions of its own; in these respects, an
instance
object is just like a specialized class object.  The difference is a
matter of
convention, of how the objects are built and used: the bindings given to
an
instance describe the properties of some {\em individual} entity; the
bindings
of a class describe things common to {\em all} entities of a certain
kind.

For example, we might define a class object called \code{icon}.
Instances of
this class are small pictures that can be moved about on the graphics
screen.
The \code{icon} object includes, say, a binding for the function
\code{goto-xy}
(which expects two numbers specifying the new X and Y coordinates at
which to
display the picture).  \code{icons}'s binding of the function
\code{goto-xy}
(along with any other bindings \code{icon} may have) is inherited by all
specializations of \code{icon}, and also by all instances of
\code{icon--} all
such objects share that inherited binding, except those objects where
the
binding has been shadowed.  In addition, each \code{icon} instance
includes
(let's say) a binding of the variables \code{x-coord} and
\code{y-coord}; these
say where on the screen the icon is currently drawn.  Obviously, those
variables can't be shared by all icons; each icon needs its own bindings
of
\code{x-coord} and \code{y-coord}, since different icons can be in
different
positions.

Typically, as in this example, class objects are given function
bindings, and
instance objects are given variable bindings.  The functions determine
how
members of a class behave, and are shared by all instances of a class;
the
variables describe the state or attributes of individual instances, and
each
instance has its own.  We speak of {\em class functions} and {\em
instance
variables}\footnote{These are analogous to flavor methods and instance
variables, respectively, in the Flavor system.  Flavors provide no
counterpart
for class variables and instance functions, however.}.  In addition
(though
less commonly) it can be useful to have variable bindings in class
objects
(class variables) and function bindings in instance objects (instance
functions).

\OBL{} requires the use of only a handful of new primitive functions:
\begin{itemize}
 \item \code{make-obj} and \code{kindof} are used to make new objects.
 \item \code{ask} is used to cause any sequence of \LISP{} expressions
to be
evaluated in the environment of a given object.
 \item \code{defobfun} is used (in place of \code{defun}) to create
function bindings in an object.
 \item \code{have} is used to create variable bindings in an object.
\end{itemize}

These primitives are described in
section~\ref{building-objects-section}.  In
addition, there are other object primitives that, although not strictly
necessary, are useful to abbreviate common patterns of functions, or for
increased efficiency and clarity, or for esoteric manipulation of
objects.
These are described in section~\ref{reference-section}.

\section{Building object systems}
 \label{building-objects-section}
\subsection{Making an object}

The function \code{make-obj} creates and returns a fresh object.  For
example:
\begin{verbatim}
    (setq icon (make-obj))}
\end{verbatim}
The global variable \code{icon} is now bound to a new object.

Let's define the functions \code{goto-xy}, \code{draw-self}, and
\code{undraw-self} for the object \code{icon}.
\begin{verbatim}
    (defobfun (goto-xy icon) (x y)
      (undraw-self x-coord y-coord)
      (draw-self x y)
      ;; Record the new position for next time.
      (setq x-coord x)
      (setq y-coord y))
    
    ; Draw icon at X,Y.
    (defobfun (draw-self icon) (x y)
      (bitblt-to-graphics-window tv:alu-xor icon-array x y))
    
    ; Erase icon already drawn at X,Y.
    (defobfun (undraw-self icon) (x y)
      (draw-self x y)) ; (XOR'ing the same thing twice cancels.)
\end{verbatim}
(Assume that the global function \code{bitblt-to-graphics-window} has
been
defined, and that the global variables {\code x-coord} and
\code{y-coord} are
bound to coordinate numbers, and \code{icon-array} is bound to an array
that
has the icon's picture.)

\code{defobfun} has the same syntax as \code{defun}, except for the
function specifier.  Instead of just the function's name, there is a
list of
the function's name and another symbol.  The other symbol must be bound
to an
object.  The function is defined locally to that object-- that is, the
object
is given its own function binding of the symbol that names the function.
Here,
the object bound to \code{icon} gets its own function bindings of
\code{goto-xy}, \code{draw-self}, and \code{undraw-self}.

Suppose the global variables \code{x-coord} and \code{y-coord} have both
been
initialized to 0, and the icon has been drawn at (0,0).  To move the
icon to
(100,100), we say
\begin{verbatim}
    (ask icon (goto-xy 100 100))
\end{verbatim}

The first argument to \code{ask} must be an object.  The remainer of the
\code{ask} form-- the body of the \code{ask}-- is evaluated in the
environment of the designated object.  This means that that object's
bindings
are in effect during the evaluation of the body.   (For the duration of
that
evaluation, The object passed to \code{ask} is called the {\em current
object}.)  In particular, the function \code{goto-xy} is bound in the
\code{icon} object, due to the \code{defobfun} definition above; so
\code{icon}'s definition is the one that is used when the above
\code{ask}
form is evaluated.  When \code{goto-xy} calls \code{draw-self} and
\code{undraw-self}, we are still (dynamically) within the body of the
\code{ask}, so \code{icon}'s function bindings of \code{draw-self} and
\code{undraw-self} are referred to.

After \code{goto-xy} has run, \code{x-coord} and \code{y-coord} are both
set to
100, and the drawing of the icon has moved to (100,100).  Note that we
have
defined \code{goto-xy} {\em only} for the \code{icon} object; if we just
say
\code{(goto-xy 50 75)} without addressing \code{icon}, we get an
undefined-function error (unless of course someone has {\em also}
defined
\code{goto-xy} globally; in that case, the global definition is
invoked).

\subsection{Classes and instances}

You may have noticed something unsatisfactory about this example: there
is just
one version of each of the variables \code{x-coord}, \code{y-coord}, and
\code{icon-array} (\code{icon-array} is global; \code{x-coord} and
\code{y-coord} are bound in \code{icon}.)  How, then, is it possible to
create
several different icons, all at different locations (and perhaps with
different
picture-arrays)?

The answer is to think of \code{icon} as a class object, and to create
various
corresponding instance objects.  Here's how that works.  Suppose we wish
to
create two icon instances, \code{icon1} and \code{icon2}.   We say
\begin{verbatim}
    (setq icon1 (kindof icon))
    (setq icon2 (kindof icon))
\end{verbatim}

\code{kindof} creates a new object as a specialization of the object(s)
provided as inputs.  (Actually, \code{kindof} and \code{make-obj} are
synonyms; \code{kindof} sounds more natural when arguments are passed,
but
both functions accept zero or more arguments.)  When there is just one
argument-- as in this example-- the specialized object {\em inherits}
all the
bindings of the {\em base object} (the object that it specializes, that
it is
``based on'').  For example, that the above definitions of
\code{goto-xy},
\code{draw-self}, and \code{undraw-self} are accessible during a
\code{ask}
to \code{icon1} or \code{icon2}, as well as to \code{icon} itself.

In addition to inheriting bindings, a specialized object can be given
its {\it
own} bindings.  These are {\em not} inherited by the base object;
inheritance
only goes in one direction.  But of course, other objects can be made as
specialized objects of a given specialized object; {\em those} objects
will
inherit the bindings established in the given object and they will also
inherit, in turn, the bindings that the given object inherited.  The
only
exception to this inheritance occurs when an object {\em shadows} a
variable or
function binding that it would otherwise have inherited; it does this by
having
its {\em own} binding of the same variable or function, which supercedes
the
one it would have inherited.

We want \code{icon1} and \code{icon2} to be instances of \code{icon}.
Thus, we
must supply these objects with appropriate instance variables--
variables that
specify the individual attributes of the two icons.  In particular, we
want
\code{icon1} and \code{icon2} each to have its own binding of the
variables
\code{x-coord}, \code{y-coord}, and \code{icon-array}.  We use
\code{have}
to create these bindings. {\code{(have '\argd{sym val})} causes
the current object to acquire its own binding of the symbol \argd{sym},
with
value \argd{val}.
\begin{verbatim}
    (ask icon1
      (have 'x-coord 0)
      (have 'y-coord 25)
      (have 'icon-array circular-design))
\end{verbatim}

Now \code{icon1} has its own bindings of \code{x-coord} and
\code{y-coord} (to
0 and 25, respectively), and of \code{icon-array} (to an array with a
circular
design, assuming that the global variable \code{circular-design} had
been bound
to such an array).  To initialize \code{icon1}'s picture on the screen,
we
should also say
\begin{verbatim}
    (ask icon1 (draw-self 0 25))
\end{verbatim}
And similarly:
\begin{verbatim}
    (ask icon2
      (have 'x-coord 0)
      (have 'y-coord 50)
      (have 'icon-array square-design)
      (draw-self 0 50))
\end{verbatim}
\code{icon1} and \code{icon2}'s variable bindings are separate from one
another, and from any global bindings of the same symbols.  For example,
evaluating \code{y-coord} globall still returns 100.  But {\code (ask
icon1
y-coord)} returns 25, and \code{(ask icon2 y-coord)} returns 50.

Suppose we say \code{(ask icon1 (goto-xy 0 75))}.  When \code{goto-xy}
was
done within \code{icon} instead of \code{icon1} (above), occurrences of
\code{x-coord}, \code{y-coord}, and \code{icon-array} in the body of
{\code
goto-xy} referred to the {\em global} bindings of those symbols; that
was
because the \code{icon} object had no bindings of those symbols.  (And
if we
now said \code{(ask icon (goto-xy 0 75))}) again, the references to
those
variables would {\em still} refer to their global values.)  But with
{\code
(ask icon1 (goto-xy 0 75))}, those same references occur during a
\code{ask}
to \code{icon1}, which {\em does} bind those symbols.  Hence, the
references
now are to \code{icon1}'s bindings.  Notice especially that this is true
both
for {\em getting} the values of these symbols (when the symbols are
evaluated
to provide arguments to \code{goto-xy}'s call to \code{undraw-self}),
and also
for {\em setting} their values (by the \code{setq}'s at the end of
{\code
goto-xy}).  \code{setq} never {\em creates} new variable bindings in an
object;
only \code{have} does that.  \code{setq} just changes the value of an
existing binding.\footnote{Readers familiar with the taxonomy of binding
schemes will notice that objects are dynamically scoped closures.  That
is,
upon entry to an object (via \code{ask}), all the variables for which
that
object has bindings are dynamaically bound to the associated values;
upon
exiting the \code{ask}, those bindings are dissolved (the values first
being
saved in the object, for the sake of any subsequent \code{ask} to that
object).  (More accurately, if one \code{ask} occurs dynamically within
another, the outer \code{ask}'s object is exited before entering the
inner
\code{ask}, then re-entered upon exiting the inner \code{ask}).} So now,
\code{(ask icon1 y-coord)} returns 75; but \code{(ask icon2 y-coord)}
still
returns 25, and evaluating \code{y-coord} globally still returns 100.

Now we have an \code{icon} class and some icon instances, but something
is
still awry.  Surely it is unacceptable to have to initialize each new
instance
by \code{ask}'ing it to \code{have} each of its instance variables (and
to draw itself initially), as we did above.  This problem will be
especially
acute when we build objects that need dozens of instance variables and
initializing actions.  Fortunately, of course, there's no need to do all
this
manually-- we can define a function to do it automatically.  For
example:
\begin{verbatim}
    (defobfun (exist icon) (&rest args &key* (x 0) (y 0)
                                             (array default-icon-array))
      ;; Establish a binding of the variable X-COORD to the value of
      ;; the EXIST function's parameter X:
      (have 'x-coord x)
      ;; Etc:
      (have 'y-coord y)
      (have 'icon-array array)
      ;; Make the initial drawing.
      (draw-self x y)
      ;; (Ignore the following line for now; it is explained below.)
      (apply 'shadowed-exist args))
\end{verbatim}
From now on, making new ICON instances is much easier; for example:
\begin{verbatim}
    (setq icon3 (kindof icon))  (ask icon3 (exist))
    (setq icon4 (kindof icon))  (ask icon4 (exist 'array
circular-design))
\end{verbatim}
The caller can provide keyword arguments to override the \code{exist}
function's defaults for the initial instance-variable values.  Of
course, we
might instead have defined the \code{exist} function to ``hardwire''
some or
all of the initial values, rather than giving the caller the choice of
supplying them; and we might have had other \code{exist} arguments, ones
that
did not correspond to instance-variable initializations.
\label{key-intro}

\begin{quote}
Note: \code{defobfun} treats \code{\&key*} arguments slightly
differently than
\code{\&key} ones.  With \code{\&key*,} the default is that a key name
is {\it
not} put in the keyword package; hence \code{(exist 'array ...)} above
rather
than \code{(exist :array ...)}.  Also, \code{\&allow-other-keys} is
implicit
when \code{\&key*} is used.  The rationale for these differences is
explained
at the end of section~\ref{key-explanation}.
\end{quote}

The idea behind the \code{exist} function is simple: although the
different
instances of \code{icon} cannot share instance variables with one
another--
each instance needs its own set of instance variables-- the instances
{\em can}
share a ``template'' for {\em creating} those variables (and for
performing
other needed initializations).  That shared template is provided, in the
form
of the \code{exist} function bound in the \code{icon} class object.
There is
nothing magic about using the name \code{exist} for this function; but
it turns
out to be a good idea to have a standard name for instance-initializing
functions, and \code{exist} is that standard.

\bigskip

We have just seen that \OBL{} does not insist on distinguishing between
classes
and instances-- both are just objects, made by the function
\code{kindof} (or
\code{make-obj})).  In fact, the distinction between classes and
instances
is entirely a matter of the conventions that the user follows.  Recall
that
when we first created the \code{icon} object, we didn't have to say
whether it
was a class or an instance-- and indeed, we used it as {\em both}.  We
defined
the class functions \code{goto-xy}, \code{draw-self}, and
\code{undraw-self}
locally to \code{icon,} as though \code{icon} were a class object.  But
when we
actually told \code{icon} to move to a new position (by saying
\code{(ask icon
(goto-xy 100 100))}, we were treating it as a instance.  It is often
useful,
when creating a new class of object on the fly, to treat the class as a
prototype instance.  That way, you don't have to decide in advance what
instance variables need to be created-- you just use global variables.
And
conversely, it may be useful to treat an instance object as a prototype
class,
by giving the instance some experimental function bindings to specialize
its
behavior.  But the conventional class/instance distinction is important,
and it
is strongly recommended that object-oriented software be designed
according to
this convention.

To facilitate the class/instance distinction, \OBL{} provides the
primitive
\code{oneof} for making instance objects, and \code{defkind} for making
class
objects.  Both of these primitives can be thought of as calling
\code{kindof,}
as well as performing some auxiliary actions.  \code{oneof} and
\code{defkind}
are useful because their auxiliary actions are especially convenient for
instances and classes (respectively); and because these primitives make
implicit declarations about the nature of the object being created,
resulting
in more efficient code.  \code{oneof} and \code{defkind} are documented
in
part~\ref{reference-oneof} of the reference section.

\subsection{Object binding vs lexical binding}
\label{obj-vs-lex}

Here is a point that deserves emphasis, as it is an easy one to stumble
on:
lexical binding {\em overrides} object binding; only {\em free
references} can
refer to object bindings.  This is now explained in detail.

Within a lambda expression (or within any implicit lambda expression,
such as a
\code{defun} or a \code{let}), certain variables-- the parameters in the
arglist of a lambda expression or function body, or the variables in the
varlist of a \code{let--} are {\em lexically bound}.  Suppose the
variable
\code{a} is lexically bound in any kind of lambda expression.  Any
reference to
\code{a} in the body of that expression-- any form to get or set the
value of
\code{a--} refers to the current lexical binding of \code{a,} {\em
regardless}
of whether we happen to be inside a \code{ask} to an object that
contains a
binding of \code{a.} For example, suppose the object bound to the symbol
\code{obj1} binds \code{a} to 10 and \code{b} to 20; and suppose we say:
\begin{verbatim}
    (let ((a 3))
      (ask obj1
         (setq a (1+ a))
         (print a)
         (setq b (1+ b))
         (print b)))
\end{verbatim}

The \code{a} that gets incremented by the expression \code{(setq a (1+
a))} is
the \code{let}'s binding of \code{a}, {\em not} \code{obj1}'s binding of
\code{a}; \code{obj1}'s binding of \code{a} is unaffected.  Similarly,
the
\code{a} in \code{(print a)} refers to the \code{let}'s binding of
\code{a};
hence, the number 4 is printed.  The two references to \code{b}, on the
other
hand, are {\em free} references-- that is, \code{b} is not lexically
bound in
this expression.  Therefore, \code{b} {\em does} refer to \code{obj1}'s
binding; \code{obj1}'s value for \code{b} is incremented, and the new
value,
21, is printed.  (Of course, if \code{obj1} had no binding for \code{b,}
then
the reference would be to the global variable \code{b}.)

(A possible source of confusion: the function \code{have} {\em creates}
an
object-binding of the specified variable, rather than {\em referring} to
an
existing binding; so \code{(have 'a {\argd value})} gives the current
object
its own binding of A, {\em even if} the \code{have} occurs in an
expression
where A is lexically bound.)

To repeat: lexical binding overrides object binding.  This fact can be
helpful
when you need to communicate one object's value for some variable to
another
object that binds the same variable.  For example, you should convince
yourself
that this expression:
\begin{verbatim}
    (ask icon1 (let ((x x-coord)
                      (y y-coord))
                  (ask icon2 (goto-xy x y))))
\end{verbatim}
changes \code{icon2}'s position to coincide with \code{icon1}'s, whereas
\begin{verbatim}
    (ask icon1 (ask icon2 (goto-xy x-coord y-coord)))
\end{verbatim}
leaves \code{icon2}'s position unchanged, since \code{x-coord} and
\code{y-coord} refer here to \code{icon2}'s own bindings.

Functions, as well as variables, can be lexically bound; function
binding is
accomplished in \LISP{} by using \code{flet} or \code{labels}.  For
functions,
too, lexical binding overrides object binding.

\section{Specialized classes}

The real power of object-oriented programming comes from being able to
{\em specialize} existing classes of objects.  A new object can be built
just
by saying how it {\em differs} from an old one; everything not mentioned
is
just inherited, and stays the same.

For example, suppose we want to make a kind of icon that draws a line
when it
moves, leaving a trail behind it.  First, we make a specialized object
from
\code{icon}:
\begin{verbatim}
    (setq icon-with-trail (kindof icon))
\end{verbatim}
This time, we're going to regard the new object as a specialized {\em
class}
object, whereas in the previous section, \code{kindof} was used to
create a
specialization of \code{icon} that we regarded as an {\em instance} of
\code{icon}.

\code{icon-with-trail} needs to shadow the inherited function binding of
\code{goto-xy} (from \code{icon}), and to supply its own definition
instead.
\code{icon-with-trail}'s \code{goto-xy} should do what the shadowed
\code{goto-xy} does; and in addition, the new \code{goto-xy} function
needs to
draw a line.  Here is a definition that is {\em almost} right:
\begin{verbatim}
    (defobfun (goto-xy icon-with-trail) (x y)
      ;; Draw line from (X-COORD,Y-COORD) to (X,Y), assuming that the
function
      ;; DRAW-LINE-ON-GRAPHICS-SCREEN has been suitably defined.
      (draw-line-on-graphics-screen x-coord y-coord x y)
      ;; Now invoke the shadowed GOTO-XY.
      (goto-xy x y)) ; This line is >WRONG<, however.
\end{verbatim}
The problem here is that the occurrence of \code{goto-xy} (in the last
line)
will {\em not} refer to the shadowed version of \code{goto-xy}; it will
refer
to the {\em shadowing} definition, which is the above definition itself.
This
version of \code{goto-xy} will call {\em itself}, not the shadowed
version of
itself.

It is common for a shadowing definition of a function to want to call
the
shadowed version, {\em in addition} to performing some new idiosyncracy.
Here,
we could accomplish this by looking up \code{icon}'s definition of
\code{goto-xy,} and copying it into the end of \code{icon-with-trail}'s
definition.  But it is much better to be able to {\em call}
\code{icon}'s
\code{goto-xy}, without needing to know how it was implemented-- and
without
needing to {\em change} \code{icon-with-trail}'s version of
\code{goto-xy} if
\code{icon}'s version is ever redefined, and we want to stay compatible
with
it.  \OBL's {\em shadowed} facility makes this possible.  Here is the
correct
definition of \code{icon-with-trail}'s \code{goto-xy}:
\begin{verbatim}
    (defobfun (goto-xy icon-with-trail) (x y)
      (draw-line-on-graphics-screen x-coord y-coord x y)
      (shadowed-goto-xy x y))
\end{verbatim}

Within the text of a definition of the function {\em name}, the symbol
\mbox{\code{shadowed-}{\em name}} refers to the version of {\em name}
that {\it
would have} been inherited, had not this very definition shadowed it.
So here,
for \code{icon-with-trail}, we've added our line-drawing idiosyncracy to
\code{goto-xy}'s shadowed behavior, without needing to be concerned with
how
that shadowed behavior was implemented.

Next, suppose we say:
\begin{verbatim}
    (setq icon5 (kindof icon-with-trail))
    (ask icon5 (exist 'x 10 'y 10))
    (ask icon5 (goto-xy 50 50))
\end{verbatim}
Now we've got \code{icon5} drawn at (50,50), and a line drawn on the
screen
from (10,10) (where \code{icon5} first appeared) to (50,50).  Note that
the
\code{exist} function just invoked was inherited by \code{icon5} from
\code{icon-with-trail,} which in turn inherited it from \code{icon}; the
functions \code{draw-self} and \code{undraw-self} are similarly
inherited.

Here's another specialization of \code{icon}:
\begin{verbatim}
    (setq boundary-icon (kindof icon))
    
    (defobfun (goto-xy boundary-icon) (x y)
      (unless (out-of-bounds? x y)
         (shadowed-goto-xy x y)))
    
    (defobfun (out-of-bounds? boundary-icon) (x y)
      (or (< x (car x-bounds)) (>= x (cadr x-bounds))
          (< y (car y-bounds)) (>= x (cadr y-bounds))))
    
    (defobfun (exist boundary-icon) (&rest args &key* (x-bounds '(0
100))
                                                      (y-bounds '(0
100)))
      (have 'x-bounds x-bounds)
      (have 'y-bounds y-bounds)
      (apply 'shadowed-exist args))
    
    (setq icon6 (kindof boundary-icon))
    (ask icon6 (exist 'scale 5))
\end{verbatim}
\code{boundary-icon} is a kind of \code{icon} that never strays outside
a
certain rectangular region.  The region is specified by the instance
variable
\code{x-bounds} (which is a list of the lower and unpper values for the
icon's
x-coordinate) and the instance variable \code{y-bounds} (similarly).
Notice
that \code{boundary-icon}'s definition of \code{goto-xy} doesn't
necessarily
invoke \code{shadowed-goto-xy}-- first, it checks to see if the new
\code{x,y}
coordinates are within bounds.  If they aren't, no further action is
taken; if
they are, \code{goto-xy} behaves as usual.

Notice how \code{boundary-icon}'s \code{exist} function is set up.  This
version of \code{exist} only knows about the instance variables that are
special to \code{boundary-icon}: the variables \code{x-bounds} and
\code{y-bounds}.  Any other key arguments that might be passed to
\code{boundary-icon}'s \code{exist} function are simply passed on to the
{\it
shadowed} \code{exist} function (via the parameter \code{args}); and
\code{boundary-icon}'s \code{exist} function has no knowledge of what
those
passed-on arguments may be.  This compartmentalization of knowledge is
valuable; to support it, \code{exist} functions should {\em always} be
defined
with no arguments other than \code{\&key*} ones.  And \code{exist}
functions
should always be defined to call \code{shadowed-exist}, passing all
arguments
along, so that the initializing actions (especially instance-variable
creation)
of the base class(es) happen along with the actions peculiar to the
specialized
object's \code{exist} definition.

\label{key-explanation} \code{\&key*} was introduced on
page~\pageref{key-intro}.  Now the rationale for \code{\&key*} becomes
apparent.  First, extraneous arguments to an \code{exist} function might
be
expected by a \code{shadowed-exist}; so each \code{exist} function
should allow
all keys (which happens automatically with \code{\&key*}.  Second, it is
important to avoid accidental name conflicts between one \code{exist}
function's keywords and those of a shadowed \code{exist} procedure
called be
the first one.  The only way to assure this avoidance, without knowing
the
other names involved, is to keep the symbols in different {\em
packages};
hence, \code{\&key*'s} default of keeping the keyword symbol's original
package, rather than moving all keyword symbols into the keyword
package.

\section{Multiple inheritance}
\label{multiple-inherit}

\code{kindof} can be called with several base objects as arguments.  In
this
case, the object that \code{kindof} creates is a specialization of all
the
input objects-- that is, the new object inherits bindings from each of
those
objects.  This is useful when either:
\begin{itemize}
\item The input objects are {\em disjoint}-- that is, if there is no
overlap
between the symbols bound by one such object, and those bound by any
other.  In
this case, the set of bindings inherited by the object is simply the
union of
all the input object's bindings.
 \item The input objects are all specializations of some common base
object.
That is, each input object adds its own idosyncracies to the common base
object.  In this case, the new object is a combination of the
idiosyncracies of
the input objects, together with the common base object.  This is
explained
more precisely below.
\end{itemize}

Consider an example of the second sort.  Here, we create a new class
object,
\code{boundary-icon-with-trail}, that inherits from both
\code{boundary-icon}
and \code{icon-with-trail} (which share the base object \code{icon}).
\begin{verbatim}
    (setq boundary-icon-with-trail (kindof boundary-icon
icon-with-trail))
    (setq icon7 (kindof boundary-icon-with-trail)
    (ask icon7 (exist))            ;ICON7 is an instance of
BOUNDARY-ICON-WITH-TRAIL.
    (ask icon7 (goto-xy 0 100))    ;ICON7 moves to 0,100, drawing a
trail.
    (ask icon7 (goto-xy 200 200)   ;Nothing happens, for 200,200 is out
of bounds.
\end{verbatim}
\label{binding-frames}

To understand how these forms work, we need to be more explicit about
the
composition of objects.  Think of an object as a list of {\em binding
frames},
listed from {\em innermost} to {\em outermost}.  An object's own
bindings
reside in its innermost frame; its inherited bindings reside in the
other
frames, which the object shares with its base object(s).  When
\code{kindof} is
called with no arguments, the resulting object's list of frames has only
one
member: the freshly-created frame.  (\LISP's ordinary global
environment,
\OBL's ``global object'', can be thought of as having a frame containing
all
global variable and function bindings; this is implicitly the outermost
frame
of {\em all} objects.) When \code{kindof} is called with just one
argument, the
new object's list of frames begins with a fresh frame that \code{kindof}
creates, followed by all the frames of the input object.

Now suppose \code{kindof} is called with several input objects.  Once
again, we
get a list of frames starting with the new object's own freshly-created
frame.
The other frames are gotten by, first, appending together the list of
frames
from each of the input objects (in the order in which the inputs were
passed);
second, eliminating any {\em duplicated} frames in the appended list,
leaving
only the {\em outermost} occurrence of each frame.  For example, just
above,
these objects
\begin{quote}
\code{boundary-icon}: \mbox{[\code{boundary-icon}'s frame],}
 \mbox{[\code{icon}'s frame].}\\
\code{icon-with-trail}: \mbox{[\code{icon-with-trail}'s frame],}
 \mbox{[\code{icon}'s frame].}
\end{quote}
were combined to form
\begin{quote}
\code{boundary-icon-with-trail} (before eliminating duplications):\\
\mbox{[\code{boundary-icon-with-trail}'s frame],}
\mbox{[\code{boundary-icon}'s frame],}
\mbox{[\code{icon}'s frame],}\\ \mbox{[\code{icon-with-trail}'s frame],}
\mbox{[\code{icon}'s frame].}\bigskip
after eliminating duplications:\\
\mbox{[\code{boundary-icon-with-trail}'s frame],}
\mbox{[\code{boundary-icon}'s frame],}\\
\mbox{[icon-with-trail's frame],} \mbox{[icons's frame].}
\end{quote}

Note that after duplicates are eliminated, the inherited frames consist
of the
two specialized frames (from \code{boundary-icon} and
\code{icon-with-trail})
followed by the frame(s) (just one, in this case) from their common base
object, \code{icon}.  \code{icon7}, of course, looks like this:
\begin{quote}
\code{icon7}: \mbox{[\code{icon7}'s frame],}
 \mbox{[\code{boundary-icon-with-trail}'s frame],}
 \mbox{[\code{boundary-icon}'s frame],}\\
 \mbox{[\code{icon-with-trail}'s frame],} \mbox{[\code{icon}'s frame].}
\end{quote}

Because the specialized frames are followed by the common inherited
frame(s),
the combined object behaves as though both specializations were made,
successively, to the common object.  When \code{icon7} is told to
\code{goto-xy}, the reference to \code{goto-xy} is resolved, as always,
by
finding the innermost frame in \code{icon7} that contains a binding of
the
function \code{goto-xy.} Therefore, \code{boundary-icon}'s definition is
found.
This version of \code{goto-xy} first checks if its arguments are within
bounds.
If not, no further action is taken-- in particular,
\code{shadowed-goto-xy} is
{\em not} called.  But if the coordinates are ok,
\code{shadowed-goto-xy} {\it
is} called.  This \code{shadowed-goto-xy} refers to the next-innermost
definition of \code{goto-xy} in \code{icon7}'s list of frames-- namely,
\code{icon-with-trail}'s definition.  \code{icon-with-trail}'s
\code{goto-xy}
draws the required trail, and also calls \code{shadowed-goto-xy}--
referring
again to the next-innermost binding of \code{goto-xy}, in this case
\code{icon}'s.  \code{icon}'s \code{goto-xy} takes care of the basic
erasing
and redrawing of the icon's picture, and maintains the icon's
\code{x-coord}
and \code{y-coord} variables.

Similarly, when \code{icon7} was told to \code{exist,}
\code{boundary-icon}'s
\code{exist} function was invoked.  It called \code{shadowed-exist},
invoking
\code{icon}'s \code{exist}.  (Recall that \code{icon-with-trail} was
never
given its own definition of \code{exist}; it just inherits
\code{icon}'s.)
Thus, the instance-variable creation (and other initializing actions) of
{\it
all} the objects that \code{boundary-icon-with-frame} was made from were
taken.
This underscores the need to define \code{exist} functions to call
\code{shadowed-exist}, so that combined objects get the
appropriately-combined
initializations.

\section{Stylistic issues}

This section recommends certain stylistic practices for \OBL{}
programming.

\begin{enumerate}
\item Organize things into abstract functional units.

If there's some coherent task to perform-- like, ``move this icon to
X,Y''--
then {\em define a function} to do the task.  This is always an
important
programming principle, but it is especially important for
object-oriented
programming.  In \OBL, one object's definition of some function (say,
\code{goto-xy}) can be shadowed by a specialized object, which
substitutes its
own definition.  This definition might, say, add some idiosyncracy to
the
function's task, or it might perform the same task by a different
algorithm
than the shadowed version.  The more things you organize into distinct
functional units, the more things you can selectively shadow in
specialized
objects.

\item Don't bind the same symbol for {\em unrelated} purposes in
different
objects.

All function bindings of a given symbol should take the same arguments
and
fulfill the same general purpose.  It's {\em possible} to use the same
symbol
to name two completely unrelated functions in two different objects (if
you
always know which version of the function you want, and which kind of
object
you're talking to).  But this is a confusing practice.  You won't be
able to
tell, just by looking, which version of the function you're invoking
(even
though you knew when you wrote the code).  And it won't be possible to
globally
document the function (because such basic properties as the number of
arguments
might differ in different objects).

As always, use {\em packages} to prevent accidental duplication of the
same
name in different bodies of code.  In addition to the advantages of
clarity
and documentability, this may yield a runtime efficiency gain.

This principle applies to variables, too.  Don't bind the same variable
in
several different objects-- except, of course, for an instance variable,
which
serves the same purpose in each instance it appears in.  Even for an
instance
variable, there should be only one class object that is responsible (via
an
\code{exist} function or a \code{definstancevar}) for creating that
variable.

Since avoiding duplication of object bindings is a matter of clarity and
efficiency (as opposed to being necessary for code to work at all), it
is ok to
be lax about it when writing small, informal, improvised programs.  But
serious
systems should take the principle seriously.

\item Follow the principle of {\em data abstraction}: keep internal
implementation details from being accidentally accessed by users of the
system.

Typically a class object has some set of functions that comprise the
preferred
interface to instances of that class.  That is, there are certain
functions
that a user is expected to call inside that object (and perhaps certain
variables that the user is expected to refer to); these functions (and
variables) are the preferred interface.  Other functions and variables
are
supposed to be {\em internal} to the object-- these are referred to by
the
interface functions, but are not intended to be accessed {\em directly}
by the
user.  Typically, the internal functions and variables are ones that
could
cause the object to be put in an erroneous state, perhaps causing an
error to
be signalled; the interface routines are designed to guarantee
consistency of
the object's state, as long as those routines are the only ones that the
user
calls directly.

At the least, the documentation that goes with an object should say what
functions are part of the preferred interface; none of the object's
other
functions or variables should be referenced by the user.  As a further
precaution, you may wish to {\em enforce} this distinction; this, again,
is a
job for packages.  Simply create a package, and put all the code for an
object
in that package.  All function and variable symbols in that code will be
internal to the package, and thus inaccessible from outside, except for
symbols
explicitly declared {\em external}; these should be the designated
interface
symbols.  (Of course, any user may, by appropriate maneuvering, access
the
internal symbols of a package; but users who do this know that they
proceed at
their own risk.)  Objects and packages can be orthogonal; there might be
several packages, each of which contains some code for each of several
objects.
Hence, what is accessible to whom can be finely tuned.

\item Don't overextend the object-oriented approach.

Object inheritance is appropriate when a number of entities form a
natural {it
specialization} hierarchy, one being a kind of another.  But object
specialization isn't the right way to relate the elements of other kinds
of
hierarchies-- for example, an inclusion hierarchy, where one entity is a
{\it
part of} another (eg, a hand is a part of an arm is a part of a body);
or a
ranking hierarchy (eg president, manager, worker), where one entity is a
subordinate of another.  A hand is not {\em a kind of} arm, and so a
hand
object should not be defined to inherit the attributes of an arm object,
nor
should arm inherit from body.  But hand and arm might be defined as
specializations of a general body-{\em part} object.

\end{enumerate}

\section{Reference}
\label{reference-section}
\subsection{Using \OBL}

\subsubsection{The \code{obj} package}

\OBL's symbols reside in the \code{obj} package.  Names of \OBL{}
primitives,
and some other useful symbols, are external to the \code{obj} package.
To
access any of these symbols, either refer to \code{obj:{\em symbol}}, or
do a
\code{(use-package obj)} in the package from which you wish to make
access.
The \code{user} package already uses the \code{obj} package.  The
external
symbols are:

\begin{verbatim} 
    ask talkto kindof oneof make-obj remake-obj
    defobfun &key* defkind define-kind defclassvar definstancevar
    defclassvars definstancevars instancevar-defs undef-instancevar
    have unhave fhave unfhave
    ask-funcall mapc-ask mapcar-ask map-ask
    object? obj-equal current-obj exist shadowed-exist
    obj-let-globally obj-listener-loop obl
    obj-name class-name print-self
    base-objs inherited-objs
    what show show-all show-vals specializations
    own own? where there? mapc-own mapcar-own own
    fown fown? fwhere fthere? fdoc mapc-fown mapcar-fown
\end{verbatim}

\subsubsection{Toplevel}

\deff{obj-listener-loop}{Function}

\code{obj-listener-loop} runs a special \OBL{} listener loop.  This is
necessary because, in the present implementation, references to object
bindings
only work properly when made textually within an \code{defobfun};
elsewhere,
free references can only access global bindings (see \code{defobfun}).
\code{obj-listener-loop} \code{defobfun}s, and then funcalls, a dummy
function
for each toplevel expression you type, so that your expression can
access
object bindings.

If the current object is other than the global object-- if, for example,
you're
in a break loop dynamically within a \code{ask}; of if, at toplevel,
you've
executed a \code{talkto} for some object (see section
\ref{reference-talkto})--
the \OBL{} listener loop identifies that object as part of the
listener's
prompt.

\deff{obl \{\argd{form}\}*}{Macro}

\code{obl} is used to access object bindings from outside the textual
scope of
an \code{defobfun}.  \code{obl} defines (via \code{defobfun}) and
funcalls a
dummy function whose body consists of the \argd{form}s.

\subsection{Evaluating inside objects}

\deff{ask \argd{obj-form} \{\argd{form}\}*}{Macro}

\argd{obj-form} must evaluate to an object (or \code{nil}, to refer to
the
global object).  The \argd{form}s constitute the body of the \code{ask},
an
implicit progn that is evaluated inside the object that \argd{obj-form}
evaluates to.  That object is said to be the {\em current object} for
the
duration of the evaluation of the \argd{form}s (except, of course, when
another
\code{ask} is invoked during that evaluation, temporarily establishing
another
current object).

\deff{ask-funcall \argd{obj-form symbol} \{\argd{arg-form}\}*}{Macro}

\code{ask-funcall} is useful when you wish to invoke a function inside
some
object, but the arguments to the function need to be evaluated in the
current
object. \argd{obj-form} must evaluate to an object; \argd{symbol} must
be a
symbol.  \argd{arg-forms} are evaluated in the current object.  Then,
\argd{symbol} is \code{fsymeval}'ed inside the specified object, and the
resulting function is applied to the arguments inside the specified
object.

A different technique for calling a function inside some object, but
with the
arguments evaluated in the current environment, is to lambda-bind some
variables to the values, then refer to those variables in the body of
the
\code{ask}.  This works because object scoping only captures free
references.
See section \ref{obj-vs-lex}, Object Binding vs Lexical Binding.

\deff{mapc-ask \argd{objlist-form} \{\argd{form}\}*}{Macro}

\argd{objlist-form} must evaluate to a list of objects.  A \code{ask} is
done
to each in turn, using the \argd{form}s as the body.  The list of
objects is
returned.

\deff{mapcar-ask \argd{objlist-form} \{\argd{form}\}*}{Macro}

\argd{objlist-form} must evaluate to a list of objects.  A \code{ask} is
done
to each in turn, using the \argd{form}s as the body.  A list of the
resulting
values is returned.

\label{reference-talkto}
\deff{talkto \&optional \argd{object}}{Function}

\argd{object} must be an object (or \code{nil}, to refer to the global
object.)
\code{object} becomes the current object.  \code{talkto} with no
argument (or
with \code{nil} as its argument) sets the current object to the global
object.

\code{talkto} is to \code{ask} as \code{setq} is to special-variable
binding.

\code{talkto} should only be used interactively, at listener level.
\code{talkto} puts you inside an object, allowing you to get or set its
variables' values (or call its functions) just as though you were making
global
references.  The object listener loop's prompt indicates what the
current
object is, if it is other than the global object.

\subsection{Creating objects}

\deff{kindof \&rest \argd{objects}}{Function}

\code{kindof} creates and returns a new object.  The \argd{objects} must
all
be objects.  If no arguments are passed, \code{kindof} creates a bare
object
that inherits only from the global object.  If one argument is passed,
the new
object is a specialization of that object.  If several arguments are
passed,
the new object is a specialization of all the \argd{objects} (see
section~\ref{multiple-inherit}).

More precisely, \code{kindof} creates and returns an object whose
binding
frames, innermost to outermost are: a new frame, which will contain the
new
object's own bindings; the frames of the first \argd{objects} argument;
the
frames of the next \argd{objects} argument; and so on.  (The arguments
must
all be objects.)  If any frame appears more than once, duplicate
appearances
are deleted, leaving only the outermost occurrence.  The global frame
(containing the ordinary \LISP{} global values and definitions for all
symbols) is implicitly the outermost frame of every object.  See
section~\ref{multiple-inherit} for elaboration.

\deff{make-obj \&rest \argd{objects}}{Function}

\code{make-obj} is a synonym of \code{kindof}.

\deff{remake-obj \argd{object} \&rest \argd{objects}}{Function}

\code{remake-obj} is used to alter an existing object's base objects.
\argd{object} is altered so that its base objects are \argd{objects},
all of
which must be objects.  The change propagates transitively to
specializations
of \argd{object}.  The new object has the same innermost binding frame
as the
original, so the original's own bindings are preserved.

Suppose there is a form in your file that says \code{(defvar obj3
(kindof
obj2))}, followed by \code{defobfun}s of many functions for \code{obj3}.
If
you were to re-execute the \code{kindof}-- either with the same base
object, or
with different one(s)-- then the functions you had defined for the
object
previously bound to \code{obj3} would not be defined for the new object
bound
to \code{obj3}.  And any specializations of the old \code{obj3} would
still
just be specializations of the old \code{obj3}, oblivious to any
differences
in the new one.  Using \code{remake-obj} solves these problems.
Usually,
\code{remake-obj} is called via \code{defkind}, which is described just
below.

\label{reference-oneof}
\deff{oneof \argd{class} \&rest \argd{keys}}{Function}

\code{oneof} is used to create a new object that is intended to be an
instance
of {\em class}, which must be an object.  \code{oneof} creates a
\code{kindof}
{\em class}, then calls the function \code{exist} inside the new object.
{\it
keys} are passed as arguments to \code{exist}.  The new object is
returned.

\deff{exist \&rest \argd{keys} \&key* \argd{obj-name}}{Function}

The global \code{exist} function recognizes the keyword \code{obj-name};
if
that keyword is supplied, the current object is given a binding of
\code{obj-name} to the argument provided.  An object's binding of {\it
obj-name} helps control the object's printed representation (see
section~\ref{obj-prep}).  \code{exist} also creates bindings of instance
variables declared by \code{definstancevar}, documented in the following
section.

\label{reference-defkind}
\deff{defkind \argd{name} \{\argd{base-class-symbol}\}*}{Macro}

\code{defkind} is used to make an object intended to be a class object.
{\it
name} and \argd{base-class-symbol}s must be symbols; and each of the
\argd{base-class-symbol}s symbols must be bound to an object.
\code{defkind}
creates an object that is a specialization of the base class objects.
In
addition, \code{defkind} takes some auxiliary actions that are useful
for class
objects:

\begin{itemize}
\item The global symbol \argd{name} is \code{defvar}'ed to be the new
class
object.
\item Crucially, if \argd{name} is already bound to an object,
\code{defkind}
creates the new object via \code{remake-obj} (see just above),
preserving the
original object's bindings, and propagating the altered base objects to
any
extant specializations of the original object.  If \argd{name} is not
bound to
an object, \code{make-obj} is used instead.
\item \argd{name}'s source file is recorded.
\item The symbol \code{class-name} is bound to \argd{name} in the new
class
object; \code{class-name} helps control an object's printed
representation (see
section~ref{obj-prep}).
\end{itemize}

\code{defkind} is for use at top level in a file (or from a listener);
it
should not be called from within a function.

% !!! cref examples next section

\subsection{Creating and deleting bindings}

\deff{have \argd{symbol} \&rest \argd{sym-val-pairs}}{Function}

\argd{sym-val-pairs} must be a list of alternating symbols and values.
For
each symbol, \code{have} gives the current object its own variable
binding of
the symbol to the corresponding value. (The last symbol's value may be
omitted,
and defaults to \code{nil}.)

\deff{unhave \argd{symbol}}{Function}

\code{unhave} deletes the current object's own variable binding (if any)
of the
symbol {\em symbol}.

\deff{fhave \argd{symbol} \&rest \argd{sym-fcn-pairs}}{Function}

\argd{sym-val-pairs} must be a list of alternating symbols and
functions.  For
each symbol, \code{have} gives the current object its own function
binding of
the symbol to the corresponding function.  (The last symbol's function
may {\it
not} be omitted, since there is no reasonable default.)

\code{fhave} signals an error if \argd{symbol} is {\em unshadowable};
see the
end of section~\ref{reference-defobfun}.

\deff{unfhave \argd{symbol}}{Function}

Deletes the current object's own function binding (if any) of the symbol
{\it
symbol}.

\deff{defclassvar (\argd{class-sym classvar})
\{\argd{init-form}\}}{Macro}

\code{defclassvar} makes a binding of the symbol \argd{classvar} for the
object
that is the value of the symbol \argd{class-sym}.  Its value is
initialized to
the value of \argd{init-form}, if that form is supplied, else
\code{nil.}
\argd{defclassvar} also declares \argd{classvar} to be a special
variable
(which is appropriate because it will be freely-- ie nonlexically--
referenced), and records the source  where it was defined.

\deff{definstancevar (\argd{class-sym instancevar})
\{\argd{init-form}\}}
 {Macro}

\code{definstancevar} is used to establish an instance variable, the
symbol
\argd{instancevar}, for all instances of the object that is the value of
the
symbol \code{class-sym}.  This is a little more complicated than
establishing a
class variable, since the instance objects which are to bind
\code{instancevar}
haven't (necessarily) even been created yet.  \code{definstancevar}
associates
the variable \argd{instancevar} (along with \argd{init-form}, if
supplied) with
the designated class object.  The global \code{exist} function finds all
such
variables for the base objects of the object being told to exist.  That
object
is given its own binding of each such variable, and (unless that binding
already existed) the associated \argd{init-form} is evaluated, providing
the
value to bind the variable to.  This is done from innermost to outermost
base
object; within a base object, the order is that in which the instance
variables
were declared.
% !!! this shd really refer to inherited rather than base objs, but the
concept
%     isn't defined yet.

Like \code{defclassvar}, \code{definstancevar} declares
\argd{instancevar}
special and records the source file of its definition.

% !!! ? instancevar-defs ?

\deff{undef-instancevar \argd{symbol object}}{Function}

\code{undef-instancevar} undoes the effect of any previous
\code{definstancevar} of the symbol \argd{symbol} for the object
\argd{object}.

\deff{defclassvars \argd{obj-sym} \{\argd{var-init}\}*}{Macro}

\code{defclassvars} is used to declare multiple class variables for the
same
object, the object which is the value of the symbol \argd{obj-sym}.
Each
\argd{var-init} is either a symbol (which becomes a class varaible
initialized
to \code{nil}), or a list of two elements: the symbol to be bound, and
the
form which is evaluated to give its initial value.

\deff{definstancevars \argd{obj-sym} \{\argd{var-init}\}*}{Macro}

\code{definstancevars}is used to declare multiple instance variables for
the
same object.  \code{definstancevars} is to \code{definstancevar} as
\code{defclassvars} is to \code{defclassvar}.

% !!! example

\subsection{DEFOBFUN} \mbox{}
\label{reference-defobfun}

\deff{defobfun \argd{(function-name object-name) arglist}
\{\argd{form}\}*}
 {-or-}

\deff{defobfun \argd{function-name arglist} \{\argd{form}\}*}{Macro}

\code{defobfun}, like \code{defun}, defines a function with
\argd{arglist} as
its arglist and \argd{body} as its body.

\argd{function-name} and \argd{object-name} (if \argd{object-name} is
supplied)
must be symbols; \argd{object-name} must evaluate to an object.  If
\argd{object-name} is supplied, the specified object is given its own
function-
inding of \argd{function-name} to the defined function.  If
\argd{object-name}
is not supplied, the function is defined globally (this is not quite the
same
as using \code{defun}, because of the following implementation quirk).

 \begin{quote} In the present implementation, object bindings are only
accessible for symbols referenced textually within an \code{defobfun}.
Thus,
if you intend a global function to be called inside any object, and to
refer to
variables or functions bound in that object, you must define that global
function using \code{defobfun} rather than \code{defun.} If \code{defun}
is
used, only the global values and definitions of freely-referenced
symbols will
be accessed; object bindings will be circumvented.  This temporary
implementation restriction should {\em not} be used deliberately to
bypass
object bindings; \code{defun} should be used only for functions that are
expected never to refer to values or functions that are have object
bindings.
To deliberately circumvent object bindings, use \code{(ask nil ...)}.

A related quirk is that \code{defobfun}, unlike \code{defun}, always
{\it
compiles} the function it defines.  This is because the lookup mechanism
for
object bindings works by intercepting free references in the compiler;
thus,
references to object bindings only work from compiled code.  This will
be
changed in a future release.
 \end{quote}

Textually within a \code{defobfun} of \argd{function-name}, calling
\code{shadowed-}\argd{function-name} invokes the shadowed version of
\argd{function-name}-- the version that would be referenced by the
symbol
\argd{function-name}, had not this very \code{defobfun} provided a
shadowing
definition.  If no shadowed binding exists, calling
\code{shadowed-}\argd{function-name} just returns \code{nil}.

\code{defobfun} recognizes an extra lambda-list keyword, \code{\&key*}.
With
this variant of \code{\&key}, the default keyword symbol for each
keyword
argument is the same as the parameter symbol, rather than being a symbol
in the
keyword package.  Also, \code{\&allow-other-keys} is implicitly declared
by
\code{\&key*}.  Section~\ref{key-explanation} explains the rationale for
this.

For reasons of efficiency, all symbols in the global package (part of
the
package system, not to be confused with the global object), as well as
all
symbols from certain internal system packages, are {\em unshadowable}--
they
cannot be shadowed by function bindings.  Hence, \code{defobfun} and
\code{fhave} signal an error if an attempt is made to function-bind such
a
symbol (except globally).  (If you are not familiar with the package
system,
all this just means that you are not allowed to shadow the definitions
of
\LISP{} system primitives.)

\subsection{Inspecting objects}

\deff{current-obj}{Function}

\code{current-obj} returns the current object-- that is, returns the
{\it
object} argument from the dynamically-innermost \code{ask} (or last
\code{talkto}).  For example, \code{(ask \argd{obj} (current-obj))}
always
returns \argd{obj}.

\deff{print-self}{Function}

Prints the printed representation of the current object.  This is always
called
to produce the printed representation of an object; hence, an object's
printed
representation can be altered by giving the object an shadowing
definition of
\code{print-self}.

\label{obj-prep}

What \code{print-self} prints is governed by the current object's
variable
bindings of the symbols \code{obj-name} and \code{class-name}.  If the
object
has its own binding of \code{class-name}, then the printed
representation is
\code{\#<The generic \argd{class} \argd{id}>}, where \argd{class} is the
printed representation of the value of \code{class-name}, and \argd{id}
is a
unique internal number.  Otherwise, if the object has its own binding of
\code{obj-name}, then if it inherits a binding of \code{class-name,} the
printed representation is \code{\#<\argd{name}, a \argd{class}
\argd{id}>}.  If
the object has its own binding of \code{obj-name}, but no binding (own
or
inherited) of \code{class-name}, the printed representation is
\code{\#<\argd{name}, no class \argd{id}>}.  If the object does not have
its
own binding of \code{obj-name} or \code{class-name}, it prints as
\code{\#<Object \argd{id}>}.

\bigskip

For the following functions, the optional argument \argd{object}
defaults to
the current object; also, \code{nil} can be specified to refer to the
global
object.

\deff{obj:what \&optional \argd{object}}{Function}

\code{what} prints the base object(s) from which \argd{object} was made.

\deff{obj:show \&optional \argd{object}}{Function}

\code{show} prints the values and functions for which \argd{object} has
its
own bindings.

\deff{obj:show-all \&optional \argd{object}}{Function}

\code{show-all} prints the values and functions for which \argd{object}
has
its own or inherited bindings (except for global bindings).

\deff{obj:show-vals \&optional \argd{object}}{Function}

\code{show-vals} prints the symbols for which \argd{object} has its own
variable bindings, together with their values.

\deff{obj:own \&optional \argd{object}}{Function}

\code{own} returns a list of all symbols for which \argd{object} has its
own
variable bindings.

\deff{obj:own? \argd{symbol} \&optional \argd{object}}{Function}

\code{own?} returns \code{t} or \code{nil} according to whether
\argd{object}
has its own variable binding of the symbol \argd{symbol}.

\deff{obj:there? \argd{symbol} \&optional \argd{object}}{Function}

\code{there?} Returns \code{t} or \code{nil} according to whether
\argd{object}
has a variable binding (its own or inherited) of the symbol
\argd{symbol}.

\deff{obj:where \argd{symbol} \&optional \argd{object}}{Function}

\code{where} returns the object (if any) from which {\em object}
inherits its
binding of the symbol \code{symbol} (or returns \argd{object} itself if
\argd{object} has its own variable binding of \argd{symbol}.)
\code{nil} is
returned if there is no such object, or if it is the global object.

\deff{obj:mapc-own \argd{function} \&optional \argd{object}}{Function}

\code{mapc-own} \code{mapc}'s \argd{function} over the symbols for which
\argd{object} has its own variable bindings.

\deff{obj:mapcar-own \argd{function} \&optional \argd{object}}{Function}

\code{mapcar-own} \code{mapcar}'s \argd{function} over the symbols for
which
\argd{object} has its own variable bindings.

\deff{obj:fown \&optional \argd{object}}{Function}

\code{fown} returns a list of all symbols for which \argd{object} has
its own
function bindings.

\deff{obj:fown? \argd{symbol} \&optional \argd{object}}{Function}

\code{fown?} returns \code{t} or \code{nil} according to whether
\argd{object}
has its own function binding of the symbol \argd{symbol}.

\deff{obj:fthere? \argd{symbol} \&optional \argd{object}}{Function}

\code{fthere?} Returns \code{t} or \code{nil} according to whether
\argd{object} has a function binding (its own or inherited) of the
symbol
\argd{symbol}.

\deff{obj:fwhere \argd{symbol} \&optional \argd{object}}{Function}

\code{fwhere} returns a list of those objects, among \argd{object} and
the
objects that \argd{object} inherits from, that have their own function
bindings
for \argd{symbol}.  The list is from innermost (most-specialized) to
outermost.
Note that \code{where} returns a single object, while \code{fwhere}
returns a
list of objects.  This is because only the single innermost binding of a
variable is accessible from an object; whereas, for a function, {\em
all} base
objects' bindings may be accessed if successive calls to the
\code{shadowed-}
versions are made.

\deff{obj:fdoc \argd{symbol} \&optional \argd{object}}{Function}

\code{fdoc} is used to locate any definition(s) of the symbol
\argd{symbol} in
the object \argd{object}. \code{fdoc} looks at \argd{object} itself, and
all
objects from which it inherits, and indicates which of those objects (if
any)
have their own function bindings of \argd{symbol}.

\deff{obj:mapc-fown \argd{function} \&optional \argd{object}}{Function}

\code{mapc-fown} \code{mapc}'s \argd{function} over the symbols for
which
\argd{object} has its own function bindings.

\deff{obj:mapcar-fown \argd{function} \&optional
\argd{object}}{Function}

\code{mapcar-fown} \code{mapcar}'s \argd{function} over the symbols for
which
\argd{object} has its own function bindings.

\deff{base-objs \&optional \argd{object}}{Function}

\code{base-objs} returns a list of \argd{object}'s base objects.

\deff{inherited-objs \&optional \argd{object}}{Function}

\code{inherited-objs} returns a list of the objects that \argd{object}
inherits
from.  These include not only \argd{object}'s base objects, but also
{\it
their} base objects, and so on.  More precisely, for each binding frame
in
\argd{object}, innermost to outermost, excluding \argd{object}'s own
frame, the
object whose own bindings are held in that frame appears (in that order)
in the
list returned by \code{inherited-objs}.

\deff{specializations \&optional \argd{object}}{Function}

\code{specializations} returns a list of the objects that inherit from
\argd{object} (unless \code{object} is \code{nil}, signifying the global
object, in which case \code{specializations} returns \code{nil}).

\deff{obj-equal \argd{object1 object2}}{Function}

\code{obj-equal} returns \code{t} or \code{nil} according to whether
\argd{object1} and \argd{object2} have the same binding frames (and in
the same
order) as one another.

\deff{object? \argd{thing}}{Function}

\code{object?} returns \code{t} or \code{nil} according to whether
\argd{thing}
is an \OBL{} object.

\end{document}


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

∂15-Aug-85  1341	gls@THINK-AQUINAS.ARPA 	Sincere apologies    
Received: from THINK.COM by SU-AI.ARPA with TCP; 15 Aug 85  13:40:52 PDT
Received: from yon by GODOT.THINK.COM via CHAOS; Thu, 15 Aug 85 16:41:22 edt
Date: Thu, 15 Aug 85 16:41 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Sincere apologies
To: cl-object-oriented-programming@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <8508141637.AA12826@HP-VENUS>
Message-Id: <850815164119.3.GLS@YON.THINK.COM>

    Date: Wed 14 Aug 85 09:38:02-PDT
    From: Alan Snyder <AS%hplabs.csnet@csnet-relay.arpa>
    To: gls@aquinas.think.com

    For your information, I distributed a "polished" proposal for
    Common Lisp objects early this year, and this proposal has
    also been implemented.  I announced it only within the object
    oriented working group, rather than to the entire Common Lisp
    mailing list.  In case you are not aware, the Xerox proposal
    was not discussed at all within the working group prior to
    its recent announcement.  I haven't even seen it yet.

      Alan Snyder
    -------


    Date: Wed, 14 Aug 85 13:39:15 MDT
    From: kessler%utah-orion@utah-cs.arpa (Robert Kessler)
    To: gls@aquinas.think.com

    HP has also produced a proposal for a CL based object package.  It was
    circulated a number of months ago in a similar manner to Xerox.  I suspect
    the meeting will discuss the merits of both proposals.

    Bob.
    p.s. MOre information on the HP proposal can be obtained from Alan Snyder
    (as@hplabs.csnet).

Obviously I have put my foot in my mouth, and I am sorry for the slight to the
HP proposal.  I remember discussing with Alan Snyder that he was working on
such a proposal, but I don't recall ever seeing a copy of it.  Either I never
got one or my memory is poor.  In any case, I apparently was wrong to
characterize the Common Loops proposal as the first major polished proposal.
(Thank you, Alan and Bob, for bringing this faux pas to my attention.)
It is, however, nevertheless a major polished proposal, and my other remarks
about it still apply.

(I am also under the impression that I am actually on the
CL-OBJECT-ORIENTED-PROGRAMMING mailing list, and thought there was little
activity on it for the last few months.  However, suddenly today about fifteen
messages spanning July and August have appeared in my mailbox all at once, with
no notice that anyone forwarded them in any special way.  Dick, can you fix me
up on the mailing list if I'm not already?)

∂16-Aug-85  1537	JAR@MIT-MC.ARPA 	Common LOOPS questions 
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 16 Aug 85  14:26:35 PDT
Date: Fri, 16 Aug 85 17:28:07 EDT
From: Jonathan A Rees <JAR@MIT-MC.ARPA>
Subject:  Common LOOPS questions
To: cl-object-oriented-programming@SU-AI.ARPA
cc: ALAN@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].615329.850816.JAR>

Are MLET and MLABELS intended to do lexical binding, like FLET and
LABELS, or dynamic binding, altering what SYMBOL-FUNCTION of the symbol
returns?  I find the description somewhat confusing, especially the
statement that "FLET binds the function cell" of a symbol.

Also: how does one obtain something which can be passed as a second
argument to SPECIALIZE?  Is there a METHOD macro to complete the ratio

  DEFUN : LAMBDA  ::  DEFMETHOD : METHOD  ?

In other words, is

  (defmethod foo ((x frob) y) body)

equivalent to a form consisting of user-visible primitives, e.g.,

  (progn (if (not (fboundp 'foo))
	     (setf (symbol-function 'foo) (make-discriminator)))
	 (setf (symbol-function 'foo)
	       (specialize (symbol-function 'foo)
			   (method ((x frob) y) body)))) ,

in the same way that

  (defun foo (x y) body)

is equivalent to

  (setf (symbol-function 'foo)
	(lambda (x y) (block foo body))) ?

Jonathan Rees

∂18-Aug-85  0025	Masinter.pa@Xerox.ARPA 	Re: Common LOOPS questions
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 18 Aug 85  00:25:34 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 18 AUG 85 00:26:52 PDT
Date: 18 Aug 85 00:27 PDT
From: Masinter.pa@Xerox.ARPA
Subject: Re: Common LOOPS questions
In-reply-to: Jonathan A Rees <JAR@MIT-MC.ARPA>'s message of Fri, 16 Aug
 85 17:28:07 EDT
To: JAR@MIT-MC.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA, ALAN@MIT-MC.ARPA
Message-ID: <850818-002652-1473@Xerox>

I think that METHOD is closer to FUNCTION than LAMBDA, e.g, I'd propose
something like:

(defmethod foo ((x frob) y) body)

=> 
(setf (symbol-function 'foo)
	(specialize (symbol-function 'foo)
			(method (lambda ((x frob) y) 
				(method-block (foo frob) body))))))

specialize can treat first-arg nil the same as first-arg as null
discriminator (getting rid of the fboundp check). method-block is there
for run-super. 

We've had some internal debates about mlet and mlabels. I think it is
clear that flet and  labels want to remain a lexical binding of
symbol-function. 

mlet and mlabels were added pretty much simultaneously with the shift
from discriminating symbols to discriminating functions.

I'm not sure mlet and mlabels are implementable (they aren't in our
implementation, which is about 4 weeks behind the paper.)




∂18-Aug-85  0139	masinter.PA@Xerox.ARPA 	correction on mlet & mlabels   
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 18 Aug 85  01:39:05 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 18 AUG 85 01:40:27 PDT
From: masinter.PA@Xerox.ARPA
Date: 18 Aug 85 1:39:58 PDT
Subject: correction on mlet & mlabels
To: cl-object-oriented-programming@su-ai.ARPA
Message-ID: <850818-014027-1490@Xerox>

I apologize for having forgotten the resolution of the mlet and mlabels
issue.

There's a problem in the paper, in that it talks about specialization of
function-cells, as JAR points out. There is a simple definition of the
semantics of mlet: it lexically binds the symbol to a discriminator
who's default implementation is to invoke the global symbol-function.

E.g.,

(mlet ((move ((a window) b) body))
	mletforms)

is roughly

(let ((move (a b)
	(if (typep a window)
	    body
	    (funcall 'move a b))))
    mletbody)



Sorry for the time-warp (work on CommonLoops has been pretty intense,
and I remembered the debate and forgot the resolution!)

Larry

∂18-Aug-85  0932	Moon@SCRC-STONY-BROOK.ARPA 	correction on mlet & mlabels    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Aug 85  09:32:14 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 298161; Sun 18-Aug-85 12:31:57-EDT
Date: Sun, 18 Aug 85 12:32 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: correction on mlet & mlabels
To: masinter.PA@XEROX.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: <850818-014027-1490@Xerox>
Message-ID: <850818123250.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 18 Aug 85 1:39:58 PDT
    From: masinter.PA@Xerox.ARPA

    There's a problem in the paper, in that it talks about specialization of
    function-cells, as JAR points out. There is a simple definition of the
    semantics of mlet: it lexically binds the symbol to a discriminator
    who's default implementation is to invoke the global symbol-function.

    E.g.,

    (mlet ((move ((a window) b) body))
	    mletforms)

    is roughly

    (let ((move (a b)
	    (if (typep a window)
		body
		(funcall 'move a b))))
	mletbody)

I doubt this is really what you meant.  May I offer

    (flet ((move (a b)
	    (if (typep a window)
		body
		(move a b))))
	mletforms)

which uses FLET rather than LET and uses the next outer binding of
the function-name MOVE rather than the global binding.  (This works
because FLET isn't LABELS; it can be done with LABELS with the
introduction of a GENSYM and two levels of LABELS.)

But then, maybe this isn't what you meant either; what if there is
already a more specific method for MOVE, say

    (defmethod move ((a storm-window) b) body...)

where storm-window is a specialization of window.  Does the MLET method
always get run first, or does it get inserted in order of specificity as
a DEFMETHOD-defined method would be?  The description of SPECIALIZE,
which appears to be connected with the implementation of MLET, is no
help in resolving this question.

It's ambiguities like this that made your proposal hard for me to
understand.

I'm also curious what is the motivation for lexical, rather than
dynamic, scoping of MLET-defined names.  For that matter, I'm curious
what the intended application for MLET is.  Your paper is generally
pretty weak on questions of motivation like this.

∂18-Aug-85  1130	masinter.PA@Xerox.ARPA 	Re: correction on mlet & mlabels    
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 18 Aug 85  11:18:42 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 18 AUG 85 11:18:55 PDT
From: masinter.PA@Xerox.ARPA
Date: 18 Aug 85 11:18:24 PDT
Subject: Re: correction on mlet & mlabels
In-reply-to: Moon@SCRC-STONY-BROOK.ARPA's message of Sun, 18 Aug 85
 12:32 EDT, <850818123250.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
To: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
cc: masinter.PA@Xerox.ARPA, cl-object-oriented-programming@SU-AI.ARPA
Message-ID: <850818-111855-1574@Xerox>

We tried to keep the "kernel" described in Section I simple and
straightforward, and keep all of the options that were possibly
controversial in Section II. The subsections of II are ordered very
roughly from benign to more controversial.

I'm a poor choice for defending or motivating mlet, but the other
author's of the paper are already on their way to IJCAI.

I agree that more examples and motivation are needed throughout the
paper, especially in some of the options section. In the interest of
brevity (and getting the paper out before IJCAI!) we kept it short.

Originally, we were using DEFUN to define methods, i.e., DEFUN changed
to say "if any of the required arguments are type-specified, then this
defun specializes rather than replaces the current definition."

Given that, the meaning of "mlet" is that it changes the specified
method lexically, rather than the discriminator.

At the risk of putting my foot in my mouth once more, I'll offer that
you're right about what mlet was intended to mean:

mlet can expand into a flet, not a let;
the result is not something that overrides more specific methods; in the
example, it doesn't override storm-window.

MLET was intended to be lexical, by analogy with FLET. In general, I
think dynamic binding of function cells is something to be avoided. 

If you have more areas that you'd like motivation or explaination for,
please let us know.. I expect that there are some parts that need to be
hashed out further as they are looked over by the rest of you.

Larry

∂24-Aug-85  1141	RPG  	Mlet & Mlabels
To:   cl-object-oriented-programming@SU-AI.ARPA 

The scoping of methods defined by these constructs is intended to be
exactly as they are for functions in Flet and Labels. The motivation for
their existence is not centered on an intended use so much as by neccesity
for the intended semantics.

The question is: what does a specialization specialize?  The alternative
that is most often suggested is that defmethod specializes the function
cell of a symbol. This alternative indicates that a specialization is an
operation on symbols. Except for providing a hatrack on which to hang the
specialization's hat, I don't see that there is any more need to talk
about the symbol with respect to specializations than there is when
discussing functions. The better alternative, I think, is that one
specializes functions.

If we talk, then, about the specialization of functions, the obvious
question is how does one specialize an Flet or Labels function? When the
distinction between Defun and Defmethod is made, the argument of Mlet and
Mlabels is complete.

			-rpg-

∂25-Aug-85  1931	FAHLMAN@CMU-CS-C.ARPA 	Meeting at IJCAI 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 25 Aug 85  19:31:15 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 25 Aug 85 22:32:14-EDT
Date: Sun, 25 Aug 1985  22:32 EDT
Message-ID: <FAHLMAN.12138081335.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   cl-object-oriented-programming@SU-AI.ARPA
Subject: Meeting at IJCAI


Could someone who made it to the object-oriented meeting at IJCAI send a
summary of what went on to this list?  Thanks.

-- Scott

∂30-Aug-85  1302	Kahn.pa@Xerox.ARPA 	Response to Masinter's multi-slot idea  
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 30 Aug 85  13:01:54 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 28 AUG 85 09:54:29 PDT
Date: 28 Aug 85 09:54 PDT
From: Kahn.pa@Xerox.ARPA
Subject: Response to Masinter's multi-slot idea
To: CL-Object-Oriented-Programming@su-ai.ARPA
cc: Kahn.pa@Xerox.ARPA
Message-ID: <850828-095429-155@Xerox>

Just before IJCAI Larry Masinter sent out the following message.  I
think its interesting.

I admit this is a wierd idea, and it didn't make it into the paper, but
I like it.

Individual structures have slots, in that each instance of the structure
has storage for each slot declared in its class. One view of a "slot" is
a special kind of method which implements primitive memory (store old
value, return new.)

In CommonLoops, there are multi-methods: methods which are invoked
depending on the classes of more than one argument. Multi-slots are a
logical extension of CommonLoops: memory which is (perhaps dynamically
allocated) for a cross product of instances of classes.

Here is an example:

A "graphics device" is a kind of stream which implements a variety of
operations in addition to the normal stream operations.

A "style" is a user-level description of the way in which character
might get rendered.

For each style and graphics device, there is an independent
specification of how that style can be rendered on the given graphics
device. 

(defstruct (graphics-stream (:include stream)) ...)
(defstruct style)

Now, the odd part is to make "defslot" the inverse of "defstruct":

(defslot (font default-font :allocation dynamic)  
           graphics-stream style) 

which would define

(graphics-stream-style-font <stream> <style>)

as the inverse of 

(setf (graphics-stream-style-font <stream> <style>) <font>)

The dyanamic allocation scheme seems to be the best choice, and could be
implemented via some double-hashing scheme, modulo garbage collector
problems.

In working with CommonLoops it took me a while to get used to the idea
that methods aren't really "owned" by a class.  Is a multi-method
"owned" by the classes it type specifies or does it simply use those
classes?  I believe that a good programming environment for CommonLoops
will allow the user to think about his or her programs as class-oriented
or selector-oriented.  While I still find it hard to think about
multi-slots (the idea that a slot is a part of single object is really
baked into my brain) they may turn out to be important.  There are so
many similarities between slots and methods in conventional
object-oriented programming that I think that if multi-methods turn out
to be important then so will multi-slots.

p.s.  Mark Stefik took extensive notes during the meeting at IJCAI and
we plan to send them out soon.

--ken kahn

∂30-Aug-85  1407	Kahn.pa@Xerox.ARPA 	Re: Response to Masinter's multi-slot idea   
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 30 Aug 85  13:02:15 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 28 AUG 85 09:59:22 PDT
Date: 28 Aug 85 09:59 PDT
From: Kahn.pa@Xerox.ARPA
Subject: Re: Response to Masinter's multi-slot idea
In-reply-to: Kahn.pa's message of 28 Aug 85 09:54 PDT
To: Kahn.pa@Xerox.ARPA
cc: CL-Object-Oriented-Programming@su-ai.ARPA
Message-ID: <850828-095922-156@Xerox>

In my previous message indentation indicating which comments were mine
and which were Larry's was lost.
My comments began with "In working with CommonLoops it took me ...".
Sorry.

∂02-Sep-85  2315	FAHLMAN@CMU-CS-C.ARPA 	Questions about Commonloops
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Sep 85  23:14:52 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 3 Sep 85 02:15:28-EDT
Date: Tue, 3 Sep 1985  02:15 EDT
Message-ID: <FAHLMAN.12140219125.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   cl-object-oriented-programming@SU-AI.ARPA
Cc:   fahlman@CMU-CS-C.ARPA
Subject: Questions about Commonloops


I've been waiting to hear the official news from the IJCAI meeting,
which I couldn't attend, but I have finally become impatient to put in
my two cents' worth.  Here goes...

I am admittedly a beginner at this game, but of the object-oriented
systems I've read about, I like the general approach of CommonLoops the
best.  Unlike flavors, it does not inflict a tremendous load of
complexity on the user who wants to do something simple.  CommonLoops is
a bit more powerful and extensible than the H-P proposal, without too
much more user-visible complexity.  As for Object Lisp, it has a certain
elegance, but to me its way of treating an object as a set of dynamic
function and variable bindings is very non-intuitive.  Perhaps I would
learn to like Object Lisp if I had a chance to play with it, and I hope
that a portable version is made available for this purpose, but I am not
drawn toward what I see in the Object Lisp manual.  The function-calling
syntax and the operator specialization of CommonLoops looks good to me,
and I think that the basic "class" level provides just about the right
amount of functionality for most of the things I would want to do.

Having said that, I must also say that there are a lot of unclear parts
in the CommonLoops proposal, and some apparent problems that I can't see
how to resolve.  Perhaps these are misunderstandings on my part.  As a
general comment, let me say that the Commonloops document suffers from a
critical lack of examples, both small and large.  Each of the proposed
mechansims should be accompanied by a little example.  It is very hard
to see exactly what is being proposed from text alone.  I know that the
authors of the document had to rush to get something out before IJCAI,
but now we badly need an expanded version of the proposal with lots of
examples.  We also need a more detailed sketch of how all this would be
implemented, if not the code itself, so that we can see clearly what all
of this costs in performance.

Perhaps the easiest way to proceed is for me to say what I think the
proposal says about certain issues and how certain things might be
implemented, and then people can tell me where I'm confused.

As I understand it, there is a new function-like object called a
discriminator that binds together a family of methods that all share the
same selector.  This discriminator does everything that a regular
function object does -- you can pass it around, funcall it or apply it
to arguments, lexically bind it to some selector symbol, globally bind
it by stuffing it into the selector symbol's function cell, and so on.
Even if this discriminator was defined by a bunch of (defmethod foo ...)
calls, it has no permanent tie to the symbol FOO.  You could move all of
the behaviors to BAR by (setf (symbol-function 'bar) (symbol-function
'foo)).  An anonymous discriminator can be created by
MAKE-DISCRIMINATOR, and additional methods can be added to the bundle by
SPECIALIZE.  A method can be removed from the bundle by REMOVE-METHOD.
There probably also should be a way to examine the constituent methods
of a discriminator -- this does not seem to be included in the proposal.

There seems to be some confusion in the description of MLET and MLABELS.
It appears that these are meant to lexically bind a new or modified
discriminator to some specifier symbol.  If so, the manual should not
speak of "binding the function cell", since the function cell is used
only to hold the global function definition; a different mechanism is
used by FLET and LABELS.  It is not clear whether MLET and MLABELS are
meant to create a new discriminator that is a copy of the old one for
the specifier in question, plus the new method, or whether the new
method is to be temporarily inserted into the existing discriminator.  I
think I would favor the former semantics.  This does not matter as long
as the discriminator is only referenced by way of the selector in
question, but someone else may have hold of the old discriminator.

Now, if the discriminator can indeed be used in all the ways that a
function can be, it seems obvious to implement it as a function
(probably a closure).  In its simplest (non-compiled) form, this
function would go down a pre-ordered list of type-restricted methods
(the "method precedence list" referred to in the paper), looking for one
whose type restrictions are satisfied.  The first winner gets funcalled
with the arguments that were passed in to the discriminator.  Presumably
the method bodies in a given discriminator may be a mixture of compiled
and uncompiled functions.

Obviously it is going to be pretty slow to do all that type-testing for
every call, since each test involves chasing multiple paths up the type
hierarchy.  I guess that this is where the cacheing comes in.  Once a
particular combination of a selector and some argument types have been
called, this combination can be hashed for future use.  However, it
would be very tricky to keep the cache consistent if discriminators are
not permanently tied to selectors, or if they don't have to have
selectors at all.  I guess the alternative is to hash not on the
selector symbol but on the discriminator itself.  One would still have
to flush all the hashtable entries for a discriminator every time a new
method is added, and changing the type hierarchy would invalidate large
parts of the cache, but in the usual case we could get a call down to N
get-type calls (one for each arg), one hashtable lookup, and an extra
funcall.

That's good enough for system development, maybe, but for production use
there has to be some way to say "I'm done with changing the type
hierarchy and with creating new methods, so now compile everything as
tightly as possible".  Certainly you should be able to avoid runtime
lookup if you call (foo (the wombat bar)), where foo has some method
that is applicable to wombats.  This will be especially important for
methods that are really slot-variable references, since even the cost of
a function-call would be unacceptable here.  There has to be some way to
give the compiler enough compile-time information to make it possible to
turn a slot reference into a simple inline SVREF.

A critical issue then, is exactly what can be changed when.  If a new
method is added to the system, is it necessary to go back and recompile
every function that calls the selector function in question?  That is
clearly impractical, so the alternative is to always do the type
dispatch (or at least the cache lookup), even in compiled code.  Or can
we perhaps treat selector functions as something like macros inline
functions -- if you change them, previously compiled functions retain
the old definition?  Or is there some way to get reasonable efficiency
without having to take this step?  In flavors the set of things that
might have to be recompiled is relatively localized; here things are
scattered all over known space.

This issue is closely related to the question of whether it is permitted
to create type-restricted methods for the built-in functions in Common
Lisp.  The CommonLoops proposal dances around this issue and does not
seem to take a clear stand.  Obviously, this cannot be allowed if these
specializations are to have a retroactive effect.  In that case, we
would never again be able to open-code a CAR or SVREF because someone
might someday come along and specialize it.  Even if such restrictions
were not retroactive, a user should probably be prevented from
specializing certain essential functions such as CAR, since this would
slow down all subsequent calls to that function by a huge factor.  It is
probably best just to forbid this, either for all built-in Common Lisp
functions or for a list of the commonly used ones that might be open
coded.

Some other issues:

The whole meta-class business sounds like a win, but without a much more
detailed description of what is controlled by the meta-class and how
this is specified, it is impossible to tell whether this is going to
fly.  I can't even formulate the proper questions in this area until the
system is spelled out a bit more.

It is unclear to me how multiple meta-classes can coexist peacefully.
What is the proper specificity ranking between two methods with selector
FOO, when one has its first argument restricted to instances of class
BAR and the other has its first argument restricted to instances of
flavor BLETCH?  (I assume that there can not be both a class BAR and a
flavor BAR.)  Can a method have one argument that is a class-instance
and another that is a flavor-instance?  Which meta-class controls what
in such a case?

In the list of built-in Common Lisp types that are disallowed as method
type specifiers one finds INTEGER, yet INTEGER is used in several of the
examples.  Perhaps it is only INTEGER with additional range arguments
that is disallowed?

The extension listed in II.A, individual specifiers, seems like a good
one.  However, I wonder if it is really advisable to twist up the
usual left-to-right specificity order in this one case.  Are indivduals
really so much more specific that they warrant this special treatment?
Some motivation for this odd exception would be useful.

In section II.B, I suppose that the variable-reference format is
necessary for emulating systems like flavors, but I wonder if the hairy
long form is really necessary.  If you're in a case this complex,
shouldn't you revert to the unambiguous function-call syntax rather than
resorting to a macro that hacks print names?

I don't understand the "annotated values" business, though I see roughly
what you are trying to do.  Some examples are critically needed here.
The scheme for changing the class of an existing instance likewise needs
some elaboration and an example.

For the method-slots business, I don't even see what you are trying to
do.  Totally mysterious.  There is an example there, but it's awfully
hard to follow.

Well, that's my first round of confusions.  I hope there's nothing fatal
here.

-- Scott

∂03-Sep-85  1353	Gregor.pa@Xerox.ARPA 	CommonLoops discussion.
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 3 Sep 85  13:50:25 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 03 SEP 85 13:48:41 PDT
Date: 3 Sep 85 13:48 PDT
From: Gregor.pa@Xerox.ARPA
Subject: CommonLoops discussion.
To: cl-object-oriented-programming@su-ai.ARPA
cc: Gregor.pa@Xerox.ARPA
Message-ID: <850903-134841-2978@Xerox>

This is an answer to the many people who have asked to be added to the
CommonLoops mailing list.

Because there is almost complete overlap between the people who have asked
to be on the CommonLoops mailing list and the people who are already on
cl-object-oriented-programming@su-ai we have moved the "general-interest"
discussion about CommonLoops to cl-object-oriented-programming.  

Messages which are only of interest to people at PARC (like bugs in the
current Interlisp implementation) should still be sent to CommonLoops↑.pa.

∂03-Sep-85  1412	Gregor.pa@Xerox.ARPA 	Re: Questions about Commonloops  
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 3 Sep 85  14:11:59 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 03 SEP 85 14:07:34 PDT
Date: 3 Sep 85 14:06 PDT
From: Gregor.pa@Xerox.ARPA
Subject: Re: Questions about Commonloops
In-reply-to: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>'s message of
 Tue, 3 Sep 85 02:15 EDT
To: Fahlman@CMU-CS-C.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA
cc: Brown.pa@Xerox.ARPA, Ricci.pa@Xerox.ARPA, deKleer.pa@Xerox.ARPA
Message-ID: <850903-140734-1030@Xerox>

A more complete answer to Fahlman's long message is forthcoming, but I
just wanted to say for now that we are working on a portable version of
Common
Loops which should help clarify many of the paper's weak points.  

We hope to have this portable version done in about 6 weeks.  The
precise
details of its availability are not finalized, but they will have the
flavor of "limited permission to copy and use Portable CommonLoops for
evaluation
and development".

In the meantime we appreciate comments, questions and suggestions about
CommonLoops or the CommonLoops paper.

Gregor Kiczales

∂03-Sep-85  1528	Gregor.pa@Xerox.ARPA 	the :allocation slot option 
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 3 Sep 85  15:26:34 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 03 SEP 85 15:27:05 PDT
Date: 3 Sep 85 15:26 PDT
From: Gregor.pa@Xerox.ARPA
Subject: the :allocation slot option
To: cl-object-oriented-programming@su-ai.ARPA
cc: Gregor.pa@Xerox.ARPA
Message-ID: <850903-152705-1132@Xerox>

A clarification about the possible values of the :allocation slot-option.
(section II.C.1, bottom of page 11) The values are symbols in the keyword
package not the lisp package as the paper implies.  So they can be one of:

:instance  -- default and means allocate in the instance at make object time.
:class -- shared value allocated in the class
:dynamic -- allocate in the instance on first access
:none  -- no slot is allocated, useful for not inheriting a slot (perhaps because
         the class being defined has a method for computing the value).

∂03-Sep-85  1544	Tribble.pa@Xerox.ARPA 	Re: CommonLoops discussion.
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 3 Sep 85  15:44:11 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 03 SEP 85 15:38:33 PDT
Date: Tue, 3 Sep 85 15:38:26 PDT
From: Tribble.pa@Xerox.ARPA
Subject: Re: CommonLoops discussion.
In-Reply-To: <850903-134841-2978@Xerox>
To: Gregor.pa@Xerox.ARPA
cc: cl-object-oriented-programming@su-ai.ARPA
Message-ID: <850903-153833-1144@Xerox>

Will this discussion get to CommonLoops↑?  I don't think I'm on the
other.  If I can be put on it, please tell me how.

Thanks,
Eric

∂03-Sep-85  2016	FAHLMAN@CMU-CS-C.ARPA 	Questions about Commonloops
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Sep 85  20:16:32 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 3 Sep 85 23:17:03-EDT
Date: Tue, 3 Sep 1985  23:16 EDT
Message-ID: <FAHLMAN.12140448779.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Gregor.pa@XEROX.ARPA
Cc:   Brown.pa@XEROX.ARPA, cl-object-oriented-programming@SU-AI.ARPA,
      deKleer.pa@XEROX.ARPA, Ricci.pa@XEROX.ARPA
Subject: Questions about Commonloops
In-reply-to: Msg of 3 Sep 1985  17:06-EDT from Gregor.pa at Xerox.ARPA


    We hope to have this portable version done in about 6 weeks.  The
    precise
    details of its availability are not finalized, but they will have the
    flavor of "limited permission to copy and use Portable CommonLoops for
    evaluation
    and development".

Some issues to keep in mind while fighting the internal battles at Xerox
over code availability:

1. No object oriented system can be seriously evaluated unless a good
fraction of the community has a chance to run it.  In practice, this
means that it must be portable, and it must be available to the Common
Lisp design community at little or no cost.

2. No object oriented system is going to become a standard for Common Lisp
unless it is very easy for every provider of Common Lisp to implement
the proposal.  In practice that means that there must be a decent
public-domain implementation that can be passed out to all of the
companies and easily installed in their systems.  If the code is tangled
up by proprietary agreements with Xerox, there is no hope that the other
companies will go along with CommonLoops as a standard, even if they
decide that they really like the system.

3. The best solution would be for Xerox to put the implementaiton into
the public domain.  That way, companies that like this package can pick
it up and start using it and there's no artificial barrier to making it
an official standard.  Xerox doesn't gain any tangible advantage from
this, but it will benefit all Common Lisp providers in the long run if
we can come up with an acceptable standard, or even if a good de facto
standard emerges.

4. If it is organizationally impossible for Xerox to put this code into
the public domain, the second best solution is for someone with no
commercial interests (e.g. one of the university groups) to develop a
public-domain implementation, perhaps with some informal advice from
individuals working at Xerox.  This amounts to an end-run around Xerox's
lawyers and bureaucrats.

5. The reason I raise this unpleasantness now is that if CMU, for
example, were to accept a Common Loops implementation from Xerox for
evaluation, that might make it legally impossible for us to go and
implement a public-domain version -- the Xerox lawyers could claim that
we stole their code.  So we should think this through before any code
gets shipped out.

I don't mean to pick on Xerox.  The same issues are raised by H-P's
stuff, by Object Lisp/LMI, and by Flavors/MIT (in matters of licensing
code, MIT behaves more like a large corporation than like a university).

-- Scott

∂04-Sep-85  1409	Masinter.pa@Xerox.ARPA 	Re: LISP has both pure and reference data types    
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 4 Sep 85  14:09:14 PDT
Received: from Cabernet.MS by ArpaGateway.ms ; 04 SEP 85 14:08:42 PDT
Date: 4 Sep 85 14:07 PDT
From: Masinter.pa@Xerox.ARPA
Subject: Re: LISP has both pure and reference data types
In-reply-to: Rem@IMSSS.ARPA's message of 4 Sep 85 06:01 PDT
To: Rem@IMSSS.ARPA
cc: CL-Object-Oriented-Programming@su-ai.ARPA
Message-ID: <850904-140842-1171@Xerox>

(For those on CL-Object-Oriented-Programming and not on
Common-Lisp@SU-AI, there's been a discussion of the value of having
"read-only" CONS cells.)

One of the issues in the CommonLoops design was whether it would be
possible to (:include cons) in a new defstruct. Expressing it in
CommonLoops terms, the issue is: what is the metaclass of ($ cons)?
Possibilities are 

(a) "built-in", i.e., you can discriminate on "cons" but can't :include
it (this is what we've defined currently)

(b) "structure" (I don't think that's acceptable for any cdr-coded
implementation unless structure knows explicitly about cdr-coding),
i.e., equivalent to requiring it look like you did something like
(defstruct (cons (:conc-name nil)) car cdr)

(c) "apparent-structure" (it looks like structure to any sub-class with
slots car and cdr, but doesn't necessarly have those slots), and 

(d) "abstract", with some other class which is the "real" class-of
built-in conses, e.g. (class-of (cons)) = ($ real-cons)

  - - - - - - - - - - - - - - -
CommonLoops currently picks (a), so as not to mess up current
implementations that think they know-all about cons cells, and because
of performance issues with consp and listp. With most of the other
choices, making another class of read-only CONSes is quite possible, and
seems like a reasonable application of the class hierarchy. Case (d)
would require only that any subclass of "cons" be able to deal with car
and cdr somehow. 

∂13-Sep-85  1541	Bobrow.pa@Xerox.ARPA 	[Masinter.pa: Re: Questions about Commonloops]  
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 13 Sep 85  15:40:59 PDT
Received: from Chardonnay.ms by ArpaGateway.ms ; 13 SEP 85 15:41:50 PDT
Date: 13 Sep 85 14:52 PDT
Sender: Bobrow.pa@Xerox.ARPA
Subject: [Masinter.pa: Re: Questions about Commonloops]
To: fahlman@c.cs.cmu.edu
cc: cl-object-oriented-programming@SU-AI.ARPA
From: Bobrow.pa@Xerox.ARPA, Kahn.pa@Xerox.ARPA, Masinter.pa@Xerox.ARPA
Message-ID: <850913-154150-2894@Xerox>

Scott,

Here are answers to the questions you asked about CommonLoops.
Your questions are in ""; our answers are in [[]].


"As I understand it, there is a new function-like object called a
discriminator that binds together a family of methods that all share the
same selector.  This discriminator does everything that a regular
function object does -- you can pass it around, funcall it or apply it
to arguments, lexically bind it to some selector symbol, globally bind
it by stuffing it into the selector symbol's function cell, and so on.
Even if this discriminator was defined by a bunch of (defmethod foo ...)
calls, it has no permanent tie to the symbol FOO.  You could move all of
the behaviors to BAR by (setf (symbol-function 'bar) (symbol-function
'foo)).  An anonymous discriminator can be created by
MAKE-DISCRIMINATOR, and additional methods can be added to the bundle by
SPECIALIZE.  A method can be removed from the bundle by REMOVE-METHOD.
There probably also should be a way to examine the constituent methods
of a discriminator -- this does not seem to be included in the
proposal."

[[There are two choices.  Either there is a new kind of funcallable
object in the system, which is of class discriminator, or one can use an
ordinary function in the symbol-cell, and provide a way of obtaining a
discriminator object associated with that function.  We have not seen
any need for it to be a closure, since there's little or no state.  The
function is composed from the definitions of the methods.  You are right
(and we use) "a way to examine the constituent methods of a
discriminator".  This is a method of the discriminator object.

The code for any method is wrapped with a compiler-let which points to
the method object, so that the run-super special form can know its
identity, and the identity of the discriminator.

Yes, the caching is so that, once you get into a discriminator with
specific classes, it doesn't have to chase up the type hierarchy. (The
chase isn't so complex, because each class contains a linearized list of
its superclasses, so you can use a simple iteration.) The cache is
global, and at any hint of trouble, the simplest thing to do is flush
the whole thing. Rebuilding cache entries (cache miss) isn't very
expensive. Yes, hashing on the discriminator itself is better than
hashing on the selector.

In the case of "all classic methods", i.e., all methods only
discriminate on the first argument, a cache-hit costs at most an extra
funcall and a type test. The type test is balanced off the ability to
assume the type throughout the rest of the definition, i.e, (defmethod
((x fixnum) ...) ...) can presume (declare (type fixnum x)). 

Presumably, but in an implementation-specific way, the second function
call can be eliminated. For example, in a typical implementation of Lisp
on stock hardware, the entry into the real method can be done by a jump
rather than a call, if calls are more expensive. In any case, the callee
(the implementation of the method) can't be dynamically changed or
relocated without the caller (the implementation of the discriminator)
knowing about it. Microcoded implementations have other mechanisms-- for
example, the type lookup and dispatch can be done entirely within the
original function call, if the call to the discriminator is detected by
the call microcode.

There's another option, which also reduces the cost of a cache-hit, but
uses a single-entry-cache-per-callee rather than a
many-entry-global-cache, that is simple and likely to be quite
effective. That is, for each discriminator, there is a single cache
element which knows the (exact) class that the discriminator was called
with, and the method that was invoked. Checking the cache involves
computing class-of, eq.

Where's the cache? The simplest place to put it is in the "function
definition cell", that is, the definition of the selector jumps right
into the "last" method, which begins with a simple preamble that asks,
"am I really the right method?" If not, it replaces itself with the
right definition and tries again. Under this scheme, the only additional
cost for a message pass (in the cache-hit case) is the type check!

Its likely that given (foo (the widget x)) that one might eliminate even
the initial function call. This is especially important for the
generated accessor methods, which must be given optimizers that "know"
how to compute them when the type of the argument is known. Better than
a user supplied declaration, the knowledge can be inferred directly if
you're in a method, e.g.

(defmethod paint ((x widget))
   ... (shape x) ...)

if shape is a slot of widget, it is fairly straightforward to infer that
it can be done with a direct access, especially if widget is a
"structure" (rather than, for example, a loops-class).

 

"The whole meta-class business sounds like a win, but without a much
more detailed description of what is controlled by the meta-class and
how
this is specified, it is impossible to tell whether this is going to
fly.  I can't even formulate the proper questions in this area until the
system is spelled out a bit more."

[[This is one of the major areas we are working on.  
Metaclasses at least have protocols for:
1) Instance creation
2) slot access 
     slow lookup and flexibility for various fast lookup schemes.
3) Computation of the class-precedence list
4) parsing of the actual defstruct (needless to say)
5) Determining what to do about inheriting from classes with
incompatible or at least different metaclasses.
]]

"If a new method is added to the system, is it necessary to go back and
recompile every function that calls the selector function in question?"

[[No, you never have to recompile callers! When you add a new method,
you have to clear any method caches which might be affected (we just
clear the global method-cache), and recompute (recompile) the
discriminator. Redefining an old method may have to do some of these but
not all -- it depends on how much the implementation knows about the
method other than how to get to it.]]

"This issue is closely related to the question of whether it is
permitted
to create type-restricted methods for the built-in functions in Common
Lisp.  The CommonLoops proposal dances around this issue and does not
seem to take a clear stand."

[[There's not a clear place to stand. Rather, there's a very narrow path
to tread between power and impact on current implementations. From the
point of view of simplifying the life of programmer's, its simplest to
make it so that you could specialize *any* built-in function. From the
point of view of the implementor, specializing built-in functions that
are declared inline can't work. CommonLoops flies and is useful taking
the most conservative stand -- i.e., no functions in Guy Steele's Silver
Book are specializable. A more aggressive stand can be taken later,
since it isn't incompatible at all.]]

"It is unclear to me how multiple meta-classes can coexist peacefully.
What is the proper specificity ranking between two methods with selector
FOO, when one has its first argument restricted to instances of class
BAR and the other has its first argument restricted to instances of
flavor BLETCH?  (I assume that there can not be both a class BAR and a
flavor BAR.)  Can a method have one argument that is a class-instance
and another that is a flavor-instance?  Which meta-class controls what
in such a case?"

[[The class name space itself is universal. (Class names are symbols, so
you can use packages, but one symbol denotes one and only one class.)
instances of "flavor-class" and "loops-class" aren't radically
different. The "include" relation is used for determining class
precidence. There's a method which determines the relation between two
classes, which returns one of 5 values

1) The classes are the same (EQ)
2) BAR includes BLETCH
3) BLETCH includes BAR
4) BAR and BLETCH are known disjoint (e.g., they're disjoint and it is
illegal to :include both simultaneously)
5) none of the above

This method can be specialized to handle special cases, e.g., if you
want to say that flavors can't mix in with classes, you can do it by
defining this as a method on flavors.

The only things the metaclass determines as far as method precedence
goes is what the ordered list of superclasses is. Thus, you can easily
have two methods, with selector FOO, when one has its first arg
restricted to BAR and the other has its first argument restricted to
instances of the flavor BLETCH. 

The current proposal requires explicit specification of the class of a
method (in the defmethod form).  We are considering an extension in
which the default class of the method is  determined by the
specification of the arguments.  Perhaps we should limit this to a class
specification of the first argument.  That is, defining BLETCH as a
flavor only says that methods which specify BLETCH are flavor-methods
(and have the implicit "with" and other kinds of method-combination
behavior) when BLETCH is the first-argument discriminator. This weighs
flavors-compatibility heavily toward those cases that actually occur in
flavors. ]]

"In the list of built-in Common Lisp types that are disallowed as method
type specifiers one finds INTEGER, yet INTEGER is used in several of the
examples.  Perhaps it is only INTEGER with additional range arguments
that is disallowed?" 

[[Yes, it was only the range-specifiers that were disallowed.]]

"The extension listed in II.A, individual specifiers, seems like a good
one.  However, I wonder if it is really advisable to twist up the
usual left-to-right specificity order in this one case.  Are indivduals
really so much more specific that they warrant this special treatment?
Some motivation for this odd exception would be useful."

[[We looked at a lot of examples. Division, for example, falls out
nicely, with divide-by-zero being a single special case. A lot of other
people have had troubles with that too.]]

"I don't understand the "annotated values" business, though I see
roughly what you are trying to do.  Some examples are critically needed
here."

[[Yes. This is an attempt to show how to do Loops-style active values,
as well as some of the more complex operations found in representation
systems such as range restrictions, when-filled methods and the like.
Its meant more as a hook for people who want to layer AI toolkits on top
of CommonLoops, and we're hoping to get more of them participating in
this area.]]

"In section II.B, I suppose that the variable-reference format is
necessary for emulating systems like flavors, but I wonder if the hairy
long form is really necessary.  If you're in a case this complex,
shouldn't you revert to the unambiguous function-call syntax rather than
resorting to a macro that hacks print names?"

[[This is a matter of religion, and we propose to have many churches --
we have different worshippers within Xerox.]]

"For the method-slots business, I don't even see what you are trying to
do.  Totally mysterious.  There is an example there, but it's awfully
hard to follow"

[[The idea is to capture the behavior that we already use in
Interlisp-D, and I spy in the Spice sources too. Its real common in most
operating systems. How do you TYO this stream? Well, you fetch the
TYO-FUNCTION of the stream and FUNCALL it. Wouldn't it be nice to have
it work the same way, but say it nicer? 

That's been the spirit of a lot of what CommonLoops is trying to do--
take current programming idioms and make them pretty. Thus, instead of
(taken from SEQ.SLISP):

(defun elt (sequence index)
  "Returns the element of SEQUENCE specified by INDEX."
  (if (listp sequence)
      (if (< index 0)
	  (error "~S: index too small." index)
	  (do ((count index (1- count)))
	      ((= count 0) (car sequence))
	    (if (atom sequence)
		(error "~S: index too large." index)
		(setq sequence (cdr sequence)))))
      (aref sequence index)))

you write

(defmethod elt ((sequence vector) index)
	(aref sequence index)

(defmethod elt ((sequence list) index)
	(if (< index 0)
	  (error "~S: index too small." index)
	  (do ((count index (1- count)))
	      ((= count 0) (car sequence))
	    (if (atom sequence)
		(error "~S: index too large." index)
		(setq sequence (cdr sequence))))


and get rid of all those seq-dispatch that hair up your code and make it
hard to read and modify. Maybe if you add a new method for a built-in
function you'll slow something down, but that's true if you redefine a
built-in function too. ]]

[[Regarding your questions about MLET and MLABELS, several people were
confused by the section in the paper.  We plan to re-write that section
soon and will send it out.]]

∂15-Sep-85  1627	Bobrow.pa@Xerox.ARPA
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 15 Sep 85  16:27:05 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 85 16:28:04 PDT
Date: 15 Sep 85 16:27 PDT
From: Bobrow.pa@Xerox.ARPA
To: fahlman@c.cs.cmu.edu
Cc: cl-object-oriented-programming@SU-AI.ARPA,bobrow.pa@Xerox.ARPA
Message-ID: <850915-162804-3646@Xerox>

Message-Id: <850913-154150-2894@Xerox>

Scott,

Here are answers to the questions you asked about CommonLoops.
Your questions are in ""; our answers are in [[]].


"As I understand it, there is a new function-like object called a
discriminator that binds together a family of methods that all share the
same selector.  This discriminator does everything that a regular
function object does -- you can pass it around, funcall it or apply it
to arguments, lexically bind it to some selector symbol, globally bind
it by stuffing it into the selector symbol's function cell, and so on.
Even if this discriminator was defined by a bunch of (defmethod foo ...)
calls, it has no permanent tie to the symbol FOO.  You could move all of
the behaviors to BAR by (setf (symbol-function 'bar) (symbol-function
'foo)).  An anonymous discriminator can be created by
MAKE-DISCRIMINATOR, and additional methods can be added to the bundle by
SPECIALIZE.  A method can be removed from the bundle by REMOVE-METHOD.
There probably also should be a way to examine the constituent methods
of a discriminator -- this does not seem to be included in the
proposal."

[[There are two choices.  Either there is a new kind of funcallable
object in the system, which is of class discriminator, or one can use an
ordinary function in the symbol-cell, and provide a way of obtaining a
discriminator object associated with that function.  We have not seen
any need for it to be a closure, since there's little or no state.  The
function is composed from the definitions of the methods.  You are right
(and we use) "a way to examine the constituent methods of a
discriminator".  This is a method of the discriminator object.

The code for any method is wrapped with a compiler-let which points to
the method object, so that the run-super special form can know its
identity, and the identity of the discriminator.

Yes, the caching is so that, once you get into a discriminator with
specific classes, it doesn't have to chase up the type hierarchy. (The
chase isn't so complex, because each class contains a linearized list of
its superclasses, so you can use a simple iteration.) The cache is
global, and at any hint of trouble, the simplest thing to do is flush
the whole thing. Rebuilding cache entries (cache miss) isn't very
expensive. Yes, hashing on the discriminator itself is better than
hashing on the selector.

In the case of "all classic methods", i.e., all methods only
discriminate on the first argument, a cache-hit costs at most an extra
funcall and a type test. The type test is balanced off the ability to
assume the type throughout the rest of the definition, i.e, (defmethod
((x fixnum) ...) ...) can presume (declare (type fixnum x)). 

Presumably, but in an implementation-specific way, the second function
call can be eliminated. For example, in a typical implementation of Lisp
on stock hardware, the entry into the real method can be done by a jump
rather than a call, if calls are more expensive. In any case, the callee
(the implementation of the method) can't be dynamically changed or
relocated without the caller (the implementation of the discriminator)
knowing about it. Microcoded implementations have other mechanisms-- for
example, the type lookup and dispatch can be done entirely within the
original function call, if the call to the discriminator is detected by
the call microcode.

There's another option, which also reduces the cost of a cache-hit, but
uses a single-entry-cache-per-callee rather than a
many-entry-global-cache, that is simple and likely to be quite
effective. That is, for each discriminator, there is a single cache
element which knows the (exact) class that the discriminator was called
with, and the method that was invoked. Checking the cache involves
computing class-of, eq.

Where's the cache? The simplest place to put it is in the "function
definition cell", that is, the definition of the selector jumps right
into the "last" method, which begins with a simple preamble that asks,
"am I really the right method?" If not, it replaces itself with the
right definition and tries again. Under this scheme, the only additional
cost for a message pass (in the cache-hit case) is the type check!

Its likely that given (foo (the widget x)) that one might eliminate even
the initial function call. This is especially important for the
generated accessor methods, which must be given optimizers that "know"
how to compute them when the type of the argument is known. Better than
a user supplied declaration, the knowledge can be inferred directly if
you're in a method, e.g.

(defmethod paint ((x widget))
   ... (shape x) ...)

if shape is a slot of widget, it is fairly straightforward to infer that
it can be done with a direct access, especially if widget is a
"structure" (rather than, for example, a loops-class).

 

"The whole meta-class business sounds like a win, but without a much
more detailed description of what is controlled by the meta-class and
how
this is specified, it is impossible to tell whether this is going to
fly.  I can't even formulate the proper questions in this area until the
system is spelled out a bit more."

[[This is one of the major areas we are working on.  
Metaclasses at least have protocols for:
1) Instance creation
2) slot access 
     slow lookup and flexibility for various fast lookup schemes.
3) Computation of the class-precedence list
4) parsing of the actual defstruct (needless to say)
5) Determining what to do about inheriting from classes with
incompatible or at least different metaclasses.
]]

"If a new method is added to the system, is it necessary to go back and
recompile every function that calls the selector function in question?"

[[No, you never have to recompile callers! When you add a new method,
you have to clear any method caches which might be affected (we just
clear the global method-cache), and recompute (recompile) the
discriminator. Redefining an old method may have to do some of these but
not all -- it depends on how much the implementation knows about the
method other than how to get to it.]]

"This issue is closely related to the question of whether it is
permitted
to create type-restricted methods for the built-in functions in Common
Lisp.  The CommonLoops proposal dances around this issue and does not
seem to take a clear stand."

[[There's not a clear place to stand. Rather, there's a very narrow path
to tread between power and impact on current implementations. From the
point of view of simplifying the life of programmer's, its simplest to
make it so that you could specialize *any* built-in function. From the
point of view of the implementor, specializing built-in functions that
are declared inline can't work. CommonLoops flies and is useful taking
the most conservative stand -- i.e., no functions in Guy Steele's Silver
Book are specializable. A more aggressive stand can be taken later,
since it isn't incompatible at all.]]

"It is unclear to me how multiple meta-classes can coexist peacefully.
What is the proper specificity ranking between two methods with selector
FOO, when one has its first argument restricted to instances of class
BAR and the other has its first argument restricted to instances of
flavor BLETCH?  (I assume that there can not be both a class BAR and a
flavor BAR.)  Can a method have one argument that is a class-instance
and another that is a flavor-instance?  Which meta-class controls what
in such a case?"

[[The class name space itself is universal. (Class names are symbols, so
you can use packages, but one symbol denotes one and only one class.)
instances of "flavor-class" and "loops-class" aren't radically
different. The "include" relation is used for determining class
precidence. There's a method which determines the relation between two
classes, which returns one of 5 values

1) The classes are the same (EQ)
2) BAR includes BLETCH
3) BLETCH includes BAR
4) BAR and BLETCH are known disjoint (e.g., they're disjoint and it is
illegal to :include both simultaneously)
5) none of the above

This method can be specialized to handle special cases, e.g., if you
want to say that flavors can't mix in with classes, you can do it by
defining this as a method on flavors.

The only things the metaclass determines as far as method precedence
goes is what the ordered list of superclasses is. Thus, you can easily
have two methods, with selector FOO, when one has its first arg
restricted to BAR and the other has its first argument restricted to
instances of the flavor BLETCH. 

The current proposal requires explicit specification of the class of a
method (in the defmethod form).  We are considering an extension in
which the default class of the method is  determined by the
specification of the arguments.  Perhaps we should limit this to a class
specification of the first argument.  That is, defining BLETCH as a
flavor only says that methods which specify BLETCH are flavor-methods
(and have the implicit "with" and other kinds of method-combination
behavior) when BLETCH is the first-argument discriminator. This weighs
flavors-compatibility heavily toward those cases that actually occur in
flavors. ]]

"In the list of built-in Common Lisp types that are disallowed as method
type specifiers one finds INTEGER, yet INTEGER is used in several of the
examples.  Perhaps it is only INTEGER with additional range arguments
that is disallowed?" 

[[Yes, it was only the range-specifiers that were disallowed.]]

"The extension listed in II.A, individual specifiers, seems like a good
one.  However, I wonder if it is really advisable to twist up the
usual left-to-right specificity order in this one case.  Are indivduals
really so much more specific that they warrant this special treatment?
Some motivation for this odd exception would be useful."

[[We looked at a lot of examples. Division, for example, falls out
nicely, with divide-by-zero being a single special case. A lot of other
people have had troubles with that too.]]

"I don't understand the "annotated values" business, though I see
roughly what you are trying to do.  Some examples are critically needed
here."

[[Yes. This is an attempt to show how to do Loops-style active values,
as well as some of the more complex operations found in representation
systems such as range restrictions, when-filled methods and the like.
Its meant more as a hook for people who want to layer AI toolkits on top
of CommonLoops, and we're hoping to get more of them participating in
this area.]]

"In section II.B, I suppose that the variable-reference format is
necessary for emulating systems like flavors, but I wonder if the hairy
long form is really necessary.  If you're in a case this complex,
shouldn't you revert to the unambiguous function-call syntax rather than
resorting to a macro that hacks print names?"

[[This is a matter of religion, and we propose to have many churches --
we have different worshippers within Xerox.]]

"For the method-slots business, I don't even see what you are trying to
do.  Totally mysterious.  There is an example there, but it's awfully
hard to follow"

[[The idea is to capture the behavior that we already use in
Interlisp-D, and I spy in the Spice sources too. Its real common in most
operating systems. How do you TYO this stream? Well, you fetch the
TYO-FUNCTION of the stream and FUNCALL it. Wouldn't it be nice to have
it work the same way, but say it nicer? 

That's been the spirit of a lot of what CommonLoops is trying to do--
take current programming idioms and make them pretty. Thus, instead of
(taken from SEQ.SLISP):

(defun elt (sequence index)
  "Returns the element of SEQUENCE specified by INDEX."
  (if (listp sequence)
      (if (< index 0)
	  (error "~S: index too small." index)
	  (do ((count index (1- count)))
	      ((= count 0) (car sequence))
	    (if (atom sequence)
		(error "~S: index too large." index)
		(setq sequence (cdr sequence)))))
      (aref sequence index)))

you write

(defmethod elt ((sequence vector) index)
	(aref sequence index)

(defmethod elt ((sequence list) index)
	(if (< index 0)
	  (error "~S: index too small." index)
	  (do ((count index (1- count)))
	      ((= count 0) (car sequence))
	    (if (atom sequence)
		(error "~S: index too large." index)
		(setq sequence (cdr sequence))))


and get rid of all those seq-dispatch that hair up your code and make it
hard to read and modify. Maybe if you add a new method for a built-in
function you'll slow something down, but that's true if you redefine a
built-in function too. ]]

[[Regarding your questions about MLET and MLABELS, several people were
confused by the section in the paper.  We plan to re-write that section
soon and will send it out.]]


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

∂17-Sep-85  2101	FAHLMAN@C.CS.CMU.EDU
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 Sep 85  21:01:40 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 18 Sep 85 00:02:31-EDT
Date: Wed, 18 Sep 1985  00:02 EDT
Message-ID: <FAHLMAN.12144127086.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Bobrow.pa@XEROX.ARPA
Cc:   cl-object-oriented-programming@SU-AI.ARPA, touretzky@A.CS.CMU.EDU
In-reply-to: Msg of 15 Sep 1985  19:27-EDT from Bobrow.pa at Xerox.ARPA


Thanks for all the answers.  It looks good so far.  I look forward to
seeing your extended descriptions of the meta-class machinery, MLET and
MLABELS, some examples of annotated values, and some additional examples
of method slots.

One thing that I didn't notice before was that the type-restrictions on
the arguments of a discriminating function would indeed serve as a type
declaration for that argument variable.  (This should be made explicit,
so that it is clear that the argument variable cannot alter be set to
something of the wrong type.)  As you say, given this declaration it
should be relatively straightforward to open-code many slot references,
but I am still a bit worried about being able to do this in more complex
situations.  When the details of this are worked out, we will all see
whether the efficiency is sufficient in the important cases, I guess.

I agree that the safe thing to do for now is to forbid specialization of
any of the built-in functions in code that is meant to be portable.
Everything in Common Lisp is potentially compiled inline at present, and
there are many cases in which the simpler cases of complex functions
like Format are source-transformed into something that does not go
through the original function's value cell.  I suppose we could allow a
built-in function to be specialized with the understanding that the
change is not retroactive, but only applies to user-level code compiled
after the specialization is created.

Both Dave Touretzky and Rob Maclachlan have independently raised
questions about the assumption (which CommonLoops shares with flavors)
that if a class adds a slot (access function) named "FOO" when it
already has a "FOO" by inheritance, then these are necessarily the same
slot.  There are a lot of situations where this is treacherous.
Touretzky has written up a critque/proposal on this, and I will
encourage him to send it in to this mailing list.

-- Scott

∂18-Sep-85  0140	Bobrow.pa@Xerox.ARPA 	Notes IJCAI mewtting of Common Lisp Object Committee 
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 18 Sep 85  01:39:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 SEP 85 16:20:31 PDT
Date: 17 Sep 85 16:20 PDT
From: Bobrow.pa@Xerox.ARPA
Subject: Notes IJCAI mewtting of Common Lisp Object Committee
To: cl-object-oriented-programming@SU-AI.ARPA
cc: Bobrow.pa@Xerox.ARPA
Message-ID: <850917-162031-223@Xerox>

Notes from an informal meeting of the

Common Lisp Object Committee
International Joint Conference on Artificial Intelligence
Math Sciences Auditorium
UCLA Campus
22 August 1985

**Caveat:  These notes were taken by Mark Stefik at the meeting for his
own purposes and were extracted from him under duress.  These are not
official and are not necessarily representative of the opinion of the
Common Lisp Objects Committee, Xerox Corporation, the United States
Government, or the Blue Petunia Society.  This summary has been checked
for accuracy only by the three speakers, Snyder, Drescher and Bobrow,
and with a few other randoms from Xerox.  It is provided for the purpose
of stimulating discussion of what should be done next, and expansion and
clarification of issues discussed at the meeting (and hopefully not to
derail us into issues concerning the accurate or selective or
(un)balanced reporting of the meeting, or the official positions of
companies now, etc)
----

Richard Gabriel of Lucid opened the meeting with a few words about
Common Lisp, and the observation that there were various kinds of
unfinished business that have been recognized since the publication of
the silver book.  One of the major areas of work is a Common Lisp
standard for object-oriented programming.  The purpose of this committee
was to create recommendations for this standard.

Ken Kahn then spoke about the purposes of this meeting as follows:

o	To present proposals for an objects extension to Common Lisp.
o	To discuss the technical aspects of the proposals
o	To begin a focused dialog in the objects subcommittee that
	will continue beyond the meeting

He outlined the following for the next few months after the meeting:

o	Continued discussion on the net
		- Experimentation in the community with shared implementations
		- Refinement and clarification of specifications

o	Work towards a consensus on technical goals and specifications

o	Prepare a recommendation for Common Lisp

The rest of the meeting was divided into two parts.  In the first part,
three proposals for an object standard were presented in 20 minutes
each.  In the last hour, the proposals were discussed.

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



The first proposal was presented by Alan Snyder of Hewlett-Packard.  (He
declined to give his system a name, so it will be referred to as the
"Snyder proposal".)  A printed version of the proposal is available from
Snyder. (snyder%hplabs@csnet-relay)

Snyder observed that "objects encapsulate interesting behavior".  He
defined encapsulation as identifying constraints on manipulation and
user interface.  He observed that although neither Common Loops nor
ObjectLisp say anything about encapsulation, either could get some
aspects of encapsulation by using the package system.  However, that
style of encapsulation differs from the object-centered
encapsulation of traditional object-oriented languages, and has
problems supporting multiple representations and distributed objects.
Snyder identified the problem of encapsulating some of the information
in a super class from a subclass -- an idea not usually found in object
systems.

Snyder said that the notion of a "kernel" was by itself inadequate,
because it fails to provide for commonality in a community of users.  He
identified some requirements of the community:

o	Need code you can read
o	DARPA wants code that can be maintained
o	A portable implementation of an object dialect.

Snyder identified the following goals of his proposal:

o	Language extension, not an implementation kernel.
o	Common subset - base for nonstandard extensions
o	Support and encourage object-oriented programming
o	Include only well-understood features
o	Avoid controversial features
o	Avoid compromising capabilities for encapsulation
o	Efficiency permitted for production code
	e.g., direct access to instance variables w/o mapping tables.

He also identified the following features of his proposal.

o	modified Flavors syntax
o	object-centered encapsulation
o	multiple inheritance
o	support of class redefinition
o	class-defined subtyping and equivalence
o	concern for separate compilation issues
o	language has been implemented and used.

He identified the following as missing from the proposal

o	access to inherited ivs
o	merging of ivs from inherited classes
o	method combination

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

The next presentation was Object-Lisp presented by Gary Drescher of MIT.
Drescher has licensed the system to LMI who is going to sell it.
Drescher was introduced by Dexter Pratt from LMI who said that LMI had
been recoding the window system in Object Lisp and were very happy with
it.  Documentation of Object-Lisp is available from LMI.

The goal of Object Lisp is to make it be a rational superset of Lisp
used for all programming, not just a set of advanced features.

Status of ObjectLisp

o	Pure Common Lisp implementation
o	Available on Lambdas in September
o	Inexpensive commercial license will be available
o	Informal distribution will be encouraged for royalty-ree evaluation. 

Objects are a set of bindings for methods and variables. 
Objects reside in sets of nested environments.
Variables and methods are symetric. 
Instance variables, class variables, instance functions, and class
functions can all be defined in the language.

Aside.  This proposal seems very Scheme-like.  But there is little
"declarative" sense of objects. 

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

The next presentation was about "CommonLoops" by Daniel Bobrow of Xerox
PARC.  Danny said the goals of CommonLoops were:

o	Compatibility -- with Lisp programming.
o	Small kernel -- easy to implement, understand. 
o	Powerful base -- for interesting applications.
o	Universal kernel -- implement Flavors, Loops, Smalltalk, ...
			-- next generation knowledge representation languages
o	Efficiency -- no special hardware required.

CommonLoops unifies Lisp and Objects so that type=class (defstruct
extensions), slot=slot (same terminology), function~method (parallel
syntax), function call ~ message send (identical syntax).

He gave examples of defining classes and methods, and multi-methods.  He
talked about how by defining many things as objects in CommonLoops, this
naturally provided hooks for extensibility

o	Discriminator Objects e.g. load time protocols
o	Method Objects e.g. compile time protocol
o	Class Objects e.g. slot accss protocol

He gave an example of using CommonLoops hooks to implement Flavors-style
method combination.

o	Flavors metaclass
	- class precedence list
	- slot-access methods 

o	Flavor discriminator
	load-time protocol

o	Flavor method
	(implicit with notation for slots)

Danny described the CommonLoops kernel as containing

o	defstruct extended for classes
o	metaclasses
o	defmethod like defun
o	simple method combination (run-super)

CommonLoops extensions include a much longer list.  (not included here)

***************************************************
Question Period

A lot of people raised questions.  Some people I didn't know, and some
questions went by too quickly to take notes.
--

Martin Griss (HP):  Isn't the issue we should decide whether or not we
want object oriented programming to look different, or not?

Bobrow: I think that it is more important to understand the various
proposals and what they make easy and hard than to start out with a
particular stand or take a vote on our current feelings.
--

Dave Dyers (Symbolics): Moon is working on a proposed new version of
Flavors that is very similar to CommonLoops.  This is not official
Symbolics position, but I think CommonLoops is a good proposal, and
compatible with existing object languages.
--

JonL White (Lucid): The three panelists are all from the research
community.  All the proposals are new.  In the original Common Lisp
effort, there was 3-10 years of experience with the various lisps.  None
of these has that.  I like CommonLoops because it makes possible the
kind of variance and experimentation.  Lisp's job is to absorb, rather
than to become.

Snyder: But CommonLoops does not support encapsulation.

Drescher: ObjectLisp is more conservative than CommonLoops because it
does not change the Lisp part of the language.

Bobrow: CommonLoops does not prescribe an approach to encapsulation, but
is not incompatible with having it.  It's just not in the kernel.  We
need to discuss the requirements for encapsulation over the net after
this meeting.
--

Touretsky (CMU): ObjectLisp throws away encapsulation.  In CommonLoops
one could specify this on a per slot basis.

Drescher: It is possible that one could use packages to do
encapsulation.

Masinter:  Packages have been the major encapsualtion mechanism inCommon
Lisp, and we should not invent new mechanisms if old ones do the job
well enough.

-------

Atardi:  You have an opportunity now as you define objects to take into
account things that will be needed for parallelism in future machines.
To support concurrent execution should use something more like actors.
What you need is

o	asynchronous send.  [with continuation]
o	synchronization methods (e.g., by locking objects)

Bobrow:  This seems premature, and also not particularly specific to
objects.  For example, one could have an asynchronous Eval.

Dyer: Current lisps don't handle concurrency well.  But this is beyond
scope of this meeting.
--

Jed Harris (Intel):  Alan Snyder's concern with encapsulation is valid,
but I'd want to make sure I could achieve it without sacrificing
efficiency. 
 
Snyder: CommonLoops can implement anything.  (so what!)  The real issue
is, what do we provide the user.  Packages may not provide good enough
encapsulation.
--

Halpern (IBM): Macro-expansions.  When do they happen?  I'm confused
about them and the Object-Lisp proposal.

Drescher:  Macro-expansion happens at DEFOBFUN-time,
which is just compile-time for compiled code, DEFUN-time for interpreted
code (ie, macro-expansion semantics becomes the same for compiled &
evaluated code,
which seems like the right thing anyway, but that's another story).
Macro definitions are always global; you can't shadow them in objects.
What is not doable in ObjectLisp is running an interpreted function that
wants to macro-expand differently on different calls.

---
Bobrow:  What I worry about in Object Lisp is the accidental capture of
names for functions.  For example, if square-root is redefined in turtle
to work only in the domain of positive integers from 1 to 1000 (so it
can work fast by table lookup, say), then in a call to SINE, the wrong
square-root might be called.  This would work better in a lexically
scoped system such as Scheme.

Drescher:  That is a problem, but we haven't run into it.
--

Jonathan Reese (MIT): The question of what can be overloaded is
orthogonal ...   The problem with Tell/Ask is a problem of modularity.
You don't want the caller (sender) to have to know whether things are
implemented as methods, or what.
--

JonL (Lucid): The issue is more than a technical one.  We don't want a
technical revolution.  We want the ability to change things
incrementally.
--

Pitman (Symbolics):  I want to say a few things about each of the
proposals.

	o	I like the Snyder proposal for encapsulation.  That's important.
Packages are clumsy in Common Lisp.  They are hard to create, and hard
to move in and out of.  It is important to get some support for data
abstraction that doesn't use packages.

	o	The Object Lisp proposal is hard to deal with because it changes the
scoping rules too drastically.  Normal programmers will have trouble.

	o	CommonLoops is the first serious propoal which dispatches on multiple
arguments.  That's an interesting idea.

--
Lieberman (MIT):  Should messages be objects?

Bobrow: This can be implemented in CommonLoops to overloading the
"method-for" function in the funcall..
--

Carnese (Schlumberger): I want to raise a question of method
combination.  Even though I wrote a thesis this thick on the subject
and did not come up with a satisfactory answer, it's important to users
and we should take a cut at simplifying the language of method
combination.  We should try to find a right way.
There is also the issue of combinating of lexical and dynamic scoping in
Object Lisp.  How will the compiler know whether it is in the object or
a free variable?  

Drescher:  All objects inherit eventually from some global context which
is itself an object.
--

Pitman:  Isn't it a violation of data abstraction in Object Lisp to have
to know whether an object has a variable "x"?
--

Greenblatt: The primary feature of Object Lisp is the ability to add
variables after an object is in existence.

Bobrow: CommonLoops supports this through dynamic variables.
--

Snyder:  I think that we should worry about the quality of error
messages.
--

Pitman:  I suggest that CommonLoops needs a facility to say "I will
eventually defun x"
--

Greenblatt: We need to know whether the commonly called functions have
more than one method.  I heard Bobrow's statistics, but those are static
and not dynamic measurements.
--
? (BBN): Speaking as a user, hurray for "with syntax" and method
combination.
--
? (Symbolics): CommonLoops is the main proposal which is in fact
addressing the needs of the user community.  Compared with Snyder's
proposal, which is prescriptive; and ObjectLisp has not been concerned
about compatibility with other languages.
--
Pitman:  It is  important that the object language we adopt not prevent
us from working the way we do now.

∂18-Sep-85  0811	Moon@SCRC-STONY-BROOK.ARPA 	Name conflicts for names of instance variables 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Sep 85  08:11:02 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 315738; Wed 18-Sep-85 11:07:22-EDT
Date: Wed, 18 Sep 85 11:11 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Name conflicts for names of instance variables
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: cl-object-oriented-programming@SU-AI.ARPA, touretzky@A.CS.CMU.EDU
In-Reply-To: <FAHLMAN.12144127086.BABYL@C.CS.CMU.EDU>
Message-ID: <850918111125.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 18 Sep 1985  00:02 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
    ....Both Dave Touretzky and Rob Maclachlan have independently raised
    questions about the assumption (which CommonLoops shares with flavors)
    that if a class adds a slot (access function) named "FOO" when it
    already has a "FOO" by inheritance, then these are necessarily the same
    slot.  There are a lot of situations where this is treacherous.

Why should name conflicts for instance slots be treated any differently
from name conflicts for functions, or anything else that has a name?  In
other words, what are packages for?

A well-known problem with Flavors as traditionally constituted is the
use of keywords for accessing instance variables.  Using keywords in
this way means that the programmer can't take advantage of packages to
resolve name conflicts.  I think this is a separate problem, not
directly related to inheritance rules for instance slots.  Indeed, the
problem arises for all messages, not just instance-variable-accessing
messages.  I think the solution is obvious: using keywords in this way
was a mistake.

Over the past year we have been evaluating experience with the first and
second generation designs of Flavors, to unravel the good features and the
bad features of Flavors.  This is one of several problems we're aware of.

    Touretzky has written up a critque/proposal on this, and I will
    encourage him to send it in to this mailing list.

I'd like to encourage him also, in spite of my argument above that the
problem is a non-problem. 

∂18-Sep-85  1558	DT50@A.CS.CMU.EDU 	slot shadowing  
Received: from A.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Sep 85  15:57:04 PDT
Date: 18 Sep 85 18:55 EDT
From: Dave.Touretzky@A.CS.CMU.EDU
To: bobrow.pa@XEROX.ARPA
Subject: slot shadowing
CC: cl-object-oriented-programming@SU-AI.ARPA

	Why Automatic Shadowing of Slots Is Essential

		   Dave Touretzky, CMU


In this note I will try to explain why automatic shadowing of slots is
essential to a Common Lisp flavor system.  I have read the ObjectLisp
document distributed at the IJCAI Common Lisp meeting in Los Angeles, which
I attended, but I am not otherwise familiar with the CommonLoops or HP
flavors proposals.  I hope people who do understand these proposals will
respond to the points raised here.

Example 1:  Customizing a Flavor.  A user of a hairy window system wants to
create his own flavor of window, called PORTHOLE, which is like an ordinary
window in most respects.  But PORTHOLE has an instance variable N which the
user can access and modify.  He defines PORTHOLE as a subtype of WINDOW, and
writes methods GET-N and SET-N for accessing and setting N.  Unbeknownst to
him, however, the window system is already using N as the name of a slot.

Suggested behavior:  instances of PORTHOLE should have two slots named N,
and one of them, WINDOW's N, should be shadowed for PORTHOLE's methods.
Let P1 be an instance of PORTHOLE.  Sending P1 a GET-N message should access
the N the user intended:  PORTHOLE's N.  Sending P1 a CLEAR-SCREEN message
should access the N inherited from WINDOW, since the CLEAR-SCREEN method is
itself inherited from WINDOW and the user knows nothing about the shadowing
of WINDOW's N by his own use of the name.

Example 2:  Replacing a Method.  Suppose a hacker who is familiar with the
window system wants to create his own type of PORTHOLE, HACKPORT, that uses
a different CLEAR-SCREEN method.  Since HACKPORT is an instance of PORTHOLE,
references to N by a HACKPORT method will normally be interpreted as
references to PORTHOLE's N rather than WINDOW's N.  So we need a way to
reference the shadowed N in methods defined for PORTHOLE or HACKPORT.  I
won't suggest a notation for this here.  However, the next example argues
that we must reference shadowed slots by a point on their inheritance path,
e.g.  by saying PORTHOLE's N; we can't just say something like SHADOWED-N
and expect the reference to be resolved.

Example 3:  Combining Orthogonal Flavors.  A naive user has available
to him two predefined flavors, WINDOW and STACK, about whose internals
he knows nothing.  He wants to build a flavor called VISIBLE-STACK,
which is a stack whose contents are constantly displayed in a window.
He defines VISIBLE-STACK as a subtype of both WINDOW and STACK, not
knowing that both these flavors contain instance variables named N.

Suggested behavior:  Let S1 be an instance of VISIBLE-STACK.  Sending
a POP-STACK message to S1 should access STACK's N, while sending a
SET-FONT message to S1 should access WINDOW's N.  

Problem:  let METHA be a method defined for VISIBLE-STACK.  How should
references to N be interpreted inside METHA?  If VISIBLE-STACK has its own
instance variable named N, then this N should shadow both WINDOW's N and
STACK's N.  But if there is no N defined at the level of VISIBLE-STACK, then
references to N inside METHA should generate an error message:  "N is an
ambiguous slot reference."

Problem:  how do we write a new CLEAR-SCREEN method for VISIBLE-STACK?  We
will need notation to explicitly specify that we want to access the
shadowed WINDOW's N rather than the shadowed STACK's N.

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

It is obvious what the ObjectLisp solution to this set of problems would
be:  place each N in a different package to keep the names distinct.  I find
this highly unsatisfactory.  In the degenerate case, each flavor will end up
with its own associated package in which instance variables are defined.  A
user of the ELEPHANT flavor will have to contend with slot names from a
host of packages, e.g.  ELEPHANT:TRUNK, MAMMAL:HAIR-COLOR,
VERTEBRATE:SPINE-LENGTH, ANIMAL:HABITAT, LIVING-THING:LIFESPAN, etc.  Of
course the packages could be organized into a hierarchy mimicing the flavor
hierarchy, so that ELEPHANT:HABITAT would reference ANIMAL:HABITAT unless
shadowed, but that wouldn't provide for detection of ambiguous slot
references as required in Example 3 above.  Furthermore, unless the
flavor/package duality was rigidly enforced by the flavor system, the user
could create quite a mess by hacking the package stuff by hand.

Finally, if packages are intended to be used for encapsulating separate
software modules, then we must allow each package to have its own set of
flavors defined within that package.  Thus, in my hairy robot system, the
flavor ARM:STACK may describe a stack of blocks, while PLANNER:STACK may be
an entirely different type of flavor, such as a stack of goals.  If flavors
usurp the package system for other tasks, like slot shadowing, the original
purpose of packages -- encapsulation of software modules -- will be hindered.

----

∂18-Sep-85  1709	Moon@SCRC-STONY-BROOK.ARPA 	slot shadowing   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Sep 85  17:09:15 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 316356; Wed 18-Sep-85 20:05:08-EDT
Date: Wed, 18 Sep 85 20:09 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: slot shadowing
To: Dave.Touretzky@A.CS.CMU.EDU
cc: bobrow.pa@XEROX.ARPA, cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: The message of 18 Sep 85 18:55-EDT from Dave.Touretzky@A.CS.CMU.EDU
Message-ID: <850918200921.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 18 Sep 85 18:55 EDT
    From: Dave.Touretzky@A.CS.CMU.EDU

	    Why Automatic Shadowing of Slots Is Essential

		       Dave Touretzky, CMU


    In this note I will try to explain why automatic shadowing of slots is
    essential to a Common Lisp flavor system.  I have read the ObjectLisp
    document distributed at the IJCAI Common Lisp meeting in Los Angeles, which
    I attended, but I am not otherwise familiar with the CommonLoops or HP
    flavors proposals.  I hope people who do understand these proposals will
    respond to the points raised here.

    Example 1:  Customizing a Flavor.  A user of a hairy window system wants to
    create his own flavor of window, called PORTHOLE, which is like an ordinary
    window in most respects.  But PORTHOLE has an instance variable N which the
    user can access and modify.  He defines PORTHOLE as a subtype of WINDOW, and
    writes methods GET-N and SET-N for accessing and setting N.  Unbeknownst to
    him, however, the window system is already using N as the name of a slot.

    Suggested behavior:  instances of PORTHOLE should have two slots named N,
    and one of them, WINDOW's N, should be shadowed for PORTHOLE's methods.
    Let P1 be an instance of PORTHOLE.  Sending P1 a GET-N message should access
    the N the user intended:  PORTHOLE's N.  Sending P1 a CLEAR-SCREEN message
    should access the N inherited from WINDOW, since the CLEAR-SCREEN method is
    itself inherited from WINDOW and the user knows nothing about the shadowing
    of WINDOW's N by his own use of the name.

Packages solve this.

    Example 2:  Replacing a Method.  Suppose a hacker who is familiar with the
    window system wants to create his own type of PORTHOLE, HACKPORT, that uses
    a different CLEAR-SCREEN method.  Since HACKPORT is an instance of PORTHOLE,
    references to N by a HACKPORT method will normally be interpreted as
    references to PORTHOLE's N rather than WINDOW's N.  So we need a way to
    reference the shadowed N in methods defined for PORTHOLE or HACKPORT.  I
    won't suggest a notation for this here.  However, the next example argues
    that we must reference shadowed slots by a point on their inheritance path,
    e.g.  by saying PORTHOLE's N; we can't just say something like SHADOWED-N
    and expect the reference to be resolved.

Packages provide a suitable notation.

    Example 3:  Combining Orthogonal Flavors.  A naive user has available
    to him two predefined flavors, WINDOW and STACK, about whose internals
    he knows nothing.  He wants to build a flavor called VISIBLE-STACK,
    which is a stack whose contents are constantly displayed in a window.
    He defines VISIBLE-STACK as a subtype of both WINDOW and STACK, not
    knowing that both these flavors contain instance variables named N.

    Suggested behavior:  Let S1 be an instance of VISIBLE-STACK.  Sending
    a POP-STACK message to S1 should access STACK's N, while sending a
    SET-FONT message to S1 should access WINDOW's N.  

Packages solve this.

    Problem:  let METHA be a method defined for VISIBLE-STACK.  How should
    references to N be interpreted inside METHA?  If VISIBLE-STACK has its own
    instance variable named N, then this N should shadow both WINDOW's N and
    STACK's N.  But if there is no N defined at the level of VISIBLE-STACK, then
    references to N inside METHA should generate an error message:  "N is an
    ambiguous slot reference."

Packages solve this; a reference to N inside METHA specifies which N it means
explicitly.  Is there a reason why this is inadequate?  Packages already provide
for an error to be signalled if there is an attempt to inherit two symbols with
the same name.

    Problem:  how do we write a new CLEAR-SCREEN method for VISIBLE-STACK?  We
    will need notation to explicitly specify that we want to access the
    shadowed WINDOW's N rather than the shadowed STACK's N.

Packages provide a suitable notation.

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

    It is obvious what the ObjectLisp solution to this set of problems would
    be:  place each N in a different package to keep the names distinct.  I find
    this highly unsatisfactory.  In the degenerate case, each flavor will end up
    with its own associated package in which instance variables are defined.  A
    user of the ELEPHANT flavor will have to contend with slot names from a
    host of packages, e.g.  ELEPHANT:TRUNK, MAMMAL:HAIR-COLOR,
    VERTEBRATE:SPINE-LENGTH, ANIMAL:HABITAT, LIVING-THING:LIFESPAN, etc.  

I think this is somewhat of a straw man.  Aren't these flavors all part of
the same software module (unlike the earlier examples), and hence all in the
same package and presumed to use non-clashing names?

									  Of
    course the packages could be organized into a hierarchy mimicing the flavor
    hierarchy, so that ELEPHANT:HABITAT would reference ANIMAL:HABITAT unless
    shadowed, but that wouldn't provide for detection of ambiguous slot
    references as required in Example 3 above.  

Packages already provide for an error to be signalled when there is an attempt
to inherit two symbols with the same name.

						Furthermore, unless the
    flavor/package duality was rigidly enforced by the flavor system, the user
    could create quite a mess by hacking the package stuff by hand.

    Finally, if packages are intended to be used for encapsulating separate
    software modules, then we must allow each package to have its own set of
    flavors defined within that package.  Thus, in my hairy robot system, the
    flavor ARM:STACK may describe a stack of blocks, while PLANNER:STACK may be
    an entirely different type of flavor, such as a stack of goals.  If flavors
    usurp the package system for other tasks, like slot shadowing, the original
    purpose of packages -- encapsulation of software modules -- will be hindered.

How are flavors different from software modules?

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

I'd like to see counterarguments, but I suspect that they will be of the form
"packages are no good in general" rather than of the form "packages are adequate
for resolving some name clashes, but not for resolving name clashes for
instance variables."

∂19-Sep-85  1758	bobrow.pa@Xerox.ARPA 	Arguments and values to get.
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 19 Sep 85  17:58:09 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 SEP 85 17:43:45 PDT
Date: 19 Sep 85 16:39 PDT
Sender: bobrow.pa@Xerox.ARPA
Subject: Arguments and values to get.
To: Common-Lisp@SU-AI.ARPA
cc: cl-object-oriented-programming@su-ai.ARPA
From: Gregor.pa@Xerox.ARPA
Message-ID: <850919-174345-1059@Xerox>

This (admittedly minor) question came up while we were writing up some
of the CommonLoops metaclass protocols.

Why does Common-Lisp GET take a default-value argument instead of
returning a second value indicating whether the property actually
exists?

Originally we had wanted to make CommonLoops' internal slot-access
function return a second value saying whether or not the slot-existed
but we ended up changing it to be more like GET.

∂19-Sep-85  1819	FAHLMAN@C.CS.CMU.EDU 	Arguments and values to get.
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 Sep 85  18:19:31 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 19 Sep 85 21:19:45-EDT
Date: Thu, 19 Sep 1985  21:19 EDT
Message-ID: <FAHLMAN.12144621737.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Gregor.pa@XEROX.ARPA
Cc:   cl-object-oriented-programming@SU-AI.ARPA, Common-Lisp@SU-AI.ARPA
Subject: Arguments and values to get.
In-reply-to: Msg of 19 Sep 1985  19:39-EDT from Gregor.pa at Xerox.ARPA


    Why does Common-Lisp GET take a default-value argument instead of
    returning a second value indicating whether the property actually
    exists?

The default argument is useful in some cases, but admittedly is a bit
inelegant -- if you want to know for sure whether a value was found, you
have to be careful to choose some default argument that couldn't
possibly be stored in any property list.  The reasoning (If I recall it
correctly) was that this occasional creation of a unique default is less
hassle than having to write an ugly multiple-value-bind every time we
want to return a default value in the property-not-found case.  I'm not
sure I believe that any more.

-- Scott

∂20-Sep-85  0709	KMP@SCRC-STONY-BROOK.ARPA 	Arguments and values to get.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Sep 85  07:08:53 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 317574; Fri 20-Sep-85 10:09:02-EDT
Date: Fri, 20 Sep 85 10:09 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Arguments and values to get.
To: Fahlman@C.CS.CMU.EDU, Gregor.pa@XEROX.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12144621737.BABYL@C.CS.CMU.EDU>
References: Msg of 19 Sep 85 19:39-EDT from Gregor.pa at Xerox.ARPA
Message-ID: <850920100928.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Thu, 19 Sep 1985  21:19 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
    To:   Gregor.pa@XEROX.ARPA
    In-reply-to: Msg of 19 Sep 1985  19:39-EDT from Gregor.pa at Xerox.ARPA

	Why does Common-Lisp GET take a default-value argument instead of
	returning a second value indicating whether the property actually
	exists?

    The default argument is useful in some cases, but admittedly is a bit
    inelegant -- if you want to know for sure whether a value was found, you
    have to be careful to choose some default argument that couldn't
    possibly be stored in any property list.  The reasoning (If I recall it
    correctly) was that this occasional creation of a unique default is less
    hassle than having to write an ugly multiple-value-bind every time we
    want to return a default value in the property-not-found case.  I'm not
    sure I believe that any more.

    -- Scott

It would be reasonable to propose a more-or-less upward-compatible extension 
to GET (for CL86 or whatever) which provided that GET both accepted a argument
specifying the default to be used -and- returned two values (one the result, 
the second a boolean saying whether the argument had been defaulted).

∂22-Sep-85  1828	masinter.pa@Xerox.ARPA 	A reply and some more thoughts on specializing built-in 
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 22 Sep 85  18:28:21 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 85 18:29:28 PDT
Date: 22 Sep 85 18:29 PDT
From: masinter.pa@Xerox.ARPA
To: cl-object-oriented-programming@su-ai.ARPA
subject: A reply and some more thoughts on specializing built-in
 functions
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Wed,
 18 Sep 85 00:02 EDT
Message-ID: <850922-182928-1003@Xerox>

"I suppose we could allow a built-in function to be specialized with the
understanding that the change is not retroactive, but only applies to
user-level code compiled after the specialization is created."

This seems like a very bad idea, because it avoids the main "feature" of
CommonLoops, which is the ability to specialize functions "after the
fact".  

It would seem more reasonable to examine the book for those functions
which are natural candidates for specialization, and to discuss what
impact it might have to allow more specialization.

The cases that come to mind are:

(a) sequence functions. Currently, there are two kinds of sequences:
vector and list. Clearly, one simple application of
object-oriented-programming is the ability to define new kinds of
sequences. This is a fundamentally powerful feature in Smalltalk, for
example. Given that most sequence functions start out with a typecase,
this shouldn't be too burdensome, as long as the "built-in" methods
aren't redefinable (e.g., you can define (mapcar my-sequence) and
(mapcar zilch) but you can't redefine (mapcar list) or (mapcar vector)
and expect the system to work the same.

(b) arithmetic. Both an exciting and difficult, allowing new kinds of
objects in arithmetic expressions would allow for natural extensions to
dealing with element-wise array operations, continued fractions, and a
wide variety of other kinds of objects. Without allowing specialization
of the number primitives, one would have to do things like shadowing +
by a macro which expands into binary-add, with  

(defmethod binary-add ((x number) (y number)) (lisp:+ x y))

and then specializing binary-add instead. (This convolution is necessary
because lisp:+ isn't binary, but it only makes sense to add methods for
the binary version.)

(c) Generic recursive object operations. There are a number of generic
recursive object operations which should be specializable, with the rule
being that the operation applies itself to subparts, including EQUAL,
COPY, whatever happens underneath printing (so that the :print-function
option in defstruct really gets turned into a simple defmethod). I think
these correspond reasonably to the "super-general" functions that REM
was referring to in his last message to common-lisp@su-ai in a
discussion about how EQUAL might be "fixed" so that it descended into
structures.



 

∂22-Sep-85  1835	masinter.pa@Xerox.ARPA 	Re: EQUAL isn't really correct, I agree  
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 22 Sep 85  18:34:46 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 85 18:35:12 PDT
Date: 22 Sep 85 18:18 PDT
From: masinter.pa@Xerox.ARPA
Subject: Re: EQUAL isn't really correct, I agree
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Tue,
 17 Sep 85 22:38 EDT
To: Fahlman@C.CS.CMU.EDU
cc: Rem@MIT-MC.ARPA, CL-object-oriented-programming@su-ai.ARPA
Message-ID: <850922-183512-1007@Xerox>

The problem of wanting to handle EQUALity differently for different
objects can be naturally handled by defining (a version of) EQUAL as a
*method*, which can be specialized for whatever types the user has in
mind. 

E.g.,

(defmethod equal (x y) (eq x y))
(defmethod equal ((x cons) (y cons))
   (and (equal (car x) (car y))
        (equal (cdr x) (cdr y)))


(defmethod equal ((x flonum) (y flonum)) (= x y))


etc.

I'd add EQUAL to the list of built-in Common Lisp functions for which
allowing specialization is a Good Thing.

∂22-Sep-85  1943	FAHLMAN@C.CS.CMU.EDU 	A reply and some more thoughts on specializing built-in   
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Sep 85  19:43:28 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 22 Sep 85 22:44:28-EDT
Date: Sun, 22 Sep 1985  22:44 EDT
Message-ID: <FAHLMAN.12145423591.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   masinter.pa@XEROX.ARPA
Cc:   cl-object-oriented-programming@SU-AI.ARPA
Subject: A reply and some more thoughts on specializing built-in
In-reply-to: Msg of 22 Sep 1985  21:29-EDT from masinter.pa at Xerox.ARPA


I think we had better be careful to separate this business of
specializing built-in functions from the rest of the CommonLoops
proposal.  The CommonLoops proposal so far is almost entirely an add-on
to Common Lisp; anything that requires a significant rewrite of existing
implementations is going to meet with much more determined resistance,
and if it slows down vanilla Lisp programs, there is absolutely no hope
of its being accepted.  I would hate to scare people away from the rest
of the CommonLoops proposal just because they are afraid of where this
tinkering with the guts of Common Lisp might lead.

The one safe case is where a built-in function handles different
argument-types in different ways (and therefore requires a type test)
and where the method extends (not "specializes") the function to handle
argument types that otherwise would signal an error.  Such cases can be
handled entirely in the error handler (once we get an error system
specified) or by adding one extra hook to the run-time type-dispatch.
If we are careful, we could add this without disrupting anything.

Similarly, it might be safe to do what I suggested before: allow users
to specialize built-in functions with the clear understanding that the
specialization is not retroactive.  Users could screw themselves by
specializing + or CDR and therefore making them horribly slow from that
time on, but no system code would be affected.

But as soon as you start talking about RETROACTIVE SPECIALIZATION of
built-in functions, that is a much more serious business.  I think that
we must avoid this.  If necessary, we might introduce a new set of
generic functions that are clones of the built-in functions, but are
specializable.  We could put all of these in a package named something
like PSEUDO, and we could then re-use the old familiar names.  So
LISP:EQUAL would behave as it always has, but PSEUDO:EQUAL would be a
specializable version whose default behavior is to do what EQUAL does,
but which the user could bend beyond all recognition if he wants to.

-- Scott

∂22-Sep-85  2242	DT50@A.CS.CMU.EDU 	reply to Moon on slot shadowing
Received: from A.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Sep 85  22:42:08 PDT
Date: 23 Sep 85 01:41 EDT
From: Dave.Touretzky@A.CS.CMU.EDU
To: cl-object-oriented-programming@SU-AI.ARPA
Subject: reply to Moon on slot shadowing
CC: Dave Touretzky@A.CS.CMU.EDU

I can't accept Moon's argument that packages solve the slot shadowing problem,
not because I dislike packages, but because I feel their use is inappropriate
in this context.  Here are three points to debate:

1.  Packages should be used for coarse-grain control of name conflicts, not
fine-grain control.  In other words, I think it's necessary to put the
compiler, the window system, and the mail system in separate packages, but
I don't think we should force a naive user writing a small program to
spread his identifiers among several packages simply because we didn't give
him proper scoping mechanisms for objects.

2.  An analogy.  Suppose function BAR modifies a global variable N.  Function
FOO, which calls BAR, innocently binds a local N.  Should this break BAR?  Of
course not; that's what lexical scoping is for.  No one would advocate
putting FOO's N and BAR's N in separate packages in this case; lexical
scoping is a much more elegant solution.  

My slot shadowing proposal is a kind of lexical scoping for objects.  It can
operate within a single package.  I believe the slot name problem is one of
proper scoping of identifiers rather than of protecting against multiple
unrelated uses of a symbol, for which packages seem more appropriate.

3.  Users should be AUTOMATICALLY protected from inadvertent name conflicts
so they don't get screwed in the ways I warned about in my proposal.  This
might occur if slot shadowing were not provided as the default behavior.  If
we insist on using packages to keep slot names distinct, then I'd like to
see a description of how this might happen automatically, yet in a way that
allows the user to refer to his slot names in a convenient manner.  I find
the notion of objects whose slot names are spread across a constellation
of packages not very appealing.

-- Dave

∂23-Sep-85  1127	Bobrow.pa@Xerox.ARPA 	Re: A reply and some more thoughts on specializing built-in    
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 23 Sep 85  11:26:50 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 SEP 85 11:27:07 PDT
Date: 23 Sep 85 10:49 PDT
From: Bobrow.pa@Xerox.ARPA
Subject: Re: A reply and some more thoughts on specializing built-in
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Sun,
 22 Sep 85 22:44 EDT
To: Fahlman@C.CS.CMU.EDU
cc: masinter.pa@Xerox.ARPA, cl-object-oriented-programming@SU-AI.ARPA
Message-ID: <850923-112707-1457@Xerox>

CommonLoops supports a predicate
(SPECIALIZABLE-P <function>).

The domain of functions in the silver book for which SPECIALIZABLE-P
returns T can start at () and increase over time as we understand 
the implementation impact of extending the list.

Proposals for an initial list of SPECIALIZABLE-P function from
the silver book is independent of any use of CommonLoops 
since as CommonLoops as defined does not require any such 
specializations.

∂23-Sep-85  1204	DLW@SCRC-VALLECITO.ARPA 	CommonLoops    
Received: from SCRC-VALLECITO.ARPA by SU-AI.ARPA with TCP; 23 Sep 85  12:01:37 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-VALLECITO.ARPA via CHAOS with CHAOS-MAIL id 36708; Mon 23-Sep-85 15:01:30-EDT
Date: Mon, 23 Sep 85 14:58 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: CommonLoops
To: Fahlman@CMU-CS-C.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12135325145.BABYL@CMU-CS-C.ARPA>
Message-ID: <850923145852.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI

    Date: Thu, 15 Aug 85 10:11 EDT
    From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>


    I don't see the CommonLoops proposal as trying to be all things to all
    people.  The basic CommonLoops langauge, with some of the proposed
    extensions, looks to me (as a relative novice in this game) like just
    the right level for most of the things I want to do.  It's clean and
    easy to understand, and it has the property that you don't run into any
    of the complexity until and unless you need it.  The lack of this
    property was the biggest problem with Flavors, in my opinion.  I could
    easily imagine doing almost all my work in base-level CommonLoops and
    using it as the teaching vehicle for students new to Lisp and objects.

Scott, I've heard you say this a few times now, both on the mail and in
person.  In a later message, you also said (speaking about Common
Loops):

    Unlike flavors, it does not inflict a tremendous load of complexity on
    the user who wants to do something simple.

I genuinely don't know what you are referring to here.  Your implication
seems to be that to do even simple things using Flavors, you first need
to understand a lot of complex stuff that isn't really necessary if you
only want to do something "simple".  I don't understand why this should
be the case.

I think the problem is that I don't know what you mean by "simple" in
this context.  Could you please construct an example in which the
requirements of the programmer are "simple" in the sense you mean, so
that I could see how Flavors can meet those requirements only with a
tremendous load of complexity, whereas CommonLoops can meet the same
requirements without such complexity?  I hope this might illustrate some
significant distinctions between the two approaches.  Thanks.

∂23-Sep-85  1535	DT50@A.CS.CMU.EDU 	SPECIALIZABLE(-)P    
Received: from A.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Sep 85  15:35:46 PDT
Date: 23 Sep 85 18:37 EDT
From: Dave.Touretzky@A.CS.CMU.EDU
To: cl-object-oriented-programming@SU-AI.ARPA
Subject: SPECIALIZABLE(-)P
CC: Dave Touretzky@A.CS.CMU.EDU

According to the Common Lisp standard (silver book, page 71) the name
SPECIALIZABLEP should not be hyphenated.  If people decided long ago
to punt this convention, then I apologize for nit picking.  I thought
it was a good idea, though.

-- Dave

∂23-Sep-85  1927	FAHLMAN@C.CS.CMU.EDU 	CommonLoops  
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Sep 85  19:27:25 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 23 Sep 85 22:28:29-EDT
Date: Mon, 23 Sep 1985  22:28 EDT
Message-ID: <FAHLMAN.12145682824.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   cl-object-oriented-programming@SU-AI.ARPA
Cc:   fahlman@C.CS.CMU.EDU
Subject: CommonLoops
In-reply-to: Msg of 23 Sep 1985  14:58-EDT from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>


[This is in reply to the message from Weinreb asking what I meant when I
said that Flavors throws a lot of complexity at the user who wants to do
something simple.  For some reason, I can no longer get mail through to
hosts like SCRC-QUABBIN or SCRC-STONY-BROOK.  Since the query was CC'ed
to this mailing list, I'll reply via the list.]

Dan,

Dave Moon asked me more or less the same question, and I sent him a
lengthy reply a couple of days ago.  (I don't know if it got there,
however -- I've heard nothing back from Moon.)  I guess since the
question has now been raised in public, I may as well send my reply to
this whole list.  It follows -- the stuff after the dashed line.

Before we get to that, let me make a couple of preliminary remarks in
response to the questions you raised:

First, I suspect that for any "simple" situation that I describe to you,
you will be able to show me a straightforward way to implement the
desired thing in flavors.  That's not the point.  The point is that in
order for a beginner to feel that he has sufficient control of flavors
to find this simple solution, he has to understand an awful lot of hairy
machinery, most of which isn't relevant to the problem at hand but which
is not far enough out of the way that a beginner can confidently ignore
it.  The image I have (admittedly an exaggeration) is of a minefield: if
I want to get from point A to point B, you can show me a simple path;
for the beginner, however, the hard part is in knowing where NOT to
step.  Commonloops (so far) has fewer mines and they are all in a couple
of well-defined areas, not sprinkled around all over.

Second, I have not tried to sort out the elements of this apparent
complexity: how much of it is fundamental in the design of flavors, how
much is due to ugly add-ons that have grown up over the years, how much
is the fault of the documentation, and how much is due to the lack of
any readable flavor-based code that I can look at for inspiration, and
how much is due to the fact that, in order to play with this system, I
have to use a machine (the 3600) whose user interface I don't get along
with at all.

Third, let me just note that I am not the only one who finds Flavors to
be excessively complex.  Ask around.  Once people have invested an
intensive month or two in learning flavors, they seem to find it a
reasonable or even indispensible tool, and these people seem to forget
that they ever found it confusing.  But my sense of the community is
that these people are greatly outnumbered by people who who have tried
to learn about flavors (perhaps in a less intense way) and have decided
that it is an ungodly hairy system that they never want to use if there
is any alternative.  I've thought hard about whether this is just a
mental block on my part -- perhaps an over-reaction to a couple of bad
experiences -- but if that is the case, a lot of other people share this
same block.  So the question is not whether I'm right or wrong about
flavors being hairy; the question is why so many people THINK it is
hairy, and what (i anything) can be done about that.

Here's the message to Moon:

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

Dave,

I'm writing this when I really should be doing a bunch of other stuff,
so this may not end up being as coherent as I would like.  But anyway,
here are some of my thoughts on why Flavors seems gratuitously hairy to
me -- more hairy than, for example, CommonLoops.  Of course, hair is
in the eye of the beholder (ugh!).

First, some general views on what makes a software system seem simple or
complex.

1. If a system has a frequently-used part that is (or could be) relatively
clean and simple and a much hairier part that is needed only
occasionally, it is important that the casual user be able to totally
ignore the hairy part.  The document should be in two layers: here's the
part of the system you are going to need right away, and here is heavy
stuff that you might someday want to learn about, once you are totally
comfortable with the basic stuff.  And the system itself should be
organized in such a way that you will not accidentally wander (or be
dragged) deeper into the woods than you really want to go; the hair
should be totally out of your way until you explicitly ask for it.

2. Some users just worry about the surface semantics of a system, but
most good programmers are thinking all the time about efficiency and
choices that affect efficiency.  That means that you must have some
mental model of how things are implemented.  This model can be
oversimplified in some areas or it can even be a total lie, as long as
it gives the programmer a good qualitative feel for what various things
cost.  If a system's underlying model is clean and obvious, or if an
adequate implementation model can be suggested by the documentation,
then the programmers using this system will feel much more secure; if
not, then the programmers will feel that the system is out of control.

3. When a system is already very hard to understand, a few inelegant
constructs that increase the level of visual clutter can make a big
difference -- the straw that broke the camel's back.

I think that the Flavors system (as described in the Gray edition of the
Chine Nual, which is the version I happen to have handy) does rather
poorly by all of these criteria.  I won't dwell on the small
inelegancies, except to note that the system has a bunch of these.  For
example, the gettable/settable/initiable options for instance variables
should be on by default, with with an option to turn them off; as it is,
even very simple flavor definitions must be cluttered up with
odd-looking keywords.  There are several things like this that increase
the general level of clutter and make flavors code LOOK hairier than it
is.

The documentation is a big part of the problem with flavors, I think.
There are a LOT of complicated little options and features and
specialized functions (such as Instantiate-Flavor) that are all mixed in
with the stuff that the average user needs to know.  It may or may not
be the case that each and every one of these is necessary for doing
advanced system programming in flavors (some of them look like real
kludges), but if they must be around they should be put in a special
"hairy flavor wizards only" section of the manual.  The first few times
I tried to read the document, I started to falter when I hit
Instantiate- Flavor, and I was totally confused by the time I made it to
the section on Defflavor options (which finished me off).

Examples are very important -- without them, the documentation has to be
perfect -- and there are essentially none of them in the manual.  Worse,
there don't seem to be any relatively simple flavor-ized programs for
people to look at anywhere in the world.  At least, we got no response
when we asked for pointers to such things.  So people have to read the
manual and then start writing their own code without a template, or else
they have to look at something like the Symbolics window system.  That
is not a good way to persuade people that flavors are simple.

I should also mention that the few times I have tried to read
production-quality flavors code (in various parts of the 3600 software),
I have had a very difficult time finding the places where some code
actually does something; most methods seem to just do a Send to
somewhere else, along with doing a tiny bit of what has to be done.  I
would suggest that an important goal of good coding style in these
systems is to make it easy for the user to find where the action really
is, or else to clearly specify what the total effect of calling a
particular method is.

I think that the most fundamental problem is that flavors tries too hard
to combine late binding and modifiability of EVERYTHING with the goal of
compiling everything in the tightest possible way, with no wasted cycles
or levels of indirection that might make the late binding less complex.
These are incompatible goals, and by trying too hard to achieve both,
Flavors ends up with an explosion both in the complexity of the language
as seen by the user and in the underlying implementation (which, as I
said above, the users will want to understand at some level).  I agree
with the view that users will not use an object-oriented system for real
applications if it costs too much at runtime.  However, I would much
prefer a less complex system that retains total flexibility at some
modest cost in efficiency, and which also allows the user to say "I am
done with modifying the hierarchy of flavors and methods, so now compile
this system to the max."  It is the attempt to get both flexibility and
maximum efficiency AT THE SAME TIME that is the source of so much hair.

The method-combination stuff is the most obvious example of this.
Instead of going with <some code> (run-super) <some more code>, it is
deemed important to smash the superior method into the middle of the
function and to get it all compiled into one lump.  But then there is
the problem of undoing all this and recompiling if some loser goes in
and changes the type hierarchy.  The result is a lot of user-visible
complexity, funny exceptions about wrappers and whoppers, and a very
complex underlying model for those users who want to understand things
at that level.

If, instead, we pay for the extra method lookup implicit in the
run-super, everything works in the obvious way.  On top of that we add a
cache (which makes things run faster without changing the user's model
much) and a finalize-and-compile mode that makes everything maximally
efficient but rules out further changes in the hierarchy (or in that
part of it that is above the function in question).  It is the
compiler's job to make sure that whatever it does is functionally
equivalent to what the non-compiled version would do, and in a situation
declared to be stable, it can do this without a lot of extra coaching by
the user.  That seems much simpler to me than :before, :after, wrappers,
recompile-flavor, and so on.  Similarly, it seems to me (I haven't
thought this through) that some judicious use of an occasional level of
indirection might make it possible to get sufficient flexibility in
load-time order without all the major gyrations that flavors seems to go
through now; a super-compile mode could again be used to eliminate this
extra cost when the user says that the system is now in its final form.

Let's look at CommonLoops by way of contrast.  Again more examples are
needed.  The current document is not cluttered by hairy special-case
options; perhaps these will have to be added later, but maybe they can
be segregated from the main writeup.  All of the extensibility is hidden
in the meta-class stuff, which the typical user will never need to get
into -- one trap-door into the hairy regions rather than fifty.  The
underlying mechanisms appear to be rather simple, though they need to
be explained better.  A cache does not add conceptual complexity because
it "does the right thing"; the same with a super-compile mode to crush
out the last drops of inefficiency once the system is stable (if indeed
they add that).  The function-call syntax is familiar and intuitive;
while there may be some complex cases where one must think carefully
about which method is the most specific, in all of the cases that will
really come up this is obvious.

The question, of course, is whether the CommonLoops thing can remain as
simple as it now appears to be while it develops the necessary hooks and
options for doing various kinds of real world work.  Maybe it can't, and
maybe as an experienced implementor of these things you see this more
clearly than I do.  But right now it looks very clean, and Flavors looks
like a nightmare by comparison.

I don't know how clear any of this is, and I'm sure that you will think
that some of this is off base.  I've tried to give you a general idea of
why flavors LOOKS hairy to me, without thinking too hard about which of
these concerns are really justified and which are just misconceptions
and lack of experience on my part.  But I guess it is the perceptions
that are of interest here.  What it adds up to for me is that I'm eager
to try CommonLoops and I hope I never have to write anything serious in
flavors.

-- Scott

∂23-Sep-85  1943	FAHLMAN@C.CS.CMU.EDU 	A reply and some more thoughts on specializing built-in   
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Sep 85  19:43:40 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 23 Sep 85 22:44:41-EDT
Date: Mon, 23 Sep 1985  22:44 EDT
Message-ID: <FAHLMAN.12145685778.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Bobrow.pa@XEROX.ARPA
Cc:   cl-object-oriented-programming@SU-AI.ARPA
Subject: A reply and some more thoughts on specializing built-in


    The domain of functions in the silver book for which SPECIALIZABLE-P
    returns T can start at () and increase over time as we understand 
    the implementation impact of extending the list.

I like this way of separating the issues.

One other comment: Even if the list of specializable functions in
portable Common Lisp code is () or very short, that would not prevent
implentors from using the CommonLoops machinery for defining sequence
functions, equal, or other things internal to their own systems, just as
nothing prevents the Lisp Machine people from using flavors in
implementing their I/O streams and such.

-- Scott

∂23-Sep-85  2144	DDYER@SCRC-QUABBIN.ARPA 	CommonLoops & Flavors' complexity  
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 23 Sep 85  21:42:05 PDT
Received: from WHITE.SWW.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 204330; Tue 24-Sep-85 00:42:02-EDT
Received: from SWW-PURPLE by SWW-WHITE via CHAOS with CHAOS-MAIL id 139739; Mon 23-Sep-85 21:47:12-PDT
Date: Mon, 23 Sep 85 21:42 PDT
From: DDYER@SCRC-RIVERSIDE.ARPA
Subject: CommonLoops & Flavors' complexity
To: cl-object-oriented-programming@SU-AI.ARPA
Fcc: W:>ddyer>mail.sent
In-Reply-To: <FAHLMAN.12145682824.BABYL@C.CS.CMU.EDU>
Supersedes: <850923213941.1.DDYER@PURPLE.SWW.Symbolics.COM>
Message-ID: <850923214254.2.DDYER@PURPLE.SWW.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI


Without responding to all the individual points, I want to register
a mostly-concurring opinion to Scott's complaints about flavors.

While I am now definitely in the class of those who think flavors is
indespensable, it hasn't been so long I can't remember my first
encounters with flavors.  They were not fun, and most of the reasons
were exactly those Scott listed.

However, the horizon is not all black.  I think that with better
documentation, organized to answer Scott's excellent criticisms,
a programmer's introduction to flavors need not be painful. 

I believe the main reason (other than the state of the documentation) that 
introduction to flavors is painful, is that the novice usually
lands "hip deep", trying to understand the very hairiest flavors
code; in the window system or the io stream system.  


∂24-Sep-85  0009	RWK@SCRC-STONY-BROOK.ARPA 	CommonLoops  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Sep 85  00:08:49 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 319700; Tue 24-Sep-85 03:09:10-EDT
Date: Tue, 24 Sep 85 03:06 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: CommonLoops
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12145682824.BABYL@C.CS.CMU.EDU>
Message-ID: <850924030612.1.RWK@CROW.SCRC.Symbolics.COM>

    Date: Mon, 23 Sep 1985  22:28 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
	 The image I have (admittedly an exaggeration) is of a minefield: if
    I want to get from point A to point B, you can show me a simple path;
    for the beginner, however, the hard part is in knowing where NOT to
    step.  Commonloops (so far) has fewer mines and they are all in a couple
    of well-defined areas, not sprinkled around all over.
I don't disagree, but I won't be sure of it until it has been
used for a while by people entirely new to object-oriented
programming.

		 So the question is not whether I'm right or wrong about
    flavors being hairy; the question is why so many people THINK it is
    hairy, and what (i anything) can be done about that.

As DDyer points out, a lot of why people think of flavors as
hairy is they quickly get deeply involved into the window-system.
Once into the window system, they quickly get overwhelmed by all
the different optional mixins, ways of putting things together,
bad modularity, missing documentation, etc.  I'm sure it's not
the only reason, but it IS hard to factor out.

(Making the window system easier to use is obviously a prime target.  I
don't believe the window system is hairy because of the flavor system,
just that the flavor system LET the window system be hairy).

    I'm writing this when I really should be doing a bunch of other stuff,
    so this may not end up being as coherent as I would like.  But anyway,
    here are some of my thoughts on why Flavors seems gratuitously hairy to
    me -- more hairy than, for example, CommonLoops.  Of course, hair is
    in the eye of the beholder (ugh!).
Excuse you!

    First, some general views on what makes a software system seem simple or
    complex.
[General views deleted for brevity.  Suffice it to say: well said].

    I think that the Flavors system (as described in the Gray edition of the
    Chine Nual, which is the version I happen to have handy) does rather
    poorly by all of these criteria.  

Do me a favor, and donate that edition to your local computer museum.
(ESPECIALLY anyone else who ONLY has a copy of the Chine Nual!)  The
damn thing was done when the company was only a year old, as a minor
update to something done before there WAS a Symbolics.  It is now 4
years and two entire versions of the documentation later.  The volume
(Vol 2 of 9) that contains the language reference material alone is
almost twice the size of that old relic.

That said, I notice that the description of flavors therein hasn't
changed much.  So a lot of your comments still apply, at least to some
degree.  But it does make it harder sometimes for me to figure out
whether what you're saying has any modern relevance.

The containing volume IS labeled as a reference guide.  (I don't think it is
bad as a reference guide, although I could be blinded by knowing it already).
While there isn't a a lot that it specifically flavors, there is a lot of
"here's how you do something using flavors" documentation in other volumes.
(Sadly, the window-system makes these much hairier than they should be).
I'd be interested in your comments on this more modern documentation.

				      I won't dwell on the small
    inelegancies, except to note that the system has a bunch of these.  For
    example, the gettable/settable/initiable options for instance variables
    should be on by default, with with an option to turn them off; as it is,
    even very simple flavor definitions must be cluttered up with
    odd-looking keywords.  There are several things like this that increase
    the general level of clutter and make flavors code LOOK hairier than it
    is.

I don't think I like this idea.  It's like making all symbols of a package
be exported by default.  But that's irrelevant to your point; can you give
me another example that I don't have this reaction to?

    The documentation is a big part of the problem with flavors, I think.
    There are a LOT of complicated little options and features and
    specialized functions (such as Instantiate-Flavor) that are all mixed in
    with the stuff that the average user needs to know.  It may or may not
    be the case that each and every one of these is necessary for doing
    advanced system programming in flavors (some of them look like real
    kludges), but if they must be around they should be put in a special
    "hairy flavor wizards only" section of the manual.  The first few times
    I tried to read the document, I started to falter when I hit
    Instantiate- Flavor, and I was totally confused by the time I made it to
    the section on Defflavor options (which finished me off).

This is better in the current documentation.  Although I think that
most of the chapter that now contains INSTANTIATE-FLAVOR should come
about 7-8 chapters later, at least it is in a separate chapter of
more obscure stuff.  (It is worth noting that INSTANTIATE-FLAVOR
is used only 20 times in the system, 2 of them inside the flavor
system!)

    Examples are very important -- without them, the documentation has to be
    perfect -- and there are essentially none of them in the manual.  Worse,
    there don't seem to be any relatively simple flavor-ized programs for
    people to look at anywhere in the world.  At least, we got no response
    when we asked for pointers to such things.  So people have to read the
    manual and then start writing their own code without a template, or else
    they have to look at something like the Symbolics window system.  That
    is not a good way to persuade people that flavors are simple.

Sorry nobody responded.  But there's a couple of problems.  Every time
anyone goes and writes a simple example, they fall prey to the urge to
make it DO something.  This gets them involved in the window system.
The other problem is that a lot of examples make very simple use of
flavors, and so don't illustrate much.  I don't know of any examples
off-hand that avoid BOTH problems.

But you might look at SYS:EXAMPLES; on your local Lispm.  The CALC
example is fairly simple.  Probably the hairiest thing is supplying
some default values for the window flavor.

    I should also mention that the few times I have tried to read
    production-quality flavors code (in various parts of the 3600 software),
    I have had a very difficult time finding the places where some code
    actually does something; most methods seem to just do a Send to
    somewhere else, along with doing a tiny bit of what has to be done.  I
    would suggest that an important goal of good coding style in these
    systems is to make it easy for the user to find where the action really
    is, or else to clearly specify what the total effect of calling a
    particular method is.

There are a lot of tools that make this easier.  (Most of them
invented since 1981, I think).  Still, your point is worth
considering.  But I'm afraid I don't see how your problem
was due to flavors, per se, or how CommonLoops solves it.
Can you say a little more about this?

I deleted the rest of your remarks (about complexity of flavors being
the attempts at delayed binding), because (I confess) I haven't more
than skimmed the CommonLoops stuff that's come by, meaning to get to
it later.  (I'm pretty sure the people here who are working on our
flavor system have paid more attention).

I will comment that being able to preserve the ability to redefine
things on the fly is much more important in an environment where you
don't boot for a month at a time.

(uptime 'crow) ;My machine
CROW                     2 weeks 5 days 18 hours 31 minutes 38 seconds

In an environment like a Lisp on a conventional system, your system
administrator would turn off your account if you stayed logged in for a
month running Common Lisp.  I confess I don't know whether this would be
a problem with CommonLoops or not.

It's too bad, too, since I guess this was your more important point,
and I understood it the least.

    I don't know how clear any of this is, and I'm sure that you will think
    that some of this is off base.  I've tried to give you a general idea of
    why flavors LOOKS hairy to me, without thinking too hard about which of
    these concerns are really justified and which are just misconceptions
    and lack of experience on my part.  But I guess it is the perceptions
    that are of interest here.  What it adds up to for me is that I'm eager
    to try CommonLoops and I hope I never have to write anything serious in
    flavors.

Thanks for sharing your perceptions, it is indeed valuable information.
I'm forwarding your comments to our documentation people here, and I
guess I should get off my ass and find time to read this proposal
more carefully.

∂24-Sep-85  1300	Bobrow.pa@Xerox.ARPA
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 24 Sep 85  12:58:17 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 SEP 85 12:56:43 PDT
Date: 24 Sep 85 12:56 PDT
From: Bobrow.pa@Xerox.ARPA
To: Dave.Touretzky@A.CS.cmu.edu
cc: cl-object-oriented-programming@SU-AI.ARPA, bobrow.pa@Xerox.ARPA
LineFold: No
Message-ID: <850924-125643-2538@Xerox>

    1.  Packages should be used for coarse-grain control of 
    name conflicts, not fine-grain control.  In other words, I think 
    it's necessary to put the compiler, the window system, and 
    the mail system in separate packages, but I don't think we 
    should force a naive user writing a small program to spread 
    his identifiers among several packages simply because we 
    didn't give him proper scoping mechanisms for objects.

The naive user ought not to have to worry about the implementation. 
He ought merely to be able to state that an identifier should be 
protected.  An implementation with packages is sufficient 
(and can be easily understood by the user if needed).


   2.  An analogy.  Suppose function BAR modifies a global 
   variable N.  Function FOO, which calls BAR, innocently 
   binds a local N.  Should this break BAR?  Of course not;
   that's what lexical scoping is for.  No one would advocate 
   putting FOO's N and BAR's N in separate packages in this
    case; lexical scoping is a much more elegant solution.  

It is the case that one requires of a user that one declares a
variable N global, or at least special (or declares implicitly
or explicitly that FOO's N is local).  The same is true for the 
solution described above.  One shouldn't confuse user view 
and implementation.

   3.  Users should be AUTOMATICALLY protected from
   inadvertent name conflicts so they don't get screwed in 
   the ways I warned about in my proposal.

Our experience is that users know much more than you imply,
and usually are using name coincidence purposefully.  Implementors  
who use obvious names for "hidden variables" which are left 
unprotected are at fault.  They should use a "private"
declaration which could be implemented with a package
name.  Warnings on definitions that further specify named
variables are an easy add on.  One could distinguish the case in
which the user put the name conflict in the ":include option"
where they were clearly aware of it, and those which occur in
the body.

danny 


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

∂24-Sep-85  1705	AS%hp-hulk.csnet@CSNET-RELAY.ARPA  
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 24 Sep 85  17:05:43 PDT
Received: from hplabs by csnet-relay.csnet id ag03529; 24 Sep 85 19:59 EDT
Received: by HP-VENUS id AA24423; Tue, 24 Sep 85 15:47:14 pdt
Message-Id: <8509242247.AA24423@HP-VENUS>
Date: Tue 24 Sep 85 15:47:27-PDT
From: Alan Snyder <AS%hplabs.csnet@CSNET-RELAY.ARPA>
To: Bobrow.pa
Cc: cl-object-oriented-programming@su-ai.arpa
In-Reply-To: Message from "Bobrow.pa@XEROX@HP-VENUS" of Tue 24 Sep 85 12:56:00-PDT
Source-Info:  From (or Sender) name not authenticated.

  The naive user ought not to have to worry about the implementation. 
  He ought merely to be able to state that an identifier should be 
  protected.  An implementation with packages is sufficient 
  (and can be easily understood by the user if needed).

My experience with the package system leads me to be very skeptical of a
solution that uses the package system merely as an implementation.  The
package system tends to make itself rather visible.  For example: one
cannot write a macro that controls how symbols in the macro body are
interned, since the symbols are already interned before the macro is
expanded.  The macro could reintern those symbols, but the "damage"
would have already been done.  Does what you have in mind avoid such
problems?
-------

∂24-Sep-85  1910	FAHLMAN@C.CS.CMU.EDU 	Complexity, yet again  
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 24 Sep 85  19:10:48 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 24 Sep 85 22:12:02-EDT
Date: Tue, 24 Sep 1985  22:11 EDT
Message-ID: <FAHLMAN.12145941975.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   cl-object-oriented-programming@SU-AI.ARPA
Cc:   fahlman@C.CS.CMU.EDU
Subject: Complexity, yet again
In-reply-to: Msg of 24 Sep 1985  03:06-EDT from Robert W. Kerns <RWK at SCRC-YUKON.ARPA>


In reply to: Robert W. Kerns <RWK at SCRC-YUKON.ARPA>

I may respond to your other points later, after I've had time to peruse
the latest edition of the Symbolics documentation.  I made reference to
the Gray manual because I've got a copy of it at home and because the
flavors documentation seemed, upon cursory inspection, to be the same as
before, modulo the addition of even more hairy features (whoppers!).

In this note, I would like to respond to one point you made that I think
may be important and very relevant to this discussion: the one about
wanting things to be modifiable forever because you never reboot your
machine.  (Back when I had a 3600, I used to reboot it at least every
half hour because I couldn't get it out of SHEET-LOCK and OUTPUT-HOLD,
but that's another story.)

I think you may have put your finger on a cultural difference that few
people recognize.  Some people like to run one Lisp world for as long as
possible, which means that late binding and the changeability of
everything in the middle of a session looms very large in their
thinking; others like to blow away a lisp job and start over ("reboot"
on a system like yours) whenever things get messed up.  This is not so
much an individual difference as a function of what a given machine and
system encourage you to do.

If I mess up a bunch of data structures or decide that I want to totally
rearrange the hierarchy of flavor types, it doesn't bother me much to go
back, fix the source file, recompile, and start off again in a clean
Lisp.  Being able to change such things while running is nice, but you
pay for this flexibility in one of two ways: either things are compiled
somewhat less tensely than if you tell the compiler that you're not
going to surprise it, or else you compile things to the max and make sure
that whenever something changes, everything that has to be fixed is
fixed.

Flavors wants full runtime modifiability and the absolute maximum in
efficiency, so it makes the latter choice.  Well, almost...some things
would just be too expensive to fix up, so they don't get fixed; others
are fixable, but only at a cost the probably doesn't want to pay.  Once
there are a few of these exceptions, you can't just tell the user to
change what he likes and to just trust the system to keep everything
consistent.  The user has to more or less understand how the fixing-up
process works and what its limitations are.  And this, I think is the
biggest unavoidable cognitive load on the would-be user of flavors.
Because of the combination of maximum compilation, arbitrary load order,
and runtime flexibility, the consistency machinery is very hairy, and
there's no simple lie that you can tell the user that will allow him to
ignore it all.  I'm pretty sure that this is a fundamental problem and
not a documentation issue.

Is that much complexity inevitable in a system with the power of
flavors?  Well, I think that the design choices that were made were the
natural ones in the MIT Lisp Machine/Symbolics culture: you don't want
to reboot, so everything must be modifiable; everything must always be
compiled to the max for best efficiency; minimizing user-visible
complexity is a laudable goal, but when push comes to shove runtime
flexibility and efficiency win.  On its own terms, given that set of
goals, flavors succeeeds admirably.

I don't like flavors because I have different goals.  Being able to
patch up EVERYTHING at runtime and loading things in completely
arbitrary orders is not so important to me.  Keeping the complexity down
is more important.  (That makes me a wimp.  Actually, I'm only worried
about all these naive users...)

I agree with Moon, who has said that an object-oriented system must in
the end produce code that runs just about as fast as if you used more
conventional techniques.  Otherwise, nobody will use it for anything
serious.  But I am willing to divide my life into phases: when I'm
messing around and doing exploratory programming, I'm willing to suffer
a modest loss of efficiency -- say, a factor of two overall.  When I've
got the system the way I want it, then I want to be able to compile out
all the flexibility to get the very last drop of performance.  the
excess complexity of flavors comes from wanting both of these things AT
THE SAME TIME.  I'm willing to accept one or the other at any given
time, and to recompile and reload the universe when the time comes to
switch modes.

By the way, I am not saying that CommonLoops does better according to
these goals -- just that they still have an opportunity to do so,
depending on how various issues get resolved.

-- Scott

∂24-Sep-85  1955	Moon@SCRC-QUABBIN.ARPA 	Complexity, yet again
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 24 Sep 85  19:55:04 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 204761; Tue 24-Sep-85 22:54:53-EDT
Date: Tue, 24 Sep 85 22:55 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Complexity, yet again
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12145941975.BABYL@C.CS.CMU.EDU>
Message-ID: <850924225537.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 24 Sep 1985  22:11 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    In this note, I would like to respond to one point you made that I think
    may be important and very relevant to this discussion: the one about
    wanting things to be modifiable forever because you never reboot your
    machine....
    Flavors wants full runtime modifiability and the absolute maximum in
    efficiency, so it makes the latter choice.  Well, almost...some things
    would just be too expensive to fix up, so they don't get fixed; others
    are fixable, but only at a cost the probably doesn't want to pay.  Once
    there are a few of these exceptions, you can't just tell the user to
    change what he likes and to just trust the system to keep everything
    consistent.  The user has to more or less understand how the fixing-up
    process works and what its limitations are.  And this, I think is the
    biggest unavoidable cognitive load on the would-be user of flavors.
    Because of the combination of maximum compilation, arbitrary load order,
    and runtime flexibility, the consistency machinery is very hairy, and
    there's no simple lie that you can tell the user that will allow him to
    ignore it all.  I'm pretty sure that this is a fundamental problem and
    not a documentation issue.

I wish you would be specific.  I spent some time trying to guess what in the
world you could be talking about.  I came up with two things: (1) you have to
call the function recompile-flavor sometimes (but that bug was fixed about
three years ago, and in any case was an implementation shortcut, not a
language issue); (2) when you change the number of instance variables in a
flavor that has already been instantiated, existing instances break (this
isn't a language issue either, since it's easy to fix, is fixed in your
student Handerson's implementation I believe, and is fixed in my
implementation (which you haven't seen, so I can't fault you for not knowing
about it.))  Except for this, I can't think of any exceptions to the rule that
you can change what you like and trust the system to keep it consistent, which
of course is a rule to which every program development system ought to adhere.
Have I correctly guessed what you're talking about, or are there some real
fundamental problems that I'm overlooking?

    ....I am willing to divide my life into phases: when I'm
    messing around and doing exploratory programming, I'm willing to suffer
    a modest loss of efficiency -- say, a factor of two overall.  When I've
    got the system the way I want it, then I want to be able to compile out
    all the flexibility to get the very last drop of performance.  the
    excess complexity of flavors comes from wanting both of these things AT
    THE SAME TIME.  I'm willing to accept one or the other at any given
    time, and to recompile and reload the universe when the time comes to
    switch modes.

In my view, forcing the user to choose between exploratory and production
modes would be an increase in cognitive complexity, not a decrease!

    By the way, I am not saying that CommonLoops does better according to
    these goals -- just that they still have an opportunity to do so,
    depending on how various issues get resolved.

Thanks, that wasn't clear to me from your original statement.  The really
important thing is that we all (I hope) agree that it is important to decrease
the apparent complexity of object-oriented programming as perceived by today
and tomorrow's users.  Your comments are helping, but I'm still trying to get
a grasp on the exact nature of that complexity.

∂24-Sep-85  2026	FAHLMAN@C.CS.CMU.EDU 	Complexity, yet again  
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 24 Sep 85  20:25:26 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 24 Sep 85 23:26:38-EDT
Date: Tue, 24 Sep 1985  23:26 EDT
Message-ID: <FAHLMAN.12145955562.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   cl-object-oriented-programming@SU-AI.ARPA
Subject: Complexity, yet again
In-reply-to: Msg of 24 Sep 1985  22:55-EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>


In reply to: David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>

        Well, almost...some things
        would just be too expensive to fix up, so they don't get fixed; others
        are fixable, but only at a cost the probably doesn't want to pay.  Once
        there are a few of these exceptions, you can't just tell the user to
        change what he likes and to just trust the system to keep everything
        consistent.

    I wish you would be specific.  I spent some time trying to guess what in the
    world you could be talking about.  I came up with two things: (1) you have to
    call the function recompile-flavor sometimes (but that bug was fixed about
    three years ago, and in any case was an implementation shortcut, not a
    language issue); (2) when you change the number of instance variables in a
    flavor that has already been instantiated, existing instances
    break...

Those are two of the things I had in mind, plus the non-propagation of
wrapper changes (if that hasn't also been fixed).  I have the impression
that there are several other such things, but I'd have to make a careful
scan of the new documentation to see if any of these really existed or
if I imagined them, and whether all such things have been fixed.  Also,
some machinery is described that allows the user to avoid having things
recompile when the first instance is created or at load time -- this is
not really a bug if the user ignores it, but I got the impression that
it was something that users ought to pay close attention to if they
don't want things to take forever.

If these things are fixed, or are fixable, then what we have is mostly a
documentation problem after all.  The point is to make it aboslutely
clear to the user that he doesn't have to worry about any of this, and
to hide the description of all this stuff in the "experts' section".

I won't be able to do that scan of the new manual for a few days, since
it lives at the office and I'm about to leave town for a bit.

-- Scott

∂24-Sep-85  2112	Moon@SCRC-STONY-BROOK.ARPA 	Complexity, yet again 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Sep 85  21:12:10 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 320570; Wed 25-Sep-85 00:12:39-EDT
Date: Wed, 25 Sep 85 00:12 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Complexity, yet again
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12145955562.BABYL@C.CS.CMU.EDU>
Message-ID: <850925001237.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 24 Sep 1985  23:26 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
    ....Those are two of the things I had in mind, plus the non-propagation of
    wrapper changes (if that hasn't also been fixed).  

That's the same thing; it's been fixed.  It sure was ugly before it was fixed!

						       I have the impression
    that there are several other such things, but I'd have to make a careful
    scan of the new documentation to see if any of these really existed or
    if I imagined them, and whether all such things have been fixed.  Also,
    some machinery is described that allows the user to avoid having things
    recompile when the first instance is created or at load time -- this is
    not really a bug if the user ignores it, but I got the impression that
    it was something that users ought to pay close attention to if they
    don't want things to take forever.

Isn't this the distinction between exploratory and production modes?
I.e.  whether you want to do your compilation ahead of time as part of
compiling a file, or whether you want to let the system just do it when
it feels like it.  I imagine that CommonLoops, and any other system that
uses any sort of caching, faces the same issue, and it's more or less
visible to the user depending on how long it takes.  In our system it's
pretty easy to find cases where the system programmers forgot to
compile-flavor-methods, especially for errors that rarely occur, and it
usually takes just long enough for the user to wonder "why is the
debugger slow today?" and not long enough for a riot to break out if it
isn't fixed.  Say 5 or 10 seconds.

    If these things are fixed, or are fixable, then what we have is mostly a
    documentation problem after all.  The point is to make it aboslutely
    clear to the user that he doesn't have to worry about any of this, and
    to hide the description of all this stuff in the "experts' section".

Indeed.  At Symbolics we're still learning how to write documentation that
is useful to audiences of widely varying expertness.

∂25-Sep-85  0425	FAHLMAN@C.CS.CMU.EDU 	Complexity, yet again  
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 25 Sep 85  04:25:40 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 25 Sep 85 07:26:51-EDT
Date: Wed, 25 Sep 1985  07:26 EDT
Message-ID: <FAHLMAN.12146042981.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   cl-object-oriented-programming@SU-AI.ARPA
Subject: Complexity, yet again
In-reply-to: Msg of 24 Sep 1985  22:55-EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>


In reply to: David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>

One last thought.  Moon says:

    In my view, forcing the user to choose between exploratory and production
    modes would be an increase in cognitive complexity, not a decrease!

I agree that this is true, other things being equal.  But according to
my second principle of apparent complexity (the one about users needing
a coherent mental model of the underlying implementation in order to
feel secure), two distinct modes might be preferable if both have
simple, obvious implementations while the one "both flexible and super
efficient mode" depends on a lot of complicated hidden machinery.  In
"flexible but not super efficient mode", it is easy to see that certain
things require runtime lookups, and that these lookups can usually be
short-circuited by cacheing; in "super efficient but not flexible mode",
it is easy to see which things would be tensely coded inline.  I'd feel
more secure this way, even if I can pretty much trust the hairy
single-mode machienry not to break on me.

Maybe I'm thinking like an implementor here -- I pried the lid off the
box and what I saw scared the hell out of me -- but as I said, most good
programmers want to have SOME model of the implementation to guide them.
It might be worth discussing this with some non-implementors and seeing
if this kind of thing bothers them.

-- Scott

∂25-Sep-85  0918	Bobrow.pa@Xerox.ARPA 	Re: --- 
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 25 Sep 85  09:18:16 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 25 SEP 85 09:15:37 PDT
Date: 25 Sep 85 09:13 PDT
From: Bobrow.pa@Xerox.ARPA
Subject: Re: ---
In-reply-to: Alan Snyder <AS@hplabs.CSNet>'s message of Tue, 24 Sep 85
 15:47:27 PDT
To: AS%hplabs.CSNet@CSNet-Relay.ARPA
cc: Bobrow.pa%hplabs.CSNet@CSNet-Relay.ARPA,
 cl-object-oriented-programming@su-ai.arpa
Message-ID: <850925-091537-3248@Xerox>

   The naive user ought not to have to worry about the implementation. 
   He ought merely to be able to state that an identifier should be 
   protected.  An implementation with packages is sufficient 
   (and can be easily understood by the user if needed).

 My experience with the package system leads me to be very skeptical of
a
 solution that uses the package system merely as an implementation.  The
 package system tends to make itself rather visible.  For example: one
 cannot write a macro that controls how symbols in the macro body are
 interned, since the symbols are already interned before the macro is
 expanded.  The macro could reintern those symbols, but the "damage"
 would have already been done.  Does what you have in mind avoid such
 problems?

Could you be more specific about the damage that has been done?  How
does this get you in trouble?  If what you are doing is hiding a symbol,
how does the previously interned wider scope symbol interfere?

∂26-Sep-85  0432	AS%hp-hulk.csnet@CSNET-RELAY.ARPA 	Re: ---   
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 26 Sep 85  04:31:26 PDT
Received: from hplabs by csnet-relay.csnet id aa16310; 26 Sep 85 7:23 EDT
Received: by HP-VENUS id AA10987; Wed, 25 Sep 85 15:33:07 pdt
Message-Id: <8509252233.AA10987@HP-VENUS>
Date: Wed 25 Sep 85 15:33:19-PDT
From: Alan Snyder <AS%hplabs.csnet@CSNET-RELAY.ARPA>
Subject: Re: ---
To: Bobrow.pa
Cc: cl-object-oriented-programming@su-ai.arpa
In-Reply-To: Message from "Bobrow.pa@XEROX@HP-VENUS" of Wed 25 Sep 85 09:13:00-PDT
Source-Info:  From (or Sender) name not authenticated.

    Could you be more specific about the damage that has been done?  How
    does this get you in trouble?  If what you are doing is hiding a symbol,
    how does the previously interned wider scope symbol interfere?

Interning a symbol in a package other than where you really want it can
cause problems later on: if the user should change the package structure
using USE-PACKAGE, IMPORT, or EXPORT, an unexpected name clash can occur
because of the unintended symbol in the package.
-------

∂01-Oct-85  0214	hplabs!snyder%hplabs.csnet@CSNET-RELAY.ARPA 	Re: slot shadowing  
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 1 Oct 85  02:14:41 PDT
Received: from hplabs by csnet-relay.csnet id aa20628; 1 Oct 85 5:11 EDT
Received: by HP-VENUS id AA29367; Mon, 30 Sep 85 17:27:05 pdt
Message-Id: <8510010027.AA29367@HP-VENUS>
Date: Monday, September 30, 1985  17:23:21
From: snyder%hplabs.csnet@CSNET-RELAY.ARPA
Subject: Re: slot shadowing
To: Dave.Touretzky%a.cs.cmu.edu@csnet-relay.arpa
Cc: cl-object-oriented-programming@su-ai.arpa
In-Reply-To: Your message of 18-Sep-85  18:55:00
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
Source-Info:  From (or Sender) name not authenticated.

    Why Automatic Shadowing of Slots Is Essential
    
    Dave Touretzky, CMU
    
    
    In this note I will try to explain why automatic shadowing of slots is
    essential to a Common Lisp flavor system.  I have read the ObjectLisp
    document distributed at the IJCAI Common Lisp meeting in Los Angeles, which
    I attended, but I am not otherwise familiar with the CommonLoops or HP
    flavors proposals.  I hope people who do understand these proposals will
    respond to the points raised here.
    
Let me describe how these situations are handled in the HP proposal:

    Example 1:  Customizing a Flavor.  A user of a hairy window system wants to
    create his own flavor of window, called PORTHOLE, which is like an ordinary
    window in most respects.  But PORTHOLE has an instance variable N which the
    user can access and modify.  He defines PORTHOLE as a subtype of WINDOW, and
    writes methods GET-N and SET-N for accessing and setting N.  Unbeknownst to
    him, however, the window system is already using N as the name of a slot.
    
    Suggested behavior:  instances of PORTHOLE should have two slots named N,
    and one of them, WINDOW's N, should be shadowed for PORTHOLE's methods.
    Let P1 be an instance of PORTHOLE.  Sending P1 a GET-N message should access
    the N the user intended:  PORTHOLE's N.  Sending P1 a CLEAR-SCREEN message
    should access the N inherited from WINDOW, since the CLEAR-SCREEN method is
    itself inherited from WINDOW and the user knows nothing about the shadowing
    of WINDOW's N by his own use of the name.
    
The HP proposal behaves pretty much as you suggest.  Instances of PORTHOLE
would have two slots named N.  One slot is accessible to methods defined on
PORTHOLE, the other is accessible to methods defined on WINDOW.

    Example 2:  Replacing a Method.  Suppose a hacker who is familiar with the
    window system wants to create his own type of PORTHOLE, HACKPORT, that uses
    a different CLEAR-SCREEN method.  Since HACKPORT is an instance of PORTHOLE,
    references to N by a HACKPORT method will normally be interpreted as
    references to PORTHOLE's N rather than WINDOW's N.  So we need a way to
    reference the shadowed N in methods defined for PORTHOLE or HACKPORT.  I
    won't suggest a notation for this here.  However, the next example argues
    that we must reference shadowed slots by a point on their inheritance path,
    e.g.  by saying PORTHOLE's N; we can't just say something like SHADOWED-N
    and expect the reference to be resolved.
    
The HP proposal would not allow a HACKPORT method to access either slot N,
unless methods were provided to do so.  The methods to access HACKPORT's N
would be provided by HACKPORT.  The methods to access WINDOW's N would be
provided by WINDOW and passed on (inherited) by HACKPORT.  If these two sets
of methods have the same names, then HACKPORT would have to provide different
names for the methods it passes on from WINDOW, to avoid a conflict.  It would
do this by defining a method GET-WINDOW-N (any name can be used) whose
definition invokes the appropriate method defined by WINDOW (which it refers
to as WINDOW's N).  The package system could be used to create different names
for the methods, if desired.

    Example 3:  Combining Orthogonal Flavors.  A naive user has available
    to him two predefined flavors, WINDOW and STACK, about whose internals
    he knows nothing.  He wants to build a flavor called VISIBLE-STACK,
    which is a stack whose contents are constantly displayed in a window.
    He defines VISIBLE-STACK as a subtype of both WINDOW and STACK, not
    knowing that both these flavors contain instance variables named N.
    
    Suggested behavior:  Let S1 be an instance of VISIBLE-STACK.  Sending
    a POP-STACK message to S1 should access STACK's N, while sending a
    SET-FONT message to S1 should access WINDOW's N.  
    
The HP proposal has this behavior.

    Problem:  let METHA be a method defined for VISIBLE-STACK.  How should
    references to N be interpreted inside METHA?  If VISIBLE-STACK has its own
    instance variable named N, then this N should shadow both WINDOW's N and
    STACK's N.  But if there is no N defined at the level of VISIBLE-STACK, then
    references to N inside METHA should generate an error message:  "N is an
    ambiguous slot reference."
    
If VISIBLE-STACK defines an instance variable N, then METHA will access that
N.  Otherwise, a reference to N within METHA will access the global variable
N, or get an error if there is no global variable N.  As described above, for
METHA to access WINDOW's N or STACK's N, the appropriate methods must be
defined on WINDOW or STACK, and VISIBLE-STACK must declare its desire to
access those variables.

    Problem:  how do we write a new CLEAR-SCREEN method for VISIBLE-STACK?  We
    will need notation to explicitly specify that we want to access the
    shadowed WINDOW's N rather than the shadowed STACK's N.
    
METHA can access WINDOW's N and STACK's N if the appropriate methods are
defined on WINDOW or STACK.  These methods can be accessed without conflict as
WINDOW's N and STACK's N within VISIBLE-STACK.  They can't both be accessed as
variables, however, because of the name conflict.  (The syntax for method
invocation allows qualified names, the syntax for variable reference does
not.)  Furthermore, an error will be generated if VISIBLE-STACK attempts to
inherit BOTH methods, as the method names would conflict.
-------

∂03-Oct-85  1436	DCP@SCRC-QUABBIN.ARPA 	Arguments and values to get.    
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 3 Oct 85  14:36:29 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 207346; Thu 3-Oct-85 17:40:11-EDT
Date: Thu, 3 Oct 85 17:39 EDT
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Arguments and values to get.
To: Gregor.pa@XEROX.ARPA, Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
    Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>, Common-Lisp@SU-AI.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: <850919-174345-1059@Xerox>,
             <FAHLMAN.12144621737.BABYL@C.CS.CMU.EDU>,
             <850920100928.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <851003173940.1.DCP@NEPONSET.SCRC.Symbolics.COM>

Consider
	(incf (get foo bar))
when the property does not exist.  INCF would die adding to NIL.  Thus,
to maintain simple style, you need
	(incf (get foo bar 0))
I think this is a LOT prettier than
	(setf (get foo bar)
	      (multiple-value-bind (value valid-p)
		  (get foo bar)
		(if valid-p (1+ value) 1)))
and the programmer doesn't have to worry about multiple evaluation of
FOO and BAR, since INCF is supposed to take care of that.

∂09-Nov-85  1944	sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA 	addn to the mailing list.	   
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 9 Nov 85  19:41:13 PST
Received: from tektronix by csnet-relay.csnet id ac20521; 9 Nov 85 22:38 EST
From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
To: cl-object-oriented-programming@su-ai.ARPA
Received: from tekchips by tektronix with smtp ; 9 Nov 85 18:24:59 PST
Date: Saturday, 9 Nov 85 18:12:52 PST
Subject:  addn to the mailing list.	

Pl add me to your list. Thanx.

sridhar%tekchips@tektronix.csnet

∂15-Dec-85  1702	RPG  	Call for Papers OOPSLA86     
To:   cl-object-oriented-programming@SU-AI.ARPA 

		    Call For Papers and Participation
			    ACM Conference on
     Object Oriented Programming Systems, Languages, and Applications

            September 29 - October 2, 1986,  Portland, Oregon

OOPSLA-86 is a new ACM-sponsored conference that brings together users and
implementors of object oriented systems.  Through tutorials, papers, panel
discussions and workshops, as well as demonstrations, exhibits and
videotapes, OOPSLA-86 will provide a forum for sharing experience and
knowledge among experts and novices alike.

We invite technical papers, case studies, and surveys in the following
areas:

Theory:     		Including core definition of object oriented
			programming, semantic models and methodology.

Languages:  		Existing object oriented languages, extensions to
			conventional languages, and new languages.

Implementation:  	Including architectural support, compilation and
            		interpretation, and special techniques.

Tools and Environments:	Including user interfaces, utilities and
operating
            		system support.

Applications:  		Commercial, educational, and scientific applications
			that exploit object oriented programming.

Related Work:  		The object oriented paradigm in other fields such as
			databases and operating systems.

Papers on other relevant topics are welcome, as are proposals for
workshops and panel discussions.

All papers will be refereed prior to selection and inclusion in the
conference proceedings.  Technical papers will be selected on the basis of
originality and contribution to the state of the art of design,
implementation, methodology, or practice.  Survey papers will be selected
on the basis of how well they crystallize and integrate, in a way not
previously presented, knowledge about one or more aspects of the field.

Papers must be submitted in English, and should be no longer than 25
double-spaced pages.  The cover page should include a title, an abstract
of not more than 100 words, and author's name, affiliation, address and
phone number.  Five copies must be received by the Program Chairman at the
address below, no later than April 1, 1986.  Authors will be notified of
acceptance by May 1, 1986, and final versions of accepted papers will be
due by June 15, 1986.  As the proceedings of this conference will be
widely disseminated, publication of more than an abstract of a submitted
paper is likely to inhibit republication in ACM's refereed publications.

A room at the conference will be reserved for video presentations that
illustrate or supplement the concepts conveyed in other presentations.
Submissions must run no longer than 15 minutes, and should be on 3/4-inch
U-Matic format tape.  Tapes must be received by the Video Chairman at the
address below, no later than July 1, 1986.

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

Conference Chairmen	Daniel Bobrow (Xerox PARC) (bobrow.pa@XEROX.ARPA)
			Alan Purdy (Servio Logic Development) 
			           <alpurdy@oregon-grad.CSNet>

Program Chairman	Daniel Ingalls, MS 22-Y
(ingalls%apple.csnet@CSNET-RELAY)
			Apple Computer
			20525 Mariani Ave.
			Cupertino, CA 95014

Video Chairman		David Robson (robson.pa@XEROX.ARPA)
			Xerox PARC
			3333 Coyote Hill Road
			Palo Alto, CA 94304

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

∂03-Jan-86  1756	Gregor.pa@Xerox.ARPA 	CommonLoops meets Object Lisp    
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 3 Jan 86  17:55:48 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 03 JAN 86 17:56:06 PST
Date: 3 Jan 86 17:55 PST
Sender: Gregor.pa@Xerox.ARPA
Subject: CommonLoops meets Object Lisp
To: CL-Object-Oriented-Programming@SU-AI.arpa
cc: Gregor.pa@Xerox.ARPA
From: CommonLoopsCore↑.pa@Xerox.ARPA
LineFold: No
Message-ID: <860103-175606-1703@Xerox>

In order to understand what would be involved in implementing ObjectLisp
on top of CommonLoops the CommonLoops group got together with Gary
Drescher to talk about it.

This message is a brief summary of what we discovered.  Understanding
this message requires familiarity with both CommonLoops (CLoops) and
ObjectLisp (OBL).

The major issues are:

1) Each ObjectLisp object is a hybrid of class and instance: it can be
   invoked like an instance, and other objects can inherit from it like
   a class.
2) In OBL method lookup is based on the "current object" (the value of
   the special variable *object*).  In Commonloops method lookup is
   based on the value of one or more of the arguments to the method.
3) In OBL both method-lookup and slot-access inherit from the global
   lisp environment if there is no object-binding.

The key points of the implementation scheme are:

1) Create a new discriminator mixin (discriminate-on-specials-mixin)
   which extends the behavior of the standard CommonLoops discriminator
   by allowing method lookup based on the value of special variables.
   OBL will use this to discriminate based on the value of *OBJECT*.
   Even though this discriminator mixin will discriminate on specials
   it will continue to use the standard CLoops method caching mechanisms.

2) Create a new metaclass object-lisp-metaclass which merges the CLoops
   class-instance relation and the CLoops class-subclass relation to get
   the OBL object-specialization relation.  In order to do this all OBL
   objects will include the object-lisp-metaclass as one of their
   superclasses.
     a) class-of for any OBL object will return the object itself,
     b) so that the superclasses of the class of an object will be the
        supers of the object itself,
     c) Each OBL-bound function FOO for object BAR will implemented
        as a method defined on bar "as a class".
     d) The object-lisp-metaclass will also support a new kind of
        slot-allocation which is a simple extension of :class
        allocation.  This allocation will allow objects and their
        specializations to share the same slot.
     e) The get-slot-using-class method for object-lisp-metaclass will
        implement the object lisp semantics of getting the global
        binding of a variable if that variable is not bound in the
        current object.

∂03-Apr-86  1600	masinter.pa@Xerox.COM 	March 24, 1986 Electronic Engineering Times article 
Received: from XEROX.COM by SU-AI.ARPA with TCP; 3 Apr 86  15:49:25 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 03 APR 86 15:27:26 PST
Date: 3 Apr 86 15:25 PST
From: masinter.pa@Xerox.COM
Subject: March 24, 1986 Electronic Engineering Times article
To: cl-object-oriented-programming@su-ai.ARPA
Message-ID: <860403-152726-1821@Xerox>

I believe this is a reasonably accurate transcription of the article.

From the March 24, 1986 Electronic Engineering Times:

Object-Oriented Extension to Lisp Language Offered
---------------------------------------------------

By Tom J. Schwartz


ANDOVER, Mass. -- The first object-oriented extension of the AI language
CommonLisp will be shipped this week.  LMI Machine Inc.'s ObjectLisp
allows generic operations to be performed on modular units, called
objects.

LMI Machines has gotten the jump on Xerox Corp. (El Segundo, CA), which
had promised to deliver a similar language, CommonLoops, by August (see
EE Times, Aug. 26, Page 1).  Xerox hasn't shipped, so LMI Machines broke
out of the gate with ObjectLisp. However, Xerox is in beta test with
CommonLoops.

CommonLisp users now have to build their own object-oriented extensions.
And yet, there's no universal standard on how to write Lisp code to deal
with objects.

A cogent example of ObjectLisp applies to the military.  Objects might
include friendly and hostile fighter planes, helicopters, and missiles.
Computer simulations of these objects can be grouped into generic types
-- moving objects.  Characteristics of moving objects can be identified
as fighters, helicopters, and missiles.

LMI's object-oriented programming incoporates a unique function: It's
able to pass messages among these objects.  ObjectLisp offers a mature
object-oriented dialogue.  And it uses syntax consistent with
CommonLisp. The message-passing function is akin to the concept of its
predecessor, SmallTalk.

SmallTalk was introduced in the 1970s at Xerox Corp.'s Palo Alto
Research Center, and it incorporated the method of representing modular
units or objects.

"ObjectLisp does not distinguish among classes and instances," said LMI
president Robert Moore, "and provides the user with a powerful and very
flexible semantic base."

CommonLisp has become the only common denominator among all Lisp
dialects that enables users to pass programs to each other.

In The Beginning
----------------

Four years ago, a group of AI innovators conceived CommonLisp as a
minimal implementation of the first symbolic programming language.
Thirty years ago, John McCarthy began work on Lisp at MIT.

The language acquired many dialects as it matured.  They were needed to
meet widely varying expectations.  Eventually, the DoD and university
researchers suggested that the proliferation of dialects should stop.

CMU and an informal ad hoc committee of Lisp researchers undertook to
create a universal software standard.  They did it in less than four
years.  Almost the entire AI community supports CommonLisp.  And IBM
reportedly has solicited bids on development of a Lisp dialect that
could merge its VM Lisp with CommonLisp.

"The time was right for CommonLisp and the ad hoc committee made the
difference," said Patrick Winston, director of MIT's AI lab.  He's the
author of a book entitled 'Lisp'.  "If the IEEE had become involved, it
could have taken another twenty years to get a Lisp standard," he added.

Industry response to these proposals has been mixed.  Dr. Raj Reddy,
director of the Robotics Institute at CMU said, "In the case of these
object-oriented extensions, we don't have the twenty years of experience
we had in Lisp.  I think it may be too early to try to formulate a
standard."

Lucid Makes Vision Clear
------------------------

Lucid Inc. Chairman Tony Slocum disagreed.  "We have a clear vision of
what symbolic computing should be," he said.  "I think these companies
are doing the right thing.  People should put forth what they believe
in.

"The marketplace and the community will focus in and form an accepted
standard," he added.

Lucid (Menlo Park, CA) manufactures a fast CommonLisp which runs on many
machines.

LMI intends to maintain ObjectLisp in portable form.  This would enable
it to run on many machines and under a number of CommonLisp
implementations.

These include: Sun 2 and 3 workstations, which run Sun CommonLisp from
Lucid; the IBM PC AT, which runs Gold Hill Golden CommonLisp; DEC's
VAX/VMS, running NIL; DEC's MicroVAX, running DEC CommonLisp; the
Silicon Graphics Workstation, running Franz Inc.'s CommonLisp; and
Symbolics 3600 CommonLisp.

The source code and specification of CommonLisp is avaialble free from
LMI.  But there's a media charge of $195.

∂04-Apr-86  0945	kempf%hplabsc@hplabs.ARPA 	Re:  March 24, 1986 Electronic Engineering Times article  
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 4 Apr 86  09:40:07 PST
Received: from hplabsc by hplabs.ARPA ; Fri, 4 Apr 86 09:38:15 pst
Received: by hplabsc ; Fri, 4 Apr 86 09:39:57 pst
Date: Fri, 4 Apr 86 09:39:57 pst
From: Jim Kempf <kempf%hplabsc@hplabs.ARPA>
Message-Id: <8604041739.AA12014@hplabsc>
To: cl-object-oriented-programming@su-ai.ARPA, masinter.pa@Xerox.COM
Subject: Re:  March 24, 1986 Electronic Engineering Times article

HP has had CommonObjects, our object oriented extension to Common
Lisp on the corporate price list for about a month or so. It
comes as part of the Development Environment for Common Lisp.
I don't know how the author got his information that LMI was
the first company to release an object-oriented extension.
		Jim Kempf	kempf@hplabs

∂04-Apr-86  1102	Masinter.pa@Xerox.COM 	Re:  March 24, 1986 Electronic Engineering Times article 
Received: from XEROX.COM by SU-AI.ARPA with TCP; 4 Apr 86  11:02:09 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 04 APR 86 11:03:00 PST
Date: 4 Apr 86 10:37 PST
From: Masinter.pa@Xerox.COM
Subject: Re:  March 24, 1986 Electronic Engineering Times article
In-reply-to: Jim Kempf <kempf%hplabsc@hplabs.ARPA>'s message of Fri, 4
 Apr 86 09:39:57 pst
To: cl-object-oriented-programming@su-ai.ARPA
Message-ID: <860404-110300-2544@Xerox>

The article has enough misinformation (e.g. "The source code and
specification of CommonLisp is available free from LMI.") that I thought
of it as a source of humor.... probably a combination of an
overimaginative member of the LMI marketing organization coupled with a
more than usually sloppy reporter.

I didn't mean to imply any belief that the *content* of the article was
factual-- only that the message actually transcribed what was printed in
the paper.



∂03-Jul-86  1112	snyder%hplsny@hplabs.HP.COM 	two questions about New Flavors
Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 3 Jul 86  11:12:03 PDT
Received: from hplsny by hplabs.HP.COM ; Thu, 3 Jul 86 11:09:41 pdt
Received: by hplsny ; Thu, 3 Jul 86 11:09:24 pdt
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
Message-Id: <8607031809.AA03276@hplsny>
Date: Thursday, July 3, 1986  11:09:14
Subject: two questions about New Flavors
To: cl-object-oriented-programming@su-ai.ARPA
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46

Sorry to wake everybody up, but I have a couple of questions about New Flavors
that I thought might be of general interest.

1. How does one update Old Flavors code that uses keyword method names?  Does
New Flavors allow generic functions with keyword names?

2. Does New Flavors have any notion of a default handler for Undefined
Methods?  In other words, does an invocation of an undefined function get
turned into an invocation of a generic function with the function name
as an argument?

  Alan
-------

∂03-Jul-86  1708	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	two questions about New Flavors    
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 3 Jul 86  17:08:43 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 35657; Thu 3-Jul-86 19:51:46 EDT
Date: Thu, 3 Jul 86 19:51 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: two questions about New Flavors
To: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: <8607031809.AA03276@hplsny>
Message-ID: <860703195109.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thursday, July 3, 1986  11:09:14
    From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>

    Sorry to wake everybody up, but I have a couple of questions about New Flavors
    that I thought might be of general interest.

Oh that's all right, I was kind of nodding off.

    1. How does one update Old Flavors code that uses keyword method names?  Does
    New Flavors allow generic functions with keyword names?

New Flavors as implemented by Symbolics includes virtually full
compatibility with the past.  This means updated Old Flavors code
can continue to use message passing (SEND) just as it did before.  I
consider all this to be a compatibility feature to ease transition for
our users, not an inherent part of the New Flavors language.  Other
implementations of New Flavors might choose to omit message passing,
in which case one of course could not import old code that uses message
passing.  In discussions with the Common Lisp community I have tended
to downplay the compatibility features because I don't think they
are interesting in their own right.

Of course it's legal to defun a keyword as a function, but in practice
nobody ever does that (as far as I know).

    2. Does New Flavors have any notion of a default handler for Undefined
    Methods?  In other words, does an invocation of an undefined function get
    turned into an invocation of a generic function with the function name
    as an argument?

Functions only become generic functions if you either define them
explicitly by evaluating a DEFGENERIC or define them implicitly by
evaluating a DEFMETHOD (neglecting other implicit definitions such as
:READABLE-INSTANCE-VARIABLES).  This means that if you call an undefined
function that nobody ever heard of, that's an ordinary undefined
function and it does whatever error processing your Lisp normally does.
In fact the error handling system turns this into the signalling of a
condition, which could be handled by the dynamic state of the program
(not by one of the arguments to the function).  If, on the other hand,
you call a function that has been explicitly or implicitly defined to be
a generic function, then it's defined and it dispatches on the type of
whatever argument(s) you defined it to dispatch upon.  If no method is
defined, that's an error in its own right, which in fact does turn into
the invocation of a generic function with the original function (I think
it's the function definition rather than the function name) as an argument.

Another way of saying this is that Flavors is not Smalltalk -- it does
not replace the entire Lisp system in which it is embedded with a fully
object-oriented system; you still have your choice of functional or
object-oriented style.

∂18-Jul-86  1343	snyder%hplsny@hplabs.HP.COM 	accessor functions   
Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 18 Jul 86  13:43:38 PDT
Received: from hplsny by hplabs.HP.COM ; Fri, 18 Jul 86 13:43:07 pdt
Received: by hplsny ; Fri, 18 Jul 86 13:42:51 pdt
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
Message-Id: <8607182042.AA00557@hplsny>
Date: Fri, 18 Jul 86  13:42:03 PDT
Subject: accessor functions
To: cl-object-oriented-programming@su-ai.ARPA
X-Mailer: NMail [$Revision: 2.5 $]

Question for New Flavors:

  Is the accessor function created for a :readable-instance-variable defined
  to be an ordinary function or a generic function?

Question for CommonLoops:

  Is the accessor function created for a slot defined to be an ordinary
  function or a generic function?
-------

∂18-Jul-86  1442	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	accessor functions  
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 18 Jul 86  14:41:40 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 45393; Fri 18-Jul-86 17:37:05 EDT
Date: Fri, 18 Jul 86 17:37 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: accessor functions
To: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: <8607182042.AA00557@hplsny>
Message-ID: <860718173708.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 18 Jul 86  13:42:03 PDT
    From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>

    Question for New Flavors:

      Is the accessor function created for a :readable-instance-variable defined
      to be an ordinary function or a generic function?

Generic.  What would ever make you think otherwise?

∂21-Jul-86  1253	Gregor.pa@Xerox.COM 	Re: accessor functions  
Received: from XEROX.COM by SU-AI.ARPA with TCP; 21 Jul 86  12:53:22 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUL 86 12:53:26 PDT
Date: 21 Jul 86 12:52 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: accessor functions
In-reply-to: Alan Snyder <snyder%hplsny@hplabs.HP.COM>'s message of Fri,
 18 Jul 86 13:42:03 PDT
To: snyder%hplsny@hplabs.HP.COM
cc: cl-object-oriented-programming@su-ai.ARPA
Message-ID: <860721-125326-1799@Xerox>

    Question for CommonLoops:

      Is the accessor function created for a slot defined to be an ordinary
      function or a generic function?

Generic function.

∂23-Jul-86  1217	snyder%hplsny@hplabs.HP.COM 	Re: accessor functions    
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 23 Jul 86  12:17:09 PDT
Received: from hplsny by hplabs.HP.COM ; Wed, 23 Jul 86 12:16:12 pdt
Received: by hplsny ; Wed, 23 Jul 86 12:16:00 pdt
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
Message-Id: <8607231916.AA02853@hplsny>
Date: Wed, 23 Jul 86  12:15:49 PDT
Subject: Re: accessor functions
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: Your message of 18-Jul-86  17:37:00
X-Mailer: NMail [$Revision: 2.5 $]

    Date: Fri, 18 Jul 86 17:37 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

        Is the accessor function created for a :readable-instance-variable defined
        to be an ordinary function or a generic function?
    
    Generic.  What would ever make you think otherwise?

Well, I did think that they most likely were generic, but I wanted to be sure
(I did not find an answer in the documentation I have).

However, there are a couple of things that might lead one to think otherwise:

  1. The most recent documentation I have indicates that the names of
     accessor functions in both New Flavors and CommonLoops include
     the name of the class as a prefix (at least by default).  If the
     accessor functions are generic, this extra "protection" against
     name conflicts would seem unnecessary and perhaps undesirable.
     What's the rationale for this default?

  2. It is useful to be able to inline-expand invocations of the accessor
     functions.  (Inline substitution is normal for structures, isn't it?)
     Since generic functions work on subclasses, inline substitution of
     accessor functions in generic functions is not possible unless one
     prohibits redefinition of the accessor functions by subclasses (or the
     invocations are defined to be immune from such redefinition -- which can
     be achieved in CommonObjects by using CALL-METHOD).  Making the accessor
     functions ordinary functions is one way to prohibit redefinition by a
     subclass.
-------

∂23-Jul-86  1333	Gregor.pa@Xerox.COM 	Re: accessor functions  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Jul 86  13:32:17 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 JUL 86 13:27:29 PDT
Date: 23 Jul 86 13:27 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: accessor functions
In-reply-to: Alan Snyder <snyder%hplsny@hplabs.HP.COM>'s message of Wed,
 23 Jul 86 12:15:49 PDT
To: snyder%hplsny@hplabs.HP.COM
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM,
 cl-object-oriented-programming@SU-AI.ARPA
Message-ID: <860723-132729-1738@Xerox>

    From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
    Subject: Re: accessor functions

      1. The most recent documentation I have indicates that the names
of
         accessor functions in both New Flavors and CommonLoops include
         the name of the class as a prefix (at least by default).  If
the
         accessor functions are generic, this extra "protection" against
         name conflicts would seem unnecessary and perhaps undesirable.
         What's the rationale for this default?

It is true that the default value for the "conc-name" is the name of the
class.  But in practice I tend to use the same conc-name for all the
classes in a class-tree.  As an example, in PCL the conc-name for
essential-class and all the classes which include it is "class-".  This
means that the accessor for the slots of any kind of class is
"CLASS-SLOTS".  When I see "(class-slots x)" in code, I read it as "x is
some kind of class, there will be a method on class-slots which knows
how to get x's slots.

While generic functions let you use a conc-name of nil I personally
don't like this style.  As an example, using conc-name nil would allow
the accessor for all things which have a name to be just "NAME".  I
prefer to see "(CLASS-NAME x)" because it tells me that x is some kind
of class.

Perhaps a more liberal use of packages or just the passage of time will
change my philosophy about this, I don't know.  

∂24-Jul-86  1157	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Re: accessor functions   
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 24 Jul 86  11:50:50 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 49123; Thu 24-Jul-86 14:50:33 EDT
Date: Thu, 24 Jul 86 14:50 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: accessor functions
To: Gregor Kiczales <Gregor.pa@Xerox.COM>
cc: snyder%hplsny@hplabs.HP.COM,
    cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: <860723-132729-1738@Xerox>
Message-ID: <860724145017.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

I and most (but not all!) of my users agree with this philosophy
and use it also.

    Date: 23 Jul 86 13:27 PDT
    From: Gregor Kiczales <Gregor.pa@Xerox.COM>

    It is true that the default value for the "conc-name" is the name of the
    class.  But in practice I tend to use the same conc-name for all the
    classes in a class-tree.  As an example, in PCL the conc-name for
    essential-class and all the classes which include it is "class-".  This
    means that the accessor for the slots of any kind of class is
    "CLASS-SLOTS".  When I see "(class-slots x)" in code, I read it as "x is
    some kind of class, there will be a method on class-slots which knows
    how to get x's slots.

    While generic functions let you use a conc-name of nil I personally
    don't like this style.  As an example, using conc-name nil would allow
    the accessor for all things which have a name to be just "NAME".  I
    prefer to see "(CLASS-NAME x)" because it tells me that x is some kind
    of class.

    Perhaps a more liberal use of packages or just the passage of time will
    change my philosophy about this, I don't know.  

∂24-Jul-86  1244	snyder%hplsny@hplabs.HP.COM 	Re: accessor functions    
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 24 Jul 86  12:26:09 PDT
Received: from hplsny by hplabs.HP.COM ; Thu, 24 Jul 86 12:25:32 pdt
Received: by hplsny ; Thu, 24 Jul 86 12:25:20 pdt
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
Message-Id: <8607241925.AA03667@hplsny>
Date: Thu, 24 Jul 86  12:25:12 PDT
Subject: Re: accessor functions
To: cl-object-oriented-programming@su-ai.ARPA
X-Mailer: NMail [$Revision: 2.5 $]

    Date: Thu, 24 Jul 86 14:50 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    
    I and most (but not all!) of my users agree with this philosophy
    and use it also.
    
    Date: 23 Jul 86 13:27 PDT
    From: Gregor Kiczales <Gregor.pa@Xerox.COM>
    
    It is true that the default value for the "conc-name" is the name of the
    class.  But in practice I tend to use the same conc-name for all the
    classes in a class-tree.  As an example, in PCL the conc-name for
    essential-class and all the classes which include it is "class-".  This
    means that the accessor for the slots of any kind of class is
    "CLASS-SLOTS".  When I see "(class-slots x)" in code, I read it as "x is
    some kind of class, there will be a method on class-slots which knows
    how to get x's slots.
    
    While generic functions let you use a conc-name of nil I personally
    don't like this style.  As an example, using conc-name nil would allow
    the accessor for all things which have a name to be just "NAME".  I
    prefer to see "(CLASS-NAME x)" because it tells me that x is some kind
    of class.
    
    Perhaps a more liberal use of packages or just the passage of time will
    change my philosophy about this, I don't know.  

Indeed, this does seem somewhat redundant with the package system.
Do you (and your users) also typically define a separate package for
an entire "class-tree"?  If so, why not use CLASS:NAME instead of
CLASS-NAME?

Also, do you use the CLASS- prefix for ALL operations defined
on a CLASS, or just the instance variable accessor functions?
I notice in the SHIP example in the December 85 New Flavors paper that
the function SHIP-MASS is defined to read the MASS instance variable,
but the function SPEED (rather than SHIP-SPEED) is defined to
compute the speed.  Is MASS less generic than SPEED?

  Alan
-------

∂24-Jul-86  2046	Carnese@SRI-KL.ARPA 	Re: accessor functions  
Received: from SRI-KL.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 86  20:45:56 PDT
Date: Thu 24 Jul 86 16:45:33-PDT
From: Dan Carnese <Carnese@SRI-KL>
Subject: Re: accessor functions
To: cl-object-oriented-programming%SU-AI@SRI-KL
In-Reply-To: Message from "David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>" of Thu 24 Jul 86 13:01:48-PDT

    Date: Thu, 24 Jul 86 14:50 EDT
    From: David A. Moon

    I and most (but not all!) of my users agree with this philosophy
    and use it also.

        Date: 23 Jul 86 13:27 PDT
        From: Gregor Kiczales <Gregor.pa@Xerox.COM>

        It is true that the default value for the "conc-name" is the name of the
        class.  But in practice I tend to use the same conc-name for all the
        classes in a class-tree.  As an example, in PCL the conc-name for
        essential-class and all the classes which include it is "class-".  This
        means that the accessor for the slots of any kind of class is
        "CLASS-SLOTS".  When I see "(class-slots x)" in code, I read it as "x is
        some kind of class, there will be a method on class-slots which knows
        how to get x's slots.

        While generic functions let you use a conc-name of nil I personally
        don't like this style.  As an example, using conc-name nil would allow
        the accessor for all things which have a name to be just "NAME".  I
        prefer to see "(CLASS-NAME x)" because it tells me that x is some kind
        of class.

        Perhaps a more liberal use of packages or just the passage of time will
        change my philosophy about this, I don't know.  

Well, the obvious problem with this convention is that you have to change a
potentially large number of function names if you ever decide to rename a
class.  This was in fact a major drawback to the old Clu requirement that
all operations include the name of the type (e.g., class$frob).  Alan will
appreciate the irony that in some circles this is now considered
appropriate Lisp style.

Seriously, though, there is a good argument that the semantics of type
operations should be tied to each other, not to a particular symbol naming
the type.  E.g., the push and pop functions should be defined in terms of a
(push pop) complex, not a random name like "stack".  Of course, there's no
problem with using the variable "stack" to refer to this complex, in just
the same way that the variable "zero" can be used to refer to the object 0.

Most contemporary work in type theory and type inference conceptualizes
types as collections of operations.  Intelligent type checking involves the
computation of the minimal set of operations required for each parameter of
each function to guarantee that no possible invocation can cause a "missing
alternative for generic function" error.  Such sets are in general a
subset of the complete operation set of a type.

-- Dan
-------

∂25-Jul-86  0843	@SRI-KL.ARPA:DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Re: accessor functions 
Received: from SRI-KL.ARPA by SAIL.STANFORD.EDU with TCP; 25 Jul 86  08:42:51 PDT
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM ([192.10.41.41].#Internet) by SRI-KL.ARPA with TCP; Fri 25 Jul 86 08:42:44-PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 49928; Fri 25-Jul-86 11:41:50 EDT
Date: Fri, 25 Jul 86 11:43 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: accessor functions
To: Carnese@SRI-KL.ARPA,
    cl-object-oriented-programming%SU-AI@SRI-KL.ARPA
In-Reply-To: The message of 24 Jul 86 19:45 EDT from Dan Carnese <Carnese@SRI-KL>
Message-ID: <860725114331.6.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Thu 24 Jul 86 16:45:33-PDT
    From: Dan Carnese <Carnese@SRI-KL>

	Date: Thu, 24 Jul 86 14:50 EDT
	From: David A. Moon

	I and most (but not all!) of my users agree with this philosophy
	and use it also.

I agree with one amendment: I'd use the same conc-name for all the
classes (flavors) of a protocol.  Not all flavors that implement a given
protocol need have some common ancestor, at least in theory, although
usually they do and so usually what Gregor said (class-tree) amounts to
the same thing.  (See further discussion of this issue, below.)

	    Date: 23 Jul 86 13:27 PDT
	    From: Gregor Kiczales <Gregor.pa@Xerox.COM>

	    While generic functions let you use a conc-name of nil I personally
	    don't like this style.  As an example, using conc-name nil would allow
	    the accessor for all things which have a name to be just "NAME".  I
	    prefer to see "(CLASS-NAME x)" because it tells me that x is some kind
	    of class.

Right, and the point here is that CLASS is a protocol.

    Well, the obvious problem with this convention is that you have to change a
    potentially large number of function names if you ever decide to rename a
    class.  

No, only if you decide to rename a protocol.  Renaming an individual
class, an individual implementation of the protocol, doesn't incur that
cost.

    Seriously, though, there is a good argument that the semantics of type
    operations should be tied to each other, not to a particular symbol naming
    the type.  E.g., the push and pop functions should be defined in terms of a
    (push pop) complex, not a random name like "stack".  Of course, there's no
    problem with using the variable "stack" to refer to this complex, in just
    the same way that the variable "zero" can be used to refer to the object 0.

My point is to make the distinction between names of implementations and
names of protocols.  The generic concept of pushing, as part of a
protocol that includes pushing, popping, and other things that make
sense for something that implements the abstraction of
being-like-a-push-down-list, are operations that are members of a
protocol, and affixing a constant prefix to each one of them, to remind
us what protocol they come from, makes sense.  This prefix need not
necesssarily have anything to do with any particular class/flavor that
implements the protocol.

    Most contemporary work in type theory and type inference conceptualizes
    types as collections of operations.  Intelligent type checking involves the
    computation of the minimal set of operations required for each parameter of
    each function to guarantee that no possible invocation can cause a "missing
    alternative for generic function" error.  Such sets are in general a
    subset of the complete operation set of a type.

In the sense of this paragraph, "type" means "protocol" rather than "class".

Now, Flavors does not have an explicit concept of a protocol right now,
and I don't think CommonLoops does as far as I know.  Instead, both
systems pretty much rely on the fact that there's usually some "abstract
class" that all implementors of the protocol are built on, and this
abstract class is what actually identifies and names the protocol.
Hence the convention that Gregor and Moon describe above.

(Speaking for myself.  I haven't discussed this previously with Gregor
and I apologize if I'm misrepresenting him.)

∂25-Jul-86  0922	DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Re: accessor functions    
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 25 Jul 86  09:13:15 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 49963; Fri 25-Jul-86 12:09:15 EDT
Date: Fri, 25 Jul 86 12:10 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: accessor functions
To: snyder%hplsny@hplabs.HP.COM,
    cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: <8607241925.AA03667@hplsny>
Message-ID: <860725121045.8.DLW@CHICOPEE.SCRC.Symbolics.COM>

(I know this was addressed to Moon and Gregor, but I'll answer anyway
whilst I look forward to seeing their answers.  Let me emphasize again
that I don't speak for Moon on this issue.)

    Date: Thu, 24 Jul 86  12:25:12 PDT
    From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>

    Indeed, this does seem somewhat redundant with the package system.
    Do you (and your users) also typically define a separate package for
    an entire "class-tree"?  If so, why not use CLASS:NAME instead of
    CLASS-NAME?

Well, actually, even apart from object oriented programming, one always
has to make the choice between putting things in their own package, or
using a prefix, or whatever.  I don't think we've been using New Flavors
long enough that a very clear dominant style preference has emerged.

I recently converted our error/condition system to use generic functions
wherever it used to use messages.  It happens that there's already a
package called DEBUGGER, or DBG for short, that doesn't have much in it
besides the error/condition stuff and the interactive debugger.  So
several of the generic function names are simply things like DBG:REPORT,
DBG:PROCEED-TYPES, etc.  On the other hand, we also used the names
DBG:CONDITION-STATUS and DBG:CONDITION-TYPE, which we felt were clearer.

In any case, I think this is the same issue that arises with non-generic
function naming, and doesn't have anything to do with genericness (with
object-oriented programming) per se.

    Also, do you use the CLASS- prefix for ALL operations defined
    on a CLASS, or just the instance variable accessor functions?
    I notice in the SHIP example in the December 85 New Flavors paper that
    the function SHIP-MASS is defined to read the MASS instance variable,
    but the function SPEED (rather than SHIP-SPEED) is defined to
    compute the speed.  Is MASS less generic than SPEED?

I don't know about the particular example, but in general there is no
reason to treat an instance variable accessor function any differently
than any other generic function.  They could have been written by hand,
if defflavor didn't provide a handy-dandy convenience feature to write
them for you.  Most important, the caller does not and should not know
whether any generic function is or is not an instance variable accessor
function; that's the business of the implementation, and not visible in
the protocol specification.

∂25-Jul-86  1222	snyder%hplsny@hplabs.HP.COM 	Re: accessor functions    
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 25 Jul 86  12:18:29 PDT
Received: from hplsny by hplabs.HP.COM ; Fri, 25 Jul 86 12:17:18 pdt
Received: by hplsny ; Fri, 25 Jul 86 10:54:53 pdt
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
Message-Id: <8607251754.AA04457@hplsny>
Date: Fri, 25 Jul 86  10:54:13 PDT
Subject: Re: accessor functions
To: DLW@QUABBIN.SCRC.Symbolics.COM
Cc: cl-object-oriented-programming@su-ai.ARPA
In-Reply-To: Your message of 25-Jul-86  12:10:00
X-Mailer: NMail [$Revision: 2.5 $]

    Date: Fri, 25 Jul 86 12:10 EDT
    From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>

        Date: Thu, 24 Jul 86  12:25:12 PDT
        From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>

        Indeed, this does seem somewhat redundant with the package system.
        Do you (and your users) also typically define a separate package for
        an entire "class-tree"?  If so, why not use CLASS:NAME instead of
        CLASS-NAME?

    Well, actually, even apart from object oriented programming, one always
    has to make the choice between putting things in their own package, or
    using a prefix, or whatever.  I don't think we've been using New Flavors
    long enough that a very clear dominant style preference has emerged.

    I recently converted our error/condition system to use generic functions
    wherever it used to use messages.  It happens that there's already a
    package called DEBUGGER, or DBG for short, that doesn't have much in it
    besides the error/condition stuff and the interactive debugger.  So
    several of the generic function names are simply things like DBG:REPORT,
    DBG:PROCEED-TYPES, etc.  On the other hand, we also used the names
    DBG:CONDITION-STATUS and DBG:CONDITION-TYPE, which we felt were clearer.

Even better would be DBG:CONDITION:STATUS and DBG:CONDITION:TYPE I would
think (if such a thing were legal).

    In any case, I think this is the same issue that arises with non-generic
    function naming, and doesn't have anything to do with genericness (with
    object-oriented programming) per se.

There are many cases where the introduction of object-oriented programming
tends to focus attention of existing problems in Common Lisp.  The package
system is probably the worst offender.  However, if you are implying that
because these problems are already in Common Lisp we should not worry about
them now, I disagree.  The interactions with object-oriented programming make
it especially important that these problems be fixed now.

        Also, do you use the CLASS- prefix for ALL operations defined
        on a CLASS, or just the instance variable accessor functions?
        I notice in the SHIP example in the December 85 New Flavors paper that
        the function SHIP-MASS is defined to read the MASS instance variable,
        but the function SPEED (rather than SHIP-SPEED) is defined to
        compute the speed.  Is MASS less generic than SPEED?

    I don't know about the particular example, but in general there is no
    reason to treat an instance variable accessor function any differently
    than any other generic function.  They could have been written by hand,
    if defflavor didn't provide a handy-dandy convenience feature to write
    them for you.  Most important, the caller does not and should not know
    whether any generic function is or is not an instance variable accessor
    function; that's the business of the implementation, and not visible in
    the protocol specification.

I agree completely.  Why then is there a conc-name feature (with a particular
default) for automatically generated functions and not for those explicitly
written?
-------

∂26-Jul-86  1048	DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Re: accessor functions    
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 26 Jul 86  10:48:18 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 50683; Sat 26-Jul-86 13:48:01 EDT
Date: Sat, 26 Jul 86 13:49 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: accessor functions
To: snyder%hplsny@hplabs.HP.COM
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: <8607251754.AA04457@hplsny>
Message-ID: <860726134941.1.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Fri, 25 Jul 86  10:54:13 PDT
    From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>

    Even better would be DBG:CONDITION:STATUS and DBG:CONDITION:TYPE I would
    think (if such a thing were legal).

In fact, the package system the Alan Bawden and I designed and
implemented for the MIT Lisp Machine system, which was superseded by the
present Common Lisp package system, did have exactly this functionality.
I believe it was removed during the Common Lisp redesign in the
interests of simplicity.  However, as time goes on, I've been wondering
whether that was such a good idea.

	In any case, I think this is the same issue that arises with non-generic
	function naming, and doesn't have anything to do with genericness (with
	object-oriented programming) per se.

    There are many cases where the introduction of object-oriented programming
    tends to focus attention of existing problems in Common Lisp.  The package
    system is probably the worst offender.  However, if you are implying that
    because these problems are already in Common Lisp we should not worry about
    them now, I disagree.  The interactions with object-oriented programming make
    it especially important that these problems be fixed now.

I didn't say that we should not worry about them.  I only said that the
problem isn't specific to object-oriented programming.  And I'm not
convinced yet that interactions with object-oriented programming
particularly exacerbate the problem, since I think the problem is just
as real even if you program with ordinary functions and defstructs.  In
any case, if you have a proposal for an improvement that you think could
be introduced into Common Lisp under the current set of ground rules
(see recent Fahlman mail), you should go ahead.

    I agree completely.  Why then is there a conc-name feature (with a particular
    default) for automatically generated functions and not for those explicitly
    written?

Well, if defflavor is going to generate functions automatically, it has
to call them something.  If we are going to encourage a programming
style in which you can make up your own names for instance variables as
easily as you can make up your own names for lexical variables (note
that careful phrasing), then using those instance variable names as
function names is hazardous, because the naming world of function names
is a package (broad), whereas the naming world of an instance variable
is only a set of comixed flavors (narrow).  If we assumed a much finer
granularity for packages, then perhaps the default conc-name feature
would not be appropriate.  I guess this is what you mean about the
particular interaction of OOP and the use of packages.

This leads into a pretty deep issue of what packages are about, and what
spaces are of names are for in general and how various naming mechanisms
interact in a language.  I could go on for a long time disussing my
thoughts on this topic, but I'm not sure that would do anybody any good.
Let me just say that changing packages to the point where the conc-name
would not be the appropriate default would be a truly massive change in
the nature of what packages are for and how they are used.  It would
have very wide implications, and might require a lot of other changes to
the language.  I obviously cannot comment on a proposed change that has
not been proposed, but in my opinion it would be a big thing, not a little
thing.

∂26-Jul-86  1551	Gregor.pa@Xerox.COM 	Re: accessor functions  
Received: from XEROX.COM by SU-AI.ARPA with TCP; 26 Jul 86  15:51:07 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 26 JUL 86 15:50:34 PDT
Date: 26 Jul 86 15:50 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: accessor functions
In-reply-to: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>'s
 message of Sat, 26 Jul 86 13:49 EDT
To: DLW@QUABBIN.SCRC.Symbolics.COM
cc: snyder%hplsny@hplabs.HP.COM,
 cl-object-oriented-programming@SU-AI.ARPA
Message-ID: <860726-155034-1858@Xerox>

I agree with most of what Dan said, I just wanted to add that...

The reason I tend to use class-name instead of class:name is that I use
one package for an entire program rather than many packages for the many
parts of a program.  In PCL, there is one package which has the symbols
CLASS-NAME and DISCRIMINATOR-NAME in it.

∂28-Jul-86  1535	Carnese@SRI-KL.ARPA 
Received: from SRI-KL.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86  15:34:51 PDT
Date: Mon, 28 Jul 1986 11:26 PDT
From: Carnese@SRI-KL
To:   dlw at QUABBIN.SCRC.Symbolics.COM
      snyder%hplsny at hplabs.HP.COM
cc:   cl-object-oriented-programming at su-ai

    Date: Fri, 25 Jul 86 11:43 EDT
    From: Daniel L. Weinreb

        Date: Thu 24 Jul 86 16:45:33-PDT
        From: Dan Carnese <Carnese@SRI-KL>

        Well, the obvious problem with this convention is that you have to change a
        potentially large number of function names if you ever decide to rename a
        class.  

    No, only if you decide to rename a protocol.  Renaming an individual
    class, an individual implementation of the protocol, doesn't incur that
    cost.

True enough -- renaming classes which do not add any new operations is no
problem.  But I hope you're not arguing that making it more difficult to
rename the rest of the classes is not that bad.  Moving operations around
a class hierarchy is critical to deriving appropriate protocols.

    My point is to make the distinction between names of implementations and
    names of protocols.  The generic concept of pushing, as part of a
    protocol that includes pushing, popping, and other things that make
    sense for something that implements the abstraction of
    being-like-a-push-down-list, are operations that are members of a
    protocol, and affixing a constant prefix to each one of them, to remind
    us what protocol they come from, makes sense.  This prefix need not
    necesssarily have anything to do with any particular class/flavor that
    implements the protocol.

Sure, it would be nice to be reminded of the connection between a function
nanme and a protocol.  But expressing this connection syntactically, in a
way that may require a good deal of non-local modification as the program
evolves, seems a bad idea.  What's called for is a more powerful set of
program interaction tools, so that looking at code in an editor or in
hardcopy would make these connections apparent.  Such tools are not hard to
envision, and simple versions would be straightforward additions to
existing programming environments.

    Date: Sat, 26 Jul 86 13:49 EDT
    From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>

        Date: Fri, 25 Jul 86  10:54:13 PDT
        From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>

        Why then is there a conc-name feature (with a particular
        default) for automatically generated functions and not for those explicitly
        written?

    Well, if defflavor is going to generate functions automatically, it has
    to call them something.  If we are going to encourage a programming
    style in which you can make up your own names for instance variables as
    easily as you can make up your own names for lexical variables (note
    that careful phrasing), then using those instance variable names as
    function names is hazardous, because the naming world of function names
    is a package (broad), whereas the naming world of an instance variable
    is only a set of comixed flavors (narrow).  If we assumed a much finer
    granularity for packages, then perhaps the default conc-name feature
    would not be appropriate.  I guess this is what you mean about the
    particular interaction of OOP and the use of packages.

The real problem is that defstruct doesn't allow any way to distinguish
between ``internal'' and ``external'' instance variables.  A conc-name
option which was applicable to the former but not the latter would allow
both of you to easily get the behavior you want.

-- Dan

∂29-Jul-86  1550	Gregor.pa@Xerox.COM 	Re: ---  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Jul 86  15:36:24 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 JUL 86 15:35:39 PDT
Date: 29 Jul 86 15:35 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: ---
In-reply-to: Carnese@SRI-KL.ARPA's message of Mon, 28 Jul 86 11:26 PDT
To: Carnese@SRI-KL.ARPA
cc: cl-object-oriented-programming@su-ai.ARPA
Message-ID: <860729-153539-4146@Xerox>

    From: Carnese@SRI-KL.ARPA

    True enough -- renaming classes which do not add any new operations
is no
    problem.  But I hope you're not arguing that making it more
difficult to
    rename the rest of the classes is not that bad.  Moving operations
around
    a class hierarchy is critical to deriving appropriate protocols.

Renaming classes, whether they add new operations or not, causes no
problems with this conc-name convention.  But renaming classes can cause
lots of other problems.  What about all the defmeth (or defmethod or
whatever) forms which mention the name of that class?  Some programming
environments are able to find all those method definitions and update
them, but in other environments the progarmmer will have to do a lot of
work to properly update each place which mentioned the name of the
class.

I also don't see what moving methods around in a class lattice has to do
with this conc-name convention.

It seems to me that the problems with both renaming classes and moving
methods are problems with having the environment understand what you are
doing.  The environment must have some knowledge of what classes and
methods really are.  I can't resist saying that the best way for the
environment to represent this meta-level information is to have the
classes and methods themselves be objects as they are in CommonLoops.

∂30-Jul-86  1719	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Re: accessor functions   
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 30 Jul 86  17:19:28 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 52913; Wed 30-Jul-86 00:15:35 EDT
Date: Wed, 30 Jul 86 00:15 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: accessor functions
To: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: <8607241925.AA03667@hplsny>
Message-ID: <860730001526.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 24 Jul 86  12:25:12 PDT
    From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>

    Also, do you use the CLASS- prefix for ALL operations defined
    on a CLASS, or just the instance variable accessor functions?
    I notice in the SHIP example in the December 85 New Flavors paper that
    the function SHIP-MASS is defined to read the MASS instance variable,
    but the function SPEED (rather than SHIP-SPEED) is defined to
    compute the speed.  Is MASS less generic than SPEED?

In this particular example, yes, MASS is less generic than SPEED.  All
this shows is that it's a poorly-crafted example, and all that shows is
that it is difficult to concoct a ten-line example of how to use object-
oriented programming, because object-oriented programming is useful
primarily for organizing very large programs, and in very small programs
just seems to get in the way.  It's difficult to give a good explanation
of how one organizes a taxonomy of classes and protocols when the world
contains nothing but one class of ships and one class of (massless)
comets.  The example was really only intended to convey syntax to those
who already knew how to use object-oriented programming.

If you want to know why the default for :CONC-NAME in DEFFLAVOR is what
it is, the easy answer is that I assumed the designers of Common Lisp
DEFSTRUCT knew what they were doing so I did the same thing.  A less
flip answer is that if there is to be a default at all, rather than
requiring the user to specify it explicitly, the safest default is the
name of the flavor.  This is based on the principle that defaults should
serve the needs of less sophisticated users, who are least well equipped
to choose a value for the option.  In this case I am thinking of the
user with a small program, with only a single implementation of each
protocol, and probably lacking a clear articulation of the distinction
between protocols and implementations of protocols.

∂30-Jul-86  1915	FAHLMAN@C.CS.CMU.EDU 	accessor functions
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86  19:15:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 30 Jul 86 22:15:08-EDT
Date: Wed, 30 Jul 1986  22:15 EDT
Message-ID: <FAHLMAN.12226945037.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   cl-object-oriented-programming@SU-AI.ARPA
Subject: accessor functions
In-reply-to: Msg of 30 Jul 1986  00:15-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


    If you want to know why the default for :CONC-NAME in DEFFLAVOR is what
    it is, the easy answer is that I assumed the designers of Common Lisp
    DEFSTRUCT knew what they were doing so I did the same thing.

A curious assumption.  I've heard rumors that those guys got a lot of
things wrong, and have been fighting about these things ever since.

But seriously, the first time I read the CommonLoops document, and again
when I read the New Flavors document, my immediate reaction was that
given this new type-specialized function-calling syntax, one will seldom
want a conc-name.  We no longer have to say SHIP-MASS, since the version
of MASS that applies to ships can now just be called MASS, and it won't
interfere with SPACESHIP-MASS or REQUIEM-MASS.  I have been meaning to
suggest ever since then that maybe we should change the default for
:CONC-NAME in DEFSTRUCT to be no conc-name (while allowing users to ask
for a conc-name if they want one).

I've stayed out of this debate, since I've got practially no experience
in using object-oriented systems for anything large, so I'm not entitled
to an opinion.  I just wanted to suggest that we shouldn't be bound by
the CONC-NAME rules of Common Lisp and we shouldn't follow them blindly,
since type-specialized functions, if we adopt them, make the
name-conflict game totally different from what it was before.

-- Scott

∂31-Jul-86  0842	CARNESE@SRI-KL.ARPA 	operation naming conventions 
Received: from SRI-KL.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86  08:42:36 PDT
Date: Thu 31 Jul 86 08:40:53-PDT
From: Dan Carnese <CARNESE@SRI-KL.ARPA>
Subject: operation naming conventions
To: cl-object-oriented-programming@SU-AI.ARPA
cc: gregor.pa@XEROX.COM

    From: Gregor Kiczales <Gregor.pa@Xerox.COM>

    Renaming classes, whether they add new operations or not, causes no
    problems with this conc-name convention.  

The convention in question is to prepend the name of the class to the name
of operations associated with it, e.g., window-draw-line.  If we decide to
change the name of class, we must then change the text of all the programs
using operations of the class, e.g., all window-using programs.  If the
name of the operation did not include the name of the class, e.g.,
draw-line, nobody's code would need to change.

                                              But renaming classes can cause
    lots of other problems.  What about all the defmeth (or defmethod or
    whatever) forms which mention the name of that class?  Some programming
    environments are able to find all those method definitions and update
    them, but in other environments the progarmmer will have to do a lot of
    work to properly update each place which mentioned the name of the
    class.

Sure, this can be a problem as well, and better programming environments
can mitigate it.  But I'd rather avoid the problem entirely.

    I also don't see what moving methods around in a class lattice has to do
    with this conc-name convention.

If an operation is moved from one class to another, the convention requires
that its name be changed.  All user programs must then be modified.

    It seems to me that the problems with both renaming classes and moving
    methods are problems with having the environment understand what you are
    doing.  The environment must have some knowledge of what classes and
    methods really are.  I can't resist saying that the best way for the
    environment to represent this meta-level information is to have the
    classes and methods themselves be objects as they are in CommonLoops.

Of course, having classes and methods be objects makes it easier to build
more powerful environments for dealing with them.  But the real problem
here is that of modifying all the programs everywhere that use a protocol.
To fully solve the problem, we would need a Pie-like system incorporating
entire communities (e.g., all Common Lisp users) where new versions with
``incompatible changes'' were distributed with programs that would
automatically rewrite the old code.  A wonderful vision, but ...

-- Dan
-------

∂31-Jul-86  1133	Gregor.pa@Xerox.COM 	Re: operation naming conventions  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 31 Jul 86  11:30:58 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 31 JUL 86 11:31:12 PDT
Date: 31 Jul 86 11:30 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: operation naming conventions
In-reply-to: Dan Carnese <CARNESE@SRI-KL.ARPA>'s message of Thu, 31 Jul
 86 08:40:53 PDT
To: CARNESE@SRI-KL.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA, gregor.pa@Xerox.COM
Message-ID: <860731-113112-1339@Xerox>

    From: Dan Carnese <CARNESE@SRI-KL.ARPA>

    The convention in question is to prepend the name of the class to
    the name of operations associated with it, e.g., window-draw-line.

I thought the convention in question was the one that Moon and I had
been using for naming generic functions.  That convention is NOT "to
prepend the name of the class to the name of operation associated with
it".  That convention IS "to (usually) prepend the name of a protocol to
the name of the operation".

So changing the name of a class has no effect on the name of generic
functions.

I think it is clear that no default value for conc-name is ever going to
be the basis for a really useful convention for naming generic
functions.  That is why I didn't think we were talking about the
*convention* you would get if you just used the default value of
conc-name (whatever it might be) all the time.

∂01-Aug-86  1338	Carnese@SRI-KL.ARPA 	Re: operation naming conventions  
Received: from SRI-KL.ARPA by SAIL.STANFORD.EDU with TCP; 1 Aug 86  13:38:08 PDT
Date: Fri, 1 Aug 86 05:10 PDT
From: Dan Carnese <Carnese@SRI-KL>
Subject: Re: operation naming conventions
To: cl-object-oriented-programming@SU-AI.ARPA
cc: gregor.pa@Xerox.COM
Message-ID: <860801051010.2.CARNESE@FLEA>

        From: Dan Carnese <CARNESE@SRI-KL.ARPA>
    
        The convention in question is to prepend the name of the class to
        the name of operations associated with it, e.g., window-draw-line.
    
    From: Gregor Kiczales <Gregor.pa@Xerox.COM>

    I thought the convention in question was the one that Moon and I had
    been using for naming generic functions.  That convention is NOT "to
    prepend the name of the class to the name of operation associated with
    it".  That convention IS "to (usually) prepend the name of a protocol to
    the name of the operation".

    So changing the name of a class has no effect on the name of generic
    functions.

I guess we're all being pretty sloppy about just what we mean by
"protocol".  An extreme position, which I had implicitly taking in this
discussion, is that whenever you introduce a new operation you are
implicitly defining a new protocol.  Maybe you'll change its specification
later (i.e., a protocol is different from a contract), but in the meantime
another person can add an alternative implementation to what you've done
and have the two coexist.

But even if you don't buy that view, the "protocol-name-prepending"
convention is a bad idea for essentially the same reasons that the
"class-name-prepending" convention is.  All the arguments against the
latter now apply to protocol renaming and moving operations around
protocols.  That's the really important part of experimental system design,
and I don't want that activity to be hampered in any way.

    I think it is clear that no default value for conc-name is ever going to
    be the basis for a really useful convention for naming generic
    functions.  That is why I didn't think we were talking about the
    *convention* you would get if you just used the default value of
    conc-name (whatever it might be) all the time.

I hope it's now clear that I'm claiming that prepending *any* string to a
operation name is a bad idea.

Enough for now.  See you all in Boston.

-- Dan

∂02-Aug-86  1428	DLW@QUABBIN.SCRC.Symbolics.COM 	Re: operation naming conventions 
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 2 Aug 86  14:28:35 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 27133; Sat 2-Aug-86 17:27:41 EDT
Date: Sat, 2 Aug 86 17:30 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: operation naming conventions
To: Carnese@SRI-KL.ARPA, cl-object-oriented-programming@SU-AI.ARPA
cc: gregor.pa@XEROX.ARPA
In-Reply-To: <860801051010.2.CARNESE@FLEA>
Message-ID: <860802173030.0.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Fri, 1 Aug 86 05:10 PDT
    From: Dan Carnese <Carnese@SRI-KL>

	    From: Dan Carnese <CARNESE@SRI-KL.ARPA>
    
	    The convention in question is to prepend the name of the class to
	    the name of operations associated with it, e.g., window-draw-line.
    
	From: Gregor Kiczales <Gregor.pa@Xerox.COM>

	I thought the convention in question was the one that Moon and I had
	been using for naming generic functions.  That convention is NOT "to
	prepend the name of the class to the name of operation associated with
	it".  That convention IS "to (usually) prepend the name of a protocol to
	the name of the operation".

	So changing the name of a class has no effect on the name of generic
	functions.

	I think it is clear that no default value for conc-name is ever going to
	be the basis for a really useful convention for naming generic
	functions.  That is why I didn't think we were talking about the
	*convention* you would get if you just used the default value of
	conc-name (whatever it might be) all the time.

I agree with Gregor on this point.  When you're using object-oriented
programming for its real intended purpose, and therefore there are many
classes that implement a given protocol, then defaulting the conc-name
from the class name is not a good convention.  Moon points out that it
might be reasonable for beginners who are only using one class for a
protocol; I can see this point, but I'm afraid that this isn't good
preparation for such users to learn how to do more sophisticated things
with protocols, so I'm not sure it's a good idea.

    I guess we're all being pretty sloppy about just what we mean by
    "protocol".  

So far, it seems to me that Gregor and Moon and I have been using the
term consistently.

		 An extreme position, which I had implicitly taking in this
    discussion, is that whenever you introduce a new operation you are
    implicitly defining a new protocol.  

I don't understand why you'd say this.  When a new operation is created,
then either it is being added to some existing protocol, or it is part
of a new protocol.

					 Maybe you'll change its specification
    later (i.e., a protocol is different from a contract), but in the meantime
    another person can add an alternative implementation to what you've done
    and have the two coexist.

A protocol isn't very different from a contract; it's a set of contracts,
actually.  Yes, there can be many implementations.  I'm not sure what you'r
getting at.

    But even if you don't buy that view, the "protocol-name-prepending"
    convention is a bad idea for essentially the same reasons that the
    "class-name-prepending" convention is.  All the arguments against the
    latter now apply to protocol renaming and moving operations around
    protocols.  That's the really important part of experimental system design,
    and I don't want that activity to be hampered in any way.

I do not buy this at all.  Changing the name of an operation that's part
of a protocol is like changing the name of any function that's part of
an external interface.  If I advertise that people can call READ-CHAR,
and then change the name to something else, of course all of the callers
must be found and changed.  How could it be otherwise?  This is equally
true whether READ-CHAR is a generic operation of a protocol, or just a
plain old Lisp function.

    I hope it's now clear that I'm claiming that prepending *any* string to a
    operation name is a bad idea.

I do agree that you should be able to rearrange the insides of the
implementation of a class, moving things among the component classes,
without any visible change to the calling modules.  I agree that the
existing conc-name default gets in the way of that, because the names of
the operations are changed when you move the methods around, and you
have to be careful to remember to override the default conc-name, etc.
This is because names of generic operations are part of a protocol,
whereas names of classes are hidden internal implementation details, and
therefore names of classes should not be used to form names of generic
operations.

However, protocol names (if there were such a thing) are completely
different.  They are part of the external interface.  They cannot be
renamed at will, invisibly to the caller; that is logically impossible.
A convention of some sort that involved formation of generic operation
names by concatenating protocol names with other strings does not create
any particular problems; it's just shorthand for writing the whole name
out every time.

∂13-Aug-86  1109	Kahn.pa@Xerox.COM 	Summary of CL OOP Meeting on August 6    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Aug 86  11:09:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 AUG 86 11:08:41 PDT
Date: 13 Aug 86 11:08 PDT
Sender: Kahn.pa@Xerox.COM
Subject: Summary of CL OOP Meeting on August 6
To: CL-Object-Oriented-Programming@su-ai.ARPA
cc: Kahn.pa@Xerox.COM
From: Ken Kahn <Kahn.pa@Xerox.COM>
Message-ID: <860813-110841-3737@Xerox>

On Wednesday afternoon after the Lisp conference there was a meeting of
the Common Lisp object-oriented programming committee.  There were
somewhere between 50 and 100 people there.  A very clear consensus was
reached that we should go with CommonLoops and that the whole community
would be involved in working out the details.  In particular, Symbolics
agreed to work closely with Xerox to iron out the differences between
New Flavors and CommonLoops.  (On Friday they had a day long meeting.) A
draft of a spec was promised by the end of September (the OOPSLA
conference).  In addition, Xerox promised to update Portable CommonLoops
to keep it in accordance with the spec.  It is hoped that a final
version of the spec will be ready by the end of the year.
Representatives from Xerox, Lucid, Symbolics, LMI, HP, Sun, and the
Japanese CommonLisp committee all backed this consensus.



----- ken

∂14-Aug-86  1335	Gregor.pa@Xerox.COM 	Portable CommonLoops Export Status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Aug 86  13:35:28 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 14 AUG 86 10:39:57 PDT
Date: 14 Aug 86 10:04 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Portable CommonLoops Export Status
To: Victor@EPIC.STANFORD.EDU
cc: CommonLoops.pa@Xerox.COM
cc: CL-Object-Oriented-Programming@SU-AI.ARPA
Message-ID: <860814-103957-4564@Xerox>

I apologize for the wide distribution of this message, if you are not
interested in using Portable CommonLoops outside the United States of
America you can ignore this message.

To use PCL outside the USA, you must first send me a "letter of
assurance agreement".  A blank letter of assurance agreement is included
at the end of this message.  You should re-type it on your company (or
university) letterhead and have it signed by someone who has the
authority to sign such things.

After I have received the letter you can take PCL outside the USA, in
accordance with what it says in the letter of assurance agreement.

Gregor

To: Gregor Kiczales
    Xerox Corporation
    3333 Coyote Hill Road
    Palo Alto, CA. 94304
    U.S.A.


                     LETTER OF ASSURANCE AGREEMENT

"This Agreement is subject to United States Export Control Regulations.
Notwithstanding any other provision hereof, (NAME OF COMPANY) will not
export,
directly or indirectly, any U.S. source technical data acquired from
Xerox, or any
products utilizing any such data, to Romania, Libya, Poland, Albania,
Bulgaria,
Czechoslovakia, German Democratic Republic (including East Berlin),
Estonia,
Hungary, Latvia, Lithuania, Mongolian People's Republic, Afghanistan,
People's
Republic of China,  Union of Soviet Socialist Republics, Cuba, North
Korea,
Vietnam, Kampuchea (Cambodia), Laos or to any other country from which
the U.S. Government or any agency therof at the time of export requires
an export license or
other governmental approval, without first obtaining the written consent
to do so
from the Department of Commerce or other agency of the U.S. Government
whenever required by an applicable statute or regulation."



                               Signed:←←←←←←←←←←←←←←←←←←←←←←←←←←←←

                               Title: ←←←←←←←←←←←←←←←←←←←←←←←←←←←←

                               Date: ←←←←←←←←←←←←←←←←←←←←←←←←←←←←←

∂19-Aug-86  1709	Kahn.pa@Xerox.COM 	OOPSLA'86  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 Aug 86  17:09:08 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 AUG 86 16:34:36 PDT
Date: 19 Aug 86 16:34 PDT
Sender: Kahn.pa@Xerox.COM
Subject: OOPSLA'86
To: CL-Object-oriented-programming@su-ai.ARPA
cc: Kahn.pa@Xerox.COM
From: Ken Kahn <Kahn.pa@Xerox.COM>
Message-ID: <860819-163436-1189@Xerox>

For those who want to know more about the OOPSLA'86:

It's the 1986 ACm First Annual Conference on Object-Oriented Programming
Systems, Languages and Applications.  Sept 29 - Oct 2 at the Portland
Marriott, Portland Oregon.  Among much else there are papers about
CommonLoops, Flavors, Common Objects.  There are even CommonLoops and
Flavors tutorials on the 29th.  For more information write

OOPSLA'86
PO Box 3845
Portland Oregon 97208-3845


----- ken kahn

∂02-Sep-86  0948	snyder%hplsny@hplabs.HP.COM 	nested class definitions  
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 2 Sep 86  09:48:35 PDT
Received: from hplsny by hplabs.HP.COM ; Tue, 2 Sep 86 09:46:44 pdt
Received: by hplsny ; Tue, 2 Sep 86 09:47:18 pdt
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
Message-Id: <8609021647.AA27100@hplsny>
Date: Tue, 2 Sep 86  09:47:07 PDT
Subject: nested class definitions
To: cl-object-oriented-programming@su-ai.ARPA
X-Mailer: NMail [$Revision: 2.6 $]

Has anyone thought about nested class definitions (should we support them and
what should they mean)?  Given that Common Lisp is (claimed to be) a lexically
scoped language, we should consider this issue.  The Simula people contend
that lexically scoped classes are useful, both for "privacy" and for
dynamically generated classes (analogous to closures, which are dynamically
generated functions).  An example of the latter is creating a new "token"
class to represent the tokens of one specific "grammar" (by a parser
generator).

If we don't want to tackle this issue now, we should make nested classes
illegal to give us room for future extensions.

  Alan

-------

∂03-Sep-86  1231	Kahn.pa@Xerox.COM 	Re: nested class definitions   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 3 Sep 86  12:31:09 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 03 SEP 86 11:13:41 PDT
Date: 3 Sep 86 10:37 PDT
From: Kahn.pa@Xerox.COM
Subject: Re: nested class definitions
In-reply-to: Alan Snyder <snyder%hplsny@hplabs.HP.COM>'s message of Tue,
 2 Sep 86 09:47:07 PDT
To: snyder%hplsny@hplabs.HP.COM
cc: cl-object-oriented-programming@su-ai.ARPA
Message-ID: <860903-111341-1026@Xerox>

There is a sense in which CommonLoops already addresses the problem of
nested class definitions.  CommonLoops is often presented in terms of
DEFMETH and DEFCLASS (or NDEFSTRUCT) but these are user convenient forms
of primitives which do not require classes and generic functions to have
names.  For example, one can write something like

(let ((c (make 'class ...)))
   (add-method some-discriminator (list c ...) ...)
   <body>)

where in the scope of <body> c is a local class.  Instances of it may be
returned and discrimination upon them works fine.   One issue here is
that an ideal implementation of CommonLoops should garbage collect a
class if the only references to them are from discriminators and super
classes.  The garbage collector should also remove the methods involved.

If this turns out to be a useful style one could package up the above in
some friendly macros.

----- ken

∂03-Sep-86  1427	Masinter.pa@Xerox.COM 	Re: nested class definitions    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 3 Sep 86  14:26:37 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 03 SEP 86 14:04:40 PDT
Date: 3 Sep 86 14:03 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: nested class definitions
In-reply-to: Kahn.pa's message of 3 Sep 86 10:37 PDT
To: Kahn.pa@Xerox.COM
cc: snyder%hplsny@hplabs.HP.COM,
 cl-object-oriented-programming@su-ai.ARPA
Message-ID: <860903-140440-1246@Xerox>

Common Lisp has taken the view that while there are local functions with
FLET /LABELS and local macros with MACROLET, there aren't any local
structures.    Lets suppose we had something like structure-let:

(structure-let (((foo (:type list)) a b c)
		  (baz x y z))
     (setq kk (make-baz ...))
     (baz-x kk)

    ...)

This certainly makes sense for (:type list) because it doesn't entail
any global data-type-space manipulation, but makes less sense for
structures & classes? In a recursive call, are the types the same
because they share names? Or different? 

In

(let ((c (make 'class ...)))
	(add-method ....)

	...)

you clearly have a dynamic scope the class and its methods. However,
most languages that have "local types" use a lexical scope instead. How
can we get lexically scoped classes?


∂03-Sep-86  1929	@WAIKATO.S4CC.SYMBOLICS.COM:KMP@STONY-BROOK.SCRC.Symbolics.COM 	Re: nested class definitions   
Received: from [128.81.51.90] by SAIL.STANFORD.EDU with TCP; 3 Sep 86  19:28:44 PDT
Received: from EMU.SCRC.Symbolics.COM by WAIKATO.S4CC.SYMBOLICS.COM via CHAOS with CHAOS-MAIL id 54894; Wed 3-Sep-86 19:38:43 EDT
Date: Wed, 3 Sep 86 19:01 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Re: nested class definitions
To: Masinter.pa@Xerox.COM, Kahn.pa@Xerox.COM
cc: snyder%hplsny@hplabs.HP.COM,
    cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: <860903-140440-1246@Xerox>
Message-ID: <860903190156.1.KMP@EMU.SCRC.Symbolics.COM>

    Date: 3 Sep 86 14:03 PDT
    From: Masinter.pa@Xerox.COM

    Common Lisp has taken the view that while there are local functions with
    FLET/LABELS and local macros with MACROLET, there aren't any local
    structures. Lets suppose we had something like structure-let ...
    This certainly makes sense for (:type list) because it doesn't entail
    any global data-type-space manipulation, but makes less sense for
    structures & classes? In a recursive call, are the types the same
    because they share names? Or different? ...
    you clearly have a dynamic scope the class and its methods. However,
    most languages that have "local types" use a lexical scope instead. How
    can we get lexically scoped classes?

Part of the issue is that you need to clearly define whether the data
which is locally typed wants to be first-class. That is, does it have
indefinite extent?  If so, then what does it mean for its type to have
been local? Does it mean that there are now no valid operations upon it,
or just that there is some kind of state which various objects might
still be carrying around which allows them to speak to the object even
though no one else can. That is, is its type marker invalidated upon
exit from the valid contour/context, or is the accessibility of the type
in the type lookup table just drastically reduced by exit from the
contour/context in question?

I should note for the record that this issue seems to me to be just like
the question people keep asking about why we have local 
(DECLARE (SPECIAL ...)) and don't insist that things be proclaimed
SPECIAL for all time? I'm not sure I have a good answer to that question
either -- seems me to be mostly a convenience issue.

The impact these convenience things (FLET, LABELS, local SPECIAL
declarations, and now local types) on debugging are potentially severe
and I think they need to be studied carefully so I recommend we go
slowly.  For example, if you declare local types to be invalidated upon
return, you're surely going to accidentally return locally-typed objects
during debugging and they'd have to be pretty well-behaved if you were
going to have a debuggable system. PRINT/READ invertibility is obviously
blown away by such a thing. Also, if the language were defined such that
the compiler were allowed to treat certain types totally lexically, then
you'd potentially get something which had its type compiled away --
which has some potential good effects (speed and space efficiency being
key among them) but you'd risk duplicating the Fortran debuggability
problem where you could lose track of the type of an object or where you
could end up cheating on accesses to typed objects in ways that you
really didn't mean to -- or worse, in ways that you did mean to...

∂13-Oct-86  2309	SMITCHELL@USC-ECL.ARPA 	Mailing list addition
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
-------

∂13-May-87  2117	Gregor.pa@Xerox.COM 	Re: CLX draft 3 revisions    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 May 87  19:49:19 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 13 MAY 87 19:48:07 PDT
Date: 13 May 87 19:47 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: CLX draft 3 revisions 
In-reply-to: Warren Harris <harris%hplwhh@hplabs.HP.COM>'s message of
 Wed, 13 May 87 18:55:35 PDT
To: harris%hplwhh@hplabs.HP.COM
cc: Oren%Tilde%ti-csl.CSNet@relay.cs.net, RWS@ZERMATT.LCS.MIT.EDU,
 cl-windows@SAIL.STANFORD.EDU,
 CL-Object-Oriented-Programming@SAIL.STANFORD.EDU
Message-ID: <870513-194807-3030@Xerox>
Comment: Remailed at SAIL.STANFORD.EDU after delay caused by mailing list error.


Well in fact, many people would say that surely a concept such as
'height' is NOT the same when talking about different sorts of things.

For example:

(height (make-instance 'elm-tree))              ;in FEET

(height (font-ref *default-hardcopy-font* #\a)) ;in INCHES

(height (make-instance 'window))                ;in PIXELS

They are really quite different.


Now some people are willing to overload the single generic function
height to be able to have all these different meanings.

Other consider that bad style, and would have window-height be a
generic-function which returns the height of any kind of window;
hardcopy-height be the generic-function which returns the height of
anything that can be sent to a hardcopy stream etc.

 It is clear that both of these positions are reasonable.  In fact, when
you want to do it one way versus another depends on lots of factors like
the size of the module you are working on.  Whether the symbols in
question will be exported or imported etc.

:accessor-prefix in CLOS is designed to make it easy to program in
either of those styles.

Note that using (:accessor-prefix nil) is the way to get the behavior
you like. 

∂14-May-87  0900	harris%hplwhh@hplabs.HP.COM 	Re: CLX draft 3 revisions 
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 14 May 87  09:00:11 PDT
Received: from hplms1 by hplabs.HP.COM with TCP ; Thu, 14 May 87 08:57:56 pdt
Received: from hplwhh (hplwhh) by hplms1; Thu, 14 May 87 08:57:34 pdt
Return-Path: <harris@hplwhh>
Received: from hplwhh.hpl.hp.com by hplwhh ; Thu, 14 May 87 08:57:17 pdt
Message-Id: <8705141557.AA02962@hplwhh>
To: Gregor.pa@Xerox.COM
Cc: Oren%Tilde%ti-csl.CSNet@relay.cs.net, RWS@ZERMATT.LCS.MIT.EDU,
        cl-windows@SAIL.STANFORD.EDU,
        CL-Object-Oriented-Programming@SAIL.STANFORD.EDU
Subject: Re: CLX draft 3 revisions 
In-Reply-To: Your message of 13 May 87 19:47:00 -0700.
             <870513-194807-3030@Xerox> 
Date: Thu, 14 May 87 08:57:10 PDT
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>

Thanks for your response.  I hadn't thought about accessors like
HEIGHT differing by their units, but differing in concept (e.g. one
application's generic-function DISPLAY which takes a window and
returns its associated display object, and another application's
DISPLAY which takes an object, and a stream and draws the object).  I
didn't really consider the former as requiring different accessors,
but the latter should obviously be separated by packages,
accessor-prefixes or individual names for the two operations.  My gut
feeling was that prefixes shouldn't be used unless needed because they
ruin the genericness of the accessor (why should I have separate
functions for ELM-TREE-HEIGHT, PERSON-HEIGHT and FONT-HEIGHT?).  But
perhaps you're right -- why confuse the user.

Warren

∂14-May-87  0854	cperdue@Sun.COM 	Re: CLX draft 3 revisions   
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 14 May 87  08:54:38 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-3.2)
	id AA09631; Thu, 14 May 87 08:51:07 PDT
Received: from clam.sun.uucp by snail.sun.com (3.2/SMI-3.2)
	id AA28978; Thu, 14 May 87 08:50:41 PDT
Received: by clam.sun.uucp (3.2/SMI-3.0DEV3)
	id AA12964; Thu, 14 May 87 08:55:42 PDT
Date: Thu, 14 May 87 08:55:42 PDT
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8705141555.AA12964@clam.sun.uucp>
To: Gregor.pa@Xerox.COM, harris%hplwhh@hplabs.HP.COM
Subject: Re: CLX draft 3 revisions
Cc: CL-Object-Oriented-Programming@SAIL.STANFORD.EDU,
        Oren%Tilde%ti-csl.CSNet@relay.cs.net, RWS@ZERMATT.LCS.MIT.EDU,
        cl-windows@SAIL.STANFORD.EDU

  Well in fact, many people would say that surely a concept such as
  'height' is NOT the same when talking about different sorts of things.
  
  For example:
  
  (height (make-instance 'elm-tree))              ;in FEET
  
  (height (font-ref *default-hardcopy-font* #\a)) ;in INCHES
  
  (height (make-instance 'window))                ;in PIXELS

Looks more like an issue of units than an issue of datatype to me.

∂14-May-87  1031	CARNESE@SPAR-20.ARPA 	Re: CLX draft 3 revisions   
Received: from SPAR-20.ARPA by SAIL.STANFORD.EDU with TCP; 14 May 87  10:31:05 PDT
Date: Thu 14 May 87 10:21:55-PDT
From: Dan Carnese <CARNESE@SPAR-20.ARPA>
Subject: Re: CLX draft 3 revisions 
To: harris%hplwhh@hplabs.hp.com
cc: Gregor.pa@XEROX.COM, Oren%Tilde%ti-csl.CSNet@RELAY.CS.NET,
    RWS@ZERMATT.LCS.MIT.EDU, cl-windows@SAIL.STANFORD.EDU,
    CL-Object-Oriented-Programming@SAIL.STANFORD.EDU
In-Reply-To: <8705141557.AA02962@hplwhh>
Message-ID: <12302345450.16.CARNESE@SPAR-20.ARPA>


    Date: Thu, 14 May 87 08:57:10 PDT
    From: Warren Harris <harris%hplwhh@hplabs.HP.COM>

    Thanks for your response.  I hadn't thought about accessors like
    HEIGHT differing by their units, but differing in concept (e.g. one
    application's generic-function DISPLAY which takes a window and
    returns its associated display object, and another application's
    DISPLAY which takes an object, and a stream and draws the object).  I
    didn't really consider the former as requiring different accessors,
    but the latter should obviously be separated by packages,
    accessor-prefixes or individual names for the two operations.  My gut
    feeling was that prefixes shouldn't be used unless needed because they
    ruin the genericness of the accessor (why should I have separate
    functions for ELM-TREE-HEIGHT, PERSON-HEIGHT and FONT-HEIGHT?).

The need to distinguish is clear.  The question is which language structure
is appropriate to realize the distinction.  

A number of concepts, such as height and width, can be viewed as "the same"
for a number of different clx objects.  Thus, it makes sense to use one
symbol to denote the concept, and thus to have one function name apply to a
number of different clx classes.  By placing such symbols in the clx
package, different applications are not precluded from using symbols with
the same name, e.g., arboretum:height, to identify different concepts.

A basic problem with function names that include class names, such as
font-height, is that it is bad for extensibility.  When subclasses of the
existing class are defined, e.g., adobe-font, users of those subclasses
will have to remember which ancestor class must be used to construct the
name of the function.  This makes such systems more difficult to learn and
increases the incidence of trivial but annoying programming errors.

A possible reason for retaining class-specific accessor names is to achieve
maximal efficiency.  If that is indeed the case, then both the "generic"
functions and the class-specific functions should be available.

-- Dan
-------

∂14-May-87  1054	Gregor.pa@Xerox.COM 	Re: CLX draft 3 revisions    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 May 87  10:54:47 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 14 MAY 87 10:47:15 PDT
Date: 14 May 87 10:44 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: CLX draft 3 revisions 
In-reply-to: Dan Carnese <CARNESE@SPAR-20.ARPA>'s message of Thu, 14 May
 87 10:21:55 PDT
To: CARNESE@SPAR-20.ARPA
cc: harris%hplwhh@hplabs.hp.com, Gregor.pa@Xerox.COM,
 Oren%Tilde%ti-csl.CSNet@relay.cs.net, RWS@ZERMATT.LCS.MIT.EDU,
 cl-windows@SAIL.STANFORD.EDU,
 CL-Object-Oriented-Programming@SAIL.STANFORD.EDU
Message-ID: <870514-104715-3566@Xerox>

    From: Dan Carnese <CARNESE@SPAR-20.ARPA>
    Subject: Re: CLX draft 3 revisions 

    A basic problem with function names that include class names,
    such as font-height, is that it is bad for extensibility.  When
    subclasses of the existing class are defined, e.g., adobe-font,
    users of those subclasses will have to remember which ancestor
    class must be used to construct the name of the function.  This
    makes such systems more difficult to learn and increases the
    incidence of trivial but annoying programming errors.

Don't think of names like window-height as including the name of a
class.  You should think of these as including the name of a protocol
(eg the window protocol).

Notice that the :accessor-prefix option in CLOS has no default value.
In particular, it doesn't default to the name of the class followed by a
"-".  This was done to explictly avoid any automatic mapping from
class-names to accessor-prefix.

As for packages, they may sometimes be helpful for this problem.  But as
I said in my earlier message, it depends on lots of things, like the
size of the module.  For example, one could imagine a graphics package
which had lots of different kinds of windows and lots of different kinds
of graphics objects.  Within the GRAPHICS package, it might be
appropriate to have 2 generic functions, window-height for all kinds of
windows and graphics-object-height for all kinds of graphics objects.

∂14-May-87  1216	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re: CLX draft 3 revisions  
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 14 May 87  12:16:27 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 81714; Thu 14-May-87 14:29:13 EDT
Date: Thu, 14 May 87 14:28 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: CLX draft 3 revisions 
To: CARNESE@SPAR-20.ARPA, harris%hplwhh@hplabs.hp.com
cc: Gregor.pa@XEROX.COM, Oren%Tilde%ti-csl.CSNet@RELAY.CS.NET, RWS@ZERMATT.LCS.MIT.EDU,
    cl-windows@SAIL.STANFORD.EDU, CL-Object-Oriented-Programming@SAIL.STANFORD.EDU
In-Reply-To: <12302345450.16.CARNESE@SPAR-20.ARPA>
Message-ID: <870514142801.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Line-fold: No

    Date: Thu 14 May 87 10:21:55-PDT
    From: Dan Carnese <CARNESE@SPAR-20.ARPA>

    A basic problem with function names that include class names, such as
    font-height, is that it is bad for extensibility.  When subclasses of the
    existing class are defined, e.g., adobe-font, users of those subclasses
    will have to remember which ancestor class must be used to construct the
    name of the function.  This makes such systems more difficult to learn and
    increases the incidence of trivial but annoying programming errors.

Right.  This is exactly why CLOS does not use the class name as the
accessor prefix.  Instead, the writer of the defclass has to specify the
prefix, and the intention is that the prefix be specified according to
the protocol that the class implements, rather than the name of the
class.

∂14-May-87  1359	CARNESE@SPAR-20.ARPA 	Re: CLX draft 3 revisions   
Received: from SPAR-20.ARPA by SAIL.STANFORD.EDU with TCP; 14 May 87  13:59:08 PDT
Date: Thu 14 May 87 13:45:40-PDT
From: Dan Carnese <CARNESE@SPAR-20.ARPA>
Subject: Re: CLX draft 3 revisions 
To: cl-windows@SAIL.STANFORD.EDU,
    cl-object-oriented-programming@SAIL.STANFORD.EDU
In-Reply-To: <8705140155.AA02460@hplwhh>
Message-ID: <12302382544.16.CARNESE@SPAR-20.ARPA>


    Date: Wed, 13 May 87 18:55:35 PDT
    From: Warren Harris <harris%hplwhh@hplabs.HP.COM>

    > Since you've got:
    >   drawable-depth, drawable-root, drawable-x, drawable-y, drawable-width,
    >   drawable-height, drawable-border-width
    > 
    > How about getting rid of:
    >   window-depth, window-root, window-x, window-y, window-width,
    >   window-height, window-border-width
    > and
    >   pixmap-depth, pixmap-root, pixmap-width, pixmap-height
    > 
    >   -LaMott

    With the advent of generic functions, I don't see why we need to
    prefix these accessors with their types anyway.  Why not just: DEPTH,
    ROOT, X, Y, WIDTH, HEIGHT, and BORDER-WIDTH?  (I know X and Y aren't
    very good function names, so how about LEFT and TOP with slots renamed
    accordingly.)  In the mean time (before generic-functions are
    available), these functions can be built from typecase statements.

    Warren

    P.S.  CLOS committee -- why all this :accessor-prefix stuff?  Since
    methods always do the "right thing" we need no longer resort to clever
    naming schemes in order that our programs do the right thing.  Surely
    a concept such as HEIGHT is the same regardless of whether we're
    talking about windows, fonts, displays, etc.

Two issues are raised here: how should specific pieces of clx functionality
be named and what good are accessor prefixes anyway?  I was addressing the
former, not the latter.  My claim was that for the above-named functions, a
single "X" in the clx package can reasonably represent the functionality of
"drawable-X", "window-X", and "pixmap-X".

As far as the appropriateness of prefixes, I think it's fair to say that
their use is a matter of personal style.  Since many people do find
prefixes useful, it is entirely appropriate to have them be a language
feature.  But I think it's also fair to say that if there were better
integration between the realizations of "class", "package", and "module" in
Common Lisp, the use of prefixes would be far less widespread.  I'm sure
this will happen -- it just hasn't happened yet.
-------

∂14-May-87  1439	schultz@nrl-aic.ARPA 	Please remove...  
Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 14 May 87  14:38:55 PDT
Return-Path: <schultz>
Received: Thu, 14 May 87 17:18:56 edt by nrl-aic.ARPA id AA22697
Date: Thu, 14 May 87 17:18:56 edt
From: Alan Schultz <schultz@nrl-aic.ARPA>
Message-Id: <8705142118.AA22697@nrl-aic.ARPA>
To: CARNESE@SPAR-20.ARPA
Cc: cl-windows@SAIL.STANFORD.EDU,
        cl-object-oriented-programming@SAIL.STANFORD.EDU
In-Reply-To: Dan Carnese's message of Thu 14 May 87 13:45:40-PDT <12302382544.16.CARNESE@SPAR-20.ARPA>
Subject: Please remove...

I don't know whose responsible, but I should not be on this mailing list.
Please remove me. (Sorry for sending this to everyone, but I'm not sure
who to tell.) --Alan C. Schultz

∂14-May-87  1633	CARNESE@SPAR-20.ARPA 	Re: [Dan Carnese <CARNESE@SPAR-20.ARPA>: Re: CLX draft 3 revisions  
Received: from SPAR-20.ARPA by SAIL.STANFORD.EDU with TCP; 14 May 87  16:33:14 PDT
Date: Thu 14 May 87 16:27:40-PDT
From: Dan Carnese <CARNESE@SPAR-20.ARPA>
Subject: Re: [Dan Carnese <CARNESE@SPAR-20.ARPA>: Re: CLX draft 3 revisions
To: Masinter.pa@XEROX.COM
cc: cl-object-oriented-programming@SAIL.STANFORD.EDU
In-Reply-To: <870514-150453-4017@Xerox>
Message-ID: <12302412033.16.CARNESE@SPAR-20.ARPA>

    Date: 14 May 87 15:04 PDT
    From: Masinter.pa@Xerox.COM

    >As far as the appropriateness of prefixes, I think it's fair to say that
    >their use is a matter of personal style.  Since many people do find
    >prefixes useful, it is entirely appropriate to have them be a language
    >feature.  But I think it's also fair to say that if there were better
    >integration between the realizations of "class", "package", and "module" in
    >Common Lisp, the use of prefixes would be far less widespread.  I'm sure
    >this will happen -- it just hasn't happened yet.


    What did you have in mind?

Well, as an extremely naive approach, one could define a package for each
class which used the packages for each ancestor class.  Then whenever you
loaded a class definition, you automatically used the associated package.
The name of each generic function would be interned in (and by default,
exported from) the package associated with the most general class for which
it is defined.

Notice that this would require that for any individual name, a single most
general class must exist.  Thus, if we had a:height and b:height, where a
and b are unrelated classes, we could not define c as a subclass of a and b
without defining a new common superclass of a and b with which a unique
"height" would be associated.  This may be a good idea, but may also be a
bit draconian for some people's taste.  It also requires a symbol-merging
capability in the package system, so the old a:height and b:height symbols
would forward to the symbol associated with the new common superclass.

Futthermore, there probably needs to be at least three kinds of symbols in
these class-associated packages.  One of these would be for the "end-users"
of the class, one for the implementers of subclasses which make some
assumptions about the implementation (e.g., the semantics of some but not
all instance variables), and one which is private to the implementer of the
class itself.

With regard to modules, it seems clear that each module ought to be
associated with a package, which used and exported some or (by default) all
of the externals of submodules.  This might justify each class definition
and some or all of the generic functions of the class being implicitly
treated as a module.  Of course, this a different notion of module that is
not compatible with the current Common Lisp "compilation unit" idea.

There are certainly more issues that need to be raised and sorted out.  But
it seems likely that some reasonable proposal could be made.
-------

∂20-May-87  0228	@RELAY.CS.NET:jkim@csd.kaist.ac.kr 	Put me on the CL-Object-Oriented-Programming Mailing List  
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 20 May 87  02:28:08 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac25047; 20 May 87 4:50 EDT
Received: from sorak.kaist.ac.kr by RELAY.CS.NET id ab22440; 20 May 87 4:44 EDT
Received: by sorak.kaist.ac.kr (5.51/4.12)
	id AA26722; Wed, 20 May 87 09:10:27+0900
Return-Path: <jkim@csd.kaist.ac.kr>
Received: by csd.kaist.ac.kr (4.12/08-14-86)
	id AA25075; Wed, 20 May 87 10:06:28+0900
Date: Wed, 20 May 87 10:06:28+0900
From: "Jin H. Kim" <jkim%csd.kaist.ac.kr@RELAY.CS.NET>
Message-Id: <8705200106.AA25075@csd.kaist.ac.kr>
To: cl-object-oriented-programming@SAIL.STANFORD.EDU
Subject: Put me on the CL-Object-Oriented-Programming Mailing List

I just learned that this kind of mailing group is out there.
Please put me on the list.
Thanks,

Jin H. Kim
Computer Science Department
Korea Advanced Institute of Science and Technology
Seoul, Korea

jkim@csd.kaist.ac.kr

∂27-May-87  1119	RPG  	OOPSLA Lisp and Object-Oriented Programming Workshop  
To:   cl-object-oriented-programming@SAIL.STANFORD.EDU    

There will be a workshop on Lisp and Object-Oriented Programming on Monday
October 5 from 9am until noon at OOPSLA.  The Common Lisp Object System
(CLOS) will be the highlight of the workshop, with presentations about
CLOS by the designers along with critiques, analyses, and responses to the
Object System, the latter selected based on contributed position papers.

Attendance will be limited to people who know Lisp and are familiar with
existing object-oriented languages.

If you would like to attend, please send me a 1-2 page description of your
position regarding either the Common Lisp Object System or
Lisp/object-oriented programming before August 1; netmail is acceptable.
Invitations will be sent on September 1. Attendance is limited to 35
people.

			Richard P. Gabriel
			Lucid, Inc
			707 Laurel Street
			Menlo Park, CA 94025
			(415)329-8400
			rpg@sail.stanford.edu

∂13-Aug-87  0956	@RELAY.CS.NET:kgk@cs.brown.edu 	CLOS    
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 13 Aug 87  09:56:50 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ag09515; 13 Aug 87 12:30 EDT
Received: from cs.brown.edu by RELAY.CS.NET id bg11618; 13 Aug 87 12:22 EDT
Received: by cs.brown.edu (5.51/1.00)
	id AA23908; Thu, 13 Aug 87 10:39:25 EDT
Date: Thu, 13 Aug 87 10:41:02 EDT
From: kgk%cs.brown.edu@RELAY.CS.NET
Message-Id: <8708131441.AA03679@nancy.cs.brown.edu>
To: cl-object-oriented-programming@SAIL.STANFORD.EDU
Subject: CLOS


I have a question about CLOS and I wonder if you could take the time
to respond:

Is it within the CLOS specification for implementations to

1.  compile slot access into, e.g., array access, and

2.  discriminate generic function calls into the appropriate methods
    at compile time,

or does CLOS require these to be compiled into calls to generic
functions?  Naturally, I assume that the class(es) of the arguments
are declared at compile time, and that there are no ambiguities (i.e.
via inheritance?) that could not be resolved until run-time.

∂14-Aug-87  1055	Moon@STONY-BROOK.SCRC.Symbolics.COM 	CLOS    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 Aug 87  10:55:20 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 213750; Fri 14-Aug-87 13:35:32 EDT
Date: Fri, 14 Aug 87 13:35 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: CLOS
To: kgk%cs.brown.edu@RELAY.CS.NET
cc: cl-object-oriented-programming@SAIL.STANFORD.EDU
In-Reply-To: <8708131441.AA03679@nancy.cs.brown.edu>
Message-ID: <870814133523.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 13 Aug 87 10:41:02 EDT
    From: kgk%cs.brown.edu@RELAY.CS.NET

    I have a question about CLOS and I wonder if you could take the time
    to respond:

    Is it within the CLOS specification for implementations to

    1.  compile slot access into, e.g., array access, and

    2.  discriminate generic function calls into the appropriate methods
	at compile time,

    or does CLOS require these to be compiled into calls to generic
    functions?  Naturally, I assume that the class(es) of the arguments
    are declared at compile time, and that there are no ambiguities (i.e.
    via inheritance?) that could not be resolved until run-time.

It's obvious that these optimizations aren't permissible if the classes
or methods involved can be redefined at run time.  It's less obvious,
but still true, that these optimizations aren't permissible if new
subclasses and/or new methods can be created at run time.  The Common
Lisp type declaration never declares the exact type of an object; it
declares that the object is of that type or some subtype.  You can read
`class' for `type' here.  The same is true of CLOS method parameter
specializers.  Thus at compile time one can never be sure of the exact
class of a value.

However, it has been proposed to add a feature by which the programmer
can declare that nothing will be added or changed at run time, and then
to compile the entire program as a unit.  In that case, the compiler
knows the complete set of methods for a generic function and the
complete set of subclasses of a class, and optimizations such as the
ones you suggest would then become permissible.  I imagine that by the
time the CLOS specification is finished and approved, there will be a
feature like this in it.  Currently, it's not in the document because
the people working out a detailed proposal haven't finished yet.

There is another answer to your question which is also worth repeating.
Note that you have used the ill-defined (in Common Lisp) concepts
"compile" and "compile time".  It is certainly permissible for
implementations to make the compiler optimizations you have suggested
provided the user never sees incorrect behavior as a result.  One way to
do this is to notice when something has been added or redefined that
makes the optimization impermissible, and automatically recompile the
optimized code so it will work properly in the new environment.  Another
way is to compile several copies of a method, each to be used in
different circumstances.  For example, one might compile a separate copy
of a method for each subclass of the class used as a parameter
specializer.  The CLOS specification doesn't need to discuss these
optimization opportunities, since they are purely implementation issues
(I'm not sure that is actually true; the presence of these optimizations
may turn out to be visible at the metaclass level if we are not
careful.)

∂14-Aug-87  1201	Kahn.pa@Xerox.COM 	Re: CLOS   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Aug 87  12:01:09 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 14 AUG 87 11:59:46 PDT
Date: Fri, 14 Aug 87 11:59:18 PDT
From: Ken Kahn <Kahn.pa@Xerox.COM>
Subject: Re: CLOS
In-Reply-To: <870814133523.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: kgk%cs.brown.edu@RELAY.CS.NET,
 cl-object-oriented-programming@SAIL.STANFORD.EDU
Message-ID: <870814-115946-3737@Xerox>

>   However, it has been proposed to add a feature by which the
programmer
>   can declare that nothing will be added or changed at run time, and
then
>   to compile the entire program as a unit.  In that case, the compiler
>   knows the complete set of methods for a generic function and the
>   complete set of subclasses of a class, and optimizations such as the
>   ones you suggest would then become permissible.  I imagine that by
the
>   time the CLOS specification is finished and approved, there will be
a
>   feature like this in it.  Currently, it's not in the document
because
>   the people working out a detailed proposal haven't finished yet.

I had always imagined that one could defined metaclasses which compiled
slot access as an array access.  These metaclasses would not allow
subclassing for its instances.  Or they would recompile or etc. Probably
something like this could be done by defining a new generic function
class which compiled method lookup specially and refused to add new
methods.

The point is to leave it up to the meta object protocol and not treat
the entire program as a unit.  Some parts of a program could use such
metaclasses and other parts remain unoptimized.


References
	Moon@STONY-BROOK.SCRC.Symbolics.COM's message of Fri, 14 Aug 87
13:35:00 EDT -- CLOS

∂14-Aug-87  1335	FAHLMAN@C.CS.CMU.EDU 	CLOS    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 87  13:35:34 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 14 Aug 87 16:35:19-EDT
Date: Fri, 14 Aug 1987  16:35 EDT
Message-ID: <FAHLMAN.12326497896.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Ken Kahn <Kahn.pa@XEROX.COM>
Cc:   cl-object-oriented-programming@SAIL.STANFORD.EDU
Subject: CLOS
In-reply-to: Msg of 14 Aug 1987  14:59-EDT from Ken Kahn <Kahn.pa at Xerox.COM>


I haven't thought this through, but I wonder if creating a new
tensely-compiling meta-class is really the right move.  What seems
better to me is a declaration of some sort that tells the compiler, "I'm
finihsed with changes now, the program is finished, now compile it for
maximum performance."  I'd rather not have to go through the code and
change all my defclasses.  And I bet that a lot of users would like to
be able to do this without having to know anything at all about
metaclass hackery.  (Of course, if what they need to do can be boiled
down into some very simple, universally applicable formula, then it's
not a problem -- the still don't need to understand metaclasses, even
though they might have to youch them with the proverbial ten-foot pole.)

-- Scott

∂14-Aug-87  1407	Kahn.pa@Xerox.COM 	Re: CLOS   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Aug 87  14:07:48 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 14 AUG 87 14:07:20 PDT
Date: Fri, 14 Aug 87 14:06:57 PDT
From: Ken Kahn <Kahn.pa@Xerox.COM>
Subject: Re: CLOS
In-Reply-To: <FAHLMAN.12326497896.BABYL@C.CS.CMU.EDU>
To: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
cc: cl-object-oriented-programming@SAIL.STANFORD.EDU
Message-ID: <870814-140720-3949@Xerox>

>   I'd rather not have to go through the code and
>   change all my defclasses.

My point is that it may be very important to change just SOME of the
defclasses to use a different metaclass.  If one wanted to change the
metaclass for an entire file I guess you could suround the entire source
with a macrolet that redefined defclass.

Users need only understand that there is a set of metaclasses which make
different performance tradeoffs some of which interfere with incremental
compilation or extension. 

References
	FAHLMAN@C.CS.CMU.EDU's message of Fri, 14 Aug 87 16:35:00 EDT -- CLOS

∂14-Aug-87  1659	FAHLMAN@C.CS.CMU.EDU 	CLOS    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 87  16:59:33 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 14 Aug 87 19:59:20-EDT
Date: Fri, 14 Aug 1987  19:59 EDT
Message-ID: <FAHLMAN.12326535039.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Ken Kahn <Kahn.pa@XEROX.COM>
Cc:   cl-object-oriented-programming@SAIL.STANFORD.EDU
Subject: CLOS
In-reply-to: Msg of 14 Aug 1987  17:06-EDT from Ken Kahn <Kahn.pa at Xerox.COM>


    >   I'd rather not have to go through the code and
    >   change all my defclasses.

    My point is that it may be very important to change just SOME of the
    defclasses to use a different metaclass.  If one wanted to change the
    metaclass for an entire file I guess you could suround the entire source
    with a macrolet that redefined defclass.

Sure, sometimes you need this selectivity, and your metaclass solution
sounds like the right thing.  But sometimes you just want to go from
development mode to tense mode with as little hassle as possible, and
the right thing is to provide the user with a big switch he can throw at
compile-time.

Wrapping the universe in a big macrolet is conceptually clean, but
not a viable solution in most implementations -- readers get unhappy, or
at least rather inefficient, when you ask them to suck down a single
form of many magabytes.  A declaration could have the same effect
without straining the reader.

-- Scott

∂18-Aug-87  1341	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: CLOS
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 18 Aug 87  13:33:45 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 215815; Tue 18-Aug-87 16:34:16 EDT
Date: Tue, 18 Aug 87 16:33 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: CLOS
To: Ken Kahn <Kahn.pa@Xerox.COM>
cc: kgk%cs.brown.edu@RELAY.CS.NET, cl-object-oriented-programming@SAIL.STANFORD.EDU
In-Reply-To: <870814-115946-3737@Xerox>
Message-ID: <870818163347.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: Fri, 14 Aug 87 11:59:18 PDT
    From: Ken Kahn <Kahn.pa@Xerox.COM>

	However, it has been proposed to add a feature by which the
	programmer can declare that nothing will be added or changed at
	run time, and then to compile the entire program as a unit.

    The point is to leave it up to the meta object protocol and not treat
    the entire program as a unit.  Some parts of a program could use such
    metaclasses and other parts remain unoptimized.

I was oversimplifying for the sake of brevity when I referred to the
entire program.  Of course one can really apply this optimization to
just some of the classes in a program.

I don't think I really care whether the programmer's declaration that
flexibility should be sacrificed for performance is implemented by
metaclasses or by some other mechanism.  Doing it with metaclasses
seems baroque and cumbersome to me, but as long as it's only a
question of implementation and doesn't affect the language, I really
don't care.

∂18-Mar-88  2359	CL-Object-Oriented-Programming-mailer 	Proposed Wording Change to the Error Terminology   
Received: from elroy.Jpl.Nasa.Gov by SAIL.Stanford.EDU with TCP; 18 Mar 88  23:58:11 PST
Received: by elroy.Jpl.Nasa.Gov (4.0/SMI-3.2+DXR)
	id AA04646; Fri, 18 Mar 88 19:34:41 PST
Received: by grian.cps.com (3.2/SMI-3.2)
	id AA06620; Fri, 18 Mar 88 18:34:27 PST
To: cps-common-object
Path: grian!uucp
From: Dick Gabriel <grian!elroy!RPG%SAIL.Stanford.EDU@elroy.Jpl.Nasa.Gov>
Newsgroups: cps.common.object
Subject: Proposed Wording Change to the Error Terminology
Message-Id: <451@grian.UUCP>
Date: 19 Mar 88 02:34:24 GMT
Sender: grian!uucp@elroy.Jpl.Nasa.Gov
Lines: 33



At the x3j13 meeting this week there was some negative comments
about the definition of ``undefined.'' The following is an attempt
to address those criticisms. The last bullet is the part in question:

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

``When situation $S$ occurs, the results are undefined.''

This terminology has the following meaning:

\beginlist

\item{\bull} If this situation occurs, the results are unpredictable.  The
results may range from harmless to fatal to the running system.

\item{\bull} No valid program should cause this situation to happen.

\item{\bull} Implementations are allowed to detect this situation and
signal an error, but no implementation is required to detect the
situation.

\item{\bull} No implementation is allowed to extend the semantics of the
\OS\ to this situation; the effects of the situation may be described
or specified by the implementors, but the effects may not be described
as an extension to the \OS\.

\endlist

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

			-rpg-

∂19-Mar-88  1156	CL-Object-Oriented-Programming-mailer 	Proposed Wording Change to the Error Terminology   
Received: from elroy.Jpl.Nasa.Gov by SAIL.Stanford.EDU with TCP; 19 Mar 88  11:56:06 PST
Received: by elroy.Jpl.Nasa.Gov (4.0/SMI-3.2+DXR)
	id AA06482; Sat, 19 Mar 88 02:33:29 PST
Received: by grian.cps.com (3.2/SMI-3.2)
	id AA07564; Sat, 19 Mar 88 01:30:11 PST
To: cps-common-object
Path: grian!uucp
From: Dick Gabriel <grian!elroy!grian!elroy!RPG%SAIL.Stanford.EDU@elroy.Jpl.Nasa.Gov>
Newsgroups: cps.common.object
Subject: Proposed Wording Change to the Error Terminology
Message-Id: <452@grian.UUCP>
Date: 19 Mar 88 09:30:09 GMT
Sender: grian!uucp@elroy.Jpl.Nasa.Gov
Lines: 34




At the x3j13 meeting this week there was some negative comments
about the definition of ``undefined.'' The following is an attempt
to address those criticisms. The last bullet is the part in question:

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

``When situation $S$ occurs, the results are undefined.''

This terminology has the following meaning:

\beginlist

\item{\bull} If this situation occurs, the results are unpredictable.  The
results may range from harmless to fatal to the running system.

\item{\bull} No valid program should cause this situation to happen.

\item{\bull} Implementations are allowed to detect this situation and
signal an error, but no implementation is required to detect the
situation.

\item{\bull} No implementation is allowed to extend the semantics of the
\OS\ to this situation; the effects of the situation may be described
or specified by the implementors, but the effects may not be described
as an extension to the \OS\.

\endlist

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

			-rpg-

∂25-May-88  1648	CL-Object-Oriented-Programming-mailer 	Some comments on ch.2.    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 25 May 88  16:47:46 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
	id AA08222; Wed, 25 May 88 14:32:47 PDT
Date: Wed, 25 May 88 14:32:47 PDT
Message-Id: <8805252132.AA08222@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
To: cl-object-oriented-programming@sail.stanford.edu
Subject: Some comments on ch.2.

Issues surrounding Symbol-Macrolet

- Incompatible Language Change

	Without symbol-macrolet in the language, it's a true statement that a
	symbol used as an s-expression in Common Lisp represents either a
	lexical variable or a dynamic one, but nothing else.  (defconstant's
	count as dynamic variables about which some additional information
	happens to be available.  But that's not the point...)  With
	symbol-macrolet, that statement no longer holds:  a harmless-looking
	symbol may be "macro-defined" to be an arbitrary operation, full of
	evil side-effects, and potentially side-affectable by anything else.

	This means that macros (or other code-walkers) which think they know
	how programs work can get fooled, because now symbols standing as
	s-expressions can represent arbitrary computations.  This means that
	any code-walker which attempts to schedule side-effects cleverly may
	(probably will) be fooled, since what was previously a variable, only
	affectable by SETQ, and with no side-effects of its own, may now be
	vulnerable to arbitrary side effects, and may in fact cause side
	effects of its own.

	A common "clever" technique is to generate a LET form which binds the
	apparent arguments of a macro to gensym'd variables, EXCEPT that
	arguments which are variables already are not rebound, for efficiency
	considerations.  These kinds of optimizations can now fail
	catastrophically if symbols no longer exclusively represent variables.

	SETQ forms can also admit new side-effects, and/or can be affected by
	side-effects in an opaque manner.  These will be even more subtle to
	locate.

	There's a sort of counter-argument that says that you can always use
	LET to clean up side-effect ordering.  Then (1) with a SSC that
	shouldn't cost you anything, and (2) nobody said that eliding the LET
	for variables was, in fact, legal.  (1) sort of assumes that either
	you have a SSC, or you aren't very serious about efficiency, and so
	clever macros aren't an issue.  (2) says that Common Lisp is not a
	very safe place in which to write programs -- you need a written
	guarantee in order to make even the most fundamental assumptions.

- Symbol-Macrolet should at least be a special form.

	Therefore, symbol-macrolet should be a special form, rather than a
	macro, and should cause changes to the environment.  Complex macros
	which accept an &environment argument could then use the
	symbol-macrolet environment information to determine whether a given
	symbol represents a variable or some other (arbitrary) form.

	Also, if one wishes to make generalized variables look like regular
	variables, then debugger support for this fairy tale is presumably
	desirable.  That support will be easier to come by if symbol-macrolet
	is considered a special form.

- Who needs it, anyway?

	with-accessors and with-slots could just as easily use regular
	macrolet to define normal local macros which happen to accept no
	arguments.  Then one would write:

	(setf (x) (* (rho) (cos (theta))))

	instead of (setq x (* rho (cos theta))).  Is it really such a big
	effort to type the extra parens that it's worth screwing around with
	some fundamental language assumptions?

	Also, readmacros should be a reasonable alternative for the with-slots
	and with-accessors uses planned for symbol-macrolet.

- It shouldn't be part of CLOS

	Symbol-macrolet represents a change to Common Lisp, not an extension
	which is part of CLOS.  While admittedly the CLOS spec. calls for
	other changes to the underlying language, this one seems to have the
	least to do with CLOS per se.

∂25-May-88  1818	CL-Object-Oriented-Programming-mailer 	Re:  Symbol-Macrolet 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 25 May 88  18:18:02 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA00012; Wed, 25 May 88 18:17:09 PDT
Received: from clam.sun.com by snail.sun.com (4.0/SMI-3.2)
	id AA02995; Wed, 25 May 88 18:14:32 PDT
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA23344; Wed, 25 May 88 18:19:33 PDT
Date: Wed, 25 May 88 18:19:33 PDT
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8805260119.AA23344@clam.sun.com>
To: cl-object-oriented-programming@sail.stanford.edu,
        piazza%lisp.DEC@decwrl.dec.com
Subject: Re:  Symbol-Macrolet

> Issues surrounding Symbol-Macrolet
> 
> - Incompatible Language Change
> 
Granted that symbol-macrolet affects the meaning of symbols
in expressions generally, and code walkers in particular.  Code
walkers will indeed have to be modified to handle symbol macros.

The specter of misuse of of symbol-macros is a red herring.  Lisp
already has plenty of power that can be misused to make programs
confusing or worse.  The SETF concept and even the concept of
macros provide this level of power.

The concern about Common Lisp not being a very safe place to write
programs boils down to the fact that macros that analyze their bodies
as Lisp code will need to be modified to expand any possible symbol-macros.

> - Symbol-Macrolet should at least be a special form.
> 
This does seem necessary.

> - It shouldn't be part of CLOS
>
Yes, I thought it was going to be proposed as an independent change
to Common Lisp which could then be used to support with-slots.

> - Who needs it, anyway?
>
The inventors of Flavors, of CLOS, and of CommonObjects all considered
the syntactic convenience important to their users.  I was privy to
the discussions and thinking that went into a predecessor of CommonObjects
and I know that this syntactic convenience was considered important.
SmallTalk also makes instance variables and local variables syntactically
the same.

To me, symbol-macros are an exciting development.  In my experience
software writers almost always avoid making interfaces with a function
and a "setf" for it unless the function takes at least one argument,
even though this supports extra bookkeeping that may be desirable, where
just using a variable does not.  With symbol-macros it will be possible
to use the variable notation that people like and get the abstraction
that we get from functional interfaces.

There are other things that behave like variables, but
aren't quite, that would be supported by symbol-macros.  In other
words, I see valid and important enhancements to Common Lisp that
will be opened up by symbol-macros, and I'm glad that they are
being proposed rather than just a special case for CLOS.
Even a special case for CLOS would be a change to the language,
and symbol-macros provide generality.

∂26-May-88  0700	CL-Object-Oriented-Programming-mailer 	Symbol-Macrolet 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 26 May 88  07:00:48 PDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Thu, 26 May 88 09:58:49 EDT
Received: by kali.think.com; Thu, 26 May 88 09:58:44 EDT
Date: Thu, 26 May 88 09:58:44 EDT
From: gls@Think.COM
Message-Id: <8805261358.AA13459@kali.think.com>
To: cperdue@sun.com
Cc: cl-object-oriented-programming@sail.stanford.edu,
        piazza%lisp.DEC@decwrl.dec.com
In-Reply-To: Cris Perdue's message of Wed, 25 May 88 18:19:33 PDT <8805260119.AA23344@clam.sun.com>
Subject:  Symbol-Macrolet

   Date: Wed, 25 May 88 18:19:33 PDT
   From: cperdue@sun.com (Cris Perdue)

   > Issues surrounding Symbol-Macrolet
   > 
   > - Incompatible Language Change
   > 
   Granted that symbol-macrolet affects the meaning of symbols
   in expressions generally, and code walkers in particular.  Code
   walkers will indeed have to be modified to handle symbol macros.

   The specter of misuse of of symbol-macros is a red herring.  Lisp
   already has plenty of power that can be misused to make programs
   confusing or worse.  The SETF concept and even the concept of
   macros provide this level of power.
   ...

I have mixed feelings about SYMBOL-MACROLET myself.  This prompts me
to propose NUMBER-MACROLET for the sake of contrast.

	(number-macrolet ((6 '(a b c))
			  (3.14159 2.71828))
	  (list 6 '6 3.14159 '3.14159))

	=> ((a b c) 6 2.71828 3.14159)

This would certainly encourage explicit quotation wherever appropriate
(which others have already advocated), and would provide a counterexample
to the adage "There's safety in numbers."

--Quux

∂26-May-88  0830	CL-Object-Oriented-Programming-mailer 	Symbol Macrolet 
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 26 May 88  08:29:47 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 26 May 88 11:30:24 EDT
To: cl-object-oriented-programming@sail.stanford.edu
Subject: Symbol Macrolet
Date: Thu, 26 May 88 11:30:13 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU


I haven't seen the full Symbol-Macrolet proposal, so I can't comment on the
details, but I think that we have needed something like this for a long
time.  Lisp is, among other things, a powerful language in which to write
other languages, and the ability to extend its syntax via macros is an
important part of that power.  Unfortunately, this extensible syntax has
only been available at the form level and not at the symbol level.  When
people have felt the need to have symbols that turn into something more
complex, they have had to rely on code-walkers that are external to the
language -- an error prone situation at best.  Symbol macros would fix
that, and if they are lexically scoped they would not be too treacherous in
the hands of a reasonably careful programmer -- at least you could see
locally what symbols you want to handle with care.

It has been suggested that this mechanism puts too much power into the
hands of the Lisp user -- enough power to confuse readers of the code,
whether they be programs or humans.  I feel that Lisp is a language that
has always chosen to give the most powerful tools to the programmer, who
can use that power either for good or evil.  Given the ability in Common
Lisp to modify code on the fly, to pass around function objects containing
shared state, to create macros that perform arbitrary transformations on
chunks of program, and to alter reader syntax beyond all recognition, the
Lisp programmer who chooses to do so already has the power to create
totally impenetrable code.  We don't want to add constructs to the language
that are gratuitously dangerous, but neither do we want to keep useful
tools out of the hands of good programmers just because bad programmers
might get into trouble.

If you want a language that tries to lock up all the sharp objects and
fire-making implements, use Pascal or Ada: the Nerf languages, harmless fun
for children of all ages, and they won't mar the furniiture.

-- Scott

∂26-May-88  0839	CL-Object-Oriented-Programming-mailer 	Re: Symbol-Macrolet  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 26 May 88  08:39:44 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 26 MAY 88 08:37:15 PDT
Date: 26 May 88 08:37 PDT
From: Rabin.pa@Xerox.COM
Subject: Re: Symbol-Macrolet
In-reply-to: gls@Think.COM's message of Thu, 26 May 88 09:58:44 EDT
To: gls@Think.COM
cc: cperdue@sun.com, cl-object-oriented-programming@sail.stanford.edu,
 piazza%lisp.DEC@decwrl.dec.com
Message-ID: <880526-083715-2325@Xerox>

:-)

If NUMBER-MACROLET be upon us, can CHARACTER-MACROLET be far behind?
Of course, we'll need a :test arg to decide whether to ignore bits and font in
recognizing an invocation... which reminds me: does NUMBER-MACROLET compare
using EQL or = ?

Dan Rabin

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



       Workshop for CLOS Users and Implementors

                October 3rd and 4th

                    Xerox PARC

               Palo Alto, California


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

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

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

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

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

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

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

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

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

∂18-Jul-88  1144	CL-Object-Oriented-Programming-mailer 	lambda list congruence    
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 18 Jul 88  11:44:51 PDT
Posted-Date: Mon, 18 Jul 88 11:45:27 PDT
Message-Id: <8807181845.AA26174@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
	id AA26174; Mon, 18 Jul 88 11:45:30 PDT
To: CL-Object-Oriented-Programming@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: lambda list congruence
Date: Mon, 18 Jul 88 11:45:27 PDT
Sender: goldman@vaxa.isi.edu


This question is based on CLOS Specification 88-002 (March 1988)

Congruent Lambda-Lists for ALL methods of a Generic Function (Page 1-29)

The requirements here seem to rule out the following:

I have a generic function, MOUSE-CLICK, and I want to insist that all 
invocations provide the following arguments:
a "window", a "button", a horizontal coordinate, a vertical coordinate, and
a timestamp.

I have two methods, whose lambda lists I would like to write as
m1)  ((w partitioned-inspector) (b (eql *middle-button*)) x y timestamp)
 and
m2) ((w expandable-icon) &rest irrelevant)  (declare (ignore irrelevant))

Apparently, I must write m2 in a more onerous fashion, as
   ((w expandable-icon) b x y tm)  (declare (ignore b x y tm))

It appear I have more flexibility if I am willing to set up my protocol
to use keyword, rather than positional, parameters, but that isn't always
practical, and, besides, I absolutely LOSE the ability to express that the
arguments are REQUIRED (common lisp, unfortunately, has no notion of
a required keyword parameter).  I would have to introduce supplied-p
parameters and test them (in each method) to ensure that no callers 
could get away with omitting some of the arguments.

What I would like is the ability to have the generic function's lambda
list be even MORE RESTRICTIVE than those of (some of) its methods, rather
than the stronger CONGRUENCE requirement stated in the specification.
Another way of stating this is that I would prefer a requirment that
all methods have lambda lists that are compatible with, but not 
necessarily congruent with, that of the generic function.
Where does this break down?  [I would certainly be willing to
always specify my generic function lambda list BEFORE I wrote any
methods with lambda lists that were less restrictive.]

Neil

∂16-Oct-88  1624	CL-Object-Oriented-Programming-mailer 	CLOS Spec Chapters 1 & 2  
Received: from SUMEX-AIM.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Oct 88  16:23:58 PDT
Date: Sun, 16 Oct 88 16:13:01 PDT
From: Tim Koschmann <KOSCHMANN@SUMEX-AIM.Stanford.EDU>
Subject: CLOS Spec Chapters 1 & 2
To: cl-object-oriented-programming@sail.Stanford.EDU
cc: koschmann@SUMEX-AIM.Stanford.EDU
Message-ID: <12438986390.23.KOSCHMANN@SUMEX-AIM.Stanford.EDU>

The first two Chapters of the CLOS spec were to appear in the 
SIGPLAN Notices and in some issue of LASC.  Does anyone know the 
references?

Tim
-------

∂17-Oct-88  1058	CL-Object-Oriented-Programming-mailer 	Re: CLOS Spec Chapters 1 & 2   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Oct 88  10:57:17 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 OCT 88 10:44:52 PDT
Date: Mon, 17 Oct 88 10:31 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: CLOS Spec Chapters 1 & 2
To: Tim Koschmann <KOSCHMANN@SUMEX-AIM.Stanford.EDU>
cc: cl-object-oriented-programming@sail.Stanford.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <12438986390.23.KOSCHMANN@SUMEX-AIM.Stanford.EDU>
Message-ID: <19881017173117.1.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no


Chapters 1 and 2 appeared in SIGPLAN Notices, Volume 23, September 1988.

This came out about 2 weeks ago.
-------

∂14-Nov-88  1156	CL-Object-Oriented-Programming-mailer 	Standard-objects in quoted constants
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 14 Nov 88  11:56:24 PST
Received: from snail.Sun.COM by Sun.COM (4.0/SMI-4.0)
	id AA24065; Mon, 14 Nov 88 11:52:53 PST
Received: from clam.sun.com by snail.Sun.COM (4.0/SMI-4.0)
	id AA18096; Mon, 14 Nov 88 11:54:44 PST
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA18734; Mon, 14 Nov 88 11:54:29 PST
Date: Mon, 14 Nov 88 11:54:29 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8811141954.AA18734@clam.sun.com>
To: cl-object-oriented-programming@sail.stanford.edu
Subject: Standard-objects in quoted constants

The compiler committee has been discussing the following proposal
(among others) on the cl-compiler mailing list.  Treatment of CLOS
objects in quoted constants compiled into files is a nontrivial issue,
and I think it is very important for the CLOS committee to contribute
to this aspect of quoted constants.

Here is the latest version of CONSTANT-COMPILABLE-TYPES:SPECIFY, which
intends to support CLOS objects in file-compiled constants but does
not yet actually do so.  Issues are whether the result of
file-compiling and then loading simply retains slot names and slot
values, or whether there is a protocol to reconstruct a file-compiled
standard-object; how references to classes are resolved, e.g. in some
fashion by name; etc..  

Note that it is likely that we will permit implementations to make the
"basic attributes" of objects of almost all built-in types immutable
when appearing in file-compiled constants.  It is important for us to
hear from you if you want slot values in file-compiled
standard-objects in quoted constants to be mutable.

We are also in the process of requesting information on current
practice from implementors.


Issue:		CONSTANT-COMPILABLE-TYPES
References:	CLtL pp. 56, 77-80, 324
		Issue CONSTANT-MODIFICATION
		Issue CONSTANT-CIRCULAR-COMPILATION
		Issue CONSTANT-ARRAY-ATTRIBUTES
Category:	CLARIFICATION, ADDITION
Edit history:	11/07/88, V1 by Cris Perdue
		11/14/88, V2 by Cris Perdue
Status:		DRAFT

Problem description:

A Common Lisp compiler must record information about constants so that
a "corresponding" constant can be created at load-time.  This is
fundamentally a problem of file-compilation.  For in-core compilation
it appears to be acceptable to use the constants appearing in the
interpreted code exactly as-is, though this is not required.  We
assume that compiled constants may be stored (i.e. on disk) in an
implementation-dependent manner.

Proposal:  CONSTANT-COMPILABLE-TYPES

- References to symbols are left for load-time resolution.
- Aggregate objects are traversed and their components are also
  recorded.
- Numbers and characters, i.e. objects that must be compared with EQL
  rather than EQ, are not aggregate in the sense being discussed here.
  They may appear in constants, and numbers and characters appearing
  in constants have the same requirements on their behavior as numbers
  and characters in any other context.

For aggregate objects there must be some policy on supporting
circular structures and otherwise shared structures.  That is not
specified here.

Each aggregate object has certain Basic Attributes (B.A.'s?)
These are recorded as the constant is compiled and they are also
traversed.

Symbol	     No symbol is a constant in the sense considered here, but
	     references to symbols are permitted in any constant.

Cons	     CAR, CDR

Array	     All elements, fill pointer existence,
	     fill pointer value if present,
	     dimensions, element-type, adjustable-array-p, displaced-to,
	     displaced-index-offset

Structure    Slot values, name of structure type

Hash-table   Keys and values.  The table's test is of course unchanged also.
	     In an EQ hash table, keys that are not EQ must not be
	     coalesced.  In an EQL hash table, keys that are not EQL
	     must not be coalesced (or made EQL).  (These are
	     exceptions to the general rule that constants may be
	     coalesced.)  In short, hash table keys that are initially
	     distinct must remain distinct across the process of
	     file-compilation and loading.

Readtable    Character syntax type for each character in the table;
	     function for each readmacro character, mappings for
	     dispatch macros; terminating or nonterminating for each
	     readmacro.

Pathname     Each pathname component

Package, Stream
             It is an error for a package, stream, or compiled-function
	     to appear ina compiled constant, but the
	     language may be extended in the future to support certain
	     cases.

Random-state
	     Random-states have no basic attributes, and only the
	     "random" operation applies to them (other than PRINT).
	     Let us say that two random-states are functionally
	     equivalent if applying "random" to them repeatedly always
	     produces the same pseudo-random numbers.  Since compiled
	     constants may become immutable, applying "random" to a
	     compiled-constant random-state is an error.  However,
	     all copies made via make-random-state must be
	     functionally equivalent and functionally equivalent to
	     the one that appeared in the source code.

Function     Function constants that are not compiled-functions are
	     permitted in compiled constants.

Generic-function, Method
	     Help is needed from the CLOS committee to determine what
	     to do here.

Standard-object
	     Help is needed from the CLOS committee to determine what
	     do do here.

Rationale:

This proposal appears to reflect user demand and appears not to exceed
the capabilities of most implementations of the language.

Current practice:

This appears to be a reasonable approximation to what is done by the
Franz and Lucid implementations.  The Explorer apparently does not
currently guarantee retention of displaced-to and
displaced-index-offset attributes.

Adoption cost:

Not known.  Probably moderate.  The cost would be to implementors
rather than users since this part of the language is currently
underspecified.

Benefits:

Users would be able to use aggregate objects in constants with
confidence about the behavior of their code.

Conversion cost:

Nil.  Less than the cost of leaving things unspecified.

Esthetics:

Since there is no adequate definition at present, a fuller definition
would be more esthetic.

Discussion:

This would subsume isse CONSTANT-ARRAY-ATTRIBUTES if accepted.

∂14-Nov-88  1324	CL-Object-Oriented-Programming-mailer 	Standard-objects in quoted constants
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Nov 88  13:24:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 492231; Mon 14-Nov-88 16:23:48 EST
Date: Mon, 14 Nov 88 16:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Standard-objects in quoted constants
To: Cris Perdue <cperdue@Sun.COM>
cc: cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <8811141954.AA18734@clam.sun.com>
Message-ID: <19881114212330.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 14 Nov 88 11:54:29 PST
    From: cperdue@Sun.COM (Cris Perdue)

    Here is the latest version of CONSTANT-COMPILABLE-TYPES:SPECIFY, which
    intends to support CLOS objects in file-compiled constants but does
    not yet actually do so.  Issues are whether the result of
    file-compiling and then loading simply retains slot names and slot
    values, or whether there is a protocol to reconstruct a file-compiled
    standard-object; 

I think this issue was discussed at length by the CLOS committee a year
or more ago, but I don't have the results of the discussion on hand.
It was not put into 88-002R, being outside the purview of that document
I guess.

This can only be done with a protocol, because only the programmer of
a particular object class knows how to do it correctly.  Not all of the
state of an object is necessarily directly visible as slot values, and
indeed it is generally a violation of abstraction for any outside agent
(which includes the file compiler) to call SLOT-VALUE rather than
interfacing through generic functions.

There should be a generic function of one argument that returns a Lisp
form which, when evaluated, returns an object "equivalent" to the
argument.  You can call it COPY-FOR-COMPILE-FILE if you can't think of a
better name (which should not be hard!).  This generic function ought to
work for built-in and structure types also, since methods might call it
recursively, although in general a method would just return a form and
assume that the file compiler would take care of all the subforms.

I strongly believe that the default method should signal an error,
although I know there are proponents of various default implementations
that they think meet the needs of some fraction of users.  It would
be reasonable to provide one or more of these default implementations
as functions so that it would be easy to write a method that uses a
particular implementation, when you know it's the right one for you.

		     how references to classes are resolved, e.g. in some
    fashion by name; etc..  

In general it would be done by name, but again only the programmer of
a particular object class knows how to do it correctly.

    Note that it is likely that we will permit implementations to make the
    "basic attributes" of objects of almost all built-in types immutable
    when appearing in file-compiled constants.  It is important for us to
    hear from you if you want slot values in file-compiled
    standard-objects in quoted constants to be mutable.

I think only the programmer of a particular object class knows the answer
to this, therefore Common Lisp and CLOS should not impose an answer.

I think I would object to your proposed rules for arrays and hash tables
if I thought about them more, but since that wasn't the subject of this
particular message, and since I don't have time to think about them more
right now, I'll let that go with just the remark that your array rules
may be overdoing it (why preserve adjustableness if they are immutable?
preserving displacedness is likely to cause trouble), and your hash
table key coalescing rules may not be possible to implement if it
implies that keys that start out EQ to other constant references (in the
same file? or what?) must remain so, when those other constant references
are subject to coalescence and may have appeared earlier in the file.

∂14-Nov-88  1401	CL-Object-Oriented-Programming-mailer 	Re:  Standard-objects in quoted constants
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 14 Nov 88  14:01:36 PST
Received: from snail.Sun.COM by Sun.COM (4.0/SMI-4.0)
	id AA27151; Mon, 14 Nov 88 13:58:02 PST
Received: from clam.sun.com by snail.Sun.COM (4.0/SMI-4.0)
	id AA24047; Mon, 14 Nov 88 13:59:07 PST
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA19771; Mon, 14 Nov 88 13:59:11 PST
Date: Mon, 14 Nov 88 13:59:11 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8811142159.AA19771@clam.sun.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Subject: Re:  Standard-objects in quoted constants
Cc: cl-object-oriented-programming@sail.stanford.edu

Thanks to Dave Moon for his comments on CLOS objects in quoted
constants.  From my point of view everything he said is more
than acceptable.  I understand that this issue has been thought
about by various people, and I hope that something in the vein
he talks about will get specified.

His comments on arrays and hash tables are also welcome.  I hope
to build a proposal acceptable to most people and I am specifically
interested in input from language implementors (via the cl-compiler
mailing list).
				-Cris


∂15-Nov-88  2159	CL-Object-Oriented-Programming-mailer 	Standard-objects in quoted constants
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Nov 88  21:52:33 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Tue, 15 Nov 88 21:45:52 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.Dialnet.Symbolics.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 294714; 16 Nov 88 00:50:03 EST
Date: Wed, 16 Nov 88 00:41 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Standard-objects in quoted constants
To: Cris Perdue <cperdue@sun.com>,
        cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <8811141954.AA18734@clam.sun.com>
Message-Id: <19881116054131.8.RWK@F.ILA.Dialnet.Symbolics.COM>

Thanks for doing this Chris, I'm glad you did this exercise.

    Date: Mon, 14 Nov 88 11:54:29 PST
    From: cperdue@Sun.COM (Cris Perdue)
    We are also in the process of requesting information on current
    practice from implementors.

Here is some information about a Lisp which shall remain nameless.

    - References to symbols are left for load-time resolution.

Furthermore:  The symbol is resolved by lookup in its home package.  If
the current package is not the same as the home package, and the symbol
is not EXTERNAL, then an error is signaled.  (I.e. it should have the
same behaviour as print/read).

This is the behaviour in the implementation I am describing, and I also
believe this should be the required behaviour.  I'm sure someone can
state it better than I just did, however.  (I recall Moon doing so in
the past).

    - Aggregate objects are traversed and their components are also
      recorded.

I think this serves as a definition of the term "aggregate objects", and
not as a guiding principle.  For example, it is an arbitrary decision
not to dump symbol's values and plists.

    - Numbers and characters, i.e. objects that must be compared with EQL
      rather than EQ, are not aggregate in the sense being discussed here.
      They may appear in constants, and numbers and characters appearing
      in constants have the same requirements on their behavior as numbers
      and characters in any other context.

EQLness is preserved in the implementation being described, uniformly
among all objects.

    For aggregate objects there must be some policy on supporting
    circular structures and otherwise shared structures.  That is not
    specified here.

Circular structures are fully supported in the list I am describing.  I
do think this should be the standard, but a number of Lisps, including
Symbolics, and I believe TI, would have to be changed, possibly
significantly.  I suspect all would agree it's the right thing, but I
don't know about willingness to comply.

    Each aggregate object has certain Basic Attributes (B.A.'s?)
    These are recorded as the constant is compiled and they are also
    traversed.

    Symbol	     No symbol is a constant in the sense considered here, but
		 references to symbols are permitted in any constant.

How is it not a constant?  (I'm sure this is just a matter of
terminology).  Or do you mean it's not an agregate object (i.e. not
traversed)?  Or that it is not made immutable?  I think we'd all agree
on the latter two questions...

    Array	     All elements, fill pointer existence,
		 fill pointer value if present,
		 dimensions, element-type, adjustable-array-p, displaced-to,
		 displaced-index-offset

All elements up to fill pointer.  A simple array is dumped, of the same
element-type.

The issue here is what is the MEANING of an array CONSTANT with a fill
pointer?  An array CONSTANT is not a dynamic datastructure.  Fill
pointers, adjustable-array-p, displaced-to, etc. are merely artifacts of
how that array of data is CREATED, not how it may be used when viewed as
a constant.  Since correctly-written programs don't bash their
constants, they won't notice if the array has a fill pointer, or is
displaced, or adjustable.  So there's no point in dumping them.

Note that this is the same behaviour as PRINT/READ, with the one
exception of the ARRAY-ELEMENT-TYPE.

    Structure    Slot values, name of structure type

This isn't good enough, but it's OK for a default.  In general, to
handle the full semantics of possible structures, properly handling
circularity, a protocol is needed where first the loader creates an
object of the right size and then passes it off to a named user function
which fills in the object, performing any necessary initialization, such
as registry in a hash table, etc.

    Hash-table   Keys and values.  The table's test is of course unchanged also.
		 In an EQ hash table, keys that are not EQ must not be
		 coalesced.  In an EQL hash table, keys that are not EQL
		 must not be coalesced (or made EQL).  (These are
		 exceptions to the general rule that constants may be
		 coalesced.)  

Er, but what if they were coalesced elsewhere in the program?  How can
you know that now you have to dump a copy?  OK, so you have to maintain
two tables, recording each EQ entry, and the (non-unique) index found
for it.  But if you were expecting it to be EQ to the same EQ constant
elsewhere in the program, you'll be supprised to learn that it's no
longer EQ.  So why bother?  And what about subelements of EQ objects in
EQ hash tables?  If I have ((A)) and the CAR of that list both as keys,
do they have to remain EQ?

I think you're either better off saying no coalescence, or saying that
EQ hash tables do not preserve EQUAL (or whatever coalescense predicate
you choose) entries.

			      In short, hash table keys that are initially
		 distinct must remain distinct across the process of
		 file-compilation and loading.

I like this principle.  I used to be a fan of coalescence, but the
difficulty of unambiguously specifying issues like this has led me to no
longer be a fan.

The mystery lisp does not currently coalesce non-EQ constants.

    Readtable    Character syntax type for each character in the table;
		 function for each readmacro character, mappings for
		 dispatch macros; terminating or nonterminating for each
		 readmacro.

(error "Can't dump readtables yet.")

This sounds right.

    Pathname     Each pathname component

Right.

    Package, Stream
		 It is an error for a package, stream, or compiled-function
		 to appear ina compiled constant, but the
		 language may be extended in the future to support certain
		 cases.

Packages are dumped by name.  It is an error to reference a package
which is not previously defined in the loading environment.

    Random-state
		 Random-states have no basic attributes, and only the
		 "random" operation applies to them (other than PRINT).
		 Let us say that two random-states are functionally
		 equivalent if applying "random" to them repeatedly always
		 produces the same pseudo-random numbers.  Since compiled
		 constants may become immutable, applying "random" to a
		 compiled-constant random-state is an error.  However,
		 all copies made via make-random-state must be
		 functionally equivalent and functionally equivalent to
		 the one that appeared in the source code.

Right.  The point you make about immutability is important, too.

    Function     Function constants that are not compiled-functions are
		 permitted in compiled constants.

Um:

(defun foo (x) #'(lambda () x))
(typep (foo 3) 'compiled-function) => ?

Is this required to return T?  It doesn't on a Symbolics 3650.

The lisp being described does not dump objects of type FUNCTION,
currently.  If it is extended to do so, it will probably dump compiled
functions.


    This appears to be a reasonable approximation to what is done by the
    Franz and Lucid implementations.  The Explorer apparently does not
    currently guarantee retention of displaced-to and
    displaced-index-offset attributes.

The Explorer is correct.  In the Explorer, also, arrays can be displaced
to a physical address, which is obviously an absurd thing to put into a
compiled file.

    Adoption cost:

    Not known.  Probably moderate.  The cost would be to implementors
    rather than users since this part of the language is currently
    underspecified.

I agree the cost is moderate, but there will probably be a cost to
some users as well as implementors.  However, such usage would not have
been portable, and portable usage will now be possible.

    Conversion cost:

    Nil.  Less than the cost of leaving things unspecified.

Nah, we can argue up the cost of specification if we TRY.

∂16-Nov-88  1156	CL-Object-Oriented-Programming-mailer 	Re:  Standard-objects in quoted constants
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 16 Nov 88  11:56:10 PST
Received: from snail.Sun.COM by Sun.COM (4.0/SMI-4.0)
	id AA29391; Wed, 16 Nov 88 11:52:51 PST
Received: from clam.sun.com by snail.Sun.COM (4.0/SMI-4.0)
	id AA06589; Wed, 16 Nov 88 11:55:37 PST
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA02384; Wed, 16 Nov 88 11:56:26 PST
Date: Wed, 16 Nov 88 11:56:26 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8811161956.AA02384@clam.sun.com>
To: RWK@F.ILA.Dialnet.Symbolics.COM,
        cl-object-oriented-programming@sail.stanford.edu
Subject: Re:  Standard-objects in quoted constants

I have replied to Robert's mail via the cl-compiler mailing list.

				-Cris

∂18-Nov-88  1504	CL-Object-Oriented-Programming-mailer 	How to reach Robert Kerns 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 18 Nov 88  15:04:29 PST
Received: from snail.Sun.COM by Sun.COM (4.0/SMI-4.0)
	id AA14311; Fri, 18 Nov 88 15:01:14 PST
Received: from clam.sun.com by snail.Sun.COM (4.0/SMI-4.0)
	id AA29455; Fri, 18 Nov 88 15:04:04 PST
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA00617; Fri, 18 Nov 88 15:04:54 PST
Date: Fri, 18 Nov 88 15:04:54 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8811182304.AA00617@clam.sun.com>
To: cl-object-oriented-programming@sail.stanford.edu
Subject: How to reach Robert Kerns

Can someone please give me a useable email address for
Robert Kerns?  I have rwk@f.ila.dialnet.symbolics.com,
but Sun's mailer, which seems to do real well for most addresses,
tells me "Host unknown".
				-Cris



∂18-Nov-88  1613	CL-Object-Oriented-Programming-mailer 	How to reach Robert Kerns 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Nov 88  16:13:28 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 495066; Fri 18-Nov-88 18:27:25 EST
Date: Fri, 18 Nov 88 18:27 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: How to reach Robert Kerns
To: Cris Perdue <cperdue@Sun.COM>
cc: cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <8811182304.AA00617@clam.sun.com>
Message-ID: <19881118232718.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 18 Nov 88 15:04:54 PST
    From: cperdue@Sun.COM (Cris Perdue)

    Can someone please give me a useable email address for
    Robert Kerns?  I have rwk@f.ila.dialnet.symbolics.com,
    but Sun's mailer, which seems to do real well for most addresses,
    tells me "Host unknown".

That address is correct.  Try using % to indirect through a better
mailer.  For instance,
rwk%f.ila.dialnet.symbolics.com@riverside.scrc.symbolics.com
is likely to work.

You could also try rwk@ai.ai.mit.edu (he has a mailbox there, I
don't know how often he reads it).

Alternatively, try cruising around Boston Harbor in a rubber
raft until you sight Bob's boat.

∂22-Nov-88  1414	CL-Object-Oriented-Programming-mailer 	How to reach Robert Kerns 
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Nov 88  14:13:35 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Tue, 22 Nov 88 14:06:18 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.Dialnet.Symbolics.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 295632; 20 Nov 88 17:40:49 EST
Date: Sun, 20 Nov 88 17:30 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: How to reach Robert Kerns
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>,
        Cris Perdue <cperdue@sun.com>
Cc: cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <19881118232718.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19881120223020.0.RWK@F.ILA.Dialnet.Symbolics.COM>

    Date: Fri, 18 Nov 88 18:27 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    That address is correct.  Try using % to indirect through a better
    mailer.  For instance,
    rwk%f.ila.dialnet.symbolics.com@riverside.scrc.symbolics.com
    is likely to work.

    You could also try rwk@ai.ai.mit.edu (he has a mailbox there, I
    don't know how often he reads it).

That forwards to ILA these days, but it is a convenient address for
those with mailers that haven't QUITE made it into the domain era.
I read it every couple of days or so, unless I'm in some other country.
(Or some other planet, as the case may be).

    Alternatively, try cruising around Boston Harbor in a rubber
    raft until you sight Bob's boat.

Dress warmly, and look closely, because I'm tucked away in a snug corner
of the harbor for the winter!

As a better alternative, may I suggest you look in Aruba or Tahiti?  You
won't find me unless you wait around a few years, but I can guarentee
you a better time than paddling around Boston Harbor this time of year!

∂28-Nov-88  0832	CL-Object-Oriented-Programming-mailer 	Standard-objects in quoted constants
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Nov 88  08:32:36 PST
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Mon, 28 Nov 88 08:25:27 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 296632; 28 Nov 88 11:31:26 EST
Date: Sun, 27 Nov 88 02:20 EST
From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
Subject: Standard-objects in quoted constants
To: cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <19881116054131.8.RWK@F.ILA.Dialnet.Symbolics.COM>
Supersedes: <19881118040034.2.RWK@F.ILA.Dialnet.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-Id: <19881127072018.7.RWK@F.ILA.Dialnet.Symbolics.COM>

    Date: Wed, 16 Nov 88 00:41 EST
    From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>

    Circular structures are fully supported in the list 
                                                   LISP
							I am describing.  I
    do think this should be the standard, but a number of Lisps, including
    Symbolics, and I believe TI, would have to be changed, possibly
    significantly.  I suspect all would agree it's the right thing, but I
    don't know about willingness to comply.
...
    The mystery lisp does not currently coalesce non-EQ constants.

Correction:  I mean to say non-EQL constants.  CL doesn't make any
guarentees anywhere else about preserving EQness; just EQLness.

∂30-Nov-88  1147	CL-Object-Oriented-Programming-mailer 	compile-time side effects 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 30 Nov 88  11:47:38 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
	id AA00817; Wed, 30 Nov 88 12:47:10 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA12993; Wed, 30 Nov 88 12:47:07 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8811301947.AA12993@defun.utah.edu>
Date: Wed, 30 Nov 88 12:47:06 MST
Subject: compile-time side effects
To: cl-object-oriented-programming@sail.stanford.edu

I'm in the process of revising my cl-compiler proposal on compile-time
side effects of defining macros, to include the various CLOS defining
macros.  Unfortunately, I'm not at all sure what the side effects
should be.  Can somebody who really groks CLOS please help me out? 

DEFCLASS: To parallel DEFTYPE and DEFSTRUCT, this should at least make
the class name known as a valid type specifier at compile time (in
case it is referenced in subsequent declarations).  Also to parallel
DEFSTRUCT, it ought to remember the class name so it can be named as a
superclass for a subsequent DEFCLASS in the file.  Does this mean that
it must also construct a real class object at compile time?  Are the
reader, writer, and accessor functions defined at compile time?

DEFGENERIC: I presume that, like DEFUN, this should *not* make the
function defined at compile time.  Is the FBOUNDP test mentioned in
the second paragraph on p 2-26 of the CLOS spec performed at compile
time or load time?  Must the arguments to the :method-combination,
:generic-function-class, and :method-class options, and classes mentioned
in the method-descriptions be defined at compile time?

DEFINE-METHOD-COMBINATION:  My guess is that it is supposed to make the
method combination known to DEFMETHOD at compile time?  

DEFMETHOD: Again, I assume that this behaves like DEFUN and doesn't
make the method defined at compile time.  Is the FBOUNDP test
supposed to happen at runtime or compiletime?  If there is a generic
function with the same name defined in the compile time environment
but whose argument list is not congruent to the method being defined,
is an error signalled at compile time?  Must the method-qualifier and
classes mentioned as specializers in the lambda list be defined at
compile time? 

-Sandra
-------

∂10-Dec-88  1249	CL-Object-Oriented-Programming-mailer 	I still need help with compile-time side-effects   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 10 Dec 88  12:49:43 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
	id AA22295; Sat, 10 Dec 88 13:48:46 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA02145; Sat, 10 Dec 88 13:48:44 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8812102048.AA02145@defun.utah.edu>
Date: Sat, 10 Dec 88 13:48:42 MST
Subject: I still need help with compile-time side-effects
To: cl-object-oriented-programming@sail.stanford.edu

I haven't yet gotten any response to my earlier plea for help about
what the compile-time side-effects of the CLOS defining macros should
be.  I would really like to get a new version of the writeup on issue
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS ready in time for the January
X3J13 meeting (which really means within the next 10 days or so
because of the holidays).  I don't understand the inner workings of
CLOS well enough to feel comfortable with arbitrarily dictating what
this behavior should be myself, and I don't think there are any other
CLOS wizards in the cl-compiler group either. 

So....  Could somebody please volunteer to help out with this issue?
Ignoring the problem won't make it go away....

-Sandra
-------

∂14-Dec-88  0146	CL-Compiler-mailer 	I still need help with compile-time side-effects  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 14 Dec 88  01:46:13 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA07363g; Wed, 14 Dec 88 01:43:21 PST
Received: by bhopal id AA12154g; Wed, 14 Dec 88 01:45:19 PST
Date: Wed, 14 Dec 88 01:45:19 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812140945.AA12154@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-object-oriented-programming@sail.stanford.edu,
        cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Sat, 10 Dec 88 13:48:42 MST <8812102048.AA02145@defun.utah.edu>
Subject: I still need help with compile-time side-effects

re: I haven't yet gotten any response to my earlier plea for help about
    what the compile-time side-effects of the CLOS defining macros should be.

Although I volunteered (at Fairfax) to help out with specifying these
requirements, I find myself so overloaded with "Cleanup" questions and
other X3J13 responsibilities that I have no time to work on this issue
before Spring 1989.  I'm sorry I can't be of more help now.

-- JonL --

∂10-Jul-89  1549	CL-Cleanup-mailer 	SYMBOL-MACROLET 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 Jul 89  15:49:25 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 623104; 10 Jul 89 18:51:10 EDT
Date: Mon, 10 Jul 89 18:50 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SYMBOL-MACROLET
To: goldman@vaxa.isi.edu
cc: cl-cleanup@sail.stanford.edu, cl-object-oriented-programming@sail.stanford.edu
Message-ID: <19890710225046.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

[Common-Lisp removed in favor of more specific mailing lists.]

    Date: Mon, 10 Jul 89 13:49:20 PST
    From: goldman@vaxa.isi.edu
    To: common-lisp@sail.stanford.edu
    Subject: SYMBOL-MACROLET
    Message-Id: <8907102149.AA27155@vaxa.isi.edu>
    
    Is it the case that the expansion code for a symbol-macro, (unlike
    a lexical macro introduced with MACROLET) has not means to obtain
    the current lexical environment?
    neil

It doesn't get to execute code in order to produce the expansion,
so obtaining the environment would be meaningless.  The only question
is, does it get the lexical environment of the binding-point or the
usage-point. I posed a question like the following to several CLOS 
implementors at the last X3J13 meeting.

 (DEFMACRO FOO () 1)
 (SYMBOL-MACROLET ((X (FOO)))
   (MACROLET ((FOO () 2))
     X))

Consensus seems to be that it is currently defined to return 2.

I think some people consider this a feature, though I've not seen a
serious example which shows why. Personally, I think it's a bug.
I'd rather that it return 1.

∂10-Jul-89  1603	CL-Cleanup-mailer 	SYMBOL-MACROLET 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 Jul 89  16:02:54 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 623112; 10 Jul 89 19:04:34 EDT
Date: Mon, 10 Jul 89 19:04 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SYMBOL-MACROLET
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: goldman@vaxa.isi.edu, cl-cleanup@sail.stanford.edu, cl-object-oriented-programming@sail.stanford.edu
In-Reply-To: <19890710225046.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890710230427.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 10 Jul 89 18:50 EDT
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

    [Common-Lisp removed in favor of more specific mailing lists.]

	Date: Mon, 10 Jul 89 13:49:20 PST
	From: goldman@vaxa.isi.edu
	To: common-lisp@sail.stanford.edu
	Subject: SYMBOL-MACROLET
	Message-Id: <8907102149.AA27155@vaxa.isi.edu>
    
	Is it the case that the expansion code for a symbol-macro, (unlike
	a lexical macro introduced with MACROLET) has not means to obtain
	the current lexical environment?
	neil

    It doesn't get to execute code in order to produce the expansion,
    so obtaining the environment would be meaningless.  The only question
    is, does it get the lexical environment of the binding-point or the
    usage-point. I posed a question like the following to several CLOS 
    implementors at the last X3J13 meeting.

     (DEFMACRO FOO () 1)
     (SYMBOL-MACROLET ((X (FOO)))
       (MACROLET ((FOO () 2))
	 X))

    Consensus seems to be that it is currently defined to return 2.

    I think some people consider this a feature, though I've not seen a
    serious example which shows why. Personally, I think it's a bug.
    I'd rather that it return 1.

This is no different from

     (DEFMACRO FOO () 1)
     (MACROLET ((X () `(FOO)))
       (MACROLET ((FOO () 2))
	 (X)))

which also returns 2.

If Common Lisp had syntactic closures, as proposed to be added to Scheme,
then it would be possible for the definition of X to specify whether
the FOO in the expansion is closed or free, i.e. whether the name FOO
is to be resolved in the environment where the macro was defined or in
the environment where the macro was called.

Since Common Lisp does not have syntactic closures at this time, it is
consistent and appropriate for SYMBOL-MACROLET to behave the same as
MACROLET.  I didn't say it was a feature, I only said it was consistent
and appropriate.