perm filename COMMON.MSG[COM,LSP]41 blob sn#844289 filedate 1987-08-10 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00389 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00055 00002	
C00056 00003	∂12-Apr-87  0005	kempf%hplabsc@hplabs.HP.COM 	Re:  redefining Common Lisp functions    
C00059 00004	∂12-Apr-87  1750	edsel!bhopal!jonl@navajo.stanford.edu 	all symbols [and delayed mail] 
C00064 00005	∂12-Apr-87  1751	edsel!bhopal!jonl@navajo.stanford.edu 	redefining Common Lisp functions    
C00066 00006	∂12-Apr-87  2225	HEWETT@SUMEX-AIM.STANFORD.EDU 	Redefining CL fns  
C00068 00007	∂13-Apr-87  1018	sears%wrs.DEC@decwrl.DEC.COM 	Re:  Redefining Common LISP Functions, MACROS and Special Forms  
C00072 00008	∂13-Apr-87  1216	gls@Think.COM 	redefining Common Lisp functions   
C00075 00009	∂13-Apr-87  1516	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	Compiling CASE 
C00081 00010	∂13-Apr-87  1528	@diamond.s4cc.symbolics.com:DCP@QUABBIN.SCRC.Symbolics.COM 	Compiling CASE 
C00087 00011	∂13-Apr-87  2016	DON%atc.bendix.com@RELAY.CS.NET 	Inconsistent keywords for sequence functions   
C00089 00012	∂14-Apr-87  0747	ROSENKING@A.ISI.EDU 	Redefinition of CL Functions 
C00096 00013	∂14-Apr-87  0851	kempf%hplabsc@hplabs.HP.COM 	Re:  Redefinition of CL Functions   
C00099 00014	∂14-Apr-87  0924	RAM@C.CS.CMU.EDU 	Redefinition of CL Functions    
C00102 00015	∂14-Apr-87  0949	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re:  Redefinition of CL Functions    
C00105 00016	∂14-Apr-87  1010	sears%wrs.DEC@decwrl.DEC.COM 	Re:  Inconsistencies in Sequence Function Arguments    
C00107 00017	∂14-Apr-87  1013	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Inconsistent keywords for sequence functions    
C00110 00018	∂14-Apr-87  1131	Moon@STONY-BROOK.SCRC.Symbolics.COM 	redefining Common Lisp functions 
C00114 00019	∂14-Apr-87  1148	VERACSD@A.ISI.EDU 	Format
C00115 00020	∂14-Apr-87  1204	FAHLMAN@C.CS.CMU.EDU 	Format  
C00117 00021	∂14-Apr-87  1706	sears%wrs.DEC@decwrl.DEC.COM 	Re:  Redefinition of CL Functions  
C00120 00022	∂14-Apr-87  1829	jcm@ORNL-MSR.ARPA 	Flavors and DEC's VMS Common Lisp?  
C00122 00023	∂14-Apr-87  2056	kempf%hplabsc@hplabs.HP.COM 	Re: Redefinition of Common Lisp Functions
C00127 00024	∂14-Apr-87  2256	MURRAY%cs.umass.edu@RELAY.CS.NET 	EVAL-WHEN symbols    
C00129 00025	∂15-Apr-87  0236	pyramid!pyramid.UUCP!bein@hplabs.HP.COM 	macroexpand inside of macrolet... 
C00133 00026	∂15-Apr-87  0818	FAHLMAN@C.CS.CMU.EDU 	Redefinition of Common Lisp Functions 
C00136 00027	∂15-Apr-87  0818	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	macroexpand inside of macrolet...  
C00139 00028	∂15-Apr-87  0903	FAHLMAN@C.CS.CMU.EDU 	EVAL-WHEN symbols 
C00141 00029	∂15-Apr-87  0955	weeks%hplbgw%hplb29a@hplabs.HP.COM 	Re:  EVAL-WHEN symbols  
C00143 00030	∂15-Apr-87  0957	Masinter.pa@Xerox.COM 	Re: macroexpand inside of macrolet...
C00145 00031	∂15-Apr-87  1034	Masinter.pa@Xerox.COM 	Re: EVAL-WHEN symbols 
C00147 00032	∂15-Apr-87  1306	Mailer@XX.LCS.MIT.EDU 	Compiling CASE   
C00150 00033	∂15-Apr-87  2258	sandra%orion@cs.utah.edu 	bignums are bogus  
C00155 00034	∂16-Apr-87  0834	FAHLMAN@C.CS.CMU.EDU 	bignums are bogus 
C00158 00035	∂16-Apr-87  0834	RAM@C.CS.CMU.EDU 	bignums are bogus
C00163 00036	∂16-Apr-87  0837	vrotney@vaxa.isi.edu 	CLARIFICATION: [italics]package arguments. 
C00165 00037	∂16-Apr-87  0859	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	bignums are bogus   
C00168 00038	∂16-Apr-87  0930	DLA@DIAMOND.S4CC.Symbolics.COM 	bignums are bogus 
C00169 00039	∂16-Apr-87  0946	RPG   	a lisp1 compatible subset of Common Lisp   
C00183 00040	∂16-Apr-87  1009	shebs%orion@cs.utah.edu 	Bognumosity    
C00186 00041	∂16-Apr-87  1042	jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	Re:  bignums are bogus   
C00189 00042	∂16-Apr-87  1054	FAHLMAN@C.CS.CMU.EDU 	Bognumosity  
C00192 00043	∂16-Apr-87  1124	KMP@STONY-BROOK.SCRC.Symbolics.COM 	bignums are bogus, but so are fixnums  
C00198 00044	∂16-Apr-87  1211	shebs%orion@cs.utah.edu 	Re:  Bognumosity    
C00203 00045	∂16-Apr-87  1216	DALY@IBM.COM 	typos in Cltl   
C00204 00046	∂16-Apr-87  1237	hoey@nrl-aic.ARPA 	Re: Bognumosity 
C00206 00047	∂16-Apr-87  1310	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re:  Bognumosity 
C00209 00048	∂16-Apr-87  1317	sdcrdcf!darrelj@CS.UCLA.EDU 	Re: bignums are bogus
C00212 00049	∂16-Apr-87  1349	@SAIL.STANFORD.EDU:REM@IMSSS 	How much memory for bignum or other large data structure?   
C00223 00050	∂16-Apr-87  1354	shebs%orion@cs.utah.edu 	Re:  Bognumosity    
C00226 00051	∂16-Apr-87  1403	preece%mycroft@gswd-vms.ARPA 	Re: Bognumosity
C00230 00052	∂16-Apr-87  1411	preece%mycroft@gswd-vms.ARPA 	Re: Bognumosity
C00234 00053	∂16-Apr-87  1419	edsel!bhopal!jonl@navajo.stanford.edu 	bignums are bogus    
C00237 00054	∂16-Apr-87  1426	FAHLMAN@C.CS.CMU.EDU 	bignums are bogus, but so are fixnums 
C00240 00055	∂16-Apr-87  1511	Masinter.pa@Xerox.COM 	bignums are bogus
C00242 00056	∂16-Apr-87  1513	hoey@nrl-aic.ARPA 	Re: How much memory for bignum or other large data structure?
C00247 00057	∂16-Apr-87  1517	Pavel.pa@Xerox.COM 	Re: typos in Cltl   
C00249 00058	∂16-Apr-87  1605	sandra%orion@cs.utah.edu 	bugnums (er, bignums)   
C00254 00059	∂16-Apr-87  1632	ghenis.pasa@Xerox.COM 	SOME and Multiple Values   
C00256 00060	∂16-Apr-87  1652	Masinter.pa@Xerox.COM 	Uncle Lisp Needs You  
C00258 00061	∂16-Apr-87  1703	pyramid!pyramid.UUCP!bein@hplabs.HP.COM 	Re: Bognumosity    
C00262 00062	∂16-Apr-87  1703	ghenis.pasa@Xerox.COM 	SETF and pathname slots    
C00264 00063	∂16-Apr-87  1736	FAHLMAN@C.CS.CMU.EDU 	SOME and Multiple Values    
C00266 00064	∂16-Apr-87  1917	diamant%hpfclp@hplabs.HP.COM 	Re: CLARIFICATION: [italics]package arguments.    
C00270 00065	∂16-Apr-87  2012	DON%atc.bendix.com@RELAY.CS.NET 	Bignums are bogus?    
C00272 00066	∂16-Apr-87  2137	fateman@mike.Berkeley.EDU 	Re:  Bignums are bogus?
C00274 00067	∂17-Apr-87  0723	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re: CLARIFICATION: [italics]package arguments. 
C00277 00068	∂17-Apr-87  0731	FAHLMAN@C.CS.CMU.EDU 	time to reactivate cl-cleanup    
C00280 00069	∂17-Apr-87  0959	RWK@YUKON.SCRC.Symbolics.COM 	SETF and pathname slots  
C00283 00070	∂17-Apr-87  1115	diamant%hpfclp@hplabs.HP.COM 	Re: CLARIFICATION: [italics]package arguments.    
C00287 00071	∂17-Apr-87  1122	Masinter.pa@Xerox.COM 	Re: time to reactivate cl-cleanup    
C00289 00072	∂17-Apr-87  1145	FAHLMAN@C.CS.CMU.EDU 	time to reactivate cl-cleanup    
C00292 00073	∂17-Apr-87  1200	Moon@ALDERAAN.SCRC.Symbolics.COM 	Language extensions (formerly [italics]package arguments.)   
C00297 00074	∂17-Apr-87  1329	FAHLMAN@C.CS.CMU.EDU 	Issue: FLET-IMPLICIT-BLOCK (Revision 4)    
C00306 00075	∂17-Apr-87  1408	FAHLMAN@C.CS.CMU.EDU 	Issue: FLET-IMPLICIT-BLOCK (Revision 5)    
C00315 00076	∂17-Apr-87  1525	Masinter.pa@Xerox.COM 	Issue: FUNCTION-TYPE (version 2)
C00323 00077	∂17-Apr-87  1536	Masinter.pa@Xerox.COM 	Issue FORMAT-ATSIGN-COLON (Version 3)
C00326 00078	∂17-Apr-87  1608	vrotney@vaxa.isi.edu 	Re: CLARIFICATION: [italics]package arguments.  
C00328 00079	∂17-Apr-87  1633	Masinter.pa@Xerox.COM 	Issue IF-BODY (Version 3)  
C00336 00080	∂17-Apr-87  1634	Masinter.pa@Xerox.COM 	status.report    
C00342 00081	∂17-Apr-87  1737	FAHLMAN@C.CS.CMU.EDU 	Issue: COMPILER-WARNING-STREAM (Revision 4)
C00347 00082	∂17-Apr-87  2007	FAHLMAN@C.CS.CMU.EDU 	Issue: DO-SYMBOLS-DUPLICATES (Revision 1)  
C00351 00083	∂17-Apr-87  2109	vrotney@vaxa.isi.edu 	Sec.11.7 [italics]package arguments.  
C00355 00084	∂17-Apr-87  2121	edsel!bhopal!jonl@navajo.stanford.edu 	CLARIFICATION: [italics]package arguments.    
C00359 00085	∂17-Apr-87  2229	MURRAY%cs.umass.edu@RELAY.CS.NET 	OR and Multiple Values    
C00362 00086	∂17-Apr-87  2236	MURRAY%cs.umass.edu@RELAY.CS.NET 	Fixnums Bogus   
C00364 00087	∂18-Apr-87  0049	Mailer@XX.LCS.MIT.EDU 	OR and Multiple Values
C00371 00088	∂18-Apr-87  0538	RPG  	Packages 
C00372 00089	∂18-Apr-87  1251	REM@IMSSS 	OR if some argument returns no values  
C00374 00090	∂18-Apr-87  1407	diamant%hpfclp@hplabs.HP.COM 	Re: CLARIFICATION: [italics]package arguments.    
C00379 00091	∂18-Apr-87  1444	FAHLMAN@C.CS.CMU.EDU 	OR if some argument returns no values 
C00381 00092	∂18-Apr-87  1628	Randy%acorn%LIVE-OAK.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	Re: SETF and pathname slots  
C00384 00093	∂18-Apr-87  1922	FAHLMAN@C.CS.CMU.EDU 	Environment-Arguments  
C00388 00094	∂18-Apr-87  2215	MURRAY%cs.umass.edu@RELAY.CS.NET 	MULTIPLE-VALUE-OR, and Consing 
C00392 00095	∂19-Apr-87  1029	primerd!doug@enx.prime.pdn 	Bigosities  
C00394 00096	∂19-Apr-87  1726	sandra%orion@cs.utah.edu 	Re: Bigosities
C00397 00097	∂19-Apr-87  1802	FAHLMAN@C.CS.CMU.EDU 	Issue ADJUST-ARRAY-DISPLACEMENT  
C00404 00098	∂19-Apr-87  2028	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue IF-BODY (Version 4)    
C00420 00099	∂19-Apr-87  2054	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: COMPILER-WARNING-STREAM (Revision 4) 
C00428 00100	∂19-Apr-87  2110	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: DO-SYMBOLS-DUPLICATES (Revision 1)   
C00432 00101	∂19-Apr-87  2115	FAHLMAN@C.CS.CMU.EDU 	Issue: COMPILER-WARNING-STREAM (Revision 4)
C00435 00102	∂19-Apr-87  2134	FAHLMAN@C.CS.CMU.EDU 	Issue: DO-SYMBOLS-DUPLICATES (Revision 1)  
C00438 00103	∂20-Apr-87  0625	DALY@IBM.COM 	Pavel's reply   
C00439 00104	∂20-Apr-87  0658	FAHLMAN@C.CS.CMU.EDU 	Issue IF-BODY (Version 4)   
C00448 00105	∂20-Apr-87  0658	preece%mycroft@gswd-vms.ARPA 	Bigosities
C00451 00106	∂20-Apr-87  0805	gls@Think.COM 	bignums are bogus   
C00453 00107	∂20-Apr-87  1027	RPG   	On the Kanji feature of Common Lisp   
C00457 00108	∂20-Apr-87  1126	Pavel.pa@Xerox.COM 	Re: Issue IF-BODY (Version 4) 
C00460 00109	∂20-Apr-87  1235	Moon@STONY-BROOK.SCRC.Symbolics.COM 	MULTIPLE-VALUE-OR, and Consing   
C00465 00110	∂20-Apr-87  1236	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Environment-Arguments  
C00471 00111	∂20-Apr-87  1448	Masinter.pa@Xerox.COM 	Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)    
C00474 00112	∂20-Apr-87  1358	Masinter.pa@Xerox.COM 	Re: Issue IF-BODY (Version 4)   
C00476 00113	∂20-Apr-87  1358	Masinter.pa@Xerox.COM 	Re: Issue: COMPILER-WARNING-STREAM (Revision 4)
C00478 00114	∂20-Apr-87  1420	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)    
C00484 00115	∂20-Apr-87  1517	Masinter.pa@Xerox.COM 	status 
C00491 00116	∂20-Apr-87  1653	Masinter.pa@Xerox.COM 	Re: Issue ADJUST-ARRAY-DISPLACEMENT  
C00493 00117	∂20-Apr-87  1911	FAHLMAN@C.CS.CMU.EDU 	Issue: COMPILER-WARNING-STREAM (Revision 4)
C00495 00118	∂21-Apr-87  0400	jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	Re: Re:  Bignums are bogus?   
C00498 00119	∂21-Apr-87  0747	FAHLMAN@C.CS.CMU.EDU 	Environment-Arguments  
C00503 00120	∂21-Apr-87  0814	Hvatum.DLAB@MIT-MULTICS.ARPA 	"Redefining" functions   
C00507 00121	∂21-Apr-87  0814	Hvatum.DLAB@MIT-MULTICS.ARPA 	Compiling CASE 
C00513 00122	∂21-Apr-87  0918	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue ADJUST-ARRAY-DISPLACEMENT  
C00516 00123	∂21-Apr-87  0919	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: FLET-IMPLICIT-BLOCK (Revision 5)    
C00518 00124	∂21-Apr-87  0920	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Environment-Arguments  
C00526 00125	∂21-Apr-87  0921	KMP@STONY-BROOK.SCRC.Symbolics.COM 	IF-BODY  
C00529 00126	∂21-Apr-87  1051	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
C00533 00127	∂21-Apr-87  1155	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Environment-Arguments  
C00535 00128	∂21-Apr-87  1215	FAHLMAN@C.CS.CMU.EDU 	IF-BODY 
C00537 00129	∂21-Apr-87  1222	FAHLMAN@C.CS.CMU.EDU 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)    
C00540 00130	∂21-Apr-87  1253	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
C00542 00131	∂21-Apr-87  1303	goldman@vaxa.isi.edu 	MULTIPLE-VALUES, consing, and clarity 
C00546 00132	∂21-Apr-87  1425	@DIAMOND.S4CC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	MULTIPLE-VALUES, consing, and clarity    
C00548 00133	∂21-Apr-87  1506	Pavel.pa@Xerox.COM 	Re: MULTIPLE-VALUES, consing, and clarity    
C00550 00134	∂21-Apr-87  1450	Pavel.pa@Xerox.COM 	[Gregor.pa: Re: ["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>: 
C00555 00135	∂21-Apr-87  1655	Moon@STONY-BROOK.SCRC.Symbolics.COM 	MULTIPLE-VALUES, consing, and clarity 
C00557 00136	∂21-Apr-87  1659	Moon@STONY-BROOK.SCRC.Symbolics.COM 	[Gregor.pa: Re: ["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>:    
C00560 00137	∂21-Apr-87  2309	MURRAY%cs.umass.edu@RELAY.CS.NET 	MULTPLE-VALUE-OR &rest args    
C00567 00138	∂22-Apr-87  1116	rauen@CLS.LCS.MIT.EDU 	Streams
C00569 00139	∂22-Apr-87  1232	KMP@STONY-BROOK.SCRC.Symbolics.COM 	ASSOC-RASSOC-IF-KEY (Version 1)   
C00573 00140	∂22-Apr-87  1343	KMP@STONY-BROOK.SCRC.Symbolics.COM 	AREF-1D  
C00578 00141	∂22-Apr-87  1351	KMP@STONY-BROOK.SCRC.Symbolics.COM 	ADJUST-ARRAY-NOT-ADJUSTABLE  
C00585 00142	∂22-Apr-87  2307	Moon@STONY-BROOK.SCRC.Symbolics.COM 	UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT 
C00591 00143	∂23-Apr-87  1205	smith@nrl-aic.ARPA 	A simple question   
C00593 00144	∂23-Apr-87  1250	Moon@STONY-BROOK.SCRC.Symbolics.COM 	A simple question 
C00595 00145	∂23-Apr-87  1255	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	A simple question   
C00598 00146	∂23-Apr-87  1313	REM@IMSSS 	Just for fun (NULL of NULL is identity)
C00600 00147	∂23-Apr-87  1822	RWK@YUKON.SCRC.Symbolics.COM 	A simple question   
C00603 00148	∂23-Apr-87  1858	KMP@STONY-BROOK.SCRC.Symbolics.COM 	A simple question  
C00608 00149	∂23-Apr-87  2022	RWK@YUKON.SCRC.Symbolics.COM 	Streams   
C00611 00150	∂23-Apr-87  2338	edsel!bhopal!jonl@navajo.stanford.edu 	A simple question    
C00613 00151	∂24-Apr-87  0741	decvax!cvbnet!admin!tbardasz@decwrl.DEC.COM 	Mailing List   
C00615 00152	∂24-Apr-87  0752	smith@nrl-aic.ARPA 	Re: A simple question    
C00617 00153	∂24-Apr-87  0843	DALY@IBM.COM 	CLtL typos list 
C00619 00154	∂24-Apr-87  2307	coffee@aerospace.aero.org 	Re: A simple question  
C00622 00155	∂25-Apr-87  0052	VERACSD@A.ISI.EDU 	Pronunciation   
C00623 00156	∂25-Apr-87  2132	@po5.andrew.cmu.edu:zs01#@andrew.cmu.edu 	Re: Pronunciation 
C00625 00157	∂25-Apr-87  2341	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Pronunciation 
C00627 00158	∂27-Apr-87  1008	unido!gmdzi!LISPM-1.GMD!@lispm-1.gmd.jc 	Pronunciation 
C00630 00159	∂27-Apr-87  1110	Moon@STONY-BROOK.SCRC.Symbolics.COM 	MULTPLE-VALUE-OR &rest args 
C00634 00160	∂27-Apr-87  1119	coffee@aerospace.aero.org 	Cleaning up predicate returns    
C00639 00161	∂27-Apr-87  1206	larus@paris.Berkeley.EDU 	(reduce #'or ...)  
C00641 00162	∂27-Apr-87  1338	quiroz@rochester.arpa 	Re: (reduce #'or ...) 
C00644 00163	∂27-Apr-87  1340	coffee@aerospace.aero.org 	Very BIG "T" 
C00646 00164	∂27-Apr-87  1517	Mailer@XX.LCS.MIT.EDU 	(reduce #'or ...)
C00649 00165	∂28-Apr-87  2212	MURRAY%cs.umass.edu@RELAY.CS.NET 	MULTIPLE-VALUES OR   
C00653 00166	∂28-Apr-87  2240	MURRAY%cs.umass.edu@RELAY.CS.NET 	(REDUCE #'OVERHEAD (MAP ...))  
C00657 00167	∂29-Apr-87  1407	gls@Think.COM 	CLtL typos list
C00660 00168	∂30-Apr-87  1113	@ACORN.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU 	(REDUCE #'OVERHEAD (MAP ...))  
C00662 00169	∂30-Apr-87  1355	FAHLMAN@C.CS.CMU.EDU 	Notice on Kyoto Common Lisp distribution   
C00665 00170	∂01-May-87  1440	EMAILDEV%UKACRL.BITNET@BERKELEY.EDU 	Notice on Kyoto Common Lisp distribution   
C00667 00171	∂05-May-87  1825	FAHLMAN@C.CS.CMU.EDU 	Kyoto Common Lisp addendum  
C00672 00172	∂08-May-87  1725	kempf%hplabsc@hplabs.HP.COM 	Rule System in CommonLoops/CLOS
C00674 00173	∂09-May-87  0501	TMB%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	Smalltalk-80 Classes for Symbolics and/or CommonLisp    
C00676 00174	∂12-May-87  0301	@REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU 	atom type question   
C00677 00175	∂12-May-87  0637	FAHLMAN@C.CS.CMU.EDU 	atom type question
C00679 00176	∂12-May-87  0715	RAM@C.CS.CMU.EDU 	atom type question    
C00682 00177	∂12-May-87  1753	RWK@YUKON.SCRC.Symbolics.COM 	atom type question  
C00687 00178	∂13-May-87  1426	berman@vaxa.isi.edu 	&REST    
C00691 00179	∂13-May-87  1512	DLW@ALDERAAN.SCRC.Symbolics.COM 	&REST  
C00693 00180	∂14-May-87  0913	coffee@aerospace.aero.org 	Re: &REST    
C00696 00181	∂14-May-87  1107	berman@vaxa.isi.edu 	Re: &REST     
C00698 00182	∂14-May-87  1314	coffee@aerospace.aero.org 	Re: Gold Hill's floating-point   
C00700 00183	∂14-May-87  1438	berman@vaxa.isi.edu 	documentation 
C00703 00184	∂14-May-87  1507	edsel!bhopal!jonl@navajo.stanford.edu 	Re: &REST  
C00706 00185	∂14-May-87  1724	FAHLMAN@C.CS.CMU.EDU 	documentation
C00708 00186	∂15-May-87  1035	coffee@aerospace.aero.org 	Re: Gold Hill's floating-point   
C00714 00187	∂15-May-87  1331	@ACORN.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU 	(REDUCE #'OVERHEAD (MAP ...))  
C00719 00188	∂15-May-87  1333	Mailer@XX.LCS.MIT.EDU 	Re: &REST   
C00722 00189	∂15-May-87  1403	ACUFF@SUMEX-AIM.STANFORD.EDU 	Re: &REST 
C00724 00190	∂15-May-87  1747	@ACORN.CS.ROCHESTER.EDU,@CASHEW.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU 	Last message to list.    
C00726 00191	∂17-May-87  1532	dg%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: &REST
C00728 00192	∂18-May-87  0603	dml@nadc 	Addition to mailing list.
C00729 00193	∂18-May-87  0811	FAHLMAN@C.CS.CMU.EDU 	Mailing List for Lucid Users
C00733 00194	∂18-May-87  1151	@RELAY.CS.NET:a37078%tansei.u-tokyo.junet@UTOKYO-RELAY.CSNET 	Introduction to a multi-byte character extension
C00739 00195	∂18-May-87  1158	@RELAY.CS.NET:a37078%tansei.u-tokyo.junet@UTOKYO-RELAY.CSNET 	A multi-byte character extension proposal  
C00781 00196	∂18-May-87  1547	berman@vaxa.isi.edu 	Format   
C00784 00197	∂18-May-87  1719	barmar@Think.COM 	Format 
C00787 00198	∂18-May-87  1736	Olasov.StudentNS@MIT-Multics.ARPA 	Communications packages in Common LISP  
C00789 00199	∂18-May-87  2222	@RELAY.CS.NET:MURRAY@cs.umass.edu 	User-Visible Declarations and Proclamations  
C00793 00200	∂19-May-87  1136	Moon@STONY-BROOK.SCRC.Symbolics.COM 	User-Visible Declarations and Proclamations
C00797 00201	∂19-May-87  1139	berman@vaxa.isi.edu 	~% Directive  
C00799 00202	∂19-May-87  1220	FAHLMAN@C.CS.CMU.EDU 	~% Directive 
C00802 00203	∂19-May-87  1347	berman@vaxa.isi.edu 	More FORMAT   
C00806 00204	∂19-May-87  1511	Moon@STONY-BROOK.SCRC.Symbolics.COM 	More FORMAT  
C00809 00205	∂19-May-87  1524	berman@vaxa.isi.edu 	Re: More FORMAT    
C00812 00206	∂19-May-87  1608	barmar@Think.COM 	Re: More FORMAT  
C00816 00207	∂19-May-87  1618	Daniels.pa@Xerox.COM 	Re: More FORMAT   
C00820 00208	∂19-May-87  1802	sandra%orion@cs.utah.edu 	All arrays can be adjustable?
C00825 00209	∂19-May-87  1835	Moon@STONY-BROOK.SCRC.Symbolics.COM 	All arrays can be adjustable?    
C00830 00210	∂19-May-87  2000	DLA@DIAMOND.S4CC.Symbolics.COM 	All arrays can be adjustable?    
C00832 00211	∂19-May-87  2000	@DIAMOND.S4CC.Symbolics.COM:Cyphers@YUKON.SCRC.Symbolics.COM 	All arrays can be adjustable?    
C00836 00212	∂19-May-87  2342	KMP@STONY-BROOK.SCRC.Symbolics.COM 	adjustable arrays  
C00840 00213	∂20-May-87  0248	Mailer@XX.LCS.MIT.EDU 	Re: More FORMAT  
C00842 00214	∂20-May-87  0635	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	All arrays can be adjustable? 
C00845 00215	∂20-May-87  0836	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re: More FORMAT  
C00848 00216	∂20-May-87  0841	DLW@ALDERAAN.SCRC.Symbolics.COM 	All arrays can be adjustable?   
C00852 00217	∂20-May-87  0851	franz!ficl!jkf@ucbarpa.Berkeley.EDU 	adjustable arrays 
C00855 00218	∂20-May-87  0859	FAHLMAN@C.CS.CMU.EDU 	All arrays can be adjustable?    
C00858 00219	∂20-May-87  0955	@RELAY.CS.NET:DUSSUD%Jenner@TI-CSL.CSNET 	[dg%acorn@oak.lcs.mit.edu:  Re: &REST]
C00862 00220	∂20-May-87  1013	johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK   
C00863 00221	∂20-May-87  1039	las@bfly-vax.bbn.com
C00865 00222	∂20-May-87  1123	barmar@Think.COM 	DISASSEMBLE, et all return values    
C00867 00223	∂20-May-87  1158	berman@vaxa.isi.edu 	Re: More FORMAT    
C00869 00224	∂20-May-87  1210	berman@vaxa.isi.edu 
C00871 00225	∂20-May-87  1239	berman@vaxa.isi.edu 	las@bfly-vax.bbn.com    
C00872 00226	∂20-May-87  1247	las@bfly-vax.bbn.com
C00875 00227	∂20-May-87  1251	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	All arrays can be adjustable? 
C00878 00228	∂20-May-87  1359	peck@Sun.COM 	Order of evaluation in PUSH (& PUSHNEW)  
C00882 00229	∂20-May-87  1551	berman@vaxa.isi.edu 	:fill-pointer maybe
C00884 00230	∂20-May-87  1623	berman@vaxa.isi.edu 	arrays   
C00887 00231	∂20-May-87  1647	FAHLMAN@C.CS.CMU.EDU 	:fill-pointer maybe    
C00892 00232	∂20-May-87  1658	FAHLMAN@C.CS.CMU.EDU 	arrays  
C00895 00233	∂20-May-87  1840	berman@vaxa.isi.edu 	arrays   
C00898 00234	∂20-May-87  1840	FAHLMAN@C.CS.CMU.EDU 	:fill-pointer maybe    
C00903 00235	∂20-May-87  1840	FAHLMAN@C.CS.CMU.EDU 	arrays  
C00906 00236	∂20-May-87  1844	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Order of evaluation in PUSH (& PUSHNEW)    
C00910 00237	∂20-May-87  1844	Moon@STONY-BROOK.SCRC.Symbolics.COM 	arrays  
C00914 00238	∂20-May-87  1902	rauen@CLS.LCS.MIT.EDU 	Roman numeral hacking.
C00915 00239	∂20-May-87  1911	ibuki!weaver@labrea.stanford.edu 	Order of evaluation in PUSH    
C00917 00240	∂20-May-87  1955	edsel!bhopal!jonl@navajo.stanford.edu 	[adjustable arrays?] More FORMAT    
C00920 00241	∂20-May-87  2037	quiroz@cs.rochester.edu 	Re: Order of evaluation in PUSH (& PUSHNEW)  
C00925 00242	∂20-May-87  2134	FAHLMAN@C.CS.CMU.EDU 	Order of evaluation in PUSH (& PUSHNEW)    
C00928 00243	∂20-May-87  2209	Mailer@XX.LCS.MIT.EDU 	[dg%acorn@oak.lcs.mit.edu:  Re: &REST]    
C00931 00244	∂20-May-87  2254	edsel!bhopal!jonl@navajo.stanford.edu 	All arrays can be adjustable?  
C00934 00245	∂21-May-87  0556	@diamond.s4cc.symbolics.com,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	[adjustable arrays?] More FORMAT    
C00938 00246	∂21-May-87  0725	DALY@IBM.COM 	validation suite
C00939 00247	∂21-May-87  0938	moss!tk@harvard.harvard.edu 	Re: Notice on Kyoto Common Lisp distribution (query)    
C00941 00248	∂21-May-87  0945	larus%paris.Berkeley.EDU@Berkeley.EDU 	Re: Order of evaluation in PUSH (& PUSHNEW)   
C00944 00249	∂21-May-87  1019	DLW@ALDERAAN.SCRC.Symbolics.COM 	[adjustable arrays?] More FORMAT
C00946 00250	∂21-May-87  1124	@DIAMOND.S4CC.Symbolics.COM:PTW@YUKON.SCRC.Symbolics.COM 	Re: Order of evaluation in PUSH (& PUSHNEW)    
C00948 00251	∂21-May-87  1148	berman@vaxa.isi.edu 	Re: :fill-pointer maybe 
C00950 00252	∂21-May-87  1156	berman@vaxa.isi.edu 	Re: validation suite    
C00952 00253	∂21-May-87  1220	FAHLMAN@C.CS.CMU.EDU 	:fill-pointer maybe    
C00954 00254	∂21-May-87  1323	Mailer@xx.lcs.mit.edu 	All arrays can be adjustable?   
C00957 00255	∂21-May-87  1347	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Order of evaluation in PUSH (& PUSHNEW)     
C00960 00256	∂21-May-87  1411	larus%paris.Berkeley.EDU@Berkeley.EDU 	Re: Order of evaluation in PUSH (& PUSHNEW)   
C00966 00257	∂22-May-87  0152	Randy%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: Order of evaluation in general  
C00969 00258	∂22-May-87  0718	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re: Order of evaluation in general   
C00972 00259	∂22-May-87  0729	gls@Think.COM 	All arrays can be adjustable? 
C00975 00260	∂22-May-87  0748	gls@Think.COM 	Re: More FORMAT     
C00978 00261	∂22-May-87  0801	gls@Think.COM 	numerals, Roman, large, overly, printing of, how to do it   
C00980 00262	∂22-May-87  0815	FAHLMAN@C.CS.CMU.EDU 	numerals, Roman, large, overly, printing of, how to do it 
C00982 00263	∂22-May-87  1257	berman@vaxa.isi.edu 	:KEY, hairsplit    
C00986 00264	∂22-May-87  1449	primerd!doug@enx.prime.pdn    
C00990 00265	∂22-May-87  1609	DLW@ALDERAAN.SCRC.Symbolics.COM 	defsystem   
C00993 00266	∂25-May-87  0459	GZ%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	All arrays can be adjustable?   
C00995 00267	∂25-May-87  1032	primerd!doug@enx.prime.pdn 	Revision 2.1 of public defsystem available
C00997 00268	∂01-Jun-87  0840	DALY@IBM.COM 	type specifiers 
C00999 00269	∂01-Jun-87  1929	RWK@YUKON.SCRC.Symbolics.COM 	type specifiers
C01003 00270	∂03-Jun-87  0739	Mailer@XX.LCS.MIT.EDU 	SIMPLE-VECTOR    
C01008 00271	∂03-Jun-87  1004	gls@Think.COM 	Latin
C01010 00272	∂03-Jun-87  1505	RWK@YUKON.SCRC.Symbolics.COM 	SIMPLE-VECTOR  
C01014 00273	∂03-Jun-87  1856	Moon@STONY-BROOK.SCRC.Symbolics.COM 	SIMPLE-VECTOR
C01017 00274	∂04-Jun-87  0802	RAM@C.CS.CMU.EDU 	SIMPLE-VECTOR    
C01019 00275	∂04-Jun-87  1425	RWK@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	SIMPLE-VECTOR   
C01021 00276	∂04-Jun-87  2350	@Score.Stanford.EDU,@MCC.COM:krall%pp.mcc.com@mcc.com 	Interpretation Needed for #+feature
C01024 00277	∂05-Jun-87  0734	samalone@ATHENA.MIT.EDU 	Re: Interpretation Needed for #+feature 
C01026 00278	∂05-Jun-87  1017	sandra%orion@cs.utah.edu 	historical question about CASE    
C01028 00279	∂05-Jun-87  1019	RPG   	JIS LISP WG of this year    
C01031 00280	∂05-Jun-87  1020	RPG   	Re: JIS LISP WG of this year
C01033 00281	∂05-Jun-87  1142	barmar@Think.COM 	historical question about CASE  
C01037 00282	∂05-Jun-87  1313	SOLEY@XX.LCS.MIT.EDU 	historical question about CASE   
C01040 00283	∂05-Jun-87  1400	gls@Think.COM 	historical question about CASE
C01044 00284	∂05-Jun-87  1400	barmar@Think.COM 	historical question about CASE  
C01046 00285	∂10-Jun-87  0755	dml@NADC.ARPA 	Common LISP omissions: Collect, Locatives    
C01051 00286	∂10-Jun-87  0837	FAHLMAN@C.CS.CMU.EDU 	Common LISP omissions: Collect, Locatives  
C01054 00287	∂10-Jun-87  1101	hoey@nrl-aic.ARPA 	LISP:STRUCTURE ?
C01056 00288	∂10-Jun-87  1120	RAM@C.CS.CMU.EDU 	LISP:STRUCTURE ? 
C01058 00289	∂10-Jun-87  1121	KMP@STONY-BROOK.SCRC.Symbolics.COM 	LISP:STRUCTURE
C01060 00290	∂10-Jun-87  1238	DALY@IBM.COM 	locatives...    
C01062 00291	∂10-Jun-87  1415	Moon@VALLECITO.SCRC.Symbolics.COM 	Common LISP omissions: Locatives   
C01070 00292	∂11-Jun-87  1313	gls@Think.COM 	Re: historical question about CASE 
C01073 00293	∂12-Jun-87  1022	dml@NADC.ARPA 	Hash-on-eq
C01075 00294	∂22-Jun-87  0422	fritzson@bigburd.PRC.Unisys.COM 	APPLY with 3+ arguments    
C01077 00295	∂22-Jun-87  0601	dml@NADC.ARPA 	Re:  APPLY with 3+ arguments  
C01079 00296	∂22-Jun-87  0654	@RELAY.CS.NET:kers@HPLB.CSNET 	I Like a Single Namespace    
C01091 00297	∂22-Jun-87  0655	samalone@ATHENA.MIT.EDU 	Re: APPLY with 3+ arguments   
C01094 00298	∂22-Jun-87  0741	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	APPLY with 3+ arguments  
C01097 00299	∂22-Jun-87  0959	barmar@Think.COM 	I Like a Single Namespace  
C01100 00300	∂22-Jun-87  1359	Daniels.pa@Xerox.COM 	Re: APPLY with 3+ arguments 
C01102 00301	∂22-Jun-87  1457	Daniels.pa@Xerox.COM 	Re: APPLY with 3+ arguments 
C01104 00302	∂23-Jun-87  0252	@RELAY.CS.NET:kers@HPLB.CSNET 
C01106 00303	∂23-Jun-87  0654	CL.BOYER@R20.UTEXAS.EDU 	Kyoto Common Lisp   
C01130 00304	∂23-Jun-87  1535	BAGGINS@IBM.COM 	A multi-byte character extension proposal  
C01139 00305	∂25-Jun-87  0923	@RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET 	Re:  A multi-byte character extension proposal    
C01149 00306	∂25-Jun-87  1028	@RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET 	Re:  A multi-byte character extension proposal    
C01159 00307	∂25-Jun-87  1143	@RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET 	Re:  A multi-byte character extension proposal    
C01169 00308	∂25-Jun-87  1255	@RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET 	Re:  A multi-byte character extension proposal    
C01179 00309	∂25-Jun-87  1505	@RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET 	Re:  A multi-byte character extension proposal    
C01189 00310	∂25-Jun-87  1626	Cassels@STONY-BROOK.SCRC.Symbolics.COM 	Format ~E nit -- language lawyer sought 
C01191 00311	∂26-Jun-87  1911	VERACSD@A.ISI.EDU 	MODIFYF    
C01194 00312	∂26-Jun-87  2250	@RELAY.CS.NET:CORK@cs.umass.edu 	Tracing locally defined functions    
C01200 00313	∂27-Jun-87  1337	sandra%orion@cs.utah.edu 	print question
C01203 00314	∂28-Jun-87  1146	edsel!bhopal!jonl@navajo.stanford.edu 	print question  
C01206 00315	∂28-Jun-87  1801	RWK@YUKON.SCRC.Symbolics.COM 	Tracing locally defined functions  
C01211 00316	∂29-Jun-87  0707	dml@NADC.ARPA 	Re:  MODIFYF   
C01214 00317	∂29-Jun-87  1031	Mailer@xx.lcs.mit.edu 	print question   
C01217 00318	∂29-Jun-87  2210	@RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET 	Re:  A multi-byte character extension proposal    
C01231 00319	∂30-Jun-87  1021	@RELAY.CS.NET:HASSETT@sp.unisys.com 	2 namespaces & a complement to #' notation 
C01237 00320	∂01-Jul-87  0742	@Score.Stanford.EDU,@MCC.COM:krall%pp.mcc.com@mcc.com 	Flavors for KCL
C01239 00321	∂02-Jul-87  0534	mab@mind.Princeton.EDU 	Loop Macro (after Zetalisp, franz, etc.) 
C01241 00322	∂02-Jul-87  0812	mab@flash.bellcore.com 	Loop Macro (after Zetalisp, Franz, etc.) 
C01243 00323	∂02-Jul-87  0911	kempf%hplabsc@hplabs.HP.COM 	Location of defsys.l?
C01245 00324	∂02-Jul-87  1355	@RELAY.CS.NET:GREENBERG@cs.umass.edu 	Questions about (function eq)   
C01248 00325	∂02-Jul-87  1510	barmar@Think.COM 	Questions about (function eq)   
C01256 00326	∂02-Jul-87  1643	primerd!enx!doug@EDDIE.MIT.EDU
C01259 00327	∂02-Jul-87  1651	jeff%JASPER.Palladian.COM@XX.LCS.MIT.EDU 	Loop Macro (after Zetalisp, Franz, etc.)   
C01265 00328	∂06-Jul-87  0937	@Score.Stanford.EDU,@MCC.COM:krall%pp.mcc.com@mcc.com 	Atoms in association lists    
C01268 00329	∂06-Jul-87  1838	OKUNO@SUMEX-AIM.STANFORD.EDU 	Re: Flavors for KCL 
C01270 00330	∂07-Jul-87  0918	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Atoms in association lists   
C01278 00331	∂07-Jul-87  1902	OKUNO@SUMEX-AIM.STANFORD.EDU 	Re: Flavors for KCL 
C01280 00332	∂08-Jul-87  0938	coffee@aerospace.aero.org 	Re: Atoms in association lists   
C01283 00333	∂08-Jul-87  1224	dml@NADC.ARPA 	Re: Atoms in association lists
C01285 00334	∂08-Jul-87  1448	Daniels.pa@Xerox.COM 	Re: Atoms in association lists   
C01287 00335	∂08-Jul-87  2038	edsel!bhopal!jonl@navajo.stanford.edu 	print question  
C01289 00336	∂08-Jul-87  2202	edsel!bhopal!jonl@navajo.stanford.edu 	Loop Macro (after Zetalisp, franz, etc.) 
C01291 00337	∂09-Jul-87  0358	sidney%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Atoms in association lists    
C01293 00338	∂09-Jul-87  0359	sidney%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: Atoms in association lists
C01296 00339	∂09-Jul-87  0452	@DIAMOND.S4CC.Symbolics.COM:Cyphers@YUKON.SCRC.Symbolics.COM 	Re: Atoms in association lists   
C01299 00340	∂09-Jul-87  0521	thoms@caen.engin.umich.edu 	OPS5   
C01301 00341	∂09-Jul-87  0546	dml@NADC.ARPA 	Re: Atoms in association lists
C01303 00342	∂09-Jul-87  0621	dml@NADC.ARPA 	Plists and NIL.
C01305 00343	∂09-Jul-87  0919	johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK 	kcl   
C01307 00344	∂09-Jul-87  0930	@RELAY.CS.NET:hagiya%kurims.kurims.kyoto-u.junet@UTOKYO-RELAY.CSNET 	Re: Flavors for KCL  
C01311 00345	∂09-Jul-87  1118	jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	UK KCL    
C01313 00346	∂09-Jul-87  1207	AI.BOYER@MCC.COM 	Re: kcl
C01314 00347	∂09-Jul-87  1207	Daniels.pa@Xerox.COM 	Re: Plists and NIL.    
C01316 00348	∂09-Jul-87  1208	vax135!lcuxle!elia@ucbvax.Berkeley.EDU 	macrolet  
C01319 00349	∂09-Jul-87  1404	berman@vaxa.isi.edu 	Validation suite   
C01322 00350	∂09-Jul-87  1856	STEVER%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	Plists and NIL.   
C01325 00351	∂10-Jul-87  0809	sandra%orion@cs.utah.edu 	special forms 
C01327 00352	∂10-Jul-87  0942	RAM@C.CS.CMU.EDU 	special forms    
C01330 00353	∂10-Jul-87  1116	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Appropriate use of the Common-Lisp mailing list  
C01334 00354	∂10-Jul-87  1116	KMP@STONY-BROOK.SCRC.Symbolics.COM 	macrolet 
C01340 00355	∂10-Jul-87  1127	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Plists and NIL.    
C01347 00356	∂14-Jul-87  0816	kempf%hplabsz@hplabs.HP.COM 	Re:  Appropriate use of the Common-Lisp mailing list    
C01351 00357	∂14-Jul-87  0922	skh@spice.cs.cmu.edu 	Apropos case sensitive?
C01353 00358	∂14-Jul-87  0929	@MCC.COM:root%bell.cad.mcc.com@mcc.com 	Test - Please ignore
C01354 00359	∂14-Jul-87  1946	vrotney@venera.isi.edu 	Re: Apropos case sensitive?    
C01358 00360	∂15-Jul-87  2313	@RELAY.CS.NET:HELLER@cs.umass.edu 	RE: Apropos case sensitive?   
C01362 00361	∂16-Jul-87  0624	kanya@caen.engin.umich.edu 	Prolog 
C01364 00362	∂16-Jul-87  1123	DALY@IBM.COM 	pathnames, portability, ed, eval-when, compile-file, fasl files   
C01369 00363	∂16-Jul-87  1609	RAM@C.CS.CMU.EDU 	editor issues    
C01374 00364	∂16-Jul-87  1630	RAM@C.CS.CMU.EDU 	eval-when issues 
C01380 00365	∂17-Jul-87  1026	edsel!bhopal!jonl@labrea.stanford.edu 	Appropriate use of the Common-Lisp mailing list    
C01384 00366	∂20-Jul-87  1132	Kahn.pa@Xerox.COM 	Re: Prolog 
C01386 00367	∂20-Jul-87  2130	edsel!bhopal!jonl@labrea.stanford.edu 	Apropos case sensitive?   
C01391 00368	∂22-Jul-87  0715	EJS%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: Atoms in association lists   
C01396 00369	∂23-Jul-87  1222	VERACSD@A.ISI.EDU 	Toplevel lexical variables
C01400 00370	∂23-Jul-87  1509	pierson@multimax.ARPA 	Toplevel lexical variables 
C01402 00371	∂23-Jul-87  1739	VERACSD@A.ISI.EDU 	Correction 
C01405 00372	∂24-Jul-87  0806	SWM@SAPSUCKER.SCRC.Symbolics.COM 	Correction 
C01408 00373	∂24-Jul-87  0939	Gregor.pa@Xerox.COM 	Re: Correction
C01411 00374	∂24-Jul-87  1020	SWM@SAPSUCKER.SCRC.Symbolics.COM 	Re: Correction  
C01415 00375	∂24-Jul-87  1043	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re: Correction   
C01417 00376	∂24-Jul-87  1218	barmar@think.com 	Re: Correction   
C01420 00377	∂25-Jul-87  2249	@RELAY.CS.NET:MURRAY@cs.umass.edu 	EOF-VALUE 
C01423 00378	∂26-Jul-87  1433	smh@EMS.MEDIA.MIT.EDU 	Re:  EOF-VALUE   
C01425 00379	∂26-Jul-87  1623	@REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU 	EOF-VALUE  
C01429 00380	∂27-Jul-87  0949	barmar@think.com 	EOF-VALUE   
C01432 00381	∂27-Jul-87  1423	gls@Think.COM 	EOF-VALUE 
C01434 00382	∂27-Jul-87  1447	SCHMIDT@SUMEX-AIM.STANFORD.EDU 	Re: Toplevel lexical variables   
C01436 00383	∂27-Jul-87  1706	pierson@multimax.ARPA 	Toplevel lexical variables 
C01438 00384	∂28-Jul-87  0050	wade@wombat.stanford.edu 	EOF value
C01439 00385	∂29-Jul-87  0039	@RELAY.CS.NET:MURRAY@cs.umass.edu 	*eof-value*    
C01442 00386	∂29-Jul-87  0648	smh@EMS.MEDIA.MIT.EDU 	Re:  *eof-value* 
C01446 00387	∂31-Jul-87  1455	wile@vaxa.isi.edu 	Test Suite availability   
C01450 00388	∂31-Jul-87  2159	sandra%orion@cs.utah.edu 	compile-time processing of REQUIRE
C01453 00389	∂01-Aug-87  1031	smh@EMS.MEDIA.MIT.EDU 	Re:  compile-time processing of REQUIRE   
C01455 ENDMK
C⊗;
∂12-Apr-87  0005	kempf%hplabsc@hplabs.HP.COM 	Re:  redefining Common Lisp functions    
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 12 Apr 87  00:05:28 PDT
Received: from hplabsc by hplabs.HP.COM with TCP ; Sat, 11 Apr 87 21:44:51 pst
Received: by hplabsc ; Sat, 11 Apr 87 21:44:52 pst
Date: Sat, 11 Apr 87 21:44:52 pst
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8704120544.AA05619@hplabsc>
To: common-lisp@sail.stanford.edu, masinter.PA@Xerox.COM
Subject: Re:  redefining Common Lisp functions

In the process of implementing CommonObjects on CommonLoops (COOL)
I found it necessary to re-implement the following functions:
EQUAL, EQL, EQUALP, TYPEP, and TYPE-OF. I tried a number of ways
to do this, but none seemed safe (= infinite recursions) or 
effective (= slowed down the system), except to provide a macro
which a user actually wanting the semantics of the redefined functions
could invoke. This macro defined the functions on uninterned symbols
then shadowing imported the symbols into the package where the user
wanted them. Although this sounds inconvenient, it did allow me to
match CommonObjects semantics (at the user's option, however) which
require these functions to be user specializable, i.e. generic functions.

		Jim Kempf	kempf@hplabs.hp.com

PS: Portable CommonLoops already allows PRINC and other print functions
to be specialized via. the :PRINT-FUNCTION option. Don't remember if
that made it into the standard, since my CLOS specification is at the
office.

∂12-Apr-87  1750	edsel!bhopal!jonl@navajo.stanford.edu 	all symbols [and delayed mail] 
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Apr 87  17:50:50 PDT
Received: by navajo.stanford.edu; Sun, 12 Apr 87 17:49:09 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
	id AA15379; Sun, 12 Apr 87 15:58:51 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
	id AA04732; Sun, 12 Apr 87 16:55:48 PDT
Date: Sun, 12 Apr 87 16:55:48 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704122355.AA04732@bhopal.edsel.com>
To: navajo!Common-Lisp%sail@navajo.stanford.edu
Subject:  all symbols [and delayed mail]

[The following message was sent when the "775 LISP symbols" was a hot
topic.  Unfortunately, the gateway at navajo.stanford.edu seems to be
a bit recalcitrant -- a problem suffered all too often.]

Return-Path: <navajo!MAILER-DAEMON>
Date: Fri, 10 Apr 87 17:33:35 PST
From: Mail Delivery Subsystem <navajo!MAILER-DAEMON>
Subject: Returned mail: Cannot send message for 3 days
To: bhopal!jonl@edsel.com

   ----- Transcript of session follows -----

   ----- Unsent message follows -----
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
	id AA01258; Tue, 7 Apr 87 14:10:20 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
	id AA25834; Tue, 7 Apr 87 15:06:28 PDT
Date: Tue, 7 Apr 87 15:06:28 PDT
From: edsel!bhopal!jonl (Jon L White)
Message-Id: <8704072206.AA25834@bhopal.edsel.com>
To: navajo!smh%EMS.MEDIA.MIT.EDU
Cc: navajo!DALY%ibm.com,
        navajo!common-lisp%sail navajo!hornig%QUABBIN.SCRC.Symbolics.COM
In-Reply-To: navajo!smh@EMS.MEDIA.MIT.EDU's message of Tue, 7 Apr 87 11:31:13 EST
Subject:  all symbols

I don't think SIZE belongs in the Lisp package -- it isn't one of the
symbols mentioned in CLtL, p160, as optimization qualities.  Perhaps
it is a Franz extension?

As to how it came about that Symbolics has 775 symbols: it occured
nearly a year ago, before the Franz-circulated list I believe, as a 
consequence of a cooperative effort between Symbolics and Lucid.
I found the following msg header in my old mail file:

    Date: Sun, 18 May 86 18:09 EDT
    From: Daniel L. Weinreb <Navajo!DLW@SCRC-QUABBIN.ARPA>
    Subject: Orthodoxy in the package world layout.
    To: edsel!bhopal!jonl@SU-NAVAJO.ARPA
    Cc: dlw@SCRC-QUABBIN.ARPA
    In-Reply-To: <8605180533.AA25219@bhopal.edsel.uucp>

    Yes, it is certainly our intention that the CL package contain exactly
    the documented external symbols, and we've tried hard to get it right.
    Checking our set against your set is clearly an excellent cross-check.
    In fact, I'm surprised none of us ever thought of it.  I'm glad you did,
    and thanks for doing the comparison.  Now, lemme see what I can figure
    out about these discrepencies and how to fix them.

    . . . 


-- JonL --

∂12-Apr-87  1751	edsel!bhopal!jonl@navajo.stanford.edu 	redefining Common Lisp functions    
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Apr 87  17:50:56 PDT
Received: by navajo.stanford.edu; Sun, 12 Apr 87 17:49:15 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
	id AA15405; Sun, 12 Apr 87 16:09:47 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
	id AA04788; Sun, 12 Apr 87 17:06:46 PDT
Date: Sun, 12 Apr 87 17:06:46 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704130006.AA04788@bhopal.edsel.com>
To: navajo!Common-Lisp%sail@navajo.stanford.edu
Subject: redefining Common Lisp functions

Unfortunately, it is hard for an implementation to determine when a user 
is truly "redefining" a function, or merely changing it's symbol-function
cell in a way compatible with portable Common Lisp.  The most obvious case 
in point is the need to install "wrapper-like" function in order to do 
traceing.  A user ought to be able to implement his own monitoring scheme, 
which would involve changing the contents of the symbol-function cell of 
an arbitrary Common Lisp function (name), without bumping into some kind 
of hard barrier.

-- JonL --

∂12-Apr-87  2225	HEWETT@SUMEX-AIM.STANFORD.EDU 	Redefining CL fns  
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Apr 87  22:25:45 PDT
Date: Sun, 12 Apr 87 22:24:43 PDT
From: Mike Hewett <HEWETT@SUMEX-AIM.STANFORD.EDU>
Subject: Redefining CL fns
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <12294088425.12.HEWETT@SUMEX-AIM.STANFORD.EDU>

As someone more concerned with using Common LISP and in
the portability of it, I can't believe any responsible 
software engineer would even think of redefining a
CL-defined function, macro, or special form.

Therefore, the question of allowing redefinition is purely
a CL environment implementation question, and I would think
that it should be perfectly legal to protect the user from
himself and not allow redefinition.

Mike Hewett
(HEWETT@SUMEX-AIM.STANFORD.EDU)
-------

∂13-Apr-87  1018	sears%wrs.DEC@decwrl.DEC.COM 	Re:  Redefining Common LISP Functions, MACROS and Special Forms  
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 13 Apr 87  10:17:56 PDT
Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
	id AA20408; Mon, 13 Apr 87 09:17:36 PST
Message-Id: <8704131717.AA20408@decwrl.dec.com>
Date: Monday, 13 Apr 1987 09:57:04-PDT
From: sears%wrs.DEC@decwrl.DEC.COM
To: common-lisp@sail.stanford.edu, sears%wrs.DEC@decwrl.DEC.COM
Subject: Re:  Redefining Common LISP Functions, MACROS and Special Forms

I think this is a deep issue in the language.  This is especially
true for those applications that are evolving systems starting from
COMMON-LISP as a base.   I think the questions are:

	1.  What is the protocol for adding an extension for an
	    interpreted function.

	2.  What is the protocol for adding an extension that is compiled.

	3.  How are "META" functions, such as SETF and DEFSTRUCT,
            to be handled.

        4.  Are some functions to be handled differently than others?
            (Forms like OR and MULTIPLE-VALUE-RETURN).

In the case of (1), changing the function cell seems to be adequate.

In the case of (2), the compiler needs to know which definition is
intended.  Using a new symbol solves this problem.

The problem in the case of (3) is that a redefined function may imply
(or not) a change to SETF.  DEFSETF is the function that does this, but
it in turn is affected by compilation.  A related problem is the handling
of DEFSTRUCT accessor, creator and setting functions. 

In the case of (4), it may well be the case that the language can
be defined as consisting of layers, but this should be specified explicitly
if this is to be the case.

I think the exact handling of these features needs to be defined in
a way that gives the system builder explicit control.

/wrs

∂13-Apr-87  1216	gls@Think.COM 	redefining Common Lisp functions   
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 13 Apr 87  12:16:35 PDT
Received: from falling-star by Think.COM via CHAOS; Mon, 13 Apr 87 14:19:17 EST
Date: Mon, 13 Apr 87 15:16 EDT
From: Guy Steele <gls@Think.COM>
Subject: redefining Common Lisp functions
To: masinter.PA@xerox.com, common-lisp@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <870411-154536-1554@Xerox>
Message-Id: <870413151618.1.GLS@FALLING-STAR.THINK.COM>

    Date: 11 Apr 87 14:44:52 PST
    From: masinter.PA@xerox.com

    Everyone (including Guy Steele!) seems to be challenging me to quote
    "chapter and verse" in Guy Steele's book supporting my assertion that it
    is an error to redefine any of the predefined Common Lisp functions and
    macros.  (The appropriate verse which claims that it is an error to
    redefine one of the predefined special forms with DEFUN having been
    found.)

Larry, the point is that the phrase "is an error" has a precise
technical meaning in CLTL, and is furthermore understood in
conversations on this mailing list to mean "is explicitly stated by CLTL
to `be an error'".  If it's just your opinion, then you can legitimately
say "It is stupid to ..." or "It is wedged to ..."  or even "It is
erroneous to ..." or (best) "I think it should be an error to ..."; but
if you say simply "It is an error to..." then that is understood to be a
statement of fact about what is in CLTL, and it is reasonable for others
to ask what part of the book backs it up.

We all like you, and we don't mean to challenge you or give you a hard
time.  Many of us even agree that it SHOULD be an error.  But (unless
I have overlooked the relevant passage) it isn't an error yet.

--Guy

∂13-Apr-87  1516	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	Compiling CASE 
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 13 Apr 87  15:16:29 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75945; Mon 13-Apr-87 09:53:51 EDT
Date: Mon, 13 Apr 87 09:57 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Compiling CASE
To: Hvatum@MIT-MULTICS.ARPA, Rob MacLachlan <RAM@C.CS.CMU.EDU>, masinter.PA@Xerox.COM,
    Jim Kempf <kempf%hplabsc@hplabs.HP.COM>, Jon L White <edsel!bhopal!jonl@navajo.stanford.edu>,
    Mike Hewett <HEWETT@SUMEX-AIM.STANFORD.EDU>, common-lisp@SAIL.STANFORD.EDU,
    navajo!Common-Lisp%sail@navajo.stanford.edu
In-Reply-To: <870411100755.599053@MIT-MULTICS.ARPA>,
             <RAM.12293665189.BABYL@C.CS.CMU.EDU>,
             <RAM.12293670645.BABYL@C.CS.CMU.EDU>,
             <870411-154536-1554@Xerox>,
             <8704120544.AA05619@hplabsc>,
             <8704130006.AA04788@bhopal.edsel.com>,
             <12294088425.12.HEWETT@SUMEX-AIM.STANFORD.EDU>
Message-ID: <870413095719.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

    Date: Sun, 12 Apr 87 22:24:43 PDT
    From: Mike Hewett <HEWETT@SUMEX-AIM.STANFORD.EDU>

    As someone more concerned with using Common LISP and in
    the portability of it, I can't believe any responsible 
    software engineer would even think of redefining a
    CL-defined function, macro, or special form.

I agree, and the implication (or my inference) is that there are
irresponsible engineers, or even the responsible ones make mistakes.

    Therefore, the question of allowing redefinition is purely
    a CL environment implementation question, and I would think
    that it should be perfectly legal to protect the user from
    himself and not allow redefinition.

I agree here too.  Various implementations do protect the user. The
Symbolics implementation does this by remembering the source file of the
original definition, and if the new source file doesn't match it
queries.  This applies to all functions, not just the core language.

    Date: Sat, 11 Apr 1987  11:09 EDT
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
	...
    The significance of code walkers has also been exaggerated.  For one
    thing, modern Lisp compilers tend not to use source code as the
    internal representation, and their operation cannot really be modeled
    as a source code walk.  Given a sufficiently rich representation, many
    things can be determined without actually grovelling the code.

    Of course internal compiler representations are highly implementation
    dependent, but this isn't necessarily a problem.  One of the main
    things that source code walkers have been used for is writing
    "optimizing macros" for non-optimizing compilers.  As long as the
    compiler adequately optimizes the code, macros can expand in a
    simple-minded way without understanding their arguments.

Speak for yourself.  They are also used to write embedded languages or
to make semantic extensions to existing languages that require
source-to-source translation to convert the embedded syntax to CLtL.
This is precisely my main use of code walkers.  Consider a simple object
oriented system where slots are referenced with AREF.  I could (1) go in
and change the compiler, (2) try to use the compiler's internal
representation, or (3) code walk looking for slot names and replace them
with the appropriate AREF forms.  (3) is the only method that has any
hope of portability, and the funarg to the code walker is 9 lines of
code.

∂13-Apr-87  1528	@diamond.s4cc.symbolics.com:DCP@QUABBIN.SCRC.Symbolics.COM 	Compiling CASE 
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Apr 87  15:28:26 PDT
Received: from DIAMOND.S4CC.Symbolics.COM ([128.81.51.3]) by navajo.stanford.edu with TCP; Mon, 13 Apr 87 15:24:54 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75945; Mon 13-Apr-87 09:53:51 EDT
Date: Mon, 13 Apr 87 09:57 EDT
From: David C. Plummer <DCP@quabbin.scrc.symbolics.com>
Subject: Compiling CASE
To: Hvatum@MIT-MULTICS.ARPA, Rob MacLachlan <RAM@c.cs.cmu.edu>,
        masinter.PA@xerox.com, Jim Kempf <kempf%hplabsc@hplabs.hp.com>,
        Jon L White <edsel!bhopal!jonl@navajo.stanford.edu>,
        Mike Hewett <HEWETT@sumex-aim.stanford.edu>,
        common-lisp@sail.stanford.edu,
        navajo!Common-Lisp%sail@navajo.stanford.edu
In-Reply-To: <870411100755.599053@MIT-MULTICS.ARPA>,
             <RAM.12293665189.BABYL@C.CS.CMU.EDU>,
             <RAM.12293670645.BABYL@C.CS.CMU.EDU>,
             <870411-154536-1554@Xerox>,
             <8704120544.AA05619@hplabsc>,
             <8704130006.AA04788@bhopal.edsel.com>,
             <12294088425.12.HEWETT@SUMEX-AIM.STANFORD.EDU>
Message-Id: <870413095719.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

    Date: Sun, 12 Apr 87 22:24:43 PDT
    From: Mike Hewett <HEWETT@SUMEX-AIM.STANFORD.EDU>

    As someone more concerned with using Common LISP and in
    the portability of it, I can't believe any responsible 
    software engineer would even think of redefining a
    CL-defined function, macro, or special form.

I agree, and the implication (or my inference) is that there are
irresponsible engineers, or even the responsible ones make mistakes.

    Therefore, the question of allowing redefinition is purely
    a CL environment implementation question, and I would think
    that it should be perfectly legal to protect the user from
    himself and not allow redefinition.

I agree here too.  Various implementations do protect the user. The
Symbolics implementation does this by remembering the source file of the
original definition, and if the new source file doesn't match it
queries.  This applies to all functions, not just the core language.

    Date: Sat, 11 Apr 1987  11:09 EDT
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
	...
    The significance of code walkers has also been exaggerated.  For one
    thing, modern Lisp compilers tend not to use source code as the
    internal representation, and their operation cannot really be modeled
    as a source code walk.  Given a sufficiently rich representation, many
    things can be determined without actually grovelling the code.

    Of course internal compiler representations are highly implementation
    dependent, but this isn't necessarily a problem.  One of the main
    things that source code walkers have been used for is writing
    "optimizing macros" for non-optimizing compilers.  As long as the
    compiler adequately optimizes the code, macros can expand in a
    simple-minded way without understanding their arguments.

Speak for yourself.  They are also used to write embedded languages or
to make semantic extensions to existing languages that require
source-to-source translation to convert the embedded syntax to CLtL.
This is precisely my main use of code walkers.  Consider a simple object
oriented system where slots are referenced with AREF.  I could (1) go in
and change the compiler, (2) try to use the compiler's internal
representation, or (3) code walk looking for slot names and replace them
with the appropriate AREF forms.  (3) is the only method that has any
hope of portability, and the funarg to the code walker is 9 lines of
code.

∂13-Apr-87  2016	DON%atc.bendix.com@RELAY.CS.NET 	Inconsistent keywords for sequence functions   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 13 Apr 87  20:16:07 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa02842; 13 Apr 87 23:08 EDT
Received: from atc.bendix.com by RELAY.CS.NET id aa27455; 13 Apr 87 23:04 AST
Date: Mon, 13 Apr 87 14:07 EDT
From: DON%atc.bendix.com@RELAY.CS.NET
Subject: Inconsistent keywords for sequence functions
To: common-lisp@SAIL.STANFORD.EDU
X-VMS-To: IN%"common-lisp@sail.stanford.edu"

Why do most of the sequence functions have the :key keyword but
reduce doesn't?  Why isn't there a reduce-if and a reduce-if-not?
An example which came up recently is

(reduce #'+ box-contents :key #'weight)

which should return the sum of the weights of the objects in the box.

Don Mitchell	  		Don@atc.bendix.com
Bendix Aero. Tech. Ctr.		Don%atc.bendix.com@relay.cs.net
9140 Old Annapolis Rd.		(301)964-4156
Columbia, MD 21045

∂14-Apr-87  0747	ROSENKING@A.ISI.EDU 	Redefinition of CL Functions 
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87  07:47:13 PDT
Date: 14 Apr 1987 10:44:12 EDT
Subject: Redefinition of CL Functions
From: Jeffrey Rosenking <ROSENKING@A.ISI.EDU>
To: common-lisp@SAIL.STANFORD.EDU
cc: rosenking@A.ISI.EDU

To: common-lisp@SAIL.STANFORD.EDU
Cc: rosenking@A.ISI.EDU
Subject: Redefinition of CL Functions
------------------------------------------------------------------------

13-Apr-87 18:57:41-EDT,3913;000000000001
Return-Path: <@SAIL.STANFORD.EDU,@diamond.s4cc.symbolics.com:DCP@QUABBIN.SCRC.Symbolics.COM>
Received: FROM SAIL.STANFORD.EDU BY USC-ISI.ARPA WITH TCP ; 13 Apr 87 18:53:02 EDT
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Apr 87  15:28:26 PDT
Received: from DIAMOND.S4CC.Symbolics.COM ([128.81.51.3]) by navajo.stanford.edu with TCP; Mon, 13 Apr 87 15:24:54 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75945; Mon 13-Apr-87 09:53:51 EDT
Date: Mon, 13 Apr 87 09:57 EDT
From: David C. Plummer <DCP@quabbin.scrc.symbolics.com>
Subject: Compiling CASE
To: Hvatum@MIT-MULTICS.ARPA, Rob MacLachlan <RAM@c.cs.cmu.edu>,
        masinter.PA@xerox.com, Jim Kempf <kempf%hplabsc@hplabs.hp.com>,
        Jon L White <edsel!bhopal!jonl@navajo.stanford.edu>,
        Mike Hewett <HEWETT@sumex-aim.stanford.edu>,
        common-lisp@sail.stanford.edu,
        navajo!Common-Lisp%sail@navajo.stanford.edu
In-Reply-To: <870411100755.599053@MIT-MULTICS.ARPA>,
             <RAM.12293665189.BABYL@C.CS.CMU.EDU>,
             <RAM.12293670645.BABYL@C.CS.CMU.EDU>,
             <870411-154536-1554@Xerox>,
             <8704120544.AA05619@hplabsc>,
             <8704130006.AA04788@bhopal.edsel.com>,
             <12294088425.12.HEWETT@SUMEX-AIM.STANFORD.EDU>
Message-Id: <870413095719.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

    Date: Sun, 12 Apr 87 22:24:43 PDT
    From: Mike Hewett <HEWETT@SUMEX-AIM.STANFORD.EDU>

    As someone more concerned with using Common LISP and in
    the portability of it, I can't believe any responsible 
    software engineer would even think of redefining a
    CL-defined function, macro, or special form.

I agree, and the implication (or my inference) is that there are
irresponsible engineers, or even the responsible ones make mistakes.

    Therefore, the question of allowing redefinition is purely
    a CL environment implementation question, and I would think
    that it should be perfectly legal to protect the user from
    himself and not allow redefinition.

I agree here too.  Various implementations do protect the user. The
Symbolics implementation does this by remembering the source file of the
original definition, and if the new source file doesn't match it
queries.  This applies to all functions, not just the core language.

I agree here too, too ! In response to the discussions above (Hewett, Masinter, Plummer, and Steele),
and my feelings on the subject, I THINK that the CL standard should support 
a mechanism to, at least, warn the user if he attempts to redefine a CL-defined
function, macro, or special form [ or perhpas initiate an error, though I 
believe that this will not coincide with the tradional flexibility which LISP
has always had ]. The Symbolics implementation [of a redefinition WARNING 
mechanism] would be a good model for the analagous CL mechanism, and it has
the advantage of working for the definition of all functions, not just those
which are strictly CL-defined. I BELIEVE that this mechanism is an essential
part of a language, especially one which was mainly designed to support 
portability and commonality among various LISP implementations.

                          -: Jeff 
-------
-------

∂14-Apr-87  0851	kempf%hplabsc@hplabs.HP.COM 	Re:  Redefinition of CL Functions   
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 14 Apr 87  08:51:30 PDT
Received: from hplabsc by hplabs.HP.COM with TCP ; Tue, 14 Apr 87 07:43:17 pst
Received: by hplabsc ; Tue, 14 Apr 87 07:44:30 pst
Date: Tue, 14 Apr 87 07:44:30 pst
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8704141544.AA07256@hplabsc>
To: ROSENKING@A.ISI.EDU, common-lisp@SAIL.STANFORD.EDU
Subject: Re:  Redefinition of CL Functions
Cc: rosenking@A.ISI.EDU

While I understand the concern about redefinition causing code
to become nonportable, I think a case can be made for redefinition
in experimental systems. Particularly when one is developing
embedded languages, the semantics of certain Common Lisp functions
may need to be changed. An example here is CommonObjects, which
extends the semantics of certain Common Lisp functions to include
user defined types. Naturally, this is not something one does
casually, in the course of developing a Common Lisp application,
but rather should be labelled by the developer as being an extension
to be used with care. A warning message upon redefinition would
be sufficient, signalling an error would remove some of the flexibility
which makes Common Lisp such an ideal environment for developing
embedded languages.

		Jim Kempf	kempf@hplabs.hp.com

∂14-Apr-87  0924	RAM@C.CS.CMU.EDU 	Redefinition of CL Functions    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87  09:24:31 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 14 Apr 87 12:13:37-EDT
Date: Tue, 14 Apr 1987  12:13 EDT
Message-ID: <RAM.12294468669.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   Jim Kempf <kempf%hplabsc@HPLABS.HP.COM>
Cc:   common-lisp@SAIL.STANFORD.EDU, ROSENKING@A.ISI.EDU
Subject: Redefinition of CL Functions
In-reply-to: Msg of 14 Apr 1987  11:44-EDT from Jim Kempf <kempf%hplabsc at hplabs.HP.COM>


One point that should be introduced into this discussion is the
distinction between "legal" and "reasonable".  It is not feasible for
Common Lisp to mandate reasonableness; users will have to decide for
themselves whether a given implementation is reasonable.  With any
standard it is possible to create a system that complies with the
letter of the standard, but is still totally unusable.

In the case of redefinitions of standard functions and macros I would
say that reasonable implementations should both:
 -- Warn when the user redefines a standard function or macro and
 -- Do its best to make the user redefinition work.

I don't think either property can be brought within the formal
language definition, so an implementation that flames out and dies
when you redefine a standard function would be legal.

  Rob

∂14-Apr-87  0949	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re:  Redefinition of CL Functions    
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 14 Apr 87  09:48:58 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 71623; Tue 14-Apr-87 12:38:03 EDT
Date: Tue, 14 Apr 87 12:34 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re:  Redefinition of CL Functions
To: kempf%hplabsc@hplabs.HP.COM, ROSENKING@A.ISI.EDU, common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <8704141544.AA07256@hplabsc>
Message-ID: <870414123431.3.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Tue, 14 Apr 87 07:44:30 pst
    From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>

    While I understand the concern about redefinition causing code
    to become nonportable, I think a case can be made for redefinition
    in experimental systems.

However, as Rob explained in a recent message, the only reason for the
Common Lisp specification to provide for anything is in order to make
sure that doing the thing is guaranteed to be portable across all
implementations of Common Lisp.  If it's not going to be portable, then
there's no point in putting it in the Common Lisp specification.  If it
is supposed to be portable, there are all the serious problems that have
been pointed out in recent mail.  There's nothing wrong with a particular
implementation having some kind of feature that allows redefinition of
built-in functions/macros/etc.

∂14-Apr-87  1010	sears%wrs.DEC@decwrl.DEC.COM 	Re:  Inconsistencies in Sequence Function Arguments    
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 14 Apr 87  10:10:27 PDT
Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
	id AA19382; Tue, 14 Apr 87 09:10:14 PST
Message-Id: <8704141710.AA19382@decwrl.dec.com>
Date: Tuesday, 14 Apr 1987 09:48:40-PDT
From: sears%wrs.DEC@decwrl.DEC.COM
To: common-lisp@SAIL.STANFORD.EDU, sears%wrs.DEC@decwrl.DEC.COM
Subject: Re:  Inconsistencies in Sequence Function Arguments


I agree that REDUCE should take a :KEY keyword.  There seems to be
little difficulty in implementing it, I have found it frequently
useful, and it provides consistency with the other sequence functions.  The
change is upward compatible with the existing language.

/wrs

∂14-Apr-87  1013	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Inconsistent keywords for sequence functions    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 Apr 87  10:12:57 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 115506; Tue 14-Apr-87 13:10:15 EDT
Date: Tue, 14 Apr 87 13:09 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Inconsistent keywords for sequence functions
To: DON%atc.bendix.com@RELAY.CS.NET
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: The message of 13 Apr 87 14:07 EDT from DON%atc.bendix.com@RELAY.CS.NET
Message-ID: <870414130937.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 13 Apr 87 14:07 EDT
    From: DON%atc.bendix.com@RELAY.CS.NET

    Why do most of the sequence functions have the :key keyword but
    reduce doesn't?  Why isn't there a reduce-if and a reduce-if-not?
    An example which came up recently is

    (reduce #'+ box-contents :key #'weight)

    which should return the sum of the weights of the objects in the box.

:key, -if, and -if-not only apply to functions that have :test arguments.
I can't imagine what reduce-if and reduce-if-not would do.  I can see
what you want reduce :key to do, but I'm not sure :key is the right name
for that.

In retrospect, it might have been better language design to have fewer
options combined with stronger encouragement of implementations to
compile efficient code for nested function invocations, compiling out
temporary storage.  Thus your example would be written:
    (reduce #'+ (mapcar #'weight box-contents))
I realize quite well that there are a number of practical and philosophical
problems connected with actually doing this; please let's not start a long
discussion of them.

∂14-Apr-87  1131	Moon@STONY-BROOK.SCRC.Symbolics.COM 	redefining Common Lisp functions 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 Apr 87  11:20:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 115605; Tue 14-Apr-87 14:19:35 EDT
Date: Tue, 14 Apr 87 14:19 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: redefining Common Lisp functions
To: masinter.PA@Xerox.COM
cc: common-lisp@sail.stanford.edu
In-Reply-To: <870411-154536-1554@Xerox>
Message-ID: <870414141907.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 11 Apr 87 14:44:52 PST
    From: masinter.PA@Xerox.COM

    Rather than attempting to divine meaning in CLtL, lets focus on some
    related but different questions:

    1. (Current practice) In your favorite Common Lisp implementation, which
    of the predefined Common Lisp functions, macros, and special forms can
    be safely redefined without causing unpredictable behavior somewhere
    else in the system? 

I don't know what "safely" means; I made an assumption about what you meant
such that the answer is "none of them, not only in my favorite implementation,
but in all the others too."

    2. (Future standards) Which of the predefined Common Lisp functions,
    macros, and special forms do you think *should* be redefinable.

I don't believe that Common Lisp should define the meaning of redefining
any of the predefined functions.  Thus I believe that it should "be an error"
to redefine any predefined function.  JonL's point about the difference between
truly redefining something and merely encapsulating it (e.g. for TRACE) is
relevant here.  But note that I do not believe that Common Lisp should require
compiled code that appears to call a predefined function, macro, or special
form to be necessarily affected by any encapsulation of that functionoid.

    3. (More constrained redefining) Presuming the CLOS, which of the
    predefined Common Lisp functions should be specializable for
    user-defined classes? How should such specialization affect the rest of
    the behavior of Common Lisp?

The working group for defining the proposed object-oriented programming
standard ("CLOS") has thought about this just enough to realize that it
is complex and difficult.  The group, or someone, will have to do more
work in this area, but it's not going to be easy.

∂14-Apr-87  1148	VERACSD@A.ISI.EDU 	Format
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87  11:48:20 PDT
Date: 14 Apr 1987 14:47-EDT
Sender: VERACSD@A.ISI.EDU
Subject: Format
From: VERACSD@A.ISI.EDU
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]14-Apr-87 14:47:31.VERACSD>

     Is there a FORMAT directive that prints real numbers as integers
(truncated or rounded), without a decimal point?

∂14-Apr-87  1204	FAHLMAN@C.CS.CMU.EDU 	Format  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87  12:04:27 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 14 Apr 87 15:04:20-EDT
Date: Tue, 14 Apr 1987  15:04 EDT
Message-ID: <FAHLMAN.12294499763.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   VERACSD@A.ISI.EDU
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: Format
In-reply-to: Msg of 14 Apr 1987  14:47-EDT from VERACSD at A.ISI.EDU


         Is there a FORMAT directive that prints real numbers as integers
    (truncated or rounded), without a decimal point?

I'm not sure, but I don't think so.  Why not call Truncate or Round on
the number and then format it with ~D ?

-- Scott

∂14-Apr-87  1706	sears%wrs.DEC@decwrl.DEC.COM 	Re:  Redefinition of CL Functions  
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 14 Apr 87  17:05:58 PDT
Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
	id AA29331; Tue, 14 Apr 87 16:06:46 PST
Message-Id: <8704150006.AA29331@decwrl.dec.com>
Date: Tuesday, 14 Apr 1987 10:10:11-PDT
From: sears%wrs.DEC@decwrl.DEC.COM
To: common-lisp@SAIL.STANFORD.EDU, sears%wrs.DEC@decwrl.DEC.COM
Subject: Re:  Redefinition of CL Functions

Are there cases where shadowing COMMON LISP symbols, then giving the
shadowing symbols new definitions does not provide sufficient capability
to layer extensions on a COMMON LISP implementation?

I built a layered language for instrumentation, and used shadowed symbols
to provide the new definitions. This works fine in VAXLISP.

It was necessary to provide type definitions for symbols used as both
a function and a type (LIST, STRING, etc), and to provide DEFSETF
expanders for the new names.  Are there other known problems?

This approach is well defined because you know which definition you are
using (It depends on the package in effect when the file is read or compiled),
and it is straightforward to reference the standard definition if it is
needed.  It also works with our compiler, which does not optimize
any of the new definitions, since it doesn't recognize any of the
new functions.

Incidentally, VAX LISP gives a warning message when you try to redefine
a built-in COMMON-LISP function.

/wrs

∂14-Apr-87  1829	jcm@ORNL-MSR.ARPA 	Flavors and DEC's VMS Common Lisp?  
Received: from ORNL-MSR.ARPA by SAIL.STANFORD.EDU with TCP; 14 Apr 87  18:29:04 PDT
Received: by ORNL-MSR.ARPA (5.51/4.9)
	id AA21592; Tue, 14 Apr 87 21:29:58 EST
Date: Tue, 14 Apr 87 21:29:58 EST
From: jcm@ORNL-MSR.ARPA (James A. Mullens)
Message-Id: <8704150229.AA21592@ORNL-MSR.ARPA>
To: common-lisp@sail.stanford.edu
Subject: Flavors and DEC's VMS Common Lisp?


[He was new to the group, he couldn't locate the mail archives, so he had
 to ask a newcomer's question...
]

Has anyone done a public-domain implementation of Symbolics-style flavors
for DEC VMS CL?  We have found a flavors package for Golden Common Lisp
which we are considering porting... any comments?

jim mullens / jcm@ornl-msr.arpa / oak ridge national lab

∂14-Apr-87  2056	kempf%hplabsc@hplabs.HP.COM 	Re: Redefinition of Common Lisp Functions
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 14 Apr 87  20:56:40 PDT
Received: from hplabsc by hplabs.HP.COM with TCP ; Tue, 14 Apr 87 16:06:24 pst
Received: by hplabsc ; Tue, 14 Apr 87 16:06:53 pst
Date: Tue, 14 Apr 87 16:06:53 pst
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8704150006.AA14181@hplabsc>
To: common-lisp@sail.stanford.edu
Subject: Re: Redefinition of Common Lisp Functions


I guess I need to clarify my comments. I see two competing needs here:

1) On the one hand, system vendors and applications distributors 
require the option of not allowing users to redefine Common 
Lisp functions. Allowing users to do so makes supplying safe,
good quality software difficult because regression testing becomes next to
impossible.

2) On the other, researchers and people prototyping advanced
applications might want to modify the semantics of certain
Common Lisp functions for experimental purposes.

It seems to me that protection of functions could be included
in postdevelopment packaging, perhaps by setting a switch or
on a package by package basis. The method I used to modify EQ, etc. in
CommonObjects may, in fact, be the desired one: shadow those
Common Lisp functions in the packages where the modified
functions are desired with noninterned symbols having the
same print names as the functions. Attempts to directly redefine
the functions may cause an error to be signalled.
This technique would require no changes in the standard, or
the standard could be toughened up to require that an error
be signalled, as long as it is not toughened to the point
where shadowing Common Lisp functions is an error.

With regard to Moon's comments about the CLOS:

>    3. (More constrained redefining) Presuming the CLOS, which of the
>    predefined Common Lisp functions should be specializable for
>    user-defined classes? How should such specialization affect the rest of
>    the behavior of Common Lisp?
>
>The working group for defining the proposed object-oriented programming
>standard ("CLOS") has thought about this just enough to realize that it
>is complex and difficult.  The group, or someone, will have to do more
>work in this area, but it's not going to be easy.

I agree. There are a core set of functions which object-oriented
application developers usually say they want to be specializable,
but, considering the wide variety of Common Lisp implementations
out there, it may be difficult to provide them without stepping
on someone's toes.

		Jim Kempf	kempf@hplabs.hp.com

∂14-Apr-87  2256	MURRAY%cs.umass.edu@RELAY.CS.NET 	EVAL-WHEN symbols    
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 14 Apr 87  22:56:10 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ah21989; 15 Apr 87 1:31 EDT
Received: from cs.umass.edu by RELAY.CS.NET id bd04862; 15 Apr 87 1:28 AST
Date:     Tue, 14 Apr 87 15:45 EDT
From:     MURRAY%cs.umass.edu@RELAY.CS.NET
To:       common-lisp@SAIL.STANFORD.EDU
Subject:  EVAL-WHEN symbols 
X-VMS-To: CSNET%"common-lisp@sail.stanford.edu"

 While on the topic of symbols and such, I have a question
 about EVAL-WHEN.  Does it only allow LISP:EVAL, LISP:COMPILE
 and LISP:LOAD, or does it only check the print-name?  

 I think it should check print-names, so you can
 shadow these symbols.  Otherwise, you would be forced
 to add the package prefix in all the EVAL-WHEN forms.

 Kelly

∂15-Apr-87  0236	pyramid!pyramid.UUCP!bein@hplabs.HP.COM 	macroexpand inside of macrolet... 
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 15 Apr 87  02:36:13 PDT
Received: by hplabs.HP.COM ; Wed, 15 Apr 87 01:36:06 pst
Received: from manpyrnova 
	by pyramid.UUCP (5.52/UUCP-Project/rel-1.0/09-16-86)
	id AA26478; Wed, 15 Apr 87 02:09:31 PDT
Received: by pyrnova.pyramid.COM (5.52/UUCP-Project/rel-1.0/09-11-86)
	id AA11138; Wed, 15 Apr 87 02:09:17 PDT
Date: 15 Apr 1987 01:59 PDT
From: David Bein <pyramid!bein@hplabs.HP.COM>
Subject: macroexpand inside of macrolet...
To: hplabs!common-lisp@sail.stanford.edu@hplabs.HP.COM
Message-Id: <545474120/bein@pyrnova>

  I was playing around inside some macrolet code and came across
what seems to a be a problem (if this issue was discussed ages ago
on this mailing list, please pardon me for raising it again).

	(MACROLET ((CONS (A B) `(LIST ',A ',B)))
	    (MACROEXPAND '(CONS 1 2)))

returns (CONS 1 2) and NIL, while

	(MACROLET ((CONS (A B) `(LIST ',A ',B)))
	     #'CONS)

blows up since FUNCTION sees the local macro definition.

  Getting a handle on the local macro environment seems to be
next to impossible. Is there some good reason for this?

  Should function be paying attention to the MACROLET
environment in the same way as it does for FLET/LABELS or is
this a bug in my implementation?

  Does anyone out there agree with the idea that
macroexpanding something inside the body of a macrolet
is a useful thing to do?

  From a debugging standpoint, the current situation
makes it difficult to see what is going on since
there is no "defined" way to see what is currently
defined and of course using something like #'FOO
is ok except if FOO is a macrolet creation.

I suggest the following:

(1) Either MACRO-FUNCTION should be changed to notice
    the local macro or some new function be defined
    for getting at the local macro environment.

(2) Either MACROEXPAND should by default use the
    current environment (implementation specific of
    course!) or a new function should be defined
    for doing the same thing or perhaps the time
    has arrived for a way to access the environment
    in a general way.

  Comments?

--David

p.s. This whole bag of %&$# would go away if macrolet were
     to vaporize itself from the language.

∂15-Apr-87  0818	FAHLMAN@C.CS.CMU.EDU 	Redefinition of Common Lisp Functions 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87  08:18:05 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 15 Apr 87 11:08:02-EDT
Date: Wed, 15 Apr 1987  11:07 EDT
Message-ID: <FAHLMAN.12294718886.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Jim Kempf <kempf%hplabsc@HPLABS.HP.COM>
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: Redefinition of Common Lisp Functions
In-reply-to: Msg of 14 Apr 1987  20:06-EDT from Jim Kempf <kempf%hplabsc at hplabs.HP.COM>


    Attempts to directly redefine
    the functions may cause an error to be signalled.
    This technique would require no changes in the standard, or
    the standard could be toughened up to require that an error
    be signalled, as long as it is not toughened to the point
    where shadowing Common Lisp functions is an error.

Unless I missed something, nobody is proposing that SHADOWING a built-in
function using the package system should signal an error or should "be
an error".  That's what the package system is for.

Clobbering the definitions of built-in symbols in the Lisp package is
another matter.  I think there's pretty general agreement that this
should be an "is an error situation", and that it would be tasteful to
at least issue a warning in such cases, perhaps under control of a magic
implementation-dependent switch.

-- Scott

∂15-Apr-87  0818	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	macroexpand inside of macrolet...  
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 15 Apr 87  08:18:22 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 76897; Wed 15-Apr-87 11:14:49 EDT
Date: Wed, 15 Apr 87 11:18 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: macroexpand inside of macrolet...
To: David Bein <pyramid!bein@hplabs.HP.COM>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <545474120/bein@pyrnova>
Message-ID: <870415111824.8.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

    Date: 15 Apr 1987 01:59 PDT
    From: David Bein <pyramid!bein@hplabs.HP.COM>

      I was playing around inside some macrolet code and came across
    what seems to a be a problem (if this issue was discussed ages ago
    on this mailing list, please pardon me for raising it again).

	    (MACROLET ((CONS (A B) `(LIST ',A ',B)))
		(MACROEXPAND '(CONS 1 2)))

    returns (CONS 1 2) and NIL, while

	    (MACROLET ((CONS (A B) `(LIST ',A ',B)))
		 #'CONS)

    blows up since FUNCTION sees the local macro definition.

You are confusing compile-time environments with runtime environments.

MACROLET works on code.  MACROEXPAND works on structure.  Unless you can
somehow grab ahold, at runtime, of the environment MACROLET has created
and pass that environment to MACROEXPAND you won't get what you are
looking for.  How about
	(MACROEXPAND-all '(MACROLET ((CONS (A B) `(LIST ',A ',B)))
			(CONS 1 2)))
	=> (MACROLET ((CONS (A B) `(LIST ',A ',B)))
	     (LIST '1 '2))
where MACROEXPAND-all (not in CL) does a macroexpanding code walk.


∂15-Apr-87  0903	FAHLMAN@C.CS.CMU.EDU 	EVAL-WHEN symbols 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87  09:03:03 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 15 Apr 87 11:55:44-EDT
Date: Wed, 15 Apr 1987  11:55 EDT
Message-ID: <FAHLMAN.12294727565.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   MURRAY%cs.umass.edu@RELAY.CS.NET
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: EVAL-WHEN symbols 
In-reply-to: Msg of 14 Apr 1987  15:45-EDT from MURRAY%cs.umass.edu at RELAY.CS.NET


     While on the topic of symbols and such, I have a question
     about EVAL-WHEN.  Does it only allow LISP:EVAL, LISP:COMPILE
     and LISP:LOAD, or does it only check the print-name?  

     I think it should check print-names, so you can
     shadow these symbols.  Otherwise, you would be forced
     to add the package prefix in all the EVAL-WHEN forms.

Eval-when is currently defined to look for EVAL, COMPILE, and LOAD as
symbols in the Lisp package.  Maybe they should have been keywords, but
it's too late now.  There's a reasonably good chance that EVAL-WHEN will
be replaced in some future badly-needed cleanup of the compiler semantics.

-- Scott

∂15-Apr-87  0955	weeks%hplbgw%hplb29a@hplabs.HP.COM 	Re:  EVAL-WHEN symbols  
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 15 Apr 87  09:55:14 PDT
Received: from hplb29a by hplabs.HP.COM with TCP ; Wed, 15 Apr 87 08:51:53 pst
Received: from hplbgw (hplbgw) by hplb29a ; Wed, 15 Apr 87 08:52:10 pst
Received: by hplbgw ; Wed, 15 Apr 87 08:54:32 pst
Date: Wed, 15 Apr 87 08:54:32 pst
From: Gregory Weeks <weeks%hplbgw%hplb29a@hplabs.HP.COM>
Message-Id: <8704151654.AA00676@hplbgw>
To: MURRAY%RELAY.CS.NET%%SAIL.STANFORD.EDU%hplabs@cs.umass.edu,
        common-lisp@SAIL.STANFORD.EDU
Subject: Re:  EVAL-WHEN symbols

	 While on the topic of symbols and such, I have a question
	 about EVAL-WHEN.  Does it only allow LISP:EVAL, LISP:COMPILE
	 and LISP:LOAD, or does it only check the print-name?  
	
	 I think it should check print-names, so you can
	 shadow these symbols.  Otherwise, you would be forced
	 to add the package prefix in all the EVAL-WHEN forms.
	
Now that you mention it:  EVAL, COMPILE, and LOAD should have been 
keywords.

	

∂15-Apr-87  0957	Masinter.pa@Xerox.COM 	Re: macroexpand inside of macrolet...
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Apr 87  09:57:06 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 APR 87 09:55:07 PDT
Date: 15 Apr 87 09:53 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: macroexpand inside of macrolet...
In-reply-to: David Bein <pyramid!bein@hplabs.HP.COM>'s message of 15 Apr
 87 01:59 PDT
To: common-lisp@sail.stanford.edu
Message-ID: <870415-095507-4213@Xerox>

The issue of a lexical environment argument to macroexpand and
macroexpand-1 was discussed at length on this list as well as on the
cleanup committee list. 

The problem doesn't go away with the removal of macrolet, because FLET
and LABELS can shadow macros, too. 


∂15-Apr-87  1034	Masinter.pa@Xerox.COM 	Re: EVAL-WHEN symbols 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Apr 87  10:34:00 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 APR 87 10:34:02 PDT
Date: 15 Apr 87 10:35 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: EVAL-WHEN symbols 
In-reply-to: MURRAY%cs.umass.edu@RELAY.CS.NET's message of Tue, 14 Apr
 87 15:45 EDT
To: MURRAY%cs.umass.edu@RELAY.CS.NET
cc: common-lisp@SAIL.STANFORD.EDU
Message-ID: <870415-103402-4296@Xerox>

If you want to shadow any of EVAL, LOAD or COMPILE and leave EVAL-WHEN,
you can do so by shadowing EVAL-WHEN with a new EVAL-WHEN which checks
for your new symbols and transforms them to the old.

Ugly, but simple.

∂15-Apr-87  1306	Mailer@XX.LCS.MIT.EDU 	Compiling CASE   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87  13:06:47 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 Apr 87 16:04-EDT
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 38194; 15 Apr 87 14:59:02-EDT
Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 32893; 14 Apr 87 16:34:08-EDT
Date: Tue, 14 Apr 87 16:32 EDT
From: Don Morrison <dfm@JASPER.PALLADIAN.COM>
Subject: Compiling CASE
To: Hvatum@MIT-MULTICS.ARPA, barmar@Think.COM
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <870411100755.599053@MIT-MULTICS.ARPA>
Message-ID: <870414163245.2.DFM@WHITBY.PALLADIAN.COM>
Reply-To: Don Morrison <DFM%JASPER@LIVE-OAK.LCS.MIT.EDU>

    Date:  Sat, 11 Apr 87 06:07 EDT
    From:  Hvatum@MIT-MULTICS.ARPA
 
    To Don Morrison:  What is the meaning of declaring a MACRO NOTINLINE?
    CLtL doesn't imply that this is even possible.
 
    (Which is not to say that CLtL implies that it ISN'T possible - I'm
    being very careful with my wording here.)

You and barmar are right; my brain was turned off.  Notinline has nothing to do with
it.  Sorry about that.

	Date: Fri, 10 Apr 87 12:58 EDT
	From: Barry Margolin <barmar@Think.COM>
	
	    Date: Wed, 8 Apr 87 10:37 EDT
	    From: Don Morrison <dfm@jasper.palladian.com>
	
	    I wonder, however, if all implementations do the right thing if you declare a macro
	    which is treated specially as notinline?
	
	I don't think it should be necessary to declare/proclaim a macro
	notinline.  For the macro to work at all, the defmacro must be seen by
	the compiler before it tries to compile the use of the macro.  I would
	hope that the macro would be smart enough to notice that the user has
	overridden the default definition.
    


∂15-Apr-87  2258	sandra%orion@cs.utah.edu 	bignums are bogus  
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87  22:58:29 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
	id AA02358; Thu, 16 Apr 87 00:01:08 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
	id AA15364; Thu, 16 Apr 87 00:01:04 MDT
Date: Thu, 16 Apr 87 00:01:04 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8704160601.AA15364@utah-orion.ARPA>
Subject: bignums are bogus
To: common-lisp@sail.stanford.edu

(Time to get out the asbestos suit -- I'm sure this is going to generate
a lot of flamage....)

Quoting from CLtL (p 13):  "Common Lisp in principle imposes no limit on
the magnitude of an integer; storage is automatically allocated as
necessary to represent large integers."

This is the only statement I can find on the subject of how large integers
can be in CL.  I think we can probably all agree that every implementation
does impose *some* limit on the size of integers; I don't know of any machine
that has an infinitely large amount of memory, or even an infinitely large
address space.  I expect some implementations of bignums have other
constraints as well:  assuming the number of bigits is a fixnum, storing
the bigits in an array (limiting the number of bigits to the maximum array
size), or similar representation-related problems.

Three questions:

(1) What is supposed to happen if the user attempts to create an integer 
larger than the implementation can support?  An easy way to do this would 
be to make several layers of calls to "ash":

    (let ((huge  most-positive-fixnum))
         (dotimes (i most-positive-fixnum)
             (setq huge (+ huge (ash huge huge))))
         huge)
        

(2) If "it is an error" to create a bignum larger than the implementation
can handle, how can user programs detect and avoid this situation?  If the
constraint is in the representation, having a constant to indicate the
maximum number of bits is a possibility, but if the problem is running out
of memory, it wouldn't be of much use.

(3) Given that every implementation has some practical limit on the size of
integers, but CLtL leaves that limit unspecified, is there any reason why
an implementation couldn't choose to make that limit fairly small, like 32
or 64 bits or whatever the largest machine integer size is?  (I realize 
that doing so might break the Universal Time functions, but I've already
noted that it's fairly easy to break other built-in functions as well,
regardless of how big integers can be.)  For that matter, what if the
maximum size of an integer just happened to be the maximum size of a fixnum?

-Sandra
-------

∂16-Apr-87  0834	FAHLMAN@C.CS.CMU.EDU 	bignums are bogus 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87  08:33:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 16 Apr 87 11:04:34-EDT
Date: Thu, 16 Apr 1987  09:13 EDT
Message-ID: <FAHLMAN.12294960256.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: bignums are bogus
In-reply-to: Msg of 16 Apr 1987  02:01-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore)


The intent of that passage is that the size of bignums should be *much*
larger than the size of fixnums.  It is true that the language does not
require that bignums be able to exhaust *all* of the machine's available
address space (or swap space), and that other implementation limits
(such as the maximum array index being a fixnum) may intrude in some
cases.  But I think that any implementation that doesn't normally allow
bignums of at least a few K bytes is cheating on the spirit, if not the
letter, of the specification.

As for how these things die when you finally reach the overflow point, I
think that this was viewed as a rare enough thing that it wasn't worth
trying to standardize it as a separate error type.  Presumably you get
the same effect that you would get if you exhausted the available space
in some other way, or if you asked for an array bigger than the space
remaining.  It is tasteful for this to be a clean, recoverable error,
but it is not required to be -- there has to be some freedom here, since
operating systems vary in the control they give you over memory
allocation and the amount of information they will give you about
available space.

-- Scott

∂16-Apr-87  0834	RAM@C.CS.CMU.EDU 	bignums are bogus
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87  08:33:23 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 16 Apr 87 11:05:25-EDT
Date: Thu, 16 Apr 1987  10:27 EDT
Message-ID: <RAM.12294973589.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: bignums are bogus
In-reply-to: Msg of 16 Apr 1987  02:01-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore)

    Date: Thursday, 16 April 1987  02:01-EDT
    From: sandra%orion at cs.utah.edu (Sandra J Loosemore)
    To:   common-lisp at sail.stanford.edu
    Re:   bignums are bogus

    Three questions:

    (1) What is supposed to happen if the user attempts to create an integer 
    larger than the implementation can support?

A reasonable implementation would signal an error of some sort,
although if paging space is physically exhausted it may be difficult
for Lisp to recover gracefully.  Many OS'es don't provide any way to
user programs to tell how how much paging space is left, and tend to
wedge in various ways when it exhausted.

    (2) If "it is an error" to create a bignum larger than the implementation
    can handle, how can user programs detect and avoid this situation?

The problem with running out of storage has no special relation to
bignums of course.  Some programs may require data structures larger
than some implementations can support on a given hardware
configuration.  This is a potential portability problem, but I see
nothing that can be done about it.

    (3) Given that every implementation has some practical limit on
    the size of integers, but CLtL leaves that limit unspecified, is
    there any reason why an implementation couldn't choose to make
    that limit fairly small, like 32 or 64 bits or whatever the
    largest machine integer size is?  For that matter, what if the
    maximum size of an integer just happened to be the maximum size of
    a fixnum?

Your implementation might reasonably be considered to be unreasonable,
and not in the spirit of the specification.  As I said earlier, it is
quite possible to build an implementation that compiles with the
letter of a specification and is still totally unusable.

I'm not a big bignum user, but I think it might be marginally
reasonable to support fixed-size 64 bit bignums.  I suspect that 64
bit bignums would take care of a large percentage of uses.  This would
also keep get-universal-time happy for a while to come.

Perhaps Common Lisp should specify a minimum maximum size for bignums
and require that an error be signalled if this is ever exceeded.  I
would guess that a limit of a few thousand bits would meet every use
except the most common, namely impressing non-lispers by typing 
(FACT 1000) and getting screens full of digits.

  Rob

∂16-Apr-87  0837	vrotney@vaxa.isi.edu 	CLARIFICATION: [italics]package arguments. 
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87  08:37:52 PDT
Received: from hpai00 (hpai00.isi.edu) by vaxa.isi.edu (4.12/4.7)
	id AA28527; Thu, 16 Apr 87 00:16:39 pst
Received: by hpai00 ; Thu, 16 Apr 87 01:15:33 pdt
From: vrotney@vaxa.isi.edu
Message-Id: <8704160815.AA02532@hpai00>
Date: Thu, 16 Apr 87  00:15:23 PDT
Subject: CLARIFICATION: [italics]package arguments.
To: common-lisp@SAIL.STANFORD.EDU
X-Mailer: NMail [$Revision: 2.6 $]

Are the package  functions  that take a package  argument in CLTL with
the name  [italics]package  allowed to have a string or symbol as that
argument?  If so, HP take note, we had to make a lot of changes in our
Symbolics  generated code to make it port to CL on the HPAIWS. If not,
then why not?

Bill Vrotney USC/ISI
-------

∂16-Apr-87  0859	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	bignums are bogus   
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 16 Apr 87  08:59:26 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 77243; Thu 16-Apr-87 09:32:15 EDT
Date: Thu, 16 Apr 87 09:35 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: bignums are bogus
To: Sandra J Loosemore <sandra%orion@cs.utah.edu>, common-lisp@sail.stanford.edu
In-Reply-To: <8704160601.AA15364@utah-orion.ARPA>
Message-ID: <870416093545.0.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Character-Type-Mappings: (1 0 (NIL 0) (:FIX :BOLD :NORMAL) "CPTFONTCB")
Fonts: CPTFONT, CPTFONTCB

I believe the spirit of CL is to encourage implementations to make the
maximum size of bignums "reasonably large".  I also believe the spirit
of CL is to have the lower limit be rather large, say at least 5000
bits.  The smaller the size of the largest bignum, the more applications
you lock out, such as symbolic algebras.

If you make the maximum size of an integer be the maximum size of a
fixnum, does that imply (+ most-positive-fixnum 1) generates an error?

I agree that a CLtL-defined implementation-dependent constant describing
the maximum number of bits of a bignum is consistent with CLtL; I'm not
sure how applications would make use of it, other than
  (when (< maximum-number-of-bignum-bits 9342)
    (error "This application won't work on this machine; bignums are too small."))

BTW, the Symbolics 3600 implementation limits bignums to 2↑28 bits.
Applications that create such things are going to page like mad.  The
error that is generated when exceeding is along the lines
    (ash 1 most-positive-fixnum)
    ε1Error: ASH shifting much too far to the left

∂16-Apr-87  0930	DLA@DIAMOND.S4CC.Symbolics.COM 	bignums are bogus 
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 16 Apr 87  09:30:27 PDT
Received: from LIMPKIN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 77351; Thu 16-Apr-87 12:29:18 EDT
Date: Thu, 16 Apr 87 12:29 EDT
From: David L. Andre <DLA@DIAMOND.S4CC.Symbolics.COM>
Subject: bignums are bogus
To: sandra%orion@cs.utah.edu, common-lisp@sail.stanford.edu
Message-ID: <870416122902.2.DLA@LIMPKIN.S4CC.Symbolics.COM>

I always favored a pair of variables MOST-POSITIVE-BIGNUM and
MOST-NEGATIVE-BIGNUM.   :-)

∂16-Apr-87  0946	RPG   	a lisp1 compatible subset of Common Lisp   
 ∂15-Apr-87  1853	KMP@STONY-BROOK.SCRC.Symbolics.COM 	a lisp1 compatible subset of Common Lisp    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Apr 87  18:52:43 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 117173; Wed 15-Apr-87 21:49:13 EDT
Date: Wed, 15 Apr 87 21:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: a lisp1 compatible subset of Common Lisp
To: Masinter.pa@Xerox.COM
cc: RPG@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <870327-152827-2635@Xerox>
Message-ID: <870415214810.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: 27 Mar 87 15:31 PST
    From: Masinter.pa@Xerox.COM
    Subject: a lisp1 compatible subset of Common Lisp
    To: RPG@SAIL.STANFORD.EDU, KMP@stony-brook.scrc.symbolics.com

    I'm sending this to you becasue you two make up the lisp-1 vs lisp-2
    committee. If others should be cc'd, please let me know.

    Imagine a subset of Common Lisp, called Common-Lisp-Disjoint-space with
    the following restrictions:

    a) it is an error for a symbol to have both a symbol-function and a
    symbol-value

    b) function-type (i.e., function data type is separate from other types)

This should be done in any case.

    c) lexical-global-scoping (i.e., the default for free, undeclared
    variable references is that they are in the global lexical context, not
    that they are dynamicly scoped).

This should be done in any case. I had dinner with Jonathan Rees tonight
and bugged him again to send out his proposal for proclaim-lexical.

    d) it is an error to use a function or macro with the same name as a
    lexical variable in the same lexical scope, i.e., to call list in a
    lexical scope that binds the variable list. (Of course, this applies
    even for those generated by macros.)

    This is a subset such that: 
    1) a program which runs in the subset will run in full common lisp
    (modulo the standard "portability" problems)

I mentioned at some point in the past and still believe that we should
actually define the term "subset" so that anyone claiming to have a subset
would have this property. This would keep one thing from being substituted
for another (eg, dynamic scoping for lexical scoping) while not disallowing
simple omissions.

In some trivial sense, I have no objection to anyone taking any dialect
which satisfies this criterion and calling it a CL subset. I do, however,
have an objection to extended subsets (where the extension is not 
CL-compatible).

    2) the "is an error" conditions imposed by the subset are enforcable,
    either by dynamic runtime checking or by static compile-time analysis

I think that "is an error" is always valid to enforce. I think what you
want to say is that things claiming to be in this subset may not extend
these restrictions and still claim to be the subset.

    Imagine a lisp-1 analogue of Common Lisp; I call it Common-Lisp-1-space.

This is the point at which I start to get worried about this. Much as the
Europeans are worried about our use of the string "Lisp" in the name 
"Common Lisp" causing them problems when they try to do other lisps, I 
worry about the use of the string "Common Lisp" in the name of anything
which is not claimed to be -the- Common Lisp. Perhaps I worry even a little
more in this case because the word "Common" was supposed to mean "Shared",
and in some sense you're suggesting a non-Shared Shared Lisp...

    Its properties are as follows:

    There is no symbol-function. Symbols have only one cell, symbol-value.
    All places in CLtL which say symbol-function now say symbol-value. The
    "function" special form is replaced as follows:

    (function frob) => frob
    (function (lambda ...)) => (lambda ...)

    lambda is a new special form, which does what (function (lambda ...))
    used to. 

In the abstract, these are not unreasonable properties for a language to have.
I certainly understand what you're driving at.

    - - - - - - - - - - - - - - - -
    - - - - - - - - - - - - - - - -
    Programs written in the subset Common-Lisp-Disjoint-space can by
    converted mechanically to Common-lisp-1-space  by defining
    symbol-function = symbol-value, and defining function as a macro. Some
    uses of funcall can be removed mechanically, although funcall is still
    occasionally useful (e.g.,  (mapcar funcall list-of-functions
    list-of-arguments)).

Well, not mechanically -- more like trivially. That is, you just add certain
functions to the environment --
 (DEFUN FUNCTION (X) X)
 (DEFMACRO LAMBDA (BVL &BODY FORMS) `#'(LAMBDA ,BVL ,@FORMS))
and things mostly work. Of course, this makes LAMBDA a macro, not a special 
form. Also, it makes FUNCTION not be a special form.

The problem is that the name you've chosen is very long and no one wants to
program in a language with a long name. If you make the name shorter, it will
sound more like "Common Lisp" -- unless you remove a critical word like 
"Common" or "Lisp" -- in which case the problem will be that it doesn't sound
enough like Common Lisp and so maybe no one will be interested in it.

Anyway, as long as it looks like Common Lisp, sounds like Common Lisp, etc.
it will drive a wedge into the pack of Common Lisp users, separating them
into separate camps. If there's one thing that is uppermost in importance,
I think, it is not to fragment the camps. CL was created with the explicit
purpose of eliminating the tower-of-babel effect in Lisp where no dialect
was able to talk to any other. I think it has done that well and we should
be careful not to destroy that.

I realize that the intent of your proposal is not to destroy it and that
you're trying to provide a peaceful way for people to coexist by allowing
them ways of saying that they want to program in a world that is neutral
about the issues that the Lisp1/Lisp2 folks are working out, but the problems
are that...

 * The camp you're asking them to live in offers neither the features
   of Lisp1 nor the features of Lisp2, and as such could be even more
   burdensome to them than either of the two positions -- perhaps causing
   some people to think Lisp is just too much hassle ... Lisp doesn't
   need that kind of negative PR at this time, I think.

 * I think that making the decision you want them to make involves users
   understanding a lot more about the linguistic process than it is 
   appropriate to make them aware of ... Many people just don't care
   about this issue a lot and we're starting to sound like the Christian
   church trying to spawn a lot of denominations ... To most people it's
   enough of a chore to decide that they belong to a major religion
   such as Lisp, Scheme, PL1, or C. The subtle denominational differences
   are something which is probably of more worry to us the clergy than it
   is to the users.

 * Making too many dialects which differ in ways that seem so subtle
   is likely to fragment the community into a lot of little communities
   who don't interact and for no good reason -- better we should just 
   insist that some agreement be reached. By allowing subsetting of this
   kind, we allow ourselves to not really address the issues and we take
   a statistical view on language design, observing after the fact what
   people liked (and trying to infer why) rather than a more reasoned
   approach.

 * I think many people use Common Lisp because they don't want to have
   to make decisions. There are AI researchers who got tired of tracking
   the feature distinctions between the dialects and justifying to their
   friends why they use dialect X instead of dialect Y. There are those
   who just got tired and said: "Give me a dialect which people seem to
   like and which I can use without feeling a need to justify myself.
   It doesn't have to be the best dialect; it just has to be an obviously
   reasonable dialect so I can just go out and learn it arbitrarily and
   do work in it and forget about the meta issues of whether or why the
   language works at all."

Some of these points seem to overlap. Oh well. I guess that means it's a
good point to stop.

I'm sorry these points took so long to conjure. I hope you find them useful.

∂16-Apr-87  1009	shebs%orion@cs.utah.edu 	Bognumosity    
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87  10:09:21 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
	id AA21692; Thu, 16 Apr 87 11:12:00 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
	id AA01398; Thu, 16 Apr 87 11:11:56 MDT
Date: Thu, 16 Apr 87 11:11:56 MDT
From: shebs%orion@cs.utah.edu (Stanley T. Shebs)
Message-Id: <8704161711.AA01398@utah-orion.ARPA>
To: common-lisp@sail.stanford.edu
Subject: Bognumosity

It only hurts CL as a standard when people start talking about the "spirit"
of the specification as a substitute for precision.  Some symbolic algebra
folks like really big numbers, starting at a "few thousand bits" and getting
bigger.  Bignums can also be a good representation technique for certain
kinds of data structures (almost like bit vectors, but with different ops
available).  Any vagueness on max size of bignums is no more acceptable
than it is for arrays or fixnums or floats, all of which have plenty of
constants defining *their* limits!

I think we should introduce an INTEGER-LENGTH-LIMIT constant which would be
the largest value that INTEGER-LENGTH could return.  It should be specifed
to be at least as large as MOST-POSITIVE-FIXNUM, with the usual exhortation
that "Implementors are encouraged to make this limit as large as practicable
without sacrificing performance." :-)

							stan

∂16-Apr-87  1042	jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	Re:  bignums are bogus   
Received: from TUNNEL.CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 16 Apr 87  10:41:38 PDT
Received: from aiva.edinburgh.ac.uk by mv1.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa08755; 16 Apr 87 13:06 WET
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Thu, 16 Apr 87 14:04:58 GMT
Message-Id: <1827.8704161404@aiva.ed.ac.uk>
To: common-lisp@sail.stanford.edu, sandra <@cs.utah.edu:sandra@orion.arpa>
Subject: Re:  bignums are bogus

> "Common Lisp in principle imposes no limit on the magnitude of an
> integer.

Note "in principle".

> I don't know of any machine that has an infinitely large amount of memory,
> or even an infinitely large address space.

Practical limits of this sort also apply to things like the maximum number
of conses, the maximum length of a list, etc.  Presumably, you don't think
lists are bogus...

> I expect some implementations of bignums have other constraints as well:
> assuming the number of bigits is a fixnum, storing the bigits in an array
> (limiting the number of bigits to the maximum array size), or similar
> representation-related problems.

Well, if the representation imposes a limit lower than that imposed by
the total storage available we might be justified in saying it is not a
correct implementation.  Of course, we would only be inclined to do this
if the lower limit was relatively small (e.g. number of bigits in a byte).

Now I suppose there'll be hundreds of these messages (at least as many as
about compiling CASE).

∂16-Apr-87  1054	FAHLMAN@C.CS.CMU.EDU 	Bognumosity  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87  10:54:24 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 16 Apr 87 13:44:06-EDT
Date: Thu, 16 Apr 1987  13:43 EDT
Message-ID: <FAHLMAN.12295009436.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   shebs%orion@λcs.utah.edu (Stanley T. Shebs)λ
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: Bognumosity
In-reply-to: Msg of 16 Apr 1987  13:11-EDT from shebs%orion at cs.utah.edu (Stanley T. Shebs)


    Any vagueness on max size of bignums is no more acceptable
    than it is for arrays or fixnums or floats, all of which have plenty of
    constants defining *their* limits!

    I think we should introduce an INTEGER-LENGTH-LIMIT constant which would be
    the largest value that INTEGER-LENGTH could return.  

Presumably, then we also need a constant called CONS-LIMIT, which is the
maximum allowable length of any list.  After all, someone might want to
use a list of T's and NIL's instead of a bit vector, and it weakens the
standard if we don't tell him exactly how long this list can be.

What we do if someone creates two of these maximum-length lists, or a
maximum-length list of maximum-length lists, I don't know, but we had
better decide, since it will weaken the standard if we are vague about
what is allowed here.  Let's just say that every legal Common Lisp must
have at least N cons cells available to the user at all times, no matter
what he may have used so far, or else it is not a legal Common Lisp.  N
should be at least a million.  Or maybe N should be seven.

A sufficiently tight standard will have no instances.

Maybe the scope of the smiley face at the end of your message was meant
to be the whole message?

-- Scott

∂16-Apr-87  1124	KMP@STONY-BROOK.SCRC.Symbolics.COM 	bignums are bogus, but so are fixnums  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Apr 87  11:24:17 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 117743; Thu 16-Apr-87 14:24:16 EDT
Date: Thu, 16 Apr 87 14:23 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: bignums are bogus, but so are fixnums
To: Fahlman@C.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU, RAM@C.CS.CMU.EDU,
    sandra%orion@cs.utah.edu, DCP@QUABBIN.SCRC.Symbolics.COM
In-Reply-To: <FAHLMAN.12294960256.BABYL@C.CS.CMU.EDU>
Message-ID: <870416142310.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

[Removed Common-Lisp, and added CL-Cleanup for sake of flame control.]

While we're on the subject, I think CLtL is ambiguous on whether
you're required to have a non-zero number of either bignums or
fixnums. That is, if you use a uniform representation for integers,
I think it's unclear whether you can arbitrarily choose to call them
either fixnums or bignums.

If you choose to call all integers bignums, then I'm not completely 
clear on what the value of MOST-POSITIVE-FIXNUM and MOST-NEGATIVE-FIXNUM
should be, since I bet most code assumes that the 
 (THE FIXNUM MOST-POSITIVE-FIXNUM)
is not an error.

If you choose to call all integers fixnums, then it's not clear what
to set MOST-POSITIVE-FIXNUM and MOST-NEGATIVE-FIXNUM to, since there
may not be an upper bound. For example, adding another piece of memory
or disk may allow you to dynamically change the value. Also, presumably,
your entire Lisp image would be taken up by representing this value.

Also, it isn't made clear that if you choose to have fixnums that
zero must be one. If you choose your fixnum range to be 500-650,
then it seems clear that MOST-NEGATIVE-FIXNUM should be 500 because
it's a fixnum and because of all the fixnums, it's the most negative
(though in fact it's not negative at all). I think this would surprise
some programs, though. In fact, if the range were completely negative,
then MOST-POSITIVE-FIXNUM might be negative. To see the problems you
can get into, consider the following code which I once wrote for
some fairly obscure application... I needed a count of the number of 
possible fixnums for some obscure reason and I did 
  (+ (- MOST-NEGATIVE-FIXNUM) ; Assume this value is negative.
     1 			      ; Account for 0
     MOST-POSITIVE-FIXNUM)    ; Assume this value is positive.
I suppose I should have done
  (+ (- MOST-POSITIVE-FIXNUM MOST-NEGATIVE-FIXNUM) 1)
I guess I was afraid of the fencepost problems in this. In any
case, this doesn't even work unless an implementation with no fixnums
is careful to pick MOST-POSITIVE-FIXNUM to be something like -1
and MOST-NEGATIVE-FIXNUM to be 0 so that they sum to -1. If you choose
them both to be 0, which would seem most obvious to me, then my code
would probably guess that there was 1 fixnum (and a human onlooker
would probably infer that the one fixnum was 0).

I imagine there's an analagous set of hassles that can come up, for
example, if short floats represent a range of numbers that don't contain
a value appropriate for SHORT-FLOAT-EPSILON, or whatever.  

These are not just mental exercises. I vaguely remember a while back
reviewing specs for various CL implementations we were considering
as targets for Macsyma and running across at least one that had some
of the aforementioned problems, which is what got me thinking about
this issue in the first place...

Some careful thought about whether these variables should be allowed 
to contain NIL when some other value would be meaningless or
computationally impractical is probably in order.

∂16-Apr-87  1211	shebs%orion@cs.utah.edu 	Re:  Bognumosity    
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87  12:11:42 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
	id AA28433; Thu, 16 Apr 87 13:14:17 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
	id AA01837; Thu, 16 Apr 87 13:14:13 MDT
Date: Thu, 16 Apr 87 13:14:13 MDT
From: shebs%orion@cs.utah.edu (Stanley T. Shebs)
Message-Id: <8704161914.AA01837@utah-orion.ARPA>
To: Fahlman@c.cs.cmu.edu, shebs%orion@λcs.utah.eduλ
Subject: Re:  Bognumosity
Cc: common-lisp@sail.stanford.edu

        Any vagueness on max size of bignums is no more acceptable
        than it is for arrays or fixnums or floats, all of which have plenty of
        constants defining *their* limits!
    
        I think we should introduce an INTEGER-LENGTH-LIMIT constant which would be
        the largest value that INTEGER-LENGTH could return.  
    
    Presumably, then we also need a constant called CONS-LIMIT, which is the
    maximum allowable length of any list.  After all, someone might want to
    use a list of T's and NIL's instead of a bit vector, and it weakens the
    standard if we don't tell him exactly how long this list can be.
    
That's part of my thesis work, so I won't insist on it being in the standard
right now!  A CONS-LIMIT of some sort would be necessary in a Lisp system
that produces programs for embedded systems, however, so it's not as
ridiculous as it appears to be...
    
    Maybe the scope of the smiley face at the end of your message was meant
    to be the whole message?

Sorry, I was quite serious.  If bignum size limits are silly, then why are
array size limits not silly?   Seems inconsistent.

Here's a (serious) meta-proposal:  every type of potentially unbounded
size must have limit parameters.  This would include arrays of all types,
numbers (both floats and rationals), packages, random states, compiled code,
hash tables, and structures.  There wouldn't be any need for a CONS-LIMIT,
because individual conses are always the same size, and a possible LIST-LIMIT
would not be meaningful, because LIST is (OR CONS NULL).

Right now the only limits are on arrays, fixnums, and floats, so there would
be a lot of extra parameters.  On the other hand, I've observed some rather
wild variation in the number of bits in a random state, which affects the
quality of random number generation.  An unlucky user of packages may find
that a package is implemented with a hash table, which is implemented with
an array, which has an ARRAY-DIMENSION-LIMIT of 1024, limiting the total
number of symbols in a package to that many.  I'm sure we're all familiar
with the sort of terminology that users apply to implementors when tricks
like this come to light...

Anyway, if all this is stupid, let me know and I'll shut up.

								stan
	

∂16-Apr-87  1216	DALY@IBM.COM 	typos in Cltl   
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87  12:16:34 PDT
Date: 16 April 1987, 14:48:02 EDT
From: Timothy Daly <DALY@ibm.com>
To:   common-lisp@sail.stanford.edu
Message-Id: <041687.144803.daly@ibm.com>
Subject: typos in Cltl

There is a typo on p 277.
The line reads:
  ((a b) #(f 3) ....
it should read
  (#(a b) #(f 3) ....

the dispatching macro character is missing.
I didn't see this one in the list of typos dated 12/85.
Is there a later one?

∂16-Apr-87  1237	hoey@nrl-aic.ARPA 	Re: Bognumosity 
Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 16 Apr 87  12:37:30 PDT
Return-Path: <hoey@nrl-aic.ARPA>
Received: Thu, 16 Apr 87 14:37:44 est by nrl-aic.ARPA id AA21715
Date: 16 Apr 1987 14:19:04 EST (Thu)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: Bognumosity
To: common-lisp@sail.stanford.edu
Message-Id: <545599144/hoey@nrl-aic>

    Date: Thu, 16 Apr 87 11:11:56 MDT
    From: shebs%orion@cs.utah.edu (Stanley T. Shebs)
    Message-Id: <8704161711.AA01398@utah-orion.ARPA>
    To: common-lisp@sail.stanford.edu

    I think we should introduce an INTEGER-LENGTH-LIMIT constant which
    would be the largest value that INTEGER-LENGTH could return.  It
    should be specifed to be at least as large as
    MOST-POSITIVE-FIXNUM....

Simpler would be to use ARRAY-TOTAL-SIZE-LIMIT for this value.  This is
based on the duality of bignums and bit vectors.  If implementors then
want to represent bignums in some silly way that restricts them, they
can then reduce their advertised ATSL (but not below 1024).

I think a Lisp with 1K-bit bignums would be about as unusable as a lisp
with 1K-element arrays.

Dan


∂16-Apr-87  1310	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re:  Bognumosity 
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 16 Apr 87  13:10:02 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72653; Thu 16-Apr-87 16:09:51 EDT
Date: Thu, 16 Apr 87 16:06 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re:  Bognumosity
To: shebs%orion@cs.utah.edu, Fahlman@CMU-CS-C.ARPA
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8704161914.AA01837@utah-orion.ARPA>
Message-ID: <870416160605.2.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Thu, 16 Apr 87 13:14:13 MDT
    From: shebs%orion@cs.utah.edu (Stanley T. Shebs)

				  There wouldn't be any need for a CONS-LIMIT,
    because individual conses are always the same size,

But what if I wanted to write a program for, as you say, an embedded
system, and I needed to know exactly how many cons cells I can create
and be quite certain that I won't run out of memory?  Conversely, if I
know what the bignum limit is, and I stay within that limit, but make
zillions of such legal bignums, then I might run out of virtual memory. 
So whether the individual object is of fixed size or of variable size
doesn't really matter, for the purposes you're referring to.

∂16-Apr-87  1317	sdcrdcf!darrelj@CS.UCLA.EDU 	Re: bignums are bogus
Received: from CS.UCLA.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87  13:17:25 PDT
From: sdcrdcf!darrelj@CS.UCLA.EDU
Received: by sdc.uucp (4.12/sdcrdcf)
        id AA05609; Thu, 16 Apr 87 12:54:57 pst
Message-Id: <8704162054.AA05609@sdc.uucp>
Received: from XAVIER by sdcrdcf with PUP; Thu, 16 Apr 87 12:54 PST
Date: 16 Apr 87 12:59 PDT (Thursday)
Subject: Re: bignums are bogus
In-Reply-To: sdcjove!cs.utah.edu!sandra%orion (Sandra J Loosemore)'s message of Thu, 16 Apr 87 00:01:04 MDT
To: sdcjove!cs.utah.edu!sandra%orion (Sandra J Loosemore)
Cc: common-lisp%sail.stanford.edu

You could always take the approach that Xerox did.  Implement bignums
in such an inefficient way that processing time grows to unacceptable
levels before representation limits are anything close to reached!

(Actually I only see a few possibilities for representation: a list of
fragments [Xerox uses lists of 14 bit components]; arrays of
fragments; or something your hardware supports which is sort of large:
e.g. 128 bit floating or 31 digit packed decimal on IBM 370s, 99 digit
decimal on Symbol-IIR, etc.  The first two could be expected to
support a million bits on almost anything from an IBM PC upwards. 
Operation time and "consing" overhead would be pretty grim.  Only the
array case might have an obvious hard upper bound.  The third case
would certainly verge on "broken" by almost any reasonable standards.
	Darrel

∂16-Apr-87  1349	@SAIL.STANFORD.EDU:REM@IMSSS 	How much memory for bignum or other large data structure?   
Received: from SAIL.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87  13:49:24 PDT
X-Date-last-edited: 1987 April 16 12:48:04 PST (=GMT-8hr)
From: Robert Elton Maas <REM%IMSSS@SAIL.Stanford.EDU>
To:common-lisp@SAIL.STANFORD.EDU
CC:hoey@nrl-aic.ARPA
Subject:How much memory for bignum or other large data structure?

<RAM> Date: Thu, 16 Apr 1987  10:27 EDT
<RAM> From: Rob MacLachlan <RAM@C.CS.CMU.EDU>

<RAM> The problem with running out of storage has no special relation to
<RAM> bignums of course.  Some programs may require data structures larger
<RAM> than some implementations can support on a given hardware
<RAM> configuration.  This is a potential portability problem, but I see
<RAM> nothing that can be done about it.

I do. A program can be aware of how close it is getting to using all
available memory (address space, swap space, etc.) by means of calls
to the LISP (CL) system, and adjust its behaviour accordingly to avoid
actually reaching the absolute limit. In this way a program can
effective utilize virtually all the memory available on any given
machine at any given time, instead of setting some arbitrary portable
limit on memory usage which may be far below that actually available.

Several kinds of programs run better the more memory they actually
use. Examples are: (1) Sort/merge, the more data that can be sorted in
memory, the larger sorted-segments can be emitted from the first pass
and the fewer disk-passes needed to merge the sorted-segments into a
single sorted-segment; (2) Any planning/lookahead program such as game
playing or robotics, the more data that can be stored in a tree
structure or hash table representing choices already analyzed, the
further ahead the program can look without having to recompute the
same choices over and over again, and thus the better "intelligence"
the program can exhibit.

In addition to parameters on particular data types that determine
their limits because of internal representation, every LISP
implementation should provide a way for a running program to ask how
much memory is remaining not currently in use (or in a system with
different kinds of data in different kinds of memory, how much memory
of a particular kind is not currently not in use). A program could ask
once, and if the answer comes back too small then force a
garbage-collect-completion and ask again, and if the answer is still
too small the program truncates its expansion at that point.

This facility is crucial enough for the kinds of "artificial
intelligence" programs typical of LISP, and is trivial enough to
implement in the underlying LISP system and virtually impossible to
hack up by user-level programming, that it should be a *required*
feature of every implementation, i.e. should be in the CL standard.

<RAM> Perhaps Common Lisp should specify a minimum maximum size for bignums
<RAM> and require that an error be signalled if this is ever exceeded.  I
<RAM> would guess that a limit of a few thousand bits would meet every use
<RAM> except the most common, namely impressing non-lispers by typing 
<RAM> (FACT 1000) and getting screens full of digits.

If the limit is representational, then indeed an
implementation-dependent largest-size-allowed parameter should be
provided by the system. If the limit is due to total memory use, any
system query specifically regarding bignums would have to use the
memory-remaining information to compute the bignum-that-would-fit
information, to account for memory already used and hence not
available. For the factorial hack, the toplevel FACT function could
first approximate the factorial by logarithms, check to see whether
there is enough memory for that data, and if not then complain and
advise the user what the maximum workable argument to FACT currently is.

<DLA> Date: Thu, 16 Apr 87 12:29 EDT
<DLA> From: David L. Andre <DLA@DIAMOND.S4CC.Symbolics.COM>

<DLA> I always favored a pair of variables MOST-POSITIVE-BIGNUM and
<DLA> MOST-NEGATIVE-BIGNUM.   :-)

Of course if this is based on memory available, only one of the two
could exist at any time, and as soon as it existed it would contradict
itself because there'd be no room left for the bignum you really
wanted. (This explanation is in case anybody didn't fully get the joke.)

<STS> Date: Thu, 16 Apr 87 13:14:13 MDT
<STS> From: shebs%orion@cs.utah.edu (Stanley T. Shebs)

<STS> Here's a (serious) meta-proposal:  every type of potentially unbounded
<STS> size must have limit parameters.  This would include arrays of all types,
<STS> numbers (both floats and rationals), packages, random states,
<STS> compiled code, hash tables, and structures.  There wouldn't be any
<STS> need for a CONS-LIMIT, because individual conses are always the same
<STS> size, and a possible LIST-LIMIT would not be meaningful, because LIST
<STS> is (OR CONS NULL).

I second that proposal (see the first part of my message) with
amendment (clarification) that these limit parameters refer to
representation rather than memory available. For example, if BIGNUMs
are implemented in a recursive way, there may be no limit on their
size whatsoever other than memory available, and some extremely
gigantic but sparse BIGNUMs may in fact be representable while some
smaller ones that aren't sparse wouldn't; in such a case the limit
parameter would be INFINITY. But if the number-of-digits of a BIGNUM
is a FIXNUM, then there's an absolute representational limit which is
given in the proposed limit parameter. -- In addition to these limit
parameters, of course, is my proposal for runtime memory-not-yet-used query.

<STS> Right now the only limits are on arrays, fixnums, and floats, so
<STS> there would be a lot of extra parameters.

Yes, but compared to the total memory available the limit parameters
would be insignificant in size, thus no problem.

<DH> Date: 16 Apr 1987 14:19:04 EST (Thu)
<DH> From: Dan Hoey <hoey@nrl-aic.ARPA>

<DH> Simpler would be to use ARRAY-TOTAL-SIZE-LIMIT for this value.

I don't understand this proposal. If all arrays are stored in some
special place in memory, that limits their total size without being
affected by CONSs consuming memory elsewhere, that would make sense.
Or do you mean the total number of elements in a single array of
multiple dimensions (axes) because of a machine limit on the size of
an index register?  Please clarify?

∂16-Apr-87  1354	shebs%orion@cs.utah.edu 	Re:  Bognumosity    
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87  13:54:13 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
	id AA03494; Thu, 16 Apr 87 14:56:23 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
	id AA02607; Thu, 16 Apr 87 14:56:17 MDT
Date: Thu, 16 Apr 87 14:56:17 MDT
From: shebs%orion@cs.utah.edu (Stanley T. Shebs)
Message-Id: <8704162056.AA02607@utah-orion.ARPA>
To: DLW@alderaan.scrc.symbolics.com, Fahlman@cmu-cs-c.arpa,
        shebs%orion@cs.utah.edu
Subject: Re:  Bognumosity
Cc: common-lisp@sail.stanford.edu

In case it wasn't clear, I was *not* trying to address the issue of the
relation between number/size of objects and size of memory available.  I'm
well aware that there are many problems, *and* very little research on them
(if anybody knows of anything, I want to hear about it).  I shouldn't have
said anything about embedded systems, they're irrelevant.

What can and should be done is to formalize the limitations that implementors
wire into the representations of data objects.  Those limits will be there
no matter how much or how little memory is available, since they have to
do with the bit patterns of data structures.  If you have a program that
wants a 1025 element array in a Lisp that limits arrays to 1024 elements,
making the heap bigger isn't going to help.

								stan

∂16-Apr-87  1403	preece%mycroft@gswd-vms.ARPA 	Re: Bognumosity
Received: from GSWD-VMS.ARPA by SAIL.STANFORD.EDU with TCP; 16 Apr 87  14:02:44 PDT
Received: from mycroft.GSD (mycroft.Gould.COM) by gswd-vms.ARPA (5.52/)
Message-Id: <8704162101.AA04269@gswd-vms.ARPA>
Date: Thu, 16 Apr 87 15:00:04 CST
From: preece%mycroft@gswd-vms.ARPA (Scott E. Preece)
To: COMMON-LISP@sail.stanford.edu
Subject: Re: Bognumosity

  Fahlman@C.CS.CMU.:
    stanley shebs:
>> I think we should introduce an INTEGER-LENGTH-LIMIT constant which would be
>> the largest value that INTEGER-LENGTH could return.  

> Presumably, then we also need a constant called CONS-LIMIT, which is the
> maximum allowable length of any list.  After all, someone might want to
> use a list of T's and NIL's instead of a bit vector, and it weakens the
> standard if we don't tell him exactly how long this list can be.
>
> What we do if someone creates two of these maximum-length lists, or a
> maximum-length list of maximum-length lists, I don't know, but we had
> better decide, since it will weaken the standard if we are vague about
> what is allowed here.
----------
The problem is that that is exactly what the limits DON'T do -- they
don't guarantee that at any given moment the biggest array you can create
is size x.  I don't really think the various limits already provided
are worth much.  Once in a while they may allow someone to decide
early on that porting a particular application to a particular
implementation is infeasible (because it uses arrays, or whatever, that
are bigger than a limit), but it can never give much assurance that
an application which does respect the limits is portable to a
particular implementation, since at any given moment there may not
be space available to allocate an object, even though it of legal
size for the implementation.

The implementor is left with the problem of deciding what to advertise
as the limits for her particular implementation.  What will users
care about?  The largest array that can be allocated on an empty
system with maximum memory?  The largest array that can be allocated
on an empty system with the smallest memory configuration sold?  The
largest array that can be allocated with memory in a "typical"
configuration and already populated with a "typical" amount of
pre-existing stuff?  What's typical?

Adding more limits doesn't seem to me to be very useful.

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

∂16-Apr-87  1411	preece%mycroft@gswd-vms.ARPA 	Re: Bognumosity
Received: from GSWD-VMS.ARPA by SAIL.STANFORD.EDU with TCP; 16 Apr 87  14:10:01 PDT
Received: from mycroft.GSD (mycroft.Gould.COM) by gswd-vms.ARPA (5.52/)
Message-Id: <8704162108.AA04289@gswd-vms.ARPA>
Date: Thu, 16 Apr 87 15:00:04 CST
From: preece%mycroft@gswd-vms.ARPA (Scott E. Preece)
To: COMMON-LISP@sail.stanford.edu
Subject: Re: Bognumosity

  Fahlman@C.CS.CMU.:
    stanley shebs:
>> I think we should introduce an INTEGER-LENGTH-LIMIT constant which would be
>> the largest value that INTEGER-LENGTH could return.  

> Presumably, then we also need a constant called CONS-LIMIT, which is the
> maximum allowable length of any list.  After all, someone might want to
> use a list of T's and NIL's instead of a bit vector, and it weakens the
> standard if we don't tell him exactly how long this list can be.
>
> What we do if someone creates two of these maximum-length lists, or a
> maximum-length list of maximum-length lists, I don't know, but we had
> better decide, since it will weaken the standard if we are vague about
> what is allowed here.
----------
The problem is that that is exactly what the limits DON'T do -- they
don't guarantee that at any given moment the biggest array you can create
is size x.  I don't really think the various limits already provided
are worth much.  Once in a while they may allow someone to decide
early on that porting a particular application to a particular
implementation is infeasible (because it uses arrays, or whatever, that
are bigger than a limit), but it can never give much assurance that
an application which does respect the limits is portable to a
particular implementation, since at any given moment there may not
be space available to allocate an object, even though it of legal
size for the implementation.

The implementor is left with the problem of deciding what to advertise
as the limits for her particular implementation.  What will users
care about?  The largest array that can be allocated on an empty
system with maximum memory?  The largest array that can be allocated
on an empty system with the smallest memory configuration sold?  The
largest array that can be allocated with memory in a "typical"
configuration and already populated with a "typical" amount of
pre-existing stuff?  What's typical?

Adding more limits doesn't seem to me to be very useful.

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

∂16-Apr-87  1419	edsel!bhopal!jonl@navajo.stanford.edu 	bignums are bogus    
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87  14:19:12 PDT
Received: by navajo.stanford.edu; Thu, 16 Apr 87 14:18:18 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
	id AA01743; Thu, 16 Apr 87 13:03:36 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
	id AA10792; Thu, 16 Apr 87 14:00:34 PDT
Date: Thu, 16 Apr 87 14:00:34 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704162100.AA10792@bhopal.edsel.com>
To: navajo!DLA%DIAMOND.S4CC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!sandra%orion%cs.utah.edu@navajo.stanford.edu,
        navajo!common-lisp%sail@navajo.stanford.edu
In-Reply-To: David L. Andre's message of Thu, 16 Apr 87 12:29 EDT
Subject: bignums are bogus

re: I always favored a pair of variables MOST-POSITIVE-BIGNUM and
    MOST-NEGATIVE-BIGNUM.   :-)
As silly as this may sound, I actually ran up against this. Really!
It turns out that most implementations have the bignum's length stored
in some field of fixed size (say, n bits).  I accidentally computed up
such an item on a 3600 about a year or so ago (while writing the
"bignum" paper for the 1986 Lisp conference).  It seemed as though
the computation was taking far too long.  Ultimately, I tracked it down
to the fact that the ephemeral GC couldn't find enough space to copy
the fool thing (even though it had been created), so it fell into the
debugger, and was trying to print out this loser for me.  In base 10!

-- JonL --

P.S.  It never finised the base-10-conversion process.

∂16-Apr-87  1426	FAHLMAN@C.CS.CMU.EDU 	bignums are bogus, but so are fixnums 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87  14:26:28 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 16 Apr 87 17:12:21-EDT
Date: Thu, 16 Apr 1987  17:11 EDT
Message-ID: <FAHLMAN.12295047205.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:   CL-Cleanup@SAIL.STANFORD.EDU, DCP@SCRC-QUABBIN.ARPA, RAM@C.CS.CMU.EDU,
      sandra%orion@CS.UTAH.EDU
Subject: bignums are bogus, but so are fixnums
In-reply-to: Msg of 16 Apr 1987  14:23-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>


    Some careful thought about whether these variables should be allowed 
    to contain NIL when some other value would be meaningless or
    computationally impractical is probably in order.

Fine, this is under-specified and should be cleaned up.  My opinion is
that this is deeply unimportant and should be considered last, after
every other issue raised to date has been settled.  I just don't lie
awake nights thinking about what the fixnum limit constants should be
fore implementations in which the fixnum range is 500 to 570.

If you think this issue deserves a higher priority, feel free to submit a
definite proposal for how to clean it up.

-- Scott

∂16-Apr-87  1511	Masinter.pa@Xerox.COM 	bignums are bogus
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87  15:10:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 APR 87 15:10:31 PDT
Date: 16 Apr 87 15:14 PDT
From: Masinter.pa@Xerox.COM
Subject: bignums are bogus
In-reply-to: various
cc: common-lisp@sail.stanford.edu
Message-ID: <870416-151031-1512@Xerox>

The only practical way I know of dealing with storage limits and the
like in a programmatic way is to treat reaching them as well defined
exceptional situations which signal conditions. Programs that care, such
as those in embedded systems, can catch those exceptional situations and
do something reasonable with them, whether it is a bignum storage
overflow or running out of CONS space. 

This is addressed in part in the exceptional-situations-in-Lisp
proposal, which is still (apparently) in committee. 


∂16-Apr-87  1513	hoey@nrl-aic.ARPA 	Re: How much memory for bignum or other large data structure?
Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 16 Apr 87  15:12:57 PDT
Return-Path: <hoey@nrl-aic.ARPA>
Received: Thu, 16 Apr 87 17:12:59 est by nrl-aic.ARPA id AA22340
Date: 16 Apr 1987 16:16:36 EST (Thu)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: How much memory for bignum or other large data structure?
To: Robert Elton Maas <REM%IMSSS@SAIL.Stanford.EDU>
Message-Id: <545606196/hoey@nrl-aic>
In-Reply-To: Robert Elton Maas's message of Thu, 16 Apr 87 154955 est
Cc: common-lisp@sail.stanford.edu

    Date: Thu, 16 Apr 87 15:49:55 est
    From: Robert Elton Maas <REM%IMSSS@SAIL.Stanford.EDU>
    To: common-lisp@SAIL.STANFORD.EDU
    Cc: hoey@nrl-aic.ARPA

    A program can be aware of how close it is getting to using all
    available memory (address space, swap space, etc.) by means of calls
    to the LISP (CL) system, and adjust its behaviour accordingly to avoid
    actually reaching the absolute limit.

The hard part is actually defining portably how to do this.  I can
imagine it might be hard for some systems to implement a function to
answer ``I want to make 50 100k-bit bignums, 100 10k fixnum-arrays, and
maybe 10K of conses, is there space?''.  Comments from implementors?
Maybe the function should take a key like :VERY-MUCH to request GC if
necessary.

Then again, a negative answer to this query might be less than useful
if the reason is that the system doesn't support 10k fixnum arrays.
And I don't favor adding a ton of hair to allow the system to answer
some of the fine-grained questions Maas proposes. In particular

    <STS> ... there would be a lot of extra parameters.

    Yes, but compared to the total memory available the limit parameters
    would be insignificant in size, thus no problem.

I'm concerned about the space consumed in the bookshelf and interaural
areas.

    <DH> Date: 16 Apr 1987 14:19:04 EST (Thu)
    <DH> From: Dan Hoey <hoey@nrl-aic.ARPA>

    <DH> Simpler would be to use ARRAY-TOTAL-SIZE-LIMIT for this value.

    I don't understand this proposal.

I was not proposing addition of runtime-related storage information,
because that has so far remained outside of CL's scope (unless someone
out there actually has MAKE-ARRAY (and CONS?) side-effect
ARRAY-TOTAL-SIZE-LIMIT).  What I advocate is that *if* some
implementation has a representational limit on BIGNUMS, it should be
required to provide it.  And rather than add the 776th symbol to LISP
(we may be running out!), I suggested using the same limit that
guarantees the size of a bit vector.  The system may be able to make a
larger bignum than ARRAY-TOTAL-SIZE-LIMIT, but the same is true of bit
vectors.  What I want the parameters for is to determine whether a
given implementation is a toy or a system.

Dan

∂16-Apr-87  1517	Pavel.pa@Xerox.COM 	Re: typos in Cltl   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87  15:17:36 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 APR 87 15:14:24 PDT
Date: 16 Apr 87 15:14 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: typos in Cltl
In-reply-to: Timothy Daly <DALY@ibm.com>'s message of 16 April 1987,
 14:48:02 EDT
To: DALY@ibm.com
cc: common-lisp@sail.stanford.edu
Message-ID: <870416-151424-1516@Xerox>

That example isn't a typo.  Note that the list (a b) is a member of the
second argument to UNION.  This fact is even brought out specifically in
the text as a reason to use :test-not #'mismatch instead of :test
#'equalp.

	Pavel

∂16-Apr-87  1605	sandra%orion@cs.utah.edu 	bugnums (er, bignums)   
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87  16:04:50 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
	id AA10150; Thu, 16 Apr 87 17:07:29 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
	id AA03261; Thu, 16 Apr 87 17:07:25 MDT
Date: Thu, 16 Apr 87 17:07:25 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8704162307.AA03261@utah-orion.ARPA>
Subject: bugnums (er, bignums)
To: common-lisp@sail.stanford.edu

I realize that running out of memory is a more general problem, and in fact
my main concern in bring this issue up was the representation issue and the
fact the CLtL defines constants and states (or recommends) minimum values
for the sizes of other kinds of objects, such as arrays and floats.
If, as some people have pointed out, having a stated limit on integer 
size would be silly because "there's nothing you can do once you run out 
of memory anyway" (or comments to that effect), than it is equally silly 
to specify limits on the size of these other objects.

I am *not* proposing any minimum limits on the *number* of objects an
implementation can support:  this is purely an issue of the *size* of a
single object.

As a secondary issue, I thought that clarifying the semantics of integer
overflow might be useful to those of us working with small implementations
on small machines; in my case, a M68K box with a meg of memory.  It's 
unlikely that I'd be able to fit a full CL on this machine and I think 
that there are other features far more important to the "spirit" of the 
spec than support for huge bignums.  (I'm all for adhering to the "spirit" 
of the spec, particularly since I don't have much chance of adhering to 
the letter!)  The point is, I can make anybody's bignum implementation 
overflow, whether the maximum number of bits I can have is 32 or 
most-positive-fixnum.  It just happens a lot more often if the limit is 32.  

Incidentally, I can think of a few other potential problems with trying 
to allocate large objects, other than the obvious representation or
running-out-of-memory problems.  For example, your operating system may 
impose a limit on the size of contiguous memory block you can snarf up.  
(I've already run into this using a C compiler with 16 bit ints -- malloc 
takes an "int" sized argument....)  Or, your Lisp compiler may assume 
that 16 bits is sufficient to represent the displacement used for 
indexing into an array.

-Sandra
-------

∂16-Apr-87  1632	ghenis.pasa@Xerox.COM 	SOME and Multiple Values   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87  16:32:01 PDT
Received: from PinotNoir.ms by ArpaGateway.ms ; 16 APR 87 16:33:00 PDT
Date: 16 Apr 87 16:31 PDT
From: ghenis.pasa@Xerox.COM
Subject: SOME and Multiple Values
To: common-lisp@sail.stanford.edu
Message-ID: <870416-163300-1658@Xerox>

Is it reasonable to expect SOME to return multiple values? CLtL says:

"SOME returns as soon as any invocation of predicate returns a non-nil
value. SOME returns that value."

What if the predicate returns multiple values?

Meta-question: As a matter of current semantics, are multiple values
mandatory only when the standard EXPLICITLY says so?

∂16-Apr-87  1652	Masinter.pa@Xerox.COM 	Uncle Lisp Needs You  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87  16:52:36 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 APR 87 16:53:36 PDT
Date: 16 Apr 87 16:57 PDT
From: Masinter.pa@Xerox.COM
Subject: Uncle Lisp Needs You
To: cl-cleanup@sail.stanford.edu
Message-ID: <870416-165336-1679@Xerox>

If you would like to have some of the proposals we have before us
actually GET VOTED ON at the next X3J13 meeting, rather than merely
enjoying the intellectual stimulation of discussing them, it is
necessary for you (collectively) to VOLUNTEER (or find someone to
volunteer) to actually work on writing up/editing the proposals we have.

Scott has promised to take a few on in the next week. I need more.
Please.

∂16-Apr-87  1703	pyramid!pyramid.UUCP!bein@hplabs.HP.COM 	Re: Bognumosity    
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87  17:03:09 PDT
Received: by hplabs.HP.COM ; Thu, 16 Apr 87 14:32:00 pst
Received: from manpyrnova 
	by pyramid.UUCP (5.52/UUCP-Project/rel-1.0/09-16-86)
	id AA12155; Thu, 16 Apr 87 14:51:24 PDT
Received: by pyrnova.pyramid.COM (5.52/UUCP-Project/rel-1.0/09-11-86)
	id AA23093; Thu, 16 Apr 87 14:51:11 PDT
Date: 16 Apr 1987 14:44 PDT
From: David Bein <pyramid!bein@hplabs.HP.COM>
Subject: Re: Bognumosity
To: hplabs!common-lisp@sail.stanford.edu@hplabs.HP.COM
Message-Id: <545606488/bein@pyrnova>

Stan:

  I agree with the spirit of essentially unlimited size bignums. On
most of the systems I know of, most-positive-fixnum is 27 bits or more,
implying that a bignum that long would take at least 16 megabytes to
represent unless one is willing to introduce a notion like floating
point where low order bits are not represented beyond some limit,
at which point why not use floating point to begin with. My system
in fact adheres roughly to your suggestion, where technically a
bignum 134217702 bits long can be allocated (most-positive-fixnum is
134217727 in my system). I think you'll find that doing anything
with a bignum that long is next to impossible since other resources
like scratch stack space may not accomodate multiple copies of something
that large (which of course is not very interesting when it happens).

  I would almost suggest that if there is a limit, it be tied to
notions like the largest float since a larger bignum can't be converted
properly unless we introduce notions like floating-infinities into the
language. If we do that however, we end up needing a definition for
rational infinity. I don't have a good handle on what infinity means
from an operational point of view. Maybe getting out of digit computers
for a while would help -- :-)

  I too am uncomfortable with the idea that rational numbers overflow,
but don't have any practical ideas about what do besides treat the
problem as simply a resource problem which is what I am already doing.

--David

∂16-Apr-87  1703	ghenis.pasa@Xerox.COM 	SETF and pathname slots    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87  17:03:10 PDT
Received: from PinotNoir.ms by ArpaGateway.ms ; 16 APR 87 17:03:08 PDT
Date: 16 Apr 87 17:01 PDT
From: ghenis.pasa@Xerox.COM
Subject: SETF and pathname slots
To: common-lisp@sail.stanford.edu
Message-ID: <870416-170308-1688@Xerox>

Should the standard require SETF to handle pathname slots? If we are
going to have MAKE-PATHNAME, PATHNAME-DEVICE, etc, for consistency we
should also have COPY-PATHNAME and be able to do things like (SETF
(PATHNAME-TYPE old-path) "OLD"). Is there any reason not to?

∂16-Apr-87  1736	FAHLMAN@C.CS.CMU.EDU 	SOME and Multiple Values    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87  17:35:58 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 16 Apr 87 20:37:18-EDT
Date: Thu, 16 Apr 1987  20:37 EDT
Message-ID: <FAHLMAN.12295084669.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   ghenis.pasa@XEROX.COM
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: SOME and Multiple Values
In-reply-to: Msg of 16 Apr 1987  19:31-EDT from ghenis.pasa at Xerox.COM


    Is it reasonable to expect SOME to return multiple values? CLtL says:

    "SOME returns as soon as any invocation of predicate returns a non-nil
    value. SOME returns that value."

    What if the predicate returns multiple values?

No, for the same reason that OR returns only a single value for clauses
other than the last one.  That is, the implicit NULL test "consumes" the
values returned from the predicate, discarding all but the last one.

-- Scott

∂16-Apr-87  1917	diamant%hpfclp@hplabs.HP.COM 	Re: CLARIFICATION: [italics]package arguments.    
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87  19:17:10 PDT
Received: from hpfclp.HP.COM by hplabs.HP.COM with TCP ; Thu, 16 Apr 87 14:21:15 pst
Received: by hpfclp.HP.COM; Thu, 16 Apr 87 16:20:21 mst
Date: Thu, 16 Apr 87 16:20:21 mst
From: John Diamant <diamant%hpfclp@hplabs.HP.COM>
Return-Path: <diamant@hpfclp>
Message-Id: <8704162320.AA08469@hpfclp.HP.COM>
To: vrotney@vaxa.isi.edu
Cc: common-lisp@sail.stanford.edu
Subject: Re: CLARIFICATION: [italics]package arguments.

> Are the package  functions  that take a package  argument in CLTL with
> the name  [italics]package  allowed to have a string or symbol as that
> argument?  If so, HP take note, we had to make a lot of changes in our
> Symbolics  generated code to make it port to CL on the HPAIWS. If not,
> then why not?

No, they aren't.  We looked very carefully in Steele for an indication that
they were allowed, but they aren't.  It quite clearly states on most
of these functions that "The argument must be a package."  A name of a
package is not a package.  The problem with being "nice" by stretching what
the standard says is exactly the problem you have.  If, as I believe from
my reading of Steele, package names are not allowed, then Symbolics is
violating the standard, and thus lulling people into writing non-portable
code (as you did).  We opted for a strict interpretation, because code
developed on our machines will have a much better chance of being portable.
Besides, if standard doesn't say what people want it to say, then it should
be changed -- that doesn't mean language developers should ignore the
standard because they don't like it.

By the way, I don't know of any reason why the package functions couldn't 
take a name as well (except that for package-name, it wouldn't make much
sense).

	John Diamant

∂16-Apr-87  2012	DON%atc.bendix.com@RELAY.CS.NET 	Bignums are bogus?    
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 16 Apr 87  20:11:59 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac19928; 16 Apr 87 23:07 EDT
Received: from atc.bendix.com by RELAY.CS.NET id ab18198; 16 Apr 87 23:04 AST
Date: Thu, 16 Apr 87 15:33 EDT
From: DON%atc.bendix.com@RELAY.CS.NET
Subject: Bignums are bogus?
To: common-lisp@SAIL.STANFORD.EDU
X-VMS-To: IN%"common-lisp@sail.stanford.edu"

>From:	IN%"Rob MacLachlan <RAM@c.cs.cmu.edu>" 16-APR-1987 12:52
>To:	Sandra J Loosemore <sandra%orion@λcs.utah.edu>
>Subj:	bignums are bogus

>I'm not a big bignum user, but I think it might be marginally
>reasonable to support fixed-size 64 bit bignums.  I suspect that 64
>bit bignums would take care of a large percentage of uses.  This would
>also keep get-universal-time happy for a while to come.

I use bignums for set representations.  I think 64 bits is far too
small.  I agree that something over a thousand would almost always
suffice.

Don Mitchell

∂16-Apr-87  2137	fateman@mike.Berkeley.EDU 	Re:  Bignums are bogus?
Received: from UCBVAX.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87  21:37:42 PDT
Received: by ucbvax.Berkeley.EDU (5.57/1.23)
	id AA23502; Thu, 16 Apr 87 20:40:18 PST
Received: by mike (3.2/5.17)
	id AA14026; Thu, 16 Apr 87 21:38:08 PDT
Date: Thu, 16 Apr 87 21:38:08 PDT
From: fateman@mike.Berkeley.EDU (Richard Fateman)
Message-Id: <8704170438.AA14026@mike>
To: common-lisp@sail.stanford.edu
Subject: Re:  Bignums are bogus?

The point about bignums is that you don't have to check for them
overflowing, because they don't.  Something more dreadful happens first.
That's why 64bit or 1kbit bignums are no good.
If you want 64 bit numbers or so, I suggest you use floating point.
In fact, a CL-subset with only floating point might be useful,
especially if exact-integer floats were printed like integers.

∂17-Apr-87  0723	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re: CLARIFICATION: [italics]package arguments. 
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 17 Apr 87  07:23:20 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72880; Fri 17-Apr-87 10:22:20 EDT
Date: Fri, 17 Apr 87 10:18 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: CLARIFICATION: [italics]package arguments.
To: diamant%hpfclp@hplabs.HP.COM
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8704162320.AA08469@hpfclp.HP.COM>
Message-ID: <870417101821.7.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Thu, 16 Apr 87 16:20:21 mst
    From: John Diamant <diamant%hpfclp@hplabs.HP.COM>

							If, as I believe from
    my reading of Steele, package names are not allowed, then Symbolics is
    violating the standard, 

Would you please show us where in CLtL it says that accepting package
names is forbidden, and required to signal an error?

			    and thus lulling people into writing non-portable
    code (as you did).  We opted for a strict interpretation, because code
    developed on our machines will have a much better chance of being portable.

That's a very different question from "violating the standard".
Supersets of the standard are explicitly allowed; the word "Common" in
the name of "Common Lisp" is derived from the phrase "common subset".
Any implementation can make tradeoffs between providing extended
functionality, or providing only what's required by CLtL and nothing
more, in any area, depending on which criteria are more important in
that case.  Or they can provide a "mode" in which extensions are
disabled as much as possible, to help users assure portability of "pure
CL" code.  Conformity with the standard only means that an implementing
will correctly run correct CL programs.

∂17-Apr-87  0731	FAHLMAN@C.CS.CMU.EDU 	time to reactivate cl-cleanup    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87  07:31:33 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 17 Apr 87 10:32:28-EDT
Date: Fri, 17 Apr 1987  10:32 EDT
Message-ID: <FAHLMAN.12295236704.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Masinter.pa@XEROX.COM
Cc:   cl-cleanup@SAIL.STANFORD.EDU
Subject: time to reactivate cl-cleanup
In-reply-to: Msg of 7 Apr 1987  17:54-EDT from Masinter.pa at Xerox.COM


Larry,

I've finally got a free day to work on some of this stuff.  Looking over
my records, it seems I have your summary/current-status messages for the
first seven issues on your list: Adjust-Array-Displacement through
Flet-Implicit-Block.  Did you send out the others?  If so, please send
me new copies -- I somehow seem to have lost them in my mail-shuffling.

Let me volunteer to take a crack at five of those seven issues for which
I have the material.  Defvar-Initialization seems to be in final form,
and I don't feel good about doing Compiler-Warning-Break, since it is
KMP's baby and I think I'm mildly opposed to it.  I'll try
Flet-Implicit-Block, Environment-Arguments, Do-Symbols-Duplicates,
Adjust-Array-Displacement (may delegate this one internally), and
Compiler-Warning-Stream.  A couple of those are trivial; a couple are
fairly hairy.

If I get the materials in time, and if RPG doesn't indicate that he's
working on it, I'll take a crack at Function-Type; then RPG can make a
final pass over what I've done.  Also, I want to produce a new proposal
on &more, just so it will be on the table.  (May or may not be able to
get to that one before my trip.)

-- Scott

∂17-Apr-87  0959	RWK@YUKON.SCRC.Symbolics.COM 	SETF and pathname slots  
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 17 Apr 87  09:58:58 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 195190; Fri 17-Apr-87 12:58:53 EDT
Date: Fri, 17 Apr 87 12:58 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: SETF and pathname slots
To: ghenis.pasa@Xerox.COM
cc: common-lisp@sail.stanford.edu
In-Reply-To: <870416-170308-1688@Xerox>
Message-ID: <870417125836.3.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

    Date: 16 Apr 87 17:01 PDT
    From: ghenis.pasa@Xerox.COM

    Should the standard require SETF to handle pathname slots? If we are
    going to have MAKE-PATHNAME, PATHNAME-DEVICE, etc, for consistency we
    should also have COPY-PATHNAME and be able to do things like (SETF
    (PATHNAME-TYPE old-path) "OLD"). Is there any reason not to?

Careful.  Not all systems have pathnames which can be modified.
In our case, it's because we want to preserve EQness of pathnames
with the same components.  In other (hypothetical) cases, a pathname
may be an operating-system-related object that you aren't allowed
to directly modify; you request a new one.

The answer is to treat (SETF (PATHNAME-NAME PATH) NEW-NAME)
like (SETF PATH (MAKE-PATHNAME :NAME NEW-NAME :DEFAULTS PATH)).
This is analogous with SETF of LDB.

∂17-Apr-87  1115	diamant%hpfclp@hplabs.HP.COM 	Re: CLARIFICATION: [italics]package arguments.    
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 17 Apr 87  11:15:13 PDT
Received: from hpfclp.HP.COM by hplabs.HP.COM with TCP ; Fri, 17 Apr 87 10:15:57 pst
Received: from hpfcjrd.HP.COM by hpfclp.HP.COM; Fri, 17 Apr 87 12:14:56 mst
Received: by hpfcjrd.HP.COM; Fri, 17 Apr 87 11:16:15 mst
Date: Fri, 17 Apr 87 11:16:15 mst
From: John Diamant <diamant%hpfclp@hplabs.HP.COM>
Return-Path: <diamant@hpfcjrd>
Message-Id: <8704171816.AA06364@hpfcjrd.HP.COM>
To: dlw@alderaan.scrc.symbolics.com
Subject: Re: CLARIFICATION: [italics]package arguments.
Cc: common-lisp@sail.stanford.edu

> Would you please show us where in CLtL it says that accepting package
> names is forbidden, and required to signal an error?

"Must" means "must."  This means that it "is an error" to do  otherwise.
Whether it signals an error or attempts to interpret what the user meant
is at the  discretion  of the  implementation.  That means, at the least
that the  program  was not a correct CL  program.  However,  the  second
point applies here (see below).

> Or they can provide a "mode" in which extensions are
> disabled as much as possible, to help users assure portability of "pure
> CL" code.  Conformity with the standard only means that an implementing
> will correctly run correct CL programs.

O.K.  I stand corrected.  It is not a violation of the standard  per-say
to  provide  such an  extension.  However,  to do so without a mode like
what  you  describe  or a  flag  that  provides  warning  messages  when
extensions  are used is doing a grave  disservice  to the user.  This is
really  the same  issue as the list of  exported  symbols  from the LISP
package.  Nowhere  in CLtL  does it say  that  extra  symbols  can't  be
exported,  but you make  portable  code  virtually  impossible  to write
unless you require that.  I believe the same is true for any  extension.
It must be  clearly  delineated  either by being in a  separate  package
(possibly  shadowing the symbol in the LISP  package) or it must provide
some kind of feedback  that the operation  just  performed is not Common
Lisp.  That  CLtL  does  not  discuss  issues  like  this  is, I  think,
extremely unfortunate.

	John Diamant

∂17-Apr-87  1122	Masinter.pa@Xerox.COM 	Re: time to reactivate cl-cleanup    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Apr 87  11:22:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 APR 87 11:23:53 PDT
Date: 17 Apr 87 11:28 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: time to reactivate cl-cleanup
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Fri,
 17 Apr 87 10:32 EDT
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870417-112353-2553@Xerox>

I was waiting until I got some volunteers for the first seven before
sending out any more. 

I'll mail out FUNCTION-TYPE today and the rest soon, but I'd like to
make sure that we get the ones on the table handled.

What do you think about flying &more (whatever it is) by the general
common-lisp mailing list before bringing it to this committee?

∂17-Apr-87  1145	FAHLMAN@C.CS.CMU.EDU 	time to reactivate cl-cleanup    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87  11:45:00 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 17 Apr 87 14:45:56-EDT
Date: Fri, 17 Apr 1987  14:45 EDT
Message-ID: <FAHLMAN.12295282839.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Masinter.pa@XEROX.COM
Cc:   cl-cleanup@SAIL.STANFORD.EDU
Subject: time to reactivate cl-cleanup
In-reply-to: Msg of 17 Apr 1987  14:28-EDT from Masinter.pa at Xerox.COM


    What do you think about flying &more (whatever it is) by the general
    common-lisp mailing list before bringing it to this committee?

Well, I'd like to get the opinions of people I respect on this before
going public.  You've seen all this flamage about bignum limit.  I
think that Common Lisp is even worse than it used to be as a medium for
rational discussion among informed people, so my inclination is to use
it only as a final sanity check: announce what we propose to do, and
then listen quietly for any really coherent objections, without trying
to answer the lunatics.  But that implies that anything we toss out
there ought to be as well-debugged as we can make it in advance.

-- Scott

∂17-Apr-87  1200	Moon@ALDERAAN.SCRC.Symbolics.COM 	Language extensions (formerly [italics]package arguments.)   
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 17 Apr 87  12:00:27 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 73021; Fri 17-Apr-87 14:59:12 EDT
Date: Fri, 17 Apr 87 14:58 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Language extensions (formerly [italics]package arguments.)
To: John Diamant <diamant%hpfclp@hplabs.HP.COM>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8704171816.AA06364@hpfcjrd.HP.COM>
Message-ID: <870417145849.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 17 Apr 87 11:16:15 mst
    From: John Diamant <diamant%hpfclp@hplabs.HP.COM>

    > Or they can provide a "mode" in which extensions are
    > disabled as much as possible, to help users assure portability of "pure
    > CL" code.  Conformity with the standard only means that an implementing
    > will correctly run correct CL programs.

    O.K.  I stand corrected.  It is not a violation of the standard  per-say
    to  provide  such an  extension.  However,  to do so without a mode like
    what  you  describe  or a  flag  that  provides  warning  messages  when
    extensions  are used is doing a grave  disservice  to the user.  This is
    really  the same  issue as the list of  exported  symbols  from the LISP
    package.  Nowhere  in CLtL  does it say  that  extra  symbols  can't  be
    exported,  but you make  portable  code  virtually  impossible  to write
    unless you require that.  I believe the same is true for any  extension.
    It must be  clearly  delineated  either by being in a  separate  package
    (possibly  shadowing the symbol in the LISP  package) or it must provide
    some kind of feedback  that the operation  just  performed is not Common
    Lisp.  That  CLtL  does  not  discuss  issues  like  this  is, I  think,
    extremely unfortunate.

It does discuss this, on pages 1 through 3.  (It discusses just the
philosophy and doesn't get down to specific cases.)  I think that providing
tools to ease writing of portable code is a fine idea, and vendors should
do so.  I violently disagree with the idea that any implementation that
does not come with a 100% perfect set of such tools is not Common Lisp.

Note that CLtL pp.1-3 says that Common Lisp is a common dialect to which
each implementation makes any necessary extensions, and that Common Lisp
is designed to make it easy to write programs that depend as little as
possible on machine-specific characteristics, but does not say that
Common Lisp's purpose is to support writing of only programs that are
100% painlessly portable.  Common Lisp would be a lot less interesting,
and a lot less widespread, if that were so.

∂17-Apr-87  1329	FAHLMAN@C.CS.CMU.EDU 	Issue: FLET-IMPLICIT-BLOCK (Revision 4)    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87  13:28:15 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 17 Apr 87 16:29:12-EDT
Date: Fri, 17 Apr 1987  16:29 EDT
Message-ID: <FAHLMAN.12295301642.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: FLET-IMPLICIT-BLOCK (Revision 4)


Status: New draft, incorporating results of CL-Cleanup discussion.  Two
issues are listed at the end that we must resolve.

Issue: FLET-IMPLICIT-BLOCK
Reference: CLtL p. 113, 67
Edit history:   Revision 2 by cleanup committee 15-Mar-87 15:13:33
		Revision 3 by Masinter (reformatting) 7-Apr-87 17:49:12 
		Revision 4 by SEF 11-April-87

Description:

Do Flet, Labels, and Macrolet have an implicit block around their bodies
like the body of a Defun?  CLtL is silent on this point.  Many users
and some implementors assume that such blocks should be established,
since they view these forms as analogous with Defun.

Test case:

(defun test ()
  (flet ((test (x) (if x (return-from test 4) 3)))
	(list (test nil) (test t))))

(test)

will return (3 4) if FLET-IMPLICIT-BLOCK:YES is adopted, and would return 4
in an implementation that did not add an implicit block around Flet.

Category: Ommission. 
Proposal: FLET-IMPLICIT-BLOCK:YES

Each function created by Flet and Labels and each macro created by
Macrolet has an implicit block around the body.  The name of this block
is that same as the (lexical) name of the function or macro.

Current Practice:

Current practice is mixed.  Several implementations do not add the
implicit block, others do.

Cost of adopting this change:
Some implementations will have to be modified.  This should be a
relatively easy modification.

Cost of not adopting the change:
If the issue is not clarified one way or another, continuing confusion
will result in portability problems.  Clarifying the issue in any other
way would also require modifications in some implementations.

Cost of converting existing code:
It is possible that some user code would break because it does a return
from within lexical function or macro to an outer block that has the same
name.  Such problems will be rare, and the code in question would not
run on all current Common Lisp systems because of the diverse
interpretations currently in effect.  It would be possible to detect all
such instances automatically, though it seems unlikely that anyone will
need to use this technique.

Discussion:

The goal is first to clean up an ambiguous situation and, second, to
do this in a way that provides consistent behavior between local and
global definitions.

There are two coherent alternatives to the proposal above:

The first would be to keep the implicit block in Defun, and to clearly
state that the lexical forms do not create implicit blocks.  This
violates the goal of consistency between lexical and global definitions,
and it seems to conflict with users' expectations.

The second alternative is to eliminate the implicit block from Defun
rather than adding such blocks to other forms.  There is some feeling
that specifying the implicit block in Defun was a poor design decision
in the first place, since it hides a reference to the name of a function
within the code of the function itself.  If a user decides to rename
some function, he must be careful to rename any return-from forms within
the body of the function as well.

On the other hand, eliminating the implicit block in Defun would be a
significant incompatible change.  Some users find this implicit block to
be a great convenience for popping out of convoluted code, and some
existing code makes heavy use of this feature.  Such code could be
repaired automatically by searching for situations in which the user
returns from a function by name and by adding an appropriate explicit
block to any function containing such a forms, but it would still
require more more work on existing user code than the proposal made
above.

There was considerable discussion in the cleanup committee about whether
these implicit blocks would interfere with tail-recursion optimization,
which we hope will become more common (perhaps even required) in future
Common Lisp implementations.  The outcome of these discussions was
general agreement that a compiler could easily eliminate the implicit
block in any case where it is not actually used, and that the impact on
tail-recursion optimization in compiled code is therefore minimal.

Issue: Does the manual say anywhere that Defmacro has such an implicit
block?  I couldn't find this.  Obviously we must add this if we are
proposing to add an implicit block to Macrolet for reasons of
consistency.

Issue: Do we want to add implicit blocks to Defsetf, Define-Setf-Method,
and Deftype as well?  This would provide a certain consistency: any form
that creates a named entity with a user-supplied body would establish a
block.

SEF is inclined to vote yes on both these issues, and on the proposal as
a whole.

∂17-Apr-87  1408	FAHLMAN@C.CS.CMU.EDU 	Issue: FLET-IMPLICIT-BLOCK (Revision 5)    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87  14:08:33 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 17 Apr 87 17:09:27-EDT
Date: Fri, 17 Apr 1987  17:09 EDT
Message-ID: <FAHLMAN.12295308952.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: FLET-IMPLICIT-BLOCK (Revision 5)


Status: New draft, incorporating results of CL-Cleanup discussion.

[ At Masinter's suggestion, this version assumes we agree to add the
blocks to Defmacro, Defsetf, Define-Setf-Method, and Deftype. ]

Issue: FLET-IMPLICIT-BLOCK
Reference: CLtL p. 113, 67
Edit history:   Revision 2 by cleanup committee 15-Mar-87 15:13:33
		Revision 3 by Masinter (reformatting) 7-Apr-87 17:49:12 
		Revision 4 by SEF 11-Apr-87
		Revision 5 by SEF 11-Apr-87

Description:

Do Flet, Labels, Defmacro, Macrolet, Defsetf, Define-Setf-Method, and
Deftype have an implicit block around their bodies like the body of a
Defun?  CLtL is silent on this point.  Many users and some implementors
assume that such blocks should be established, since they view these
forms as analogous with Defun.

Test case:

(defun test ()
  (flet ((test (x) (if x (return-from test 4) 3)))
	(list (test nil) (test t))))

(test)

will return (3 4) if FLET-IMPLICIT-BLOCK:YES is adopted, and would return 4
in an implementation that did not add an implicit block around Flet.

Category: Ommission. 
Proposal: FLET-IMPLICIT-BLOCK:YES

Each function created by Flet and Labels and each macro created by
Defmacro and Macrolet has an implicit block around the body.  The name
of this block is that same as the (lexical) name of the function or
macro.  Similarly, the body code in Defsetf, Define-Setf-Method, and
Deftype is surrounded by a block with the same name as the accessor
or type.

Current Practice:

Current practice is mixed.  Several implementations do not add the
implicit block, others do, some add some of these blocks and not others.

Cost of adopting this change:
Some implementations will have to be modified.  This should be a
relatively easy modification.

Cost of not adopting the change:
If the issue is not clarified one way or another, continuing confusion
will result in portability problems.  Clarifying the issue in any other
way would also require modifications in some implementations.

Cost of converting existing code:
It is possible that some user code would break because it does a return
from within a code body to an outer block that has the same as the
newly-required block.  Such problems will be rare, and the code in
question would not run on all current Common Lisp systems because of the
diverse interpretations currently in effect.  It would be possible to
detect all such instances automatically, though it seems unlikely that
anyone will need to use this technique.

Discussion:

The goal is first to clean up an ambiguous situation and, second, to do
this in a way that provides consistent behavior between local and global
definitions.  The proposed change would allow a simple rule of thumb:
any named entity that takes a code body establishes an implicit block
with the obvious name.

There are two coherent alternatives to the proposal above:

The first would be to keep the implicit block in Defun, and to clearly
state that the other forms do not create implicit blocks.  This
violates the goal of consistency between lexical and global definitions,
and it seems to conflict with users' expectations.

The second alternative is to eliminate the implicit block from Defun
rather than adding such blocks to other forms.  There is some feeling
that specifying the implicit block in Defun was a poor design decision
in the first place, since it hides a reference to the name of a function
within the code of the function itself.  If a user decides to rename
some function, he must be careful to rename any return-from forms within
the body of the function as well.

On the other hand, eliminating the implicit block in Defun would be a
significant incompatible change.  Some users find this implicit block to
be a great convenience for popping out of convoluted code, and some
existing code makes heavy use of this feature.  Such code could be
repaired automatically by searching for situations in which the user
returns from a function by name and by adding an appropriate explicit
block to any function containing such a forms, but it would still
require more more work on existing user code than the proposal made
above.

There was considerable discussion in the cleanup committee about whether
these implicit blocks would interfere with tail-recursion optimization,
which we hope will become more common (perhaps even required) in future
Common Lisp implementations.  The outcome of these discussions was
general agreement that a compiler could easily eliminate the implicit
block in any case where it is not actually used, and that the impact on
tail-recursion optimization in compiled code is therefore minimal.

∂17-Apr-87  1525	Masinter.pa@Xerox.COM 	Issue: FUNCTION-TYPE (version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Apr 87  15:25:17 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 APR 87 15:26:18 PDT
Date: 17 Apr 87 15:31 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE (version 2)
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870417-152618-2924@Xerox>

Status:  General agreement on basic proposal.
	Wording to be worked out.
	Fahlman volunteer to revise & run by RPG first

Issue:     FUNCTION-TYPE
References:   functions (pg 32), types (pg 33), FUNCTIONP (pg 76),
	      APPLY (pg 107).
Category:     CHANGE/CLARIFICATION
Edit History: Version 1 by RPG 02/26/87
			Version 2 by cleanup committee 15-Mar-87 15:37:21

Problem Description:

The definition of the term `function' in CLtL includes all symbols and
many lists in addition to true functions. The type named `FUNCTION' is,
therefore, not a reasonable type. The language would be much cleaned up
and improved if functions were treated as a type in a consistent and
useful manner. Most of the reason for the current state of affairs is
the desire for compatibility with the past.

Proposal:

1. Currently the FUNCTION type specifier can only be used for
declaration and not for discrimination. This proposal makes FUNCTION a
full-fledged type. Symbols, whether or not fboundp, and lambda
expressions do not qualify as functions. Specifically the types CONS,
SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION are pairwise disjoint.

Under this proposal, a lambda expression is not of type FUNCTION. A list
may not be used to implement any FUNCTION subtype.

Implementations may add sub-types of FUNCTION, for example,
COMPILED-FUNCTION, INTERPRETED-FUNCTION, COMPILED-CLOSURE etc.

2. This proposal changes the behavior of the FUNCTIONP function such
that it is equivalent to #'(LAMBDA (X) (TYPEP X 'FUNCTION)). In
particular, lists whose cars are LAMBDA, and symbols are no longer
FUNCTIONP.

3. The descriptions of FUNCALL, APPLY, MAPCAR and all functions in CLtL
which take functional arguments are modified to clarify that they will
take either functions, symbols, or lists that represent
lambda-expressions; if given non-functions, they coerce their functional
argument to a function first. Their behavior is not changed.  

4. It is an error to use the special form FUNCTION around symbols that
denote macros or special forms. (Some implementations may not signal
this error for performance reasons.) In all non-error situations, the
result of evaluating a FUNCTION special form is required to be of type
FUNCTION.  

5. It is an error to invoke SYMBOL-FUNCTION on 

Page 76, the description of FUNCTIONP should be amended to read:

``FUNCTIONP is true if its argument is a function (see page 32).''

Page 107, the second sentence should be amended to read:

``*Function* must be a function (see page 32).''

Page 107, the first and fourth examples should be amended to read:

(setq f #'+) (apply f '(1 2)) => 3

(apply #'cons '((+ 2 3) 4)) =>
       ((+ 2 3) . 4)  *not* (5 . 4)

Other examples might require amendment.

Rationale:

I believe that this change takes a currently meaningless concept in
Common
Lisp (a function) and gives it a firmer foundation. Many programmers
cannot rely on FUNCTIONP filtering out true functions from mere symbols.

Current Practice:

Programmers write their own predicate for true FUNCTIONP.

Adoption Cost:

Compiled functions are true functions in almost all implementations,
but,
in some implementations, interpreted functions are represented as lists.
This would need to be changed in the interpreter, FUNCALL, APPLY, and
other places.

Benefits:

A concept would be resurrected:  currently the concept of a function in
Common Lisp is bankrupt.  Common Lisp would come in closer alignment
with
Scheme. It is the first step towards a Lisp1-ification of Common Lisp.

Conversion Cost:

Unknown. Deep-rooted bugs could be uncovered.

Aesthetics:

Making the concept of a function well-defined will probably be perceived
as a simplification.

Discussion:

The committee felt a need for a new function which replaces the old
behavior of FUNCTIONP, which tests whether the argument is a function
object, a symbol which is FBOUNDP with a function object in its
symbol-function, or a list whose CAR is LAMBDA or some other valid
implementation-specific s-expression representation of a function. 

What does COMPILE do? Can one COMPILE already compiled things.

Does (SETF (SYMBOL-FUNCTION x) '(LAMBDA ...)) coerce the lambda
expression?
Is it an error?

SYMBOL-FUNCTION of a special form "is an error".

∂17-Apr-87  1536	Masinter.pa@Xerox.COM 	Issue FORMAT-ATSIGN-COLON (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Apr 87  15:35:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 APR 87 15:36:58 PDT
Date: 17 Apr 87 15:40 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue FORMAT-ATSIGN-COLON (Version 3)
To: cl-cleanup@sail.stanford.edu
Message-ID: <870417-153658-2933@Xerox>

This is the final form of the proposal as distributed at the last X3J13
meeting. No additional work is needed.

Issue:        FORMAT-ATSIGN-COLON
References:   FORMAT description (p386)
Category:     CLARIFICATION
Edit history: Revision 1 by KMP 02/27/87
              Revision 2 by cleanup committee 15-Mar-87 14:50:50
              Revision 3 by Masinter 15-Mar-87 18:37:23

Problem Description:

CLtL describes the format op syntax as:

"a format directive consists of a tilde (~), optional prefix parameters
separated by commas, optional colon (:) and atsign (@) modifiers, and a
single character indicating what kind of directive this is."

CLtL uses :@ fairly consistently throughout without saying whether @: is
legal. Is @: allowed?

Proposal (FORMAT-ATSIGN-COLON:OK):

There is no required ordering between the @ and : modifier.

Rationale:

This is currently underspecified, and this way of specifying it will
cause the least disruption to user code.

Current practice:

Most implementations accept these in either order. Some implementations
have been known to expect only :@.

Adoption Cost:

The change to accept either syntax is probably quite trivial.

Benefits:

Having @: and :@ mean different things would be awkward. 

Conversion Cost:

Existing user code would be unaffected.

Aesthetics:

Leaving these unordered is slightly simpler conceptually.

Discussion:

The cleanup committee supports this clarification.

∂17-Apr-87  1608	vrotney@vaxa.isi.edu 	Re: CLARIFICATION: [italics]package arguments.  
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87  16:08:53 PDT
Received: from hpai00 (hpai00.isi.edu) by vaxa.isi.edu (4.12/4.7)
	id AA16667; Fri, 17 Apr 87 15:10:06 pst
Received: by hpai00 ; Fri, 17 Apr 87 16:08:56 pdt
From: vrotney@vaxa.isi.edu
Message-Id: <8704172308.AA02892@hpai00>
Date: Fri, 17 Apr 87  15:08:45 PDT
Subject: Re: CLARIFICATION: [italics]package arguments.
To: common-lisp@sail.stanford.edu
In-Reply-To: Your message of 17-Apr-87  10:18:00
X-Mailer: NMail [$Revision: 2.6 $]

In the spirit of making CLTL a slightly  better   specification,  what
about the following extension?

On page 182, extend the statement

	"Any argument described as a package name may be either
	 a string or a symbol."

 to

	"Any argument described in this section as a package name
	 or package may be either a string or a symbol."

Bill Vrotney USC/ISI
-------

∂17-Apr-87  1633	Masinter.pa@Xerox.COM 	Issue IF-BODY (Version 3)  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Apr 87  16:32:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 APR 87 16:33:53 PDT
Date: 17 Apr 87 16:38 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue IF-BODY (Version 3)
To: cl-cleanup@sail.stanford.edu
Message-ID: <870417-163353-2990@Xerox>

Status: I (Masinter) tried to merge and summarize the arguments for and
against this proposal. However, I have made enough edits that I no
longer have a lot of confidence that it reflects the "will of the
committee".  If you would like to create the next draft, please let me
know.


Issue:        IF-BODY
References:   IF (p115)
Category:     ENHANCEMENT
Edit history: Revision 1 by KMP 02/27/87
		Version 2 (IF-BODY:NO) by SEF 3/3/87
		Revision 2 by Masinter 17-Apr-87

Problem Description:

IF only allows 2 or 3 arguments. This is restrictive, and not compatible
with current practice in some implementations. 

Test Case:
 
 (IF T NIL NIL NIL NIL NIL NIL T). 

Currently, this is an error.  In some implementations this returns T.

Proposal (IF-BODY:YES):

Extend IF to accept a body of else forms (to be treated as an implicit
PROGN), with syntax (IF test then {else}*).

Rationale:

This is an extension which exists in many implementations.

Current Practice:

Some implementations already provide this feature.  Others do not, and
signal an error. A few may provide alternate keyword-driven extensions
to IF that are incompatible with this extension.   
   
Adoption Cost:

Presumably most implementations would require minor adjustments to the
interpreter, the compiler, and any code walking tools. The estimated
cost is low. Implementations which provided an alternate keyword-driven
extension would have more serious difficulties.

Benefits:

This will diminish one common source of aggravation in applications that
took advantage of the extension provided by some implementations, as
they would not have to remove this implementation dependency.

Cost of not adopting this change:

Users with code which had multiple else expressions would have to find
them and convert them to (if test then (PROGN else)) or an equivalent
construct, or else construct a new compatibility package which shadowed
IF. (Implementations which currently provide an extension could continue
to do so, although programs that used it would not be valid Common
Lisp.)

Conversion Cost:

Most code which simply uses IF would not be affected adversely except in
implementations which provided keyword-driven extensions.

Some user-defined code might depend on understanding the syntax of IF
because it is defined to be a primitive special form. Such programs
would require modification, although those modifications are likely to
be simple. 

Aesthetics:

Some people like the IF body idea and find it more visually aesthetic
than the more-parenthesized (and incidentally also more-indented) COND
alternative.

Some people really dislike the idea of an IF body: it would destroy the
symmetry of the THEN and ELSE clauses in an IF expression, and would
lead to a visually confusing format. 

This proposal leaves that choice to the individual programmer.

Discussion:

Much of the discussion around this proposal centered on the form of the
arguments rather than on the proposal itself. The issue of whether the
fact that some implementations had chosen to extend IF should influence
the future of Common Lisp was debated. 


Pitman: "this is a source of frustration for users, only a small
fraction of
  which care about arguing about whether more than three arguments is
aesthetic.
  They just want their programs to port without hassle. CLtL has egged
on the
  problem by explicitly suggesting that such extensions were
permissible."

Fahlman: "Whatever we decide about the merits of this proposal itself, I
want to
    VEHEMENTLY OBJECT to the rationale put forward in this proposal....
it
    is an extremely bad precedent . . .

    This same argument could be used to slip any number of unspeakable
    horrors into the language...."

Moon: "the mere fact that some people like this extension is not
sufficient reason to put it into the language, but it is certainly
sufficient reason to -discuss- putting it into the language." 

Steele: " I agree with Scott's assessment of the IF-BODY proposal
(though I think
the proposal was worth making). I would point out that one of the
reasons for including IF in the language is to have a simple primitive
that can easily be recognized, by people and by program-walkers alike,
as being the simplest conditional and not having implicit PROGNs as do
WHEN, UNLESS, and COND."

Summary: Most of the cleanup committee are mildly opposed to adopting
this proposal. We agree that we should consider, but not be held hostage
to, extensions made by some implementations and demanded by their users.


∂17-Apr-87  1634	Masinter.pa@Xerox.COM 	status.report    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Apr 87  16:33:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 APR 87 16:34:50 PDT
Date: 17 Apr 87 16:39 PDT
From: Masinter.pa@Xerox.COM
Subject: status.report
to: cl-cleanup@sail.stanford.edu
Message-ID: <870417-163450-2991@Xerox>

Status of proposals before CL-CLEANUP committee

Date:   17-Apr-87

ADJUST-ARRAY-DISPLACEMENT (revision 1)
	Received but not discussed.
	Need volunteer to lead discussion, summarize positions.
	remailed 7-apr-87
	SEF volunteered to delegate.

COMPILER-WARNING-BREAK (revision 2)
	not Released.
	Questions on interaction with condition proposal.
	Defer to error/signal/condition committee? 
	remailed 7-apr-87
	SEF suggested KMP should work on.

COMPILER-WARNING-STREAM (Revision 3)
	Released
	Comment from Dussand at TI, forwarded to cl-cleanup, no response.
	remailed 7-apr-87
	SEF volunteered to work on.

DEFVAR-INITIALIZATION (Revision 3)
	Released
	remailed 7-apr-87
	(final form)

DO-SYMBOLS-DUPLICATES (Revision 1)
	Received but not discussed
	Need volunteer to put in standard format
	mailed 7-apr-87
	SEF volunteered to work on

ENVIRONMENT-ARGUMENTS (revision 1)
	Need volunteer to work over the proposal further.
	Mailed 7-apr-87
	SEF volunteered to work on

FLET-IMPLICIT-BLOCK (Revision 5)
	Discussion & agreement on cl-cleanup.
	revision by Fahlman, 17-Apr-87 to cl-cleanup
	
FORMAT-ATSIGN-COLON (Revision 3)
	Released.
	(final form, mailed 17-Apr-87)

FORMAT-OP-C (revision 1)
	Discussed and agreed, final form not yet available
	(with Moon's amendment)
	Need volunteer.

FUNCTION-TYPE (revision 2)
	General agreement on basic proposal.
	Wording to be worked out.
	Mailed 17-Apr-87
	Fahlman volunteered to revise & run by RPG

IF-BODY (Version 3)
	General agreement to recommend against.
	Final form not yet available.
	Version 3 mailed by Masinter , 17-Apr-87


IGNORE-ERRORS
	Discussed and agreed, final form not yet available
	(LMM: Some objections, defer to error/signal committee?)
	Need volunteer.

IMPORT-SETF-SYMBOL-PACKAGE (Revision 3)
	Released
	Should remove confusing "To further clarify: " which is
	about INTERN and not IMPORT.

PEEK-CHAR-READ-CHAR-ECHO
	Agreed to be controversial
	Need volunteer to summarize positions.


PRINC-CHARACTER:WRITE-CHAR
	Discussed and agreed, final form not yet available
	(write-char choice)
	Need volunteer.

PROMPT-FOR
	Agreed to be controversial
	Need volunteer to summarize positions.

REMF-DESTURCTION-UNSPECIFIED
	Not discussed
	Need volunteer to check over, lead discussion.

SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
	(Should FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
	Tabled, a subset which deals with only those functions that
	don't work in positions will be separated out.
	Need volunteer.

SHARPSIGN-BACKSLASH-BITS
	No general agreement (the meeting notes read "we cringed")
	Need volunteer to summarize positions.

SHARPSIGN-PLUS-MINUS-NUMBER
	Discussed, without general agreement.
	Need volunteer to summarize positions.

SHARPSIGN-PLUS-MINUS-PACKAGE
	Discussed, without general agremenet.
	Need volunteer to summarize positions.

TAILP-NIL
	Received but not discussed
	Need volunteer to lead discussion, summarize positions.

UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
	Discussed and agreed, final form not yet available
	 (choice  1c & 2c)
	Need volunteer.


∂17-Apr-87  1737	FAHLMAN@C.CS.CMU.EDU 	Issue: COMPILER-WARNING-STREAM (Revision 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87  17:37:14 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 17 Apr 87 20:38:15-EDT
Date: Fri, 17 Apr 1987  20:38 EDT
Message-ID: <FAHLMAN.12295346987.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: COMPILER-WARNING-STREAM (Revision 4)


Status: Released.  This version slightly revised to incorporate Dussud's
comment about the effect of this change on Dribble and to clean up some
awkward wording.

Issue:        COMPILER-WARNING-STREAM
References:   COMPILE (p438), COMPILE-FILE (p439)
Category:     CLARIFICATION/CHANGE
Edit history: Revision 1 by KMP 02/27/87
              Revision 2 at committee meeting 15-Mar-87 14:18:56
              Revision 3 reformat by Masinter 15-Mar-87 17:42:10
	      Revision 4, minor revision by SEF 15-Apr-87

Problem Description:

The description of the COMPILE and COMPILE-FILE functions does not
explicitly permit them to print warnings.  If this is to be allowed, it
should be specified what stream such warnings are printed on.

Proposal (COMPILER-WARNING-STREAM:ERROR-OUTPUT)

COMPILE and COMPILE-FILE are permitted to output warnings; warnings
should go to the stream that is the value of *ERROR-OUTPUT*.

As a corollary of this, DRIBBLE is required to record from
*ERROR-OUTPUT* as well as *STANDARD-INPUT* and *STANDARD-OUTPUT* so that
it can record any compiler warnings that may be generated while it is in
effect.

Rationale:

Compiler warning output is a widely accepted feature of compilation.
Warnings that come via the WARN function will go to the stream that is
the value of *ERROR-OUTPUT*.

Current Practice:

Some implementations send compiler warning output to *ERROR-OUTPUT*.
Other implementations send it to *STANDARD-OUTPUT*.

Adoption Cost:

In most cases, the change to the compiler to redirect output is expected
to be very slight.

Benefits:

Currently, it is difficult to redirect the output of COMPILE and
COMPILE-FILE because it isn't clear what stream receives the warnings.

Conversion Cost:

Most user programs that care are probably already tolerant of both
situations or naively expect that output will go to *ERROR-OUTPUT*. As
such, most users will probably perceive this as a clarification.

Aesthetics:

Most users will probably perceive this change as a simplification
because it will allow the kind of warning that comes from WARN and the
kind of warning that comes from compilation to be conceptually grouped.

Discussion:

This was a problem in adapting MACSYMA to Common Lisp because Macsyma
provides alternate user interfaces to the compiler which it needs to be
able to control.

The cleanup committee supports this change.

∂17-Apr-87  2007	FAHLMAN@C.CS.CMU.EDU 	Issue: DO-SYMBOLS-DUPLICATES (Revision 1)  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87  20:07:39 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 17 Apr 87 23:08:34-EDT
Date: Fri, 17 Apr 1987  23:08 EDT
Message-ID: <FAHLMAN.12295374347.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: DO-SYMBOLS-DUPLICATES (Revision 1)


Status:  New Proposal (in the CL-Cleanup process, anyway)

Issue:        DO-SYMBOLS-DUPLICATES
References:   Do-Symbols, Page 187
Category:     Clarification
Edit history: Revision 1 by SEF 17-Apr-87

Problem Description:

CLtL specifies that Do-Symbols executes the body once for each symbol
accessible in the package.  It does not say whether it is permissible
for the body to be executed more than once for some accessible symbols.
The term "accessible" is defined on page 172 to include symbols
inherited from other packages (not including any symbols that may be
shadowed).  It is very expensive in some implementations to eliminate
duplications that occur because the same symbol is inherited from
multiple packages.

Proposal: DO-SYMBOLS-DUPLICATES:ALLOWED

Add to the specification of DO-SYMBOLS a note that it may execute the
body more than once for some symbols.

Rationale:

Most uses of DO-PACKAGE would not be harmed by the presence of
duplicates.  For these applications it is unreasonable to force users to
pay the high cost of filtering out the duplications.  Users who really
want the duplicates to be removed can add additional code to do this job.

Current Practice:

Many implementations have always produced duplicate values.

Adoption Cost:

None.  Implemenations would still be free to eliminate the duplications,
though code will not be assuming that this has been done.

Benefits:

Clarification of a situation that is currently ambiguous.

Conversion Cost:

Users who have been assuming that DO-SYMBOLS eliminates duplications
will have to be modified, but such code would run on few existing Common
Lisp systems.

Aesthetics:

It would be cleaner to present each symbol exactly once.  This is a
clear case of choosing efficiency over elegance.

Discussion:

This issue was discussed on the Common Lisp mailing list in 1985, and
the solution proposed here seems to have been informally agreed to at
the time -- there was no formal decision-making process in place then.

∂17-Apr-87  2109	vrotney@vaxa.isi.edu 	Sec.11.7 [italics]package arguments.  
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87  21:09:03 PDT
Received: from hpai00 (hpai00.isi.edu) by vaxa.isi.edu (4.12/4.7)
	id AA18659; Fri, 17 Apr 87 20:10:16 pst
Received: by hpai00 ; Fri, 17 Apr 87 21:09:05 pdt
From: vrotney@vaxa.isi.edu
Message-Id: <8704180409.AA02941@hpai00>
Date: Fri, 17 Apr 87  20:08:53 PDT
Subject: Sec.11.7 [italics]package arguments.
To: common-lisp@sail.stanford.edu
X-Mailer: NMail [$Revision: 2.6 $]

In the spirit of making CLTL a slightly  better   specification,  what
about the following extension?

On page 182, extend the statement

	"Any argument described as a package name may be either
	 a string or a symbol."

 to

	"Any argument described in this section as a package name
	 or package may be either a string or a symbol."

--------------------------------------------------------------------------------
Post Script:

After sending the above message I realized that someone may  interpret
it too  literally.   My original  message on this  indicated  that the
functions in Sec.11.7 created a  "misinterpretation  portability trap"
or what  ever you want to call it. The  above is a  suggestion  for an
extension  that  means  that all  arguments  in  this  section   named
[italics]package,  be allowed to be a string or symbol, as they can be
in some implementations.   I suppose the extended sentence above could
be worded better to help define what something described as a "package
name"   means. For example,

	"Any argument described in this section as a package name
	 may be either a string or symbol. Any argument designated
	 as [italics]package may be a package, string or symbol."

In other  words,  reqardless  of what most of us think CLTL says these
package  arguments can or can not be, a good future extension might be
to specify exactly that all of these package  arguments  (except for a
few) be allowed to be a package, string or symbol.


Bill Vrotney USC/ISI
-------

∂17-Apr-87  2121	edsel!bhopal!jonl@navajo.stanford.edu 	CLARIFICATION: [italics]package arguments.    
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87  21:21:09 PDT
Received: by navajo.stanford.edu; Fri, 17 Apr 87 20:20:45 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
	id AA01217; Fri, 17 Apr 87 20:18:48 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
	id AA00738; Fri, 17 Apr 87 21:16:27 PDT
Date: Fri, 17 Apr 87 21:16:27 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704180416.AA00738@bhopal.edsel.com>
To: navajo!vrotney%vaxa.isi.edu@navajo.stanford.edu
Cc: navajo!common-lisp%sail@navajo.stanford.edu
In-Reply-To: navajo!vrotney@vaxa.isi.edu's message of Fri, 17 Apr 87  15:08:45 PDT
Subject: CLARIFICATION: [italics]package arguments.

Somewhere between 1 year ago and 2 years ago, I sent out a proposal to this 
list suggesting that the package functions of CLtL section 11.7 fall into
four categories:
  (1) those whose argument is documented as "must be a package";
  (2) those whose argument is documented as "a package";
  (3) those whose argument is documented as a "name" of (or for) a package;
  (4) all the rest.
Contrary to what John Diamant suggested, I think that very few functions
fall into category (1).  The vast majority seem to be in category (2).

Both Symbolics and Lucid apparently, independently, made a decision to 
interpret the documentation of category (2) to mean that any argument 
reasonably coercible to a package would in fact be so coerced.  That is, 
if the documentation goes out of its way to say "must be a package" for 
some functions, but doesn't do so for others, then it must be that the 
latter ones can be more generous in accepting alternate forms.

This implies, for example, that a string or symbol could be supplied as 
the "pacakge" argument to UNINTERN; but the argument to PACKAGE-NICKNAMES
can only be of type package, because it "must be a packge".

There wasn't a lot of discussion back then about these points -- certainly
there was no serious objection to them.  Probably the HP folks weren't
receiving the mail then?

-- JonL --


∂17-Apr-87  2229	MURRAY%cs.umass.edu@RELAY.CS.NET 	OR and Multiple Values    
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 17 Apr 87  22:29:12 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ai22053; 18 Apr 87 1:22 EDT
Received: from cs.umass.edu by RELAY.CS.NET id ce03359; 18 Apr 87 1:17 AST
Date:     Fri, 17 Apr 87 18:27 EDT
From:     MURRAY%cs.umass.edu@RELAY.CS.NET
To:       common-lisp@SAIL.STANFORD.EDU
Subject:  OR and Multiple Values
X-VMS-To: CLMAIL


>    Is it reasonable to expect SOME to return multiple values?
>    What if the predicate returns multiple values?
>>No, for the same reason that OR returns only a single value for clauses
>>other than the last one.  That is, the implicit NULL test "consumes" the
>>values returned from the predicate, discarding all but the last one.

I've always been a little disturbed by this fact.  I suppose the 
extra effort to always insure multiple values are dealt with "properly"
is probably not worth it in general.  However, I'll take this opportuntiy
to again ask for a MULTIPLE-VALUE-OR special form, since it cannot be
defined without consing in Common-Lisp (I guess it COULD be a macro that
expands into consing code, but the compiler would know about, but that is
another discussion).

- Kelly 

∂17-Apr-87  2236	MURRAY%cs.umass.edu@RELAY.CS.NET 	Fixnums Bogus   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 17 Apr 87  22:36:24 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa22296; 18 Apr 87 1:33 EDT
Received: from cs.umass.edu by RELAY.CS.NET id cj03359; 18 Apr 87 1:28 AST
Date:     Fri, 17 Apr 87 19:51 EDT
From:     MURRAY%cs.umass.edu@RELAY.CS.NET
To:       common-lisp@SAIL.STANFORD.EDU
Subject:  Fixnums Bogus
X-VMS-To: CLMAIL


Just to throw my two cents in...

It is undeniably a loophole that bignums don't have some
minimum size, because fixnums don't have a minimum size,
and thus one could "legally" get away with integers that
only need to be big enough to hold other "defined" 
minimum values, such as ARRAY-DIMENSION-LIMIT, 
which must be greater than 1024.

My question is: does anybody really use these constants
to conditionalize their programs?  It seems to me, either
an implementation will run your program, or not.

Without official validation, a system calling itself a
"Common Lisp" can only be refering to its "spirit",
(-: which likes to float around in a large virtual memory
    with many friends who speak microcode :-)

Kelly

∂18-Apr-87  0049	Mailer@XX.LCS.MIT.EDU 	OR and Multiple Values
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Apr 87  00:49:06 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 18 Apr 87 03:51-EDT
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 38683; 18 Apr 87 03:49:17-EDT
Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 33358; 18 Apr 87 03:45:01-EDT
Date: Sat, 18 Apr 87 03:43 EDT
From: Don Morrison <dfm@JASPER.PALLADIAN.COM>
Subject: OR and Multiple Values
To: MURRAY%cs.umass.edu@RELAY.CS.NET, common-lisp@SAIL.STANFORD.EDU
In-Reply-To: The message of 17 Apr 87 18:27 EDT from MURRAY%cs.umass.edu@RELAY.CS.NET
Message-ID: <870418034319.5.DFM@WHITBY.PALLADIAN.COM>
Reply-To: Don Morrison <DFM%JASPER@LIVE-OAK.LCS.MIT.EDU>

    Date:     Fri, 17 Apr 87 18:27 EDT
    From:     MURRAY%cs.umass.edu@RELAY.CS.NET

    However, I'll take this opportuntiy to again ask for a MULTIPLE-VALUE-OR special
    form, since it cannot be defined without consing in Common-Lisp (I guess it COULD
    be a macro that expands into consing code, but the compiler would know about, but
    that is another discussion).

What are the semantics of MULTIPLE-VALUE-OR?  Does it

a) return all the values returned by the first form with a non-null first value
   (since we're no longer implicitly expecting exactly one value what does it
   do in the case of zero values?)

b) return all the values returned by the first form with all its values non-null
   (if there are zero values does that count as all non-null?)

c) return all the values returned by the first form with any of its values non-null
   (if there are zero values does that count as none non-null?)

d) return the maximum number of values returned by any forms with each slot chosen
   from the first form that returned non-null in that form (this one would require
   always evaluating all the forms, so I'm probably getting bogus here)

e) return all the values returned by the first form that returned the maximum number
   of non-null values (even more bogus)

f) ...

I think more to the heart of the matter is that Common LISP needs a way to grab,
inspect, and pass on an unknown number of multiple values without consing (and yes,
avoiding consing can be crucial for real applications give the current state of the
art for garbage collection on conventional hardware).  It's possible that, using
multiple-value-call, simply having some way of doing non-consing &rest arguments may
be sufficient.  For example, I believe the following gives something close to the
semantics of (a) without consing, if the bogus declaration ensures that the &rest
argument isn't consed (and, of course, if the implementors haven't introduced
gratuitous consing, which is far from a sure thing, especially in
multiple-value-call....).

(defmacro multiple-value-or (&rest forms)		; don't care about this &rest
  `(block #0=#:mv-or-block
     ,@(mapcar
	 #'(lambda (form)
	     `(multiple-value-call
		#'(lambda (&rest #1=#:mv-or-args)	; this &rest musn't cons
	            (declare (dynamic-extent #1#))
		    (when (first #1#)
		      (return-from #0# (apply #'values #1#))))
		,form))
	 forms)
     nil))

For example,

(multiple-value-or (mumble) (shout) (bellow))

->

(block #:mv-or-block
  (multiple-value-call
    #'(lambda (&rest #:mv-or-args)
        (declare (dynamic-extent #:mv-or-args))
	(when (first #:mv-or-args)
	  (return-from #:mv-or-block (apply #'values #:mv-or-args))))
    (mumble))
  (multiple-value-call
    #'(lambda (&rest #:mv-or-args)
        (declare (dynamic-extent #:mv-or-args))
	(when (first #:mv-or-args)
	  (return-from #:mv-or-block (apply #'values #:mv-or-args))))
    (shout))
  (multiple-value-call
    #'(lambda (&rest #:mv-or-args)
        (declare (dynamic-extent #:mv-or-args))
	(when (first #:mv-or-args)
	  (return-from #:mv-or-block (apply #'values #:mv-or-args))))
    (bellow))
  nil)

(B) and (c) can be implemented by replacing "(when (first #1#)" by
"(when (every #'identity #1#)" and "(when (some #'identity #1#)",
respectively.


∂18-Apr-87  0538	RPG  	Packages 
To:   common-lisp@SAIL.STANFORD.EDU   
On the proposal:

	"Any argument described in this section as a package name
	 or package may be either a string or a symbol."

This, of course, makes the language just a little worse than it is.
There is no rational sense in which a string or a symbol is a
package.

			-rpg-

∂18-Apr-87  1251	REM@IMSSS 	OR if some argument returns no values  
Received: from IMSSS by SAIL with PUP; 18-Apr-87 12:50 PDT
Date: 18 Apr 1987 1159-PDT
From: Rem@IMSSS
Subject: OR if some argument returns no values
To:   Common-LISP@SU-AI

The manual doesn't say as far as I can tell what OR is supposed to do
if one of the arguments doesn't return any values at all. OR is defined
in terms of COND, which likewise isn't documented in the no-return-value
case. If CL doesn't support no-return-values at all within the general
framework of multiple return values, then this question is moot.
(Can an expert say whether no-return-values is as legal as one-return-value
or multiple-return-values?) If CL *does* support no-return-values, or if
that is a legitimate extension to the language, then my opinion is that
it should "be an error" to do an OR (or COND) with one of the tests
not returning any value at all, the logic being "if the function won't tell
me what its answer is, how am I supposed to use that answer to make a
decision?". AND and a few other functionoids may fall into this same
category as OR and COND.
-------

∂18-Apr-87  1407	diamant%hpfclp@hplabs.HP.COM 	Re: CLARIFICATION: [italics]package arguments.    
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 18 Apr 87  14:06:58 PDT
Received: from hpfclp.HP.COM by hplabs.HP.COM with TCP ; Sat, 18 Apr 87 10:52:47 pst
Received: by hpfclp.HP.COM; Sat, 18 Apr 87 12:51:52 mst
Date: Sat, 18 Apr 87 12:51:52 mst
From: John Diamant <diamant%hpfclp@hplabs.HP.COM>
Return-Path: <diamant@hpfclp>
Message-Id: <8704181951.AA22390@hpfclp.HP.COM>
To: edsel!bhopal!jonl@navajo.stanford.edu
Subject: Re: CLARIFICATION: [italics]package arguments.
Cc: common-lisp@sail.stanford.edu

> Contrary to what John Diamant suggested, I think that very few functions
> fall into category (1).  The vast majority seem to be in category (2).

After looking through several pages of CLtL, I see that you are right that
only a few fall in category (1).  However, it is still a major leap to
conclude (2) simply because the "must" is not listed for the function.  If
that were the intended interpretation, then a statement at the beginning
of the section should say that.  This is comparable to taking a word and
saying in this sentence it means "A" and in this other sentence it means "B."
It is still true that package means package, and not package name, so what
you are talking about is still an extension, not something that can be
concluded from the text.

> There wasn't a lot of discussion back then about these points -- certainly
> there was no serious objection to them.  Probably the HP folks weren't
> receiving the mail then?

Well, that's probably true.  I certainly wasn't, as I wasn't with HP 2
years ago.  Even if the mailing list was being received, it could have been
missed.  However, when interpretations like that are "added" to CLtL, we
need to be careful to record them for inclusion in further standards.
Standards don't do us any good if people decide to reinterpret them beyond
what is stated, simply because they don't like the standard.

Note that I have no objection to your proposed enhancement, but it requires
a clarification to the standard, not just a joint decision from some of
the implementors.

Regarding David Moon's comments: we will have to agree to disagree.  I believe
that any extension to CLtL should be clearly delineated or not included.
I would be much happier if CLtL stated how this delineation must occur
(explicitly requiring extensions to not be in the LISP package, possibly
shadowing symbols that are, for instance).  Portability is probably the
most important feature of Common Lisp, and I hate to see such a lack of
committment to it that if something isn't convenient because of portability
issues, we just ignore the portability issue.

	John Diamant

∂18-Apr-87  1444	FAHLMAN@C.CS.CMU.EDU 	OR if some argument returns no values 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Apr 87  14:44:05 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 18 Apr 87 17:44:56-EDT
Date: Sat, 18 Apr 1987  17:44 EDT
Message-ID: <FAHLMAN.12295577578.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   common-lisp@SAIL.STANFORD.EDU
Subject: OR if some argument returns no values


To Rem at IMSSS:

    The manual doesn't say as far as I can tell what OR is supposed to do
    if one of the arguments doesn't return any values at all. 

Page 133-134:

"If the caller of a function does not request multiple values, but the
called function returns multiple values, then the first value is given
to the caller and all the other values are discarded; if the called
function produces zero values, then the caller gets NIL as a value."

OR, COND, and friends do not expect multiple values from the sub-forms,
except in certain tail-recursive poisitions.

Seems pretty clear to me.  Whether you like this behavior is another
question.

-- Scott

∂18-Apr-87  1628	Randy%acorn%LIVE-OAK.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	Re: SETF and pathname slots  
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Apr 87  16:27:56 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 18 Apr 87 19:30-EDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 38740; 18 Apr 87 19:29:54-EDT
Received: from PINK-FLOYD.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 65237; Sat 18-Apr-87 19:17:01-EST
Date: Fri, 17 Apr 87 10:39 EDT
From: Randy%acorn@oak.lcs.mit.edu
To: ghenis.pasa@Xerox.COM
Subject: Re: SETF and pathname slots
Cc: common-lisp@sail.stanford.edu

    Date: 16 Apr 87 17:01 PDT
    From: ghenis.pasa@Xerox.COM
    
    Should the standard require SETF to handle pathname slots? If we are
    going to have MAKE-PATHNAME, PATHNAME-DEVICE, etc, for consistency we
    should also have COPY-PATHNAME and be able to do things like (SETF
    (PATHNAME-TYPE old-path) "OLD"). Is there any reason not to?
    
Probably not, since a lot of implementations might want to cache
pathnames (so they are EQ).  You could have COPY-PATHNAME take
keyword arguments of slots to change in the copying process.
Or you could probably use MERGE-PATHNAMES for these sorts of
things.

Random

∂18-Apr-87  1922	FAHLMAN@C.CS.CMU.EDU 	Environment-Arguments  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Apr 87  19:22:13 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 18 Apr 87 22:23:05-EDT
Date: Sat, 18 Apr 1987  22:23 EDT
Message-ID: <FAHLMAN.12295628211.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   cl-cleanup@SAIL.STANFORD.EDU
Subject: Environment-Arguments


Before I try to put the Environment-Arguments proposal into final form,
there's an unresolved issue we need to clean up.

In mail several months ago, Moon said that he agreed with adding an
optional environment argument to MACRO-FUNCTION, but that for
consistency we should also add such an argument to SPECIAL-FORM-P,
SYMBOL-FUNCTION, and SYMBOL-VALUE.

I think that this is wrong.  (Masinter apparently does too, but I'll
speak for myself.)  

This facility isn't designed for writing debuggers; it is meant to allow
macro-expanding macros to operate properly.  Macros sometimes need to
expand other macros at compile time so that they can do SETF-like
things.  In accessing some otehr macro's definition, a macro should take
cognizance of any MACROLET definitions and of lexical function
definitions that might shadow a macro definition.  Therefore, they need
to be able to call MACRO-FUNCTION with an environment arg.

I don't think macros need to get at function definitions and values in
the same way.  Function definitions do not have to be available at
compile time, nor do values.  And special forms are immutable: they
cannot be redefined, so presumably they cannot be shadowed either.
(Larry proposes to make this explicit as part of this proposal; I would
prefer to make it a separate proposal, but agree with the
clarification.)

So I don't believe that SPECIAL-FORM-P, SYMBOL-FUNCTION, or SYMBOL-VALUE
need an environment arg after all.

Dave, do you buy that analysis?  If so, I'll propoduce a proposal along
the lines of what Larry sent out.

-- Scott

∂18-Apr-87  2215	MURRAY%cs.umass.edu@RELAY.CS.NET 	MULTIPLE-VALUE-OR, and Consing 
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 Apr 87  22:15:17 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac00469; 19 Apr 87 1:08 EDT
Received: from cs.umass.edu by RELAY.CS.NET id am08685; 19 Apr 87 1:03 AST
Date:     Sat, 18 Apr 87 19:34 EDT
From:     MURRAY%cs.umass.edu@RELAY.CS.NET
To:       common-lisp@SAIL.STANFORD.EDU
Subject:  MULTIPLE-VALUE-OR, and Consing
X-VMS-To: CLMAIL


>From: Don Morrison <dfm@jasper.palladian.com>
>What are the semantics of MULTIPLE-VALUE-OR?   ...

It should be the same as OR, but return multiple-values.  Since OR only
conditionalizes on the first value, MULTIPLE-VALUE-OR does the same,
but returns all the rest of the values as well.
As standard with multiple-values, when less than asked for are returned, 
the extra are filled out with NIL's, so no-values is the same as a NIL value.

>I think more to the heart of the matter is that Common LISP needs a way to grab,
>inspect, and pass on an unknown number of multiple values without consing
> (and yes, avoiding consing can be crucial for real applications
> give the current state of the art for garbage collection
> on conventional hardware).  It's possible that, using
>multiple-value-call, simply having some way of 
>doing non-consing &rest arguments may be sufficient.   ...

I whole-heartly agree that A) Unneccessary consing should always be avoided,
 B) it would be great to have &rest args that don't cons.
I currently have plans to have a STACK-LIST declaration that declares that
a &Rest is stack-allocated (as well as WITH-STACK-LIST, ala Lisp Machines)
in my system.  I would suggest that others consider this as well, but
of course, it is only a declaration that could be ignored.
(I already avoid consing for (&Rest ignore), which should be easy).

My point is that MULTIPLE-VALUE-OR can only be done efficiently by low-level
implementation-specific code, and thats why it should be in Common Lisp.

- Kelly Edward Murray
  University of Massachusetts, Amherst

∂19-Apr-87  1029	primerd!doug@enx.prime.pdn 	Bigosities  
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 19 Apr 87  10:29:50 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id <AA13976@EDDIE.MIT.EDU>; Sun, 19 Apr 87 13:31:55 EDT
Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail)
	id AA14369; Sun, 19 Apr 87 13:10:47 EST
Message-Id: <8704191810.AA14369@primerd.prime.com>
Received: (from user DOUG) by ENX.Prime.PDN; 17 Apr 87 10:20:06 EST
Subject: Bigosities
To: common-lisp@sail.stanford.edu
From: primerd!DOUG@ENX.Prime.PDN
Date: 17 Apr 87 10:20:06 EST

The concept that 64 bits could be construed as a reasonable integer 
limit is silly since there are many hardware architectures where a
basic arithmetic operation can be done on 64 bits in both integer
and floating point.   Also 64 bits is only ~21 decimal digits.

Doug

∂19-Apr-87  1726	sandra%orion@cs.utah.edu 	Re: Bigosities
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 19 Apr 87  17:26:52 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
	id AA14758; Sun, 19 Apr 87 18:29:35 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
	id AA03009; Sun, 19 Apr 87 18:29:31 MDT
Date: Sun, 19 Apr 87 18:29:31 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8704200029.AA03009@utah-orion.ARPA>
Subject: Re: Bigosities
Newsgroups: fa.common-lisp
To: common-lisp@sail.stanford.edu
References: <8704191810.AA14369@primerd.prime.com>

In article <8704191810.AA14369@primerd.prime.com>, 
primerd!DOUG@ENX.Prime.PDN writes:
> The concept that 64 bits could be construed as a reasonable integer 
> limit is silly since there are many hardware architectures where a
> basic arithmetic operation can be done on 64 bits in both integer
> and floating point.   Also 64 bits is only ~21 decimal digits.
> 
> Doug

Maybe I should have put a few :-)'s in my original posting:  I certainly
wasn't intending 64-bit bignums as a serious proposal.  My reason for
throwing out the idea in the first place was to point out that integer
overflow is bad news whether the limit on integer size is large or small,
and also to point out that the manual doesn't *say* it has to be huge.

If the limit is huge, we can maybe get away with some handwaving and saying
that any program that runs up against the limit is wedged anyway.  But 
that does not change the fact that there is a problem with overflow.

-Sandra

∂19-Apr-87  1802	FAHLMAN@C.CS.CMU.EDU 	Issue ADJUST-ARRAY-DISPLACEMENT  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 Apr 87  18:02:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 19 Apr 87 21:03:10-EDT
Date: Sun, 19 Apr 1987  21:03 EDT
Message-ID: <FAHLMAN.12295875812.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   CL-CLEANUP@SAIL.STANFORD.EDU
Subject: Issue ADJUST-ARRAY-DISPLACEMENT


[Note: some comments by Nick Gall on DISPLACED-ARRAY-P, a totally
separate proposal on Steele's list, were mixed in with the discussion
file Larry sent out, probably because Gall addressed several distinct
issues in the same message.]

Status: New proposal (discussed earlier on Common Lisp list).

Issue: ADJUST-ARRAY-DISPLACEMENT
Reference: Steele p.297
Category: Clarification
Edit history: Revision 1 by SEF, 18-Apr-87 (from Steele's list)

Problem Description:

The interaction of Adjust-Array and displacement is insufficiently
specified in the case where the array being adjusted is displaced.

Proposal: ADJUST-ARRAY-DISPLAYCEMENT:RULES

Suppose we are adjusting array A, which is perhaps displaced
to B before the Adjust-Array call and perhaps to C after the call.

(1) A is not displaced before or after: The dimensions of A are altered,
and the contents rearranged as appropriate.  Additional elements of A
are taken from the :initial-element.  The use of :initial-contents
causes all old contents to be discarded.

(2) A is not displaced before, but is displaced to C after.  As
specified in CLtL, none of the original contents of A appears in A
afterwards; A now contains the contents of C, without any rearrangement
of C.

(3) A is displaced to B before the call, and is displaced to C after the
call.  As in case (2), the contents of B do not appear in A afterward
(unless such contents also happen to be in C).  If
:displaced-index-offset is not specified in the Adjust-Array call, it
defaults to zero; the old offset (into B) is not retained.

(4) A is displaced to B before the call, but not displaced afterward.  A
gets a new "data region", and contents of B are copied into it as
appropriate to maintain the existing old contents; additional elements
of A are taken from the :initial-element.  However, the use of
:initial-contents causes all old contents to be discarded.

Note that if array X is displaced to array Y, and array Y is displaced
to array Z, and array Y is altered by Adjust-Array, array X must now
refer to the adjusted contents of Y.  This means that an implementation
may not collapse the chain to make X refer to Z directly and forget that
the chain of reference passes through array Y.  (Cacheing techniques are
of course permitted, as long as they preserve the semantics specified
here and in CLtL.)

If X is displaced to Y, it is an error to adjust Y in such a way that it
no longer has enough elements to satisfy X.  This error may be signalled
at the time of the adjustment, but this is not required.

Rationale:

This interaction must be clarified.  This set of rules was proposed some
time ago, as a result of discussions on the Common Lisp mailing list,
and this model has been adopted by many Common Lisp implementations.

Current Practice:

Many implementations currently follow the model proposed here.  Others
may do something random.  There is no major competing alternative.

Adoption cost:

Some existing implementations may have to be changed, but adopting any
other model would be worse.  Public-domain code implementing this model
is available from CMU.

Benefits:

Clarification of a situation that is currently not addressed by the
standard.

Conversion Cost:

This is a relatively uncommon situation, which is the reason it didn't
occur to the original language designers to specify how it works.  Any
user code that cares about this issue probably already follows the
proposed model.

Discussion:

Discussed long ago on the Common Lisp mailing list.  This proposal
attempts to capture the overall consensus that emerged at that time.

∂19-Apr-87  2028	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue IF-BODY (Version 4)    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 Apr 87  20:27:48 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 119725; Sun 19-Apr-87 23:27:59 EDT
Date: Sun, 19 Apr 87 23:27 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue IF-BODY (Version 4)
To: Masinter.PA@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
References: <870417-163353-2990@Xerox>
Message-ID: <870419232729.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Notes on this draft:

 I expanded a few of the sections where I thought important information
 was missing.

 I changed the Test Case to one which would show up a case that
 the old test case hadn't -- some implementations quietly ignore
 the additional forms.

 I removed the Summary, which I thought sounded downright paranoid.
 The whole point of committees and voting is to ensure due process.
 It goes without saying that we're not held hostage by much of 
 anything. Words like "hostage" suggest an undue air of tension.

 I added another clump of discussion by me in the Discussion.

==============================================================================
Issue:        IF-BODY
References:   IF (p115)
Category:     ENHANCEMENT
Edit history: 27-Feb-87, Version 1 by Pitman   
	       3-Mar-87, Version 2 by Fahlman  (added IF-BODY:NO)
	      17-Apr-87, Version 3 by Masinter (misc editing)
	      19-Apr-87, Version 4 by Pitman   (misc editing)
Status:       Not for release

Problem Description:

  CLtL defines the meaning of an IF expression only in the case of
  2 or 3 arguments. Some implementations extend the meaning to allow
  more arguments, but this extension tends to thwart code portability
  because of widespread use of IF.

Test Case:
 
  (IF NIL 'THEN 'ELSE 'MORE)

  According to CLtL, this is an error.
  In some implementations, this returns ELSE.
  In some implementations, this returns MORE.
  In some implementations, this signals an error at syntax analysis time.

Proposal (IF-BODY:YES):

  Extend IF to accept a body of else forms (to be treated as an implicit
  PROGN), with syntax (IF test then {else}*).

Rationale:

  Some implementations provide this extension while others do not.
  Dependence of user code on this feature commonly goes undetected
  until the code is ported to a system which does not have the feature,
  which is often inconveniently late in the development cycle.

  In principle, it is possible to develop and test code thoroughly
  in one (extended) dialect, compile it in another dialect without 
  obtaining any compiler warnings, and then to run it in the second
  dialect and find that it does not behave as the original programmer
  intended. This phenomenon is counter to the portability goals of
  Common Lisp.

Current Practice:

  Some implementations already provide this feature.

  A few implementations provide alternate keyword-driven extensions
  that are incompatible with this extension.
   
  Some implementations signal an error if other than two or three
  arguments are passed.

  Some implementations quietly ignore additional arguments to IF, making
  it hard to detect errors in code that was developed on systems with
  the extended syntax.

Adoption Cost:

  Presumably most implementations would require minor adjustments
  to the interpreter, the compiler, and any code walking tools.
  The estimated cost is low.

  Implementations which provided an alternate keyword-driven
  extension could have more serious difficulties. In some cases,
  however, heuristic solutions which select a semantics based on
  the presence or absence of keywords may be of use.

Benefits:

  This will diminish one common source of aggravation in applications
  that took advantage of the extension provided by some implementations,
  as they would not have to remove this implementation dependency.

Cost of not adopting this change:

  Unless someone proposes an ammendment to CLtL which requires that
  LISP:IF not be extended to allow additional arguments, users will
  continue to develop code in some implementations where these features
  are available, and then upon porting their code may notice that their
  code either does not compile (generates syntax errors) or does not
  compile correctly (the additional forms are quietly ignored and the
  code generated is not what the writer intended).

  If this proposal is not adopted, Common Lisp users doing ports from
  certain dialects to certain other dialects will repeatedly risk lost
  time and effort in debugging problems which could be defined away
  by this proposal.

  Users with code which had multiple else expressions should find them
  and convert them to (COND (test then) (T {else}*)), but in practice
  they may be very hard to find until the time the port is done, which
  is usually inconveniently late in the development cycle for this kind
  of bug to be detected.

Conversion Cost:

  Uses of the IF special form in portable user-defined code would
  not be affected since the extension is ``upward compatible.''

  Some portable user-defined code (such as macros or code-walking
  utilities) might depend on understanding the syntax of IF because
  it is defined to be a primitive special form. Such programs would
  require modification, although those modifications are likely to
  be simple.

  Uses of the IF special form in dialects which allow keyword-driven
  extensions (or other incompatible extensions) to IF would be 
  affected syntactically. Non-portable program-understanding tools
  for those dialects (including the interpreter and compiler) would
  be impacted as well.

Aesthetics:

  Some people like the IF body idea and find it more visually
  aesthetic than the more-parenthesized (and incidentally also 
  more-indented) COND alternative.

  Some people really dislike the idea of an IF body because they
  feel it would destroy the symmetry of the THEN and ELSE clauses
  in an IF expression, and would lead to a visually confusing format.

  The IF-BODY:YES proposal does not preclude a self-imposed 
  programming style which uses no more than 3 arguments. In that
  sense, it leaves the style issue up to the individual programmer.

Discussion:

  A big chunk of the discussion around this proposal centered on 
  the form of the arguments rather than on the proposal itself.
  The issue of whether the fact that some implementations had
  chosen to extend IF should influence the future of Common Lisp
  was debated. 

 Pitman:
  This is a source of frustration for users, only a few of whom
  care about arguing about whether more than three arguments is
  aesthetic. They just want their programs to port without hassle.
  CLtL has egged on the problem by explicitly suggesting that
  such extensions were permissible.

 Fahlman:
  Whatever we decide about the merits of this proposal itself,
  I want to VEHEMENTLY OBJECT to the rationale put forward in
  [the first draft of] this proposal ... it is an extremely bad
  precedent ... This same argument could be used to slip any
  number of unspeakable horrors into the language....

 Moon:
  The mere fact that some people like this extension is not
  sufficient reason to put it into the language, but it is
  certainly sufficient reason to -discuss- putting it into the
  language.

 Steele:
  I agree with Scott's assessment of the IF-BODY proposal (though
  I think the proposal was worth making). I would point out that
  one of the reasons for including IF in the language is to have
  a simple primitive that can easily be recognized, by people and
  by program-walkers alike, as being the simplest conditional and
  not having implicit PROGNs as do WHEN, UNLESS, and COND.

 Pitman:
  Experience has shown that implementations are going to disagree
  in a way that thwarts portability until we do something about it.

  Both the extended dialect and the non-extended dialect are
  within their rights. No individual dialect is at fault when
  programs do not port correctly due to this problem; rather,
  we are at fault for having provided a specification which
  promotes this sort of problem.

  To me, the question is not "Should we do something?" but rather
  "What should we do?". I see only two choices: We can -require-
  implementations to signal an error if there is ever more than
  3 arguments to an IF or we can extend the language to make the
  case of more than 3 arguments be well-defined in some interesting
  way.

  If we voted to disallow extensions to IF altogether, I'd want to
  be able to justify that to our installed customer base. I can
  imagine myself telling people they couldn't use the extended
  case any more because it was cluttering the otherwise simple 
  syntax of Common Lisp -- I'd get laughed out of the room. All
  someone would have to do to break down my argument would be to
  compare the impact of this syntax extension to those already 
  present in LAMBDA or DEFUN. In truth, program understanding 
  programs have considerably more formidable problems than worrying
  about whether IF has symmetric arguments, so I just don't buy
  this counter-argument that some have presented.

  Users don't care that IF and COND were introduced at differing
  syntactic layers. They just care that the total space of 
  constructs available is adequately expressive, easy to modify,
  etc. For those who are content to simply not use these 
  extensions, those needs are trivially easy to satisfy. For 
  those who -do- use those extensions, I'd like to have more 
  than a gold star to offer them in exchange for the expressive
  power I'd be removing by making the if-body case illegal.

∂19-Apr-87  2054	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: COMPILER-WARNING-STREAM (Revision 4) 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 Apr 87  20:54:05 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 119728; Sun 19-Apr-87 23:53:52 EDT
Date: Sun, 19 Apr 87 23:53 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMPILER-WARNING-STREAM (Revision 4)
To: Fahlman@C.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12295346987.BABYL@C.CS.CMU.EDU>
Message-ID: <870419235327.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Fri, 17 Apr 1987  20:38 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    Status: Released.  This version slightly revised to incorporate Dussud's
    comment about the effect of this change on Dribble and to clean up some
    awkward wording.

Although an earlier version of this was released, my feeling is that if a
semantic modification is made to a released proposal, the proposal should
become unreleased pending discussion in committee so that copies of it don't
accidentally get distributed too widely before there's been a chance for 
internal review of `obvious' problems.

    Issue:        COMPILER-WARNING-STREAM
    References:   COMPILE (p438), COMPILE-FILE (p439)
    Category:     CLARIFICATION/CHANGE
    Edit history: Revision 1 by KMP 02/27/87
		  Revision 2 at committee meeting 15-Mar-87 14:18:56
		  Revision 3 reformat by Masinter 15-Mar-87 17:42:10
		  Revision 4, minor revision by SEF 15-Apr-87

    Problem Description:

    The description of the COMPILE and COMPILE-FILE functions does not
    explicitly permit them to print warnings.  If this is to be allowed, it
    should be specified what stream such warnings are printed on.

    Proposal (COMPILER-WARNING-STREAM:ERROR-OUTPUT)

    COMPILE and COMPILE-FILE are permitted to output warnings; warnings
    should go to the stream that is the value of *ERROR-OUTPUT*.

    As a corollary of this, DRIBBLE is required to record from
    *ERROR-OUTPUT* as well as *STANDARD-INPUT* and *STANDARD-OUTPUT* so that
    it can record any compiler warnings that may be generated while it is in
    effect.

I'm worried about potential unintended consequences of a proposal to change
DRIBBLE that piggybacks on this proposal. 

For example, I could easily imagine someone doing
 (SETQ *ERROR-OUTPUT* (OPEN filename1))
 ...stuff...
and then wanting a transcript so doing
 (SETQ *ERROR-OUTPUT* (OPEN filename2)) 
 (DRIBBLE filename3)
 ...stuff...
 (DRIBBLE) 
I would say their clear intent here is that *ERROR-OUTPUT* not be redirected.
I think that DRIBBLE is supposed to have no visible effect on the interaction
between (DRIBBLE file) and (DRIBBLE), so I'm surprised that it suggests
changing *STANDARD-INPUT* and *STANDARD-OUTPUT* rather than *TERMINAL-IO*.
Similar questions can be asked about *QUERY-IO* and *DEBUG-IO*.

My feeling is that the description of DRIBBLE needs lots of fixing as part of
a separate proposal unrelated to this one. I'm amenable to such a proposal, but
I don't think it belongs here because it requires further elaboration and
justification. 

    Rationale:

    Compiler warning output is a widely accepted feature of compilation.
    Warnings that come via the WARN function will go to the stream that is
    the value of *ERROR-OUTPUT*.

    Current Practice:

    Some implementations send compiler warning output to *ERROR-OUTPUT*.
    Other implementations send it to *STANDARD-OUTPUT*.

    Adoption Cost:

    In most cases, the change to the compiler to redirect output is expected
    to be very slight.

    Benefits:

    Currently, it is difficult to redirect the output of COMPILE and
    COMPILE-FILE because it isn't clear what stream receives the warnings.

    Conversion Cost:

    Most user programs that care are probably already tolerant of both
    situations or naively expect that output will go to *ERROR-OUTPUT*. As
    such, most users will probably perceive this as a clarification.

    Aesthetics:

    Most users will probably perceive this change as a simplification
    because it will allow the kind of warning that comes from WARN and the
    kind of warning that comes from compilation to be conceptually grouped.

    Discussion:

    This was a problem in adapting MACSYMA to Common Lisp because Macsyma
    provides alternate user interfaces to the compiler which it needs to be
    able to control.

    The cleanup committee supports this change.

∂19-Apr-87  2110	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: DO-SYMBOLS-DUPLICATES (Revision 1)   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 Apr 87  21:10:35 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 119735; Mon 20-Apr-87 00:10:32 EDT
Date: Mon, 20 Apr 87 00:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DO-SYMBOLS-DUPLICATES (Revision 1)
To: Fahlman@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12295374347.BABYL@C.CS.CMU.EDU>
Message-ID: <870420001008.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

While I agree it might be somewhat expensive to filter duplicates in
some cases, I wonder how often the efficiency matters.  In my personal
experience, DO-SYMBOLS and friends is never used in realtime because
it usually pages like crazy anyway.

In my code, it's generally used in environment initialization situations
where efficiency is not my chief concern, and where not making a mistake
is sometimes critical. I think it would be nicer if programmers didn't
have to worry about duplication. Sometimes I do very complicated package
surgery using DO-SYMBOLS where I think terrifying things might happen if
I hit a duplicate. Usually by the time I've debugged the code I make it
a goal to make repeat calls to the body not hurt things so I can test
the code more than once, but having it try to help me as much as
possible until I've gotten all the glitches out would be nice.

Does anyone care to make an estimate of exactly how much things get
slowed down if you don't duplicate any symbols and/or an estimate of how
often this slowdown would cause an adverse performance impact?
Including such assumptions in this proposal would be useful so that they
can be discussed or contested.

Personally, I'd rather see a keyword argument added someplace saying
that I'm willing to accept seeing duplications so that naive expectations
would not be violated in the default situation. As a straw man, something
like:

 (DO-SYMBOLS (SYMBOL (FIND-PACKAGE "FRED") NIL
	       :ALLOW-DUPLICATES T
	       :EXTERNAL-ONLY NIL)
   ...)

Note that this could eliminate the need for DO-EXTERNAL-SYMBOLS...

∂19-Apr-87  2115	FAHLMAN@C.CS.CMU.EDU 	Issue: COMPILER-WARNING-STREAM (Revision 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 Apr 87  21:15:21 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 20 Apr 87 00:16:22-EDT
Date: Mon, 20 Apr 1987  00:16 EDT
Message-ID: <FAHLMAN.12295910980.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: COMPILER-WARNING-STREAM (Revision 4)
In-reply-to: Msg of 19 Apr 1987  23:53-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>


    Although an earlier version of this was released, my feeling is that if a
    semantic modification is made to a released proposal, the proposal should
    become unreleased pending discussion in committee so that copies of it don't
    accidentally get distributed too widely before there's been a chance for 
    internal review of `obvious' problems.

I agree.

As for KMP's substantive objections, the problem is that we have already
said too much about Dribble, and now we're caught in the game of trying
to specify it exactly.  We can't standardize it in detail, since it
will have to be handled differently on different systems, depending on
the details of each system's user interface.  It seems to me that the
two coherent possibilities are to eliminate it from the standard
altogether, or to say something like the following:

Some implemenations may provide a mechanism for saving a transcript of
the top-level user interaction (input and output) to a file.  When such
a mechanism is present, it is conventionally turned on by (dribble
<pathname>) and is turned off by (dribble).  Period.

-- Scott

∂19-Apr-87  2134	FAHLMAN@C.CS.CMU.EDU 	Issue: DO-SYMBOLS-DUPLICATES (Revision 1)  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 Apr 87  21:34:03 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 20 Apr 87 00:35:01-EDT
Date: Mon, 20 Apr 1987  00:34 EDT
Message-ID: <FAHLMAN.12295914368.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:   cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: DO-SYMBOLS-DUPLICATES (Revision 1)
In-reply-to: Msg of 20 Apr 1987  00:10-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>


It's hard to estimate the cost of eliminating duplicates in DO-SYMBOLS.
The obvious strategy is to cons up (or keep around) a hash-table and to
note symbols as they go by.  That would be a big hash-table for some
packages, and might double the paging required (or push a non-paging
program into thrash-land.  Let's guess that it doubles the time required
on the average.

I wouldn't mind adding a non-duplicating version of DO-SYMBOLS, as long
as this isn't the default.  I don't want to pay the price for KMP's
occasional hairy applications every time I scan the symbol table looking
for something.  I don't really object to the keyword idea (with
duplicates-allowed as the default), but the minimum-incompatibility
solution now would be to keep the two functions we have and add
DO-SYMBOLS-NO-DUPLICATES as either a new built-in function or a yellow
pages package for people who want it.

-- Scott

∂20-Apr-87  0625	DALY@IBM.COM 	Pavel's reply   
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 20 Apr 87  06:25:36 PDT
Date: 20 April 1987, 09:21:28 EDT
From: Timothy Daly <DALY@ibm.com>
To:   common-lisp@sail.stanford.edu
Message-Id: <042087.092128.daly@ibm.com>
Subject: Pavel's reply

Quite right. The missing # isn't missing. Mea Culpa.

∂20-Apr-87  0658	FAHLMAN@C.CS.CMU.EDU 	Issue IF-BODY (Version 4)   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Apr 87  06:58:12 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 20 Apr 87 09:54:07-EDT
Date: Mon, 20 Apr 1987  09:54 EDT
Message-ID: <FAHLMAN.12296016150.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:   CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue IF-BODY (Version 4)
In-reply-to: Msg of 19 Apr 1987  23:27-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>


There are many ways in which we could present controversial issues like
this.  The idea of having two separate proposals, one in favor of the
change and one against, is obviously insane.  It is also unreasonable to
allow the last person to touch the propsal to write an essay favoring
one point of view, while everyone else's arguments get boiled down to a
few selected phrases and some ellipsis dots.  Any reasonably fair way of
presenting this stuff is all right with me.  Maybe the best approach is
to let KMP write up the proposal, state his case at length in a
"Discussion: Pro" section, and let the loyal opposition have more or
less equal space in a "Discussion: Con" section.

The only quibble I have with the pre-discussion part of KMP's
presentation is that he presents (COND (test then) (T {else}*)) as the
obvious translation, and then picks on this in the aesthetics section.
If we're going to argue aesthetics, I prefer the following translation:
(if test
    (progn {then-clauses}*)
    (progn {else-clauses}*))

Here is what I would propose for the Discussion:Con section.  Others in
sympathy with this view are invited to contribute to this section:
---------------------------------------------------------------------------

On purely aesthetic grounds, I am opposed to this proposal because it
makes code harder to scan quickly (and since we all have to read Common
Lisp code written by others, this is not a situation where each user can
make his own choice).  The three elements of the current IF expression
are easy to spot, and there is a symmetry between the THEN and the ELSE
clause; in the extended form, all the clauses tend to run together
visually into a large, amorphous body, and it is hard to locate the THEN
clause in the middle of all the others.  If a programmer wants either
the THEN or the ELSE clause to be a PROGN, he should use an explicit
PROGN.  The result is indeed "more parenthesized and indented"; this is
a virtue.

On aesthetic matters such as this, reasonable people may differ.  If a
majority in the Common Lisp community favor the extended form of IF,
their taste should prevail, but this has not been the majority view when
this issue has come up in the past.

The remaining argument is that this extension should be added because
some dialects already support it, some users do not realize that this
usage is not legal Common Lisp, and that these users are inconvenienced
when they discover, "late in the development cycle", that their code
does not run on other machines.  I believe that it would set a very bad
precedent to give this argument any weight whatsoever.  To do so would
be to give each implementor a tool that could be used to force any
compatible extension, no matter how ill-advised, into the language
standard: simply add the extension to your own dialect, refuse to
provide any warnings to your users that they are using a non-standard
feature, and then petition the standards committee (on the users'
behalf) to add the extension to Common Lisp so that these poor users
won't be inconvenienced.

The original charter of Common Lisp made it clear that implementations
could add non-standard extensions, but that users who want their code to
be portable should use the standard language only.  The proper way to
protect users from portability problems is for each implementation to
provide a compilation mode (or code-walking tool or whatever) that warns
about the use of non-portable extensions.  It has been suggested that
such a mode should be required, but Moon has argued (correctly, in my
view) that this is an environment issue not appropriate for
standardization.  So each implementation that chooses to extend the
language in some way must take responsibility for protecting its users
from the consequences; if it neglects to do so, its users should
complain to the implementors, not to the Common Lisp standards
committee.

So, to the two choices that KMP presents (forbid any extension to IF or
adopt this proposal), I would add a third choice: encourage (but do not
require) that extended implementions issue a warning when non-portable
constructs are used, and encourage users to make life hot for any vendor
who refuses to do this.

I would point out that in this case a code-walker or compiler can easily
detect the use of extended-IF, and that it would be trivial to provide a
tool that puts an explicit PROGN around the ELSE clauses.  It doesn't
matter whether this happens "late in the development cycle" since it is
a trivial modification.

∂20-Apr-87  0658	preece%mycroft@gswd-vms.ARPA 	Bigosities
Received: from GSWD-VMS.ARPA by SAIL.STANFORD.EDU with TCP; 20 Apr 87  06:58:24 PDT
Received: from mycroft.GSD (mycroft.Gould.COM) by gswd-vms.ARPA (5.52/)
Message-Id: <8704201356.AA13978@gswd-vms.ARPA>
Date: Mon, 20 Apr 87 07:55:24 CST
From: preece%mycroft@gswd-vms.ARPA (Scott E. Preece)
To: COMMON-LISP@sail.stanford.edu
Subject: Bigosities

  primerd!DOUG@ENX.Prime.PDN
> The concept that 64 bits could be construed as a reasonable integer
> limit is silly since there are many hardware architectures where a basic
> arithmetic operation can be done on 64 bits in both integer and floating
> point.  Also 64 bits is only ~21 decimal digits.
----------
What has the size of the basic hardware operation size got to do with
anything?  Frankly, as long as the standard doesn't specify a minimum
size for bignum coverage, I would say 64 bits would be conforming.
I have never done any Lisp coding myself (outside of tests of our
implementation) which required numbers bigger than 64 bits -- if I were
going out shopping for a CL for my own use, that restriction wouldn't
bother me.

The most important thing is that each implementation make its limits
clear, so that the porter knows if she has a chance of making the port
in less than geological time and so that the shopper knows whether
the implementation is suitable for the proposed use.  I don't really
care whether the limits are encoded as constants or printed on paper,
but I would like the standard to require that they be available and
that they be separated into representational limits and space limits.

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

∂20-Apr-87  0805	gls@Think.COM 	bignums are bogus   
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 20 Apr 87  08:04:56 PDT
Received: from boethius by Think.COM via CHAOS; Mon, 20 Apr 87 09:54:32 EST
Date: Mon, 20 Apr 87 10:51 EDT
From: Guy Steele <gls@Think.COM>
Subject: bignums are bogus
To: Fahlman@c.cs.cmu.edu, sandra%orion@cs.utah.edu
Cc: common-lisp@sail.stanford.edu, gls@think.com
In-Reply-To: <FAHLMAN.12294960256.BABYL@C.CS.CMU.EDU>
Message-Id: <870420105121.1.GLS@BOETHIUS.THINK.COM>

I have a vague memory of sending to this mailing list, a couple of years
ago, the observation that one could have MOST-POSITIVE-BIGNUM and
MOST-NEGATIVE-BIGNUM, and probably each would occupy 1/3 of the total
memory space.

∂20-Apr-87  1027	RPG   	On the Kanji feature of Common Lisp   
 ∂20-Apr-87  0042	a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET 	On the Kanji feature of Common Lisp 
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 20 Apr 87  00:42:15 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa07982; 20 Apr 87 3:41 EDT
Received: from utokyo-relay by RELAY.CS.NET id ab14315; 20 Apr 87 3:34 AST
Received: from tansei.u-tokyo.junet by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
	id AA08435; Mon, 20 Apr 87 16:42:07 jst
Received: by tansei.u-tokyo.junet (4.12/6.2Junet)
	id AA14916; Mon, 20 Apr 87 16:33:09+0900
Date: Mon, 20 Apr 87 16:33:09+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@ccut.u-tokyo.junet>
Message-Id: <8704200733.AA14916@tansei.u-tokyo.junet>
To: ida%u-tokyo.junet@RELAY.CS.NET, mathis@ADA20.ISI.EDU, 
    x3j13@SAIL.STANFORD.EDU
Subject: On the Kanji feature of Common Lisp

      Dear Bob Mathis,

Please suggest your idea on the contents of this mail.

Thank you.

Masayuki


--------------------------------------------------------
      On 17th April, we had a meeting of Kanji WG under Jeida Common Lisp
Committee to discuss about the draft in ENGLISH for the kanji extension of Common Lisp.
      We concluded that
1) we want to propose our specification to ANSI X3J13.
  The specification is not so restrictive.
2) Prior to do so, One of the author, namely ida, will send
 the whole contents to common-lisp@sail.stanford to get 
 reactions of the US colleagues.
3) The proposed date of submission to CL bboard is
 on the week of May 11th.
4) We are ready to send a person to the next meeting
 to explain our proposal.
5) The reactions on the CL bboard will be gathered, and will
 be transfered to WG members as quick as possible.
 (several of them have E-mail links to ida.)
 We will try to discuss on the issue by E-mails as possible as we can.
 (we have no ethernet-like link to USA, so we cannot reply immediately.)

 we finished the first draft of the english version.
 It was mainly translated by the person of Nippon Symbolics.
 (Thanks Mr.Shiota.)
 The size is 12 pages long in letter sized papers.
 We will revise up and send it.

      Masayuki Ida

∂20-Apr-87  1126	Pavel.pa@Xerox.COM 	Re: Issue IF-BODY (Version 4) 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Apr 87  11:26:16 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 APR 87 11:27:18 PDT
Date: 20 Apr 87 11:27 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Issue IF-BODY (Version 4)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Sun, 19 Apr 87 23:27 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870420-112718-1241@Xerox>

I oppose this proposal on two grounds:

1) I like very much the extremely simple syntax/semantics of the current
IF construct.  Making the syntax assymetric is very ugly and, it seems
to me, likely to encourage programmers to negate otherwise reasonable
conditions in order to make the else clause be the one they need more
than one statement for.  I agree with Scott here; the extra indenting is
a virtue, not a vice.

2) When users lose time due to being confused about which features are
non-standard, it is not proper to complain to the standards committee.
Rather, they should complain to the implementors who did not provide
them with an easy way to be warned about non-portable constructs.
Obviously, not all such extensions can be easily flagged by the
compiler, but it's trivial to notice and warn about uses of IF-BODY.

	Pavel

∂20-Apr-87  1235	Moon@STONY-BROOK.SCRC.Symbolics.COM 	MULTIPLE-VALUE-OR, and Consing   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 Apr 87  12:35:40 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 119912; Mon 20-Apr-87 13:23:57 EDT
Date: Mon, 20 Apr 87 13:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: MULTIPLE-VALUE-OR, and Consing
To: MURRAY%cs.umass.edu@RELAY.CS.NET
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: The message of 18 Apr 87 19:34 EDT from MURRAY%cs.umass.edu@RELAY.CS.NET
Message-ID: <870420132345.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date:     Sat, 18 Apr 87 19:34 EDT
    From:     MURRAY%cs.umass.edu@RELAY.CS.NET

    >I think more to the heart of the matter is that Common LISP needs a way to grab,
    >inspect, and pass on an unknown number of multiple values without consing
    > (and yes, avoiding consing can be crucial for real applications
    > give the current state of the art for garbage collection
    > on conventional hardware).  It's possible that, using
    >multiple-value-call, simply having some way of 
    >doing non-consing &rest arguments may be sufficient.   ...

    I whole-heartly agree that A) Unneccessary consing should always be avoided,
     B) it would be great to have &rest args that don't cons.
    I currently have plans to have a STACK-LIST declaration that declares that
    a &Rest is stack-allocated (as well as WITH-STACK-LIST, ala Lisp Machines)
    in my system.  I would suggest that others consider this as well, but
    of course, it is only a declaration that could be ignored.
    (I already avoid consing for (&Rest ignore), which should be easy).

    My point is that MULTIPLE-VALUE-OR can only be done efficiently by low-level
    implementation-specific code, and thats why it should be in Common Lisp.

I don't think this conclusion follows from your previous paragraph.
If the proposed MULTIPLE-VALUE-OR can easily be implemented in terms of
existing primitives, such as MULTIPLE-VALUE-CALL, and would be efficient
if there were non-consing &rest arguments, and non-consing &rest arguments
are desirable for other reasons, then I think a more logical conclusion is
"because non-consing &rest arguments can only be done efficiently by low-level
implementation-specific code, they should be in Common Lisp."

By the way, I don't think a declaration for non-consing &rest arguments
should be necessary.  It should be simple enough for any compiler to
recognize special cases such as the following, once implementors'
attention has been drawn to the desirability of such optimizations.  Another
way of saying the same thing is that I think consing is an implementation
issue, not a language issue, just as much as whether integer multiplication
takes 1 microsecond or 10 microseconds.

  (lambda (&rest values)
    (when (first values)
      (return-from block (values-list values))))

∂20-Apr-87  1236	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Environment-Arguments  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 Apr 87  12:35:59 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 119933; Mon 20-Apr-87 14:04:19 EDT
Date: Mon, 20 Apr 87 14:03 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Environment-Arguments
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12295628211.BABYL@C.CS.CMU.EDU>
Message-ID: <870420140356.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sat, 18 Apr 1987  22:23 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    In mail several months ago, Moon said that he agreed with adding an
    optional environment argument to MACRO-FUNCTION, but that for
    consistency we should also add such an argument to SPECIAL-FORM-P,
    SYMBOL-FUNCTION, and SYMBOL-VALUE.

    I think that this is wrong.  (Masinter apparently does too, but I'll
    speak for myself.)  

    This facility isn't designed for writing debuggers; it is meant to allow
    macro-expanding macros to operate properly.  Macros sometimes need to
    expand other macros at compile time so that they can do SETF-like
    things.  In accessing some otehr macro's definition, a macro should take
    cognizance of any MACROLET definitions and of lexical function
    definitions that might shadow a macro definition.  Therefore, they need
    to be able to call MACRO-FUNCTION with an environment arg.

I don't think the last sentence follows.  The argument that leads up to it
is an argument that MACROEXPAND and MACROEXPAND-1 need to take an environment
argument.  They already do.  So the real reason for giving MACRO-FUNCTION
an environment arg must be something else; I forget what the reason given
a few months ago was, but I remember that I thought it applied equally well
to those other operations.

    I don't think macros need to get at function definitions and values in
    the same way.  Function definitions do not have to be available at
    compile time, nor do values.  And special forms are immutable: they
    cannot be redefined, so presumably they cannot be shadowed either.

I see no such restriction (special forms cannot be shadowed) in CLtL.
Adding such a restriction seems like a poor idea in view of the third
paragraph on page 57.  In any case, it would be a poor idea to make
MACRO-FUNCTION and SPECIAL-FORM-P behave inconsistently with respect to
the lexical environment, because that could lead to a large body of user
code with the restriction that special forms cannot be shadowed wired
into its structure, and that in turn would make it difficult to lift
such a restriction, either in the language definition or in individual
implementations.  A little forethought now will save a peck of trouble
later.

    (Larry proposes to make this explicit as part of this proposal; I would
    prefer to make it a separate proposal, but agree with the
    clarification.)

    So I don't believe that SPECIAL-FORM-P, SYMBOL-FUNCTION, or SYMBOL-VALUE
    need an environment arg after all.

    Dave, do you buy that analysis?  If so, I'll propoduce a proposal along
    the lines of what Larry sent out.

I don't buy the analysis at all for SPECIAL-FORM-P.  I feel less strongly
about SYMBOL-FUNCTION and SYMBOL-VALUE, but I think your analysis is still
wrong there, if only because of inline functions and constant "variables".

∂20-Apr-87  1448	Masinter.pa@Xerox.COM 	Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Apr 87  14:48:33 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 APR 87 14:39:25 PDT
Date: 20 Apr 87 14:39 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Mon, 20 Apr 87 17:20 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@sail.stanford.edu,
 DUSSUD%Jenner%ti-csl.CSNet@relay.cs.net
Message-ID: <870420-143925-1269@Xerox>

David,


Two things:

I can't imagine this proposal being adopted by X3J13 without some more
explaination, within the proposal itself, of how this proposal makes
CLOS easier. As it stands, it doesn't make the connection at all clear.

Second,  since there will be a technical editor and an oversight
committee concerned with exact wording, I think that there will be
objections to a vote on any proposal which mandates exact wording. Thus,
although your description is coherent, I think it needs to be explained
in terms of what happens to Common Lisp, rather than the words in which
it is described.  

I have no objection to the proposal itself. 

Thanks,

Larry

∂20-Apr-87  1358	Masinter.pa@Xerox.COM 	Re: Issue IF-BODY (Version 4)   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Apr 87  13:58:03 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 APR 87 13:50:22 PDT
Date: 20 Apr 87 12:07 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue IF-BODY (Version 4)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870420-135022-1113@Xerox>

I think we have discussed the pros and cons of this issue sufficiently,
to the point that it is counter-productive to repeat any of the
arguments.  We have also agreed that, even though a majority of the
committee does not like this proposal, we want to release it.  All we
need now is a version of the write-up which we can all agree to
distribute.

I support Scott's proposal for doing so, viz: "let KMP write up the
proposal, state his case at length in a `Discussion: Pro' section, and
let the loyal opposition have more or less equal space in a `Discussion:
Con' section."

Does anyone disagree?  I think it would be best if Kent and Scott can
get a copy together privately and then mail it out as Version 5, so that
we can get this one off the table and proceed with some of the other
issues. 

Thanks

Larry




∂20-Apr-87  1358	Masinter.pa@Xerox.COM 	Re: Issue: COMPILER-WARNING-STREAM (Revision 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Apr 87  13:58:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 APR 87 13:51:00 PDT
Date: 20 Apr 87 12:25 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: COMPILER-WARNING-STREAM (Revision 4)
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Mon,
 20 Apr 87 00:16 EDT
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870420-135100-1125@Xerox>

Kent and Scott have pointed out some of the difficulties of
incorporating Dussand's suggestion into this proposal. I suggest we
revert to the previous version of the proposal, and add a note in the
Discussion section that this proposal does further specify the behavior
of DRIBBLE because of the problems of the current under-specification of
DRIBBLE. 

We can independently consider proposals either to further specify (or to
broaden the possible behavior of) DRIBBLE, and relate it to
ERROR-OUTPUT.

OK?



∂20-Apr-87  1420	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 Apr 87  14:20:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 120087; Mon 20-Apr-87 17:20:41 EDT
Date: Mon, 20 Apr 87 17:20 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
To: CL-Cleanup@sail.stanford.edu
cc: Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>
Message-ID: <870420172029.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

Status: New (but see "adoption cost" below) issue.

Issue:        KEYWORD-ARGUMENT-NAME-PACKAGE
References:   Middle of p.60
	      First complete sentence on p.62
Category:     CLARIFICATION/CHANGE
Edit history: Revision 1 is the initial version. (Moon 4/20/87)

Problem Description:

CLtL says that only keyword symbols can be used as keyword names in &key
parameter specifiers.  This seems to imply (although it is not actually
a logical consequence) that only keyword symbols can be used as keyword
names in calls to functions that take keyword arguments.  (It is not a
logical consequence because the called function might have been
implemented a different way than with &key.)

Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)

Remove restrictions on the package of keyword argument names; allow
any symbol, including NIL."

In the middle of p.60, change "each -keyword- must be a keyword symbol,
such as :start" to "each -keyword- must be a symbol, such as :start".
Add these sentences: "Keyword symbols are most commonly used, but any
symbol is valid.  Non-keyword symbols are sometimes used to provide
isolation between packages, but unlike keywords they must be quoted by
callers of the function, making the syntax slightly less convenient.
NIL is a valid -keyword-, although it is unlikely that a stylish
programmer would choose to use it."  Be careful about where the italics
go in those sentences.

Change the last word in the first complete sentence on p.62 from
"keyword" to "symbol".

On p.64, add the following two examples to illustrate the explicit
keyword syntax:
((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
 => (1 2 6 NIL)
((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
 => (1 2 6 NIL)

Rationale:

If Common Lisp truly has a restriction that only keyword symbols can be
used as keyword names in calls to functions that take keyword arguments,
it will be more difficult to come up with an object-oriented programming
standard that fits within Common Lisp.

Current Practice:

Some implementations do not have the restriction that I propose to remove.
I don't know of any implementations that enforce the restriction, but
there might be one.

Some implementations have bugs that prevent NIL from working as a keyword
argument name, but allow all non-NIL symbols.  One Symbolics version that
I checked had this bug.

Adoption Cost:

No existing programs will stop working.  Some implementors might have to
rearrange their error checking slightly, but it should be very easy.

I was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but I may be wrong.

Benefits:

This will help with the object-oriented programming standard.

Conversion Cost:

None.

Aesthetics:

There will probably be an argument about whether the restriction is
more esthetic or less esthetic than the freedom, but in either case
the aesthetic effect is slight.

Discussion:

None yet.

∂20-Apr-87  1517	Masinter.pa@Xerox.COM 	status 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Apr 87  15:17:06 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 APR 87 15:17:01 PDT
Date: 20 Apr 87 15:17 PDT
From: Masinter.pa@Xerox.COM
Subject: status
To: cl-cleanup@sail.stanford.edu
Message-ID: <870420-151701-1366@Xerox>

We were asked at X3J13 not to batch up our proposals but to send them
out when ready. Can we send some out this week?

Here is my status file. Please mail corrections asap.


ADJUST-ARRAY-DISPLACEMENT (revision 1)
	Received but not discussed.
	Need volunteer to lead discussion, summarize positions.
	remailed 7-apr-87
	SEF volunteered to delegate.
	(I thought I saw a message from SEF discussing this but I 
	cannot find it.)  

COMPILER-WARNING-BREAK (revision 2)
	not Released.
	Questions on interaction with condition proposal.
	Defer to error/signal/condition committee? 
	remailed 7-apr-87
	SEF suggested KMP should work on.

COMPILER-WARNING-STREAM (Revision 4)
	Rev 3 was released
	Comment from Dussand, forwarded to cl-cleanup,
	SEF edited 15-Apr, incorporating dribble check & minor cleanup
	Revert to omit DRIBBLE specification? 

DEFVAR-INITIALIZATION (Revision 3)
	Released
	remailed 7-apr-87
	(final form)

DO-SYMBOLS-DUPLICATES (Revision 1)
	mailed 7-apr-87
	Revision 1 by SEF 17-apr
	Not released, in discussion
	Questions "is it really inefficient to require non-duplicates?"
	Add more arguments?

ENVIRONMENT-ARGUMENTS (revision 1)
	SEF volunteered to work over the proposal further.
	Mailed 7-apr-87
	SEF summarized issues 18-Apr
	(in question: add env arguments to SPECIAL-FORM-P etc)

FLET-IMPLICIT-BLOCK (Revision 5)
	Discussion & agreement on cl-cleanup.
	revision by Fahlman, 17-Apr-87 to cl-cleanup
	
FORMAT-ATSIGN-COLON (Revision 3)
	Released.
	(final form, mailed 17-Apr-87)

FORMAT-OP-C (revision 1)
	Discussed and agreed, final form not yet available
	(with Moon's amendment)
	Need volunteer.

FUNCTION-TYPE (revision 2)
	General agreement on basic proposal.
	Wording to be worked out.
	Mailed 17-Apr-87
	Fahlman volunteered to revise & run by RPG

IF-BODY (Version 4)
	General agreement to recommend against.
	Final form not yet available.
	Version 4 mailed by KMP , 19-Apr-87
	Debate over proposal summary: how to balance pro & con?


IGNORE-ERRORS
	Discussed and agreed, final form not yet available
	(LMM: Some objections, defer to error/signal committee?)
	Need volunteer.

IMPORT-SETF-SYMBOL-PACKAGE (Revision 3)
	Released
	Should remove confusing "To further clarify: " which is
	about INTERN and not IMPORT.

KEWYWORD-ARGUMENT-NAME-PACKAGE (Version 1)
	Submitted by Moon 20 Apr 87.
 
PEEK-CHAR-READ-CHAR-ECHO
	Agreed to be controversial
	Need volunteer to summarize positions.


PRINC-CHARACTER:WRITE-CHAR
	Discussed and agreed, final form not yet available
	(write-char choice)
	Need volunteer.

PROMPT-FOR
	Agreed to be controversial
	Need volunteer to summarize positions.

REMF-DESTURCTION-UNSPECIFIED
	Not discussed
	Need volunteer to check over, lead discussion.

SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
	(Should FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
	Tabled, a subset which deals with only those functions that
	don't work in positions will be separated out.
	Need volunteer.

SHARPSIGN-BACKSLASH-BITS
	No general agreement (the meeting notes read "we cringed")
	Need volunteer to summarize positions.

SHARPSIGN-PLUS-MINUS-NUMBER
	Discussed, without general agreement.
	Need volunteer to summarize positions.

SHARPSIGN-PLUS-MINUS-PACKAGE
	Discussed, without general agremenet.
	Need volunteer to summarize positions.

TAILP-NIL
	Received but not discussed
	Need volunteer to lead discussion, summarize positions.

UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
	Discussed and agreed, final form not yet available

∂20-Apr-87  1653	Masinter.pa@Xerox.COM 	Re: Issue ADJUST-ARRAY-DISPLACEMENT  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Apr 87  16:53:13 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 APR 87 16:54:12 PDT
Date: 20 Apr 87 16:54 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue ADJUST-ARRAY-DISPLACEMENT
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Sun,
 19 Apr 87 21:03 EDT
To: Fahlman@C.CS.CMU.EDU
cc: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <870420-165412-1492@Xerox>

I found the message. Sorry for the confusion.

ADJUST-ARRAY-DISPLACEMENT should be marked with status "Revision 1 by SEF, 18-Apr-87".

Is there any discussion?




∂20-Apr-87  1911	FAHLMAN@C.CS.CMU.EDU 	Issue: COMPILER-WARNING-STREAM (Revision 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Apr 87  19:10:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 20 Apr 87 22:11:49-EDT
Date: Mon, 20 Apr 1987  22:11 EDT
Message-ID: <FAHLMAN.12296150451.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Masinter.pa@XEROX.COM
Cc:   cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: COMPILER-WARNING-STREAM (Revision 4)
In-reply-to: Msg of 20 Apr 1987  15:25-EDT from Masinter.pa at Xerox.COM


Yes, I support reverting to the previous version of
Compiler-Warning-Stream (with no mention of Dribble) and that we
consider some fix to Dribble as a separate item.

-- Scott

∂21-Apr-87  0400	jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	Re: Re:  Bignums are bogus?   
Received: from CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 21 Apr 87  03:59:28 PDT
Received: from aiva.edinburgh.ac.uk by mv1.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa00334; 20 Apr 87 18:23 WET
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Mon, 20 Apr 87 19:21:25 GMT
Message-Id: <21105.8704201921@aiva.ed.ac.uk>
To: common-lisp@sail.stanford.edu
Subject: Re: Re:  Bignums are bogus?

> From: Richard Fateman <fateman@edu.berkeley.mike>
> The point about bignums is that you don't have to check for them
> overflowing, because they don't.  Something more dreadful happens first.
> That's why 64bit or 1kbit bignums are no good.

I agree.  Bignums should be analogous to lists; representation based
sublimits on size are acceptable only if they are so large that they are
like running out of memory.  True, arrays and floats have size limits for
individual objects, but why should bignums be analogous to arrays and not
to lists?  Page 13 of Steele says "storage is automatically allocated as
necessary".

It's beginning to seem that this discussion may be even longer than the one
of compiling CASE, perhaps because it's more trivial :-).

∂21-Apr-87  0747	FAHLMAN@C.CS.CMU.EDU 	Environment-Arguments  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Apr 87  07:47:30 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 21 Apr 87 10:48:28-EDT
Date: Tue, 21 Apr 1987  10:48 EDT
Message-ID: <FAHLMAN.12296288180.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   cl-cleanup@SAIL.STANFORD.EDU
Subject: Environment-Arguments


        Macros sometimes need to
        expand other macros at compile time so that they can do SETF-like
        things...

    I don't think the last sentence follows.  The argument that leads up to it
    is an argument that MACROEXPAND and MACROEXPAND-1 need to take an environment
    argument.  They already do.

Right.  I was confused (as usual).  Let me take another crack at this.

First, I think that the issues should be re-separated, as they were
originally.  I don't think the part about adding an environment argument
to GET-SETF-METHOD is controversial.  Also, the business about whether
special forms and other such things can be shadowed should be broken out
into a separate proposal that we can discuss on its own merits; we don't
seem to share the same assumptions here.

That leaves the old MACRO-FUNCTION-ENVIRONMENT proposal.  As Moon points
out, what macros really need to do is call MACROEXPAND on forms (or
parts of forms) that the user passes in; MACROEXPAND needs an
environment arg in order to do this, and it has one already.

The original MACRO-FUNCTION-ENVIRONMENT proposal contains the following
example:

(defmacro example (form &environment environment)
   (let ((macro (macro-function (car form) <environment> ))
      (when macro .... (funcall macro form) ...)

where the <environment> arg to MACRO-FUNCTION is not currently legal but
would be under the proposal.  SETF-like forms need to do something like
the above code: check whether the form is a macro in the current lexical
context and, if so, expand it.  Note, however, that instead of calling
MACRO-FUNCTION and then maybe FUNCALL, you could just let MACROEXPAND do
the whole job.  The original Clisp designers, in their infinite wisdom,
decided that if you call MACROEXPAND on somehting not currently a macro,
it just returns the argument with a second value of NIL (meaning "not a
macro after all").

So I no longer see any motivation at all for MACRO-FUNCTION-ENVIRONMENT,
nor for adding an environment arg to SYMBOL-FUNCTION, etc.  There may
well need to be some new machinery set up to deal with the aliasing
problem -- macros that change their meaning when executed in certain
lexical contexts -- but that is a big problem that is in the hands of
another committee, and we should do nothing until we see a comprehensive
proposal on how to handle macros elegantly in a lexical world.

If nobody can come up with a coherent argument for
MACRO-FUNCTION-ENVIRONMENT, I propose we drop this, approve the SETF
part of the proposal, and move on.

∂21-Apr-87  0814	Hvatum.DLAB@MIT-MULTICS.ARPA 	"Redefining" functions   
Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87  08:13:49 PDT
Date:  Tue, 21 Apr 87 01:02 EDT
From:  Hvatum@MIT-MULTICS.ARPA
Subject:  "Redefining" functions
To:  common-lisp@SAIL.STANFORD.EDU
Message-ID:  <870421050242.558425@MIT-MULTICS.ARPA>

From: Steve Bacher (Draper Lab)
 
  From:  Jim Kempf <kempf%hplabsc at HPLABS.HP.COM>
  Subject:  Re: Redefinition of Common Lisp Functions
  To:  common-lisp at SAIL.STANFORD.EDU
 
  I guess I need to clarify my comments. I see two competing needs here:
 
  1) On the one hand, system vendors and applications distributors
  require the option of not allowing users to redefine Common
  Lisp functions. Allowing users to do so makes supplying safe,
  good quality software difficult because regression testing becomes next to
  impossible.
 
  2) On the other, researchers and people prototyping advanced
  applications might want to modify the semantics of certain
  Common Lisp functions for experimental purposes.
 
I had in mind a third need:
 
3) User specifying a function whose name happens to conflict with the
   name of an already existing LISP function, not with the intent of
   changing the behavior of the LISP function, but with the purpose of
   defining a new function for use with that user's code only.
 
The user may not know that the function already exists, and therefore
will not qualify or shadow it wrt the package system or use FLET.
 
Even if a non-used function name is chosen, who is to say that CL
version II won't chew up that name and (depending on the implementation)
break this guy's system?
 
Conceivably the LISP system could be compiled so that calls to any
built-in CL functions are done in a special "fast-call" way which
bypasses actually referencing the function cells of those symbols.
(Especially true for inline code.)  Of course, this has the effect
of making CommonLOOPS-style function-redefining impossible, but
there ought to be other solutions to that problem.  Which is the
subject of another discussion that I don't feel qualified to
participate in.
 
                                        - SEB
 
≠

∂21-Apr-87  0814	Hvatum.DLAB@MIT-MULTICS.ARPA 	Compiling CASE 
Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87  08:13:14 PDT
Date:  Tue, 21 Apr 87 01:02 EDT
From:  Hvatum@MIT-MULTICS.ARPA
Subject:  Compiling CASE
To:  common-lisp@SAIL.STANFORD.EDU
Message-ID:  <870421050209.453617@MIT-MULTICS.ARPA>

From: Steve Bacher (Draper Lab)
 
  From: Rob MacLachlan <RAM at C.CS.CMU.EDU>
 
      The package system will not protect Common LISP from having
      its functions redefined, since a user who wants to define
      his/her own CAR function will likely not call it USER:CAR;
      thus, since there is already a CAR in the LISP package, that's
      the one that will get defined.
 
  This is what SHADOW is for.
 
But the point is that it still requires a specific user action which
presumes knowledge that a built-in CL function is being redefined,
be it explicit package prefixing or use of SHADOW.
 
   ...it is not reasonable to redefine system functions.
 
True.  However, if a programmer uses a name like ENCODE-UNIVERSAL-TIME
as a "local" function (in the Franz sense?), such that the compiler
doesn't make its definition globally available, this should be no
problem.  I guess FLET is the solution here.  Otherwise, the LISP
system should probably issue a warning, and possibly rename the
function internally (where possible).
 
I do not have in mind "redefining" CL functions in the sense of
changing the behavior of pieces of the LISP system that use them.
Rather, I mean defining new functions which happen to have names that
are the same as existing CL functions.  If the system is set up so as
to protect itself properly from having pieces of itself suddenly
change their behavior, there should be no problem.  I think that if
guidelines similar to those above are followed, programs that define
functions with the same names as CL functions (NOT "redefine" those
functions) can be portable.
 
One more point:  If you say that portability precludes
implementation-dependent constructs, then we no longer have different
CL-compatible implementations - just a single CL implementation with
different code generators for different hardware.  Maybe this is what
we all REALLY want.  Who knows?
 
   Of course internal compiler representations are highly
   implementation dependent, but this isn't necessarily a problem.
   One of the main things that source code walkers have been used
   for is writing "optimizing macros" for non-optimizing compilers.
   As long as the compiler adequately optimizes the code, macros can
   expand in a simple-minded way without understanding their
   arguments.
 
Let's not try to unload the total optimizing burden on the compiler.
Surely there are situations where a macro is in a far better position
to know how to optimize a particular construct than the compiler,
whose job is to optimize the general cases.
 
Also, as far as internal representation of source code is concerned,
no matter how fancy your compiler is, there's always got to be a
phase where real source code is analyzed and converted to whatever
internal form you like.  Certainly transformations can be invoked
at that level.  What's more, user-written transformations necessarily
operate on the source code, unless a LISP implementation is required
to make its compiler's internal representation open for manipulation.
 
                                                  - SEB
 
≠

∂21-Apr-87  0918	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue ADJUST-ARRAY-DISPLACEMENT  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87  09:18:25 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 120118; Mon 20-Apr-87 17:51:49 EDT
Date: Mon, 20 Apr 87 17:51 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue ADJUST-ARRAY-DISPLACEMENT
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12295875812.BABYL@C.CS.CMU.EDU>
Message-ID: <870420175130.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

Unlike many of the other issues being discussed, this is one on which
I might be expected to have an opinion.

Current practice: Symbolics implements what is proposed, except for

    (4) A is displaced to B before the call, but not displaced afterward.  A
    gets a new "data region", and contents of B are copied into it as
    appropriate to maintain the existing old contents; additional elements
    of A are taken from the :initial-element.

We never copy the contents of B in this case; all elements are taken from
the :initial-element.

Either behavior seems equally justifiable to me.  One could say
"adjust-array never stores into the array if it ends up displaced" or
"adjust-array only preserves the elements of non-displaced arrays."  I
have no information as to whether it matters to users.

∂21-Apr-87  0919	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: FLET-IMPLICIT-BLOCK (Revision 5)    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87  09:19:32 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 120124; Mon 20-Apr-87 18:02:02 EDT
Date: Mon, 20 Apr 87 18:01 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FLET-IMPLICIT-BLOCK (Revision 5)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12295308952.BABYL@C.CS.CMU.EDU>
Message-ID: <870420180149.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

I approve, let's release this.

∂21-Apr-87  0920	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Environment-Arguments  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87  09:19:59 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 120130; Mon 20-Apr-87 18:13:24 EDT
Date: Mon, 20 Apr 87 18:13 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Environment-Arguments
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12295628211.BABYL@C.CS.CMU.EDU>
References: <870407-174210-2710@Xerox>
Supersedes: <870420140356.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870420181313.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

[This is a revised version of my previous missive, revised after
reading the referenced message, which was From: Masinter.pa@Xerox.COM
Subject: Issue: ENVIRONMENT-ARGUMENTS (Revision 1)]

    Date: Sat, 18 Apr 1987  22:23 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    In mail several months ago, Moon said that he agreed with adding an
    optional environment argument to MACRO-FUNCTION, but that for
    consistency we should also add such an argument to SPECIAL-FORM-P,
    SYMBOL-FUNCTION, and SYMBOL-VALUE.

    I think that this is wrong.  (Masinter apparently does too, but I'll
    speak for myself.)  

    This facility isn't designed for writing debuggers; it is meant to allow
    macro-expanding macros to operate properly.  Macros sometimes need to
    expand other macros at compile time so that they can do SETF-like
    things.  In accessing some otehr macro's definition, a macro should take
    cognizance of any MACROLET definitions and of lexical function
    definitions that might shadow a macro definition.  Therefore, they need
    to be able to call MACRO-FUNCTION with an environment arg.

I don't think the last sentence follows.  The argument that leads up to it
is an argument that MACROEXPAND and MACROEXPAND-1 need to take an environment
argument.  They already do.  So the real reason for giving MACRO-FUNCTION
an environment arg must be something else; I forget what the reason given
a few months ago was, but I remember that I thought it applied equally well
to those other operations.

The reason for changing MACRO-FUNCTION given in the 2nd referenced
message is for macros that do their own macroexpansion, calling the
macro expander function directly instead of going through MACROEXPAND. 
I think that that is a separate issue from fixing SETF so that it can
pass the correct arguments to MACROEXPAND-1 for macros defined with
MACROLET, and should be proposed/debated separately.

    I don't think macros need to get at function definitions and values in
    the same way.  Function definitions do not have to be available at
    compile time, nor do values.  And special forms are immutable: they
    cannot be redefined, so presumably they cannot be shadowed either.

I see no such restriction (special forms cannot be shadowed) in CLtL.
Adding such a restriction seems like a poor idea in view of the third
paragraph on page 57.  In any case, it would be a poor idea to make
MACRO-FUNCTION and SPECIAL-FORM-P behave inconsistently with respect to
the lexical environment, because that could lead to a large body of user
code with the restriction that special forms cannot be shadowed wired
into its structure, and that in turn would make it difficult to lift
such a restriction, either in the language definition or in individual
implementations.  A little forethought now will save a peck of trouble
later.

    (Larry proposes to make this explicit as part of this proposal; I would
    prefer to make it a separate proposal, but agree with the
    clarification.)

    So I don't believe that SPECIAL-FORM-P, SYMBOL-FUNCTION, or SYMBOL-VALUE
    need an environment arg after all.

    Dave, do you buy that analysis?  If so, I'll propoduce a proposal along
    the lines of what Larry sent out.

I don't buy the analysis at all for SPECIAL-FORM-P.  I feel less strongly
about SYMBOL-FUNCTION and SYMBOL-VALUE, but I think your analysis is still
wrong there, if only because of inline functions and constant "variables".
I feel that MACRO-FUNCTION should be discussed together with SPECIAL-FORM-P,
SYMBOL-FUNCTION, and SYMBOL-VALUE, and should be discussed separately from
GET-SETF-METHOD, GET-SETF-METHOD-MULTIPLE-VALUE, and DEFINE-SETF-METHOD.

I'm strongly opposed to burying
  Clarify that it is an error to use FLET/LABELS/MACROLET on any of the
  symbols defined in CLtL as designating special forms.
in the middle of another proposal; it should be proposed and discussed
on its own (lack of) merits.  The 2nfd referenced message incorporates
a message from me explaining why I think this proposal is unworkable.

∂21-Apr-87  0921	KMP@STONY-BROOK.SCRC.Symbolics.COM 	IF-BODY  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87  09:20:53 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 120149; Mon 20-Apr-87 19:08:48 EDT
Date: Mon, 20 Apr 87 19:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IF-BODY
To: Fahlman@C.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12296016150.BABYL@C.CS.CMU.EDU>
Message-ID: <870420190818.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Funny you objected to my changing the (IF test then (PROGN {else}*))
to (COND (test then) (T {else}*)). I did that to help your case. I
consider the former to be so ugly that I never use it in any code, while
I don't find COND to be so ugly that I wouldn't sometimes use it. I
was honestly trying to keep things as balanced as possible. I guess
the situation is just very complicated and requires both rewrites to
be illustrated...

By the way, I was surprised that the copy I was working with (done by
Masinter) had left out Fahlman's IF-BODY:NO suggestion, but I assumed
that I had just mis-remembered what we discussed at the in-person
meeting and that we'd decided for some reason not to make ballot items
for proposals that amount to the status quo...

I'm happy to work with you on a revised proposal that feels balanced
as suggested in today's mail from Masinter. Why don't you send me 
something privately which you think feels more balanced -- ie, factor
back in the earlier arguments in a way you feel comfortable with and
we'll go from there, reporting back to the committee when we're in 
agreement.
-kmp

∂21-Apr-87  1051	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87  10:51:23 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 120687; Tue 21-Apr-87 13:50:53 EDT
Date: Tue, 21 Apr 87 13:50 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870420-143925-1269@Xerox>
Message-ID: <870421135040.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 20 Apr 87 14:39 PDT
    From: Masinter.pa@Xerox.COM

    I can't imagine this proposal being adopted by X3J13 without some more
    explanation, within the proposal itself, of how this proposal makes
    CLOS easier. As it stands, it doesn't make the connection at all clear.

Do you really think that's appropriate?  If you do, I'll try to write some,
but I didn't think cleanup proposals were supposed to contain that sort of
discussion.  Maybe it would be better to remove all reference to CLOS and
simply say that there are applications both existing and proposed that use
packaged (i.e. non-keyword) symbols as &key argument names?  Or would it
be better to leave in the specific reference to CLOS?

    Second,  since there will be a technical editor and an oversight
    committee concerned with exact wording, I think that there will be
    objections to a vote on any proposal which mandates exact wording. Thus,
    although your description is coherent, I think it needs to be explained
    in terms of what happens to Common Lisp, rather than the words in which
    it is described.  

I didn't mean to imply that that was mandated wording, only sample wording.
What I was really trying to do was to enumerate the places in the book
that would have to change.

I'll send out a revision 2 after this discussion converges.

∂21-Apr-87  1155	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Environment-Arguments  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87  11:55:39 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 120808; Tue 21-Apr-87 14:55:46 EDT
Date: Tue, 21 Apr 87 14:55 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Environment-Arguments
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12296288180.BABYL@C.CS.CMU.EDU>
Message-ID: <870421145535.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 21 Apr 1987  10:48 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    If nobody can come up with a coherent argument for
    MACRO-FUNCTION-ENVIRONMENT, I propose we drop this, approve the SETF
    part of the proposal, and move on.

That sounds good to me.

∂21-Apr-87  1215	FAHLMAN@C.CS.CMU.EDU 	IF-BODY 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Apr 87  12:14:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 21 Apr 87 15:15:51-EDT
Date: Tue, 21 Apr 1987  15:15 EDT
Message-ID: <FAHLMAN.12296336858.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:   CL-Cleanup@SAIL.STANFORD.EDU
Subject: IF-BODY
In-reply-to: Msg of 20 Apr 1987  19:08-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>


I'm leaving town for a week, starting in about 20 minutes.  In my view a
balanced presentation would consist of your version of the proposal, and
for discussion the long statement you included in the last version, plus
the rebuttal I sent out a day or two ago.  If you're willing to leave it
at that, fine; else we'll have to iterate until someone gives up and
lets the other guy have the last word.  rather than stall the process,
I'm happy to let someone else from the CON camp do the iterating in my
absence.

-- Scott

∂21-Apr-87  1222	FAHLMAN@C.CS.CMU.EDU 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Apr 87  12:21:53 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 21 Apr 87 15:22:46-EDT
Date: Tue, 21 Apr 1987  15:22 EDT
Message-ID: <FAHLMAN.12296338085.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
In-reply-to: Msg of 21 Apr 1987  13:50-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


        I can't imagine this proposal being adopted by X3J13 without some more
        explanation, within the proposal itself, of how this proposal makes
        CLOS easier. As it stands, it doesn't make the connection at all clear.

    Do you really think that's appropriate?  If you do, I'll try to write some,
    but I didn't think cleanup proposals were supposed to contain that sort of
    discussion.  Maybe it would be better to remove all reference to CLOS and
    simply say that there are applications both existing and proposed that use
    packaged (i.e. non-keyword) symbols as &key argument names?  Or would it
    be better to leave in the specific reference to CLOS?

Whether you reference CLOS or just give a random example, I think some
sort of example is needed.  I couldn't imagine a good reason for this
change.  Keywords don't interfere with one another, so modularity is not
the issue in any obvious way, and I'm not sympathetic to making a change
just because some people would rather type 'FOO than :FOO.  I'm sure
you've got a good reason for proposing this, and I'd like some
indication of what it is.

-- Scott

∂21-Apr-87  1253	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87  12:53:28 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 120916; Tue 21-Apr-87 15:52:23 EDT
Date: Tue, 21 Apr 87 15:51 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
To: Fahlman@C.CS.CMU.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12296338085.BABYL@C.CS.CMU.EDU>
Message-ID: <870421155153.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

I have had applications which for various reasons I can't go
into in detail where I needed to have a keyword which no one
but myself would use. That is,

 (DEFUN FOO (&KEY ((PRIVATE-KEYWORD VAR) default) ...)
   ...)

I'm much happier about this than about

 (DEFUN FOO (&KEY ANYONE-OTHER-THAN-KMP-WHO-USES-THIS-KEYWORD-DESERVES-TO-LOSE)
   ...)

I support allowing keyword designators to be in other than the keyword package.

∂21-Apr-87  1303	goldman@vaxa.isi.edu 	MULTIPLE-VALUES, consing, and clarity 
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 21 Apr 87  13:03:26 PDT
Received: by vaxa.isi.edu (4.12/4.7)
	id AA03718; Tue, 21 Apr 87 12:04:52 pst
Message-Id: <8704212004.AA03718@vaxa.isi.edu>
Date: 21 Apr 1987 1204-PST (Tuesday)
To: COMMON-LISP@SAIL.STANFORD.EDU
From: goldman@VAXA.ISI.EDU
Subject: MULTIPLE-VALUES, consing, and clarity
Cc: goldman@VAXA.ISI.EDU

I'm sure this must have been suggested long ago, but I'd at least like
to know why it is not part of common lisp:

From the point of view of writing clear code, as well as just good old
symmetry, it seems unfortunate that we have the richness of LAMBDA-LISTs
to pass information from calling environments into functions, but
only the impoverished
 (MULTIPLE-VALUE-BIND Var* values-form  ...) for communication in
the reverse direction.  I have found numerous cases where my code
would be much clearer if I could write
  (MULTIPLE-VALUE-BIND LAMBDA-LIST values-form  ...), using
&rest, &key, and &optional receive parameters to help me "destructure"
the information coming back from values-form -- including default
values for optional parameters.

I bring this up (again?) now only because of recent discussions
about multiple values and consing. If I could write
  (multiple-value-bind (&rest values) values-producer
    (cond ((test values) (values-list values))
	  ...))

a good compiler could recognize that there was no need to cons up a list
of values only to spread (a tail of) the list back onto the stack.


[Of course, this is NOT upward compatible with the current
multiple-value-bind, since the current one allows a mismatch
between the number of variables being bound and the number of
values being returned.  How did THAT find its way into the specification,
anyway?  I suppose its an attempt to reduce the need for
multiple-value-list when you don't know how many values might come back?]

The main objection I see to allowing a lambda list is with maintenance --
adding additional return values from a function F could invalidate calls
on F that were not prepared to accept (even if only to ignore) them.  

∂21-Apr-87  1425	@DIAMOND.S4CC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	MULTIPLE-VALUES, consing, and clarity    
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 21 Apr 87  14:25:13 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by DIAMOND.S4CC.Symbolics.COM via INTERNET with SMTP id 78601; 21 Apr 87 17:24:18 EDT
Date: Tue, 21 Apr 87 17:24 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: MULTIPLE-VALUES, consing, and clarity
To: goldman@VAXA.ISI.EDU, COMMON-LISP@SAIL.STANFORD.EDU
In-Reply-To: <8704212004.AA03718@vaxa.isi.edu>
Message-ID: <870421172431.7.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

    Date: 21 Apr 1987 1204-PST (Tuesday)
    From: goldman@VAXA.ISI.EDU

    I'm sure this must have been suggested long ago, but I'd at least like
    to know why it is not part of common lisp:

MULTIPLE-VALUE-CALL.  (Naively, MULTIPLE-VALUE-BIND is a macro that
turns into MULTIPLE-VALUE-CALL with a lambda-list of
	(&optional ,@varlist &rest ignore)
]


∂21-Apr-87  1506	Pavel.pa@Xerox.COM 	Re: MULTIPLE-VALUES, consing, and clarity    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Apr 87  15:06:51 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 APR 87 15:07:53 PDT
Date: 21 Apr 87 15:07 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: MULTIPLE-VALUES, consing, and clarity
In-reply-to: goldman@VAXA.ISI.EDU's message of 21 Apr 87 12:04 PST
 (Tuesday)
To: goldman@VAXA.ISI.EDU
cc: COMMON-LISP@SAIL.STANFORD.EDU
Message-ID: <870421-150753-2649@Xerox>

If you want to say

   (MULTIPLE-VALUE-BIND LAMBDA-LIST values-form  ...)

you can always say instead

  (multiple-value-call #'(lambda LAMBDA-LIST ...) values-form)

The proverbial good compiler can still do the optimization you
mentioned.  If you don't like the syntax (and who could blame you), you
could always make a macro for it.

	Pavel

∂21-Apr-87  1450	Pavel.pa@Xerox.COM 	[Gregor.pa: Re: ["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>: 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Apr 87  14:50:36 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 APR 87 13:54:46 PDT
Date: 21 Apr 87 13:54 PDT
From: Pavel.pa@Xerox.COM
Subject: [Gregor.pa: Re: ["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>:
 Environment-Arguments]]
To: CL-Cleanup@SAIL.Stanford.Edu
cc: Gregor.pa@Xerox.COM
Message-ID: <870421-135446-2536@Xerox>

I asked Gregor what he thought about not giving the environment argument
to macro-function.  This is his response.

	Pavel

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

Date: 21 Apr 87 13:18 PDT
From: Gregor.pa
Subject: Re: ["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>:
Environment-Arguments]
In-reply-to: Pavel.pa's message of 21 Apr 87 12:12 PDT
To: Pavel.pa
cc: Gregor.pa

Well I would have to see the macros committe stuff (whenever that gets
done) to know for sure, but even macro-function-environment is less than
you really need.  You also need to be able to build the env arg to
macroexpand-1.  The screw case is a macro which is so hairy that it
needs to be able to take an environment, and then macroexpand its body
in an environment which is "slightly different" than that environment.
The problem is that macroexpanding, in general, means yielding control
over who gets to do the macroexpansion to some other code.  That other
code might call macroexpand itself and so it must be able to provide a
suitable second argument.


Here is the canonical example:

(defmacro my-hairy-macro (&body body &environment e)
  (walk-form body e#'(lambda ...)))

my hairy macro is a macro like with-slots which needs to walk its body,
macroexpanding the whole thing and perhaps replacing parts of it.  Like
many macros, it needs to take the environment argument in because it is
going to have to call macroexpand on its body to work.

But this macro passes its environment to the walker.  In order to do its
job, the walker is going to have to be able to augment that environment
structure and be able to pass it back to macroexpand.  The rest of the
example is.

(defmacro foo () ''loser)

(my-hairy-macro
  (macrolet ((foo () ''winner))
    (my-hairy-macro
       (foo))))

When the walker "walks down into" the body of the macrolet, it needs to
be able to make a new lexical environment which includes the previous
lexical environment plus a (in this case new) definition for FOO.


Perhaps a nice thing would be for the second argument to macroexpand to
really be a function, this function (if supplied) is the actual
macroexpansion function to call.  These functions would be lexical
closures over what we now think of as the environment.  People could use
standard lexical closure techniques for augmenting environments.  The
combination language for 'building' environments would be Lisp, it would
be a win for all the standard reasons.

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

∂21-Apr-87  1655	Moon@STONY-BROOK.SCRC.Symbolics.COM 	MULTIPLE-VALUES, consing, and clarity 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87  16:54:53 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 121218; Tue 21-Apr-87 19:54:57 EDT
Date: Tue, 21 Apr 87 19:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: MULTIPLE-VALUES, consing, and clarity
To: goldman@VAXA.ISI.EDU
cc: COMMON-LISP@SAIL.STANFORD.EDU
In-Reply-To: <8704212004.AA03718@vaxa.isi.edu>
Message-ID: <870421195424.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

This was discussed at enormous length early in the design of Common Lisp.
Most of the mail discussions, draft manuals, and ballots have been archived,
so if you really care that much, it's possible to reconstruct the discussion.
I'll just say here that at one time MULTIPLE-VALUE-BIND did allow & keywords,
but it was changed.

∂21-Apr-87  1659	Moon@STONY-BROOK.SCRC.Symbolics.COM 	[Gregor.pa: Re: ["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>:    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87  16:59:02 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 121221; Tue 21-Apr-87 19:59:11 EDT
Date: Tue, 21 Apr 87 19:58 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [Gregor.pa: Re: ["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>:
         Environment-Arguments]]
To: Pavel.pa@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.Edu, Gregor.pa@Xerox.COM
In-Reply-To: <870421-135446-2536@Xerox>
Message-ID: <870421195859.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

What I read from Gregor's comments (as well as our own similar experiences) is
that merely adding an optional argument to macro-function is not enough.  To
support the full generality of code walkers, it would be necessary to define
standard operations for manipulating lexical environments, making them more
"first class" than at present in Common Lisp, where they can be passed around
but their structure is undefined.  I would hope that we could do this in an
abstract way, so that lexical environments were not constrained to be
implemented in one particular way.

This sounds like a fine thing, but a little beyond the scope of the cleanup
committee.

∂21-Apr-87  2309	MURRAY%cs.umass.edu@RELAY.CS.NET 	MULTPLE-VALUE-OR &rest args    
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 21 Apr 87  23:09:30 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ab26960; 22 Apr 87 2:07 EDT
Received: from cs.umass.edu by RELAY.CS.NET id bl27373; 22 Apr 87 1:58 AST
Date:     Tue, 21 Apr 87 15:45 EDT
From:     MURRAY%cs.umass.edu@RELAY.CS.NET
To:       common-lisp@SAIL.STANFORD.EDU
Subject:  MULTPLE-VALUE-OR &rest args
X-VMS-To: CLMAIL


    >I think more to the heart of the matter is that Common LISP needs a way to grab,
    >inspect, and pass on an unknown number of multiple values without consing
    > (and yes, avoiding consing can be crucial for real applications
    > give the current state of the art for garbage collection
    > on conventional hardware).  It's possible that, using
    >multiple-value-call, simply having some way of 
    >doing non-consing &rest arguments may be sufficient.   ...

    I whole-heartly agree that A) Unneccessary consing should always be avoided,
     B) it would be great to have &rest args that don't cons.
    I currently have plans to have a STACK-LIST declaration that declares that
    a &Rest is stack-allocated (as well as WITH-STACK-LIST, ala Lisp Machines)
    in my system.  I would suggest that others consider this as well, but
    of course, it is only a declaration that could be ignored.
    (I already avoid consing for (&Rest ignore), which should be easy).

    My point is that MULTIPLE-VALUE-OR can only be done efficiently by low-level
    implementation-specific code, and thats why it should be in Common Lisp.

 >I don't think this conclusion follows from your previous paragraph.
 >If the proposed MULTIPLE-VALUE-OR can easily be implemented in terms of
 >existing primitives, such as MULTIPLE-VALUE-CALL, and would be efficient
 >if there were non-consing &rest arguments, and non-consing &rest arguments
 >are desirable for other reasons, then I think a more logical conclusion is
 >"because non-consing &rest arguments can only be done efficiently by low-level
 >implementation-specific code, they should be in Common Lisp."

Are you just pointing out a flaw in my logic, or are you suggesting that
Common Lisp REQUIRE certain &rest args to not cons?  The last sentence
was not meant to logically follow from the previous -- I was merely
re-iterating my point in requesting a MULTIPLE-VALUE-OR form, which is it
can be efficiently implemented WITHOUT non-consing rest args.  I might
also add that using MULTIPLE-VALUE-CALL is going to require both 
a Lambda and a Block, in which the Return-From will end up being a Throw.
It might not Cons, but I wouldn't call that "Efficient" (Maybe Symbolics does
function calls and throws more efficiently than a couple tests and a branch?
If so, that is exactly why it should be in Common Lisp -- You do it your way,
I'll do it mine).

 >By the way, I don't think a declaration for non-consing &rest arguments
 >should be necessary.  It should be simple enough for any compiler to
 >recognize special cases such as the following, once implementors'
 >attention has been drawn to the desirability of such optimizations.  Another
 >way of saying the same thing is that I think consing is an implementation
 >issue, not a language issue, just as much as whether integer multiplication
 >takes 1 microsecond or 10 microseconds.

 >  (lambda (&rest values)
 >    (when (first values)
 >      (return-from block (values-list values))))

I guess you are saying Common Lisp shouldn't REQUIRE any &rest args not to cons.
I certainly agree - it is properly in the domain of Optimizations.  A declaration
may not be always be necessary, but this is just about in the same category
as determining whether a function has side-effects.  You can sometimes prove
it doesn't, but why go to all the bother if a very knowledgable and intelligent
(compared to a compiler) programmer can simply tell you?

- Kelly Murray

∂22-Apr-87  1116	rauen@CLS.LCS.MIT.EDU 	Streams
Received: from CLS.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Apr 87  11:16:37 PDT
Received: by CLS.LCS.MIT.EDU (4.12/4.7); Wed, 22 Apr 87 12:55:04 est
From: rauen@CLS.LCS.MIT.EDU (James R. Rauen)
Message-Id: <8704221755.AA00926@CLS.LCS.MIT.EDU>
Date: 22 Apr 1987 1254-EST (Wednesday)
To: common-lisp@sail.stanford.edu
Subject: Streams


I'm encountering some difficulties with synonym streams.  Let's say I
do the following:

	(defvar a *standard-input*)
	(defvar b *standard-output*)
	(defvar c (make-synonym-stream 'a))
	(defvar d (make-synonym-stream 'b))
	(defvar e (make-two-way-stream c d))
	(setq a *standard-output*)

Now stream C has been turned into an output stream.  What is E now?
What does it answer to INPUT-STREAM-P?  I can also cause trouble by
changing the value of a synonym stream's variable from a character
stream to a byte stream.

		--Jim

∂22-Apr-87  1232	KMP@STONY-BROOK.SCRC.Symbolics.COM 	ASSOC-RASSOC-IF-KEY (Version 1)   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Apr 87  12:32:27 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 121957; Wed 22-Apr-87 15:14:43 EDT
Date: Wed, 22 Apr 87 15:14 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ASSOC-RASSOC-IF-KEY (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: GLS@Think.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870422151450.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        ASSOC-RASSOC-IF-KEY
References:   ASSOC-IF (p280), ASSOC-IF-NOT (p280), RASSOC-IF (p281),
	      RASSOC-IF-NOT (p281)
Category:     CLARIFICATION/ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
Status:       For Internal Discussion

Problem Description:

  The descriptions of ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF, and RASSOC-IF-NOT
  do not mention a :KEY option.

Proposal (ASSOC-RASSOC-IF-KEY:YES):

  Allow a :KEY keyword for ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF, and RASSOC-IF-NOT.
  If not supplied, it should default to #'IDENTITY as do the :KEY keywords
  for other -IF and -IF-NOT functions.

Rationale:

  All the other -IF and -IF-NOT variations of list operations omit the
  :TEST and :TEST-NOT keywords, but allow :KEY. For example, consider
  the family of MEMBER, MEMBER-IF, and MEMBER-IF-NOT. The omission of
  :KEY in this situation in CLtL was probably an oversight.

Current Practice:

  The Symbolics implementation went ahead and added :KEY.
  I suspect that implementations are split down the middle on
  whether this is offered.

Adoption Cost:

  A small amount of additional code is necessary to support this in 
  implementations not already offering it as an extension.

Benefits:

  This would make the set of -IF and -IF-NOT functions be more regular in
  their calling conventions.

Conversion Cost:

  The change is essentially upward compatible with user code.

Aesthetics:

  Although this introduces additional mechanism, it does so in a way that
  probably makes it easier to think about which functions do what, so it
  would likely be seen as a simplification.

Discussion:

  KMP supports this change/clarification.

∂22-Apr-87  1343	KMP@STONY-BROOK.SCRC.Symbolics.COM 	AREF-1D  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Apr 87  13:43:20 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 122090; Wed 22-Apr-87 16:42:48 EDT
Date: Wed, 22 Apr 87 16:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: AREF-1D
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870422164300.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        AREF-1D
References:   Arrays (pp286-298)
Category:     ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY
  efficiently in Common Lisp because they take arguments of varying
  arity. Currently, you have to make a displaced array to work with
  temporarily and then throw away the displaced array when you're done.
  In the case of FILLARRAY, I find this bothersome because there is no
  a priori reason why FILLARRAY should have to cons at all.

Proposal (AREF-1D:YES):

  Introduce a new function AREF-1D which allows 1D access to the storage
  backing up a given array assuming the normal row-major storage layout.

  This accessor should be valid for use with SETF.

Rationale:

  We already document the row-major storage layout and have a number of
  operators which allow users to exploit that order. This would be a 
  useful addition.

  LISTARRAY and FILLARRAY, for example, could be trivially defined by
  loops which had the following form:

    (DOTIMES (I (ARRAY-TOTAL-SIZE ARRAY))
      ... (AREF-1D ARRAY I) ...)

  Currently, the only really efficient way to write this involves
  something like:

    (ECASE (ARRAY-RANK ARRAY1)
      ((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
      ((1) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
	     (SETF (AREF ARRAY1 I) (AREF ARRAY2 I))))
      ((2) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
	     (DOTIMES (I (ARRAY-DIMENSION ARRAY 1))
	       (SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
      ...some finite number of clauses...)

Current Practice:

  Many implementations have this primitive under some other name
  for use internally. In Symbolics systems, for example, it is SYS:%1D-AREF.

Adoption Cost:

  This change is fairly localized. In implementations which already use
  this primitive internally, it's little more than a matter of changing the
  name of or otherwise releasing the existing primitive. In some implementations,
  it might involve writing a small amount of code (and associated compiler
  optimizers).

Benefits:

  This gives users efficient access to something which they already have
  inefficient access to.

Conversion Cost:

  This is an upward-compatible change.

Aesthetics:

  I think this allows certain programs to be written in a more aesthetic way.

Discussion:

  KMP supports this change.

∂22-Apr-87  1351	KMP@STONY-BROOK.SCRC.Symbolics.COM 	ADJUST-ARRAY-NOT-ADJUSTABLE  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Apr 87  13:51:32 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 122107; Wed 22-Apr-87 16:51:08 EDT
Date: Wed, 22 Apr 87 16:51 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ADJUST-ARRAY-NOT-ADJUSTABLE
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870422165116.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        ADJUST-ARRAY-NOT-ADJUSTABLE
References:   ADJUST-ARRAY (p297)
Category:     ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  The description of ADJUST-ARRAY on pp297-298 says that it is ``not permitted
  to call ADJUST-ARRAY on an array that was not created with the :ADJUSTABLE
  option.''

Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:OK):

  Change the definition of ADJUST-ARRAY to say that any array is a valid argument.
  Say that if the array is not adjustable or if its old rank is not compatible
  with the newly specified rank, then a new array will be created and returned.

  In the case where a new array is returned, an implementation is permitted to
  (but not required to) recycle the storage backing up that array if it is also
  willing to do appropriate error checking to assure that AREFs to that array 
  will signal an error. In other words, the actual pointer to the array cannot
  be reclaimed unless the compiler can prove that there are no pointers to it
  and if the array is not reclaimed, references through it must not point to
  recycled storage. [Note: I'm flexible on this, but it seems about right. I'm
  patterning this after `dead arrays' in Maclisp. --KMP]

  As with other destructive operations (most of which have names starting with
  the letter "N"), users would be encouraged to use this for value wherever
  possible and would be told that they can rely on the array to be adjusted
  `for effect' only when it was adjustable and the new rank matched the old.

Rationale:

  ADJUST-ARRAY offers features which are offered by no other function and which
  are useful in cases involving non-adjustable arrays (for what amounts to copying).
  This change would allow an expression such as:

    (SETQ X (ADJUST-ARRAY X ...))

  to work reliably. Those desiring the old behavior could do:

    (IF (OR (NOT (ADJUSTABLE-ARRAY-P X))
	    (NOT (EQUAL (ARRAY-RANK X) (LENGTH NEW-DIMENSIONS))))
        (ERROR "Array cannot be adjusted."))
  
  to get the old style error checking.

Current Practice:

  Probably no one implements this extension.

Adoption Cost:

  Although this change is not trivial, it is localized and would probably not
  require an excessive amount of work to install. Probably most of the necessary
  routines already exist and it's just a matter of offering an interface.

Benefits:

  In cases where a user would want to adjust an array but the array is not
  adjustable, he may well decide to try to simulate the contract of 
  ADJUST-ARRAY in copying the array. This can be tedious and may be error
  prone. It would be better for such code to be written once, efficiently 
  and uniformly, and then offered to the user in a well-packaged way.

Conversion Cost:

  No correct user code currently tries to modify arrays which are 
  non-adjustable, so this change is technically upward compatible.

  Some advanced code-walking tools which believe that this function 
  works only by side-effect would have to be modified very slightly
  to know that its return value was of interest.

Aesthetics:

  I'm not sure how people's sense of aesthetics is affected by this.

Discussion:

  MACSYMA needed something like this.

  If people don't like this, I could construct an alternate variation of
  this proposal which involved the introduction of a new COPY-ARRAY 
  primitive that took an input array and some combination of the args
  now allowed by MAKE-ARRAY and ADJUST-ARRAY. The variation above seemed
  the simplest to me, but the presence of a COPY-ARRAY such as described
  in this paragraph would also have satisfied my needs.

∂22-Apr-87  2307	Moon@STONY-BROOK.SCRC.Symbolics.COM 	UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Apr 87  23:07:45 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 122478; Thu 23-Apr-87 02:08:00 EDT
Date: Thu, 23 Apr 87 02:07 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Hornig@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <870227172152.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870423020745.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

Larry's status report says that this issue has been agreed, and that the
answer is 1c and 2c (in the terminology of the referenced message), that
is, the throw that invoked the unwind-protect is abandoned and the new
throw takes place, regardless of whether the target of the new throw is
dynamically inside or equal-to-or-outside-of the target of the original
throw.

I never agreed to this, and I think you are overlooking something.  I
went back through the old discussion and couldn't find any discussion of
this issue: Consider the form

  (loop
    (catch 'foo
      (unwind-protect (loop)
        (throw 'foo t))))

With the proposed semantics, it is impossible to stop this program
except by hitting it with two throws in rapid succession, with exactly
the right amount of delay between them so that the catch and
unwind-protect have not yet been re-established when the second throw
strikes.  Consider any program-stopping operation that aborts execution
by throwing to a catch in the top-level read-eval-print loop (control-G
in Maclisp or c-Abort in Genera; most other systems have their own
equivalent of this).  With the proposed semantics, when this throw
executes the unwind-protect cleanup handler, as it must, the throw will
be abandoned and execution will resume looping.

To me, the inability to stop a program is a much worse problem than
providing so-called correct semantics for a contrived program that
doesn't correspond to any real application.  It was suggested that the
error system might depend on the ability to abort throws like this.  If
that were demonstrated, I would change my tune, but until it's
demonstrated I am completely skeptical of the notion that any error
system would do this.

Therefore I propose that case 1, transfer to a point inside the point to
which control would have transferred, not do the second throw.  There
are two things we could require it to do instead (or we could just
wimping out and say it "is an error").  It could signal an error, or
it could resume the original throw, just as if the cleanup handler had
exited normally.  I prefer signalling an error, because I firmly believe
that the program is ill-formed.  Note that signalling an error must
avoid the following pitfall once an error-handling facility is added to
Common Lisp:

  (loop
    (ignore-errors
      (unwind-protect (loop)
        (error))))

The illegal-nested-throw error must not be caught by ignore-errors or
nothing will have been solved.

At a minimum I would like to see these considerations included in the
discussion section of the issue file before it is released.  Not all
readers of the file will immediately realize that option (1c) installs
a serious environment bug into Common Lisp.

∂23-Apr-87  1205	smith@nrl-aic.ARPA 	A simple question   
Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87  12:05:27 PDT
Return-Path: <smith@nrl-aic.ARPA>
Received: Thu, 23 Apr 87 14:05:35 est by nrl-aic.ARPA id AA10064
Date: 23 Apr 1987 13:42:18 EST (Thu)
From: Russ Smith <smith@nrl-aic.ARPA>
Subject: A simple question
To: common-lisp@sail.stanford.edu
Cc: spears@nrl-aic.arpa
Message-Id: <546201738/smith@nrl-aic>

The "Cc"ed individual above uncovered an interesting difference between
interpreted and compiled CommonLisp on a Sun workstation that generated
a splurge of conversation here. In particular:

	(null (null '(a b c))

returns T when interpreted, but returns (a b c) when compiled. On
reading the **Sun** CommonLisp manual, this behavior, while possibly
despicable, is permitted. On reading THE CommonLisp manual, things are
not quite as obvious. Page 73 contains a definition for NULL that may
or may not say that NULL returns strictly T or NIL (see also page 82).

What's the poop?

∂23-Apr-87  1250	Moon@STONY-BROOK.SCRC.Symbolics.COM 	A simple question 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87  12:50:15 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123106; Thu 23-Apr-87 15:50:29 EDT
Date: Thu, 23 Apr 87 15:50 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: A simple question
To: Russ Smith <smith@NRL-AIC.ARPA>
cc: common-lisp@sail.stanford.edu, spears@NRL-AIC.ARPA
In-Reply-To: <546201738/smith@nrl-aic>
Message-ID: <870423155015.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 23 Apr 1987 13:42:18 EST (Thu)
    From: Russ Smith <smith@nrl-aic.ARPA>

    The "Cc"ed individual above uncovered an interesting difference between
    interpreted and compiled CommonLisp on a Sun workstation that generated
    a splurge of conversation here. In particular:

	    (null (null '(a b c))

    returns T when interpreted, but returns (a b c) when compiled.

My question for you:  Does (not (null '(a b c)) do the same thing in the
same implementation, or does it always return T?

∂23-Apr-87  1255	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	A simple question   
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 23 Apr 87  12:55:02 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79392; Thu 23-Apr-87 15:54:33 EDT
Date: Thu, 23 Apr 87 15:54 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: A simple question
To: Russ Smith <smith@NRL-AIC.ARPA>, common-lisp@sail.stanford.edu
cc: spears@NRL-AIC.ARPA
In-Reply-To: <546201738/smith@nrl-aic>
Message-ID: <870423155440.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

    Date: 23 Apr 1987 13:42:18 EST (Thu)
    From: Russ Smith <smith@nrl-aic.ARPA>

    Page 73 contains a definition for NULL that may
    or may not say that NULL returns strictly T or NIL (see also page 82).

    What's the poop?

Page 73 says several things.  It says NULL returns true if the argument
is ().  To me at least, this implies NULL is used for flow/predicate and
not for value.  It goes on to say that NULL is the same as NOT.  NOT
(page 82) explicitly says NOT returns T or NIL.  It also says NULL is
the same as NOT.  If you believe in transitive closure, one would
conclude that (null (null something)) returns strictly T or NIL.  Poor
programs may be broken by this; better programs never use (null (null
...)) but instead express the better intent (not (null ...)).

Personally, I would consider (null (null ...)) to be "an error" and that
the compiler for the Sun should be able to get away with returning the
inner argument.  Things get worse when you separate nil and ().

∂23-Apr-87  1313	REM@IMSSS 	Just for fun (NULL of NULL is identity)
Received: from IMSSS by SAIL with PUP; 23-Apr-87 13:13 PDT
Date: 23 Apr 1987 1310-PDT
From: Rem@IMSSS
Subject: Just for fun (NULL of NULL is identity)
To:   COMMON-LISP@SU-AI

That "despicable" behaviour of NULL on the SUN when compiled,
namely that (NULL (NULL 'FOO)) returns FOO instead of T,
could have been obtained interpreted too if something like this
had been done:

(SETQ G*NON-NULL-VALUE 'T) ;Initial value

(DEFUN MY-NULL (LL)
  (COND (LL (PROGN (SETQ G*NON-NULL-VALUE LL)
		   'NIL))
	(T G*NON-NULL-VALUE)))

Does CLtL explicitly forbid this? I don't think so. It defines "true"
as anything not NIL, and says NULL is "true" if it argument is ().
But it *does* say that (null x) is the same as (eq x '()), so
presumably if you hack NULL then EQ must be hacked too, and
also typep.
-------

∂23-Apr-87  1822	RWK@YUKON.SCRC.Symbolics.COM 	A simple question   
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87  18:22:01 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 198073; Thu 23-Apr-87 21:09:50 EDT
Date: Thu, 23 Apr 87 21:09 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: A simple question
To: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: Russ Smith <smith@NRL-AIC.ARPA>, common-lisp@sail.stanford.edu,
    spears@NRL-AIC.ARPA
In-Reply-To: <870423155440.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Message-ID: <870423210941.6.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

    Date: Thu, 23 Apr 87 15:54 EDT
    From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
    Page 73 says several things.  It says NULL returns true if the argument
    is ().  To me at least, this implies NULL is used for flow/predicate and
    not for value.  It goes on to say that NULL is the same as NOT.  NOT
    (page 82) explicitly says NOT returns T or NIL.  It also says NULL is
    the same as NOT.  If you believe in transitive closure, one would
    conclude that (null (null something)) returns strictly T or NIL.  Poor
    programs may be broken by this; better programs never use (null (null
    ...)) but instead express the better intent (not (null ...)).

    Personally, I would consider (null (null ...)) to be "an error" and that
    the compiler for the Sun should be able to get away with returning the
    inner argument.  Things get worse when you separate nil and ().

I disagree; after all, NOT is the same as NULL.
(NOT (NULL <something)) has long been an idiom for
"always return T or NIL".

I'll bet the Sun compiler does the same thing for
(NOT (NULL <something>))?

∂23-Apr-87  1858	KMP@STONY-BROOK.SCRC.Symbolics.COM 	A simple question  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87  18:58:27 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123583; Thu 23-Apr-87 21:57:24 EDT
Date: Thu, 23 Apr 87 21:57 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: A simple question
To: smith@NRL-AIC.ARPA, spears@NRL-AIC.ARPA
cc: RWK@STONY-BROOK.SCRC.Symbolics.COM,
    DCP@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp@SAIL.STANFORD.EDU
In-Reply-To: <870423210941.6.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <870423215712.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Some miscellaneous observations on this issue...

In my opinion, it is not appropriate to document that NOT and NULL are the
same even if they have identical behavior. If their intended uses differ
(as I would claim they do), they are not interchangeable. Perhaps we can
get this wording fixed in the upcoming manual. People should use NULL for
lists and not for predicates as a matter of style. Although (NULL (NULL x))
is not "an error" in the CLtL sense, I'd put red marks next to it if I were
teaching a programming course and someone turned in a program that did it.

By the way, there are GC implications to returning the thing itself and not
T. If the x was a large structure that was not otherwise pointed to, it
would be a shame for it to not get GC'd just because someone was passing
it around for truth value.

Also, there are data abstraction issues. You run the risk of accidentally
violating the integrity of private data structures if you give them away,
and the compilers should be leary of optimizations that can do this kind
of thing.

In T (Yale Scheme), we actually created a whole line of operators called
MEMBER?, ASSOC?, etc. which were like MEMBER, ASSOC, etc. but returned
T/NIL for cases where abstraction and/or GC behavior was an issue.

On the LispM, this optimization would be particularly funny for stack lists
since I guess you could claim that a stack list could `rightly' be returned
here (it being non-null, after all, regardless of what its ever-varying
contents were). If you never used it for anything other than its existence
and non-nullness...

This optimization, by the way, is related to the (+ X 0) => X optimization,
which can be pretty bizarre error-checking-wise when X is a string or some
other non-addable quantity and SAFETY is high (because no error may get
signalled where the intuition may be that one should be). Presumably the
next CL standard should take some stand on optimizations like this so that
users can know what to expect (or know to expect nothing) and implementors
can know what to feel comfortable about providing.

∂23-Apr-87  2022	RWK@YUKON.SCRC.Symbolics.COM 	Streams   
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87  20:22:00 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 198124; Thu 23-Apr-87 23:22:02 EDT
Date: Thu, 23 Apr 87 23:21 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Streams
To: James R. Rauen <rauen@CLS.LCS.MIT.EDU>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8704221755.AA00926@CLS.LCS.MIT.EDU>
Message-ID: <870423232136.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

    Date: 22 Apr 1987 1254-EST (Wednesday)
    From: rauen@CLS.LCS.MIT.EDU (James R. Rauen)

    I'm encountering some difficulties with synonym streams.  Let's say I
    do the following:

	    (defvar a *standard-input*)
	    (defvar b *standard-output*)
	    (defvar c (make-synonym-stream 'a))
	    (defvar d (make-synonym-stream 'b))
	    (defvar e (make-two-way-stream c d))
	    (setq a *standard-output*)

    Now stream C has been turned into an output stream.  What is E now?
Illegal.  It's first argument is required to be an input stream.

    What does it answer to INPUT-STREAM-P?  
Probably T, in in many implementations.  NIL if it
actually checks its input stream.
					    I can also cause trouble by
    changing the value of a synonym stream's variable from a character
    stream to a byte stream.
Sure.  CL gives you enough rope to hang yourself.

∂23-Apr-87  2338	edsel!bhopal!jonl@navajo.stanford.edu 	A simple question    
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Apr 87  23:38:15 PDT
Received: by navajo.stanford.edu; Thu, 23 Apr 87 22:37:32 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
	id AA25848; Thu, 23 Apr 87 22:26:02 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
	id AA06964; Thu, 23 Apr 87 23:23:38 PDT
Date: Thu, 23 Apr 87 23:23:38 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704240623.AA06964@bhopal.edsel.com>
To: navajo!smith%nrl-aic.ARPA@navajo.stanford.edu
Cc: navajo!common-lisp%sail@navajo.stanford.edu,
        navajo!spears%nrl-aic.arpa@navajo.stanford.edu
In-Reply-To: Russ Smith's message of 23 Apr 1987 13:42:18 EST (Thu)
Subject: A simple question

What is the version number of your Sun Common Lisp ?  try calling
(lisp-implementation-version), or look at the initial greeting.

Version 2 (and it's follow-ons) has been current since December 1986,
and doesn't have the pessimization you reported, namely that
(not (not x)) ==> x.   Version 1 appears to have the problem.

As has often been remarked, "The source of all bugs is pre-mature
optimization."

-- JonL --

∂24-Apr-87  0741	decvax!cvbnet!admin!tbardasz@decwrl.DEC.COM 	Mailing List   
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 24 Apr 87  07:39:50 PDT
Received: from decvax.dec.com by decwrl.dec.com (5.54.3/4.7.34)
	id AA28946; Fri, 24 Apr 87 06:40:48 PST
Received: from admin.uucp (mcae) by cvbnet.uucp (2.0/SMI-2.0)
	id AA02955; Fri, 24 Apr 87 10:16:40 est
Received: by admin.uucp (1.1/SMI-3.0DEV3)
	id AA13156; Fri, 24 Apr 87 10:12:41 EST
Date: Fri, 24 Apr 87 10:12:41 EST
From: decvax!cvbnet!admin!tbardasz@decwrl.DEC.COM (Ted Bardasz)
Message-Id: <8704241512.AA13156@admin.uucp>
To: cvbnet!decvax!decwrl!SAIL.STANFORD.EDU!COMMON-LISP@decwrl.DEC.COM
Subject: Mailing List


Hello,
     Could you please add me to the mailing list for:

	COMMON LISP

     My mail address is:
	decvax!cvbnet!basie!tbardasz@decwrl.dec.com

     Thank you very much,
	Ted Bardasz at Computervision Corp.

∂24-Apr-87  0752	smith@nrl-aic.ARPA 	Re: A simple question    
Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 24 Apr 87  07:52:09 PDT
Return-Path: <smith>
Received: Fri, 24 Apr 87 06:19:15 est by nrl-aic.ARPA id AA01286
Date: 24 Apr 1987 06:01:42 EST (Fri)
From: Russ Smith <smith@nrl-aic.ARPA>
Subject: Re: A simple question
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: spears@nrl-aic.arpa, common-lisp@sail.stanford.edu
Message-Id: <546260502/smith@nrl-aic>
In-Reply-To: David A. Moon's message of Thu, 23 Apr 87 1550 EDT

(not (null '(a b c)) returns the correct value (CLtL definition of
NOT, not Sun's...which, though apparently returning the correct value,
is not documented entirely correctly).

But this does not answer the question of what NULL is supposed to
return. The definition given on page 73 is arguably ambiguous. What
does "same operation" mean? Is this equivalence (one is just an alias
for the other)? Or is it merely a way of saying that the functionality is
somewhat similar as far as various interesting things are concerned?

Note, for example, that the TYPEP and EQ triple-line equivalences given
below the definition return true or false, not T or NIL.

I remain perplexed.

∂24-Apr-87  0843	DALY@IBM.COM 	CLtL typos list 
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 24 Apr 87  08:42:59 PDT
Date: 24 April 1987, 11:26:11 EDT
From: Timothy Daly <DALY@ibm.com>
To:   common-lisp@sail.stanford.edu
Message-Id: <042487.112612.daly@ibm.com>
Subject: CLtL typos list

To those who have asked, yes there is a CLtL typos list.
The header on the file says the directory is:

/u/gis/tl/sla/corr.txt dated 12/6/85

My copy has been IBMeroxed through so many generations that it is
almost unreadable. From the GIS in the pathname I assume the
source is Guy Steele and I believe his tent is still pitched at CMU.

Guy, if you receive this, is there a later version?

Tim Daly
DALY@IBM.COM

∂24-Apr-87  2307	coffee@aerospace.aero.org 	Re: A simple question  
Received: from AEROSPACE.AERO.ORG by SAIL.STANFORD.EDU with TCP; 24 Apr 87  23:07:25 PDT
Received: by aerospace.aero.org (5.54/6.0.GT)
	id AA08928; Fri, 24 Apr 87 22:53:56 PST
Posted-Date: Fri, 24 Apr 87 22:53:47 -0800
Message-Id: <8704250653.AA08928@aerospace.aero.org>
To: Russ Smith <smith@nrl-aic.ARPA>
Cc: common-lisp@sail.stanford.edu
Subject: Re: A simple question
In-Reply-To: Your message of 23 Apr 1987 13:42:18 EST (Thu).
             <546201738/smith@nrl-aic>
Date: Fri, 24 Apr 87 22:53:47 -0800
From: coffee@aerospace.aero.org

Page 71 of CLtL resolves any ambiguity on page 73 when it says, "We say that
a predicate is true when it returns a non-nil value, and is false when it
returns nil..."; thus <wry grin> implementors are free to let an expression
like (null (null 'foo)) return GRAND_PIANO if they wish, but portability-
oriented programmers are _not_ free to assume anything but non-nilness in
the returned value.

Personally, NUMBERP is the one that bothers me: it would be so nice to get
back the argument if it is numeric, nil otherwise, but CLtL merely says that
the value will be "true" and this is all that one may safely assume. Saying,
as CLtL does, that (numberp x) is identical (as in three horizontal bars) to
(typep x 'number) even tends to _suggest_ that the value _will_ be strictly
T or nil, a loss in my opinion.

Thanks for bringing this up--rationalization of this issue may be worth
fighting for in the ANSI Common Lisp committee's "clean-up of Steele" phase.

                                                              - Pc↑2

∂25-Apr-87  0052	VERACSD@A.ISI.EDU 	Pronunciation   
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 25 Apr 87  00:51:48 PDT
Date: 24 Apr 1987 23:01-EDT
Sender: VERACSD@A.ISI.EDU
Subject: Pronunciation
From: VERACSD@A.ISI.EDU
To: common-lisp@SAIL.STANFORD.EDU
Cc: veracsd@A.ISI.EDU
Message-ID: <[A.ISI.EDU]24-Apr-87 23:01:01.VERACSD>

What is the proper pronunciation of PROG?

∂25-Apr-87  2132	@po5.andrew.cmu.edu:zs01#@andrew.cmu.edu 	Re: Pronunciation 
Received: from PO5.ANDREW.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Apr 87  21:32:38 PDT
Received: by po5.andrew.cmu.edu (5.54/3.15) id <AA00915> for common-lisp@SAIL.STANFORD.EDU; Sun, 26 Apr 87 00:33:24 EDT
Received: via switchmail; Sun, 26 Apr 87 00:33:21 edt
Received: FROM z.itc.cmu.edu VIA queuemail
          ID </cmu/common/mailqs/q007/QF.z.itc.cmu.edu.20918de2.40>;
          Sun, 26 Apr 87 00:32:36 edt
Received: FROM z.itc.cmu.edu VIA qmail
          ID </cmu/itc/zs01/.Outgoing/QF.z.itc.cmu.edu.20918d57.d57bad>;
          Sun, 26 Apr 87 00:30:17 edt
Message-Id: <QUYMpKy00Vs8yuk0J8@andrew.cmu.edu>
X-Trace: MS Version 3.22 on ibm032 host z.itc.cmu.edu, by zs01 (623).
Date: Sun, 26 Apr 87 00:30:14 edt
From: zs01#@andrew.cmu.edu (Zalman Stern)
To: common-lisp@SAIL.STANFORD.EDU
Subject: Re: Pronunciation
Cc: veracsd@A.ISI.EDU
In-Reply-To: <[A.ISI.EDU]24-Apr-87 23:01:01.VERACSD>

>>>>What is the proper pronunciation of PROG?

Rhymes with "frog". And most code (with the exception of macro expansions)
that uses them should croak.

Sincerely,
Zalman Stern


∂25-Apr-87  2341	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Pronunciation 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 25 Apr 87  23:41:34 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 124696; Sun 26-Apr-87 02:41:53 EDT
Date: Sun, 26 Apr 87 02:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Pronunciation
To: zs01#@andrew.cmu.edu
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <QUYMpKy00Vs8yuk0J8@andrew.cmu.edu>
Message-ID: <870426024148.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Could we please terminate this discussion before it leads to a rush of
useless mail. I'm sure there are as many people who would suggest that
`the other' pronunciation is better. It doesn't matter who's right.

This mailing list reaches a huge number of people, many of whom are quite
busy. Also, many mailers get bogged down a long time delivering each
piece of mail sent. It's not worth the time spent either by the
mailers or by the readers of the mail to debate issues which have such
a large potential for going on forever, so little chance of being 
usefully resolved, and so little value even if resolved.

∂27-Apr-87  1008	unido!gmdzi!LISPM-1.GMD!@lispm-1.gmd.jc 	Pronunciation 
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 27 Apr 87  10:08:21 PDT
Received: from unido.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP 
	id AA04143; Mon, 27 Apr 87 13:08:25 EDT
Received: by unido.uucp with uucp; 
	  Mon, 27 Apr 87 18:03:36 +0100
Received: by gmdzi.UUCP id AA16067; Mon, 27 Apr 87 15:35:30 -0100
Date: Mon, 27 Apr 87 15:34+0100
From: "Juergen Christoffel" <unido!gmdzi!LISPM-1!JC@seismo.CSS.GOV>
Subject: Pronunciation
To: common-lisp@sail.stanford.edu
Cc: KMP@stony-brook.scrc.symbolics.com
In-Reply-To: <870426024148.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870427153401.6.JC@LISPM-1.GMD>

    Date: Sun, 26 Apr 87 02:41 EDT
    From: "Kent M Pitman" <KMP%STONY-BROOK.SCRC.Symbolics.COM%unido@gmdzi>

    Could we please terminate this discussion before it leads to a rush of
    useless mail. [...]

    This mailing list reaches a huge number of people, many of whom are quite
    busy. [...]

Kent, I agree. And, *please*, all of you listeners: when composing a
reply, think twice before yanking in the whole message which spawned
your reply. I don't need the original message that many times sent to
me; normally it should be sufficient, to quote a part of it.  So,
please, stop this annoying habbit.

Thank you, JC

∂27-Apr-87  1110	Moon@STONY-BROOK.SCRC.Symbolics.COM 	MULTPLE-VALUE-OR &rest args 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 27 Apr 87  11:09:38 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 125233; Mon 27-Apr-87 14:05:18 EDT
Date: Mon, 27 Apr 87 14:04 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: MULTPLE-VALUE-OR &rest args
To: MURRAY%cs.umass.edu@RELAY.CS.NET
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: The message of 21 Apr 87 15:45 EDT from MURRAY%cs.umass.edu@RELAY.CS.NET
Message-ID: <870427140455.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date:     Tue, 21 Apr 87 15:45 EDT
    From:     MURRAY%cs.umass.edu@RELAY.CS.NET

     >I don't think this conclusion follows from your previous paragraph.
     >If the proposed MULTIPLE-VALUE-OR can easily be implemented in terms of
     >existing primitives, such as MULTIPLE-VALUE-CALL, and would be efficient
     >if there were non-consing &rest arguments, and non-consing &rest arguments
     >are desirable for other reasons, then I think a more logical conclusion is
     >"because non-consing &rest arguments can only be done efficiently by low-level
     >implementation-specific code, they should be in Common Lisp."

    Are you just pointing out a flaw in my logic, or are you suggesting that
    Common Lisp REQUIRE certain &rest args to not cons?  

I was suggesting that a declaration which, like all declarations,
encourages but does not require the compiler to generate a certain kind
of code, could be added to Common Lisp.  If it were added, it would be
more broadly applicable than MULTIPLE-VALUE-OR, and would eliminate the
need for MULTIPLE-VALUE-OR as a special language construct since it
would make the portable definition of MULTIPLE-VALUE-OR efficient.

							 The last sentence
    was not meant to logically follow from the previous -- I was merely
    re-iterating my point in requesting a MULTIPLE-VALUE-OR form, which is it
    can be efficiently implemented WITHOUT non-consing rest args.  I might
    also add that using MULTIPLE-VALUE-CALL is going to require both 
    a Lambda and a Block, in which the Return-From will end up being a Throw.

You are assuming that (multiple-value-call #'(lambda ...) ...) cannot be compiled
as efficiently as ((lambda ...) ...).  I see no justification for assuming that.

∂27-Apr-87  1119	coffee@aerospace.aero.org 	Cleaning up predicate returns    
Received: from AEROSPACE.AERO.ORG by SAIL.STANFORD.EDU with TCP; 27 Apr 87  11:18:48 PDT
Received: by aerospace.aero.org (5.54/6.0.GT)
	id AA10100; Mon, 27 Apr 87 11:15:03 PDT
Posted-Date: Mon, 27 Apr 87 11:14:52 -0800
Message-Id: <8704271815.AA10100@aerospace.aero.org>
To: common-lisp@sail.stanford.edu
Cc: Masinter.pa@xerox.com
Subject: Cleaning up predicate returns
Date: Mon, 27 Apr 87 11:14:52 -0800
From: coffee@aerospace.aero.org


> From: Masinter.pa@xerox.com
> Subject: Re: A simple question
> To: coffee@aerospace.aero.org

> If this were to be "cleaned up", in which way should it go?

> Should NOT, NULL, EQ and friends be required to return T or NIL always,
> rather than the less-specified "true" and NIL? Would this adversely
> affect performance? Are there any current implementations which don't
> return T or NIL for predicates?

I haven't put together a complete clean-up proposal yet, part of which
would certainly be discussion of implementation costs (regarding which
I have a bit of research to do!).

We have to be able to take the type of a NIL, and to recognize NIL as a
symbol, etc., so we can't realistically have (for example) ATOM return
its argument if true and NIL otherwise.

With CONSP, NUMBERP, STRINGP, INTEGERP, and all of the other predicates on
CLtL 74-76 except LISTP & COMMONP, however, there's no ambiguity in returning
the argument if true and NIL otherwise. I have grown accustomed to this
behavior in the ExperTelligence Lisps, and have to remind myself when writing
code that I'll need to port that this "filter" view of a predicate (as
opposed to the traditional "Boolean" view) is not portable at this time. We
have certainly grown used to the filter treatment of AND and OR, so I don't
think we're Boolean bigots here, and requiring this would not break code
unless it does things like testing for EQness to T instead of just using the
returned value as the Boolean.

The only argument I can see for _requiring_ return of strictly T or NIL, 
in these cases or in all of the currently indeterminate cases -- and
it may be a good argument at that -- is that it promotes portability by
preventing programmer reliance on a discretionary implementation that might,
for example, have LISTP return the object if it is a non-empty list and return
merely T for the empty list (nil otherwise). I don't favor this as standard
behavior, since LISTP could then return either a list or the T atom as
"true," meaning that code would need to check for each and be just
as ugly (or worse) than if return is limited (or assumed to be limited) to
T or NIL strictly.

I stress that this is a "wouldn't it be nice if," based on my own ideas of
what makes good-looking code, _not_ yet researched to the point that I call
it a "proposal." The extent to which I get flamed will probably determine
whether it dies immediately :-).  I've run it past one other Lisper here
and been "Boolean bashed": he thought this style much less readable.
Of course, no one would _have_ to use the value as anything but a Boolean.

Regards, Pc↑2

∂27-Apr-87  1206	larus@paris.Berkeley.EDU 	(reduce #'or ...)  
Received: from [128.32.150.46] by SAIL.STANFORD.EDU with TCP; 27 Apr 87  12:06:26 PDT
Received: by paris.Berkeley.EDU (3.2/1.22)
	id AA22811; Mon, 27 Apr 87 12:06:56 PDT
From: larus@paris.Berkeley.EDU (James Larus)
Message-Id: <8704271906.AA22811@paris.Berkeley.EDU>
To: common-lisp@sail.stanford.edu
Subject: (reduce #'or ...)
Date: Mon, 27 Apr 87 12:06:52 PDT

I use REDUCE quite frequently and recently ran across a strange
interaction between it and another CL feature.  I was trying to
execute:

	(reduce #'or (mapcar ...))

The problem is that OR is a macro, not a function, so that the idiom
#'OR is disallowed by some (all?) Lisps.  Even if the idiom was legal,
REDUCE could not funcall OR.

I can always define my own OR function, which is strict in both
arguments, but that does not really fix the problem.  I doubt that I
am the first or last person to stumble across this interaction.

I'd like to suggest to the committee cleaning up CL that they try
unraveling the multiple semantics given to OR and AND.  I think that
the language would be cleaner if logical operations were seperated
from control-flow.

/Jim

∂27-Apr-87  1338	quiroz@rochester.arpa 	Re: (reduce #'or ...) 
Received: from CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 27 Apr 87  13:38:16 PDT
Received: by cayuga.cs.rochester.edu (5.52/a) id AA05810; Mon, 27 Apr 87 16:37:37 EDT
Received: from loopback by ur-seneca.arpa id AA08517 (4.12z); Mon, 27 Apr 87 16:37:26 edt
Message-Id: <8704272037.8517@ur-seneca.arpa>
To: larus@paris.Berkeley.EDU (James Larus)
Cc: common-lisp@sail.stanford.edu
Subject: Re: (reduce #'or ...)
In-Reply-To: Your message of Mon, 27 Apr 87 12:06:52 PDT.
             <8704271906.AA22811@paris.Berkeley.EDU>
Date: Mon, 27 Apr 87 16:37:18 -0500
From: quiroz@rochester.arpa

I agree it is a bad surprise to rediscover that OR is not a
function, it happens to me rather often.

These days I rely on things like:
    (some #'<predicate> <sequence>)
whenever I feel like doing 
    (reduce #'or (mapcar #'<predicate> <sequence>)) 
I hope that is more or less what you need.  (The <predicate>s need
not be the same, needless is to say the example above is not a
mechanical equivalence.)
 
=Cesar
--------
Cesar Augusto  Quiroz Gonzalez
 
Department of Computer Science     {allegra|seismo}!rochester!quiroz
University of Rochester            or
Rochester,  NY 14627               quiroz@cs.rochester.edu

∂27-Apr-87  1340	coffee@aerospace.aero.org 	Very BIG "T" 
Received: from AEROSPACE.AERO.ORG by SAIL.STANFORD.EDU with TCP; 27 Apr 87  13:39:39 PDT
Received: by aerospace.aero.org (5.54/6.0.GT)
	id AA11832; Mon, 27 Apr 87 13:31:39 PDT
Posted-Date: Mon, 27 Apr 87 13:31:34 -0800
Message-Id: <8704272031.AA11832@aerospace.aero.org>
To: common-lisp@sail.stanford.edu
Subject: Very BIG "T"
Date: Mon, 27 Apr 87 13:31:34 -0800
From: coffee@aerospace.aero.org


> The only argument I can see for _requiring_ return of strictly T or NIL...
> is that it promotes portability...

Excuse me -- I missed the earlier message that observes how unpleasant
it would be to keep a big, otherwise unused object around merely because
it's being passed around as the non-NIL returned from a predicate. Good
point.

- Pc↑2


∂27-Apr-87  1517	Mailer@XX.LCS.MIT.EDU 	(reduce #'or ...)
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Apr 87  15:17:43 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 27 Apr 87 18:15-EDT
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 40029; 27 Apr 87 18:15:41-EDT
Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 34140; 27 Apr 87 16:44:00-EDT
Date: Mon, 27 Apr 87 16:45 EDT
From: Don Morrison <dfm@JASPER.PALLADIAN.COM>
Subject: (reduce #'or ...)
To: larus@paris.Berkeley.EDU
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8704271906.AA22811@paris.Berkeley.EDU>
Message-ID: <870427164540.5.DFM@WHITBY.PALLADIAN.COM>
Reply-To: Don Morrison <DFM%JASPER@LIVE-OAK.LCS.MIT.EDU>

    Date: Mon, 27 Apr 87 12:06:52 PDT
    From: larus@paris.Berkeley.EDU (James Larus)

    I use REDUCE quite frequently and recently ran across a strange
    interaction between it and another CL feature.  I was trying to
    execute:

	    (reduce #'or (mapcar ...))

Will using "some" solve your problems?  I believe that (some #'f L) is equivalent to
(reduce #'(lambda (x y) (or x y)) (mapcar #'f L) :initial-value nil), except that in most implementations it's faster and
conses less, so  long as f doesn't have side effects.

The fact that and and or only evaluate as many of their arguments as necessary is hardwired into most LISPers spines,
and many believe that using it as a control construct is often more perspicuous than the alternatives.  I think it most
unlikely that it'll be changed.


∂28-Apr-87  2212	MURRAY%cs.umass.edu@RELAY.CS.NET 	MULTIPLE-VALUES OR   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 28 Apr 87  22:12:17 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac13332; 29 Apr 87 1:05 EDT
Received: from cs.umass.edu by RELAY.CS.NET id ac04612; 29 Apr 87 1:02 EDT
Date:     Tue, 28 Apr 87 08:50 EDT
From:     MURRAY%cs.umass.edu@RELAY.CS.NET
To:       common-lisp@SAIL.STANFORD.EDU
Subject:  MULTIPLE-VALUES OR
X-VMS-To: CLMAIL


 The idea behind Multiple Values is that they are more efficient and 
 cleaner than the basic alternatives of returning a list, or stashing
 values in global variables.
 If using Multiple Values is going to be more costly than 
 these alternatives, then their use will not be widespread.  
 I think they have suceeded in this regard, and believe they will become more
 common at time goes on.  However, I think MULTIPLE-VALUE-OR is a case
 where it fails to live up to its efficiency goals.

 I have written code that needed OR which returned multiple values, (and after
 spending a while tracking down a strange bug that ending up being OR not
 returning multiple values except if its the LAST form), I wrote it as a macro.
 I have since changed the code to store the results in global variables 
 because it made the function much faster, and speed was important for this
 particular function.

 I would like to think Common Lisp implementors will provide non-consing
 &Rest args, since they are very useful for many things, as their use
 on the MIT-based Lisp Machines shows, but it is not a trivial task.
 MULTIPLE-VALUE-OR can be implemented without them (I'll give details
 if anyone really wants to know), but perhaps MULTIPLE-VALUE-OR just isn't that
 widely applicable to warrant special treatment to make it as efficient
 as possible.  If people are happy with that, then I can live with
 using uglier mechanisms when speed and efficiency are important.

 - Kelly

∂28-Apr-87  2240	MURRAY%cs.umass.edu@RELAY.CS.NET 	(REDUCE #'OVERHEAD (MAP ...))  
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 28 Apr 87  22:39:47 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac13592; 29 Apr 87 1:28 EDT
Received: from cs.umass.edu by RELAY.CS.NET id cf04612; 29 Apr 87 1:22 EDT
Date:     Tue, 28 Apr 87 19:32 EDT
From:     MURRAY%cs.umass.edu@RELAY.CS.NET
To:       common-lisp@SAIL.STANFORD.EDU
Subject:  (REDUCE #'OVERHEAD (MAP ...))
X-VMS-To: CLMAIL


> From: James Larus <larus@paris.berkeley.edu>
> I use REDUCE quite frequently and recently ran across a strange
> interaction between it and another CL feature.  I was trying to
> execute:
>	(reduce #'or (mapcar ...))

 If you're doing a lot of stuff like this, maybe you should look into
 the "Generic Mapping Functions" that Daniel Corkill has defined.
 They do much of what REDUCE + MAP is used for, but
 the notion of combining the results of mapping is generalized,
 and is done more efficiently since it isn't always necessary to cons
 up the intermediate results.
 MAPCAR can be thought of as using CONS to combine mapping results.
 The above use of OR is generally done through SOME in Common Lisp, but
 is expressed using the Generalized Maps as MAPC-OR.  EVERY is MAPC-AND, and 
 MAPCAN (MAPC-NCONC) functionality is done better as MAPC-CONDCONS.
 MAPC-MAX is a popular one, as is MAPC-+ (MAPC-UNION, MAPC-AVERAGE, etc).
 There are also MAPL-xxx functions that operate on sucessive sublists.
 We have plans to extend these to work on sequences and not just lists,
 but haven't done it yet (:- of course, they handle circular-lists :-)
    The MAP-FUN general form takes a gob of keywords
 to allow just about any mapping combination to be defined, and all the
 others are defined in terms of it.  They are Functions, but have
 Compiler transforms that convert them into very efficient DO loops.

 We can probably get the code to anyone interested.

- Kelly Murray 
  University of Massachusetts

∂29-Apr-87  1407	gls@Think.COM 	CLtL typos list
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 29 Apr 87  14:07:06 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 29 Apr 87 13:48:47 EDT
Date: Wed, 29 Apr 87 13:45 EDT
From: Guy Steele <gls@Think.COM>
Subject: CLtL typos list
To: DALY@ibm.com, common-lisp@sail.stanford.edu
In-Reply-To: <042487.112612.daly@ibm.com>
Message-Id: <870429134554.3.GLS@BOETHIUS.THINK.COM>

    Date: 24 April 1987, 11:26:11 EDT
    From: Timothy Daly <DALY@ibm.com>

    To those who have asked, yes there is a CLtL typos list.
    The header on the file says the directory is:

    /u/gis/tl/sla/corr.txt dated 12/6/85

    My copy has been IBMeroxed through so many generations that it is
    almost unreadable. From the GIS in the pathname I assume the
    source is Guy Steele and I believe his tent is still pitched at CMU.

    Guy, if you receive this, is there a later version?

    Tim Daly
    DALY@IBM.COM


Yes, there is a typos list, but the version of 12/6/85 is the latest one.

For everyone's information, I have not been at CMU for over four years,
and have not been in Pittsburgh for over two years (though I do love to
visit as often as I can).  For those who care:

August 1980-December 1982	Assistant Professor, Carnegie-Mellon University

January 1983-January 1985	Senior Scientist, Tartan Laboratories
				Assistant professor on leave, CMU

January 1985-present		Thinking Machines Corporation, Cambridge, MA

--Guy

∂30-Apr-87  1113	@ACORN.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU 	(REDUCE #'OVERHEAD (MAP ...))  
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87  11:13:10 PDT
Received: from CASHEW.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 11948; Thu 30-Apr-87 14:00:56 EDT
Date: Thu, 30 Apr 87 14:00 EDT
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: (REDUCE #'OVERHEAD (MAP ...))
To: MURRAY%cs.umass.edu@RELAY.CS.NET
cc: common-lisp@SAIL.STANFORD.EDU, miller@ACORN.CS.ROCHESTER.EDU
In-Reply-To: <8704290611.AA12297@cayuga.cs.rochester.edu>
Message-ID: <870430140059.2.MILLER@CASHEW.CS.ROCHESTER.EDU>
Sender: miller@cs.rochester.edu
Reply-To: miller@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:     Tue, 28 Apr 87 19:32 EDT
    From: MURRAY%cs.umass.edu@RELAY.CS.NET

I'd like to see more on this, if possible...
Code/doc, etc.. I use MAP, MAPCAR, etc. a >lot<.

Brad Miller
------
miller@cs.rochester.edu
miller@acorn.cs.rochester.edu
miller@rochester.arpa

∂30-Apr-87  1355	FAHLMAN@C.CS.CMU.EDU 	Notice on Kyoto Common Lisp distribution   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87  13:55:35 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 30 Apr 87 16:56:31-EDT
Date: Thu, 30 Apr 1987  16:56 EDT
Message-ID: <FAHLMAN.12298714494.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   common-lisp@SAIL.STANFORD.EDU
Subject: Notice on Kyoto Common Lisp distribution


Mr. Yuasa asked me to pass the following announcement along to the
appropriate mailing lists in the U.S.:

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

We, the Kyoto Common Lisp people have decided to distribute KCL
through channels other than a commercial company,
free of charge out of Japan.
We are looking for a best possible channel but it may take some time.
Please note the following:

1. We always claimed that no fee is charged for the source of KCL, and
if any fee is charged, it is exclusively for the service of distribution,
maintenance, etc. of the software.

2. We never received any kind of royality out of the software or service for
it up to present.

Research Institute for Mathematical Sciences
Kyoto University
	Reiji Nakajima
	Taiichi Yuasa
	Masami Hagiya

∂01-May-87  1440	EMAILDEV%UKACRL.BITNET@BERKELEY.EDU 	Notice on Kyoto Common Lisp distribution   
Received: from JADE.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87  02:30:08 PDT
Received: by jade.berkeley.edu (5.54 (CFC 4.22.3)/1.16.13)
	id AA27974; Fri, 1 May 87 02:17:44 PDT
Message-Id: <8705010917.AA27974@jade.berkeley.edu>
Return-Path: EMAILDEV%UKACRL.BITNET@WISCVM.WISC.EDU
Received: By UK.AC.RL.IB (MAILER) ; Fri, 01 May 87 10:28:41 BST
Via:      UK.AC.BHAM.COMP-V1;  1 MAY 87 10:28:37 BST
Date:     1-MAY-1987 10:25:30
From: BATTEN%UK.AC.BHAM.COMP-V1@ac.uk
To: COMMON-LISP@sail.stanford.edu
Subject:  Notice on Kyoto Common Lisp distribution
Reply-To: Batten%bham.ac.uk@seismo.css.gov
Comment: Remailed at SAIL.STANFORD.EDU after delay caused by mailing list error.

Perhaps KCL could be distributed through the GNU project?  I think it
needs a full common lisp.

ian

∂05-May-87  1825	FAHLMAN@C.CS.CMU.EDU 	Kyoto Common Lisp addendum  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 5 May 87  18:25:46 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 5 May 87 21:24:59-EDT
Date: Tue, 5 May 1987  21:24 EDT
Message-ID: <FAHLMAN.12300074083.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Common-Lisp@SAIL.STANFORD.EDU, AIList@STRIPE.SRI.COM
Subject: Kyoto Common Lisp addendum


A clarification from Mr. Yuasa:

To whom it may concern,

It seems that the previous note of ours, announcing that we are looking
for a free channel for KCL distribution, may have brought confusions and
misunderstandings to many people.  It may be mostly because only the
facts were mentioned, with no explanation of the background necessary to
understand our intention.

Our intention is to make it clear that KCL is an academic free software.
By "free", we mean that any one can get it free of charge, if he agrees
the conditions we put in the License Agreement.  It does NOT mean that
anyone has any *free*dom for KCL.  In particular, we have no intention
to put KCL into the public domain.  We would rather like to keep the
identity of KCL, so that we can keep up its high quality.

Some commercial organizations are now distributing KCL and they charge a
certain amount of fees to their customers.  These fees are exclusively
for the distribution costs and the service they offer to their
customers.  We require no royalties to them.  We are happy if more
people have got the chance to use this software.  It is a voluntary work
if we give them technical help on their requests.

Unfortunately, some people believe that we are receiving royalties for
KCL.  In order to overcome this wrong belief, we decided to look for a
free channel for KCL distribution.  Apparently, some KCL users
(including potential users) do not need any maintenance service at all.
We are glad to make KCL available to such users for free.  Note that we
do not intend to restrict the activities of commercial organizations for
KCL distribution.  We intend to give a choice to the user and to make it
clear what the user is charged for by commercial organizations.  Note
also that some KCL versions require additional programs developed by
commercial organizations and we cannot force them to make their code
open to the public, though we expect them to do so.

We are now seriously looking for a free channel.  We already found some
candidates, but it will take some time before we decide the best
appropriate channel for our purpose.  In case we cannot find an
appropriate channel, we ourselves will directly distribute KCL.
However, this will require a lot of work and we will have to spend a lot
of time.  So, this should be the last solution.

Thanks.

Taiichi Yuasa, Dr.
Research Institute for Mathematical Sciences
Kyoto University

∂08-May-87  1725	kempf%hplabsc@hplabs.HP.COM 	Rule System in CommonLoops/CLOS
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 8 May 87  17:24:53 PDT
Received: from hplabsc by hplabs.HP.COM with TCP ; Fri, 8 May 87 16:25:43 pdt
Received: by hplabsc ; Fri, 8 May 87 16:26:06 pdt
Date: Fri, 8 May 87 16:26:06 pdt
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8705082326.AA15913@hplabsc>
To: common-lisp@sail.stanford.edu
Subject: Rule System in CommonLoops/CLOS

Anybody out there doing a rule system in CommonLoops or CLOS? There
is some interest here in such, if it is publically available. Thanks.

		Jim Kempf	kempf@hplabs.hp.com

∂09-May-87  0501	TMB%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	Smalltalk-80 Classes for Symbolics and/or CommonLisp    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 May 87  05:00:52 PDT
Date: Sat 9 May 87 07:49:55-EDT
From: "Thomas M. Breuel" <TMB%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: Smalltalk-80 Classes for Symbolics and/or CommonLisp
To: pcl-hackers%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU,
    common-lisp%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU,
    info-lispm%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU,
    lisp-forum%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
cc: tmb%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Message-ID: <12300974291.86.TMB@OZ.AI.MIT.EDU>

I am looking for an implementation of the Smalltalk-80 classes, or a
subset of them, on the Symbolics 3600 and/or under Common Lisp.  I am
only interested in this for new program developments, not porting, so
compatibility is not a strict requirement. Implementations using
flavours or PCL are fine. If you have such a beast, or a pointer to
one, please let me know.

					Thomas.
					tmb@prep.ai.mit.edu
-------

∂12-May-87  0301	@REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU 	atom type question   
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 May 87  03:01:02 PDT
Received: from DESCARTES.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 39231; Tue 12-May-87 06:00:35 EDT
Date: Tue, 12 May 87 06:00 EDT
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: atom type question
To: common-lisp@sail.stanford.edu
Message-ID: <870512060032.8.CFRY@DESCARTES.AI.MIT.EDU>

CLtL says, p. 73 "The predicate ATOM is true if its argument
is not a cons."

Is ATOM supposed to be true of non-COMMON data types as well?

∂12-May-87  0637	FAHLMAN@C.CS.CMU.EDU 	atom type question
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 May 87  06:36:58 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 12 May 87 09:36:19-EDT
Date: Tue, 12 May 1987  09:36 EDT
Message-ID: <FAHLMAN.12301780077.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   common-lisp@SAIL.STANFORD.EDU
Subject: atom type question
In-reply-to: Msg of 12 May 1987  06:00-EDT from Christopher Fry <cfry at OZ.AI.MIT.EDU>


    CLtL says, p. 73 "The predicate ATOM is true if its argument
    is not a cons."

    Is ATOM supposed to be true of non-COMMON data types as well?

My opinion: unless the non-Common data type is a subtype of CONS, ATOM
should be true of it.

-- Scott

∂12-May-87  0715	RAM@C.CS.CMU.EDU 	atom type question    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 May 87  07:06:37 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 12 May 87 10:05:57-EDT
Date: Tue, 12 May 1987  10:05 EDT
Message-ID: <RAM.12301785477.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To:   common-lisp@SAIL.STANFORD.EDU
Subject: atom type question


    Date: Tuesday, 12 May 1987  06:00-EDT
    From: Christopher Fry <cfry at OZ.AI.MIT.EDU>
    Re:   atom type question

    ...
    Is ATOM supposed to be true of non-COMMON data types as well?

I think the language in the manual pretty clearly indicates that the
answer is yes, although there currently isn't much discussion of
extensions to the type system.  CONS is a subtype of COMMON and ATOM =
(NOT CONS), therefore anything not COMMON must be an ATOM.  

In can't see any reason for wanting thing to be otherwise.  If you
want to add some new object that acts like a cons but isn't, then you
can make it a subtype of cons.  Although CLTL says that
"implementations may not unilaterally add subtypes to COMMON", I think
that there is no way for a correct program to tell that you have added
a subtype except in the cases where CLTL says that some types form an
exhaustive partition of another type.

  Rob

∂12-May-87  1753	RWK@YUKON.SCRC.Symbolics.COM 	atom type question  
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 12 May 87  17:52:41 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 207069; Tue 12-May-87 20:50:54 EDT
Date: Tue, 12 May 87 20:50 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: atom type question
To: Ram@C.CS.CMU.EDU
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12301785477.BABYL@>
Message-ID: <870512205052.7.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

    Date: Tue, 12 May 1987  10:05 EDT
    From: Ram@C.CS.CMU.EDU
	Date: Tuesday, 12 May 1987  06:00-EDT
	From: Christopher Fry <cfry at OZ.AI.MIT.EDU>
	...
	Is ATOM supposed to be true of non-COMMON data types as well?

    I think the language in the manual pretty clearly indicates that the
    answer is yes, although there currently isn't much discussion of
    extensions to the type system.  CONS is a subtype of COMMON and ATOM =
    (NOT CONS), therefore anything not COMMON must be an ATOM.  

    In can't see any reason for wanting thing to be otherwise.  If you
    want to add some new object that acts like a cons but isn't, then you
    can make it a subtype of cons.  
I agree with this, except I don't believe in the type
COMMON.  You can get the same result by omitting references
to COMMON:  If it's not a subtype of CONS, by ATOM = (NOT CONS),
it must be an ATOM.

				    Although CLTL says that
    "implementations may not unilaterally add subtypes to COMMON", I think
    that there is no way for a correct program to tell that you have added
    a subtype except in the cases where CLTL says that some types form an
    exhaustive partition of another type.
Not even then, because you may be partitioning an one of those
types further, or extending one to contain additional elements.

COMMON is a joke.  Without any clear statement of just what
COMMONP is supposed to buy you, it's impossible to come up
with any clear view of what it should mean.  What happens
if Common Lisp '89 comes out, and defines 6 new types?  Without
any advance knowledge of how this extension would be handled,
you can't write you code defensively using COMMON.

Instead, in situations where you try to handle all of the
types in CL, I believe you should just use ETYPECASE naming the
types you actually DO handle.  Extended types will either fit
in with types you implemented (say a new subtype of CONS will
fit in with your LIST clause), or they won't.

∂13-May-87  1426	berman@vaxa.isi.edu 	&REST    
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 13 May 87  14:26:22 PDT
Received: by vaxa.isi.edu (4.12/4.7)
	id AA02845; Wed, 13 May 87 14:24:38 pdt
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8705132124.AA02845@vaxa.isi.edu>
Date: 13 May 1987 1424-PDT (Wednesday)
To: common-lisp@sail.stanford.edu
Cc: berman@vaxa.isi.edu
Subject: &REST


Now, I'm SURE this one has come up, but here goes...

In your favorite implementation of CL, try this:

(DEFUN FOO (&REST A) A)
(FOO 1 2 3)

By direct experience, both TI (version 2) and Symbolics (Version 7) do not
return (1 2 3).  They have an efficiency hack wherein the cons space used to
create the &REST arg is reused, and thus the pointer that is returned (which
is a pointer to a list) is pointing to memory which does not contain the same
thing as when the pointer was last evaluated.  That is, he process of
returning has the side effect of changing the contents of the list created
when binding A.  Seth Goldman tells me that several Macintosh Lisps also
behave this way.

CLtL, on page 61, states:

"If there is a rest parameter, it is bound to a list of all as-yet-unprocessed
arguments."

This part works fine.  These implementations DO make a list and bind it and
all that.  The symbolics manual specifically warns one to use copylist if you
want to return any tail or sublist of an &REST argument (thus consing it in
"real" memory).

As I am putting together the test suite, I have run into a problem:  Many
tests actualy use &REST.  These seem to expect to get a proper list and not
some imaginary list that changes when the function returns.  My feelings are
that the above efficiency hack is a bug, even though it may be "supported by
hardware".  

Can anyone show me a valid justification for the above behavior?  So far, HP
has an implementation that does the correct thing (returns the list).  TI, in
their version 3 software (which we are beta-ing) has fixed this.  Note that
page 60 clearly states, about the body in a lambda,

"The body consists of any number of forms (possibly zero).  These forms are
evaluated in sequence, and the results of the last form only are returned as
the results of the application..."

This does not allow for any alteration of the results of the last form.  

OK?

RB





∂13-May-87  1512	DLW@ALDERAAN.SCRC.Symbolics.COM 	&REST  
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 13 May 87  15:12:26 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 81313; Wed 13-May-87 18:10:48 EDT
Date: Wed, 13 May 87 18:10 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: &REST
To: berman@vaxa.isi.edu, common-lisp@sail.stanford.edu
In-Reply-To: <8705132124.AA02845@vaxa.isi.edu>
Message-ID: <870513181032.7.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: 13 May 1987 1424-PDT (Wednesday)
    From: berman@vaxa.isi.edu (Richard Berman)
								 My feelings are
    that the above efficiency hack is a bug, even though it may be "supported by
    hardware".  

    Can anyone show me a valid justification for the above behavior?

There isn't any justification.  It's a bug.  It's among the list of
documented non-conformances of the Symbolics implementation, most of
which are a whole lot less severe than this one.  Unfortunately, it is
extremely difficult to fix without an unacceptable impairment of
performance in this implementation.  "No excuse, sir."

∂14-May-87  0913	coffee@aerospace.aero.org 	Re: &REST    
Received: from AEROSPACE.AERO.ORG by SAIL.STANFORD.EDU with TCP; 14 May 87  09:12:30 PDT
Received: by aerospace.aero.org (5.54/6.0.GT)
	id AA06471; Thu, 14 May 87 09:10:19 PDT
Posted-Date: Thu, 14 May 87 09:10:07 -0800
Message-Id: <8705141610.AA06471@aerospace.aero.org>
To: berman@vaxa.isi.edu (Richard Berman)
Cc: common-lisp@sail.stanford.edu
Subject: Re: &REST
In-Reply-To: Your message of 13 May 1987 1424-PDT (Wednesday).
             <8705132124.AA02845@vaxa.isi.edu>
Date: Thu, 14 May 87 09:10:07 -0800
From: coffee@aerospace.aero.org


Well, I don't know about "several of the Macintosh Lisps," but ExperCommon
Release 2.2 handles (defun foo (&rest a) a);(foo 1 2 3) --> (1 2 3) 
correctly; so, for that matter, do Gold Hill's GC286 and GC386(Hummingboard)
implementations. By the way, I've mentioned this in lisp news already, but
watch out for the Hummingboard Lisp: it thinks that log of 1e6 to the base
10 is a double-precision value slightly greater than pi, reproducibly, and
the rest of its math functions are similarly creative. It also gives
incorrect results (not error _messages_, mind you, just wrong answers)
running a version of Forgy's OPS5 that was only modified as necessary to
make it run on GC286. Gold Hill's phone support has been courteous and
sincerely interested, but for the moment we're in the incongruous position
of using the Hummingboard as an unbelievably nice editor but doing serious
testing and production on a plain-vanilla DeskPro 286...

∂14-May-87  1107	berman@vaxa.isi.edu 	Re: &REST     
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 14 May 87  11:07:44 PDT
Posted-Date: Thu, 14 May 87 11:04:37 PDT
Message-Id: <8705141804.AA05984@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
	id AA05984; Thu, 14 May 87 11:04:45 PDT
To: coffee@aerospace.aero.org
Cc: berman@vaxa.isi.edu (Richard Berman), common-lisp@sail.stanford.edu
Subject: Re: &REST 
In-Reply-To: Your message of Thu, 14 May 87 09:10:07 -0800.
             <8705141610.AA06471@aerospace.aero.org> 
Date: Thu, 14 May 87 11:04:37 PDT
From: berman@vaxa.isi.edu


Well, as for the "several Mac lisps", as I mentioned in my message this was
told to me by Seth goldman and was not a matter of my personal experience.  I
did not name any names.  He said ExperLisp DID behave incorrectly, but he
didn't say which release.  I am glad to hear that it is not as widespread as
Seth implied.

RB

∂14-May-87  1314	coffee@aerospace.aero.org 	Re: Gold Hill's floating-point   
Received: from AEROSPACE.AERO.ORG by SAIL.STANFORD.EDU with TCP; 14 May 87  13:13:52 PDT
Received: by aerospace.aero.org (5.54/6.0.GT)
	id AA12386; Thu, 14 May 87 13:04:07 PDT
Posted-Date: Thu, 14 May 87 13:04:02 -0800
Message-Id: <8705142004.AA12386@aerospace.aero.org>
To: samalone@athena.mit.edu
Cc: common-lisp@sail.stanford.edu
Subject: Re: Gold Hill's floating-point
In-Reply-To: Your message of Thu, 14 May 87 13:37:25 EDT.
             <8705141737.AA19398@HADES.MIT.EDU>
Date: Thu, 14 May 87 13:04:02 -0800
From: coffee@aerospace.aero.org

Thanks -- this explains an annoying, but different, problem that also
occurs under GC286 on an 80286/80287 machine. Thanks again (I'll put this
into my definition of the (dos) function to make it automatic).

						- Peter C.

∂14-May-87  1438	berman@vaxa.isi.edu 	documentation 
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 14 May 87  14:38:47 PDT
Posted-Date: Thu, 14 May 87 14:37:03 PDT
Message-Id: <8705142137.AA11169@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
	id AA11169; Thu, 14 May 87 14:37:05 PDT
To: common-lisp@sail.stanford.edu
Subject: documentation
Date: Thu, 14 May 87 14:37:03 PDT
From: berman@vaxa.isi.edu


What should the following do?

(documentation 'doc 'doc)

Per page 440 of CLtL, there is a list of documentation types, but no mention
of what to do if given some other symbol.  Should it return NIL?  Should it
signal or "be" an error?  Can it return some other arbitrary value, or is it
totally up to the implementor?

Likewise, (setf (documentation 'doc 'doc) "xyz"),

I have an implementation here that allows documentation to work this way.  It
appears to more or less syntactic-sugar for property lists, 'cuz in the above
case, the setf will put "xyz" on the symbol DOC as it documentation type DOC.

I have another implementation which is strictly by the book in that if it is
not on that list of legal documentation types, it signals an error.

Note:  The first implementation is a bit too relaxed--it allows (setf
(documentation "FOO" 'doc) "xyz"), which is clearly incorrect 'cuz "Both
arguments must be symbols".

RB

∂14-May-87  1507	edsel!bhopal!jonl@navajo.stanford.edu 	Re: &REST  
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 May 87  15:07:28 PDT
Received: by navajo.stanford.edu; Thu, 14 May 87 15:04:56 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
	id AA04439; Thu, 14 May 87 14:18:04 pdt
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
	id AA04811; Thu, 14 May 87 14:19:29 PDT
Date: Thu, 14 May 87 14:19:29 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8705142119.AA04811@bhopal.edsel.uucp>
To: navajo!common-lisp%sail.stanford.edu@navajo.stanford.edu
Subject: Re: &REST

For compatibility with the semantics of CLtL, Lucid chose to make the
&rest arg be a true (heap-consed) list.

But the kinds of folks who have tolerated the bug which Dan Wienreb so
gloriously announced are not entirely stupid.  There is a market, at
least amongst some systems programmers who use lisp, to get the kind of
"last-bit tweaking" performance that a stack-allocated &rest list would
afford.  Lucid's product will shortly be giving the user access to some
of the underlying primitives which permit dynamic-extent consing (the
3600's "stack list" consing is one such example).

The default for &REST lists will, of course, still be lists of indefinite 
extent.

-- JonL --

∂14-May-87  1724	FAHLMAN@C.CS.CMU.EDU 	documentation
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 May 87  17:24:38 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 14 May 87 20:23:56-EDT
Date: Thu, 14 May 1987  20:23 EDT
Message-ID: <FAHLMAN.12302422265.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   berman@VAXA.ISI.EDU
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: documentation
In-reply-to: Msg of 14 May 1987  17:37-EDT from berman at vaxa.isi.edu


I think that only the specified symbols are required to work.  Anything
else "is an error".  However, it is legal to extend the language so that
other symbols or even non-symbols work.

-- Scott

∂15-May-87  1035	coffee@aerospace.aero.org 	Re: Gold Hill's floating-point   
Received: from AEROSPACE.AERO.ORG by SAIL.STANFORD.EDU with TCP; 15 May 87  10:34:31 PDT
Received: by aerospace.aero.org (5.54/6.0.GT)
	id AA01230; Fri, 15 May 87 10:29:47 PDT
Posted-Date: Fri, 15 May 87 10:29:32 -0800
Message-Id: <8705151729.AA01230@aerospace.aero.org>
To: MATHIS@ada20.isi.edu
Cc: common-lisp@sail.stanford.edu
Subject: Re: Gold Hill's floating-point
In-Reply-To: Your message of 15 May 1987 06:35-PDT.
             <[ADA20.ISI.EDU]15-May-87 06:35:47.MATHIS>
Date: Fri, 15 May 87 10:29:32 -0800
From: coffee@aerospace.aero.org

Bob Mathis notes, correctly, that my earlier reply to samalone assumed
that you had all seen the original message. Mea culpa. The problem that
_he_ had fixed was Gold Hill 286's habit of returning _weird_-looking
floating-point results (multiple decimal points, etc.) after a period
of use: apparently, this is due to pushing to DOS and leaving the 8087
or 80287 in an odd state that Gold Hill's interpreter does not correct
on returning. The fix is to make the call (SYS::8087-FPP) after returning
from DOS. I have my own (dos) function defined in USERINIT to provide
a "press a key to return to Lisp" prompt if (dos) is called with an argument,
so adding this call to that function has fixed the problem.

The Hummingboard release uses the call (SYS::8087-FPP :emulate) in view
of the absence of a physical numeric chip on that board, and I have seen
no such bizarre behavior -- not this specific variety, I mean -- on it,
so there is no apparent reason to do this on the Hummer. The general problem
of floating-point creativity in GC 386 Developer continues, I'm sad to
say: how about (log 1024 2) --> 9.53638... to double precision? The same
result also occurs with single- or double-precision real arguments. Further,
another user tells me that regular old non-Hummingboard GC386 does the
same thing on her "Inboard" 386 card.

BTW, I have mentioned the substantial enhancements to the editor as a major
advantage of the Gold Hill 386 vs. 286 products; I learned yesterday that
a new, compiled, enhanced editor (sounds exactly like the 386 version) is a
key feature of the GC286 2.2 upgrade, $90. Since we're not seeing nearly the
factor of five speed increase that Gold Hill claims versus "an AT" (maybe
they ran against a 6 MHz machine? We're seeing speed ratios of from one to
four with a Hummingboard in a DeskPro 386 against an 8-MHz DeskPro 286),
consider this in your cost-effectiveness evaluation. A twelve- or sixteen-MHz
80286 with adequate RAM may be quite competitive, especially if (like us)
you're doing pattern recognition in telemetry streams or other number-
crunching things. Of course, the Hummingboard can be dropped right into any
XT clone with a decent hard disk, an important factor if you already
own such a box.

I'm sorry if this extended discussion of microcomputer implementations has
annoyed anyone: in general, I direct such comments to lang.lisp, and will
continue to do so now that the loose ends on this exchange are (I believe)
tied off. I would also like to stress that Gold Hill's people have been
prompt, courteous, and helpful in our discussions of these problems and that
I have every confidence that they will be quickly resolved.

						Regards, Pc↑2

∂15-May-87  1331	@ACORN.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU 	(REDUCE #'OVERHEAD (MAP ...))  
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 15 May 87  13:31:40 PDT
Received: from CASHEW.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 12731; Fri 15-May-87 16:19:08 EDT
Date: Fri, 15 May 87 04:16 EDT
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: (REDUCE #'OVERHEAD (MAP ...))
To: MURRAY%cs.umass.edu@RELAY.CS.NET
cc: common-lisp@SAIL.STANFORD.EDU, miller@ACORN.CS.ROCHESTER.EDU
In-Reply-To: <8704290611.AA12297@cayuga.cs.rochester.edu>
Message-ID: <870515041614.4.MILLER@CASHEW.CS.ROCHESTER.EDU>
Sender: miller@cs.rochester.edu
Reply-To: miller@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:     Tue, 28 Apr 87 19:32 EDT
    From: MURRAY%cs.umass.edu@RELAY.CS.NET

    > From: James Larus <larus@paris.berkeley.edu>
    > I use REDUCE quite frequently and recently ran across a strange
    > interaction between it and another CL feature.  I was trying to
    > execute:
    >	(reduce #'or (mapcar ...))

     If you're doing a lot of stuff like this, maybe you should look into
     the "Generic Mapping Functions" that Daniel Corkill has defined.
     They do much of what REDUCE + MAP is used for, but
     the notion of combining the results of mapping is generalized,
     and is done more efficiently since it isn't always necessary to cons
     up the intermediate results.
     MAPCAR can be thought of as using CONS to combine mapping results.
     The above use of OR is generally done through SOME in Common Lisp, but
     is expressed using the Generalized Maps as MAPC-OR.  EVERY is MAPC-AND, and 
     MAPCAN (MAPC-NCONC) functionality is done better as MAPC-CONDCONS.
     MAPC-MAX is a popular one, as is MAPC-+ (MAPC-UNION, MAPC-AVERAGE, etc).
     There are also MAPL-xxx functions that operate on sucessive sublists.
     We have plans to extend these to work on sequences and not just lists,
     but haven't done it yet (:- of course, they handle circular-lists :-)
	The MAP-FUN general form takes a gob of keywords
     to allow just about any mapping combination to be defined, and all the
     others are defined in terms of it.  They are Functions, but have
     Compiler transforms that convert them into very efficient DO loops.

     We can probably get the code to anyone interested.

    - Kelly Murray 
      University of Massachusetts

Sorry if this is a repeat, but I am very interested in your conjoined mapping
functions... If you can mail it, terrific, if ftp access is better, let me
know, or if you want a tape...

Thanks,
Brad Miller
------
miller@cs.rochester.edu
miller@acorn.cs.rochester.edu

∂15-May-87  1333	Mailer@XX.LCS.MIT.EDU 	Re: &REST   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 May 87  13:33:07 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 May 87 16:29-EDT
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 42955; 15 May 87 16:29:59-EDT
Received: from KITTYHAWK.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 35711; 15 May 87 13:04:19-EDT
Date: Fri, 15 May 87 13:03 EDT
From: K. Shane Hartman <SHANE@JASPER.PALLADIAN.COM>
Subject: Re: &REST
To: Common-Lisp@sail.stanford.edu
In-Reply-To: <8705142119.AA04811@bhopal.edsel.uucp>
Message-ID: <870515130345.5.SHANE@KITTYHAWK.PALLADIAN.COM>
Reply-To: K. Shane Hartman <SHANE%JASPER@LIVE-OAK.LCS.MIT.EDU>

    Date: Thu, 14 May 87 14:19:29 PDT
    From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)

	...

    But the kinds of folks who have tolerated the bug which Dan Wienreb so
    gloriously announced are not entirely stupid.  There is a market, at
    least amongst some systems programmers who use lisp, to get the kind of
    "last-bit tweaking" performance that a stack-allocated &rest list would
    afford.  Lucid's product will shortly be giving the user access to some
    of the underlying primitives which permit dynamic-extent consing (the
    3600's "stack list" consing is one such example).
	
	...

In fact, we use stack allocated &REST lists exclusively.  We tried using heap
allocated &REST lists and found that it significantly impaired the performance of at
least one large system.  I think lisp vendors should be encouraged to provide this
sort of feature.  
    
-[Shane]->


∂15-May-87  1403	ACUFF@SUMEX-AIM.STANFORD.EDU 	Re: &REST 
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 15 May 87  14:03:13 PDT
Date: Fri, 15 May 87 14:01:46 PDT
From: Richard Acuff <Acuff@SUMEX-AIM.STANFORD.EDU>
Subject: Re: &REST
To: berman@VAXA.ISI.EDU, common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <8705132124.AA02845@vaxa.isi.edu>
Message-ID: <12302647619.45.ACUFF@SUMEX-AIM.STANFORD.EDU>

   For the record, in Release 3, TI has attempted, with apparent
success, to remove the restrictions on using &REST lists outside of
the dynamic scope of the parameter.  (While increasing the performance
of the system, to boot.)

	-- Rich
-------

∂15-May-87  1747	@ACORN.CS.ROCHESTER.EDU,@CASHEW.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU 	Last message to list.    
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 15 May 87  17:47:40 PDT
Received: from CASHEW.CS.ROCHESTER.EDU (CASHEW.CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 12746; 15 May 87 20:48:15 EDT
Date: Fri, 15 May 87 08:45 EDT
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: Last message to list.
To: common-lisp@sail.stanford.edu
cc: miller@ACORN.CS.ROCHESTER.EDU
Message-ID: <870515084522.9.MILLER@CASHEW.CS.ROCHESTER.EDU>
Sender: miller@cs.rochester.edu
Reply-To: miller@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, that wasn't meant for the entire list. Apologies, etc.

Brad Miller
------
miller@cs.rochester.edu
miller@acorn.cs.rochester.edu

∂17-May-87  1532	dg%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: &REST
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 May 87  15:32:23 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 May 87 18:30-EDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 43116; 17 May 87 18:29:57-EDT
Received: from RAVEL.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 69423; Sun 17-May-87 17:58:22-EDT
Date: Sun, 17 May 87 17:56 est
From: dg%acorn@oak.lcs.mit.edu
To: Acuff@SUMEX-AIM.STANFORD.EDU
Subject: Re: &REST
Cc: common-lisp@SAIL.STANFORD.EDU

    Date: Fri, 15 May 87 14:01:46 PDT
    From: Richard Acuff <Acuff@SUMEX-AIM.STANFORD.EDU>
    
       For the record, in Release 3, TI has attempted, with apparent
    success, to remove the restrictions on using &REST lists outside of
    the dynamic scope of the parameter.  (While increasing the performance
    of the system, to boot.)
    
    	-- Rich
    -------

Are there exactly 0 restrictions now?

Does this mean that removing the restrictions actually improved the
performance of the system, or was that just coincidental?

-dg

∂18-May-87  0603	dml@nadc 	Addition to mailing list.
Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 18 May 87  06:03:07 PDT
Date: 18 May 1987 08:58:24-EDT
From: dml@NADC
To: common-lisp@sail.stanford.edu
Subject: Addition to mailing list.

I am involved in design of both expert system shells and expert systems
on PC/AT and Symbolics-3600 series.  Please add me to your mailing list.
Please send any recent info you have r about: Gold Hiλill LISP, Symbolics Common Lisp
, or Kyoto Common LISP.

David Loewenstern
Naval Air Development Center
code 7013
Warminster, PA 18974-5000

<dml@nadc.arpa>

∂18-May-87  0811	FAHLMAN@C.CS.CMU.EDU 	Mailing List for Lucid Users
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 May 87  08:10:58 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 18 May 87 11:10:08-EDT
Date: Mon, 18 May 1987  11:10 EDT
Message-ID: <FAHLMAN.12303370022.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Common-Lisp@SAIL.STANFORD.EDU, AIList@STRIPE.SRI.COM
Subject: Mailing List for Lucid Users


We have set up an ARPAnet mailing list, "lucites@c.cs.cmu.edu", for the
exchange of information related to Lucid Common Lisp.  This mailing list
is meant to function as a sort of informal users' group; it is not under
the control of Lucid, though some Lucid people will receive it.
"Lucites" is an appropriate channel for queries, programming hints, and
the sharing of software (large programs can be announced but should not
be distributed over this mailing list).  "Lucites" is not an appropriate
channel for bug reports, commercial announcements, or sales pitches.

Because our machine's capacity to forward mail is limited, we must
reserve the right to refuse any request to add more than two recipients
to the list from any given site; if you have three or more people who
want to receive this mail, you are expected to set up you own local
redistribution list or to direct the mail to a bulletin board that your
people can access.  (If anyone wants to set up a version of this list
without such restrictions, please contact us and we will gladly turn the
task over to you.)

To get your name on the list, send mail to
"lucites-request@c.cs.cmu.edu".  Requests sent to us personally will be
ignored.  Requests sent to the mailing list as a whole will result in
scorn and abuse being heaped upon you.  If any address on the list
starts bouncing mail sent to it, it will be excised from the list at
once.

Scott E. Fahlman
David B. McDonald

Computer Science Department
Carnegie-Mellon University

∂18-May-87  1151	@RELAY.CS.NET:a37078%tansei.u-tokyo.junet@UTOKYO-RELAY.CSNET 	Introduction to a multi-byte character extension
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 May 87  11:50:56 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac05113; 18 May 87 14:19 EDT
Received: from utokyo-relay by RELAY.CS.NET id ek09318; 18 May 87 14:03 EDT
Received: by u-tokyo.junet (5.51/4.9J-1[JUNET-CSNET])
	id AA19456; Mon, 18 May 87 14:09:05 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
	id AA06680; Mon, 18 May 87 14:05:32+0900
Date: Mon, 18 May 87 14:05:32+0900
From: Masayuki Ida <a37078%tansei.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8705180505.AA06680@tansei.cc.u-tokyo.junet>
To: common-lisp@SAIL.STANFORD.EDU, ida%tansei.u-tokyo.junet@RELAY.CS.NET
Subject: Introduction to a multi-byte character extension

In the separate mail, I posted  a mail titled
"A multi-byte character extension proposal",
which has 740 lines.

Since I posted mails on kanji manipulation in May 1986,
I have been thinking of this problem.
I organized the kanji WG under Jeida Common Lisp committee,
and I welcomed Dr. Motoyoshi  from Electro-technical Laboratory
as the chair of the WG.
I asked him and his group to make a proposal.
Their porposal was first appeared on the academic meeting
(IPSJ SIGSYM Jan. 1987) and then reported in the annual report
of Jeida, then was refined into the english version I posted
as a mail.
I believe the contents are worth to distribute in USA and
to have  criticism and suggestions
as a base for multi-byte character manipulation extension
of Common Lisp.
It is a report of our kanji WG
to make a guide line for multi-byte character manipulation
in Common Lisp, not by myself only, but by the contributions of
all the members of kanji WG.
	kanji WG members:
                IKEO, J. (Fuji Xerox Co., Ltd.)
                KIMURA, K. (Toshiba Corp.)
                MURAYAMA, K. (Nippon Univac Kaisha, Ltd.)
                NAKAMURA, S. (Fujitsu, Ltd.)
                OKA, M. (Japan Radio Co., Ltd.)
                SAKAIBARA, K. (Hitachi Co., Ltd.)
                SHIOTA, E. (Nihon Symbolics Corp.)
                SUGIMURA, T. (Nippon Telegraph and Telephone Corp.)

Especially, thanks to Mr. Shiota of Nippon Symbolics,
who made a first english version.

It has a digest, 4 chapters and one appendix;
   Digest
   1. A proposal for embedding multi-byte characters
   2. Additional features for embedding multi-byte characters
   3. Common parts which we implement
   4. Proposed changes to CLtL to support multiple character sets
   Appendix Proposed Japanese character processing facilities for Common Lisp

We tried to split the general issues on multi-byte character extension
and the japanese character manipulation.
We hope this specification will fit to any other character set handling.
Our proposal is based on the clear specification of CLtL
for character data type.

Roughly speaking,
First, we give a value larger than 256, may be 65536 or larger,
to *char-code-limit* constant.
Second, for the implementation which do not need to have
a multi-byte character feature, we propose internal-thin-things.
Third, to handle multi-byte character properly, we propose
write-width function.

We did not make a conclusion on font- style- issue.
And our proposal does not have a direct concern to the issue.


We will welcome any comments on it.
But we can not make a rapid answer to arpa.
So, please dont haste. excuse me.
We will make answers to the important questions
considering our limited budget for communication.

Masayuki Ida

∂18-May-87  1158	@RELAY.CS.NET:a37078%tansei.u-tokyo.junet@UTOKYO-RELAY.CSNET 	A multi-byte character extension proposal  
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 May 87  11:58:10 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ae05113; 18 May 87 14:19 EDT
Received: from utokyo-relay by RELAY.CS.NET id el09318; 18 May 87 14:04 EDT
Received: by u-tokyo.junet (5.51/4.9J-1[JUNET-CSNET])
	id AA19470; Mon, 18 May 87 14:10:20 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
	id AA06726; Mon, 18 May 87 14:06:46+0900
Date: Mon, 18 May 87 14:06:46+0900
From: Masayuki Ida <a37078%tansei.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8705180506.AA06726@tansei.cc.u-tokyo.junet>
To: common-lisp@SAIL.STANFORD.EDU, ida%tansei.u-tokyo.junet@RELAY.CS.NET
Subject: A multi-byte character extension proposal

Date: Mon, 18 May 87 09:44:19 JST
From: moto@XXX.XXX.junet (MOTOYOSHI)
To: ida@tansei.cc.u-tokyo.junet
Subject: Kanji Proposal


-------------------- Beginning of text --------------------
@Comment[-*- Mode: Text -*-]
@heading[Digest]

@heading[1. Hierarcy of characters and strings]

    Let the value of char-code-limit be large enough to include all
characters.

	char > string-char >= internal-string-char > standard-char

	string >= internal-thin-string > simple-internal-thin-string

	simple-string >= simple-internal-thin-string

	string = (or internal-thin-string (vector string-char))

		Type internal-thin-string and (vector string-char) are
		disjoint or identical.

	simple-string = (or simple-internal-thin-string
			    (simple-array string-char (*)))

		Type simple-internal-thin-string and (simple-array
		string-char (*)) are disjoint or identical.

	notes:	A > B means B is a subtype of A,
		A >= B means B is a subtype of A or B is equal to A.

@Heading[2. Print width]

	Only standard characters are required to have fix-pitched
print width. Use the newly introdued function 'write-width'
to know the print width of an expression.

@Heading[3. Functions]

	Functions dealing with strings should work as before,
expect ones which change the contents of internal-thin-string
to non internal-thin-char's.

	Functions producing strings should create (vector
string-char), not internal-thin-string, unless they were
explicitly specified.

	Funtions comaring strings should copare them elementwise.
Therefore it is possible that a (vector string-char) is equal
to an internal-thin-string.
@newpage
@Heading[1. A proposal for embedding multi-byte characters]

The Kanji Working Group (KWG) examined implementation of facilities for
multi-byte character to Common Lisp.  This report is the result of many
discussions of many proposals.  Of course, this report doesn't satisfy
all proposals, but it is very close.

In order to decide on a final proposal, we chose essential and
desirable characteristics of a working multi-byte character system.
Chapter 2 describes these characteristics in some detail.

Chapter 3 describes additional features to Common Lisp which will be useful
not just for multi-byte character, but also for many other kinds of character sets.
This chapter describes internal data structures.  If this proposal is
accepted in Common Lisp, it will be easy for countries to add original mechanisms.

Chapters 4 describes proposed changes to @I[Common Lisp -- The Language]
(CLtL).

@Heading[2. Additional features for embedding multi-byte characters.]

This chapter describes design principles which can be used to design
multi-byte character language extensions to Common Lisp.

There are many programming languages which can multi-byte characters.
Most of them can use multi-byte character as string character data 
but not as variables or function names. 

It is necessary for programming languages like Lisp that use symbolic data 
to be able to process not only single-byte characters but also multi-byte characters.
That is, it should be possible to use multi-byte characters in character string and 
symbols, and it must be possible to store both kinds of characters in them.

Treating multi-byte characters just like other alpha-numeric characters
means that multi-byte character must be treated as a single character object.
Many of the present implementations of Lisp treat multi-byte character as
pairs of bytes.  Alternatively, they use a different data type which
doesn't permit multi-byte character to be mixed with standard characters.
Such systems are not useful for user.

Thus, the basic design principles for embedding multi-byte character to Common Lisp are:

@Begin[Itemize]

Multi-byte character should be treated like single-byte character, that is, 
a multi-byte character is one character object.

@End[Itemize]

@Begin[Itemize]

A program which was coded without explicit attention for multi-byte character should 
handle multi-byte character data as is.

@End[Itemize]

These principles provide sufficient functionality, but we can't ignore
efficiency.  So we considered the next principle:

@Begin[Itemize]

The performance of the system in terms of CPU and memory
utilization should not be consideraly affected in programs which do not use multi-byte
characters.

@End[Itemize]

This principle is contradictory to other principles, but this can't be
ignored when we consider the users of actual systems, so we have to
compromise.  We think that following methods will satisfy both of these
requirements.

@Heading[3. Common parts which we implement.]

This chapter describes the implementation of multiple character sets in Common Lisp. 

To treat multi-byte characters like single-byte characters, the multi-byte character must be
included in the set of possible character codes.

We consider the following implementation methods.

@Begin[Itemize]

Add multi-byte characters by setting the variable char-code-limit to a large number.

@End[Itemize]

In this case, the single-byte character set and the multi-byte character 
set must be ordered into a single sequence of character codes. This means multi-byte 
character set must not overlap with the single-byte character set.  This method could 
be satisfied within most implementations with ease.

If we use this method, it is possible to use multi-byte characters with
fonts in Common Lisp, and operations that work for single-byte 
character will also work for multi-byte character without any change.

This implementation method has problems with efficiency.  
In the case that the value of character code is greater than size of 1 byte
(multi-byte characters are in this category), memory utilization is
affected.  A string containing only one single-byte character is 2 bytes long.
The same problem would also occur with symbol p-names.  If we can solve the problem 
for strings, we can solve other problems, so we will start by considering only strings.

To avoid this memory utilization problem, it is possible to optimize and 
make single-byte character strings by packing internally. In other words, 
to have two kinds of data types and not show it to user. There is only one type of 
data from the viewpoint of users, which means that every function which uses strings 
will continue to work as defined.

This can be implemented in almost everywhere without so many costs.  The only
problem occurs when a function attempts to put a multi-byte character into an optimized
and packed sigle-byte-only string.  To work according to the definition, the implementation 
must unpack the original packed string. This presents an implementation inefficiency which 
the user may find undesirable.

One solution would be to
@Begin[Itemize]

Generate errors for operations that try to use multi-byte characters into 
single-byte string and presenting two string datatypes to users.

@End[Itemize]

We propose this latter implementation.  Common lisp should have 2 string
types to treat multi-byte characters efficiently.  The first of these is
@b[ε1stringε0], which stores any character of type @B[ε1string-charε0], i.e.,
whose @I[ε2bitsε0] and @I[ε2fontε0] are both zero.  The type of string is
@B[ε1internal-thin-stringε0] which is the optimized character string.
@B[ε1internal-thin-charε0] is a subtype of @B[ε1characterε0] and can be inserted into string
@B[ε1internal-thin-stringε0].  The predicate which tests for this type of character is 
@B[ε1internal-thin-char-pε0].

The type @B[ε1internal-thin-charε0] is a subtype of @B[ε1string-charε0], and is a
supertype of @B[ε1standard-charε0]. 
The data type hierarchy for @B[ε1characterε0] and @B[ε1stringε0] is shown in figure 1.
@b[ε1Internal-thin-charε0] and @b[ε1string-charε0] may be equal as it is possible that situations
 may arise where both sets describe the same character-set.
 This is equivalent to the type of system that has only one type of character from the 
viewpoint of the user as discussed in the previous chapter.  This proposal permits both 
kinds of implementations. 
@newpage                        
@Begin[Verbatim]                        
				character
				    |
			       string-char
				    |
			    internal-thin-char
				    |
			       standard-char

@Center[Fig-1.a  Structure of character type]

				string
				  |
		-----------------------------------
		|		  |		  |
		|	    simple-string	  |
		|		  |		  |
       internal-thin-string	  |   (vector string-char)
		|		  |		  |
		-----------------------------------
		|				  |
		|				  |
   simple-internal-thin-string  (simple-array string-char (*))


@Center[Fig-1.b  Structure of string type]




@End[Verbatim]

To compare @B[ε1stringε0] characters with @B[ε1internal-thin-stringε0] characters, it is
necessary to convert both to the @B[ε1string-charε0] format.  This means that
the same character is the same object regardless of whether it is found
in an @B[ε1internal-thin-stringε0] or a normal @B[ε1stringε0].


Next we must discuss character input. The proposal does not discuss what is stored 
in files, nor what happens between the Lispimplementation and a terminal.  
Each system will implement this in itsown way.  Instead, let us discuss the data 
as passed to lisp programs. We think that treating all input data as @B[ε1stringε0] 
is the safest possible course. Since a symbol's p-name string should not be modified, 
it can be optimized.

This may cause performance problems for programs which use only
single-byte characters. The variable @B[ε1*read-default-string-type*ε0] is
provided for these programs.  When its value is @B[ε1internal-thin-stringε0], the system 
expects single-byte characters only. so the system will return input data
in the form of @B[ε1internal-thin-stringε0]. Though it is possible that the system may 
choose to ignore this variable.
@newpage
@Heading[4 Proposed changes to CLtL to support multiple character sets.]

In this section, we list proposed modifications to CLtL.  Chapters 13,
14 and 18 of CLtL are concerned very greatly with multi-byte character, so we specify
modifications to these chapters by making a list of all constants,
functions and variables.  For other chapters we specify only additional
and modifying parts.  Those portions which are not mentioned are
unchanged.

  @b(2  Data Types)

  @b(2.5.2 Strings)
@begin(equation)
   "a string is a specialized vector .... type string-char"
				↓
   "a string is a specialized vector .... type string-char or @B[internal-thin-char]"
@end(equation)
  @b(2.15 Overlap,Inclusion and Disjointness of Types)

   a description of type string-char is changed to :

      Type standard-char is a subtype of @B[internal-thin-char].
      @B[internal-thin-char] is a subtype of string-char.  string-char is a
      subtype of character.

   and add the following :
    
      Type @B[internal-thin-string] is a subtype of vector because @B[internal-thin-string] means 
      (vector internal-thin-char).

   a description of type string is changed to :

      Type string is a subtype of vector because string means (or
      (vector string-char) internal-thin-string).  Type (vector
      string-char) and @B[internal-thin-string] are disjoint or equality.

   a description of type simple-vector,simple-string ... is changed to :
  
      Type simple-vector,simple-string and simple-bit-vector are disjoint subtype of
      simple-array because each one means (simple-array t (*)),
      (or (simple-array string-char (*)),(or (simple-array internal-thin-char (*)) and
      (simple-array bit (*)).

   and add following :

      Type simple-internal-thin-string means (simple-array
      internal-thin-char (*)) and is a subtype of @B[internal-thin-string]. 

      Type (simple-array string-char (*)) and simple-internal-thin-string are disjoint or
      equality.


  @b(4  Type Specifiers)

  @b(4.1 Type Specifier Symbols)

   add followings to system defined type specifiers :

      simple-internal-thin-string
      internal-thin-string
      internal-thin-char


  @b(4.5 Type Specifiers That Specialize)

   "The specialized types (vector string-char) ... data types."
					↓
   "The specialized types (vector internal-thin-char), (vector
   string-char) and (vector bit) are so useful that they have the
   special names string and bit-vector.  Every implementation of Common
   Lisp must provide distinct representation for string and bit-vector
   as distinct specialized data types."

@begin(equation)
  @b(13  Characters)

  @b(13.1 Character Attributes)


    char-code-limit@>[constant]
    char-font-limit@>[constant]
    char-bits-limit@>[constant]

  @b(13.2 Predicates on Characters)

   standard-char-p char@>[constant]

   graphic-char-p char@>[constant]
@begin(quotation)
      a description "graphic characters of font 0 are all of the same width when printed" in
      the CLtL changed to "standard-char without #\Newline of font 0 are all of the same
      width when printed".
@end(quotation)

   string-char-p char @>[function]

   internal-thin-char-p char@>[function]
@begin(quotation)
      this function must be added.  
      the argument char must be a character object.  internal-thin-char-p
      is true if char can be stored into a internal-thin-string, and
      otherwise is false.
@end(quotation)

   alpha-char-p char@>[function]

   upper-case-p char@>[function]
   lower-case-p char@>[function]
   both-case-p char@>[function]
      "If a character is either ... alphabetic."
		↓
      "If a character is either uppercase or lowercase, it is necessarily character
      that alpha-char-p returns true."

   digit-char-p char &optional (radix 10)@>[function]

   alphanumericp char@>[function]

   char= character &rest more-characters@>[function]
   char/= character &rest more-characters@>[function]
   char< character &rest more-characters@>[function]
   char> character &rest more-characters@>[function]
   char<= character &rest more-characters@>[function]
   char>= character &rest more-characters@>[function]

   char-equal character &rest more-characters@>[function]
   char-not-equal character &rest more-characters@>[function]
   char-lessp character &rest more-characters@>[function]
   char-greaterp character &rest more-characters@>[function]
   char-not-greaterp character &rest more-characters@>[function]
   char-not-lessp character &rest more-characters@>[function]

  @b(13.3 Character Construction and Selection)

   char-code char@>[function]
   
   char-bits char@>[function]
   
   char-font char@>[function]
   
   code-char char &optional (bits 0) (font 0)@>[function]

   make-char char &optional (bits 0) (font 0)@>[function]

  @b(13.4 Character Conversion)
   character char@>[function]
   
   char-upcase char@>[function]
   char-downcase char@>[function]
   
   digit-char weight &optional (radix 10) (font 0)@>[function]

   char-int char@>[function]

   int-char char@>[function]

   char-name char@>[function]

   name-char char@>[function]
   
  @b(13.5 Character control-bit functions)

   char-control-bit@>[constant]
   char-meta-bit@>[constant]
   char-super-bit@>[constant]
   char-hyper-bit@>[constant]

   char-bit char name@>[function]

   set-char-bit char name newvalue@>[function]

  @b(14 Sequence)

  @b(14.1 Simple sequence functions)
   elt sequence index@>[Function]

   subseq sequence start &optional end@>[Function]

   copy-seq sequence@>[Function]

   length sequence@>[Function]

   reverse sequence@>[Function]

   nreverse sequence@>[Function]

   make-sequence type size &key :initial-element@>[Function]

  @b(14.2 Sequence connection)
   concatenate result-type &rest sequences@>[Function]

   map result-type function sequence &rest more-sequences@>[Function]

   some predicate sequence &rest more-sequences@>[Function]
   every predicate sequence &rest more-sequences@>[Function]
   notany predicate sequence &rest more-sequences@>[Function]
   notevery predicate sequence &rest more-sequences@>[Function]

   reduce function sequence@>[Function]
			&key :from-end :start :end :initial-value

  @b(14.3 Sequence correction)
   fill sequence item &key :start :end@>[Function]

   replace sequence1 sequence2 &key :start1 :end1 :start2 :end2@>[Function]

   remove item sequence@>[Function]
			&key :from-end :test :test-not 
			     :start :end :count :key
   remove-if test sequence@>[Function]
			&key :from-end :start
			     :end :count :key
   remove-if-not test sequence@>[Function]
			&key :from-end :start
			     :end :count :key


   delete item sequence@>[Function]
			&key :from-end :test :test-not 
			     :start :end :count :key
   remove-if test sequence@>[Function]
			&key :from-end :start
			     :end :count :key
   remove-if-not test sequence@>[Function]
			&key :from-end :start
			     :end :count :key

   remove-duplicates sequence@>[Function]
			&key :from-end :test :test-not 
			     :start :end :key
   delete-duplicates sequence@>[Function]
			&key :from-end :test :test-not 
			     :start :end :key

   subsutitute newitem test sequence@>[Function]
			&key :from-end :test :test-not 
			     :start :end :count :key
   subsutitute-if newitem test sequence@>[Function]
			&key :from-end :start :end :count :key
   subsutitute-if-not newitem test sequence@>[Function]
			&key :from-end :start :end :count :key

   nsubsutitute newitem test sequence@>[Function]
			&key :from-end :test :test-not 
			     :start :end :count :key
   nsubsutitute-if newitem test sequence@>[Function]
			&key :from-end :start :end :count :key
   nsubsutitute-if-not newitem test sequence@>[Function]
			&key :from-end :start :end :count :key

  @b(14.4 Search)
   find item sequence @>[Function]
			&key :from-end :test :test-not
			     :start :end :key
   find-if test sequence @>[Function]
			&key :from-end :start :end :key
   find-if-not test sequence>[Function]
			&key :from-end :start :end :key

   position item sequence@>[Function]
			&key :from-end :test :test-not
			     :start :end :key
   position-if test sequence@>[Function]
			&key :from-end :start :end :key
   position-if-not test sequence@>[Function]
			&key :from-end :start :end :key

   count item sequence@>[Function]
			&key :from-end :test :test-not
			     :start :end :key
   count-if item sequence@>[Function]
			&key :from-end :start :end :key
   count-if-not item sequence@>[Function]
			&key :from-end :start :end :key

   mismatch sequence1 sequence2@>[Function]
			&key :from-end :test :test-not
			     :key :start1 :start2 
			     :end1 :end2

   search sequence1 sequence2@>[Function]
			&key :from-end :test :test-not
			     :key :start1 :start2
			     :end1 :end2



  @b(14.5 Sort,merge)

   sort sequence predicate &key :key@>[Function]

   stable-sort sequence predicate &key :key@>[Function]

   merge result-type sequence1 sequence2 predicate &key :key@>[Function]


  @b(18 Strings)

   "the type string is identical ... (array string-char (*))."
				↓
   "the type string is identical to the type
    (or (vector internal-thin-char) (vector string-char)), 
    which in turn is the same as (or (array internal-thin-char (*))
    (array string-char (*)))."

  @b(18.3 String Construction and Manipulation)

   make-string size &key :initial-element@>[function]

@begin(quotation)
      add following :

      To make an internal-thin-string, you should use make-array or make-sequence.
@end(quotation)

   
  @b(22  Input/Output)

  @b(22.2 Input Functions)

  @b(22.2.1 Output to Character Stream)

   add following :
  
      *read-default-string-type*@>[variables]
@begin(quotation)
        The value is string or internal-thin-string.  This determines string that the function 
        read takes whether type string or internal-thin-string.
@end(quotation)

  @b(22.3 Output Functions)

  @b(22.3.1 Output from Character Stream)
@begin(quotation)
   add following :
@end(quotation)

      write-width object@>[function]
			&key :unit-type :stream :escape :radix :base
			     :circle :pretty :label :length :case :gensym :array
@begin(quotation)
        This function returns the printed width as the value of the unit
        specified by :unit-type when then printed representation of
        object is written to the output stream specified by :stream.  It
        returns nil when object includes control characters
        (#\Newline,#\Tab etc).  The default of :unit-type is byte.  The
        value which we can specify :unit-type depends on implementation.
@end(quotation)
@end(equation)
@newpage
@Heading[Appendix Proposed Japanese character processing facilities for Common Lisp.]

In addition to the modification of CLtL, here are some suggestions for systems 
including Japanese characters.

 1). How should system behave for Japanese characters both
under unmodified part of CLtL and the part changed for multi-byte
processing.

 2). About function that are specific to Japanese and no at all related
to multi-byte processing.

 Notes: All Japanese characters are constituent. JIS is a abreviation of Japanese Industry 
Standard.
@begin(equation)
   @b(13. Characters)

   @b(13.1. Character Attributes)

    char-code-limit char @>[Function]
@begin(quotation)
	The value of char-code-limit should be large enough to include Japanese characters,
	e.g. 65536.
@end(quotation)

   @b(13.2. Predicates on Characters)

    standard-char-p char @>[Function]
@begin(quotation)
	Return nil for all Japanese characters.
@end(quotation)
	
    graphic-char-p char @>[Function]
@begin(quotation)
	Return t for Japanese characters.
@end(quotation)

   internal-thin-char-p char @>[Function]
@begin(quotation)
	The result depends on each implementation that whether the Japanese character is in
	internal-thin-string or not.
@end(quotation)

    alpha-char-p char @>[Function]
@begin(quotation)
	Return nil for all character except alphabets in Japanese character.  It depends on
        each implementation whether to return t or nil for alphabets in Japanese characters.
@end(quotation)

@newpage

    jis-char-p char@>[Function]
@begin(quotation)
	The argument char has to be a character type object.  jis-char-p is true if the 
argument is included in JIS C-6226, and otherwise false.
@end(quotation)

    japanese-char-p char@>[Function]
@begin(quotation)
	The argument char has to be a character type object.  japanese-char-p is true if the
	argument is a Japanese character and is otherwise false.  All characters that satisfy
        jis-char-p must satisfy japanese-char-p; other characters might.
@end(quotation)
	
    kanji-char-p char@>[Function]
@begin(quotation)
	The argument char has to be character type object.  kanji-char-p is true if the
        argument is one of the 6353 Kanji characters in JIS C6226(3.1.8), the repeat symbol,
	the kanji numeric zero or the same as above symbol for a total of 6356 characters
        that also satisfy jis-char-p. 
@end(quotation)

    hiragana-char-p char@>[Function]
@begin(quotation)
	The argument char has to be character type object.
	hiragana-char-p is true if the argument is one of the 83
	hiragana characters in JIS C6226(3.1.4), the hiragana repeat
	symbol, or dakuten for a total of 85 characters that also
	satisfy jis-char-p.
@end(quotation)

    katakana-char-p char@>[Function]
@begin(quotation)
	The argument char has to be a character type object.
	katakana-char-p is true if the argument is one of the 86
	hiragana characters in JIS C6226(3.1.5), long-sound-symbol,
	katakana-repeat symbol, or katakana-dakuten for a total of 89
	characters that also satisfy jis-char-p.
@end(quotation)

    kana-char-p char@>[Function]
@begin(quotation)
	equivalence (or (hiragana-char-p char) (katakana-char-p char))
@end(quotation)

    upper-case-p char@>[Function]
    lower-case-p char@>[Function]
    both-case-p char@>[Function]
@begin(quotation)
	These are nil if the argument does not satisfy alpha-char-p.
	Japanese characters which satisfy alpha-char-p should be treated
	as normal alphabetic characters.
@end(quotation)
@newpage
    digit-char-p char &optional (radix 10)@>[Function]
@begin(quotation)
	digit-char-p is nil if the argument is a Japanese character.
@end(quotation)

    alphanumericp char@>[Function]
@begin(quotation)
	equivalence (or (alpha-char-p char) (not (null (digit-char-p char))))
@end(quotation)

    char= character &rest more-characters@>[Function]
    char/= character &rest more-characters@>[Function]
    char< character &rest more-characters@>[Function]
    char> character &rest more-characters@>[Function]
    char<= character &rest more-characters@>[Function]
    char>= character &rest more-characters@>[Function]
@begin(quotation)
	The ordering of hiragana, katakana, kanji follows the JIS ordering.
@end(quotation)

   @b(13.4 character Conversions)

    char-upcase char@>[Function]
    char-downcast char@>[Function]
@begin(quotation)
	These return the argument if the argument does not satisfy
	alpha-char-p.  It depends on the implementation whether these
	work on the alphabets included in JIS or not. But it should be
	consistent with upper-case-p, lower-case-p, both-case-p.
@end(quotation)
@end(equation)





∂18-May-87  1547	berman@vaxa.isi.edu 	Format   
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 18 May 87  15:46:52 PDT
Posted-Date: Mon, 18 May 87 15:46:42 PDT
Message-Id: <8705182246.AA12230@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
	id AA12230; Mon, 18 May 87 15:46:45 PDT
To: common-lisp@sail.stanford.edu
Subject: Format
Date: Mon, 18 May 87 15:46:42 PDT
From: Richard Berman <berman@vaxa.isi.edu>


What should this do:

(FORMAT () "~E" 3/4)

I have one implementation that produces "0.75" and another that produces
"7.5E-1".  As far as I can detect, the latter MAY be correct.  CLtL says, on
page 393 about the ~E directive, "If all of [the parameters] are omitted, then
the effect is to print the value using ordinary free-format
exponential-notation output; prin1 uses this format for any non-zero number
whose magnitude is less than 10↑-3 or greater than or equal to 10↑7.
     "If arg is a rational number, then it is coerced to be a single-float and
then printed."

	It is unclear whether: (a) the same format used by prin1 for numbers
in the given range should be used regardless of the range of the arg, or (b)
if it should print like prin1.

	It seems the former interpretation may be correct, as it clearly
states that the format used is used by prin1 "for any non-zero number whose
magnitude...", and it is the *format* we are talking about, not "what prin1"
does.  I would like clarification of this point.

Thanks in advance.

RB

∂18-May-87  1719	barmar@Think.COM 	Format 
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 18 May 87  17:19:32 PDT
Received: from xavier by Think.COM via CHAOS; Mon, 18 May 87 20:21:49 EDT
Date: Mon, 18 May 87 20:18 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Format
To: Richard Berman <berman@vaxa.isi.edu>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8705182246.AA12230@vaxa.isi.edu>
Message-Id: <870518201858.7.BARMAR@XAVIER.THINK.COM>

    Date: Mon, 18 May 87 15:46:42 PDT
    From: Richard Berman <berman@vaxa.isi.edu>


    What should this do:

    (FORMAT () "~E" 3/4)

    I have one implementation that produces "0.75" and another that produces
    "7.5E-1".  As far as I can detect, the latter MAY be correct.  CLtL says, on
    page 393 about the ~E directive, "If all of [the parameters] are omitted, then
    the effect is to print the value using ordinary free-format
    exponential-notation output; prin1 uses this format for any non-zero number
    whose magnitude is less than 10↑-3 or greater than or equal to 10↑7.
	 "If arg is a rational number, then it is coerced to be a single-float and
    then printed."

	    It is unclear whether: (a) the same format used by prin1 for numbers
    in the given range should be used regardless of the range of the arg, or (b)
    if it should print like prin1.

To me, that sentence strictly says that PRIN1 may contain code like the
following:
	(when (and (not (= number 0.0))
		   (or (< number 1.0e-3)
		       (>= number 1.0e7)))
	  (format stream "~E" number))

which I guess corresponds to your (a).

Whether that is what was intended is a different story....
						barmar

∂18-May-87  1736	Olasov.StudentNS@MIT-Multics.ARPA 	Communications packages in Common LISP  
Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 18 May 87  17:36:13 PDT
Acknowledge-To:  Olasov@MIT-Multics.ARPA
Date:  Mon, 18 May 87 20:22 EDT
From:  Olasov@MIT-Multics.ARPA
Subject:  Communications packages in Common LISP
To:  common-lisp@SAIL.STANFORD.EDU
Message-ID:  <870519002252.487741@MIT-Multics.ARPA>

Hello,

Does  anyone  know  of  communications programs written in Common LISP for IBM
80286  type  machines  that  can  perform  not  only  the usual modem software
functions, i.e.  dialing, receiving files, sending files, answering, etc.  but
which also allow the user to develop routines for processing character streams
from  the  foreign  host,  and  responding to them according to user specified
directives?  Alternatively, is anyone developing such applications?  In either
case, I'd be very interested to hear about these applications. 

Thanks,

Ben Olasov

<Olasov@MIT-MULTICS.ARPA>

∂18-May-87  2222	@RELAY.CS.NET:MURRAY@cs.umass.edu 	User-Visible Declarations and Proclamations  
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 May 87  22:22:45 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ae11645; 19 May 87 1:17 EDT
Received: from cs.umass.edu by RELAY.CS.NET id ao13616; 19 May 87 1:11 EDT
Date: Mon, 18 May 87 12:04 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
Subject: User-Visible Declarations and Proclamations
To: common-lisp@SAIL.STANFORD.EDU
X-VMS-To: CLMAIL


   Because of all the interest in the Maps, I've rewritten Dan Corkill's
 original code to handle sequences as well as lists (as well as other changes).
 The code is now available (I'm sending it out via Netmail), and Dan
 should have a paper on the Maps finished up real soon now.  

 Since the code now works on both sequences and lists, it must test
 at run-time what kind of argument it has (similiar to the MAP-INTO code).
 This could be avoided if the type was declared to be a list or vector.

 I would like to solicit discussion on the possibility of providing one
 or more functions or variables in Common Lisp to provide information 
 about any declarations or proclaimations that are in effect.   

 Previous mail by a number of people has indicated a desire to be able to
 determine whether a variable has been proclaimed special (e.g. DEFVAR).
 This is another example of the general problem.

 For type declarations, something like (DECLARED-RESULT-TYPE Form) --> Type  
 would allow macro-expanders to possibly generate much more efficient code.  
 I imagine all systems with a compiler have this kind of a function in one
 form or another.  A system could always just return T.

 What about defining the global variables *speed*, *safety*, and
 *compiler-speed* to be bound to their proclaimed values?

 Another possibility is to have one general function that takes as arguments
 what kind of information is requested.

 - Kelly Murray
   University of Massachusetts

∂19-May-87  1136	Moon@STONY-BROOK.SCRC.Symbolics.COM 	User-Visible Declarations and Proclamations
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 May 87  11:36:16 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 143821; Tue 19-May-87 14:34:22 EDT
Date: Tue, 19 May 87 14:34 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: User-Visible Declarations and Proclamations
To: MURRAY%cs.umass.edu@RELAY.CS.NET
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: The message of 18 May 87 12:04 EDT from MURRAY%cs.umass.edu@RELAY.CS.NET
Message-ID: <870519143423.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 18 May 87 12:04 EDT
    From: MURRAY%cs.umass.edu@RELAY.CS.NET
    ....
    Since the code now works on both sequences and lists, it must test
    at run-time what kind of argument it has (similiar to the MAP-INTO code).
    This could be avoided if the type was declared to be a list or vector.

    I would like to solicit discussion on the possibility of providing one
    or more functions or variables in Common Lisp to provide information 
    about any declarations or proclaimations that are in effect.   

    Previous mail by a number of people has indicated a desire to be able to
    determine whether a variable has been proclaimed special (e.g. DEFVAR).
    This is another example of the general problem.

    For type declarations, something like (DECLARED-RESULT-TYPE Form) --> Type  
    would allow macro-expanders to possibly generate much more efficient code.  
    I imagine all systems with a compiler have this kind of a function in one
    form or another.  A system could always just return T.

    What about defining the global variables *speed*, *safety*, and
    *compiler-speed* to be bound to their proclaimed values?

    Another possibility is to have one general function that takes as arguments
    what kind of information is requested.

This sort of thing would probably be useful, although I think it's clear that
it needs to be thought out a lot more carefully before standardizing on anything.
However, I don't think you need it for your particular application.  Just expand
into a TYPECASE and rely on the compiler to constant-fold it if the type tests
have known results due to declarations.  Perhaps not all compilers do this
optimization, but it's a reasonable optimization to expect.

∂19-May-87  1139	berman@vaxa.isi.edu 	~% Directive  
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87  11:39:16 PDT
Posted-Date: Tue, 19 May 87 11:38:22 PDT
Message-Id: <8705191838.AA02897@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
	id AA02897; Tue, 19 May 87 11:38:54 PDT
To: common-lisp@sail.stanford.edu
Subject: ~% Directive
Date: Tue, 19 May 87 11:38:22 PDT
From: Richard Berman <berman@vaxa.isi.edu>


Hi again.

do you know what this should do?

(FORMAT NIL "~-1%")

CLtL pg 397 says
"This outputs a #\Newline character, thereby terminating the current output
line and beginning a new one (see TERPRI).  ~n% outputs n newlines.  No arg is
used..."

No mention of <1 values being ignored, errors, etc.  Which is it?  Eh?

RB

∂19-May-87  1220	FAHLMAN@C.CS.CMU.EDU 	~% Directive 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87  12:20:33 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 19 May 87 15:19:54-EDT
Date: Tue, 19 May 1987  15:19 EDT
Message-ID: <FAHLMAN.12303677629.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Richard Berman <berman@VAXA.ISI.EDU>
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: ~% Directive
In-reply-to: Msg of 19 May 1987  14:38-EDT from Richard Berman <berman at vaxa.isi.edu>


    do you know what this should do?

    (FORMAT NIL "~-1%")

Two choices:

1. "It is an error."
2. "Crank up the monitor's voltage and send a lethal blast of X-rays
   into the face of the person issuing such a silly command."

Since not all machines can support solution 2, we should probably go
with 1, even though 2 is the more elegant and long-lasting solution.

But seriously, there seem to be a number of places in the format
directives where negative numbers would make no sense.  I don't think
that all of these are explicitly flagged.  This should probably be fixed
up in the standard, but until then it seems reasonable to assume
non-negative integers unless there's some obvious meaning for the
negative case.

-- Scott

∂19-May-87  1347	berman@vaxa.isi.edu 	More FORMAT   
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87  13:47:40 PDT
Posted-Date: Tue, 19 May 87 13:47:25 PDT
Message-Id: <8705192047.AA04062@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
	id AA04062; Tue, 19 May 87 13:47:27 PDT
To: common-lisp@sail.stanford.edu
Subject: More FORMAT
Date: Tue, 19 May 87 13:47:25 PDT
From: Richard Berman <berman@vaxa.isi.edu>


Oh yeah, and what about using non-defined flags, like so:

(FORMAT NIL "~:%")

Ignore?

Error?

I am testing a couple implementations which handle such things differently
(one implementation generaly ignores things which were not defined
specifically in CLtL, the other always signals an error for such things.)

MORE HAIR SPLITTING:

Page 389, CLtL:

as regards ~:@R, what if the arg is zero?  There is no old roman for this.
One implementation just prints 0, the other signals an error!

Another case:  ~:@R again.

Given an argument above 3999, the "forgiving" implementation just prints it as
a decimal integer.  The "unforgiving" implimentation causes an error.

Is this 'cuz the old romans didn't count pas 3999 or somethin'?

The above is also true for ~@R.

Now, for ~:R...

Is there an authoritative source on how one spells the zero ordinance?  Is it
"ZEROTH" or "ZEROETH".  These implementation give different results.

-----------------------------
 
A related subject.

Both these implementations accept the following:

(setq x (make-array 10 :element-type 'string-char :fill-pointer 0))

(format x "test")

X => "test"

I can not find any reference that indicates a string may be used as a stream.
The nearest thing is on page 331, WITH-OUTPUT-TO-STRING.  This appears to
exactly describe the behavior described above (as if the following
transformation had occured)
(with-output-to-string (foo x) (format foo "test"))

However, I don't find anything in FORMAT which says this is expected or
allowed.  Of course, (STREAMP X) => NIL.  

One of these implementations even violates this further, by extending X if it
goes beyond 10 characters.  I can find absolutely nothing to allow this, as it
is not :adjustable.  In fact, every possible justifying reference to allowing
the above FORMAT would still cause an error (or would just ignore) in the case
of over extension.  

HELP!

RB

∂19-May-87  1511	Moon@STONY-BROOK.SCRC.Symbolics.COM 	More FORMAT  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 May 87  15:11:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 144146; Tue 19-May-87 17:46:18 EDT
Date: Tue, 19 May 87 17:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: More FORMAT
To: Richard Berman <berman@vaxa.isi.edu>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8705192047.AA04062@vaxa.isi.edu>
Message-ID: <870519174622.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 19 May 87 13:47:25 PDT
    From: Richard Berman <berman@vaxa.isi.edu>
    ....
    (setq x (make-array 10 :element-type 'string-char :fill-pointer 0))

    (format x "test")

    X => "test"

    I can not find any reference that indicates a string may be used as a stream.

Look harder, it's right at the top of page 386.  It's not being used as a stream,
it's being used as a format destination.

    One of these implementations even violates this further, by extending X if it
    goes beyond 10 characters.  I can find absolutely nothing to allow this, as it
    is not :adjustable.

In some implementations all arrays are adjustable even if you didn't explicitly
ask for an adjustable array in make-array.

∂19-May-87  1524	berman@vaxa.isi.edu 	Re: More FORMAT    
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87  15:23:59 PDT
Posted-Date: Tue, 19 May 87 15:22:17 PDT
Message-Id: <8705192222.AA05902@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
	id AA05902; Tue, 19 May 87 15:22:29 PDT
To: "David A. Moon" <Moon@stony-brook.scrc.symbolics.com>
Cc: Richard Berman <berman@vaxa.isi.edu>, common-lisp@sail.stanford.edu
Subject: Re: More FORMAT 
In-Reply-To: Your message of Tue, 19 May 87 17:46:00 -0400.
             <870519174622.9.MOON@EUPHRATES.SCRC.Symbolics.COM> 
Date: Tue, 19 May 87 15:22:17 PDT
From: Richard Berman <berman@vaxa.isi.edu>



Thanks for the ref: on page 386.  As for some implementations defaulting to
adjustable arrays, page 288 says, of the :adjustable keyword in make-array,
"...if specified and not nil, indicates that it must be possible to alter the
array's size dynamically after it is created.  This argument defaults to nil."

Granted, this does not say that a value of nil prohibits adjustability, but
only that it must be adjustable if given non-nil.  Do you interpret this as
meaning  "nil value *may* indicate it is possible to alter ...."?  

I hope there is a way to have guaranteed non-adjustable arrays!

RB

∂19-May-87  1608	barmar@Think.COM 	Re: More FORMAT  
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 19 May 87  16:08:01 PDT
Received: from ueberweg by Think.COM via CHAOS; Tue, 19 May 87 19:09:55 EDT
Date: Tue, 19 May 87 19:07 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Re: More FORMAT 
To: Richard Berman <berman@vaxa.isi.edu>
Cc: David A. Moon <Moon@stony-brook.scrc.symbolics.com>,
        common-lisp@sail.stanford.edu
In-Reply-To: <8705192222.AA05902@vaxa.isi.edu>
Message-Id: <870519190744.8.BARMAR@UEBERWEG.THINK.COM>

    Date: Tue, 19 May 87 15:22:17 PDT
    From: Richard Berman <berman@vaxa.isi.edu>



    Thanks for the ref: on page 386.  As for some implementations defaulting to
    adjustable arrays, page 288 says, of the :adjustable keyword in make-array,
    "...if specified and not nil, indicates that it must be possible to alter the
    array's size dynamically after it is created.  This argument defaults to nil."

    Granted, this does not say that a value of nil prohibits adjustability, but
    only that it must be adjustable if given non-nil.  Do you interpret this as
    meaning  "nil value *may* indicate it is possible to alter ...."?  

:adjustable T means "I plan on adjusting this array, so make sure it is
adjustable."  :adjustable NIL means "I don't plan on adjusting this
array, so don't go out of your way to make it adjustable."  The response
to the latter on some systems is, "oh, it's no trouble."

    I hope there is a way to have guaranteed non-adjustable arrays!

Some systems (Maclisp, for example!) don't have non-adjustable arrays.

This is no different from the element type.  If you specify
:element-type 'integer you are requiring Lisp to create an array that
can at least hold integers.  It doesn't prohibit it from creating an
array that can hold other things, too.

The way to think of these things is as hints or declarations.  Telling
the system that you only plan on storing integers or that you don't plan
on adjusting the array allows it to choose an optimal array format.  If
a particular implementation chooses not to perform a particular
optimization it doesn't affect the semantics.
						barmar

∂19-May-87  1618	Daniels.pa@Xerox.COM 	Re: More FORMAT   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 May 87  16:18:41 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 MAY 87 16:10:39 PDT
Date: 19 May 87 16:10 PDT
From: Daniels.pa@Xerox.COM
Subject: Re: More FORMAT
In-reply-to: Richard Berman <berman@vaxa.isi.edu>'s message of Tue, 19
 May 87 13:47:25 PDT
To: berman@vaxa.isi.edu
cc: common-lisp@sail.stanford.edu
Message-ID: <870519-161039-1087@Xerox>

I believe that all format directives not covered by the standard should
be "is an error." This includes providing incorrect arguments to the
format directives as well as using undefined format directives.
Implementations are then free to ignore the colon in "~:%", signal an
error, or even provide an extension that gives this a meaning. In the
latter case, it would be nice if there were a mode that does flag
nonstandard usages.

~@R and ~:@R are abominations, but if we have to have them, I agree that
the standard should specify what ranges of numbers are covered by these
directives. Cleanup committe: has anyone looked into this?

    I can not find any reference that indicates a string may be
    used as a stream. The nearest thing is on page 331,
    WITH-OUTPUT-TO-STRING.  This appears to exactly describe the
    behavior described above (as if the following transformation had
    occured) (with-output-to-string (foo x) (format foo "test"))

    However, I don't find anything in FORMAT which says this is
    expected or allowed.  Of course, (STREAMP X) => NIL.  

CLtL p. 386: "If destination is a string with a fill pointer, then in
effect the output characters are added to the end of the string (as if
by use of VECTOR-PUSH-EXTEND)." So the implementation in question was
correct in appending the formatted output to the string.

    One of these implementations even violates this further, by
    extending X if it goes beyond 10 characters.  I can find absolutely
    nothing to allow this, as it is not :adjustable.  In fact, every
    possible justifying reference to allowing the above FORMAT would
    still cause an error (or would just ignore) in the case of over
    extension.

Indeed, CLtL p. 296 explicitly states that if the fill pointer gets too
large and the vector is not adjustable, an error should be signalled. 

∂19-May-87  1802	sandra%orion@cs.utah.edu 	All arrays can be adjustable?
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87  18:02:29 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
	id AA12308; Tue, 19 May 87 19:03:37 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
	id AA04735; Tue, 19 May 87 19:03:33 MDT
Date: Tue, 19 May 87 19:03:33 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8705200103.AA04735@orion.utah.edu>
Subject: All arrays can be adjustable?
To: common-lisp@sail.stanford.edu


  From: barmar@Think.COM (Barry Margolin)
  Date: 19 May 87 23:07:00 GMT

      Date: Tue, 19 May 87 15:22:17 PDT
      From: Richard Berman <berman@vaxa.isi.edu>

      I hope there is a way to have guaranteed non-adjustable arrays!

  Some systems (Maclisp, for example!) don't have non-adjustable arrays.

  The way to think of these things is as hints or declarations.  Telling
  the system that you only plan on storing integers or that you don't plan
  on adjusting the array allows it to choose an optimal array format.  If
  a particular implementation chooses not to perform a particular
  optimization it doesn't affect the semantics.
  						barmar


It's definitely wrong for make-array to randomly return adjustable arrays
when the user doesn't specifically ask for them.  From page 289:  "If 
make-array is called with the :adjustable, :fill-pointer, and :displaced-to 
arguments all either unspecified or nil, then the resulting array is 
guaranteed to be a simple array."  

This actually sounds like a good problem for the cleanup committee to 
address.  As I see it, a correct implementation needs to do two things:

(1) Ensure that things like svref work correctly on things that 
are supposed to be simple arrays:

	(svref (make-array 3 :initial-element 'foo) 0)

(2) Ensure that user programs can distinguish arrays that are supposed to
be simple arrays from those that are not, regardless of whether or not
simple arrays use the same internal representation as non-simple arrays.

	(simple-vector-p (make-array 3 :initial-element 'foo)) => true
	(simple-vector-p (make-array 3 :adjustable t)) => false


I do agree that this problem is similar to whether or not the implementation
has specialized representations for arrays that can only contain a specified
element type.  However, this issue has the same semantic problems as above.
Would you like to get a general vector back when you're expecting a simple
string?  Especially if it doesn't even print like a string?

-Sandra
-------

∂19-May-87  1835	Moon@STONY-BROOK.SCRC.Symbolics.COM 	All arrays can be adjustable?    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 May 87  18:35:07 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 144366; Tue 19-May-87 21:34:22 EDT
Date: Tue, 19 May 87 21:34 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: All arrays can be adjustable?
To: Sandra J Loosemore <sandra%orion@cs.utah.edu>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8705200103.AA04735@orion.utah.edu>
Message-ID: <870519213421.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 19 May 87 19:03:33 MDT
    From: sandra%orion@cs.utah.edu (Sandra J Loosemore)

    It's definitely wrong for make-array to randomly return adjustable arrays
    when the user doesn't specifically ask for them.  

I disagree.  See below.

						      From page 289:  "If 
    make-array is called with the :adjustable, :fill-pointer, and :displaced-to 
    arguments all either unspecified or nil, then the resulting array is 
    guaranteed to be a simple array."  

    This actually sounds like a good problem for the cleanup committee to 
    address.  As I see it, a correct implementation needs to do two things:

    (1) Ensure that things like svref work correctly on things that 
    are supposed to be simple arrays:

	    (svref (make-array 3 :initial-element 'foo) 0)

Of course.

    (2) Ensure that user programs can distinguish arrays that are supposed to
    be simple arrays from those that are not, regardless of whether or not
    simple arrays use the same internal representation as non-simple arrays.

I don't see anything in CLtL that requires this.  It seems like a bad
idea, because it would require all implementations to be more complex
without giving any benefit to the user.  The concept of simple arrays
exists because in some implementations they can be more efficient than
full arrays, not because people have a need to write application programs
that use simple arrays.  Simple arrays don't give any extra expressive
power.

    I do agree that this problem is similar to whether or not the implementation
    has specialized representations for arrays that can only contain a specified
    element type.  However, this issue has the same semantic problems as above.
    Would you like to get a general vector back when you're expecting a simple
    string?  Especially if it doesn't even print like a string?

If you think about it for a moment I think you'll realize how false this
analogy is.  No one is proposing to change how anything prints, or indeed to
do anything other than not enforce a restriction.  The distinction between
strings and general vectors is quite different from the distinction between
simple arrays and full arrays.  I believe Margolin's original analogy was
a different one, referring to the lack of semantic problems when you ask
for an array that can only hold integers and get an array that can hold
anything.

∂19-May-87  2000	DLA@DIAMOND.S4CC.Symbolics.COM 	All arrays can be adjustable?    
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 19 May 87  19:59:51 PDT
Received: from LIMPKIN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 88321; Tue 19-May-87 22:21:35 EDT
Date: Tue, 19 May 87 22:21 EDT
From: David L. Andre <DLA@DIAMOND.S4CC.Symbolics.COM>
Subject: All arrays can be adjustable?
To: sandra%orion@cs.utah.edu
cc: common-lisp@sail.stanford.edu, DLA@DIAMOND.S4CC.Symbolics.COM
In-Reply-To: <8705200103.AA04735@orion.utah.edu>
Message-ID: <870519222134.7.DLA@LIMPKIN.S4CC.Symbolics.COM>

    Date: Tue, 19 May 87 19:03:33 MDT
    From: sandra%orion@cs.utah.edu (Sandra J Loosemore)

    It's definitely wrong for make-array to randomly return adjustable arrays
    when the user doesn't specifically ask for them.

I don't think the issue is whether or not users can tell whether arrays
are simple or adjustable.  The issue is what action CL primitives should
take with respect to extending arrays, if that would be a plausible
option of their contract.

∂19-May-87  2000	@DIAMOND.S4CC.Symbolics.COM:Cyphers@YUKON.SCRC.Symbolics.COM 	All arrays can be adjustable?    
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 19 May 87  19:59:54 PDT
Received: from RAVEN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 88320; Tue 19-May-87 22:18:43 EDT
Date: Tue, 19 May 87 22:18 EDT
From: Scott Cyphers <Cyphers@YUKON.SCRC.Symbolics.COM>
Subject: All arrays can be adjustable?
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%orion@cs.utah.edu
cc: common-lisp@sail.stanford.edu
In-Reply-To: <870519213421.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870519221837.3.CYPHERS@RAVEN.S4CC.Symbolics.COM>

    Date: Tue, 19 May 87 21:34 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	Date: Tue, 19 May 87 19:03:33 MDT
	From: sandra%orion@cs.utah.edu (Sandra J Loosemore)

	It's definitely wrong for make-array to randomly return adjustable arrays
	when the user doesn't specifically ask for them.  

    I disagree.  See below.

I mopstly agree with you, but the bottom of page 28 seems to imply that
you can make arrays which are not to be adjusted, and this is one of the
properties of simple arrays.

One use of a non-adjustable array might be when you know that the array
is big enough for your program, and if something which automatically
adjusts adjustable arrays tries to adjust your array to make it bigger,
that means your program is broken somehow.  Rather than letting the
array get grown until you run out of address space to discover this
error, it would be desirable to get an error when the array tried to get
bigger than the size you originally limited it to.  Why something like
this is tied up in the concept of "simple" arrays I don't know; it seems
that an array which is able to provide this service may be less simple
to implement in some implementations.  Maybe the concept of "simple" is
what is bogus?

∂19-May-87  2342	KMP@STONY-BROOK.SCRC.Symbolics.COM 	adjustable arrays  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 May 87  23:42:25 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 144502; Wed 20-May-87 02:41:11 EDT
Date: Wed, 20 May 87 02:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: adjustable arrays
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%orion@cs.utah.edu
cc: common-lisp@sail.stanford.edu, kmp@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <870519213421.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870520024109.4.KMP@TSUKUBA.SCRC.Symbolics.COM>

I think you are both expressing reasonable and relatively coherent
views of the world.

The real problem is that CLtL is not explicit enough to distinguish between
the two cases.  It has insufficient concept exposition about adjustable
arrays to clearly indicate the intent of the authors about what properties
were intentional and which were accidental. Consequently, people made up
their own concepts.

The problem with incomplete specs like this is that there are multiple
extrapolations which are compatible with the base spec, and those 
extrapolations are not necessarily compatible with each other. This result
acts as a real barrier to portability at times.

I can relate to Moon's claims because I use the lispm a lot and believe it to
be an internally consistent correct reading of CLtL in this area. On the
other hand, it's not what I had expected from reading the CL manual. As such,
I know first hand that other people can have internally consistent but
differing readings. I also know first hand that it's a pain to port code
between dialects with conflicting views because it's hard to test the code
in one implementation and have any confidence that it will run in the other.
Whether we decide on the conservative reading that Sandra and others have
pushed or the less conservative reading that Moon asserts was intended, the
important thing is that the manual say clearly what will happen so that users
can simply read the book and know what to expect with no need to do lengthy
deductions about the consequences of what they have or have not read.

I think the issues are clearly understood and little more is to be gained by
prolonged debate at this time. A process (X3J13) exists for introducing 
changes/corrections to CLtL and I think that process should now be asked to
do its job by addressing that issue.

∂20-May-87  0248	Mailer@XX.LCS.MIT.EDU 	Re: More FORMAT  
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87  02:48:00 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 20 May 87 05:46-EDT
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 43464; 20 May 87 05:42:35-EDT
Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 1; 20 May 87 01:29:56-EDT
Date: Wed, 20 May 87 01:01 EDT
From: Don Morrison <dfm@JASPER.PALLADIAN.COM>
Subject: Re: More FORMAT 
To: berman@vaxa.isi.edu
cc: Moon@stony-brook.scrc.symbolics.com, common-lisp@sail.stanford.edu
In-Reply-To: <8705192222.AA05902@vaxa.isi.edu>
Message-ID: <870520010156.3.DFM@WHITBY.PALLADIAN.COM>
Reply-To: Don Morrison <DFM%JASPER@LIVE-OAK.LCS.MIT.EDU>

    Date: Tue, 19 May 87 15:22:17 PDT
    From: Richard Berman <berman@vaxa.isi.edu>

    I hope there is a way to have guaranteed non-adjustable arrays!

Why?  Is there any thing that non-adjustable arrays are good for the adjustable
arrays are not?  I thought it was just that you paid a performance hit for
adjustability in some (typically non-special-microcode) implementations.




∂20-May-87  0635	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	All arrays can be adjustable? 
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 20 May 87  06:35:41 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 88382; Wed 20-May-87 09:33:14 EDT
Date: Wed, 20 May 87 09:37 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: All arrays can be adjustable?
To: Sandra J Loosemore <sandra%orion@cs.utah.edu>, David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
    David L. Andre <DLA@DIAMOND.S4CC.Symbolics.COM>, Scott Cyphers <Cyphers@YUKON.SCRC.Symbolics.COM>,
    Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, common-lisp@sail.stanford.edu
In-Reply-To: <8705200103.AA04735@orion.utah.edu>,
             <870519213421.9.MOON@EUPHRATES.SCRC.Symbolics.COM>,
             <870519222134.7.DLA@LIMPKIN.S4CC.Symbolics.COM>,
             <870519221837.3.CYPHERS@RAVEN.S4CC.Symbolics.COM>,
             <870520024109.4.KMP@TSUKUBA.SCRC.Symbolics.COM>
Message-ID: <870520093735.8.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

Maybe if we could figure out how to express the various types of arrays
using set language we wouldn't accidentally invert phrases.  For
example, I think everybody agrees that simple is a subset of
  (intersect not-adjustable not-fill-pointer not-displaced)
That's the >only< thing that phrase says.  It can't be inverted,
conversed, contra-positived, or anything to say that simple arrays are
not adjustable.  The contra-positive (the only thing provably true) is
that the UNION of adjustable, fill-pointered or displaced arrays is a
subset of non-simple arrays. 

∂20-May-87  0836	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re: More FORMAT  
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 20 May 87  08:36:23 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 83485; Wed 20-May-87 11:35:51 EDT
Date: Wed, 20 May 87 11:35 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: More FORMAT
To: Daniels.pa@Xerox.COM, berman@vaxa.isi.edu
cc: common-lisp@sail.stanford.edu
In-Reply-To: <870519-161039-1087@Xerox>
Message-ID: <870520113503.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Line-fold: No

    Date: 19 May 87 16:10 PDT
    From: Daniels.pa@Xerox.COM

    Indeed, CLtL p. 296 explicitly states that if the fill pointer gets too
    large and the vector is not adjustable, an error should be signalled. 

However, it does not state that (make-array 5) produces an array that it
not adjustable.  No implementation is required to support explicitly
non-adjustable arrays.  It's too bad that CLtL is so unclear about this.
But, for example, if you look at the documentation of :adjustable on p.
288, note the use of the word "must": this is trying to say that
:adjustable t means that it "must" be adjustable, whereas :adjustable
nil means that it need not be adjustable, although it can be.

∂20-May-87  0841	DLW@ALDERAAN.SCRC.Symbolics.COM 	All arrays can be adjustable?   
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 20 May 87  08:41:23 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 83482; Wed 20-May-87 11:31:34 EDT
Date: Wed, 20 May 87 11:31 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: All arrays can be adjustable?
To: Cyphers@YUKON.SCRC.Symbolics.COM
cc: common-lisp@sail.stanford.edu
In-Reply-To: <870519221837.3.CYPHERS@RAVEN.S4CC.Symbolics.COM>
Message-ID: <870520113117.4.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Tue, 19 May 87 22:18 EDT
    From: Scott Cyphers <Cyphers@YUKON.SCRC.Symbolics.COM>

	Date: Tue, 19 May 87 21:34 EDT
	From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	    Date: Tue, 19 May 87 19:03:33 MDT
	    From: sandra%orion@cs.utah.edu (Sandra J Loosemore)

	    It's definitely wrong for make-array to randomly return adjustable arrays
	    when the user doesn't specifically ask for them.  

	I disagree.  See below.

    I mopstly agree with you, but the bottom of page 28 seems to imply that
    you can make arrays which are not to be adjusted, and this is one of the
    properties of simple arrays.

"and is not to have its size adjusted" is just another ambiguous phrase.
I read this to mean "and its caller is not allowed to assume that it
would work to adjust its size"; that is, it makes no promises that
adjusting the size would work.

There is no question what the intention of the writers of CLtL was.  The
idea of "simple" arrays was to provide a way for stock hardware
implementations to implement simpler arrays more cheaply, without making
any impositions on architectures in which there's no extra cost for more
complex arrays.  The wording in CLtL was intended to convey this idea,
but apparently it falls short.

Yes, it might be useful to have a feature that provides for an array
that is guaranteed to signal an error if there is an attempt to adjust
it.  However, CL has no such feature, and I think it's only slightly
useful.  Arrays have enough features as it is; you have to draw the line
somewhere.

∂20-May-87  0851	franz!ficl!jkf@ucbarpa.Berkeley.EDU 	adjustable arrays 
Received: from UCBARPA.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87  08:51:39 PDT
Received: by ucbarpa.Berkeley.EDU (5.57/1.25)
	id AA29057; Wed, 20 May 87 08:51:38 PDT
Received: from ficl by franz (5.5/3.14)
	id AA20347; Wed, 20 May 87 08:20:10 PDT
Received: by ficl (5.5/3.14)
	id AA16895; Wed, 20 May 87 08:20:04 PDT
From: franz!ficl!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <ficl!jkf>
Message-Id: <8705201520.AA16895@ficl>
To: common-lisp@sail.stanford.edu
Subject: adjustable arrays
Date: Wed, 20 May 87 08:20:02 PDT

    To give another data point to the discussion: in our lisp (Extended
Common Lisp) we have a variety of internal array implementations to
satisify the various combinations of array features the user might
select.   I expect most other implemenations do likewise.   Many of
these internal implementations are adjustable however our lisp will
refuse to adjust any array not explictly specified as adjustable by
the user.   Since we're going to extra work to refuse to do something
that we could easily do, there should be a good reason for it, and 
in our case that reason is portabilty.  If a user wants needs an adjustable
array and doesn't specify it, then he'll find out right away instead
of when he ports his code to another lisp.   

    I don't feel that returning a adjustable array when the user
doesn't ask for one 'is an error'.  When you call 'make-array' you ask
for the minimum set of features you need and the system returns
the best thing it can.   Implementations should be encouraged to return
the best match to the user's request, thus if the user doesn't ask for
an adjustable array, then returning an non-adjustable array is better
than returning an adjustable one, but both are valid.

 

- John Foderaro
  Franz Inc.

∂20-May-87  0859	FAHLMAN@C.CS.CMU.EDU 	All arrays can be adjustable?    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87  08:59:32 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 20 May 87 11:51:45-EDT
Date: Wed, 20 May 1987  11:51 EDT
Message-ID: <FAHLMAN.12303901889.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: All arrays can be adjustable?
In-reply-to: Msg of 20 May 1987  09:37-EDT from David C. Plummer <DCP at QUABBIN.SCRC.Symbolics.COM>


    Maybe if we could figure out how to express the various types of arrays
    using set language we wouldn't accidentally invert phrases.  For
    example, I think everybody agrees that simple is a subset of
      (intersect not-adjustable not-fill-pointer not-displaced)
    That's the >only< thing that phrase says.  It can't be inverted,
    conversed, contra-positived, or anything to say that simple arrays are
    not adjustable.  The contra-positive (the only thing provably true) is
    that the UNION of adjustable, fill-pointered or displaced arrays is a
    subset of non-simple arrays. 

Gee, it's been a while since I hacked formal logic in any serious way,
but it seems to be true that if X is a subset of the intersection of A,
B, C, and D, then X is (provably) a subset of A.  I cheated and used
little pictures instead of contrapositives (my religion forbids the use
of contrapositives, even among consenting adults), but I think it's
still true.  Maybe I should go audit a logic course and see what I'm
doing wrong.

-- Scott

∂20-May-87  0955	@RELAY.CS.NET:DUSSUD%Jenner@TI-CSL.CSNET 	[dg%acorn@oak.lcs.mit.edu:  Re: &REST]
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 20 May 87  09:55:48 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ad00189; 20 May 87 12:25 EDT
Received: from ti-csl by RELAY.CS.NET id ad24696; 20 May 87 12:01 EDT
Received: by tilde id AA16282; Wed, 20 May 87 08:54:45 CDT
Message-Id: <2757506096-3811281@Jenner>
Date: Wed, 20 May 87  08:54:56 CDT
From: Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>
To: dg%acorn@LIVE-OAK.LCS.MIT.EDU, "Daniel L. Cerys" <Cerys@xx.arpa>
Cc: common-lisp@SAIL.STANFORD.EDU, Acuff@SUMEX-AIM.STANFORD.EDU
Subject: [dg%acorn@oak.lcs.mit.edu:  Re: &REST]
In-Reply-To: Msg of Tue, 19 May 87  09:58:50 EDT from "Daniel L. Cerys" <Cerys@xx.ARPA>

     
     Date: Sun, 17 May 87 17:56 est
     From: dg%acorn@oak.lcs.mit.edu
     Subject: Re: &REST
     To:   Acuff@SUMEX-AIM.STANFORD.EDU
     Cc:   common-lisp@SAIL.STANFORD.EDU
     
         Date: Fri, 15 May 87 14:01:46 PDT
         From: Richard Acuff <Acuff@SUMEX-AIM.STANFORD.EDU>
         
            For the record, in Release 3, TI has attempted, with apparent
         success, to remove the restrictions on using &REST lists outside of
         the dynamic scope of the parameter.  (While increasing the performance
         of the system, to boot.)
         
         	-- Rich
         -------
     
     Are there exactly 0 restrictions now?
     
     Does this mean that removing the restrictions actually improved the
     performance of the system, or was that just coincidental?
     
     -dg
     

There are 0 restrictions on using &REST lists outside of the dynamic
scope of the parameter. The way we do it is the following:
We have a new datatype for &rest args (A list on the stack). When
somebody tries to store a pointer of type stack-list, the microcode
triggers a copy. The copy process is recursive if the &rest args are
nested. The copy is done is such a way that it preserves EQness. Since
the data type check is hardware assisted, it is done without performance
penalty.

The performance improvement is coincidental.

Patrick.

∂20-May-87  1013	johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK   
Received: from [14.0.0.9] by SAIL.STANFORD.EDU with TCP; 20 May 87  10:13:14 PDT
Received: from cvaxa.sussex.ac.uk by mv1.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa09225; 20 May 87 18:07 BST
From: John Williams <johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK>
Date: Wed, 20 May 87 17:35:43 gmt
Message-Id: <5464.8705201735@cvaxa.sussex.ac.uk>
To: common-lisp@sail.stanford.edu

Am I right in thinking that Cltl does not specify the result(s)
returned by the following functions:

    DISASSEMBLE
    DRIBBLE
    ED
    INSPECT
    PROCLAIM
    ROOM

∂20-May-87  1039	las@bfly-vax.bbn.com
Received: from BFLY-VAX.BBN.COM by SAIL.STANFORD.EDU with TCP; 20 May 87  10:39:36 PDT
To: common-lisp@sail.stanford.edu
Date: 20 May 87 13:41:08 EDT (Wed)
From: las@bfly-vax.bbn.com


Regarding Roman numerals:

  Having recently visited Roman-numeral land, I too was curious about implementations that 
did not print Romam numerals above 3999 (new) or 4999 (old). Not recalling the entirety
of my elementary school education, I consulted the Table of Numbers in
Webster's Ninth New Collegiate Dictionary (page 812).

  Roman numerals above 1000 are written with "bars" above them. These have no ascii
equivalent. Use of lower case is equivalent to the upper case use. Below, a hyphen
following a letter is to be interpreted as a bar above it.
The numerals above 1000 are:

	     5,000      V-
            10,000  	X-
           100,000      C-
         1,000,000      M-

  The question is: after the year 4999, how will Common Lisp print film copyright
dates?


                                       - Larry Stabile

∂20-May-87  1123	barmar@Think.COM 	DISASSEMBLE, et all return values    
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 20 May 87  11:23:06 PDT
Received: from xavier by Think.COM via CHAOS; Wed, 20 May 87 14:24:21 EDT
Date: Wed, 20 May 87 14:21 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: DISASSEMBLE, et all return values
To: John Williams <johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <5464.8705201735@cvaxa.sussex.ac.uk>
Message-Id: <870520142124.6.BARMAR@XAVIER.THINK.COM>

    Date: Wed, 20 May 87 17:35:43 gmt
    From: John Williams <johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK>

    Am I right in thinking that Cltl does not specify the result(s)
    returned by the following functions:

	DISASSEMBLE
	DRIBBLE
	ED
	INSPECT
	PROCLAIM
	ROOM

It doesn't specify return values in my copy of the book.  That means
that a portable program should not do anything with the values of these
functions.  As far as CLtL is concerned, they are only useful for their
side-effects.
						barmar

∂20-May-87  1158	berman@vaxa.isi.edu 	Re: More FORMAT    
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87  11:56:57 PDT
Posted-Date: Wed, 20 May 87 11:55:34 PDT
Message-Id: <8705201855.AA02717@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
	id AA02717; Wed, 20 May 87 11:55:56 PDT
To: Don Morrison <DFM%JASPER@live-oak.lcs.mit.edu>
Cc: common-lisp@sail.stanford.edu
Subject: Re: More FORMAT 
In-Reply-To: Your message of Wed, 20 May 87 01:01:00 -0400.
             <870520010156.3.DFM@WHITBY.PALLADIAN.COM> 
Date: Wed, 20 May 87 11:55:34 PDT
From: Richard Berman <berman@vaxa.isi.edu>


As someone else mentioned, it can be more than useful to know that something
is causing an array to grow.  It seems reduntant to me to have an :adjustable
keyword if there are no clear semantics to :adjustable nil, only to
:adjustable T.  Especially when :adjustable (non-nil) == :adjustable nil.

Or perhaps we need a :non-adjustable keyword, just to keep our semantics
consistent, where :non-adjustable T means "definitely" non-adjustable, and
:non-adjustable nil means "maybe non-adjustable"?

RB

∂20-May-87  1210	berman@vaxa.isi.edu 
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87  12:10:14 PDT
Posted-Date: Wed, 20 May 87 12:05:53 PDT
Message-Id: <8705201905.AA02808@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
	id AA02808; Wed, 20 May 87 12:05:56 PDT
To: las@bfly-vax.bbn.com
Cc: common-lisp@sail.stanford.edu, berman@vaxa.isi.edu
In-Reply-To: Your message of Wed, 20 May 87 13:41:08 -0400.
             <8705201807.AA02149@vaxa.isi.edu> 
Date: Wed, 20 May 87 12:05:53 PDT
From: Richard Berman <berman@vaxa.isi.edu>


My only question re: roman numerals is:  what does *common lisp* do for values
above the specified range (or unspecified, so far as the spec is concerned).
Do we just not print romans above certain values?  What is printed instead?
Etc.?

RB

∂20-May-87  1239	berman@vaxa.isi.edu 	las@bfly-vax.bbn.com    
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87  12:38:50 PDT
Posted-Date: Wed, 20 May 87 12:38:44 PDT
Message-Id: <8705201938.AA03160@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
	id AA03160; Wed, 20 May 87 12:38:46 PDT
To: common-lisp@sail.stanford.edu
Subject: las@bfly-vax.bbn.com
Date: Wed, 20 May 87 12:38:44 PDT
From: Richard Berman <berman@vaxa.isi.edu>


To everyone else: sorry.


I can't send you mail.  You will have to call me.  213-822-1511

RB

∂20-May-87  1247	las@bfly-vax.bbn.com
Received: from BFLY-VAX.BBN.COM by SAIL.STANFORD.EDU with TCP; 20 May 87  12:47:39 PDT
To: berman@vaxa.isi.edu
CC: common-lisp@sail.stanford.edu
Date: 20 May 87 15:44:22 EDT (Wed)
From: las@bfly-vax.bbn.com

More on Roman numerals:

   I haven't given the question a large amount of thought, but it seems to me that the 
printed representation of a number is as much tied to the font characteristics of a given
output device as it is to the "style" or "language" of the number. 

   This problem seems to apply to other areas as well, such as non-English printing.
Rumbling about Roman numerals only scratches the surface.

   I see the following solutions to the Roman problem:

	1. Print in decimal, when Roman won't work.

	2. Extend the Roman system, e.g.,  V-CCIV = 5204.

	3. Deem it an error.

	4. Extend the character set and sense properties of the output
	   device when printing. This, of course, does not solve
	   the problem in general.

   I think I like (1) best, since it guarantees a number recognizable by
English-speaking humans (which the rest of Common Lisp seems geared to),
and does not lead us into the quagmire of querying devices, extending
character sets, etc. The need to address those problems, however,
is not far off.

                                            -Larry Stabile

∂20-May-87  1251	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	All arrays can be adjustable? 
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 20 May 87  12:50:54 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 88582; Wed 20-May-87 15:48:49 EDT
Date: Wed, 20 May 87 15:53 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: All arrays can be adjustable?
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12303901889.BABYL@C.CS.CMU.EDU>
Message-ID: <870520155306.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

Well, I guess I blew it.  (I had it right when I first wrote it and then
made the mistake of thinking too much and conversed everything.)  The
idea still stands: figure out formal relationships and draw conclusions
from them.  What I meant, in IF-THEN language, was
  Statement:
	IF  not adjustable, and
	    no fill-pointer, and
	    not displaced
	THEN
	    simple
  Contrapositive (for those that believe in it):
	IF not simple
	THEN
	   adjustable, or
	   fill-pointer, or
	   displaced

I agree with whoever (Moon?) said that simple is largely a semantic
concept that allows implementations to get leverage if they can.

∂20-May-87  1359	peck@Sun.COM 	Order of evaluation in PUSH (& PUSHNEW)  
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 20 May 87  13:59:28 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-3.2)
	id AA03347; Wed, 20 May 87 13:55:56 PDT
Received: from denali.sun.com by snail.sun.com (3.2/SMI-3.2)
	id AA05880; Wed, 20 May 87 13:55:28 PDT
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
	id AA29640; Wed, 20 May 87 13:58:00 PDT
Message-Id: <8705202058.AA29640@denali.sun.com>
To: common-lisp@sail.stanford.edu
Subject: Order of evaluation in PUSH (& PUSHNEW) 
Date: Wed, 20 May 87 13:57:56 -0700
From: peck@Sun.COM

 In the form: (push (ref1) (car (ref2)))
It is unclear whether (ref1) should be evaluated before (ref2). 

CLtL, page 270 states:
" The *effect* of (PUSH Item Place) is *roughly* equivalent to
(SETF Place (CONS Item Place))
except that the latter would evaluate any subforms of Place twice
while PUSH takes care to evaluate them only once."

CLtL, in discussion of generalized variable accessors/modifiers,
page 99 states:
"Macros that manipulate generalized variables must guarentee the "obvious"
semantics: subforms of generalized-variable references are evaluated ...
in exactly the same order as they appear in the *source* program."

	[Is this the *definition* of "obvious" semantics...?]

PUSH is in the class of "Macros that manipulate generalized variables".
However, even though the *generalized-variable references*
are evaluated with the "obvious" semantics, should standard macros
necessarily evaluate *all* their arguments in the "obvious" order?

The problem is that PUSH is [almost] specified as a macro which expands 
 to something in which its args are not in the "obvious" source order.

Shall we just agree that PUSH does not follow the "obvious" semantics?

Lucic and Franz evaluate (ref2) then (ref1)
Symbolics evaluate (ref1) then (ref2)

Lucid:
> (macroexpand '(push (ref1) (car (ref2))))
((LAMBDA (#:G2) 
  ((LAMBDA (#:G1) (SET-CAR #:G2 #:G1)) 
   (CONS (REF1) (CAR #:G2)))) 
  (REF2))
T

ExCL:
<cl> (macroexpand '(push (ref1) (car (ref2))))
(LET* ((#:G8 (REF2))
       (#:G7 (CONS (REF1) (CAR #:G8))))
  (EXCL::.INV-CAR #:G8 #:G7)) 
T 

Symbolics:
Command: (macroexpand '(push (ref1) (car (ref2))))
(LET* ((#:G5 (REF1))
       (#:G4 (REF2)))
  NIL
  (SYS:RPLACA2 #:G4 (VALUES (CONS #:G5 (CAR #:G4)))))
T


Definitely one for the CL comittee.

∂20-May-87  1551	berman@vaxa.isi.edu 	:fill-pointer maybe
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87  15:51:51 PDT
Posted-Date: Wed, 20 May 87 15:51:43 PDT
Message-Id: <8705202251.AA05057@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
	id AA05057; Wed, 20 May 87 15:51:46 PDT
To: common-lisp@sail.stanford.edu
Subject: :fill-pointer maybe
Date: Wed, 20 May 87 15:51:43 PDT
From: Richard Berman <berman@vaxa.isi.edu>


Another maybe!

On pg 288, about the :fill-pointer keyword to MAKE-ARRAY:

"This argument specifies that the array should have a fill pointer.  If this
option is specified and not NIL, the array must be one-dimensional.  The value
is used to initialize the fill pointer for the array.  If the value T is
specified, the length of the array is used...etc."

It doesn't say that an array with :fill-pointer nil *doesn't* have a fill
pointer, although it implies that multi-dimensional arrays can't or don't have
one.  I have one implmentation where all vectors have fill pointers, and
another that strictly reports an error when vector-push-extend is called on an
array with no fill pointer.

Any idea if this is intentional relaxation, or oversight?

RB

∂20-May-87  1623	berman@vaxa.isi.edu 	arrays   
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87  16:22:57 PDT
Posted-Date: Wed, 20 May 87 16:22:48 PDT
Message-Id: <8705202322.AA05367@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
	id AA05367; Wed, 20 May 87 16:22:51 PDT
To: common-lisp@sail.stanford.edu
Subject: arrays
Date: Wed, 20 May 87 16:22:48 PDT
From: Richard Berman <berman@vaxa.isi.edu>

On bit vectors:

on page 12:

"One dimensional arrays of bits (that is, of integers whose values are 0 or 1)
are called bit vectors"

implies that any array of all 0 and 1 integers is a bit vector.

Page 29:

"All implementations are also required to provide specialized arrays of bits,
that is, arrays of type (array bit); the one-dimensional instances of this
specialization are called bit-vectors."

Page 286:

"Vectors whose elements are restricted to type bit are called bit-vectors"

This implies strongly that a bit vector won't let one store any other value
than 0 or 1.

So, is this a bit vector?

#(1 0 0 1) and should things like BIT-NOT which specifically want a bit vector
work on it.  Does it return a general vector like this in this case rather
than something like *0110???

It is my *opinion* that #(1 0 0 1) is not a bit vector because there is a
precise input style for such (like *1001) and bit vectors are specialized.

What do you think? Is this a real maybe?

RB

∂20-May-87  1647	FAHLMAN@C.CS.CMU.EDU 	:fill-pointer maybe    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87  16:47:42 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 20 May 87 19:47:14-EDT
Date: Wed, 20 May 1987  19:47 EDT
Message-ID: <FAHLMAN.12303988451.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Richard Berman <berman@VAXA.ISI.EDU>
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: :fill-pointer maybe
In-reply-to: Msg of 20 May 1987  18:51-EDT from Richard Berman <berman at vaxa.isi.edu>


Richard,

It looks to me like you and some others are missing a key concept.

There are an awful lot of places in CLtL where it is specified that
certain things have to work, but where the manual is silent on what
happens if those conditions don't hold.  A classic example is a built-in
function whose arguments "must" be of a certain type.  As a rule, these
unspecified situations should be considered to "be an error".

That phrase means that a legal Common Lisp implementation is free to
extend the language to handle this situation in some allegedly useful
way; it is not required to signal an error or to self-destruct.
Portable Common Lisp code may not depend on any such extensions, but an
implementation is free to extend all it wants.

In some cases where CLtL is silent, it is an oversight and a case can be
made for changing to a "signals an error" case or for specifying exactly
what must happen in that situation.  In most cases, however, the
language is left open-ended deliberately.  The feeling of the designers
was that Common Lisp is a living, growing language, and we didn't want
to bind it all up too tightly by trying to specify EVERYTHING.  "Signals
an error" was only specified in those cases where we felt that an error
signal was essential and where detecting the error would not impose too
great a performance penalty on some calsses of machine.

Now, if an implementation takes advantage of its freedom to extend the
language, and if it does not provide a compiler mode or some other tool
that flags the use of such non-portable extensions, then that
implementation is unsuitable for developing portable applications.  (I
could name some names, but I won't.)  Nevertheless, such implementations
are perfectly legal and are operating within the spirit of the Common
Lisp spec.  The language was meant to be extensible; that was an
important part of the original charter that we set for ourselves.

So, for the purposes of validation, you should treat these unspecified
cases as "is an error" cases and leave them alone (unless it is unclear
whether the case is or is not specified).  It couldn't hurt to make a
list of the ones you encounter for later discussion, but in almost all
cases the default answer is "this situation is an error; implementations
may do what they like".  It is the job of the validation suite to make
sure that the cases that ARE specified are handled correctly.

-- Scott

∂20-May-87  1658	FAHLMAN@C.CS.CMU.EDU 	arrays  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87  16:58:03 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 20 May 87 19:57:39-EDT
Date: Wed, 20 May 1987  19:57 EDT
Message-ID: <FAHLMAN.12303990345.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Richard Berman <berman@VAXA.ISI.EDU>
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: arrays
In-reply-to: Msg of 20 May 1987  19:22-EDT from Richard Berman <berman at vaxa.isi.edu>


    "Vectors whose elements are restricted to type bit are called bit-vectors"

    This implies strongly that a bit vector won't let one store any other value
    than 0 or 1.

This one is right in my opinion.  Sloppy wording in some of the other
descriptions you quote.

    So, is this a bit vector?

    #(1 0 0 1) 

No.

    should things like BIT-NOT which specifically want a bit vector
    work on it.  Does it return a general vector like this in this case rather
    than something like *0110???

They have to work on bit vectors.  It is an error to give it anything
else.  If an implementation wants to handle general vectors that happen
to be full of 1's and 0's, that's a legal extension; in such cases, it
is no business of Common Lisp what it returns.

-- Scott

∂20-May-87  1840	berman@vaxa.isi.edu 	arrays   
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87  16:22:57 PDT
Posted-Date: Wed, 20 May 87 16:22:48 PDT
Message-Id: <8705202322.AA05367@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
	id AA05367; Wed, 20 May 87 16:22:51 PDT
To: common-lisp@sail.stanford.edu
Subject: arrays
Date: Wed, 20 May 87 16:22:48 PDT
From: Richard Berman <berman@vaxa.isi.edu>

On bit vectors:

on page 12:

"One dimensional arrays of bits (that is, of integers whose values are 0 or 1)
are called bit vectors"

implies that any array of all 0 and 1 integers is a bit vector.

Page 29:

"All implementations are also required to provide specialized arrays of bits,
that is, arrays of type (array bit); the one-dimensional instances of this
specialization are called bit-vectors."

Page 286:

"Vectors whose elements are restricted to type bit are called bit-vectors"

This implies strongly that a bit vector won't let one store any other value
than 0 or 1.

So, is this a bit vector?

#(1 0 0 1) and should things like BIT-NOT which specifically want a bit vector
work on it.  Does it return a general vector like this in this case rather
than something like *0110???

It is my *opinion* that #(1 0 0 1) is not a bit vector because there is a
precise input style for such (like *1001) and bit vectors are specialized.

What do you think? Is this a real maybe?

RB

∂20-May-87  1840	FAHLMAN@C.CS.CMU.EDU 	:fill-pointer maybe    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87  16:47:42 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 20 May 87 19:47:14-EDT
Date: Wed, 20 May 1987  19:47 EDT
Message-ID: <FAHLMAN.12303988451.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Richard Berman <berman@VAXA.ISI.EDU>
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: :fill-pointer maybe
In-reply-to: Msg of 20 May 1987  18:51-EDT from Richard Berman <berman at vaxa.isi.edu>


Richard,

It looks to me like you and some others are missing a key concept.

There are an awful lot of places in CLtL where it is specified that
certain things have to work, but where the manual is silent on what
happens if those conditions don't hold.  A classic example is a built-in
function whose arguments "must" be of a certain type.  As a rule, these
unspecified situations should be considered to "be an error".

That phrase means that a legal Common Lisp implementation is free to
extend the language to handle this situation in some allegedly useful
way; it is not required to signal an error or to self-destruct.
Portable Common Lisp code may not depend on any such extensions, but an
implementation is free to extend all it wants.

In some cases where CLtL is silent, it is an oversight and a case can be
made for changing to a "signals an error" case or for specifying exactly
what must happen in that situation.  In most cases, however, the
language is left open-ended deliberately.  The feeling of the designers
was that Common Lisp is a living, growing language, and we didn't want
to bind it all up too tightly by trying to specify EVERYTHING.  "Signals
an error" was only specified in those cases where we felt that an error
signal was essential and where detecting the error would not impose too
great a performance penalty on some calsses of machine.

Now, if an implementation takes advantage of its freedom to extend the
language, and if it does not provide a compiler mode or some other tool
that flags the use of such non-portable extensions, then that
implementation is unsuitable for developing portable applications.  (I
could name some names, but I won't.)  Nevertheless, such implementations
are perfectly legal and are operating within the spirit of the Common
Lisp spec.  The language was meant to be extensible; that was an
important part of the original charter that we set for ourselves.

So, for the purposes of validation, you should treat these unspecified
cases as "is an error" cases and leave them alone (unless it is unclear
whether the case is or is not specified).  It couldn't hurt to make a
list of the ones you encounter for later discussion, but in almost all
cases the default answer is "this situation is an error; implementations
may do what they like".  It is the job of the validation suite to make
sure that the cases that ARE specified are handled correctly.

-- Scott

∂20-May-87  1840	FAHLMAN@C.CS.CMU.EDU 	arrays  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87  16:58:03 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 20 May 87 19:57:39-EDT
Date: Wed, 20 May 1987  19:57 EDT
Message-ID: <FAHLMAN.12303990345.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Richard Berman <berman@VAXA.ISI.EDU>
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: arrays
In-reply-to: Msg of 20 May 1987  19:22-EDT from Richard Berman <berman at vaxa.isi.edu>


    "Vectors whose elements are restricted to type bit are called bit-vectors"

    This implies strongly that a bit vector won't let one store any other value
    than 0 or 1.

This one is right in my opinion.  Sloppy wording in some of the other
descriptions you quote.

    So, is this a bit vector?

    #(1 0 0 1) 

No.

    should things like BIT-NOT which specifically want a bit vector
    work on it.  Does it return a general vector like this in this case rather
    than something like *0110???

They have to work on bit vectors.  It is an error to give it anything
else.  If an implementation wants to handle general vectors that happen
to be full of 1's and 0's, that's a legal extension; in such cases, it
is no business of Common Lisp what it returns.

-- Scott

∂20-May-87  1844	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Order of evaluation in PUSH (& PUSHNEW)    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 May 87  18:44:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 145741; Wed 20-May-87 20:56:15 EDT
Date: Wed, 20 May 87 20:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Order of evaluation in PUSH (& PUSHNEW) 
To: peck@Sun.COM
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8705202058.AA29640@denali.sun.com>
Message-ID: <870520205618.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 20 May 87 13:57:56 -0700
    From: peck@Sun.COM

     In the form: (push (ref1) (car (ref2)))
    It is unclear whether (ref1) should be evaluated before (ref2). 

The intention of the two paragraphs on page 99

  Other macros that manipulate generalized variables include ... push ....
    Macros that manipulate generalized variables must guarantee...
  subforms of generalized-variable references are evaluated ...
  in exactly the same order as they appear in the *source* program.

was to require (ref1) to be evaluated before (ref2).  If some
implementations fail to follow this, that's evidence that this part
of the specification is not considered universally important, but
I don't think it changes the language.

I hadn't realized until I read your message that the book is actually
ambiguous (here as in so many other places).  The quoted paragraphs could
be taken to restrict order of evaluation only of the subforms of
(car (ref2)), not all of the subforms of the push form.  I'm sure
this weaker interpretation was not what was intended, and the discussion
of (setf reference value) later on the same page supports that,
since value is not a subform of a generalized-variable reference.

I personally think it's pretty dangerous for order of evaluation to
be unspecified and implementation-dependent, so I would prefer to
leave the language the way I claim it was intended to be, and as part
of the standardization process write a less ambiguous specification.

∂20-May-87  1844	Moon@STONY-BROOK.SCRC.Symbolics.COM 	arrays  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 May 87  18:44:03 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 145711; Wed 20-May-87 20:20:50 EDT
Date: Wed, 20 May 87 20:20 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: arrays
To: Richard Berman <berman@vaxa.isi.edu>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8705202322.AA05367@vaxa.isi.edu>
Message-ID: <870520202050.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 20 May 87 16:22:48 PDT
    From: Richard Berman <berman@vaxa.isi.edu>

    On bit vectors:

    on page 12:

    "One dimensional arrays of bits (that is, of integers whose values are 0 or 1)
    are called bit vectors"

    implies that any array of all 0 and 1 integers is a bit vector.

    Page 29:

    "All implementations are also required to provide specialized arrays of bits,
    that is, arrays of type (array bit); the one-dimensional instances of this
    specialization are called bit-vectors."

    Page 286:

    "Vectors whose elements are restricted to type bit are called bit-vectors"

    This implies strongly that a bit vector won't let one store any other value
    than 0 or 1.

I think the imprecise language on page 12 should not be assumed to overrule
the more precise language on pages 29 and 286.  So bit-vector and bit-array
refer to the specialized types.  Another way of saying this is that you cannot
change whether an object is a bit-vector (or a bit-array) by using setf of aref,
or indeed by using any other Common Lisp feature (read the description of the
:element-type argument to adjust-array carefully).

    It is my *opinion* that #(1 0 0 1) is not a bit vector because there is a
    precise input style for such (like *1001) and bit vectors are specialized.

I'm sure you're right.

∂20-May-87  1902	rauen@CLS.LCS.MIT.EDU 	Roman numeral hacking.
Received: from CLS.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87  19:02:33 PDT
Received: by CLS.LCS.MIT.EDU (4.12/4.7); Wed, 20 May 87 22:07:31 edt
Date: Wed, 20 May 87 22:07:31 edt
From: rauen@CLS.LCS.MIT.EDU (James R. Rauen)
Message-Id: <8705210207.AA16268@CLS.LCS.MIT.EDU>
To: common-lisp@sail.stanford.edu
Subject: Roman numeral hacking.


How about just throwing more M's in front?  (6666 = MMMMMMDCLXVI).
The case I'd worry about is zero.  The Romans didn't have a zero;
maybe (format nil "~@R" 0) should return "".

		--Jim

∂20-May-87  1911	ibuki!weaver@labrea.stanford.edu 	Order of evaluation in PUSH    
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87  19:10:13 PDT
Received: by labrea.stanford.edu; Wed, 20 May 87 18:08:28 PDT
Received: by ibuki.UUCP (1.4/4.7)
	id AA3211335; Wed, 20 May 87 17:19:21 pdt
Date: Wed, 20 May 87 17:19:21 pdt
From: ibuki!weaver@labrea.stanford.edu (Eric Weaver)
Message-Id: <8705210019.AA3211335@ibuki.UUCP>
To: labrea!common-lisp@sail.arpa
Subject: Order of evaluation in PUSH

    Date: Wed, 20 May 87 13:57:56 -0700
    From: labrea!peck@Sun.COM

     In the form: (push (ref1) (car (ref2)))
    It is unclear whether (ref1) should be evaluated before (ref2). 
    ....

    Lucid and Franz evaluate (ref2) then (ref1)
    Symbolics evaluate (ref1) then (ref2)

KCL falls in the former group:

(macroexpand '(push (ref1) (car (ref2))))   =>

(LET* ((#:G7 (REF2)) (#:G8 (CONS (REF1) (CAR #:G7))))
  (PROGN (RPLACA #:G7 #:G8) #:G8))

∂20-May-87  1955	edsel!bhopal!jonl@navajo.stanford.edu 	[adjustable arrays?] More FORMAT    
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87  19:55:39 PDT
Received: by navajo.stanford.edu; Wed, 20 May 87 19:53:13 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
	id AA00421; Wed, 20 May 87 19:25:54 pdt
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
	id AA03071; Wed, 20 May 87 19:27:34 PDT
Date: Wed, 20 May 87 19:27:34 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8705210227.AA03071@bhopal.edsel.uucp>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!berman%vaxa.isi.edu@navajo.stanford.edu,
        navajo!common-lisp%sail@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 19 May 87 17:46 EDT <870519174622.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: [adjustable arrays?] More FORMAT

Re: In some implementations all arrays are adjustable even if you didn't 
    explicitly ask for an adjustable array in make-array.
Isn't this a bug?  It certainly provides a loophole for non-portable code
that isn't reasonably detectable as non-portable.  For CLtL says
  (1) on p289 that certain arguments to make-array "guarantee" that the 
      result will be a simple array;
  (2) and on p28 that a simple array "is not to have its size adjusted
      dynamically after creation".
You can imagine how someone using a system that doesn't detect this error
will fare when trying to run on another system that really can't adjust
simple arrays.

-- JonL --

∂20-May-87  2037	quiroz@cs.rochester.edu 	Re: Order of evaluation in PUSH (& PUSHNEW)  
Received: from CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87  20:37:38 PDT
Received: by cayuga.cs.rochester.edu (5.52/b) id AA02470; Wed, 20 May 87 23:36:11 EDT
Received: from loopback by yed.cs.rochester.edu (3.2/b) id AA00246; Wed, 20 May 87 23:38:54 EDT
Message-Id: <8705210338.AA00246@yed.cs.rochester.edu>
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: peck@Sun.COM, common-lisp@sail.stanford.edu
Summary: Left to right seems correct.  Unspecified might be better.
Subject: Re: Order of evaluation in PUSH (& PUSHNEW) 
In-Reply-To: Your message of Wed, 20 May 87 20:56:00 -0400.
             <870520205618.1.MOON@EUPHRATES.SCRC.Symbolics.COM> 
Date: Wed, 20 May 87 23:38:50 -0400
From: quiroz@cs.rochester.edu

I agree that the letter and spirit of CLtL strongly suggest that
the order of evaluation should be left to right.  This is so mainly
because that is the way things normally go in Common Lisp, and so
the programmer must expect that behavior unless explicitly told not
to.

However, specifying strict left to right order of evaluation kills a
substantial amount of parallelism in argument evaluation.  At least,
it makes it harder to recognize when the arguments of a function
call can be parallelized.

I am almost sure this has been raised before and probably the
original committee even considered this, but as I am new to the list,
I haven't seen this discussed:  Was it ever considered to leave the
order of evaluation in function calls unspecified (or less
restricted) than in the current version?  I am thinking of something
along the lines of saying that, except for special forms, other
evaluable forms are evaluated by:

	1- determining the function to call or macro to expand.
	2- computing the arguments, if a function.
    3- calling the function (or (eval (macroexpand....))).

1- and 2- could go in parallel, or 1- could be guaranteed to occur
before 2-.

It is obvious that certain forms have no meaning but for an order of
evaluation (progn,...) and others need special rules for whether an
argument even gets eval'd (and, or, ...).  But that's why all of
these forms are 'special', and pure applicative thinking [:-)] makes
it unnecessary to depend on the order of evaluation for the normal
function calls.  I suspect that the original committee had a really
good reason to tie up this part of the language, but I cannot think
of one...

=Cesar
(Of course, if this has been hashed time and again, please just
point me to the relevant archives.)
--------
Cesar Augusto  Quiroz Gonzalez

Department of Computer Science     {allegra|seismo}!rochester!quiroz
University of Rochester            or
Rochester,  NY 14627               quiroz@cs.rochester.edu

∂20-May-87  2134	FAHLMAN@C.CS.CMU.EDU 	Order of evaluation in PUSH (& PUSHNEW)    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87  21:34:39 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 21 May 87 00:34:04-EDT
Date: Thu, 21 May 1987  00:33 EDT
Message-ID: <FAHLMAN.12304040661.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   quiroz@CS.ROCHESTER.EDU
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: Order of evaluation in PUSH (& PUSHNEW) 
In-reply-to: Msg of Wed 20 May 87 23:38:50 -0400 from quiroz at cs.rochester.edu


In the original design discussions, we briefly considered leaving the
order of argument evaluation undefined in order to make life easier for
some future parallel version of Common Lisp.  However, we felt that the
question of what should go into a parallel Lisp was an open research
issue (it still is).  We decided that designing a good serial Lisp was
plenty hard enough, and that worrying about various half-baked ideas for
a parallel Lisp would be a distraction we didn't need.  So the design
went forward with parallel processing explicitly excluded from the
design criteria; given that stance, tying down the order of evaluation
seemed to be a good idea for portability.

Even if we had left order of argument evaluation open, this change by
itself would only buy you a factor of two or so on the average, and
that's with no overhead for splitting and merging processes.

-- Scott

∂20-May-87  2209	Mailer@XX.LCS.MIT.EDU 	[dg%acorn@oak.lcs.mit.edu:  Re: &REST]    
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87  22:09:27 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 21 May 87 01:07-EDT
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 43633; 21 May 87 01:08:30-EDT
Received: from CHUGACH.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 110; 21 May 87 00:44:33-EDT
Date: Thu, 21 May 87 00:44 EDT
From: Jeff Gibbons <jeff@JASPER.PALLADIAN.COM>
Subject: [dg%acorn@oak.lcs.mit.edu:  Re: &REST]
To: Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>,
    dg%acorn@LIVE-OAK.LCS.MIT.EDU, Daniel L. Cerys <Cerys@xx.arpa>
cc: common-lisp@SAIL.STANFORD.EDU, Acuff@SUMEX-AIM.STANFORD.EDU
In-Reply-To: <2757506096-3811281@Jenner>
Message-ID: <870521004419.0.JEFF@CHUGACH.PALLADIAN.COM>
Reply-To: Jeff Gibbons <JEFF%JASPER@LIVE-OAK.LCS.MIT.EDU>

    Date: Wed, 20 May 87  08:54:56 CDT
    From: Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>

    ...     in Release 3, TI ...

    There are 0 restrictions on using &REST lists outside of the dynamic
    scope of the parameter. ...

    Patrick.

This claim may be true but don't be fooled into thinking they are fully blessed
lists. Try:

(defun trouble (&rest x) (rplacd x '(a b c)))

(trouble 1 2 3) => Hello, debugger!

Jeff Gibbons


∂20-May-87  2254	edsel!bhopal!jonl@navajo.stanford.edu 	All arrays can be adjustable?  
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87  22:54:16 PDT
Received: by navajo.stanford.edu; Wed, 20 May 87 22:51:50 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
	id AA01603; Wed, 20 May 87 22:43:20 pdt
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
	id AA03359; Wed, 20 May 87 22:45:04 PDT
Date: Wed, 20 May 87 22:45:04 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8705210545.AA03359@bhopal.edsel.uucp>
To: navajo!DLA%DIAMOND.S4CC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!sandra%orion%cs.utah.edu@navajo.stanford.edu,
        navajo!common-lisp%sail@navajo.stanford.edu
In-Reply-To: David L. Andre's message of Tue, 19 May 87 22:21 EDT <870519222134.7.DLA@LIMPKIN.S4CC.Symbolics.COM>
Subject: All arrays can be adjustable?

Re: I don't think the issue is whether or not users can tell whether arrays
    are simple or adjustable.  . . .
Whether or not that is the issue with Loosemore's complaint, it is indeed a 
requirement of Common Lisp --  a user need only do (typep x 'simple-array).  
See CLtL page 34 where simple-array is defined as a subtype of array.
Note also that everywhere "subtype" is used, it means "proper subtype".  

-- JonL --


∂21-May-87  0556	@diamond.s4cc.symbolics.com,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	[adjustable arrays?] More FORMAT    
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87  05:56:39 PDT
Received: from DIAMOND.S4CC.Symbolics.COM ([128.81.51.3]) by navajo.stanford.edu with TCP; Thu, 21 May 87 05:52:42 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by DIAMOND.S4CC.Symbolics.COM via INTERNET with SMTP id 88819; 21 May 87 08:53:17 EDT
Date: Thu, 21 May 87 08:57 EDT
From: David C. Plummer <DCP@quabbin.scrc.symbolics.com>
Subject: [adjustable arrays?] More FORMAT
To: Jon L White <edsel!bhopal!jonl@navajo.stanford.edu>,
        navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!berman%vaxa.isi.edu@navajo.stanford.edu,
        navajo!common-lisp%sail@navajo.stanford.edu
In-Reply-To: <8705210227.AA03071@bhopal.edsel.uucp>
Message-Id: <870521085729.6.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

    Date: Wed, 20 May 87 19:27:34 PDT
    From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
	...
    You can imagine how someone using a system that doesn't detect this error
    will fare when trying to run on another system that really can't adjust
    simple arrays.

"You can imagine how someone using a system that doesn't do
number-of-argument checking will fare ..."

As I recall, the number-of-argument discussion did happen several months
ago, and by the strict reading of CLtL it "is an error" to supply the
wrong number of arguments but implementations are not required to
"signal an error."  To me, this array discussion should fall in the same
class: 
 - What "is an error?"
 - What "signals an error?"
 - What implementation freedom should there be?
 - How important are some of these to various parts of the language?
   For example, I would rank number of argument checking considerably
   more important than worrying about allowing some systems to adjust
   even simple arrays.


∂21-May-87  0725	DALY@IBM.COM 	validation suite
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 21 May 87  07:25:38 PDT
Date: 21 May 1987, 09:45:11 EDT
From: Timothy Daly <DALY@ibm.com>
To:   common-lisp@sail.stanford.edu
Message-Id: <052187.094511.daly@ibm.com>
Subject: validation suite

Is there a publically available validation suite of programs
for common lisp?

∂21-May-87  0938	moss!tk@harvard.harvard.edu 	Re: Notice on Kyoto Common Lisp distribution (query)    
Received: from HARVARD.HARVARD.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87  09:38:07 PDT
Received: by harvard.harvard.edu; Thu, 21 May 87 12:26:46 EDT
Received: by RUTGERS.EDU (5.54/1.14) with UUCP 
	id AA13987; Thu, 21 May 87 12:34:38 EDT
Received: by moss.ATT.COM (smail2.5)
	id AA16386; 21 May 87 11:21:06 EDT (Thu)
To: common-lisp@sail.stanford.edu
In-Reply-To: "Scott E. Fahlman"'s message of Thu, 30 Apr 1987  16:56 EDT <FAHLMAN.12298714494.BABYL@C.CS.CMU.EDU>
Subject: Re: Notice on Kyoto Common Lisp distribution (query)
Date: 21 May 87 11:21:06 EDT (Thu)
From: tk@moss.att.com (Tom Kirk)
Message-Id: <8705211121.AA16386@moss.ATT.COM>

Does anyone have new information about the availability of KCL, or
what the distribution mechanism will be? I'd appreciate any current
knowledge anyone could pass along.

Thanks,
tom kirk
-------
tk@nosc, tk@moss.att.com

∂21-May-87  0945	larus%paris.Berkeley.EDU@Berkeley.EDU 	Re: Order of evaluation in PUSH (& PUSHNEW)   
Received: from [128.32.150.46] by SAIL.STANFORD.EDU with TCP; 21 May 87  09:44:58 PDT
Received: by paris.Berkeley.EDU (5.57/1.25)
	id AA24598; Thu, 21 May 87 09:43:20 PDT
From: larus%paris.Berkeley.EDU@berkeley.edu (James Larus)
Message-Id: <8705211643.AA24598@paris.Berkeley.EDU>
To: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
Cc: quiroz@cs.rochester.edu, common-lisp@sail.stanford.edu
Subject: Re: Order of evaluation in PUSH (& PUSHNEW) 
In-Reply-To: Your message of Thu, 21 May 87 00:33:00 EDT.
             <FAHLMAN.12304040661.BABYL@C.CS.CMU.EDU> 
Date: Thu, 21 May 87 09:43:16 PDT


Leaving the order of evaluation of actual parameters unspecified (a la
Scheme) would help some serial, as well as parallel, implementations.
Consider a machine that uses registers for passing parameters and
evaluating expressions.  If a compiler is free to reorder the
evaluation of expressions, it can evaluate the more complex ones using
the (empty) registers, then evaluate the other ones directly into
their target registers.  From personal experience on SPUR, this
freedom would produce noticeably better code and reduce the number of
temporaries that have to be allocated by the register allocator.

Of course, some existing programs would break.  But a good argument
can be made that these programs were dependent an implementation
artifact.

/Jim

PS  Did the CL committee ever decide which sentence actually *requires*
left-to-right evaluation of formals?

∂21-May-87  1019	DLW@ALDERAAN.SCRC.Symbolics.COM 	[adjustable arrays?] More FORMAT
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 21 May 87  10:19:46 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 84258; Thu 21-May-87 13:18:16 EDT
Date: Thu, 21 May 87 13:17 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: [adjustable arrays?] More FORMAT
To: edsel!bhopal!jonl@navajo.stanford.edu
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8705210227.AA03071@bhopal.edsel.uucp>
Message-ID: <870521131752.5.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Wed, 20 May 87 19:27:34 PDT
    From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)

    Isn't this a bug?  It certainly provides a loophole for non-portable code
    that isn't reasonably detectable as non-portable.

No.  As Fahlman explained clearly in an earlier message, providing
extensions that make it harder to determine portability is in no way a
"bug" or "violation of Common Lisp".

∂21-May-87  1124	@DIAMOND.S4CC.Symbolics.COM:PTW@YUKON.SCRC.Symbolics.COM 	Re: Order of evaluation in PUSH (& PUSHNEW)    
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 21 May 87  11:24:06 PDT
Received: from TIGGER.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 88979; Thu 21-May-87 14:19:26 EDT
Date: Thu, 21 May 87 14:19 EDT
From: P. T. Withington <PTW@YUKON.SCRC.Symbolics.COM>
Subject: Re: Order of evaluation in PUSH (& PUSHNEW) 
To: James Larus <larus%paris.Berkeley.EDU@berkeley.edu>, Scott E. Fahlman <Fahlman@c.cs.cmu.edu>
cc: quiroz@cs.rochester.edu, common-lisp@sail.stanford.edu
In-Reply-To: <8705211643.AA24598@paris.Berkeley.EDU>
Message-ID: <870521141924.9.PTW@TIGGER.S4CC.Symbolics.COM>

I see no reason to require evaluation order of arguments when there is
already a mechanism to enforce it:  use LET* where evaluation order is
important.  A good compiler should be able to optimize away the implied
temporaries when the expressed evaluation order matches the
implementation evaluation order.


∂21-May-87  1148	berman@vaxa.isi.edu 	Re: :fill-pointer maybe 
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87  11:48:42 PDT
Posted-Date: Thu, 21 May 87 11:48:24 PDT
Message-Id: <8705211848.AA10759@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
	id AA10759; Thu, 21 May 87 11:48:27 PDT
To: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
Cc: common-lisp@sail.stanford.edu
Subject: Re: :fill-pointer maybe 
In-Reply-To: Your message of Wed, 20 May 87 19:47:00 -0400.
             <FAHLMAN.12303988451.BABYL@C.CS.CMU.EDU> 
Date: Thu, 21 May 87 11:48:24 PDT
From: Richard Berman <berman@vaxa.isi.edu>



Scott, I get the picture.  What I may be able to do is still put in checks to
cause these "is an error" conditions, with messages that if anything other
than "strict" results are obtained, the report mentions that it is optional or
implementation dependent, or whatever.

Like if no error "is signalled" (which would be the strictest interpretation
of "is an error"), then I would report that, with the above modifier.


How's that sound?

RB

∂21-May-87  1156	berman@vaxa.isi.edu 	Re: validation suite    
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87  11:56:23 PDT
Posted-Date: Thu, 21 May 87 11:55:10 PDT
Message-Id: <8705211855.AA10809@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
	id AA10809; Thu, 21 May 87 11:55:28 PDT
To: Timothy Daly <DALY@ibm.com>
Cc: common-lisp@sail.stanford.edu, berman@vaxa.isi.edu
Subject: Re: validation suite 
In-Reply-To: Your message of 21 May 87 00:00:00 +0000.
             <052187.094511.daly@ibm.com> 
Date: Thu, 21 May 87 11:55:10 PDT
From: Richard Berman <berman@vaxa.isi.edu>


Dear Tim,

Subscribe to CL-VALIDATION@sail.stanford.edu.  Get its archive, which is not
too long.  Look it over.

RB

∂21-May-87  1220	FAHLMAN@C.CS.CMU.EDU 	:fill-pointer maybe    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87  12:20:30 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 21 May 87 15:20:04-EDT
Date: Thu, 21 May 1987  15:20 EDT
Message-ID: <FAHLMAN.12304201957.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Richard Berman <berman@VAXA.ISI.EDU>
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: :fill-pointer maybe 
In-reply-to: Msg of 21 May 1987  14:48-EDT from Richard Berman <berman at vaxa.isi.edu>


Sounds fine, though I wouldn't waste a lot of effort looking for
extensions to flag.  The most important task is to flag those places
where an implementation falls short, rather than those places where it
does more than it has to.

-- Scott

∂21-May-87  1323	Mailer@xx.lcs.mit.edu 	All arrays can be adjustable?   
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87  13:23:42 PDT
Received: from XX.LCS.MIT.EDU by navajo.stanford.edu with TCP; Thu, 21 May 87 13:18:58 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 21 May 87 16:19-EDT
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 43733; 21 May 87 16:20:33-EDT
Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 149; 21 May 87 15:20:33-EDT
Date: Thu, 21 May 87 15:20 EDT
From: Don Morrison <dfm@jasper.palladian.com>
Subject: All arrays can be adjustable?
To: edsel!bhopal!jonl@navajo.stanford.edu
Cc: navajo!DLA%DIAMOND.S4CC.Symbolics.COM@navajo.stanford.edu,
        navajo!sandra%orion%cs.utah.edu@navajo.stanford.edu,
        navajo!common-lisp%sail@navajo.stanford.edu
In-Reply-To: <8705210545.AA03359@bhopal.edsel.uucp>
Message-Id: <870521152017.2.DFM@WHITBY.PALLADIAN.COM>
Reply-To: Don Morrison <DFM%JASPER@live-oak.lcs.mit.edu>

    Date: Wed, 20 May 87 22:45:04 PDT
    From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)

    See CLtL page 34 where simple-array is defined as a subtype of array.
    Note also that everywhere "subtype" is used, it means "proper subtype".  

CLtL, page 33: "If x is a supertype of y, then any object of type y is also of type x,
and y is said to be a subtype of x."  Doesn't sound like "proper subtype" to me.
Also, in both Symbolics and Lucid, (subtypep x x) => t for every type I tried.


∂21-May-87  1347	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Order of evaluation in PUSH (& PUSHNEW)     
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 May 87  13:46:57 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 146808; Thu 21-May-87 16:42:06 EDT
Date: Thu, 21 May 87 16:42 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Order of evaluation in PUSH (& PUSHNEW) 
To: P. T. Withington <PTW@YUKON.SCRC.Symbolics.COM>
cc: James Larus <larus%paris.Berkeley.EDU@berkeley.edu>, Scott E. Fahlman <Fahlman@c.cs.cmu.edu>,
    quiroz@cs.rochester.edu, common-lisp@sail.stanford.edu
In-Reply-To: <870521141924.9.PTW@TIGGER.S4CC.Symbolics.COM>
Message-ID: <870521164208.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 21 May 87 14:19 EDT
    From: P. T. Withington <PTW@YUKON.SCRC.Symbolics.COM>

    I see no reason to require evaluation order of arguments when there is
    already a mechanism to enforce it:  use LET* where evaluation order is
    important.  A good compiler should be able to optimize away the implied
    temporaries when the expressed evaluation order matches the
    implementation evaluation order.

Remember that Common Lisp is a language with side-effects, and in such
languages there are more constraints on evaluation order than just the
data dependencies.  With LET* you are talking data dependencies.

In any case, Scott Fahlman explained quite clearly in an earlier message
why Common Lisp takes the stand it does.  I think that reasoning is just
as true today as it was three years ago.

∂21-May-87  1411	larus%paris.Berkeley.EDU@Berkeley.EDU 	Re: Order of evaluation in PUSH (& PUSHNEW)   
Received: from [128.32.150.46] by SAIL.STANFORD.EDU with TCP; 21 May 87  14:11:15 PDT
Received: by paris.Berkeley.EDU (5.57/1.25)
	id AA25054; Thu, 21 May 87 14:08:44 PDT
From: larus%paris.Berkeley.EDU@berkeley.edu (James Larus)
Message-Id: <8705212108.AA25054@paris.Berkeley.EDU>
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: P. T. Withington <PTW@yukon.scrc.symbolics.com>,
        Scott E. Fahlman <Fahlman@c.cs.cmu.edu>, quiroz@cs.rochester.edu,
        common-lisp@sail.stanford.edu
Subject: Re: Order of evaluation in PUSH (& PUSHNEW) 
In-Reply-To: Your message of Thu, 21 May 87 16:42:00 EDT.
             <870521164208.9.MOON@EUPHRATES.SCRC.Symbolics.COM> 
Date: Thu, 21 May 87 14:08:36 PDT

	 Date: Thu, 21 May 87 14:19 EDT
	 From: P. T. Withington <PTW@YUKON.SCRC.Symbolics.COM>

	 I see no reason to require evaluation order of arguments when there is
	 already a mechanism to enforce it:  use LET* where evaluation order is
	 important.  A good compiler should be able to optimize away the implied
	 temporaries when the expressed evaluation order matches the
	 implementation evaluation order.

     Remember that Common Lisp is a language with side-effects, and in such
     languages there are more constraints on evaluation order than just the
     data dependencies.  With LET* you are talking data dependencies.

In discussing side-effects between the evaluation of formal arguments,
we are also talking about data-dependencies.  Taking a page from the
vector processor and multiprocessor compiler literature: a data-dependence
between two statements occurs when one statement writes a value into a
location and another statement either reads or writes this location.
This gives us three types of data-dependencies: W(rite) followed by
R(read), R followed by W, and W followed by W.

Moon is expressing the common belief that all data-dependencies are of
the first type, as for example:

	(LET* ((A (FOO))
	       (B (BAR A))) ...)

in which the first clause of the LET* statement writes a value into
the location called `a' and the second reads the same location (W-R
for short).

However, there is no fundamental difference between this example and
the following one (R-W):

	(REORDER-AND-DIE ARG (SETQ ARG 1))

The major difference between the two is that a larger group of people
would probably object to the latter example on grounds of taste.


     In any case, Scott Fahlman explained quite clearly in an earlier message
     why Common Lisp takes the stand it does.  I think that reasoning is just
     as true today as it was three years ago.

As I tried to suggest in my earlier note, there are strong reasons
apart from multiprocessor Lisps why Common Lisp's stand is an
unnecessary constraint on the language.

The status quo be better defended on two grounds: I like side-effects
and want predictability without having to introduce additional
sequence constraints like LET* and PROGN or this is a major change
that will break a lot of code.  Multiprocessors are just a
red-herring.

/Jim

∂22-May-87  0152	Randy%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: Order of evaluation in general  
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 May 87  01:52:18 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 22 May 87 04:50-EDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 43818; 22 May 87 04:52:54-EDT
Received: from PINK-FLOYD.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 70302; Fri 22-May-87 02:56:02-EDT
Date: Fri, 22 May 87 02:55 EDT
From: Randy%acorn@oak.lcs.mit.edu
To: common-lisp@sail.stanford.edu
Subject: Re: Order of evaluation in general

    From: larus%paris.Berkeley.EDU@berkeley.edu (James Larus)
    Date: Thu, 21 May 87 09:43:16 PDT
    
    Leaving the order of evaluation of actual parameters unspecified (a la
    Scheme) would help some serial, as well as parallel, implementations.
    ...

I realize that it was explicitly stated (somewhere) that Common 
Lisp is ignoring issues of parallelism.  Given that parellel is 
going to be the next fad, it's probably time to start thinking about
parallel issues.  In addition to special forms like PROGN-IN-ANY-ORDER
(or some more aesthetic name), there should be versions of DO-family
and MAP-family functions that could frotz with order however they 
wanted.

Random


∂22-May-87  0718	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re: Order of evaluation in general   
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 22 May 87  07:18:14 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 84675; Fri 22-May-87 10:17:45 EDT
Date: Fri, 22 May 87 10:17 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: Order of evaluation in general
To: Randy%acorn@oak.lcs.mit.edu, common-lisp@sail.stanford.edu
In-Reply-To: The message of 22 May 87 02:55 EDT from Randy%acorn@oak.lcs.mit.edu
Message-ID: <870522101716.4.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Fri, 22 May 87 02:55 EDT
    From: Randy%acorn@oak.lcs.mit.edu

    I realize that it was explicitly stated (somewhere) that Common 
    Lisp is ignoring issues of parallelism.  Given that parellel is 
    going to be the next fad, it's probably time to start thinking about
    parallel issues.

It's certainly time for many people and many groups to be thinking about
parallel issues, and many are.  But I don't think X3J13 is the right
forum for that.  Standardization is a very different activity from
language exploration and design.  Imposing the constraints of the former
on the latter would be a mistake.  It's not time yet to standardize on
parallelism in Lisp; it's time to try things out and gain experience.
That can be done best the way Lisp has always grown: experimentation in
environments that encourage creativity and freedom, rather than the
practical constraints of ANSI standardization.

∂22-May-87  0729	gls@Think.COM 	All arrays can be adjustable? 
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 22 May 87  07:29:17 PDT
Received: from boethius by Think.COM via CHAOS; Fri, 22 May 87 10:28:41 EDT
Date: Fri, 22 May 87 10:26 EDT
From: Guy Steele <gls@Think.COM>
Subject: All arrays can be adjustable?
To: DFM%JASPER@live-oak.lcs.mit.edu, edsel!bhopal!jonl@navajo.stanford.edu
Cc: navajo!DLA%DIAMOND.S4CC.Symbolics.COM@navajo.stanford.edu,
        navajo!sandra%orion%cs.utah.edu@navajo.stanford.edu,
        common-lisp@sail.stanford.edu
In-Reply-To: <870521152017.2.DFM@WHITBY.PALLADIAN.COM>
Message-Id: <870522102614.1.GLS@BOETHIUS.THINK.COM>

    Date: Thu, 21 May 87 15:20 EDT
    From: Don Morrison <dfm@jasper.palladian.com>

	Date: Wed, 20 May 87 22:45:04 PDT
	From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)

	See CLtL page 34 where simple-array is defined as a subtype of array.
	Note also that everywhere "subtype" is used, it means "proper subtype".  

    CLtL, page 33: "If x is a supertype of y, then any object of type y is also of type x,
    and y is said to be a subtype of x."  Doesn't sound like "proper subtype" to me.
    Also, in both Symbolics and Lucid, (subtypep x x) => t for every type I tried.

CLTL page 72: "This predicate [subtypep] is true if type1 is a (not
necessarily proper) subtype of type2."
--Guy

∂22-May-87  0748	gls@Think.COM 	Re: More FORMAT     
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 22 May 87  07:48:04 PDT
Received: from boethius by Think.COM via CHAOS; Fri, 22 May 87 10:49:17 EDT
Date: Fri, 22 May 87 10:46 EDT
From: Guy Steele <gls@Think.COM>
Subject: Re: More FORMAT 
To: berman@vaxa.isi.edu, DFM%JASPER@live-oak.lcs.mit.edu
Cc: common-lisp@sail.stanford.edu, gls@think.com
In-Reply-To: <8705201855.AA02717@vaxa.isi.edu>
Message-Id: <870522104659.2.GLS@BOETHIUS.THINK.COM>

    Date: Wed, 20 May 87 11:55:34 PDT
    From: Richard Berman <berman@vaxa.isi.edu>


    As someone else mentioned, it can be more than useful to know that something
    is causing an array to grow.  It seems reduntant to me to have an :adjustable
    keyword if there are no clear semantics to :adjustable nil, only to
    :adjustable T.  Especially when :adjustable (non-nil) == :adjustable nil.

    Or perhaps we need a :non-adjustable keyword, just to keep our semantics
    consistent, where :non-adjustable T means "definitely" non-adjustable, and
    :non-adjustable nil means "maybe non-adjustable"?

    RB

It is not redundant.  It is, however, in some sense merely an
efficiency hint.  :ADJUSTABLE NIL is a promise on the part of the
programmer never to try to adjust the array.  The value of this
promise is that the implementation may then be able to create
an array that uses less time or space.
--Guy

∂22-May-87  0801	gls@Think.COM 	numerals, Roman, large, overly, printing of, how to do it   
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 22 May 87  08:00:50 PDT
Received: from boethius by Think.COM via CHAOS; Fri, 22 May 87 10:58:47 EDT
Date: Fri, 22 May 87 10:55 EDT
From: Guy Steele <gls@Think.COM>
Subject: numerals, Roman, large, overly, printing of, how to do it
To: berman@vaxa.isi.edu, las@bfly-vax.bbn.com
Cc: common-lisp@sail.stanford.edu, gls@think.com
In-Reply-To: <8705201905.AA02808@vaxa.isi.edu>
Message-Id: <870522105532.3.GLS@BOETHIUS.THINK.COM>

    Date: Wed, 20 May 87 12:05:53 PDT
    From: Richard Berman <berman@vaxa.isi.edu>


    My only question re: roman numerals is:  what does *common lisp* do for values
    above the specified range (or unspecified, so far as the spec is concerned).
    Do we just not print romans above certain values?  What is printed instead?
    Etc.?

    RB

Implementors are informally encouraged to print either the decimal
equivalent, or else the phrase

	GUIDO CANTABRIGIENSIS PERDITOR PERDELIRUS

--Quux

∂22-May-87  0815	FAHLMAN@C.CS.CMU.EDU 	numerals, Roman, large, overly, printing of, how to do it 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 May 87  08:14:57 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 22 May 87 11:14:30-EDT
Date: Fri, 22 May 1987  11:14 EDT
Message-ID: <FAHLMAN.12304419394.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Guy Steele <gls@THINK.COM>
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: numerals, Roman, large, overly, printing of, how to do it
In-reply-to: Msg of 22 May 1987  10:55-EDT from Guy Steele <gls at Think.COM>


    Implementors are informally encouraged to print either the decimal
    equivalent, or else the phrase

    	GUIDO CANTABRIGIENSIS PERDITOR PERDELIRUS


OK, somebody has to ask: What, O mighty and imponederable Quux, does
this phrase mean in English, if indeed it is translatable and not too
obscene for transmission via netmail?

My Latin stopped with "Sic Friat Crustulum": So crumbles the cookie.
(Actually, I think it's "biscuit" -- the Romans seem not have had
cookies in the modern sense, since Cortes had not yet conquered the land
where chocolate chips grow.)

-- Scott

∂22-May-87  1257	berman@vaxa.isi.edu 	:KEY, hairsplit    
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 22 May 87  12:56:57 PDT
Posted-Date: Fri, 22 May 87 12:56:46 PDT
Message-Id: <8705221956.AA04810@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
	id AA04810; Fri, 22 May 87 12:56:48 PDT
To: common-lisp@sail.stanford.edu
Subject: :KEY, hairsplit
Date: Fri, 22 May 87 12:56:46 PDT
From: Richard Berman <berman@vaxa.isi.edu>


I have an implementation here which interprets the :KEY keyword
of SUBLIS as applying to the ALIST.  Consistency seems to demand
that it applies to the TREE.  For example, the code for SUBST on
page 274, and the description of :KEY on 246.  Nevertheless, with
the description on 246 I couldn't say that they are wrong in applying
it to ALIST:

"If an operation tests elements of a sequence in any manner, the keyword
argument :key, if not nil, should be a function of one argument that will
extract from an element the part to be tested in place of the whole element."

But in SUBLIS, both ALIST and TREE are being "tested".  But since it is TREE
that would be affected, and since things like SUBST, SUBSTITUTE and relatives,
all use :key on the effected sequence, it would be inconsistent for :key to
work on ALIST as above.  Strictly speaking, I could see how an implementor
could interpret pg 246 to mean applying :key to both ALIST and TREE.
Especially because the only description of :key is in the Sequence chapter,
and despite the fact that :key is used in a number of places in the LISTS
chapter, it is not defined, leaving one with the sequence definition  Page 273
says "The naming conventions for these functions and for their keyword
arguments generally follow the conventions for the generic sequence
functions."

Fine.

I am sure most will agree to my interpretation -- That ALIST does not get :key
applied to it, and TREE does.  I am trying to convert some of one
manufacturer's tests to the standard format, and ran into this goody.  

Any official word?

RB

∂22-May-87  1449	primerd!doug@enx.prime.pdn    
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 May 87  14:49:32 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 
	id <AA08168@EDDIE.MIT.EDU>; Fri, 22 May 87 17:47:10 EDT
Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail)
	id AA16674; Fri, 22 May 87 17:27:10 EDT
Message-Id: <8705222127.AA16674@primerd.prime.com>
Received: (from user DOUG) by ENX.Prime.PDN; 22 May 87 16:34:47 EST
To: COMMON-LISP@SAIL.STANFORD.EDU
From: primerd!DOUG@ENX.Prime.PDN
Date: 22 May 87 16:34:48 EST

To:       (common-lisp@sail.stanford.edu)
From:     Doug Rand (DOUG@ENX.PRIME.COM)
Date:     22 May 87  4:25 PM
Subject:  Portable public domain DEFSYSTEM available for use

I have a defsystem and associated utilities that others may find
useful.  I have made the code available for use on SAIL via anonymous
ftp from defsys.lsp[com,lsp] and the documentation from
defsys.doc[com,lsp]. (Many thanks to Dick Gabriel for putting them up
for me)

The usual caveats apply about no warrantty expressed or implied.  You
can pass the source and documentation on to others but I ask that
enhancements get funnelled back through me.  Modification for your
own use is,  of course,  no problem.

Some effort has been made in options to use existing names for items
where appropriate but this really isn't a direct copy of the
functionality of the ZETALISP defsystem facility on the LISPM.

Cheers,

Doug

---------------------------
An abbreviated description:
---------------------------

(defsystem system-name
   (system-options*)
   module-descriptions*
   )

Compile-system (function)

(compile-system system-name {keys})
     Compiles  all modules requiring recompilation.  The recompile keyword will
cause all recompilations to occur regardless of 'need'.  Need is determined  by
the date-time of the respective binary and source files.

(load-system system-name {keys})
     Loads modules of a system.  Load-system  is  called  recursively  for  all
required systems.  Keyword options are:

(show-system system-name)
     Pretty output of system description.


∂22-May-87  1609	DLW@ALDERAAN.SCRC.Symbolics.COM 	defsystem   
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 22 May 87  16:09:40 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 84991; Fri 22-May-87 19:09:02 EDT
Date: Fri, 22 May 87 19:08 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: defsystem
To: primerd!DOUG@ENX.Prime.PDN, COMMON-LISP@SAIL.STANFORD.EDU
In-Reply-To: <8705222127.AA16674@primerd.prime.com>
Message-ID: <870522190809.5.DLW@CHICOPEE.SCRC.Symbolics.COM>

I thought this would be a nice test case to see how good Common Lisp is
for making portable code, so I tried it out.

It looks as if the function COMPILE-IF-NEEDED needs to have a
declaration, saying (DECLARE (SPECIAL SYSTEM COMPILED-MODULES)) in it,
in order to work properly.  Does your CL implementation work without
such a declaration?  If so, you might want to check into that, since it
oughtn't, if I'm not mistaken.

It would also be nice to put in (DECLARE (IGNORE LEVEL)) in the
functions PRINT-SYSTEM and PRINT-MODULE, just to suppress the compiler
warnings.

There are a few places that manipulate pathnames by using concatenate to
append a file name to a directory name.  That'll work OK with the PRIME
file system (and Symbolics's file system), but it won't with several
others, because syntaxes vary.  It should use the pathname manipulation
functions in CL.

I tried running it on a simple case.  It signalled an error, trying to
find the file-write-date of a bin file that didn't exist yet, because
the source file (which I had just created) had never been compiled.
This appears to be our bug; file-write-date is supposed to return NIL
"if it cannot be determined".  After I fixed this, compile-system,
load-system, and show-system appeared to work properly.

∂25-May-87  0459	GZ%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	All arrays can be adjustable?   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 May 87  04:59:23 PDT
Date: Mon 25 May 87 07:58:15-EDT
From: "Gail Zacharias" <GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: All arrays can be adjustable?
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <12305170113.39.GZ@OZ.AI.MIT.EDU>

The description of ADJUST-ARRAY (bottom of p. 297) says "It is not permitted
to call adjust-array on an array that was not created with the :adjustable
option."

Of course, assuming "not permitted" means "is an error" rather than "signals
an error", an implementation is free to make an extension to CL and have
ADJUST-ARRAY work on some arrays which weren't created with the :ADJUSTABLE
option, and non-portable code is free to take advantage of such an extension.
It seems rather pointless to me, however.  Unless the user has detailed
knowledge of exactly which combinations of other arguments to MAKE-ARRAY will
allow ADJUST-ARRAY to work, he has no business trying to adjust an array which
he didn't ask to be adjustable.  A friendly implementation would signal an
error, at least when running in a safe mode.
-------

∂25-May-87  1032	primerd!doug@enx.prime.pdn 	Revision 2.1 of public defsystem available
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 May 87  10:32:31 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 
	id <AA19645@EDDIE.MIT.EDU>; Mon, 25 May 87 13:30:19 EDT
Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail)
	id AA01965; Mon, 25 May 87 11:28:04 EDT
Message-Id: <8705251528.AA01965@primerd.prime.com>
Received: (from user DOUG) by ENX.Prime.PDN; 25 May 87 11:06:33 EST
Subject: Revision 2.1 of public defsystem available
To: common-lisp@sail.stanford.edu
From: primerd!DOUG@ENX.Prime.PDN
Date: 25 May 87 11:06:33 EST

There is a new version of defsys available for public ftp from SAIL.  This
version has make-pathname instead of concatenate for constructing source and
binary paths and so will work on systems that don't have regularly formed
pathnames.  This version should also compile without any errors or warnings.

Cheers,

Doug (doug@enx.prime.com)

∂01-Jun-87  0840	DALY@IBM.COM 	type specifiers 
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 1 Jun 87  08:37:05 PDT
Date: 1 June 1987, 11:24:47 EDT
From: Timothy Daly <DALY@ibm.com>
To:   common-lisp@sail.stanford.edu
Message-Id: <060187.112448.daly@ibm.com>
Subject: type specifiers

CLtL states that
  (SIMPLE-VECTOR *) is an abbreviation for (VECTOR T *)
 except that the elements are of type simple vector (p47)

CLtL states that
 If a type specifier is a list, the car of the list is a symbol
and the rest of the list is subsidiary type information. ... (p42)

CLtL state that
 As a convenience, if a list has one or more unspecified items
at the end, such items may simply be dropped rather than writing
an explicit * for each one. (p43)

Is (SIMPLE-VECTOR T) valid? (semantics: (SIMPLE-VECTOR T *))

tim
DALY@IBM.COM

∂01-Jun-87  1929	RWK@YUKON.SCRC.Symbolics.COM 	type specifiers
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87  19:28:51 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 217124; Mon 1-Jun-87 22:12:56 EDT
Date: Mon, 1 Jun 87 22:12 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: type specifiers
To: Timothy Daly <DALY@ibm.com>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <060187.112448.daly@ibm.com>
Message-ID: <870601221248.6.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

    Date: 1 June 1987, 11:24:47 EDT
    From: Timothy Daly <DALY@ibm.com>

    CLtL states that
      (SIMPLE-VECTOR *) is an abbreviation for (VECTOR T *)
     except that the elements are of type simple vector (p47)

[This doesn't relate to your question, but...]

A serious bit of miswording, that.  It should have said
"except that it additionally specifies that OBJECTS OF THE
TYPE are @I(simple) arrays."  I don't have a current list
of corrections to the manual; is this on it already?

    CLtL states that
     If a type specifier is a list, the car of the list is a symbol
    and the rest of the list is subsidiary type information. ... (p42)
[I'm not sure how this part relates to your question.]

    CLtL state that
     As a convenience, if a list has one or more unspecified items
    at the end, such items may simply be dropped rather than writing
    an explicit * for each one. (p43)

    Is (SIMPLE-VECTOR T) valid? (semantics: (SIMPLE-VECTOR T *))

No.  I don't know why you thought it might, so I'm not sure this is
the most helpful answer, but I think p47 is pretty clear that SIMPLE-VECTOR
takes only a single argument, a size.  I.e. (SIMPLE-VECTOR 47) =
(SIMPLE-ARRAY T 47).

However, I think this is really also a bug in the manual, and that it is
SUPPOSED to take two arguments, like you apparently thought, and it was
accidentally edited to take arguments like SIMPLE-STRING instead of
SIMPLE-ARRAY.  Unfortunately, we've been using the manual to specify the
language, and at this point I think this would have to be regarded as
an incompatible change.  (I still think we should fix it; SIMPLE-VECTOR
is of much less use as currently defined, and quite confusing).

If we fix it as described, then the answer to your question is YES.

    tim
    DALY@IBM.COM


∂03-Jun-87  0739	Mailer@XX.LCS.MIT.EDU 	SIMPLE-VECTOR    
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87  07:39:40 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 3 Jun 87 10:38-EDT
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by LIVE-OAK.LCS.MIT.EDU.ARPA via DIAL with SMTP id 45438; 3 Jun 87 10:23:47-EDT
Received: from DWORKIN.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 1187; 2 Jun 87 21:55:44-EDT
Date: Tue, 2 Jun 87 21:54 EDT
From: Glenn S. Burke <gsb@JASPER.PALLADIAN.COM>
Subject: SIMPLE-VECTOR
To: RWK@YUKON.SCRC.Symbolics.COM, DALY@ibm.com
cc: common-lisp@sail.stanford.edu
In-Reply-To: <870601221248.6.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <870602215436.6.GSB@DWORKIN.PALLADIAN.COM>
Reply-To: Glenn S. Burke <GSB%JASPER@LIVE-OAK.LCS.MIT.EDU>

    Date: Mon, 1 Jun 87 22:12 EDT
    From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>

	Date: 1 June 1987, 11:24:47 EDT
	From: Timothy Daly <DALY@ibm.com>

        . . .

	Is (SIMPLE-VECTOR T) valid? (semantics: (SIMPLE-VECTOR T *))

    No.  I don't know why you thought it might, so I'm not sure this is
    the most helpful answer, but I think p47 is pretty clear that SIMPLE-VECTOR
    takes only a single argument, a size.  I.e. (SIMPLE-VECTOR 47) =
    (SIMPLE-ARRAY T 47).

    However, I think this is really also a bug in the manual, and that it is
    SUPPOSED to take two arguments, like you apparently thought, and it was
    accidentally edited to take arguments like SIMPLE-STRING instead of
    SIMPLE-ARRAY.  Unfortunately, we've been using the manual to specify the
    language, and at this point I think this would have to be regarded as
    an incompatible change.  (I still think we should fix it; SIMPLE-VECTOR
    is of much less use as currently defined, and quite confusing).

    If we fix it as described, then the answer to your question is YES.

Historically, SIMPLE-VECTOR is a contraction of SIMPLE-GENERAL-VECTOR, i.e.
(SIMPLE-ARRAY T (*)) -- it IS intentionally like SIMPLE-STRING.  The name got
contracted because many got bent out of shape by the length of SIMPLE-GENERAL-VECTOR,
and I guess no one argued (strongly enough?) against the inconsistent nomenclature.

I think this has caused enough confusion to require attention and an eventual change,
but I am against any reinterpretation of the meaning in the current CL incarnation.
Without looking, i would bet that the only inconsistency is in the name itself, and
the manual is fairly clear on what it means.


∂03-Jun-87  1004	gls@Think.COM 	Latin
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Jun 87  10:04:20 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 13:06:50 EDT
Date: Wed, 3 Jun 87 13:04 EDT
From: Guy Steele <gls@Think.COM>
Subject: Latin
To: common-lisp@sail.stanford.edu
Cc: gls@think.com
Message-Id: <870603130434.8.GLS@BOETHIUS.THINK.COM>

    Date: Fri, 22 May 1987  11:14 EDT
    From: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
    
    
	Implementors are informally encouraged to print either the decimal
	equivalent, or else the phrase
    
	    GUIDO CANTABRIGIENSIS PERDITOR PERDELIRUS
    
    
    OK, somebody has to ask: What, O mighty and imponederable Quux, does
    this phrase mean in English, if indeed it is translatable and not too
    obscene for transmission via netmail?

How does "Guy of Cambridge, that brain-damaged loser" grab you?

∂03-Jun-87  1505	RWK@YUKON.SCRC.Symbolics.COM 	SIMPLE-VECTOR  
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 3 Jun 87  15:05:25 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 218481; Wed 3-Jun-87 18:03:12 EDT
Date: Wed, 3 Jun 87 18:03 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: SIMPLE-VECTOR
To: Glenn S. Burke <GSB%JASPER@LIVE-OAK.LCS.MIT.EDU>
cc: DALY@ibm.com, common-lisp@sail.stanford.edu
In-Reply-To: <870602215436.6.GSB@DWORKIN.PALLADIAN.COM>
Message-ID: <870603180301.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

    Date: Tue, 2 Jun 87 21:54 EDT
    From: Glenn S. Burke <gsb@JASPER.PALLADIAN.COM>
    Historically, SIMPLE-VECTOR is a contraction of SIMPLE-GENERAL-VECTOR, i.e.
    (SIMPLE-ARRAY T (*)) -- it IS intentionally like SIMPLE-STRING.  The name got
    contracted because many got bent out of shape by the length of SIMPLE-GENERAL-VECTOR,
    and I guess no one argued (strongly enough?) against the inconsistent nomenclature.
I was just guessing, since I didn't pay attention when this was discussed.

    I think this has caused enough confusion to require attention and an eventual change,
    but I am against any reinterpretation of the meaning in the current CL incarnation.
    Without looking, i would bet that the only inconsistency is in the name itself, and
    the manual is fairly clear on what it means.
Right, I believe the manual is consistant.  Perhaps the cleanup to be done
here is to note (in the next printing of the manual?) that the terminology is
is inconsistant.

Unfortunately, leaving it inconsistant means this highly-specific and less
useful thing is taking up the obvious name for a less-specific and more
flexible and useful thing.  What would one call this more useful thing?
SIMPLE-VECTOR-MAYBE-NOT-GENERAL?  SIMPLE-VECTOR-SPECIALIZED?
SIMPLE-VECTOR-TWO-ARGUMENTS?

∂03-Jun-87  1856	Moon@STONY-BROOK.SCRC.Symbolics.COM 	SIMPLE-VECTOR
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Jun 87  18:56:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 163443; Wed 3-Jun-87 21:55:02 EDT
Date: Wed, 3 Jun 87 21:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SIMPLE-VECTOR
To: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
cc: Glenn S. Burke <GSB%JASPER@LIVE-OAK.LCS.MIT.EDU>, DALY@ibm.com, common-lisp@sail.stanford.edu
In-Reply-To: <870603180301.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <870603215451.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 3 Jun 87 18:03 EDT
    From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>

	Date: Tue, 2 Jun 87 21:54 EDT
	From: Glenn S. Burke <gsb@JASPER.PALLADIAN.COM>
	Historically, SIMPLE-VECTOR is a contraction of SIMPLE-GENERAL-VECTOR

    ....this highly-specific and less
    useful thing is taking up the obvious name for a less-specific and more
    flexible and useful thing.  What would one call this more useful thing?
    SIMPLE-VECTOR-MAYBE-NOT-GENERAL?  SIMPLE-VECTOR-SPECIALIZED?
    SIMPLE-VECTOR-TWO-ARGUMENTS?

(SIMPLE-ARRAY * 1).  I don't think we need to add even more names for
subtypes of ARRAY to Common Lisp; there are already too many.

I of course would prefer to remove the whole concept of "simple arrays" from
Common Lisp.  But it's certainly not my decision.

∂04-Jun-87  0802	RAM@C.CS.CMU.EDU 	SIMPLE-VECTOR    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Jun 87  08:02:08 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 4 Jun 87 10:59:34-EDT
Date: Thu, 4 Jun 1987  10:59 EDT
Message-ID: <RAM.12307824544.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To:   "Robert W. Kerns" <RWK@SCRC-YUKON.ARPA>
Cc:   common-lisp@SAIL.STANFORD.EDU, DALY@IBM.COM,
      "Glenn S. Burke" <GSB%JASPER@LIVE-OAK.LCS.MIT.EDU>
Subject: SIMPLE-VECTOR
In-reply-to: Msg of 3 Jun 1987  18:03-EDT from Robert W. Kerns <RWK at YUKON.SCRC.Symbolics.COM>


SIMPLE-VECTOR started out meaning "one dimensional simple array" with
exactly the syntax you suggest, and it was changed to the current
semantics.  I believe this was because Moon argued that that
interpretation of simple-vector is fairly useless, at least without an
element type being specified.  Since under that interpretation, SVREF
is useless, it made sense to flush the bletcherous SGVREF and make
SVREF do that useful thing.  I believe that the SIMPLE-ARRAY type was
introduced at the same time.

Note that the old SIMPLE-VECTOR can easily be defined using
SIMPLE-ARRAY:
  (deftype rwk-array (&optional type size)
     `(simple-array ,type (,size)))

  Rob

∂04-Jun-87  1425	RWK@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	SIMPLE-VECTOR   
Received: from ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM by SAIL.STANFORD.EDU with TCP; 4 Jun 87  14:25:10 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 181251; Thu 4-Jun-87 17:11:57 EDT
Date: Thu, 4 Jun 87 17:12 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: SIMPLE-VECTOR
To: Ram@C.CS.CMU.EDU
cc: common-lisp@SAIL.STANFORD.EDU, DALY@IBM.COM, Glenn S. Burke <GSB%JASPER@LIVE-OAK.LCS.MIT.EDU>
In-Reply-To: <RAM.12307824544.BABYL@>
Message-ID: <870604171246.5.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

    Date: Thu, 4 Jun 1987  10:59 EDT
    From: Ram@C.CS.CMU.EDU
    Note that the old SIMPLE-VECTOR can easily be defined using
    SIMPLE-ARRAY:
      (deftype rwk-array (&optional type size)
	 `(simple-array ,type (,size)))

Certainly.  My only concern is that I don't think RWK-ARRAY
is quite the right name.  There's no issue here larger than
what name to attach to which concept.  It doesn't seem worth
the energy it will take to do anything about it.

∂04-Jun-87  2350	@Score.Stanford.EDU,@MCC.COM:krall%pp.mcc.com@mcc.com 	Interpretation Needed for #+feature
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jun 87  23:50:29 PDT
Received: from MCC.COM by SU-SCORE.ARPA with TCP; Thu 4 Jun 87 09:26:19-PDT
Received: from pp.mcc.com by MCC.COM with TCP; Thu 4 Jun 87 11:23:55-CDT
Posted-Date: Thursday, 4 June 1987, 11:23-CDT
Message-Id: <8706041624.AA15436@pp.mcc.com>
Received: from amber.pp.mcc.com by pp.mcc.com (4.12/KA70505) 
	id AA15436; Thu, 4 Jun 87 11:24:14 cdt
Date: Thursday, 4 June 1987, 11:23-CDT
From: <krall%pp.mcc.com%pp.mcc.com@mcc.com>
Sender: krall%pp.mcc.com@mcc.com
Subject: Interpretation Needed for #+feature
To: common-lisp@SAIL.STANFORD.EDU


On some systems (LMI Lambda, KCL) the form below is NOT read (or, at least,
	I get no complaint):

#+symbolics (local-symbolics-package:name a b c)

On Golden Common Lisp, however, the reader balks because it cannot resolve
	local-symbolics-package:name since the package does not exist.

Naturally, I prefer the first behavior for writing code to be moved to
	many different machines.  What is the correct interpretation?



-Ed Krall
Parallel Processing Program
Microelectronics and Computer Technology Corporation
3500 West Balcones Center Drive
Austin, Texas  78759
(512) 338-3406
ARPA: krall@mcc.com
UUCP: {ihnp4,seismo,ctvax}!ut-sally!im4u!milano!mcc-pp!krall

∂05-Jun-87  0734	samalone@ATHENA.MIT.EDU 	Re: Interpretation Needed for #+feature 
Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Jun 87  07:34:35 PDT
Received: by ATHENA (5.45/4.7)
	id AA03976; Fri, 5 Jun 87 10:35:33 EDT
From: <samalone@ATHENA.MIT.EDU>
Received: by HADES.MIT.EDU (5.45/4.7) id AA16032; Fri, 5 Jun 87 10:31:50 EDT
Message-Id: <8706051431.AA16032@HADES.MIT.EDU>
To: common-lisp@sail.stanford.edu
Subject: Re: Interpretation Needed for #+feature 
Date: Fri, 05 Jun 87 10:31:49 EDT


One of the many unimplemented features of Golden Common Lisp is
*READ-SUPPRESS*, which is why GCLisp does the wrong thing with #+ and #-.
(See page 345 of CLtL.)

I have successfully gotten around the problem by redefining the #+ and #-
reader macros to do the following instead of binding *READ-SUPPRESS*:

	Copy the current readtable and save it.

	Modify the entry for #\: to make it behave the same as #\A.

	Read the suppressed form.

	Restore the old readtable.

Even this is not easy because, although GCLisp has readtables, it is missing
the standard readtable functions.  Send me mail if you need help.

				--Stuart A. Malone

∂05-Jun-87  1017	sandra%orion@cs.utah.edu 	historical question about CASE    
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 5 Jun 87  10:17:49 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
	id AA22787; Fri, 5 Jun 87 11:19:24 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
	id AA26939; Fri, 5 Jun 87 11:19:20 MDT
Date: Fri, 5 Jun 87 11:19:20 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8706051719.AA26939@orion.utah.edu>
Subject: historical question about CASE
To: common-lisp@sail.stanford.edu

While porting some code between CL implementations, I got bit by the fine
print in the manual about how NIL was not allowed as a singleton key in
CASE, as it could be confused with an empty key list.  It's easy enough
to wrap a pair of parentheses around the NIL, but I got to thinking that
an empty key list is not very interesting anyway.  Does anyone remember why
it was decided to treat NIL as a list instead of a symbol in this context?

Just curious,

-Sandra
-------

∂05-Jun-87  1019	RPG   	JIS LISP WG of this year    
Received: from utokyo-relay by RELAY.CS.NET id ab00570; 5 Jun 87 3:03 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
	id AA17054; Fri, 5 Jun 87 15:26:01 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
	id AA17711; Fri, 5 Jun 87 15:23:12+0900
Date: Fri, 5 Jun 87 15:23:12+0900
From: a37078%tansei.cc.u-tokyo.junet@utokyo-relay.csnet (Masayuki Ida)
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8706050623.AA17711@tansei.cc.u-tokyo.junet>
To: fahlman@c.cs.cmu.edu, gls@think.com,
        ida%tansei.cc.u-tokyo.junet@utokyo-relay.csnet, mathis@ada20.isi.edu,
        rpg@su-ai.arpa
Subject: JIS LISP WG of this year

Dear Sirs,

The JIS LISP WG of 1986 was finished March 3rd.
To organize the JIS LISP WG of 1987, we had a preparatory meeting on May 29 Fri.
On the meeting, we welcomed the new chair from Tohoku-university.
His name is Prof. T. Itoh.
He is, I think, about 50 years old and a full professor.
I hope he can settle the matter.
I am a member of the WG.
But the rest of the membership is still misty.
There are still hot debate on the starring.
The meeting of May 29 itself could not enter technical issues.
I feel our JIS situation is the prelude to ISO situation.
MITI person suggested the possibility of the joint effort with ANSI,
but as we had no request from US, his suggestion was not fully understood
by the attendant.

May God Bless us.

Masayuki Ida



∂05-Jun-87  1020	RPG   	Re: JIS LISP WG of this year
 ∂05-Jun-87  0443	MATHIS@ADA20.ISI.EDU 	Re: JIS LISP WG of this year
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Jun 87  04:43:05 PDT
Date: 5 Jun 1987 04:40-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: Re: JIS LISP WG of this year
From: MATHIS@ADA20.ISI.EDU
To: a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Cc: fahlman@C.CS.CMU.EDU, gls@THINK.COM
Cc: rpg@SAIL.STANFORD.EDU
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Jun-87 04:40:08.MATHIS>
In-Reply-To: <8706050623.AA17711@tansei.cc.u-tokyo.junet>

Masayuki,

You mentioned a "nonexistent" request from ANSI.  ANSI is very
hard to get to do anything; but know that you have a standing
offer from X3J13 for any kind of reasonable cooperation.  As
Chairman of that committee, I can act on this matter in the
absence of ANSI direction to the contrary.  If all that sounds
backward, remember this is a nation of lawyers.  As Lispers lets
get together.

Bob

∂05-Jun-87  1142	barmar@Think.COM 	historical question about CASE  
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87  11:42:34 PDT
Received: from occam by Think.COM via CHAOS; Fri, 5 Jun 87 14:44:06 EDT
Date: Fri, 5 Jun 87 14:41 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: historical question about CASE
To: Sandra J Loosemore <sandra%orion@cs.utah.edu>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8706051719.AA26939@orion.utah.edu>
Message-Id: <870605144148.3.BARMAR@OCCAM.THINK.COM>

    Date: Fri, 5 Jun 87 11:19:20 MDT
    From: sandra%orion@cs.utah.edu (Sandra J Loosemore)

    While porting some code between CL implementations, I got bit by the fine
    print in the manual about how NIL was not allowed as a singleton key in
    CASE, as it could be confused with an empty key list.  It's easy enough
    to wrap a pair of parentheses around the NIL, but I got to thinking that
    an empty key list is not very interesting anyway.  Does anyone remember why
    it was decided to treat NIL as a list instead of a symbol in this context?

    Just curious,

    -Sandra
    -------

I don't remember specifically, but I would guess that it is for the
benefit of macros that take a lists of things and turn them into case
clauses.  For example:

(defmacro do-something (thing &key allow-list ignore-list complain-list)
  `(case ,thing
     (,allow-list (frob-thing ,thing))
     (,ignore-list nil)
     (,complain-list (error "I won't frob ~S!" ,thing))))

By the way, this is probably a good time to remind people that if they
write macros that make a case clause out of each element of a list, they
should always make them be lists of one element, not singleton keys.
Here's a trivial example:

(defmacro my-case (object &rest clauses)
  "Like CASE, but only takes singleton keys."
  `(case .,(loop for (key . consequent) in clauses	;I know it isn't CL LOOP
		 collect `((,key) .,consequent))))

						barmar

∂05-Jun-87  1313	SOLEY@XX.LCS.MIT.EDU 	historical question about CASE   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Jun 87  13:12:44 PDT
Date: Fri, 5 Jun 1987  16:11 EDT
Message-ID: <SOLEY.12308143452.BABYL@XX.LCS.MIT.EDU>
From: SOLEY@XX.LCS.MIT.EDU
To:   Barry Margolin <barmar@THINK.COM>
Cc:   common-lisp@SAIL.STANFORD.EDU,
      Sandra J Loosemore <sandra%orion@CS.UTAH.EDU>
Subject: historical question about CASE
In-reply-to: Msg of 5 Jun 1987  14:41-EDT from Barry Margolin <barmar at Think.COM>

    Date: Friday, 5 June 1987  14:41-EDT
    From: Barry Margolin <barmar at Think.COM>
    To:   Sandra J Loosemore <sandra%orion at cs.utah.edu>

        Date: Fri, 5 Jun 87 11:19:20 MDT
        From: sandra%orion@cs.utah.edu (Sandra J Loosemore)

        While porting some code between CL implementations, I got bit . . .
	Does anyone remember why it was decided to treat NIL as a list
	instead of a symbol in this context?

    I don't remember specifically, but I would guess that it is for the
    benefit of macros that take a lists of things and turn them into case
    clauses.  For example:

    (defmacro do-something (thing &key allow-list ignore-list complain-list)
      `(case ,thing
         (,allow-list (frob-thing ,thing))
         (,ignore-list nil)
         (,complain-list (error "I won't frob ~S!" ,thing))))

Silly Programmer, hacks are for kids.  That's no reason.

(defmacro do-something (thing &key allow-list ignore-list complain-list)
  (append `(case ,thing)
	  (if allow-list `((,allow-list (frob-thing ,thing))))

	  .. etc ..
  ))

	-- Richard

∂05-Jun-87  1400	gls@Think.COM 	historical question about CASE
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87  13:59:51 PDT
Received: from boethius by Think.COM via CHAOS; Fri, 5 Jun 87 17:01:16 EDT
Date: Fri, 5 Jun 87 16:59 EDT
From: Guy Steele <gls@Think.COM>
Subject: historical question about CASE
To: SOLEY@xx.lcs.mit.edu, barmar@think.com
Cc: common-lisp@sail.stanford.edu, sandra%orion@cs.utah.edu, gls@think.com
In-Reply-To: <SOLEY.12308143452.BABYL@XX.LCS.MIT.EDU>
Message-Id: <870605165904.4.GLS@BOETHIUS.THINK.COM>

    Date: Fri, 5 Jun 1987  16:11 EDT
    From: SOLEY@xx.lcs.mit.edu

	Date: Friday, 5 June 1987  14:41-EDT
	From: Barry Margolin <barmar at Think.COM>
	To:   Sandra J Loosemore <sandra%orion at cs.utah.edu>

	    Date: Fri, 5 Jun 87 11:19:20 MDT
	    From: sandra%orion@cs.utah.edu (Sandra J Loosemore)

	    While porting some code between CL implementations, I got bit . . .
	    Does anyone remember why it was decided to treat NIL as a list
	    instead of a symbol in this context?

	I don't remember specifically, but I would guess that it is for the
	benefit of macros that take a lists of things and turn them into case
	clauses.  For example:

	(defmacro do-something (thing &key allow-list ignore-list complain-list)
	  `(case ,thing
	     (,allow-list (frob-thing ,thing))
	     (,ignore-list nil)
	     (,complain-list (error "I won't frob ~S!" ,thing))))

    Silly Programmer, hacks are for kids.  That's no reason.

    (defmacro do-something (thing &key allow-list ignore-list complain-list)
      (append `(case ,thing)
	      (if allow-list `((,allow-list (frob-thing ,thing))))

	      .. etc ..
      ))

	    -- Richard

Why APPEND?  What's wrong with this:

(defmacro do-something (thing &key allow-list ignore-list complain-list)
  `(case ,thing
     ,@(when allow-list `((,allow-list (frob-thing ,thing))))
     ,@(when ignore-list `((,ignore-list nil)))
     ,@(when complain-list `((,complain-list (error "I won't frob ~S!" ,thing))))))

I use the idiom ",@(when foo `(...baz...))" a LOT.

But indeed, perhaps () as a case item should not have been made
to mean an empty list.  But it's probably too late now.
--Guy

∂05-Jun-87  1400	barmar@Think.COM 	historical question about CASE  
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87  13:59:51 PDT
Received: from occam by Think.COM via CHAOS; Fri, 5 Jun 87 17:01:33 EDT
Date: Fri, 5 Jun 87 16:59 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: historical question about CASE
To: SOLEY@xx.lcs.mit.edu
Cc: common-lisp@sail.stanford.edu,
        Sandra J Loosemore <sandra%orion@cs.utah.edu>
In-Reply-To: <SOLEY.12308143452.BABYL@XX.LCS.MIT.EDU>
Message-Id: <870605165918.7.BARMAR@OCCAM.THINK.COM>

    Date: Fri, 5 Jun 1987  16:11 EDT
    From: SOLEY@xx.lcs.mit.edu

	(defmacro do-something (thing &key allow-list ignore-list complain-list)
	  `(case ,thing
	     (,allow-list (frob-thing ,thing))
	     (,ignore-list nil)
	     (,complain-list (error "I won't frob ~S!" ,thing))))

    Silly Programmer, hacks are for kids.  That's no reason.

    (defmacro do-something (thing &key allow-list ignore-list complain-list)
      (append `(case ,thing)
	      (if allow-list `((,allow-list (frob-thing ,thing))))

	      .. etc ..
      ))

I don't know about you, but I find mine much easier to read.

						barmar

∂10-Jun-87  0755	dml@NADC.ARPA 	Common LISP omissions: Collect, Locatives    
Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87  07:55:21 PDT
Received: by NADC.ARPA (5.51/1.0 )
	id AA08852; Wed, 10 Jun 87 10:53:14 EDT
Date: Wed, 10 Jun 87 10:53:14 EDT
From: dml@nadc.arpa (D. Loewenstern)
Message-Id: <8706101453.AA08852@NADC.ARPA>
To: common-lisp@sail.stanford.edu
Subject: Common LISP omissions: Collect, Locatives
Cc: dml@NADC.ARPA, silbert@NADC.ARPA

We have been using Common LISP and have noticed two  
important omissions in the language.  
 
  1) Locatives ("LOCF" as found in ZetaLISP). 
  2) A COLLECT macro. 
 
  A primary reason for locatives would be to create your own  
"hash-on-eq" functions.  Common LISP provides SXHASH which  
hashes on equal.  A serious problem occurs if the keys are  
circular objects. 
 
  A collect macro would allow the construction of lists  
maintaining the order of creation.  Currently, the only way  
to produce the same effect, would be to use PUSH and the  
NREVERSE.  If the programmer intends to use the partially  
constructed list, it would need to be REVERSEd each time.   
An example of the collection macro could look like: 
 
(DEFMACRO With-Collection (vars &body body) 
  (LET (collects gensym) 
     (DOLIST (var vars) 
       (SETQ gensym (GENSYM var)) 
       (PUSH gensym (GET var :collect)) 
       (PUSH gensym collects)) 
     (PROG1 
       `(LET (,@vars ,@collects) 
              ,@(Macroexpand-All body)) 
       (DOLIST (var vars) (POP (GET var :collect))))) 
  ) 
 
(DEFMACRO Collect (obj place) 
  (LET ((endptr (CAR (GET place :collect)))) 
  `(COND 
    (,place (SETF (CDR ,endptr) (NCONS ,obj)) 
            (SETQ ,endptr (CDR ,endptr))) 
    (T (SETQ ,place (NCONS ,obj)) 
       (SETQ ,endptr ,place)))) 
) 
   
(DEFUN Macroexpand-All (form &AUX (mac (MACROEXPAND form))) 
  (IF (CONSP form) 
      (CONS (Macroexpand-All (CAR mac)) (Macroexpand-All (CDR mac))) 
    mac)) 
 
  It would be easier to implement the collect macro if a  
function like LOCF existed.  Furthermore, we would not need  
to check the partially constructed list each time to  
determine whether it was still empty (see the COND in  
#'Collect). 
 
  ZetaLISP's LOOP macro includes the collect facility, but  
collection should be possible outside of a loop (for  
example, when searching through a graph). 
 
 
David Loewenstern
Mark Silbert
Naval Air Development Center, code 7013
Warminster, PA 18974

<dml@nadc.arpa>
<silbert@nadc.arpa>

∂10-Jun-87  0837	FAHLMAN@C.CS.CMU.EDU 	Common LISP omissions: Collect, Locatives  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Jun 87  08:37:04 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 10 Jun 87 11:35:55-EDT
Date: Wed, 10 Jun 1987  11:35 EDT
Message-ID: <FAHLMAN.12309404026.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   dml@λnadc.arpa (D. Loewenstern)λ
Cc:   common-lisp@SAIL.STANFORD.EDU, silbert@NADC.ARPA
Subject: Common LISP omissions: Collect, Locatives
In-reply-to: Msg of 10 Jun 1987  10:53-EDT from dml at nadc.arpa (D. Loewenstern)


We considered adding locatives early in the original design process, but
decided that they didn't make much sense except on machines with
hardware support for forwarding pointers.  Lisp machines can use
locatives to implement other Common Lisp constructs, but we felt that it
would be confusing to users and something of a performance trap to make
them part of the portable language, that also has to run well on stock
hardware.

As for collect, when something can be written without any special
problems in the existing language, our strategy has been to add it to
the standard only if (1) a LOT of people would otherwise end up coding
this hack for themselves and (2) a single built-in version would satisfy
all of those users.  If that kind of need can be demonstrated for
COLLECT, it should go in; if not, it should be added to the
public-domain library for those people who do want it.

Most of the critics of Common Lisp feel that we have put in too many of
these optional things already.

-- Scott

∂10-Jun-87  1101	hoey@nrl-aic.ARPA 	LISP:STRUCTURE ?
Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87  11:01:39 PDT
Return-Path: <hoey@nrl-aic.ARPA>
Received: Wed, 10 Jun 87 13:59:26 edt by nrl-aic.ARPA id AA29108
Date: 10 Jun 1987 12:43:18 EDT (Wed)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: LISP:STRUCTURE ?
To: common-lisp@sail.stanford.edu
Message-Id: <550341798/hoey@nrl-aic>

1. Is there a symbol named "STRUCTURE" in the LISP package?  In all the
``official'' lists I have seen, the symbol appears.  Yet I find no
mention of it in CLtL nor in the lists of errata.

2. In the Common Lisps I have been able to test, LISP:STRUCTURE names a
type of which types defined by DEFSTRUCT are subtypes.  Is STRUCTURE a
standard type that should be added to table 4-1?

3. If the answer to 1 is yes, and the answer to 2 is no, then what is
LISP:STRUCTURE for?

Dan

∂10-Jun-87  1120	RAM@C.CS.CMU.EDU 	LISP:STRUCTURE ? 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Jun 87  11:20:40 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Wed 10 Jun 87 14:17:47-EDT
Date: Wed, 10 Jun 1987  14:17 EDT
Message-ID: <RAM.12309433493.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To:   Dan Hoey <hoey@NRL-AIC.ARPA>
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: LISP:STRUCTURE ?
In-reply-to: Msg of 10 Jun 1987  12:43-EDT from Dan Hoey <hoey at nrl-aic.ARPA>


STRUCTURE is a documentation type: see the DOCUMENTATION function.  I
believe you are right that STRUCTURE is not a Common Lisp type
specifier.

  Rob

∂10-Jun-87  1121	KMP@STONY-BROOK.SCRC.Symbolics.COM 	LISP:STRUCTURE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87  11:21:14 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 169440; Wed 10-Jun-87 14:18:48 EDT
Date: Wed, 10 Jun 87 14:18 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: LISP:STRUCTURE
To: hoey@nrl-aic.ARPA
cc: Common-Lisp@SAIL.STANFORD.EDU
In-Reply-To: <550341798/hoey@nrl-aic>
Message-ID: <870610141846.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

See p440. STRUCTURE is a valid second argument to DOCUMENTATION and by
implication must be on the LISP package. As with VARIABLE, it is not a type.

∂10-Jun-87  1238	DALY@IBM.COM 	locatives...    
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 10 Jun 87  12:37:53 PDT
Date: 10 June 1987, 15:13:19 EDT
From: Timothy Daly <DALY@ibm.com>
To:   common-lisp@sail.stanford.edu
Message-Id: <061087.151319.daly@ibm.com>
Subject: locatives...

Re: locatives

We also have felt the need to do hashing-on-eq type of operations.
That is, we would like to be able to hash a pair consisting
of (address of left subtree . address of right subtree).
Unfortunately, SXHASH will walk both subtrees which is much
too expensive. We could think of no portable way to implement
this in common lisp. Since the language gives us no way to
implement this it does not seem that locatives are a frill.

tim
DALY@IBM.COM
T.J.Watson Research, Yorktown.

∂10-Jun-87  1415	Moon@VALLECITO.SCRC.Symbolics.COM 	Common LISP omissions: Locatives   
Received: from SCRC-VALLECITO.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87  14:15:12 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 131870; Wed 10-Jun-87 17:09:32 EDT
Date: Wed, 10 Jun 87 17:07 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Common LISP omissions: Locatives
To: David Loewenstern <dml@NADC.ARPA>, Mark Silbert <silbert@NADC.ARPA>,
    Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, Timothy Daly <DALY@ibm.com>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8706101453.AA08852@NADC.ARPA>,
             <FAHLMAN.12309404026.BABYL@C.CS.CMU.EDU>,
             <061087.151319.daly@ibm.com>
Message-ID: <870610170743.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 10 Jun 87 10:53:14 EDT
    From: dml@nadc.arpa (D. Loewenstern)

    We have been using Common LISP and have noticed two  
    important omissions in the language.  
 
      1) Locatives ("LOCF" as found in ZetaLISP). 
      2) A COLLECT macro. 
 
[I won't address COLLECT in this particular message]

      A primary reason for locatives would be to create your own  
    "hash-on-eq" functions.  Common LISP provides SXHASH which  
    hashes on equal.  A serious problem occurs if the keys are  
    circular objects. 

Locatives have no relevance to hashing on EQ.  The Zetalisp feature you
are thinking of is %POINTER, not LOCF.  %POINTER is a function that
returns a number which is the address of its argument.  LOCF is a macro
that returns a locative that designates the cell that is designated by
the generalized variable (in the SETF sense) that is LOCF's first
subform.  The possible operations on locatives are getting the contents
of the cell, changing the contents of the cell, making the cell
"unbound", checking whether the cell is "unbound", comparing two
locatives for equality, and recovering the object that contains the cell.

It's pretty easy to make your own variant of SXHASH that detects
circularities, although it's bound to be a little slower.  I believe
the IBM VM/LISP people published a paper on this a while back.

    Date: 10 June 1987, 15:13:19 EDT
    From: Timothy Daly <DALY@ibm.com>

    We also have felt the need to do hashing-on-eq type of operations.
    That is, we would like to be able to hash a pair consisting
    of (address of left subtree . address of right subtree).
    Unfortunately, SXHASH will walk both subtrees which is much
    too expensive. We could think of no portable way to implement
    this in common lisp. Since the language gives us no way to
    implement this it does not seem that locatives are a frill.

There -is- no portable way to implement hashing-on-eq efficiently,
because it is inherently dependent on the implementation details of the
system's garbage collector.  For example, in many systems a garbage
collection changes the numerical value of the addresses of objects.  In
these systems, anything that depends on the numerical values of
addresses of objects has to be recomputed after a garbage collection.
It's difficult to come up with a portable and efficient way of doing
that, particularly in systems with multiple levels of garbage
collection, which several systems do in somewhat different ways.  It's
even harder to do it in a way that doesn't impose an efficiency burden
on systems where garbage collection does not change the numerical values
of object addresses.  This is why Common Lisp did not attempt to provide
a hash-on-eq primitive, that is, a function that returns a number given
an object, without looking at the contents of the object, and always
returns the same number for the same object.

There is a portable -inefficient- way to implement hashing-on-eq, which
is to use a hash table :test #'eq to remember what hash code you have
assigned to each object.  I have actually used this.  However, this is
usually too inefficient to be seriously considered.

    Date: Wed, 10 Jun 1987  11:35 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    We considered adding locatives early in the original design process, but
    decided that they didn't make much sense except on machines with
    hardware support for forwarding pointers.

Locatives have no relevance to forwarding pointers, nor do they have any
relevance to hardware support.

However, I agree that locatives should not be in Common Lisp.  My reason
is that only some of the possible Lisp implementation techniques for
object representation permit the efficient implementation of locatives. 
It is always possible to implement locatives, as T has demonstrated, but
it isn't always possible to implement them efficiently.  It seems
inappropriate to design the language in a way that would rule out some
otherwise reasonable implementation techniques (BIBOP, for example).

∂11-Jun-87  1313	gls@Think.COM 	Re: historical question about CASE 
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87  13:13:27 PDT
Received: from boethius by Think.COM via CHAOS; Thu, 11 Jun 87 16:15:05 EDT
Date: Thu, 11 Jun 87 16:12 EDT
From: Guy Steele <gls@Think.COM>
Subject: Re: historical question about CASE
To: FREEMAN@sumex-aim.stanford.edu
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <12309682881.14.FREEMAN@SUMEX-AIM.STANFORD.EDU>
Message-Id: <870611161254.3.GLS@BOETHIUS.THINK.COM>

    Date: Thu, 11 Jun 87 10:07:37 PDT
    From: Andy Freeman <FREEMAN@sumex-aim.stanford.edu>

    You wrote:
	I use the idiom ",@(when foo `(...baz...))" a LOT.

    I thought that it was considered poor style to use "when" for its
    value.  I may be confusing my dialects, but is there actually a
    guarantee that "when"'s definition is much like following?

    (defmacro when (pred &body x)
      `(if , pred (progn '() ,@ x)
	   '()))

Yes, there is such a guarantee: the second sentence of the
description of WHEN in CLTL, page 115.  (Did you look there?)

I agree that in this case I am not consistent; strictly speaking
perhaps AND is more appropriate, but I find WHEN mnemonically
more appealing in this context, and there is no question that
the value is being used, because of the presence of ",@" right
before the form.

--Guy

∂12-Jun-87  1022	dml@NADC.ARPA 	Hash-on-eq
Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 12 Jun 87  10:22:02 PDT
Received: by NADC.ARPA (5.51/1.0 )
	id AA22156; Fri, 12 Jun 87 13:20:34 EDT
Date: Fri, 12 Jun 87 13:20:34 EDT
From: dml@nadc.arpa (D. Loewenstern)
Message-Id: <8706121720.AA22156@NADC.ARPA>
To: daly@ibm.com
Subject: Hash-on-eq
Cc: common-lisp@sail.stanford.edu

     We have implemented a portable, efficient method for performing hash-on- 
eq upon structures: 
    1. Set up a global counter. 
    2. For each key structure that will be hashed, add an extra slot. 
    3. Each time a key structure is instantiated, the current value of the  
global counter is incremented and stored in the extra slot.  
    4. Instead of using SXHASH upon the key structure, use the accessor  
function to get the value in the extra slot.  
    As an added feature, this method will produce nearly uniform hash table  
distributions.  At the expense of introducing an extra slot per structure, you  
gain a very fast hashing function. 

David Loewenstern & Mark Silbert
<dml@nadc.arpa, silbert@nadc.arpa>

∂22-Jun-87  0422	fritzson@bigburd.PRC.Unisys.COM 	APPLY with 3+ arguments    
Received: from BIGBURD.PRC.UNISYS.COM by SAIL.STANFORD.EDU with TCP; 22 Jun 87  04:21:55 PDT
Received: from bigburd.PRC.Unisys.COM by burdvax.PRC.Unisys.COM (burdvax) [5.54/1.0] 
	id AA01279; Mon, 22 Jun 87 07:21:34 EDT
Received: by bigburd.PRC.Unisys.COM (bigburd) [5.54/1.0] 
	id AA16283; Mon, 22 Jun 87 07:21:31 EDT
From: Richard Fritzson <fritzson@bigburd.PRC.Unisys.COM>
Message-Id: <8706221121.AA16283@bigburd.PRC.Unisys.COM>
Received: from Plebian by bigburd with PUP; Mon, 22 Jun 87 07:21 EDT
Date: 22 Jun 87 07:19 EDT (Monday)
To: common-lisp@sail.stanford.edu
Subject: APPLY with 3+ arguments

Can anyone provide a motivation for the CLtL definition of APPLY when
more than one arglist is provided? I understand what it does perfectly
well, but I don't understand when I am going to have a use for this.

	-Rich Fritzson
	 ARPA: fritzson@prc.unisys.com
	 UUCP: {seismo,sdcrdcf,psuvax1}!burdvax!fritzson

∂22-Jun-87  0601	dml@NADC.ARPA 	Re:  APPLY with 3+ arguments  
Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 22 Jun 87  06:01:23 PDT
Received: by NADC.ARPA (5.51/1.0 )
	id AA03305; Mon, 22 Jun 87 09:01:16 EDT
Date: Mon, 22 Jun 87 09:01:16 EDT
From: dml@nadc.arpa (D. Loewenstern)
Message-Id: <8706221301.AA03305@NADC.ARPA>
To: common-lisp@sail.stanford.edu, fritzson@bigburd.prc.unisys.com
Subject: Re:  APPLY with 3+ arguments

I use 3+ arguments for APPLY often.  Usually, I use this when the first few arguments to a function
are known, but the remainder are to be passed in as a list:
    (APPLY #'MAX 0 list) == find the MAX of a list, but return 0 if all elements of the list are negative.

Naturally, this isn't strictly necessary -- you could write the above as:
    (MAX 0 (APPLY #'MAX list)) 

but I find the first preferable.
David Loewenstern
Naval Air Development Center
code 7013
Warminster, PA 18974-5000

<dml@nadc.arpa>

∂22-Jun-87  0654	@RELAY.CS.NET:kers@HPLB.CSNET 	I Like a Single Namespace    
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 22 Jun 87  06:53:56 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa13493; 22 Jun 87 9:19 EDT
Received: from hplb by RELAY.CS.NET id aa10406; 22 Jun 87 9:10 EDT
From: Christopher Dollin <kers%hplb.csnet@RELAY.CS.NET>
Date: Mon, 22 Jun 87 13:53:15 GMT
Message-Id: <25156.8706221353@hplb.lb.hp.co.uk>
To: common-lisp@SAIL.STANFORD.EDU
Subject:  I Like a Single Namespace

Issues in Function and Value Cells
------ -- -------- --- ----- -----

I have been reading "Issues of Separation in Function Cells and Value Cells"
and would like to add some comments. It is interesting to compare the choices
discussed in the paper, and taken in Common Lisp, with similar choices in the
language Pop11 (as instantiated in Poplog Version 11 onwards).

Pop is a good language for comparison purposes, as it falls into the same
general class as Lisp: imperative, interactive (and incremental), dynamically
typed, extensible. (In contrast to Lisp, it is compile-only, has orthodox
syntax, uses an open stack, and does not unite the notions of list and
program. But these are separate issues.)

Pop has (shallow) dynamic binding and (full) lexical binding, with variables
having only one value cell. In practice there does not seem to be any
particular problem with local names shadowing global ones (since Pop11 is
intended as, amongst other things, a teaching language, this is a significant
point). Why is this?

Partly because of the names of the built-in procedures. Some of them, such as
the underlying primitive "sysconslist", have names a user (especially a
beginner!) would be unlikely to choose. Some of them have such common and
well-entrenched meanings that it doesn't occur to anyone that they might use
them as variables (eg, "hd", the approximate equivalent of "car"). Many of
them are spelt with sign characters, eg the list brackets "[" and "]", the
append operator "<>"; it is less natural to use names like this for ordinary
variables,  especially for programmers originally trained in Pascal or C,
where the set of infix operators is not extensible.

The other reason is that those names are "protected"; they cannot be
redeclared or assigned to. Hence one learns rapidly which names are acceptable
and which are not; there are only a few names one misses being able to use
("in" and "to" are the ones that come to mind, and I once made the mistake of
reserving "a"). Experienced users can unprotect - and protect - names if they
so desire.

What about efficiency? Since there is only one value namespace, mustn't every
call be checked to ensure it is a procedure object being applied? In general,
yes.

The first observation is that Pop programs run "fast enough", so clearly the
inefficency induced by checking calls of every user procedure is not that
high. The second is that the only sort of type declaration supported (at
present) by the underlying implementation is that of declaring a variable to
be of type procedure, in which case only procedure values can be stored into
it and calls can be compiled as direct jumps rather than going through
"apply".

Variables can also be declared as "constant", permitting the compiler to avoid
generating additional indirections in the code (this is true for values other
than procedures as well, of course). Many system procedures are "protected
constant procedure"s. (As it happens, they are also not garbage-collected, and
have absolute addresses, but that's a separate issue).

What have we demonstrated? That, by example, the single namespace is workable,
and the possible disadvantages of efficiency and name clashes are countered by
declarations (a device Common Lisp already supports) and name protection (a
natural device that Common Lisp omits).

Another point worthy of note is the way Pop treats variable declarations. When
a variable is declared, it is annotated as being dynamic ("vars") or lexical
("lvars"). The declaration masks any that would be inherited from an outer
scope. Unlike Common Lisp, variables can be declared lexical at the "top
level" of a compilation (interaction) too: in this case they are local to the
current compilation and are inaccessible from outside it. This turns out to be
very convenient, permitting modules to be defined which expose only a few
names to the outside world, while having many names internally, without having
to use the Pop "section" mechanism (roughly equivalent to Lisp packages, but
with a different set of design mistakes).

Pop distinguishes "dynamic" constants (which are dynamic variables with fixed
values) from "lexical" constants; just as with variables, lexical constants
are visible only within a single compilation unit. Although it is possible to
change a dynamic constant (by re-declaring it; of course all existing
references will still get the old constant, so this facility is primarily
useful when re-loading code when a change has been made) a lexical constant
cannot be redefined.

Naturally procedure names may be defined as being in any of the four classes
"vars", "lvars", "constant", or "lconstant"; this is done with the simple
expedient of allowing one of these words to follow the introductory "define"
of the declaration.

A very interesting difference between Lisp's and Pop's treatment of local
declarations of dynamic variables is the way the dyamic variable is rebound
when the binding procedure is entered - it isnt. The variable continues to
have its existing value until an assignment to it is made; the only effect of
the local redefinition is to ensure that its OLD value will be restored on
procedure exit. This turns out to be useful behaviour, eg for locally
incrementing a counter, or locally augmenting a procedure. For example, in a
simple popup menu procedure which paints its picture inside an editor buffer,
I have a declaration rather like

    vars interrupt = restore_the_screen <> interrupt;

"interrupt" is called when an error occurs, and "<>" will compose procedures
as well as append lists (and vectors). This declaration will temporarily
change interrupt so that it will restore the screen before doing whatever it
used to do; note that for this to work it is ESSENTIAL that the old value of
interrupt be available. Another useful definition is

    vars popliblist = my_library :: popliblist;

within a library-searching procedure to augment the library list "popliblist"
with ones own library; again, it is essential that the old value of the
dynamic variable be available. Without this one has to restore to
unwind-protects or double declarations as in

    (let ((old-special-variable special-variable))
        (let ((special-variable expression-involving-old-special-variable))
            bit-that-does-the-work
        )
    )

where the unholy conspiracy between the structure of let-bindings and the
behaviour of dynamic binding leaves a lot to be desired, especially if more
than one special variable is being so modified.

What is the conclusion here? That a sensible and useful meaning can be found
for top-level lexical bindings ("global" bindings in the terms of the paper),
and that a useful alternative definition for local dynamic variable
declarations can be found and is used in an existing language.


A local guru tells me that I can be contacted at

    kers%hplb.csnet@csnet-relay.arpa

which is my address at HPLabs Bristol.

Kers

∂22-Jun-87  0655	samalone@ATHENA.MIT.EDU 	Re: APPLY with 3+ arguments   
Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Jun 87  06:55:17 PDT
Received: by ATHENA.MIT.EDU (5.45/4.7)
	id AA04179; Mon, 22 Jun 87 09:57:07 EDT
From: <samalone@ATHENA.MIT.EDU>
Received: by HADES.MIT.EDU (5.45/4.7) id AA02757; Mon, 22 Jun 87 09:51:48 EDT
Message-Id: <8706221351.AA02757@HADES.MIT.EDU>
To: common-lisp@sail.stanford.edu
Subject: Re: APPLY with 3+ arguments 
Date: Mon, 22 Jun 87 09:51:46 EDT


	Can anyone provide a motivation for the CLtL definition of
	APPLY when more than one arglist is provided?  I understand
	what it does perfectly well, but I don't understand when I am
	going to have a use for this. 

Another use is to write functions like the following:

(defun simplify (new old sequence &rest keyword-args)
  (apply #'remove-duplicates
    (apply #'substitute new old sequence :count 1 keyword-args)
    keyword-args))

If APPLY took only two arguments it would be necessary for this function to
either take explicit keywords itself or splice the :count keyword/value pair
into the argument list for SUBSTITUTE manually.  (BTW: Adding keyword arguments
in this way is well-defined -- see pg. 62 of CLtL.)

				--Stuart A. Malone

∂22-Jun-87  0741	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	APPLY with 3+ arguments  
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 22 Jun 87  07:40:58 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 98345; Mon 22-Jun-87 10:15:32 EDT
Date: Mon, 22 Jun 87 10:14 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: APPLY with 3+ arguments
To: Richard Fritzson <fritzson@bigburd.PRC.Unisys.COM>, common-lisp@sail.stanford.edu
In-Reply-To: <8706221121.AA16283@bigburd.PRC.Unisys.COM>
Message-ID: <870622101406.6.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

    Date: 22 Jun 87 07:19 EDT (Monday)
    From: Richard Fritzson <fritzson@bigburd.PRC.Unisys.COM>

    Can anyone provide a motivation for the CLtL definition of APPLY when
    more than one arglist is provided? I understand what it does perfectly
    well, but I don't understand when I am going to have a use for this.

There are two common uses I have seen.  One is to have a function take
an &REST arg which is the arguments for some other function, yet the
middle-man wants to supply additional keywords or override them, such as
	(defun make-raster-bit-array (width height &rest other-make-array-args)
	  (apply #'make-array (list height width) :element-type 'bit
		 other-make-array-args))

The other common case is similar, but is used to supply required
and optional arguments to a function which also takes an &REST arg, for
example, 
	(defun trace-format (format-string &rest format-args)
	  (apply #'format *trace-output* format-string format-args))

∂22-Jun-87  0959	barmar@Think.COM 	I Like a Single Namespace  
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 22 Jun 87  09:59:25 PDT
Received: from occam by Think.COM via CHAOS; Mon, 22 Jun 87 13:01:49 EDT
Date: Mon, 22 Jun 87 12:59 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: I Like a Single Namespace
To: Christopher Dollin <kers%hplb.csnet@relay.cs.net>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <25156.8706221353@hplb.lb.hp.co.uk>
Message-Id: <870622125923.6.BARMAR@OCCAM.THINK.COM>

    Date: Mon, 22 Jun 87 13:53:15 GMT
    From: Christopher Dollin <kers%hplb.csnet@relay.cs.net>

    Issues in Function and Value Cells
    ------ -- -------- --- ----- -----

    [...]
    Without this one has to restore to
    unwind-protects or double declarations as in

	(let ((old-special-variable special-variable))
	    (let ((special-variable expression-involving-old-special-variable))
		bit-that-does-the-work
	    )
	)

    where the unholy conspiracy between the structure of let-bindings and the
    behaviour of dynamic binding leaves a lot to be desired, especially if more
    than one special variable is being so modified.

The above is not necessary in any Maclisp-descended Lisp I'm familiar
with.

	(let ((*special-var* *special-var*))
	  bit-that-does-the-work)

works fine (and is used quite often) in Maclisp, Zetalisp, and Common
Lisp.  The expressions in a LET value form are evaluated in the dynamic
environment OUTSIDE the LET.  You may be confusing this with the fact
that declarations at the beginning of a LET body refer to variables in
the value forms; this means that you can't do

	(let ((*special-var* *special-var*))
	  (declare (unspecial *special-var*))
	  bit-that-does-the-work)

and have the lexical *SPECIAL-VAR* get initialized from the dynamic
*SPECIAL-VAR*.

						barmar

∂22-Jun-87  1359	Daniels.pa@Xerox.COM 	Re: APPLY with 3+ arguments 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Jun 87  13:59:47 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 JUN 87 12:10:23 PDT
Date: 22 Jun 87 12:09 PDT
From: Daniels.pa@Xerox.COM
Subject: Re: APPLY with 3+ arguments
In-reply-to: Richard Fritzson <fritzson@bigburd.PRC.Unisys.COM>'s
 message of 22 Jun 87 07:19 EDT (Monday)
To: fritzson@bigburd.PRC.Unisys.COM
cc: common-lisp@sail.stanford.edu
Message-ID: <870622-121023-1188@Xerox>

Perhaps you're a little confused about how APPLY with more than 2 args
works. Only the last argument passed to APPLY is an arglist. The rest
are individual arguments to the applied function. As CLtL says, "it is
as if all the arguments to apply execpt the function were given to LIST*
to create the argumentlist."

Thus (APPLY #'LIST '(1 2) '(3 4)) => ((1 2) 3 4), not (1 2 3 4). Page
108 of CLtL and the other replies to your message give reasonable
examples of what you can use this for.

		-- Andy. --

∂22-Jun-87  1457	Daniels.pa@Xerox.COM 	Re: APPLY with 3+ arguments 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Jun 87  13:59:47 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 JUN 87 12:10:23 PDT
Date: 22 Jun 87 12:09 PDT
From: Daniels.pa@Xerox.COM
Subject: Re: APPLY with 3+ arguments
In-reply-to: Richard Fritzson <fritzson@bigburd.PRC.Unisys.COM>'s
 message of 22 Jun 87 07:19 EDT (Monday)
To: fritzson@bigburd.PRC.Unisys.COM
cc: common-lisp@sail.stanford.edu
Message-ID: <870622-121023-1188@Xerox>

Perhaps you're a little confused about how APPLY with more than 2 args
works. Only the last argument passed to APPLY is an arglist. The rest
are individual arguments to the applied function. As CLtL says, "it is
as if all the arguments to apply execpt the function were given to LIST*
to create the argumentlist."

Thus (APPLY #'LIST '(1 2) '(3 4)) => ((1 2) 3 4), not (1 2 3 4). Page
108 of CLtL and the other replies to your message give reasonable
examples of what you can use this for.

		-- Andy. --

∂23-Jun-87  0252	@RELAY.CS.NET:kers@HPLB.CSNET 
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 23 Jun 87  02:52:14 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa22002; 23 Jun 87 4:19 EDT
Received: from hplb by RELAY.CS.NET id ab04330; 23 Jun 87 4:11 EDT
From: Christopher Dollin <kers%hplb.csnet@RELAY.CS.NET>
Date: Tue, 23 Jun 87 08:22:01 GMT
Message-Id: <1977.8706230822@hplb.lb.hp.co.uk>
To: common-lisp@SAIL.STANFORD.EDU


Oops!

Yes, I guess I slipped. Using LET* will cover the case of multiple
bindings, too. Must have been a bad day ... can't even blame jet-lag ...

Regards,
Kers

(Using KMail 10-Apr-87 (Kers))

∂23-Jun-87  0654	CL.BOYER@R20.UTEXAS.EDU 	Kyoto Common Lisp   
Received: from R20.UTEXAS.EDU by SAIL.STANFORD.EDU with TCP; 23 Jun 87  06:54:29 PDT
Date: Mon 22 Jun 87 20:24:22-CDT
From: CL.BOYER@R20.UTEXAS.EDU
Subject: Kyoto Common Lisp
To: ailist@STRIPE.SRI.COM, common-lisp@SAIL.STANFORD.EDU,
    arpanet-bboards@MC.LCS.MIT.EDU
Message-ID: <12312656894.9.CL.BOYER@R20.UTEXAS.EDU>

Kyoto Common Lisp (KCL) is a complete implementation of Common Lisp written
by T. Yuasa and M. Hagiya working under Professor R. Nakajima at the
Research Institute for Mathematical Sciences, Kyoto University.  It runs on
many different machines and is highly portable.  It executes very
efficiently and it is superbly documented.  KCL is being made available at
no fee through the implementors' generosity.  The complete sources are
included.  One channel of distribution is via ftp on the Arpanet/Internet.

                               LICENSE REQUIRED!

IMPORTANT: Although there is no fee, KCL is not in the public domain.  You
are authorized to obtain it only after signing and mailing in a license
agreement.  Before you ftp KCL files you MUST fill out and send in the
license agreement included in this message.  Otherwise, you are not
permitted to make copies of KCL.

                           COPYING KCL VIA INTERNET

KCL may be obtained from Internet source rascal.ics.utexas.edu [128.83.144.1],
a Sun-3 at the University of Texas at Austin.  To obtain KCL, login as "ftp"
with password "guest".  There are three tar files:

   /pub/kcl.tar, 4.0 megabytes
   /pub/kcl.tar.C, produced by compact from kcl.tar, 2.8 megabytes
   /pub/kcl.tar.Z, produced by compress from kcl.tar, 1.2 megabytes

Any of the three files is sufficient to generate KCL.  Please ftp the
compressed file if possible.  Please use ftp at an odd hour if possible to
reduce traffic on a sometimes heavily loaded network.  Be sure to use binary
mode with ftp.  A current version of this message may be found as the file
/pub/kcl.broadcast.

                          MACHINES ON WHICH KCL RUNS

KCL runs on many machines.  With the sources provided in the ftp file, KCL
may be executed on the following machines (and operating systems).

	VAX/UNIX (4.2BSD)
	SUN2 (OS2, 3) SUN3 (OS3)
	SONY'S NEWS (4.2BSD)
	ATT3B2 (System V)
	Fujitu S3000 (System V)
	Sumitomo's E15 (Uniplus System V)
	Data General MV (DGUX)

Instructions for making the system are in the file doc/porting in the ftp
tar file.

                               KCL LICENSE FORM

To obtain the right to copy KCL, sign this license form and send it and a copy
to the Kyoto address at the end of the form.  ONCE YOU HAVE MAILED THE SIGNED
LICENSE FORM, YOU MAY COPY KCL.  YOU DO NOT HAVE TO WAIT FOR RECEIPT OF THE
SIGNED FORM.
--------------------------- cut here ----------------------------
!

                               LICENSE AGREEMENT
                                      FOR
                               KYOTO COMMON LISP

The Special Interest Group in LISP (Taiichi Yuasa and Masami Hagiya) at the
Research Institute for Mathematical Sciences, Kyoto University (hereinafter
referred to as SIGLISP) grants to

USER NAME: _________________________________________

USER ADDRESS: ______________________________________
              ______________________________________

(hereinafter referred to as USER), a non-transferable and non-exclusive license
to copy and use Kyoto Common LISP (hereinafter referred to as KCL) under the
following terms and conditions and for the period of time identified in
Paragraph 6.

1.  This license agreement grants to the USER the right to use KCL within their
own home or organization.  The USER may make copies of KCL for use within their
own home or organization, but may not further distribute KCL except as provided
in paragraph 2.

2.  SIGLISP intends that KCL be widely distributed and used, but in a
manner which preserves the quality and integrity of KCL.  The USER may send
a copy of KCL to another home or organization only after either receiving
permission from SIGLISP or after seeing written evidence that the other
home or organization has signed this agreement and sent a hard copy of it
to SIGLISP.  If the USER has made modifications to KCL and wants to
distribute that modified copy, the USER will first obtain permission from
SIGLISP by written or electronic communication.  Any USER which has
received such a modified copy can pass it on as received, but must receive
further permission for further modifications.  All modifications to copies
of KCL passed on to other homes or organizations shall be clearly and
conspicuously indicated in all such copies.  Under no other circumstances
than provided in this paragraph shall a modified copy of KCL be represented
as KCL.

3.  The USER will ensure that all their copies of KCL, whether modified or not,
carry as the first information item the following copyright notice:

(c) Copyright Taiichi Yuasa and Masami Hagiya, 1984.  All rights reserved.
Copying of this file is authorized to users who have executed the true and
proper "License Agreement for Kyoto Common LISP" with SIGLISP.

4.  Title to and ownership of KCL and its copies shall at all times remain
with SIGLISP and those admitted by SIGLISP as contributors to the
development of KCL.  The USER will return to SIGLISP for further
distribution modifications to KCL, modifications being understood to mean
changes which increase the speed, reliability and existing functionality of
the software delivered to the USER.  The USER may make for their own
ownership and use enhancements to KCL which add new functionality and
applications which employ KCL.  Such modules may be returned to SIGLISP at
the option of the USER.

5.  KCL IS LICENSED WITH NO WARRANTY OF ANY KIND.  SIGLISP WILL NOT BE
RESPONSIBLE FOR THE CORRECTION OF ANY BUGS OR OTHER DEFICIENCIES.  IN NO
EVENT SHALL SIGLISP BE LIABLE FOR ANY DAMAGES OF ANY KIND, INCLUDING
SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, ARISING OUT OF OR IN CONNECTION
WITH THE USE OR PERFORMANCE OF KCL.

6.  This license for KCL shall be effective from the date hereof and shall
remain in force until the USER discontinues use of KCL.  In the event the USER
neglects or fails to perform or observe any obligations under this Agreement,
this Agreement and the License granted hereunder shall be immediately
terminated and the USER shall certify to SIGLISP in writing that all copies of
KCL in whatever form in its possession or under its control have been
destroyed.

7.  Requests.  KCL is provided by SIGLISP in a spirit of friendship and
cooperation.  SIGLISP asks that people enjoying the use of KCL cooperate in
return to help further develop and distribute KCL.  Specifically, SIGLISP
would like to know which machines KCL gets used on.  A brief notice form is
appended to this agreement which the user is requested to send by email or
otherwise.  Please send in further notifications at reasonable intervals if
you increase the number and type of machines on which KCL is loaded.  You
may send these notices to another USER which is cooperating with SIGLISP
for this purpose.

USER

  DATE:  _________________________________________

  BY:  ___________________________________________

  TITLE:  ________________________________________

  ADDRESS:  ______________________________________
            ______________________________________


SIGLISP

  DATE:  _________________________________________

  BY:  ___________________________________________
       Taiichi Yuasa			Masami Hagiya
       Special Interest Group in LISP
       Research Institute for Mathematical Sciences
       Kyoto University
       Kyoto, 606,  JAPAN
       Telex:  05422020 RIMS J
       JUNET:  siglisp@kurims.kurims.kyoto-u.junet
       CSNET:  siglisp%kurims.kurims.kyoto-u.junet@utokyo-relay.csnet



USER has loaded KCL on the following machines since (date):

Model Number     Production Name       Number of Machines




!

                    END OF LICENSE FORM
--------------------------- cut here ------------------------

                                 DOCUMENTATION

The principal documentation for KCL is, of course, the book "Common Lisp
The Language" by Guy L. Steele, Jr. with contributions by Scott E. Fahlman,
Richard P. Gabriel, David A. Moon, and Daniel L. Weinreb, Digital Press,
1984.  Implementation-specific details of KCL (debugging, garbage
collection, data structure format, declarations, operating system
interface, installation) may be found in the 131 page "Kyoto Common Lisp
Report" by Taiichi Yuasa and Masami Hagiya, the authors of KCL.  This
report is available from:

	Teikoku Insatsu Inc.
	Shochiku-cho,
	Ryogae-cho-dori Takeya-machi Sagaru,
	Naka-gyo-ku,
	Kyoto, 604, Japan
	tel: 075-231-4757

for 5,000 yen plus postage.

The KCL Report is produced by the text-formatter KROFF (Kyoto ROFF), which
is used locally within Kyoto University.  Currently KROFF works only on
printers available in Japan.  It is possible that an American
distributorship of this report will be arranged.  The source of the report,
with KROFF commands, is found in the file doc/report on the ftp tar file.
It is possible to read this source, though it is as hard on the eyes as TeX
or Scribe source.  A translation of this source into TeX is underway and
will be available as part of the distribution tape.  Future information
about the availability of the KCL Report will be available in updated
versions of this message, in the file /pub/kcl.broadcast.

A document describing how to port KCL to other systems is available at no
charge from the authors of KCL.

Each of the KCL primitives is thoroughly described by the "describe"
function, which is based on 340K bytes of documentation.

                                    SUPPORT

KCL is one of the most bug-free large software systems that we have ever used.
However, when bugs are found, they may be reported to the implementors:

  hagiya%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET
  yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET

We have found them extremely responsive to bug reports and suggestions.

                               SAMPLE TRANSCRIPT

Below is a complete transcript for obtaining and installing KCL on a Sun-3.

        Make a directory for locating KCL

tutorial% mkdir /usr/joe/kcl

        Get the compressed tar file

tutorial% cd /usr/joe/kcl
tutorial% ftp 128.83.144.1
220 rascal FTP server (Version 4.7 Sun Sep 14 12:44:57 PDT 1986) ready.
Name: ftp
Password: guest
ftp>binary
ftp>get /pub/kcl.tar.Z kcl.tar.Z
ftp>quit

        Build the KCL directory structure

tutorial% uncompress kcl.tar.Z
tutorial% tar -xvf kcl.tar .
tutorial% rm kcl.tar

        Make KCL

tutorial% cd /usr/joe/kcl/
tutorial% su
password: super-user-password
tutorial# cp  h/cmpinclude.h /usr/include
tutorial# exit
tutorial% make

        Edit and Install Two Files 

We wish to replace "~" by "/usr/joe" in lc and kcl, and put
them in a directory on the search path e.g. "/usr/joe/bin"

tutorial% cd /usr/joe/kcl/unixport
tutorial% mkdir /usr/joe/bin
tutorial% sed -e "s.~./usr/joe/kcl.g" lc >  /usr/joe/bin/lc
tutorial% sed -e "s.~./usr/joe/kcl.g" kcl > /usr/joe/bin/kcl
tutorial% chmod a+x   /usr/joe/bin/lc /usr/joe/bin/kcl

It is now possible to run kcl:

tutorial% /usr/joe/bin/kcl
KCL (Kyoto Common Lisp)

>(+ 2 3)
5
>(bye)

It is best to become super user and execute the following commands, so that all
users may execute kcl.

tutorial% su
Password: superuser-password
tutorial# cp  /usr/joe/bin/kcl /usr/local/bin
tutorial# cp  /usr/joe/bin/lc  /usr/local/bin
tutorial# exit

This transcript puts the entire kcl system, including sources and
documentation, in the directory /usr/joe/kcl.  Any other directory name
would do as well, e.g., /usr/local instead of /usr/joe.  Although this
transcript has worked perfectly for us on a Sun-3, it might not work for
you if you are running under NFS but not logged into the right machine:
you may need to login as root on the system where /usr/include and
/usr/local/bin are really located to do the super-user things.  Immediately
after the make is finished about 8.4 megatyes of disk space are in use.


                                SINCERELY YOURS

     Robert S. Boyer            William F. Schelter
     cl.boyer@r20.utexas.edu    atp.schelter@r20.utexas.edu

This message was written by Robert S. Boyer and William F. Schelter.  The
opinions expressed are theirs and are not necessarily those of the authors of
KCL, the University of Texas, or MCC.  The authors of KCL have, however,
indicated that they have no objection to our distributing this message.

P.S. Thanks to Dave Capshaw, George Fann, Warren Hunt, Ken Rimey, and Carl
Quillen for helping debug this message.  Ken Rimey,
rimey@ernie.Berkeley.EDU, makes the following remarks about bringing up
this release of KCL under BSD 4.3 on a Vax.

1.  Bringing up KCL under BSD4.3.  The machine on which I installed kcl was
a Vax 88xx running Ultrix V2.0.  Kcl crashed when executing the final
save-system command in init_kcl.lsp.  It also did so on a Vax running
BSD4.3.  (I don't know of any Vaxen still running 4.2.)  The problem is
caused by some highly non-portable code introduced into Lsave() in
c/unixsave.c since the version of March 28, 1986.  I deleted the new code
and reintroduced the old which had been commented out.  Here is the
resulting working Lsave():

Lsave()
{
	char filename[256];

	check_arg(1);
	check_type_or_pathname_string_symbol_stream(&vs_base[0]);
	coerce_to_filename(vs_base[0], filename);

	_cleanup();
	memory_save(kcl_self, filename);
	exit(0);
	/*  no return  */
}

KCL ran successfully after only fixing the Lsave problem.

2. The files o/makefile and unixport/makefile define variables that need to be
changed when compiling for any machine other than a Sun-3.  These definitions
are found at the heads of these files.  Here is the head of my copy of
o/makefile:

	MACHINE = VAX
	#	Select 'VAX', 'SUN', 'SUN2R3', 'SUN3', 'ISI', 'SEQ', 'IBMRT',
	#	or 'NEWS'.

	CHTAB	= char_table.s
	#	Select 'char_table.s' or 'sun_chtab.s'.
	#	1) char_table.s : for VAX, SEQ and NEWS
	#	2) sun_chtab.s  : for SUN, SUN2R3 and SUN3
	#	3) isi_chtab.s  : for ISI
	#	4) ibmrt_chtab.s: for IBMRT

For machines other than Sun-3, one might change the MAKE KCL
section of this message to:

tutorial% cd /usr/joe/kcl/
tutorial% vi o/makefile	  (If not Sun-3, change definitions MACHINE and CHTAB.)
tutorial% vi o/unixport	  (If not Sun-3, change definition of MACHINE.)
tutorial% su
password: super-user-password
tutorial# cp  h/cmpinclude.h /usr/include
tutorial# exit
tutorial% make

-------

∂23-Jun-87  1535	BAGGINS@IBM.COM 	A multi-byte character extension proposal  
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 23 Jun 87  15:34:22 PDT
Date: Tue, 23 Jun 87 12:54:31 PDT
From: "Thomas Linden (Thom)" <baggins@ibm.com>
To: "Dr. Masayuki Ida"
 <a37078%tansei.u-tokyo.junet%utokyo-relay.csnet@relay.cs.net>, Common
 Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <870623.125431.baggins@IBM.com>
Subject: A multi-byte character extension proposal

Professor Ida:



  We have had the opportunity to review the
English translation of part of the JEIDA proposal
regarding the extension of Common Lisp to large
(multi-byte) character sets.  We were impressed with the scope of the
issues addressed.  However, the translation was vague on a few points,
and we would like clarification.  Your anwsers to the following
questions would be appreciated:


 1)

The paper proposes that Lisp characters be assigned unique codes over
a potentially large domain (possibly all the integers between 0 and
65535).  Are characters with different codes always syntactically
distinct?  Can the standard character #\( have two different codes,
corresponding, for example, to two different external file system
representations of that character?  If so, would the Lisp reader
always parse these two representations identically?


 2)

CLtL says, (p. 233) "The code attribute is intended to distinguish
among the printed glyphs and formatting functions for characters."
Does the JEIDA proposal permit two different string-chars to have
the same print glyph, '(' for example, but different syntactical
properties?


 3)

Under the proposal, it is up to each implementation how it
chooses to translate the contents of files or terminal input when
passed as input to the Lisp system.  We have both single-byte and
double-byte character conventions for file contents; thus is it
allowable to map both of these sets of codes into the one,
internal Lisp character code set when inputting data to Lisp, and
adopt our own conventions for translating output back to single
and double byte?


 4)

An elaboration of the the previous question: Is it possible for an
implementation to represent all of the standard characters internally
with 2-byte codes, and to map some 2-byte character codes and some
1-byte character codes in system files onto the same set of 2-byte
internal codes for the standard characters when read into Lisp?



 5)

The English copy we saw of the proposal did not contain section 4.4.
Based on our own translation from the original in Japanese, this
section seems to discuss implementation issues.  Given a system such
as our's, which has both single-byte and double-byte conventions for
some characters, including the Common Lisp standard characters, there
seem to be two possible treatments of double byte characters.  The
first is the case where a double-byte character can be a standard
character.  The second is where a double-byte character cannot be
a standard character.


 5a)

Is the proposal's default, in section 4.4, that a Lisp
implementation reading a file on a system with both single-byte
and double-byte conventions, not recognize any double-byte character
in that file as a standard character?

 5b)

There are three example Lisp forms with underlining which seem
to indicate three options of single-byte/double-byte equivalency.
Consider the symbol 'abc' in these forms.  Is the difference
between option 1 and option 2 whether the Lisp system would
recognize a single-byte version and a double-byte version
of this symbol-name in the same file as referring to the same
(EQ) symbol?

          1.  (list    abc    /fg   " xy " )
             --------------------------------
          2.  (list    abc    /fg   " xy " )
             --    ----   -----   ---    ----
          3.  (list    abc    /fg   " xy " )
             ------------------------   -----

 5c)

If a Lisp system does not recognize these two symbol names
as equivalent, doesn't that require the Lisp system to have
two characters with different codes but the same print glyph?

 5d)

Under the default proposal, if the character object print
syntax "#\a" or "#\A" is read from a file, is alpha-char-p true

          1. if the 'a' had been encoded as a single byte?
          2. if the 'a' had been encoded as a double byte?
          3. if the 'A' had been encoded as a single byte?
          4. if the 'A' had been encoded as a double byte?

 5e)

Is section 4.4 a part of the proposal to ANSI, or
has it been included for merely illustrative purposes?

If you could elaborate (in English) on the content of section
4.4, we would greatly appreciate it.


 6)

Even if the Lisp system supports a large character set, only
standard characters have, as a default, non-constituent syntax
type, constituent character attributes relevant to parsing of numbers
and symbols, or defined syntax within a format control string.
Correct?


 7)

If a Lisp system supports a large character code set, need it allow
every character of type string-char to have a non-constituent syntax
type defined in the readtable, or is the proposal's default that
only standard characters need be represented in the readtable?


 8)

A specific case related to the previous question: suppose #\% were a
non-standard character, but still a string-char in some implementation
of Lisp.  Is

           (make-dispatch-macro-character #\%)

necessarily permitted in every implementation that supports #\% as a
string-char?


Regards,
  Thom Linden

∂25-Jun-87  0923	@RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET 	Re:  A multi-byte character extension proposal    
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Jun 87  09:22:18 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac04243; 25 Jun 87 11:10 EDT
Received: from utokyo-relay by RELAY.CS.NET id aa19616; 25 Jun 87 11:04 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
	id AA24561; Thu, 25 Jun 87 23:49:44 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
	id AA15608; Thu, 25 Jun 87 23:48:59+0900
Date: Thu, 25 Jun 87 23:48:59+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8706251448.AA15608@tansei.cc.u-tokyo.junet>
To: baggins@ibm.com, 
    ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Subject: Re:  A multi-byte character extension proposal
Cc: common-lisp@SAIL.STANFORD.EDU


	Date: Tue, 23 Jun 87 12:54:31 PDT
	From: "Thomas Linden (Thom)" <baggins@ibm.com>
	
	
	 1)
	
	        Are characters with different codes always syntactically
	distinct?
Yes.
	           Can the standard character #\( have two different codes,
	corresponding, for example, to two different external file system
	representations of that character?  
No.
(because you said 'the standard character'...)
We cannot talk about the different representations on files.
Some implementations may read 'similar' characters into one internal
code, but others may not.
	
	 2)
	
	Does the JEIDA proposal permit two different string-chars to have
	the same print glyph, '(' for example, but different syntactical
	properties?
We did not discuss about the issue related to your question,
because we have no scope on the characters which has the same print glyph but
different syntactical properties.
There are several japanese characters which have similar glyphs.
But their glyphs are not 'the same' (except for blank characters).
	
	
	 3)
	
			Is it
	allowable to map both of these sets of codes into the one,
	internal Lisp character code set when inputting data to Lisp, and
	adopt our own conventions for translating output back to single
	and double byte?
yes.
	
	
	 4)
	
	An elaboration of the the previous question: Is it possible for an
	implementation to represent all of the standard characters internally
	with 2-byte codes, and to map some 2-byte character codes and some
	1-byte character codes in system files onto the same set of 2-byte
	internal codes for the standard characters when read into Lisp?
yes.
	
	
	
	 5)
	
	The English copy we saw of the proposal did not contain section 4.4.
	Based on our own translation from the original in Japanese, this
	section seems to discuss implementation issues. 
Since we could not make a good conclusion on the issue,
the section 4.4 of the early draft injapanese was deleted.
The proposal have many freedom for implementors.
					there
	seem to be two possible treatments of double byte characters.  The
	first is the case where a double-byte character can be a standard
	character.  The second is where a double-byte character cannot be
	a standard character.
I think so too.
	
	
	 5a)
	
	
Implementation dependent.

	 5b)
	
						Is the difference
	between option 1 and option 2 whether the Lisp system would
	recognize a single-byte version and a double-byte version
	of this symbol-name in the same file as referring to the same
	(EQ) symbol?
Yes.
	
	          1.  (list    abc    /fg   " xy " )
	             --------------------------------
	          2.  (list    abc    /fg   " xy " )
	             --    ----   -----   ---    ----
	          3.  (list    abc    /fg   " xy " )
	             ------------------------   -----
We tried to select one and only one selection among the above 3 'options'.
But we found we cannot make decision until ISO related standardization
of japanese character representation.
	
	 5c)
I cannot understand what you said.
I don't imagine the status like "there is a character which has a same print glyph but different code."
	
	
	 5d)
Implementation dependent.
Standard-character may be single-byte or may be multi-byte,
according to the definition of the implementation.
	
	 5e)
	
	Is section 4.4 a part of the proposal to ANSI? 
No.
	
	If you could elaborate (in English) on the content of section
	4.4, we would greatly appreciate it.
Please ask IBM  japan (your subsidiary) for the complex issue
behind the section 4.4 of the early draft in japanese.
We need more observations on other languages, file systems,
operating systems and JIS character set definition refinement
itself before we might make a firm guideline for the matter.
	
	
	 6)
	
	Correct?
Your interpretation can cope with our proposal.
	
	
	 7)
	
	If a Lisp system supports a large character code set, need it allow
	every character of type string-char to have a non-constituent syntax
	type defined in the readtable, or is the proposal's default that
	only standard characters need be represented in the readtable?
	
CLtL says (22.1.5 page  360):
"every character of type string-char must be represented in the readtable."
The members felt as we extended the definition of string-char to include
japanese characters, as the results of a natual interpretation of CLtL,
the readtable must have more than 64k 'logical' entries.
	
	
	Regards,
	  Thom Linden
	
Masayuki Ida

PS: our proposal is the result of several japanese and USA CL implementations.
Though we will welcome any opinions to our proposal, I feel
the final decision will be by ANSI, JIS, and ISO.
One of the members of our WG will attend the X3J13 meeting, since
I cannot leave my university on the next week.
He is a very active members and he knows the process.
He is scheduled to have a presentation on this issue at the X3J13 meeting.

∂25-Jun-87  1028	@RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET 	Re:  A multi-byte character extension proposal    
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Jun 87  09:22:18 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac04243; 25 Jun 87 11:10 EDT
Received: from utokyo-relay by RELAY.CS.NET id aa19616; 25 Jun 87 11:04 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
	id AA24561; Thu, 25 Jun 87 23:49:44 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
	id AA15608; Thu, 25 Jun 87 23:48:59+0900
Date: Thu, 25 Jun 87 23:48:59+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8706251448.AA15608@tansei.cc.u-tokyo.junet>
To: baggins@ibm.com, 
    ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Subject: Re:  A multi-byte character extension proposal
Cc: common-lisp@SAIL.STANFORD.EDU


	Date: Tue, 23 Jun 87 12:54:31 PDT
	From: "Thomas Linden (Thom)" <baggins@ibm.com>
	
	
	 1)
	
	        Are characters with different codes always syntactically
	distinct?
Yes.
	           Can the standard character #\( have two different codes,
	corresponding, for example, to two different external file system
	representations of that character?  
No.
(because you said 'the standard character'...)
We cannot talk about the different representations on files.
Some implementations may read 'similar' characters into one internal
code, but others may not.
	
	 2)
	
	Does the JEIDA proposal permit two different string-chars to have
	the same print glyph, '(' for example, but different syntactical
	properties?
We did not discuss about the issue related to your question,
because we have no scope on the characters which has the same print glyph but
different syntactical properties.
There are several japanese characters which have similar glyphs.
But their glyphs are not 'the same' (except for blank characters).
	
	
	 3)
	
			Is it
	allowable to map both of these sets of codes into the one,
	internal Lisp character code set when inputting data to Lisp, and
	adopt our own conventions for translating output back to single
	and double byte?
yes.
	
	
	 4)
	
	An elaboration of the the previous question: Is it possible for an
	implementation to represent all of the standard characters internally
	with 2-byte codes, and to map some 2-byte character codes and some
	1-byte character codes in system files onto the same set of 2-byte
	internal codes for the standard characters when read into Lisp?
yes.
	
	
	
	 5)
	
	The English copy we saw of the proposal did not contain section 4.4.
	Based on our own translation from the original in Japanese, this
	section seems to discuss implementation issues. 
Since we could not make a good conclusion on the issue,
the section 4.4 of the early draft injapanese was deleted.
The proposal have many freedom for implementors.
					there
	seem to be two possible treatments of double byte characters.  The
	first is the case where a double-byte character can be a standard
	character.  The second is where a double-byte character cannot be
	a standard character.
I think so too.
	
	
	 5a)
	
	
Implementation dependent.

	 5b)
	
						Is the difference
	between option 1 and option 2 whether the Lisp system would
	recognize a single-byte version and a double-byte version
	of this symbol-name in the same file as referring to the same
	(EQ) symbol?
Yes.
	
	          1.  (list    abc    /fg   " xy " )
	             --------------------------------
	          2.  (list    abc    /fg   " xy " )
	             --    ----   -----   ---    ----
	          3.  (list    abc    /fg   " xy " )
	             ------------------------   -----
We tried to select one and only one selection among the above 3 'options'.
But we found we cannot make decision until ISO related standardization
of japanese character representation.
	
	 5c)
I cannot understand what you said.
I don't imagine the status like "there is a character which has a same print glyph but different code."
	
	
	 5d)
Implementation dependent.
Standard-character may be single-byte or may be multi-byte,
according to the definition of the implementation.
	
	 5e)
	
	Is section 4.4 a part of the proposal to ANSI? 
No.
	
	If you could elaborate (in English) on the content of section
	4.4, we would greatly appreciate it.
Please ask IBM  japan (your subsidiary) for the complex issue
behind the section 4.4 of the early draft in japanese.
We need more observations on other languages, file systems,
operating systems and JIS character set definition refinement
itself before we might make a firm guideline for the matter.
	
	
	 6)
	
	Correct?
Your interpretation can cope with our proposal.
	
	
	 7)
	
	If a Lisp system supports a large character code set, need it allow
	every character of type string-char to have a non-constituent syntax
	type defined in the readtable, or is the proposal's default that
	only standard characters need be represented in the readtable?
	
CLtL says (22.1.5 page  360):
"every character of type string-char must be represented in the readtable."
The members felt as we extended the definition of string-char to include
japanese characters, as the results of a natual interpretation of CLtL,
the readtable must have more than 64k 'logical' entries.
	
	
	Regards,
	  Thom Linden
	
Masayuki Ida

PS: our proposal is the result of several japanese and USA CL implementations.
Though we will welcome any opinions to our proposal, I feel
the final decision will be by ANSI, JIS, and ISO.
One of the members of our WG will attend the X3J13 meeting, since
I cannot leave my university on the next week.
He is a very active members and he knows the process.
He is scheduled to have a presentation on this issue at the X3J13 meeting.

∂25-Jun-87  1143	@RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET 	Re:  A multi-byte character extension proposal    
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Jun 87  09:22:18 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac04243; 25 Jun 87 11:10 EDT
Received: from utokyo-relay by RELAY.CS.NET id aa19616; 25 Jun 87 11:04 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
	id AA24561; Thu, 25 Jun 87 23:49:44 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
	id AA15608; Thu, 25 Jun 87 23:48:59+0900
Date: Thu, 25 Jun 87 23:48:59+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8706251448.AA15608@tansei.cc.u-tokyo.junet>
To: baggins@ibm.com, 
    ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Subject: Re:  A multi-byte character extension proposal
Cc: common-lisp@SAIL.STANFORD.EDU


	Date: Tue, 23 Jun 87 12:54:31 PDT
	From: "Thomas Linden (Thom)" <baggins@ibm.com>
	
	
	 1)
	
	        Are characters with different codes always syntactically
	distinct?
Yes.
	           Can the standard character #\( have two different codes,
	corresponding, for example, to two different external file system
	representations of that character?  
No.
(because you said 'the standard character'...)
We cannot talk about the different representations on files.
Some implementations may read 'similar' characters into one internal
code, but others may not.
	
	 2)
	
	Does the JEIDA proposal permit two different string-chars to have
	the same print glyph, '(' for example, but different syntactical
	properties?
We did not discuss about the issue related to your question,
because we have no scope on the characters which has the same print glyph but
different syntactical properties.
There are several japanese characters which have similar glyphs.
But their glyphs are not 'the same' (except for blank characters).
	
	
	 3)
	
			Is it
	allowable to map both of these sets of codes into the one,
	internal Lisp character code set when inputting data to Lisp, and
	adopt our own conventions for translating output back to single
	and double byte?
yes.
	
	
	 4)
	
	An elaboration of the the previous question: Is it possible for an
	implementation to represent all of the standard characters internally
	with 2-byte codes, and to map some 2-byte character codes and some
	1-byte character codes in system files onto the same set of 2-byte
	internal codes for the standard characters when read into Lisp?
yes.
	
	
	
	 5)
	
	The English copy we saw of the proposal did not contain section 4.4.
	Based on our own translation from the original in Japanese, this
	section seems to discuss implementation issues. 
Since we could not make a good conclusion on the issue,
the section 4.4 of the early draft injapanese was deleted.
The proposal have many freedom for implementors.
					there
	seem to be two possible treatments of double byte characters.  The
	first is the case where a double-byte character can be a standard
	character.  The second is where a double-byte character cannot be
	a standard character.
I think so too.
	
	
	 5a)
	
	
Implementation dependent.

	 5b)
	
						Is the difference
	between option 1 and option 2 whether the Lisp system would
	recognize a single-byte version and a double-byte version
	of this symbol-name in the same file as referring to the same
	(EQ) symbol?
Yes.
	
	          1.  (list    abc    /fg   " xy " )
	             --------------------------------
	          2.  (list    abc    /fg   " xy " )
	             --    ----   -----   ---    ----
	          3.  (list    abc    /fg   " xy " )
	             ------------------------   -----
We tried to select one and only one selection among the above 3 'options'.
But we found we cannot make decision until ISO related standardization
of japanese character representation.
	
	 5c)
I cannot understand what you said.
I don't imagine the status like "there is a character which has a same print glyph but different code."
	
	
	 5d)
Implementation dependent.
Standard-character may be single-byte or may be multi-byte,
according to the definition of the implementation.
	
	 5e)
	
	Is section 4.4 a part of the proposal to ANSI? 
No.
	
	If you could elaborate (in English) on the content of section
	4.4, we would greatly appreciate it.
Please ask IBM  japan (your subsidiary) for the complex issue
behind the section 4.4 of the early draft in japanese.
We need more observations on other languages, file systems,
operating systems and JIS character set definition refinement
itself before we might make a firm guideline for the matter.
	
	
	 6)
	
	Correct?
Your interpretation can cope with our proposal.
	
	
	 7)
	
	If a Lisp system supports a large character code set, need it allow
	every character of type string-char to have a non-constituent syntax
	type defined in the readtable, or is the proposal's default that
	only standard characters need be represented in the readtable?
	
CLtL says (22.1.5 page  360):
"every character of type string-char must be represented in the readtable."
The members felt as we extended the definition of string-char to include
japanese characters, as the results of a natual interpretation of CLtL,
the readtable must have more than 64k 'logical' entries.
	
	
	Regards,
	  Thom Linden
	
Masayuki Ida

PS: our proposal is the result of several japanese and USA CL implementations.
Though we will welcome any opinions to our proposal, I feel
the final decision will be by ANSI, JIS, and ISO.
One of the members of our WG will attend the X3J13 meeting, since
I cannot leave my university on the next week.
He is a very active members and he knows the process.
He is scheduled to have a presentation on this issue at the X3J13 meeting.

∂25-Jun-87  1255	@RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET 	Re:  A multi-byte character extension proposal    
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Jun 87  09:22:18 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac04243; 25 Jun 87 11:10 EDT
Received: from utokyo-relay by RELAY.CS.NET id aa19616; 25 Jun 87 11:04 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
	id AA24561; Thu, 25 Jun 87 23:49:44 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
	id AA15608; Thu, 25 Jun 87 23:48:59+0900
Date: Thu, 25 Jun 87 23:48:59+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8706251448.AA15608@tansei.cc.u-tokyo.junet>
To: baggins@ibm.com, 
    ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Subject: Re:  A multi-byte character extension proposal
Cc: common-lisp@SAIL.STANFORD.EDU


	Date: Tue, 23 Jun 87 12:54:31 PDT
	From: "Thomas Linden (Thom)" <baggins@ibm.com>
	
	
	 1)
	
	        Are characters with different codes always syntactically
	distinct?
Yes.
	           Can the standard character #\( have two different codes,
	corresponding, for example, to two different external file system
	representations of that character?  
No.
(because you said 'the standard character'...)
We cannot talk about the different representations on files.
Some implementations may read 'similar' characters into one internal
code, but others may not.
	
	 2)
	
	Does the JEIDA proposal permit two different string-chars to have
	the same print glyph, '(' for example, but different syntactical
	properties?
We did not discuss about the issue related to your question,
because we have no scope on the characters which has the same print glyph but
different syntactical properties.
There are several japanese characters which have similar glyphs.
But their glyphs are not 'the same' (except for blank characters).
	
	
	 3)
	
			Is it
	allowable to map both of these sets of codes into the one,
	internal Lisp character code set when inputting data to Lisp, and
	adopt our own conventions for translating output back to single
	and double byte?
yes.
	
	
	 4)
	
	An elaboration of the the previous question: Is it possible for an
	implementation to represent all of the standard characters internally
	with 2-byte codes, and to map some 2-byte character codes and some
	1-byte character codes in system files onto the same set of 2-byte
	internal codes for the standard characters when read into Lisp?
yes.
	
	
	
	 5)
	
	The English copy we saw of the proposal did not contain section 4.4.
	Based on our own translation from the original in Japanese, this
	section seems to discuss implementation issues. 
Since we could not make a good conclusion on the issue,
the section 4.4 of the early draft injapanese was deleted.
The proposal have many freedom for implementors.
					there
	seem to be two possible treatments of double byte characters.  The
	first is the case where a double-byte character can be a standard
	character.  The second is where a double-byte character cannot be
	a standard character.
I think so too.
	
	
	 5a)
	
	
Implementation dependent.

	 5b)
	
						Is the difference
	between option 1 and option 2 whether the Lisp system would
	recognize a single-byte version and a double-byte version
	of this symbol-name in the same file as referring to the same
	(EQ) symbol?
Yes.
	
	          1.  (list    abc    /fg   " xy " )
	             --------------------------------
	          2.  (list    abc    /fg   " xy " )
	             --    ----   -----   ---    ----
	          3.  (list    abc    /fg   " xy " )
	             ------------------------   -----
We tried to select one and only one selection among the above 3 'options'.
But we found we cannot make decision until ISO related standardization
of japanese character representation.
	
	 5c)
I cannot understand what you said.
I don't imagine the status like "there is a character which has a same print glyph but different code."
	
	
	 5d)
Implementation dependent.
Standard-character may be single-byte or may be multi-byte,
according to the definition of the implementation.
	
	 5e)
	
	Is section 4.4 a part of the proposal to ANSI? 
No.
	
	If you could elaborate (in English) on the content of section
	4.4, we would greatly appreciate it.
Please ask IBM  japan (your subsidiary) for the complex issue
behind the section 4.4 of the early draft in japanese.
We need more observations on other languages, file systems,
operating systems and JIS character set definition refinement
itself before we might make a firm guideline for the matter.
	
	
	 6)
	
	Correct?
Your interpretation can cope with our proposal.
	
	
	 7)
	
	If a Lisp system supports a large character code set, need it allow
	every character of type string-char to have a non-constituent syntax
	type defined in the readtable, or is the proposal's default that
	only standard characters need be represented in the readtable?
	
CLtL says (22.1.5 page  360):
"every character of type string-char must be represented in the readtable."
The members felt as we extended the definition of string-char to include
japanese characters, as the results of a natual interpretation of CLtL,
the readtable must have more than 64k 'logical' entries.
	
	
	Regards,
	  Thom Linden
	
Masayuki Ida

PS: our proposal is the result of several japanese and USA CL implementations.
Though we will welcome any opinions to our proposal, I feel
the final decision will be by ANSI, JIS, and ISO.
One of the members of our WG will attend the X3J13 meeting, since
I cannot leave my university on the next week.
He is a very active members and he knows the process.
He is scheduled to have a presentation on this issue at the X3J13 meeting.

∂25-Jun-87  1505	@RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET 	Re:  A multi-byte character extension proposal    
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Jun 87  09:22:18 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac04243; 25 Jun 87 11:10 EDT
Received: from utokyo-relay by RELAY.CS.NET id aa19616; 25 Jun 87 11:04 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
	id AA24561; Thu, 25 Jun 87 23:49:44 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
	id AA15608; Thu, 25 Jun 87 23:48:59+0900
Date: Thu, 25 Jun 87 23:48:59+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8706251448.AA15608@tansei.cc.u-tokyo.junet>
To: baggins@ibm.com, 
    ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Subject: Re:  A multi-byte character extension proposal
Cc: common-lisp@SAIL.STANFORD.EDU


	Date: Tue, 23 Jun 87 12:54:31 PDT
	From: "Thomas Linden (Thom)" <baggins@ibm.com>
	
	
	 1)
	
	        Are characters with different codes always syntactically
	distinct?
Yes.
	           Can the standard character #\( have two different codes,
	corresponding, for example, to two different external file system
	representations of that character?  
No.
(because you said 'the standard character'...)
We cannot talk about the different representations on files.
Some implementations may read 'similar' characters into one internal
code, but others may not.
	
	 2)
	
	Does the JEIDA proposal permit two different string-chars to have
	the same print glyph, '(' for example, but different syntactical
	properties?
We did not discuss about the issue related to your question,
because we have no scope on the characters which has the same print glyph but
different syntactical properties.
There are several japanese characters which have similar glyphs.
But their glyphs are not 'the same' (except for blank characters).
	
	
	 3)
	
			Is it
	allowable to map both of these sets of codes into the one,
	internal Lisp character code set when inputting data to Lisp, and
	adopt our own conventions for translating output back to single
	and double byte?
yes.
	
	
	 4)
	
	An elaboration of the the previous question: Is it possible for an
	implementation to represent all of the standard characters internally
	with 2-byte codes, and to map some 2-byte character codes and some
	1-byte character codes in system files onto the same set of 2-byte
	internal codes for the standard characters when read into Lisp?
yes.
	
	
	
	 5)
	
	The English copy we saw of the proposal did not contain section 4.4.
	Based on our own translation from the original in Japanese, this
	section seems to discuss implementation issues. 
Since we could not make a good conclusion on the issue,
the section 4.4 of the early draft injapanese was deleted.
The proposal have many freedom for implementors.
					there
	seem to be two possible treatments of double byte characters.  The
	first is the case where a double-byte character can be a standard
	character.  The second is where a double-byte character cannot be
	a standard character.
I think so too.
	
	
	 5a)
	
	
Implementation dependent.

	 5b)
	
						Is the difference
	between option 1 and option 2 whether the Lisp system would
	recognize a single-byte version and a double-byte version
	of this symbol-name in the same file as referring to the same
	(EQ) symbol?
Yes.
	
	          1.  (list    abc    /fg   " xy " )
	             --------------------------------
	          2.  (list    abc    /fg   " xy " )
	             --    ----   -----   ---    ----
	          3.  (list    abc    /fg   " xy " )
	             ------------------------   -----
We tried to select one and only one selection among the above 3 'options'.
But we found we cannot make decision until ISO related standardization
of japanese character representation.
	
	 5c)
I cannot understand what you said.
I don't imagine the status like "there is a character which has a same print glyph but different code."
	
	
	 5d)
Implementation dependent.
Standard-character may be single-byte or may be multi-byte,
according to the definition of the implementation.
	
	 5e)
	
	Is section 4.4 a part of the proposal to ANSI? 
No.
	
	If you could elaborate (in English) on the content of section
	4.4, we would greatly appreciate it.
Please ask IBM  japan (your subsidiary) for the complex issue
behind the section 4.4 of the early draft in japanese.
We need more observations on other languages, file systems,
operating systems and JIS character set definition refinement
itself before we might make a firm guideline for the matter.
	
	
	 6)
	
	Correct?
Your interpretation can cope with our proposal.
	
	
	 7)
	
	If a Lisp system supports a large character code set, need it allow
	every character of type string-char to have a non-constituent syntax
	type defined in the readtable, or is the proposal's default that
	only standard characters need be represented in the readtable?
	
CLtL says (22.1.5 page  360):
"every character of type string-char must be represented in the readtable."
The members felt as we extended the definition of string-char to include
japanese characters, as the results of a natual interpretation of CLtL,
the readtable must have more than 64k 'logical' entries.
	
	
	Regards,
	  Thom Linden
	
Masayuki Ida

PS: our proposal is the result of several japanese and USA CL implementations.
Though we will welcome any opinions to our proposal, I feel
the final decision will be by ANSI, JIS, and ISO.
One of the members of our WG will attend the X3J13 meeting, since
I cannot leave my university on the next week.
He is a very active members and he knows the process.
He is scheduled to have a presentation on this issue at the X3J13 meeting.

∂25-Jun-87  1626	Cassels@STONY-BROOK.SCRC.Symbolics.COM 	Format ~E nit -- language lawyer sought 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 25 Jun 87  16:25:48 PDT
Received: from KRYPTON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 182534; Thu 25-Jun-87 19:10:35 EDT
Date: Thu, 25 Jun 87 19:10 EDT
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Format ~E nit -- language lawyer sought
To: Common-Lisp@SAIL.Stanford.EDU
Message-ID: <870625191023.3.CASSELS@KRYPTON.SCRC.Symbolics.COM>

What should be the result of (format nil "~E" 1.0)?

A. "1.0e+0"
B. "1.0e0"
C. All of the above
D. None of the above

The top of page 393 says, "Next, either a plus or a minus sign is
printed, followed by e digits ... [decimal exponent]"

Later on page 393 we see, "If all of w, d, and e are omitted, then the
effect is ... [like prin1].

Page 366 [presumably where prin1 is defined] doesn't explicitly say that
the plus sign is omitted from the exponent, but all the examples (and
usual practice) indicate that.


The first reference implies that A is correct, the third reference
implies that B is correct.  The second reference implies that A and B
are the same.

∂26-Jun-87  1911	VERACSD@A.ISI.EDU 	MODIFYF    
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 26 Jun 87  19:11:13 PDT
Date: 26 Jun 1987 22:10-EDT
Sender: VERACSD@A.ISI.EDU
Subject: MODIFYF
From: VERACSD@A.ISI.EDU
To: common-lisp@SAIL.STANFORD.EDU
Cc: veracsd@A.ISI.EDU
Message-ID: <[A.ISI.EDU]26-Jun-87 22:10:38.VERACSD>

     Was the following ever considered for Common Lisp?


     After SETF, the most logical and general generalized-variable
function (macro) to have next would clearly seem to be something
I call MODIFYF.

(MODIFYF function place . args)

would be approximately equivalent to

(SETF place (function place . args))

except of course for subforms of place being evaluated only once.


     (There are a couple of issues, such as
1) unless you prefer swapping the order of args in MODIFYF,
   function being evaluated before place)
2) evaluating function and going to (funcall function place . args) instead,
   thus allowing lambdas and suchlike.)


     This is reminiscent of, among other things, the op= statements
of the C language, where op includes +, -, etc.


     Many (if not all) "modify macros" would be easily defined in terms
of it.  E.g.,

(defmacro INCF (place &optional (increment 1))
  (MODIFYF + place increment))


     When called directly in user code, MODIFYF stands in approximately
the same relation to DEFINE-MODIFY-MACRO as LAMBDA-expressions stand to
DEFUN.


Bob Sasseen
veracsd@a.isi.edu

∂26-Jun-87  2250	@RELAY.CS.NET:CORK@cs.umass.edu 	Tracing locally defined functions    
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 26 Jun 87  22:50:12 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ag10427; 27 Jun 87 1:39 EDT
Received: from cs.umass.edu by RELAY.CS.NET id bf00359; 27 Jun 87 1:33 EDT
Date: Fri, 26 Jun 87 16:18 EDT
From: "Dan Corkill A356 LGRC (413)545-0156" <CORK%cs.umass.edu@RELAY.CS.NET>
Subject: Tracing locally defined functions
To: Common-Lisp@SAIL.STANFORD.EDU
X-VMS-To: IN%"Common-Lisp@SAIL.STANFORD.EDU",CORK

This is a plea for Common Lisp implementers to augment their TRACE utility to
handle functions defined using FLET and (especially!) LABELS.  For example,
here is a recursive definition of FACTORIAL with argument checking that uses
LABELS to define a recursively invoked helper function:

(defun FACTORIAL (n)
  (check-type n (integer 0 *))
  (labels
    ((factorial-helper (n)
      (cond ((zerop n) 1)
            (t (* n (factorial-helper (- n 1)))))))
    (factorial-helper n)))


If I wanted to trace factorial and factorial-helper, I would at least hope
that I could add the following expression to the function definition:

(defun FACTORIAL (n)
  (check-type n (integer 0 *))
  (labels
    ((factorial-helper (n)
      (cond ((zerop n) 1)
            (t (* n (factorial-helper (- n 1)))))))
    (when (member 'factorial (trace) :TEST #'eq)     ; <---
      (trace 'factorial-helper))                     ; <---
    (factorial-helper n)))

The trace of factorial-helper is initialized within the scope of the LABELS
special form, conditionally based on the trace status of the enclosing
factorial function.  Once I've completed debugging, the clause would be
removed.

I believe this ``patch'' is slightly better than avoiding LABELS until all
debugging is complete, but the technique is quite ugly.


A better solution would have implementers augment TRACE with the ability to
trace locally defined functions that are defined within a function:

(TRACE factorial :LOCALLY-DEFINED-FUNCTIONS t)

where TRACE would be smart enough to also trace any functions defined by FLET
and LABELS.  Specific functions might also be an option:

(TRACE factorial :LOCALLY-DEFINED-FUNCTIONS '(factorial-helper)).

One means of implementing such an extension to TRACE would have the LABELS
and FLET special forms check at initialization time whether the functions
they are defining are to be traced.  (I would be satisifed if this check was
only performed for interpreted code.)  When factorial is encapsulated, the
information that factorial-helper should also be traced when it is defined
would be stored for later use by LABELS.  LABELS would create the local
function and also encapsulate it for TRACE.  Then the body of the LABELS
would be evaluated.


Without the ability to trace functions defined by FLET and LABELS, these
forms loose much of their attractiveness--especially to novice programmers.
I consider the definition of factorial using LABELS to be a good example
of Common Lisp programming style, but without the ability to trace its
behavior it is difficult to recommend such programming style to beginners.

Does anyone's implementation of TRACE handle LABELS or FLET?


-- Dan Corkill

∂27-Jun-87  1337	sandra%orion@cs.utah.edu 	print question
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 27 Jun 87  13:37:00 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
	id AA24317; Sat, 27 Jun 87 14:38:55 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
	id AA23897; Sat, 27 Jun 87 14:38:47 MDT
Date: Sat, 27 Jun 87 14:38:47 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8706272038.AA23897@orion.utah.edu>
Subject: print question
To: common-lisp@sail.stanford.edu

In the description of how to print conses on p. 368 of CLtL, the
algorithm says to "print a space" between successive list elements.  Is
this supposed to be taken literally?  I have been having some problems
with large data structures printing out on a single line that's too long
for other utilities (like text editors!) to handle.  It is very annoying
to have your application write files you can't look at.  Turning 
*print-pretty* on does give me a file that the editor can read, but some
of the data structures I'm trying to print are so deeply nested that I
would really prefer not to have all that extra whitespace -- *I* can't
read what it's printing.

I know that some people will say it's the editor that's wedged, but I 
think that in some cases it would be much more user-friendly to write
out a newline instead of a space when the line length exceeds 80
characters or so.  In other cases (like writing to a string output
stream) I probably do not want to get a newline unless I explicitly ask
for one.  Maybe the real solution is to add another parameter to write?
Or should this be an attribute of the particular output stream?  I don't
have a specific proposal in mind (and I really cringe at the thought of
making CL bigger!), but I thought the problem was worth mentioning....

-Sandra
-------

∂28-Jun-87  1146	edsel!bhopal!jonl@navajo.stanford.edu 	print question  
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Jun 87  11:46:38 PDT
Received: by navajo.stanford.edu; Sun, 28 Jun 87 11:43:55 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
	id AA01509; Sun, 28 Jun 87 05:24:48 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
	id AA00660; Sun, 28 Jun 87 05:27:40 PDT
Date: Sun, 28 Jun 87 05:27:40 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706281227.AA00660@bhopal.edsel.uucp>
To: navajo!sandra%orion%cs.utah.edu@navajo.stanford.edu
Cc: navajo!common-lisp%sail.stanford.edu@navajo.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Sat, 27 Jun 87 14:38:47 MDT <8706272038.AA23897@orion.utah.edu>
Subject: print question

Although the MacLisp printer took care to insert "newline"'s ocasionally,
I finally came to believe that PRINT was the wrong place to handle this.
We ultimately made it a per-stream property -- whether or not to break 
long lines -- but one thing I proposed for VAX/NIL and for Interlisp-D 
(which I don't think ever got implemented) was to put the line-breaking 
code into the stream.  That is, some low-level byte-output method in a
stream would be paying attention so such matters of whether or not to 
substitute a "newline" for an ocasional "space", in order to limit the
line length of the output [of course, you would still lose for long
sequences of characters that had no spaces at all in them].  The main
advantage of doing it "in the stream" is user-coded "printers" based
over WRITE-CHAR or WRITE-STRING would also get the benefit.

-- JonL --


∂28-Jun-87  1801	RWK@YUKON.SCRC.Symbolics.COM 	Tracing locally defined functions  
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jun 87  18:00:58 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 231472; Sun 28-Jun-87 20:59:54 EDT
Date: Sun, 28 Jun 87 20:59 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Tracing locally defined functions
To: "Dan Corkill A356 LGRC (413)545-0156" <CORK%cs.umass.edu@RELAY.CS.NET>
cc: Common-Lisp@SAIL.STANFORD.EDU
In-Reply-To: The message of 26 Jun 87 16:18 EDT from "Dan Corkill A356 LGRC (413)545-0156" <CORK%cs.umass.edu@RELAY.CS.NET>
Message-ID: <870628205952.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

    Date: Fri, 26 Jun 87 16:18 EDT
    From: "Dan Corkill A356 LGRC (413)545-0156" <CORK%cs.umass.edu@RELAY.CS.NET>
    A better solution would have implementers augment TRACE with the ability to
    trace locally defined functions that are defined within a function:

    (TRACE factorial :LOCALLY-DEFINED-FUNCTIONS t)

    where TRACE would be smart enough to also trace any functions defined by FLET
    and LABELS.  Specific functions might also be an option:

    (TRACE factorial :LOCALLY-DEFINED-FUNCTIONS '(factorial-helper)).

    Does anyone's implementation of TRACE handle LABELS or FLET?


    -- Dan Corkill

(trace 'foo) would have to refer to the global value.  One simple
technique for tracing from inside a program would be to a
(TRACEF place).

The real problem is that Common Lisp thinks that all functions can
be named with symbols.  This just isn't the case.  Function names
are inherently structured objects.  Our function specs allow us
to trace not just internal functions, but functions living on
property lists, in flavor method tables, in type descriptor objects,
etc. etc.  In general, they are either a symbol (i.e. the trivial
CL usage), or (<type> <primary-name> . <additional info>)

For example, (flavor:method open-the-door door)
refers to the function which implements the OPEN-THE-DOOR
operation for a DOOR flavor.  Another benefit is that the
user doesn't have to know where it's stored or how to get
at it.

Unfortunately, our :INTERNAL function-spec type is a little
awkward; you have to know an internal index.  For anonymous
lambdas, this makes sense, and the index is zero-origin, so
it's not that hard to deal with, but you'd like to be able to
skip the index when it's unambiguous.

For example, your FACTORIAL-HELPER internal function would
be known as (:INTERNAL FACTORIAL 0 FACTORIAL-HELPER)
in our system.  A better scheme would be:

(:INTERNAL FACTORIAL FACTORIAL-HELPER 0), where the 0 is optional,
so long as there's just one FACTORIAL-HELPER local function.

I think we proposed this years ago, but nobody saw the need
back then.  Perhaps now there's enough experience with the
language to let us adopt something like this?

∂29-Jun-87  0707	dml@NADC.ARPA 	Re:  MODIFYF   
Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jun 87  07:06:51 PDT
Received: by NADC.ARPA (5.51/1.0 )
	id AA27336; Mon, 29 Jun 87 10:06:30 EDT
Date: Mon, 29 Jun 87 10:06:30 EDT
From: dml@nadc.arpa (D. Loewenstern)
Message-Id: <8706291406.AA27336@NADC.ARPA>
To: VERACSD@a.isi.edu, common-lisp@sail.stanford.edu
Subject: Re:  MODIFYF
Cc: veracsd@a.isi.edu

In reference to Bob Sasseen's idea of a Modifyf macro:
(Modifyf (CAR x) + 3) <-> (SETF (CAR x) (+ (CAR x) 3))

We have implemented a different, but similar macro:
(DEFMACRO Self (place function-or-form) ...)
Self can take a place and a single function to modify the place with:
(Self object CDDDR) <-> (SETF object (CDDDR object))

If function-or-form is a form, not the name of a function, then Self replaces
the symbol :self with the place:

(Self (Structure-Thing struc) (DELETE NIL :self)) <->
   (SETF (Structure-Thing struc) (DELETE NIL (Structure-Thing struc)))

If place is of type (Function1 (Function2 ...)), Self takes care that
(Function2 ...) is only evaled once:

(Self (CAR (SECOND x)) 1+) <->
   (LET ((#:|(second x)| (SECOND x)))
      (SETF (CAR #:|(second x)|) (1+ (CAR #:|(second x)|))))

I think this is more generally useful than MODIFYF because the
modified field need not be the first argument of the modifier.

I don't feel that Self, Modifyf, or any similar modify macro
should be made part of CL until questions such as robustness vs. readability
can be resolved.


David Loewenstern
Naval Air Development Center
code 7013
Warminster, PA 18974-5000

<dml@nadc.arpa>

∂29-Jun-87  1031	Mailer@xx.lcs.mit.edu 	print question   
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Jun 87  10:31:08 PDT
Received: from XX.LCS.MIT.EDU by navajo.stanford.edu with TCP; Mon, 29 Jun 87 10:27:47 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jun 87 13:28-EDT
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by LIVE-OAK.LCS.MIT.EDU.ARPA via DIAL with SMTP id 49628; 29 Jun 87 13:30:24-EDT
Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 3998; 29 Jun 87 13:00:20-EDT
Date: Mon, 29 Jun 87 12:56 EDT
From: Don Morrison <dfm@jasper.palladian.com>
Subject: print question
To: edsel!bhopal!jonl@navajo.stanford.edu
Cc: navajo!sandra%orion%cs.utah.edu@navajo.stanford.edu,
        navajo!common-lisp%sail.stanford.edu@navajo.stanford.edu
In-Reply-To: <8706281227.AA00660@bhopal.edsel.uucp>
Message-Id: <870629125637.0.DFM@WHITBY.PALLADIAN.COM>
Reply-To: Don Morrison <DFM%JASPER@live-oak.lcs.mit.edu>

    Date: Sun, 28 Jun 87 05:27:40 PDT
    From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)

    Although the MacLisp printer took care to insert "newline"'s ocasionally,
    I finally came to believe that PRINT was the wrong place to handle this.

I would think that it does need to be handled higher up than character I/O.  I
would expect newlines to replace spaces between tokens, but not spaces embedded
within tokens, such as strings; otherwise you can't parse what you print.  Or am
I missing something?



∂29-Jun-87  2210	@RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET 	Re:  A multi-byte character extension proposal    
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 29 Jun 87  22:09:48 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa02113; 30 Jun 87 0:04 EDT
Received: from utokyo-relay by RELAY.CS.NET id aj16893; 29 Jun 87 23:53 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
	id AA14909; Mon, 29 Jun 87 13:26:26 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
	id AA04557; Mon, 29 Jun 87 13:25:54+0900
Date: Mon, 29 Jun 87 13:25:54+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8706290425.AA04557@tansei.cc.u-tokyo.junet>
To: baggins@ibm.com, 
    ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Subject: Re:  A multi-byte character extension proposal
Cc: common-lisp@SAIL.STANFORD.EDU


I got a mail from nippon UNIVAC person as for the matter.
He is one of the contributors of Kanji WG.

Here is his comment.
(I am just acting as a junction between japanese net and US.)

If someone is interested in his reply, I will forward
mails to him (since direct mailing is not premitted.)


Masayuki Ida


============================ his comment =================================

Date: Fri, 26 Jun 87 16:46:31 JST
From: tshimizu@xxx.yyy.junet (Toshihiko Shimizu)
To: ida@u-tokyo.junet
Subject: Our comments to Thom Linden's q

  We  have  reviewed  the  JEIDA  proposal  and  Mr.   Thom   Linden's
questions.  We have been making  efforts for an implementation  of the
extention of Common Lisp for Japanese character processing on Explorer
lisp machine.  Our  efforts have  been made  in pararell  to the JEIDA
Kanji WG activity, and our specifications had been nearly fixed before
the final proposal was issued.  But our implementation almost conforms
to the proposal except the point left being implementation  dependent.
We think it is important to answer Linden's question according to  our
implementation for your information.

 First we have to give an overview of our implementation.  Our primary
goal is completely the same as the JEIDA proposal that we want to  use
Japanese  characters  "as  almost  the  same  as"  characters  already
available.  In Explorer, an extended  ASCII character set called  Lisp
Machine character set has  been used.  We  have added a  new character
set for Japanese characters called JIS character set which is  defined
to be the standard in Japan.  This set has double-byte character code.
Explorer has the  capability to  handle strings  whose elements  are 2
byte long.  This string type can be considered to be a subtype of type
string.  Then  we  use  this  type  of  strings  to  hold  double-byte
characters.  Apparently  these  strings  are  able to hold single-byte
characters as mixture.  This  implementation is considered  almost the
same as the scheme using "internal-thin-string" type described in  the
proposal.  We are  now preparing  a paper  on this  implementation for
WGSYM IPSJ, September 1987.  Please refer it for further detailes.


The followings are our answers to Linden's questions;


1)
 All Common Lisp standard characters are included in the standared JIS
character set, but they have different character code from the ones in
ASCII character set.  This situation is almost likely in case of usual
file systems  which  allow  JIS  character  set.   Then we think these
difference has to  be preserved  when files  are read  into Lisp  as a
sequance of characters.  After that we can think of parsing, discussed
later.


2)
 Above interpretation seems  to lead  to a  contradiction against  the
description in CLtL  (p.233).  We  think that  two distinct  character
objects may have the  same print glyphs,  but in this  case they shold
have  the  same  syntactic  properties.   Indeed  they  are  different
characters but somtimes we doubt.   Because they may be  printed using
various fonts and sometimes these printed figures are very similar.


3), 4)
 Actually we have both single-byte and double-byte representations for
some characters.  But  we never  try to  map them  into the one except
when the Lisp reader  parses them.  This  is because these  difference
have to be preserved as described above.  And we think that once these
two representation is mapped into the one, there are no reasonable way
to make inverse mapping.  This  is the crucial point  for applications
on Lisp to interact with other conventional applications.  Suppose  we
have a text processing application on Lisp and we want use it  against
a text  file  in  which  single-byte  and  double-byte  characters are
containted in  mixture.   It  is  not  desirable  if  all  single-byte
characters in the source text file are mapped into double-byte ones.


5)
 Now our stand point is that a double-byte character can be a standard
character within  the  parsing  context  only  if its printed glyph is
regarded as a  standard character.   As a  result, there  must be some
test for  this  correspondence.   Acturally  we have this "equivalence
test".   Both  the  single-byte  character  set  and  the  double-byte
character set include  standard characters.   If a  character from the
single-byte character set which  is a standard  character, there is  a
corresponding character in the  double-byte character set.   And these
two characters  pass  the  "equivalence  test",  but they never be EQ.
However this point may lead to  a contradiction to the description  in
CLtL (p.20).

5a)
 Then, our implementation  recognizes some  double-byte characters  as
standard characters.  For example,  STANDARD-CHAR-P returns T  against
#\a in the double-byte character set.

5b)
 Our implementation takes option 3 in the proposal.  That is, we don't
distinguish single-byte and  double-byte versions  of symbols,  but we
preserve these difference within strings.  For example, two version of
a symbol 'LAMBDA are considered to be EQ, but two versions of a string
"LAMBDA" are  distinguished,  or  not  EQUAL,  but  they pass the test
described above.  Further,  there may  be mixed  versions of  a string
"LAMBDA".

5c)
 We might  agree  Linden's  point  if  we  didn't think about strings.
Actually our  primary  understanding  was  that  there  was no need to
distinguish such a  difference for  the sole  purpose of  Common Lisp.
But there is a certain  requirement for interaction with  conventional
applications in which distinction between single-byte and  double-byte
version is significant.  Then we  decided that the distinction  is not
neccessary for  symbols  which  plays  an  important role in programs,
whereas it  is  neccessary  for  strings  which are primarily used for
interaction with outer world, such as files, displays, and networks.

5d)
 As we  defined  that  a  double-byte  character  may  be  a  standard
character, it  is  consistent  to  define  such a character to satisfy
ALPHA-CHAR-P.   Then  both   version  of   a  character   'a'  satisfy
ALPHA-CHAR-P, ALPHANUMERICP and LOWER-CASE-P.

5e)
 We think that these description  sholud be eraborated, but  the JEIDA
committee  has  decided  that  these  should  be  left  implementation
dependent.


6)
 In our implementation, such syntactic attributes relevant to  parsing
and format controlling are only defined for standard characters.  That
is, if a  character is  a double-byte  character and  also a standared
character at  the  same  time,  it  may  have  non-constituent syntax.
Indeed it has the same syntax attribute as the single-byte version  of
it.  For example, a string "123" in double-byte version is also parsed
into a  number  123.   Otherwise  its  syntax  cannot  be  other  than
constituent.


7)
 We think it is  not neccessary to  have such a  large readtable which
covers all characters of type  string-char.  We only have  a readtable
for single-byte characters and uses  the "equivalent" mapping for  the
double-byte version of these characters.  And the rest of  double-byte
characters are defined to have constituent syntax.


8)
 In  our  implementation,   MAKE-DISPATCH-MACRO-CHARACTER  against   a
non-standard, double-byte character is an error.





------------- end of the message -----------

∂30-Jun-87  1021	@RELAY.CS.NET:HASSETT@sp.unisys.com 	2 namespaces & a complement to #' notation 
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 30 Jun 87  10:21:03 PDT
Received: from relay2.cs.net by RELAY.CS.NET id af06830; 30 Jun 87 12:11 EDT
Received: from sp.unisys.com by RELAY.CS.NET id ac20556; 30 Jun 87 12:05 EDT
Date:     Tue, 30 Jun 87 11:05 CDT
From:     Jim Hassett <HASSETT%sp.unisys.com@RELAY.CS.NET>
To:       common-lisp@SAIL.STANFORD.EDU
Subject:  2 namespaces & a complement to #' notation
X-VMS-To: IN%"common-lisp@SAIL.STANFORD.EDU"

The recent article by Kers (Christopher Dollin) concerning the two-namespace
issue and Pop gives me an excuse for bringing up a related item.  I'll be
surprised if this idea has not been discussed before, but I've only been on
this list for a year, so I haven't seen it.  Like Kers, I recently
read "Issues of Separation in Function Cells and Value Cells" by Gabriel &
Pitman.  I have been unable to resolve my personal preferences on this
issue.  I like the elegance and notational simplicity of a single
namespace, but I also find it convenient that I needn't worry much about
selecting names for lexical variables in Common Lisp.  I might find a
single namespace easier to accept were it not for a mere handful of very
useful functions whose names happen to be very useful variable names (e.g.,
COUNT, LIST, STRING, and GET-SETF-METHOD-MULTIPLE-VALUE :-).

But perhaps it is too late to change Common Lisp to a single-namespace Lisp
dialect.  If so, we should look for ways to mitigate the problems of having
two namespaces.  One problem is the awkwardness of having to use FUNCALL to
invoke a function which is the (ordinary) value of a variable or other
form.  This is illustrated by Gabriel & Pitman with definitions of the Y
operator (or paradoxical combinator) of lambda calculus.  For a language
with a single namespace, the definition given is

   (defun y (f)
    ((lambda (g) (lambda (h) ((f (g g)) h)))
     (lambda (g) (lambda (h) ((f (g g)) h)))))

For a language with separate function and value namespaces, the definition
is more complex:

   (defun y (f)
    ((lambda (g) #'(lambda (h) (funcall (funcall f (funcall g g)) h)))
     #'(lambda (g) #'(lambda (h) (funcall (funcall f (funcall g g)) h)))))

(Note: My copy of the Gabriel & Pitman paper omits the second #', but it is
needed to prevent attempted evaluation of the lambda expression.)

To simplify the notation of this definition, we could alter the evaluation
of forms to allow the definition a macro character, perhaps #@, to
complement the #' syntax.  A form preceded by #@ in the function position
would have its ordinary value used as the function to be applied.  The
definition of Y would then be shorter, if not prettier:

   (defun y (f)
    ((lambda (g) #'(lambda (h) (#@(#@f (#@g g)) h)))
     #'(lambda (g) #'(lambda (h) (#@(#@f (#@g g)) h)))))

The effect of this change can be obtained in Common Lisp by the following
inelegant technique.  Define ORDINARY-FUNCTION-VALUE-READER to convert a #@
form into a lambda-expression which applies the value of the form to its
arguments, and install this function to handle the #@ macro character:

   (defun ordinary-function-value-reader (stream subchar arg)
     (declare (ignore subchar arg))
     `(lambda (&rest args) (apply ,(read stream t nil t) args)))

   (set-dispatch-macro-character #\# #\@ #'ordinary-function-value-reader)

This works, but a better implementation would allow some new expression
such as (ordinary-value <form>) to be used in the function position,
analogous to the current use of lambda expressions.

Has this approach been considered?  Is it just too ugly to get much
support?  Or am I missing a serious problem?

Jim Hassett

∂01-Jul-87  0742	@Score.Stanford.EDU,@MCC.COM:krall%pp.mcc.com@mcc.com 	Flavors for KCL
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Jul 87  07:42:33 PDT
Received: from MCC.COM by SU-SCORE.ARPA with TCP; Wed 1 Jul 87 07:37:25-PDT
Received: from pp.mcc.com by MCC.COM with TCP; Wed 1 Jul 87 09:28:21-CDT
Posted-Date: Wednesday, 1 July 1987, 08:32-CDT
Message-Id: <8707011334.AA29297@pp.mcc.com>
Received: from amber.pp.mcc.com by pp.mcc.com (4.12/KA70505) 
	id AA29297; Wed, 1 Jul 87 08:34:16 cdt
Date: Wednesday, 1 July 1987, 08:32-CDT
From: <krall%pp.mcc.com%pp.mcc.com@mcc.com>
Sender: krall%pp.mcc.com@mcc.com
Subject: Flavors for KCL
To: common-lisp@SAIL.STANFORD.EDU

Does anyone have access to a machine independent Flavors or a Flavors
for Kyoto Common Lisp.  We have some software here written for Symbolics
in Common Lisp with Flavors and would like to port it to KCL will minimal
change.


-Ed Krall
Parallel Processing Program
Microelectronics and Computer Technology Corporation
3500 West Balcones Center Drive
Austin, Texas  78759
(512) 338-3406
ARPA: krall@mcc.com
UUCP: {ihnp4,seismo,ctvax}!ut-sally!im4u!milano!mcc-pp!krall

∂02-Jul-87  0534	mab@mind.Princeton.EDU 	Loop Macro (after Zetalisp, franz, etc.) 
Received: from PRINCETON.EDU by SAIL.STANFORD.EDU with TCP; 2 Jul 87  05:34:18 PDT
Received: by Princeton.EDU (5.51/1.29)
	id AA08478; Thu, 2 Jul 87 08:32:54 EDT
Received: by mind.Princeton.EDU (4.12/1.52)
	id AA06027; Thu, 2 Jul 87 08:36:08 edt
Date: Thu, 2 Jul 87 08:36:08 edt
From: Marie Bienkowski <mab@mind.Princeton.EDU>
Message-Id: <8707021236.AA06027@mind.Princeton.EDU>
To: common-lisp@sail.stanford.edu
Subject: Loop Macro (after Zetalisp, franz, etc.)

Has anyone ported the powerful loop macro provided
with, e.g., the Symbolics Zetalisp, into regular
common lisp.  I am particularly interested in a
version for Lucid Common Lisp.

		Thanks,
		Marie
		(mab@mind.princeton.edu)

∂02-Jul-87  0812	mab@flash.bellcore.com 	Loop Macro (after Zetalisp, Franz, etc.) 
Received: from FLASH.BELLCORE.COM by SAIL.STANFORD.EDU with TCP; 2 Jul 87  08:11:57 PDT
Received: by flash.bellcore.com (4.12/4.7)
	id AA12487; Thu, 2 Jul 87 08:25:11 edt
Date: Thu, 2 Jul 87 08:25:11 edt
From: mab@flash.bellcore.com (Marie Bienkowski)
Message-Id: <8707021225.AA12487@flash.bellcore.com>
To: common-lisp@sail.stanford.edu
Subject: Loop Macro (after Zetalisp, Franz, etc.)

Has anyone ported the wonderful loop macro provided
e.g., with Symbolics Zetalisp, into regular Common
Lisp (most particularly, Lucid Common Lisp).

Even a port into another Common Lisp would be helpful.

			Thanks in advance
			Marie

∂02-Jul-87  0911	kempf%hplabsc@hplabs.HP.COM 	Location of defsys.l?
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 2 Jul 87  09:11:01 PDT
Received: from hplabsc by hplabs.HP.COM with TCP ; Thu, 2 Jul 87 09:10:13 pdt
Received: by hplabsc ; Thu, 2 Jul 87 08:11:34 pdt
Date: Thu, 2 Jul 87 08:11:34 pdt
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8707021511.AA22363@hplabsc>
To: common-lisp@sail.stanford.edu
Subject: Location of defsys.l?

Some time ago, someone posted the location of a public domain defsys.l
on SAIL, which I neglected to save. Could someone who has it either
mail it or send me the location? I would be eternally grateful.
		Jim Kempf	kempf@hplabs.hp.com

∂02-Jul-87  1355	@RELAY.CS.NET:GREENBERG@cs.umass.edu 	Questions about (function eq)   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 2 Jul 87  13:55:02 PDT
Received: from relay2.cs.net by RELAY.CS.NET id au00953; 2 Jul 87 11:47 EDT
Received: from cs.umass.edu by RELAY.CS.NET id ay00482; 2 Jul 87 1:08 EDT
Date: Wed, 1 Jul 87 14:25 EDT
From: Michael Greenberg <GREENBERG%cs.umass.edu@RELAY.CS.NET>
Subject: Questions about (function eq)
To: common-lisp@SAIL.STANFORD.EDU
X-VMS-To: IN%"common-lisp@sail.stanford.edu"


I have several questions concerning the difference between

    (pushnew 'foo bar :test #'eq)

and

    (pushnew 'foo bar :test 'eq)


What are the semantic differences?  Is there
a difference between

    (defun xyz ()
	(flet ((eq (a b) (bar a b)))
	  (pushnew 'foo bar :test #'eq)))

and

    (defun xyz ()
	(flet ((eq (a b) (bar a b)))
	  (pushnew 'foo bar :test 'eq)))


What are the stylistic differences?


Which of the following macro definitions
is preferred?  Why?

(defmacro foo (fn)
  (if (eq fn 'eq)
      '(expansion-1 ...)
      '(expansion-2 ...)))

(defmacro foo (fn)
  (if (eq fn #'eq)
      '(expansion-1 ...)
      '(expansion-2 ...)))

(defmacro foo (fn)
  (if (or (eq fn #'eq) (eq fn 'eq))
      '(expansion-1 ...)
      '(expansion-2 ...)))



Michael Greenberg
greenberg@cs.umass.edu

∂02-Jul-87  1510	barmar@Think.COM 	Questions about (function eq)   
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 2 Jul 87  15:10:39 PDT
Received: from ubaldo by Think.COM via CHAOS; Thu, 2 Jul 87 18:11:50 EDT
Date: Thu, 2 Jul 87 18:09 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Questions about (function eq)
To: Michael Greenberg <GREENBERG%cs.umass.edu@relay.cs.net>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8707022101.AA29766@Think.COM>
Message-Id: <870702180943.1.BARMAR@UBALDO.THINK.COM>

    Date: Wed, 1 Jul 87 14:25 EDT
    From: Michael Greenberg <GREENBERG%cs.umass.edu@relay.cs.net>

    What are the semantic differences?  Is there
    a difference between

	(defun xyz ()
	    (flet ((eq (a b) (bar a b)))
	      (pushnew 'foo bar :test #'eq)))

    and

	(defun xyz ()
	    (flet ((eq (a b) (bar a b)))
	      (pushnew 'foo bar :test 'eq)))

Yes there is.  In the first case, PUSHNEW will call your local function
EQ, while in the second case it will call the global one.  The second
one is equivalent to

	(defun xyz ()
	    (flet ((eq (a b) (bar a b)))
	      (pushnew 'foo bar :test (symbol-function 'eq))))

FLET creates a lexical binding, it doesn't do anything to the symbol's
function cell; therefore, if PUSHNEW is given the symbol, all it can do
is call SYMBOL-FUNCTION to extract its global function binding.

    What are the stylistic differences?

Since there are semantic differences, I don't think the stylistic
differences matter.  Style choices don't come into play unless you're
choosing between equivalent operations.

    Which of the following macro definitions
    is preferred?  Why?

    (defmacro foo (fn)
      (if (eq fn 'eq)
	  '(expansion-1 ...)
	  '(expansion-2 ...)))

    (defmacro foo (fn)
      (if (eq fn #'eq)
	  '(expansion-1 ...)
	  '(expansion-2 ...)))

    (defmacro foo (fn)
      (if (or (eq fn #'eq) (eq fn 'eq))
	  '(expansion-1 ...)
	  '(expansion-2 ...)))

I don't think any of them are even right.  You presumably meant the
conditional to be one of
	(equal fn ''eq)
	(equal fn '#'eq)
or
	(or (equal fn '#'eq) (equal fn ''eq))

because macros are passed the data structure from the form, not the
evaluation (you have to use EQUAL because they are lists).  I'm assuming
that FOO is intended to be called as
	(FOO 'EQ)
or
	(FOO #'EQ)

If you want to allow both forms, then my third conditional would be the
one to use.

If you want it to be callable as (FOO EQ), then your (not my) first form
would be correct.

I don't think this will do the right thing in the face of
locally-shadowed functions, though.  The conditional is only looking at
the list structure, i.e. it is checking whether its argument is the list
whose first element is either the symbol FUNCTION or the symbol QUOTE
and whose second element is the symbol EQ.  In the #'EQ case, the macro
has no way of evaluating this in the appropriate lexical environment in
order to check whether it refers to the "real" EQ function.  If the
expansion contains ,FN or #'EQ, though, it will refer to a local EQ
function if there is one, because macro expansions get processed in the
caller's lexical scope.

For this reason, I recommend that you not try to do this as a macro.  If
you do it as a function you can compare the argument against
(SYMBOL-FUNCTION 'EQ), and conditionalize it at that time.  If you
really need the performance gain that the macro provides, you should
clearly document the fact that it assumes that #'EQ is the standard EQ.

In general, macros and FLET can have some weird interactions.  Every
macro makes assumptions about the functional values of symbols.  For
example,

(defmacro bar (a b)
  `(list (cons ,a 1) (cons ,b 2)))

makes an assumption about LIST.  If one then did

(defun quux (c)
  (flet ((list (thing) (car thing)))
    (bar c (1+ c))))

an error would be reported because the local function LIST was being
called with the wrong number of arguments, because this is equivalent to

(defun quux (c)
  (flet ((list (thing) (car thing)))
    (list (cons c '1) (cons (1+ c) '2))))

Macros, as they are currently defined, don't obey lexical scoping,
because they are very simple rewrite rules.

There has been some research on new ways to define macro expansion that
don't have these problems, and there is some investigation taking place
in X3J13, the ANSI Common Lisp standardization committee.  For now,
though, that's the way it is.

						barmar

∂02-Jul-87  1643	primerd!enx!doug@EDDIE.MIT.EDU
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Jul 87  16:43:26 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 
	id <AA05553@EDDIE.MIT.EDU>; Thu, 2 Jul 87 19:41:57 EDT
Received: by primerd.prime.com (3.2/SMI-3.0DEV3/smail)
	id AA12485; Thu, 2 Jul 87 13:54:14 EDT
Message-Id: <8707021754.AA12485@primerd.prime.com>
Received: (from user DOUG) by ENX.Prime.PDN; 02 Jul 87 13:06:38 EST
To: COMMON-LISP@SAIL.STANFORD.EDU
From: primerd!DOUG@ENX.Prime.PDN
Date: 02 Jul 87 13:06:38 EST

To:       Commonlisp (common-lisp@sail.stanford.edu)
From:     Doug Rand (DOUG@ENX.PRIME.COM)
Date:     02 Jul 87  1:04 PM
Subject:  Re: Location of defsys.l?

They are on defsys.lsp[com,lsp] and defsys.doc[com,lsp] on SAIL.

To add to the meager documentation (I'll eventually fix this in
defsys.doc):

:needed-systems lets a system require other systems.  So to use system A
you would like systems B and C to be loaded you can specify this with
:needed-systems (B C).  This means that B and C will be loaded before
A.  It also means that when you compile-system A then B and C with be
recompiled (as if you typed (compile-system B) (compile-system C)
before (compile-system A)).  This behavior is controlled by
the :include-components keyword arg to load-system and compile-system.

The obscure sentence about :recompile-on means that the module with
be recompiled if the date-time-modified (DTM) of any of the named,
updated modules is newer then the module's DTM.  This is a common
concept in utilities like UNIX MAKE and I'm suprised that this is
a new concept for LISPer's.

Cheers,

Doug

∂02-Jul-87  1651	jeff%JASPER.Palladian.COM@XX.LCS.MIT.EDU 	Loop Macro (after Zetalisp, Franz, etc.)   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Jul 87  16:51:47 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 2 Jul 87 19:42-EDT
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by LIVE-OAK.LCS.MIT.EDU.ARPA via DIAL with SMTP id 50147; 2 Jul 87 19:35:44-EDT
Received: from CHUGACH.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 4262; 2 Jul 87 18:37:44-EDT
Date: Thu, 2 Jul 87 18:33 EDT
From:  <jeff@JASPER.Palladian.COM>
Subject: Loop Macro (after Zetalisp, Franz, etc.)
To: Marie Bienkowski <mab@flash.bellcore.com>,
    common-lisp@sail.stanford.edu
In-Reply-To: <8707021225.AA12487@flash.bellcore.com>
Message-ID: <"870702183327.7.jeff@JASPER"@CHUGACH.Palladian.COM>
Reply-To: jeff%JASPER@LIVE-OAK.LCS.MIT.EDU

    Date: Thu, 2 Jul 87 08:25:11 edt
    From: mab@flash.bellcore.com (Marie Bienkowski)

    Has anyone ported the wonderful loop macro provided
    e.g., with Symbolics Zetalisp, into regular Common
    Lisp (most particularly, Lucid Common Lisp).

    Even a port into another Common Lisp would be helpful.

			    Thanks in advance
			    Marie


Read below. This is an exerpt from our local copy of the file which the exerpt
describes. We use this with Lucid Common Lisp. BTW, the file is about 58K bytes.

jeff

   ;;;; LOOP Iteration Macro
   
   ;;; This is the "officially sanctioned" version of LOOP for running in
   ;;; Common Lisp.  It is a conversion of LOOP 829, which is fairly close to
   ;;; that released with Symbolics Release 6.1 (803).  This conversion was
   ;;; made by Glenn Burke (one of the original author/maintainers);  the
   ;;; work was performed at Palladian Software, in Cambridge MA, April 1986.
   ;;; 
   ;;; The current version of this file will be maintained at MIT, available
   ;;; for anonymous FTP on MC.LCS.MIT.EDU from the file "LSB1;CLLOOP >".  This
   ;;; location will no doubt change sometime in the future.

[NB. It appears to have been moved to AI.AI.MIT.EDU in "GSB;CLLOOP >" -jeff]

   ;;; 
   ;;; This file, like the LOOP it is derived from, has unrestricted
   ;;; distribution -- anyone may take it and use it.  But for the sake of
   ;;; consistency, bug reporting, compatibility, and users' sanity, PLEASE
   ;;; PLEASE PLEASE don't go overboard with fixes or changes.  Remember that
   ;;; this version is supposed to be compatible with the Maclisp/Zetalisp/NIL
   ;;; LOOP;  it is NOT intended to be "different" or "better" or "redesigned".
   ;;; Report bugs and propose fixes to BUG-LOOP@MC.LCS.MIT.EDU;
   ;;; announcements about LOOP will be made to the mailing list
   ;;; INFO-LOOP@MC.LCS.MIT.EDU.  Mail concerning those lists (such as requests
   ;;; to be added) should be sent to the BUG-LOOP-REQUEST and
   ;;; INFO-LOOP-REQUEST lists respectively.  Note the Change History page
   ;;; below...
   ;;; 
   ;;; LOOP documentation is still probably available from the MIT Laboratory
   ;;; for Computer Science publications office:
   ;;; 	LCS Publications
   ;;; 	545 Technology Square
   ;;; 	Cambridge, MA 02139
   ;;; It is Technical Memo 169, "LOOP Iteration Macro", and is very old.  The
   ;;; most up-to-date documentation on this version of LOOP is that in the NIL
   ;;; Reference Manual (TR-311 from LCS Publications);  while you wouldn't
   ;;; want to get that (it costs nearly $15) just for LOOP documentation,
   ;;; those with access to a NIL manual might photocopy the chapter on LOOP.
   ;;; That revised documentation can be reissued as a revised technical memo
   ;;; if there is sufficient demand.


∂06-Jul-87  0937	@Score.Stanford.EDU,@MCC.COM:krall%pp.mcc.com@mcc.com 	Atoms in association lists    
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jul 87  09:37:34 PDT
Received: from MCC.COM by SU-SCORE.ARPA with TCP; Mon 6 Jul 87 09:32:56-PDT
Received: from pp.mcc.com by MCC.COM with TCP; Mon 6 Jul 87 11:36:45-CDT
Posted-Date: Monday, 6 July 1987, 11:34-CDT
Message-Id: <8707061637.AA02959@pp.mcc.com>
Received: from amber.pp.mcc.com by pp.mcc.com (4.12/KA70505) 
	id AA02959; Mon, 6 Jul 87 11:37:16 cdt
Date: Monday, 6 July 1987, 11:34-CDT
From: <krall%pp.mcc.com%pp.mcc.com@mcc.com>
Sender: krall%pp.mcc.com@mcc.com
Subject: Atoms in association lists
To: common-lisp@sail.stanford.edu


I am not sure if this is just another interpretation or (more likely) a
	bug:

	I write
		(setq alist '((a . 1) b (c . 3)))
	then try
		(assoc 'c alist)

In Kyoto Common Lisp and in ZetaLisp, I get an error since the second
	element of alist is not a CONS.  In Golden Common Lisp, I get no
	error.  In fact
		(assoc 'b alist) ==> nil

I like the Gold Hill implementation, however.  It makes the processing of
	things like 
		((:gettable-instance-variables a b)
		 :settable-instance-variables
		 (inittable-instance-variables c d))
	easier.

Is the GCLisp interpretation wrong?  If so, aside from RPLACD problems,
	wouldn't the GCLisp be slightly more useful?


-Ed Krall
Parallel Processing Program
Microelectronics and Computer Technology Corporation
3500 West Balcones Center Drive
Austin, Texas  78759
(512) 338-3406
ARPA: krall@mcc.com
UUCP: {ihnp4,seismo,ctvax}!ut-sally!im4u!milano!mcc-pp!krall


∂06-Jul-87  1838	OKUNO@SUMEX-AIM.STANFORD.EDU 	Re: Flavors for KCL 
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jul 87  18:38:11 PDT
Date: Mon, 6 Jul 87 18:35:28 PDT
From: Hiroshi "Gitchang" Okuno <Okuno@SUMEX-AIM.STANFORD.EDU>
Subject: Re: Flavors for KCL
To: krall%pp.mcc.com%MCC.COM@SUMEX-AIM.STANFORD.EDU
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <8707011334.AA29297@pp.mcc.com>
Organization: Knowledge Systems Laboratory
Group: Heuristic Programming Project
Project: Advanced Architectures Project
Address: 701 Welch Road, Building C, Palo Alto, CA 94304-1703
Phone: +1 (415)725-4854
Message-ID: <12316328931.47.OKUNO@SUMEX-AIM.STANFORD.EDU>

Mr. Hagiya, one of the implementors of KCL ported the Flavors system
to KCL.  This Flavors was originally written in Franz Lisp by Franz
Inc.  Please contact him if you are interested.  His E-mail address is

	hagiya%kurims.kurims.kyoto-u.junet%japan.csnet@relay.cs.net

- Gitchang -
-------

∂07-Jul-87  0918	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Atoms in association lists   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 7 Jul 87  09:18:25 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 188793; Mon 6-Jul-87 22:34:14 EDT
Date: Mon, 6 Jul 87 22:34 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Atoms in association lists
To: krall%pp.mcc.com@mcc.com
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8707061637.AA02959@pp.mcc.com>
Message-ID: <870706223404.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Monday, 6 July 1987, 11:34-CDT
    From: <krall%pp.mcc.com%pp.mcc.com@mcc.com>

    ... I write  (setq alist '((a . 1) b (c . 3)))
        then try (assoc 'c alist)

    In Kyoto Common Lisp and in ZetaLisp, I get an error since the second
    element of alist is not a CONS.  In Golden Common Lisp, I get no error.
    ...

This is an "is an error" situation. Implementations are permitted to do
whatever they want in such a situation since you are not supposed to ever
cause this situation to occur.

    I like the Gold Hill implementation, however.  It makes the processing of
    things like 
	    ((:gettable-instance-variables a b)
	     :settable-instance-variables
	     (inittable-instance-variables c d))
    easier.

Nothing to do with your question, but I wouldn't use ASSOC for this anyway,
since using it implies to me that you're looping over possible keywords doing
ASSOC rather than looping over the supplied options checking validity. This
is bad for at least three reasons that come immediately to mind:
 * You won't detect mis-spelled or totally bogus keywords. For example,
   (ASSOC ':INITABLE-INSTANCE-VARIABLES your-list) will return NIL
   both because you didn't write it in the keyword package and because
   you didn't spell it right.
 * It will seem as if :SETTABLE-INSTANCE-VARIABLES is missing because
   (ASSOC ':SETTABLE-INSTANCE-VARIABLES your-list) will return NIL.
   I guess you can MEMBER for it later, but that seems really odd to me.
 * You won't correctly detect duplications. eg,
    ((:gettable-instance-variables a) (:gettable-instance-variables b))
   which you may want to treat like:
    ((:gettable-instance-variables a b))
   or at least you way want to warn about.
Getting back to your original question, though...

    Is the GCLisp interpretation wrong?

I can't really speak for GCLisp. Even if it does this, you'd better check
their documentation carefully to see if it is documented behavior. If it's
not, they'd be within their rights to change the behavior incompatibly
between releases, leaving your code broken.

I know that Maclisp used to have a similar behavior, but it worked by
never doing an atom test before taking CAR of the alist entry.  That
generally worked out fine because the (CAR symbol) returned something
which you couldn't make any other way and hence were not likely to be
searching for. (It wouldn't surprise me to find that
 (ASSOC (CAR 'A) '(A)) => A
in compiled Maclisp.) Anyway, CL could surely not tolerate an
interpretation that allowed blind CAR'ing into symbols. CL implementations
represent symbols in lots of different ways, and some of them might have
interesting user-accessible objects in the slot that CAR would look in,
so asking ASSOC to ignore atoms would mean putting an explicit atom check
in the ASSOC inner loop, which might be very slow in some implementations.

Also, efficiency aside, there's an error-checking argument. Even if we
made atoms in an alist be legal, that wouldn't mean that every time an
atom occurred in an alist it was there intentionally. Ill-formed alists
are easy to construct. If we made it legal to have atoms at toplevel in
an alist, an interesting class of program bugs that could have been
detected would not be detectable because we could not tell whether the
atom was there by design or by accident. In fact, entry to the debugger
is not always bad. The KCL and Zetalisp versions are doing you a favor
by flagging a buggy situation in your code; GCLisp is apparently not
doing you that favor.

    If so, aside from RPLACD problems, wouldn't the GCLisp be slightly
    more useful?

I doubt any claimed usefulness would be worth the price in lost efficiency
and error checking. By the way, there are no RPLACD problems.
 (ASSOC 'B '((A 3) B (C 4)))
returns NIL, but so does
 (ASSOC 'B '((A 3) (C 4)))
You must always either do an ATOM check on the result of an ASSOC or
know absolutely for sure that the thing you're looking for is going to
be in the list before you do the RPLACD. Any RPLACD problem you're
alluding to was either already present before you brought up this issue
or was just imagined.

∂07-Jul-87  1902	OKUNO@SUMEX-AIM.STANFORD.EDU 	Re: Flavors for KCL 
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Jul 87  19:02:09 PDT
Date: Tue, 7 Jul 87 19:00:23 PDT
From: Hiroshi "Gitchang" Okuno <Okuno@SUMEX-AIM.STANFORD.EDU>
Subject: Re: Flavors for KCL
To: krall%pp.mcc.com%MCC.COM@SUMEX-AIM.STANFORD.EDU,
    common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <12316328931.47.OKUNO@SUMEX-AIM.STANFORD.EDU>
Organization: Knowledge Systems Laboratory
Group: Heuristic Programming Project
Project: Advanced Architectures Project
Address: 701 Welch Road, Building C, Palo Alto, CA 94304-1703
Phone: +1 (415)725-4854
Message-ID: <12316595611.63.OKUNO@SUMEX-AIM.STANFORD.EDU>

I'm sorry that I posted a wrong information on FLavors.  It should read
"Mr. Hagiya, one of the implementors of KCL, ported a public domain
Flavors system to KCL.  This system was originally developed at MIT".

Sorry for your inconvenience,

- Gitchang -
-------

∂08-Jul-87  0938	coffee@aerospace.aero.org 	Re: Atoms in association lists   
Received: from [26.2.0.65] by SAIL.STANFORD.EDU with TCP; 8 Jul 87  09:38:09 PDT
Received: by aerospace.aero.org (5.54/6.0.GT)
	id AA05259; Tue, 7 Jul 87 23:41:51 PDT
Posted-Date: Tue, 07 Jul 87 23:41:31 -0800
Message-Id: <8707080641.AA05259@aerospace.aero.org>
To: krall%pp.mcc.com%pp.mcc.com@mcc.com
Cc: common-lisp@sail.stanford.edu
Subject: Re: Atoms in association lists
In-Reply-To: Your message of Monday, 6 July 1987, 11:34-CDT.
             <8707061637.AA02959@pp.mcc.com>
Date: Tue, 07 Jul 87 23:41:31 -0800
From: coffee@aerospace.aero.org


I wonder how Gold Hill would handle the example on p. 281 of CLtL, i.e., a
NIL appearing in place of a pair in the a-list and an invocation of
(assoc nil a-list). Steele notes that (assoc item list :test fn) is
equivalent to (find item list :test fn :key #'car) *except* in this case,
because the FIND will take the CAR of NIL and succeed with NIL while the
ASSOC "will ignore the NIL in the a-list and continue to search for an
actual pair (cons) whose CAR is NIL." I rather suspect that the Gold Hill
implementation will fail to make this distinction, and if so I would consider
this a bug (no matter how special the case may be).

∂08-Jul-87  1224	dml@NADC.ARPA 	Re: Atoms in association lists
Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 8 Jul 87  12:23:49 PDT
Received: by NADC.ARPA (5.51/1.0 )
	id AA11071; Wed, 8 Jul 87 15:00:19 EDT
Date: Wed, 8 Jul 87 15:00:19 EDT
From: dml@NADC.ARPA (D. Loewenstern)
Message-Id: <8707081900.AA11071@NADC.ARPA>
To: coffee@aerospace.aero.org, krall%pp.mcc.com%pp.mcc.com@mcc.com
Subject: Re: Atoms in association lists
Cc: common-lisp@sail.stanford.edu

Actually, GCLisp handles atoms in alists by ignoring them, whether they are
strings, NIL, or other symbols.  E.g.,

(SETQ abc '(c (c . 3) NIL (NIL . 4)))
(ASSOC 'c abc) --> (c . 3)
(ASSOC nil abc) --> (NIL . 4)

This is in accordance with CLtL, I believe.

David Loewenstern
Naval Air Development Center
code 7013
Warminster, PA 18974-5000

<dml@nadc.arpa>

∂08-Jul-87  1448	Daniels.pa@Xerox.COM 	Re: Atoms in association lists   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Jul 87  14:48:09 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUL 87 14:34:02 PDT
Date: 8 Jul 87 14:33 PDT
From: Daniels.pa@Xerox.COM
Subject: Re: Atoms in association lists
In-reply-to: dml@NADC.ARPA (D. Loewenstern)'s message of Wed, 8 Jul 87
 15:00:19 EDT
To: dml@NADC.ARPA
cc: coffee@aerospace.aero.org, krall%pp.mcc.com%pp.mcc.com@mcc.com,
 common-lisp@sail.stanford.edu
Message-ID: <870708-143402-2869@Xerox>

Ignoring NIL in an alist is in accordance with CLtL. Any other non-cons
in an alist is an error and may be dealt with as you see fit.

		-- Andy. --

∂08-Jul-87  2038	edsel!bhopal!jonl@navajo.stanford.edu 	print question  
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Jul 87  20:37:53 PDT
Received: by navajo.stanford.edu; Wed, 8 Jul 87 20:35:09 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
	id AA04214; Wed, 8 Jul 87 20:23:28 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
	id AA03874; Wed, 8 Jul 87 20:27:01 PDT
Date: Wed, 8 Jul 87 20:27:01 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8707090327.AA03874@bhopal.edsel.uucp>
To: navajo!DFM%JASPER%LIVE-OAK.LCS.MIT.EDU@navajo.stanford.edu
Cc: navajo!sandra%orion%cs.utah.edu@navajo.stanford.edu,
        navajo!common-lisp%sail@navajo.stanford.edu
In-Reply-To: Don Morrison's message of Mon, 29 Jun 87 12:56 EDT
Subject: print question

[This may have been answered already]

MacLisp "streams" had an operation which basically amounted to saying
"I want to output an n-character, unbroken sequence".  By using this
rather internal operation, the PRINT function would insure that streams
with line-breaking capability didn't put the breaks at inappropriate 
places.  I guess this means that the PRINT function is still somewhat
involved.

-- JonL --

∂08-Jul-87  2202	edsel!bhopal!jonl@navajo.stanford.edu 	Loop Macro (after Zetalisp, franz, etc.) 
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Jul 87  22:02:47 PDT
Received: by navajo.stanford.edu; Wed, 8 Jul 87 21:59:43 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
	id AA04307; Wed, 8 Jul 87 21:33:03 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
	id AA04024; Wed, 8 Jul 87 21:36:35 PDT
Date: Wed, 8 Jul 87 21:36:35 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8707090436.AA04024@bhopal.edsel.uucp>
To: navajo!mab%mind.Princeton.EDU@navajo.stanford.edu
Cc: navajo!common-lisp%sail.stanford.edu@navajo.stanford.edu
In-Reply-To: Marie Bienkowski's message of Thu, 2 Jul 87 08:36:08 edt
Subject: Loop Macro (after Zetalisp, franz, etc.)

A MacLisp/Zetalisp LOOP facility is ready for "beta testing" in the Lucid 2.1
image; it is not a standard part of the 2.1 release, but can be obtained as a 
set of loadable files.

It may be possible to retro-fit the "beta" LOOP for the 2.0 image also.

-- JonL --

∂09-Jul-87  0358	sidney%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Atoms in association lists    
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Jul 87  03:58:21 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 9 Jul 87 06:58-EDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by LIVE-OAK.LCS.MIT.EDU.ARPA via DIAL with SMTP id 50791; 9 Jul 87 06:58:16-EDT
Date: Thu, 9 Jul 87 06:05 EDT
From: sidney%acorn@oak.lcs.mit.edu
Subject: Atoms in association lists
To: krall%pp@mcc.com
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8707061637.AA02959@pp.mcc.com>
Message-ID: <870709060531.1.SIDNEY@ACORN.Gold-Hill.DialNet.Symbolics.COM>

The behavior of assoc in current versions of Gold Hill's GCLISP is
to not signal an error when it encounters an atom in an alist. It is not
a matter of evaluating the car of an atom as nil, thus
  (assoc nil '((a   1) b (nil 5)) => (nil 5)

This behavior is a deficiency in the error checking, even if technically
not a bug. It is not an intentional interpretation of the standard.
GCLISP v3.0, our first version which fully conforms to CLtL, corrects
this.

-- sidney markowitz <sidney%acorn@oak.lcs.mit.edu>
   Gold Hill Computers

∂09-Jul-87  0359	sidney%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: Atoms in association lists
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Jul 87  03:59:32 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 9 Jul 87 06:59-EDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by LIVE-OAK.LCS.MIT.EDU.ARPA via DIAL with SMTP id 50792; 9 Jul 87 06:58:34-EDT
Date: Thu, 9 Jul 87 06:23 EDT
From: sidney%acorn@oak.lcs.mit.edu
Subject: Re: Atoms in association lists
To: dml@NADC.ARPA
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8707081900.AA11071@NADC.ARPA>
Message-ID: <870709062325.2.SIDNEY@ACORN.Gold-Hill.DialNet.Symbolics.COM>


   Actually, GCLisp handles atoms in alists by ignoring them,
   whether they are strings, NIL, or other symbols.  E.g.,

   (SETQ abc '(c (c . 3) NIL (NIL . 4)))
   (ASSOC 'c abc) --> (c . 3)
   (ASSOC nil abc) --> (NIL . 4)

   This is in accordance with CLtL, I believe.

   David Loewenstern
--------
Since NIL is a list as well as an atom and (car NIL) => NIL
the correct result is
   (assoc NIL '((c . 3) NIL (NIL . 4))) => NIL

The version of GCLisp I work with (2.4) evaluates it correctly. If an
earlier version does return (NIL . 4) then it is a bug. (I didn't try it
on any earlier versions.)

-- sidney markowitz <sidney%acorn@oak.mit.edu>
   Gold Hill Computers

∂09-Jul-87  0452	@DIAMOND.S4CC.Symbolics.COM:Cyphers@YUKON.SCRC.Symbolics.COM 	Re: Atoms in association lists   
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 9 Jul 87  04:52:04 PDT
Received: from RAVEN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 103750; Thu 9-Jul-87 07:50:39 EDT
Date: Thu, 9 Jul 87 07:49 EDT
From: Scott Cyphers <Cyphers@YUKON.SCRC.Symbolics.COM>
Subject: Re: Atoms in association lists
To: sidney%acorn@oak.lcs.mit.edu, dml@NADC.ARPA
cc: common-lisp@sail.stanford.edu
In-Reply-To: <870709062325.2.SIDNEY@ACORN.Gold-Hill.DialNet.Symbolics.COM>
Message-ID: <870709074958.7.CYPHERS@RAVEN.S4CC.Symbolics.COM>

    Date: Thu, 9 Jul 87 06:23 EDT
    From: sidney%acorn@oak.lcs.mit.edu


       Actually, GCLisp handles atoms in alists by ignoring them,
       whether they are strings, NIL, or other symbols.  E.g.,

       (SETQ abc '(c (c . 3) NIL (NIL . 4)))
       (ASSOC 'c abc) --> (c . 3)
       (ASSOC nil abc) --> (NIL . 4)

       This is in accordance with CLtL, I believe.

       David Loewenstern
    --------
    Since NIL is a list

But NIL is not a cons.  See page 281 of CLtL.

 as well as an atom and (car NIL) => NIL
    the correct result is
       (assoc NIL '((c . 3) NIL (NIL . 4))) => NIL

(NIL . 4) should be returned, as someone stated earlier.

    The version of GCLisp I work with (2.4) evaluates it correctly. If an
    earlier version does return (NIL . 4) then it is a bug. (I didn't try it
    on any earlier versions.)

    -- sidney markowitz <sidney%acorn@oak.mit.edu>
       Gold Hill Computers


∂09-Jul-87  0521	thoms@caen.engin.umich.edu 	OPS5   
Received: from CAEN.ENGIN.UMICH.EDU by SAIL.STANFORD.EDU with TCP; 9 Jul 87  05:21:01 PDT
Received: by caen.engin.umich.edu (5.31/umix-2.0)
	id AA00351; Thu, 9 Jul 87 08:04:05 EDT
Date: Thu, 9 Jul 87 08:04:05 EDT
From: thoms@caen.engin.umich.edu (Dale E Thoms)
Message-Id: <8707091204.AA00351@caen.engin.umich.edu>
To: common-lisp@sail.stanford.edu
Subject: OPS5


   Does anyone know of an OPS5 interpreter written
in CommonLisp?  Any information you could give me
would be much appreciated.
  My net address is:
    
     thoms@caen.engin.umich.edu

  Thanks,
 
  Dale Thoms
  EECS Department
  University of Michigan
  

∂09-Jul-87  0546	dml@NADC.ARPA 	Re: Atoms in association lists
Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jul 87  05:45:49 PDT
Received: by NADC.ARPA (5.51/1.0 )
	id AA05017; Thu, 9 Jul 87 08:45:29 EDT
Date: Thu, 9 Jul 87 08:45:29 EDT
From: dml@nadc.arpa (D. Loewenstern)
Message-Id: <8707091245.AA05017@NADC.ARPA>
To: dml@NADC.ARPA, sidney%acorn@LIVE-OAK.LCS.MIT.EDU
Subject: Re: Atoms in association lists
Cc: common-lisp@sail.stanford.edu

1) Version 2.2, LM performs as I stated.  I don't have 2.4.  Personally,
I prefer this performance.

2) CLtL, p.281, "if NIL appears in the a-list in place of a pair ... ASSOC 
will ignore the NIL in the a-list and continue to search for an actual 
pair (cons) whose car is NIL."

If 2.4 returns NIL, then it is a bug.

∂09-Jul-87  0621	dml@NADC.ARPA 	Plists and NIL.
Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jul 87  06:18:35 PDT
Received: by NADC.ARPA (5.51/1.0 )
	id AA06374; Thu, 9 Jul 87 09:16:07 EDT
Date: Thu, 9 Jul 87 09:16:07 EDT
From: dml@nadc.arpa (D. Loewenstern)
Message-Id: <8707091316.AA06374@NADC.ARPA>
To: common-lisp@sail.stanford.edu
Subject: Plists and NIL.
Cc: dml@NADC.ARPA

1) NIL is a symbol.  Like all symbols, it has a plist (see CLtL p.4 for an 

example).



2) NIL is a list.



Therefore, does (SETQ z NIL)

                (SETF (GETF z :a) :b)

                z



return NIL or (:a :b)? (That is, does the property go on NIL's plist or

directly into the list referenced by z?)



Golden Common LISP (ver. 2.2LM) resolves this by having no plist on NIL.  I 

consider this a bug, however.



David Loewenstern

<dml@nadc>

∂09-Jul-87  0919	johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK 	kcl   
Received: from CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 9 Jul 87  09:18:45 PDT
Received: from cvaxa.sussex.ac.uk by nss.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa11401; 9 Jul 87 17:13 BST
From: John Williams <johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK>
Date: Thu, 9 Jul 87 16:58:14 gmt
Message-Id: <27802.8707091658@cvaxa.sussex.ac.uk>
To: common-lisp@sail.stanford.edu
Subject: kcl


Does anyone know of a UK distrubtion point for Kyoto Common Lisp ?
I have a licence that has been approved by Kyoto U; but can't FTP 
the sources from the US as described in an earlier posting.
Many thanks,

john

∂09-Jul-87  0930	@RELAY.CS.NET:hagiya%kurims.kurims.kyoto-u.junet@UTOKYO-RELAY.CSNET 	Re: Flavors for KCL  
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 9 Jul 87  09:30:28 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac09037; 9 Jul 87 12:18 EDT
Received: from utokyo-relay by RELAY.CS.NET id am10711; 9 Jul 87 12:12 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
	id AA26575; Fri, 10 Jul 87 00:38:41 JST
Received: by titcca.cc.titech.junet (4.12/6.2Junet)
	id AA26856; Fri, 10 Jul 87 00:11:36 jst
Received: by nttlab.NTT (4.12/6.2NTT.f) with TCP; Thu, 9 Jul 87 19:43:30 jst
Received: by kuis.kuis.kyoto-u.junet (2.0/6.2Junet)
	id AA14586; Thu, 9 Jul 87 12:33:01 jst
Received: by kurims.kurims.kyoto-u.junet (3.2/6.2Junet)
	id AA00314; Thu, 9 Jul 87 10:15:33 JST
Date: Thu, 9 Jul 87 10:15:33 JST
From: Masami Hagiya <hagiya%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <hagiya@kurims.kurims.kyoto-u.junet>
Message-Id: <8707090115.AA00314@kurims.kurims.kyoto-u.junet>
To: common-lisp@SAIL.STANFORD.EDU
Subject: Re: Flavors for KCL

    Mr. Hagiya, one of the implementors of KCL ported the Flavors system
    to KCL.  This Flavors was originally written in Franz Lisp by Franz
    Inc.  Please contact him if you are interested.  His E-mail address is

          hagiya%kurims.kurims.kyoto-u.junet%japan.csnet@relay.cs.net

    - Gitchang -

What I obtained from Franz (directly from the president) is the
so called Old Flavors, which is in the public domain, and which
is different from Franz's Flavors or Symbolics' New Flavors.

Gitchang's comment is not correct in that I did not port Old Flavors
to KCL, but my collegue Yuasa did.  Moreover, since Old Flavors is
written in dynamically scoped Lisp, he could not completely port it
to KCL.  As he is not satisfied with the result, he does not want
to give the code away.

If you are interested in obtaining the code, try to persuade him.

-- Masami Hagiya

∂09-Jul-87  1118	jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	UK KCL    
Received: from CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 9 Jul 87  11:17:21 PDT
Received: from aiva.edinburgh.ac.uk by nss.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa13164; 9 Jul 87 18:53 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Thu, 9 Jul 87 18:52:11 -0100
Message-Id: <29800.8707091752@aiva.ed.ac.uk>
To: johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK
Subject: UK KCL
Cc: common-lisp@sail.stanford.edu

We have a copy at Edinburgh that we are able to redistribute under the same
conditions as U-Texas (that is, one must send in the license forms first),
but it has not yet put it in place for ftp from outside the local ethernet.
That will happen any day now, once certain admin. details have been dealt
with.  Instructions for obtaining a copy will be posted in the UK at that
time.

-- Jeff

∂09-Jul-87  1207	AI.BOYER@MCC.COM 	Re: kcl
Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 9 Jul 87  12:07:01 PDT
Date: Thu 9 Jul 87 14:03:42-CDT
From:  Bob Boyer <AI.BOYER@MCC.COM>
Subject: Re: kcl
To: johnw%cvaxa.sussex.ac.uk@NSS.CS.UCL.AC.UK
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <27802.8707091658@cvaxa.sussex.ac.uk>
Message-ID: <12317044043.39.AI.BOYER@MCC.COM>

ajcole%ai.leeds.ac.uk@Cs.Ucl.AC.UK has a copy and may help
you out.
-------

∂09-Jul-87  1207	Daniels.pa@Xerox.COM 	Re: Plists and NIL.    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Jul 87  12:07:14 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUL 87 11:35:19 PDT
Date: 9 Jul 87 11:34 PDT
From: Daniels.pa@Xerox.COM
Subject: Re: Plists and NIL.
In-reply-to: dml@nadc.arpa (D. Loewenstern)'s message of Thu, 9 Jul 87
 09:16:07 EDT
To: dml@nadc.arpa
cc: common-lisp@sail.stanford.edu
Message-ID: <870709-113519-4138@Xerox>

You seem to be confused. GETF always operates on an immediate plist,
unlike GET, which operates on the plist of a given symbol. Thus (GETF Z
:A) always refers to the plist that is the value of the variable Z.
Whether or not NIL is a symbol or has a plist does not enter into the
picture. The correct result of 

  (setq z ())
  (setf (getf z :a) :b)
  z

is the list (:a :b).

		-- Andy. --

∂09-Jul-87  1208	vax135!lcuxle!elia@ucbvax.Berkeley.EDU 	macrolet  
Received: from UCBVAX.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 9 Jul 87  12:08:24 PDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
	id AA24651; Thu, 9 Jul 87 10:21:07 PDT
Received: by lcuxle.UUCP (4.6/4.2)
	id AA03351; Thu, 9 Jul 87 13:04:27 EDT
Date: Thu, 9 Jul 87 13:04:27 EDT
From: vax135!lcuxle!elia@ucbvax.Berkeley.EDU (Weixelbaum Elia)
Message-Id: <8707091704.AA03351@lcuxle.UUCP>
To: common-lisp@sail.stanford.edu
Subject: macrolet

When I read the explanation for macrolet on page 114, Cltl, I had a few
problems with the 'clear' example:

(defun foo (x flag)
  (macrolet ((fudge (z)
		;The parameters x and flag are not accessible
		;at this point; a reference to flag would be to
		;the global variable of that name.
		`(if flag (* ,z ,z) ,z)))
	;The parameters x and flag are accessible here.
	(+ x
	   (fudge x)
	   (fudge (+ x 1)))))

It seems that while this is a valid example, it does not emphasize the
point that is trying to be made.  While 'fudge' is being defined foo's
flag is not accessible, but since flag is quoted inside of fudge, by
the time that the body of the macrolet is run, i.e., in (+ x ...),
flag is accessible.  Therefore if I run

(setq flag t) ==> t
(foo 10 nil) ==> 31 (since flag is taken as nil).

A more illustrative example might be to change the body of fudge to:

`(if ,flag (* ,z ,z) ,z)	; Evaluate flag within macro expansion

Now, by running

(setq flag t) ==> t
(foo 10 nil) ==> 231 (since flag is taken as t).

Elia Weixelbaum

∂09-Jul-87  1404	berman@vaxa.isi.edu 	Validation suite   
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 9 Jul 87  14:04:28 PDT
Posted-Date: Thu, 09 Jul 87 14:04:38 PDT
Message-Id: <8707092104.AA04144@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
	id AA04144; Thu, 9 Jul 87 14:04:40 PDT
To: common-lisp@sail.stanford.edu
Subject: Validation suite
Date: Thu, 09 Jul 87 14:04:38 PDT
From: Richard Berman <berman@vaxa.isi.edu>


From the recent X3 committee meeting, it was gathered that, despite having
posted several messages recently to CL-VALIDATION, it is apparent that even
some people who subscribe to that mailing list haven't received my messages
regarding the available common lisp test suite.

Perhaps that mailing list is broken??

The only people that I know for sure have recieved copies of the test suite
(which is available anonomous FTP from VENERA.ISI.EDU) are those who asked me
directly for copies, and I gave them the information on where to find it.  

If you need this information, get on the CL-VALIDATION mailing list.  If you
ARE on it and you haven't received my messages, let Dick Gabriel know.  If you
have received my messages, please send me note to that effect.

Rather than burden everyone with the full messages, send me a note if you want
the info on the validation suite.  And get on CL-VALIDATION.

RB

∂09-Jul-87  1856	STEVER%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	Plists and NIL.   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Jul 87  18:56:42 PDT
Date: Thu, 9 Jul 1987  21:59 EDT
Message-ID: <STEVER.12317119678.BABYL@MIT-OZ>
From: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To:   dml@NADC.ARPA (D. Loewenstern)
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: Plists and NIL.
In-reply-to: Msg of 9 Jul 1987  09:16-EDT from dml at nadc.arpa (D. Loewenstern)

    Date: Thursday, 9 July 1987  09:16-EDT
    From: dml at nadc.arpa (D. Loewenstern)

    1) NIL is a symbol.  Like all symbols, it has a plist (see CLtL p.4 for an 
    example).

    2) NIL is a list.

    Therefore, does (SETQ z NIL)

                    (SETF (GETF z :a) :b)

                    z

    return NIL or (:a :b)? (That is, does the property go on NIL's plist or
    directly into the list referenced by z?)

It goes into the list referenced by Z.  Your question seems to imply
an extra level of evaluation, which doesn't occur with GETF.

LISP is wonderful.  It lets you say the same thing many ways.
Here are some incantations and what they do (according to Steele
and DEC-20 Common Lisp I'm using):

These change NIL's property list:
  (SETQ Z NIL)
  (SETF (GET Z :A) :B)
     or
  (SETF (GETF (SYMBOL-PLIST 'NIL) :A) :B)
     or
  (SETF (GET 'NIL :A) :B)
  Note:  (SETF (GETF Z :A) :B) gives Z the value (:A :B)

This attempts to change NIL's value:
  (SETF (GETF NIL :A) :B)

These retrieve properties from NIL's property list:
  (SETQ Z NIL)
  (GET Z :A)
    or
  (GETF (SYMBOL-PLIST 'NIL) :A)
    or
  (GET 'NIL :A)
  Note:  (GETF Z :A) returns NIL (since Z contains an empty
		     propert list)


- Stephen

∂10-Jul-87  0809	sandra%orion@cs.utah.edu 	special forms 
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 10 Jul 87  08:09:27 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
	id AA26840; Fri, 10 Jul 87 09:11:41 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
	id AA05214; Fri, 10 Jul 87 09:11:37 MDT
Date: Fri, 10 Jul 87 09:11:37 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8707101511.AA05214@orion.utah.edu>
Subject: special forms
To: common-lisp@sail.stanford.edu

Is it legit to implement a CL special form as a macro that expands into
an implementation-specific special form?  (For example, making FUNCTION
expand into a CLOSURE form in some circumstances.)  I do not think this
would cause problems for code-walkers that use the procedure described
on p. 57, since the code-walker is expected to have its own handling
for all of the CL special forms and should never try to macroexpand
them.  Assuming this is allowed, should SPECIAL-FORM-P be true of the
implementation-specific special forms or only those listed in CLtL?

-Sandra
-------

∂10-Jul-87  0942	RAM@C.CS.CMU.EDU 	special forms    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Jul 87  09:42:03 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Fri 10 Jul 87 12:40:45-EDT
Date: Fri, 10 Jul 1987  12:40 EDT
Message-ID: <RAM.12317280147.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To:   sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: special forms
In-reply-to: Msg of 10 Jul 1987  11:11-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore)


Well, the implementation note on 58 implies that standard macros are
allowed to expand into implementation-dependent special forms.  In
combination with the premission on 57 to implement special forms as
macros, this suggests that it is legal for special forms to be
implemented as macros that expand into implementation-dependent
special forms.

I am pretty certain that special forms, both standard and
implementation dependent, should be special-form-p.  It is true that
it doesn't help a code walker much to know it has tripped over a
special form it doesn't know about, but at least it can fail
gracefully instead of treating random syntax as being evaluated forms.

Having said this, I encourage you to avoid using implementation
dependent special forms.  In all the cases I have come across,
expanding into a function call works just as well.  You just stick in
"'" and "#'" as necessary to prevent stuff from being evaluated.  The
compiler can still special-case these "funny functions" in arbitrary
ways, but they obey function syntax, and thus make life easy for
people who don't care.

  Rob

∂10-Jul-87  1116	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Appropriate use of the Common-Lisp mailing list  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jul 87  11:16:09 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 190963; Thu 9-Jul-87 21:53:46 EDT
Date: Thu, 9 Jul 87 21:53 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Appropriate use of the Common-Lisp mailing list
To: Common-Lisp@SAIL.STANFORD.EDU
Message-ID: <870709215332.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

The mailing list Common-Lisp@SAIL.STANFORD.EDU was created as a
communication path between the Common-Lisp designers. Since its
creation, a number of `outsiders' have asked to be added and the list
has grown to enormous proportions.

While we have allowed such `auditing' of this discussion, and while such
`auditors' have occassionally contributed usefully to the discussion,
please keep in mind that every message sent to this list takes a large
amount of CPU time on dozens of machines to deliver, a large amount of
disk space to deliver and archive, and ultimately reaches hundreds of
people, most of whom are probably very busy.

I don't wish to sound elitist, but this list is of little value to me or
the other Common-Lisp designers if the quality of conversation which
crosses it is not very high. It is not intended as a free consulting
service for us to bring novices up to speed; we just don't have the time.

If you think you have something to "contribute" but you've never
implemented a lisp or you don't have many years of experience in
serious Lisp programming, please think twice or talk it over with an
expert before asking a question of this large community which could as
easily have been answered by an individual. You can save the community
much time, disk space, work, and ultimately money -- and you can save
yourself some embarrassment.

Thanks very much for your time and cooperation.
 -kmp

∂10-Jul-87  1116	KMP@STONY-BROOK.SCRC.Symbolics.COM 	macrolet 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jul 87  11:16:41 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 190967; Thu 9-Jul-87 22:16:49 EDT
Date: Thu, 9 Jul 87 22:16 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: macrolet
To: vax135!lcuxle!elia@ucbvax.Berkeley.EDU
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <8707091704.AA03351@lcuxle.UUCP>
Message-ID: <870709221637.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

[Aside: I don't think the purpose of the Common-Lisp list is to discuss
 the choice of examples in an already published book, except perhaps,
 in some cases where such examples are erroneous, misleading or
 contradictory. I don't think this is such a case. Personally, I think
 this would have been a good issue on which to get some private help
 rather than sending mail to this list.]

    Date: Thu, 9 Jul 87 13:04:27 EDT
    From: vax135!lcuxle!elia@ucbvax.Berkeley.EDU (Weixelbaum Elia)

    When I read the explanation for macrolet on page 114, Cltl, I had a few
    problems with the 'clear' example:

    (defun foo (x flag)
      (macrolet ((fudge (z) ... `(if flag (* ,z ,z) ,z))) ...))
    ...
    (setq flag t) ==> t
    (foo 10 nil) ==> 31 (since flag is taken as nil).

    A more illustrative example might be to change the body of fudge to:

    `(if ,flag (* ,z ,z) ,z)	; Evaluate flag within macro expansion
    ...

Your "fixed" code above fails to proclaim FLAG special. (Also, being
special CLtL suggests the variable be called *FLAG* unless you have a
compelling reason not to name it so.) Using DEFPARAMETER (or DEFVAR)
rather than SETQ to set FLAG would have accomplished this.

But more importantly, you have confused compilation time with load time.
The SETQ (or even the DEFPARAMETER initialization) will not take place
until the code is loaded, which is generally -after- the macro has
expanded (except in the special case of interactive use, such as you
probably did to test your example). You would have to have written the
SETQ, DEFVAR, or DEFPARAMETER inside (EVAL-WHEN (EVAL COMPILE) ...) to
assure that the assignment happened at the right time (ie, before the
macroexpansion).

I won't bother to address the issue that your suggested rewrite didn't
include the removal of the FLAG variable (which is now unused) and the
resulting visual confusion which might ensue from having a function bind
a variable and then not refer to it while at the same time referring to
a variable by the same name evaluated in some other context.

All this aside, however, the code you suggest is not in a style that I
think I would encourage people to use. The need to use global state is
lamentable but often necessary. The use of compile time global state is
even trickier and more to be avoided whenever possible just because of
the confusion that can result about whether the compile time and runtime
environment are the same or not. This varies a lot from dialect to
dialect and is an easy place for code portability to be impacted.
Encouraging a style which is likely to lead to trouble in portable
programming is probably not wise. The example on p114 does not
illustrate the full power of macrolet, but it does illustrate a fairly
typical example of the way in which it is intended to be used, and
that's what's important.

∂10-Jul-87  1127	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Plists and NIL.    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jul 87  11:26:59 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191277; Fri 10-Jul-87 14:26:06 EDT
Date: Fri, 10 Jul 87 14:25 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Plists and NIL.
To: dml@NADC.ARPA
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <8707091316.AA06374@NADC.ARPA>
Message-ID: <870710142547.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Thu, 9 Jul 87 09:16:07 EDT
    From: dml@nadc.arpa (D. Loewenstern)

    1) NIL is a symbol.  Like all symbols, it has a plist
       (see CLtL p.4 for an example).

Correct.

    2) NIL is a list.

Correct.

    Therefore, does (SETQ z NIL)
		    (SETF (GETF z :a) :b)
		    z
    return NIL or (:a :b)?

If you're having to ask this question, you must be confusing GET and GETF.
GETF operates on the plist-format list which is returned by the place named
in its first argument position. In the case you've described where Z
contains the empty list,
 (SETF (GETF z :a) :b)
is equivalent to
 (SETQ z (LIST* :a :b z))
CLtL is unambiguous on that Z should contain (:A :B) after the series
of operations you're asking about.

    (That is, does the property go on NIL's plist or directly into the list
    referenced by z?)

Quoting from p166 in the first line of the description of GETF:
 ``... searches the property list store in <place> ..."
The description of generalized variables on pp93-94 is adequate to allow you
to interpret this, but just to be clear: A place is a form which if evaluated
would access a location. Something is in a place if it would be yield by
evaluating that place. the result of evaluating Z is NIL. Z is the place,
NIL is the something that is in the place Z. The thing which is searched is
the NIL. Updating a place means causing future accesses to that place, Z, to
yield an updated value. SETF does such updating. The thing which is updated
in the case of (SETF (GETF z ...) ...) is Z since Z is the thing whose contents
are searched by GETF.

    Golden Common LISP (ver. 2.2LM) resolves this by having no plist on NIL.
    I consider this a bug, however.
    David Loewenstern <dml@nadc>

It may be that GCLISP doesn't have a plist of NIL. My guess without doing the
requisite research is that this is a bug, but you should take it up with them,
not with the whole Common-Lisp community.

In any case, the question of whether or not NIL has a plist has no
bearing on the question of what GETF does, except in the special case
which you did not mention where (GETF (SYMBOL-PLIST sym) ...) is done.
(The description of GET is quite clear on this at the top of p165 where
it actually makes this equivalence.) Even here, there is no ambiguity
because here it is clear that you search the SYMBOL-PLIST cell:

 (GETF Z 'indicator) looks in the value Z. (SETF (GETF Z 'indicator) 'value)
 sets the value of Z an appropriate value so that subsequent calls to 
 (GETF Z 'indicator) will yield the VALUE.

 (GET 'Z 'indicator) or (GETF (SYMBOL-PLIST 'Z) 'indicator) looks in the
 symbol-plist of the symbol Z. (SETF (GET 'Z 'indicator) 'value) or
 (SETF (GETF (SYMBOL-PLIST 'Z) 'indicator) 'value) sets the symbol-plist
 of the symbol Z to an appropriate value so that subsequent calls to
 (GET 'Z 'indicator) or (GETF (SYMBOL-PLIST 'Z) 'indicator) will yield
 VALUE. 

By the way, the telltale quotes all through the second paragraph should
be the give-away that Z is being manipulated as a symbol, not a variable.
As a symbol, accesses to it as a slot are typically the standard mode of
interaction. As a variable, references to its value are typically the
standard mode of interaction.

In my opinion, it is appropriate to bring to the attention of this
community situations in which two different vendors make the claim that
there is a unique interpretation to a passage of CLtL and where those
interpretations are not in agreement. I do not believe this is such a case.
I think that all implementors are in agreement and I think you need to do
your homework better. I'm sure your Gold Hill service representative would
have been happy to provide you with this information if you'd gone to
him/her before coming to us.

∂14-Jul-87  0816	kempf%hplabsz@hplabs.HP.COM 	Re:  Appropriate use of the Common-Lisp mailing list    
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 14 Jul 87  08:16:37 PDT
Received: from hplms1 by hplabs.HP.COM with TCP ; Tue, 14 Jul 87 08:14:33 pdt
Received: from hplabsz.hpl.hp.com by hplms1; Tue, 14 Jul 87 08:14:10 pdt
Return-Path: <kempf@hplabsz.hpl.hp.com>
Received: by hplabsz; Tue, 14 Jul 87 08:14:52 pdt
Date: Tue, 14 Jul 87 08:14:52 pdt
From: Jim Kempf <kempf%hplabsz@hplabs.HP.COM>
Message-Id: <8707141514.AA25943@hplabsz.hpl.hp.com>
To: @SAIL.STANFORD.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM,
        Common-Lisp@SAIL.STANFORD.EDU
Subject: Re:  Appropriate use of the Common-Lisp mailing list

While I understand the motivation behind this note, I belive a more fruitful
approach would be to provide a forum for novices to post questions, rather
than chiding them for posting their questions to the only forum they perhaps
know about. I personally believe that Common Lisp is generally useful enough
as a language that information about how to use it should not become the
property of an "elitist" club, but rather should be available to all. 
Electronic bboards are one of the most effective and timely means of 
dissemintating such information.

I agree, in addition, that there should be a forum for experts, where
serious design questions can be posted, particularly with regard to
enhancements and fixes needed as a result of the standardization process.

For those users who have access to UN*X notes, a more appropriate forum
for novice questions might be the notes group comp.lang.lisp. Traffic
in this group is generally light, and mostly of the nature of "Where
can I find <unbound> implementation" or "Does anyone have experience
with <unbound> implementation"  rather than questions about how to
the use the language. This is in contrast to the groups on C and
other languages, where such questions form the bulk of the notes.

Therefore, perhaps a better suggestion would be to use comp.lang.lisp
for specific questions about how to use the language, and save
this group for design questions on the language itself. Those users
who don't have a UN*X notes feed will, unfortunately, have a problem,
but notes feeds are easy to get.

Additionally, as Ken pointed out in the base note, local experts (providing
they are available) are generally even more effective than bboards, and
books are approprate for getting the bigger picture.

	Jim Kempf	kempf@hplabs.hp.com

∂14-Jul-87  0922	skh@spice.cs.cmu.edu 	Apropos case sensitive?
Received: from SPICE.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Jul 87  09:22:04 PDT
Date: 14 Jul 1987 12:03-EDT 
From: Steve.Handerson@spice.cs.cmu.edu
To: Common-Lisp@SAIL.STANFORD.EDU
Subject: Apropos case sensitive?
Message-Id: <553277038/skh@spice.cs.cmu.edu>

Sorry if this has already been decided, but I've been using
lucid, which has a case-sensitive apropos, and think it's
*the wrong thing*.

It's easy to write a case-sensitive apropos using a case-sensitive one,
but to do the reverse you're effectively rewriting apropos.

What if some mad C hacker was writing code for you?
"Oh yeah, apropos foo."
Did he mean FOO, Foo, or foo?  Or maybe (gasp) fOO?

-- STeVe

∂14-Jul-87  0929	@MCC.COM:root%bell.cad.mcc.com@mcc.com 	Test - Please ignore
Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 14 Jul 87  09:29:52 PDT
Received: from bell by MCC.COM with TCP; Tue 14 Jul 87 11:29:10-CDT
Date: Tue, 14 Jul 87 11:28:07 CDT
From: Self-Deluded Demigod <root%bell.cad.mcc.com@mcc.com>
Posted-Date: Tue, 14 Jul 87 11:28:07 CDT
Message-Id: <8707141628.AA05857@bell>
Received: by bell (5.51/CAD) 
	id AA05857; Tue, 14 Jul 87 11:28:07 CDT
To: common-lisp@sail.stanford.edu
Subject: Test - Please ignore
Cc: arisco%bell.cad.mcc.com@mcc.com

This is only a test.  Please excuse the intrusion.

∂14-Jul-87  1946	vrotney@venera.isi.edu 	Re: Apropos case sensitive?    
Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 14 Jul 87  19:46:29 PDT
Posted-Date: Tue, 14 Jul 87  19:45:12 PDT
Received: from hpai00.isi.edu by venera.isi.edu (5.54/5.51)
	id AA22941; Tue, 14 Jul 87 19:46:42 PDT
Received: by hpai00 ; Tue, 14 Jul 87 19:45:27 pdt
From: vrotney@venera.isi.edu
Message-Id: <8707150245.AA03095@hpai00>
Date: Tue, 14 Jul 87  19:45:12 PDT
Subject: Re: Apropos case sensitive?
To: Common-Lisp@sail.stanford.edu
In-Reply-To: Your message of 14-Jul-87  12:03:00
X-Mailer: NMail [$Revision: 2.6 $]

re:
--------------------------------------------------------------------------------
From:  Steve.Handerson@spice.cs.cmu.edu

Sorry if this has already been decided, but I've been using
lucid, which has a case-sensitive apropos, and think it's
*the wrong thing*.
--------------------------------------------------------------------------------

I think lucid is doing the right thing according to CLTL. CLTL  says

	"(apropos [italics]string) tries to find all available symbols
	  whose print name contains [italics]string as a substring."

Since we are dealing  with  strings, I take  "substring"  here to mean
case  sensitive. For example  (string= "FOO" "foo") => NIL. If this is
what CLTL says however (clarification  please) then two points need to
made.  (1.)  There  are  other CL   implementations    that  do a case
INSENSATIVE   apropos.   (2.)   The  traditional   apropos  did a case
INSENSATIVE  comparison and I find this to be a generally  more useful
one.

It would have been better (I think) if CLTL had specified EXACTLY that
if  apropos  was  given a string  as an  argument  it  would  do  case
sensitive,  and if given a  symbol  it  would  do  case   insensative.
Because,  on an  implementation  that does a strictly  speaking  "case
sensitive  apropos"  then  (apropos  'foo)  should not  print  out the
function  who's print name is "foo" since the print name of the symbol
'foo is "FOO".
-------

∂15-Jul-87  2313	@RELAY.CS.NET:HELLER@cs.umass.edu 	RE: Apropos case sensitive?   
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 15 Jul 87  23:12:53 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa23577; 16 Jul 87 2:07 EDT
Received: from cs.umass.edu by RELAY.CS.NET id ad02188; 16 Jul 87 1:57 EDT
Date: Wed, 15 Jul 87 08:51 EDT
From: Stride 440 User <HELLER%cs.umass.edu@RELAY.CS.NET>
Subject: RE: Apropos case sensitive?
To: Common-LISP@SAIL.STANFORD.EDU
X-VMS-To: IN%"Common-LISP@sail.stanford.edu"

I too think Lucid's case-sensitive apropos is wrong. After all, APROPOS is
searching SYMBOL print-names for substring matches. In Common LISP, symbol
print-names get converted to uppercase (unless enclosed with vertical bars
or backslashed or "manually" created with intern). Thus (unless you make
heavy use either vertical bars or backslashes), most of the print-names of
the symbols typed in (or loaded from files) by users will have all uppercase
names. Since most people using Common LISP are probably not using caps only
terminals (such as the Teletype Model 33) or have the Caps-Lock key down,
they will be entering expressions (either in files or interactively) using
mostly lowercase letters. While it is posible to allways pass a SYMBOL to
apropos, this has the side affect of actually creating a symbol which will
match the symbol(s) sought (the one passed as the argument to apropos). This
is probably tolerable (although posibly confusing to novices) for
interactive queries. It can cause problems with functions using apropos-list
(functions which do something to all symbols which have some special
character sequence in them).

The apropos function on both of the other Common LISPs I have used (DEC
VAX/VMS VAX-LISP and TI Explorer LISP) is case-insensitive.  In fact when I
had need to mess with Lucid LISP on a loaner SUN, I put the case-insensitive
version of apropos into the function slot of apropos in my init file (and
later into the saved system).

Also, there is in Common LISP a case-insensitve string compare function:
EQUALP.  (EQUALP "FOO" "foo") => T (last example, page 82 of CLtL).

		Robert Heller
ARPANet:	Heller@CS.UMass.EDU
BITNET:		Heller@UMass.BITNET
BIX:		Heller
GEnie:		RHeller
FidoNet:	321/148 (Locks Hill BBS, Wendell, MA)
CompuServe	71450,3432
Local PV VAXen:	COINS::HELLER
UCC Cyber/DG:	Heller@CS

∂16-Jul-87  0624	kanya@caen.engin.umich.edu 	Prolog 
Received: from CAEN.ENGIN.UMICH.EDU by SAIL.STANFORD.EDU with TCP; 16 Jul 87  06:24:49 PDT
Received: by caen.engin.umich.edu (5.31/umix-2.0)
	id AA01050; Thu, 16 Jul 87 09:09:39 EDT
Date: Thu, 16 Jul 87 09:09:39 EDT
From: kanya@caen.engin.umich.edu (Kanya Likanasudh)
Message-Id: <8707161309.AA01050@caen.engin.umich.edu>
To: common-LISP@sail.stanford.edu
Subject: Prolog

  Does anyone know of a Prolog interpreter written in Common Lisp?
Any information about it would be appreciated.
  My network address is:
           kanya@caen.engin.umich.edu
  Thank you.
                  -Kanya
  

∂16-Jul-87  1123	DALY@IBM.COM 	pathnames, portability, ed, eval-when, compile-file, fasl files   
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 16 Jul 87  11:23:20 PDT
Date: 16 July 1987, 10:12:53 EDT
From: Timothy Daly <DALY@ibm.com>
To:   common-lisp@sail.stanford.edu
Message-Id: <071687.101253.daly@ibm.com>
Subject: pathnames, portability, ed, eval-when, compile-file, fasl files

First question:


Is there any *portable* way to get the pathname of the file
that is currently being compiled or loaded? I would like to
be able to edit the file when an error occurs (similar to
turbo pascal).

That is, if someone types:

(compile-file ">daly>foo.lisp")

and my parser detects an error, I'd like to

(ed ">daly>foo.lisp")

but there doesn't appear to be a get-current-pathname function
defined anywhere.

Does common lisp plan to add such a function when the 'debugging
facilities' get expanded?


Actually, I'd like to be able to incant

(progn (ed ">daly>foo.lisp") (ed-search arbitrary-text-string))

which would leave the user in the editor and positioned at the error.
It appears that this could be defined in a portable manner
as every editor has a text search command.

And, dreaming on, I'd like a definition of

(ed-command arbitrary-but-implementation-dependent-editor-command)

that is, I'd like the interface syntax to the editor command handler
to be defined in a portable manner. I understand that the actual
commands to perform the manipulations would be different across
systems but I could create editor scripts and assign them to
implementation dependent variables.

Second question:

 Is there any *portable* way I can tell whether a macro is being
expanded in the compile time environment or the top level
command environment?

That is, I need to set up certain compile time information for
macros. These macros perform two functions. They generate
forms for the compiler to compile into the file and they
set up top level environment information. If they are expanded
from compile-file in the compile-time environment, they modify
the global state. If they are expanded at the top level they
create and return forms that modify the global state redundantly.

Truly tedious programming gets around this problem but one of two
possible modifications to common lisp would solve *my* problem.

First, export the state used by EVAL-WHEN so I can use it (eval-when
does not seem to be available except at the top level, thus I have
to hack a compiler:phase-1-hook property which is beyond my cutoff
point for hacking this week). If I could get at the state I could
conditionalize my code without using eval-when special forms.

The second modification would be to allow me to write into a fasl
file without using compile-file. That is,

(compile 'foo :output-file pathname :if-exists :append)

If I could write compiled objects I could create my own fasl file
definition and write something portable that would get around the
previous hacks.

tim.

DALY@IBM.COM
T. J. Watson Research Center

If I had ham, I could have ham and eggs, if I had eggs. Sigh.

∂16-Jul-87  1609	RAM@C.CS.CMU.EDU 	editor issues    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Jul 87  16:09:04 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 16 Jul 87 19:07:58-EDT
Date: Thu, 16 Jul 1987  19:07 EDT
Message-ID: <RAM.12318923506.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To:   Timothy Daly <DALY@IBM.COM>
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: editor issues
In-reply-to: Msg of 16 Jul 1987 10:12:53 EDT from Timothy Daly <DALY at ibm.com>


    Date: 16 July 1987, 10:12:53 EDT
    From: Timothy Daly <DALY at ibm.com>
    Re:   pathnames, portability, ed, eval-when, compile-file, fasl files

    Is there any *portable* way to get the pathname of the file
    that is currently being compiled or loaded?
No.

    I would like to be able to edit the file when an error occurs
    (similar to turbo pascal).

    That is, if someone types:

    (compile-file ">daly>foo.lisp")

    and my parser detects an error, I'd like to

    (ed ">daly>foo.lisp")

I think you are trying to do too much that is properly part of the
"programming environment", and inherently not portable (at least with
the current Common Lisp design goals).

A more portable alternative would be to have a SYNTAX-ERROR condition
and an EDIT proceed function, or something like that.  This would
provide a portable interface to "editing errors", if that capability
exists.

    [...] but there doesn't appear to be a get-current-pathname function
    defined anywhere.  Does common lisp plan to add such a function
    when the 'debugging facilities' get expanded?

Well, this was mentioned before, but I believe it was by you.  Unless
someone comes  up with a formal proposal that convincingly argues that
this is well-defined and useful, then it won't be adopted.  Although
you may think the semantics are obvious, it may be difficult to
clearly define.  Consider that code may be consed up and compiled
without ever having been in a file, and that code can be read from
places other than files.

    Actually, I'd like to be able to incant

    (progn (ed ">daly>foo.lisp") (ed-search arbitrary-text-string))

I think that anything of this sort is doomed in the absence of a
standard editor/environment.  As a practical matter this isn't very
important either.  Given that the editor exists and provides the
functionality you want (which Common Lisp doesn't guarantee), you can
have a trivial (but non-portable) code file that implements what you
expect in terms of what is available.

    And, dreaming on, I'd like a definition of

    (ed-command arbitrary-but-implementation-dependent-editor-command)

    that is, I'd like the interface syntax to the editor command
    handler to be defined in a portable manner.  [...] I could create
    editor scripts and assign them to implementation dependent
    variables.

This is just silly.  Your code isn't any more portable just because
the first symbol in each form is the same.  Since Lisp supports
arbitrary functional values, you can stick "editor scripts" in
variables just as easily as arbitrary code.

  Rob

∂16-Jul-87  1630	RAM@C.CS.CMU.EDU 	eval-when issues 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Jul 87  16:29:59 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 16 Jul 87 19:28:53-EDT
Date: Thu, 16 Jul 1987  19:28 EDT
Message-ID: <RAM.12318927315.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To:   Timothy Daly <DALY@IBM.COM>
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: eval-when issues
In-reply-to: Msg of 16 Jul 1987 10:12:53 EDT from Timothy Daly <DALY at ibm.com>


    Date: 16 July 1987, 10:12:53 EDT
    From: Timothy Daly <DALY at ibm.com>
    Re:   pathnames, portability, ed, eval-when, compile-file, fasl files

    [...]
    Second question:

    Is there any *portable* way I can tell whether a macro is being
    expanded in the compile time environment or the top level
    command environment?

Probably the answer is no.  A macro can do different things in these
circumstances using EVAL-WHEN, of course.  Moving on out over thin
ice, I would argue that a program that needs this information is
broken, is in error, is not Common Lisp.  The problem is that concepts
such as "at compile time" are very hard to pin down given the wide
range of legal Common Lisp implementation strategies such as "compile
only", "interpret only", and all kinds of hybrid/incremental
compilation schemes.

    That is, I need to set up certain compile time information for
    macros. These macros perform two functions. They generate
    forms for the compiler to compile into the file and they
    set up top level environment information. If they are expanded
    from compile-file in the compile-time environment, they modify
    the global state. If they are expanded at the top level they
    create and return forms that modify the global state redundantly.
    Truly tedious programming gets around this problem but one of two
    possible modifications to common lisp would solve *my* problem.

It's hard to tell what you are trying to do, but sounds like you are
writing your macros wrong.  Macroexpansion should never have
side-effects.  You should get your "compile time" side-effects by
using EVAL-WHEN.  If you put the stuff in an EVAL-WHEN (COMPILE LOAD EVAL),
then it will happen both at compile and load time, but only once when
interpreted at top-level.

    First, export the state used by EVAL-WHEN so I can use it (eval-when
    does not seem to be available except at the top level, thus I have
    to hack a compiler:phase-1-hook property which is beyond my cutoff
    point for hacking this week).

EVAL-WHEN (or equivalent) should work anywhere.  The concept of
"top-level form" doesn't belong in Common Lisp.  This is currently an
area of major lossage in the spec.  I have a compiler cleanup proposal
that replaces eval-when and banishes top-level forms.  This proposal
is supposedly being considered by the compiler cleanup committee.

    The second modification would be to allow me to write into a fasl
    file without using compile-file. That is,

    (compile 'foo :output-file pathname :if-exists :append)

Gag my with a spoon!  Hunh-uh...  No way!  fat chance, over my bloated
corpse. 

  Rob

∂17-Jul-87  1026	edsel!bhopal!jonl@labrea.stanford.edu 	Appropriate use of the Common-Lisp mailing list    
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Jul 87  10:25:56 PDT
Received: by labrea.stanford.edu; Fri, 17 Jul 87 10:23:15 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
	id AA03837; Thu, 16 Jul 87 18:32:33 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
	id AA07740; Thu, 16 Jul 87 18:36:30 PDT
Date: Thu, 16 Jul 87 18:36:30 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8707170136.AA07740@bhopal.edsel.uucp>
To: labrea!kempf.hplabsz%hplabs.HP.COM@labrea.stanford.edu,
        labrea!KMP%SCRC.Symbolics.COM@labrea.stanford.edu
Cc: labrea!Common-Lisp%SAIL@labrea.stanford.edu
In-Reply-To: Jim Kempf's message of Tue, 14 Jul 87 08:14:52 pdt <8707141514.AA25943@hplabsz.hpl.hp.com>
Subject:  Appropriate use of the Common-Lisp mailing list


[Apologies again for replying several days late -- Lucid's link, at Stanford,
to the Internet seems to have been wedged since last Friday.]

Many other forums have seen fit to divide into two mailing lists -- one for
imlementational questions and another for general "information".  A paradigm
might be the BUG-<mumble> and INFO-<mumble> lists that sprang up around
MIT years ago (but maybe they weren't so successful? I dunno).

On the other hand, I don't find the (unnanounced and informal) change in 
purpose of the Common-Lisp@SU-AI mailing list to be so bad; my reasons
for tolerating it are:
   (1) It generates *** substantially less volume ** in my mail file than 
       it did one year ago, when every apostle from the MIT-AI lab (myself
       included) who imagined he was designing the world's greatest language
       felt it necessary to publicly argue every little issue that came up.
   (2) Users, who are not implementors, frequently have a different point
       of view as to what the important issues are, and they often read
       standardized documentation in a way different from "wizards"; I want
       to remain informed as to what they are thinking.

-- JonL --



∂20-Jul-87  1132	Kahn.pa@Xerox.COM 	Re: Prolog 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Jul 87  11:32:10 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 20 JUL 87 11:30:55 PDT
Date: Mon, 20 Jul 87 11:30:41 PDT
From: Ken Kahn <Kahn.pa@Xerox.COM>
Subject: Re: Prolog
In-Reply-To: <8707161309.AA01050@caen.engin.umich.edu>
To: kanya@caen.engin.umich.edu (Kanya Likanasudh)
cc: common-LISP@sail.stanford.edu
Message-ID: <870720-113055-1588@Xerox>

I've written one called CommonLog.  Unfortunately Xerox hasn't decided
yet what to do with it.  Do you know about ZYX Prolog for HP?  What
other responses did you get to your message?

References
	kanya@caen.engin.umich.edu's message of Thu, 16 Jul 87 9:09:39 EDT --
Prolog

∂20-Jul-87  2130	edsel!bhopal!jonl@labrea.stanford.edu 	Apropos case sensitive?   
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Jul 87  21:30:39 PDT
Received: by labrea.stanford.edu; Mon, 20 Jul 87 21:25:54 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
	id AA05223; Fri, 17 Jul 87 11:45:06 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
	id AA00220; Fri, 17 Jul 87 11:49:11 PDT
Date: Fri, 17 Jul 87 11:49:11 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8707171849.AA00220@bhopal.edsel.uucp>
To: labrea!vrotney%venera.isi.edu@labrea.stanford.edu
Cc: labrea!Common-Lisp%sail@labrea.stanford.edu,
        labrea!cl-cleanup%sail@labrea.stanford.edu
In-Reply-To: vrotney@venera.isi.edu's message of Tue, 14 Jul 87  19:45:12 PDT <8707150245.AA03095@hpai00>
Subject: Apropos case sensitive?

[Note: LUCIDites are now using another mail gateway: typical address is:
       edsel!jonl@labrea.stanford.edu]

Our reasoning here at Lucid was similar to what you came up with -- namely
that the language of CLtL, p. 443, very strongly implied the same semantics
of macthing as the default for SEARCH, which is an EQL, rather than an
EQUALP, test.  

Many of us also felt the need so strongly for a case-insensitive apropos 
that Lucid Common Lisp actually has two such functions hidden inside it:
    lucid::case-insensitive-apropos
    lucid::case-insensitive-apropos-list
but they will probably be "shaken" out in the delivered 2.1 beta images.  

I feel that this issue should be presented to the "cleanup" sub-committee
of the X3J13 standards committee.  Perhaps SEF can prod Steve Handerson 
into writing up a proposal to them?  Lucid might feel impelled to "expose"
this hidden function if the committe were inclined towards the proposal.

By the way, there are some other issues about apropos that might need 
"cleaning up", some of which were discussed on this list a couple of 
years ago (for "couple" mabye equal to one).  For example, the 
documentation uses the term "available symbols", but in at least one 
instance, it ought to use "accessible symbols", for conformity to 
chapter 11 on packages.  Also, the scope of do-all-symbols has been 
questioned by some; there have been at least two proposals on it:

  (1) to add a new "function" called, say do-most-symbols, that excluded
      certain packages

  (2) to add a global variable (or a special variable) called, say,
      *all-symbols-exclusions* which is a list of packages which the
      several "all-symbols" functions would skip [e.g., do-all-symbols,
      find-all-symbols, apropos, case-insensitive-apropos, etc]


-- JonL --

∂22-Jul-87  0715	EJS%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: Atoms in association lists   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Jul 87  07:14:57 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 22 Jul 87 09:48-EDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by LIVE-OAK.LCS.MIT.EDU.ARPA via DIAL with SMTP id 52437; 22 Jul 87 10:00:27-EDT
Date: Wed, 22 Jul 87 08:59 EDT
From: EJS%acorn@oak.lcs.mit.edu
Subject: Re: Atoms in association lists
To: Cyphers@YUKON.SCRC.Symbolics.COM, sidney%acorn@oak.lcs.mit.edu,
    dml@NADC.ARPA
cc: common-lisp@sail.stanford.edu
In-Reply-To: <870709074958.7.CYPHERS@RAVEN.S4CC.Symbolics.COM>
Message-ID: <870722085942.3.EJS@ACORN.Gold-Hill.DialNet.Symbolics.COM>

    Return-path: <@OAK.Gold-Hill.DialNet.Symbolics.COM,@LIVE-OAK.LCS.MIT.EDU.ARPA,@SAIL.STANFORD.EDU.ARPA,@SAIL.STANFORD.EDU,@DIAMOND.S4CC.Symbolics.COM:Cyphers@YUKON.SCRC.Symbolics.COM>
    Received: from LIVE-OAK.LCS.MIT.EDU.ARPA (MIT-LIVE-OAK.DialNet.Symbolics.COM) by GOLD-HILL-ACORN.DialNet.Symbolics.COM via DIAL with SMTP id 74916; 9 Jul 87 09:06:26-EDT
    Received: from SAIL.STANFORD.EDU (SAIL.STANFORD.EDU.ARPA) by LIVE-OAK.LCS.MIT.EDU.ARPA via INTERNET with SMTP id 50799; 9 Jul 87 08:06:44-EDT
    Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 9 Jul 87  04:52:04 PDT
    Received: from RAVEN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 103750; Thu 9-Jul-87 07:50:39 EDT
    Date: Thu, 9 Jul 87 07:49 EDT
    From: Scott Cyphers <Cyphers@YUKON.SCRC.Symbolics.COM>
    Subject: Re: Atoms in association lists
    To: sidney%acorn@oak.lcs.mit.edu, dml@NADC.ARPA
    cc: common-lisp@sail.stanford.edu
    In-Reply-To: <870709062325.2.SIDNEY@ACORN.Gold-Hill.DialNet.Symbolics.COM>
    Message-ID: <870709074958.7.CYPHERS@RAVEN.S4CC.Symbolics.COM>

	Date: Thu, 9 Jul 87 06:23 EDT
	From: sidney%acorn@oak.lcs.mit.edu


	   Actually, GCLisp handles atoms in alists by ignoring them,
	   whether they are strings, NIL, or other symbols.  E.g.,

	   (SETQ abc '(c (c . 3) NIL (NIL . 4)))
	   (ASSOC 'c abc) --> (c . 3)
	   (ASSOC nil abc) --> (NIL . 4)

	   This is in accordance with CLtL, I believe.

	   David Loewenstern
	--------
	Since NIL is a list

    But NIL is not a cons.  See page 281 of CLtL.

     as well as an atom and (car NIL) => NIL
	the correct result is
	   (assoc NIL '((c . 3) NIL (NIL . 4))) => NIL

    (NIL . 4) should be returned, as someone stated earlier.

	The version of GCLisp I work with (2.4) evaluates it correctly. If an
	earlier version does return (NIL . 4) then it is a bug. (I didn't try it
	on any earlier versions.)

	-- sidney markowitz <sidney%acorn@oak.mit.edu>
	   Gold Hill Computers

No Sidney, I believe we are not in conformance with the spec since we fail
the specific test case mentioned in CLtL.  This is a long-reported bug for
which the bug form sits on my desk this very instance.  It is still a bug
in 2.9.3 (beta release of 3.0).

∂23-Jul-87  1222	VERACSD@A.ISI.EDU 	Toplevel lexical variables
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 87  12:22:50 PDT
Date: 23 Jul 1987 15:19-EDT
Sender: VERACSD@A.ISI.EDU
Subject: Toplevel lexical variables
From: VERACSD@A.ISI.EDU
To: common-lisp@SAIL.STANFORD.EDU
Cc: veracsd.rs@A.ISI.EDU
Message-ID: <[A.ISI.EDU]23-Jul-87 15:19:07.VERACSD>


(let ((x 1))
  (defun f ()
    x))

     According to CLtL, it seems the above should work essentially
the same at top level as it would within a function definition with
(function (lambda ... )) in place of (defun ... ).
     The documentation for let (p. 111) says "each binding will be a
lexical binding unless there is a special declaration to the contrary
...  The bindings of the variables have lexical scope and indefinite
extent".
     The documentation for defun (p. 67) says "Evaluating a
defun form causes the symbol ... to be a global name for the function
specified by the lambda-expression ... defined in the lexical environment
in which the defun form was executed".
     However, neither Symbolics nor TI seems to allow this (I may not
have checked the very latest releases).

     Why would anyone want to use this?  Well, because it's there, because
it's (to my taste) cleaner and more elegant than using a global special
variable, and because it's good software engineering practice not to
have things accessible from where they're not intended to be accessed.
For a practical example, one might perhaps think of a login function using
a (computed) list of passwords.

     The compile function (p. 438) presumably ought to work the same way
(at least with the second argument supplied), although there isn't any
specific textual justification.  Symbolics and TI don't support this
either.

     Finally, if I may add a comment not about Common Lisp per se,
both Symbolics and TI fail to actually compile a defun within
a let, but make it a named-lambda instead (in addition to not scoping
it properly), when using c-sh-C from the editor, and probably do
the same when compiling and loading a file.  This is tolerated by
Common Lisp (defun is one of the top-level forms of which CLtL says
on p. 66 "Compilers, for example, may not recognize these forms properly
in other than top-level contexts"), but I would think that sophisticated
implementations should do the reasonable thing here.


Bob Sasseen

∂23-Jul-87  1509	pierson@multimax.ARPA 	Toplevel lexical variables 
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jul 87  15:09:11 PDT
Received:  by multimax.ARPA (4.12/25-eef)
	id AA06883; Thu, 23 Jul 87 18:04:23 edt
Date: Thu, 23 Jul 87 18:04:23 edt
From: Dan Pierson <pierson@multimax.ARPA>
Message-Id: <8707232204.AA06883@multimax.ARPA>
To: common-lisp@SAIL.STANFORD.EDU
Subject: Toplevel lexical variables

If you expand the example to:

(let ((x 1))
  (defun f ()
    x)
  (defun g (bar)
    ...
    (setq x ...)
    ...))

It becomes clear that this sort of structure is quite useful.  X may
be a private constant or a private "global" shared by the two top
level functions F and G.  The same sort of information hiding can be
done with packages, but both the cost and code complexity will rise.

This style is more common in Scheme than Common Lisp but it seems to
me that Common Lisp implementations are required to support it.

                                            dan

In real life: Dan Pierson, Encore Computer Corporation, Research
Usenet: {talcott,linus,necis,decvax,ihnp4}!encore!pierson
Arpanet: pierson@multimax.arpa

∂23-Jul-87  1739	VERACSD@A.ISI.EDU 	Correction 
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 87  17:38:57 PDT
Date: 23 Jul 1987 20:38-EDT
Sender: VERACSD@A.ISI.EDU
Subject: Correction
From: VERACSD@A.ISI.EDU
To: common-lisp@SAIL.STANFORD.EDU
Cc: veracsd.rs@A.ISI.EDU
Message-ID: <[A.ISI.EDU]23-Jul-87 20:38:49.VERACSD>

     I have to apologize to Symbolics.  Their release 7.1 (possibly also
7.0, but not 6.1) does allow toplevel lexical variables such as described
in my posting earlier today.  The user is asked whether this is really
what he wants.
     I am informed that TI's upcoming release 3.0 will support this too.
     (What I said about the functions not being actually compiled remains
true for 7.1; I'm not sure about 3.0.)
     (I might add that Symbolics does not allow lexical bindings around
defmethods (not sure about TI); I hope they will consider it.)

     A little thought has also revealed to me that there is no way one
can expect the compile function, called at runtime, to pick up lexical
bindings.  The other alternative, putting the let around the second
argument to compile (as part of it) is clearly not supported by CLtL,
although it would be nice if it were.

     Sorry for any inconvenience.

Bob Sasseen

∂24-Jul-87  0806	SWM@SAPSUCKER.SCRC.Symbolics.COM 	Correction 
Received: from [128.81.41.223] by SAIL.STANFORD.EDU with TCP; 24 Jul 87  08:05:53 PDT
Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 148310; Fri 24-Jul-87 10:45:29 EDT
Date: Fri, 24 Jul 87 10:45 EDT
From: Scott McKay <SWM@SAPSUCKER.SCRC.Symbolics.COM>
Subject: Correction
To: VERACSD@A.ISI.EDU, common-lisp@SAIL.STANFORD.EDU
cc: veracsd.rs@A.ISI.EDU
In-Reply-To: <[A.ISI.EDU]23-Jul-87 20:38:49.VERACSD>
Message-ID: <870724104512.0.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM>

    Date: 23 Jul 1987 20:38-EDT
    From: VERACSD@A.ISI.EDU

	 I have to apologize to Symbolics.  Their release 7.1 (possibly also
    7.0, but not 6.1) does allow toplevel lexical variables such as described
    in my posting earlier today.  The user is asked whether this is really
    what he wants.
	 I am informed that TI's upcoming release 3.0 will support this too.
	 (What I said about the functions not being actually compiled remains
    true for 7.1; I'm not sure about 3.0.)

So far, they remain uncompiled.

	 (I might add that Symbolics does not allow lexical bindings around
    defmethods (not sure about TI); I hope they will consider it.)

Isn't this what instance variables are for?  In CLOS, methods get to
choose what "slots" (CLOSpeak for "instance variable") they are allowed
to access, so can get the "own variable" behavior you want that way.

	 A little thought has also revealed to me that there is no way one
    can expect the compile function, called at runtime, to pick up lexical
    bindings.  The other alternative, putting the let around the second
    argument to compile (as part of it) is clearly not supported by CLtL,
    although it would be nice if it were.

	 Sorry for any inconvenience.

    Bob Sasseen


∂24-Jul-87  0939	Gregor.pa@Xerox.COM 	Re: Correction
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 24 Jul 87  09:39:32 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 JUL 87 09:39:17 PDT
Date: 24 Jul 87 09:38 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Correction
In-reply-to: Scott McKay <SWM@SAPSUCKER.SCRC.Symbolics.COM>'s message of
 Fri, 24 Jul 87 10:45 EDT
To: SWM@SAPSUCKER.SCRC.Symbolics.COM
cc: VERACSD@A.ISI.EDU, common-lisp@SAIL.STANFORD.EDU,
 veracsd.rs@A.ISI.EDU
Message-ID: <870724-093917-2611@Xerox>

    From: Scott McKay <SWM@SAPSUCKER.SCRC.Symbolics.COM>
    Subject: Correction

        Date: 23 Jul 1987 20:38-EDT
        From: VERACSD@A.ISI.EDU

    	 (I might add that Symbolics does not allow lexical
        bindings around defmethods (not sure about TI); I hope they
        will consider it.)

    Isn't this what instance variables are for?  In CLOS, methods
    get to choose what "slots" (CLOSpeak for "instance variable") they
    are allowed to access, so can get the "own variable" behavior you
    want that way.

No, this kind of use of lexical variables is not at all the same as
slots (instance variables).  Slots are a piece of storage which is
associated with an object (in the case of class variables it can be more
than one object).  Effectively that means that with respect to the body
of the method slots are dynamic variables.  Needless to say, lexical
variables around a defmethod aren't dynamic variables.  Here is what I
think of as a prototypical example of methods using both a slot and a
lexical variable.

(defclass plist-mixin ()
    ((plist :initform ()
            :accessor plist)))

(let ((mark (list "mark")))

  (defmethod mark  ((x plist-mixin))
    (setf (getf (plist x) mark) t))

  (defmethod markp ((x plist-mixin))
    (getf (plist x) mark))

  )

∂24-Jul-87  1020	SWM@SAPSUCKER.SCRC.Symbolics.COM 	Re: Correction  
Received: from [128.81.41.223] by SAIL.STANFORD.EDU with TCP; 24 Jul 87  10:20:26 PDT
Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 148385; Fri 24-Jul-87 13:21:07 EDT
Date: Fri, 24 Jul 87 13:20 EDT
From: Scott McKay <SWM@SAPSUCKER.SCRC.Symbolics.COM>
Subject: Re: Correction
To: Gregor.pa@Xerox.COM, SWM@SAPSUCKER.SCRC.Symbolics.COM
cc: VERACSD@A.ISI.EDU, common-lisp@SAIL.STANFORD.EDU, veracsd.rs@A.ISI.EDU
In-Reply-To: <870724-093917-2611@Xerox>
Message-ID: <870724132056.7.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM>

    Date: 24 Jul 87 09:38 PDT
    From: Gregor.pa@Xerox.COM

	From: Scott McKay <SWM@SAPSUCKER.SCRC.Symbolics.COM>
	Subject: Correction

	    Date: 23 Jul 1987 20:38-EDT
	    From: VERACSD@A.ISI.EDU

	     (I might add that Symbolics does not allow lexical
	    bindings around defmethods (not sure about TI); I hope they
	    will consider it.)

	Isn't this what instance variables are for?  In CLOS, methods
	get to choose what "slots" (CLOSpeak for "instance variable") they
	are allowed to access, so can get the "own variable" behavior you
	want that way.

    No, this kind of use of lexical variables is not at all the same as
    slots (instance variables).  Slots are a piece of storage which is
    associated with an object (in the case of class variables it can be more
    than one object).  Effectively that means that with respect to the body
    of the method slots are dynamic variables.  Needless to say, lexical
    variables around a defmethod aren't dynamic variables.  Here is what I
    think of as a prototypical example of methods using both a slot and a
    lexical variable.

Thanks for unconfusing me.

    (defclass plist-mixin ()
	((plist :initform ()
		:accessor plist)))

    (let ((mark (list "mark")))

      (defmethod mark  ((x plist-mixin))
	(setf (getf (plist x) mark) t))

      (defmethod markp ((x plist-mixin))
	(getf (plist x) mark))

      )


∂24-Jul-87  1043	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re: Correction   
Received: from [128.81.41.109] by SAIL.STANFORD.EDU with TCP; 24 Jul 87  10:43:48 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 103619; Fri 24-Jul-87 13:34:38 EDT
Date: Fri, 24 Jul 87 13:33 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: Correction
To: Gregor.pa@Xerox.COM, SWM@SAPSUCKER.SCRC.Symbolics.COM
cc: VERACSD@A.ISI.EDU, common-lisp@SAIL.STANFORD.EDU, veracsd.rs@A.ISI.EDU
In-Reply-To: <870724-093917-2611@Xerox>
Message-ID: <870724133345.1.DLW@CHICOPEE.SCRC.Symbolics.COM>
Line-fold: No

It seems to me that the use of lexical bindings around several methods
is rather akin to the concept of "class variables".  (Except that you
control the scope by lexical containment in the let, rather than having
the scope always me the set of all methods of a class.)

∂24-Jul-87  1218	barmar@think.com 	Re: Correction   
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 24 Jul 87  12:18:03 PDT
Received: from nietzsche by Think.COM via CHAOS; Fri, 24 Jul 87 15:12:05 EDT
Date: Fri, 24 Jul 87 15:12 EDT
From: Barry Margolin <barmar@think.com>
Subject: Re: Correction
To: Daniel L. Weinreb <DLW@alderaan.scrc.symbolics.com>
Cc: Gregor.pa@xerox.com, SWM@sapsucker.scrc.symbolics.com, VERACSD@a.isi.edu,
        common-lisp@sail.stanford.edu, veracsd.rs@a.isi.edu
In-Reply-To: <870724133345.1.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <870724151251.2.BARMAR@NIETZSCHE.THINK.COM>

    Date: Fri, 24 Jul 87 13:33 EDT
    From: Daniel L. Weinreb <DLW@alderaan.scrc.symbolics.com>

    It seems to me that the use of lexical bindings around several methods
    is rather akin to the concept of "class variables".  (Except that you
    control the scope by lexical containment in the let, rather than having
    the scope always me the set of all methods of a class.)

To continue further from what Dan was saying, I believe that the
response to this type of thing in the past has been to suggest that the
class should be broken up into two classes.  In Gregor's example, the
LET would be replaced by a MARK-MIXIN, which would have the class
variable MARK.

						barmar

∂25-Jul-87  2249	@RELAY.CS.NET:MURRAY@cs.umass.edu 	EOF-VALUE 
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Jul 87  22:49:22 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac21038; 26 Jul 87 1:49 EDT
Received: from cs.umass.edu by RELAY.CS.NET id bt15822; 26 Jul 87 1:39 EDT
Date: Sat, 25 Jul 87 19:53 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
Subject: EOF-VALUE
To: common-lisp@SAIL.STANFORD.EDU
X-VMS-To: CLMAIL


What is the default value of EOF-VALUE for all the read functions?

For example, READ takes (&Optional input-stream eof-error-p eof-value).

If only INPUT-STREAM and EOF-ERROR-P are supplied, and EOF-ERROR-P is non-nil,
CLtL says that the value of EOF-VALUE will be returned if an end-of-file 
is found.  Without any further specification, I must assume that it
defaults to NIL, which is the default default value for unsupplied &Optionals.

For READ-CHAR, and READ-BYTE, NIL is an impossible value, but for READ
and company, NIL is a perfectly reasonable return value.
Thus, it makes no sense to supply a non-nil second argument, but not the third.  
In fact, the only safe value for EOF-VALUE in these cases is some
non-atomic object that could never be EQ to something read in.  

For this reason, In just about every file that calls read, I've got something
like (Defconst *eof-value* (cons nil nil)), (maybe it's eof-value, or
si:eof-value, or sys:**eof-value**, I can never remember), so I can supply
and test for it as an EOF-VALUE.   

I would like to suggest the addition of new constant, *eof-value*, that
is the default value for EOF-VALUE in all the read functions.  

Every system using something like this, why not make it standard?

 - Kelly Murray

∂26-Jul-87  1433	smh@EMS.MEDIA.MIT.EDU 	Re:  EOF-VALUE   
Received: from EMS.MEDIA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 87  14:33:21 PDT
Received: by EMS.MEDIA.MIT.EDU (5.54/4.8)  id AA17837; Sun, 26 Jul 87 17:24:57 EDT
Date: Sun, 26 Jul 87 17:24:57 EDT
From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich)
Message-Id: <8707262124.AA17837@EMS.MEDIA.MIT.EDU>
To: MURRAY%cs.umass.edu@RELAY.CS.NET, common-lisp@SAIL.STANFORD.EDU
Subject: Re:  EOF-VALUE

   From: MURRAY%cs.umass.edu@RELAY.CS.NET
   I would like to suggest the addition of new constant, *eof-value*, that
   is the default value for EOF-VALUE in all the read functions.  

This is not *quite* an upward compatible change.  An existing
application using READ could reasonably depend on NIL being synonymous
to a real EOF.  Although the proposed change is otherwise cogent, I
would opt against it since the benefit is only minor convenience and
not increased functionality.

∂26-Jul-87  1623	@REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU 	EOF-VALUE  
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 87  16:23:36 PDT
Received: from JONES.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 50335; Sun 26-Jul-87 19:23:37 EDT
Date: Sun, 26 Jul 87 19:23 EDT
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: EOF-VALUE
To: MURRAY%cs.umass.edu@RELAY.CS.NET, common-lisp@SAIL.STANFORD.EDU
In-Reply-To: The message of 25 Jul 87 19:53 EDT from MURRAY%cs.umass.edu@RELAY.CS.NET
Message-ID: <870726192338.4.CFRY@JONES.AI.MIT.EDU>




    What is the default value of EOF-VALUE for all the read functions?

    For example, READ takes (&Optional input-stream eof-error-p eof-value).

    If only INPUT-STREAM and EOF-ERROR-P are supplied, and EOF-ERROR-P is non-nil,
    CLtL says that the value of EOF-VALUE will be returned if an end-of-file 
    is found.  Without any further specification, I must assume that it
    defaults to NIL, which is the default default value for unsupplied &Optionals.

    For READ-CHAR, and READ-BYTE, NIL is an impossible value, but for READ
    and company, NIL is a perfectly reasonable return value.
    Thus, it makes no sense to supply a non-nil second argument, but not the third.  
    In fact, the only safe value for EOF-VALUE in these cases is some
    non-atomic object that could never be EQ to something read in.  

    For this reason, In just about every file that calls read, I've got something
    like (Defconst *eof-value* (cons nil nil)), (maybe it's eof-value, or
    si:eof-value, or sys:**eof-value**, I can never remember), so I can supply
    and test for it as an EOF-VALUE.   

    I would like to suggest the addition of new constant, *eof-value*, that
    is the default value for EOF-VALUE in all the read functions.  

    Every system using something like this, why not make it standard?

     - Kelly Murray
I second this proposal. Make EOF processing easy!


∂27-Jul-87  0949	barmar@think.com 	EOF-VALUE   
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 27 Jul 87  09:49:03 PDT
Received: from nietzsche by Think.COM via CHAOS; Mon, 27 Jul 87 11:51:35 EDT
Date: Mon, 27 Jul 87 11:29 EDT
From: Barry Margolin <barmar@think.com>
Subject: EOF-VALUE
To: MURRAY%cs.umass.edu@relay.cs.net
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8707260551.AA27872@Think.COM>
Message-Id: <870727112913.6.BARMAR@NIETZSCHE.THINK.COM>

    Date: Sat, 25 Jul 87 19:53 EDT
    From: MURRAY%cs.umass.edu@relay.cs.net

[...]

    For this reason, In just about every file that calls read, I've got something
    like (Defconst *eof-value* (cons nil nil)), (maybe it's eof-value, or
    si:eof-value, or sys:**eof-value**, I can never remember), so I can supply
    and test for it as an EOF-VALUE.   

    I would like to suggest the addition of new constant, *eof-value*, that
    is the default value for EOF-VALUE in all the read functions.  

    Every system using something like this, why not make it standard?

While I admit that it is common, it is not foolproof, because someone
can type #.*eof-value*.  The only really safe eof value is an object
consed on the fly, as in

	(let ((eof-value (ncons '*eof-value*)))	;self-documenting structure
	  ...
	  (read *standard-input* nil eof-value)
	  ...)

The only way one could get at that value is by using a debugger or some
other internal hack to look in the lexical environment, and they don't
count.

However, I wouldn't object strongly to adding *eof-value*, as anyone who
types #.*eof-value* deserves what they get.

                                                barmar

∂27-Jul-87  1423	gls@Think.COM 	EOF-VALUE 
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 27 Jul 87  14:23:07 PDT
Received: from polycarp by Think.COM via CHAOS; Mon, 27 Jul 87 15:33:27 EDT
Date: Mon, 27 Jul 87 15:26 EDT
From: Guy Steele <gls@Think.COM>
Subject: EOF-VALUE
To: barmar@think.com, MURRAY%cs.umass.edu@relay.cs.net
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <870727112913.6.BARMAR@NIETZSCHE.THINK.COM>
Message-Id: <870727152620.7.GLS@POLYCARP.THINK.COM>

    Date: Mon, 27 Jul 87 11:29 EDT
    From: Barry Margolin <barmar@think.com>

	Date: Sat, 25 Jul 87 19:53 EDT
	From: MURRAY%cs.umass.edu@relay.cs.net
	...
    ...
    However, I wouldn't object strongly to adding *eof-value*, as anyone who
    types #.*eof-value* deserves what they get.

That's true even if we don't spec or implement it.
--Guy

∂27-Jul-87  1447	SCHMIDT@SUMEX-AIM.STANFORD.EDU 	Re: Toplevel lexical variables   
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 87  14:46:56 PDT
Date: Mon, 27 Jul 87 14:46:58 PDT
From: Christopher Schmidt <SCHMIDT@SUMEX-AIM.STANFORD.EDU>
Subject: Re: Toplevel lexical variables
To: VERACSD%A.ISI.EDU@SUMEX-AIM.STANFORD.EDU
cc: common-lisp@SAIL.STANFORD.EDU
Message-ID: <12321792358.60.SCHMIDT@SUMEX-AIM.STANFORD.EDU>

(DEFUN A ()                         (DEFUN B ()
   (LET ((X 1))                        (LET ((X 1))
      (DEFUN F () X)                      (SETF (SYMBOL-FUNCTION 'F)
						#'(LAMBDA () X))
      (DEFUN G (Y) (SETQ X Y))))          (SETF (SYMBOL-FUNCTION 'G)
						#'(LAMBDA (Y) (SETQ X Y)))))

I think definition B above would provide the behavior you desire and
skirt the issue of compiling DEFUN as other than a top-level form;
hence I believe it to be more portable.
--Christopher

P.S. My apologies to the list if this is so obvious that it doesn't
bear stating.
-------

∂27-Jul-87  1706	pierson@multimax.ARPA 	Toplevel lexical variables 
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 27 Jul 87  17:06:19 PDT
Received:  by multimax.ARPA (4.12/25-eef)
	id AA02229; Mon, 27 Jul 87 20:00:55 edt
Date: Mon, 27 Jul 87 20:00:55 edt
From: Dan Pierson <pierson@multimax.ARPA>
Message-Id: <8707280000.AA02229@multimax.ARPA>
To: SCHMIDT@SUMEX-AIM.STANFORD.EDU
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: Toplevel lexical variables

Ah, but the original desire (as I understand it) was to have the LET
be top-level rather than nested inside of a DEFUN.  CLtL allows
top-level forms to be nested inside PROGN but not LET.  The use of
top-level LETs is a common, and useful, Scheme idiom.  I suspect that
it was discovered by the Scheme folks first because they've had
lexical scoping longer, but we really should support it in Common
Lisp.

Your definition B followed by:

     (eval-when (load eval) (b))

does the same job at the costs of: an extra function defintion and
call, and considerably more opaque syntax.  I don't believe that it's
any easier to compile properly (i.e. ensure that the internal lambdas
are optionally compiled).

                                            	dan

∂28-Jul-87  0050	wade@wombat.stanford.edu 	EOF value
Received: from WOMBAT by SAIL.STANFORD.EDU with TCP; 28 Jul 87  00:49:55 PDT
Date: 28 Jul 87 00:48:00 PST
From: "Wade Hennessey" <wade@wombat.stanford.edu>
Subject: EOF value
To: "common-lisp" <common-lisp@sail.stanford.edu>
Reply-To: "Wade Hennessey" <wade@wombat.stanford.edu>

The stream you are reading from is usually a perfectly good EOF
value. Rod Brooks showed me this, and I have yet to encounter a 
situation where it did not suffice.

Wade
------

∂29-Jul-87  0039	@RELAY.CS.NET:MURRAY@cs.umass.edu 	*eof-value*    
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 29 Jul 87  00:39:21 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa22549; 29 Jul 87 3:37 EDT
Received: from cs.umass.edu by RELAY.CS.NET id bj03680; 29 Jul 87 3:29 EDT
Date: Tue, 28 Jul 87 14:35 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
Subject: *eof-value*
To: common-lisp@SAIL.STANFORD.EDU
X-VMS-To: CLMAIL

From: MURRAY%cs.umass.edu@RELAY.CS.NET
 I would like to suggest the addition of new constant, *eof-value*, that
 is the default value for EOF-VALUE in all the read functions.  

>From:	IN%"Steven Haflich <smh@ems.media.mit.edu>" 28-JUL-1987 01:59
>Although the proposed change is otherwise cogent, I
>would opt against it since the benefit is only minor convenience and
>not increased functionality.

But at no real cost, since the constant is going to exist anyway.

>From: Barry Margolin <barmar@THINK.COM>
>While I admit that it is common, it is not foolproof, because someone
>can type #.*eof-value*.  The only really safe eof value is an object
>consed on the fly, as in..

I hadn't considered this, but it just occured to me you found a neat
way of commenting out the rest of a file! 
(Assuming the loader is checking for *eof-value*, and not NIL, or something
consed on the fly, or si:*eof-value*, or etc.)

(defun foo ..)
#.*eof-value* 
(defun unused-foo ..)
..

 - Kelly Murray
   University of Massachusetts

∂29-Jul-87  0648	smh@EMS.MEDIA.MIT.EDU 	Re:  *eof-value* 
Received: from EMS.MEDIA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 87  06:48:03 PDT
Received: by EMS.MEDIA.MIT.EDU (5.54/4.8)  id AA08459; Wed, 29 Jul 87 09:39:29 EDT
Date: Wed, 29 Jul 87 09:39:29 EDT
From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich)
Message-Id: <8707291339.AA08459@EMS.MEDIA.MIT.EDU>
To: MURRAY%cs.umass.edu@RELAY.CS.NET, common-lisp@SAIL.STANFORD.EDU
Subject: Re:  *eof-value*

   From: MURRAY%cs.umass.edu@RELAY.CS.NET
    I would like to suggest the addition of new constant, *eof-value*, that
    is the default value for EOF-VALUE in all the read functions.  

   >From:	IN%"Steven Haflich <smh@ems.media.mit.edu>" 28-JUL-1987 01:59
   >Although the proposed change is otherwise cogent, I
   >would opt against it since the benefit is only minor convenience and
   >not increased functionality.

   But at no real cost, since the constant is going to exist anyway.

Perhaps I wasn't really clear.  The important cost is that changing
the current default value of eof-value from NIL to anything else may
break existing code that depends on (READ stream NIL) returning NIL on
eof.  Even though CL might be a better language if the spec were
changed in this regard, this rather minor improvement wouldn't justify
making an incompatible change, particularly since the desired
functionality can be achieved via (READ stream NIL *EOF-VALUE*).

By the way, exporting a new symbol such as *EOF-VALUE* from the LISP
package is an incompatible change, although often a more-easily
detectible one.  The problem is that code written under the old spec
will suddenly find it's like-named internal symbol(s) "unified" with
the symbol in the LISP package.  If it were really a CONSTANT (why?)
than presumably any user attempt to set or even DEFVAR it will signal
an error.  But even innocently adding a new exported function name can
break code that happens to use that name either as a function or a
special variable.

It will certainly happen that X3J13 will propose add new functions and
variables that must be exported from the LISP package.  However, they
will weigh the cost of each such change and only make changes for
which there is a significant benefit that cannot otherwise easily be
obtained using the existing language definition.

∂31-Jul-87  1455	wile@vaxa.isi.edu 	Test Suite availability   
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 87  14:55:48 PDT
Posted-Date: Fri, 31 Jul 87 14:33:58 PDT
Message-Id: <8707312134.AA13154@vaxa.isi.edu>
Received: from loopback by vaxa.isi.edu (5.54/5.51)
	id AA13154; Fri, 31 Jul 87 14:34:02 PDT
To: COMMON-LISP@sail.stanford.edu
From: wile@vaxa.isi.edu
Subject: Test Suite availability
Date: Fri, 31 Jul 87 14:33:58 PDT
Sender: wile@vaxa.isi.edu


A Common Lisp Validation Suite has been assembled here at ISI by Richard
Berman.  He essentially developed a test driver and has converted
portions of the suites of some of the vendors to his format.  The suite
contains only a small fraction of the tests he has received, but it is a
start for anyone responsible for quality assurance of CL
implementations. 

Unfortunately for us, Richard resigned recently (to go off and become a
recording star and/or AI in music guru), so there will be little
additional support or development until a replacement for him is found.

Although several of you are aware of the existence of this suite, we
have been told that many interested parties were not; hence, this
message.  To access the suite, ftp to venera.isi.edu logging in as
anonymous.  Please respond with your name and affiliation as the
password.  The two directories of interest are: /usr/ftp/Valid-Code/*.*
and /usr/ftp/Valid-Tests/*.*.  (Capitalization is necessary.)  The file
README.NOW contains the information necessary to understand how to
invoke the test suite and what files to transfer to your machine.
Apparently around 400 tests are available now.  

We have no way to monitor the activity on the files, except with the ftp
log of your anonymous password.  We would very much appreciate hearing
about any successes, problems, or suggestions (perhaps as to which
remaining tests to convert first) you have.  Send mail to
WILE@VAXA.ISI.EDU for now.  There is a mailing list for the validation
group--named CL-VALIDATION.  You get onto it by mailing to
RPG@SAIL.STANFORD.EDU.

∂31-Jul-87  2159	sandra%orion@cs.utah.edu 	compile-time processing of REQUIRE
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 87  21:59:39 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
	id AA09047; Fri, 31 Jul 87 23:02:09 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
	id AA05593; Fri, 31 Jul 87 23:02:05 MDT
Date: Fri, 31 Jul 87 23:02:05 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8708010502.AA05593@orion.utah.edu>
Subject: compile-time processing of REQUIRE
To: common-lisp@sail.stanford.edu

Am I correct that REQUIRE forms appearing at top level are not supposed
to be evaluated at compile time?  It is not in the list of magic
functions on p. 182 of CLtL.  However, both VaxLisp and Lucid attempt to
process them at compile time.  Has there been a proposal to make REQUIRE
magical, that I haven't heard about?

The reason why this behavior is causing a problem for me is that I have
a number of modules which involve several files.  I've found it
convenient to put all of the external interface stuff (EXPORTs, etc.) in
a separate file and have it REQUIRE the remaining files.  When I compile
this top-level file, sometimes these other files don't exist yet:  I
haven't compiled them yet, or I haven't copied the files to the place
where REQUIRE wants to look for them, or whatever.  If this is not the
way REQUIRE was intended to be used, can somebody tell me how it *is*
supposed to be used?

-Sandra
-------

∂01-Aug-87  1031	smh@EMS.MEDIA.MIT.EDU 	Re:  compile-time processing of REQUIRE   
Received: from EMS.MEDIA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Aug 87  10:31:16 PDT
Received: by EMS.MEDIA.MIT.EDU (5.54/4.8)  id AA25229; Sat, 1 Aug 87 13:23:25 EDT
Date: Sat, 1 Aug 87 13:23:25 EDT
From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich)
Message-Id: <8708011723.AA25229@EMS.MEDIA.MIT.EDU>
To: common-lisp@sail.stanford.edu, sandra%orion@cs.utah.edu
Subject: Re:  compile-time processing of REQUIRE

The problem is only partly one of underspecification.  Depending
whether the required file contains only macros, both macros and
execution-time functions, or just execution-time functions, typically
you will want REQUIRE to happen at compile/eval, compile/load/eval, or
load/eval times.

Regardless when a naked REQUIRE does or doesn't happen, you can get
explicit control by surrounding it with an EVAL-WHEN.  This will
protect somewhat from differences between implementations.

∂02-Aug-87  0808	edsel!bhopal!jonl@labrea.stanford.edu 	compile-time processing of REQUIRE  
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Aug 87  08:08:10 PDT
Received: by labrea.stanford.edu; Sat, 1 Aug 87 22:32:50 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
	id AA07051; Sat, 1 Aug 87 22:34:04 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
	id AA08106; Sat, 1 Aug 87 22:31:24 PDT
Date: Sat, 1 Aug 87 22:31:24 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8708020531.AA08106@bhopal.edsel.uucp>
To: labrea!sandra%orion%cs.utah.edu@labrea.stanford.edu
Cc: labrea!common-lisp%sail@labrea.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Fri, 31 Jul 87 23:02:05 MDT <8708010502.AA05593@orion.utah.edu>
Subject: compile-time processing of REQUIRE

re: Am I correct that REQUIRE forms appearing at top level are not supposed
    to be evaluated at compile time?  It is not in the list of magic
    functions on p. 182 of CLtL.  However, both VaxLisp and Lucid . . . 

I have been under the impression that the compilation interface is one 
area where CLtL, as a specification, didn't succeed very well.  Although 
no complete guarantee can be given to insure package layout consistency, 
it seems to me that the usage pattern of REQUIRE (but *not* PROVIDE) is 
such that it should be implicitly recognized by the compiler interface.

For example, see Table 11-1 of CLtL, p189:
    ;;;; Lisp init file for I. Newton
    ;;; Set upthe USER pacakge the wayk I like it.
    (require 'calculus)                ;I use CALCULUS a lot.  Load it.
    (use-package 'calculus)            ;Get easy access to its exported symbols
    . . . 
    ;;; Import only what I need into the USER package. 
    (require 'relativity)
    (import '(relativity:speed-of-light)...)

Quite evidently, the CALCULUS package is created and set up by the
calculus module; and parameters with names like RELATIVITY:SPEED-OF-LIGHT
are defined in the RELATIVITY module (indeed, isn't this the intention of 
"modular" programming!).  Thus this example, as a file, would not be 
compilable unless the REQUIRE statements are executed, in the order in 
which they appear, during the file compilation.

In addition to REQUIRE, Lucid has added UNINTERN to the set of forms
implicitly wrapped in an eval-when(eval compile load).  Note that there
is nothing stopping the programmer from using his own wrappers, which
will have precedence over the implicit one.

Incidentally, one other area where I personally violate the CLtL 
suggestions on package usage is in the placement of PROVIDE statements.
Section 11.9 suggests placeing them first in a file, and the cutsy little
mnemonic on page 191 -- PutInSevenExtremelyRandomUserInterfaceCommands --
also does that.  But because loading a lisp file is a dynamic action
with ocasionally loooooong duration, and because it is very easy to
abort the loading right in the middle -- either interactively or through 
the error system -- then I place my PROVIDE's last, so that the *MODULES* 
list will not actually be updated until the whole module is fully present.


One final point: I've used the word "statements" to refer to these
functions.  I hope you don't think that I'm just some kind of nerd who
learned Lisp yesterday and doesn't know enough to refer to these sorts 
of things as "forms" or "s-expressions" or whatever.  In fact the 
functionality provided by these "...ExtremelyRandomUserInterface..."
commands is very much like that of a JobControlLanguage.  That is why 
I refer to them as "statements".  

Allow me, if you will, to express one more very strong opinion:  I 
definitely prefer to write my "statements" in Lisp syntax rather than 
in YAJCL*, or FORTRAN, or even the Emacs-inspired "File Attribute"
syntax of the MIT Lisp machine descendents.  [Lisp is "good enough";
it does the job.]


-- JonL --


*  =  YetAnotherJobControlLanguage

∂03-Aug-87  0907	barmar@Think.COM 	New special form suggestion: LET-CONSTANT 
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Aug 87  09:07:12 PDT
Received: from nietzsche by Think.COM via CHAOS; Mon, 3 Aug 87 12:06:50 EDT
Date: Mon, 3 Aug 87 12:07 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: New special form suggestion: LET-CONSTANT
To: common-lisp@sail.stanford.edu
Message-Id: <870803120736.7.BARMAR@NIETZSCHE.THINK.COM>

Today I noticed myself creating DEFCONSTANTS for symbolic constants that
would only be used by the one function I was writing.  It struck me that
they really wanted to be local to the function, not top-level variables,
but I wanted to make sure that the compiler would open-code them, and I
also wanted to declare their constantness to readers.  There is
currently no way to do this in Common Lisp (nor, as far as I know, in
Symbolics Common Lisp, which I was using) without DEFCONSTANT, which
also creates a useless special variable.

It seems like a LET-CONSTANT special form, or an &CONSTANT lambda-list
keyword, would be the right thing for this.  LET-CONSTANT would be to
DEFPARAMETER what FLET is to DEFUN, and &CONSTANT would be analogous to
&AUX.

Actually, for consistency with the names FLET and MACROLET, I suppose
this should be called CONSTANTLET (although to me that seems like the
word for a little constant).  However, I never liked those names anyway.

						barmar@think.com

∂03-Aug-87  0930	samalone@ATHENA.MIT.EDU 	Re: New special form suggestion: LET-CONSTANT     
Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87  09:30:24 PDT
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA22194; Mon, 3 Aug 87 12:28:47 EDT
From: <samalone@ATHENA.MIT.EDU>
Received: by HADES.MIT.EDU (5.45/4.7) id AA00890; Mon, 3 Aug 87 12:28:40 EDT
Message-Id: <8708031628.AA00890@HADES.MIT.EDU>
To: common-lisp@sail.stanford.edu
Subject: Re: New special form suggestion: LET-CONSTANT 
In-Reply-To: Your message of Mon, 03 Aug 87 12:07:00 -0400.
             <870803120736.7.BARMAR@NIETZSCHE.THINK.COM> 
Date: Mon, 03 Aug 87 12:28:38 EDT


	It seems like a LET-CONSTANT special form, or an &CONSTANT
	lambda-list keyword, would be the right thing for this. 
	LET-CONSTANT would be to DEFPARAMETER what FLET is to DEFUN,
	and &CONSTANT would be analogous to &AUX.

As an alternative, I recommend a CONSTANT declaration.  DEFCONSTANT could then
be defined in terms of (PROCLAIM '(CONSTANT variable)).  The statement
(PROCLAIM '(DECLARATION CONSTANT)) would provide compatibility with
implementations that don't support the declaration.

				--Stuart A. Malone

∂03-Aug-87  1021	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	New special form suggestion: LET-CONSTANT    
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 3 Aug 87  10:20:51 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110034; Mon 3-Aug-87 13:17:49 EDT
Date: Mon, 3 Aug 87 13:17 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: New special form suggestion: LET-CONSTANT
To: Barry Margolin <barmar@Think.COM>, samalone@ATHENA.MIT.EDU
cc: common-lisp@sail.stanford.edu
In-Reply-To: <870803120736.7.BARMAR@NIETZSCHE.THINK.COM>,
             <8708031628.AA00890@HADES.MIT.EDU>
Message-ID: <870803131722.1.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>

Yes, CONSTANTLET would be a better name.

Proclamations don't solve Barry's concern: he doesn't want a "useless"
variable which proclomations would require.  As far as I can tell,
PROCLAIM/DEFPARAMETER is just another syntax for DEFCONSTANT and doesn't
solve anything.

On the other hand, a (DECLARE (CONSTANT XYZ)) in the declarations part
of a LET body (or of a DEFUN for &AUX) might be the way to go.

You can get what you want today, kludgily, by using MACROLET and making
the desired constants look like function calls.

I'm glad some people prefer to err on the side of naming seldom-used
constants than to wire in magic numbers into their code; numbers by
themselves don't convey much information to the casual reader.

∂03-Aug-87  1023	snyder%hplsny@hplabs.HP.COM 	Re: compile-time processing of REQUIRE   
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 3 Aug 87  10:21:12 PDT
Received: from hplms2 by hplabs.HP.COM with TCP ; Mon, 3 Aug 87 10:19:13 pdt
Received: from hplsny (hplsny) by hplms2; Mon, 3 Aug 87 10:18:53 pdt
Return-Path: <snyder@hplsny>
Received: from hplsny.hpl.hp.com by hplsny ; Mon, 3 Aug 87 10:18:35 pdt
Message-Id: <8708031718.AA03272@hplsny>
To: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Cc: common-lisp@sail.stanford.edu
Subject: Re: compile-time processing of REQUIRE 
Reply-To: snyder@hplabs
In-Reply-To: Your message of Sat, 01 Aug 87 22:31:24 -0700.
             <8708020531.AA08106@bhopal.edsel.uucp> 
Date: Mon, 03 Aug 87 10:18:31 PDT
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>

    In addition to REQUIRE, Lucid has added UNINTERN to the set of forms
    implicitly wrapped in an eval-when(eval compile load).  Note that there
    is nothing stopping the programmer from using his own wrappers, which
    will have precedence over the implicit one.

I believe that the CLtL specification of EVAL-WHEN is inadequate to
guarantee that the programmer can achieve this effect.  In particular,
following the "precise model" (p 70):

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

is no different than

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

There is no way to have a "negative" effect (such as "do NOT do this at
compile time").  I hope the "clean up" committee is addressing this issue.

  Alan

∂03-Aug-87  1041	RpK%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Question on function type spec and lambda-list keywords   
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87  10:40:53 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 3 Aug 87 13:40-EDT
Received: from ACORN.Gold-Hill.DialNet.Symbolics.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 54193; 3 Aug 87 13:35:58-EDT
Date: Mon, 3 Aug 87 12:39 EDT
From: RpK%acorn@oak.lcs.mit.edu
Subject: Question on function type spec and lambda-list keywords
To: common-lisp@sail.stanford.edu
Message-ID: <870803123923.1.RPK@ACORN.Gold-Hill.DialNet.Symbolics.COM>

Is the ftype of +

  (function (&rest number) number)

or

  (function (&rest list) number)

  ?

I would assume the former (since &rest args are always of type list), but
there aren't any examples in CLtL that make this clear.

∂03-Aug-87  1211	edsel!kent-state!eb@labrea.stanford.edu 	New special form suggestion: LET-CONSTANT   
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87  12:11:45 PDT
Received: by labrea.stanford.edu; Mon, 3 Aug 87 12:00:16 PDT
Received: from kent-state.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
	id AA10784; Mon, 3 Aug 87 12:08:32 PDT
Received: by kent-state.edsel.uucp (3.2/SMI-3.2)
	id AA11862; Mon, 3 Aug 87 12:05:52 PDT
Date: Mon, 3 Aug 87 12:05:52 PDT
From: edsel!kent-state!eb@labrea.stanford.edu (Eric Benson)
Message-Id: <8708031905.AA11862@kent-state.edsel.uucp>
To: labrea!barmar%Think.COM@labrea.stanford.edu
Cc: labrea!common-lisp%sail.stanford.edu@labrea.stanford.edu
In-Reply-To: Barry Margolin's message of Mon, 3 Aug 87 12:07 EDT <870803120736.7.BARMAR@NIETZSCHE.THINK.COM>
Subject: New special form suggestion: LET-CONSTANT

There's actually no need for a declaration or special form.  LET will
do fine all by itself.  If the expression to which the variable is
bound is constant and there are no SETQs to the variable, all
references to the variable may be legitimately replaced by the
constant expression.  This is a very common optimization in Lisp
compilers.  However, as far as I know it is not done by the Symbolics
compiler.

∂03-Aug-87  1315	vanroggen%aitg.decnet@hudson.dec.com 	LET-CONSTANT and DECLARE (CONSTANT   
Received: from HUDSON.DEC.COM by SAIL.STANFORD.EDU with TCP; 3 Aug 87  13:15:20 PDT
Date: 3 Aug 87 16:09:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: LET-CONSTANT and DECLARE (CONSTANT
To: "common-lisp" <common-lisp@su-ai.ARPA>
cc: vanroggen   
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>

Perhaps the complaint about "binding constants" isn't about the
constancy of association between a variable and its value, but about
whether the value happens to be read-only.

This would permit additional compiler optimizations regarding state
dependent functions like ELT.

Related question: are quoted constants in compiled functions "read-only"?
How about initial values for DEFCONSTANTs?

Is this what was intended by DECLARE (CONSTANT V)?

			---Walter
------

∂03-Aug-87  1317	Moon@SAPSUCKER.SCRC.Symbolics.COM 	New special form suggestion: LET-CONSTANT    
Received: from [128.81.41.223] by SAIL.STANFORD.EDU with TCP; 3 Aug 87  13:17:24 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 150921; Mon 3-Aug-87 16:18:16 EDT
Date: Mon, 3 Aug 87 16:18 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New special form suggestion: LET-CONSTANT
To: Eric Benson <edsel!kent-state!eb@labrea.stanford.edu>
cc: barmar@Think.COM, common-lisp@sail.stanford.edu
In-Reply-To: <8708031905.AA11862@kent-state.edsel.uucp>
Message-ID: <870803161813.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 3 Aug 87 12:05:52 PDT
    From: edsel!kent-state!eb@labrea.stanford.edu (Eric Benson)

    There's actually no need for a declaration or special form.  LET will
    do fine all by itself.  If the expression to which the variable is
    bound is constant and there are no SETQs to the variable, all
    references to the variable may be legitimately replaced by the
    constant expression.  This is a very common optimization in Lisp
    compilers.  However, as far as I know it is not done by the Symbolics
    compiler.

It isn't an optimization in the Symbolics 3600, for most constants.  The
same is true in any other machine that keeps variables in registers and
doesn't have an immediate addressing mode capable of accomodating all Lisp
constants, I believe.

I'm not disagreeing that it is useful for compilers to make this optimization
in the cases where it is in fact an optimization.  I think your reasoning for
why Common Lisp has DEFCONSTANT but no corresponding local form is correct:
the local form isn't needed since the compiler has access to everything in
the scope of a local variable and hence can infer the same information.

∂03-Aug-87  1340	RAM@C.CS.CMU.EDU 	LET-CONSTANT and DECLARE (CONSTANT   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87  13:39:57 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Mon 3 Aug 87 16:39:50-EDT
Date: Mon, 3 Aug 1987  16:39 EDT
Message-ID: <RAM.12323615129.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To:   common-lisp@SAIL.STANFORD.EDU
Subject: LET-CONSTANT and DECLARE (CONSTANT


    Date: Monday, 3 August 1987  16:09-EDT
    From: AITG::VANROGGEN <vanroggen%aitg.decnet at hudson.dec.com>
    To:   common-lisp <common-lisp at su-ai.ARPA>
    Re:   LET-CONSTANT and DECLARE (CONSTANT

    Related question: are quoted constants in compiled functions "read-only"?
    How about initial values for DEFCONSTANTs?

Yes and yes.  I believe that assuming that quoted constants are immutable
is widely accepted.  If the inital value to defconstant is quoted,
that the constant value would also be immutable.  In order to conclude
that constants are constant in the general case of an arbitrary
expression, I appeal to taste and common sense.

  Rob

∂03-Aug-87  1352	BROOKS%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	New special form suggestion: LET-CONSTANT  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87  13:52:39 PDT
Date: Mon, 3 Aug 1987  16:52 EDT
Message-ID: <BROOKS.12323617403.BABYL@MIT-OZ>
From: BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   barmar@THINK.COM, common-lisp@SAIL.STANFORD.EDU,
      Eric Benson <edsel!kent-state!eb@LABREA.STANFORD.EDU>
Subject: New special form suggestion: LET-CONSTANT
In-reply-to: Msg of 3 Aug 1987  16:18-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


EB:
                                If the expression to which the variable is
        bound is constant and there are no SETQs to the variable, all
        references to the variable may be legitimately replaced by the
        constant expression.

MOON:
    It isn't an optimization in the Symbolics 3600, for most constants.  The
    same is true in any other machine that keeps variables in registers and
    doesn't have an immediate addressing mode capable of accomodating all Lisp
    constants, I believe.

Actually that's not quite true. On the 68k in Lucid lisp for instance compare

1.  (let ((foo 'baz))
      (setf (car x) foo))

and

2.  (setf (car x) 'baz)

The symbol baz can't be represented as an immediate addressing mode. Instead
it is at some constant offset (inside any particular procedure)
from a closure pointer which is in a known register. There is a memory to memory
move on the 68k that can accomodate a source addressing mode that refers to
baz, and a destination mode that refers to (car x), assuming x is already in
a register. So case 2 takes one instruction, whereas case 1 under your description
would take two--one to move baz into the register used for foo, and one to move
that into (car x). Of course in this simple case a peephole optimizer should
be able to clean case 1 up, but if there is other intervening stuff around it
may not get it as easily as the source level transform.

So on some machines the optimization is more generally useful than your note implies.

∂03-Aug-87  1427	barmar@Think.COM 	New special form suggestion: LET-CONSTANT 
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Aug 87  14:27:11 PDT
Received: from nietzsche by Think.COM via CHAOS; Mon, 3 Aug 87 17:25:32 EDT
Date: Mon, 3 Aug 87 17:26 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: New special form suggestion: LET-CONSTANT
To: Eric Benson <edsel!kent-state!eb@labrea.stanford.edu>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8708031905.AA11862@kent-state.edsel.uucp>
Message-Id: <870803172620.2.BARMAR@NIETZSCHE.THINK.COM>

    Date: Mon, 3 Aug 87 12:05:52 PDT
    From: edsel!kent-state!eb@labrea.stanford.edu (Eric Benson)

    There's actually no need for a declaration or special form.  LET will
    do fine all by itself.  If the expression to which the variable is
    bound is constant and there are no SETQs to the variable, all
    references to the variable may be legitimately replaced by the
    constant expression.  This is a very common optimization in Lisp
    compilers.  However, as far as I know it is not done by the Symbolics
    compiler.

I thought of that, and rejected it.  I want to tell the compiler,
interpreter, and other programmers reading the code that a particular
name is a symbolic constant.  If I accidentally assign to it, I want the
system to produce an error message.  In Lisp this isn't a problem as
much as in my previous language, PL/I, because Lisp doesn't have call by
reference; however, I still prefer to code what I mean.

Someone else (DCP?) mentioned using MACROLET for this.  I also
considered this, and almost did it.  It just seemed more esthetically
unpleasing than the DEFCONSTANTs.  Now, if Symbolics had SYMBOL-MACROLET
to go with their DEFINE-SYMBOL-MACRO, I could use that (my code was a
Zmail extension, so I had no reason not to use Symbolics-only features)
(actually, I don't really care for symbol macros, because they allow a
function call to masquerade as a variable reference, which is really
confusing to the reader).

						barmar

∂03-Aug-87  1658	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: New special form suggestion: LET-CONSTANT   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Aug 87  16:58:43 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 205940; Mon 3-Aug-87 19:59:39 EDT
Date: Mon, 3 Aug 87 19:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: New special form suggestion: LET-CONSTANT 
To: common-lisp@sail.stanford.edu
In-Reply-To: <8708031628.AA00890@HADES.MIT.EDU>
Message-ID: <870803195934.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 03 Aug 87 12:28:38 EDT
    From: <samalone@ATHENA.MIT.EDU>

	It seems like a LET-CONSTANT special form....

    As an alternative, I recommend a CONSTANT declaration.

The Cleanup subcommittee of X3J13 were discussing just that in May, incidental
to another proposal for language cleanup.  Perhaps such a declaration is a good
idea.  Presumably it would mean that the compiler is allowed to assume that the
variable is never setq'ed and the variable's value is never side-effected
(e.g. if an array, its elements are not changed and not side-effected themselves),
and the compiler is encouraged to complain if it can prove that these assumptions
are violated.

Right now that cleanup proposal is in limbo but perhaps it will get more attention
later.

∂03-Aug-87  2039	edsel!bhopal!jonl@labrea.stanford.edu 	compile-time processing of REQUIRE  
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87  20:39:25 PDT
Received: by labrea.stanford.edu; Mon, 3 Aug 87 20:26:34 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
	id AA11997; Mon, 3 Aug 87 20:18:06 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
	id AA17170; Mon, 3 Aug 87 20:15:34 PDT
Date: Mon, 3 Aug 87 20:15:34 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8708040315.AA17170@bhopal.edsel.uucp>
To: labrea!snyder%hplabs@labrea.stanford.edu
Cc: labrea!common-lisp%sail@labrea.stanford.edu
In-Reply-To: Alan Snyder's message of Mon, 03 Aug 87 10:18:31 PDT <8708031718.AA03272@hplsny>
Subject: compile-time processing of REQUIRE 

You've jumped ahead into another problem -- that of the pervasiveness of
the COMPILE context.

But I was talking merely about the compiler's interface -- when and where
it decides to wrap an eval-when(eval compile load) around a form.  When the 
user supplies his own wrapper, e.g.

   (eval-when (eval load) (require "tarnation"))

then this form is not implicitly "wrapped", since the user's actions take
precedence over the implicit activity.  That is, Lucid's compiler does
NOT convert the above form into anything like.

   (eval-when (eval load) 
     (eval-when (eval compile load) (require "tarnation"))
   )

I wonder if this view of "implicit wrapping" is used in other compiler?


-- JonL --

∂03-Aug-87  2317	edsel!bhopal!jonl@labrea.stanford.edu 	LET-CONSTANT [or "Anonymous Constants"]  
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87  23:17:51 PDT
Received: by labrea.stanford.edu; Mon, 3 Aug 87 23:05:15 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
	id AA12283; Mon, 3 Aug 87 23:00:28 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
	id AA00205; Mon, 3 Aug 87 22:57:55 PDT
Date: Mon, 3 Aug 87 22:57:55 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8708040557.AA00205@bhopal.edsel.uucp>
To: labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu
Cc: bhopal!eb@labrea.stanford.edu, labrea!barmar%Think.COM@labrea.stanford.edu,
        labrea!common-lisp%sail@labrea.stanford.edu
In-Reply-To: David A. Moon's message of Mon, 3 Aug 87 16:18 EDT <870803161813.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: LET-CONSTANT [or "Anonymous Constants"]

A compiler can figure out that a local variable isn't being setq'd, and 
hence can propogate through the binding as a constant literal *providing*
that it can determine that the form it is being bound to is a constant.

Admittedly, that seems to be the thrust of the messages so far -- does
common lisp need a local constant declaration for variables -- and I 
think the answer is, as you phrase it, "no, because any information that 
such a declaration provides can equally well be discerned mechanically
by the compiler."  

But I see the need for a local constant declaration for random expressions 
apart from the issue of properties of program variables.  "Anonymous
Constants", if you will.  Consider for example Interlisp's [special-form] 
function CONSTANT:

   (let ((x (constant `(JonL-phone-no ,(call-up-bell-tel-co)))))
     (check-phone-book x) 
     (broadcast-to-friends x (constant (figger-out-broadcast-routing)))
     x)

Without the very-local "declaration" provided by 'constant', the compiler
would be obliged NOT to propogate the binding value of x, and not to
elide the runtim calls to 'call-up-bell-tel-co', 'list', and the totally
random 'figger-out-broadcast-routing'.  [And also not to create the list in
a static, or read-only area, etc.]

Using 'constant' rather than #. is more of an issue in Interlisp style 
-- the "residential" style as opposed to the EMACS style -- but I don't
think it should be ignored in CL.  In fact, a later addition to Interlisp 
was 'loadtimeconstant', which is a functionality that has been under active 
discussion on this mailing list in recent weeks.

-- JonL --

∂04-Aug-87  1057	@DIAMOND.S4CC.Symbolics.COM:Cyphers@YUKON.SCRC.Symbolics.COM 	New special form suggestion: LET-CONSTANT  
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 4 Aug 87  10:57:23 PDT
Received: from RAVEN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110013; Mon 3-Aug-87 12:30:09 EDT
Date: Mon, 3 Aug 87 12:29 EDT
From: Scott Cyphers <Cyphers@YUKON.SCRC.Symbolics.COM>
Subject: New special form suggestion: LET-CONSTANT
To: barmar@Think.COM, common-lisp@sail.stanford.edu
In-Reply-To: <870803120736.7.BARMAR@NIETZSCHE.THINK.COM>
Message-ID: <870803122946.7.CYPHERS@RAVEN.S4CC.Symbolics.COM>

    Date: Mon, 3 Aug 87 12:07 EDT
    From: Barry Margolin <barmar@Think.COM>

    Today I noticed myself creating DEFCONSTANTS for symbolic constants that
    would only be used by the one function I was writing.  It struck me that
    they really wanted to be local to the function, not top-level variables,
    but I wanted to make sure that the compiler would open-code them, and I
    also wanted to declare their constantness to readers.  There is
    currently no way to do this in Common Lisp (nor, as far as I know, in
    Symbolics Common Lisp, which I was using) without DEFCONSTANT, which
    also creates a useless special variable.

    It seems like a LET-CONSTANT special form, or an &CONSTANT lambda-list
    keyword, would be the right thing for this.  LET-CONSTANT would be to
    DEFPARAMETER what FLET is to DEFUN, and &CONSTANT would be analogous to
    &AUX.

I think a CONSTANT declaration would be better than a new special form.
It would be the value cell equivalent of the INLINE declaration for
functions.

    Actually, for consistency with the names FLET and MACROLET, I suppose
    this should be called CONSTANTLET (although to me that seems like the
    word for a little constant).  However, I never liked those names anyway.

						    barmar@think.com


∂06-Aug-87  0721	SOLEY@XX.LCS.MIT.EDU 	New special form suggestion: LET-CONSTANT  
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Aug 87  07:21:42 PDT
Date: Thu, 6 Aug 1987  10:18 EDT
Message-ID: <SOLEY.12324332217.BABYL@XX.LCS.MIT.EDU>
From: SOLEY@XX.LCS.MIT.EDU
To:   Barry Margolin <barmar@THINK.COM>
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: New special form suggestion: LET-CONSTANT
In-reply-to: Msg of 3 Aug 1987  12:07-EDT from Barry Margolin <barmar at Think.COM>

    Date: Monday, 3 August 1987  12:07-EDT
    From: Barry Margolin <barmar at Think.COM>

    Today I noticed myself creating DEFCONSTANTS for symbolic constants that
    would only be used by the one function I was writing.

A declaration would be much cleaner; you could still write let-constant
(or constantlet) in terms of it, as well as defconstant for that matter
[(proclaim '(constant ...))].

    It seems like a LET-CONSTANT special form, or an &CONSTANT lambda-list
    keyword, would be the right thing for this.  LET-CONSTANT would be to
    DEFPARAMETER what FLET is to DEFUN, and &CONSTANT would be analogous to
    &AUX.

Yeah, and how about an &LOGOUT lambda-list keyword, to log out the current
process?  Really, although I understand the trivial difference in scope
between LET and &AUX, do we need to continue adding random lambda-list
keywords, which (worse yet) aren't keywords at all?

	-- Richard

∂06-Aug-87  0809	gls@Think.COM 	New special form suggestion: LET-CONSTANT    
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 6 Aug 87  08:09:24 PDT
Return-Path: <gls@Think.COM>
Received: from boethius by Think.COM via CHAOS; Thu, 6 Aug 87 11:08:41 EDT
Date: Thu, 6 Aug 87 11:11 EDT
From: Guy Steele <gls@Think.COM>
Subject: New special form suggestion: LET-CONSTANT
To: SOLEY@xx.lcs.mit.edu, barmar@Think.COM
Cc: common-lisp@sail.stanford.edu, gls@Think.COM
In-Reply-To: <SOLEY.12324332217.BABYL@XX.LCS.MIT.EDU>
Message-Id: <870806111111.3.GLS@BOETHIUS.THINK.COM>

    Date: Thu, 6 Aug 1987  10:18 EDT
    From: SOLEY@xx.lcs.mit.edu

	Date: Monday, 3 August 1987  12:07-EDT
	From: Barry Margolin <barmar at Think.COM>
	...
	It seems like a LET-CONSTANT special form, or an &CONSTANT lambda-list
	keyword, would be the right thing for this.  LET-CONSTANT would be to
	DEFPARAMETER what FLET is to DEFUN, and &CONSTANT would be analogous to
	&AUX.

    Yeah, and how about an &LOGOUT lambda-list keyword, to log out the current
    process?  Really, although I understand the trivial difference in scope
    between LET and &AUX, do we need to continue adding random lambda-list
    keywords, which (worse yet) aren't keywords at all?

Oh, wow!  I don't mean to make fun of anyone, but you just gave me
a great idea for eliminating LOOP by folding it into LAMBDA.
(JONL, are you listening?  That old idea resurfaces in new syntax.)

(defun factorial (n &for j &from 1 &to n &for a &= 1 &then (* a j) &finally (return a)))

A great feature of this is that it defuses the old quibble of
whether or not LOOP "keywords" should be :-keywords by making
them be &-keywords.

We can get declarations in this way, too.

(defun factorial (n &integer n
			&for j &from 1 &to n
			&for a &= 1 &then (* a j)
			&integer j a
			&finally (return a)))

Also, let's do for English as for Lisp and replace documentation
strings.  What's sauce for the goose is sauce for the gander.


(defun factorial (n &integer n
			&for j &from 1 &to n
			&for a &= 1 &then (* a j)
			&integer j a
			&finally (return a))
			&documentation &factorial &takes &a &nonnegative
				&integer &n &and &returns &the &product &of
				&all &positive &integers ¬ &greater
				&than &n &.)

&Maybe &I &could &get &to &like &this &language &after &all &.

--Quux

∂06-Aug-87  1308	sandra%orion@cs.utah.edu 	truename, merge-pathnames, etc.   
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 6 Aug 87  13:08:44 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
	id AA29865; Thu, 6 Aug 87 14:11:17 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
	id AA16097; Thu, 6 Aug 87 14:11:14 MDT
Date: Thu, 6 Aug 87 14:11:14 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8708062011.AA16097@orion.utah.edu>
Subject: truename, merge-pathnames, etc.
To: common-lisp@sail.stanford.edu

I'm having a problem with incorrect expansion of pathnames under VMS, when
logical names are used.  The problem happens when I, or the Lisp runtime, does
something like

    (merge-pathnames "LIBRARY:" *default-pathname-defaults*)

My logical name "LIBRARY:" is likely to translate to a string that supplies
both a device and directory.  However, the Lisp doesn't do the translation and
is instead pulling the directory from *default-pathname-defaults*, with the
end result that it builds up a pathname pointing to the wrong place.  I can't
use TRUENAME to force translation of the logical name first, because it 
complains about not being able to find a file that matches the incomplete
specification.  And, I can't build up a complete file specification to give
to TRUENAME because of the other problem.  Perhaps we need another function
like TRUENAME that just does the name translation without checking to see
that the file exists?

-Sandra
-------

∂06-Aug-87  1612	RWK@YUKON.SCRC.Symbolics.COM 	truename, merge-pathnames, etc.    
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 6 Aug 87  16:12:06 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 246352; Thu 6-Aug-87 19:07:56 EDT
Date: Thu, 6 Aug 87 19:07 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: truename, merge-pathnames, etc.
To: Sandra J Loosemore <sandra%orion@cs.utah.edu>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8708062011.AA16097@orion.utah.edu>
Message-ID: <870806190756.3.RWK@WHITE-BIRD.SCRC.Symbolics.COM>

    Date: Thu, 6 Aug 87 14:11:14 MDT
    From: sandra%orion@cs.utah.edu (Sandra J Loosemore)

    I'm having a problem with incorrect expansion of pathnames under VMS, when
    logical names are used.  The problem happens when I, or the Lisp runtime, does
    something like

	(merge-pathnames "LIBRARY:" *default-pathname-defaults*)

    My logical name "LIBRARY:" is likely to translate to a string that supplies
    both a device and directory.  However, the Lisp doesn't do the translation and
    is instead pulling the directory from *default-pathname-defaults*, with the
    end result that it builds up a pathname pointing to the wrong place.  I can't
    use TRUENAME to force translation of the logical name first, because it 
    complains about not being able to find a file that matches the incomplete
    specification.  And, I can't build up a complete file specification to give
    to TRUENAME because of the other problem.  Perhaps we need another function
    like TRUENAME that just does the name translation without checking to see
    that the file exists?

    -Sandra
    -------

This is what :UNSPECIFIC as a pathname component is good for.
(Not that we implement it in this particular case, either).
The people who borrowed the Symbolics pathname system for
Common Lisp emasculated it without understanding it.

The idea is that if a pathname *isn't supposed to have* certain
components, then you use :UNSPECIFIC.  If they're just not supplied
yet, use NIL.  Then MERGE-PATHNAMES can figure out the right thing
to do for itself.

Of course, this moves the burden onto the shoulders of PARSE-PATHNAME.
For UNIX pathnames (distinguishing between "foo", and "foo.", and
"foo" with no type specified yet), this is apparent from the syntax.
Since the designers of VMS didn't choose to make their pathname syntax
independent of run-time context (boo, hiss!), PARSE-PATHNAME has to
be able to ask the operating system what logical pathname translations
are in effect at the time.

The pathname section of CLtL is full of gotcha's like this.  It is
in need of some serious cleanup.

∂07-Aug-87  2215	@RELAY.CS.NET:HELLER@cs.umass.edu 	RE: truename, merge-pathnames, etc.
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 7 Aug 87  22:15:09 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ad05638; 8 Aug 87 1:12 EDT
Received: from cs.umass.edu by RELAY.CS.NET id ak07820; 8 Aug 87 1:04 EDT
Date: Fri, 7 Aug 87 09:06 EDT
From: Stride 440 User <HELLER%cs.umass.edu@RELAY.CS.NET>
Subject: RE: truename, merge-pathnames, etc.
To: Common-lisp@SAIL.STANFORD.EDU
X-VMS-To: IN%"Common-lisp@SAIL.STANFORD.EDU"

>From:	IN%"Sandra J Loosemore <sandra%orion@CS.UTAH.EDU>"  7-AUG-1987 04:58
>Subj:	truename, merge-pathnames, etc.
>
>I'm having a problem with incorrect expansion of pathnames under VMS, when
>logical names are used.  The problem happens when I, or the Lisp runtime, does
>something like
>
>    (merge-pathnames "LIBRARY:" *default-pathname-defaults*)
>
>My logical name "LIBRARY:" is likely to translate to a string that supplies
>both a device and directory.  However, the Lisp doesn't do the translation and
>is instead pulling the directory from *default-pathname-defaults*, with the
>end result that it builds up a pathname pointing to the wrong place.  I can't
>use TRUENAME to force translation of the logical name first, because it 
>complains about not being able to find a file that matches the incomplete
>specification.  And, I can't build up a complete file specification to give
>to TRUENAME because of the other problem.  Perhaps we need another function
>like TRUENAME that just does the name translation without checking to see
>that the file exists?
>
>-Sandra
>-------
>

Hm... What version of VAX-LISP are you using?  I just did some tests and it
actually works ok for me:

Lisp> (translate-logical-name "LLVS")
("LLVS$DISK:[LLVS]")

Lisp> (merge-pathnames "LLVS:" *default-pathname-defaults*)
#S(pathname :host "VAX9" :device "VIS3$DISK" :directory "LLVS" :name nil
	    :type nil :version :newest)

Lisp>  *default-pathname-defaults*
#S(pathname :host "VAX9" :device "VIS$DISK" 
	    :directory "HELLER.VISION.NEW_SYSTEM" :name nil :type nil
	    :version nil)

For completeness I also tried:

Lisp> (merge-pathnames (pathname "LLVS:") *default-pathname-defaults*)
#S(pathname :host "VAX9" :device "VIS3$DISK" :directory "LLVS" :name nil
	    :type nil :version :newest)

I think the last version is probably safest, since it forces the logical
name to be processed into a proper pathname.  There is still a problem with
search lists (logical names with a list of values).  For that you probably
should not use merge-pathnames at all - instead use concatenate to create an
un-parsed filename string and use probe-file to fetch the actual path.
(Probe-file correctly handle search lists, since it calls RMS to search
for the file (probably with a SYS$SEARCH call).)

BTW:  we are running VMS 4.5 and VAX-LISP U2.2 (yes we are a field test
site).  

		Robert Heller
ARPANet:	Heller@CS.UMass.EDU
BITNET:		Heller@UMass.BITNET
BIX:		Heller
GEnie:		RHeller
FidoNet:	321/148 (Locks Hill BBS, Wendell, MA)
CompuServe	71450,3432
Local PV VAXen:	COINS::HELLER
UCC Cyber/DG:	Heller@CS

∂08-Aug-87  0858	sandra%orion@cs.utah.edu 	RE: truename, merge-pathnames, etc.    
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 8 Aug 87  08:58:21 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
	id AA03714; Sat, 8 Aug 87 10:00:58 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
	id AA21647; Sat, 8 Aug 87 10:00:54 MDT
Date: Sat, 8 Aug 87 10:00:54 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8708081600.AA21647@orion.utah.edu>
To: HELLER%cs.umass.edu@relay.cs.net
Cc: common-lisp@sail.stanford.edu
Subject: RE: truename, merge-pathnames, etc.
News-Path: utah-cs!@SAIL.STANFORD.EDU,@RELAY.CS.NET:HELLER@cs.umass.edu
References: <8708080541.AA18042@cs.utah.edu>

Actually, I was having the problem with Lucid Lisp.  VaxLisp does 
indeed handle logical names in a "reasonable" manner, but after
rereading CLtL I've decided that its behavior is probably technically
incorrect, and that Lucid's behavior is correct.  That is, CLtL implies
that PARSE-NAMESTRING and MERGE-PATHNAMES are only supposed to operate
on pathname *syntax* without regard to the *semantics* attached to the
various components by the underlying file system.  Translation is
mentioned only in the context of TRUENAME.

Your idea with concatenating and using probe-file won't work either,
first of all because it's nonportable (the whole reason for having the
pathname functions in the first place is to avoid this kind of
operation), and secondly because I may be trying to build the name of a
file that doesn't exist yet.

Also, this problem is not specific to VMS.  You can get into the same
problem under Un*x if your Lisp supports the use of environment variables
or shell variables in filenames.

-Sandra

∂08-Aug-87  1347	RAM@C.CS.CMU.EDU 	truename, merge-pathnames, etc. 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Aug 87  13:46:53 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Sat 8 Aug 87 16:46:33-EDT
Date: Sat, 8 Aug 1987  16:46 EDT
Message-ID: <RAM.12324927073.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To:   sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ
Cc:   common-lisp@SAIL.STANFORD.EDU
Subject: truename, merge-pathnames, etc.
In-reply-to: Msg of 6 Aug 1987  16:11-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore)


In CMU Common Lisp, we have hacked around these problems by playing
with the rules for filename parsing.  Although the result may be
somewhat nonintuitive, it is legal common Lisp, since the 
namestring => pathname translation is not specified.  Parse-Namestring
contrives to translate pathnames so that Merge-Pathnames "works
right".  This is mostly done by by sticking special values in the
pathname, and is probably similar to the notion of :Unspecified.

For example, we get around to problem you mention by having:
   (pathname-device "foo:")  =>  #()
That is, a namestring that specifies only a device is translated so as
to make explcit that a directory is being specified as well.  The
directory has no components, so NAMESTRING translates back to the
original namestring, but merging of other directories in inhibited.
We are currently running on a Unix filesystem.  Since Unix has no
notion of devices or logical names, we use the pathname device field
for a "search list" mechanism that is implemented by Lisp.  If we were
on a filesystem where devices meant anything, then this hack probably
wound't work so well.

There are also some other cases in which merging is inhibited by the
appropriate namestring translation:
  (pathname-device "/foo/")  =>  :ABSOLUTE
  (pathname-device "foo/")  =>  "Default"
  (pathname-type "foo.")  =>  ""

I agree that Common Lisp should address this, and think that a general
solution would be appropriate, but it is possible in many cases to do
the right thing within the constraints of the current MERGE-PATHNAMES
definition by tweaking the namestring translation.

  Rob

∂09-Aug-87  1439	tsf@theory.cs.cmu.edu 	Continuation Passing Style?
Received: from THEORY.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Aug 87  14:39:07 PDT
Date: Sunday, 9 August 1987 17:40:16 EDT
From: Timothy.Freeman@theory.cs.cmu.edu
To: common-lisp@sail.stanford.edu
Subject: Continuation Passing Style?
Message-ID: <1987.8.9.21.29.37.Timothy.Freeman@theory.cs.cmu.edu>

Does anyone have any code to transform some subset of Common Lisp into
continuation passing style?  How about some idea of what that subset
would have to be?  

If you have a response, please mail it to me as well as the mailing
list, because I no longer read this mailing list.

∂10-Aug-87  1216	wile@vaxa.isi.edu 	Test suite available 
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 10 Aug 87  12:16:03 PDT
Posted-Date: Mon, 10 Aug 87 12:16:23 PDT
Message-Id: <8708101916.AA00282@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
	id AA00282; Mon, 10 Aug 87 12:16:28 PDT
To: COMMON-LISP@sail.stanford.edu
From: wile@vaxa.isi.edu
Subject: Test suite available
Date: Mon, 10 Aug 87 12:16:23 PDT
Sender: wile@vaxa.isi.edu


Folks--


A Common Lisp Validation Suite has been assembled here at ISI by Richard
Berman.  He essentially developed a test driver and has converted
portions of the suites of some of the vendors to his format.  The suite
contains only a small fraction of the tests he has received, but it is a
start for anyone responsible for quality assurance of CL
implementations. 

Unfortunately for us, Richard resigned recently (to go off and become a
recording star and/or AI in music guru), so there will be little
additional support or development until a replacement for him is found.

Although several of you are aware of the existence of this suite, we
have been told that many interested parties were not; hence, this
message.  To access the suite, ftp to venera.isi.edu logging in as
anonymous.  Please respond with your name and affiliation as the
password.  The two directories of interest are: /usr/ftp/Valid-Code/*.*
and /usr/ftp/Valid-Tests/*.*.  (Capitalization is necessary.)  The file
README.NOW contains the information necessary to understand how to
invoke the test suite and what files to transfer to your machine.
Apparently around 400 tests are available now.  

We have no way to monitor the activity on the files, except with the ftp
log of your anonymous password.  We would very much appreciate hearing
about any successes, problems, or suggestions (perhaps as to which
remaining tests to convert first) you have.  Send mail to
WILE@VAXA.ISI.EDU for now.

					Testily yours,
					Dave Wile
					USC/ Information Sciences Institute
					(213) 822-1511