perm filename COMMON.MSG[COM,LSP]36 blob sn#799324 filedate 1985-07-12 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00537 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00072 00002	
C00073 00003	∂24-Jan-85  1800	Moon@SCRC-STONY-BROOK.ARPA 	Make-Hash-Table  
C00078 00004	∂24-Jan-85  1800	Moon@SCRC-STONY-BROOK.ARPA 	Make-Hash-Table  
C00083 00005	∂25-Jan-85  0801	REM@IMSSS 	how to document yellow page entries, belated discussion by REM  
C00086 00006	∂26-Jan-85  1753	FAHLMAN@CMU-CS-C.ARPA 	how to document yellow page entries, belated discussion by REM
C00089 00007	∂26-Jan-85  2003	FAHLMAN@CMU-CS-C.ARPA 	A proposal  
C00098 00008	∂26-Jan-85  2139	Moon@SCRC-STONY-BROOK.ARPA 	A proposal  
C00101 00009	∂26-Jan-85  2216	REM%IMSSS.#Pup@SU-SCORE.ARPA 	Character macros, erratum
C00103 00010	∂26-Jan-85  2340	fateman%ucbdali@Berkeley 	Re:  A proposal    
C00110 00011	∂27-Jan-85  0952	FAHLMAN@CMU-CS-C.ARPA 	A proposal  
C00117 00012	∂27-Jan-85  1701	@MIT-MC:PGS@MIT-OZ 	definition of lexical closure 
C00122 00013	∂27-Jan-85  1705	fateman%ucbdali@Berkeley 	Re:  A proposal    
C00125 00014	∂27-Jan-85  1727	FAHLMAN@CMU-CS-C.ARPA 	A proposal  
C00129 00015	∂28-Jan-85  0511	OHLANDER@USC-ISI.ARPA 	Re: A proposal   
C00133 00016	∂28-Jan-85  0739	OHLANDER@USC-ISI.ARPA 	Re: A proposal   
C00136 00017	∂29-Jan-85  0335	@MIT-MC:PGS@MIT-OZ 	definition of lexical closure 
C00139 00018	∂29-Jan-85  1328	GRISS%hp-hulk.csnet@csnet-relay.arpa 	Re: how to document yellow page entries, belated discussion by REM 
C00141 00019	∂03-Feb-85  0833	RAM@CMU-CS-C.ARPA 	Defstruct copiers and included structures
C00143 00020	∂04-Feb-85  1248	Moon@SCRC-STONY-BROOK.ARPA 	FLET and the INLINE declaration 
C00145 00021	∂06-Feb-85  0950	brown@DEC-HUDSON 	Clearly non-controversial  
C00149 00022	∂06-Feb-85  1847	RAM@CMU-CS-C.ARPA 	of course you don't copy everything that includes that structure!!
C00153 00023	∂07-Feb-85  2224	WHOLEY@CMU-CS-C.ARPA 	Clearly non-controversial   
C00159 00024	∂07-Feb-85  2330	WHOLEY@CMU-CS-C.ARPA 	Clearly non-controversial   
C00165 00025	∂12-Feb-85  1931	JLW  	Your non-controversial suggestions for function names 
C00167 00026	∂14-Feb-85  1140	KMP@SCRC-STONY-BROOK.ARPA 	Not clearly non-controversial    
C00173 00027	∂18-Feb-85  1028	HEDRICK@RUTGERS.ARPA 	doc strings  
C00174 00028	∂20-Feb-85  0216	rwg@RUSSIAN.SPA.Symbolics.COM 	gcd of rationals--flame added in proof 
C00183 00029	∂21-Feb-85  1334	godot!gls@AQUINAS 	gcd of rationals--flame added in proof   
C00185 00030	∂26-Feb-85  0909	hpfclp!paul%hplabs.csnet@csnet-relay.arpa 	truncate/round/floor/ceiling functions    
C00188 00031	∂26-Feb-85  1648	RAM@CMU-CS-C.ARPA 	truncate/round/floor/ceiling functions   
C00190 00032	∂04-Mar-85  0934	RAM@CMU-CS-C.ARPA 	do-xxx-symbols  
C00195 00033	∂04-Mar-85  1048	FAHLMAN@CMU-CS-C.ARPA 	do-xxx-symbols   
C00199 00034	∂04-Mar-85  1606	HEDRICK@RUTGERS.ARPA 	Re: do-xxx-symbols
C00201 00035	∂04-Mar-85  1851	HEDRICK@RUTGERS.ARPA 	Re: do-xxx-symbols
C00205 00036	∂04-Mar-85  2026	FAHLMAN@CMU-CS-C.ARPA 	do-xxx-symbols   
C00208 00037	∂04-Mar-85  2036	HEDRICK@RUTGERS.ARPA 	Re: do-xxx-symbols
C00211 00038	∂05-Mar-85  1541	godot!gls@AQUINAS 	Complex arc tangent  
C00213 00039	∂07-Mar-85  1707	dzg@cmu-cs-spice.arpa 	file-length 
C00218 00040	∂07-Mar-85  1707	dzg@cmu-cs-spice.arpa 	file-length 
C00223 00041	∂07-Mar-85  1708	dzg@cmu-cs-spice.arpa 	file-length 
C00228 00042	∂07-Mar-85  2026	FAHLMAN@CMU-CS-C.ARPA 	file-length 
C00230 00043	∂07-Mar-85  2112	KMP@SCRC-STONY-BROOK.ARPA 	FILE-LENGTH  
C00234 00044	∂07-Mar-85  2130	KMP@SCRC-STONY-BROOK.ARPA 	DO-SYMBOLS finding shadowed symbols   
C00239 00045	∂08-Mar-85  0827	FAHLMAN@CMU-CS-C.ARPA 	DO-SYMBOLS finding shadowed symbols  
C00243 00046	∂08-Mar-85  1140	HEDRICK@RUTGERS.ARPA 	Re: file-length   
C00246 00047	∂08-Mar-85  1442	RAM@CMU-CS-C.ARPA 	file-length
C00248 00048	∂12-Mar-85  0710	hpfclp!paul%hplabs.csnet@csnet-relay.arpa 	float-digits
C00250 00049	∂12-Mar-85  0748	FAHLMAN@CMU-CS-C.ARPA 	float-digits
C00253 00050	∂19-Mar-85  0056	JLW  	DO-SYMBOLS: duplicates and shadowings  
C00256 00051	∂19-Mar-85  0114	JLW  	File-length on pathnames
C00258 00052	∂19-Mar-85  0717	FAHLMAN@CMU-CS-C.ARPA 	DO-SYMBOLS: duplicates and shadowings     
C00260 00053	∂19-Mar-85  1344	RAM@CMU-CS-C.ARPA 	File-length on pathnames  
C00264 00054	∂19-Mar-85  1855	FAHLMAN@CMU-CS-C.ARPA 	[Gall: Bug Report]    
C00292 00055	∂19-Mar-85  2212	cork%umass-cs.csnet@csnet-relay.arpa 	Implementation of MAP, SOME, EVERY, etc...
C00294 00056	∂19-Mar-85  2228	REM@IMSSS 	Default attributes of copy due to SUBSEQ    
C00297 00057	∂19-Mar-85  2228	REM@IMSSS 	What should CLOSE return? Closed-channel-object, or truefilename.    
C00300 00058	∂19-Mar-85  2228	REM@IMSSS 	Length of currently-open-for-write file is ambiguous or meaningless  
C00306 00059	∂20-Mar-85  0132	RAM@CMU-CS-C.ARPA 	Length of currently-open-for-write file is ambiguous or meaningless    
C00308 00060	∂20-Mar-85  0141	RAM@CMU-CS-C.ARPA 	Default attributes of copy due to SUBSEQ 
C00310 00061	∂20-Mar-85  0144	RAM@CMU-CS-C.ARPA 	Default attributes of copy due to SUBSEQ 
C00312 00062	∂20-Mar-85  0208	RAM@CMU-CS-C.ARPA 	Implementation of MAP, SOME, EVERY, etc...    
C00315 00063	∂20-Mar-85  2032	DDYER@USC-ISIB.ARPA 	Re: Implementation of MAP, SOME, EVERY, etc...   
C00317 00064	∂20-Mar-85  2053	RAM@CMU-CS-C.ARPA 	Query (FILE-LENGTH in particular) of file by name when open  
C00319 00065	∂20-Mar-85  2052	RAM@CMU-CS-C.ARPA 	[REM: Query (FILE-LENGTH in particular) of file by name when open]
C00323 00066	∂20-Mar-85  2052	RAM@CMU-CS-C.ARPA 	[REM: destructive operations on circular emulation of infinite list]   
C00330 00067	∂20-Mar-85  2122	JLW  	Implementation of MAP, SOME, etc  
C00331 00068	∂20-Mar-85  2152	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Follow-up and New Questions
C00343 00069	∂21-Mar-85  0056	RAM@CMU-CS-C.ARPA 	Implementation of MAP, SOME, EVERY, etc...    
C00345 00070	∂21-Mar-85  0111	RAM@CMU-CS-C.ARPA 	Follow-up and New Questions    
C00347 00071	∂21-Mar-85  1302	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: Follow-up and New Questions 
C00350 00072	∂21-Mar-85  1317	FAHLMAN@CMU-CS-C.ARPA 	Follow-up and New Questions
C00352 00073	∂21-Mar-85  1352	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Lost bet    
C00354 00074	∂21-Mar-85  2218	cork%umass-cs.csnet@csnet-relay.arpa 	More on MAP, SOME, EVERY, etc.....   
C00360 00075	∂25-Mar-85  1831	JLW  	DELFILE, thanks to DWIM 
C00362 00076	∂25-Mar-85  1914	JLW  	Excluding some symbols from DO-ALL-SYMBOLS  
C00364 00077	∂26-Mar-85  0312	JLW  	Previous note about DELFILE/DWIM  
C00365 00078	∂27-Mar-85  1240	eak@angband 	multiple-value-setq   
C00366 00079	∂27-Mar-85  1241	eak@angband 	values-list 
C00367 00080	∂27-Mar-85  1807	Moon@SCRC-STONY-BROOK.ARPA 	do-xxx-symbols   
C00372 00081	∂27-Mar-85  1808	Moon@SCRC-STONY-BROOK.ARPA 	Implementation of MAP, SOME, EVERY, etc...
C00375 00082	∂27-Mar-85  1818	FAHLMAN@CMU-CS-C.ARPA 	multiple-value-setq   
C00377 00083	∂27-Mar-85  1820	FAHLMAN@CMU-CS-C.ARPA 	do-xxx-symbols   
C00380 00084	∂27-Mar-85  1820	FAHLMAN@CMU-CS-C.ARPA 	values-list 
C00383 00085	∂27-Mar-85  2020	FAHLMAN@CMU-CS-C.ARPA 	Implementation of MAP, SOME, EVERY, etc...
C00385 00086	∂28-Mar-85  0553	Moon@SCRC-STONY-BROOK.ARPA 	[Gall: Bug Report]    
C00406 00087	∂28-Mar-85  1036	Moon@SCRC-STONY-BROOK.ARPA 	Implementation of MAP, SOME, EVERY, etc...
C00409 00088	∂28-Mar-85  1116	FAHLMAN@CMU-CS-C.ARPA 	values-list 
C00411 00089	∂28-Mar-85  1126	Moon@SCRC-STONY-BROOK.ARPA 	values-list 
C00414 00090	∂28-Mar-85  1154	EAK@MIT-MC 	values-list  
C00416 00091	∂28-Mar-85  1158	RWK@SCRC-STONY-BROOK.ARPA 	Clearly non-controversial   
C00419 00092	∂28-Mar-85  1433	DLW@SCRC-STONY-BROOK.ARPA 	[Gall: Bug Report]
C00422 00093	∂28-Mar-85  1434	Moon@SCRC-STONY-BROOK.ARPA 	values-list 
C00424 00094	∂28-Mar-85  1621	Moon@SCRC-STONY-BROOK.ARPA 	[Gall: Bug Report]    
C00428 00095	∂28-Mar-85  2216	cork%umass-cs.csnet@csnet-relay.arpa 	More on MAP, SOME, EVERY, etc.....   
C00435 00096	∂29-Mar-85  2041	TIM@MIT-MC 	multiple-value-setf    
C00436 00097	∂01-Apr-85  0118	masinter.pa@Xerox.ARPA 	Re: Arg count checking    
C00440 00098	∂01-Apr-85  1123	godot!gls@cca-unix 	[Gall: Bug Report]  
C00442 00099	∂01-Apr-85  1127	godot!gls@cca-unix 	Implementation of MAP, SOME, EVERY, etc...   
C00446 00100	∂01-Apr-85  1844	KMP@SCRC-QUABBIN.ARPA 	Re: Arg count checking
C00455 00101	∂02-Apr-85  0745	DLW@SCRC-QUABBIN.ARPA 	Re: Arg count checking
C00459 00102	∂02-Apr-85  1201	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: PROCLAIM [Gall: Bug Report] 
C00462 00103	∂02-Apr-85  1201	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: INTERN [Gall: Bug Report]   
C00468 00104	∂02-Apr-85  1218	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: NIL and DEFCONSTANT [Gall: Bug Report]
C00470 00105	∂02-Apr-85  1218	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: SPECIAL FUNCTION NAME [Gall: Bug Report]   
C00474 00106	∂02-Apr-85  1218	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: [Gall: Bug Report]
C00479 00107	∂02-Apr-85  1218	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: COPY-SYMBOL [Gall: Bug Report]   
C00482 00108	∂02-Apr-85  1327	JAR@MIT-MC 	SPECIAL FUNCTION NAME [Gall: Bug Report]   
C00487 00109	∂02-Apr-85  1329	fateman%ucbdali@Berkeley 	CLRM?    
C00489 00110	∂02-Apr-85  1722	Moon@SCRC-STONY-BROOK.ARPA 	Re: NIL and DEFCONSTANT [Gall: Bug Report]
C00492 00111	∂02-Apr-85  1724	Moon@SCRC-STONY-BROOK.ARPA 	Re: INTERN [Gall: Bug Report]   
C00501 00112	∂02-Apr-85  2002	FAHLMAN@CMU-CS-C.ARPA 	INTERN [Gall: Bug Report]  
C00506 00113	∂02-Apr-85  2021	FAHLMAN@CMU-CS-C.ARPA 	NIL and DEFCONSTANT [Gall: Bug Report]    
C00509 00114	∂03-Apr-85  1226	JLW  	INTERN and "intern" -- the unwise choice of  terminology   
C00512 00115	∂03-Apr-85  1438	Gall.HIS←Guest@MIT-MULTICS.ARPA    
C00518 00116	∂03-Apr-85  1502	JLW  	Assymetry between argument-passing and value-returning
C00522 00117	∂03-Apr-85  1556	BSG@SCRC-STONY-BROOK.ARPA 	Re: Arg count checking 
C00526 00118	∂03-Apr-85  1749	Masinter.pa@Xerox.ARPA 	Re: SPECIAL FUNCTION NAME [Gall: Bug Report]  
C00528 00119	∂03-Apr-85  1843	Moon@SCRC-QUABBIN.ARPA 	INTERN and "intern" -- the unwise choice of  terminology     
C00532 00120	∂03-Apr-85  1846	KSH@MIT-MC
C00535 00121	∂03-Apr-85  2043	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: INTERN [Gall: Bug Report]   
C00543 00122	∂03-Apr-85  2105	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: NIL and DEFCONSTANT [Gall: Bug Report]
C00546 00123	∂03-Apr-85  2110	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: What should CLOSE return?   
C00552 00124	∂04-Apr-85  0750	RAM@CMU-CS-C.ARPA 	INTERN and "intern" -- the unwise choice of  terminology     
C00555 00125	∂04-Apr-85  1104	Moon@SCRC-STONY-BROOK.ARPA 	INTERN and "intern" -- the unwise choice of  terminology      
C00558 00126	∂04-Apr-85  1345	JLW  	"home-ifying" symbols   
C00561 00127	∂04-Apr-85  1423	RAM@CMU-CS-C.ARPA 	"home-ifying" symbols     
C00563 00128	∂04-Apr-85  1812	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: INTERN and "intern" -- the unwise choice of terminology   
C00566 00129	∂04-Apr-85  2042	FAHLMAN@CMU-CS-C.ARPA 	Intern 
C00568 00130	∂04-Apr-85  2046	FAHLMAN@CMU-CS-C.ARPA 	Minor correction 
C00569 00131	∂04-Apr-85  2056	FAHLMAN@CMU-CS-C.ARPA 	NIL and DEFCONSTANT [Gall: Bug Report]    
C00571 00132	∂05-Apr-85  1106	Moon@SCRC-STONY-BROOK.ARPA 	Intern 
C00574 00133	∂05-Apr-85  1227	REM%IMSSS.#Pup@SU-SCORE.ARPA 	Any complete CL implementations??  
C00577 00134	∂05-Apr-85  1740	@SU-SCORE.ARPA:HEDRICK@RUTGERS.ARPA 	Re: Any complete CL implementations?? 
C00581 00135	∂07-Apr-85  2026	FAHLMAN@CMU-CS-C.ARPA 	Any complete CL implementations??    
C00584 00136	∂08-Apr-85  0723	RAM@CMU-CS-C.ARPA 	Probe-File and proposed extension.  
C00587 00137	∂08-Apr-85  0821	gls%AQUINAS.TMC@Think 	NIL and DEFCONSTANT [Gall: Bug Report]    
C00589 00138	∂08-Apr-85  1134	Moon@SCRC-STONY-BROOK.ARPA 	Probe-File and proposed extension.   
C00593 00139	∂08-Apr-85  1156	RAM@CMU-CS-C.ARPA 	Probe-File and proposed extension.  
C00596 00140	∂08-Apr-85  1208	greek@DEC-HUDSON 	More on PROBE-FILE.   
C00597 00141	∂08-Apr-85  1208	greek@DEC-HUDSON 	PROBE-FILE  
C00599 00142	∂08-Apr-85  1222	RAM@CMU-CS-C.ARPA 	PROBE-FILE 
C00601 00143	∂08-Apr-85  1234	RAM@CMU-CS-C.ARPA 	PROBE-FILE 
C00603 00144	∂08-Apr-85  1345	REM@IMSSS 	error-protected OPEN isn't a good way to fake a probe 
C00606 00145	∂08-Apr-85  1446	Moon@SCRC-STONY-BROOK.ARPA 	Probe-File and proposed extension.   
C00618 00146	∂08-Apr-85  1452	Moon@SCRC-STONY-BROOK.ARPA 	error-protected OPEN isn't a good way to fake a probe    
C00622 00147	∂08-Apr-85  1531	RAM@CMU-CS-C.ARPA 	Probe-File and proposed extension.  
C00625 00148	∂08-Apr-85  1719	card.pa@Xerox.ARPA 	Re: Arg count checking   
C00632 00149	∂08-Apr-85  1736	KMP@SCRC-STONY-BROOK.ARPA 	PROBE-FILE   
C00640 00150	∂08-Apr-85  1937	FAHLMAN@CMU-CS-C.ARPA 	NIL and DEFCONSTANT [Gall: Bug Report]    
C00643 00151	∂08-Apr-85  1946	fateman%ucbdali@Berkeley 	Re: Arg count checking  
C00645 00152	∂09-Apr-85  0100	hplabs!perdue%hplabs.csnet@csnet-relay.arpa 	Compilation and package system
C00649 00153	∂09-Apr-85  0448	REM@IMSSS 	I agree, but manual should tell LUSERs why  
C00654 00154	∂09-Apr-85  0451	REM@IMSSS 	READ loses info as to whether package is specified or not, my fix    
C00657 00155	∂09-Apr-85  0709	gls%AQUINAS.TMC@Think 	NIL and DEFCONSTANT [Gall: Bug Report]    
C00661 00156	∂09-Apr-85  1147	root%bostonu.csnet@csnet-relay.arpa 	Re: Arg count checking 
C00664 00157	∂09-Apr-85  1341	DLW@SCRC-STONY-BROOK.ARPA 	Re: Arg count checking 
C00666 00158	∂09-Apr-85  1352	DLW@SCRC-STONY-BROOK.ARPA 	Compilation and package system   
C00668 00159	∂09-Apr-85  1722	JLW  	Arg cont checking, optionals, keywords, etc 
C00670 00160	∂09-Apr-85  1803	Moon@SCRC-STONY-BROOK.ARPA 	Probe-File and proposed extension.   
C00676 00161	∂09-Apr-85  1811	JLW  	Meaning of PROBE-FILE for direction output  
C00680 00162	∂09-Apr-85  1915	WHOLEY@CMU-CS-C.ARPA 	Compilation and package system   
C00686 00163	∂09-Apr-85  1958	RICHER@SUMEX-AIM.ARPA 	Re: Arg cont checking, optionals, keywords, etc     
C00688 00164	∂10-Apr-85  1012	DDYER@USC-ISIB.ARPA 
C00689 00165	∂10-Apr-85  1024	DCP@SCRC-VALLECITO.ARPA 	What are we talking about anyway?  
C00692 00166	∂10-Apr-85  1112	smh@mit-eddie.ARPA 	defstruct slot names
C00696 00167	∂10-Apr-85  1156	FAHLMAN@CMU-CS-C.ARPA 	defstruct slot names  
C00699 00168	∂10-Apr-85  1159	RAM@CMU-CS-C.ARPA 	Meaning of PROBE-FILE for direction output    
C00701 00169	∂10-Apr-85  1222	RAM@CMU-CS-C.ARPA 	Compilation and package system 
C00704 00170	∂10-Apr-85  1504	REM@IMSSS 	interp .neq. compil, even in CL   
C00708 00171	∂10-Apr-85  1933	Moon@SCRC-STONY-BROOK.ARPA 	Compilation and package system  
C00717 00172	∂10-Apr-85  2006	GSB@MIT-MC 	Meaning of PROBE-FILE for direction output      
C00719 00173	∂10-Apr-85  2051	WHOLEY@CMU-CS-C.ARPA 	Compilation and package system   
C00728 00174	∂10-Apr-85  2137	KMP@SCRC-STONY-BROOK.ARPA 	Compilation and package system   
C00740 00175	∂11-Apr-85  0044	WHOLEY@CMU-CS-C.ARPA 	Compilation and package system   
C00745 00176	∂11-Apr-85  0607	greek@DEC-HUDSON 	PROBE-FILE  
C00747 00177	∂11-Apr-85  0649	greek@DEC-HUDSON 	A comment on packages (at the risk of being a fool) 
C00749 00178	∂11-Apr-85  1052	Moon@SCRC-QUABBIN.ARPA 	A comment on packages (at the risk of being a fool)
C00752 00179	∂11-Apr-85  1103	OLDMAN@USC-ISI.ARPA 	Data General Common LISP
C00753 00180	∂11-Apr-85  1128	KMP@SCRC-YUKON.ARPA 	PROBE-FILE    
C00759 00181	∂11-Apr-85  1156	FAHLMAN@CMU-CS-C.ARPA 	PROBE-FILE  
C00762 00182	∂11-Apr-85  1227	greek@DEC-HUDSON 	PROBE-FILE  
C00763 00183	∂11-Apr-85  1237	greek@DEC-HUDSON 	PROBE-FILE  
C00764 00184	∂11-Apr-85  1237	greek@DEC-HUDSON 	The compiler and packages. 
C00767 00185	∂11-Apr-85  1302	dzg@cmu-cs-spice.arpa 	Probe-file and errors 
C00770 00186	∂11-Apr-85  1613	Moon@SCRC-STONY-BROOK.ARPA 	PROBE-FILE  
C00772 00187	∂11-Apr-85  1702	Moon@SCRC-STONY-BROOK.ARPA 	The compiler and packages. 
C00777 00188	∂11-Apr-85  1852	masinter.pa@Xerox.ARPA 	Common Lisp should use lexical scoping   
C00780 00189	∂11-Apr-85  1932	masinter.pa@Xerox.ARPA 	probe-file 
C00784 00190	∂11-Apr-85  1937	FAHLMAN@CMU-CS-C.ARPA 	Common Lisp should use lexical scoping    
C00786 00191	∂11-Apr-85  2127	masinter.pa@Xerox.ARPA 	Re: PROBE-FILE  
C00787 00192	∂11-Apr-85  2139	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: PROBE-FILE   
C00792 00193	∂12-Apr-85  0701	greek@DEC-HUDSON 	A-Packaging we will go...  
C00798 00194	∂12-Apr-85  0704	FAHLMAN@CMU-CS-C.ARPA 	PROBE-FILE  
C00800 00195	∂12-Apr-85  1103	KMP@SCRC-STONY-BROOK.ARPA 	Probe-file and errors  
C00803 00196	∂12-Apr-85  1416	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: PROBE-FILE   
C00808 00197	∂12-Apr-85  1755	JLW  	Two PROBE-FILE questions
C00811 00198	∂12-Apr-85  1822	card.pa@Xerox.ARPA 	Re: Arg cont checking, optionals, keywords, etc   
C00813 00199	∂12-Apr-85  1929	FAHLMAN@CMU-CS-C.ARPA 	Common Lisp should use lexical scoping    
C00817 00200	∂13-Apr-85  1410	HANDERSON@CMU-CS-C.ARPA 	Common Lisp should use lexical scoping  
C00820 00201	∂15-Apr-85  1712	Moon@SCRC-QUABBIN.ARPA 	Common Lisp should use lexical scoping   
C00825 00202	∂15-Apr-85  1713	Moon@SCRC-QUABBIN.ARPA 	A-Packaging we will go... 
C00833 00203	∂15-Apr-85  1718	DLW@SCRC-STONY-BROOK.ARPA 	probe-file   
C00837 00204	∂15-Apr-85  1718	DLW@SCRC-STONY-BROOK.ARPA 	Common Lisp should use lexical scoping
C00840 00205	∂15-Apr-85  1719	DLW@SCRC-STONY-BROOK.ARPA 	PROBE-FILE   
C00842 00206	∂15-Apr-85  1843	FAHLMAN@CMU-CS-C.ARPA 	probe-file  
C00844 00207	∂16-Apr-85  0740	greek@DEC-HUDSON 	Packages and the Compiler  
C00846 00208	∂16-Apr-85  1433	DLW@SCRC-STONY-BROOK.ARPA 	Compilation and package system   
C00853 00209	∂16-Apr-85  1556	Moon@SCRC-STONY-BROOK.ARPA 	Compilation and package system  
C00855 00210	∂16-Apr-85  1808	DD60@CMU-CS-A.ARPA 	Package system 
C00858 00211	∂16-Apr-85  1921	FAHLMAN@CMU-CS-C.ARPA 	Compilation and package system  
C00862 00212	∂17-Apr-85  0800	DLW@SCRC-QUABBIN.ARPA 	Package system   
C00864 00213	∂17-Apr-85  0841	GSB@MIT-MC 	Re: Compilation and package system    
C00867 00214	∂17-Apr-85  1722	masinter.pa@Xerox.ARPA 	"lexical" packages   
C00874 00215	∂17-Apr-85  1752	FAHLMAN@CMU-CS-C.ARPA 	"lexical" packages    
C00878 00216	∂18-Apr-85  1013	DLW@SCRC-STONY-BROOK.ARPA 	Compilation and package system, an addendum
C00881 00217	∂18-Apr-85  1253	REM%IMSSS.#Pup@SU-SCORE.ARPA 	What is a "file"? Lexical package usage?
C00884 00218	∂18-Apr-85  1847	Moon@SCRC-STONY-BROOK.ARPA 	"lexical" packages    
C00886 00219	∂18-Apr-85  1911	KMP@MIT-MC 	"lexical" packages
C00887 00220	∂19-Apr-85  2128	DLW@SCRC-STONY-BROOK.ARPA 	"lexical" packages
C00891 00221	∂19-Apr-85  2133	DLW@SCRC-STONY-BROOK.ARPA 	"lexical" packages
C00894 00222	∂21-Apr-85  0357	RAM@CMU-CS-C.ARPA 	Bug in CLM.
C00896 00223	∂22-Apr-85  2230	JLW  	Bug in CLM?   
C00898 00224	∂23-Apr-85  0234	JLW  	Problems with packages? 
C00904 00225	∂24-Apr-85  0655	greek@DEC-HUDSON 	Code Generated by Macros   
C00906 00226	∂24-Apr-85  0714	RAM@CMU-CS-C.ARPA 	Bug in CLM?     
C00908 00227	∂24-Apr-85  0750	FAHLMAN@CMU-CS-C.ARPA 	Bug in CLM?      
C00911 00228	∂24-Apr-85  0836	WHOLEY@CMU-CS-C.ARPA 	Code Generated by Macros    
C00914 00229	∂24-Apr-85  0958	greek@DEC-HUDSON 	Code Generated by Macros   
C00916 00230	∂24-Apr-85  1208	DCP@STONY-BROOK.SCRC.Symbolics.COM 	Code Generated by Macros
C00920 00231	∂24-Apr-85  1628	GSB@MIT-MC 	Code Generated by Macros    
C00922 00232	∂24-Apr-85  1750	Moon@STONY-BROOK.SCRC.Symbolics.COM 	When is a package name equivalent to a package? 
C00925 00233	∂24-Apr-85  1822	KMP@STONY-BROOK.SCRC.Symbolics.COM 	When is a package name equivalent to a package?  
C00931 00234	∂24-Apr-85  1829	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Code Generated by Macros    
C00934 00235	∂24-Apr-85  1905	FAHLMAN@CMU-CS-C.ARPA 	When is a package name equivalent to a package?
C00937 00236	∂24-Apr-85  1932	Moon@STONY-BROOK.SCRC.Symbolics.COM 	When is a package name equivalent to a package? 
C00942 00237	∂24-Apr-85  2057	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Problems with packages?     
C00948 00238	∂25-Apr-85  0054	JLW  	When is a package name equivalent to a package?  
C00950 00239	∂25-Apr-85  0343	JLW  	More on (B): the editor's "reading" of files
C00954 00240	∂25-Apr-85  0419	JLW  	What package are feature names resident in? 
C00958 00241	∂25-Apr-85  0642	greek@DEC-HUDSON 	Code Generated by Macros   
C00960 00242	∂25-Apr-85  1507	Moon@STONY-BROOK.SCRC.Symbolics.COM 	More on (B): the editor's "reading" of files    
C00963 00243	∂25-Apr-85  1523	fateman%ucbdali@Berkeley 	RPG's benchmarks coming out as an MIT press book 
C00965 00244	∂25-Apr-85  1935	FAHLMAN@CMU-CS-C.ARPA 	When is a package name equivalent to a package?     
C00967 00245	∂26-Apr-85  1211	RAM@CMU-CS-C.ARPA 	What package are feature names resident in?   
C00969 00246	∂26-Apr-85  1453	GSB@MIT-MC 	package names, consistency  
C00971 00247	∂27-Apr-85  1142	TIM@MIT-MC 	Editing multiple package files   
C00976 00248	∂28-Apr-85  1123	RPG   	Common Lisp song considered offensive?
C00980 00249	∂28-Apr-85  1124	RPG   	Common Lisp song considered offensive?
C00983 00250	∂28-Apr-85  1124	RPG   	Common Lisp song considered offensive?
C00986 00251	∂28-Apr-85  1400	Moon@SCRC-STONY-BROOK.ARPA 	Any complete CL implementations??    
C00989 00252	∂28-Apr-85  2033	RPG   	Common Lisp song considered offensive?
C00992 00253	∂29-Apr-85  1300	Moon@SCRC-VALLECITO.ARPA 	wimpy COERCE function   
C00995 00254	∂29-Apr-85  1714	RWK@SCRC-STONY-BROOK.ARPA 	More on (B): the editor's "reading" of files    
C00998 00255	∂30-Apr-85  0735	DLW@SCRC-STONY-BROOK.ARPA 	wimpy COERCE function  
C01000 00256	∂04-May-85  0838	RAM@CMU-CS-C.ARPA 	Misfeature: macros expanding into declarations
C01003 00257	∂04-May-85  1209	FAHLMAN@CMU-CS-C.ARPA 	Misfeature: macros expanding into declarations 
C01006 00258	∂04-May-85  1529	TIM@MIT-MC 	Misfeature: macros expanding into declarations  
C01013 00259	∂04-May-85  1543	vanroggen@DEC-HUDSON 	macr --> declares 
C01015 00260	∂04-May-85  1549	RAM@CMU-CS-C.ARPA 	Misfeature: macros expanding into declarations
C01018 00261	∂04-May-85  1557	RAM@CMU-CS-C.ARPA 	macr --> declares    
C01020 00262	∂05-May-85  0145	HEDRICK@RUTGERS.ARPA 	(setf (apply #'foo
C01022 00263	∂05-May-85  0853	FAHLMAN@CMU-CS-C.ARPA 	macr --> declares
C01026 00264	∂05-May-85  0909	RAM@CMU-CS-C.ARPA 	macr --> declares    
C01028 00265	∂05-May-85  0919	FAHLMAN@CMU-CS-C.ARPA 	Misfeature: macros expanding into declarations 
C01032 00266	∂05-May-85  0953	FAHLMAN@CMU-CS-C.ARPA 	macr --> declares
C01034 00267	∂05-May-85  1036	fateman%ucbdali@Berkeley 	mysterious declarations off in left field   
C01036 00268	∂05-May-85  1112	FAHLMAN@CMU-CS-C.ARPA 	mysterious declarations off in left field 
C01038 00269	∂05-May-85  1633	KMP@SCRC-STONY-BROOK.ARPA 	mysterious declarations off in left field  
C01043 00270	∂05-May-85  1739	FAHLMAN@CMU-CS-C.ARPA 	mysterious declarations off in left field 
C01046 00271	∂05-May-85  1742	SOLEY@MIT-MC 	Misfeature: macros expanding into declarations
C01050 00272	∂05-May-85  1826	REM@IMSSS 	Restrictions on what macros may call, to avoid needing to preload file    
C01055 00273	∂05-May-85  1837	MLY@MIT-MC 	Misfeature: macros expanding into declarations  
C01061 00274	∂05-May-85  1845	SOLEY@MIT-MC 	Misfeature: macros expanding into declarations
C01066 00275	∂05-May-85  1849	SOLEY@MIT-MC 	Restrictions on what macros may call, to avoid needing to preload file 
C01069 00276	∂05-May-85  1948	FAHLMAN@CMU-CS-C.ARPA 	Misfeature: macros expanding into declarations 
C01072 00277	∂05-May-85  2001	GSB@MIT-MC 	(setf (apply #'foo ...) ...)
C01074 00278	∂05-May-85  2252	HEDRICK@RUTGERS.ARPA 	Re: (setf (apply #'foo ...) ...) 
C01075 00279	∂06-May-85  0834	gls%AQUINAS@THINK.ARPA 	SETF of APPLY   
C01078 00280	∂06-May-85  0845	gls%AQUINAS@THINK.ARPA 	Macros -> declarations    
C01081 00281	∂06-May-85  0854	gls%AQUINAS@THINK.ARPA 	PROCLAIM and type declarations 
C01083 00282	∂06-May-85  0947	vanroggen@DEC-HUDSON 	macros --> declarations
C01084 00283	∂06-May-85  0953	vanroggen@DEC-HUDSON 	local declarations
C01086 00284	∂06-May-85  1043	vanroggen@DEC-HUDSON 	SETF APPLY ...    
C01088 00285	∂06-May-85  1053	WHOLEY@CMU-CS-C.ARPA 	(setf (apply #'foo ...) ...)
C01090 00286	∂06-May-85  1148	FAHLMAN@CMU-CS-C.ARPA 	local declarations    
C01092 00287	∂06-May-85  1159	FAHLMAN@CMU-CS-C.ARPA 	SETF of APPLY    
C01094 00288	∂06-May-85  1235	Moon@SCRC-YUKON.ARPA 	SETF of APPLY
C01097 00289	∂06-May-85  1241	OLDMAN@USC-ISI.ARPA 	defconstant vs. lexical variables 
C01099 00290	∂06-May-85  1347	gls%AQUINAS@THINK.ARPA 	local declarations   
C01102 00291	∂06-May-85  1444	Moon@SCRC-QUABBIN.ARPA 	Macros -> declarations    
C01109 00292	∂06-May-85  1642	KMP@SCRC-STONY-BROOK.ARPA 	Macros -> declarations 
C01113 00293	∂06-May-85  1721	WHOLEY@CMU-CS-C.ARPA 	Macros -> declarations 
C01117 00294	∂06-May-85  1744	HEDRICK@RUTGERS.ARPA 	SETF (APPLY  
C01119 00295	∂06-May-85  1745	KMP@SCRC-STONY-BROOK.ARPA 	Macros -> declarations 
C01126 00296	∂06-May-85  1801	WHOLEY@CMU-CS-C.ARPA 	Macros -> declarations 
C01128 00297	∂06-May-85  1804	Moon@SCRC-STONY-BROOK.ARPA 	SETF (APPLY 
C01131 00298	∂06-May-85  1830	HEDRICK@RUTGERS.ARPA 	Re: SETF (APPLY   
C01133 00299	∂06-May-85  1857	FAHLMAN@CMU-CS-C.ARPA 	Macros -> declarations
C01135 00300	∂07-May-85  1118	BSG@SCRC-RIVERSIDE.ARPA 	Macros -> declarations   
C01138 00301	∂07-May-85  1139	FAHLMAN@CMU-CS-C.ARPA 	Macros -> declarations
C01143 00302	∂07-May-85  1221	KMP@SCRC-STONY-BROOK.ARPA 	Macros -> declarations 
C01152 00303	∂07-May-85  1319	REM%IMSSS.#Pup@SU-SCORE.ARPA 	Read macros vs. macro-->declare    
C01155 00304	∂07-May-85  1350	KMP@SCRC-STONY-BROOK.ARPA 	Read macros vs. macro-->declare  
C01160 00305	∂07-May-85  1951	FAHLMAN@CMU-CS-C.ARPA 	Macros -> declarations
C01163 00306	∂07-May-85  2237	hoey@nrl-aic 	Re: SETF of APPLY    
C01171 00307	∂08-May-85  0835	JLW  	PARSE-BODY    
C01173 00308	∂08-May-85  0859	RWK@SCRC-STONY-BROOK.ARPA 	Macros -> declarations 
C01177 00309	∂08-May-85  0919	JLW  	... point on a different point    
C01179 00310	∂08-May-85  1121	FAHLMAN@CMU-CS-C.ARPA 	... point on a different point       
C01181 00311	∂08-May-85  1513	RPG  	Proposal 
C01185 00312	∂08-May-85  1843	FAHLMAN@CMU-CS-C.ARPA 	Proposal    
C01190 00313	∂08-May-85  2159	TIM@MIT-MC 	Lack of EQUALP hash tables  
C01192 00314	∂08-May-85  2246	RPG  	Fahlman's comments 
C01194 00315	∂09-May-85  0511	GJC@MIT-MC
C01197 00316	∂09-May-85  0622	RAM@CMU-CS-C.ARPA 	Lack of EQUALP hash tables
C01199 00317	∂09-May-85  0643	BSG@SCRC-STONY-BROOK.ARPA 	Macros -> declarations 
C01202 00318	∂09-May-85  0900	DCP@SCRC-STONY-BROOK.ARPA 	hash table types  
C01205 00319	∂09-May-85  0911	FAHLMAN@CMU-CS-C.ARPA 	Fahlman's comments    
C01208 00320	∂09-May-85  0929	GRISS%hp-hulk.csnet@csnet-relay.arpa 	Re: PARSE-BODY        
C01210 00321	∂09-May-85  1103	RPG  	Comments on ...    
C01213 00322	∂09-May-85  2101	FAHLMAN@CMU-CS-C.ARPA 	PARSE-BODY       
C01216 00323	∂09-May-85  2254	KMP@SCRC-STONY-BROOK.ARPA 	Macros -> declarations 
C01225 00324	∂09-May-85  2319	JLW  	READ-AN-DO-FILE-ATTRIBUTES   
C01227 00325	∂09-May-85  2356	JLW  	EQUALP hash tables (and more ...) 
C01231 00326	∂10-May-85  0017	JLW  	Y.A.R.I.M.: Macros inside DECLARE?
C01233 00327	∂10-May-85  0146	hoey@nrl-aic 	Re: EQUALP hash tables (and more ...)    
C01236 00328	∂10-May-85  0906	FAHLMAN@CMU-CS-C.ARPA 	Macros -> declarations
C01244 00329	∂10-May-85  1057	REM@IMSSS 	Instead of read macros, how about one reserved-word for process-time macro?    
C01249 00330	∂10-May-85  1139	BSG@SCRC-STONY-BROOK.ARPA 	Y.A.R.I.M.: Macros inside DECLARE?    
C01252 00331	∂10-May-85  1239	BSG@SCRC-STONY-BROOK.ARPA 	Macros -> declarations 
C01256 00332	∂10-May-85  2005	FAHLMAN@CMU-CS-C.ARPA 	Macros -> declarations
C01258 00333	∂11-May-85  0635	FAHLMAN@CMU-CS-C.ARPA 	:-(    
C01260 00334	∂11-May-85  0759	FAHLMAN@CMU-CS-C.ARPA 	EQUALP hash tables (and more ...)    
C01264 00335	∂11-May-85  1229	WHOLEY@CMU-CS-C.ARPA 	EQUALP hash tables (and more ...)     
C01269 00336	∂11-May-85  1404	RWK@SCRC-STONY-BROOK.ARPA 	Macros -> declarations 
C01276 00337	∂11-May-85  2300	TIM@MIT-MC 	Macros -> declarations 
C01280 00338	∂12-May-85  0550	GJC@MIT-MC 	hash table types  
C01283 00339	∂12-May-85  1225	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: defconstant vs. lexical variables
C01286 00340	∂12-May-85  1748	hoey@nrl-aic 	Re: EQUALP hash tables (and more ...)    
C01288 00341	∂12-May-85  2030	FAHLMAN@CMU-CS-C.ARPA 	EQUALP hash tables (and more ...)    
C01291 00342	∂13-May-85  0905	JLW  	YARIM and the adbmal example 
C01293 00343	∂13-May-85  0919	BSG@SCRC-STONY-BROOK.ARPA 	:-(
C01301 00344	∂13-May-85  0930	BSG@SCRC-STONY-BROOK.ARPA 	YARIM and the adbmal example     
C01305 00345	∂13-May-85  1144	DCP%TENEX.SCRC@MIT-XX.ARPA 	hash table types 
C01313 00346	∂13-May-85  1145	DCP%TENEX.SCRC@MIT-XX.ARPA 	hash table types 
C01322 00347	∂14-May-85  0905	KESSLER@UTAH-20.ARPA 	&optional with &key    
C01324 00348	∂14-May-85  0933	gls@AQUINAS.ARPA 	&optional with &key   
C01326 00349	∂14-May-85  1002	RWK@SCRC-STONY-BROOK.ARPA 	&optional with &key    
C01329 00350	∂14-May-85  1655	REM@IMSSS 	Semantic question about closures  
C01332 00351	∂14-May-85  1858	RAM@CMU-CS-C.ARPA 	Semantic question about closures    
C01338 00352	∂14-May-85  2103	WHOLEY@CMU-CS-C.ARPA 	Apply-But-Last    
C01340 00353	∂15-May-85  1221	REM@IMSSS 	Another question about lexical closures
C01343 00354	∂15-May-85  1233	MOON%TENEX.SCRC@MIT-XX.ARPA 	Validation 
C01347 00355	∂15-May-85  1331	RWK@SCRC-STONY-BROOK.ARPA 	Another question about lexical closures    
C01352 00356	∂15-May-85  1332	RWK@SCRC-STONY-BROOK.ARPA 	Another question about lexical closures    
C01358 00357	∂15-May-85  1354	STENGER%ti-csl.csnet@csnet-relay.arpa 	adding PARSE-BODY primitive    
C01360 00358	∂15-May-85  1643	J.Dalton%edxa@Ucl-Cs.ARPA 	lexical closures  
C01365 00359	∂01-Jun-85  0859	RPG  	Preposterousness   
C01368 00360	∂16-May-85  1845	Masinter.pa@Xerox.ARPA 	Re: Macros -> declarations
C01370 00361	∂16-May-85  1847	FAHLMAN@CMU-CS-C.ARPA 	Preposterousness      
C01375 00362	∂16-May-85  1946	FAHLMAN@CMU-CS-C.ARPA 	Macros -> declarations
C01378 00363	∂16-May-85  2007	GRISS%hp-hulk.csnet@csnet-relay.arpa 	Collections of CL tests and validations   
C01380 00364	∂16-May-85  2346	RPG  	Benchmarking  
C01381 00365	∂17-May-85  0129	REM@IMSSS 	Property lists
C01383 00366	∂17-May-85  0544	KMP@SCRC-QUABBIN.ARPA 	Property lists   
C01386 00367	∂17-May-85  0621	KMP@SCRC-QUABBIN.ARPA 	Macros -> declarations
C01393 00368	∂17-May-85  0731	JLW  	∂10-May-85  0146	hoey@nrl-aic 	Re: EQUALP hash tables (and more ...)      
C01400 00369	∂17-May-85  0735	JLW  	SXHASH on circular structures?    
C01404 00370	∂17-May-85  0803	gls%AQUINAS@THINK.ARPA 	Poor excuse for packages  
C01406 00371	∂17-May-85  0803	Masinter.pa@Xerox.ARPA 	Re: Macros -> declarations
C01410 00372	∂17-May-85  0807	JLW  	EQUALP hash tables 
C01415 00373	∂17-May-85  0841	JLW  	hash table types   
C01417 00374	∂17-May-85  0905	BSG@SCRC-STONY-BROOK.ARPA 	Poor excuse for packages    
C01420 00375	∂17-May-85  0905	KMP@SCRC-STONY-BROOK.ARPA 	Poor excuse for packages    
C01425 00376	∂17-May-85  0905	Cassels@SCRC-STONY-BROOK.ARPA 	Poor excuse for packages
C01430 00377	∂17-May-85  0944	smh@mit-eddie.ARPA 	Re:  Poor excuse for packages 
C01434 00378	∂17-May-85  0957	hoey@nrl-aic 	SXHASH and EQ hash tables 
C01437 00379	∂17-May-85  0958	gls%AQUINAS@THINK.ARPA 	Poor excuse for a Quux    
C01439 00380	∂17-May-85  0959	gls%AQUINAS@THINK.ARPA 	Backquote idioms
C01442 00381	∂17-May-85  1045	@MIT-REAGAN.ARPA:Soley@MIT-MC.ARPA 	Macros -> declarations  
C01445 00382	∂17-May-85  1158	HEDRICK@RUTGERS.ARPA 	special declaration    
C01448 00383	∂17-May-85  1815	Moon@SCRC-STONY-BROOK.ARPA 	EQUALP hash tables (and more ...)    
C01451 00384	∂17-May-85  1831	Moon@SCRC-STONY-BROOK.ARPA 	Macros -> declarations
C01460 00385	∂17-May-85  2051	FAHLMAN@CMU-CS-C.ARPA 	Macros -> declarations
C01463 00386	∂18-May-85  0815	KMP@SCRC-STONY-BROOK.ARPA 	Macros -> declarations 
C01472 00387	∂18-May-85  0932	masinter.PA@Xerox.ARPA 	uses for specials    
C01474 00388	∂18-May-85  1112	KMP@SCRC-STONY-BROOK.ARPA 	DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special Form"  
C01481 00389	∂18-May-85  1156	WHOLEY@CMU-CS-C.ARPA 	Macros -> declarations 
C01484 00390	∂18-May-85  1352	FAHLMAN@CMU-CS-C.ARPA 	Macros -> declarations
C01493 00391	∂18-May-85  1406	FAHLMAN@CMU-CS-C.ARPA 	DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special Form" 
C01497 00392	∂18-May-85  1413	FAHLMAN@CMU-CS-C.ARPA 	Macros -> declarations (oops!)  
C01499 00393	∂18-May-85  1916	GSB@MIT-MC 	Re: EQUALP hash tables (and more ...) 
C01503 00394	∂19-May-85  0926	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special   
C01514 00395	∂19-May-85  0930	DD60@CMU-CS-A.ARPA 	user hash tables    
C01519 00396	∂19-May-85  1246	FAHLMAN@CMU-CS-C.ARPA 	Yellow pages
C01523 00397	∂20-May-85  0707	DCP@SCRC-STONY-BROOK.ARPA 	Macros -> declarations 
C01527 00398	∂20-May-85  0721	DCP@SCRC-STONY-BROOK.ARPA 	hash table types       
C01531 00399	∂20-May-85  1012	gls%AQUINAS@THINK.ARPA 	Backquote idioms
C01533 00400	∂20-May-85  1328	KMP@SCRC-VALLECITO.ARPA 	"Special Operator" vs "Special Form"    
C01539 00401	∂20-May-85  1810	GSB@MIT-MC 	hash table types -- ROT
C01541 00402	∂20-May-85  1844	GSB@MIT-MC 	terminology  
C01543 00403	∂20-May-85  2252	REM@IMSSS 	FORM vs. FUNCTION etc.  
C01546 00404	∂21-May-85  0801	RWK@SCRC-STONY-BROOK.ARPA 	Backquote idioms  
C01552 00405	∂21-May-85  0848	JAR@MIT-MC 	"Special Operator"
C01554 00406	∂21-May-85  2211	Moon@SCRC-VALLECITO.ARPA 	terminology   
C01556 00407	∂22-May-85  0805	gls%AQUINAS@THINK.ARPA 	Backquote idioms
C01568 00408	∂22-May-85  0853	DCP@SCRC-STONY-BROOK.ARPA 	Backquote idioms  
C01570 00409	∂22-May-85  0906	BSG@SCRC-RIVERSIDE.ARPA 	Backquote idioms    
C01574 00410	∂22-May-85  1010	DCP@SCRC-STONY-BROOK.ARPA 	Backquote idioms  
C01580 00411	∂22-May-85  1012	DDYER@USC-ISIB.ARPA 	Local SPECIAL declarations   
C01582 00412	∂22-May-85  1142	smh@mit-eddie.ARPA 	Re:  Backquote idioms    
C01586 00413	∂22-May-85  1155	gls@AQUINAS.ARPA 	Backquote idioms 
C01589 00414	∂22-May-85  1206	Masinter.pa@Xerox.ARPA 	Backquote idioms
C01591 00415	∂22-May-85  1213	KMP@SCRC-STONY-BROOK.ARPA 	Re:  Backquote idioms  
C01597 00416	∂22-May-85  1343	DCP@SCRC-STONY-BROOK.ARPA 	Re:  Backquote idioms  
C01600 00417	∂22-May-85  1600	RWK@SCRC-STONY-BROOK.ARPA 	Backquote idioms  
C01603 00418	∂22-May-85  1927	Moon@SCRC-STONY-BROOK.ARPA 	Special form terminology   
C01606 00419	∂22-May-85  1927	DLW@SCRC-STONY-BROOK.ARPA 	Macros -> declarations 
C01610 00420	∂22-May-85  2057	RAM@CMU-CS-C.ARPA 	Adjustable and displaced arrays
C01613 00421	∂22-May-85  2108	DLW@SCRC-STONY-BROOK.ARPA 	EQUALP hash tables (and more ...)     
C01616 00422	∂23-May-85  0130	STEINER@RUTGERS.ARPA 	Does FORMAT handle multiple values    
C01618 00423	∂23-May-85  0157	RAM@CMU-CS-C.ARPA 	Does FORMAT handle multiple values  
C01620 00424	∂23-May-85  0503	RAM@CMU-CS-C.ARPA 	Get-Setf-Method 
C01621 00425	∂23-May-85  0657	greek@DEC-HUDSON 	Adjusting Displaced Arrays 
C01622 00426	∂23-May-85  0747	gls%AQUINAS@THINK.ARPA 	Does FORMAT handle multiple values  
C01624 00427	∂23-May-85  0757	gls%AQUINAS@THINK.ARPA 	Adjustable and displaced arrays
C01629 00428	∂23-May-85  0818	gls%AQUINAS@THINK.ARPA 	Rules of the game    
C01635 00429	∂23-May-85  0841	fateman%ucbdali@Berkeley 	rules of the game  
C01638 00430	∂23-May-85  0939	GRISS%hp-hulk.csnet@csnet-relay.arpa 	Re: Local SPECIAL declarations  
C01640 00431	∂23-May-85  1038	RAM@CMU-CS-C.ARPA 	Adjustable and displaced arrays
C01643 00432	∂23-May-85  1113	DLW@SCRC-STONY-BROOK.ARPA 	Re:  Backquote idioms  
C01645 00433	∂23-May-85  1336	DCP@SCRC-STONY-BROOK.ARPA 	Adjustable and displaced arrays  
C01648 00434	∂23-May-85  1456	RPG   	Yellow pages 
C01650 00435	∂23-May-85  1539	STEINER@RUTGERS.ARPA 	Re: Does FORMAT handle multiple values
C01655 00436	∂23-May-85  1819	GSB@MIT-MC 	Get-Setf-Method   
C01656 00437	∂23-May-85  2022	DLW@SCRC-STONY-BROOK.ARPA 	Fahlman's comments     
C01659 00438	∂23-May-85  2302	GSB@MIT-MC 	Re: Adjustable and displaced arrays   
C01665 00439	∂24-May-85  0909	DLW@SCRC-STONY-BROOK.ARPA 	Rules of the game 
C01668 00440	∂24-May-85  0955	GRISS%hp-hulk.csnet@csnet-relay.arpa 	Addendum/Erratum 
C01670 00441	∂24-May-85  1030	gls%AQUINAS@THINK.ARPA 	Rules of the game and stability
C01674 00442	∂24-May-85  1300	gls%AQUINAS@THINK.ARPA 	Addendum/Erratum
C01682 00443	∂27-May-85  1105	RAM@CMU-CS-C.ARPA 	Does Defmacro establish a block?    
C01684 00444	∂27-May-85  1225	DLW@SCRC-STONY-BROOK.ARPA 	Does Defmacro establish a block? 
C01686 00445	∂28-May-85  0742	greek@DEC-HUDSON 	Rules of the Game
C01688 00446	∂28-May-85  0822	greek@DEC-HUDSON 	Adjusting displaced arrays.
C01690 00447	∂28-May-85  0946	DCP@SCRC-STONY-BROOK.ARPA 	Adjusting displaced arrays. 
C01694 00448	∂28-May-85  1439	masinter.pa@Xerox.ARPA 	programs writing backquote
C01696 00449	∂28-May-85  1450	masinter.pa@Xerox.ARPA 	Re: Rules of the game and stability 
C01697 00450	∂28-May-85  1515	KMP@SCRC-STONY-BROOK.ARPA 	programs writing backquote  
C01701 00451	∂28-May-85  1532	MASINTER@SUMEX-AIM.ARPA 	(duplicate) programs writing backquote  
C01704 00452	∂29-May-85  0005	REM@IMSSS 
C01708 00453	∂29-May-85  0709	greek@DEC-HUDSON 	Internal representation of backquotes
C01710 00454	∂29-May-85  1246	greek@DEC-HUDSON 	Internal representation of backquotes
C01712 00455	∂29-May-85  1257	DCP@SCRC-STONY-BROOK.ARPA 	programs writing backquote  
C01718 00456	∂29-May-85  1257	DLW@SCRC-STONY-BROOK.ARPA 	Re: Rules of the game and stability   
C01720 00457	∂29-May-85  1445	gls@AQUINAS.ARPA 	Re: Rules of the game and stability  
C01723 00458	∂31-May-85  0926	DCP@SCRC-STONY-BROOK.ARPA 	CLtL Index   
C01725 00459	∂31-May-85  1440	hplabs!perdue%hplabs.csnet@csnet-relay.arpa 	Re: Programs writing backquote
C01727 00460	∂02-Jun-85  0802	FAHLMAN@CMU-CS-C.ARPA 	Programs writing backquote 
C01730 00461	∂02-Jun-85  1058	FAHLMAN@CMU-CS-C.ARPA 	Rules of the game and stability 
C01736 00462	∂02-Jun-85  1220	FAHLMAN@CMU-CS-C.ARPA 	Get-Setf-Method  
C01738 00463	∂03-Jun-85  0520	JLW  	Explicit definition of backquote  
C01744 00464	∂03-Jun-85  0624	greek@DEC-HUDSON 	Programs writing backquotes
C01745 00465	∂03-Jun-85  0710	KMP@SCRC-STONY-BROOK.ARPA 	Programs writing backquotes 
C01747 00466	∂03-Jun-85  0945	vanroggen@DEC-HUDSON 	read macros  
C01749 00467	∂03-Jun-85  1925	GSB@MIT-MC.ARPA 	Get-Setf-Method   
C01751 00468	∂05-Jun-85  1328	gls@THINK.ARPA 	common lisp- &environment objects 
C01753 00469	∂05-Jun-85  1904	FAHLMAN@CMU-CS-C.ARPA 	common lisp- &environment objects    
C01756 00470	∂05-Jun-85  1921	FAHLMAN@CMU-CS-C.ARPA 	common lisp- &environment objects    
C01758 00471	∂06-Jun-85  0543	JLW  	Degenerate array axes   
C01761 00472	∂06-Jun-85  0740	gls@THINK.ARPA 	Degenerate array axes   
C01766 00473	∂06-Jun-85  0809	FAHLMAN@CMU-CS-C.ARPA 	Degenerate array axes      
C01769 00474	∂06-Jun-85  1001	FAHLMAN@CMU-CS-C.ARPA 	Degenerate array axes      
C01772 00475	∂06-Jun-85  1021	MLY@MIT-MC.ARPA 	Degenerate array axes  -- really array printing.
C01775 00476	∂06-Jun-85  1230	greek@DEC-HUDSON 	Arrays with zero dimensions.    
C01776 00477	∂06-Jun-85  2212	wilensky%ucbdali@Berkeley 	Common LISP terminology
C01787 00478	∂07-Jun-85  0651	gls@THINK.ARPA 	Arrays with zero dimensions. 
C01789 00479	∂07-Jun-85  0933	greek@DEC-HUDSON 	Arrays with Zero Dimensions
C01790 00480	∂09-Jun-85  1707	DCP@SCRC-YUKON.ARPA 	Arrays with zero dimensions. 
C01792 00481	∂09-Jun-85  1707	DCP@SCRC-YUKON.ARPA 	common lisp- &environment objects 
C01796 00482	∂09-Jun-85  1756	ima!inmet!norman@cca-unix
C01797 00483	∂09-Jun-85  2016	FAHLMAN@CMU-CS-C.ARPA 	common lisp- &environment objects    
C01803 00484	∂10-Jun-85  0357	DCP@SCRC-STONY-BROOK.ARPA 	common lisp- &environment objects
C01812 00485	∂10-Jun-85  0646	FAHLMAN@CMU-CS-C.ARPA 	common lisp- &environment objects    
C01818 00486	∂10-Jun-85  0702	REM@IMSSS 	Environment-objects don't exist in CL according to manual  
C01822 00487	∂10-Jun-85  0748	FAHLMAN@CMU-CS-C.ARPA 	Environment-objects don't exist in CL according to manual
C01826 00488	∂10-Jun-85  1040	HEDRICK@RUTGERS.ARPA 	extent of environments 
C01829 00489	∂10-Jun-85  1108	greek@DEC-HUDSON 	Scott's observation on MACROLET 
C01830 00490	∂10-Jun-85  1200	DCP@SCRC-STONY-BROOK.ARPA 	common lisp- &environment objects
C01834 00491	∂10-Jun-85  2256	@MIT-MC:BROOKS@MIT-OZ 	function type specifiers   
C01836 00492	∂11-Jun-85  1043	RWW  	using lower case   
C01837 00493	∂11-Jun-85  1245	Moon@SCRC-STONY-BROOK.ARPA 	Adjustable and displaced arrays 
C01847 00494	∂11-Jun-85  1247	FAHLMAN@CMU-CS-C.ARPA 	using lower case      
C01849 00495	∂11-Jun-85  1259	Moon@SCRC-STONY-BROOK.ARPA 	Degenerate array axes      
C01852 00496	∂11-Jun-85  1311	Moon@SCRC-STONY-BROOK.ARPA 	common lisp- &environment objects    
C01856 00497	∂11-Jun-85  1316	Moon@SCRC-STONY-BROOK.ARPA 	Does Defmacro establish a block?
C01859 00498	∂11-Jun-85  1317	gls@THINK.ARPA 	Environment-objects don't exist in CL according to manual  
C01861 00499	∂11-Jun-85  1817	FAHLMAN@CMU-CS-C.ARPA 	Does Defmacro establish a block?
C01864 00500	∂11-Jun-85  1819	FAHLMAN@CMU-CS-C.ARPA 	common lisp- &environment objects    
C01866 00501	∂11-Jun-85  1825	FAHLMAN@CMU-CS-C.ARPA 	Degenerate array axes      
C01868 00502	∂11-Jun-85  1842	FAHLMAN@CMU-CS-C.ARPA 	Adjustable and displaced arrays 
C01871 00503	∂11-Jun-85  2048	Moon@SCRC-STONY-BROOK.ARPA 	Does Defmacro establish a block?
C01874 00504	∂11-Jun-85  2052	Moon@SCRC-STONY-BROOK.ARPA 	Adjustable and displaced arrays 
C01878 00505	∂12-Jun-85  0417	walton%ll-xn.arpa@ll-xn.arpa 	Two suggestions on array adjustability. 
C01882 00506	∂12-Jun-85  0557	greek@DEC-HUDSON 	Using #.(MAKE-ARRAY ...    
C01884 00507	∂12-Jun-85  0630	greek@DEC-HUDSON 	Adjusting Displaced Arrays 
C01887 00508	∂12-Jun-85  0928	gls@THINK.ARPA 	Adjusting Displaced Arrays   
C01890 00509	∂12-Jun-85  0959	BSG@SCRC-STONY-BROOK.ARPA 	Using #.(MAKE-ARRAY ...
C01893 00510	∂12-Jun-85  1225	greek@DEC-HUDSON 	Printing Arrays with #.    
C01894 00511	∂12-Jun-85  1312	REM@IMSSS 	Test suite to say what manual is confusing about 
C01896 00512	∂12-Jun-85  1339	REM@IMSSS 	Printing of displaced/shared arrays    
C01899 00513	∂12-Jun-85  1353	AS%hp-hulk.csnet@csnet-relay.arpa 	Re: Does Defmacro establish a block?    
C01902 00514	∂12-Jun-85  1459	RAM@CMU-CS-C.ARPA 	Does Defmacro establish a block?    
C01904 00515	∂12-Jun-85  1704	@MIT-MC.ARPA:BROOKS@MIT-OZ 	declaration pervasiveness. 
C01906 00516	∂13-Jun-85  0542	BSG@SCRC-STONY-BROOK.ARPA 	Re: Does Defmacro establish a block?  
C01908 00517	∂13-Jun-85  0821	DCP@SCRC-STONY-BROOK.ARPA 	declaration pervasiveness.  
C01912 00518	∂13-Jun-85  0933	FAHLMAN@CMU-CS-C.ARPA 	declaration pervasiveness. 
C01915 00519	∂13-Jun-85  0935	@MIT-MC.ARPA:BROOKS@MIT-OZ 	Re: declaration pervasiveness.  
C01918 00520	∂13-Jun-85  1139	gls@THINK.ARPA 	declaration pervasiveness.   
C01923 00521	∂13-Jun-85  1246	@MIT-MC.ARPA:BROOKS@MIT-OZ 	Re: declaration pervasiveness.  
C01927 00522	∂13-Jun-85  1428	AS%hp-hulk.csnet@csnet-relay.arpa 	conflicting declarations 
C01930 00523	∂13-Jun-85  1447	FAHLMAN@CMU-CS-C.ARPA 	conflicting declarations   
C01932 00524	∂13-Jun-85  1942	Moon@SCRC-STONY-BROOK.ARPA 	What package are feature names resident in?    
C01940 00525	∂14-Jun-85  0610	greek@DEC-HUDSON 	What's in *FEATURES*? 
C01942 00526	∂14-Jun-85  0900	gls@THINK.ARPA 	[hpfclp!paul%hplabs.csnet: LCM]   
C01945 00527	∂14-Jun-85  1010	Moon@SCRC-STONY-BROOK.ARPA 	What's in *FEATURES*? 
C01949 00528	∂14-Jun-85  1120	KMP@SCRC-STONY-BROOK.ARPA 	What's in *FEATURES*?  
C01956 00529	∂14-Jun-85  1317	greek@DEC-HUDSON 	Putting features in the keyword package.  
C01959 00530	∂14-Jun-85  1439	REM@IMSSS 	Features in keyword package? Yes. 
C01962 00531	∂14-Jun-85  1503	Masinter.pa@Xerox.ARPA 	What #+rmhackery a good idea #-rmhackery utter nonsense 
C01964 00532	∂14-Jun-85  1810	DCP@SCRC-STONY-BROOK.ARPA 	What #+rmhackery a good idea #-rmhackery utter nonsense   
C01969 00533	∂14-Jun-85  1846	FAHLMAN@CMU-CS-C.ARPA 	features    
C01973 00534	∂14-Jun-85  2043	KMP@SCRC-STONY-BROOK.ARPA 	features
C01980 00535	∂15-Jun-85  1859	Masinter.pa@Xerox.ARPA 	Re: What #+rmhackery a good idea #-rmhackery utter nonsense  
C01982 00536	∂16-Jun-85  0600	DCP@SCRC-STONY-BROOK.ARPA 	Re: What #+rmhackery a good idea #-rmhackery utter nonsense    
C01988 00537	∂16-Jun-85  1300	KMP@SCRC-STONY-BROOK.ARPA 	Re: What #+rmhackery a good idea #-rmhackery utter nonsense    
C01993 ENDMK
C⊗;
∂24-Jan-85  1800	Moon@SCRC-STONY-BROOK.ARPA 	Make-Hash-Table  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Jan 85  18:00:07 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 165974; Thu 24-Jan-85 21:01:32-EST
Date: Thu, 24 Jan 85 21:00 EST
From: David A. Moon <Moon@SCRC-RIVERSIDE.ARPA>
Subject: Make-Hash-Table
To: Skef Wholey <Wholey@CMU-CS-C.ARPA>
cc: Common-Lisp@SU-AI.ARPA, Common-Lisp-Implementation@SU-AI.ARPA,
    bug-CLCP@SCRC-STONY-BROOK.ARPA
In-Reply-To: <WHOLEY.12081735733.BABYL@CMU-CS-C.ARPA>
Message-ID: <850124210049.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 22 Jan 1985  22:56 EST
    From: Skef Wholey <Wholey@CMU-CS-C.ARPA>

    I propose the following clarification to the specification of how the
    :rehash-threshold and :rehash-size options interact:

    There are four cases:

	    1. :rehash-threshold is an integer and :rehash-size is an integer.

	    In this case, when a hash table is grown (by adding rehash-size to
	    the current hash table size), the rehash-threshold is scaled up by
	    multiplying it by the ceiling of the ratio of the new size to the
	    original size.

	    2. :rehash-threshold is an integer and :rehash-size is a float.

	    In this case, when a hash table is grown (by multiplying the current
	    hash table size by the rehash-size), the rehash-threshold is scaled
	    up by multiply it, too, by the rehash-size.

Don't forget to convert the result of that multiplication from a float back
to an integer!

	    3. :rehash-threshold is a float and :rehash-size is an integer.

	    In this case, when a hash table is grown (by adding rehash-size to
	    the current hash table size), we just leave the rehash-threshold
	    alone.

	    4. :rehash-threshold is a float and :rehash-size is a float.

	    To grow, just multiply the current hash table size by the rehash-size
	    and again leave the rehash-threshold alone.

    If :rehash-threshold is a fixnum, then the hash table is grown when the number
    of entries in the table exceeds the :rehash-threshold.  If :rehash-threshold is
    a float, then the hash table is grown when the ratio of the number of entries
    in the to the size of the table exceeds the :rehash-threshold.

I think you can eliminate cases 1 and 2 by the trick of doing
  (when (integerp rehash-threshold)
    (setq rehash-threshold (/ (float rehash-threshold) size)))
at initialization.  Now it scales automatically.

    This seems to be the "obvious" interpretation of the description on pages
    283-284, and this is how I intended to implement hash tables for Spice Lisp.

I believe this interpretation.

Bug-CLCP: We don't seem to implement any case other than #4.  This is mentioned
in the release notes.

∂24-Jan-85  1800	Moon@SCRC-STONY-BROOK.ARPA 	Make-Hash-Table  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Jan 85  18:00:07 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 165974; Thu 24-Jan-85 21:01:32-EST
Date: Thu, 24 Jan 85 21:00 EST
From: David A. Moon <Moon@SCRC-RIVERSIDE.ARPA>
Subject: Make-Hash-Table
To: Skef Wholey <Wholey@CMU-CS-C.ARPA>
cc: Common-Lisp@SU-AI.ARPA, Common-Lisp-Implementation@SU-AI.ARPA,
    bug-CLCP@SCRC-STONY-BROOK.ARPA
In-Reply-To: <WHOLEY.12081735733.BABYL@CMU-CS-C.ARPA>
Message-ID: <850124210049.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 22 Jan 1985  22:56 EST
    From: Skef Wholey <Wholey@CMU-CS-C.ARPA>

    I propose the following clarification to the specification of how the
    :rehash-threshold and :rehash-size options interact:

    There are four cases:

	    1. :rehash-threshold is an integer and :rehash-size is an integer.

	    In this case, when a hash table is grown (by adding rehash-size to
	    the current hash table size), the rehash-threshold is scaled up by
	    multiplying it by the ceiling of the ratio of the new size to the
	    original size.

	    2. :rehash-threshold is an integer and :rehash-size is a float.

	    In this case, when a hash table is grown (by multiplying the current
	    hash table size by the rehash-size), the rehash-threshold is scaled
	    up by multiply it, too, by the rehash-size.

Don't forget to convert the result of that multiplication from a float back
to an integer!

	    3. :rehash-threshold is a float and :rehash-size is an integer.

	    In this case, when a hash table is grown (by adding rehash-size to
	    the current hash table size), we just leave the rehash-threshold
	    alone.

	    4. :rehash-threshold is a float and :rehash-size is a float.

	    To grow, just multiply the current hash table size by the rehash-size
	    and again leave the rehash-threshold alone.

    If :rehash-threshold is a fixnum, then the hash table is grown when the number
    of entries in the table exceeds the :rehash-threshold.  If :rehash-threshold is
    a float, then the hash table is grown when the ratio of the number of entries
    in the to the size of the table exceeds the :rehash-threshold.

I think you can eliminate cases 1 and 2 by the trick of doing
  (when (integerp rehash-threshold)
    (setq rehash-threshold (/ (float rehash-threshold) size)))
at initialization.  Now it scales automatically.

    This seems to be the "obvious" interpretation of the description on pages
    283-284, and this is how I intended to implement hash tables for Spice Lisp.

I believe this interpretation.

Bug-CLCP: We don't seem to implement any case other than #4.  This is mentioned
in the release notes.

∂25-Jan-85  0801	REM@IMSSS 	how to document yellow page entries, belated discussion by REM  
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 85-01-25 07:57:12 PST (=GMT-8hr)
Date: 85-01-25 07:54:58 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132012160130.G0348
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To:Fahlman@CMU-CS-C
CC:COMMON-LISP@SU-AI
Subject: how to document yellow page entries, belated discussion by REM
Reply-to: REM%IMSSS@SU-SCORE.ARPA

> Date: Thu, 24 Jan 1985  21:18 EST
> From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
> 
> ;;; Program name: Gritch Generator
> ;;; Keywords: foo, bar, grumble, bletch
> ;;; Author: James Madison
> ;;; Description: This is an example of a long field that goes onto more
> ;;;  than one line.  The subsequent lines have this extra bit of
> ;;;  indentation after the triple-semicolon stuff.

One disadvantage of this format, as any ;-style comments, is that when
you copy a file using the LISP reader, such as to prettyprint or to
translate to another dialect, or to convert into or out of RLISP form,
or to expand some private macros, etc., all those comments are
stripped off during READing and thus will be missing from the output
version of the program.  Do you know of a LISP pseudo-reader that
somehow internalizes sections of a file like READ does except that
;-style comments are retained, somehow attached to the normal
s-expressions, so that when the file is PRINTed or PRETTYPRINTed etc.
back out using a correspondingly-modified version of the appropriate
output function the ;-style comments are put back in?

If not, I would say that *any* use of ;-style comments in an otherwise
READable&PRINTable LISP-source file is bad programming style since it
limits the kinds of processing that can effectively be done on the file.

(CC to COMMON-LISP general forum to spark debate on this controversial issue.)

∂26-Jan-85  1753	FAHLMAN@CMU-CS-C.ARPA 	how to document yellow page entries, belated discussion by REM
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 26 Jan 85  17:53:13 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 26 Jan 85 20:54:38-EST
Date: Sat, 26 Jan 1985  20:54 EST
Message-ID: <FAHLMAN.12082762097.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   REM%IMSSS@SU-SCORE.ARPA
Cc:   COMMON-LISP@SU-AI.ARPA
Subject: how to document yellow page entries, belated discussion by REM
In-reply-to: Msg of 85-01-25 07:54:58 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.SU.EDU>


I totally disagree with your statement that *any* use of ;-style
comments in an otherwise readable and printable file is bad programming
style.  If there is some reason you want to process or save such
comments when the file is read, it is a trivial matter to redefine the
character macro for #\; to pack the comment line into a string and
return it in some form that the reader will find unobjectionable.

So I see no reason why ;-style comments are not a good vehicle for
header information in yellow pages files.  The default Common Lisp
reader discards these things, but that's what you want most of the time.
If you want a program to extract and save this stuff, building a reader
to do that is well within the capabilities of most beginning Lisp
programmers.

-- Scott

∂26-Jan-85  2003	FAHLMAN@CMU-CS-C.ARPA 	A proposal  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 26 Jan 85  20:03:19 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 26 Jan 85 23:04:42-EST
Date: Sat, 26 Jan 1985  23:04 EST
Message-ID: <FAHLMAN.12082785776.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   cl-charter@SU-AI.ARPA, ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA,
      squires@USC-ISI.ARPA
Subject: A proposal


So far, I've only received two replies to my charter proposal, one from
Guy Steele and one from Richard Fateman.  That means either that (a) all
the rest of you agree with my proposal in all its details, (b) all of
you find it so hopelessly wrong that it's not worth commenting on, (c)
none of you give a damn about these issues, or (d) you people out in
companies only read your mail once a month.  At least let me know which
of these is really the case.

Fateman favors going with no formal organization at all, in part because
he believes that the legal fees will be overwhelming if we try to start
such a thing.  Does anyone have some hard data on the legal costs for
similar efforts?

To answer another of Fateman's queries, I think that Digital Press would
be quite willing to turn the copyright over to the organization, once it
is up and running, as long as they retain the exclusive rights to
publish the manual in commercial book form.  They have suggested as much
in preliminary discussions, though there are a large number of details
to be worked out.  We can't proceed with anything like this until there
is some entity with whom they can make the deal.

We come finally, to the central point:

     Why, after all this, is (3) not so bad?  Well, look at what happened
  to Lisp 1.5, and the little MIT press blue&white book describing it.
  Was that so bad?  Did anyone ever validate a lisp 1.5 implementation?

In my opinion, it was "so bad".  The lack of a usable standard
for Lisp 1.5, and some way of updating that standard as Lisp evolved
into something whose relation to Lisp 1.5 was almost unrecognizable, was
responsible for a couple of major schisms and a huge amount of duplicated
effort.  The resulting chaotic situation probably set the
commercialization of AI back by 5 years or so.

Finally, Fateman argues that a separate organization would make it
inevitable that the original group of Common Lisp people would lose
control of the language as more and more companies develop a strong
commercial interest in it.  That seems like a desirable evolution to me.
Who better to control the language than those who have a stake in it?
If the language becomes too stable over time, we researchers will just
have to call our wild new languages something else.

Both Fateman and Steele have expressed some uneasiness over the veto
power that I proposed for the industrial members, on the grounds that
such companies would tend to be too conservative.  I think that both of
you are selling the companies short.  I have not noticed any tendency of
the companies involved in this process to be more conservative than
anyone else.  On a lot of issues I've been the conservative, or Gabriel
has, or Hedrick or Fateman -- academics all (at the time).  Where people
from the stock-hardware companies have felt that they lacked expertise
on some issue, they have generally kept quiet.  I see no reason to
believe that this would change.  Of course the companies will resist any
expensive changes for which there is not a clear benefit to be gained,
but so will the rest of us -- that's what stability is all about.

Note that I am NOT proposing that any single company, or small group of
them, be given a veto.  That would be disastrous.  But if the technical
committee cannot persuade at least half of the companies that some change
is worthwhile, it seems to me that the change should not go through.
Note also that even a majority of the companies could not force through
a lot of changes that would ruin the existing language, unless they also
gain control of the technical committee.  The pressure to come up with
subsets and compromises will evaporate after a year or two; by then,
most companies will be offering full Common Lisp implementations and
will no longer have much interest in reverting to dynamic scoping or
flushing all of the sequence functions.

The reason for including this veto provision in the first place is that,
when I try to look at this organization from the point of view of the
companies who want to invest heavily in Common Lisp, I see a need for
some protection against the technical committee (a small group of
people, after all) going crazy and changing the language beyond all
recognition, destroying my investment.  To spin out just one disturbing
fantasy, some company that does not want to see Common Lisp succeed
might try to pack the association with its employees as individual
members, elect a technical committee of its own liking, and hijack the
language definition machinery.  The mere existence of a veto power by
the other corporate members would eliminate this threat, I think.

For those reasons, I would oppose giving the technical committee the
final word by giving them the power to over-ride vetos.  It wouldn't
bother me to require a 2/3 majority of corporate members for a veto, but
I prefer a simple majority.  As a practical matter, I think that any
technical committee would be mad to shove through any change that is not
acceptable to a majority of the companies, even if they had the power to
do so.

-- Scott

∂26-Jan-85  2139	Moon@SCRC-STONY-BROOK.ARPA 	A proposal  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Jan 85  21:39:41 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 166927; Sun 27-Jan-85 00:42:42-EST
Date: Sun, 27 Jan 85 00:42 EST
From: David A. Moon <Moon@SCRC-RIVERSIDE.ARPA>
Subject: A proposal
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: cl-charter@SU-AI.ARPA, ohlander@USC-ISI.ARPA,
    quinquevirate@SU-AI.ARPA, squires@USC-ISI.ARPA
In-Reply-To: <FAHLMAN.12082785776.BABYL@CMU-CS-C.ARPA>
Message-ID: <850127004201.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sat, 26 Jan 1985  23:04 EST
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

    So far, I've only received two replies to my charter proposal, one from
    Guy Steele and one from Richard Fateman.  That means either that (a) all
    the rest of you agree with my proposal in all its details, (b) all of
    you find it so hopelessly wrong that it's not worth commenting on, (c)
    none of you give a damn about these issues, or (d) you people out in
    companies only read your mail once a month.  At least let me know which
    of these is really the case.

(c).  Note that I am not on the CL-Charter mailing list.  Other people at
Symbolics are on that mailing list, perhaps they will speak up.  Some of
them are extremely busy this month trying to get out a software release
on time and with an acceptable level of bugs, so maybe that explains the
delay.  I am sure the "official" position of Symbolics is not (c).

The rest of your message seems reasonable to me.

∂26-Jan-85  2216	REM%IMSSS.#Pup@SU-SCORE.ARPA 	Character macros, erratum
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 26 Jan 85  22:16:13 PST
Received: from IMSSS by Score with Pup; Sat 26 Jan 85 22:15:36-PST
Date: 26 Jan 1985 2214-PST
From: Rem@IMSSS
Subject: Character macros, erratum
To:   COMMON-LISP%SU-AI@SCORE

According to the index in the CL book, topic "characters", subtopic
"macros" is on pages 246-351 inclusive. This is obviusly a typo.
Does somebody have a collected list of errata that I could use to
fixup my copy of the book en masse to avoid bumping into already-found
errata? I think I asked this general question when I first found out
about this mailing list, but nobody knew of any such errata collection.
[Erratum of my own, which I cannot correct in NETMSG=SNDMSG:
 obviusly -> obviously]
-------

∂26-Jan-85  2340	fateman%ucbdali@Berkeley 	Re:  A proposal    
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 26 Jan 85  23:40:02 PST
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.41)
	id AA07748; Sat, 26 Jan 85 23:41:07 pst
Received: by ucbdali.ARPA (4.24/4.40)
	id AA26395; Sat, 26 Jan 85 23:41:09 pst
Date: Sat, 26 Jan 85 23:41:09 pst
From: fateman%ucbdali@Berkeley (Richard Fateman)
Message-Id: <8501270741.AA26395@ucbdali.ARPA>
To: Fahlman@CMU-CS-C.ARPA, cl-charter@SU-AI.ARPA, ohlander@USC-ISI.ARPA,
        quinquevirate@SU-AI.ARPA, squires@USC-ISI.ARPA
Subject: Re:  A proposal

	Fateman favors going with no formal organization at all, in part because
	he believes that the legal fees will be overwhelming if we try to start
	such a thing.  Does anyone have some hard data on the legal costs for
	similar efforts?
I am sure that the costs would be higher for anything "original" 
(as opposed to what has been done with Fortran, COBOL, Basic, Pascal, MUMPS).
I wonder if the extra cost would buy much.
	
	To answer another of Fateman's queries, I think that Digital Press would
	be quite willing to turn the copyright over to the organization, once it
	is up and running, as long as they retain the exclusive rights to
	publish the manual in commercial book form.
Whose manual?  CommonLisptheLanguage is not a reference manual.  Where, for
example, are the error messages? The debugger?  It is an incomplete work.
I agree that there are a large number of details to be worked out, but there
are some major issues, too.  To what extent does DEC own all "composite" works?
Would DEC permit a "composite" to remove sections or paragraphs ... e.g.
to change the meaning of a function ..  or to use dynamic rather than
lexical scope? Or would DEC be the de facto standard setter by saying that
if you alter anything you must write the manual from scratch?
	
	The lack of a usable standard
	for Lisp 1.5, and some way of updating that standard as Lisp evolved
	into something whose relation to Lisp 1.5 was almost unrecognizable, was
	responsible for a couple of major schisms and a huge amount of duplicated
	effort.  The resulting chaotic situation probably set the
	commercialization of AI back by 5 years or so.
I guess I disagree.  The effort to make an Interlisp program run in a
Maclisp system, or vice versa strikes me as not so great.  Few people
have wanted to use other people's "magnum opus" programs as components in 
their systems.  The fact that some were Interlisp and others Maclisp
is irrelevant.  The smaller programs... tools like the BBN/Interlisp/CMU-Franz
structure editor or flavors .. have been moved.  In spite of the biennial
Crisis-in-Lisp meetings, I am not sure anyone can point to any great
waste of human effort in retargeting.  It's been mostly religion, and
all we see now is Maclisp is in the ascendancy.

Perhaps this is not the place to discuss the question, but do you have
in mind some "commercial AI program of today" that might have been out
5 years earlier? Certainly Macsyma would not have been affected by this
issue.  I doubt that KEE would have been.
I think hardware has been much more critical.
	
	The pressure to come up with
	subsets and compromises will evaporate after a year or two; by then,
	most companies will be offering full Common Lisp implementations and
	will no longer have much interest in reverting to dynamic scoping or
	flushing all of the sequence functions.
I doubt it. Do you think IBM PCs and Macintoshes will evaporate in 2 years?
	
	To spin out just one disturbing
	fantasy, some company that does not want to see Common Lisp succeed
	might try to pack the association with its employees as individual
	members, elect a technical committee of its own liking, and hijack the
	language definition machinery.
How has this been avoided in Fortran or ... committees?  Why are you assuming
we must break new ground?
	
I too would like to hear from the others..

∂27-Jan-85  0952	FAHLMAN@CMU-CS-C.ARPA 	A proposal  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Jan 85  09:52:43 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 27 Jan 85 12:53:47-EST
Date: Sun, 27 Jan 1985  12:53 EST
Message-ID: <FAHLMAN.12082936705.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   fateman%ucbdali@λBerkeley (Richard Fateman)λ
Cc:   cl-charter@SU-AI.ARPA, ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA,
      squires@USC-ISI.ARPA
Subject: A proposal


Richard,

  I am sure that the costs would be higher for anything "original" 
  (as opposed to what has been done with Fortran, COBOL, Basic, Pascal, MUMPS).
  I wonder if the extra cost would buy much.

Well, our situation is unique in some ways, I think, but I certainly
don't want to invent any more of this than is necessary.  One reason I'm
uneasy about chairing this group is that I've carefully avoided
standardization committees and other such political groups in the past,
so I'm not very well acquainted with some of these earlier efforts.  All
that I've heard about them have been a lot of horror stories.  If anyone
can point to an existing model that they think is worth emulating, and
to some way of getting the details on it, I'd love to copy something
successful. 

On the manual issue, the Common Lisp organization would control the
content and any additions.  Digital Press has never wanted to control
the content of they manual; they have tried to faithfully follow our
request that nobody be allowed to reprint the manual with random
mutations of their own choosing.  I think that Digital Press would be
satisfied with any arrangement in which, if some composite work is to be
published as a commercial book, they either do the publishing or get a
roylaty on the part of the work they now control.  The problem with
licensing legitimate derivitive works has been the low bandwidth of our
interations with Digital Press, the slow pace at which Digital Press
does anything, and some confusion about who speaks for the Common Lisp
community.  If the organization were to gain control of the copyright,
these problems would be greatly alleviated.  In fact, that's one of the
biggest reasons why we ought to move fast on this charter business and
not let it sit for a year.

As for the "5 years earlier" issue, I wasn't terribly close to Macsyma,
but it is probably a good example of a program that would have found its
way into industry many years ago if the Lisp that it ran on was stable,
well-documented, and ran more or less compatibly on a variety of
machines.  When I was at MIT, eight or so years ago, I heard many rumors
of industrial groups looking into Macsyma and other early Maclisp-based
systems and giving up when they saw what kind of shape Maclisp was in.
(Some of them probably were driven away by MIT's lawyers instead, but
that's another problem.)

I don't think that Macintoshes and IBM PC's will have disappeared in two
years, but I am quite sure that virtual-memory PC's, capable of running
a full Common Lisp with editor and compiler, will exist within that time
frame at prices comparable to today's Macintoshes and PC's.  There will
be plenty of non-VM personal computers still running -- older machines
or super-cheap ones -- but there will be plenty of clean,
well-considered subsets of Common Lisp running on these machines.

Right now, most of the pressure for substantially altering Common Lisp
comes not from the small-machine people, but from those trying to turn
some already-existing Lisp into Common Lisp by bending it a little.
This is the game that I think will be over within a year or two.  By
then, these people will either have succeeded in developing a legal
Common Lisp from wherever they are starting, or will have been blown
away by some from-scratch Common Lisp implementation for the same
machine.

-- Scott

∂27-Jan-85  1701	@MIT-MC:PGS@MIT-OZ 	definition of lexical closure 
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Jan 85  17:00:58 PST
Date: Sun, 27 Jan 1985  19:57 EST
Message-ID: <PGS.12083013843.BABYL@MIT-OZ>
From: PGS%MIT-OZ@MIT-MC.ARPA
To:   common-lisp@SU-AI.ARPA
Subject: definition of lexical closure

I was talking to someone today about the Common Lisp notion of a closure, and
I noticed that the definition of a lexical closure on page 87 of the CL
manual is sort of vague and unsatisfactory.  It says that a lexical closure
is the object returned by FUNCTION, that is, a function which, when invoked,
obeys the rules for lexical scoping.

The problem with this definition is that it makes it difficult to explain why
the thing referred to is called a closure.  It's hard to relate the definition
even vaguely to the set-theoretic notion of a closure, because it doesn't
describe a set, so one can't explain the term as coming from the notion of
`closing over' a set of bindings.

If you say that the reason why lexical closures are functions in Common Lisp,
and not just sets of bindings, is because there is this sense of a closure
not only of the bindings in the definition environment, but of the bindings
of the formals to the actuals in the invocation of a function, you create
this other pedagogical problem, which is that the thing returned by FUNCTION
isn't a lexical closure then, because it can't include the bindings created
by function invocation, because those bindings are created afresh whenever
the function is invoked, and don't even exist when the object is returned.

It was easier to explain what a Lisp Machine Lisp closure was, because there
was an idea that a closure existed as something separate from a function.  One
could do more than invoke the closure's function; there were things like
SYMEVAL-IN-CLOSURE, for example.  So a closure could be explained as a set of
bindings, which is much more palatable than saying that it is a function.

Those were sets of dynamic bindings.  What I would like to say to people who
ask what a lexical closure is in Common Lisp is that it is a set of lexical
bindings; that is, the set of lexical bindings in the environment in which a
function is defined.  Then we could say that FUNCTION returns, not a lexical
closure, but an object that includes a lexical closure, and that the
environment in which the function text is evaluated is the union of that
lexical closure with the bindings of the formals to the actuals.

I'd like to see this definition in a future edition of the CL manual, on the
grounds that it's cleaner and therefore easier to teach.  Would anyone object?

∂27-Jan-85  1705	fateman%ucbdali@Berkeley 	Re:  A proposal    
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 27 Jan 85  17:05:22 PST
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.41)
	id AA18772; Sun, 27 Jan 85 17:06:22 pst
Received: by ucbdali.ARPA (4.24/4.40)
	id AA00855; Sun, 27 Jan 85 17:06:25 pst
Date: Sun, 27 Jan 85 17:06:25 pst
From: fateman%ucbdali@Berkeley (Richard Fateman)
Message-Id: <8501280106.AA00855@ucbdali.ARPA>
To: Fahlman@CMU-CS-C.ARPA, fateman%ucbdali%λBerkeleyλ@Berkeley
Subject: Re:  A proposal
Cc: cl-charter@SU-AI.ARPA, ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA,
        squires@USC-ISI.ARPA

Is it your intention to forbid a lisp manual to use the CL chapter
on packages [paying suitable royalties], if the lisp in question
neglects to adopt the string chapter? How about lexical scoping?  
Is this DEC's intention too?  I guess I would be happier if the manual
were put in the public domain, and the imprimateur of the CL committee
was separate.

P.S...apologies for the tangent...but...
Macsyma's distribution problems have been caused by
hardware and legal issues, not divisiveness in languages. Had Macsyma
run in Interlisp and PSL, nothing would have changed. Had anyone really
wanted either of these, they could have been done, technically speaking,
without much effort.  

The VAX solved the hardware issues. The MC68000 and cheap memory
made the solution more realistic.
Few people realize that Macsyma has been run routinely FOR 2 YEARS on numerous
(different) 68000-based workstations at UCB. 
MIT and Symbolics have maintained legal barriers to its distribution.

∂27-Jan-85  1727	FAHLMAN@CMU-CS-C.ARPA 	A proposal  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Jan 85  17:26:54 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 27 Jan 85 20:27:45-EST
Date: Sun, 27 Jan 1985  20:27 EST
Message-ID: <FAHLMAN.12083019346.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   fateman%ucbdali@λBerkeley (Richard Fateman)λ
Cc:   cl-charter@SU-AI.ARPA, ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA,
      squires@USC-ISI.ARPA
Subject: A proposal
In-reply-to: Msg of 27 Jan 1985  20:06-EST from fateman%ucbdali at Berkeley (Richard Fateman)


    Is it your intention to forbid a lisp manual to use the CL chapter
    on packages [paying suitable royalties], if the lisp in question
    neglects to adopt the string chapter? How about lexical scoping?  
    Is this DEC's intention too?  I guess I would be happier if the manual
    were put in the public domain, and the imprimateur of the CL committee
    was separate.

I see two issues here.  First, the manual is at present the sole written
form of the Common Lisp standard, and the whole community has an
interest in preventing random mutations in that standard, or confusion
as to what the standard really is.  So I believe that if anyone wants to
use parts of this manual and not other parts, this should only be
allowed if there is a firm agreement that the new version clearly label
itself as not a Common Lisp, but is a distinct dialect that happens to
use a package system identical to that in Common Lisp (or whatever).
That's very important.  Putting the manual in the public domain would
allow the publication of many nearly-identical versions of the manual,
all claiming to be Common Lisp, and some of them "improved" in various
ways by irresponsible or incompetent editors.

The other issue is simply makign sure that the original author and/or
the current copyright holder is appropriately compensated if commercial
use is made of significant parts of the original work.  That can be a
private matter between the parties concerned.

-- Scott

∂28-Jan-85  0511	OHLANDER@USC-ISI.ARPA 	Re: A proposal   
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 28 Jan 85  05:11:34 PST
Date: 28 Jan 1985 08:11-EST
Sender: OHLANDER@USC-ISI.ARPA
Subject: Re: A proposal
From: OHLANDER@USC-ISI.ARPA
To: Fahlman@CMU-CS-C.ARPA
Cc: cl-charter@SU-AI.ARPA, quinquevirate@SU-AI.ARPA
Cc: squires@USC-ISI.ARPA
Message-ID: <[USC-ISI.ARPA]28-Jan-85 08:11:50.OHLANDER>
In-Reply-To: <FAHLMAN.12082785776.BABYL@CMU-CS-C.ARPA>

Scott, 
	I have not expressed an opinion yet, not because I am not
vitally interested, but because I have been on travel and am now
just catching up with correspondence.  Personnaly, I think the
charter issue is the most vital thing that has to happen if the a
users group is going to materialize.  I am overjoyed that you
have taken some steps to get issues on the table and a draft
going.

I agree with Scott in that we need some form of formal
organization.  In terms of what it costs to get going, we might
be able to gain some idea of what it takes from some of the
original organizers of the AAAI.

We need a formal organization because it is essential to
"institutionalize" Common Lisp in order to make provision for its
continuance after key people disappear from the scene and also in
order to retain some kind of control over its instantiation and
continued refinement.  An informal group can lose interest and
not feel committed in the long run to the health of Common Lisp.
Organizations outlive its individual members, have more stature,
and have a stronger commitment to its objectives.

The veto issue is a key one.  On the one hand, we have all seen
vendors who are reluctant to make changes to a language and only
issue new releases under the strongest pressure.  However, as
Scott points out the vendors will have a vested interest and tend
to act as counterbalance to academics who might want to run a
little wild.  I believe the essential problem is to come up with
a mechanism that permits a balance of viewpoints to prevail.  I
think I lean towards a 2/3 vote to veto recommendations of the
technical community.

Ron

∂28-Jan-85  0739	OHLANDER@USC-ISI.ARPA 	Re: A proposal   
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 28 Jan 85  07:38:59 PST
Date: 28 Jan 1985 08:23-EST
Sender: OHLANDER@USC-ISI.ARPA
Subject: Re: A proposal
From: OHLANDER@USC-ISI.ARPA
To: Fahlman@CMU-CS-C.ARPA
Cc: cl-charter@SU-AI.ARPA, quinquevirate@SU-AI.ARPA
Cc: squires@USC-ISI.ARPA
Message-ID: <[USC-ISI.ARPA]28-Jan-85 08:23:21.OHLANDER>
In-Reply-To: <FAHLMAN.12082936705.BABYL@CMU-CS-C.ARPA>

I gorgot to mention that I have talked to Osbourne at Digital
Press and Fuller at Dec.  I believe that they would be willing to
stipulate that the Common Lisp Users group would own all reights
to the Common Lisp specification.  Furthermore, they have both
said that they look upon their contribution to the establishment
of Common Lisp as a public service and would be willing to
contibute some share of profits to the users group.  I think we
have to get some sort of agreement in writing and am going to see
if I can get government lawyers involved.

I should also point out that Digital Press's claim to a
copywright is questionable.  What do they have a copyright for?
There were a number of organizations and individuals that
contributed to the overall effort.  I think they may have a valid
claim to the manual, as written, but how can they have a clear
claim for the specification.  to complicate the problem, how do
you diambiguate the two?

I believe that we can reach a reasonable written agreement after
we (or in conjunction with) getting a users group established.
By the way, this is another reason for formal status of the users
group.  We have to get a written agreement because players will
change over the years.

Ron

∂29-Jan-85  0335	@MIT-MC:PGS@MIT-OZ 	definition of lexical closure 
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 29 Jan 85  03:35:31 PST
Date: Tue, 29 Jan 1985  06:34 EST
Message-ID: <PGS.12083391933.BABYL@MIT-OZ>
From: PGS%MIT-OZ@MIT-MC.ARPA
To:   common-lisp@SU-AI.ARPA
Subject: definition of lexical closure
In-reply-to: Msg of 27 Jan 1985  19:57-EST from PGS

    Date: Sunday, 27 January 1985  19:57-EST
    From: PGS
    To:   common-lisp at SU-AI.ARPA
    Re:   definition of lexical closure

    I was talking to someone today about the Common Lisp notion of a closure,
    and I noticed that the definition of a lexical closure on page 87 of the
    CL manual is sort of vague and unsatisfactory.  It says that a lexical
    closure is the object returned by FUNCTION, that is, a function which,
    when invoked, obeys the rules for lexical scoping.

    The problem with this definition is that it makes it difficult to explain
    why the thing referred to is called a closure.  It's hard to relate the
    definition even vaguely to the set-theoretic notion of a closure, because
    it doesn't describe a set, so one can't explain the term as coming from
    the notion of `closing over' a set of bindings...

Oops, I take it all back.  I dug out my copy of Kleene and found that I
really wanted the predicate calculus notion of closure, not the set-theoretic
notion of closure.

∂29-Jan-85  1328	GRISS%hp-hulk.csnet@csnet-relay.arpa 	Re: how to document yellow page entries, belated discussion by REM 
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 29 Jan 85  13:28:02 PST
Received: from hplabs by csnet-relay.csnet id ah07582; 29 Jan 85 16:13 EST
Received: by HP-VENUS id AA16614; Mon, 28 Jan 85 07:15:34 pst
Message-Id: <8501281515.AA16614@HP-VENUS>
Date: Sun 27 Jan 85 19:29:41-PST
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Re: how to document yellow page entries, belated discussion by REM
To: Fahlman, REM%IMSSS@su-score.ARPA
Cc: COMMON-LISP@su-ai.ARPA, GRISS@hplabs.CSNET
In-Reply-To: Message from ""Scott E. Fahlman" <Fahlman@CMU-CS-C@HP-VENUS>" of Sat 26 Jan 85 23:26:30-PST
Source-Info:  From (or Sender) name not authenticated.

I agree with Scott. We use (as Bob Kessler pointed out) a comment convention.

Most of the time its ignored, but certain programs extract the stuff
as desired.

M
-------

∂03-Feb-85  0833	RAM@CMU-CS-C.ARPA 	Defstruct copiers and included structures
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Feb 85  08:33:39 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Sun 3 Feb 85 11:35:09-EST
Date: Sun, 3 Feb 1985  11:35 EST
Message-ID: <RAM.12084757395.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   common-lisp@SU-AI.ARPA
Subject: Defstruct copiers and included structures


Query: Does a copier for a structure correctly copy all structures
       which include that structure?

    I would argue that it should, both on esthetic and practical
grounds.  Since the including structure is a subtype of the included
structure, it should inherit all operations on that structure.  It
would also be useful to be able count on this behavior.  It turns out
that our implementation already does this, since it uses the same
copier function for all structures.

  Rob

∂04-Feb-85  1248	Moon@SCRC-STONY-BROOK.ARPA 	FLET and the INLINE declaration 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Feb 85  12:48:07 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 171683; Mon 4-Feb-85 15:44:04-EST
Date: Mon, 4 Feb 85 15:41 EST
From: David A. Moon <Moon@SCRC-QUABBIN.ARPA>
Subject: FLET and the INLINE declaration
To: Common-Lisp@SU-AI.ARPA
Message-ID: <850204154157.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 4 Feb 85 14:20 EST
    From: Charles Hornig <Hornig@SCRC-STONY-BROOK>

    ....This is a good idea except for one problem: where do you put the
    declaration?  FLET and LABELS do not allow you to put declarations
    before their bodies.  Perhaps this is a language bug.

    (flet ((plus1 (x) (1+ x)))
       (declare (inline plus1))	 ;; This declare is illegal in the CLM
       (list (plus1 1) (plus1 2)))

You have to say

    (flet ((plus1 (x) (1+ x)))
       (locally (declare (inline plus1))
	 (list (plus1 1) (plus1 2))))

I think this is a language bug and declarations, other than declarations
of variable bindings, should have been allowed at this position in FLET,
LABELS, and MACROLET.  Does anyone else have an opinion?

∂06-Feb-85  0950	brown@DEC-HUDSON 	Clearly non-controversial  
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 6 Feb 85  09:49:38 PST
Date: Wed, 06 Feb 85 12:52:15 EST
From: brown@DEC-HUDSON
Subject: Clearly non-controversial
To: common-lisp@su-ai

Here are several clearly non-controversial functions which I think
should be considered for inclusion in the language.
   

 USER-NAME						[function]
  A string is returned that identifies the current user of the
  Common Lisp system.  If a reasonable name cannot be determined,
  NIL is returned (or an empty-string?).

(It has been suggested that this should be called something like
USER-INFORMATION and take a lot of keyword arguments.)
   
 DELETE-SETF-METHOD access-fn				[function]
  Removes the update form associated with the symbol access-fn.
  The access function can no longer be used as generalized
  variable.

 HASH-TABLE-REHASH-SIZE  hash-table			[function]
 HASH-TABLE-REHASH-TRESHOLD  hash-table			[function]
 HASH-TABLE-SIZE  hash-table				[function]
 HASH-TABLE-TEST  hash-table				[function]
  These functions return the values that were specified when
  the hash-table was created.

 DELETE-PACKAGE	package					[function]
  Uninterns all the symbols interned in package, deletes the package,
  and unuses all packages it uses.  An error is signaled if the 
  package is used by any other package.

 UNCOMPILE symbol					[function]
  Restores the interpreted function definition of a symbol if
  the symbol's function definition was compiled by the COMPILE
  function.

 COMPILEDP symbol					[function]
  Returns NIL if the symbol does not have a compiled function
  definition.  Returns T if the symbol has a compiled function
  definition which was not compiled by the COMPILE function;
  for example, loaded from a compiled file.  Returns the
  interpreted function definition if the function was compiled
  by the COMPILE function.
      
(This list used to contain TERMINALP which returned T if its
 argument (string, pathname, etc.) was an "interactive terminal".
 I think this function would be useful, but decided I was unable
 to define what a terminal is, so removed it.)

-Gary Brown

∂06-Feb-85  1847	RAM@CMU-CS-C.ARPA 	of course you don't copy everything that includes that structure!!
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 Feb 85  18:46:50 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 6 Feb 85 21:48:04-EST
Date: Wed, 6 Feb 1985  21:47 EST
Message-ID: <RAM.12085655396.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   REM@MIT-MC.ARPA
cc:   common-lisp@SU-AI.ARPA
Subject: of course you don't copy everything that includes that structure!!
In-reply-to: Msg of 1985 Feb 06 17:41:06 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.SU.EDU>


    Date: 1985 February 06 17:41:06 PST (=GMT-8hr)
    From: Robert Elton Maas <REM at IMSSS.SU.EDU>
    To:   RAM at CMU-CS-C
    Re:   of course you don't copy everything that includes that structure!!

    > Query: Does a copier for a structure correctly copy all structures
    >        which include that structure?

    ABSOLUTELY NOT!!!!
    It's possible you had a typographic error there and said the exact
    opposite of what you meant, but I'll assume no typo and answer exactly
    what you said.

I think that you totally spaced what I was talking about, which was
structures and copiers as created by defstruct, with include meaning
defstruct inclusion.  Looking back at my message, I noticed that I
only mentioned Defstruct in the subject...

I have had some second-thoughts thought about the issue some since I
sent the message, but I still don't think that the answer is blatently
obvious.

The thing that I realized is that if the canonical implementation of
defstruct copiers is the one that we have chosen, in which there is
basically one generic defstruct copier function that copies all types
of structures, then it is kind of silly to have distinct named copier
functions for each structure type, since there could just as easily be
one Copy-Structure function.

Presumably the rationale behind having distinct copier functions is
that they could be more efficient, since they could be specialized for
the particular structure that they copy.  The problem is that any
likely scheme for significantly specializing the copier function will
probably not have the property that subtypes (by inclusion) of that
structure are correctly copied.

  Rob

∂07-Feb-85  2224	WHOLEY@CMU-CS-C.ARPA 	Clearly non-controversial   
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 7 Feb 85  22:24:46 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Fri 8 Feb 85 01:26:21-EST
Date: Fri, 8 Feb 1985  01:26 EST
Message-ID: <WHOLEY.12085957297.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To:   Common-Lisp@SU-AI.ARPA
Subject: Clearly non-controversial

    From: brown at DEC-HUDSON
    Re:   Clearly non-controversial

     DELETE-SETF-METHOD access-fn				[function]
      Removes the update form associated with the symbol access-fn.
      The access function can no longer be used as generalized
      variable.

How about UN-DEFTYPE and UN-DEFSTRUCT and UN-DEFCONSTANT and so on?  All of
these would be useful (for the same reason as DELETE-SETF-METHOD is useful --
one is really screwed if there's no way to undo a wrong one).  Coming up with a
list of all such things is a non-trivial task, and including one without all
others could be silly.  On the other hand, adding a dozen undo functions to the
language, however simple, might stir up some controversy.  I don't know the
right way to go here.  Perhaps implementors might include information on how to
undo these things in their red pages.  Undoing functions could conceivably be
treated as "user interface", since they aren't likely to appear in programs.

     HASH-TABLE-REHASH-SIZE  hash-table			[function]
     HASH-TABLE-REHASH-TRESHOLD  hash-table			[function]
     HASH-TABLE-SIZE  hash-table				[function]
     HASH-TABLE-TEST  hash-table				[function]
      These functions return the values that were specified when
      the hash-table was created.

When it was created? How about the current (possibly after rehashing) values?
Was your above description a thinko?  Could the rehash parameters be set with
SETF?  [Rambling ideas: That could be useful for growing hash tables in some
non-linear, non-exponential fashion.  Maybe :REHASH-SIZE could also be a
function, in which case it takes an integer (the old size) and returns an
integer (the new size).  :REHASH-THRESHOLD could likewise be a two-arg
predicate.  This would let you rehash hash tables every Tuesday, for example.]

     DELETE-PACKAGE	package					[function]
      Uninterns all the symbols interned in package, deletes the package,
      and unuses all packages it uses.  An error is signaled if the 
      package is used by any other package.

Yes, that's definitely a good thing to have.  Hint for programmers living 
without this: use Rename-Package to get rid of the bogus package.
          
    (This list used to contain TERMINALP which returned T if its
     argument (string, pathname, etc.) was an "interactive terminal".
     I think this function would be useful, but decided I was unable
     to define what a terminal is, so removed it.)

I don't think all implementations could accurately answer the "is this stream
backed by a user" question.  I guess a second value indicating whether or not
the answer was determined for sure would have to be returned.  What would you
use such a thing for?  I can only think of things that aren't really good
things for supposedly portable programs to do.  In line with the other
stream type predicate functions (e.g. Input-Stream-P), perhaps the name could
be Interactive-Stream-P?

--Skef

∂07-Feb-85  2330	WHOLEY@CMU-CS-C.ARPA 	Clearly non-controversial   
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 7 Feb 85  22:24:46 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Fri 8 Feb 85 01:26:21-EST
Date: Fri, 8 Feb 1985  01:26 EST
Message-ID: <WHOLEY.12085957297.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To:   Common-Lisp@SU-AI.ARPA
Subject: Clearly non-controversial

    From: brown at DEC-HUDSON
    Re:   Clearly non-controversial

     DELETE-SETF-METHOD access-fn				[function]
      Removes the update form associated with the symbol access-fn.
      The access function can no longer be used as generalized
      variable.

How about UN-DEFTYPE and UN-DEFSTRUCT and UN-DEFCONSTANT and so on?  All of
these would be useful (for the same reason as DELETE-SETF-METHOD is useful --
one is really screwed if there's no way to undo a wrong one).  Coming up with a
list of all such things is a non-trivial task, and including one without all
others could be silly.  On the other hand, adding a dozen undo functions to the
language, however simple, might stir up some controversy.  I don't know the
right way to go here.  Perhaps implementors might include information on how to
undo these things in their red pages.  Undoing functions could conceivably be
treated as "user interface", since they aren't likely to appear in programs.

     HASH-TABLE-REHASH-SIZE  hash-table			[function]
     HASH-TABLE-REHASH-TRESHOLD  hash-table			[function]
     HASH-TABLE-SIZE  hash-table				[function]
     HASH-TABLE-TEST  hash-table				[function]
      These functions return the values that were specified when
      the hash-table was created.

When it was created? How about the current (possibly after rehashing) values?
Was your above description a thinko?  Could the rehash parameters be set with
SETF?  [Rambling ideas: That could be useful for growing hash tables in some
non-linear, non-exponential fashion.  Maybe :REHASH-SIZE could also be a
function, in which case it takes an integer (the old size) and returns an
integer (the new size).  :REHASH-THRESHOLD could likewise be a two-arg
predicate.  This would let you rehash hash tables every Tuesday, for example.]

     DELETE-PACKAGE	package					[function]
      Uninterns all the symbols interned in package, deletes the package,
      and unuses all packages it uses.  An error is signaled if the 
      package is used by any other package.

Yes, that's definitely a good thing to have.  Hint for programmers living 
without this: use Rename-Package to get rid of the bogus package.
          
    (This list used to contain TERMINALP which returned T if its
     argument (string, pathname, etc.) was an "interactive terminal".
     I think this function would be useful, but decided I was unable
     to define what a terminal is, so removed it.)

I don't think all implementations could accurately answer the "is this stream
backed by a user" question.  I guess a second value indicating whether or not
the answer was determined for sure would have to be returned.  What would you
use such a thing for?  I can only think of things that aren't really good
things for supposedly portable programs to do.  In line with the other
stream type predicate functions (e.g. Input-Stream-P), perhaps the name could
be Interactive-Stream-P?

--Skef

∂12-Feb-85  1931	JLW  	Your non-controversial suggestions for function names 
To:   brown@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA  

Eric Benson and I quite independently came up with the need for
DELETE-PACKAGE last week;  oddly enough, we even chose the same
name!

The 3600 documentation has 'pkg-kill'  to de-register a package
(its name and all nicknames) and to flush the respective 'use'
lists; but we rather agree that DELETE-PACKAGE ought also to
make a pass over the atoms in the package to insure that any
who are interned with that packge as 'home' have their symbol-package
slot smashed [i.e., at least a subset of what unintern would do].

-- JonL --

∂14-Feb-85  1140	KMP@SCRC-STONY-BROOK.ARPA 	Not clearly non-controversial    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 14 Feb 85  11:39:40 PST
Received: from SCRC-MISSISSIPPI by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 178344; Thu 14-Feb-85 14:41:19-EST
Date: Thu, 14 Feb 85 14:41 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Not clearly non-controversial
To: brown@DEC-HUDSON.ARPA, COMMON-LISP@SU-AI.ARPA
In-Reply-To: The message of 6 Feb 85 12:52-EST from brown at DEC-HUDSON
Message-ID: <850214144132.2.KMP@MISSISSIPPI.SCRC.Symbolics.COM>

    Date: Wed, 06 Feb 85 12:52:15 EST
    From: brown@DEC-HUDSON
    Re:   Clearly non-controversial

     USER-NAME						[function]
      A string is returned that identifies the current user of the
      Common Lisp system.  If a reasonable name cannot be determined,
      NIL is returned (or an empty-string?).

    (It has been suggested that this should be called something like
    USER-INFORMATION and take a lot of keyword arguments.)
   
Not just user information, but system information. eg, on the LispM it
means little (even in Common Lisp) to know the guy's name is "Joe" unless
you know what machine or site that name is relative to. At the least, 
you'd need a way of getting the machine name, too. The USER-INFORMATION
thing sounds a little more plausible, but I'd prefer to see a specific
suggestion before saying go ahead.

     DELETE-SETF-METHOD access-fn				[function]
      Removes the update form associated with the symbol access-fn.
      The access function can no longer be used as generalized
      variable.

I dislike the use of the morpheme "DELETE-" in this context.  The Lisp 
Machine uses "UN" tacked onto the defining form name, which is easy
to remember and doesn't feel like it wants a second argument of a list
to delete the thing from. Perhaps we should have a lot of UNthings.
Perhaps we should have a special form UNDO which works like SETF
but undoes things. eg, (UNDO (DEFINE-SETF-METHOD ...)) would undo a
SETF method. (UNDO (DEFUN FOO (X) ...)) would undo a DEFUN. We'd have
to define clearly the effect of:
 (DEFUN F (X) X) (DEFUN F (X) (1+ X)) (UNDO (DEFUN F (X) (1+ X)))
If it wasn't to make F be an identity function again, then UNDO might
be a slightly misleading name. Anyway, I'd rather address this general
problem than add a ton of special case DELETE-mumble or UNmumble 
functions.

     COMPILEDP symbol					[function]
      Returns NIL if the symbol does not have a compiled function
      definition.  Returns T if the symbol has a compiled function
      definition which was not compiled by the COMPILE function;
      for example, loaded from a compiled file.  Returns the
      interpreted function definition if the function was compiled
      by the COMPILE function.
      
What about 

  (DEFUN FOO (X) X)
  (COMPILE 'FOO)
  (DEFUN F ()
    (FLET ((FOO (Y) (1+ Y)))
      (COMPILEDP 'FOO)))

I would feel better if any COMPILEDP thing took an argument of 
an object and told you if it were compiled. So you could write
(COMPILEDP #'symbol) instead.

Personally, I wish COMPILE had been defined to just return its result
rather than to also install it because it propagates the same kind of
confusion. But I guess it's a little late to worry about that now.
-kmp

∂18-Feb-85  1028	HEDRICK@RUTGERS.ARPA 	doc strings  
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 18 Feb 85  10:28:36 PST
Date: 18 Feb 85 13:30:14 EST
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: doc strings
To: common-lisp@SU-AI.ARPA

Does anybody happen to have a set of documentation strings for
Common Lisp?  The Spice Lisp code that we are using does have it,
but for various reasons it would be mildly helpful for us to have
a separate file that has all the doc strings.
-------

∂20-Feb-85  0216	rwg@RUSSIAN.SPA.Symbolics.COM 	gcd of rationals--flame added in proof 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Feb 85  02:16:20 PST
Received: from SPA-RUSSIAN by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 181670; Wed 20-Feb-85 04:52:21-EST
Received: from SPA-LOS-TRANCOS by SPA-RUSSIAN via CHAOS with CHAOS-MAIL id 102914; Wed 20-Feb-85 01:50:12-PST
Date: Wed, 20 Feb 85 01:50 PST
From: Bill Gosper <rwg@RUSSIAN.SPA.Symbolics.COM>
Subject: gcd of rationals--flame added in proof
To: ALAN@SCRC-STONY-BROOK.ARPA, fateman%ucbdali@UCB-VAX.ARPA
cc: rem@MIT-MC.ARPA, numerics@SCRC-STONY-BROOK.ARPA,
    common-lisp@SU-AI.ARPA
In-Reply-To: <850129023720.8.RWG@RUSSIAN.SPA.Symbolics.COM>
Message-ID: <850220015044.3.RWG@LOS-TRANCOS.SPA.Symbolics.COM>

    Date: Tue, 29 Jan 85 02:37 PST
    From: Bill Gosper <rwg@RUSSIAN.SPA.Symbolics.COM>
	Date: Saturday, 19 January 1985  01:03-EST
	From: Alan Bawden <ALAN at SCRC-TENEX>
	    Date: Friday, 28 December 1984, 01:28-PST
	    From: Bill Gosper <rwg at SPA-NIMBUS>
		Date: Wednesday, 19 December 1984, 23:45-EST
		From: David C. Plummer in disguise <DCP at SCRC-QUABBIN>
		    [(GCD 1\4 1\3) errs.]
		    . . .

		    BTW, the correct answer is 1\12.

		Not as far as ZL is concerned.  Nor CL for that matter.

	    Ouch!  They must have been jet-lagged at those CL meetings.  As
	    Schroeppel pointed out several millenia back,

	    (GCD A\B C\D) = (GCD A C)/(LCM B D),

	    assuming args are in lowest terms.  MACSYMA has long known this.

	You know Gosper, I had always assumed that people who proposed to extend
	GCD to the rationals were just confused about just what GCD really was, so
	I was quite surprised to hear that this was an idea endorsed by Schroeppel.
	So I thought about it for a while...

	In what sense must the GCD of 1/3 and 1/4 be 1/12?  Suppose I pick some
	subring of Q that contains both 1/3 and 1/4 and I look at the ideal
	generated by 1/3 and 1/4.  Certainly that ideal is the same as the ideal
	generated by 1/12, and in general the formula you give above will always
	yeild such a generator, but there are many other elements in the ring that
	generate that ideal.  In fact, since 1/12 is a unit in any subring of Q,
	that ideal must be generated by 1, so why not say GCD(1/3,1/4)=1?  What is
	the additional constraint you impose that requires 1/12?

	Well, suppose that instead of thinking about GCD as defined in terms of
	generators of ideals in subrings of Q, we think about GCD as defined in
	terms of generators of Z-modules contained in Q.  In that case, the formula
	above gives the unique (modulo sign) generator of the module generated by
	the arguments to GCD.  But that seems somewhat arbitrary; suppose I was
	working with some ring other than Z, call it A, and I wanted to play with
	A-modules contained in Q?  No problem!  Although the formula can't always
	give you a unique generator, it will give you -one- of the generators,
	which is certainly the best you can ask for.

	Summary:  I'm convinced.  This really is the right way to extend GCD to the
	rational numbers if you are going to do it at all.  (Since my suggestions
	that GCD, NUMERATOR and DENOMINATOR be extended in the -only- possible way to
	the complex integers were ignored, I have little hope that Common Lisp will
	adopt the idea, however.)

	    But the absoLULU is further down page 202 of the CL book:

	    "Mathematically, (lcm) should return infinity."  This is so wildly
	    absurd that I can't even guess the fallacy that led to it.  It should
	    simply be 1.

	It is clearly a result of taking the identity
	 (LCM ...) = (/ (ABS (* ...)) (GCD ...))
	too seriously.

    Hell, that's only valid for exactly TWO arguments!

(+ A B) is (+ (MAX A B) (MIN A B)), but
(+ A B C) isn't (+ (MAX A B C) (MIN A B C)) and 
(+ A) isn't (+ (MAX A) (MIN A)) !

	From: fateman@ucbdali (Richard Fateman)
	To: rwg@NIMBUS.SPA.Symbolics
	Subject: Re:  Irrational GCD

	The notion of a GCD over fractions is probably not such a great thing to
	put in as a primitive in a programming language. I guess it shows how advanced
	Common Lisp is..  The usual kind of programming language has
	trouble with REMAINDER.

	It was a real pain to get straight in macsyma, as I recall.  If you worry
	about unique factorization domains, I believe fields (e.g. rational numbers)
	don't qualify for the GCD operation.  Which means you can probably extend
	the operation any way you please so long as it coincides on the integers...
	e.g. gcd (a\b,c\d) == if b=d=1 then gcd(a,c) else 1.

    Barf, what is all this prissy pedantry?  Groups, modules, rings, ufds, patent-
    office algebra.  Barf!

    GCD once stood for Greatest Common Divisor, an English Phrase.  What is the
    greatest rational that produces and integer when you divide it into 1/3 and
    1/4?  Answer:  1/12.

    Another view.  Extend unique prime factorization to rationals.  Then you got
    p1↑a1 p2↑a2 . . . just like with integers, except now the ai can be
    negative.  GCD is still prod pi↑min(ai of each arg), and LCM is still max.

Even (DEFUN EGCD (A B) (IF (ZEROP B) (ABS A) (EGCD B (\ A B)))) does the right
thing with rationals!

Then you can (DEFUN ELCM (&REST NUMS) (CL:// (APPLY #'EGCD (MAPCAR #'CL:// NUMS)))),
i.e., reciprocate the GCD of the reciprocals.
(Like MIN is negative of MAX of negatives.)

Why isn't there a CL destructive MAP on sequences??

∂21-Feb-85  1334	godot!gls@AQUINAS 	gcd of rationals--flame added in proof   
Received: from CCA-UNIX.ARPA by SU-AI.ARPA with TCP; 21 Feb 85  13:33:40 PST
Received: by cca-unix.ARPA (4.12/4.7)
	id AA10420; Thu, 21 Feb 85 16:29:22 est
Message-Id: <8502212129.AA10420@cca-unix.ARPA>
Received: by godot with CHAOS id AA23697; Thu, 21 Feb 85 16:23:58 est
Date: Thursday, 21 February 1985, 16:25-EST
From: Guy Steele <godot!gls@AQUINAS>
Subject: gcd of rationals--flame added in proof
To: rwg%RUSSIAN.SPA.Symbolics.COM@GODOT, ALAN%SCRC-STONY-BROOK.ARPA@GODOT,
        fateman%ucbdali%UCB-VAX.ARPA@GODOT
Cc: rem%MIT-MC.ARPA@GODOT, numerics%SCRC-STONY-BROOK.ARPA@GODOT,
        common-lisp%SU-AI.ARPA@GODOT, gls@AQUINAS
In-Reply-To: <850220015044.3.RWG@LOS-TRANCOS.SPA.Symbolics.COM>

The claim in the manual that (lcm) should be infinity is outright
wrong, as REM has already pointed out to me.  Probably I was indeed
misled by the formula (/ (* x y) (gcd x y)); I cannot remember.
However, the statement is certainly my fault.  I'm sorry.  Maybe
in the next version of Common Lisp we can safely define (lcm) => 1,
as it will be a compatible extension.

∂26-Feb-85  0909	hpfclp!paul%hplabs.csnet@csnet-relay.arpa 	truncate/round/floor/ceiling functions    
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 26 Feb 85  09:09:15 PST
Received: from hplabs by csnet-relay.csnet id au20234; 26 Feb 85 11:52 EST
Date: Mon, 25 Feb 85 13:25:26 pst
From: hpfclp!paul%hplabs.csnet@csnet-relay.arpa
MMDF-Warning:  Parse error in preceding line at CSNET-RELAY.ARPA
Received: by HP-VENUS id AA02146; Mon, 25 Feb 85 13:25:26 pst
Message-Id: <8502252125.AA02146@HP-VENUS>
To: hplabs!common-lisp@su-ai.ARPA
Subject: truncate/round/floor/ceiling functions
Source-Info:  From (or Sender) name not authenticated.


I  think  that I may  have  found  an  inconsistent  definition  for the
functions floor/round/ceiling and trucate.

This inconsistency  occurs when there are 2 arguments.  For example, let
us look at `(truncate 10.0 4.0)'.

1).  We see that  (truncate  10.0 4.0) is  defined to be  equivalent  to
    (truncate (/ 10.0 4.0)) = (truncate 2.5), which yields (2 0.5).

2.) However, applying the sentence (from pg 216 in the Aluminum Edition)

	"If any of  these  functions  is given 2  arguments  x and y and
	 produces results q and r, then q*y + r = x."

    yields, for  x=10.0 and y= 4.0, q=2 and r=2.0, or a result of 
    (2.0 2.0).

We then have 2 different results for `truncate 10.0 4.0', depending upon
whether one does the division or not.

How is this resolved?  Any clarifications would be appreciated.

Paul Beiser
Hewlett-Packard   
Ft. Collins, Colorado
uucp:   ...{ihnp4,hplabs}!hpfcla!paul
arpa:   "hpfclp!paul%hplabs.csnet"@csnet-relay


∂26-Feb-85  1648	RAM@CMU-CS-C.ARPA 	truncate/round/floor/ceiling functions   
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 26 Feb 85  16:48:49 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Tue 26 Feb 85 19:50:19-EST
Date: Tue, 26 Feb 1985  19:50 EST
Message-ID: <RAM.12090876859.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   hpfclp!paul%hplabs.csnet@CSNET-RELAY.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: truncate/round/floor/ceiling functions
In-reply-to: Msg of 25 Feb 1985  16:25-EST from hpfclp!paul%hplabs.csnet at csnet-relay.arpa


    I had already pointed this out in a previous message on the
mailing list.  The correct interpretation is that the second value is
always the remainder.  The description of the meaning of the second
argument is only correct if one disregards the second value.

  Rob

∂04-Mar-85  0934	RAM@CMU-CS-C.ARPA 	do-xxx-symbols  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Mar 85  09:34:29 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Mon 4 Mar 85 12:33:31-EST
Date: Mon, 4 Mar 1985  12:33 EST
Message-ID: <RAM.12092370210.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   Charles Hedrick <HEDRICK@RUTGERS.ARPA>
cc:   common-lisp@SU-AI.ARPA
Subject: do-xxx-symbols
In-reply-to: Msg of 3 Mar 1985  21:43-EST from Charles Hedrick <HEDRICK at RUTGERS.ARPA>


    Date: Sunday, 3 March 1985  21:43-EST
    From: Charles Hedrick <HEDRICK at RUTGERS.ARPA>
    To:   ram
    Re:   do-xxx-symbols

    The definition of DO-SYMBOLS says that it iterates over all symbols
    accessible in the specified package, and that it does each once.  The
    term "accessible in" is ambiguous. The code I have from Spice simply
    iterates over the externals and internals of that package. One could
    also interpret that as including packages used by the specified package.
    In that case, some interesting code would be needed to prevent a given
    symbol from being used more than once, since if IMPORT was done, a
    symbol could appear in several packages.  Does Spice still make the
    interpretation that DO-SYMBOLS looks only at the package specified?

    Similarly, APROPOS talks about symbols "available in" a given  package.
    The wording talks about inheritance paths, so the implication seems
    fairly clear that APROPOS does look at used packages.

Even after staring at the manual, I was unable to determine what the
intent was.  It is unfortunate that after spending N pages developing
the theory and terminology, the actual function description blows it.
The two possibilities are to iterate over all symbols available in the
package, or only over those present in the package.

If Do-Symbols is supposed to iterate over all symbols available in the
package, then it is clearly impractical to guarantee that each symbol
is only done once, so there probably should be a caveat similar to
that for Do-All-Symbols in the Do-Symbols description.  I think that
with some imagination, one could read the statement that each symbol
is done once to mean that each symbol is done at least once.

There is another problem with this interpretation, though.  Before you
can iterate over any symbol for a used package, you must check to see
if the symbol is shadowed in the inheriting package.  This could cause
a substantial performance penalty in Do-Symbols, since it would be
forced to do a hashtable lookup for each inherited symbol iterated
over.  This means that doing an apropos in any package using the lisp
package would require doing 1000 hashtable lookups.

On the other hand, the word accessible could be replaced with
present, and everyone would be happy.  Apropos would have to be
changed to do a Do-External-Symbols on each used package, and would
ignore details such as shadowed symbols.

  Rob

∂04-Mar-85  1048	FAHLMAN@CMU-CS-C.ARPA 	do-xxx-symbols   
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Mar 85  10:47:57 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 4 Mar 85 13:46:53-EST
Date: Mon, 4 Mar 1985  13:46 EST
Message-ID: <FAHLMAN.12092383554.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Cc:   common-lisp@SU-AI.ARPA, Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: do-xxx-symbols
In-reply-to: Msg of 4 Mar 1985  12:33-EST from Rob MacLachlan <RAM>


I don't think that the term "accessible in" is ambiguous, given the
definition on page 172.  Where is the ambiguity?  So DO-SYMBOLS wants to
iterate over all of the internal and external symbols directly present
in the current package, and also those symbols that are present because
they are external in the packages used by the specified package.

I don't think we need to worry about eliminating duplicates that result
from explicit calls to IMPORT.  That would entail a lot of extra
bookkeeping and would usually not be important.  The business about
shadowing is a bit more complex.  Technically, a symbol shadowed in
package P is not accessible in P, but again a lot of bookkeeping would
be required to eliminate these.  Unless someone has a clever idea for
how to do this efficiently, we should probably revise the description of
DO-SYMBOLS to allow it to ignore this problem.  In the reare case where
a user really cares, he can check for shadowed symbols himself.  In any
event, the manual should be clarified on these two points.

In the description of APROPOS, the term "available in" is supposed to be
"accessible in", so the rules for DO-SYMBOLS should apply if the package
is specified, and DO-ALL-SYMBOLS if all packages are to be searched.

By the way, several groups have decided that the default for no package
specified is bogus, and that if no package is specified the user
probably should be given all symbols ACCESSIBLE IN the current package.
An argument of T could mean that you really do want to see ALL the
symbols, including internal compiler symbols, etc.  Opinions?

-- Scott

∂04-Mar-85  1606	HEDRICK@RUTGERS.ARPA 	Re: do-xxx-symbols
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 4 Mar 85  16:06:25 PST
Date: 4 Mar 85 19:05:43 EST
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: do-xxx-symbols
To: RAM@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message from "Rob MacLachlan <RAM@CMU-CS-C.ARPA>" of 4 Mar 85 12:33:00 EST

My current implementation is the following:
  DO-ALL-SYMBOLS - all symbols in all packages
  DO-MOST-SYMBOLS - all symbols in all packages except not internals in
	LISP or COMPILER (which I claim the user is not interested in
	seeing in many cases)
  DO-SYMBOLS - all symbols in the package mentioned
  DO-ACCESSIBLE-SYMBOLS - all symbols in the package, and all externals
	in used packages.  No attempt to remove shadowed symbols.
  APROPOS
   if package is omitted or NIL: DO-MOST-SYMBOLS
   if package is T:  DO-ALL-SYMBOLS
   otherwise: DO-ACCESSIBLE-SYMBOLS
-------

∂04-Mar-85  1851	HEDRICK@RUTGERS.ARPA 	Re: do-xxx-symbols
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 4 Mar 85  18:50:55 PST
Date: 4 Mar 85 21:50:06 EST
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: do-xxx-symbols
To: Fahlman@CMU-CS-C.ARPA
cc: RAM@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: Message from ""Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>" of 4 Mar 85 13:46:00 EST

There are at least four reasons why the description of DO-SYMBOLS does
not appear to include symbols in used packages:

1) "do-symbols provides straightforward iteration over the symbols
of a package".  Searching all the used packages is not straightforward
iteration over the package.

2) There is an implication that UNINTERN can be called to remove symbols
from the package.  UNINTERN'ing a symbol in a used package does not
exactly remove it from the package under discussion.

3) It is said that every symbol is processed once.  In DO-ALL-SYMBOLS
there is an explicit warning that symbols may occur more than once. The
implication is that this is not true for DO-SYMBOLS.  If DO-SYMBOLS
was supposed to look at used packages, then the same warning would
apply to it.

4) DO-EXTERNAL-SYMBOLS says that it is like DO-SYMBOLS, but only
the external symbols of the specified package are used.  The wording
of DO-EXTERNAL-SYMBOLS seems to imply even more clearly that only
the specified package is scanned, not any used packages.  It also seems
to imply that DO-SYMBOLS does the same thing, but for both internal and
external symbols.

Can we get an authoritative statement about what is covered by
DO-SYMBOLS and DO-EXTERNAL-SYMBOLS, and about whether duplicates and
shadowed symbols should be removed?  I think this question is
separate from the APROPOS question.  APROPOS with no argument is
documented as using DO-ALL-SYMBOLS.  But with an argument it is not
said to use DO-SYMBOLS.  So it would be perfectly acceptable to
say that DO-SYMBOLS looks only at the symbols in a particular 
package, whereas APROPOS following the used chain.  (Indeed that is
what I have done for the moment.)
-------

∂04-Mar-85  2026	FAHLMAN@CMU-CS-C.ARPA 	do-xxx-symbols   
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Mar 85  20:25:46 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 4 Mar 85 23:24:38-EST
Date: Mon, 4 Mar 1985  23:24 EST
Message-ID: <FAHLMAN.12092488741.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: do-xxx-symbols
In-reply-to: Msg of 4 Mar 1985  21:50-EST from Charles Hedrick <HEDRICK at RUTGERS.ARPA>


    Can we get an authoritative statement about what is covered by
    DO-SYMBOLS and DO-EXTERNAL-SYMBOLS, and about whether duplicates and
    shadowed symbols should be removed?

Well, I think that the machinery for issuing authoritative statements is
pretty rusty right now.  I hope that we will soon have some sort of duly
constituted authority, but right now all we have is the ad hoc executive
committee of which I am the ad hoc chairman.

Hedrick's note points out that the description in the manual is
ambiguous at best.  OK.  I wrote most of that (with input from Moon and
Steele, among others) and I'm sure that DO-SYMBOLS was meant to include
symbols inherited from used packages.  It never occurred to me that
explicit IMPORT statements could set up a situation in which a symbol
might show up twice unless you go to a lot of trouble to prevent this.
I also didn't think about shadowed symbols.

In my earlier note, I sent out my view of how to patch the existing
description.  This is my view of "how it ought to be" rather than "what
the manual says".  Does anyone object to adopting this as the "official"
interpretation?  The only thing I'm uneasy about is letting DO-SYMBOLS
generate shadowed symbols, but I don't see any good alternative.

-- Scott

∂04-Mar-85  2036	HEDRICK@RUTGERS.ARPA 	Re: do-xxx-symbols
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 4 Mar 85  20:36:18 PST
Date: 4 Mar 85 23:34:48 EST
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: do-xxx-symbols
To: Fahlman@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message from ""Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>" of 4 Mar 85 23:24:00 EST

I had forgotten that you wrote the chapter.  I think that for the
author of a section to say "this is what I meant" is as authoritative
as we can reasonably expect.  The only way I can see to guarantee only
one occurence, and no shadowed symbols is to hash each symbol before
passing it to the user.  We did that in one implementation.  It isn't
that horrible. Hashes are supposed to be fast.  The idea is that you
keep a list of the packages that you have looked at so far.  For
each candidate symbol, you look it up in all the hash tables you have
already used.  If it is found, then you forget that symbol.  If you
search the packages in the right order, this should do the right thing.
The cost of this depends upon how expensive the contents of the loop
are.  It is going to perform N/2 hash lookups per symbol, where N is
the length of the use list.  I conjecture that this will be on the
order of 3.  3 hash lookups isn't that much.  But I certainly won't
do it unless I am told to.  I can think of uses of both possible
semantics.  If you remove duplicates, it is useful for things like
APROPOS.  If you don't, it is useful for code that manipulates the
package system.  E.g. you might use it to look for duplicates,
shadowed symbols, etc.  So it is important to make sure we know
which thing is to be done.  Don't say something like: well, we should
really only show him the symbol once, but some implementations may
not want to go to that work, so it's OK to ignore the problem.
-------

∂05-Mar-85  1541	godot!gls@AQUINAS 	Complex arc tangent  
Received: from MIT-EDDIE.ARPA by SU-AI.ARPA with TCP; 5 Mar 85  15:41:02 PST
Received: by mit-eddie.ARPA (4.12/4.8)  id AA06352; Tue, 5 Mar 85 18:35:36 est
Message-Id: <8503052335.AA06352@mit-eddie.ARPA>
Received: by godot with CHAOS id AA07351; Tue, 5 Mar 85 18:19:29 est
Date: Tuesday, 5 March 1985, 18:20-EST
From: Guy Steele <godot!gls@AQUINAS>
Subject: Complex arc tangent
To: mit-eddie!common-lisp%sail.arpa@GODOT
Cc: gls@AQUINAS

I spoke with Paul Penfield yesterday, and he says that he now agrees
with Kahan on the treatment of the branch cut for complex arc tangent.
He proposes to write some sort of joint letter recommending to the APL
and Common Lisp communities that this Kahan's definition of the branch
cut be adopted.  This would mean a (small) change to Common Lisp if
we endorse it.  Then everyone who cares at all about complex functions
in IEEE arithmetic will agree on the branch cuts.  Are there any objections?
--Guy

∂07-Mar-85  1707	dzg@cmu-cs-spice.arpa 	file-length 
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 7 Mar 85  17:07:05 PST
Apparently-From: dzg@CMU-CS-SPICE
Date: Thu 07 Mar 85 17:26:25-EST
From: dzg@CMU-CS-SPICE
To: common-lisp@SU-AI.ARPA
Subject: file-length
Message-ID: <6590.167185583.dzg>

I don't remember this being discussed on this bboard, so here it goes...

I think the definition of (file-length) on page 425 of the aluminum edition
leaves something to be desired. In particular, I object to the first
sentence: "<file-stream> must be a stream that is open to a file."
This requirement was probably dictated by the desire to return the length
in exactly the same units that were used to create the file. Reasonable as
this seems, it presents a lot of problems.

For one thing, it always forces you to write something like
        (when probe-file FILE-NAME
          (with-open-file
            (little-dummy-stream FILE-NAME :direction :input)
              ... (file-length little-dummy-stream) ...
even when you don't want to read the file at all, but just see how big it
is.  This is not exactly clear, I think.

Things are a lot worse, though, when you move into a networking environment.
One such environment, which I will use as an example, is Spice.  Imagine
now you want to check the length of a remote file in Spice; imagine, say,
that you are worried about whether you'd be able to retrieve a huge
database file and fit in on your local disk.  The Spice networking stuff is
perfectly happy with a "length of remote file" request, and will tell you
you do not have room.  Imagine, though, that you wanted to do the same
thing from within Common Lisp.  Well, you have to play the little
(with-open-file ...) game.  BUT, in the Spice world (as in many, many other
worlds) this means you indeed want to read the file, all of it!  As a
result, the file is shipped over to your machine, taking 5 minutes if you
are lucky. And if you are unlucky, the file will overflow your paging space
(not your file-system space, obviously, because you are NOT retrieving the
file to the file system, by golly, just checking its size!).
All of this is complete nonsense, obviously, when you could have gotten the
same reply in a millisecond if you just didn't have to open the file.

I suppose one could expand on the idea of (open :direction :probe), but
this still seems artificial. Why not just say that file-length takes "a
filename or a stream that is open to a file", like file-write-date, and
maybe let you specify what units you want file-length to return?

∂07-Mar-85  1707	dzg@cmu-cs-spice.arpa 	file-length 
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 7 Mar 85  17:07:28 PST
Apparently-From: dzg@CMU-CS-SPICE
Date: Thu 07 Mar 85 17:26:25-EST
From: dzg@CMU-CS-SPICE
To: common-lisp@SU-AI.ARPA
Subject: file-length
Message-ID: <6590.167185583.dzg>

I don't remember this being discussed on this bboard, so here it goes...

I think the definition of (file-length) on page 425 of the aluminum edition
leaves something to be desired. In particular, I object to the first
sentence: "<file-stream> must be a stream that is open to a file."
This requirement was probably dictated by the desire to return the length
in exactly the same units that were used to create the file. Reasonable as
this seems, it presents a lot of problems.

For one thing, it always forces you to write something like
        (when probe-file FILE-NAME
          (with-open-file
            (little-dummy-stream FILE-NAME :direction :input)
              ... (file-length little-dummy-stream) ...
even when you don't want to read the file at all, but just see how big it
is.  This is not exactly clear, I think.

Things are a lot worse, though, when you move into a networking environment.
One such environment, which I will use as an example, is Spice.  Imagine
now you want to check the length of a remote file in Spice; imagine, say,
that you are worried about whether you'd be able to retrieve a huge
database file and fit in on your local disk.  The Spice networking stuff is
perfectly happy with a "length of remote file" request, and will tell you
you do not have room.  Imagine, though, that you wanted to do the same
thing from within Common Lisp.  Well, you have to play the little
(with-open-file ...) game.  BUT, in the Spice world (as in many, many other
worlds) this means you indeed want to read the file, all of it!  As a
result, the file is shipped over to your machine, taking 5 minutes if you
are lucky. And if you are unlucky, the file will overflow your paging space
(not your file-system space, obviously, because you are NOT retrieving the
file to the file system, by golly, just checking its size!).
All of this is complete nonsense, obviously, when you could have gotten the
same reply in a millisecond if you just didn't have to open the file.

I suppose one could expand on the idea of (open :direction :probe), but
this still seems artificial. Why not just say that file-length takes "a
filename or a stream that is open to a file", like file-write-date, and
maybe let you specify what units you want file-length to return?

∂07-Mar-85  1708	dzg@cmu-cs-spice.arpa 	file-length 
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 7 Mar 85  17:07:56 PST
Apparently-From: dzg@CMU-CS-SPICE
'common-lisp@SU-AI.ARPA' βDate: Thu 07 Mar 85 17:26:25-EST
From: dzg@CMU-CS-SPICE
To: common-lisp@SU-AI.ARPA
Subject: file-length
Message-ID: <6590.167185583.dzg>

I don't remember this being discussed on this bboard, so here it goes...

I think the definition of (file-length) on page 425 of the aluminum edition
leaves something to be desired. In particular, I object to the first
sentence: "<file-stream> must be a stream that is open to a file."
This requirement was probably dictated by the desire to return the length
in exactly the same units that were used to create the file. Reasonable as
this seems, it presents a lot of problems.

For one thing, it always forces you to write something like
        (when probe-file FILE-NAME
          (with-open-file
            (little-dummy-stream FILE-NAME :direction :input)
              ... (file-length little-dummy-stream) ...
even when you don't want to read the file at all, but just see how big it
is.  This is not exactly clear, I think.

Things are a lot worse, though, when you move into a networking environment.
One such environment, which I will use as an example, is Spice.  Imagine
now you want to check the length of a remote file in Spice; imagine, say,
that you are worried about whether you'd be able to retrieve a huge
database file and fit in on your local disk.  The Spice networking stuff is
perfectly happy with a "length of remote file" request, and will tell you
you do not have room.  Imagine, though, that you wanted to do the same
thing from within Common Lisp.  Well, you have to play the little
(with-open-file ...) game.  BUT, in the Spice world (as in many, many other
worlds) this means you indeed want to read the file, all of it!  As a
result, the file is shipped over to your machine, taking 5 minutes if you
are lucky. And if you are unlucky, the file will overflow your paging space
(not your file-system space, obviously, because you are NOT retrieving the
file to the file system, by golly, just checking its size!).
All of this is complete nonsense, obviously, when you could have gotten the
same reply in a millisecond if you just didn't have to open the file.

I suppose one could expand on the idea of (open :direction :probe), but
this still seems artificial. Why not just say that file-length takes "a
filename or a stream that is open to a file", like file-write-date, and
maybe let you specify what units you want file-length to return?

∂07-Mar-85  2026	FAHLMAN@CMU-CS-C.ARPA 	file-length 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 7 Mar 85  20:26:37 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 7 Mar 85 23:26:01-EST
Date: Thu, 7 Mar 1985  23:25 EST
Message-ID: <FAHLMAN.12093275415.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   dzg@CMU-CS-SPICE.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: file-length
In-reply-to: Msg of 7 Mar 1985  17:26-EST from dzg at CMU-CS-SPICE


Dario,

I dimly remember some discussion of this before, but I don't have time
right now to try to track this down in the archives at SAIL.

I think it was specified that the file had to be open in order for
File-Length to work because a number of operating systems can't do it
any other way, so in portable code you can only count on the open-stream
case.  There's no reason why non-brain-damaged systems like Spice could
not extend this call as you propose, or provide some alternative call
that as a non-standard extension.  (The latter would make it easier to
catch non-portable usage, but users would have to remember two different
calls that do roughly the same thing -- confusing at best.)

-- Scott

∂07-Mar-85  2112	KMP@SCRC-STONY-BROOK.ARPA 	FILE-LENGTH  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 7 Mar 85  21:12:17 PST
Received: from SCRC-RIO-DE-JANEIRO by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 192195; Fri 8-Mar-85 00:10:59-EST
Date: Fri, 8 Mar 85 00:11 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: FILE-LENGTH
To: Fahlman@CMU-CS-C.ARPA, dzg@CMU-CS-SPICE.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12093275415.BABYL@CMU-CS-C.ARPA>, 
             <6590.167185583.dzg>
Message-ID: <850308001150.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Thu 07 Mar 85 17:26:25-EST
    From: dzg@CMU-CS-SPICE

    ... For one thing, it always forces you to write something like
	    (when probe-file FILE-NAME
	      (with-open-file
		(little-dummy-stream FILE-NAME :direction :input)
		  ... (file-length little-dummy-stream) ...
    even when you don't want to read the file at all, but just see how big it
    is...

I agree this is lousy. I hate idiomatic usages like this. They're a pain
to read even when you recognize them and some people seem to have a talent
for picking ways to code the same idea in ways that are much less
intelligible than you could ever guessed could be devised...

Why not just let FILE-LENGTH take an optional ELEMENT-TYPE argument
to be used if the operation has to be simulated. If the file is already
open and is not of the given ELEMENT-TYPE, then signal an error if it's
not possible to convert from the given element type to the type the file
is open in. If the file is not open (ie, arg was a path instead of a stream),
then if the operating system primitively supports a file-length operation 
on closed files and the ELEMENT-TYPE given is compatible with the type of 
the file, then allow the system to optimize out the idiomatic OPEN given 
above, and otherwise just simulate it in whatever way is convenient. Seems 
to me like that would be portable.
-kmp

∂07-Mar-85  2130	KMP@SCRC-STONY-BROOK.ARPA 	DO-SYMBOLS finding shadowed symbols   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 7 Mar 85  21:30:01 PST
Received: from SCRC-RIO-DE-JANEIRO by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 192222; Fri 8-Mar-85 00:28:37-EST
Date: Fri, 8 Mar 85 00:29 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: DO-SYMBOLS finding shadowed symbols
To: Fahlman@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12092488741.BABYL@CMU-CS-C.ARPA>
Message-ID: <850308002930.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Mon, 4 Mar 1985  23:24 EST
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

    In my earlier note, I sent out my view of how to patch the existing
    description.  This is my view of "how it ought to be" rather than "what
    the manual says".  Does anyone object to adopting this as the "official"
    interpretation?  The only thing I'm uneasy about is letting DO-SYMBOLS
    generate shadowed symbols, but I don't see any good alternative.

I'm also quite uneasy about this shadowed symbols issue. I see two situations:

The first is interactive. When working interactively, you resort to mapping
when the space of things you're frobbing is too large to do manually. In that
case, you want all the help you can get and writing the code to keep out
shadowed symbols may be something you forget or find very hard to write 
correctly the first time (and you may only get one chance, unless you're
very careful). Undoing an incorrect mapping operation involving INTERN may
be massively hard.

The second is non-interactive. There you have the time to write and debug
an algorithm, but you may not be thinking about the shadowed symbol case and
may forget to write it in because it doesn't occur in the scenario you're
thinking about or whatever ... so you release code that mostly works but
has a bug sitting in it just waiting to happen.

If you make DO-SYMBOLS find symbols that are technically not accessible, 
you'd better document it well. But personally, I don't advise it, even 
if it makes coding it much harder. Better you, the implementor, spend the
time doing it once right than users spend the time over and over again
correcting for your ... I was going to say laziness, but that's obviously
the wrong word for people like all the CL implementors are. Nevertheless, 
you get my point. "An ounce of prevention, ..." and all that.

As to worrying about duplicated symbols, that doesn't strike me as as big
a deal, though I'm open to arguments to the contrary.
-kmp

∂08-Mar-85  0827	FAHLMAN@CMU-CS-C.ARPA 	DO-SYMBOLS finding shadowed symbols  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Mar 85  08:27:04 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 8 Mar 85 11:26:08-EST
Date: Fri, 8 Mar 1985  11:25 EST
Message-ID: <FAHLMAN.12093406500.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: DO-SYMBOLS finding shadowed symbols
In-reply-to: Msg of 8 Mar 1985  00:29-EST from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>


I've been having some second thoughts about shadowed symbols in
DO-SYMBOLS myself.  It really is pretty dirty conceptually to have
DO-SYMBOLS supply anything that is not really accessible in the package.

I guess there are some ways that implementors could hack this without
incurring unacceptable costs.  For example, we could set a bit
somewhere, either in the symbol itself or in the hash-table entry, for
any symbol that has ever been shadowed in any other package.  For the
small minority of symbols with this bit set, we would have to do the
extra checking to make sure that it really is accessible; for all other
symbols, we could skip this.  We wouldn't have to worry about un-setting
this bit if a symbol gets un-shadowed -- it's just a heuristic.  There
are lots of variations on this theme.  The point is that it need not
involve unacceptable overhead to eliminate shadowed symbols, though it
does make a bit of extra work for implementors.  I guess I'd opt in this
case to keep the language clean rather than the implementation.

So my revised suggestion is that DO-SYMBOLS does provide all accessible
symbols including those inherited via USE-PACKAGE.  It will present each
symbol at least once (may be more than once in cases of explicit
importantion), but will not present any symbols that are not really
accessible in the package in question due to shadowing.

-- Scott

∂08-Mar-85  1140	HEDRICK@RUTGERS.ARPA 	Re: file-length   
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 8 Mar 85  11:40:41 PST
Date: 8 Mar 85 14:39:47 EST
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: file-length
To: common-lisp@SU-AI.ARPA
In-Reply-To: Message from ""Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>" of 7 Mar 85 23:25:00 EST

Tops-20 requires a GTJFN before we can find file length.  But we can
certainly implement it by opening the file temporarily inside
file-length.  So you shouldn't stop just because some OS's may
need to open the file.

However you should consider that this may lead to ambiguity because of
version numbers.  Consider the following code sequences:
   (check-attributes "foo.bar")
   (if (attributes-look-good)
       (read-file "foo.bar"))
or
   (write-file "foo.bar")
   (look-at-attributes "foo.bar")
The problem with both of these is that some other program may create
a new version of foo.bar in the interim.  If we say that you can
look at attributes only for an open stream, then people are more
likely to open the file once, and do their I/O and attribute-checking
on the open stream.  On TOPS-20, we could get the same effect by
encouraging people to do TRUE-NAME the first time they refer to a
file.  Then they can be sure they are always talking about the same
one.  But on Unix this wouldn't work.

So the safest thing is probably to keep the current definition.
If somebody really does want to look at the length of a file and
will never be opening it, you can define a macro to allow a
syntax like
  (with-temporarily-open-file "foo.bar" x (file-length x))
-------

∂08-Mar-85  1442	RAM@CMU-CS-C.ARPA 	file-length
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Mar 85  14:42:10 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Fri 8 Mar 85 17:41:31-EST
Date: Fri, 8 Mar 1985  17:41 EST
Message-ID: <RAM.12093474853.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: file-length
In-reply-to: Msg of 8 Mar 1985  14:39-EST from Charles Hedrick <HEDRICK at RUTGERS.ARPA>


    Your argument is bogus, since there is no guarantee that arbitrary
operating systems will prevent a file from being overwritten while you
have it open.  In particular, Spice has no concept of an open file,
thus no assurance of consistency.  Unix has no guarantee of fileystem
consistency of any kind, so worrying about it is a lost cause.

  Rob

∂12-Mar-85  0710	hpfclp!paul%hplabs.csnet@csnet-relay.arpa 	float-digits
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 12 Mar 85  07:10:19 PST
Received: from hplabs by csnet-relay.csnet id ad07182; 12 Mar 85 9:59 EST
Date: Tue, 12 Mar 85 02:53:42 pst
From: hpfclp!paul%hplabs.csnet@csnet-relay.arpa
MMDF-Warning:  Parse error in preceding line at CSNET-RELAY.ARPA
Received: by HP-VENUS id AA29106; Tue, 12 Mar 85 02:53:42 pst
Message-Id: <8503121053.AA29106@HP-VENUS>
To: hplabs!common-lisp@su-ai.ARPA
Subject: float-digits
Source-Info:  From (or Sender) name not authenticated.


What is the result of (float-digits 0.0)?

Why isn't "float-radix" a constant?


Paul Beiser
Hewlett-Packard   
Ft. Collins, Colorado
uucp:   ...{ihnp4,hplabs}!hpfcla!paul
arpa:   "hpfclp!paul%hplabs.csnet"@csnet-relay


∂12-Mar-85  0748	FAHLMAN@CMU-CS-C.ARPA 	float-digits
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Mar 85  07:47:51 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 12 Mar 85 10:47:11-EST
Date: Tue, 12 Mar 1985  10:47 EST
Message-ID: <FAHLMAN.12094447991.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   hpfclp!paul%hplabs.csnet@CSNET-RELAY.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: float-digits
In-reply-to: Msg of 12 Mar 1985  05:53-EST from hpfclp!paul%hplabs.csnet at csnet-relay.arpa


Paul,

Floating point hackery is not my specialty, but maybe I can give you a
quick answer that will stand unless one of the real experts pops up to
contradict me.

    What is the result of (float-digits 0.0)?

Float-digits tells you how many radix-b digits there are in the
representation of the fractional part (the "significand") of the type of
number you feed it.  It doesn't care at all about the value of the
argument, just about which type of float it is.  So in this case, it
tells you the number of digits (usually bits) in the significand of a
number of the default floating type, as controlled by
*read-default-float-format*. 

    Why isn't "float-radix" a constant?

Float-radix may in principle be different for different types of floats
in the same implementation, though I don't know of any existing
implemenation that does this.  By making it a function, we allow the
user to ask for the float-radix of some particular type of number: the
type of the argument.

-- Scott

∂19-Mar-85  0056	JLW  	DO-SYMBOLS: duplicates and shadowings  
To:   Fahlman@CMU-CS-C.ARPA
CC:   common-lisp@SU-AI.ARPA 
My reading of the do-symbols documentation was that "the symbols of a
package" was a colloquialism for "symbols accessible in a package", and
hence it should include the inherited symbols -- the Spice code I saw
appeared to be buggy on that score.

Perhaps we should identify the needs and the costs of the two components
in your "revised" suggestion.  
1) I have no need [currently!] for removal of duplicates, but would be
   willing to listen to someone who claims such a need.  As for cost
   of implementing this, it sounds like Hedricks 3+ hashtable lookups
   [on average] per symbol "done" is th best contender.  That could
   easily make some simple cases an order of magnitude slower.
2) In at least one case I know of, it would be rather disastrous for a
   shadowed symbol to be "done", in addition to the shadowing counterpart.
   As for cost of removing shadowed potential inheritees, I would like
   to hear some estimates on the average number of shadowing symbols
   in a package that has an earnest need for some shadowing.  The one
   example I can think of off-hand is a language emulator which is a
   variant on Common Lisp -- the non-standard, conflicting definitions
   have to be shadowed; in the example I'm thinking of, it is still less 
   than 100 shadowings.  The answer to this question may affect the
   strategy for shadowed-symbol omission, and hence the cost.

Just for the record, one may have duplicates arise because the same
symbol is inherited from several different used packages; IMPORT is not
the only villain here.

-- JonL --

∂19-Mar-85  0114	JLW  	File-length on pathnames
To:   dzg@CMU-CS-SPICE.ARPA
CC:   Fahlman@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA   
I believe that Interlisp, at one time, limited the use of the file-length
equivalent to open file; this turned out to be very inconvenient, and was
changed [maybe about the time I began working for Xerox, three years ago].
A lesson to be learned: no matter what the implementation cost, it will
ultimately be more costly *not* to provide that capability to the user;
somebody's example of how Spice would react to the opening of a huge
remote file shows that this is the sort of thing that ought to be done
by the system implementor.

As for potential inconsistencies due to multi-user access to a shared
file system -- consider the two alternatives:  (A) Smooth results, with
only an epsilonic probability that they will be ragged [non "Smooth"] due
to the multi-user, shared access, or (B) nothing.  While opting for (A),
I don't consider myself a gambler.

By the way, what kind of distributed file system does Spice have?  Isn't
it rather primitive to provide no byte-level or page-level access to
remote files?  It sounds from the previous discussions that only an FTP
like facility is provided.

-- JonL --

∂19-Mar-85  0717	FAHLMAN@CMU-CS-C.ARPA 	DO-SYMBOLS: duplicates and shadowings     
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Mar 85  07:17:43 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 19 Mar 85 10:05:40-EST
Date: Tue, 19 Mar 1985  10:05 EST
Message-ID: <FAHLMAN.12096275453.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Jon White <JLW@SU-AI.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: DO-SYMBOLS: duplicates and shadowings  


The Spice Lisp system has now been changed by Rob Maclachlan so that
DO-SYMBOLS does the right thing (according to my latest proposal):
inherited symbols are presented, there is no special effort to eliminate
duplicates, and shadowed symbols are eliminated.  As I understand it,
the latter is accomplished by keeping track of which packages contain
*any* shadowed symbols, and for symbols exported by these packages doing
what amounts to a call to FIND-SYMBOL on each candidate.  Rob tells me
that even when this extra checking is being done, it doesn't hurt us too
much in speed.

-- Scott

∂19-Mar-85  1344	RAM@CMU-CS-C.ARPA 	File-length on pathnames  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Mar 85  13:43:52 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Tue 19 Mar 85 16:42:55-EST
Date: Tue, 19 Mar 1985  16:42 EST
Message-ID: <RAM.12096347756.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   Jon White <JLW@SU-AI.ARPA>
Cc:   common-lisp@SU-AI.ARPA, dzg@CMU-CS-SPICE.ARPA, Fahlman@CMU-CS-C.ARPA
Subject: File-length on pathnames
In-reply-to: Msg of 19 Mar 1985  04:14-EST from Jon White <JLW at SU-AI.ARPA>


    The official party line is that Spice has no concept of a host.
In order to access a file on another machine, you embed that
filesystem into your filesystem.  There is no reasonable way to talk
about access at the byte level or page level, since the only file I/O
primitives are reading and writing an entire file.  This works fairly
well, since the file is only mapped when you read it, and the reading
not actually done until you touch the page.  There is currently work
in progress to permit mapping of files and memory over the network.
When this capability exists, the problem will go away.

    I find the restriction on FILE-LENGTH extremely silly.  As near as
I can tell, the argument for requiring the restriction is the
following:
  - Some operating systems require an operation (which they may nor may
    not call open, and is in any case not probably not identical in
    semantics to the Common Lisp open) to be done before the length of
    a file can be determined.
  - This "operating system open" call may have some requirement for
    exclusive access.  If some other process has the file open, then
    the call to FILE-LENGTH may wait or fail.
  - It is somehow more intuitive to have OPEN wait or fail than to
    have FILE-LENGTH wait or fail.

    I think that if there is any implicit guarantee in the CLM
filesystem chapter that certain calls may not wait or fail whenever
they feel like it, then it is bogus.  There is no way the CLM can hope
to describe the semantics of arbitrary filesystems, let alone the
real-time properties.

  Rob

∂19-Mar-85  1855	FAHLMAN@CMU-CS-C.ARPA 	[Gall: Bug Report]    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Mar 85  18:55:00 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 19 Mar 85 21:54:17-EST
Date: Tue, 19 Mar 1985  21:53 EST
Message-ID: <FAHLMAN.12096404394.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   common-lisp@SU-AI.ARPA
Subject: [Gall: Bug Report]


Here are some Common Lisp questions sent to me by Nick Gall of Gold
Hill.  I'll take a crack at answering some of them when I get the time,
if nobody else beats me to this.

-- Scott

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

Date: Tuesday, 19 March 1985  13:39-EST
From: Nick Gall <Gall at MIT-MULTICS.ARPA>
To:   Fahlman
Re:   Bug Report
Posted-Date: 19 Mar 85 13:41 EST
Acknowledge-To: Nick Gall <Gall@MIT-MULTICS.ARPA>

These comments are presented in the style suggested by Postscript
to the Ada (TM) Language Reference Manual.  The format of the
header is as follows:

          !section  SECTION#(PARAGRAPH#)          NAME      ISO-DATE
          !version  REFERENCE-MANUAL-VERSION-NAME
          !topic    SUMMARY-OF-COMMENT

The Ada RM states that,

          The topic line should contain a one line summary of the
    comment.  This line is essential, and you are kindly asked to
    avoid topics such as "Typo" or "Editorial comment" which will
    not convey any  information when printed in a table of
    contents.  As an example consider:

                    !topic Subcomponents of constants are constants

          Note also that nothing prevents the topic line from including
    all the information of a comment, as in the following topic
    line:

                    !topic    Insert: "... are {implicitly} defined by a
                              subtype declarartion"

-----------------------------------------------------------------
!section  None      Nick Gall 85-03-19
!version  Digital Press 1984
!topic    Paragraphs should be numbered

Paragraphs should be numbered as in the Ada (TM) Language
Reference Manual.  This would make identification of particular
paragraphs in discussions much simpler.

-----------------------------------------------------------------
!section  14.1(2)   Nick Gall 85-03-19
!version  Digital Press 1984
!topic    Copying arrays

Although functions such as SUBSEQ state that the copy made of an
array is of the same type, they say nothing of the two other array
attributes, fill pointer and adjustable.

The question is, "Should copied arrays share these attributes
with their originals, or should they be simple?"

The answer should be stated in the standard.

I think the best solution is to make simple copies by default,
and allow an optional or keyword arg. to specify that all
attributes should be copied.

-----------------------------------------------------------------
!section  18.3(2)   Nick Gall 85-03-19
!version  Digital Press 1984
!topic    Implied copying in the trim functions

Although it is implied that the result of the string `trim'
functions is a copy of the original strings, it is not explicitly
stated.  Since all the other functions which can potentially make
copies of strings/arrays state this explicitly (e.g. SUBSEQ,
CONCATENATE, SUBSTITUTE), the trim functions should also.

----------------------------------------------------------------- 
!section  18.3(2)   Nick Gall 85-03-19
!version  Digital Press 1984
!topic    Implied copying in the STRING-{UP | DOWN}CASE functions

Although it is implied that the result of the {up | down}
functions is a copy of the original strings, it is not explicitly
stated.  Since all the other functions which can potentially make
copies of strings/arrays state this explicitly (e.g. SUBSEQ,
CONCATENATE, SUBSTITUTE), the {up | down} functions should also.

----------------------------------------------------------------- 
!section  9.1(6)    Nick Gall 85-03-19
!version  Digital Press 1984
!topic    Pervasiveness of declarations over FLET and LABELS

Example:
          (defun the-many-function-names-foo (x)
                    (declare (inline foo))
                    (foo x)                                           ; First call of FOO
                    (flet     ((foo (y z) (zap z y)))
                       (foo x x))                                     ; Second call of FOO
                    (foo x))                                ; Third call of FOO

According to the paragraph in question: "Declarations that do not
concern themselves with variable bindings are pervasive,
affecting ALL CODE IN THE BODY OF THE SPECIAL FORM."  Thus, the
second call to FOO will be open-coded; in spite of the fact that
the second call of FOO refers to a function which is totally
unrelated (except by name) to the FOO referred to in the other
two calls.

To prevent this, one has to provide a declaration
within the FLET form:
          ...
          (flet ((foo (y z) (zap z y)))
                (declare (notinline foo))
             ...)
          ...

But what if this FLET were the expansion of a macro?  How is the
macro expansion function supposed to know which pervasive
declarations will affect the functional objects specified in the
FLET?

In an analogous case concerning special variables instead of
function names, no such redeclaration is necessary:

          (defun the-many-variables-foo (foo)
                    (declare (special foo))
                    (fram foo)                                        ; dynamic binding
                    (let ((foo (boop)))
                       (frab foo))                                    ; local lexical binding
                    (zoop foo))                                       ; dynamic binding

Declarations concerning function names should be treated as
special variable declarartions are:  references are pervasively
affected, but not bindings.

The last paragraph in each of the function name declarations
(e.g. FUNCTION, INLINE, etc.) which begins, "Note that the rules
of lexical scoping...", suggests that function names and special
variables ARE treated analogously.  If this is so, it should be
made explicitly clear in section 9.1.

----------------------------------------------------------------- 
!section  9.1(12)   Nick Gall 85-03-19
!version  Digital Press 1984
!topic    Non-Top-Level use of PROCLAIM

Can PROCLAIM be used, other than at top-level?  Since DEFVAR,
etc., are proclamations and can be used at other than top-level,
the answer to this question seems to be `yes'.

Is PROCLAIM a `declaration', i.e., must it appear only where a
declaration is allowed?  Since it is allowed at top-level (unlike 
DECLARE), and it is a function, and since the other proclaiming
forms (e.g. DEFVAR, etc.) could not be considered declarations
(since they perform evaluation and assignment), the answer must
be no.

Then what is the effect of using PROCLAIM (or one one the other
proclaiming forms) in the middle of a function?  For example:

          (defun foo (a) (zap a) (proclaim '(special a)) (zark a))

Does the first reference to A refer to the local binding?  Does
the second reference refer to the global?

Some mention of the effects of the non-top-level use of PROCLAIM
and the other proclaiming forms should be made.

-----------------------------------------------------------------
!section  7.5(14)   Nick Gall 85-03-19
!version  Digital Press 1984
!topic    Scope and Extent of local function names

NOTE: See 9.2 (ftype, function, inline).

Example:
          (DEFUN CREATE-MAKEP (MAKE)
             (FLET ((CAR (SYMBOL) (GET SYMBOL 'AUTOMOBILE)))
                #'(LAMBDA (OWNER) (EQ MAKE (CAR OWNER)))))

          (SETQ FOO (CREATE-MAKEP 'HONDA))
          (FUNCALL FOO 'BILL) => ?????

Question: What does CAR refer to when it is used in the closure
                    returned by CREATE-MAKEP?  I.E., What is the scope and
                    extent of the binding of a local function name to a
                    functional object?

Section 7.1(1) states that "There are two spaces of variables in
Common Lisp, in effect: ordinary variables and function names." 
And the function name binding control structures appear in the
section entitled "Establishing New Variable Bindings".

I suggest that Common Lisp go all the way, and allow a
SPECIAL-FUNCTION-NAME declaration that would be analogous to the
SPECIAL declaration for "ordinary" variables.

Such a concept would make the idea of
ordinary-variable/function-name binding and assignment much more
consistent.
-----------------------------------------------------------------
!section  5.2.2(4)  Nick Gall 85-03-19
!version  Digital Press 1984
!topic      Lambda variables with the same `name'

Ex. 1:
          (lambda (a a) (values a))

Ex. 2:
          ;; Assume (not (eq p1::a p2::a))
          (lambda (p1::a p2::a) (values p1::a p2::a))

Ex. 3:
          ;; Assume (eq p1::a p2::a)
          (lambda (p1::a p2::a) (values p1::a p2::a))


1. Is Ex. 1 legal? If so, which args., value is returned?
   My answer: No, and the CLRM should state this.

2. Is Ex. 2 legal?
   My answer: Yes.

3. Is Ex. 3 legal?
   My answer: No. it is just like Ex. 1.

The point that Exs. 2 + 3 point out is that it is the symbols
THEMSELVES that name variables, not their (qualified)
print-names.  This distinction should be pointed out.

This same comment applies to all the other environment
establishing functions (section 7.5).
-----------------------------------------------------------------
!section  5.3.2(7)  Nick Gall 85-03-19
!version  Digital Press 1984
!topic    Redeclaring Constants with DEFCONSTANT

It should be mentioned in this paragraph, as it is in 5.1.2(6),
that,

          Constant symbols defined by DEFCONSTANT also become reserved
and may not be further assigned to or bound (although they may be
redefined, if necessary, by using DEFCONSTANT again).

-----------------------------------------------------------------
!section  7.8.5(3)  Nick Gall 85-03-19
!version  Digital Press 1984
!topic    Are identical TAGs legal?

If so, which one is gone to? If not, it should be stated.
-----------------------------------------------------------------
!section  7.8.5(3)  Nick Gall 85-03-19
!version  Digital Press 1984
!topic    Items which are not symbols, integers, or lists in
            a TAGBODY

The sentence,

          An item in the body may be a symbol or an integer, in which
    case it is called a TAG, or ... a list, in which case it is
    called a STATEMENT.

Does this mean that any other atom is illegal?  If so, it should
be stated.
-----------------------------------------------------------------
!section  9.1(10)   Nick Gall 85-03-19
!version  Digital Press 1984
!topic    Replace: "... the parameter {of} NONSENSE named Z."

-----------------------------------------------------------------
!section  23.1.2(11)          Nick Gall 85-03-19
!version  Digital Press 1984
!topic    Replace: "... if no syntactically correct {namestring}
                                         was seen."

-----------------------------------------------------------------
!
-----------------------------------------------------------------
!section  10.3(9)   Nick Gall 85-03-19
!version  Digital Press 1984
!topic    Which  bindings are copied by COPY-SYMBOL?

          "the initial value and function-definition of the new symbol
will be the same as those of SYM..."

          Does this mean that the (dynamic) value of the variable
referred to by SYM, at the point where COPY-SYMBOL symbol is
invoked, is copied?   Or, does it mean that the `initial', i.e.
global value of the special variable named by SYM is copied?
Although the wording seems to suggest the latter, it should be
made clearer.

The same questions and suggestion applies to the
function-definition copied by COPY-SYMBOL.

-----------------------------------------------------------------
!section  15.2(39)  Nick Gall 85-03-19
!version  Digital Press 1984
!topic    The effect of NCONC on '() arguments

          "The arguments are changed, rather than copied."

Surely, this does not apply to the arguments which are empty
lists.  Also, the last argument is NOT changed, right?

Are dotted-lists allowed?  If so, the result of a call such as,

          (NCONC '(1 2 . 3) NIL)

should be made explicit.
-----------------------------------------------------------------
!section  15.2(55)  Nick Gall 85-03-19
!version  Digital Press 1984
!topic    What may N be in BUTLAST?

MUST N be a non-negative integer?  Or can it be negative (with a
neg. N having the same effect as a zero N)?  The constraints on
the type and range of N should be made explicit.
-----------------------------------------------------------------
!section  15.2(57)  Nick Gall 85-03-19
!version  Digital Press 1984
!topic    When is LIST modified in NBUTLAST?

Shouldn't the condition, "If the LIST has fewer than N
elements..." read, "If the LIST has N or fewer elements...".
-----------------------------------------------------------------
!section  15.5(8)   Nick Gall 85-03-19
!version  Digital Press 1984
!topic    Is (TAILP NIL list) true or false for every list?

"This preicate is true if SUBLIST is a sublist of LIST (i.e. one
of the conses that makes up LIST)."  According to this criterion,
NIL is not a sublist to any list since it is not a cons.

"...TAILP is true if (NTHCDR n list) is sublist, for some value
of N."  According to this definition NIL is a sublist of every
list, since the (NTHCDR (LENGTH list) list) is NIL for every
LIST.

Although a phrase in the definition of LDIFF, "If SUBLIST is not
a tail of LIST (and in particular if SUBLIST is NIL)," seems to
indicate that NIL is NOT a sublist (or tail) of any list, this
should be stated explicitly in the definition of TAILP.
-----------------------------------------------------------------
!section  20.1(7)   Nick Gall 85-03-19
!version  Digital Press 1984
!topic    Is *APPLYHOOK* funcalled for special forms?

"The variable *APPLYHOOK* ... is used when a function is about to
be applied to arguments."  Does `function' refer to a functional
object which is in fact a function (i.e., its args. are evaled
before it is called), or does it refer to any functional object
(e.g., `special' functional objects)?

Later in the paragraph, it is stated that, 

          The apply hook function is used only for application of
    ordinary functions within eval.  It is not used for
    applications via apply, or funcall, for applications by such
    functions as map or reduce, or for invocation of
    macro-expansion functions...

This paragraph does not really address the "application of
ordinary functions within eval" but rather the "ordinary
application of functions by eval."  Also it does not clarify the
action taken for special forms.

This paragraph should be made clearer.

-----------------------------------------------------------------
!section  21.3(7)   Nick Gall 85-03-19
!version  Digital Press 1984
!topic    What does CLOSE Return?

I think it should return the STREAM it was given to close.  This
would make it symmetric with OPEN: OPEN returns an open stream,
CLOSE returns a closed stream.
-----------------------------------------------------------------
!section  20.1(last-1)        Nick Gall 85-03-19
!version  Digital Press 1984
!topic    Is nil declared by defconstant?

          ...all constant symbols declared by DEFCONSTANT, such as NIL,
    T, and PI.

If NIL is declared by DEFCONSTANT then it can legally be
redefined according to section 5.1.2(last):

          Constant symbols defined by DEFCONSTANT ... may be redefined,
    if necessary, by using DEFCONSTANT again[].

Is such an interpretation correct?

-----------------------------------------------------------------
!section  4.8(1)    Nick Gall 85-03-19
!version  Digital Press 1984
!topic    The meaning of the word `convert'

Does coerce `convert' (i.e., change the type bits) and return the
original object (or the pointer if typed pointers are supported)
when possible (e.g., coercing a string to an array of
(unsigned-byte 8) in some implementations); or does coerce ALWAYS
create and return a new `equivalent' object; or does the Common
Lisp spec. not define this?

-----------------------------------------------------------------
!section  5.3.2(7)  Nick Gall 85-03-19
!version  Digital Press 1984
!topic    Lexical variable with the same name as a named constant

A named constant is declared using DEFCONSTANT.  DEFCONSTANT
PROCLAIMs that a symbol always names a special variable (which
happens to have a fixed value).  This proclamation applies to ALL
bindings and references.  Therefore, after such a proclamation,
no lexical variable with such a name can be used.

If this is the case, when would the compiler ever have the
opportunity to 

          ...issue warnings about bindings of the lexical variable of
    the same name [as a name declared by DEFCONSTANT to be
    constant].

∂19-Mar-85  2212	cork%umass-cs.csnet@csnet-relay.arpa 	Implementation of MAP, SOME, EVERY, etc...
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 19 Mar 85  22:12:08 PST
Received: from umass-cs by csnet-relay.csnet id af11355; 20 Mar 85 1:07 EST
Date:     Tue, 19 Mar 85 11:58 EST
From:     Dan Corkill <cork%umass-cs.csnet@csnet-relay.arpa>
To:       common-lisp@su-ai.ARPA
Subject:  Implementation of MAP, SOME, EVERY, etc...


There is an easily made implementation error in MAP, SOME, EVERY, etc.
The published semantics indicate that these functions use the length of
the shortest argument sequence to determine how many iterations to 
perform (and in this way parallel the semantics of mapc, mapcar, etc.).

Thus it would appear that:

	(map 'list '+ '(1 2 3) (star 2))

where star builds a circular list of its argument should be legal and
return => (3 4 5).

Implementations that use length to check the length of argument sequences
will break on such a call.

Dan Corkill
(Cork@UMass)

∂19-Mar-85  2228	REM@IMSSS 	Default attributes of copy due to SUBSEQ    
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Mar-19 22:24:02 PST (=GMT-8hr)
Date: 1985 March 19 21:23:38 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132100055002.G0396
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To:common-lisp@SU-AI.ARPA
CC:Gall@MIT-MULTICS.ARPA
Subject: Default attributes of copy due to SUBSEQ
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM@MIT-MC.ARPA

> Date: Tuesday, 19 March 1985  13:39-EST
> From: Nick Gall <Gall at MIT-MULTICS.ARPA> (via Fahlman)
> Posted-Date: 19 Mar 85 13:41 EST
>
> !section  14.1(2)   Nick Gall 85-03-19
> !version  Digital Press 1984
> !topic    Copying arrays
>
> Although functions such as SUBSEQ state that the copy made of an
> array is of the same type, they say nothing of the two other array
> attributes, fill pointer and adjustable.
> 
> The question is, "Should copied arrays share these attributes
> with their originals, or should they be simple?"
> 
> The answer should be stated in the standard.

I agree completely so far. I would think it would copy those other
attributes, rather than clobber them to SIMPLE when making the copy,
but on the other hand, I'm not really sure.
But clearly the manual should say, and probably an extra argument
should be available to override the default.

∂19-Mar-85  2228	REM@IMSSS 	What should CLOSE return? Closed-channel-object, or truefilename.    
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Mar-19 22:24:42 PST (=GMT-8hr)
Date: 1985 March 19 22:10:06 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132100055052.G0446
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To:common-lisp@SU-AI.ARPA
CC:Gall@MIT-MULTICS.ARPA
Subject: What should CLOSE return? Closed-channel-object, or truefilename.
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM@MIT-MC.ARPA

> !section  21.3(7)   Nick Gall 85-03-19
> !version  Digital Press 1984
> !topic    What does CLOSE Return?
> 
> I think it should return the STREAM it was given to close.  This
> would make it symmetric with OPEN: OPEN returns an open stream,
> CLOSE returns a closed stream.

That's not symmetric, that's coercive. OPEN and CLOSE are like
matching parenthesis, one does it and the other undos it except for
a residual side-effect. OPEN takes a name and returns an I/O channel
(at the LISP level, an object that can be name an active stream of
data). CLOSE takes an I/O channel and should return a name to be
symmetric with OPEN. This would be an opportune time to solve race
conditions where several users are making different versions of the
same file at the same time by the trick of writing a temporary file
and then renaming it during the CLOSE. At CLOSE the version number is
determined, and at that moment before somebody can create a later
version the lisp CLOSE function obtains the true filename of the
particular version we created.

∂19-Mar-85  2228	REM@IMSSS 	Length of currently-open-for-write file is ambiguous or meaningless  
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Mar-19 22:23:35 PST (=GMT-8hr)
Date: 1985 March 19 20:54:07 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132100054747.G0371
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To: common-lisp@SU-AI.ARPA
CC: RAM@CMU-CS-C.ARPA
Subject: Length of currently-open-for-write file is ambiguous or meaningless
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM@MIT-MC.ARPA

> Date: Tue, 19 Mar 1985  16:42 EST
> From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
> Subject: File-length on pathnames
>...
>  - This "operating system open" call may have some requirement for
>    exclusive access.  If some other process has the file open, then
>    the call to FILE-LENGTH may wait or fail.
>  - It is somehow more intuitive to have OPEN wait or fail than to
>    have FILE-LENGTH wait or fail.
>
>    I think that if there is any implicit guarantee in the CLM
> filesystem chapter that certain calls may not wait or fail whenever
> they feel like it, then it is bogus. ...

I agree completely with RAM, in fact I'd like to present a case that
FILE-LENGTH is meaningless when a file is open for write access by
self or by other task/user, and thus that it's quite reasonable for
FILE-LENGTH to fail (signal an error). FILE-LENGTH is supposed to tell
the length of the disk file, right? Well, if you're in the middle of
modifying it, either by replacing it with a new version you're in the
midst of creating, or by destructively modifying it and by changing
the directory attributes (length, disk record map, etc.), what exactly
do you mean by the length?
 (1) Length that it was before you started to modify it (that info
   probably already clobbered in case of destructive modification,
   although available if making new version which is not yet installed).
 (2) Length it will be when you close it (not known yet).
 (3) Some sort of momentary length as it currently exists (does that
   include I/O buffers which have been partially filled in RAM but not
   yet written to disk? buffers that have been written to disk but not
   yet included in directory? buffers that have been unwritten by
   decreasing the end-of-file pointer but haven't yet been expunged and
   thus still are part of the file in some sense that if the system
   crashed a wizard could recover them?)

Perhaps the function should include an extra argument that tells
whether you want the old info or a failure (error signal) or a
wait-for-close then new info or the instantaneous-guess info in such
an ambiguous case? Probably the default should be failure if you don't
supply the &OPTIONAL or &KEYWORD argument. If a file is open only for
read, I think there's no problem, the file can always be sized? (Or in
a network environment, perhaps there is only one copy of the file at
any time, and to size it you have to first move it to your site, which
means nobody else can have it open for read elsewhere? In such a
network it might fail even in case of open for read by somebody else
on another site, and the extra argument might be needed to say what to
do to resolve the problem.)

Since even in the case of a file you have open yourself the above
ambiguity can occur, with FILE-LENGTH of an I/O channel signalling an
error, I see no problem with implementing FILE-LENGTH applied to
filenames, where it's completely reasonable for the programmer to
have to be aware it might signal an error at random times when
somebody (yourself included) happens to have the file open for write.

∂20-Mar-85  0132	RAM@CMU-CS-C.ARPA 	Length of currently-open-for-write file is ambiguous or meaningless    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Mar 85  01:32:15 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 20 Mar 85 04:31:46-EST
Date: Wed, 20 Mar 1985  04:31 EST
Message-ID: <RAM.12096476811.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   REM@MIT-MC.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: Length of currently-open-for-write file is ambiguous or meaningless
In-reply-to: Msg of 1985 Mar 19 20:54:07 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.SU.EDU>


    I think that file-length of a stream that is open for write is
perfectly meaningful.  file-length is the file-position of EOF.  In
the presence of multiple concurrent writers, the result may be
ill-defined, but if that is the case, you are in bad trouble anyway.

    The meaning of File-Length on the name of a file which is open for
write seems operating system dependant, and should be undefined.  Since
it is in fact this case which I understand to be the basis for not
allowing file-length on file names, taking this stand would dispose of
any problems.

  Rob

∂20-Mar-85  0141	RAM@CMU-CS-C.ARPA 	Default attributes of copy due to SUBSEQ 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Mar 85  01:41:32 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 20 Mar 85 04:40:52-EST
Date: Wed, 20 Mar 1985  04:40 EST
Message-ID: <RAM.12096478471.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   REM@MIT-MC.ARPA
Cc:   common-lisp@SU-AI.ARPA, Gall@MIT-MULTICS.ARPA
Subject: Default attributes of copy due to SUBSEQ
In-reply-to: Msg of 1985 Mar 19 21:23:38 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.SU.EDU>


    The semantics that I favor (and those implemented by Spice Lisp)
are that every Common Lisp function which returns an array returns a
simple array unless the function is make-array or one of the arguments
is eq to the result.  This has the advantage of being a simple
specification, and also allows the compiler to do more interesting
type-inference.

  Rob

∂20-Mar-85  0144	RAM@CMU-CS-C.ARPA 	Default attributes of copy due to SUBSEQ 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Mar 85  01:44:21 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 20 Mar 85 04:43:45-EST
Date: Wed, 20 Mar 1985  04:43 EST
Message-ID: <RAM.12096478990.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   REM@MIT-MC.ARPA
Cc:   common-lisp@SU-AI.ARPA, Gall@MIT-MULTICS.ARPA
Subject: Default attributes of copy due to SUBSEQ
In-reply-to: Msg of 1985 Mar 19 21:23:38 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.SU.EDU>


    Well, I guess that's a bit excessively simple if read literally.
It could be "every function that creates an array creates a simple
array unless that function is make-array".

  Rob

∂20-Mar-85  0208	RAM@CMU-CS-C.ARPA 	Implementation of MAP, SOME, EVERY, etc...    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Mar 85  02:08:14 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 20 Mar 85 05:07:23-EST
Date: Wed, 20 Mar 1985  05:07 EST
Message-ID: <RAM.12096483296.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   Dan Corkill <cork%umass-cs.csnet@CSNET-RELAY.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Implementation of MAP, SOME, EVERY, etc...
In-reply-to: Msg of 19 Mar 1985  11:58-EST from Dan Corkill <cork%umass-cs.csnet at csnet-relay.arpa>


    I think that a sufficiently fascist interpretation of the CLM
would say that this is erroneous.  Nowhere in the CLM is it stated
that a circular list is the same as an infinite list, and it is
unlikely that any implementation would consistently have those
semantics.   Setting element 537 of an infinite list should only
change element 537.  Setting element 537 in a one-element circular
list would probably change all the elements if it terminates.

    The definition of a normal list in the Lists chapter is one
terminated by NIL.  By this definition, a circular list is a dotted
list.  I believe that there was a decision at one point that functions
which use lists as sequences (a superset of the sequence functions)
are allowed to complain about dotted lists.  This is implied by the
statement that Endp is the canonical list-end predicate.

  Rob

∂20-Mar-85  2032	DDYER@USC-ISIB.ARPA 	Re: Implementation of MAP, SOME, EVERY, etc...   
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 20 Mar 85  20:32:02 PST
Date: 20 Mar 1985 20:07:05 PST
Subject: Re: Implementation of MAP, SOME, EVERY, etc...
From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12096483296.BABYL@CMU-CS-C.ARPA>


 I disagree with RAM;  Imposing the requirement that all lists
passed to MAPxxx be "proper" imposes an unnecesary burden on
the use of mapping functions;  The programmer shouldn't have to
know anything about the lists passed to MAPxxx except that the
sortest list is a proper list.

 Besides, it would be an extremely poor implementation technique
to take LENGTH of all the lists before starting work -- I would say
that system functions should NEVER use LENGTH unless it is otherwise
known that the functin in question will inspect every element of the
list anyway, both because lists might legitimately be "improper",
and because lists can legitimately be very long, which makes 
LENGTH wasteful.
-------

∂20-Mar-85  2053	RAM@CMU-CS-C.ARPA 	Query (FILE-LENGTH in particular) of file by name when open  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Mar 85  20:52:45 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 20 Mar 85 23:21:39-EST
Date: Wed, 20 Mar 1985  21:30 EST
Message-ID: <RAM.12096662208.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   REM@MIT-MC.ARPA
cc:   common-lisp@SU-AI.ARPA
Subject: Query (FILE-LENGTH in particular) of file by name when open
In-reply-to: Msg of 1985 Mar 20 02:44:29 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.SU.EDU>


    I don't think we can require it to signal an error, since some
operating systems don't provide any way to tell if a file is open.
In Spice, for example, there is no open call, so the question isn't
even meaningful.  I think that all we can say is that it is an error,
and implementations are encouraged to detect it, or at least not
delete all you files and crash the machine.

  Rob

∂20-Mar-85  2052	RAM@CMU-CS-C.ARPA 	[REM: Query (FILE-LENGTH in particular) of file by name when open]
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Mar 85  20:52:25 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 20 Mar 85 23:21:37-EST
Date: Wed, 20 Mar 1985  21:25 EST
Message-ID: <RAM.12096661456.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   common-lisp@SU-AI.ARPA
Subject: [REM: Query (FILE-LENGTH in particular) of file by name when open]

Date: 1985 March 20 02:44:29 PST (=GMT-8hr)
From: Robert Elton Maas <REM at IMSSS.SU.EDU>
Sender: REM%IMSSS at SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-To: REM at MIT-MC.ARPA
To:   RAM
Re:   Query (FILE-LENGTH in particular) of file by name when open
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Mar-20 14:51:03 PST (=GMT-8hr)

> Date: Wed, 20 Mar 1985  04:31 EST
> From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
> Subject: Length of currently-open-for-write file is ambiguous or meaningless
> 
>     The meaning of File-Length on the name of a file which is open for
> write seems operating system dependant, and should be undefined.  Since
> it is in fact this case which I understand to be the basis for not
> allowing file-length on file names, taking this stand would dispose of
> any problems.

May I take it that you mostly agree with me on this point, that the
ambiguity I pointed out (size of file before during or after current
update), and you're saying the default (or only possible
implementation) should be to signal an error if the file you happen to
ask about by name is currently open for write? (Therefore the general
idea of asking about a file by name is well-defined and should be
provided by CL: if the file is open-for-write the query signals an
error, else the query works as expected?)

If so, I think we've reached 2-party concensus (I yield on the other
point you made about query on lisp I/O-channel-object being meaningful).

∂20-Mar-85  2052	RAM@CMU-CS-C.ARPA 	[REM: destructive operations on circular emulation of infinite list]   
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Mar 85  20:52:01 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 20 Mar 85 23:21:34-EST
Date: Wed, 20 Mar 1985  21:25 EST
Message-ID: <RAM.12096661390.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   common-lisp@SU-AI.ARPA
Subject: [REM: destructive operations on circular emulation of infinite list]

Date: 1985 March 20 03:01:16 PST (=GMT-8hr)
From: Robert Elton Maas <REM at IMSSS.SU.EDU>
Sender: REM%IMSSS at SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-To: REM at MIT-MC.ARPA
To:   RAM
cc:   "cork%umass-cs.csnet" at CSNET-RELAY.ARPA
Re:   destructive operations on circular emulation of infinite list
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Mar-20 14:51:18 PST (=GMT-8hr)

> Date: Wed, 20 Mar 1985  05:07 EST
> From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
> Subject: Implementation of MAP, SOME, EVERY, etc...
> 
>     I think that a sufficiently fascist interpretation of the CLM
> would say that this is erroneous.  Nowhere in the CLM is it stated
> that a circular list is the same as an infinite list, and it is
> unlikely that any implementation would consistently have those
> semantics.   Setting element 537 of an infinite list should only
> change element 537.  Setting element 537 in a one-element circular
> list would probably change all the elements if it terminates.

I agree. Mathematically if LISP emulates an infinite list by a
circular list instead of by a continuation, and you ask LISP to make
an infinite list, then if you ask LISP to change a single element, the
circular list must be converted to a linear list up to the point of
change so that only the single element you specify will get changed. A
problem arises however if you fake out LISP by doing a RPLACD or NCONC
et al yourself without telling LISP whether you really meant to end
upwith a circular list (side-effects shared) or an emulation of an
infinite lisp (unfold-on-modify). In that case CLM should say the
result is implementation-dependent and such trick should be avoided in
portable code. Rebuttal?

>     The definition of a normal list in the Lists chapter is one
> terminated by NIL.  By this definition, a circular list is a dotted
> list.

Does it say anything except a normal list is a dotted list? There are
no other datatypes in the world? Or does it allow a third choice
(infinite list, circular list, list-by-continuation, etc.) which it
then fails to properly document?

> I believe that there was a decision at one point that functions
> which use lists as sequences (a superset of the sequence functions)
> are allowed to complain about dotted lists.

I think they should complain about (finite) dotted lists, but permit
both normal lists and circular/infinite lists if the latter is/are
permitted otherwise in CL. The semantics of MAPping down a set of
lists none of which is normal nor dotted, should be that the process
runs forever until a THROW-type event happens or the environment runs
out of memory or another kind of error happens. For example, a
reasonable hack would be to MAP down a circular list of ten elements
and when a realtime interupt happens process the current cell and THROW
out of the otherwise-infinite loop, thereby processing a random element
from a finite set. Or MAP down a circular list of devices trying to
find one that is available, looping forever if none of them ever
become free, otherwise using the first random one that becomes free.
The code for looping in a circular list seems to me cleaner than using
a 2-level loop with the outer loop DOing FOREVER the inner finite loop.

If the manual is unclear, I favor the above. If the manual clearly
forbids my interpretation, then I guess it's too late to change it.

∂20-Mar-85  2122	JLW  	Implementation of MAP, SOME, etc  
To:   common-lisp@SU-AI.ARPA

Surely the CLM doesn't suggest that the implementation of these functions
must call the LENGTH function -- whereas it may not hurt to do so for what
I'd call "index access" datatypes, there are many reasons for not doing so
on lists.  The phrase I see in the manual is "... if the end of a sequence
is reached ...", and this doesn't say how one determines that the end
is reached.  But the docmentation of ENDP suggests that it is the preferred
way to answer the question for lists.

-- JonL --

∂20-Mar-85  2152	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Follow-up and New Questions
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 20 Mar 85  21:52:19 PST
Posted-Date:  21 Mar 85 00:52 EST
Acknowledge-To:  Nick Gall <Gall@MIT-MULTICS.ARPA>
Date:  Thu, 21 Mar 85 00:49 EST
From:  Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject:  Follow-up and New Questions
To:  common-lisp@SU-AI.ARPA
cc:  RAM@CMU-CS-C.ARPA, REM@MIT-MC.ARPA
Message-ID:  <850321054958.626398@MIT-MULTICS.ARPA>

**********
    From: Robert Elton Maas <REM@IMSSS.SU.EDU>
    To:Gall@MIT-MULTICS.ARPA
    Subject:Compiler warning msgs

    > !section  5.3.2(7)  Nick Gall 85-03-19
    > !version  Digital Press 1984
    > !topic    Lexical variable with the same name as a named constant
    > ... (illegal, can't do it)
    > If this is the case, when would the compiler ever have the
    > opportunity to
    >           ...issue warnings about bindings of the lexical variable of
    >     the same name [as a name declared by DEFCONSTANT to be
    >     constant].

    My guess is what is meant by "warning" is "nonfatal diagnostic
    message", i.e. the construction is illegal and the compiler can't
    possibly compile it into correct code, but the error doesn't crash the
    compiler, the compiler merely issues a diagnostic (warning) and
    proceeds to try to recover and compile the rest of the file.

I think you misunderstood my question.  Take this code for example:

          (defconstant const ...)

          (defun foo ()
            (let ((const 1))
              ...))

One might think that the LET is binding a lexical variable named CONST; it is
not.  LET is binding a special var. named CONST.  This is due to the fact that
defconstant does an implicit proclaim.  This proclaim pervasively affects all
bindings of the proclaimed var.  This means that once a variable name appears
in a defconstant, there is no context in which the interpreter or compiler
would consider that name to be the name of a lexical variable.  So... there is
no way the compiler could ever warn the user that they are using a lexical
variable with the same name as a constant.  To put it briefly, I bet you can't
show me a piece of Common Lisp code that would cause such a warning.
**********
    From: Robert Elton Maas <REM@IMSSS.SU.EDU>
    To:common-lisp@SU-AI.ARPA
    CC:Gall@MIT-MULTICS.ARPA
    Subject: What should CLOSE return? Closed-channel-object, or truefilename.

    > !section  21.3(7)   Nick Gall 85-03-19
    > !version  Digital Press 1984
    > !topic    What does CLOSE Return?
    >
    > I think it should return the STREAM it was given to close.  This
    > would make it symmetric with OPEN: OPEN returns an open stream,
    > CLOSE returns a closed stream.

    That's not symmetric, that's coercive. OPEN and CLOSE are like
    matching parenthesis, one does it and the other undos it except for
    a residual side-effect. OPEN takes a name and returns an I/O channel
    (at the LISP level, an object that can be name an active stream of
    data). CLOSE takes an I/O channel and should return a name to be
    symmetric with OPEN. This would be an opportune time to solve race
    conditions where several users are making different versions of the
    same file at the same time by the trick of writing a temporary file
    and then renaming it during the CLOSE. At CLOSE the version number is
    determined, and at that moment before somebody can create a later
    version the lisp CLOSE function obtains the true filename of the
    particular version we created.

You're right `symmetric' is the wrong adj.  But I still think CLOSE should
return the (closed) stream.  It can't (always) return the truename of the file
associated with the stream, since not all streams are associated with files.

How can one rename a file `during' a CLOSE?  CLOSE should not return until the
stream is really closed (and the file associated with the stream is quiesent).

To obtain the truename of a just closed file, one could write

          (truename (close x))          ; where x is bound to a file stream

since truename will take a stream as an argument.  (Unfortunately,
the CLRM (23.1.2(5)) is only explicit about what truename does
with an `open' stream.)
**********
    From:  Rob MacLachlan <RAM at CMU-CS-C>
    Subject:  Default attributes of copy due to SUBSEQ
    To:  REM at MIT-MC
    cc:  common-lisp at SU-AI, Gall at MIT-MULTICS

        The semantics that I favor (and those implemented by Spice Lisp)
    are that every Common Lisp function which returns an array returns a
    simple array unless the function is make-array or one of the arguments
    is eq to the result.  This has the advantage of being a simple
    specification, and also allows the compiler to do more interesting
    type-inference.

Your semantics are correct:

          Whenever a sequence function must construct and return a
        new vector, it always returns a SIMPLE vector (see
        section 2.5).  Similarly, any strings will be simple
        strings.
                                        CLRM 14.0(last paragraph)

Sorry I didn't see this sooner...
**********
!section  11.7      Nick Gall 85-03-20
!version  Digital Press 1984
!topic    INTERN's effect on an accessible symbol's owner.

          As a verb, to `intern' a symbol in a package means to
        cause the symbol to be interned (sic) in the package if
        it was not already; this function is performed by the
        function INTERN.  If the symbol was previously unowned,
        then the package it is being interned in becomes its
        owner (home package)...
                                        CLRM Section 11.0 (pg. 172)

I interpret this passage in the following way:

;; Current package is USER

* (setf p1 (make-package 'p1 :use '()))
{printed rep. of p1}

* (import 'p1::xyzzy)
T

* (symbol-package 'xyzzy)
{printed rep. of p1}

* (unintern 'xyzzy p1)
T

* (symbol-package 'xyzzy)
NIL

* (intern "XYZZY")
XYZZY
:INTERNAL

* (symbol-package 'xyzzy)
{printed rep. of user}

In other words, INTERN ensures that the symbol that it returns
as its first value has a home package.

Is this interpretation correct?

------------------------------------------------------------
!section  11.7      Nick Gall 85-03-20
!version  Digital Press 1984
!topic    UNINTERNing a shadowing-symbol
UNINTERN:

When uninterning a shadowing symbol (call it foo), UNINTERN
collects all inherited symbols with the same print-name
as foo, including foo (assuming foo was inherited).  If the name
conflict is only between foo and one other symbol, what sense
does it make to signal a name conflict error and give the user a
choice between shadow-importing foo and the other symbol.  If the
user chooses foo, it is no different from aborting from the
error.

In the above case, shouldn't UNINTERN just automatically
shadow-import the other symbol?

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

∂21-Mar-85  0056	RAM@CMU-CS-C.ARPA 	Implementation of MAP, SOME, EVERY, etc...    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 21 Mar 85  00:56:48 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Thu 21 Mar 85 03:56:22-EST
Date: Thu, 21 Mar 1985  03:56 EST
Message-ID: <RAM.12096732510.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   Dave Dyer <DDYER@USC-ISIB.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Implementation of MAP, SOME, EVERY, etc...
In-reply-to: Msg of 20 Mar 1985  23:07-EST from Dave Dyer <DDYER at USC-ISIB.ARPA>


    Our implementation of Map takes the length of every sequence; it
is a page of code.  When every sequence is a list, things are simple.
Life is interesting when mapping over a list, a bit-vector and a
string.

  Rob

∂21-Mar-85  0111	RAM@CMU-CS-C.ARPA 	Follow-up and New Questions    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 21 Mar 85  01:11:02 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Thu 21 Mar 85 04:04:35-EST
Date: Thu, 21 Mar 1985  04:04 EST
Message-ID: <RAM.12096734006.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   Nick Gall <Gall@MIT-MULTICS.ARPA>
Cc:   common-lisp@SU-AI.ARPA, REM@MIT-MC.ARPA
Subject: Follow-up and New Questions
In-reply-to: Msg of 21 Mar 1985  00:49-EST from Nick Gall <Gall at MIT-MULTICS.ARPA>

    From: Nick Gall <Gall at MIT-MULTICS.ARPA>
    To:   common-lisp at SU-AI.ARPA
    Re:   Follow-up and New Questions
    Posted-Date: 21 Mar 85 00:52 EST

      So... there is no way the compiler could ever warn the user that
    they are using a lexical variable with the same name as a constant.
    To put it briefly, I bet you can't show me a piece of Common Lisp code
    that would cause such a warning.

The Spice Lisp compiler would object.  Similarity between special
variables and constants is an implementation detail.  The name names a
constant, the compiler knows this, the compiler complains.

  Rob

∂21-Mar-85  1302	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: Follow-up and New Questions 
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 21 Mar 85  13:02:16 PST
Date:  Thu, 21 Mar 85 15:57 EST
From:  Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject:  Re: Follow-up and New Questions
To:  Rob MacLachlan <RAM@CMU-CS-C.ARPA>
cc:  common-lisp@SU-AI.ARPA
In-Reply-To:  Message of 21 Mar 85 04:04 EST from "Rob MacLachlan"
Message-ID:  <850321205739.178211@MIT-MULTICS.ARPA>

Given a piece of code like

          (defconstant const ...)

          (defun foo ()
            (let ((const 1))
              ...))


I am not saying that the compiler would not object.  I am saying that
WHEN it objected, the message MUST NOT be

          Warning: Binding a LEXICAL variable with the same name as
          a constant.

it SHOULD be

          Error: Attempting to bind a SPECIAL variable defined by
          DEFCONSTANT.

It can't be the first message, because DEFCONSTANT, by doing an implicit

          (proclaim '(special const))

(which pervasively affect BINDINGS and references) FORCES the compiler
to assume that the LET form is binding a SPECIAL variable, not a LEXICAL
variable.  To put it briefly, I was merely arguing that the variable
name `const' in the LET form could not possibly considered a LEXICAL
variable (so how could the compiler warn me about a `lexical'
variable?).

          -- Nick

∂21-Mar-85  1317	FAHLMAN@CMU-CS-C.ARPA 	Follow-up and New Questions
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 21 Mar 85  13:16:47 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 21 Mar 85 16:15:50-EST
Date: Thu, 21 Mar 1985  16:15 EST
Message-ID: <FAHLMAN.12096867089.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Nick Gall <Gall@MIT-MULTICS.ARPA>
Cc:   common-lisp@SU-AI.ARPA, Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Subject: Follow-up and New Questions
In-reply-to: Msg of 21 Mar 1985  15:57-EST from Nick Gall <Gall at MIT-MULTICS.ARPA>


Let's just issue the warning "Attempting to bind a constant, FOO, as a
variable" and let it go at that.  No point in arguing about what kind of
variable it would be if this illegal operation weren't illegal.

-- Scott

∂21-Mar-85  1352	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Lost bet    
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 21 Mar 85  13:52:41 PST
Date:  Thu, 21 Mar 85 16:49 EST
From:  Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject:  Lost bet
To:  common-lisp@SU-AI.ARPA
Message-ID:  <850321214921.734669@MIT-MULTICS.ARPA>

(defun foo ()
   (let ((const 1)) const))

(defconstant const 2)         ;; Compiler should issue a warning about
                              ;; the use of lexical variable const in
                              ;; foo.

(defun bar ()
  (let ((const 2)) const)     ;; Compiler should signal an
                                        ;; error about the binding of a
                                        ;; constant.

I guess I lose my bet.

          -- Nick

∂21-Mar-85  2218	cork%umass-cs.csnet@csnet-relay.arpa 	More on MAP, SOME, EVERY, etc.....   
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 21 Mar 85  22:18:39 PST
Received: from umass-cs by csnet-relay.csnet id ag24346; 22 Mar 85 1:07 EST
Date:     Thu, 21 Mar 85 13:21 EST
From:     Dan Corkill <cork%umass-cs.csnet@csnet-relay.arpa>
To:       common-lisp@su-ai.ARPA
Subject:  More on MAP, SOME, EVERY, etc.....


As I expected, my flame about MAP, SOME, EVERY, etc. has raised some
important issues.....

First, RAM suggests that viewing a circular list as a dotted list
avoids the problem:

>    The definition of a normal list in the Lists chapter is one
> terminated by NIL.  By this definition, a circular list is a dotted
> list.  I believe that there was a decision at one point that functions
> which use lists as sequences (a superset of the sequence functions)
> are allowed to complain about dotted lists.  This is implied by the
> statement that Endp is the canonical list-end predicate.

However, the next sentence from that chapter argues that a circular
list CANNOT be a dotted list:

``A list whose cdr chain is terminated by some non-nil atom is called
a dotted list.''  Clearly, a circular list is not terminated by some
non-NIL atom (is it terminated at all?), and ENDP cannot be used to
detect a circular list.

~~ An aside --- As the CLM is unclear on whether or not a circular is
~~ is an ORDINARY or DOTTED list, I would argue that it is better
~~ viewed as an ORDINARY list.  In a sense a circular list is a list
~~ that shares structure with itself.  Unless destructive functions
~~ are applied to a circular list, it behaves identically to an
~~ infinite list.  Further supporting this position is the observation 
~~ that mapc, mapcar, etc. work with circular list arguments and 
~~ generate errors with dotted (non-circular) list arguments.

*** Back to the original complaint about MAP, SOME, EVERY, etc. ***

Under the premise that a circular list is NOT a dotted list, the 
implementation of MAP, SOME, EVERY, etc. should not care whether
or not an argument sequence is circular or not.  (It should be
up to the user to worry about the effects of any destructive
changes to an arglist.  I suggest that all the following should
be legal:

	(map 'list '+ '(1 2 3) (star 5))  => (6 7 8)

;; (defun star (&REST arglist)
;;    (nconc arglist arglist))

	(some 'char< "string" (star #\x)) => t

	(map 'array '#(2 3 4) (star 5))   => #(7 8 9)

	(replace '(1 2 3 4 5) (star -1) 
           :START1 2 :END1 4))            => (1 2 -1 -1 5)

;; Note that (replace (star -1) '(1 2 3 4 5) :start1 2 :end1 4)
;; should not be expected to produce (-1 -1 1 2 -1 ... ).  But
;; should be undefined as to what it does.


I agree with Dave Dyer that the programmer shouldn't have to know anything
about the lists passed to MAPxxx except that the shortest sequence (if a
list) is a proper list. 

I would hope that even the following would be legal:

	(map 'list '+ '(1 2 3) '(1 2 3 4 5 . 6)) => (2 4 6)


I also agree that the use of LENGTH for lists is a poor implementation
technique, and Dave's admonition against the use of LENGTH in system
functions unless all elements are guaranteed to be inspected is 
reasonable.  

In summary, I believe that implementations of MAP, SOME, EVERY, etc.
using LENGTH do not follow the semantics of the CLM and are inconsistent
with the usual behavior of the traditional list mapping functions.
I strongly suggest that it is the implementations that are incorrect
rather than ambiguity in the semantics and argue that merely changing
the descriptions to explicitly exclude circular lists greatly curtails
the utility of the sequence functions.

Dan Corkill
Cork@UMass

∂25-Mar-85  1831	JLW  	DELFILE, thanks to DWIM 
To:   DHare@SRI-CSL.ARPA
CC:   Common-Lisp@SU-AI.ARPA    

Apart from the failure to ask if you wanted the "correction" GETFILE into
DELFILE, there is also the question of why DELFILE was happy with the
extra argument (in your example, 'SIZE).  Common Lisp programs have the
notion of argument-number checking, and many spurious forms like
(DELFILE 'FOO.BAR 'SIZE) would be rejected at that level.

Argument-number checking isn't completely incompatible with Interlisp --
or at least the use of Interlisp without unwarranted DWIM interference.
All that would be required is the breaking of the rather dubious contract
that *all* functions must have *all* arguments in the category of "optional
and defaulting to NIL".

Totaly leaving aside the question of backwards compatibility with all those
never-changing Interlisp programs dating back to the 1960's, it would be
instructive to know what percentage of current users feel that the current 
situation of *no* argment-number checking is completely satisfactory.   The 
alternative need not require explicity NIL's in calling code, since many 
functions may want some kind of &optional behaviour anyway.


-- JonL --

∂25-Mar-85  1914	JLW  	Excluding some symbols from DO-ALL-SYMBOLS  
To:   Hedrick@RUTGERS.ARPA
CC:   Common-Lisp@SU-AI.ARPA  

Re your message of 4-Mar-85 19:05 EST

I'm a little bit apprehensive about having two "functions" to iterater over
"all the symbols of interest"  -- How about instead of introducing the second
one [do-most-symbols] we simply introduce a new global variable called, say,
    *do-all-symbols-exclusions*
This list would merely exclude some of the packages which would otherwise
be the output of list-all-packages.  This way, not only could the compiler
internal symbols be omitted, but any other package which a user develops
could also be, temporarily or permanently, excluded.  I'm currently thinking
that this facility would not exclude the external symbols of those packages.

-- JonL --

∂26-Mar-85  0312	JLW  	Previous note about DELFILE/DWIM  
To:   common-lisp@SU-AI.ARPA

My apologies for this note getting onto the mailing list -- it was not
intended for Common Lisp, but rather for Bug-1100.  The spazz was partly
my fault, and partly a "gift" from the wonderful featurfulness of the
su-ai editor/mailer.

-- JonL --

∂27-Mar-85  1240	eak@angband 	multiple-value-setq   
Received: from S1-B.ARPA by SU-AI.ARPA with TCP; 27 Mar 85  12:40:51 PST
Received: by angband.ARPA id AA00677; Wed, 27 Mar 85 11:14:11 pst
	id AA00677; Wed, 27 Mar 85 11:14:11 pst
Date: Wed, 27 Mar 85 11:14:11 pst
From: Earl Killian <eak@angband>
Message-Id: <8503271914.AA00677@angband.ARPA>
To: common-lisp@su-ai.ARPA
Subject: multiple-value-setq

Is this really multiple-value-setf?  I.e. can the list be a list of
places or just a list of variables?

∂27-Mar-85  1241	eak@angband 	values-list 
Received: from S1-B.ARPA by SU-AI.ARPA with TCP; 27 Mar 85  12:41:03 PST
Received: by angband.ARPA id AA00664; Wed, 27 Mar 85 11:10:55 pst
	id AA00664; Wed, 27 Mar 85 11:10:55 pst
Date: Wed, 27 Mar 85 11:10:55 pst
From: Earl Killian <eak@angband>
Message-Id: <8503271910.AA00664@angband.ARPA>
To: common-lisp@su-ai.ARPA
Subject: values-list

A useful extension to values-list would be to make it take multiple
arguments the way apply does, i.e. all but the last are values to
return and the last is a list of further values to return.

∂27-Mar-85  1807	Moon@SCRC-STONY-BROOK.ARPA 	do-xxx-symbols   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 27 Mar 85  13:35:07 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 204359; Wed 27-Mar-85 16:05:30-EST
Date: Wed, 27 Mar 85 16:06 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: do-xxx-symbols
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>,
    Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>,
    Charles Hedrick <HEDRICK@RUTGERS.ARPA>
cc: common-lisp@SU-AI.ARPA, Moon@SCRC-STONY-BROOK.ARPA
In-Reply-To: <RAM.12092370210.BABYL@CMU-CS-C.ARPA>,
             <FAHLMAN.12092383554.BABYL@CMU-CS-C.ARPA>,
             The message of 4 Mar 85 19:05-EST from Charles Hedrick <HEDRICK@RUTGERS.ARPA>,
             The message of 4 Mar 85 21:50-EST from Charles Hedrick <HEDRICK@RUTGERS.ARPA>,
             <FAHLMAN.12092488741.BABYL@CMU-CS-C.ARPA>,
             The message of 4 Mar 85 23:34-EST from Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Message-ID: <850327160624.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comment: Message remailed after delay caused by distribution list error.

Due to some kind of mail problem I didn't see this conversation until today.

We take DO-SYMBOLS to mean to iterate over all symbols accessible to this package,
including ones that are inherited from other packages.  That seems like the most
reasonable interpretation of what the manual says.  I agree with Scott that the authors
of the manual never imagined that other interpretations were possible.

We provide DO-LOCAL-SYMBOLS as an extension.  It iterates over only symbols present
in the specified package.

Our DO-SYMBOLS has the usual bug with shadowed symbols: its iteration includes symbols
that would have been inherited had they not been shadowed.  I think it's clear that
this is a bug and not an allowable interpretation of the manual.

Our DO-SYMBOLS has the usual bug with unnecessarily imported or exported
symbols: its iteration sees a symbol more than once if that symbol is imported
even though it would have been inherited, or is exported from two used packages.
Perhaps this case is rare enough in practice, and difficult enough to test for,
that the manual should be changed to say that a symbol can be seen more than once,
as Scott suggested.

Of course, certain implementations of packages (ones that hash symbols
redundantly in every package that inherits them, so that INTERN need do only
a single hash lookup regardless of the length of the use-list) would never
encounter such bugs.  Perhaps the language should be based on such a simple
implementation as a standard, and other implementations that try to save
space are responsible for not deviating from that standard.  Opinions?

∂27-Mar-85  1808	Moon@SCRC-STONY-BROOK.ARPA 	Implementation of MAP, SOME, EVERY, etc...
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 27 Mar 85  13:39:50 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 204367; Wed 27-Mar-85 16:16:13-EST
Date: Wed, 27 Mar 85 16:17 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Implementation of MAP, SOME, EVERY, etc...
To: Dan Corkill <cork%umass-cs.csnet@CSNET-RELAY.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 19 Mar 85 11:58-EST from Dan Corkill <cork%umass-cs.csnet@csnet-relay.arpa>
Message-ID: <850327161712.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comment: Message remailed after delay caused by distribution list error.

    Date:     Tue, 19 Mar 85 11:58 EST
    From:     Dan Corkill <cork%umass-cs.csnet@csnet-relay.arpa>


    There is an easily made implementation error in MAP, SOME, EVERY, etc.
    The published semantics indicate that these functions use the length of
    the shortest argument sequence to determine how many iterations to 
    perform (and in this way parallel the semantics of mapc, mapcar, etc.).

    Thus it would appear that:

	    (map 'list '+ '(1 2 3) (star 2))

    where star builds a circular list of its argument should be legal and
    return => (3 4 5).

    Implementations that use length to check the length of argument sequences
    will break on such a call.

The Common Lisp LENGTH function returns NIL when given a circular list.

∂27-Mar-85  1818	FAHLMAN@CMU-CS-C.ARPA 	multiple-value-setq   
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Mar 85  16:40:16 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 27 Mar 85 19:39:45-EST
Date: Wed, 27 Mar 1985  19:39 EST
Message-ID: <FAHLMAN.12098477115.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Earl Killian <eak@S1-B.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: multiple-value-setq
In-reply-to: Msg of 27 Mar 1985  14:14-EST from Earl Killian <eak at angband>
Comment: Remailed after delay caused by distribution list error at SU-AI.


    Is this really multiple-value-setf?  I.e. can the list be a list of
    places or just a list of variables?

Multiple-Value-Setq definitely does not take SETF-style place names.  I
think that the manual is quite clear on this.  Whether there should be
an M-V-SETF is another issue, but I don't think there's much demand for
this.  I've seen very few uses of M-V-SETQ, as compared with M-V-BIND.

-- Scott

∂27-Mar-85  1820	FAHLMAN@CMU-CS-C.ARPA 	do-xxx-symbols   
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Mar 85  14:13:39 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 27 Mar 85 17:12:29-EST
Date: Wed, 27 Mar 1985  17:12 EST
Message-ID: <FAHLMAN.12098450245.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: do-xxx-symbols
In-reply-to: Msg of 27 Mar 1985  16:06-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
Comment: Remailed after delay caused by distribution list error at SU-AI.


I thought that you had been unusually quiet of late.

    Of course, certain implementations of packages (ones that hash symbols
    redundantly in every package that inherits them, so that INTERN need do only
    a single hash lookup regardless of the length of the use-list) would never
    encounter such bugs.  Perhaps the language should be based on such a simple
    implementation as a standard, and other implementations that try to save
    space are responsible for not deviating from that standard.  Opinions?

I think that requiring adherence to a model that is conceptually simple
but that imposes a very heavy (and in my opinion, unacceptable) cost in
space is the wrong move here, unless you can demonstrate some reasonable
way of adhering to that model without incurring these costs.  To just
asy "it's the implementor's problem" is a good way to either make the
language unusable because of the adherence to impractical models or to
get the implementors to decide to deviate from the standard rather than
pay these costs.

Yes, I know we've done it before in this language, but in a couple of
cases we've come to regret it.

-- Scott

∂27-Mar-85  1820	FAHLMAN@CMU-CS-C.ARPA 	values-list 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Mar 85  16:51:22 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 27 Mar 85 19:50:43-EST
Date: Wed, 27 Mar 1985  19:50 EST
Message-ID: <FAHLMAN.12098479109.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Earl Killian <eak@S1-B.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: values-list
In-reply-to: Msg of 27 Mar 1985  14:10-EST from Earl Killian <eak at angband>
Comment: Remailed after delay caused by distribution list error at SU-AI.


    A useful extension to values-list would be to make it take multiple
    arguments the way apply does, i.e. all but the last are values to
    return and the last is a list of further values to return.

You can easily get the effect you want with a macro, as long as you're
willing to cons all the returned values into a list at some point.  I
guess your point is that sometimes you don't know how many values to
expect, but would like to handle the first few without consing via
values-list.  Multiple-Value-Call with a &rest arg gives you this
effect, but forces you to do a function call that might be superfluous.
So there is a niche for your proposed mechanism, but I don't think it's
a common enough situation to worry about.  The only cases I've seen
where you don't know how many args are coming back would not be bothered
by the overhead of the function call or the values-list; in the tense
cases, you generally how many args to expect.

-- Scott

∂27-Mar-85  2020	FAHLMAN@CMU-CS-C.ARPA 	Implementation of MAP, SOME, EVERY, etc...
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Mar 85  20:20:08 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 27 Mar 85 23:19:20-EST
Date: Wed, 27 Mar 1985  23:19 EST
Message-ID: <FAHLMAN.12098517085.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Implementation of MAP, SOME, EVERY, etc...
In-reply-to: Msg of 27 Mar 1985  16:17-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>


Moon claims:

    The Common Lisp LENGTH function returns NIL when given a circular list.

I disagree.  On page 265 of the aluminum edition, we find the following
quote:

"LIST-LENGTH differs from LENGTH when the list is circular; LENGTH may
 fail to return, whereas LIST-LENGTH will return NIL."

The feeling was that LENGTH was used often, and we didn't want to
require that it run more slowly on all lists just to accommodate the
rare case of a circular list.

-- Scott

∂28-Mar-85  0553	Moon@SCRC-STONY-BROOK.ARPA 	[Gall: Bug Report]    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Mar 85  05:52:50 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 204544; Wed 27-Mar-85 20:08:58-EST
Date: Wed, 27 Mar 85 20:09 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: [Gall: Bug Report]
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12096404394.BABYL@CMU-CS-C.ARPA>,
             The message of 19 Mar 85 21:53-EST from Fahlman at CMU-CS-C,
             <FAHLMAN.12096404394.BABYL@CMU-CS-C.ARPA>,
             The message of 21 Mar 85 00:49-EST from Gall@MIT-MULTICS.ARPA,
             <850321054958.626398@MIT-MULTICS.ARPA>
Message-ID: <850327200955.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

Here are some comments on -portions- of the two long messages from Nick Gall.

    !section  9.1(6)    Nick Gall 85-03-19
    !version  Digital Press 1984
    !topic    Pervasiveness of declarations over FLET and LABELS

    Example:
	      (defun the-many-function-names-foo (x)
		(declare (inline foo))
		(foo x)			; First call of FOO
		(flet ((foo (y z) (zap z y)))
		  (foo x x))		; Second call of FOO
		(foo x))		; Third call of FOO
    ....
    Declarations concerning function names should be treated as
    special variable declarartions are:  references are pervasively
    affected, but not bindings.

Agreed.  There are a number of areas in the language where the
implications of adding FLET and LABELS (thus adding local function
definitions) were not immediately obvious and therefore were not
reflected in other parts of the manual.

    !section  9.1(12)   Nick Gall 85-03-19
    !version  Digital Press 1984
    !topic    Non-Top-Level use of PROCLAIM

    Can PROCLAIM be used, other than at top-level?  Since DEFVAR,
    etc., are proclamations and can be used at other than top-level,
    the answer to this question seems to be `yes'.

Agreed.

    Is PROCLAIM a `declaration', i.e., must it appear only where a
    declaration is allowed?  Since it is allowed at top-level (unlike 
    DECLARE), and it is a function, and since the other proclaiming
    forms (e.g. DEFVAR, etc.) could not be considered declarations
    (since they perform evaluation and assignment), the answer must
    be no.

Agreed.

    Then what is the effect of using PROCLAIM (or one one the other
    proclaiming forms) in the middle of a function?  For example:

	      (defun foo (a) (zap a) (proclaim '(special a)) (zark a))

    Does the first reference to A refer to the local binding?  Does
    the second reference refer to the global?

PROCLAIM is merely a function, and has effect when it is called, not
when a call to it is compiled.  Your example might be rewritten as

  (defun foo (a)
    (zap a)
    (eval-when (compile)
      (proclaim '(special a)))
    (zark a))

were EVAL-WHEN permitted inside a function body (it is not; see p.66).
Of course you could write a macro that evaluates the PROCLAIM at macro
expansion time.  If you did so, you could properly be castigated for
using incomprehensible programming style, and I presume your program
would execute differently in different Common Lisp compilers and
interpreters.

    Some mention of the effects of the non-top-level use of PROCLAIM
    and the other proclaiming forms should be made.

On p.66 it says that DEFVAR is not allowed elsewhere than top-level.
PROCLAIM is the only function (rather than special form) that makes
declarations, and presumably the declarations it makes when it is
called take effect "immediately", but the exact definition of "immediately"
might be implementation-dependent.  For example, it is implementation-
dependent whether PROCLAIM affects interpreted functions that have already
been defined.

    -----------------------------------------------------------------
    !section  7.5(14)   Nick Gall 85-03-19
    !version  Digital Press 1984
    !topic    Scope and Extent of local function names

    NOTE: See 9.2 (ftype, function, inline).

    Example:
	      (DEFUN CREATE-MAKEP (MAKE)
		 (FLET ((CAR (SYMBOL) (GET SYMBOL 'AUTOMOBILE)))
		    #'(LAMBDA (OWNER) (EQ MAKE (CAR OWNER)))))

	      (SETQ FOO (CREATE-MAKEP 'HONDA))
	      (FUNCALL FOO 'BILL) => ?????

    Question: What does CAR refer to when it is used in the closure
			returned by CREATE-MAKEP?  I.E., What is the scope and
			extent of the binding of a local function name to a
			functional object?

    Section 7.1(1) states that "There are two spaces of variables in
    Common Lisp, in effect: ordinary variables and function names." 
    And the function name binding control structures appear in the
    section entitled "Establishing New Variable Bindings".

Lexical function name bindings and lexical variable name bindings are
treated identically.  This should, of course, be discussed in chapter 3.
See above comment about the implications of FLET and LABELS not having
been fully thought out and reflected in the manual.

    I suggest that Common Lisp go all the way, and allow a
    SPECIAL-FUNCTION-NAME declaration that would be analogous to the
    SPECIAL declaration for "ordinary" variables.

    Such a concept would make the idea of
    ordinary-variable/function-name binding and assignment much more
    consistent.

As I recall this was considered and rejected on the basis that it would
be confusing and wouldn't give any real increase in expressive power
(since FUNCALL of a special variable could be used).  I agree with that
decision, even though our implementation has always had the feature.
The only place where we use it is in a crock that could just as well be
done some other way.

    -----------------------------------------------------------------
    !section  10.3(9)   Nick Gall 85-03-19
    !version  Digital Press 1984
    !topic    Which  bindings are copied by COPY-SYMBOL?

	      "the initial value and function-definition of the new symbol
    will be the same as those of SYM..."

	      Does this mean that the (dynamic) value of the variable
    referred to by SYM, at the point where COPY-SYMBOL symbol is
    invoked, is copied?   Or, does it mean that the `initial', i.e.
    global value of the special variable named by SYM is copied?
    Although the wording seems to suggest the latter, it should be
    made clearer.

The word "initial" was meant to refer to the new symbol, not the old
symbol, I believe.  Probably no one realized the English could be
regarded as ambiguous.

    The same questions and suggestion applies to the
    function-definition copied by COPY-SYMBOL.

    -----------------------------------------------------------------
    !section  15.5(8)   Nick Gall 85-03-19
    !version  Digital Press 1984
    !topic    Is (TAILP NIL list) true or false for every list?

False.

By the way, the index entry for TAILP contains a typographical error and
furthermore the function is documented in the wrong section (it's hard
to see a justification for regarding it as an operation on sets).

    "...TAILP is true if (NTHCDR n list) is sublist, for some value
    of N."  According to this definition NIL is a sublist of every
    list, since the (NTHCDR (LENGTH list) list) is NIL for every
    LIST.

Yes, this side comment in the text would better have been omitted.

    -----------------------------------------------------------------
    !section  20.1(7)   Nick Gall 85-03-19
    !version  Digital Press 1984
    !topic    Is *APPLYHOOK* funcalled for special forms?

    "The variable *APPLYHOOK* ... is used when a function is about to
    be applied to arguments."  Does `function' refer to a functional
    object which is in fact a function (i.e., its args. are evaled
    before it is called), or does it refer to any functional object
    (e.g., `special' functional objects)?

Special forms are excluded.

    Later in the paragraph, it is stated that, 

	      The apply hook function is used only for application of
	ordinary functions within eval.  It is not used for
	applications via apply, or funcall, for applications by such
	functions as map or reduce, or for invocation of
	macro-expansion functions...

    This paragraph does not really address the "application of
    ordinary functions within eval" but rather the "ordinary
    application of functions by eval."  

I disagree (but this may be an ambiguity of English).

					Also it does not clarify the
    action taken for special forms.

Indeed, it ought to say something like "linkage from EVAL to special forms."
Part of the problem is that there is no way, in Common Lisp, to describe
the intercommunication between EVAL and special forms, since it is
implementation-dependent and the language provides no way for the user
to add new special forms.  This is not a deficiency in the language (in
my opinion), just something that makes it hard to fit special forms into
that paragraph of documentation.

    -----------------------------------------------------------------
    !section  20.1(last-1)        Nick Gall 85-03-19
    !version  Digital Press 1984
    !topic    Is nil declared by defconstant?

	      ...all constant symbols declared by DEFCONSTANT, such as NIL,
	T, and PI.

    If NIL is declared by DEFCONSTANT then it can legally be
    redefined according to section 5.1.2(last):

	      Constant symbols defined by DEFCONSTANT ... may be redefined,
	if necessary, by using DEFCONSTANT again[].

    Is such an interpretation correct?

I do not believe that system-supplied constants can legally be redefined.

    -----------------------------------------------------------------
    !section  4.8(1)    Nick Gall 85-03-19
    !version  Digital Press 1984
    !topic    The meaning of the word `convert'

    Does coerce `convert' (i.e., change the type bits) and return the
    original object (or the pointer if typed pointers are supported)
    when possible (e.g., coercing a string to an array of
    (unsigned-byte 8) in some implementations); or does coerce ALWAYS
    create and return a new `equivalent' object; or does the Common
    Lisp spec. not define this?

Common Lisp does not specify sharing or non-sharing of storage between
the argument and result of COERCE.  I don't see how it could, since this
is necessarily very implementation-dependent.  But the documentation
could be clearer.

    !section  11.7      Nick Gall 85-03-20
    !version  Digital Press 1984
    !topic    INTERN's effect on an accessible symbol's owner.

	      As a verb, to `intern' a symbol in a package means to
	    cause the symbol to be interned (sic) in the package if
	    it was not already; this function is performed by the
	    function INTERN.  If the symbol was previously unowned,
	    then the package it is being interned in becomes its
	    owner (home package)...
					    CLRM Section 11.0 (pg. 172)

    I interpret this passage in the following way:

    ;; Current package is USER

    * (setf p1 (make-package 'p1 :use '()))
    {printed rep. of p1}

    * (import 'p1::xyzzy)
    T

    * (symbol-package 'xyzzy)
    {printed rep. of p1}

    * (unintern 'xyzzy p1)
    T

    * (symbol-package 'xyzzy)
    NIL

    * (intern "XYZZY")
    XYZZY
    :INTERNAL

    * (symbol-package 'xyzzy)
    {printed rep. of user}

    In other words, INTERN ensures that the symbol that it returns
    as its first value has a home package.

    Is this interpretation correct?

I think the mention of accessible but unowned symbols on page 172 (in the
discussion of home packages) shoots down your example.  The result of the
last call to SYMBOL-PACKAGE is probably undefined.

    ------------------------------------------------------------
    !section  11.7      Nick Gall 85-03-20
    !version  Digital Press 1984
    !topic    UNINTERNing a shadowing-symbol
    UNINTERN:

    When uninterning a shadowing symbol (call it foo), UNINTERN
    collects all inherited symbols with the same print-name
    as foo, including foo (assuming foo was inherited).  If the name
    conflict is only between foo and one other symbol, what sense
    does it make to signal a name conflict error and give the user a
    choice between shadow-importing foo and the other symbol.  If the
    user chooses foo, it is no different from aborting from the
    error.

    In the above case, shouldn't UNINTERN just automatically
    shadow-import the other symbol?

Surely it is a bad idea to guess the user's intent in this pathological
case, rather than asking.  I suppose it would be legal for a debugger
not to offer the redundant option of shadowing-importing foo again,
although that doesn't seem like a feature of great importance.


I hope someone is listening to comments on unclarities in the manual,
such as Gall's, and that someday a revised and improved manual will
be issued.  The Common Lisp community is hardly in possession of the
same resources as the Ada community, so I don't think we can realistically
expect as precise a specification as Ada enjoys.

∂28-Mar-85  1036	Moon@SCRC-STONY-BROOK.ARPA 	Implementation of MAP, SOME, EVERY, etc...
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Mar 85  10:35:58 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 204967; Thu 28-Mar-85 13:18:36-EST
Date: Thu, 28 Mar 85 13:19 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Implementation of MAP, SOME, EVERY, etc...
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12098517085.BABYL@CMU-CS-C.ARPA>
Message-ID: <850328131955.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 27 Mar 1985  23:19 EST
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>


    Moon claims:

	The Common Lisp LENGTH function returns NIL when given a circular list.

    I disagree.  On page 265 of the aluminum edition, we find the following
    quote:

    "LIST-LENGTH differs from LENGTH when the list is circular; LENGTH may
     fail to return, whereas LIST-LENGTH will return NIL."

    The feeling was that LENGTH was used often, and we didn't want to
    require that it run more slowly on all lists just to accommodate the
    rare case of a circular list.

My mistake.  LENGTH used to check for circular lists, and when that feature
was removed from the language we saw no reason to remove it from our
implementation.  I foolishly relied on memory and trying an example,
rather than checking the manual.

∂28-Mar-85  1116	FAHLMAN@CMU-CS-C.ARPA 	values-list 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 28 Mar 85  11:16:17 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 28 Mar 85 14:15:35-EST
Date: Thu, 28 Mar 1985  14:15 EST
Message-ID: <FAHLMAN.12098680245.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA, Earl Killian <eak@S1-B.ARPA>
Subject: values-list
In-reply-to: Msg of 28 Mar 1985  13:36-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>


Ooops, my reply was indeed about Multiple-Value-List.  If EAK did indeed
mean that he wanted Values-List to take args like apply, I agree with
Moon that just using apply here solves the problem without adding any
extra hair to the language.

This week's confusion score stands at Moon 1, Fahlman 1.  Look's like
we're headed for overtime to break the tie.

-- Scott

∂28-Mar-85  1126	Moon@SCRC-STONY-BROOK.ARPA 	values-list 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Mar 85  11:26:13 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 204994; Thu 28-Mar-85 13:35:14-EST
Date: Thu, 28 Mar 85 13:36 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: values-list
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: Earl Killian <eak@S1-B.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12098479109.BABYL@CMU-CS-C.ARPA>
Message-ID: <850328133629.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 27 Mar 1985  19:50 EST
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

        From: EAK
	A useful extension to values-list would be to make it take multiple
	arguments the way apply does, i.e. all but the last are values to
	return and the last is a list of further values to return.

What's wrong with (APPLY #'VALUES-LIST A B C L)?

    You can easily get the effect you want with a macro, as long as you're
    willing to cons all the returned values into a list at some point.  I
    guess your point is that sometimes you don't know how many values to
    expect, but would like to handle the first few without consing via
    values-list.  Multiple-Value-Call with a &rest arg gives you this
    effect, but forces you to do a function call that might be superfluous.
    So there is a niche for your proposed mechanism, but I don't think it's
    a common enough situation to worry about.  The only cases I've seen
    where you don't know how many args are coming back would not be bothered
    by the overhead of the function call or the values-list; in the tense
    cases, you generally how many args to expect.

This discussion appears to be about MULTIPLE-VALUE-LIST.


∂28-Mar-85  1154	EAK@MIT-MC 	values-list  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 28 Mar 85  11:51:48 PST
Date: 28 March 1985 14:52-EST
From: Earl A. Killian <EAK @ MIT-MC>
Subject:  values-list
To: Moon @ SCRC-STONY-BROOK
cc: common-lisp @ SU-AI

    Date: Thu, 28 Mar 85 13:36 EST
    From: David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>

    What's wrong with (APPLY #'VALUES-LIST A B C L)?

You mean (APPLY #'VALUES A B C L).  This is actually where the
idea comes from.

I don't really care about this; I was just observing that an
obvious extension exists.  If I wanted to be argumentative my
reply would be
	"The same thing that's wrong with (APPLY #'VALUES L)
	 that caused (VALUES-LIST L) to be added to the language."

∂28-Mar-85  1158	RWK@SCRC-STONY-BROOK.ARPA 	Clearly non-controversial   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Mar 85  11:58:17 PST
Received: from SCRC-CROW by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 205049; Thu 28-Mar-85 14:32:07-EST
Date: Thu, 28 Mar 85 14:32 EST
From: Robert W. Kerns <RWK@SCRC-STONY-BROOK.ARPA>
Subject: Clearly non-controversial
To: brown@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 6 Feb 85 12:52-EST from brown at DEC-HUDSON
Message-ID: <850328143248.2.RWK@CROW.SCRC.Symbolics.COM>

    Date: Wed, 06 Feb 85 12:52:15 EST
    From: brown@DEC-HUDSON

     DELETE-SETF-METHOD access-fn				[function]
      Removes the update form associated with the symbol access-fn.
      The access function can no longer be used as generalized
      variable.
Either FMAKUNBOUND should call this, or maybe it should just
be a part of FMAKUNBOUND.

     HASH-TABLE-REHASH-SIZE  hash-table			[function]
     HASH-TABLE-REHASH-TRESHOLD  hash-table			[function]
Should these two be SETFable?

     HASH-TABLE-SIZE  hash-table				[function]
     HASH-TABLE-TEST  hash-table				[function]
      These functions return the values that were specified when
      the hash-table was created.
      
    (This list used to contain TERMINALP which returned T if its
     argument (string, pathname, etc.) was an "interactive terminal".
     I think this function would be useful, but decided I was unable
     to define what a terminal is, so removed it.)

How about "a terminal is something that has a keyboard attached,
with a good chance of having a user attached to the keyboard, and
able to send characters back on any stream"?  I'd suggest just
defining it to work on streams.

    -Gary Brown


∂28-Mar-85  1433	DLW@SCRC-STONY-BROOK.ARPA 	[Gall: Bug Report]
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Mar 85  14:33:20 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 205213; Thu 28-Mar-85 16:54:47-EST
Date: Thu, 28 Mar 85 16:56 EST
From: Daniel L. Weinreb <DLW@SCRC-STONY-BROOK.ARPA>
Subject: [Gall: Bug Report]
To: Moon@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <850327200955.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <850328165608.0.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Wed, 27 Mar 85 20:09 EST
    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
    were EVAL-WHEN permitted inside a function body (it is not; see p.66).

    ...

    On p.66 it says that DEFVAR is not allowed elsewhere than top-level.

Are we reading the same page 66?  Mine says "It is not illegal to use
these forms at other than top level, but whether it is meaningful to do
so depends on context."  To my ears, this is sort of like saying
that integers can be of any precision, but after they get larger
than the fixnum limit, their behavior depends on context.

Also, note the wording in the description of DEFUN on page 67: "Because
DEFUN forms normally appear at top level, this is normally the null
lexical environment."  This wording strongly suggests that DEFUN might
sometimes not be at top level, and the environment is not necessarily
always null.  After all, if DEFUN were only allowed at top-level, why
bother with the "normally" qualifiers?  But you never find out anything
further.

I'm not advocating either side right at the moment; my point is that the
manual is ambiguous (one might even say "coy") on this subject.

∂28-Mar-85  1434	Moon@SCRC-STONY-BROOK.ARPA 	values-list 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Mar 85  14:34:38 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 205160; Thu 28-Mar-85 16:13:54-EST
Date: Thu, 28 Mar 85 16:15 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: values-list
To: Earl A. Killian <EAK@MIT-MC.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 28 Mar 85 14:52-EST from Earl A. Killian <EAK at MIT-MC>
Message-ID: <850328161516.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 28 March 1985 14:52-EST
    From: Earl A. Killian <EAK @ MIT-MC>

	Date: Thu, 28 Mar 85 13:36 EST
	From: David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>

	What's wrong with (APPLY #'VALUES-LIST A B C L)?

    You mean (APPLY #'VALUES A B C L).  This is actually where the
    idea comes from.

You're right.

    I don't really care about this; I was just observing that an
    obvious extension exists.  If I wanted to be argumentative my
    reply would be
	    "The same thing that's wrong with (APPLY #'VALUES L)
	     that caused (VALUES-LIST L) to be added to the language."

Indeed, I wouldn't care to defend the presence of VALUES-LIST in the language.

∂28-Mar-85  1621	Moon@SCRC-STONY-BROOK.ARPA 	[Gall: Bug Report]    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Mar 85  16:21:40 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 205314; Thu 28-Mar-85 19:04:52-EST
Date: Thu, 28 Mar 85 19:06 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: [Gall: Bug Report]
To: Daniel L. Weinreb <DLW@SCRC-STONY-BROOK.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850328165608.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-ID: <850328190615.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 28 Mar 85 16:56 EST
    From: Daniel L. Weinreb <DLW@SCRC-STONY-BROOK.ARPA>

	Date: Wed, 27 Mar 85 20:09 EST
	From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
	were EVAL-WHEN permitted inside a function body (it is not; see p.66).

	...

	On p.66 it says that DEFVAR is not allowed elsewhere than top-level.

    Are we reading the same page 66?  Mine says "It is not illegal to use
    these forms at other than top level, but whether it is meaningful to do
    so depends on context."  To my ears, this is sort of like saying
    that integers can be of any precision, but after they get larger
    than the fixnum limit, their behavior depends on context.

In my opinion, saying that is not meaningful is tantamount to saying that
it is not allowed.  The phrase I should have used was not "not allowed",
but "not defined by standard Common Lisp".

    Also, note the wording in the description of DEFUN on page 67: "Because
    DEFUN forms normally appear at top level, this is normally the null
    lexical environment."  This wording strongly suggests that DEFUN might
    sometimes not be at top level, and the environment is not necessarily
    always null.  After all, if DEFUN were only allowed at top-level, why
    bother with the "normally" qualifiers?  But you never find out anything
    further.

    I'm not advocating either side right at the moment; my point is that the
    manual is ambiguous (one might even say "coy") on this subject.

Indeed.

∂28-Mar-85  2216	cork%umass-cs.csnet@csnet-relay.arpa 	More on MAP, SOME, EVERY, etc.....   
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 28 Mar 85  22:16:49 PST
Received: from umass-cs by csnet-relay.csnet id ab02829; 29 Mar 85 1:02 EST
Date:     Thu, 28 Mar 85 09:26 EST
From:     Dan Corkill <cork%umass-cs.csnet@csnet-relay.arpa>
To:       common-lisp@su-ai.ARPA
Subject:  More on MAP, SOME, EVERY, etc.....


I'm not certain this made it through the network.....

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


As I expected, my flame about MAP, SOME, EVERY, etc. has raised some
important issues.....

First, RAM suggests that viewing a circular list as a dotted list
avoids the problem:

>    The definition of a normal list in the Lists chapter is one
> terminated by NIL.  By this definition, a circular list is a dotted
> list.  I believe that there was a decision at one point that functions
> which use lists as sequences (a superset of the sequence functions)
> are allowed to complain about dotted lists.  This is implied by the
> statement that Endp is the canonical list-end predicate.

However, the next sentence from that chapter argues that a circular
list CANNOT be a dotted list:

``A list whose cdr chain is terminated by some non-nil atom is called
a dotted list.''  Clearly, a circular list is not terminated by some
non-NIL atom (is it terminated at all?), and ENDP cannot be used to
detect a circular list.

~~ An aside --- As the CLM is unclear on whether or not a circular is
~~ is an ORDINARY or DOTTED list, I would argue that it is better
~~ viewed as an ORDINARY list.  In a sense a circular list is a list
~~ that shares structure with itself.  Unless destructive functions
~~ are applied to a circular list, it behaves identically to an
~~ infinite list.  Further supporting this position is the observation 
~~ that mapc, mapcar, etc. work with circular list arguments and 
~~ generate errors with dotted (non-circular) list arguments.

*** Back to the original complaint about MAP, SOME, EVERY, etc. ***

Under the premise that a circular list is NOT a dotted list, the 
implementation of MAP, SOME, EVERY, etc. should not care whether
or not an argument sequence is circular or not.  (It should be
up to the user to worry about the effects of any destructive
changes to an arglist.  I suggest that all the following should
be legal:

	(map 'list '+ '(1 2 3) (star 5))  => (6 7 8)

;; (defun star (&REST arglist)
;;    (nconc arglist arglist))

	(some 'char< "string" (star #\x)) => t

	(map 'array '#(2 3 4) (star 5))   => #(7 8 9)

	(replace '(1 2 3 4 5) (star -1) 
           :START1 2 :END1 4))            => (1 2 -1 -1 5)

;; Note that (replace (star -1) '(1 2 3 4 5) :start1 2 :end1 4)
;; should not be expected to produce (-1 -1 1 2 -1 ... ).  But
;; should be undefined as to what it does.


I agree with Dave Dyer that the programmer shouldn't have to know anything
about the lists passed to MAPxxx except that the shortest sequence (if a
list) is a proper list. 

I would hope that even the following would be legal:

	(map 'list '+ '(1 2 3) '(1 2 3 4 5 . 6)) => (2 4 6)


I also agree that the use of LENGTH for lists is a poor implementation
technique, and Dave's admonition against the use of LENGTH in system
functions unless all elements are guaranteed to be inspected is 
reasonable.  

In summary, I believe that implementations of MAP, SOME, EVERY, etc.
using LENGTH do not follow the semantics of the CLM and are inconsistent
with the usual behavior of the traditional list mapping functions.
I strongly suggest that it is the implementations that are incorrect
rather than ambiguity in the semantics and argue that merely changing
the descriptions to explicitly exclude circular lists greatly curtails
the utility of the sequence functions.

Dan Corkill
Cork@UMass

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

∂29-Mar-85  2041	TIM@MIT-MC 	multiple-value-setf    
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 29 Mar 85  20:41:27 PST
Date: 29 March 1985 23:41-EST
From: Tim McNerney <TIM @ MIT-MC>
Subject:  multiple-value-setf
To: Fahlman @ CMU-CS-C
cc: common-lisp @ SU-AI, eak @ S1-B
In-reply-to: Msg of Wed 27 Mar 1985  19:39 EST from Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>

Granted that it is relatively easy to write a multiple-value-setf,
it probably should have been included in the language to begin
with.  I had several uses for it and was forced to write my own.

∂01-Apr-85  0118	masinter.pa@Xerox.ARPA 	Re: Arg count checking    
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 1 Apr 85  01:18:21 PST
Received: from Semillon.ms by ArpaGateway.ms ; 01 APR 85 01:18:18 PST
Date: 1 Apr 85 01:00 PST
From: masinter.pa@XEROX.ARPA
Subject: Re: Arg count checking
In-reply-to: various messages
To: bug-1100@SUMEX-AIM.ARPA
cc: common-lisp@SU-AI.ARPA

The only places I've seen extra args used in situations where it isn't
(clearly) a bug is in code that is dealing with two different
implementations.

Implementation A has a function FOO with args A B and an optional C.

Implementation B has a function FOO with args A B. No optional.

You can then write a client that will work with both implementations, as
long as it knows that some implementations may ignore the last argument.
(Most of the cases I've seen have been ones where its been a "flag",
e.g. implementation A has a "slow" and a "fast" case, and you can say
(FOO 1 2 T) and it means do (FOO 1 2) and, if you care, do it fast
rather than slow..., although there have been other uses.)

I can think of about a half-dozen cases of this, off hand; e.g., the
"standard system" has a vanilla WHEREIS, but there's a super-WHEREIS
that takes lots of args, and it redefines WHEREIS to have lots of
optionals.  

The odd thing is that I can't think of a really clean way of doing
this-- having variant argument lists in different implementations -- I
suppose you'd have to write a &REST in every implementation that didn't
have the args.

Another place this arises are in mapping functions which take functional
arguments; they apply the functional arg; sometimes they pass extra
arguments which of course the functional is free to ignore. 

All of these are instances where the CALLER knows the args are optional.

I can imagine (not very seriously) a separate syntax for that, e.g., put
the &OPTIONAL on the caller rather than the callee:

(FOO 1 2 &OPTIONAL T) which says to call FOO with 2 arguments, and throw
away the third if FOO only takes two arguments, but otherwise pass it
all three.

Can this be different than multiple-value-return where the caller is
expecting fewer values than the callee returns?  


∂01-Apr-85  1123	godot!gls@cca-unix 	[Gall: Bug Report]  
Received: from CCA-UNIX.ARPA by SU-AI.ARPA with TCP; 1 Apr 85  11:23:08 PST
Received: by cca-unix.ARPA (4.12/4.7)
	id AA25503; Mon, 1 Apr 85 14:18:04 est
Message-Id: <8504011918.AA25503@cca-unix.ARPA>
Received: by godot with CHAOS id AA04348; Mon, 1 Apr 85 13:46:19 est
Date: Monday, 1 April 1985, 13:46-EST
From: Guy Steele <godot!gls@cca-unix>
Subject: [Gall: Bug Report]
To: Moon%SCRC-STONY-BROOK.ARPA@GODOT, common-lisp%SU-AI.ARPA@GODOT
Cc: gls@AQUINAS
In-Reply-To: <850327200955.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

I have been tracking comments on ambiguities and lack of clarity
in the manual, and have been making a list of "small" (not substantive)
changes which might be incorporated in the next printing.  While I
expect no objections to the changes, I will circulate the list well
before sending it to Digital Press.
--Guy

∂01-Apr-85  1127	godot!gls@cca-unix 	Implementation of MAP, SOME, EVERY, etc...   
Received: from CCA-UNIX.ARPA by SU-AI.ARPA with TCP; 1 Apr 85  11:27:19 PST
Received: by cca-unix.ARPA (4.12/4.7)
	id AA25468; Mon, 1 Apr 85 14:16:46 est
Message-Id: <8504011916.AA25468@cca-unix.ARPA>
Received: by godot with CHAOS id AA04234; Mon, 1 Apr 85 13:38:48 est
Date: Monday, 1 April 1985, 13:39-EST
From: Guy Steele <godot!gls@cca-unix>
Subject: Implementation of MAP, SOME, EVERY, etc...
To: Moon%SCRC-STONY-BROOK.ARPA@GODOT,
        cork%umass-cs.csnet%CSNET-RELAY.ARPA@GODOT
Cc: common-lisp%SU-AI.ARPA@GODOT, gls@AQUINAS
In-Reply-To: <850327161712.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Received: by godot id AA28148; Wed, 27 Mar 85 22:11:41 est
    Received: from SU-AI.ARPA (su-ai.arpa.ARPA) by cca-unix.ARPA (4.12/4.7)
	    id AA24285; Wed, 27 Mar 85 21:34:41 est
    Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 27 Mar 85  13:39:50 PST
    Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 204367; Wed 27-Mar-85 16:16:13-EST
    Date: Wed, 27 Mar 85 16:17 EST
    From: David A. Moon <cca!Moon%SCRC-STONY-BROOK.ARPA@godot>
    Subject: Implementation of MAP, SOME, EVERY, etc...
    To: Dan Corkill <cork%umass-cs.csnet%CSNET-RELAY.ARPA@godot>
    Cc: common-lisp%SU-AI.ARPA@godot
    In-Reply-To: The message of 19 Mar 85 11:58-EST from Dan Corkill <cork%umass-cs.csnet@csnet-relay.arpa>
    Message-Id: <850327161712.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
    Comment: Message remailed after delay caused by distribution list error.

	Date:     Tue, 19 Mar 85 11:58 EST
	From:     Dan Corkill <cork%umass-cs.csnet@csnet-relay.arpa>


	There is an easily made implementation error in MAP, SOME, EVERY, etc.
	The published semantics indicate that these functions use the length of
	the shortest argument sequence to determine how many iterations to 
	perform (and in this way parallel the semantics of mapc, mapcar, etc.).

	Thus it would appear that:

		(map 'list '+ '(1 2 3) (star 2))

	where star builds a circular list of its argument should be legal and
	return => (3 4 5).

	Implementations that use length to check the length of argument sequences
	will break on such a call.

    The Common Lisp LENGTH function returns NIL when given a circular list.

From the Common Lisp manual, page 265:
"LIST-LENGTH differs from LENGTH when the list is circular;
LENGTH may fail to return, whereas LIST-LENGTH will return NIL."

∂01-Apr-85  1844	KMP@SCRC-QUABBIN.ARPA 	Re: Arg count checking
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 1 Apr 85  18:44:26 PST
Received: from SCRC-RIO-DE-JANEIRO by SCRC-YUKON via CHAOS with CHAOS-MAIL id 98514; Mon 1-Apr-85 21:43:55-EST
Date: Mon, 1 Apr 85 21:43 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Re: Arg count checking
To: masinter.pa@XEROX.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 1 Apr 85 04:00-EST from masinter.pa@XEROX.ARPA
Message-ID: <850401214307.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

[Removed Bug-1100@SUMEX-AIM]

    Date: 1 Apr 85 01:00 PST
    From: masinter.pa@XEROX.ARPA
    Subject: Re: Arg count checking
    In-reply-to: various messages
    To: bug-1100@SUMEX-AIM.ARPA
    cc: common-lisp@SU-AI.ARPA

    The only places I've seen extra args used in situations where it isn't
    (clearly) a bug is in code that is dealing with two different
    implementations.

    Implementation A has a function FOO with args A B and an optional C.

    Implementation B has a function FOO with args A B. No optional.

    You can then write a client that will work with both implementations, as
    long as it knows that some implementations may ignore the last argument.
    (Most of the cases I've seen have been ones where its been a "flag",
    e.g. implementation A has a "slow" and a "fast" case, and you can say
    (FOO 1 2 T) and it means do (FOO 1 2) and, if you care, do it fast
    rather than slow..., although there have been other uses.)

    I can think of about a half-dozen cases of this, off hand; e.g., the
    "standard system" has a vanilla WHEREIS, but there's a super-WHEREIS
    that takes lots of args, and it redefines WHEREIS to have lots of
    optionals.  

    The odd thing is that I can't think of a really clean way of doing
    this-- having variant argument lists in different implementations -- I
    suppose you'd have to write a &REST in every implementation that didn't
    have the args.

The proper solution would have been for the person who wrote the 
super-WHEREIS to call it something else (or in a language like CL,
use the same name but put it in a different package). Then old code still
calls the old utility and new code can call the new super-WHEREIS.
Even if the super-WHEREIS fixes some misfeature the old WHEREIS wants,
the writer should have done
 (DEFUN WHEREIS (...compatible-args...) (SUPER-WHEREIS ...whatever...))
 (DEFUN SUPER-WHEREIS (...hairy-args...) ...)
so that people wouldn't be tempted to call the existing WHEREIS with
the hairy args and get into the situation you're talking about.

It's the fault of the person who created the new FOO abstraction 
without giving it a new name that you are in this mess.

If (FOO x y) and (FOO x y z) does already exist in two implementations,
you should just write your own GENERALIZED-FOO abstraction that does
 (DEFUN GFOO (X Y &REST Z)
   (COND ((MEMQ 'HAIRY-FOO *FEATURES*) (APPLY #'FOO X Y Z))
	 (T (FOO X Y))))
or some macroesque equivalent (if you're an efficiency fiend).

    Another place this arises are in mapping functions which take functional
    arguments; they apply the functional arg; sometimes they pass extra
    arguments which of course the functional is free to ignore. 

This is interesting. I hadn't ever thought about
 (MAPCAR #'(LAMBDA (X &OPTIONAL (Y 0)) (LIST X Y)) '(A B C D) '(1 2))
I suppose one could argue that returning ((A 1) (B 2) (C 0) (D 0)) would
have been the "right" thing. Of course, 
 (MAPCAR #'(LAMBDA (&OPTIONAL (X 0) (Y 0)) (LIST X Y)) '(A B C D) '(1 2))
might have been a little harder to deal with ... since presumably that
just wouldn't return... of course, the fact that 
 (MAPCAR #'(LAMBDA (&OPTIONAL (X 0)) (PRINT X)))
loops indefinitely rather than returning argues in favor of such a position.
... I think.

    All of these are instances where the CALLER knows the args are optional.

    I can imagine (not very seriously) a separate syntax for that, e.g., put
    the &OPTIONAL on the caller rather than the callee:

    (FOO 1 2 &OPTIONAL T) which says to call FOO with 2 arguments, and throw
    away the third if FOO only takes two arguments, but otherwise pass it
    all three.

This is certainly consistent with the symmetry provided in the allow-other-keys
portion of the keyword arg specs. 

Somehow this bothers me; I'm at a loss to say exactly why, though. But I
think it also bothers me that :ALLOW-OTHER-KEYS is there (for reasons beyond
the obvious fact that it's an ugly special case in the middle of the keyword
namespace), so don't take it too personally. I think it has something to do 
with the fact that it means you're really trying to shoehorn an additional 
abstraction in where room wasn't provided. ie, the real problem is that all 
the old code is still calling FOO instead of GENERIC-FOO. I guess I think 
that's just a bug in that code. 

    Can this be different than multiple-value-return where the caller is
    expecting fewer values than the callee returns?  

I definitely agree these two issues are not different. I think this just
shows that what multiple value return does is wrong. I've held the position
for quite some time that multiple values should have to be &OPTIONAL'd 
and &REST'd. I believe there are others on this committee who side with me,
but we were in the minority in the discussions leading up to the current spec.
Perhaps that will change with time.

∂02-Apr-85  0745	DLW@SCRC-QUABBIN.ARPA 	Re: Arg count checking
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 2 Apr 85  07:44:51 PST
Received: from SCRC-CHICOPEE by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 149181; Tue 2-Apr-85 10:39:25-EST
Date: Tue, 2 Apr 85 10:46 EST
From: Daniel L. Weinreb <DLW@SCRC-STONY-BROOK.ARPA>
Subject: Re: Arg count checking
To: KMP@SCRC-STONY-BROOK.ARPA, masinter.pa@XEROX.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850401214307.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <850402104635.2.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Mon, 1 Apr 85 21:43 EST
    From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>

    This is interesting. I hadn't ever thought about
     (MAPCAR #'(LAMBDA (X &OPTIONAL (Y 0)) (LIST X Y)) '(A B C D) '(1 2))
    I suppose one could argue that returning ((A 1) (B 2) (C 0) (D 0)) would
    have been the "right" thing. 

You'd have to change the definition of MAPCAR.  Currently it's defined
to stop after any of the lists run out.  You'd have to change it;
perhaps to say that it should keep going until ALL of the lists run out,
but the old rule was there for a reason.  Or that it should stop as soon
as any of the lists that are being used as "required" argument run out,
although that's on the hirsute side. 
				 
				 Of course, 
     (MAPCAR #'(LAMBDA (&OPTIONAL (X 0) (Y 0)) (LIST X Y)) '(A B C D) '(1 2))
    might have been a little harder to deal with ... since presumably that
    just wouldn't return... 

No.  Under any of the possibilities above, it must terminate after four steps.

			    of course, the fact that 
     (MAPCAR #'(LAMBDA (&OPTIONAL (X 0)) (PRINT X)))
    loops indefinitely rather than returning argues in favor of such a position.
    ... I think.

The first list argument to MAPCAR is required, so this simply bombs out with
too few arguments to MAPCAR.

    I definitely agree these two issues are not different. I think this just
    shows that what multiple value return does is wrong. I've held the position
    for quite some time that multiple values should have to be &OPTIONAL'd 
    and &REST'd. I believe there are others on this committee who side with me,
    but we were in the minority in the discussions leading up to the current spec.
    Perhaps that will change with time.

That's right.  This was argued to death, and the present behavior was
arrived at after lots of discussion about both (and other) schemes.

∂02-Apr-85  1201	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: PROCLAIM [Gall: Bug Report] 
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 2 Apr 85  12:01:32 PST
Date:  Tue, 2 Apr 85 14:58 EST
From:  Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject:  Re: PROCLAIM [Gall: Bug Report]
To:  common-lisp@SU-AI.ARPA
In-Reply-To:  Message of 28 Mar 85 09:28 EST from "Network←Server.Daemon (Moon@SCRC-STONY-BROOK.ARPA@SU-AI)"
Message-ID:  <850402195849.627063@MIT-MULTICS.ARPA>

        !section  9.1(12)   Nick Gall 85-03-19
        !version  Digital Press 1984
        !topic    Non-Top-Level use of PROCLAIM

        Some mention of the effects of the non-top-level use of PROCLAIM
        and the other proclaiming forms should be made.

    On p.66 it says that DEFVAR is not allowed elsewhere than top-level.
    PROCLAIM is the only function (rather than special form) that makes
    declarations, and presumably the declarations it makes when it is
    called take effect "immediately", but the exact definition of "immediately"
    might be implementation-dependent.  For example, it is implementation-
    dependent whether PROCLAIM affects interpreted functions that have already
    been defined.

I guess what really bothers me about the definition of proclaim
is the following sentence:

          This allows a program to compute a declaration and then
        put it into effect by calling proclaim. (pg. 156)

This encourages a style that is bound to bring out an
inconsistency in between the semantics assigned to a correct
program by the compiler and the interpreter.

Is there a STRONG reason for allowing run-time declares? If not,
I think the above sentence should be struck, and proclaim's usage
restricted to DEFVAR, etc., and top-level.
≠

∂02-Apr-85  1201	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: INTERN [Gall: Bug Report]   
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 2 Apr 85  12:00:57 PST
Date:  Tue, 2 Apr 85 14:57 EST
From:  Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject:  Re: INTERN [Gall: Bug Report]
To:  common-lisp@SU-AI.ARPA
In-Reply-To:  Message of 28 Mar 85 09:28 EST from "Network←Server.Daemon (Moon@SCRC-STONY-BROOK.ARPA@SU-AI)"
Message-ID:  <850402195716.255225@MIT-MULTICS.ARPA>

        !section  11.7      Nick Gall 85-03-20
        !version  Digital Press 1984
        !topic    INTERN's effect on an accessible symbol's owner.

                    As a verb, to `intern' a symbol in a package means to
                  cause the symbol to be interned (sic) in the package if
                  it was not already; this function is performed by the
                  function INTERN.  If the symbol was previously unowned,
                  then the package it is being interned in becomes its
                  owner (home package)...
                                                          CLRM Section 11.0 (pg. 172)

        I interpret this passage in the following way:

        ;; Current package is USER

        * (setf p1 (make-package 'p1 :use '()))
        {printed rep. of p1}

        * (import 'p1::xyzzy)
        T

        * (symbol-package 'xyzzy)
        {printed rep. of p1}

        * (unintern 'xyzzy p1)
        T

        * (symbol-package 'xyzzy)
        NIL         ;; At this point, xyzzy is an accessible uninterned symbol.

        * (intern "XYZZY")
        XYZZY
        :INTERNAL

        * (symbol-package 'xyzzy)
        {printed rep. of user}

        In other words, INTERN ensures that the symbol that it returns
        as its first value has a home package.

        Is this interpretation correct?

    I think the mention of accessible but unowned symbols on page 172 (in the
    discussion of home packages) shoots down your example.  The result of the
    last call to SYMBOL-PACKAGE is probably undefined.

I don't understand your response.  The mention of accessible but
unowned symbols on page 172 merely confirms the possibility of
accessible uninterned symbols.  I fully agree that such beasts
may exist.  In fact, I have annotated the above code to show that
BEFORE the intern is done, xyzzy is an accessible uninterned
symbol.

My contention is that the above call to INTERN should (according
to my interpretation of the CLRM and for practical reasons which
I will point out below) change xyzzy from an accessible
uninterned symbol into an interned symbol (simply by updating its
package cell).

    If the symbol was previously unowned, then the package it is
    being interned in becomes its owner (home package); but if the
    symbol was previously owned by another package, that other
    package continues to own the symbol.

This sentence strongly suggests to me that intern does affect
accessible uninterned symbols.

If intern does not update an accessible symbol whose package cell
contains NIL, there is NO WAY to change the home package of the
symbol.  I can't give it a new home!

Suppose I defun foo in the user package.  Then I decide that it
`belongs' in my tool package.  The best I can do now is

* (import 'foo 'tool)
T

* (unintern 'foo)
T

But whenever foo is printed, it will print as #:foo.  This is
unacceptable.

∂02-Apr-85  1218	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: NIL and DEFCONSTANT [Gall: Bug Report]
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 2 Apr 85  12:16:52 PST
Date:  Tue, 2 Apr 85 15:06 EST
From:  Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject:  Re: NIL and DEFCONSTANT [Gall: Bug Report]
To:  common-lisp@SU-AI.ARPA
In-Reply-To:  Message of 28 Mar 85 09:28 EST from "Network←Server.Daemon (Moon@SCRC-STONY-BROOK.ARPA@SU-AI)"
Message-ID:  <850402200658.769017@MIT-MULTICS.ARPA>

        !section  20.1(last-1)        Nick Gall 85-03-19
        !version  Digital Press 1984
        !topic    Is nil declared by defconstant?

                    ...all constant symbols declared by DEFCONSTANT, such as NIL,
              T, and PI.

        If NIL is declared by DEFCONSTANT then it can legally be
        redefined according to section 5.1.2(last):

                    Constant symbols defined by DEFCONSTANT ... may be redefined,
              if necessary, by using DEFCONSTANT again[].

        Is such an interpretation correct?

    I do not believe that system-supplied constants can legally be redefined.

Is it that my interpretation is incorrect (and if so why?) or is
it that the CLRM is incorrect (and if so how?).
≠

∂02-Apr-85  1218	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: SPECIAL FUNCTION NAME [Gall: Bug Report]   
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 2 Apr 85  12:16:02 PST
Posted-Date:  2 Apr 85 15:04 EST
Date:  Tue, 2 Apr 85 15:01 EST
From:  Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject:  Re: SPECIAL FUNCTION NAME [Gall: Bug Report]
To:  common-lisp@SU-AI.ARPA
In-Reply-To:  Message of 28 Mar 85 09:28 EST from "Network←Server.Daemon (Moon@SCRC-STONY-BROOK.ARPA@SU-AI)"
Message-ID:  <850402200150.524049@MIT-MULTICS.ARPA>

        !section  7.5(14)   Nick Gall 85-03-19
        !version  Digital Press 1984
        !topic    Scope and Extent of local function names

    See above comment about the implications of FLET and LABELS not having
    been fully thought out and reflected in the manual.

        I suggest that Common Lisp go all the way, and allow a
        SPECIAL-FUNCTION-NAME declaration that would be analogous to the
        SPECIAL declaration for "ordinary" variables.

        Such a concept would make the idea of
        ordinary-variable/function-name binding and assignment much more
        consistent.

    As I recall this was considered and rejected on the basis that it would
    be confusing and wouldn't give any real increase in expressive power
    (since FUNCALL of a special variable could be used).  I agree with that
    decision, even though our implementation has always had the feature.
    The only place where we use it is in a crock that could just as well be
    done some other way.

I think that a thought out explanation of FLET and LABELS would
allow a SPECIAL-FUNCTION-NAME declaration to be described in
perspicuous manner.

As for its usefulness, I am writing a command processor, and I
wish to prevent the user from typing in forms that might abort
the processor (e.g., (exit), (reset-stack-group), etc.).  FLET
would allow me to establish temporary global function definitions
for these dangerous functions.  The code would be much clearer
than saving the old function definitions, doing defuns (or setfs
of symbol-functions) and then restoring the old definitions.
≠

∂02-Apr-85  1218	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: [Gall: Bug Report]
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 2 Apr 85  12:18:08 PST
Posted-Date:  2 Apr 85 15:15 EST
Date:  Tue, 2 Apr 85 15:12 EST
From:  Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject:  Re: [Gall: Bug Report]
To:  "Daniel L. Weinreb" <DLW@SCRC-STONY-BROOK.ARPA>
cc:  Moon@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To:  Message of 28 Mar 85 16:56 EST from "Daniel L. Weinreb"
Message-ID:  <850402201250.950711@MIT-MULTICS.ARPA>

    Date:  28 March 1985 16:56 est
    From:  Daniel L. Weinreb <DLW at SCRC-STONY-BROOK>
    Subject:  [Gall: Bug Report]

        Date: Wed, 27 Mar 85 20:09 EST
        From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
        were EVAL-WHEN permitted inside a function body (it is not; see p.66).
    
        ...
    
        On p.66 it says that DEFVAR is not allowed elsewhere than top-level.
    
    Are we reading the same page 66?  Mine says "It is not illegal to use
    these forms at other than top level, but whether it is meaningful to do
    so depends on context."  To my ears, this is sort of like saying
    that integers can be of any precision, but after they get larger
    than the fixnum limit, their behavior depends on context.
    
    Also, note the wording in the description of DEFUN on page 67: "Because
    DEFUN forms normally appear at top level, this is normally the null
    lexical environment."  This wording strongly suggests that DEFUN might
    sometimes not be at top level, and the environment is not necessarily
    always null.  After all, if DEFUN were only allowed at top-level, why
    bother with the "normally" qualifiers?  But you never find out anything
    further.
    
    I'm not advocating either side right at the moment; my point is that the
    manual is ambiguous (one might even say "coy") on this subject.
    

Hmm! I thought ALL integers were infinitely precise.

As to defuns at other that top level, on pg. 67 it says

    Evaluating a defun form causes the symbol NAME to be a global
    name for the function specified by the
    lambda-expression...DEFINED IN THE LEXICAL ENVIRONMENT IN
    WHICH THE defun WAS EXECUTED.

I take this to mean that the CLRM specifically allows and defines
the correct semantics for non-top-level use of DEFUN.

I think pg. 66 is what needs cleaning up (i.e., it should
enumerate the correct uses of `Top-Level' forms).  "Depends on
context" is equivalent to "is undefined" in my book.
≠

∂02-Apr-85  1218	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: COPY-SYMBOL [Gall: Bug Report]   
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 2 Apr 85  12:16:27 PST
Date:  Tue, 2 Apr 85 15:05 EST
From:  Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject:  Re: COPY-SYMBOL [Gall: Bug Report]
To:  common-lisp@SU-AI.ARPA
In-Reply-To:  Message of 28 Mar 85 09:28 EST from "Network←Server.Daemon (Moon@SCRC-STONY-BROOK.ARPA@SU-AI)"
Message-ID:  <850402200539.663972@MIT-MULTICS.ARPA>

        !section  10.3(9)   Nick Gall 85-03-19
        !version  Digital Press 1984
        !topic    Which  bindings are copied by COPY-SYMBOL?

                    "the initial value and function-definition of the new symbol
        will be the same as those of SYM..."

                    Does this mean that the (dynamic) value of the variable
        referred to by SYM, at the point where COPY-SYMBOL symbol is
        invoked, is copied?   Or, does it mean that the `initial', i.e.
        global value of the special variable named by SYM is copied?
        Although the wording seems to suggest the latter, it should be
        made clearer.

    The word "initial" was meant to refer to the new symbol, not the old
    symbol, I believe.  Probably no one realized the English could be
    regarded as ambiguous.

        The same questions and suggestion applies to the
        function-definition copied by COPY-SYMBOL.


What confused me in the defintion of COPY-SYMBOL was the phrase,
"the initial value and function definition of the NEW SYMBOL"
[emphasis mine N.G.].  Symbols do not have values and/or function
defintions in CL (or at least they are not required to), a point
made very well on pg. 163.  The language should be more like "the
initial value of the dynamic variable NAMED BY THE new symbol..."
≠

∂02-Apr-85  1327	JAR@MIT-MC 	SPECIAL FUNCTION NAME [Gall: Bug Report]   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Apr 85  13:27:03 PST
Date: 2 April 1985 16:26-EST
From: Jonathan A Rees <JAR @ MIT-MC>
Subject:  SPECIAL FUNCTION NAME [Gall: Bug Report]
To: Gall @ MIT-MULTICS
cc: common-lisp @ SU-AI

    Date: Tue, 2 Apr 85 15:01 EST
    From: Nick Gall <Gall at MIT-MULTICS.ARPA>

    ...As for its usefulness, I am writing a command processor, and I
    wish to prevent the user from typing in forms that might abort
    the processor (e.g., (exit), (reset-stack-group), etc.).  FLET
    would allow me to establish temporary global function definitions
    for these dangerous functions.  The code would be much clearer
    than saving the old function definitions, doing defuns (or setfs
    of symbol-functions) and then restoring the old definitions.

I think that special function binding was explicitly and intentionally
omitted from CL.  Symmetry with variables would suggest that they are
desirable, but there were reasons for their omission (descriptive and
implementation simplicity come to mind).

You could do what you need to do by implementing yourself a sort of
generalized special binding which is symmetric with SETF instead of with
SETQ, using UNWIND-PROTECT:

  (SETF-TEMPORARILY place value-form
    ... body-forms ...)

could expand into something like

  (LET ((SAVED-VALUE place))
    (UNWIND-PROTECT (PROGN (SETF SAVED-VALUE place)
			   ... body-forms ...)
		    (SETF place SAVED-VALUE)))

(with appropriate DEFSETF-like hair).  Now you have a much more
symmetrical facility, which will work not only with function bindings
(take place = (SYMBOL-FUNCTION ...)) but any other kind of location -
including CAR's of lists, lexical variables (!), etc.  (Think about it.)

We've been using exactly this facility in T (Yale Scheme) for quite a
while (in fact, it replaces specbinding altogether) and it's pretty
nice.  Perhaps even a little too powerful.

You run into problems if you're running in a multitasking or
multiprocessing environment.  Presumably special variable bindings are
local to a process in any such system (whether deep- or shallow-bound).
If you're multitasking you could imagine an UNWIND-PROTECT primitive for
changing dynamic state going from one process to another, so that you
could specbind arbitrary places; but this totally breaks down in a
multiprocessor system, where deep binding would be necessary.  How do
you deep-bind the car of a pair, or the 13th bit of a bit-vector?  That
would argue in favor of permitting function specbinding by special
dispensation, although how you'd implement it efficiently I can't
imagine.

For this particular application, though, isn't the right thing just to
set up a separate package?...

Jonathan

∂02-Apr-85  1329	fateman%ucbdali@Berkeley 	CLRM?    
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 2 Apr 85  13:24:51 PST
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.42)
	id AA22191; Tue, 2 Apr 85 12:50:14 pst
Received: by ucbdali.ARPA (4.24/4.42)
	id AA02474; Tue, 2 Apr 85 12:50:16 pst
Date: Tue, 2 Apr 85 12:50:16 pst
From: fateman%ucbdali@Berkeley (Richard Fateman)
Message-Id: <8504022050.AA02474@ucbdali.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: CLRM?

I think this is what I call CLTL  (Common Lisp the Language).  I am perhaps
guilty of wishful thinking to hope that a CLRM  (Common Lisp Reference Manual)
will be a different, perhaps public domain, document.  Is there any hope of
this happening?  In the meantime, I will wait for CLTM, (Common Lisp the
Movie) and TWK (The numeric supplement... The Wrath of Kahan ).

∂02-Apr-85  1722	Moon@SCRC-STONY-BROOK.ARPA 	Re: NIL and DEFCONSTANT [Gall: Bug Report]
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 Apr 85  17:17:01 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 207707; Tue 2-Apr-85 19:27:57-EST
Date: Tue, 2 Apr 85 19:28 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: NIL and DEFCONSTANT [Gall: Bug Report]
To: Nick Gall <Gall@MIT-MULTICS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850402200658.769017@MIT-MULTICS.ARPA>
Message-ID: <850402192844.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date:  Tue, 2 Apr 85 15:06 EST
    From:  Nick Gall <Gall@MIT-MULTICS.ARPA>

	    !section  20.1(last-1)        Nick Gall 85-03-19
	    !version  Digital Press 1984
	    !topic    Is nil declared by defconstant?

			...all constant symbols declared by DEFCONSTANT, such as NIL,
		  T, and PI.

	    If NIL is declared by DEFCONSTANT then it can legally be
	    redefined according to section 5.1.2(last):

			Constant symbols defined by DEFCONSTANT ... may be redefined,
		  if necessary, by using DEFCONSTANT again[].

	    Is such an interpretation correct?

	From: Moon
	I do not believe that system-supplied constants can legally be redefined.

    Is it that my interpretation is incorrect (and if so why?) or is
    it that the CLRM is incorrect (and if so how?).

The CLRM is not self-consistent.  As I said, I do not believe that system-supplied
constants can legally be redefined, so where the CLRM says or implies that they can
be it is wrong, in my opinion, and where it says or implies that they cannot be
it is not wrong.

∂02-Apr-85  1724	Moon@SCRC-STONY-BROOK.ARPA 	Re: INTERN [Gall: Bug Report]   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 Apr 85  17:18:21 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 207711; Tue 2-Apr-85 19:40:43-EST
Date: Tue, 2 Apr 85 19:41 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: INTERN [Gall: Bug Report]
To: Nick Gall <Gall@MIT-MULTICS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850402195716.255225@MIT-MULTICS.ARPA>
Message-ID: <850402194129.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

Sorry about the long message but I can't justify deleting any of
the context yet.  Summary of conclusions at the end.

    Date:  Tue, 2 Apr 85 14:57 EST
    From:  Nick Gall <Gall@MIT-MULTICS.ARPA>

	    !section  11.7      Nick Gall 85-03-20
	    !version  Digital Press 1984
	    !topic    INTERN's effect on an accessible symbol's owner.

			As a verb, to `intern' a symbol in a package means to
		      cause the symbol to be interned (sic) in the package if
		      it was not already; this function is performed by the
		      function INTERN.  If the symbol was previously unowned,
		      then the package it is being interned in becomes its
		      owner (home package)...
							      CLRM Section 11.0 (pg. 172)

	    I interpret this passage in the following way:

	    ;; Current package is USER

	    * (setf p1 (make-package 'p1 :use '()))
	    {printed rep. of p1}

	    * (import 'p1::xyzzy)
	    T

	    * (symbol-package 'xyzzy)
	    {printed rep. of p1}

	    * (unintern 'xyzzy p1)
	    T

	    * (symbol-package 'xyzzy)
	    NIL         ;; At this point, xyzzy is an accessible uninterned symbol.

	    * (intern "XYZZY")
	    XYZZY
	    :INTERNAL

	    * (symbol-package 'xyzzy)
	    {printed rep. of user}

	    In other words, INTERN ensures that the symbol that it returns
	    as its first value has a home package.

	    Is this interpretation correct?

	I think the mention of accessible but unowned symbols on page 172 (in the
	discussion of home packages) shoots down your example.  The result of the
	last call to SYMBOL-PACKAGE is probably undefined.

    I don't understand your response.  The mention of accessible but
    unowned symbols on page 172 merely confirms the possibility of
    accessible uninterned symbols.  I fully agree that such beasts
    may exist.  In fact, I have annotated the above code to show that
    BEFORE the intern is done, xyzzy is an accessible uninterned
    symbol.

To amplify my response, I don't feel that when INTERN finds an already
accessible symbol (rather than creating a new one), that it "interns
the symbol".  I think the symbol is already interned and INTERN shouldn't
mess with its home package.  Of course this is a matter of interpretation
and perhaps you are right.  The implementation might be expensive in some
systems, though.

    My contention is that the above call to INTERN should (according
    to my interpretation of the CLRM and for practical reasons which
    I will point out below) change xyzzy from an accessible
    uninterned symbol into an interned symbol (simply by updating its
    package cell).

	If the symbol was previously unowned, then the package it is
	being interned in becomes its owner (home package); but if the
	symbol was previously owned by another package, that other
	package continues to own the symbol.

    This sentence strongly suggests to me that intern does affect
    accessible uninterned symbols.

Oh my.  The sentence you quote (on p. 172) appears to be left over from
the days when INTERN would allow a symbol as its argument.  The language
was later changed to permit only strings as arguments to INTERN.  But if
this isn't really a left-over, then it is evidence for your position.

    If intern does not update an accessible symbol whose package cell
    contains NIL, there is NO WAY to change the home package of the
    symbol.  I can't give it a new home!

I think IMPORT was intended to be the way to do that.  Again, the manual
does not appear to have been updated to reflect this after the arguments
allowed for INTERN were changed.  SYMBOL-PACKAGE is also SETF'able in
our implementation, but apparently not in the standard language.

    Suppose I defun foo in the user package.  Then I decide that it
    `belongs' in my tool package.  The best I can do now is

    * (import 'foo 'tool)
    T

    * (unintern 'foo)
    T

    But whenever foo is printed, it will print as #:foo.  This is
    unacceptable.

Do the operations in the other order.  (Of course you have to read
the IMPORT form before evaluating the UNINTERN form).  That works in
our implementation, although I admit it isn't crystal clear that that
is what the manual intends.

I think this issue may need to be referred to the (not yet existent)
technical committee on clarifications to the language.  If you want my
own opinion, in summary:
	- INTERN never changes the SYMBOL-PACKAGE of a symbol that it
	  did not just create.
	- IMPORT sets the SYMBOL-PACKAGE to the package imported into
	  when given an uninterned symbol (more precisely, a symbol
	  whose SYMBOL-PACKAGE is NIL).

∂02-Apr-85  2002	FAHLMAN@CMU-CS-C.ARPA 	INTERN [Gall: Bug Report]  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Apr 85  20:02:42 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 2 Apr 85 23:02:04-EST
Date: Tue, 2 Apr 1985  23:01 EST
Message-ID: <FAHLMAN.12100086792.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA, Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject: INTERN [Gall: Bug Report]
In-reply-to: Msg of 2 Apr 1985  19:41-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>


This concerns the recent exchange between Moon and Gall on how INTERN
should handle home packages.  I will refrain from including all previous
context.  Unfortunately, I read most of this mail on an 80-column screen
and if things get nested too deeply, each line starts on the next line.

First, let me say that this is probably not of world-shaking importance.
Home packages are just a convenience for the printer, so that if a
symbol isn't accessible in the current package, it can (usually) either
tell you some package where the symbol is accessible or flag the cases
in which a symbol is not accessible in any package.  It is true that by
clever use of Unintern you can manage to create an accessible sysmbol
with no recorded home package.  Unintern also allows you to screw
yourself in lots of other ways if you work hard at it.  Yawn!

Having said that, it seems to me that Gall's original reading of the
manual is as reasonable as any other.  This says that if Intern finds an
acessible symbol that has no home (as opposed to creating a new symbol),
it should bash the Symbol-Package cell to the value of the package in
which it is doing the interning.  It is too much work to make sure that
every symbol that is accessible in any package always has a home
package, but when we trip over an anomalous case like this, we may as
well fix it.  It seems intuitive that Intern should return a symbol that
is "interned", in the sense of being accessible and having a home.

Moon grants that this might be a reasonable implementation, but then
comments that implementing this might be expensive.  I don't see where
the expense would be.  If Intern creates a symbol, it sets the home
package; if Intern finds a symbol whose package cell is NIL, it again
sets the home package.  Checking the home package for nillity is a tiny
expense compared to the hash-table lookups, etc.

The sentence on page 172 should more properly say "when a STRING is
interned in a package...", since as Moon points out you cannot intern a
symbol directly.  However, I think that this passage makes sense despite
this, if you make the reasonable assumption that the "symbol" referred
to here is either the one that is created or the already accessible
symbol that is found, as the case may be.

We decided not to allow users to use SETF on Symbol-Package, since there
seemed to be no good use for this and since by diddling around with this
you can create some very confusing situations.

-- Scott

∂02-Apr-85  2021	FAHLMAN@CMU-CS-C.ARPA 	NIL and DEFCONSTANT [Gall: Bug Report]    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Apr 85  20:15:02 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 2 Apr 85 23:14:24-EST
Date: Tue, 2 Apr 1985  23:14 EST
Message-ID: <FAHLMAN.12100089053.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA, Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject: NIL and DEFCONSTANT [Gall: Bug Report]
In-reply-to: Msg of 2 Apr 1985  19:28-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>


I agree with Moon that it "is an error" to redefine built-in constants.
It probably is not required that an implementation stop you from doing
this, but it would be a good idea.  

I think that the description on page 56 is OK as it is.  First it says
that there are built-in named constants that you don't get to change.
Here it talks about such things as T and NIL.  Then it says that
"constant symbols defined by Defconstant" are also treated this way, but
that they may be redefined if necessary by using Defconstant again.  I
don't see anything that would imply that T and NIL are implicitly
defined by Defconstant and that they are therefore redefinable.

-- Scott

∂03-Apr-85  1226	JLW  	INTERN and "intern" -- the unwise choice of  terminology   
To:   Gall@MIT-MULTICS.ARPA, Moon@SCRC-STONY-BROOK.ARPA
CC:   Common-Lisp@SU-AI.ARPA   

I believe the confusion over the interning-an-unowned-symbol stems from
the misleading use of the verb "intern" on page 172, and I think I'd
rather see that part of the documentation fixed than have any change
in th semantics of INTERN, UNINTERN, and/or IMPORT.

The state of being "interned" clearly requires the symbol to be owned; and 
the penultimate paragraph of the introductory to chapter 11 says "this process 
[interning] is performed by the function INTERN."  For these reasons, one 
might be tempted to agree with Nick that every call to INTERN results in an
interned symbol; yet the definition of INTERN rather implies that when
a symbol is already accessible [note well: "accessible", not "interned"]
it is merely returned, without the modification to the home package 
outlined for the case of when "no such symbol is found".

My recommendations are quite straightforward:
 1) pick some other word to use in place of "interned" to describe the
    state so laboriously depicted on page 172, so that the reader is not
    tempted to jump to the conclusion that it is coextensive with INTERN'd
 2) Introduce the user-level operation for modifying a symbol's package
    "cell" [its home package].  As Nick has already pointed out, the
    current design doesn't prevent one from damageing that cell, by 
    injudicious use of UNINTERN and/or IMPORT; and worse yet, it doesn't
    provide any way to say precisely what you mean when you want to
    change its home [which is different from merely IMPORTing it somewhere].

-- JonL --

∂03-Apr-85  1438	Gall.HIS←Guest@MIT-MULTICS.ARPA    
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 3 Apr 85  14:37:41 PST
Date:  Wed, 3 Apr 85 17:36 EST
From:  Nick Gall <Gall@MIT-MULTICS.ARPA>
To:  common-lisp@SU-AI.ARPA
In-Reply-To:  Message of 3 Apr 85 03:28 EST from "Network←Server.Daemon (REM@IMSSS@SU-AI.ARPA)"
Message-ID:  <850403223620.774008@MIT-MULTICS.ARPA>

    Date:  3 April 1985 03:28 est
    From:  Network←Server.Daemon (REM@IMSSS@SU-AI.ARPA)

    Return-Path: <@MIT-MULTICS.ARPA,@SU-AI.ARPA:REM@IMSSS>
    Received: from SU-AI.ARPA by MIT-MULTICS.ARPA TCP; 03-Apr-1985 03:28:38-est
    Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Apr-03 00:23:16 PST (=GMT-8hr)
    Date: 1985 April 02 23:36:01 PST (=GMT-8hr)
    Message-id: SU-IMSSS.REM.A132116072764.G0391
    From: Robert Elton Maas <REM@IMSSS.SU.EDU>
    To:Gall@MIT-MULTICS.ARPA
    Subject:CL, INTERN, etc.
    Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
    Reply-to: REM@MIT-MC.ARPA

    > Date:  Thu, 21 Mar 85 00:36 EST
    > From:  Nick Gall <Gall@MIT-MULTICS.ARPA>
    >
    > Thanks for the encouragement.  Having previously worked on an Ada
    > implementation effort, I was hoping that the Common Lisp spec. would
    > have been as carefully and completely defined.  But it's never to
    > late, as long as there is a concerned community.

    Well, it's more difficult to make substantive changes now, because
    those who worked on the current version of the manual and have done
    some implentation are unwilling to start all over now, which I
    understand (PCNET pulled the rug out from under my software and
    documentation too many times), but indeed perhaps it's never too late
    to fix the document to say something consistent and reasonable.

    > I am sending my replies to some of your replies to the
    > Common-Lisp mailing list.
    Ok. (I think I already saw some of them, I'm falling behind in
    answering my netmail.)

    > !section  11.7      Nick Gall 85-03-20
    > !version  Digital Press 1984
    > !topic    UNINTERNing a shadowing-symbol
    > When uninterning a shadowing symbol (call it foo), UNINTERN
    > collects all inherited symbols with the same print-name
    > as foo, including foo (assuming foo was inherited).  If the name
    > conflict is only between foo and one other symbol, what sense
    > does it make to signal a name conflict error and give the user a
    > choice between shadow-importing foo and the other symbol.  If the
    > user chooses foo, it is no different from aborting from the
    > error.

    This plus later messages bring up a curious question. Originally
    INTERN could take a symbol and put it in a hash table so it'd be
    accessible by name in addition to by internal pointer. Any values or
    properties it had would presumably be kept. But CL allows INTERN only
    for strings (creating an symbol or finding an old one), so it never
    modifies an existing non-interned identifier to make it itself
    interned, it always makes a new symbol, thus it's impossible to keep
    the old properties and value from the old symbol in the new one. I
    this correct?


IMPORT can be used to "put [a symbol] in a hash table so it'd be
accessible by name...".

∂03-Apr-85  1502	JLW  	Assymetry between argument-passing and value-returning
To:   common-lisp@SU-AI.ARPA

In view of the recent semi-suggestions that the logical similarity between
argument passing and value receiving be institutionalized in Common Lisp,
perhaps we ought to review some of the reasons as to why we *didn't* do
it in the first place.

For one thing, I believe the need to mediate the argument spectrum could be
done on either side -- the defining side or the calling side -- but that
doing it on the defining side is simpler.  For example, it is possible
to correct a definition *** in one place *** that fixes up a whole
slew of differing calls (e.g., some calls passing 3 args, some passing
5 args, etc).  Similarly, we would keep the calling side "simple" even when
multiple return values are expected (i.e., no &optional or &rest, and
no destructuring).  For the cases where some dynamic variation *is*
desirable, well, APPLY permits full freedom on the caller side for argument
passing, and MULTIPLE-VALUE-LIST permits full freedom on the caller side for 
receiving values; of course, these "full freedom" capabilities are consy,
but they aren't expected to be very important.

The case offered as a potential example needing (or rather,"wanting") some
caller control over the argument spectrum -- simple WHEREIS and extended
WHEREIS -- seems to be a clear case of buggy design.  For example, suppose
a caller passes 6 arguments at a time when the 4-argument-only version
is resident.  What could possibly be expected?  Should one assume that the
extra two argments didn't convey any information, and can safely be discarded?
If so, then what is the point of the 6-argument version.  If one takes the
obvious tactic of having the 4-argument version admit two optional aguments
and run a fatal error if either argument is passed in [or even perhaps
autoload the 6-argument version when the optionals are passed in] then 
there is no "4-argument" version; both are in fact 6-argument functions,
although one of them is biased against the 5th and 6th args.


In short, if one wants downward compatibility, he has to design the low-end
function to do something reasonable with callers who request high-end
features.

-- JonL --

∂03-Apr-85  1556	BSG@SCRC-STONY-BROOK.ARPA 	Re: Arg count checking 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 3 Apr 85  15:47:58 PST
Received: from SCRC-CONCORD by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 208449; Wed 3-Apr-85 18:47:06-EST
Date: Wed, 3 Apr 85 18:48 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Re: Arg count checking
To: masinter.pa@XEROX.ARPA, bug-1100@SUMEX-AIM.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 1 Apr 85 04:00-EST from masinter.pa@XEROX.ARPA
Message-ID: <850403184831.0.BSG@CONCORD.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTI

    Date: 1 Apr 85 01:00 PST
    From: masinter.pa@XEROX.ARPA

    All of these are instances where the CALLER knows the args are optional.

    I can imagine (not very seriously) a separate syntax for that, e.g., put
    the &OPTIONAL on the caller rather than the callee:

    (FOO 1 2 &OPTIONAL T) which says to call FOO with 2 arguments, and throw
    away the third if FOO only takes two arguments, but otherwise pass it
    all three.
I have needed this some number of times; it has been discussed locally
around here some, but to no end. 

Specifically, I had a function "A" with a functional argument.  A's contract
includes not only its own argument list, but the set of arguments with which
it calls its functional argument.   Some callees are not interested in 
all of the things that A passes them.  The callees can &REST IGNORE
the uninteresting arguments, or declare the arguments and ignore them.

I (and not many others) see a true lack of symmetry with ordinary
optional arguments.  The whole reason &OPTIONAL exists is so that a
caller need not have or show knowledge of arguments in which he is not
interested: not have dummy variables, or have to give their name or
number.  Every such argument[English,not Lisp] can be applied equally
well to the functional callees of functions accepting functional
arguments.

∂03-Apr-85  1749	Masinter.pa@Xerox.ARPA 	Re: SPECIAL FUNCTION NAME [Gall: Bug Report]  
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 3 Apr 85  17:49:35 PST
Received: from Salvador.ms by ArpaGateway.ms ; 03 APR 85 17:49:37 PST
Date: 3 Apr 85 17:49 PST
From: Masinter.pa@XEROX.ARPA
Subject: Re: SPECIAL FUNCTION NAME [Gall: Bug Report]
In-reply-to: Jonathan A Rees <JAR@MIT-MC.ARPA>'s message of 2 Apr 85
 16:26 EST
To: common-lisp@SU-AI.ARPA

"For this particular application, though, isn't the right thing just to
set up a separate package?..."

Not if you ever had some other function which called (exit). The intent
is to wall off the functionality, not the names.

∂03-Apr-85  1843	Moon@SCRC-QUABBIN.ARPA 	INTERN and "intern" -- the unwise choice of  terminology     
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 3 Apr 85  18:43:20 PST
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 150291; Wed 3-Apr-85 21:39:57-EST
Date: Wed, 3 Apr 85 21:43 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: INTERN and "intern" -- the unwise choice of  terminology   
To: Jon White <JLW@SU-AI.ARPA>
cc: Gall@MIT-MULTICS.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 3 Apr 85 15:26-EST from Jon White <JLW@SU-AI.ARPA>
Message-ID: <850403214317.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

I agree completely with the enclosed message from Jon L.

    Date: 03 Apr 85  1226 PST
    From: Jon White <JLW@SU-AI.ARPA>

    I believe the confusion over the interning-an-unowned-symbol stems from
    the misleading use of the verb "intern" on page 172, and I think I'd
    rather see that part of the documentation fixed than have any change
    in th semantics of INTERN, UNINTERN, and/or IMPORT.

    The state of being "interned" clearly requires the symbol to be owned; and 
    the penultimate paragraph of the introductory to chapter 11 says "this process 
    [interning] is performed by the function INTERN."  For these reasons, one 
    might be tempted to agree with Nick that every call to INTERN results in an
    interned symbol; yet the definition of INTERN rather implies that when
    a symbol is already accessible [note well: "accessible", not "interned"]
    it is merely returned, without the modification to the home package 
    outlined for the case of when "no such symbol is found".

    My recommendations are quite straightforward:
     1) pick some other word to use in place of "interned" to describe the
	state so laboriously depicted on page 172, so that the reader is not
	tempted to jump to the conclusion that it is coextensive with INTERN'd
     2) Introduce the user-level operation for modifying a symbol's package
	"cell" [its home package].  As Nick has already pointed out, the
	current design doesn't prevent one from damageing that cell, by 
	injudicious use of UNINTERN and/or IMPORT; and worse yet, it doesn't
	provide any way to say precisely what you mean when you want to
	change its home [which is different from merely IMPORTing it somewhere].

∂03-Apr-85  1846	KSH@MIT-MC
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Apr 85  18:45:46 PST
Date: 3 April 1985 21:45-EST
From: Kjeld Hvatum <KSH @ MIT-MC>
To: Fahlman @ CMU-CS-C
cc: common-lisp @ SU-AI

Date: 04/03/85
From: Steve Bacher
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Subject: INTERN (Gall: Bug Report)
 
(Note: Please forgive absence of square brackets - I'm an IBM user.)
 
  We decided not to allow users to use SETF on Symbol-Package, since there
  seemed to be no good use for this and since by diddling around with this
  you can create some very confusing situations.
 
It seems to me that this might be construed as a violation of the
LISP (hacker?) ethic, which provides the user with the ability to
manipulate his/her environment any which way {s}he wishes.  Not
that CL is required to provide every tool in the book, especially
since it's straightforward enough to do your own DEFSETF for a
(SETF SYMBOL-PACKAGE ...) construct, but the above reasoning
seems a mite feeble, especially considering the degree of bashing
that *is* permitted by CL.
 
You should keep in mind that users have a way of discovering the
most amazing uses for features that originated as afterthoughts
or oversights.  To say that users should be protected from
nonfunctionality and/or self-confusion runs counter to all that
I have been led to believe.
 

∂03-Apr-85  2043	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: INTERN [Gall: Bug Report]   
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 3 Apr 85  20:43:01 PST
Posted-Date:  3 Apr 85 23:42 EST
Date:  Wed, 3 Apr 85 23:38 EST
From:  Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject:  Re: INTERN [Gall: Bug Report]
To:  "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
cc:  "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>, 
     common-lisp@SU-AI.ARPA
In-Reply-To:  Message of 2 Apr 85 23:01 EST from "Scott E. Fahlman"
Message-ID:  <850404043851.615892@MIT-MULTICS.ARPA>

    Date:  2 April 1985 23:01 est
    From:  Scott E. Fahlman <Fahlman at CMU-CS-C>
    Subject:  INTERN [Gall: Bug Report]

    This concerns the recent exchange between Moon and Gall on how INTERN
    should handle home packages.  I will refrain from including all previous
    context.  Unfortunately, I read most of this mail on an 80-column screen
    and if things get nested too deeply, each line starts on the next line.

    First, let me say that this is probably not of world-shaking importance.
    Home packages are just a convenience for the printer, so that if a
    symbol isn't accessible in the current package, it can (usually) either
    tell you some package where the symbol is accessible or flag the cases
    in which a symbol is not accessible in any package.  It is true that by
    clever use of Unintern you can manage to create an accessible sysmbol
    with no recorded home package.  Unintern also allows you to screw
    yourself in lots of other ways if you work hard at it.  Yawn!

    Having said that, it seems to me that Gall's original reading of the
    manual is as reasonable as any other.  This says that if Intern finds an
    acessible symbol that has no home (as opposed to creating a new symbol),
    it should bash the Symbol-Package cell to the value of the package in
    which it is doing the interning.  It is too much work to make sure that
    every symbol that is accessible in any package always has a home
    package, but when we trip over an anomalous case like this, we may as
    well fix it.  It seems intuitive that Intern should return a symbol that
    is "interned", in the sense of being accessible and having a home.

    Moon grants that this might be a reasonable implementation, but then
    comments that implementing this might be expensive.  I don't see where
    the expense would be.  If Intern creates a symbol, it sets the home
    package; if Intern finds a symbol whose package cell is NIL, it again
    sets the home package.  Checking the home package for nillity is a tiny
    expense compared to the hash-table lookups, etc.

    The sentence on page 172 should more properly say "when a STRING is
    interned in a package...", since as Moon points out you cannot intern a
    symbol directly.  However, I think that this passage makes sense despite
    this, if you make the reasonable assumption that the "symbol" referred
    to here is either the one that is created or the already accessible
    symbol that is found, as the case may be.

    We decided not to allow users to use SETF on Symbol-Package, since there
    seemed to be no good use for this and since by diddling around with this
    you can create some very confusing situations.

    -- Scott

I agree with you completely.  I disagree with the recommendations given
by Jon L.  White:

     1) pick some other word to use in place of "interned" to describe the
          state so laboriously depicted on page 172, so that the reader is not
          tempted to jump to the conclusion that it is coextensive with INTERN'd
     2) Introduce the user-level operation for modifying a symbol's package
          "cell" [its home package].  As Nick has already pointed out, the
          current design doesn't prevent one from damageing that cell, by
          injudicious use of UNINTERN and/or IMPORT; and worse yet, it doesn't
          provide any way to say precisely what you mean when you want to
          change its home [which is different from merely IMPORTing it somewhere].

Since the CLRM already implies that INTERN may clobber the package cell
of an accessible symbol (an inexpensive operation) isn't it simpler (and
cleaner) to merely state it explicitly in the def.  of INTERN (pg.184),
instead of changing pg.  172 AND inventing a WHOLE NEW user-level
operation (and a dangerous one at that)?

∂03-Apr-85  2105	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: NIL and DEFCONSTANT [Gall: Bug Report]
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 3 Apr 85  21:05:18 PST
Date:  Wed, 3 Apr 85 23:52 EST
From:  Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject:  Re: NIL and DEFCONSTANT [Gall: Bug Report]
To:  "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
cc:  "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>, 
     common-lisp@SU-AI.ARPA
In-Reply-To:  Message of 2 Apr 85 23:14 EST from "Scott E. Fahlman"
Message-ID:  <850404045222.726223@MIT-MULTICS.ARPA>

    Date:  2 April 1985 23:14 est
    From:  Scott E. Fahlman <Fahlman at CMU-CS-C>
    Subject:  NIL and DEFCONSTANT [Gall: Bug Report]

    I agree with Moon that it "is an error" to redefine built-in constants.
    It probably is not required that an implementation stop you from doing
    this, but it would be a good idea.

    I think that the description on page 56 is OK as it is.  First it says
    that there are built-in named constants that you don't get to change.
    Here it talks about such things as T and NIL.  Then it says that
    "constant symbols defined by Defconstant" are also treated this way, but
    that they may be redefined if necessary by using Defconstant again.  I
    don't see anything that would imply that T and NIL are implicitly
    defined by Defconstant and that they are therefore redefinable.

    -- Scott


I agree with Moon also.  And I agree that pg.  56 is ok too.  It is pg.
69 that is a little shaky, and pg.  324 DEFINITELY states that NIL and T
are defined with DEFCONSTANT.

∂03-Apr-85  2110	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: What should CLOSE return?   
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 3 Apr 85  21:08:48 PST
Posted-Date:  4 Apr 85 00:07 EST
Date:  Thu, 4 Apr 85 00:05 EST
From:  Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject:  Re: What should CLOSE return?
To:  REM@MIT-MC.ARPA
cc:  common-lisp@SU-AI.ARPA
In-Reply-To:  Message of 3 Apr 85 03:29 EST from "Network←Server.Daemon (REM@IMSSS@SU-AI.ARPA)"
Message-ID:  <850404050502.925392@MIT-MULTICS.ARPA>

    Date:  3 April 1985 03:29 est
    From:  Network←Server.Daemon (REM@IMSSS@SU-AI.ARPA)

    Return-Path: <@MIT-MULTICS.ARPA,@SU-AI.ARPA:REM@IMSSS>
    Received: from SU-AI.ARPA by MIT-MULTICS.ARPA TCP; 03-Apr-1985 03:28:38-est
    Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Apr-03 00:23:00 PST (=GMT-8hr)
    Date: 1985 April 02 18:50:35 PST (=GMT-8hr)
    Message-id: SU-IMSSS.REM.A132116072744.G0366
    From: Robert Elton Maas <REM@IMSSS.SU.EDU>
    To:Gall@MIT-MULTICS.ARPA
    Subject:attempt to bind constant, what should CLOSE return
    Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
    Reply-to: REM@MIT-MC.ARPA

    > Date:  Thu, 21 Mar 85 00:49 EST
    > From:  Nick Gall <Gall@MIT-MULTICS.ARPA>
    >
    >    From: Robert Elton Maas <REM@IMSSS.SU.EDU>
    >    Subject: What should CLOSE return? Closed-channel-object, or truefilename.
    >
    >     > !topic    What does CLOSE Return?
    >     >
    >     > I think it should return the STREAM it was given to close.  This
    >     > would make it symmetric with OPEN: OPEN returns an open stream,
    >     > CLOSE returns a closed stream.

    >     That's not symmetric, that's coercive. OPEN and CLOSE are like
    >     matching parenthesis, one does it and the other undos it except for
    >     a residual side-effect. ...
    >
    > You're right `symmetric' is the wrong adj.  But I still think CLOSE should
    > return the (closed) stream.  It can't (always) return the truename
    > of the file associated with the stream, since not all streams are
    > associated with files.

    It's a matter of opinion as to what "should" be returned, and if
    there's any use for the closed stream that couldn't be obtained by
    retaining a pointer to the original open stream and using that pointer
    after the CLOSE has been done, then I'll agree with you. But usually a
    closed stream is just an open stream that has been modified in place
    to be closed, in which case anyone wanting the closed stream can just
    as well retain the old pointer instead of expecting that CLOSE will
    return it back to you. On the other hand, if a system doesn't assign a
    version number until the moment a file is closed, and if there's no
    particular reason to need CLOSE to return the closed stream, then it
    should return the true filename to save the user the hassle of getting
    that info itself.

You still haven't said what close should return when the stream being
closed is NOT a file stream (e.g., closing a string stream).  Note that
the CLOSE function is in the chapter on streams NOT the file system
interface chapter.

    > To obtain the truename of a just closed file, one could write
    >           (truename (close x))          ; where x is bound to a file stream
    > since truename will take a stream as an argument.  (Unfortunately,
    > the CLRM (23.1.2(5)) is only explicit about what truename does
    > with an `open' stream.)
    Clearly something needs to be change, either force truename to work on
    closed streams, telling the true name that couldn't have been known
    for sure while the file was still open, or having CLOSE return the
    true filename as I suggested.

Agreed.

∂04-Apr-85  0750	RAM@CMU-CS-C.ARPA 	INTERN and "intern" -- the unwise choice of  terminology     
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Apr 85  07:50:02 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Thu 4 Apr 85 10:43:06-EST
Date: Thu, 4 Apr 1985  10:42 EST
Message-ID: <RAM.12100476562.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   Jon White <JLW@SU-AI.ARPA>
Cc:   Common-Lisp@SU-AI.ARPA, Gall@MIT-MULTICS.ARPA, Moon@SCRC-STONY-BROOK.ARPA
Subject: INTERN and "intern" -- the unwise choice of  terminology   
In-reply-to: Msg of 3 Apr 1985  15:26-EST from Jon White <JLW at SU-AI.ARPA>


    I don't think that a home-package-setting operation is well
defined, at least without some constraints.  The system would
certainly get confused if you set the home package to a package that
the symbol was not accessible in, and it would be dubious to set the
home package to a package where the symbol is not present (as opposed
to inherited).

    If you impose these requirements, setting the home package starts
to sound a great deal like IMPORT.  I think that the proposal to have
IMPORT set the home package if there is none makes a great deal of
sense.  The effect of IMPORT is really about the same as old-style
intern on a symbol.  I don't really like the idea of INTERN having
obscure side-effects such as setting the home package, since it is
something that the system often does without an explicit request.

  Rob

∂04-Apr-85  1104	Moon@SCRC-STONY-BROOK.ARPA 	INTERN and "intern" -- the unwise choice of  terminology      
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Apr 85  11:03:50 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 209032; Thu 4-Apr-85 13:56:10-EST
Date: Thu, 4 Apr 85 13:57 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: INTERN and "intern" -- the unwise choice of  terminology   
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
cc: Jon White <JLW@SU-AI.ARPA>, Common-Lisp@SU-AI.ARPA,
    Gall@MIT-MULTICS.ARPA
In-Reply-To: <RAM.12100476562.BABYL@CMU-CS-C.ARPA>
Message-ID: <850404135733.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 4 Apr 1985  10:42 EST
    From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>

	I don't think that a home-package-setting operation is well
    defined, at least without some constraints.  The system would
    certainly get confused if you set the home package to a package that
    the symbol was not accessible in, and it would be dubious to set the
    home package to a package where the symbol is not present (as opposed
    to inherited).

	If you impose these requirements, setting the home package starts
    to sound a great deal like IMPORT.  I think that the proposal to have
    IMPORT set the home package if there is none makes a great deal of
    sense.  The effect of IMPORT is really about the same as old-style
    intern on a symbol.  I don't really like the idea of INTERN having
    obscure side-effects such as setting the home package, since it is
    something that the system often does without an explicit request.

This message makes sense to me.

∂04-Apr-85  1345	JLW  	"home-ifying" symbols   
To:   ram@CMU-CS-C.ARPA
CC:   gall@MIT-MULTICS.ARPA, moon@SCRC-STONY-BROOK.ARPA,
      common-lisp@SU-AI.ARPA  

Several people, yourself included, have suggested that if a luser
sets a symbol's package cell to something random then "the system
will get very confused".

How?

The package cell seems to affect *nothing* in the system except
print, and there is nothing particularly confusing about the
fact that print will want to 
  1) certify either a nil or a package in that cell, and
  2) output a #: prefix if it was nil.
Given the current capabilities of unintern, there seems to be no way
to avoid the so-called pathalogical situation wherein a symbol is
"homed" nowhere, yet accessible from one or more packages [shall we
call such a non-homed symbol a "bastard" since no one "owns" it?]

The problem with trying to insure the existence of a home through
side-effects in INTERN and/or IMPORT is that that doesn't address the
issue that's been galling us all along.  Namely, a symbol is present
in several packages, and owned by one of them; but the luser decides
that it is homed * in the wrong package * and he wishes to change it.

How about having a set-symbol-package capablity which certifies
that the symbol is at least present in the package that it is
being "homed" in?  Would that satisfy your feeling for constraints?


-- JonL --

P.S. Two uses of "certify" above mean "run a cerror if condition not met".

∂04-Apr-85  1423	RAM@CMU-CS-C.ARPA 	"home-ifying" symbols     
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Apr 85  14:21:59 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Thu 4 Apr 85 17:21:24-EST
Date: Thu, 4 Apr 1985  17:21 EST
Message-ID: <RAM.12100549079.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   Jon White <JLW@SU-AI.ARPA>
Cc:   common-lisp@SU-AI.ARPA, gall@MIT-MULTICS.ARPA, moon@SCRC-STONY-BROOK.ARPA
Subject: "home-ifying" symbols   
In-reply-to: Msg of 4 Apr 1985  16:45-EST from Jon White <JLW at SU-AI.ARPA>


    I would consider the system very confused if a symbol which
appears to be interned does not print readably when no package system
changes have been made between the printing and the reading.  This
could happen if a symbol is not accessible in its home package.  

    It would be reasonable to allow setf on symbol-package with the
constraint that the new value may only be a package that the symbol is
present in.  I have survived until now without this capability, but
won't object to its addition to the language, since opposing any
feature would not be in the spirit of Common Lisp.

  Rob

∂04-Apr-85  1812	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: INTERN and "intern" -- the unwise choice of terminology   
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 4 Apr 85  18:12:27 PST
Date:  Thu, 4 Apr 85 21:06 EST
From:  Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject:  Re: INTERN and "intern" -- the unwise choice of terminology
To:  common-lisp@SU-AI.ARPA
In-Reply-To:  Message of 4 Apr 85 10:42 EST from "Rob MacLachlan"
Message-ID:  <850405020617.786913@MIT-MULTICS.ARPA>

    Date:  4 April 1985 10:42 est
    From:  Rob MacLachlan <RAM at CMU-CS-C>
    Subject:  INTERN and "intern" -- the unwise choice of terminology

        I don't think that a home-package-setting operation is well
    defined, at least without some constraints.  The system would
    certainly get confused if you set the home package to a package that
    the symbol was not accessible in, and it would be dubious to set the
    home package to a package where the symbol is not present (as opposed
    to inherited).

        If you impose these requirements, setting the home package starts
    to sound a great deal like IMPORT.  I think that the proposal to have
    IMPORT set the home package if there is none makes a great deal of
    sense.  The effect of IMPORT is really about the same as old-style
    intern on a symbol.  I don't really like the idea of INTERN having
    obscure side-effects such as setting the home package, since it is
    something that the system often does without an explicit request.

      Rob

I prefer this proposal to White's `setf with constraints' proposal.

∂04-Apr-85  2042	FAHLMAN@CMU-CS-C.ARPA 	Intern 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Apr 85  20:42:07 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 4 Apr 85 23:42:03-EST
Date: Thu, 4 Apr 1985  23:42 EST
Message-ID: <FAHLMAN.12100618376.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   common-lisp@SU-AI.ARPA
Subject: Intern


OK, I'd like to end this Intern nonsense before my mailbox overflows.
Could everyone live with the following:

1. Intern never messes with the Symbol-Package cell.

2. Import fills in the symbol's Symbol-Package cell with the importing
package if that cell is NIL.

3. In the next edition of the manual we fix up the description of
symbols being "interned in a package" either by flushing this whole
concept or by finding a more precise term for it.

If we do all of that, I don't think it is redundant to add a Setf for
Symbol-Package (with a check that the symbol is accessible in its home
package), but I wouldn't fight to the death if people wanted to include
this mechanism as well.  I would fight an attempt to add a non-checking
Setf of Symbol-Package.

-- Scott

∂04-Apr-85  2046	FAHLMAN@CMU-CS-C.ARPA 	Minor correction 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Apr 85  20:46:35 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 4 Apr 85 23:46:36-EST
Date: Thu, 4 Apr 1985  23:46 EST
Message-ID: <FAHLMAN.12100619208.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   common-lisp@SU-AI.ARPA
Subject: Minor correction


Where I spoke of allowing SETF of Symbol-Package with a check for
accessibility of the symbol in that package, I should have said
"presence" of the symbol.

-- Scott

∂04-Apr-85  2056	FAHLMAN@CMU-CS-C.ARPA 	NIL and DEFCONSTANT [Gall: Bug Report]    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Apr 85  20:56:47 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 4 Apr 85 23:56:22-EST
Date: Thu, 4 Apr 1985  23:56 EST
Message-ID: <FAHLMAN.12100620981.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Nick Gall <Gall@MIT-MULTICS.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: NIL and DEFCONSTANT [Gall: Bug Report]
In-reply-to: Msg of 3 Apr 1985  23:52-EST from Nick Gall <Gall at MIT-MULTICS.ARPA>


    I agree with Moon also.  And I agree that pg.  56 is ok too.  It is pg.
    69 that is a little shaky, and pg.  324 DEFINITELY states that NIL and T
    are defined with DEFCONSTANT.

OK, we all agree that it is an error to redefine built-in constants,
whether or not we think of them as having been created by defconstant.
The manual should be made consistent on this point.

-- Scott

∂05-Apr-85  1106	Moon@SCRC-STONY-BROOK.ARPA 	Intern 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 5 Apr 85  11:06:46 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 209748; Fri 5-Apr-85 14:04:36-EST
Date: Fri, 5 Apr 85 14:06 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Intern
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12100618376.BABYL@CMU-CS-C.ARPA>
Message-ID: <850405140606.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 4 Apr 1985  23:42 EST
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

    OK, I'd like to end this Intern nonsense before my mailbox overflows.
    Could everyone live with the following:

    1. Intern never messes with the Symbol-Package cell.

    2. Import fills in the symbol's Symbol-Package cell with the importing
    package if that cell is NIL.

    3. In the next edition of the manual we fix up the description of
    symbols being "interned in a package" either by flushing this whole
    concept or by finding a more precise term for it.

    If we do all of that, I don't think it is redundant to add a Setf for
    Symbol-Package (with a check that the symbol is accessible in its home
    package), but I wouldn't fight to the death if people wanted to include
    this mechanism as well.  I would fight an attempt to add a non-checking
    Setf of Symbol-Package.

This is fine with me.

Hey, I don't even have to make any changes in my implementation to conform
to this clarified specification!

∂05-Apr-85  1227	REM%IMSSS.#Pup@SU-SCORE.ARPA 	Any complete CL implementations??  
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Apr 85  12:27:01 PST
Received: from IMSSS by Score with Pup; Fri 5 Apr 85 12:26:35-PST
Date:  5 Apr 1985 1224-PST
From: Rem@IMSSS
Subject: Any complete CL implementations??
To:   COMMON-LISP%SU-AI@SCORE

At this time, has anybody completely 100% implemented Common LISP
on any machine at all? I mean every single function in the manual
without exception, every single feature in the manual (either as
documented in manual or as amended more recently for next edition)
for each such function, and every general capability such as all
datatypes and closures of lexical variabls etc. etc.?

If not, what is the best anybody has done to date? Would anybody with
at least 50% of Common LISP (by some reasonable way of measuring)
please send me a brief description of their implementation (CPU and
operating system, % of CL implemented, list of major capabilities
not implemented yet) for my curiosity?

SCORE's mailbridge doesn't put correct return address, so reply via any of:
Local on IMSSS: REM
Anywhere on SU-NET with PUPMAIL: REM@IMSSS
Anywhere on Arpanet: REM%IMSSS@SCORE
Anywhere else on TCP/IP Arpa-Internet: REM@MIT-MC.ARPA (forwards to IMSSS)
-------

∂05-Apr-85  1740	@SU-SCORE.ARPA:HEDRICK@RUTGERS.ARPA 	Re: Any complete CL implementations?? 
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Apr 85  17:40:48 PST
Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Fri 5 Apr 85 17:40:02-PST
Date: 5 Apr 85 20:39:53 EST
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: Any complete CL implementations??
To: rem%imsss@SU-SCORE.ARPA
cc: COMMON-LISP%SU-AI@SU-SCORE.ARPA
In-Reply-To: Message from "Rem@IMSSS" of 5 Apr 85 15:24:00 EST

It is very hard to evaluation how much is finished, as there is no
evaluation suite.  We have an implementation for TOPS-20, based on
the CMU Spice Lisp implementation.  Here are the known bugs and
omissions, but it is certainly possible that there are things we
don't know about.  This prefixed by * will be fixed fairly soon.

*Supposedly the same args can be used for &rest and &key.  This fails
(in interpreted code only; the compiler can handle this).

Complex numbers are not implemented.

When doing file-position, and maybe clrbfo and clrbfi, maybe
we should clear lookahead and other status.

Fix GRINDEF of macros to reproduce the DEFMACRO format, 
instead of using the undocumented MACRO format.

Fix ` to produce a macro instead of expanding at read time.
That way GRINDEF can print them properly.

It should be possible to continue after a break initiated by ↑B.

Printing of circular objects is not implemented.

INSPECT is not really implemented.

RANDOM don't seem very hot: There seems to be too many repeated values.
Maybe this is word-size dependent or something.

Use | | instead of slashification in printing atom names.

Missing :copier option for defstruct

Missing &environment option for defmacro

In Arith, function that could benefit from handcoding:
  dramatic benefit: floor, ceiling, round, mod, logcount
  some benefit: rem, ffloor, fceiling, ftruncate, fround

RATIONALIZE is currently the same as RATIONAL.

Compiler can't handle closures.  Programs will work, but functions
requiring closures will be interpreted.

Missing DEFTYPE

*READ barfs when CL:CLISP is typed in.

*TRUNCATE doesn't return correct remainders for some values.  Eg, -0.7
and -0.3.
-------

∂07-Apr-85  2026	FAHLMAN@CMU-CS-C.ARPA 	Any complete CL implementations??    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 7 Apr 85  20:26:39 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 7 Apr 85 23:26:32-EST
Date: Sun, 7 Apr 1985  23:26 EST
Message-ID: <FAHLMAN.12101401976.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Rem @ MIT-MC.ARPA
Cc:   COMMON-LISP@SU-AI.ARPA
Subject: Any complete CL implementations??
In-reply-to: Msg of 5 Apr 1985  15:24-EST from Rem at IMSSS


Our CMU version of Common Lisp on the Perq is essentially complete
except for complex numbers.  These have now been coded, and will
probably be added to our system this week.  By "essentially complete", I
mean that nothing big is missing, though from time to time we discover
that something has slipped through the cracks.  CCASE and CTYPECASE are
still among the missing, I think.  I cannot claim that our system is
believed to be a 100% complete and correct implementation.  A number of
bugs have been discovered and not yet fixed, and the whole system is in
need of a systematic testing.

A number of companies have started with our code and have had a lot more
manpower for testing and fixing, so I wouldn't be surprised if a number
of implementations are as complete as ours and a good deal more
polished.  There is not much reason for anyone following this route to
end up with a less-than-complete Common Lisp -- once the basics are up,
we can hand them the code for the rest.  It is usually the
implementations that try to bend some existing Lisp into a Common Lisp
that end up stuck at 90% compatibility.

-- Scott

∂08-Apr-85  0723	RAM@CMU-CS-C.ARPA 	Probe-File and proposed extension.  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Apr 85  07:23:33 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Mon 8 Apr 85 10:23:37-EST
Date: Mon, 8 Apr 1985  10:23 EST
Message-ID: <RAM.12101521600.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   common-lisp@SU-AI.ARPA
Subject: Probe-File and proposed extension. 


Query:
    Should Probe-File never signal an error, even if it is given a
namestring which is malformed?

Proposal:
    There needs to be some way to determine whether a file name is
legal for output.  I brought this issue up once before on this mailing
list, but I think the discussion died.  I am bringing it up again
because we need something of the sort in Spice Lisp, so I am going to
implement it.  My proposed solution is the following:  Probe-File
should take a direction argument, which defaults to :input.  The
semantics of Probe-File would be to return the pathname which would be
used if the file was opened in that direction, and to return NIL if
the open would fail.  Secondary query: Should the direction argument
be a keyword or an optional?  I favor an optional, since I can't think
of any other arguments that want to be added to Probe-File.

  Rob

∂08-Apr-85  0821	gls%AQUINAS.TMC@Think 	NIL and DEFCONSTANT [Gall: Bug Report]    
Received: from [10.4.0.6] by SU-AI.ARPA with TCP; 8 Apr 85  08:16:26 PST
Received: by Think.ARPA with CHAOS id AA14362; Mon, 8 Apr 85 11:13:45 est
Date: Mon, 8 Apr 85 11:16 EST
From: Guy Steele <gls%AQUINAS.TMC@Think>
Subject: NIL and DEFCONSTANT [Gall: Bug Report]
To: Gall%MULTICS.MIT@Think
Cc: common-lisp@SU-AI.ARPA, gls%AQUINAS.TMC@Think
In-Reply-To: <FAHLMAN.12100620981.BABYL@CMU-CS-C.ARPA>

Maybe a right attitude to take is that it is an error
to execute any compiled code that refers to a DEFCONSTANT'ed
name that has been re-DEFCONSTANT'ed to a different (non-EQL?)
value since the code was compiled.

That would say that it is okay to (DEFCONSTANT T 43), but then
you had better not execute any system code that refers to T.
But the evaluator probably refers to T, so in practice you had
simply better not do it.
--Guy

∂08-Apr-85  1134	Moon@SCRC-STONY-BROOK.ARPA 	Probe-File and proposed extension.   
Received: from [18.26.0.206] by SU-AI.ARPA with TCP; 8 Apr 85  11:34:38 PST
Received: from WAIKATO by ZERMATT via CHAOS with CHAOS-MAIL id 2202; Mon 8-Apr-85 14:32:39-EST
Received: from SCRC-EUPHRATES by WAIKATO via CHAOS with CHAOS-MAIL id 91565; Mon 8-Apr-85 14:32:07-EST
Date: Mon, 8 Apr 85 14:33 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Probe-File and proposed extension. 
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12101521600.BABYL@CMU-CS-C.ARPA>
Message-ID: <850408143305.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 8 Apr 1985  10:23 EST
    From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>


    Query:
	Should Probe-File never signal an error, even if it is given a
    namestring which is malformed?

    Proposal:
	There needs to be some way to determine whether a file name is
    legal for output.  I brought this issue up once before on this mailing
    list, but I think the discussion died.  I am bringing it up again
    because we need something of the sort in Spice Lisp, so I am going to
    implement it.  My proposed solution is the following:  Probe-File
    should take a direction argument, which defaults to :input.  The
    semantics of Probe-File would be to return the pathname which would be
    used if the file was opened in that direction, and to return NIL if
    the open would fail.  

What's wrong with calling OPEN and handling the error when it fails?  Since
I don't understand the desired application, I don't know whether my question
makes sense.

"Common Lisp does not have a standard way to handle errors" is not an acceptable
answer.  It should get one.

			  Secondary query: Should the direction argument
    be a keyword or an optional?  I favor an optional, since I can't think
    of any other arguments that want to be added to Probe-File.

I can think of two other arguments right off the bat; make it a keyword.


∂08-Apr-85  1156	RAM@CMU-CS-C.ARPA 	Probe-File and proposed extension.  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Apr 85  11:56:07 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Mon 8 Apr 85 14:55:43-EST
Date: Mon, 8 Apr 1985  14:55 EST
Message-ID: <RAM.12101571128.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Probe-File and proposed extension. 
In-reply-to: Msg of 8 Apr 1985  14:33-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>


    There are circumstances where being able to validate a filename as
potentially writable without actually writing that file would be
useful.  

The specific problem I want to solve involves the the "Visit File"
command in Hemlock.  If you visit a file that exists, you read the
file, and the pathname associated with the buffer becomes the truename
of the file; no problem there.  The question is what do you do if
Probe-File of the filename is false?  Does this mean that the file
simply doesn't exist, or does it mean that the filename is somehow
broken?  An example of a broken filename would be one with a
nonexistant directory or device.

    If the filename is broken it would be useful to be able to
tell the user this when he visits the file, rather than getting some
error when he tries to save it.  It is also useful to be able to get
the name of the file that you expect to be created, since then you can
set the buffer pathname to that, rather than leaving it a relative
pathname until the file is actually created.

  Rob

∂08-Apr-85  1208	greek@DEC-HUDSON 	More on PROBE-FILE.   
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 8 Apr 85  12:07:56 PST
Date: Mon, 08 Apr 85 15:05:05 EST
From: greek@DEC-HUDSON
Subject: More on PROBE-FILE.
To: common-lisp@su-ai

Just got Dave Moon's message about Rob's proposal for PROBE-FILE.
Although I certainly agree that Common LISP needs an error
handling facility, I don't want to have to use it to investigate
whether or not a file exists.  That's a basic file operation for
which we've already attempted to account.  Let's fix up the way
we do it, not just punt it.

- Paul

∂08-Apr-85  1208	greek@DEC-HUDSON 	PROBE-FILE  
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 8 Apr 85  12:08:25 PST
Date: Mon, 08 Apr 85 15:02:22 EST
From: greek@DEC-HUDSON
Subject: PROBE-FILE
To: common-lisp@su-ai

Rob's proposal makes sense.  A few comments:

1.  Yup, use a keyword, namely :DIRECTION.

2.  If we believe in :DIRECTION for PROBE-FILE, then we have to admit
    that :DIRECTION :PROBE makes no sense for OPEN, because probing
    is orthogonal to direction.  I suggest we either add :PROBE T
    as another keyword to OPEN, or, better yet, remove the feature
    from OPEN.

3.  PROBE-FILE needs to tell me more.  I want to know if I can't get
    at the file because:
      a)  the file spec is bad.
      b)  the device doesn't exist.
      c)  the directory doesn't exist.
      d)  I don't have sufficient access privilege.
      e)  etc., etc.

The basic need addressed by Rob is a real one:  Is this file spec good,
can I get to the file, and what can I do to it (read, write, etc).

- Paul

∂08-Apr-85  1222	RAM@CMU-CS-C.ARPA 	PROBE-FILE 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Apr 85  12:22:46 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Mon 8 Apr 85 15:22:27-EST
Date: Mon, 8 Apr 1985  15:22 EST
Message-ID: <RAM.12101576001.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   greek@DEC-HUDSON.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: PROBE-FILE
In-reply-to: Msg of 8 Apr 1985  15:02-EST from greek at DEC-HUDSON


    A while back when bogosity in the file system chapter was being
discussed on this list, Moon proposed that :direction :probe be
flushed, and everyone seemed to agree.

  Rob

∂08-Apr-85  1234	RAM@CMU-CS-C.ARPA 	PROBE-FILE 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Apr 85  12:33:59 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Mon 8 Apr 85 15:33:19-EST
Date: Mon, 8 Apr 1985  15:33 EST
Message-ID: <RAM.12101577955.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   greek@DEC-HUDSON.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: PROBE-FILE
In-reply-to: Msg of 8 Apr 1985  15:02-EST from greek at DEC-HUDSON


    The issue of how to get back more information about what is wrong
with a file was where we got bogged down before.  I think that error
systems are the called for when you start to consider that sort of
issue.  Any enumeration of all the things that can go wrong with
writing a file will also probably be hopelessly implementation
dependent.  Unless you can come up with a simple, highly esthetic
proposal, I think we should stick with NIL for failure.

    I suppose we could return an error-message string as a second
value, but anything along those lines seems like a sort of half-way
measure to me.

  Rob

∂08-Apr-85  1345	REM@IMSSS 	error-protected OPEN isn't a good way to fake a probe 
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Apr-08 13:38:39 PST (=GMT-8hr)
Date: 1985 April 08 13:37:02 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132123230137.G0465
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To:Moon@SCRC-STONY-BROOK.ARPA
CC:COMMON-LISP@SU-AI.ARPA,RAM@CMU-CS-C.ARPA
Subject: error-protected OPEN isn't a good way to fake a probe
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM@MIT-MC.ARPA

  |Date: Mon, 8 Apr 85 14:33 EST
  |From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
  |Subject: Probe-File and proposed extension. 
  |To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
  |cc: common-lisp@SU-AI.ARPA
  |	There needs to be some way to determine whether a file name is
  |    legal for output.
  |What's wrong with calling OPEN and handling the error when it fails?  Since
  |I don't understand the desired application, I don't know whether my question
  |makes sense.
That's unacceptable. Suppose you have an application program that
wants to write two output files (for example, binary and listing
output from assembler or compiler) under luser-control (one or both
names might be wrong, and this is common enough to protect against in
a clean way). The program wants to check both files for validity
before opening either. If you handle error when OPEN fails, then if
the first name is good and the second bad, by the time you find out
the second is bad you have already made the mistake of starting to
create the first file when the process can't finish and the file must
then be garbage. It is therefore necessary to probe both files before
opening either (or at least probe all but one and then
error-protected-OPEN the remaining; but probing all of them is cleaner).

∂08-Apr-85  1446	Moon@SCRC-STONY-BROOK.ARPA 	Probe-File and proposed extension.   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Apr 85  14:45:43 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 211090; Mon 8-Apr-85 17:00:45-EST
Date: Mon, 8 Apr 85 17:38 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Probe-File and proposed extension. 
To: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>,
    Rob MacLachlan <RAM@CMU-CS-C.ARPA>, greek@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850408143305.9.MOON@EUPHRATES.SCRC.Symbolics.COM>,
             <RAM.12101571128.BABYL@CMU-CS-C.ARPA>,
             The message of 8 Apr 85 15:02-EST from greek at DEC-HUDSON,
             The message of 8 Apr 85 15:05-EST from greek at DEC-HUDSON,
             <RAM.12101576001.BABYL@CMU-CS-C.ARPA>,
             <RAM.12101577955.BABYL@CMU-CS-C.ARPA>
Message-ID: <850408173849.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 8 Apr 85 14:33 EST
    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>

	Date: Mon, 8 Apr 1985  10:23 EST
	From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>

	Query:
	    Should Probe-File never signal an error, even if it is given a
	namestring which is malformed?

No, it should signal lots of errors.

	Proposal:
	    There needs to be some way to determine whether a file name is
	legal for output.  I brought this issue up once before on this mailing
	list, but I think the discussion died.  I am bringing it up again
	because we need something of the sort in Spice Lisp, so I am going to
	implement it.  My proposed solution is the following:  Probe-File
	should take a direction argument, which defaults to :input.  The
	semantics of Probe-File would be to return the pathname which would be
	used if the file was opened in that direction, and to return NIL if
	the open would fail.  

    What's wrong with calling OPEN and handling the error when it fails?  Since
    I don't understand the desired application, I don't know whether my question
    makes sense.

Answered below.

    "Common Lisp does not have a standard way to handle errors" is not an acceptable
    answer.  It should get one.

    Date: Mon, 8 Apr 1985  14:55 EST
    From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>

	There are circumstances where being able to validate a filename as
    potentially writable without actually writing that file would be
    useful.  

    The specific problem I want to solve involves the the "Visit File"
    command in Hemlock.  If you visit a file that exists, you read the
    file, and the pathname associated with the buffer becomes the truename
    of the file; no problem there.  The question is what do you do if
    Probe-File of the filename is false?  Does this mean that the file
    simply doesn't exist, or does it mean that the filename is somehow
    broken?  An example of a broken filename would be one with a
    nonexistant directory or device.

	If the filename is broken it would be useful to be able to
    tell the user this when he visits the file, rather than getting some
    error when he tries to save it.  

I see.  In our implementation, the ambiguous phrase (actually lifted
from the old Lisp Machine manual) "if there is no file named" in the
documentation of PROBE-FILE is interpreted to mean that only a
file-not-found error returns NIL; any other error, such as
directory-not-found, host-not-up, name-too-long, etc. is signalled in
the normal way.  Thus PROBE-FILE serves as a test for whether you'll be
able to write the file, assuming you have access to write, the host is
still up when you try to write, the disk hasn't filled up by then, etc.
Another way of saying this is that PROBE-FILE returns NIL without
signalling an error if it would be possible for the file to exist at
some future time (well, this is still ambiguous, after all someone could
create a directory, rename a device, buy a new computer, or whatever).

I think this means that our PROBE-FILE does everything your Visit File
command needs.

But I see that others could interpret the Common Lisp manual differently.
I suppose the manual has to be ambiguous because anything more specific
might be unimplementable on some file system!  I think it would be better
for you to fix your PROBE-FILE (to signal errors other than file-not-found)
than to change its arguments to make it optional to do so.

				     It is also useful to be able to get
    the name of the file that you expect to be created, since then you can
    set the buffer pathname to that, rather than leaving it a relative
    pathname until the file is actually created.

Agreed.  Our understanding is that MERGE-PATHNAMES is how relative
pathnames get expanded.  The manual doesn't say anything about relative
pathnames, but I don't see how anything but MERGE-PATHNAMES could expand
them, since they have to be relative to some default.  But maybe you
mean something different by "relative pathnames" than I; after all, the
manual doesn't define the term.  I mean pathnames with relative directory
names, which start at some default directory in the tree of directories,
rather than starting at the root.  In Unix, all pathnames that don't start
with a slash.

    Date: Mon, 08 Apr 85 15:02:22 EST
    From: greek@DEC-HUDSON
    ....
    3.  PROBE-FILE needs to tell me more.  I want to know if I can't get
	at the file because:
	  a)  the file spec is bad.
	  b)  the device doesn't exist.
	  c)  the directory doesn't exist.
	  d)  I don't have sufficient access privilege.
	  e)  etc., etc.

    The basic need addressed by Rob is a real one:  Is this file spec good,
    can I get to the file, and what can I do to it (read, write, etc).

Agreed, but see below.

    Although I certainly agree that Common LISP needs an error
    handling facility, I don't want to have to use it to investigate
    whether or not a file exists.  

Why not?

    That's a basic file operation for which we've already attempted to
    account.  Let's fix up the way we do it, not just punt it.

Why is using the error-handling facility considered punting?

    Date: Mon, 8 Apr 1985  15:22 EST
    From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>

	A while back when bogosity in the file system chapter was being
    discussed on this list, Moon proposed that :direction :probe be
    flushed, and everyone seemed to agree.

I still think so.  It should exist only as an internal implementation
detail of PROBE-FILE in some implementations.

    Date: Mon, 8 Apr 1985  15:33 EST
    From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>

	The issue of how to get back more information about what is wrong
    with a file was where we got bogged down before.  I think that error
    systems are the called for when you start to consider that sort of
    issue.  Any enumeration of all the things that can go wrong with
    writing a file will also probably be hopelessly implementation
    dependent.  

I agree.  Look at Greek's list above, for example, especially item (e).

		Unless you can come up with a simple, highly esthetic
    proposal, I think we should stick with NIL for failure.

	I suppose we could return an error-message string as a second
    value, but anything along those lines seems like a sort of half-way
    measure to me.

I don't think a string is what is going to be wanted in many cases, since
it is not program-understandable.

∂08-Apr-85  1452	Moon@SCRC-STONY-BROOK.ARPA 	error-protected OPEN isn't a good way to fake a probe    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Apr 85  14:52:30 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 211097; Mon 8-Apr-85 17:08:39-EST
Date: Mon, 8 Apr 85 17:46 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: error-protected OPEN isn't a good way to fake a probe
To: REM@MIT-MC.ARPA
cc: COMMON-LISP@SU-AI.ARPA, RAM@CMU-CS-C.ARPA
In-Reply-To: SU-IMSSS.REM.A132123230137.G0465
Message-ID: <850408174655.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    From: Robert Elton Maas <REM@IMSSS.SU.EDU>

      |Date: Mon, 8 Apr 85 14:33 EST
      |From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
      |Subject: Probe-File and proposed extension. 
      |To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
      |cc: common-lisp@SU-AI.ARPA
      |	There needs to be some way to determine whether a file name is
      |    legal for output.
      |What's wrong with calling OPEN and handling the error when it fails?  Since
      |I don't understand the desired application, I don't know whether my question
      |makes sense.
    That's unacceptable. Suppose you have an application program that
    wants to write two output files (for example, binary and listing
    output from assembler or compiler) under luser-control (one or both
    names might be wrong, and this is common enough to protect against in
    a clean way). The program wants to check both files for validity
    before opening either. If you handle error when OPEN fails, then if
    the first name is good and the second bad, by the time you find out
    the second is bad you have already made the mistake of starting to
    create the first file when the process can't finish and the file must
    then be garbage. It is therefore necessary to probe both files before
    opening either (or at least probe all but one and then
    error-protected-OPEN the remaining; but probing all of them is cleaner).

This is what the :ABORT argument to CLOSE is for.

∂08-Apr-85  1531	RAM@CMU-CS-C.ARPA 	Probe-File and proposed extension.  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Apr 85  15:30:23 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Mon 8 Apr 85 18:29:59-EST
Date: Mon, 8 Apr 1985  18:29 EST
Message-ID: <RAM.12101610106.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA, greek@DEC-HUDSON.ARPA
Subject: Probe-File and proposed extension. 
In-reply-to: Msg of 8 Apr 1985  17:38-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>


    The point about relative pathnames is the following: When you
actually write a file, Open resolves any relative pathname down to an
absolute pathname.  Any implementation that allows writing relative
pathnames must have some way to map the relative pathname to an
absolute pathname.  This mapping is not necessarily the same as merge
pathnames, and in any case, there is no way in Common Lisp to
determine what the defaults are.

    In Spice Lisp, when you open a file for write, Open first looks
for any file with that name on the default search list, and if found,
overwrites it, otherwise it creates a file in the current directory.
I will argue that this is the right semantics in our implementation,
and it is clearly implementation dependent.

    Regardeless of the error issue, it would be useful to be able to
default a pathname for output in this fashion.

    As for the error issue, Spice Lisp currently does exactly what you
suggest.  A user complained that this was not what the manual said it
should do.  I tried both the Dec-20 Clisp and the Kyoto Common Lisp
implementations, and they both refused to signal errors, no matter
what garbage you gave them.  I decided at this point that the issue
was unclear, but that the Spice Lisp implementation was probably
wrong.

  Rob

∂08-Apr-85  1719	card.pa@Xerox.ARPA 	Re: Arg count checking   
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 8 Apr 85  17:16:40 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 APR 85 17:07:23 PST
Date: 8 Apr 85 17:06 PST
From: card.pa@Xerox.ARPA
Subject: Re: Arg count checking
In-reply-to: masinter.pa's message of 1 Apr 85 01:00 PST
To: masinter.pa@Xerox.ARPA
cc: bug-1100@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA

Larry's message had an idea that coud be developed to handle both what I
take to be the motivations of arg count checking and the motivations for
optional arguments and more.

1. I remember that programming in Stanford Lisp 1.6, the mismatched
number of argument was one of the most effective checks for getting out
nuissance bugs quickly, especially the kind that comes where you change
the arguments of the callee and miss some occurrences of calls to it.

2. The main offsetting advantage from giving this up in Interlisp-D
seems to be that for functions with complicated arguments that are
infrequently used.  A simple calling sequnce is available for simple
calls, more complicated calls for complicated situations.  But there
would seem to be be more graceful (from the point of view of the program
reflecting the user's intentions) methods of achieving this.

3. It is certainly eaiser for the programmer to call

	(NSPRINT 'MYPRINTER)

than to have to write

	(NSPRINT 'MYPRINTER NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL).  

Thus optional arguments are handy.  But they are not really handy enough
because

	(NSPRINT 'MYPRINTER NIL NIL NIL NIL NIL NIL NIL NIL T)

is still required to request stapling on the printed output.  This call
is not programmable without reference to the manual or a system aid such
as ?=.  It is a likely location for error (miscouting the arguments) and
it is not readable by someone looking over the code.

If (1) arguments could be addressed by argument name and (2) could be
optional, then such problems would disappear.  A notation that would
stay within the Interlisp tradition, would be to pattern it after
DLAMBDA declarations in DECL.  Thus OPTIONAL would become a property of
arguments in the same way as FIXP.

DEFINEQ
((NSPRINT
	(LAMBDA     (PRINTER
				(FILE.NAME OPTIONAL)
				(DOCUMENT.NAME OPTIONAL)
				(DOCUMENT.CREATION.DATE OPTIONAL)
				(RECIPIENT.NAME OPTIONAL)
				(#COPIES OPTIONAL)
				(MEDIUM OPTIONAL)
				(PRIORITY OPTIONAL)
				(STAPLE? OPTIONAL)
				(TWO.SIDED OPTIONAL)))))

implements a function where the first argument PRINTER is mandatory and
the remaining are all optional.

The function could be called with the syntax

	(NSPRINT 'MYPRINTER STAPLE?=T)

or perhaps a prefix syntax syntax such as

	(NSPRINT 'MYPRINTER (& STAPLE? T))

or

	(NSPRINT 'MYPRINTER / STAPLE? T) .

ANY argument ought to be callable this way.  (A more elegant proposal
might even be able to encompass the current syntax of (FOR X IN L
SUCHTHAT ...) as an instance, thus serving as a unifying abstraction for
Interlisp syntax).  Of course, the OPTIONAL property would be made to
fit into DECL as just one more property:

	(DLAMBDA ((A LISTP SPECIAL )
			     (B FIXP LOCAL OPTIONAL))  . . . ).

Arguments described by name and optional arguments would probably be a
slight bit slower than fixed arguments, but (1) this would be well worth
the convenience and readability is most cases (e.g. NSPRINT).  (2) The
fixed argument called by place would still be about as the same speed as
they were, probably, and (3) Fast versions of complicated argument calls
where small gains in speed were very important would be programmed in
fast versions, as at present  (FRPLACA).

Thus both bug detection and optional argument calling flexibility can be
had within a unified framework that generalizes both.  It would seem
that one can car one's cake and cons it too.

∂08-Apr-85  1736	KMP@SCRC-STONY-BROOK.ARPA 	PROBE-FILE   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Apr 85  17:35:47 PST
Received: from SCRC-RIO-DE-JANEIRO by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 211220; Mon 8-Apr-85 19:42:56-EST
Date: Mon, 8 Apr 85 20:19 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: PROBE-FILE
To: greek@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA, Moon@SCRC-STONY-BROOK.ARPA
In-Reply-To: The message of 8 Apr 85 15:02-EST from greek at DEC-HUDSON
Message-ID: <850408201917.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Mon, 08 Apr 85 15:02:22 EST
    From: greek@DEC-HUDSON

    Rob's proposal makes sense.  A few comments:
    ...
    3.  PROBE-FILE needs to tell me more.  I want to know if I can't get
	at the file because:
	  a)  the file spec is bad.
	  b)  the device doesn't exist.
	  c)  the directory doesn't exist.
	  d)  I don't have sufficient access privilege.
	  e)  etc., etc.

    The basic need addressed by Rob is a real one:  Is this file spec good,
    can I get to the file, and what can I do to it (read, write, etc).

It is precisely because of this need to return a multitude of kinds of 
information that the Lisp Machine has gone away from having more functions 
to do this kind of investigation and toward using errors to convey this
information. In the Lisp Machine's not-really-new-any-more "new error system",
failure is flavorized so that a lot of kinds of information can be extracted
depending on what the caller needs to know. This also has the important
advantage that users who don't realize they need to detect odd situations
will have their code stopped cold in its tracks rather than having it 
stumble on and notice a problem only later.

For example, in Lisp Machine lisp, if you want to know if the failure was 
due to device doesn't exist, you can take the error object and do:
 (TYPEP error-object 'FS:DEVICE-NOT-FOUND)
or if you want to know if a directory was not found, you do:
 (TYPEP error-object 'FS:DIRECTORY-NOT-FOUND)
Or if you want more general information you can do:
 (TYPEP error-object 'FS:FILE-LOOKUP-ERROR)
which will find both FS:DEVICE-NOT-FOUND errors and FS:DIRECTORY-NOT-FOUND
errors. This allows error signallers to be quite exact about the error
that occurred (by mixing in as many error types as are known to be relevant)
and still have a fair chance that the handler will do something reasonable
(by allowing it to look for more specific condition types than are actually
signal.

If you compare this to what you're asking for PROBE-FILE, you quickly
realize that there is no obvious way to stop a huge explosion of functions
named things like:
 (PROBE-FILE-RETURNING-NIL-FOR-BAD-PATHNAME ...)
 (PROBE-FILE-RETURNING-NIL-FOR-BAD-DEVICE-BUT-ERRING-ON-OTHER-PATHNAMES ...)
 ...
or a huge explosion of keywords as in:
 (PROBE-FILE ... :ALLOW-ERROR-IF '(:BAD-DEVICE :BAD-DIRECTORY))
or a huge explosion of return values as in:
 (PROBE-FILE pathname) => pathname-or-NIL,
		          device-not-found-p,
			  device-not-valid-p,
			  directory-not-found-p,
			  ...
or a huge explosion of keywords in return values such as
 (PROBE-FILE pathname) => pathname-or-NIL, reason-keyword (one of 
			   :DEVICE-NOT-FOUND, :DIRECTORY-NOT-AVAILABLE,...)
etc. The problem with these situations is that you are then locked into a
bottomless pit of having to make non-general extensions to the language
every time a new situation comes up. 

In the Lisp Machine case, the definition of PROBEF is fairly simple. It 
returns a pathname if the probe code succeeds and the file was there, 
NIL if the probe code succeeds but no file was there, and errs if the probe
code encounters a problem. How those problems may occur is something
which users know is device dependent and subject to change as new devices
are added or devices change their behavior.  The really nice point is that
flavors were designed to accomodate both the process of change and some 
sense of ambiguity in terms of what the error type is ("Is it a string error
or a file error? hmm. Guess i'll make a new flavor file-string-error so
that people watching for either situation can handle it.") 

So I really think this is something to be relegated to error handling.
Although there's been little discussion on the error handling mailing list,
I did get what I think is a fairly workable proposal out before discussion
died down, so don't worry that we're just talking pipe dreams here.

That's about all I have to say on the subject for now. Over the past
several years using the LispM file system, I've been extremely pleased
with how little I had to think about the target file system because of
the nice abstractions upon which it's based. So my proxy basically goes
to Moon for any further discussion on this subject. Just wanted to say
something supportive since on sheer volume of mail it might have 
appeared he wasn't being believed.

∂08-Apr-85  1937	FAHLMAN@CMU-CS-C.ARPA 	NIL and DEFCONSTANT [Gall: Bug Report]    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Apr 85  19:37:30 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 8 Apr 85 22:37:30-EST
Date: Mon, 8 Apr 1985  22:37 EST
Message-ID: <FAHLMAN.12101655193.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   common-lisp@SU-AI.ARPA
Subject: NIL and DEFCONSTANT [Gall: Bug Report]


Response to Steele:

    Maybe a right attitude to take is that it is an error
    to execute any compiled code that refers to a DEFCONSTANT'ed
    name that has been re-DEFCONSTANT'ed to a different (non-EQL?)
    value since the code was compiled.

Yeah, that seems reasonable.  We want to be able to change the value of
a constant if, for example, we notice a typo, but once something has
been compiled that uses that constant, it is unpredictable which value
you get if you then change the constant.

    That would say that it is okay to (DEFCONSTANT T 43), but then
    you had better not execute any system code that refers to T.
    But the evaluator probably refers to T, so in practice you had
    simply better not do it.

This looks like trouble to me.  I don't think we'd better tell the users
that this is legal but that they'd probably better not do it in
practice.  Unlike us high-powered language designers, mere users are
likely to be confused by this.  Maybe we'd just better tell them that it
is erroneous, wrongheaded, evil, and uncool to do this, and that if they
persist in this practice Father Lisp won't bring them any parentheses
when they hang out their bit buckets on Flag Day.

-- Scott

∂08-Apr-85  1946	fateman%ucbdali@Berkeley 	Re: Arg count checking  
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 8 Apr 85  19:46:22 PST
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.45)
	id AA05969; Mon, 8 Apr 85 19:45:24 pst
Received: by ucbdali.ARPA (4.24/4.42)
	id AA05239; Mon, 8 Apr 85 19:46:33 pst
Date: Mon, 8 Apr 85 19:46:33 pst
From: fateman%ucbdali@Berkeley (Richard Fateman)
Message-Id: <8504090346.AA05239@ucbdali.ARPA>
To: card.pa@Xerox.ARPA, masinter.pa@Xerox.ARPA
Subject: Re: Arg count checking
Cc: bug-1100@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA

A heretical suggestion:

(let ((staple? t)) (nsprint 'mprinter)).

Using dynamic scope and global variables has been widely used in
Interlisp and other systems to great advantage (and disadvantage).

Setting up your default nsprint environment by setq's and then locally
overriding is handy, though I suppose this is possible to do by 
initializing the optional arguments according to whether global variables 
of the same name are bound etc.

∂09-Apr-85  0100	hplabs!perdue%hplabs.csnet@csnet-relay.arpa 	Compilation and package system
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 9 Apr 85  00:59:52 PST
Received: from hplabs by csnet-relay.csnet id ad14103; 9 Apr 85 3:42 EST
Received: by HP-VENUS id AA23590; Mon, 8 Apr 85 18:04:43 pst
Message-Id: <8504090204.AA23590@HP-VENUS>
Date:  8-Apr-85 18:03:48
To: Common-lisp@su-ai.ARPA
Subject: Compilation and package system
From: perdue%hplabs.csnet@csnet-relay.arpa
Source-Info:  From (or Sender) name not authenticated.

It is surprising to me that there has not been discussion of
the problems of compiling when there is a package system.
The specific problem I have in mind is in the handling of
symbols that are referred to in the input text without a package
qualifier.

The user of a Common LISP implementation sees the problem as a
difference between the behavior of a module (file) loaded in its
interpretive form and loaded in its compiled form.  Specifically,
references to symbols will in some cases be resolved differently
depending on whether or not the file was compiled before being loaded.

The source of the problem is that LISP compilers use READ to get
forms to compile and READ loses all information about whether a symbol
was specified with a package qualifier and whether a single or double
colon.  If the file has an IN-PACKAGE at the beginning it is only
pathological cases that cause problems, but if the file does not,
needed information has clearly been lost.

The CLM specifies that loading a compiled file shall be equivalent
to loading an interpretive file, but the packages of symbols in
a compiled file have in effect been DETERMINED AT COMPILE TIME,
and load-time binding can only be faked.

Various heuristics are used by implementations to try to do more
or less the right thing.  For example, any symbol available without
name qualification when read can be assumed to have been named
without a package qualifier.  At loadtime the reference can be
resolved as though it had no qualifier.  But the knowledge of
whether it was actually written with qualification has been lost.
If the module (file) is loaded with a current package different than
the current package when it was compiled, loading of the compiled
version will not necessarily result in references to the same symbols
as loading the interpretive version of the module.
-------

∂09-Apr-85  0448	REM@IMSSS 	I agree, but manual should tell LUSERs why  
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Apr-09 04:46:51 PST (=GMT-8hr)
Date: 1985 April 09 02:54:05 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132124131673.G0390
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To:Fahlman@CMU-CS-C.ARPA
CC:common-lisp@SU-AI.ARPA
Subject: I agree, but manual should tell LUSERs why
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM@MIT-MC.ARPA

  |Date: Mon, 8 Apr 1985  22:37 EST
  |From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
  |Subject: NIL and DEFCONSTANT [Gall: Bug Report]
  |
  |    Maybe a right attitude to take is that it is an error
  |    to execute any compiled code that refers to a DEFCONSTANT'ed
  |    name that has been re-DEFCONSTANT'ed to a different (non-EQL?)
  |    value since the code was compiled.
  |
  |Yeah, that seems reasonable.  We want to be able to change the value of
  |a constant if, for example, we notice a typo, but once something has
  |been compiled that uses that constant, it is unpredictable which value
  |you get if you then change the constant.
I agree. But more than just saying "it is an error to use code that
has been compiled with one value of a constant in an environment where
that constant now has a different value", we should explain what seems
obvious to us so LUSERs who can't see the obvious can be shown the
obvious and then see it themselves. (This is the sort of thing that
isn't machine-dependent, the same problem would happen on virtually
any system we imagine, thus we CAN say something more than the
mysterious cop-out "it is an error to ...".) We could say something
like "if code is compiled with the constant having one value, but then
the constant is redefined and the previously-compiled code is run, it
will probably use the old value instead of the new value. Accordingly,
it is an error to continue to run the previously-compiled code after
the constant has been redefined, and it is an error to redefine any
commonly-used system constant unless one plans to recompile the whole
LISP system immediately thereafter. It is an error to redefine T or
NIL in any case of course."

  |Maybe we'd just better tell them that it is erroneous, wrongheaded,
  |evil, and uncool to do this, and that if they persist in this practice
  |Father Lisp won't bring them any parentheses when they hang out their
  |bit buckets on Flag Day.
That's the right idea, but of course you are being flip here, the
manual certainly shouldn't be so cutesy as that.

∂09-Apr-85  0451	REM@IMSSS 	READ loses info as to whether package is specified or not, my fix    
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Apr-09 04:49:45 PST (=GMT-8hr)
Date: 1985 April 09 04:49:12 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132124132151.G0365
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To: "perdue%hplabs.csnet"@csnet-relay.arpa
CC: Common-LISP@SU-AI.ARPA
Subject: READ loses info as to whether package is specified or not, my fix
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM@MIT-MC.ARPA

  |Date:  8-Apr-85 18:03:48
  |Subject: Compilation and package system
  |From: perdue%hplabs.csnet@csnet-relay.arpa

  |It is surprising to me that there has not been discussion of
  |the problems of compiling when there is a package system.
  |The specific problem I have in mind is in the handling of
  |symbols that are referred to in the input text without a package
  |qualifier.
  |
  |The user of a Common LISP implementation sees the problem as a
  |difference between the behavior of a module (file) loaded in its
  |interpretive form and loaded in its compiled form.  Specifically,
  |references to symbols will in some cases be resolved differently
  |depending on whether or not the file was compiled before being loaded.

I agree, this may indeed be a serious problem. I think the answer is
to flush the idea that any piece of LISPish text must run exactly the
same interpreted and compiled, and rather say that any correct LISP
program must run the same interpreted and compiled. We define a file
without an IN-PACKAGE at the beginning to NOT be a correct LISP
program. Thus it may still work interpreted, and compiled, although
differently, but the compiler should flag as an warning that it is not
a valid LISP program and might not execute as expected (as it did
interpreted).

∂09-Apr-85  0709	gls%AQUINAS.TMC@Think 	NIL and DEFCONSTANT [Gall: Bug Report]    
Received: from [10.4.0.6] by SU-AI.ARPA with TCP; 9 Apr 85  07:08:58 PST
Received: by Think.ARPA with CHAOS id AA22257; Tue, 9 Apr 85 10:06:22 est
Date: Tue, 9 Apr 85 10:09 EST
From: Guy Steele <gls%AQUINAS.TMC@Think>
Subject: NIL and DEFCONSTANT [Gall: Bug Report]
To: common-lisp@SU-AI.ARPA
Cc: gls%AQUINAS.TMC@Think
In-Reply-To: <FAHLMAN.12101655193.BABYL@CMU-CS-C.ARPA>

Response to Fahlman:

    Response to Steele:

	Maybe a right attitude to take is that it is an error
	to execute any compiled code that refers to a DEFCONSTANT'ed
	name that has been re-DEFCONSTANT'ed to a different (non-EQL?)
	value since the code was compiled.

    Yeah, that seems reasonable.  We want to be able to change the value of
    a constant if, for example, we notice a typo, but once something has
    been compiled that uses that constant, it is unpredictable which value
    you get if you then change the constant.

	That would say that it is okay to (DEFCONSTANT T 43), but then
	you had better not execute any system code that refers to T.
	But the evaluator probably refers to T, so in practice you had
	simply better not do it.

    This looks like trouble to me.  I don't think we'd better tell the users
    that this is legal but that they'd probably better not do it in
    practice.  Unlike us high-powered language designers, mere users are
    likely to be confused by this.  Maybe we'd just better tell them that it
    is erroneous, wrongheaded, evil, and uncool to do this, and that if they
    persist in this practice Father Lisp won't bring them any parentheses
    when they hang out their bit buckets on Flag Day.

All I meant by this is that the evilness of redefining T follows logically
from (1) the proposed rule that allows users to carefully redefine things,
and (2) the fact that EVERYTHING depends on T.  What we tell the user is
another story.  An additional attitude is that it is reasonable for the
system to take a benevolent protective interest in those constants on which
it depends.  (Translation: refuse to change T because everything will break.)

--Guy

∂09-Apr-85  1147	root%bostonu.csnet@csnet-relay.arpa 	Re: Arg count checking 
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 9 Apr 85  11:47:22 PST
Received: from bostonu by csnet-relay.csnet id ab02727; 9 Apr 85 14:30 EST
Received: by bu-cs.ARPA (4.12/4.7)
	id AA12160; Tue, 9 Apr 85 12:55:13 est
Date: Tue, 9 Apr 85 12:55:13 est
From: BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa>
To: card.pa@XEROX.ARPA, masinter.pa@XEROX.ARPA
Subject: Re: Arg count checking
Cc: bug-1100@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA

> Date: 8 Apr 85 17:06 PST
> From: card.pa@XEROX.ARPA
> Subject: Re: Arg count checking
> ....
> DEFINEQ
> ((NSPRINT
> 	(LAMBDA     (PRINTER
> 				(FILE.NAME OPTIONAL)
> 				(DOCUMENT.NAME OPTIONAL)
> 				(DOCUMENT.CREATION.DATE OPTIONAL)
> 				(RECIPIENT.NAME OPTIONAL)
> 				(#COPIES OPTIONAL)
> 				(MEDIUM OPTIONAL)
> 				(PRIORITY OPTIONAL)
> 				(STAPLE? OPTIONAL)
> 				(TWO.SIDED OPTIONAL)))))
> 
> implements a function where the first argument PRINTER is mandatory and
> the remaining are all optional.

I agree but thought at this design stage I could throw my
two cents in. It seems that rather than those redundant OPTIONALs
a default value would be more useful, the fact that it is a list
rather than an atom is sufficient to deduce that this is a keyword
parameter (and it makes the whole thing consistent with PROG.)

That's it...just two cents worth.

	-Barry Shein, Boston University


∂09-Apr-85  1341	DLW@SCRC-STONY-BROOK.ARPA 	Re: Arg count checking 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Apr 85  13:36:33 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 211848; Tue 9-Apr-85 16:29:34-EST
Date: Tue, 9 Apr 85 16:31 EST
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Re: Arg count checking
To: card.pa@XEROX.ARPA, masinter.pa@XEROX.ARPA
cc: bug-1100@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 8 Apr 85 20:06-EST from card.pa@XEROX.ARPA
Message-ID: <850409163106.9.DLW@CHICOPEE.SCRC.Symbolics.COM>

I don't think I understand the point of your message.  What is the
difference between what you are proposing and Common Lisp keyword
arguments, other than syntax?

∂09-Apr-85  1352	DLW@SCRC-STONY-BROOK.ARPA 	Compilation and package system   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Apr 85  13:30:49 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 211844; Tue 9-Apr-85 16:26:09-EST
Date: Tue, 9 Apr 85 16:27 EST
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Compilation and package system
To: perdue%hplabs.csnet@CSNET-RELAY.ARPA, Common-lisp@SU-AI.ARPA
In-Reply-To: <8504090204.AA23590@HP-VENUS>
Message-ID: <850409162744.7.DLW@CHICOPEE.SCRC.Symbolics.COM>

When the compiler compiles a file, it has to know what package to do the
READs in.  If the compiler reads the symbols into the wrong package,
there's no hope.  Our system has a convention that lets you tell the
compiler what package to use.  The same convention tells the editor and
the loader what package to use as well.

∂09-Apr-85  1722	JLW  	Arg cont checking, optionals, keywords, etc 
To:   Card.pa@XEROX.ARPA
CC:   bug-1100@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA    

Common Lisp has already developed a keyword argument syntax, so that
"optionals" may be passed in random order.

Until one actually gets down to implementing that proposal, he may be
frightened away by the thought that it would unduly slow down the
function calling protocol.  I don't think it does (slow the vanilla
case down), but am not inclined to elucidate over network mail.

A major problem for Interlisp-D is, however, the backwards compatiblity
question.  Whereas it may be quite all right to take a function, say,
  (DEFINEQ (FOO (A B C) ...]
and redefine it like
  (DEFINEQ (FOO (&OPTIONAL A B C) ...]
and, I think, even suffer no slowdown.  But what if you really wanted
  (DEFINEQ (FOO (A B &OPTIONAL C) ...]
Then a lot of code may have to be re-written (or perhaps massaged
mechanically) so that calls like (FOO 3) become (FOO 3 NIL).  The
benefits of arg count checking won't be realized without breaking some
already running code.

-- JonL --

∂09-Apr-85  1803	Moon@SCRC-STONY-BROOK.ARPA 	Probe-File and proposed extension.   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Apr 85  17:37:24 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 211990; Tue 9-Apr-85 20:37:10-EST
Date: Tue, 9 Apr 85 20:37 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Probe-File and proposed extension. 
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA, greek@DEC-HUDSON.ARPA
In-Reply-To: <RAM.12101610106.BABYL@CMU-CS-C.ARPA>
Message-ID: <850409203759.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 8 Apr 1985  18:29 EST
    From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>

	The point about relative pathnames is the following: When you
    actually write a file, Open resolves any relative pathname down to an
    absolute pathname.  Any implementation that allows writing relative
    pathnames must have some way to map the relative pathname to an
    absolute pathname.  This mapping is not necessarily the same as merge
    pathnames, and in any case, there is no way in Common Lisp to
    determine what the defaults are.

Well, the defaults for MERGE-PATHNAMES are whatever the program wants to
pass to merge-pathnames as an argument.  I would hope that if OPEN has to
call MERGE-PATHNAMES, it would use *DEFAULT-PATHNAME-DEFAULTS*.  But this
is moot since by relative pathnames you meant something different than I:

	In Spice Lisp, when you open a file for write, Open first looks
    for any file with that name on the default search list, and if found,
    overwrites it, otherwise it creates a file in the current directory.
    I will argue that this is the right semantics in our implementation,
    and it is clearly implementation dependent.

	Regardeless of the error issue, it would be useful to be able to
    default a pathname for output in this fashion.

I see.  This is not covered by the generic file-system model, but that
doesn't mean there is anything wrong with it.  You need an interface to
this implementation-dependent feature, and the question is, should the
interface be defined in an implementation-independent way?  Looked at
that way, the proposal for a :direction keyword to PROBE-FILE seems
pretty reasonable.  Now that I understand it, this seems reasonable to
me, and perhaps it's time for you to make an explicit proposal.

On the other hand, you could always just add a function to Spice Lisp
that is just an implementation-dependent interface to Accent.  Trying
to do file-system-related things in an implementation-independent way
can often be very tricky.  I know of at least one file system that would
have some difficulty implementing this feature (specifically, getting the
version number right), although it probably wouldn't be impossible.

This should go on any lists that are being kept of proposed language
enhancements and clarifications.

	As for the error issue, Spice Lisp currently does exactly what you
    suggest.  A user complained that this was not what the manual said it
    should do.  I tried both the Dec-20 Clisp and the Kyoto Common Lisp
    implementations, and they both refused to signal errors, no matter
    what garbage you gave them.  I decided at this point that the issue
    was unclear, but that the Spice Lisp implementation was probably
    wrong.

I think the Spice Lisp implementation is right.  I don't think any
implementation without an error-handling system can be used as a fair
test of the circumstances in which PROBE-FILE should signal an error.

∂09-Apr-85  1811	JLW  	Meaning of PROBE-FILE for direction output  
To:   moon@SCRC-STONY-BROOK.ARPA, ram@CMU-CS-C.ARPA,
      greek@DEC-HUDSON.ARPA
CC:   common-lisp@SU-AI.ARPA  

There are a couple of problems with using a non-OPENing probe for
output files, which caused the Intelisp-D development group to want
to flush the equivalent [outfilep].  One problem is the obvious one that
when the result is non-null, it can be a guarantee only for a short
interval of time [I'm assuming that even personal workstations will be
having access to shared file servers] that such a file name may be
opened for writing by the caller -- because someone else may sneak in
and open up exactly the file you want.   Another problem stems from a
possible discrepancy between the pathname completion done by the file
system when actually OPENing and when merely probing (without opening)

On the other hand, it appears as though some persons may feel as Paul
does, that using an "error" trap to do normal programming is bad practice.
A reasonable way out of this dilemma is simply to stop calling such signals
"errors", and admit signals as a first class mechanism.  Xerox's Mesa language
has an admirable signalling mechanism, although a little too baroque for
my taste.  The interface definition of any function then requires
a description of the types of input argments, the types of output values
(multple values) and an enumeration of any signals raised.

In pdp10 MacLisp days, all "signals" were raised via calling ERRORs; the
lossage with that approach is the too-limited bandwith of a single signal
(the ERROR signal).

So the "signal" approach would require the client program to actually do an OPEN
and to check for signals as well as the return value; there are numerous ways
to insure that an abort after the actual open will cause a close, but I
wonder what purpose would be served by providing a probe-file for output
operation if th client didn't actually open the file sooner or later anyhow.

-- JonL --

∂09-Apr-85  1915	WHOLEY@CMU-CS-C.ARPA 	Compilation and package system   
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 9 Apr 85  19:15:26 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Tue 9 Apr 85 22:14:16-EST
Date: Tue, 9 Apr 1985  22:14 EST
Message-ID: <WHOLEY.12101913081.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To:   "Daniel L. Weinreb" <DLW%SCRC-Tenex@MIT-MC.ARPA>
CC:   Common-lisp@SU-AI.ARPA, perdue%hplabs.csnet@CSNET-RELAY.ARPA
Subject: Compilation and package system

There are a number of ways to let the compiler know about the package that a
file will be loaded into.  The portable, Common Lisp way to do this is with a
call to In-Package at the beginning of a file, as suggested in CLTL, on page
189.  The Lisp Machine -*- file comment hack (which is used by the editor,
compiler, and loader) has a few drawbacks.

First of all, it is not portable.  People write Common Lisp programs with a -*-
package specification, but these programs must be modified (by adding a real
In-Package to the program text) when they are moved to non-Lisp Machine Common
Lisps.

Secondly, one cannot put all of the information about the packages Use'd or
symbols Import'ed in the file comment.  One cannot accurately fix up the
package environment by looking at the file comment.  I suppose one could hair
it up to include imports and shadows and whatnot (maybe someone already has),
but that just leaves one with more stuff to "translate into Common Lisp" when
he moves his program off of the Lisp Machine.

Finally, the Symbolics Common Lisp Compatibility Package will give an error
when one attempts to load or compile a file with a header something like that
presented below, because it interprets the file comment, and wants to find any
package specified there before reading anything in the file.  In fact, the
first form read may be the one that creates the package, so it may not be there
for the file comment gremlin to interpret.  In-Package is a nice language
feature that Does The Right Thing, but has been rendered useless on the Lisp
Machine by zealous use of file comment magic.

We have adopted the convention that any -*- package specification is for the
editor only, and that the compiler and friends should get stuff out of Lisp
forms.  Thus, a typical Spice Lisp system file might begin with something like:

	;;; -*- Package: Lisp; Log: Code.Log -*-
	;;;
	;;; ...blah blah blah...
	;;;

	(in-package "LISP" :use '("SYSTEM"))

	(export '(things that this file defines))

The editor knows which package to associate with a buffer created when visiting
this file, but the compiler and loader and everyone else just read Lisp forms,
the way Father Lisp wanted them to.

Since the -*- convention is not part of Common Lisp (and perhaps for good
reason), I would encourage EVERYONE writing Common Lisp programs to begin each
file in the way suggested in CLTL.  Smart editors need to know things like the
package (so that functions compiled in the text editor end up in the right
package, for example), however, so it might be worth some effort to standardize
the semantics of -*- file comments.  Unfortunately, I imagine neither the Lisp
Machine community nor the Spice Lisp community is willing to give in.

--Skef

∂09-Apr-85  1958	RICHER@SUMEX-AIM.ARPA 	Re: Arg cont checking, optionals, keywords, etc     
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 9 Apr 85  19:57:50 PST
Date: Tue 9 Apr 85 19:57:32-PST
From: Mark Richer <RICHER@SUMEX-AIM.ARPA>
Subject: Re: Arg cont checking, optionals, keywords, etc 
To: JLW@SU-AI.ARPA
cc: Card.pa@XEROX.ARPA, bug-1100@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA,
    RICHER@SUMEX-AIM.ARPA
In-Reply-To: Message from "Jon White <JLW@SU-AI.ARPA>" of Tue 9 Apr 85 17:22:00-PST

I wonder if Interlisp could have an option where arg checking was optional
or only done on functions with a certain editdate (beyond the date the 
incompatibility is announced) without a penalty to users who set arg checking
to be done always?

mark
-------

∂10-Apr-85  1012	DDYER@USC-ISIB.ARPA 
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 10 Apr 85  10:12:47 PST
FYI:  Adding mandatory/optional argument checking to Interlisp-VAX
would be easy, and incur no additional overhead.
ReSent-Date: 10 Apr 1985 10:12:15 PST
ReSent-From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
ReSent-To: common-lisp@SU-AI.ARPA

Default values for &optional args would require a substantial
rethinking of the function call mechanism, as would &rest and 
&key.

∂10-Apr-85  1024	DCP@SCRC-VALLECITO.ARPA 	What are we talking about anyway?  
Received: from SCRC-VALLECITO.ARPA by SU-AI.ARPA with TCP; 10 Apr 85  10:24:09 PST
Received: from SCRC-NEPONSET by SCRC-VALLECITO via CHAOS with CHAOS-MAIL id 6908; Wed 10-Apr-85 13:22:59-EST
Date: Wed, 10 Apr 85 13:24 EST
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: What are we talking about anyway?
To: Dave Dyer <DDYER@USC-ISIB.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 10 Apr 85 13:12-EST from Dave Dyer <DDYER@USC-ISIB.ARPA>
Message-ID: <850410132431.9.NFEP@NEPONSET.SCRC.Symbolics.COM>

    Date: 10 Apr 1985 10:12:15 PST
    From: Dave Dyer       <DDYER@USC-ISIB.ARPA>

    Received: from SCRC-STONY-BROOK by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 152301; Wed 10-Apr-85 13:15:37-EST
    Received: from SU-AI.ARPA by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 212320; 10 Apr 85 13:13:52-EST
    Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 10 Apr 85  10:12:47 PST
    FYI:  Adding mandatory/optional argument checking to Interlisp-VAX
    would be easy, and incur no additional overhead.
    ReSent-Date: 10 Apr 1985 10:12:15 PST
    ReSent-From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
    ReSent-To: common-lisp@SU-AI.ARPA

Where did THAT header come from?  There is no To: or From: fields.

    Default values for &optional args would require a substantial
    rethinking of the function call mechanism, as would &rest and 
    &key.

Point of information: Why are people discussing various implementations
of the Interlisp calling strategies on the common-lisp mailing list?  As
I remember, this whole thing started because somebody didn't realize
what keyword arguments (in Common Lisp) are for.

∂10-Apr-85  1112	smh@mit-eddie.ARPA 	defstruct slot names
Received: from MIT-EDDIE.ARPA by SU-AI.ARPA with TCP; 10 Apr 85  11:11:57 PST
Received: by mit-eddie.ARPA (4.12/4.8)  id AA09669; Wed, 10 Apr 85 14:04:48 est
Date: Wed, 10 Apr 85 14:04:48 est
From: Steven M. Haflich <smh@mit-eddie.ARPA>
Message-Id: <8504101904.AA09669@mit-eddie.ARPA>
To: Common-Lisp@SU-AI.ARPA
Subject: defstruct slot names

I hope this wasn't discussed in the distant past.

The CLTL definition of the defstruct macro (p.308) has a hole which
deserves plugging.  Each slot-name in the defstruct form is required
only to be a symbol.  It would seem that the following is perfectly
legal, even if it has no clear motivation:

	(defstruct automobile
		   engine:horsepower
		   insurance:dollar-value)

It is reasonable to assume that the constructor function can only
ignore the package of a slot-name regardless whether it is the same
package as the structure name.  So this is OK:

	(make-automobile :horsepower 289 :dollar-value 14500)

Anyway, this is probably what would happen in any obvious implementation
which had given this issue no thought at all.  But consider:

	(defstruct automobile
		   engine:horsepower
		   liability-insurance:dollar-value
		   collision-insurance:dollar-value)

While there is no requirement that slot-names be distinct, it is
reasonable that identical slot names should be an error.  But the two
dollar-value slots are distinct even though they herniate the naming
scheme for constructor keywords and access-functions.  The problem is
that slot names are semantically scoped within the structure containing
them, so packages are irrelevant.  The ways in which slot names are used
rather assumes this, but the assumption is nowhere explicit.

Can anyone think of a legitimate use for packages in slots names?  If
not, I propose the manual should explicitly state that defstruct interns
all slot names in the keyword package.  Compare the definition of the
#S(name slot1 'value ...) reader syntax (p.357).

This issue will likely also affect active objects.

∂10-Apr-85  1156	FAHLMAN@CMU-CS-C.ARPA 	defstruct slot names  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 Apr 85  11:56:46 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 10 Apr 85 14:55:54-EST
Date: Wed, 10 Apr 1985  14:55 EST
Message-ID: <FAHLMAN.12102095449.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   "Steven M. Haflich" <smh@MIT-EDDIE.ARPA>
Cc:   Common-Lisp@SU-AI.ARPA
Subject: defstruct slot names
In-reply-to: Msg of 10 Apr 1985  14:04-EST from Steven M. Haflich <smh at mit-eddie.ARPA>


I think that the motivation for allowing slot names to be non-keywords
was that it might be useful to have these be local to some particular
package.  Of course, none of us was so perverse as to imagine that users
would (a) mix together a lot of packages in the same defstruct
definition and (b) then go on and introduce name conflicts among the
symbols.  I think that instead of somehow trying to make this illegal,
we should just let the users hang themselves if they're that eager to do
so.  If there was some way in which this situation might happen by
accident in halfway reasonable code, then it might be worthwhile to
check for this case and keep the user out of trouble, but I don't see
any potential for innocent lossage here.

-- Scott

"Nothing is foolproof because fools are so ingenious."

∂10-Apr-85  1159	RAM@CMU-CS-C.ARPA 	Meaning of PROBE-FILE for direction output    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 Apr 85  11:58:59 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 10 Apr 85 14:57:09-EST
Date: Wed, 10 Apr 1985  14:56 EST
Message-ID: <RAM.12102095659.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   Jon White <JLW@SU-AI.ARPA>
Cc:   common-lisp@SU-AI.ARPA, greek@DEC-HUDSON.ARPA, moon@SCRC-STONY-BROOK.ARPA
Subject: Meaning of PROBE-FILE for direction output  
In-reply-to: Msg of 9 Apr 1985  21:11-EST from Jon White <JLW at SU-AI.ARPA>


    I don't think that either of the problems of a non-opening probe
for output files that you mention are important.

    The problem of the result only being valid for an arbitrarily
short period of is not unique to this function.  When opening for
input, the file could be deleted or opened in a read-exclusive fashion
between the probe-file and any open attempt.

    I'm not quite sure what sort of problem you are referring to in
the second case.  Are you talking about the business of the version
number not being known, or what?  The function I propose would
probably return a null version, since that could not be known.

  Rob

∂10-Apr-85  1222	RAM@CMU-CS-C.ARPA 	Compilation and package system 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 Apr 85  12:22:39 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 10 Apr 85 15:16:32-EST
Date: Wed, 10 Apr 1985  15:16 EST
Message-ID: <RAM.12102099201.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   perdue%hplabs.csnet@CSNET-RELAY.ARPA
Cc:   Common-lisp@SU-AI.ARPA
Subject: Compilation and package system
In-reply-to: Msg of 8 Apr 1985  18:03-EST from perdue%hplabs.csnet at csnet-relay.arpa


    Yep, that's true.  In the hurry to say that compiling code has no
effects on its semantics, the CLM glossed over some uglies that are
unlikely to go away.

    One is the problem that you mention: reading throws away
information, so the load-time semantics cannot be the same with
compiled code.  It would be nice if someone could decide what should
be guaranteed about the package semantics of symbols in compiled code.

    Another problem involves the constraints placed on objects that
can be function constants.
 1] Can any type of object be dumped?  Compiled functions, hashtables,
    streams?  The answer is almost certainly no, but nowhere is it
    specified what you can dump.  A conservative rule would be to only
    guarantee that readable objects can be dumped.
 2] Is sharing and non-sharing preserved?  Probably not.
 3] Can circular structures can dumped?  Note that they can be read
    and printed.

  Rob

∂10-Apr-85  1504	REM@IMSSS 	interp .neq. compil, even in CL   
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Apr-10 15:01:27 PST (=GMT-8hr)
Date: 1985 April 10 15:00:36 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132125241707.G0365
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To:RAM@CMU-CS-C.ARPA
CC:COMMON-LISP@SU-AI.ARPA
Subject:interp .neq. compil, even in CL
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up)

  |Date: Wed, 10 Apr 1985  15:16 EST
  |From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
  |
  |    Yep, that's true.  In the hurry to say that compiling code has no
  |effects on its semantics, the CLM glossed over some uglies that are
  |unlikely to go away.

Hear! Hear!

You've brought up several items that ought to be explained in the
manual. It should say something like "Common LISP tries to make the
semantics of compiled programs and the semantics of their interpreted
sources as nearly identical as they can be. But certain processes such
as reading data in or writing it out lose information thereby causing
some differences between interpreted and compiled code: - READing an
s-expression containing unqualified identifiers (those with no
explicit package qualifier) to be assigned to a package at the time
they are read, thus causing compiled identifiers to be assigned to a
package which was default at the time of compiling rather than the
package that is default at the time the compiled code is later read
and executed. To force these two packages to be the same, the
IN-PACKAGE declaration is available (page ...). - When writing two
different s-expressions (using PRIN1 or via compiling and
FASL-writing), information about internal structure they share is
lost. There is no way short of hashcons to maintain that sharing over
a write-read cycle. ..." etc. etc.

This list of differences between interpreted and compiled software
should be summarized all in one place, as above, although details of
IN-PACKAGE and the like can be elsewhere. CLM should realize it has
not totally obtained the goal of interp/compil equivalence, and state
to which degree it has and hasn't succeeded, lest hundreds of LUSERs
discover for themselves (painfully) that we haven't told them the truth.

∂10-Apr-85  1933	Moon@SCRC-STONY-BROOK.ARPA 	Compilation and package system  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 Apr 85  19:33:06 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 212741; Wed 10-Apr-85 22:33:05-EST
Date: Wed, 10 Apr 85 22:33 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Compilation and package system
To: Skef Wholey <Wholey@CMU-CS-C.ARPA>
cc: Common-lisp@SU-AI.ARPA
In-Reply-To: <WHOLEY.12101913081.BABYL@CMU-CS-C.ARPA>
Message-ID: <850410223354.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 9 Apr 1985  22:14 EST
    From: Skef Wholey <Wholey@CMU-CS-C.ARPA>

    There are a number of ways to let the compiler know about the package that a
    file will be loaded into.  The portable, Common Lisp way to do this is with a
    call to In-Package at the beginning of a file, as suggested in CLTL, on page
    189.  The Lisp Machine -*- file comment hack (which is used by the editor,
    compiler, and loader) has a few drawbacks.

    First of all, it is not portable.  People write Common Lisp programs with a -*-
    package specification, but these programs must be modified (by adding a real
    In-Package to the program text) when they are moved to non-Lisp Machine Common
    Lisps.

I guess it's a matter of viewpoint which way is non-portable, depending on which
way you're trying to port.  But let's not get into that.

    Secondly, one cannot put all of the information about the packages Use'd or
    symbols Import'ed in the file comment.  One cannot accurately fix up the
    package environment by looking at the file comment.  I suppose one could hair
    it up to include imports and shadows and whatnot (maybe someone already has),
    but that just leaves one with more stuff to "translate into Common Lisp" when
    he moves his program off of the Lisp Machine.

We believe that complex package setups should go in their own files.

    Finally, the Symbolics Common Lisp Compatibility Package will give an error
    when one attempts to load or compile a file with a header something like that
    presented below, because it interprets the file comment, and wants to find any
    package specified there before reading anything in the file.  In fact, the
    first form read may be the one that creates the package, so it may not be there
    for the file comment gremlin to interpret.  In-Package is a nice language
    feature that Does The Right Thing, but has been rendered useless on the Lisp
    Machine by zealous use of file comment magic.

I don't think it would be constructive for me to respond to the above paragraph
in the same tone as it was written, so I will refrain.

    We have adopted the convention that any -*- package specification is for the
    editor only, and that the compiler and friends should get stuff out of Lisp
    forms.  Thus, a typical Spice Lisp system file might begin with something like:

	    ;;; -*- Package: Lisp; Log: Code.Log -*-
	    ;;;
	    ;;; ...blah blah blah...
	    ;;;

	    (in-package "LISP" :use '("SYSTEM"))

	    (export '(things that this file defines))

    The editor knows which package to associate with a buffer created when visiting
    this file, but the compiler and loader and everyone else just read Lisp forms,
    the way Father Lisp wanted them to.

This all sounds at first like it makes a lot of sense, but wait a minute.  I
fail to see how the editor needs any less information about packages than the
compiler and the loader.  How does the editor know the names of the functions
in the file if it doesn't know what package they are relative to?  How can the
editor understand forms in the file, telling you about arguments wanted by
functions, documentation of variables, syntax of macros, and so forth, if it
can't intern symbols whose printed representations it finds there?  How can you
incrementally compile or load portions of the file being edited if the machine
doesn't know what package to read the forms in?  Or does you editor make a
special pass through the file when it reads it in, looking for "(IN-PACKAGE "?

In our system all programs that read Lisp forms from files get the package
information from the same place and they all work consistently.

    Since the -*- convention is not part of Common Lisp (and perhaps for good
    reason), I would encourage EVERYONE writing Common Lisp programs to begin each
    file in the way suggested in CLTL.  Smart editors need to know things like the
    package (so that functions compiled in the text editor end up in the right
    package, for example), however, so it might be worth some effort to standardize
    the semantics of -*- file comments.  Unfortunately, I imagine neither the Lisp
    Machine community nor the Spice Lisp community is willing to give in.

Probably not, considering that IN-PACKAGE was put into Common Lisp over my dead body.
This is my fault for not doing an adequate job of explaining why it was a bad idea
and only workable in the short run.  As you say, it might be worth some effort to
standardize the semantics of -*-.

∂10-Apr-85  2006	GSB@MIT-MC 	Meaning of PROBE-FILE for direction output      
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 10 Apr 85  20:05:46 PST
Date: Wed,10 Apr 85 23:04:40 EST
From: Glenn S. Burke <GSB@MIT-MC>
Subject: Meaning of PROBE-FILE for direction output  
To: common-lisp@SU-AI
Message-ID: <[MIT-MC].450268.850410.GSB>

Another timing problem with this is that any way of doing it which
involves actually doing the open might leave an entry in the
filesystem, even though only temporarily.  I would not want to have to
simulate any hairy (tops-20, vms, especially version 4) operating
system's algorithm for determining if i had access -- ergo, i would
implement it by doing the open to see if it succeeds.

∂10-Apr-85  2051	WHOLEY@CMU-CS-C.ARPA 	Compilation and package system   
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 Apr 85  20:51:22 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Wed 10 Apr 85 23:51:08-EST
Date: Wed, 10 Apr 1985  23:51 EST
Message-ID: <WHOLEY.12102192890.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   Common-lisp@SU-AI.ARPA
Subject: Compilation and package system

    Date: Wednesday, 10 April 1985  22:33-EST
    From: David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>

        Date: Tue, 9 Apr 1985  22:14 EST
        From: Skef Wholey <Wholey@CMU-CS-C.ARPA>

        First of all, it [the -*- comment convention] is not portable.

    I guess it's a matter of viewpoint which way is non-portable, depending on
    which way you're trying to port.  But let's not get into that.

Let's get into that for just one paragraph.  Nothing in CLTL says anything
about -*- comments.  Files with those comments will have the effect that you
(Dave Moon) expect them to in only one Common Lisp implementation: the
Symbolics CLCP.  The implementations done by DEC, DG, Rutgers, Kyoto
University, and CMU will not understand them.  I realize that (by itself) this
kind of survey is a bad way to decide language design issues, but the reason
that those implementations do not hack -*- the Lisp Machine way is that there's
nothing in the spec that says they should.

    We believe that complex package setups should go in their own files.

I have two programs that I've run on both Perqs and 3600's.  One is a Common
Lisp version of OPS-5, and another is the Spice Lisp microcode assembler.  Each
are contained in exactly one file, and are thus easy to move from system to
system.  Why should I need to double the number of files in such systems?

For us, "complex package setups" are a way of life, because we've chosen to put
the code for communicating with each OS server in its own file.  When I sit
down to write a graphics hack, I begin a file with
	;;; -*- Package: Hack -*-
	(in-package "HACK" :use '("LISP" "ACCINT" "SAPPH" "SESAME")).
I suppose our differences may stem from the fact that we Spice Lispers don't
think that packages are very expensive.  Packages can be used for little hacks
as well as big systems.  In the former case, one shouldn't need to stash this
information in a separate file that then must be loaded by hand (or in my init
file (or by some hook I frob in my init file)).

        The editor knows which package to associate with a buffer created when
        visiting this file, but the compiler and loader and everyone else just
        read Lisp forms, the way Father Lisp wanted them to.

    This all sounds at first like it makes a lot of sense, but wait a minute.
    I fail to see how the editor needs any less information about packages than
    the compiler and the loader.  How does the editor know the names of the
    functions in the file if it doesn't know what package they are relative to?

I guess I was being unclear.  The editor interprets -*- comments, and
associates a package with the buffer the file was read into.  This package is
made the default package (i.e. *package* is bound to it) whenever the editor
parses code in the file (e.g. for incremental compilation) or the echo area
(e.g. when asked to list the argument names of a given function).

If the package does not exist, then the user is asked if it should be created.
If that package uses packages other than LISP, then the user must evaluate the
In-Package or Use-Package or Import or whatever himself before counting on the
editor to parse code correctly.  This last step could be automated, but we
haven't done it.

    In our system all programs that read Lisp forms from files get the package
    information from the same place and they all work consistently.

Ah, but all those programs have to do some magic thing (not part of the Common
Lisp language) to interpret the stuff between -*-'s in the first line of the
file.  Should a user be able to write a portable slow-loader (that just reads
forms from a given file) or not?  I think he should.  People should be able to
write things like program cross-referencers in Common Lisp.  Portable Common
Lisp (whatever that means).

    IN-PACKAGE was put into Common Lisp over my dead body.

The rumors of your death have been greatly exaggerated.

    It might be worth some effort to standardize the semantics of -*-.

How about this: Symbolics could provide a portable -*- comment hacking package.
This would be made part of the yellow pages, and all implementations could
"voluntarily" adopt it as a thing that gets called by Load, Compile-File, etc.
This might then be adopted in Common Lisp Mark II (it's really no worse than
FORMAT, I guess).  I'm still personally biased against this idea (I really do
believe that a slow-loader should just read forms out of a file), but portable
code would make the Lisp Machine convention a lot easier to swallow.

On the other hand, we could decide that -*-'s don't port, and warn users about
differences from system to system.  Rob MacLachlan has suggested a very
sinister solution to the problem: conditionalized constructs in -*- coments...

    -*- #+LISPM{Syntax: Common-Lisp; Uppercase: Mostly;} Package: Zippy -*-

--Skef

∂10-Apr-85  2137	KMP@SCRC-STONY-BROOK.ARPA 	Compilation and package system   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 Apr 85  21:37:00 PST
Received: from SCRC-RIO-DE-JANEIRO by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 212797; Thu 11-Apr-85 00:37:00-EST
Date: Thu, 11 Apr 85 00:35 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Compilation and package system
To: Wholey@CMU-CS-C.ARPA, Moon@SCRC-STONY-BROOK.ARPA
cc: Common-lisp@SU-AI.ARPA
In-Reply-To: <WHOLEY.12102192890.BABYL@CMU-CS-C.ARPA>
Message-ID: <850411003554.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Wed, 10 Apr 1985  23:51 EST
    Message-ID: <WHOLEY.12102192890.BABYL@CMU-CS-C.ARPA>
    Sender: WHOLEY@CMU-CS-C.ARPA
    From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
    To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
    Cc:   Common-lisp@SU-AI.ARPA
    Subject: Compilation and package system

	Date: Wednesday, 10 April 1985  22:33-EST
	From: David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>

	    Date: Tue, 9 Apr 1985  22:14 EST
	    From: Skef Wholey <Wholey@CMU-CS-C.ARPA>

	    First of all, it [the -*- comment convention] is not portable.

	I guess it's a matter of viewpoint which way is non-portable, depending on
	which way you're trying to port.  But let's not get into that.

    Let's get into that for just one paragraph.  Nothing in CLTL says anything
    about -*- comments.  Files with those comments will have the effect that you
    (Dave Moon) expect them to in only one Common Lisp implementation: the
    Symbolics CLCP.  The implementations done by DEC, DG, Rutgers, Kyoto
    University, and CMU will not understand them.  I realize that (by itself) this
    kind of survey is a bad way to decide language design issues, but the reason
    that those implementations do not hack -*- the Lisp Machine way is that there's
    nothing in the spec that says they should.

Don't be silly. Common Lisp programs don't have to run gracefully in all 
implementations, they just have to run. If a person has written -*- ... -*-
and not put (IN-PACKAGE ...), he has not written a common lisp program.
But that doesn't mean the Lisp Machine doesn't support IN-PACKAGE. If a 
person has put (IN-PACKAGE ...) but no -*- ... -*- that means his program
will run in the way Common Lisp says it will, but that doesn't mean it will
interface gracefully to parts of the system not specified by Common Lisp.
The Lisp Machine simply (and reasonably) suggests that in order to work
compatibly with non-Common-Lisp utilities and still be portable, you should
do -*- ... -*- and (IN-PACKAGE ...), redundantly. In fact, I suspect that
users will be content to use simply -*- ... -*- and add (IN-PACKAGE ...) only
when they get around to actually shipping files but that shouldn't matter.

	We believe that complex package setups should go in their own files.

    I have two programs that I've run on both Perqs and 3600's.  One is a Common
    Lisp version of OPS-5, and another is the Spice Lisp microcode assembler.  Each
    are contained in exactly one file, and are thus easy to move from system to
    system.  Why should I need to double the number of files in such systems?

    For us, "complex package setups" are a way of life, because we've chosen to put
    the code for communicating with each OS server in its own file.  When I sit
    down to write a graphics hack, I begin a file with
	    ;;; -*- Package: Hack -*-
	    (in-package "HACK" :use '("LISP" "ACCINT" "SAPPH" "SESAME")).
    I suppose our differences may stem from the fact that we Spice Lispers don't
    think that packages are very expensive.  Packages can be used for little hacks
    as well as big systems.  In the former case, one shouldn't need to stash this
    information in a separate file that then must be loaded by hand (or in my init
    file (or by some hook I frob in my init file)).

Of course, for this sort of thing I usually just write:there's the alternate syntax:
  ;;; -*- Package: ("HACK" :USE ("LISP" "ACCINT" "SAPPH" "SESAME")) -*-
which seems to work OK...

	    The editor knows which package to associate with a buffer created when
	    visiting this file, but the compiler and loader and everyone else just
	    read Lisp forms, the way Father Lisp wanted them to.

	This all sounds at first like it makes a lot of sense, but wait a minute.
	I fail to see how the editor needs any less information about packages than
	the compiler and the loader.  How does the editor know the names of the
	functions in the file if it doesn't know what package they are relative to?

    I guess I was being unclear.  The editor interprets -*- comments, and
    associates a package with the buffer the file was read into.  This package is
    made the default package (i.e. *package* is bound to it) whenever the editor
    parses code in the file (e.g. for incremental compilation) or the echo area
    (e.g. when asked to list the argument names of a given function).

    If the package does not exist, then the user is asked if it should be created.
    If that package uses packages other than LISP, then the user must evaluate the
    In-Package or Use-Package or Import or whatever himself before counting on the
    editor to parse code correctly.  This last step could be automated, but we
    haven't done it.

	In our system all programs that read Lisp forms from files get the package
	information from the same place and they all work consistently.

    Ah, but all those programs have to do some magic thing (not part of the Common
    Lisp language) to interpret the stuff between -*-'s in the first line of the
    file.  Should a user be able to write a portable slow-loader (that just reads
    forms from a given file) or not?  I think he should.  People should be able to
    write things like program cross-referencers in Common Lisp.  Portable Common
    Lisp (whatever that means).

Don't forget the Lisp Machine uses -*- ... -*- for other languages besides lisp.
(IN-PACKAGE ...) would not work at the top of files in other languages besides
lisp and we don't have hands in design groups for every existing language so 
cannot always get those languages to add a syntax for specifying the package.
Putting it in a comment is mostly likely to win in all languages since nearly 
every language has a comment syntax and I know of no languages for which the 
comment syntax is not compatible with -*- ... -*-.

	IN-PACKAGE was put into Common Lisp over my dead body.

    The rumors of your death have been greatly exaggerated.

	It might be worth some effort to standardize the semantics of -*-.

    How about this: Symbolics could provide a portable -*- comment hacking package.
    This would be made part of the yellow pages, and all implementations could
    "voluntarily" adopt it as a thing that gets called by Load, Compile-File, etc.
    This might then be adopted in Common Lisp Mark II (it's really no worse than
    FORMAT, I guess).  I'm still personally biased against this idea (I really do
    believe that a slow-loader should just read forms out of a file), but portable
    code would make the Lisp Machine convention a lot easier to swallow.

    On the other hand, we could decide that -*-'s don't port, and warn users about
    differences from system to system.  Rob MacLachlan has suggested a very
    sinister solution to the problem: conditionalized constructs in -*- coments...

	-*- #+LISPM{Syntax: Common-Lisp; Uppercase: Mostly;} Package: Zippy -*-

    --Skef

∂11-Apr-85  0044	WHOLEY@CMU-CS-C.ARPA 	Compilation and package system   
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Apr 85  00:41:22 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Thu 11 Apr 85 03:41:09-EST
Date: Thu, 11 Apr 1985  03:41 EST
Message-ID: <WHOLEY.12102234761.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To:   Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc:   Common-lisp@SU-AI.ARPA, Moon@SCRC-STONY-BROOK.ARPA
Subject: Compilation and package system
In-reply-to: Msg of 11 Apr 1985  00:35-EST from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>

    Date: Thursday, 11 April 1985  00:35-EST
    From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>

    Don't be silly. Common Lisp programs don't have to run gracefully in all 
    implementations, they just have to run. If a person has written -*- ... -*-
    and not put (IN-PACKAGE ...), he has not written a common lisp program.

Right.  That was what I said in the last paragraph in my original message on
this topic.

    The Lisp Machine simply (and reasonably) suggests that in order to work
    compatibly with non-Common-Lisp utilities and still be portable, you should
    do -*- ... -*- and (IN-PACKAGE ...), redundantly.

Right.  That's the way Spice Lisp works, too, more or less, as I've explained.
The difference in the two implementations comes up in only one case, but a very
common one.  If, in CLCP, I load or compile a file with a -*- comment that puts
it in package FOO, and package FOO does not exist, then I get an error.  Every
time this has happened to me, it has been the case that the first form of FOO
would have created the package.

    Of course, for this sort of thing I usually just write:there's the
    alternate syntax:
      ;;; -*- Package: ("HACK" :USE ("LISP" "ACCINT" "SAPPH" "SESAME")) -*-
    which seems to work OK...

What about IMPORT and friends?  Those matter, too.

    Putting it in a comment is mostly likely to win in all languages since
    nearly every language has a comment syntax and I know of no languages for
    which the comment syntax is not compatible with -*- ...  -*-.

The example I gave above, with the FOO package, leads to a situation where the
Lisp Machine signals an error when handed a valid program.  That would suggest
that Common Lisp is a language which is not compatible with -*- comments, as
interpreted the Lisp Machine way.

If you think this is nitpicking, fine: we'll drop it.  I doubt many man-years
will be lost fixing headers while porting between Common Lisp dialects.  The
problem has annoyed at least one Common Lisp programmer, however.

--Skef

∂11-Apr-85  0607	greek@DEC-HUDSON 	PROBE-FILE  
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 11 Apr 85  06:07:30 PST
Date: Thu, 11 Apr 85 09:07:38 EST
From: greek@DEC-HUDSON
Subject: PROBE-FILE
To: common-lisp@su-ai

At the risk of continuing a well-beaten subject:

I agree with Kent that there is no pleasant way of returning all the
possible errors from PROBE-FILE, and that some kind of objecty signalling
facility is probably the right way to go.

However, I just really have a problem with handling "normal" errors
using an error system.  I can barely keep from gagging when I have to
wrap an UNWIND-PROTECT around something every six months or so.
To have to wrap various signal-handling forms all over the place...

- Paul

∂11-Apr-85  0649	greek@DEC-HUDSON 	A comment on packages (at the risk of being a fool) 
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 11 Apr 85  06:49:00 PST
Date: Thu, 11 Apr 85 09:11:31 EST
From: greek@DEC-HUDSON
Subject: A comment on packages (at the risk of being a fool)
To: common-lisp@su-ai

We've had lots of discussion on the differences being interpreting
and compiling when using symbols without package prefixes.

I believe the rule with the slow loader is that an unqualified
symbol is loaded into the current package, which may or may not
have been established with an IN-PACKAGE at the top of the file.
Why doesn't the compiler simply do the same thing?

Namely, it sets the current package to "SPECIAL-COMPILER-PACKAGE-NO-ONE-
ELSE-CAN-USE".  Then it read/compiles the file and arranges that any
symbols in that special package will be fast loaded into what is then
the current package.  If the user has an IN-PACKAGE at the top of the
file, then no symbols will end up in that special package -- fine.

Am I missing something?

- Paul

∂11-Apr-85  1052	Moon@SCRC-QUABBIN.ARPA 	A comment on packages (at the risk of being a fool)
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 11 Apr 85  10:52:26 PST
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 152716; Thu 11-Apr-85 13:38:26-EST
Date: Thu, 11 Apr 85 13:38 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: A comment on packages (at the risk of being a fool)
To: greek@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 11 Apr 85 09:11-EST from greek at DEC-HUDSON
Message-ID: <850411133853.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 11 Apr 85 09:11:31 EST
    From: greek@DEC-HUDSON

    We've had lots of discussion on the differences being interpreting
    and compiling when using symbols without package prefixes.

    I believe the rule with the slow loader is that an unqualified
    symbol is loaded into the current package, which may or may not
    have been established with an IN-PACKAGE at the top of the file.
    Why doesn't the compiler simply do the same thing?

    Namely, it sets the current package to "SPECIAL-COMPILER-PACKAGE-NO-ONE-
    ELSE-CAN-USE".  Then it read/compiles the file and arranges that any
    symbols in that special package will be fast loaded into what is then
    the current package.  If the user has an IN-PACKAGE at the top of the
    file, then no symbols will end up in that special package -- fine.

    Am I missing something?

Think about executing, at compile time, the bodies of macros defined in the file.


∂11-Apr-85  1103	OLDMAN@USC-ISI.ARPA 	Data General Common LISP
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 11 Apr 85  11:02:13 PST
Date: 11 Apr 1985 14:01-EST
Sender: OLDMAN@USC-ISI.ARPA
Subject: Data General Common LISP
From: OLDMAN@USC-ISI.ARPA
To: Common-Lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]11-Apr-85 14:01:51.OLDMAN>

DG has recently released Common LISP running on its 32 bit family
of machines.  A brief summary of the implementation and a list of
benchmark timings is available on USC-ISI in:

    ps:<oldman>dg-common-lisp

-- Dan Oldman

∂11-Apr-85  1128	KMP@SCRC-YUKON.ARPA 	PROBE-FILE    
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 11 Apr 85  11:28:00 PST
Received: from SCRC-RIO-DE-JANEIRO by SCRC-YUKON via CHAOS with CHAOS-MAIL id 118912; Thu 11-Apr-85 14:28:52-EST
Date: Thu, 11 Apr 85 14:26 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: PROBE-FILE
To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 11 Apr 85 09:07-EST from greek at DEC-HUDSON
Message-ID: <850411142639.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Thu, 11 Apr 85 09:07:38 EST
    From: greek@DEC-HUDSON

    ... I agree with Kent that there is no pleasant way of returning all the
    possible errors from PROBE-FILE, and that some kind of objecty signalling
    facility is probably the right way to go.

    However, I just really have a problem with handling "normal" errors
    using an error system.  I can barely keep from gagging when I have to
    wrap an UNWIND-PROTECT around something every six months or so.
    To have to wrap various signal-handling forms all over the place...

Well, in fact one of the "nice" things about this is that because you know
you'll get thrown into the error handler if something funny happens, you
can sometimes write your code without the error handling and add it lazily 
if it's ever needed.

In dialects where PROBEF can fail due to other than file-not-found, you may
have the problem that the program will "finish" but not correctly. At least
if an error is not signalled, you know things worked correctly. For many
applications, this means writing

  (COND ((NOT (PROBEF ...)) ;File is not found
	 ...)
	(T ;File is found
	 ...))

where formerly (with a PROBEF that refuses to err) you might really have
been forced into doing something like:

  (COND ((NOT (PROBEF ...)) ;Hmmm... File is either not found 
			    ;or not available or not correctly named or ...
	 (COND (...hair to figure out what to do if name was bad...)
	       (...hair to figure out what to do if not accessible...
		   machine down? drive offline? file write opened in
	           append mode by someone else and therefore locked?
		   no more of some needed system resource? ...)
	       (T ...the only part i really cared about...)))
	(T ;File is found
	  ...))

in order to be able to get to sleep at night with a clean conscience.

I guess what I'm saying is that in Maclisp, I've always considered programmers
irresponsible if they wrote "simplified" code that didn't handle the hairy
cases because they were just setting up to cause lossage when someone ran 
their program in unusual circumstances.

On the other, Lisp Machine Lisp programmers that don't write code to handle 
the hairy cases are often being sensible. They can have some sense of confidence
that if an unusual situation arises, the program will stop dead in its tracks
instead of producing bad data.

Given the choice between a buggy program that enters the error handler
and a buggy program which just continues to run blindly, I nearly always
prefer the former.

So, perhaps surprisingly, I'm suggesting that using error signalling may
simplify (rather than complicate) the look of code and maybe people with
hairy-construct phobias will actually like this...
-kmp

∂11-Apr-85  1156	FAHLMAN@CMU-CS-C.ARPA 	PROBE-FILE  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Apr 85  11:56:14 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 11 Apr 85 14:56:03-EST
Date: Thu, 11 Apr 1985  14:55 EST
Message-ID: <FAHLMAN.12102357619.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   common-lisp@SU-AI.ARPA
Subject: PROBE-FILE
In-reply-to: Msg of 11 Apr 1985  14:26-EST from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>


I've avoided stepping into this particular discussion (and probably will
regret doing so now) but it looks to me like it might be time to try to
close the issue, for now at least.  Let me toss out the following
suggestions to see if they are acceptable to everyone:

1. It is allowable for a Common Lisp system to signal an error on probef
if the file name is malformed in some way, or if the file is not found
for other than the usual reasons.

2. Implementations that don't want to handle this with an error, perhaps
because they lack an error-handling system of sufficient power, can for
now do something compatible but non-portable about this, such as taking
a special keyword or returning an extra value describing what went
wrong.

3. We should try again for a clean, fully portable solution to this
problem after we have reached some consensus on a standard
signal/error-handling system.  At that point, we'll be able to see much
more clearly whether this is a good way to deal with this sort of
situation.

-- Scott

∂11-Apr-85  1227	greek@DEC-HUDSON 	PROBE-FILE  
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 11 Apr 85  12:27:39 PST
Date: Thu, 11 Apr 85 15:27:49 EST
From: greek@DEC-HUDSON
Subject: PROBE-FILE
To: common-lisp@su-ai

Scott's suggestion seems reasonable to me.  We should avoid getting
bogged down in specific error-handling problems until we think about
a general signaling mechanism.

- Paul

∂11-Apr-85  1237	greek@DEC-HUDSON 	PROBE-FILE  
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 11 Apr 85  12:37:08 PST
Date: Thu, 11 Apr 85 15:37:13 EST
From: greek@DEC-HUDSON
Subject: PROBE-FILE
To: common-lisp@su-ai

That's not to say that I like handling errors with a signaling facility,
but I guess I'm willing to change...

- Paul

∂11-Apr-85  1237	greek@DEC-HUDSON 	The compiler and packages. 
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 11 Apr 85  12:35:10 PST
Date: Thu, 11 Apr 85 15:35:16 EST
From: greek@DEC-HUDSON
Subject: The compiler and packages.
To: common-lisp@su-ai

Well, Mr. Moon, I gave your comment some thought.  It was a bit terse,
but perhaps this is what you meant:

What happens if a macro calls a function during the expansion of a
macro call?  If that function is in, say, the "USER" package, and the
compiler were to make the current package "SPECIAL-COMPILER-PACKAGE-
THAT-NO-ONE-ELSE-USES", then indeed the function wouldn't be found
at compile time.

But then again, it wouldn't be found if the user didn't happen to be
in the "USER" package when compiling the program.  If the program
must be compiled in the "USER" package, it ought to do an IN-PACKAGE
at the top.

If I read you wrong, please let me know.

By the way, here's what VAX LISP currently does:  If the compiler goes
to dump a symbol which is in the current package (not any special
compiler package), then it dumps it without a package.  This means
it will be loaded into the current package at the time of loading.
I don't think this is quite right, since it means that if I'm in
the "FOO" package when I compile, and I say FOO::SYM, and then I'm
in "BAR" when I load it, SYM will end up in "BAR" rather than "FOO".
To avoid this problem, I think you need the special compiler package.

- Paul

∂11-Apr-85  1302	dzg@cmu-cs-spice.arpa 	Probe-file and errors 
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 11 Apr 85  13:01:41 PST
Apparently-From: dzg@CMU-CS-SPICE
Date: Thu 11 Apr 85 15:41:18-EST
From: dzg@CMU-CS-SPICE.ARPA
To: common-lisp@SU-AI.ARPA
Subject: Probe-file and errors
Message-ID: <6595.160879383.>

What seems to be impossible, for some reason, is to make simple things simple.
Here is the original application I had in mind:
- I need to find a dictionary file that is the key to everything else.
  Access is to a remote machine of unspecified nature.
- Depending on the remote file system, the dictionary file may be under
  different paths (e.g. /usr/xxx for a Unix machine, and so on).
- There are only two or three possible remote paths, one per machine, maybe.
- My code just wants to do
  (cond ((probe-file "/usr/foo/bar")
         ...)
        ((probe-file "/user/may/be")
         ...)
        ((probe-file "/yet/another/one")
         ...)
        (t
	 ... cannot find it. Bye. ...))
  Simple as that.

I do not (DO NOT!) want to handle an error. This is the simplest possible
thing I can ask of a file system. Do you have it or not? I couldn't care
less that the pathname is malformed because Unix directories must sit under
/usr/. I just want to see whether the file is there.

I understand there may be serious cases when one wants to "stop dead in the
tracks". I am willing to believe one really cares to find out why the file
system thinks there is no such file because the color of the third bit in
the filename is not blue. But I do want to have a simple call. I have seen
many systems that use exception handling as a way of passing arguments,
and they are NOT the clearest systems I have seen.
  - Dario -

∂11-Apr-85  1613	Moon@SCRC-STONY-BROOK.ARPA 	PROBE-FILE  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Apr 85  16:11:36 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 213650; Thu 11-Apr-85 19:07:53-EST
Date: Thu, 11 Apr 85 19:09 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: PROBE-FILE
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12102357619.BABYL@CMU-CS-C.ARPA>
Message-ID: <850411190901.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 11 Apr 1985  14:55 EST
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
    ....Let me toss out the following
    suggestions to see if they are acceptable to everyone....

Fine with me.

∂11-Apr-85  1702	Moon@SCRC-STONY-BROOK.ARPA 	The compiler and packages. 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Apr 85  17:02:21 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 213672; Thu 11-Apr-85 20:01:29-EST
Date: Thu, 11 Apr 85 20:02 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: The compiler and packages.
To: greek@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 11 Apr 85 15:35-EST from greek at DEC-HUDSON
Message-ID: <850411200255.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 11 Apr 85 15:35:16 EST
    From: greek@DEC-HUDSON

    Well, Mr. Moon, I gave your comment some thought.  It was a bit terse,
    but perhaps this is what you meant:

    What happens if a macro calls a function during the expansion of a
    macro call?  If that function is in, say, the "USER" package, and the
    compiler were to make the current package "SPECIAL-COMPILER-PACKAGE-
    THAT-NO-ONE-ELSE-USES", then indeed the function wouldn't be found
    at compile time.

What if the function was in the LISP package?  Does your special compiler
package inherit from there or doesn't it?  If it doesn't, macros can't
run.  If it does, you can't tell whether a symbol came from there via
package prefix or via inheritance.

    But then again, it wouldn't be found if the user didn't happen to be
    in the "USER" package when compiling the program.  If the program
    must be compiled in the "USER" package, it ought to do an IN-PACKAGE
    at the top.

    If I read you wrong, please let me know.

    By the way, here's what VAX LISP currently does:  If the compiler goes
    to dump a symbol which is in the current package (not any special
    compiler package), then it dumps it without a package.  This means
    it will be loaded into the current package at the time of loading.

In other words, it does the same thing as PRINT.  This is what our compiler
does, too.

    I don't think this is quite right, since it means that if I'm in
    the "FOO" package when I compile, and I say FOO::SYM, and then I'm
    in "BAR" when I load it, SYM will end up in "BAR" rather than "FOO".
    To avoid this problem, I think you need the special compiler package.

A better approach is for the compiler to tell the loader what the value
of *PACKAGE* was when the file was compiled.  If the loader binds
*PACKAGE* to the same value (that is, to a package with the same name)
when the file is loaded, symbol names in the compiled file will be
interpreted as the compiler intended when it dumped them.  This approach
works well for us.  Of course the user can get into arbitrary amounts of
trouble by changing package definitions between the time a file is compiled
and the time it is loaded, but that is inherently unavoidable.  For instance,
if the source file referenced FOO::SYM, and SYM was imported or inherited
by the source file's package at compile time, but not at load time, then
the wrong SYM will be referenced.

∂11-Apr-85  1852	masinter.pa@Xerox.ARPA 	Common Lisp should use lexical scoping   
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 11 Apr 85  18:46:35 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 APR 85 18:42:42 PST
Date: 11 Apr 85 18:42 PST
From: masinter.pa@Xerox.ARPA
Subject: Common Lisp should use lexical scoping
To: Common-Lisp@SU-AI.ARPA

I think Common Lisp should use lexical scoping and not dynamic scoping.
Dynamic scoping is the cause of some subtle incompatibilities between
compiled and interpreted code. 

Of course, I'm not talking about the scoping of variables, but rather of
packages. The "package" of a piece of code is really a lexical property
of the code. The fact that packages are dynamic in extent rather than
lexical has led to almost all of the problems in defining what happens
to packages and the compiler. 

I believe that lexical scoping for packages would require some extra
syntax. I'm not sure I'm up for proposing what that syntax should be,
but I'd guess that some kind of reader macro(s) would be appropriate
replacements for the Extremely Random User Interface Commands. (Imagine
"#;;;-*- Package:"  as a reader macro.)

It would then be reasonable to expect the compiler to preserve the
lexical scoping of packages, but the mechanism can now be part of the
implementation. 

It would remove the odd restrictions on the compiler mechanisms (as
suggested by the implementation note in CLTL p 182) and much of the
necessity for having some of the more arcane features of the Packages
chapter. 

∂11-Apr-85  1932	masinter.pa@Xerox.ARPA 	probe-file 
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 11 Apr 85  19:27:46 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 APR 85 19:27:54 PST
Date: 11 Apr 85 19:27 PST
From: masinter.pa@Xerox.ARPA
Subject: probe-file
To: common-lisp@su-ai.ARPA

Probe-file is useful but necessarily heuristic, even for output mode.
(The Interlisp equivalent is called OUTFILEP, and hasn't been flushed.) 

Let us suppose a that we had probe-file-that-generates-errors. This is
the one that does the probe-file, but generates errors if the file name
has illegal syntax, the server is down, etc. Lets suppose for a moment
that the error string in the error is always (kind of error: additional
information), e.g. "file server not responding: name-of-server".

Let me define a new function probe-file-without-errors, defined to
return the value of probe-file-that-generates-errors if the latter
returns non-NIL without errors, or else NIL and an optional second
argument, which is the "error code". Lets say that the error code is a
list of strings.

Note that there is some mutual property of these two functions, in that
either is relatively simple to implement in terms of the other, given an
error system of the imagined complexity of the Common Lisp error system.

Which would you prefer to have in the "standard" Common Lisp? Both?
Which would fit well with "most programs"? Which would "most
programmers" naturally chose if they had both available in their
library?

Given that probe-file is, on any machine except stand-alone
single-process systems, a heuristic at best, I'd claim that
probe-file-without-errors is more useful. I would claim that "can't
tell" is also a reasonable "error" code, and that it would be legitimate
(but not particularly useful) for an implementation to always return NIL
to probe-file, with "can't tell" as the reason. 

 

∂11-Apr-85  1937	FAHLMAN@CMU-CS-C.ARPA 	Common Lisp should use lexical scoping    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Apr 85  19:37:40 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 11 Apr 85 22:37:47-EST
Date: Thu, 11 Apr 1985  22:37 EST
Message-ID: <FAHLMAN.12102441681.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   masinter.pa@XEROX.ARPA
Cc:   Common-Lisp@SU-AI.ARPA
Subject: Common Lisp should use lexical scoping
In-reply-to: Msg of 11 Apr 1985  21:42-EST from masinter.pa at Xerox.ARPA


Interesting suggestion if packages are used only for loading chunks of
already-developed code, but it's not clear to me that lexically scoped
packages would work out for interactive program development, where you
sometimes need to bop back and forth from one package environment to
another, adding code incrementally.

-- Scott

∂11-Apr-85  2127	masinter.pa@Xerox.ARPA 	Re: PROBE-FILE  
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 11 Apr 85  21:27:22 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 APR 85 21:24:34 PST
Date: 11 Apr 85 21:24 PST
From: masinter.pa@Xerox.ARPA
Subject: Re: PROBE-FILE
In-reply-to: various messages
To: common-lisp@SU-AI.ARPA

I missed some of the mail on probe-file before firing off my suggestion.
I think deferring discussion until after resolution of some of the error
system questions sounds reasonable.

 

∂11-Apr-85  2139	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: PROBE-FILE   
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 11 Apr 85  21:39:17 PST
Posted-Date:  12 Apr 85 00:23 EST
Date:  Fri, 12 Apr 85 00:21 EST
From:  Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject:  Re: PROBE-FILE
To:  common-lisp@SU-AI.ARPA
In-Reply-To:  Message of 11 Apr 85 14:55 EST from "Scott E. Fahlman"
Message-ID:  <850412052150.000502@MIT-MULTICS.ARPA>

    Date:  11 April 1985 14:55 est
    From:  Scott E. Fahlman <Fahlman at CMU-CS-C>
    Subject:  PROBE-FILE

    I've avoided stepping into this particular discussion (and probably will
    regret doing so now) but it looks to me like it might be time to try to
    close the issue, for now at least.  Let me toss out the following
    suggestions to see if they are acceptable to everyone:

    1. It is allowable for a Common Lisp system to signal an error on probef
    if the file name is malformed in some way, or if the file is not found
    for other than the usual reasons.

    2. Implementations that don't want to handle this with an error, perhaps
    because they lack an error-handling system of sufficient power, can for
    now do something compatible but non-portable about this, such as taking
    a special keyword or returning an extra value describing what went
    wrong.

    3. We should try again for a clean, fully portable solution to this
    problem after we have reached some consensus on a standard
    signal/error-handling system.  At that point, we'll be able to see much
    more clearly whether this is a good way to deal with this sort of
    situation.

    -- Scott



I think the signalling of an error in the case of a namestring that is
syntactically illegal is an entirely separate issue that applies to most
of the file system interface function.

Many functions besides PROBE-FILE can take a namestring as an argument
(e.g., PATHNAME, OPEN, RENAME-FILE,DELETE-FILE).  Nowhere does the CLRM
define what occurs if one of these functions is given a syntactically
illegal namestring.

Only PARSE-NAMESTRING is explicitly defined to signal an error "if the
[name]string does not consist entirely of the representation of a
pathname."

My suggestions are as follows:

1.  The function PATHNAME be defined to signal an error if given a
syntactically illegal namestring.

2.  The parameter names FILE, FILENAME, and THING be flushed and
replaced with PATHNAME.

3.  Explicity state that all functions that take a PATHNAME argument
implicity apply the function PATHNAME to the argument.

This would mean that PROBE-FILE WOULD signal an error if given a
syntactically illegal namestring.  Otherwise, if PROBE-FILE is given a
legal namestring, it should NOT signal an error if the pathname is
SEMANTICALLY illegal (e.g., non-existent dir.), I assumed this is what
TRUENAME was for.  (If this is not the case, what IS the dif.  between
PROBE-FILE and TRUENAME).

∂12-Apr-85  0701	greek@DEC-HUDSON 	A-Packaging we will go...  
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 12 Apr 85  07:00:12 PST
Date: Fri, 12 Apr 85 10:00:19 EST
From: greek@DEC-HUDSON
Subject: A-Packaging we will go...
To: common-lisp@su-ai

[My new comments are in square brackets -- Paul.]

    Well, Mr. Moon, I gave your comment some thought.  It was a bit terse,
    but perhaps this is what you meant:

    What happens if a macro calls a function during the expansion of a
    macro call?  If that function is in, say, the "USER" package, and the
    compiler were to make the current package "SPECIAL-COMPILER-PACKAGE-
    THAT-NO-ONE-ELSE-USES", then indeed the function wouldn't be found
    at compile time.

What if the function was in the LISP package?  Does your special compiler
package inherit from there or doesn't it?  If it doesn't, macros can't
run.  If it does, you can't tell whether a symbol came from there via
package prefix or via inheritance.

[Well, as you say, it must inherit from the LISP package.
But why do I care whether the compiler can tell that the symbol had
a package prefix or inherited the symbol?  The fact is that the symbol
is in the LISP package, so the fast loader better find it there.]

    But then again, it wouldn't be found if the user didn't happen to be
    in the "USER" package when compiling the program.  If the program
    must be compiled in the "USER" package, it ought to do an IN-PACKAGE
    at the top.

    If I read you wrong, please let me know.

    By the way, here's what VAX LISP currently does:  If the compiler goes
    to dump a symbol which is in the current package (not any special
    compiler package), then it dumps it without a package.  This means
    it will be loaded into the current package at the time of loading.

In other words, it does the same thing as PRINT.  This is what our compiler
does, too.

[But do we agree that's correct?]

    I don't think this is quite right, since it means that if I'm in
    the "FOO" package when I compile, and I say FOO::SYM, and then I'm
    in "BAR" when I load it, SYM will end up in "BAR" rather than "FOO".
    To avoid this problem, I think you need the special compiler package.

A better approach is for the compiler to tell the loader what the value
of *PACKAGE* was when the file was compiled.  If the loader binds
*PACKAGE* to the same value (that is, to a package with the same name)
when the file is loaded, symbol names in the compiled file will be
interpreted as the compiler intended when it dumped them.  This approach
works well for us.  Of course the user can get into arbitrary amounts of
trouble by changing package definitions between the time a file is compiled
and the time it is loaded, but that is inherently unavoidable.  For instance,
if the source file referenced FOO::SYM, and SYM was imported or inherited
by the source file's package at compile time, but not at load time, then
the wrong SYM will be referenced.

[I don't see how this solves the problem I described above with the FOO
and BAR packages.  Seems to me that SYM would end up in the FOO package
alright, but so would an unqualified symbol, say SYM2.  But SYM2 ought
to end up in BAR, the current package at load time.  To summarize:

source file, compiled when FOO is current package:

	FOO::SYM1
	SYM2

fastload file, loaded when BAR is current package:

	FOO::SYM1	; Better end up in FOO.
	SYM2		; Better end up in BAR.
]

∂12-Apr-85  0704	FAHLMAN@CMU-CS-C.ARPA 	PROBE-FILE  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Apr 85  07:03:54 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 12 Apr 85 10:03:47-EST
Date: Fri, 12 Apr 1985  10:03 EST
Message-ID: <FAHLMAN.12102566546.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Nick Gall <Gall@MIT-MULTICS.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: PROBE-FILE
In-reply-to: Msg of 12 Apr 1985  00:21-EST from Nick Gall <Gall at MIT-MULTICS.ARPA>


A problem with your suggestion is that in most of the distributed,
heterogenous environments that people are moving to now, there's not a
clear separation between syntactic and semantic problems with a
namestring.  Add a unix system to your search-list, and suddenly the
slash character turns from syntactic garbage to an essential part of an
address.  So I wouldn't want the error/no-error distinction to depend on
whether the string was ill-formed or merely happened not to point to a
reasonable place in the current environment.

- Scott

∂12-Apr-85  1103	KMP@SCRC-STONY-BROOK.ARPA 	Probe-file and errors  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 12 Apr 85  11:03:18 PST
Received: from SCRC-RIO-DE-JANEIRO by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 214170; Fri 12-Apr-85 13:58:44-EST
Date: Fri, 12 Apr 85 13:58 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Probe-file and errors
To: dzg@CMU-CS-SPICE.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <6595.160879383.>
Message-ID: <850412135811.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Thu 11 Apr 85 15:41:18-EST
    From: dzg@CMU-CS-SPICE.ARPA

    What seems to be impossible, for some reason, is to make simple things simple.
    ... My code just wants to do
      (cond ((probe-file "/usr/foo/bar")
	     ...)
	    ((probe-file "/user/may/be")
	     ...)
	    ((probe-file "/yet/another/one")
	     ...)
	    (t
	     ... cannot find it. Bye. ...))
    Simple as that. I do not (DO NOT!) want to handle an error...

In LispM lisp, you would write:

    (cond ((ignore-errors (probe-file "/usr/foo/bar"))
	   ...)
	  ...etc)

It seems to me that this is not an unreasonable thing and has the
advantage of making it nicely explicit that you in fact don't care 
what happens in the failing cases. 

IGNORE-ERRORS is not in my error proposal but could be added.
-kmp

∂12-Apr-85  1416	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: PROBE-FILE   
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 12 Apr 85  14:15:56 PST
Date:  Fri, 12 Apr 85 17:11 EST
From:  Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject:  Re: PROBE-FILE
To:  common-lisp@SU-AI.ARPA
In-Reply-To:  Message of 12 Apr 85 10:03 EST from "Scott E. Fahlman"
Message-ID:  <850412221124.132617@MIT-MULTICS.ARPA>

    Date:  12 April 1985 10:03 est
    From:  Scott E. Fahlman <Fahlman at CMU-CS-C>
    Subject:  PROBE-FILE

    A problem with your suggestion is that in most of the distributed,
    heterogenous environments that people are moving to now, there's not a
    clear separation between syntactic and semantic problems with a
    namestring.  Add a unix system to your search-list, and suddenly the
    slash character turns from syntactic garbage to an essential part of an
    address.  So I wouldn't want the error/no-error distinction to depend on
    whether the string was ill-formed or merely happened not to point to a
    reasonable place in the current environment.

    - Scott


My suggestion is based on the `clear separation' that the CLRM itself
makes between an `ill-formed' namestring and a namestring that is
well-formed but meaningless.  This distinction is explicitly made in the
definition of PARSE-NAMESTRING (pg.  414):  An error is signalled if the
[name]string does not consist entirely of the representation of a
pathname.

1.  IF one agrees that PARSE-NAMESTRING signals an error when given an
ill-formed namestring, but does not signal an error when given a
well-formed namestring (regardless of its meaningfulness)

2.  AND IF one agrees that any function (call it FOO) that takes a
namestring argument implicity calls PARSE-NAMESTRING (perhaps via
PATHNAME) to transform the namestring into a pathname

3.  AND IF one agrees that any error signalled by the implicit call to
PARSE-NAMESTRING is propagated by FOO

THEN one should agree that PROBE-FILE must signal an error if (but not
necessarily only if) given an ill-formed namestring.

My suggestion boils down to making points 2 and 3 EXPLICIT in the CLRM,
based on my belief that these two points are already IMPLIED in the
CLRM.

P.S.  I'm not sure I understand the comment about adding a unix system
to my search list, but I believe that namestrings are usually parsed
`with reference to a particular file name syntax of several avaialable
in the implementation' (pg.  414).  And the Host component is `used to
determine the syntax convention' (pg.  414).  Doesn't this take care of
the slashes?

∂12-Apr-85  1755	JLW  	Two PROBE-FILE questions
To:   RAM@CMU-CS-C.ARPA
CC:   common-lisp@SU-AI.ARPA

In-reply-to: your Msg of 10-Apr-85 14:56 EST

I think you've elucidated, in the second paragraph, the main difficulty
of a non-opening probe-file.  True, one of these problems isn't unique to
probe-for-output -- that of asynchronous change in th file system by some
other process -- but that doesn't lessen the importance.  The second one
(that I was thinking of) is simply the problem of TRUENAME -- unless you
actually open-for-output, then there's a high probability that you can't
find exactly th fully-qualified pathname that the file system would have
returned.  Version numbers is one of the problems; following links may be
another; and finaly (for me, at least) there is the confusion as to whether
the result of a direction-output call is a "file name" or merely a very
hypothetical pathname -- e.g., "this pathname is NOT a file, but if you
had called open instead of probe-file, then this would have been the name
of the file so opened".

Say, Rob, do you get the same sense that I do that something went astray
with this discussion?  In my note of 9-Apr-85, I thought I was arguing
the case for using OPEN directly, rather than preceeding it by a call
to PROBE-FILE; this led to the suggestion to continue the development
of "signals"  *** in order to field the file-not-found error from OPEN ***
But it looks like the discussion centered around fielding error signals
from probe-file.  foo.

If I wasn't clear about my bias before, let me state it now; I don't see
much use for direction-output for probe-file.  Let probe-file remain a
simple function, such as DZG wants, with an informational nature, and
let us discourage users from imagining it to be some kind of file system
semaphore.

-- JonL --

∂12-Apr-85  1822	card.pa@Xerox.ARPA 	Re: Arg cont checking, optionals, keywords, etc   
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 12 Apr 85  18:04:51 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 APR 85 18:01:41 PST
Date: 12 Apr 85 18:01 PST
From: card.pa@Xerox.ARPA
Subject: Re: Arg cont checking, optionals, keywords, etc 
In-reply-to: Jon White <JLW@SU-AI.ARPA>'s message of 09 Apr 85 17:22 PST
To: JLW@SU-AI.ARPA
cc: Card.pa@Xerox.ARPA, bug-1100@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA

I believe the Common Lisp syntax untimately derives from Muddle.  There
is of course virtue, if the change were to occur in Interlisp-D,
adopting a  syntax compatible with Common Lisp.  

For my taste, however, I would prefer one compatible with Interlisp-D
DECL DLAMBDAs as in my earlier examples.  This allows (at the option of
the programmer) stronger error checking than argument counting alone as
well as self-documentation of the variables.  Both syntaxes could be
available in this case and could compile to the same code.

Stu

∂12-Apr-85  1929	FAHLMAN@CMU-CS-C.ARPA 	Common Lisp should use lexical scoping    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Apr 85  19:29:15 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 12 Apr 85 22:29:23-EST
Date: Fri, 12 Apr 1985  22:29 EST
Message-ID: <FAHLMAN.12102702302.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   masinter.pa@XEROX.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: Common Lisp should use lexical scoping
In-reply-to: Msg of 12 Apr 1985  19:09-EST from masinter.pa at Xerox.ARPA


Larry, 

Maybe I misunderstand what you mean by "lexical scoping" of packages,
since your proposal was not spelled out in detail.  But here's what I am
worried about:

When we're speaking of the scope variables, lexical scoping means that
the scope of the variable is one contiguous chunk in the file being
read, and once you leave the lexical block you can never again get hold
of that variable by using its name (though function closures defined
within the block can still get at the variable).  You cannot sneak in
one more function later that refers to the same X.  That's awkward at
times, but also an advantage, since the compiler can be sure that after
it has reached the end of a block, it knows all about how a lexical
variable in that block can be referenced.

In lexically scoped packages, presumably this property would be
preserved.  So you would have to load all of the contents of a package
in a single chunk, even if this stuff comes form several files.
After you exit the lexical scope of a package, presumably you could
never again go back and add a new symbol to it, though I suppose the
reader could still refer to existing symbols in that package.
(Otherwise, the whole package could just be thrown out after you exit
the scope.)

That might possible make sense if you are thinking only of reading a
bunch of existing files into the Lisp, but when you are developing code
that perhaps lives in several packages, you need to be able to bounce
back and forth between packages, adding new stuff to each package.  I
don't see any way to do this without some sort of dynamic scoping of
packages.

Perhaps I have totally misunderstood your proposal?

-- Scott

∂13-Apr-85  1410	HANDERSON@CMU-CS-C.ARPA 	Common Lisp should use lexical scoping  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 13 Apr 85  14:10:28 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Sat 13 Apr 85 17:10:36-EST
Date: Sat, 13 Apr 1985  17:10 EST
Message-ID: <HANDERSON.12102906405.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To:   "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Cc:   common-lisp@SU-AI.ARPA, masinter.pa@XEROX.ARPA
Subject: Common Lisp should use lexical scoping
In-reply-to: Msg of 12 Apr 1985  22:29-EST from Scott E. Fahlman <Fahlman>


I think that the reason for this property (that an environment is created once
and never altered) is so that you can assign positions in a vector to the
variables, for runtime efficiency.  If you have an alist, there's no reason why
you couldn't create a scheme where you could push things onto it etc. and have
it do the right thing.  

For interning symbols, you could probably afford to do a hairy loadtime search
to find where the symbol is, since once you find it, you have this physical
object to refer to.  The package specification would just look something like a
pathname.  Of course, I think one of the problems with packages might be that
adding a variable FOO to a shadowing packages doesn't shadow an already-loaded
symbol.  I dunno.

-- Steve

∂15-Apr-85  1712	Moon@SCRC-QUABBIN.ARPA 	Common Lisp should use lexical scoping   
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 15 Apr 85  17:12:26 PST
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 153822; Mon 15-Apr-85 15:33:51-EST
Date: Mon, 15 Apr 85 15:30 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Common Lisp should use lexical scoping
To: masinter.pa@XEROX.ARPA, Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>,
    Steven <Handerson@CMU-CS-C.ARPA>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 11 Apr 85 21:42-EST from masinter.pa@Xerox.ARPA,
             <FAHLMAN.12102702302.BABYL@CMU-CS-C.ARPA>,
             <HANDERSON.12102906405.BABYL@CMU-CS-C.ARPA>
Message-ID: <850415153047.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

The subject of this conversation is rather a misnomer.  I believe that
what you are really suggesting is that packages should affect the
mapping from symbols to named entities (variables, functions, etc.)
rather than the mapping from print-names to symbols.

That is certainly a reasonable position to take, and some other
languages (Scheme, T, Lisp 2) have taken it with varying degrees of
success.  As I recall, we considered this when designing Common Lisp but
decided that the technical risk was too high.  One thing to think about
is that there are many different mappings from symbols to named
entities, some of them implemented by user programs; the "et cetera" in
my first paragraph is hiding a multitude of things.  Sticking to Common
Lisp, there are data types, defstructs, declarations, properties, and
keywords.  Going outside of Common Lisp brings in such named objects as
flavors, messages, editor commands, and any number of user-defined
spaces of named objects.  Which of these should be affected by packages
and which should not?  And should the implementation of a mapping by the
property list or by some other mechanism be exposed in the semantics of
that mapping with respect to packages?

T has some reasonable responses to these issues, and I think if Common
Lisp were being designed in 1987 we might decide differently after
studying languages such as T and how their users use them.  But Common
Lisp was designed in 1982.  We decided to go with the well-understood
package philosophy that the Lisp machine had been using since about
1978, substantially redesigned to fix its well-understood bugs without
radically changing the whole philosophy.  It's hard to achieve
perfection in this mortal vale.  For additional insight, see the James
Madison quotation on the second page of the manual.

∂15-Apr-85  1713	Moon@SCRC-QUABBIN.ARPA 	A-Packaging we will go... 
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 15 Apr 85  17:12:52 PST
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 153861; Mon 15-Apr-85 17:00:44-EST
Date: Mon, 15 Apr 85 16:57 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: A-Packaging we will go...
To: greek@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 12 Apr 85 10:00-EST from greek at DEC-HUDSON
Message-ID: <850415165739.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 12 Apr 85 10:00:19 EST
    From: greek@DEC-HUDSON

    [My new comments are in square brackets -- Paul.]

	Well, Mr. Moon, I gave your comment some thought.  It was a bit terse,
	but perhaps this is what you meant:

	What happens if a macro calls a function during the expansion of a
	macro call?  If that function is in, say, the "USER" package, and the
	compiler were to make the current package "SPECIAL-COMPILER-PACKAGE-
	THAT-NO-ONE-ELSE-USES", then indeed the function wouldn't be found
	at compile time.

    What if the function was in the LISP package?  Does your special compiler
    package inherit from there or doesn't it?  If it doesn't, macros can't
    run.  If it does, you can't tell whether a symbol came from there via
    package prefix or via inheritance.

    [Well, as you say, it must inherit from the LISP package.
    But why do I care whether the compiler can tell that the symbol had
    a package prefix or inherited the symbol?  The fact is that the symbol
    is in the LISP package, so the fast loader better find it there.]

I thought the whole point of your suggestion for a special compiler package
was that you cared.

	But then again, it wouldn't be found if the user didn't happen to be
	in the "USER" package when compiling the program.  If the program
	must be compiled in the "USER" package, it ought to do an IN-PACKAGE
	at the top.

	If I read you wrong, please let me know.

	By the way, here's what VAX LISP currently does:  If the compiler goes
	to dump a symbol which is in the current package (not any special
	compiler package), then it dumps it without a package.  This means
	it will be loaded into the current package at the time of loading.

    In other words, it does the same thing as PRINT.  This is what our compiler
    does, too.

    [But do we agree that's correct?]

I believe that it is inherently the best thing that can be done, if you grant
the compiler uses the Lisp READ function as its lexical analyzer.

	I don't think this is quite right, since it means that if I'm in
	the "FOO" package when I compile, and I say FOO::SYM, and then I'm
	in "BAR" when I load it, SYM will end up in "BAR" rather than "FOO".
	To avoid this problem, I think you need the special compiler package.

    A better approach is for the compiler to tell the loader what the value
    of *PACKAGE* was when the file was compiled.  If the loader binds
    *PACKAGE* to the same value (that is, to a package with the same name)
    when the file is loaded, symbol names in the compiled file will be
    interpreted as the compiler intended when it dumped them.  This approach
    works well for us.  Of course the user can get into arbitrary amounts of
    trouble by changing package definitions between the time a file is compiled
    and the time it is loaded, but that is inherently unavoidable.  For instance,
    if the source file referenced FOO::SYM, and SYM was imported or inherited
    by the source file's package at compile time, but not at load time, then
    the wrong SYM will be referenced.

    [I don't see how this solves the problem I described above with the FOO
    and BAR packages.  Seems to me that SYM would end up in the FOO package
    alright, but so would an unqualified symbol, say SYM2.  But SYM2 ought
    to end up in BAR, the current package at load time.  To summarize:

    source file, compiled when FOO is current package:

	    FOO::SYM1
	    SYM2

    fastload file, loaded when BAR is current package:

	    FOO::SYM1	; Better end up in FOO.
	    SYM2		; Better end up in BAR.
    ]

This problem derives entirely from the (doomed) attempt to compile a file
in one package and load it into another.  You cannot expect reasonable
results from this.  Hence my suggestion for the loader to ensure that the
file is loaded into the correct package.  If FOO was not the correct
package, why did you compile it in that package?  Or, to ask the question
another way, why did your compiler compile it in the wrong package?  This
relates to the other discussion about the file attribute convention (-*-).

This piece of mail is getting rather long.  I suggest that if we need to
discuss this further, we should prune it.  I myself don't have anything
further to say.

∂15-Apr-85  1718	DLW@SCRC-STONY-BROOK.ARPA 	probe-file   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Apr 85  17:17:43 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 214940; Mon 15-Apr-85 16:10:40-EST
Date: Mon, 15 Apr 85 16:10 EST
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: probe-file
To: masinter.pa@XEROX.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 11 Apr 85 22:27-EST from masinter.pa@Xerox.ARPA
Message-ID: <850415161032.9.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: 11 Apr 85 19:27 PST
    From: masinter.pa@Xerox.ARPA

I understand your point and disagree.  We gave this a great deal of
thought when we were designing our error system.

    Note that there is some mutual property of these two functions, in that
    either is relatively simple to implement in terms of the other, given an
    error system of the imagined complexity of the Common Lisp error system.

Indeed.  In Symbolics Common Lisp, probe-file-that-generates-errors is
just probe-file, and probe-file-without-errors can be defined as

(defun probe-file-without-errors (pathname)
  (condition-case (error-object)
      (probe-file pathname)
    (error (values nil error-object))))

    Which would you prefer to have in the "standard" Common Lisp? Both?
    Which would fit well with "most programs"? Which would "most
    programmers" naturally chose if they had both available in their
    library?

Given a good error-handler system such as ours, I think the
"generates-errors" is the one that should be provided.  In my
experience, doing it the way you suggest (returning error codes) means
that either every function call has to be surrounded by all these forms
to receive the value and test it and so on, or else the programmers get
lazy, leave that stuff out, and when the error conditions happen the
programs plow right along doing all kinds of incorrect things.  In our
system, if the programmers have something in particular that they'd like
to do in the face of errors, they can express these things concisely and
clearly, and if they aren't thinking about errors or are just lazy, then
unanticipated errors put the program into an interactive debugger before
they go off and cause more damage.

We've been using this error system for a couple of years and are quite
happy with it.

∂15-Apr-85  1718	DLW@SCRC-STONY-BROOK.ARPA 	Common Lisp should use lexical scoping
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Apr 85  17:18:14 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 214948; Mon 15-Apr-85 16:24:26-EST
Date: Mon, 15 Apr 85 16:24 EST
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Common Lisp should use lexical scoping
To: masinter.pa@XEROX.ARPA, Common-Lisp@SU-AI.ARPA
Message-ID: <850415162426.1.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: 11 Apr 85 18:42 PST
    From: masinter.pa@Xerox.ARPA

    Of course, I'm not talking about the scoping of variables, but rather of
    packages. The "package" of a piece of code is really a lexical property
    of the code. The fact that packages are dynamic in extent rather than
    lexical has led to almost all of the problems in defining what happens
    to packages and the compiler. 

Packages aren't dynamic in extent.  They have indefinite extent.  See
Chapter 3.  I'm not sure that the analogy to the "lexical versus
dynamic" dichotomy is a very good way of looking at this, since nothing
in question has dynamic extent.  ("Dynamic scope" really means
indefinite scope and dynamic extent.)

In any case, I'm wondering the same things as Scott.  Could you please
elaborate on your proposal?

∂15-Apr-85  1719	DLW@SCRC-STONY-BROOK.ARPA 	PROBE-FILE   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Apr 85  17:18:32 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 214964; Mon 15-Apr-85 16:55:53-EST
Date: Mon, 15 Apr 85 16:55 EST
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: PROBE-FILE
To: KMP@STONY-BROOK.SCRC.Symbolics.COM, greek@DEC-HUDSON.ARPA,
    common-lisp@SU-AI.ARPA
Message-ID: <850415165553.6.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Thu, 11 Apr 85 14:26 EST
    From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>

    So, perhaps surprisingly, I'm suggesting that using error signalling may
    simplify (rather than complicate) the look of code and maybe people with
    hairy-construct phobias will actually like this...
    -kmp

I agree completely and strongly with Kent's point.  In my earlier reply
to Masinter, this is what I was trying to get at.

∂15-Apr-85  1843	FAHLMAN@CMU-CS-C.ARPA 	probe-file  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 15 Apr 85  18:43:33 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 15 Apr 85 21:43:39-EST
Date: Mon, 15 Apr 1985  21:43 EST
Message-ID: <FAHLMAN.12103480407.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   common-lisp@SU-AI.ARPA
Subject: probe-file
In-reply-to: Msg of 15 Apr 1985  16:10-EST from Daniel L. Weinreb <DLW at TENEX.SCRC.Symbolics.COM>


As I said earlier, it probably is best to handle this on an ad hoc basis
until we get an error system defined.  We're not going to make much
progress as long as some of us view the error system as warm and fuzzy
and others of us view it as something to be avoided at all costs.

-- Scott

∂16-Apr-85  0740	greek@DEC-HUDSON 	Packages and the Compiler  
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 16 Apr 85  07:40:28 PST
Date: Tue, 16 Apr 85 10:40:28 EST
From: greek@DEC-HUDSON
Subject: Packages and the Compiler
To: common-lisp@su-ai

Yes, I guess we've exhausted this subject pretty much.  I think compiling
in one package and loading into another is useful.  I always debug a
new subsystem, say FORMAT, by working in a temporary FORMAT package
and then finally loading the file into SYSTEM and running the tests.
Why should I have to recompile it again to do that?

Anyway, we basically agree that compiling in one package and loading
into another is ill-defined.

- Paul

∂16-Apr-85  1433	DLW@SCRC-STONY-BROOK.ARPA 	Compilation and package system   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Apr 85  14:33:03 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 215535; Tue 16-Apr-85 17:20:07-EST
Date: Tue, 16 Apr 85 17:20 EST
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Compilation and package system
To: Wholey@CMU-CS-C.ARPA
cc: Common-lisp@SU-AI.ARPA, perdue%hplabs.csnet@CSNET-RELAY.ARPA
In-Reply-To: <WHOLEY.12101913081.BABYL@CMU-CS-C.ARPA>,
             The message of 9 Apr 85 22:14-EST from Wholey@CMU-CS-C.ARPA,
             <WHOLEY.12101913081.BABYL@CMU-CS-C.ARPA>,
             The message of 10 Apr 85 22:33-EST from Moon@STONY-BROOK.SCRC.Symbolics.COM,
             <850410223354.7.MOON@EUPHRATES.SCRC.Symbolics.COM>,
             The message of 10 Apr 85 23:51-EST from Wholey@CMU-CS-C.ARPA,
             <WHOLEY.12102192890.BABYL@CMU-CS-C.ARPA>,
             The message of 11 Apr 85 00:35-EST from KMP@STONY-BROOK.SCRC.Symbolics.COM,
             <850411003554.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
             <WHOLEY.12101913081.BABYL@CMU-CS-C.ARPA>,
             The message of 11 Apr 85 03:41-EST from Wholey@CMU-CS-C.ARPA,
             <WHOLEY.12102234761.BABYL@CMU-CS-C.ARPA>
Message-ID: <850416172034.2.DLW@CHICOPEE.SCRC.Symbolics.COM>

To summarize this discussion, the desired solution that would satisfy
everyone would have the following properties:

(1) Package specifications should not use the -*- stuff at all, because
there's nothing about -*- in the Common Lisp manual.  Not only does this
make it easier to port programs, but it's necessary to allow the
building of portable programs that understand files of Common Lisp code
(e.g. cross referencers).  It's OK to have the -*- in ADDITION to the
portable forms that specify package setups, but it's purely optional
from the point of view of the Common Lisp evaluator and compiler.
(Possibly we could back off and have a yellow-pages package that
Symbolics provides and other implementations pick up.)

(2) The editor needs as much information about packages as the compiler
and the loader.  All programs that read Lisp forms from files must get
the package information from the same place, and work consistently.
Furthermore, it is out of the question for you to have to manually
evaluate forms out of the buffer before you can edit properly.

(3) It should not be required that complex package setups be in their own
file, since you want to be able to use packages flexibly even in
programs that fit in one file.  Use of packages shouldn't force you to
have to split your program into many files, with associated pain in
copying them, etc, etc.

(4) If Symbolics Common Lisp and its editor are to work correctly on
ported unmodified Common Lisp source files, it must be prepared to deal
with CMU files, which use -*- lines that refer to packages that aren't
created until that very file is evaluated.  Right now, the CLCP user
at CMU gets an error.  Strictly speaking, the program is valid Common
Lisp, because Common Lisp doesn't ever look inside comments, and so
the CLCP is technically in error.

As far as I can tell, the only way to meet the first three constraints
is to require the editor to parse through the entire file, finding all
of the package-related forms such as IMPORT, when the file is read in.
It's a bit harder than that, since those forms might be inside of
EVAL-WHEN forms.  Or COND forms.  Or there might be a function defined
in the file and later called at top-level that does an IMPORT.  Worse
yet, the "package environment" might be different at different parts of
the file, as various package-related forms are sprinkled among the
function definitions.

I don't think this is feasible.

Zetalisp has basically taken the stance that each file has exactly one
"package environment" that's the same throughout the file, and the
information that sets up this environment is essentially declarative,
rather than imperative.  These restrictions have not turned out to be a
problem, based on large volumes of sophisticated code turned out over
several years.  In exchange for them, we get point (2) above.  Perhaps
it is our disagreement over (2)'s importance that is really at the
bottom of this discussion.

∂16-Apr-85  1556	Moon@SCRC-STONY-BROOK.ARPA 	Compilation and package system  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Apr 85  15:56:21 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 215600; Tue 16-Apr-85 18:56:32-EST
Date: Tue, 16 Apr 85 18:53 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Compilation and package system
To: Common-lisp@SU-AI.ARPA
References: <850416172034.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-ID: <850416185341.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

Side-comment: I know of three other (besides Symbolics) Lisps that use the
-*- convention for file attributes and have representatives on this mailing
list.  I'm mildly surprised that none of them have spoken up so far.

∂16-Apr-85  1808	DD60@CMU-CS-A.ARPA 	Package system 
Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 16 Apr 85  18:08:32 PST
Date: Tue, 16 Apr 85 20:58 EST
From: David.Dill@CMU-CS-A.ARPA (L170DD60)
To: common-lisp@su-ai.arpa
Subject: Package system
Message-Id: <16Apr85.205840.DD60@CMU-CS-A.ARPA>

One must use the package system in a very restricted way in order for
compilers, editors, and other (mostly not-yet-existent) program
transformation tools to do reasonable things.  During the design of the
package system, I don't think that anyone was under the delusion that
arbitrary common lisp code sequences that manipulate the package system
(or do a large number of other things) would behave the same compiled
as interpreted.

The package chapter should probably have had more to say about this,
and should not have documented the "conventional use of the package
system", which is very important for preserving sanity, in the
"example" subsection.  Somewhere, relatively simple restrictions on the
use of the package system should be precisely described, so that users
can distinguish code that will work from code that might not, and
portable code from non-portable code.

Why does the editor problem have to be so hard?  It seems to me that if
programmers would make the call to in-package be the first lisp form in
the file, the editor would have no more trouble setting up the proper
package context than it would with the magic comment crock.

I also think that if complex package structures turn out to be really
necessary (which I am not convinced of), a number of standard ways to
deal with them could be developed so that a user could be reasonably
assured of not getting screwed, AND editors, compilers, and so on,
would be able to understand what is going on, all within CL.


∂16-Apr-85  1921	FAHLMAN@CMU-CS-C.ARPA 	Compilation and package system  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 16 Apr 85  19:21:13 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 16 Apr 85 22:20:44-EST
Date: Tue, 16 Apr 1985  22:20 EST
Message-ID: <FAHLMAN.12103749301.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   "Daniel L. Weinreb" <DLW%scrc@MIT-MC.ARPA>
Cc:   Common-lisp@SU-AI.ARPA
Subject: Compilation and package system


    (1)...  It's OK to have the -*- in ADDITION to the
    portable forms that specify package setups, but it's purely optional
    from the point of view of the Common Lisp evaluator and compiler.

Right!

I'm not sure what all gets tangled up in the Zetalisp compiler when
CLCP is turned on, but maybe something like the following would fly:
Use a slightly different notation in the comment line for each of the
three cases of interest:

A. This is a Zetalisp-style file comment, and the editor can get all
that it needs right here in this comment line.

B. This is vanilla Common Lisp, but it follows the convention (as in
Zetalisp and the vast majority of Spice Lisp code) that the whole file
fits into one package environment that is set by in the first few forms
in the file.  The first time the user asks for some form in the buffer
to be read into Lisp or compiled, the system would first execute these
opeing forms, stopping when it hits something non-package-related.
(Or we could use some explicit marker telling the system when to stop.)
In this case, if there is a "Package:Foo" in the -*- line, that is
shorthand for "Don't bother reading anything in the file -- all you need
to know is that the first statement is a simple (in-package "FOO").

C. This is vanilla Common Lisp with no guarantees about the package
structure in the file.  If the user actually asks for something in the
buffer to be read into Lisp or compiled, the system must first read
everything up to that point in order to be sure that the environment is
right.  The system could query him to see if he wants to go through with
this.

Note that this is not an extension to Common Lisp, but merely a
convention that those implementations with embedded Emacs-like editors
might adopt to make code-sharing easier.

-- Scott

∂17-Apr-85  0800	DLW@SCRC-QUABBIN.ARPA 	Package system   
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 17 Apr 85  08:00:10 PST
Received: from SCRC-CHICOPEE by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 154375; Wed 17-Apr-85 11:00:10-EST
Date: Wed, 17 Apr 85 11:01 EST
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Package system
To: David.Dill@CMU-CS-A.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <16Apr85.205840.DD60@CMU-CS-A.ARPA>
Message-ID: <850417110105.7.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Tue, 16 Apr 85 20:58 EST
    From: David.Dill@CMU-CS-A.ARPA (L170DD60)

    Why does the editor problem have to be so hard?  It seems to me that if
    programmers would make the call to in-package be the first lisp form in
    the file, the editor would have no more trouble setting up the proper
    package context than it would with the magic comment crock.

What if there are some IMPORT forms following the IN-PACKAGE form?

What if there are some IMPORT forms 3/4 of the way into the file?
How does the editor know when to stop scanning for such forms?

∂17-Apr-85  0841	GSB@MIT-MC 	Re: Compilation and package system    
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 17 Apr 85  08:40:54 PST
Date: Wed,17 Apr 85 11:40:48 EST
From: Glenn S. Burke <GSB@MIT-MC>
Subject: Re: Compilation and package system
To: Moon@SCRC-STONY-BROOK
cc: Common-lisp@SU-AI
Message-ID: <[MIT-MC].458008.850417.GSB>

    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>

    Side-comment: I know of three other (besides Symbolics) Lisps that use the
    -*- convention for file attributes and have representatives on this mailing
    list.  I'm mildly surprised that none of them have spoken up so far.

I had thought i had sent a request to my PR department to send the
standard file-attribute-list blurb off to the common-lisp people, but
they must have slipped up.  Oh well -- you know what it's like in
these huge organizations.

NIL uses file attribute lists quite heavily.  The method in which they
are defined is (or at least was a year ago) an extension of how it was
done in Zetalisp, too.  They are most commonly used for package
specification, and secondarily for specifying the reader syntax, since
NIL has been incrementally converted to common-lisp reader syntax.
(This doesn't count "editor mode", but that's almost invariably "lisp"
for lisp code anyway.)

∂17-Apr-85  1722	masinter.pa@Xerox.ARPA 	"lexical" packages   
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 17 Apr 85  17:22:19 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 APR 85 17:20:45 PST
Date: 17 Apr 85 17:20 PST
From: masinter.pa@Xerox.ARPA
Subject: "lexical" packages
To: Common-Lisp@SU-AI.ARPA

Rebuttals:

Fahlman:

"When we're speaking of the scope variables, lexical scoping means that
the scope of the variable is one contiguous chunk in the file being
read, and once you leave the lexical block you can never again get hold
of that variable by using its name (though function closures defined
within the block can still get at the variable).  You cannot sneak in
one more function later that refers to the same X.  That's awkward at
times, but also an advantage, since the compiler can be sure that after
it has reached the end of a block, it knows all about how a lexical
variable in that block can be referenced."

Of course this isn't true, lest we be reduced to using core dumps to
debug. Of course, the debugger and the environment can reasonably be
expected to provide a way to access "lexical" variables. But such
mechanisms are part of CLTE rather than CLTL. The language has semantics
with invariants (if you (setq x --) here and call a function, you can
still expect x to have the same value), and the environment gives you
tools to break those invariants. Thus, while I propose making the
"package" a lexical property (more on that later), any reasonable
environment would provide ways of dynamically switching.

Moon:
"T has some reasonable responses to these issues, and I think if Common
Lisp were being designed in 1987 we might decide differently after
studying languages such as T and how their users use them.  But Common
Lisp was designed in 1982.  We decided to go with the well-understood
package philosophy that the Lisp machine had been using since about
1978, substantially redesigned to fix its well-understood bugs without
radically changing the whole philosophy.  It's hard to achieve
perfection in this mortal vale.  For additional insight, see the James
Madison quotation on the second page of the manual."

This is one of the weakest arguments to make -- it can be applied to any
of the discussions on this or any of the other mailing lists about
Common Lisp. If there's no chance to remove some of the mistakes in
Common Lisp, there seems to be no grounds for further discussion.

- - - - - - -

Restatement of proposal:

Packages should rightfully be lexical (determined by character sequences
in the file) rather than a dynamic (determined by what you've recently
executed). 

Let me make a specific proposal:

Just as (DECLARE --) is a special form, and "it is an error" to attempt
to evaluate a declaration, I propose that 

provide, in-package, shadow, export, require, use-package, import

all be documented as as special forms; they may only occur at the
beginnings of files. They are special markers that load, the compiler,
and the editor etc. can look for. (The wording for this can be taken
almost directly from the documentation of "declare" in CLTL p 153).

This turns what was formally a convention into a requirement. It means
that editors/file packages/etc. can actually look at a file and
determine (by scanning the beginning of the file) what packages might be
used/exported/etc. by the file. It makes illegal most of the odd (bad
programming practice) things that can go wrong with the package system.
It removes the requirement that the whole file be read, parsed and
executed in order to get a particular function. Many of the caveats in
the package section could be removed.

For those who already have an implementation of the current package
mechanism, the burden of this new scheme is minimal -- they can add
error checking, but need not.

∂17-Apr-85  1752	FAHLMAN@CMU-CS-C.ARPA 	"lexical" packages    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 17 Apr 85  17:51:50 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 17 Apr 85 20:51:55-EST
Date: Wed, 17 Apr 1985  20:51 EST
Message-ID: <FAHLMAN.12103995276.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   masinter.pa@XEROX.ARPA
Cc:   Common-Lisp@SU-AI.ARPA
Subject: "lexical" packages
In-reply-to: Msg of 17 Apr 1985  20:20-EST from masinter.pa at Xerox.ARPA


Larry,

OK, now I think I understand what you're saying, as far as it goes.
This is very similar to what the Symbolics people were just arguing for:
that all of the package stuff happens at the start of a file, and the
"scope" within which a package is the default for the reader is one
file.

I'm basically in sympathy with the idea that you don't change the
package environment in the middle of a file.  Right now, I can't think
of any situation in which I'd really want to change packages within a
file.  So far, so good.

I think that I would often want to load N files, some of which go into
package A and some of which go into package B in any order.  There's no
problem with this as long as each file going into a certain package has
identical (or maybe just compatible) package stuff at the start.  To me,
this isn't exactly lexical, as I understand the term, but there's no
point in quibbling about terminology.

What I don't understand about your proposal is how one deals with
input to the reader that is not in the form of a file, with its natural
lexical boundaries.  How do we handle terminal input, input from streams
whose source is unknown to the Lisp, and so on, if not dynamically?

If the essence of your proposal is that we handle packages more as less
as we do now, except that IN FILES the package forms must all occur at
the start and the system can take their scope to be the whole file,
that's worth some careful study.  It certainly is good style in all the
situations I can think of, so maybe enforcing it wouldn't be so bad.
However, this sort of messes up the abstraction that Lisp just sucks
streams into the reader and that the reader doesn't care where the stuff
is coming from.

-- Scott

∂18-Apr-85  1013	DLW@SCRC-STONY-BROOK.ARPA 	Compilation and package system, an addendum
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Apr 85  10:10:21 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 216975; Thu 18-Apr-85 13:09:26-EST
Date: Thu, 18 Apr 85 13:10 EST
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Compilation and package system, an addendum
To: TIM@MC.MIT
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[MIT-MC].459123.850418.TIM>
Message-ID: <850418131043.2.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Thu,18 Apr 85 01:22:26 EST
    From: Tim McNerney <TIM@MIT-MC>

    Yes, there could be an arbitrary amount of hair, but there is a big
    difference between assuming that an entire file will be read in the
    package declared by the -*- line and supporting lusers who want to
    generate the screw cases you allude to above.  Once the package
    environment is established, simply having the ZMACS keep a package
    attribute for each section will support editing files like patch files
    which need to be read in a number of different packages.

You seem to be saying that the high cost can be avoided by not
supporting "lusers" who generate the "screw cases".  In other words, the
editor should not actually parse the entire file, because that costs too
much, and it's OK if it does the wrong thing for the screw cases.  I
could be convinced of that principle.  So, what is your counterproposal?
Exactly what will the editor do when a file is read in, such that it
does all the right things except in "screw cases"?  How does it know
where to stop parsing?

And if you expect the editor to work correctly on files like patch
files, with different package environments in each section, then you
certainly do need to scan the entire file.  If you disagree, what's
your countersuggestion?

∂18-Apr-85  1253	REM%IMSSS.#Pup@SU-SCORE.ARPA 	What is a "file"? Lexical package usage?
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 18 Apr 85  12:52:55 PST
Received: from IMSSS by Score with Pup; Thu 18 Apr 85 12:39:03-PST
Date: 18 Apr 1985 1235-PST
From: Rem@IMSSS
Subject: What is a "file"? Lexical package usage?
To:   COMMON-LISP%SU-AI@SCORE

A file signals its end by an end-of-file marker of some kind (I'd have to
look in the CL manual to remind myself what it is in CL). The beginning of
a file is indicated by being right after you have done some kind of OPEN,
and is lexical extent is from that point unti the end-of-file marker occurs.
Perhaps if lexical packages are implemented, other streams can issue package
and other start-of-file stuff right after they are "opened" whatever that
means for the stream, and can signal the end of a lexical segment by an
end-of-file marker? For terminal-input and other infinite streams, the
interpretor can immediately re-open them after noting the lexical break
caused by end-of-file, flushing any info it had about the package state
from the just-now-closed segment and preparing to accept new package
declarations from the new segment to arrive next on the re-opened stream.
Would that solve the problem with "IN A FILE" being a special case?
-------

∂18-Apr-85  1847	Moon@SCRC-STONY-BROOK.ARPA 	"lexical" packages    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Apr 85  18:47:32 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 217657; Thu 18-Apr-85 21:47:29-EST
Date: Thu, 18 Apr 85 21:44 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: "lexical" packages
To: masinter.pa@XEROX.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 17 Apr 85 20:20-EST from masinter.pa at XEROX
Message-ID: <850418214445.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

I understand now that what you meant was not at all what you seemed to be saying.
This will bear some thinking about.  More from me on this later, perhaps.

∂18-Apr-85  1911	KMP@MIT-MC 	"lexical" packages
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Apr 85  19:07:24 PST
Date: Thu,18 Apr 85 22:01:15 EST
From: Kent M Pitman <KMP@MIT-MC>
Subject: "lexical" packages
To: Common-Lisp@SU-AI, Masinter.PA@XEROX, Fahlman@CMU-CS-C,
    Moon@SCRC-STONY-BROOK
Message-ID: <[MIT-MC].460578.850418.KMP>

I'd prefer to see the sort of lexicality I think you're talking about
handled through OPEN rather than READ, but agree it's worth thinking
about..

∂19-Apr-85  2128	DLW@SCRC-STONY-BROOK.ARPA 	"lexical" packages
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 19 Apr 85  21:28:19 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 218502; Sat 20-Apr-85 00:28:00-EST
Date: Sat, 20 Apr 85 00:30 EST
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: "lexical" packages
To: masinter.pa@XEROX.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 17 Apr 85 20:20-EST from masinter.pa@XEROX.ARPA
Message-ID: <850420003003.1.DLW@CHICOPEE.SCRC.Symbolics.COM>

If you recall my four-point message (of Tue, 16 Apr 85 17:20 EST,
replying to Skef), your proposal indeed meets all four points.  It also
solves the editor-scanning problem, since as soon as the editor sees any
normal forms it can stop scanning.  It also solves all those other
problems I mentioned about evaluating those things inside various forms
or functions, since they can no longer appear there.

Only one problem comes to mind, and it's not hard to solve.  Sometimes
you have a system made up of many files that are all in the same
package, and all have the same package environement.  (In fact, almost
all of the software that we work on here is big enough that we handle it
this way.)  It would be inconvenient and error-prone to have to
duplicate the package setup information in each of the files, since it
needs to be modified from time to time.  There needs to be some kind of
indirection feature that lets you have one centralized file holding the
package setup.  The editor would have to read this centralized file when
the original file is read in.

This leads to problems inherent in storing absolute pathnames inside of
files.  On the Lisp Machine, we would store logical pathnames, so that
if the whole group of files were installed at some other site, the
embedded pathname would still work.  This is outside the realm of CLTL
as currently defined, but for us it should suffice.  There may be other
problems with embedded pathnames that aren't coming to mind, however.
I'd like to hear other comments.

∂19-Apr-85  2133	DLW@SCRC-STONY-BROOK.ARPA 	"lexical" packages
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 19 Apr 85  21:32:47 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 218506; Sat 20-Apr-85 00:32:28-EST
Date: Sat, 20 Apr 85 00:34 EST
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: "lexical" packages
To: masinter.pa@XEROX.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 17 Apr 85 20:20-EST from masinter.pa@XEROX.ARPA
Message-ID: <850420003442.2.DLW@CHICOPEE.SCRC.Symbolics.COM>

One other thing: you still have to let some of these things work from
interactive Lisp top level, or else it will be hard for programmers to
try things out, learn, interactively debug, and so on.  I don't think
in-package is needed, but I think most of the others are.

By the way, our implementation doesn't actually forbid you from typing a
(declare ...) form at top level.  It just returns the symbol DECLARE, as
Maclisp did.  The interpreter does this with declare forms inside
programs, as well.  The compiler gives you a warning, saying that the
declare doesn't belong there, and ignores it.

Your proposal uses the term "special form" in a non-standard way; COND
and DEFUN are special forms.  In fact, I think the CLRM is wrong when it
refers to DECLARE as a special form; in fact, (DECLARE ---) isn't a form
at all, the way that the CLRM defines it.  This is probably what led to
the ambiguity.

∂21-Apr-85  0357	RAM@CMU-CS-C.ARPA 	Bug in CLM.
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 21 Apr 85  03:57:37 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Sun 21 Apr 85 06:57:44-EST
Date: Sun, 21 Apr 1985  06:57 EST
Message-ID: <RAM.12104891993.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   common-lisp@SU-AI.ARPA
Subject: Bug in CLM.


    In CLTL, the description of #S on page 357 refers to the
defstruct constructor macro, when there is no such thing.  Obviously
what is meant here is a keyword (as opposed to BOA) constructor
function.

    The same description also appears to have an erroneous piece of
lisp code.  The symbol KEYWORD is passed to intern to indicate that
the symbol is interned in the keyword package.  The manual says that
the package argument "must be a package".

  Rob

∂22-Apr-85  2230	JLW  	Bug in CLM?   
To:   ram@CMU-CS-A.ARPA
CC:   common-lisp@SU-AI.ARPA

Regarding the second of your two bugs -- I notice a difference in
terminology in the manual between some functions of chapter 11 and
others.  In particular, some functions are documented like 'package-name'
is, namely it specifies that "The argument must be a package".  But
others, such as 'intern' for example, lack any such constraint, and
use phrases like "the specified package".  

There is such consistency in this choice of phraseology that I take it to 
mean that unless there is a clear statement that the argment must be a 
package datatype, then it is permissible for it to be anything reasonably 
coerceible to a package.  In this case, (intern ... 'KEYWORD) is the same 
as  (intern ... "KEYWORD") and (intern ... (find-package "KEYWORD"))

-- JonL --

∂23-Apr-85  0234	JLW  	Problems with packages? 
To:   common-lisp@SU-AI.ARPA

Just to review, do we all agree that 
  (1) readtables, 
  (2) packages, 
  (3) dynamic variables *read-base* and *read-suppress* etc
all form part of a global database affecting the reader syntax, and that it
is a unique featue of Lisp that this database may be modified dynamically
by the user?  Perhaps a fourth point ought to be added:
  (4) packages do not solve, nor even address, the problem of lexicality.

Too often in the past several years I've seen persons who "come up" with
a solution to the problem of lexical variables by "putting them in
separate packages".  It takes a lot of explaining to separate out the
difference between syntax parsing and program semantics; perhaps it is
because Lisp is so lividly dynamic that this confusion is so easy to make.
On the other hand, the spate of conjectures as to what "lexical packages" 
might possibly mean leads to a situation, a variant of (4), which could be 
stated as:
  (5) lexicality does not solve, nor even address, the problem of packages.

Given this background, and the fact that the "lexical packages" discussion 
seems to have been started by a misunderstanding of "lexical" or "packages" 
or both, then I think we can best spend our broadcasted mail time focusing
on questions like the following:
  (A) What else besides the default setting of *package* should be added
      to the set of conventions?  is the ZetaLisp "Syntax:" command adequate?
      Of course there is *read-base*, but what else?
  (B) Must the editor settle all parsing/syntax related settings before
      even "loading" in the file ?  or can it wait until a READ operation
      is applied to some part of the buffer?  a "lazy" parsing.
  (C) What are reasonable conventions for scoping a database configuration?
      Is a file the appropriate scope?   What about streams that arent files?

Regarding (B), one may well ask why a line like
    (IN-PACKAGE "FOO")
is any more mysterious to a default-context parser than the line
;;; Package: FOO
Dill seemed to be asking this question in his note last week; one needn't
think that the former line has to be subjected to READ any more than the
latter one.  But the more lispy looking line *can* be interpreted by
the simple-minded read-eval-print loaded.

Weinreb seemed to summarize the differences between th ZetaLisp approach
and the SpiceLisp approach as the amount of importance attached to the
editor context problem.  I hope it will never be the case, such as it
is now in Interlisp, that one can create files which the standard system
tools cannot parse well enough to be able to edit (and, hence to fix
the silly little bug that managed to creep into them).  Admittedly it
doesn't happen often, but on those ocasions one must abandon the standard
program/file editor (in Interlisp) and drop down to some kind of text
editor to repair the damage.  [It is not, repeat not, such a simple 
thing to do to an Interlisp program file, for generally lots of low-level
things you never really wanted to know about will break when you "hand-
edit" a file, and you'll spend half an hour to half a day trying to
figure out random messages about "file maps" and so on.]


-- JonL --

∂24-Apr-85  0655	greek@DEC-HUDSON 	Code Generated by Macros   
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 24 Apr 85  06:54:42 PST
Date: Wed, 24 Apr 85 09:54:41 EST
From: greek@DEC-HUDSON
Subject: Code Generated by Macros
To: common-lisp@su-ai

Did anyone out there write any of the Common LISP macro definitions
so that they generate DO, DOTIME, DOLIST or the like?  Oops.

If the programmer uses a macro inside a construct that establishes
a block named NIL, and then does a RETURN from inside the macro,
there had better not be any blocks named NIL generated by the macro,
or the RETURN will return to the wrong place.

Not an obvious problem, and we blew it.  Or maybe the idea of a block
named NIL is bogus.

- Paul

∂24-Apr-85  0714	RAM@CMU-CS-C.ARPA 	Bug in CLM?     
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Apr 85  07:14:05 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 24 Apr 85 10:14:03-EST
Date: Wed, 24 Apr 1985  10:13 EST
Message-ID: <RAM.12105714157.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   Jon White <JLW@SU-AI.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Bug in CLM?   
In-reply-to: Msg of 23 Apr 1985  01:30-EST from Jon White <JLW at SU-AI.ARPA>


    Date: Tuesday, 23 April 1985  01:30-EST
    From: Jon White <JLW at SU-AI.ARPA>
    cc:   common-lisp at SU-AI.ARPA
    Re:   Bug in CLM?   

    There is such consistency in this choice of phraseology that I take it to 
    mean that unless there is a clear statement that the argment must be a 
    package datatype, then it is permissible for it to be anything reasonably 
    coerceible to a package.  In this case, (intern ... 'KEYWORD) is the same 
    as  (intern ... "KEYWORD") and (intern ... (find-package "KEYWORD"))

Does everyone agree that this is correct?  If this is the case, then
may *package* be random things also?  Currently Spice Lisp requires
every package argument to be a package.

  Rob

∂24-Apr-85  0750	FAHLMAN@CMU-CS-C.ARPA 	Bug in CLM?      
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Apr 85  07:50:03 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 24 Apr 85 10:50:09-EST
Date: Wed, 24 Apr 1985  10:49 EST
Message-ID: <FAHLMAN.12105720714.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Cc:   common-lisp@SU-AI.ARPA, Jon White <JLW@SU-AI.ARPA>
Subject: Bug in CLM?   
In-reply-to: Msg of 24 Apr 1985  10:13-EST from Rob MacLachlan <RAM>


I seem to have misplaced JONL's original message, so I'm not sure what
"consistency of terminology" he is referring to.  I think that any
consistency in the manual is purely coincidental.  :-}

I believe that in writing the package chapter we were careful to say
that an argument could be "a package or package name" where that is what
we meant.  (A package name can be either a string or a symbol.)  When we
don't say that, as in INTERN, "package" means an object of type package
and nothing else.  It certainly is not the case that *package* can be
anything but a true package.  See page 174, the first sentence after the
heading for section 11.3, for a definitive statement of this.

-- Scott

∂24-Apr-85  0836	WHOLEY@CMU-CS-C.ARPA 	Code Generated by Macros    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Apr 85  08:36:03 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Wed 24 Apr 85 11:35:57-EST
Date: Wed, 24 Apr 1985  11:35 EST
Message-ID: <WHOLEY.12105729067.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To:   greek@DEC-HUDSON.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: Code Generated by Macros
In-reply-to: Msg of 24 Apr 1985  09:54-EST from greek at DEC-HUDSON

Yeah, I went through a little bit of contortion to make Do-All-Symbols and
friends be efficient and maintain the right block structure.  I don't remember
any other macros in the language that require bending over backwards to do this
sort of thing.  Do you have a list of such things that you ran into for the
rest of us?

Zetalisp has some stuff to get around this problem (which makes it easier for
users to write iteration macros that do the right thing), but I doubt it could
be easily added to the Common Lisp language.  Since Common Lisp programs are
supposed to be easily machine-analyzable, one might write a portable thing that
mangles the Returns inside a piece of code to return to a block of one's
choice.

It might be worth a sentence or two in the manual to point out to implementors
and users alike that one may have to resort to writing hairy Progs to retain
the "returnability" feature.  Implementors are, of course, required to do so
for things specified in CLTL, and users should be encouraged to do so.

--Skef

∂24-Apr-85  0958	greek@DEC-HUDSON 	Code Generated by Macros   
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 24 Apr 85  09:58:21 PST
Date: Wed, 24 Apr 85 12:58:16 EST
From: greek@DEC-HUDSON
Subject: Code Generated by Macros
To: common-lisp@su-ai

We found that the following "macros" generated loops that hid a
surrounding NIL block:

	CCASE
	CTYPECASE
	DO-SYMBOLS et al
	lots of compiler transformations (e.g., that turned a map
		into a loop)

Also, of course, plenty of macros written by users can inadvertently
cause the problem.

The simplest way around is to only generate TAGBODYs.  Even PROG
establishes a NIL block.

- Paul

∂24-Apr-85  1208	DCP@STONY-BROOK.SCRC.Symbolics.COM 	Code Generated by Macros
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Apr 85  12:07:28 PST
Received: from NEPONSET.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223090; Wed 24-Apr-85 15:07:14-EST
Date: Wed, 24 Apr 85 15:07 EST
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: Code Generated by Macros
To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 24 Apr 85 09:54-EST from greek at DEC-HUDSON
References: The message of 24 Apr 85 09:54-EST from greek at DEC-HUDSON,
            <WHOLEY.12105729067.BABYL@CMU-CS-C.ARPA>
Message-ID: <850424150703.5.NFEP@NEPONSET.SCRC.Symbolics.COM>

    Date: Wed, 24 Apr 85 09:54:41 EST
    From: greek@DEC-HUDSON

    Did anyone out there write any of the Common LISP macro definitions
    so that they generate DO, DOTIME, DOLIST or the like?  Oops.

    If the programmer uses a macro inside a construct that establishes
    a block named NIL, and then does a RETURN from inside the macro,
    there had better not be any blocks named NIL generated by the macro,
    or the RETURN will return to the wrong place.

    Not an obvious problem, and we blew it.  Or maybe the idea of a block
    named NIL is bogus.

I know what you are talking about, but I can't come up with an example
that can't be programmed around.  For example,
	(defmacro dotimes-named (name (var form) &body body)
	  `(block ,name
	     (return-from nil
 	       (block do-return-from-nil
		 (return-from ,name
		   (dotimes (,var ,form)
		     (block dont-return-from-nil
		       (return-from do-return-from-nil
			 (block nil
			   ,@body
			   (return-from dont-return-from-nil))))))))))

It isn't pretty, but it does work. I don't know if there are easier ways
to do this particular things.  I have seen easier ways to other similar
things.

Perhaps it is for reasons like this that Lisp Machine Lisp has DO-NAMED?
That is, perhaps DO-NAMED is the prefered thing to expand into instead
of DO, since it won't accidentally steal the block named NIL?

Another way out is to document your macros as "having an implicit block
named NIL".

∂24-Apr-85  1628	GSB@MIT-MC 	Code Generated by Macros    
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 24 Apr 85  16:28:38 PST
Date: Wed, 24 Apr 85 19:18:08 EST
From: Glenn S. Burke <GSB@MIT-MC>
Subject: Code Generated by Macros
To: common-lisp@SU-AI
Message-ID: <[MIT-MC].468518.850424.GSB>

    Date: Wed, 24 Apr 85 12:58:16 EST
    From: greek@DEC-HUDSON

    We found that the following "macros" generated loops that hid a
    surrounding NIL block:

    	CCASE
    	CTYPECASE
    	DO-SYMBOLS et al
    	lots of compiler transformations (e.g., that turned a map
    		into a loop)

    Also, of course, plenty of macros written by users can inadvertently
    cause the problem.

    The simplest way around is to only generate TAGBODYs.  Even PROG
    establishes a NIL block.

Oh come on.  This is what BLOCK and GENSYM are good for.  This is why
named PROGs have been useful in the past (in NIL and Zetalisp).
GENSYM is also good for generating tags within your tagbody -- you
still need to worry about uniqueness there.

∂24-Apr-85  1750	Moon@STONY-BROOK.SCRC.Symbolics.COM 	When is a package name equivalent to a package? 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Apr 85  17:50:03 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223474; Wed 24-Apr-85 20:49:47-EST
Date: Wed, 24 Apr 85 20:50 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: When is a package name equivalent to a package?
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
cc: Jon White <JLW@SU-AI.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12105714157.BABYL@CMU-CS-C.ARPA>
Message-ID: <850424205010.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 24 Apr 1985  10:13 EST
    From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>

	Date: Tuesday, 23 April 1985  01:30-EST
	From: Jon White <JLW at SU-AI.ARPA>

	There is such consistency in this choice of phraseology that I take it to 
	mean that unless there is a clear statement that the argment must be a 
	package datatype, then it is permissible for it to be anything reasonably 
	coerceible to a package.  In this case, (intern ... 'KEYWORD) is the same 
	as  (intern ... "KEYWORD") and (intern ... (find-package "KEYWORD"))

    Does everyone agree that this is correct?  If this is the case, then
    may *package* be random things also?  Currently Spice Lisp requires
    every package argument to be a package.

I think the manual is quite clear.

p.183 requires that the value of *package* be a package.

p.182 specifies that certain functions, including INTERN, shall accept strings
and symbols in place of packages.  As is unfortunately typical of the CLM,
this specification is not repeated in the documentation of each of the affected
functions, so it's quite easy to overlook.

∂24-Apr-85  1822	KMP@STONY-BROOK.SCRC.Symbolics.COM 	When is a package name equivalent to a package?  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Apr 85  18:21:54 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223510; Wed 24-Apr-85 21:21:31-EST
Date: Wed, 24 Apr 85 21:21 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: When is a package name equivalent to a package?
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, RAM@CMU-CS-C.ARPA
cc: JLW@SU-AI.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <850424205010.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <850424212146.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Return-path: <@MIT-MC.ARPA,@SU-AI.ARPA:Moon@STONY-BROOK.SCRC.Symbolics.COM>
    Received: from MIT-MC.ARPA by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 223502; 24 Apr 85 21:10:54-EST
    Received: from SU-AI.ARPA by MIT-MC.ARPA; 24 APR 85 21:00:04 EST
    Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Apr 85  17:50:03 PST
    Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223474; Wed 24-Apr-85 20:49:47-EST
    Date: Wed, 24 Apr 85 20:50 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    Subject: When is a package name equivalent to a package?
    To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
    cc: Jon White <JLW@SU-AI.ARPA>, common-lisp@SU-AI.ARPA
    In-Reply-To: <RAM.12105714157.BABYL@CMU-CS-C.ARPA>
    Message-ID: <850424205010.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

	Date: Wed, 24 Apr 1985  10:13 EST
	From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>

	    Date: Tuesday, 23 April 1985  01:30-EST
	    From: Jon White <JLW at SU-AI.ARPA>

	    There is such consistency in this choice of phraseology that I take it to 
	    mean that unless there is a clear statement that the argment must be a 
	    package datatype, then it is permissible for it to be anything reasonably 
	    coerceible to a package.  In this case, (intern ... 'KEYWORD) is the same 
	    as  (intern ... "KEYWORD") and (intern ... (find-package "KEYWORD"))

	Does everyone agree that this is correct?  If this is the case, then
	may *package* be random things also?  Currently Spice Lisp requires
	every package argument to be a package.

    I think the manual is quite clear.

    p.183 requires that the value of *package* be a package.

    p.182 specifies that certain functions, including INTERN, shall accept strings
    and symbols in place of packages.  As is unfortunately typical of the CLM,
    this specification is not repeated in the documentation of each of the affected
    functions, so it's quite easy to overlook.

I wonder if it wouldn't be worth introducing a PACKAGE-BIND special form, as in:
 (DEFMACRO PACKAGE-BIND (PACKAGE &BODY FORMS)
   `(LET ((*PACKAGE* (FIND-PACKAGE ,PACKAGE))) ,@FORMS))
just so users would never need to explicitly call FIND-PACKAGE.

Sure enough, I just checked and there's an SI:PKG-BIND special form which does
exactly that on the LispM so someone must have agreed with this suggestion...

∂24-Apr-85  1829	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Code Generated by Macros    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Apr 85  18:29:19 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223514; Wed 24-Apr-85 21:29:10-EST
Date: Wed, 24 Apr 85 21:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Code Generated by Macros
To: greek@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 24 Apr 85 12:58-EST from greek@DEC-HUDSON
Message-ID: <850424212930.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 24 Apr 85 12:58:16 EST
    From: greek@DEC-HUDSON

    We found that the following "macros" generated loops that hid a
    surrounding NIL block:

	    CCASE
	    CTYPECASE
	    DO-SYMBOLS et al
	    lots of compiler transformations (e.g., that turned a map
		    into a loop)

DO-SYMBOLS is clearly documented to create a block named NIL.

You're right that the others are errors.  Our implementation handles
these correctly, but perhaps you were talking about macro definitions in
some other implementation, such as Spice Lisp.  It's quite easy to do
them right.

    Also, of course, plenty of macros written by users can inadvertently
    cause the problem.

    The simplest way around is to only generate TAGBODYs.  Even PROG
    establishes a NIL block.

A good rule of thumb is never to use PROG under any circumstances for
anything.

The real problem is DO, which you would often like to use, but have
to be careful about whether you intended to create a block or not.
A good rule of thumb is to write macros whose name does not start
with "DO" in terms of BLOCK, LET, and TAGBODY only -- then everything
is explicit.

∂24-Apr-85  1905	FAHLMAN@CMU-CS-C.ARPA 	When is a package name equivalent to a package?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Apr 85  19:04:28 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 24 Apr 85 22:04:42-EST
Date: Wed, 24 Apr 1985  22:04 EST
Message-ID: <FAHLMAN.12105843536.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   "David A. Moon" <moon%scrc@MIT-MC.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: When is a package name equivalent to a package?
In-reply-to: Msg of 24 Apr 1985  20:50-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


    I think the manual is quite clear.

    p.183 requires that the value of *package* be a package.

    p.182 specifies that certain functions, including INTERN, shall accept strings
    and symbols in place of packages.  As is unfortunately typical of the CLM,
    this specification is not repeated in the documentation of each of the affected
    functions, so it's quite easy to overlook.

Are we looking at the same page 182?   Where does it say that?  In the
last paragraph it says that "Any argument described as a PACKAGE NAME
may be either a string or a symbol."  Is that waht you're thinking of?
Intern takes a package argument, but says nothing about taking a package
name instead.

-- Scott

∂24-Apr-85  1932	Moon@STONY-BROOK.SCRC.Symbolics.COM 	When is a package name equivalent to a package? 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Apr 85  19:32:38 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223559; Wed 24-Apr-85 22:32:34-EST
Date: Wed, 24 Apr 85 22:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: When is a package name equivalent to a package?
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12105843536.BABYL@CMU-CS-C.ARPA>
Message-ID: <850424223253.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 24 Apr 1985  22:04 EST
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

        From: Moon
	I think the manual is quite clear.

	p.183 requires that the value of *package* be a package.

	p.182 specifies that certain functions, including INTERN, shall accept strings
	and symbols in place of packages.  As is unfortunately typical of the CLM,
	this specification is not repeated in the documentation of each of the affected
	functions, so it's quite easy to overlook.

    Are we looking at the same page 182?   Where does it say that?  In the
    last paragraph it says that "Any argument described as a PACKAGE NAME
    may be either a string or a symbol."  Is that waht you're thinking of?
    Intern takes a package argument, but says nothing about taking a package
    name instead.

You're absolutely right.  I didn't read the manual carefully enough and missed
the word "name" after "package", especially since two sentences earlier in the
same paragraoh it was talking about arguments named @I[package].  The wording
could use some improvement here, I think.

In fact page 182, now that I am reading it carefully, says nothing about
what values are legal to pass to an argument named package.

Now I have to ask if there is any significance to the fact that the argument
to FIND-PACKAGE is called name rather than package-name.

Obviously I should withdraw the first sentence of my earlier message!

Our implementation of these functions (INTERN, USE-PACKAGE, IMPORT, etc.)
accepts a package name as an argument where a package is required.  It seems
natural, and doesn't cost anything if you were doing error-checking anyway (and
blithely assuming that the argument is a package seems extra-dangerous here!).
However, I won't advocate that every implementation be required to accept a
package name in place of a package.

∂24-Apr-85  2057	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Problems with packages?     
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Apr 85  20:57:17 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223602; Wed 24-Apr-85 23:56:50-EST
Date: Wed, 24 Apr 85 23:57 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Problems with packages? 
To: Jon White <JLW@SU-AI.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 23 Apr 85 05:34-EST from Jon White <JLW@SU-AI.ARPA>
Message-ID: <850424235711.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 23 Apr 85  0234 PST
    From: Jon White <JLW@SU-AI.ARPA>
    ....I think we can best spend our broadcasted mail time focusing
    on questions like the following:
      (A) What else besides the default setting of *package* should be added
	  to the set of conventions?  is the ZetaLisp "Syntax:" command adequate?
	  Of course there is *read-base*, but what else?
      (B) Must the editor settle all parsing/syntax related settings before
	  even "loading" in the file ?  or can it wait until a READ operation
	  is applied to some part of the buffer?  a "lazy" parsing.
      (C) What are reasonable conventions for scoping a database configuration?
	  Is a file the appropriate scope?   What about streams that arent files?

(B): In our editor, "loading" in a file applies READ operations to parts of it.
How else is it supposed to know what functions are defined in the file?
The READ operation used is of course parameterized by the language and dialect
the file is written in, along with language-dependent parameters such as the
package.

    Regarding (B), one may well ask why a line like
	(IN-PACKAGE "FOO")
    is any more mysterious to a default-context parser than the line
    ;;; Package: FOO

I explained earlier that some editors, such as ours, need to support
multiple languages.  Not all languages have the same syntax for
statements in the language itself (clearly!), but every language that
we've heard of has comments and the same syntax of file attribute line
(the line with the -*-) can be used inside the comments of every
language that we've heard of.

To give a concrete example of the issues: of the three dialects of Lisp
we support, only one contains a function named IN-PACKAGE.

    Dill seemed to be asking this question in his note last week; one needn't
    think that the former line has to be subjected to READ any more than the
    latter one.  But the more lispy looking line *can* be interpreted by
    the simple-minded read-eval-print loaded.

It would be possible to make an editor that understands package
specifications in some clearly defined syntax besides the clearly
defined syntax of the file attribute line, and looks for that syntax if
it doesn't find a file attribute line.  Common Lisp does not begin to
specify such a syntax, it merely suggests (p.182) that "all of the
package setup forms appear near the start of the file."  I'm not
interested in spending my limited energies making this specification
concrete enough that it could be useful to a program, but perhaps others
are.

∂25-Apr-85  0054	JLW  	When is a package name equivalent to a package?  
To:   fahlman@CMU-CS-C.ARPA, moon@SCRC-STONY-BROOK.ARPA
CC:   common-lisp@SU-AI.ARPA   

In-reply-to: your messge of 24-Apr-85 22:04 EST

There are only three places I can remember that explicitly say 
"... must be a package":  the definition of *package*, the argument to
package-name, and the argment to package-nicknames.  It would seem reasonable
to me to let all other arguments called "package" be coercible from symbols,
strings, and packages.  I can't say that requireing the arguments to
package-name and package-nicknames to be "a package" achieves anything;
I'd be happier with Moon's suggestion to let all function args be coercible.

Actually, another constraint has been bugging me recently -- the argument
to in-package is constrained to be a "name"; why not let it be a package
also?  If you did so, it would have no bearing one way or other on the
advisibility of using a form like
   (IN-PACKAGE "USER")
as a CL minor-mode specifier.

∂25-Apr-85  0343	JLW  	More on (B): the editor's "reading" of files
To:   moon@SCRC-STONY-BROOK.ARPA
CC:   common-lisp@SU-AI.ARPA 

In-reply-to: your message of 24-Apr-85 23:57 EST

OK, I buy the argument that the editor wants to be able to distinguish
various language types [egad, some even do so by looking at the "extension"
field of the file name]; but after having made that distinction, wouldn't
it be reasonable to dispatch off to a programmable attribute-parser that
could be quite different from one language to another?

That is, given that you know that a file is in Common Lisp syntax (as
opposed to, say, Franz, or Fortran, or random text), then some flavor
of specialized parser would rip along and find out attributes that are
possibly unique to common lisp and possibly shared with other lisps.
One of the problems with the ;;; -*- convention is its lack of
"tailor-ability" by the user; and as this whole line of discussions has
brought out, there are more and more things that seem to want to be
in the attributes lines.

Of course, these are only conventions for the initial, or default, settings
of various user-accessible switches on the READer -- as DLW pointed out,
one may still have to process the file "in order", form by form, to be
100% sure of the correct state at any paticular point in the file.  Yet,
if some convention like this isn't adopted, then will CL be substandard
compared to zetalisp or spicelisp?  One of the latter two conventions
could be adopted bodily into CL;  I'm sure you have a preference here.

Interlisp has a number of internal, non-READ parsers that inspect the first 
portion of a file for certain information.  But it is mainly a time-saving 
hack that READ isn't used, because such source files are virtually always
mechaniclly produced, and have a very rigid format; in Interlisp, you
can *always* READ the first expression or so of the file and look at it
with CAR and CDR etc, because the Interlisp reader has no errors other
than premature end of file.  [well, almost *no* errors -- there is the
problem that symbols are limited to 256 characters.  I fixed a bug related
to this limitation sometime last year.]

By the bye, I'm not sure if your reply laid to rest my "fear" that one
can produce an almost-correct common lisp source file which the zetalisp
editor can't even bring in to a buffer (previous note used "load") because
it dies trying to READ some little part of it that happens to be total
garbage.  What's the scoop?


-- JonL --

∂25-Apr-85  0419	JLW  	What package are feature names resident in? 
To:   common-lisp@SU-AI.ARPA

Bottom of page 358 clearly suggests that #+ should READ in the expression
following the +, and obtain symbols which are tested for MEMBERship in
the *features* list.  So what should happen from the following fragment:
    (in-package "LUSER")
    (push 'dull *features*)
    (in-package "WINNER")
    (push 'snazzy *features*)
    (in-package "USER")
    '(a #+dull b #+snazzy c )
Now, how long a list is the last form read?

Consider when package LUSER is, and is not, a user of package LISP; and
when "dull" is, and is not, an external symbol of the LISP package.

I believe I see two schools of thought, exemplified in the several 
implemetations I've looked at so far.  One says that feature names can be
any lisp objects, and since luser:snazzy and winner:snazzy are two separate
features, you have to be careful about which one you really mean.  The 
other school says that feature names are analogous to the names of
packages -- a kind of global namespace --  and will probably implement #+ 
by binding *package* to some canonical place (like, the keyword package).

I'm not sure I can give an adequate defense of either position, but
the fact that two different implementations initialize their *features*
lists to symbols in different packages makes it difficult to interpret
forms like  
    #+Lispm (do-this)
because you don't which symbol the "Lispm" will turn into.  Should you
have to say
   #+:Lispm (do-this)
I don't think this was intended (to have to put package qualifiers for
feature names), but if there are two differing implemetations . . . 

Some folks here at Lucid think there was discussion on the matter a couple
years ago, but no one seems sure if a resolution was achieved.  Any
commets?


-- JonL --


P.S. The problem isnt IN-PACKAGE -- as someone pointed out already, it
is so trivial as to be almost redundant.  Most usages of it would be 
equivalent to (setq *package* (find-package <package-name>)).

∂25-Apr-85  0642	greek@DEC-HUDSON 	Code Generated by Macros   
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 25 Apr 85  06:42:05 PST
Date: Thu, 25 Apr 85 09:42:03 EST
From: greek@DEC-HUDSON
Subject: Code Generated by Macros
To: common-lisp@su-ai

Dave Plummer - Yes, I understand that you can write named DOs, and that
Common LISP should probably have one (and maybe not the DO we actually
have).  I was simply pointing out that standard Common LISP macros
could potentially be written incorrectly.  That macro you supplied,
DOTIMES-NAMED, doesn't seem to work.

Glenn Burke - Huh?  I'm not at all sure what you are trying to say.
PROG is, in fact, no good for this problem since it generates a NIL
block.

Dave Moon - Thank you for that succinct summary.  In fact, we DID
have a problem with DO-ALL-SYMBOLS, because it used DO-SYMBOLS, so
that two NIL blocks were generated and a RETURN would not quite get
all the way out.  That's what I was trying to say.

- Paul

∂25-Apr-85  1507	Moon@STONY-BROOK.SCRC.Symbolics.COM 	More on (B): the editor's "reading" of files    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 25 Apr 85  15:06:49 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 224275; Thu 25-Apr-85 18:06:30-EST
Date: Thu, 25 Apr 85 18:06 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: More on (B): the editor's "reading" of files
To: Jon White <JLW@SU-AI.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 25 Apr 85 06:43-EST from Jon White <JLW@SU-AI.ARPA>
Message-ID: <850425180639.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 25 Apr 85  0343 PST
    From: Jon White <JLW@SU-AI.ARPA>
    ....By the bye, I'm not sure if your reply laid to rest my "fear" that one
    can produce an almost-correct common lisp source file which the zetalisp
    editor can't even bring in to a buffer (previous note used "load") because
    it dies trying to READ some little part of it that happens to be total
    garbage.  What's the scoop?

We provide and document a command that reads a file into the editor without
looking at its attributes.  You are then editing the file in Fundamental Mode,
and the editor makes no attempt to do anything language-specific.

∂25-Apr-85  1523	fateman%ucbdali@Berkeley 	RPG's benchmarks coming out as an MIT press book 
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 25 Apr 85  15:23:19 PST
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.46)
	id AA05204; Thu, 25 Apr 85 15:22:11 pst
Received: by ucbdali.ARPA (4.24/4.46)
	id AA13833; Thu, 25 Apr 85 15:23:59 pst
Date: Thu, 25 Apr 85 15:23:59 pst
From: fateman%ucbdali@Berkeley (Richard Fateman)
Message-Id: <8504252323.AA13833@ucbdali.ARPA>
To: rpg@su-ai
Subject: RPG's benchmarks coming out as an MIT press book
Cc: common-lisp@su-ai

If the benchmarks which I submitted are going to appear in a copyrighted
book, I would like explicit permission
to appear that says that reproduction of the code, and reprinting of the
tables with additional data, and similar modifications or corrections
can be done without copyright hassles.

If it appears that I will lose control of programs that I wrote
as a consequence of RPG's paper, I would prefer to withdraw my benchmark.

Although I think that an MIT press copyright of such a program would be invalid,
let's try to set the correct precedent this time.  We messed up
royally on CLTL and Digital Press, in my opinion.

∂25-Apr-85  1935	FAHLMAN@CMU-CS-C.ARPA 	When is a package name equivalent to a package?     
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 25 Apr 85  19:35:11 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 25 Apr 85 22:35:31-EST
Date: Thu, 25 Apr 1985  22:35 EST
Message-ID: <FAHLMAN.12106111284.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Jon White <JLW@SU-AI.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: When is a package name equivalent to a package?  
In-reply-to: Msg of 25 Apr 1985  03:54-EST from Jon White <JLW at SU-AI.ARPA>


In the earlier messages we were discussing what the current situation
is, according to the manual.  I don't have time to search the archives,
but it seems to me that where we said "package", we meant "package".  We
might even have had a good reason for this.

If we are going to discuss changes, right now it sounds reasonable to me
to allow package names in most of the places that are documented to take
packages -- all except *package*, package-name, and package-nicknames --
as you suggest.  I can't construct a good argument against this right
now.

-- Scott

∂26-Apr-85  1211	RAM@CMU-CS-C.ARPA 	What package are feature names resident in?   
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 26 Apr 85  12:11:22 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Fri 26 Apr 85 15:11:22-EST
Date: Fri, 26 Apr 1985  15:11 EST
Message-ID: <RAM.12106292554.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   Jon White <JLW@SU-AI.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: What package are feature names resident in? 
In-reply-to: Msg of 25 Apr 1985  07:19-EST from Jon White <JLW at SU-AI.ARPA>


    I believe that the issue discussed was "Should features always be
keywords?"  The conclusion was "No, but they can be."  An implication
of this decision is that features are packaged symbols.

  Rob

∂26-Apr-85  1453	GSB@MIT-MC 	package names, consistency  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 26 Apr 85  14:52:38 PST
Date: Fri, 26 Apr 85 17:47:24 EST
From: Glenn S. Burke <GSB@MIT-MC>
Subject: package names, consistency
To: common-lisp@SU-AI
Message-ID: <[MIT-MC].471684.850426.GSB>

    Date: Thu, 25 Apr 1985  22:35 EST
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

    . . .
    If we are going to discuss changes, right now it sounds reasonable to me
    to allow package names in most of the places that are documented to take
    packages -- all except *package*, package-name, and package-nicknames --
    as you suggest.  I can't construct a good argument against this right
    now.

This sounds reasonable.  If one wants to draw comparisons, however, the
various PATHNAME "accessors", such as pathname-host, pathname-name, all
take anything which can be coerced to a pathname...

There are a few other things, mostly nomenclature inconsistencies,
which i have found myself explaining more than once.  One of the worst
appears to be simple-vector.  It should have been left as
simple-general-vector in spite of the verbiage.

∂27-Apr-85  1142	TIM@MIT-MC 	Editing multiple package files   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Apr 85  11:42:32 PST
Date: Sat, 27 Apr 85 14:42:44 EST
From: Tim McNerney <TIM@MIT-MC>
Subject:  Editing multiple package files
To: DLW@SCRC-STONY-BROOK
cc: Common-Lisp@SU-AI
Message-ID: <[MIT-MC].472449.850427.TIM>


    Date: Thu, 18 Apr 85 13:10 EST
    From: Daniel L. Weinreb <DLW at TENEX.SCRC.Symbolics.COM>
    To:   TIM at MC.MIT
    cc:   common-lisp at SU-AI.ARPA
    Re:   Compilation and package system, an addendum

        Date: Thu,18 Apr 85 01:22:26 EST
        From: Tim McNerney <TIM@MIT-MC>

        Yes, there could be an arbitrary amount of hair, but there is a big
        difference between assuming that an entire file will be read in the
        package declared by the -*- line and supporting lusers who want to
        generate the screw cases you allude to above.  Once the package
        environment is established, simply having the ZMACS keep a package
        attribute for each section will support editing files like patch files
        which need to be read in a number of different packages.

    You seem to be saying that the high cost can be avoided by not
    supporting "lusers" who generate the "screw cases".  In other words, the
    editor should not actually parse the entire file, because that costs too
    much, and it's OK if it does the wrong thing for the screw cases.  I
    could be convinced of that principle.  So, what is your counterproposal?
    Exactly what will the editor do when a file is read in, such that it
    does all the right things except in "screw cases"?  How does it know
    where to stop parsing?

    And if you expect the editor to work correctly on files like patch
    files, with different package environments in each section, then you
    certainly do need to scan the entire file.  If you disagree, what's
    your countersuggestion?

No, not at all.  You seem to have misunderstood me completely (This
probably stems from your not having read the message that my message
(above) was an addendum to).  

The original message merely suggested that since the editor has to
scan the file at least once, namely when the file is first being read
into the buffer (during "sectionization" in Zmacs' case), that the
editor record the package for each definition at that time.  The
"screw cases" that I refer to are those where a NON-TRIVIAL package
environment is set up BY THE FILE BEING READ IN.  As I said, once the
package environment is stable, having the editor support multiple
package files is more tractable.

∂28-Apr-85  1123	RPG   	Common Lisp song considered offensive?
 ∂27-Apr-85  1217	WHOLEY@CMU-CS-C.ARPA 	Common Lisp song considered offensive?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Apr 85  12:17:38 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Sat 27 Apr 85 15:17:50-EST
Date: Sat, 27 Apr 1985  15:17 EST
Message-ID: <WHOLEY.12106555872.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To:   Fahlman@CMU-CS-C.ARPA, Steele@THINK.ARPA, Moon@SCRC-STONY-BROOK.ARPA,
      DLW@SCRC-STONY-BROOK.ARPA, RPG@SU-AI.ARPA
Subject: Common Lisp song considered offensive?

Yesterday I received a piece of air mail from Taiichi Yuasa of Kyoto
University.  He and M. Hagiya are writing an article about "the current
movement of Common Lisp people in the States."  While looking through the
archives of the Common Lisp mailing list, they found my Common Lisp song, sung
to the tune of Bob Dylan's "Maggie's Farm."  They wrote asking me permission to
include it in their article.  I mentioned this to Scott, and he pointed out
that the song may be considered offensive to those of you mentioned in it.

If any of you object, I'll write to these guys and tell them not to print it.

To refresh your memories, the song implies (verse for verse) that
  1. Common Lisp is a compromise -- it's less than perfect,
  2. Fahlman runs a sweat shop,
  3. Steele doesn't read his mail,
  4. Moon is responsible for great gobs of hair, including Defsetf, and
     the Gang of Five settled some issues without the consent of the rest of
     those on the Common Lisp mailing list, and
  6. Some Lispers raised on pre-modern Lisps can't appreciate the fact that
     Explode and friends are gone.

I didn't think these things are particularly nasty, but understand that some of
you might not appreciate these things being published in Japanese BIT, "one of
the most popular computer science journals in Japan."  Let me know if that's
the case.

--Skef

∂28-Apr-85  1124	RPG   	Common Lisp song considered offensive?
 ∂27-Apr-85  1824	FAHLMAN@CMU-CS-C.ARPA 	Common Lisp song considered offensive?    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Apr 85  18:23:53 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 27 Apr 85 21:23:38-EST
Date: Sat, 27 Apr 1985  21:23 EST
Message-ID: <FAHLMAN.12106622464.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Skef Wholey <Wholey@CMU-CS-C.ARPA>
Cc:   DLW@SCRC-STONY-BROOK.ARPA, Moon@SCRC-STONY-BROOK.ARPA, RPG@SU-AI.ARPA,
      Steele@THINK.ARPA
Subject: Common Lisp song considered offensive?
In-reply-to: Msg of 27 Apr 1985  15:17-EST from Skef Wholey <Wholey>


I don't think that people not closely involved in this effort will have
any idea what most of the song is about, especially if they're Japanese.
I'm not sure they'll even know what a Perq is, let alone an X-1 key.

But I have no desire to stifle free speech, and it is undeniable that I
run a sweatshop.  (The Perq flashes a subliminal message with sexual
overtones that keeps my undergrads coming back for more -- a technique I
learned during my days as a brain programmer for the Illuminati.)  So I
won't be the one to object.  This article couldn't do nearly as much
damage as the Gabriel and Brooks "critique" or the upcoming publication 
of last year's Lisp benchmarks by MIT Press.

-- Scott

∂28-Apr-85  1124	RPG   	Common Lisp song considered offensive?
 ∂27-Apr-85  2101	DLW@QUABBIN.SCRC.Symbolics.COM 	Common Lisp song considered offensive?
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 27 Apr 85  21:01:32 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 158141; Sat 27-Apr-85 23:59:49-EST
Date: Sun, 28 Apr 85 00:04 EST
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Common Lisp song considered offensive?
To: Wholey@CMU-CS-C.ARPA, Fahlman@CMU-CS-C.ARPA, Steele@THINK.ARPA,
    Moon@STONY-BROOK.SCRC.Symbolics.COM, RPG@SU-AI.ARPA
cc: cwh@TENEX.SCRC.Symbolics.COM
In-Reply-To: <WHOLEY.12106555872.BABYL@CMU-CS-C.ARPA>
Message-ID: <850428000401.8.DLW@CHICOPEE.SCRC.Symbolics.COM>

I wish you had been here to hear my side-splitting laughter when I read
your message.  From my (admittedly limited) experience, this is a very
characteristically Japanese request.  Yuasa probably considers this a
great hack, and BIT would certainly publish it.  Anyway, it's fine with
me.  You might, however, want to ask him to run the idea by Masayuki
Ida, who is trying to get Common Lisp adopted as an industry standard of
JIEDA (sp?), and who is translating the manual into Japanese, just to
see if he'd consider it a problem.  It's fine with me, personally (I
don't even think I'm mentioned, anyway).

∂28-Apr-85  1400	Moon@SCRC-STONY-BROOK.ARPA 	Any complete CL implementations??    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Apr 85  13:59:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 225397; Sun 28-Apr-85 16:59:17-EDT
Date: Sun, 28 Apr 85 17:00 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Any complete CL implementations??
To: Rem%IMSSS@SU-SCORE.ARPA
cc: COMMON-LISP@SU-AI.ARPA
In-Reply-To: The message of 5 Apr 85 15:24-EST from Rem@IMSSS
Message-ID: <850428170009.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date:  5 Apr 1985 1224-PST
    From: Rem@IMSSS

    At this time, has anybody completely 100% implemented Common LISP
    on any machine at all? ....

I guess no one at Symbolics has answered this.  Our implementation of
Common Lisp, included in Release 6.0 of our 3600 software, is intended to
be complete and correct.  I'm sure there are still bugs that have not yet
been found and fixed.  In addition, there is a brief list of known deviations
from the standard, which can be found in volume 2 of the Release 6 documentation
set.  The functions and features that are not implemented, according
to that list, are integers as GO tags, certain declarations, row-major-order
arrays, ARRAY-ROW-MAJOR-INDEX, MAKE-CONCATENATED-STREAM, MAKE-ECHO-STREAM,
and ~E and ~G in FORMAT.  The other deviations are minor: for details, find
a 3600 installation and ask to look at their Release 6 documentation.

∂28-Apr-85  2033	RPG   	Common Lisp song considered offensive?
 ∂28-Apr-85  1917	FAHLMAN@CMU-CS-C.ARPA 	Common Lisp song considered offensive?    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 28 Apr 85  19:16:57 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 28 Apr 85 22:16:40-EDT
Date: Sun, 28 Apr 1985  22:16 EDT
Message-ID: <FAHLMAN.12106883352.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   DLW@SCRC-STONY-BROOK.ARPA, RPG@SU-AI.ARPA, Steele@THINK.ARPA,
      Skef Wholey <Wholey@CMU-CS-C.ARPA>
Subject: Common Lisp song considered offensive?
In-reply-to: Msg of 28 Apr 1985  16:33-EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>



    Actually if I remember correctly I'm not responsible for DEFSETF,
    only for cleaning it up and simplifying it, but I didn't check any
    archives.

I remember the event fairly well.  DEFSETF was simple but buggy on a few
things such as LDB.  You were the one who pointed this out and indicated
that in order to do DEFSETF right in the hard cases we had to go with
the five-fold version, DEFINE-SETF-METHOD (which you got from Bawden, I
believe).  So while you were not responsible for DEFSETF, you were the
one who brought the ultra-hairy version into the picture.  I guess that
counts as "claening up", but I'm not so sure about "simplifying".

Of course, I'd have just swept this particular problem under the rug,
which is why my rugs are always so lumpy.  One advantage of having a
group working on this kind of thing is that each of us was inclined to
be lazy about a different set of things, and there was usually someone
around to heap scorn on such laziness.

-- Scott

∂29-Apr-85  1300	Moon@SCRC-VALLECITO.ARPA 	wimpy COERCE function   
Received: from SCRC-VALLECITO.ARPA by SU-AI.ARPA with TCP; 29 Apr 85  13:00:31 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-VALLECITO.ARPA via CHAOS with CHAOS-MAIL id 10269; Mon 29-Apr-85 16:00:33-EDT
Date: Mon, 29 Apr 85 16:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: wimpy COERCE function
To: Niels Lauritzen <SR.LAURITZEN%MIT-SPEECH@MIT-MC.ARPA>
cc: BUG-LISPM%MIT-SPEECH@MIT-MC.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: <850428192527.1.LAURITZEN@YOGI.MIT>
Message-ID: <850429160029.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sunday, 28 April 1985, 19:25-EDT
    From: Niels Lauritzen <SR.LAURITZEN at MIT-SPEECH>

    In Symbolics 3670 Release 6.0

    >>Error: I don't know how to coerce an object to an integer modulo 3

    Hey, any computer ought to know how to coerce integers to integers modulo N.

    COERCE:  (P.C. = 22)
       Arg 0 (OBJECT): 45
       Arg 1 (TO-TYPE): (MOD 3)

I agree that this coercion would be easy to implement, provided you could get everyone
to agree that what you meant was (MOD 45 3) rather than signalling an error that 45
was out of range.

On the other hand, if you read the documentation of COERCE in the Common Lisp manual,
this is not one of the coercions that it lists as permissible.

I'm cc'ing this to the Common-Lisp mailing list in case anyone there wants to discuss
the pros and cons of what Common Lisp specifies for COERCE.  That discussion should
not include the other recipients, please.

∂29-Apr-85  1714	RWK@SCRC-STONY-BROOK.ARPA 	More on (B): the editor's "reading" of files    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 29 Apr 85  17:13:51 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 226043; Mon 29-Apr-85 20:12:59-EDT
Date: Mon, 29 Apr 85 20:13 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: More on (B): the editor's "reading" of files
To: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
cc: Jon White <JLW@SU-AI.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <850425180639.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <850429201354.0.RWK@CROW.SCRC.Symbolics.COM>

    Date: Thu, 25 Apr 85 18:06 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	Date: 25 Apr 85  0343 PST
	From: Jon White <JLW@SU-AI.ARPA>
	....By the bye, I'm not sure if your reply laid to rest my "fear" that one
	can produce an almost-correct common lisp source file which the zetalisp
	editor can't even bring in to a buffer (previous note used "load") because
	it dies trying to READ some little part of it that happens to be total
	garbage.  What's the scoop?

    We provide and document a command that reads a file into the editor without
    looking at its attributes.  You are then editing the file in Fundamental Mode,
    and the editor makes no attempt to do anything language-specific.

Also, we make use of our error system to trap such errors,
report the problem gracefully, and then read it in in Fundamental
Mode.

∂30-Apr-85  0735	DLW@SCRC-STONY-BROOK.ARPA 	wimpy COERCE function  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 30 Apr 85  07:35:18 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 226352; Tue 30-Apr-85 10:34:29-EDT
Date: Tue, 30 Apr 85 10:38 EDT
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: wimpy COERCE function
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: <850429160029.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <850430103856.8.DLW@CHICOPEE.SCRC.Symbolics.COM>

I'd say it's clear that both the letter and the spirit of the manual say
that this should signal an error.  I feel that this is the right thing.
The name MOD appears to be a pun capable of confusing people: it's just
an abbreviation.

∂04-May-85  0838	RAM@CMU-CS-C.ARPA 	Misfeature: macros expanding into declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 May 85  08:38:27 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Sat 4 May 85 11:08:50-EDT
Date: Sat, 4 May 1985  07:36 EDT
Message-ID: <RAM.12108296011.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   common-lisp@SU-AI.ARPA
Subject: Misfeature: macros expanding into declarations


    The Common Lisp feature of allowing a macro to expand into
declarations ought to be flushed; it complicates much code while
giving no useful return.  I suspect some of the complications were not
forseen when this feature was added to the language.  I believe that
the original purpose of this feature is subsumed by Deftype (which was
added later).

    The largest issue that I see is that writing macros that parse
declarations becomes much more complicated.  Every macro writer must
duplicate the non-trivial code which expands macros looking for
declarations.  Even if the macro writer goes to this trouble, a
subtlety that he is sure to miss is supplying the &environment keyword
to defmacro so that he can pass the lexical environment to
macroexpand.

    If this feature must remain, then there should be standard
functions for parsing declarations in the language.  This might not be
a bad idea anyway, but if the misfeature was eliminated there would be
no need to pass in the lexical environment.

    I won't even discuss the hair & inefficiency that this misfeature
adds to the system for fear of being accused of being a wimp or
interpreter weenie; anyone who has implemented a Common Lisp knows it
all too well.

  Rob

∂04-May-85  1209	FAHLMAN@CMU-CS-C.ARPA 	Misfeature: macros expanding into declarations 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 May 85  12:09:13 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 4 May 85 15:09:43-EDT
Date: Sat, 4 May 1985  15:09 EDT
Message-ID: <FAHLMAN.12108378504.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Misfeature: macros expanding into declarations
In-reply-to: Msg of 4 May 1985  07:36-EDT from Rob MacLachlan <RAM>


I agree with Rob: we should eliminate the ability of a macro in certain
places to expand into a declaration.  I cannot think of anything
essential that this feature buys us, and it certainly has caused many
bugs and lots of inefficiency in the various interpreters that I've
seen.  Code analysis tools would all have similar problems with this.
If I remember the original debate on this, it was a "what the hell, it
might be useful someday, let's add it" sort of decision, whose
consequeces we didn't totally appreciate.  If there's some important
case that really needs this feature, that's different, but I don't think
that there is.  Nor do I believe that there are more than ten lines of
Common Lisp code anywhere in the world (outside of validation tests)
that depend on this feature, so taking it out at this late date wouldn't
cause major upheavals.

Note that we are not arguing against the ability of a macro to turn into
some top-level form such as a DO that, among other things, contains
declarations.  We are arguing for the elimination of the feature
described on page 154, in the paragraph starting "It is permissible..."

-- Scott

∂04-May-85  1529	TIM@MIT-MC 	Misfeature: macros expanding into declarations  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 May 85  15:29:25 PDT
Date: Sat,  4 May 85 18:26:24 EST
From: Tim McNerney <TIM@MIT-MC>
Subject:  Misfeature: macros expanding into declarations
To: Fahlman@CMU-CS-C
cc: TIM@MIT-MC, common-lisp@SU-AI, RAM@CMU-CS-C
In-reply-to: Msg of Sat 4 May 1985  15:09 EDT from Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
Message-ID: <[MIT-MC].485362.850504.TIM>

    Date: Sat, 4 May 1985  07:36 EDT
    From: Rob MacLachlan <RAM at CMU-CS-C.ARPA>

        The Common Lisp feature of allowing a macro to expand into
    declarations ought to be flushed; it complicates much code while
    giving no useful return.

Although this "misfeature" makes life much harder on the Lisp implementor and
the macro writer, its semantics are not without utility.  Let me illustate
this with a couple of simple examples:

  ;;; Example 1

  (defmacro declare-my-specials ()
    '(declare (special *foo* *bar* *baz))

  ;; Once this is done, you can use this in all the functions which
  ;; use these special variables like so:

  (defun frob1! (a b)
    (declare-my-specials)
    ...)

  (defun frob2 (x)
    (declare-my-specials)
    ...)

  ;;; Example 2

  (defmacro declare-inlines ()
    (declare (special *debugging-p*))
    (if *debugging-p*                   ;Compile time flag
        '(declare (notinline car cdr)
      '(declare (inline car cdr eq)))

  ;; Then this declaration macro can be used is time-critical code like so:

  (defun %eq-seconds-p (list-1 list-2)
    (declare-inlines)
    (eq (cadr list-1) (cadr list-2)))

I am not saying that permitting macros to expand into declarations as stated
on p. 154 is a good mechanism for achieving this effect, but there should be
some way of getting the functionality suggested in the above examples.

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

    Note that we are not arguing against the ability of a macro to turn into
    some top-level form such as a DO that, among other things, contains
    declarations.  We are arguing for the elimination of the feature
    described on page 154, in the paragraph starting "It is permissible..."

I don't think that is reasonable to require the programmer to define macros
like DEFUN-WITH-MY-SPECIALS or DEFUN-WITH-DEBUGGABLE-INLINES or anything of
the sort.  At top level, these stand a good chance of confusing editors and
human readers.

For the sake of Lisp implementers and macro writers, I would suggest that
this mechanism be flushed in favor of a user-extensible DECLARE.  The DEFTYPE
macro is seriously deficient in this role.  Rather than using
(DECLARE-MY-SPECIALS) above, I could use (DECLARE (MY-SPECIALS)) or something
of the sort after defining MY-SPECIALS in some way.

    From: Rob MacLachlan <RAM at CMU-CS-C.ARPA>

        The largest issue that I see is that writing macros that parse
    declarations becomes much more complicated.  Every macro writer must
    duplicate the non-trivial code which expands macros looking for
    declarations.

        If this feature must remain, then there should be standard
    functions for parsing declarations in the language.  This might
    not be a bad idea anyway...

This is a great suggestion!  This would save a lot of duplicated effort. 
Case in point:

        ;Insert form after any declarations.  This is about the fifth place
        ;in the system that knows how to do this; somebody fix this.
        (DEFUN INSERT-INTO-BODY (FORM BODY)
          (LOOP WHILE (AND (CDR BODY)
			   (OR (STRINGP (CAR BODY))
			       (AND (LISTP (CAR BODY))
				    (EQ (CAAR BODY) 'DECLARE))))
		COLLECT (POP BODY) INTO DECLARATIONS
		FINALLY (RETURN (NCONC DECLARATIONS (NCONS FORM) BODY))))

        --From sys:sys2;flavor.lisp.564  (c) 1985 Symbolics, Inc.

Of course the common lisp version would be much hairier if the "misfeature"
were allowed to remain.

        Tim

∂04-May-85  1543	vanroggen@DEC-HUDSON 	macr --> declares 
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 4 May 85  15:43:01 PDT
Date: Sat, 04 May 85 18:44:06 EDT
From: vanroggen@DEC-HUDSON
Subject: macr --> declares
To: common-lisp@su-ai
Cc: vanroggen

I complained about this a while ago, and at the time, no one seemed to think
it worth changing the language definition. But it is a useful feature, and
not having macros expand into declarations won't avoid having some macros
needing to parse declarations.
While we're into complaining about declarations, I'd like to grouse about
type declarations not being meaningful when not applied to a binding in
the immediate special form or macro. The ability to say that a variable
will always be a certain type within a small body of code is very useful
and very common. Officially, requiring one to write a LET or the like just
so one can write a type declaration is very annoying.
			---Walter

∂04-May-85  1549	RAM@CMU-CS-C.ARPA 	Misfeature: macros expanding into declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 May 85  15:49:30 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Sat 4 May 85 18:49:56-EDT
Date: Sat, 4 May 1985  18:49 EDT
Message-ID: <RAM.12108418593.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   Tim McNerney <TIM@MIT-MC.ARPA>
Cc:   common-lisp@SU-AI.ARPA, Fahlman@CMU-CS-C.ARPA
Subject: Misfeature: macros expanding into declarations
In-reply-to: Msg of 4 May 1985  19:26-EDT from Tim McNerney <TIM at MIT-MC>


    I think both of your examples are better handled by other
mechanisms that already exist.

    In you (declare (special ...)) example, I suspect that making the
variables globally special would work better.  The only time it
wouldn't work was if you were actually binding the variables, and
sometimes bound them specially and sometimes not.  I doubt that anyone
does this, and if they do, it should probably be glaringly obvious.

As for the second example, I suggest:
  (defun %eq-seconds-p (list-1 list-2)
    #-debugging-p
    (declare (inline car cdr eq)))
    (eq (cadr list-1) (cadr list-2)))

    Are these samples of real code, or are they just contrived examples?

  Rob

∂04-May-85  1557	RAM@CMU-CS-C.ARPA 	macr --> declares    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 May 85  15:57:07 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Sat 4 May 85 18:57:23-EDT
Date: Sat, 4 May 1985  18:57 EDT
Message-ID: <RAM.12108419950.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   vanroggen@DEC-HUDSON.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: macr --> declares
In-reply-to: Msg of 4 May 1985  18:44-EDT from vanroggen at DEC-HUDSON


    I complained about this a while ago, and at the time, no one seemed to
    think it worth changing the language definition. But it is a useful
    feature, and not having macros expand into declarations won't avoid
    having some macros needing to parse declarations.

It won't eliminate the need for *any* macro's declaration parsing; it
will make it easier to do correctly.  I suspect that at the time,
nobody had implemented a macro that parsed declarations correctly, and
it is entirely possibly that this is still the case.

I challenge you assertion that it is a useful feature---show me.

  Rob

∂05-May-85  0145	HEDRICK@RUTGERS.ARPA 	(setf (apply #'foo
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 5 May 85  01:44:54 PDT
Date: 5 May 85 02:59:26 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: (setf (apply #'foo
To: common-lisp@SU-AI.ARPA

According to the manual, (setf (apply #'foo x y) z) is defined only when
(setf (foo x y) z) expands to something of the form (set-foo z x y). In
this case the original SETF expands to (apply #'set-foo z x y). I claim
that this statement is vacuous.  The problem is that no SETF form can
expand in this way.  To do so would violate the provision that SETF
must preserve left to right evaluation.  Certainly left to right
evaluation can be preserved by complex patterns involving LET, etc.
However in the case where SETF expands to a simple function call, it
is clear that the arguments must be in the same order as the arguments
to the original SETF.  In that case, the new value must be last, which
violates the preconditions for (SETF (APPLY
-------

∂05-May-85  0853	FAHLMAN@CMU-CS-C.ARPA 	macr --> declares
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 May 85  08:53:09 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 5 May 85 11:53:10-EDT
Date: Sun, 5 May 1985  11:53 EDT
Message-ID: <FAHLMAN.12108604865.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   vanroggen@DEC-HUDSON.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: macr --> declares
In-reply-to: Msg of 4 May 1985  18:44-EDT from vanroggen at DEC-HUDSON


    While we're into complaining about declarations, I'd like to grouse about
    type declarations not being meaningful when not applied to a binding in
    the immediate special form or macro. The ability to say that a variable
    will always be a certain type within a small body of code is very useful
    and very common. Officially, requiring one to write a LET or the like just
    so one can write a type declaration is very annoying.

It would be even more annoying to find that you've created a nice,
local, lexical variable binding and that its type is being mysteriously
restricted by some declaration off in left field somewhere.  I think
that it is clear that we want all of the declarations relevant to a
lexical variable binding to be present right there with the binding.

Of course, a SPECIAL proclamation can have non-local effects on what
would otherwise be lexical bindings, but at least we try to minimize the
bug-creation potential of this by encouraging people to use the *foo*
convention for such globally-special variables.

What does seem to be reasonable is to allow pervasive type declarations
for global special variables.  It seems reasonable to allow something
like the following:

(proclaim (special *foo*))
(proclaim (integer *foo*))

or

(defvar *foo* 27 "Number of FOOs still to be used." 'integer)

This seems quite useful to me, and doesn't ruin the locality of lexical
bindings.

-- Scott

∂05-May-85  0909	RAM@CMU-CS-C.ARPA 	macr --> declares    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 May 85  09:09:45 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Sun 5 May 85 12:09:47-EDT
Date: Sun, 5 May 1985  12:09 EDT
Message-ID: <RAM.12108607886.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Cc:   common-lisp@SU-AI.ARPA, vanroggen@DEC-HUDSON.ARPA
Subject: macr --> declares
In-reply-to: Msg of 5 May 1985  11:53-EDT from Scott E. Fahlman <Fahlman>


    The CLM seems to believe that type proclamations are legal.  The
following example is on page 156:

    (proclaim '(type float tolerance))

  Rob

∂05-May-85  0919	FAHLMAN@CMU-CS-C.ARPA 	Misfeature: macros expanding into declarations 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 May 85  09:19:08 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 5 May 85 12:19:02-EDT
Date: Sun, 5 May 1985  12:18 EDT
Message-ID: <FAHLMAN.12108609568.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Tim McNerney <TIM@MIT-MC.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Misfeature: macros expanding into declarations
In-reply-to: Msg of 4 May 1985  19:26-EDT from Tim McNerney <TIM at MIT-MC>



    Although this "misfeature" makes life much harder on the Lisp implementor and
    the macro writer, its semantics are not without utility.  Let me illustate
    this with a couple of simple examples:

If it were just a matter of making life harder on the Lisp implementor,
simple utility would probably be a sufficient argument.  It is a fact,
lamented by some, that in the original Common Lisp design we were quite
willing to make the implementor go through incredible gyrations in order
to make things slightly more uniform or useful at the user level.  This
has generally been accepted since, in many cases, this implementation
effort only had to be done once, in some public-domain implementaiton,
and all the others could then just copy the solution.  It hasn't always
worked that way, but that was the motivation for letting certain
hard-to-implement things into the language.

This macro-expansion business is not just a one-shot implementation
problem, however.  It is a rich source of bugs whose flow has shown no
sign of diminishing over time.  It affects not just the hard-core
implementors, but anyone who wants to write macros or other source-level
tranformation or analysis tools.  Not many people working at user level
understand everything you need to understand in order to do this right.
I'm not even 100% certain myself that a correct implementation is
possible.  We keep finding subtle problems.

In addition to the problem of recurring bugs, it is clear that this is a
major contributor to poor performance in Common Lisp interpreters.

Given these problems, I think that we should only keep this mechanism if
people come up with important, non-imaginary uses for it that cannot
easily be done any other way.  It seems a shame to keep such an evil
machanism in the language just because people can think up some clever
ways of using it.

-- Scott

∂05-May-85  0953	FAHLMAN@CMU-CS-C.ARPA 	macr --> declares
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 May 85  09:53:21 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 5 May 85 12:53:23-EDT
Date: Sun, 5 May 1985  12:53 EDT
Message-ID: <FAHLMAN.12108615826.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: macr --> declares


Oops, looks like I'm confused again (with a little help from the
manual).  There it is, right there on page 156: a type proclamation, big
as life.  The text on page 158 describing the TYPE declaration specifier
seems to deny that such a thing is possible, since it says that this
specifier applies only to variable BINDINGS, but I think we ought to go
with page 156, since (as I was just arguing) this mechanism is clearly
useful.

I believe that our current Slisp compiler, and probably several
compilers derived from it, do not currently do anything with TYPE
proclamations, but it's a five-minute change to add this (I think).  In
fact, type-restricted global specials were in there at one time, but
were ripped out when PROCLAIM came along.

-- Scott

∂05-May-85  1036	fateman%ucbdali@Berkeley 	mysterious declarations off in left field   
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 5 May 85  10:36:43 PDT
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.46)
	id AA15145; Sun, 5 May 85 10:35:39 pdt
Received: by ucbdali.ARPA (4.24/4.46)
	id AA26300; Sun, 5 May 85 10:37:51 pdt
Date: Sun, 5 May 85 10:37:51 pdt
From: fateman%ucbdali@Berkeley (Richard Fateman)
Message-Id: <8505051737.AA26300@ucbdali.ARPA>
To: Fahlman@CMU-CS-C.ARPA, vanroggen@DEC-HUDSON.ARPA
Subject: mysterious declarations off in left field
Cc: common-lisp@SU-AI.ARPA

Don't packages offer an alternative way of scoping declarations?

∂05-May-85  1112	FAHLMAN@CMU-CS-C.ARPA 	mysterious declarations off in left field 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 May 85  11:12:26 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 5 May 85 14:12:19-EDT
Date: Sun, 5 May 1985  14:12 EDT
Message-ID: <FAHLMAN.12108630198.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   fateman%ucbdali@λBerkeley (Richard Fateman)λ
Cc:   common-lisp@SU-AI.ARPA
Subject: mysterious declarations off in left field
In-reply-to: Msg of 5 May 1985  13:37-EDT from fateman%ucbdali at Berkeley (Richard Fateman)


    Don't packages offer an alternative way of scoping declarations?

Sure, but packages normally function at a very large grain size.
Sometimes you want to add something to a package without having to scan
the whole package definition to ensure that some fool has not declared X
to be a quadruple-float.  If I bind a lexical X, that's my X and I'm not
interested in anyone else's views about what type X's in general should
be.

-- Scott

∂05-May-85  1633	KMP@SCRC-STONY-BROOK.ARPA 	mysterious declarations off in left field  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 5 May 85  16:33:05 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 230444; Sun 5-May-85 19:31:32-EDT
Date: Sun, 5 May 85 19:30 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: mysterious declarations off in left field
To: Fahlman@CMU-CS-C.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12108630198.BABYL@CMU-CS-C.ARPA>
Message-ID: <850505193039.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Sun, 5 May 1985  14:12 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

	Don't packages offer an alternative way of scoping declarations?

    Sure, but packages normally function at a very large grain size.
    Sometimes you want to add something to a package without having to scan
    the whole package definition to ensure that some fool has not declared X
    to be a quadruple-float.

Or SPECIAL! I've already had problems in Macsyma source code with closures
that didn't "close" because someone decided STRING should be a special variable.
I guess you can imagine how that would be a pretty high-probability variable
name and a poor choice of special name ... Consider too that names like
LIST, STRING, etc. are not likely to be private -- nearly everyone is going
to inherit them from GLOBAL -- so the first time anyone in any "package"
declares one of them to be special, it screws everyone else who tries to do
compilations in that environment.

    If I bind a lexical X, that's my X and I'm not interested in anyone 
    else's views about what type X's in general should be.

Indeed.

Actually, I wonder if we shouldn't have said that type proclamations
should pertain only to special variables. eg,

 (PROCLAIM '(TYPE FLOAT TOLERANCE))

might have only applied to special occurrences of TOLERANCE. This would
mean that people using variables lexically in other modules would be far
less likely to find irrelevant declarations affecting them...

In cases where people wanted to make assertions about lexical variables,
they should perhaps have to scope such declarations lexically.

Although obviously such a change is somewhat incompatible, we might consider
it (or something like it) for the next round of revisions. (An alternate
approach which would achieve the same end would be to introduce a new
declaration operator which had the property of applying only to special 
occurrences so that people could choose which style they wanted.)

Of course this doesn't solve the problem I alluded to earlier of having
people declare things special behind my back...

∂05-May-85  1739	FAHLMAN@CMU-CS-C.ARPA 	mysterious declarations off in left field 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 May 85  17:39:26 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 5 May 85 20:38:55-EDT
Date: Sun, 5 May 1985  20:38 EDT
Message-ID: <FAHLMAN.12108700574.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc:   Common-Lisp@SU-AI.ARPA
Subject: mysterious declarations off in left field
In-reply-to: Msg of 5 May 1985  19:30-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>


    Or SPECIAL! I've already had problems in Macsyma source code with closures
    that didn't "close" because someone decided STRING should be a special variable.

Well, in any future MACSYMA, that special would be named *STRING* and
would therefore be harmless, assuming that the author of the code
follows the suggested conventions.  Quick conversions of old code are
unlikely to observe such restrictions, however, and for compatibility
reasons we stopped short of actually requiring specials to have funny
names or funny syntax around them.


    Actually, I wonder if we shouldn't have said that type proclamations
    should pertain only to special variables. eg,

     (PROCLAIM '(TYPE FLOAT TOLERANCE))

    might have only applied to special occurrences of TOLERANCE. This would
    mean that people using variables lexically in other modules would be far
    less likely to find irrelevant declarations affecting them...

I think we did say that.  The description of (PROCLAIM '(TYPE ...)) on
page 156 says that "any variable names mentioned are assumed to refer to
the dynamic values of the variable.  So a lexical binding of TOLERANCE
would not inherit this type restriction.

-- Scott

∂05-May-85  1742	SOLEY@MIT-MC 	Misfeature: macros expanding into declarations
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85  17:42:18 PDT
Date: Sun,  5 May 85 20:42:51 EST
From: Richard Mark Soley <SOLEY@MIT-MC>
Subject:  Misfeature: macros expanding into declarations
To: TIM@MIT-MC
cc: common-lisp@SU-AI, Fahlman@CMU-CS-C, RAM@CMU-CS-C,
    isrlist@GYRE, sgr@SCRC-STONY-BROOK
In-reply-to: Msg of Sat  4 May 85 18:26:24 EST from Tim McNerney <TIM>
Message-ID: <[MIT-MC].486343.850505.SOLEY>

    Date: Sat,  4 May 85 18:26:24 EST
    From: Tim McNerney <TIM>
    To:   Fahlman at CMU-CS-C
    cc:   TIM, common-lisp at SU-AI, RAM at CMU-CS-C
    Re:   Misfeature: macros expanding into declarations

        Date: Sat, 4 May 1985  07:36 EDT
        From: Rob MacLachlan <RAM at CMU-CS-C.ARPA>

            The Common Lisp feature of allowing a macro to expand into
        declarations ought to be flushed; it complicates much code while
        giving no useful return.

    Although this "misfeature" makes life much harder on the Lisp
    implementor and the macro writer, its semantics are not
    without utility.  Let me illustate this with a couple of simple examples:

Implementor, shmimplementor!  I don't think we're trying to
optomize things for the implementor, but CERTAINLY we care about
the macro writer, 'cause that's EVERYBODY!  One thing this
feature overlooks is the (admittedly bad) behavior of some macro
writers that write overly-circular code, in which too-early
expansion of macros kills the program.  We've all seen the
garbage codes that must be loaded interpreted first and THEN
compiled; I've ported a couple of systems that depended on this
rubbish and had troubles because of the early macro expansion
(which I eventually had to turn off).  I'll send anyone who cares
my wonderful Symbolics Common Lisp function
SI:BREAK-THE-SYSTEM-FOR-THE-SAKE-OF-NISP.

Anyway, at LEAST if we're going to continue to have this feature,
there must be some flag that is set when we're doing "early"
macro expansion so that the macro writer can tell how to expand,
i.e., *EXPANDING-FOR-DECLARATIONS*.

	-- Richard Soley

∂05-May-85  1826	REM@IMSSS 	Restrictions on what macros may call, to avoid needing to preload file    
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-May-05 17:26:23 PST (=GMT-8hr)
Date: 1985 May 05 17:24:22 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132157012100.G0353
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To:Common-LISP@SU-AI.ARPA
Subject:Restrictions on what macros may call, to avoid needing to preload file
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up)

Today somebody mentionned the problem of having to preload a file of
macros interpreted (in the compiler environment) before being able to
compile that same file, because of the macros needing themselves.

I encountered a more subtle problem which likewise requires preloading
the file of macros. In my case I was being careful not to have a macro
depend on itself, but it did depend on EXPRs in the same file. Loading
the macro interpreted was fine, because first the macro and all needed
EXPRs were loaded, and then any use of the macro occurred, so at that
point everything needed to expand the macro-form was available. But
when compiling, only macros are loaded into the compiler environment,
EXPRs are merely compiled and written to output, not also loaded. Thus
when it came time to compile a function which contained the
macro-form, only the toplevel macro-expander, not the EXPRs called by
the macro-expander, were available. I found I had to pre-load the file
interpreted, then compile it. But then every time a macro was compiled
the second time around the compiler complained about duplicate macro
definitions. (This is with PSL, but the same general problem would
probably happen with any LISP.)

I'm on the verge of rewriting all my macros that have subfunctions to
avoid subfunctions entirely, hacking the same effect by generating
forms that contain sub-macros within them, thus the calling of
sub-expanders happens via the macro mechanism after the toplevel
macro-expander has returned a form to re-expand, rather than from
within the body of the toplevel macro-expander, and the sub-expanders
are all macros instead of EXPRs and thus automatically loaded into the
compiler environment without needing to be pre-loaded interpreted. Is
this change the best approach to avoid compiler hassles, or does CL
provide a way to assure that certain EXPRs will both be compiled to
the output file and loaded into the compiler environment so that one
wouldn't have to do my proposed change?

∂05-May-85  1837	MLY@MIT-MC 	Misfeature: macros expanding into declarations  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85  18:37:15 PDT
Date: Sun,  5 May 85 21:37:38 EST
From: Richard Mlynarik <MLY@MIT-MC>
Subject:  Misfeature: macros expanding into declarations
To: SOLEY@MIT-MC, common-lisp@SU-AI
Message-ID: <[MIT-MC].486426.850505.MLY>

[with additional comments by gsb@mc]

    Date: Sun,  5 May 85 20:42:51 EST
    From: Richard Mark Soley <SOLEY@MIT-MC>

        Date: Sat,  4 May 85 18:26:24 EST
        From: Tim McNerney <TIM>

            Date: Sat, 4 May 1985  07:36 EDT
            From: Rob MacLachlan <RAM at CMU-CS-C.ARPA>

                The Common Lisp feature of allowing a macro to expand into
            declarations ought to be flushed; it complicates much code while
            giving no useful return.

It isn't that hard. It has at least some utility. I did it quite some
time ago when this whole mess originally came up n months ago (and
implemented the DOCUMENTATION declaration at the same time for reasons
which were discussed then).

Let's not rehash things discussed before, which is where the present
discussion seems to be leading.

        Although this "misfeature" makes life much harder on the Lisp
	implementor and the macro writer...
Only the wimpy ones.
[gsb:  I don't actually see how this makes life "much" harder.  The
whole deal of declaration parsing (or separation from the "body") is
enough of a pain, that adding in macroexpansion was fairly trivial.
Of course, NIL has its own set of internal "language tools" which
handle various levels of declaration hacking, but they don't really
amount to all that much.  Obviously what we are lacking in CL are some
additional tools for dealing with declarations, macroexpansion, etc.]

    Anyway, at LEAST if we're going to continue to have this feature,
    there must be some flag that is set when we're doing "early"
    macro expansion so that the macro writer can tell how to expand,
    i.e., *EXPANDING-FOR-DECLARATIONS*.

I don't understand exactly what this means at all.
If the macro expands into "(declare ...)" then it is "exanding for
declarations" as far as I can tell.
[gsb:  i don't understand the point of this either, particularly.  I
can see a potential for lossage when there is pre-parsing and thus
macroexpansion performed at definition time rather than at runtime in
interpreted code.]

What -is- useful for a macro to know is whether it is being expanded
by the compiler or the interpreter or for some other random purpose
(mainly in order to make use of different error-reporting techniques,
particularly those of the compiler) This information is part of the
environment passed to the macroexpansion function and has been in NIL
and the LMIT Lispm software for some time.
[gsb:  NIL uses the environment given to macro functions as a pointer
to more information than just the current set of macro definitions.
For instance, it is used by SETF which keeps separate databases for
runtime and compiletime definitions.  We have a set of utilities for
dealing with this sort of thing trivially, and basically all one has
to do is pass around the macroexpansion-environment to keep the
context straight.]

∂05-May-85  1845	SOLEY@MIT-MC 	Misfeature: macros expanding into declarations
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85  18:44:12 PDT
Date: Sun,  5 May 85 21:44:43 EST
From: Richard Mark Soley <SOLEY@MIT-MC>
Subject:  Misfeature: macros expanding into declarations
To: MLY@MIT-MC
cc: common-lisp@SU-AI
In-reply-to: Msg of Sun  5 May 85 21:37:38 EST from Richard Mlynarik <MLY>
Message-ID: <[MIT-MC].486436.850505.SOLEY>

    Date: Sun,  5 May 85 21:37:38 EST
    From: Richard Mlynarik <MLY>
    To:   SOLEY, common-lisp at SU-AI
    Re:   Misfeature: macros expanding into declarations

    [with additional comments by gsb@mc]

        Date: Sun,  5 May 85 20:42:51 EST
        From: Richard Mark Soley <SOLEY@MIT-MC>

            Date: Sat,  4 May 85 18:26:24 EST
            From: Tim McNerney <TIM>

                Date: Sat, 4 May 1985  07:36 EDT
                From: Rob MacLachlan <RAM at CMU-CS-C.ARPA>

                    The Common Lisp feature of allowing a macro to expand into
                declarations ought to be flushed; it complicates much code while
                giving no useful return.

            Although this "misfeature" makes life much harder on the Lisp
    	implementor and the macro writer...
    Only the wimpy ones.
I agree, and I don't care to heavily support wimpy implementors
(wimplementors?).  My point is that we SHOULD support wimpy macro writers.

        Anyway, at LEAST if we're going to continue to have this feature,
        there must be some flag that is set when we're doing "early"
        macro expansion so that the macro writer can tell how to expand,
        i.e., *EXPANDING-FOR-DECLARATIONS*.

    I don't understand exactly what this means at all.
    If the macro expands into "(declare ...)" then it is "exanding for
    declarations" as far as I can tell.
    [gsb:  i don't understand the point of this either, particularly.  I
    can see a potential for lossage when there is pre-parsing and thus
    macroexpansion performed at definition time rather than at runtime in
    interpreted code.]

Exactly.  The point is, there are macros that don't want to be
expanded at interpreter-load (eval) time [i.e., when the DEFUN is
loaded], but only when the defun is compiled.  REGARDLESS of the
fact that no DECLARE is returned.

    What -is- useful for a macro to know is whether it is being expanded
    by the compiler or the interpreter or for some other random purpose
    (mainly in order to make use of different error-reporting techniques,
    particularly those of the compiler) This information is part of the
    environment passed to the macroexpansion function and has been in NIL
    and the LMIT Lispm software for some time.

Exactly what I was proposing.  But this sucker would have to be
well documented.

	-- Richard

∂05-May-85  1849	SOLEY@MIT-MC 	Restrictions on what macros may call, to avoid needing to preload file 
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85  18:49:10 PDT
Date: Sun,  5 May 85 21:48:38 EST
From: Richard Mark Soley <SOLEY@MIT-MC>
Subject:  Restrictions on what macros may call, to avoid needing to preload file
To: REM%IMSSS@SU-SCORE
cc: Common-LISP@SU-AI
In-reply-to: Msg of 1985 May 05 17:24:22 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.SU.EDU>
Message-ID: <[MIT-MC].486449.850505.SOLEY>

    Date: 1985 May 05 17:24:22 PST (=GMT-8hr)
    From: Robert Elton Maas <REM at IMSSS.SU.EDU>
    Sender: REM%IMSSS at SU-SCORE.ARPA (for undeliverable-mail notifications)
    Reply-To: REM%IMSSS at SU-SCORE.ARPA (temporary until nameservers up)
    To:   Common-LISP at SU-AI.ARPA
    Re:   Restrictions on what macros may call, to avoid needing to preload file

    Today somebody mentionned the problem of having to preload a file of
    macros interpreted (in the compiler environment) before being able to
    compile that same file, because of the macros needing themselves.

    I encountered a more subtle problem which likewise requires preloading
    the file of macros. In my case I was being careful not to have a macro
    depend on itself, but it did depend on EXPRs in the same file. . . .
    EXPRs are merely compiled and written to output, not also loaded. . .

    I'm on the verge of rewriting all my macros that have subfunctions to
    avoid subfunctions entirely, . . .

What's wrong with

(defmacro burble (blah ...) (burble-internal blah ...))

(EVAL-WHEN (EVAL COMPILE LOAD)
(defun burble-internal ...)
)

I use it all the time for exactly the problem you mentioned.

	-- Richard

∂05-May-85  1948	FAHLMAN@CMU-CS-C.ARPA 	Misfeature: macros expanding into declarations 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 May 85  19:48:27 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 5 May 85 22:48:23-EDT
Date: Sun, 5 May 1985  22:48 EDT
Message-ID: <FAHLMAN.12108724147.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Richard Mlynarik <MLY@MIT-MC.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Misfeature: macros expanding into declarations


It is probably not worthwhile to argue over whether the macro expansion
misfeature makes life MUCH harder or just somewhat harder for
implementors and macro-writers, and how kind we want to be to "wimpy"
implementors.  I am curious to find out if the people who think this is
not very hard have really handled the problem correctly; after several
iterations on the Spice Lisp interpreter and assorted macros, we've
still got some problems, so it doesn't look easy to us.

The fact remains that this misfeature slows down the interpreter and it
has been the source of a steady stream of bugs.  The people responsible
for these bugs include assorted users trying to write macros and some
fairly experienced Common Lisp implementors (including me).  Given that,
I still think that if nobody comes forward with a better argument for
this stuff than the examples we've seen so far, it should be flushed.
To let something this hairy into the language just because it is "not
without some utility" was a serious mistake, and one that we can correct
now with very little impact on existing code.

-- Scott

∂05-May-85  2001	GSB@MIT-MC 	(setf (apply #'foo ...) ...)
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85  20:01:11 PDT
Date: Sun,  5 May 85 23:01:39 EST
From: Glenn S. Burke <GSB@MIT-MC>
Subject: (setf (apply #'foo ...) ...)
To: HEDRICK@RUTGERS
cc: common-lisp@SU-AI
Message-ID: <[MIT-MC].486573.850505.GSB>

[oohhh, unbalanced parentheses hurt my eyes!!!   Was that message complete?]

What you say is true, but...  The primary utility of SETF of APPLY is
with those things like AREF which take a variable number of arguments;
as a result, the inversion functions for them typically take the value
first rather than last, e.g.
    (SETF (AREF a i j k ...) v) ==> (ASET v a i j k ...)
so you sort of get stuck with having to do the LET-binding hair anyway.

I don't know what your SETF code is like.  NIL uses a SETF i wrote
which utilizes a slightly hacked version of the moon/bawden code
analysis and variable-substitution stuff.  My experience is that it
does sufficiently well to rarely produce completely superfluous
bindings, and the rest are usually necessary or worthwhile.  Should i
take it that your setf makes no use of code analysis/simplification
stuff?

∂05-May-85  2252	HEDRICK@RUTGERS.ARPA 	Re: (setf (apply #'foo ...) ...) 
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 5 May 85  22:51:54 PDT
Date: 6 May 85 01:52:04 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: (setf (apply #'foo ...) ...)
To: GSB@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message from "Glenn S. Burke <GSB@MIT-MC>" of 6 May 85 00:01:39 EDT

We use the Spice Lisp SETF.
-------

∂06-May-85  0834	gls%AQUINAS@THINK.ARPA 	SETF of APPLY   
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 6 May 85  08:34:41 PDT
Received: by THINK.ARPA with CHAOS id AA14159; Mon, 6 May 85 11:33:39 edt
Date: Monday, 6 May 1985, 11:33-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: SETF of APPLY
To: common-lisp@sail
Cc: gls%AQUINAS@THINK.ARPA
Message-Id: <850506113354.1.GLS@DESIDERIUS.THINK>

Hedrick is quite correct that there is a glaring inconsistency
in what the manual says about SETF of APPLY.  I think that what it
says ought to be approximately the truth, but it needs to be hedged
with something about the need to use LET to get the evaluation order
straight.  It is of course precisely to avoid such messy details
that SETF is a canned primitive in the first place.

What would you think of the more complex strategy outlined below
as a replacement for some of the text on page 96?



The SETF method for the function <name> must be such that the
expansion of

(SETF (<name> <z1> <z2> ... <zn> <zrest>) <z0>)

uses the form <zrest> (or the generated variable that fronts for it)
only as the last argument in some number of function calls

(<any-function> <q1> ... <qn> <zrest>)

Every such function call in the expansion is altered to be

(APPLY #'<any-function> <q1> ... <qn> <zrest>)


For example, suppose that (SETF (AREF FOO (P) (Q) (R)) X) were to expand to

(LET* ((#:G0018 FOO)
       (#:G0019 (P))
       (#:G0020 (Q))
       (#:G0021 (R)))
  (ASET X #:G0018 #:G0019 #:G0020 #:G0021))

Then the expansion of (SETF (APPLY #'AREF FOO (P) (Q) (R)) X) would be

(LET* ((#:G0018 FOO)
       (#:G0019 (P))
       (#:G0020 (Q))
       (#:G0021 (R)))
  (APPLY #'ASET X #:G0018 #:G0019 #:G0020 #:G0021))

--Guy

∂06-May-85  0845	gls%AQUINAS@THINK.ARPA 	Macros -> declarations    
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 6 May 85  08:45:14 PDT
Received: by THINK.ARPA with CHAOS id AA14271; Mon, 6 May 85 11:43:25 edt
Date: Monday, 6 May 1985, 11:43-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Macros -> declarations
To: common-lisp@sail
Cc: gls%AQUINAS@THINK.ARPA
Message-Id: <850506114342.2.GLS@DESIDERIUS.THINK>

I would be not at all unhappy if this feature were to go away.
I agree that Scott's assessment that it is unlikely that any
existing code (outside of diagnostic tests for this very feature)
would be harmed.

I am persuaded not at all by the argument that it is hard to implement.
I am mildly swayed by the efficiency considerations for the interpreter.
The convincing point to me, however, is that the facility is likely
to confuse macro-writers (who do, indeed, frequently find it necessary
to find the division point between declarations/documentation and body).

As a proposal separate from the question of eliminating the expansion
of macros into declarations, I suggest the following primitive
for consideration:

PARSE-BODY list

The list is treated as a body (a list of forms) that may have declarations
and a documentation string at its head.

Three values are returned.  The first is some tail of the list,
the executable part of the body.  The second value is a list
of declarations (lists whose car is DECLARE) at the head of the body.
The third value is the documentation string, or NIL if there was
no documentation string.

--Guy

∂06-May-85  0854	gls%AQUINAS@THINK.ARPA 	PROCLAIM and type declarations 
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 6 May 85  08:54:39 PDT
Received: by THINK.ARPA with CHAOS id AA14309; Mon, 6 May 85 11:47:28 edt
Date: Monday, 6 May 1985, 11:47-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: PROCLAIM and type declarations
To: common-lisp@sail
Cc: gls%AQUINAS@THINK.ARPA
Message-Id: <850506114744.3.GLS@DESIDERIUS.THINK>

I believe that the sentences from page 156 about PROCLAIM covers
the case currently under debate:

  Any variable names mentioned are assumed to refer to the dynamic values
  of the variable.... Similarly, any function names mentioned are assumed
  to refer to the global function definition.

In a later paragraph it is noted that PROCLAIM of SPECIAL is given an
unusual interpretation.

--Guy

∂06-May-85  0947	vanroggen@DEC-HUDSON 	macros --> declarations
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 6 May 85  09:47:30 PDT
Date: Mon, 06 May 85 12:48:36 EDT
From: vanroggen@DEC-HUDSON
Subject: macros --> declarations
To: ram@cmu-cs-c
Cc: common-lisp@su-ai

I think others have provided examples of their usefulness. However,
usefulness is not a sufficient criterion for inclusion in the language
(fortunately!). I don't understand why you ask me to provide an example
when I'd also like to have the feature removed.
			---Walter

∂06-May-85  0953	vanroggen@DEC-HUDSON 	local declarations
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 6 May 85  09:51:59 PDT
Date: Mon, 06 May 85 12:53:00 EDT
From: vanroggen@DEC-HUDSON
Subject: local declarations
To: fahlman@cmu-cs-c
Cc: common-lisp@su-ai

What I was complaining about was the implication in the manual that
the following code was "not meaningful":
(TYPECASE X
  (SIMPLE-STRING
    (LOCALLY (DECLARE (SIMPLE-STRING X))
      ...))
  ...)
This local declaration isn't "off in left field somehwere"; it's
quite lexical. (I'm assuming X isn't SPECIAL; that problem has
been aired a number of times now.)
			---Walter

∂06-May-85  1043	vanroggen@DEC-HUDSON 	SETF APPLY ...    
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 6 May 85  10:43:01 PDT
Date: Mon, 06 May 85 13:44:06 EDT
From: vanroggen@DEC-HUDSON
Subject: SETF APPLY ...
To: hedrick@rutgers
Cc: common-lisp@su-ai

BIT and SBIT are two other Common Lisp functions which should work
inside SETF of APPLY, but they're the only other ones.
It seems to me that we could have both the newvalue passed as the
last arg of the setting function and the ability to do SETF of
APPLY if we would admit to a function, that I'll call APPLY-BUT-LAST,
that's just like APPLY, except that it's the next-to-last argument
that must be a list, and the last argument is just passed as the
last argument to the applied function. This won't help with
multiple-value-setfs (which I think don't belong in Common Lisp),
but it will allow SETF of APPLY of other named SETFable forms.
			---Walter

∂06-May-85  1053	WHOLEY@CMU-CS-C.ARPA 	(setf (apply #'foo ...) ...)
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 May 85  10:52:23 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Mon 6 May 85 13:52:00-EDT
Date: Mon, 6 May 1985  13:51 EDT
Message-ID: <WHOLEY.12108888638.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To:   Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Cc:   common-lisp@SU-AI.ARPA, GSB@MIT-MC.ARPA
Subject: (setf (apply #'foo ...) ...)

Just for the record (and to maybe make things epsilon easier for other
implementors), (setf (apply #'aref ...) ...) in Spice Lisp turns into a call to
Lisp::%Aset, which takes its arguments in the new-element-is-last order,
instead of the Zetalisp order.  That turned out to be just as easy for us.
Also, the Let bindings that Setf produces that it can't prove can go away are
examined by a general-purpose "Let optimizer" in our compiler, which does a
more thorough job of removing spurious bindings.

--Skef

∂06-May-85  1148	FAHLMAN@CMU-CS-C.ARPA 	local declarations    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 May 85  11:48:05 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 6 May 85 14:48:02-EDT
Date: Mon, 6 May 1985  14:47 EDT
Message-ID: <FAHLMAN.12108898844.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   vanroggen@DEC-HUDSON.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: local declarations
In-reply-to: Msg of 6 May 1985  12:53-EDT from vanroggen at DEC-HUDSON


Ah, I misunderstood what you were suggesting.  Yes, to somehow be able
to specify the type of a lexical variable within a subset of that
variable's scope is indeed something that would be useful (though doing
one quick copy into a type-restricted LET variable doesn't seem too
bad).

It also was not totally clear whether you were areguing for keeping
themacro-to-declaration lossage or flushing it.  Glad to hear you're on
the side of sanity.

-- Scott

∂06-May-85  1159	FAHLMAN@CMU-CS-C.ARPA 	SETF of APPLY    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 May 85  11:58:50 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 6 May 85 14:58:12-EDT
Date: Mon, 6 May 1985  14:58 EDT
Message-ID: <FAHLMAN.12108900686.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Guy Steele <gls%AQUINAS@THINK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: SETF of APPLY
In-reply-to: Msg of 6 May 1985 11:33-EDT from Guy Steele <gls%AQUINAS at THINK.ARPA>


I like Guy's new formulation for the SETF of APPLY stuff.

One other thing that should be said is that SETF of APPLY of AREF is
required to work, regardless of how the AREF-setting function is
implemented internally.  The main object of this stuff is to get this
one case to work, and yet an implementation is technically permitted to
implement the AREF setter in some way that does not fit into the
framework described.

-- Scott

∂06-May-85  1235	Moon@SCRC-YUKON.ARPA 	SETF of APPLY
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 6 May 85  12:35:16 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 123937; Mon 6-May-85 15:35:04-EDT
Date: Mon, 6 May 85 15:34 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: SETF of APPLY
To: Guy Steele <gls%AQUINAS@THINK.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850506113354.1.GLS@DESIDERIUS.THINK>
Message-ID: <850506153459.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

I agree with your proposed revised description of SETF of APPLY.  The specific
code in our implementation of APPLY's SETF-method follows; it may be useful
in constructing the English description.  This is not the whole SETF-method,
just the relevant code fragment.

(DEFINE-SETF-METHOD APPLY (FUNCTION &REST ARGS)
  ....
  (SETQ FUNCTION (SECOND FUNCTION))
  (MULTIPLE-VALUE-BIND (VARS VALS STORE-VARS STORE-FORM ACCESS-FORM)
      (GET-SETF-METHOD-MULTIPLE-VALUE (CONS FUNCTION ARGS))
    (LET ((LIST-VAR (LOOP FOR VAR IN VARS AND VAL IN VALS
			  WHEN (EQ VAL (CAR (LAST ARGS))) RETURN VAR)))
      (OR (AND LIST-VAR
	       (EQ (CAR (LAST ACCESS-FORM)) LIST-VAR)
	       (EQ (CAR (LAST STORE-FORM)) LIST-VAR))
	  (ERROR "APPLY of ~S not understood as a generalized variable" FUNCTION))


While SETF of APPLY of AREF could be implemented some other way, not involving
the last argument to the original form remaining last in the access-form and
store-form, I think it is necessary for SETF of APPLY of a user-defined function
to work this way.

This is all certainly ugly, but I still think the alternative (a separate
DEFSETF system for functions seen inside APPLY) would be a lot worse.

∂06-May-85  1241	OLDMAN@USC-ISI.ARPA 	defconstant vs. lexical variables 
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 6 May 85  12:41:00 PDT
Date: 6 May 1985 15:40-EDT
Sender: OLDMAN@USC-ISI.ARPA
Subject: defconstant vs. lexical variables
From: OLDMAN@USC-ISI.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA] 6-May-85 15:40:52.OLDMAN>

Page 69 of the CLM states:

"Once a name has been declared by defconstant to be constant, any
further assignment to or binding of that special variable is an
error.  ...  A compiler may also choose to issue warnings about
bindings of the lexical variable of the same name."

Question: How can I make a lexical binding of the thing if it's
implicitly proclaimed special by the defconstant?

Alternate question: Why don't we have a way of declaring
something locally lexical?

--Dan Oldman {Data General}

∂06-May-85  1347	gls%AQUINAS@THINK.ARPA 	local declarations   
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 6 May 85  13:47:06 PDT
Received: by THINK.ARPA with CHAOS id AA01781; Mon, 6 May 85 16:45:33 edt
Date: Monday, 6 May 1985, 16:45-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: local declarations
To: vanroggen@DEC-HUDSON@THINK.ARPA, fahlman@cmu-cs-c
Cc: common-lisp@su-ai, gls%AQUINAS@THINK.ARPA
In-Reply-To: The message of 6 May 85 12:53-EDT from vanroggen at DEC-HUDSON at think
Message-Id: <850506164554.4.GLS@DESIDERIUS.THINK>

    Date: Mon, 06 May 85 12:53:00 EDT
    From: vanroggen@DEC-HUDSON@think

    What I was complaining about was the implication in the manual that
    the following code was "not meaningful":
    (TYPECASE X
      (SIMPLE-STRING
	(LOCALLY (DECLARE (SIMPLE-STRING X))
	  ...))
      ...)
    This local declaration isn't "off in left field somehwere"; it's
    quite lexical. (I'm assuming X isn't SPECIAL; that problem has
    been aired a number of times now.)
			    ---Walter


"Any REALLY good compiler" could figure this case out without needing
the explicit declaration.  (But of course it can't figure out general
cases.)

You can get around this somewhat either by using LET or by using THE:

	(TYPECASE X
	  (SIMPLE-STRING
	    ... (CHAR (THE SIMPLE-STRING X) 43) ...)
	  ...)

For true hair, use MACROLET:

	(TYPECASE X
	  (SIMPLE-STRING
	     (MACROLET ((X () '(THE SIMPLE-STRING X)))
      	        ... (CHAR (X) 43) ...))
	  ...)

[Yuk.]

--Guy

∂06-May-85  1444	Moon@SCRC-QUABBIN.ARPA 	Macros -> declarations    
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 6 May 85  14:43:20 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 161094; Mon 6-May-85 17:40:21-EDT
Date: Mon, 6 May 85 17:43 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Macros -> declarations
To: Guy Steele <gls%AQUINAS@THINK.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850506114342.2.GLS@DESIDERIUS.THINK>
Message-ID: <850506174305.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Monday, 6 May 1985, 11:43-EDT
    From: Guy Steele <gls%AQUINAS@THINK.ARPA>

    I would be not at all unhappy if this feature were to go away.
    I agree that Scott's assessment that it is unlikely that any
    existing code (outside of diagnostic tests for this very feature)
    would be harmed.

I have no opinion one way or the other about whether the feature of macros
expanding into DECLARE forms should be retained or flushed.  Maybe we'll
hear from KMP what he had in mind when he suggested it, back in 1982 or
thereabouts, before we make a decision.

I would like to point out, though, that anyone claiming that no one uses
the feature is on very thin ice.  A hell of a lot of copies of Common
Lisp: The Language have been sold.  I have heard of more than one
implementation existing "off in left field".  My experience has been
that users will often use features that you wouldn't have expected them
to use, or even discover, and then will get mad when you remove the
feature.  The worst case of this, of course, is when the user thought it
was a feature and the implementor thought it was a bug.

    I am persuaded not at all by the argument that it is hard to implement.
    I am mildly swayed by the efficiency considerations for the interpreter.

I found it easy enough to implement an interpreter that handles these efficiently.
It pre-processes certain special forms the first time it encounters them.  No
big deal.

    The convincing point to me, however, is that the facility is likely
    to confuse macro-writers (who do, indeed, frequently find it necessary
    to find the division point between declarations/documentation and body).

    As a proposal separate from the question of eliminating the expansion
    of macros into declarations, I suggest the following primitive
    for consideration:

    PARSE-BODY list

    The list is treated as a body (a list of forms) that may have declarations
    and a documentation string at its head.

    Three values are returned.  The first is some tail of the list,
    the executable part of the body.  The second value is a list
    of declarations (lists whose car is DECLARE) at the head of the body.
    The third value is the documentation string, or NIL if there was
    no documentation string.

This is a good suggestion.  We already have this, but haven't documented it
pending standardization or other reasons why we might want to change it.  Our
implementation of this raises some points:

 - It needs to take a lexical environment argument so it can expand macros
   so it can look for declarations.

 - It needs to take an argument that tells it whether documentation strings
   are allowed in this kind of body.

 - It's convenient for the caller if PARSE-BODY peels off the DECLARE's and
   simply returns a one-level list of declarations.  The caller can cons
   DECLARE back onto the front of this list if desired.

 - For our system's applications, we found it convenient to split the
   declarations into four kinds returned as separate lists.  I don't
   know that it would make sense to standardize this in Common Lisp,
   though.  The four kinds were SPECIAL declarations, type declarations,
   declarations that need to be saved until run time for the Debugger
   (not a portable concept), and all others.

∂06-May-85  1642	KMP@SCRC-STONY-BROOK.ARPA 	Macros -> declarations 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 6 May 85  16:42:24 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 231404; Mon 6-May-85 19:38:28-EDT
Date: Mon, 6 May 85 19:39 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Macros -> declarations
To: Moon@SCRC-STONY-BROOK.ARPA, gls%AQUINAS@THINK.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850506174305.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <850506193941.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Mon, 6 May 85 17:43 EDT
    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>

	Date: Monday, 6 May 1985, 11:43-EDT
	From: Guy Steele <gls%AQUINAS@THINK.ARPA>

	I would be not at all unhappy if this feature were to go away...

    I have no opinion one way or the other about whether the feature of macros
    expanding into DECLARE forms should be retained or flushed.  Maybe we'll
    hear from KMP what he had in mind when he suggested it, back in 1982 or
    thereabouts, before we make a decision. ...

Thanks for reminding me about this. Indeed, I did have reasons other than the
ones I've seen mentioned thus far. I think that at least one possible use I
had in mind was for allowing macros so that you could create alternate syntax 
for declarations. eg, suppose a BIT-REGISTER was some abstraction on special 
variables that hold fixnums. Then

 (DEFMACRO DECLARE-BIT-REGISTER (&REST NAMES)
   `(DECLARE (SPECIAL ,@NAMES)
             (FIXNUM  ,@NAMES)))
   
might be something you could imagine writing and

 (DEFUN FROB (REG)
   (DECLARE-BIT-REGISTER REG)
   (FROB-1))

 (DEFUN FROB-1 ()
   (DECLARE-BIT-REGISTER REG)
   ...)

might be a sample usage. Note that in this situation it is not the case that
DEFVAR or the like is called for, since we're only communicating between two
functions. Also, one may not want to write:

 (DEFUN FROB (REG)
   (DECLARE (SPECIAL REG) (FIXNUM REG))
   (FROB-1))

 (DEFUN FROB-1 ()
   (DECLARE (SPECIAL REG) (FIXNUM REG))
   ...)

because that loses an abstraction level.

By the way, abstractions like my DECLARE-BIT-REGISTER do not provide "room for"
other declarations. Eg, consider:

 (DEFUN FOO (REG)
   (DECLARE-BIT-REGISTER REG)
   (DECLARE (SPECIAL *FOO*))
   ...)

There is no way (without violating the BIT-REGISTER abstraction) to not write
two leading DECLAREs.

∂06-May-85  1721	WHOLEY@CMU-CS-C.ARPA 	Macros -> declarations 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 May 85  17:21:06 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Mon 6 May 85 20:20:52-EDT
Date: Mon, 6 May 1985  20:20 EDT
Message-ID: <WHOLEY.12108959433.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To:   Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA, gls%AQUINAS@THINK.ARPA,
      Moon@SCRC-STONY-BROOK.ARPA
Subject: Macros -> declarations
In-reply-to: Msg of 6 May 1985  19:39-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>

    Date: Monday, 6 May 1985  19:39-EDT
    From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
    Re:   Macros -> declarations

    By the way, abstractions like my DECLARE-BIT-REGISTER do not provide "room
    for" other declarations. Eg, consider:

     (DEFUN FOO (REG)
       (DECLARE-BIT-REGISTER REG)
       (DECLARE (SPECIAL *FOO*))
       ...)

    There is no way (without violating the BIT-REGISTER abstraction) to not
    write two leading DECLAREs.

So what's really wanted is a DEFDECLARATION or somesuch that works like DEFTYPE
in defining a macro-like thing that expands into a list of declare forms.
Although a scheme like this wouldn't eliminate the need for a body parser to
"macroexpand" stuff at runtime, it would eliminate the screw that was the last
straw to Rob MacLachlan -- the need for all macro writers to do &environment
hacking whenever parsing bodies.

 (defdeclaration bit-register (&rest guys)
   (mapcan #'(lambda (guy) `((special ,guy) (fixnum ,guy))) guys))

 (defun foo (reg)
   (declare (bit-register reg) (special *foo*))
   ...)

Note that there is no way to scope DEFTYPE's.  With the above suggestion, there
would be no way to scope DEFDECLARATION's either.  An alternate solution, which
requires only a one-word change to the language spec, is to restrict macros
that can expand into declarations to GLOBAL macros.  This solution would handle
all of the imaginative uses for this feature that people here have come up
with, while removing the big ball of hair that makes it hard for users to write
correct macros.

This latter suggestion is ugly, I agree.  A completely separate macro-like
mechanism is provided for types, and happens to prevent the definition of local
types, so why not have a similar mechanism for declarations?

--Skef

∂06-May-85  1744	HEDRICK@RUTGERS.ARPA 	SETF (APPLY  
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 6 May 85  17:44:05 PDT
Date: 6 May 85 20:44:26 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: SETF (APPLY
To: common-lisp@SU-AI.ARPA

The problem with the current definition is that it depends upon the
implementation.  Rather than kludging up the definition more so that
it properly describes hairier implementations of SETF, how about
simply saying that SETF (APPLY must work for AREF, BITS, and SBITS,
if those are the only useful cases.  You might also say that it
is suggested that the implementation be such that this construct
should work for as many additional cases as possible.  But I would
much rather have a specific list of those cases where it is supposed
to work than a description whose interpretation is implementation-
dependent.  Currently, I can claim that I have implemented 
SETF (APPLY correctly, since in my implementation there is no case
where the precondition would apply.  I recently added special-case
code to handle AREF, and if people agree that BITS and SBITS are
also useful, I will add them too.  I will use a strategy similar
to VanRoggen's suggested APPLY-BUT-LAST.
-------

∂06-May-85  1745	KMP@SCRC-STONY-BROOK.ARPA 	Macros -> declarations 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 6 May 85  17:44:51 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 231431; Mon 6-May-85 20:40:24-EDT
Date: Mon, 6 May 85 20:41 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Macros -> declarations
To: Wholey@CMU-CS-C.ARPA, KMP@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA, gls%AQUINAS@THINK.ARPA,
    Moon@SCRC-STONY-BROOK.ARPA
In-Reply-To: <WHOLEY.12108959433.BABYL@CMU-CS-C.ARPA>
Message-ID: <850506204139.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Mon, 6 May 1985  20:20 EDT
    From: Skef Wholey <Wholey@CMU-CS-C.ARPA>

	Date: Monday, 6 May 1985  19:39-EDT
	From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
	Re:   Macros -> declarations

	By the way, abstractions like my DECLARE-BIT-REGISTER do not provide "room
	for" other declarations. Eg, consider:

	 (DEFUN FOO (REG)
	   (DECLARE-BIT-REGISTER REG)
	   (DECLARE (SPECIAL *FOO*))
	   ...)

	There is no way (without violating the BIT-REGISTER abstraction) to not
	write two leading DECLAREs.

    So what's really wanted is a DEFDECLARATION or somesuch that works like DEFTYPE
    in defining a macro-like thing that expands into a list of declare forms.
    Although a scheme like this wouldn't eliminate the need for a body parser to
    "macroexpand" stuff at runtime, it would eliminate the screw that was the last
    straw to Rob MacLachlan -- the need for all macro writers to do &environment
    hacking whenever parsing bodies.

     (defdeclaration bit-register (&rest guys)
       (mapcan #'(lambda (guy) `((special ,guy) (fixnum ,guy))) guys))

     (defun foo (reg)
       (declare (bit-register reg) (special *foo*))
       ...)

    Note that there is no way to scope DEFTYPE's.  With the above suggestion, there
    would be no way to scope DEFDECLARATION's either.  An alternate solution, which
    requires only a one-word change to the language spec, is to restrict macros
    that can expand into declarations to GLOBAL macros.  This solution would handle
    all of the imaginative uses for this feature that people here have come up
    with, while removing the big ball of hair that makes it hard for users to write
    correct macros.

    This latter suggestion is ugly, I agree.  A completely separate macro-like
    mechanism is provided for types, and happens to prevent the definition of local
    types, so why not have a similar mechanism for declarations?

    --Skef

Well, that would certainly help a lot... but I'm not sure it would handle all 
the useful cases.

For example, you couldn't use MACROLET to create a local declaration
type. We'd either need a DECLARATION-LET special form or we'd have to
say that all declaration types have to be global. I'm not taking a stand
on that issue; just pointing it out.

Another odd situation to consider is that you might be working in a package on which 
it was desirable to shadow the symbol DECLARE for some reason. Rather than have
to write (LISP:DECLARE ...) everywhere, you could imagine wanting to do:

(DEFMACRO MY:DECLARE (&REST DECLS)
  `(LISP:DECLARE ,@DECLS))

I don't expect this situation to be common early-on, but if people get into writing
embedded languages as macrofied extensions making heavy use of the package system,
they might well want such a provision ... or possibly something like:

(DEFMACRO MY:DECLARE (&REST DECLS)
  `(LISP:DECLARE ,@(MY:TRANSLATE DECLS)))

It turns out that if anyone ever wants to recycle any of the names CL defines as
usable in declarations (like INTEGER, etc) to mean anything else in an embedded language,
they will need this sort of hook in order to avoid having to provide an intermediate
translator from their language to CL.

I could imagine Macsyma possibly wanting to play games like this if it were ever
really made to run "natively" in Common Lisp ... right now it has a lot of 
intermediate translators that should not really be needed if the macro facility
of the underlying language is appropriately powerful.

By the way, I don't think that the frequency of parsing bodies (as opposed to
just propagating them) is so high as to make it offensive to have to use 
&ENVIRONMENT in those situations.

∂06-May-85  1801	WHOLEY@CMU-CS-C.ARPA 	Macros -> declarations 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 May 85  17:58:29 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Mon 6 May 85 20:58:16-EDT
Date: Mon, 6 May 1985  20:58 EDT
Message-ID: <WHOLEY.12108966237.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To:   Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA, gls%AQUINAS@THINK.ARPA,
      Moon@SCRC-STONY-BROOK.ARPA
Subject: Macros -> declarations
In-reply-to: Msg of 6 May 1985  20:41-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>

    Date: Monday, 6 May 1985  20:41-EDT
    From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
    Re:   Macros -> declarations

    For example, you couldn't use MACROLET to create a local declaration
    type. We'd either need a DECLARATION-LET special form or we'd have to
    say that all declaration types have to be global. I'm not taking a stand
    on that issue; just pointing it out.

Right -- there is no TYPE-LET special form, either, and that no one has missed
it!  (I won't tell them if you don't.)

∂06-May-85  1804	Moon@SCRC-STONY-BROOK.ARPA 	SETF (APPLY 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 6 May 85  18:04:38 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 231446; Mon 6-May-85 21:00:53-EDT
Date: Mon, 6 May 85 21:04 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: SETF (APPLY
To: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 6 May 85 20:44-EDT from Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Message-ID: <850506210428.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 6 May 85 20:44:26 EDT
    From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>

    The problem with the current definition is that it depends upon the
    implementation.  Rather than kludging up the definition more so that
    it properly describes hairier implementations of SETF, how about
    simply saying that SETF (APPLY must work for AREF, BITS, and SBITS,
    if those are the only useful cases.  

Wait a minute.  Those may be the only useful cases among the functions
listed in Common Lisp: The Language, but that doesn't mean that there
aren't user-defined functions that are equally as useful to SETF APPLY.
This is Lisp, the supposedly extensible and consistent language.

∂06-May-85  1830	HEDRICK@RUTGERS.ARPA 	Re: SETF (APPLY   
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 6 May 85  18:28:55 PDT
Date: 6 May 85 21:29:06 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: SETF (APPLY
To: Moon@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message from "David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>" of 6 May 85 21:04:00 EDT

I believe that we have two separate cases, each of which can be
described without implementation-dependent cruft:

(1) builtin SETF things.  In this case there is a finite list, and we
should say which of these forms should work with SETF (APPLY.

(2) user defined SETF's.  I believe that the most common cases
are those where the original language as in the manual works, except
instead of saying that they expand to the form (storefn zi1 .. zm),
say that the expansion is defined by a DEFSETF whose body is
of that form.  (Probably that is what the original author was thinking.)
Again, you may want to suggest that other forms may be supported if
possible, but I believe the definition should be in terms of what
the user writes, not the actual expansion.
-------

∂06-May-85  1857	FAHLMAN@CMU-CS-C.ARPA 	Macros -> declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 May 85  18:57:04 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 6 May 85 21:56:46-EDT
Date: Mon, 6 May 1985  21:56 EDT
Message-ID: <FAHLMAN.12108976886.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Macros -> declarations
In-reply-to: Msg of 6 May 1985  20:41-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>


The business about wanting to be able to shadow LISP:DECLARE seems
pretty weak to me.  It seems reasonable to me that if people want to
redefine the essential structural symbols like DECLARE out from under
Common Lisp, then they should either be willing to say something like
LISP:DECLARE to get the old version or do a source-level transformation
on the surrounding form.  There are a number of other structural
symbols, in addition to DECLARE, that are known to the interpreter, and
we can't very well macroexpand everything in sight in order to see if we
have one of these.

-- Scott

∂07-May-85  1118	BSG@SCRC-RIVERSIDE.ARPA 	Macros -> declarations   
Received: from SCRC-RIVERSIDE.ARPA by SU-AI.ARPA with TCP; 7 May 85  11:17:45 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-RIVERSIDE.ARPA via CHAOS with CHAOS-MAIL id 38048; Tue 7-May-85 08:47:43-EDT
Date: Tue, 7 May 85 08:51 EDT
From: Bernard S. Greenberg <BSG@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Macros -> declarations
To: Fahlman@CMU-CS-C.ARPA, KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12108976886.BABYL@CMU-CS-C.ARPA>
Message-ID: <850507085122.9.BSG@CONCORD.SCRC.Symbolics.COM>

    Date: Mon, 6 May 1985  21:56 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>


    The business about wanting to be able to shadow LISP:DECLARE seems
    pretty weak to me.  
He's hardly shadowing Lisp:declare....
			It seems reasonable to me that if people want to
    redefine the essential structural symbols like DECLARE out from under
    Common Lisp, then they should either be willing to say something like
    LISP:DECLARE to get the old version or do a source-level transformation
    on the surrounding form.  There are a number of other structural
    symbols, in addition to DECLARE, that are known to the interpreter, and
    we can't very well macroexpand everything in sight in order to see if we
    have one of these.

    -- Scott

I don't buy this as a counterargument to what KMP said.  Subsitute "DEFUN"
for "DECLARE" in the above paragraph.    You can only define functions with
DEFUN -- (generic)Lisp provides no other way.  Yet, we have the whole
top-level macro mechanism to allow you to define application-language-embedded
function-definers, calls to whom are expanded at top-level to ultimately
produce DEFUNs.  DECLARE is the only way to declare things lexically.
The same arguments apply.

∂07-May-85  1139	FAHLMAN@CMU-CS-C.ARPA 	Macros -> declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 7 May 85  11:38:56 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 7 May 85 14:08:50-EDT
Date: Tue, 7 May 1985  10:18 EDT
Message-ID: <FAHLMAN.12109112004.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   "Bernard S. Greenberg" <BSG%scrc@MIT-MC.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Macros -> declarations
In-reply-to: Msg of 7 May 1985  08:51-EDT from Bernard S. Greenberg <BSG at STONY-BROOK.SCRC.Symbolics.COM>


    I don't buy this as a counterargument to what KMP said.  Subsitute "DEFUN"
    for "DECLARE" in the above paragraph.    You can only define functions with
    DEFUN -- (generic)Lisp provides no other way.  Yet, we have the whole
    top-level macro mechanism to allow you to define application-language-embedded
    function-definers, calls to whom are expanded at top-level to ultimately
    produce DEFUNs.  DECLARE is the only way to declare things lexically.
    The same arguments apply.

I guess I didn't make myself clear.  I understand that macros are able
to provide suitable disguises for anything that takes the form of a list
to be evaluated, such as DEFUN, and that this is useful in creating
embedded sublanguages with a LIsp-like syntax.  My point was that we do not
have anything like macros for disguising "structural" items that are not
in the form of lists to be evaluated: argument lists, things like
&optional, T and NIL, certain keywords, declarations, components of
declarations, doc strings, and so on.  Various parts of the interpreter
look for such things verbatim, without doing any macro-expansion of
objects or structures that might turn into the item being sought.

That's good for efficiency, particularly in the presence of MACROLET,
and gives the human reader of Lisp code at least a few stable landmarks
to hold on to.  The price is that if you really want to monkey around
with these structural things in an embedded language, you have to
transform the whole surrounding form and not just the item itself.  To
me that seems like a reasonable price for those people who want an
embedded language that departs from Lisp syntax in such a deep way.  If
you get rid of parentheses or prefix notation or argument lists, you'll
have to do a transformation on the whole form anyway; I'm just saying
that we could reasonably consider declarations to be something basic to
the syntax of the language, like argument lists, rather than thinking
of them as a funny kind of body form.  Just because (DECLARE ...) looks
like any old lisp form, that doesn't mean we have to treat it as one.

-- Scott

∂07-May-85  1221	KMP@SCRC-STONY-BROOK.ARPA 	Macros -> declarations 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 7 May 85  12:20:52 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 232005; Tue 7-May-85 15:16:41-EDT
Date: Tue, 7 May 85 15:17 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Macros -> declarations
To: Fahlman@CMU-CS-C.ARPA, BSG@TENEX.SCRC.Symbolics.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12109112004.BABYL@CMU-CS-C.ARPA>
Message-ID: <850507151759.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Tue, 7 May 1985  10:18 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

	Date: Tue, 7 May 85 08:51 EDT
	From: Bernard S. Greenberg <BSG@STONY-BROOK.SCRC.Symbolics.COM>

	I don't buy this as a counterargument to what KMP said.  Subsitute "DEFUN"
	for "DECLARE" in the above paragraph.    You can only define functions with
	DEFUN -- (generic)Lisp provides no other way.  Yet, we have the whole
	top-level macro mechanism to allow you to define application-language-embedded
	function-definers, calls to whom are expanded at top-level to ultimately
	produce DEFUNs.  DECLARE is the only way to declare things lexically.
	The same arguments apply.

    I guess I didn't make myself clear.  I understand that macros are able
    to provide suitable disguises for anything that takes the form of a list
    to be evaluated, such as DEFUN, and that this is useful in creating
    embedded sublanguages with a LIsp-like syntax.  My point was that we do not
    have anything like macros for disguising "structural" items that are not
    in the form of lists to be evaluated: argument lists, things like
    &optional, T and NIL, certain keywords, declarations, components of
    declarations, doc strings, and so on.  Various parts of the interpreter
    look for such things verbatim, without doing any macro-expansion of
    objects or structures that might turn into the item being sought.

I guess the issue is whether you think of DECLARE as "structural". Consider:

(DEFMACRO FROB (WIDGET)
  (COND ((> MOST-NEGATIVE-FIXNUM something)
	 ...expansion that assumes WIDGET was represented as a fixnum...)
	(T
	 ...expansion that assumes WIDGET was represented as a list...)))

(DEFMACRO DECLARE-WIDGET (&REST NAMES)
  `(DECLARE (TYPE ,(IF (> MOST-NEGATIVE-FIXNUM something) 'FIXNUM 'LIST) ,@NAMES)))

(DEFUN FOO (X)
  (DECLARE-WIDGET X)
  ... (FROB X) ...)

Certainly I need as a minimum the ability to do this. It is not reasonable 
(as you seem to be proposing) that I should have to do:

(DEFMACRO DEFINE-WIDGET-OPERATION (NAME BVL &BODY FORMS)
  `(DEFUN FOO ,BVL
     (DECLARE ...hair to parse &WIDGET keywords in BVL 
	         or DECLARE-WIDGET magic at head of FORMS...)
     ,@FORMS))

since it is not compositional -- ie, if I have a similar DEFINE-GIZMO-OPERATION
macro, I cannot easily define something which frobs both gizmos and widgets.
Hence, I claim the declaration is not structural in the sense that, for example,
a COND clause is.

By the way, Macsyma does this sort of thing with read-conditionals because
languages don't allow it the flexibility to do it any other way. I hope I don't
have to explain to you how and why this offends me.

By the way, Skef's proposal (for "declaration macros") handles this problem, too.
I'm just a little skeptical about a special-purpose declaration macro just
for this context. Certainly it is the minimum potentially acceptable position,
since it at least tries to address the issues I'm raising rather than sweeping
them under the rug. I'm a little afriad that next people will want COND macros
and LAMBDA macros (oops, the LispM has them already) and ... but I might yet be
willing to yield to the suggestion of these declaration macros -- I'm still
thinking about it in light of some of the problems I mentioned in my last message.

    That's good for efficiency, particularly in the presence of MACROLET,
    and gives the human reader of Lisp code at least a few stable landmarks
    to hold on to.  The price is that if you really want to monkey around
    with these structural things in an embedded language, you have to
    transform the whole surrounding form and not just the item itself.  To
    me that seems like a reasonable price for those people who want an
    embedded language that departs from Lisp syntax in such a deep way.  If
    you get rid of parentheses or prefix notation or argument lists, you'll
    have to do a transformation on the whole form anyway; I'm just saying
    that we could reasonably consider declarations to be something basic to
    the syntax of the language, like argument lists, rather than thinking
    of them as a funny kind of body form.  Just because (DECLARE ...) looks
    like any old lisp form, that doesn't mean we have to treat it as one.

I just don't buy this claim that it's an efficiency issue. Moon's recent
messages claims this was done efficiently on the Lisp Machine.
Experience with Scheme likewise suggests this can be done efficiently.
You only have to do it once when the form is first seen by the
interpreter and never again. There's no loss of efficiency there. In
fact (leaving aside the question of macrofied declares for the context
of this sentence), if you are lazily or repeatedly expanding macros,
you're risking having a function change its behavior in midstream on any
expression involving macros, which I'd claim is a violation of the maxim
that interpreted and compiled code should execute the same for legal
expressions.

∂07-May-85  1319	REM%IMSSS.#Pup@SU-SCORE.ARPA 	Read macros vs. macro-->declare    
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 7 May 85  13:19:18 PDT
Received: from IMSSS by Score with Pup; Tue 7 May 85 13:19:08-PDT
Date:  7 May 1985 1319-PDT
From: Rem@IMSSS
Subject: Read macros vs. macro-->declare
To:   COMMON-LISP%SU-AI@SCORE

I agree that read macros aren't the right thing, i.e. something like
#<MACRO>(FOO ...) expanding at read time into (DECLARE (SPECIAL FROB)
(INTEGER FROB)) loses because it forces the macro-expansion environment
to be the read environment instead of the compiler environment, which
may not be exactly the same.  But would it be feasible to have a
continuation read-macro that produces a scheme-style continuation that
gets evaluated the first time anybody tries to perform an operation
upon it, even a trivial one like PAIRP? Then you could with this single
facility have macros that expanded into arglists, or into declarations,
or into arbitrary sequences of forms spliced into bodies of functions,
or into COND clauses, or into function names, or into type names,
or into any other sub-expression or splice-list? The programmer would
have to be careful not to try to do an operation on the continuation-ptr
until such time as the correct macro-expansion operation is in effect.
-------

∂07-May-85  1350	KMP@SCRC-STONY-BROOK.ARPA 	Read macros vs. macro-->declare  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 7 May 85  13:49:52 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 232132; Tue 7-May-85 16:43:19-EDT
Date: Tue, 7 May 85 16:44 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Read macros vs. macro-->declare
To: Rem%IMSSS@SU-SCORE.ARPA, COMMON-LISP@SU-AI.ARPA
In-Reply-To: The message of 7 May 85 16:19-EDT from Rem@IMSSS
Message-ID: <850507164439.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date:  7 May 1985 1319-PDT
    From: Rem@IMSSS
    Subject: Read macros vs. macro-->declare
    To:   COMMON-LISP%SU-AI@SCORE

    ...  would it be feasible to have a continuation read-macro that 
    produces a scheme-style continuation that gets evaluated the first time
    anybody tries to perform an operation upon it, even a trivial one 
    like PAIRP?

You're already (implicitly) performing "an operation" upon it if you
assume the expression is code at all. The bad part about readmacros
is that they force me to think "language semantics" at times when I might
only want to think "symbol manipulation". eg, I can't write an editor 
utility which calls normal READ to get
 (DEFUN FOO (X) #+LISPM X #-LISPM (1- X))
out of the buffer, manipulate the expression, and PRINT it back into
the buffer with any hope it that it will run on a system with different
characteristics than those I used to edit it. Here the expression is 
not code but data. Something along the lines of
 (DEFUN FOO (X)
   (IF-FEATURE LISPM X (1- X)))
works much better because you can READ-manipulate-PRINT it all day
without worrying that it's code, then can READ-COMPILE-FASDUMP or
READ-ABSORB-EXECUTE the processed code in some other system than
you did the original processing in without fear that you've lost a
read conditional.

By the way, this made me think of an interesting point on a slightly
different point, which is that one might imagine files full of (non-program) 
symbolic data which want to be read in certain package, but which because
it will never be EVAL cannot use the IN-PACKAGE strategy. That's another
example of inferring too strongly that anything that will be seen by
READ must be code and another argument for -*- ... Package: ... -*-
rather than IN-PACKAGE. ie, I'd rather use

  ;;; -*- Package: KEYWORD; -*-
  ;;; My data file

  (3 FOO BAR 7)
  (16.0 3/7 (X Y Z))

and be able to just repeatedly call READ on the file contents than
continually do some kludge to look for an IN-PACKAGE form at the head
of data files, as in:

  ;;; My data file

  (IN-PACKAGE "KEYWORD")
  (3 FOO BAR 7)
  (16.0 3/7 (X Y Z))

or worse

  (IN-PACKAGE "JOE")
  (EXPORT '(...))
  (3 FOO BAR 7)

where it might be ambiguous whether EXPORT, etc. are part of the package
spec or part of the data.

-kmp

∂07-May-85  1951	FAHLMAN@CMU-CS-C.ARPA 	Macros -> declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 7 May 85  19:50:50 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 7 May 85 22:50:34-EDT
Date: Tue, 7 May 1985  22:50 EDT
Message-ID: <FAHLMAN.12109248831.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Kent M Pitman <KMP%SCRC@MIT-MC.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Macros -> declarations
In-reply-to: Msg of 7 May 1985  15:17-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>


OK, I never doubted that people could make up cases where this macro ->
declare expansion appears to be useful.  I just doubted that it really
would be an important mechanism in practice, or at least important
enough to justify the pain it causes.

Is there any hope that we can all agree on flushing macro -> declaration
expansion and replacing it with something like Skef's "declaration
macro" proposal?  You state that this is the minimum acceptable position
(minimun acceptable amount of hair, I guess), and for me it's about the
maximum acceptable position.  It would seem to cover about 99% of the
cases where people claim that they need the macro expansion.

I agree that if taken to the logical extreme, this proliferation of
specialized macro-like forms is bad news.  On the other hand, one might
argue that macroexpanding potential declarations is also the start of a
slippery slide that, if taken to the logical extreme, could be equally
disastrous.  Maybe we could try to solve the problem at hand and agree
that taking things to their logical extremes is probably a bad idea in a
language this complex and this full of compromises.

-- Scott

∂07-May-85  2237	hoey@nrl-aic 	Re: SETF of APPLY    
Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 7 May 85  22:37:04 PDT
Message-Id: <8505080536.AA10133@nrl-aic>
Date: 7 May 1985 22:16:42 EDT (Tue)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: SETF of APPLY
To: common-lisp@SU-AI.ARPA

I like Guy's new text much more than the existing page 96, and after
reading Moon's code I believe it almost states the criterion for a
setf-applyable function correctly.  The problem is that it obscures
with faint emphasis its major point.  I read the statement:

    The SETF method for the function <name> must be such that the
    expansion of

    (SETF (<name> <z1> <z2> ... <zn> <zrest>) <z0>)

    uses the form <zrest> (or the generated variable that fronts for it)
    only as the last argument in some number of function calls

    (<any-function> <q1> ... <qn> <zrest>)			<1>

as the definition for a setf-applyable function, and the statement

    Every such function call in the expansion is altered to be

    (APPLY #'<any-function> <q1> ... <qn> <zrest>)		<2>

as the beginning of an explanation of what it does.  But by examining
the code I realize that the latter statement is the main point:  that
when those forms <1> get alterated to <2> their semantics must change
analogously to the alteration of

(<name> <x1> <x2> ... <xn> <zrest>)

to

(APPLY #'<name> <x1> <x2> ... <xn> <zrest>)

or the SETF will do something bizarre.  For instance, if <any-function>
has <n+1> required arguments and <zrest> turns out to be NIL, the
expansion will be in error.

Forgive the impulsive radicality of a neophyte but I think this
restriction needs an explanation that is not feasible until SETF
methods are introduced.  I would much rather see page 96 say something
like

    o A call to APPLY of the form (APPLY #'<name> {arg}* <others>)
      where <name>, has a ``SETF method'' amenable to APPLY, as
      described at the end of this section.  The only functions whose
      SETF expansions are defined by Common Lisp to have this form are
      AREF, BIT, and SBIT.

      As an example, suppose that the variable INDEXES ....

Then somewhere around page 106 the real bag of worms can be dumped on
the table:

    When

    (APPLY #'<name> <x1> <x2> ... <xn> <rest>)

    is used as a generalized variable, the SETF method for APPLY will
    access the SETF method for <name> with exactly <n+1> arguments:

    (GET-SETF-METHOD '(<name> <x1> <x2> ... <xn> <zrest>))

    that is, with the final argument to APPLY--and thus a list of final
    arguments to <name>--replaced by a single final argument to <name>.
    The storing and accessing forms returned by the SETF method must
    refer to the temporary variable <temp-rest> corresponding to <zrest>
    only as the last argument to a function:

    (<func> <q1> <q2> ... <qm> <temp-rest>)

    Each such function call will be altered when used in the SETF
    method of APPLY to be

    (APPLY #'<func> <q1> <q2> ... <qm> <temp-rest>)

    replacing the final argument to <func> by a list of final arguments.
    For (APPLY #'<name> <x1> <x2> ... <xn> <rest>) to be used as a
    generalized variable to be meaningful, the transformation
    described above must produce a correct SETF method for it.

I think it important that <x1> ... <xn> be guaranteed to be passed
verbatim in case their structure matters.

It might help to put the actual code for the APPLY SETF method in.

Further desiderata:

I wish there were some way for the author to declare that a SETF method
is or is not amenable to APPLY, and for a SETF method to determine
whether it is expanding for APPLY.  This might be done by promising
that APPLY's SETF method will use `(:MORE-ARGS ,(gensym)) for <zrest>
above.

Shouldn't <name>'s SETF method to be restricted to at most <n> required
and optional arguments, modulo destructuring?  Should

	(SETF (APPLY #'AREF (CONS FOO INDEXES)) NEWVALUE)

be allowed, or should it be required to be written

	(SETF (APPLY #'AREF FOO INDEXES) NEWVALUE)

as on page 97?  As it is, the code apparently works for the former only
by the accident that the SETF method for AREF could be (or is?) defined
with only an &REST argument:

	(DEFINE-SETF-METHOD AREF (&REST AREF-FORM)
	  (LET ((STORE (GENSYM))
		(AREF-FORM-TEMP (LOOP FOR ARGUMENT IN AREF-FORM
				      COLLECT (GENSYM))))
	     (VALUES AREF-FORM-TEMP
	     	     AREF-FORM
		     (LIST STORE)
		     `(ASET ,STORE ,@AREF-FORM-TEMP)
		     `(AREF ,@AREF-FORM-TEMP))))

Dan

∂08-May-85  0835	JLW  	PARSE-BODY    
To:   gls%aquinas@THINK.ARPA
CC:   common-lisp@SU-AI.ARPA

Re your message of 6-May-85 11:43 EDT

About a year and a half ago, I wrote such a internal utility for Interlisp-D.
Then I discovered that Ron Kaplan had also written a similar utility
a year or two prior.  The unfortunate thing is that neither of us 
managed to get our "utilty" promoted to user-level status, and docmented
for all to use and not re-invent.

Isn't it about time for somebody in the Common Lisp community to implement
it, and put it into (at least) the yellow pages?

Once that is done, then the only argument against macro-expansions
producing DECLAREs and docmentation-strings is the potential for
confusion with side-effect-producing macros.  I'm in favor of ignoreing
this problem (worrying about multiple side-effects from macro expansions)
but some others are more concerned.

-- JonL --

∂08-May-85  0859	RWK@SCRC-STONY-BROOK.ARPA 	Macros -> declarations 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 May 85  08:52:55 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 232642; Wed 8-May-85 11:48:51-EDT
Date: Wed, 8 May 85 11:53 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Macros -> declarations
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: Kent M Pitman <KMP@TENEX.SCRC.Symbolics.COM>, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12109248831.BABYL@CMU-CS-C.ARPA>
Message-ID: <850508115301.3.RWK@CROW.SCRC.Symbolics.COM>

    Date: Tue, 7 May 1985  22:50 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
    Is there any hope that we can all agree on flushing macro -> declaration
    expansion and replacing it with something like Skef's "declaration
    macro" proposal?  You state that this is the minimum acceptable position
    (minimun acceptable amount of hair, I guess), and for me it's about the
    maximum acceptable position.  It would seem to cover about 99% of the
    cases where people claim that they need the macro expansion.

Might I suggest another proposal that I think adds less complexity
for the same gain (for either side of the issue)?

Instead of DECLARE forms being allowed to be macros, why not allow the
forms INSIDE declare forms be macros?  Using macros rather than
"declaration macros" lets you then use macrolet, and avoids the need for
any new "DEFDECLARE" special forms to document or implement.

This doesn't quite cover the bases, though, unless we also deal with
expanding into multiple declarations [i.e. (REGISTER X) ->
(SPECIAL X) (FIXNUM X)].
I'll propose two ways to deal with that.

1)  Allow (DECLARE (FOO X) ((SPECIAL X) (FIXNUM X))) to mean the
same as (DECLARE (FOO X) (SPECIAL X) (FIXNUM X))

2)  Allow (DECLARE (FOO X) (DECLARE (SPECIAL X) (FIXNUM X))).  I.e.
Allow DECLARE as a declaration containing declarations.

∂08-May-85  0919	JLW  	... point on a different point    
To:   kmp@MIT-MC.ARPA
CC:   common-lisp@SU-AI.ARPA  

Re your message of 7-May-85 16:43 EDT

in your defense of
;;; -*- Package:...
;;; my data file
over
;;; my data file
(in-package ...)
you seem to be arguing as though the former happens at a level below READ,
and is thus unambiguous, whereas th latter is ambiguous since the form
(in-package ...)
could be data for the application program.

I don't see any such permission for READ mentioned in th CL manual.  In fact,
I have on numerous ocasions wanted to open a file and read character-by-character
to get a "close" look at the first few lines; and then call READ.

Isn't the right decomposition of functionality here to have a system-supplied
function called, say, READ-AND-DO-FILE-ATTRIBUTES; then LOAD would call it
on source files, and lusers who have random data files would make the
determination of attribute-information or data programmatically.  I.e., 
the mere act of opening a file, or reading from it, would not, by itself,
do the READ-AND-DO-FILE-ATTRIBUTES; but th luser can call it, either at 
top-level, or from some lower-level program.

-- JonL --

∂08-May-85  1121	FAHLMAN@CMU-CS-C.ARPA 	... point on a different point       
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 May 85  11:20:35 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 8 May 85 14:19:28-EDT
Date: Wed, 8 May 1985  14:19 EDT
Message-ID: <FAHLMAN.12109417898.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Jon White <JLW@SU-AI.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: ... point on a different point    
In-reply-to: Msg of 8 May 1985  12:19-EDT from Jon White <JLW at SU-AI.ARPA>


    Isn't the right decomposition of functionality here to have a system-supplied
    function called, say, READ-AND-DO-FILE-ATTRIBUTES; then LOAD would call it
    on source files, and lusers who have random data files would make the
    determination of attribute-information or data programmatically.

If by "system-supplied" you mean a part of the Common Lisp
specification, I don't think that we should elevate the current concept
of file attributes and mode lines to the status of a language feature if
we can possibly avoid this.  To establish this convention by treaty
among the suppliers of Common Lisps with Lisp-Machine-like environments
would be OK, however.

-- Scott

∂08-May-85  1513	RPG  	Proposal 
To:   quinquevirate@SU-AI.ARPA, ohlander@USC-ISI.ARPA,
      squires@USC-ISI.ARPA 

I'd like to make a proposal regarding validation, but I want
to run it by you folks first to see whether there are too many
negatives before I run it past everyone. 

I'd like to propose that there be a 2-stage validation
process. A group of hackers would be contracted to
collect and perform validation tests. This group would apply the
validation suite in an `intelligent' manner, producing a report
which stated what parts of common lisp: 1. are ok, 2. are not ok,
3. are missing, 4. are stretching the definition. These would be backed
up be specific tests that passed, failed, etc. This report, along with
a representative of the testing agency, would go before the validation
group, which would look at the report and any possible recommendations
the testing agency would have, and decide whether the Lisp passed overall
or was required to fix some things. 

The idea would be that the testing agency would not hide the test results
from the tested-Lisp implementors, and that the report would be open to
scrutiny, and the testers subject to questioning.

Now, why such a complex setup? The fact is that the companies have
all the talent and test code. Lucid's test suite is around 10k non-trivial
lines of test code already. We would be willing to act as the test agency
at the outset. We estimate that we could start testing Lisps within 2 months
from today, once our test suite is a little better.

To validate our common lisp, we would let the validation committee run,
or observe us running, the proposed test suite over it. The test suite
would be available for the validation committee to review. Or something fair.

I think that without some group, like us, stepping forward, the validation
effort will not get very far. I'm not so much interested in validation
per se, but I am concerned with `false advertising' to users about what they
are getting. 

So, if there are any comments about this proposal, I'd like to air them
in this forum before general discussion.

			-rpg-

∂08-May-85  1843	FAHLMAN@CMU-CS-C.ARPA 	Proposal    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 May 85  18:43:30 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 8 May 85 21:43:34-EDT
Date: Wed, 8 May 1985  21:43 EDT
Message-ID: <FAHLMAN.12109498777.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Dick Gabriel <RPG@SU-AI.ARPA>
Cc:   ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA, squires@USC-ISI.ARPA
Subject: Proposal 
In-reply-to: Msg of 8 May 1985  18:13-EDT from Dick Gabriel <RPG at SU-AI.ARPA>


Dick,

If I understand your proposal, you are trying to set up some way to do
validation of Common Lisp without actually making the official
validation suite available to the public.

If that's what you're saying, I think it is a bad idea.  With some sort
of official validation suite available to the public it will be very
easy for everyone, including random customers, to determine which
implementations are OK and which are deficient in various respects.  We
would still need a bit of machinery for officially blessing
implementations, but it can be very simple.  Public validation code also
makes it possible for implementors to see what is required, and will
serve to resolve some of the ambiguities in the manual.  With secret,
proprietary validation code, we get none of these advantages;
implementors will be stuck with debugging their systems by generate and
test.

Of course, if nobody gets to work doing this public validation suite,
and if all the companies choose to hang on to their own proprietary
validation code, then your plan may be the only option.  But it seems to
me that the advantages of having a body of validation code available to
the public are so great that even if companies hold onto their own code,
it is worth the effort of duplicating it.  In that case, the companies'
internal testing code would have no official standing, though it might
be of value to them for internal testing.  If there were money
available, perhaps the companies could be paid for throwing their
validation code into the pool, and thus could get something back on
their investment.

I suffered a minor setback here when two of my hand-trained undergrads
left for more lucrative jobs this summer.  Were it not for that, I could
have offered to do a big chink of a validation suite here this summer.
I still may be able to do this -- I've got a couple of very good
high-school kids working for me, but they are new and I don't know how
soon they will be ready to write serious validation code.  If ISI gets
the support contract for Common Lisp, they can do some of this as well.

-- Scott

∂08-May-85  2159	TIM@MIT-MC 	Lack of EQUALP hash tables  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 8 May 85  21:59:35 PDT
Date: Thu,  9 May 85 01:00:05 EST
From: Tim McNerney <TIM@MIT-MC>
Subject:  Lack of EQUALP hash tables
To: common-lisp@SU-AI
Message-ID: <[MIT-MC].492730.850509.TIM>

I noticed that EQUALP is no included in the set of valid :TEST's for
hash tables (CLTL p. 282).  What was the motivation behind this?  An
EQUALP hash table seems like a perfectly reasonable type of hash table
to want, especially in applications where floating-point numbers and
integers are intermixed.  Implementing the many to one hashing
function seems to be a bit tricky, but not insurmountable.  Am I
missing something?

∂08-May-85  2246	RPG  	Fahlman's comments 
To:   quinquevirate@SU-AI.ARPA, ohlander@USC-ISI.ARPA,
      squires@USC-ISI.ARPA 

The point of keeping (some) of the validation code `secret' is to
make sure that people don't cheat and get exactly the validation
code to work. I believe that is approximtely owow  ADA is done. 

I would also be in favor of doing it exactly the way ADA is done:
have a public validation suite along with a `secret' one. When the
public one has passed, the public and the private ones are applied
by the testors. 

In fact, there is no `proprietariness' to it at all. The validation
suite that would be used for this purpose, if done the way I suggest,
would be government property. 

			-rpg-

∂09-May-85  0511	GJC@MIT-MC
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 9 May 85  05:11:14 PDT
Date: Thu,  9 May 85 08:11:50 EST
From: George J. Carrette <GJC@MIT-MC>
To: TIM@MIT-MC
cc: COMMON-LISP@SU-AI
Message-ID: <[MIT-MC].493032.850509.GJC>

EQUALP hash tables were absolutely essential in keeping LMI in
business, maybe thats why they were excluded. But seriously folks, the
digital CAD program we use in-house, "NewDraw," broke when moving from
pre-common-lisp system to post-common-lisp. Right at the time when
major new hardware development was going on, and the "NewDraw" users
wanted to move to post-common-lisp because of vast speed improvements
such as microcoded ethernet. There clearly wasnt any time for major
rewrites, so that the only thing to do was to change all functions
which inductively called EQUAL in the pre-common-lisp to ones that
call EQUALP in the new system.  EQUAL => EQUALP, and ASSOC =>
ASSOC-EQUALP are the kind of obvious cases, but the program still
didnt work until a clever hardware engineer realized that he was being
screwed by hash table lookup, and changed MAKE-HASH-TABLE :TEST 'EQUAL
=> :TEST 'EQUALP.  Which of course didnt work until a software person
implemented it.

The problem was that (EQUAL "foo" "FOO") used to be T, but now is NIL,
and all the hardware databases had chip and signal names in both
upper and lowercase, depending on what the user first typed in.

So from practical experience I can definitely put in a vote for
having :TEST 'EQUALP in hash tables.

-gjc


∂09-May-85  0622	RAM@CMU-CS-C.ARPA 	Lack of EQUALP hash tables
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 9 May 85  06:22:26 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Thu 9 May 85 09:22:32-EDT
Date: Thu, 9 May 1985  09:22 EDT
Message-ID: <RAM.12109626021.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   common-lisp@SU-AI.ARPA
Subject: Lack of EQUALP hash tables
In-reply-to: Msg of 9 May 1985  02:00-EDT from Tim McNerney <TIM at MIT-MC>


I think an Equalp hashtable would also be useful because it would
allow you to use arrays and structures as keys.

In my code I have never had any great use for the case-insensitiveness
of equalp, since I use string-equal.  In fact, I think it would be
useful if there was a predicate which used eql for comparison and
descended into arrays and structures.  There have been a number of
times when I could have used such a function.

  Rob

∂09-May-85  0643	BSG@SCRC-STONY-BROOK.ARPA 	Macros -> declarations 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 May 85  06:41:05 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 233367; Thu 9-May-85 09:36:59-EDT
Date: Thu, 9 May 85 09:43 EDT
From: Bernard S. Greenberg <BSG@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Macros -> declarations
To: RWK@YUKON.SCRC.Symbolics.COM, Fahlman@CMU-CS-C.ARPA
cc: KMP@TENEX.SCRC.Symbolics.COM, common-lisp@SU-AI.ARPA
In-Reply-To: <850508115301.3.RWK@CROW.SCRC.Symbolics.COM>
Message-ID: <850509094320.7.BSG@CONCORD.SCRC.Symbolics.COM>

    Date: Wed, 8 May 85 11:53 EDT
    From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>

    Instead of DECLARE forms being allowed to be macros, why not allow the
    forms INSIDE declare forms be macros?  Using macros rather than
    "declaration macros" lets you then use macrolet, and avoids the need for
    any new "DEFDECLARE" special forms to document or implement.

    This doesn't quite cover the bases, though, unless we also deal with
    expanding into multiple declarations [i.e. (REGISTER X) ->
    (SPECIAL X) (FIXNUM X)].
    I'll propose two ways to deal with that.

    1)  Allow (DECLARE (FOO X) ((SPECIAL X) (FIXNUM X))) to mean the
    same as (DECLARE (FOO X) (SPECIAL X) (FIXNUM X))

    2)  Allow (DECLARE (FOO X) (DECLARE (SPECIAL X) (FIXNUM X))).  I.e.
    Allow DECLARE as a declaration containing declarations.

3) Allow (DECLARE (PROGN .....))  [The onus of history.]

At any rate, RWK's whole proposal seems to cover all bases.

∂09-May-85  0900	DCP@SCRC-STONY-BROOK.ARPA 	hash table types  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 May 85  09:00:17 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 233515; Thu 9-May-85 11:56:12-EDT
Date: Thu, 9 May 85 12:01 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: hash table types
To: George J. Carrette <GJC@MIT-MC.ARPA>
cc: TIM@MIT-MC.ARPA, COMMON-LISP@SU-AI.ARPA
In-Reply-To: <[MIT-MC].493032.850509.GJC>
Message-ID: <850509120102.8.NFEP@NEPONSET.SCRC.Symbolics.COM>

    Date: Thu,  9 May 85 08:11:50 EST
    From: George J. Carrette <GJC@MIT-MC>

    The problem was that (EQUAL "foo" "FOO") used to be T, but now is NIL,
    and all the hardware databases had chip and signal names in both
    upper and lowercase, depending on what the user first typed in.

It sounds like you should fix the root problem instead of this kind of
workaround.  Another alternative would be to implement
CASE-INSENSITIVE-EQUAL-HASH-TABLEs, where the :test is
CASE-INSENSITIVE-EQUAL or somesuch.

    So from practical experience I can definitely put in a vote for
    having :TEST 'EQUALP in hash tables.

That's not to say I think equalp hash tables are a bad idea.  I'm not
sure if they are good or bad.  I fear the efficiency penalty of
traversing every array it finds.  Your message is clearly a request for
equal-like hash table that ignore case (or maybe you should change your
hardware database (or make your program always STRING-UPCASE)).

Also keep in mind that it is relatively easy for flavor-based
implementations to "just go off and add" more types of hash tables.  The
expsnse-to-implement::usefulness ratio may be too high for other
architectures/systems.

∂09-May-85  0911	FAHLMAN@CMU-CS-C.ARPA 	Fahlman's comments    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 9 May 85  09:11:36 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 9 May 85 11:36:37-EDT
Date: Thu, 9 May 1985  10:56 EDT
Message-ID: <FAHLMAN.12109643052.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Dick Gabriel <RPG@SU-AI.ARPA>
Cc:   ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA, squires@USC-ISI.ARPA
Subject: Fahlman's comments 
In-reply-to: Msg of 9 May 1985  01:46-EDT from Dick Gabriel <RPG at SU-AI.ARPA>


Ah, OK, I totally misunderstood what you were suggesting.  Never mind.

Certainly if we have a public validation suite that covers everything we
want to test, and a secret set of variations on this to keep people
honest, that is the best of all possible worlds.  And given that, the
machinery that you propose sounds reasonable to me.

The other manufacturers may not be enthusiastic about having Lucid be
the tester, but presumably DOD has the right to designate anyone they
want (subject, perhaps, to competitive bidding requirements) as the
validator of Lisps for government work.  We still might be able to get
other companies to contribute code for the public test suite, but that
can be treated as optional.

If it looks like this plan is going to fly, I'll coordiante any work we
do in writing public-domain validation stuff with RPG so as to minimize
duplicated effort and fill in any holes as quickly as possible.

-- Scott

∂09-May-85  0929	GRISS%hp-hulk.csnet@csnet-relay.arpa 	Re: PARSE-BODY        
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 9 May 85  09:29:06 PDT
Received: from hplabs by csnet-relay.csnet id ab22357; 9 May 85 12:26 EDT
Received: by HP-VENUS id AA25414; Thu, 9 May 85 05:55:47 pdt
Message-Id: <8505091255.AA25414@HP-VENUS>
Date: Thu 9 May 85 05:55:37-PDT
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Re: PARSE-BODY    
To: JLW
Cc: common-lisp@su-ai.ARPA, GRISS@hplabs.CSNET
In-Reply-To: Message from "Jon White <JLW@SU-AI@HP-VENUS>" of Wed 8 May 85 08:35:00-PDT
Source-Info:  From (or Sender) name not authenticated.

Apropos Yellow PAges. Is anything happening to the Yellow pages?
Is there a set of publically available and documented files, yet?

Martin Griss
-------

∂09-May-85  1103	RPG  	Comments on ...    
To:   quinquevirate@SU-AI.ARPA, ohlander@USC-ISI.ARPA,
      squires@USC-ISI.ARPA 

I believe that the tricky and essential part of this scheme is that Lucid
(or whoever helpd with validation later on) does not actually do
validation, but they contribute evidence that is used by the validation
group itself. Second, the testing group probably has to have their Lisp
validated extra carefully, and with probably a more detailed and lengthy
technique so as to be above reproach. What the testing group produces must
be a report (full of facts like: passed the lambda-list tests, except for
the one where you SETQ the &rest argument during the optional defaulting
process) that is rebuttable and non-binding on the tested Lisp. It will be
a judgement call for someone to decide what the evidence means.

I believe that once the procedure is set up with one group doing the
work for a while, the job could rotate among the various groups
willing to do it. Also, to be quite honest, I would prefer to see the
group most likely to have (and want to have) the most rigorously
tested and complete Common Lisp be the first group to do the work.

If we don't do something like this, then we'll have to set up a separate
group at a neutral place, like ISI, and I'm simply not sure that we can
find people who would want to do that sort of work conscientiously in such
a setting. The only reason to try something like this is to find a way
for the competent people to do the job.

			-rpg-

∂09-May-85  2101	FAHLMAN@CMU-CS-C.ARPA 	PARSE-BODY       
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 9 May 85  21:01:48 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 10 May 85 00:01:24-EDT
Date: Fri, 10 May 1985  00:01 EDT
Message-ID: <FAHLMAN.12109786018.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Martin <GRISS%hplabs.csnet@CSNET-RELAY.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: PARSE-BODY    
In-reply-to: Msg of 9 May 1985  08:55-EDT from Martin <GRISS%hplabs.csnet at csnet-relay.arpa>


We now have a small collection of public-domain programs in Common
Lisp, with documentation, for our local users at CMU.  Many of these
things depend on features only present in the Perq and the Accent
operating system, though in many of those the dependencies are minor and
easily worked around.  Some things are fully portable Common Lisp.  A
couple of biggies (OPS5, a portable Flavors implementation, a drawing
program, and a Lisp-based shell for Spice) will be in there soon, but
are not there now.

Right now this stuff lives on CMU-CS-SPICE in /usr/spice/library/lisp.
Since anonymous FTP doesn't work on this machine, I'll try to copy this
stuff over to CMU-CS-C sometime soon, and will let people know when this
is done.

This is just a start, of course.  Once we have enough things to justify
the split, I'll create separate directories for truly portable things
and those that depend on some aspect of Perq/Accent.  If anyone has any
portable code to contribute, feel free to send it to me, but only if it
is public domain or if you can grant us the rights to pass this code out
to anyone who wants it.

-- Scott

∂09-May-85  2254	KMP@SCRC-STONY-BROOK.ARPA 	Macros -> declarations 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 May 85  22:54:25 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 234166; Fri 10-May-85 01:50:12-EDT
Date: Fri, 10 May 85 01:51 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Macros -> declarations
To: RWK@SCRC-YUKON.ARPA, Fahlman@CMU-CS-C.ARPA
cc: KMP@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <850508115301.3.RWK@CROW.SCRC.Symbolics.COM>
Message-ID: <850510015144.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Wed, 8 May 85 11:53 EDT
    From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>

	Date: Tue, 7 May 1985  22:50 EDT
	From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
	Is there any hope that we can all agree on flushing macro -> declaration
	expansion and replacing it with something like Skef's "declaration
	macro" proposal?  You state that this is the minimum acceptable position
	(minimun acceptable amount of hair, I guess), and for me it's about the
	maximum acceptable position.  It would seem to cover about 99% of the
	cases where people claim that they need the macro expansion.

    Might I suggest another proposal that I think adds less complexity
    for the same gain (for either side of the issue)?

    Instead of DECLARE forms being allowed to be macros, why not allow the
    forms INSIDE declare forms be macros?  Using macros rather than
    "declaration macros" lets you then use macrolet, and avoids the need for
    any new "DEFDECLARE" special forms to document or implement.

No, this is too confusing. What about things like STRING which are already functions?
Do we propose to have macro syntax available in a context where function syntax is not?
I think that would be very confusing. Also, what if someone did

(DEFMACRO TYPE (X) `(PRINT ,X))

and then someone else did (DECLARE (TYPE LIST FOO)). You wouldn't want to tell people
that the possible declaration names (which are all really good names) weren't available
to them for definition as names for macros (but -were- available to them as function
names)... would you?

    This doesn't quite cover the bases, though, unless we also deal with
    expanding into multiple declarations [i.e. (REGISTER X) ->
    (SPECIAL X) (FIXNUM X)].
    I'll propose two ways to deal with that.

Skef's declaration macros covered this case by making them always return a list of
declarations. (This also allows one to conveniently return no declarations, which is
good since if (REGISTER X) didn't want to expand into any declarations it would
otherwise be stuck expanding into NIL implying (DECLARE NIL) which may be ill-formed
for all I know... or (SPECIAL) implying (DECLARE (SPECIAL)) which is semantically silly.)

    1)  Allow (DECLARE (FOO X) ((SPECIAL X) (FIXNUM X))) to mean the
    same as (DECLARE (FOO X) (SPECIAL X) (FIXNUM X))

    2)  Allow (DECLARE (FOO X) (DECLARE (SPECIAL X) (FIXNUM X))).  I.e.
    Allow DECLARE as a declaration containing declarations.

Yuck.

On the other hand, I'm really bothered by the fact that one can write:

(DEFMACRO DECLARE-FOO (&REST X) `(DECLARE (FOO ,@X)))

and use (DECLARE-FOO ...) at toplevel but not inside a DEFUN. I think people
will find this an ugly inconsistency.

I am also bothered by the idea of checking explicitly for DECLARE because
it means that the thing would not really be an operator at all. It would 
essentially be just a part of the syntax of some other form (eg, DEFUN or
LAMBDA) -- yet another odd kind of keyword (like OTHERWISE in SELECTQ).

And when everything is said and done, the only thing we're trying to avoid
is occasionally having to change:

(DEFMACRO DEFFOO (NAME BVL &BODY FORMS)
  `(DEFUN ,(FOOIFY NAME) BVL ,@FORMS))

Oops, no that's not one of the one that has to change. Lemme see. It's gotta
be more complicated than that before any of this matters. Ah yes, I wrote
something like this just the other day:

(DEFMACRO DEF-MY-MACRO (NAME BVL &BODY FORMS)
  `(DEFMACRO ,NAME ,BVL
     (MAKE-MY-ENCAPSULATION (PROGN ,@FORMS))))

must be rewritten as

(DEFMACRO DEF-MY-MACRO (NAME BVL &BODY FORMS &ENVIRONMENT ENV)
  (MULTIPLE-VALUE-BIND (BODY DECLARATIONS DOCUMENTATION)
      (PARSE-BODY FORMS)
    `(DEFMACRO ,NAME ,BVL
       ,@DECLARATIONS ,DOCUMENTATION
       (MAKE-MY-ENCAPSULATION (PROGN ,@BODY)))))

I just don't see this as a big deal.

Since it is so idiomatic, though, how about if &BODY did the declaration
parsing if you gave it a list of vars instead of a symbol var. Eg,

(DEFMACRO DEF-MY-MACRO (NAME BVL &BODY (BODY DECLS DOC))
  `(DEFMACRO ,NAME ,BVL
     ,@DECLS ,DOC
     (MAKE-MY-ENCAPSULATION (PROGN ,@BODY))))

could be defined to mean the same as what I had just written. Or maybe

(DEFMACRO DEF-MY-MACRO (NAME BVL &BODY BODY DECLS DOC)
  ...)

if you thionk the DECLS and DOC look too much like initializations and
present-p checks the other way. This latter syntax means you could have
defaults for these. Eg,

(DEFMACRO DEF-MY-MACRO (NAME BVL &BODY (BODY '(...default body...))
				       (DECLS '((DECLARE (SPECIAL *FOO*))))
				       (DOC "a macro"))
  ...)

I believe that attacking the problem of DECLARE at the level people have been
attacking it gives up programmer flexibility to no good end (not to mention
introducing an incompatible change to the language semantics). A change
like these syntax extensions to DEFMACRO that I've been speaking about would
make life easy for the macro writer without giving up the macro-writing 
freedoms I was originally supporting.

Thoughts?

∂09-May-85  2319	JLW  	READ-AN-DO-FILE-ATTRIBUTES   
To:   Fahlman@CMU-CS-C.ARPA
CC:   common-lisp@SU-AI.ARPA 

Yes, by "system-supplied", I was proposing this for white pages level on
the next go-around (hopefully, for yellow pages level during the interim --
expecting that interim not to be longer than 2 years).

But I didn'nt mean to imply the Lispm convention of lines with ;;; -*-
when saying "attributes";  I mean the generalized notion of whatever
the agreed-upon convention will be.  This means that merely having
the 7-extremely-randoms in a lisp-like syntax near the beginning of
the file would be fine.  

Moon is disinclined to go for another convention (i.e. something other
than the ;;; -*-), and one can sympathize with him, given the investment
of time etc that Symbolics has in it.  But I don't think it would be so
hard to spec out a lisp-syntax proposal, especially if there were a means
of doing a "limited" READ (i.e., a READ that doesn't swallow more than,
say, 1024 characters.)  It's not just a love of lisp syntax that brings
this matter up, but rather the difficlty of extending the ;;;-*- notation
to meet the increasing number of contextual needs.

-- JonL --

∂09-May-85  2356	JLW  	EQUALP hash tables (and more ...) 
To:   tim@MIT-MC.ARPA
CC:   common-lisp@SU-AI.ARPA  

Not too long ago, some of the LOOPS people at Xerox PARC needed a more
generalized form of hashing; the solution was to admit two more "properties"
of hashtables -- the "equivalenceing" function, and the "numericalizing"
function.  Both of these are fully general arguments -- the user may supply
any reasonable function there -- and I don't see why such an extended definition
hasn't been accepted into CL; can anyone remember a reason for the restriction
to such a limited set?  [current Interlisp-D release documents changes made
to hashing almost a year ago -- this loops-inspired extension was done only
at the end of 1984, and wasn't even fully integrated into the system by the
time I left Xerox in January 1985].

For "equivalence" function, the user may supply #'eq, #'string=, or even 
something random like #'=-mod-5; the "numericalizing" function is simply 
how to reduce a general s-expression into a reaonable sized fixnum; for EQ 
type tables, this is usually something like MacLisp's MAKNUM (Interlisp's LOC),
and for EQUAL type tables it is usually SXHASH.

One very interesting point to note is that the CLM doesn't require that EQ
type tables actually use the pointer address (ie. numericalizing by MAKNUM);
apparently in an effort to maintain generality and portability, the only
specification for such tables is that the equivalencing test be EQ.  I and
several of my colleagues "believe" that everyone thinks hashing on EQ means
using the pointer address, rather than the sxhash, as the numerical start --
but nothing in the CLM would prevent an implementation from using sxhash
instead.  And indeed, the only way one would ever notice the difference
(apart from an unreasonably slow implementation of SXHASH!), is that
using MAKNUM would insulate against re-orderings of the "chains" inside
the table [I'm assuming everyone knows the problem with using sxhash
for the numericalizing -- that updates to a hashed structure will change
its sxhash value, and thereby cause it to be in a differnt chain in
the hash table.]

-- JonL --

∂10-May-85  0017	JLW  	Y.A.R.I.M.: Macros inside DECLARE?
To:   rwk@SCRC-STONY-BROOK.ARPA
CC:   common-lisp@SU-AI.ARPA  

In-reply-to: your message of 8-May-85 11:53 EDT

As far as I'm concerned, your attempt to unify source-level transformations
under the existing DEFMACRO is the best thing to come out of all this 
discussion.  No more DEFMUMBLEs where DEFMUMBLE is 
                YetAnotherRedundantImitationofMacros!
I feel that this is more important than the issues of whether macros may 
produce declares, or whether declare macroexpands its innards.

The comment above is also a vote against "lambda macros" -- they provide
absolutely no functionality beyond that capable by ordinary macros, and
give only marginally better error checking.

-- JonL --

∂10-May-85  0146	hoey@nrl-aic 	Re: EQUALP hash tables (and more ...)    
Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 10 May 85  01:46:39 PDT
Date: 10 May 1985 03:54:51 EDT (Fri)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: EQUALP hash tables (and more ...)
To: Jon White <JLW@SU-AI.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Message-Id: <484559691/hoey@nrl-aic>

    Date: 09 May 85  2356 PDT
    From: Jon White <JLW@SU-AI.ARPA>

    ... a more generalized form of hashing ... two more "properties" of
    hashtables -- the "equivalenceing" function, and the "numericalizing"
    function....

    For "equivalence" function, the user may supply #'eq, #'string=, or
    even something random like #'=-mod-5;

Bravo!  If CL should have hash tables, it should have these.  The
existing lack of functionality is embarrassing in an otherwise
orthogonal, extensible language.

    ... the "numericalizing" function is simply how to reduce a general
    s-expression into a reasonable sized fixnum....

I would leave off ``reasonable sized''; certainly gethash is capable of
hashing a fixnum value to its favorite range.

    I [believe] hashing on EQ means using the pointer address...
    but nothing in the CLM would prevent an implementation from using sxhash
    instead.

Two problems with this.  First, as you note, the key could get
modified.  I'm not sure you noticed, but this means that in order for
GETHASH to fail, it would have to examine the whole table for modified
structures.  Second, I think SXHASH might not terminate on circular
structures, though this caveat is not in the manual (and it, or its
denial, should be).

Dan

∂10-May-85  0906	FAHLMAN@CMU-CS-C.ARPA 	Macros -> declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 May 85  09:06:19 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 10 May 85 11:35:56-EDT
Date: Fri, 10 May 1985  10:18 EDT
Message-ID: <FAHLMAN.12109898307.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Macros -> declarations
In-reply-to: Msg of 10 May 1985  01:51-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>


I agree with KMP's critique of RWK's proposal to just use normal macros
inside the declaration forms.  Too many problems.

As for KMP's comments...

    On the other hand, I'm really bothered by the fact that one can write:

    (DEFMACRO DECLARE-FOO (&REST X) `(DECLARE (FOO ,@X)))

    and use (DECLARE-FOO ...) at toplevel but not inside a DEFUN. I think people
    will find this an ugly inconsistency.

But you CAN'T use DECLARE-FOO at top-level, since the DECLARE form
produced will not be legal there.  In general, macros only work in place
of forms that you are going to evaluate.  In quoted contexts, or other
non-evaluated places like arglists, a macro would never expand.  DECLARE
is one of those, since you never evaluate the DECLARE, but just look at
it while deciding how to set up the arguments.  The ugly inconsistency
here is allowing macros in this place.

    I am also bothered by the idea of checking explicitly for DECLARE because
    it means that the thing would not really be an operator at all. It would 
    essentially be just a part of the syntax of some other form (eg, DEFUN or
    LAMBDA) -- yet another odd kind of keyword (like OTHERWISE in SELECTQ).

That's right, DECLARE is not an opertor in Common Lisp, just a piece of
syntax that happens to take the form of an operator.  The form is
probably a hold-over from Maclisp, where DECLARE was an operator.  If we
had chosen a different syntax for this, such as always having the first
list of the body be a declaration without any DECLARE marker in front of
it, or hiding the declarations in the arglist after an &declare marker,
we would not have made the mistake of treating this as a funny kind of
operator when it's really structural.

    (DEFMACRO DEF-MY-MACRO (NAME BVL &BODY FORMS)
      `(DEFMACRO ,NAME ,BVL
         (MAKE-MY-ENCAPSULATION (PROGN ,@FORMS))))

    must be rewritten as

    (DEFMACRO DEF-MY-MACRO (NAME BVL &BODY FORMS &ENVIRONMENT ENV)
      (MULTIPLE-VALUE-BIND (BODY DECLARATIONS DOCUMENTATION)
          (PARSE-BODY FORMS)
        `(DEFMACRO ,NAME ,BVL
           ,@DECLARATIONS ,DOCUMENTATION
           (MAKE-MY-ENCAPSULATION (PROGN ,@BODY)))))

    I just don't see this as a big deal.

It may not be a big deal, but you DID get it wrong.  Parse-Body has to
receive the appropriate ENV as an argument in order to do its work,
unless your version of Parse-Body is somehow getting this as a special.
That, basically, is the mistake that people keep making.

Well, it looks like we're going to lose this battle.  Too many people on
this list are fascinated by the alleged flexibility that the macro ->
declaration misfeature gives them, and too few are bothered by the
errors, confusion, and inefficiency that this causes.  Since the
misfeature is already in the manual, it would require a clear consensus
to remove it, and I don't see that emerging.

The fallback position is to add a reasonable PARSE-BODY form to the
language, with a required environment argument as well as the forms
argument.  We should probably do that in any event, since each and every
implementation seems to have invented this and few people can write a
correct macro without this.  The manual will need to be extended, in the
section on Macros, I guess, to explain what this is about and give an
example or two.

I am also very interested in KMP's suggestion for an extenstion to the
&body syntax, but need to study this a bit to make sure that there are
not hidden problems.  The big advantage of this, of course, is that it
allows the casual macro-writer to avoid dealing explicitly with
environments and hairy M-V uses of Parse-body for most simple things.  I
grant that people who can't hack these things shouldn't be writing
macros, but they will be, and life will be easier all around if we can
make this process less error-prone.

-- Scott

∂10-May-85  1057	REM@IMSSS 	Instead of read macros, how about one reserved-word for process-time macro?    
Received: from IMSSS by SU-AI with PUP; 10-May-85 10:57 PDT
Date: 10 May 1985 1058-PDT
From: Rem@IMSSS
Subject: Instead of read macros, how about one reserved-word for process-time macro?
To:   COMMON-LISP@SU-AI

Here's an idea I used here as an alternative to splicing macros and other
MacLISP grunge which weren't available here, and which might in CL be a general
solution to macro->declare, argument-list macros, etc.
Have one reserved word, which in the CAR position of any form, even an
inner form, causes the CADR to be the name of a macro and the CDDR to be
a form to be passed to that macro. The result from that macro is then the
effective form to be processed instead of the original form containing the
reserved word. For example, if ! is the reserved word, and FOO is a macro,
then (A B ! FOO X Y Z) means (A B . q) WHERE q is the result of applying
FOO to the s-expression (X Y Z). For example, if FOO is a macro that
expands into the arglist (VAL1 VAL2 TMP) then (DEFUN BAR (!FOO) ...)
is effectively (DEFUN BAR (VAL1 VAL2 TMP) ...). If you want to patch
things together, use ! before CONS or APPEND, for example if FOO2 is
a macro that expands into another arglist (PTR1 PTR2) then you can get
all five args by saying (DEFUN BAR (! APPEND (! FOO) (! FOO2)) ...).

I'm a bit sloppy because this is just an idea. Should we use recursive
evaluation when passing arguments to macros or functions named after !,
or should we use EVALQUOTE conventions where args are implicitly quoted?
You can of course suppress evaluation by ' or increase evaluation by
doing (! EVAL <form>) so either way you get full flexibility. Of course
the context of the macro-expansion should be whatever context would be
doing the normal processing of the data. Note that even user data could
use this convention if the particular program doing the processing were
(advertised as) respecting this data-macro convention. Initially only a
few system utilities would respect this convention, such as the compiler
and interpretor when the data-macro appears in certain places in forms
to be compiled or evaluated, but later additional programs could install
the convention and start to advertise it. (Imagine having random data
fed into some random program that happens to respect the convention, with
that data having the ability to perform arbitrary processing before
passing the effective data to the program! Sort of like actors/objects!)
-------

∂10-May-85  1139	BSG@SCRC-STONY-BROOK.ARPA 	Y.A.R.I.M.: Macros inside DECLARE?    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 May 85  11:38:52 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 234523; Fri 10-May-85 14:34:23-EDT
Date: Fri, 10 May 85 14:39 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Y.A.R.I.M.: Macros inside DECLARE?
To: JLW@SU-AI.ARPA, rwk@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 10 May 85 03:17-EDT from Jon White <JLW@SU-AI.ARPA>
Message-ID: <850510143907.6.BSG@CONCORD.SCRC.Symbolics.COM>

    Date: 10 May 85  0017 PDT
    From: Jon White <JLW@SU-AI.ARPA>


    In-reply-to: your message of 8-May-85 11:53 EDT

    As far as I'm concerned, your attempt to unify source-level transformations
    under the existing DEFMACRO is the best thing to come out of all this 
    discussion.  No more DEFMUMBLEs where DEFMUMBLE is 
		    YetAnotherRedundantImitationofMacros!
    I feel that this is more important than the issues of whether macros may 
    produce declares, or whether declare macroexpands its innards.

    The comment above is also a vote against "lambda macros" -- they provide
    absolutely no functionality beyond that capable by ordinary macros, and
    give only marginally better error checking.

    -- JonL --

Do I read you right, that what you are suggesting is that
I say (defmacro adbmal (x) `(lambda . (cdr ,x)))
and I could then say
      (funcall foo #'(adbmal (y) (+ y 3))
? That's clearly right.

∂10-May-85  1239	BSG@SCRC-STONY-BROOK.ARPA 	Macros -> declarations 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 May 85  12:39:02 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 234581; Fri 10-May-85 15:34:38-EDT
Date: Fri, 10 May 85 15:39 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Macros -> declarations
To: KMP@SCRC-STONY-BROOK.ARPA, RWK@SCRC-YUKON.ARPA,
    Fahlman@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850510015144.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <850510153924.2.BSG@CONCORD.SCRC.Symbolics.COM>

    Date: Fri, 10 May 85 01:51 EDT
    From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>

    No, this is too confusing. What about things like STRING which are already functions?
    Do we propose to have macro syntax available in a context where function syntax is not?
    I think that would be very confusing. Also, what if someone did

    (DEFMACRO TYPE (X) `(PRINT ,X))

    and then someone else did (DECLARE (TYPE LIST FOO)). You wouldn't want to tell people
    that the possible declaration names (which are all really good names) weren't available
    to them for definition as names for macros (but -were- available to them as function
    names)... would you?
Damn!  Just when I was beginning to like this!  How about, for a really off-the-wall suggestion,
a "macroification context", defined by each macro by the &EXPANDWHEN-CONTEXT notkeyword, and
whose default is (:EVAL :COMPILE)  (choose any names you like)
   (defmacro push (x y &expandwhen-context (:eval :compile)) ..etc.) 
means that evaluation and compilation (the only kind valid today) are the contexts in which
this macro will be recognized.  (I can see several implementation possibilities.)
This allows extension to :declaration, :functional-form (lambda macro) :lap-code and
n other non-intrusive, compatible possibilities.
  Thus,
   (defmacro register (x &EXPANDWHEN-CONTEXT :declare) `(fixnum ,(cdr x)))

∂10-May-85  2005	FAHLMAN@CMU-CS-C.ARPA 	Macros -> declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 May 85  20:05:34 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 10 May 85 22:35:40-EDT
Date: Fri, 10 May 1985  22:04 EDT
Message-ID: <FAHLMAN.12110026915.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   "Bernard S. Greenberg" <BSG@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Macros -> declarations
In-reply-to: Msg of 10 May 1985  15:39-EDT from Bernard S. Greenberg <BSG at SCRC-STONY-BROOK.ARPA>


You forgot to put in the :-) glyph.  Without it, someone might thing you
are serious.

-- Scott

∂11-May-85  0635	FAHLMAN@CMU-CS-C.ARPA 	:-(    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 May 85  06:35:36 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 11 May 85 09:35:44-EDT
Date: Sat, 11 May 1985  09:35 EDT
Message-ID: <FAHLMAN.12110152717.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   common-lisp@SU-AI.ARPA
Subject: :-(


Upon reflection, I shouldn't have been so flippant in dismissing BSG's
suggestion about macro-expansion environments, and I apologize to him.
I assume that his suggestion was serious, and poking fun at suggestions
that we disagree with is obviously not the best way to promote the free
flow of ideas.  It has been a long week, and I was feeling irritable.

I think that this suggestion is a step in the wrong direction.  We want
to make the whole issue of macros expanding in funny places less
confusing, not more so, and a multiple name space mechansism so that
macros in various places can have the same name doesn't look to me like
a good idea.

-- Scott

∂11-May-85  0759	FAHLMAN@CMU-CS-C.ARPA 	EQUALP hash tables (and more ...)    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 May 85  07:59:16 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 11 May 85 10:59:21-EDT
Date: Sat, 11 May 1985  10:59 EDT
Message-ID: <FAHLMAN.12110167939.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Jon White <JLW@SU-AI.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: EQUALP hash tables (and more ...) 
In-reply-to: Msg of 10 May 1985  02:56-EDT from Jon White <JLW at SU-AI.ARPA>


The Interlisp-like extension to hash tables that JONL proposes sounds
like a pretty good one to me: allow users to specify their own test
functions, but if they choose anything other than a small set of
"built-in" tests, they have to supply the appropriate numericalizing
function as well.  I'm not sure what the new keyword to make-hash-table
would be.  :numericalize doesn't do much for me.

This is a compatible extension, as long as we allow the user not to
supply the numericalizer if the test is one of EQ, EQL, or EQUAL (and
maybe we add EQUALP).  For EQ, at least, the numericalizer has to be
built in, because we really can't put anything like MAKNUM in the
portable language.

A few other things might be required to round this out.  One is a
keyword that says whether the table has to be rehashed after a GC, as
most implementations now do for EQ hashtables.  This switch would be
ignored in implementations that do not move things during a GC.  We also
probably want to supply the user with a manual REHASH function that takes a
whole hashtable and rehashes it.  For modifying individual keys, we just
have to make clear to the users that they had better remove the item,
alter it, and then put it back.

I'm not sure if we want to make so large an extension to hash tables,
but if we do, this is a compatible way of doing it.

-- Scott

∂11-May-85  1229	WHOLEY@CMU-CS-C.ARPA 	EQUALP hash tables (and more ...)     
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 May 85  12:29:13 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Sat 11 May 85 15:29:18-EDT
Date: Sat, 11 May 1985  15:29 EDT
Message-ID: <WHOLEY.12110217078.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To:   Common-Lisp@SU-AI.ARPA
Subject: EQUALP hash tables (and more ...) 
In-reply-to: Msg of 11 May 1985  10:59-EDT from Scott E. Fahlman <Fahlman>

I think a user-extensible hash table mechanism would be a win, and would be
easily implementable even in our non-flavorized system (surprise, surprise).
I have a few comments, though:

1. I don't think it's possible to let users write some form of hashing function
that generates = numbers for EQ objects.  There might be an arbitrarily long
time between computing the hash number and using it as an index into a vector,
in which countless objects may be transported or garbage collected.  This, of
course, entirely ignores the ugly mechanism that necessitates rehashing the
hash tables at the right time.  I would suggest that any hashing facility
involving EQ or EQL for some subset of Lisp objects be left to the system.  I
really don't think much functionality is lost this way, although I know it's
very easy to dream up examples which "need" such a feature.

2. The user-supplied hashing function (why not call it :hash instead of
:equivalencing?) will probably want to avoid running into bignum arithmetic and
so forth.  The manual should at least mention this danger when describing this
feature.

3. Some implementations may have tense routines for computing a hash code for
certain objects.  String hashing is microcoded on the Perq, and assembly-coded
on other Spice Lisp-derived systems, for example.  A user can get to this
particular routine via SXHASH, but that might not be the case for other hash
functions.  Should all specialized, system-supplied, hashing functions be
implementation specific, and documented in the appropriate places?  I guess
that would work.

4. Regarding SXHASH on circular structures: Might there be optional arguments
to SXHASH to restrict the "length" and "depth" it will descend into an object?
These would default to some "reasonable" implementation-dependent values.  One
Spice Lisp application (a spelling checker that lives inside the editor) dives
straight into the microcode to compute the hash value of a substring.  This
extension to SXHASH would eliminate non-portabilities like that.

--Skef

∂11-May-85  1404	RWK@SCRC-STONY-BROOK.ARPA 	Macros -> declarations 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 May 85  14:03:43 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 234939; Sat 11-May-85 16:59:15-EDT
Date: Sat, 11 May 85 17:03 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Macros -> declarations
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
cc: Fahlman@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <850510015144.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <850511170339.8.RWK@CROW.SCRC.Symbolics.COM>

    Date: Fri, 10 May 85 01:51 EDT
    From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>

	Date: Wed, 8 May 85 11:53 EDT
	From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>

	Instead of DECLARE forms being allowed to be macros, why not allow the
	forms INSIDE declare forms be macros?  Using macros rather than
	"declaration macros" lets you then use macrolet, and avoids the need for
	any new "DEFDECLARE" special forms to document or implement.

    No, this is too confusing. What about things like STRING which are already functions?
    Do we propose to have macro syntax available in a context where function syntax is not?
    I think that would be very confusing. 

It certainly would be confusing to define a declaration named STRING,
since there's already a function of that name.  In our system, you'd
get redefinition warnings.  Why not call it STRING-DECL?  How is this
any more confusing than any other naming conflict?

					  Also, what if someone did

    (DEFMACRO TYPE (X) `(PRINT ,X))

    and then someone else did (DECLARE (TYPE LIST FOO)). You wouldn't want to tell people
    that the possible declaration names (which are all really good names) weren't available
    to them for definition as names for macros (but -were- available to them as function
    names)... would you?

No, of course not.  I see no reason why DECLARE should macroexpand things
it already understands.  To do so would be to allow gratiutous confusion,
such as this.

	1)  Allow (DECLARE (FOO X) ((SPECIAL X) (FIXNUM X))) to mean the
	same as (DECLARE (FOO X) (SPECIAL X) (FIXNUM X))

	2)  Allow (DECLARE (FOO X) (DECLARE (SPECIAL X) (FIXNUM X))).  I.e.
	Allow DECLARE as a declaration containing declarations.

    Yuck.

Hey, remember that this is the expanded output of a macro, not
something that you write in your code.  I think the macro definition
ends up looking pretty obvious, and besides, the compiler is likely
to give you a useful error message if you put one of these macros
in an inappropriate place.

    (DEFMACRO DEF-MY-MACRO (NAME BVL &BODY FORMS)
      `(DEFMACRO ,NAME ,BVL
	 (MAKE-MY-ENCAPSULATION (PROGN ,@FORMS))))

    must be rewritten as

    (DEFMACRO DEF-MY-MACRO (NAME BVL &BODY FORMS &ENVIRONMENT ENV)
      (MULTIPLE-VALUE-BIND (BODY DECLARATIONS DOCUMENTATION)
	  (PARSE-BODY FORMS)
	`(DEFMACRO ,NAME ,BVL
	   ,@DECLARATIONS ,DOCUMENTATION
	   (MAKE-MY-ENCAPSULATION (PROGN ,@BODY)))))

    I just don't see this as a big deal.

I don't, either, since you need that, regardless of whether
or not macros can expand into DECLARE's.  However, thinking
of humans, I have to say that I don't like macros expanding
into entire DECLARE forms because it gets in the way of my
adding my own declaration, and because *I* might not recognize
something as a declaration.  I'm not too worried about it
being "too hard" for programs to handle.

I believe that DECLARE is already structural, rather than
an operator, and that allowing macros to expand into it
merely confuses that issue.

The other reason I proposed making them macros is so that
MACROLET could be used.  Most of the uses I can think of
would be to allow declarations inside of calls to macros,
where MACROLET would be just the right thing to define
any declarations.

    Since it is so idiomatic, though, how about if &BODY did the declaration
    parsing if you gave it a list of vars instead of a symbol var. Eg,

    (DEFMACRO DEF-MY-MACRO (NAME BVL &BODY (BODY DECLS DOC))
      `(DEFMACRO ,NAME ,BVL
	 ,@DECLS ,DOC
	 (MAKE-MY-ENCAPSULATION (PROGN ,@BODY))))

This (and its varients I omit for brevity) is a very interesting
suggestion, and is worth of discussion independently of of the
declaration/macro issue.

∂11-May-85  2300	TIM@MIT-MC 	Macros -> declarations 
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 11 May 85  22:59:24 PDT
Date: Sun, 12 May 85 01:58:19 EST
From: Tim McNerney <TIM@MIT-MC>
Subject:  Macros -> declarations
To: common-lisp@SU-AI
Message-ID: <[MIT-MC].498921.850512.TIM>

    Date: Fri, 10 May 85 01:51 EDT
    From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>

    	Date: Wed, 8 May 85 11:53 EDT
    	From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>

    	Instead of DECLARE forms being allowed to be macros, why not allow
    	the forms INSIDE declare forms be macros?  Using macros rather than
    	"declaration macros" lets you then use macrolet, and avoids the need
    	for any new "DEFDECLARE" special forms to document or implement.

    No, this is too confusing. What about things like STRING which are
    already functions?  Do we propose to have macro syntax available in a
    context where function syntax is not?  I think that would be very
    confusing.

IFF we have to flush macros -> declarations, I think Kerns' user-extensible
DECLARE is the most palatable suggestion so far.  Unfortunately, there are a
number of problems with allowing macros inside of DECLARE, and indeed with
nearly any user-extensible DECLARE.

Perhaps the biggest problem is that the namespace available for use as
declaration names has already been "given away."  The sort naming conflict
that KMP bought up could be solved by having a declarations package which
does not use the LISP package, but CL implementations are free to use any
names not explicitly mentioned in CLTL for implementation-dependent
declarations.  Thus, allowing macros inside of DECLARE could potentially
reduce the portability of code that used this proposed feature.

Whereas

  (declare-private-specials) -> (declare (special *foo* *bar*))

would pose no problems with portability, 

  (declare (private-specials)) -> (declare (special *foo* *bar*))

might conflict with an existing PRIVATE-SPECIALS declaration specific to a
given target implementation (unless the user is allowed to override
implementation-dependent declaration names with his own, yuk!).

I vote for keeping macros -> declarations and augmenting the language 
with a set a standard tools for keeping hairy macro writers out of trouble.

∂12-May-85  0550	GJC@MIT-MC 	hash table types  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 12 May 85  05:50:31 PDT
Date: Sun, 12 May 85 08:51:09 EST
From: George J. Carrette <GJC@MIT-MC>
Subject:  hash table types
To: DCP@SCRC-QUABBIN
cc: TIM@MIT-MC, COMMON-LISP@SU-AI
In-reply-to: Msg of Thu 9 May 85 12:01 EDT from David C. Plummer in disguise <DCP at SCRC-QUABBIN.ARPA>
Message-ID: <[MIT-MC].499100.850512.GJC>

We figured that fixing the root of the problem, the lack of canonicalization
in the hardware database would possibly cost enough time to break a production
development window and put off the introduction of a new hardware item
for a few months, with possible losses in sales of a million dollars
or more for the year. Given this sort of lossage mode one cant stress
enough the importance of having *some* way of getting compatibility
between RELEASE N and RELEASE N+1. Remember that at some time
in "zetalisp" EQUAL on type STRING meant STRING-EQUAL, which was for
better or worse case insensitive. LMI release 2 and presumably also
Symbolics release 6 does away with this. If there is nothing available
which behaves in exactly the same way as the *old* EQUAL-HASH-TABLE
then people can be screwed badly. Remember also that many ugly things
that were left in Common-Lisp from maclisp days (such as the empty
list being a SYMBOL, making the set of all lists and all symbols
have a non-null intersection) were justified soley on the basis that
there was no *automatic* way for people to detect if they were depending
on such lossage and convert their programs. To quote Dave Moon:
"Our customers just wont stand for it." 

-gjc

∂12-May-85  1225	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: defconstant vs. lexical variables
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 12 May 85  12:25:23 PDT
Date:  Sun, 12 May 85 15:17 EDT
From:  Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject:  Re: defconstant vs. lexical variables
cc:  common-lisp@SU-AI.ARPA
In-Reply-To:  Message of 6 May 85 15:40 EDT from "OLDMAN at USC-ISI"
Message-ID:  <850512191735.970989@MIT-MULTICS.ARPA>

    Date:  6 May 1985 15:40 edt
    From:  OLDMAN at USC-ISI
    Subject:  defconstant vs. lexical variables

    Page 69 of the CLM states:

    "Once a name has been declared by defconstant to be constant, any
    further assignment to or binding of that special variable is an
    error.  ...  A compiler may also choose to issue warnings about
    bindings of the lexical variable of the same name."

    Question: How can I make a lexical binding of the thing if it's
    implicitly proclaimed special by the defconstant?

    Alternate question: Why don't we have a way of declaring
    something locally lexical?

    --Dan Oldman {Data General}



Answer:
    (defun foo (lex-x) ...)

    (proclaim '(special lex-x))    ; Compiler should warn me
                                   ; when it hits this statement.

Alternate answer:
    I don't know.  I think we should also.  Until then, one should
    stick to the convention of surrounding special vars. with *'s.
    This should reduce the chance of unknowingly using a var. that
    has been proclaimed special.

∂12-May-85  1748	hoey@nrl-aic 	Re: EQUALP hash tables (and more ...)    
Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 12 May 85  17:47:59 PDT
Date: 12 May 1985 19:12:56 EDT (Sun)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: EQUALP hash tables (and more ...) 
To: Wholey@CMU-CS-C.ARPA, Fahlman@CMU-CS-C.ARPA, Common-Lisp@SU-AI
Message-Id: <484787577/hoey@nrl-aic>
In-Reply-To: Msg of 11 May 1985  15:29 EDT from Skef Wholey and
	     Msg of 11 May 1985  10:59-EDT from Scott E. Fahlman

Skef,

I was about to bring up the problem you mentioned:
    ``I don't think it's possible to let users write some form of hashing
    function that generates = numbers for EQ objects.''
but then I noticed that the language already provides a mechanism for
writing a perfect EQ hashing function:

    (DEFVAR *EQ-HASH-TABLE* (MAKE-HASH-TABLE :TEST #'EQ))
    (DEFVAR *EQ-HASH-COUNTER* 0)

    (DEFUN EQHASH (X)
      (OR (GETHASH X *EQ-HASH-TABLE*)
	  (SETF (GETHASH X *EQ-HASH-TABLE*) (INCF *EQ-HASH-COUNTER*))))

It is a pity that there's no way to let the GC collect stuff out of the
*EQ-HASH-TABLE* for fear of breaking MAPHASH.  Maybe there should be
some way of declaring a hash table GC-able, perhaps by declaring it
un-MAPHASH-able.

Dan

∂12-May-85  2030	FAHLMAN@CMU-CS-C.ARPA 	EQUALP hash tables (and more ...)    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 May 85  20:30:38 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 12 May 85 23:30:34-EDT
Date: Sun, 12 May 1985  23:30 EDT
Message-ID: <FAHLMAN.12110566837.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Dan Hoey <hoey@NRL-AIC.ARPA>
Cc:   Common-Lisp@SU-AI.ARPA
Subject: EQUALP hash tables (and more ...) 
In-reply-to: Msg of 12 May 1985  19:12-EDT from Dan Hoey <hoey at nrl-aic.ARPA>


    ...
    but then I noticed that the language already provides a mechanism for
    writing a perfect EQ hashing function:

        (DEFVAR *EQ-HASH-TABLE* (MAKE-HASH-TABLE :TEST #'EQ))
        (DEFVAR *EQ-HASH-COUNTER* 0)

        (DEFUN EQHASH (X)
          (OR (GETHASH X *EQ-HASH-TABLE*)
    	  (SETF (GETHASH X *EQ-HASH-TABLE*) (INCF *EQ-HASH-COUNTER*))))

So I guess the point is that given magic EQ and EQL hashtables that work
even when a GC moves things, you can use these to build a slower version
of EQ and EQL hashtables (and related thingies) that also works, without
giving the users direct access to the magic.  Interesting in principle,
but not the way you'd want to do anything real.

By allowing the user to specify at hashtable creation time whether his
hashing function at some level makes use of something that amounts to an
address pointer (and which will therefore need to be fixed after a
copying GC mangles things), we allow the user to win without having to
make hashtable references in the course of his comparison.

-- Scott

∂13-May-85  0905	JLW  	YARIM and the adbmal example 
To:   bsg@SCRC-STONY-BROOK.ARPA
CC:   common-lisp@SU-AI.ARPA  

Re: your message of 10-May-85 14:39 EDT

Not only is your adbmal example "right", but the following would have to
work too
(defmacro mumble (x) `(lambda (,x) (list ,x)))
(defun foo () ((mumble z) (mumble z)))
I just tried this out in pdp10 maclisp, and it still sort of works [I 
remember putting this hac in about 1979 or 1980, and it wasn`t all
that well received even back then].


Incidentally, I did take your suggestion for macro-expansion contexts
seriously.  Not that I approve of going al the way for it, but you do
bring into focus the fact that several different kinds of processing
are going on during interpretations -- not just EVAL alone, but there
is FUNVAL (if you will) to fetch the function part, there is DODECLS
to add to a declarations database [Maclisp had a functional counterpart
to DECLARE, which is why macroexpansion seemed like such a natural idea
there], and there is lambda-list parsing.  I'd prefer to see a uniform
meta-expansion syntax -- such as defmacro -- but we may have to consider
context as per your suggestion.

-- JonL --

∂13-May-85  0919	BSG@SCRC-STONY-BROOK.ARPA 	:-(
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 May 85  09:12:30 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 235635; Mon 13-May-85 12:07:49-EDT
Date: Mon, 13 May 85 12:13 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: :-(
To: Fahlman@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12110152717.BABYL@CMU-CS-C.ARPA>
Message-ID: <850513121344.4.BSG@CONCORD.SCRC.Symbolics.COM>

    Date: Sat, 11 May 1985  09:35 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>


    Upon reflection, I shouldn't have been so flippant in dismissing BSG's
    suggestion about macro-expansion environments, and I apologize to him.

Thankyou.  I thought your assessment was in fact unduly harsh.  The
criteria for judging this kind of suggestion should include, "Does it
solve the problem?" "Does it create new problems?"  "Does it bother
things other than the thing it was designed to address?" "Given that it
addresses some hairy need, will you have to deal with it unless you have
that hairy need?"  "Is it consistent in design and philosophy with the
rest of the language?"  "Is it straightforward to explain?" "Is
efficient implementation obvious?"  I think that the general idea
of my suggestion meets these (admittedly self-supplied) criteria.

    I assume that his suggestion was serious, and poking fun at suggestions
    that we disagree with is obviously not the best way to promote the free
    flow of ideas.  It has been a long week, and I was feeling irritable.
Thankyou.  I hope you feel better.
    I think that this suggestion is a step in the wrong direction.  We want
    to make the whole issue of macros expanding in funny places less
    confusing, not more so, and a multiple name space mechansism so that
    macros in various places can have the same name doesn't look to me like
    a good idea.
(what follows is sort of rambling...)

Any better than the "declaration 'functions'" (like STRING in the
preceding conversation) having the same name as a real function?   Why
isn't the set of those things extensible?  Remember in MacLisp they
actually WERE functions?  I suppose macros there worked! I wonder if
anyone actually ever exploited that!

But now we are above that, and we have asserted that the declaration
namespace is in fact divorced from the function namespace.  There
already -is- this multiple namespace.  As there should be.  Why isn't a
macro paradigm within that namespace reasonable?  OK, don't use
defmacro, say
  (putprop 'my-decl #'my-decl-expander :declaration-macro) for all I care,
if my syntax is too bizarre.  It seems as though it's that very capability
that you don't like.  

I would like to dredge up an elegant feature of LAP (remember those?) on
Multics, which, if it encountered a symbol marked as a Lisp Macro
name-symbol, as the CAR of an instruction specification, it would apply
the macro-function to the instruction specification, and assemble the
returned list of instructions in place.

This is a typical, potent, and elegant use of "the Lisp Macro concept"
to extend operator sets embedded in the Lisp Language.  -Surely-, if I
had thought along these lines back then, we would have some different
kind or option of DEFMACRO (which didn't even exist per se) for defining
LAP macros in this way.

DEFMACRO provides three things for you:
  1) A way to define a -LISP FUNCTION- to be called by the evaluator
     and compiler at certain highly specific times and contexts.
  2) A way to define a Lisp function of one argument which has
     built-in syntactic shorthands for destructuring and structure-verifying
     that argument.
  3) A -conceptual- ability, a paradigm, for extension of the language via
     transformation of code fragments.

2 & 3, esp. 3, are obviously, by the cited examples, useful in a wide,
extensible variety of contexts other than "evaluation/compilation of
Lisp forms".  Clearly, I can put in replacements for (1) (e.g., DEFLAPMACRO)
all I want, in any program I want (does this invoke your objection of
"macros expanding in funny places?").  There is nothing in the language
to prevent me, or even discourage me from doing this.  In fact,
I think it is something to encourage.

Having said that, why is the notion of the Language providing hooks of
-some kind- for extensibility via transformation (a euphemism, if you like),
at other points where the symbol CAR of a form is significant (e.g., LAMBDA,
declarations, type specs.....) not reasonable?

∂13-May-85  0930	BSG@SCRC-STONY-BROOK.ARPA 	YARIM and the adbmal example     
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 May 85  09:21:11 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 235644; Mon 13-May-85 12:16:32-EDT
Date: Mon, 13 May 85 12:22 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: YARIM and the adbmal example 
To: JLW@SU-AI.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 13 May 85 12:05-EDT from Jon White <JLW@SU-AI.ARPA>
Message-ID: <850513122226.5.BSG@CONCORD.SCRC.Symbolics.COM>

    Date: 13 May 85  0905 PDT
    From: Jon White <JLW@SU-AI.ARPA>


    Re: your message of 10-May-85 14:39 EDT

    Not only is your adbmal example "right", but the following would have to
    work too
    (defmacro mumble (x) `(lambda (,x) (list ,x)))
    (defun foo () ((mumble z) (mumble z)))
    I just tried this out in pdp10 maclisp, and it still sort of works [I 
    remember putting this hac in about 1979 or 1980, and it wasn`t all
    that well received even back then].


    Incidentally, I did take your suggestion for macro-expansion contexts
    seriously.  Not that I approve of going al the way for it, but you do
    bring into focus the fact that several different kinds of processing
    are going on during interpretations -- not just EVAL alone, but there
    is FUNVAL (if you will) to fetch the function part, there is DODECLS
    to add to a declarations database [Maclisp had a functional counterpart
    to DECLARE, which is why macroexpansion seemed like such a natural idea
    there], and there is lambda-list parsing.  I'd prefer to see a uniform
    meta-expansion syntax -- such as defmacro -- but we may have to consider
    context as per your suggestion.
You got it. That is exactly what I just said to Scott.  Each of these
contexts should be identified separately, via a uniform mechanism.
That would fix ((mumble z) (mumble z)), i.e., make it -not- work.

∂13-May-85  1144	DCP%TENEX.SCRC@MIT-XX.ARPA 	hash table types 
Received: from MIT-XX.ARPA by SU-AI.ARPA with TCP; 13 May 85  11:44:01 PDT
Received: by MIT-XX via Chaosnet; 13 May 85 14:38-EDT
Date: Sunday, 12 May 1985  10:56-EDT
From: David C. Plummer <DCP at SCRC-TENEX>
To:   George J. Carrette <GJC at MIT-MC>
Subject:  hash table types
cc:   DCP at SCRC-QUABBIN, TIM at MIT-MC, COMMON-LISP at SU-AI
In-rely-to: <[MIT-MC].499100.850512.GJC>

    Date: Sun, 12 May 85 08:51:09 EST
    From: George J. Carrette <GJC@MIT-MC>

    We figured that fixing the root of the problem, the lack of
    canonicalization in the hardware database would possibly cost
    enough time to break a production development window and put
    off the introduction of a new hardware item for a few months,
    with possible losses in sales of a million dollars or more
    for the year. Given this sort of lossage mode one cant stress
    enough the importance of having *some* way of getting
    compatibility between RELEASE N and RELEASE N+1. Remember
    that at some time in "zetalisp" EQUAL on type STRING meant
    STRING-EQUAL, which was for better or worse case insensitive.
    LMI release 2 and presumably also Symbolics release 6 does
    away with this. If there is nothing available which behaves
    in exactly the same way as the *old* EQUAL-HASH-TABLE then
    people can be screwed badly. Remember also that many ugly
    things that were left in Common-Lisp from maclisp days (such
    as the empty list being a SYMBOL, making the set of all lists
    and all symbols have a non-null intersection) were justified
    soley on the basis that there was no *automatic* way for
    people to detect if they were depending on such lossage and
    convert their programs. To quote Dave Moon: "Our customers
    just wont stand for it."

For that exact reason, "Our customers just won't stand for it",
Release 6 is compatible with Release 5 w.r.t. EQUAL-HASH-TABLEs,
i.e., case is ignoreed.  Release 6 provides hints on how to write
code that will work in both Release 6 and Release 7, requiring
recompilation and possibly minimal, if any conversion.  In
Release 7 there will most likely be a CASE-INSENSITIVE-HASH-TABLE
that uses CASE-INSENSITIVE-EQUAL as the predicate and
CASE-INSENSITIVE-EQUAL-HASH (unless EQUAL-HASH will continue to
ignore case).

More generally, and on the generic issue: Symbolics has had
generic hash tables for quite a while.  I don't know if Lisp
Machine Lisp is general has.  The definer of the hash table is
required to write two methods, the equality predicate and the
hash function.  They are quite useful.  All implementations must
do a dispatch, since the entrypoints are the same for all types
of hash tables.  In a flavor-based implementation, the dispatch
happens at the message send level.  In other implementations, my
guess is that FUNCALL is used where the function comes from some
defstruct slot.  In any case, generalizing does not appear to be
a hard thing to implement.

The external things I see needing changing are
 * An additional argument to make-hash-table.  My vote for a name
   is :hash-function.
 * If the hash function is not provided, it defaults from the
   predicate. 
 * It is an error not to supply a hash function if the predicate
   is not one of those builtin (currently, EQ, EQL and EQUAL).
   [Implementatyions may supply more builtins and opt not to
   signal the error.]
 * Requirements of the hash function: It must return an integer,
   possibly restricted to fixnum, possibly required to be
   positive.  [The LispM builtin hash functions attempt to return
   positive fixnums that use as many bits as possible.  This is
   so that there is more uniform distribution after it is MODed
   with the hash table modulus.]
 * Hints on how to write implementation independent, efficient
   hash functions.  This is the hardest part.  Maybe there are
   enough constants defined in the language to make this possible
   (e.g., bits-per-fixnum, etc).  Hmmm... Many LispM hash
   functions use the functions ROT (better called ROTATE-FIXNUM)
   and LSH (better called LOGICAL-SHIFT-FIXNUM).  They often use
   LOGXOR, but this is part of CLtL.  I have a memory of being
   told that ROT and LSH were consciously not part of the CL
   language because they weren't mathematical.  With names like
   ROTATE-FIXNUM and LOGICAL-SHIFT-FIXNUM maybe they should be
   put back?  [Also see Turing's biography about the hardware
   designers diking out his boolean instructions for similar
   reasons.] 
 * The use of MAKNUM, %POINTER or

∂13-May-85  1145	DCP%TENEX.SCRC@MIT-XX.ARPA 	hash table types 
Received: from MIT-XX.ARPA by SU-AI.ARPA with TCP; 13 May 85  11:44:50 PDT
Received: by MIT-XX via Chaosnet; 13 May 85 14:41-EDT
Date: Sunday, 12 May 1985  10:56-EDT
From: David C. Plummer <DCP at SCRC-TENEX>
To:   George J. Carrette <GJC at MIT-MC>
Subject:  hash table types
cc:   DCP at SCRC-QUABBIN, TIM at MIT-MC, COMMON-LISP at SU-AI
In-rely-to: <[MIT-MC].499100.850512.GJC>

    Date: Sun, 12 May 85 08:51:09 EST
    From: George J. Carrette <GJC@MIT-MC>

    We figured that fixing the root of the problem, the lack of
    canonicalization in the hardware database would possibly cost
    enough time to break a production development window and put
    off the introduction of a new hardware item for a few months,
    with possible losses in sales of a million dollars or more
    for the year. Given this sort of lossage mode one cant stress
    enough the importance of having *some* way of getting
    compatibility between RELEASE N and RELEASE N+1. Remember
    that at some time in "zetalisp" EQUAL on type STRING meant
    STRING-EQUAL, which was for better or worse case insensitive.
    LMI release 2 and presumably also Symbolics release 6 does
    away with this. If there is nothing available which behaves
    in exactly the same way as the *old* EQUAL-HASH-TABLE then
    people can be screwed badly. Remember also that many ugly
    things that were left in Common-Lisp from maclisp days (such
    as the empty list being a SYMBOL, making the set of all lists
    and all symbols have a non-null intersection) were justified
    soley on the basis that there was no *automatic* way for
    people to detect if they were depending on such lossage and
    convert their programs. To quote Dave Moon: "Our customers
    just wont stand for it."

For that exact reason, "Our customers just won't stand for it",
Release 6 is compatible with Release 5 w.r.t. EQUAL-HASH-TABLEs,
i.e., case is ignoreed.  Release 6 provides hints on how to write
code that will work in both Release 6 and Release 7, requiring
recompilation and possibly minimal, if any conversion.  In
Release 7 there will most likely be a CASE-INSENSITIVE-HASH-TABLE
that uses CASE-INSENSITIVE-EQUAL as the predicate and
CASE-INSENSITIVE-EQUAL-HASH (unless EQUAL-HASH will continue to
ignore case).

More generally, and on the generic issue: Symbolics has had
generic hash tables for quite a while.  I don't know if Lisp
Machine Lisp is general has.  The definer of the hash table is
required to write two methods, the equality predicate and the
hash function.  They are quite useful.  All implementations must
do a dispatch, since the entrypoints are the same for all types
of hash tables.  In a flavor-based implementation, the dispatch
happens at the message send level.  In other implementations, my
guess is that FUNCALL is used where the function comes from some
defstruct slot.  In any case, generalizing does not appear to be
a hard thing to implement.

The external things I see needing changing are
 * An additional argument to make-hash-table.  My vote for a name
   is :hash-function.
 * If the hash function is not provided, it defaults from the
   predicate. 
 * It is an error not to supply a hash function if the predicate
   is not one of those builtin (currently, EQ, EQL and EQUAL).
   [Implementatyions may supply more builtins and opt not to
   signal the error.]
 * Requirements of the hash function: It must return an integer,
   possibly restricted to fixnum, possibly required to be
   positive.  [The LispM builtin hash functions attempt to return
   positive fixnums that use as many bits as possible.  This is
   so that there is more uniform distribution after it is MODed
   with the hash table modulus.]
 * Hints on how to write implementation independent, efficient
   hash functions.  This is the hardest part.  Maybe there are
   enough constants defined in the language to make this possible
   (e.g., bits-per-fixnum, etc).  Hmmm... Many LispM hash
   functions use the functions ROT (better called ROTATE-FIXNUM)
   and LSH (better called LOGICAL-SHIFT-FIXNUM).  They often use
   LOGXOR, but this is part of CLtL.  I have a memory of being
   told that ROT and LSH were consciously not part of the CL
   language because they weren't mathematical.  With names like
   ROTATE-FIXNUM and LOGICAL-SHIFT-FIXNUM maybe they should be
   put back?  [Also see Turing's biography about the hardware
   designers diking out his boolean instructions for similar
   reasons.] 
 * The use of MAKNUM, %POINTER or whatever it is for a particular
   implementation is to be forbidden for user suplied hash
   functions.  This is because the GC can move objects and change
   their addresses, and there is no way in CL to communicate this
   between the hash table and the GC.  Individual implementations
   may wish to implement such a communication and allow %POINTER
   and use it for builtin hash tables to improve efficiency.

Conclusion: generic hash tables are useful and probably simple to
implement.  User supplied hash functions are required but
difficult.

Additionaly, I think there should be a CASE-INSENSITIVE-EQUAL
function and a corresponding (builtin) hash table type.  I have
an uneasy feeling about EQUALP hash tables.  I think the
uneasiness comes in the traversing of arbitrary array structure
that EQUALP implies and the possible inefficiency.  The example
needs I have so far seen for EQUALP are dealt with by
CASE-INSENSITIVE-EQUAL.

∂14-May-85  0905	KESSLER@UTAH-20.ARPA 	&optional with &key    
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 14 May 85  09:05:42 PDT
Date: Tue 14 May 85 10:05:01-MDT
From: Robert R. Kessler <KESSLER@UTAH-20.ARPA>
Subject: &optional with &key
To: common-lisp@SU-AI.ARPA

If you provide an &optional followed by &key's, does that mean that
the &optional becomes required?  The examples don't seem to address the
case:

 ((lambda (a &optional (b 3) &key c (d a))
     (list a b c d x))
  1 :c 7)

Is this an error (i.e. a is bound to 1, b is bound to :c and 7 causes
the error), or is a bound to 1, b bound to 3, c to 7 and d to 1.

Bob.
-------

∂14-May-85  0933	gls@AQUINAS.ARPA 	&optional with &key   
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 14 May 85  09:33:08 PDT
Received: by THINK.ARPA with CHAOS id AA23862; Tue, 14 May 85 12:24:51 edt
Date: Tue, 14 May 85 12:25 EDT
From: Guy Steele <gls@AQUINAS.ARPA>
Subject: &optional with &key
To: kessler%utah-20@GODOT.ARPA
Cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.ARPA
In-Reply-To: Your message of 14 May 85 12:05-EDT
Message-Id: <850514122500.1.GLS@DESIDERIUS.ARPA>

It isn't quite accurate to say that the presence of &key makes an
&optional parameter be required.  It is true, however, that, if a
function has both &optional and &key parameters, it is impossible to
specify explicit arguments for any keyword parameters unless arguments
are first explicitly given for all optional parameters.  The book
doesn't say so in one sentence, but you can deduce this from careful
reading of page 61.  I agree that an explicit statement of this fact
would be worthwhile, and that an example would be useful.
--Guy

∂14-May-85  1002	RWK@SCRC-STONY-BROOK.ARPA 	&optional with &key    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 14 May 85  10:02:23 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 236361; Tue 14-May-85 12:57:41-EDT
Date: Tue, 14 May 85 13:02 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: &optional with &key
To: Robert R. Kessler <KESSLER@UTAH-20.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 14 May 85 12:05-EDT from Robert R. Kessler <KESSLER@UTAH-20.ARPA>
Message-ID: <850514130227.0.RWK@CROW.SCRC.Symbolics.COM>

    Date: Tue 14 May 85 10:05:01-MDT
    From: Robert R. Kessler <KESSLER@UTAH-20.ARPA>

    If you provide an &optional followed by &key's, does that mean that
    the &optional becomes required?  The examples don't seem to address the
    case:

     ((lambda (a &optional (b 3) &key c (d a))
	 (list a b c d x))
      1 :c 7)

    Is this an error (i.e. a is bound to 1, b is bound to :c and 7 causes
    the error), or is a bound to 1, b bound to 3, c to 7 and d to 1.
    -------

It is an error (i.e. A is bound to 1, B is bound to :C and 7 causes
the error).  However, that is not the same as B being required!
All it means is that the keyword arguments start AFTER B.  This
implies that you have to supply B in order to supply C or D, but
that's true in (a &optional (b 3) c (d a)), too.

∂14-May-85  1655	REM@IMSSS 	Semantic question about closures  
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-May-14 15:55:04 PST (=GMT-8hr)
Date: 1985 May 14 15:54:28 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132167250130.G0353
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To: Common-LISP@SU-AI
Subject: Semantic question about closures
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up)

I have a question about closures in CL. When a closure is made, with
some variable encapsulated in the closure, is that variable accessible
only with the exact function that was closed (thus somehow a copy of
the gut function must be made such that it internally references that
closure-cell directly rather than how the gut function in vacuuo would
reference that named variable), or is that variable accessible also
from any function called by the closure (thus we can implement a
closure by fluid-binding the closure-variable as we pass from the
closure into the gut function and copying the final value of the
fluid-binding back into the closure-cell when returning)? I.e. if
function A binds special X to some initial value, makes a closure of B
with free variable X referring to A's fluid-binding of X, then
lambda-binds X another level deep to a new value, then calls
B-closure, obviously references to X within B-closure will get the
first binding of X, but if B calls C which also refers to free
variable X does C get the closure-of-first-binding-of-X inherited from
closure-B or does C get the second-fluid-binding-of-X inherited
directly from A skipping over B?

∂14-May-85  1858	RAM@CMU-CS-C.ARPA 	Semantic question about closures    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 14 May 85  18:58:32 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Tue 14 May 85 21:58:40-EDT
Date: Tue, 14 May 1985  21:58 EDT
Message-ID: <RAM.12111074390.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   REM%IMSSS@λSU-SCORE.ARPA (temporary until nameservers up)λ
Cc:   Common-LISP@SU-AI.ARPA
Subject: Semantic question about closures
In-reply-to: Msg of 1985 May 14 15:54:28 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.SU.EDU>

    Date: 1985 May 14 15:54:28 PST (=GMT-8hr)
    From: Robert Elton Maas <REM at IMSSS.SU.EDU>
    Re:   Semantic question about closures

    When a closure is made, with some variable encapsulated in the
    closure, is that variable accessible only with the exact function
    that was closed (...), or is that variable accessible also from any
    function called by the closure...

The value is not visible.  This is exactly what lexical scoping means.
A variable DOES NOT EXIST outside of code textually enclosed by the
binding form.  You shouldn't worry about closures when trying to
understand lexical variables--- closures are just an implementation
detail.

I think that you are confusing yourself by talking about "free
variables"; this is not a very useful concept in Common Lisp.  Instead
you should think in terms of special variables and lexical variables.
Special variables and lexical variables have very different semantics,
and the language has possibly done a disservice by making them appear
to be similar.

The operation of "binding" a lexical variable is quite unlike that of
binding a special.  Binding a lexical variable actually creates a new
"variable" which is then associated with that name within the lexical
scope.  By a "variable", I mean a nameless memory location which can be
used for storing a value.  The fact that some variables can be stack
allocated is unimportant for understanding what a piece of code does.

The reason that the called function in your example cannot see the
original variable is that its variable is totally different from the
one in the calling function, although it does happen to have the same
name.  The fact that it has the same name is totally irrelevant,
since the association of name with variable does not exist outside of
the lexical context in which the variable was created.

It is important to draw the distinction between variables and names.
This may be difficult for people whose primary experience is with
old-fashioned shallow/special-binding lisps, since in these
implementations there is a one-to-one correspondence between variables
(value cells) and names (symbols).

   (thus somehow a copy of the gut function must be
    made such that it internally references that closure-cell directly
    rather than how the gut function in vacuuo would reference that
    named variable)

Your parenthetical inference is incorrect, however.  There is no "gut
function" to copy.  The compiler must determine at compile time
whether it is going to close over a variable.  If it decides to close
over variables, it compiles code to access closure variables.  Lexical
variable references do not exist "in vacuo".  A lexical variable is
created when it is bound.

    I.e. if function A binds special X to some initial value, makes a
    closure of B with free variable X referring to A's fluid-binding
    of X, ...

Special variables are not closed over.  The meaning of a special
variable reference is "give me the most recent binding in my current
dynamic context."  This is incompatible with the notion of closing
over variables.

  Rob

∂14-May-85  2103	WHOLEY@CMU-CS-C.ARPA 	Apply-But-Last    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 14 May 85  21:02:53 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Wed 15 May 85 00:03:04-EDT
Date: Wed, 15 May 1985  00:02 EDT
Message-ID: <WHOLEY.12111097035.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To:   Common-Lisp@SU-AI.ARPA
Subject: Apply-But-Last

    From: vanroggen@DEC-HUDSON
    Subject: SETF APPLY ...

    It seems to me that we could have both the newvalue passed as the
    last arg of the setting function and the ability to do SETF of
    APPLY if we would admit to a function, that I'll call APPLY-BUT-LAST,
    that's just like APPLY, except that it's the next-to-last argument
    that must be a list, and the last argument is just passed as the
    last argument to the applied function.

That name is misleading (too much in common with some list manipluation
functions), and the effect can be obtained portably (and reasonably efficiently
(even with dumb compilers)) with Multiple-Value-Call:

	(multiple-value-call #'function arg1 arg2 ...
			     (values-list rest-arg)
			     last-arg)

--Skef

∂15-May-85  1221	REM@IMSSS 	Another question about lexical closures
Received: from IMSSS by SU-AI with PUP; 15-May-85 12:20 PDT
Date: 15 May 1985 0213-PDT
From: Rem@IMSSS
Subject: Another question about lexical closures
To:   COMMON-LISP@SU-AI

There's a little ambiguity about when two bindings are "the same" and when
they are "different" bindings. If you bind exactly the same lexical variable
(in the same function or other executable form) to exactly the same value
(the values are EQ), at two different times, are the two bindings you get
considered to be the same or different? I.e. if you make a lexical closure
in function FOO with X bound to NIL and then make another lexical closure
in function FOO with X bound to NIL, will the X-variables in those two
closures be the same variable (sharing side-effects) or not? My guess
is they will be different, that is each time you go into a lambda-binding
you get a "different" binding even if the lexical variable and its value
are the same both times. Am I correct? (Note the example at the bottom of
page 87 doesn't answer this question since TWO-FUNS is called only once.
If it got called a second time, with exactly the same args, and the result
SETQ'd to global FUNS2, would (CAR FUNS) and (CAR FUNS2) share their
lexical-closure-variable, i.e. "the binding of the variable X created
on entry to the function TWO-FUNS when it was called with argument 6"
as described at the bottom of the page? That phrasing indicates there
WOULD be sharing, but due to what it says on page 37 top "it depends
on the invocaton during which the reference is made" I think it WOULD NOT
be sharing, i.e. wording on page 87 should really say "... on that particular
entry to the function TWO-FUNS ..." even though in that example it is moot
since TWO-FUNS was called only once in the example.)
-------

∂15-May-85  1233	MOON%TENEX.SCRC@MIT-XX.ARPA 	Validation 
Received: from MIT-XX.ARPA by SU-AI.ARPA with TCP; 15 May 85  12:18:26 PDT
Received: by MIT-XX via Chaosnet; 15 May 85 02:40-EDT
Date: Tuesday, 14 May 1985  21:38-EDT
From: MOON at SCRC-TENEX
To:   Dick Gabriel <RPG at SU-AI.ARPA>
Cc:   ohlander at USC-ISI.ARPA, quinquevirate at SU-AI.ARPA,
      squires at USC-ISI.ARPA
Subject: Validation
In-reply-to: The message of 08 May 85  2246 PDT from Dick Gabriel <RPG@SU-AI.ARPA>

    Date: 08 May 85  2246 PDT
    From: Dick Gabriel <RPG@SU-AI.ARPA>

    The point of keeping (some) of the validation code `secret' is to
    make sure that people don't cheat and get exactly the validation
    code to work. I believe that is approximtely owow  ADA is done. 

    I would also be in favor of doing it exactly the way ADA is done:
    have a public validation suite along with a `secret' one. When the
    public one has passed, the public and the private ones are applied
    by the testors. 

I think this idea is totally preposterous!

Until Common Lisp is used as widely as Ada, until Common Lisp is used in
systems on which human life depends, and until as much money is thrown into
Common Lisp as is thrown into Ada, let's not worry so much about setting up
elaborate bureaucracies and complex mechanisms to deal with the possibility
of cheating.  Until Common Lisp is as rigorously defined as Ada, how are
you going to respond to an implementor of a Common Lisp that fails the
secret validation suite who says "My implementation is correct, your
validation suite must be broken.  Show me what it does."?

I believe that it is neither feasible nor desirable to validate Common Lisp
as rigorously as Ada is validated (at present).  We're going to have a hard
enough time doing any validation at all, so let's not burden ourselves with
creating two validation suites and trying to keep one of them secret.

Question of fact: what is the ratio between the calendar 1986 budget for
Ada validation and the calendar 1986 budget for Common Lisp validation?  To
stimulate discussion, I will make an uninformed guess: I believe that the
ratio is between 1,000 and 5,000.  I wouldn't be surprised to learn that my
guess is much too low.  Think about it.

I have no objection to the rest of your proposal.

∂15-May-85  1331	RWK@SCRC-STONY-BROOK.ARPA 	Another question about lexical closures    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 May 85  13:31:39 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 237413; Wed 15-May-85 16:26:05-EDT
Date: Wed, 15 May 85 16:30 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Another question about lexical closures
To: Rem@IMSSS
cc: COMMON-LISP@SU-AI.ARPA
In-Reply-To: The message of 15 May 85 05:13-EDT from Rem@IMSSS
Message-ID: <850515163014.9.RWK@CROW.SCRC.Symbolics.COM>

    Date: 15 May 1985 0213-PDT
    From: Rem@IMSSS

    There's a little ambiguity about when two bindings are "the same" and when
    they are "different" bindings. If you bind exactly the same lexical variable
    (in the same function or other executable form) to exactly the same value
    (the values are EQ), at two different times, are the two bindings you get
    considered to be the same or different? 
The way I think of this is "Two calls to LET produce two different
bindings".  So if I read your question right, the answer is "different".

					    I.e. if you make a lexical closure
    in function FOO with X bound to NIL and then make another lexical closure
    in function FOO with X bound to NIL, will the X-variables in those two
    closures be the same variable (sharing side-effects) or not? 

I assume here you mean two calls to FOO, not something like

(LET ((X 5))
  (VALUES #'(LAMBDA () X) #'(LAMBDA (Y) (SETQ X Y))))

where the answer is "save variable (sharing side effects)"

								 My guess
    is they will be different, that is each time you go into a lambda-binding
    you get a "different" binding even if the lexical variable and its value
    are the same both times. Am I correct? 
Yes.

					   (Note the example at the bottom of
    page 87 doesn't answer this question since TWO-FUNS is called only once.

Indeed, I think this section could use a bit more exposition and further
examples.  I think the manual can't help being a bit of a language
tutorial here, and should abandon the tersness of a reference manual,
even if it ends up repeating the same concept in different ways.

    If it got called a second time, with exactly the same args, and the result
    SETQ'd to global FUNS2, would (CAR FUNS) and (CAR FUNS2) share their
    lexical-closure-variable, i.e. "the binding of the variable X created
    on entry to the function TWO-FUNS when it was called with argument 6"
    as described at the bottom of the page? That phrasing indicates there
    WOULD be sharing, but due to what it says on page 37 top "it depends
    on the invocaton during which the reference is made" I think it WOULD NOT
    be sharing, i.e. wording on page 87 should really say "... on that particular
    entry to the function TWO-FUNS ..." even though in that example it is moot
    since TWO-FUNS was called only once in the example.)
    -------
That's right.  There would be sharing between (CAR FUNS) and (CADR FUNS), and
between (CAR FUNS2) and (CADR FUNS2), but not between the elements of FUNS
and FUNS2.

∂15-May-85  1332	RWK@SCRC-STONY-BROOK.ARPA 	Another question about lexical closures    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 May 85  13:32:17 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 237418; Wed 15-May-85 16:26:43-EDT
Date: Wed, 15 May 85 16:30 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Another question about lexical closures
To: Rem%IMSSS@SU-SCORE.ARPA
cc: COMMON-LISP@SU-AI.ARPA
In-Reply-To: The message of 15 May 85 05:13-EDT from Rem@IMSSS
Supersedes: <850515163014.9.RWK@CROW.SCRC.Symbolics.COM>,
            <850515163043.0.RWK@CROW.SCRC.Symbolics.COM>
Message-ID: <850515163051.1.RWK@CROW.SCRC.Symbolics.COM>

    Date: 15 May 1985 0213-PDT
    From: Rem@IMSSS

    There's a little ambiguity about when two bindings are "the same" and when
    they are "different" bindings. If you bind exactly the same lexical variable
    (in the same function or other executable form) to exactly the same value
    (the values are EQ), at two different times, are the two bindings you get
    considered to be the same or different? 
The way I think of this is "Two calls to LET produce two different
bindings".  So if I read your question right, the answer is "different".

					    I.e. if you make a lexical closure
    in function FOO with X bound to NIL and then make another lexical closure
    in function FOO with X bound to NIL, will the X-variables in those two
    closures be the same variable (sharing side-effects) or not? 

I assume here you mean two calls to FOO, not something like

(LET ((X 5))
  (VALUES #'(LAMBDA () X) #'(LAMBDA (Y) (SETQ X Y))))

where the answer is "save variable (sharing side effects)"

								 My guess
    is they will be different, that is each time you go into a lambda-binding
    you get a "different" binding even if the lexical variable and its value
    are the same both times. Am I correct? 
Yes.

					   (Note the example at the bottom of
    page 87 doesn't answer this question since TWO-FUNS is called only once.

Indeed, I think this section could use a bit more exposition and further
examples.  I think the manual can't help being a bit of a language
tutorial here, and should abandon the tersness of a reference manual,
even if it ends up repeating the same concept in different ways.

    If it got called a second time, with exactly the same args, and the result
    SETQ'd to global FUNS2, would (CAR FUNS) and (CAR FUNS2) share their
    lexical-closure-variable, i.e. "the binding of the variable X created
    on entry to the function TWO-FUNS when it was called with argument 6"
    as described at the bottom of the page? That phrasing indicates there
    WOULD be sharing, but due to what it says on page 37 top "it depends
    on the invocaton during which the reference is made" I think it WOULD NOT
    be sharing, i.e. wording on page 87 should really say "... on that particular
    entry to the function TWO-FUNS ..." even though in that example it is moot
    since TWO-FUNS was called only once in the example.)
    -------
That's right.  There would be sharing between (CAR FUNS) and (CADR FUNS), and
between (CAR FUNS2) and (CADR FUNS2), but not between the elements of FUNS
and FUNS2.

∂15-May-85  1354	STENGER%ti-csl.csnet@csnet-relay.arpa 	adding PARSE-BODY primitive    
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 15 May 85  13:53:56 PDT
Received: from ti-csl by csnet-relay.csnet id am03561; 15 May 85 2:01 EDT
Date: 14 May 1985 1011-CDT
From: Dan Stenger <STENGER%ti-csl.csnet@csnet-relay.arpa>
Subject: adding PARSE-BODY primitive
To: common-lisp@su-ai.ARPA
In-Reply-To: Your message of 6-May-85 1043-CDT
Received: from csl60 by ti-csl; Tue, 14 May 85 10:09 CST

I am all for adding the PARSE-BODY function.  Every implementation has to
have this code in it anyway and since it is generally useful why not
standardize it.

	Dan Stenger
-------

∂15-May-85  1643	J.Dalton%edxa@Ucl-Cs.ARPA 	lexical closures  
Received: from UCL-CS.ARPA by SU-AI.ARPA with TCP; 15 May 85  16:42:36 PDT
Received: from edxa.ac.uk by 44d.Ucl-Cs.AC.UK   via Janet with NIFTP  id a011256;
          16 May 85 0:39 BST
From:        DALTON FHL (on ERCC DEC-10) <J.Dalton%edxa@ucl-cs.arpa>
Date:        Wednesday, 15-May-85 23:06:16-GMT
Message-ID:  <132170-754-714@EDXA>
To:          Common-Lisp <Common-Lisp%su-ai.arpa@ucl-cs.arpa>, 
             J.Dalton%edxa@ucl-cs.arpa
Subject:     lexical closures

--------
Closures ...

   Date: 1985 May 14 15:54:28 PST (=GMT-8hr)
   From: Robert Elton Maas <REM@imsss.su.edu>

   I.e. if function A binds special X to some initial value, makes a
   closure of B with free variable X referring to A's fluid-binding of X,
   then lambda-binds X another level deep to a new value, then calls
   B-closure, obviously references to X within B-closure will get the
   first binding of X,

It turns out that the B-closure will refer to the second (deeper) value of
X, but not because of anything involving closures.  Lexical closures in
Common Lisp do not include special variables [see pp 39-40].  If X is
a special variable, the free X in B will always refer to the most recent
binding of X; lexical closures don't change this.

One reason for the confusion may be that other dialects of Lisp, such as
ZetaLisp and Franz, do provide closures over special variables that work
more or less in the way you describe.

   Date: 15 May 1985 0213-PDT
   From: Rem@imsss
   Subject: Another question about lexical closures

   There's a little ambiguity about when two bindings are "the same" and when
   they are "different" bindings. If you bind exactly the same lexical variable
   (in the same function or other executable form) to exactly the same value
   (the values are EQ), at two different times, are the two bindings you get
   considered to be the same or different?

If you call the same function twice, you get two different bindings (p 36:
"a new binding is established on every invocation").  The text on pages
87-89 seems clear on what this means for closures, particularly the example
in the middle of page 88 (think of each LET as a function call).  Now if
TWO-FUNS were called twice, there would be two different bindings of X, and
closures involving different bindings must be different if the bound values
could be changed by SETQ.  Since the second of them includes a SETQ, the
closures returned in the list must be different each time.  Now if it weren't
for the SETQ, each call to TWO-FUNS would still normally return different
closures because X might have a different value each time.  If two calls
happened to use the same EQ value twice, I don't see anything to guarantee
that the closures would be different (after all, they would be 
"behaviorially identical with respect to invocation"), but would any
implementation notice that they could be the same?

So I think the book is fairly clear, although you might have to reread it
a few times if you aren't already familiar with the stuff involved.

--------

∂01-Jun-85  0859	RPG  	Preposterousness   
To:   quinquevirate@SU-AI.ARPA, ohlander@USC-ISI.ARPA,
      squies@USC-ISI.ARPA  

What happens when an implementor says, ``your test case is wrong,
show me what it does'' is this: we show him (or her) what it does.
There is nothing magic about a `secret' test suite except that 
it encourages people to implement all of the nooks and crannies
rather than exactly the ones in the test suite. To develop a
second test suite, you simply remove a fraction of the original
single one. I presume the point of the public suite is to inform
the implementors of the coverage of the tests. At the moment,
I could put together these 2 suites in about 1 day from the
total suite I have now - so what's the big deal?

The facts regarding an implementation are simply part of the
validation process. The decision as to whether an implementation
as given satisifies the specification of CL is a matter I do
not address. Perhaps it will turn out that PSL as it is today
is a Common Lisp.

In terms of the need for validation: when I hear some of the schemes
for using AI by the DoD and NASA, I think more and more about 
making these Lisp systems solid. I think that a small investment
in validation can make a significant difference, even if the difference
is the result of increased diligence generated by concern about the
`secret' suite.
			-rpg-

∂16-May-85  1845	Masinter.pa@Xerox.ARPA 	Re: Macros -> declarations
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 16 May 85  18:43:29 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 16 MAY 85 14:59:19 PDT
Date: 16 May 85 14:53 PDT
From: Masinter.pa@Xerox.ARPA
Subject: Re: Macros -> declarations
In-reply-to: various
To: common-lisp@SU-AI.ARPA

The only reason for this issue is because the interpreter has to look
ahead for SPECIAL declarations. SPECIAL declarations are the only ones
that have any semantic import. Furthermore, SPECIAL declarations are the
only ones that are textually retroactive, in that they apply to things
that appeared BEFORE the declaration rather than after.

Rather than hacking around the deficiencies of DECLARE, why not change
it? Put SPECIAL declarations where they belong, next to the variable.
Leave all the other declarations where they are. Most of these issues
then become moot, and we can even consider freeing up some of the
restrictions on declarations; it would seem reasonable to allow
declarations anywhere in an implicit PROGN to refer to the stuff that
follows.

∂16-May-85  1847	FAHLMAN@CMU-CS-C.ARPA 	Preposterousness      
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 16 May 85  18:47:36 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 16 May 85 21:16:45-EDT
Date: Thu, 16 May 1985  14:46 EDT
Message-ID: <FAHLMAN.12111519930.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Dick Gabriel <RPG@SU-AI.ARPA>
Cc:   ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA, squires@USC-ISI.ARPA
Subject: Preposterousness   
In-reply-to: Msg of 1 Jun 1985  11:59-EDT from Dick Gabriel <RPG at SU-AI.ARPA>


I guess I side with RPG on this one.  It's important that the public
validation suite test all those things that are going to be tested, so
that if your program runs the public code and you're not deliberately
trying to out-trick the test, you are nearly certain to pass the secret
test as well.  But I see no problem, and some advantage, to having a
bunch of additional tests that are kept private, just to keep people
from cutting corners by "tuning" against the actual cases that appear in
the test.

On the assumption that nobody else was going to provide any validation
code, I hired a couple of high-school kids (good ones) and have been
training them up to the point where they could write the relatively
simple parts of a validation suite, starting in a couple of weeks.
Since RPG is so close to having a complete test suite, I'll put these
people to work on other things unless I hear of validation code that
needs to be written.  (They are not ready to write the test code for
hairy arglist parsing or anything like that.)

Since I'm writing to this group anyway, let me toss out an idea I've
already mentioned to Gabriel: now that the interesting question is whose
Common Lisp is fastest on various things, and not whether Common Lisp
beats Interlisp or Maclisp or PSL, the business of benchmarking programs
becomes easier.  It would be a relatively simple matter for someone to
collect a bunch of fairly large, realistic programs written in portable
Common Lisp, and to use these for testing one Common Lisp against
another.  Examples might be a smallish system written in portable OPS5,
the Spice Lisp compiler, somebody's natural language system, etc.  No
longer do we have to use tiny benchmarks because they are the only ones
people are willing to translate.  No longer do we have to avoid timing
string code because not all Lisps have strings.

This sort of thing might make a good follow-up to RPG's study, if
someone can be found to coordinate it.  After listening to RPG's war
stories, however, I doubt that any of us would be interested in
coordinating this -- we need some poor soul who either doesn't know what
he's getting into or who actually likes taking public abuse.

-- Scott

∂16-May-85  1946	FAHLMAN@CMU-CS-C.ARPA 	Macros -> declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 16 May 85  19:45:56 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 16 May 85 22:45:05-EDT
Date: Thu, 16 May 1985  22:45 EDT
Message-ID: <FAHLMAN.12111607133.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Masinter.pa@XEROX.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: Macros -> declarations
In-reply-to: Msg of 16 May 1985  17:53-EDT from Masinter.pa at Xerox.ARPA


We've kicked this idea around before in various forms, including the use
of some sort of syntactic marker on special bindings -- something like
turning FOO into $FOO if the variable is special, or treating the *FOO*
convention as being a declaration of specialness.  Other lexical Lisps
have done this sort of thing with no obvious ill effects (and arguably
some good effects), but it seems to have been too radical a change to
have been seriously considered by most of the Common Lisp people when
the language was being designed.  It would be even tougher now that the
langauge is starting to be used and assorted companies are rushing to
get implementations out.

Personally, I like the idea.  I've felt for some time that we ought to
separate SPECIAL declarations from all the others, even if that means
that Common Lisp ends up looking a little different from Maclisp.  But
we should only make this move so late in the game if just about everyone
else feels likewise.

-- Scott

∂16-May-85  2007	GRISS%hp-hulk.csnet@csnet-relay.arpa 	Collections of CL tests and validations   
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 16 May 85  20:07:23 PDT
Received: from hplabs by csnet-relay.csnet id ae15232; 16 May 85 18:38 EDT
Received: by HP-VENUS id AA13027; Thu, 16 May 85 05:31:14 pdt
Message-Id: <8505161231.AA13027@HP-VENUS>
Date: Thu 16 May 85 05:31:09-PDT
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Collections of CL tests and validations
To: common-lisp@su-ai.ARPA
Cc: GRISS@hplabs.CSNET
Source-Info:  From (or Sender) name not authenticated.

Has anyone started to collect or distribute a CL validation suite or
even scattered tests of CL. Are any of these publically available?

Thanks

Martin Griss

-------

∂16-May-85  2346	RPG  	Benchmarking  
To:   quinquevirate@SU-AI.ARPA, ohlander@USC-ISI.ARPA,
      squires@USC-ISI.ARPA 
The original intent of the benchmark study was to use large, real
programs as benchmarks. We were unable to do that because not all
Lisps supportted all things - this is as Scott suggested. To benchmark
Common Lisps, though, we can use such large programs. Because I'm
used to the abuse now, I'd be happy to continue with it.
			-rpg-

∂17-May-85  0129	REM@IMSSS 	Property lists
Received: from IMSSS by SU-AI with PUP; 17-May-85 01:29 PDT
Date: 17 May 1985 0128-PDT
From: Rem@IMSSS
Subject: Property lists
To:   COMMON-LISP@SU-AI

It seems to me that the choice of whether property lists should be kept
as ASSOC lists or as alternating lists should be an implementation issue.
Functions for adding, deleting, finding, modifying them should exist
so that the user hardly ever needs to actually see the structure except
when debugging. Yet the CL manual insists that in CL they must be implemented
as alternating lists, not as ASSOC lists. Why was this decision made??
Should it be rescinded?
-------

∂17-May-85  0544	KMP@SCRC-QUABBIN.ARPA 	Property lists   
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 17 May 85  05:44:03 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 164444; Fri 17-May-85 08:38:41-EDT
Date: Fri, 17 May 85 08:43 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Property lists
To: Rem@IMSSS, COMMON-LISP@SU-AI.ARPA
In-Reply-To: The message of 17 May 85 04:28-EDT from Rem@IMSSS
Message-ID: <850517084324.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: 17 May 1985 0128-PDT
    From: Rem@IMSSS

    It seems to me that the choice of whether property lists should be kept
    as ASSOC lists or as alternating lists should be an implementation issue.
    Functions for adding, deleting, finding, modifying them should exist
    so that the user hardly ever needs to actually see the structure except
    when debugging. Yet the CL manual insists that in CL they must be implemented
    as alternating lists, not as ASSOC lists. Why was this decision made??
    Should it be rescinded?

No.

For one thing, the term "property list format" provides useful terminology
for contrasting "association list format".

For another thing, GETF has a variety of uses in situations where lists were
not actually created by (SETF (GETF ...)), etc. eg, keyword argument lists can
be easily manipulated using GETF. You couldn't do that if the format wasn't
defined. Instead, you'd write code identical to what's there just so that you
could use it "safely". Since there are advantages to saying what the format is
and no particular disadvantages (data abstractions notwithstanding; you could
always write a TABLE abstraction), it has been the concensus that the format
might as well be documented.
-kmp

∂17-May-85  0621	KMP@SCRC-QUABBIN.ARPA 	Macros -> declarations
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 17 May 85  06:21:04 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 164450; Fri 17-May-85 09:15:42-EDT
Date: Fri, 17 May 85 09:20 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Macros -> declarations
To: Fahlman@CMU-CS-C.ARPA, Masinter.pa@XEROX.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12111607133.BABYL@CMU-CS-C.ARPA>
Message-ID: <850517092025.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Thu, 16 May 1985  22:45 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

    We've kicked this idea around before in various forms, including the use
    of some sort of syntactic marker on special bindings -- something like
    turning FOO into $FOO if the variable is special, or treating the *FOO*
    convention as being a declaration of specialness.  Other lexical Lisps
    have done this sort of thing with no obvious ill effects (and arguably
    some good effects), but it seems to have been too radical a change to
    have been seriously considered by most of the Common Lisp people when
    the language was being designed.  It would be even tougher now that the
    langauge is starting to be used and assorted companies are rushing to
    get implementations out.

    Personally, I like the idea.  I've felt for some time that we ought to
    separate SPECIAL declarations from all the others, even if that means
    that Common Lisp ends up looking a little different from Maclisp.  

Referring specifically to your comments about a standard (enforced) naming 
convention for specials...

* For the record, some programs like Macsyma use the printname of symbols to
  record other kinds of information and would have to be radically restructured
  to adapt to such a scheme. eg, in Macsyma any symbol with $ is accessable to
  the Macsyma user; ie, the macsyma expression FOO+BAR parses to something involving
  the Lisp symbols $FOO and $BAR. Since there need to be some special variables 
  accessible to users and others which are not, this kind of change would cause
  all kinds of hassle.

  Admittedly, such a convention is just poor excuses for a package system,
  but its semantics is much different than the CL package system and it's not a 
  trivial syntactic change to convert things.

  I suspect this isn't an isolated example. The Programmer's Apprentice has a
  ton of code (by Dick Waters) which prefixes a digit to every symbol so you
  can tell what module it belongs to. eg, its "database" code uses names like
  8FOO and 8BAR while the display module uses 7FOO and 7BAR. I suppose a 
  -very- careful Query Replace of "DISPLAY:" for "7" would almost "fix" things,
  but it'd be fairly tricky.

* In general, I would want to avoid attaching language semantics to the print 
  name of a symbol. It's bad enough that all symbols with & as their first
  char or that are interned on the keyword package are reserved. For example,
  if specials had different print names than other symbols, you'd need to 
  add a :SPECIAL-P keyword to GENTEMP which said whether to do hair to make 
  sure the symbol had a print name suitable to be a special variable. Various
  other applications that concatentated symbols to make new symbols in macros
  would have to use care not to produce symbols like OLD-*FOO* (preferring,
  I suppose *OLD-*FOO*) or OLD-$FOO (preferring $OLD-$FOO). There used to be
  something nice about the sanctity of a symbol ... I feel as if we're starting
  to walk all over that. I hope we will move -away- from having reserved symbols.
  eg, eventually (might take a while before we can swing it) flushing &keywords 
  in the bvl for :keywords, and making :keywords not be SYMBOLP.

    ... But we should only make this move so late in the game if just about 
    everyone else feels likewise.

Wouldn't want you to think they did.

∂17-May-85  0731	JLW  	∂10-May-85  0146	hoey@nrl-aic 	Re: EQUALP hash tables (and more ...)      
To:   Hoey@NRL-AIC.ARPA
CC:   common-lisp@SU-AI.ARPA
Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 10 May 85  01:46:39 PDT
Date: 10 May 1985 03:54:51 EDT (Fri)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: EQUALP hash tables (and more ...)
To: Jon White <JLW@SU-AI.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Message-Id: <484559691/hoey@nrl-aic>

    Date: 09 May 85  2356 PDT
    From: Jon White <JLW@SU-AI.ARPA>

    ... a more generalized form of hashing ... two more "properties" of
    hashtables -- the "equivalenceing" function, and the "numericalizing"
    function....

    For "equivalence" function, the user may supply #'eq, #'string=, or
    even something random like #'=-mod-5;

Bravo!  If CL should have hash tables, it should have these.  The
existing lack of functionality is embarrassing in an otherwise
orthogonal, extensible language.

    ... the "numericalizing" function is simply how to reduce a general
    s-expression into a reasonable sized fixnum....

I would leave off ``reasonable sized''; certainly gethash is capable of
hashing a fixnum value to its favorite range.

    I [believe] hashing on EQ means using the pointer address...
    but nothing in the CLM would prevent an implementation from using sxhash
    instead.

Two problems with this.  First, as you note, the key could get
modified.  I'm not sure you noticed, but this means that in order for
GETHASH to fail, it would have to examine the whole table for modified
structures.  Second, I think SXHASH might not terminate on circular
structures, though this caveat is not in the manual (and it, or its
denial, should be).

Dan

SXHASH on circular structures?

In-reply-to: your message of 10-May-85  3:54:51 EDT

Yes, one might implement SXHASH in a manner that would loop on circular
structures, but there is no requirement to do so.  In fact, the CLM is
so vague about sxhash that (defun sxhash (x) 1)  is a perfectly legitimate
definition!  

I think there has been a common misconception about sxhash that it must
descend into every node of a structure; indeed, the first implementation
in pdp10 MacLisp, over a decade ago, did just that (and I'm no doubt the 
guilty party).  But more recently, I (and others) have experimented with
definitions which are depth-limited.  [Similarly, during the NIL development,
both NIL and pdp10 MacLisp got definitions for a number of functions which were depth-limited, solely as a (slow) way to stop
depth-limiting;  this was done primarily as a low-overhead, fail-safe way to 
detect circularities.  However, a fairly large limit has to be allowed, and thus
this idea has a loop hole on "blam" lists given to EQUAL; but it effectively
and somewhat quickly stop circularites on LENGTH, NTH, and a few others.]

But the purpose of SXHASH is to provide a user interface to the "numericalizing"
function needed for hash arrays; there is no need to make it more discriminatory
that would be useful in providing a moderately random distribution of collision
chains in hash tables.  SXHASH is a many-to-one mapping, and there is no reason
to assume that, statistically speaking, the depth cutoff is more damaging than
is the accidental coinciding of a particular dataset -- one might think of this
"accidental coinciding" as the inherent noise in the information of the problem.

Of course, too small a limit on the depth would certainly be noticeable in
terms of the *average* speed of hashing functions, but just exactly where
that boundary is may be difficult to determine. [I wouldn't seriously
suggest using a constant function, or even one that merely discriminated
on the data type -- but can anyone seriously suggest that depth 1000 will
be statistically different from depth 100?  I would like to know.]
For some months now, Lucid Common Lisp has been running with variations on
the limited-depth sxhash, and not only does it meet the CLM requirements,
but it seems to meet our day-to-day needs.

-- JonL --

∂17-May-85  0735	JLW  	SXHASH on circular structures?    
To:   Hoey@NRL-AIC.ARPA
CC:   common-lisp@SU-AI.ARPA

In-reply-to: your message of 10-May-85  3:54:51 EDT

Yes, one might implement SXHASH in a manner that would loop on circular
structures, but there is no requirement to do so.  In fact, the CLM is
so vague about sxhash that (defun sxhash (x) 1)  is a perfectly legitimate
definition!  

I think there has been a common misconception about sxhash that it must
descend into every node of a structure; indeed, the first implementation
in pdp10 MacLisp, over a decade ago, did just that (and I'm no doubt the 
guilty party).  But more recently, I (and others) have experimented with
definitions which are depth-limited.  [Similarly, during the NIL development,
both NIL and pdp10 MacLisp got definitions for a number of functions which were depth-limited, solely as a (slow) way to stop
depth-limiting;  this was done primarily as a low-overhead, fail-safe way to 
detect circularities.  However, a fairly large limit has to be allowed, and thus
this idea has a loop hole on "blam" lists given to EQUAL; but it effectively
and somewhat quickly stop circularites on LENGTH, NTH, and a few others.]

But the purpose of SXHASH is to provide a user interface to the "numericalizing"
function needed for hash arrays; there is no need to make it more discriminatory
that would be useful in providing a moderately random distribution of collision
chains in hash tables.  SXHASH is a many-to-one mapping, and there is no reason
to assume that, statistically speaking, the depth cutoff is more damaging than
is the accidental coinciding of a particular dataset -- one might think of this
"accidental coinciding" as the inherent noise in the information of the problem.

Of course, too small a limit on the depth would certainly be noticeable in
terms of the *average* speed of hashing functions, but just exactly where
that boundary is may be difficult to determine. [I wouldn't seriously
suggest using a constant function, or even one that merely discriminated
on the data type -- but can anyone seriously suggest that depth 1000 will
be statistically different from depth 100?  I would like to know.]
For some months now, Lucid Common Lisp has been running with variations on
the limited-depth sxhash, and not only does it meet the CLM requirements,
but it seems to meet our day-to-day needs.

-- JonL --

∂17-May-85  0803	gls%AQUINAS@THINK.ARPA 	Poor excuse for packages  
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 17 May 85  07:38:10 PDT
Received: by THINK.ARPA with CHAOS id AA04932; Fri, 17 May 85 10:31:42 edt
Date: Friday, 17 May 1985, 10:32-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Poor excuse for packages
To: common-lisp%sail@THINK.ARPA
Cc: gls%AQUINAS@THINK.ARPA
Message-Id: <850517103227.1.GLS@DESIDERIUS.ARPA>

KMP hinted at a very interesting solution to the special-variables
problem: let symbols in the package SPECIAL name special variables,
and let all others name local variables.  There doesn't seem to be
much wrong with
	(LET ((SPECIAL:MY-GLOBAL-FLAG 43)
	      (SPECIAL:PRINT-PRETTY T))
          ...)
or
	(DEFUN FOO (A B SPECIAL:C) ...)

It's cheap to detect, too, in interpreter or compiler: just check the
package cell.  This I like.  Too bad it's too late.

An ugly suggestion is to ADD this mechanism to the language without
removing the declaration syntax yet, and let people phase over during
the next year.  Ugh, bletch.

∂17-May-85  0803	Masinter.pa@Xerox.ARPA 	Re: Macros -> declarations
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 17 May 85  07:44:25 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAY 85 07:42:47 PDT
Date: 17 May 85 07:42 PDT
From: Masinter.pa@Xerox.ARPA
Subject: Re: Macros -> declarations
In-reply-to: KMP, Fahlman
To: common-lisp@SU-AI.ARPA

There are two alternatives for dealing with specials, both of which
remove SPECIAL from DECLARE. One is lexographic, relying on the
characters of the symbol. (Examples include inferring specialness from
*var* or $var, or, the Fortan II approach: special variables all begin
with the letters P, Q or S :-).

Another is syntactic; still allow arbitrary variables to be special, but
denote them in a way that removes the declaration from the (optional)
DECLARE syntax. For example, one might allow, at the "top level", a
special form 

(SPECIAL var1 var2 .... varn)

and also, in any place where a variable is bound (LET, DO, lambda lists,
etc.), allow (SPECIAL var) wherever var is allowed.

(This leads to a bit of a burden if you want a
special-optional-variable, because you have to say something like

(lambda (a b &optional ((special c))) --)



- - - - - - - - - - - - - -
I will attempt to step gently around the sticky issue of how "Common
Lisp" should balance implementation inertia against technical advances,
and restrict myself to comments about the form of inertia.

There are two kinds of inertia: implementations of "Common Lisp" and
programs implemented in it. It would seem that there is some confusion
among the implementations on whether macros are or are not allowed to
expand into declarations.  I would claim that, at least the syntactic
example above represents no more turmoil to the typical compiler and
interpreter than either adding or removing the requirement that macros
can or cannot expand into DECLAREs.

Inertial of existing programs is a little harder to rate; it would also
seem reasonable for those with large quantities of MacLisp code such as
Macsyma might want to run in an (improper) superset which allows
"old-style" declares.

It would help, 

∂17-May-85  0807	JLW  	EQUALP hash tables 
To:   Fahlman@CMU-CS-C.ARPA
CC:   common-lisp@SU-AI.ARPA 

In-reply-to: your message of 11-May-85  10:59 EDT

As for names for the "equivalence" and "numericalizing" functions for
hash tables, well, the :test argument is already the "equivalence" argument;
how about :sxhash for the numericalizing argument?  This has the mnemonic
value that the default for it could simply be #'SXHASH.

I see no reason to restrict the possible values that :sxhash may have --
even when the :test argment is #'EQ; as my note last week was intending
to point out, EQ-type hash tables needn't be constrained to use pointer
bits for the :sxhash -- it's only a vague general feeling that we don't
want to have to re-hash whenever some object in th table is updated that
prevents use of #'SXHASH here.  But for many (maybe even most?) applications
there is really no need to worry about the updating problem;  after all,
who really worrys about it with EQUAL type tables?  and it's just as
serious a problm there too, as Hoey pointed out.

How  would you feel about this?  The default :sxhash value will be an internal
version of MAKNUM *** when the :test arg is #'EQ o #'EQL *** rather than
SXHASH (appropriate conversions from 'EQ and 'EQL).  iven this, is there any
need to have the user supply the information that the table will have to be
re-hash'd after a relocating GC?  This condition should only occur when the
:sxhash function is somehow a function of the entry's pointer address -- and
by fiat you are ruling out any user-level function that returns that address.
Can anyone think of a case where this isn't true?

Finally, I'd say your suggestion for a REHASH function is quite timely.
Interlisp  has such a function:
  (REHASH hash-array new-array)
where both argments are hash-arrays, and the first one is merely re-hashed
into the second; a NIL for the second arg means something like (I think)
"cons up a fresh hash array just big enough to hold all the elements of
the first argument, and it's :rehash-threshold size"; and a T for the
second arg means something like (I think) "cons up a fresh hash array big
enough to be the growth by the :rehash-size of the first argument".
[well, if it doesn't operate exactly like that, it should].  

A useful scenario is to make a huge hash table, make many entries over a
period of time, and then finally decide that not may more entries will
be made; thus one will want to "shrink" the table to the minimum feasible
size for holding the current entries.  REHASH, as defined above, with a
second arg of NIL is just the right thing.

-- JonL --

∂17-May-85  0841	JLW  	hash table types   
To:   dcp%tenex.scrc@MIT-XX.ARPA
CC:   common-lisp@SU-AI.ARPA 

In-reply-to: your message of 12-May-85 10:56 EDT

Your list of "external things [I] see need changing" looks quite good
to me.  I might add the suggestion that we add a ROT primitive to CL
which is machine independent.  The following definition got added to
Interlisp shortly after I went to Xerox:
  (ROT x n fieldsize)
"performs a bitwise left-rotation of the integer x, by n places, within
a field of fieldsize bits wide.  Bits shifted out of the position selected
by (expt 2 (sub1 fieldsize)) will flow into the 'units' position."

Now, this definition has the advantage that on many machines, there will be
one particular field size for which the implementation of this ROT will be
very efficient (i.e., the one actually supported by a hardware ROT instruction).
And since SXHASH is permitted to be implemetation dependent -- not "address
dependent", but rather varying between one implementation and another -- then
each implementation can use a ROT in it's sxhash with a field size that is
efficient.

-- JonL --

∂17-May-85  0905	BSG@SCRC-STONY-BROOK.ARPA 	Poor excuse for packages    
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 17 May 85  08:38:26 PDT
Received: from SCRC-STONY-BROOK.ARPA (scrc-stony-brook.arpa.ARPA) by THINK.ARPA id AA05295; Fri, 17 May 85 11:27:52 edt
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 238638; Fri 17-May-85 11:28:13-EDT
Date: Fri, 17 May 85 11:24 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Poor excuse for packages
To: gls%AQUINAS@THINK.ARPA, common-lisp%sail@THINK.ARPA
In-Reply-To: <850517103227.1.GLS@DESIDERIUS.ARPA>
Message-Id: <850517112438.5.BSG@CONCORD.SCRC.Symbolics.COM>

    Date: Friday, 17 May 1985, 10:32-EDT
    From: Guy Steele <gls%AQUINAS@THINK.ARPA>

    KMP hinted at a very interesting solution to the special-variables
    problem: let symbols in the package SPECIAL name special variables,
    and let all others name local variables.  There doesn't seem to be
    much wrong with
	    (LET ((SPECIAL:MY-GLOBAL-FLAG 43)
		  (SPECIAL:PRINT-PRETTY T))
	      ...)
    or
	    (DEFUN FOO (A B SPECIAL:C) ...)

    It's cheap to detect, too, in interpreter or compiler: just check the
    package cell.  This I like.  Too bad it's too late.

    An ugly suggestion is to ADD this mechanism to the language without
    removing the declaration syntax yet, and let people phase over during
    the next year.  Ugh, bletch.
There is a fairly major problem with this.  "Suppose two applications
that have nothing to do with each other use the symbol SPECIAL:FOO".

I.e., everything that packages had bought you is now lost.

∂17-May-85  0905	KMP@SCRC-STONY-BROOK.ARPA 	Poor excuse for packages    
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 17 May 85  08:38:55 PDT
Received: from SCRC-STONY-BROOK.ARPA (scrc-stony-brook.arpa.ARPA) by THINK.ARPA id AA05313; Fri, 17 May 85 11:31:04 edt
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 238641; Fri 17-May-85 11:31:09-EDT
Date: Fri, 17 May 85 11:30 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Poor excuse for packages
To: gls%AQUINAS@THINK.ARPA, common-lisp%sail@THINK.ARPA
In-Reply-To: <850517103227.1.GLS@DESIDERIUS.ARPA>
Message-Id: <850517113027.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Friday, 17 May 1985, 10:32-EDT
    From: Guy Steele <gls%AQUINAS@THINK.ARPA>

    KMP hinted at a very interesting solution to the special-variables
    problem: let symbols in the package SPECIAL name special variables,
    and let all others name local variables.  There doesn't seem to be
    much wrong with
	    (LET ((SPECIAL:MY-GLOBAL-FLAG 43)
		  (SPECIAL:PRINT-PRETTY T))
	      ...)
    or
	    (DEFUN FOO (A B SPECIAL:C) ...)

    It's cheap to detect, too, in interpreter or compiler: just check the
    package cell.  This I like. Too bad it's too late.

    An ugly suggestion is to ADD this mechanism to the language without
    removing the declaration syntax yet, and let people phase over during
    the next year.  Ugh, bletch.

I certainly did not intend to hint at such a thing. While it might be 
appropriate for a user program to put all its specials on one package and
all its non-specials on another, or even appropriate for it to be possible
for a whole package to somehow be declared to have implicitly special 
variables (perhaps unless explicitly declared LEXICAL), it is not reasonable 
to make every utility's specials share the same namespace!

Your suggestion is tantamount to saying that package information should be
ignored for variables and used only by EQ and function lookup since the package
of a lexical variable almost never matters -- ie, how many people do you
expect to write:
 (DEFUN F (FOO:X BAR:X) (+ FOO:X BAR:X))
? On the other hand, you might well expect someone to write:
 (DEFUN AVERAGE-LINEL () (// (+ FOO:*LINEL* BAR:*LINEL*) 2))
and certainly
(DEFUN AVERAGE-LINEL () (// (+ SPECIAL:*FOO-LINEL* SPECIAL:*BAR-LINEL*) 2))
would be a -real- step backward.

Adopting a solution like this would mean that programs written without 
knowledge of each other might collide very badly when loaded into the same
environment for some application that wanted to compose them. 

Clearly unacceptable.

∂17-May-85  0905	Cassels@SCRC-STONY-BROOK.ARPA 	Poor excuse for packages
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 17 May 85  08:59:20 PDT
Received: from SCRC-STONY-BROOK.ARPA (scrc-stony-brook.arpa.ARPA) by THINK.ARPA id AA05491; Fri, 17 May 85 11:53:37 edt
Received: from CUYAHOGA.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 238658; Fri 17-May-85 11:52:10-EDT
Date: Fri, 17 May 85 11:52 EDT
From: Robert A. Cassels <Cassels%TENEX.SCRC.Symbolics.COM@THINK.ARPA>
Subject: Poor excuse for packages
To: gls%AQUINAS@THINK.ARPA, common-lisp%sail@THINK.ARPA
In-Reply-To: <850517103227.1.GLS@DESIDERIUS.ARPA>
Message-Id: <850517115227.0.CASSELS@CUYAHOGA.SCRC.Symbolics.COM>

    Date: Friday, 17 May 1985, 10:32-EDT
    From: Guy Steele <gls%AQUINAS@THINK.ARPA>

    KMP hinted at a very interesting solution to the special-variables
    problem: let symbols in the package SPECIAL name special variables,
    and let all others name local variables.  There doesn't seem to be
    much wrong with
	    (LET ((SPECIAL:MY-GLOBAL-FLAG 43)
		  (SPECIAL:PRINT-PRETTY T))
	      ...)
    or
	    (DEFUN FOO (A B SPECIAL:C) ...)

Ack!  What's the point of packages then?  I thought they were for
avoiding name conflicts.  Maybe you meant that some packages should be
declared as holding only special symbols.  Then we could have
MY-SPECIAL:FOO and YOUR-SPECIAL:FOO.  But this is getting silly.

I think a more interesting interpretation of KMP's idea is to have some
symbols which are always special.  How they are marked internally is an
implementation detail.  The problem from the language designer's point
of view is then to decide how the programmer specifies which of the
symbols he typed are special and which are not.  Other places in the
language, we have used syntactic markers -- why not here?  (YOW!  Are we
Common SCHEME yet??)

The only similar thing in the present CL is the ":" vs. "::" syntax for
internal and external package symbols.  So we probably want some sort of
prefix operator.  Perhaps "*" as a leading character, since that would
break the smallest number of existing programs.  Maybe *:FOO and
MY-PACKAGE*:FOO.  Hopefully someone an come up with a better syntax.

    It's cheap to detect, too, in interpreter or compiler: just check the
    package cell.  This I like.  Too bad it's too late.

    An ugly suggestion is to ADD this mechanism to the language without
    removing the declaration syntax yet, and let people phase over during
    the next year.  Ugh, bletch.


∂17-May-85  0944	smh@mit-eddie.ARPA 	Re:  Poor excuse for packages 
Received: from MIT-EDDIE.ARPA by SU-AI.ARPA with TCP; 17 May 85  09:34:13 PDT
Received: by mit-eddie.ARPA (4.12/4.8)  id AA27181; Fri, 17 May 85 12:33:48 edt
Date: Fri, 17 May 85 12:33:48 edt
From: Steven M. Haflich <smh@mit-eddie.ARPA>
Message-Id: <8505171633.AA27181@mit-eddie.ARPA>
To: common-lisp@sail
Subject: Re:  Poor excuse for packages
Cc: gls%aquinas@think

> KMP hinted at a very interesting solution to the special-variables
> problem: let symbols in the package SPECIAL name special variables,
> and let all others name local variables.

But, but, then all specials are necessarily in the same package, and
we are back to the original problem that component subsystems cannot
ensure that their symbols will not clash with those of other
subsystems.

> It's cheap to detect, too, in interpreter or compiler: just check the
> package cell.  This I like.  Too bad it's too late.

This aspect is indeed nice!  I think to do it right, each package
would implicitly be split into two components: one subpackage
containing the specials, and one the non-specials.  (This use of
"subpackage" has nothing to do with the old LM notion of subpackage.)
The package name of the specials subpackage would be automatically
generated, perhaps by prepending `*'.  By reader convention, *:foo
would be the special variable foo in the current package.

The implementation would be such that the subpackages necessarily
share the same inheritance structure; naming either subpackage in
intern, import, export, shadow, etc., would be equivalent, except for
the implication of variable specialness.

On the balance, I agree this idea is not worth the pain.  However, its
consideration leads to an interesting question:  Can anyone think of a
situation in which it is useful or even reasonable to refer to a
non-special variable using an explicit package qualifier?

∂17-May-85  0957	hoey@nrl-aic 	SXHASH and EQ hash tables 
Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 17 May 85  09:53:46 PDT
Message-Id: <8505171652.AA09246@nrl-aic>
Date: 17 May 1985 12:08:27 EDT (Fri)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: SXHASH and EQ hash tables
To: Jon White <JLW@SU-AI.ARPA>
Cc: common-lisp@su-ai.ARPA

I agree that limiting the number of substructures visited by SXHASH is
a good thing to do.  The next manual should promise that SXHASH will
operate on any object, and mention depth- and length-limiting as an
implementation note.  Probably what you want is just a limit on the
number of substructures visited.  There's probably no good way of
outlawing a constant function, but I think the desirability of having a
large range for SXHASH goes without saying.

Scott pointed out to me that efficiency rules out having (SETF (GETHASH
KEY ...)) do an automatic (COPY-TREE KEY) for the insertion.  He
suggested removing the item from the hashtable, then modifying it, then
reinserting; that's a solution in some cases, but what if a lot of keys
share the modified structure?  Well, for EQUAL hash tables, I think the
manual should mention that you might want to (SETF (GETHASH (COPY-TREE
Key)...)).  And for EQUALP hashtables, there should be a
COPY-SUBSTRUCTURE (or COPY-TREE :TEST #'EQUALP ?) function to do the
analogous thing.

As for using SXHASH on EQ hash tables, I think this is a really bad
idea.  There's just no way to get around rehashing, and I think it's
conceptually wrong to have to worry about it.  I can see rehashing
``whenever some object in the table is updated'' but for EQ keys you
aren't modifying the object in the table.  Here I think the manual
should promise that EQ hashing is insensitive to changes in
substructures.

Dan

∂17-May-85  0958	gls%AQUINAS@THINK.ARPA 	Poor excuse for a Quux    
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 17 May 85  09:58:16 PDT
Received: by THINK.ARPA with CHAOS id AA06628; Fri, 17 May 85 12:47:31 edt
Date: Friday, 17 May 1985, 12:48-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Poor excuse for a Quux
To: common-lisp@sail
Cc: gls%AQUINAS@THINK.ARPA
Message-Id: <850517124814.1.GLS@DESIDERIUS.ARPA>

Sigh.  I figured out why the SPECIAL:FOO suggestion was totally wedged
about three seconds after I had mailed off my note.  My apologies for
wasting everyone's time.  (Apologies too to KMP for misrepresenting his
intentions.)  I won't insult your intelligence by suggesting such
epicycles as

	USER:SPECIAL:PRINT-PRETTY
and	TV:SPECIAL:MOUSE-CURSOR-PATTERN

That's what I get for shooting from the hip.

∂17-May-85  0959	gls%AQUINAS@THINK.ARPA 	Backquote idioms
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 17 May 85  09:58:42 PDT
Received: by THINK.ARPA with CHAOS id AA06920; Fri, 17 May 85 12:56:43 edt
Date: Friday, 17 May 1985, 12:57-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Backquote idioms
To: common-lisp@sail
Cc: gls%AQUINAS@THINK.ARPA
Message-Id: <850517125728.2.GLS@DESIDERIUS.ARPA>

Has anyone ever undertaken a study or catalog of backquote idioms?
Those of you who have used backquote at all seriously have probably come
to regard
		',	,',	,,	,@,	,@',	,',',

as primitive idioms, almost recognizable as units, such as we take in CADDR
at a glance without thinking about the three component operations.

I raise this question because a few weeks ago I was confronted for the
first time with a situation for which the eventual solution was

		,@(LIST ,@X)

and it occurred to me that  ,@(LIST ,@  is another useful idiom.
(It is the splicing analogue[*] of ,, .)

Anyway, it would be interesting to assemble a list of such useful idioms.
It might make a good paper for the 1986 LISP conference.  (Alan, are
you listening?)

--Guy


[*] I am aware that it is terribly inconsistent of me to write "catalog"
but "analogue".  I promise not to do it again (very much).

∂17-May-85  1045	@MIT-REAGAN.ARPA:Soley@MIT-MC.ARPA 	Macros -> declarations  
Received: from MIT-REAGAN.ARPA by SU-AI.ARPA with TCP; 17 May 85  10:30:23 PDT
Received: from MIT-CHERRY by MIT-REAGAN via CHAOS with CHAOS-MAIL id 4996; Fri 17-May-85 13:32:09-EDT
Date: Fri, 17 May 85 13:30 EDT
From: Soley@MIT-MC.ARPA
Subject: Macros -> declarations
To: Fahlman@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850517092025.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <850517133012.1.SOLEY@CHERRY.MIT>

    Date: Thu, 16 May 1985  22:45 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
    
    We've kicked this idea around before in various forms, including the use
    of some sort of syntactic marker on special bindings -- something like
    turning FOO into $FOO if the variable is special, or treating the *FOO*
    convention as being a declaration of specialness.  Other lexical Lisps
    have done this sort of thing with no obvious ill effects (and arguably
    some good effects), but it seems to have been too radical a change to
    have been seriously considered by most of the Common Lisp people when
    the language was being designed.

Definitely, a great idea.  But instead, why not just say that all
variables whose printnames start with the characters 'I' through 'N' are
special?  A good extension to tried and true languages. :-)

	-- Richard

∂17-May-85  1158	HEDRICK@RUTGERS.ARPA 	special declaration    
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 17 May 85  11:56:57 PDT
Date: 17 May 85 14:55:49 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: special declaration
To: common-lisp@SU-AI.ARPA

As an implementor, I would be only too happy to flush the current
(incomplete) tests for SPECIAL declarations in favor of something
that is in the lambda list.  The idea of using the pname is
obviously a bad one, but I don't see any problem with things
such as
    (foo &special bar)
    (foo (special bar))
    (foo #$bar)
I would much prefer these to the current situation, and the sooner
the better...  At the moment there probably isn't a large body of
CL code yet.  It is just barely possible to make changes like this
now.  Shortly it will not be practical.  I assert that it is
possible to do a mechanical translation from the old to the new
form, particularly for implementations that don't yet handle
macros that expand to declarations.  I have thought of one case
that this can't handle, but it is probably so pathological that
we can ignore it.
	
		  ------------------------

Appendix.  A pathlogical case.

In order to assure portability, it might be helpful to make sure
that code can run in implementations that use lexical binding
and in implementations that use dynamic binding.  For this
purpose, we will declare all of our variables using the
macro SOMETIMES-SPECIAL.  This will declare all of its arguments
special when the day of the month is odd, and otherwise expand
to NIL.
-------

∂17-May-85  1815	Moon@SCRC-STONY-BROOK.ARPA 	EQUALP hash tables (and more ...)    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 17 May 85  18:14:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 239098; Fri 17-May-85 21:14:43-EDT
Date: Fri, 17 May 85 21:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: EQUALP hash tables (and more ...) 
To: Common-Lisp@SU-AI.ARPA
Message-ID: <850517211410.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

DCP's message of 12 May said most of what I want to say on the subject of
generic hash tables, Symbolics' experience with them, and what issues are
involved in implementing them.

One other point: I suspect that rather than specifying the equivalence
function and the hashing function as separate arguments to
MAKE-HASH-TABLE, you would be better off introducing a DEFHASH special
form that defines a new flavor [sic] of hash table.  That way, you
package up the equivalence function and the hashing function together
into something that has a name, and you don't have to face the issue of
inconsistent combinations.  Furthermore, the DEFHASH for EQ and EQL hash
tables has already been done by the Common Lisp implementation, so you
don't have to publish the name of their implementation-dependent hashing
function.

Our CL implementation already uses the :TEST argument to MAKE-HASH-TABLE
as a key looked up in a table of flavors of hash table, but we haven't
told users how to add their own entries to that table.

∂17-May-85  1831	Moon@SCRC-STONY-BROOK.ARPA 	Macros -> declarations
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 17 May 85  18:31:03 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 239102; Fri 17-May-85 21:30:58-EDT
Date: Fri, 17 May 85 21:30 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Macros -> declarations
To: common-lisp@SU-AI.ARPA
In-Reply-To: <850510015144.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
             <FAHLMAN.12109898307.BABYL@CMU-CS-C.ARPA>,
             The message of 16 May 85 17:53-EDT from Masinter.pa@Xerox.ARPA,
             <FAHLMAN.12111607133.BABYL@CMU-CS-C.ARPA>,
             The message of 17 May 85 10:42-EDT from Masinter.pa@Xerox.ARPA,
             The message of 17 May 85 14:55-EDT from Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Message-ID: <850517213026.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 10 May 85 01:51 EDT
    From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>

    (DEFMACRO DEF-MY-MACRO (NAME BVL &BODY (BODY '(...default body...))
					   (DECLS '((DECLARE (SPECIAL *FOO*))))
					   (DOC "a macro"))
      ...)

    I believe that attacking the problem of DECLARE at the level people have been
    attacking it gives up programmer flexibility to no good end (not to mention
    introducing an incompatible change to the language semantics). A change
    like these syntax extensions to DEFMACRO that I've been speaking about would
    make life easy for the macro writer without giving up the macro-writing 
    freedoms I was originally supporting.

I think this is a good suggestion.  Of course we ought to think about it a bit before
adopting it, but I haven't seen any problems of Common Lisp changing too fast lately!

    Date: 16 May 85 14:53 PDT
    From: Masinter.pa@Xerox.ARPA

    The only reason for this issue is because the interpreter has to look
    ahead for SPECIAL declarations. SPECIAL declarations are the only ones
    that have any semantic import. Furthermore, SPECIAL declarations are the
    only ones that are textually retroactive, in that they apply to things
    that appeared BEFORE the declaration rather than after.

This last sentence is not true.  Actually, there are almost no declarations
in Common Lisp that are -not- textually retroactive, because declarations
are placed in the -middle- of the form to which they apply.

    Rather than hacking around the deficiencies of DECLARE, why not change
    it? Put SPECIAL declarations where they belong, next to the variable.
    Leave all the other declarations where they are. Most of these issues
    then become moot, and we can even consider freeing up some of the
    restrictions on declarations; it would seem reasonable to allow
    declarations anywhere in an implicit PROGN to refer to the stuff that
    follows.

I don't think it is only SPECIAL declarations that need to be attached to
variable bindings.  Consider the data-type declarations.

One point I'd like to make in this connection is that making SPECIAL
declarations locally, rather than globally with DEFVAR, is generally not
something we should be encouraging.  It's worth noting that the main use
of local SPECIAL declarations in Maclisp-like languages in the past has
been to simulate what FLET does better.  Now that we have full lexical scoping,
we can probably dispense with local SPECIAL declarations.

Perhaps the SPECIAL declaration should be phased out, so we can say that
DECLARE never has "semantic import", but is only a hint to the compiler
or otherwise an "annotation."  The SPECIAL proclamation would remain, of
course.  If people feel it is necessary, some way to change the SPECIAL
status of a name locally could be retained, but it need not be DECLARE.
It could be a special [multiple puns intentional] version of LET.

This wouldn't change the fact that macro writers need a PARSE-BODY,
since losing an annotation that makes the code run efficiently is almost
as unacceptable as losing an annotation that makes the code run
correctly or one that documents the code.

    Date: Thu, 16 May 1985  22:45 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

    Personally, I like the idea.  I've felt for some time that we ought to
    separate SPECIAL declarations from all the others, even if that means
    that Common Lisp ends up looking a little different from Maclisp.  But
    we should only make this move so late in the game if just about everyone
    else feels likewise.

Agreed.

    Date: 17 May 85 14:55:49 EDT
    From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>

    As an implementor, I would be only too happy to flush the current
    (incomplete) tests for SPECIAL declarations in favor of something
    that is in the lambda list.  The idea of using the pname is
    obviously a bad one, but I don't see any problem with things
    such as
	(foo &special bar)

We haven't bothered to remove support for &SPECIAL from our system yet,
so we could hardly complain if it became a standard instead of an obsolete
holdover from the past!  Again, though, I think there is little real need
for local SPECIAL declarations.

∂17-May-85  2051	FAHLMAN@CMU-CS-C.ARPA 	Macros -> declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 17 May 85  20:50:57 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 17 May 85 23:50:21-EDT
Date: Fri, 17 May 1985  23:50 EDT
Message-ID: <FAHLMAN.12111881156.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Macros -> declarations
In-reply-to: Msg of 17 May 1985  21:30-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


Now there's an idea: flush local SPECIAL declarations altogether,
keeping only global SPECIAL proclamations.  I'll have to think about
this awhile to see if I really believe that we can do without these
declarations, but it is certainly a very attractive suggestion at first
glance.  Can anyone think of a really important use for such
declarations?

I don't understand Moon's comment that local SPECIAL declarations have
mostly been used to simulate what FLET does better.  Can you elaborate a
bit? 

As Moon points out, even with this change we would still need PARSE-BODY
for macro writers, but it would sure make life easier for the
interpreter, since the other declarations can all be ignored unless
you're doing tense error-checking.

-- Scott

∂18-May-85  0815	KMP@SCRC-STONY-BROOK.ARPA 	Macros -> declarations 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 May 85  08:15:34 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 239203; Sat 18-May-85 11:15:26-EDT
Date: Sat, 18 May 85 11:14 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Macros -> declarations
To: Fahlman@CMU-CS-C.ARPA, Moon@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12111881156.BABYL@CMU-CS-C.ARPA>
Message-ID: <850518111450.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Fri, 17 May 1985  23:50 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

    Now there's an idea: flush local SPECIAL declarations altogether,
    keeping only global SPECIAL proclamations.  I'll have to think about
    this awhile to see if I really believe that we can do without these
    declarations, but it is certainly a very attractive suggestion at first
    glance.  Can anyone think of a really important use for such
    declarations?

I can provide a few from recent experience with Macsyma. I'm not sure they'll
convince you 100%, but hopefully they'll at least make you stop and think.
It largely depends on whether you consider the goal is to produce a language
that's clean and shiny or one that cares about things like compatibility with
the past where possible, etc. I think these goals conflict pretty badly. With
my language designer's hat on, I'd reject almost all of these arguments out of
hand. But since CL was designed by people prone to wear their politician's hats
a lot of the time, I'm of the impression that things like "compatibility with
the past" and such are likely to carry more weight, so here goes...

* Sometimes a function will need to be compiled "out of place" (eg,
  before the relevant DEFVAR is loaded). In such cases, the problem
  may go away if you move the definition containing the spurious
  reference to another file (which is processed after the DEFVAR),
  but the SPECIAL declaration may linger.

* In any large system which is being converted incrementally from some other
  Lisp dialect (eg, old Maclisp or a relative, Interlisp, ...), it may be
  desirable to incrementally convert the semantics of variables used by
  functions. Using local SPECIAL declarations, you can gradually whittle away
  the region in which certain specials are used. If you force global SPECIAL
  declarations, you undermine the ability to make such transitions incrementally.

* Although Macsyma is being converted for Common Lisp, it may continue to run
  in other dialects of Lisp as well. As such, FLET and friends may not be
  available in those dialects and a number of situations may arise where 
  local SPECIAL declarations provide a way of achieving compatibility with
  those otherwise-not-cooperating dialects.

* There are numerous examples of special variables being used as
  communication between three or four definitions. We've been working on
  converting:

  (DECLARE (SPECIAL X))
  (DEFUN FOO () ... refers to special X ...)
  (DEFUN BAR () ... refers to special X ...)
  (DECLARE (UNSPECIAL X))

  into

  (DEFUN FOO () (DECLARE (SPECIAL X)) ... refers to special X ...)
  (DEFUN BAR () (DECLARE (SPECIAL X)) ... refers to special X ...)

  This a couple of advantages worth noting.

  * Common Lisp has no UNSPECIAL declaration (that I could find).
    If the special is a common name like X, we need to not have every
    reference to X compiled SPECIAL. It may be very expensive and
    dangerous (ie, in terms of potential for typos, timing errors, etc)
    to change all 180 source files for Macsyma to use names that could
    reasonably be left SPECIAL all the time. (At some point we may
    consider this, but...)

  * It makes it explicit when you look at a particular definition
    just how the communication is being done (since mostly these variables
    don't have *...* around them.

  * It is a -very- common problem that we will modify a definition
    and just put that definition in a patch file, only to find it compiles
    differently out of context because the appropriate SPECIAL declarations
    were not present. Having the SPECIAL declarations in the definition
    means they will move with the definition into the patch file. (This 
    problem would be "solved" by making SPECIAL declarations global and
    outlawing UNSPECIAL, but would mean I'd have to rename an awful lot of 
    variables, which I mentioned above is a bit scary...)

----Fahlman:
    I don't understand Moon's comment that local SPECIAL declarations have
    mostly been used to simulate what FLET does better.  Can you elaborate a
    bit? 

I assume he meant that variables which must be accessed in downward funargs
(eg, to MAPCAR and user-defined friends) no longer have to be passed special.
Likewise, what people used to write as:

(DEFUN IN (OBJ TREE) (DECLARE (SPECIAL OBJ)) (IN1 TREE))

(DEFUN IN1 ()
  (DECLARE (SPECIAL OBJ))
  (COND ((ATOM TREE) (EQ OBJ TREE))
	(T (OR (IN1 (CAR TREE)) (IN1 (CDR TREE))))))

can now be written:

(DEFUN IN (OBJ TREE)
  (LABELS ((IN1 (TREE)
	     (COND ((ATOM TREE) (EQ OBJ TREE))
		   (T (OR (IN1 (CAR TREE)) (IN1 (CDR TREE)))))))
    (IN1 TREE)))

----Fahlman:
    As Moon points out, even with this change we would still need PARSE-BODY
    for macro writers,

or my &BODY hack. No sense in not providing both, though.

    but it would sure make life easier for the interpreter, since the other
    declarations can all be ignored unless you're doing tense error-checking.

∂18-May-85  0932	masinter.PA@Xerox.ARPA 	uses for specials    
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 18 May 85  09:32:35 PDT
Received: from Riesling.ms by ArpaGateway.ms ; 18 MAY 85 09:32:17 PDT
From: masinter.PA@Xerox.ARPA
Date: 18 May 85 9:30:27 PDT
Subject: uses for specials
To: common-lisp@su-ai.ARPA

I've seen more than one program that constructs expressions on the fly,
and then EVALs them in another context. 

PROGV has an implicit local special declaration. 


As long as an incompatible name is being considered, how about changing
the name? While there's some amusement in having SPECIAL a special form,
the novice may well wonder, "well, what's so SPECIAL about them?". Guy
was careful to call them DYNAMIC in the book; it sounds like a more
appropriate name for a (different syntax) declaration.

∂18-May-85  1112	KMP@SCRC-STONY-BROOK.ARPA 	DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special Form"  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 May 85  11:11:50 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 239223; Sat 18-May-85 14:11:42-EDT
Date: Sat, 18 May 85 14:11 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special Form"
To: masinter.PA@XEROX.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 18 May 85 12:30-EDT from masinter.PA@XEROX.ARPA
Message-ID: <850518141104.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: 18 May 85 9:30:27 PDT
    From: masinter.PA@Xerox.ARPA

    ... As long as an incompatible name is being considered, how about changing
    the name? While there's some amusement in having SPECIAL a special form,
    the novice may well wonder, "well, what's so SPECIAL about them?". Guy
    was careful to call them DYNAMIC in the book; it sounds like a more
    appropriate name for a (different syntax) declaration.

-- DYNAMIC/LEXICAL --

It would seem reasonable that CL86 should add DYNAMIC as a synonym for SPECIAL 
in the declaration world, and LEXICAL for symmetry. Then in CL88 could flush 
SPECIAL (or make it mean something incompatible).

-- *LEXPR --

Can we get a ruling on whether

 (FUNCTION (FOO INTEGER &OPTIONAL INTEGER))

is a valid declaration? p159 is very vague on the subject, giving no syntax
restrictions for the arglist components at all. (Only through the limited
fixed-arg example can you even infer that the arglist given should contain 
type names and not be the actual arglist used by the function.)

The compiler should be encouraged to complain if it sees
 (PROCLAIM '(FUNCTION FOO INTEGER &OPTIONAL INTEGER))
and later sees
 (DEFUN FOO (X)
   (DECLARE (SYMBOL X))
   ...)
but should be discouraged from complaining (or should at least be encouraged
to notice the non-fatal nature of the situation) if it later sees:
 (DEFUN FOO (X &OPTIONAL (Y 1) (Z 2))
   (DECLARE (INTEGER X Y Z))
   ...)
since in the latter case, the definition is upward compatible with the
declaration.

It occurred to me that without &OPTIONAL working in FUNCTION declarations,
the functionality of Maclisp's *LEXPR declaration is conspicuously absent.

By the way, apropos of Masinter's comments above, and given that it's useful
to declare something like takes-variable-number-of-args in advance to thwart 
forward-referencing problems, it might also want to be possible to declare 
that some form, WITH-RANDOM-BINDINGS, is a special form so that 
forward-references (which will tend to be fatal errors) to it can be
diagnosed immediately rather than having to wait for the definition to roll
by. I assume this is what he was alluding to about it might have been 
more appopriate for syntax declarations, as in
 (PROCLAIM '(SPECIAL WITH-RANDOM-BINDINGS)).
I guess it's a little late to try to make such a change in CL84, much less
CL86. Maybe CL88...

-- "Special Operator" vs "Special Form" --

Also, I'd like to replace the term "special form" with "special operator"
when it doesn't apply to the whole form. ie, COND is not a special form,
it is a special operator (properly, it's the name of a special operator
but that's not so critical to me at this point). Certainly,
(COND ((NULL X) T) (T NIL)) is a "special form" and COND is not of the
same type so needs its own name. I would like to see SPECIAL-FORM-P made
obsolete (but retained for a while for compatibility) and SPECIAL-OPERATOR-P
introduced as an alternative. In this way, SPECIAL-FORM-P could eventually
be recycled (or flushed from CL proper and re-invented by private applications
that care) to be (AND (TYPEP x 'CONS) (SPECIAL-OPERATOR-P (CAR x))). Actually,
having the interim compatibility definition be 
 (OR (SPECIAL-OPERATOR-P x)
     (AND (TYPEP x 'CONS) (SPECIAL-OPERATOR-P (CAR x))))
wouldn't be so bad either if we could agree to that. That way, people who
order their COND clauses correctly, could start taking advantage of the
recycled meaning right away. In any case, the important point here is that
the "form" / "operator" distinction needs to be made more clearly than we've
been making it.

∂18-May-85  1156	WHOLEY@CMU-CS-C.ARPA 	Macros -> declarations 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 May 85  11:56:31 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Sat 18 May 85 14:56:12-EDT
Date: Sat, 18 May 1985  14:56 EDT
Message-ID: <WHOLEY.12112046053.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To:   Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA, Fahlman@CMU-CS-C.ARPA, Moon@SCRC-STONY-BROOK.ARPA
Subject: Macros -> declarations
In-reply-to: Msg of 18 May 1985  11:14-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>

    Date: Saturday, 18 May 1985  11:14-EDT
    From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>

        Date: Fri, 17 May 1985  23:50 EDT
        From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

        As Moon points out, even with this change we would still need
        PARSE-BODY for macro writers,

    or my &BODY hack. No sense in not providing both, though.

I think that PARSE-BODY is needed even if the &BODY hack is used.  People other
than DEFMACRO (the mythical code analysis tools, for example) should have some
convenient way to parse bodies.  Also, providing such a hook and encouraging
everyone to use it could make users' lives easier when and if the language
changed in any radical way.

On the other hand, the fancy &BODY syntax is a great win, and should be in the
language as well.

--Skef

∂18-May-85  1352	FAHLMAN@CMU-CS-C.ARPA 	Macros -> declarations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 May 85  13:52:02 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 18 May 85 16:51:38-EDT
Date: Sat, 18 May 1985  16:51 EDT
Message-ID: <FAHLMAN.12112067060.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Macros -> declarations
In-reply-to: Msg of 18 May 1985  11:14-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>


Here's where my thinking is right now on all of this declaration stuff.

1. If it were up to me, I would still flush macro-to-definition
expansion, not because it is TOTALLY worthless but because the hassle it
causes far outweighs the marginal benefits.  However, I am willing to
concede that this battle is lost, and that this misfeature will stay in
the language.

2. Given that, we definitely need PARSE-BODY as an official part of the
language, and some advice on its use in the chapter on Macros (or
someplace).  The arguments would be (form environment &optional
(doc-string-allowed t)).  Query: when this form returns a body, is it
desirable to allow it to return a cons of the macro-expanded first form
and the rest of the body, or should we require the original body to be
returned?  Returning the expanded first form might sometimes save some
work, but I suppose you have to worry about things where some
optional-argument init code changes something that would alter the
macro-expansion.

3. I also think we should add KMP's extended syntax for &body, since
that makes it possible for Macro writers to pick apart these things
without having to explictly handle environments or even multiple values.
I prefer the simple syntax for this, as in (...&body (body decl doc)),
since it is less visually confusing (fewer nested parens) than the
version with defaults, and since I see no real use for these defaults.
But I could live with the more complex version, I guess.

4. We should give very serious consideration to eliminating local
special declarations.  We would add DYNAMIC and LEXICAL proclamations,
and phase out the use of the term "special variable" and the SPECIAL
proclamation.  (These would be changed in the 1986 manual, with a note
that this change has been made and advice that implementors handle the
phase-out gradually and carefully.)  There would be some style advice
that DYNAMIC variables should generally be dynamic thoughout a whole
program and should observe the *foo* convention.  The ability to switch
a variable back and forth from DYNAMIC to LEXICAL is provided mostly to
allow old code to be more easily ported to Common Lisp.  We might
possibly need something like the SPECIAL-LET that Moon suggested -- I'm
not sure.

In answer to KMP's comments about the usefulness of special declarations
in porting old code: 

Yes, clean language design and compatibility are natural enemies, as
most of us in this effort have seen many times.  Any one of us could
have designed a better Lisp if compatibility were not an issue.  On the
other hand, we explicitly decided that we would not shoot for full upward
compatibility with Maclisp or even for fully automatic translatability.
Some things were just too ugly not to change.

My own view of how compatible we want to be goes more or less as
follows: it should be possible to translate a program like Macsyma into
Common Lisp by having some competent programmer make a careful pass
through the code.  If there are things that just don't translate in any
reasonable way (leaving aside some of the godawful PDP-10 hacks that
occur at low levels in Macsyma), then we have diverged too far.  But we
should not feel constrained to have macsyma run in Common Lisp without a
conversion effort, and we certainly shouldn't feel constrained by a
desire to have the same source code run in other dialects of Lisp.

Of the specific problems that KMP raises, mostly having to do with
wanting to do big conversions a little bit at a time, I think that most
of these problems go away if we provide both DYNAMIC and LEXICAL
declarations.  I recognize that it is sometimes convenient to have such
declarations lexically bundled into the function definitions they
modify, but I see no reason why the proclamations and the definitions
can't be moved into a patch file together, as though they were
surrounded by one set of outer parens.  If you really care, there's
always PROGN to bundle these top-level forms together.  I think that
this would handle Masinter's objection, about passing a form from one
environment to another, as well.

Finally, on BSG's suggestion for extensions to the macro syntax, so that
we can macro-expand different types of forms in different namespaces.
Right now we've only got two such contexts, normal evaluated forms and
type declarations.  There was a proposal for a third type of context,
declaration subforms, but if we retain the Macro->declaration lossage it is
not necessary to add this.  I see no need to go to a more general
mechanism to combine the two existing uses of macro-like expansion.  I
also feel that if we do make this generalization, the pressure to
macro-expand new and bizarre kinds of things will increase over time.
SO I think we should table BSG's suggestion until such time as there is
a real need for it.

I've dumped all this stuff at once since I'm going to be off the net for
two weeks starting Monday.

-- Scott

∂18-May-85  1406	FAHLMAN@CMU-CS-C.ARPA 	DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special Form" 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 May 85  14:06:19 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 18 May 85 17:05:50-EDT
Date: Sat, 18 May 1985  17:05 EDT
Message-ID: <FAHLMAN.12112069635.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special Form"
In-reply-to: Msg of 18 May 1985  14:11-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>


    By the way, apropos of Masinter's comments above, and given that it's useful
    to declare something like takes-variable-number-of-args in advance to thwart 
    forward-referencing problems, it might also want to be possible to declare 
    that some form, WITH-RANDOM-BINDINGS, is a special form so that 
    forward-references (which will tend to be fatal errors) to it can be
    diagnosed immediately rather than having to wait for the definition to roll
    by. I assume this is what he was alluding to about it might have been 
    more appopriate for syntax declarations, as in
     (PROCLAIM '(SPECIAL WITH-RANDOM-BINDINGS)).
    I guess it's a little late to try to make such a change in CL84, much less
    CL86. Maybe CL88...

I don't understand this at all.  Are you asking for a way for users to
declare that some user-defined form is a special form?  There aren't
supposed to be any user-defined special forms.

    -- "Special Operator" vs "Special Form" --

    Also, I'd like to replace the term "special form" with "special operator"
    when it doesn't apply to the whole form. ie, COND is not a special form,
    it is a special operator (properly, it's the name of a special operator
    but that's not so critical to me at this point).

Well, I've already used up my quota of ridicule for the month, so I'll
just say that this looks to me like nit-picking and I would oppose any
change to the name of a function in order to remove the alleged
inconsistency in the nomenclature.  Name changes are always more hassle
than they should be, so they should only be done when the old name was
actually confusing people.

-- Scott

∂18-May-85  1413	FAHLMAN@CMU-CS-C.ARPA 	Macros -> declarations (oops!)  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 May 85  14:13:36 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 18 May 85 17:13:22-EDT
Date: Sat, 18 May 1985  17:13 EDT
Message-ID: <FAHLMAN.12112071020.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   common-lisp@SU-AI.ARPA
Subject: Macros -> declarations (oops!)
In-reply-to: Msg of 18 May 1985  16:51-EDT from Scott E. Fahlman <Fahlman>


In my previous message, next to last paragrpah, I referred to providing
DYNAMIC and LEXICAL "declarations" a couple of times when I meant to say
"proclamations".  To clarify, the proposal is that there would be no
DYNAIMC and LEXICAL declarations.  Sigh!

-- Scott

∂18-May-85  1916	GSB@MIT-MC 	Re: EQUALP hash tables (and more ...) 
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 May 85  19:14:28 PDT
Date: Sat, 18 May 85 22:15:14 EST
From: Glenn S. Burke <GSB@MIT-MC>
Subject: Re: EQUALP hash tables (and more ...) 
To: Common-Lisp@SU-AI
Message-ID: <[MIT-MC].509855.850518.GSB>

    Date: Fri, 17 May 85 21:14 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    . . .
    One other point: I suspect that rather than specifying the equivalence
    function and the hashing function as separate arguments to
    MAKE-HASH-TABLE, you would be better off introducing a DEFHASH special
    form that defines a new flavor [sic] of hash table.  That way, you
    package up the equivalence function and the hashing function together
    into something that has a name, and you don't have to face the issue of
    inconsistent combinations.  Furthermore, the DEFHASH for EQ and EQL hash
    tables has already been done by the Common Lisp implementation, so you
    don't have to publish the name of their implementation-dependent hashing
    function.
Yes.
    Our CL implementation already uses the :TEST argument to MAKE-HASH-TABLE
    as a key looked up in a table of flavors of hash table, but we haven't
    told users how to add their own entries to that table.
NIL does likewise.   One of the "flavors" of hash table is
functional-hash-table, which is additionally parameterizable by a
function to do error checking on the key (so that it gets caught at
gethash level rather than by the equality or hashing function).  There
is also some hair so that the equality function used can be different
from the name used to reference;  e.g., hash-tables which use :TEST
#'STRING-EQUAL (one of the hash table tests predefined in NIL)
actually use an internal two-argument-only form of string-equal which
doesn't check its arguments, rather than applying the hairy one which
takes keyworded arguments.  All NIL hash tables other than EQ and EQL
are implemented through this (string=, char-equal, string-equal and
equal are predefined).

∂19-May-85  0926	Gall.HIS←Guest@MIT-MULTICS.ARPA 	Re: DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special   
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 19 May 85  09:25:44 PDT
Posted-Date:  19 May 85 12:03 EDT
Date:  Sun, 19 May 85 12:01 EDT
From:  Nick Gall <Gall@MIT-MULTICS.ARPA>
Subject:  Re: DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special
          Form"
To:  common-lisp@SU-AI.ARPA
In-Reply-To:  Message of 18 May 85 14:11 EDT from "Kent M Pitman"
Message-ID:  <850519160157.528715@MIT-MULTICS.ARPA>

    Date:  18 May 1985 14:11 edt
    From:  Kent M Pitman <KMP at SCRC-STONY-BROOK>
    Subject:  DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special
              Form"

        Date: 18 May 85 9:30:27 PDT
        From: masinter.PA@Xerox.ARPA

        ... As long as an incompatible name is being considered, how about changing
        the name? While there's some amusement in having SPECIAL a special form,
        the novice may well wonder, "well, what's so SPECIAL about them?". Guy
        was careful to call them DYNAMIC in the book; it sounds like a more
        appropriate name for a (different syntax) declaration.

    -- DYNAMIC/LEXICAL --

    It would seem reasonable that CL86 should add DYNAMIC as a synonym for SPECIAL
    in the declaration world, and LEXICAL for symmetry. Then in CL88 could flush
    SPECIAL (or make it mean something incompatible).

Yes.
    -- *LEXPR --

    Can we get a ruling on whether

     (FUNCTION (FOO INTEGER &OPTIONAL INTEGER))

    is a valid declaration? p159 is very vague on the subject, giving no syntax
    restrictions for the arglist components at all. (Only through the limited
    fixed-arg example can you even infer that the arglist given should contain
    type names and not be the actual arglist used by the function.)

First, there is an error in the equivalence between the FUNCTION and
FTYPE decl.  specifiers.  The equivalence should be:

(FUNCTION name arglist result-type-1 result-type-2 ...)
<=> (FTYPE (FUNCTION arglist (VALUES result-type-1 result-type-2 ...)) name)

Secondly, the definition of `arglist' appears on pg.  47 in the def.  of
the FUNCTION type specifier.

Two suggestions for the FUNCTION type-specifier definition.  (1) Change
the word "markers" to "lambda-list keywords".  (2) Define how a keyword
and its type are associated.  For example, if I have a function that
takes a keyword argument named FOO of type INTEGER, I assume the type
specifier would look like this:  (FUNCTION (&KEY (FOO INTEGER)) ...).

Also, take a look at the VALUES type-specifier on the next page.  I was
surprised to see that it also allows lambda-list keywords (albeit for a
reason that confuses me).  Could someone give an example of the
usefulness of this?

    The compiler should be encouraged to complain if it sees
     (PROCLAIM '(FUNCTION FOO INTEGER &OPTIONAL INTEGER))
    and later sees
     (DEFUN FOO (X)
       (DECLARE (SYMBOL X))
       ...)
    but should be discouraged from complaining (or should at least be encouraged
    to notice the non-fatal nature of the situation) if it later sees:
     (DEFUN FOO (X &OPTIONAL (Y 1) (Z 2))
       (DECLARE (INTEGER X Y Z))
       ...)
    since in the latter case, the definition is upward compatible with the
    declaration.

Again I am confused.  Is the following legal?

(PROCLAIM '(FUNCTION FOO INTEGER &OPTIONAL INTEGER))

(DEFUN FOO (ARG1)
  (DECLARE (INTEGER ARG1))
  ...)

I.E., Is downward compatibility allowed also?  If not, then perhaps the
upward compatibility case should not be legal.  If downwardly compatible
definitions ARE allowed, then to make a proclamation that allows
upwardly compat.  definitions one should proclaim

(PROCLAIM '(FUNCTION FOO INTEGER &OPTIONAL INTEGER &REST LIST))

This would allow any number of additional optional arguments.

My guess is that neither are legal and that the arglist in the FUNCTION
type-specifier must exactly match its corresponding lambda-list.

    It occurred to me that without &OPTIONAL working in FUNCTION declarations,
    the functionality of Maclisp's *LEXPR declaration is conspicuously absent.

    By the way, apropos of Masinter's comments above, and given that it's useful
    to declare something like takes-variable-number-of-args in advance to thwart
    forward-referencing problems, it might also want to be possible to declare
    that some form, WITH-RANDOM-BINDINGS, is a special form so that
    forward-references (which will tend to be fatal errors) to it can be
    diagnosed immediately rather than having to wait for the definition to roll
    by. I assume this is what he was alluding to about it might have been
    more appopriate for syntax declarations, as in
     (PROCLAIM '(SPECIAL WITH-RANDOM-BINDINGS)).
    I guess it's a little late to try to make such a change in CL84, much less
    CL86. Maybe CL88...

I agree with Scott's comment.  In CL, there's no such thing as a
special-form that the compiler and interpreter don't know about.

    -- "Special Operator" vs "Special Form" --

    Also, I'd like to replace the term "special form" with "special operator"
    when it doesn't apply to the whole form. ie, COND is not a special form,
    it is a special operator (properly, it's the name of a special operator
    but that's not so critical to me at this point). Certainly,
    (COND ((NULL X) T) (T NIL)) is a "special form" and COND is not of the
    same type so needs its own name. I would like to see SPECIAL-FORM-P made
    obsolete (but retained for a while for compatibility) and SPECIAL-OPERATOR-P
    introduced as an alternative. In this way, SPECIAL-FORM-P could eventually
    be recycled (or flushed from CL proper and re-invented by private applications
    that care) to be (AND (TYPEP x 'CONS) (SPECIAL-OPERATOR-P (CAR x))). Actually,
    having the interim compatibility definition be
     (OR (SPECIAL-OPERATOR-P x)
         (AND (TYPEP x 'CONS) (SPECIAL-OPERATOR-P (CAR x))))
    wouldn't be so bad either if we could agree to that. That way, people who
    order their COND clauses correctly, could start taking advantage of the
    recycled meaning right away. In any case, the important point here is that
    the "form" / "operator" distinction needs to be made more clearly than we've
    been making it.

Yes.  I think its at least worth mentioning in the section on special
forms that calling the symbol COND a `special-form' is a misnomer;
precisely speaking it is the name of a special form.  This kind of
clarification is done for other `muddy' terms in CL, e.g., DYNAMIC,
UNBOUND.

∂19-May-85  0930	DD60@CMU-CS-A.ARPA 	user hash tables    
Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 19 May 85  09:29:59 PDT
Date: Sun, 19 May 85 12:28 EDT
From: David.Dill@CMU-CS-A.ARPA (L170DD60)
To: common-lisp@SU-AI.ARPA
Subject: user hash tables
Message-Id: <19May85.122856.DD60@CMU-CS-A.ARPA>

I have needed these badly.  I have two suggestions:

I frequently want to store objects that have their retrieval keys in them
already; for example, a structure representing a symbol in a table often
has the string for the symbol sitting in the structure already for various
reasons.  It is pointlessly inefficient to represent this in the hash
table as a pair (key . thing) when the thing contains the key already.

What you need here is a set implemented as a hash table, where the
definition of equality does comparison on some piece of the structure
of the object stored in the table, while hash tables as currently
designed are obviously intended to be like association lists.  If a hash
set could be created with user-supplied :hash and :equality routines,
it would be very easy to do this.  I believe that a hashed set
abstraction is also useful in its own right.

Now, in the example of a symbol table it is often the case that you
have a string in hand, and you want to find out if it is already in
the symbol table.  If it is, you do nothing; if not, you want to create
a symbol structure with various auxilliary fields and store it in the
table.  Hash sets as proposed above can be extended to do this very nicely
by adding a :insert routine, which is called when something is added
("adjoined", I guess) to the table.  In this example, the insert routine
would take the string and table as an argument and create the symbol
table structure just before stuffing into the appropriate hash bucket.

Given hash sets in this form, it would be very easy to implement hash
tables by having the insert routine cons up a (key . object) pair.
(Actually, a lookup would return the pair and I don't remember whether
CL hash tables return this or the object.)

I have used a hash set implementation like this at CMU on the PQCC
project and at Tartan Labs (the :insert routine idea was John Nestor's).

Tables of this form don't quite do everything: sometimes I have wanted the
key to be a combination of several fields of the structure being stored
(say "name" field and "type" or "package").  I suppose the routines could
be extended to take &REST arguments or whatever.

One of the properties I usually want from a hash table is speed.  Pulling
hash and equality routines out of a hash table object and calling them
is obviously going to add a fair amount of overhead to the whole process.
It would be nice if users could define a new type of hash table by
some method similar to DEFSTRUCT, and have these routines defined as
macros that could be expanded at compile time (but please don't suggest
hairing up DEFSTRUCT even more to do this!).

∂19-May-85  1246	FAHLMAN@CMU-CS-C.ARPA 	Yellow pages
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 May 85  12:46:28 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 19 May 85 15:46:18-EDT
Date: Sun, 19 May 1985  15:46 EDT
Message-ID: <FAHLMAN.12112317328.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   common-lisp@SU-AI.ARPA
Subject: Yellow pages


I have copied our local Spice Lisp program library to macine
CMU-CS-C.ARPA, from which it should be easily accessible by FTP.  The
directory is PRVA:<SLISP.LIBRARY>, and the file CATALOG.TXT describes
the various programs in the library in a format that should be farily
easy for future "librarian" programs to use.  The master copy is still
on CMU-CS-SPICE, but we'll try to keep the two directories in sync.  RPG
may also move a copy to SU-AI.

This is just a beginning, of course.  Some of the programs in this
library are in somewhat ragged shape, and most of them are dependent on
the Spice/Accent enviornment in some way.  We hope to add some
additional stuff to this library as the summer progresses, including
OPS5 and Flavors.  We will also be putting some effort into polishing
these things up and separating the truly portable things from the
non-portable ones.

For now at least, we reserve the right to change or improve these files
in incompatible ways any time we want to.  If you want a stable copy of
something, grab your own copy.

If anyone else has contributions for this library, please let me know.
If you take one of these modules and significantly improve it, please
notify both the maintainer listed in the catalog file and me, and we'll
try to fold your improvements into the library version in a coherent
way.  For now, we will only put things into the library that are public
domain or for which we have been granted permission to redistribute the
work without restriction.

No, we are not prepared to mail anyone a tape of this stuff.  It is
changing too fast for that to be a worthwhile pursuit.

-- Scott

∂20-May-85  0707	DCP@SCRC-STONY-BROOK.ARPA 	Macros -> declarations 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 May 85  07:05:40 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 239627; Mon 20-May-85 10:03:52-EDT
Date: Mon, 20 May 85 10:04 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: Macros -> declarations
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>,
    Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12112067060.BABYL@CMU-CS-C.ARPA>
Message-ID: <850520100457.9.NFEP@NEPONSET.SCRC.Symbolics.COM>

Suppose: We flush Macros -> declarations.

Question: Is the compiler allowed to do arbitrary and repetitive
("destructive") macro expansion at any time?  By "destructive", I don't
necessarily mean RPLACA, I mean that the compiler then operates on the
expanded expressions?

If the answer is 'No' I suggest CLtL explains WHEN the compiler IS
allowed to expand macros.

If the answer is 'Yes' then I don't see how it is possible to flush
macro calls expanding into declarations.  In this case, the
implementation of the compiler, NOT THE DEFINITION OF LANGUAGE, will
determine the semantics of the macro.  A compiler that pre-expanded all
forms and subforms before "compiling" it would get the declarations that
were the result of macro expansion.  (As a side effect, the compiler
would be guarenteed it wouldn't have to do macro expansion during
"compiling".)  A compiler that expanded outermost expressions as it got
to them would not see the declarations which came from macros.

An alternative, which I mention just for completeness and is so vile I'm
glad I'm not prone to vomiting, is to kludge the automatic macro
expansion facility to know when declarations are possible and not to
expand macros it sees in those places (or maybe expand the macros but
wrap a PROGN around it).

∂20-May-85  0721	DCP@SCRC-STONY-BROOK.ARPA 	hash table types       
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 May 85  07:21:04 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 239648; Mon 20-May-85 10:11:10-EDT
Date: Mon, 20 May 85 10:12 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: hash table types   
To: Jon White <JLW@SU-AI.ARPA>, dcp@TENEX
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 17 May 85 11:41-EDT from Jon White <JLW@SU-AI.ARPA>
Message-ID: <850520101218.0.NFEP@NEPONSET.SCRC.Symbolics.COM>

    Date: 17 May 85  0841 PDT
    From: Jon White <JLW@SU-AI.ARPA>

    Your list of "external things [I] see need changing" looks quite good
    to me.  I might add the suggestion that we add a ROT primitive to CL
    which is machine independent.  The following definition got added to
    Interlisp shortly after I went to Xerox:
      (ROT x n fieldsize)
    "performs a bitwise left-rotation of the integer x, by n places, within
    a field of fieldsize bits wide.  Bits shifted out of the position selected
    by (expt 2 (sub1 fieldsize)) will flow into the 'units' position."

    Now, this definition has the advantage that on many machines, there will be
    one particular field size for which the implementation of this ROT will be
    very efficient (i.e., the one actually supported by a hardware ROT instruction).
    And since SXHASH is permitted to be implemetation dependent -- not "address
    dependent", but rather varying between one implementation and another -- then
    each implementation can use a ROT in it's sxhash with a field size that is
    efficient.

I wouldn't object to this, but a refinement is necessary.  Is ROT
supposed to give the same answer in all implementations?  On two's
complement machines, (rot 1 (1- n) n) where N is the word width is
(probably) MOST-NEGATIVE-FIXNUM.  Also, (rot 1 (1- n) n) == (ash -1 (1- n)).
In other words, ROT should imply sign extension (on two's complement
machines).

∂20-May-85  1012	gls%AQUINAS@THINK.ARPA 	Backquote idioms
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 20 May 85  10:12:15 PDT
Received: by THINK.ARPA with CHAOS id AA25172; Mon, 20 May 85 13:02:45 edt
Date: Monday, 20 May 1985, 13:03-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Backquote idioms
To: Common-lisp%sail@THINK.ARPA
Cc: gls%AQUINAS@THINK.ARPA
In-Reply-To: The message of 20 May 85 11:42-EDT from Mail Delivery Subsystem <MAILER-DAEMON at GODOT>
Message-Id: <850520130325.6.GLS@DESIDERIUS.ARPA>

    Date: Fri, 17 May 85 20:44:49 EST
    From: Jonathan A Rees <JAR@MIT-MC@think>
    Subject:  Backquote idioms
    To: gls%AQUINAS@THINK

    And consider the useful but not CL-supported ,,@ .

Much to my surprise, I find that
(a)  ,,@  *is* supported by Common Lisp.
(b)  ,,@  is equivalent to  ,@(list ,@

I obtained these results by working through the expansions of
	`(foo `(bar ,,@x))
and     `(foo `(bar ,@(list ,@x)))
using the rules on pages 349-350 of the CLM.
--Guy

∂20-May-85  1328	KMP@SCRC-VALLECITO.ARPA 	"Special Operator" vs "Special Form"    
Received: from SCRC-VALLECITO.ARPA by SU-AI.ARPA with TCP; 20 May 85  13:28:17 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-VALLECITO.ARPA via CHAOS with CHAOS-MAIL id 14082; Mon 20-May-85 16:28:29-EDT
Date: Mon, 20 May 85 16:28 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: "Special Operator" vs "Special Form"
To: Fahlman@CMU-CS-C.ARPA
cc: KMP@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12112069635.BABYL@CMU-CS-C.ARPA>
Message-ID: <850520162811.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Sat, 18 May 1985  17:05 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

        Date: 18 May 1985  14:11-EDT
	From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>

	By the way, apropos of Masinter's comments ... I assume this is what he
	was alluding to about it might have been more appopriate for syntax 
	declarations, as in
	 (PROCLAIM '(SPECIAL WITH-RANDOM-BINDINGS)).
	I guess it's a little late to try to make such a change in CL84, much less
	CL86. Maybe CL88...

    I don't understand this at all.  Are you asking for a way for users to
    declare that some user-defined form is a special form?  There aren't
    supposed to be any user-defined special forms.

Sorry, I still get special and macro confused. In my Special Forms paper in
the 1980 lisp conference, I defined macros to be a subset of special forms.
Somewhere along the line, someone has taken it upon himself to change the
terminology and I haven't completely debugged things. Well, (PROCLAIM '(SPECIAL ...))
could still be meaningful, just not useful. I guess I was really thinking
(PROCLAIM '(MACRO ...)), though. In any case, I wasn't meaning to propose
anything; was mostly just making an observation.

I'm glad you agree that precise terminology on these things is important, though,
because that brings me neatly into the other point...

	-- "Special Operator" vs "Special Form" --

	Also, I'd like to replace the term "special form" with "special operator"
	when it doesn't apply to the whole form. ie, COND is not a special form,
	it is a special operator (properly, it's the name of a special operator
	but that's not so critical to me at this point).

    Well, I've already used up my quota of ridicule for the month, so I'll
    just say that this looks to me like nit-picking and I would oppose any
    change to the name of a function in order to remove the alleged
    inconsistency in the nomenclature.  Name changes are always more hassle
    than they should be, so they should only be done when the old name was
    actually confusing people.

My experience with teaching novices is that things work better when important 
terms like these work better when used very consistently, and I really believe
people are probably being confused by this. I consider the issue of consistent
naming to be extremely important during the "formative years" of programmers
learning a new language. I think it sufficiently important to be worth weathering
the hassle of a name-change, though as I said I'm willing to all that name change
to happen in two steps over several years if necessary.

∂20-May-85  1810	GSB@MIT-MC 	hash table types -- ROT
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 20 May 85  18:10:18 PDT
Date: Mon, 20 May 85 21:11:13 EST
From: Glenn S. Burke <GSB@MIT-MC>
Subject: hash table types -- ROT
To: common-lisp@SU-AI
Message-ID: <[MIT-MC].511876.850520.GSB>

NIL has a ROT function which rotates within a fixnum size.  It was
there years and years ago, and never taken out.  The ONLY use within
all of NIL is hidden inside a macro which combines hash codes, called
SXHASH-COMBINE -- (SXHASH-COMBINE n1 n2 ...) crunches together its
arguments, rotating them varying amounts first.

I can't say i've ever wanted to use ROT in any other circumstance.  I
have on occasion, however, thought about a LDB which sign-extends.

∂20-May-85  1844	GSB@MIT-MC 	terminology  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 20 May 85  18:44:39 PDT
Date: Mon, 20 May 85 21:46:08 EST
From: Glenn S. Burke <GSB@MIT-MC>
Subject: terminology
To: common-lisp@SU-AI
Message-ID: <[MIT-MC].511948.850520.GSB>

I haven't looked through the manual in a while so don't remember
exactly what terminology it uses for these things.  But...  Two of
the terms which I have been asked about many times (with reference to
CLtM, but also to the NIL manual and maybe also Lisp machine lisp
documentation) are "function" and "special form".  Not even including
referential issues ("the name of"), "function" has been taken to mean
those things which you can apply, and sometimes those PLUS macros and
special forms.  The definition of FUNCTIONP does not help things
either.

The use of "form" in special form leads to additional confusion -- is
"(if this that something-else)" a special-form, or is "if" a special
form?  I would much prefer "special operator", although that leads me
to say that "operator" should be used to refer to {special-operators,
macros, functions}.

∂20-May-85  2252	REM@IMSSS 	FORM vs. FUNCTION etc.  
Received: from IMSSS by SU-AI with PUP; 20-May-85 22:51 PDT
Date: 20 May 1985 2247-PDT
From: Rem@IMSSS
Subject: FORM vs. FUNCTION etc.
To:   COMMON-LISP@SU-AI

It seems to me the following is consistent usage close to LISP tradition:

A 'form' is an executable s-expression, i.e. something that might reasonably
be passed to EVAL or pass through the compiler. Forms are atomic or
non-atomic. Non-atomic forms have two parts, the function part (the CAR,
which may be a function or the name of a function or something analagous)
and the argument part (the CDR, which is usually a list of arguments but
may be rather strange in macros and special-forms). Perhaps anything that
can fit in the function part of a form should be called a 'function',
but in CL that term has been restricted to omit macros and special-forms
[sic]. Alternatively it could be called an 'operator'. Thus an operator
would be either a function or a macro-operator or a special-operator
or the names of any of those: I.e. any of #<FUNCTION 2 174625> or
(LAMBDA (X) (PLUS 5 X)) or ADD5 or #<MACRO 126453> or PROG1 or
#<FEXPR 142231> or GO.  (Don't take those code-pointers literally, DWIM.)
So, is it likely we can agree on some consistent usage that distinguishes
a function or operator (or its name) from a form containing it?
-------

∂21-May-85  0801	RWK@SCRC-STONY-BROOK.ARPA 	Backquote idioms  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 21 May 85  08:01:10 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 240608; Tue 21-May-85 11:00:56-EDT
Date: Tue, 21 May 85 11:00 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Backquote idioms
To: Guy Steele <gls%AQUINAS@THINK.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850517125728.2.GLS@DESIDERIUS.ARPA>
Message-ID: <850521110036.5.RWK@CROW.SCRC.Symbolics.COM>

    Date: Friday, 17 May 1985, 12:57-EDT
    From: Guy Steele <gls%AQUINAS@THINK.ARPA>

    Has anyone ever undertaken a study or catalog of backquote idioms?
    Those of you who have used backquote at all seriously have probably come
    to regard
		    ',	,',	,,	,@,	,@',	,',',

---------------------------------------------------------↑↑↑↑
Shades of back-quote TECO!  I discourage people from nesting
things three deep, and never do in my code!  It makes the
list of idioms too long.

Anyway, to contribute my own "idiom" and thoughts to your list:

You *NEVER* see ,',@.  It's useful to recognize this one as
an error.  (It helps to look at it as ,(QUOTE ,@X), and to
remember that QUOTE does not take a variable number of arguments.)

When I'm explaining backquote to people, I stick with the
following list, as the "most useful" and "easiest explained".

,   ',   ,',   ,@',

And, of course, the error case above, which helps them remember
it's ,@', not ,',@.

Personally, I feel we would do well to include a list of idioms
in the next CLtL and recommend that people stick with the set of
idioms.  It makes it a lot easier to read code if you only have
to contend with a fixed set of "tokens".

I think a little taxonomy of idioms is useful:

In most usage of nested back-quoting, the form produced is going to be
evaluated once per level.

Doing (SETQ ARGS '('A 'AA 'AAA))
(setq f '``(list ,@(list ,@ARGS)))
(eval f) ==> `(LIST A AA AAA)
(eval (eval f)) ==> (LIST A AA AAA)

In this case, we see that A, AA, and AAA, while originally quoted, are
about to be evaluated in the resulting form.  This double evaluation
is a charactaristic of all of these idioms which have more than one
more comma than quote.  I.e. ,,   ,@,   ,,@   and   ,@(list ,@ARGS)

In general, it is rarely the right thing for something to be evaluated
multiple times.  We rarely write A and expect the value of A's value.

I find this division of these idioms into "single-evaluation",
"multiple evaluation" and "complete error" to be quite helpful.  I
consider any use of "multiple evaluation" idioms to be suspect when
I'm looking for bugs in code.  Also, since I can never construct convincing
examples of when they're useful when I'm showing someone backquote, I
usually don't explain them at all the first time around.

However, it seems to me that ,@(LIST is the same as just plain comma.
I.e. the following also gives the same result.

(setq f1 '``(list ,,@args))
(eval f1) ==> `(LIST A AA AAA)
(eval (eval f1)) ==> (LIST A AA AAA)

Is there really a reason to add ,@(LIST ,@ to our lexicon?

∂21-May-85  0848	JAR@MIT-MC 	"Special Operator"
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 May 85  08:48:43 PDT
Date: Tue, 21 May 85 11:49:46 EST
From: Jonathan A Rees <JAR@MIT-MC>
Subject:  "Special Operator"
To: common-lisp@SU-AI
In-reply-to: Msg of Sat 18 May 85 14:11 EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Message-ID: <[MIT-MC].512627.850521.JAR>

    Date: Sat, 18 May 85 14:11 EDT
    From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>

    ... Also, I'd like to replace the term "special form" with "special
    operator" when it doesn't apply to the whole form. ie, COND is not a
    special form, it is a special operator.

Creating a new term to permit this distinction is an excellent idea.
Saying that COND is a special form is like saying that CAR is a function
call.

Jonathan

∂21-May-85  2211	Moon@SCRC-VALLECITO.ARPA 	terminology   
Received: from SCRC-VALLECITO.ARPA by SU-AI.ARPA with TCP; 21 May 85  22:11:22 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-VALLECITO.ARPA via CHAOS with CHAOS-MAIL id 14543; Tue 21-May-85 21:21:59-EDT
Date: Tue, 21 May 85 21:21 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: terminology
To: Glenn S. Burke <GSB@MIT-MC.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[MIT-MC].511948.850520.GSB>
Message-ID: <850521212134.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 20 May 85 21:46:08 EST
    From: Glenn S. Burke <GSB@MIT-MC>

    The use of "form" in special form leads to additional confusion -- is
    "(if this that something-else)" a special-form, or is "if" a special
    form?  I would much prefer "special operator", although that leads me
    to say that "operator" should be used to refer to {special-operators,
    macros, functions}.

I agree with this.  I also believe (but haven't checked recently) that this
is the terminology used in Symbolics documentation and training (except that
not all of the documentation has yet been updated to conform to the standard
terminology).

∂22-May-85  0805	gls%AQUINAS@THINK.ARPA 	Backquote idioms
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 22 May 85  08:04:48 PDT
Received: by THINK.ARPA with CHAOS id AA16659; Wed, 22 May 85 10:55:58 edt
Date: Wednesday, 22 May 1985, 10:56-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Backquote idioms
To: ALAN@MIT-MC@THINK.ARPA, JAR@MIT-MC
Cc: common-lisp@sail, gls%AQUINAS@THINK.ARPA
In-Reply-To: <[MIT-MC].513387.850521.ALAN>
Message-Id: <850522105634.1.GLS@MUNGO.ARPA>

    Received: from GODOT by AQUINAS via CHAOS with CHAOS-MAIL; Tue 21-May-85 22:44:45-EDT
    Received: from MIT-MC (mit-mc.arpa.ARPA) by THINK.ARPA id AA13184; Tue, 21 May 85 22:34:23 edt
    Date: Tue, 21 May 85 22:34:20 EST
    From: Alan Bawden <ALAN@MIT-MC@think>
    Subject:  Backquote idioms
    To: JAR@MIT-MC
    Cc: GLS@MIT-MC
    In-Reply-To: Msg of Tue 21 May 85 12:39:38 EST from Jonathan A Rees <JAR>
    Message-Id: <[MIT-MC].513387.850521.ALAN>

	Date: Tue, 21 May 85 12:39:38 EST
	From: Jonathan A Rees <JAR>
	    Date: Monday, 20 May 1985, 10:48-EDT
	    From: Guy Steele <gls at AQUINAS>
	    Much to my surprise, I find that
	    (a)  ,,@  *is* supported by Common Lisp.
	    (b)  ,,@  is equivalent to  ,@(list ,@

	Alan told me that  `(,b)  was allowed to expand to  (cons b nil) , which
	would cause ,,@ to not work:  ``(,,@x)  ==>  `(cons ,@x nil)
	I don't have my CLTL handy, so I can't check this.

    Steele is right!  I have been making fun of the crazy grammar that the CL
    book uses to explain backquote expansion, but no more!  According to that
    grammar all of ",,@", ",@,", ",@,@" and ",@'," work as expected!  I didn't
    bother to work out all of the three level comma combinations, I expect they
    work too, but I can't figure out at the moment if ",@',,@" makes sense...

    We could start sending bug reports to all of the backquote implementation
    that fail to meet the CL specification.  I would predict that that would
    involve us in nit-picking discussions of the precise meaning of the list of
    "ligitimate" expansions given at the top of page 351.

My position is that the examples on page 351 are all correct, but there
should also be examples illustrating that they are not all correct if
any of the items is a ,@-d form.  I suspect that the problem in most
implementations that fail my funny example is that there is an
overzealous simplifier that is not checking for nested ,@ before
simplifying.

By the way, ',@x is not always an error!  It does make sense if x is
exactly a singleton list.  Sometimes this is useful in obscure cases.

Similarly, ,@',,@x makes sense if x is a singleton list.  See the end of
this note.

I have constructed a version of backquote that rigorously follows the
backquote grammar on pages 349-350, and then optionally applies a
simplifier of my own random device.  Here follow a bunch of examples.
For each example is shown:
	the original backquoted form
	the unsimplified expansion
	the simplified expansion
	result of applying EVAL once
	result of applying EVAL twice
	...
	result of applying EVAL as many times as there were backquotes


;;; First, some useful data for the examples.

(defun foo (x) (list 'fooed x))
(setq q '(r s))
(defun r (x) (reduce #'* x))
(setq r '(3 5))
(setq s '(4 6))


``(,,q)
(APPEND (LIST 'APPEND) (LIST (APPEND (LIST 'LIST) (LIST Q))))
(LIST 'LIST Q)
(LIST (R S))
(24)

``(,@,q)
(APPEND (LIST 'APPEND) (LIST Q))
Q
(R S)
24

``(,,@q)
(APPEND (LIST 'APPEND) (LIST (APPEND (LIST 'LIST) Q)))
(CONS 'LIST Q)
(LIST R S)
((3 5) (4 6))

``(,@,@q)
(APPEND (LIST 'APPEND) Q)
(CONS 'APPEND Q)
(APPEND R S)
(3 5 4 6)


`(foo `(bar ,,q))
(APPEND (LIST 'FOO)
        (LIST (APPEND (LIST 'APPEND)
                      (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'BAR)))))
                      (LIST (APPEND (LIST 'LIST) (LIST Q))))))
(LIST 'FOO (LIST 'LIST '(QUOTE BAR) Q))
(FOO (LIST (QUOTE BAR) (R S)))
(FOOED (BAR 24))

`(foo `(bar ,@,q))
(APPEND (LIST 'FOO)
        (LIST (APPEND (LIST 'APPEND)
                      (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'BAR)))))
                      (LIST Q))))
(LIST 'FOO (LIST 'CONS '(QUOTE BAR) Q))
(FOO (CONS (QUOTE BAR) (R S)))
(FOOED (BAR . 24))

`(foo `(bar ,,@q))
(APPEND (LIST 'FOO)
        (LIST (APPEND (LIST 'APPEND)
                      (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'BAR)))))
                      (LIST (APPEND (LIST 'LIST) Q)))))
(LIST 'FOO (LIST* 'LIST '(QUOTE BAR) Q))
(FOO (LIST (QUOTE BAR) R S))
(FOOED (BAR (3 5) (4 6)))

`(foo `(bar ,@,@q))
(APPEND (LIST 'FOO)
        (LIST (APPEND (LIST 'APPEND)
                      (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'BAR)))))
                      Q)))
(LIST 'FOO (LIST 'CONS '(QUOTE BAR) (CONS 'APPEND Q)))
(FOO (CONS (QUOTE BAR) (APPEND R S)))
(FOOED (BAR 3 5 4 6))


``(,',q)
(APPEND (LIST 'APPEND) (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST Q))))))
(LIST 'QUOTE (LIST Q))
(QUOTE ((R S)))
((R S))

``(,@',q)
(APPEND (LIST 'APPEND) (LIST (APPEND (LIST 'QUOTE) (LIST Q))))
(LIST 'QUOTE Q)
(QUOTE (R S))
(R S)


`(foo `(bar ,',q))
(APPEND (LIST 'FOO)
        (LIST (APPEND (LIST 'APPEND)
                      (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'BAR)))))
                      (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST Q))))))))
(LIST 'FOO (LIST 'QUOTE (LIST 'BAR Q)))
(FOO (QUOTE (BAR (R S))))
(FOOED (BAR (R S)))

`(foo `(bar ,@',q))
(APPEND (LIST 'FOO)
        (LIST (APPEND (LIST 'APPEND)
                      (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'BAR)))))
                      (LIST (APPEND (LIST 'QUOTE) (LIST Q))))))
(LIST 'FOO (LIST 'QUOTE (CONS 'BAR Q)))
(FOO (QUOTE (BAR R S)))
(FOOED (BAR R S))

`(foo `(bar ',',q))
(APPEND
 (LIST 'FOO)
 (LIST (APPEND (LIST 'APPEND)
               (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'BAR)))))
               (LIST (APPEND (LIST 'LIST)
                             (LIST (APPEND (LIST 'APPEND)
                                           (LIST (APPEND (LIST 'LIST)
                                                         (LIST (APPEND (LIST 'QUOTE)
                                                                       (LIST 'QUOTE)))))
                                           (LIST (APPEND (LIST 'LIST)
                                                         (LIST (APPEND (LIST 'QUOTE)
                                                                       (LIST Q))))))))))))
(LIST 'FOO (LIST 'QUOTE (LIST 'BAR (LIST 'QUOTE Q))))
(FOO (QUOTE (BAR (QUOTE (R S)))))
(FOOED (BAR (QUOTE (R S))))


```(,@',,@q)				;Alan's example
(APPEND (LIST 'APPEND)
        (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'APPEND)))))
        (LIST (APPEND (LIST 'LIST)
                      (LIST (APPEND (LIST 'APPEND)
                                    (LIST (APPEND (LIST 'LIST)
                                                  (LIST (APPEND (LIST 'QUOTE)
                                                                (LIST 'QUOTE)))))
                                    (LIST (APPEND (LIST 'LIST) Q)))))))
(LIST* 'LIST '(QUOTE QUOTE) Q)
(LIST (QUOTE QUOTE) R S)
(QUOTE (3 5) (4 6))
<error>					;but would be sensible if Q were the singleton list (R),
					; in which case third evaluation would produce (3 5).

Do you all believe these?

--Guy

∂22-May-85  0853	DCP@SCRC-STONY-BROOK.ARPA 	Backquote idioms  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85  08:53:29 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 241751; Wed 22-May-85 11:52:45-EDT
Date: Wed, 22 May 85 11:54 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: Backquote idioms
To: Guy Steele <gls%AQUINAS@THINK.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850522105634.1.GLS@MUNGO.ARPA>
Message-ID: <850522115407.9.NFEP@NEPONSET.SCRC.Symbolics.COM>

    Date: Wednesday, 22 May 1985, 10:56-EDT
    From: Guy Steele <gls%AQUINAS@THINK.ARPA>

    ```(,@',,@q)				;Alan's example
	...etc...
    (QUOTE (3 5) (4 6))
    <error>		;but would be sensible if Q were the singleton list (R),
			; in which case third evaluation would produce (3 5).

    Do you all believe these?

Does it matter?  RWK said he has never used a triple backquote.  Neither
have I.  There may be applications which are really good hacks, but can
they be maintained?  Even some double nested backquotes require enough
though that they should probably be avoided.  Conciseness and
compactness does not imply clarity and robustness.

∂22-May-85  0906	BSG@SCRC-RIVERSIDE.ARPA 	Backquote idioms    
Received: from SCRC-RIVERSIDE.ARPA by SU-AI.ARPA with TCP; 22 May 85  09:06:07 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-RIVERSIDE.ARPA via CHAOS with CHAOS-MAIL id 38658; Wed 22-May-85 12:05:20-EDT
Date: Wed, 22 May 85 12:04 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Backquote idioms
To: DCP@SCRC-QUABBIN.ARPA, gls%AQUINAS@THINK.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850522115407.9.NFEP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <850522120451.4.BSG@CONCORD.SCRC.Symbolics.COM>

    Date: Wed, 22 May 85 11:54 EDT
    From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>

	Date: Wednesday, 22 May 1985, 10:56-EDT
	From: Guy Steele <gls%AQUINAS@THINK.ARPA>

	```(,@',,@q)				;Alan's example
	    ...etc...
	(QUOTE (3 5) (4 6))
	<error>		;but would be sensible if Q were the singleton list (R),
			    ; in which case third evaluation would produce (3 5).

	Do you all believe these?

    Does it matter?  RWK said he has never used a triple backquote.  Neither
    have I.  There may be applications which are really good hacks, but can
    they be maintained?  Even some double nested backquotes require enough
    though that they should probably be avoided.  Conciseness and
    compactness does not imply clarity and robustness.

From LMFS:DEFSTORAGE (part of PL/I record simulating substrate of File System):

(defmacro once-onlify-index-offset (form)
  (let ((do-it-p (gensym))
	(was-ixo (gensym))
	(ggs (gensym)))
    `(let ((,do-it-p (not (atom *defstorage-index-offset*)))
	   (,was-ixo *defstorage-index-offset*))
       (let-if ,do-it-p				;Guaranteed needs wrapping now.
	       ((*defstorage-index-offset* '',ggs))
	 (wrap-if (symbolp ,was-ixo)		;Needs once-onlying at macro time.
		  `(once-only (,,was-ixo) ,:the-form)
		  (wrap-if ,do-it-p
			   ``(let ((,',',ggs ,,,was-ixo)) ,,:the-form)
			   ,form))))))

Admittedly, now that there are "language tools", this can be done better.

Also, idioms like

  `',
and the like should be discussed.  I have always been amused by
the analogy to tensor subscripts and superscripts and their
contraction rules.

∂22-May-85  1010	DCP@SCRC-STONY-BROOK.ARPA 	Backquote idioms  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85  10:09:41 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 241800; Wed 22-May-85 12:48:22-EDT
Date: Wed, 22 May 85 12:49 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: Backquote idioms
To: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>,
    DCP@SCRC-QUABBIN.ARPA, gls%AQUINAS@THINK.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850522120451.4.BSG@CONCORD.SCRC.Symbolics.COM>
Message-ID: <850522124944.2.NFEP@NEPONSET.SCRC.Symbolics.COM>

    Date: Wed, 22 May 85 12:04 EDT
    From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>

	Date: Wed, 22 May 85 11:54 EDT
	From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>

	    Date: Wednesday, 22 May 1985, 10:56-EDT
	    From: Guy Steele <gls%AQUINAS@THINK.ARPA>

	    ```(,@',,@q)				;Alan's example
		...etc...
	    (QUOTE (3 5) (4 6))
	    <error>		;but would be sensible if Q were the singleton list (R),
				; in which case third evaluation would produce (3 5).

	    Do you all believe these?

	Does it matter?  RWK said he has never used a triple backquote.  Neither
	have I.  There may be applications which are really good hacks, but can
	they be maintained?  Even some double nested backquotes require enough
	though that they should probably be avoided.  Conciseness and
	compactness does not imply clarity and robustness.

    From LMFS:DEFSTORAGE (part of PL/I record simulating substrate of File System):

    (defmacro once-onlify-index-offset (form)
      (let ((do-it-p (gensym))
	    (was-ixo (gensym))
	    (ggs (gensym)))
	`(let ((,do-it-p (not (atom *defstorage-index-offset*)))
	       (,was-ixo *defstorage-index-offset*))
	   (let-if ,do-it-p				;Guaranteed needs wrapping now.
		   ((*defstorage-index-offset* '',ggs))
	     (wrap-if (symbolp ,was-ixo)		;Needs once-onlying at macro time.
		      `(once-only (,,was-ixo) ,:the-form)
		      (wrap-if ,do-it-p
			       ``(let ((,',',ggs ,,,was-ixo)) ,,:the-form)
			       ,form))))))

    Admittedly, now that there are "language tools", this can be done better.

I would not want to maintain this, especially the line
			       ``(let ((,',',ggs ,,,was-ixo)) ,,:the-form)
Is that ,,, really correct, or are you using the fact that NIL and T are
self evaluating?  If you have to think about that for more than 10
seconds, something is wrong.  If it is obvious to you, I commend you for
your understanding of complex uses of backquote, and ask you to take
pity on the rest of us.  

I'll contend it can be done better without language tools.  For example,
you could build the form from the inside out, instead of your outside in
method.  Something like (I'm not sure what the semantics of :the-form
are, so I'll guess),
    (defmacro once-onlify-index-offset (form)
      (let ((do-it-p (gensym))
	    (was-ixo (gensym))
	    (ggs (gensym)))
	`(let ((,do-it-p (not (atom *defstorage-index-offset*)))
	       (,was-ixo *defstorage-index-offset*))
	   (let-if ,do-it-p ((*defstorage-index-offset* '',ggs))
	     (setq form (wrap-if ,do-it-p
				 `(let ((,',ggs ,,was-ixo)) ,:the-form)
				 form))
	     (setq form (wrap-if (symbolp ,was-ixo)
				 `(once-only (,,was-ixo) ,:the-form)
				 form))
	     form))))
I also have personal problems with macros that do computation instead of
translation.

    Also, idioms like

      `',
    and the like should be discussed.  I have always been amused by
    the analogy to tensor subscripts and superscripts and their
    contraction rules.


∂22-May-85  1012	DDYER@USC-ISIB.ARPA 	Local SPECIAL declarations   
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 22 May 85  10:10:59 PDT
Date: 22 May 1985 10:05:16 PDT
Subject: Local SPECIAL declarations
From: Dave Dyer       <DDYER@USC-ISIB.ARPA>
To: common-lisp@SU-AI.ARPA


 I want to put in a good word for the use of local rather than
global "SPECIAL" declarations.   Local Specials are the perfect
way to implement communication among functions that aren't
lexically related, and where the information being passed
in the specials is only needed among a few functions.  The
discipline of including the SPECIAL declaractions in every 
function focuses attention on the fact that this particular
variable is indeed "special" in the ordinary sense as well
as lisp's sense of the word.
-------

∂22-May-85  1142	smh@mit-eddie.ARPA 	Re:  Backquote idioms    
Received: from MIT-EDDIE.ARPA by SU-AI.ARPA with TCP; 22 May 85  11:41:56 PDT
Received: by mit-eddie.ARPA (4.12/4.8)  id AA16866; Wed, 22 May 85 14:33:01 edt
Date: Wed, 22 May 85 14:33:01 edt
From: Steven M. Haflich <smh@mit-eddie.ARPA>
Message-Id: <8505221833.AA16866@mit-eddie.ARPA>
To: common-lisp@su-ai.ARPA
Subject: Re:  Backquote idioms

    From @SU-AI.ARPA:DCP@SCRC-STONY-BROOK.ARPA Wed May 22 12:01:25 1985
    Subject: Backquote idioms

        Do you all believe these?

    Does it matter?  RWK said he has never used a triple backquote.
    Neither have I.  There may be applications which are really good
    hacks, but can they be maintained?  Even some double nested backquotes
    require enough though[t] that they should probably be avoided.
    Conciseness and compactness does not imply clarity and robustness.

I plead that it *does* matter.  It does not depend on the wisdom of
anyone (other than my good friend Bernie) writing triple nested
backquotes.  Consider rather automatic code generators.  Sometimes a
code generator needs output source code to a file, instead of
generating forms in memory.  Backquotes exist not to provide any
additional expressiveness in printed representations, but (roughly) to
make clearer constructions which embed the results of form evaluation
inside a template.  It is conceivable that a good automatic code
generator could use backquotes to aid human readablility of its
output, if only to aid debugging.  But an automatic code generator
might, like Bernie, lack sufficient discretion not to nest backquotes
in cases where readability is indeed *not* enhanced.

I apologise to BSG for pulling his leg a little, but the point is
serious:  CLTL must either document firmly that more than two levels
of backquotes are undefined, or else the reader grammar must be clear
and obeyed by all implementations.

∂22-May-85  1155	gls@AQUINAS.ARPA 	Backquote idioms 
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 22 May 85  11:55:02 PDT
Received: by THINK.ARPA with CHAOS id AA20244; Wed, 22 May 85 14:49:16 edt
Date: Wed, 22 May 85 14:49 EDT
From: Guy Steele <gls@AQUINAS.ARPA>
Subject: Backquote idioms
To: BSG@SCRC-STONY-BROOK.ARPA, DCP@SCRC-QUABBIN.ARPA, gls%AQUINAS@GODOT.ARPA
Cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.ARPA
In-Reply-To: <850522124944.2.NFEP@NEPONSET.SCRC.Symbolics.COM>
Message-Id: <850522144942.2.GLS@UBALDO.ARPA>

While I am not prepared to defend the clarity of the original
ONCE-ONLIFY-INDEX-OFFSET, I can say that the proposed replacement
bothers me because of the repeated SETQ-ing of the argument variable
FORM.  It's hard to condemn nesting per se, as LISP is perhaps the
quintessence of nesting languages.

I think it *is* quite clear, with an order of magnitude less than ten
seconds' thought, that ONCE-ONLIFY-INDEX-OFFSET is not depending on
repeated evaluation of T or NIL: the value of WAS-IXO is a gensym, which
is certainly not T or NIL.  (In fact, that gensym is bound by a LET
generated by the first level of backquote.)

I have, once or twice in my career, had a need to write a macro that
generates macros that generate code--and then need to abstract that
ouetr macro yet again.  This leads to triply nested backquotes.
Generating things incrementally this way is not difficult at all,
proceeding one layer of abstraction at a time.  I wanted to investigate
things from the point of the (human) reader, who sees the whole thing
all at once.

I use `',x a LOT.

--Guy

∂22-May-85  1206	Masinter.pa@Xerox.ARPA 	Backquote idioms
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 22 May 85  12:06:09 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 MAY 85 12:05:25 PDT
Date: 22 May 85 12:05 PDT
From: Masinter.pa@Xerox.ARPA
Subject: Backquote idioms
To: common-lisp@su-ai.ARPA

Many of these issues would be moot if the implementation of backquote
were specified in terms of what the read-macro generated, and the
implementation of the macros that it then expanded to. Implementations
could diverge from the "specified" one only if their divergence was
invisible.

It might mean that some of the current implementations might have to
change, but if the "specified" implementation is faithful in
implementing the book, it couldn't mean too much disruption in existing
code, could it?

∂22-May-85  1213	KMP@SCRC-STONY-BROOK.ARPA 	Re:  Backquote idioms  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85  12:12:48 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 241931; Wed 22-May-85 15:12:23-EDT
Date: Wed, 22 May 85 15:12 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Re:  Backquote idioms
To: smh@MIT-EDDIE.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8505221833.AA16866@mit-eddie.ARPA>
Message-ID: <850522151235.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Wed, 22 May 85 14:33:01 edt
    From: Steven M. Haflich <smh@mit-eddie.ARPA>

	From @SU-AI.ARPA:DCP@SCRC-STONY-BROOK.ARPA Wed May 22 12:01:25 1985
	Subject: Backquote idioms

	    Do you all believe these?

	Does it matter?  RWK said he has never used a triple backquote.
	Neither have I.  There may be applications which are really good
	hacks, but can they be maintained?  Even some double nested backquotes
	require enough though[t] that they should probably be avoided.
	Conciseness and compactness does not imply clarity and robustness.

    I plead that it *does* matter.  It does not depend on the wisdom of
    anyone (other than my good friend Bernie) writing triple nested
    backquotes.  Consider rather automatic code generators.  Sometimes a
    code generator needs output source code to a file, instead of
    generating forms in memory.  Backquotes exist not to provide any
    additional expressiveness in printed representations, but (roughly) to
    make clearer constructions which embed the results of form evaluation
    inside a template.  It is conceivable that a good automatic code
    generator could use backquotes to aid human readablility of its
    output, if only to aid debugging.  But an automatic code generator
    might, like Bernie, lack sufficient discretion not to nest backquotes
    in cases where readability is indeed *not* enhanced.

Indeed. All too much mail on this list recently seems to address the 
issue of what `reasonable people' should do. As much as possible, 
people shouldn't be writing programs; programs should be writing programs. 
And as such, it matters critically that language features be clearly 
defined to arbitrary levels of complexity. eg, I have programs that
convert backquote syntax to LIST syntax and back, and I would be -very- 
aggravated if I had to pass level-number parameters around to make sure 
I wasn't nesting excessively. Just because people get bogged down with
the number 7 plus or minus 2 doesn't mean programs do...

I also disagree fully with the notion that 3-level is too deep. I think
 ,',',',',', is quite readable. I don't think ,',,',',, is as readable.
Probably most of us find CAAAAAAAAR more readable than CADAADDAAR, though.
I do use triply-nested backquote, though, and believe it to be even
stylistically reasonable on occassion.

    I apologise to BSG for pulling his leg a little, but the point is
    serious:  CLTL must either document firmly that more than two levels
    of backquotes are undefined, or else the reader grammar must be clear
    and obeyed by all implementations.

Fine for a style handbook to claim that common idioms are preferred,etc
but not fine for the language spec to take any stand at all other than
to say what the definition is in a way that is neatly recursively defined.

∂22-May-85  1343	DCP@SCRC-STONY-BROOK.ARPA 	Re:  Backquote idioms  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85  13:41:09 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 242016; Wed 22-May-85 16:40:27-EDT
Date: Wed, 22 May 85 16:41 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: Re:  Backquote idioms
To: Steven M. Haflich <smh@MIT-EDDIE.ARPA>,
    Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8505221833.AA16866@mit-eddie.ARPA>,
             <850522151235.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <850522164152.8.NFEP@NEPONSET.SCRC.Symbolics.COM>

I am not saying that 69 levels of backquote should not be defined.  I am
saying that it should not be encouraged for people writing programs.
(After all, how do program writing programs bootstrap?)  I have no
objections to programs outputing 69 levels of backquoted structure, as
long as a human never has to go near it; only some (possibly other)
program should need to reinterpret it.

As for what CLtL should say, I think it should say that backquote works
to indefinite levels of nesting.  I think it should give the common
idioms.  I think it should say that the deeper the nesting, the greater
the loss of clarity to the human reader and the <some number> (2 for me
and probably most people in this day and age) is what is considered
within the normal style of programming.  [I refer the audience to "The
Program Feature" where it uses the word 'style' many times.]

Note: I finally found where backquote is documented.  it would be nice
if there were a 'backquote' entry in the index.

∂22-May-85  1600	RWK@SCRC-STONY-BROOK.ARPA 	Backquote idioms  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85  16:00:10 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 242126; Wed 22-May-85 18:59:40-EDT
Date: Wed, 22 May 85 18:59 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Backquote idioms
To: Guy Steele <gls%AQUINAS@THINK.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850522105634.1.GLS@MUNGO.ARPA>
Message-ID: <850522185932.7.RWK@CROW.SCRC.Symbolics.COM>

    Date: Wednesday, 22 May 1985, 10:56-EDT
    From: Guy Steele <gls%AQUINAS@THINK.ARPA>
    By the way, ',@x is not always an error!  It does make sense if x is
    exactly a singleton list.  Sometimes this is useful in obscure cases.

    Similarly, ,@',,@x makes sense if x is a singleton list.  See the end of
    this note.

I think "is an error" is still the right phrase to apply.
Just because there happens to be a value that does not result
in an error does not make it proper.  I think it is *MUCH*
clearer to write ',(CAR X).  You can do additional error
checking on X if you like, and signal a comprehensible
error, rather than depending on QUOTE to check!  (I have
seen implementations where QUOTE did not check).

∂22-May-85  1927	Moon@SCRC-STONY-BROOK.ARPA 	Special form terminology   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85  19:27:30 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 242291; Wed 22-May-85 22:19:24-EDT
Date: Wed, 22 May 85 22:19 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Special form terminology
To: Common-Lisp@SU-AI.ARPA
References: <850522182532.3.ACW@ROCKY-MOUNTAINS.SCRC.Symbolics.COM>
Message-ID: <850522221918.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

The following message may be of interest to you:

Date: Wed, 22 May 85 18:25 EDT
From: Allan C. Wechsler <acw@WAIKATO.SCRC.Symbolics.COM>

The line we have taken at Ed. Services is that macros are a subclass of
special operator.  The taxonomic tree we have been using looks like
this:

		    Operators
	      ←←←←←←←←←←/\←←←←←
	      |               |
	  Functions    Special Operators
		 ←←←←←←←←←←←←/\←←←←←←←←←←←←
		 |                        |
	       Macros      Primitive Special Operators (PSOs)

This way we have a name for each useful subdivision.  Also, we need not
distinguish macros from PSOs when it suits us not to.  I think that
whether a special operator is a PSO or a macro is often an
implementation detail, which we shouldn't have to document in case we
change our minds.

So when I teach DEFSTRUCT, for example, I say it's a special operator.
The students don't care whether it's primitive or not.  They do care
that it does not have function semantics.


∂22-May-85  1927	DLW@SCRC-STONY-BROOK.ARPA 	Macros -> declarations 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85  19:27:18 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 242258; Wed 22-May-85 21:20:26-EDT
Date: Wed, 22 May 85 21:20 EDT
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Macros -> declarations
To: Fahlman@CMU-CS-C.ARPA, Masinter.pa@XEROX.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12111607133.BABYL@CMU-CS-C.ARPA>
Message-ID: <850522212037.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
Reply-To: dlw@SCRC-STONY-BROOK.ARPA

    Date: Thu, 16 May 1985  22:45 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
								       But
    we should only make this move so late in the game if just about everyone
    else feels likewise.

    -- Scott

Taking this a few steps further, I think it's important that we decide
what our philosophy is about "changes to Common Lisp", particularly in
light of the fact that the manual has been published and is now on the
shelves of bookstores.  What does it mean for us to "make a move"?

This is not intended as a criticism of Masinter's suggestion or any
other particular suggestion (I actually like the suggestion, although I
haven't considered it carefully).  I just think we'd spend our time
better if it were somewhat more clear what game we are playing and what
the rules are, and I'm worried that we're spending a great deal of time
and energy designing Common Lisp after the horse has been let out of the
barn.  Are we really designing a new second-generation Common Lisp?  Or
are we proposing to tell the world shortly that the book isn't really
the Real Common Lisp, please make the following forty changes to your
copy?  Once we have answered this question, then we can agree on a general
philosophy about what degree of change is allowable.

∂22-May-85  2057	RAM@CMU-CS-C.ARPA 	Adjustable and displaced arrays
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 22 May 85  20:56:58 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 22 May 85 23:56:52-EDT
Date: Wed, 22 May 1985  23:56 EDT
Message-ID: <RAM.12113193061.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   common-lisp@SU-AI.ARPA
Subject: Adjustable and displaced arrays


I am somewhat confused about the interaction between array adjustment
and displacement.

In CLTL p298:

    Note that if the array a is created displaced to array b and
    subsequently array b is given to adjust-array, array a will still
    be displaced to array b; the effects of this displacement and the
    rule of row-major storage order must be taken into account.

What is this trying to say?  Is this a warning to the user or a threat
to the implementor?  The obvious interpretation of this statement
seems to require that all non-simple arrays contain a list of all the
other array headers that share the same data so that they can be fixed
up when the array is adjusted.  The answer that you stick in a
forwarding pointer is not acceptable.

The statement in the manual also doesn't answer the question of what
happens to array b if array a is adjusted.  Is it legal or meaningful
to have arrays which are both displaced to another array and
adjustable?  What are the semantics of adjusting such an array?

  Rob

∂22-May-85  2108	DLW@SCRC-STONY-BROOK.ARPA 	EQUALP hash tables (and more ...)     
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85  21:08:22 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 242358; Thu 23-May-85 00:07:47-EDT
Date: Thu, 23 May 85 00:08 EDT
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: EQUALP hash tables (and more ...) 
To: Fahlman@CMU-CS-C.ARPA, hoey@NRL-AIC.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12110566837.BABYL@CMU-CS-C.ARPA>
Message-ID: <850523000805.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
Reply-To: dlw@SCRC-STONY-BROOK.ARPA

    Date: Sun, 12 May 1985  23:30 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

    So I guess the point is that given magic EQ and EQL hashtables that work
    even when a GC moves things, you can use these to build a slower version
    of EQ and EQL hashtables (and related thingies) that also works, without
    giving the users direct access to the magic.  Interesting in principle,
    but not the way you'd want to do anything real.

Au contraire.  Multics Maclisp uses this to implement the wonderful
Maclisp MAKNUM and MUNKAM functions.  I suppose it depends on what
you mean by "real"...

∂23-May-85  0130	STEINER@RUTGERS.ARPA 	Does FORMAT handle multiple values    
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 23 May 85  01:30:41 PDT
Date: 23 May 85 04:30:24 EDT
From: Dave <Steiner@RUTGERS.ARPA>
Subject: Does FORMAT handle multiple values
To: Common-Lisp@SU-AI.ARPA


Does format handle multiple values at all?  What I want to do is
something like the following (only this throws away everything but
the first value):

(format t "~S~%" (progn ... (values ...)))

Is there anyway to handle this (or should it be handling it but there
is a bug in our CLisp)?

BTW, I'm sure that I can do this with a values-list and the iteration
directive but I wanted to know if I can do this without knowing a
head of time whether I would be getting mv's back or not.

thanks,
ds
uucp:   ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!steiner
arpa:   Steiner@RUTGERS
-------

∂23-May-85  0157	RAM@CMU-CS-C.ARPA 	Does FORMAT handle multiple values  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 23 May 85  01:57:27 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Thu 23 May 85 04:57:06-EDT
Date: Thu, 23 May 1985  04:57 EDT
Message-ID: <RAM.12113247712.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   Dave <Steiner@RUTGERS.ARPA>
Cc:   Common-Lisp@SU-AI.ARPA
Subject: Does FORMAT handle multiple values
In-reply-to: Msg of 23 May 1985  04:30-EDT from Dave <Steiner at RUTGERS.ARPA>

    Date: Thursday, 23 May 1985  04:30-EDT
    From: Dave <Steiner at RUTGERS.ARPA>
    To:   Common-Lisp at SU-AI.ARPA
    Re:   Does FORMAT handle multiple values

    (format t "~S~%" (progn ... (values ...)))

I'm not sure what you think that code is supposed to do, but there are
two ways that I can think of to turn MV's into format arguments (or
any other kind of arguments).  You can use Multiple-Value-List (not
values-list, as you said) to get a list, or you can use
Multiple-Value-Call.

In Common Lisp, there is no user-visible distinction between returning
one value and returning one "multiple value", so the
multiple-value-### primitives will work fine even if only one value is
being returned.

  Rob

∂23-May-85  0503	RAM@CMU-CS-C.ARPA 	Get-Setf-Method 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 23 May 85  05:03:34 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Thu 23 May 85 08:03:33-EDT
Date: Thu, 23 May 1985  08:03 EDT
Message-ID: <RAM.12113281659.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   common-lisp@SU-AI.ARPA
Subject: Get-Setf-Method


    Get-Setf-Method should take an (optional?) environment argument so
that it can expand macros correctly. 

  Rob

∂23-May-85  0657	greek@DEC-HUDSON 	Adjusting Displaced Arrays 
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 23 May 85  06:57:36 PDT
Date: Thu, 23 May 85 09:57:23 EDT
From: greek@DEC-HUDSON
Subject: Adjusting Displaced Arrays
To: common-lisp@su-ai

We were so confused about the problem of adjusting displaced arrays,
we simply don't allow it in VAX LISP.  I'd sure appreciate some
thoughts on the matter myself.

- Paul

∂23-May-85  0747	gls%AQUINAS@THINK.ARPA 	Does FORMAT handle multiple values  
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 23 May 85  07:47:31 PDT
Received: by THINK.ARPA with CHAOS id AA04605; Thu, 23 May 85 10:42:58 edt
Date: Thursday, 23 May 1985, 10:43-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Does FORMAT handle multiple values
To: Common-Lisp%SU-AI.ARPA@THINK.ARPA
Cc: gls%AQUINAS@THINK.ARPA
In-Reply-To: Your message of 23 May 85 04:30-EDT
Message-Id: <850523104328.2.GLS@YON.ARPA>

    Date: 23 May 85 04:30:24 EDT
    From: Dave <Steiner@RUTGERS.ARPA@think>


    Does format handle multiple values at all?  What I want to do is
    something like the following (only this throws away everything but
    the first value):

    (format t "~S~%" (progn ... (values ...)))

I would write this as

    (multiple-value-call #'format t "~S~%" (progn ... (values ...)))

thereby causing multiple values from each argument form to be
"spread out" as separate arguments to FORMAT.

--Guy

∂23-May-85  0757	gls%AQUINAS@THINK.ARPA 	Adjustable and displaced arrays
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 23 May 85  07:57:41 PDT
Received: by THINK.ARPA with CHAOS id AA04649; Thu, 23 May 85 10:51:00 edt
Date: Thursday, 23 May 1985, 10:51-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Adjustable and displaced arrays
To: common-lisp%SU-AI@THINK.ARPA
Cc: gls%AQUINAS@THINK.ARPA
In-Reply-To: <RAM.12113193061.BABYL@CMU-CS-C.ARPA>
Message-Id: <850523105129.3.GLS@YON.ARPA>

    Date: Wed, 22 May 1985  23:56 EDT
    From: Rob MacLachlan <RAM@CMU-CS-C.ARPA@think>

    I am somewhat confused about the interaction between array adjustment
    and displacement.

    In CLTL p298:

	Note that if the array a is created displaced to array b and
	subsequently array b is given to adjust-array, array a will still
	be displaced to array b; the effects of this displacement and the
	rule of row-major storage order must be taken into account.

    What is this trying to say?  Is this a warning to the user or a threat
    to the implementor?  The obvious interpretation of this statement
    seems to require that all non-simple arrays contain a list of all the
    other array headers that share the same data so that they can be fixed
    up when the array is adjusted.  The answer that you stick in a
    forwarding pointer is not acceptable.

This should be elucidated in the next edition.  If you put this paragraph
beside the descriptions of :DISPLACED-TO and :DISPLACED-INDEX-OFFSET on pages
288-289, and assume that array a is essentially unaffected, one concludes
that array a is still displaced to array b, the mapping between elements
still being determined by taking the elements in row-major order and then
mapping element k of array a to element k+n of array b, where n is the
:displaced-index-offset for array a.  The only difference is that array b,
having been adjusted, may have a different row-major ordering.  (A nasty
problem is that the roles of arrays A and B are reversed on pages 288 and
298!  Sorry about that.)

    The statement in the manual also doesn't answer the question of what
    happens to array b if array a is adjusted.  Is it legal or meaningful
    to have arrays which are both displaced to another array and
    adjustable?  What are the semantics of adjusting such an array?

Well, page 298 says that if A is displaced to X, then after adjustment of A,
A has no relationship to X, nor does the returned result, unless X is
respecified explicitly in the :displaced-to option to ADJUST-ARRAY.
I admit that this fails to state explicitly that X is unaffected.

      Rob

∂23-May-85  0818	gls%AQUINAS@THINK.ARPA 	Rules of the game    
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 23 May 85  08:17:49 PDT
Received: by THINK.ARPA with CHAOS id AA04768; Thu, 23 May 85 11:09:39 edt
Date: Thursday, 23 May 1985, 11:10-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Rules of the game
To: common-lisp%SU-AI@THINK.ARPA
Cc: gls%AQUINAS@THINK.ARPA
In-Reply-To: <850522212037.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <850523111007.4.GLS@YON.ARPA>

    Date: Wed, 22 May 85 21:20 EDT
    From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM@think>

				 ... I think it's important that we decide
    what our philosophy is about "changes to Common Lisp", particularly in
    light of the fact that the manual has been published and is now on the
    shelves of bookstores.  What does it mean for us to "make a move"?

				  ...  I just think we'd spend our time
    better if it were somewhat more clear what game we are playing and what
    the rules are, and I'm worried that we're spending a great deal of time
    and energy designing Common Lisp after the horse has been let out of the
    barn.  Are we really designing a new second-generation Common Lisp?  Or
    are we proposing to tell the world shortly that the book isn't really
    the Real Common Lisp, please make the following forty changes to your
    copy?  Once we have answered this question, then we can agree on a general
    philosophy about what degree of change is allowable.

My attitude is that the horse is indeed out of the barn.  I believe that changes
of the following five kinds are appropriate.  I list them in order of increasing
seriousness and likeliness to cause disruption:

(1) Typographical and editorial corrections (such as a better index!).  In
this category I would place changes in terminology that would leave code
unaffected.  For example, changing the term "special form" to "special
operator" would fall into this category, but renaming SPECIAL-FORM-P to
SPECIAL-OPERATOR-P would not.

(2) Substantive elucidations of intent.  An example of this is my reply earlier
today elucidating what is supposed to happen when adjusting an array to which
another array is displaced.

(3) Compatible extensions to the language (such as adding a quaternion data type,
or flavors, or Bessel functions, or PARSE-BODY, or the proposed three-variable
&BODY feature for DEFMACRO).

(4) Incompatible changes to existing features because they cannot possibly
operate correctly as specified.  An example is the recent report that
GET-SETF-METHOD needs to take an environment argument.

(5) Incompatible changes required to bring Common Lisp into conformance with
an external standard.  This category is fraught with danger, and the benefits
must be weighed carefully.  An example is the proposal to change the branch
cuts of arctangent to conform to expected practice by the APL and IEEE
proposed floating-point communities.


I believe that it is too late for incompatible changes for the sake of
clarity, consistency, or convenience.  Therefore I would strongly oppose
renaming or removing any existing function or feature.  (This represents a
reversal of my previous position on the proposal to eliminate expansion of
macros into declarations.)

--Guy

∂23-May-85  0841	fateman%ucbdali@Berkeley 	rules of the game  
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 23 May 85  08:40:52 PDT
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.46)
	id AA09771; Thu, 23 May 85 08:38:42 pdt
Received: by ucbdali.ARPA (4.24/4.46)
	id AA12133; Thu, 23 May 85 08:40:55 pdt
Date: Thu, 23 May 85 08:40:55 pdt
From: fateman%ucbdali@Berkeley (Richard Fateman)
Message-Id: <8505231540.AA12133@ucbdali.ARPA>
To: common-lisp@su-ai
Subject: rules of the game

It seems to me that this was brought up at the Monterey meeting (by me).
That CLTL was an informal description of an approach to a Lisp dialect,
leaving a considerable amount of discretion to the implementor.  A language
consistent with CLTL could be called compatible with CL'84 (say).  When/if
there is another CL, one which has an official standard-setting description,
it could be called (say) CL '86.   There could also be some subset CL standard.

The relationship between CL'84 and CL '86 could resemble the relationships
between the various Fortrans.  Namely, they have similar names and intentions,
but are not necessarily compatible in detail.

To imply that CL is static will encourage people to design and promulgate
the YADOCL family of languages (Yet Another Derivative of Common Lisp).

Now if CL'84 stands in the same relation to Lisps of the next 20 years as
Lisp 1.5 stood to Lisps of the previous 20 years, this may also be OK.
It doesn't solve DARPA's problems of complete compatibility and portability
of code, but neither, after all, did CL '84.

I think it would be a mistake to be stubborn about changes.

P.S. the location of the branch cut for the complex atan is not likely to
affect any existing CL code, and I think that the IEEE or APL standards
committee might be followed without injury.

∂23-May-85  0939	GRISS%hp-hulk.csnet@csnet-relay.arpa 	Re: Local SPECIAL declarations  
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 23 May 85  09:39:07 PDT
Received: from hplabs by csnet-relay.csnet id ad04548; 23 May 85 12:28 EDT
Received: by HP-VENUS id AA02099; Thu, 23 May 85 05:49:47 pdt
Message-Id: <8505231249.AA02099@HP-VENUS>
Date: Thu 23 May 85 05:49:20-PDT
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Re: Local SPECIAL declarations
To: DDYER, common-lisp@su-ai.ARPA
Cc: GRISS@hplabs.CSNET
In-Reply-To: Message from "Dave Dyer <DDYER@USC-ISIB@HP-VENUS>" of Wed 22 May 85 10:05:16-PDT
Source-Info:  From (or Sender) name not authenticated.

I too like the notion of the local special. I once used a language
(BALM) that exploited $ at the point of binding as a readmacro;

(defun foo (x $y z)
   (setq y 3))

which effectively expanded into

(defun foo (x (special y) z)
   (setq y 3))

Perhaps the $ should have been used on ALL references to the special
y for more consistency.

It was very comfortable to use.

M
-------

∂23-May-85  1038	RAM@CMU-CS-C.ARPA 	Adjustable and displaced arrays
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 23 May 85  10:38:37 PDT
Received: from CMU-CS-C.ARPA (cmu-cs-c.arpa.ARPA) by THINK.ARPA id AA06595; Thu, 23 May 85 13:34:54 edt
Received: ID <RAM@CMU-CS-C.ARPA>; Thu 23 May 85 13:35:06-EDT
Date: Thu, 23 May 1985  13:35 EDT
Message-Id: <RAM.12113342010.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Guy Steele <gls%AQUINAS@THINK.ARPA>
Cc: common-lisp%SU-AI@THINK.ARPA
Subject: Adjustable and displaced arrays
In-Reply-To: Msg of 23 May 1985 10:51-EDT from Guy Steele <gls%AQUINAS at THINK.ARPA>


    I'm still not sure we have communicated here.  My specific concern
is that if I am interpreting you intent correctly, the implementation
of complex arrays in Spice Lisp (and derived implementations) is
seriously flawed.

    Spice Lisp implements complex arrays as a header which contains,
among other things, a pointer to the one-dimensional simple-array
which actually holds tha data, and the displaced-index-offset.  When a
displaced array is made, the data vector is the data vector of the
original array, and the offset is set appropriately.

    With this representation displacement is handled with minimal
additional overhead.  The problem is that the header for the displaced
array contains the pointer to the actual data vector for the original
array.  If the original array is adjusted, the aliasing will be lost.

    If this implementation is indeed incorrect, what is the correct
implementation?

  Rob

∂23-May-85  1113	DLW@SCRC-STONY-BROOK.ARPA 	Re:  Backquote idioms  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 May 85  11:13:13 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 242733; Thu 23-May-85 14:08:26-EDT
Date: Thu, 23 May 85 14:09 EDT
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Re:  Backquote idioms
To: DCP@SCRC-QUABBIN.ARPA, smh@MIT-EDDIE.ARPA, KMP@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850522164152.8.NFEP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <850523140903.1.DLW@CHICOPEE.SCRC.Symbolics.COM>
Reply-To: dlw@SCRC-STONY-BROOK.ARPA

    Date: Wed, 22 May 85 16:41 EDT
    From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>

    I am not saying that 69 levels of backquote should not be defined.  I am
    saying that it should not be encouraged for people writing programs.

I rather doubt that any users, upon seeing the explanation in the manual,
will then rush to their terminals so use triple-nested backquotes.  It's
not something that people will be "encouraged" to use; in fact, most people
will have a very hard time figuring out why you'd ever use it.  So I don't
think there's much to worry about.

∂23-May-85  1336	DCP@SCRC-STONY-BROOK.ARPA 	Adjustable and displaced arrays  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 May 85  13:36:17 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 242854; Thu 23-May-85 16:35:44-EDT
Date: Thu, 23 May 85 16:37 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: Adjustable and displaced arrays
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12113193061.BABYL@CMU-CS-C.ARPA>
References: <RAM.12113193061.BABYL@CMU-CS-C.ARPA>,
            The message of 23 May 85 09:57-EDT from greek@DEC-HUDSON
Message-ID: <850523163729.9.NFEP@NEPONSET.SCRC.Symbolics.COM>

For references, the following describes how Lisp Machines do displacing.

If array a is created displaced to array b, then there are two items of
interest in this relationship.  (1) Array a is holding onto array b, and
array a has a number stored in it which is the offset into b.

If array b is then adjusted, nothing "physically" happens to array a.
Array a still is still holding onto array b and still has the same
offset within b, independent of what b looked like before and after b
was adjusted.

I order for a to be >>meaningfully displaced<< to b, especially when b
has been adjusted, the rules of row major storage must be taken into
account.  By the above description, people programming LispMs need to
beware, not the people implementing CL for LispMs.

∂23-May-85  1456	RPG   	Yellow pages 
 ∂21-May-85  0010	GRISS%hp-hulk.csnet@csnet-relay.arpa 	Yellow pages
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 21 May 85  00:10:44 PDT
Received: from hplabs by csnet-relay.csnet id ad18529; 21 May 85 3:00 EDT
Received: by HP-VENUS id AA16145; Mon, 20 May 85 20:38:46 pdt
Resent-Message-Id: <8505210338.AA16145@HP-VENUS>
Message-Id: <8505210338.AA16145@HP-VENUS>
Mail-From: GRISS created at 20-May-85 20:38:01
Date: Mon 20 May 85 20:38:00-PDT
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Yellow pages
To: fahlman@cmu-cs-c.ARPA
Cc: GRISS@hplabs.CSNET
Resent-Date: Mon 20 May 85 20:38:23-PDT
Resent-From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Resent-To: rpg@su-ai.ARPA
Source-Info:  From (or Sender) name not authenticated.

Scott:

I picked up the CATLOG.TXT. Thanks. I was a bit disappointed to see
how little "portable" code there was; HIST and TIMING were all I saw.

Is catalog up todate? What else could be released?
M
-------

∂23-May-85  1539	STEINER@RUTGERS.ARPA 	Re: Does FORMAT handle multiple values
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 23 May 85  15:38:51 PDT
Received: from RUTGERS.ARPA (rutgers-gw.ARPA) by THINK.ARPA id AA09073; Thu, 23 May 85 18:32:45 edt
Date: 23 May 85 18:32:54 EDT
From: Dave <Steiner@RUTGERS.ARPA>
Subject: Re: Does FORMAT handle multiple values
To: gls%AQUINAS@THINK.ARPA, RAM@CMU-CS-C.ARPA
Cc: Common-Lisp%SU-AI.ARPA@THINK.ARPA
In-Reply-To: Message from "Guy Steele <gls%AQUINAS@THINK.ARPA>" of 17 Nov 1858 13:01:42 EST


    Date: Thu, 23 May 1985  04:57 EDT
    From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
    Subject: Does FORMAT handle multiple values

	Date: Thursday, 23 May 1985  04:30-EDT
	From: Dave <Steiner at RUTGERS.ARPA>
	To:   Common-Lisp at SU-AI.ARPA
	Re:   Does FORMAT handle multiple values

	(format t "~S~%" (progn ... (values ...)))

    I'm not sure what you think that code is supposed to do, but there are
    two ways that I can think of to turn MV's into format arguments (or
    any other kind of arguments).  You can use Multiple-Value-List (not
    values-list, as you said) 

Oops, I always mix up Values-List and Multiple-Value-List.  Obviously
need a TWIM (Type What I Mean :-)).

			      to get a list, or you can use
    Multiple-Value-Call.

What I'm doing is generating a bunch of test cases for random
functions, ie (format t "~S~%" (foo ...)).  I'd rather not have to do
a Multiple-Value-List around everything for the few times that
something returns MVs.  I was hoping that format could handle
multiple values in some way that I wouldn't have to know if I was
dealing with MVs or not.  Doesn't look like it.  Oh well.

    In Common Lisp, there is no user-visible distinction between returning
    one value and returning one "multiple value", so the
    multiple-value-### primitives will work fine even if only one value is
    being returned.

      Rob

    Date: Thursday, 23 May 1985, 10:43-EDT
    From: Guy Steele <gls%AQUINAS@THINK.ARPA>
    Subject: Does FORMAT handle multiple values

	Date: 23 May 85 04:30:24 EDT
	From: Dave <Steiner@RUTGERS.ARPA@think>


	Does format handle multiple values at all?  What I want to do is
	something like the following (only this throws away everything but
	the first value):

	(format t "~S~%" (progn ... (values ...)))

    I would write this as

	(multiple-value-call #'format t "~S~%" (progn ... (values ...)))

In this case you either have to know how many values you are going to
be returning or use the iteration directive in the format string.  If
you type this in as written (assuming that you get more than one
value back from values), you only get one value printed.

    thereby causing multiple values from each argument form to be
    "spread out" as separate arguments to FORMAT.

    --Guy

Oh well, looks like I'm going to have to have a separate case for
MVs.  thanks anyway.

ds
uucp:   ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!steiner
arpa:   Steiner@RUTGERS
-------

∂23-May-85  1819	GSB@MIT-MC 	Get-Setf-Method   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 23 May 85  18:19:33 PDT
Date: Thu, 23 May 85 21:17:35 EST
From: Glenn S. Burke <GSB@MIT-MC>
Subject: Get-Setf-Method
To: RAM@CMU-CS-C
cc: common-lisp@SU-AI
Message-ID: <[MIT-MC].516353.850523.GSB>

    Date: Thu, 23 May 1985  08:03 EDT
    From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>


        Get-Setf-Method should take an (optional?) environment argument so
    that it can expand macros correctly. 

I pointed this out months ago, and i thought we had established this
as a given.

∂23-May-85  2022	DLW@SCRC-STONY-BROOK.ARPA 	Fahlman's comments     
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 May 85  20:21:59 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 243087; Thu 23-May-85 23:21:08-EDT
Date: Thu, 23 May 85 23:21 EDT
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Fahlman's comments 
To: RPG@SU-AI.ARPA, quinquevirate@SU-AI.ARPA, ohlander@USC-ISI.ARPA,
    squires@USC-ISI.ARPA
In-Reply-To: The message of 9 May 85 01:46-EDT from Dick Gabriel <RPG@SU-AI.ARPA>
Message-ID: <850523232152.1.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Reply-To: dlw@SCRC-STONY-BROOK.ARPA

    Date: 08 May 85  2246 PDT
    From: Dick Gabriel <RPG@SU-AI.ARPA>

    The point of keeping (some) of the validation code `secret' is to
    make sure that people don't cheat and get exactly the validation
    code to work. I believe that is approximtely owow  ADA is done. 

Just for the record, I belive that starting with this year's test suite,
the ADA people got rid of the secret part.  I don't know why (though I
have suspicions that the reason was not technical).  I think I agree
with you that having a secret part to keep people honest is a good idea
and doesn't really incur substantial extra expense.

∂23-May-85  2302	GSB@MIT-MC 	Re: Adjustable and displaced arrays   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 23 May 85  23:02:26 PDT
Date: Fri, 24 May 85 02:01:24 EST
From: Glenn S. Burke <GSB@MIT-MC>
Sender: GSB0@MIT-MC
Subject: Re: Adjustable and displaced arrays
To: RAM@CMU-CS-C
cc: common-lisp@SU-AI
Message-ID: <[MIT-MC].516737.850524.GSB0>

It sounds like NIL implements complex arrays in a somewhat similar
manner to Spice Lisp.  However, in the general case, the complex array
header might have to point to another complex array header.  As a
result an AREF might have to iterate to find the eventual data vector.
Only in the case where none of the involved arrays (other than the
outermost) are adjustable can the data vector be "cached" as your
implementation does.

For instance.  
	(setq c (make-array '(5 5) :adjustable t))
C is a complex array header, whose displaced-to field (like your data
vector) is a simple vector 25 long, and whose displaced-index-offset
field holds 0.
	(setq b (make-array 20 :displaced-to c :displaced-index-offset 5))
B is a complex array header, whose displaced-to field is C, because C is
adjustable, and its data vector might get thrown out and replaced by a
new one.
	(setq a (make-array '(3 3) :displaced-to b :displaced-index-offset 4))
A is a complex array header, whose displaced-to field is C.  It is NOT
B, because B is not adjustable, so can be optimized out.  Its
displaced-index-offset field is 4, which was obtained by adding its
own with B's.

(aref A i j) operates by computing a row-major-order index into A,
using the dimensionality of A.  Then (because this is a complex array)
the displaced-index-offset (9) is added to this, and that is used as a
row-major-order index into its displaced-to array, C.  C is itself a
complex array, so the process iterates once more.  C's
displaced-index-offset is 0 and its displaced-to happens to be just a
simple vector.
--------------
Moon and i discussed this specification some well over a year ago,
because i was somewhat disturbed at the efficiency penalty in some of
the displacement.  We pretty much decided that in spite of the hair
needed, this model of array displacement was reasonable, and at least
simple arrays can be crunched pretty efficiently.  (The point being
that i was somewhat put off by the implementation necessary.)  In NIL,
the sequence functions operate internally by reducing a sequence to a
simple sequence and an offset, and then crunch on the simple sequence.
So, for instance, doing REPLACE on two strings, no matter how
adjustable or displaced, will eventually use the vax MOVC3
instruction, as implemented by a primitive which moves "bytes" from
one simple binary data object to another (the same thing works on
bignums).

The one thing i do NOT like about the specification is how elements
are preserved by adjust-array.  The replacement of those things with
matching indices is pretty random, and pretty inefficient to boot.  It
should just preserve the row-major-order data insofar as that is
possible (truncating, or extending with some initial-element or
"undefined" value, depending on whether the total-size is being
decreased or increased).

∂24-May-85  0909	DLW@SCRC-STONY-BROOK.ARPA 	Rules of the game 
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 24 May 85  09:09:39 PDT
Received: from SCRC-STONY-BROOK.ARPA (scrc-stony-brook.arpa.ARPA) by THINK.ARPA id AA14729; Fri, 24 May 85 12:05:52 edt
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 243338; Fri 24-May-85 11:53:16-EDT
Date: Fri, 24 May 85 11:54 EDT
From: Daniel L. Weinreb <DLW%TENEX.SCRC.Symbolics.COM@THINK.ARPA>
Subject: Rules of the game
To: gls%AQUINAS@THINK.ARPA, common-lisp%SU-AI@THINK.ARPA
In-Reply-To: <850523111007.4.GLS@YON.ARPA>
Message-Id: <850524115418.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Reply-To: dlw@SCRC-STONY-BROOK.ARPA

I agree with all of this, except for point 3 (Compatible extensions),
which I think is somewhat dubious.  Accepting this point means that we
can sit here and add feature after feature.  Anyone comtemplating
supporting Common Lisp will have to be told "Not only do you have to
implement everything in this book, but there will probably be a steady
stream of new features that you are REQUIRED to implement, lest some
guaranteed-white-pages-compatible program not be able to run on your
system."  Is that really fair to the world?

A great deal of discussion on this mailing list has been related to
things that certainly do not fall within the domains of points 1, 2, 4,
and 5.  I think our time would be far better spent on those points than
on designing a new version of Common Lisp.  I agree with Fateman's
general point about CL '84 and CL '86, and I think we should spend our
time where it is most urgently needed: on CL '84.

∂24-May-85  0955	GRISS%hp-hulk.csnet@csnet-relay.arpa 	Addendum/Erratum 
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 24 May 85  09:55:12 PDT
Received: from hplabs by csnet-relay.csnet id ab11256; 24 May 85 12:32 EDT
Received: by HP-VENUS id AA18809; Fri, 24 May 85 05:50:52 pdt
Message-Id: <8505241250.AA18809@HP-VENUS>
Date: Fri 24 May 85 05:50:26-PDT
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Addendum/Erratum
To: common-lisp@su-ai.ARPA
Cc: GRISS@hplabs.CSNET
Source-Info:  From (or Sender) name not authenticated.

Are there plans to publish an Erratum or Addendum sheet to go with the
current CL ref manual. Is someone gathering and editing the
various comments and elucidations submitted since the book appeared.

M
-------

∂24-May-85  1030	gls%AQUINAS@THINK.ARPA 	Rules of the game and stability
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 24 May 85  10:29:57 PDT
Received: by THINK.ARPA with CHAOS id AA15759; Fri, 24 May 85 13:19:06 edt
Date: Friday, 24 May 1985, 13:19-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Rules of the game and stability
To: common-lisp%sail@THINK.ARPA
Cc: gls%AQUINAS@THINK.ARPA
Message-Id: <850524131942.2.GLS@ELIGIUS.ARPA>

I agree with Fateman that Common Lisp should not be regarded as frozen
forever and that there can be staged versions of it as for FORTRAN.  I
do think that two years is too short a cycle, however; given LISP's
history of instability, large changes to Common Lisp over only two
years will simply look like more of the same chaos.  Hedrick's point
is also well taken that by 1986 a lot of people will barely have
finished implementing CL'84.

On the other hand, FORTRAN's revisions run on an 11-year cycle, which
I think is much too long.  If I had to make a projection today (and I
will; here it comes, ta da), I would say that the time for a major
"version change" to Common Lisp will be ripe about 1988 or 1989, and
there is room for a "corrected edition" of CL'84 in about 1986 (I
think it will take about another year to discuss the outstanding and
new issues raised since the book was published a year ago, decide what
to do, change the book, and get the new edition published).

I agree with DLW that my category (3) should be regarded with caution,
if not suspicion; my examples were not well chosen.  I am not
recommending the introduction of flavors in the near future, for
example.  I was ordering the categories according to user disruption,
not implementation disruption, and of course both are important.
A small number of things like &body won't hurt, but we don't want
to introduce a hundred new functions.

Someone referred to my previous note with the word "policy".  I would
like to say that I am not attempting to establish policy unilaterally.
I am trying to summarize my sense of what everyone seems to want,
colored of course by my opinions as to what I think would be best for
everyone concerned.  (It might be useful for everyone to understand
that right now I am more a user of Common Lisp than an implementor!
On the other hand, part of my work here at Thinking Machines is
concerned with implementing a sideset of Common Lisp for parallel
processing.)

--Guy

∂24-May-85  1300	gls%AQUINAS@THINK.ARPA 	Addendum/Erratum
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 24 May 85  13:00:30 PDT
Received: by THINK.ARPA with CHAOS id AA17473; Fri, 24 May 85 15:55:21 edt
Date: Friday, 24 May 1985, 15:55-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Addendum/Erratum
To: common-lisp%su-ai@THINK.ARPA
Cc: GRISS%hplabs.CSNET@THINK.ARPA, gls%AQUINAS@THINK.ARPA
In-Reply-To: <8505241250.AA18809@HP-VENUS>
Message-Id: <850524155541.1.GLS@DESIDERIUS.ARPA>

I have been collecting changes that I believe to be non-controversial
into one place.  I also keep track of all Common Lisp mail.  Now that
discussions have been revving up again on this mailing list, I would
like later this summer to gather up the discussions, make up another
ballot, and conduct a poll on proposed changes.  The results of this
poll must, I suppose, be considered provisional until we come up with an
organizational charter.

Appended to this message is my list of non-controversial changes.
----------------------------------------------------------------

Corrections to first printing of  Common Lisp: The Language

10  First two paragraphs should have monospace comma and colon,
respectively, at the left margin.

18  3.1010299957f-1 should be 3.010299957f-1 (first "1" should be deleted).

43  Table 43-1 should include the names "signed-byte" and "unsigned-byte".

67  The comment in (defun discriminant ...) is wrong, because the code
works for complex coefficients.  Change the line
	The quadratic equation a*x↑2+b*x+c=0 has real, multiple
to be the two lines
	If the coefficients a, b, and c are all real numbers, then
	the quadratic equation a*x↑2+b*x+c=0 has real, multiple

69  Top line, last word but one, should be "replace", not "replaces".

99  In first line of second paragraph, delete the italicized word "newvalue".

145  Three lines from the bottom, the term "&environment" should
appear at the left in monospace.

147  Last line on this page should be deleted; it duplicates first line
on page 148.

157  In third line, "declaration-form" should be "decl-spec" (in italics).

200  At the end of the first paragraph "returns the result." add the sentence
"It is an error if any argument other than the first is zero."
After "With one argument, / reciprocates the result" add the sentence
"The argument must not be zero."

204  Halfway down, the last line of a paragraph "#C(0.5 1.73205)."
should say "#C(1.0 1.73205)."

216  Alter "The divisor may be any non-complex number." to read
"The divisor may be any non-zero non-complex number."

216  Change "For example, (floor 5 2) @EQ (floor (/ 5 2)) ..." to
"For example, (values (floor 5 2)) @EQ (values (floor (/ 5 2))) ...".

216 Before last paragraph, insert this new paragraph:
Note that while (floor 5 2) and (floor (/ 5 2)) return the same first
value, they return different remainders as the second value:
	(floor 5 2) => 2 1
	(floor (/ 5 2)) => 2 1/2
This is why @f[values] was used above in the remark that
(values (floor 5 2)) @EQ (values (floor (/ 5 2))).

276  Halfway down, in the display line before "See pushnew.", the phrase
"(fn item)" should be "(funcall fn item)", with "funcall" in monospace
and "fn" and "item" in italics as before.

307  In the header line for "defstruct", "{slot-description}+" should
be "{slot-description}*" (star instead of plus).

309  First paragraph should end "see section 19.6)." not "see section 19.6.";
there is a missing parenthesis.

325  The name of the variable "-" does not appear in the header line.

347-348  The page layout is a bit confused here; some connection should
be made between the description of ";" and the example.

349  Before the first complete paragraph, there should be a heading
line consisting of a single monospace backquote (accent grave).

349  In the first example of the use of backquote, the character
just before " (print ,x)" is a "t".  (It is badly printed in several
copies.)

373 Third line from bottom: "print-array" in monospace should
be "*print-array*".

454 In index entry for "defun", first page number should be 67, not 57.

458  In index entry for "macrolet", page numbers should be 113-114 instead
of 93-94.

465  "zerop" is missing from the index (it is defined on page 195).

458  First reference for "macrolet" should be 113-114, not 93-94.

459  Add index entry "newline 20, 21-22, 235, 243, 336, 347, 378, 383, 384,
397".

∂27-May-85  1105	RAM@CMU-CS-C.ARPA 	Does Defmacro establish a block?    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 May 85  01:30:09 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Mon 27 May 85 04:30:09-EDT
Date: Mon, 27 May 1985  04:30 EDT
Message-ID: <RAM.12114291388.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   common-lisp@SU-AI.ARPA
Subject: Does Defmacro establish a block?
Comment: Remailed after delay caused by distribution list error at SU-AI.


    Does defmacro establish a named block around the definition the
same way that defun does?  CLTL doesn't mention this issue at all,
leading one to suppose that it doesn't, but this seems to create a
pointless inconsistency with defun.

    If defmacro does, do define-setf-method, defsetf, deftype...?

  Rob

∂27-May-85  1225	DLW@SCRC-STONY-BROOK.ARPA 	Does Defmacro establish a block? 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 27 May 85  12:25:41 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 244204; Mon 27-May-85 15:24:36-EDT
Date: Mon, 27 May 85 15:26 EDT
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Does Defmacro establish a block?
To: RAM@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12114291388.BABYL@CMU-CS-C.ARPA>
Message-ID: <850527152627.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Reply-To: dlw@SCRC-STONY-BROOK.ARPA

    Date: Mon, 27 May 1985  04:30 EDT
    From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>

    Does defmacro establish a named block around the definition the
    same way that defun does?

I know you're asking about the definition of CL, and I don't have
anything to add about that, but I thought you might be interested to
know that it does in our implementation.

∂28-May-85  0742	greek@DEC-HUDSON 	Rules of the Game
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 28 May 85  07:41:41 PDT
Date: Tue, 28 May 85 10:41:47 EDT
From: greek@DEC-HUDSON
Subject: Rules of the Game
To: common-lisp@su-ai

I'm glad we are taking time to establish a "policy" about making
changes to CL'84.  Regarding Guy's categories 3 and 4, I think we
should only introduce new features when they are necessary to repair
a (more or less) flawed feature in the language.  For example, 
PARSE-BODY is needed by every correct implementation, so indeed
we might as well specify it.  Incompatible changes should only
be made when absolutely necessary to fix a broken feature.

New features and incompatible changes which do not fall into  the
above category should be left for CL'8n.  As Guy said, we ought to
give everyone a half a chance to finish implementing CL'84 before
we throw a pile of new good stuff at them.  Remember, CLs that are
real products can't be changed continuously, because real products
change in cycles (often as long as a year or two).


- Paul

∂28-May-85  0822	greek@DEC-HUDSON 	Adjusting displaced arrays.
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 28 May 85  08:21:49 PDT
Date: Tue, 28 May 85 11:21:20 EDT
From: greek@DEC-HUDSON
Subject: Adjusting displaced arrays.
To: common-lisp@su-ai

Erf!  I certainly should have objected to the incredible hair needed
to implement adjustable arrays, particularly those which are displaced,
back when we specified them.  However, I'd like to object now.

I'd like to see a list of the uses people make of displaced and
adjustable arrays.  Maybe there are only two or three real features
that people use, and we could restrict ourselves to those.  I looked
around here at DEC, and found exactly two uses:

1.  Make an array bigger.  Obviously this could be done with MAKE-ARRAY
    and REPLACE.

2.  Linearize a multidimensional array so that row-major references
    can be done.  This is useful, but an AREF-ROW-MAJOR function could
    probably do it more efficiently.

It seems to me that any set of rules that require AREF to iterate to
find the data ought to be simplified.  So much for inline code.

- Paul

∂28-May-85  0946	DCP@SCRC-STONY-BROOK.ARPA 	Adjusting displaced arrays. 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 May 85  09:46:29 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 244606; Tue 28-May-85 12:46:07-EDT
Date: Tue, 28 May 85 12:48 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: Adjusting displaced arrays.
To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 28 May 85 11:21-EDT from greek@DEC-HUDSON
Message-ID: <850528124820.3.NFEP@NEPONSET.SCRC.Symbolics.COM>

    Date: Tue, 28 May 85 11:21:20 EDT
    From: greek@DEC-HUDSON

    Erf!  I certainly should have objected to the incredible hair needed
    to implement adjustable arrays, particularly those which are displaced,
    back when we specified them.  However, I'd like to object now.

    I'd like to see a list of the uses people make of displaced and
    adjustable arrays.  Maybe there are only two or three real features
    that people use, and we could restrict ourselves to those.  I looked
    around here at DEC, and found exactly two uses:

    1.  Make an array bigger.  Obviously this could be done with MAKE-ARRAY
	and REPLACE.

    2.  Linearize a multidimensional array so that row-major references
	can be done.  This is useful, but an AREF-ROW-MAJOR function could
	probably do it more efficiently.

LispMs (which include Symbolics, and I believe LMI and TI for this
discussion) use displaced arrays for at least the following:
	NSUBSTRING (which is SUBSTRING, but shares storage)
	bitmaps (both for creating subwindows of windows, and for
		 redirecting an array (a) to a physical screen or (b) to
		 a bit save array.)
	de/en-capsulating network packets (e.g., the data of a packet is a
		string that shares storage with the packet; the string
		starts after the protocol header.)
I don't think we don't use it for your case (1); instead we do make a
new array, copy, and structure forwared the old to the new.  They can
also be used for your case (2), but I think the our function
SYS:%1D-AREF subsumes the need.

    It seems to me that any set of rules that require AREF to iterate to
    find the data ought to be simplified.  So much for inline code.

∂28-May-85  1439	masinter.pa@Xerox.ARPA 	programs writing backquote
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 28 May 85  14:38:51 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 28 MAY 85 14:38:55 PDT
Date: 28 May 85 14:38 PDT
From: masinter.pa@Xerox.ARPA
Subject: programs writing backquote
To: common-lisp@su-ai.ARPA
Message-ID: <[]<>MG>Q>Item-850528-143855-1480@Xerox>


In part of the discussion over nesting depth of backquote, more than one
person alluded to the possibility that a *program* could write a 3-deep
nested backquote and that this was generally a good thing.

However, as far as I can tell, it would be easier for a Snobol program
to write nested backquotes rather than Lisp, because there is no defined
S-expression representation of backquotes... the only thing GSSB ( Guy
Steele's Silver Book) defines is the surface syntax.

Do I misunderstand? Can someone give a program which creates a Common
Lisp 3-deep-nested backquote, without resorting to string manipulations?



∂28-May-85  1450	masinter.pa@Xerox.ARPA 	Re: Rules of the game and stability 
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 28 May 85  14:50:31 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 28 MAY 85 14:46:36 PDT
Date: 28 May 85 14:46 PDT
From: masinter.pa@Xerox.ARPA
Subject: Re: Rules of the game and stability
To: common-lisp@SU-AI.ARPA
cc: common-lisp-charter@su-ai.ARPA
Message-ID: <[]<>MG>Q>Item-850528-144636-1487@Xerox>

Isn't this what the "charter" committee is supposed to be deciding? I've
not seen much action on CLCHRT.MSG -- is there more happening
behind-the-scenes?




∂28-May-85  1515	KMP@SCRC-STONY-BROOK.ARPA 	programs writing backquote  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 May 85  15:15:03 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 244953; Tue 28-May-85 18:14:34-EDT
Date: Tue, 28 May 85 18:14 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: programs writing backquote
To: masinter.pa@XEROX.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <[]<>MG>Q>Item-850528-143855-1480@Xerox>
Message-ID: <850528181434.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: 28 May 85 14:38 PDT
    From: masinter.pa@Xerox.ARPA

    In part of the discussion over nesting depth of backquote, more than one
    person alluded to the possibility that a *program* could write a 3-deep
    nested backquote and that this was generally a good thing.

    However, as far as I can tell, it would be easier for a Snobol program
    to write nested backquotes rather than Lisp, because there is no defined
    S-expression representation of backquotes... the only thing GSSB ( Guy
    Steele's Silver Book) defines is the surface syntax.

    Do I misunderstand? Can someone give a program which creates a Common
    Lisp 3-deep-nested backquote, without resorting to string manipulations?

The program that manipulates the common lisp does not itself have to be
written in common lisp. (eg, we've already conceded you can't write a real time 
editor in common lisp, but that doesn't free us from the constraint that
common lisp code must be editable...)

In fact, the programs that I have which manipulate common backquote structure
are written in Zetalisp and they make assumptions about the internal representation
of backquoted structure.

However, all that aside, it is completely trivial to write a common lisp program
which has its own readtable and its own representation for backquoted structure
and whose sole job in life is to read in expressions, frob their backquoted 
structure using its private representation, and write them back out.

... not to mention manipulating the expression at the text level -- such as
using just c-m-K and c-Y in Emacs to move a doubly nested backquote expression 
inside a macro which already has a level of backquote ... something I do all
the time without the aid of any tools fancier than Emacs...

∂28-May-85  1532	MASINTER@SUMEX-AIM.ARPA 	(duplicate) programs writing backquote  
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 28 May 85  15:32:24 PDT
Date: Tue 28 May 85 15:32:25-PDT
From: Larry Masinter  <MASINTER@SUMEX-AIM.ARPA>
Subject: (duplicate) programs writing backquote
To: common-lisp@SU-AI.ARPA

I've gotten back about twenty "Unable to deliver" messages because of a new
"message-id" that our local mail-handler started adding. I'm
repeating the message here -- sorry if it is a duplicate.

Date: 28 May 85 14:38 PDT
From: masinter.pa@Xerox.ARPA
Subject: programs writing backquote
To: common-lisp@su-ai.ARPA
Message-ID: <[]<>MG>Q>Item-850528-143855-1480@Xerox>

In part of the discussion over nesting depth of backquote, more than one
person alluded to the possibility that a *program* could write a 3-deep
nested backquote and that this was generally a good thing.

However, as far as I can tell, it would be easier for a Snobol program
to write nested backquotes rather than Lisp, because there is no defined
S-expression representation of backquotes... the only thing GSSB ( Guy
Steele's Silver Book) defines is the surface syntax.

Do I misunderstand? Can someone give a program which creates a Common
Lisp 3-deep-nested backquote, without resorting to string manipulations?

-------

∂29-May-85  0005	REM@IMSSS 
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-May-29 23:02:12 PST (=GMT-8hr)
Date: 1985 May 28 22:56:08 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132206061364.G0353
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To:masinter.pa@Xerox.ARPA
CC:COMMON-LISP@SU-AI.ARPA
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up)

> Date: 28 May 85 14:38 PDT
> From: masinter.pa@Xerox.ARPA
> Subject: programs writing backquote
> 
> In part of the discussion over nesting depth of backquote, more than one
> person alluded to the possibility that a *program* could write a 3-deep
> nested backquote and that this was generally a good thing.
> 
> However, as far as I can tell, ... because there is no defined
> S-expression representation of backquotes... the only thing GSSB ( Guy
> Steele's Silver Book) defines is the surface syntax.

This is curious because in PSL the ` read-macro seems to generate a
true LISP macro (i.e. an s-expression representation of the ` syntax)
which then actually implements the semantics of the ` character when
interpreted or compiled. Perhaps CL should specify something like this
explicitly?  Below are examples of original PSL source and the result
of READing into memory following by PRIN1ing it back out (then
manually prettyprinting in EMACS). It seems to me quite reasonable
that a PRINter function that is smarter than PRIN1 might re-introduce
the backquote optimizations (or in complex cases find better
optimizations than given by original programmer).


(defmacro cl-alias (sl-name cl-name)
  `(defmacro ,cl-name form
     `(,',sl-name . ,form)))

(DEFMACRO CL-ALIAS (SL-NAME CL-NAME)
  (BACKQUOTE
    (DEFMACRO (UNQUOTE CL-NAME) FORM
      (BACKQUOTE ((UNQUOTE (QUOTE (UNQUOTE SL-NAME)))
		  UNQUOTE FORM)))))

(defmacro errset (form flag)
  `(errorset `,',form ,flag ,flag))

(DEFMACRO ERRSET (FORM FLAG)
  (BACKQUOTE
    (ERRORSET
      (BACKQUOTE (UNQUOTE (QUOTE (UNQUOTE FORM))))
      (UNQUOTE FLAG)
      (UNQUOTE FLAG))))

∂29-May-85  0709	greek@DEC-HUDSON 	Internal representation of backquotes
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 29 May 85  07:08:44 PDT
Date: Wed, 29 May 85 10:08:47 EDT
From: greek@DEC-HUDSON
Subject: Internal representation of backquotes
To: common-lisp@su-ai

We would have to be very careful if we wanted to specify how backquotes
et al are represented when read in.  In PSL, you have an explicit
form for backquote et al, but in VAX LISP the reader converts the
backquotes into the actual LISP code needed to build the backquoted
lists.  So we lose all knowledge that a backquote was ever involved
(unless, of course, you turn on the magic variable that causes
us to remember).

I think we need to allow maximum flexibility in generating efficient
code for backquotes.

- Paul

∂29-May-85  1246	greek@DEC-HUDSON 	Internal representation of backquotes
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 29 May 85  07:08:44 PDT
Date: Wed, 29 May 85 10:08:47 EDT
From: greek@DEC-HUDSON
Subject: Internal representation of backquotes
To: common-lisp@su-ai

We would have to be very careful if we wanted to specify how backquotes
et al are represented when read in.  In PSL, you have an explicit
form for backquote et al, but in VAX LISP the reader converts the
backquotes into the actual LISP code needed to build the backquoted
lists.  So we lose all knowledge that a backquote was ever involved
(unless, of course, you turn on the magic variable that causes
us to remember).

I think we need to allow maximum flexibility in generating efficient
code for backquotes.

- Paul

∂29-May-85  1257	DCP@SCRC-STONY-BROOK.ARPA 	programs writing backquote  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 29 May 85  12:57:19 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 245299; Wed 29-May-85 10:56:43-EDT
Date: Wed, 29 May 85 10:59 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: programs writing backquote
To: masinter.pa@XEROX.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <[]<>MG>Q>Item-850528-143855-1480@Xerox>
Message-ID: <850529105911.3.NFEP@NEPONSET.SCRC.Symbolics.COM>

    Date: 28 May 85 14:38 PDT
    From: masinter.pa@Xerox.ARPA


    In part of the discussion over nesting depth of backquote, more than one
    person alluded to the possibility that a *program* could write a 3-deep
    nested backquote and that this was generally a good thing.

    However, as far as I can tell, it would be easier for a Snobol program
    to write nested backquotes rather than Lisp, because there is no defined
    S-expression representation of backquotes... the only thing GSSB ( Guy
    Steele's Silver Book) defines is the surface syntax.

    Do I misunderstand? Can someone give a program which creates a Common
    Lisp 3-deep-nested backquote, without resorting to string manipulations?

This doesn't resort to string manipulation, and it produces structure
that is more than 3 deep.  It is quite contrived, but it does satisfy
your requirements.  Just trying to produce this example gave me the
opinion it is hard to write meaningful programs [that write meaningful
programs...] that produce highly nested backquoted structure.

(defun print-using-backquote (exp)
  (pprint (sublis '((list . si:xr-bq-list)
		    (cons . si:xr-bq-cons)
		    (list* . si:xr-bq-list*)
		    (append . si:xr-bq-append))
		  exp)))

(print-using-backquote
  ;; exp starts out being a constructor of an alist.  The data of the
  ;; alist is another alist 
  (do ((exp '(list (list 'a (cons 'ab ab) (cons 'ac ac))
		   (list 'b (cons 'bb bb) (cons 'bc bc))
		   (list 'c (cons 'cb cb) (cons 'cc cc)))
	    (subst exp 'bc exp))
       (count 2 (1- count)))
      ((zerop count) (print-using-backquote exp))))

`((A (AB .,AB) (AC .,AC))
  (B (BB .,BB)
   (`((A (AB .,AB) (AC .,AC))
      (B (BB .,BB)
       (`((A (AB .,AB) (AC .,AC))
          (B (BB .,BB)
           (`((A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC)))
            (A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC))))
          (C (CB .,CB) (CC .,CC)))
        (A (AB .,AB) (AC .,AC))
        (B (BB .,BB)
         (`((A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC)))
          (A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC))))
        (C (CB .,CB) (CC .,CC))))
      (C (CB .,CB) (CC .,CC)))
    (A (AB .,AB) (AC .,AC))
    (B (BB .,BB)
     (`((A (AB .,AB) (AC .,AC))
        (B (BB .,BB)
         (`((A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC)))
          (A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC))))
        (C (CB .,CB) (CC .,CC)))
      (A (AB .,AB) (AC .,AC))
      (B (BB .,BB)
       (`((A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC)))
        (A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC))))
      (C (CB .,CB) (CC .,CC))))
    (C (CB .,CB) (CC .,CC))))
  (C (CB .,CB) (CC .,CC)))

∂29-May-85  1257	DLW@SCRC-STONY-BROOK.ARPA 	Re: Rules of the game and stability   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 29 May 85  12:57:29 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 245277; Wed 29-May-85 10:46:45-EDT
Date: Wed, 29 May 85 10:47 EDT
From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
Subject: Re: Rules of the game and stability
To: masinter.pa@XEROX.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <[]<>MG>Q>Item-850528-144636-1487@Xerox>
Message-ID: <850529104747.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI
Reply-To: dlw@SCRC-STONY-BROOK.ARPA

    Date: 28 May 85 14:46 PDT
    From: masinter.pa@Xerox.ARPA

    Isn't this what the "charter" committee is supposed to be deciding?

Yes, that's what I thought too.

∂29-May-85  1445	gls@AQUINAS.ARPA 	Re: Rules of the game and stability  
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 29 May 85  14:45:49 PDT
Received: by THINK.ARPA with CHAOS id AA17733; Wed, 29 May 85 17:23:35 edt
Date: Wed, 29 May 85 17:24 EDT
From: Guy Steele <gls@AQUINAS.ARPA>
Subject: Re: Rules of the game and stability
To: common-lisp@SU-AI.ARPA
Cc: gls@AQUINAS.ARPA
In-Reply-To: <850529104747.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <850529172430.3.GLS@DESIDERIUS.ARPA>
Fonts: CPTFONT, CPTFONTB, CPTFONTI

    Date: Wed, 29 May 85 10:47 EDT
    From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM@think>

	Date: 28 May 85 14:46 PDT
	From: masinter.pa@Xerox.ARPA

	Isn't this what the "charter" committee is supposed to be deciding?

    Yes, that's what I thought too.

That's what I thought, too.  When I started this whole discussion
I clearly labeled my list of "rules" as merely my opinion of what
we ought to do.  The charter committee may consider that list as
input to their discussions.  The charter committee must also bear
in mind that to make no decision is also a decision.

People clearly want a revised edition (or revised printing) of the
manual, or at least an errata sheet.  I will do the editing work on
this, but the charter should provide guidance how to go about it.  If
this doesn't happen in the next four months or so, I, radical fanatic
that I am, may just go ahead and conduct a poll as we have done before
and go from there, simply to get something done.  However, I would
rather have an agreed-upon structure in place to work within before
this time comes.

--Guy

∂31-May-85  0926	DCP@SCRC-STONY-BROOK.ARPA 	CLtL Index   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 31 May 85  09:26:01 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 246905; Fri 31-May-85 12:25:18-EDT
Date: Fri, 31 May 85 12:28 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: CLtL Index
To: common-lisp@SU-AI.ARPA
Message-ID: <850531122824.9.NFEP@NEPONSET.SCRC.Symbolics.COM>

CLtL's index doesn't have &anything either at the beginning or the end
(with the other non-alphabetics).  I therefore can't look up &KEY, etc,
since they aren't listed under their non-& names.

∂31-May-85  1440	hplabs!perdue%hplabs.csnet@csnet-relay.arpa 	Re: Programs writing backquote
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 31 May 85  14:40:04 PDT
Received: from hplabs by csnet-relay.csnet id ag02308; 31 May 85 17:35 EDT
Received: by HP-VENUS id AA09296; Fri, 31 May 85 13:00:59 pdt
Message-Id: <8505312000.AA09296@HP-VENUS>
Date: 31-May-85 12:58:47
To: common-lisp@su-ai.ARPA
Subject: Re: Programs writing backquote
From: perdue%hplabs.csnet@csnet-relay.arpa
Source-Info:  From (or Sender) name not authenticated.

I'd like to second the proposal that Common LISP backquote "`" be
explicitly defined as expanding into a macro, and that ",", ",@", and
",." expand similarly into s-expression forms.  This makes backquote
more accessible to programs.  The point has been made that if "`"
expands into a LISP macro invokation, a conventional interpreter will
run the code relatively slowly.  This kind of objection of course
applies to use of macros in general, and I don't think we usually let
it stop us from defining macros where they are useful.
-------

∂02-Jun-85  0802	FAHLMAN@CMU-CS-C.ARPA 	Programs writing backquote 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Jun 85  08:02:33 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 2 Jun 85 11:02:19-EDT
Date: Sun, 2 Jun 1985  11:02 EDT
Message-ID: <FAHLMAN.12115935645.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   perdue%hplabs.csnet@CSNET-RELAY.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: Programs writing backquote
In-reply-to: Msg of 31 May 1985  12:58-EDT from perdue%hplabs.csnet at csnet-relay.arpa


    I'd like to second the proposal that Common LISP backquote "`" be
    explicitly defined as expanding into a macro, and that ",", ",@", and
    ",." expand similarly into s-expression forms.  This makes backquote
    more accessible to programs.  The point has been made that if "`"
    expands into a LISP macro invokation, a conventional interpreter will
    run the code relatively slowly.  This kind of objection of course
    applies to use of macros in general, and I don't think we usually let
    it stop us from defining macros where they are useful.

If we really want to do this, it should be sufficient to define
S-expression forms that the various backquote character macros COULD
expand into, and that programs can generate to get the same effect.  We
don't have to require implementors to actually use these in processing
backquoted expressions.

Since all of these generated forms have equivalents that use only
pre-defined things like QUOTE, CONS, APPEND, and NCONC, I don't really
see much point in adding a bunch of new things that correspond directly
to the backquote forms.  Programs can just say what they really mean,
without having to try to think in terms of these cute surface-level
forms that happen to be convenient for humans.

-- Scott

∂02-Jun-85  1058	FAHLMAN@CMU-CS-C.ARPA 	Rules of the game and stability 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Jun 85  10:58:18 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 2 Jun 85 13:58:26-EDT
Date: Sun, 2 Jun 1985  13:58 EDT
Message-ID: <FAHLMAN.12115967697.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Guy Steele <gls%aquinas@THINK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Rules of the game and stability
In-reply-to: Msg of 29 May 1985  17:24-EDT from Guy Steele <gls at AQUINAS.ARPA>


The charter committee has indeed been too inactive of late, and even
when we were active we were concentrating more on organizational issues
than on the proper philosophy for stability versus fixing things.  I'll
try to fire this discussion up again, once I get finished with some
immediate demands on my time.  I sort of put things on hold until we all
could get some idea of what services the DARPA/ISI contract was going to
provide, and when.

I agree with Guy's list of the kinds of changes that might be
considered, in increasing order of disruptiveness.  I would only add
that there is a lot of variation in each of these categories: an
incompatible change in the cut points of obscure trig functions is not
going to disrupt things as much as, say, an incompatible change in the
handling of special variables.  Additions to the language are not a
burden if accompanied by portable code that implements the addition.
Other additions might not be implementable in a portable way, but would
obviously require only very minor and local changes to implement.

I also agree that Common Lisp 84 should be considered frozen in the way
that Guy proposes: only compatible or absolutely essential changes
should be made at this point.  There should be no fundamental additions
to Common Lisp 84 either, though there is no harm in putting together a
body of quasi-standard code that can be trivially added to any complete
and correct implementation, with the understanding that these features
go into the base language the next time around.  Library files could
begin assuming the existence of these additions right now.

But having said that, I should also say that the language as it stands
is still very young, relatively untried, and full of known flaws.  We
should therefore allow for a reasonably fast evolution at the start.  I
think that for the next few years, it would be optimal to an updated
specification appear every year, or at most every two years.  I
certainly don't want to wait until 1989 or whenever in order to fix the
small but important problems that we've already identified.

I'm not talking about a major upheaval every year -- I'm sure that we
will carefully weigh the benefit of each change against the cost both to
users and implementors -- but once we've decided that a change is worth
making, we should not have to wait too long for the next release cycle
to come around.  At any time, there will be one well-defined version of
Common Lisp that corresponds to the latest official release, and another
that includes the changes that have been approved for the next future
release.  Nobody would be required to track the latter until the release
date rolls around, but some of us (in universities, maybe) should
install any such changes right away in order to verify that they do
their job as intended.

In any event, I think we should be aiming for another release as early
as possible in 1986, and the incompatible changes we have been
discussing should be considered to be proposals for that next release.

-- Scott

∂02-Jun-85  1220	FAHLMAN@CMU-CS-C.ARPA 	Get-Setf-Method  
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Jun 85  12:20:36 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 2 Jun 85 15:20:44-EDT
Date: Sun, 2 Jun 1985  15:20 EDT
Message-ID: <FAHLMAN.12115982668.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Get-Setf-Method
In-reply-to: Msg of 23 May 1985  08:03-EDT from Rob MacLachlan <RAM>


        Get-Setf-Method should take an (optional?) environment argument so
    that it can expand macros correctly. 

Steve Handerson has pointed out that MACRO-FUNCTION also needs an
optional evironment argument, since without this we have no way of
getting hold of the expansion function for a lexically defined macro
(though we can execute this function).  This may or may not be important
for normal code, but it is definitely important for writing environment
tools such as a single-stepper.

-- Scott

∂03-Jun-85  0520	JLW  	Explicit definition of backquote  
To:   Fahlman@CMU-CS-C.ARPA
CC:   Perdue%hplabs@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA    

In-reply-to: your message of  2-Jun-85  11:02 EDT

MacLisp may have been the first implementation to use macro wrappers for the
target of the various "backquote" readmacros; it was motivated by the desire
to use the programable "prettyprinter", which had a very simple readmacroinverse
facility.  The goal was to have read/print do for backquote what it was doing
for singlequote.  Later, the Lispm (which had backquote first) switched from a 
direct expansion into basic primitives (like, QUOTE, CONS, APPEND etc)
to the use of internal, semi-unpronouncable names which were copies of
these primitives, primarily to retain a modicum of the structure of the
original text (I don't think it succeeds in all cases, as does the pdp10
MacLisp and NIL code.  By the way, MacLisp's wrapper names are also
quite unpronounceable -- but then, MacLisp has no package system.)

In defense of using eval-time macros, rather than going directly to
"efficient" primitive code, one may notice that CL requires a macro
expansion hook (CLtL, page 152), with which one may smoothly implement
the equivalent of the MacLisp MACROMEMO macro cacheing scheme [this
is somewhat equivalent to Interlisp's cacheing of expansions in the
hashtable CLISPARRAY].  With a very modest amount of time spent on
tuning the evaluator, there should be no hesitation to use macros freely 
in CL; in fact, with a compile-time-only "optimizer", it's quite feasible
to retain full input syntax, while compiling something quite different,
something which has been "optimized" to the hilt.

Even a vanilla implementation, wrappers or not, for the next manual would
be of immense help, and could fullfill your suggestion:
    If we really want to do this, it should be sufficient to define
    S-expression forms that the various backquote character macros COULD
    expand into, and that programs can generate to get the same effect.  We
    don't have to require implementors to actually use these in processing
    backquoted expressions.
Frankly, I think such a suggestive coding, in Lisp, would be more easily
understandable than the formal specification of CLtL pages 349-351.  

This may have more value than one would think at first.  A few years back,
someone in the Interlisp community decided to re-invent the backquote facility
in a more "Interlispy" fashion, and spent three years getting it wrong.  The 
test case was some doubly-nested (not triply-nested!!) code taken from Bob 
Kern's original implementation of DEFSETF for MacLisp/NIL.   About every six
months, this individual would proffer yet another version of the newly-invented
substitute for backquote, and I would have to grovel over the output on the
test case to see why it was wrong.  Sometimes the code produced was grossly 
erroneous (unbound gensyms as free variables!) but most often it would
CONS when it should have LIST'd, or CAR when it should have CDR'd; and
the only way to check it was to compare it with the normalized form
produced by pdp10 MacLisp.

We need the CL equivalent of that MacLisp version -- a standard by which
other, alleged backquote implementations may be measured.

-- JonL --

∂03-Jun-85  0624	greek@DEC-HUDSON 	Programs writing backquotes
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 3 Jun 85  06:24:15 PDT
Date: Mon, 03 Jun 85 09:24:25 EDT
From: greek@DEC-HUDSON
Subject: Programs writing backquotes
To: common-lisp@su-ai

I agree with Scott.  Backquote et al are shorthands for people.  Programs
can (really almost) just as easily generate the real code.

- Paul

∂03-Jun-85  0710	KMP@SCRC-STONY-BROOK.ARPA 	Programs writing backquotes 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 3 Jun 85  07:10:24 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 247754; Mon 3-Jun-85 10:09:12-EDT
Date: Mon, 3 Jun 85 10:09 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Programs writing backquotes
To: greek@DEC-HUDSON
cc: Common-Lisp@SAIL
Message-ID: <850603100932.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Don't be silly. Programs that write programs to run maybe can generate 
`real' code, but programs that write programs to read better use a 
readable convention. It is not just writing convenience that leads one
to write with backquote. 

Further, the issue of program-manipulation of backquote is not only one
of generation, but of intelligibility of code written by users. It should
be possible to have called vanilla READ and to get backquoted structure
and to be able to identify it as such. The grinder is an obvious example
of a program which needs to be able to recognize such things, but it would
be easy to conjure others.

∂03-Jun-85  0945	vanroggen@DEC-HUDSON 	read macros  
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 3 Jun 85  09:45:12 PDT
Date: Mon, 03 Jun 85 12:45:17 EDT
From: vanroggen@DEC-HUDSON
Subject: read macros
To: common-lisp@su-ai
Cc: vanroggen

I agree invertibility of backquote is desired. But users can define their
own read macros. Why don't we supply a mechanism to allow users to define
inverses of read macros, and have system supplied ones also use this
mechanism, and have the pretty-printer print the inverse?
Which reminds me--there hasn't been any discussion of Waters's modification
of FORMAT and streams to do pretty printing on this mailing list. It seems
there was some accord back in September that his proposal was reasonable.
This would be a good example of a non-portable, compatible extension to
Common Lisp; we should try to agree on this now so that its future inclusion
will be easy.
			---Walter

∂03-Jun-85  1925	GSB@MIT-MC.ARPA 	Get-Setf-Method   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Jun 85  19:25:34 PDT
Date: Mon,  3 Jun 85 22:21:23 EST
From: Glenn S. Burke <GSB@MIT-MC.ARPA>
Subject: Get-Setf-Method
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].529174.850603.GSB>

    Date: Sun, 2 Jun 1985  15:20 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

    Steve Handerson has pointed out that MACRO-FUNCTION also needs an
    optional evironment argument, since without this we have no way of
    getting hold of the expansion function for a lexically defined macro
    (though we can execute this function).  This may or may not be important
    for normal code, but it is definitely important for writing environment
    tools such as a single-stepper.

    -- Scott

Yes. I don't remember why, but apparently it was important to something in
NIL. I don't think it was  just the stepper.  From the looks of the
sources we put this in last october or earlier.

∂05-Jun-85  1328	gls@THINK.ARPA 	common lisp- &environment objects 
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 5 Jun 85  13:28:18 PDT
Received: by THINK.ARPA with CHAOS id AA08313; Wed, 5 Jun 85 16:24:54 edt
Date: Wednesday, 5 June 1985, 16:25-EDT
From: Guy Steele <gls@THINK.ARPA>
Subject: common lisp- &environment objects
To: common-lisp%sail@THINK.ARPA
In-Reply-To: <850605151454.3.BRADLEY@ROCK.ARPA>
Message-Id: <850605162546.1.GLS@DESIDERIUS.ARPA>

    Received: from GODOT by AQUINAS via CHAOS with CHAOS-MAIL; Wed 5-Jun-85 15:18:54-EDT
    Received: by THINK.ARPA with CHAOS id AA07682; Wed, 5 Jun 85 15:13:58 edt
    Date: Wednesday, 5 June 1985, 15:14-EDT
    From: Bradley C. Kuszmaul <BRADLEY@AQUINAS>
    Subject: common lisp- &environment objects
    To: gls@AQUINAS, bradley@AQUINAS
    Message-Id: <850605151454.3.BRADLEY@ROCK.ARPA>

    I would like to be able to save &environment objects away somewhere, but
    the book is silent about whether I can do that.  Symbolics does not let
    me save them because they are on the stack.

     -Brad

The book is silent in the question of the extent of environments as delivered
to &environment bindings in DEFMACRO, hook functions, etc.  What shall we say?
--Guy

∂05-Jun-85  1904	FAHLMAN@CMU-CS-C.ARPA 	common lisp- &environment objects    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 Jun 85  19:04:33 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 5 Jun 85 22:06:18-EDT
Date: Wed, 5 Jun 1985  22:06 EDT
Message-ID: <FAHLMAN.12116842945.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Guy Steele <gls@THINK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: common lisp- &environment objects
In-reply-to: Msg of 5 Jun 1985 16:25-EDT from Guy Steele <gls at THINK.ARPA>


 The book is silent in the question of the extent of environments as delivered
 to &environment bindings in DEFMACRO, hook functions, etc.  What shall we say?

One false move here and we have not Lisp but Conniver.  How about
requiring "dynamic" extent for environment objects, and no more?  Will
that take care of the needs for macro-expansion, steppers, and so on?
True, you could imagine cute ways of using environments that outlive
their invocations, but I REALLY don't want to pay for those cute uses
with inefficiency or severe constraints on the implementor.  If anyone
wants to implement Conniver in Common Lisp, I can supply the old Maclisp
code, but let's not drag down Common Lisp itself.

-- Scott

∂05-Jun-85  1921	FAHLMAN@CMU-CS-C.ARPA 	common lisp- &environment objects    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 Jun 85  19:21:38 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 5 Jun 85 22:23:29-EDT
Date: Wed, 5 Jun 1985  22:23 EDT
Message-ID: <FAHLMAN.12116846074.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Guy Steele <gls@THINK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: common lisp- &environment objects


Actually, that was a slight overstatement.  You only get CONNIVER if you
actually allow the user to make use of the environment in certain ways,
such as GO-ing to the tags it contains.  There's not much harm in making
the environment object itself non-ephemeral, I suppose, as long as
people don't get the idea that you can do very much with these objects
once you exit the dynamic extent.  Still, I would opt for dynamic extent
unless someone comes up with a very clear need to go with something more
difficult.

-- Scott

∂06-Jun-85  0543	JLW  	Degenerate array axes   
To:   common-lisp@SU-AI.ARPA

What does one mean by (make-array '(0 5)) ?  How should it print?
(assuming that *print-array* is non-null)

The description of array printing on page 369 presumes that the array
is either single-dimensional, or else it has some (i.e., not 0) elements.
Notice how the looping part of the algorithm resets an index to 0 (not -1)
in order to try to access the "element" at index <i1 i2 ... 0 ...>.

I've looked a several CL implementations, and all fail to print such
objects in a readable manner.  Furthermore, they all print the above
array exactly the same as they do (make-array '(0 10)), even though the 
two arrays are not equalp [with *print-array* set to non-null].

It seems clear to me that the algorithm of page 369 does not
provide for a way to distinguish these two arrays, since the
#nA syntax deduces the contents of th dimensions list from
the :initial-contents -- but for arrays of array-total-size equal to
zero, they all have the same "initial contents" even though their
dimensions lists may assume infinitely may values.

Three possible solutions come to mind:
  1) simply rule out degenerate axes as being somehow wrong -- the
     only zero-element arrays must then be vectors
  2) coerce all such beasts into one with all dimensions zero -- e.g.,
     treat the '(0 5) and '(0 10) as if they were '(0 0); then a NIL
     for the :initial-contents would be acceptable.
  3) extend the print syntax of #nA so that it can specify the dimension
     list exactly, and independently of the :initial-contents field.
Anyone have any ideas on this one?

-- JonL --

∂06-Jun-85  0740	gls@THINK.ARPA 	Degenerate array axes   
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 6 Jun 85  07:39:56 PDT
Received: by THINK.ARPA with CHAOS id AA23798; Thu, 6 Jun 85 10:34:00 edt
Date: Thu, 6 Jun 85 10:34 EDT
From: Guy Steele <gls@THINK.ARPA>
Subject: Degenerate array axes   
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK.ARPA
In-Reply-To: Your message of 6 Jun 85 08:43-EDT
Message-Id: <850606103442.4.GLS@DESIDERIUS.ARPA>

    Date: 06 Jun 85  0543 PDT
    From: Jon White <JLW@SU-AI.ARPA@think>

    What does one mean by (make-array '(0 5)) ?  How should it print?
    (assuming that *print-array* is non-null)

    The description of array printing on page 369 presumes that the array
    is either single-dimensional, or else it has some (i.e., not 0) elements.
    Notice how the looping part of the algorithm resets an index to 0 (not -1)
    in order to try to access the "element" at index <i1 i2 ... 0 ...>.

Eeee-yuk!  This boner is completely my fault, and I feel very bad about it,
inasmuch as I put a lot of study into how APL hackers solved this problem.
(Essentially what they do is to exhibit a NON-empty array showing typical
components, and then say "the array I'm talking about is just like this
one except that thus-and-so axes are zero".  I'm not crazy about this solution,
since we don't have the same problem of prototypes [their technical term for
what you get when you take the "CAR" of an empty array] that APL does.)

    I've looked a several CL implementations, and all fail to print such
    objects in a readable manner.  Furthermore, they all print the above
    array exactly the same as they do (make-array '(0 10)), even though the 
    two arrays are not equalp [with *print-array* set to non-null].

    It seems clear to me that the algorithm of page 369 does not
    provide for a way to distinguish these two arrays, since the
    #nA syntax deduces the contents of th dimensions list from
    the :initial-contents -- but for arrays of array-total-size equal to
    zero, they all have the same "initial contents" even though their
    dimensions lists may assume infinitely may values.

    Three possible solutions come to mind:
      1) simply rule out degenerate axes as being somehow wrong -- the
	 only zero-element arrays must then be vectors
      2) coerce all such beasts into one with all dimensions zero -- e.g.,
	 treat the '(0 5) and '(0 10) as if they were '(0 0); then a NIL
	 for the :initial-contents would be acceptable.
      3) extend the print syntax of #nA so that it can specify the dimension
	 list exactly, and independently of the :initial-contents field.
    Anyone have any ideas on this one?

    -- JonL --

Under option (3), how about
	#A<dimension-list><initial-element>
?  This would provide a notation for empty arrays, as well as a concise
notation for arrays with all elements the same (EQL).  For empty arrays
the initial element doesn't especially matter, so use ().
So one would have
	(make-array '(0 5)) => #A(0 5)()
	(make-array '(0 10)) => #A(0 10)()

Of course, this is a non-trivial extension to the language.

--Guy

∂06-Jun-85  0809	FAHLMAN@CMU-CS-C.ARPA 	Degenerate array axes      
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 Jun 85  08:09:39 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 6 Jun 85 11:11:28-EDT
Date: Thu, 6 Jun 1985  11:11 EDT
Message-ID: <FAHLMAN.12116985877.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Guy Steele <gls@THINK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Degenerate array axes   
In-reply-to: Msg of 6 Jun 1985  10:34-EDT from Guy Steele <gls at THINK.ARPA>


Guy's suggested syntax extension seems to be the best way to go, IF we
really want to handle this problem properly.  I'm not sure that this
degenerate case is worth the hassle of a major syntax extension,
however.  The only reason we allowed a dimension to be 0 (in a vector)
was for APL compatibility -- the argument was that we may as well make
the boundary conditions such that someone could implement APL easily in
Common Lisp.  So I guess the question is whether keeping a (0 5) array
distinct from a (0 10) array during reading and printing is really
necessary for APL compatibility and, if so, whether we continue to care
about APL compatibility.  Maybe the right move is to require ALL
dimensions to be > 0 and not >= 0.

-- Scott

∂06-Jun-85  1001	FAHLMAN@CMU-CS-C.ARPA 	Degenerate array axes      
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 Jun 85  08:09:39 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 6 Jun 85 11:11:28-EDT
Date: Thu, 6 Jun 1985  11:11 EDT
Message-ID: <FAHLMAN.12116985877.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Guy Steele <gls@THINK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Degenerate array axes   
In-reply-to: Msg of 6 Jun 1985  10:34-EDT from Guy Steele <gls at THINK.ARPA>


Guy's suggested syntax extension seems to be the best way to go, IF we
really want to handle this problem properly.  I'm not sure that this
degenerate case is worth the hassle of a major syntax extension,
however.  The only reason we allowed a dimension to be 0 (in a vector)
was for APL compatibility -- the argument was that we may as well make
the boundary conditions such that someone could implement APL easily in
Common Lisp.  So I guess the question is whether keeping a (0 5) array
distinct from a (0 10) array during reading and printing is really
necessary for APL compatibility and, if so, whether we continue to care
about APL compatibility.  Maybe the right move is to require ALL
dimensions to be > 0 and not >= 0.

-- Scott

∂06-Jun-85  1021	MLY@MIT-MC.ARPA 	Degenerate array axes  -- really array printing.
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Jun 85  10:20:17 PDT
Date: Thu,  6 Jun 85 11:46:27 EST
From: Richard Mlynarik <MLY@MIT-MC.ARPA>
Subject:  Degenerate array axes  -- really array printing.
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].532788.850606.MLY>

    Date: Thu, 6 Jun 85 10:34 EDT
    From: Guy Steele <gls@THINK.ARPA>

    [...]

    Under option (3), how about
    	#A<dimension-list><initial-element>
    ?  This would provide a notation for empty arrays, as well as a concise
    notation for arrays with all elements the same (EQL).  For empty arrays
    the initial element doesn't especially matter, so use ().
    So one would have
    	(make-array '(0 5)) => #A(0 5)()
    	(make-array '(0 10)) => #A(0 10)()

    Of course, this is a non-trivial extension to the language.

It is also rather ugly, in that there seem to be no other predefined
reader macros which read TWO sexps as this does, and as such this may
be a little confusing.

I suppose the other way to do this is to print
`#.(make-array '(0 5) :initial-element 'foo)'

Speaking of which, it has always struck me as sort of a shame that
there is no convenient representation for arrays other than simple
bit-vectors, simple strings, and multidimensional arrays of
element-type `t'.

It would have been nice if there had been some facility for providing
`make-array' options by way of the `#a' macro construct (excluding
`:displaced-to' and `:displaced-index-offset') but as it is one must
print `#.(make-array ...)' in order to read in an `isomorphicp' array.

Any takers for
`#a((2 5) :element-type (mod 4) :fill-pointer 2 :initial-element 3)'?!!

∂06-Jun-85  1230	greek@DEC-HUDSON 	Arrays with zero dimensions.    
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 6 Jun 85  12:30:31 PDT
Date: Thu, 06 Jun 85 15:30:40 EDT
From: greek@DEC-HUDSON
Subject: Arrays with zero dimensions.
To: common-lisp@su-ai

Is it really of cosmic importance that we allow dimensions of zero?
We sure could invent a lot of baggage to handle it correctly, but...

- Paul

∂06-Jun-85  2212	wilensky%ucbdali@Berkeley 	Common LISP terminology
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 6 Jun 85  22:12:00 PDT
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.46)
	id AA23236; Thu, 6 Jun 85 17:59:55 pdt
Received: by ucbdali.ARPA (4.24/4.46)
	id AA19201; Thu, 6 Jun 85 18:02:59 pdt
Date: Thu, 6 Jun 85 18:02:59 pdt
From: wilensky%ucbdali@Berkeley (Robert Wilensky)
Message-Id: <8506070102.AA19201@ucbdali.ARPA>
To: common-lisp@su-ai.ARPA
Subject: Common LISP terminology


There appears to be considerable terminological confusion in Commmon LISP.
Here are two examples:

(1) The use of the terms ``binding'', ``bound'' and ``unbound''.  

On p. 55 we are told variable can be ``assigned to, as by `setq' or bound,
as by `let'. ''  However, a binding is defined as a particular parameter
instance (p. 36).  Moreover, a special variable (and only a special
variable)  can be ``unbound''.  It is also rather hard to avoid saying that
a special variable is ``bound'' when it has a value, as ``boundp'' will
return true in this case.

Unfortunately, these meanings are in conflict.  For example, they allow for
the case in which a variable is ``bound'' but has no ``binding'' (namely,
when the reference is to the global value); the variable can be ``unbound'',
but have a binding (as you point out, when it is ``bound'', but valueless.)
If you simply refuse to say that a variable without any bindings is bound
(even though ``boundp'' of it is true), you are then committed to saying
that it is not `bound'', not ``unbound'', and has no ``binding'' (although,
of course, it has a perfectly fine and accessible value).  In addition, a
``bound variable'' appears to mean a variable that currently has a binding
(as in, ``a variable bound by `let' ''), although, of course, such a bound
variable may very well be ``unbound''.

In addition, there appears to be confusion as to whether a variable or a
binding is something that is referenced, etc.  For example, p. 37 talks
about the scope and extent of special bindings, whereas p. 38 talks about
the scope and extent of special variables.  it is unclear what a reference
to a variable that happens to be a parameter might be, other than a
reference to its current binding, since this is an fact the particular
instance of that paramater that is in force.  For example, p. 55 talks about
``the reference ... to the variable specified by the binding''.  It is not
clear how a particular instance of a parameter can specify a variable.  Nor
would this seem desirable.  If two different invocations of the same
function are considered to have the same variables but with different
bindings, then one would not want to reference any variable, but rather, the
current bindings of those variables.  

I could go on, but I think you get the point.

Here are some suggestions:

(1) Drop the notion of binding altogether.  I think this is really an old
implementation artifact.  Instead, say that every APPLICATION of a lambda
form creates new variables for its formal parameters.  Also, every symbol
has a global variable associated with it.  A variable may have a value, or
it may be valueless.  A variable has an extent and a scope.  

Introduce the function ``assignedp'', which meets the current description of
``boundp''.  ``setq'' changes the value of a variable through
``assignment''.  Lambda application creates a new variable and assigns it a
value. 

(2) Preserve the notion of a binding as the association of a variable and a
value.  We still say that every APPLICATION of a lambda form creates new
variables for its formal parameters.  But we can now consistently say that a
variable is bound, meaning that it has a binding, meaning that it is
currently associated with a value.  Leave ``boundp'' as is.  Parameter
variables, special variables and global variables can all be ``bound'' to
values.

(3) Introduce some more terminology.  First, state that all variables have
``bindings'', i. e., instances of variables.  This includes a global binding
for the global variable named by each symbol.  Different applications of a
lambda refer to different bindings of the same variable (if you must).  All
variables are always ``bound'', unless perhaps you introduce some new
construct that really and abnormally removes bindings.  In addition,
bindings, and only bindings, which are the only repositories for values, can
be ``assigned'' values.  ``assignedp'' does what ``boundp'' now does.

Note that if you define ``binding'' as a variable instance, i. e., an
object, rather than as an association of a variable (or variable instance)
with a symbol (or with a value!), then we are in need of terms to describe
(1) the relation of a symbol to a variable, (2) the relation of a variable
to its binding(s), and (3) relation of a binding to a value.  The first
seems to be the ``naming'' or ``named by'' relation; the second may be
called ``instantiation'',  or some such, and the third could be called
``assignment.''

Personally, I prefer (1).  It is simplest and least confusing.  The
terminology of shadowing can still apply to give a lucid description of the
rules of reference.  Also, it seems to be most compatible with the notion of
generalized variables.

(2) Special Form Terminology

A special form is defined as a form beginning with one of the symbols
appearing in Table 5-1.  However, p. 57 states that ``The  set of special
forms is fixed in Common LISP'' and that ``The set of special forms in
Common LISP is purposely kept very small''.  Of course, these claims are
both false.  There are an infinite number of special forms in Common LISP.
What is finite and small is the set of symbols that designate special forms.
These are referred to in Table 5-1 as the ``names'' of special forms.  

Ugh.  I propose the following terminology:  Leave the definition of special
forms alone.  Call the objects referred to by the symbols that designate
special forms ``special functions''.  Call the objects referred to by
symbols that invoke macro definitions ``macro functions''.  Call everything
else a ``normal'' function.  These are the unmarked case, analogous to the
lack of a compelling name for non-``special'' variables.  

This terminology appears to be consistent with ``symbol-function'', which
may return something ``representing a special form (sic) or macro.''





∂07-Jun-85  0651	gls@THINK.ARPA 	Arrays with zero dimensions. 
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 7 Jun 85  06:50:52 PDT
Received: by THINK.ARPA with CHAOS id AA05194; Fri, 7 Jun 85 09:47:08 edt
Date: Friday, 7 June 1985, 09:48-EDT
From: Guy Steele <gls@THINK.ARPA>
Subject: Arrays with zero dimensions.
To: greek@DEC-HUDSON@THINK.ARPA, common-lisp@su-ai
Cc: gls@THINK.ARPA
In-Reply-To: The message of 6 Jun 85 15:30-EDT from greek at DEC-HUDSON at think
Message-Id: <850607094803.1.GLS@DESIDERIUS.ARPA>

    Date: Thu, 06 Jun 85 15:30:40 EDT
    From: greek@DEC-HUDSON@think

    Is it really of cosmic importance that we allow dimensions of zero?
    We sure could invent a lot of baggage to handle it correctly, but...

    - Paul

Well, empty strings have their uses.  And in image processing I can
easily imagine wanting to extract a sub-rectangle of a rectangular
pixel array; in certain boundary cases one dimensions might be zero.
--Guy

∂07-Jun-85  0933	greek@DEC-HUDSON 	Arrays with Zero Dimensions
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 7 Jun 85  09:33:24 PDT
Date: Fri, 07 Jun 85 12:33:33 EDT
From: greek@DEC-HUDSON
Subject: Arrays with Zero Dimensions
To: common-lisp@su-ai

Yes, I should have made myself clearer.  Of course, zero-length vectors
are great.  But once you go to multiple dimensions, the problem of
telling which is zero is messy.

- Paul

∂09-Jun-85  1707	DCP@SCRC-YUKON.ARPA 	Arrays with zero dimensions. 
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 9 Jun 85  17:06:51 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 130299; Sun 9-Jun-85 13:43:55-EDT
Date: Sun, 9 Jun 85 14:56 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: Arrays with zero dimensions.
To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 6 Jun 85 15:30-EDT from greek@DEC-HUDSON
Message-ID: <850609145609.5.NFEP@NEPONSET.SCRC.Symbolics.COM>

    Date: Thu, 06 Jun 85 15:30:40 EDT
    From: greek@DEC-HUDSON

    Is it really of cosmic importance that we allow dimensions of zero?
    We sure could invent a lot of baggage to handle it correctly, but...

We already have it:
  (array-dimensions "") => (0)
The problems presented so far only come up when the number of dimensions
is 2 or more.  My answer to that is that such arrays have legitimate
structure and are therefore meaningful.  Zero-dimensional arrays
likewise have legitimate structure, which is why I assume they were
included in the language.

∂09-Jun-85  1707	DCP@SCRC-YUKON.ARPA 	common lisp- &environment objects 
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 9 Jun 85  17:07:10 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 130300; Sun 9-Jun-85 13:48:51-EDT
Date: Sun, 9 Jun 85 15:01 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: common lisp- &environment objects
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>,
    Guy Steele <gls@THINK.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12116842945.BABYL@CMU-CS-C.ARPA>
Message-ID: <850609150107.6.NFEP@NEPONSET.SCRC.Symbolics.COM>

    Date: Wed, 5 Jun 1985  22:06 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>


     The book is silent in the question of the extent of environments as delivered
     to &environment bindings in DEFMACRO, hook functions, etc.  What shall we say?

    One false move here and we have not Lisp but Conniver.  How about
    requiring "dynamic" extent for environment objects, and no more?  Will
    that take care of the needs for macro-expansion, steppers, and so on?
    True, you could imagine cute ways of using environments that outlive
    their invocations, but I REALLY don't want to pay for those cute uses
    with inefficiency or severe constraints on the implementor.  If anyone
    wants to implement Conniver in Common Lisp, I can supply the old Maclisp
    code, but let's not drag down Common Lisp itself.

Moon very carefully solved this problem in Symbolics' implementation of
Common Lisp by having an &ENVIRONMENT keyword to defmacro and making
sure all possible expanders of macros took an optional environment
argument, to which they can pass to MACROEXPAND(-1).  This isn't cute;
it is functional.  It isn't inefficient and it doesn't pose any
constraints on the implementor, unless I misunderstand what "the
implementor" is suposed to mean.

∂09-Jun-85  1756	ima!inmet!norman@cca-unix
Received: from CCA-UNIX.ARPA by SU-AI.ARPA with TCP; 9 Jun 85  17:56:22 PDT
Received: by cca-unix.ARPA (4.12/4.7)
	id AA29292; Sun, 9 Jun 85 20:55:25 edt
Date: Sun, 9 Jun 85 20:55:25 edt
From: ima!inmet!norman@cca-unix
Message-Id: <8506100055.AA29292@cca-unix.ARPA>
Sender: inmet!norman@cca-unix
To: Common-lisp@SU-AI.ARPA

Would you add my name to the common lisp distributaion list.
My mailing address is ima!imnet!norman@cca-unix.arpa

Thanks    Norman rubin
          Intermetrics

∂09-Jun-85  2016	FAHLMAN@CMU-CS-C.ARPA 	common lisp- &environment objects    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 9 Jun 85  20:16:07 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 9 Jun 85 23:17:03-EDT
Date: Sun, 9 Jun 1985  23:17 EDT
Message-ID: <FAHLMAN.12117904408.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   "David C. Plummer in disguise" <DCP@SCRC-QUABBIN.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: common lisp- &environment objects
In-reply-to: Msg of 9 Jun 1985  15:01-EDT from David C. Plummer in disguise <DCP at SCRC-QUABBIN.ARPA>


        One false move here and we have not Lisp but Conniver.  How about
        requiring "dynamic" extent for environment objects, and no more?  Will
        that take care of the needs for macro-expansion, steppers, and so on?
        True, you could imagine cute ways of using environments that outlive
        their invocations, but I REALLY don't want to pay for those cute uses
        with inefficiency or severe constraints on the implementor.  If anyone
        wants to implement Conniver in Common Lisp, I can supply the old Maclisp
        code, but let's not drag down Common Lisp itself.

    Moon very carefully solved this problem in Symbolics' implementation of
    Common Lisp by having an &ENVIRONMENT keyword to defmacro and making
    sure all possible expanders of macros took an optional environment
    argument, to which they can pass to MACROEXPAND(-1).  This isn't cute;
    it is functional.  It isn't inefficient and it doesn't pose any
    constraints on the implementor, unless I misunderstand what "the
    implementor" is suposed to mean.

I don't understand what you are saying here.  What does this have to do
with the extent of environment objects?  What, exactly, are you arguing
for?

As I said in an immediate follow-up to the above message, you only get a
lot of additional expense if you actually let users do all of the
"obvious" things with an immortal environment object, such as going to
the tags and diddling the lexical variables.  I really don't care if
environment objects have indefinite or dynamic extent, as long as these
expensive kinds of uses are clearly forbidden once you exit the dynamic
extent, but the politics of this group are such that we must be very
careful about introducing features that, if taken to their logical
conclusion, lead us to somewhere we don't want to go; there are always a
lot of people who demand that everything be taken to its logical
conclusion, and damn the expense, so it is sometimes better not to take
the first step.

I do note that the original query suggested that Symbolics was
stack-allocating environment objects, and other implementations might
want to do similarly tense things in order to make the interpreter
reasonably cons-free.  That suggests to me that it would be a good idea
to allow environment objects to have dynamic extent only, unless someone
can explain why this is unworkable or can demonstrate some important
thing that cannot be done if we take this position.  I am always
nervous about disappearing objects, such as the disappearing &rest args
in Zetalisp (not legal in Common Lisp), but in the case of environment
arguments we might choose to go with a dangerous but efficient solution.

-- Scott

∂10-Jun-85  0357	DCP@SCRC-STONY-BROOK.ARPA 	common lisp- &environment objects
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 Jun 85  03:57:02 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 250864; Mon 10-Jun-85 06:54:31-EDT
Date: Mon, 10 Jun 85 06:56 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: common lisp- &environment objects
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>,
    David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12117904408.BABYL@CMU-CS-C.ARPA>
Message-ID: <850610065628.8.NFEP@NEPONSET.SCRC.Symbolics.COM>

    Date: Sun, 9 Jun 1985  23:17 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>


	    One false move here and we have not Lisp but Conniver.  How about
	    requiring "dynamic" extent for environment objects, and no more?  Will
	    that take care of the needs for macro-expansion, steppers, and so on?
	    True, you could imagine cute ways of using environments that outlive
	    their invocations, but I REALLY don't want to pay for those cute uses
	    with inefficiency or severe constraints on the implementor.  If anyone
	    wants to implement Conniver in Common Lisp, I can supply the old Maclisp
	    code, but let's not drag down Common Lisp itself.

	Moon very carefully solved this problem in Symbolics' implementation of
	Common Lisp by having an &ENVIRONMENT keyword to defmacro and making
	sure all possible expanders of macros took an optional environment
	argument, to which they can pass to MACROEXPAND(-1).  This isn't cute;
	it is functional.  It isn't inefficient and it doesn't pose any
	constraints on the implementor, unless I misunderstand what "the
	implementor" is suposed to mean.

    I don't understand what you are saying here.  What does this have to do
    with the extent of environment objects?  What, exactly, are you arguing
    for?

I'm arguing that CLtL says much too little about environments.  It does
not say how to get your hands on one, but specifies them as optional
arguments to functions, for example EVALHOOK, APPLYHOOK, MACROEXPAND(-1)
(and in our implementation EVAL).  Dynamic extent isn't good enough; how
can you do upward funargs?  This is far from cute:
	(defun adder (val)
	  #'(lambda (x) (+ x val)))
it is instead at the heart of lexical scoping.

    As I said in an immediate follow-up to the above message, you only get a
    lot of additional expense if you actually let users do all of the
    "obvious" things with an immortal environment object, such as going to
    the tags 
Tags have dynamic extent.  Going with tags outside their dynamic extent
should generate errors.
    and diddling the lexical variables.
What good is lexical scoping if you can't diddle lexical variables?
    I really don't care if
    environment objects have indefinite or dynamic extent, as long as these
    expensive kinds of uses are clearly forbidden once you exit the dynamic
    extent, but the politics of this group are such that we must be very
    careful about introducing features that, if taken to their logical
    conclusion, lead us to somewhere we don't want to go; there are always a
    lot of people who demand that everything be taken to its logical
    conclusion, and damn the expense, so it is sometimes better not to take
    the first step.
CLtL'84, on page 39 pretty clearly gives the scope and extent of just
about everything.  Maybe you are concerned that I want the users to
diddle with the environment itself?  Not at all.  The structure of the
environment is peculiar to the implementation.  I am, perhaps
incorrectly, assuming that creating a lexical closure captures the
current environment.

    I do note that the original query suggested that Symbolics was
    stack-allocating environment objects, and other implementations might
    want to do similarly tense things in order to make the interpreter
    reasonably cons-free.  That suggests to me that it would be a good idea
    to allow environment objects to have dynamic extent only, unless someone
    can explain why this is unworkable or can demonstrate some important
    thing that cannot be done if we take this position.  I am always
    nervous about disappearing objects, such as the disappearing &rest args
    in Zetalisp (not legal in Common Lisp), but in the case of environment
    arguments we might choose to go with a dangerous but efficient solution.
I'll repeat the classic lexical scoping example:
	(defun adder (val)
	  #'(lambda (x) (+ x val)))
Environments must have indefinite extent (at least the environment of
non-special variables and local functions (FLET, LABELS)).  The way this
works is that the environment has a slot which is called ENV-EVACUATION
which is the heap version created as necessary.  Therefore, internal
interpreter functions (e.g., the definition of the FUNCTION special
form) explicitly evacuate the environment since it is being stored in
permanent storage.

∂10-Jun-85  0646	FAHLMAN@CMU-CS-C.ARPA 	common lisp- &environment objects    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 Jun 85  06:46:12 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 10 Jun 85 09:47:18-EDT
Date: Mon, 10 Jun 1985  09:47 EDT
Message-ID: <FAHLMAN.12118019135.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   "David C. Plummer in disguise" <DCP@SCRC-QUABBIN.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: common lisp- &environment objects
In-reply-to: Msg of 10 Jun 1985  06:56-EDT from David C. Plummer in disguise <DCP at SCRC-QUABBIN.ARPA>


    I'm arguing that CLtL says much too little about environments.  It does
    not say how to get your hands on one, but specifies them as optional
    arguments to functions, for example EVALHOOK, APPLYHOOK, MACROEXPAND(-1)
    (and in our implementation EVAL).  Dynamic extent isn't good enough; how
    can you do upward funargs?  This is far from cute:
    	(defun adder (val)
    	  #'(lambda (x) (+ x val)))
    it is instead at the heart of lexical scoping.

Ah, OK, we've got some misunderstanding here between the general concept
of an environment and the specific concept of an environment object, as
returned by &environment.  I agree that lexical closures have to work,
and that this requires that some parts of the environment in which a
function is closed be saved with indefinite extent.  However, this
doesn't say that environment objects must have indefinite extent.  It
doesn't even say that the lexical variable part of the environment has
to be saved or has to be an object with indefinite extent.  In our
current (inefficient) Spice Lisp interpreter, this environment is a
consed A-list, but one could certainly imagine an implementation that
stack allocated this structure (with provision for saving it if a
closure is created) or some sort of shallow-bound variable environment
that never has a specific object that represents the current variable
environment, but that somehow arranges to save all the right value cells
when a closure is created.  So I agree that closures have to work, but
not that this implies anything about the extent of environment objects.

In speaking of the expense of diddling variable values, I am referring
to those values that are not part of any lexical closure, but that might
somehow still be accessible if we were to take seriously the notion that
environment objects can be kept alive indefinitely and passed around.  I
don't think we want to allow this.  We do, of course, have to make sure
that properly created lexical closures work properly, but we should not
specify the internal mechanism that makes that possible.  Parts of the
lexical function name environment must similarly be of indefinite extent
if FLET and LABELS are to work properly, but again we do not need to
keep the entire environment around in order to accomplish this.

Clearly go-tags and block-names want to become inoperative outside of
the dynamic extent of their blocks, whatever we decide about the extent
of environment objects.

So again the question is whether we can accomplish everything we need to
with environment objects even if these objects have only dynamic extent.
Whether some parts of the environment need to have indefinite extent in
order to make closures work is a different question, I think.

-- Scott

∂10-Jun-85  0702	REM@IMSSS 	Environment-objects don't exist in CL according to manual  
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Jun-10 06:01:26 PST (=GMT-8hr)
Date: 1985 June 10 06:00:54 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132222142466.G0353
From: Robert Elton Maas <REM@IMSSS.SU.EDU>
To:COMMON-LISP@SU-AI
SUBJECT:Environment-objects don't exist in CL according to manual
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up)

Prodded by all this recent discussion about whether environments have
dynamic or indefinite extent, how one might obtain an
environment-object so as to pass it as optional argument to EVAL, what
kinds of info might be captured in such an object, I looked in the
index to the CL manual to see what the manual said about environments.
The answer, if I can believe the index, is that CL has no such things
as environment objects. There are only two mentions of "environment"
in the index: one referring to a general statement that special
structures in CL allow the programmer to organize a program, some
having to do with flow of control (control structures) and others
controlling access to variables (environment structures); the other
referring to LISP funcitons to query the system regarding such matters
as time-of-day or CPU-ID. Neither has anything to do with the topic
that seems to be under discussion recently.

Is this recent discussion utter nonsense (referring to some local
extension to CL rather than to CL itself), or is the index grossly
deficient in this topic? If the latter, can somebody supply me/us with
a list of pages where environment objects are discussed in the CL
manual? If the former, there seems to be no need to introduce the
topic; if environment-objects can't be passed to functions, there's no
need to worry about how to create them or what aspects of the
environment they might encapsulate if they could be created.

∂10-Jun-85  0748	FAHLMAN@CMU-CS-C.ARPA 	Environment-objects don't exist in CL according to manual
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 Jun 85  07:48:35 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 10 Jun 85 10:49:50-EDT
Date: Mon, 10 Jun 1985  10:49 EDT
Message-ID: <FAHLMAN.12118030498.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   REM%IMSSS@λSU-SCORE.ARPA (temporary until nameservers up)λ
Cc:   COMMON-LISP@SU-AI.ARPA
Subject: Environment-objects don't exist in CL according to manual


Assuming that something doesn't exist in Common Lisp just because it
doesn't appear in the index of the manual is a pretty risky business.
In fact, this business of environment objects would probably be indexed
under &environment, but all the &-thingies got left out of the index.
In this case, the problem is compounded by a serious typo in the text.

The use of &evironment in the arglist of a defmacro is described on page
145 at the very bottom.  In my copy of the manual, at least, the actual
word "&environment" got left out, but it is supposed to be the label for
the last paragraph on this page, after the paragraph describing &whole.

Uses of these environment objects are described under macroexpand and
macroexpand-1, and also under the hook functions in the Eval chapter.
Subsequent discussion has revealed that you also need these environment
objects as arguments to the proposed PARSE-BODY, to MACRO-FUNCTION, and
also to GET-SETF-METHOD.  Arguably also to EVAL, because of the damned
macro-> declaration business, but I'm not sure about that.  Basically,
everyone who might have to expand a macro as part of the expansion of
another macro has to receive the environment object so that lexically
defined macros are handled properly.

I have come around to the conclusion that we really blew it when we let
MACROLET into the language, despite that operator's occasional
usefulness.  If not for that, none of this environment hackery would be
necessary, and macro->declaration processing would be straightforward.

-- Scott

∂10-Jun-85  1040	HEDRICK@RUTGERS.ARPA 	extent of environments 
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 10 Jun 85  10:40:06 PDT
Date: 10 Jun 85 13:39:50 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: extent of environments
To: common-lisp@SU-AI.ARPA

TOPS-20 Common Lisp in fact does precisely what Scott conjectured
a hypothetical implementation might do:  We put the environment
information on the stack.  We copy it into the heap whenever we have
to give the information to the user.  This seems to speed up the
interpreter a lot.  If somebody can guarantee us that the things
we give to a macro with &environment can safely be left on the
stack, that would speed up those macro expansions.  This is not
critical, however, since we only do macro expansions once.  (We
use the old UCI Lisp displacement technique.)  What has actually
stopped us from doing &environment is not this problem (which is
trivial to fix - after all we already have the function to copy
the environment into the heap) but the fact that we have to make
the compiler do it also.  Thus the compiler is going to have to
construct an environment which will look to the macro as if it were
the runtime enviornment in which the macro was called.  The copy
of Spice Lisp that we have (which may, as usual, be slightly
out of date) simply doesn't deal with these issues.  Indeed in
SETF they have a separate macro expander that explicitly tests
whether it is in the compiler or not.  We are going to have to
replace that with a new mechanism that does things right.  The 
whole implementation of macros that expand to declarations and
&environment seems to be one single knotted mess, which I will
solve the first time I get a weekend that I can devote to it.
-------

∂10-Jun-85  1108	greek@DEC-HUDSON 	Scott's observation on MACROLET 
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 10 Jun 85  11:07:54 PDT
Date: Mon, 10 Jun 85 13:37:28 EDT
From: greek@DEC-HUDSON
Subject: Scott's observation on MACROLET
To: common-lisp@su-ai

MACROLET?  What's MACROLET?  Must be a mistake.  Let's erase it from
the book.

- Paul

∂10-Jun-85  1200	DCP@SCRC-STONY-BROOK.ARPA 	common lisp- &environment objects
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 Jun 85  11:59:44 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 251236; Mon 10-Jun-85 14:57:03-EDT
Date: Mon, 10 Jun 85 14:59 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: common lisp- &environment objects
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>,
    David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12118019135.BABYL@CMU-CS-C.ARPA>
Message-ID: <850610145904.7.NFEP@NEPONSET.SCRC.Symbolics.COM>

    Date: Mon, 10 Jun 1985  09:47 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

    So again the question is whether we can accomplish everything we need to
    with environment objects even if these objects have only dynamic extent.
    Whether some parts of the environment need to have indefinite extent in
    order to make closures work is a different question, I think.

OK, I think I understand the question you are asking.  My question is:
Does it matter?  I cannot think of any valid programs (read: macros)
that would want to store an environment in permanent storage.  For that
matter, I cannot think of any valid programs (read: macros) that side
effect the environment.  They only USE them, which means you pass them
as arguments to macroexpand(-1).  Therefore, I don't think it matters
how they are implemented, since all programs should be using them as
lexical scope, dynamic extent, which is the most restrictive.  The only
"program" that needs to update the environment is the interpreter (read:
special forms), and that "program" is supplied by the vendor and users
don't need to know about it.

Aside: Symbolics' EVAL function takes an &OPTIONAL ENV argument so that
the implementation of special forms can call EVAL instead of
EVAL-WITH-ENV or somesuch.

∂10-Jun-85  2256	@MIT-MC:BROOKS@MIT-OZ 	function type specifiers   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 10 Jun 85  22:56:10 PDT
Received: from MIT-OZ by MIT-MC via Chaosnet; 11 JUN 85  01:00:22 EDT
Date: Tue 11 Jun 85 00:57:48-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: function type specifiers
To: common-lisp@SU-AI.ARPA
cc: jk@SU-AI.ARPA

In CTtL page 47 it defines a function type specifier to look like:
	(function (arg1-type arg2-type ...) value-type)
and says "The value-type may be a values type specifier in order to
indicate the types of multiple values.".

On page 158 in talking about delarations it says that for
	(ftype type function-name-1 function-name-2 ...)
type must be a functional type. Then on page 159 it says that
	(function name arglist result-type1 result-type-2 ...)
is entirely equivalent to
	(ftype (function arglist result-type1 result-type2 ...) name)
which establishes a contradiction. Page 159 should be changed.
-------

∂11-Jun-85  1043	RWW  	using lower case   
To:   common-lisp@SU-AI.ARPA
Is there any way to make common lisp simply be totally case sensitive in the 
naive way?  I would somply like symbols to have PNAMES like
Hello     or
hEllo	  or
heLLo
...

and all be different symbols which I do not need to type any other 
characters to use this way?
Richard

∂11-Jun-85  1245	Moon@SCRC-STONY-BROOK.ARPA 	Adjustable and displaced arrays 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85  12:45:10 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252220; Tue 11-Jun-85 15:42:22-EDT
Date: Tue, 11 Jun 85 15:44 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Adjustable and displaced arrays
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>, greek@DEC-HUDSON.ARPA,
    Glenn S. Burke <GSB@MIT-MC.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12113193061.BABYL@CMU-CS-C.ARPA>,
             The message of 23 May 85 09:57-EDT from greek@DEC-HUDSON,
             <850523163729.9.NFEP@NEPONSET.SCRC.Symbolics.COM>,
             <[MIT-MC].516737.850524.GSB0>,
             The message of 28 May 85 11:21-EDT from greek@DEC-HUDSON,
             <850528124820.3.NFEP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <850611154451.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

Perhaps I can clarify one or two points in this discussion.

    Date: Wed, 22 May 1985  23:56 EDT
    From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>

    I am somewhat confused about the interaction between array adjustment
    and displacement.

    In CLTL p298:

	Note that if the array a is created displaced to array b and
	subsequently array b is given to adjust-array, array a will still
	be displaced to array b; the effects of this displacement and the
	rule of row-major storage order must be taken into account.

    What is this trying to say?  Is this a warning to the user or a threat
    to the implementor?  The obvious interpretation of this statement
    seems to require that all non-simple arrays contain a list of all the
    other array headers that share the same data so that they can be fixed
    up when the array is adjusted.  The answer that you stick in a
    forwarding pointer is not acceptable.

I can't tell what you mean by your last two sentences, but if you encache
information about array b inside of array a, you must arrange one way or
another to discover when that cache is invalid.  An alternative to encaching
is to examine array b on every access to array a.  We use a combination of
both techniques; normal array accesses to array a examine array b, but a
tight array processing loop can use a declaration to get the array decoding
moved outside of the loop.  This encached information is automatically
updated if any array is adjusted (our hardware can do with this without
taking any extra time; the validity check for the encached information
consists of comparing two numbers, one of which increments every time an
array is adjusted, and is overlapped with memory access time).  In a system
that doesn't allow multiple processes, you could probably get away without
any provision for cache updating if you require the user not to do any
array adjustment inside his inner loop.

    The statement in the manual also doesn't answer the question of what
    happens to array b if array a is adjusted.  Is it legal or meaningful
    to have arrays which are both displaced to another array and
    adjustable?  What are the semantics of adjusting such an array?

The answer is that it is extremely straightforward.  Adjusting array a
never affects array b in any way.  Adjusting a displaced array never moves
any data elements around in storage; it simply changes the dimensions,
displaced-to, and/or index-offset of the displaced array.  It sounds like
the manual needs to be improved.

    Date: Thu, 23 May 85 09:57:23 EDT
    From: greek@DEC-HUDSON

    We were so confused about the problem of adjusting displaced arrays,
    we simply don't allow it in VAX LISP.  I'd sure appreciate some
    thoughts on the matter myself.

See above; adjusting displaced arrays is much easier than adjusting
ordinary arrays.

    Date: Tue, 28 May 85 11:21:20 EDT
    From: greek@DEC-HUDSON

    Erf!  I certainly should have objected to the incredible hair needed
    to implement adjustable arrays, particularly those which are displaced,
    back when we specified them.  However, I'd like to object now.

    I'd like to see a list of the uses people make of displaced and
    adjustable arrays.  Maybe there are only two or three real features
    that people use, and we could restrict ourselves to those.  I looked
    around here at DEC, and found exactly two uses:

    1.  Make an array bigger.  Obviously this could be done with MAKE-ARRAY
	and REPLACE.

This is not obvious at all!  Suppose there are multiple references to the
original array; how do they get updated to refer to the new copy?  That
issue is the whole reason why adjustable arrays exist.

    2.  Linearize a multidimensional array so that row-major references
	can be done.  This is useful, but an AREF-ROW-MAJOR function could
	probably do it more efficiently.

    It seems to me that any set of rules that require AREF to iterate to
    find the data ought to be simplified.  So much for inline code.

Common Lisp was explicitly not designed for efficient implementation on
Fortran machines in the absence of declarations.  Does the ability to declare
an array to be SIMPLE take care of your problems with implementing inline
code for AREF?  If not, there is an issue we need to address.

    Date: Tue, 28 May 85 12:48 EDT
    From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>

    I don't think we don't use it for your case (1); instead we do make a
    new array, copy, and structure forwared the old to the new.  They can
    also be used for your case (2), but I think the our function
    SYS:%1D-AREF subsumes the need.

Slight clarifications: SYS:%1D-AREF and AREF-ROW-MAJOR are two names for
exactly the same thing.  "structure forward" is a Lisp machine concept
that does not exist in Common Lisp.

∂11-Jun-85  1247	FAHLMAN@CMU-CS-C.ARPA 	using lower case      
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Jun 85  12:47:48 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 11 Jun 85 15:46:08-EDT
Date: Tue, 11 Jun 1985  15:46 EDT
Message-ID: <FAHLMAN.12118346592.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   Richard Weyhrauch <RWW@SU-AI.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: using lower case   
In-reply-to: Msg of 11 Jun 1985  13:43-EDT from Richard Weyhrauch <RWW at SU-AI.ARPA>


There is no way in standard Common Lisp to get full case-sensitivity as
the reader default.  Individual implementations may have a
case-sensitive input mode as an extension, but the CMU code upon which
many Common Lisp implementations are based does not have this feature.

-- Scott

∂11-Jun-85  1259	Moon@SCRC-STONY-BROOK.ARPA 	Degenerate array axes      
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85  12:59:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252237; Tue 11-Jun-85 15:54:53-EDT
Date: Tue, 11 Jun 85 15:57 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Degenerate array axes   
To: Jon White <JLW@SU-AI.ARPA>, Guy Steele <gls@THINK.ARPA>,
    Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>,
    Richard Mlynarik <MLY@MIT-MC.ARPA>, greek@DEC-HUDSON.ARPA,
    David C. Plummer in disguise <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 6 Jun 85 08:43-EDT from Jon White <JLW@SU-AI.ARPA>,
             <850606103442.4.GLS@DESIDERIUS.ARPA>,
             <FAHLMAN.12116985877.BABYL@CMU-CS-C.ARPA>,
             <[MIT-MC.ARPA].532788.850606.MLY>,
             The message of 6 Jun 85 15:30-EDT from greek@DEC-HUDSON,
             The message of 7 Jun 85 12:33-EDT from greek@DEC-HUDSON,
             <850609145609.5.NFEP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <850611155723.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

I read the seven messages in this discussion about multidimensional arrays where
some of the dimensions (other than the last) are zero.  My opinion is that the
language semantics are correct and consistent, and the problem lies solely in
the print syntax.  The best suggestion so far, in my opinion, is the one from
Mlynarik that when array cannot be meaningfully be printed with #A it should
be printed with #.(MAKE-ARRAY ...).

∂11-Jun-85  1311	Moon@SCRC-STONY-BROOK.ARPA 	common lisp- &environment objects    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85  13:11:16 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252256; Tue 11-Jun-85 16:08:31-EDT
Date: Tue, 11 Jun 85 16:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: common lisp- &environment objects
To: David C. Plummer in disguise <DCP@QUABBIN.SCRC.Symbolics.COM>,
    Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <850610145904.7.NFEP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <850611161100.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 10 Jun 85 14:59 EDT
    From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>

	Date: Mon, 10 Jun 1985  09:47 EDT
	From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

	So again the question is whether we can accomplish everything we need to
	with environment objects even if these objects have only dynamic extent.
	Whether some parts of the environment need to have indefinite extent in
	order to make closures work is a different question, I think.

    OK, I think I understand the question you are asking.  My question is:
    Does it matter?  I cannot think of any valid programs (read: macros)
    that would want to store an environment in permanent storage.  For that
    matter, I cannot think of any valid programs (read: macros) that side
    effect the environment.  They only USE them, which means you pass them
    as arguments to macroexpand(-1).  Therefore, I don't think it matters
    how they are implemented, since all programs should be using them as
    lexical scope, dynamic extent, which is the most restrictive.  The only
    "program" that needs to update the environment is the interpreter (read:
    special forms), and that "program" is supplied by the vendor and users
    don't need to know about it.

I think Scott has hit the nail on the head and I also agree with Dave's comments.
To sum up: the data structure that Common Lisp offers to users is the lexical
closure, not the environment.  The only thing a user can do with an environment
is receive it as an argument and pass it to another function as an argument.
I believe that these environments should be defined to have only dynamic extent;
in other words, a user isn't allowed to save them away in permanent structures.


∂11-Jun-85  1316	Moon@SCRC-STONY-BROOK.ARPA 	Does Defmacro establish a block?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85  13:16:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252265; Tue 11-Jun-85 16:12:17-EDT
Date: Tue, 11 Jun 85 16:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Does Defmacro establish a block?
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA, bug-CLCP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <RAM.12114291388.BABYL@CMU-CS-C.ARPA>
Message-ID: <850611161450.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 27 May 1985  04:30 EDT
    From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>

	Does defmacro establish a named block around the definition the
    same way that defun does?  CLTL doesn't mention this issue at all,
    leading one to suppose that it doesn't, but this seems to create a
    pointless inconsistency with defun.

	If defmacro does, do define-setf-method, defsetf, deftype...?

I believe that all defining forms that have a name and a body should put
a named block around the body.  In our implementation, defun and defmacro
do so, but currently the others you mentioned do not.  I'm calling that
a bug in our implementation and suggesting that a future clarification
of Common Lisp should require this.

∂11-Jun-85  1317	gls@THINK.ARPA 	Environment-objects don't exist in CL according to manual  
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85  13:17:29 PDT
Received: by THINK.ARPA with CHAOS id AA27754; Tue, 11 Jun 85 16:12:51 edt
Date: Tuesday, 11 June 1985, 16:14-EDT
From: Guy Steele <gls@THINK.ARPA>
Subject: Environment-objects don't exist in CL according to manual
To: REM%IMSSS@SU-SCORE.ARPA, COMMON-LISP@SU-AI
Cc: gls@THINK.ARPA
In-Reply-To: SU-IMSSS.REM.A132222142466.G0353
Message-Id: <850611161408.2.GLS@ROCK.ARPA>

    Date: 1985 June 10 06:00:54 PST (=GMT-8hr)
    From: Robert Elton Maas <REM@IMSSS.SU.EDU@think>

    ...
    The answer, if I can believe the index, is that CL has no such things
    as environment objects. ...

You can't believe the index.  The index is lousy.  I am looking into automated
technology to improve the index for the next edition.
--Guy

∂11-Jun-85  1817	FAHLMAN@CMU-CS-C.ARPA 	Does Defmacro establish a block?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Jun 85  18:16:51 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 11 Jun 85 21:17:43-EDT
Date: Tue, 11 Jun 1985  21:17 EDT
Message-ID: <FAHLMAN.12118406963.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA, Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Subject: Does Defmacro establish a block?
In-reply-to: Msg of 11 Jun 1985  16:14-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


    	If defmacro does, do define-setf-method, defsetf, deftype...?

    I believe that all defining forms that have a name and a body should put
    a named block around the body.  In our implementation, defun and defmacro
    do so, but currently the others you mentioned do not.  I'm calling that
    a bug in our implementation and suggesting that a future clarification
    of Common Lisp should require this.

I can accept this, but let's be sure we agree on what the block name
would be in each case.  For the SETF forms, is it the name of the
accessing operator?  For DEFTYPE, is it the name of the type?

-- Scott

∂11-Jun-85  1819	FAHLMAN@CMU-CS-C.ARPA 	common lisp- &environment objects    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Jun 85  18:19:03 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 11 Jun 85 21:20:04-EDT
Date: Tue, 11 Jun 1985  21:19 EDT
Message-ID: <FAHLMAN.12118407391.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: common lisp- &environment objects
In-reply-to: Msg of 11 Jun 1985  16:11-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


    To sum up: the data structure that Common Lisp offers to users is the lexical
    closure, not the environment.  The only thing a user can do with an environment
    is receive it as an argument and pass it to another function as an argument.
    I believe that these environments should be defined to have only dynamic extent;
    in other words, a user isn't allowed to save them away in permanent structures.

Fine, I agree with Moon.  Any passionately dissenting opinions?

-- Scott

∂11-Jun-85  1825	FAHLMAN@CMU-CS-C.ARPA 	Degenerate array axes      
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Jun 85  18:25:38 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 11 Jun 85 21:26:34-EDT
Date: Tue, 11 Jun 1985  21:26 EDT
Message-ID: <FAHLMAN.12118408573.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Degenerate array axes   
In-reply-to: Msg of 11 Jun 1985  15:57-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


OK, maybe the best way out is to follow Mlynarik's suggestion that (a)
we allow multi-D arrays with one or more dimensions of 0 and (b) we go
with #.make-array for those situations where the #A syntax can't make
it.  That way we avoid a significant incompatible change to the syntax
and we avoid outlawing a heretofore legal object type.

-- Scott

∂11-Jun-85  1842	FAHLMAN@CMU-CS-C.ARPA 	Adjustable and displaced arrays 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Jun 85  18:42:42 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 11 Jun 85 21:43:42-EDT
Date: Tue, 11 Jun 1985  21:43 EDT
Message-ID: <FAHLMAN.12118411695.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Adjustable and displaced arrays
In-reply-to: Msg of 11 Jun 1985  15:44-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


OK, if we accept Moon's view of the proper semantics for all this, and
if we decide not to outlaw displacing to adjustable arrays, then the
Fortran machines probably have to forego cacheing and let each call to
Aref potentially grovel the headers of both arrays (or a whole chain of
arrays).  Maybe that is not so bad, since none of this affects
Simple-Vectors, and they are the only kind of array that really HAS to
be fast.

However, the vendors of non-microcodable machines may feel, with some
justification, that they don't want to slow down ALL references to
non-simple arrays just so that the obscure case of adjusting an array
that is displaced to will work properly.  Perhaps the right move is to
unbundle the SIMPLE declaration and allow the user to declare that an
array is NOT-DISPLACED, even if it is not simple in other respects.

-- Scott

∂11-Jun-85  2048	Moon@SCRC-STONY-BROOK.ARPA 	Does Defmacro establish a block?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85  20:48:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252531; Tue 11-Jun-85 23:45:14-EDT
Date: Tue, 11 Jun 85 23:47 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Does Defmacro establish a block?
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA, Rob MacLachlan <RAM@CMU-CS-C.ARPA>
In-Reply-To: <FAHLMAN.12118406963.BABYL@CMU-CS-C.ARPA>
Message-ID: <850611234750.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 11 Jun 1985  21:17 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>


	    If defmacro does, do define-setf-method, defsetf, deftype...?

	I believe that all defining forms that have a name and a body should put
	a named block around the body.  In our implementation, defun and defmacro
	do so, but currently the others you mentioned do not.  I'm calling that
	a bug in our implementation and suggesting that a future clarification
	of Common Lisp should require this.

    I can accept this, but let's be sure we agree on what the block name
    would be in each case.  For the SETF forms, is it the name of the
    accessing operator?  For DEFTYPE, is it the name of the type?

Yes.  I propose this rule: In any DEFxxx form that has a body that is code to
executed, then if CADR of the form is a symbol, then a BLOCK with that symbol
as its name is automatically wrapped around the body in such a place that
RETURN-FROM that block is the same as making the body evaluate to the returned
value.  The complicated language here is to deal with the case where the 
form expands into a large bunch of code with the user-supplied body buried
somewhere inside it.

∂11-Jun-85  2052	Moon@SCRC-STONY-BROOK.ARPA 	Adjustable and displaced arrays 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85  20:52:13 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252533; Tue 11-Jun-85 23:49:29-EDT
Date: Tue, 11 Jun 85 23:51 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Adjustable and displaced arrays
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12118411695.BABYL@CMU-CS-C.ARPA>
Message-ID: <850611235159.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 11 Jun 1985  21:43 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>


    OK, if we accept Moon's view of the proper semantics for all this, and
    if we decide not to outlaw displacing to adjustable arrays, then the
    Fortran machines probably have to forego cacheing and let each call to
    Aref potentially grovel the headers of both arrays (or a whole chain of
    arrays).  Maybe that is not so bad, since none of this affects
    Simple-Vectors, and they are the only kind of array that really HAS to
    be fast.

    However, the vendors of non-microcodable machines may feel, with some
    justification, that they don't want to slow down ALL references to
    non-simple arrays just so that the obscure case of adjusting an array
    that is displaced to will work properly.  Perhaps the right move is to
    unbundle the SIMPLE declaration and allow the user to declare that an
    array is NOT-DISPLACED, even if it is not simple in other respects.

Sure.  I would think that an appropriate way to proceed would be for the
implementors on non-Lisp machines to get together and agree on a common
set of language extensions to deal with this sort of issue.  At a later
time, those extensions can be moved into the standard language, once
they are well-debugged and agreed to be the right thing for all machines
that need them.  Until that happens, programs that use the extensions won't
be portable to all implementations (but they will probably be portable to
almost all implementations if the extensions are designed right, e.g. as
ignorable declarations).

∂12-Jun-85  0417	walton%ll-xn.arpa@ll-xn.arpa 	Two suggestions on array adjustability. 
Received: from LL-XN.ARPA by SU-AI.ARPA with TCP; 12 Jun 85  04:16:54 PDT
Received: by ll-xn.arpa.ARPA (4.24/4.7)
	id AA02250; Wed, 12 Jun 85 07:17:35 edt
Date: Wed, 12 Jun 85 07:17:35 edt
From: walton%ll-xn.arpa@ll-xn.ARPA (Robert Walton)
Message-Id: <8506121117.AA02250@ll-xn.arpa.ARPA>
To: common-lisp@su-ai
Subject: Two suggestions on array adjustability.

We (Machine Intelligence and Tactical Sensors Project of MIT Lincoln Laboratory)
have an `image understanding operating system' called SKETCH written
in FRANZ and C and running on a VAX which has a large array package
that effectively replaces the FRANZ array package for our purposes.
Based on our experience with this, I do not think we could (optimally)
use COMMON LISP arrays for an image understanding system, and here are
two suggestions, triggered by the recent discussion of displaced arrays,
that might begin to fix this.

(1) Non-adjustability should be a dynamic declarable attribute.
    If an array is declared non-adjustable in a block, it should be an error
    to adjust the array when the block is active.  The compiler
    should make use of the declaration to optimize code.

    However, when an array is in no such block, it should be adjustable.

    Non-adjustability of a displaced array implies non-adjustability of
    the array it is displaced to.

    We often adjust displaced arrays and then pass them off to C code that
    treats them as non-adjustable (given a good enough COMMON LISP compiler
    we might, sometime in the future, replace the C code with COMMON LISP code).

    [I would guess that non-adjustability could never be the same as simplicity,
    since the later may imply a different array header structure, and untagged
    hardware should know about this difference at compile time if possible.]

(2) Displaced arrays should be allowed to have non-standard subscript
    multipliers.  Negative multipliers and 0 should be allowed.

    We use this most frequently to transpose arrays and reverse left and right
    or up and down.  It is obviously applicable to decimating arrays,
    though we have little actual experience with this.

I offer these suggestions from the user's point of view only, though they
certainly seem implementable to me (after being refined to make them
more precise).

∂12-Jun-85  0557	greek@DEC-HUDSON 	Using #.(MAKE-ARRAY ...    
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 12 Jun 85  05:56:41 PDT
Date: Wed, 12 Jun 85 08:56:25 EDT
From: greek@DEC-HUDSON
Subject: Using #.(MAKE-ARRAY ...
To: common-lisp@su-ai

I have an uncomfortable feeling about the printer generating complex
function calls with #. as a way to print something.  I'm not really
sure why it bothers me so much.

Should we also adopt the convention that arrays which can't be printed
with #A for other reasons will be printed with #.  Such things as
fill pointers, adjustability, displacement, etc. can't be represented
with #A.  If we do this, then the printed representation is not
suitable for the :INITIAL-CONTENTS options, since that option won't
take an array.  If we don't do this, the printer is really lying about
the array.

- Paul

∂12-Jun-85  0630	greek@DEC-HUDSON 	Adjusting Displaced Arrays 
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 12 Jun 85  06:30:17 PDT
Date: Wed, 12 Jun 85 09:29:57 EDT
From: greek@DEC-HUDSON
Subject: Adjusting Displaced Arrays
To: common-lisp@su-ai

I'll accept the hair of allowing arbitrary "nesting" of displaced arrays,
but I don't have to like it.

Unless I missed a message, I still don't understand some things.

1.  CLtL says that if the :DISPLACED-TO option is specified on ADJUST-ARRAY
    then none of the original contents of the array appears in the new
    array.  I presume, of course, that this is not the case when displacing
    back to the original target array, which I have to explicitly request
    according to the first paragraph on page 298.

2.  Moon stated that adjusting an array never affect the target array.
    Assuming my point #1 is correct, then the target array is affected
    if a) it is specified in the :DISPLACED-TO option, and b) the
    :INITIAL-ELEMENT option is also specified.

    If I'm incorrect here, then I think that implies that the new array
    has to share some element with the original target array and also
    have some of its own!

The reason we chose not to implement adjustable displaced arrays in VAX
LISP was not because we have a religious objection, but because I
didn't understand what to do.  I guess I'd like to see a list of all
the options to ADJUST-ARRAY and what they do to displaced arrays.
We also need to specify any interactions between the options, such
as with :DISPLACED-TO AND :INITIAL-ELEMENT above.

- Paul

∂12-Jun-85  0928	gls@THINK.ARPA 	Adjusting Displaced Arrays   
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 12 Jun 85  09:28:21 PDT
Received: by THINK.ARPA with CHAOS id AA05340; Wed, 12 Jun 85 12:23:04 edt
Date: Wednesday, 12 June 1985, 12:24-EDT
From: Guy Steele <gls@THINK.ARPA>
Subject: Adjusting Displaced Arrays
To: greek@DEC-HUDSON@THINK.ARPA, common-lisp@su-ai
Cc: gls@THINK.ARPA
In-Reply-To: The message of 12 Jun 85 09:29-EDT from greek at DEC-HUDSON at think
Message-Id: <850612122418.1.GLS@UBALDO.ARPA>

    Date: Wed, 12 Jun 85 09:29:57 EDT
    From: greek@DEC-HUDSON@think

    ....

    2.  Moon stated that adjusting an array never affect the target array.
	Assuming my point #1 is correct, then the target array is affected
	if a) it is specified in the :DISPLACED-TO option, and b) the
	:INITIAL-ELEMENT option is also specified.

	If I'm incorrect here, then I think that implies that the new array
	has to share some element with the original target array and also
	have some of its own!

The problem here is vague language in the manual under ADJUST-ARRAY.
Under MAKE-ARRAY, it says in more than one place that :INITIAL-ELEMENT
and :DISPLACED-TO may not be used together.  This restriction should
apply to ADJUST-ARRAY also.  The language under ADJUST-ARRAY is misleading
in a number of respects about how :INITIAL-ELEMENT and :DISPLACED-TO are
handled.

--Guy

∂12-Jun-85  0959	BSG@SCRC-STONY-BROOK.ARPA 	Using #.(MAKE-ARRAY ...
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 12 Jun 85  09:59:23 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252868; Wed 12-Jun-85 12:56:10-EDT
Date: Wed, 12 Jun 85 13:00 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Using #.(MAKE-ARRAY ...
To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 12 Jun 85 08:56-EDT from greek@DEC-HUDSON
Message-ID: <850612130012.9.BSG@CONCORD.SCRC.Symbolics.COM>

    Date: Wed, 12 Jun 85 08:56:25 EDT
    From: greek@DEC-HUDSON

    I have an uncomfortable feeling about the printer generating complex
    function calls with #. as a way to print something.  I'm not really
    sure why it bothers me so much.
Well, for one, if I had some complex network of displaced arrays with
all sorts of hairy attributes, I think it would be as part of
some complicated data structure: an attempt to print them out
in such away that the reader, on reading-back-in, would create
an array "similar to lisp", but in no way part of the data
structure of my program at that time, is wholly bogus and misguided help.
    Should we also adopt the convention that arrays which can't be printed
    with #A for other reasons will be printed with #.  Such things as
    fill pointers, adjustability, displacement, etc. can't be represented
    with #A.  If we do this, then the printed representation is not
    suitable for the :INITIAL-CONTENTS options, since that option won't
    take an array.  If we don't do this, the printer is really lying about
    the array.
By my argument above, the more cases it uses #< (I think that's what you meant)
the better it is, and the fewer times it will lie about arrays.
    - Paul


∂12-Jun-85  1225	greek@DEC-HUDSON 	Printing Arrays with #.    
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 12 Jun 85  12:25:06 PDT
Date: Wed, 12 Jun 85 15:24:48 EDT
From: greek@DEC-HUDSON
Subject: Printing Arrays with #.
To: common-lisp@su-ai

Just to clarify, I really was asking whether all funny arrays should
be printed with #. (not #<>).  I don't like the idea, either for
arrays with zero dimensions or for nonsimple arrays, but I'm not
sure why it bothers me.  I'd rather see those guys printed with #<>.

- Paul

∂12-Jun-85  1312	REM@IMSSS 	Test suite to say what manual is confusing about 
Received: from IMSSS by SU-AI with PUP; 12-Jun-85 13:12 PDT
Date: 12 Jun 1985 1310-PDT
From: Rem@IMSSS
Subject: Test suite to say what manual is confusing about
To:   COMMON-LISP@SU-AI

It seems to me urgent to create a test suite for aspects of CL that are
so complicated that nobody has found a way to explain them so that a
majority of readers would truly understand them. Thus the test suite would
determine whether a given implementation is correct or not, and would serve
as the standard definition until such time as somebody figures out how
to explain it precisely in English.

It also seems that displaced adjustable mumble arrays is a case where
this need for test suite applies. Anybody who thinks he understands what
the manual meant to say, care to volunteer to make a test suite for arrays?
(Anybody agree with my opinion that test suite is needed for such?)
-------

∂12-Jun-85  1339	REM@IMSSS 	Printing of displaced/shared arrays    
Received: from IMSSS by SU-AI with PUP; 12-Jun-85 13:37 PDT
Date: 12 Jun 1985 1334-PDT
From: Rem@IMSSS
Subject: Printing of displaced/shared arrays
To:   COMMON-LISP@SU-AI

It seems to me the "problem" of loss of sharing when you print displaced
arrays and try to read them back in is classical. Normal printing of any
data structure that shares non-atomic parts with itself or anything else,
followed by reading it back in, causes the sharing to be lost. We've
accepted that fact since day one and seeing it crop up with displaced
arrays shouldn't upset us. We should expect that when an array is printed
out all information about its structure (dimensions) and contents (elements)
should be included in the printing, except that information about shared
structure will be lost if the normal printer is used. Some really smart
printer might be able to recognize shared structure and arrange to preserve
it on reading back in, but normally we shouldn't expect such a printer to
be available for all possible cases of sharing that can occur.

If a program has a crazy-quilt of displaced arrays sharing structure,
the programmer shouldn't expect to be able to print out the structure
and later read it back in. But the programmer should be able to expect
to be able to print out the structure for purpose of eyeballing it
during debugging, and not have critical information lost, such as
which axis are of length zero.

Thus the proposal to use #.(MAKE-ARRAY ...) or whatever seems reasonable
in cases where normal print representation loses critical information.
-------

∂12-Jun-85  1353	AS%hp-hulk.csnet@csnet-relay.arpa 	Re: Does Defmacro establish a block?    
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 12 Jun 85  13:53:00 PDT
Received: from hplabs by csnet-relay.csnet id ak28624; 12 Jun 85 16:48 EDT
Received: by HP-VENUS id AA16535; Wed, 12 Jun 85 09:23:17 pdt
Message-Id: <8506121623.AA16535@HP-VENUS>
Date: Wed 12 Jun 85 09:24:07-PDT
From: Alan Snyder <AS%hplabs.csnet@csnet-relay.arpa>
Subject: Re: Does Defmacro establish a block?
To: common-lisp@su-ai.ARPA
In-Reply-To: Message from ""David A. Moon" <Moon@stony-brook.scrc.symbolics.com@HP-VENUS>" of Tue 11 Jun 85 14:32:35-PDT
Source-Info:  From (or Sender) name not authenticated.

  I believe that all defining forms that have a name and a body should put
  a named block around the body.

I fail to see the advantage of all these named blocks being created
implicitly.  Too many implicit definitions can be confusing.  Is it
really too much to ask the programmer to put in an explicit block on
those occasions when he/she wants to do a return from one of these
constructs?  Does it happen that often?  Are there some situations (I
hope not!) where the system can put a block where the programmer cannot
(and where it makes sense to return to)?
-------

∂12-Jun-85  1459	RAM@CMU-CS-C.ARPA 	Does Defmacro establish a block?    
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Jun 85  14:59:13 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 12 Jun 85 17:58:32-EDT
Date: Wed, 12 Jun 1985  17:58 EDT
Message-ID: <RAM.12118632846.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To:   Alan Snyder <AS%hplabs.csnet@CSNET-RELAY.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Does Defmacro establish a block?
In-reply-to: Msg of 12 Jun 1985  12:24-EDT from Alan Snyder <AS%hplabs.csnet at csnet-relay.arpa>


    It is clearly stated in the manual that defun establishes a block
named with the function name.  This is a feature which I use
extensively.  The question is "Which of the other def-mumbles establish
a block as well, and if not why not?"

    Moon's answer is "They all do."  Admittedly returning out of the
body of a deftype will probably not often be useful, but this
definition has the advantage that it is consistent.  This consistency
doesn't cost anything, so we might as well do thing this way.

  Rob

∂12-Jun-85  1704	@MIT-MC.ARPA:BROOKS@MIT-OZ 	declaration pervasiveness. 
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 12 Jun 85  17:04:32 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 12 JUN 85  19:46:52 EDT
Date: Wed 12 Jun 85 19:44:14-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: declaration pervasiveness.
To: common-lisp@SU-AI.ARPA
cc: jk@SU-AI.ARPA

I'm having trouble deciding exactly how pervasive certain declarations
are. For instance:

(defun f (n)
  (flet ((f (m) (* m m)))
    (declare (ftype (function (integer) integer) f))
    (declare (notinline f))
    (+ (f n)
       (flet ((f (m) (bar m m)))
         (f n)))))

By analogy to type it would appear that the ftype declaration applies
to the call to the (* m m) f, but not to the (bar m m) call. There is
specific language in the first paragraph of page 159 that implies
that. However notinline , which has precisely the same language
applied to it at the top of page 160, is earlier singled out has
having nothing to do with bindings and being pervasive on page 155.

So does the notinline apply to the call to the (bar m m) version or
not? If not, then page 155, and the notion of pervasiveness seem
misleading.
-------

∂13-Jun-85  0542	BSG@SCRC-STONY-BROOK.ARPA 	Re: Does Defmacro establish a block?  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Jun 85  05:42:11 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 253452; Thu 13-Jun-85 08:39:18-EDT
Date: Thu, 13 Jun 85 08:43 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Re: Does Defmacro establish a block?
To: AS%hplabs.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <8506121623.AA16535@HP-VENUS>
Message-ID: <850613084351.1.BSG@CONCORD.SCRC.Symbolics.COM>

    Date: Wed 12 Jun 85 09:24:07-PDT
    From: Alan Snyder <AS%hplabs.csnet@csnet-relay.arpa>

      I believe that all defining forms that have a name and a body should put
      a named block around the body.

    I fail to see the advantage of all these named blocks being created
    implicitly.  Too many implicit definitions can be confusing.  
Can you provide an example of how an implicit named block around, say,
a DEFMACRO, will ever confuse anyone, in any case, forced as it may be?

"Why, suppose somebody shouted 'ALAKAZAM00112233MXYZPTLK' by accident!"

∂13-Jun-85  0821	DCP@SCRC-STONY-BROOK.ARPA 	declaration pervasiveness.  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Jun 85  08:21:41 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 253562; Thu 13-Jun-85 11:18:40-EDT
Date: Thu, 13 Jun 85 11:20 EDT
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Subject: declaration pervasiveness.
To: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>, common-lisp@SU-AI.ARPA
cc: jk@SU-AI.ARPA
In-Reply-To: The message of 12 Jun 85 19:44-EDT from Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Message-ID: <850613112008.7.NFEP@NEPONSET.SCRC.Symbolics.COM>

    Date: Wed 12 Jun 85 19:44:14-EDT
    From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>

    I'm having trouble deciding exactly how pervasive certain declarations
    are. For instance:

    (defun f (n)
      (flet ((f (m) (* m m)))
	(declare (ftype (function (integer) integer) f))
	(declare (notinline f))
	(+ (f n)
	   (flet ((f (m) (bar m m)))
	     (f n)))))

    By analogy to type it would appear that the ftype declaration applies
    to the call to the (* m m) f, but not to the (bar m m) call. There is
    specific language in the first paragraph of page 159 that implies
    that. However notinline , which has precisely the same language
    applied to it at the top of page 160, is earlier singled out has
    having nothing to do with bindings and being pervasive on page 155.

    So does the notinline apply to the call to the (bar m m) version or
    not? If not, then page 155, and the notion of pervasiveness seem
    misleading.
    -------

If you follow the language defined in the book, you will find that your
function is illegal.  Declarations are not permitted after FLET, LABELS,
or MACROLET.  A lot of the language in the book seems to assume that
these forms don't exist.

Once you admit their existance, it is clear (to me at least) that
several things follow.  First, FTYPE and [NOT]INLINE declarations should
be able to follow them and second, that these declarations should not be
pervasive.

∂13-Jun-85  0933	FAHLMAN@CMU-CS-C.ARPA 	declaration pervasiveness. 
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 13 Jun 85  09:32:53 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 13 Jun 85 12:32:33-EDT
Date: Thu, 13 Jun 1985  12:32 EDT
Message-ID: <FAHLMAN.12118835652.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To:   "David C. Plummer in disguise" <DCP@SCRC-QUABBIN.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: declaration pervasiveness.
In-reply-to: Msg of 13 Jun 1985  11:20-EDT from David C. Plummer in disguise <DCP at SCRC-QUABBIN.ARPA>


    If you follow the language defined in the book, you will find that your
    function is illegal.  Declarations are not permitted after FLET, LABELS,
    or MACROLET.  A lot of the language in the book seems to assume that
    these forms don't exist.

    Once you admit their existance, it is clear (to me at least) that
    several things follow.  First, FTYPE and [NOT]INLINE declarations should
    be able to follow them and second, that these declarations should not be
    pervasive.

This seems to me like the only sensible interpretation, even if the
language in the book is contradictory.  What we have here is a very
strong analogy with variable-binding forms, and we need similar
machinery for declaring things about a particular lexical binding of a
function name.  Obviously the language about declarations in the book
was written before we had really faced up to the existence of lexically
scoped function definitions.

I'm not so sure about MACROLET, however.  It's not clear that FTYPE and
INLINE make any sense here.

-- Scott

∂13-Jun-85  0935	@MIT-MC.ARPA:BROOKS@MIT-OZ 	Re: declaration pervasiveness.  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Jun 85  09:35:35 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 13 JUN 85  12:34:49 EDT
Date: Thu 13 Jun 85 12:32:11-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: Re: declaration pervasiveness.
To: DCP@SCRC-QUABBIN.ARPA, common-lisp@SU-AI.ARPA
cc: jk@SU-AI.ARPA
In-Reply-To: Message from "David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>" of Thu 13 Jun 85 11:23:12-EDT

    From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
    Subject: declaration pervasiveness.

    If you follow the language defined in the book, you will find that your
    function is illegal.  Declarations are not permitted after FLET, LABELS,
    or MACROLET.  A lot of the language in the book seems to assume that
    these forms don't exist.

?? In my copy of the book (the one from digital press) all of FLET,
LABELS and MACROLET are included in a list at the top of page 154
which claim to be the forms in which declarations can appear at the
beginning of a body. However page 113 does seem to disagree with
this--there the only declarations are in the definition parts of the
functional `variables'.

    Once you admit their existance, it is clear (to me at least) that
    several things follow.  First, FTYPE and [NOT]INLINE declarations should
    be able to follow them and second, that these declarations should not be
    pervasive.

That sounds reasonable to me too. But that's not what page 155
currently says.
-------

∂13-Jun-85  1139	gls@THINK.ARPA 	declaration pervasiveness.   
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 13 Jun 85  11:39:38 PDT
Received: by THINK.ARPA with CHAOS id AA17400; Thu, 13 Jun 85 14:29:45 edt
Date: Thu, 13 Jun 85 14:30 EDT
From: Guy Steele <gls@THINK.ARPA>
Subject: declaration pervasiveness.
To: common-lisp@SU-AI.ARPA
Cc: jk@SU-AI.ARPA, gls@THINK.ARPA
In-Reply-To: Your message of 12 Jun 85 19:44-EDT
Message-Id: <850613143035.1.GLS@YON.ARPA>

    Received: from GODOT by AQUINAS via CHAOS with CHAOS-MAIL; Wed 12-Jun-85 20:08:52-EDT
    Received: from SU-AI.ARPA (su-ai.arpa.ARPA) by THINK.ARPA id AA09914; Wed, 12 Jun 85 20:03:40 edt
    Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 12 Jun 85  17:04:32 PDT
    Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 12 JUN 85  19:46:52 EDT
    Date: Wed 12 Jun 85 19:44:14-EDT
    From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA@think>
    Subject: declaration pervasiveness.
    To: common-lisp@SU-AI.ARPA
    Cc: jk@SU-AI.ARPA

    I'm having trouble deciding exactly how pervasive certain declarations
    are. For instance:

    (defun f (n)
      (flet ((f (m) (* m m)))
	(declare (ftype (function (integer) integer) f))
	(declare (notinline f))
	(+ (f n)
	   (flet ((f (m) (bar m m)))