perm filename COMMON.MSG[COM,LSP]39 blob sn#840437 filedate 1987-05-25 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00262 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00038 00002	
C00039 00003	∂12-Apr-87  0005	kempf%hplabsc@hplabs.HP.COM 	Re:  redefining Common Lisp functions    
C00042 00004	∂12-Apr-87  1750	edsel!bhopal!jonl@navajo.stanford.edu 	all symbols [and delayed mail] 
C00047 00005	∂12-Apr-87  1751	edsel!bhopal!jonl@navajo.stanford.edu 	redefining Common Lisp functions    
C00049 00006	∂12-Apr-87  2225	HEWETT@SUMEX-AIM.STANFORD.EDU 	Redefining CL fns  
C00051 00007	∂13-Apr-87  1018	sears%wrs.DEC@decwrl.DEC.COM 	Re:  Redefining Common LISP Functions, MACROS and Special Forms  
C00055 00008	∂13-Apr-87  1216	gls@Think.COM 	redefining Common Lisp functions   
C00058 00009	∂13-Apr-87  1516	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	Compiling CASE 
C00064 00010	∂13-Apr-87  1528	@diamond.s4cc.symbolics.com:DCP@QUABBIN.SCRC.Symbolics.COM 	Compiling CASE 
C00070 00011	∂13-Apr-87  2016	DON%atc.bendix.com@RELAY.CS.NET 	Inconsistent keywords for sequence functions   
C00072 00012	∂14-Apr-87  0747	ROSENKING@A.ISI.EDU 	Redefinition of CL Functions 
C00079 00013	∂14-Apr-87  0851	kempf%hplabsc@hplabs.HP.COM 	Re:  Redefinition of CL Functions   
C00082 00014	∂14-Apr-87  0924	RAM@C.CS.CMU.EDU 	Redefinition of CL Functions    
C00085 00015	∂14-Apr-87  0949	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re:  Redefinition of CL Functions    
C00088 00016	∂14-Apr-87  1010	sears%wrs.DEC@decwrl.DEC.COM 	Re:  Inconsistencies in Sequence Function Arguments    
C00090 00017	∂14-Apr-87  1013	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Inconsistent keywords for sequence functions    
C00093 00018	∂14-Apr-87  1131	Moon@STONY-BROOK.SCRC.Symbolics.COM 	redefining Common Lisp functions 
C00097 00019	∂14-Apr-87  1148	VERACSD@A.ISI.EDU 	Format
C00098 00020	∂14-Apr-87  1204	FAHLMAN@C.CS.CMU.EDU 	Format  
C00100 00021	∂14-Apr-87  1706	sears%wrs.DEC@decwrl.DEC.COM 	Re:  Redefinition of CL Functions  
C00103 00022	∂14-Apr-87  1829	jcm@ORNL-MSR.ARPA 	Flavors and DEC's VMS Common Lisp?  
C00105 00023	∂14-Apr-87  2056	kempf%hplabsc@hplabs.HP.COM 	Re: Redefinition of Common Lisp Functions
C00110 00024	∂14-Apr-87  2256	MURRAY%cs.umass.edu@RELAY.CS.NET 	EVAL-WHEN symbols    
C00112 00025	∂15-Apr-87  0236	pyramid!pyramid.UUCP!bein@hplabs.HP.COM 	macroexpand inside of macrolet... 
C00116 00026	∂15-Apr-87  0818	FAHLMAN@C.CS.CMU.EDU 	Redefinition of Common Lisp Functions 
C00119 00027	∂15-Apr-87  0818	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	macroexpand inside of macrolet...  
C00122 00028	∂15-Apr-87  0903	FAHLMAN@C.CS.CMU.EDU 	EVAL-WHEN symbols 
C00124 00029	∂15-Apr-87  0955	weeks%hplbgw%hplb29a@hplabs.HP.COM 	Re:  EVAL-WHEN symbols  
C00126 00030	∂15-Apr-87  0957	Masinter.pa@Xerox.COM 	Re: macroexpand inside of macrolet...
C00128 00031	∂15-Apr-87  1034	Masinter.pa@Xerox.COM 	Re: EVAL-WHEN symbols 
C00130 00032	∂15-Apr-87  1306	Mailer@XX.LCS.MIT.EDU 	Compiling CASE   
C00133 00033	∂15-Apr-87  2258	sandra%orion@cs.utah.edu 	bignums are bogus  
C00138 00034	∂16-Apr-87  0834	FAHLMAN@C.CS.CMU.EDU 	bignums are bogus 
C00141 00035	∂16-Apr-87  0834	RAM@C.CS.CMU.EDU 	bignums are bogus
C00146 00036	∂16-Apr-87  0837	vrotney@vaxa.isi.edu 	CLARIFICATION: [italics]package arguments. 
C00148 00037	∂16-Apr-87  0859	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	bignums are bogus   
C00151 00038	∂16-Apr-87  0930	DLA@DIAMOND.S4CC.Symbolics.COM 	bignums are bogus 
C00152 00039	∂16-Apr-87  0946	RPG   	a lisp1 compatible subset of Common Lisp   
C00166 00040	∂16-Apr-87  1009	shebs%orion@cs.utah.edu 	Bognumosity    
C00169 00041	∂16-Apr-87  1042	jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	Re:  bignums are bogus   
C00172 00042	∂16-Apr-87  1054	FAHLMAN@C.CS.CMU.EDU 	Bognumosity  
C00175 00043	∂16-Apr-87  1124	KMP@STONY-BROOK.SCRC.Symbolics.COM 	bignums are bogus, but so are fixnums  
C00181 00044	∂16-Apr-87  1211	shebs%orion@cs.utah.edu 	Re:  Bognumosity    
C00186 00045	∂16-Apr-87  1216	DALY@IBM.COM 	typos in Cltl   
C00187 00046	∂16-Apr-87  1237	hoey@nrl-aic.ARPA 	Re: Bognumosity 
C00189 00047	∂16-Apr-87  1310	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re:  Bognumosity 
C00192 00048	∂16-Apr-87  1317	sdcrdcf!darrelj@CS.UCLA.EDU 	Re: bignums are bogus
C00195 00049	∂16-Apr-87  1349	@SAIL.STANFORD.EDU:REM@IMSSS 	How much memory for bignum or other large data structure?   
C00206 00050	∂16-Apr-87  1354	shebs%orion@cs.utah.edu 	Re:  Bognumosity    
C00209 00051	∂16-Apr-87  1403	preece%mycroft@gswd-vms.ARPA 	Re: Bognumosity
C00213 00052	∂16-Apr-87  1411	preece%mycroft@gswd-vms.ARPA 	Re: Bognumosity
C00217 00053	∂16-Apr-87  1419	edsel!bhopal!jonl@navajo.stanford.edu 	bignums are bogus    
C00220 00054	∂16-Apr-87  1426	FAHLMAN@C.CS.CMU.EDU 	bignums are bogus, but so are fixnums 
C00223 00055	∂16-Apr-87  1511	Masinter.pa@Xerox.COM 	bignums are bogus
C00225 00056	∂16-Apr-87  1513	hoey@nrl-aic.ARPA 	Re: How much memory for bignum or other large data structure?
C00230 00057	∂16-Apr-87  1517	Pavel.pa@Xerox.COM 	Re: typos in Cltl   
C00232 00058	∂16-Apr-87  1605	sandra%orion@cs.utah.edu 	bugnums (er, bignums)   
C00237 00059	∂16-Apr-87  1632	ghenis.pasa@Xerox.COM 	SOME and Multiple Values   
C00239 00060	∂16-Apr-87  1652	Masinter.pa@Xerox.COM 	Uncle Lisp Needs You  
C00241 00061	∂16-Apr-87  1703	pyramid!pyramid.UUCP!bein@hplabs.HP.COM 	Re: Bognumosity    
C00245 00062	∂16-Apr-87  1703	ghenis.pasa@Xerox.COM 	SETF and pathname slots    
C00247 00063	∂16-Apr-87  1736	FAHLMAN@C.CS.CMU.EDU 	SOME and Multiple Values    
C00249 00064	∂16-Apr-87  1917	diamant%hpfclp@hplabs.HP.COM 	Re: CLARIFICATION: [italics]package arguments.    
C00253 00065	∂16-Apr-87  2012	DON%atc.bendix.com@RELAY.CS.NET 	Bignums are bogus?    
C00255 00066	∂16-Apr-87  2137	fateman@mike.Berkeley.EDU 	Re:  Bignums are bogus?
C00257 00067	∂17-Apr-87  0723	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re: CLARIFICATION: [italics]package arguments. 
C00260 00068	∂17-Apr-87  0731	FAHLMAN@C.CS.CMU.EDU 	time to reactivate cl-cleanup    
C00263 00069	∂17-Apr-87  0959	RWK@YUKON.SCRC.Symbolics.COM 	SETF and pathname slots  
C00266 00070	∂17-Apr-87  1115	diamant%hpfclp@hplabs.HP.COM 	Re: CLARIFICATION: [italics]package arguments.    
C00270 00071	∂17-Apr-87  1122	Masinter.pa@Xerox.COM 	Re: time to reactivate cl-cleanup    
C00272 00072	∂17-Apr-87  1145	FAHLMAN@C.CS.CMU.EDU 	time to reactivate cl-cleanup    
C00275 00073	∂17-Apr-87  1200	Moon@ALDERAAN.SCRC.Symbolics.COM 	Language extensions (formerly [italics]package arguments.)   
C00280 00074	∂17-Apr-87  1329	FAHLMAN@C.CS.CMU.EDU 	Issue: FLET-IMPLICIT-BLOCK (Revision 4)    
C00289 00075	∂17-Apr-87  1408	FAHLMAN@C.CS.CMU.EDU 	Issue: FLET-IMPLICIT-BLOCK (Revision 5)    
C00298 00076	∂17-Apr-87  1525	Masinter.pa@Xerox.COM 	Issue: FUNCTION-TYPE (version 2)
C00306 00077	∂17-Apr-87  1536	Masinter.pa@Xerox.COM 	Issue FORMAT-ATSIGN-COLON (Version 3)
C00309 00078	∂17-Apr-87  1608	vrotney@vaxa.isi.edu 	Re: CLARIFICATION: [italics]package arguments.  
C00311 00079	∂17-Apr-87  1633	Masinter.pa@Xerox.COM 	Issue IF-BODY (Version 3)  
C00319 00080	∂17-Apr-87  1634	Masinter.pa@Xerox.COM 	status.report    
C00325 00081	∂17-Apr-87  1737	FAHLMAN@C.CS.CMU.EDU 	Issue: COMPILER-WARNING-STREAM (Revision 4)
C00330 00082	∂17-Apr-87  2007	FAHLMAN@C.CS.CMU.EDU 	Issue: DO-SYMBOLS-DUPLICATES (Revision 1)  
C00334 00083	∂17-Apr-87  2109	vrotney@vaxa.isi.edu 	Sec.11.7 [italics]package arguments.  
C00338 00084	∂17-Apr-87  2121	edsel!bhopal!jonl@navajo.stanford.edu 	CLARIFICATION: [italics]package arguments.    
C00342 00085	∂17-Apr-87  2229	MURRAY%cs.umass.edu@RELAY.CS.NET 	OR and Multiple Values    
C00345 00086	∂17-Apr-87  2236	MURRAY%cs.umass.edu@RELAY.CS.NET 	Fixnums Bogus   
C00347 00087	∂18-Apr-87  0049	Mailer@XX.LCS.MIT.EDU 	OR and Multiple Values
C00354 00088	∂18-Apr-87  0538	RPG  	Packages 
C00355 00089	∂18-Apr-87  1251	REM@IMSSS 	OR if some argument returns no values  
C00357 00090	∂18-Apr-87  1407	diamant%hpfclp@hplabs.HP.COM 	Re: CLARIFICATION: [italics]package arguments.    
C00362 00091	∂18-Apr-87  1444	FAHLMAN@C.CS.CMU.EDU 	OR if some argument returns no values 
C00364 00092	∂18-Apr-87  1628	Randy%acorn%LIVE-OAK.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	Re: SETF and pathname slots  
C00367 00093	∂18-Apr-87  1922	FAHLMAN@C.CS.CMU.EDU 	Environment-Arguments  
C00371 00094	∂18-Apr-87  2215	MURRAY%cs.umass.edu@RELAY.CS.NET 	MULTIPLE-VALUE-OR, and Consing 
C00375 00095	∂19-Apr-87  1029	primerd!doug@enx.prime.pdn 	Bigosities  
C00377 00096	∂19-Apr-87  1726	sandra%orion@cs.utah.edu 	Re: Bigosities
C00380 00097	∂19-Apr-87  1802	FAHLMAN@C.CS.CMU.EDU 	Issue ADJUST-ARRAY-DISPLACEMENT  
C00387 00098	∂19-Apr-87  2028	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue IF-BODY (Version 4)    
C00403 00099	∂19-Apr-87  2054	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: COMPILER-WARNING-STREAM (Revision 4) 
C00411 00100	∂19-Apr-87  2110	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: DO-SYMBOLS-DUPLICATES (Revision 1)   
C00415 00101	∂19-Apr-87  2115	FAHLMAN@C.CS.CMU.EDU 	Issue: COMPILER-WARNING-STREAM (Revision 4)
C00418 00102	∂19-Apr-87  2134	FAHLMAN@C.CS.CMU.EDU 	Issue: DO-SYMBOLS-DUPLICATES (Revision 1)  
C00421 00103	∂20-Apr-87  0625	DALY@IBM.COM 	Pavel's reply   
C00422 00104	∂20-Apr-87  0658	FAHLMAN@C.CS.CMU.EDU 	Issue IF-BODY (Version 4)   
C00431 00105	∂20-Apr-87  0658	preece%mycroft@gswd-vms.ARPA 	Bigosities
C00434 00106	∂20-Apr-87  0805	gls@Think.COM 	bignums are bogus   
C00436 00107	∂20-Apr-87  1027	RPG   	On the Kanji feature of Common Lisp   
C00440 00108	∂20-Apr-87  1126	Pavel.pa@Xerox.COM 	Re: Issue IF-BODY (Version 4) 
C00443 00109	∂20-Apr-87  1235	Moon@STONY-BROOK.SCRC.Symbolics.COM 	MULTIPLE-VALUE-OR, and Consing   
C00448 00110	∂20-Apr-87  1236	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Environment-Arguments  
C00454 00111	∂20-Apr-87  1448	Masinter.pa@Xerox.COM 	Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)    
C00457 00112	∂20-Apr-87  1358	Masinter.pa@Xerox.COM 	Re: Issue IF-BODY (Version 4)   
C00459 00113	∂20-Apr-87  1358	Masinter.pa@Xerox.COM 	Re: Issue: COMPILER-WARNING-STREAM (Revision 4)
C00461 00114	∂20-Apr-87  1420	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)    
C00467 00115	∂20-Apr-87  1517	Masinter.pa@Xerox.COM 	status 
C00474 00116	∂20-Apr-87  1653	Masinter.pa@Xerox.COM 	Re: Issue ADJUST-ARRAY-DISPLACEMENT  
C00476 00117	∂20-Apr-87  1911	FAHLMAN@C.CS.CMU.EDU 	Issue: COMPILER-WARNING-STREAM (Revision 4)
C00478 00118	∂21-Apr-87  0400	jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	Re: Re:  Bignums are bogus?   
C00481 00119	∂21-Apr-87  0747	FAHLMAN@C.CS.CMU.EDU 	Environment-Arguments  
C00486 00120	∂21-Apr-87  0814	Hvatum.DLAB@MIT-MULTICS.ARPA 	"Redefining" functions   
C00490 00121	∂21-Apr-87  0814	Hvatum.DLAB@MIT-MULTICS.ARPA 	Compiling CASE 
C00496 00122	∂21-Apr-87  0918	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue ADJUST-ARRAY-DISPLACEMENT  
C00499 00123	∂21-Apr-87  0919	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: FLET-IMPLICIT-BLOCK (Revision 5)    
C00501 00124	∂21-Apr-87  0920	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Environment-Arguments  
C00509 00125	∂21-Apr-87  0921	KMP@STONY-BROOK.SCRC.Symbolics.COM 	IF-BODY  
C00512 00126	∂21-Apr-87  1051	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
C00516 00127	∂21-Apr-87  1155	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Environment-Arguments  
C00518 00128	∂21-Apr-87  1215	FAHLMAN@C.CS.CMU.EDU 	IF-BODY 
C00520 00129	∂21-Apr-87  1222	FAHLMAN@C.CS.CMU.EDU 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)    
C00523 00130	∂21-Apr-87  1253	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
C00525 00131	∂21-Apr-87  1303	goldman@vaxa.isi.edu 	MULTIPLE-VALUES, consing, and clarity 
C00529 00132	∂21-Apr-87  1425	@DIAMOND.S4CC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	MULTIPLE-VALUES, consing, and clarity    
C00531 00133	∂21-Apr-87  1506	Pavel.pa@Xerox.COM 	Re: MULTIPLE-VALUES, consing, and clarity    
C00533 00134	∂21-Apr-87  1450	Pavel.pa@Xerox.COM 	[Gregor.pa: Re: ["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>: 
C00538 00135	∂21-Apr-87  1655	Moon@STONY-BROOK.SCRC.Symbolics.COM 	MULTIPLE-VALUES, consing, and clarity 
C00540 00136	∂21-Apr-87  1659	Moon@STONY-BROOK.SCRC.Symbolics.COM 	[Gregor.pa: Re: ["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>:    
C00543 00137	∂21-Apr-87  2309	MURRAY%cs.umass.edu@RELAY.CS.NET 	MULTPLE-VALUE-OR &rest args    
C00550 00138	∂22-Apr-87  1116	rauen@CLS.LCS.MIT.EDU 	Streams
C00552 00139	∂22-Apr-87  1232	KMP@STONY-BROOK.SCRC.Symbolics.COM 	ASSOC-RASSOC-IF-KEY (Version 1)   
C00556 00140	∂22-Apr-87  1343	KMP@STONY-BROOK.SCRC.Symbolics.COM 	AREF-1D  
C00561 00141	∂22-Apr-87  1351	KMP@STONY-BROOK.SCRC.Symbolics.COM 	ADJUST-ARRAY-NOT-ADJUSTABLE  
C00568 00142	∂22-Apr-87  2307	Moon@STONY-BROOK.SCRC.Symbolics.COM 	UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT 
C00574 00143	∂23-Apr-87  1205	smith@nrl-aic.ARPA 	A simple question   
C00576 00144	∂23-Apr-87  1250	Moon@STONY-BROOK.SCRC.Symbolics.COM 	A simple question 
C00578 00145	∂23-Apr-87  1255	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	A simple question   
C00581 00146	∂23-Apr-87  1313	REM@IMSSS 	Just for fun (NULL of NULL is identity)
C00583 00147	∂23-Apr-87  1822	RWK@YUKON.SCRC.Symbolics.COM 	A simple question   
C00586 00148	∂23-Apr-87  1858	KMP@STONY-BROOK.SCRC.Symbolics.COM 	A simple question  
C00591 00149	∂23-Apr-87  2022	RWK@YUKON.SCRC.Symbolics.COM 	Streams   
C00594 00150	∂23-Apr-87  2338	edsel!bhopal!jonl@navajo.stanford.edu 	A simple question    
C00596 00151	∂24-Apr-87  0741	decvax!cvbnet!admin!tbardasz@decwrl.DEC.COM 	Mailing List   
C00598 00152	∂24-Apr-87  0752	smith@nrl-aic.ARPA 	Re: A simple question    
C00600 00153	∂24-Apr-87  0843	DALY@IBM.COM 	CLtL typos list 
C00602 00154	∂24-Apr-87  2307	coffee@aerospace.aero.org 	Re: A simple question  
C00605 00155	∂25-Apr-87  0052	VERACSD@A.ISI.EDU 	Pronunciation   
C00606 00156	∂25-Apr-87  2132	@po5.andrew.cmu.edu:zs01#@andrew.cmu.edu 	Re: Pronunciation 
C00608 00157	∂25-Apr-87  2341	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Pronunciation 
C00610 00158	∂27-Apr-87  1008	unido!gmdzi!LISPM-1.GMD!@lispm-1.gmd.jc 	Pronunciation 
C00613 00159	∂27-Apr-87  1110	Moon@STONY-BROOK.SCRC.Symbolics.COM 	MULTPLE-VALUE-OR &rest args 
C00617 00160	∂27-Apr-87  1119	coffee@aerospace.aero.org 	Cleaning up predicate returns    
C00622 00161	∂27-Apr-87  1206	larus@paris.Berkeley.EDU 	(reduce #'or ...)  
C00624 00162	∂27-Apr-87  1338	quiroz@rochester.arpa 	Re: (reduce #'or ...) 
C00627 00163	∂27-Apr-87  1340	coffee@aerospace.aero.org 	Very BIG "T" 
C00629 00164	∂27-Apr-87  1517	Mailer@XX.LCS.MIT.EDU 	(reduce #'or ...)
C00632 00165	∂28-Apr-87  2212	MURRAY%cs.umass.edu@RELAY.CS.NET 	MULTIPLE-VALUES OR   
C00636 00166	∂28-Apr-87  2240	MURRAY%cs.umass.edu@RELAY.CS.NET 	(REDUCE #'OVERHEAD (MAP ...))  
C00640 00167	∂29-Apr-87  1407	gls@Think.COM 	CLtL typos list
C00643 00168	∂30-Apr-87  1113	@ACORN.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU 	(REDUCE #'OVERHEAD (MAP ...))  
C00645 00169	∂30-Apr-87  1355	FAHLMAN@C.CS.CMU.EDU 	Notice on Kyoto Common Lisp distribution   
C00648 00170	∂01-May-87  1440	EMAILDEV%UKACRL.BITNET@BERKELEY.EDU 	Notice on Kyoto Common Lisp distribution   
C00650 00171	∂05-May-87  1825	FAHLMAN@C.CS.CMU.EDU 	Kyoto Common Lisp addendum  
C00655 00172	∂08-May-87  1725	kempf%hplabsc@hplabs.HP.COM 	Rule System in CommonLoops/CLOS
C00657 00173	∂09-May-87  0501	TMB%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	Smalltalk-80 Classes for Symbolics and/or CommonLisp    
C00659 00174	∂12-May-87  0301	@REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU 	atom type question   
C00660 00175	∂12-May-87  0637	FAHLMAN@C.CS.CMU.EDU 	atom type question
C00662 00176	∂12-May-87  0715	RAM@C.CS.CMU.EDU 	atom type question    
C00665 00177	∂12-May-87  1753	RWK@YUKON.SCRC.Symbolics.COM 	atom type question  
C00670 00178	∂13-May-87  1426	berman@vaxa.isi.edu 	&REST    
C00674 00179	∂13-May-87  1512	DLW@ALDERAAN.SCRC.Symbolics.COM 	&REST  
C00676 00180	∂14-May-87  0913	coffee@aerospace.aero.org 	Re: &REST    
C00679 00181	∂14-May-87  1107	berman@vaxa.isi.edu 	Re: &REST     
C00681 00182	∂14-May-87  1314	coffee@aerospace.aero.org 	Re: Gold Hill's floating-point   
C00683 00183	∂14-May-87  1438	berman@vaxa.isi.edu 	documentation 
C00686 00184	∂14-May-87  1507	edsel!bhopal!jonl@navajo.stanford.edu 	Re: &REST  
C00689 00185	∂14-May-87  1724	FAHLMAN@C.CS.CMU.EDU 	documentation
C00691 00186	∂15-May-87  1035	coffee@aerospace.aero.org 	Re: Gold Hill's floating-point   
C00697 00187	∂15-May-87  1331	@ACORN.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU 	(REDUCE #'OVERHEAD (MAP ...))  
C00702 00188	∂15-May-87  1333	Mailer@XX.LCS.MIT.EDU 	Re: &REST   
C00705 00189	∂15-May-87  1403	ACUFF@SUMEX-AIM.STANFORD.EDU 	Re: &REST 
C00707 00190	∂15-May-87  1747	@ACORN.CS.ROCHESTER.EDU,@CASHEW.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU 	Last message to list.    
C00709 00191	∂17-May-87  1532	dg%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: &REST
C00711 00192	∂18-May-87  0603	dml@nadc 	Addition to mailing list.
C00712 00193	∂18-May-87  0811	FAHLMAN@C.CS.CMU.EDU 	Mailing List for Lucid Users
C00716 00194	∂18-May-87  1151	@RELAY.CS.NET:a37078%tansei.u-tokyo.junet@UTOKYO-RELAY.CSNET 	Introduction to a multi-byte character extension
C00722 00195	∂18-May-87  1158	@RELAY.CS.NET:a37078%tansei.u-tokyo.junet@UTOKYO-RELAY.CSNET 	A multi-byte character extension proposal  
C00764 00196	∂18-May-87  1547	berman@vaxa.isi.edu 	Format   
C00767 00197	∂18-May-87  1719	barmar@Think.COM 	Format 
C00770 00198	∂18-May-87  1736	Olasov.StudentNS@MIT-Multics.ARPA 	Communications packages in Common LISP  
C00772 00199	∂18-May-87  2222	@RELAY.CS.NET:MURRAY@cs.umass.edu 	User-Visible Declarations and Proclamations  
C00776 00200	∂19-May-87  1136	Moon@STONY-BROOK.SCRC.Symbolics.COM 	User-Visible Declarations and Proclamations
C00780 00201	∂19-May-87  1139	berman@vaxa.isi.edu 	~% Directive  
C00782 00202	∂19-May-87  1220	FAHLMAN@C.CS.CMU.EDU 	~% Directive 
C00785 00203	∂19-May-87  1347	berman@vaxa.isi.edu 	More FORMAT   
C00789 00204	∂19-May-87  1511	Moon@STONY-BROOK.SCRC.Symbolics.COM 	More FORMAT  
C00792 00205	∂19-May-87  1524	berman@vaxa.isi.edu 	Re: More FORMAT    
C00795 00206	∂19-May-87  1608	barmar@Think.COM 	Re: More FORMAT  
C00799 00207	∂19-May-87  1618	Daniels.pa@Xerox.COM 	Re: More FORMAT   
C00803 00208	∂19-May-87  1802	sandra%orion@cs.utah.edu 	All arrays can be adjustable?
C00808 00209	∂19-May-87  1835	Moon@STONY-BROOK.SCRC.Symbolics.COM 	All arrays can be adjustable?    
C00813 00210	∂19-May-87  2000	DLA@DIAMOND.S4CC.Symbolics.COM 	All arrays can be adjustable?    
C00815 00211	∂19-May-87  2000	@DIAMOND.S4CC.Symbolics.COM:Cyphers@YUKON.SCRC.Symbolics.COM 	All arrays can be adjustable?    
C00819 00212	∂19-May-87  2342	KMP@STONY-BROOK.SCRC.Symbolics.COM 	adjustable arrays  
C00823 00213	∂20-May-87  0248	Mailer@XX.LCS.MIT.EDU 	Re: More FORMAT  
C00825 00214	∂20-May-87  0635	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	All arrays can be adjustable? 
C00828 00215	∂20-May-87  0836	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re: More FORMAT  
C00831 00216	∂20-May-87  0841	DLW@ALDERAAN.SCRC.Symbolics.COM 	All arrays can be adjustable?   
C00835 00217	∂20-May-87  0851	franz!ficl!jkf@ucbarpa.Berkeley.EDU 	adjustable arrays 
C00838 00218	∂20-May-87  0859	FAHLMAN@C.CS.CMU.EDU 	All arrays can be adjustable?    
C00841 00219	∂20-May-87  0955	@RELAY.CS.NET:DUSSUD%Jenner@TI-CSL.CSNET 	[dg%acorn@oak.lcs.mit.edu:  Re: &REST]
C00845 00220	∂20-May-87  1013	johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK   
C00846 00221	∂20-May-87  1039	las@bfly-vax.bbn.com
C00848 00222	∂20-May-87  1123	barmar@Think.COM 	DISASSEMBLE, et all return values    
C00850 00223	∂20-May-87  1158	berman@vaxa.isi.edu 	Re: More FORMAT    
C00852 00224	∂20-May-87  1210	berman@vaxa.isi.edu 
C00854 00225	∂20-May-87  1239	berman@vaxa.isi.edu 	las@bfly-vax.bbn.com    
C00855 00226	∂20-May-87  1247	las@bfly-vax.bbn.com
C00858 00227	∂20-May-87  1251	@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	All arrays can be adjustable? 
C00861 00228	∂20-May-87  1359	peck@Sun.COM 	Order of evaluation in PUSH (& PUSHNEW)  
C00865 00229	∂20-May-87  1551	berman@vaxa.isi.edu 	:fill-pointer maybe
C00867 00230	∂20-May-87  1623	berman@vaxa.isi.edu 	arrays   
C00870 00231	∂20-May-87  1647	FAHLMAN@C.CS.CMU.EDU 	:fill-pointer maybe    
C00875 00232	∂20-May-87  1658	FAHLMAN@C.CS.CMU.EDU 	arrays  
C00878 00233	∂20-May-87  1840	berman@vaxa.isi.edu 	arrays   
C00881 00234	∂20-May-87  1840	FAHLMAN@C.CS.CMU.EDU 	:fill-pointer maybe    
C00886 00235	∂20-May-87  1840	FAHLMAN@C.CS.CMU.EDU 	arrays  
C00889 00236	∂20-May-87  1844	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Order of evaluation in PUSH (& PUSHNEW)    
C00893 00237	∂20-May-87  1844	Moon@STONY-BROOK.SCRC.Symbolics.COM 	arrays  
C00897 00238	∂20-May-87  1902	rauen@CLS.LCS.MIT.EDU 	Roman numeral hacking.
C00898 00239	∂20-May-87  1911	ibuki!weaver@labrea.stanford.edu 	Order of evaluation in PUSH    
C00900 00240	∂20-May-87  1955	edsel!bhopal!jonl@navajo.stanford.edu 	[adjustable arrays?] More FORMAT    
C00903 00241	∂20-May-87  2037	quiroz@cs.rochester.edu 	Re: Order of evaluation in PUSH (& PUSHNEW)  
C00908 00242	∂20-May-87  2134	FAHLMAN@C.CS.CMU.EDU 	Order of evaluation in PUSH (& PUSHNEW)    
C00911 00243	∂20-May-87  2209	Mailer@XX.LCS.MIT.EDU 	[dg%acorn@oak.lcs.mit.edu:  Re: &REST]    
C00914 00244	∂20-May-87  2254	edsel!bhopal!jonl@navajo.stanford.edu 	All arrays can be adjustable?  
C00917 00245	∂21-May-87  0556	@diamond.s4cc.symbolics.com,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM 	[adjustable arrays?] More FORMAT    
C00921 00246	∂21-May-87  0725	DALY@IBM.COM 	validation suite
C00922 00247	∂21-May-87  0938	moss!tk@harvard.harvard.edu 	Re: Notice on Kyoto Common Lisp distribution (query)    
C00924 00248	∂21-May-87  0945	larus%paris.Berkeley.EDU@Berkeley.EDU 	Re: Order of evaluation in PUSH (& PUSHNEW)   
C00927 00249	∂21-May-87  1019	DLW@ALDERAAN.SCRC.Symbolics.COM 	[adjustable arrays?] More FORMAT
C00929 00250	∂21-May-87  1124	@DIAMOND.S4CC.Symbolics.COM:PTW@YUKON.SCRC.Symbolics.COM 	Re: Order of evaluation in PUSH (& PUSHNEW)    
C00931 00251	∂21-May-87  1148	berman@vaxa.isi.edu 	Re: :fill-pointer maybe 
C00933 00252	∂21-May-87  1156	berman@vaxa.isi.edu 	Re: validation suite    
C00935 00253	∂21-May-87  1220	FAHLMAN@C.CS.CMU.EDU 	:fill-pointer maybe    
C00937 00254	∂21-May-87  1323	Mailer@xx.lcs.mit.edu 	All arrays can be adjustable?   
C00940 00255	∂21-May-87  1347	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Order of evaluation in PUSH (& PUSHNEW)     
C00943 00256	∂21-May-87  1411	larus%paris.Berkeley.EDU@Berkeley.EDU 	Re: Order of evaluation in PUSH (& PUSHNEW)   
C00949 00257	∂22-May-87  0152	Randy%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: Order of evaluation in general  
C00952 00258	∂22-May-87  0718	DLW@ALDERAAN.SCRC.Symbolics.COM 	Re: Order of evaluation in general   
C00955 00259	∂22-May-87  0729	gls@Think.COM 	All arrays can be adjustable? 
C00958 00260	∂22-May-87  0748	gls@Think.COM 	Re: More FORMAT     
C00961 00261	∂22-May-87  0801	gls@Think.COM 	numerals, Roman, large, overly, printing of, how to do it   
C00963 00262	∂22-May-87  0815	FAHLMAN@C.CS.CMU.EDU 	numerals, Roman, large, overly, printing of, how to do it 
C00965 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)