perm filename COMMON.MSG[COM,LSP]38 blob sn#829927 filedate 1986-12-09 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00276 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00041 00002	
C00042 00003	∂29-Jul-86  0328	a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA 	Re: exit-to-system    
C00045 00004	∂29-Jul-86  0623	Moon@RIVERSIDE.SCRC.Symbolics.COM 	Proposal #7: TYPE-SPECIFIER-P 
C00048 00005	∂29-Jul-86  0642	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Some easy ones (?)  
C00050 00006	∂29-Jul-86  0642	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Proposal #8: Clarifications to DEFCONSTANT   
C00055 00007	∂29-Jul-86  0642	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Proposal #14:  THE and VALUES 
C00060 00008	∂29-Jul-86  0642	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Proposal #11: Contents of Tagbody  
C00064 00009	∂29-Jul-86  0643	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Proposal #9: Variable Name Conflicts    
C00070 00010	∂29-Jul-86  0643	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Proposal #13: Structure Sharing in Arguments 
C00079 00011	∂29-Jul-86  0644	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Re: Proposal about lambda-list params   
C00081 00012	∂29-Jul-86  0649	DCP@QUABBIN.SCRC.Symbolics.COM 	Proposal #5 status
C00084 00013	∂29-Jul-86  0652	NGALL@G.BBN.COM 	Re: Proposal about lambda-list params 
C00087 00014	∂29-Jul-86  0658	DCP@QUABBIN.SCRC.Symbolics.COM 	Proposal #5 status
C00090 00015	∂29-Jul-86  1123	DCP@QUABBIN.SCRC.Symbolics.COM 	Re: PARSE-BODY    
C00093 00016	∂29-Jul-86  1215	@SU-SCORE.ARPA,@REAGAN.AI.MIT.EDU:MLY@AI.AI.MIT.EDU 	Re: PARSE-BODY   
C00107 00017	∂29-Jul-86  1218	Miller.pa@Xerox.COM 	Re: Proposal about lambda-list params  
C00110 00018	∂29-Jul-86  1219	DCP@QUABBIN.SCRC.Symbolics.COM 	Staus of proposals 10, 11, and 12
C00113 00019	∂29-Jul-86  1220	@MIT-LIVE-OAK.ARPA,@GOLD-HILL-ACORN.LCS.MIT.EDU:mike%gold-hill-acorn@MIT-LIVE-OAK.ARPA 	Re: Proposal #7 Status:  TYPE-SPECIFIER-P 
C00119 00020	∂29-Jul-86  1255	RPG  	Yapper of the Month Club
C00120 00021	∂29-Jul-86  1456	FAHLMAN@C.CS.CMU.EDU 	Proposed moratorium (clarification)   
C00122 00022	∂29-Jul-86  1734	pyramid!bein@SUN.COM 	closing standard channels   
C00124 00023	∂29-Jul-86  1835	NGALL@G.BBN.COM 	Re: Proposal #9: Variable Name Conflicts   
C00127 00024	∂29-Jul-86  1848	NGALL@G.BBN.COM 	Re: Staus of proposals 10, 11, and 12 
C00130 00025	∂29-Jul-86  1854	FAHLMAN@C.CS.CMU.EDU 	Proposal #8: Clarifications to DEFCONSTANT 
C00133 00026	∂29-Jul-86  1920	FAHLMAN@C.CS.CMU.EDU 	Proposal #9: Variable Name Conflicts  
C00136 00027	∂30-Jul-86  0640	MASINTER.PA@Xerox.COM 	declarations in macrolet puzzle 
C00138 00028	∂30-Jul-86  0705	RAM@C.CS.CMU.EDU 	Declarations in MACROLET   
C00140 00029	∂30-Jul-86  1001	gls@Think.COM 	Motivation for PARSE-BODY
C00142 00030	∂30-Jul-86  1049	Masinter.pa@Xerox.COM 	Re: Motivation for PARSE-BODY   
C00145 00031	∂30-Jul-86  1137	gls@Think.COM 	Re: Proposal about lambda-list params   
C00147 00032	∂30-Jul-86  1252	DCP@QUABBIN.SCRC.Symbolics.COM 	Proposal #5, or somewhere around there (rather long, constructive, and non-flaming(!))  
C00154 00033	∂30-Jul-86  1259	berman@vaxa.isi.edu 	Conference    
C00156 00034	∂30-Jul-86  1330	berman@vaxa.isi.edu 	Conference    
C00158 00035	∂30-Jul-86  1339	FAHLMAN@C.CS.CMU.EDU 	Handout at Lisp Conference  
C00166 00036	∂30-Jul-86  1356	FREEMAN@SUMEX-AIM.ARPA 	Re: Proposal #9: Variable Name Conflicts 
C00169 00037	∂30-Jul-86  1400	jbarnett@nrtc 	Re:  Proposal #9 Status: Variable Name Conflicts  
C00171 00038	∂30-Jul-86  1418	FAHLMAN@C.CS.CMU.EDU 	Proposal #9: Variable Name Conflicts  
C00173 00039	∂30-Jul-86  1434	Gregor.pa@Xerox.COM 	Re: Motivation for PARSE-BODY
C00175 00040	∂30-Jul-86  1719	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Proposal #5 (aside) 
C00177 00041	∂30-Jul-86  1720	KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	#5, #5A, #6, #7, #8, #9, #9A, #9B, #10, #11, #12, #13, #14   
C00193 00042	∂30-Jul-86  1720	BSG@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Re: exit-to-system   
C00196 00043	∂30-Jul-86  1720	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Status of declare UNSPECIAL   
C00200 00044	∂30-Jul-86  2018	FAHLMAN@C.CS.CMU.EDU 	Proposal #5 (aside)    
C00204 00045	∂31-Jul-86  0451	@MCC.COM,@HAL.MCC.DialNet.Symbolics.COM:Loeffler@[10.3.0.62] 	Re: exit-to-system
C00207 00046	∂31-Jul-86  1143	alatto@cc5.bbn.com 	Re: #13, #14   
C00214 00047	∂31-Jul-86  1502	@QUABBIN.SCRC.Symbolics.COM:Zippy@TENEX.SCRC.Symbolics.COM 	Re: Staus of proposals 10, 11, and 12   
C00218 00048	∂31-Jul-86  1506	@QUABBIN.SCRC.Symbolics.COM:Zippy@TENEX.SCRC.Symbolics.COM 	Proposal #5 (aside) 
C00221 00049	∂31-Jul-86  1514	hoey@nrl-aic 	Proposal #9: Fast testing in PROGV  
C00223 00050	∂31-Jul-86  1533	@YUKON.SCRC.Symbolics.COM:Zippy@TENEX.SCRC.Symbolics.COM 	Re:  Proposal #9 Status: Variable Name Conflicts    
C00227 00051	∂31-Jul-86  1827	FAHLMAN@C.CS.CMU.EDU 	Proposal #9 Status: Variable Name Conflicts
C00229 00052	∂31-Jul-86  1848	FAHLMAN@C.CS.CMU.EDU 	What's going on?  
C00232 00053	∂31-Jul-86  1943	NGALL@G.BBN.COM 	Re: declarations in macrolet puzzle   
C00234 00054	∂31-Jul-86  1949	NGALL@G.BBN.COM 	Re: Declarations in MACROLET
C00236 00055	∂31-Jul-86  2155	FAHLMAN@C.CS.CMU.EDU 	Japanese Subset Proposal    
C00238 00056	∂31-Jul-86  2211	KMP@YUKON.SCRC.Symbolics.COM 	Comments on DCP's revised &BODY proposal
C00243 00057	∂31-Jul-86  2229	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Proposal #5, or somewhere around there (rather long, constructive, and non-flaming(!))    
C00245 00058	∂31-Jul-86  2230	KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	QUIT  
C00257 00059	∂01-Aug-86  0357	hpfclp!hpfcjrd!diamant@hplabs.HP.COM 	Proposal #13: Structure Sharing in Arguments   
C00260 00060	∂01-Aug-86  0536	DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Proposal #9: Fast testing in PROGV  
C00263 00061	∂01-Aug-86  0955	hoey@nrl-aic 	Proposal #9: Fast testing in PROGV  
C00266 00062	∂01-Aug-86  0956	gls@Think.COM 	Proposal #9: Fast testing in PROGV 
C00269 00063	∂01-Aug-86  1533	Hadden.CSCES@HI-MULTICS.ARPA 	Re: Proposal #9 Status: Variable Name Conflicts   
C00271 00064	∂04-Aug-86  1300	Dan@Think.COM 	ignore this message 
C00272 00065	∂05-Aug-86  0908	pyramid!bein@hplabs.HP.COM 	synonym streams..
C00274 00066	∂05-Aug-86  1111	Masinter.pa@Xerox.COM 	Re: synonym streams.. 
C00276 00067	∂06-Aug-86  1100	@QUABBIN.SCRC.Symbolics.COM,@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	DPB, DPBS, something like that  
C00279 00068	∂06-Aug-86  1724	@QUABBIN.SCRC.Symbolics.COM,@EUPHRATES.SCRC.Symbolics.COM:Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: synonym streams..    
C00281 00069	∂06-Aug-86  1904	SOLEY@XX.LCS.MIT.EDU 	DPB, DPBS, something like that   
C00283 00070	∂09-Aug-86  2041	mips!earl@glacier.stanford.edu 	:allow-other-keys query
C00285 00071	∂09-Aug-86  2104	FAHLMAN@C.CS.CMU.EDU 	:allow-other-keys query
C00287 00072	∂09-Aug-86  2320	Hvatum.DLAB@MIT-MULTICS.ARPA 	&rest destruction   
C00294 00073	∂10-Aug-86  1205	FAHLMAN@C.CS.CMU.EDU 	&rest destruction 
C00298 00074	∂10-Aug-86  1350	shebs%utah-orion@utah-cs.arpa 	TAGBODY vs LABELS  
C00300 00075	∂10-Aug-86  2132	RAM@C.CS.CMU.EDU 	TAGBODY vs LABELS
C00302 00076	∂10-Aug-86  2327	masinter.PA@Xerox.COM 	tagbody using labels  
C00305 00077	∂11-Aug-86  0916	gls@Think.COM 	,',@ 
C00306 00078	∂11-Aug-86  1120	gls@Think.COM 	tagbody using labels
C00307 00079	∂11-Aug-86  2258	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	TAGBODY vs LABELS   
C00311 00080	∂11-Aug-86  2307	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	:allow-other-keys query  
C00314 00081	∂12-Aug-86  1246	snyder%hplsny@hplabs.HP.COM 	Re: Proposal #7 Status:  TYPE-SPECIFIER-P
C00319 00082	∂13-Aug-86  1051	Moon@QUABBIN.SCRC.Symbolics.COM 	Proposal #7:  TYPE-SPECIFIER-P  
C00324 00083	∂13-Aug-86  2151	LOOSEMORE@UTAH-20.ARPA 	question about subtypep   
C00326 00084	∂14-Aug-86  0353	RAM@C.CS.CMU.EDU 	question about subtypep    
C00329 00085	∂14-Aug-86  0559	Hvatum.DLAB@MIT-MULTICS.ARPA 	&rest destruction   
C00332 00086	∂14-Aug-86  1444	Pavel.pa@Xerox.COM 	More words on the scoping of declarations    
C00352 00087	∂14-Aug-86  1602	RAM@C.CS.CMU.EDU 	More words on the scoping of declarations (FTYPE)   
C00354 00088	∂15-Aug-86  0734	cvfong@mitre.ARPA 	drop out   
C00355 00089	∂18-Aug-86  1101	RAM@C.CS.CMU.EDU 	More words on the scoping of declarations 
C00358 00090	∂18-Aug-86  1459	@DIAMOND.S4CC.Symbolics.COM:File-Server@DIAMOND.S4CC.Symbolics.COM 	string-/=, etc.  
C00360 00091	∂18-Aug-86  1725	HEDRICK@RED.RUTGERS.EDU 	close on synonym streams, etc 
C00362 00092	∂18-Aug-86  1825	franz!fizzy!jkf@kim.Berkeley.EDU 	Re: synonym streams..     
C00366 00093	∂19-Aug-86  1045	ACUFF@SUMEX-AIM.ARPA 	Re: synonym streams..  
C00368 00094	∂19-Aug-86  1240	KMP@STONY-BROOK.SCRC.Symbolics.COM 	close on synonym streams, etc
C00374 00095	∂19-Aug-86  1556	pyramid!bein@hplabs.HP.COM 	streams ... 
C00379 00096	∂19-Aug-86  1827	sridhar%tekecs.tek.csnet@CSNET-RELAY.ARPA 	documentation strings in BOA constructors ?    
C00381 00097	∂19-Aug-86  1840	RAM@C.CS.CMU.EDU 	documentation strings in BOA constructors ?    
C00384 00098	∂20-Aug-86  0540	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	"fonted" characters in CL
C00388 00099	∂20-Aug-86  1040	RICE@SUMEX-AIM.ARPA 	Defstruct and Documentation. 
C00389 00100	∂22-Aug-86  1333	@MC.LCS.MIT.EDU,@SEBASTIAN.THINK.COM:gls@AQUINAS.THINK.COM 	1986 Lisp conference bibliography  
C00428 00101	∂25-Aug-86  1059	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Defstruct and Documentation.  
C00430 00102	∂25-Aug-86  1105	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	question about subtypep  
C00434 00103	∂25-Aug-86  1117	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Re: synonym streams..    
C00436 00104	∂25-Aug-86  1201	RAM@C.CS.CMU.EDU 	question about subtypep    
C00439 00105	∂25-Aug-86  2029	@MIT-LIVE-OAK.ARPA,@GOLD-HILL-ACORN.LCS.MIT.EDU:mike%gold-hill-acorn@MIT-LIVE-OAK.ARPA 	More words on the scoping of declarations 
C00444 00106	∂25-Aug-86  2154	@MIT-LIVE-OAK.ARPA,@GOLD-HILL-ACORN.LCS.MIT.EDU:mike%gold-hill-acorn@MIT-LIVE-OAK.ARPA 	"fonted" characters in CL  
C00450 00107	∂26-Aug-86  0057	pyramid!bein@hplabs.HP.COM 	re: synonym streams.. 
C00458 00108	∂26-Aug-86  0653	preece%ccvaxa@gswd-vms.ARPA 	Re: More words on the scoping of dec
C00461 00109	∂26-Aug-86  0904	RAM@C.CS.CMU.EDU 	More words on the scoping of declarations 
C00464 00110	∂27-Aug-86  0925	Gregor.pa@Xerox.COM 	Fixing optional arguments?   
C00467 00111	∂27-Aug-86  1058	FAHLMAN@C.CS.CMU.EDU 	Fixing optional arguments?  
C00469 00112	∂27-Aug-86  1846	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	Fixing optional arguments?    
C00473 00113	∂28-Aug-86  1122	Gregor.pa@Xerox.COM 	Re: Fixing optional arguments?    
C00476 00114	∂28-Aug-86  1216	RAM@C.CS.CMU.EDU 	Fixing optional arguments? 
C00478 00115	∂29-Aug-86  0956	@DIAMOND.S4CC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	Re: Fixing optional arguments? 
C00481 00116	∂31-Aug-86  1341	LOOSEMORE@UTAH-20.ARPA 	question about pprint, *print-pretty*    
C00483 00117	∂02-Sep-86  0909	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	question about pprint, *print-pretty*   
C00487 00118	∂02-Sep-86  0909	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	question about pprint, *print-pretty*   
C00491 00119	∂02-Sep-86  1149	KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	PRINT 
C00494 00120	∂02-Sep-86  1234	Masinter.pa@Xerox.COM 	Re: close on synonym streams, etc    
C00497 00121	∂03-Sep-86  1409	RICE@SUMEX-AIM.ARPA 	Documentation strings and function.    
C00500 00122	∂03-Sep-86  1636	VERACSD@A.ISI.EDU 	Deletion from Mailing-List
C00501 00123	∂03-Sep-86  1810	FAHLMAN@C.CS.CMU.EDU 	Documentation strings and function.   
C00503 00124	∂03-Sep-86  1929	@WAIKATO.S4CC.SYMBOLICS.COM:KMP@STONY-BROOK.SCRC.Symbolics.COM 	Documentation strings and function. 
C00508 00125	∂04-Sep-86  0739	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	Documentation strings and function.
C00511 00126	∂04-Sep-86  0853	allen@bfly-vax.bbn.com 	Re: Documentation strings and function.  
C00513 00127	∂04-Sep-86  0945	FAHLMAN@C.CS.CMU.EDU 	Documentation strings and function.   
C00516 00128	∂04-Sep-86  1038	LINNDR%VUENGVAX.BITNET@WISCVM.WISC.EDU 	Problems with Notation in CLtL
C00520 00129	∂04-Sep-86  1102	allen@bfly-vax.bbn.com 	Re: Documentation strings and function.  
C00522 00130	∂04-Sep-86  1222	FAHLMAN@C.CS.CMU.EDU 	Documentation strings and function.   
C00524 00131	∂04-Sep-86  1421	Bobrow.pa@Xerox.COM 	Re: Documentation strings and function.
C00526 00132	∂04-Sep-86  1421	Bobrow.pa@Xerox.COM 	Re: Documentation strings and function.
C00528 00133	∂04-Sep-86  1518	@ELEPHANT-BUTTE.SCRC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	Re: Documentation strings and function.
C00531 00134	∂04-Sep-86  1639	@ELEPHANT-BUTTE.SCRC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	Re: Documentation strings and function.
C00533 00135	∂04-Sep-86  1842	@REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU 	Re: Documentation strings and function.  
C00538 00136	∂05-Sep-86  1236	gls@Think.COM 	Problems with Notation in CLtL
C00540 00137	∂05-Sep-86  2358	ELIOT%cs.umass.edu@CSNET-RELAY.ARPA 	Programmer Notes  
C00544 00138	∂07-Sep-86  1646	KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	#+FOO:BAR  
C00546 00139	∂08-Sep-86  0909	@ELEPHANT-BUTTE.SCRC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	Programmer Notes   
C00548 00140	∂11-Sep-86  0839	MATT@LL.ARPA 	 
C00549 00141	∂12-Sep-86  0311	bradley@Think.COM 	An example of where setf does not do what I want.  
C00551 00142	∂12-Sep-86  0814	FAHLMAN@C.CS.CMU.EDU 	An example of where setf does not do what I want.    
C00555 00143	∂12-Sep-86  0844	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	An example of where setf does not do what I want. 
C00559 00144	∂12-Sep-86  0942	fateman@renoir.Berkeley.EDU 	OPS-5 in Common Lisp 
C00561 00145	∂12-Sep-86  1030	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	An example of where setf does not do what I want. 
C00564 00146	∂13-Sep-86  1846	ELIOT%cs.umass.edu@CSNET-RELAY.ARPA 	Locally 
C00567 00147	∂14-Sep-86  1337	FAHLMAN@C.CS.CMU.EDU 	Locally 
C00570 00148	∂14-Sep-86  1543	Gregor.pa@Xerox.COM 	Portable CommonLoops port liasons 
C00572 00149	∂15-Sep-86  1357	fateman@renoir.Berkeley.EDU 	ops-5 
C00574 00150	∂15-Sep-86  1438	jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	Re:  OPS-5 in Common Lisp
C00577 00151	∂15-Sep-86  1937	NGALL@G.BBN.COM 	defstruct slots' default-inits   
C00579 00152	∂17-Sep-86  1044	tsf@theory.cs.cmu.edu 	Readtables and prin1  
C00581 00153	∂17-Sep-86  1813	FAHLMAN@C.CS.CMU.EDU 	Readtables and prin1   
C00583 00154	∂17-Sep-86  1847	FAHLMAN@C.CS.CMU.EDU 	Readtables and prin1   
C00585 00155	∂17-Sep-86  2001	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Readtables and prin1   
C00589 00156	∂17-Sep-86  2216	@DIAMOND.S4CC.Symbolics.COM:DDYER@RIVERSIDE.SCRC.Symbolics.COM 	Readtables and prin1 
C00592 00157	∂18-Sep-86  0701	@UR-ACORN.ARPA,@UR-CASHEW.ARPA:miller@UR-ACORN.ARPA 	Re: Readtables and prin1   
C00595 00158	∂18-Sep-86  1037	FAHLMAN@C.CS.CMU.EDU 	Readtables and prin1   
C00598 00159	∂18-Sep-86  1039	yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA 	Re: OPS5 in Common Lisp 
C00600 00160	∂18-Sep-86  1100	LOOSEMORE@UTAH-20.ARPA 	*applyhook* question 
C00601 00161	∂18-Sep-86  1104	LOOSEMORE@UTAH-20.ARPA 	*applyhook* question (hopefully I'll get it right this time) 
C00603 00162	∂18-Sep-86  1538	pyramid!bein@hplabs.HP.COM 	testing addresses ... please ignore  
C00604 00163	∂19-Sep-86  1853	cross@afit-ab.ARPA 	please add my name  
C00605 00164	∂20-Sep-86  1751	cross@afit-ab.ARPA 	xlisp query    
C00606 00165	∂22-Sep-86  1734	@RIVERSIDE.SCRC.Symbolics.COM,@BIS-ALICE-LIDDELL.DialNet.Symbolics.COM:Stever@BIS-ALICE-LIDDELL.BISCC.DIALNET.SYMBOLICS.COM 	" macro character   
C00608 00166	∂22-Sep-86  1749	Moon@STONY-BROOK.SCRC.Symbolics.COM 	*applyhook* question (hopefully I'll get it right this time)   
C00612 00167	∂23-Sep-86  0352	ma←jpf%ux63.bath.ac.uk@Cs.Ucl.AC.UK 	OPS-5   
C00613 00168	∂24-Sep-86  1159	ACUFF@SUMEX-AIM.ARPA 	Re: Readtables and prin1    
C00614 00169	∂24-Sep-86  1932	FAHLMAN@C.CS.CMU.EDU 	Mailing list requests  
C00615 00170	∂24-Sep-86  1943	FAHLMAN@C.CS.CMU.EDU 	Readtables and prin1   
C00617 00171	∂25-Sep-86  0640	@MC.LCS.MIT.EDU:STEVER%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU 	Are strings adjustable arrays? 
C00619 00172	∂25-Sep-86  1358	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	Are strings adjustable arrays?
C00622 00173	∂25-Sep-86  1416	RPG  	Jim Meehan Comments
C00625 00174	∂26-Sep-86  0558	Dan@Think.COM 	Jim Meehan Comments 
C00628 00175	∂29-Sep-86  1037	DALY@IBM.COM 	getting on the common lisp list
C00629 00176	∂03-Oct-86  1337	@MC.LCS.MIT.EDU:STEVER%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU   
C00631 00177	∂03-Oct-86  1429	RAM@C.CS.CMU.EDU    
C00633 00178	∂03-Oct-86  1853	@REAGAN.AI.MIT.EDU:RDZ@AI.AI.MIT.EDU 	Printing DEFSTRUCTs   
C00635 00179	∂03-Oct-86  2100	DT50@A.CS.CMU.EDU 	printing structures  
C00637 00180	∂04-Oct-86  0023	bader@spice.cs.cmu.edu 	Re: printing structures   
C00638 00181	∂04-Oct-86  1817	RWK@YUKON.SCRC.Symbolics.COM 	Re: printing structures  
C00641 00182	∂05-Oct-86  2017	Masinter.pa@Xerox.COM 	Re: printing structures    
C00644 00183	∂05-Oct-86  2115	SOLEY@XX.LCS.MIT.EDU 	printing structures    
C00646 00184	∂05-Oct-86  2223	ELIOT%cs.umass.edu@CSNET-RELAY.ARPA 	Printing Structures    
C00649 00185	∂06-Oct-86  1045	DLW@ALDERAAN.SCRC.Symbolics.COM 	Printing Structures   
C00652 00186	∂06-Oct-86  2103	RWK@YUKON.SCRC.Symbolics.COM 	Re: printing structures  
C00656 00187	∂07-Oct-86  0917	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	Re: printing structures  
C00659 00188	∂16-Oct-86  0123	KMP@STONY-BROOK.SCRC.Symbolics.COM 	DEFVAR   
C00661 00189	∂16-Oct-86  0123	KMP@STONY-BROOK.SCRC.Symbolics.COM 	ADJUST-ARRAY  
C00664 00190	∂16-Oct-86  1604	Moon@STONY-BROOK.SCRC.Symbolics.COM 	ADJUST-ARRAY 
C00669 00191	∂16-Oct-86  1801	Moon@STONY-BROOK.SCRC.Symbolics.COM 	ADJUST-ARRAY 
C00674 00192	∂20-Oct-86  1046	FAHLMAN@C.CS.CMU.EDU 	DEFVAR  
C00676 00193	∂21-Oct-86  0851	@UR-ACORN.ARPA,@UR-CASHEW.ARPA:miller@UR-ACORN.ARPA 	Applying functions to all the symbols in a package...    
C00679 00194	∂21-Oct-86  0913	FAHLMAN@C.CS.CMU.EDU 	Applying functions to all the symbols in a package...
C00682 00195	∂30-Oct-86  1346	RPG   	Fahlman's remarks 
C00691 00196	∂30-Oct-86  1346	RPG   	Fahlman's remarks 
C00694 00197	∂30-Oct-86  1347	RPG   	Fahlman's remarks 
C00696 00198	∂30-Oct-86  1422	RPG   	Fahlman's remarks 
C00703 00199	∂31-Oct-86  1324	edsel!sunvalleymall!jlz@navajo.stanford.edu 	Call for Papers
C00710 00200	∂31-Oct-86  1923	JAR@AI.AI.MIT.EDU 	[KLOTZ: defstruct initialization in :constructor ] 
C00713 00201	∂03-Nov-86  0718	samalone@ATHENA.MIT.EDU 	DEFSTRUCT copier query   
C00715 00202	∂03-Nov-86  0755	RAM@C.CS.CMU.EDU 	DEFSTRUCT copier query
C00717 00203	∂03-Nov-86  1338	Pavel.pa@Xerox.COM 	Re: DEFSTRUCT copier query    
C00720 00204	∂03-Nov-86  1937	Bobrow.pa@Xerox.COM 	Re: DEFSTRUCT copier query   
C00724 00205	∂03-Nov-86  1938	@MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU 	DEFSTRUCT copier query
C00728 00206	∂06-Nov-86  2120	sridhar%tekchips.tek.csnet@RELAY.CS.NET 	Why is #'equalp not allowed in make-hash-table ? 
C00730 00207	∂07-Nov-86  1028	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	DEFVAR    
C00733 00208	∂08-Nov-86  1208	RPG   	Re: from Japan    
C00735 00209	∂10-Nov-86  1921	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Why is #'equalp not allowed in make-hash-table ?
C00738 00210	∂11-Nov-86  1220	edsel!bhopal!jonl@navajo.stanford.edu 	Why is #'equalp not allowed in make-hash-table ?   
C00743 00211	∂11-Nov-86  1300	@MIT-LIVE-OAK.ARPA:Soley@MIT-XX.ARPA 	Why is #'equalp not allowed in make-hash-table ?    
C00745 00212	∂12-Nov-86  1435	STEVER%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	Declarations within FLET    
C00746 00213	∂14-Nov-86  0955	AI.BOYER@MCC.COM 	sloop  
C00750 00214	∂17-Nov-86  0218	z30083%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET 	type-of    
C00756 00215	∂17-Nov-86  1503	RAM@C.CS.CMU.EDU 	type-of
C00759 00216	∂18-Nov-86  0812	@ACORN.CS.ROCHESTER.EDU,@CASHEW.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU 	Package functions not powerful enough?  
C00764 00217	∂18-Nov-86  1058	@ACORN.CS.ROCHESTER.EDU,@CASHEW.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU 	[miller@UR-ACORN.ARPA: Package functions not powerful enough?]   
C00770 00218	∂18-Nov-86  1257	wile@vaxa.isi.edu 	Packages: a modest solution.   
C00778 00219	∂18-Nov-86  1304	RWK@YUKON.SCRC.Symbolics.COM 	type-of   
C00793 00220	∂18-Nov-86  1454	shebs%utah-orion@utah-cs.arpa 	Packages 
C00796 00221	∂18-Nov-86  1539	masinter.pa@Xerox.COM 	Re: type-of 
C00799 00222	∂18-Nov-86  1854	Miller.pa@Xerox.COM 	Re: Packages: a modest solution.  
C00801 00223	∂18-Nov-86  1906	RAM@C.CS.CMU.EDU 	Package functions not powerful enough?    
C00804 00224	∂18-Nov-86  1909	FAHLMAN@C.CS.CMU.EDU 	TYPE-OF 
C00808 00225	∂19-Nov-86  0749	shebs%utah-orion@utah-cs.arpa 	Re: type-of   
C00810 00226	∂19-Nov-86  0817	sandra%utah-orion@utah-cs.arpa 	type-of 
C00814 00227	∂19-Nov-86  1132	DLW@ALDERAAN.SCRC.Symbolics.COM 	Packages    
C00818 00228	∂19-Nov-86  2254	@MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU 	Packages: a modest solution.    
C00825 00229	∂19-Nov-86  2355	a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET 	TYPE-OF    
C00836 00230	∂20-Nov-86  0703	RAM@C.CS.CMU.EDU 	type-of
C00841 00231	∂20-Nov-86  0747	cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	fboundp question    
C00842 00232	∂20-Nov-86  1020	DLW@ALDERAAN.SCRC.Symbolics.COM 	side comment
C00844 00233	∂20-Nov-86  1032	spe@cad.cs.cmu.edu 	EVAL 
C00846 00234	∂20-Nov-86  1150	DLW@VALLECITO.SCRC.Symbolics.COM 	TYPE-OF    
C00850 00235	∂20-Nov-86  1217	gls@think.com 	TYPE-OF   
C00852 00236	∂20-Nov-86  1250	RPG  	TYPE-OF  
C00853 00237	∂20-Nov-86  1325	FAHLMAN@C.CS.CMU.EDU 	EVAL    
C00857 00238	∂20-Nov-86  1433	DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	TYPE-OF    
C00861 00239	∂20-Nov-86  1532	Pavel.pa@Xerox.COM 	Re: fboundp question
C00863 00240	∂21-Nov-86  0242	a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET 	question: EVAL  
C00865 00241	∂21-Nov-86  0613	RAM@C.CS.CMU.EDU 	question: EVAL   
C00867 00242	∂21-Nov-86  0637	RAM@C.CS.CMU.EDU 	TYPE-OF
C00871 00243	∂21-Nov-86  0808	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Packages
C00875 00244	∂21-Nov-86  0944	wile@vaxa.isi.edu 	Package solution "motivation"  
C00882 00245	∂21-Nov-86  1152	RWK@STONY-BROOK.SCRC.Symbolics.COM 	type-of  
C00889 00246	∂21-Nov-86  1231	RWK@STONY-BROOK.SCRC.Symbolics.COM 	TYPE-OF  
C00892 00247	∂21-Nov-86  1300	RWK@STONY-BROOK.SCRC.Symbolics.COM 	TYPE-OF  
C00899 00248	∂21-Nov-86  1519	sandra%utah-orion@utah-cs.arpa 	Re: type-of  
C00902 00249	∂21-Nov-86  1657	RAM@C.CS.CMU.EDU 	TYPE-OF
C00907 00250	∂22-Nov-86  1433	@REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU 	EVAL  
C00910 00251	∂22-Nov-86  1701	Pavel.pa@Xerox.COM 	Re: EVAL  
C00912 00252	∂22-Nov-86  1743	ricks%shambhala.Berkeley.EDU@BERKELEY.EDU 	Macrolet and setf
C00914 00253	∂22-Nov-86  1820	@REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU 	Re: EVAL   
C00917 00254	∂22-Nov-86  1922	Pavel.pa@Xerox.COM 	Re: Macrolet and setf    
C00919 00255	∂22-Nov-86  1932	franz!ficl!jkf@ucbarpa.Berkeley.EDU 	Re: Macrolet and setf  
C00921 00256	∂22-Nov-86  2052	FAHLMAN@C.CS.CMU.EDU 	Macrolet and setf 
C00924 00257	∂22-Nov-86  2054	RPG  	GET-SETF-METHOD    
C00926 00258	∂23-Nov-86  1236	RAM@C.CS.CMU.EDU 	(typep 3 'complex) => t    
C00930 00259	∂23-Nov-86  1413	Masinter.pa@Xerox.COM 	Re: (typep 3 'complex) => t
C00933 00260	∂23-Nov-86  1432	RAM@C.CS.CMU.EDU 	(typep 3 'complex) => t    
C00936 00261	∂23-Nov-86  1538	Masinter.pa@Xerox.COM 	Re: (typep 3 'complex) => t
C00938 00262	∂24-Nov-86  1135	@MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU 	question: EVAL   
C00943 00263	∂24-Nov-86  1300	sandra%utah-orion@utah-cs.arpa 	hash table question    
C00945 00264	∂24-Nov-86  1543	DLW@ALDERAAN.SCRC.Symbolics.COM 	hash table question   
C00947 00265	∂24-Nov-86  1630	sandra%utah-orion@utah-cs.arpa 	Re: hash table question
C00950 00266	∂24-Nov-86  1725	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: hash table question
C00954 00267	∂24-Nov-86  1959	FAHLMAN@C.CS.CMU.EDU 	hash table question    
C00956 00268	∂24-Nov-86  2130	edsel!bhopal!jonl@navajo.stanford.edu 	type-of    
C00959 00269	∂24-Nov-86  2134	edsel!bhopal!jonl@navajo.stanford.edu 	hash table question  
C00966 00270	∂25-Nov-86  2005	@MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU 	EVAL   
C00970 00271	∂25-Nov-86  2124	ALAN@AI.AI.MIT.EDU 	EVAL 
C00972 00272	∂26-Nov-86  0834	KMP@YUKON.SCRC.Symbolics.COM 	EVAL 
C00980 00273	∂26-Nov-86  0834	spe@cad.cs.cmu.edu 	Re:  EVAL 
C00982 00274	∂26-Nov-86  1308	@ACORN.CS.ROCHESTER.EDU,@CASHEW.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU 	eval and other topics    
C00989 00275	∂26-Nov-86  1407	@WAIKATO.S4CC.Symbolics.COM:KMP@STONY-BROOK.SCRC.Symbolics.COM 	eval and other topics
C00993 00276	∂26-Nov-86  1734	ALAN@AI.AI.MIT.EDU 	EVAL 
C00998 ENDMK
C⊗;
∂29-Jul-86  0328	a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA 	Re: exit-to-system    
Received: from CSNET-RELAY.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86  03:28:11 PDT
Received: from utokyo-relay by csnet-relay.csnet id ac01013; 29 Jul 86 6:31 EDT
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
	id AA18879; Tue, 29 Jul 86 16:30:28+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
	id AA22657; Tue, 29 Jul 86 16:14:11+0900
Date: Tue, 29 Jul 86 16:14:11+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
Message-Id: <8607290714.AA22657@ccut.u-tokyo.junet>
To: common-lisp@SU-AI.ARPA, gls%aquinas.think.com@CSNET-RELAY.ARPA, 
    ida%u-tokyo.junet@CSNET-RELAY.ARPA
Subject: Re: exit-to-system

        Date: Mon, 21 Jul 86 15:01 EDT
        From: Guy Steele <gls%ZARATHUSTRA.THINK.COM@u-tokyo.junet>
        Subject: Re: exit-to-system 
            ...
        Well, we do have ED, which is clearly a user-interface thing.
        Here is a stab at defining QUIT:
        
        QUIT					[Function]
        
        This function is intended to terminate the running Lisp system in some
        appropriate manner.     ... 
	...
        --Guy
I agree. The name QUIT sounds reasonable.

ida@utokyo-relay.csnet
-----

∂29-Jul-86  0623	Moon@RIVERSIDE.SCRC.Symbolics.COM 	Proposal #7: TYPE-SPECIFIER-P 
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86  06:23:30 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 43549; Mon 28-Jul-86 20:24:25 EDT
Date: Mon, 28 Jul 86 20:24 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposal #7: TYPE-SPECIFIER-P
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>,
             <860721-221520-2564@Xerox>,
             <860722-102542-2911@Xerox>,
             <860722174822.6.DCP@FIREBIRD.SCRC.Symbolics.COM>,
             <[G.BBN.COM]23-Jul-86 02:30:50.NGALL>,
             <860723130828.1.DCP@FIREBIRD.SCRC.Symbolics.COM>,
             <8607272237.AA21099@lmi-angel.ARPA>,
             <FAHLMAN.12226129722.BABYL@C.CS.CMU.EDU>,
             <FAHLMAN.12226153071.BABYL@C.CS.CMU.EDU>,
             <860728111011.1.DCP@FIREBIRD.SCRC.Symbolics.COM>,
             <860728-123623-2787@Xerox>
Message-ID: <860728202419.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

TYPE-SPECIFIER-P is an appropriate name for a function that takes an
(OR SYMBOL LIST) and tells whether it's a valid specifier.  If you're
going to replace this with a function that takes a SYMBOL and tells
whether it's the name of a type, call it TYPE-NAME-P.

However, I agree with Masinter's comment that we should concentrate on
fixing what is wrong with the language rather than adding more features.
I have no objection to either of TYPE-SPECIFIER-P or TYPE-NAME-P if
someone can show why these are needed to fix something wrong with the
language.  Perhaps Guy can comment on why the original proposal 51 in
his clarifications list was tagged with an asterisk indicating that it
corrects an important flaw or resolves an ambiguity in the
specification.

∂29-Jul-86  0642	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Some easy ones (?)  
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 29 Jul 86  06:41:50 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51598; Mon 28-Jul-86 17:32:55 EDT
Date: Mon, 28 Jul 86 17:32 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Some easy ones (?)
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>
Message-ID: <860728173256.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

I would find it much easier to follow these discussions if there
weren't ten discussions going on simultaneously in the -same-
messages.  If each discussion was conducted in a different set
of messages, I could sort the messages into individual discussions
and read each discussion as an uninterrupted, coherent whole.

To practice what I preach, I am going to respond to each of the
ten proposals in your message of 21 July with a separate message
(except for the ones that I don't respond to at all).

∂29-Jul-86  0642	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Proposal #8: Clarifications to DEFCONSTANT   
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 29 Jul 86  06:42:04 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51809; Mon 28-Jul-86 20:57:55 EDT
Date: Mon, 28 Jul 86 20:57 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposal #8: Clarifications to DEFCONSTANT
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>,
             <860722174822.6.DCP@FIREBIRD.SCRC.Symbolics.COM>,
             <[G.BBN.COM]23-Jul-86 02:30:50.NGALL>,
             <FAHLMAN.12226153748.BABYL@C.CS.CMU.EDU>
Message-ID: <860728205756.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 21 Jul 1986  21:46 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    Proposal #8:  Clarifications to DEFCONSTANT

    Clarify that using DEFCONSTANT to redefine any constant described in the
    Common Lisp specification is an error.

Non-controversial.

    Clarify that if the user defines a constant, compiles code that refers
    to that constant, and then redefines the constant, then behavior of the
    compiled code may be unpredictable.  It is an error to execute such
    code.

Non-controversial, and "is an error" seems clearly the right level, rather
than "signals an error."

    Clarify that it is not an error to issue a second DEFCONSTANT command
    for an existing constant iff the new value is EQL to the old one.

    [That last clarification has not been discussed previously, as far as I
    know, but seems to be needed for reloading certain compiled code files,
    etc.]

Do you mean EQL or EQUAL?  Consider the example

  (defconstant error-message-69 "Le *terminal-io* n'est pas une pipe.")

I don't see any good justification for reading and evaluating that form
twice to be an error.  Consider that many Lisp dialects consider EQUAL
constants equivalent and coalesce them into EQ objects.  Of course EQUAL
isn't exactly the right test either, since (equal #(1 2 3) #(1 2 3)) is nil.
The appropriate test would be one that compares all elements of structured
objects and compares atoms with EQL, which doesn't exist as a predefined
function in Common Lisp.  Equality was one of the areas where we decided
to punt in the interests of getting a language specification out in a
finite time, since there wasn't complete agreement on what to do.

Perhaps parts 2 and 3 of this proposal properly belong to the system
environment, rather than to the programming language, especially when
you start talking about such concepts as "compiled code files".

∂29-Jul-86  0642	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Proposal #14:  THE and VALUES 
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 29 Jul 86  06:42:16 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51845; Mon 28-Jul-86 21:21:50 EDT
Date: Mon, 28 Jul 86 21:21 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposal #14:  THE and VALUES
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>,
             <860722174822.6.DCP@FIREBIRD.SCRC.Symbolics.COM>,
             <[G.BBN.COM]23-Jul-86 02:30:50.NGALL>,
             <RAM.12224974495.BABYL@C.CS.CMU.EDU>,
             <860723125416.0.DCP@FIREBIRD.SCRC.Symbolics.COM>,
             <860723130828.1.DCP@FIREBIRD.SCRC.Symbolics.COM>,
             <[G.BBN.COM]23-Jul-86 22:40:33.NGALL>,
             <FAHLMAN.12226167693.BABYL@C.CS.CMU.EDU>
Message-ID: <860728212151.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 21 Jul 1986  21:46 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    Specify that in (THE (VALUES ...) form), the form may return more
    values, but not fewer, than the number of types specified in the (VALUES
    ...) form, and that any extra values are of unrestricted type.

    Also specify that (THE type form) where type is not (VALUES ...) is
    equivalent to (THE (VALUES type) form).

I agree completely with MacLachlan's comments, enclosed.  Both parts of
the proposal should be rejected.  I do have one query; see below.

Plummer's suggestion of a standardized way to coerce a result to a
particular number of values sounds useful but should be raised as a
separate issue.

    Date: Wed, 23 Jul 1986  09:50 EDT
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>

	Well, I think everyone is wrong about this one. (THE (VALUES ...) ...)
    specifies the functional type of the continuation.  This is in effect
    what CLTL already says: "...indicates the parameter list of a function
    that, when given to multiple-value-call along with the values, would
    be suitable for receiving those values."

My question is whether the quoted text (CLtL p.48) is a mistake.  It could
have been accidentally retained from the days when multiple-value-bind
allowed & keywords, or it could be intentional.

	I strongly disagree with any proposal which gives THE mandatory
    run-time semantics.  THE is a declaration --- its presence should not
    change the meaning of a correct program.  If the form returns too many
    values, then the program is in error and the result is undefined.

	I agree that it is highly desirable to be able to specify the
    type of the first value without worrying about the actual number of
    values.  To this end, I propose that (THE FOO ...) should be
    synonomous with the (THE (VALUES FOO &REST T) ...).  This allows one
    to say things like (THE FIXNUM (TRUNCATE ...)).

	It should also be clarified that the VALUES type specifier may
    have &ALLOW-OTHER-KEYS.


∂29-Jul-86  0642	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Proposal #11: Contents of Tagbody  
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 29 Jul 86  06:42:11 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51834; Mon 28-Jul-86 21:07:53 EDT
Date: Mon, 28 Jul 86 21:07 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposal #11: Contents of Tagbody
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>,
             <860722174822.6.DCP@FIREBIRD.SCRC.Symbolics.COM>,
             <[G.BBN.COM]23-Jul-86 02:30:50.NGALL>,
             The message of 23 Jul 86 15:30 EDT from "BACH::VANROGGEN" <vanroggen%bach.decnet@hudson.dec.com>,
             <FAHLMAN.12226158847.BABYL@C.CS.CMU.EDU>
Message-ID: <860728210754.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 21 Jul 1986  21:46 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    Proposal #11: Contents of Tagbody

    Specify that constant forms such as strings may appear at top-level in a
    tagbody, but that only symbols and integers are considered to be tags.
    It is an error to use anything else as the destination tag for a GO.

    [Several forms of this have been kicked around.  This seems as good as
    any.  The original issue was whether you could put something like a
    string at top-level and, if so, whether you could go to it.]

I prefer Steele's original proposal, which was:

  Specify explicitly that anything in a TAGBODY other than
  a symbol, integer, or list is an error.

The manual already implies this, so the change would not be incompatible.
I can see nothing but user confusion resulting from allowing strings or
any other object that is not self-evidently either a form or a tag.
I'm more than willing to take (tagbody #1="bar" (print 1) (go #1#))
out of the Symbolics interpreter (the compiler already complains).

I think we should continue to allow integers as tags, for two reasons.
(1) Removing them would be an unnecessary incompatibility.
(2) Some people may be used to using integers as tags in other languages
(Basic, Pascal, Fortran) and these are the people most likely to be using
GO directly (rather than as part of the expansion of a macro).

∂29-Jul-86  0643	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Proposal #9: Variable Name Conflicts    
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 29 Jul 86  06:42:54 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51857; Mon 28-Jul-86 22:10:57 EDT
Date: Mon, 28 Jul 86 22:10 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposal #9: Variable Name Conflicts
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>,
             <860722174822.6.DCP@FIREBIRD.SCRC.Symbolics.COM>,
             <[G.BBN.COM]23-Jul-86 02:30:50.NGALL>,
             The message of 23 Jul 86 15:30 EDT from "BACH::VANROGGEN" <vanroggen%bach.decnet@hudson.dec.com>,
             <12225052592.76.FREEMAN@SUMEX-AIM.ARPA>,
             <[G.BBN.COM]23-Jul-86 21:39:54.NGALL>,
             <[G.BBN.COM]23-Jul-86 23:55:15.NGALL>,
             <12225270515.16.ANDY@Sushi.Stanford.EDU>,
             <FAHLMAN.12225389688.BABYL@C.CS.CMU.EDU>,
             The message of 25 Jul 86 00:30 EDT from Dave.Touretzky@A.CS.CMU.EDU,
             <[G.BBN.COM]25-Jul-86 01:45:01.NGALL>,
             The message of 25 Jul 86 09:15 EDT from "BACH::VANROGGEN" <vanroggen%bach.decnet@hudson.dec.com>,
             <860725174559.4.GLS@IGNATIUS.THINK.COM>,
             <12225647140.10.ANDY@Sushi.Stanford.EDU>,
             <FAHLMAN.12225773488.BABYL@C.CS.CMU.EDU>,
             <[G.BBN.COM]26-Jul-86 12:50:48.NGALL>,
             <12225811022.11.ANDY@Sushi.Stanford.EDU>,
             <FAHLMAN.12225827449.BABYL@C.CS.CMU.EDU>,
             <860726-182347-1898@Xerox>,
             <FAHLMAN.12225891798.BABYL@C.CS.CMU.EDU>,
             <[AI.AI.MIT.EDU].76153.860726.ALAN>,
             <FAHLMAN.12226156362.BABYL@C.CS.CMU.EDU>
Message-ID: <860728221058.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sun, 27 Jul 1986  22:02 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    Proposal #9A:

    It is an error for two parameters (including supplied-p and &aux
    parameters) in the same lambda list to be represented by the same (EQ)
    symbol.  This also holds for parameters bound by LET, LET*, DO, DO*,
    FLET, LABELS, PROGV, MACROLET, MV-BIND, and PROG.

There is no such thing as MV-BIND; I expect you meant MULTIPLE-VALUE-BIND.
You forgot PROG*.  You omitted COMPILER-LET and PROGV, but I can't guess
whether this was accidental or intentional.

    ---------------------------------------------------------------------------
    Proposal #9B:

    Same, but don't include LET*.
    ---------------------------------------------------------------------------

Although I favor 9A, I have to point out that Fahlman has used his power
as moderator to make proposal 9B look bad.  Surely the real 9B would
treat all of the sequential binding forms in a consistent way.

This appears to be one of those situations where the answer is obviously
correct, but the obviously correct answer is different for different
individuals.  The only comment I can add is that no matter which
proposal is adopted, it is very easy for the proponents of the other
proposal to define a LET+ macro which is LET* done the way they wanted,
and similarly for the other sequential binding forms.

∂29-Jul-86  0643	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Proposal #13: Structure Sharing in Arguments 
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 29 Jul 86  06:42:32 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51850; Mon 28-Jul-86 21:54:06 EDT
Date: Mon, 28 Jul 86 21:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposal #13: Structure Sharing in Arguments
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>,
             <860722174822.6.DCP@FIREBIRD.SCRC.Symbolics.COM>,
             The message of 23 Jul 86 00:39 EDT from hpfclp!diamant@hplabs.HP.COM,
             <[G.BBN.COM]23-Jul-86 02:30:50.NGALL>,
             <860723130828.1.DCP@FIREBIRD.SCRC.Symbolics.COM>,
             <860723132120.2.DCP@FIREBIRD.SCRC.Symbolics.COM>,
             <860723142439.9.MILLER@UR-CASHEW.ARPA>,
             The message of 23 Jul 86 15:30 EDT from "BACH::VANROGGEN" <vanroggen%bach.decnet@hudson.dec.com>,
             <8607232003.AA00325@tekchips.TEK>,
             <860724141621.4.DCP@FIREBIRD.SCRC.Symbolics.COM>,
             <FAHLMAN.12225382154.BABYL@C.CS.CMU.EDU>,
             <FAHLMAN.12225383753.BABYL@C.CS.CMU.EDU>,
             <8607251827.AA05634@utah-orion.ARPA>,
             <860725150616.3.GLS@IGNATIUS.THINK.COM>,
             <860726135509.3.DLW@CHICOPEE.SCRC.Symbolics.COM>,
             <FAHLMAN.12225834449.BABYL@C.CS.CMU.EDU>,
             <860726171228.4.DLW@CHICOPEE.SCRC.Symbolics.COM>,
             <FAHLMAN.12225845128.BABYL@C.CS.CMU.EDU>,
             The message of 26 Jul 86 18:38 EDT from SCOTT <SAFIER%cgi.csnet@CSNET-RELAY.ARPA>,
             <8607262326.AA01397@utah-orion.ARPA>,
             <FAHLMAN.12225931299.BABYL@C.CS.CMU.EDU>,
             <FAHLMAN.12226167028.BABYL@C.CS.CMU.EDU>
Message-ID: <860728215406.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 25 Jul 86 15:06 EDT
    From: Guy Steele <gls@Think.COM>

    I think the lesson here is that, in general, you shouldn't ever clobber
    a CONS if you don't know where it has been.  Certain CL primitives do
    guarantee to cons up fresh lists, and you can safely clobber their
    results.  Everything else you ought to be careful with, and that
    includes &rest arguments, the results of PARSE-BODY, the results of FOO,
    and so on.  Unless a function or other construct is clearly documented
    to indicate that it is okay to clobber its result, then you should avoid
    doing so.

I agree so strongly with the above statement that I'm going to waste
hundreds of people's time by including it in my message so that they
have to read it again.  The negation of this statement is practically
the definition of poor programming practice.

    Date: Tue, 22 Jul 86 21:39:37 pdt
    From: hpfclp!diamant@hplabs.HP.COM

    ....it better be clear that the
    list returned may not be something which will go away on exiting the
    function (which could happen if the parameter list were stored on the
    stack and a pointer to that list was returned -- apparently what
    Symbolics does).

Symbolics has always agreed that this aspect of our implementation is
not in conformance with Common Lisp, and have said so in our
documentation.  We just haven't gotten around to fixing the bug yet, for
engineering reasons that I won't bore you by expounding.  No one should
think that we oppose Diamant's statement above.

    Date: Sun, 27 Jul 1986  23:01 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    13A: Specify that the &REST or &BODY argument to a macro may be the very
    list from the macro call, and not a copy.  Therefore, if this argument
    is destructively modified, the originl text of the macro may also be
    altered.

Agreed.  Make sure the word is "might", not "must", where you now use
the ambiguous word "may" in two places.

Vanroggen brought up &WHOLE.  The manual already implies that the &WHOLE
argument is required to be the original form, and not a copy, but this
should be made more explicit.  Is this big enough to be a separate issue?

    13B: Specify explicitly that the &REST argument in a function has
    indefinite extent and may, for example, be returned to the function's
    caller.

Agreed.

    13C: The &REST list in a function is not necessarily a freshly-consed
    list.  If the function is called with APPLY, the &REST list may share
    top-level structure with the last argument to the APPLY.  Users should
    keep this in mind if they are considering destructive modifications to
    such a list.

Agreed, but the wording should be changed to say that an &REST argument
might share structure with something else regardless of how the function
was called, and simply use APPLY as an example.  There is no reason to
put extra restrictions on the implementation here.

    - OR -

    13C': The &REST list in a function is freshly consed upon function entry.
    It shares no top-level structure with any pre-existing list.

It's a bad idea to base the language specification on the idiosyncracies
of a particular implementation.

∂29-Jul-86  0644	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Re: Proposal about lambda-list params   
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 29 Jul 86  06:43:26 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51852; Mon 28-Jul-86 21:58:19 EDT
Date: Mon, 28 Jul 86 21:58 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Proposal about lambda-list params
To: NGALL@G.BBN.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[G.BBN.COM]23-Jul-86 23:55:15.NGALL>
Message-ID: <860728215820.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 23 Jul 1986 23:55-EDT
    From: NGALL@G.BBN.COM

    The following thought just struck me.  If we change CL to outlaw
    things like (lambda (x x ...)...), then people who have been writing
    code like (lambda (ignore x ignore) (declare (ignore ignore))...)
    may be upset when their code breaks.

Since it "is an error", not "signals an error", those people are free to
criticize their compiler for wasting their time with worthless warnings
if it warns about this.  It seems clear enough that warning about duplicate
parameter names when the parameters are explicitly ignored does no one
any good.

∂29-Jul-86  0649	DCP@QUABBIN.SCRC.Symbolics.COM 	Proposal #5 status
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86  06:49:45 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25028; Tue 29-Jul-86 09:47:45 EDT
Date: Tue, 29 Jul 86 09:48 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Proposal #5 status
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
    David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12226431936.BABYL@C.CS.CMU.EDU>
Message-ID: <860729094823.0.DCP@FIREBIRD.SCRC.Symbolics.COM>

    Date: Mon, 28 Jul 1986  23:16 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

	    4. The macro-expansion for the first form in return value 3, if any.
	Why the macroexpansion of the first form of the body?  Why not the body
	with the first form possibly expanded?

    It saves a CONS.

As if macroexpansion doesn't cons up the wazoo?

    It saves a CONS.

What's a CONS among friends?

    It saves a CONS.

Let the GC take care of it.

    It saves a CONS.

Since when does saving a single CONS dictate language design?

	Why not toss in the kitchen sink?  It looks to me like
	design-by-committee disease is striking.

    Why is it always the guy who endlessly nit-picks every last unimportant
    detail who accuses others of design by committee?

If there isn't at least one nit-picking asshole (who unfortunately
doesn't read the 2 messages about etiquette burried in the middle of 30
messages before responding to half of the remaining 28), there is the
possibility that real issues won't be raised and that what some people
think are unimportant issues might turn out to be huge timebombs.

∂29-Jul-86  0652	NGALL@G.BBN.COM 	Re: Proposal about lambda-list params 
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86  06:52:40 PDT
Date: 29 Jul 1986 09:50-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Proposal about lambda-list params
From: NGALL@G.BBN.COM
To: Moon@SCRC-STONY-BROOK.ARPA
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]29-Jul-86 09:50:57.NGALL>
In-Reply-To: <860728215820.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

	
    Date: Mon, 28 Jul 86 21:58 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    
	Date: 23 Jul 1986 23:55-EDT
	From: NGALL@G.BBN.COM
    
	The following thought just struck me.  If we change CL to outlaw
	things like (lambda (x x ...)...), then people who have been writing
	code like (lambda (ignore x ignore) (declare (ignore ignore))...)
	may be upset when their code breaks.
    
    Since it "is an error", not "signals an error", those people are free to
    criticize their compiler for wasting their time with worthless warnings
    if it warns about this.  It seems clear enough that warning about duplicate
    parameter names when the parameters are explicitly ignored does no one
    any good.
    
But under some of the new declaration-semantics proposals, the ignore
decl. would apply to only one of the parameters, thus given

(lambda (x y x z x) (declare (ignore x))...)

a compiler should still warn (or signal an error) that two of the
parameters illegally share a name. [Perhaps this can be used as an
argument against the proposal that a decl only affect only one of the
identically named entities to which it refers.]

-- Nick

∂29-Jul-86  0658	DCP@QUABBIN.SCRC.Symbolics.COM 	Proposal #5 status
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86  06:56:42 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25036; Tue 29-Jul-86 09:54:51 EDT
Date: Tue, 29 Jul 86 09:55 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Proposal #5 status
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
    David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12226431936.BABYL@C.CS.CMU.EDU>
Message-ID: <860729095530.1.DCP@FIREBIRD.SCRC.Symbolics.COM>

    Date: Mon, 28 Jul 1986  23:16 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

As I pointed out in another message, the argument should be called
stop-parsing-on-string-p or something like that.  I gave examples that
the current definition of parse-body implies are errors.

FYI, The normal way things appear in the manual is
	{ declaration | doc-string }* 
and that is also the order I have seen it (declarations before
doc-string) in code at Symbolics.

	??  I assume somebody has convinced themselves that the ordering or
	separation of declares has no semantic meaning in CL?

    Yes, unless you have a counter-example.

I can't think of any, but I wanted to make sure somebody has convinced
themselves.

∂29-Jul-86  1123	DCP@QUABBIN.SCRC.Symbolics.COM 	Re: PARSE-BODY    
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86  10:23:59 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25110; Tue 29-Jul-86 11:54:38 EDT
Date: Tue, 29 Jul 86 11:55 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: PARSE-BODY
To: Masinter.pa@XEROX.COM, common-lisp@sail.stanford.edu
In-Reply-To: <860728-140217-2923@Xerox>
Message-ID: <860729115514.7.DCP@FIREBIRD.SCRC.Symbolics.COM>

    Date: 28 Jul 86 13:43 PDT
    From: Masinter.pa@Xerox.COM

    a) it is of little general utility
    Given the addition of &body variables for macros, I can think of no
    examples where I would want to directly call parse-body instead of just
    using the macro-expansion option. (I currently have lots of examples
    that call parse-body, but they're all in macros that could use the new
    &body options instead.)

(defmacro condition-bind (list &body body)
  (expand-condition-bind ''t list body))
(defmacro conditin-bind-if (predicate list &body body)
  (expand-condition-bind predicate list body))

Why should I be forced to destructure the body in the defmacro instead
of the common expansion routine?

∂29-Jul-86  1215	@SU-SCORE.ARPA,@REAGAN.AI.MIT.EDU:MLY@AI.AI.MIT.EDU 	Re: PARSE-BODY   
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 86  10:25:29 PDT
Received: from REAGAN.AI.MIT.EDU by SU-SCORE.ARPA with TCP; Tue 29 Jul 86 08:52:15-PDT
Received: from RICKY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 41068; Tue 29-Jul-86 11:55:55-EDT
Date: Tue, 29 Jul 86 11:54 EDT
From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
Subject: Re: PARSE-BODY
To: Masinter.pa@Xerox.COM, common-lisp@sail.stanford.edu
In-Reply-To: <860728-140217-2923@Xerox>
Message-ID: <860729115443.3.MLY@RICKY.AI.MIT.EDU>

    Date: 28 Jul 86 13:43 PDT
    From: Masinter.pa@Xerox.COM

    I am (now) opposed to adding  PARSE-BODY to the Common Lisp standard (as
    long as the parse-body option is added to the macro expansion argument
    list) for the following reasons:

    a) it is of little general utility
    Given the addition of &body variables for macros, I can think of no
    examples where I would want to directly call parse-body instead of just
    using the macro-expansion option. (I currently have lots of examples
    that call parse-body, but they're all in macros that could use the new
    &body options instead.)

I disagree; here's an example, of which I could provide many more:
[I named it extract-declarations in some code I wrote to avoid a possible
 conflict with anybody who had already implemented a function named PARSE-BODY]

(defmacro condition-case (form &rest clauses &environment environment)
  "Execute FORM with conditions handled according to CLAUSES.
Each element of CLAUSES specifies one or more condition names,
 and what to do if they are signalled.
 More specifically, each clause is a list:
    (<conditions> <arglist> . <body-forms...>)
  <conditions> is not evaluated, and should be either a condition name
   or a list of condition names to be handled.
  <arglist> is either a list of a single symbol specifying a variable
   to be bound to the condition being handled,
   or () meaning that the clause is not interested in the particular
   condition object.
  <body-forms> are evaluated if a condition specified by <conditions>
   is signalled.  The value of the last of the forms is returned from
   CONDITION-CASE in this case.
 The clauses are considered in order, as in TYPECASE.
If no clause is executed to handle a condition, the values of FORM are returned."
  #+lispm (declare (zwei:indentation 0 3 1 1))
  (flet ((lose (&rest format)
           (apply #'lisp:error "Error macro-expanding ~S: ~?"
		  'condition-case format)))
    (dolist (clause clauses)
      (cond ((not (consp clause))
             (lose "clauses must be lists: ~S" clause))
            ((not (or (null (cadr clause))
                      (and (consp (cadr clause))
                           (null (cdr (cadr clause)))
                           (symbolp (car (cadr clause))))))
             (lose "second element of a clause must be () or a list of a variable to bind: ~S"
		   clause))
            ;... other error checks...
            ))
    (let ((gensym (gensym)))
      `(block ,gensym
	 ;; this depends on the order in which condition-bind and condition-case
	 ;;  clauses are defined to be searched
	 (condition-bind
	   ;; I get a Gold Star for not using LOOP
	   (,@(mapcar #'(lambda (clause)
			  (multiple-value-bind (body decls)
			      (extract-declarations (cddr clause) environment)
			    `(,(car clause)
			      #'(lambda ,(or (cadr clause) (list gensym))
				  (declare
				    ,@(if (cadr clause) () `((ignore ,gensym)))
				    ,@decls)
				  #+symbolics
				    ,@(if (cadr clause) () (list gensym))
				  (return-from ,gensym
				    (progn ,@body))))))
		      clauses))
	   ,form)))))

If anything, I think that PARSE-BODY is more essential than the proposed
extensions to &BODY.  (I am not overly fond of the &body-extensions
because of their dissimilarity to other defmacro destructuring, but
acknowledge their usefulness)
    ----------------------------------------------------------------------
    b) it is controversial
    While every implementation will have SOMETHING like parse-body (if only
    to implement the handing of macro arguments) there seems to be little
    agreement on what its arguments might be or what values it might return.
    It would seem that every implementation wants something slightly
    different (e.g., it depends on whether you cache macro translations as
    for whether you want to save the macro translation & the work of
    obtaining it or recompute it.)

The `controversy' I think you will find is over rather minor (even stupid)
details.  (Like order arguments and returned values, and the stuff you
cite relating to Fahlman's 4th and 5th values)

I find your last argument (about macroexpansion efficiency) rather spurious.
    ----------------------------------------------------------------------
    c) it isn't very simple
    (This is isn't a simple argument to make, unfortunately.) The value of
    features is inversly proportional to the complexity of their interfaces.
    Functions that have a "process-it-this-way-p" arguments and "returns 3
    values, but maybe just the first" should be viewed with suspicion, that
    they don't represent the "true" interface to what is going on in the
    system. That is, "parse-body" is just a piece of some more complex
    processing of macros, arguments & bodies that is part of the language
    writers toolkit, that isn't very isolated. Motivating it (what's this
    for?) would be difficult without a lot more context.

Here's what I think is a pretty-much-adequate implementation (so much
for complexity!)

(defun extract-declarations (body &optional environment doc-string-valid-p)
  "Extract declarations and documentation string from BODY and return them.
The first value is what is left of BODY after any doc string and decls are
removed.  It is BODY missing some number of its initial elements.

The second value is the list of declarations found.
Each element of a DECLARE found in body is a declaration
and goes on this list.

The third value is the doc string found in BODY, if there was one.
However, doc strings are only processed if DOC-STRING-VALID-P is non-NIL."
  #+lmnil (declare (values body declarations doc-string))
  (let (form (doc nil) (decls ()))
    (loop
      ;; Macro-expand the form, but don't worry if we get an error.
      ;; In that case, we will not see it as a declaration,
      ;; it will get macroexpanded again, and generate a warning then.
      ;;>>  We can't use condition:condition-case since in this toy
      ;;>>  implementation MACROEXPAND probably doesn't signal `our' errors
      (setq form #+lmnil (si:condition-case ()
			     (macroexpand (car body) environment)
			   (si:error (return)))
	         #+lucid ;is buggy for (macroexpand '(declare)) [bugous?]
		 	 ;  Of course, this means we lose if DECLARE is
			 ;  lexically defined in ENVIRONMENT.
		         (if (and (consp (car body))
				  (eq (caar body) 'declare))
			     (car body)
			     ;; this is about as good as I could figure
			     ;;  out without sources or a disassembler
			     (let ((tem (lucid::with-error-trapping
					  (macroexpand (car body)
						       environment))))
			       (if (and (consp tem)
					(member (car tem)
						'(lisp:error lisp:cerror))
					(consp (cdr tem))
					(string= (cadr tem) "Error")
					(consp (cddr tem))
					(stringp (caddr tem))
					(consp (cdddr tem))
					(listp (cadddr tem)))
				   form
				   tem)))
	         ;; other implementations probably have some way to hack
		 ;;  ignore-errors
	         #-(or lmnil lucid)
		   (macroexpand (car body) environment)
		 )
      (cond ((and doc-string-valid-p
		  (stringp form))
		  ;; If the string is the last thing in the body,
		  ;; don't inhale it, since it needs to be the return value.
		  (or (cdr body) (return))
		  ;; We skip any number of strings, but use only the first.
		  (or doc (setq doc form)))
	    ((and (consp form) (eq (car form) 'declare))
	     ;; silently ignore badly-formed declare forms.  Probably should warn.
	     (let ((decl (remove-if-not #'consp (the list (cdr form)))))
	       ;; hack the DOCUMENTATION declaration specially
	       (let ((tem (assoc 'documentation decl)))
		 (when (and tem doc-string-valid-p)
		   (when (and (null doc)
			      (stringp (cadr tem)))
		     (setq doc (cadr tem)))
		   (setq decl (delete 'documentation decl :key #'car))))
	       (if decl
		   ;; We allow any number of DECLAREs, and process them all.
		   (setq decls (append decl decls)))))
	    (t (return)))
      (pop body))
    (values body decls doc)))

∂29-Jul-86  1218	Miller.pa@Xerox.COM 	Re: Proposal about lambda-list params  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Jul 86  11:41:19 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 29 JUL 86 11:38:09 PDT
Date: 29 Jul 86 11:37 PDT
From: Miller.pa@Xerox.COM
Subject: Re: Proposal about lambda-list params
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Mon, 28 Jul 86 21:58 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: NGALL@G.BBN.COM, common-lisp@SU-AI.ARPA
Message-ID: <860729-113809-3801@Xerox>

	Date: Mon, 28 Jul 86 21:58 EDT
	From: David A. Moon 

	    Date: 23 Jul 1986 23:55-EDT
	    From: NGALL@G.BBN.COM

	    The following thought just struck me.  If we change CL to outlaw
	    things like (lambda (x x ...)...), then people who have been
writing
	    code like (lambda (ignore x ignore) (declare (ignore ignore))...)
	    may be upset when their code breaks.

	Since it "is an error", not "signals an error", those people are free
to
	criticize their compiler for wasting their time with worthless warnings
	if it warns about this.  It seems clear enough that warning about
duplicate
	parameter names when the parameters are explicitly ignored does no one
	any good.

"it is an error" means that a correct compiler may generate arbitrary
and worthless code when it encounters this case.  If "(lambda (ignore x
ignore) (declare (ignore ignore))...)" is an error, then it may do worse
than break.  This should either be legal, specified to signal an error,
or at least specified that, if not caught, will be harmless (not one of
the error catagories I know of)

∂29-Jul-86  1219	DCP@QUABBIN.SCRC.Symbolics.COM 	Staus of proposals 10, 11, and 12
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86  10:34:11 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25108; Tue 29-Jul-86 11:49:59 EDT
Date: Tue, 29 Jul 86 11:50 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Staus of proposals 10, 11, and 12
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
    David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12226438578.BABYL@C.CS.CMU.EDU>
Message-ID: <860729115038.6.DCP@FIREBIRD.SCRC.Symbolics.COM>

    Date: Mon, 28 Jul 1986  23:53 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

	    Proposal #10: Forms That Allow Declarations

	I did question the need/usefullness of allowing declarations in
	MACROLET.  Nobody has responded and I still can't think of any.

    It would come as a nasty surprise to people if MACROLET were different
    from FLET and LABELS in this respect.

I'm not saying we shouldn't do it, I'm saying we should acknowledge we
don't know what to do with it yet.  There have been parts of the
Symbolics documentation that say "We think this is useful but haven't
figured out for what yet.  We encourage experimentation and reports of
its usage."  I may have thought of one usage:
	(macrolet ((print-them (list)
		     `(mapc #'print ,list)))
	  (declare (notinline mapc))
	  ...)
If anybody else believes this, perhaps it should be one of the examples?

∂29-Jul-86  1220	@MIT-LIVE-OAK.ARPA,@GOLD-HILL-ACORN.LCS.MIT.EDU:mike%gold-hill-acorn@MIT-LIVE-OAK.ARPA 	Re: Proposal #7 Status:  TYPE-SPECIFIER-P 
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 86  10:34:24 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 5930; 29 Jul 86 12:57:53-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 31206; Tue 29-Jul-86 12:50:36-EDT
Date: Tue, 29 Jul 86 12:47 EST
Sender: mike%gold-hill-acorn@mit-live-oak.arpa
To:  Masinter.pa@Xerox.COM
From: mike%gold-hill-acorn@mit-live-oak.arpa
Subject: Re: Proposal #7 Status:  TYPE-SPECIFIER-P 
cc: common-lisp@su-ai.arpa

    Date: 28 Jul 86  1301 PDT
    ......
    From:
    Subject: Re: Proposal #7 Status:  TYPE-SPECIFIER-P
    In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Sun,
     27 Jul 86 21:44 EDT
    ......    
    On some further thought,  TYPE-SPECIFIER-P is ambiguous in some cases
    where the argument is a symbol: 
    Suppose you have
    
    (deftype relatively-prime-to (n) `(satisfies (lambda (x) (= 1 (gcd x
    ,n)))))
    
    In this case, relatively-prime-to by itself is not "a valid type
    specifier". 
    (relatively-prime-to 10) is a valid type specifier, and
    (relatively-prime-to t) is not.

Your point about deftype can be looked at differently.
If I have a deftype, i.e., (deftype mod (n) ...) etc. then
"mod" is a parameterized type.

The polymorphic lambda calculus has abstraction and 
beta reduction defined for types, so following its example, the
type of "mod" might be (type-lambda (n) <type-expression in n>), where
type-lambda is the type abstraction.

In the light of this, (type-specifier-p 'relatively-prime-to) should
be true (independent of whether we add any type-abstraction notations to CL).

{ aside:: By the way, the polymorphic lambda calculus is fairly
interesting, so for those of you interested in fixing up the type
system, I suggest you look at it carefully.  If you want, send me
mail (NO NOT TO THE CL MAILING LIST!!) and I will send some
references. :-) }

Any attempt to make type-specifier-p tell you whether a type specifier 
specifies any real class of objects cannot work due to undecidability 
problems. What we want is a SYNTACTIC property.

    Is the intent "is this something I can hand to typep?" If so, it would
    be false for "relatively-prime-to". If the intent is "does this *name* a
    type-specifier" then we could allow it, but the usefulness of such a
    thing is unclear to me.

Note that (typep 'relatively-prime-to...) should be invalid, since 
'relatively-prime-to is not a type, but it IS a valid specifier.
Note, there are no objects of type (type-lambda (n) ...) since those
objects would be TYPES, not instances of types.
    
    .....
    
    d) of all of the proposals to consider, proposals to add new constructs
    should get much lower priority than those to clarify or standardize
    current constructs.

Amen.
I just think we should plan to revise the type system somewhat, instead of 
just adding features. I agree that this is fairly low priority, and in
the light of...
    e) there is another proposal (before the Object Oriented Programming
    committee in this case) which satisfies  at least part of the original
    requirement in a different way.

Most object-oriented stuff impacts the type system dramatically, so 
we should reexamine the type-system in light of object oriented extentions.

...mike beckerle
Gold Hill Computers

    



∂29-Jul-86  1255	RPG  	Yapper of the Month Club
To:   common-lisp@SAIL.STANFORD.EDU   

From May 14 through July 28 there were 690 messages to
Common-Lisp, around 9 a day. Here are the top message senders
with the number of messages sent during that period. There is
a fairly sharp break between these folks and the rest, with several
having 10 messages or so. 

132 Fahlman
 56 Plummer
 44 Gall
 30 Masinter
 27 Steele
 25 Moon
 24 Weinreb
 23 Pitman
 20 Loosemore
 18 Foderaro
 18 Beckerle (Mike@a)
 18 Shebs

Er, congratulations.

			-rpg-

∂29-Jul-86  1456	FAHLMAN@C.CS.CMU.EDU 	Proposed moratorium (clarification)   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 86  14:56:27 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 29 Jul 86 17:56:41-EDT
Date: Tue, 29 Jul 1986  17:56 EDT
Message-ID: <FAHLMAN.12226635848.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: Proposed moratorium (clarification)


At the end of my suggestion for a Lisp Conference moratorium on
technical mail, I said "this is only a suggestion, but I can't guarantee
that mail arriving during that itme will be read."  This was a feeble
attempt at a joke.  All mail will be read eventually.  I still think it
would be a good idea to ease up on the mail during this period, however.

Sometimes I get comedy and tragedy confused, I'm afraid.

-- Scott

∂29-Jul-86  1734	pyramid!bein@SUN.COM 	closing standard channels   
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 29 Jul 86  17:34:24 PDT
Received: from sun.uucp by sun.com (3.2/SMI-3.0)
	id AA14484; Tue, 29 Jul 86 17:34:11 PDT
Received: by sun.uucp (1.1/SMI-3.0)
	id AA12057; Tue, 29 Jul 86 17:34:55 PDT
Received: by pyramid (4.12/3.14)
	id AA02084; Tue, 29 Jul 86 17:10:26 pdt
Date: 29 Jul 1986 17:07-PDT
From: David Bein <pyramid!bein@SUN.COM>
Subject: closing standard channels
To: common-lisp@su-ai.ARPA
Message-Id: <523066026/bein@pyramid>

  I know this question may have been asked before..

  What seems to be the consensus on closing streams
like *terminal-io*,*standard-input*, etc? Should it
be an error to try to close them, should it be a
noop or what?

--David

∂29-Jul-86  1835	NGALL@G.BBN.COM 	Re: Proposal #9: Variable Name Conflicts   
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86  18:35:08 PDT
Date: 29 Jul 1986 21:33-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Proposal #9: Variable Name Conflicts
From: NGALL@G.BBN.COM
To: Moon@SCRC-STONY-BROOK.ARPA
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]29-Jul-86 21:33:23.NGALL>
In-Reply-To: <860728221058.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

	
    Date: Mon, 28 Jul 86 22:10 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    
	Date: Sun, 27 Jul 1986  22:02 EDT
	From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
    
	Proposal #9A:
    
	It is an error for two parameters (including supplied-p and &aux
	parameters) in the same lambda list to be represented by the same (EQ)
	symbol.  This also holds for parameters bound by LET, LET*, DO, DO*,
	FLET, LABELS, PROGV, MACROLET, MV-BIND, and PROG.
    
    There is no such thing as MV-BIND; I expect you meant MULTIPLE-VALUE-BIND.
    You forgot PROG*.  You omitted COMPILER-LET and PROGV, but I can't guess
    whether this was accidental or intentional.
    
I think I submitted this list of var. binding forms.  I abbreviated
MULTIPLE-VALUE to MV, sorry if it wasn't clear.  PROGV wasn't omitted
(see?).  The omission of compiler-let and prog* was accidental
(compiler-let wasn't in the list on page 154 (which was all I looked
at) and I guess I didn't see prog* under prog).

-- Nick

∂29-Jul-86  1848	NGALL@G.BBN.COM 	Re: Staus of proposals 10, 11, and 12 
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86  18:47:54 PDT
Date: 29 Jul 1986 21:47-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Staus of proposals 10, 11, and 12
From: NGALL@G.BBN.COM
To: Common-Lisp@SU-AI.ARPA
Cc: Fahlman@C.CS.CMU.EDU
Message-ID: <[G.BBN.COM]29-Jul-86 21:47:02.NGALL>
In-Reply-To: <860729115038.6.DCP@FIREBIRD.SCRC.Symbolics.COM>

	
    Date: Tue, 29 Jul 86 11:50 EDT
    From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
    
    I may have thought of one usage:
	    (macrolet ((print-them (list)
			 `(mapc #'print ,list)))
	      (declare (notinline mapc))
	      ...)
    If anybody else believes this, perhaps it should be one of the examples?

I don't believe it.  The stuff inside the backquoted list is not code,
it is data.  Here's a similar one that I believe:
(macrolet ((print-them (list)
             `(progn ,@(mapcar #'(lambda (item) `(print ',item))
                               list)))
  (declare (notinline mapcar))
  ...)
In this, the mapcar funcall form IS code.  Note that this still is not
a strong argument for decls in the body of a macrolet, since the decl
could have been put in the body of the print-them macro definition.
But I agree that we should allow decls in the body of a macrolet.

-- Nick

∂29-Jul-86  1854	FAHLMAN@C.CS.CMU.EDU 	Proposal #8: Clarifications to DEFCONSTANT 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 86  18:54:26 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 29 Jul 86 21:53:34-EDT
Date: Tue, 29 Jul 1986  21:53 EDT
Message-ID: <FAHLMAN.12226678969.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:   common-lisp@SU-AI.ARPA
Subject: Proposal #8: Clarifications to DEFCONSTANT
In-reply-to: Msg of 28 Jul 1986  20:57-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


        Clarify that it is not an error to issue a second DEFCONSTANT command
        for an existing constant iff the new value is EQL to the old one.

    Do you mean EQL or EQUAL?  Consider the example

      (defconstant error-message-69 "Le *terminal-io* n'est pas une pipe.")

    I don't see any good justification for reading and evaluating that form
    twice to be an error.

Well, we prohibit compilers from replacing a constant reference with
inline code that is merely EQUAL to the constant; it must be EQL.  This
was so that you could do things like

(defconstant terminator '(nil))

and then do EQL testing for instances of TERMINATOR.  Perhaps this is
bogus, but if we keep that, we can't allow users to redefine constants
to other values that are merely EQUAL, because it will break such code.

I am not sure if it is safe to detect that the new constant value is
EQUAL to the old one and, if so, to leave the old one in place.

-- Scott

∂29-Jul-86  1920	FAHLMAN@C.CS.CMU.EDU 	Proposal #9: Variable Name Conflicts  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 86  19:20:05 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 29 Jul 86 22:20:14-EDT
Date: Tue, 29 Jul 1986  22:20 EDT
Message-ID: <FAHLMAN.12226683825.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:   common-lisp@SU-AI.ARPA
Subject: Proposal #9: Variable Name Conflicts


    Although I favor 9A, I have to point out that Fahlman has used his power
    as moderator to make proposal 9B look bad.  Surely the real 9B would
    treat all of the sequential binding forms in a consistent way.

If I were to propose something along these lines, it would be to treat
all of the sequential binding forms (including LAMBDA/DEFUN) in a
consistent way.  I believe that Andy Freeman was the one who first
argued for what became 9B, and he specifically said that LAMBDA/DEFUN
should not allow multiple args of the same name.  He couldn't decide
about DO*.

If, in summarizing, I replace the opposition's proposals with something
I think is better, that's an abuse of power.  If I faithfully report
what was proposed when I know better, I'm making them look bad,
and that's also an abuse of power.  Oh, well.

-- Scott

∂30-Jul-86  0640	MASINTER.PA@Xerox.COM 	declarations in macrolet puzzle 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Jul 86  06:40:49 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 30 JUL 86 06:41:09 PDT
From: MASINTER.PA@Xerox.COM
Date: 30 Jul 86 6:40:17 PDT
Subject: declarations in macrolet puzzle
To: common-lisp@su-ai.ARPA
Message-ID: <860730-064109-1194@Xerox>

(macrolet ((specials () (specials) '(declare (special special-list ,@special-list))))
	(specials)
		   special-list))


since macros can expand into declarations
and bodies have to have macros expanded before declarations can be seen
yet macrolet macros are visible in the body then ...

∂30-Jul-86  0705	RAM@C.CS.CMU.EDU 	Declarations in MACROLET   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86  07:05:34 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Wed 30 Jul 86 10:06:00-EDT
Date: Wed, 30 Jul 1986  10:05 EDT
Message-ID: <RAM.12226812298.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: Declarations in MACROLET


    I don't think that it would be correct for a declaration at the
head of a macrolet to affect the bodies of any of the macros, since
the bodies of the macros are defined to be in the null environment.
The only use for declarations in this place would be to make pervasive
declarations which affect the body of the MACROLET.  Of course this
could be done by LOCALLY.

  Rob

∂30-Jul-86  1001	gls@Think.COM 	Motivation for PARSE-BODY
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 30 Jul 86  10:00:52 PDT
Received: from boethius by Godot.Think.COM via CHAOS; Wed, 30 Jul 86 13:00:36 edt
Date: Wed, 30 Jul 86 13:01 EDT
From: Guy Steele <gls@Think.COM>
Subject: Motivation for PARSE-BODY
To: Masinter.pa@Xerox.COM, common-lisp@sail.stanford.edu
Cc: gls@AQUINAS
In-Reply-To: <860728-140217-2923@Xerox>
Message-Id: <860730130117.1.GLS@BOETHIUS.THINK.COM>

Some of us, at least, use Lisp for the inventing of new embedded languages, and
one of the great things about Lisp is that is lets you get at various tools that
are used within the Lisp implementation itself (or were, at a time when a
particular paradigm was standard).  Examples of these are READ, PRINT, PROGV,
ASSOC, and PAIRLIS.  (You might not think of READ and PRINT as peculiarly part
of the interpreter, but consider how many language implementations have a very
complicated routine for reading and parsing programs but don't let the user get
at it?  Consider APL, for example, whose program editor is not invocable by user
programs.)

If I want to invent my own interpreter (and I often do), having PARSE-BODY around
would be very convenient.
--Guy

∂30-Jul-86  1049	Masinter.pa@Xerox.COM 	Re: Motivation for PARSE-BODY   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Jul 86  10:48:41 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 JUL 86 10:47:07 PDT
Date: 30 Jul 86 10:46 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Motivation for PARSE-BODY
In-reply-to: Guy Steele <gls@Think.COM>'s message of Wed, 30 Jul 86
 13:01 EDT
To: gls@Think.COM
cc: common-lisp@su-ai.ARPA
Message-ID: <860730-104707-1440@Xerox>

Guy,

I refer you to the compatibility note on pp 364-365 in a book written by
some random fellow, where there was a claim that "This design is an
attempt to make the reader as simple as possible to understand, use, and
implement." and "It is unnecessary, however, to cater to more complex
lexical analysis or parsing than that needed for Common Lisp."

Even if PARSE-BODY were as generally useful as, say, splicing reader
macros, the argument that it should be in Common Lisp because it >might
be convenient< for writers of embedded languages is a very weak one.

As has been pointed out, anyone who wants to write an embedded language
can write their own PARSE-BODY trivially relying only on MACROEXPAND and
a few CONSes and EQLs. Maybe we could even put PARSE-BODY it in the
(whatever-happened-to-the) yellow pages.

Just as Common Lisp doesn't provide built-in support for BNF parsing,
there's no reason to put something as awkward as parse-body into the
standard.

 

 

∂30-Jul-86  1137	gls@Think.COM 	Re: Proposal about lambda-list params   
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 30 Jul 86  11:37:03 PDT
Received: from boethius by Godot.Think.COM via CHAOS; Wed, 30 Jul 86 14:37:02 edt
Date: Wed, 30 Jul 86 14:37 EDT
From: Guy Steele <gls@Think.COM>
Subject: Re: Proposal about lambda-list params
To: NGALL@G.BBN.COM
Cc: common-lisp@SU-AI.ARPA, gls@AQUINAS
In-Reply-To: <[G.BBN.COM]29-Jul-86 09:50:57.NGALL>
Message-Id: <860730143746.5.GLS@BOETHIUS.THINK.COM>

    Date: 29 Jul 1986 09:50-EDT
    From: NGALL@G.BBN.COM
    ...
    But under some of the new declaration-semantics proposals, the ignore
    decl. would apply to only one of the parameters, thus given

    (lambda (x y x z x) (declare (ignore x))...)

    a compiler should still warn (or signal an error) that two of the
    parameters illegally share a name. ...

Maybe one should have to write
    (lambda (x y x z x) (declare (ignore x) (ignore x) (ignore x))...)
to suppress all warnings.

--Quux  :-)

∂30-Jul-86  1252	DCP@QUABBIN.SCRC.Symbolics.COM 	Proposal #5, or somewhere around there (rather long, constructive, and non-flaming(!))  
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 30 Jul 86  12:52:02 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25613; Wed 30-Jul-86 14:38:14 EDT
Date: Wed, 30 Jul 86 14:39 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Proposal #5, or somewhere around there (rather long, constructive, and non-flaming(!))
To: common-lisp@SU-AI.ARPA
Message-ID: <860730143900.6.DCP@FIREBIRD.SCRC.Symbolics.COM>

Alternate proposal that has a declarative syntax, and is probably a lot
more comprehensible.

  [ &DECLARATIONS declares-var [ &DOC-STRING doc-string-var ]] &BODY body-var

If somebody wants to call it &DOCUMENTATION-STRING, go ahead; CLtL
usuually abbreviates "documentation-string" it to "doc-string".

Full semantics:
 - Since &BODY can only be used in macros, these extensions may
   only be used in macros.
 - &DECLARATIONS may only appear if &BODY appears.
 - &DOC-STRING may only appear if &DECLARATIONS appears.
 - If any of these extensions appear, they appear in the order given, on
   the grounds that is the normal order found within code.  It probably
   makes parsing defmacro's lambda-list a bit easier, and uniformity
   will make code easier to understand by other than the author.
 - declares-var is a catenation of the declarations.  If the original
   body had
	(declare (ignore a))
	(declare (ignore b) (inline aref))
   then declares-var would get bound to
	((ignore a) (ignore b) (inline aref))
 - If &DOC-STRING is present, the first string of the unpruned body is
   the documentation string, and parsing/pruning stops with the second
   string, which is considered part of the implicit progn.  [The
   exception is a string that is the last form of the body, in that case
   it is part of the implicit and not a doc-string, just like now.]
 - If &DOC-STRING is not present, then the first string stops the
   parsing/pruning of body.  Any declares after a string are part of the
   implicit progn and "are an error".  Presumably the code that groks
   implicit progns will complain about the presence of declares.
 - body-var is the body without the declarations and/or doc-string, and
   also with the first form NOT macroexpanded, even though
   macroexpansion was necessary to search for declarations and
   doc-strings.  If the first form is a macro, it may get expanded
   again.  Tough, macros shouldn't have side effects.

I believe this nests correctly, as all the other defmacro destructuring
does.  [Example deleted because even the simplest one is 16 lines long.]

I am willing to endorse this; I more-or-less believe it.  I do not
believe the original
	&BODY body-var [something-var [something-else-var]]
because it is totally lacking in syntax and comprehensibility.

Aside #1: I personally think &KEY and &BODY are mutually exclusive
because of their semantics; more-so when we worry about the presence of
declarations and a doc-string.  This is because the semantics of a body
includes an implicit progn, whereas the semantics of keyword/values is of
markers and values.  For those that do want &KEY and &BODY at the same
time it is probably necessary to require that the &KEY parsing happens
after the declarations/doc-string pruning.

Aside #2: If we had a simply specified PARSE-BODY, the simple
implementation of the above would be
	(multiple-value-bind (declares-var doc-string-var body-var)
	    (parse-body original-body want-doc-string environment)
	  ...)
I think we should have a (simply specified) PARSE-BODY even if (some)
extension to &BODY is adopted.  The compiler and special-form groker
need them for the same reason users want them for defmacro.  I think
PARSE-BODY and an &BODY extension should look very similar to each
other.  I believe the ideas in this messages show such a similarity.

∂30-Jul-86  1259	berman@vaxa.isi.edu 	Conference    
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86  12:59:44 PDT
Received: by vaxa.isi.edu (4.12/4.7)
	id AA27427; Wed, 30 Jul 86 12:59:35 pdt
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8607301959.AA27427@vaxa.isi.edu>
Date: 30 Jul 1986 1259-PDT (Wednesday)
To: common-lisp@su-ai.arpa
Cc: 
Subject: Conference


Hi ya.  I just found out that I'm going to the conference to meet with some
developers and what-not.  So...I haven't been following the conference info
closely.  Could somebody please post the times/locations for the Common Lisp
specific events?

Thanks.

RB

∂30-Jul-86  1330	berman@vaxa.isi.edu 	Conference    
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86  13:29:25 PDT
Received: by vaxa.isi.edu (4.12/4.7)
	id AA27668; Wed, 30 Jul 86 13:29:14 pdt
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8607302029.AA27668@vaxa.isi.edu>
Date: 30 Jul 1986 1329-PDT (Wednesday)
To: common-lisp@su-ai.arpa
Subject: Conference


Hi ya.  I just found out that I'm going to the conference to meet with some
developers and what-not.  So...I haven't been following the conference info
closely.  Could somebody please post the times/locations for the Common Lisp
specific events?

Thanks.

RB

∂30-Jul-86  1339	FAHLMAN@C.CS.CMU.EDU 	Handout at Lisp Conference  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86  13:39:22 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 30 Jul 86 16:39:34-EDT
Date: Wed, 30 Jul 1986  16:39 EDT
Message-ID: <FAHLMAN.12226883945.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: Handout at Lisp Conference


We plan to hand out the following informational flier at the Lisp
Conference registration.  People who read it here won't have to take
one.  
---------------------------------------------------------------------------

          STATUS OF COMMON LISP STANDARDIZATION EFFORTS

Common Lisp is fast becoming a de facto standard for Lisp, especially in
the commercial world where the need for a standard, widely accepted Lisp
dialect has long been felt.  Almost all Lisp suppliers in the U.S. now
offer, or intend to offer, implementations of Common Lisp.  The language
is now available on most of the workstations and mainframes that are
used by the AI research community.  Several Japanese companies have also
been active in Common Lisp development, and a Japanese standardization
committee has been established.  Common Lisp is being used in Europe,
and the European efforts at Lisp standardization are taking Common Lisp
as one important input.

At a meeting in Boston in December, 1985, representatives from the
Common Lisp community agreed to form technical and steering committees
to work on Common Lisp standardization.  The technical committee is to
develop a detailed language specification for Common Lisp; the steering
committee is to work on the non-technical aspects of the standardization
process.  A group of people, including five key contributors to the
original Common Lisp design, was chosen to select the members for these
new committees; that task was completed in March of 1986.

The technical committee members are Alan Bawden, Daniel Bobrow, Richard
Gabriel, Martin Griss, David Moon, Jonathan Rees, Guy Steele, and Scott
Fahlman (chairman).  The steering committee members are Richard Gabriel,
John McCarthy, Ronald Ohlander, Stephen Squires, Guy Steele, and Robert
Mathis (chairman).  It is expected that some non-U.S.  members will be
added to both committees in the near future.  Both of these committees
are interim bodies that will be integrated into the normal standards
process, once that process is operating fully.

A formal proposal was made to X3, the accredited U.S. standards
committee for information processing systems, to establish a technical
committee for Common Lisp standardization.  This proposal was accepted;
the Common Lisp committee is called X3J13.  Plans are also being made
for the establishment of an international committee for Lisp
standardization under ISO.  The formation of an X3 technical committee
is the normal way for the U.S. to participate in ISO activities.

Most of the technical discussion on Common Lisp occurs on the ARPAnet
via the mailing list "common-lisp@@sail.stanford.edu", administered by
Richard Gabriel (rpg@@sail.stanford.edu).  A number of other networks
have mail gateways to the ARPAnet, making it possible for almost all
interested parties to participate in the technical discussions.
Electronic mail communication has been established with participants in
Japan and Europe.

The first meeting of X3J13, the U.S. Technical Committee for the
standardization of Lisp, will be Tuesday and Wednesday, September 23 and
24, 1986, in Washington, DC, at the headquarters of CBEMA, Suite 500,
311 First St, NW.  On Tuesday (23) the meeting will be from 10am to 5pm;
on Wednesday (24) the meeting will be from 9am to 3pm.  No special hotel
arrangements are being made.

Membership in X3 technical committees is open to all who actively
participate (attend meetings or correspond) and pay an annual service
fee (about $175).  US citizenship or residency is not required.  The
first meeting is important since policies and procedures for X3
technical committees will be discussed and specific plans for the Lisp
activity will be made.

Anyone interested in joining X3J13, and particularly anyone planning to
attend the first meeting, should contact the convenor for X3J13: Dr.
Robert Mathis, 9712 Ceralene Dr., Fairfax, VA 22032.  Phone: (703)
425-5923. Arpanet: mathis@@b.isi.edu.

∂30-Jul-86  1356	FREEMAN@SUMEX-AIM.ARPA 	Re: Proposal #9: Variable Name Conflicts 
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86  13:55:37 PDT
Date: Wed 30 Jul 86 13:51:18-PDT
From: Andy Freeman <FREEMAN@SUMEX-AIM.ARPA>
Subject: Re: Proposal #9: Variable Name Conflicts
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12226683825.BABYL@C.CS.CMU.EDU>
Message-ID: <12226886097.79.FREEMAN@SUMEX-AIM.ARPA>

Fahlman wrote:
    If I were to propose [something like let* can have repeated names],
    it would be to treat all of the sequential binding forms (including
    LAMBDA/DEFUN) in a consistent way.

Lambda and defun are not sequential binding forms; the order of
argument evaluation is irrelevant.  "Lambda and defun are sequential
binding forms because the arguments they are applied to are evaluated
sequentially" is the only interpretation of Fahlman's statement I
could think of.  I'm certain he had something else in mind; that's
much like Masinter's position which neither Fahlman nor I agree with.

I didn't think Fahlman's proposal 9B wording was unfair; some of his
"moderator's summary" wasn't as fair as it could have been.  There is
a reason for Proposal 9; it just doesn't apply to let* or do*.  (Under
Masinter's lambda model, all of 9 is wrong.)

Fahlman's concerns (about let* and do*) can be included as a warning
in the manual much like the *specials* *suggestion*.  That's a
compromise 9B that I could live with.

Declarations (at least non-specials) should be decided before Proposal
9.  I think pervasive declarations are a good idea and much more
important than 9A vs 9B.  If we settle on 9A, then that argues
(weakly) against pervasive declarations.  If we decide on pervasive
declarations, then 9A vs 9B goes on its merits.

-andy
-------

∂30-Jul-86  1400	jbarnett@nrtc 	Re:  Proposal #9 Status: Variable Name Conflicts  
Received: from NRTC.ARPA by SAIL.STANFORD.EDU with TCP; 30 Jul 86  13:58:08 PDT
Date:     Wed, 30 Jul 86 13:55:54 PDT
From:     Jeff Barnett <jbarnett@nrtc>
To:       common-lisp@SU-AI.ARPA
cc:       Fahlman@C.CS.CMU.EDU
Subject:  Re:  Proposal #9 Status: Variable Name Conflicts

It was assumed in this and a previous message that looking for duplicate
names in the variable-list argument of a PROGV is an N**2 operation.  Not
true.  In the first place, if the list is short N**2 is small.  In the
second place it can be done in N*log N time. To wit: (1) copy the list--
order n, (2) sort the list--order N*log N, and (3) search the ordered
list for adjacent duplicates--order N.

	Jeff

∂30-Jul-86  1418	FAHLMAN@C.CS.CMU.EDU 	Proposal #9: Variable Name Conflicts  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86  14:17:56 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 30 Jul 86 17:18:14-EDT
Date: Wed, 30 Jul 1986  17:18 EDT
Message-ID: <FAHLMAN.12226890971.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Andy Freeman <FREEMAN@SUMEX-AIM.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Proposal #9: Variable Name Conflicts
In-reply-to: Msg of 30 Jul 1986  16:51-EDT from Andy Freeman <FREEMAN at SUMEX-AIM.ARPA>


    Lambda and defun are not sequential binding forms; the order of
    argument evaluation is irrelevant.  "Lambda and defun are sequential
    binding forms because the arguments they are applied to are evaluated
    sequentially" is the only interpretation of Fahlman's statement I
    could think of.  I'm certain he had something else in mind; that's
    much like Masinter's position which neither Fahlman nor I agree with.

Well, DEFUN and LAMBDA are partly sequential-binding forms.  They
process defaults and &aux vars sequentially.  That's what I was
referring to.

-- Scott

∂30-Jul-86  1434	Gregor.pa@Xerox.COM 	Re: Motivation for PARSE-BODY
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Jul 86  14:34:34 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 JUL 86 14:29:22 PDT
Date: 30 Jul 86 14:28 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: Motivation for PARSE-BODY
In-reply-to: Masinter.pa's message of 30 Jul 86 10:46 PDT
To: Masinter.pa@Xerox.COM
cc: gls@Think.COM, common-lisp@su-ai.ARPA
Message-ID: <860730-142922-1699@Xerox>

    From: Masinter.pa

    Even if PARSE-BODY were as generally useful as, say, splicing reader
    macros, the argument that it should be in Common Lisp because it
>might
    be convenient< for writers of embedded languages is a very weak one.

Independent of this sub-debate, I think the example the was already
given (by MLY I think) of:

(defmacro foo (&body body) (foo-internal body nil))

(defmacro foo* (&body body) (foo-internal body t))

(defun foo-internal (body sequentialp)
  (multiple-value-bind (decls doc real-body) (parse-body body) ...)))

Is enough motivation for having PARSE-BODY.

∂30-Jul-86  1719	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Proposal #5 (aside) 
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 30 Jul 86  17:19:09 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 52899; Tue 29-Jul-86 22:46:42 EDT
Date: Tue, 29 Jul 86 22:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposal #5 (aside)
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>
Message-ID: <860729224641.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 21 Jul 1986  21:46 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    Proposal #5: PARSE-BODY
    ....PARSE-BODY may perform macro-expansion (using the given
    environment) in order to determine whether an initial macro-call expands
    into a DECLARE form or documentation string.

Since when can macros expand into documentation strings?

∂30-Jul-86  1720	KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	#5, #5A, #6, #7, #8, #9, #9A, #9B, #10, #11, #12, #13, #14   
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 30 Jul 86  17:20:01 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 52919; Wed 30-Jul-86 01:33:13 EDT
Date: Wed, 30 Jul 86 01:32 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: #5, #5A, #6, #7, #8, #9, #9A, #9B, #10, #11, #12, #13, #14
To: Fahlman@C.CS.CMU.EDU
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>
References: <FAHLMAN.12226116535.BABYL@C.CS.CMU.EDU>,
            <12226310687.19.LOOSEMORE@UTAH-20.ARPA>,
            The message of 25 Jul 86 00:30-EDT from Dave.Touretzky@A.CS.CMU.EDU,
            <860728202419.3.MOON@EUPHRATES.SCRC.Symbolics.COM>,
            <860728205756.7.MOON@EUPHRATES.SCRC.Symbolics.COM>,
            <860728212151.9.MOON@EUPHRATES.SCRC.Symbolics.COM>,
            <RAM.12224974495.BABYL@C.CS.CMU.EDU>
Message-ID: <860730013252.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Proposals #5, #5A: PARSE-BODY

 I think it's important to standardize on PARSE-BODY in some
 form, distinct from &BODY. Most people probably wouldn't need
 it, but those who did need it should -not- be encouraged to
 write their own.

 Don't call the argument DOCUMENTATION-ALLOWED-P. The issue 
 isn't whether a doc string is accepted, it's whether a string
 in that position should be assumed to be a doc string or 
 assumed to be a literal constant. (DEFUN FOO (X) "hi" X)
 would be a valid program even if there were no such thing
 as a doc string. Call the arg PARSE-DOCUMENTATION-P.

 The additional return values suggested in proposal 5A seem
 misguided to me. I prefer returning just body, declares,
 and doc in that order.

 I think the BODY should be a list of forms with the first
 form potentially macroexpanded since the pre-expanded form
 is easy to recover by doing something like:
   (CAR (LAST (LDIFF unparsed-body (CDR parsed-body)))) 
 Actually, though, the macro might have smashed the macro 
 call's argument list, perhaps not even leaving it in a
 semantically meaningful form, though more commonly just
 displacing the macro expansion in place. So claiming you
 were going to return an unexpanded form would be impossible
 to really do in the general case.

 Related questions: Is there anything in CLtL that specifies 
 that the "foo" in (LAMBDA FOO () "foo") has a body form of
 "foo" and not just a doc string of "foo" with a null body list?
 Is there anything that says whether 
    (LAMBDA (X) "foo" (DECLARE (IGNORE X))) 
 is well-formed or what it returns? Regardless of the answers 
 to these questions, having PARSE-BODY around would mean that
 individual users would not have to develop private heuristic 
 solutions.

 When everyone's done with this initial round of comments,
 I'd want to see a reworked proposal so that I could give
 a boolean vote.

Proposal #6: Parsing in &BODY

 I strongly lean toward the syntax I proposed. In addition to
 the issues of upward-compatibility with existing code and the
 argument about symmetry with &REST, it just involves less parens.
 
 Also, I'm inclined to agree with Sandra that &REST and &BODY
 need not be mutually exclusive. This would be properly consistent
 with the conjoined use of &REST and &KEY, and with the conjoined
 use of &WHOLE and other arguments.

Proposal #7: TYPE-SPECIFIER-P

 I agree with Moon that this should only be called TYPE-SPECIFIER-P
 if it were going to really predicate type expressions and not type
 symbols. I'm content to include only TYPE-NAME-P for now. The need
 for this comes up in my error proposal implementation in a situation
 where SYMBOLP ends up sufficing (modulo reduced error checking). I
 think TYPE-NAME-P is an important primitive to have.

Proposal #8:  Clarifications to DEFCONSTANT

 I concur with most of Moon's remarks here. Also, I think it's pretty 
 clear that EQUAL is an acceptable predicate since even in the case of
 (DEFCONSTANT FOO (LIST 'A 'B))
 where the person is obviously going to work to get something less
 EQL than
 (DEFCONSTANT FOO '(A B))
 would have gotten him, the compiler is under no contract to preserve
 that absence of sharing in the inlined code it outputs to binary files.

 Perhaps we should say explicitly that it is an error to side-effect
 a system constant, and permit systems to warn in compiled code about
 things like (SETF (CAR FOO) 3), to signal an error at runtime (eg, by
 putting such constants in read-only areas), etc.

 I would prefer that the warning about redefining a constant be
 refined to make the "is an error" part dependent on whether the programs
 have made assumptions about the value of the constant, not just whether
 they refer to the constant. eg, macros might have called functions which
 use the old value even if they do not themselves refer to the constant
 explicitly.

 I would also prefer that the warning about redefining constants refer
 not only to compiled code being invalidated but also to interpreted code.
 If particular implementations happen to not make assumptions about
 constants in interpreted code, that's ok but should not be part of any
 guarantee offered by CL. That way, implementations are not precluded from
 doing prelimary Scheme-style semantic analysis even in interpreted code.

Proposal #9, #9A, #9B: Variable Name Conflicts

 My feeling is that &AUX and LET* should not be subject to the variable
 name conflict rule. I agree with completely with Dave Touretzky's comment
 that "outlawing duplicate names in LET* promotes too shallow a notion of
 consistency:  one based on syntax rather than semantics."

 The case of DO* is interesting. Although superficially this seems similar 
 to DO in the same way as LET* is to LET, I think at a deeper level it is
 not quite as analagous. Could someone please explain to me what a repeated
 variable would mean? Would the second one be a side-effect at the same
 level or would it actually shadow something? If shadowed, is the shadowing
 magically undone when you get to stepping the variable or do both steps
 refer to the value of the second variable in the init column? Unless 
 someone can suggest a meaning for repeated variables in this context, I'd 
 suggest that repeated var names in DO* be made illegal even if it's allowed
 in &AUX and LET*.

 In my mind, there's no real basis for Masinter's claim that the 
 declaration issue needs to get involved here. If you have
  (DEFUN FOO (X &AUX (X (F X)) (X (G X))) (DECLARE (SPECIAL X)) (H X))
 and you're wondering which of F, G, and H will see the special X, I 
 think we should say arbitrarily -- only H. People should break up the &AUX
 into nested LET expressions with explicit declarations as appropriate if 
 they want otherwise. Ditto for LET*.

 I cannot agree to any of #9, #9A, or #9B.

Proposal #10: Forms That Allow Declarations

 I'd like to see declarations allowed in a LABELS or FLET. 

 I agree with those who've suggested that this would not be appropriate for
 MACROLET. Unlike FLET, LABELS, LET, etc. which introduce semantic terms,
 MACROLET introduces only syntactic terms. If DECLARE was ever needed 
 inside a MACROLET, it is probably just a coincidence and not a result 
 of the MACROLET.

Proposal #11: Contents of Tagbody

 I hate arbitrary little rules that say things like only symbols and 
 integers are allowed. The reason we can get away with tags at all 
 is that they're atoms and atoms can't have side-effects. I think all 
 atoms should be allowed here. I think we should just define the 
 predicate that gets used, and I think the predicate should be EQL. 
 Maybe someone will come up with a creative use of character objects 
 as tags. I see no reason to preclude that.

 I note that in your proposal 12, you say "... the same (EQL) tag ...", 
 and I put that forth as evidence that this is how people already like 
 to think about tag equivalence.

Proposal #12: Unique Names For Tags

 This seems non-controversial.

Proposal #13: Structure Sharing in Arguments

 In the case of &REST in macros, I see no reason to not simply say 
 that the argument list is -always- shared. Is there an argument for 
 why this might not always be possible? In the case of &BODY, it may 
 not be possible to do the sharing, so I'm willing to leave this 
 undefined and say it "is an error" to modify the list.

 For a function that takes &REST arguments, I would prefer that a copy
 always be made unless the interpreter or compiler can prove that it 
 won't be necessary. If we cannot agree to do that, then it must be 
 noted both that it "is an error" to modify such a list AND that it 
 is an error to pass such a list to someone else using APPLY and then 
 later modify it. eg,	(PROGN (APPLY #'FOO L) (SETF (CDR L) ...))
 may screw up state that FOO has encached for later use.

Proposal #14:  THE and VALUES

 I'm not happy with this form of the clarification. 

 I agree with Moon that the discussion of &keywords in the VALUES 
 declaration seems pretty out of place. We don't check number of return
 values or do &keyword-hacking on return values anywhere else so
 doing it here seems out of place.

 If we did keep it, though, I'd want (THE type form) to be equivalent 
 to (THE (VALUES type &REST T) form) and would want any use of 
 (VALUES ...) to mean that I expected exactly the indicated number
 of values.

 Others seem to be disagreeing, though, so it may be better to agree
 to think harder on the issue and for now not bother to try gratuitously 
 "clarifying" something we don't adequately understand.

∂30-Jul-86  1720	BSG@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Re: exit-to-system   
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 30 Jul 86  17:20:38 PDT
Received: from SORA.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 53172; Wed 30-Jul-86 12:12:39 EDT
Date: Wed, 30 Jul 86 12:12 EDT
From: Bernard S. Greenberg <BSG@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: exit-to-system
To: a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA,
    common-lisp@SU-AI.ARPA, gls%aquinas.think.com@CSNET-RELAY.ARPA,
    ida%u-tokyo.junet@CSNET-RELAY.ARPA
In-Reply-To: <8607290714.AA22657@ccut.u-tokyo.junet>
Message-ID: <860730121244.3.BSG@SORA.SCRC.Symbolics.COM>

    Date: Tue, 29 Jul 86 16:14:11+0900
    From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>

	    Date: Mon, 21 Jul 86 15:01 EDT
	    From: Guy Steele <gls%ZARATHUSTRA.THINK.COM@u-tokyo.junet>
	    Subject: Re: exit-to-system 
		...
	    Well, we do have ED, which is clearly a user-interface thing.
	    Here is a stab at defining QUIT:
        
	    QUIT					[Function]
        
	    This function is intended to terminate the running Lisp system in some
	    appropriate manner.     ... 
	    ...
	    --Guy
    I agree. The name QUIT sounds reasonable.

    ida@utokyo-relay.csnet
    -----

The name QUIT does not sound reasonable.  Quit what?  Is ease of typing
an issue, for something which is typed once per session and probably
appears once in even the largest subsystem?  EXIT-LISP sounds much
better.    I can easily (and have) had internal functions, and macros
called QUIT.  I don't think the name should be used up in this way.

∂30-Jul-86  1720	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Status of declare UNSPECIAL   
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 30 Jul 86  17:20:47 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 53212; Wed 30-Jul-86 12:27:06 EDT
Date: Wed, 30 Jul 86 12:26 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Status of declare UNSPECIAL
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: <860725110937.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-ID: <860730122659.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 25 Jul 86 11:09 EDT
    From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>

    For the record, I also remember that we decided explicitly not to have
    an "UNSPECAL" (whatever you call it) declaration, and I also don't
    remember why.  Unfortunately, I remember this discussing occurring
    during a physical meeting, but someone should poke into the old archives
    and see if there was any good reasoning that we should all know about.
    Otherwise, I agree that there should be such a declaration.

I don't remember either, but here is my guess.  Maclisp and Zetalisp 
declaration scoping follows essentially the rules proposed by Bawden, in
which all declarations are pervasive, and therefore they need UNSPECIAL.
Once you switch to the current Common Lisp rules, in which a binding
of a variable shadows a SPECIAL declaration of the same name in an outer
contour, and creates a lexical binding rather than a special binding, you
no longer need an UNSPECIAL declaration to get that lexical binding.

UNSPECIAL was probably removed because of the mistaken argument that
the above implies that UNSPECIAL is never needed.  It is still possible
to concoct more complicated situations where UNSPECIAL would not be a
no-op in the current Common Lisp rules, which I think all involve UNSPECIAL
applying to references rather than to a binding.  Also of course UNSPECIAL
is the only way to shadow a SPECIAL proclamation, but perhaps it was
considered undesirable to allow that.

Among the declaration types listed in chapter 9, the only ones that
cannot be turned off by another declaration are SPECIAL, IGNORE, and
DECLARATION.

I'm not taking a stand on whether UNSPECIAL should or should not be included
in the language, especially not until we have settled the scoping rules
for declarations, but I thought the above facts and conjectures might
be interesting.

∂30-Jul-86  2018	FAHLMAN@C.CS.CMU.EDU 	Proposal #5 (aside)    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86  20:17:40 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 30 Jul 86 23:17:51-EDT
Date: Wed, 30 Jul 1986  23:17 EDT
Message-ID: <FAHLMAN.12226956455.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:   common-lisp@SU-AI.ARPA
Subject: Proposal #5 (aside)
In-reply-to: Msg of 29 Jul 1986  22:46-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


    Since when can macros expand into documentation strings?

My reading of the manual on this point may be faulty or perhaps
"rabbinical", but here is what I think the book says:

On page 154, it says that it is permissible for a macro call to expand
into a declaration and be recognized as such, provided that the macro
call appears where a declaration may legitimately appear.

On page 67 it says that declarations may follow a doc string.

Suppose you have

(defun foo (...)
  (MACRO1 ...)
  (MACRO2 ...)
  ... more forms...)

Suppose MACRO1 expands into a string and MACRO2 expands into a DECLARE
form.  If we expand MACRO1 and get a string, I would say that this is
the documentation string and we should then expand MACRO2 to see if it
is a declaration, since it is in a place where a declaration may
legitimately appear.  That seems like the most reasonable interpretation
to me.  I agree that we could say that a string obtained from a leading
MACRO is not allowed to be a doc-string, in which case it is a body form
and we can stop looking for macros.

The book doesn't seem to come down on one side or the other.  Note,
however, that it is allowed to expand all the macros at defun time (some
implementations actually do this), and in that case my interpretation
would fall out automatically unless special care is taken to disallow
this.

-- Scott

∂31-Jul-86  0451	@MCC.COM,@HAL.MCC.DialNet.Symbolics.COM:Loeffler@[10.3.0.62] 	Re: exit-to-system
Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 31 Jul 86  04:51:49 PDT
Received: from HAL.MCC.DialNet.Symbolics.COM (HAL.CAD.MCC.COM.#Internet) by MCC.COM with TCP; Thu 31 Jul 86 06:52:37-CDT
Date: Thu, 31 Jul 86 06:51 CDT
From: David D. Loeffler <Loeffler@[10.3.0.62]>
Subject: Re: exit-to-system
To: common-lisp@SU-AI.ARPA
In-Reply-To: <860730121244.3.BSG@SORA.SCRC.Symbolics.COM>
Message-ID: <860731065106.0.LOEFFLER@HAL.MCC.DialNet.Symbolics.COM>
Reply-To: Loeffler@[10.3.0.62]
Postal-address: P.O. Box 200195, 9430 Research Blvd., Austin, TX 78720

    Date: Wed, 30 Jul 86 12:12 EDT
    From: Bernard S. Greenberg <BSG@STONY-BROOK.SCRC.Symbolics.COM>

    The name QUIT does not sound reasonable.  Quit what?  Is ease of typing
    an issue, for something which is typed once per session and probably
    appears once in even the largest subsystem?  EXIT-LISP sounds much
    better.    I can easily (and have) had internal functions, and macros
    called QUIT.  I don't think the name should be used up in this way.

I agree with Bernie on this one.  EXIT-LISP is better than QUIT.  I used
to work on a system that had  a very uniform command set and  QUIT meant
"exit" from almost every one of the subsystems.  Other system used EXIT.
If a programmer wants to  put an escape out  of lisp in their  code then
EXIT-LISP is the right thing.  Vendors may wish to incorporate their own
QUIT or EXIT functions  so that users  will know how  to get out  of the
interpreter.

  -- Dave

∂31-Jul-86  1143	alatto@cc5.bbn.com 	Re: #13, #14   
Received: from BBNCC5.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86  11:42:51 PDT
To: Kent M Pitman <KMP@scrc-stony-brook.ARPA>
cc: Common-Lisp@su-ai.ARPA
Subject: Re: #13, #14
In-reply-to: Your message of Wed, 30 Jul 86 01:32 EDT.
	     <860730013252.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
References: <FAHLMAN.12226116535.BABYL@C.CS.CMU.EDU>,
            <12226310687.19.LOOSEMORE@UTAH-20.ARPA>,
            The message of 25 Jul 86 00:30-EDT from Dave.Touretzky@A.CS.CMU.EDU,
            <860728202419.3.MOON@EUPHRATES.SCRC.Symbolics.COM>,
            <860728205756.7.MOON@EUPHRATES.SCRC.Symbolics.COM>,
            <860728212151.9.MOON@EUPHRATES.SCRC.Symbolics.COM>,
            <RAM.12224974495.BABYL@C.CS.CMU.EDU>
Date: 31 Jul 86 14:26:30 EDT (Thu)
From: Andy Latto <alatto@cc5.bbn.com>


Proposal #13: Structure Sharing in Arguments

	Kent says:

...
    For a function that takes &REST arguments, I would prefer that a copy
    always be made unless the interpreter or compiler can prove that it 
    won't be necessary. If we cannot agree to do that, then it must be 
    noted both that it "is an error" to modify such a list AND that it 
    is an error to pass such a list to someone else using APPLY and then 
    later modify it. eg,	(PROGN (APPLY #'FOO L) (SETF (CDR L) ...))
    may screw up state that FOO has encached for later use.

	I don't see why allowing the &rest list to be the same list that was
passed to apply requires any of the above suggestions about what "is an error".
Lisp functions are allowed to modify their arguments, or save them for
later use.  Proposal 13 says that APPLY, like NCONC, is such a function in
the case where the function being APPLYed does destructive operations on
its &rest argument. (apply #'rplacd args) and (apply #'foo args) both
modify their arguments if foo is a function that does destructive
operations on its &rest argument, and I don't see a big difference
between them. In general, if I write a function that destructively
modifies its arguments (or use an existing one, like NCONC), I
must be careful that no other part of the code assumes that the
structure I have modified will not change. If you use argument-modifing
functions recklessly, you will produce obscure, hard-to-find, bugs. This is
certainly true of normal arguments to functions, and I don't see why it
shouldn't be true of &rest arguments as well, particularly if it can make
some implementations more efficient.

	I also believe their should be some kind of &temp-rest lambda
list keyword that produces an &rest list with dynamic extent, but that's
a separate proposal that should be dealt with later.

Proposal #14:  THE and VALUES

	The purpose of THE is to give the compiler or interpreter
information on the type of the value(s) returned by the form, since
this may help produce more efficient code. Information on the
number of values reuturned can presumably be put to similar use.
It would be nice to have syntax to say either "These are the
types of the first two returned values, and I don't know the types
of any others, if any" or "Exactly two values will be returned, and here
are their types". (THE (VALUES type1 type2 &rest T)) and
(THE (VALUES type1 type2)) seems like as good a syntax as any
for expressing these two concepts.
	I have no strong feelings as to whether (THE type1) should
be equivalent to (THE (VALUES type1)) or (THE (VALUES type1 &rest T)).
	On the subject of VALUES, I noticed that Cltl says, on the
issue of checking the type of the value(s) returned by a form in a
THE special form, "Implementations are encouraged to make an explicit
error check when running interpretively" (P 163). It seems to me that this
check should be made if it is declared (optimize (safety 3) (speed 0)),
and should not be made if it is declared (optimize (safety 0) (speed 3)), regardless
of whether it is interpreted or compiled, and that the reference to the
interpreter should be removed.

							Andy Latto
							alatto@bbn.ARPA

∂31-Jul-86  1502	@QUABBIN.SCRC.Symbolics.COM:Zippy@TENEX.SCRC.Symbolics.COM 	Re: Staus of proposals 10, 11, and 12   
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86  14:59:57 PDT
Received: from CREEPER.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 26022; Thu 31-Jul-86 15:03:33 EDT
Date: Thu, 31 Jul 86 15:04 EDT
From: dcp@TENEX.SCRC.Symbolics.COM
Sender: Zippy@TENEX.SCRC.Symbolics.COM
Subject: Re: Staus of proposals 10, 11, and 12
To: NGALL@G.BBN.COM, Common-Lisp@SU-AI.ARPA
cc: Fahlman@C.CS.CMU.EDU
In-Reply-To: <[G.BBN.COM]29-Jul-86 21:47:02.NGALL>
Message-ID: <860731150441.4.LISP-MACHINE@CREEPER.SCRC.Symbolics.COM>

    Date: 29 Jul 1986 21:47-EDT
    From: NGALL@G.BBN.COM

	
	Date: Tue, 29 Jul 86 11:50 EDT
	From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
    
	I may have thought of one usage:
		(macrolet ((print-them (list)
			     `(mapc #'print ,list)))
		  (declare (notinline mapc))
		  ...)
	If anybody else believes this, perhaps it should be one of the examples?

    I don't believe it.  The stuff inside the backquoted list is not code,
    it is data.  Here's a similar one that I believe:
    (macrolet ((print-them (list)
		 `(progn ,@(mapcar #'(lambda (item) `(print ',item))
				   list)))
      (declare (notinline mapcar))
      ...)
    In this, the mapcar funcall form IS code.  
You misunderstand.  Declarations have a scoping for code that it sees.
My intention was that anybody who calls (print-them some-list) expands into
	(mapc #'print some-list)
and that the declaration forces MAPC to be open coded.  Your definition
has two differences from mine:  (1) Your declaration tries to affect the
expansion PROCESS (mine affects the processing of the expansion), and
(2) your contract is different than mine (mine takes a runtime list,
your's takes a compile time list).  To get (1), I claim your declaration
is in the wrong place.  It should have been 
    (macrolet ((print-them (list)
		 (declare (notinline mapcar))
		 `(progn ,@(mapcar #'(lambda (item) `(print ',item))
				   list))))
      ...)

					       Note that this still is not
    a strong argument for decls in the body of a macrolet, since the decl
    could have been put in the body of the print-them macro definition.
"must" not "could"
    But I agree that we should allow decls in the body of a macrolet.

∂31-Jul-86  1506	@QUABBIN.SCRC.Symbolics.COM:Zippy@TENEX.SCRC.Symbolics.COM 	Proposal #5 (aside) 
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86  15:06:43 PDT
Received: from CREEPER.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 26023; Thu 31-Jul-86 15:07:00 EDT
Date: Thu, 31 Jul 86 15:08 EDT
From: dcp@TENEX.SCRC.Symbolics.COM
Sender: Zippy@TENEX.SCRC.Symbolics.COM
Subject: Proposal #5 (aside)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
    common-lisp@SU-AI.ARPA
In-Reply-To: <860729224641.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860731150815.5.LISP-MACHINE@CREEPER.SCRC.Symbolics.COM>

    Date: Tue, 29 Jul 86 22:46 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	Date: Mon, 21 Jul 1986  21:46 EDT
	From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

	Proposal #5: PARSE-BODY
	....PARSE-BODY may perform macro-expansion (using the given
	environment) in order to determine whether an initial macro-call expands
	into a DECLARE form or documentation string.

    Since when can macros expand into documentation strings?

Sidestepping the issue of whether or not it is currently allowed, I see
no reason it shouldn't be allowed.  Consider a program-writing-program
that generates some code like
	(defun helper-function-259 (...args...)
	  (declare (safety 2) (speed 1))
	  (compute-documentation-string :safety 2 :speed 1
					:parent "helper-function"
					:contract "factor the number 259")
	  (declare (inline aref))
	  ...)

∂31-Jul-86  1514	hoey@nrl-aic 	Proposal #9: Fast testing in PROGV  
Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86  15:14:29 PDT
Date: Thu, 31 Jul 86 18:11:20 edt
From: Dan Hoey <hoey@nrl-aic>
Message-Id: <8607312211.AA13507@nrl-aic>
To: jbarnett@nrtc.ARPA, common-lisp@su-ai.ARPA
Subject: Proposal #9: Fast testing in PROGV

    From: Jeff Barnett <jbarnett@nrtc>

    It was assumed in this and a previous message that looking for
    duplicate names in the variable-list argument of a PROGV is an
    N**2 operation....  It can be done in N*log N time.

You can put a mark on the property lists of the variables
for a linear algorithm.

Dan

∂31-Jul-86  1533	@YUKON.SCRC.Symbolics.COM:Zippy@TENEX.SCRC.Symbolics.COM 	Re:  Proposal #9 Status: Variable Name Conflicts    
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86  15:33:39 PDT
Received: from CREEPER.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 66534; Thu 31-Jul-86 14:59:38 EDT
Date: Thu, 31 Jul 86 14:59 EDT
From: DCP@TENEX.SCRC.Symbolics.COM
Sender: Zippy@TENEX.SCRC.Symbolics.COM
Subject: Re:  Proposal #9 Status: Variable Name Conflicts
To: Common-Lisp@SU-AI.ARPA, Jeff Barnett <jbarnett@NRTC.ARPA>
In-Reply-To: The message of 30 Jul 86 16:55 EDT from Jeff Barnett <jbarnett@nrtc>
Message-ID: <860731145915.3.LISP-MACHINE@CREEPER.SCRC.Symbolics.COM>

    Date:     Wed, 30 Jul 86 13:55:54 PDT
    From:     Jeff Barnett <jbarnett@nrtc>

    It was assumed in this and a previous message that looking for duplicate
    names in the variable-list argument of a PROGV is an N**2 operation.  Not
    true.  In the first place, if the list is short N**2 is small.  In the
    second place it can be done in N*log N time. To wit: (1) copy the list--
    order n, (2) sort the list--order N*log N, and (3) search the ordered
    list for adjacent duplicates--order N.

Any implementation that did this would probably discourage users from
using PROGV because it would be costly (inefficient) to use.  copying
the list conses and takes time.  Sorting can potentially cons, may be
NlogN, but is quite expensive in the smaller cases.  PROGV has so real
and valid uses; it should be relatively inexpensive to use.

I think PROGV should be removed from the list of forms that check for
variable name conflicts.  I think variable name conflicts should be
detected by the compiler; not the runtime system.  I think the semantics
of PROGV are that the LAST symbol/value pair takes presedence in case
there is more than one pair for a given symbol.

∂31-Jul-86  1827	FAHLMAN@C.CS.CMU.EDU 	Proposal #9 Status: Variable Name Conflicts
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 86  18:27:15 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 31 Jul 86 21:27:32-EDT
Date: Thu, 31 Jul 1986  21:27 EDT
Message-ID: <FAHLMAN.12227198519.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: Proposal #9 Status: Variable Name Conflicts


In response to: DCP@TENEX.SCRC.Symbolics.COM

    I think PROGV should be removed from the list of forms that check for
    variable name conflicts.  I think variable name conflicts should be
    detected by the compiler; not the runtime system.  I think the semantics
    of PROGV are that the LAST symbol/value pair takes presedence in case
    there is more than one pair for a given symbol.

As I said in response to this question earlier, nobody is proposing a
"list of forms that CHECK FOR variable name conflicts".  There is a
proposal for forms in which the use of duplicate variable names "is an
error".  Not the same thing.

-- Scott

∂31-Jul-86  1848	FAHLMAN@C.CS.CMU.EDU 	What's going on?  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 86  18:47:32 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 31 Jul 86 21:47:43-EDT
Date: Thu, 31 Jul 1986  21:47 EDT
Message-ID: <FAHLMAN.12227202184.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: What's going on?


Several people have asked what became of the summaries I promised for
issue #14 and for the declaration scope stuff.

I have not sent these out yet.  It has become clear to me that the
discussion/decision process is not working at all well: the mail volume
is too high, the load on the moderator is MUCH too high, the rate of
progress is negligible, a lot of time is being wasted discussing issues
that don't really matter, and my efforts to improve all this have
antagonized a lot of people without solving any of the problems.

My top-level task right now is to discuss these problems with the
technical committee members and others to see if we can figure out some
procedural changes that will get things moving in useful directions with
less wear and tear on everyone.  Until we've decided how to proceed,
I won't be pushing too hard to make progress on specific technical
issues.

-- Scott

∂31-Jul-86  1943	NGALL@G.BBN.COM 	Re: declarations in macrolet puzzle   
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86  19:39:22 PDT
Date: 31 Jul 1986 22:39-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: declarations in macrolet puzzle
From: NGALL@G.BBN.COM
To: MASINTER.PA@XEROX.COM
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]31-Jul-86 22:39:13.NGALL>
In-Reply-To: <860730-064109-1194@Xerox>

	
    Date: 30 Jul 86 6:40:17 PDT
    From: MASINTER.PA@Xerox.COM
    
    (macrolet ((specials () (specials) '(declare (special special-list ,@special-list))))
	    (specials)
		       special-list))
    
     ...

The missing piece to your puzzle is that declarations are expanded
BEFORE any bindings take place (perhaps this should be stated
explicitly in CLtL).  Thus, the call to specials in the body of the
macrolet does NOT refer to the specials being bound in the head of
macrolet.  This is true, not only of bindings made by macrolet, but
also those made by let, flet, etc.

-- Nick

∂31-Jul-86  1949	NGALL@G.BBN.COM 	Re: Declarations in MACROLET
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86  19:49:05 PDT
Date: 31 Jul 1986 22:49-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Declarations in MACROLET
From: NGALL@G.BBN.COM
To: RAM@C.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]31-Jul-86 22:49:06.NGALL>
In-Reply-To: <RAM.12226812298.BABYL@C.CS.CMU.EDU>

	
    Date: Wed, 30 Jul 1986  10:05 EDT
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
    
    
	I don't think that it would be correct for a declaration at the
    head of a macrolet to affect the bodies of any of the macros, since
    the bodies of the macros are defined to be in the null environment.

You raise an interesting question:

(flet ((foo ()))
  (locally (declare (inline foo))
    (macrolet ((bar () (foo 1 2 3)))
      (foo)...)))

Currently, does the inline decl affect both calls to foo?  I can't
tell from CLtL.

-- Nick

∂31-Jul-86  2155	FAHLMAN@C.CS.CMU.EDU 	Japanese Subset Proposal    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 86  21:55:22 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 1 Aug 86 00:55:43-EDT
Date: Fri, 1 Aug 1986  00:55 EDT
Message-ID: <FAHLMAN.12227236417.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: Japanese Subset Proposal


Profesor Masayuki Ida, the chairman of the Common Lisp subcomittee of
JEIDA in Japan, has sent me a draft of a subset proposal that a number
of Japanese researchers have been working on.  He is interested in
discussing this with the U.S. Common Lisp community, and especially
those people interested in subsets.  The proposal is too long to send to
the whole Common-Lisp mailing list, so I have put it on C.CS.CMU.EDU
as file "prva:<slisp.standard>japan-core.txt".   Discussion of this
proposal should probably take place on the CL-SUBSET mailing list.

-- Scott

∂31-Jul-86  2211	KMP@YUKON.SCRC.Symbolics.COM 	Comments on DCP's revised &BODY proposal
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86  22:10:47 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 66811; Fri 1-Aug-86 00:45:01 EDT
Date: Fri, 1 Aug 86 00:44 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Comments on DCP's revised &BODY proposal
To: DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <860730143900.6.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-ID: <860801004440.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

I mostly like this variation of the &BODY proposal.

I would prefer the name &DOCUMENTATION. 

In fact, given that we have &ENV instead of &ENVIRONMENT, it might be more 
consistent to have a short names like &DOC and &DECLS. I'm won't champion
that very strongly, but I think it's worth pointing out both for the sake
of consistency and the sake of reducing indentation. By using &DOCUMENTATION
and &DECLARATIONS you're virtually assuring that things like:
(DEFUN SOMETHING (NAME BVL &DECLARATIONS DECLS &DOCUMENTATION DOC &BODY FORMS)
 ...)
will be pushing the right margin on an 80-column screen even given reasonably
concice choices of macro and variable names.

In the presence of displacing macros, I feel fairly strongly that we can't 
currently guarantee that the &BODY will contain unexpanded forms. My feeling
is that we should either guarantee that the expanded (rather than unexpanded)
form be returned if an expansion happened, or that we should be explicitly
vague. It would be very unwise to document something we couldn't reliably 
provide.

With regard to your aside about &KEY, I agree that &KEY and &BODY should be
exclusive. Alternatively, though, we could revise the description of &KEY to
do something useful. It comes up in the current error proposal that there
are a lot of forms with bodies that have leading keywords. ie,
   (name bvl :key1 :value1 :key2 :value2 ... . body)
The body is defined to start when the keyword pairs run out. Right now, these
have to be "manually" parsed. It would be amazingly convenient to be able to 
say
   (NAME BVL &KEY KEY1 KEY2 &BODY FORMS)
I'd be content for now to just leave this syntax undefined and let people
think about a proposal on this subject later, but my desire to have this 
work makes this it seem very desirable to at least just disallow the current
meaning to a coupled &BODY/&KEY configuration for the interim.

∂31-Jul-86  2229	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Proposal #5, or somewhere around there (rather long, constructive, and non-flaming(!))    
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 31 Jul 86  22:29:25 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 54292; Thu 31-Jul-86 17:01:24 EDT
Date: Thu, 31 Jul 86 17:01 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposal #5, or somewhere around there (rather long, constructive, and non-flaming(!))
To: common-lisp@SU-AI.ARPA
In-Reply-To: <860730143900.6.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-ID: <860731170132.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

I believe that Plummer's suggestion of adding &DECLARATIONS and &DOC-STRING
is superior to the previous two proposals for extensions to DEFMACRO for
parsing bodies.

I disagree with Plummer's suggestion that &KEY and &BODY are mutually
exclusive.  The semantics of &BODY is not an implicit progn; the only
semantics of &BODY involves code formatting and indentation (CLtL p.145).
I agree that &KEY and &DECLARATIONS are mutually exclusive.

∂31-Jul-86  2230	KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	QUIT  
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 31 Jul 86  22:29:23 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 54240; Thu 31-Jul-86 16:05:24 EDT
Date: Thu, 31 Jul 86 16:04 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: QUIT
To: Common-Lisp@SU-AI.ARPA
cc: KMP@SCRC-STONY-BROOK.ARPA
References: <860730121244.3.BSG@SORA.SCRC.Symbolics.COM>,
            <8607290714.AA22657@ccut.u-tokyo.junet>
Message-ID: <860731160402.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

I'm sorry, but I just will not support the idea of a single function QUIT
as is currently being discussed. If the problem were re-cast, it might be
soluble, but I believe the problem as I've seen it stated thus far is just
plain insoluble.

I base my criticisms on experience that I have from create a portable 
QUIT function for use in Macsyma internals. I created such a function
using various non-portable primitives provided by particular dialects
I was studying. As with the GC problem, I found that the idea seemed
superficially plausible but just didn't work out in practice. Here are
some of my observations and conclusions ...

 1. Where is control transfered?

    Of the implementations which primitively offer some variant of QUIT, 
    all that I know of are on partitioned address space machines  which
    have a basically tree-structured process system that offers a 
    distinguished superior (usually an exec) to which it is obvious that
    control should be transfered upon call to QUIT.
    
    Shared address space machines (ie, Lisp Machines) have the problem 
    that there is no tree of processes. All occupy an equal status and 
    there is no obvious process to which control should be returned.

 2. What is a process?
 
    On partitioned address space machines, each process typically 
    comes with its own "global" state. Killing a process means killing its
    "global" state. On shared address machines, killing the process will
    generally kill only its dynamic state, not its global state (which
    is generally intertwined with the global state of other processes).
    To kill its global state means killing the global state of sibling
    activities, which may be highly undesirable.

 3. Can the process be resumed?

    Even among partitioned address space machines, there is disagreement
    about whether exiting (to the exec) means that you can re-enter later.
 
 4. What does it mean for a process to be resumed?

    Presumably resuming leaves the global state intact. Does it restart
    the process or does the call to QUIT just return NIL?

 5. If a process is killed permanently, are the associated UNWIND-PROTECT
    cleanup forms guaranteed to run first?

Obviously, some of these issues cannot be answered by the Common-Lisp
committee.  They are architectural issues beyond the scope of the
language. If we standardize on any meaning for QUIT, however, it must be
guided by an understanding that people do not use linguistic primitives
in the absence of intent, and that we should not provide primitives
which do not allow the programmer to clearly specify some meaningful
intent.  In light of the questions I've raised above, I hope it's clear
that definitions like "Exits the Lisp system" do not make any intent
clear.

Here are some real-life scenarios that I see...

 1. If the intent was to exit, what if there was no place to go?
    On the 3600, the Lisp Listener doubles as an exec. It is the 
    standard place to which programmers return to give commands, 
    not a place to be returned from. Having a "user interface" 
    function named QUIT which was a no-op when typed to Lisp would 
    be very confusing. Having it randomly select another activity
    would be fairly useless. I feel that people don't interactively 
    ask to exit something unless they think there is an obvious 
    place to go.

 2. If the intent is to exit temporarily and the exit turns out to 
    be permanent, this can have remarkably drastic consequences. A 
    user of Macsyma would be phenomenally irritated if I offered a
    temporary-exit function and it ended up exiting permanently
    before s/he had a chance to save the MACSYMA's state.

 3. If the intent was to exit permanently and the program was 
    allowed to proceed, the effects of continuing could be very
    strange. I've found myself resorting to things like:
	(PROGN (QUIT)  ;Try a permanent exit
	       (...))  ;If we got here, the QUIT didn't work,
		       ;so try cleaning up enough to continue
    or even:
	(LOOP (QUIT))  ;Insist on a permanent exit!

 4. If the intent was to exit "lisp" permanently, destroying global
    state, I'd argue that it could not possibly have been the intent 
    of any portable program to really kill everything on the machine
    since those other things are beyond the scope of Common Lisp and
    not something that CL programs have any obvious way to reason 
    about.

    On the 3600, you can't opt to "start over" without taking the 
    Editor, Mail Reader, Peek, Telnet Windows, etc. with it. Some
    people here at Symbolics do all their work from the same Lisp for
    several weeks at a time, building up lots of state which they
    don't want thrown away casually. There is no "starting over" that
    is not synonymous with "cold booting". In the case of server
    machines, this would mean that file connections would be broken,
    mail would stop being delivered until the (sometimes long) cold
    boot sequence had run, etc. In fact, the boot sequence may not
    begin automatically just because I halt my machine. If I was
    dialing in from home, I might have to go to work to initialize 
    the system again.

    Some non-Lispms have an in-Lisp editor even though they have
    other processes which are separable. Perhaps some of those 
    users use that editor only for editing Lisp and are content to
    have the editor and the lisp go away as a unit because they do
    other text editing in an editor that doesn't go away with Lisp,
    but that's presumably a property of the user rather than the
    system. 

The real problem here is that there is no such thing as exiting in the
pure abstract. Exiting means to pass through an abstract boundary
between an abitrarily chosen inside and outside. In the CL spec, we have
remained intentionally silent on the issue of where that line is drawn
in order to accomodate both Lispm-based and conventional systems.  I
think that corollary to this silence is the fact that functions which
attempt to cross the boundary are ill-defined. Not only do some systems
draw the boundary in different places than others, but some
intentionally don't draw it at all.

I don't care whether the primitive is called QUIT, EXIT, EXIT-TO-SYSTEM,
or whatever. The names themselves are not the problem. I only care that
any names we choose have a very clear behavior and that I can reason
about at coding time, or that my programs can reason about at runtime
prior to actually invoking the primitive which actually attempts to exit.

I don't plan to seriously consider any proposal for a QUIT primitive
which does not carefully address these issues.

∂01-Aug-86  0357	hpfclp!hpfcjrd!diamant@hplabs.HP.COM 	Proposal #13: Structure Sharing in Arguments   
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 1 Aug 86  03:41:58 PDT
Received: by hplabs.HP.COM ; Fri, 1 Aug 86 03:40:43 pdt
Received: from hpfcjrd.UUCP; Thu, 31 Jul 86 23:49:27
Received: by hpfcjrd; Thu, 31 Jul 86 23:49:27 mdt
Date: Thu, 31 Jul 86 23:49:27 mdt
From: John Diamant <hpfcjrd!diamant@hplabs.HP.COM>
Return-Path: <hpfcjrd!diamant>
To: common-lisp@sail.stanford.edu
Subject: Proposal #13: Structure Sharing in Arguments

	Subject: #5, #5A, #6, #7, #8, #9, #9A, #9B, #10, #11, #12, #13, #14
	From: Kent M Pitman <hplabs!KMP@SCRC-STONY-BROOK.ARPA>
	
	Proposal #13: Structure Sharing in Arguments
	
	 In the case of &REST in macros, I see no reason to not simply say 
	 that the argument list is -always- shared. Is there an argument for 
	 why this might not always be possible? In the case of &BODY, it may 
	 not be possible to do the sharing, so I'm willing to leave this 
	 undefined and say it "is an error" to modify the list.
	
A language specification has no business specifying implementation details.
Requiring that the list be shared is an efficiency requirement, not a
language specification.  I agree with the warning that the list may be
shared, but I certainly wouldn't require it!

	John

∂01-Aug-86  0536	DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Proposal #9: Fast testing in PROGV  
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 1 Aug 86  05:36:48 PDT
Received: from CREEPER.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 54637; Fri 1-Aug-86 08:36:16 EDT
Date: Fri, 1 Aug 86 08:36 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Proposal #9: Fast testing in PROGV
To: Dan Hoey <hoey@NRL-AIC.ARPA>, jbarnett@NRTC.ARPA,
    common-lisp@SU-AI.ARPA
In-Reply-To: <8607312211.AA13507@nrl-aic>
Message-ID: <860801083615.2.DCP@CREEPER.SCRC.Symbolics.COM>

    Date: Thu, 31 Jul 86 18:11:20 edt
    From: Dan Hoey <hoey@nrl-aic>

	From: Jeff Barnett <jbarnett@nrtc>

	It was assumed in this and a previous message that looking for
	duplicate names in the variable-list argument of a PROGV is an
	N**2 operation....  It can be done in N*log N time.

    You can put a mark on the property lists of the variables
    for a linear algorithm.

Nit: no you can't.  Putting a mark on a property list takes linear time
(length of the property list to see if it is already there), and you
have to do this for N variables.  So you are back to N↑2 again, and you
are likely consing, and misusing property lists, and...


∂01-Aug-86  0955	hoey@nrl-aic 	Proposal #9: Fast testing in PROGV  
Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 1 Aug 86  09:55:22 PDT
Date: 1 Aug 1986 12:31:26 EDT (Fri)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Proposal #9: Fast testing in PROGV
To: David C. Plummer <DCP@scrc-QUABBIN.ARPA>
Cc: jbarnett@NRTC.ARPA, common-lisp@SU-AI.ARPA
Message-Id: <523297888/hoey@nrl-aic>

    Date: Fri, 1 Aug 86 08:36 EDT
    From: David C. Plummer <DCP@scrc-QUABBIN.arpa>

        From: Dan Hoey <hoey@nrl-aic>

	    From: Jeff Barnett <jbarnett@nrtc>

	    ...looking for duplicate names in the variable-list argument
	    of a PROGV ... can be done in N*log N time.
   
        You can put a mark on the property lists of the variables
        for a linear algorithm.
    
    Nit: no you can't.

Antinit: Sure you can.

    Putting a mark on a property list takes linear time
    (length of the property list to see if it is already there)

I had in mind putting a GENSYMmed on the front of the property list and
only testing for it there.  (Nit me no nits about multiple processes
until they're in CLtL.)

    and you have to do this for N variables.  So you are back to
    N↑2 again,

Nit: That's N E(L), for L the length of a property list.

    and you are likely consing,

My PROGV checker would keep all its conses for use the next time.

    and misusing property lists,

I would spend the extra CONS to keep the plists legal.

    and...

if there is further discussion, we can do it between ourselves.  Anyone
out there who wants to write a PROGV checker should check with David or
me for the latest in variable uniqueness theory.

Dan

∂01-Aug-86  0956	gls@Think.COM 	Proposal #9: Fast testing in PROGV 
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 1 Aug 86  09:55:41 PDT
Received: from thorlac by Godot.Think.COM via CHAOS; Fri, 1 Aug 86 12:55:36 edt
Date: Fri, 1 Aug 86 12:56 EDT
From: Guy Steele <gls@Think.COM>
Subject: Proposal #9: Fast testing in PROGV
To: DCP@QUABBIN.SCRC.Symbolics.COM, hoey@NRL-AIC.ARPA, jbarnett@NRTC.ARPA,
        common-lisp@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <860801083615.2.DCP@CREEPER.SCRC.Symbolics.COM>
Message-Id: <860801125635.6.GLS@THORLAC.THINK.COM>
Moon: 3 days, 19 hours, 20 minutes since the last quarter of the moon.

    Date: Fri, 1 Aug 86 08:36 EDT
    From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
			Putting a mark on a property list takes linear time
    (length of the property list to see if it is already there), and you
    have to do this for N variables.  So you are back to N↑2 again, and you
    are likely consing, and misusing property lists, and...

Barf!  Who says you have to search the entire property list?  One of the
reasons we are having such an explosion of mail is that many people are
failing to think for more than three seconds before shooting from the hip.

(defun does-a-list-of-symbols-contain-duplicates-p (symbols)
  (let ((unique (list 'foo)))
    (unwind-protect
	(dolist (s symbols)
	  (when (eq (car (symbol-plist s)) unique)
	    (return-from does-a-list-of-symbols-contain-duplicates-p t))
	  (setf (symbol-plist s) (list* unique t (symbol-plist s))))
      (dolist (s symbols)
	(if (eq (car (symbol-plist s)) unique)
	    (setf (symbol-plist s) (cddr (symbol-plist s)))
	    (return))))
    nil))

Looks like linear time to me.  (Historical note: the implementation of
SUBLIS in MacLisp used to pull a similar trick.)

--Guy

∂01-Aug-86  1533	Hadden.CSCES@HI-MULTICS.ARPA 	Re: Proposal #9 Status: Variable Name Conflicts   
Received: from HI-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 1 Aug 86  15:32:44 PDT
Acknowledge-To:  Hadden@HI-MULTICS.ARPA
Date:  Fri, 1 Aug 86 09:46 CDT
From:  Hadden@HI-MULTICS.ARPA
Subject:  Re: Proposal #9 Status: Variable Name Conflicts
To:  Jeff Barnett <jbarnett@NRTC.ARPA>
cc:  common-lisp@SU-AI.ARPA
In-Reply-To:  Message of 30 Jul 86 15:55 CDT from "Jeff Barnett"
Message-ID:  <860801144651.291022@HI-MULTICS.ARPA>

actually, i think it can be done in order N.  the idea is to scan down
the list checking each symbol's property list for a flag.  if it's not
there, put it there; if it is, you've already seen it.  the following
(untested) code may give you the idea:

(defun dup-p (arg-list)
  (do ((l arg-list (cdr l))
       (foo (gensym)))
      ((null l) (mapc #'(lambda (x) (remprop x foo)) arg-list) nil)
    (if (get (car l) foo)
        (progn (mapc #'(lambda (x) (remprop x foo)) arg-list)
               (return t))
        (setf (get (car l) foo) t))))

-geo

∂04-Aug-86  1300	Dan@Think.COM 	ignore this message 
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 4 Aug 86  12:59:56 PDT
Received: from epicurus by Godot.Think.COM via CHAOS; Mon, 4 Aug 86 16:00:15 edt
Date: Mon, 4 Aug 86 16:00 EDT
From: Dan Aronson <Dan@Think.COM>
Subject: ignore this message
To: common-lisp@SU-AI.ARPA
Message-Id: <860804160059.2.DAN@EPICURUS.THINK.COM>

Please ignore this test of our local mailing list.

--dan

∂05-Aug-86  0908	pyramid!bein@hplabs.HP.COM 	synonym streams..
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 5 Aug 86  09:08:39 PDT
Received: by hplabs.HP.COM ; Tue, 5 Aug 86 09:07:35 pdt
Received: by pyramid (5.51/3.14)
	id AA16356; Tue, 5 Aug 86 09:06:34 PDT
Date: 5 Aug 1986 09:05-PDT
From: David Bein <pyramid!bein@hplabs.HP.COM>
Subject: synonym streams..
To: common-lisp@su-ai
Message-Id: <523641937/bein@pyramid>

Should a close on a synonym-stream merely close what it is
synonymous with or should it too be rendered useless
after the close (regardless of what happens to the underlying
stream -- see my last note re: standard streams) ??

--David

∂05-Aug-86  1111	Masinter.pa@Xerox.COM 	Re: synonym streams.. 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Aug 86  11:11:28 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 AUG 86 11:10:34 PDT
Date: 5 Aug 86 11:09 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: synonym streams..
In-reply-to: David Bein <pyramid!bein@hplabs.HP.COM>'s message of 5 Aug
 86 09:05 PDT
To: common-lisp@su-ai.ARPA
Message-ID: <860805-111034-2460@Xerox>

I propose the following rule: "It is an error to attempt to close a
stream that wasn't created with open."

With this rule, it would follow that, since synonym, broadcast and
two-way streams are not created with open,  it is an error to perform
"close" on them.

∂06-Aug-86  1100	@QUABBIN.SCRC.Symbolics.COM,@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	DPB, DPBS, something like that  
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 6 Aug 86  11:00:05 PDT
Received: from DIAMOND.S4CC.Symbolics.COM (DIAMOND.S4CC.Symbolics.COM) by QUABBIN.SCRC.Symbolics.COM via INTERNET with SMTP id 28119; 6 Aug 86 13:56:55 EDT
Received: from FIREBIRD.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 2592; Wed 6-Aug-86 10:32:11 EDT
Date: Wed, 6 Aug 86 10:31 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: DPB, DPBS, something like that
To: common-lisp@SU-AI.ARPA
Message-ID: <860806103157.4.DCP@FIREBIRD.S4CC.Symbolics.COM>

When writing system code especially, but sometimes when writing normal
code, I have often had to write long chains of DPBs, such as
	(dpb val1 spec1
	     (dpb val2 spec2
		  (dpb val3 spec3
		       ...)))
This (a) gets tedious and (b) looks bad.  I would either like to extend
DPB to take an odd number of arguments, or have a new function which
does.  (It probably wants to be a function rather than a macro.)  Thus,
	(dpb val1 spec1
	     val2 spec2
	     val3 spec3
	     ...
	     background-integer)
Have others had a need for this and would find this generally useful?


∂06-Aug-86  1724	@QUABBIN.SCRC.Symbolics.COM,@EUPHRATES.SCRC.Symbolics.COM:Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: synonym streams..    
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 6 Aug 86  17:24:05 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM (EUPHRATES.SCRC.Symbolics.COM) by QUABBIN.SCRC.Symbolics.COM via INTERNET with SMTP id 28297; 6 Aug 86 20:22:51 EDT
Date: Wed, 6 Aug 86 20:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: synonym streams..
To: common-lisp@SU-AI.ARPA
In-Reply-To: <860805-111034-2460@Xerox>
Message-ID: <860806202341.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 5 Aug 86 11:09 PDT
    From: Masinter.pa@Xerox.COM

    I propose the following rule: "It is an error to attempt to close a
    stream that wasn't created with open."

    With this rule, it would follow that, since synonym, broadcast and
    two-way streams are not created with open,  it is an error to perform
    "close" on them.

I think this is a fine suggestion.


∂06-Aug-86  1904	SOLEY@XX.LCS.MIT.EDU 	DPB, DPBS, something like that   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Aug 86  19:04:28 PDT
Date: Wed, 6 Aug 1986  22:09 EDT
Message-ID: <SOLEY.12228779029.BABYL@XX.LCS.MIT.EDU>
From: SOLEY@XX.LCS.MIT.EDU
To:   "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: DPB, DPBS, something like that
In-reply-to: Msg of 6 Aug 1986  10:31-EDT from David C. Plummer <DCP at QUABBIN.SCRC.Symbolics.COM>

    Date: Wednesday, 6 August 1986  10:31-EDT
    From: David C. Plummer <DCP at QUABBIN.SCRC.Symbolics.COM>
    To:   common-lisp at SU-AI.ARPA
    Re:   DPB, DPBS, something like that

    	(dpb val1 spec1 (dpb val2 spec2 (dpb val3 spec3 ... int)))
	==>
    	(dpb val1 spec1 val2 spec2 val3 spec3 ... int)

    Have others had a need for this and would find this generally useful?

I too have written this a million times.  It's an obvious
upward-compatible extension.

∂09-Aug-86  2041	mips!earl@glacier.stanford.edu 	:allow-other-keys query
Received: from GLACIER.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Aug 86  20:41:09 PDT
Received: by glacier.stanford.edu with Sendmail; Sat, 9 Aug 86 20:42:42 pdt
Received: from pachyderm.UUCP (pachyderm.ARPA) by mips.UUCP (4.12/4.7)
	id AA12969; Sat, 9 Aug 86 19:30:22 pdt
Received: by pachyderm.UUCP (4.12/4.7)
	id AA13610; Sat, 9 Aug 86 19:30:20 pdt
Date: Sat, 9 Aug 86 19:30:20 pdt
From: mips!earl@glacier.stanford.edu (Earl Killian)
Message-Id: <8608100230.AA13610@pachyderm.UUCP>
To: common-lisp@su-ai.ARPA
Subject: :allow-other-keys query

Given
	(defun bah (&key humbug)
	  ...)
which of the following are legal?
  1	(bah :allow-other-keys nil :other 'blah)
  2	(bah :allow-other-keys t :other 'blah)
  3	(bah :allow-other-keys nil)
Certainly 1 is in error and 2 is legal.  What about 3?  The way I read
the manual this is an error, which I don't think is the intent of this
feature.  Opinions?

∂09-Aug-86  2104	FAHLMAN@C.CS.CMU.EDU 	:allow-other-keys query
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Aug 86  21:04:42 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 10 Aug 86 00:04:09-EDT
Date: Sun, 10 Aug 1986  00:04 EDT
Message-ID: <FAHLMAN.12229586322.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   mips!earl@λglacier.stanford.edu (Earl Killian)λ
Cc:   common-lisp@SU-AI.ARPA
Subject: :allow-other-keys query
In-reply-to: Msg of 9 Aug 1986  22:30-EDT from mips!earl at glacier.stanford.edu (Earl Killian)


    Given
    	(defun bah (&key humbug)
    	  ...)
    which of the following are legal?
      1	(bah :allow-other-keys nil :other 'blah)
      2	(bah :allow-other-keys t :other 'blah)
      3	(bah :allow-other-keys nil)
    Certainly 1 is in error and 2 is legal.  What about 3?  The way I read
    the manual this is an error, which I don't think is the intent of this
    feature.  Opinions?

I agree with your analysis: a strict reading of the current wording of
the manual would suggest that case 3 is an error, but it would make more
sense if this were not treated as an error.

∂09-Aug-86  2320	Hvatum.DLAB@MIT-MULTICS.ARPA 	&rest destruction   
Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 9 Aug 86  23:20:36 PDT
Date:  Sun, 10 Aug 86 02:11 EDT
From:  Hvatum@MIT-MULTICS.ARPA
Subject:  &rest destruction
To:  common-lisp@SU-AI.ARPA
Message-ID:  <860810061145.560694@MIT-MULTICS.ARPA>

From: Steve Bacher (CSDL)
Subject: What's all this fuss about &rest destruction?

Having been watching while just about everyone on the CL mailing list
has argued about the &REST proposal, I have to jump in and make a point.
Many of you are now contending that there is no difference between
restricting the user from destroying a list passed as an argument to a
function and restricting the user from passing same list back as a
return value or storing it in "stable" storage (e.g. SETQ'ing some
global variable thereto).  I find it incredible that this idea should
be suddenly gaining concurrency.

Ever since LISP began (I realize this is a meaningless argument to most
Common LISPers)... or maybe I should say that scattered throughout
every LISP manual and certainly CLtL (though I can't quote any exact
references), it has been emphasized that the destructive operations
are DANGEROUS and should be used WITH CAUTION only by EXPERIENCED
LISP PROGRAMMERS.  It follows that if you are about to do something
that will destructively update a list, you'd better be damned sure
that nobody else is pointing to that list.  The only way to be certain
of this is (usually) if you create the list yourself out of fresh
conses (or if you get the list back from a function which you know has
created a list safe for destruction).

Conversely, I find it hard to accept the notion that Common LISP may
specify that some particular kind of argument to a function is
GUARANTEED to be freshly consed and therefore destructible.  Suppose you
have a function like

 (defun foo (a b &rest c) ...)

Why should I be guaranteed that the value bound to c will be
clobberable, when I am not given such a guarantee for a and b?
Perhaps your answer will be that functions should always do COPY-LIST on
any list arguments they pass to other functions, since those other
functions might wish to do NCONC or RPLACA on their args? :-)

On the other hand, NEVER in the history of any LISP that I know has
there been a rule that for some situation or other, the user may not
pass a given object back as a return value or store it somewhere
permanent.  Such a restriction is truly abhorrent and contrary to the
spirit of the language.  But it sure might make some compiler
implementors happy.  Imagine: the whole problem of upward funargs
could have been avoided so easily - just tell users that functions
may be passed as arguments, but they may not be returned as values or
assigned to global variables!  We might never had had to design all
those hairy mechanisms for saving environments in heap storage.

If the rationale behind this is that certain implementations
put their &REST args on the stack to save some conses, that's just too
bad.  (Should we support implementations that keep lexical closure
environments on the stack because it's just too hard to let users
pass lexical closures around as arguments?)  I agree with
Scott Fahlman's suggestion for an additional mechanism in the
language to provide for LEXPR'ish passing of varying numbers of args
on the stack as an alternative to consing &REST lists.

In short, there most definitely IS a qualitative distinction between
proscribing wanton clobbering of lists regardless of their origin
and limiting users' right to do with arguments what they please in
nondestructive ways.

                                          - Steve Bacher
                                            C.S.Draper Laboratory

≠

∂10-Aug-86  1205	FAHLMAN@C.CS.CMU.EDU 	&rest destruction 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Aug 86  12:05:22 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 10 Aug 86 15:05:34-EDT
Date: Sun, 10 Aug 1986  15:05 EDT
Message-ID: <FAHLMAN.12229750419.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: &rest destruction
In-reply-to: Msg of 10 Aug 1986  02:11-EDT from Hvatum at MIT-MULTICS.ARPA


    From: Steve Bacher (CSDL)
    Subject: What's all this fuss about &rest destruction?
    ...
    Conversely, I find it hard to accept the notion that Common LISP may
    specify that some particular kind of argument to a function is
    GUARANTEED to be freshly consed and therefore destructible.  Suppose you
    have a function like

     (defun foo (a b &rest c) ...)

    Why should I be guaranteed that the value bound to c will be
    clobberable, when I am not given such a guarantee for a and b?

The situation for A and B is not the same as for C.  The values for A
and B come direct from the caller.  In the case of a normal call to FOO,
the value passed in for C will be a list that is freshly consed at
runtime.  The only case in which C might not be freshly consed is if FOO
is called via APPLY.  Since calls via APPLY are relatively rare, the
question is whether we should require copying in this rare case (which
would allow users to assume that a rest arg is ALWAYS freshly-consed),
or whether we should warn the users that the &rest arg may have shared
top-level strucutre in some rare cases.

The issue of whether &rest args have indefinite extent is a separate
one, dragged in by some random comments by DCP.  It seems that everyone
agrees that Common Lisp currently requires &rest args to have indefinite
extent, and that this should not be changed.

-- Scott

∂10-Aug-86  1350	shebs%utah-orion@utah-cs.arpa 	TAGBODY vs LABELS  
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 10 Aug 86  13:50:10 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
	id AA23843; Sun, 10 Aug 86 14:50:42 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
	id AA00254; Sun, 10 Aug 86 14:50:39 MDT
Date: Sun, 10 Aug 86 14:50:39 MDT
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8608102050.AA00254@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: TAGBODY vs LABELS

I was in the process of implementing TAGBODY in terms of LABELS (each
piece of straightline code turns into a function, and GO turns into
function calls), but upon perusing CLtl more closely, I found that
the GO is apparently supposed to undo catchers, which wouldn't happen
if it becomes a function call...  Is this analysis correct?  If so,
then perhaps the standard deserves something a little stronger than
the phrase "can break up catchers if necessary to get to the target"
(middle of p. 131), which leaves me wondering what else GOs are supposed
to do to get to those elusive targets...

							stan

∂10-Aug-86  2132	RAM@C.CS.CMU.EDU 	TAGBODY vs LABELS
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Aug 86  21:32:09 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Mon 11 Aug 86 00:32:27-EDT
Date: Mon, 11 Aug 1986  00:32 EDT
Message-ID: <RAM.12229853616.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   shebs%utah-orion@λutah-cs.arpa (Stanley Shebs)λ
Cc:   common-lisp@SU-AI.ARPA
Subject: TAGBODY vs LABELS
In-reply-to: Msg of 10 Aug 1986  16:50-EDT from shebs%utah-orion at utah-cs.arpa (Stanley Shebs)


    GO has to do whatever is necessary in your implementation to get
out of whatever possible stuff that you wrap around the GO.  There are
no restrictions on where a GO may appear other than that it must
be lexically within the body of the TAGBODY and that it must be
evaluated within the dynamic context of the TAGBODY.

    It may be partly due to a lack of complete understanding of how
the LABELS hack works, but I believe that there isn't a
straightforward general conversion in Common Lisp.  In general, any
kind of dynamic state may have to be magically undone.  Consider the
example in p131 where the call to MAPCAR is aborted by a GO.  Special
bindings seem to cause similar problems.

  Rob

∂10-Aug-86  2327	masinter.PA@Xerox.COM 	tagbody using labels  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Aug 86  23:27:10 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 10 AUG 86 23:27:33 PDT
From: masinter.PA@Xerox.COM
Date: 10 Aug 86 23:26:24 PDT
Subject: tagbody using labels
To: ram@c.cs.cmu.edu
cc: common-lisp@su-ai.ARPA
Message-ID: <860810-232733-1239@Xerox>

GO requires no more magic than return-from.

This was an interesting puzzle. This definition doesn't handle go's from
inside an inner tagbody to an outer one, but I couldn't figure out how
to do that without introducing a compiler-let. 

(defmacro tagbody (&rest rest)
  (labels
   ((parse (tail &aux (rest (member-if #'atom (cdr tail))))
       (if tail (cons (cons (gensym) (ldiff tail rest)) (parse rest)))))
   (let ((name (gensym))
        (bodies (parse (cons (gensym) rest))))
    `(block ,name
      (macrolet ((go (tag)
                   `(return-from ,(car (find tag ',bodies :key 'cadr))
nil)))
        (labels
          ,(maplist
            #'(lambda (tail)
             `(,(caar tail) ()
                  ,@(reduce #'(lambda (body tag)
                                 `((block ,(car tag) ,@body)
                                   (return-from ,name (,(car tag)))))
                            bodies
                            :initial-value
                            `(,@(cddar tail)
                              ,(if (cdr tail)
                                  `(return-from ,(caadr tail) nil))))))
            bodies)
           (,(caar bodies))))))))


Larry
<:-)

∂11-Aug-86  0916	gls@Think.COM 	,',@ 
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 11 Aug 86  09:16:06 PDT
Received: from nymphodora by Godot.Think.COM via CHAOS; Mon, 11 Aug 86 12:15:53 edt
Date: Mon, 11 Aug 86 12:16 EDT
From: Guy Steele <gls@Think.COM>
Subject: ,',@
To: common-lisp@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <860801153243.3.ALAN@PIGPEN.AI.MIT.EDU>
Message-Id: <860811121629.4.GLS@NYMPHODORA.THINK.COM>

For the record, I was somewhat wedged in my last reply to Alan about
,',@ and I am now in full agreement with him on the technical issues.
--Guy

∂11-Aug-86  1120	gls@Think.COM 	tagbody using labels
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 11 Aug 86  11:19:35 PDT
Received: from nymphodora by Godot.Think.COM via CHAOS; Mon, 11 Aug 86 14:19:34 edt
Date: Mon, 11 Aug 86 14:20 EDT
From: Guy Steele <gls@Think.COM>
Subject: tagbody using labels
To: common-lisp@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <860810-232733-1239@Xerox>
Message-Id: <860811142008.3.GLS@NYMPHODORA.THINK.COM>

Utterly astonishing!  --Guy

∂11-Aug-86  2258	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	TAGBODY vs LABELS   
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 11 Aug 86  22:57:50 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 61106; Tue 12-Aug-86 01:56:40 EDT
Date: Tue, 12 Aug 86 01:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: TAGBODY vs LABELS
To: Stanley Shebs <shebs%utah-orion@UTAH-CS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8608102050.AA00254@utah-orion.ARPA>
Message-ID: <860812015648.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sun, 10 Aug 86 14:50:39 MDT
    From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)

    I was in the process of implementing TAGBODY in terms of LABELS (each
    piece of straightline code turns into a function, and GO turns into
    function calls), but upon perusing CLtl more closely, I found that
    the GO is apparently supposed to undo catchers, which wouldn't happen
    if it becomes a function call...  Is this analysis correct?  If so,
    then perhaps the standard deserves something a little stronger than
    the phrase "can break up catchers if necessary to get to the target"
    (middle of p. 131), which leaves me wondering what else GOs are supposed
    to do to get to those elusive targets...

Most people implement non-local GO in terms of THROW and local GO.

(tagbody (foo #'(lambda () (go a)))
         (baz)
       a (bar))
==>
(tagbody (case (catch g0001
		 (foo #'(lambda () (throw g0001 1)))
		 2)
	   (1 (go a))
	   (2 (baz)))
       a (bar))
or
(tagbody (catch g0001
	   (foo #'(lambda () (throw g0001 nil)))
	   (go g0002))
         (go a)
   g0002 (baz)
       a (bar))

where g0001 is bound to something dynamically unique (using
a gensym constant here won't work, you should easily be able
to construct a counterexample using recursive functions).

Regardless of your exact implementation, I think you'll find that cases
exist in which only an implementation of GO that uses THROW will work.

∂11-Aug-86  2307	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	:allow-other-keys query  
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 11 Aug 86  23:07:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 61108; Tue 12-Aug-86 02:05:59 EDT
Date: Tue, 12 Aug 86 02:06 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: :allow-other-keys query
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12229586322.BABYL@C.CS.CMU.EDU>
Message-ID: <860812020607.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sun, 10 Aug 1986  00:04 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

        From: earl
	Given
	    (defun bah (&key humbug)
	      ...)
	which of the following are legal?
	  1	(bah :allow-other-keys nil :other 'blah)
	  2	(bah :allow-other-keys t :other 'blah)
	  3	(bah :allow-other-keys nil)
	Certainly 1 is in error and 2 is legal.  What about 3?  The way I read
	the manual this is an error, which I don't think is the intent of this
	feature.  Opinions?

    I agree with your analysis: a strict reading of the current wording of
    the manual would suggest that case 3 is an error, but it would make more
    sense if this were not treated as an error.

Our implementation treated 3 as an error for a while, due to being misled
by the manual, and we decided that that was a bug.  I agree with Earl;
all &key functions accept :allow-other-keys, and the manual (pp.62-3)
should be clarified accordingly.

∂12-Aug-86  1246	snyder%hplsny@hplabs.HP.COM 	Re: Proposal #7 Status:  TYPE-SPECIFIER-P
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 12 Aug 86  12:46:07 PDT
Received: from hplsny by hplabs.HP.COM ; Tue, 12 Aug 86 12:45:21 pdt
Received: by hplsny ; Tue, 12 Aug 86 12:44:44 pdt
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
Message-Id: <8608121944.AA12075@hplsny>
Date: Tue, 12 Aug 86  12:43:53 PDT
Subject: Re: Proposal #7 Status:  TYPE-SPECIFIER-P
To: Masinter.pa@Xerox.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: common-lisp@su-ai.ARPA
In-Reply-To: Your message of 28-Jul-86  11:52:00
X-Mailer: NMail [$Revision: 2.5 $]

    Date: 28 Jul 86 11:52 PDT
    From: Masinter.pa@Xerox.COM

    c)  this is a request for a feature, but there's little evidence that
    there are significant, meaningful, portable uses for it. (Portable = a
    program written with one Common Lisp's version is likely to run with
    another Common Lisp's version.)
    
    e) there is another proposal (before the Object Oriented Programming
    committee in this case) which satisfies  at least part of the original
    requirement in a different way.
    
    Date: Mon, 28 Jul 86 20:24 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    I have no objection to either of TYPE-SPECIFIER-P or TYPE-NAME-P if
    someone can show why these are needed to fix something wrong with the
    language.  Perhaps Guy can comment on why the original proposal 51 in
    his clarifications list was tagged with an asterisk indicating that it
    corrects an important flaw or resolves an ambiguity in the
    specification.

I think the original request for this feature came from me, and the motivation
was in fact to allow the portable implementation of object-oriented
programming extensions.  If DEFCLASS defines a TYPE, then DEFCLASS needs some
way to tell if the specified class name is the name of an existing type, so
that it can issue some reasonable error message.  (Presumably, DEFCLASS knows
if the specified name is the name of an existing CLASS, but it doesn't know
about other types.)  TYPE-NAME-P is adequate for this purpose, although it
would look ugly to have TYPE-NAME-P in the language if we ever figured out
what TYPE-SPECIFIER-P should do (perhaps Guy's definition is adequate).

To the best of my knowledge, neither DEFTYPE nor DEFSTRUCT define what happens
if the specified type name names an existing type.  Defining their behavior in
this case might also solve the problem (if an error is signalled in all cases
of interest).  (Only the moderator is allowed to interpret this paragraph as
opening a new issue!)

  Alan
-------

∂13-Aug-86  1051	Moon@QUABBIN.SCRC.Symbolics.COM 	Proposal #7:  TYPE-SPECIFIER-P  
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 13 Aug 86  10:51:35 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 29452; Wed 13-Aug-86 13:40:34 EDT
Date: Wed, 13 Aug 86 13:41 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposal #7:  TYPE-SPECIFIER-P
To: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8608121944.AA12075@hplsny>
Message-ID: <860813134107.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 12 Aug 86  12:43:53 PDT
    From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>

    I think the original request for this feature came from me, and the motivation
    was in fact to allow the portable implementation of object-oriented
    programming extensions.  If DEFCLASS defines a TYPE, then DEFCLASS needs some
    way to tell if the specified class name is the name of an existing type, so
    that it can issue some reasonable error message.  (Presumably, DEFCLASS knows
    if the specified name is the name of an existing CLASS, but it doesn't know
    about other types.)  TYPE-NAME-P is adequate for this purpose, although it
    would look ugly to have TYPE-NAME-P in the language if we ever figured out
    what TYPE-SPECIFIER-P should do (perhaps Guy's definition is adequate).

    To the best of my knowledge, neither DEFTYPE nor DEFSTRUCT define what happens
    if the specified type name names an existing type.  Defining their behavior in
    this case might also solve the problem (if an error is signalled in all cases
    of interest).  (Only the moderator is allowed to interpret this paragraph as
    opening a new issue!)

I see.  Note that you should be allowed to re-evaluate "the same" DEFTYPE,
DEFSTRUCT, or DEFCLASS, but should get an error if you evaluate one that is
not "the same" but has the same name.  This seems like a programming
environment issue.  For example, in Symbolics' system "the same" is defined by
the name of the file containing the form, with all forms typed in from the
terminal assumed to be "the same" and not "the same as" any form that came
from a file.  I can easily imagine other programming environments where
"the same" would be defined in a very different way.

The problem with calling this a programming environment issue rather than a
language issue is that that doesn't make it go away, since the whole point was
that you want a portable way to define (or extend) the programming
environment.  I don't have any solutions to offer, but my opinion is that
one of TYPE-NAME-P or TYPE-SPECIFIER-P should exist, but DEFCLASS should not
need to call it.

∂13-Aug-86  2151	LOOSEMORE@UTAH-20.ARPA 	question about subtypep   
Received: from UTAH-20.ARPA by SAIL.STANFORD.EDU with TCP; 13 Aug 86  21:43:17 PDT
Date: Wed 13 Aug 86 22:43:11-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: question about subtypep
To: common-lisp@SU-AI.ARPA
Message-ID: <12230642017.7.LOOSEMORE@UTAH-20.ARPA>

On p. 35 of CLtL, it says that the type "array" may or may not be a
subtype of "common", depending on whether your implementation allows you
to make arrays that can only hold items of a type which isn't a subtype
of common.  Supposing the implementation has not made this extension, is
it acceptable for (subtypep 'array 'common) to return T?  Or is subtypep
only supposed to return T if the subtype relationship definitely holds
in *all* CL implementations?

-Sandra
-------

∂14-Aug-86  0353	RAM@C.CS.CMU.EDU 	question about subtypep    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 86  03:52:59 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 14 Aug 86 06:51:55-EDT
Date: Thu, 14 Aug 1986  06:51 EDT
Message-ID: <RAM.12230709127.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   SANDRA <LOOSEMORE@UTAH-20.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: question about subtypep
In-reply-to: Msg of 14 Aug 1986  00:43-EDT from SANDRA <LOOSEMORE at UTAH-20.ARPA>


    CLTL is pretty vague about what subtypep does.  My intpretation
(based on intensive meditation and reading of scripture) is that
SUBTYPEP returns information about the actual subtype relations in
your implementation.  Discrepencies will exist most often when an
implementation decides to fold potentially distinct types together.
For example, if all arrays are adjustable and have fill-pointers, then
SIMPLE-ARRAY is indentical to ARRAY, and therefore 
(SUBTYPEP 'ARRAY 'SIMPLE-ARRAY) is true.

    Note there are some possible users of SUBTYPEP that would prefer
answers to be based on some hypothetical maximally restrictive type
system.  The main example is a compiler which does compile-time type
checking when possible.  Although (THE SHORT-FLOAT 1F0) is quite legal
in an implementation in which SHORT-FLOAT and SINGLE-FLOAT are
identical, it would be reasonable for the compiler to give a warning
anyway.  Applications that care about this sort of thing will have to
use a variant version of subtypep that is distinct from the real
SUBTYPEP.

  Rob

∂14-Aug-86  0559	Hvatum.DLAB@MIT-MULTICS.ARPA 	&rest destruction   
Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 14 Aug 86  05:59:37 PDT
Date:  Thu, 14 Aug 86 08:57 EDT
From:  Hvatum@MIT-MULTICS.ARPA
Subject:  &rest destruction
To:  common-lisp@SU-AI.ARPA
Message-ID:  <860814125727.259238@MIT-MULTICS.ARPA>

 
From: Steve Bacher: CSDL
Subject: &rest destruction
 
I see one more potential case where the &rest args may be indestructible - a
possible compiler optimization where, given a function
 
  (defun foo (&rest x) ...)
 
and a call like
 
(foo 'bar 'baz 'frob)
 
the compiler may choose to pass an inline list '(BAR BAZ FROB) to save
on consing.  Guaranteed destructibility would merely enjoin the compiler
writer from generating this optimization, which would probably not be a
problem (although I wouldn't be too happy with such a restriction).
 
(There's one other useful case: if there's a function FROBOZZ,
say, that takes one &REST arg, the compiler should be able to take
 
   (apply #'frobozz some-list)
 
and compile it as a direct call to FROBOZZ, passing the list itself on
as is.  In some architectures this may be much more efficient, even
apart from the elimination of APPLY from the picture; there may be
an INTERNAL-FROBOZZ that takes a single list arg and does the same
thing, in which case the compiler could do a source transform on the
above.  Again, forced consing in this (possibly more frequent) case
could be detrimental.)
 
                                         - Steve
 
≠

∂14-Aug-86  1444	Pavel.pa@Xerox.COM 	More words on the scoping of declarations    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Aug 86  14:43:47 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 14 AUG 86 14:11:51 PDT
Date: 14 Aug 86 14:11 PDT
From: Pavel.pa@Xerox.COM
Subject: More words on the scoping of declarations
In-reply-to: NGALL@G.BBN.COM's message of 19 Jul 86 17:17 EDT
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860814-141151-4806@Xerox>

Having been gone for three weeks, I was unable to properly defend my
proposal on the scoping of declarations.  Although I've been back for
three days now, I have only now finished reading the incredible torrent
of mail spewed out over that time.  I therefore ask for your indulgence
as I refer to messages now more than 25 days old.  I have included
contextual excerpts for those of you who haven't just read it all at
once.

	Date: 19 Jul 86 17:17 EDT
	From: NGALL@G.BBN.COM
	
	    Date: 11 Jul 86 18:43 PDT
	    From: Pavel.pa@Xerox.COM
	    
	    In this message I will give a complete description of my proposal
for
	    declaration scoping.  I won't attempt to argue for it on the basis
of
	    ``obviousness'' or clarity, though, because I think that there are
	    people who find each of the two ways of scoping special
declarations
	    confusing.  Rather, I like this way of doing things because it
satisfies
	    an important (to me) consistency criterion: the scope of \any/
	    declaration coincides with a particular lexical identifier scope.
	
	I don't think you mean 'any' here; I think you mean 'any declaration
	that concerns the bindings of variables' (cf. pg. 154).  You cannot
	mean 'any' since in the example below
	(let ((x 1))
	  (declare (inline foo))
	  (foo x))
	the declaration does not 'coincide with a particular lexical
	identifier scope.' A more extreme example is
	(let (...)
	 (declare (optimize ...))
	 ...)
	in which the declaration does not refer to ANY named entity.

Being a disciple of the Mad Hatter, I said what I meant and meant what I
said.  A declaration need not refer to a named entity in order to share
that entity's scope.  In the second example you gave, the OPTIMIZE
declaration applies to the bindings made in the LET and to all code in
the body of the LET.  Thus, if we were asking to optimize speed at the
expense of space, the compiler would be encouraged to bind the variables
in the fastest way possible, even if it used up an extra stack cell, for
example.  I fully understand that most implementations, including that
of Xerox, haven't the freedom to further optimize the creation of
bindings (though it is a fascinating concept...).  The point is that
those bindings \are/ covered by the declaration and that the init-forms
for the bindings are \not/ so covered, as stated in my proposal.

	Unfortunately, TYPE and IGNORE are the only decl specs that only
	concern bindings.  SPECIAL concerns bindings also, but it
	also pervasively affects references (this is what you want changed).

I am \not/ trying to change the so-called ``pervasive'' nature of
special declarations, only their scope.  More on this later.

	And FTYPE and INLINE simply confuse me.

How can FTYPE be confusing when TYPE is not?  They perform precisely
symmetrically along the value/function axis.  TYPE makes a statement
about the kinds of \values/ that can be referred to by the \value/-names
given, while FTPYPE makes a statement about the kinds of \functions/
that can be referred to by the \function/-names given.  No difference,
no confusion.

	First of all, FTYPE is not explicitly stated to be a pervasive decl
	spec, I believe this is an omission.  Secondly, there is this
	confusing sentence at the end of their descriptions:

	"Note that the rules of lexical scoping are observed; if one of the
	functions mentioned has a lexically apparent local definition (as made
	by FLET or LABELS), then the declaration applies to that local
	definition and not to the global definition."

	This makes it sound like FTYPE and INLINE are like SPECIAL: they
	concern bindings AND affect references (but not pervasively?).

	For example,
	(FLET ((zap (...)...(zap...)...))
	  (declare (inline zap))
	  ...)

	Is the call to zap in the local definition of zap affected by the
	declaration?  My reading of CLtL and commonsense make me answer no.
	The call to zap is not a call to the local def. of zap, and according
	to my reading of the sentence quoted above, the decl. only affects
	references within the scope of the innermost binding of the name zap.
	But this interpretation depends upon not interpreting 'pervasively' as
	stated in CLtL. Is my interpretation correct?

One is strongly reminded of rabbinical study of the Talmud...
This whole view of pervasive vs. non-pervasive is a red herring based
upon some unclearly-written prose in CLtL.  A given declaration has a
certain scope and has an effect (possibly empty) on every single
language construct in that scope.  Thus, \every/ declaration is
``pervasive'' in the sense of CLtL.  To describe the meaning of a given
kind of declaration, it is necessary and sufficient to lay out its
effect on every kind of language feature that can appear within its
scope; clearly, most declaration-kinds will have non-empty effects on
only a small set of language features.  For example, a SPECIAL
declaration affects variable bindings and references, but not
function-calls or other declarations.  The DECLARATION declaration
affects only other declarations and none of variable bindings,
references or function calls.  I will lay out my understanding of the
meanings of all of the CLtL declaration-kinds in another message (since
this one is going to be too long as it is).

	I propose the following change to CLtL (which pretty much agrees with
	both CLtL and Pavel):
		
		...

I disagree with the statement that Nick's proposal agrees with mine.


		...

	Some examples should help clarify this:

	(let ((y x))
	  (declare (type list x))
	  ...x...)
	Both references to x are affected.

	(let ((x x))
	  (declare (type list x))
	  ...x...)
	Only the second reference to x is affected (since the first reference
	is not within the scope of the binding named by x).

This is losing.  Either the init-forms of the LET should be covered by
the declarations or they should not, but it shouldn't depend upon what
variables are being bound.  It is precisely behaviour like this against
which I am raging: the scope of declarations corresponding to random,
arbitrary, and hard-to-remember rules as opposed to the same, sane rules
of lexical scoping around which the whole remainder of the language
revolves.

	(FLET ((zap (...)...(zap...)...(zoop...)...))
	  (declare (function zap (...)...)
	           (function zoop (...)...))
	  ...)
	The call to zap is not affected, but the call to zoop is.

This is the example that really hurts.  The world will be a simpler
place if we can simply agree that every declaration has a certain scope,
regardless of what constructs appear in that scope.  Thus, the scope of
these declarations either includes or does not include the body of the
function ZAP.  If they do (and I think that they should not), then both
function calls shown should be affected.  If the scope does not include
that body, then neither call is affected.  Clear?

Note that I specified a \single/ scope for both declarations above, not
a separate one for each; the only exception to this policy should be the
sequential binding forms, including LAMBDA.

	I believe this proposal is complete, consistent, and simple to apply.

I believe this proposal is incomplete (since it does not include a
specific enumeration of the semantics of all declarations in all of the
special forms), inconsistent (see my last set of comments above) and
difficult to apply (it requires examination of the names of variables
being bound, as opposed to having scope and semantics independent of
specific context).

-----------

The next proposal was from Bawden and was later dubbed ``Bawden's
Alternate Proposal'':

	Date: Mon, 21 Jul 86 16:02:37 EDT
	From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
	
	...
	
	Actually, the more I think about this as a simplification, the more I
like
	it.  So here is a counter-proposal for rationalizing the semantics of
	declarations:


	1.  All declarations are completely pervasive.  That is, if you write

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

	then every occurance of FOO within the body is taken to be a special
	reference or a special binding.  The only way to escape from the
effects of
	a declaration within the body, is to explicitly shadow the declaration
with
	another.  This applies to -all- declarations: FTYPE, INLINE, etc.

	2.  Declarations that occur in the bodies of special forms (DEFUN, LET,
DO,
	etc.), and in LAMBDA expressions, are taken to mean the same thing as
if
	the entire form was enclosed in a LOCALLY containing the same
declarations.
	So

	  (let ,pairs ,@dcls ,@body)

	and

	  (locally ,@dcls (let ,pairs ,@body))

	are completely equivalent.  

	(Since LAMBDA expressions aren't forms, the equivalent using LOCALLY
isn't
	always completely straightforward to construct.  For example, this
case:

	  ((lambda ,vars ,@dcls ,@body) ,@vals)

	is equivalent to using LOCALLY as follows:

	  (funcall (locally ,@dcls (function (lambda ,vars ,@body))) ,@vals)

	.)

One certainly can't fault this proposal on the ground of complexity.
No, my major objection to Alan's plan is that it sets up an entirely
separate scoping mechanism for declarations.  That mechanism is entirely
lexical and straightforward and all that, but it's not the same one that
the binding of names uses.  Why have two scopes when one will do?  Also,
I agree with Paul the Greek that the following is undesirable:

	Date: Mon, 21 Jul 86 17:55:05 EDT
	From: Alan Bawden <ALAN@AI.AI.MIT.EDU>

	    From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
	    Bawden's proposal would result in the following.

	      (FLET ((FOO (X) (FOO X X)))
	        (DECLARE (FUNCTION FOO (INTEGER) INTEGER))

	        ... (FOO 5) ...)

	    The declaration for FOO would pertain to both the locally-defined
	    FOO and the outer FOO used in its body.

	This is correct.  Since function names are lexically scoped, you can
call
	the inner function something other than FOO with only a minor change to
	your program.  Is this situation actually common in anyone's code?

It bothers me that a single declaration can refer to two different
variables that happen to share the same name.  Notice that it is the
creation of a separate-but-equal scoping mechanism for declarations that
causes this problem; were declarations to use the same scoping mechanism
as names, this problem could not arise.

JonL wrote in support of Alan's proposal:

	Date: Wed, 23 Jul 86 03:53:30 PDT
	From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)

	...

	It seems to me that Alan's proposal infuses declarations with the same 
	kind of scoping semantics that exists for variable bindings.  In the
form
	    (let ((a <something>))
	      . . .
	      (let ((a <something-else>))
	        . . . 
	      ))
	the meaning of this is "a is bound to something, unless it is bound
	to something else"; which is parallel to Alan's notion for declarations
	that has (unfortunately) been called "shadowing".

	I find the unification of these two scoping rules to be very
attractive.

	-- JonL --

Alan's proposal does not unify the two scoping rules, but rather grants
them both first-class status, separate but equal, as I said above.  I
believe that my proposal, linking the scope of declarations directly to
the scope of names, truly unifies the two.

I've talked enough for this letter.  I will send out a separate message
revising and completing my proposal in as much detail I would expect
(hope) the language specification to contain.

	Pavel

∂14-Aug-86  1602	RAM@C.CS.CMU.EDU 	More words on the scoping of declarations (FTYPE)   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 86  15:59:44 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 14 Aug 86 18:57:21-EDT
Date: Thu, 14 Aug 1986  18:57 EDT
Message-ID: <RAM.12230841185.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   Pavel.pa@XEROX.COM
Cc:   Common-Lisp@SU-AI.ARPA
Subject: More words on the scoping of declarations (FTYPE)
In-reply-to: Msg of 14 Aug 1986  17:11-EDT from Pavel.pa at Xerox.COM


    My reading of the manual supports the claim that FTYPE is not
symmetrical with TYPE.  TYPE may only be used with a binding, while
FTYPE is shown in examples as being used "pervasively" on a global
identifier.  If FTYPE was in fact like TYPE, then you couldn't use it
at all, since currently no declarations are allowed in functional
binding forms.

    Whether this is desirable is another point altogether.  We should
probably clean up this gratuitous inconsistency if we are going to
make sweeping changes to the declaration scoping rules.

  Rob

∂15-Aug-86  0734	cvfong@mitre.ARPA 	drop out   
Received: from MITRE.ARPA by SAIL.STANFORD.EDU with TCP; 15 Aug 86  07:34:18 PDT
Full-Name: C. Vanessa Fong
Message-Id: <8608151424.AA21531@mitre.ARPA>
Organization: The MITRE Corp., Washington, D.C.
To: common-lisp@su-ai.ARPA
Subject: drop out
Date: Fri, 15 Aug 86 10:24:33 -0500
From: Vanessa Fong <cvfong@mitre.ARPA>

Please delete my name from your distribution list. Thanks!

C. Vanessa Fong (cvfong@mitre.arpa)

∂18-Aug-86  1101	RAM@C.CS.CMU.EDU 	More words on the scoping of declarations 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Aug 86  11:01:09 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Mon 18 Aug 86 14:01:05-EDT
Date: Mon, 18 Aug 1986  13:56 EDT
Message-ID: <RAM.12231834939.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   Pavel.pa@XEROX.COM
Cc:   Common-Lisp@SU-AI.ARPA
Subject: More words on the scoping of declarations
In-reply-to: Msg of 14 Aug 1986  17:11-EDT from Pavel.pa at Xerox.COM


    I think that I like the substance of your proposal for declaration
scoping, but I have some misgivings about the way that you have
expressed it.

    In your definition, you attempt to simply define all interactions
between all forms where declarations can appear and all code that can
appear in them.  This approach attempts to deny the need for a theory
of declaration scoping.  Such a theory would give people a model for
understanding how things work, and would also enforce some sort of
consistency in the definition.

    It is evident that you do have a theory of variable binding, but
you don't really attempt to formalize it to the point where
declartion semantics becomes obvious.  You theory is based on the idea
that declaration scoping should follow the same scope rules as
variables.  It is a property of this theory that a declaration for a
specific name cannot refer to multipel variables which have the same
name.

    So far as the application of the theory goes, the main problem
that I see is with LET* and possibly other places where sequential
bindings happen.  It is not obvious to me what the scope of
delcarations in LET* should be, even if we disallow repeated variable
names.

  Rob

∂18-Aug-86  1459	@DIAMOND.S4CC.Symbolics.COM:File-Server@DIAMOND.S4CC.Symbolics.COM 	string-/=, etc.  
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 18 Aug 86  14:58:53 PDT
Date: Mon, 18 Aug 86 17:58 EDT
From: DCP@QUABBIN.SCRC.Symbolics.COM
Sender: File-Server@DIAMOND.S4CC.Symbolics.COM
Subject: string-/=, etc.
To: common-lisp@SU-AI.ARPA
Supersedes: <860808175848.1.DCP@FIREBIRD.S4CC.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-ID: <860818175815.4.FILE-SERVER@DIAMOND.S4CC.Symbolics.COM>

Page 301 is slightly ambiguous.  If you read it carefully, some parts
imply it is a relative index ("...then the result is the index within
the strings..." and "put another way, the result is the length of the
logest common prefix...") but other parts imply it is absolute ("The
index returned in case of a mistmatch is an index into /string1/.")  The
last sentence on the page is the real clincher, but is said much too
late and the almost-relative wording.

[In hindsight, some of us may think the answer should be relative to the
beginning of the specified substrings, not absolute in string1, but
that's incompatible and probably too incompatible.]

∂18-Aug-86  1725	HEDRICK@RED.RUTGERS.EDU 	close on synonym streams, etc 
Received: from RED.RUTGERS.EDU by SAIL.STANFORD.EDU with TCP; 18 Aug 86  17:25:40 PDT
Date: 18 Aug 86 20:25:45 EDT
From: Charles Hedrick <HEDRICK@RED.RUTGERS.EDU>
Subject: close on synonym streams, etc
To: common-lisp@SU-AI.ARPA
Message-ID: <12231905873.61.HEDRICK@RED.RUTGERS.EDU>

I would think that it would be legal to close a synonym stream,
broadcast stream, etc., but that this close would affect only the
synonym stream, as opposed to the stream it points to.  I could conceive
of implementations where buffering is done in each stream.  In that
case, it might be a good idea to close a synonym or broadcast stream, in
order to make sure that any buffered characters are taken care of and
any cleanup is done. It should be an error to do any I/O operation on a
stream that has been closed.  If you intend to outlaw close on one
of these composite streams, then you should mention this fact clearly
where synonym and broadcast streams are defined, and note that this
means that they must be implemented in such a way that a close is not
required when you are finished using them.
-------

∂18-Aug-86  1825	franz!fizzy!jkf@kim.Berkeley.EDU 	Re: synonym streams..     
Received: from [128.32.130.7] by SAIL.STANFORD.EDU with TCP; 18 Aug 86  18:25:39 PDT
Received: by kim.Berkeley.EDU (5.53/1.16)
	id AA01094; Mon, 18 Aug 86 18:26:34 PDT
From: franz!fizzy!jkf@kim.Berkeley.EDU
Received: from fizzy by franz (5.5/3.14)
	id AA11103; Mon, 18 Aug 86 15:22:33 PDT
Received: by fizzy (4.12/3.14)
	id AA19698; Mon, 18 Aug 86 15:23:02 pdt
Return-Path: <fizzy!jkf>
Message-Id: <8608182223.AA19698@fizzy>
To: ucbkim!Xerox.COM!Masinter.pa
Cc: common-lisp@su-ai.arpa
Subject: Re: synonym streams.. 
In-Reply-To: Your message of 05 Aug 86 11:09:00 PDT.
             <860805-111034-2460@Xerox> 
Date: Mon, 18 Aug 86 15:22:59 PDT


>> Date: 5 Aug 86 11:09 PDT
>> From: franz!ucbkim!Xerox.COM!Masinter.pa
>> I propose the following rule: "It is an error to attempt to close a
>> stream that wasn't created with open."

>> With this rule, it would follow that, since synonym, broadcast and
>> two-way streams are not created with open,  it is an error to perform
>> "close" on them.

[sorry for the delay in the reply, this is the first chance I've had
to reply]
This topic was brought up in this mailing list on Aug 21, 1985 and 
discussed at great length on Sept 7, 1985.    My feeling was then and
is still now that closing a synonym stream is legal, and that the only
effect is that  read and writes to the closed synonym stream will cause an
error to be signaled.  [At the time the only other possibility
discussed was that closing a synonym stream would cause the stream
that it was a synonym of to be closed as well.  No one has brought
this option up so I assume that either it has no backers or else they
are on vacation].
 Suppose I have a function which takes a stream and reads and
processes data from that stream and when an eof is seen, it closes the
stream and returns.  What is to be gained by my program having to know
about synonym streams and having to check that it wasn't a synonym
stream passed in before it does a close?   I would like my function to
be able to accept input from *standard-input* by having 
my program create a synonym stream (call it X) for *standard-input*
and passing it to the function. When my function closes X, that should 
be ok, and it shouldn't affect *standard-input* (or *terminal-io*, 
if *standard-input* is a synonym for *terminal-io*).

-john foderaro
 Franz Inc.



∂19-Aug-86  1045	ACUFF@SUMEX-AIM.ARPA 	Re: synonym streams..  
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 19 Aug 86  10:45:33 PDT
Date: Tue 19 Aug 86 10:45:43-PDT
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Re: synonym streams.. 
To: franz!fizzy!jkf@KIM.BERKELEY.EDU,
    ucbkim!Xerox.COM!Masinter.pa@KIM.BERKELEY.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8608182223.AA19698@fizzy>
Message-ID: <12232095191.66.ACUFF@SUMEX-AIM.ARPA>

   I agree with John that making it an error to close an active stream
of any sort is a mistake, since the closing code may have picked up
the stream anywhere and not know its nature.

   What are the arguments against CLOSE closing the actual stream passed
to it, leaving any underlying streams alone?  The only one I can think
of is the desire to close those underlying streams as well, which indicates
a potential need for a mechanism to recover embedded streams.

	-- Rich
-------

∂19-Aug-86  1240	KMP@STONY-BROOK.SCRC.Symbolics.COM 	close on synonym streams, etc
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 Aug 86  12:40:33 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 83435; Tue 19-Aug-86 15:24:50 EDT
Date: Tue, 19 Aug 86 15:24 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: close on synonym streams, etc
To: HEDRICK@RED.RUTGERS.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <12231905873.61.HEDRICK@RED.RUTGERS.EDU>
Message-ID: <860819152419.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: 18 Aug 86 20:25:45 EDT
    From: Charles Hedrick <HEDRICK@RED.RUTGERS.EDU>

    ... I could conceive of implementations where buffering is done 
    in each stream.  In that case, it might be a good idea to close 
    a synonym or broadcast stream, in order to make sure that any 
    buffered characters are taken care of and any cleanup is done. 

It looks to me like this issue is adequately addressed by the presence
of FINISH-OUTPUT and FORCE-OUTPUT. Perhaps the documentation could be
clearer on that point.

    ... If you intend to outlaw close on one of these composite streams,
    then you should mention this fact clearly where synonym and broadcast
    streams are defined, and note that this means that they must be
    implemented in such a way that a close is not required when you are
    finished using them.

Indeed, the documentation should be clear about these points.

It seems to me, however, that the only point to CLOSE is that it 
allows the freeing of things like operating system "channels" 
which are often critical resources. In that respect, it's like 
a fast GC. If they weren't critical resources, I assume we'd 
just drop pointers to streams and let the GC take care of 
straightening out the resources in its own sweet time. 

Since echo and broadcast streams are presumably just lisp objects 
which have slots containing other streams, I see no reason to worry
about fast GC of them. Statistically, I bet their components will
tend to (not really coincidentally) get closed anyway by other
mechanisms. eg, consider:

 (WITH-OPEN-FILE (FILE-STREAM ...)
   (LET ((ECHO-STREAM (MAKE-ECHO-STREAM STREAM *TERMINAL-IO*)))
     ...))

The file stream will get closed fine by the WITH-OPEN-FILE. The echo
stream (holding the closed file stream) will eventually get cleaned 
up by the GC. That should be fine. No one's going to miss the couple
of conses which is presumably the only resource being used in the
meantime.

It's true that there may be certain situations where you might think
you want ECHO-STREAM-P, ECHO-STREAM-INPUT-STREAM, and 
ECHO-STREAM-OUTPUT-STREAM operations in order to clean up the loose 
ends. Eg, you might have done:

 (DEFVAR *ECHO-STREAM* (MAKE-ECHO-STREAM (OPEN ...) *TERMINAL-IO*))

and maybe you later want to close the encapsulated real stream, but my
feeling is that it was so easy for you to have done:

 (DEFVAR *FILE-STREAM* (OPEN ...))
 (DEFVAR *ECHO-STREAM* (MAKE-ECHO-STREAM *FILE-STREAM* *TERMINAL-IO*))

that there just isn't any way to claim that the language didn't let 
you do what you wanted to do. In fact, if someone else wrote the module 
that gave you the pointer to the echo stream and that person wouldn't 
give you the encapsulated stream, maybe it was for a reason. If so, 
you're asking a lot by claiming it should be ok to be closing that 
encapsulated stream...

∂19-Aug-86  1556	pyramid!bein@hplabs.HP.COM 	streams ... 
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 19 Aug 86  15:55:49 PDT
Received: by hplabs.HP.COM ; Tue, 19 Aug 86 15:54:54 pdt
Received: by pyramid (5.51/3.14)
	id AA20141; Tue, 19 Aug 86 12:52:19 PDT
Date: 19 Aug 1986 12:52 PDT
From: David Bein <pyramid!bein@hplabs.HP.COM>
Subject: streams ...
To: common-lisp@su-ai
Message-Id: <524862532/bein@pyramid>

  Sorry for all the confusion. Now for a fresh batch.

  My questions are motivated by what is supposed to happen when
a stream which is composed of other streams runs into one of the
standard streams (e.q. original *standard-input*,*standard-output*,
or *terminal-io*). Note that I am assuming that it is erroneous
to bash the original streams. I do not know whether it should cause
an error or simply do nothing. My feeling is that either is desirable
at different times. I also can imagine cases where one explicitly
wants to bash one of the original streams. Any interactive error/query system
ought to be able to throw its hands up when someone closes *terminal-io*.

  My proposal for handling this mess without forcing true believers
on either side of the question is:

(1) Provide a stream operation which marks a stream as "NEVER-CLOSE".
    When CLOSE (either directly or via a CLOSE on some composed stream)
    hits one of these it ignores it and returns. We could designate
    this as a "DINER" stream since it is always open.

(2) Provide a stream operation which marks a stream as "COMPLAIN-IF-CLOSED".
    When CLOSE (same conditions as above) hits one of these it flames
    out and causes an error.

  Any stream which has neither of these attributes is fair game
for closing either directly or via recursion. Both options may of
course be turned off if a user desires it.

  Establish well-defined defaults for any of the standard streams
so that one can write "portable" code. Perhaps neither attribute
should be on when a stream is created. Of course this does not
help much when *terminal-io* appears out of nowhere as far as
any user is concerned.

  I agree with those people who believe a close on a composed-stream
(echo,synonym,two-way,concatenated,broadcast) should render the
top level stream unusable.

  While on the subject, I think that it would be reasonable to be
able to query a composed stream. It would also be reasonable to
make the various kinds of streams be distinct types (each a subtyp of STREAM)
so the typing system could help differentiate between the streams.
Of course we will have to draw some distinction between "portable"
streams and all the other kinds which implementers have added.

  More food for thought -- what do people think is reasonable to
do with *terminal-io* if the process is running without any kind
of connection to an interactive device? I have seen different
approaches. I personally like the idea that use of *terminal-io*
when no kind of interactive device exists should cause some kind
of merciless death. This has implications for error/query systems
of course.

--David

∂19-Aug-86  1827	sridhar%tekecs.tek.csnet@CSNET-RELAY.ARPA 	documentation strings in BOA constructors ?    
Received: from CSNET-RELAY.ARPA by SAIL.STANFORD.EDU with TCP; 19 Aug 86  18:27:25 PDT
Received: from tektronix by csnet-relay.csnet id ae12858; 19 Aug 86 18:43 EDT
Received: by tektronix.TEK (5.31/6.16)
	id AA29746; Tue, 19 Aug 86 14:22:27 PDT
Received: by tekecs.GWD.TEK (5.16/6.16) 
	id AA03925; Tue, 19 Aug 86 14:23:25 PDT
From: "S. Sridhar" <sridhar%tekecs.tek.csnet@CSNET-RELAY.ARPA>
Message-Id: <8608192123.AA03925@tekecs.GWD.TEK>
Date: Tue, 19 Aug 86 14:23:23 PDT
To: common-lisp@SU-AI.ARPA
Subject: documentation strings in BOA constructors ?

 Suppose you have :
    (defstruct (point (:constructor make-point (x y) "this makes a point"))
     		x y)

 There is no mention on page315-316 in CltL about having
documentation strings for such functions.
Our  implementation does:
 (documentation 'make-point 'function) => nil.

 What should the "correct" behaviour be?


--sridhar

∂19-Aug-86  1840	RAM@C.CS.CMU.EDU 	documentation strings in BOA constructors ?    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 Aug 86  18:40:32 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 19 Aug 86 21:38:44-EDT
Date: Tue, 19 Aug 1986  21:38 EDT
Message-ID: <RAM.12232181270.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   "S. Sridhar" <sridhar%tekecs.tek.csnet@CSNET-RELAY.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: documentation strings in BOA constructors ?
In-reply-to: Msg of 19 Aug 1986  17:23-EDT from S. Sridhar <sridhar%tekecs.tek.csnet at CSNET-RELAY.ARPA>

    Date: Tuesday, 19 August 1986  17:23-EDT
    From: S. Sridhar <sridhar%tekecs.tek.csnet at CSNET-RELAY.ARPA>
    Re:   documentation strings in BOA constructors ?

    Suppose you have :
       (defstruct (point (:constructor make-point (x y) "this makes a point"))
		   x y)

I think it clear that this is illegal and that there is no way to
specify doc strings in DEFSTRUCT.  Although a possible area for
extensions, it not a big problem since SETF of DOCUMENTATION can be
used to given function documentation to any function.

If we were to extend DEFSTRUCT so that the functions could be directly
documented, then the extension should apply to *all* defstruct
generated functions, and not just BOA constructors.

  Rob

∂20-Aug-86  0540	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	"fonted" characters in CL
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 20 Aug 86  05:40:36 PDT
Received: from FIREBIRD.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 5857; Wed 20-Aug-86 08:40:10 EDT
Date: Wed, 20 Aug 86 08:40 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: "fonted" characters in CL
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: <860802175500.1.DCP@FIREBIRD.S4CC.Symbolics.COM>
Message-ID: <860820084000.8.DCP@FIREBIRD.S4CC.Symbolics.COM>

I propose we eliminate char-font-limit and the associated concepts from
the language.  Either that or make the specification considerably more
tight and detailed saying how >numeric< values are interpreted.  Either
that, or specify some >symbolic< notion of "fonts" we can live with.

Symbolics found that the CL notion of "fonts" is not very portable, nor
is it very useful.  Therefore, char-font-limit => 1 and (char-font
<char>) =always=> 0.  This is in accordance with CLtL, but it doesn't
help us move code to other Common Lisp implementations, and it doesn't
help others port to our system.  

What we have done instead (note I don't want to push this and I'm not
sure the development staff does either since only beta-test sites have
seen this so far) is to define a character to have the following
attributes:
	A character set
	A code within the character set
	Bits
	Style
The character set and code within character set is roughly char-code.
Bits are as per CLtL.  Style is a symbolic notion of what the characters
LOOK like, for example, bold, italic, small, very-large, fixed width,
etc, and combinations.  A "font" is a set of glyphs.  A font is mapped
to by the triple character-set, style and output device.  There are
probably some lies in this description; our documentation is clearer and
more verbose.

My point is that the current numbering scheme is a holdover from 1970's
text formatters (TJ6, R, etc) and the simplistic mapping of those to the
MIT Lisp Machines editor buffers.  The numbers in those systems are
relative to something; the numbers in CLtL aren't relative to anything.
Those ideas don't hold in real production systems.

∂20-Aug-86  1040	RICE@SUMEX-AIM.ARPA 	Defstruct and Documentation. 
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Aug 86  10:40:33 PDT
Date: Wed 20 Aug 86 09:59:37-PDT
From: James Rice <Rice@SUMEX-AIM.ARPA>
Subject: Defstruct and Documentation.
To: Common-Lisp@SU-AI.ARPA
Message-ID: <12232348944.62.RICE@SUMEX-AIM.ARPA>


I agree that doc string should be allowed in ALL
defstruct generated functions.

I also think that Declarations should be allowed.
There may well be good reasons for wanting to
(declare (optimize (safety 3) (speed 0))).
Particularly whilst debugging.


Rice.
-------

∂22-Aug-86  1333	@MC.LCS.MIT.EDU,@SEBASTIAN.THINK.COM:gls@AQUINAS.THINK.COM 	1986 Lisp conference bibliography  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Aug 86  13:32:43 PDT
Received: from Godot.Think.COM by MC.LCS.MIT.EDU 22 Aug 86 14:09:45 EDT
Received: from SEBASTIAN.THINK.COM by Godot.Think.COM; Fri, 22 Aug 86 14:05:52 edt
Date: Fri, 22 Aug 86 14:06 EDT
From: Guy Steele <gls@Think.COM>
Subject: 1986 Lisp conference bibliography
To: common-lisp@SU-AI.ARPA, rrrs-authors@MC.LCS.MIT.EDU
Cc: gls@AQUINAS
Message-Id: <860822140628.4.GLS@SEBASTIAN.THINK.COM>

With the help of Bill Scherlis, I have massaged the table of contents
(with some corrections) for the 1986 ACM Conference on Lisp and
Functional Programming into the form of a bibliography database suitable
for use with LaTeX/BibTeX and (almost) SCRIBE.  The database has been
tested with BibTeX, and uses TeX conventions for forcing capitalization
and for accenting characters (there are three accents acute, one umlaut,
and one "i" with a circumflex over it).  The database should require
only slight modification to make it suitable for use with SCRIBE.

I am mailing out the database in the interest of making it easier for
everyone to refer to all these great papers from the conference.  The
database follows at the end of this message, followed by the BibTeX
transcription of it for a bibliography format very similar to that
required by CACM.  (I considered just mailing out a pointer to an
FTP-able file, but I find that in practice this method is rather clumsy
and people don't use it.)

--Guy

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

@InProceedings(LAWS-IN-MIRANDA
	,Key = "Thompson"
	,Author = "Simon Thompson"
	,Title = "Laws in {M}iranda"
	,Pages = "1-12"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(MINI-ML
	,Key = "Clement"
	,Author = "Dominique Cl\'ement and {Jo\"elle} Despeyroux and Thierry Despeyroux and Gilles Kahn"
	,Title = "A Simple Applicative Language: {M}ini-{ML}"
	,Pages = "13-27"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(INTEGRATING-FUNCTIONAL-AND-IMPERATIVE-PROGRAMMING
	,Key = "Gifford"
	,Author = "David K. Gifford and John M. Lucassen"
	,Title = "Integrating Functional and Imperative Programming"
	,Pages = "28-38"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(EXPERIENCE-WITH-AN-UNCOMMON-LISP
	,Key = "Alberga"
	,Author = "Cyril N. Alberga and Chris Bosman-Clark and Martin Mikelsons and Mary S. Van Deusen and Julian Padget"
	,Title = "Experience with an Uncommon {L}isp"
	,Pages = "39-53"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(DESIDERATA-FOR-THE-STANDARDISATION-OF-LISP
	,Key = "Padget"
	,Author = "Julian Padget and others"
	,Title = "Desiderata for the Standardisation of {L}isp"
	,Pages = "54-66"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(OPTIMIZING-DYNAMICALLY-RETARGETABLE-COMPILER-FOR-COMMON-LISP
	,Key = "Brooks"
	,Author = "Rodney A. Brooks and David B. Posner and James L. McDonald and Jon L. White and Eric Benson and Richard P. Gabriel"
	,Title = "Design of an Optimizing, Dynamically Retargetable Compiler for {C}ommon {L}isp"
	,Pages = "67-85"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(IMPLEMENTATION-OF-PC-SCHEME
	,Key = "Bartley"
	,Author = "David H. Bartley and John C. Jensen"
	,Title = "The Implementation of {PC} {S}cheme"
	,Pages = "86-93"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(CODE-GENERATION-TECHNIQUES-FOR-FUNCTIONAL-LANGUAGES
	,Key = "Fairbairn"
	,Author = "Jon Fairbairn and Stuart C. Wray"
	,Title = "Code Generation Techniques for Functional Languages"
	,Pages = "94-104"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(ARCHITECTURE-FOR-MOSTLY-FUNCTIONAL-LANGUAGES
	,Key = "Knight"
	,Author = "Tom Knight"
	,Title = "An Architecture for Mostly Functional Languages"
	,Pages = "105-112"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(EFFICIENT-MULTIPROCESSOR-COMBINATOR-REDUCTION
	,Key = "Lemaitre"
	,Author = "M. Lema\↑\itre and M. Castan and M.-H. Durand and G. Durrieu and B. Lecussan"
	,Title = "Mechanisms for Efficient Multiprocessor Combinator Reduction"
	,Pages = "113-121"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(CURRY-CHIP
	,Key = "Ramsdell"
	,Author = "John D. Ramsdell"
	,Title = "The {CURRY} Chip"
	,Pages = "122-131"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(VARIATIONS-ON-STRICTNESS-ANALYSIS
	,Key = "Bloss"
	,Author = "Adrienne Bloss and Paul Hudak"
	,Title = "Variations on Strictness Analysis"
	,Pages = "132-142"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(EXPANSION-PASSING-STYLE
	,Key = "Dybvig"
	,Author = "R. Kent Dybvig and Daniel P. Friedman and Christopher T. Haynes"
	,Title = "Expansion-Passing Style:  Beyond Conventional Macros"
	,Pages = "143-150"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(HYGIENIC-MACRO-EXPANSION
	,Key = "Kohlbecker"
	,Author = "Eugene Kohlbecker and Daniel P. Friedman and Matthias Felleisen and Bruce Duba"
	,Title = "Hygienic Macro Expansion"
	,Pages = "151-161"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(EXACT-REAL-ARITHMETIC
	,Key = "Boehm"
	,Author = "Hans-J. Boehm and Robert Cartwright and Mark Riggle and Michael J. O'Donnell"
	,Title = "Exact Real Arithmetic:  A Case Study in Higher Order Programming"
	,Pages = "162-173"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(RECONFIGURABLE-RETARGETABLE-BIGNUMS
	,Key = "White"
	,Author = "Jon L. White"
	,Title = "Reconfigurable, Retargetable Bignums: A Case Study in Efficient, Portable {L}isp System Building"
	,Pages = "174-191"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(LISP-ON-A-REDUCED-INSTRUCTION-SET-PROCESSOR
	,Key = "Steenkiste"
	,Author = "Peter Steenkiste and John Hennessy"
	,Title = "{L}isp on a Reduced-Instruction-Set-Processor"
	,Pages = "192-201"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(PARTITIONING-PARALLEL-PROGRAMS-FOR-MACRO-DATAFLOW
	,Key = "Sarkar"
	,Author = "Vivek Sarkar and John Hennessy"
	,Title = "Partitioning Parallel Programs for Macro-Dataflow"
	,Pages = "202-211"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(NORMA-GRAPH-REDUCTION-PROCESSOR
	,Key = "Scheevel"
	,Author = "Mark Scheevel"
	,Title = "{NORMA}:  A Graph Reduction Processor"
	,Pages = "212-219"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(FOUR-STROKE-REDUCTION-ENGINE
	,Key = "Clack"
	,Author = "Chris Clack and Simon L. Peyton Jones"
	,Title = "The Four-Stroke Reduction Engine"
	,Pages = "220-232"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(USE-OF-LISP-IN-IMPLEMENTING-DENOTATIONAL-SEMANTICS
	,Key = "Lee"
	,Author = "Peter Lee and Uwe Pleban"
	,Title = "On the Use of {L}isp in Implementing Denotational Semantics"
	,Pages = "233-248"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(SEMANTICS-DIRECTED-COMPILING-FOR-FUNCTIONAL-LANGUAGES
	,Key = "Nielson"
	,Author = "Hanne R. Nielson and Flemming Nielson"
	,Title = "Semantics Directed Compiling for Functional Languages"
	,Pages = "249-257"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(CONNECTION-GRAPHS
	,Key = "Bawden"
	,Author = "Alan Bawden"
	,Title = "Connection Graphs"
	,Pages = "258-265"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(IMPLEMENTING-FUNCTIONAL-LANGUAGES-IN-THE-CATEGORICAL-ABSTRACT-MACHINE
	,Key = "Mauny"
	,Author = "Michel Mauny and Asc\'ander Su\'arez"
	,Title = "Implementing Functional Languages in the Categorical Abstract Machine"
	,Pages = "266-278"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(CONNECTION-MACHINE-LISP
	,Key = "Steele"
	,Author = "Steele, Guy L., Jr. and W. Daniel Hillis"
	,Title = "Connection Machine LISP:  Fine-Grained Parallel Symbolic Processing"
	,Pages = "279-297"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(MYSTERY-OF-THE-TOWER-REVEALED
	,Key = "Wand"
	,Author = "Mitchell Wand and Daniel P. Friedman"
	,Title = "The Mystery of the Tower Revealed:  A Non-Reflective Description of the Reflective Tower"
	,Pages = "298-307"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(TYPE-INFERENCE-APPROACH-TO-POLYMORPHIC-EXPRESSIONS
	,Key = "Mitchell"
	,Author = "John C. Mitchell"
	,Title = "A Type-Inference Approach to Reduction Properties and Semantics of Polymorphic Expressions (summary)"
	,Pages = "308-319"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(EQUATIONS-SETS-AND-REDUCTION-SEMANTICS
	,Key = "Jayaraman"
	,Author = "Bharat Jayaraman and Frank S. K. Silbermann"
	,Title = "Equations, Sets, and Reduction Semantics for Functional and Logic Programming"
	,Pages = "320-331"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(SEMANTIC-THEORY-FOR-EQUATIONAL-PROGRAMMING-LANGUAGES
	,Key = "Thatte"
	,Author = "Satish R. Thatte"
	,Title = "Towards a Semantic Theory for Equational Programming Languages"
	,Pages = "332-342"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(PROTOCOL-FOR-DISTRIBUTED-REFERENCE-COUNTING
	,Key = "Lermen"
	,Author = "Claus-Werner Lermen and Dieter Maurer"
	,Title = "A Protocol for Distributed Reference Counting"
	,Pages = "343-350"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(SEMANTIC-MODEL-OF-REFERENCE-COUNTING-AND-ITS-ABSTRACTION
	,Key = "Hudak"
	,Author = "Paul Hudak"
	,Title = "A Semantic Model of Reference Counting and its Abstraction (detailed summary)"
	,Pages = "351-363"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(DISTRIBUTED-COPYING-GARBAGE-COLLECTION
	,Key = "Rudalics"
	,Author = "Martin Rudalics"
	,Title = "Distributed Copying Garbage Collection"
	,Pages = "364-372"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

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

\bibitem{EXPERIENCE-WITH-AN-UNCOMMON-LISP}
Alberga, Cyril N., Bosman-Clark, Chris, Mikelsons, Martin, Deusen, Mary S. Van, and Padget, Julian.
Experience with an uncommon {L}isp.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 39--53.

\bibitem{IMPLEMENTATION-OF-PC-SCHEME}
Bartley, David H., and Jensen, John C.
The implementation of {PC} {S}cheme.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 86--93.

\bibitem{CONNECTION-GRAPHS}
Bawden, Alan.
Connection graphs.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 258--265.

\bibitem{VARIATIONS-ON-STRICTNESS-ANALYSIS}
Bloss, Adrienne, and Hudak, Paul.
Variations on strictness analysis.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 132--142.

\bibitem{EXACT-REAL-ARITHMETIC}
Boehm, Hans-J., Cartwright, Robert, Riggle, Mark, and O'Donnell, Michael J.
Exact real arithmetic: a case study in higher order programming.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 162--173.

\bibitem{OPTIMIZING-DYNAMICALLY-RETARGETABLE-COMPILER-FOR-COMMON-LISP}
Brooks, Rodney A., Posner, David B., McDonald, James L., White, Jon L., Benson, Eric, and Gabriel, Richard P.
Design of an optimizing, dynamically retargetable compiler for {C}ommon {L}isp.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 67--85.

\bibitem{FOUR-STROKE-REDUCTION-ENGINE}
Clack, Chris, and Jones, Simon L. Peyton.
The four-stroke reduction engine.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 220--232.

\bibitem{MINI-ML}
Cl\'ement, Dominique, Despeyroux, {Jo\"elle}, Despeyroux, Thierry, and Kahn, Gilles.
A simple applicative language: {M}ini-{ML}.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 13--27.

\bibitem{EXPANSION-PASSING-STYLE}
Dybvig, R. Kent, Friedman, Daniel P., and Haynes, Christopher T.
Expansion-passing style: beyond conventional macros.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 143--150.

\bibitem{CODE-GENERATION-TECHNIQUES-FOR-FUNCTIONAL-LANGUAGES}
Fairbairn, Jon, and Wray, Stuart C.
Code generation techniques for functional languages.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 94--104.

\bibitem{INTEGRATING-FUNCTIONAL-AND-IMPERATIVE-PROGRAMMING}
Gifford, David K., and Lucassen, John M.
Integrating functional and imperative programming.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 28--38.

\bibitem{SEMANTIC-MODEL-OF-REFERENCE-COUNTING-AND-ITS-ABSTRACTION}
Hudak, Paul.
A semantic model of reference counting and its abstraction (detailed summary).
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 351--363.

\bibitem{EQUATIONS-SETS-AND-REDUCTION-SEMANTICS}
Jayaraman, Bharat, and Silbermann, Frank S. K.
Equations, sets, and reduction semantics for functional and logic programming.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 320--331.

\bibitem{ARCHITECTURE-FOR-MOSTLY-FUNCTIONAL-LANGUAGES}
Knight, Tom.
An architecture for mostly functional languages.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 105--112.

\bibitem{HYGIENIC-MACRO-EXPANSION}
Kohlbecker, Eugene, Friedman, Daniel P., Felleisen, Matthias, and Duba, Bruce.
Hygienic macro expansion.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 151--161.

\bibitem{USE-OF-LISP-IN-IMPLEMENTING-DENOTATIONAL-SEMANTICS}
Lee, Peter, and Pleban, Uwe.
On the use of {L}isp in implementing denotational semantics.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 233--248.

\bibitem{EFFICIENT-MULTIPROCESSOR-COMBINATOR-REDUCTION}
Lema\↑\itre, M., Castan, M., Durand, M.-H., Durrieu, G., and Lecussan, B.
Mechanisms for efficient multiprocessor combinator reduction.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 113--121.

\bibitem{PROTOCOL-FOR-DISTRIBUTED-REFERENCE-COUNTING}
Lermen, Claus-Werner, and Maurer, Dieter.
A protocol for distributed reference counting.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 343--350.

\bibitem{IMPLEMENTING-FUNCTIONAL-LANGUAGES-IN-THE-CATEGORICAL-ABSTRACT-MACHINE}
 
Mauny, Michel, and Su\'arez, Asc\'ander.
Implementing functional languages in the categorical abstract machine.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 266--278.

\bibitem{TYPE-INFERENCE-APPROACH-TO-POLYMORPHIC-EXPRESSIONS}
Mitchell, John C.
A type-inference approach to reduction properties and semantics of polymorphic expressions (summary).
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 308--319.

\bibitem{SEMANTICS-DIRECTED-COMPILING-FOR-FUNCTIONAL-LANGUAGES}
Nielson, Hanne R., and Nielson, Flemming.
Semantics directed compiling for functional languages.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 249--257.

\bibitem{DESIDERATA-FOR-THE-STANDARDISATION-OF-LISP}
Padget, Julian, et al.
Desiderata for the standardisation of {L}isp.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 54--66.

\bibitem{CURRY-CHIP}
Ramsdell, John D.
The {CURRY} chip.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 122--131.

\bibitem{DISTRIBUTED-COPYING-GARBAGE-COLLECTION}
Rudalics, Martin.
Distributed copying garbage collection.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 364--372.

\bibitem{PARTITIONING-PARALLEL-PROGRAMS-FOR-MACRO-DATAFLOW}
Sarkar, Vivek, and Hennessy, John.
Partitioning parallel programs for macro-dataflow.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 202--211.

\bibitem{NORMA-GRAPH-REDUCTION-PROCESSOR}
Scheevel, Mark.
{NORMA}: a graph reduction processor.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 212--219.

\bibitem{CONNECTION-MACHINE-LISP}
Steele, Jr., Guy L., and Hillis, W. Daniel.
Connection machine lisp: fine-grained parallel symbolic processing.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 279--297.

\bibitem{LISP-ON-A-REDUCED-INSTRUCTION-SET-PROCESSOR}
Steenkiste, Peter, and Hennessy, John.
{L}isp on a reduced-instruction-set-processor.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 192--201.

\bibitem{SEMANTIC-THEORY-FOR-EQUATIONAL-PROGRAMMING-LANGUAGES}
Thatte, Satish R.
Towards a semantic theory for equational programming languages.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 332--342.

\bibitem{LAWS-IN-MIRANDA}
Thompson, Simon.
Laws in {M}iranda.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 1--12.

\bibitem{MYSTERY-OF-THE-TOWER-REVEALED}
Wand, Mitchell, and Friedman, Daniel P.
The mystery of the tower revealed: a non-reflective description of the reflective tower.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 298--307.

\bibitem{RECONFIGURABLE-RETARGETABLE-BIGNUMS}
White, Jon L.
Reconfigurable, retargetable bignums: a case study in efficient, portable {L}isp system building.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 174--191.


∂25-Aug-86  1059	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Defstruct and Documentation.  
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 25 Aug 86  10:59:27 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 67941; Mon 25-Aug-86 13:54:56 EDT
Date: Mon, 25 Aug 86 13:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Defstruct and Documentation.
To: James Rice <Rice@SUMEX-AIM.ARPA>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <12232348944.62.RICE@SUMEX-AIM.ARPA>
Message-ID: <860825135423.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed 20 Aug 86 09:59:37-PDT
    From: James Rice <Rice@SUMEX-AIM.ARPA>

    I agree that doc string should be allowed in ALL
    defstruct generated functions.

    I also think that Declarations should be allowed.
    There may well be good reasons for wanting to
    (declare (optimize (safety 3) (speed 0))).
    Particularly whilst debugging.

Shouldn't that be done as

(locally (declare (optimize (safety 3) (speed 0)))
  (defstruct ...))

or (proclaim '(optimize (safety 3) (speed 0))) ?

∂25-Aug-86  1105	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	question about subtypep  
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 25 Aug 86  11:05:11 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 67948; Mon 25-Aug-86 14:03:19 EDT
Date: Mon, 25 Aug 86 14:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: question about subtypep
To: Rob MacLachlan <RAM@C.CS.CMU.EDU>
cc: SANDRA <LOOSEMORE@UTAH-20.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12230709127.BABYL@C.CS.CMU.EDU>
Message-ID: <860825140245.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 14 Aug 1986  06:51 EDT
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>

	Note there are some possible users of SUBTYPEP that would prefer
    answers to be based on some hypothetical maximally restrictive type
    system.  The main example is a compiler which does compile-time type
    checking when possible.  Although (THE SHORT-FLOAT 1F0) is quite legal
    in an implementation in which SHORT-FLOAT and SINGLE-FLOAT are
    identical, it would be reasonable for the compiler to give a warning
    anyway.  Applications that care about this sort of thing will have to
    use a variant version of subtypep that is distinct from the real
    SUBTYPEP.

They'll have to do more than that.  If the user wrote (THE SHORT-FLOAT 1s0)
it would read as exactly the same Lisp object as (THE SHORT-FLOAT 1f0) in an
implementation where SHORT-FLOAT and SINGLE-FLOAT are identical, so I don't
see how the compiler could distinguish these and give a warning for one but
not for the other.

    My intpretation
    (based on intensive meditation and reading of scripture) is that
    SUBTYPEP returns information about the actual subtype relations in
    your implementation.

I agree.  I think that's the only consistent interpretation.

∂25-Aug-86  1117	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Re: synonym streams..    
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 25 Aug 86  11:15:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 67962; Mon 25-Aug-86 14:13:20 EDT
Date: Mon, 25 Aug 86 14:12 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: synonym streams.. 
To: common-lisp@SU-AI.ARPA
In-Reply-To: <8608182223.AA19698@fizzy>,
             <12231905873.61.HEDRICK@RED.RUTGERS.EDU>,
             <12232095191.66.ACUFF@SUMEX-AIM.ARPA>,
             <860819152419.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
             <524862532/bein@pyramid>
Message-ID: <860825141247.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

I believe all of these problems would go away if programmers would follow
the rule that the same module that opens (or otherwise creates) a stream
is responsible for closing (or otherwise disposing of) it.  This seems
eminently simple and sensible, and has worked well for us for many years.

∂25-Aug-86  1201	RAM@C.CS.CMU.EDU 	question about subtypep    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Aug 86  11:57:59 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Mon 25 Aug 86 14:56:53-EDT
Date: Mon, 25 Aug 1986  14:56 EDT
Message-ID: <RAM.12233680997.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: question about subtypep
In-reply-to: Msg of 25 Aug 1986  14:02-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


    Date: Monday, 25 August 1986  14:02-EDT
    From: David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>

        Date: Thu, 14 Aug 1986  06:51 EDT
        From: Rob MacLachlan <RAM@C.CS.CMU.EDU>

    	Although (THE SHORT-FLOAT 1F0) is quite legal in an
    	implementation in which SHORT-FLOAT and SINGLE-FLOAT are
        identical, it would be reasonable for the compiler to give a warning
        anyway.  Applications that care about this sort of thing will have to
        use a variant version of subtypep that is distinct from the real
        SUBTYPEP.

    They'll have to do more than that.  If the user wrote
    (THE SHORT-FLOAT 1s0) it would read as exactly the same Lisp object as
    (THE SHORT-FLOAT 1f0) in an implementation where SHORT-FLOAT and
    SINGLE-FLOAT are identical, so I don't see how the compiler could
    distinguish these and give a warning for one but not for the
    other.

I realized this was a bad example after I sent the message.  Instead
1F0, substitute <any expression known to be SINGLE-FLOAT>.  For
example, (THE SHORT-FLOAT (THE SINGLE-FLOAT ...)).

  Rob

∂25-Aug-86  2029	@MIT-LIVE-OAK.ARPA,@GOLD-HILL-ACORN.LCS.MIT.EDU:mike%gold-hill-acorn@MIT-LIVE-OAK.ARPA 	More words on the scoping of declarations 
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Aug 86  20:28:13 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM (DIAL|DIAL|4925473) by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 8026; 25 Aug 86 23:31:36-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 37859; Mon 25-Aug-86 22:58:50-EDT
Date: Mon, 25 Aug 86 23:09 EST
Sender: mike%gold-hill-acorn@mit-live-oak.arpa
To: RAM@C.CS.CMU.EDU
From: mike%acorn@mit-live-oak.arpa
Subject: More words on the scoping of declarations
Cc: Pavel.pa@XEROX.COM, Common-Lisp@SU-AI.ARPA

    Date: Mon, 18 Aug 1986  13:56 EDT
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
    
    .....
    
        It is evident that you do have a theory of variable binding, but
    you don't really attempt to formalize it to the point where
    declartion semantics becomes obvious.  You theory is based on the idea
    that declaration scoping should follow the same scope rules as
    variables.  It is a property of this theory that a declaration for a
    specific name cannot refer to multipel variables which have the same
    name.
    
        So far as the application of the theory goes, the main problem
    that I see is with LET* and possibly other places where sequential
    bindings happen.  It is not obvious to me what the scope of
    delcarations in LET* should be, even if we disallow repeated variable
    names.

The scoping of a declaration in a let* should be as close as possible
to that of a let. I think repeated names should be allowed, and the
innermost one should be the one to which the declaration applies.

(let*  ((a (foo a))
        (b a)
        (a 7))
 (declare (type fixnum a)
          (type frobboz b))
  ...a...b...)

The only "a" which is a fixnum here is the one which gets the value 7.
Semantically, the form should be equivalent to:

(let ((a (foo a)))
 (let ((b a))
  (declare (type frobboz b))
   (let ((a 7))
     (declare (type fixnum a))
     ... a ...b..)

This means that the semantics of declaration in let* is exactly as
if you moved the declarations up into a nested let construct,
except for the case of a repeated identifier, where the innermost
name is the one the declaration applies to.
There are of course ambiguous cases where expressing exactly the 
declarations you want requires breaking up a let* into two nested
let*'s so that you can stick a declare in between. I don't see this
as a tragedy. It's still better than the situation in most programming
languages, where the names of identifiers are often chosen to reflect
their type......

In summary, two things. (1) I think Pavel's proposal is right.
(2) I think the "theory" should be extended to reflect the "innermost"
principle for sequential binding constructs.

...mike beckerle
   Gold Hill Computers



∂25-Aug-86  2154	@MIT-LIVE-OAK.ARPA,@GOLD-HILL-ACORN.LCS.MIT.EDU:mike%gold-hill-acorn@MIT-LIVE-OAK.ARPA 	"fonted" characters in CL  
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Aug 86  21:53:56 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM (DIAL|DIAL|4925473) by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 8037; 26 Aug 86 00:57:49-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 37862; Tue 26-Aug-86 00:03:47-EDT
Date: Tue, 26 Aug 86 00:14 EST
Sender: mike%gold-hill-acorn@mit-live-oak.arpa
To: DCP@QUABBIN.SCRC.Symbolics.COM
From: mike%acorn@mit-live-oak.arpa
Subject: "fonted" characters in CL
Cc: Common-Lisp@SU-AI.ARPA

    Date: Wed, 20 Aug 86 08:40 EDT
    From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
    
    I propose we eliminate char-font-limit and the associated concepts from
    the language.

I agree, vehemently. 

    Either that or make the specification considerably more
    tight and detailed saying how >numeric< values are interpreted.  Either
    that, or specify some >symbolic< notion of "fonts" we can live with.
    
I don't think this is a good idea for CL, see more below.

    Symbolics found that the CL notion of "fonts" is not very portable, nor
    is it very useful.

    ......
    
    What we have done instead (note I don't want to push this and I'm not
    sure the development staff does either since only beta-test sites have
    seen this so far) is to define a character to have the following
    attributes:
    	A character set
    	A code within the character set
    	Bits
    	Style
    The character set and code within character set is roughly char-code.
    Bits are as per CLtL.  Style is a symbolic notion of what the characters
    LOOK like, for example, bold, italic, small, very-large, fixed width,
    etc, and combinations.  A "font" is a set of glyphs.  A font is mapped
    to by the triple character-set, style and output device.

Let me dramatize for a second to make a point.  I don't see "size",
"rotation", "shading", "projection", "mask", "color",... why don't we
just put TROFF in format macros and throw that in too. This
would give us a full composition language....

Now don't get me wrong. I agree completely with the MOTIVATION for
the new symbolics way of representing characters. It acknowledges
that characters are complex objects having lots of relative
attributes, etc., and that quick little hacks with font "bits" and
numbers up to some limit won't work for real high-quality output.
However, I see no reason for this to become part of a language
standard. The users of common lisp are NOT primarily typographers. 

High quality screen output should be discussed w.r.t. a window system
standard.  (Note: there seems to be no de-facto standard here.)  High
quality printer output should be discussed w.r.t. an output device
standard.  (Note: there are two emerging standards here... Postscript
and Interpress. Trademarks of somebody...) Without these notions,
having "font" information is just clutter in the language.

Concretely. I think char-font-limit = 1, (char-font <char>) = 0
should always be the case, and that ultimately we should drop
the font concept from the language. (like I said, I agree vehemently...)


...mike beckerle
Gold Hill Computers


∂26-Aug-86  0057	pyramid!bein@hplabs.HP.COM 	re: synonym streams.. 
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 26 Aug 86  00:57:25 PDT
Received: by hplabs.HP.COM ; Tue, 26 Aug 86 00:55:52 pdt
Received: by pyramid (5.51/3.14)
	id AA24121; Tue, 26 Aug 86 00:50:52 PDT
Date: 26 Aug 1986 00:48 PDT
From: David Bein <pyramid!bein@hplabs.HP.COM>
Subject: re: synonym streams..
To: common-lisp@su-ai
Message-Id: <525418881/bein@pyramid>

  Regarding David Moon's comment about what sensible programmers should do,
I agree wholeheartedly. It is somewhat clearer that streams come
in more flavors than just what OPEN will return (as currently defined
in both CLtL and various LispMachine manuals for existing implementations).

  David's suggestion seems to omit the need for making streams more usable.
Closing down a stream (whether it be the product of some composite
operation like make-broadcast-stream or not) is a reasonable thing
to want to do. I think the issue here is deciding whether or not
the programmer/user has an adequate amount of flexibility in
this area.

	 ONE QUESTION for the designers:

    Why was there no function like

	(MAKE-FILTER-STREAM '<input-stream>
			    '<output-stream>
			    '<function-of-2-args>)
 
where function gets passed both streams and does input from <input-stream>
filtering it in some way and possibly doing some output to
<output-stream>?

  I really wish that the original specification for streams had
included itself in the typing system. I feel that it would have
been cleaner to define one function called:

	(stream-message stream :keyword <...>)

much in the object-oriented spirit. I can think of some esoteric
methods I would have added certainly, but the most important ones
include being able to differentiate amongst streams, interrogating
streams and applying a handful of options to alter how close behaves
on any stream.

  Below the ====='ed line is my proposal.

  I welcome comments,modifications,critcisms, et al to the proposal
presented below.

--David

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

(typep stream 'stream)

	(stream-message stream :type)

		Returns stream type, e.g. synonym-stream.
		This should return something rather specialized.
		Those who feel that TYPE-OF would answer this
		need might consider what kinds of hair seem
		to be in most implementations of TYPE-OF.

	(stream-message stream :operations)

		Returns a list of operations which make
		sense for this stream. Defined to not
		recurse into streams underneath.

(typep stream 'broadcast-stream)

	(stream-message stream :broadcasters)

		Returns a list of the streams to broadcast to.

(typep stream 'synonym-stream)

	(stream-message stream :synonym)

		Returns the symbol which the stream is synonymous with.

	(stream-message stream :sanity-check)

		Returns T if the stream contains no loops like
		the kind which bite KMP and others (me too). Otherwise,
		returns NIL which means that this stream is inherently
		unsafe. NOTE: I know this is out of place and definitely
		smells bad. I could live with out this one I guess.

(or (typep stream 'two-way-stream)
    (typep stream 'echo-stream))

	(stream-message stream :input)

		Returns the input stream.

	(stream-message stream :output)

		Returns the output stream.

(I think of echo streams as a specialization of two-way streams.)

(typep stream 'concatenated-stream)

	(stream-message stream :sources)

		Returns a list of the input streams.

(typep stream 'stream)		;; CLOSE attributes

	(stream-message stream :close-forever)

		Marks this stream as one which CLOSE
		should render unsuable and which
		should have CLOSE applied to its
		children. This is the DEFAULT for
		streams produced by OPEN or
		MAKE-<COMMON>-STREAM.

	(stream-message stream :close-never)

		Marks this stream as always open.
		A CLOSE will not look to see if
		this stream has children.

	(stream-message stream :close-parent)

		Marks this stream as one which CLOSE
		renders unusable but does not touch
		any streams underneath.

	(stream-message stream :close-children)

		Marks this stream as one which never closes
		but a CLOSE applied to it will be applied
		to streams underneath.

(typep stream 'stream)		;; CLOSE and ERROR

	(stream-message stream :close-no-error)

		Permit this stream to be CLOSEd. This
		is the DEFAULT for streams produced by
		OPEN,MAKE-<COMMON>-STREAM.

	(stream-message stream :close-error)

		Marks this stream in such a way that
		a CLOSE of it causes an error. Handy for
		things like (close *terminal-io*) where
		it probably does not make sense to close it.



∂26-Aug-86  0653	preece%ccvaxa@gswd-vms.ARPA 	Re: More words on the scoping of dec
Received: from GSWD-VMS.ARPA by SAIL.STANFORD.EDU with TCP; 26 Aug 86  06:53:37 PDT
Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.51/)
	id AA13672; Tue, 26 Aug 86 08:52:57 CDT
Message-Id: <8608261352.AA13672@gswd-vms.ARPA>
Date: Tue, 26 Aug 86 08:51:24 cdt
From: preece%ccvaxa@gswd-vms.ARPA (Scott E. Preece)
To: COMMON-LISP@su-ai.arpa
Subject: Re: More words on the scoping of dec

> From: mike%acorn@mit-live-oak.arpa
> The scoping of a declaration in a let* should be as close as possible
> to that of a let. I think repeated names should be allowed, and the
> innermost one should be the one to which the declaration applies.
----------
I agree that repeated names should be allowed, but I think the
declaration should apply to the ENTIRE set of bindings, not just
the innermost.  If the user wants to have different declarations
for the repeated instances of the name, she can break the LET*
into nested LET*s.  If, on the other hand, she is playing games
and doing a multi-step calculation of a value in the header of the LET*,
the one declaration should apply to all parts of it.

-- 
scott preece
gould/csd - urbana
uucp:	ihnp4!uiucdcs!ccvaxa!preece
arpa:	preece@gswd-vms

∂26-Aug-86  0904	RAM@C.CS.CMU.EDU 	More words on the scoping of declarations 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Aug 86  09:04:12 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 26 Aug 86 12:03:22-EDT
Date: Tue, 26 Aug 1986  12:03 EDT
Message-ID: <RAM.12233911549.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   mike%acorn@LIVE-OAK.LCS.MIT.EDU
Cc:   Common-Lisp@SU-AI.ARPA, Pavel.pa@XEROX.COM
Subject: More words on the scoping of declarations
In-reply-to: Msg of 26 Aug 1986  00:09-EDT from mike%acorn at mit-live-oak.arpa


    Actually I wasn't primarily worried about the meaning of repeated
LET* variables, supposing they are legal.  I was more concerned about
the scope in LET* of declarations which don't pertain to a particular
variable.   In LET* there isn't a clear environment division which can
contain these "pervasive" declarations.

I can think of two reasonable scopes for pervasive declarations in LET*: 
 1] The declarations syntactically enclose all of the incremental
    environments in the LET*, and thus affect all init forms as well as
    the body.
 2] The declarations affect only the innermost environment, and thus
    are in effect only in the body, and in none of the init forms.

I favor the latter interpretation, since it more closely resembles the
scoping in LET.  In any case, it seems that LET* must special-case the
declarations depending on whether they are "pervasive" or not.
Although the concept of a pervasive declaration seems to cause Pavel
to cringe, I am not yet convinced that it is a bankrupt idea.

  Rob

∂27-Aug-86  0925	Gregor.pa@Xerox.COM 	Fixing optional arguments?   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Aug 86  09:24:48 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 27 AUG 86 09:24:26 PDT
Date: 27 Aug 86 09:24 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Fixing optional arguments?
To: Common-Lisp@SU-AI.arpa
cc: Gregor.pa@Xerox.COM
Message-ID: <860827-092426-1167@Xerox>

A standard problem with optional arguments in Common Lisp is that it
difficult to use the fact that a function was only called with n
arguments to call some other function with only n arguments.  For
example:

(defun foo (x &optional (y nil y-p))
  ...
    (if y-p
        (bar x y)
        (bar x)))

This is a proposed solution to that problem.

- The default default value for an optional argument is the value of the
constant UNSUPPLIED-OPTIONAL-ARGUMENT (instead of nil).

So given the definition (defun foo (x &optional y) y).  (foo 1) would
return the value of the constant unsupplied-optional-argument.

- When function call sees the value of unsupplied-optional-argument
being used as an argument to a function, it treats it as an unsupplied
value for an optional argument.  As an important performance
optimization, any arguments following unsupplied-optional-argument are
also discarded.

The example becomes:

(defun foo (x &optional y)
  ...
  (bar x y) ..)


In addition, it is possible to write code like:

 ...
 (when <something>
    ;; We are only going to call baz with 2 arguments.
    (setq arg-3 unsupplied-optional-argument))
 (baz arg-1 arg-2 arg-3 arg-4)

In this example, the call to baz will be as if only two arguments were
supplied.


The supplied-p variable stuff is also no longer needed since the same
thing can be determined by using (unsupplied-optional-argument-p <arg>).


∂27-Aug-86  1058	FAHLMAN@C.CS.CMU.EDU 	Fixing optional arguments?  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Aug 86  10:54:26 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 27 Aug 86 13:52:08-EDT
Date: Wed, 27 Aug 1986  13:51 EDT
Message-ID: <FAHLMAN.12234193461.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Gregor Kiczales <Gregor.pa@XEROX.COM>
Cc:   Common-Lisp@SU-AI.ARPA
Subject: Fixing optional arguments?
In-reply-to: Msg of 27 Aug 1986  12:24-EDT from Gregor Kiczales <Gregor.pa at Xerox.COM>


This could be done by convention, without any change to the language, as
long as both the caller and the callee know and observe the same
convention.

-- Scott

∂27-Aug-86  1846	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	Fixing optional arguments?    
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 27 Aug 86  18:46:22 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 7902; Wed 27-Aug-86 21:14:17 EDT
Date: Wed, 27 Aug 86 21:14 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Fixing optional arguments?
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
    Gregor Kiczales <Gregor.pa@XEROX.COM>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12234193461.BABYL@C.CS.CMU.EDU>
Message-ID: <860827211406.7.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

    Date: Wed, 27 Aug 1986  13:51 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    This could be done by convention, without any change to the language, as
    long as both the caller and the callee know and observe the same
    convention.

Sure, but I think that misses the point.  Suppose I have a function that
looks like
	(defun foo (a &optional b c &rest d &key e)
	  ...)
and somebody calls it with B or C being the value of unsupplied-...  That
means I would have to put a prelude function in that looks roughly like
	(tagbody
	  (cond ((eq b unsupplied...)
		 (go b-is-unsupplied))
		((eq c unsupplied...)
		 (go c-is-unsupplied)))
       b-is-unsupplied
	  (setq c unsupplied...)
       c-is-unsupplied
	  (setq d nil
		e unsupplied...))
	  (setq c unsupplied...)
	  (go c-unsupplied))
in order to make all the unsupplieds consistent.  

It also means I can't
	(when (not b)
	  (setq b (compute-b-default)))
since B is not NIL.  This is a rather major change to the language.
There is probably some validity behind it someplace, but history
probably won't allow it.

Gregor, does multiple-value-call solve any of your problems?
	(multiple-value-call #'bar
	  arg-1 arg2
	  (if <something>
	      (values)
	      (values arg-3 arg-4)))
?

∂28-Aug-86  1122	Gregor.pa@Xerox.COM 	Re: Fixing optional arguments?    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Aug 86  11:22:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 28 AUG 86 11:19:26 PDT
Date: 28 Aug 86 11:18 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: Fixing optional arguments?
In-reply-to: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>'s message
 of Wed, 27 Aug 86 21:14 EDT
To: DCP@QUABBIN.SCRC.Symbolics.COM
cc: Fahlman@C.CS.CMU.EDU, Gregor.pa@Xerox.COM, Common-Lisp@SU-AI.ARPA
Message-ID: <860828-111926-2340@Xerox>

    From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
    Subject: Fixing optional arguments?

    and somebody calls it with B or C being the value of unsupplied-...  That
    means I would have to put a prelude function in that looks roughly like

No you wouldn't have to put such a prelude.  As soon as function call sees the
value of unsupplied-optional-argument it drops the rest of the arguments on
the floor.

	(multiple-value-call #'bar
	  arg-1 arg2
	  (if <something>
	      (values)
	      (values arg-3 arg-4)))

I don't see that as being much easier than saying:

   (if <something>
     (foo arg-1 arg-2)
     (foo arg-1 arg-2 arg-3 arg-4))


∂28-Aug-86  1216	RAM@C.CS.CMU.EDU 	Fixing optional arguments? 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Aug 86  12:14:07 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 28 Aug 86 15:14:00-EDT
Date: Thu, 28 Aug 1986  15:13 EDT
Message-ID: <RAM.12234470538.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   Gregor Kiczales <Gregor.pa@XEROX.COM>
Cc:   Common-Lisp@SU-AI.ARPA
Subject: Fixing optional arguments?
In-reply-to: Msg of 28 Aug 1986  14:18-EDT from Gregor Kiczales <Gregor.pa at Xerox.COM>


    I don't think that we should significantly change the language in
a way that will adversely affect the performance of many
implementations to get an enhancement that is of marginal utility at
best.

    Many implementations on stock hardware use a link-table to resolve
the optional arg entry points at load time, thus eliminating any
run-time arg-count dispatching.  The change you propose would make
this impossible since there would be no way for the compiler to tell
how many "real" arguments are being supplied.

    Even if we disregard this efficiency issue, we would have good
reason to reject the proposal as being too radical a change in
language semantics.

  Rob

∂29-Aug-86  0956	@DIAMOND.S4CC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	Re: Fixing optional arguments? 
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 29 Aug 86  09:56:00 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by DIAMOND.S4CC.Symbolics.COM via INTERNET with SMTP id 8447; 29 Aug 86 12:52:16 EDT
Date: Fri, 29 Aug 86 12:50 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: Fixing optional arguments?
To: Gregor Kiczales <Gregor.pa@Xerox.COM>,
    DCP@QUABBIN.SCRC.Symbolics.COM
cc: Fahlman@C.CS.CMU.EDU, Common-Lisp@SU-AI.ARPA
In-Reply-To: <860828-111926-234@Xerox>
Message-ID: <860829125053.7.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

    Date: 28 Aug 86 11:18 PDT
    From: Gregor Kiczales <Gregor.pa@Xerox.COM>

	From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
	Subject: Fixing optional arguments?

	and somebody calls it with B or C being the value of unsupplied-...  That
	means I would have to put a prelude function in that looks roughly like

    No you wouldn't have to put such a prelude.  As soon as function call sees the
    value of unsupplied-optional-argument it drops the rest of the arguments on
    the floor.

I guess that depends a lot on how your architecture does function
calling.  Many machines currently do not look at the value of the
arguments, partly for historical reasons, partly for speed and perhaps
partly for ease of implementation.  It would also have to be very
careful if some CL extension included the MultiLisp concept of futures.
In that case, you DON'T want to examine the data (or you have to do so
very carefully) for fear of forcing the contained computation to
complete.



∂31-Aug-86  1341	LOOSEMORE@UTAH-20.ARPA 	question about pprint, *print-pretty*    
Received: from UTAH-20.ARPA by SAIL.STANFORD.EDU with TCP; 31 Aug 86  13:41:15 PDT
Date: Sun 31 Aug 86 14:39:44-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: question about pprint, *print-pretty*
To: common-lisp@SU-AI.ARPA
Message-ID: <12235272600.9.LOOSEMORE@UTAH-20.ARPA>

In Common Lisp, both print and pprint are defined to print out a newline
*before* the form rather than after.  This is backwards from PSL, where
the prettyprinter indents things relative to the "current" character
position on the output stream, and prints a newline afterwards.  Is there
a portable way I can get the same kind of relative indentation in Common
Lisp?  Exactly what turning on *print-pretty* does is left rather vague --
the manual just says the printer should insert more whitespace.  Is there
some overwhelming reason why these functions were defined "backwards" in
the first place that I've missed?

-Sandra
-------

∂02-Sep-86  0909	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	question about pprint, *print-pretty*   
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 2 Sep 86  09:08:53 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72015; Tue 2-Sep-86 12:05:08 EDT
Date: Tue, 2 Sep 86 12:05 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: question about pprint, *print-pretty*
To: common-lisp@SU-AI.ARPA
In-Reply-To: <12235272600.9.LOOSEMORE@UTAH-20.ARPA>
Message-ID: <860902120503.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sun 31 Aug 86 14:39:44-MDT
    From: SANDRA <LOOSEMORE@UTAH-20.ARPA>

    In Common Lisp, both print and pprint are defined to print out a newline
    *before* the form rather than after.  This is backwards from PSL, where
    the prettyprinter indents things relative to the "current" character
    position on the output stream, and prints a newline afterwards.  Is there
    a portable way I can get the same kind of relative indentation in Common
    Lisp?  Exactly what turning on *print-pretty* does is left rather vague --
    the manual just says the printer should insert more whitespace.  Is there
    some overwhelming reason why these functions were defined "backwards" in
    the first place that I've missed?

I don't know if this is an overwhelming reason, but PRINT has always printed
the newline first, all the way back to Lisp 1.5 (check the blue and white Lisp 1.5
manual).  I think it's intentional that the definition of what it means to
print prettily is left rather vague, since different implementations have
different ideas about what looks pretty and about how effort they are willing
to expend to make something look pretty.

Surely binding *PRINT-PRETTY* to T is not supposed to turn PRIN1 into
PPRINT.  In other words, PRIN1 with *PRINT-PRETTY* = T should not print
a leading newline, should indent things relative to the current
character position on the output stream, and should not print a trailing
newline.  Next time the manual should include definitions of all of these
functions in terms of WRITE, instead of only defining half of them!

∂02-Sep-86  0909	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	question about pprint, *print-pretty*   
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 2 Sep 86  09:09:18 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72016; Tue 2-Sep-86 12:05:55 EDT
Date: Tue, 2 Sep 86 12:05 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: question about pprint, *print-pretty*
To: common-lisp@SU-AI.ARPA
In-Reply-To: <12235272600.9.LOOSEMORE@UTAH-20.ARPA>
Message-ID: <860902120550.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sun 31 Aug 86 14:39:44-MDT
    From: SANDRA <LOOSEMORE@UTAH-20.ARPA>

    In Common Lisp, both print and pprint are defined to print out a newline
    *before* the form rather than after.  This is backwards from PSL, where
    the prettyprinter indents things relative to the "current" character
    position on the output stream, and prints a newline afterwards.  Is there
    a portable way I can get the same kind of relative indentation in Common
    Lisp?  Exactly what turning on *print-pretty* does is left rather vague --
    the manual just says the printer should insert more whitespace.  Is there
    some overwhelming reason why these functions were defined "backwards" in
    the first place that I've missed?

I don't know if this is an overwhelming reason, but PRINT has always printed
the newline first, all the way back to Lisp 1.5 (check the blue and white Lisp 1.5
manual).  I think it's intentional that the definition of what it means to
print prettily is left rather vague, since different implementations have
different ideas about what looks pretty and about how effort they are willing
to expend to make something look pretty.

Surely binding *PRINT-PRETTY* to T is not supposed to turn PRIN1 into
PPRINT.  In other words, PRIN1 with *PRINT-PRETTY* = T should not print
a leading newline, should indent things relative to the current
character position on the output stream, and should not print a trailing
newline.  Next time the manual should include definitions of all of these
functions in terms of WRITE, instead of only defining half of them!

I think the answer to your question is to call WRITE and then TERPRI.

∂02-Sep-86  1149	KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	PRINT 
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 2 Sep 86  11:48:56 PDT
Received: from EMU.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72179; Tue 2-Sep-86 14:47:52 EDT
Date: Tue, 2 Sep 86 14:47 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: PRINT
To: Common-Lisp@SU-AI.ARPA
cc: KMP@SCRC-STONY-BROOK.ARPA
References: <860902120550.6.MOON@EUPHRATES.SCRC.Symbolics.COM>,
            <12235272600.9.LOOSEMORE@UTAH-20.ARPA>
Message-ID: <860902144720.7.KMP@EMU.SCRC.Symbolics.COM>

If we get to a point where we're capable of contemplating incompatible
changes to CL, I would strongly urge the group to consider renaming
PRIN1 to PRINT (and, obviously, renaming what's currently called PRINT 
to something else). Sandra's query is not an isolated one. There is 
wide-spread confusion about what it means to "print" something because 
the operator named PRINT does more than just "print" a thing. eg, 
the :PRINT-FUNCTION specifier in DEFSTRUCT effectively defines how to
PRIN1 something, not how to PRINT something, which I think most novices 
are apt to be confused by. I think that thoughtful renaming of a few 
functions to make the English and the Lisp be consistent would go a 
long way toward fixing this kind of confusion.

∂02-Sep-86  1234	Masinter.pa@Xerox.COM 	Re: close on synonym streams, etc    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Sep 86  12:33:21 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 02 SEP 86 12:26:49 PDT
Date: 2 Sep 86 12:26 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: close on synonym streams, etc
In-reply-to: various
To: common-lisp@su-ai.ARPA
Message-ID: <860902-122649-1037@Xerox>

I still prefer "it is an error" to close streams not created with OPEN. 

However, if there is strong sentiment to allow CLOSE on pseudo-streams
like broadcast, synonym and the like, it would be the most consistent to
define it as a no-op. That is, closing a synonym stream should have no
effect.

Why?

a) this is certainly the simplest to implement. There's no need to keep
pseudo-state "open" or "closed" on streams that would otherwise not need
them.

b) this would allow the most programs to function, when handed
pseudo-streams instead of file streams. In the example of "a program
that, when encountering end-of-file closes the inpupt stream and
returns" would work when handed a synonym stream to *standard-input*.

c) it is upward compatible-- no current program would stop functioning.

d) those implementations which "cache" some information into buffered
streams could use "close" to mean "flush the cache", although this would
have no effect on the program semantics.


∂03-Sep-86  1409	RICE@SUMEX-AIM.ARPA 	Documentation strings and function.    
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 86  14:07:15 PDT
Date: Wed 3 Sep 86 11:56:07-PDT
From: James Rice <Rice@SUMEX-AIM.ARPA>
Subject: Documentation strings and function.
To: Common-Lisp@SU-AI.ARPA
Message-ID: <12236040169.57.RICE@SUMEX-AIM.ARPA>


Since one is allowed to declare the following :-

(defun foo (a b)
  "A docstring."
  (declare (special a))
  "Another docstring."
  (declare (special b))
  (frob a b))

what will the documentation be for Foo?  The book seems to be quiet on
this issue.  I would hope that it  would be either a) the two strings
concatenated (i.e. when Parse-Body (what?) returns the docstring they
are all stuck together, or b) it returns a list of docstrings.
The implemetation I am using discards all but the first.

While on the subject of documentation :-

Wouldn't it be a good idea to have a Documentation function doc type
called :All or some such, returning an AList of doctype and docstring.
Since a number of CL supporting systems will have doc types of their
own (Flavor and such like) and users might want to add their own it
would be jolly good if one could guarantee getting all of the docs
for a symbol.


Rice.
-------

∂03-Sep-86  1636	VERACSD@A.ISI.EDU 	Deletion from Mailing-List
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 86  16:36:49 PDT
Date: 3 Sep 1986 19:14-EDT
Sender: VERACSD@A.ISI.EDU
Subject: Deletion from Mailing-List
From: VERACSD@A.ISI.EDU
To: common-lisp@SU-AI.ARPA
Cc: veracsd@A.ISI.EDU
Message-ID: <[A.ISI.EDU] 3-Sep-86 19:14:52.VERACSD>


Please delete me from the mailing-list.
(I can now get it via a bulletin board.)

Thanks.

-- Cris Kobryn

∂03-Sep-86  1810	FAHLMAN@C.CS.CMU.EDU 	Documentation strings and function.   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 86  18:10:44 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 3 Sep 86 21:09:46-EDT
Date: Wed, 3 Sep 1986  21:09 EDT
Message-ID: <FAHLMAN.12236108178.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   James Rice <Rice@SUMEX-AIM.ARPA>
Cc:   Common-Lisp@SU-AI.ARPA
Subject: Documentation strings and function.
In-reply-to: Msg of 3 Sep 1986  14:56-EDT from James Rice <Rice at SUMEX-AIM.ARPA>


    Since one is allowed to declare the following :-

    (defun foo (a b)
      "A docstring."
      (declare (special a))
      "Another docstring."
      (declare (special b))
      (frob a b))

What makes you think that one is allowed to declare the preceding?  I
believe that this form is illegal, and that the resulting doc-string is
therefore undefined.  See page 67 about a third of the way down: "It is
an error if more than one doc-string is present."  Since that second
string cannot be a doc string, the second declare form is in an illegal
position.

-- Scott

∂03-Sep-86  1929	@WAIKATO.S4CC.SYMBOLICS.COM:KMP@STONY-BROOK.SCRC.Symbolics.COM 	Documentation strings and function. 
Received: from [128.81.51.90] by SAIL.STANFORD.EDU with TCP; 3 Sep 86  19:29:06 PDT
Received: from EMU.SCRC.Symbolics.COM by WAIKATO.S4CC.SYMBOLICS.COM via CHAOS with CHAOS-MAIL id 54912; Wed 3-Sep-86 21:58:28 EDT
Date: Wed, 3 Sep 86 21:57 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Documentation strings and function.
To: Fahlman@CMU-CS-C.ARPA
cc: Common-Lisp@SU-AI.ARPA, Rice@SUMEX-AIM
In-Reply-To: <FAHLMAN.12236108178.BABYL@C.CS.CMU.EDU>
Message-ID: <860903215722.4.KMP@EMU.SCRC.Symbolics.COM>

Although I would not argue in favor of such an interpretation, I think you'd
have a tough time arguing that the restriction on p67 refers to anything other
than functions defined by DEFUN.

Both the description of DEFUN on p67 (which you cite) and the description of 
LAMBDA on p60 (which you don't comment on) use the same confusing syntax
description:
  ...
  {declaration | documentation-string}*
  ...
Well, ok, they don't. p60 refers to documentation-string and p67 refers to a
doc-string. (-: Maybe only a doc-string is constrained the way you suggest but
a documentation-string is not. :-)

[On an unrelated issue that I noticed on the same page, p67 should clearly
 say that 
  (DEFUN name lambda-list {declaration|doc-string}* {form}*)
 causes the symbol NAME to be a global name for the function specified by
 the lambda expression
  (LAMBDA lambda-list {declaration|doc-string}* (BLOCK name {form}*))
 Otherwise, the ability of RETURN-FROM to work in a DEFUN seems just a little
 too magical, and suggests that LAMBDA or DEFUN somehow interacts with RETURN-FROM
 in some strange way that we don't ever explain.]

Anyway, I think that multiple doc strings should not be undefined and that we
should relax that restriction. They would be especially to people (like myself) 
who get grossed out by The Indentation Problem as illustrated in:

(DEFUN FOO (X Y)
  "This is a very long documentation string which when printed out
   seems to have an obscure amount of indentation on its second and
   third line even though it looked nicely lined up in the source."
  ...)

or:

(DEFUN FOO (X Y)
  "This is a very long documentation string which when printed out
has no problem about indentation for the subsequent lines, but when
viewed in the source looks pretty yucky."
  ...)

I'd prefer:

(DEFUN FOO (X Y)
  "This is how we might allow a very long documentation string to be"
  "typed in in order to let it look good in the source and also to"
  "let it look good when obtained later, perhaps as a single string with"
  "newlines inserted between each of the pieces.")

This would also be handy for defmacro, since you could prefix or postfix
documentation strings in the expansion without worrying about whether the
user was also going to supply a documentation string that elaborated on
the standardly provided documentation.

∂04-Sep-86  0739	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	Documentation strings and function.
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 4 Sep 86  07:39:21 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 9425; Thu 4-Sep-86 10:37:15 EDT
Date: Thu, 4 Sep 86 10:37 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Documentation strings and function.
To: James Rice <Rice@SUMEX-AIM.ARPA>,
    Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
    Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>,
    Common-Lisp@SU-AI.ARPA
In-Reply-To: <12236040169.57.RICE@SUMEX-AIM.ARPA>,
             <FAHLMAN.12236108178.BABYL@C.CS.CMU.EDU>,
             <860903215722.4.KMP@EMU.SCRC.Symbolics.COM>
Message-ID: <860904103704.6.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

When I brought up the multiple-doc-string issue when we were discussing
parse-body, everybody seemed unanimous that the current book intended
that the first string was the only doc string and that subsequent
strings were part of the executable body (and therefore declarations
after the second string were an error).

Anyway, I was then and am willing to continue believing multiple doc
strings should be OK, though I don't have strong enough opinions to take
sides.  If multiple doc strings are allowed, what does parse-body (if we
ever decide on what that should be and do) return?  Should it return a
list of the doc strings (in the order encountered)?  Should it return
one string with newlines between the individual strings?  What does
(documentation 'foo 'defun) return?  A list of strings?  One string with
newlines or some other separator?

∂04-Sep-86  0853	allen@bfly-vax.bbn.com 	Re: Documentation strings and function.  
Received: from BFLY-VAX.BBN.COM by SAIL.STANFORD.EDU with TCP; 4 Sep 86  08:53:52 PDT
To: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
cc: James Rice <Rice@sumex-aim.ARPA>, Common-Lisp@su-ai.ARPA, 
    allen@bfly-vax.bbn.com
Subject: Re: Documentation strings and function.
In-reply-to: Your message of Wed, 3 Sep 1986  21:09 EDT.
	     <FAHLMAN.12236108178.BABYL@C.CS.CMU.EDU>
Date: 04 Sep 86 11:45:55 EDT (Thu)
From: allen@bfly-vax.bbn.com

Scott:
It would seem that "It is an error if more than one doc-string is present"
is inconsistent with the syntactic description of defun at the top of page 67.
I refer specifically to the {declaration | doc-string}* segment, which 
implies a free mix of any number of declarations and doc-strings. Rice's
example is legal, if one relies on the latter. It should be decided which
is correct, and the appropriate repair made to the book. 

/Don
    


∂04-Sep-86  0945	FAHLMAN@C.CS.CMU.EDU 	Documentation strings and function.   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 86  09:45:47 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 4 Sep 86 12:44:23-EDT
Date: Thu, 4 Sep 1986  12:44 EDT
Message-ID: <FAHLMAN.12236278321.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   allen@BFLY-VAX.BBN.COM
Cc:   Common-Lisp@SU-AI.ARPA
Subject: Documentation strings and function.
In-reply-to: Msg of 4 Sep 1986  11:45-EDT from allen at bfly-vax.bbn.com


Well, there are things that are hard to express in the simple syntactic
notation Guy chose to use: exactly three of these things are allowed if
and only if one of those things is present, etc.  I think that there are
several places in the book where the syntactic expressions provide some
necessary conditions, but where further restrictions on the format are
specified by the text.

In order to fix all of these things, so that the syntactic expressions
provide a necessary and sufficient formal grammar for the language, we
would have to go to a much more complex notation, which would be
much tougher on the average reader.  I think that the current system,
where there are syntactic expressions that are sometimes further
restricted by English statements, is the way to go.

I agree that the statement forbidding multiple doc-strings should not be
as well-hidden as it currently is.  The fact that people have missed it
is pretty good evidence that it is not visible enough.

-- Scott

∂04-Sep-86  1038	LINNDR%VUENGVAX.BITNET@WISCVM.WISC.EDU 	Problems with Notation in CLtL
Received: from WISCVM.WISC.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 86  10:37:50 PDT
Received: from (LINNDR)VUENGVAX.BITNET by WISCVM.WISC.EDU on 09/04/86
  at 12:37:07 CDT
Date:     Thu, 4 Sep 86 12:27 CST
From:        <LINNDR%VUENGVAX.BITNET@WISCVM.WISC.EDU> (David Linn)
Subject:  Problems with Notation in CLtL
To:  Common-Lisp@SU-AI.ARPA
X-Original-To:  Common-Lisp@SU-AI.ARPA, LINNDR

>Well, there are things that are hard to express in the simple syntactic
>notation Guy chose to use: exactly three of these things are allowed if
>and only if one of those things is present, etc.  I think that there are
>several places in the book where the syntactic expressions provide some
>necessary conditions, but where further restrictions on the format are
>specified by the text.
>
>In order to fix all of these things, so that the syntactic expressions
>provide a necessary and sufficient formal grammar for the language, we
>would have to go to a much more complex notation, which would be
>much tougher on the average reader.  I think that the current system,
>where there are syntactic expressions that are sometimes further
>restricted by English statements, is the way to go.
>
>I agree that the statement forbidding multiple doc-strings should not be
>as well-hidden as it currently is.  The fact that people have missed it
>is pretty good evidence that it is not visible enough.
>
>-- Scott
>
-------------------------------------------------------------------------
Would it be appropriate to provide a second reference to clear up this
confusion? If sufficient notation would make CLtL impenetrable for the
average reader, could not a reference with sufficient notation be made
availble for those with the desire to wade through it?

David Linn
LINNDR@VUENGVAX.BITNET
LINNDR%VUEGNVAX.BITNET@WISCVM.WISC.EDU          ! Internet (I think)
...!psuvax1!vuengvax.bitnet!linndr              ! uucp/USENET

∂04-Sep-86  1102	allen@bfly-vax.bbn.com 	Re: Documentation strings and function.  
Received: from BFLY-VAX.BBN.COM by SAIL.STANFORD.EDU with TCP; 4 Sep 86  11:02:48 PDT
To: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
cc: allen@bfly-vax.bbn.com, Common-Lisp@su-ai.ARPA
Subject: Re: Documentation strings and function.
In-reply-to: Your message of Thu, 4 Sep 1986  12:44 EDT.
	     <FAHLMAN.12236278321.BABYL@C.CS.CMU.EDU>
 -------- 
Scott: 
Date: 04 Sep 86 13:55:50 EDT (Thu)
From: allen@bfly-vax.bbn.com

It may be that there are aspects of the language that are hard or
impossible to express in Guy's simple notation. Since I think that
simplicity is a virtue, I would advocate retaining the notation and in
those cases where it is insufficient the description can be augmented
with (non-well-hidden) English.

For this case though, if we agree that the sentence midway thru pg 67
is The Truth, then how about

defun name lambda-list {declaration}* [doc-string] {declaration}* {form}*

/don

∂04-Sep-86  1222	FAHLMAN@C.CS.CMU.EDU 	Documentation strings and function.   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 86  12:22:43 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 4 Sep 86 15:21:09-EDT
Date: Thu, 4 Sep 1986  15:20 EDT
Message-ID: <FAHLMAN.12236306826.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   allen@BFLY-VAX.BBN.COM
Cc:   Common-Lisp@SU-AI.ARPA
Subject: Documentation strings and function.
In-reply-to: Msg of 4 Sep 1986  13:55-EDT from allen at bfly-vax.bbn.com



    defun name lambda-list {declaration}* [doc-string] {declaration}* {form}*

Yes, it looks like this is the right way to express things in this case.

-- Scott

∂04-Sep-86  1421	Bobrow.pa@Xerox.COM 	Re: Documentation strings and function.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Sep 86  14:21:06 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 04 SEP 86 14:00:42 PDT
Date: 4 Sep 86 13:58 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Documentation strings and function.
In-reply-to: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>'s message
 of Thu, 4 Sep 86 10:37 EDT
To: DCP@QUABBIN.SCRC.Symbolics.COM
cc: Rice@SUMEX-AIM.ARPA, Fahlman@C.CS.CMU.EDU,
 KMP@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp@SU-AI.ARPA
Message-ID: <860904-140042-1593@Xerox>

  If multiple doc strings are allowed, what does parse-body
 (if we ever decide on what that should be and do) return? 

A single string or a list of such, so that these are distinguished.


-- danny

∂04-Sep-86  1421	Bobrow.pa@Xerox.COM 	Re: Documentation strings and function.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Sep 86  14:20:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 04 SEP 86 14:00:40 PDT
Date: 4 Sep 86 13:56 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Documentation strings and function.
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Thu,
 4 Sep 86 12:44 EDT
To: Fahlman@C.CS.CMU.EDU
cc: allen@BFLY-VAX.BBN.COM, Common-Lisp@SU-AI.ARPA
Message-ID: <860904-140040-1592@Xerox>

I think multiple document strings should be allowed.  Perhaps all should
precede any declarations.  The argument for multiple document strings is
that one can then use a simple parsing program to collect documentation
from code.  One could imagine a convention of the first document string
describing the external interface or purpose of a document, and the
second information about the implementation.  Why isn't the syntax

... lambda-list {documentation}* {declarations}* ...


-- danny

∂04-Sep-86  1518	@ELEPHANT-BUTTE.SCRC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	Re: Documentation strings and function.
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 4 Sep 86  15:18:41 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by ELEPHANT-BUTTE.SCRC.Symbolics.COM via INTERNET with SMTP id 74511; 4 Sep 86 18:13:36 EDT
Date: Thu, 4 Sep 86 18:13 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: Documentation strings and function.
To: Bobrow.pa@Xerox.COM, DCP@QUABBIN.SCRC.Symbolics.COM
cc: Rice@SUMEX-AIM.ARPA, Fahlman@C.CS.CMU.EDU,
    KMP@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp@SU-AI.ARPA
In-Reply-To: <860904-140042-1593@Xerox>
Message-ID: <860904181314.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

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

      If multiple doc strings are allowed, what does parse-body
     (if we ever decide on what that should be and do) return? 

    A single string or a list of such, so that these are distinguished.

I would prefer that the result would always (SATISFY LISTP).  This would
let macros do
	,@doc-strings
instead of
	,@(if (stringp doc-strings) `(,doc-strings) doc-strings)
as well as what DOCUMENTATION returns.  I think this is the case where
optimizing a singleton list to be its single component does more harm
than good.


∂04-Sep-86  1639	@ELEPHANT-BUTTE.SCRC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	Re: Documentation strings and function.
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 4 Sep 86  16:39:30 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by ELEPHANT-BUTTE.SCRC.Symbolics.COM via INTERNET with SMTP id 74534; 4 Sep 86 18:37:16 EDT
Date: Thu, 4 Sep 86 18:36 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: Documentation strings and function.
To: Bobrow.pa@Xerox.COM, Fahlman@C.CS.CMU.EDU
cc: allen@BFLY-VAX.BBN.COM, Common-Lisp@SU-AI.ARPA
In-Reply-To: <860904-140040-1592@Xerox>
Message-ID: <860904183653.9.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

Personally, I usually put the documentation strings after the
declarations.  One also has to consider macros expanding into both
documentation strings (is this really allowed?) as well as declarations.

The "simple parsing program" you allude to has been proposed under the
name of PARSE-BODY, but partly with my flaming seems to have been
stalled in committee.


∂04-Sep-86  1842	@REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU 	Re: Documentation strings and function.  
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 86  18:42:26 PDT
Received: from JONES.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 1445; Thu 4-Sep-86 21:43:56 EDT
Date: Thu, 4 Sep 86 21:43 EDT
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: Re: Documentation strings and function.
To: Bobrow.pa@Xerox.COM, Fahlman@C.CS.CMU.EDU
cc: allen@BFLY-VAX.BBN.COM, Common-Lisp@SU-AI.ARPA
In-Reply-To: <860904-140040-1592@Xerox>
Message-ID: <860904214328.1.CFRY@JONES.AI.MIT.EDU>

Expressing the current CL syntax is complicated because the syntax is unnecessarily flexible.
Let's decide on whether the first doc string should be before or after the declarations
and change the spec to reflect that.

    I think multiple document strings should be allowed.  Perhaps all should
    precede any declarations.  The argument for multiple document strings is
    that one can then use a simple parsing program to collect documentation
    from code.  One could imagine a convention of the first document string
    describing the external interface or purpose of a document, and the
    second information about the implementation.  Why isn't the syntax

    ... lambda-list {documentation}* {declarations}* ...
I've yanked in Bobrow's statement since I think he has basically the right idea.
Here's an example of the format that I use:
(defun foo (a b) "this is THE doc string. It's used for describing the functionality of
   this function as seen by the outside world."
   (declare ...)
   (declare ...)
   (some code)
   "this is a programmer comment. I use it to say things like,
     FIX UP this code someday, or this algorhythm is too slow."
   (some code)
   "maybe another programmer comment"
   (final code))

The function DOCUMENTTION returns the top doc string.
My own function PROGRAMMER-COMMENTS returns a list of
strings. In the above example it would return the 2nd and 3rd strings
in the body. The programmer-comments above don't violate existing CL semantics.
And a clever compiler will just throw them out.

The restriction on programmer-comments is that they do not include the
first string in the body and do not include the last form in the body if that happens 
to be a string. The flexibility of whether doc strings or declarations go first
or intermingle is unncessarily confusing for both human and machine.

I find being able to imbed programer-comments in a definition and have a program that
can find them helps me make notes to myself in code. Frequently you know something is 
not working well but can't fix it at the moment. Having a convenient way to store
the information which a machine can get at and tell you about it when you ask 
is a great reminder.

∂05-Sep-86  1236	gls@Think.COM 	Problems with Notation in CLtL
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 5 Sep 86  12:35:22 PDT
Received: from katherine by Godot.Think.COM via CHAOS; Fri, 5 Sep 86 15:31:51 edt
Date: Fri, 5 Sep 86 15:32 EDT
From: Guy Steele <gls@Think.COM>
Subject: Problems with Notation in CLtL
To: LINNDR%VUENGVAX.BITNET@WISCVM.WISC.EDU, Common-Lisp@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <8609041739.AA09293@Zarathustra.Think.COM>
Message-Id: <860905153241.6.GLS@KATHERINE.THINK.COM>

    Date:     Thu, 4 Sep 86 12:27 CST
    From: <LINNDR%VUENGVAX.BITNET@WISCVM.WISC.EDU> (David Linn)
    Would it be appropriate to provide a second reference to clear up this
    confusion? If sufficient notation would make CLtL impenetrable for the
    average reader, could not a reference with sufficient notation be made
    availble for those with the desire to wade through it?

The construction of an accurate if impenetrable reference for CLtL is
merely "a small matter of writing".  Sounds like a job for ANSI X3J13.
Any volunteers?  The first meeting, as has already been announced on this
mailing list, is in Washington D.C. on September 23-24.  Be there or
be square.

--Guy

∂05-Sep-86  2358	ELIOT%cs.umass.edu@CSNET-RELAY.ARPA 	Programmer Notes  
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 5 Sep 86  23:58:43 PDT
Received: from umass-cs by csnet-relay.csnet id bl04873; 6 Sep 86 2:27 EDT
Date:     Fri, 5 Sep 86 19:40 EST
From:     ELIOT%cs.umass.edu@CSNET-RELAY.ARPA
To:       Common-Lisp@SU-AI.ARPA
Subject:  Programmer Notes
X-VMS-To: CSNET%"Common-Lisp@SU-AI.arpa"

When I want to leave a note to myself I include a comment with (...) in it.
This can easilly be found by a program (EMACS/ZWEI) and then I am
even in context where I can do something about it.  Along this line, 
I have often wanted to make the symbol ... be a special symbol which can
always be read, but whose evaluation always signals an error.  In NIL
the symbol ... causes the compiler to bomb, so you can't use it to
indicate unimplemented functions (GJC!).  I think that LISPMs can read
that symbol and do reasonable things with it.  (Make it a special.)

I think that one documentation string is enough, the rest can be
ignored by any sufficiently smart compiler given the semantics of the
language, and anyone who builds a really nice Commmon Lisp environment
is welcome to extend the notion of documentation strings to include
multiple ones.

Most people are, I think, under the impression that documentation strings
can only be supplied once per function and so multiple documentatoin
strings are, de facto, a change to Common Lisp.  This is a very unimportant
kind of thing to worry about, and I suggest it isn't worth it.  I don't
care one way or the other, except that I think we need to have a standard.

A much more important issue is to define a syntactic standard for these kind
of things.  There are several places in CLtL where it is suggested that
some entity fit into a sentence-schema in a certain way. I think that these
guidlines should be made strict requirements, and I think that a good
sentence-schema for documentation strings would be appropriate.


...Now back to important things, like message passing and declaration
scoping=>

∂07-Sep-86  1646	KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	#+FOO:BAR  
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 7 Sep 86  16:46:37 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75402; Sat 6-Sep-86 16:42:35 EDT
Date: Sat, 6 Sep 86 16:42 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: #+FOO:BAR
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860906164226.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

We need to rule on whether people can say:
 #+FOO:BAR
 #+(AND FOO:BAR ...)
if FOO is a potentially non-existent package and/or BAR is a
potentially non-exported symbol. My feeling is that in both
cases, these should be treated as "failing" features but should
not signal read errors.

There are other things that should be resolved about #+/#-, too.
Such as what package it defaultly reads in, whether there are any
standard features we can all agree on which should be in some known
package, etc.

∂08-Sep-86  0909	@ELEPHANT-BUTTE.SCRC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	Programmer Notes   
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 8 Sep 86  09:09:20 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by ELEPHANT-BUTTE.SCRC.Symbolics.COM via INTERNET with SMTP id 76279; 8 Sep 86 11:58:01 EDT
Date: Mon, 8 Sep 86 11:57 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Programmer Notes
To: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 5 Sep 86 20:40 EDT from ELIOT%cs.umass.edu@CSNET-RELAY.ARPA
Message-ID: <860908115735.1.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

Re: ... try using ---, since CLtL has forbidden (unquoted) symbols
consisting soley of dots.

I think it is a VERY BAD idea to encourage "really nice CL envirnoment"
to extend the concept of documentation strings to multiple documentation
strings.  That is encouraging >gratuitous< incompatibility.  We should
decide what we want and make the description and the prose match the
decision.


∂11-Sep-86  0839	MATT@LL.ARPA 	 
Received: from LL.ARPA by SAIL.STANFORD.EDU with TCP; 11 Sep 86  08:39:06 PDT
Date: Thu 11 Sep 1986 11:36:59 EDT
From: <MATT@LL.ARPA>
Subject: 
To: COMMON-LISP@SU-AI 
Message-ID: <MATT.25441758@LL.ARPA>

Hi,
  Please add me to your common lisp mailing list.  Thanx.
Matt Stillerman
 

∂12-Sep-86  0311	bradley@Think.COM 	An example of where setf does not do what I want.  
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 12 Sep 86  03:11:37 PDT
Received: by Godot.Think.COM; Fri, 12 Sep 86 06:11:05 edt
Message-Id: <8609121011.AA17090@Godot.Think.COM>
To: common-lisp@godot
Subject: An example of where setf does not do what I want.
Date: 12 Sep 86 06:11:02 EDT (Fri)
From: Bradley C. Kuszmaul <bradley@Think.COM>

I want to do

  (setf (apply #'aref (cons my-array dims)) value)

where MY-ARRAY, DIMS, and VALUE are bound to meaningful values

Unfortunately, my reading of SETF says that the above won't work.
If I had (ASET value array &rest dims) then I could to
  (apply #'aset (list* value my-array dims))
to do what I want.

How do I do what I want?
 -Brad

∂12-Sep-86  0814	FAHLMAN@C.CS.CMU.EDU 	An example of where setf does not do what I want.    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Sep 86  08:14:32 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 12 Sep 86 11:13:15-EDT
Date: Fri, 12 Sep 1986  11:13 EDT
Message-ID: <FAHLMAN.12238358866.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   "Bradley C. Kuszmaul" <bradley@ZARATHUSTRA.THINK.COM>
Cc:   common-lisp@SU-AI.ARPA
Subject: An example of where setf does not do what I want.
In-reply-to: Msg of 12 Sep 1986  06:11-EDT from Bradley C. Kuszmaul <bradley at Think.COM>


The inclusion of APPLY as one of the cases handled by SETF (page 96)
was prompted by exactly the case you describe:

(setf (apply #'aref (cons my-array dims)) value)

As I recall, we considered saying that (setf (apply #'aref ...) ...)
was required to work one way or another, but went with this supposedly
more general form instead: in a SETF the first argument to APPLY must be any
function known to SETF whose internal setting function is of a certain
form.

Unfortunately, when all this got written into the manual, we neglected
to say explicitly that AREF was required to be one of those functions
that works in this context (though all the examples indicate that this
is what we had in mind).  So technically, given the current wording of
the manual, it is legal for SETF of APPLY of AREF not to work.  In my
opinion, any Lisp that takes advantage of this loophole is broken, and
the manual should be clarified to require that SETF of APPLY of AREF
must work as you would expect.

Unfortunately, the Spice Lisp code seems to be broken in exactly this
way at present.  I thought we had put in a special check to handle
AREF years ago, but apparently the fix didn't take.  Other
implementations may have caught this bug from us.

-- Scott

∂12-Sep-86  0844	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	An example of where setf does not do what I want. 
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 12 Sep 86  08:43:32 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 11465; Fri 12-Sep-86 11:42:35 EDT
Date: Fri, 12 Sep 86 11:41 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: An example of where setf does not do what I want.
To: Bradley C. Kuszmaul <bradley@Think.COM>, common-lisp@SU-AI.ARPA
In-Reply-To: <8609121011.AA17090@Godot.Think.COM>
Message-ID: <860912114143.1.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

    Date: 12 Sep 86 06:11:02 EDT (Fri)
    From: Bradley C. Kuszmaul <bradley@Think.COM>

    I want to do

      (setf (apply #'aref (cons my-array dims)) value)

    where MY-ARRAY, DIMS, and VALUE are bound to meaningful values

    Unfortunately, my reading of SETF says that the above won't work.
    If I had (ASET value array &rest dims) then I could to
      (apply #'aset (list* value my-array dims))
    to do what I want.

    How do I do what I want?

Your code should work.  First, you don't need to do that consing for
apply.  The old Zetalisp APPLY only took 2 arguments, but Common Lisp
APPLY takes 2 or more (and is like Zetalisp lexpr-funcall).

Notice (in the Symbolics [7.0] implementation)
	(setf (apply #'aref my-array dims) value)
	=> (APPLY #'ZL:ASET VALUE MY-ARRAY DIMS)
and also
	(setf (apply #'aref (cons my-array dims)) value)
	=> (APPLY #'ZL:ASET VALUE (VALUES (CONS MY-ARRAY DIMS)))

To show order of evaluation is still correct:
	(setf (apply #'aref (my-array) (dims)) (value))
	=> (LET* ((#:G8656 (MY-ARRAY))
		  (#:G8657 (DIMS)))
	     NIL
	     (APPLY #'ZL:ASET (VALUES (VALUE)) #:G8656 #:G8657))
and
	(setf (apply #'aref (cons (my-array) (dims))) (value))
	=> (LET* ((#:G8659 (CONS (MY-ARRAY) (DIMS))))
	     NIL
	     (APPLY #'ZL:ASET (VALUES (VALUE)) #:G8659)) 

What "reading of SETF" are you using?  Pages 96 and 97 explicitly
describe this situation and also use AREF as the example.  What
implementation are you using and how does it expand (or fail to expand).

∂12-Sep-86  0942	fateman@renoir.Berkeley.EDU 	OPS-5 in Common Lisp 
Received: from RENOIR.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 12 Sep 86  09:41:56 PDT
Received: by renoir.Berkeley.EDU (5.53/1.16)
	id AA06052; Fri, 12 Sep 86 09:42:15 PDT
Date: Fri, 12 Sep 86 09:42:15 PDT
From: fateman@renoir.Berkeley.EDU (Richard Fateman)
Message-Id: <8609121642.AA06052@renoir.Berkeley.EDU>
To: common-lisp@Sail.Stanford.EDU
Subject: OPS-5 in Common Lisp

A student here has ported the OPS-5 code from Franz Lisp to Common Lisp.
If there are no objections from CMU, we are willing to send 
this to requestors to whom we can send electronic mail.
We would like recipient to tell us about bugs (and fixes, 
if possible) that they find.

     I don't know if there is any other OPS-5/CL version around, but
if there is a comparably "public" version, I'd be glad to compare the
two and suppress ours if ours is inferior.  

    It might lend itself to some useful benchmarking.

∂12-Sep-86  1030	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	An example of where setf does not do what I want. 
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 12 Sep 86  10:29:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79588; Fri 12-Sep-86 13:27:28 EDT
Date: Fri, 12 Sep 86 13:27 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: An example of where setf does not do what I want.
To: Bradley C. Kuszmaul <bradley@Think.COM>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8609121011.AA17090@Godot.Think.COM>
Message-ID: <860912132726.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 12 Sep 86 06:11:02 EDT (Fri)
    From: Bradley C. Kuszmaul <bradley@Think.COM>

    I want to do

      (setf (apply #'aref (cons my-array dims)) value)

    where MY-ARRAY, DIMS, and VALUE are bound to meaningful values

    Unfortunately, my reading of SETF says that the above won't work.
    If I had (ASET value array &rest dims) then I could to
      (apply #'aset (list* value my-array dims))
    to do what I want.

Recall that APPLY in Common Lisp allows more than two arguments,
unlike APPLY in traditional languages such as Maclisp, Zetalisp,
and Lisp 1.5.  Hence the expansion is

  (APPLY #'aset VALUE (CONS MY-ARRAY DIMS))

where aset is not a standard Common Lisp function, but we all know
what it does.

∂13-Sep-86  1846	ELIOT%cs.umass.edu@CSNET-RELAY.ARPA 	Locally 
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 13 Sep 86  18:42:46 PDT
Received: from umass-cs by csnet-relay.csnet id ap00376; 11 Sep 86 17:38 EDT
Date:     Wed, 10 Sep 86 20:24 EDT
From:     ELIOT%cs.umass.edu@CSNET-RELAY.ARPA
To:       Common-Lisp@SU-AI.ARPA
Subject:  Locally
X-VMS-To: CSNET%"Common-Lisp@Su-Ai.arpa"

What does the form:
(locally (declare (special foo))
  (let ((foo 3))
    (print foo)))
do?

On P.156 it says that Locally "does not bind any variables and therefore
cannot be used meaningfully for declarations of variable bindings".
This would imply that the FOO bound by the LET is not affected by the
LOCALLY and that this form should be an error because the SPECIAL
reference to FOO in (print foo) is not bound by the lexical binding
of FOO.

In NIL, Vaxlisp and HPCommon Lisp this form executes smoothly and
prints "3".  Either all three implementations are wrong, or
the documentation is confusing (to me.)

Personally I think that the implementations are correct, since
the other interpretation implies that the let in:
	(locally (declare (special foo))
	  ...
	  (let ((foo ...))
		...))
Cannot ever be meaningfu, since the variable foo is REFERENCED as
a special, but bound as a lexical.

I think that Locally (declae (special foo)) should affect
every binding and reference to foo within the body of the locally.
This would make it behave like a lexically scoped version of "proclaim".

In any case the documentation seems ambiguous or wrong.

∂14-Sep-86  1337	FAHLMAN@C.CS.CMU.EDU 	Locally 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Sep 86  13:37:11 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 14 Sep 86 16:36:00-EDT
Date: Sun, 14 Sep 1986  16:35 EDT
Message-ID: <FAHLMAN.12238941924.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   ELIOT%cs.umass.edu@RELAY.CS.NET
Cc:   Common-Lisp@SU-AI.ARPA
Subject: Locally
In-reply-to: Msg of 10 Sep 1986  20:24-EDT from ELIOT%cs.umass.edu at CSNET-RELAY.ARPA


    (locally (declare (special foo))
      (let ((foo 3))
        (print foo)))

    In NIL, Vaxlisp and HPCommon Lisp this form executes smoothly and
    prints "3".  Either all three implementations are wrong, or
    the documentation is confusing (to me.)
    ...
    I think that Locally (declae (special foo)) should affect
    every binding and reference to foo within the body of the locally.
    This would make it behave like a lexically scoped version of "proclaim".

I think that all three implementations are right, but not for the reason
you suspect.  The binding of FOO within the LET is a lexical binding,
because the external special declaration has no effect on this binding.
This lexical binding is what the reference to FOO in the PRINT form
sees.  This new binding shadows the SPECIAL declaration for references
lexically within the LET.  See the example on page 158, which is almost
exactly the same case.

The current rules covering special declarations are strange, at best,
but I think the manual is reasonably clear, under the circumstances.
There is an example covering the case that confused you.  I admit that
the example is a bit hard to follow...

-- Scott

∂14-Sep-86  1543	Gregor.pa@Xerox.COM 	Portable CommonLoops port liasons 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Sep 86  15:43:00 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 14 SEP 86 15:38:01 PDT
Date: Sun, 14 Sep 86 15:36 PDT
From: Gregor.pa@Xerox.COM
Subject: Portable CommonLoops port liasons
To: Common-Lisp@SU-AI.arpa
Message-ID: <860914153628.2.GREGOR@AVALON.XEROX-PARC>
Line-fold: no


I apologize for the wide distribution of this message.

For each of the Common Lisp developers, I am looking for a liason with
whom I can communicate about porting Portable CommonLoops (PCL) to their
Lisp.

In the past I have been able to do most of the implementation-specific
customizations myself.  Now, in order to make PCL run faster, I expect
the customizations to become more elaborate, and I would like to have
someone who works on each of the Common Lisp implementations to ask
questions of etc.

Could a system implementor from each of the from each of the Common Lisp
implementation groups please send me a message.

Thanks.

P.S. I already have liasons for the following implementations:

Kyoto Common Lisp
Lucid
Symbolics
Xerox Common Lisp
-------

∂15-Sep-86  1357	fateman@renoir.Berkeley.EDU 	ops-5 
Received: from RENOIR.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 86  13:57:22 PDT
Received: by renoir.Berkeley.EDU (5.53/1.16)
	id AA22172; Sun, 14 Sep 86 17:08:23 PDT
Date: Sun, 14 Sep 86 17:08:23 PDT
From: fateman@renoir.Berkeley.EDU (Richard Fateman)
Message-Id: <8609150008.AA22172@renoir.Berkeley.EDU>
To: common-lisp@Sail.Stanford.EDU
Subject: ops-5


There turns out to be an ops5 in CL at CMU, in addition to
the one done here.  A cursory inspection of the CMU one indicates
that the changes made were quite similar to those in our version.
Unless someone is desperate for a copy, I suggest holding off a
few weeks until we get a chance to more carefully
compare the two and perhaps put the best of both in one system.
Distribution in either case would be public domain. 

∂15-Sep-86  1438	jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	Re:  OPS-5 in Common Lisp
Received: from CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 15 Sep 86  14:35:57 PDT
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK   via Janet with NIFTP
           id a006635; 13 Sep 86 19:19 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Sat, 13 Sep 86 19:20:10 -0100
Message-Id: <12876.8609131820@aiva.ed.ac.uk>
To: fateman@renoir.berkeley.edu
Subject: Re:  OPS-5 in Common Lisp
Cc: common-lisp@su-ai.arpa

For what it's worth, I ported OPS-5 from Franz to CL a while ago but
haven't been sending it around because I didn't know what restrictions
applied (there is a copyright notice at the beginning).

My port wasn't meant to be very efficient because I wanted to use
techniques that would apply to arbitrary Franz programs without
my understanding how they worked.  So, for example, rather than
eliminate the fexprs, I had an automatic way to define them as a
combination of a macro and a function.

Anyway, I would also be interested in knowing whether I can redistribute
this, as there is some demand for it in the UK.

I have run some benchmarks using things like the monkey and banana problem,
but I would be interested in better tests if anyone has some.

-- Jeff

∂15-Sep-86  1937	NGALL@G.BBN.COM 	defstruct slots' default-inits   
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 15 Sep 86  19:37:14 PDT
Date: 15 Sep 1986 22:35-EDT
Sender: NGALL@G.BBN.COM
Subject: defstruct slots' default-inits
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]15-Sep-86 22:35:17.NGALL>

Is the following legal CL:

(defstruct foo
  (a 1)
  (b (+ a 2)))

Specifically, is the default-init form of a slot allowed to reference the
values of slots to its left (above)?  In other words, is the above
defined by CL to be equivalent to

(defstruct (foo (:constructor make-foo (&key (a 1) (b (+ a 2)))))
  a
  b)

(assuming that &key was allowed in the lambda-list for a BOA
constructor)

The only hint that I can find that indicates that it is legal is on
page 309 (bottom): "It is as if the initialization forms were used as
init forms for the keyword parameters of the constructor function."

Is there a more direct statement about the interaction of default-init
forms and other slots?  If not, there should be.

-- Nick

∂17-Sep-86  1044	tsf@theory.cs.cmu.edu 	Readtables and prin1  
Received: from THEORY.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Sep 86  10:44:08 PDT
Date: Wednesday, 17 September 1986 13:40:39 EDT
From: Timothy.Freeman@theory.cs.cmu.edu
To: common-lisp@su-ai.arpa
Subject: Readtables and prin1
Message-ID: <1986.9.17.17.29.57.Timothy.Freeman@theory.cs.cmu.edu>

When prin1 is used to print something out, should it look at the current
value of *readtable* and produce text that can be read in assuming that
readtable is in effect, or should it produce text that can be read in with
the standard readtable?  The manual says the following about the
*print-escape* flag:
   "When this flag is not nil, then an attempt is made to print an
    expression in such a way that it can be read again to produce an equal
    structure."
(page 370, near the bottom)

Maybe Common Lisp needs a *print-readtable* variable that is analogous to
the *print-base* variable.

∂17-Sep-86  1813	FAHLMAN@C.CS.CMU.EDU 	Readtables and prin1   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Sep 86  18:13:24 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 17 Sep 86 21:08:13-EDT
Date: Wed, 17 Sep 1986  21:07 EDT
Message-ID: <FAHLMAN.12239777784.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Timothy.Freeman@THEORY.CS.CMU.EDU
Cc:   common-lisp@SU-AI.ARPA
Subject: Readtables and prin1
In-reply-to: Msg of 17 Sep 1986  13:40-EDT from Timothy.Freeman at theory.cs.cmu.edu


I think that the usual practice is to print things out so that they can
be read in using the standard readtable.  It would be VERY difficult to
write code that can print out text for any user-modified readtable,
especially if the read-table contains macros.

-- Scott

∂17-Sep-86  1847	FAHLMAN@C.CS.CMU.EDU 	Readtables and prin1   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Sep 86  18:13:24 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 17 Sep 86 21:08:13-EDT
Date: Wed, 17 Sep 1986  21:07 EDT
Message-ID: <FAHLMAN.12239777784.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Timothy.Freeman@THEORY.CS.CMU.EDU
Cc:   common-lisp@SU-AI.ARPA
Subject: Readtables and prin1
In-reply-to: Msg of 17 Sep 1986  13:40-EDT from Timothy.Freeman at theory.cs.cmu.edu


I think that the usual practice is to print things out so that they can
be read in using the standard readtable.  It would be VERY difficult to
write code that can print out text for any user-modified readtable,
especially if the read-table contains macros.

-- Scott

∂17-Sep-86  2001	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Readtables and prin1   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Sep 86  20:01:19 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106638; Wed 17-Sep-86 22:59:46 EDT
Date: Wed, 17 Sep 86 23:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Readtables and prin1
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: Timothy.Freeman@THEORY.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12239777784.BABYL@C.CS.CMU.EDU>
Message-ID: <860917230007.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 17 Sep 1986  21:07 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    I think that the usual practice is to print things out so that they can
    be read in using the standard readtable.  It would be VERY difficult to
    write code that can print out text for any user-modified readtable,
    especially if the read-table contains macros.

Many systems attempt to print things out so that they can be read in using
the current readtable.  For example, the Symbolics system uses the current
readtable to determine where escape characters are required (feed the
symbol's name back through the readtable and see if you get the same thing).
I agree that it is very difficult to cope with arbitrary user modifications
to the readtable, especially with the readtable-modifying primitives provided
by Common Lisp, but on the other hand it's easy to cope with some common,
simple modifications such as changing exclamation point from a constituent
to a macro.  Basing this on the current readtable rather than the standard
readtable gives the user more flexibility, but as Common Lisp is currently
defined it is up to each implementation to decide whether it wants to go
to this much care.

I think if we're going to be more specific than "an attempt is made to
print an expression in such a way that it can be read again", then it
is incumbent on us to define more specifically how to customize the
printer in the same way that the reader can be customized, e.g. changing
the parenthesis characters.

∂17-Sep-86  2216	@DIAMOND.S4CC.Symbolics.COM:DDYER@RIVERSIDE.SCRC.Symbolics.COM 	Readtables and prin1 
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 17 Sep 86  22:16:31 PDT
Received: from WHITE.SWW.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12684; Thu 18-Sep-86 01:15:45 EDT
Received: from PURPLE.SWW.Symbolics.COM by WHITE.SWW.Symbolics.COM via CHAOS with CHAOS-MAIL id 33202; Wed 17-Sep-86 22:09:12 PDT
Date: Wed, 17 Sep 86 21:54 PDT
From: DDYER@RIVERSIDE.SCRC.Symbolics.COM
Subject: Readtables and prin1
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
    Timothy.Freeman@THEORY.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
Fcc: W:>ddyer>mail.sent
In-Reply-To: <FAHLMAN.12239777784.BABYL@C.CS.CMU.EDU>
Message-ID: <860917215432.5.DDYER@PURPLE.SWW.Symbolics.COM>

    Date: Wed, 17 Sep 1986  21:07 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>


    I think that the usual practice is to print things out so that they can
    be read in using the standard readtable.  It would be VERY difficult to
    write code that can print out text for any user-modified readtable,
    especially if the read-table contains macros.

    -- Scott

Gee, that's the way Interlisp has always done it.  In Interlisp, all
print operations accept a readtable as an optional argument, which
determines how things are printed.   All you have to do is pre-process
the readtable so you know which characters need to be slashified.

∂18-Sep-86  0701	@UR-ACORN.ARPA,@UR-CASHEW.ARPA:miller@UR-ACORN.ARPA 	Re: Readtables and prin1   
Received: from UR-ACORN.ARPA by SAIL.STANFORD.EDU with TCP; 18 Sep 86  07:01:08 PDT
Received: from UR-CASHEW.ARPA (UR-CASHEW.ARPA) by UR-ACORN.ARPA via INTERNET with SMTP id 34026; 18 Sep 86 10:00:17-EDT
Date: Thu, 18 Sep 86 10:00 EDT
From: Brad Miller <miller@UR-ACORN.ARPA>
Subject: Re: Readtables and prin1
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA
Fcc: ACORN:>miller>babyl.text
In-Reply-To: <FAHLMAN.12239777784.BABYL@C.CS.CMU.EDU>
Message-ID: <860918100035.2.MILLER@UR-CASHEW.ARPA>
Sender: miller@UR-ACORN.ARPA
Organization: University of Rochester, Department of Computer Science
Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627
Phone: 716-275-7747
Moon: 7 minutes since the full moon.

    Date: Wed, 17 Sep 1986  21:07 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>


    I think that the usual practice is to print things out so that they can
    be read in using the standard readtable.  It would be VERY difficult to
    write code that can print out text for any user-modified readtable,
    especially if the read-table contains macros.

    -- Scott

It may be hard, but I suspect necessary. Given the user is in some context, he
would expect his print function to work "so it can be read in again" which
implies in his current context. Having to change contexts just to enter forms
(which would then get into even more difficult problems about packaging, etc.
in the new context) is not in my opinion a good user interface.

Brad Miller
------
miller@rochester.arpa
miller@ur-acorn.arpa

∂18-Sep-86  1037	FAHLMAN@C.CS.CMU.EDU 	Readtables and prin1   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Sep 86  10:37:14 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 18 Sep 86 13:35:17-EDT
Date: Thu, 18 Sep 1986  13:35 EDT
Message-ID: <FAHLMAN.12239957598.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: Readtables and prin1
In-reply-to: Msg of 18 Sep 1986  10:00-EDT from Brad Miller <miller at UR-ACORN.ARPA>


OK, apparently lots of systems peek at the current readtable in order to
see which characters need to be slashified (or vertical-barred) on
output.  That's probably impossible to get right, if by "right" you mean
doing the minimal slashification that is necessary but no more.
However, it doesn't hurt to slashify extra characters if there is some
doubt.  I'm not sure whether I think this is valuable or important, but
I won't argue against it.

I still think that requiring PRIN1 to perform correctly given any
arbitrary readtable is much too hard to make this a required part of the
language, and probably impossible.  I'm not sure whether a half-assed
attempt to adapt to the current readtable is better than explicitly not
doing this at all.  My inclination would be to require anyone using an
extensively hacked readtable to write his own matching printer.

-- Scott

∂18-Sep-86  1039	yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA 	Re: OPS5 in Common Lisp 
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 Sep 86  10:39:43 PDT
Received: from utokyo-relay by csnet-relay.csnet id ba05313; 18 Sep 86 1:40 EDT
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
	id AA09220; Sat, 13 Sep 86 14:15:23+0900
From: yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA
Received: by nttlab.ntt.junet (4.12/5.0) with TCP; Sat, 13 Sep 86 13:22:58 jst
Received: by kurims.kurims.kyoto-u.junet (2.0/6.1Junet)
	id AA00467; Sat, 13 Sep 86 13:12:28+0900
Date: Sat, 13 Sep 86 13:12:28+0900
Message-Id: <8609130412.AA00467@kurims.kurims.kyoto-u.junet>
To: common-lisp%su-ai.arpa%u-tokyo.junet@CSNET-RELAY.ARPA
Subject: Re: OPS5 in Common Lisp

We also have OPS5 running on KCL.  It is VPS2, an interpreter for OPS5,
copyrighted by C.Forgy in 1979, 1980, and 1981.  The sources came from
Edinburgh AIAI, where Jeff ported VPS2 onto Spice Lisp.  Just removing
the use of fexpr was enough to port it onto KCL.

-- Taiichi

∂18-Sep-86  1100	LOOSEMORE@UTAH-20.ARPA 	*applyhook* question 
Received: from UTAH-20.ARPA by SAIL.STANFORD.EDU with TCP; 18 Sep 86  10:59:00 PDT
Date: Thu 18 Sep 86 11:58:48-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: *applyhook* question
To: common-lisp@SU-AI.ARPA
Message-ID: <12239961893.17.LOOSEMORE@UTAH-20.ARPA>

CLtL says the apply hook function "takes three arguments, a function, a list
of arguments, and an environment".  Three questions:

(1) Is the "function" argument already evaluated?  There are no user
accessible functions for extracting its definition from the environment.
-------

∂18-Sep-86  1104	LOOSEMORE@UTAH-20.ARPA 	*applyhook* question (hopefully I'll get it right this time) 
Received: from UTAH-20.ARPA by SAIL.STANFORD.EDU with TCP; 18 Sep 86  11:04:18 PDT
Date: Thu 18 Sep 86 12:04:06-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: *applyhook* question (hopefully I'll get it right this time)
To: common-lisp@SU-AI.ARPA
Message-ID: <12239962857.17.LOOSEMORE@UTAH-20.ARPA>

CLtL says the apply hook function "takes three arguments, a function, a list
of arguments, and an environment".  Three questions:

(1) Is the "function" argument already evaluated?  There are no user-
accessible functions for extracting its definition from the environment, so
I don't see how the hook function could make much use of an unevaluated
function.

(2) Are the arguments in the argument list argument already evaluated, or
is it the responsibility of the hook function to evaluate them before
applying the function?

(3) If both the "function" and "argument list" arguments are already
evaluated, what does the hook function need an environment for?

-Sandra
-------

∂18-Sep-86  1538	pyramid!bein@hplabs.HP.COM 	testing addresses ... please ignore  
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86  15:38:42 PDT
Received: by hplabs.HP.COM ; Thu, 18 Sep 86 15:37:41 pdt
Date: Thu, 18 Sep 86 15:12:46 PDT
From: pyramid!bein@hplabs.HP.COM (David Bein)
Message-Id: <8609182212.AA14499@pyramid>
Received: by pyramid (5.51/3.14)
	id AA14499; Thu, 18 Sep 86 15:12:46 PDT
To: common-lisp@sail.stanford.edu
Subject: testing addresses ... please ignore


--David

∂19-Sep-86  1853	cross@afit-ab.ARPA 	please add my name  
Received: from AFIT-AB.ARPA by SAIL.STANFORD.EDU with TCP; 19 Sep 86  18:53:19 PDT
Date: 19 Sep 1986 21:26-EDT
From: cross@wpafb-ab
To: ai-ed-request@sumex-aim, soft-eng-request@mit-xx, common-lisp@su-ai,
        info-xlisp-request@cmu-cs-spice
Subject: please add my name

Please add me to the list.  Thanks.

Steve Cross
AFIT/ENG, WPAFB OH 45433-6583
(513) 255-3576

∂20-Sep-86  1751	cross@afit-ab.ARPA 	xlisp query    
Received: from AFIT-AB.ARPA by SAIL.STANFORD.EDU with TCP; 20 Sep 86  17:51:18 PDT
Date: 20 Sep 1986 20:46-EDT
From: cross@wpafb-afita
To: common-lisp@su-ai, ai-ed@sumex-aim
Subject: xlisp query

Would appreciate a pointer to where I could download the source code for 
xlisp 1.6 and any demonstratable programs written in xlisp.  I'm aware 
of the stuff published in AI Expert and have downloaded it, but cannot 
find the source code.  Thanks in advance.

Steve Cross


∂22-Sep-86  1734	@RIVERSIDE.SCRC.Symbolics.COM,@BIS-ALICE-LIDDELL.DialNet.Symbolics.COM:Stever@BIS-ALICE-LIDDELL.BISCC.DIALNET.SYMBOLICS.COM 	" macro character   
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 22 Sep 86  17:34:18 PDT
Received: from BIS-ALICE-LIDDELL.BISCC.Dialnet.Symbolics.Com (BIS-ALICE-LIDDELL.DialNet.Symbolics.COM) by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 60147; 22 Sep 86 20:26:49 EDT
Date: Mon, 22 Sep 86 16:24 EDT
From: Stephen Robbins <Stever@BIS-ALICE-LIDDELL.BISCC.Dialnet.Symbolics.Com>
Subject: " macro character
To: common-lisp%su-ai.arpa@SCRC-RIVERSIDE.DialNet.Symbolics.COM
Message-ID: <860922162454.3.STEVER@BIS-ALICE-LIDDELL.BISCC.Dialnet.Symbolics.Com>

Hi!

On page 347 of CLtL, it says that the double quote character
accumulates characters until another double quote is seen.  "An
exception to this occurs if a \single escape/ character is seen; ..."

If I want to write my function which handles " in Common-Lisp itself,
how can my handler tell when a character it's read is a single escape
character?  It would have to be able to look into the readtable.  If
there are ways to look inside readtables, I've missed them...

          Thanks!

                Stever


∂22-Sep-86  1749	Moon@STONY-BROOK.SCRC.Symbolics.COM 	*applyhook* question (hopefully I'll get it right this time)   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Sep 86  17:48:59 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110259; Mon 22-Sep-86 20:47:24 EDT
Date: Mon, 22 Sep 86 20:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: *applyhook* question (hopefully I'll get it right this time)
To: SANDRA <LOOSEMORE@UTAH-20.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <12239962857.17.LOOSEMORE@UTAH-20.ARPA>
Message-ID: <860922204642.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu 18 Sep 86 12:04:06-MDT
    From: SANDRA <LOOSEMORE@UTAH-20.ARPA>

I haven't seen any replies to this.  I guess I can try to take a crack at it.

    CLtL says the apply hook function "takes three arguments, a function, a list
    of arguments, and an environment".  Three questions:

    (1) Is the "function" argument already evaluated?  There are no user-
    accessible functions for extracting its definition from the environment, so
    I don't see how the hook function could make much use of an unevaluated
    function.

    (2) Are the arguments in the argument list argument already evaluated, or
    is it the responsibility of the hook function to evaluate them before
    applying the function?

The intent of this ("when a function is about to be applied to arguments",
CLtL p.322) is that the applyhook is called after everything has been evaluated.

    (3) If both the "function" and "argument list" arguments are already
    evaluated, what does the hook function need an environment for?

It's not for anything!  Apparently this was discussed on the mailing list
long ago, because this comment appears in our source code:

;After discussion on the Common Lisp mailing list, the ENV for the apply hook
;is the environment in which the arguments have already been evaluated, not
;the environment of the function to be called, which is of course still inside
;its closure.  Its completely inutile to have the environment as an argument here,
;but it's in the book so I'll accept it and ignore it.

I suspect this env is a mistake, although it's conceivable that it is a hook
for some kind of future feature.

∂23-Sep-86  0352	ma←jpf%ux63.bath.ac.uk@Cs.Ucl.AC.UK 	OPS-5   
Received: from CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 23 Sep 86  03:52:07 PDT
Received: from ux63.bath.ac.uk by 44d.Cs.Ucl.AC.UK   via Janet with NIFTP
           id a012978; 22 Sep 86 15:14 BST
Date:       22 Sep 1986 11:14:06-GMT
To:         common-lisp <@Cs.Ucl.AC.UK:common-lisp@su-ai.arpa>
Subject:    OPS-5
From:       ma←jpf%ux63.bath.ac.uk@Cs.Ucl.AC.UK

What is all the fuss about?  We ported OPS-5 to the HP Bobcat Common LISP
in a very small time; even improved the thing on the way.  Is there an
official port to Common Lisp?  Why?
==John


∂24-Sep-86  1159	ACUFF@SUMEX-AIM.ARPA 	Re: Readtables and prin1    
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Sep 86  11:59:35 PDT
Date: Wed 24 Sep 86 11:56:35-PDT
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Re: Readtables and prin1
To: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12239957598.BABYL@C.CS.CMU.EDU>
Message-ID: <12241545278.32.ACUFF@SUMEX-AIM.ARPA>

		 ... My inclination would be to require anyone using an
 extensively hacked readtable to write his own matching printer.

 -- Scott

What do you mean by "extensively"?

	-- Rich
-------

∂24-Sep-86  1932	FAHLMAN@C.CS.CMU.EDU 	Mailing list requests  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Sep 86  19:32:39 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 24 Sep 86 22:31:28-EDT
Date: Wed, 24 Sep 1986  22:31 EDT
Message-ID: <FAHLMAN.12241628079.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: Mailing list requests


Several people have recently written to me with requests to be taken off
the Common Lisp mailing list.  This list is maintained and altered by
Dick Gabriel, RPG@SU-AI.

-- Scott

∂24-Sep-86  1943	FAHLMAN@C.CS.CMU.EDU 	Readtables and prin1   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Sep 86  19:41:18 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 24 Sep 86 22:34:03-EDT
Date: Wed, 24 Sep 1986  22:33 EDT
Message-ID: <FAHLMAN.12241628544.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Readtables and prin1
In-reply-to: Msg of 24 Sep 1986  14:56-EDT from Richard Acuff <Acuff at SUMEX-AIM.ARPA>


    		 ... My inclination would be to require anyone using an
     extensively hacked readtable to write his own matching printer.

  What do you mean by "extensively"?

Hacked enough that you can't do what you want to do with what is
presently in Common Lisp.

-- Scott

∂25-Sep-86  0640	@MC.LCS.MIT.EDU:STEVER%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU 	Are strings adjustable arrays? 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Sep 86  06:40:10 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 SEP 86  09:23:00 EDT
Date: Thu, 25 Sep 86 09:23:17 EDT
From: "Stephen E. Robbins" <STEVER%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Subject: Are strings adjustable arrays?
To: common-lisp@SU-AI.ARPA
Message-ID: <[MX.LCS.MIT.EDU].949090.860925.STEVER>


I have an application that does a lot of string hacking.  For
efficiency reasons, we'd like to mutate our strings rather than
creating new ones all the time.  It seems like strings which are
adjustable arrays with fill pointers are what we want.  I
gather from page 299 that, while strings MAY have fill pointers,
there is no mechanism for having them automatically created
that way.

Is that the intention, or is there actually some way to have
strings created with fill pointers?

	Stever

∂25-Sep-86  1358	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	Are strings adjustable arrays?
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 25 Sep 86  13:58:46 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 14426; Thu 25-Sep-86 16:57:22 EDT
Date: Thu, 25 Sep 86 16:56 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Are strings adjustable arrays?
To: Stephen E. Robbins <STEVER%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>,
    common-lisp@SU-AI.ARPA
In-Reply-To: <[MX.LCS.MIT.EDU].949090.860925.STEVER>
Message-ID: <860925165650.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

    Date: Thu, 25 Sep 86 09:23:17 EDT
    From: "Stephen E. Robbins" <STEVER%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>


    I have an application that does a lot of string hacking.  For
    efficiency reasons, we'd like to mutate our strings rather than
    creating new ones all the time.  It seems like strings which are
    adjustable arrays with fill pointers are what we want.  I
    gather from page 299 that, while strings MAY have fill pointers,
    there is no mechanism for having them automatically created
    that way.

    Is that the intention, or is there actually some way to have
    strings created with fill pointers?

To get either fill-pointers or adjustability, you have to use
make-array.  make-string is not enough.
	(make-array <size>
		    :element-type 'string-char
		    :fill-pointer 0
		    :adjustable t)

∂25-Sep-86  1416	RPG  	Jim Meehan Comments
To:   common-lisp@SAIL.STANFORD.EDU   

Jim Meehan asked me to forward a remark he was unable to successfully
mail to Common-Lisp.
			-rpg-

ps. Oh yeah, by the way, here it is:

Date: Thu, 18 Sep 86 13:24:42 edt
From: James R. Meehan <csi!meehan@UUCP>
To: common-lisp@su-ai.arpa
Subject: Ignoring the DOTIMES variable

CLtL doesn't say whether DOTIMES actually "uses" the loop-variable, as
opposed to its value, and this ambiguity causes problems with portable
code.  If DOTIMES does use the loop-variable, then

  (DOTIMES (I 10) (DECLARE (IGNORE I)) (FOO))

can cause the compiler to issue a warning, but if DOTIMES doesn't use
the loop-variable, then

  (DOTIMES (I 10) (FOO)) 

can also cause the compiler to issue a warning.

Personally, I think DOTIMES shouldn't use the variable, so that

  (DOTIMES (I 10) (DECLARE (IGNORE I)) (FOO))

would be the correct style. That is, it should behave as if it were
implemented this way, more or less:

  (DEFMACRO DOTIMES ((VAR END &OPTIONAL FINAL) &BODY BODY)
    (LET ((I (GENSYM)) (STOP (GENSYM)))
      `(DO ((,I 0 (1+ ,I))
            (,STOP ,END))
           ((>= ,I ,STOP) (LET ((,VAR ,I)) ,FINAL))
         (LET ((,VAR ,I)) ,@BODY))))

[This may need some additional work for copying declarations in the
"final" code, via the proposed PARSE-BODY or whatever.]

I've seen several implementations where DOTIMES actually uses the
loop-variable, thus permitting horrors like using SETQ to change the
value of the loop-variable and therefore control the iterations.  The
implementation above would prevent that.

∂26-Sep-86  0558	Dan@Think.COM 	Jim Meehan Comments 
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 26 Sep 86  05:58:26 PDT
Received: from zachary by Godot.Think.COM via CHAOS; Fri, 26 Sep 86 08:58:14 edt
Date: Fri, 26 Sep 86 09:00 EDT
From: Dan Aronson <Dan@Think.COM>
Subject: Jim Meehan Comments
To: RPG@SAIL.STANFORD.EDU
Cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <8609252118.AA00590@Zarathustra.Think.COM>
Message-Id: <860926090057.4.DAN@ZACHARY.THINK.COM>

    Date: Thu, 18 Sep 86 13:24:42 edt
    From: James R. Meehan <csi!meehan@UUCP>

    CLtL doesn't say whether DOTIMES actually "uses" the loop-variable, as
    opposed to its value, and this ambiguity causes problems with portable
    code.

    I've seen several implementations where DOTIMES actually uses the
    loop-variable, thus permitting horrors like using SETQ to change the
    value of the loop-variable and therefore control the iterations.  The
    implementation above would prevent that.

Oh yes it does, page 128 of CLtL says:
	Altering the value of VAR in the body of the loop (by using SETQ, for
	example) will have unpredictable, possibly implementation-dependent results.  
	A Common Lisp compiler may choose to issue a warning if such a variable 
	appears in a SETQ.

This clearly means that if you do things like SETQ then you are going to run
in to portability problems.  

--Dan

∂29-Sep-86  1037	DALY@IBM.COM 	getting on the common lisp list
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 29 Sep 86  10:37:46 PDT
Date: 29 September 1986, 12:47:02 EDT
From: "Timothy P. Daly"  <DALY@ibm.com>
To:   common-lisp@su-ai.arpa
Message-Id: <092986.124703.daly@ibm.com>
Subject: getting on the common lisp list

Hi,
 How can I get on the list to receive the common lisp discussion?
My address is DALY@IBM.COM.

∂03-Oct-86  1337	@MC.LCS.MIT.EDU:STEVER%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Oct 86  13:37:13 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 OCT 86  16:37:12 EDT
Date: Fri,  3 Oct 86 16:36:39 EDT
From: "Stephen E. Robbins" <STEVER%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
To: common-lisp@SU-AI.ARPA
Message-ID: <[MX.LCS.MIT.EDU].950779.861003.STEVER>

Hi!

I'm doing a fair amount of string hacking right now.  A lot of
things involve comparing and manipulating substrings.  I do most
of this via the :START and :END arguments on the string functions.

Symbolics Common Lisp blows up if you specify a :END which is
greater than the length of a string.  It also signals an error
if you give a large :END to a subsequence extract with SUBSEQ.

I looked through CLtL, but couldn't find any mention of this
case.  Is the result of extracting past the end of a subsequence
considered undefined?

		Stever

∂03-Oct-86  1429	RAM@C.CS.CMU.EDU    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Oct 86  14:29:30 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Fri 3 Oct 86 17:27:26-EDT
Date: Fri, 3 Oct 1986  17:27 EDT
Message-ID: <RAM.12243932018.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   "Stephen E. Robbins" <STEVER%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Cc:   common-lisp@SU-AI.ARPA
In-reply-to: Msg of 3 Oct 1986  16:36-EDT from Stephen E. Robbins <STEVER%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU>

    Date: Friday, 3 October 1986  16:36-EDT
    From: Stephen E. Robbins <STEVER%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU>

    ...Is the result of extracting past the end of a subsequence
    considered undefined?

    		Stever

Yes.  Although it isn't explicitly stated when :END is discussed on
page 246, the discussion doesn't make any sense otherwise.  One could
hypothesize a magical exception in the case where END is greater than
the length, but there is nothing in the manual to support such a
conclusion.  There are many illegal things which are not explicitly
stated to be illegal in the manual.

  Rob

∂03-Oct-86  1853	@REAGAN.AI.MIT.EDU:RDZ@AI.AI.MIT.EDU 	Printing DEFSTRUCTs   
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Oct 86  18:53:28 PDT
Received: from NULLSTELLENSATZ.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 5075; Fri 3-Oct-86 21:53:47 EDT
Date: Fri, 3 Oct 86 21:53 EDT
From: Ramin Zabih <RDZ@AI.AI.MIT.EDU>
Subject: Printing DEFSTRUCTs
To: common-lisp@SU-AI.ARPA
Message-ID: <861003215337.4.RDZ@NULLSTELLENSATZ.AI.MIT.EDU>

The standard way of printing structures involves printing out all
the slots in #S notation.  The Common Lisp manual requires that
structures print in this way unless the user specifies his own
printing function in his structure definition (page 370).  I don't think
that this is a very useful way of printing structures, since a lot of
structures are circular, and even those that aren't tend to be large in
any program that isn't a toy.

I would prefer that the default way of printing structures be changed to
be more useful (for instance the way ZetaLisp DEFSTRUCTs used to print,
which was as "#<SHIP 7765321>").  A less-preferable solution would
involve a global variable that controls how structures default to
printing.


					Ramin

∂03-Oct-86  2100	DT50@A.CS.CMU.EDU 	printing structures  
Received: from A.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Oct 86  20:58:50 PDT
Date:  3 Oct 86 23:57 EDT
From: Dave.Touretzky@A.CS.CMU.EDU
To: common-lisp@SU-AI.ARPA
Subject: printing structures

I second Ramin Zabih's suggestion that the default way to print a structure
should be to NOT show its components.  If Common Lisp has to specify a
default print convention, the #<SHIP 1234567> notation is a better choice.

The same problem shows up with closures:  some implementations build
closures that are circular or, at the very least, long and and hairy.  They
are a source of annoyance every time the user accidentally (or purposely)
tries to print one.  Since the Common Lisp standard deliberately says
nothing about the representation of closures, maybe it shouldn't specify
how they are printed.  But it should at least SUGGEST to implementors that
they should choose a printing convention doesn't screw the user by default,
i.e.  by trying to print something huge or circular.  I like the Lisp Machine
#<LEXICAL-CLOSURE 1234567> notation just fine.

-- Dave

∂04-Oct-86  0023	bader@spice.cs.cmu.edu 	Re: printing structures   
Received: from SPICE.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Oct 86  00:23:51 PDT
Date:    Sat,  4 Oct 1986 02:28:46-EDT
From:    Miles Bader <bader@spice.cs.cmu.edu>
Subject: Re: printing structures
To:      common-lisp@SU-AI.ARPA
Message-ID: <BMS.528791326.bader@spice.cs.cmu.edu>

Of course, some people actually like to read in what they print.  Why not
just give different values to *print-length*, *print-level* and
*print-circle* in your init file?

						-Miles

∂04-Oct-86  1817	RWK@YUKON.SCRC.Symbolics.COM 	Re: printing structures  
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 4 Oct 86  18:17:42 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 97828; Sat 4-Oct-86 21:15:41 EDT
Date: Sat, 4 Oct 86 21:16 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: printing structures
To: Miles Bader <bader@spice.cs.cmu.edu>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <BMS.528791326.bader@spice.cs.cmu.edu>
Message-ID: <861004211602.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

    Date:    Sat,  4 Oct 1986 02:28:46-EDT
    From:    Miles Bader <bader@spice.cs.cmu.edu>

    Of course, some people actually like to read in what they print.  Why not
    just give different values to *print-length*, *print-level* and
    *print-circle* in your init file?

						    -Miles
As Common Lisp is currently designed, this just breaks
programs that like to read in what they print.

We provide a macro, WITH-STANDARD-IO-ENVIRONMENT which
binds the I/O control variables to their standard values.
This provides a sorely needed decoupling between I/O
for inter-program communication and the user-interface.

It is far easier to wrap this one form around the
portion of your program which does I/O than it is to
figure out what variables it depends on, and bind each
of them.  Even if you want a few non-standard bindings,
it's easier to start with the standard bindings and
rebind a few than to deal with each of them.

I >strongly< recommend this be adopted.  Once it's
adopted, it's much easier to discuss changing
the default global bindings for the I/O control
variables to make the environment easier to use
interactively.  Without it, we'll just get caught up
in the communications and compatibility issues.

∂05-Oct-86  2017	Masinter.pa@Xerox.COM 	Re: printing structures    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Oct 86  20:17:49 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 OCT 86 20:05:51 PDT
Date: 5 Oct 86 20:08 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: printing structures
In-reply-to: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>'s message of
 Sat, 4 Oct 86 21:16 EDT
To: RWK@YUKON.SCRC.Symbolics.COM
cc: common-lisp@SU-AI.ARPA
Message-ID: <861005-200551-3386@Xerox>

Separating out I/O for for inter-program communication and the
user-interface is a good idea, but your proposal puts the burden on
inter-program communication ("wrap this one form around the portion of
your program which does I/O.") rather than on the user interface.

Wouldn't it be simpler to suggest that implementors of a
"top-level-loop" might want to bind a separate I/O environment for
reading and printing (but not for execution)?  

Back onto the original discussion: we added a variable *print-structure*
which controlled how structures were printed by the default structure
printer, in the same way that *print-array* controls array output. I'm
reluctant to propose additions to the language, but if one was wanted,
this seems like a logical choice.

 

∂05-Oct-86  2115	SOLEY@XX.LCS.MIT.EDU 	printing structures    
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Oct 86  21:15:32 PDT
Date: Mon, 6 Oct 1986  00:14 EDT
Message-ID: <SOLEY.12244530480.BABYL@XX.LCS.MIT.EDU>
From: SOLEY@XX.LCS.MIT.EDU
To:   Dave.Touretzky@A.CS.CMU.EDU
Cc:   common-lisp@SU-AI.ARPA
Subject: printing structures
In-reply-to: Msg of 3 Oct 1986  23:57-EDT from Dave.Touretzky at A.CS.CMU.EDU

    Date: Friday, 3 October 1986  23:57-EDT
    From: Dave.Touretzky at A.CS.CMU.EDU

    I second Ramin Zabih's suggestion that the default way to print a structure
    should be to NOT show its components.  If Common Lisp has to specify a
    default print convention, the #<SHIP 1234567> notation is a better choice.

I third the suggestion, and further suggest *print-structure* control
the action of the printer on structures (a la *print-array*), and default
to not show components.

These two are just general cases of "*print-readably*", so to speak;
perhaps we should generalize?

	-- Richard Soley

∂05-Oct-86  2223	ELIOT%cs.umass.edu@CSNET-RELAY.ARPA 	Printing Structures    
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 5 Oct 86  22:23:46 PDT
Received: from umass-cs by csnet-relay.csnet id ac02811; 6 Oct 86 1:08 EDT
Date:     Sun, 5 Oct 86 09:33 EDT
From:     ELIOT%cs.umass.edu@CSNET-RELAY.ARPA
To:       Common-Lisp@SU-AI.ARPA
Subject:  Printing Structures
X-VMS-To: CSNET%"Common-Lisp@Su-ai.arpa"

I do not want the default printing format for structures changed.
Symbolic's incorrect implementation of this has gotten me very upset.

The default syntax is good at the begining of an implementation, when
the data structures are being defined and you will be looking
closely at all of the details.  Eventually, I always define print
functions for each defstruct.  "Eventually" often means just before
I implement the functions to create circular links.

The default syntax is also good for teaching people about Lisp.  It is much
easier to explain how to use structures when you can show people
exactly what is in them.  It would be harder to convince people
that nothing magical is going on if`
  
if you had to define a print function while explaining it.

As for lexical closures, and other system defined objects which do
not behave well using the default syntax, nothing in CL should prevent
the implementation from giving these objects special syntax.  The default
syntax applies to user defined structures.

One more point.  The default syntax is also best for testing out new
Lisp features.

∂06-Oct-86  1045	DLW@ALDERAAN.SCRC.Symbolics.COM 	Printing Structures   
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 6 Oct 86  10:45:04 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 9317; Mon 6-Oct-86 13:43:14 EDT
Date: Mon, 6 Oct 86 13:48 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Printing Structures
To: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 5 Oct 86 09:33 EDT from ELIOT%cs.umass.edu@CSNET-RELAY.ARPA
Message-ID: <861006134816.4.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date:     Sun, 5 Oct 86 09:33 EDT
    From:     ELIOT%cs.umass.edu@CSNET-RELAY.ARPA

    I do not want the default printing format for structures changed.
    Symbolic's incorrect implementation of this has gotten me very upset.

Just for the record, Symbolics's Release 7 (coming very soon) implements
this in accordance with the standard.  In general, Release 7 has far
fewer variances with the CL spec than Release 6.

We also have a special variable, called *print-structure-contents*,
(default t, of course) that controls this behavior.  That several
implementations have found it necessary to adopt extensions to provide
this ability suggests that the ability ought to be made part of the
common standard.

∂06-Oct-86  2103	RWK@YUKON.SCRC.Symbolics.COM 	Re: printing structures  
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 6 Oct 86  21:03:30 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 98732; Tue 7-Oct-86 00:01:02 EDT
Date: Tue, 7 Oct 86 00:01 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: printing structures
To: Masinter.pa@Xerox.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <861005-200551-3386@Xerox>
Message-ID: <861007000135.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

    Date: 5 Oct 86 20:08 PDT
    From: Masinter.pa@Xerox.COM

    Separating out I/O for for inter-program communication and the
    user-interface is a good idea, but your proposal puts the burden on
    inter-program communication ("wrap this one form around the portion of
    your program which does I/O.") rather than on the user interface.

I claim that's where the burden belongs.  Programs interact
with the user a lot more than they interact with other programs
via read/print.  And these interactions happen in a myriad
unpredictable way (consider tracing, for example).  The
user-interface is global, it's the inter-program I/O that's
localized, so that's why it gets the form wrapped around it.

Besides and every time programms communicate, you have to think about
whether what is being communicated can be communicated via read/print,
whether you need *print-circle*, etc, anyway.

    Wouldn't it be simpler to suggest that implementors of a
    "top-level-loop" might want to bind a separate I/O environment for
    reading and printing (but not for execution)?  
That doesn't solve the problem.  It isn't just a matter of
printing the return values, it's error messages, messages from
the program, debugging, etc. etc.

    Back onto the original discussion: we added a variable *print-structure*
We called ours *print-structure-contents*

    which controlled how structures were printed by the default structure
    printer, in the same way that *print-array* controls array output. I'm
    reluctant to propose additions to the language, but if one was wanted,
    this seems like a logical choice.
Indeed.

∂07-Oct-86  0917	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	Re: printing structures  
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 7 Oct 86  09:16:57 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 16849; Tue 7-Oct-86 12:15:13 EDT
Date: Tue, 7 Oct 86 12:14 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: printing structures
To: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>,
    Masinter.pa@Xerox.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <861007000135.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <861007121449.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

    Date: Tue, 7 Oct 86 00:01 EDT
    From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>

	...
	Back onto the original discussion: we added a variable *print-structure*
    We called ours *print-structure-contents*
Nit: SYMBOLICS-COMMON-LISP:*PRINT-STRUCTURE-CONTENTS*, (or
SCL:*PRINT-STRUCTURE-CONTENTS*) to be exact.

	which controlled how structures were printed by the default structure
	printer, in the same way that *print-array* controls array output. I'm
	reluctant to propose additions to the language, but if one was wanted,
	this seems like a logical choice.
    Indeed.
Ditto.  I set it to NIL in my init file for the same reasons other
implementations have provided this extension.

∂16-Oct-86  0123	KMP@STONY-BROOK.SCRC.Symbolics.COM 	DEFVAR   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Oct 86  21:30:50 PDT
Received: from EMU.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 134663; Thu 16-Oct-86 00:30:09 EDT
Date: Thu, 16 Oct 86 00:28 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DEFVAR
To: Common-Lisp@SU-AI.ARPA
Message-ID: <861016002852.8.KMP@EMU.SCRC.Symbolics.COM>

CLtL (p68) is not explicit on its intent about whether (DEFVAR FOO) is
allowed to or intended to intialize FOO. For example, in Symbolics'
Common Lisp FOO is left unbound but in VAXLISP it is initialized to NIL.
The manual should state clearly whether an initialization occurs or be
more up front if an ambiguity is in fact intended.

∂16-Oct-86  0123	KMP@STONY-BROOK.SCRC.Symbolics.COM 	ADJUST-ARRAY  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Oct 86  21:43:08 PDT
Received: from EMU.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 134668; Thu 16-Oct-86 00:41:53 EDT
Date: Thu, 16 Oct 86 00:40 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ADJUST-ARRAY
To: Common-Lisp@SU-AI.ARPA
Message-ID: <861016004039.9.KMP@EMU.SCRC.Symbolics.COM>

CLtL (p297) says that it is "not permitted to call ADJUST-ARRAY on an
array that was not created with the :ADJUSTABLE option." This strikes me
as overly restrictive. Why don't we say that ADJUST-ARRAY always returns
an adjusted array and that the argument array will be modified only if
(ADJUSTABLE-ARRAY-P array) was true. This is no more unreasonable than
the current specification for the DELETE function. The way to be sure you
were going to win would be to say:

    (SETQ X (ADJUST-ARRAY X ...))

just as you would do

    (SETQ X (DELETE ... X))

and in special cases you would know that you didn't have to do the SETQ.
Does anyone really feel strongly that erring is necessary here? 

I have an application where this comes up and as nearly as I can tell,
I must now go and simulate the effect of ADJUST-ARRAY in order to create
an array to a new size and make sure it gets filled properly. It makes me
sad that I should have to do this when there's a function already that 
comes so close to what I want.

∂16-Oct-86  1604	Moon@STONY-BROOK.SCRC.Symbolics.COM 	ADJUST-ARRAY 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Oct 86  16:00:38 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 135094; Thu 16-Oct-86 13:23:35 EDT
Date: Thu, 16 Oct 86 13:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ADJUST-ARRAY
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: <861016004039.9.KMP@EMU.SCRC.Symbolics.COM>
Message-ID: <861016132226.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 16 Oct 86 00:40 EDT
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

    CLtL (p297) says that it is "not permitted to call ADJUST-ARRAY on an
    array that was not created with the :ADJUSTABLE option." This strikes me
    as overly restrictive. Why don't we say that ADJUST-ARRAY always returns
    an adjusted array and that the argument array will be modified only if
    (ADJUSTABLE-ARRAY-P array) was true. This is no more unreasonable than
    the current specification for the DELETE function.

I suspect people rely on arrays as updatable objects with identity a lot more
often than they rely on lists that way.  In other words, if ADJUST-ARRAY
sometimes quietly returns a new array and leaves the old one unadjusted,
there are likely to be other references to the old array that don't get
updated, and hence there will be bugs.

I always argued for making all arrays adjustable, for this reason.  Given
that we can't have that, I think your behavior is reasonable but it should
not be the default because it could lead to undetected bugs.

    I have an application where this comes up and as nearly as I can tell,
    I must now go and simulate the effect of ADJUST-ARRAY in order to create
    an array to a new size and make sure it gets filled properly. It makes me
    sad that I should have to do this when there's a function already that 
    comes so close to what I want.

This is a good argument.  This is a typical example of where Common Lisp went
wrong by standardizing a new, untried idea instead of standardizing current
practice, which would be okay except that what was standardized was a bundle
of several primitives and the underlying primitives were not exposed, so that
users can't easily define functions to hide the deficiencies they feel are
present in the standardized bundle.

I think there should be a new keyword argument to ADJUST-ARRAY that does
what you want, or else a separate function for this purpose, as there
was in Zetalisp (ARRAY-GROW).  I don't think the default behavior of
ADJUST-ARRAY should be changed, for reasons given above.  I can't think
of any good names for the keyword argument; the best I was able to come
up with was :IF-NOT-ADJUSTABLE with values :ERROR and :COPY.

∂16-Oct-86  1801	Moon@STONY-BROOK.SCRC.Symbolics.COM 	ADJUST-ARRAY 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Oct 86  18:01:02 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 135094; Thu 16-Oct-86 13:23:35 EDT
Date: Thu, 16 Oct 86 13:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ADJUST-ARRAY
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: <861016004039.9.KMP@EMU.SCRC.Symbolics.COM>
Message-ID: <861016132226.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 16 Oct 86 00:40 EDT
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

    CLtL (p297) says that it is "not permitted to call ADJUST-ARRAY on an
    array that was not created with the :ADJUSTABLE option." This strikes me
    as overly restrictive. Why don't we say that ADJUST-ARRAY always returns
    an adjusted array and that the argument array will be modified only if
    (ADJUSTABLE-ARRAY-P array) was true. This is no more unreasonable than
    the current specification for the DELETE function.

I suspect people rely on arrays as updatable objects with identity a lot more
often than they rely on lists that way.  In other words, if ADJUST-ARRAY
sometimes quietly returns a new array and leaves the old one unadjusted,
there are likely to be other references to the old array that don't get
updated, and hence there will be bugs.

I always argued for making all arrays adjustable, for this reason.  Given
that we can't have that, I think your behavior is reasonable but it should
not be the default because it could lead to undetected bugs.

    I have an application where this comes up and as nearly as I can tell,
    I must now go and simulate the effect of ADJUST-ARRAY in order to create
    an array to a new size and make sure it gets filled properly. It makes me
    sad that I should have to do this when there's a function already that 
    comes so close to what I want.

This is a good argument.  This is a typical example of where Common Lisp went
wrong by standardizing a new, untried idea instead of standardizing current
practice, which would be okay except that what was standardized was a bundle
of several primitives and the underlying primitives were not exposed, so that
users can't easily define functions to hide the deficiencies they feel are
present in the standardized bundle.

I think there should be a new keyword argument to ADJUST-ARRAY that does
what you want, or else a separate function for this purpose, as there
was in Zetalisp (ARRAY-GROW).  I don't think the default behavior of
ADJUST-ARRAY should be changed, for reasons given above.  I can't think
of any good names for the keyword argument; the best I was able to come
up with was :IF-NOT-ADJUSTABLE with values :ERROR and :COPY.

∂20-Oct-86  1046	FAHLMAN@C.CS.CMU.EDU 	DEFVAR  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Oct 86  10:46:12 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 20 Oct 86 13:45:49-EDT
Date: Mon, 20 Oct 1986  13:45 EDT
Message-ID: <FAHLMAN.12248348124.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc:   Common-Lisp@SU-AI.ARPA
Subject: DEFVAR
In-reply-to: Msg of 16 Oct 1986  00:28-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>


    CLtL (p68) is not explicit on its intent about whether (DEFVAR FOO) is
    allowed to or intended to intialize FOO.

I believe that everyone's intent was that (DEFVAR FOO) should leave FOO
unbound.  I would have sworn that the manual said this, but I guess it
doesn't.  

Given that and the current syntax, there is the question of how the user
is supposed to supply a doc string for the variable if no initial
value is wanted.  This was discussed in the past on one or two
occasions.  I think the general feeling was that SETF of DOCUMENTAITON
was good enough in the rare case where this functionality is needed.

-- Scott

∂21-Oct-86  0851	@UR-ACORN.ARPA,@UR-CASHEW.ARPA:miller@UR-ACORN.ARPA 	Applying functions to all the symbols in a package...    
Received: from UR-ACORN.ARPA by SAIL.STANFORD.EDU with TCP; 21 Oct 86  08:50:50 PDT
Received: from UR-CASHEW.ARPA by UR-ACORN.ARPA via INTERNET with SMTP id 35577; 21 Oct 86 11:52:33-EDT
Date: Tue, 21 Oct 86 11:53 EDT
From: Brad Miller <miller@UR-ACORN.ARPA>
Subject: Applying functions to all the symbols in a package...
To: common-lisp@SU-AI.ARPA
cc: miller@UR-ACORN.ARPA
Message-ID: <861021115308.3.MILLER@UR-CASHEW.ARPA>
Sender: miller@UR-ACORN.ARPA
Organization: University of Rochester, Department of Computer Science
Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627
Phone: 716-275-7747
Moon: 3 days, 13 hours, 15 minutes since the full moon.

As a general rule, I find that as a style of coding, MAP and recursion are the
most clear, iteration much less so, and GO's the least so. I realize this may
be somewhat of a religious issue, so I won't go into why I despise iteration,
with the possible exception of array manipulation.

For this reason, I am somewhat surprised, that CL has iterative functions for
fiddling with all they symbols in a package (i.e. DO-SYMBOLS and
DO-EXTERNAL-SYMBOLS but no equivalent MAP forms (e.g. the zetalisp MAPATOMS
and MAPATOMS-ALL). This is particularly surprising in light of the fact that
almost every other MAP function has equivalent iterations forms, and
vice-versa.

I would like to suggest that such functions be added to the CL standard.  I
believe the zetalisp functions mentioned above are sufficient, and provide a
clean user interface.  This would be a downward compatible upgrade.

Brad Miller
------
miller@rochester.arpa
miller@ur-acorn.arpa

∂21-Oct-86  0913	FAHLMAN@C.CS.CMU.EDU 	Applying functions to all the symbols in a package...
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Oct 86  09:13:11 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 21 Oct 86 12:12:19-EDT
Date: Tue, 21 Oct 1986  12:12 EDT
Message-ID: <FAHLMAN.12248593239.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Brad Miller <miller@UR-ACORN.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Applying functions to all the symbols in a package...
In-reply-to: Msg of 21 Oct 1986  11:53-EDT from Brad Miller <miller at UR-ACORN.ARPA>


Back when the initial design was being done, we explicitly considered
whether to go with MAP-SYMBOLS or DO-SYMBOLS.  At the time, it seemed
that most of us had the opposite religion from Mr. Miller.  Most of us
favored the iterative form, and I don't remember anyone arguing for the
mapping form.  A practical argument is that DO-SYMBOLS typically is used
in situations where there are a LOT of symbols must be processed, and in
the absence of a very clever compiler the MAP form would be slower due
to the need for explicitly calling the supplied functional argument.

I don't think that it would be worthwhile to include both forms just to
accommodate both stylistic preferences.  These facilities are not used
often, so the occasional use of a less-favored style should not be a big
hardship for anyone.  And, of course, fanatical DO-haters can write a
MAP-SYMBOLS macro easily enough, and not have to worry about what it
expands into.

-- Scott

∂30-Oct-86  1346	RPG   	Fahlman's remarks 
 ∂28-Oct-86  0819	FAHLMAN@C.CS.CMU.EDU 	Fahlman's remarks 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 86  08:18:54 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 28 Oct 86 11:17:12-EST
Date: Tue, 28 Oct 1986  11:17 EST
Message-ID: <FAHLMAN.12250429124.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   willc%tekchips.tek.csnet@RELAY.CS.NET
Cc:   Bobrow.pa@XEROX.COM, dlw@SCRC-STONY-BROOK.ARPA, gjs@AI.AI.MIT.EDU,
      GLS@ZARATHUSTRA.THINK.COM, RPG@SU-AI.ARPA, scherlis@C.CS.CMU.EDU,
      willc%tekchips.tek.com@RELAY.CS.NET, fahlman@C.CS.CMU.EDU
Subject: Fahlman's remarks
In-reply-to: Msg of 27 Oct 1986  15:38-EST from willc%tekchips.tek.csnet at CSNET-RELAY.ARPA


Will,

As you noticed, my earlier post was biased -- I wasn't even trying to be
fair.  Actually, I was hoping that by presenting the anti-change side of
the argument in an argumentative style, I would inspire someone to put
together the best possible case in favor of the change.  I'd really like
to see that, and don't see a compelling case for making the change at
present.  So, if you are tempted to add arguments in favor of the
change, please don't resist the temptation.  I'd honestly like to see
what they are (besides the ones I listed).

A couple of serious rebuttals to your serious comments:

    Macros have problems, but I can't accept the argument that people don't
    use FLET and LABELS very often so it's ok to have a macro screw the few
    who do.  

Well, we differ in what we can accept, I guess.  FLET and LABELS are in
Common Lisp over my objections.  In all the Common Lisp code I've seen,
these things are practically never used, and in the rare cases when they
are used the user can take special care to avoid using macros with which
he is not personally familiar.  So this hole in Common Lisp is
theoretical, and doesn't bother anyone with the good sense to avoid
using FLET and LABELS altogether.  But the problem with macros and
merged names spaces is onmipresent and unavoidable.  If we really feel
that the current situation is too treacherous to tolerate in the long
run, I would advocate removing FLET and LABELS rather than removing or
adding great hair to macros, which are used very heavily.

    I would say that correct macros are hard to write, and always have been.
    Incorrect macros are as easy to write as ever.  It is certainly true that
    bugs in macros are more likely to be discovered with a more uniform
    semantics; in the real world, this is considered a good thing.

Again, the "incorrectness" at present is manifested only in a couple of
odd situations that most sensible programmers avoid.  After the
namespace merger, the same kind of incorrectness can lead to nasty
hard-to-find problems in any part of your code, and the user must
therfore take great care to avoid such incorrectness.  We don't have
good mechanisms for this at present.  If we did, I'd feel a lot better
about this.

I don't understand why merging the namespaces would make it easier to
discover these bugs.  Can you elaborate, beyond just saying that it
makes the semantics more uniform?  Is it just that the merger tends to
insure that the bugs will come out and bite you rather than lying
dormant waiting for someone to do something dumb with an FLET?

    It seems to me that Kohlbecker's recent thesis is the best extant
    summary of the problems with Lisp macros and their proposed solutions.
    I agree that Kohlbecker's solutions are not fully acceptable, but they
    are better than anything I've seen coming out of the Common Lisp community.

Maybe we should wait until someone has a "fully acceptable" solution to
the macro problem to propose before we make changes that make the
effects of this problem much more serious for working programmers?
Until then, I'm much more comfortable with the situation in Common Lisp,
in which macros are quite useful and quite heavily used, despite the
theoretically dangerous interaction with FLET and LABELS.

    In my view, the one significant argument against getting rid of the
    function environment is the cost of converting existing code.  This
    is not an argument that is likely to carry much weight with someone
    who has just begun to use Lisp or is thinking about using Lisp, and
    I should hope that people now in that situation will form the majority
    of users for any eventual Lisp standard.  If not, the standard will
    have failed.

True, but all users are not created equal.  These new users will want to
build on the large body of software that exists in Common Lisp when they
take it up, not on the bare language itself.  So the question is whether
the benfits of this change are worth chucking out all the software
accumulated so far and starting over, or at least spending a number of
high-quality man-years fixing old code and getting all the fixes to hang
together at once, instead of producing useful new programs.  I'm not
saying that no change could ever be worth such an effort; I am wondering
whether THIS change is worth the effort at this time.

As a rule, if some change is going to come eventually, it is better to
take the hit now rather than later, since the total cost will be
smaller.  However, a lot of companies and new users have finally been
drawn into Common Lisp by the promise of a widespread and stable
standard, and this might not not be a time in which to turn the Common
Lisp world upside down, especially if we can't explain what real
benefits this disruptive change will bring to the user community.

-- Scott

∂30-Oct-86  1346	RPG   	Fahlman's remarks 
 ∂28-Oct-86  0922	gls@Think.COM 	Fahlman's remarks   
Received: from ZARATHUSTRA.THINK.COM by SAIL.STANFORD.EDU with TCP; 28 Oct 86  09:22:07 PST
Received: by Zarathustra.Think.COM; Tue, 28 Oct 86 12:18:20 EST
Received: from valentine by Godot.Think.COM via CHAOS; Tue, 28 Oct 86 12:20:40 est
Date: Tue, 28 Oct 86 12:22 EST
From: Guy Steele <gls@Think.COM>
Subject: Fahlman's remarks
To: Fahlman@C.CS.CMU.EDU, willc%tekchips.tek.csnet@RELAY.CS.NET
Cc: Bobrow.pa@XEROX.COM, dlw@SCRC-STONY-BROOK.ARPA, gjs@AI.AI.MIT.EDU,
        GLS@ZARATHUSTRA, RPG@SU-AI.ARPA, scherlis@C.CS.CMU.EDU,
        willc%tekchips.tek.com@RELAY.CS.NET, gls@AQUINAS
In-Reply-To: <FAHLMAN.12250429124.BABYL@C.CS.CMU.EDU>
Message-Id: <861028122203.1.GLS@VALENTINE.THINK.COM>

I too would be grateful if Will should choose to draw up a more closely
reasoned set of arguments in favor of the namespace merger.  (Maybe
bring it to the meeting, Will?)

I would like to caution Scott that while he has seen a great deal of
Common Lisp code, he has not seen it all.  Neither have I, but I do know
that there is a substantial body of "working code" (read "code that some
company makes a lot of money from") that uses LABELS quite heavily and
with good reason.  I don't think it is a simple matter of "nobody uses
LABELS, so let's just flush it", nor is it a matter of "anyone who uses
LABELS is a loser (not `sensible')"; just as it is not a simple matter
of "let's just merge the namespaces, because anyone who would be screwed
is a loser".

--Guy

∂30-Oct-86  1347	RPG   	Fahlman's remarks 
 ∂28-Oct-86  1039	FAHLMAN@C.CS.CMU.EDU 	Fahlman's remarks 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 86  10:39:35 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 28 Oct 86 13:38:31-EST
Date: Tue, 28 Oct 1986  13:38 EST
Message-ID: <FAHLMAN.12250454822.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   willc%tekchips.tek.csnet@RELAY.CS.NET, Bobrow.pa@XEROX.COM,
      dlw@SCRC-STONY-BROOK.ARPA, gjs@AI.AI.MIT.EDU, GLS@ZARATHUSTRA.THINK.COM,
      RPG@SU-AI.ARPA, scherlis@C.CS.CMU.EDU, fahlman@C.CS.CMU.EDU
Subject: Fahlman's remarks
In-reply-to: Msg of 27 Oct 1986  15:38-EST from willc%tekchips.tek.csnet at CSNET-RELAY.ARPA


Date: Tuesday, 28 October 1986  11:34-EST
From: Dick Gabriel <RPG at SAIL.STANFORD.EDU>
To:   fahlman at C.CS.CMU.EDU
Re:   FLET/LABELS   

Scott, please forward this - I'm leaving for the airport right now.

In Lucid system code and in Lucid user's code we see *a lot*
of LABELS code. I would say that the use of FLET/LABELS has
taken off rather than being a curiosity.

			-rpg-


∂30-Oct-86  1422	RPG   	Fahlman's remarks 
 ∂27-Oct-86  2158	willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Fahlman's remarks
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 27 Oct 86  21:58:11 PST
Received: from tektronix by csnet-relay.csnet id ai11952; 27 Oct 86 18:02 EST
Received: by tektronix.TEK (5.31/6.16)
	id AA12252; Mon, 27 Oct 86 12:36:42 PST
Received: by tekchips.TEK (5.31/6.16)
	id AA07540; Mon, 27 Oct 86 12:38:52 PST
Message-Id: <8610272038.AA07540@tekchips.TEK>
To: RPG@SU-AI.ARPA, Bobrow.pa@XEROX.COM, dlw@SCRC-STONY-BROOK.ARPA, 
    gjs@AI.AI.MIT.EDU, GLS@ZARATHUSTRA.THINK.COM, scherlis@C.CS.CMU.EDU, 
    fahlman@C.CS.CMU.EDU
Cc: willc%tekchips.tek.com@CSNET-RELAY.ARPA
Subject: Fahlman's remarks
Date: 27 Oct 86 12:38:47 PST (Mon)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA

Fahlman listed four arguments in favor of getting rid of the separate
function environment, devoting one line to each and tainting each by a
begrudging parenthetical remark.  For amusement (and balance),  I have
edited his arguments against the change into that style.

I was tempted to add arguments in favor, but I resisted.  Below the
edited arguments, however, I add a couple of serious observations.

----------------------------------------------------------------
ARGUMENTS IN FAVOR OF THE CHANGE:

Makes the language more elegant in the eyes of some.

* Simplifies compilers (a bit).

* Simplifies formal reasoning about programs (though the practical
importance of this is unclear at present).

* Making this move may be the cost of peace with the Eulisp group (or it
may encourage them to make additional demands).

* Brings Common Lisp somewhat closer to Scheme (though there are so many
other differences that this may not matter much).

ARGUMENTS AGAINST THE CHANGE:

* Statically typed variables help prevent mistakes (and make programming
less convenient).

* FUNCALL might be expensive so it ought to look expensive (but it ought
not to be).

* Existing implementations will have to change (future implementations
also if the change is merely put off).

* Existing user programs will have to be fixed (future programs also
if the change is merely put off).

* Complicates the link-table strategy (a bit).

* Fixing one problem might imply that we're going to do something about
the others (but we probably won't).

* Macros that insert free references to function variables won't work
(but they don't work even now, thanks to FLET and LABELS).

----------------------------------------------------------------
Macros have problems, but I can't accept the argument that people don't
use FLET and LABELS very often so it's ok to have a macro screw the few
who do.  There is a solution, which is to give the macro writer a
mechanism for inserting direct references to procedures and other values
(as opposed to indirect references through a named variable) into the
expanded code.  Fahlman objects that macros then become hard to write.
I would say that correct macros are hard to write, and always have been.
Incorrect macros are as easy to write as ever.  It is certainly true that
bugs in macros are more likely to be discovered with a more uniform
semantics; in the real world, this is considered a good thing.

It seems to me that Kohlbecker's recent thesis is the best extant
summary of the problems with Lisp macros and their proposed solutions.
I agree that Kohlbecker's solutions are not fully acceptable, but they
are better than anything I've seen coming out of the Common Lisp community.

----------------------------------------------------------------
In my view, the one significant argument against getting rid of the
function environment is the cost of converting existing code.  This
is not an argument that is likely to carry much weight with someone
who has just begun to use Lisp or is thinking about using Lisp, and
I should hope that people now in that situation will form the majority
of users for any eventual Lisp standard.  If not, the standard will
have failed.

Peace, Will

∂31-Oct-86  1324	edsel!sunvalleymall!jlz@navajo.stanford.edu 	Call for Papers
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 31 Oct 86  13:23:55 PST
Received: by navajo.stanford.edu; Fri, 31 Oct 86 13:22:27 PST
Received: from sunvalleymall.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
	id AA03857; Fri, 31 Oct 86 12:33:15 pst
Received: by sunvalleymall.edsel.uucp (1.1/SMI-3.0DEV3)
	id AA09846; Fri, 31 Oct 86 12:34:05 PST
Date: Fri, 31 Oct 86 12:34:05 PST
From: edsel!sunvalleymall!jlz@navajo.stanford.edu (Jan Zubkoff)
Message-Id: <8610312034.AA09846@sunvalleymall.edsel.uucp>
To: navajo!Common-lisp%sail@navajo.stanford.edu
Cc: sunvalleymall!jlz@navajo.stanford.edu
Subject: Call for Papers



		      LISP AND SYMBOLIC COMPUTATION:
		      An International Journal
				     
				 10/27/86

			      CALL FOR PAPERS



LISP AND SYMBOLIC COMPUTATION: An International Journal (LASC) is
a new journal published by Kluwer Academic Publishers.  Richard
P. Gabriel, Lucid, Inc. and Guy L. Steele Jr., Thinking Machines,
Inc. are Editors-in-Chief.

The aim of this new journal is to present a forum for current and
evolving symbolic computing, focusing on LISP and
object-oriented programming.  The scope includes:



	* Programming language notations for symbolic computing
	  (e.g., data abstraction, parallelism, lazy evaluation,
	  infinite data objects, self-reference, message-passing,
	  generic functions, inheritance, encapsulation,
	  protection, metaobjects).

	* Implementations and techniques (e.g., specialized
	  architectures, compiler design, combinatory models,
	  garbage collection, storage management, performance
	  analysis, smalltalks, flavors, common loops, etc.).

	* Programming logics (e.g., semantics and reasoning about
	  programs, types and type inference).

	* Programming environments and tools (e.g.,
	  Knowledge-based programming tools, program
	  transformations, specifications, debugging tools).

	* Applications and experience with symbolic computing
	  (e.g., real-time programming, artificial intelligence
	  tools, experience with LISP, object-oriented
	  programming, window systems, user interfaces, operating
	  systems, parallel/distributed computing.

!

			REQUIREMENTS FOR SUBMISSION




Timetable.  Authors must submit five (5) complete copies of their papers.
Notice of acceptance or rejection will be sent to the first author.

Appearance.  Each copy of the paper should be clearly legible.
Papers should be printed on 8-1/2 by 11" paper, double spaced
with at least 1 inch margins with no smaller than 12 pt.  type.

Title Page.  Each copy of the paper must have a title page (separate from
the body of the paper) containing the title of the paper, the names and
addresses of all the authors.  The affiliation appearing under the author's
name should be the name of the organization for which the work was carried
out.  When this is no longer the author's current affiliation, the latter
is given in the address footnote on the first page.  The title page must
specify one topic from the scopes listed on the reverse side of this page.

Abstract.  The abstract should be 150 to 200 words and should be short and
direct.  It should be informative enough to serve as a substitute for
reading the paper itself.  Work planned but not done should not be
described in the abstract.  Do not display formulas and do not use citation
reference numbers.

Review Criteria.  Each paper will be reviewed by experts in the area
specified from the scope as the topic of the paper.  Acceptance will be
based on overall merit and significance of the reported research, as well
as the quality of the presentation.

Please send papers to: 

Jan Zubkoff		
Associate Editor, LASC			
Lucid, Inc.		
707 Laurel Street	
Menlo Park, CA  94025	
edsel!jlz@su-navajo	
(415) 329-8400


Suggestions and inquiries to:

Dick Gabriel			Guy L. Steele Jr.
Editor-in-Chief			Editor-in-Chief
Lucid, Inc.			Thinking Machines, Inc.
707 Laurel Street		245 First Street
Menlo Park, CA  94025		Cambridge, MA  02142
rpg@sail			gls@think.COM
(415) 329-8400			(617) 876-1111


∂31-Oct-86  1923	JAR@AI.AI.MIT.EDU 	[KLOTZ: defstruct initialization in :constructor ] 
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Oct 86  19:23:42 PST
Date: Fri, 31 Oct 86 22:25:47 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  [KLOTZ: defstruct initialization in :constructor ]
To: common-lisp@SU-AI.ARPA
Message-ID: <[AI.AI.MIT.EDU].113071.861031.JAR>

Parameter lists for :CONSTRUCTOR's should act as much as possible like
lambda lists.  CLtL doesn't require this, but it seems like a good idea.

- Jonathan

Date: Thu, 2 Oct 86 20:31 EDT
From: Leigh L. Klotz <KLOTZ at OZ.AI.MIT.EDU>
To:   pgslcd at AI.AI.MIT.EDU
cc:   jar at AI.AI.MIT.EDU
Re:   defstruct initialization in :constructor 
Message-ID: <861002203146.1.KLOTZ@JOE-LOUIS.LCS.MIT.EDU>

(DEFSTRUCT (STATIC-VARIABLE-CACHE-ENTRY
	     (:CONSTRUCTOR MAKE-STATIC-VARIABLE-CACHE-ENTRY
		(REAL-OBJECT &AUX
			     (VARIABLE (CAR REAL-OBJECT))
			     (UNIQUE-IDENTIFIER (CADR REAL-OBJECT)))))
  VARIABLE
  UNIQUE-IDENTIFIER
  REAL-OBJECT)

The silver book doesn't explicitly say that the &aux's can depend on the
real args, but it does say that &aux was included to make all desirable
behaviors possible, and &aux forms in lambda can depend on the args.

...

∂03-Nov-86  0718	samalone@ATHENA.MIT.EDU 	DEFSTRUCT copier query   
Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Nov 86  07:18:31 PST
Received: by ATHENA (5.45/4.7)
	id AA10177; Mon, 3 Nov 86 10:18:01 EST
From: <samalone@ATHENA.MIT.EDU>
Received: by ARES (5.45/4.7)
	id AA20604; Mon, 3 Nov 86 10:17:13 EST
Date: Mon, 3 Nov 86 10:17:13 EST
Message-Id: <8611031517.AA20604@ARES>
To: common-lisp@sail.stanford.edu
Subject: DEFSTRUCT copier query

What is the defined behavior of the DEFSTRUCT-created copier function in the
face of :INCLUDEd types?  For instance, given:

(defstruct bread
  (state 'freshly-baked))

(defstruct (rye-bread (:include bread))
  (seeded-p t))

is the result of evaluating:

(copy-bread (make-rye-bread :state 'stale :seeded-p nil))


	A:	#S(RYE-BREAD :STATE STALE :SEEDED-P NIL)
or
	B:	#S(BREAD :STATE STALE)

I am hoping that the correct answer is A.  A function with behavior B can be
easily implemented in Common Lisp by any user who needs it, while a function
with behavior A cannot be without hardwiring all of the subtypes (recursively)
of the structure into the function, which seems like a harsh fate.

				--Stuart A. Malone

∂03-Nov-86  0755	RAM@C.CS.CMU.EDU 	DEFSTRUCT copier query
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Nov 86  07:55:07 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 3 Nov 86 10:54:15-EST
Date: Mon, 3 Nov 1986  10:54 EST
Message-ID: <RAM.12251997821.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   <samalone@ATHENA.MIT.EDU>
Cc:   common-lisp@SU-AI.ARPA
Subject: DEFSTRUCT copier query
In-reply-to: Msg of 3 Nov 1986  10:17-EST from <samalone at ATHENA.MIT.EDU>

    Date: Monday, 3 November 1986  10:17-EST
    From: <samalone at ATHENA.MIT.EDU>
    Re:   DEFSTRUCT copier query

    (copy-bread (make-rye-bread :state 'stale :seeded-p nil))

	A:	#S(RYE-BREAD :STATE STALE :SEEDED-P NIL)
    or
	B:	#S(BREAD :STATE STALE)

This unclarity has been pointed out before, but there didn't seem to
be any real consensus.  I agree that it seems to be semantically
cleaner to return an object of the same type as the argument.  I think
the only reasonable alternative would be to say that it is erronous.
Since there doesn't seem to be any support for B, no one can complain
if you implement A, although it may not be required for Common Lisp.

  Rob

∂03-Nov-86  1338	Pavel.pa@Xerox.COM 	Re: DEFSTRUCT copier query    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 3 Nov 86  12:49:53 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 03 NOV 86 11:57:47 PST
Date: 3 Nov 86 11:57 PST
From: Pavel.pa@Xerox.COM
Subject: Re: DEFSTRUCT copier query
In-reply-to: Rob MacLachlan <RAM@C.CS.CMU.EDU>'s message of Mon, 3 Nov
 86 10:54 EST
To: RAM@C.CS.CMU.EDU
cc: samalone@ATHENA.MIT.EDU, common-lisp@SU-AI.ARPA
Message-ID: <861103-115747-5004@Xerox>

    Date: Mon, 3 Nov 86 10:54 EST
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>

        Date: Monday, 3 November 1986  10:17-EST
        From: <samalone at ATHENA.MIT.EDU>

        (copy-bread (make-rye-bread :state 'stale :seeded-p nil))

             A:	#S(RYE-BREAD :STATE STALE :SEEDED-P NIL)
        or
             B:	#S(BREAD :STATE STALE)

    Since there doesn't seem to be any support for B, no one can
    complain if you implement A, although it may not be required for
    Common Lisp.

I can complain, and I would.  I am strongly of the opinion that the
function COPY-BREAD here should always create a value of type BREAD, not
one of its subtypes.  If you want to get the effect of A, let us create
a new function COPY that copies any Lisp value at all.  It seems strange
to have several such functions, one for each section of the type space.
I claim that such a function, along with COPY-BREAD having semantics B
above, would provide all of the functionality desired in the cleanest
way.

	Pavel

∂03-Nov-86  1937	Bobrow.pa@Xerox.COM 	Re: DEFSTRUCT copier query   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 3 Nov 86  19:36:48 PST
Received: from Salvador.ms by ArpaGateway.ms ; 03 NOV 86 18:14:13 PST
Date: 3 Nov 86 18:13 PST
Sender: Bobrow.pa@Xerox.COM
Subject: Re: DEFSTRUCT copier query
In-reply-to: Pavel.pa's message of 3 Nov 86 11:57 PST
To: Pavel.pa@Xerox.COM
cc: RAM@C.CS.CMU.EDU, samalone@ATHENA.MIT.EDU, common-lisp@SU-AI.ARPA
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861103-181413-5511@Xerox>

        Date: Mon, 3 Nov 86 10:54 EST From: Rob MacLachlan
        <RAM@C.CS.CMU.EDU>

            Date: Monday, 3 November 1986  10:17-EST From:
            <samalone at ATHENA.MIT.EDU>

            (copy-bread (make-rye-bread :state 'stale :seeded-p
    nil))

                 A:	#S(RYE-BREAD :STATE STALE :SEEDED-P
            NIL) or
                 B:	#S(BREAD :STATE STALE)

        Since there doesn't seem to be any support for B, no
        one can complain if you implement A, although it may not be
        required for Common Lisp.

    I can complain, and I would.  I am strongly of the opinion that
    the function COPY-BREAD here should always create a value of type
    BREAD, not one of its subtypes.  If you want to get the effect of
    A, let us create a new function COPY that copies any Lisp value at
    all.  It seems strange to have several such functions, one for each
    section of the type space. I claim that such a function, along with
    COPY-BREAD having semantics B above, would provide all of the
    functionality desired in the cleanest way.

    	Pavel

Within the new emerging Common Lisp Object Standard, COPY will be
specified as a generic function that copies its argument, producing an
instance of the same type.  Functions such as copy-bread would be an
anomaly, but could mean what Pavel suggested.


-- danny

∂03-Nov-86  1938	@MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU 	DEFSTRUCT copier query
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Nov 86  19:38:42 PST
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM (DIAL|DIAL|4925473) by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 15523; 3 Nov 86 22:37:26-EST
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 43523; Mon 3-Nov-86 21:12:54-EST
Date: Mon, 3 Nov 86 22:13 est
Sender: mike@acorn
To: RAM@C.CS.CMU.EDU
From: mike%acorn@mit-live-oak.arpa
Subject: DEFSTRUCT copier query
Cc: samalone@ATHENA.MIT.EDU, common-lisp@SU-AI.ARPA

    Date: Mon, 3 Nov 1986  10:54 EST
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
    
        Date: Monday, 3 November 1986  10:17-EST
        From: <samalone at ATHENA.MIT.EDU>
        Re:   DEFSTRUCT copier query
    
        (copy-bread (make-rye-bread :state 'stale :seeded-p nil))
    
    	A:	#S(RYE-BREAD :STATE STALE :SEEDED-P NIL)
        or
    	B:	#S(BREAD :STATE STALE)
    
    This unclarity has been pointed out before, but there didn't seem to
    be any real consensus.  I agree that it seems to be semantically
    cleaner to return an object of the same type as the argument.  I think
    the only reasonable alternative would be to say that it is erronous.
    Since there doesn't seem to be any support for B, no one can complain
    if you implement A, although it may not be required for Common Lisp.
    
      Rob
    
While we're at it, there are alot of problems with inheritance in
defstruct. Another is,

(defun (foo (:print-function (lambda ...)))

(defun (bar (:include foo)) slot1 slot2)

Now, does bar have a print function inherited from foo?
Clearly it can't inherit the constructor function from foo since
it doesn't have the same slots as foo, but the print function
is more at issue.

I think we should define :include to include only slots, and not any
other functions by options.  If CommonLoops catches on, and if the
defstruct syntax is chosen, then we can specify the inheritance for
objects of class STRUCTURE to be only this, and you can use 
a different class for inheriting other stuff.

....mike beckerle
Gold Hill Computers






∂06-Nov-86  2120	sridhar%tekchips.tek.csnet@RELAY.CS.NET 	Why is #'equalp not allowed in make-hash-table ? 
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 6 Nov 86  21:20:25 PST
Received: from tektronix by csnet-relay.csnet id aa05236; 6 Nov 86 15:46 EST
Received: by tektronix.TEK (5.31/6.16)
	id AA12988; Thu, 6 Nov 86 11:43:04 PST
Received: by tekchips.TEK (5.31/6.16)
	id AA13331; Thu, 6 Nov 86 11:43:11 PST
Message-Id: <8611061943.AA13331@tekchips.TEK>
To: common-lisp@SU-AI.ARPA
Subject: Why is #'equalp not allowed in make-hash-table ?
Date: 06 Nov 86 11:43:08 PST (Thu)
From: sridhar%tekchips.tek.csnet@RELAY.CS.NET


 I want to create a hash table in which the keys are lisp objects
that satisfy #'equalp. CLtL does not allow #'equalp  in :test
argument to make-hash-table. Why?
Specifically I cannot have vectors as key values.
For instance  , how can you create a hash-table such that:

	(setf (gethash (setq a (vector 1 2 3)) hash-table) 'foo)
	(gethash a hash-table) => FOO T
        (gethash (vector 1 2 3 ) hash-table) => FOO T.

--sridhar

∂07-Nov-86  1028	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	DEFVAR    
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 7 Nov 86  10:14:45 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25906; Fri 7-Nov-86 13:12:59 EST
Date: Fri, 7 Nov 86 13:12 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: DEFVAR
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
    Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12248348124.BABYL@C.CS.CMU.EDU>
Message-ID: <861107131230.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

    Date: Mon, 20 Oct 1986  13:45 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

	CLtL (p68) is not explicit on its intent about whether (DEFVAR FOO) is
	allowed to or intended to intialize FOO.

    I believe that everyone's intent was that (DEFVAR FOO) should leave FOO
    unbound.  I would have sworn that the manual said this, but I guess it
    doesn't.  

    Given that and the current syntax, there is the question of how the user
    is supposed to supply a doc string for the variable if no initial
    value is wanted.  This was discussed in the past on one or two
    occasions.  I think the general feeling was that SETF of DOCUMENTAITON
    was good enough in the rare case where this functionality is needed.

I personally preferred the
	(defvar foo foo "foo's doc string")
suggestion since that is one declarative form instead of
	(defvar foo)
	(setf (documentation 'foo) "foo's doc string")
on the grounds that the latter is two forms, one declarative and one
procedural, and is more clumsy.  It's not at all clear this is "rare".

∂08-Nov-86  1208	RPG   	Re: from Japan    
 ∂08-Nov-86  0707	MATHIS@ADA20.ISI.EDU 	Re: from Japan    
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 8 Nov 86  07:07:43 PST
Date: 8 Nov 1986 06:54-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: Re: from Japan
From: MATHIS@ADA20.ISI.EDU
To: a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Cc: Mathis@ADA20.ISI.EDU, Fahlman@C.CS.CMU.EDU
Cc: rpg@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU] 8-Nov-86 06:54:19.MATHIS>
In-Reply-To: <8611041357.AA17427@ccut.u-tokyo.junet>

Idasan, Thank you for the message.  I got it just before I was
leaving for the SC22 meeting in Vienna, Austria.  I am glad you
hada chance to talk with Nakata.  I don't know how things will
go, but I'll send out a message next weekend when Iget back.  --
Bob Mathis

∂10-Nov-86  1921	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Why is #'equalp not allowed in make-hash-table ?
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Nov 86  19:21:11 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 155303; Mon 10-Nov-86 22:19:54 EST
Date: Mon, 10 Nov 86 22:19 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Why is #'equalp not allowed in make-hash-table ?
To: sridhar%tekchips.tek.csnet@RELAY.CS.NET
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8611061943.AA13331@tekchips.TEK>
Message-ID: <861110221911.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 06 Nov 86 11:43:08 PST (Thu)
    From: sridhar%tekchips.tek.csnet@RELAY.CS.NET

     I want to create a hash table in which the keys are lisp objects
    that satisfy #'equalp. CLtL does not allow #'equalp  in :test
    argument to make-hash-table. Why?

The :test argument to make-hash-table is not user-extensible because of
the nature of hashing.  Each :test function has to have a corresponding
hashing function, which maps from an object to an integer that can be
used as an index into the hash table.  These two functions have to be
consistent in the sense that for any two objects A and B, if the test
function returns true when applied to A and B, then the hash function
must return the same integer for both A and B.

Because Common Lisp didn't want to provide portable ways for users to
write hashing functions (in general this requires implementation
dependent knowledge to do a good job), Common Lisp doesn't allow
arbitrary predicates to be provided for the :test argument.

I think your suggestion that equalp be added to the set of allowed
predicates is a good one.

∂11-Nov-86  1220	edsel!bhopal!jonl@navajo.stanford.edu 	Why is #'equalp not allowed in make-hash-table ?   
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Nov 86  12:20:36 PST
Received: by navajo.stanford.edu; Tue, 11 Nov 86 12:17:26 PST
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
	id AA03376; Fri, 7 Nov 86 11:17:31 pst
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
	id AA06073; Fri, 7 Nov 86 11:16:24 PST
Date: Fri, 7 Nov 86 11:16:24 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8611071916.AA06073@bhopal.edsel.uucp>
To: navajo!sridhar%tekchips.tek.csnet%RELAY.CS.NET@navajo.stanford.edu
Cc: navajo!common-lisp%su-ai.arpa@navajo.stanford.edu
In-Reply-To: navajo!sridhar%tekchips.tek.csnet@RELAY.CS.NET's message of 06 Nov 86 11:43:08 PST (Thu)
Subject: Why is #'equalp not allowed in make-hash-table ?


About a year or so ago, there were two points about hash-tables receiving 
heavy discussion:
  1) Why not permit any predicate of two arguments as the :test argument
  2) Why not permit explicit specification of the "sxhashing" function.

Several implementations, Lucid's included, have the capability of doing 
(1) with no extra work.  However, the question posed by (2) raises the 
issue of consistency between the "numericalizing" function [i.e., whatever 
you might use in place of sxhash] and the "equivalencing" function [i.e., 
whatever you might use in place of equal].

Although there didn't seem to be general consensus on the issue, the 
proposal that seemed most consistent to me was:
  (A) Extend Common Lisp hash-tables to permit any two-argument predicate 
      to be used as a :test function; and add an :sxhash argument which 
      specifies the function to reduce an s-expression into the integer 
      used in computing the collision chains (assuming you hash that way).
  (B) The default for the :sxhash argument for EQ/EQL type tables can be
      something internal (probably not documented or exported); the 
      default for any other :test argument will be #'equal.
This permits the extensions without having to address the issue of having
a function which computes the address of a pointer (for EQ/EQL tables).

Along that line I wonder why the default isn't :test = #'EQUAL, rather
than #'EQL?  (or better yet, #'EQUALP).  The EQ/EQL semantics is almost
never right when the table contains "complex" structures like lists,
vectors, defstructs and so on, and typically has unfortunate consequences
for relocating garbage collectors. Yet an EQUAL table can be just as
"speedy" as an EQ/EQL one when the entries aren't such "complex" entities;
so one should never try to switch semantics merely for "speed".  This
doesn't say that there is no place for EQ/EQL tables -- merely that they 
are often used for the wrong reasons.


-- JonL --

∂11-Nov-86  1300	@MIT-LIVE-OAK.ARPA:Soley@MIT-XX.ARPA 	Why is #'equalp not allowed in make-hash-table ?    
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 11 Nov 86  12:59:53 PST
Received: from MIT-CHERRY.ARPA by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 16388; Tue 11-Nov-86 15:49:47-EST
Date: Tue, 11 Nov 86 15:50 EST
From: Soley@MIT-XX.ARPA
Subject: Why is #'equalp not allowed in make-hash-table ?
To: common-lisp@SU-AI.ARPA
In-Reply-To: <8611071916.AA06073@bhopal.edsel.uucp>
Message-ID: <861111155021.1.SOLEY@CHERRY.LCS.MIT.EDU>

    Along that line I wonder why the default isn't :test = #'EQUAL, rather
    than #'EQL?

For symmettry with ASSOC, MEMBER, DELETE, REMOVE, etc.

	-- Richard

∂12-Nov-86  1435	STEVER%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	Declarations within FLET    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Nov 86  14:34:58 PST
Date: Wed, 12 Nov 1986  17:34 EST
Message-ID: <STEVER.12254430013.BABYL@MIT-OZ>
From: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To:   common-lisp%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Subject: Declarations within FLET


Is there any reason why declarations aren't permitted before the body
of an FLET?  They ARE permitted before the body of a LET...

		Stever

∂14-Nov-86  0955	AI.BOYER@MCC.COM 	sloop  
Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 14 Nov 86  09:54:39 PST
Date: Fri, 14 Nov 1986  11:52 CST
Message-ID: <AI.BOYER.12254902958.BABYL@MCC.COM>
From: AI.BOYER@MCC.COM
To:   common-lisp@su-ai
Subject: sloop

Bill Schelter has produced a lovely Common Lisp substitute
for the Maclisp/Zetalisp loop construct called sloop.  It is
mostly upwards compatible with loop.  This note describes
where to get it, what's new, etc.   Fahlman observes that
any detailed discussion of the merits of this package
should be directed to the cl-iteration mailing list.

Sloop sources may be found in the file
  <atp.schelter>sloop.lisp
on utexas-20.edu.

The code is free.  It was written by Schelter from scratch
and is hence definitely free of any MIT or lisp machine
company copyright claim.

Like the original I.S.OPR facility in Interlisp, the sloop
construct permits the addition of new "collection" type
operators; for example, an averaging operation is defined.

A very general facility different from that of loop's has
been implemented to provide user extensible iteration paths.
One can map over tree fringes, Common Lisp hash tables, or
packages, e.g.
  (sloop for sym in-package 'user when (fboundp sym) collect sym).

A "cross-product" concept has been added.
Instead of writing something like:
  (loop for x in (l1) nconc (loop for y in (l2) collect (fn x y)))
one may write:
  (sloop for x in (l1) sloop (for y in (l2) collect (fn x y)))
Only one "collection site" is created and used during
these two nested iterations.

Like the original loop, sloop takes advantage of locatives
to do collection more efficiently when they are available,
e.g., on MIT type lisp machines.

Sloop has been run in at least four dialects of Common Lisp
on three different kinds of machines.

I believe Schelter is definitely interested in reports of
bugs and suggestions for improvements.  Mail will reach him
at atp.schelter@utexas-20.edu or at the Mathematics
Department, University of Texas at Austin, Austin, Texas
78712.

∂17-Nov-86  0218	z30083%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET 	type-of    
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 17 Nov 86  02:18:18 PST
Received: from utokyo-relay by csnet-relay.csnet id ab05487; 17 Nov 86 5:12 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
	id AA04493; Mon, 17 Nov 86 18:10:46+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
	id AA16158; Mon, 17 Nov 86 18:06:12+0900
Date: Mon, 17 Nov 86 18:06:12+0900
From: Masayuki Ida <z30083%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Message-Id: <8611170906.AA16158@ccut.u-tokyo.junet>
To: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET
Subject: type-of

Is it absolutely impossible to define TYPE-OF more specific than 
the current CLtL ?
I have been seen many problems derived from the underspecification of TYPE-OF.
As one of the users of PCL since Feb. on several different CommonLisp 
implementation, I felt PCL might get more portability if TYPE-OF can be more defined.

I had sent a mail to several key persons about the possiblity of new definition of TYPE-OF,
but thier answers were pesimistic to do so.
The main reason of them is 
'it is impossible or very hard to determine "the most-specific type"
among lots of CL implementations.'

I know there are many implementation designs and we cannot standardize it.
But, on the langauage specification level not on the hardware level,
we can define "the most specific type" of object according to 2.15 of CLtL.
Or 2.15 of CLtL should be updated to copy with TYPE-OF.

I had wrote a hierarchy chart based on 2.15.
which is attached on the japanese edition of CLtL.

Here is a brief sketch of it.

T>{pathname,stream,hash-table,readtable,package,random-state,
   sequence,symbol,array,character,number}
   
   sequence>{list,vector}
     list>{cons,null}
   symbol>{null}
   array>{vector,simple-array}
     vector>{string,bit-vector}
     simple-array>{simple-string,simple-bit-array,simple-vector}
     string>{simple-string}
     bit-vector>{simple-bit-vector}
   charcter>{string-char}
     string-char>{standard-char}
   number>{rational,float,complex}
     rational>{integer,ratio}
     integer>{fixnum,bignum}
     float>{short-float,single-float,double-float,long-float}

   where 'a>b' means 'a is the direct super of b, or b is just connected
   to a as a direct subtype'

   I tried to define 'terminal types'
   terminal-types={pathname,stream,hash-table,readtable,package,
     random-state,cons,null,simple-string,
     simple-bit-vector,simple-vector,standard-char,fixnum,bignum,
     ratio,short-float,single-float,double-float,long-float,complex}
   terminal-types are types which do not appear on the left of the above '>'.
   (keyword type was not appeared in 2.15, so keyword is not included here.)

   Roughly, I imagine the value of TYPE-OF should be,
     the symbol (not the list) of the most specific type among
     terminal-types or higher types which are listed above or nil.
     (do not permit the lower hardware dependent types)
     'nil' is for undefined object, say unreadable objects.

 I am writing an educational CommonLoops interpreter (the first version was
represented at the conf. of JSSST and IPSJ).
in it, I have a strong desire to get the firm definition of TYPE-OF.

 I also have a suggestion from friends that
     'there is a CLASS-OF in PCL'.
but CLASS-OF also need the detailed definition
on the built-in-classes.
  If CLASS-OF is the right things to discuss,
I have no problem to shift the discussion  to CLASS-OF.


     Masayuki Ida

     PS: there is no Ethernet-like link between US and Japan.
     (though there is a firm link between us)
     So, my response will be not timely. Sorry.

∂17-Nov-86  1503	RAM@C.CS.CMU.EDU 	type-of
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Nov 86  15:03:51 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 17 Nov 86 18:03:28-EST
Date: Mon, 17 Nov 1986  18:03 EST
Message-ID: <RAM.12255745977.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   Masayuki Ida <z30083%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Cc:   common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET
Subject: type-of
In-reply-to: Msg of Mon 17 Nov 86 18:06:12+0900 from Masayuki Ida <z30083%ccut.u-tokyo.junet%utokyo-relay.csnet at RELAY.CS.NET>


I think that your suggestion is contrary to the intent of the
specification.  The "most specific" type can hardly ever be
represented by symbol, since there is almost always a more specific
type that does make use of a list type-specifier.  Although it is
difficult to specify just how specific the type must be, it is clearly
a step in the wrong direction to require it to be a symbol.

It would also be wrong for NIL to be returned to indicate a random
object, since NIL is a meaningful type, but not one that any object
can posess.  It would make more sense to return T or a new type such
as RANDOM.

I also have some doubts about the need to specify what Type-Of
returns.  Could you demonstrate some code that needs to use Type-Of
and is adversely affected by different implementations?  I suppose
that we could rigorously specify some function that does what you
want, but it shouldn't be Type-Of.

  Rob

∂18-Nov-86  0812	@ACORN.CS.ROCHESTER.EDU,@CASHEW.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU 	Package functions not powerful enough?  
Received: from UR-ACORN.ARPA by SAIL.STANFORD.EDU with TCP; 18 Nov 86  08:11:54 PST
Received: from CASHEW.CS.ROCHESTER.EDU (CASHEW.CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 2310; 18 Nov 86 11:12:21 EST
Date: Tue, 18 Nov 86 11:12 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: Package functions not powerful enough?
To: CL@ACORN.CS.ROCHESTER.EDU
cc: miller@ACORN.CS.ROCHESTER.EDU
Message-ID: <861118111222.3.MILLER@CASHEW.CS.ROCHESTER.EDU>
Sender: miller@ACORN.CS.ROCHESTER.EDU
Organization: University of Rochester, Department of Computer Science
Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627
Phone: 716-275-7747

Hi all.

I'm having a problem, which I think revolves around the package funtions not
really being powerful enough to "do the job" correctly. Here is an instance
of the problem, since it is best illustrated by example:

Assume the packages FOO and BAR, where FOO is on BAR's USE list. Assume that
BAR has some symbol interned and marked as external, say 'frotz. The problem
is, that given this package layout is part of some program implementation
(i.e. not meant to be seen by the user) and the program wants to intern 'frotz
as an external symbol in FOO, so any other packages that USE FOO would see
this new definition. The program "knows" about 'frotz in BAR and wants BAR to
shadow it's own definition of 'frotz over FOO's. (in fact, we can even assume
it was interned with SHADOW).

The problem is that there is no way to export the symbol from FOO without
getting an error, because of the possible conflict with the symbol in BAR.
What I would like is some capability to supply an option to EXPORT, like
"export this symbol, and for any package there is a name conflict, make the
local symbol shadow the newly exported one" or vice versa, etc., rather than
makeing the user do it via the debugger. 

The only extremely crufty solution to this problem with the existing tools
seems to be to unintern 'frotz from BAR, intern it in FOO, export it, then
SHADOW it in BAR. Since in a more realistic example the number of packages
'frotz could be in is potentially large, this doesn't seem to be the best of
plans, since each value of 'frotz must also be stored temporarily in the
interim.

To generalize the suggestion, I think that functions which have the
opportunity of creating name conflicts (as defined in section 11.5 CLtL)
should also allow the programmer to tell the system how they should be
resolved in advance. (This is an upwards compatible improvement: the
programmer need not give such "advice" and if none is given, the current
definition obtains.)

Brad Miller

PS: reply to miller@rochester.arpa, not the address in the header, it will
bounce.
------
miller@rochester.arpa
miller@ur-acorn.arpa

∂18-Nov-86  1058	@ACORN.CS.ROCHESTER.EDU,@CASHEW.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU 	[miller@UR-ACORN.ARPA: Package functions not powerful enough?]   
Received: from UR-ACORN.ARPA by SAIL.STANFORD.EDU with TCP; 18 Nov 86  10:57:59 PST
Received: from CASHEW.CS.ROCHESTER.EDU (CASHEW.CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 2316; 18 Nov 86 13:57:59 EST
Date: Tue, 18 Nov 86 13:58 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: [miller@UR-ACORN.ARPA: Package functions not powerful enough?]
To: common-lisp@su-ai.stanford.edu
cc: miller@ACORN.CS.ROCHESTER.EDU
Message-ID: <861118135804.5.MILLER@CASHEW.CS.ROCHESTER.EDU>
Sender: miller@ACORN.CS.ROCHESTER.EDU
Organization: University of Rochester, Department of Computer Science
Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627
Phone: 716-275-7747

Sorry if this is the second time thru - it looked like it bounced the first
time.

%%%%Forwarded Message%%%%
From: Brad Miller <miller@UR-ACORN.ARPA>
Subject: Package functions not powerful enough?
To: common-lisp@su-ai.stanford.edu
Sender: miller@UR-ACORN.ARPA

Hi all.

I'm having a problem, which I think revolves around the package functions not
really being powerful enough to "do the job" correctly. Here is an instance
of the problem, since it is best illustrated by example:

Assume the packages FOO and BAR, where FOO is on BAR's USE list. Assume that
BAR has some symbol interned and marked as external, say 'frotz. The problem
is, that given this package layout is part of some program implementation
(i.e. not meant to be seen by the user) and the program wants to intern 'frotz
as an external symbol in FOO, so any other packages that USE FOO would see
this new definition. The program "knows" about 'frotz in BAR and wants BAR to
shadow it's own definition of 'frotz over FOO's. (in fact, we can even assume
it was interned with SHADOW).

The problem is that there is no way to export the symbol from FOO without
getting an error, because of the possible conflict with the symbol in BAR.
What I would like is some capability to supply an option to EXPORT, like
"export this symbol, and for any package there is a name conflict, make the
local symbol shadow the newly exported one" or vice versa, etc., rather than
makeing the user do it via the debugger. 

The only extremely crufty solution to this problem with the existing tools
seems to be to unintern 'frotz from BAR, intern it in FOO, export it, then
SHADOW it in BAR. Since in a more realistic example the number of packages
'frotz could be in is potentially large, this doesn't seem to be the best of
plans, since each value of 'frotz must also be stored temporarily in the
interim.

To generalize the suggestion, I think that functions which have the
opportunity of creating name conflicts (as defined in section 11.5 CLtL)
should also allow the programmer to tell the system how they should be
resolved in advance. (This is an upwards compatible improvement: the
programmer need not give such "advice" and if none is given, the current
definition obtains.)

Brad Miller

PS: reply to miller@rochester.arpa, not the address in the header, it will
bounce.
------
miller@rochester.arpa
miller@ur-acorn.arpa
%%%%End Forwarded Message%%%%
------
miller@rochester.arpa
miller@ur-acorn.arpa

∂18-Nov-86  1257	wile@vaxa.isi.edu 	Packages: a modest solution.   
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 18 Nov 86  12:57:06 PST
Received: by vaxa.isi.edu (4.12/4.7)
	id AA08142; Tue, 18 Nov 86 12:57:19 pst
Message-Id: <8611182057.AA08142@vaxa.isi.edu>
Date: 18 Nov 1986 1257-PST (Tuesday)
To: COMMON-LISP@SU-AI.ARPA
From: wile@ISI-VAXA
Subject: Packages: a modest solution.



Aha!  I finally figured out the solution to the package problem!

I believe inclusion of packages is the worst mistake in Common LISP's
design.  There isn't a day goes by (when I actually get to program or
debug) when I don't have package problems.  Often, they dominate the
debugging time.  I now type <pkg>::<symbol> all the time, just so I don't
have to think about whether the reader can figure out the right default.  I
truly miss the days when a symbol was a symbol--surely one of the most
elegant features of Lisp 1.0 that's been lost.

But, of course, almost everyone feels this way.  They just don't know how
to get around the problems packages seem to solve.  Actually, I believe
that object-oriented programming generic functions solve about half the
problems packages are meant to solve; but they're not in Common LISP yet.

Everyone also realizes that the "mistake" is in tying package determination
to the reader.  The reader simply has so little context that to determine
where a symbol belongs has to be done very stupidly.  The solution
ultimately has to be a combination of the following:

   * determining the appropriate package becomes trivial, unnecessary or
     meaningless (keywords, generic functions, English commentary, 
     lexically scoped variables and functions(!), or symbols with
     explicitly provided package names);

   * more sophisticated programs determine the package after reading has
     occurred (during a sort of "package expansion" phase); i.e., admit
     that Lisp has a parser.

It is worth noting that the former category constitutes the bulk of the
symbols used in programs, and that getting these symbols in the "wrong"
package is the source of so much frustration and futility.

To move toward this future world, in which package determination becomes
decoupled from the reader, we simply need to make UNINTERNED symbol be the
MOST common symbol to be used.  The reader must be able to be told not to
use default package.  A solution might be to allow the read function to be
passed a package determiner function, as an optional (keyword) argument.
The determiner takes the result from read (uninterned symbols when no
package was explicitly given via : or :: and a symbol was read) and returns
the package expanded expression.  

Notice, I am not assuming that reading a symbol is the only result of read.
In particular, the intelligent determination of packages comes from calling
the package determiner on S-expressions returned by the reader (full of
uninterned symbols and symbols with explicitly specified packages).  I'm
not claiming that it will be easy to write such functions (if it were,
having the reader itself determine the package might be easy); I'm simply
claiming that it's worth it!

This must be defined carefully.  At first blush, it may seem that the
reader should not invoke the package expander in a bottom up fashion.  Only
the top level expression should be given to the expander.  Then the
expander could be allowed to smash structure.  This assumes no read macros
return previously defined structure (an invalid assumption, generally).
Alternatively, perhaps the expander should be called on every
sub-expression,  with an extra argument indicating whether the top level
expression is being passed.  Clearly, the reader should be able to assume
that if an uninterned symbol is determined to mean an interned symbol that
the uninterned symbol can be deleted if it just created it...

Present implementations of uninterned symbols cannot support this
determiner idea well.  To support this, uninterned symbols should print out
very normally, perhaps in lower case without bars, instead of #:....  These
symbols should be full-fledged symbols with values and function cells.
Obviously, I am proposing that they not be syntactically distinguishable
from interned symbols.  Should (MAKE-SYMBOL "a") be EQ to itself (it isn't
on Symbolics implementations).  Is there any other way to create the
uninterned symbol with that name?

Comments?

				Dave Wile

P.S.  I am looking for conventions that make packages easier to live with.
      Since I have converted code from an existing Interlisp implementation
      in which all my global symbols were prefixed, I found using explicit
      package prefixes on all exported symbols (for emphasis) whereever
      they occur to be convenient.  Naturally, I hid all the others and
      dropped the prefix.  Any other folklore on this?

∂18-Nov-86  1304	RWK@YUKON.SCRC.Symbolics.COM 	type-of   
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 18 Nov 86  13:04:32 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 121418; Tue 18-Nov-86 16:02:39 EST
Date: Tue, 18 Nov 86 16:04 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: type-of
To: Masayuki Ida <z30083%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
cc: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET
In-Reply-To: <8611170906.AA16158@ccut.u-tokyo.junet>
Message-ID: <861118160431.3.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

I'm considering writing a paper on the type system and the role of
SUBTYPEP.  (I've been working on an extension of the type system for the
last year or so).  Your question really relates to one of the core
issues of this topic.

I can think of a lot of analogies for TYPE-OF and SUBTYPEP,
and maybe I'll develop one of them for the paper, but they
all boil down to SELECTION of an object, and matching the
object with something which ACCEPTS objects.  The exact
token which passes between the object and the acceptor of
objects doesn't matter, so long as the information is there!
Viewed in the abstract, it should be clear that the more
information this token has, the more flexibility the acceptor
has in deciding whether this object is suitable.

The tokens, of course, are the type specifiers.  The
acceptor can be TYPE-CASE, CHECK-TYPE, or any function
which handles only a certain range of types.  And SUBTYPEP/TYPEP
is what answers the question "is this object suitable."
Given this model, there is no such thing as "too specific"
an answer from TYPE-OF.  On the contrary, the concern should
be with "not specific enough".

To address your specific points:

    Date: Mon, 17 Nov 86 18:06:12+0900
    From: Masayuki Ida <z30083%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>

    Is it absolutely impossible to define TYPE-OF more specific than 
    the current CLtL ?
    I have been seen many problems derived from the underspecification of TYPE-OF.
    As one of the users of PCL since Feb. on several different CommonLisp 
    implementation, I felt PCL might get more portability if TYPE-OF can be more defined.
TYPE-OF's >>lack<< of restriction is essential for
portability.  It is SUBTYPEP which needs to be more
carefully defined.

    I had sent a mail to several key persons about the possiblity of new definition of TYPE-OF,
    but thier answers were pesimistic to do so.
    The main reason of them is 
    'it is impossible or very hard to determine "the most-specific type"
    among lots of CL implementations.'
It is wrong and impossible to define "the most-specific type".
What you want to specify is the "least-specific type".  I.e.
we should specify that it must return a type *at least as specific as* X.
X is then the LEAST-SPECIFIC type which TYPE-OF may return; it may,
however, return something a good deal more specific.  And it should,
if at all possible.

For example, TYPE-OF of a number must return one of INTEGER, COMPLEX, FLOAT,
RATIO, or one of their subtypes (if any), or some other subtype of NUMBER.
However, it is not good enough for it to return NUMBER.

However, it does not make sense to specify that TYPE-OF return one
of FIXNUM or BIGNUM, rather than INTEGER; a system which implemented
all numbers as "BIGNA" would be correct, if inefficient.

And a system might reasonably have two kinds of BIGNUM's, NEGATIVE-BIGNUM and
POSITIVE-BIGNUM.  If you specify that TYPE-OF return just BIGNUM,
you prevent any program from distinguishing between them, when it
may be the program's advantage to make the distinction.

By over-specifying TYPE-OF, you can eliminate any implementation
flexibility or extensibility.

Along with this flexibility in what TYPE-OF returns goes a requirement
that SUBTYPEP know the answer when comparing the result of TYPE-OF and
whatever "least-specific type" that is specified.  For example, if
TYPE-OF returns POWER-OF-TWO-POSITIVE-BIGNUM, SUBTYPEP must return
the values T T when asked if this is a subtype of BIGNUM, of INTEGER,
and of NUMBER.

SUBTYPEP is the only predicate provided for comparing types;
it goes without saying that any code that uses something else
like EQUAL will not be portable.  Any type you get back from
TYPE-OF you must interpret with SUBTYPEP.

Here is an example of completely-portable code which depends on
TYPE-OF returning the MOST specific type.

(defun store-in-array-if-fits (object array &rest indicies)
  (let ((object-type (type-of object))
        (array-type (array-element-type array)))
    (if (subtypep object-type array-type)
	;; If the object fits, store it
	(setf (apply #'aref array indicies) object)
      ;; Doesn't fit, so store 0 instead.
      (setf (apply #'aref array indicies) 0))))

SUBTYPEP does explicitly the comparison that TYPEP does
implicitly when given an object and a type.  For example,
when you write (TYPEP FOO 'BIGNUM) you don't have to worry
about whether the BIGNUM type is split into POWER-OF-TWO-BIGNUM
and NON-POWER-OF-TWO-BIGNUM's.  Yet, a programmer writing
lower-level code can use the same primitive to distinguish
the two cases.  For example:

(defun count-bits (integer)
  (type-case integer
     (fixnum (count-fixnum-bits integer))
     ;; Easy BIGNUM case
     (positive-power-of-two-bignum 1)
     ;; All other BIGNUM's
     (bignum (count-general-bignum-bits integer))))

This is the reason for the "most-specific" requirement in 2.15.

If I implement the type (ARRAY POSITIVE-POWER-OF-TWO-BIGNUM)
efficiently (by just storing the exponent), my first example continues
to work, so long as TYPE-OF returns the most-specific type.
If it instead just returned BIGNUM, as you propose, there
would be no way to write code which would decide whether this
particluar type of number will fit in this particular type
of array.

    I know there are many implementation designs and we cannot standardize it.
    But, on the langauage specification level not on the hardware level,
    we can define "the most specific type" of object according to 2.15 of CLtL.
    Or 2.15 of CLtL should be updated to copy with TYPE-OF.

    I had wrote a hierarchy chart based on 2.15.
    which is attached on the japanese edition of CLtL.

    Here is a brief sketch of it.
The english version of CLtL would be clearer if it
included something like this.

    T>{pathname,stream,hash-table,readtable,package,random-state,
       sequence,symbol,array,character,number}
   
       sequence>{list,vector}
	 list>{cons,null}
       symbol>{null}
       array>{vector,simple-array}
	 vector>{string,bit-vector}
	 simple-array>{simple-string,simple-bit-array,simple-vector}
	 string>{simple-string}
	 bit-vector>{simple-bit-vector}
       charcter>{string-char}
	 string-char>{standard-char}
       number>{rational,float,complex}
	 rational>{integer,ratio}
	 integer>{fixnum,bignum}
	 float>{short-float,single-float,double-float,long-float}

       where 'a>b' means 'a is the direct super of b, or b is just connected
       to a as a direct subtype'

       I tried to define 'terminal types'
       terminal-types={pathname,stream,hash-table,readtable,package,
	 random-state,cons,null,simple-string,
	 simple-bit-vector,simple-vector,standard-char,fixnum,bignum,
	 ratio,short-float,single-float,double-float,long-float,complex}
       terminal-types are types which do not appear on the left of the above '>'.
       (keyword type was not appeared in 2.15, so keyword is not included here.)

       Roughly, I imagine the value of TYPE-OF should be,
	 the symbol (not the list) of the most specific type among
	 terminal-types or higher types which are listed above or nil.
	 (do not permit the lower hardware dependent types)
** REQUIRE ** the lower hardware dependent types.

	 'nil' is for undefined object, say unreadable objects.

No, not NIL.  T would be a better choice here than NIL!

First, there are several kinds of unreadable objects
which already have types, such as COMPILED-FUNCTION.
Second, NIL is defined to be the *empty* type, that is *no*
objects are of type NIL.  There is nothing wrong with having
an UNDEFINED type, however.  NIL will be a subtype of
UNDEFINED, of course, and UNDEFINED will be a subtype of T.

     I am writing an educational CommonLoops interpreter (the first version was
    represented at the conf. of JSSST and IPSJ).
    in it, I have a strong desire to get the firm definition of TYPE-OF.
More important is a firm definition of SUBTYPEP!
SUBTYPEP is the key to using the result of TYPE-OF.

     I also have a suggestion from friends that
	 'there is a CLASS-OF in PCL'.
    but CLASS-OF also need the detailed definition
    on the built-in-classes.
      If CLASS-OF is the right things to discuss,
    I have no problem to shift the discussion  to CLASS-OF.
CLASS-OF is not the issue here.

	 Masayuki Ida

	 PS: there is no Ethernet-like link between US and Japan.
	 (though there is a firm link between us)
	 So, my response will be not timely. Sorry.


∂18-Nov-86  1454	shebs%utah-orion@utah-cs.arpa 	Packages 
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 18 Nov 86  14:53:59 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
	id AA21982; Tue, 18 Nov 86 15:55:05 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
	id AA11049; Tue, 18 Nov 86 15:49:29 MST
Date: Tue, 18 Nov 86 15:49:29 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs)
Message-Id: <8611182249.AA11049@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Packages

I haven't found packages to be as much of a headache as some people on
this list.  They were both a pain and a necessity for PCLS, because the
code is sort of half PSL and half CL, and many symbols of the same name
exist in both packages (the psl: and lisp: packages don't use each other).
User-type code (at least around here) tends to use packages sparingly -
a program doesn't get its own package until it has a fat user manual and
a community of users :-).  As a consequence, adding the package operations
occurs late in development, after the program has stabilized somewhat.
Since there are no explicit package references in the source, there is a
strong inducement to avoid adding explicit internal symbol references
all over the place.

The package fixes that have been proposed seem to me like bandaids, and not
worth the effort.  A *real* solution would promote environments to full
first-class objects, and provide some good protocols for operating on
them.  Look to T for a first attempt, and to Eulisp for more concentrated
efforts to get it right.  Somehow, I don't see it ever getting into the
present form of CL.  (Strange how CL is starting to look a little dated
here and there...)

								stan

∂18-Nov-86  1539	masinter.pa@Xerox.COM 	Re: type-of 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Nov 86  15:39:25 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 18 NOV 86 15:24:08 PST
Date: 18 Nov 86 15:24 PST
From: masinter.pa@Xerox.COM
Subject: Re: type-of
In-reply-to: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>'s message of
 Tue, 18 Nov 86 16:04 EST
To: RWK@YUKON.SCRC.Symbolics.COM
cc: common-lisp@SU-AI.ARPA
Message-ID: <861118-152408-2377@Xerox>

Here's a proposed level of specificity for type-of and subtypep which
would be an improvement:

Let Z be  the set of "well-behaved" type specifiers. (To be listed).
Then, for all Z:

For all  data X:

if (typep x Z) => (subtypep (type-of x) z)

This says that type-of has to return something specific enough that
subtypep can deal with it.

My candidate set of "well-behaved" subtypes are exactly those that are
required to be distinct in Common Lisp:

array, number, integer, complex, float, symbol, ratio, rational... 


This (a) isn't hard (b) is probably implemented by most common lisps
anyway. 

The exact set of types identified as "well-behaved" is debatable, but I
think it is wise to leave out any implementation dependent types,
(long-float vs short-float, fixnum vs bignum), all of the non-intrinsic
types (satisfies), or require the relation to be true of any types that
are hard to calculate (things like nested ands and ors).

There may be a more specific stringent specification of type-of and
subtypep that people want to adopt, but its hard to imagine something
*less* specific than this, yet this seems adequate for most of the
purposes I know of. 

∂18-Nov-86  1854	Miller.pa@Xerox.COM 	Re: Packages: a modest solution.  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Nov 86  18:51:52 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 18 NOV 86 18:07:06 PST
Date: 18 Nov 86 18:08 PST
Sender: Miller.pa@Xerox.COM
Subject: Re: Packages: a modest solution.
In-reply-to: wile@VAXA.ISI.EDU's message of 18 Nov 86 12:57 PST
 (Tuesday)
To: wile@VAXA.ISI.EDU
cc: COMMON-LISP@SU-AI.ARPA
From: Mark S. Miller <Miller.pa@Xerox.COM>
Message-ID: <861118-180706-2579@Xerox>

Take a look at the T language.  It has reified lexical environments.
Such reified environments (called LOCALEs) seem able to do all that's
valuable with packages, and are based on a clean scoping semantics.
Modularity can be understood in terms of the abstract language and not
its reader.

I believe that if LOCALEs were added to CommonLisp, then (after new
programmers grew up with it) packages would only be used for old code.
This change can probably be made in an upwards compatible fashion.


----- MarkM

∂18-Nov-86  1906	RAM@C.CS.CMU.EDU 	Package functions not powerful enough?    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Nov 86  19:06:27 PST
Received: ID <RAM@C.CS.CMU.EDU>; Tue 18 Nov 86 22:05:54-EST
Date: Tue, 18 Nov 1986  22:05 EST
Message-ID: <RAM.12256052258.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   miller@ROCHESTER.ARPA
cc:   common-lisp@SU-AI.ARPA
Subject: Package functions not powerful enough?


    Your message is pretty unclear, but I think that there are
adequate tools for explicitly resolving potential name conflicts.  In
the CMU Common Lisp package code, all conflict resolution is done with
standard package functions, so it is clearly doable.  Of course, as
you make arbitrarily complex changes to the namespace, the code to do
so becomes arbitrarily complex.

Although I am fairly sure that there is a simpler solution than the
one proposed, the cruftiness is a natural reflection of the mismatch
between what you want the package system to do and what it was meant
to do.  

The big problems that I see users having with the package system are
due to their inaccurate models of the real semantics of the package
system.  This is encouraged by the current language in CLTL.  One of
the biggest misconceptions is that a symbol "belongs" to its home
package.  In fact, the home package has no semantics other than
printing.  A more fundamental problem is that the package system
manipulates names, whereas users (quite reasonably) thing in terms of
managing named objects.

  Rob

∂18-Nov-86  1909	FAHLMAN@C.CS.CMU.EDU 	TYPE-OF 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Nov 86  19:09:35 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 18 Nov 86 22:09:06-EST
Date: Tue, 18 Nov 1986  22:09 EST
Message-ID: <FAHLMAN.12256052839.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: TYPE-OF


Before we start debating proposals to improve TYPE-OF, we should
probably try to figure out what we really want to accomplish.  Then we
will have some goals against which to measure the various proposals.

Given that the Common Lisp type system is a lattice and not a simple
tree, TYPE-OF (originally known as "one-argument TYPEP") was considered
to be of very dubious value, and was almost dropped.  It was kept in the
language for only one purpose: to provide users with a quick and dirty
way to examine various objects interactively to see what they are.  For
this purpose, the current definition is exactly right: each
implementation should provide as detailed a description as it can manage
conveniently.  This is non-portable, but given the purpose of this
function, portability is less valuable than getting as much information
to the user as possible.

CLTL (page 52-53) basically says that TYPE-OF is not meant to be used in
code, except in a few odd situations that are adequately handled by the
current definition.

I sounds to me like Ida and Masinter have in mind some use of TYPE-OF
within programs, and that such use is not adequately covered by TYPEP
and TYPE-CASE.  It seems to me that the best way to make progress is to
first spell out this problem or problems, then decide whether TYPE-OF is
the right way to solve the problem (as opposed to inventing some new
form), and finally to think about how to change the definition of
TYPE-OF.  If these problems arise in the context of CommonLoops, then
maybe CLASS-OF is the right form to use.

-- Scott

∂19-Nov-86  0749	shebs%utah-orion@utah-cs.arpa 	Re: type-of   
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 19 Nov 86  07:49:39 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
	id AA00592; Wed, 19 Nov 86 08:50:46 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
	id AA14443; Wed, 19 Nov 86 08:19:15 MST
Date: Wed, 19 Nov 86 08:19:15 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs)
Message-Id: <8611191519.AA14443@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Re: type-of

If type-of is meant for interactive use, perhaps it should be moved to
the miscellaneous chapter.  Also, make it a macro that doesn't evaluate
its argument :-) :-).

							stan

∂19-Nov-86  0817	sandra%utah-orion@utah-cs.arpa 	type-of 
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 19 Nov 86  08:17:05 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
	id AA01245; Wed, 19 Nov 86 09:18:12 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
	id AA14790; Wed, 19 Nov 86 09:11:01 MST
Date: Wed, 19 Nov 86 09:11:01 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Message-Id: <8611191611.AA14790@utah-orion.ARPA>
Subject: type-of
To: common-lisp@su-ai.arpa

    From: RWK@YUKON.SCRC.Symbolics.COM (Robert W. Kerns)
    Date: 18 Nov 86 21:04:00 GMT

    Here is an example of completely-portable code which depends on
    TYPE-OF returning the MOST specific type.

    (defun store-in-array-if-fits (object array &rest indicies)
      (let ((object-type (type-of object))
            (array-type (array-element-type array)))
        (if (subtypep object-type array-type)
   	  ;; If the object fits, store it
	    (setf (apply #'aref array indicies) object)
          ;; Doesn't fit, so store 0 instead.
            (setf (apply #'aref array indicies) 0))))

Sorry, I can't buy this motivation.  All this example illustrates is that
there is a good reason for having the TYPEP function around.

As it happens, in PCLS, TYPE-OF does go through a considerable amount of 
work to find the most specific type that it can.  So, (TYPE-OF 0) returns 
BIT, which is correct but largely useless.  My "gut feeling" is that what
the user probably wants is either FIXNUM or INTEGER --  something which 
indicates how the object is represented internally, or (in other words) 
one of the set of types which CLtL says are disjoint.

I'll have to agree that TYPE-OF as defined now is pretty bogus.  The only 
place I've ever had reason to use TYPE-OF in real code was to get a type
to pass to COERCE or CONCATENATE, etc., when I wanted to ensure that two
objects were of the same type; for example, both lists or whatever.  But 
this is full of holes, too.  For example, 

    (coerce '#(a b c) (type-of (list)))

may fail, depending on whether your favorite implementation thinks NIL is
of type NULL, LIST, or SYMBOL.  I ended up writing a specialized function
to do what I wanted, without relying on TYPE-OF.

In short, I am not convinced that TYPE-OF would be particularly useful even
if its definition were firmed up more.  If nobody has any good use for this
function, arguing over how it should behave is rather pointless.

-Sandra
-------

∂19-Nov-86  1132	DLW@ALDERAAN.SCRC.Symbolics.COM 	Packages    
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 19 Nov 86  11:30:27 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 22063; Wed 19-Nov-86 14:26:48 EST
Date: Wed, 19 Nov 86 14:28 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Packages
To: shebs%utah-orion@UTAH-CS.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <8611182249.AA11049@utah-orion.ARPA>
Message-ID: <861119142829.4.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Tue, 18 Nov 86 15:49:29 MST
    From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs)

			      Somehow, I don't see it ever getting into the
    present form of CL.  (Strange how CL is starting to look a little dated
    here and there...)

Certainly.  CL is an attempt to unify and codify a set of dialects that existed
and were well-tested and understood as of a few years ago.  The idea was to do
basic cleanups, resolve differences between similar dialects into one large
Common subset, and codify it and make it stable.  That's what Common Lisp is all
about.

There are lots of exciting new ideas in Lisp that are being worked on, including
locales and a lot of other things.  To take every good new idea as it comes
along, and "add it to" Common Lisp, will destroy the stabilty of the language and
the confidence of the users outside the inner circle of Lisp innovators.  These
new ideas are great things, but the reaction to them should not be to "add them
to the standard".  A standard is useless if it isn't extremely stable.  Common
Lisp's purpose in life is to be a standard, and so stability is of paramount
importance.  Experimentation and new ideas in Lisp should continue, I hope in
great quantity and strength, and there should always be new dialects.  But it's
not necessary to first "add it to Common Lisp".

∂19-Nov-86  2254	@MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU 	Packages: a modest solution.    
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 19 Nov 86  22:54:25 PST
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 17359; 20 Nov 86 01:43:49-EST
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 44908; Wed 19-Nov-86 22:33:42-EST
Date: Wed, 19 Nov 86 23:09 est
Sender: mike@acorn
To: wile@ISI-VAXA
from: mike%acorn@mit-live-oak.arpa
Subject: Packages: a modest solution.
Cc: COMMON-LISP@SU-AI.ARPA

    Date: 18 Nov 1986 1257-PST (Tuesday)
    From: wile@ISI-VAXA
    
    Aha!  I finally figured out the solution to the package problem!
    
    I believe inclusion of packages is the worst mistake in Common LISP's
    design.  There isn't a day goes by (when I actually get to program or
    debug) when I don't have package problems.  Often, they dominate the
    debugging time.  I now type <pkg>::<symbol> all the time, just so I don't
    have to think about whether the reader can figure out the right default.

This seems like a problem to me, since you have no control over internal
and external names anymore. I have a similarly explicit approach, but
it preserves the internal/external symbol distinction:

The biggest problem with packages is lack of education about how to
avoid most of their pitfalls. I have found that if you avoid
use-package or the options for :use to in-package and relatives,
and you explicitly export and inport names, then package problems go
away. The only packages which should be used are those which define
the lisp language, i.e., lisp, but not SYS. This avoids most snafu's.

The rule of thumb is "don't use a package unless you personally know
every single exported symbol of that package and know that it doesn't
conflict with any name you are using." This means basically that you
should never use-package anything except package lisp.  (even this
causes problems, since lisp is such a big language that people
frequently begin accidently redefining primitives like check-type,
assert, etc. in embedded language systems.....)

For example, we had a major problem with the function
sys:lambda-list, which is supposed to take a symbol and print the
lambda-list, and a bunch of code which uses an internal symbol
"lambda-list" just as a local lexical var.  If you load the files in
the wrong order, you get a package problem.  This is only since
package lisp uses package sys, an unfortunate situation that can't be
rectified easily. The solution was to make a moby export file which
is read before almost anything, but this is really a kludge.  The
problem is really that lisp code has no business using the symbol
"lambda-list" internally anywhere without recognizing the existance
of that name as an internal part of the sys package.

If you explicitly export and import the right symbols manually, then
the code to do this automatically interns all the right things in the
right places, i.e., in order to say that you are importing certain
symbols you must introduce them to the reader properly qualified with
a package prefix. Hence you won't die having to unintern some symbol
which was read into the wrong place before the export/import happened.

I'm in favor of leaving the package system as it is, but I think the
manual (or a later spec) should contain alot of warnings about the
kinds of problems that use-package causes. The naive user almost
always thinks the easiest thing to do is have all his packages use
each-other. And if he does experience package problems, then the
naive view again is that making everything use everything solves
these problems. There is no "DWIM-with-all-the-symbols"; the control
of names in large systems requires a methodical, explicit approach.


...mike beckerle
Gold Hill Computers







∂19-Nov-86  2355	a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET 	TYPE-OF    
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 19 Nov 86  23:55:05 PST
Received: from utokyo-relay by csnet-relay.csnet id aa09456; 19 Nov 86 10:53 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
	id AA23688; Wed, 19 Nov 86 23:51:37+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
	id AA16856; Wed, 19 Nov 86 23:41:56+0900
Date: Wed, 19 Nov 86 23:41:56+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Message-Id: <8611191441.AA16856@ccut.u-tokyo.junet>
To: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET
Subject: TYPE-OF

This mail is the reply to RAM's mail and RWK's mail.
(And I just read Fahlman's mail and Masinter' mail on posting this.
this mail is not directly related to my committee work for the standardization)

My trigger to think of TYPE-OF (and SUBTYPEP) is the definition of
the Common Lisp interpreter including CommonLoops.
I've been thinking of it since last November before PCL was there.
(And presented a paper on Dec. 1985 in Japan)
I named it Discriminating Eval (D-Eval).
D-Eval is an executable model of Common Lisp scheme.
D-Eval always keeps track of the type of a object.

With this D-Eval, Common Lisp can, I think, bridge the object oriented world and
lisp, and formal systems.
I feel several researchers are independently working in near here.
(If someone is interested in D-Eval I will send a version of it to anyone)

Here is a conversation with D-Eval:

D-Eval>(+ 1 2)
3
; FIXNUM
D-Eval>(cdr '(a))
()
; NULL
D-Eval>(ndefmeth foo ((x integer)) (+ x 1))
FOO
; SYMBOL
D-Eval>(foo 1)
2
; FIXNUM
...


Then, I will try to discuss.
>Date: Mon, 17 Nov 1986  18:03 EST
>From: Rob MacLachlan <RAM%C.CS.CMU.EDU@u-tokyo.junet>
>Received: from CSNet-Relay by utokyo-relay; 19 Nov 86 12:58:34-JST (Wed)
>
> ...
>It would also be wrong for NIL to be returned to indicate a random
>object, since NIL is a meaningful type, but not one that any object
>can posess.  It would make more sense to return T or a new type such
>as RANDOM.
I understood. I confess that I did not make a deep consideration on random object prior to posting my mail.
I am wrong.
They should not goto NIL.
Thank you.

>I also have some doubts about the need to specify what Type-Of
>returns.  Could you demonstrate some code that needs to use Type-Of
>and is adversely affected by different implementations?  I suppose
>that we could rigorously specify some function that does what you
>want, but it shouldn't be Type-Of.
D-Eval concept needs TYPE-OF.
kinds of type inferencing system will also need TYPE-OF to determine the type.
>
>  Rob
>
----------

>Date: Tue, 18 Nov 86 16:04 EST
>From: Robert W. Kerns <RWK%YUKON.SCRC.Symbolics.COM@u-tokyo.junet>
>In-Reply-To: <8611170906.AA16158@ccut.u-tokyo.junet>
>Received: from CSNet-Relay by utokyo-relay; 19 Nov 86 15:19:54-JST (Wed)
>
> ... Your question really relates to one of the core
>issues of this topic.
I think so if my image of SUBTYPEP is same as yours.

>
>        ...    And SUBTYPEP/TYPEP
>is what answers the question "is this object suitable."
>Given this model, there is no such thing as "too specific"
>an answer from TYPE-OF.  On the contrary, the concern should
>be with "not specific enough".
>
>To address your specific points:
>
>    Date: Mon, 17 Nov 86 18:06:12+0900
>    From: Masayuki Ida <z30083%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
>
>    ...
>
>For example, TYPE-OF of a number must return one of INTEGER, COMPLEX, FLOAT,
>RATIO, or one of their subtypes (if any), or some other subtype of NUMBER.
TYPE-OF of a number must return one of the FIXNUM, BIGNUM, RATIO, SHORT-FLOAT,
SINGLE-FLOAT, DOUBLE-FLOAT, LONG-FLOAT, COMPLEX. If TYPE-OF can not return
one of the above, it must return the type which is closer to the above terminal type.
>
>However, it does not make sense to specify that TYPE-OF return one
>of FIXNUM or BIGNUM, rather than INTEGER; a system which implemented
>all numbers as "BIGNA" would be correct, if inefficient.
>
>And a system might reasonably have two kinds of BIGNUM's, NEGATIVE-BIGNUM and
>POSITIVE-BIGNUM.  If you specify that TYPE-OF return just BIGNUM,
>you prevent any program from distinguishing between them, when it
>may be the program's advantage to make the distinction.
 NEGATIVE-BIGNUM and POSITIVE-BIGNUM are not defined in Common Lisp,
 though they are possible to exist.
>
>By over-specifying TYPE-OF, you can eliminate any implementation
>flexibility or extensibility.
TYPE-OF story and implementation flexibility are quite different.
I think the definition of TYPE-OF is needed to keep Common Lisp as well-defined.
It is the issue of formality.
What I said is TYPE-OF should return the name of the symbol which is defined in the language specification.
And,
the value (type) should be at the bottom of hierarchy chart whenever it is possible.
For example,
(type-of ()) should not be SYMBOL as in some CL implementations, but NULL.

>

> ...
>TYPE-OF returns POWER-OF-TWO-POSITIVE-BIGNUM, SUBTYPEP must return
		 ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
		 this symbol is not in my dictionary.
	 Again, I think TYPE-OF should not return implementation dependent things.
>the values T T when asked if this is a subtype of BIGNUM, of INTEGER,
>and of NUMBER.
>
>SUBTYPEP is the only predicate provided for comparing types;
>it goes without saying that any code that uses something else
>like EQUAL will not be portable.  Any type you get back from
>TYPE-OF you must interpret with SUBTYPEP.
>
>    I had wrote a hierarchy chart based on 2.15.
>    which is attached on the japanese edition of CLtL.
>
>    Here is a brief sketch of it.
>The english version of CLtL would be clearer if it
>included something like this.
I think so. ( I already sent it to GLS)
>
>    T>{pathname,stream,hash-table,readtable,package,random-state,
>
>	 'nil' is for undefined object, say unreadable objects.
>No, not NIL.  T would be a better choice here than NIL!
Thank you. As I answered to RAM's message, I am wrong.
>
> .... There is nothing wrong with having
>an UNDEFINED type, however.     ...  
Will you push to make UNDEFINED type ?
I think its interesting.


I want to add one more thing.
(type-of "string") must return SIMPLE-STRING. SIMPLE-STRING is a subtype of
STRING and SIMPLE-ARRAY simultaneously.

If this call returns STRING, SIMPLE-ARRAY related things can not handle
the things caused by (type-of "string").

Masayuki Ida



∂20-Nov-86  0703	RAM@C.CS.CMU.EDU 	type-of
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Nov 86  07:03:32 PST
Received: ID <RAM@C.CS.CMU.EDU>; Thu 20 Nov 86 09:34:07-EST
Date: Wed, 19 Nov 1986  23:32 EST
Message-ID: <RAM.12256330165.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   "Robert W. Kerns" <RWK@SCRC-YUKON.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: type-of
In-reply-to: Msg of 18 Nov 1986  16:04-EST from Robert W. Kerns <RWK at YUKON.SCRC.Symbolics.COM>


    I have also done some thinking about types in connection with my
project of writing a Common Lisp compiler that takes types seriously.
I tend to agree Sandra that your example demonstrates a problem in the
type system rather than a solution.  Unless you have a better example,
what you are really demonstrating is the horrible lossage in the
definition of specialized array types.

    I agree that it might be useful to be able to determine if an
object can be stored in an array, but I suggest that the problem be
solved by adding an Array-Can-Hold-P predicate.  The problem is that
in principle, there is no reason why the "type" of object that can be
stored in a specialized array must be representable with a Common Lisp
type specifier.  I guess that with your
ARRAY-POSITIVE-POWER-OF-TWO-BIGNUM example, you were suggesting that
it is always possible to do the back-mapping without losing
information, but I don't think that it is a good idea to require this.

    Much of the confusion revolves around the lack of distinction
between types and objects.  When the implementation decides to
create an instance of a type, it chooses a representation.  This
mapping between types and representations is neither injective nor
surjective.  The implementation may decide to discard information, as
in (ARRAY SYMBOL) ==> (ARRAY T).  It may also decide to add
information, as in INTEGER ==> FIXNUM.

    Many functions in the language use the to-implementation mapping;
I believe that only Type-Of and Array-Element-Type attempt to perform
the from-implementation mapping.  If these functions are ignored, then
implementation's freedom to choose representations is totally
invisible, and is restricted only by the requirements that certain
types "are disjoint".

    I think that any attempt to use Type-Of or Array-Element-Type in
code is highly suspect.  The only such use that I know of is to find the
type of an object which is known to be a structure; this is presumably
what Class-Of does.  Note that in this case, Type-Of is actually doing
something totally different from what it normally does: it is making
no attempt to return the "most specific type"; instead it is making a
well-defined from-implementation mapping based on an explicitly
defined type hierarchy.  If we treated objects other than structures
the same way, then we could make a similar back-mapping for them.
This capability seems to be what Ida seems to be interested in, but it
isn't what Type-Of does.

  Rob

∂20-Nov-86  0747	cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	fboundp question    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 Nov 86  07:47:47 PST
Received: from JONES.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 20 Nov 86 06:12-EST
Date: Thu, 20 Nov 86 06:12 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: fboundp question
To: common-lisp@SU-AI.ARPA
Message-ID: <861120061242.7.CFRY@JONES.AI.MIT.EDU>

(fboundp 'cond) =>  ?

(fboundp 'go)   =>  ? 

I am not happy with the spec on symbol-function.

∂20-Nov-86  1020	DLW@ALDERAAN.SCRC.Symbolics.COM 	side comment
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 20 Nov 86  10:20:40 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 22688; Thu 20-Nov-86 13:19:12 EST
Date: Thu, 20 Nov 86 13:20 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: side comment
To: common-lisp@SU-AI.ARPA
Message-ID: <861120132014.2.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Wed, 19 Nov 1986  23:32 EST
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>

					 Unless you have a better example,
    what you are really demonstrating is the horrible lossage in the
    definition of specialized array types.

Side comment: This is what happens when experienced, well-intentioned
Lisp experts decide to put an untested new idea into a language
standard.  In many, perhaps most, cases where we put in new ideas that
had not been tested in "production" circumstances, we got nasty
surprises much later.  This is a fine thing to happen in a growing Lisp
implementation, but not a fine thing to happen in a stable Lisp
standard.

∂20-Nov-86  1032	spe@cad.cs.cmu.edu 	EVAL 
Received: from CAD.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Nov 86  10:32:21 PST
Date: 20 Nov 1986 13:28-EST 
From: Sean.Engelson@cad.cs.cmu.edu
To: common-lisp@SU-AI.ARPA
Subject: EVAL
Message-Id: <532895293/spe@cad.cs.cmu.edu>

Why is it that EVAL returns the value in the current DYNAMIC
environment, rather than the lexical environment?  Or perhaps the most
recent binding (lexical unless a variable is special)?  Or if this is
necessary for some reason, why isn't there another function, say,
LEXICAL-EVAL that does this?  It seems rather strange to have a mainly
lexically scoped language with no facility for lexical evaluation.

∂20-Nov-86  1150	DLW@VALLECITO.SCRC.Symbolics.COM 	TYPE-OF    
Received: from SCRC-VALLECITO.ARPA by SAIL.STANFORD.EDU with TCP; 20 Nov 86  11:50:45 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 71990; Thu 20-Nov-86 14:49:44 EST
Date: Thu, 20 Nov 86 13:34 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: TYPE-OF
To: a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET,
    common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET
In-Reply-To: <8611191441.AA16856@ccut.u-tokyo.junet>
Message-ID: <861120133433.3.DLW@CHICOPEE.SCRC.Symbolics.COM>

OK, I think it's clear that you don't really want TYPE-OF to return "the
most specific type".  Rather, you want it to be the case that TYPE-OF is
well-defined for all objects in Common Lisp, and that the definition,
which will be written out clearly somewhere, will tend to specify that
more-specific rather than less-specific types be returned.  If some
implementation has its own even-more-specific type, TYPE-OF will not
return it.

Even so, I'm not sure I understand why you need TYPE-OF.  As far as I
can tell, almost the only useful thing to do with a type is to see
whether some object is of that type, and that's what TYPEP is for.

In your D-Eval example, evaluating (foo 1) returned 2 and printed out ";
FIXNUM".  If you had said (foo 0), it would have returned 1, but would
it have printed out "; BIT"?  Apparently not, because that's not in your
list of number types.  On the other hand, why doesn't 2 print out ";
INTEGER"?  That is, why does your list exclude BIT but include FIXNUM
and BIGNUM?  Whether an integer is a FIXNUM or not depends on the
implementation, and usually it's better to hide it than draw attention
to it.  Same question for the different floating point formats.  In
order to make TYPE-OF fully-defined, some kinds of decisions have to be
made, and some of them seem rather arbitrary (in the sense that it's not
really clear which decision is best).

∂20-Nov-86  1217	gls@think.com 	TYPE-OF   
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 20 Nov 86  12:17:09 PST
Received: from hilarion by Godot.Think.COM via CHAOS; Thu, 20 Nov 86 15:23:53 EST
Date: Thu, 20 Nov 86 15:16 EST
From: Guy Steele <gls@think.com>
Subject: TYPE-OF
To: DLW@alderaan.scrc.symbolics.com,
        a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@relay.cs.net,
        common-lisp@su-ai.arpa, ida%u-tokyo.junet@relay.cs.net
Cc: gls@aquinas.think.com
In-Reply-To: <861120133433.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <861120151614.4.GLS@HILARION.THINK.COM>

One might want (TYPE-OF 2) => (INTEGER 2 2), or perhaps just (INTEGER 2)
and define (INTEGER x) <=> (integer x x).  But this does not seem to
generalize nicely to other data types.

If the goal is that TYPE-OF should return the most specific possible
type, then clearly when applied to object x it should return (MEMBER x),
as that is the most specific type that contains x.  But this is not
very useful, and therefore this goal is not what we really want.

--Guy

∂20-Nov-86  1250	RPG  	TYPE-OF  
To:   common-lisp@SAIL.STANFORD.EDU   

Given the recent re-discovery that TYPE-OF cannot be defined to have the
same precise behavior in all Common Lisps, it seems we should rename
`types' to be `sorts' and therefore rename `TYPE-OF' to be `SORT-OF.'

			-rpg-

∂20-Nov-86  1325	FAHLMAN@C.CS.CMU.EDU 	EVAL    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Nov 86  13:20:19 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 20 Nov 86 16:19:24-EST
Date: Thu, 20 Nov 1986  16:19 EST
Message-ID: <FAHLMAN.12256513463.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Sean.Engelson@CAD.CS.CMU.EDU
Cc:   common-lisp@SU-AI.ARPA
Subject: EVAL
In-reply-to: Msg of 20 Nov 1986 13:28-EST from Sean.Engelson at cad.cs.cmu.edu


    Why is it that EVAL returns the value in the current DYNAMIC
    environment, rather than the lexical environment?  Or perhaps the most
    recent binding (lexical unless a variable is special)?  Or if this is
    necessary for some reason, why isn't there another function, say,
    LEXICAL-EVAL that does this?  It seems rather strange to have a mainly
    lexically scoped language with no facility for lexical evaluation.

EVAL cannot easily be defined to work in the lexical environment in
which it appears because that lexical environment is not around at
runtime, when the argument to EVAL arrives and the evaluation occurs.
In any event, it would eliminate many of the benefits of lexical scoping
to provide a loophole through which arbitrary forms might be smuggled
into a lexical environment at runtime.  For example, certain
optimization are now possible because the compiler can examine all
possible references to a lexically-bound variable by scanning the
lexical block in which it is bound; thsi would go away in the presence
of your LEXICAL-EVAL.

So the language specifies that EVAL operates within the current dynamic
environment and the null lexical environment, and it does not provide a
way to pass a non-null lexical environment to EVAL.

For debugging, it is useful to be able to access lexical variables by
name, but this falls outside of the language proper.  It does not need
to be portable and it does not need to work in code that has been
altered beyond recognition by the compiler.

I must have answered this question a hundred times, both on this mailing
list and elsewhere.  We'd better put a "rationale" statement intot he
next version of the manual, since people seem to find this more
confusing than anything else (except maybe packages and case conversion).

-- Scott

∂20-Nov-86  1433	DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	TYPE-OF    
Received: from ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM by SAIL.STANFORD.EDU with TCP; 20 Nov 86  14:33:25 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 111079; Thu 20-Nov-86 14:48:32 EST
Date: Thu, 20 Nov 86 13:34 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: TYPE-OF
To: a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET,
    common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET
In-Reply-To: <8611191441.AA16856@ccut.u-tokyo.junet>
Message-ID: <861120133433.3.DLW@CHICOPEE.SCRC.Symbolics.COM>

OK, I think it's clear that you don't really want TYPE-OF to return "the
most specific type".  Rather, you want it to be the case that TYPE-OF is
well-defined for all objects in Common Lisp, and that the definition,
which will be written out clearly somewhere, will tend to specify that
more-specific rather than less-specific types be returned.  If some
implementation has its own even-more-specific type, TYPE-OF will not
return it.

Even so, I'm not sure I understand why you need TYPE-OF.  As far as I
can tell, almost the only useful thing to do with a type is to see
whether some object is of that type, and that's what TYPEP is for.

In your D-Eval example, evaluating (foo 1) returned 2 and printed out ";
FIXNUM".  If you had said (foo 0), it would have returned 1, but would
it have printed out "; BIT"?  Apparently not, because that's not in your
list of number types.  On the other hand, why doesn't 2 print out ";
INTEGER"?  That is, why does your list exclude BIT but include FIXNUM
and BIGNUM?  Whether an integer is a FIXNUM or not depends on the
implementation, and usually it's better to hide it than draw attention
to it.  Same question for the different floating point formats.  In
order to make TYPE-OF fully-defined, some kinds of decisions have to be
made, and some of them seem rather arbitrary (in the sense that it's not
really clear which decision is best).

∂20-Nov-86  1532	Pavel.pa@Xerox.COM 	Re: fboundp question
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Nov 86  15:27:20 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 20 NOV 86 14:24:35 PST
Date: 20 Nov 86 14:24 PST
From: Pavel.pa@Xerox.COM
Subject: Re: fboundp question
In-reply-to: Christopher Fry <cfry@OZ.AI.MIT.EDU>'s message of Thu, 20
 Nov 86 06:12 EST
To: cfry@OZ.AI.MIT.EDU
cc: common-lisp@SU-AI.ARPA
Message-ID: <861120-142435-4722@Xerox>

Page 71: ``We say that a predicate `is true' when it returns a non-NIL
value''

Page 90-91: ``FBOUNDP is true if the symbol has a global function
definition.  Note that FBOUNDP is true when the symbol names a special
form or macro.''

Page 116: ``COND {(test {form}*)}*   [Macro]''

Page 133: ``GO tag    [Special Form]''


Therefore,
	(fboundp 'cond) => a non-NIL value
	(fboundp 'go) => a non-NIL value


Nothing more is guaranteed by the language definition.  Xerox and Lucid
Lisps return T in both cases.

	Pavel

∂21-Nov-86  0242	a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET 	question: EVAL  
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 21 Nov 86  02:42:07 PST
Received: from utokyo-relay by csnet-relay.csnet id ac01740; 21 Nov 86 4:56 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
	id AA11733; Fri, 21 Nov 86 18:10:26+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
	id AA12885; Fri, 21 Nov 86 17:49:44+0900
Date: Fri, 21 Nov 86 17:49:44+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Message-Id: <8611210849.AA12885@ccut.u-tokyo.junet>
To: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET
Subject: question: EVAL


In the list of GLS, there is an EVAL extension to have an optional argument
for 'environment'.
will it be defined in the comming specification ?
Is this only one argument ?
Does the value of this optional 'environmental' argument have a defined
syntax/semantics ?

ida

∂21-Nov-86  0613	RAM@C.CS.CMU.EDU 	question: EVAL   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Nov 86  06:13:05 PST
Received: ID <RAM@C.CS.CMU.EDU>; Fri 21 Nov 86 09:12:26-EST
Date: Fri, 21 Nov 1986  09:12 EST
Message-ID: <RAM.12256697887.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Cc:   common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET
Subject: question: EVAL
In-reply-to: Msg of Fri 21 Nov 86 17:49:44+0900 from Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet at RELAY.CS.NET>


    You can use Evalhook to evaluate a form in an environment,
supposing that you can get your hands on one.  Currently the only
way to get your hands on a guaranteed evaluation environment is to use
*evalhook* or *applyhook*.  With such an environment, the semantics
are well defined.  Some implementations that don't have an evaluator
don't support *evalhook* though...

  Rob

∂21-Nov-86  0637	RAM@C.CS.CMU.EDU 	TYPE-OF
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Nov 86  06:37:07 PST
Received: ID <RAM@C.CS.CMU.EDU>; Fri 21 Nov 86 09:36:58-EST
Date: Fri, 21 Nov 1986  09:36 EST
Message-ID: <RAM.12256702349.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Cc:   common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET
Subject: TYPE-OF
In-reply-to: Msg of Wed 19 Nov 86 23:41:56+0900 from Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet at RELAY.CS.NET>

    Date: Wed, 19 Nov 86 23:41:56+0900
    From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet at RELAY.CS.NET>
    To:   common-lisp at SU-AI.ARPA, ida%u-tokyo.junet at RELAY.CS.NET
    Re:   TYPE-OF

    D-Eval concept needs TYPE-OF.  kinds of type inferencing system
    will also need TYPE-OF to determine the type.
    Here is a conversation with D-Eval:

    D-Eval>(+ 1 2)
    3
    ; FIXNUM

Well, if all D-Eval uses Type-Of for is to print out the type, then it
doesn't really matter what it returns.  I had in mind a fragment of
code that needed to use Type-Of.  I don't know exactly what you mean
by a "type inferencer", but for the kinds of type inferences that I
could conceive of a Lisp compiler wanting to do, you definitely want
the *most specific* type, and certainly don't want to return random
things such as FIXNUM which represent implementation details rather
than language semantics.

Suppose that I was examining the expression:
  (+ (aref a 3) 7)
Now, if A is known (due to declaration) to be 
(array (unsigned-byte 8)), then I could combine the fact that 7 is
(integer 7 7) with that information to determine that the result of the
addition is (integer 262 7), which is probably a useful thing to know.
If all that I know is that 7 is FIXNUM, then all bets are off.

I didn't mention this on the mailing list as a valid use of Type-Of,
since:
  1] The compiler *is* the implementation, so it doesn't matter if it
     is implementiaton dependent.
  2] The version of Type-Of that I am using in the compiler is
     optimized to return what the compiler considers most interesting,
     rather than what the user might consider most informative.  For
     example, given a symbol, it returns (member <symbol>).

  Rob

∂21-Nov-86  0808	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Packages
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Nov 86  08:08:04 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 5975; Thu 20-Nov-86 20:24:05 EST
Date: Thu, 20 Nov 86 20:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Packages
To: wile@ISI-VAXA.ARPA
cc: COMMON-LISP@SU-AI.ARPA
In-Reply-To: <8611182057.AA08142@vaxa.isi.edu>
Message-ID: <861120202347.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 18 Nov 1986 1257-PST (Tuesday)
    From: wile@ISI-VAXA

    I believe inclusion of packages is the worst mistake in Common LISP's
    design.  There isn't a day goes by (when I actually get to program or
    debug) when I don't have package problems....
    I am looking for conventions that make packages easier to live with.

I am surprised that you have not noticed that Common Lisp does NOT require the
programmer to use packages.  The only packages Common Lisp requires you to
know about are USER, LISP, and KEYWORD.  You can ignore the distinction
between USER and LISP, and pretend that KEYWORD symbols are just symbols with
colons in their names, and get along just fine.  Of course you don't get any
of the benefits of packages this way, but you don't get any of the problems,
either.  Another way to look at it is that Common Lisp contains the
Maclisp/Interlisp one-symbol-namespace dialect as a subset.

I do not mean by this comment to stifle anyone's research into better
modularity facilities for Lisp than packages.  I am confident that something
better will eventually be invented, developed, and tempered in the fire of
real-life use.  Several promising ideas have already come forth (starting at
least 22 years ago, actually).  If any of those ideas are so well-developed
and problem-free that they are ready for universal adoption, I haven't heard
about it yet, but I'm sure it's bound to happen eventually.

∂21-Nov-86  0944	wile@vaxa.isi.edu 	Package solution "motivation"  
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 21 Nov 86  09:44:50 PST
Received: by vaxa.isi.edu (4.12/4.7)
	id AA11398; Fri, 21 Nov 86 09:45:10 pst
Message-Id: <8611211745.AA11398@vaxa.isi.edu>
Date: 21 Nov 1986 0945-PST (Friday)
To: COMMON-LISP@SU-AI.ARPA
From: wile@ISI-VAXA
Subject: Package solution "motivation"



I was afraid of that.  Everyone jumped on the complaint and ignored the
proposal.  I'll complain more succinctly in a separate message.

The problem I am trying to solve, as a producer of software that
manipulates program specifications and implementations, is to allow my 
users to be as unconcerned with packages as possible.

I have written a system, called Popart, which takes BNF grammars extended
with regular expressions and operator precedence, a produces a parser,
lexical analyzer, pretty printer, pattern matcher, (old style) structure
editor, and transformation system for the language written in that grammar.
Of course, I have tried to integrate the facility consistent with Common
LISP conventions, rather than just deeming packages "red herrings" to be
ignored.  Generally, our use of Popart will be to allow users to specify
the functionality of their application in a language we call Gist,
transform that specification into a language we call Will, which will be
automatically compiled into Common LISP.

Yesterday's comment that "the user must have a firm model of the package
structure" is right on.  Consider the packages involved in the scenario
above:

  Grammar parse tree structures
  Grammar constants
  Grammar grammar parse tree structures
  Grammar grammar constants
  Transformation definition language parse tree
      "     "      "   "      "  "   constants
  Transformation definitions themselves (their names, like
     divide-and-conquer, duplicate-arm-motion-removal, ...)
  User Gist symbols (Gist application package, e.g. relation names, 
     agent names)
  User Will symbols (e.g. demon names, type definitions)
  LISP and below

Obviously, creating the right defaulting mechanism is very important here.

The first major decision was to put all grammar constants (begin, end, +,
etc.) in the keyword package for all grammars.  I would prefer to put them
into the uninterned symbol (non)package, but I don't know how to read into
that package.  The reason I would prefer to do this is partially an
efficiency issue.  If I could read symbols that way, I could decide to put
the (few) symbols whose packages matter (names of functions, defined
entities in the users' languages) in that package.  The only option I seem
to have is to read everything into the user's package and change them into
grammar constants when I see that that name has been used in the grammar.
Perhaps I could read everything into the keyword package, but I had visions
of creating lots of garbage keyword symbols.  I don't know...  Reading the
symbol uninterned and then deciding where to intern it seems conceptually
the right hook.  Thus, the proposal to allow read an optional functional
parameter to decide where to put the symbol.

[Incidentally, the other defaults:

  Grammar grammar parse tree structures are in the parser's package.
  Transformation definition language parse trees are in the transformation
     system's package.
  Transformation definitions themselves are in the grammar's package for
     which language they are transformations.
  User Gist and Will symbols are in packages defined (used) by the user
     (just as function definitions, variable definitions, etc., are in
     Lisp)
]

Sorry for the vitriolic attack.  (I'd tried to make it many times before,
with no proposed solution, so I'd resisted.  I thought I was being positive
with my proposal.)  Perhaps now you understand my frustration...

   Dave Wile

∂21-Nov-86  1152	RWK@STONY-BROOK.SCRC.Symbolics.COM 	type-of  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Nov 86  11:51:57 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6714; Fri 21-Nov-86 14:44:48 EST
Date: Fri, 21 Nov 86 14:46 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: type-of
To: Sandra J Loosemore <sandra%utah-orion@UTAH-CS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8611191611.AA14790@utah-orion.ARPA>
Supersedes: <861121144528.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <861121144625.5.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

    Date: Wed, 19 Nov 86 09:11:01 MST
    From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)

	From: RWK@YUKON.SCRC.Symbolics.COM (Robert W. Kerns)
	Date: 18 Nov 86 21:04:00 GMT

	Here is an example of completely-portable code which depends on
	TYPE-OF returning the MOST specific type.

	(defun store-in-array-if-fits (object array &rest indicies)
	  (let ((object-type (type-of object))
		(array-type (array-element-type array)))
	    (if (subtypep object-type array-type)
	      ;; If the object fits, store it
		(setf (apply #'aref array indicies) object)
	      ;; Doesn't fit, so store 0 instead.
		(setf (apply #'aref array indicies) 0))))

    Sorry, I can't buy this motivation.  All this example illustrates is that
    there is a good reason for having the TYPEP function around.

(defun typep (object type)
  (subtypep (type-of object) type))

Yes, my example is a bit oversimplified; I was more interested in
demonstrating portability than necessity.  And the "important half"
of TYPEP is SUBTYPEP, not TYPE-OF.  But TYPEP doesn't let you
make the decision about the type separately from the object in
question.

    As it happens, in PCLS, TYPE-OF does go through a considerable amount of 
    work to find the most specific type that it can.  So, (TYPE-OF 0) returns 
    BIT, which is correct but largely useless.  My "gut feeling" is that what
    the user probably wants is either FIXNUM or INTEGER --  something which 
    indicates how the object is represented internally, or (in other words) 
    one of the set of types which CLtL says are disjoint.
If the user is writing his code properly, he is using
type-comparison (i.e. SUBTYPEP), so he doesn't really
care.  But your "gut feeling" is right, he probably
doesn't care about anything more specific than
FIXNUM.

That's why I think it would be advantagious to more
precisely specify TYPE-OF.  Right now the spec could
be read as requiring (TYPE-OF 0) => BIT.  If we specify
a "least specific" type (FIXNUM in this case), than
any implementation which returns something *at least*
as specific as FIXNUM is fine.  If an implementation
has reason for being more specific, however, it should
be free to do so.

    I'll have to agree that TYPE-OF as defined now is pretty bogus.  The only 
    place I've ever had reason to use TYPE-OF in real code was to get a type
    to pass to COERCE or CONCATENATE, etc., when I wanted to ensure that two
    objects were of the same type; for example, both lists or whatever.  But 
    this is full of holes, too.  For example, 

	(coerce '#(a b c) (type-of (list)))

    may fail, depending on whether your favorite implementation thinks NIL is
    of type NULL, LIST, or SYMBOL.  I ended up writing a specialized function
    to do what I wanted, without relying on TYPE-OF.

This is just a matter of TYPE-OF not being specific enough
together with COERCE not being general enough.  If TYPE-OF
is properly specific (i.e. NULL), and COERCE finds the
"least supertype" of the argument type that it supports
(for example, if you wrote it with TYPECASE or SUBTYPEP,
rather than EQL), then there's no problem.

Our entire user-interface in Release 7 is based on just
type sort of question.  It is fundamental to any theory
of TYPEP, as well.  I freely admit that it isn't often
called, but that's not a reason to eliminate it, or to
leave it sloppily specified.

    In short, I am not convinced that TYPE-OF would be particularly useful even
    if its definition were firmed up more.  If nobody has any good use for this
    function, arguing over how it should behave is rather pointless.
I think your own example contradicts this position.

∂21-Nov-86  1231	RWK@STONY-BROOK.SCRC.Symbolics.COM 	TYPE-OF  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Nov 86  12:31:44 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6790; Fri 21-Nov-86 15:29:36 EST
Date: Fri, 21 Nov 86 15:30 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: TYPE-OF
To: Guy Steele <gls@think.com>
cc: DLW@ALDERAAN.SCRC.Symbolics.COM,
    a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@relay.cs.net,
    common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@relay.cs.net
In-Reply-To: <861120151614.4.GLS@HILARION.THINK.COM>
Message-ID: <861121153042.6.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

    Date: Thu, 20 Nov 86 15:16 EST
    From: Guy Steele <gls@think.com>

    One might want (TYPE-OF 2) => (INTEGER 2 2), or perhaps just (INTEGER 2)
    and define (INTEGER x) <=> (integer x x).  But this does not seem to
    generalize nicely to other data types.

    If the goal is that TYPE-OF should return the most specific possible
    type, then clearly when applied to object x it should return (MEMBER x),
    as that is the most specific type that contains x.  But this is not
    very useful, and therefore this goal is not what we really want.

    --Guy

Right.  That's why I proposed specifying a "least specific"
type, saying that "it must be at least this specific".  Combine
this with the requirement that whatever is actually returned
must be understood by SUBTYPEP (i.e. SUBTYPEP of that type
and the "least specific" type specified must return T T).

∂21-Nov-86  1300	RWK@STONY-BROOK.SCRC.Symbolics.COM 	TYPE-OF  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Nov 86  12:59:48 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6852; Fri 21-Nov-86 15:57:48 EST
Date: Fri, 21 Nov 86 15:58 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: TYPE-OF
To: Rob MacLachlan <RAM@C.CS.CMU.EDU>
cc: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>,
    common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET
In-Reply-To: <RAM.12256702349.BABYL@C.CS.CMU.EDU>
Message-ID: <861121155855.7.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

    Date: Fri, 21 Nov 1986  09:36 EST
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>

	Date: Wed, 19 Nov 86 23:41:56+0900
	From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet at RELAY.CS.NET>
	To:   common-lisp at SU-AI.ARPA, ida%u-tokyo.junet at RELAY.CS.NET
	Re:   TYPE-OF

	D-Eval concept needs TYPE-OF.  kinds of type inferencing system
	will also need TYPE-OF to determine the type.
	Here is a conversation with D-Eval:

	D-Eval>(+ 1 2)
	3
	; FIXNUM

    Well, if all D-Eval uses Type-Of for is to print out the type, then it
    doesn't really matter what it returns.  I had in mind a fragment of
    code that needed to use Type-Of.  I don't know exactly what you mean
    by a "type inferencer", but for the kinds of type inferences that I
    could conceive of a Lisp compiler wanting to do, you definitely want
    the *most specific* type, and certainly don't want to return random
    things such as FIXNUM which represent implementation details rather
    than language semantics.
Eh?  You're contradicting yourself.

Compilers deal directly with implementation, and that's
why you want something more specific, such as FIXNUM,
rather than something at the level of language semantics,
such as INTEGER.  I think you're trying to argue that you
want something more specific still, but that's not TYPE-OF's
job.

    Now, if A is known (due to declaration) to be 
    (array (unsigned-byte 8)), then I could combine the fact that 7 is
    (integer 7 7) with that information to determine that the result of the
    addition is (integer 262 7), which is probably a useful thing to know.
    If all that I know is that 7 is FIXNUM, then all bets are off.
If all you have is TYPE-OF and SUBTYPEP, yes, that is true.
If you don't want to throw away information, keep the
original object.

In a recent message, I oversimplified TYPEP, because I'm
trying to stay out of certain issues better handled in
a paper, where hopefully I can be more careful and
verbose.  So I lied a little.  Let's consider that
lie for a moment.  (My apologies for presenting all of
this in such a fragmentary way).

In that other message, I defined TYPEP as

(defun typep (object type)
  (subtypep (type-of object) type))

This mostly works.  However, this depends on TYPE-OF
returning the most-specific type, so for any appropriate
type for an object, TYPE-OF will return something at
least as specific, and which SUBTYPEP can decide on.
Let me assert at this point, without proof, that there
is no such single type.

The problem is that TYPE-OF is inherently an information-losing
operation.  The pair TYPE-OF/SUBTYPEP is actually a special
case of a more general matching process that I really don't want
to go into right now.  The key point, however, is that TYPEP
actually does some things that SUBTYPEP can't, because it actually
has the object.  The same is true of your "type merger" for addition,
which should look at the actual object when it has one, and not
call TYPE-OF.

    I didn't mention this on the mailing list as a valid use of Type-Of,
    since:
      1] The compiler *is* the implementation, so it doesn't matter if it
	 is implementiaton dependent.
      2] The version of Type-Of that I am using in the compiler is
	 optimized to return what the compiler considers most interesting,
	 rather than what the user might consider most informative.  For
	 example, given a symbol, it returns (member <symbol>).

This is an interesting approach.  It reduces TYPE-OF/SUBTYPEP to TYPEP!

∂21-Nov-86  1519	sandra%utah-orion@utah-cs.arpa 	Re: type-of  
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 21 Nov 86  15:19:00 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
	id AA20321; Fri, 21 Nov 86 16:20:00 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
	id AA07808; Fri, 21 Nov 86 16:19:56 MST
Date: Fri, 21 Nov 86 16:19:56 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Message-Id: <8611212319.AA07808@utah-orion.ARPA>
Subject: Re: type-of
To: Robert W. Kerns <RWK@scrc-yukon.arpa>
Cc: common-lisp@su-ai.arpa
In-Reply-To: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>, Fri, 21 Nov 86 14:46 EST

Two comments on your comments.

First of all, neither TYPE-OF or SUBTYPEP is necessary for implementing
TYPEP.  In fact, doing it that way is probably the most inefficient 
implementation possible.  In PCLS, for example, all of the built-in types
like INTEGER or SIMPLE-STRING have predicates associated with them that
can be found by a quick lookup procedure, and there is special logic for 
handling the more complicated type specifiers like (ARRAY ...).

I agree that TYPE-OF should not be thrown out just because nobody uses
it much, *provided* that the function is there because it implements some
functionality users could not easily implement themselves.  For the uses
of TYPE-OF that people have mentioned so far, this is not the case.  Here
is a portable, 3-line function that will check an object against whatever
set of type specifiers I think are appropriate in this situation:

(defun my-type-of (object possible-type-spec-list)
    (dolist (type possible-type-spec-list t)
        (if (typep object type) (return type))))

The only case where this would fail would be if I do not know in advance
what type specifiers I want to see returned.  Gee whiz!  Isn't that what
TYPE-OF is supposed to do now?  :-)

-Sandra
-------

∂21-Nov-86  1657	RAM@C.CS.CMU.EDU 	TYPE-OF
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Nov 86  16:57:10 PST
Received: ID <RAM@C.CS.CMU.EDU>; Fri 21 Nov 86 19:57:05-EST
Date: Fri, 21 Nov 1986  19:57 EST
Message-ID: <RAM.12256815241.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   "Robert W. Kerns" <RWK@SCRC-YUKON.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: TYPE-OF
In-reply-to: Msg of 21 Nov 1986  15:58-EST from Robert W. Kerns <RWK at YUKON.SCRC.Symbolics.COM>

    Date: Friday, 21 November 1986  15:58-EST
    From: Robert W. Kerns <RWK at YUKON.SCRC.Symbolics.COM>
    To:   Rob MacLachlan <RAM>

        Date: Fri, 21 Nov 1986  09:36 EST
        From: Rob MacLachlan <RAM@C.CS.CMU.EDU>

        ... I don't know exactly what you mean
        by a "type inferencer", but for the kinds of type inferences that I
        could conceive of a Lisp compiler wanting to do, you definitely want
        the *most specific* type, and certainly don't want to return random
        things such as FIXNUM which represent implementation details rather
        than language semantics.
    Eh?  You're contradicting yourself.
Nope, (INTEGER 3 3) is more specific than FIXNUM, which is after all
just (INTEGER most-negative-fixnum most-positive-fixnum).

    Compilers deal directly with implementation, and that's
    why you want something more specific, such as FIXNUM,
    rather than something at the level of language semantics,
    such as INTEGER.  I think you're trying to argue that you
    want something more specific still, but that's not TYPE-OF's
    job.
What we are trying to determine is what TYPE-OF's jobs is.  I
introduced my compiler example, not necessarily because I thought that
TYPE-OF should do what my CTYPE-OF does, but because I wanted to
challenge Ida's contention that TYPE-OF was useful for type inference.
I.e. I am still trying to home in on a valid use for TYPE-OF.  The way
that type inference is done by my compiler is irrelevant; I simply
wanted to show that Ida's TYPE-OF is useless in my type inferencer.

    In a recent message, I oversimplified TYPEP, [...]
    This mostly works.  However, this depends on TYPE-OF
    returning the most-specific type, so for any appropriate
    type for an object, TYPE-OF will return something at
    least as specific, and which SUBTYPEP can decide on.
    Let me assert at this point, without proof, that there
    is no such single type.

    The problem is that TYPE-OF is inherently an information-losing
    operation. [...]

I think we are agreeing violently.  My main disagreement with you is
over whether there is a way to make TYPE-OF as strongly defined as you
want without pointlessly constraining the implementation, and if so
whether it is worth the bother (and core).  People have written a
number of programs without a well-defined TYPE-OF/SUBTYPEP.  It is not
clear we should foist additional overhead on Common Lisp just to make
the semantics of a nearly useless operation esthetically appealing.

  Rob

∂22-Nov-86  1433	@REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU 	EVAL  
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Nov 86  14:33:00 PST
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 12420; Sat 22-Nov-86 17:32:40 EST
Date: Sat, 22 Nov 86 17:32 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: EVAL
To: Fahlman@C.CS.CMU.EDU
cc: Sean.Engelson@CAD.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12256513463.BABYL@C.CS.CMU.EDU>
Message-ID: <861122173233.4.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Thu, 20 Nov 1986  16:19 EST
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
    EVAL cannot easily be defined to work in the lexical environment in
    which it appears because that lexical environment is not around at
    runtime, when the argument to EVAL arrives and the evaluation occurs.
    In any event, it would eliminate many of the benefits of lexical
    scoping to provide a loophole through which arbitrary forms might be
    smuggled into a lexical environment at runtime.  For example, certain
    optimization are now possible because the compiler can examine all
    possible references to a lexically-bound variable by scanning the
    lexical block in which it is bound; thsi would go away in the presence
    of your LEXICAL-EVAL....

Right.  This demonstrates that LEXICAL-EVAL would have to be a new special
form, rather than simply a function.

∂22-Nov-86  1701	Pavel.pa@Xerox.COM 	Re: EVAL  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Nov 86  17:00:55 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 22 NOV 86 17:00:37 PST
Date: 22 Nov 86 17:00 PST
From: Pavel.pa@Xerox.COM
Subject: Re: EVAL
In-reply-to: Alan Bawden <Alan@AI.AI.MIT.EDU>'s message of Sat, 22 Nov
 86 17:32 EST
To: Alan@AI.AI.MIT.EDU
cc: common-lisp@SU-AI.ARPA
Message-ID: <861122-170037-2387@Xerox>

    Date: Sat, 22 Nov 86 17:32 EST
    From: Alan Bawden <Alan@AI.AI.MIT.EDU>
    
    Right.  This demonstrates that LEXICAL-EVAL would have to be a
    new special form, rather than simply a function.

Even if it were a special form, what code could the compiler generate
for it?  Would the presence of such a special form require turning off
all optimizations having to do with the lexical environment and cause
the compiler to create some sort of run-time environment structure
containing names and such?  Yecch.

	Pavel

∂22-Nov-86  1743	ricks%shambhala.Berkeley.EDU@BERKELEY.EDU 	Macrolet and setf
Received: from UCBVAX.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 22 Nov 86  17:42:53 PST
Received: by ucbvax.Berkeley.EDU (5.53/1.18)
	id AA16854; Sat, 22 Nov 86 17:42:37 PST
Received: by shambhala.berkeley.edu (4.12/5.6)
	id AA02560; Sat, 22 Nov 86 15:04:06 pst
From: ricks%shambhala.Berkeley.EDU@BERKELEY.EDU (Rick L Spickelmier)
Message-Id: <8611222304.AA02560@shambhala.berkeley.edu>
Date: 22 Nov 1986 1504-PST (Saturday)
To: COMMON-LISP@su-ai.arpa
Subject: Macrolet and setf

Are macros defined with macrolet allowed as place forms in setf?

I have tried the following in VAXLISP and EXCL with both reporting
that 'mmm' can not be used as a place form (interpreted and compiled).

(defun abc (n)
  (macrolet ((mmm (z) `(gethash ,z *bob*)))
	    (setf (mmm n) 5)))

		
		Rick Spickelmier
		UC Berkeley

∂22-Nov-86  1820	@REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU 	Re: EVAL   
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Nov 86  18:20:29 PST
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 12445; Sat 22-Nov-86 21:20:12 EST
Date: Sat, 22 Nov 86 21:20 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: Re: EVAL
To: Pavel.pa@Xerox.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <861122-170037-2387@Xerox>
Message-ID: <861122212008.0.ALAN@PIGPEN.AI.MIT.EDU>

    Date: 22 Nov 86 17:00 PST
    From: Pavel.pa@Xerox.COM
	Date: Sat, 22 Nov 86 17:32 EST
	From: Alan Bawden <Alan@AI.AI.MIT.EDU>
	Right.  This demonstrates that LEXICAL-EVAL would have to be a new
	special form, rather than simply a function.
    Even if it were a special form, what code could the compiler generate
    for it?  Would the presence of such a special form require turning off
    all optimizations having to do with the lexical environment and cause
    the compiler to create some sort of run-time environment structure
    containing names and such?  Yecch.

That would seem to be what you have to do.  The variables that are
lexically apparent at the site of the LEXICAL-EVAL would have to be handled
somewhat more carefully than ordinary lexical variables.  Presumably by
bundling them up into some kind of explicit environment structure.

In Common Lisp you would also have to include the current function
definitions established by FLET, the current BLOCK names and TAGBODY tags,
and the current macro definitions established by MACROLET.

Please note that I have yet to express an opinion about this.

∂22-Nov-86  1922	Pavel.pa@Xerox.COM 	Re: Macrolet and setf    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Nov 86  19:22:16 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 22 NOV 86 19:21:22 PST
Date: 22 Nov 86 19:21 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Macrolet and setf
In-reply-to: ricks%shambhala.Berkeley.EDU@BERKELEY.EDU (Rick L
 Spickelmier)'s message of 22 Nov 86 15:04 PST (Saturday)
To: ricks%shambhala.Berkeley.EDU@BERKELEY.EDU
cc: COMMON-LISP@su-ai.arpa
Message-ID: <861122-192122-2541@Xerox>

    Date: 22 Nov 86 15:04 PST (Saturday)
    From: ricks%shambhala.Berkeley.EDU@BERKELEY.EDU (Rick L
    Spickelmier)
     
    Are macros defined with macrolet allowed as place forms in setf?
     
    I have tried the following in VAXLISP and EXCL with both
    reporting that 'mmm' can not be used as a place form (interpreted
and
    compiled).
     
    (defun abc (n)
      (macrolet ((mmm (z) `(gethash ,z *bob*)))
    	    (setf (mmm n) 5)))
     
I believe that VAXLISP and EXCL are both in error.  Xerox, Lucid, and
Symbolics all do this correctly.

	Pavel

∂22-Nov-86  1932	franz!ficl!jkf@ucbarpa.Berkeley.EDU 	Re: Macrolet and setf  
Received: from UCBARPA.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 22 Nov 86  19:32:14 PST
Received: by ucbarpa.Berkeley.EDU (5.57/1.18)
	id AA14358; Sat, 22 Nov 86 19:32:14 PST
Received: from ficl by franz (5.5/3.14)
	id AA22968; Sat, 22 Nov 86 18:51:35 PST
Received: by ficl (5.5/3.14)
	id AA08389; Sat, 22 Nov 86 18:52:05 PST
From: franz!ficl!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <ficl!jkf>
Message-Id: <8611230252.AA08389@ficl>
To: ricks%shambhala.Berkeley.EDU@BERKELEY.EDU (Rick L Spickelmier)
Cc: COMMON-LISP@su-ai.arpa
Subject: Re: Macrolet and setf 
In-Reply-To: Your message of Sat, 22 Nov 86 15:04:00 PST.
             <8611222304.AA02560@shambhala.berkeley.edu> 
Date: Sat, 22 Nov 86 18:52:02 PST


>> (defun abc (n)
>>   (macrolet ((mmm (z) `(gethash ,z *bob*)))
>> 	    (setf (mmm n) 5)))


 I believe that the preceeding should be permitted, but it requires that
get-setf-method be permitted to take a second, environment, argument.
Such a change may have already been proposed.


-john foderaro
franz inc.

∂22-Nov-86  2052	FAHLMAN@C.CS.CMU.EDU 	Macrolet and setf 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Nov 86  20:51:54 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 22 Nov 86 23:51:50-EST
Date: Sat, 22 Nov 1986  23:51 EST
Message-ID: <FAHLMAN.12257120126.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   franz!ficl!jkf@λucbarpa.Berkeley.EDU (John Foderaro)λ
Cc:   COMMON-LISP@SU-AI.ARPA
Subject: Macrolet and setf 
In-reply-to: Msg of 22 Nov 1986  21:52-EST from franz!ficl!jkf at ucbarpa.Berkeley.EDU (John Foderaro)


    >> (defun abc (n)
    >>   (macrolet ((mmm (z) `(gethash ,z *bob*)))
    >> 	    (setf (mmm n) 5)))


     I believe that the preceeding should be permitted, but it requires that
    get-setf-method be permitted to take a second, environment, argument.
    Such a change may have already been proposed.

You're right, that's what it takes, and this change has already been
proposed.  It seemed pretty clear to everyone that this change was
required in order for SETF of macros to work properly, so a number of
implementations went ahead and added it (as an optional arg), even
though there has been no mechanism whereby this change could be adopted
officially.

-- Scott

∂22-Nov-86  2054	RPG  	GET-SETF-METHOD    
To:   common-lisp@SAIL.STANFORD.EDU   

This issue comes up every 6-12 months. Most recently, on December 13,
1985, Steele proposed a clarification, which he lists as `serious':

   (*) 107 Clarify that GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE do
   not perform macro-expansion on the given form, and that in most contexts
   the usage should be (GET-SETF-METHOD (MACROEXPAND form env)).  Indeed,
   the simplified example version of SETF given on page 108 should be
   changed to: <you don't want to see it>

Nine hours and 31 minutes later, Rob MacLachlan pointed out that this
would not work because of setf methods.

Two days, 11 hours, and 49 minutes later, Steele agreed.

In the meantime, on December 14, 1985, Eric Benson pointed out that
DEFINE-SETF-METHOD also needed an environment passed.  On July 19 Plummer
noticed it himself, and MacLachlan affirmed this observation.

Several vendors made the change because it seemed a clear case of a
mistake in the language rather than a clarification.

I would say that VaxLisp and ExCL are not in error, but the usefulness
of MACROLET is limited without this change.

			-rpg-

∂23-Nov-86  1236	RAM@C.CS.CMU.EDU 	(typep 3 'complex) => t    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Nov 86  12:36:25 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 23 Nov 86 15:36:20-EST
Date: Sun, 23 Nov 1986  15:36 EST
Message-ID: <RAM.12257292060.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: (typep 3 'complex) => t


There is a bit of type sysem lossage that I noticed lately which is
unrelated to the TYPE-OF discussion.  My realization is that RATIONAL
is a subtype of (COMPLEX NUMBER), since according to p47, "...this
type encompasses those complex numbers that can result from giving
numbers of the specified type to the function COMPLEX."  Of course,
(COMPLEX 3 0) => 3.

This interpretation depends on the meaning of the phrase "complex
numbers" in the above passage.  This interperetation does not hold if
"complex number" in the above passage means a number where
(NOT (EQL (IMAGPART number) 0)).

Due to the rule for complex canonicalization, it makes no sense to
require the non-0 imagpart, since it makes the declaration useless
for complex numbers with rational components.

It seems that there is an analogy between COMPLEX and RATIONAL due to
the similarity of the complex and rational canonicalization rules.  3
is a rational, since a rational can be canonicalized to an integer.
Similarly, 3 is a complex since a complex can be canonicalized to an
integer.  The real problem is that there is no type which is to
COMPLEX as RATIO is to RATIONAL, i.e. a type that represents complex
numbers that have not been canonicalized.

If my intepretation is correct, then the COMPLEX type with no
component type specified is effectively equivalent to 
(AND NUMBER (NOT FLOAT)).  This makes the COMPLEXP function fairly
useless if it continues to be equivalent to (TYPEP ... 'COMPLEX).

There is some mumbling about "may be different for declaration and
discrimination" in the definition of the COMPLEX type specifier, but
close reading suggests that this is irrelevant to the issue at hand,
since it is really attempting to say that COMPLEX types are similar to
ARRAY types in that the implementation has freedom in choosing
component type specializations.  Comparison with the similar hemming
and hawing in the ARRAY definition supports this conclusion.

  Rob

∂23-Nov-86  1413	Masinter.pa@Xerox.COM 	Re: (typep 3 'complex) => t
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Nov 86  14:13:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 NOV 86 14:13:43 PST
Date: 23 Nov 86 14:13 PST
From: Masinter.pa@Xerox.COM
Subject: Re: (typep 3 'complex) => t
In-reply-to: Rob MacLachlan <RAM@C.CS.CMU.EDU>'s message of Sun, 23 Nov
 86 15:36 EST
To: RAM@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
Message-ID: <861123-141343-2764@Xerox>

I'd thought all along that the COMPLEX type was intended to be the
analog of RATIO, and not include those numbers which canonicalized to
RATIONAL. Your message seems to assert that the description on p 47
implies otherwise, but it seems more reasonable that this is just a case
of ambiguous wording. 

You claim  "Due to the rule for complex canonicalization, it makes no
sense to require the non-0 imagpart, since it makes the declaration
useless for complex numbers with rational components."

But it does make sense, and such declarations are useful, (well, as
useful as RATIO declarations) for example:


(typecase x
	(rational  ... )
	(complex (locally (declare (type complex x)) ...)
	...)


where one could assume within the scope of the declaration that realpart
and imagpart could be optimized, for example. 

∂23-Nov-86  1432	RAM@C.CS.CMU.EDU 	(typep 3 'complex) => t    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Nov 86  14:32:45 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 23 Nov 86 17:32:41-EST
Date: Sun, 23 Nov 1986  17:32 EST
Message-ID: <RAM.12257313244.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   Masinter.pa@XEROX.COM
Cc:   common-lisp@SU-AI.ARPA
Subject: (typep 3 'complex) => t
In-reply-to: Msg of 23 Nov 1986  17:13-EST from Masinter.pa at Xerox.COM


    But under my interpretation, (DECLARE (COMPLEX FIXNUM)) would be
much more useful, since the it would be a declaration that the user
could reasonably make, yet would give the system the useful
information that both the realpart and imagpart are fixnums.  In this
case, the compiler could reasonably store the realpart and imagpart as
separate fixnums, and would only have to canonicalize them when it is
forced to pointerize the number.

    In the case of a float component type, there is no difference in
the results of the two interpretations, since complex float types are
not canonicalized.  I think that the definition of complex rational
types was not thoroughly thought out due to their novelty.

    If there were no RATIONAL type, then it would make sense to argue
that COMPLEX should be useless by analogy with RATIO, but if we are
trying to provide a useful type system, then it is silly.

    Perhaps COMPLEX should remain what everyone thought it was, but
there is definitely a need for the type that I think COMPLEX ought to
be.  I think that there is a strong argument that my interpretation
should get the "good" name, since it is what people will usually want
to use.

  Rob

∂23-Nov-86  1538	Masinter.pa@Xerox.COM 	Re: (typep 3 'complex) => t
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Nov 86  15:38:39 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 NOV 86 15:38:36 PST
Date: 23 Nov 86 15:38 PST
From: Masinter.pa@Xerox.COM
Subject: Re: (typep 3 'complex) => t
In-reply-to: Rob MacLachlan <RAM@C.CS.CMU.EDU>'s message of Sun, 23 Nov
 86 17:32 EST
To: RAM@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
Message-ID: <861123-153836-2807@Xerox>

why don't you use  

(deftype complex-number (&optional type)
   (if type `(or ,type (complex ,type))
            '(or rational complex)))


e.g., (declare (type complex-number x))
means that either X is strictly complex or else a rational, while

(declare (type (complex-number fixnum) x)
means that either X is a fixnum or a (complex fixnum).

It seems well within the bounds of the Common Lisp framework to use
deftype to add types that are interesting to some compilers, without
requiring that the types be added to every other implementation.



∂24-Nov-86  1135	@MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU 	question: EVAL   
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 86  11:34:50 PST
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 18517; 24 Nov 86 13:57:23-EST
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 44996; Fri 21-Nov-86 11:39:30-EST
Date: Fri, 21 Nov 86 11:39 est
Sender: mike@acorn
To: a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
From: mike%gold-hill-acorn@mit-live-oak.arpa
Subject: question: EVAL
Cc: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET

    Date: Fri, 21 Nov 86 17:49:44+0900
    From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
    
    
    In the list of GLS, there is an EVAL extension to have an optional argument
    for 'environment'.
    will it be defined in the comming specification ?
    Is this only one argument ?
    Does the value of this optional 'environmental' argument have a defined
    syntax/semantics ?
    
    ida

I have no qualms at all about adding the ability to address the
current macro-expansion environment, and to pass it to eval.  I have
real difficulty with the ability to pass the complete lexical
environment.I think the issue of whether to add complete environments
for eval is one of the more controvercial ones in "the list of GLS".

Having the ability to pass a lexical environment assumes the
ability to access the lexical environment. There is currently 
no way to access this, it is implicitly passed by eval to 
evalhooks, and so on.  Let me assume that you also want a way
to access the current lexical environment, say by a function
(get-current-env).

I think any code which uses this environment would be impossible to
compile, in the sense that the compiler probably couldn't do much
with it. This would hold for the entire body of lexically surrounding
code. For example:

(defun wierd-function (s-expression)
  (block here
    (tagbody :tag
       (let ((x (foo s-expression)))
        (labels ((bar (y) (+ x y)))
          (eval s-exp (get-current-env)))))))

The s-expression could draw on any of the environment here, so 
we can't optimize anything out of the environment. We can achieve
the desired effect by writing:

(defun wierd-function (s-expression)
  (eval `(block here
          (tagbody :tag
            (let ((x (foo s-expression)))
             (labels ((bar (y) (+ x y)))
                ,@s-exp))

Which is probably just about as good as the compiler could do anyway
and doesn't use any environments.


...mike beckerle
Gold Hill Computers



    



∂24-Nov-86  1300	sandra%utah-orion@utah-cs.arpa 	hash table question    
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 24 Nov 86  12:59:06 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
	id AA19611; Mon, 24 Nov 86 14:00:13 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
	id AA21161; Mon, 24 Nov 86 14:00:10 MST
Date: Mon, 24 Nov 86 14:00:10 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Message-Id: <8611242100.AA21161@utah-orion.ARPA>
Subject: hash table question
To: common-lisp@su-ai.arpa

Is hashing supposed to "work" if destructive operations are performed on
the hashed object, or is the hash index computed for an object a function
of what's "in" the object rather than the object itself?  As an example,
does this bit of code always return true?

(let* ((cons  (cons 'a 'b))
       (before  (sxhash cons))
       (after   (sxhash (rplaca cons 'foobar))))
      (eql before after))

-Sandra
-------

∂24-Nov-86  1543	DLW@ALDERAAN.SCRC.Symbolics.COM 	hash table question   
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 24 Nov 86  15:43:14 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 23873; Mon 24-Nov-86 18:41:14 EST
Date: Mon, 24 Nov 86 18:39 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: hash table question
To: sandra%utah-orion@UTAH-CS.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <8611242100.AA21161@utah-orion.ARPA>
Message-ID: <861124183912.0.DLW@CHICOPEE.SCRC.Symbolics.COM>

No, it doesn't always return true.  sxhash is an "equal" hash, returning
the same value for equal structures, even if they're not eq.  So the
idea is that it does a tree walk and computes its number out of what it
finds in the leaves.  Since you've changed a leaf and it is no longer
"equal" to what it used to be, it can have a new sxhash value, and
probably does.  This could have been spelled out in more detail in CLtL.

∂24-Nov-86  1630	sandra%utah-orion@utah-cs.arpa 	Re: hash table question
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 24 Nov 86  16:30:28 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
	id AA28782; Mon, 24 Nov 86 17:31:32 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
	id AA22562; Mon, 24 Nov 86 17:31:28 MST
Date: Mon, 24 Nov 86 17:31:28 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Message-Id: <8611250031.AA22562@utah-orion.ARPA>
Subject: Re: hash table question
To: Daniel L. Weinreb <DLW@alderaan.scrc.symbolics.com>
Cc: sandra%utah-orion@utah-cs.arpa, common-lisp@su-ai.arpa
In-Reply-To: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>, Mon, 24 Nov 86 18:39 EST

    Date: Mon, 24 Nov 86 18:39 EST
    From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>

    No, it doesn't always return true.  sxhash is an "equal" hash, returning
    the same value for equal structures, even if they're not eq.

Fine.  So what happens if the cons I just clobbered was being used as a
key in an "eq" hash table?  Certainly the original cons is still "eq" to 
itself after it's been clobbered.  Does this mean that an "eq" hash table
*can't* look at the contents of an object to compute a hash index?

(Actually, I can't think of any reason why one would *want* to perform
destructive operations on an object that is being used as a hash key, and 
would be happy to see this made "an error".)

-Sandra
-------

∂24-Nov-86  1725	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: hash table question
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 24 Nov 86  17:24:53 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 8947; Mon 24-Nov-86 20:21:45 EST
Date: Mon, 24 Nov 86 20:21 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: hash table question
To: Sandra J Loosemore <sandra%utah-orion@UTAH-CS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8611250031.AA22562@utah-orion.ARPA>
Message-ID: <861124202145.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 24 Nov 86 17:31:28 MST
    From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)

	Date: Mon, 24 Nov 86 18:39 EST
	From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>

	No, it doesn't always return true.  sxhash is an "equal" hash, returning
	the same value for equal structures, even if they're not eq.

    Fine.  So what happens if the cons I just clobbered was being used as a
    key in an "eq" hash table?  Certainly the original cons is still "eq" to 
    itself after it's been clobbered.  Does this mean that an "eq" hash table
    *can't* look at the contents of an object to compute a hash index?

    (Actually, I can't think of any reason why one would *want* to perform
    destructive operations on an object that is being used as a hash key, and 
    would be happy to see this made "an error".)

Suppose you're doing object-oriented programming, and you're an old-line
Lisp type who didn't make it past chapter 16 of CLtL, so you're
implementing your objects as conses.  Suppose the car of each cons is the
class, while the cdr of each cons is a property-list containing the local
state.  Then it would be quite reasonable to simultaneously use these
objects as :test 'eq hash-table keys and to perform destructive operations
on them.  The hashing, with :test 'eq, is using the object's identity as
the key, not using the object's contents as the key.

Thus I think the answer is that an "eq" hash table must not look at the
contents of an object when it hashes.  This could all be explained a whole
lot better in the manual (although the language on p.282, distinguishing
tables that hash on objects from tables that hash on tree structure, was
probably intended to be the explanation of this.)

∂24-Nov-86  1959	FAHLMAN@C.CS.CMU.EDU 	hash table question    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 86  19:59:27 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 24 Nov 86 22:58:59-EST
Date: Mon, 24 Nov 1986  22:58 EST
Message-ID: <FAHLMAN.12257634784.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   sandra%utah-orion@λutah-cs.arpa (Sandra J Loosemore)λ
Cc:   common-lisp@SU-AI.ARPA
Subject: hash table question
In-reply-to: Msg of 24 Nov 1986  16:00-EST from sandra%utah-orion at utah-cs.arpa (Sandra J Loosemore)


The hashing obviously will be messed up if you make destructive changes
that would alter the key under which things are hashed.  If you have
things stored in an EQ hash table and you change the datum in such a way
that the resulting objects are still EQ, things should still work.
Ditto if you have a EQUAL hash-table and change an entry in some way
that leaves it EQUAL to what it was before.  But if you sneak in and
change some list element from 3 to 'foo, the datum would no longer be
hashed properly and you can only win if you remove the datum and then
re-enter it into the hash-table.

-- Scott

∂24-Nov-86  2130	edsel!bhopal!jonl@navajo.stanford.edu 	type-of    
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 86  21:30:39 PST
Received: by navajo.stanford.edu; Mon, 24 Nov 86 21:28:23 PST
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
	id AA18138; Mon, 24 Nov 86 19:37:15 pst
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
	id AA05882; Mon, 24 Nov 86 19:36:21 PST
Date: Mon, 24 Nov 86 19:36:21 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8611250336.AA05882@bhopal.edsel.uucp>
To: navajo!sandra%utah-orion%utah-cs.arpa@navajo.stanford.edu
Cc: navajo!common-lisp%su-ai.arpa@navajo.stanford.edu
In-Reply-To: navajo!sandra%utah-orion@utah-cs.arpa's message of Wed, 19 Nov 86 09:11:01 MST
Subject: type-of




I had once thought of using TYPE-OF in the situation where I knew something
was a defstruct, but didn't know it's name/type;  however, just knowing that
something is an instance of a defstruct isn't a portable question right now.

Wasn't there a suggestion some time ago to have a new primitive function 
(or functions) for asking just these kinds of questions; i.e., is an object 
an instance of a structure defined without the :type option? and if so, what 
is its type name?

-- JonL --



∂24-Nov-86  2134	edsel!bhopal!jonl@navajo.stanford.edu 	hash table question  
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 86  21:34:10 PST
Received: by navajo.stanford.edu; Mon, 24 Nov 86 21:31:53 PST
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
	id AA18149; Mon, 24 Nov 86 19:39:31 pst
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
	id AA05886; Mon, 24 Nov 86 19:38:38 PST
Date: Mon, 24 Nov 86 19:38:38 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8611250338.AA05886@bhopal.edsel.uucp>
To: navajo!sandra%utah-orion%utah-cs.arpa@navajo.stanford.edu
Cc: navajo!common-lisp%su-ai.arpa@navajo.stanford.edu
In-Reply-To: navajo!sandra%utah-orion@utah-cs.arpa's message of Mon, 24 Nov 86 14:00:10 MST
Subject: hash table question



SXHASH has the contract of returning the same value on things that
"print alike".  This is implicit in the definition of sxhash that says:
"(equal x y) implies (= (sxhash x) (sxhash y))".  [See CLtL p285; also
the rule-of-thumb definition of EQUAL on p80.]

In your example, you have two items which are EQ but not EQUAL  [wait, 
read the rest before you judge this a contradiction].  Since they are
not equal, you can't expect them to have the same sxhash values.

The "two items" involved are two readings of the same "memory cell" at 
different times.  Since it is "the same memory cell", the two items are 
EQ;  but since an intrusive update occured during the time between the 
the two readings, "they" are no longer equal.

I find it somewhat curious that the following dumb definition perfectly 
satisfies  CLtL's requirements for SXHASH:
    (defun sxhash (x) 5)
and this definition would give you the before/after equivalence you are 
asking about.  How SXHASH differs fundamentally from the non-Common-Lisp 
function %POINTER available in ZetaLisp (or the LOC in Interlisp) is that
it must be independent of the address of a "memory cell", if any, holding 
the object.  CLtL tries to say this with language like "incarnation" and
"core image".  But, note how well the above dumb definition of sxhash 
satisfies this independence criterion!

On the other hand, 5 really isn't a very good hashing function.  It would
give very poor distribution if it were the basis of gethash -- all entries
would be in the same collision chain -- so it seems reasonable to descend 
into structures, even updatable structures, and compute a value that is, 
by design, potentially different after the object is updated.  The value 
returned by %POINTER (and LOC) wouldn't be affected by the RPLACA in your 
example, but they have other problems: 
  (1) they don't have the "equal[x,y] ==> sxhash[x] = sxhash[y]" property 
      mentioned above, and 
  (2) they don't remain the same over a relocating gc or a generational 
      scavenge.

If your point in asking this question is to examine the semantics of
EQ-type hash tables, then I think there is general consensus that
EQ-type tables don't simply mean that the "test" is EQ (as opposed
to EQUAL), but that the collision chains are based upon the object
"address" rather than the object "contents".  EQ-testing hash tables
with collision chains built the other way are certainly conceivable,
but one wonders what value they would be.  As I surmised in a previous 
note to this community, there is an unfortunate tendency to think that 
EQ-tables are "much faster" than EQUAL-tables, and the semantically 
wrong choice of :test is often made because of a mistaken conception 
about performance.   [A typical place where EQ-type tables *are* indeed 
the correct choice is in circularity detection, or possibly in macro-
expansion caches like MACROMEMO of MacLisp and CLISPARRAY of Interlisp].

This may also explain why there hasn't been a greater interest in
opening up an independent :sxhash argument to MAKE-HASH-TABLE;  EQ-type
tables are only really useful when it is the "address" of the key
that is important (rather than its contents), so suppying some other
:sxhash argument wouldn't be as useful as the built-in %POINTER.  Also,
most people are reluctant to admit %POINTER/LOC as a primitive in the
language since it is so deeply affected by memory-management strategy.


-- JonL --


∂25-Nov-86  2005	@MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU 	EVAL   
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Nov 86  20:05:28 PST
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM (DIAL|DIAL|4925473) by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 19003; 25 Nov 86 19:02:40-EST
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 45101; Tue 25-Nov-86 02:35:23-EST
Date: Tue, 25 Nov 86 02:36 est
Sender: mike@acorn
To: Alan@AI.AI.MIT.EDU
From: mike%acorn@mit-live-oak.arpa
Subject: EVAL
Cc: Fahlman@C.CS.CMU.EDU, Sean.Engelson@CAD.CS.CMU.EDU,
    common-lisp@SU-AI.ARPA

    Date: Sat, 22 Nov 86 17:32 EST
    From: Alan Bawden <Alan@AI.AI.MIT.EDU>
    
        Date: Thu, 20 Nov 1986  16:19 EST
        From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
        EVAL cannot easily be defined to work in the lexical environment in
        which it appears because that lexical environment is not around at
        runtime,....

    Right.  This demonstrates that LEXICAL-EVAL would have to be a new special
    form, rather than simply a function.

This same issue seems to come up over and over. Will someone tell
me what is wrong with the following argument:
    
I see no reason for "lexical-eval" or any eval with an environment arg.
The following is a trivial source-to-source you can use to get the 
effect of a lexical eval:

Suppose you wanted

(defun foo (s-exp)  
  (let ((x 5))
   (flet ((bar (y) (+ x y)))
    (block here
     (tagbody :there
        (lexical-eval s-exp))))))

this is exactly equivalent to:

(defun foo (s-exp)  
 (eval
 `(let ((x 5))
   (flet ((bar (y) (+ x y)))
    (block here
     (tagbody :there
       ,s-exp))))))

which does not use any "lexical-eval". Since the primary 
effect of the compiler is to eliminate lexical environments, any
lexical "stuff" surrounding a call to "lexical-eval" can't really
be compiled (not much anyway) since it all might be referred to
by the s-expression being evaled. This being the case, the
second form here, which just eval's the entire lexical scope,
is roughly as efficient. 

...mike beckerle
Gold Hill Computers.



∂25-Nov-86  2124	ALAN@AI.AI.MIT.EDU 	EVAL 
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Nov 86  21:24:09 PST
Date: Wed, 26 Nov 86 00:24:12 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  EVAL
To: mike%acorn@LIVE-OAK.LCS.MIT.EDU
cc: common-lisp@SU-AI.ARPA, Fahlman@C.CS.CMU.EDU,
    Sean.Engelson@CAD.CS.CMU.EDU
In-reply-to: Msg of Tue 25 Nov 86 02:36 est from mike%acorn at mit-live-oak.arpa
Message-ID: <123570.861126.ALAN@AI.AI.MIT.EDU>

    Date: Tue, 25 Nov 86 02:36 est
    From: mike%acorn at mit-live-oak.arpa
        Date: Sat, 22 Nov 86 17:32 EST
        From: Alan Bawden <Alan@AI.AI.MIT.EDU>
	...  This demonstrates that LEXICAL-EVAL would have to be a new
	special form, rather than simply a function.
    This same issue seems to come up over and over. Will someone tell
    me what is wrong with the following argument:...

I'm not quite sure what your proposed source transformation was supposed to
demonstrate.  How do you compile

  (defun bind-x-then-call-f (x f)
    (funcall f `(cons x x)))

given that anyone can do

  (bind-x-then-call-f 'foo #'lexical-eval)?

∂26-Nov-86  0834	KMP@YUKON.SCRC.Symbolics.COM 	EVAL 
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 26 Nov 86  08:34:07 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 126346; Wed 26-Nov-86 11:31:57 EST
Date: Wed, 26 Nov 86 11:31 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: EVAL
To: ALAN@AI.AI.MIT.EDU
cc: mike%acorn@LIVE-OAK.LCS.MIT.EDU, common-lisp@SU-AI.ARPA,
    Fahlman@C.CS.CMU.EDU, Sean.Engelson@CAD.CS.CMU.EDU
In-Reply-To: <123570.861126.ALAN@AI.AI.MIT.EDU>
Message-ID: <861126113148.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Wed, 26 Nov 86 00:24:12 EST
    From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
    Subject:  EVAL
    To: mike%acorn@LIVE-OAK.LCS.MIT.EDU
    cc: common-lisp@SU-AI.ARPA, Fahlman@C.CS.CMU.EDU,
	Sean.Engelson@CAD.CS.CMU.EDU
    In-reply-to: Msg of Tue 25 Nov 86 02:36 est from mike%acorn at mit-live-oak.arpa
    Message-ID: <123570.861126.ALAN@AI.AI.MIT.EDU>

	Date: Tue, 25 Nov 86 02:36 est
	From: mike%acorn at mit-live-oak.arpa
	    Date: Sat, 22 Nov 86 17:32 EST
	    From: Alan Bawden <Alan@AI.AI.MIT.EDU>
	    ...  This demonstrates that LEXICAL-EVAL would have to be a new
	    special form, rather than simply a function.
	This same issue seems to come up over and over. Will someone tell
	me what is wrong with the following argument:
	    
	I see no reason for "lexical-eval" or any eval with an environment arg.
	The following is a trivial source-to-source you can use to get the 
	effect of a lexical eval:
	
	Suppose you wanted
	
	(defun foo (s-exp)  
	  (let ((x 5))
	   (flet ((bar (y) (+ x y)))
	    (block here
	     (tagbody :there
		(lexical-eval s-exp))))))
	
	this is exactly equivalent to:
	
	(defun foo (s-exp)  
	 (eval
	 `(let ((x 5))
	   (flet ((bar (y) (+ x y)))
	    (block here
	     (tagbody :there
	       ,s-exp))))))
	
	which does not use any "lexical-eval". Since the primary 
	effect of the compiler is to eliminate lexical environments, any
	lexical "stuff" surrounding a call to "lexical-eval" can't really
	be compiled (not much anyway) since it all might be referred to
	by the s-expression being evaled. This being the case, the
	second form here, which just eval's the entire lexical scope,
	is roughly as efficient. 

No, it's -roughly- equivalent to:

 (defun foo (s-exp)  
   (eval `(let ((s-exp ',s-exp))
	    (let ((x 5))
	      (flet ((bar (y) (+ x y)))
		(block here
		  (tagbody :there ,s-exp)))))))

and even then it doesn't address the issue of what happens if S-EXP 
contains code that destructively modifies the list structure in the 
object held by S-EXP. My rewrite, which at least appropriately binds
the variable S-EXP, makes that be well-behaved, which is not a
semantics-preserving transformation.

    I'm not quite sure what your proposed source transformation was supposed to
    demonstrate.  How do you compile

      (defun bind-x-then-call-f (x f)
	(funcall f `(cons x x)))

    given that anyone can do

      (bind-x-then-call-f 'foo #'lexical-eval)?

Right. Your remark about how this could be done as a special form
thwarts the ability to do this (since you can't do #'<special-form>)
and hides the potential problem in a fortuitous way. The real issue,
of course, is that this is the power people -want-. They want things
like EVAL-IN-CLOSURE, which are the problemsome cases, because the
introduction of such into the language ties the hands of the compiler
and doesn't allow any optimization.

I think Mike's intent is correct, though, in that the situations where
you might want LEXICAL-EVAL in cases that are constrained adequately so
as not to break the language are handled adequately by his suggested
rewrite using EVAL. The cases that are not handled by that rewrite --
and not at all by coincidence -- are the cases which strike fear in the
hearts of compiler maintainers everywhere.

Moreover, using LEXICAL-EVAL invites many of the name collision problems
that the move to lexical scoping did away with. 
(DEFUN F (X Y) (+ X (EVAL Y))) 
used to be a problem in dynamic lisps because the local X and Y would 
interfere with the EVAL (at least in the interpreter and also in some 
compilers). In a lexical Lisp, such as CL, the name collision problem 
doesn't happen. Allowing people to do LEXICAL-EVAL there is just asking 
for the same unwanted name collisions that we were trying to get away
with in CL.

I concur with those who have said we should explicitly document the 
rationale for the absence of this primitive in the next CL language spec.

∂26-Nov-86  0834	spe@cad.cs.cmu.edu 	Re:  EVAL 
Received: from CAD.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Nov 86  08:34:05 PST
Date: 26 Nov 1986 11:29-EST 
From: Sean.Engelson@cad.cs.cmu.edu
To: Alan Bawden <ALAN@AI.AI.MIT.EDU>
cc: common-lisp@su-ai.arpa
Subject: Re:  EVAL
Message-Id: <533406551/spe@cad.cs.cmu.edu>
In-Reply-To: Alan Bawden's mail message of Wed, 26 Nov 86 00:24:12 EST

    >Date: Wed, 26 Nov 86 00:24:12 EST
    From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
    Subject:  EVAL

    I'm not quite sure what your proposed source transformation was supposed to
    demonstrate.  How do you compile
    
      (defun bind-x-then-call-f (x f)
        (funcall f `(cons x x)))
    
    given that anyone can do
    
      (bind-x-then-call-f 'foo #'lexical-eval)?

Yes, but given lexical-eval as a special form, you couldn't do that.

Perhaps lexical-eval could substitute lexical values for the variables
in its argument, then eval the result?

	-Sean-

∂26-Nov-86  1308	@ACORN.CS.ROCHESTER.EDU,@CASHEW.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU 	eval and other topics    
Received: from UR-ACORN.ARPA by SAIL.STANFORD.EDU with TCP; 26 Nov 86  13:07:58 PST
Received: from CASHEW.CS.ROCHESTER.EDU (CASHEW.CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 2622; 26 Nov 86 15:49:21 EST
Date: Wed, 26 Nov 86 15:50 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: eval and other topics
To: common-lisp@su-ai.arpa
cc: miller@ACORN.CS.ROCHESTER.EDU
Message-ID: <861126155002.1.MILLER@CASHEW.CS.ROCHESTER.EDU>
Sender: miller@ACORN.CS.ROCHESTER.EDU
Reply-To: miller@ACORN.CS.ROCHESTER.EDU
Organization: University of Rochester, Department of Computer Science
Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627
Phone: 716-275-7747

A large number of arguments against doing feature X for a while have been
along the lines of:

We shouldn't do feature X because then the compiler becomes harder, and
couldn't optimize the code as much.

While this may certainly be true (though it is more likely that the compiler
would have to detect the use of feature X and THEN not optimize the code as
much), I think it completely avoids the much deeper issue.

I am a user of lisp. I am not a compiler writer (now). I don't CARE if such
and so is easily compilable. I use lisp because it lets me express my ideas
more easily than other languages do. If we stifle the growth of CL toward the
lisp USER's needs, we will have a very fast, very compilable language that no
one will want to use.

I think that the questions that need to be asked when feature X is proposed is

1) is it a real problem? is there a simple mechanism that already exists to
address the problem? If the proposal is syntactic sugar is it of the form that
will allow program writers greater perspicuity?

2) does the proposed solution actually address the problem generically, or
does it only address some instance?

3) can the solution be implemented at all?

4) is it reasonably upwards-compatible with the existing language? (not
necessarily existing implementations). If not, is the scope of the change
relatively small (will not require substantial rewrite of existing USER code,
and/or the rewrite involved could be handled via a simple text
transformation).

5) has the proposed solution actually been tried? Has it actually helped users
who have run accross the problem? Does it otherwise constrain them? Is it
intuitive? (i.e. is it something that seems to "fit" the language - nebulous I
know, but this is an intuitive description too. Something like is it in the
style of Lisp.)

If the answers to the above are satisfactory, then I think there is a
reasonably good case for adding the feature to the language. Minor
difficulties like requiring smarter compilers, substantial rewrites to
existing compilers, etc. is a complete side issue, I think. Mostly because if
adding feature X allows a reasonable increase in USER productivity, who cares
how much time it takes the COMPILER writer to implement it - that time is
amortized over all the users who are now saving time with the new feature (or
at least able to express themselves more clearly in CL, or whatever).

Flames? Comments?

Brad Miller

PS: I bring this up because I mentioned the EVAL thing privately to Fahlman a
few months ago back when he was controlling new discussion, and basically got
back his original posting on the subject. While I certainly concur that a
lexical eval is not a particularly good idea as far as a compiler writer is
concerned (because it is very hard, and very inefficient), I think it is a
TERRIFIC idea for USERS. I've needed the functionality several times, and each
workaround is a total hack that has to be explaned in about a page of extra
documentation so the next poor slob that has to maintain my code can figure
out why I wrote such dreadful code in the first place (and what it does).
------
miller@rochester.arpa
miller@ur-acorn.arpa

∂26-Nov-86  1407	@WAIKATO.S4CC.Symbolics.COM:KMP@STONY-BROOK.SCRC.Symbolics.COM 	eval and other topics
Received: from [128.81.51.90] by SAIL.STANFORD.EDU with TCP; 26 Nov 86  14:06:58 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by WAIKATO.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 77582; Wed 26-Nov-86 17:05:04 EST
Date: Wed, 26 Nov 86 17:04 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: eval and other topics
To: miller@ACORN.CS.ROCHESTER.EDU
cc: kmp@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: <861126155002.1.MILLER@CASHEW.CS.ROCHESTER.EDU>
Message-ID: <861126170437.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Wed, 26 Nov 86 15:50 EST
    From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
    
    ... While I certainly concur that a lexical eval is not a particularly good
    idea as far as a compiler writer is concerned (because it is very hard, and
    very inefficient), I think it is a TERRIFIC idea for USERS. I've needed the 
    functionality several times, and each workaround is a total hack that has to be
    explained in about a page of extra documentation so the next poor slob that has
    to maintain my code can figure out why I wrote such dreadful code in the first
    place (and what it does). ...

I (and I'm sure others on this list) would be very interested to see a sketch,
explanation, or example of a place where you think LEXICAL-EVAL was essential.
Personally, I can think of no places (other than in debuggging or situations
closely related to debugging) where it was either essential or even appropriate.

I seriously doubt that I can be convinced that it is a "terrific" idea for
users in any case. The whole point of lexicality is to allow static analysis.
The whole-point of LEXICAL-EVAL is to allow a Turing-powerful piece of code
to modify the lexical environment in arbitrary ways, potentially thwarting
many (probably most) useful kinds of static analysis which one might contemplate.
The compiler is not pathological here -- any tool which tried to do program
understanding (including macros, translators, optimizers, and human programmers)
would have to expect trouble in the face of this primitive. I don't find this
prospect "terrific".

∂26-Nov-86  1734	ALAN@AI.AI.MIT.EDU 	EVAL 
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Nov 86  17:34:07 PST
Date: Wed, 26 Nov 86 20:34:26 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  EVAL
To: common-lisp@SU-AI.ARPA
Message-ID: <123881.861126.ALAN@AI.AI.MIT.EDU>

    Date: 26 Nov 1986 11:29-EST 
    From: Sean.Engelson at cad.cs.cmu.edu
        Date: Wed, 26 Nov 86 00:24:12 EST
        From: Alan Bawden <Alan at AI.AI.MIT.EDU>
        ...  How do you compile...
    Yes, but given lexical-eval as a special form, you couldn't do that.

Which is exactly why my original message said:

    	    Date: Sat, 22 Nov 86 17:32 EST
    	    From: Alan Bawden <Alan at AI.AI.MIT.EDU>
    	    ...  This demonstrates that LEXICAL-EVAL would have to be a new
    	    special form, rather than simply a function.

    Perhaps lexical-eval could substitute lexical values for the variables
    in its argument, then eval the result?

Perhaps it could use the more or less the same evaluator the interpreter
uses, passing it an environment constructed by the compiler from the
lexically apparent entities surrounding the occurrence of the LEXICAL-EVAL
form.

In painful detail:

(defmacro lexical-eval (foo)
  `(sys:internal-lexical-eval ,foo (sys:the-surrounding-lexical-environment)))

Where SYS:INTERNAL-LEXICAL-EVAL is an ordinary function that is an
implementation dependent entry into the interpreter, and
SYS:THE-SURROUNDING-LEXICAL-ENVIRONMENT is a special form that causes the
compiler to create and return an implementation dependent datastructure
that the interpreter can use to access the variables, block names, tagbody
tags, and macro definitions apparent at that location.

It is -incorrect- that an occurrence of LEXICAL-EVAL hopelessly cripples the
compiler's ability to compile the surrounding code.  A possible expansion
of (SYS:THE-SURROUNDING-LEXICAL-ENVIRONMENT) might be:

(list (list :read 'x (lambda () x))
      (list :setq 'x (lambda (v) (setq x v)))
      (list :read 'y (lambda () y))
      (list :setq 'y (lambda (v) (setq y v)))
      (list :return-from 'top (lambda (v) (return-from top v)))
      (list :go 'loop (lambda () (go loop))))

where X and Y are the lexically apparent variables, and TOP and LOOP are
the lexically apparent block names and tagbody tags respectively.  This
datastructure would give the interpreter all the access it needs to the
environment in question.  I hope that most Common Lisp compilers can
-already- successfully compile the above expression.

Yes, I have ignored a couple of issues here (like the representation of the
macro definition environment, and the possibility of returning multiple
values from a block), but I don't see any fatal flaws, only complications
that don't belong in a brief message.

I'm still not advocating anything, I'm just trying to make sure we all know
what we are flaming about.

∂28-Nov-86  1341	@MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU 	EVAL   
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Nov 86  13:41:19 PST
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM (DIAL|DIAL|4925473) by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 19439; 28 Nov 86 16:30:19-EST
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 45600; Wed 26-Nov-86 11:09:57-EST
Date: Wed, 26 Nov 86 11:10 est
Sender: mike@acorn
To: ALAN@AI.AI.MIT.EDU
From: mike%acorn@mit-live-oak.arpa
Subject: EVAL
Cc: mike%acorn@LIVE-OAK.LCS.MIT.EDU, common-lisp@SU-AI.ARPA,
    Fahlman@C.CS.CMU.EDU, Sean.Engelson@CAD.CS.CMU.EDU

    Date: Wed, 26 Nov 86 00:24:12 EST
    From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
    
        Date: Tue, 25 Nov 86 02:36 est
        From: mike%acorn at mit-live-oak.arpa
            Date: Sat, 22 Nov 86 17:32 EST
            From: Alan Bawden <Alan@AI.AI.MIT.EDU>
    	...  This demonstrates that LEXICAL-EVAL would have to be a new
    	special form, rather than simply a function.
        This same issue seems to come up over and over. Will someone tell
        me what is wrong with the following argument:...
    
    I'm not quite sure what your proposed source transformation was supposed to
    demonstrate.  How do you compile
    
      (defun bind-x-then-call-f (x f)
        (funcall f `(cons x x)))
    
    given that anyone can do
    
      (bind-x-then-call-f 'foo #'lexical-eval)?
    

I just write

(defun bind-x-then-call-f (x f)
   (eval `(funcall ,f '(cons ,x ,x)))

and do this 

  (bind-x-then-call-f 'foo #'eval) 

instead, which is to say I don't bother compiling it at all.
I see no difference semantically here. Is there a 
tougher example, possibly involving closures?


... mike beckerle.


    



∂30-Nov-86  0026	ALAN@AI.AI.MIT.EDU 	EVAL 
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Nov 86  00:26:49 PST
Date: Sun, 30 Nov 86 03:26:23 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject:  EVAL
To: Common-Lisp@SU-AI.ARPA
In-reply-to: Msg of Wed 26 Nov 86 11:10 est from mike%acorn at mit-live-oak.arpa
Message-ID: <124500.861130.ALAN@AI.AI.MIT.EDU>

    Date: Wed, 26 Nov 86 11:10 est
    From: mike at acorn
        Date: Wed, 26 Nov 86 00:24:12 EST
        From: Alan Bawden <ALAN at AI>
        ...  How do you compile
        
          (defun bind-x-then-call-f (x f)
            (funcall f `(cons x x)))...

    I just write

    (defun bind-x-then-call-f (x f)
       (eval `(funcall ,f '(cons ,x ,x)))...

I presume you mean this to be

  (defun bind-x-then-call-f (x f)
    (eval `(funcall ',f '(cons ',x ',x)))).

The quotes prevent an extra evaluation I doubt you intended.

You can't rewrite BIND-X-THEN-CALL-F this way because before your rewrite
it was the case that:

  (bind-x-then-call-f 7 #'cadr)  ==>  X

but afterwords:

  (bind-x-then-call-f 7 #'cadr)  ==>  (QUOTE 7)


∂01-Dec-86  0954	@ACORN.CS.ROCHESTER.EDU,@CASHEW.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU 	eval and other topics    
Received: from UR-ACORN.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 86  09:53:55 PST
Received: from CASHEW.CS.ROCHESTER.EDU (CASHEW.CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 2690; 1 Dec 86 12:51:52 EST
Date: Mon, 1 Dec 86 12:53 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: eval and other topics
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
cc: Common-Lisp@SU-AI.ARPA, miller@ACORN.CS.ROCHESTER.EDU
In-Reply-To: <861126170437.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <861201125315.0.MILLER@CASHEW.CS.ROCHESTER.EDU>
Sender: miller@ACORN.CS.ROCHESTER.EDU
Reply-To: miller@ACORN.CS.ROCHESTER.EDU
Organization: University of Rochester, Department of Computer Science
Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627
Phone: 716-275-7747

    Date: Wed, 26 Nov 86 17:04 EST
    From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>

	Date: Wed, 26 Nov 86 15:50 EST
	From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
    
	... While I certainly concur that a lexical eval is not a particularly good
	idea as far as a compiler writer is concerned (because it is very hard, and
	very inefficient), I think it is a TERRIFIC idea for USERS. I've needed the 
	functionality several times, and each workaround is a total hack that has to be
	explained in about a page of extra documentation so the next poor slob that has
	to maintain my code can figure out why I wrote such dreadful code in the first
	place (and what it does). ...

    I (and I'm sure others on this list) would be very interested to see a sketch,
    explanation, or example of a place where you think LEXICAL-EVAL was essential.
    Personally, I can think of no places (other than in debuggging or situations
    closely related to debugging) where it was either essential or even appropriate.
	
    [....]

Well, it's been a while since I gave up on doing things that way, so I don't
have any code handy, but the idea was that given lexical scoping, one can then
define functions with precisely defined scope rules, e.g. using flet. However,
once I had defined these functions, I could not use eval on them, since they
were invisible to the dynamic environment. The details of why I was trying to
do this (seemingly) reasonable thing are hazy, but as I recall in one case,
there were some functions (axioms for a horne clause theorem prover) that were
evaluated normally by some routines that would 'interpret' the language by
calling the routines by prefixing them with a string (to prevent name
conflicts with CL functions). This was the hack - the better solution was to
temporarily redefine these functions using flet so the threaded language could
be interpreted directly, without globally redefining the lisp function. Since
which function had to be called varied somewhat by context (modeled by which
function actually did the interpretation) the same name could serve for each
of these flets - since lexical scoping would not be ambiguous. Instead, with
all functions globably defined, different strings were hacked into the
pseudo-function call names, and then the (new) lisp stream could be eval'd.

There may well be a better hack than this (actually, I'm not the one who ended
up writing it, but I suppose I am responsible for it), however, I don't think
anything might have surpassed the simple and clean elegance of a lexical-eval.

Brad Miller
------
miller@rochester.arpa
miller@ur-acorn.arpa

∂01-Dec-86  1239	spe@cad.cs.cmu.edu 	Packages  
Received: from CAD.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 86  12:39:12 PST
Date:  1 Dec 1986 15:34-EST 
From: Sean.Engelson@cad.cs.cmu.edu
To: common-lisp@su-ai
Subject: Packages
Message-Id: <533853280/spe@cad.cs.cmu.edu>

This idea has probably been brought up before, but as a solution to the
'packages problem', without really any loos of functionality, I propose
the following:  To have symbols be universal, but their values and
function definitions (maybe extended to all properties) be
package-tied.  Thus symbols are symbols and are EQ to each other in all
the expectable cases, etc.., but we have the functionality of differing
name spaces.  This could be implemented by having a PACKAGE 'property'
attached to different values of a symbol's property..

∂01-Dec-86  1326	@MIT-LIVE-OAK.ARPA:Soley@MIT-XX.ARPA 	Packages    
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 86  13:26:26 PST
Received: from CHERRY.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 19829; Mon 1-Dec-86 16:25:08-EST
Date: Mon, 1 Dec 86 16:25 EST
From: Soley@MIT-XX.ARPA
Subject: Packages
To: Sean.Engelson@cad.cs.cmu.edu, common-lisp@SU-AI.ARPA
In-Reply-To: <533853280/spe@cad.cs.cmu.edu>
Message-ID: <861201162542.1.SOLEY@CHERRY.LCS.MIT.EDU>

    Date:  1 Dec 1986 15:34-EST 
    From: Sean.Engelson@cad.cs.cmu.edu
    To: common-lisp@su-ai
    Subject: Packages
    Message-Id: <533853280/spe@cad.cs.cmu.edu>

    This idea has probably been brought up before, but as a solution to the
    'packages problem', without really any loos of functionality, I propose
    the following:  To have symbols be universal, but their values and
    function definitions (maybe extended to all properties) be
    package-tied.  Thus symbols are symbols and are EQ to each other in all
    the expectable cases, etc.., but we have the functionality of differing
    name spaces.  This could be implemented by having a PACKAGE 'property'
    attached to different values of a symbol's property..

Pardon, but let me be the first to barf.  Blech.

Are you saying that (eql #'FOO:QUUX #'BAR:QUUX) => NIL, but
(eql 'FOO:QUUX 'BAR:QUUX) => T ??

First (to say it politely) I don't see how your solution solves
anything.  Second, the more obvious solution of making
(EQL 'FOO:QUUX 'BAR:QUUX) => T is (1) uneconomical, and (2) unteachable
in the presence of (eql #'FOO:QUUX #'BAR:QUUX) => NIL.

I don't think there's really a problem, and, if there is, I don't think
this solves it.  (Sorry for the legal reasoning in that sentence).

	-- Richard Soley

∂01-Dec-86  1350	spe@cad.cs.cmu.edu 	Re: Packages   
Received: from CAD.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 86  13:47:34 PST
Date:  1 Dec 1986 16:40-EST 
From: Sean.Engelson@cad.cs.cmu.edu
To: Soley@MIT-XX.ARPA, common-lisp@su-ai
Subject: Re: Packages
Message-Id: <533857218/spe@cad.cs.cmu.edu>

	Date: Mon, 1 Dec 86 16:25 EST
	From: Soley@MIT-XX.ARPA
	Subject: Packages
	To: Sean.Engelson@cad.cs.cmu.edu, common-lisp@SU-AI.ARPA

		.......

	Are you saying that (eql #'FOO:QUUX #'BAR:QUUX) => NIL, but (eql
	'FOO:QUUX 'BAR:QUUX) => T ??  

	First (to say it politely) I don't see how your solution solves
	anything.  Second, the more obvious solution of making (EQL 'FOO:QUUX
	'BAR:QUUX) => T is (1) uneconomical, and (2) unteachable in the
	presence of (eql #'FOO:QUUX #'BAR:QUUX) => NIL.  



I guess my idea wasn't well-worded.  Let me try to clarify.  I would
remove any association of symbols to packages, thus there would be no
FU:QUUX, there would just be QUUX.  However, QUUX's value and function
would be attached to packages, thus we could speak of QUUX's function
in package FU, or QUUX's value in package BAR.  Thus we have separate
name spaces for functions and values, without the ridiculosity of
having to do interning, or string coercion whenever comparison of
symbols is needed.

		-Sean Engelson-

∂01-Dec-86  1434	@MIT-LIVE-OAK.ARPA:Soley@MIT-XX.ARPA 	Re: Packages
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 86  14:32:56 PST
Received: from CHERRY.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 19849; Mon 1-Dec-86 17:31:31-EST
Date: Mon, 1 Dec 86 17:32 EST
From: Soley@MIT-XX.ARPA
Subject: Re: Packages
To: Sean.Engelson@cad.cs.cmu.edu, common-lisp@SU-AI.ARPA
In-Reply-To: <533857218/spe@cad.cs.cmu.edu>
Message-ID: <861201173212.2.SOLEY@CHERRY.LCS.MIT.EDU>

    Date:  1 Dec 1986 16:40-EST 
    From: Sean.Engelson@cad.cs.cmu.edu

	    Date: Mon, 1 Dec 86 16:25 EST
	    From: Soley@MIT-XX.ARPA

	    Are you saying that (eql #'FOO:QUUX #'BAR:QUUX) => NIL, but (eql
	    'FOO:QUUX 'BAR:QUUX) => T ??  

    I guess my idea wasn't well-worded.  Let me try to clarify.  I would
    remove any association of symbols to packages, thus there would be no
    FU:QUUX, there would just be QUUX.  However, QUUX's value and function
    would be attached to packages, thus we could speak of QUUX's function
    in package FU, or QUUX's value in package BAR.  Thus we have separate
    name spaces for functions and values, without the ridiculosity of
    having to do interning, or string coercion whenever comparison of
    symbols is needed.

I don't see what this solves.  You still need to /talk about/ functions
attached to symbols in other packages, in order to apply them.  I was
just using "FOO:QUUX" as that syntax; are you suggesting something like

	((function QUUX FOO) 1 2 3)

for the current (FOO:QUUX 1 2 3) ??  And if you want the A package value
of the symbol B, instead of A:B you have to type (value-of B 'A) or
something?  That's just syntax.  And there're separate
function/value/property slots for each symbol for each known package?

I think this makes the world more complex, not simpler.  I think in most
cases you don't want the name of one of your symbols to be eq to another
symbol that just happens to have the same name, but is in another
package.

	-- Richard Soley

∂01-Dec-86  1847	DALY@IBM.COM 	progv and dynamic variables    
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 1 Dec 86  18:47:08 PST
Date: 1 December 1986, 13:53:21 EST
From: "Timothy P. Daly"  <DALY@ibm.com>
To:   common-lisp@su-ai.arpa
Message-Id: <120186.135322.daly@ibm.com>
Subject: progv and dynamic variables

What should the following do:

 (defun foo (a s v)
  (progv s v (print a)))

 with:

 (foo 3 '(a) '(4))

 The actual result is 3 but from the book description of PROGV
 on p112 it appears that it should be 4. I have tried this on
 3 different common lisps with the same result.

∂01-Dec-86  1901	BROOKS%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	progv and dynamic variables 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 86  19:01:22 PST
Date: Mon, 1 Dec 1986  22:04 EST
Message-ID: <BROOKS.12259459812.BABYL@MIT-OZ>
From: BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To:   "Timothy P. Daly" <DALY@IBM.COM>
Cc:   common-lisp@SU-AI.ARPA
Subject: progv and dynamic variables
In-reply-to: Msg of 1 Dec 1986 13:53:21 EST from Timothy P. Daly <DALY at ibm.com>


    What should the following do:

     (defun foo (a s v)
      (progv s v (print a)))

     with:

     (foo 3 '(a) '(4))

     The actual result is 3 but from the book description of PROGV
     on p112 it appears that it should be 4. I have tried this on
     3 different common lisps with the same result.

The `a' in (print a) refers to the lexical variable `a' named in
foo's parameter list. The progv binds the dynamic variable `a'.
You can get the answer to be 4 a number of ways:

1.
 (defvar a)

 (defun foo (a s v)
  (progv s v (print a)))

This makes all references to `a' pervasively dynamic so even
the call to foo binds the dynamic `a'.

2.
 (defun foo (a s v)
  (declare (special a))
  (progv s v (print a)))

Has the same effect on foo, but other functions can use a lexically
scoped `a'.

3.
 (defun foo (a s v)
  (progv s v
    (declare (special a))
    (print a)))

The binding of `a' during the call to foo is lexical, but the
reference in (print a) is dynamic.

∂01-Dec-86  1945	DLW@ALDERAAN.SCRC.Symbolics.COM 	progv and dynamic variables
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 1 Dec 86  19:45:44 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25355; Mon 1-Dec-86 22:43:50 EST
Date: Mon, 1 Dec 86 22:46 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: progv and dynamic variables
To: DALY%ibm.com@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <120186.135322.daly@ibm.com>
Message-ID: <861201224611.0.DLW@CHICOPEE.SCRC.Symbolics.COM>

Juse in case the sense of Rod's reply was not completely clear:  the
answer is that it is supposed to be 3, not 4, so the implementations
were correct.  PROGV always does a "special-bind" operation, regardless
of what's going on with declarations.  The reference to "a" is a lexical
reference because there are no declarations making it a dynamic
reference.

∂01-Dec-86  2227	franz!ficl!jkf@ucbarpa.Berkeley.EDU 	Re: progv and dynamic variables  
Received: from UCBARPA.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 86  22:26:53 PST
Received: by ucbarpa.Berkeley.EDU (5.57/1.18)
	id AA19366; Mon, 1 Dec 86 22:27:04 PST
Received: from ficl by franz (5.5/3.14)
	id AA02598; Mon, 1 Dec 86 22:16:22 PST
Received: by ficl (5.5/3.14)
	id AA27858; Mon, 1 Dec 86 22:17:00 PST
From: franz!ficl!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <ficl!jkf>
Message-Id: <8612020617.AA27858@ficl>
To: BROOKS%OZ.AI.MIT.EDU@xx.lcs.mit.edu
Cc: DALY@ibm.com, common-lisp@su-ai.arpa
Subject: Re: progv and dynamic variables 
In-Reply-To: Your message of Mon, 01 Dec 86 22:04:00 EST.
             <BROOKS.12259459812.BABYL@MIT-OZ> 
Date: Mon, 01 Dec 86 22:16:58 PST


>> 3.
>>  (defun foo (a s v)
>>   (progv s v
>>     (declare (special a))
>>     (print a)))

>> The binding of `a' during the call to foo is lexical, but the
>> reference in (print a) is dynamic.

Aren't declarations illegal before a progv body?

-john foderaro

∂01-Dec-86  2250	BROOKS%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	progv and dynamic variables 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 86  22:47:24 PST
Date: Tue, 2 Dec 1986  01:50 EST
Message-ID: <BROOKS.12259501038.BABYL@MIT-OZ>
From: BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To:   franz!ficl!jkf@UCBARPA.BERKELEY.EDU (John Foderaro)
Cc:   common-lisp@SU-AI.ARPA
Subject: progv and dynamic variables 
In-reply-to: Msg of 2 Dec 1986  01:16-EST from franz!ficl!jkf at ucbarpa.Berkeley.EDU (John Foderaro)


    Aren't declarations illegal before a progv body?

    -john foderaro


Pages 153-154 seem to imply so. I guess the CL I have in front of
me has some extensions. 

∂02-Dec-86  0928	jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	Re: Packages   
Received: from CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 2 Dec 86  09:28:41 PST
Received: from aiva.edinburgh.ac.uk by mv1.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa00737; 2 Dec 86 17:07 WET
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Tue, 2 Dec 86 16:58:15 GMT
Message-Id: <21159.8612021658@aiva.ed.ac.uk>
To: Sean.Engelson@cad.cs.cmu.edu, Soley@xx.lcs.mit.edu, common-lisp@su-ai.arpa
Subject: Re: Packages

I believe Sean's suggestion is in intention equivalent to the proposal that
packages be replaced by something like Scheme's environments (T's locales).
That is, there would be only one symbol X, but it would have different
values in different environments.  This is the sort of thing that happens
already, e.g. with closures.  The difference is that these environments
would be separate data objects from which you can import values (rather
than their names), etc.

Several people have already expressed the opinion that the environment
approach is insufficiently developed to serve as a replacement for
packages.  That may be so.  In any case, packages and environemnts are more
or less independent since reference with respect to packages is resolved at
read time and with respect to environments at some eval-like time.  So it
should be possible to experiment with environment-like approaches in
Common Lisp.

If anyone from the Scheme would like to explain how environments can be
implemented efficiently I'd be interested, but perhaps this list isn't the
best place to discuss it?

-- Jeff

∂02-Dec-86  1844	jbarnett@nrtc 	Packages then and now    
Received: from NRTC.ARPA by SAIL.STANFORD.EDU with TCP; 2 Dec 86  18:43:46 PST
Date:     Tue, 2 Dec 86 18:25:23 PST
From:     Jeff Barnett <jbarnett@nrtc>
To:       common-lisp@SU-AI.ARPA
Subject:  Packages then and now

This note is in regargds to the recent conversation about packages.  First, a
few historical comments.  The first appearance in the LISP world was in LISP2
where global program pieces, e.g., special variables, functions, macros,
etc., where given a first and last name.  (The first name was an integer in
the range of 0 to 127.)  Symbols, then called identifiers, had only one
incarnation.  LISP2 was done in the early 1960's.  As far as I know, this
looked just like the mechansim used by IBM assemblers  from the
early-middle 1950's.  In both, there was a default package (first name) in
which to put definitions unless the name of the defined object included an
explicit  package.  Reference ambiguity was resolved, at compile time, by an
ordered list of package names.  If a symbol (rather than a full name) was
used, if there was a definition in the first package on the list it was used;
if not, the second one was tried, and so on.  For the record, packages were
called sections and the first name was really written second.
	The last attempt at a development along these lines was an
implementation called CRISP done in the mid 1970's.  In CRISP, symbols and
names were different kinds of objects: SYMBOLP and NAMEP were different
predicates and no object satisfied both.  There were subtypes of name, e.g.,
variable, function, function with partially specified interface, etc.  The
mechanism was to protect system developers from each other; not to protect
the system from the users.  A name object had fields for its binding, type
information (as specifically as known), its print name (two symbols) and junk
for the GC.  A symbol had fields for its printname, property list, and system
property list.  The system property list located all name objects with this
primary name, i.e.,  all objects with this name in all the packages in which
it existed.  The property list was tree structured.  A node on the property
list was a 4-tuple: property name, property value, rest of property list, 
and inferior property list.  The property functions took a list of
indicators, e.g.,
     (GET 'foo 'semantics 'lexicon 'phonetics)
Usually, the names of the first property was the same as a package name.
Most programs only used a single indicator while the layers below it used
two. Though the qualification string could be indefinately nested, more than
two indicators were rare.  Further, the name qualification was only one deep
though it could have been generalized.  It was not for two reasons: (1) it
didn't seem necessary and (2) the default rule became very complex.  A
finally historical note, these systems were meant for Programmers (with a
capital P).  They were not meant to separate the unwashed from each other.
In fact it is clear that, without change they cannot do the whole job.
	As to the current state of affairs.  I don't like the present package
system very much.  I happen to like the distinction between symbols as
universals and names of program pieces.  Unfortunately, in this
standardization effort, a change as radical as this would imply is probably
misguided.  What I hope is that there will be a variety of implementations
that experiment with the issues that bridge naming, encapsulation, and
presentation.  I don't know of an entirely satisfactory solution.  Judging by
the recent flames, I see that no one else does either.  The work on object
style programming in LISP will effect the future.  Don't forget, that it is
another mechanism whose stated purpose is similar: namely to allow
development of different programs in the same environment AND development of
the same program by multiple contributors.

∂02-Dec-86  2113	Miller.pa@Xerox.COM 	Re: Packages then and now    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 86  21:13:46 PST
Received: from Salvador.ms by ArpaGateway.ms ; 02 DEC 86 20:54:20 PST
Date: 2 Dec 86 20:54 PST
Sender: Miller.pa@Xerox.COM
Subject: Re: Packages then and now
In-reply-to: Jeff Barnett <jbarnett@nrtc.ARPA>'s message of Tue, 2 Dec
 86 18:25:23 PST
To: jbarnett@nrtc.ARPA
cc: common-lisp@SU-AI.ARPA
From: Mark S. Miller <Miller.pa@Xerox.COM>
Message-ID: <861202-205420-3471@Xerox>

    Date: Tue, 2 Dec 86 18:25:23 PST
    From: Jeff Barnett <jbarnett@nrtc.ARPA>

    What I hope is that there will be a variety of implementations
    that experiment with the issues that bridge naming, encapsulation,
    and presentation.  I don't know of an entirely satisfactory
    solution.  Judging by the recent flames, I see that no one else
    does either.

What is non-satisfactory about T's scheme?


----- MarkM

∂02-Dec-86  2300	@REAGAN.AI.MIT.EDU:Henry@OZ.AI.MIT.EDU 	Common EVAL    
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 86  22:59:29 PST
Received: from SINATRA.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 14027; Wed 3-Dec-86 01:58:41 EST
Date: Wed, 3 Dec 86 01:58 EST
From: CFry@OZ.AI.MIT.EDU
Sender: Henry@OZ.AI.MIT.EDU
Subject: Common EVAL
To: Common-Lisp@SU-AI.ARPA
cc: Henry@OZ.AI.MIT.EDU
Message-ID: <861203015844.2.HENRY@SINATRA.AI.MIT.EDU>
Reply-To: HENRY@AI.AI.MIT.EDU



Common EVAL

Henry Lieberman and Christopher Fry


Abstract

We propose that the Common Lisp standard be extended by adding to the
language specification a short program, itself written in Common Lisp, to
implement the EVAL function.  The interpreters for every correct
implementation of Common Lisp would be required to match the semantics of
Common EVAL on valid Common Lisp expressions.  
It should treat other expressions as errors or as implementation dependent 
extensions.  There are
three cogent reasons for including a Common EVAL in the standard:
First, since EVAL fixes the meaning of Lisp programs, it would
insure uniformity of program semantics across implementations.
Second, it would aid validation efforts, since the behavior of a
particular implementation could always be compared to the behavior
of Common EVAL.  Third, it would facilitate the creation of debuggers
and other program-manipulating programs that could be ported across
Common Lisp implementations. 

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

One of the marvelous things about Lisp is that the language can be written in
itself.  In Lisp, programs can be data and data can be programs.  The
operation of the language itself can be described as a function written in
the very same language: the EVAL function.  Lisp advocates always point
with pride to this fact as a major reason for Lisp's superiority over
conventional languages.  It is why Lisp has traditionally supported the
best debugging environments.  It is why Lisp can be used to write the
program-manipulating programs which are essential in artificial
intelligence work, and in building advanced interactive programming
environments.

Sadly, this important advantage is becoming steadily eroded by some of the
modern production implementations of Lisp.  The quest for efficiency and
experimentation with esoteric programming constructs are leading to
non-standard implementations of Lisp interpreters that foil attempts
to make use of Lisp's self-descriptive capability.

With Common Lisp, we have a unique opportunity to insure that the
program-data equivalence which is one of Lisp's cornerstones remains
available as Lisp implementations proliferate.  But the English
description in the Steele book is not detailed enough to exclude semantic
deviations which frustrate serious developers of program-manipulating
programs.

Specifying the EVAL function as a Common Lisp program can provide a
concise, precise, and easily understood description which could serve as a guide for
implementors and a means by which to evaluate the results.  
Implementors would not be required to run the exact code for Common
EVAL in their implementation. 
They could provide another implementation, which may be more efficient or include
extra features, but they would be required to assure that their version matched the
semantics of Common EVAL.
Differences in behavior between a particular Lisp implementation and Common EVAL
would be evidence for violations of the Common Lisp standard.

Many advanced Lisp applications rely on the precise details of the operation of
EVAL.  Implementing a single-stepping debugger for Lisp code, for example,
requires imitating EVAL on Lisp expressions, while inserting display operations
and requesting input at events during evaluation.

Lisp's extensibility makes it ideal for defining embedded application-dependent
languages, which may even have a different control structure than Lisp's.  Often,
these languages need to "use Lisp" as a subset, call Lisp functions from code in
the other language, or even invoke foreign language code from Lisp code.  For
the interface to be smooth, the language designer must be able to depend on how
Lisp code is evaluated, perhaps including details such as variable environments
and function definitions.

Many programs which need to analyze Lisp programs statically require a "code
walker", a program that determines which subexpressions of a Lisp expression
represent code to be evaluated, and which represent data, like expressions which
appear inside a QUOTEd list.  Such code walkers, which separate the uses of
Lisp expressions as programs from uses as data, appear in virtually every Lisp
compiler.  Smart pretty-printers that print expressions according to their
semantics, indexers, or other "programmer's apprentice" tools need this, too.
Code walkers anticipate the action of EVAL on an expression, so they are
inextricably tied to EVAL's operation.

With Common EVAL, a designer of a program-manipulating program can base their
tools on the definition of Common EVAL rather than the details of a particular
Lisp implementation.
The implementor can then have confidence that the tools will work in all valid
implementations of Common Lisp.
This should significantly enhance Common Lisp's suitability for advanced applications.

The interpreters for MIT-descended Lisp Machines by Symbolics, LMI and TI 
show how production implementations have compromised Lisp semantics.  
Surprisingly, if you look at the system's definition of the EVAL
function, you will find that it only appears to be written in Lisp.  
It calls "subprimitives" which are special-cased by the compiler, compiling
into specialized microcode, motivated by an attempt to make the Lisp interpreter more
efficient.  
The subprimitives do things which, for example, violate the stack discipline of Lisp. 
The system's definition of EVAL cannot even be interpreted by EVAL itself!

Because of the additional complexity that machine-dependent efficiency hacks add to
the evaluator, it is no longer feasible to write an EVAL without subprimitives, and
have any confidence that the results will be equivalent to the system's EVAL.
If the code for the evaluator relies on subprimitives, it won't even be intelligible to
the human reader literate only in Lisp.

This is not to say that we are against subprimitives; obviously, they are necessary
for such functions as CAR and EQ.
The English description of the behavior of lowest level functions in the 
Steele book is adequate, as is the description of middle level functions like APPEND.
It is only when the complexity of something like EVAL is reached that 
divergence among implementations becomes a real problem.

Periodically, internal changes to a system's evaluator require changing any
imitative implementation.
For example, Symbolics recently changed the function cell of an interpreted function
from containing a lambda expression to SI:DIGESTED-LAMBDA, which necessitated
similar changes in any program which expected to interpret functions.
A standard EVAL would clarify what representations a user could rely on, and clarify
what representations an implementor could change without breaking system code
or affecting users. 

Another central problem is that "extensions" to the Lisp language may be 
implemented in the interpreter by low-level constructs that cannot
be directly implemented by a Lisp program.  While Common Lisp is
designed to permit extensions to the language, it should not allow
extensions which rely on microcode and other non-Lisp implementation techniques to 
change the basic semantics of the language.
Such extensions effectively prevent any program-manipulating
program written in Common Lisp from operating on code containing
the extensions. 

Spaghetti stacks in Interlisp are an example where an attempt to
implement non-standard programming constructs wreaks havoc with the
interpreter's semantics.  It is impossible for an Interlisp
user to write a stepping debugger capable of working on interpreted code
that uses spaghetti stacks.  
Common EVAL should provide well-defined points in the evaluation process at which
particular implementations could provide extensions, such as defining a new variety of
functional object.

How detailed should the Common EVAL implementation be?  Everyone knows
that it is possible to implement a wide range of meta-circular
interpreters ranging from a one-page interpreter in the vein of the
original Lisp 1.5 book, to one that is so detailed it specifies every bit
and would probably run to hundreds of pages.  Clearly, a middle course is
called for.  The interpreter should be the minimal size necessary
to specify the interpreter in terms of calls to Common Lisp functions.
It should probably take no more than ten pages to do this.  It should
be detailed enough to do things like specify the behavior of all
the special forms, but does not have to be so detailed as to
specify all the internal representations used by the evaluator.  

The interpreter may need a variety of helping functions to access
representations of data structures, for example lexical variable binding
environments.  To avoid constraining the freedom of implementors to choose
efficient representations for such data structures, Common EVAL could call
abstract functions whose implementation would not be prescribed by the
standard.  Every implementation could provide its own EXTEND-ENVIRONMENT
function, whose behavior would be specified by a description, in the
manner of the Steele book.  A simple Common Lisp implementation, for
example implementing environments as ALISTs, could be shown for
illustrative purposes without fixing the ALIST representation in every
Common Lisp implementation.

Finally, to illustrate the intent of our proposal more concretely, we present a
short segment of Lisp code for a skeleton Common EVAL.  Don't take this code
too literally -- we mean it only to illustrate the style and the level of detail
we would expect of the real Common EVAL, and as a springboard for
discussion.  

#| 

Some notes about the code:
- The LE package contains the lexical environment manipulator
   fns, many of which are yet to be written. If the CL community
   decides to provide advertised support for lexical environment functions,
   some of the functions here could be moved into to LISP package.

- The NOT-CL package contains miscellaneous support functions for Common EVAL.
 
- An implementation of eval is permitted to differ semantically
  from Common EVAL only by redefining NOT-CL:EVAL.
  This provides a well defined place for modifications to take place.
  Our default definition here simply errors, as would a pure CL
  implementation.

Functions here which are called, not in CL, and intended to be
  defined by Common EVAL include:
  - APPLY
  - The lexical environment accessors.
  - The functions for handling individual special forms.
  - Closures and lexical functions are not dealt with yet.
  
|#

(defun eval (exp &optional lex-env)
  "currently doesn't check for lex-env fns.
   Right now, CL doesn't permit EVAL to take a 2nd arg.
   LEX-ENV defaults to the null lexical environment."
   (cond ((not-cl:self-evaluating-p exp) exp)
         ((symbolp exp) (not-cl:symbol-eval exp lex-env))                 
         ((consp exp) 
          (cond ((symbolp (car exp))                          
                 (cond ((macro-function (car exp))
                        (eval (macroexpand exp) lex-env))
                       ((special-form-p (car exp)) 
                        (not-cl:eval-special-function-call exp lex-env))
                       ((fboundp (car exp))                         
                        (apply (car exp) 
                               (not-cl:list-of-values (cdr exp) lex-env)))
                       (t (not-cl:eval exp lex-env))))
                 ((and (consp (car exp)) 
                       (eq (car (car exp)) 'lambda))
                  (apply (car exp) (cdr exp)))
                 (t (not-cl:eval exp lex-env))))
         (t (not-cl:eval exp lex-env))))

(defun not-cl:self-evaluating-p (form)
   (or (numberp form) (stringp form) (characterp form) (keywordp form)
       (null form) (eq form t)))

(defun not-cl:symbol-eval (symbol lex-env)
  "If SYMBOL is a variable in LEX-ENV, return its value.
   Else If SYMBOL is bound, return its value, 
   else error."
  (if (le:boundp symbol)
      (le:symbol-value symbol lex-env)
      (if (boundp symbol)
          (symbol-value symbol)
          (error "Attempt to evaluate an unbound symbol ~S" symbol))))

(defun not-cl:list-of-values (list lex-env)
   (if list
       (cons (eval (car list) lex-env)
             (not-cl:list-of-values (cdr list) lex-env))))

(defun not-cl:eval-special-function-call (exp lex-env)
  (case (car exp)
   (block (not-cl:eval-block exp lex-env))
   (catch (not-cl:eval-catch exp lex-env))
   ;...
   (otherwise (error "not-cl:eval-special-function-call passed
                      non-implemented special form ~S" exp))))

(defun not-cl:eval (exp &optional lex-env)
      (error "Eval passed non-CL form ~S" exp))
                

∂03-Dec-86  2318	hplb29a!hplbgw!weeks@hplabs.HP.COM 	Re: Packages  
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 3 Dec 86  23:18:09 PST
Received: by hplabs.HP.COM ; Wed, 3 Dec 86 15:57:37 pst
Received: from hplbgw (hplbgw) by hplb29a ; Wed, 3 Dec 86 15:50:39 pst
Received: by hplbgw ; Wed, 3 Dec 86 15:50:22 pst
Date: Wed, 3 Dec 86 15:50:22 pst
From: Gregory Weeks <hplb29a!hplbgw!weeks@hplabs.HP.COM>
Message-Id: <8612032350.AA00381@hplbgw>
To: Soley@MIT-XX.ARPA, su-ai!common-lisp@hplabs.HP.COM,
        hplabs!!cad.cs.cmu.edu!spe@SAIL.STANFORD.EDU
Subject: Re: Packages


			.......
	
		Are you saying that (eql #'FOO:QUUX #'BAR:QUUX) => NIL, but (eql
		'FOO:QUUX 'BAR:QUUX) => T ??  
	
		First (to say it politely) I don't see how your solution solves
		anything.  Second, the more obvious solution of making (EQL 'FOO:QUUX
		'BAR:QUUX) => T is (1) uneconomical, and (2) unteachable in the
		presence of (eql #'FOO:QUUX #'BAR:QUUX) => NIL.  
	
	
	
	I guess my idea wasn't well-worded.  Let me try to clarify.  I would
	remove any association of symbols to packages, thus there would be no
	FU:QUUX, there would just be QUUX.  However, QUUX's value and function
	would be attached to packages, thus we could speak of QUUX's function
	in package FU, or QUUX's value in package BAR.  Thus we have separate
	name spaces for functions and values, without the ridiculosity of
	having to do interning, or string coercion whenever comparison of
	symbols is needed.
	
			-Sean Engelson-
	
Hi.  The notion you present is essentially the same as one I came up 
with.  Here is a summary of how I see it all working.


1.  Symbols with the same name are identical.  Symbols do not have
    values, function-cells, package-cells, or property lists.

2.  By definition, a BINDING associates a symbol and a "property" 
    (another symbol) with a value.  A PACKAGE is a set of bindings.
    At any given time, one package is current.

3.  Defining constructs exist which create bindings and add them to the 
    current package.  There are also referencing constructs which 
    access or mutate bindings.  A binding may not be referenced before
    it has been defined!  (So bindings can not be created with SETF.) 

    (Names for defining constructs might be DEFVAR, DEFUN, DEFMACRO,
    DEFTYPE, DEFSTRUCT, and so on, all of which would be special cases
    of, say, DEFPROP.)

4.  Constructs exist which allow a package to reference some of the
    bindings of other packages.  However, no two distinct bindings with
    the same symbol and property may be referenceable (without 
    qualifiers) in any one package.  Also, no package may redefine a
    binding it did not define!


The above notion eliminates all spurious name clashes.  It has several
drawbacks as far as Common Lisp is concerned.  Here are the worst in
my opinion.

First, binding values are looked up (and possibly cached) as needed at 
run time.  I don't see how to do this efficiently.  Second, Common Lisp 
is already a standard, so major changes aren't reasonable.  Finally, 
while the above is the best I could come up with, I feel that there is 
something else out there better.  (For example, I don't know anything
about locales.)

Still, I think the idea you presented to be basically sound and 
semantically a significant improvement over the status quo.  Good
luck in getting Soley to see things the same way.

Greg Weeks

∂05-Dec-86  1604	RMA  	ANSI doings?  
To:   common-lisp@SAIL.STANFORD.EDU   
Is anybody willing to post a precis of the current ANSI meetings?

∂05-Dec-86  1734	MATHIS@ADA20.ISI.EDU 	is it real or is it... 
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86  17:34:30 PST
Date: 5 Dec 1986 12:05-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: is it real or is it...
From: MATHIS@ADA20.ISI.EDU
To: common-lisp@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU] 5-Dec-86 12:05:20.MATHIS>

On page 56 of the November 1986 "High Technology Magazine" there
is an unidentified person in a picture.  Is it Danny Bobrow or
some celebrity look-a-like that marketing found?

∂05-Dec-86  2055	shebs%utah-orion@utah-cs.arpa 	Underspecification of ~R
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 5 Dec 86  20:55:45 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
	id AA00374; Fri, 5 Dec 86 21:57:12 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
	id AA21384; Fri, 5 Dec 86 21:57:09 MST
Date: Fri, 5 Dec 86 21:57:09 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs)
Message-Id: <8612060457.AA21384@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Underspecification of ~R

In the description of the various : and @ options to ~R (cardinals, ordinals,
and two flavors of Roman numerals), it is said that any integer is printed
in the appropriate way.  How should negative and very large integers be
handled?  HP CL prints out a "negative " for negative cardinals and ordinals,
and prints out various error messages for other cases.  I would prefer to
see "minus four" and have an error for negative cardinals, since "minus
fourth" sounds pretty strange!  Sandra suggests "a lot" as the right way
to print large integers, while I favor "many" (consider the New Guinea
tribes whose number system is "one", "two", "three", "many").  There should
also be a definite bound on integer size (I would make it low;  "five
decillion" also looks pretty strange).  Finally, keep in mind that Americans
and Britons do things differently above one million - perhaps the time
zone returned by get-decoded-time should be used to decide whether to
print "billion" or "milliard" (which do Canadians use anyway?).

Of course, the : and @ options could just be omitted...

						stan the obscure

∂06-Dec-86  0758	MATHIS@ADA20.ISI.EDU 	ANSI doings  
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 6 Dec 86  07:57:58 PST
Date: 6 Dec 1986 07:29-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: ANSI doings
From: MATHIS@ADA20.ISI.EDU
To: common-lisp@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU] 6-Dec-86 07:29:54.MATHIS>

The next X3J13 meeting will be in Dallas, TX, Dec 10-12, 1986.
Topics on the agenda include the function cell value cell issue
and a discussion of error systems.  The first meeting included a
discussion of object system proposals and "minor" corrections to
the Steele book.

There is a separate mailing list for X3J13.  If you are
interested, please reply directly to me.

We are also beginning to discuss how to take advantage of the
open technical interchange which occurs here and then work that
into X3J13 decision making about the eventual standard.  Thoughts
on this topic may be communicated directly to me or to the whole
common-lisp mailing list.  When a suggestion on how to do this is
put together, I will be sure that it is circulated to the whole
community (not just X3J13).

-- Bob Mathis, Convenor and Acting Chairman, X3J13

∂07-Dec-86  2249	ELIOT%cs.umass.edu@RELAY.CS.NET 	Added Keyword argument to load. 
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 7 Dec 86  22:48:53 PST
Received: from cs.umass.edu by csnet-relay.csnet id aq13844; 8 Dec 86 1:32 EST
Date:     Sun, 7 Dec 86 18:11 EDT
From:     ELIOT%cs.umass.edu@RELAY.CS.NET
To:       Common-lisp@SU-AI.ARPA
Subject:  Added Keyword argument to load.
X-VMS-To: CSNET%"Common-lisp@su-ai.arpa"

I would find a "compile" option for the LOAD function to be quite
useful.  It would be a simple, upwards compatible change to add
a :COMPILE keyword argument whose values would be NIL (default), T
or :IF-NEEDED.  NIL and T would mean never and always.  :IF-NEEDED would
specify that LOAD should check the FILE-WRITE-DATE of the source
and (possibly non-existent) previous binary file, and compile the source
if the binary doesn't exist or is older than the source.

This would not be intended to replace a full fledged source code control
system or system rebuilder like the Lisp Machine supplies.  It would
be very useful for people, (like students) who write many small Lisp
programs.  Each semester I write several programs, none of which normally
have more than five source files, and no complicated dependancies.
However, I may be forced to move among many different machines,
and it may be impossible for me to maintain a single library of
"personal" utilities that can be accessed by all of the machines I use.

With these needs in mind the two semantic issues of my proposal can
be dealt with.
(1) What should be done about compile-time/load-time dependancies.
For example should there be any concern about loading macro libraries
before compiling specific files.
Answer: No.  Those issues should be dealt with by a larger scale,
probably implementation dependant utility.  These issues are not
critical for small (< 2000 lines) programs which is the scal of programs
which this feature attempts to support.
(2) How can LOAD determine which source file corresponds to which compiled
file.
Answer: (1) Load already is defined to know how to do this, because
it can "in some implementation dependant way" choose whether to
load a text or object version of the file.
	(2) It should check at least the files which it would otherwise
load, and it should check the files which COMPILE-FILE would read and
write if COMPILE-FILE were given the same argument.

Implementations which don't distinguish compiled files would obviously
be free to ignore this keyword.

∂08-Dec-86  0531	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	Underspecification of ~R 
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 8 Dec 86  05:31:33 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 34474; Mon 8-Dec-86 08:29:36 EST
Date: Mon, 8 Dec 86 08:29 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Underspecification of ~R
To: Stanley T. Shebs <shebs%utah-orion@UTAH-CS.ARPA>,
    common-lisp@SU-AI.ARPA
In-Reply-To: <8612060457.AA21384@utah-orion.ARPA>
Message-ID: <861208082926.7.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

    Date: Fri, 5 Dec 86 21:57:09 MST
    From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs)

    ... I would prefer to see "minus four" and have an error for
    negative cardinals, since "minus fourth" sounds pretty strange!

(dolist (power '(-4 -2 0 2 4))
  (format t "~A to the ~:R power~%" "X" power))
X to the minus fourth power
X to the minus second power
X to the zeroth power
X to the second power
X to the fourth power

Doesn't sound strange to me.

    Sandra suggests "a lot" as the right way
    to print large integers, while I favor "many" (consider the New Guinea
    tribes whose number system is "one", "two", "three", "many").  There should
    also be a definite bound on integer size (I would make it low;  "five
    decillion" also looks pretty strange).  Finally, keep in mind that Americans
    and Britons do things differently above one million - perhaps the time
    zone returned by get-decoded-time should be used to decide whether to
    print "billion" or "milliard" (which do Canadians use anyway?).

Security in obscurity?  Some systems (e.g. Symbolics) punt after certain
limits.

(dotimes (i 10)
  (format t "10↑~D ~@R~%" i (expt 10 i)))10↑0 I
10↑1 X
10↑2 C
10↑3 M
10↑4 10000
10↑5 100000
10↑6 1000000
10↑7 10000000
10↑8 100000000
10↑9 1000000000

(do ((i 8 (+ i 2))) ((> i 50))
  (format t "10↑~D ~R~%" i (expt 10 i)))
10↑8 one hundred million
10↑10 ten billion
10↑12 one trillion
10↑14 one hundred trillion
10↑16 ten quadrillion
10↑18 one quintillion
10↑20 one hundred quintillion
10↑22 ten sextillion
10↑24 one septillion
10↑26 one hundred septillion
10↑28 ten octillion
10↑30 one nonillion
10↑32 one hundred nonillion
10↑34 ten decillion
10↑36 one undecillion
10↑38 one hundred undecillion
10↑40 ten duodecillion
10↑42 one times ten to the forty-second power
10↑44 one hundred times ten to the forty-second power
10↑46 ten times ten to the forty-fifth power
10↑48 one times ten to the forty-eighth power
10↑50 one hundred times ten to the forty-eighth power

One could possibly claim no "reasonable" program would be working
properly (or was given proper inputs) if it ever tried to make such
large numbers intelligible.

    Of course, the : and @ options could just be omitted...

						    stan the obscure


∂08-Dec-86  1256	@DIAMOND.S4CC.Symbolics.COM:chaowatkins@STONY-BROOK.SCRC.Symbolics.COM 	X3J13 mailing list
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 8 Dec 86  12:56:21 PST
Received: from PENG.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 34724; Mon 8-Dec-86 15:53:43 EST
Date: Mon, 8 Dec 86 15:53 EST
From: susan watkins <chaowatkins@STONY-BROOK.SCRC.Symbolics.COM>
Subject: X3J13 mailing list
To: MATHIS@ADA20.ISI.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[ADA20.ISI.EDU] 6-Dec-86 07:29:54.MATHIS>
Message-ID: <861208155333.5.CHAOWATKINS@PENG.S4CC.Symbolics.COM>

    Date: 6 Dec 1986 07:29-PST
    From: MATHIS@ADA20.ISI.EDU

    The next X3J13 meeting will be in Dallas, TX, Dec 10-12, 1986.
    Topics on the agenda include the function cell value cell issue
    and a discussion of error systems.  The first meeting included a
    discussion of object system proposals and "minor" corrections to
    the Steele book.

    There is a separate mailing list for X3J13.  If you are
    interested, please reply directly to me.

Please put me on the mailing list. Thanks. 
My arpa address is :
	chaowatkins@srcr-stony-brook.arpa



	[..... ]



    -- Bob Mathis, Convenor and Acting Chairman, X3J13


∂08-Dec-86  2233	RPG   	Re: testing suite 
 p8-Dec-86  1243	berman@vaxa.isi.edu 	Re: testing suite  
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 86  12:39:54 PST
Received: by vaxa.isi.edu (4.12/4.7)
	id AA09635; Mon, 8 Dec 86 12:38:46 pst
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8612082038.AA09635@vaxa.isi.edu>
Date:  8 Dec 1986 1238-PST (Monday)
To: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet%RELAY.CS.NET@vaxa.isi.edu>
Cc: berman@VAXA.ISI.EDU, fahlman@C.CS.CMU.EDU, gls@ZARATHUSTRA.THINK.COM,
        ida%u-tokyo.junet%RELAY.CS.NET@vaxa.isi.edu, mathis@ADA20.ISI.EDU,
        ohlandar@VAXA.ISI.EDU, rpg@SU-AI.ARPA
Subject: Re: testing suite
In-Reply-To: Your message of Wed, 26 Nov 86 17:18:19+0900.
             <8611260818.AA03707@ccut.u-tokyo.junet>


Here is the explanation I promised.  It is sort of rough, but...

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

DEFTEST is used to define a test.  It puts the test into a database.

The arguments are:

ITEM which is one of the common lisp function names, variables, macro names, 
     etc. or a subject name.  The name must be present in the organizing
     database.

NAME must be a unique symbol for this test.  If not provided, a unique name
     is created.

TYPE is optional, defaulting to :NOEVAL.  It must be one of :NOEVAL,
     :EVAL or :ERROR.  :NOEVAL means the testform eval section is 
     evaluated and compared (using the indicated compare in the testform)
     with the unevaluated compare section.  :EVAL means both halves 
     are evaluated and compared.  :ERROR means the form should produce
     an error.

TESTFORM is the test form, composed of 1 or 3 parts.  If this is 
     and :ERROR test, TESTFORM is an expresion which must produce
     an error.  Otherwise there are 3 parts.  The first is a form 
     which can be used as a function by APPLY, taking two arguments
     and used to compare the results of the eval and compare forms.
     The second form is the eval form, which is evaluated.  
     The compare form is either evalutated (type :EVAL) or not 
     (type :NOEVAL).

The remaining arguments are optional, referenced by keywords.  They are:
  
:CONTRIB$ is a documentation string showing the originator of the test.
If unspecified or NIL it gets its value from CL-TESTS:*CONTRIB$*

:FAILFORM is a form to evaluate in the event that an unexpected error
     was generated, or the comparison failed.

:ERROR$ is a string to print out if the comparison fails.

:SETUP is a form to evaluate before TESTFORM.

:UNSETUP is a form to evaluate after TESTFORM.

:DOC$ is a string documenting this test.  If not specified (or nil) it
    gets it value from the global variable CL-TESTS:*DOC$*

:CONTROL may be any of :GLOBAL, :EVAL-ONLY or :COMPILE-ONLY.  If it is :GLOBAL,
    it means that the test controller will decide when/if to eval and
    compile the test.  If it is :EVAL, then the test will ignore 
    controller attempts to compile it, and if it is :COMPILE the
    controller cannot eval it.  The default is :GLOBAL.

  (defmacro DEFTEST
	    ((item &optional (name :not-provided) (type ':noeval))
	     testform
	     &key (contrib$ *contrib$*)
	          (failform nil)
	          (error$ nil)
	          (setup nil)
	          (unsetup nil)
	          (doc$ nil)
	          (control :GLOBAL)) ...)

Here a an example useage:

  (deftest
    (aref)
    (EQUAL (AREF (MAKE-ARRAY 5 :INITIAL-CONTENTS '(1 2 3 4 5)) 3)
	   4)
    :doc$ "array - 1 dimensional array of 5 elements, subscript 3")

This shows a simple use with NAME and TYPE not provided, as well
as most of the &KEY arguments.  Only :DOC$ is specified.  Here is
a more involved example:

  (deftest
    (block)
    (eq (aux) t)
    :setup (defun aux () (return-from aux t))
    :unsetup (fmakunbound 'aux)
    :doc$ "DEFUN implicitly defines a BLOCK")

This uses the :SETUP and :UNSETUP keywords.  Some keyword arguments
are rarely used.  :FAILFORM is currently unused, being reserved
for future application.  

Often a whole series of tests have the same CONTRIB$ and/or
DOC$.  The global variables *CONTRIB$* and *DOC$* are used
to simplify this use, as follows:

  (setq *contrib$* "contributor string")
  (setq *doc$* "documentation string")

  (deftest ...)

  (deftest ...)


  (setq *contrib$* nil  *doc$* nil)

If any of the deftest forms have a :CONTRIB$ or :DOC$ keyword
used, that would override the defaults set in the global
variables, but only for that deftest form.

The :ERROR$ parameter is somewhat experimental just now.  I don't
recommend using it, but currently, when an error occurs while
running a test, if there is a given :ERROR$, then a statement like

  (format *test-error-stream*  error$ name (car evalform) nil result contrib$)

is executed, where *TEST-ERROR-STREAM* is the run-time error 
reporting stream (usually just T), ERROR$ is the given string,
NAME is the test name, (CAR EVALFORM) is the first form (the
one always evaluated), RESULT is the result of executing
(CAR EVALFORM), and CONTRIB$ contains the name of the author.

For example:

  (deftest
    (+ +-int-13)
    (eq (+ -7 5) -3)
    :error$ "~s failed.  (eq ~s ~s).~%")

would cause "+-INT-13 failed.  (eq -2 -3)." to be printed (of
course, without the enclosing quote marks).

If the test type is :ERROR, then the format string for :ERROR$ is
used like this:

  (format *test-error-stream*  error$ name (car evalform) contrib$)

with the same meanings.

TEST SEQUENCES

Because the tests are all put into a data base, the ordering of
the tests (from the input file) is normally lost.  Usually each
test is independent of another.  However, at times you have
an extensive environment around a group of tests (using :SETUP
and :UNSETUP) that is inconvenient to duplicate for each
test.  And also sometimes the exact order of tests IS important.

In this case, you would use DEFTEST-SEQ to define a sequence of
tests.

  (defmacro DEFTEST-SEQ ((item seq-name)
			 test-seq
			 &key (contrib$ *contrib$*)
			      (setup nil)
			      (unsetup nil)
			      (doc$ *doc$*)) ...)

This uses an ITEM as in DEFTEST, and adds the concept of the
SEQ-NAME.  This is a unique name assigned to the entire
sequence of tests.  

TEST-SEQ is the list of tests, formatted like so:

(( NIL | (<test name> <optional type>)
   testform
   <optional keyword data>)
 ( NIL | (<test name> <optional type>)
   testform
   <optional keyword data>)
 ...)

This is a list of forms.  Each form has a CAR that is
either NIL or a list containing at least the name of this
testform, and, optionally, the test type as in DEFTEST.  
If no name is given (because we used NIL instead of a list
here) then the name is constructed from the SEQ-NAME.

The TESTFORM is a form as in DEFTEST, varying in structure
depending on if TYPE is :ERROR or not.  The optional 
keyword data is exactly as per DEFTEST.

Here is an example:

   (deftest-seq
     (apply apply-CDC-tests)
     (
      (nil
	(eq (APPLY #'+ '()) 0))
      (nil
	(equal (APPLY #'(LAMBDA (&KEY A B) (LIST A B)) '(:B 3))
	       (nil 3))
	:doc$ "Book test, page 108")))

This shows a sequence of APPLY, named APPLY-CDC-TESTS. It 
has two tests in it, each automatically named and defaulting
to NOEVAL type.  The second test has a :DOC$ value.

In addition to the keywords that may appear on each test, the
entire sequence may have the keywords :CONTRIB$, :SETUP,
:UNSETUP and :DOC$.  These act as defaults for each individual
test in the sequence, being overridden by any use of these
keywords in the individual test.

Typically a sequence would have an environment specified by 
:SETUP and :UNSETUP which would be used by the tests in the
sequence.


Here are some actual samples of tests. These were converted
from tests supplied by CDC.  I make no guarantee of their
usefullness or correctness, except as examples of the
test format.

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

;; -*-  mode:Common-Lisp; Base: 10; Package:cl-tests  -*-

(in-package 'cl-tests)

(setq *contrib$* "CDC")
(setq *DOC$* "Test Integer Addition.")

(deftest
  (+ +-int-1)
  (eq (+ 1 2) 3))

(deftest
  (+ +-int-2)
  (eq (+ 0 0) 0))

(deftest
  (+ +-int-3)
  (eq (+) 0))

(deftest
  (+ +-int-4)
  (eq (+ 1 2 3 4 5 6 7 8 9 10) 55))

(deftest
  (+ +-int-5)
  (eq (+ -5) -5))

(deftest
  (+ +-int-6)
  (eq (+ 10) 10))

(deftest
  (+ +-int-7)
  (eq (+ 1 (+ 1 1)) 3))

(deftest
  (+ +-int-8)
  (eq (+ 5 (+ 7 -7)) 5))

(deftest
  (+ +-int-9)
  (eq (+ 4 (+ 3 (+ 2 (+ 1)))) 10))

(deftest
  (+ +-int-11)
  (eq  (+ 1514 (- 1511)) 3))

(deftest
  (+ +-int-12)
  (eq (+ 0) 0))

(deftest
  (+ +-int-13)
  (eq (+ -7 5) -2))

(deftest
  (+ +-int-14)
  (eq (+ 1 -2 +3 -4 5 -6 +7 -8 9 -10) -5))

(deftest
  (+ +-int-15)
  (eq (+ 1793 22485) 24278))


(deftest-seq
  (+ CDC-+-FLOAT-TESTS)
  ((nil
    (ADD-P (+ 0.01 0.1) 0.11))
   (nil
    (add-p (+ 0.0) 0.0))
   (nil
    (add-p (+ 0.0 0.000) 0))
   (nil
    (add-p (+ 0.0 0.12) 0.12))
   (nil
    (add-p (+ 1.23 0) 1.23))
   (nil
    (add-p  (+ 2.401E125 5.738E123) 2.45838E125))
   (nil
    (add-p  (+ 0.1 0.11 0.111 0.1111) 0.4321))
   (nil
    (add-p  (+ 0.1 -1.01 +10.001 -100.0001 1000.00001) 909.09091))
   (nil
    (add-p  (+ 12.4 2.31 (+ 10.38 25.77)) 50.86))
   (nil
    (add-p (+ 0.001) 0.001))
   (nil
    (add-p  (+ 0.1 (+ 0.11 (+ 0.111 (+ 0.1111 0.11111)))) 0.54321))
   (nil
    (add-p  (+ A B) 55.761)))
  :setup  (progn
	    (DEFUN ABSOLUTE_V (G1 G2)
	      (IF (MINUSP (- G1 G2)) (- G2 G1) (- G1 G2)))

	    (DEFUN ADD-P (G1 G2)
	      (COND ((EQUAL G1 G2) T)
		    ((< (/ (ABSOLUTE_V G1 G2)
			   G1) 1E-10) T)))
	    (SETQ A (+ 50.481 (SET 'B (+ 2.41 0.23)))))

  :unsetup (progn
	     (makunbound 'a)
	     (makunbound 'b)
	     (fmakunbound 'add-p)
	     (fmakunbound 'absolute_v))
  :doc$  "Floating point test of +.  Not sure that the values are meaningful in the ADD function here!")


(deftest-seq
  (+ +-float/int-tests)
  ((nil
    (add-p (+ 0 0.0 -0.0 +0. -0) 0))
   (nil
    (add-p  (+ 50.3 41 -24 -18.73) 48.57))
   (nil
    (add-p (+ 5 4.4 3 (+ 2.2 1 0.1) -2.7 -4 -4.5) 4.5))
   (nil
    (add-p  (+ 54321.12345 54321 2.7E3 -9.99E+06) -9878657.87655))
   (nil
    (add-p  (+ 5.4879993E-3 -1005.4879992E-3 1) 9.9994679203E-11))
   (nil
    (add-p  (+ 8.76E122 9.766E-3 6543210) 8.76E122))
   (nil
    (add-p (+ 1 3 5 (+) (+ 6) (+ 1.1 3.3 5.5 (+) (+ 6.6)) 8) 39.5))
   (nil
    (add-p (+ 300 20 1 0 .1 .02 .003 .0004 .00005 .000006 (-(+ 321 0.123456))) -7.27595E-12)))
  :doc$ "test the ADD function under the floating point and integer calculation"
  :setup (DEFUN ADD-p (G1 G2)
	   (PROG (ADD_V)
		 (SETQ ADD_V (- G1 G2))
		 (COND ((OR (AND (< 0 G1)
				 (< 0 ADD_V))
			    (AND (< G1 0)
				 (< ADD_V 0)))
			T))
		 (COND ((< (/ ADD_V G1) 1E-5) (RETURN T))
		       (T (RETURN NIL)))))
  :unsetup (fmakunbound 'add-p))


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

;; -*-  Mode:Common-Lisp; Base: 10; Package:cl-tests  -*-

(in-package 'cl-tests #m :use #m "lisp")

(setq *contrib$* "Pete Warburton @ CDC")
(setq *doc$* nil)

(deftest-seq
  (boole boole-CDC)
  ((nil
     (eq (boole boole-clr logtest01 logtest10) 0))
   (nil
     (eq (boole boole-set logtest01 logtest10) -1))
   (nil
     (eq (boole boole-1 logtest01 logtest10) logtest01))
   (nil
     (eq (boole boole-2 logtest01 logtest10) logtest10))
   (nil
     (eq (boole boole-c1 logtest01 logtest10) (lognot logtest01)))
   (nil
     (eq (boole boole-c2 logtest01 logtest10) (lognot logtest10)))
   (nil
     (eq (boole boole-and logtest01 logtest10) logtest0))
   (nil
     (eq (boole boole-ior logtest01 logtest10) logtest1))
   (nil
     (eq (boole boole-xor logtest01 logtest10) logtest1))
   (nil
     (eq (boole boole-eqv logtest01 logtest10) (lognot logtest1)))
   (nil
     (equal (boole boole-nand logtest01 logtest10) (lognot logtest0)))
   (nil
     (equal (boole boole-nor logtest01 logtest10) (lognot logtest1)))
   (nil
     (equal (boole boole-andc1 logtest01 logtest10) logtest10))
   (nil
     (equal (boole boole-andc2 logtest01 logtest10) logtest01))
   (nil
     (equal (boole boole-orc1 logtest01 logtest10) (lognot logtest01)))
   (nil
     (equal (boole boole-orc2 logtest01 logtest10) (lognot logtest10))))
  :setup (progn
	   (setq logtest0 0)
	   (setq logtest-1 -1)
	   (setq logtest1 (+ 1 2 4 8 16 32 64 128 256 512 1024 2048 ))
	   (setq logtest01 (+ 1 4 16 64 256 1024))
	   (setq logtest10 (+ 2 8 32 128 512 2048 )))
  :unsetup (progn
	     (makunbound logtest9)
	     (makunbound logtest-1)
	     (makunbound logtest1)
	     (makunbound logtest01)
	     (makunbound logtest10)))

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

RB

∂08-Dec-86  2237	RPG   	Common EVAL  
 ∂02-Dec-86  2300	@REAGAN.AI.MIT.EDU:Henry@OZ.AI.MIT.EDU 	Common EVAL    
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 86  22:59:29 PST
Received: from SINATRA.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 14027; Wed 3-Dec-86 01:58:41 EST
Date: Wed, 3 Dec 86 01:58 EST
From: CFry@OZ.AI.MIT.EDU
Sender: Henry@OZ.AI.MIT.EDU
Subject: Common EVAL
To: Common-Lisp@SU-AI.ARPA
cc: Henry@OZ.AI.MIT.EDU
Message-ID: <861203015844.2.HENRY@SINATRA.AI.MIT.EDU>
Reply-To: HENRY@AI.AI.MIT.EDU



Common EVAL

Henry Lieberman and Christopher Fry


Abstract

We propose that the Common Lisp standard be extended by adding to the
language specification a short program, itself written in Common Lisp, to
implement the EVAL function.  The interpreters for every correct
implementation of Common Lisp would be required to match the semantics of
Common EVAL on valid Common Lisp expressions.  
It should treat other expressions as errors or as implementation dependent 
extensions.  There are
three cogent reasons for including a Common EVAL in the standard:
First, since EVAL fixes the meaning of Lisp programs, it would
insure uniformity of program semantics across implementations.
Second, it would aid validation efforts, since the behavior of a
particular implementation could always be compared to the behavior
of Common EVAL.  Third, it would facilitate the creation of debuggers
and other program-manipulating programs that could be ported across
Common Lisp implementations. 

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

One of the marvelous things about Lisp is that the language can be written in
itself.  In Lisp, programs can be data and data can be programs.  The
operation of the language itself can be described as a function written in
the very same language: the EVAL function.  Lisp advocates always point
with pride to this fact as a major reason for Lisp's superiority over
conventional languages.  It is why Lisp has traditionally supported the
best debugging environments.  It is why Lisp can be used to write the
program-manipulating programs which are essential in artificial
intelligence work, and in building advanced interactive programming
environments.

Sadly, this important advantage is becoming steadily eroded by some of the
modern production implementations of Lisp.  The quest for efficiency and
experimentation with esoteric programming constructs are leading to
non-standard implementations of Lisp interpreters that foil attempts
to make use of Lisp's self-descriptive capability.

With Common Lisp, we have a unique opportunity to insure that the
program-data equivalence which is one of Lisp's cornerstones remains
available as Lisp implementations proliferate.  But the English
description in the Steele book is not detailed enough to exclude semantic
deviations which frustrate serious developers of program-manipulating
programs.

Specifying the EVAL function as a Common Lisp program can provide a
concise, precise, and easily understood description which could serve as a guide for
implementors and a means by which to evaluate the results.  
Implementors would not be required to run the exact code for Common
EVAL in their implementation. 
They could provide another implementation, which may be more efficient or include
extra features, but they would be required to assure that their version matched the
semantics of Common EVAL.
Differences in behavior between a particular Lisp implementation and Common EVAL
would be evidence for violations of the Common Lisp standard.

Many advanced Lisp applications rely on the precise details of the operation of
EVAL.  Implementing a single-stepping debugger for Lisp code, for example,
requires imitating EVAL on Lisp expressions, while inserting display operations
and requesting input at events during evaluation.

Lisp's extensibility makes it ideal for defining embedded application-dependent
languages, which may even have a different control structure than Lisp's.  Often,
these languages need to "use Lisp" as a subset, call Lisp functions from code in
the other language, or even invoke foreign language code from Lisp code.  For
the interface to be smooth, the language designer must be able to depend on how
Lisp code is evaluated, perhaps including details such as variable environments
and function definitions.

Many programs which need to analyze Lisp programs statically require a "code
walker", a program that determines which subexpressions of a Lisp expression
represent code to be evaluated, and which represent data, like expressions which
appear inside a QUOTEd list.  Such code walkers, which separate the uses of
Lisp expressions as programs from uses as data, appear in virtually every Lisp
compiler.  Smart pretty-printers that print expressions according to their
semantics, indexers, or other "programmer's apprentice" tools need this, too.
Code walkers anticipate the action of EVAL on an expression, so they are
inextricably tied to EVAL's operation.

With Common EVAL, a designer of a program-manipulating program can base their
tools on the definition of Common EVAL rather than the details of a particular
Lisp implementation.
The implementor can then have confidence that the tools will work in all valid
implementations of Common Lisp.
This should significantly enhance Common Lisp's suitability for advanced applications.

The interpreters for MIT-descended Lisp Machines by Symbolics, LMI and TI 
show how production implementations have compromised Lisp semantics.  
Surprisingly, if you look at the system's definition of the EVAL
function, you will find that it only appears to be written in Lisp.  
It calls "subprimitives" which are special-cased by the compiler, compiling
into specialized microcode, motivated by an attempt to make the Lisp interpreter more
efficient.  
The subprimitives do things which, for example, violate the stack discipline of Lisp. 
The system's definition of EVAL cannot even be interpreted by EVAL itself!

Because of the additional complexity that machine-dependent efficiency hacks add to
the evaluator, it is no longer feasible to write an EVAL without subprimitives, and
have any confidence that the results will be equivalent to the system's EVAL.
If the code for the evaluator relies on subprimitives, it won't even be intelligible to
the human reader literate only in Lisp.

This is not to say that we are against subprimitives; obviously, they are necessary
for such functions as CAR and EQ.
The English description of the behavior of lowest level functions in the 
Steele book is adequate, as is the description of middle level functions like APPEND.
It is only when the complexity of something like EVAL is reached that 
divergence among implementations becomes a real problem.

Periodically, internal changes to a system's evaluator require changing any
imitative implementation.
For example, Symbolics recently changed the function cell of an interpreted function
from containing a lambda expression to SI:DIGESTED-LAMBDA, which necessitated
similar changes in any program which expected to interpret functions.
A standard EVAL would clarify what representations a user could rely on, and clarify
what representations an implementor could change without breaking system code
or affecting users. 

Another central problem is that "extensions" to the Lisp language may be 
implemented in the interpreter by low-level constructs that cannot
be directly implemented by a Lisp program.  While Common Lisp is
designed to permit extensions to the language, it should not allow
extensions which rely on microcode and other non-Lisp implementation techniques to 
change the basic semantics of the language.
Such extensions effectively prevent any program-manipulating
program written in Common Lisp from operating on code containing
the extensions. 

Spaghetti stacks in Interlisp are an example where an attempt to
implement non-standard programming constructs wreaks havoc with the
interpreter's semantics.  It is impossible for an Interlisp
user to write a stepping debugger capable of working on interpreted code
that uses spaghetti stacks.  
Common EVAL should provide well-defined points in the evaluation process at which
particular implementations could provide extensions, such as defining a new variety of
functional object.

How detailed should the Common EVAL implementation be?  Everyone knows
that it is possible to implement a wide range of meta-circular
interpreters ranging from a one-page interpreter in the vein of the
original Lisp 1.5 book, to one that is so detailed it specifies every bit
and would probably run to hundreds of pages.  Clearly, a middle course is
called for.  The interpreter should be the minimal size necessary
to specify the interpreter in terms of calls to Common Lisp functions.
It should probably take no more than ten pages to do this.  It should
be detailed enough to do things like specify the behavior of all
the special forms, but does not have to be so detailed as to
specify all the internal representations used by the evaluator.  

The interpreter may need a variety of helping functions to access
representations of data structures, for example lexical variable binding
environments.  To avoid constraining the freedom of implementors to choose
efficient representations for such data structures, Common EVAL could call
abstract functions whose implementation would not be prescribed by the
standard.  Every implementation could provide its own EXTEND-ENVIRONMENT
function, whose behavior would be specified by a description, in the
manner of the Steele book.  A simple Common Lisp implementation, for
example implementing environments as ALISTs, could be shown for
illustrative purposes without fixing the ALIST representation in every
Common Lisp implementation.

Finally, to illustrate the intent of our proposal more concretely, we present a
short segment of Lisp code for a skeleton Common EVAL.  Don't take this code
too literally -- we mean it only to illustrate the style and the level of detail
we would expect of the real Common EVAL, and as a springboard for
discussion.  

#| 

Some notes about the code:
- The LE package contains the lexical environment manipulator
   fns, many of which are yet to be written. If the CL community
   decides to provide advertised support for lexical environment functions,
   some of the functions here could be moved into to LISP package.

- The NOT-CL package contains miscellaneous support functions for Common EVAL.
 
- An implementation of eval is permitted to differ semantically
  from Common EVAL only by redefining NOT-CL:EVAL.
  This provides a well defined place for modifications to take place.
  Our default definition here simply errors, as would a pure CL
  implementation.

Functions here which are called, not in CL, and intended to be
  defined by Common EVAL include:
  - APPLY
  - The lexical environment accessors.
  - The functions for handling individual special forms.
  - Closures and lexical functions are not dealt with yet.
  
|#

(defun eval (exp &optional lex-env)
  "currently doesn't check for lex-env fns.
   Right now, CL doesn't permit EVAL to take a 2nd arg.
   LEX-ENV defaults to the null lexical environment."
   (cond ((not-cl:self-evaluating-p exp) exp)
         ((symbolp exp) (not-cl:symbol-eval exp lex-env))                 
         ((consp exp) 
          (cond ((symbolp (car exp))                          
                 (cond ((macro-function (car exp))
                        (eval (macroexpand exp) lex-env))
                       ((special-form-p (car exp)) 
                        (not-cl:eval-special-function-call exp lex-env))
                       ((fboundp (car exp))                         
                        (apply (car exp) 
                               (not-cl:list-of-values (cdr exp) lex-env)))
                       (t (not-cl:eval exp lex-env))))
                 ((and (consp (car exp)) 
                       (eq (car (car exp)) 'lambda))
                  (apply (car exp) (cdr exp)))
                 (t (not-cl:eval exp lex-env))))
         (t (not-cl:eval exp lex-env))))

(defun not-cl:self-evaluating-p (form)
   (or (numberp form) (stringp form) (characterp form) (keywordp form)
       (null form) (eq form t)))

(defun not-cl:symbol-eval (symbol lex-env)
  "If SYMBOL is a variable in LEX-ENV, return its value.
   Else If SYMBOL is bound, return its value, 
   else error."
  (if (le:boundp symbol)
      (le:symbol-value symbol lex-env)
      (if (boundp symbol)
          (symbol-value symbol)
          (error "Attempt to evaluate an unbound symbol ~S" symbol))))

(defun not-cl:list-of-values (list lex-env)
   (if list
       (cons (eval (car list) lex-env)
             (not-cl:list-of-values (cdr list) lex-env))))

(defun not-cl:eval-special-function-call (exp lex-env)
  (case (car exp)
   (block (not-cl:eval-block exp lex-env))
   (catch (not-cl:eval-catch exp lex-env))
   ;...
   (otherwise (error "not-cl:eval-special-function-call passed
                      non-implemented special form ~S" exp))))

(defun not-cl:eval (exp &optional lex-env)
      (error "Eval passed non-CL form ~S" exp))
                

∂08-Dec-86  2239	RPG   	SUBSET  
 ∂20-Nov-86  0439	a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET 	SUBSET
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 20 Nov 86  04:39:48 PST
Received: from utokyo-relay by csnet-relay.csnet id ad19259; 20 Nov 86 5:36 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
	id AA02091; Thu, 20 Nov 86 19:11:39+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
	id AA11959; Thu, 20 Nov 86 19:03:53+0900
Date: Thu, 20 Nov 86 19:03:53+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Message-Id: <8611201003.AA11959@ccut.u-tokyo.junet>
To: fahlman@C.CS.CMU.EDU, gls@ZARATHUSTRA.THINK.COM, 
    ida%u-tokyo.junet@RELAY.CS.NET, mathis@ADA20.ISI.EDU, rpg@SU-AI.ARPA
Subject: SUBSET

I and JerryB communicated as for subsetting several times.
in his last message of Sept., he wrote
"I will consult Fahlman, RPG,.. to make a organization for subset in ANSI".
In Octber, he came to japan for his own business.
He and I had a promise to discuss about the matter with my subset committee.
But due to his personal accident, he only stayed 2days in japan and
had retuned USA. I could not meet and talk with him.

In the agenda for the commming X3 meeting,
Scope of X3J13 will not take subset into account or so.

It means the offical subset is not going to appear in USA  ?
at least, for a while ?

I have a plan to gather software vendors who sells or will sell
'Common Lisp'-like -subset Lisps, to follow CL/Core in January.
And, I had thought the companies who selling/maintaining GCLisp might
join. 
(Currently, main framers in japan are busy to implement their own
full-set Common Lisp. And in japan,
though Personal Computers have great influence for the people,
the softwares for PC including OS/language processors  were
undertaken by ISV or the subsideries of main framers.)
Do you have any comments on it ?


Masayuki

∂08-Dec-86  2248	RPG   	from Japan   
 ∂05-Nov-86  0337	a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA 	from Japan  
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 5 Nov 86  03:36:47 PST
Received: from utokyo-relay by csnet-relay.csnet id dd00194; 5 Nov 86 1:28 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
	id AA04539; Tue, 4 Nov 86 23:11:45+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
	id AA17427; Tue, 4 Nov 86 22:57:05+0900
Date: Tue, 4 Nov 86 22:57:05+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
Message-Id: <8611041357.AA17427@ccut.u-tokyo.junet>
To: fahlman@C.CS.CMU.EDU, gls@ZARATHUSTRA.THINK.COM, 
    ida%u-tokyo.junet@CSNET-RELAY.ARPA, mathis@ADA20.ISI.EDU, rpg@SU-AI.ARPA
Subject: from Japan

***** This is not the official translation *****

On 1986 August 1st, MITI Japan announced the 3rd Japan-French round table 
was to be held on Oct. 8th and 9th. at the meeting room of the MITI.
 Oct.8th : morning. discussion by all the members
	 afternoon. working group discussion; AI, OSI, mechtronics, space industries, HA, Data base.
 Oct. 9th working group discussions and lunchon

--------------------
AI group meeting at Oct 8th 14:00-18:00

 from japan; 11 members(NEC,Fujitsu,OKI,Mitsubishi,JEDR,Toshiba,Hitachi,ICOT,MITI)
 from France; 9 members(Act Informatique, Bull, Cognitec, Cril,Syseca,Telemecanique,Cescom,INRIA,DIELI)

1) Japan and France agreed to do information exchange about the standardization
on AI.
2) Japan and France agreed that Lisp is enough matured to be a subject of standardization.
3) France proposed to make INRIA as the correspondant.
France also asked japan to find the correspondant.
Japan agreed to search it.
4) France proposed to make an expert meeting for Lisp standardization.
Japan understood their will. But, japan declared it is too early.
japan explained japanese domestic efforts on standardization.
5) France claimed the objection to USA based standardization, especially 
to Common Lisp.
6) France understood japanese way.
7) Mr. Simon of CRIL presented the objection to Common Lisp and claimed
Eulisp is good using the documents prepared by jerome chailloux.

------------------
Prof. Nakata, who will attend ISO SC22 meeting asked me the dirction.  I
sent him a message,"please watch for a while. do'nt say yes to Eulisp."
(I need more a few months to persuade several old-timer Lisp researcher in
JIS committee)
-----------------
In these several months, Jeida Common Lisp committee have presentations of
Hitachi, Fujitsu, NEC about their own Common Lisp implementations.  While,
JIS committee decided to make a JIS Lisp.  We studied about the pros and
cons of Eulisp/Scheme.  But, we feel if we will use Eulisp/scheme as a
base for JIS, it is too early to make JIS.  also we feel Common Lisp is
suitable for current standard.  The current issue is 100%common-lisp or
100% independent.
--------------------
Kanji working group of Jeida committee will finish their first draft on Kanji
related language extension in Jan.1987.
It will be appeared on IPSJ WGSYM meeting and Jeida report.
As soon as the document is available, I will send it to CL mail box.

Masayuki Ida


∂08-Dec-86  2249	RPG   	Lisp standardization   
 ∂18-Sep-86  2047	a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA 	Lisp standardization  
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 Sep 86  20:47:05 PDT
Received: from utokyo-relay by csnet-relay.csnet id aj09430; 18 Sep 86 11:30 EDT
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
	id AA18188; Thu, 18 Sep 86 23:12:03+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
	id AA17403; Thu, 18 Sep 86 23:03:17+0900
Date: Thu, 18 Sep 86 23:03:17+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
Message-Id: <8609181403.AA17403@ccut.u-tokyo.junet>
To: Bobrow.pa%xerox.arpa@CSNET-RELAY.ARPA, fahlman@C.CS.CMU.EDU, 
    gls@ZARATHUSTRA.THINK.COM, ida%u-tokyo.junet@CSNET-RELAY.ARPA, 
    mathis@ADA20.ISI.EDU, rpg@SU-AI.ARPA
Subject: Lisp standardization

Dear Bob Mathis,

     Yesterday, I received a percel from you containing an agenda and
related documents for the comming ANSI meeting. Thank you.

As we discussed already, I can not attend the ANSI meeting on Sept.23,24,
because of my university schedule.

So, I describe the Japanese status as follows for your reference.
(and this is the reason why I sent this mail to Fahlman, gls, Dany, and Dick)

1) we had a second meeting of JIS LISP WG on Sept.5th.
The main issue was to determine the schedule and the scope.
I proposed three items, one is JIS LISP should be based on Common Lisp,
another is to  make an international contribution as a JIS activity,
and the other is to make a draft and send it to MITI.
This WG has three years. We must finish WG on July 1989, which will conform to 
the ISO schedule you proposed.
We have finally made a consensus that we will be based on Common Lisp,
after hot discussions !

2) As a researcher I have had a continous interest to CommonLoops since March 1985, one half years ago.
And as a chair I have played a role of the gate for the PCL distribution
and related things.
The number of the acknowledged holders of PCL in japan is (going to be) more than
10 organizations.

3) I was told by MITI stuff that ANSI asked MITI japan to investigate 
the possibility of the joint efforts to make a joint standardization
on some items in Computer area.
MITI is now thinking of the LISP is suitable or no.
But they know the current status of Lisp area, becuase I told them.
And, Common Lisp is a candidate for the joint standardization.
Please push ANSI head office if you want to do so.

4) Jeida Common Lisp committee will make a second workshop on Common lisp on
Sept.19 and 20 (tomorrow).
This meeting will be also very important to the future of CL in japan.
Several mainframer will present their papers on their own Common Lisp (and CommonLoops !) implementation in the comming annual conferences of japanese
academic societies. I think its only a research level.
On the meeting we will have tomorrow,
a) the schedule of the Jeida proposal for the Kanji and the outline will be discussed. My private feeling is the target date is December 1986 or January 1987.
b) further policy for CL/Core will be decided. it should be only a specification ?
Or the pilot or the complete source will be jointly developed ?
The proposal from US implementors should be taken into ?
...
c) the schedule for the CommonLoops research group will be decided.

5) I received several mails from chaillou and Eulisp people.
I was surprised that they have a quite different feeling 
on the result of the 'Tuesday night meeting'.
I adviced them that they should send their spec to european standardization 
organization or should send to the computer manifactures to make the implementation.

I pray God that the everything is governed by God's will.
May God bless us.

Thank you

M.ida
ida%utokyo-relay.csnet@csnet-relay.arpa

∂09-Dec-86  1605	RICHER@SUMEX-AIM.ARPA 	X window system  
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Dec 86  16:05:45 PST
Date: Tue 9 Dec 86 16:03:11-PST
From: Mark Richer <RICHER@SUMEX-AIM.ARPA>
Subject: X window system
To: common-lisp@SU-AI.ARPA
cc: richer@SUMEX-AIM.ARPA
Message-ID: <12261524037.86.RICHER@SUMEX-AIM.ARPA>

I am interested in extensions to Commonlisp that are interfaced to the X
window system, especially using object-oriented programming. THere are groups
at Berkeley, Utah, and so on that are doing this right now. I am
putting together a mailing list on this and if you have something to share
or would  just like to be on the list let me know.  I guess if you are
interested in interfaces to SUN's new window system NEWS let me know
also.

Mark
-------