perm filename COMMON.6[COM,LSP] blob sn#810559 filedate 1986-02-12 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00659 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00087 00002	
C00088 00003	∂15-Sep-85  1441	MMcM@SCRC-STONY-BROOK.ARPA 	LAMBDA expression to the SATISFIES type specifier   
C00091 00004	∂16-Sep-85  1115	RAM@C.CS.CMU.EDU 	structure equality in slisp
C00094 00005	∂16-Sep-85  1251	REM%IMSSS.#Pup@SU-SCORE.ARPA 	EQUAL isn't really correct, I agree
C00098 00006	∂16-Sep-85  1456	hplabs!snyder%hplabs.csnet@CSNET-RELAY.ARPA 	compiling anonymous functions 
C00101 00007	∂17-Sep-85  0727	FAHLMAN@C.CS.CMU.EDU 	compiling anonymous functions    
C00108 00008	∂18-Sep-85  0637	gls@THINK-AQUINAS.ARPA 	Franz -> Common Lisp 
C00111 00009	∂18-Sep-85  0805	robbins@DEC-HUDSON 	Modification to LISTEN   
C00113 00010	∂18-Sep-85  0956	FAHLMAN@C.CS.CMU.EDU 	Modification to LISTEN 
C00115 00011	∂18-Sep-85  1251	robbins@DEC-HUDSON 	Concatenated Stream Query
C00117 00012	∂18-Sep-85  1311	FAHLMAN@C.CS.CMU.EDU 	Concatenated Stream Query   
C00119 00013	∂18-Sep-85  1318	@MIT-REAGAN.ARPA:Soley@MIT-MC.ARPA 	Concatenated Stream Query    
C00122 00014	∂18-Sep-85  1415	gls@THINK-AQUINAS.ARPA 	Concatenated Stream Query 
C00124 00015	∂18-Sep-85  1516	wagner@GSWD-VMS 	Erratum 
C00125 00016	∂18-Sep-85  1822	MMcM@SCRC-STONY-BROOK.ARPA 	Modification to LISTEN
C00128 00017	∂19-Sep-85  0702	gls@THINK-AQUINAS.ARPA 	Erratum    
C00130 00018	∂19-Sep-85  1626	MLY%MIT-OZ@MIT-MC.ARPA 	Returning additional values from advertised functions   
C00134 00019	∂19-Sep-85  1758	bobrow.pa@Xerox.ARPA 	Arguments and values to get.
C00136 00020	∂19-Sep-85  1819	FAHLMAN@C.CS.CMU.EDU 	Arguments and values to get.
C00139 00021	∂20-Sep-85  0649	sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA 	Erratum on p.107Subject:     
C00141 00022	∂20-Sep-85  0651	sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA 	erratum: logic error on p.125
C00143 00023	∂20-Sep-85  0709	KMP@SCRC-STONY-BROOK.ARPA 	Arguments and values to get.
C00147 00024	∂20-Sep-85  0737	DLW@SCRC-STONY-BROOK.ARPA 	erratum: logic error on p.125    
C00150 00025	∂20-Sep-85  0741	DLW@SCRC-STONY-BROOK.ARPA 	Erratum on p.107Subject:    
C00153 00026	∂20-Sep-85  1215	gls@THINK-AQUINAS.ARPA 	Erratum on p.107Subject:  
C00156 00027	∂20-Sep-85  1219	gls@THINK-AQUINAS.ARPA 	erratum: logic error on p.125  
C00159 00028	∂20-Sep-85  1221	gls@THINK-AQUINAS.ARPA 	erratum: logic error on p.125  
C00161 00029	∂20-Sep-85  1348	mips!escargot.earl@glacier 	Arguments and values to get.    
C00163 00030	∂20-Sep-85  1702	FAHLMAN@C.CS.CMU.EDU 	EQUAL isn't really correct, I agree   
C00166 00031	∂20-Sep-85  2312	GSB@MIT-MC.ARPA 	Modification to LISTEN 
C00168 00032	∂21-Sep-85  0729	robbins@DEC-HUDSON 	LISTEN Proposal
C00170 00033	∂21-Sep-85  1350	edsel!jim@su-navajo.arpa 	listen, etc.  
C00175 00034	∂22-Sep-85  1814	GJC@MIT-MC.ARPA 	Lisp Test    
C00177 00035	∂22-Sep-85  1846	FAHLMAN@C.CS.CMU.EDU 	Lisp Test    
C00179 00036	∂22-Sep-85  1848	FAHLMAN@C.CS.CMU.EDU 	Lisp Test -- oops!
C00181 00037	∂23-Sep-85  1131	DDYER@SCRC-QUABBIN.ARPA 	Lisp Test 
C00184 00038	∂23-Sep-85  1425	gls@THINK-AQUINAS.ARPA 	Public relations: second time around
C00189 00039	∂24-Sep-85  2129	RPG  	Meeting  
C00193 00040	∂24-Sep-85  2359	TIM@MIT-MC.ARPA 	Lisp Test    
C00195 00041	∂25-Sep-85  0946	KESSLER@UTAH-20.ARPA 	Argument Type Mismatch Errors    
C00198 00042	∂25-Sep-85  1132	smh@mit-ems.ARPA 	Re:  Argument Type Mismatch Errors   
C00201 00043	∂25-Sep-85  1153	smh@mit-ems.ARPA 	missing function: typep-type-p  
C00204 00044	∂25-Sep-85  1438	gls@THINK-AQUINAS.ARPA 	Public relations: data so far  
C00216 00045	∂25-Sep-85  1535	JAR@MIT-MC.ARPA 	Public relations: data so far    
C00218 00046	∂25-Sep-85  1844	Moon@SCRC-STONY-BROOK.ARPA 	Lisp Test   
C00220 00047	∂25-Sep-85  1845	Moon@SCRC-STONY-BROOK.ARPA 	Returning additional values from advertised functions    
C00222 00048	∂25-Sep-85  1901	Moon@SCRC-STONY-BROOK.ARPA 	go and return-from inside unwind-protect cleanup    
C00225 00049	∂25-Sep-85  1914	RAM@C.CS.CMU.EDU 	Discouraged programming practices    
C00227 00050	∂26-Sep-85  0100	STEINER@BLUE.RUTGERS.EDU 	More corrections to CLtL
C00229 00051	∂26-Sep-85  0404	smh@mit-ems.ARPA 	CLtL ambiguity in trace    
C00231 00052	∂26-Sep-85  0432	bs%hp-mars.csnet@CSNET-RELAY.ARPA 	disassemble and compile questions  
C00235 00053	∂26-Sep-85  0501	smh@mit-ems.ARPA 	CLtL error re function special form  
C00238 00054	∂26-Sep-85  0728	gls@THINK-AQUINAS.ARPA 	Joke  
C00240 00055	∂26-Sep-85  0744	AS%hp-hulk.csnet@CSNET-RELAY.ARPA 	Re: missing function: typep-type-p 
C00242 00056	∂26-Sep-85  0748	gls@THINK-AQUINAS.ARPA 	go and return-from inside unwind-protect cleanup   
C00246 00057	∂26-Sep-85  0751	gls@THINK-AQUINAS.ARPA 	Discouraged programming practices   
C00248 00058	∂26-Sep-85  0758	gls@THINK-AQUINAS.ARPA 	More corrections to CLtL  
C00252 00059	∂26-Sep-85  0806	gls@THINK-AQUINAS.ARPA 	CLtL error re function special form 
C00257 00060	∂26-Sep-85  0954	gls@THINK-AQUINAS.ARPA 	Infinite optimization
C00261 00061	∂26-Sep-85  1250	DDYER@SCRC-QUABBIN.ARPA 	Infinite optimization    
C00264 00062	∂26-Sep-85  1455	Moon@SCRC-STONY-BROOK.ARPA 	go and return-from inside unwind-protect cleanup    
C00266 00063	∂26-Sep-85  1516	Moon@SCRC-STONY-BROOK.ARPA 	disassemble and compile questions    
C00272 00064	∂27-Sep-85  1512	FAHLMAN@C.CS.CMU.EDU 	Argument Type Mismatch Errors    
C00275 00065	∂30-Sep-85  1724	bs%hp-mars.csnet@CSNET-RELAY.ARPA 	Re: disassemble and compile questions   
C00279 00066	∂30-Sep-85  1734	FAHLMAN@C.CS.CMU.EDU 	disassemble and compile questions
C00281 00067	∂30-Sep-85  1948	GJC@MIT-MC.ARPA 	go and return-from inside unwind-protect cleanup
C00283 00068	∂01-Oct-85  1022	gray@GSWD-VMS 	UNIX terminal io incompatibility   
C00286 00069	∂01-Oct-85  1106	ANDY@SU-SUSHI.ARPA 	Re: UNIX terminal io incompatibility    
C00288 00070	∂01-Oct-85  1148	DLW@SCRC-STONY-BROOK.ARPA 	Re: disassemble and compile questions 
C00292 00071	∂01-Oct-85  1545	GJC@MIT-MC.ARPA 	UNIX terminal io incompatibility 
C00294 00072	∂01-Oct-85  2333	STEINER@RED.RUTGERS.EDU 	Another printing bug in CLtL  
C00296 00073	∂02-Oct-85  0808	gls@THINK-AQUINAS.ARPA 	Another printing bug in CLtL   
C00298 00074	∂02-Oct-85  1505	mips!escargot.earl@glacier 	Another printing bug in CLtL    
C00300 00075	∂02-Oct-85  1800	@MIT-MC.ARPA:uucp@MIT-CCC
C00304 00076	∂03-Oct-85  1436	DCP@SCRC-QUABBIN.ARPA 	Arguments and values to get.    
C00306 00077	∂03-Oct-85  1451	DCP@SCRC-QUABBIN.ARPA 	Discouraged programming practices    
C00309 00078	∂03-Oct-85  1507	wagner@GSWD-VMS 	CLtL binding 
C00310 00079	∂03-Oct-85  1910	RAM@C.CS.CMU.EDU 	Without-Interrupts    
C00314 00080	∂04-Oct-85  1548	DLW@SCRC-STONY-BROOK.ARPA 	implicit blocks   
C00317 00081	∂07-Oct-85  1054	RPG  
C00323 00082	∂08-Oct-85  0917	OLDMAN@USC-ISI.ARPA 	UNIX terminal io incompatibility  
C00325 00083	∂09-Oct-85  1018	RPG  	Response to CL Meeting Announcement    
C00326 00084	∂10-Oct-85  0528	GJC@MIT-MC.ARPA 	Response to CL Meeting Announcement        
C00327 00085	∂10-Oct-85  1708	isrlist@tove.umd.edu
C00328 00086	∂10-Oct-85  1726	SCHUMACHER%hp-hulk.csnet@CSNET-RELAY.ARPA 	pathnames.  
C00330 00087	∂10-Oct-85  1739	DCP@SCRC-STONY-BROOK.ARPA 	pathnames.   
C00332 00088	∂11-Oct-85  0748	wagner@GSWD-VMS 	oversight?   
C00333 00089	∂11-Oct-85  1242	Moon@SCRC-STONY-BROOK.ARPA 	oversight?  
C00336 00090	∂11-Oct-85  1549	hplabs!schumacher%hplabs.csnet@CSNET-RELAY.ARPA 	Re: pathnames.  
C00339 00091	∂11-Oct-85  2025	Moon@SCRC-STONY-BROOK.ARPA 	Re: pathnames.   
C00344 00092	∂15-Oct-85  1119	RLB@SCRC-STONY-BROOK.ARPA 	Re: pathnames.    
C00349 00093	∂15-Oct-85  1247	RWK@SCRC-STONY-BROOK.ARPA 	Re: pathnames.    
C00351 00094	∂15-Oct-85  1520	GSB@MIT-MC.ARPA 	SETF of pathname components 
C00353 00095	∂22-Oct-85  1546	greek@DEC-HUDSON 	WITHOUT-INTERRUPTS    
C00354 00096	∂22-Oct-85  1554	gls@THINK-AQUINAS.ARPA 	Report on trip to Japan   
C00358 00097	∂22-Oct-85  1908	gls@THINK-AQUINAS.ARPA 	Report on trip to Japan   
C00362 00098	∂23-Oct-85  0723	BSG@SCRC-YUKON.ARPA 	WITHOUT-INTERRUPTS 
C00365 00099	∂23-Oct-85  0822	greek@DEC-HUDSON 	WITHOUT-INTERRUPTS    
C00367 00100	∂23-Oct-85  0947	BSG@SCRC-STONY-BROOK.ARPA 	WITHOUT-INTERRUPTS
C00371 00101	∂23-Oct-85  1023	greek@DEC-HUDSON 	WITHOUT-INTERRUPTS    
C00373 00102	∂23-Oct-85  1030	Moon@SCRC-STONY-BROOK.ARPA 	WITHOUT-INTERRUPTS    
C00377 00103	∂23-Oct-85  1110	Moon@SCRC-STONY-BROOK.ARPA 	WITHOUT-INTERRUPTS    
C00380 00104	∂23-Oct-85  1258	greek@DEC-HUDSON 	WITHOUT-INTERRUPTS    
C00382 00105	∂24-Oct-85  1036	gls@THINK-AQUINAS.ARPA 	WITHOUT-INTERRUPTS: my last message 
C00385 00106	∂24-Oct-85  1042	GJC@MIT-MC.ARPA 	WITHOUT-INTERRUPTS
C00388 00107	∂25-Oct-85  1337	RPG  	Meeting  
C00389 00108	∂26-Oct-85  1315	RPG  	Tentative Schedule for the Common Lisp Meeting   
C00390 00109	∂28-Oct-85  0855	masinter.pa@Xerox.ARPA 	Re: Tentative Schedule for the Common Lisp Meeting      
C00391 00110	∂28-Oct-85  1233	OLDMAN@USC-ISI.ARPA 	Uniqueness of &rest arguments
C00393 00111	∂28-Oct-85  1445	gls@THINK-AQUINAS.ARPA 	Uniqueness of &rest arguments  
C00396 00112	∂28-Oct-85  1711	Moon@SCRC-STONY-BROOK.ARPA 	Uniqueness of &rest arguments   
C00400 00113	∂28-Oct-85  1715	Moon@SCRC-STONY-BROOK.ARPA 	Tentative Schedule for the Common Lisp Meeting      
C00402 00114	∂29-Oct-85  1649	hoey@nrl-aic 	Default scope of references    
C00407 00115	∂30-Oct-85  0545	jeff%aiva.edinburgh.ac.uk@ucl-cs.ARPA 	Re:  Tentative Schedule for the Common Lisp Meeting
C00410 00116	∂30-Oct-85  0632	GJC@MIT-MC.ARPA 	Default scope of references 
C00413 00117	∂30-Oct-85  1013	JAR@MIT-MC.ARPA 	absence of (declare (unspecial ...))  
C00414 00118	∂30-Oct-85  1142	DLW@SCRC-STONY-BROOK.ARPA 	Default scope of references 
C00416 00119	∂30-Oct-85  1225	RWK@SCRC-YUKON.ARPA 	Default scope of references  
C00421 00120	∂31-Oct-85  0847	MLY@MIT-MC.ARPA 	free variable references in interpreter.   
C00425 00121	∂31-Oct-85  0947	FAHLMAN@C.CS.CMU.EDU 	free variable references in interpreter.   
C00428 00122	∂31-Oct-85  1551	GJC@MIT-MC.ARPA 	free variable references in interpreter.   
C00433 00123	∂31-Oct-85  1820	FAHLMAN@C.CS.CMU.EDU 	free variable references in interpreter.   
C00438 00124	∂31-Oct-85  1858	GSB@MIT-MC.ARPA 	free variable references in interpreter.   
C00442 00125	∂01-Nov-85  0846	gls@THINK-AQUINAS.ARPA 	free variable references in interpreter. 
C00448 00126	∂01-Nov-85  1136	FAHLMAN@C.CS.CMU.EDU 	free variable references in interpreter.   
C00455 00127	∂01-Nov-85  1242	shebs%utah-orion@utah-cs.arpa 	Declaring Functions
C00458 00128	∂01-Nov-85  1529	DCP@SCRC-STONY-BROOK.ARPA 	free variable references in interpreter.   
C00462 00129	∂01-Nov-85  1721	FAHLMAN@C.CS.CMU.EDU 	free variable references in interpreter.   
C00465 00130	∂02-Nov-85  2052	isrlist@tove.umd.edu 	defvar, defparameter, :unbound   
C00467 00131	∂03-Nov-85  0510	GJC@MIT-MC.ARPA 	extra features/values  
C00468 00132	∂03-Nov-85  0719	SOLEY@MIT-MC.ARPA 	defvar, defparameter, :unbound 
C00470 00133	∂03-Nov-85  0724	SOLEY@MIT-MC.ARPA 	extra features/values
C00473 00134	∂04-Nov-85  0846	DCP@SCRC-QUABBIN.ARPA 	free variable references in interpreter.  
C00477 00135	∂04-Nov-85  1022	@MIT-MC.ARPA:Soley@MIT-MC.ARPA 	free variable references in interpreter.   
C00480 00136	∂04-Nov-85  1022	@MIT-MC.ARPA:Soley@MIT-MC.ARPA 	free variable references in interpreter.   
C00483 00137	∂04-Nov-85  1240	DLW@SCRC-STONY-BROOK.ARPA 	defvar, defparameter, :unbound   
C00485 00138	∂04-Nov-85  1447	AS%hp-hulk.csnet@CSNET-RELAY.ARPA 	functions that return nonstandard extra values    
C00487 00139	∂04-Nov-85  1500	hplabs!perdue%hplabs.csnet@CSNET-RELAY.ARPA 	Re: free variable references in interpreter. 
C00489 00140	∂04-Nov-85  1703	DCP@SCRC-STONY-BROOK.ARPA 	functions that return nonstandard extra values  
C00492 00141	∂04-Nov-85  1858	GJC@MIT-MC.ARPA 	functions that return nonstandard extra values  
C00494 00142	∂04-Nov-85  1925	DLW@SCRC-STONY-BROOK.ARPA 	Declaring Functions    
C00497 00143	∂04-Nov-85  1934	DLW@SCRC-STONY-BROOK.ARPA 	functions that return nonstandard extra values  
C00499 00144	∂04-Nov-85  2019	GSB@MIT-MC.ARPA 	defvar, defparameter, :unbound   
C00501 00145	∂05-Nov-85  0734	DCP@SCRC-STONY-BROOK.ARPA 	functions that return nonstandard extra values  
C00504 00146	∂05-Nov-85  0941	gls@THINK-AQUINAS.ARPA 	functions that return nonstandard extra values
C00507 00147	∂05-Nov-85  0950	gls@THINK-AQUINAS.ARPA 	defvar, defparameter, :unbound 
C00511 00148	∂05-Nov-85  1154	isrlist@tove.umd.edu 	defvar, defparameter, :unbound   
C00513 00149	∂05-Nov-85  1213	LOOSEMORE@UTAH-20.ARPA 	queries about *query-io*  
C00515 00150	∂05-Nov-85  1239	DCP@SCRC-STONY-BROOK.ARPA 	defvar, defparameter, :unbound   
C00519 00151	∂05-Nov-85  1517	HENRIK@MIT-MC.ARPA 	queries about *query-io* 
C00522 00152	∂05-Nov-85  1655	LOOSEMORE@UTAH-20.ARPA 	Re: queries about *query-io*   
C00524 00153	∂06-Nov-85  0400	GJC@MIT-MC.ARPA 	(GETHASH X Y)  ==> (CDR (GETHASH X Y))
C00526 00154	∂06-Nov-85  0429	GJC@MIT-MC.ARPA 	functions that return nonstandard extra values  
C00530 00155	∂06-Nov-85  0738	MEEHAN@YALE.ARPA 	CL erratissimo   
C00531 00156	∂06-Nov-85  0904	mips!escargot.earl@glacier 	defvar, defparameter, :unbound  
C00533 00157	∂06-Nov-85  0947	gls@THINK-AQUINAS.ARPA 	CL erratissimo  
C00535 00158	∂08-Nov-85  1646	FAHLMAN@C.CS.CMU.EDU 	astronaut  example on p.313      
C00537 00159	∂08-Nov-85  1648	FAHLMAN@C.CS.CMU.EDU 	Language spec should be public domain 
C00539 00160	∂08-Nov-85  1649	gls@THINK-AQUINAS.ARPA 	Common Lisp manual online?
C00541 00161	∂08-Nov-85  1651	gls@THINK-AQUINAS.ARPA 	astronaut  example on p.313    
C00544 00162	∂08-Nov-85  1705	hplabs!snyder%hplabs.csnet@CSNET-RELAY.ARPA 	compiler-let (clarification needed)
C00547 00163	∂08-Nov-85  2244	PGS%MIT-OZ@MIT-MC.ARPA 	astronaut  example on p.313    
C00550 00164	∂09-Nov-85  1115	DLW@SCRC-STONY-BROOK.ARPA 	Suggested addition to the index of CLtL    
C00552 00165	∂09-Nov-85  1606	RPG  	Meeting: The Details    
C00558 00166	Common-lisp/su
C00561 00167	∂10-Nov-85  1828	EVAN@SU-CSLI.ARPA 	Pointers to vax/unix version   
C00563 00168	∂11-Nov-85  0944	Kahn.pa@Xerox.ARPA 	RE: Steele's programming style
C00565 00169	∂18-Nov-85  1331	gls@THINK-AQUINAS.ARPA 	TYPEP and arrays of (SATISFIES F)   
C00568 00170	∂19-Nov-85  0056	RAM@C.CS.CMU.EDU 	:Structure-Print and *print-level*   
C00570 00171	∂19-Nov-85  1346	KESSLER@UTAH-20.ARPA 	Universal Catch   
C00572 00172	∂19-Nov-85  1645	REM@IMSSS 	CATCH-ALL
C00574 00173	∂19-Nov-85  1657	RWK@SCRC-YUKON.ARPA 	Universal Catch    
C00577 00174	∂19-Nov-85  1739	kessler%utah-orion@utah-cs.arpa 	Re:  Universal Catch  
C00579 00175	∂19-Nov-85  1925	GSB@MIT-MC.ARPA 	catching
C00582 00176	∂19-Nov-85  1941	@MIT-MC.ARPA:BROOKS@MIT-OZ 	Re:  Universal Catch  
C00585 00177	∂20-Nov-85  0050	sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA 	Extra paren in example on p.430   
C00587 00178	∂20-Nov-85  0911	gls@THINK-AQUINAS.ARPA 	Extra paren in example on p.430
C00589 00179	∂20-Nov-85  1139	gls@THINK-AQUINAS.ARPA 	Extra paren in example on p.430
C00591 00180	∂20-Nov-85  1148	BSG@SCRC-STONY-BROOK.ARPA 	CATCH-ALL    
C00594 00181	∂20-Nov-85  1417	Moon@SCRC-QUABBIN.ARPA 	Fill-pointers and sequences    
C00597 00182	∂20-Nov-85  1428	Moon@SCRC-QUABBIN.ARPA 	Universal Catch 
C00600 00183	∂20-Nov-85  1429	Moon@SCRC-QUABBIN.ARPA 	CATCH-ALL  
C00602 00184	∂20-Nov-85  1432	Moon@SCRC-QUABBIN.ARPA 	CATCH-ALL  
C00604 00185	∂20-Nov-85  1729	FAHLMAN@C.CS.CMU.EDU 	Fill-pointers and sequences 
C00608 00186	∂21-Nov-85  0702	FAHLMAN@C.CS.CMU.EDU 	:Structure-Print and *print-level*    
C00613 00187	∂21-Nov-85  0741	gls@THINK-AQUINAS.ARPA 	Fill-pointers and sequences    
C00617 00188	∂21-Nov-85  0844	gls@THINK-AQUINAS.ARPA 	Fill-pointers and sequences    
C00621 00189	∂21-Nov-85  0846	gls@THINK-AQUINAS.ARPA 	:Structure-Print and *print-level*  
C00624 00190	∂21-Nov-85  1030	greek%bach.decnet@hudson.dec.com 	Recursive print & depth abbreviation
C00628 00191	∂21-Nov-85  1214	hoey@nrl-aic 	Re: :Structure-Print and *print-level*   
C00632 00192	∂21-Nov-85  1313	greek%bach.decnet@hudson.dec.com 	Recursive printing.  
C00634 00193	∂21-Nov-85  1324	FAHLMAN@C.CS.CMU.EDU 	:Structure-Print and *print-level*    
C00636 00194	∂21-Nov-85  1402	greek%bach.decnet@hudson.dec.com 	Recursive printing.  
C00637 00195	∂21-Nov-85  1703	hoey@nrl-aic 	Re: Recursive printing.   
C00641 00196	∂21-Nov-85  1913	robbins%bach.decnet@hudson.dec.com 	Recursive printing.
C00645 00197	∂22-Nov-85  0738	DLW@SCRC-STONY-BROOK.ARPA 	adjust-array with :initial-elements and fill pointers
C00648 00198	∂22-Nov-85  0826	greek%bach.decnet@hudson.dec.com 	Apology for our brain-damaged mailer.    
C00650 00199	∂22-Nov-85  0856	KMP@SCRC-STONY-BROOK.ARPA 	adjust-array with :initial-elements and fill pointers
C00655 00200	∂22-Nov-85  0938	robbins%bach.decnet@hudson.dec.com 	Recursive printing proposal  
C00657 00201	∂22-Nov-85  1015	RPG  	Reminder about the Common Lisp Meeting 
C00660 00202	∂22-Nov-85  1106	robbins%bach.decnet@hudson.dec.com 	LET-IF   
C00661 00203	∂22-Nov-85  1127	FAHLMAN@C.CS.CMU.EDU 	Recursive printing proposal 
C00663 00204	∂22-Nov-85  1156	greek%bach.decnet@hudson.dec.com 	TOP-LEVEL-PRINT macro.    
C00665 00205	∂22-Nov-85  1143	FAHLMAN@C.CS.CMU.EDU 	LET-IF  
C00667 00206	∂22-Nov-85  1208	DLW@SCRC-STONY-BROOK.ARPA 	adjust-array with :initial-elements and fill pointers
C00671 00207	∂22-Nov-85  1224	Moon@SCRC-STONY-BROOK.ARPA 	LET-IF 
C00674 00208	∂22-Nov-85  1243	Moon@SCRC-STONY-BROOK.ARPA 	:Structure-Print and *print-level*   
C00679 00209	∂22-Nov-85  1249	Moon@SCRC-STONY-BROOK.ARPA 	Fill-pointers and sequences
C00684 00210	∂22-Nov-85  1253	Moon@SCRC-STONY-BROOK.ARPA 	TYPEP and arrays of (SATISFIES F)    
C00689 00211	∂22-Nov-85  1304	greek%bach.decnet@hudson.dec.com 	Common LISP is too big?   
C00691 00212	∂22-Nov-85  1304	robbins%bach.decnet@hudson.dec.com 	LET-IF   
C00694 00213	∂22-Nov-85  1305	KMP@SCRC-STONY-BROOK.ARPA 	Recursive printing proposal 
C00698 00214	∂22-Nov-85  1321	KMP@SCRC-STONY-BROOK.ARPA 	adjust-array with :initial-elements and fill pointers
C00703 00215	∂22-Nov-85  1328	FAHLMAN@C.CS.CMU.EDU 	Fill-pointers and sequences 
C00707 00216	∂22-Nov-85  1331	FAHLMAN@C.CS.CMU.EDU 	LET-IF  
C00709 00217	∂22-Nov-85  1352	FAHLMAN@C.CS.CMU.EDU 	Recursive printing proposal 
C00711 00218	∂22-Nov-85  1419	greek%bach.decnet@hudson.dec.com 	Sigh on recursive printing.    
C00713 00219	∂22-Nov-85  1430	FAHLMAN@C.CS.CMU.EDU 	LET-IF  
C00717 00220	∂22-Nov-85  1515	JAR@MIT-MC.ARPA 	LET-IF  
C00718 00221	∂22-Nov-85  1636	DLW@SCRC-STONY-BROOK.ARPA 	Sigh on recursive printing. 
C00720 00222	∂22-Nov-85  1722	GJC@MIT-MC.ARPA 	Recursive printing proposal 
C00722 00223	∂22-Nov-85  1733	robbins%bach.decnet@hudson.dec.com 	LET-IF   
C00723 00224	∂22-Nov-85  1743	Moon@SCRC-QUABBIN.ARPA 	Sigh on recursive printing.    
C00725 00225	∂22-Nov-85  1743	GJC@MIT-MC.ARPA 	LET-IF  
C00728 00226	∂23-Nov-85  0913	shebs%utah-orion@utah-cs.arpa 	Misc Queries  
C00731 00227	∂23-Nov-85  1348	DLW@SCRC-STONY-BROOK.ARPA 	Minor typo   
C00733 00228	∂23-Nov-85  1356	Moon@SCRC-STONY-BROOK.ARPA 	Misc Queries
C00739 00229	∂23-Nov-85  1429	FAHLMAN@C.CS.CMU.EDU 	Misc Queries 
C00741 00230	∂23-Nov-85  1628	RPG  	Minor Typo = Major Faux Pas! 
C00742 00231	∂23-Nov-85  1933	mips!escargot.earl@glacier 	Misc Queries
C00745 00232	∂24-Nov-85  0930	shebs%utah-orion@utah-cs.arpa 	Re:  Misc Queries  
C00750 00233	∂24-Nov-85  1500	Moon@SCRC-STONY-BROOK.ARPA 	Re:  Misc Queries
C00753 00234	∂25-Nov-85  0739	gls@THINK-AQUINAS.ARPA 	LET-IF
C00755 00235	∂25-Nov-85  0747	gls@THINK-AQUINAS.ARPA 	Minor typo 
C00757 00236	∂25-Nov-85  0752	gls@THINK-AQUINAS.ARPA 	Minor Typo = Major Faux Pas!   
C00760 00237	∂25-Nov-85  1408	@SCRC-RIVERSIDE.ARPA:rsl@RUSSIAN.SPA.Symbolics.COM 	LET-IF  
C00763 00238	∂25-Nov-85  1547	sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA 	Typos on p.284 and p.324
C00765 00239	∂25-Nov-85  1715	RPG  	New, Improved Agenda    
C00769 00240	∂26-Nov-85  0537	BSG@SCRC-STONY-BROOK.ARPA 	LET-IF  
C00772 00241	∂26-Nov-85  0805	GJC@MIT-MC.ARPA 	Mr Roberts vs Mr Rogers
C00773 00242	∂26-Nov-85  0940	GJC@MIT-MC.ARPA 	Mr Roberts vs Mr Rogers
C00774 00243	∂26-Nov-85  0959	gls@THINK-AQUINAS.ARPA 	LET-IF
C00779 00244	∂26-Nov-85  1128	hplabs!schumacher@hplabs.ARPA 	Amatuer Archivists.
C00781 00245	∂26-Nov-85  1200	gls@THINK-AQUINAS.ARPA 	Amatuer Archivists.  
C00784 00246	∂26-Nov-85  1202	gls@THINK-AQUINAS.ARPA 	Amatuer Archivists (again)
C00786 00247	∂26-Nov-85  1202	KMP@SCRC-STONY-BROOK.ARPA 	DEFSTRUCT and predicates    
C00788 00248	∂26-Nov-85  1224	WHOLEY@C.CS.CMU.EDU 	DEFSTRUCT and predicates
C00791 00249	∂26-Nov-85  1418	NGALL@BBNG.ARPA 	Re: DEFSTRUCT and predicates
C00795 00250	∂26-Nov-85  1528	WHOLEY@C.CS.CMU.EDU 	DEFSTRUCT and predicates
C00798 00251	∂26-Nov-85  2233	TIM@MIT-MC.ARPA 	Amatuer Archivists (again)  
C00801 00252	∂27-Nov-85  1901	mips!escargot.earl@glacier 	lexical scope and dynamic extent
C00803 00253	∂27-Nov-85  2011	BROOKS%MIT-OZ@MIT-MC.ARPA 	Re: lexical scope and dynamic extent  
C00806 00254	∂28-Nov-85  1051	ACUFF@SUMEX-AIM.ARPA 	Re: lexical scope and dynamic extent  
C00808 00255	∂30-Nov-85  1245	RPG  	ANSI/ISO 
C00811 00256	∂30-Nov-85  1257	RPG  	More on the CL meeting  
C00815 00257	∂01-Dec-85  1219	DLW@SCRC-STONY-BROOK.ARPA 	lexical scope and dynamic extent 
C00818 00258	∂01-Dec-85  1645	NGALL@BBNG.ARPA 	Re: DEFSTRUCT and predicates
C00822 00259	∂01-Dec-85  1756	Moon@SCRC-STONY-BROOK.ARPA 	More on the CL meeting     
C00825 00260	∂02-Dec-85  0815	FAHLMAN@C.CS.CMU.EDU 	ANSI/ISO     
C00829 00261	∂02-Dec-85  0822	FAHLMAN@C.CS.CMU.EDU 	More on the CL meeting      
C00831 00262	∂02-Dec-85  0828	DLW@SCRC-STONY-BROOK.ARPA 	More on the CL meeting      
C00835 00263	∂02-Dec-85  1051	FAHLMAN@C.CS.CMU.EDU 	as I was saying...
C00837 00264	∂02-Dec-85  1054	RPG  	ANSI/ISO and Hotel Strike    
C00841 00265	∂02-Dec-85  1135	FAHLMAN@C.CS.CMU.EDU 	ANSI/ISO and Hotel Strike        
C00847 00266	∂02-Dec-85  1153	RPG  	Exposing My Machiavellan Tendencies    
C00850 00267	∂02-Dec-85  1209	FAHLMAN@C.CS.CMU.EDU 	Exposing My Machiavellan Tendencies        
C00853 00268	∂02-Dec-85  1250	DLW@SCRC-QUABBIN.ARPA 	ANSI/ISO    
C00855 00269	∂02-Dec-85  1622	DLW@SCRC-STONY-BROOK.ARPA 	ANSI/ISO
C00860 00270	∂02-Dec-85  1738	Moon@SCRC-STONY-BROOK.ARPA 	Hotel Strike
C00862 00271	∂02-Dec-85  2037	FAHLMAN@C.CS.CMU.EDU 	Charter stuff
C00880 00272	∂03-Dec-85  1706	hplabs!snyder@hplabsd 	manual bug (index)    
C00881 00273	∂03-Dec-85  1719	hplabs!snyder@hplabsd 	keywords    
C00883 00274	∂03-Dec-85  1954	FAHLMAN@C.CS.CMU.EDU 	keywords
C00885 00275	∂03-Dec-85  2030	RPG  	More on Issues
C00888 00276	∂04-Dec-85  0120	TIM@MIT-MC.ARPA 	The variables +, -, *, and /
C00890 00277	∂04-Dec-85  0301	wagner%fang@gswd-vms 	minor index errors
C00891 00278	∂04-Dec-85  0310	smh@mit-ems.ARPA 	Re:  The variables +, -, *, and /    
C00894 00279	∂04-Dec-85  0312	BSG@SCRC-STONY-BROOK.ARPA 	keywords
C00897 00280	∂04-Dec-85  0806	FAHLMAN@C.CS.CMU.EDU 	keywords
C00900 00281	∂04-Dec-85  0814	FAHLMAN@C.CS.CMU.EDU 	The variables +, -, *, and /
C00902 00282	∂04-Dec-85  0833	FAHLMAN@C.CS.CMU.EDU 	More on Issues    
C00907 00283	∂04-Dec-85  0837	@MIT-MC.ARPA:Soley@MIT-MC.ARPA 	The variables +, -, *, and /
C00910 00284	∂04-Dec-85  0844	AS@HP-HULK 	Re: keywords 
C00912 00285	∂04-Dec-85  1006	KMP@SCRC-STONY-BROOK.ARPA 	The variables +, -, *, and /
C00915 00286	∂04-Dec-85  1019	BSG@SCRC-STONY-BROOK.ARPA 	Re: keywords 
C00918 00287	∂04-Dec-85  1109	BSG@SCRC-STONY-BROOK.ARPA 	Re: keywords 
C00921 00288	∂04-Dec-85  1344	MLY@MIT-MC.ARPA 	keywords
C00922 00289	∂05-Dec-85  0023	REM%IMSSS.#Pup@SU-SCORE.ARPA 	Bad to hang properties off keywords to install their semantics   
C00926 00290	∂05-Dec-85  0118	@SU-SCORE.ARPA:DOUG@SU-CSLI.ARPA 	Bad to hang properties off keywords to install their semantics    
C00928 00291	∂05-Dec-85  0135	REM@IMSSS 	Implementation issue? (re proplist on keyword)   
C00931 00292	∂05-Dec-85  0638	@SU-SCORE.ARPA:BSG@SCRC-YUKON.ARPA 	Bad to hang properties off keywords to install their semantics  
C00935 00293	∂05-Dec-85  0841	AS@HP-HULK 	Keywords with cells    
C00937 00294	∂05-Dec-85  1049	LOOSEMORE@UTAH-20.ARPA 	keywords   
C00939 00295	∂05-Dec-85  1101	FAHLMAN@C.CS.CMU.EDU 	Keywords with cells    
C00941 00296	∂05-Dec-85  1649	DLW@SCRC-STONY-BROOK.ARPA 	Charter stuff
C00945 00297	∂05-Dec-85  1728	FAHLMAN@C.CS.CMU.EDU 	ISO
C00951 00298	∂06-Dec-85  0028	TIM@MIT-MC.ARPA 	The variables +, -, *, and /
C00955 00299	∂06-Dec-85  0606	GJC@MIT-MC.ARPA 	macsyma and common-lisp
C00959 00300	∂06-Dec-85  0642	KMP@SCRC-VALLECITO.ARPA 	The variables +, -, *, and /  
C00966 00301	∂06-Dec-85  0702	FAHLMAN@C.CS.CMU.EDU 	The variables +, -, *, and /
C00970 00302	∂06-Dec-85  1223	jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	ISO Standard   
C00973 00303	∂06-Dec-85  1321	FAHLMAN@C.CS.CMU.EDU 	ISO Standard 
C00975 00304	∂06-Dec-85  1916	TIM@MIT-MC.ARPA 	The variables +, -, *, and /
C00977 00305	∂07-Dec-85  0719	FAHLMAN@C.CS.CMU.EDU 	The variables +, -, *, and /
C00981 00306	∂07-Dec-85  1206	RPG  	Legal Issues  
C00983 00307	∂07-Dec-85  1723	REM@IMSSS 	need subset of CL! 
C00986 00308	∂07-Dec-85  2328	masinter.PA@Xerox.ARPA 	packages   
C00988 00309	∂08-Dec-85  0606	FAHLMAN@C.CS.CMU.EDU 	packages
C00990 00310	∂08-Dec-85  1107	DLW@SCRC-STONY-BROOK.ARPA 	need subset of CL!
C00992 00311	∂08-Dec-85  1806	RWK@SCRC-STONY-BROOK.ARPA 	The variables +, -, *, and /
C00996 00312	∂08-Dec-85  1823	MATHIS@USC-ISIF.ARPA 	Re: ISO Standard  
C00997 00313	∂10-Dec-85  1352	hplabs!perdue@hplabsd 	Macrolet index bug    
C00998 00314	∂12-Dec-85  1836	shebs%utah-orion@utah-cs.arpa 	Special Form Question   
C01000 00315	∂13-Dec-85  0705	DLW@SCRC-STONY-BROOK.ARPA 	Special Form Question  
C01003 00316	∂13-Dec-85  0708	NGALL@BBNG.ARPA 	Re: Special Form Question   
C01007 00317	∂13-Dec-85  0744	shebs%utah-orion@utah-cs.arpa 	Re: Special Form Question    
C01010 00318	∂13-Dec-85  0804	FAHLMAN@C.CS.CMU.EDU 	Special Form Question  
C01013 00319	∂13-Dec-85  1022	Moon@SCRC-QUABBIN.ARPA 	Special Form Question
C01017 00320	∂13-Dec-85  1101	NGALL@BBNG.ARPA 	Re: Special Form Question   
C01021 00321	∂13-Dec-85  1109	NGALL@BBNG.ARPA 	Re: Special Form Question   
C01024 00322	∂13-Dec-85  1155	shebs%utah-orion@utah-cs.arpa 	Clarification Comments (long)
C01034 00323	∂13-Dec-85  1215	gls@THINK-AQUINAS.ARPA 	list of proposed changes to Common Lisp  
C01059 00324	∂13-Dec-85  1217	gls@THINK-AQUINAS.ARPA 	Typographical corrections to Common Lisp book 
C01077 00325	∂13-Dec-85  1320	gls@THINK-AQUINAS.ARPA 	Clarification Comments (long)  
C01084 00326	∂13-Dec-85  1401	shebs%utah-orion@utah-cs.arpa 	Re:  Clarification Comments (long)
C01091 00327	∂13-Dec-85  1606	REM%IMSSS.#Pup@SU-SCORE.ARPA 	What about advising special forms? 
C01093 00328	∂13-Dec-85  1703	Moon@SCRC-STONY-BROOK.ARPA 	Re: Special Form Question  
C01095 00329	∂13-Dec-85  1846	FAHLMAN@C.CS.CMU.EDU 	What about advising special forms?    
C01098 00330	∂13-Dec-85  1903	FAHLMAN@C.CS.CMU.EDU 	Re: Special Form Question   
C01102 00331	∂13-Dec-85  2146	RAM@C.CS.CMU.EDU 	list of proposed changes to Common Lisp   
C01111 00332	∂14-Dec-85  1752	edsel!eb@su-navajo.arpa 	Undoing global side-effects   
C01116 00333	∂14-Dec-85  1953	edsel!eb@su-navajo.arpa 	Questions, comments and clarifications on clarifications    
C01122 00334	∂14-Dec-85  1953	edsel!eb@su-navajo.arpa 	More clarifications 
C01125 00335	∂15-Dec-85  1155	RAM@C.CS.CMU.EDU 	Another omission: global lexicals    
C01128 00336	∂15-Dec-85  1322	RPG   	[Richard Acuff <Acuff@SUMEX-AIM.ARPA>: Summary of Common Lisp meeting]   
C01138 00337	∂15-Dec-85  1327	DLW@SCRC-STONY-BROOK.ARPA 	Questions, comments and clarifications on clarifications  
C01146 00338	∂15-Dec-85  1330	DLW@SCRC-STONY-BROOK.ARPA 	Another omission: global lexicals
C01148 00339	∂15-Dec-85  1341	Moon@SCRC-STONY-BROOK.ARPA 	XOR    
C01150 00340	∂15-Dec-85  1350	RAM@C.CS.CMU.EDU 	Another omission: global lexicals    
C01153 00341	∂15-Dec-85  1447	DLW@SCRC-STONY-BROOK.ARPA 	Another omission: global lexicals
C01158 00342	∂15-Dec-85  1447	RAM@C.CS.CMU.EDU 	Another Common Lisp unclarity   
C01162 00343	∂15-Dec-85  1455	REM%IMSSS.#Pup@SU-SCORE.ARPA 	Elegant rule for what to copy 
C01165 00344	∂15-Dec-85  1503	GJC@MIT-MC.ARPA 	Another omission: global lexicals
C01168 00345	∂15-Dec-85  1541	RAM@C.CS.CMU.EDU 	Another omission: global lexicals    
C01170 00346	∂15-Dec-85  1608	RPG   	Name change  
C01173 00347	∂15-Dec-85  1621	RAM@C.CS.CMU.EDU 	Minor package unclarity    
C01175 00348	∂15-Dec-85  1631	RPG  
C01176 00349	∂15-Dec-85  1631	RPG   	Please add `mly-lispm@mit-mc' to cl-error-handling   
C01177 00350	∂15-Dec-85  1659	RAM@C.CS.CMU.EDU 	unclarities: defstruct print functions    
C01179 00351	∂15-Dec-85  1855	JAR@MIT-MC.ARPA 	Another omission: global lexicals
C01188 00352	∂15-Dec-85  1935	RAM@C.CS.CMU.EDU 	list of proposed changes to Common Lisp   
C01193 00353	∂15-Dec-85  2128	RAM@C.CS.CMU.EDU 	Another omission: global lexicals    
C01196 00354	∂15-Dec-85  2134	RAM@C.CS.CMU.EDU 	Another omission: global lexicals    
C01199 00355	∂16-Dec-85  0303	cfry%MIT-OZ@MIT-MC.ARPA 	clarifications 
C01201 00356	∂16-Dec-85  0641	DLW@SCRC-STONY-BROOK.ARPA 	Another omission: global lexicals
C01203 00357	∂16-Dec-85  0657	wagner%fang@gswd-vms 	&ALLOW-OTHER-KEYS 
C01205 00358	∂16-Dec-85  0704	DLW@SCRC-STONY-BROOK.ARPA 	Another omission: global lexicals
C01207 00359	∂16-Dec-85  0935	gls@THINK-AQUINAS.ARPA 	list of proposed changes to Common Lisp  
C01210 00360	∂16-Dec-85  1002	gls@THINK-AQUINAS.ARPA 	Questions, comments and clarifications on clarifications
C01213 00361	∂16-Dec-85  1005	gls@THINK-AQUINAS.ARPA 	XOR   
C01215 00362	∂16-Dec-85  1014	gls@THINK-AQUINAS.ARPA 	Another omission: global lexicals   
C01219 00363	∂16-Dec-85  1032	gls@THINK-AQUINAS.ARPA 	meta corrections to CLtL  
C01221 00364	∂16-Dec-85  1035	gls@THINK-AQUINAS.ARPA 	&ALLOW-OTHER-KEYS    
C01223 00365	∂16-Dec-85  1058	DCP@SCRC-QUABBIN.ARPA 	get-setf-method  
C01225 00366	∂16-Dec-85  1058	DLW@SCRC-QUABBIN.ARPA 	Questions, comments and clarifications on clarifications 
C01228 00367	∂16-Dec-85  1149	DLW@SCRC-QUABBIN.ARPA 	Another omission: global lexicals    
C01232 00368	∂16-Dec-85  1154	RAM@C.CS.CMU.EDU 	list of proposed changes to Common Lisp   
C01235 00369	∂16-Dec-85  1400	masinter.pa@Xerox.ARPA 	Re: Special Form Question 
C01237 00370	∂16-Dec-85  1412	GSB@MIT-MC.ARPA 	get-setf-method   
C01239 00371	∂16-Dec-85  1518	masinter.pa@Xerox.ARPA 	Re: clarifications   
C01241 00372	∂16-Dec-85  1524	DCP@SCRC-STONY-BROOK.ARPA 	XOR
C01244 00373	∂16-Dec-85  1703	mips!escargot.earl@glacier 	Re: Special Form Question  
C01248 00374	∂16-Dec-85  2018	DLW@SCRC-STONY-BROOK.ARPA 	Non-top-level DEFUN    
C01250 00375	∂16-Dec-85  2042	FAHLMAN@C.CS.CMU.EDU 	Non-top-level DEFUN    
C01252 00376	∂17-Dec-85  0808	gls@THINK-AQUINAS.ARPA 	Questions, comments and clarifications on clarifications
C01255 00377	∂17-Dec-85  0911	gls@THINK-AQUINAS.ARPA 	Questions, comments and clarifications on clarifications
C01258 00378	∂17-Dec-85  1026	vanroggen%bizet.decnet@hudson.dec.com 	more comments   
C01265 00379	∂17-Dec-85  1129	edsel!jonl@su-navajo.arpa 	Functions for special operators  
C01272 00380	∂17-Dec-85  1129	edsel!jonl@su-navajo.arpa 	"lexical" globals?
C01287 00381	∂17-Dec-85  1633	KMP@SCRC-STONY-BROOK.ARPA 	XOR
C01293 00382	∂17-Dec-85  2126	KMP@SCRC-STONY-BROOK.ARPA 	XOR
C01299 00383	∂17-Dec-85  2157	JAR@MIT-MC.ARPA 	"lexical" globals?
C01303 00384	∂17-Dec-85  2213	mcvax!delphi.UUCP!beppe@seismo.CSS.GOV 	mailing list   
C01305 00385	∂18-Dec-85  0330	cfry%MIT-OZ@MIT-MC.ARPA 	Re: clarifications  
C01311 00386	∂18-Dec-85  0701	preece%ccvaxa@gswd-vms 	Re: XOR    
C01314 00387	∂18-Dec-85  0842	@MC.LCS.MIT.EDU:RAMBO@AI.AI.MIT.EDU 	recent request for assistance    
C01316 00388	∂18-Dec-85  1153	Gregor.pa@Xerox.ARPA 	what do :copiers do?   
C01318 00389	∂19-Dec-85  0932	gls@THINK-AQUINAS.ARPA 	XOR   
C01321 00390	∂19-Dec-85  0935	gls@THINK-AQUINAS.ARPA 	READ-DELIMTED-LIST and dots    
C01323 00391	∂19-Dec-85  1346	Masinter.pa@Xerox.ARPA 	fonts in CLtL   
C01328 00392	∂19-Dec-85  2051	apollo!dfm@uw-beaver.arpa 	GLS's clarifications list (moderately long)
C01343 00393	∂20-Dec-85  1203	FAHLMAN@C.CS.CMU.EDU 	fonts in CLtL
C01347 00394	∂20-Dec-85  1211	gls@THINK-AQUINAS.ARPA 	GLS's clarifications list (moderately long)   
C01353 00395	∂20-Dec-85  1403	gls@THINK-AQUINAS.ARPA 	Multiple values and &optional  
C01356 00396	∂20-Dec-85  1636	DLW@SCRC-STONY-BROOK.ARPA 	GLS's clarifications list (moderately long)
C01358 00397	∂20-Dec-85  2356	apollo!dfm@uw-beaver.arpa 	Re: Elegant rule for what to copy
C01360 00398	∂21-Dec-85  1724	Moon@SCRC-STONY-BROOK.ARPA 	Multiple values and &optional   
C01361 00399	∂21-Dec-85  1738	NGALL@BBNG.ARPA 	Re: Multiple values and &optional
C01364 00400	∂21-Dec-85  2102	NGALL@BBNG.ARPA 	Re: Multiple values and &optional
C01367 00401	∂23-Dec-85  0030	MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA 	Comments  
C01374 00402	∂23-Dec-85  0756	NGALL@BBNG.ARPA 	Re:  Comments
C01382 00403	∂23-Dec-85  0756	GSB@MC.LCS.MIT.EDU 	xor  
C01384 00404	∂23-Dec-85  0756	FAHLMAN@C.CS.CMU.EDU 	Comments
C01388 00405	∂23-Dec-85  1029	REM%IMSSS.#Pup@SU-SCORE.ARPA 	Ground rules not yet decided???    
C01390 00406	∂23-Dec-85  1323	JAR@MC.LCS.MIT.EDU 	unspecial & global & macrolet 
C01393 00407	∂23-Dec-85  1357	FAHLMAN@C.CS.CMU.EDU 	Ground rules not yet decided???  
C01402 00408	∂23-Dec-85  2058	apollo!dfm@uw-beaver.arpa 	copy (moderately long message)   
C01416 00409	∂23-Dec-85  2058	α@uw-beaver.arpa    
C01417 00410	∂24-Dec-85  1530	gls@THINK-AQUINAS.ARPA 	Reader hacks    
C01419 00411	∂24-Dec-85  1535	gls@THINK-AQUINAS.ARPA 	GLS's clarifications list (moderately long)   
C01421 00412	∂26-Dec-85  0934	Moon@SCRC-STONY-BROOK.ARPA 	Symbols as pathnames  
C01428 00413	∂26-Dec-85  1012	Moon@SCRC-STONY-BROOK.ARPA 	XOR    
C01431 00414	∂26-Dec-85  1028	gls@THINK-AQUINAS.ARPA 	Comments   
C01435 00415	∂26-Dec-85  1054	Moon@SCRC-STONY-BROOK.ARPA 	Reader hacks
C01438 00416	∂26-Dec-85  1139	Bobrow.pa@Xerox.ARPA 	Re: copy     
C01440 00417	∂26-Dec-85  1240	LOOSEMORE@UTAH-20.ARPA 	BOA constructor questions 
C01442 00418	∂26-Dec-85  1309	gls@THINK-AQUINAS.ARPA 	BOA constructor questions 
C01446 00419	∂26-Dec-85  1342	GSB@MC.LCS.MIT.EDU 	Reader hacks   
C01450 00420	∂26-Dec-85  1628	REM%IMSSS.#Pup@SU-SCORE.ARPA 	COPY and COPY-IN    
C01452 00421	∂26-Dec-85  1706	@SU-SCORE.ARPA:Bobrow.pa@Xerox.ARPA 	Re: COPY and COPY-IN   
C01455 00422	∂26-Dec-85  1959	Moon@SCRC-STONY-BROOK.ARPA 	XOR    
C01459 00423	∂26-Dec-85  2000	Moon@SCRC-STONY-BROOK.ARPA 	RE: Symbols as pathnames   
C01462 00424	∂27-Dec-85  0320	cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	GLS's clarifications list (moderately long)  
C01464 00425	∂27-Dec-85  0530	GJC@MC.LCS.MIT.EDU 	Reader hacks   
C01466 00426	∂27-Dec-85  1054	LOOSEMORE@UTAH-20.ARPA 	Another inconsistency in CLtL  
C01468 00427	∂28-Dec-85  1509	Moon@SCRC-YUKON.ARPA 	BOA constructor questions   
C01473 00428	∂28-Dec-85  1533	edsel!eb@su-navajo.arpa 	Tail recursive Common Lisp interpreter? 
C01477 00429	∂28-Dec-85  1636	GJC@MC.LCS.MIT.EDU 	Tail recursive Common Lisp interpreter? 
C01480 00430	∂29-Dec-85  1415	DCP@SCRC-STONY-BROOK.ARPA 	Multiple values and &optional    
C01482 00431	∂29-Dec-85  1524	NGALL@BBNG.ARPA 	Re: Reader hacks  
C01485 00432	∂30-Dec-85  0237	REM@IMSSS 	Retry, IMSSS->SCORE mail down a few days Flush implicit catch frames
C01489 00433	∂30-Dec-85  0601	GJC@MC.LCS.MIT.EDU 	tail recursion in CL interpreters. 
C01491 00434	∂30-Dec-85  0832	gls@THINK-AQUINAS.ARPA 	BOA constructor questions 
C01496 00435	∂30-Dec-85  1231	JAR@MC.LCS.MIT.EDU 	Retry, IMSSS->SCORE mail down a few days Flush implicit catch frames 
C01500 00436	∂30-Dec-85  1247	REM%IMSSS.#Pup@SU-SCORE.ARPA 	Reader hacks, whitespace algorithm 
C01502 00437	∂02-Jan-86  1022	GSB@MC.LCS.MIT.EDU 	Re: Reader hacks    
C01504 00438	∂03-Jan-86  0050	cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	Re: Reader hacks    
C01507 00439	∂03-Jan-86  0818	REM%IMSSS.#Pup@SU-SCORE.ARPA 	Reader hacks, whitespace algorithm 
C01509 00440	∂03-Jan-86  0917	LOOSEMORE@UTAH-20.ARPA 	yet another typo in the manual 
C01510 00441	∂04-Jan-86  1905	@SU-SCORE.ARPA:GSB@MC.LCS.MIT.EDU 	Reader hacks, whitespace algorithm 
C01512 00442	∂05-Jan-86  1523	shebs%utah-orion@utah-cs.arpa 	Defsetf and define-setf-method    
C01514 00443	∂06-Jan-86  0854	RAM@C.CS.CMU.EDU 	Another inconsistency in CLtL   
C01516 00444	∂06-Jan-86  1323	Moon@SCRC-YUKON.ARPA 	Defsetf and define-setf-method   
C01520 00445	∂07-Jan-86  0038	cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	Type questions 
C01522 00446	∂07-Jan-86  0911	gls@THINK-AQUINAS.ARPA 	Type questions  
C01526 00447	∂07-Jan-86  0913	gls@THINK-AQUINAS.ARPA 	No more index typos, please    
C01528 00448	∂08-Jan-86  0839	kempf@hplabsc 	Hooks for Common Objects 
C01535 00449	∂09-Jan-86  0847	gls@THINK-AQUINAS.ARPA 	Common Lisp 'open'   
C01538 00450	∂09-Jan-86  1910	LOOSEMORE@UTAH-20.ARPA 	questions about packages  
C01540 00451	∂10-Jan-86  0711	NGALL@G.BBN.COM 	Re: questions about packages
C01543 00452	∂10-Jan-86  0941	RPG  	Varia from Tektronix    
C01545 00453	∂10-Jan-86  1102	GJC@MC.LCS.MIT.EDU 	SETF of an &REST list.   
C01547 00454	∂12-Jan-86  0642	RAM@C.CS.CMU.EDU 	fill-pointers and destructive sequence functions    
C01550 00455	∂13-Jan-86  1711	LOOSEMORE@UTAH-20.ARPA 	time of evaluation   
C01552 00456	∂14-Jan-86  1217	@MC.LCS.MIT.EDU:Soley@MC.LCS.MIT.EDU 	time of evaluation    
C01555 00457	∂14-Jan-86  1854	sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA 	Errata on p.431    
C01557 00458	∂15-Jan-86  0606	BSG@SCRC-STONY-BROOK.ARPA 	time of evaluation
C01561 00459	∂15-Jan-86  0815	SOLEY@MC.LCS.MIT.EDU 	time of evaluation
C01564 00460	∂15-Jan-86  0858	DLW@SCRC-STONY-BROOK.ARPA 	time of evaluation
C01570 00461	∂15-Jan-86  1002	kempf@hplabsc 	Re:  time of evaluation  
C01574 00462	∂15-Jan-86  1049	FAHLMAN@C.CS.CMU.EDU 	time of evaluation
C01579 00463	∂15-Jan-86  1226	RAM@C.CS.CMU.EDU 	time of evaluation    
C01583 00464	∂15-Jan-86  1430	LOOSEMORE@UTAH-20.ARPA 	Re: time of evaluation    
C01587 00465	∂15-Jan-86  1445	DLW@SCRC-STONY-BROOK.ARPA 	time of evaluation
C01590 00466	∂15-Jan-86  1457	RAM@C.CS.CMU.EDU 	time of evaluation    
C01592 00467	∂15-Jan-86  1504	Moon@SCRC-STONY-BROOK.ARPA 	time of evaluation of defstruct, deftype, etc. 
C01596 00468	∂15-Jan-86  1728	FAHLMAN@C.CS.CMU.EDU 	time of evaluation
C01602 00469	∂15-Jan-86  1736	FAHLMAN@C.CS.CMU.EDU 	time of evaluation of defstruct, deftype, etc.  
C01605 00470	∂15-Jan-86  1850	Moon@SCRC-STONY-BROOK.ARPA 	time of evaluation of defstruct, deftype, etc. 
C01608 00471	∂16-Jan-86  0141	REM@IMSSS 	2 ways to compile macros correctly
C01614 00472	∂16-Jan-86  1126	HEDRICK@RED.RUTGERS.EDU 	compiler enviornment
C01618 00473	∂16-Jan-86  1407	REM@IMSSS 	compiler environment, how best to isolate side effects
C01628 00474	∂17-Jan-86  0303	GJC@MC.LCS.MIT.EDU 	compiler enviornment
C01630 00475	∂17-Jan-86  0701	pyramid!bein@sri-unix 	compile environment.. 
C01637 00476	∂17-Jan-86  0753	FAHLMAN@C.CS.CMU.EDU 	compile environment..  
C01640 00477	∂17-Jan-86  1628	DLW@SCRC-QUABBIN.ARPA 	time of evaluation    
C01645 00478	∂17-Jan-86  1644	DLW@SCRC-QUABBIN.ARPA 	compiler environment, how best to isolate side effects   
C01649 00479	∂17-Jan-86  1813	hplabs!snyder@hplabs.ARPA 	Re: time of evaluation 
C01653 00480	∂19-Jan-86  1537	pyramid!bein@sri-unix 	floating point question    
C01656 00481	∂19-Jan-86  1559	RPG  
C01659 00482	∂19-Jan-86  1706	FAHLMAN@C.CS.CMU.EDU 	floating point question
C01662 00483	∂19-Jan-86  1736	Moon@SCRC-STONY-BROOK.ARPA 	floating point question    
C01664 00484	∂20-Jan-86  0951	BACH@SU-SCORE.ARPA 	Spelling correction 
C01666 00485	∂20-Jan-86  1023	FAHLMAN@C.CS.CMU.EDU 	Spelling correction    
C01670 00486	∂20-Jan-86  1052	DCP@SCRC-QUABBIN.ARPA 	Spelling correction   
C01674 00487	∂20-Jan-86  1859	RPG   	the Common-Lisp mailinglist 
C01676 00488	∂21-Jan-86  0836	gls@THINK-AQUINAS.ARPA 	Spelling correction  
C01681 00489	∂21-Jan-86  1039	SCHUMACHER@HP-HULK  
C01682 00490	∂22-Jan-86  1324	DDYER@SCRC-QUABBIN.ARPA 	Spelling correction 
C01690 00491	∂22-Jan-86  1738	BACH@SU-SCORE.ARPA 	Re: Spelling correction  
C01692 00492	∂22-Jan-86  2048	shebs%utah-orion@utah-cs.arpa 	Re: Spelling correction 
C01694 00493	∂22-Jan-86  2228	shebs%utah-orion@utah-cs.arpa 	Re: Spelling correction 
C01696 00494	∂23-Jan-86  0657	FAHLMAN@C.CS.CMU.EDU 	Spelling correction    
C01699 00495	∂23-Jan-86  1333	gls@THINK-AQUINAS.ARPA 	[vrotney@isi-vaxa.ARPA: Forwarded]  
C01701 00496	∂23-Jan-86  1847	mips!escargot.earl@glacier 	time of evaluation    
C01704 00497	∂23-Jan-86  2124	Moon@SCRC-STONY-BROOK.ARPA 	[vrotney@isi-vaxa.ARPA: Forwarded]   
C01706 00498	∂23-Jan-86  2253	GSB@MC.LCS.MIT.EDU 	common-lisp loop    
C01708 00499	∂24-Jan-86  1258	fateman@dali.berkeley.edu 	comparisons between floats and ratios 
C01711 00500	∂24-Jan-86  1618	Cassels@SCRC-STONY-BROOK.ARPA 	comparisons between floats and ratios  
C01718 00501	∂24-Jan-86  1935	Cassels@SCRC-STONY-BROOK.ARPA 	comparisons between floats and ratios  
C01725 00502	∂24-Jan-86  1946	FAHLMAN@C.CS.CMU.EDU 	comparisons between floats and ratios 
C01728 00503	∂24-Jan-86  2101	fateman@dali.berkeley.edu 	Re:  comparisons between floats and ratios 
C01731 00504	∂26-Jan-86  1324	Moon@SCRC-STONY-BROOK.ARPA 	Re:  comparisons between floats and ratios
C01734 00505	∂26-Jan-86  1413	fateman@dali.berkeley.edu 	more boring-to-most-people floating point stuff 
C01737 00506	∂26-Jan-86  1920	GJC@MC.LCS.MIT.EDU 	precision vs more information 
C01739 00507	∂26-Jan-86  1939	KSH@MC.LCS.MIT.EDU  
C01743 00508	∂27-Jan-86  0543	GZ%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	comparisons between floats and ratios
C01745 00509	∂27-Jan-86  0644	RAM@C.CS.CMU.EDU 	Compiler side effects lossage   
C01748 00510	∂27-Jan-86  0737	FAHLMAN@C.CS.CMU.EDU 	comparisons between floats and ratios 
C01750 00511	∂27-Jan-86  0742	FAHLMAN@C.CS.CMU.EDU 	comparisons between floats and ratios 
C01752 00512	∂27-Jan-86  0812	DCP@SCRC-VALLECITO.ARPA 	comparisons between floats and ratios   
C01756 00513	∂27-Jan-86  1153	fateman@dali.berkeley.edu 	precision, accuracy, and floating conversion (GJC's comment)   
C01758 00514	∂27-Jan-86  1417	gls@THINK-AQUINAS.ARPA 	precision, accuracy, and floating conversion (GJC's comment) 
C01760 00515	∂27-Jan-86  1449	gls@THINK-AQUINAS.ARPA 	Comparing float to rational    
C01765 00516	∂27-Jan-86  1608	GJC@MC.LCS.MIT.EDU 	precision, accuracy, and floating conversion (GJC's comment)
C01767 00517	∂27-Jan-86  1854	ME  	:capitalize in *print-case*   
C01769 00518	∂27-Jan-86  2050	FAHLMAN@C.CS.CMU.EDU 	:capitalize in *print-case*      
C01771 00519	∂27-Jan-86  2110	Moon@SCRC-STONY-BROOK.ARPA 	:capitalize in *print-case*     
C01773 00520	∂27-Jan-86  2308	fateman@dali.berkeley.edu 	IEEE float co-processors    
C01777 00521	∂28-Jan-86  0331	cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	Spelling correction 
C01779 00522	∂28-Jan-86  0452	GJC@MC.LCS.MIT.EDU 	Spelling correction 
C01781 00523	∂28-Jan-86  0545	FAHLMAN@C.CS.CMU.EDU 	Spelling correction    
C01783 00524	∂28-Jan-86  0555	FAHLMAN@C.CS.CMU.EDU 	IEEE float co-processors    
C01786 00525	∂28-Jan-86  0728	csi!meehan%UUCP@YALE.ARPA 	DEFUN inside LET  
C01788 00526	∂28-Jan-86  0748	DCP@SCRC-STONY-BROOK.ARPA 	IEEE float co-processors    
C01790 00527	∂28-Jan-86  1108	Moon@SCRC-STONY-BROOK.ARPA 	IEEE float co-processors   
C01792 00528	∂28-Jan-86  1250	Cassels@SCRC-STONY-BROOK.ARPA 	Comparing float to rational  
C01798 00529	∂28-Jan-86  1256	Cassels@SCRC-STONY-BROOK.ARPA 	comparisons between floats and ratios  
C01803 00530	∂28-Jan-86  1309	Cassels@SCRC-STONY-BROOK.ARPA 	comparisons between floats and ratios  
C01806 00531	∂28-Jan-86  1314	lab@rochester.arpa 	IEEE float co-processors 
C01808 00532	∂28-Jan-86  1500	REM@IMSSS 	Rebuttal to incorrect statement of portability definition  
C01812 00533	∂28-Jan-86  1526	Moon@SCRC-STONY-BROOK.ARPA 	IEEE float co-processors   
C01816 00534	∂28-Jan-86  1803	Cassels@SCRC-STONY-BROOK.ARPA 	more boring-to-most-people floating point stuff  
C01822 00535	∂28-Jan-86  1823	hilfingr@renoir.berkeley.edu 	Re: IEEE float co-processors  
C01830 00536	∂28-Jan-86  2015	FAHLMAN@C.CS.CMU.EDU 	DEFUN inside LET  
C01832 00537	∂29-Jan-86  1040	mcvax!nplmg1a.uucp!jrp@seismo.CSS.GOV 	Floating Point Computation
C01835 00538	∂29-Jan-86  1052	FAHLMAN@C.CS.CMU.EDU 	Floating Point Computation  
C01837 00539	∂29-Jan-86  1133	fateman@dali.berkeley.edu 	Re:  Floating Point Computation  
C01839 00540	∂29-Jan-86  1144	JAR@MC.LCS.MIT.EDU 	DEFUN inside LET    
C01841 00541	∂29-Jan-86  1206	FAHLMAN@C.CS.CMU.EDU 	DEFUN inside LET  
C01843 00542	∂30-Jan-86  0702	NGALL@G.BBN.COM 	Re:  DEFUN inside LET  
C01847 00543	∂30-Jan-86  0834	mcvax!nplmg1a.uucp!jrp@seismo.CSS.GOV 	Re: Floating Point Computation 
C01851 00544	∂30-Jan-86  1011	jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	Re:  DEFUN inside LET    
C01854 00545	∂30-Jan-86  1130	FAHLMAN@C.CS.CMU.EDU 	Defun inside Let  
C01856 00546	∂30-Jan-86  1146	RAM@C.CS.CMU.EDU 	DEFUN inside of LET   
C01860 00547	∂30-Jan-86  1304	DCP@SCRC-STONY-BROOK.ARPA 	Defun inside Let  
C01865 00548	∂30-Jan-86  1405	JAR@MC.LCS.MIT.EDU 	Defun inside Let    
C01869 00549	∂30-Jan-86  1426	smh@mit-ems.ARPA 	Re:  DEFUN inside LET 
C01872 00550	∂30-Jan-86  1506	DCP@SCRC-STONY-BROOK.ARPA 	Defun inside Let  
C01875 00551	∂30-Jan-86  1529	REM@IMSSS 	Defun inside Let   
C01885 00552	∂30-Jan-86  1712	smh@mit-ems.ARPA 	Re:  Defun inside Let 
C01889 00553	∂30-Jan-86  1714	RAM@C.CS.CMU.EDU 	Defun inside Let 
C01895 00554	∂30-Jan-86  1723	mips!escargot.earl@glacier 	DEFUN inside of LET   
C01897 00555	∂30-Jan-86  1805	@SCRC-QUABBIN.ARPA,@EUPHRATES.SCRC.Symbolics.COM:Moon@SCRC-STONY-BROOK.ARPA 	Defun inside Let  
C01902 00556	∂30-Jan-86  1805	DCP@SCRC-STONY-BROOK.ARPA 	Defun inside Let  
C01906 00557	∂30-Jan-86  1811	GJC@MC.LCS.MIT.EDU 	editing environments
C01909 00558	∂30-Jan-86  1930	FAHLMAN@C.CS.CMU.EDU 	Defun inside Let  
C01913 00559	∂30-Jan-86  2050	meehan@YALE.ARPA    
C01915 00560	∂30-Jan-86  2055	FAHLMAN@C.CS.CMU.EDU
C01917 00561	∂31-Jan-86  0906	DLW@SCRC-STONY-BROOK.ARPA 	Defun inside Let  
C01919 00562	∂31-Jan-86  0938	DLW@SCRC-QUABBIN.ARPA 	Defun inside Let 
C01922 00563	∂31-Jan-86  1806	OLDMAN@USC-ISI.ARPA 	Defmacro inside of a let
C01924 00564	∂31-Jan-86  1806	OLDMAN@USC-ISI.ARPA 	&environment  
C01925 00565	∂31-Jan-86  1808	OLDMAN@USC-ISI.ARPA 	deftype with &key  
C01926 00566	∂31-Jan-86  2156	OLDMAN@USC-ISI.ARPA 	Defmacro inside of a let
C01928 00567	∂31-Jan-86  2228	FAHLMAN@C.CS.CMU.EDU 	&environment 
C01930 00568	∂31-Jan-86  2306	OLDMAN@USC-ISI.ARPA 	&environment  
C01931 00569	∂31-Jan-86  2337	OLDMAN@USC-ISI.ARPA 	get-setf-method-multiple-value    
C01932 00570	∂01-Feb-86  0025	OLDMAN@USC-ISI.ARPA 	deftype with &key  
C01933 00571	∂01-Feb-86  0051	Moon@SCRC-STONY-BROOK.ARPA 	Retraction  
C01936 00572	∂01-Feb-86  0713	RAM@C.CS.CMU.EDU 	Defmacro inside of a let   
C01938 00573	∂01-Feb-86  0805	FAHLMAN@C.CS.CMU.EDU 	Retraction   
C01941 00574	∂01-Feb-86  1235	Moon@SCRC-QUABBIN.ARPA 	get-setf-method-multiple-value 
C01943 00575	∂01-Feb-86  1500	Moon@SCRC-STONY-BROOK.ARPA 	deftype with &key
C01945 00576	∂01-Feb-86  1630	GJC@MC.LCS.MIT.EDU 	Retraction
C01947 00577	∂01-Feb-86  1638	smh@mit-ems.ARPA 	Re:  Defun inside Let 
C01949 00578	∂02-Feb-86  1912	DCP@SCRC-STONY-BROOK.ARPA 	Nothing to do with Common Lisp   
C01959 00579	∂03-Feb-86  0639	jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	Re: Re: Defun inside Let 
C01963 00580	∂03-Feb-86  0736	FAHLMAN@C.CS.CMU.EDU 	Defun inside Let  
C01966 00581	∂03-Feb-86  0952	gls@THINK-AQUINAS.ARPA 	Defun inside Let
C01969 00582	∂03-Feb-86  1059	REM%IMSSS.#Pup@SU-SCORE.ARPA 	Jeff Dalton's point 
C01971 00583	∂03-Feb-86  1101	Moon@SCRC-STONY-BROOK.ARPA 	Re: Re: Defun inside Let   
C01974 00584	∂03-Feb-86  1646	vollum@SCRC-STONY-BROOK.ARPA 	Re:  Defmacro inside of a let 
C01978 00585	∂03-Feb-86  1708	WEEKS@HP-THOR 	eval'd macros  
C01980 00586	∂03-Feb-86  1738	FAHLMAN@C.CS.CMU.EDU 	eval'd macros
C01982 00587	∂03-Feb-86  1905	RAM@C.CS.CMU.EDU 	Defmacro inside of a let   
C01985 00588	∂04-Feb-86  0734	DCP@SCRC-STONY-BROOK.ARPA 	eval'd macros
C01988 00589	∂04-Feb-86  0739	gallagher%umass-cs.csnet@CSNET-RELAY.ARPA 	Defstruct Extensions  
C01993 00590	∂04-Feb-86  0916	liz@brillig.umd.edu 	loop macro    
C01997 00591	∂04-Feb-86  0952	kempf@hplabsc 	Re:  Defstruct Extensions
C02000 00592	∂04-Feb-86  1005	jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	Re:  eval'd macros  
C02002 00593	∂04-Feb-86  1029	KMP@SCRC-STONY-BROOK.ARPA 	eval'd macros (the other point of view)    
C02007 00594	∂04-Feb-86  1032	Gregor.pa@Xerox.COM 	Re: Defstruct Extensions
C02010 00595	∂04-Feb-86  1037	FAHLMAN@C.CS.CMU.EDU 	eval'd macros (the other point of view)    
C02012 00596	∂04-Feb-86  1103	FAHLMAN@C.CS.CMU.EDU 	loop macro   
C02014 00597	∂04-Feb-86  1119	FAHLMAN@C.CS.CMU.EDU 	loop macro   
C02016 00598	∂04-Feb-86  1319	liz@brillig.umd.edu 	Re: loop macro
C02019 00599	∂04-Feb-86  1332	BSG@SCRC-STONY-BROOK.ARPA 	Re: loop macro    
C02023 00600	∂04-Feb-86  1416	FAHLMAN@C.CS.CMU.EDU 	loop macro   
C02029 00601	∂04-Feb-86  1434	sean@cadre.dsl.pittsburgh.edu 	Re: loop macro
C02031 00602	∂04-Feb-86  1552	Gregor.pa@Xerox.COM 	Re: loop macro
C02034 00603	∂04-Feb-86  1556	DLW@SCRC-STONY-BROOK.ARPA 	loop macro   
C02039 00604	∂04-Feb-86  1651	snyder@hplsny 	Re: loop macro 
C02042 00605	∂04-Feb-86  1722	FAHLMAN@C.CS.CMU.EDU 	loop macro   
C02044 00606	∂04-Feb-86  1753	liz@brillig.umd.edu 	Re: loop macro
C02050 00607	∂04-Feb-86  1811	FAHLMAN@C.CS.CMU.EDU 	loop macro   
C02055 00608	∂04-Feb-86  1826	FAHLMAN@C.CS.CMU.EDU 	loop macro   
C02057 00609	∂04-Feb-86  1954	sean@cadre.dsl.pittsburgh.edu 	Re:  loop macro    
C02059 00610	∂05-Feb-86  0616	FAHLMAN@C.CS.CMU.EDU 	loop macro   
C02061 00611	∂05-Feb-86  0721	gls@THINK-AQUINAS.ARPA 	Re: loop macro  
C02064 00612	∂05-Feb-86  0908	gls@THINK-AQUINAS.ARPA 	Re: loop macro  
C02078 00613	∂05-Feb-86  1501	shebs%utah-orion@utah-cs.arpa 	GLS replacements for LOOP    
C02081 00614	∂05-Feb-86  1522	@MC.LCS.MIT.EDU:Soley@MC.LCS.MIT.EDU 	Re: loop macro   
C02084 00615	∂05-Feb-86  1522	AI.BOYER@MCC.ARPA 	loop speed 
C02086 00616	∂05-Feb-86  1529	jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	Re:  eval'd macros (the other point of view) 
C02089 00617	∂05-Feb-86  1536	Fitch%cs.ucl.ac.uk@Cs.Ucl.AC.UK 	LISP standardisation  
C02096 00618	∂05-Feb-86  1650	hpfclp!diamant@hplabs.ARPA 	Re: eval'd macros (the other point of view)    
C02101 00619	∂05-Feb-86  1650	willc%tekchips%tektronix.csnet@CSNET-RELAY.ARPA 	lexical scope & program development 
C02107 00620	∂05-Feb-86  1738	hpfclp!diamant@hplabs.ARPA 	intern 
C02112 00621	∂05-Feb-86  1900	BSG@SCRC-STONY-BROOK.ARPA 	Re: loop macro    
C02115 00622	∂05-Feb-86  1901	DLW@SCRC-STONY-BROOK.ARPA 	loop macro   
C02126 00623	∂05-Feb-86  2025	FAHLMAN@C.CS.CMU.EDU 	eval'd macros (the other point of view)    
C02132 00624	∂05-Feb-86  2051	FAHLMAN@C.CS.CMU.EDU 	loop macro   
C02135 00625	∂05-Feb-86  2123	FAHLMAN@C.CS.CMU.EDU 	eval'd macros (the other point of view)    
C02140 00626	∂05-Feb-86  2310	zorn@renoir.berkeley.edu 	Interest in "large" Common Lisp Programs    
C02143 00627	∂06-Feb-86  0507	DLW@SCRC-STONY-BROOK.ARPA 	lexical scope & program development   
C02145 00628	∂06-Feb-86  0514	DLW@SCRC-STONY-BROOK.ARPA 	Re: loop macro    
C02149 00629	∂06-Feb-86  0659	NGALL@G.BBN.COM 	Re: intern   
C02152 00630	∂06-Feb-86  0704	sean@cadre.dsl.pittsburgh.edu 	Common Lisp LOOP Package
C02154 00631	∂06-Feb-86  0828	DCP@SCRC-STONY-BROOK.ARPA 	eval'd macros (the other point of view)    
C02158 00632	∂06-Feb-86  0939	gls@THINK-AQUINAS.ARPA 	LISP standardisation 
C02160 00633	∂06-Feb-86  1318	Gregor.pa@Xerox.COM 	Re: loop macro
C02163 00634	∂06-Feb-86  1320	RPG   	Please remover CSTACY from this mailing list    
C02166 00635	∂06-Feb-86  1329	RPG  	Loop Macro    
C02168 00636	∂06-Feb-86  1611	MMcM@SCRC-STONY-BROOK.ARPA 	LOOP again  
C02169 00637	∂06-Feb-86  1742	DLW@SCRC-STONY-BROOK.ARPA 	Re: loop macro    
C02174 00638	∂07-Feb-86  0814	hoey@nrl-aic 	Re: loop macro  
C02181 00639	∂07-Feb-86  0944	RPG  
C02182 00640	∂07-Feb-86  1313	Moon@SCRC-QUABBIN.ARPA 	loop macro 
C02185 00641	∂07-Feb-86  1322	Moon@SCRC-STONY-BROOK.ARPA 	loop macro  
C02188 00642	∂07-Feb-86  1521	DDYER@SCRC-STONY-BROOK.ARPA 	loop macro 
C02192 00643	∂08-Feb-86  2048	sean@cadre.dsl.pittsburgh.edu 	LOOP Macro code for Common Lisp   
C02194 00644	∂10-Feb-86  1145	Gregor.pa@Xerox.COM 	Compiling functions which appear inside top-level forms.   
C02197 00645	∂10-Feb-86  1215	@MIT-REAGAN.ARPA:KWH@MIT-AI.ARPA 	The return of UNSPECIAL   
C02199 00646	∂10-Feb-86  1245	FAHLMAN@C.CS.CMU.EDU 	Compiling functions which appear inside top-level forms.  
C02202 00647	∂10-Feb-86  1305	Gregor.pa@Xerox.COM 	Re: Compiling functions which appear inside top-level forms.    
C02204 00648	∂11-Feb-86  0811	kessler%utah-orion@utah-cs.arpa 	Car and Cdr of nil is nil  
C02206 00649	∂11-Feb-86  0915	FAHLMAN@C.CS.CMU.EDU 	Car and Cdr of nil is nil   
C02209 00650	∂11-Feb-86  0922	FAHLMAN@C.CS.CMU.EDU 	Compiling functions which appear inside top-level forms.  
C02211 00651	∂11-Feb-86  0941	BROOKS%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	code density as a function of elegance
C02217 00652	∂11-Feb-86  1122	Bobrow.pa@Xerox.COM 	Re: Car and Cdr of nil is nil
C02219 00653	∂11-Feb-86  1228	liz@brillig.umd.edu 	Re: loop macro
C02236 00654	∂11-Feb-86  1234	hpfclp!diamant@hplabs.ARPA 	Re: intern  
C02241 00655	∂11-Feb-86  1443	masinter.pa@Xerox.COM 	Re: Car and Cdr of nil is nil   
C02243 00656	∂11-Feb-86  2008	HEDRICK@RED.RUTGERS.EDU 	problem with (CAR NIL) = NIL  
C02245 00657	∂12-Feb-86  0708	jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	Re: loop macro 
C02247 00658	∂12-Feb-86  0757	NGALL@G.BBN.COM 	Re: intern   
C02256 00659	∂12-Feb-86  1951	FAHLMAN@C.CS.CMU.EDU 	The return of UNSPECIAL
C02258 ENDMK
C⊗;
∂15-Sep-85  1441	MMcM@SCRC-STONY-BROOK.ARPA 	LAMBDA expression to the SATISFIES type specifier   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Sep 85  14:41:39 PDT
Received: from MERRIMACK.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 313991; Sun 15-Sep-85 17:38:27-EDT
Date: Sun, 15 Sep 85 17:42 EDT
From: Mike McMahon <MMcM@SCRC-STONY-BROOK.ARPA>
Subject: LAMBDA expression to the SATISFIES type specifier
To: Guy Steele <gls@THINK-AQUINAS.ARPA>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <850911163632.9.GLS@DESIDERIUS.THINK.COM>
Message-ID: <850915174204.1.MMCM@MERRIMACK.SCRC.Symbolics.COM>

    Date: Wed, 11 Sep 85 16:36 EDT
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>

    The case I was worried about was

    (defun foo (x y)
      (declare (type (satisfies (lambda (q) (eq q y))) x))
      ...)

That doesn't seem to me substantially different from

(defun foo (x)
  (flet ((foo-p (q) (eq q x)))
    (let ((y x))
      (declare (type (satisfies foo-p) y))
      ...)))

which the manual is quite clear on (it doesn't work).  I have no
objection to the first example not working either.  It seems that we
should allow LAMBDA expressions and be consistent about the lexical
environment for both functions and variables, presumably global.

∂16-Sep-85  1115	RAM@C.CS.CMU.EDU 	structure equality in slisp
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 Sep 85  11:14:17 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Mon 16 Sep 85 14:14:56-EDT
Date: Mon, 16 Sep 1985  14:14 EDT
Message-ID: <RAM.12143757965.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   David.Butcher@ML.RI.CMU.EDU
Cc:   Gripe@ML.RI.CMU.EDU, Scott.Fahlman@C.CS.CMU.EDU,
      Skef.Wholey@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
Subject: structure equality in slisp
In-reply-to: Msg of 13 Sep 1985  14:23-EDT from David.Butcher at ML.RI.CMU.EDU

   From: David.Butcher at ML.RI.CMU.EDU
   To:   Gripe at ML.RI.CMU.EDU
   Re:   structure equality in slisp

  (equal (make-point) (make-point)) returned nil.

  a point is just three slots containing a number each.

  according to the book, things that have the same print name are equal.
  so shouldn't equal work on structures?

Unfortunately, EQUAL is not a structural equality predicate.  For
historical reasons, EQUAL on any atom other than a string (or a
bit-vector) is equivalent to EQL.  Even worse, *there is no structural
equality predicate* in Common Lisp.  You can use EQUALP, but then
comparisons of characters are case-insensitive.  Yes, this is
misleading, confusing and inconsistent.  I think it sucks.  Flame
flame.

  Rob

∂16-Sep-85  1251	REM%IMSSS.#Pup@SU-SCORE.ARPA 	EQUAL isn't really correct, I agree
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 16 Sep 85  12:51:35 PDT
Received: from IMSSS by Score with Pup; Mon 16 Sep 85 12:50:06-PDT
Date: 16 Sep 1985 1251-PDT
From: Rem@IMSSS
Subject: EQUAL isn't really correct, I agree
To:   RAM%C.CS.CMU.EDU@SCORE
cc:   COMMON-LISP%SU-AI@SCORE

Several months ago I came to the same conclusion, that none of the equality
predicates are correct for many structure-comparing operations, and I roughly
sketched out what would be better: a flexible structure-comparing function.
Basically you tell the function what kinds of primitive cells should be
STOP points and what should be recurse-through cells (the union of the
two sets should be the universe of data types, or at least should include
every kind of cell encountered in the task at hand). At STOP points, some
more primitive function is needed to perform the actual comparison, so you
tell the general function what primitive comparison function is to be used
at each STOP point. Also, at each recurse-through some method of mapping
all the components is needed, which would be implicit in the function
definition for built-in datatypes but may need to be described explicitly
for user-defined datatypes or for deliberately not recursing down certain
branches.

Typical variations on the usual EQUAL that would be supported trivially
by this method:  Identifiers get compared by PNAME rather than EQ, thus
matching non-interned identifiers correctly.  Numbers get compared with
fudge factor that is magnitude-dependent in unusual way.  Recursion occurs
through the VALUE and PROPERTY-LIST of each identifier that is in the
FOO package but stops on other identifiers (hint, make identifiers STOP
points but define the comparison function at that point to look at the
package cell and explicitly call the super-equal function recursively
in some cases).  ...

Once this super-general function is properly defined and implemented,
special cases can be described in a uniform way as canned arguments to
this function, and then can be handcoded more efficiently if desired.

In many cases there are oodles of special-case functions and nothing
properly general in CL currently. Perhaps general functions should be
defined and some of the special cases flushed, as such cases are recognized?
Super-general-EQUAL could be the first such super-general function?
-------

∂16-Sep-85  1456	hplabs!snyder%hplabs.csnet@CSNET-RELAY.ARPA 	compiling anonymous functions 
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 16 Sep 85  14:55:55 PDT
Received: from hplabs by csnet-relay.csnet id am07932; 16 Sep 85 17:52 EDT
Received: by HP-VENUS id AA23982; Mon, 16 Sep 85 11:13:54 pdt
Message-Id: <8509161813.AA23982@HP-VENUS>
Date: Monday, September 16, 1985  11:03:01
From: snyder%hplabs.csnet@CSNET-RELAY.ARPA
Subject: compiling anonymous functions
To: common-lisp@su-ai.arpa
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
Source-Info:  From (or Sender) name not authenticated.

I agree with Jonathan Rees that compilers should compile anonymous functions,
and that it is important that programmers be able to assume this behavior.  I
also agree with Scott Fahlman that the best approach would be to require (or
at least strongly suggest) that compilers treat all compilable functions
equally.  Thus, if a compiler compiles top-level defuns in a given
implementation, it must also compile other compilable function definitions as
well.

However, this notion depends on being able to come up with a clear definition
of "compilable function".  Anyone have any suggestions on how to define this?
Can this notion be defined in a way that does not unduly restrict the
implementation?  One thing that has bothered me in the definition of CL is the
limited definition of "top-level form" (page 66).  I would suggest extending
it (recursively) to include forms directly nested in top-level occurrences of
LOCALLY, MACROLET, COMPILER-LET, EVAL-WHEN, and PROGN.
-------

∂17-Sep-85  0727	FAHLMAN@C.CS.CMU.EDU 	compiling anonymous functions    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 Sep 85  07:27:35 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 17 Sep 85 10:28:14-EDT
Date: Tue, 17 Sep 1985  10:28 EDT
Message-ID: <FAHLMAN.12143978847.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   snyder%hplabs.csnet@CSNET-RELAY.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: compiling anonymous functions
In-reply-to: Msg of 16 Sep 1985  11:03-EDT from snyder%hplabs.csnet at CSNET-RELAY.ARPA


Disclaimer: All of the following is a suggestion for how the language
specification might be improved, once we have a mechanism in place for
considering such improvements.

Clearly the whole section on top-level forms needs to be reconsidered
and tightened up.  We got off on the wrong foot on that one, and never
recovered.  Probably we should flush the whole notion of top-level forms
and just provide some rules about what the compiler does.  We can
probably go ahead and assume that there is a compiler of some sort and
that it is written in Common Lisp without saying much about what code it
generates or how intensively it hacks things.  What we need to specify
more clearly are which things get compiled (whatever that may mean) and
which forms are "seen" by the compiler in the sense of causing side
effects -- macro definitions, constant definitions, declarations, and
the like.

I think that the following are more or less standard practice now, and
should probably be required (or at least strongly suggested and assumed
by portable code libraries) at some future time:

1. Occurrences of (function (lambda ...)) within forms that are being
compiled are themselves compiled.  So if a function definition is

(defun foo () (setf x #'(lambda () (mumble))))

then if we compile foo and then call it, X will contain a function
object that is compiled as if it had been a top-level defun.  Note that
if you want to set X to an uncompiled expression, you can use '(lambda
...). 

2. Embedded Defuns get compiled, roughly as if they were embedded
(setf (symbol-function <name>) (function (lambda ...))) forms.
We don't want to force users to write the long form in order to ensure
compilation.  If an implementation has defun doing additional things,
such as maintaining data structures for the programming environment,
then it is up to the implementor to do the right thing when compiling
embedded Defuns, but the actual definition still should end up compiled.

3. "Random" Top-level forms (anything whose semantics are not special to
the compiler) are compiled and then executed at load time.  So if a file
being compiled contains

(mumble ...)

it is compiled more or less as if it were

(defun <made-up-name> () (mumble ...))
(<made-up-name>)

The point is not to force all implementations to execute these things
fast at load time, though that is certainly a plus for any
implementation.  The point of including this in the standard is to
standardize what happens when the random form contains constructs that
might have side effects on the compiler or sub-forms that might want to
be compiled.  (This was discussed at some length before the manual came
out, but I don't think the manual currently takes a stand on this.)

So, if all the above were to become standard, a user could employ an
idiom like

(let ((x 0) (y 1024))
  (defun foo () ...)
  (defun bar () ...))

and be sure that FOO and BAR would be compiled, whatever that means for
a given implementaiton.  I don't think this is guaranteed now, though it
is an idiom I use a lot.

I think that this subsumes Snyder's suggestions for extending the list
of forms whose interiors are considered to be "top-level", at least on
the issue of what gets compiled.  The question of where you can put
PROCLAIM forms and the like might be more complicated.

-- Scott

∂18-Sep-85  0637	gls@THINK-AQUINAS.ARPA 	Franz -> Common Lisp 
Received: from THINK.COM by SU-AI.ARPA with TCP; 18 Sep 85  06:37:11 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Wed, 18 Sep 85 09:37:58 edt
Date: Wed, 18 Sep 85 09:37 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Franz -> Common Lisp
To: leite@UCI-ICSD.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 17 Sep 85 19:52-EDT from Julio Leite <leite at uci-icsd>
Message-Id: <850918093747.1.GLS@DESIDERIUS.THINK.COM>

    Date: 17 Sep 85 16:52:10 PDT (Tue)
    From: Julio Leite <leite@uci-icsd>

    Dear Mr Steele,

	    We at the Reuse Project, over University of California at
    Irvine, are working in a conversion  of a large prototype  system
    from Franz Lisp to  Common Lisp.
	    We suppose that other people had this experience before,
    and we would like to know if you know somebody who did it, and if
    there are any references available.
	    We appreciate your attention, and be sure that any information
    you may have will be very useful to us.
	    Thank you,
			    Julio Cesar Leite
			      UCI - ICS
			     Irvine,Ca 92717
			     leite@uci-icsd.arpa
			     ucbvax!ucivax!leite
	

I am forwarding this message to the common-lisp mailing list to
see what information we can come up with.
--Guy

∂18-Sep-85  0805	robbins@DEC-HUDSON 	Modification to LISTEN   
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 18 Sep 85  08:04:37 PDT
Date: Wed, 18 Sep 85 11:07:13 EDT
From: robbins@DEC-HUDSON
Subject: Modification to LISTEN
To: common-lisp@su-ai
Cc: robbins@dec-hudson

I would like to have LISTEN return two values.  The first value is the same as
it is now and the second value is true if end of file is encountered.  The
new definition allows READ-CHAR-NO-HANG to be implemented using only READ-CHAR
and LISTEN.

    (defun read-char-no-hang (&optional input-stream eof-error-p eof-value
                                        recursive-p)
      (multiple-value-bind (char-available-p eof-encountered-p)
                           (listen input-stream)
        (cond (char-available-p
                (read-char input-stream eof-error-p eof-value recursive-p))
              (eof-encountered-p
                (if eof-error-p (error ...) eof-value)))))

              

∂18-Sep-85  0956	FAHLMAN@C.CS.CMU.EDU 	Modification to LISTEN 
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Sep 85  09:55:53 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 18 Sep 85 12:56:44-EDT
Date: Wed, 18 Sep 1985  12:56 EDT
Message-ID: <FAHLMAN.12144268018.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   robbins@DEC-HUDSON.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: Modification to LISTEN
In-reply-to: Msg of 18 Sep 1985  11:07-EDT from robbins at DEC-HUDSON


    I would like to have LISTEN return two values.  The first value is the same as
    it is now and the second value is true if end of file is encountered.  The
    new definition allows READ-CHAR-NO-HANG to be implemented using only READ-CHAR
    and LISTEN.

Looks like a good suggestion to me.  It could be implemented in a
completely upward-compatible way.

-- Scott

∂18-Sep-85  1251	robbins@DEC-HUDSON 	Concatenated Stream Query
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 18 Sep 85  12:47:04 PDT
Date: Wed, 18 Sep 85 15:50:09 EDT
From: robbins@DEC-HUDSON
Subject: Concatenated Stream Query
To: common-lisp@su-ai
Cc: robbins

Given the following streams:

(setf stream-1 (make-string-input-stream "A line without a newline."))
(setf stream-2 (make-string-input-stream "Our generic second line."))
(setf stream-3 (make-concatenated-stream stream-1 stream-2))

What should (read-line stream-3) return,  I can imagine two possibilities

"A line without a newline.Our generic second line." t

"A line without a newline." nil

-- Rich

∂18-Sep-85  1311	FAHLMAN@C.CS.CMU.EDU 	Concatenated Stream Query   
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Sep 85  13:11:27 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 18 Sep 85 16:12:08-EDT
Date: Wed, 18 Sep 1985  16:12 EDT
Message-ID: <FAHLMAN.12144303598.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   robbins@DEC-HUDSON.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: Concatenated Stream Query
In-reply-to: Msg of 18 Sep 1985  15:50-EDT from robbins at DEC-HUDSON


    (setf stream-1 (make-string-input-stream "A line without a newline."))
    (setf stream-2 (make-string-input-stream "Our generic second line."))
    (setf stream-3 (make-concatenated-stream stream-1 stream-2))

    What should (read-line stream-3) return,  I can imagine two possibilities

    "A line without a newline.Our generic second line." t

    "A line without a newline." nil

I think the first candidate is the obvious winner.  I see nothing in the
manual that would support the existence of an implicit newline character
between the concatenated streams, and I don't think that this would be
desirable.

-- Scott

∂18-Sep-85  1318	@MIT-REAGAN.ARPA:Soley@MIT-MC.ARPA 	Concatenated Stream Query    
Received: from MIT-REAGAN.ARPA by SU-AI.ARPA with TCP; 18 Sep 85  13:18:49 PDT
Received: from MIT-CHERRY by MIT-REAGAN via CHAOS with CHAOS-MAIL id 8171; Wed 18-Sep-85 16:20:33-EDT
Date: Wed, 18 Sep 85 16:18 EDT
From: Soley@MIT-MC.ARPA
Subject: Concatenated Stream Query
To: robbins@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 18 Sep 85 15:50-EDT from robbins at DEC-HUDSON
Message-ID: <850918161848.7.SOLEY@CHERRY.MIT>

    Date: Wed, 18 Sep 85 15:50:09 EDT
    From: robbins@DEC-HUDSON
    Subject: Concatenated Stream Query
    To: common-lisp@su-ai
    Cc: robbins

    Given the following streams:

    (setf stream-1 (make-string-input-stream "A line without a newline."))
    (setf stream-2 (make-string-input-stream "Our generic second line."))
    (setf stream-3 (make-concatenated-stream stream-1 stream-2))

    What should (read-line stream-3) return,  I can imagine two possibilities

    (1) "A line without a newline.Our generic second line." t

    (2) "A line without a newline." nil

I think it definitely MUST return (1).  Consider

(setf stream-1 (make-string-input-stream "A line without a newline.
"))
(setf stream-2 (make-string-input-stream "Our generic second line."))
(setf stream-3 (make-concatenated-stream stream-1 stream-2))

which should return (2).  [The next (read-line stream-3) shouldn't
return "", but {"Our generic second line.", t}.

	-- Richard

∂18-Sep-85  1415	gls@THINK-AQUINAS.ARPA 	Concatenated Stream Query 
Received: from THINK.COM by SU-AI.ARPA with TCP; 18 Sep 85  14:14:37 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Wed, 18 Sep 85 17:15:28 edt
Date: Wed, 18 Sep 85 17:15 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Concatenated Stream Query
To: robbins@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <850918161848.7.SOLEY@CHERRY.MIT>
Message-Id: <850918171522.6.GLS@DESIDERIUS.THINK.COM>

I am in agreement with Fahlman and Soley on this matter.  The manual
should be clearer on the point that the user of a concatenated stream
does not see any end-of-file indication when subsidiary streams other
than the last hit end of file.  However, the manual certainly does not
support the implicit inclusion of any additional separator characters or
other such phenomena as one subsidiary stream ends and the next one
comes into use.
--Guy

∂18-Sep-85  1516	wagner@GSWD-VMS 	Erratum 
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 18 Sep 85  15:16:22 PDT
Date: Wed, 18 Sep 85 17:16:00 CDT
From: wagner@GSWD-VMS
Subject: Erratum
To: common-lisp@su-ai.arpa
Cc: wagner

On the top of page 295 of CLtL, three examples are given for
the bit-array logic functions.  The third example is

	(bit-andc1 #*1100 #*1010) => #*0100

Given the definition of BIT-ANDC1 on page 294 ("and complement
argument1 with argument2"), this example is in error.  Either
the function should be BIT-ANDC2, or the return value should
be #*0010.

Fran

∂18-Sep-85  1822	MMcM@SCRC-STONY-BROOK.ARPA 	Modification to LISTEN
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Sep 85  18:22:22 PDT
Received: from MERRIMACK.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 316386; Wed 18-Sep-85 21:18:44-EDT
Date: Wed, 18 Sep 85 21:22 EDT
From: Mike McMahon <MMcM@SCRC-STONY-BROOK.ARPA>
Subject: Modification to LISTEN
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: robbins@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12144268018.BABYL@C.CS.CMU.EDU>
Message-ID: <850918212239.2.MMCM@MERRIMACK.SCRC.Symbolics.COM>

    Date: Wed, 18 Sep 1985  12:56 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

	I would like to have LISTEN return two values.  The first value is the same as
	it is now and the second value is true if end of file is encountered.  The
	new definition allows READ-CHAR-NO-HANG to be implemented using only READ-CHAR
	and LISTEN.

    Looks like a good suggestion to me.  It could be implemented in a
    completely upward-compatible way.

In good lisp machine style, programs use both READ-CHAR-NO-HANG and
LISTEN.  LISTEN is treated only as a (possibly spurious) wakeup.
Imagine a network stream interface, where LISTEN returns when some
packet-ready-for-reciept hardware flag gets set.  READ-CHAR-NO-HANG
might return NIL if the packet that it reads out is damaged, out of
sequence, etc.  The rule is that LISTEN is allowed to return T when
READ-CHAR-NO-HANG will return NIL, provided that READ-CHAR-NO-HANG will
tend to clear the spurious condition.

I'm not sure this advocates against the above proposal, but I do feel
that there is good reason for having both primitives.

∂19-Sep-85  0702	gls@THINK-AQUINAS.ARPA 	Erratum    
Received: from THINK.COM by SU-AI.ARPA with TCP; 19 Sep 85  07:02:43 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Thu, 19 Sep 85 10:03:33 edt
Date: Thu, 19 Sep 85 10:03 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Erratum
To: wagner@GSWD-VMS.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 18 Sep 85 18:16-EDT from wagner at GSWD-VMS
Message-Id: <850919100326.1.GLS@DESIDERIUS.THINK.COM>

    Date: Wed, 18 Sep 85 17:16:00 CDT
    From: wagner@GSWD-VMS

    On the top of page 295 of CLtL, three examples are given for
    the bit-array logic functions.  The third example is

	    (bit-andc1 #*1100 #*1010) => #*0100

    Given the definition of BIT-ANDC1 on page 294 ("and complement
    argument1 with argument2"), this example is in error.  Either
    the function should be BIT-ANDC2, or the return value should
    be #*0010.

    Fran

Right you are.  Thanks.
--Guy

∂19-Sep-85  1626	MLY%MIT-OZ@MIT-MC.ARPA 	Returning additional values from advertised functions   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 19 Sep 85  16:25:52 PDT
Date: Thu 19 Sep 85 19:27:24-EDT
From: Richard Mlynarik
Subject: Returning additional values from advertised functions
Sender: MLY%MIT-OZ@MIT-MC.ARPA
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
Reply-To: MLY@MIT-OZ
In-Reply-To: <FAHLMAN.12144268018.BABYL@C.CS.CMU.EDU>
Message-ID: <12144601298.71.MLY@MIT-OZ>

    Date: Wed, 18 Sep 1985  12:56 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
    To:   robbins@DEC-HUDSON.ARPA
    Cc:   common-lisp@SU-AI.ARPA
    Subject: Modification to LISTEN
    In-reply-to: Msg of 18 Sep 1985  11:07-EDT from robbins at DEC-HUDSON


        I would like to have LISTEN return two values. [...]

    Looks like a good suggestion to me.  It could be implemented in a
    completely upward-compatible way.

I am a little worried about this answer.  The existence of
the multiple-value-call special form means that no such change can
truly be made upward-compatibly.  The lisp I maintain has a number
of functions which return useful, additional values (though usually
somewhat too implementation-specific or marginal to be advocated as a
an enhancement for "official" cl) beyond those specified by GSSB, and
I am somewhat loathe to flush them simply for compatibility when I am
sure that most receivers of multiple values are either
multiple-value-bind/setq's.

I remember that at the time of the initial discussion of the cl
multiple-value scheme there were a number of people (kmp stands out
most distinctly in my memory) who advocated as rigorous checking in
receiving multiple values from calls as in receiving arguments to
calls.  Perhaps they were right.
As it stands, I think that anybody using multiple-value-call is
except in very constrained situations is probably Courting Lossage

Just a point to bear in mind....

[BTW I have been inconvenienced several times recently by the fact the
multiple-value-setq is not multiple-value-setf.  This is a somewhat
curious shortcoming, especially now that the All-New Fashion in lisp
code seems to be to entirely eschew setq in favour of setf] 
-------

∂19-Sep-85  1758	bobrow.pa@Xerox.ARPA 	Arguments and values to get.
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 19 Sep 85  17:58:09 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 SEP 85 17:43:45 PDT
Date: 19 Sep 85 16:39 PDT
Sender: bobrow.pa@Xerox.ARPA
Subject: Arguments and values to get.
To: Common-Lisp@SU-AI.ARPA
cc: cl-object-oriented-programming@su-ai.ARPA
From: Gregor.pa@Xerox.ARPA
Message-ID: <850919-174345-1059@Xerox>

This (admittedly minor) question came up while we were writing up some
of the CommonLoops metaclass protocols.

Why does Common-Lisp GET take a default-value argument instead of
returning a second value indicating whether the property actually
exists?

Originally we had wanted to make CommonLoops' internal slot-access
function return a second value saying whether or not the slot-existed
but we ended up changing it to be more like GET.

∂19-Sep-85  1819	FAHLMAN@C.CS.CMU.EDU 	Arguments and values to get.
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 Sep 85  18:19:31 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 19 Sep 85 21:19:45-EDT
Date: Thu, 19 Sep 1985  21:19 EDT
Message-ID: <FAHLMAN.12144621737.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Gregor.pa@XEROX.ARPA
Cc:   cl-object-oriented-programming@SU-AI.ARPA, Common-Lisp@SU-AI.ARPA
Subject: Arguments and values to get.
In-reply-to: Msg of 19 Sep 1985  19:39-EDT from Gregor.pa at Xerox.ARPA


    Why does Common-Lisp GET take a default-value argument instead of
    returning a second value indicating whether the property actually
    exists?

The default argument is useful in some cases, but admittedly is a bit
inelegant -- if you want to know for sure whether a value was found, you
have to be careful to choose some default argument that couldn't
possibly be stored in any property list.  The reasoning (If I recall it
correctly) was that this occasional creation of a unique default is less
hassle than having to write an ugly multiple-value-bind every time we
want to return a default value in the property-not-found case.  I'm not
sure I believe that any more.

-- Scott

∂20-Sep-85  0649	sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA 	Erratum on p.107Subject:     
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 20 Sep 85  06:49:52 PDT
Received: from tektronix by csnet-relay.csnet id ae04939; 20 Sep 85 9:43 EDT
From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
To: common-lisp@su-ai.ARPA
Fcc: cl-mail  
Received: from tekchips by tektronix with smtp ; 19 Sep 85 10:13:47 PDT
Date: Thursday, 19 Sep 85 10:09:07 PDT
Subject: Erratum on p.107Subject:  

On p.107 at the bottom of the page where the setq's and apply's occur:

 Replace respectively:
  (setq f '+) ... and
  (apply 'cons ...)

	BY
   (setq f #'+) ... and
   (apply #'cons ...)


This will improve consistency of syntax for function symbols.

Sridhar
...!tektronix!tekchips!sridhar

∂20-Sep-85  0651	sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA 	erratum: logic error on p.125
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 20 Sep 85  06:51:02 PDT
Received: from tektronix by csnet-relay.csnet id aa04939; 20 Sep 85 9:46 EDT
From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
To: common-lisp@su-ai.ARPA
Fcc: cl-mail  
Received: from tekchips by tektronix with smtp ; 19 Sep 85 18:03:46 PDT
Date: Thursday, 19 Sep 85 17:58:26 PDT
Subject: erratum: logic error on p.125

On p.125 about the middle of the page in the ribcage-lookup function
 in the scope of the second do:
  
  REPLACE (v (cdar r) (cdr v))) BY (v (cadar r) (cdr v)))
  [the cdar is replaced by cadar] 

∂20-Sep-85  0709	KMP@SCRC-STONY-BROOK.ARPA 	Arguments and values to get.
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Sep 85  07:08:53 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 317574; Fri 20-Sep-85 10:09:02-EDT
Date: Fri, 20 Sep 85 10:09 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Arguments and values to get.
To: Fahlman@C.CS.CMU.EDU, Gregor.pa@XEROX.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12144621737.BABYL@C.CS.CMU.EDU>
References: Msg of 19 Sep 85 19:39-EDT from Gregor.pa at Xerox.ARPA
Message-ID: <850920100928.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Thu, 19 Sep 1985  21:19 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
    To:   Gregor.pa@XEROX.ARPA
    In-reply-to: Msg of 19 Sep 1985  19:39-EDT from Gregor.pa at Xerox.ARPA

	Why does Common-Lisp GET take a default-value argument instead of
	returning a second value indicating whether the property actually
	exists?

    The default argument is useful in some cases, but admittedly is a bit
    inelegant -- if you want to know for sure whether a value was found, you
    have to be careful to choose some default argument that couldn't
    possibly be stored in any property list.  The reasoning (If I recall it
    correctly) was that this occasional creation of a unique default is less
    hassle than having to write an ugly multiple-value-bind every time we
    want to return a default value in the property-not-found case.  I'm not
    sure I believe that any more.

    -- Scott

It would be reasonable to propose a more-or-less upward-compatible extension 
to GET (for CL86 or whatever) which provided that GET both accepted a argument
specifying the default to be used -and- returned two values (one the result, 
the second a boolean saying whether the argument had been defaulted).

∂20-Sep-85  0737	DLW@SCRC-STONY-BROOK.ARPA 	erratum: logic error on p.125    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Sep 85  07:37:32 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 317626; Fri 20-Sep-85 10:37:37-EDT
Date: Fri, 20 Sep 85 10:35 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: erratum: logic error on p.125
To: sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA,
    common-lisp@SU-AI.ARPA
In-Reply-To: The message of 19 Sep 85 20:58-EDT from S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
Message-ID: <850920103525.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI

    Date: Thursday, 19 Sep 85 17:58:26 PDT
    From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>

    On p.125 about the middle of the page in the ribcage-lookup function
     in the scope of the second do:
  
      REPLACE (v (cdar r) (cdr v))) BY (v (cadar r) (cdr v)))
      [the cdar is replaced by cadar] 

I don't think so.  It appears to me that the example is correct.  Read
the text above the example carefully.  It says "...the cdr of each cons
is a list...".  That is, the elements of the top-level lists are conses,
not two-element lists.

There is, however, a picotypo in this example: the introductory text
says "...suppose that ENV holds a list of conses...", but the example
doesn't use the variable ENV anywhere.  (Do I get the "picky, picky"
award for submitting the most trivial erratum?)

∂20-Sep-85  0741	DLW@SCRC-STONY-BROOK.ARPA 	Erratum on p.107Subject:    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Sep 85  07:40:56 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 317634; Fri 20-Sep-85 10:40:00-EDT
Date: Fri, 20 Sep 85 10:37 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Erratum on p.107Subject:  
To: sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA,
    common-lisp@SU-AI.ARPA
In-Reply-To: The message of 19 Sep 85 13:09-EDT from S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
Message-ID: <850920103750.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI

    Date: Thursday, 19 Sep 85 10:09:07 PDT
    From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>

    On p.107 at the bottom of the page where the setq's and apply's occur:

     Replace respectively:
      (setq f '+) ... and
      (apply 'cons ...)

	    BY
       (setq f #'+) ... and
       (apply #'cons ...)


    This will improve consistency of syntax for function symbols.

This is not an error.  Read the textual description of "apply".  The
description explicitly mentions that you can use a symbol as the first
argument to apply, and gives some rules about doing so.  The examples
that you're referring to were included to illustrate the use of symbols
as functions.  That is, the number-signs were omitted intentionally.

∂20-Sep-85  1215	gls@THINK-AQUINAS.ARPA 	Erratum on p.107Subject:  
Received: from THINK.COM by SU-AI.ARPA with TCP; 20 Sep 85  12:15:18 PDT
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Fri, 20 Sep 85 15:16:10 edt
Date: Fri, 20 Sep 85 15:16 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Erratum on p.107Subject:  
To: sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 19 Sep 85 13:09-EDT from S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
Message-Id: <850920151620.1.GLS@JEHOSEPHAT.THINK.COM>

    Date: Thursday, 19 Sep 85 10:09:07 PDT
    From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>

    On p.107 at the bottom of the page where the setq's and apply's occur:

     Replace respectively:
      (setq f '+) ... and
      (apply 'cons ...)

	    BY
       (setq f #'+) ... and
       (apply #'cons ...)


    This will improve consistency of syntax for function symbols.

    Sridhar
    ...!tektronix!tekchips!sridhar

Thank you for your comment.  The examples are indeed inconsistent as to
style, but all are legitimate.  The cases without #' were intended to
demonstrate that it is legitimate to give a symbol to APPLY, and it will
implicitly "dereference" the symbol by looking at its global functional
value.  Some remarks to this effect shou;ld be added in the prose to
elucidate this.  Depending on one's purpose, one may wish to use ' or #'.

--Guy

∂20-Sep-85  1219	gls@THINK-AQUINAS.ARPA 	erratum: logic error on p.125  
Received: from THINK.COM by SU-AI.ARPA with TCP; 20 Sep 85  12:19:48 PDT
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Fri, 20 Sep 85 15:20:46 edt
Date: Fri, 20 Sep 85 15:20 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: erratum: logic error on p.125
To: sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 19 Sep 85 20:58-EDT from S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
Message-Id: <850920152057.2.GLS@JEHOSEPHAT.THINK.COM>

    Date: Thursday, 19 Sep 85 17:58:26 PDT
    From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>

    On p.125 about the middle of the page in the ribcage-lookup function
     in the scope of the second do:
  
      REPLACE (v (cdar r) (cdr v))) BY (v (cadar r) (cdr v)))
      [the cdar is replaced by cadar] 

Thank you for your comment.  The code as it stands is consistent with
the description in the preceding paragraph, and in particular with the
remark that the ribcage resembles an association list.

There are two styles of coding that I have observed people using in LISP
code with respect to associating lists.  One is the traditional a-list: 
	
	((A . B) (C . D) (E . F))

The other is similar, but uses 2-lists instead of dotted pairs:

	((A B) (C D) (E F))

The first saves CONS cells, but is more complicated to print.  The
second looks neater, but takes more memory space and requires extra CAR
operations to access.  I think this latter style has been promulgated by
the SCHEME community in particular.

Either is fine, but the example was intended to use the first style of
list.  Perhaps more explanation is needed for this example.

--Guy

∂20-Sep-85  1221	gls@THINK-AQUINAS.ARPA 	erratum: logic error on p.125  
Received: from THINK.COM by SU-AI.ARPA with TCP; 20 Sep 85  12:21:31 PDT
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Fri, 20 Sep 85 15:22:35 edt
Date: Fri, 20 Sep 85 15:22 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: erratum: logic error on p.125
To: DLW@SCRC-QUABBIN.ARPA, sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA,
        common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <850920103525.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <850920152246.3.GLS@JEHOSEPHAT.THINK.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI

    Date: Fri, 20 Sep 85 10:35 EDT
    From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>

    ....

    There is, however, a picotypo in this example: the introductory text
    says "...suppose that ENV holds a list of conses...", but the example
    doesn't use the variable ENV anywhere.  (Do I get the "picky, picky"
    award for submitting the most trivial erratum?)

It's as legitimate a typo as anything else.  Do I get an award for
generating the trivial error in the first place?

--Guy

∂20-Sep-85  1348	mips!escargot.earl@glacier 	Arguments and values to get.    
Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 20 Sep 85  13:48:14 PDT
Received: by glacier with Sendmail; Fri, 20 Sep 85 13:48:20 pdt
Received: from escargot.UUCP (escargot.ARPA) by mips.UUCP (4.12/4.7)
	id AA00574; Fri, 20 Sep 85 12:21:37 pdt
Received: by escargot.UUCP (4.12/4.7)
	id AA09473; Fri, 20 Sep 85 13:05:36 pdt
Date: Fri, 20 Sep 85 13:05:36 pdt
From: mips!escargot.earl@glacier (Earl Killian)
Message-Id: <8509202005.AA09473@escargot.UUCP>
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: "Scott E. Fahlman"'s message of Thu, 19 Sep 1985  21:19 EDT
Subject: Arguments and values to get.

When you really need to know whether the value was present in the
property list or not, I agree that the &OPTIONAL default argument to
GET is painful.  Other times, however, it is exactly what you want
(you really just want a default value), and implementing the default
from a second return value is painful.  Thus the current definition
is not a mistake, although it may not be featureful enough.

∂20-Sep-85  1702	FAHLMAN@C.CS.CMU.EDU 	EQUAL isn't really correct, I agree   
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 Sep 85  19:37:44 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 17 Sep 85 22:38:35-EDT
Date: Tue, 17 Sep 1985  22:38 EDT
Message-ID: <FAHLMAN.12144111807.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Rem@MIT-MC.ARPA
Cc:   COMMON-LISP@SU-AI.ARPA
Subject: EQUAL isn't really correct, I agree
Comment: Remailed at SU-AI after delay caused by distribution list problem.


    Once this super-general function is properly defined and implemented,
    special cases can be described in a uniform way as canned arguments to
    this function, and then can be handcoded more efficiently if desired.

    In many cases there are oodles of special-case functions and nothing
    properly general in CL currently. Perhaps general functions should be
    defined and some of the special cases flushed, as such cases are recognized?
    Super-general-EQUAL could be the first such super-general function?

Gee, maybe we should provide COND and DEFMACRO and let the user code up
whatever equality predicate he really wants.  Would that be general
enough?  Oops, we did that already...

But seriously, it is a very serious step to put in some piece of
special-purpose programmable mechanism for some random part of the
language.  This might be called for in the case of iteration (if we
could ever agree on a syntax for something like the loop macro), but I
can't see any compelling reason to put in yet another load of hair for a
customizable equality predicate.  If there are kinds of equality that
are FREQUENTLY needed and are not currently provided (and I think there
are a couple) we should consider adding these, but let's not go
overboard (yet again).

-- Scott

∂20-Sep-85  2312	GSB@MIT-MC.ARPA 	Modification to LISTEN 
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 20 Sep 85  23:12:17 PDT
Date: Sat, 21 Sep 85 02:12:53 EDT
From: Glenn S. Burke <GSB@MIT-MC.ARPA>
Subject: Modification to LISTEN
To: robbins@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].653117.850921.GSB>

Aside from some already mentioned reasons, one can always do

(defun listen (&optional (input-stream *standard-input*))
  (let ((char (read-char-no-hang stream nil nil)))
    (cond ((null char) nil)
	  (t (unread-char char) t))))

instead of the other way around, without changing the definition of
anything.

∂21-Sep-85  0729	robbins@DEC-HUDSON 	LISTEN Proposal
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 21 Sep 85  07:29:05 PDT
Date: Sat, 21 Sep 85 10:31:45 EDT
From: robbins@DEC-HUDSON
Subject: LISTEN Proposal
To: common-lisp@su-ai
Cc: GSB@MIT-MC

Obviously there is no pressing need to do anything to the current 
definition of LISTEN.  However, I think that it is kind of strange to 
have a pair of similar functions whose definitions are just inconsistent 
enough so that the "intuitive" implementation of one fails.

	... one can always do

	(defun listen (&optional (input-stream *standard-input*))
	  (let ((char (read-char-no-hang stream nil nil)))
	    (cond ((null char) nil)
		  (t (unread-char char) t))))

I agree that this will work just fine.  Am I the only one who objects to
the extra IO implicit in this definition?  

From the definition of READ-CHAR-NO-HANG CLtL page 380:

	"LISTEN does not distinguish between end-of-file and no
	 input being available, whereas READ-CHAR-NO-HANG does
	 make that distinction returning EOF-VALUE at end-of-file ..."

Is there a good reason for this seemingly gratuitous inconsistency in 
the language?

∂21-Sep-85  1350	edsel!jim@su-navajo.arpa 	listen, etc.  
Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 21 Sep 85  13:50:13 PDT
Received: by su-navajo.arpa with Sendmail; Sat, 21 Sep 85 13:47:40 pdt
Received: by edsel.uucp (2.0/SMI-2.0)
	id AA28888; Sat, 21 Sep 85 13:41:51 pdt
Date: Sat, 21 Sep 85 13:41:51 pdt
From: edsel!jim@su-navajo.arpa (Jim McDonald)
Message-Id: <8509212041.AA28888@edsel.uucp>
To: navajo!common-lisp@su-ai
Subject: listen, etc.


CLtL currently says "The predicate LISTEN is true if there is a
character immediately available from input-stream, and false if not."

This precludes any reasonable use for LISTEN on non-character streams,
which seems to me to be a flaw.  It is not hard to imagine a program that
loads binary data from a network while carrying on other tasks (like 
responding to the user!) during the pauses between arrival of packets.
There might even be non-character, non-byte streams that act as pipes
or queues of complex objects.  It would be useful if LISTEN could be
used to poll arbitrary input streams, even if many such applications
might be handled better by interrupt-driven routines.

Are there any objections to changing the definition to say "The predicate
LISTEN is true if a transaction datum is immediately available from
input-stream, and false if not."?

Note that with this revised definition, READ-CHAR-NO-HANG and potential,
analogous, routines such as READ-BYTE-NO-HANG would be too specialized
to define LISTEN.  Thus as long as the change I propose is not completely
ruled out, it would be premature to define LISTEN in terms of 
READ-CHAR-NO-HANG.

---

In a similar vein, the book groups CLEAR-INPUT among those routines that
act on character streams, but the definition itself does not seem to imply
that the stream must be a character stream.  Likewise, FINISH-OUTPUT, 
FORCE-OUTPUT, and CLEAR-OUTPUT are grouped with functions on character
streams, but seem to be reasonable for arbitrary output streams.
I propose that such routines should work for all streams with the 
appropriate direction.  Could someone involved with their definition
clarify this?

---

Would READ-DATUM, PEEK-DATUM, READ-DATUM-NO-HANG, and UNWRITE-DATUM be
appropriate stream functions, with -CHAR- and -BYTE- forms available for
clarity and/or efficiency?  

---

Finally, have there been any proposals for mechanisms to create
non-character, non-byte streams, and if not, is it due to lack of 
interest or lack of agreement?  I think a good queueing primitive
would find many uses.

  Jim McDonald



∂22-Sep-85  1814	GJC@MIT-MC.ARPA 	Lisp Test    
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Sep 85  18:14:30 PDT
Date: Sun, 22 Sep 85 21:15:09 EDT
From: George J. Carrette <GJC@MIT-MC.ARPA>
Subject: Lisp Test
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].654263.850922.GJC>

Here are some questions I'm thinking about putting into a lisp teasers
test. In order so that I can get an idea of how difficult the questions
are, please reply with your answers. Take no longer than 4 minutes.

What are the return values of the following expressions when evaluated:
[1] (let ((x (list nil))) (car x))
[2] (let ((x (list nil))) (setf (car x) 5) (car x))
[3] (flet ((g () 5)) (g))
[4] (flet ((g () 5)) (setf #'g #'(lambda () 7)) (g))


∂22-Sep-85  1846	FAHLMAN@C.CS.CMU.EDU 	Lisp Test    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Sep 85  18:45:05 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 22 Sep 85 21:46:04-EDT
Date: Sun, 22 Sep 1985  21:46 EDT
Message-ID: <FAHLMAN.12145412963.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   "George J. Carrette" <GJC@MIT-MC.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Lisp Test
In-reply-to: Msg of 22 Sep 1985  21:15-EDT from George J. Carrette <GJC at MIT-MC.ARPA>


    [1] (let ((x (list nil))) (car x))				nil
    [2] (let ((x (list nil))) (setf (car x) 5) (car x))		5
    [3] (flet ((g () 5)) (g))					5
    [4] (flet ((g () 5)) (setf #'g #'(lambda () 7)) (g))	error

The error is "FUNCTION not a SETF-able form." or words to that effect.
If in 4 you meant to setf (symbol-function 'g), then the answer is 5.

-- Scott

∂22-Sep-85  1848	FAHLMAN@C.CS.CMU.EDU 	Lisp Test -- oops!
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Sep 85  18:46:32 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 22 Sep 85 21:47:25-EDT
Date: Sun, 22 Sep 1985  21:47 EDT
Message-ID: <FAHLMAN.12145413212.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   "George J. Carrette" <GJC@MIT-MC.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Lisp Test -- oops!
In-reply-to: Msg of 22 Sep 1985  21:15-EDT from George J. Carrette <GJC at MIT-MC.ARPA>


Sorry, I meant to send that just to GJC and not to the whole list, but I
hit the wrong key.  Hope I didn't spoil the fun.

-- Scott

∂23-Sep-85  1131	DDYER@SCRC-QUABBIN.ARPA 	Lisp Test 
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 23 Sep 85  11:31:38 PDT
Received: from WHITE.SWW.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 204097; Mon 23-Sep-85 14:31:34-EDT
Received: from SWW-PURPLE by SWW-WHITE via CHAOS with CHAOS-MAIL id 139578; Mon 23-Sep-85 11:36:30-PDT
Date: Mon, 23 Sep 85 11:33 PDT
From: DDYER@SCRC-RIVERSIDE.ARPA
Subject: Lisp Test
To: George J. Carrette <GJC@MIT-MC.ARPA>, common-lisp@SU-AI.ARPA
Fcc: W:>ddyer>mail.sent
In-Reply-To: <[MIT-MC.ARPA].654263.850922.GJC>
Message-ID: <850923113338.7.DDYER@PURPLE.SWW.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI

    Date: Sun, 22 Sep 85 21:15:09 EDT
    From: George J. Carrette <GJC@MIT-MC.ARPA>

    Here are some questions I'm thinking about putting into a lisp teasers
    test. In order so that I can get an idea of how difficult the questions
    are, please reply with your answers. Take no longer than 4 minutes.

    What are the return values of the following expressions when evaluated:
    [1] (let ((x (list nil))) (car x))
nil
    [2] (let ((x (list nil))) (setf (car x) 5) (car x))
5
    [3] (flet ((g () 5)) (g))
5
    [4] (flet ((g () 5)) (setf #'g #'(lambda () 7)) (g))
7
Except, it actually returns 5, and the global function (g) returns 7.
This has to be a bug.

∂23-Sep-85  1425	gls@THINK-AQUINAS.ARPA 	Public relations: second time around
Received: from THINK.COM by SU-AI.ARPA with TCP; 23 Sep 85  14:25:05 PDT
Received: from sebastian by GODOT.THINK.COM via CHAOS; Mon, 23 Sep 85 17:26:11 edt
Date: Mon, 23 Sep 85 17:25 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Public relations: second time around
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <850923172551.4.GLS@SEBASTIAN.THINK.COM>

This is a retransmission of an earlier note requesting information on
Common Lisp implementations.  So far I have gotten NO replies.  Am I to
assume that no one wants to be mentioned when I talk in Japan?

I could make up a list without any help, but it would probably have
holes and stale information in it.  I really do want to use accurate
information, but I need this information by Thursday, September 26, to
be useful.  Please help me out.

--Thanks, 
  Guy
----------------------------------------------------------------------
I am seeking summary data about existing Common Lisp implementations.

I am planning to travel to Japan in October and give seminars there
about Common Lisp.  (This is in connection with the recent publication
of the Japanese translation by Dr. Masayuki Ida of the Common Lisp
manual.)  While most of the content will be technical, I will surely be
asked about existing implementations, particularly those in the United
States.  I would like to be accurate and complete, and so I need your
help.

If you are supporting an implementation of Common Lisp (or a subset),
could you please send me the following information about it?

(1) Name of implementation
(2) Name of support organization (implementor, vendor, or whatever)
(3) Hardware configuration(s) and operating system(s)
(4) Available now?  If not, when?
(5) Full Common Lisp or subset?
(6) If a subset, what's missing?  Will missing parts be implemented later?
(7) (optional) Address of support organization or other contact
(8) (optional) Any interesting language extensions or
	   applications packages you want mentioned?

This won't be a sales presentation, and I won't recommend any
implementation over any other, so I'm not interested in prices.
(Actually, I am, but if you send me price information I won't use it in
these seminars.)  I intend simply to present a list, both on overhead
transparencies during my talk and in hardcopy form.  I think it would
give Common Lisp a boost to have a nice long list of implementors to
show off.

I have also requested my contacts in Japan to prepare a similar list of
Japanese implementations, and I will report any information received to
this mailing list.

Thank you for your help.

--Guy

∂24-Sep-85  2129	RPG  	Meeting  
To:   common-lisp@SU-AI.ARPA
It being a year since the last Common Lisp Meeting, I would like to
propose a second meeting. To be accurate, DARPA has suggested that
someone ought to propose a second meeting. I think we are in a position
to finally settle the following questions:

	1) How shall the charter be constructed for Common Lisp?

	2) Are we all agreed that the minor changes to Common Lisp,
	   especially the errata, are to be part of the Common Lisp
	   standard?

	3) Shall we adopt an error handling facility?

I think we can have reasonable discussions on the following:

	1) How shall windows be handled?

	2) Shall we agree to experiment with CommonLoops (appropriately
	   named) as the object-oriented programming paradigm?

There are several new topics that deserve discussion:

	1) What shall be our approach to ANSI standardization.

	2) How shall we handle changes to the Common Lisp book?
	   (This topic includes copyright questions that have come up).

I have some thoughts as to the organization of the meeting and other
administrative details. First, the meeting would best be held on the East
Coast - it was held in Monterey, California last year.  Second, attendance
should be limited to 2 or 3 representatives from each organization. This
rule will help us to keep the discussions from getting out of control.  I
would be willing to let more people attend the meeting, but restrict
commentary to a small number of people. If only 2 people are allowed, we
should probably leave the actual decisions to a written ballot after the
meeting, with advisory votes at the meeting.

Third, the meeting should be held at a location that is easily accessible.
Several possibilities that come to mind are Washington, New York, and
Boston.  Fourth, I think that the meeting should be held towards the end
of November, so that there is plenty of time to arrange schedules.  Fifth,
I think we should decide on the above before the end of September.

Please mail to me (RPG@SAIL) your responses to these ideas, and I will
attempt to coalesce them into some sort of decision or into a condensed
set of issues for all of us to consider - I want to keep the discussion
about the meeting streamlined.

			-rpg-

∂24-Sep-85  2359	TIM@MIT-MC.ARPA 	Lisp Test    
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 24 Sep 85  23:57:56 PDT
Date: Wed, 25 Sep 85 02:59:30 EDT
From: Tim McNerney <TIM@MIT-MC.ARPA>
Subject:  Lisp Test
To: GJC@MIT-MC.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-reply-to: Msg of Sun 22 Sep 85 21:15:09 EDT from George J. Carrette <GJC at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].658760.850925.TIM>

    Date: Sun, 22 Sep 85 21:15:09 EDT
    From: George J. Carrette <GJC at MIT-MC.ARPA>

    [4] (flet ((g () 5)) (setf #'g #'(lambda () 7)) (g))

George,

I had been wondering about this for a while.  I thought that FUNCTION
might be magic, but (SETF (FUNCTION ...) ...) does not appear to be
defined in CLtL.  Perhaps you meant to use SYMBOL-FUNCTION instead.
If so, it would indeed make a good teaser for testing to see if people
had carefully read page 90.

Folks,

Does Common Lisp provide any way to side effect "lexical function cells"
such as G above?

∂25-Sep-85  0946	KESSLER@UTAH-20.ARPA 	Argument Type Mismatch Errors    
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 25 Sep 85  09:46:08 PDT
Date: Wed 25 Sep 85 10:46:19-MDT
From: Robert R. Kessler <KESSLER@UTAH-20.ARPA>
Subject: Argument Type Mismatch Errors
To: common-lisp@SU-AI.ARPA
Message-ID: <12146101145.24.KESSLER@UTAH-20.ARPA>

Is there any agreement as to what a CL system should do when a type
error occurs?  What I am thinking about are things like append, which
specifies that all arguments (except) the last are to be lists.  If one
element is not a list should an error occur?  In Hedrick's Dec-20 CL, it
does cause an error.  Since the standard doesn't say that an error is
required, couldn't one write a legal implementation of CL where it ignores
the offending argument?  Along similar lines is our PCLS implementation of the
package system.  Packages are implemented as defstructs, so if a non
package argument is passed to a function that expect the package, our
system currently causes an error as it tries to access a field in the
defstruct (defstructs are vectors so the error message says something like
illegal to index non vector `bar').  At least in this case it gets an error,
although one that could be confusing to the programmer.  [The obvious
reason for not type checking that the argument is in fact a package
defstruct is because of efficiency.]

Thanks.
Bob.
-------

∂25-Sep-85  1132	smh@mit-ems.ARPA 	Re:  Argument Type Mismatch Errors   
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 25 Sep 85  11:31:16 PDT
Received: by mit-ems.ARPA (4.12/4.8)  id AA07704; Wed, 25 Sep 85 14:31:20 edt
Date: Wed, 25 Sep 85 14:31:20 edt
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8509251831.AA07704@mit-ems.ARPA>
To: KESSLER@UTAH-20.ARPA, common-lisp@SU-AI.ARPA
Subject: Re:  Argument Type Mismatch Errors

	From: Robert R. Kessler <KESSLER@UTAH-20.ARPA>
	Subject: Argument Type Mismatch Errors
	
	Since the standard doesn't say that an error is required,
	couldn't one write a legal implementation of CL where it
	ignores the offending argument?

CLtL section 1.2.4 (pg.5) precisely defines what is required of an
implementation.  The short answer to your question is, yes, you can
write a valid CL with an append that ignores invalid arguments, but you
*cannot* write a valid CL program that exploits this behaviour!

Unofficially:  An implementation obviously should detect and signal
errors when convenient.  The primary force against always doing so is
run-time efficiency.  Personally, I feel that once an implementation
detects an error such as an inappropriate argument type, it should
always signal the error rather than silently proceeding.  There's no
reason not to signal the error, assuming the price of detecting it has
already been paid.

∂25-Sep-85  1153	smh@mit-ems.ARPA 	missing function: typep-type-p  
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 25 Sep 85  11:53:05 PDT
Received: by mit-ems.ARPA (4.12/4.8)  id AA07882; Wed, 25 Sep 85 14:53:27 edt
Date: Wed, 25 Sep 85 14:53:27 edt
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8509251853.AA07882@mit-ems.ARPA>
To: common-lisp@su-ai
Subject: missing function: typep-type-p

It is an error if the "typep" and "subtypep" functions are passed
something other than a valid type specifier.  The set of valid type
specifiers is extensible by defstruct (and possibly by some proposed
active object extensions).  However, there appears to be no way to
determine if an arbitrary expression is a valid second argument to
typep (or declaration type, or first argument to the "the" special
form).  Sometimes one might need to know -- for instance, to determine
if a "foo" defstruct has ever been defined.  I can think of no
non-implementation-dependent way to find out.  By the way, typep is not
required to signal an error if passed an invalid type specifier, so it
might return t, or nil, or whatever.

I suggest a new predicate with an ugly name:

	typep-type-p expr				[Function]

	The expr can be anything at all, and this predicate is true
	iff expr is a valid type specifier in the current Lisp world.

∂25-Sep-85  1438	gls@THINK-AQUINAS.ARPA 	Public relations: data so far  
Received: from THINK.COM by SU-AI.ARPA with TCP; 25 Sep 85  14:38:21 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Wed, 25 Sep 85 17:39:13 edt
Date: Wed, 25 Sep 85 17:39 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Public relations: data so far
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <850925173916.5.GLS@DESIDERIUS.THINK.COM>

I have collated the data given to me so far about Common Lisp
implementations and have put it into a more-or-less standardized format.
The data appears at the end of this message.  Some of the information
was so incomplete that I could not include it here (though that same
information was useful in giving me leads to chase down further).

Implementations that I believe to exist in some form but that are not
given below, and which I would like to have data on: DEC VAX LISP; Data
General; Texas Instruments for Explorer; Intermetrics for IBM 370;
Symbolics; LMI; Franz, Inc., for machines other than Tektronix; Gold
Hill for IBM PC; MIT NIL for VAX.  Please send data if you can!

Thanks to all who have responded.  Can you please check my summaries
for accuracy and completeness?

Some respondents sent rather long descriptions that are very interesting
but won't fit on a slide.  I would be happy to redistribute these long
responses to this mailing list, but perhaps it would be more appropriate
for the original senders to do so if they wish.  (One or two messages
contained some data that might be sensitive in the near future, and so I
don't want to redistribute the messages wholesale without permission.)

--Guy

----------------------------------------------------------------
The data given in my talk will be preceded by a notice such
as the following:

The following Common Lisp implementation data is
provided for purposes of information only.  It is
accurate and complete to the best of my knowledge,
but I (Guy Steele) cannot guarantee that it is
correct.  I do not speak for or represent the
implementors and vendors in any way.  If you wish
further information, please contact the vendors at
the addresses given.
----------------------------------------------------------------
[I realize that the formatting is ugly.  I am going to fix it up using
TeX or something.]


Name: Portable Common Lisp Subset (PCLS, ``pickles'')
Supported by: University of Utah
Hardware and operating system: Sun, Apollo, HP, Vax/VMS, Vax/Unix, Dec-20, IBM-370/CMS, Cray, Gould
Availability: Spring 1986
Full language or subset: subset
Missing features: rational and complex numbers, characters, closures.
Remarks: PCLS is a subset of Common Lisp that will run in any PSL implementation.
Contact:
Prof. Robert R. Kessler
3160 M.E.B.
Department of Computer Science
University of Utah
Salt Lake City, Utah   84112
USA


Name: Gould Common Lisp
Supported by: Gould Electronics, Computer Systems Division
Hardware and operating system: Gould Powernode 9000 and 6000 series with UTX-32 (UNIX 4.2BSD with System V enhancements)
Availability: 1986
Full language or subset: full
Remarks: Ability to call C and Fortran functions from within Lisp.
Contact: 
International Sales and Marketing
Gould Computer Systems Division
6901 W. Sunrise Blvd.
Fort Lauderdale, Florida  33313
USA


Name: Hewlett Packard Development Environment for Common Lisp
Supported by: Hewlett Packard, Fort Collins Systems Division
Hardware and operating system: HP 9000 models 310 (68010-based) and 320 (68020-based) with HP-UX (UNIX System V plus Berkeley enhancements)
Availability: January 1986
Full language or subset: full
Remarks: EMACS-like editor with browsers.  Support for object-oriented programming.
Not based on CMU implementation.
Contact:
Mike Bacco, AI Products Manager (marketing) or Roger Ison, Project Manager (technical)
Ft. Collins Systems Division
Hewlett Packard Company
Ft. Collins, Colorado  80525
USA
(303) 226-3800


Name: TekCommonLisp
Implemented by:  Tektronix, Inc., in conjunction with Franz, Inc.
Supported by: Tektronix, Inc.
Hardware and operating system: Tektronix 4404 (68010-based), 4405, 4406 (68020-based)
Availability: First quarter 1986
Full language or subset: full
Remarks: Flavors, calls to functions in other programming languages, Lisp structure editor, and other utilities.
Contact: 
Mike Taylor
Marketing Manager
Artificial Intelligence Machines Group
Tektronix Inc.
PO Box 1000, MS 60-405
Wilsonville, Oregon  97070
USA  
(503) 685-2942

Franz, Inc.
1141 Harbor Bay Parkway,
Alameda, California  94501
USA
(415) 769-5656.


Name: ETI Lisp (formerly called Spice Lisp)
Implemented by: Carnegie-Mellon University
Supported by: Expert Technologies, Inc.
Hardware and operating system: PERQ with Accent version S6 (release 2)
Availability: now
Full language or subset: subset
Missing features: complex numbers
Remarks: Flavors, remote process spawning, remote procedure calls, HEMLOCK (EMACS-like editor).
Contact: 
Joseph R. Ginder
Expert Technologies, Inc.
461 Melwood Avenue
Pittsburgh, Pennsylvania  15213
USA

For the UK and Europe:
Roger Vinnecombe
Advent, Ltd.
12 The Business Centre
Molley Millars Lane
Wokingham, Berkshire
RG11 2RT
ENGLAND    


Name: Sun Common Lisp
Implemented by: Lucid, Inc.
Supported by: Sun
Hardware and operating system: Sun workstation (68xxx-based) with UNIX
Availability: December 1985 (in USA)
Full language or subset: full
Remarks: Calls to functions in other programming languages.
By August 1986 are expected editor, windows, object-oriented programming.
Contact: 
???

Name: Apollo Common Lisp
Implemented by: Lucid, Inc.
Supported by: Apollo
Hardware and operating system: Apollo workstation (68xxx-based) with Aegis and DomainIX
Availability: January 1986 (in USA)
Full language or subset: full
Remarks: Calls to functions in other programming languages.
By August 1986 are expected editor, windows, object-oriented programming.
Contact: 
???

Name: Prime Common Lisp
Implemented by: Lucid, Inc.
Supported by: Prime
Hardware and operating system: Prime 50 series with Primos (IX mode)
Availability: to be determined
Full language or subset: full
Remarks: Calls to functions in other programming languages.
By August 1986 are expected editor, object-oriented programming.
Contact: 
???

Name: Symbolics Cross Compiler for Sun and Apollo
Implemented by: Lucid, Inc.
Supported by: Symbolics, Inc.
Hardware and operating system: Symbolics 3600
Availability: March 1986
Full language or subset: full
Contact: 
???

    
Name: T
Implemented by: Yale University
Supported by: unsupported
Hardware and operating system: Apollo (68000-based), VAX with UNIX, VAX with VMS
Availability: now
Full language or subset: incompatible subset
Missing features: DEFUN, FUNCTION, arrays, sequences, packages, and others
No plans to implement missing features.
Remarks: T is more closely related to SCHEME than to Common Lisp.
Features include tail recursion, single function/variable namespace, lexical environments
used instead of packages, LAMBDA special form, NIL is different from ().
Contact: 
Jim Philbin
Yale University
New Haven, Connecticut  06520
USA
Philbin-Jim@Yale.ARPA

∂25-Sep-85  1535	JAR@MIT-MC.ARPA 	Public relations: data so far    
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 25 Sep 85  15:35:17 PDT
Date: Wed, 25 Sep 85 18:36:54 EDT
From: Jonathan A Rees <JAR@MIT-MC.ARPA>
Subject:  Public relations: data so far
To: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Wed 25 Sep 85 17:39 EDT from Guy Steele <gls at THINK-AQUINAS.ARPA>
Message-ID: <[MIT-MC.ARPA].659546.850925.JAR>

Lest anyone be confused about the appearance of T in Guy's list of
Common Lisps, I just want to make sure people realize that it was a
joke.  I intended it to be a cynical comment on the vacuity of the
concept of "extended subset".

Jonathan

∂25-Sep-85  1844	Moon@SCRC-STONY-BROOK.ARPA 	Lisp Test   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 25 Sep 85  18:44:19 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 321222; Wed 25-Sep-85 21:39:26-EDT
Date: Wed, 25 Sep 85 21:39 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Lisp Test
To: Tim McNerney <TIM@MIT-MC.ARPA>
cc: GJC@MIT-MC.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: <[MIT-MC.ARPA].658760.850925.TIM>
Message-ID: <850925213949.3.MOON@NEPONSET.SCRC.Symbolics.COM>

    Date: Wed, 25 Sep 85 02:59:30 EDT
    From: Tim McNerney <TIM@MIT-MC.ARPA>

	Date: Sun, 22 Sep 85 21:15:09 EDT
	From: George J. Carrette <GJC at MIT-MC.ARPA>

	[4] (flet ((g () 5)) (setf #'g #'(lambda () 7)) (g))
    ...(SETF (FUNCTION ...) ...) does not appear to be
    defined in CLtL.  Perhaps you meant to use SYMBOL-FUNCTION instead.

    Does Common Lisp provide any way to side effect "lexical function cells"
    such as G above?

No.  They are constants.  (More accurately, they take on a new value every
time the FLET is evaluated, but you can't change their value.)

∂25-Sep-85  1845	Moon@SCRC-STONY-BROOK.ARPA 	Returning additional values from advertised functions    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 25 Sep 85  18:45:46 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 321231; Wed 25-Sep-85 21:46:07-EDT
Date: Wed, 25 Sep 85 21:46 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Returning additional values from advertised functions
To: MLY@OZ.MIT
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <12144601298.71.MLY@MIT-OZ>
Message-ID: <850925214630.4.MOON@NEPONSET.SCRC.Symbolics.COM>

    Date: Thu 19 Sep 85 19:27:24-EDT
    From: Richard Mlynarik
    I have been inconvenienced several times recently by the fact the
    multiple-value-setq is not multiple-value-setf.  This is a somewhat
    curious shortcoming, especially now that the All-New Fashion in lisp
    code seems to be to entirely eschew setq in favour of setf.

(multiple-value-setq (a b c) (foo))
and
(setf (values a b c) (foo))
are identical, and the latter allows you to put the values into other
places besides variables.  The latter form is not standard Common Lisp,
but it should be.

∂25-Sep-85  1901	Moon@SCRC-STONY-BROOK.ARPA 	go and return-from inside unwind-protect cleanup    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 25 Sep 85  19:00:36 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 321241; Wed 25-Sep-85 22:00:55-EDT
Date: Wed, 25 Sep 85 22:01 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: go and return-from inside unwind-protect cleanup
To: Guy Steele <gls@THINK-AQUINAS.ARPA>
cc: DCP@SCRC-QUABBIN.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: <850909130121.2.GLS@IGNATIUS.THINK.COM>
Message-ID: <850925220118.5.MOON@NEPONSET.SCRC.Symbolics.COM>

    Date: Mon, 9 Sep 85 13:01 EDT
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>

	Date: Mon, 9 Sep 85 09:43 EDT
	From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>

	Are the following legal?

		(defun foo (go-p)
		  (prog nil
		     tag
			(unwind-protect
			    (return (compute))
			  (if go-p (go tag)))))

		(defun bar (return-p)
		  (prog nil
		     tag
			(unwind-protect
			    (progn (compute)
				   (go tag))
			  (if return-p (return nil)))))

    I regard both of these as completely legal.

While they may be legal and implementable, I feel that this programming
style should be strongly discouraged.  For one thing, it can be
rather difficult to stop the execution of (FOO T), since any attempt
to THROW out of it will simply cause it to re-enter its infinite loop.

∂25-Sep-85  1914	RAM@C.CS.CMU.EDU 	Discouraged programming practices    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 25 Sep 85  19:11:31 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Wed 25 Sep 85 22:12:38-EDT
Date: Wed, 25 Sep 1985  22:12 EDT
Message-ID: <RAM.12146204226.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: Discouraged programming practices


Another discouraged programming practice is to write

    (without-interrupts (loop))

as it may be difficult to terminate the execution of this form.
WITHOUT-INTERRUPTS is not a part of Common-Lisp, but it should be.

:-)?

  Rob

∂26-Sep-85  0100	STEINER@BLUE.RUTGERS.EDU 	More corrections to CLtL
Received: from BLUE.RUTGERS.EDU by SU-AI.ARPA with TCP; 26 Sep 85  01:00:06 PDT
Date: 26 Sep 85 04:00:01 EDT
From: Dave <Steiner@BLUE.RUTGERS.EDU>
Subject: More corrections to CLtL
To: common-lisp@SU-AI.ARPA
Reply-To: Steiner@Rutgers


I've found several printing bugs in the format chapter.

1) The code on p. 394 to show the scale factor doesn't work.  It
should be something like:

(dotimes (k 13)
  (format t "~%Scale factor ~2D:~:* |~13,6,2,VE|"
          (- k 5) 3.14159))

Ie, Missing % at the beginning and a missing ~:* to back up to the
scale factor again (or add (- k 5) as a third arg in the second
position and don't include the ~:*).

2) The output to this code with scale factor of 7 is missing a 0 after
the decimal point.  Ie.  |3141590.0E-06|, not | 3141590.E-06|.

3) The format expr in the function definition of FOO (on p 396) is
missing a 4th x arg.

ds
uucp:   ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!steiner
arpa:   Steiner@RUTGERS
-------

∂26-Sep-85  0404	smh@mit-ems.ARPA 	CLtL ambiguity in trace    
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 26 Sep 85  04:03:27 PDT
Received: by mit-ems.ARPA (4.12/4.8)  id AA12169; Thu, 26 Sep 85 07:03:50 edt
Date: Thu, 26 Sep 85 07:03:50 edt
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8509261103.AA12169@mit-ems.ARPA>
To: common-lisp@sail
Subject: CLtL ambiguity in trace

The description on page 440:

	trace {function-name}*				[Macro]

	Invoking trace with one or more function names (symbols)
	causes the functions named to be traced.  Henceforth,
	whenever such a function is invoked ...

It is unclear whether the named function may legally be a macro.
This obviously-useful feature should not cause problems for any
implementation.  It should be required, and the manual clarified.

∂26-Sep-85  0432	bs%hp-mars.csnet@CSNET-RELAY.ARPA 	disassemble and compile questions  
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 26 Sep 85  04:31:55 PDT
Received: from hplabs by csnet-relay.csnet id af16310; 26 Sep 85 7:24 EDT
Received: by HP-VENUS id AA00218; Wed, 25 Sep 85 16:51:09 pdt
Message-Id: <8509252351.AA00218@HP-VENUS>
Date: Wed, 25 Sep 85 16:35:06 pdt
From: Bob Shaw <bs%hplabs.csnet@CSNET-RELAY.ARPA>
Received: by HP-MARS id AA24583; Wed, 25 Sep 85 16:35:06 pdt
To: common-lisp@su-ai.arpa
Subject: disassemble and compile questions
Cc: bs@hplabs.CSNET
Source-Info:  From (or Sender) name not authenticated.

I'm in need of enlightenment.  The answers to the following two
questions are not obvious from my readings of the book.

   1.  If f is an interpreted function, does (disassemble 'f) 
       cause f to become a compiled function?

   2.  What is the appropriate way to compile a function object
       that is not compiled, not a lambda-expression and not the
       function definition for a symbol?  Consider the "lexical
       closure" example in section 2.13 of CLtL.

More on 1:  
  According to CLtl section 25.1, in the definition of disassemble,
  "The argument should be either a function object, a lambda-expression,
   or a symbol with a function definition.  If the relevent function is
   not a compiled function, it is first compiled.  ... This is primarily
   useful for debugging the compiler ... ."  
  Side-effecting the function cell by disassembling does not seem like
  a result I would desire, especially when debugging the compiler.
  Is (compile 'symbol) or (compile nil (symbol-function 'symbol)) the
  intended means of compilation?
  
More on 2:
  The definition of compile states that it will only handle lambda-
  expressions: "If definition is supplied, it should be a lambda-expression,
  the interpreted function to be compiled.  If it is not supplied, then
  name should be a symbol with a definition that is a lambda-expression;
  ... ."  Section 2.13 states that lists other than lambda expessions
  may, in certain implementations, serve as functions.  Should the 
  definition of compile include such cases?  I hope so.


Thanks.

∂26-Sep-85  0501	smh@mit-ems.ARPA 	CLtL error re function special form  
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 26 Sep 85  05:01:04 PDT
Received: by mit-ems.ARPA (4.12/4.8)  id AA12317; Thu, 26 Sep 85 08:01:25 edt
Date: Thu, 26 Sep 85 08:01:25 edt
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8509261201.AA12317@mit-ems.ARPA>
To: common-lisp@sail
Subject: CLtL error re function special form

Surely this must have been noticed before, but on page 87:

	function fn				[Special Form]

	The value of function is always the functional interpretation
	of fn;  fn is interpreted as if it had appeared in the
	functional-position of a function invocation.  In particular,
	if fn is a symbol, the functional definition associated with
	that symbol is returned;  see symbol-function.  If fn is a
	lambda-expression ...

Unlike the function special form, symbol-function does not see lexical
function bindings.  The reference to symbol-function here was probably
intended just to convey the distinction between a symbol's `functional'
interpretation and it's `regular' i.e. symbol-value interpretation.
But it's wrong, and potentially misleading.

Fixing the text is awkward because lexical function binding special
forms are not presented until p.113.  But CLtL is more of a reference
than a teaching manual.  Perhaps the reference to symbol function
should just be deleted.

A similar but less bothersome slip occurs on p.32 about functional data
types:

	   A symbol may serve as a function;  an attempt to invoke a
	symbol as a function causes the contents of the symbol's
	function cell to be used.  See symbol-function and defun.

∂26-Sep-85  0728	gls@THINK-AQUINAS.ARPA 	Joke  
Received: from THINK.COM by SU-AI.ARPA with TCP; 26 Sep 85  07:27:52 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Thu, 26 Sep 85 10:29:02 edt
Date: Thu, 26 Sep 85 10:29 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Joke
To: JAR@MIT-MC.ARPA
Cc: gls@THINK-AQUINAS.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <[MIT-MC.ARPA].659523.850925.JAR>
Message-Id: <850926102903.1.GLS@DESIDERIUS.THINK.COM>

    Date: Wed, 25 Sep 85 18:14:16 EDT
    From: Jonathan A Rees <JAR@MIT-MC.ARPA>

    It was a joke, Guy.

Sure fooled me.  I figured you just wanted people to know about T as
well as various Common Lisps.  If you were willing to send the data, I
was willing to include it.

∂26-Sep-85  0744	AS%hp-hulk.csnet@CSNET-RELAY.ARPA 	Re: missing function: typep-type-p 
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 26 Sep 85  07:44:50 PDT
Received: from hplabs by csnet-relay.csnet id ab17614; 26 Sep 85 10:41 EDT
Received: by HP-VENUS id AA26541; Thu, 26 Sep 85 07:16:13 pdt
Message-Id: <8509261416.AA26541@HP-VENUS>
Date: Thu 26 Sep 85 07:16:07-PDT
From: Alan Snyder <AS%hplabs.csnet@CSNET-RELAY.ARPA>
Subject: Re: missing function: typep-type-p
To: smh
Cc: common-lisp@su-ai.arpa
In-Reply-To: Message from "Steven Haflich <smh@MIT-EMS@HP-VENUS>" of Thu 26 Sep 85 01:38:35-PDT
Source-Info:  From (or Sender) name not authenticated.

I agree with the desirability of a predicate for testing legal
type specifiers.  I would call it TYPE-SPECIFIER-P, however.

One might also wish to find out more information about a type
specifier, such as whether it is a structure type or not and,
if so, what type, if any, it is a subtype of.
-------

∂26-Sep-85  0748	gls@THINK-AQUINAS.ARPA 	go and return-from inside unwind-protect cleanup   
Received: from THINK.COM by SU-AI.ARPA with TCP; 26 Sep 85  07:47:29 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Thu, 26 Sep 85 10:48:38 edt
Date: Thu, 26 Sep 85 10:48 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: go and return-from inside unwind-protect cleanup
To: Moon@SCRC-STONY-BROOK.ARPA, gls@THINK-AQUINAS.ARPA
Cc: DCP@SCRC-QUABBIN.ARPA, Common-Lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <850925220118.5.MOON@NEPONSET.SCRC.Symbolics.COM>
Message-Id: <850926104847.3.GLS@DESIDERIUS.THINK.COM>

    Date: Wed, 25 Sep 85 22:01 EDT
    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>

	Date: Mon, 9 Sep 85 13:01 EDT
	From: Guy Steele <gls@THINK-AQUINAS.ARPA>

	    Date: Mon, 9 Sep 85 09:43 EDT
	    From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>

	    Are the following legal?

		    (defun foo (go-p)
		      (prog nil
			 tag
			    (unwind-protect
				(return (compute))
			      (if go-p (go tag)))))

		    (defun bar (return-p)
		      (prog nil
			 tag
			    (unwind-protect
				(progn (compute)
				       (go tag))
			      (if return-p (return nil)))))

	I regard both of these as completely legal.

    While they may be legal and implementable, I feel that this programming
    style should be strongly discouraged.  For one thing, it can be
    rather difficult to stop the execution of (FOO T), since any attempt
    to THROW out of it will simply cause it to re-enter its infinite loop.

I agree that GO should not be used capriciously, especially in company
with UNWIND-PROTECT.  (For some *really* awful code of this type, see
the early SCHEME papers.)

I do think that the interaction between GO/RETURN and UNWIND-PROTECT
should be well-defined, however, because of the following kind
of situation:

(DEFMACRO HAIRY-PROTECTED-MACRO-WITH-BODY (...)
  `(UNWIND-PROTECT (PROGN ... ,@BODY)
     ...))

(TAGBODY
   ...
   (HAIRY-PROTECTED-MACRO-WITH-BODY
     ...
     (WHEN (GROSS-ME-OUT) (GO LOSE))
     ...)
   ...
 LOSE (ERROR "I am grossed out."))

The GO ought to work more-or-less as expected; you shouldn't have to
know that the macro has an UNWIND-PROTECT in it.  On the other hand, the
UNWIND-PROTECT must do its job of protecting things, and shouldn't have
to know anything special about a GO being in its body.

--Guy

∂26-Sep-85  0751	gls@THINK-AQUINAS.ARPA 	Discouraged programming practices   
Received: from THINK.COM by SU-AI.ARPA with TCP; 26 Sep 85  07:50:19 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Thu, 26 Sep 85 10:51:21 edt
Date: Thu, 26 Sep 85 10:51 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Discouraged programming practices
To: RAM@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <RAM.12146204226.BABYL@C.CS.CMU.EDU>
Message-Id: <850926105132.4.GLS@DESIDERIUS.THINK.COM>

    Date: Wed, 25 Sep 1985  22:12 EDT
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>


    Another discouraged programming practice is to write

	(without-interrupts (loop))

    as it may be difficult to terminate the execution of this form.
    WITHOUT-INTERRUPTS is not a part of Common-Lisp, but it should be.

    :-)?

      Rob

Maybe we should regard it as a valid compiler optimization to compile
this idiom as an exit to the operating system with a message such as
"I'm bored.  This program will never terminate, so let's do something else."
This could give greater credence to the joke about a supercomputer
so fast it executes an infinite loop in two seconds.

:-? !

--Guy

∂26-Sep-85  0758	gls@THINK-AQUINAS.ARPA 	More corrections to CLtL  
Received: from THINK.COM by SU-AI.ARPA with TCP; 26 Sep 85  07:58:04 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Thu, 26 Sep 85 10:58:56 edt
Date: Thu, 26 Sep 85 10:59 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: More corrections to CLtL
To: Steiner@RUTGERS.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 26 Sep 85 04:00-EDT from Dave <Steiner@BLUE.RUTGERS.EDU>
Message-Id: <850926105901.5.GLS@DESIDERIUS.THINK.COM>

    Date: 26 Sep 85 04:00:01 EDT
    From: Dave <Steiner@BLUE.RUTGERS.EDU>


    I've found several printing bugs in the format chapter.

    1) The code on p. 394 to show the scale factor doesn't work.  It
    should be something like:

    (dotimes (k 13)
      (format t "~%Scale factor ~2D:~:* |~13,6,2,VE|"
	      (- k 5) 3.14159))

    Ie, Missing % at the beginning and a missing ~:* to back up to the
    scale factor again (or add (- k 5) as a third arg in the second
    position and don't include the ~:*).

You are quite right.

    2) The output to this code with scale factor of 7 is missing a 0 after
    the decimal point.  Ie.  |3141590.0E-06|, not | 3141590.E-06|.

I disagree.  In this case k=7 and d=6.  Page 392 specifies that there will
be k (7) digits before the decimal point and d-k+1 (0) digits after the
decimal point.  The requirement on page 393, that a zero digit should
appear after the decimal point if permitted by the width constraint,
applies only in the case that the parameter d is omitted.

    3) The format expr in the function definition of FOO (on p 396) is
    missing a 4th x arg.

Right.

    ds
    uucp:   ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!steiner
    arpa:   Steiner@RUTGERS
    -------

Thanks for the corrections.  Keep those cards and letters coming!
--Guy

∂26-Sep-85  0806	gls@THINK-AQUINAS.ARPA 	CLtL error re function special form 
Received: from THINK.COM by SU-AI.ARPA with TCP; 26 Sep 85  08:05:45 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Thu, 26 Sep 85 11:06:48 edt
Date: Thu, 26 Sep 85 11:06 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: CLtL error re function special form
To: smh@MIT-EMS.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <8509261201.AA12317@mit-ems.ARPA>
Message-Id: <850926110656.6.GLS@DESIDERIUS.THINK.COM>

    Date: Thu, 26 Sep 85 08:01:25 edt
    From: Steven Haflich <smh@mit-ems.ARPA>

    Surely this must have been noticed before, but on page 87:

	    function fn				[Special Form]

	    The value of function is always the functional interpretation
	    of fn;  fn is interpreted as if it had appeared in the
	    functional-position of a function invocation.  In particular,
	    if fn is a symbol, the functional definition associated with
	    that symbol is returned;  see symbol-function.  If fn is a
	    lambda-expression ...

    Unlike the function special form, symbol-function does not see lexical
    function bindings.  The reference to symbol-function here was probably
    intended just to convey the distinction between a symbol's `functional'
    interpretation and it's `regular' i.e. symbol-value interpretation.
    But it's wrong, and potentially misleading.

    Fixing the text is awkward because lexical function binding special
    forms are not presented until p.113.  But CLtL is more of a reference
    than a teaching manual.  Perhaps the reference to symbol function
    should just be deleted.

You're right.  The text as it stands is misleading.  Thanks for catching it.

    A similar but less bothersome slip occurs on p.32 about functional data
    types:

	       A symbol may serve as a function;  an attempt to invoke a
	    symbol as a function causes the contents of the symbol's
	    function cell to be used.  See symbol-function and defun.

I don't regard this one as a slip.  In a case such as

	(cons a b)

the symbol CONS is not being invoked as a function; rather, it is evaluated
in a functional context to yield a function object, and it is that object
that is invoked.  In a situation such as

	(apply 'cons args)

then the symbol CONS is invoked as a function (APPLY actually sees the
symbol and must dereference it by fetching the function cell);  in the context

	(apply #'cons args)

it is not (APPLY never sees the symbol, only the function object).
Some examples of this may be needed.

--Guy

∂26-Sep-85  0954	gls@THINK-AQUINAS.ARPA 	Infinite optimization
Received: from THINK.COM by SU-AI.ARPA with TCP; 26 Sep 85  09:54:22 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Thu, 26 Sep 85 12:55:14 edt
Date: Thu, 26 Sep 85 12:55 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Infinite optimization
To: Rem@IMSSS, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 26 Sep 85 11:59-EDT from Rem at IMSSS
Message-Id: <850926125521.9.GLS@DESIDERIUS.THINK.COM>

    Date: 26 Sep 1985 0859-PDT
    From: Rem@IMSSS

    I like your idea. If an optimizing compiler happens to discover that the
    code it's trying to optimize absolutely cannot ever return nor produce any
    output, it would be nice for the LUSER if the compiler would inform the
    LUSER of that fact instead of blindly compiling a hung CPU and blindly leading
    the LUSER into executing it and having to reboot the system to escape it.
    Of course if the compiler doesn't happen to discover it, caveat emptor.

    Note such a very-smart compiler would wreak havoc with some timing benchmarks
    that do nothing useful over and over and throw away all the results; a good
    compiler could totally optimize-away such moot calculations, making the
    LISP system seem a million times faster than microcode when in fact it
    is simply punting the moot calculations. I have long advocated benchmarks
    being careful to do truly non-moot calculations. The CRAY-2 test whereby
    a large Mersenne prime is verified is a good benchmark. There's no way
    an optimizing compiler can turn the benchmark into a punt-cheat, providin
    it's a new Mersenne prime nobody computed before and hence couldn't be
    included as a special-case optimization a priori. (Did you see/hear the
    news story about that CRAY-2 test earlier this week?)
    -------

A few years ago a vendor did advertise a set of FORTRAN benchmarks
comparing their machine to a VAX.  Most of the numbers were reasonable,
but on one benchmark Brand X was several orders of magnitude faster than
the VAX.  This appeared in the table without comment.  The fact was that
their compiler had noticed that the results of the inner loops were
unused, and optimized away an entire timing subroutine.
--Guy

∂26-Sep-85  1250	DDYER@SCRC-QUABBIN.ARPA 	Infinite optimization    
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 26 Sep 85  12:50:08 PDT
Received: from WHITE.SWW.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 205393; Thu 26-Sep-85 15:49:37-EDT
Received: from SWW-PURPLE by SWW-WHITE via CHAOS with CHAOS-MAIL id 140473; Thu 26-Sep-85 12:55:33-PDT
Date: Thu, 26 Sep 85 12:51 PDT
From: DDYER@SCRC-RIVERSIDE.ARPA
Subject: Infinite optimization
To: common-lisp@SU-AI.ARPA
Fcc: W:>ddyer>mail.sent
In-Reply-To: <850926125521.9.GLS@DESIDERIUS.THINK.COM>
Supersedes: <850926124913.8.DDYER@PURPLE.SWW.Symbolics.COM>
Message-ID: <850926125125.9.DDYER@PURPLE.SWW.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI

    Date: Thu, 26 Sep 85 12:55 EDT
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>

	Date: 26 Sep 1985 0859-PDT
	From: Rem@IMSSS

	I like your idea. If an optimizing compiler happens to discover that the
	code it's trying to optimize absolutely cannot ever return nor produce any
	output, it would be nice for the LUSER if the compiler would inform the
	LUSER of that fact instead of blindly compiling a hung CPU and blindly leading
	the LUSER into executing it and having to reboot the system to escape it.
	Of course if the compiler doesn't happen to discover it, caveat emptor.

I don't think this is a very likely case.  Any loop that calls a
function, or which can be interrupted, can exit via *THROW.

∂26-Sep-85  1455	Moon@SCRC-STONY-BROOK.ARPA 	go and return-from inside unwind-protect cleanup    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Sep 85  14:54:59 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 322135; Thu 26-Sep-85 17:55:12-EDT
Date: Thu, 26 Sep 85 17:55 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: go and return-from inside unwind-protect cleanup
To: Guy Steele <gls@THINK-AQUINAS.ARPA>
cc: DCP@SCRC-QUABBIN.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: <850926104847.3.GLS@DESIDERIUS.THINK.COM>
Message-ID: <850926175528.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

I have no objection, stylistic or otherwise, to GO inside the
first subform of UNWIND-PROTECT.  It's only GO inside of the
cleanup subforms (the second, third, ...) of UNWIND-PROTECT
that makes me barf.  The same applies to RETURN, RETURN-FROM,
THROW, and any other transfer-of-control device.

∂26-Sep-85  1516	Moon@SCRC-STONY-BROOK.ARPA 	disassemble and compile questions    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Sep 85  15:16:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 322160; Thu 26-Sep-85 18:16:10-EDT
Date: Thu, 26 Sep 85 18:16 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: disassemble and compile questions
To: Bob Shaw <bs%hplabs.csnet@CSNET-RELAY.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8509252351.AA00218@HP-VENUS>
Message-ID: <850926181620.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 25 Sep 85 16:35:06 pdt
    From: Bob Shaw <bs%hplabs.csnet@CSNET-RELAY.ARPA>

    I'm in need of enlightenment.  The answers to the following two
    questions are not obvious from my readings of the book.

I think you've come up with some good places where the book would
benefit from more precise language.

       1.  If f is an interpreted function, does (disassemble 'f) 
	   cause f to become a compiled function?

That seems like a bad idea (as you say below).

       2.  What is the appropriate way to compile a function object
	   that is not compiled, not a lambda-expression and not the
	   function definition for a symbol?  Consider the "lexical
	   closure" example in section 2.13 of CLtL.

The only kind of uncompiled function object that exists is the lambda
expression.

    More on 1:  
      According to CLtl section 25.1, in the definition of disassemble,
      "The argument should be either a function object, a lambda-expression,
       or a symbol with a function definition.  If the relevent function is
       not a compiled function, it is first compiled.  ... This is primarily
       useful for debugging the compiler ... ."  
      Side-effecting the function cell by disassembling does not seem like
      a result I would desire, especially when debugging the compiler.
      Is (compile 'symbol) or (compile nil (symbol-function 'symbol)) the
      intended means of compilation?

In Symbolics' implementation, disassemble will compile a lambda
expression, but if given a symbol whose function definition is
interpreted, it will complain rather than compile it.  This seems
consistent with the statement that the feature of disassemble compiling
interpreted things is for debugging the compiler.

    More on 2:
      The definition of compile states that it will only handle lambda-
      expressions: "If definition is supplied, it should be a lambda-expression,
      the interpreted function to be compiled.  If it is not supplied, then
      name should be a symbol with a definition that is a lambda-expression;
      ... ."  Section 2.13 states that lists other than lambda expessions
      may, in certain implementations, serve as functions.  Should the 
      definition of compile include such cases?  I hope so.

I don't think the language designers intended that you be able to compile
lexical closures.  Note that it is possible to create two lexical closures
that have a binding in common; in order to compile one of these, leave the
other interpreted, and obtain correct semantics, the compiler would have
to use the same representation of lexical variable binding environments
as the interpreter.  Also note that the argument to COMPILE is specified
as a lambda-expression, not as a function in the general sense of section 2.13.

∂27-Sep-85  1512	FAHLMAN@C.CS.CMU.EDU 	Argument Type Mismatch Errors    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 Sep 85  15:12:06 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 27 Sep 85 18:12:35-EDT
Date: Fri, 27 Sep 1985  18:12 EDT
Message-ID: <FAHLMAN.12146684821.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Steven Haflich <smh@MIT-EMS.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Argument Type Mismatch Errors
In-reply-to: Msg of 25 Sep 1985  14:31-EDT from Steven Haflich <smh at mit-ems.ARPA>


    Unofficially:  An implementation obviously should detect and signal
    errors when convenient.  The primary force against always doing so is
    run-time efficiency.  Personally, I feel that once an implementation
    detects an error such as an inappropriate argument type, it should
    always signal the error rather than silently proceeding.  There's no
    reason not to signal the error, assuming the price of detecting it has
    already been paid.

I disagree with this slightly.  In some cases the book says "is an
error" rather than "signals an error" because we recognized that on some
machines it might be costly to detect and signal certain errors.  But in
other cases, the motivation was to allow flexibility for experimenting
with non-standard language extensions.  So I can certainly imagine some
situations in which an implementation detects an error but deliberately
goes on to do something other than signalling the error.  The existence
of such extensions should not be taken as a license for sloppy
implementation, however: extensions of this sort should be carefully
considered and should be well-documented.

-- Scott

∂30-Sep-85  1724	bs%hp-mars.csnet@CSNET-RELAY.ARPA 	Re: disassemble and compile questions   
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 30 Sep 85  17:23:52 PDT
Received: from hplabs by csnet-relay.csnet id bb17699; 30 Sep 85 20:17 EDT
Received: by HP-VENUS id AA12153; Mon, 30 Sep 85 11:29:45 pdt
Message-Id: <8509301829.AA12153@HP-VENUS>
Date: Mon, 30 Sep 85 11:28:47 pdt
From: Bob Shaw <bs%hplabs.csnet@CSNET-RELAY.ARPA>
Received: by HP-MARS id AA23741; Mon, 30 Sep 85 11:28:47 pdt
To: common-lisp <@CSNET-RELAY.ARPA,@hplabs.CSNET:common-lisp@su-ai.arpa>
Subject: Re: disassemble and compile questions
Cc: bs@hplabs.CSNET
Source-Info:  From (or Sender) name not authenticated.

Well, I essentially shot myself in the foot with the wording of my 
question about compiling things other than lambda-expressions.  
Lexical closures were a convenient example, not the real concern.
Let me make another attempt.

Is it allowable to have a function object that is specified by
a lambda-expression but is not stored as a lambda-expression or
compiled code?  In other words, does Common Lisp allow intermediate,
iterpretable representations?  If it is possible to have such a 
function object, is there a mechanism by which it can be later compiled?


In section 5.3.1 it states, "Evaluating a defun form causes the symbol
name to be a global name for the function specified by the lambda-
expression ... ."  This doesn't seem to preclude an intermediate form.

In section 2.13 it states, "A function is anything that may be correctly
given to the funcall or apply function, and is to be executed as code
when arguments are supplied."  Funcall is defined in terms of functions
(section 7.3) and apply (section 7.3) states, "function may be a
compiled-code object, or a lambda-expression, or a symbol ... ."  If
I interpret "may" as "must" in the preceding statement, then, for
such an intermediate form, (apply 'f 1 2 3) is legal, but
(apply (symbol-function 'f) 1 2 3) is not.


Thanks for any help.

∂30-Sep-85  1734	FAHLMAN@C.CS.CMU.EDU 	disassemble and compile questions
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 Sep 85  17:33:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 30 Sep 85 20:34:52-EDT
Date: Mon, 30 Sep 1985  20:34 EDT
Message-ID: <FAHLMAN.12147497155.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Bob Shaw <bs%hplabs.csnet@CSNET-RELAY.ARPA>
Cc:   Common-Lisp@SU-AI.ARPA
Subject: disassemble and compile questions


The language spec says nothing about what a compiled-code object looks
like, so it seems perfectly reasonable to me that an implementation
could have several internal compiled code formats, some (a lot) more
compiled than others.  Also, many implementations do a little work on
the lambda expression that would otherwise be produced by DEFUN before
storing it in a function cell, at least to the extent of making that
implicit BLOCK explicit.

-- Scott

∂30-Sep-85  1948	GJC@MIT-MC.ARPA 	go and return-from inside unwind-protect cleanup
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 30 Sep 85  19:48:16 PDT
Date: Mon, 30 Sep 85 22:50:57 EDT
From: George J. Carrette <GJC@MIT-MC.ARPA>
Subject:  go and return-from inside unwind-protect cleanup
To: Moon@SCRC-STONY-BROOK.ARPA
cc: Common-Lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM,
    DCP@SCRC-QUABBIN.ARPA
In-reply-to: Msg of Wed 25 Sep 85 22:01 EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
Message-ID: <[MIT-MC.ARPA].664177.850930.GJC>

About a year ago I gave (prog nil foo (unwind-protect (compute) (go
foo)) as a challange to folks at LMI. Pace Willison was able to get
out by using the single-step macro-instruction mode he had just
implemented in the debugger, to execute the CONTROL-R command right
before to (GO FOO) instruction. I was suprised he was able to get
out because he hadn't told me about the new debugger command.

The awful construct came up during the translation of some code in C
that used SETJMP/SIGNAL/LOGJMP into lisp.

∂01-Oct-85  1022	gray@GSWD-VMS 	UNIX terminal io incompatibility   
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 1 Oct 85  10:21:49 PDT
Date: Tue, 01 Oct 85 12:21:30 CDT
From: gray@GSWD-VMS
Subject: UNIX terminal io incompatibility
To: common-lisp@su-ai.arpa
Cc: gray

Common Lisp maps poorly onto UNIX(tm) in the area of terminal io.

On pages 328 and 329 of CLtL it says:

"*standard-input*,  *standard-output*,  *error-output*,   *trace-
output*,  *query-io*,  and  *debug-io*  are  initially  bound  to
synonym streams that pass all operations on to the stream that is
the  value  of  *terminal-io*."   Earlier  on,  the specification
describes *query-io* and *debug-io* as always  being  interactive
streams.

These requirements cause problems under UNIX  when  you  redirect
the  output  of  a  program,  specifically  when you redirect the
output of a Lisp session.  For example:

        clisp > FOO

If we follow the specification and attach *terminal-io*  to  UNIX
stdin/stdout  file  descriptors  and  leave all the other streams
bound to *terminal-io*,  output  from  *debug-io*  will  also  be
redirected  to  the  file,  not  to  the  terminal.  If we attach
*terminal-io* to /dev/tty and leave the other  streams  bound  to
*terminal-out*, then UNIX redirection doesn't work.

Our proposed solution is to  attach  *terminal-io*  to  /dev/tty,
then  attach  *standard-in*  to  UNIX stdin and *standard-out* to
UNIX stdout (not to *terminal-io*).  All  the  other  io  streams
remain bound to *terminal-io*.

This permits the user to redirect stdin and  stdout,  and  output
from  *debug-io*,  etc., still appears on the terminal.  Although
this does not abide by the standard, it is useful enough that  we
propose it as a UNIX-specific addition.
		
			Anne Jane Gray
			Gould CSD, Urbana, IL.

∂01-Oct-85  1106	ANDY@SU-SUSHI.ARPA 	Re: UNIX terminal io incompatibility    
Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 1 Oct 85  11:05:50 PDT
Date: Tue 1 Oct 85 10:57:17-PDT
From: Andy Freeman <ANDY@SU-SUSHI.ARPA>
Subject: Re: UNIX terminal io incompatibility
To: gray@GSWD-VMS.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message from "gray@GSWD-VMS" of Tue 1 Oct 85 10:37:56-PDT

Unix isn't the only operating system with redirectable output.
(TOPS-20, believe it or not, does also; probably Tenex does as well.
.priin and .priou are similar to stdin and stdout.  The reason you've
never heard of it is that they couldn't figure out a decent exec
syntax.)

If one is going to attach *standard-output* and *standard-input* to
stdout and stdin respectively, *error-output* should be attached to
stderr.  I don't know about *trace-output*.

-andy
-------

∂01-Oct-85  1148	DLW@SCRC-STONY-BROOK.ARPA 	Re: disassemble and compile questions 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 1 Oct 85  11:47:36 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 324445; Tue 1-Oct-85 14:41:44-EDT
Date: Tue, 1 Oct 85 14:40 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Re: disassemble and compile questions
To: bs%hplabs.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA
cc: bs@hplabs.CSNET
In-Reply-To: <8509301829.AA12153@HP-VENUS>
Message-ID: <851001144005.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI

    Date: Mon, 30 Sep 85 11:28:47 pdt
    From: Bob Shaw <bs%hplabs.csnet@CSNET-RELAY.ARPA>

    Is it allowable to have a function object that is specified by
    a lambda-expression but is not stored as a lambda-expression or
    compiled code?  In other words, does Common Lisp allow intermediate,
    iterpretable representations?  If it is possible to have such a 
    function object, is there a mechanism by which it can be later compiled?

In my opinion, this is the correct answer: Any Common Lisp
implementation is allowed to have its own, non-standard (not in CLtL),
additional kinds of functions.  Programs written in such a way as to
make this additional thing visible might not end up being portable.  So
in your case, the answer is yes, it's OK for you to put in your own
additional (intermediate, or whatever) representation, but programs that
want to be portable will have to not depend on its existence.

    If I interpret "may" as "must" in the preceding statement, then, for
    such an intermediate form, (apply 'f 1 2 3) is legal, but
    (apply (symbol-function 'f) 1 2 3) is not.

I don't understand how you conclude this. The latter form is also legal.
After all, it is defined that what happens when you apply a symbol is
that the object in the symbol's function cell is applied instead (see
2.13 again).

∂01-Oct-85  1545	GJC@MIT-MC.ARPA 	UNIX terminal io incompatibility 
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 1 Oct 85  15:45:44 PDT
Date: Tue,  1 Oct 85 18:48:29 EDT
From: George J. Carrette <GJC@MIT-MC.ARPA>
Subject:  UNIX terminal io incompatibility
To: ANDY@SU-SUSHI.ARPA
cc: common-lisp@SU-AI.ARPA, gray@GSWD-VMS.ARPA
In-reply-to: Msg of Tue 1 Oct 85 10:57:17-PDT from Andy Freeman <ANDY at SU-SUSHI.ARPA>
Message-ID: <[MIT-MC.ARPA].665347.851001.GJC>

VMS also has redirectable input/output.
$ define/user sys$output ...
$ define/user sys$input ...
$ define/user sys$error ...
$ define/user sys$command ...

one might wonder what DEC COMMON LISP does in this case.

∂01-Oct-85  2333	STEINER@RED.RUTGERS.EDU 	Another printing bug in CLtL  
Received: from RED.RUTGERS.EDU by SU-AI.ARPA with TCP; 1 Oct 85  23:33:14 PDT
Date: 2 Oct 85 02:33:00 EDT
From: Dave <Steiner@RED.RUTGERS.EDU>
Subject: Another printing bug in CLtL
To: common-lisp@SU-AI.ARPA


On p. 396 in the examples of using ~G for format, one of the examples
is:

(foo 3.14E12)  => "*********|314.2$+10|0.314E+13| 3.14L+12"
                                 ↑                    ↑
                                 |                    |
                                 |                    shouldn't this be E?
                                 |
                                 shouldn't this be a 0?

ds
uucp:   ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!steiner
arpa:   Steiner@RUTGERS
-------

∂02-Oct-85  0808	gls@THINK-AQUINAS.ARPA 	Another printing bug in CLtL   
Received: from THINK.COM by SU-AI.ARPA with TCP; 2 Oct 85  08:08:40 PDT
Received: from yon by GODOT.THINK.COM via CHAOS; Wed, 2 Oct 85 11:09:52 edt
Date: Wed, 2 Oct 85 11:09 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Another printing bug in CLtL
To: Steiner@RED.RUTGERS.EDU, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 2 Oct 85 02:33-EDT from Dave <Steiner@RED.RUTGERS.EDU>
Message-Id: <851002110940.1.GLS@YON.THINK.COM>

    Date: 2 Oct 85 02:33:00 EDT
    From: Dave <Steiner@RED.RUTGERS.EDU>


    On p. 396 in the examples of using ~G for format, one of the examples
    is:

    (foo 3.14E12)  => "*********|314.2$+10|0.314E+13| 3.14L+12"
				     ↑                    ↑
				     |                    |
				     |                    shouldn't this be E?
				     |
				     shouldn't this be a 0?

    ds
    uucp:   ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!steiner
    arpa:   Steiner@RUTGERS
    -------

Right you are.  Thank you very much.
--Guy

∂02-Oct-85  1505	mips!escargot.earl@glacier 	Another printing bug in CLtL    
Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 2 Oct 85  15:04:26 PDT
Received: by glacier with Sendmail; Wed, 2 Oct 85 15:03:59 pdt
Received: from escargot.UUCP (escargot.ARPA) by mips.UUCP (4.12/4.7)
	id AA03750; Wed, 2 Oct 85 14:35:10 pdt
Received: by escargot.UUCP (4.12/4.7)
	id AA00772; Wed, 2 Oct 85 14:33:32 pdt
Date: Wed, 2 Oct 85 14:33:32 pdt
From: mips!escargot.earl@glacier (Earl Killian)
Message-Id: <8510022133.AA00772@escargot.UUCP>
To: gls@THINK-AQUINAS.ARPA
Cc: common-lisp@SU-AI.ARPA
In-Reply-To: Guy Steele's message of Wed, 2 Oct 85 11:09 EDT
Subject: Another printing bug in CLtL

Now that a few common lisp implementations exist, maybe someone should
take all the examples in the book and execute them.  This wasn't possible
when the book was written, but it is now...

∂02-Oct-85  1800	@MIT-MC.ARPA:uucp@MIT-CCC
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Oct 85  18:00:29 PDT
Received: from MIT-CCC by MIT-MC.ARPA via Chaosnet; 2 OCT 85  20:15:04 EDT
Date: 2 Oct 1985 19:47:40-EDT
From: uucp@MIT-CCC

From gjc@cap Wed Oct  2 15:05:08 1985 remote from LMI-CAPRICORN
Received: from LMI-LAMBDA-6 by LMI-LAMBDA-3 with CHAOS-MAIL; Wed 2-Oct-1985 15:03:28-EDT
Date: Wednesday, 2 October 1985, 15:03-EDT
From: George Carrette <gjc@cap>
Subject: lisp listings
To: mitccc!common-lisp%su-ai%mc@cap

I'll send this directly to the whole mailing list to give
people a chance to point out anything I've left out.
Here are two listings:

(1) MIT-LISPMACHINE SYSTEM, or MIT-ZETALISP, MIT-SYSTEM 99
(2) implemented at MIT AI LAB
(3) MIT-CADR, LMI-CADR, SYMBOLICS-LM2
(4) now
(5) full
(6) in fact a couple numerical functions such as complex ACOS seem to be missing.
(7) no commercial support.
(8) Systemic: Flavors, ZMACS editor, chaosnet protocols on chaos or ethernet hardware.
    File-System.
    Applications: check through the AI LAB memos.

(1) ZETALISP-PLUS(tm)
(2) Lisp Machine Inc.
(3) LMI-LAMBDA(tm), LMI-LAMBDA-E(tm), TI-EXPLORER(tm).
(4) now.
(5) full.
(7) Lisp Machine Inc
    6 Tech Drive
    Andover MA 01810
    671-689-3554, or 1-800-USA-LISP for customer service.
(8)  Systemic: Flavors, ZMACS editor, chaosnet and tcp-ip protocols on ethernet hardware.
     File-System. ObjectLisp(tm) alternative object oriented programming system.
     Applications:
     PICON(tm) Industrial Process Control System.
     DOE-MACSYMA, symbolic algebra system.
     VISTA(tm) 3-D generic graphics system and window-system extensions
     implemented in ObjectLisp(tm).
     KEE(tm), ART(tm).


The applications are of course mainly in the Zetalisp we all know and
loved, so even though one could come up with an impressively long list
of lispmachine software applications that could be misleading, in that
that not all those applications were in fact in "Common-Lisp." The
ObjectLisp(tm) package is the closest (Objectlisp(tm) uses LOOP at this time)
to being common lisp, running on the Symbolics, LMI, and MIT VAX-NIL
implementations.



∂03-Oct-85  1436	DCP@SCRC-QUABBIN.ARPA 	Arguments and values to get.    
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 3 Oct 85  14:36:29 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 207346; Thu 3-Oct-85 17:40:11-EDT
Date: Thu, 3 Oct 85 17:39 EDT
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Arguments and values to get.
To: Gregor.pa@XEROX.ARPA, Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
    Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>, Common-Lisp@SU-AI.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: <850919-174345-1059@Xerox>,
             <FAHLMAN.12144621737.BABYL@C.CS.CMU.EDU>,
             <850920100928.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <851003173940.1.DCP@NEPONSET.SCRC.Symbolics.COM>

Consider
	(incf (get foo bar))
when the property does not exist.  INCF would die adding to NIL.  Thus,
to maintain simple style, you need
	(incf (get foo bar 0))
I think this is a LOT prettier than
	(setf (get foo bar)
	      (multiple-value-bind (value valid-p)
		  (get foo bar)
		(if valid-p (1+ value) 1)))
and the programmer doesn't have to worry about multiple evaluation of
FOO and BAR, since INCF is supposed to take care of that.

∂03-Oct-85  1451	DCP@SCRC-QUABBIN.ARPA 	Discouraged programming practices    
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 3 Oct 85  14:50:55 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 207354; Thu 3-Oct-85 17:54:34-EDT
Date: Thu, 3 Oct 85 17:54 EDT
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Discouraged programming practices
To: Rob MacLachlan <RAM@C.CS.CMU.EDU>, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12146204226.BABYL@C.CS.CMU.EDU>
Message-ID: <851003175412.2.DCP@NEPONSET.SCRC.Symbolics.COM>

    Date: Wed, 25 Sep 1985  22:12 EDT
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>


    Another discouraged programming practice is to write

	(without-interrupts (loop))

    as it may be difficult to terminate the execution of this form.
    WITHOUT-INTERRUPTS is not a part of Common-Lisp, but it should be.

    :-)?

On the serious side, what exactly does WITHOUT-INTERRUPTS mean?  Does it
mean WITHOUT-SCHEDULING, as it does on a variety of Lisp Machines?  Does
it mean WITHOUT-SCHEDULING-AND-WITHOUT-IO-DEVICES, which is what it
could mean on a 68000, PDP-11 or variety of other machines.  Does it
mean WITHOUT-OPERATING-SYSTEM (which on a time sharing system would be
very anti-social).  On a multi-processor (tightly coupled, loosely
coupled, or in between doesn't matter), does it mean some of the above
for the processor executing it, or does it mean
WITHOUT-ANY-OTHER-PROCESSOR.  Does spawning of sub-tasks to other
processors inherit the WITHOUT-INTERRUPTS.

In other words, WITHOUT-INTERRUPTS is much to vague to put in Common
Lisp.

∂03-Oct-85  1507	wagner@GSWD-VMS 	CLtL binding 
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 3 Oct 85  15:04:08 PDT
Date: Thu, 03 Oct 85 17:03:50 CDT
From: wagner@GSWD-VMS
Subject: CLtL binding
To: common-lisp@su-ai.arpa
Cc: wagner

Concerning binding...no, not of variables, of the book!
My copy of CLtL is falling apart after a few months of
hard use because of the "perfect" binding.  I'd pay a
few extra dollars for sewn signatures in the next edition.

			Fran Wagner
			Gould CSD-Urbana

∂03-Oct-85  1910	RAM@C.CS.CMU.EDU 	Without-Interrupts    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 3 Oct 85  19:07:46 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 3 Oct 85 22:08:40-EDT
Date: Thu, 3 Oct 1985  22:08 EDT
Message-ID: <RAM.12148300645.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Without-Interrupts
In-reply-to: Msg of 3 Oct 1985  17:54-EDT from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>


    It is true that WITHOUT-INTERRUPTS could mean a number of things,
but that doesn't mean that it has no place in portable code.  The
primary use is in protecting code which modifies data structures so
that the update appears atomic as far as the user is concerned.  No
matter where he types ↑G, the data structures of his program won't get
trashed.  Although Common Lisp doesn't require asynchronous interrupts
from the user, any reasonable implementation will have them, and good
software must deal with that fact somehow.

    Note that Common Lisp only defines a single-thread environment,
thus the behavior of WITHOUT-INTERRUPTS in a multiple-thread Lisp
implementation wouldn't be a proper part of its Common Lisp
specification.  In a multi-thread environment, it should probably freeze
out all other threads during the execution of the body.  This makes it
very expensive in a multiprocessor, and therefore probably useless,
but then nobody ever said that writing software for a multiprocessor
was easy.

    I believe that the Lisp machine interpretation is about right,
although it is silly to talk about "inhibiting scheduling" in a
single-thread implementation.  WITHOUT-INTERRUPTS shouldn't have
anything to do with real hardware interrupts, it affects "software
interrupts".  Although some systems might get upset if you ran without
interrupts for minutes, programmers who use WITHOUT-INTERRUPTS
in a "reasonable" fashion shouldn't have to worry about trashing the
system.

    WITHOUT-INTERRUPTS should nest properly, which means that
	(without-interrupts xxx)
can't turn into 
	(interrupts-off) xxx (interrupts-on)
Spice Lisp (and Zetalisp, I believe), implement WITHOUT-INTERRUPTS by
binding a special variable which the low-level interrupt handling
mechanism looks at before deciding to actually service an interrupt.

  Rob

∂04-Oct-85  1548	DLW@SCRC-STONY-BROOK.ARPA 	implicit blocks   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Oct 85  15:48:34 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 327115; Fri 4-Oct-85 18:49:36-EDT
Date: Fri, 4 Oct 85 18:48 EDT
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: implicit blocks
To: common-lisp@SU-AI.ARPA
cc: BSG@SCRC-STONY-BROOK.ARPA, DCP@SCRC-QUABBIN.ARPA,
    Margulies@SCRC-YUKON.ARPA, mbell@SCRC-YUKON.ARPA,
    bug-compiler@SCRC-YUKON.ARPA
Message-ID: <851004184805.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI

From our reading of the manual, it appears that while functions defined
by DEFUN have an implicit BLOCK around them, functions defined by FLET
and LABELS do not.  Several people here have been discussing this, and
the concensus seems to be that FLET and LABELS functions really ought to
set up such a block implicitly, both for uniformity with DEFUN and for
the same reasons that DEFUN does so in the first place.

I don't recall ever hearing this issue discussed.  I don't think that
omitting the implicit BLOCK from FLET and LABELS was intentional.  If
I'm wrong about these points, please let me know.  If we develop a
procedure for making small language definition changes, I think this one
ought to be made.  Fortunately, it seems highly unlikely that the change
would break any existing programs.

∂07-Oct-85  1054	RPG  
To:   common-lisp@SU-AI.ARPA, Squires@USC-ISI.ARPA,
      Ohlander@USC-ISI.ARPA   
Common Lisp Meeting

Here is a summary of the responses I got to the suggestion of a
Common Lisp meeting and some suggestions I have on its organization:

1. The meeting will be held either at MIT or at a local convention
center in the Boston Area.

2. The meeting will last 2 days.

3. The dates are, Thursday and Friday, Decemeber 5 and 6.

4. The schedule of events will be:

Thurs	8:30am  Welcome, registration, and coffee
	9:00am  Charter Discussion
	Noon	Lunch (brought in)
		[Informal discussion and lobbying]
	1:00pm	Charter Discussion

Fri	8:30am 	Coffee
	9:00am	Parallel discussions on:
		Object-oriented programming
		Errors
		Validation
		ANSI
		Windows
	Noon	Lunch (brought in)
	1:00pm 	Parallel Discussion
	5:00pm  Hit the Road

During the Charter discussion, the following topics will be discussed:

	Inclusion of the recent minor changes and errata to the 
	Common Lisp specification

	Methods for updating the book (second edition)

	Publishing problems - some vendors wish to have a language manual
	for their Common Lisp and desire to publish it themselves.

	Making decisions during the parallel sessions on Friday

	Administrative format of validation

                *   *   *

    Suggested Administrative Format of the Charter Discussion

[Please note: these are my suggestions and do not represent an edict.]

At the start of each session, including the Charter session, the chairman
of the committee will review the state of the discussion under his
purview.

Each organization - company or university - doing an implementation of Common
Lisp may send 2 representatives who can comment and vote during the
Charter discussion. Each organization representing a significant user
community may send 1 individual who can comment and vote during the
Charter discussion. Interested individuals of standing in the Lisp
community may also attend and vote; however, some votes may be taken
in which implementors only may vote.

In addition, each organization doing an implementation may send 2 people
to each of the parallel discussions, but only 1 of those may vote.  Each
organization representing a significant user community may send 1 person
to each of the parallel discussions. Individuals may attend the parallel
discussions, but they might be restricted from voting in some cases as
in the Charter Discussion.

Each discussion will be run approximately according to Robert's Rules of
Order to keep things under control. I assume only Guy Steele knows these
rules, so perhaps he should help run the Charter discussion so that the
other chairmen will learn how to do it. I know this sounds silly, but
remember the madhouse at Monterey.

I would like to get a list of the proposed attendees for planning
purposes.  I would also like to solicit one of our friends for the Boston
Area to arrange for the meeting rooms. Once I have a count of attendees, I
will pass the information on to that person.

I propose that the meeting rooms, morning coffee, and the lunches be
paid for by DARPA.

			-rpg-

∂08-Oct-85  0917	OLDMAN@USC-ISI.ARPA 	UNIX terminal io incompatibility  
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 8 Oct 85  09:17:17 PDT
Date: 8 Oct 1985 12:18-EDT
Sender: OLDMAN@USC-ISI.ARPA
Subject: UNIX terminal io incompatibility
From: OLDMAN@USC-ISI.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA] 8-Oct-85 12:18:11.OLDMAN>

Data General Common LISP also has redirectable output.

   execute lisp/I=infile/O=outfile/E=errorfile

The presence of any of these switches causes the default bindings of
the standard streams to change.  *terminal-io* is still attached to
the console if one is available.  If one is not available (such as when
you are running in batch mode),  we have a slightly crazy set of rules
that "do the right thing".

-- Dan Oldman

∂09-Oct-85  1018	RPG  	Response to CL Meeting Announcement    
To:   common-lisp@SU-AI.ARPA
Friends:
There has been some concern expressed about parallel sessions.
When you respond to me regarding the proposed schedule, please also
indicate your preference for parallel sessions over 2 days versus
sequential sessions over 3 days. Also, would the week after
December 5 - namely, December 9, 10, 11 - be open for you as well?
Some people mentioned a problem with December 5 and 6.

Thank you.
			-rpg-

∂10-Oct-85  0528	GJC@MIT-MC.ARPA 	Response to CL Meeting Announcement        
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 10 Oct 85  05:28:10 PDT
Date: Thu, 10 Oct 85 08:31:06 EDT
From: George J. Carrette <GJC@MIT-MC.ARPA>
Subject:  Response to CL Meeting Announcement    
To: RPG@SU-AI.ARPA
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of 09 Oct 85  1018 PDT from Dick Gabriel <RPG at SU-AI.ARPA>
Message-ID: <[MIT-MC.ARPA].674959.851010.GJC>

I think parallel sessions are fine as long as there are not more
than two at once.

∂10-Oct-85  1708	isrlist@tove.umd.edu
Received: from TOVE.UMD.EDU by SU-AI.ARPA with TCP; 10 Oct 85  17:05:23 PDT

∂10-Oct-85  1726	SCHUMACHER%hp-hulk.csnet@CSNET-RELAY.ARPA 	pathnames.  
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 10 Oct 85  17:26:41 PDT
Received: from hplabs by csnet-relay.csnet id ac14781; 10 Oct 85 20:25 EDT
Received: by HP-VENUS id AA02649; Thu, 10 Oct 85 16:06:27 pdt
Message-Id: <8510102306.AA02649@HP-VENUS>
Date: Thu 10 Oct 85 16:06:07-PDT
From: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA
Subject: pathnames.
To: common-lisp@su-ai.arpa
Cc: freeze@hplabs.CSNET
Source-Info:  From (or Sender) name not authenticated.

The manual doesn't state explicitly that the accessor functions for
pathname objects are setf'able.  Is this an oversight on my part,  the 
manuals part,  or is there some justification for this.  Admittedly the 
desired effect can be achieved using make-pathname with the current
pathname as the :default and the desired change specified as a keyword
arg,  but this seems sort of strange ...

 Lee Schumacher
-------

∂10-Oct-85  1739	DCP@SCRC-STONY-BROOK.ARPA 	pathnames.   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 Oct 85  17:39:20 PDT
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 331605; Thu 10-Oct-85 20:42:16-EDT
Date: Thu, 10 Oct 85 20:42 EDT
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: pathnames.
To: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA
cc: freeze@hplabs.CSNET
In-Reply-To: <8510102306.AA02649@HP-VENUS>
Message-ID: <851010204203.2.DCP@NEPONSET.SCRC.Symbolics.COM>

    Date: Thu 10 Oct 85 16:06:07-PDT
    From: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA

    The manual doesn't state explicitly that the accessor functions for
    pathname objects are setf'able.  Is this an oversight on my part,  the 
    manuals part,  or is there some justification for this.  Admittedly the 
    desired effect can be achieved using make-pathname with the current
    pathname as the :default and the desired change specified as a keyword
    arg,  but this seems sort of strange ...

Symbolics interns our pathnames.  Is SYMBOL-NAME setf'able?

∂11-Oct-85  0748	wagner@GSWD-VMS 	oversight?   
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 11 Oct 85  07:48:00 PDT
Date: Fri, 11 Oct 85 09:47:43 CDT
From: wagner@GSWD-VMS
Subject: oversight?
To: common-lisp@su-ai.arpa
Cc: wagner

On page 418 of CLtL, concerning the OPEN function:  "The filename
...may be a string, a pathname, or a stream."  May it not also be
a symbol, and shouldn't the spec say so?  Same for WITH-OPEN-FILE,
etc.?  (The underlying pathname functions work with symbols.)

Fran Wagner
Gould CSD-Urbana

∂11-Oct-85  1242	Moon@SCRC-STONY-BROOK.ARPA 	oversight?  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Oct 85  12:42:43 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 332245; Fri 11-Oct-85 15:32:50-EDT
Date: Fri, 11 Oct 85 15:32 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: oversight?
To: wagner@GSWD-VMS.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 11 Oct 85 10:47-EDT from wagner@GSWD-VMS
Message-ID: <851011153205.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 11 Oct 85 09:47:43 CDT
    From: wagner@GSWD-VMS

    On page 418 of CLtL, concerning the OPEN function:  "The filename
    ...may be a string, a pathname, or a stream."  May it not also be
    a symbol, and shouldn't the spec say so?  Same for WITH-OPEN-FILE,
    etc.?  (The underlying pathname functions work with symbols.)

It's true that most places in the manual say that symbols are acceptable
where pathnames are required, and are parsed as namestrings.  I don't
understand why this feature is in there; it seems like asking for trouble.
What about implementations (yes they exist) where some streams are
implemented as symbols?  How do you tell whether a symbol was supposed to
be a stream or supposed to be a string?  What if NIL is accidentally used
where a pathname was expected, do you really want to get a file named "NIL"?

It's possible that the feature of allowing symbols as pathnames was blindly
copied from an old version of Zetalisp, which used to allow that.  A couple
of bad ideas got into Common Lisp that way, in spite of significant effort
by the committee to try to keep it from happening.  Zetalisp allowed symbols
for compatibility with an old version of pdp-10 Maclisp that didn't have
strings.

∂11-Oct-85  1549	hplabs!schumacher%hplabs.csnet@CSNET-RELAY.ARPA 	Re: pathnames.  
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 11 Oct 85  15:49:11 PDT
Received: from hplabs by csnet-relay.csnet id ag23808; 11 Oct 85 18:38 EDT
Received: by HP-VENUS id AA04620; Fri, 11 Oct 85 09:17:59 pdt
Message-Id: <8510111617.AA04620@HP-VENUS>
Date: Friday, October 11, 1985  08:53:50
From: schumacher%hplabs.csnet@CSNET-RELAY.ARPA
Subject: Re: pathnames.
To: hplabs!DCP%scrc-quabbin.arpa@csnet-relay.arpa
Cc: common-lisp@su-ai.arpa
In-Reply-To: Your message of 10-Oct-85  20:42:00
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
Source-Info:  From (or Sender) name not authenticated.

  Date: Thu, 10 Oct 85 20:42 EDT
  From: "David C. Plummer" <hplabs!DCP%scrc-quabbin.arpa@CSNET-RELAY>

    Date: Thu 10 Oct 85 16:06:07-PDT
    From: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA

    The manual doesn't state explicitly that the accessor functions for
    pathname objects are setf'able.  Is this an oversight on my part,  the 
    manuals part,  or is there some justification for this.  Admittedly the 
    desired effect can be achieved using make-pathname with the current
    pathname as the :default and the desired change specified as a keyword
    arg,  but this seems sort of strange ...

  Symbolics interns our pathnames.  Is SYMBOL-NAME setf'able?

I'm not sure I understand this statement (question?).  Are you interning
the namestring of the pathname ?  Perhaps I should have been more specific:
given a path name (setq foo (pathname "<dir>foo.bar")) I want to change the 
type field of pathname foo to be "jnk".  Is it legal cl to say 
(setf (pathname-type foo) "jnk") ?  If this isn't legal then it seems that
the only way to do this is (setq foo (make-pathname :type "jnk" :defaults foo)).
Is that any clearer ?

-------

∂11-Oct-85  2025	Moon@SCRC-STONY-BROOK.ARPA 	Re: pathnames.   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Oct 85  20:25:09 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 332541; Fri 11-Oct-85 23:28:00-EDT
Date: Fri, 11 Oct 85 23:27 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: pathnames.
To: schumacher%hplabs.csnet@CSNET-RELAY.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8510111617.AA04620@HP-VENUS>
Message-ID: <851011232700.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Friday, October 11, 1985  08:53:50
    From: schumacher%hplabs.csnet@CSNET-RELAY.ARPA

      Date: Thu, 10 Oct 85 20:42 EDT
      From: "David C. Plummer" <hplabs!DCP%scrc-quabbin.arpa@CSNET-RELAY>

	Date: Thu 10 Oct 85 16:06:07-PDT
	From: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA

	The manual doesn't state explicitly that the accessor functions for
	pathname objects are setf'able.  Is this an oversight on my part,  the 
	manuals part,  or is there some justification for this.  Admittedly the 
	desired effect can be achieved using make-pathname with the current
	pathname as the :default and the desired change specified as a keyword
	arg,  but this seems sort of strange ...

      Symbolics interns our pathnames.  Is SYMBOL-NAME setf'able?

    I'm not sure I understand this statement (question?).  Are you interning
    the namestring of the pathname ?  Perhaps I should have been more specific:
    given a path name (setq foo (pathname "<dir>foo.bar")) I want to change the 
    type field of pathname foo to be "jnk".  Is it legal cl to say 
    (setf (pathname-type foo) "jnk") ?  If this isn't legal then it seems that
    the only way to do this is (setq foo (make-pathname :type "jnk" :defaults foo)).
    Is that any clearer ?

Perhaps I can clarify.  In Common Lisp it is not legal to change the components
of a pathname, for the same reasons that it is not legal to change the name of
a symbol and not legal to change the denominator of a ratio.

In Symbolics' implementation, every time you ask for a pathname with the same
components, you get the same object, so that pathname equality can be tested
with EQ.  This is what DCP was pointing out.  However, this is irrelevant.
Even in a system that didn't "intern" or "canonicalize" pathnames in this way,
it would be inappropriate to perform side-effects on a pathname because it
might be in use by someone else.  That's the basis for the language design;
unfortunately it isn't explained in the manual.  You're correct that the way
to get a pathname that is like another pathname but with one component different
is to call make-pathname.

∂15-Oct-85  1119	RLB@SCRC-STONY-BROOK.ARPA 	Re: pathnames.    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Oct 85  11:19:31 PDT
Received: from PETREL.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 334182; Tue 15-Oct-85 14:21:51-EDT
Date: Tue, 15 Oct 85 14:21 EDT
From: Richard L. Bryan <RLB@SCRC-QUABBIN.ARPA>
Subject: Re: pathnames.
To: Moon@SCRC-STONY-BROOK.ARPA, schumacher%hplabs.csnet@CSNET-RELAY.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851011232700.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <851015142135.3.RLB@PETREL.SCRC.Symbolics.COM>

    Date: Fri, 11 Oct 85 23:27 EDT
    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>

	Date: Friday, October 11, 1985  08:53:50
	From: schumacher%hplabs.csnet@CSNET-RELAY.ARPA

	  Date: Thu, 10 Oct 85 20:42 EDT
	  From: "David C. Plummer" <hplabs!DCP%scrc-quabbin.arpa@CSNET-RELAY>

	    Date: Thu 10 Oct 85 16:06:07-PDT
	    From: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA

	    The manual doesn't state explicitly that the accessor functions for
	    pathname objects are setf'able.  Is this an oversight on my part,  the 
	    manuals part,  or is there some justification for this.  Admittedly the 
	    desired effect can be achieved using make-pathname with the current
	    pathname as the :default and the desired change specified as a keyword
	    arg,  but this seems sort of strange ...

	  Symbolics interns our pathnames.  Is SYMBOL-NAME setf'able?

	I'm not sure I understand this statement (question?).  Are you interning
	the namestring of the pathname ?  Perhaps I should have been more specific:
	given a path name (setq foo (pathname "<dir>foo.bar")) I want to change the 
	type field of pathname foo to be "jnk".  Is it legal cl to say 
	(setf (pathname-type foo) "jnk") ?  If this isn't legal then it seems that
	the only way to do this is (setq foo (make-pathname :type "jnk" :defaults foo)).
	Is that any clearer ?

    Perhaps I can clarify.  In Common Lisp it is not legal to change the components
    of a pathname, for the same reasons that it is not legal to change the name of
    a symbol and not legal to change the denominator of a ratio.

    In Symbolics' implementation, every time you ask for a pathname with the same
    components, you get the same object, so that pathname equality can be tested
    with EQ.  This is what DCP was pointing out.  However, this is irrelevant.
    Even in a system that didn't "intern" or "canonicalize" pathnames in this way,
    it would be inappropriate to perform side-effects on a pathname because it
    might be in use by someone else.  That's the basis for the language design;
    unfortunately it isn't explained in the manual.  You're correct that the way
    to get a pathname that is like another pathname but with one component different
    is to call make-pathname.

Perhaps SETF of pathname components should work the same
way as SETF of LDB.

∂15-Oct-85  1247	RWK@SCRC-STONY-BROOK.ARPA 	Re: pathnames.    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Oct 85  12:47:29 PDT
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 334265; Tue 15-Oct-85 15:26:34-EDT
Date: Tue, 15 Oct 85 15:25 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Re: pathnames.
To: Richard L. Bryan <RLB@SCRC-QUABBIN.ARPA>
cc: Moon@SCRC-STONY-BROOK.ARPA, schumacher%hplabs.csnet@CSNET-RELAY.ARPA,
    common-lisp@SU-AI.ARPA
In-Reply-To: <851015142135.3.RLB@PETREL.SCRC.Symbolics.COM>
Message-ID: <851015152519.4.RWK@CROW.SCRC.Symbolics.COM>

    Date: Tue, 15 Oct 85 14:21 EDT
    From: Richard L. Bryan <RLB@SCRC-QUABBIN.ARPA>
    Perhaps SETF of pathname components should work the same
    way as SETF of LDB.
As former pathnamemeister for Symbolics (theoretically retired)
I concur with Moon's analysis and RLB's suggestion.

For uniformity we could extend this to other read-only accessors
like SYMBOL-NAME, and DENOMINATOR although it's hard to see it as
useful in the former case, and it's pretty strange in the later
(and probably indicative of a woefully ineffecient program).

∂15-Oct-85  1520	GSB@MIT-MC.ARPA 	SETF of pathname components 
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 15 Oct 85  15:20:25 PDT
Date: Tue, 15 Oct 85 18:23:24 EDT
From: Glenn S. Burke <GSB@MIT-MC.ARPA>
Subject: SETF of pathname components
To: RWK@SCRC-YUKON.ARPA
cc: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].680489.851015.GSB>

    Date: Tue, 15 Oct 85 15:25 EDT
    From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>

    . . .

    For uniformity we could extend this to other read-only accessors
    like SYMBOL-NAME, and DENOMINATOR although it's hard to see it as
    useful in the former case, and it's pretty strange in the later
    (and probably indicative of a woefully ineffecient program).

I agree with Moon's analysis, but i disagree that on these grounds
SETF should handle pathname components like LDB handles integers.  I
don't think pathnames appear to be sufficiently non-structured that
the read-only-ness of the components should be taken advantage of
in order to permit this hack.

The same goes for symbol-name.  As for denominator, it sounds
sufficiently ludicrous that i think it also should be left out, but
only because it seems perverse.

∂22-Oct-85  1546	greek@DEC-HUDSON 	WITHOUT-INTERRUPTS    
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Oct 85  15:34:38 PDT
Date: Tue, 22 Oct 85 12:45:43 EDT
From: greek@DEC-HUDSON
Subject: WITHOUT-INTERRUPTS
To: common-lisp@su-ai

I think if we abandon the name WITHOUT-INTERRUPTS, which has all kinds
of vague conotations, and adopt the name CRITICAL-SECTION, we might
get further in understanding what it ought to do.

- Paul

∂22-Oct-85  1554	gls@THINK-AQUINAS.ARPA 	Report on trip to Japan   
Received: from THINK.COM by SU-AI.ARPA with TCP; 22 Oct 85  15:50:26 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Tue, 22 Oct 85 12:41:38 edt
Date: Tue, 22 Oct 85 12:43 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Report on trip to Japan
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <851022124308.1.GLS@THINK-DESIDERIUS.ARPA>

Well, my face is red.  I did not get to Japan after all.  When I
presented my passport at the airport gate in Seattle, I was informed
that the passport contained no visa for travel to Japan.  Japan requires
that a visa be obtained in advance of travel.  I didn't know this (none
of the European countries I have visited has required a visa), and none
of the many people helping me (and who did many other things to make the
trip possible) thought to advise me to get a visa.  My problem occurred
on a Saturday morning, and no Japanese consulate would be open until
Monday, which would be too late; and so my trip was cancelled.  Too bad.
This is especially disappointing to me as I had hoped to have some
discussions about means of international cooperation in the development
of Common Lisp.  I may be able to try again next spring.

Nevertheless, I am grateful to all of you who supplied me with
implementation data for the survey I conducted in preparation for the
trip.  I think the survey was well worth doing.  I have distributed it
to this mailing list.  Since then a couple more entries have come in,
and I will distribute this addendum in a few days.  (Any more out
there?)

It was suggested to me that it might be useful to publish this survey in
some forum such as SIGPLAN Notices or the SIGART newsletter.  However, I
made a specific statement up front about the uses to which I would put
the collected data, and I would not feel right about publishing it
without first checking back with all of you who supplied the data.
Questions:

(1) Do you feel it would be useful to publish the collected survey data?
(2) If you supplied data, would you consent to using the data for this
    purpose?  (Perhaps you may wish to supply a corrected version now that
    you have seen all the entries together?)

There remains the question of whether such a journal would wish to publish
the list, but that's another matter.

∂22-Oct-85  1908	gls@THINK-AQUINAS.ARPA 	Report on trip to Japan   
Received: from THINK.COM by SU-AI.ARPA with TCP; 22 Oct 85  15:50:26 PDT
Received: from desiderius by GODOT.THINK.COM via CHAOS; Tue, 22 Oct 85 12:41:38 edt
Date: Tue, 22 Oct 85 12:43 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Report on trip to Japan
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <851022124308.1.GLS@THINK-DESIDERIUS.ARPA>

Well, my face is red.  I did not get to Japan after all.  When I
presented my passport at the airport gate in Seattle, I was informed
that the passport contained no visa for travel to Japan.  Japan requires
that a visa be obtained in advance of travel.  I didn't know this (none
of the European countries I have visited has required a visa), and none
of the many people helping me (and who did many other things to make the
trip possible) thought to advise me to get a visa.  My problem occurred
on a Saturday morning, and no Japanese consulate would be open until
Monday, which would be too late; and so my trip was cancelled.  Too bad.
This is especially disappointing to me as I had hoped to have some
discussions about means of international cooperation in the development
of Common Lisp.  I may be able to try again next spring.

Nevertheless, I am grateful to all of you who supplied me with
implementation data for the survey I conducted in preparation for the
trip.  I think the survey was well worth doing.  I have distributed it
to this mailing list.  Since then a couple more entries have come in,
and I will distribute this addendum in a few days.  (Any more out
there?)

It was suggested to me that it might be useful to publish this survey in
some forum such as SIGPLAN Notices or the SIGART newsletter.  However, I
made a specific statement up front about the uses to which I would put
the collected data, and I would not feel right about publishing it
without first checking back with all of you who supplied the data.
Questions:

(1) Do you feel it would be useful to publish the collected survey data?
(2) If you supplied data, would you consent to using the data for this
    purpose?  (Perhaps you may wish to supply a corrected version now that
    you have seen all the entries together?)

There remains the question of whether such a journal would wish to publish
the list, but that's another matter.

∂23-Oct-85  0723	BSG@SCRC-YUKON.ARPA 	WITHOUT-INTERRUPTS 
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 23 Oct 85  07:23:16 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 162582; Wed 23-Oct-85 10:02:46-EDT
Date: Wed, 23 Oct 85 10:07 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: WITHOUT-INTERRUPTS
To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 22 Oct 85 12:45-EDT from greek@DEC-HUDSON
Message-ID: <851023100741.6.BSG@CONCORD.SCRC.Symbolics.COM>

    Date: Tue, 22 Oct 85 12:45:43 EDT
    From: greek@DEC-HUDSON

    I think if we abandon the name WITHOUT-INTERRUPTS, which has all kinds
    of vague conotations, and adopt the name CRITICAL-SECTION, we might
    get further in understanding what it ought to do.

    - Paul

No, it hides the issue rather than clarifies it.  On a certain class of
simple systems, CRITICAL-SECTION means "without interrupts".  When
multiprocessing and other complications are introduced, then
"without interrupts" is not only not sufficiently adequate,
but not sufficiently -specific- as to exactly what must be locked out.
"CRITICAL-SECTION" makes no claim to asserting exactly what must be
locked out, but in no way addresses the problem that this is a
complicated set, either.

∂23-Oct-85  0822	greek@DEC-HUDSON 	WITHOUT-INTERRUPTS    
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 23 Oct 85  08:22:02 PDT
Date: Wed, 23 Oct 85 11:28:22 EDT
From: greek@DEC-HUDSON
Subject: WITHOUT-INTERRUPTS
To: common-lisp@su-ai

Mr. Greenberg has pointed out that I've only hidden the problem by
suggesting CRITICAL-SECTION instead of WITHOUT-INTERRUPTS.  That's 
exactly what I intended to do.

WITHOUT-INTERRUPTS is too specific, and deals only with interrupt
questions, not with memory lockout or other strange things that
may occur on multiprocessors.

CRITICAL-SECTION, I believe, suggests what it is that we are trying
to accomplish, without being specific.  On a simple processor running
a LISP without its own tasking or interrupts, it would be a nop.
With interrupts, it would lock them out.  With tasks, it would also
prevent task switches.  On a multiprocessor it might also do some
kind of memory lockout to prevent the other processors from stomping
on things.  Who knows -- and that's exactly the point.

Perhaps the problem is that there are so many classes of things we
want to lock out that we need multiple macros or options to the
one macro.

- Paul

∂23-Oct-85  0947	BSG@SCRC-STONY-BROOK.ARPA 	WITHOUT-INTERRUPTS
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 Oct 85  09:47:37 PDT
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 339514; Wed 23-Oct-85 12:25:47-EDT
Date: Wed, 23 Oct 85 12:31 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: WITHOUT-INTERRUPTS
To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 23 Oct 85 11:28-EDT from greek@DEC-HUDSON.ARPA
Message-ID: <851023123157.6.BSG@CONCORD.SCRC.Symbolics.COM>

    Date: Wed, 23 Oct 85 11:28:22 EDT
    From: greek@DEC-HUDSON

    Mr. Greenberg has pointed out that I've only hidden the problem by
    suggesting CRITICAL-SECTION instead of WITHOUT-INTERRUPTS.  That's 
    exactly what I intended to do.

    WITHOUT-INTERRUPTS is too specific, and deals only with interrupt
    questions, not with memory lockout or other strange things that
    may occur on multiprocessors.

    CRITICAL-SECTION, I believe, suggests what it is that we are trying
    to accomplish, without being specific.  On a simple processor running
    a LISP without its own tasking or interrupts, it would be a nop.
    With interrupts, it would lock them out.  With tasks, it would also
    prevent task switches.  On a multiprocessor it might also do some
    kind of memory lockout to prevent the other processors from stomping
    on things.  Who knows -- and that's exactly the point.
As you hint in the next paragraph, it's not a question of "who knows",
but an issue of different kinds of outlocking being appropriate at
different times, on a more complicated system
    Perhaps the problem is that there are so many classes of things we
    want to lock out that we need multiple macros or options to the
    one macro.
Exactly, if we decide that the problem has to be addressed by the
language at all.  Unless CRITICAL-SECTION has a bunch of options,
it addresses -no- problems.  It is not clear to me that the
conceptual options can be stated in a system-independent way.
I am not willing to say that I know about all the tasking and
processor-sharing paradigms that have been, or might be invented.
    - Paul


∂23-Oct-85  1023	greek@DEC-HUDSON 	WITHOUT-INTERRUPTS    
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 23 Oct 85  10:19:09 PDT
Date: Wed, 23 Oct 85 13:25:24 EDT
From: greek@DEC-HUDSON
Subject: WITHOUT-INTERRUPTS
To: common-lisp@su-ai

Mr. Greenberg is certainly correct when he says we don't understand
all the locking mechanisms that exist.  However, unless I'm off
base here, it seems to me that CRITICAL-SECTION could be specified
as locking out ANY possible contention from other tasks, interrupt
handlers, processors, etc.  If a particular implementation needs
additional kinds of locking macros, they can add them.

Perhaps we should define CRITICAL-SECTION as follows:

	CRITICAL-SECTION (&key options) &body body

and say that, without options, it locks out "everything".  On the other
hand, perhaps "everything" is simply too nebulous.

- Paul

∂23-Oct-85  1030	Moon@SCRC-STONY-BROOK.ARPA 	WITHOUT-INTERRUPTS    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 Oct 85  10:30:21 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 339575; Wed 23-Oct-85 13:31:08-EDT
Date: Wed, 23 Oct 85 13:32 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: WITHOUT-INTERRUPTS
To: greek@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 23 Oct 85 11:28-EDT from greek@DEC-HUDSON
Message-ID: <851023133207.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

I seem to have come in in the middle of this discussion.  Perhaps there
was some earlier mail that I missed for some reason.

I think WITHOUT-INTERRUPTS, or any other multiprocessing primitive, is
much too implementation-dependent to be appropriate for the portable
Common Lisp language.  I don't see any point in discussing it, because
there is no possible primitive that will meet the needs of all multiprocessing
implementation techniques.

    Date: Wed, 23 Oct 85 11:28:22 EDT
    From: greek@DEC-HUDSON

    On a simple processor running
    a LISP without its own tasking or interrupts, it would be a nop.
    With interrupts, it would lock them out.  With tasks, it would also
    prevent task switches.  On a multiprocessor it might also do some
    kind of memory lockout to prevent the other processors from stomping
    on things.  

So what we have is that on some uniprocessors WITHOUT-INTERRUPTS or
CRITICAL-SECTION, it matters not at all what you call it, is
meaningless, on other uniprocessors it makes sense, and on large
multiprocessors it is so expensive to implement that no one will ever
use it.  If instead you decide to make a primitive that specifies more
precisely what synchronization is required, so that the implementation
will not be so expensive, you will have to build in assumptions about
some particular multiprocessor architecture.  There are an enormous
number of possible architectures, many of them advocated as the best
by people of strong convictions, and no agreement at present on unifying
general principles.

		Who knows -- and that's exactly the point.

Mine too.

This issue is simply outside the scope of what Common Lisp can hope to address.

∂23-Oct-85  1110	Moon@SCRC-STONY-BROOK.ARPA 	WITHOUT-INTERRUPTS    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 Oct 85  11:10:08 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 339615; Wed 23-Oct-85 14:07:38-EDT
Date: Wed, 23 Oct 85 14:08 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: WITHOUT-INTERRUPTS
To: greek@DEC-HUDSON.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 23 Oct 85 13:25-EDT from greek@DEC-HUDSON.ARPA
Message-ID: <851023140830.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 23 Oct 85 13:25:24 EDT
    From: greek@DEC-HUDSON

    Mr. Greenberg is certainly correct when he says we don't understand
    all the locking mechanisms that exist.  However, unless I'm off
    base here, it seems to me that CRITICAL-SECTION could be specified
    as locking out ANY possible contention from other tasks, interrupt
    handlers, processors, etc.  If a particular implementation needs
    additional kinds of locking macros, they can add them.

    Perhaps we should define CRITICAL-SECTION as follows:

	    CRITICAL-SECTION (&key options) &body body

    and say that, without options, it locks out "everything".  On the other
    hand, perhaps "everything" is simply too nebulous.

Let me just ask you to think about one thing and then I promise not to send
any more mail.

In Lisp on VAX/VMS, will CRITICAL-SECTION stop VMS from scheduling any processes
that have shared global sections mapped into their address space that are also
mapped into the address space of this Lisp?

∂23-Oct-85  1258	greek@DEC-HUDSON 	WITHOUT-INTERRUPTS    
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 23 Oct 85  12:58:35 PDT
Date: Wed, 23 Oct 85 16:04:59 EDT
From: greek@DEC-HUDSON
Subject: WITHOUT-INTERRUPTS
To: common-lisp@su-ai

I too promise that this is my last message.

Mr. Moon is right -- VMS certainly couldn't promise to lock out
other processes that might touch a shared section.  Somehow that
doesn't bother me, however.  We can't worry about other processes
that have nothing to do with LISP -- that's too implementation
specific.

Yeah, sure, this is getting ridiculous.  I begin to agree that
WITHOUT-INTERRUPTS is hopeless for a portable language.

- Paul

∂24-Oct-85  1036	gls@THINK-AQUINAS.ARPA 	WITHOUT-INTERRUPTS: my last message 
Received: from THINK.COM by SU-AI.ARPA with TCP; 24 Oct 85  08:38:32 PDT
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Thu, 24 Oct 85 11:40:21 edt
Date: Thu, 24 Oct 85 11:42 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: WITHOUT-INTERRUPTS: my last message
To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 23 Oct 85 16:04-EDT from greek@DEC-HUDSON
Message-Id: <851024114209.1.GLS@THINK-JEHOSEPHAT.ARPA>
Comment: Remailed at SU-AI after delay caused by distribution list error.

    Date: Wed, 23 Oct 85 16:04:59 EDT
    From: greek@DEC-HUDSON

    I too promise that this is my last message.

Me, too.

    Mr. Moon is right -- VMS certainly couldn't promise to lock out
    other processes that might touch a shared section.

Sure it could... if it wanted to.  Alternatively, the LISP could
simply refuse to share.

On the third hand, suppose I want to swap the names of two files,
so I do

    (critical-section
	(rename-file "foo" "temp")
	(rename-file "bar" "foo")
	(rename-file "temp" "bar"))

Assuming that files foo and bar both existed to begin with, am I guaranteed
that at no time can any other process get the value NIL for

	(and (probe-file "foo") (probe-file "bar"))

?  That would be an awfully nice property to have.

--Guy

∂24-Oct-85  1042	GJC@MIT-MC.ARPA 	WITHOUT-INTERRUPTS
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 24 Oct 85  09:40:19 PDT
Date: Thu, 24 Oct 85 12:42:03 EDT
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject:  WITHOUT-INTERRUPTS
To: greek@HUDSON.DEC.COM
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Wed 23 Oct 85 13:25:24 EDT from greek at DEC-HUDSON
Message-ID: <[MIT-MC.ARPA].691403.851024.GJC>
Comment: Remailed at SU-AI after delay caused by distribution list error.

Without-Interrupts can be very confusing. On the LISPM for example it
is possible to call, knowingly or unknowingly, PROCESS-WAIT from within
a Without-Interrupts, this can then allow a process switch, which
may or may not defeat the purpose of the without-interrupts.
On the VAX, in VAX-NIL which I'm most familiar with, I would be
worried about critical sections of code from the point of view of
AST handlers and such. However, I know that in NIL, by default,
any straight line sequence of code without a function call is
exectuted without testing for the interrupt polling BIT, or, while
writing (or compiling lisp to) LMI-LAMBDA microcode there are similar
considerations, therefore I can take advantage of this condition in
writing code that has possible interlocking dangers. But conditions
are so different in the different lisps that a simple-looking PORTABLE
construct such as CRITICAL-SECTION would not work. Those very people
who would want to use it are probably those that couldnt understand
the underlying mechanisms sufficiently to write such code correctly
and portably.

Instead, maybe a few primitive datastructures, such as QUEUE's with
properly interlocked manipulation primitives could be introduced into
the language. That is to say, what kinds of things are you wanting to
use CRITICAL-SECTION for anyway?

∂25-Oct-85  1337	RPG  	Meeting  
To:   common-lisp@SU-AI.ARPA
I am at this very moment in negotiations with hotels and the like
in the Boston area regarding the exact dates for the meeting. I expect
to get some definitive answer to the question of ``when?'' by Monday
or Tuesday. As it happens, it is not always possible to pick the exact
days only 1.5 months in advance.
			-rpg-

∂26-Oct-85  1315	RPG  	Tentative Schedule for the Common Lisp Meeting   
To:   common-lisp@SU-AI.ARPA
I have tentatively booked the Hotel Sonesta in Cambridge, Massachusetts,
for December 16, 17, and 18 for the meeting (not for accommodations). 
Are these dates acceptable? I must have a firm answer by monday.
			-rpg-

∂28-Oct-85  0855	masinter.pa@Xerox.ARPA 	Re: Tentative Schedule for the Common Lisp Meeting      
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 28 Oct 85  08:55:10 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 28 OCT 85 08:57:08 PST
Date: 28 Oct 85 09:03 PST
From: masinter.pa@Xerox.ARPA
Subject: Re: Tentative Schedule for the Common Lisp Meeting   
In-reply-to: Dick Gabriel <RPG@SU-AI.ARPA>'s message of 26 Oct 85 13:15
 PDT
To: RPG@SU-AI.ARPA
cc: common-lisp@SU-AI.ARPA
Message-ID: <851028-085708-2075@Xerox>

What happened to the week of December 3? You changed the date without a
lot of discussion....

∂28-Oct-85  1233	OLDMAN@USC-ISI.ARPA 	Uniqueness of &rest arguments
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 28 Oct 85  12:32:12 PST
Date: 28 Oct 1985 15:32-EST
Sender: OLDMAN@USC-ISI.ARPA
Subject: Uniqueness of &rest arguments
From: OLDMAN@USC-ISI.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]28-Oct-85 15:32:44.OLDMAN>

Are &rest arguments guaranteed to be copied?  Consider the following:

    (defmacro m (&rest args)
         `',(nreverse args)        ; Destructive reverse
    )
    (setq x '(m a b c d))
    (eval x)

What is the final value of x?   I think that I would argue that
it is undefined since args may or may not be a copy of the original
form.   Is there anything in Cttl that clarifies this?

-- Dan

∂28-Oct-85  1445	gls@THINK-AQUINAS.ARPA 	Uniqueness of &rest arguments  
Received: from THINK.COM by SU-AI.ARPA with TCP; 28 Oct 85  14:45:15 PST
Received: from desiderius by GODOT.THINK.COM via CHAOS; Mon, 28 Oct 85 16:07:57 est
Date: Mon, 28 Oct 85 16:09 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Uniqueness of &rest arguments
To: OLDMAN@USC-ISI.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <[USC-ISI.ARPA]28-Oct-85 15:32:44.OLDMAN>
Message-Id: <851028160902.2.GLS@THINK-DESIDERIUS.ARPA>

    Date: 28 Oct 1985 15:32-EST
    From: OLDMAN@USC-ISI.ARPA

    Are &rest arguments guaranteed to be copied?  Consider the following:

	(defmacro m (&rest args)
	     `',(nreverse args)        ; Destructive reverse
	)
	(setq x '(m a b c d))
	(eval x)

    What is the final value of x?   I think that I would argue that
    it is undefined since args may or may not be a copy of the original
    form.   Is there anything in Cttl that clarifies this?

    -- Dan

I cannot find any place in the manual that addresses this point.  The
text describing APPLY alludes to appending the last argument to APPLY to
a list of all other arguments (except the function, of course), and so
one might think, referring to the definition of APPEND, that the
resulting list of arguments might contain actual cons cells from the
list that is the last argument to APPLY.  However, nothing addresses
whether a &REST argument might share with this list.

My own opinion is that indeed the args might not be a copy of the
original form, but I regard this as a non-trivial clarification worthy
of discussion.

--Guy

∂28-Oct-85  1711	Moon@SCRC-STONY-BROOK.ARPA 	Uniqueness of &rest arguments   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Oct 85  17:11:43 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 343004; Mon 28-Oct-85 20:06:37-EST
Date: Mon, 28 Oct 85 20:07 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Uniqueness of &rest arguments
To: Guy Steele <gls@THINK-AQUINAS.ARPA>
cc: OLDMAN@USC-ISI.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <851028160902.2.GLS@THINK-DESIDERIUS.ARPA>
Message-ID: <851028200712.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 28 Oct 85 16:09 EST
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>

	Date: 28 Oct 1985 15:32-EST
	From: OLDMAN@USC-ISI.ARPA

	Are &rest arguments guaranteed to be copied?  Consider the following:

	    (defmacro m (&rest args)
		 `',(nreverse args)        ; Destructive reverse
	    )
	    (setq x '(m a b c d))
	    (eval x)

	What is the final value of x?   I think that I would argue that
	it is undefined since args may or may not be a copy of the original
	form.   Is there anything in Cttl that clarifies this?

    I cannot find any place in the manual that addresses this point.  The
    text describing APPLY alludes to appending the last argument to APPLY to
    a list of all other arguments (except the function, of course), and so
    one might think, referring to the definition of APPEND, that the
    resulting list of arguments might contain actual cons cells from the
    list that is the last argument to APPLY.  However, nothing addresses
    whether a &REST argument might share with this list.

None of this applies to macros anyway, since they aren't invoked with APPLY.

    My own opinion is that indeed the args might not be a copy of the
    original form, but I regard this as a non-trivial clarification worthy
    of discussion.

I hope it doesn't take a whole lot of discussion.  It's pretty clear to me
that if the manual doesn't guarantee explicitly that the user can freely
bash the &rest argument, then the user can only sensibly assume that it is
not safe to bash it.  I also can't see any significant advantage to the user
to be gained requiring implementations to make copies of &rest arguments.
Note that if there are implementations that can't avoid making a copy (but
not for macros!), they can easily have a compiler optimizer to remove
calls to copy-list, so there can be no argument from efficiency.

∂28-Oct-85  1715	Moon@SCRC-STONY-BROOK.ARPA 	Tentative Schedule for the Common Lisp Meeting      
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Oct 85  17:15:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 343009; Mon 28-Oct-85 20:14:50-EST
Date: Mon, 28 Oct 85 20:15 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Tentative Schedule for the Common Lisp Meeting   
To: Dick Gabriel <RPG@SU-AI.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 26 Oct 85 16:15-EDT from Dick Gabriel <RPG@SU-AI.ARPA>
Message-ID: <851028201531.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 26 Oct 85  1315 PDT
    From: Dick Gabriel <RPG@SU-AI.ARPA>

    I have tentatively booked the Hotel Sonesta in Cambridge, Massachusetts,
    for December 16, 17, and 18 for the meeting (not for accommodations). 
    Are these dates acceptable? 

They appear to be okay for me.

    I must have a firm answer by monday.

By when?  You can't have meant today if you sent mail on Saturday.  Do you
mean next Monday?

∂29-Oct-85  1649	hoey@nrl-aic 	Default scope of references    
Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 29 Oct 85  16:48:53 PST
Date: 29 Oct 1985 18:09:05 EST (Tue)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Default scope of references
To: Common-lisp@SU-AI.ARPA
Message-Id: <499475345/hoey@nrl-aic>

I would like some protection against accidental references to
dynamically bound variables in interpreted code.  Compilers typically
complain about such lossage.  When I heard that Common Lisp defaulted
to lexical binding, I thought that was what was meant.  For instance,
given

(DEFVAR *TEST-1* '(PROGN (DEFUN SET-FOO (VAL)
				(SETQ FOO VAL))
			 (SET-FOO NIL)))

(DEFVAR *TEST-2* '(PROGN (SET 'FOO T)
			 (DEFUN GET-FOO ()
				FOO)
			 (GET-FOO)))

in the absence of (PROCLAIM (SPECIAL FOO)), I somehow expected that
(EVAL *TEST-1*) and (EVAL *TEST-2*) would each tell me that I was
accessing a variable that was neither declared special nor lexically
bound.  According to CLtL, however, ``The general rule is that if the
symbol occurs textually within a program construct that creates a
*binding* for a variable of the same name, then the reference is to the
variable specified by the binding; if no such program construct
textually contains the reference, then it is taken to refer to the
special variable of that name.'' [p. 55]  Thus these forms are
supposedly legally evaluable.  Is this what was intended?  Should
evaluation of these forms be or signal an error?  I would certainly
hope that the answer is the same for both tests.

The CL interpreters I have seen signal an error in (EVAL *TEST-1*);
they are happy to let (EVAL *TEST-2*) modify the global value of FOO.  
A funnier situation occurs when we have

(DEFVAR *TEST-3* '(PROGN (EVAL (BUTLAST *TEST-1*))
			 (DEFUN LEX-TEST ()
				(LET ((FOO T))
				     (SET-FOO NIL)
				     FOO))
			 (LEX-TEST)))

I have actually seen an implementation for which (EVAL *TEST-3*) yields
NIL, but that is clearly erroneous.  Other implementations happily
evaluate *TEST-3* to T, setting the global value of FOO to NIL.  A
stranger situation occurs with

(DEFVAR *TEST-4* '(PROGN (EVAL (BUTLAST *TEST-3*))
			 (COMPILE 'LEX-TEST)
		         (LEX-TEST)))

In the implementations I have tested, (EVAL *TEST-4*) will signal an
error when SET-FOO attempts to change the value of FOO.

Unfortunately, my access to Common Lisp implementations is confined to
one vendor's Beta release and two other implementations to which I have
no hands-on access.  Rather than disparage anyone's implementation on
such slender evidence, I would like to hear from implementors on the
results of evaluating the four tests in the most current versions of
their implementations.

Dan

∂30-Oct-85  0545	jeff%aiva.edinburgh.ac.uk@ucl-cs.ARPA 	Re:  Tentative Schedule for the Common Lisp Meeting
Received: from UCL-CS.ARPA by SU-AI.ARPA with TCP; 30 Oct 85  05:45:14 PST
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK   via Janet with NIFTP
           id a000666; 30 Oct 85 12:26 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@ucl-cs.arpa>
Date: Tue, 29 Oct 85 19:18:29 GMT
To: RPG@su-ai.arpa, common-lisp@su-ai.arpa
Subject: Re:  Tentative Schedule for the Common Lisp Meeting

|Date: 26 Oct 85  1315 PST
|From: Dick Gabriel <RPG@arpa.su-ai>
|Subject: Tentative Schedule for the Common Lisp Meeting   
|
|I have tentatively booked the Hotel Sonesta in Cambridge, Massachusetts,
|for December 16, 17, and 18 for the meeting (not for accommodations). 
|Are these dates acceptable? I must have a firm answer by monday.
|				-rpg-
	
I know this is after monday, but I'm going to send it anyway.  For flying
transatlantic, the 16-18 have the advantage of being over a month away
so that it's possible to buy a reasonable ticket.  But they are almost
certainly into the busy (and expensive) season.  (Last year fares went up
the 13th and then down again around the 27th.)  Still, this way I need
stay only a week to be home for Christmas.

The dates are acceptable, though.

Cheers,
Jeff Dalton
AIAI, University of Edinburgh

∂30-Oct-85  0632	GJC@MIT-MC.ARPA 	Default scope of references 
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 30 Oct 85  06:31:16 PST
Date: Wed, 30 Oct 85 09:33:12 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject:  Default scope of references
To: hoey@NRL-AIC.ARPA
cc: Common-lisp@SU-AI.ARPA
In-reply-to: Msg of 29 Oct 1985 18:09:05 EST (Tue) from Dan Hoey <hoey at nrl-aic.ARPA>
Message-ID: <[MIT-MC.ARPA].698107.851030.GJC>

In the LMI Systems that you have the behavior of your test cases is
controlled by the variable 
 SI::*ALL-FREE-INTERPRETER-VARIABLE-REFERENCES-SPECIAL*, which
defaults to NIL. With this default setting both cases *TEST-1* and
*TEST-2* signal errors as you wish. There was some discussion about
getting rid of this option, or at least defaulting it to T.  In
DOE-MACSYMA for example the setting of this variable must be T,
because of the unrestricted use of EVAL in the pattern matcher code.
The VAX-NIL system system took a different tack, prefering to be
somewhat like the usual compiler approach. An undeclared (SETQ FOO
...) will generate a warning, and then a "FOO assumed special." This
also has its drawbacks.

There is the issue of how correct to be vs how much trouble to
cause users with old habits. Many users of the LMI system set the
variable controlling the behavior to T. Your reported results are not
consistent with the behavior of LMI systems in either setting. Both
variable reference and variable setting are caught, but you report
that variable setting is not caught. Perhaps you evaluated (SET-FOO)
in a lisp-listener instead of as (EVAL '(SET-FOO)). These have
different behaviors because the system is trying to be more forgiving
to top-level calls than to constructs inside programs.

-gjc


∂30-Oct-85  1013	JAR@MIT-MC.ARPA 	absence of (declare (unspecial ...))  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 30 Oct 85  10:13:10 PST
Date: Wed, 30 Oct 85 13:15:05 EST
From: Jonathan A Rees <JAR@MIT-MC.ARPA>
Subject:  absence of (declare (unspecial ...))
To: Common-Lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].698338.851030.JAR>

While we're on the subject of lexical versus special, I'd like to ask if
anyone remembers why there's no UNSPECIAL declaration in Common Lisp.
It seems important enough that there must have been some compelling
reason for its omission.

∂30-Oct-85  1142	DLW@SCRC-STONY-BROOK.ARPA 	Default scope of references 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 30 Oct 85  11:42:20 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 344503; Wed 30-Oct-85 14:42:51-EST
Date: Wed, 30 Oct 85 14:44 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Default scope of references
To: hoey@NRL-AIC.ARPA, Common-lisp@SU-AI.ARPA
In-Reply-To: <499475345/hoey@nrl-aic>
Message-ID: <851030144425.4.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: 29 Oct 1985 18:09:05 EST (Tue)
    From: Dan Hoey <hoey@nrl-aic.ARPA>

In Symbolics Common Lisp, *test-1* returns NIL, *test-2* returns T,
*test-3* returns T, and *test-4* returns T.  No errors are signalled.
As far as I understand the definition of the language, this is correct.

∂30-Oct-85  1225	RWK@SCRC-YUKON.ARPA 	Default scope of references  
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 30 Oct 85  12:25:26 PST
Received: from CROW.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 165515; Wed 30-Oct-85 15:28:22-EST
Date: Wed, 30 Oct 85 15:25 EST
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Default scope of references
To: Dan Hoey <hoey@NRL-AIC.ARPA>
cc: Common-lisp@SU-AI.ARPA
In-Reply-To: <499475345/hoey@nrl-aic>
Message-ID: <851030152528.6.RWK@CROW.SCRC.Symbolics.COM>

    Date: 29 Oct 1985 18:09:05 EST (Tue)
    From: Dan Hoey <hoey@nrl-aic.ARPA>
    (DEFVAR *TEST-1* '(PROGN (DEFUN SET-FOO (VAL)
				    (SETQ FOO VAL))
			     (SET-FOO NIL)))
(eval *test-1*)
==> NIL
foo
==> NIL
    (DEFVAR *TEST-2* '(PROGN (SET 'FOO T)
			     (DEFUN GET-FOO ()
				    FOO)
			     (GET-FOO)))
(eval *test-1*)
==> NIL
foo
==> NIL
    in the absence of (PROCLAIM (SPECIAL FOO)), I somehow expected that
    (EVAL *TEST-1*) and (EVAL *TEST-2*) would each tell me that I was
    accessing a variable that was neither declared special nor lexically
    bound.  According to CLtL, however, ``The general rule is that if the
    symbol occurs textually within a program construct that creates a
    *binding* for a variable of the same name, then the reference is to the
    variable specified by the binding; if no such program construct
    textually contains the reference, then it is taken to refer to the
    special variable of that name.'' [p. 55]  Thus these forms are
    supposedly legally evaluable.  Is this what was intended?  
Yes.
							       Should
    evaluation of these forms be or signal an error?  
No.
						      I would certainly
    hope that the answer is the same for both tests.
It is.

    (DEFVAR *TEST-3* '(PROGN (EVAL (BUTLAST *TEST-1*))
			     (DEFUN LEX-TEST ()
				    (LET ((FOO T))
					 (SET-FOO NIL)
					 FOO))
			     (LEX-TEST)))
(eval *test-3*)
==> T
foo
==> NIL

    (DEFVAR *TEST-4* '(PROGN (EVAL (BUTLAST *TEST-3*))
			     (COMPILE 'LEX-TEST)
			     (LEX-TEST)))
(eval *test-4*)
==> T
foo
==> NIL

I believe the "best" alternative is what VAX/NIL does; namely
give a warning like the compiler.  (It would be best if it
did it only once for a given form).  However, this might be
unpopular with users if this warning interferes with their
interaction.

Of course, the real conclusion to draw from this is to
use the compiler.  Most compilers give you a lot of
static error checking that you won't see interpreted.
For example, if your compiler does wrong-number-of-args
checking, it will check the number of arguments even on
parts of your function that are only called once in a blue
moon.

∂31-Oct-85  0847	MLY@MIT-MC.ARPA 	free variable references in interpreter.   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 31 Oct 85  08:47:35 PST
Date: Thu, 31 Oct 85 11:49:30 EST
From: Richard Mlynarik <MLY@MIT-MC.ARPA>
Subject: free variable references in interpreter.
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].699862.851031.MLY>

GJC has somewhat misstated what happens both in NIL and in the MIT
(lmi) lisp machine interpreters.

The initial decision about whether a free variable reference should be
considered "an error" is made by looking at the environment in which
the form was evaluated, not at a magic variable.

"Top-level" evaluation (the sort of thing the user types at a lisp
listener) passes EVAL an environment object which says `just silently
take any free variable references to be a reference to the special
value of that variable' (which is exactly the same as the mechanism
of function lookup, incidentally)

On the other kettle of fish, "normal" evaluation, made in the null
lexical environment, (EVAL's default) signals an error when a free
variable reference occurs.  (The variable GJC mentioned,
si::*mumble-free-mumble-reference-mumble-special, is used to override
this for the use truly crufty old code which nobody wants to invest
any time in improving.  Anybody else seen binding it should be shot
with a gun)

The result of this is that a user may type "(setq foo *)" and
"(funcall (frob foo) 1)" at a lisp listener without being harrassed
too unduly, but that compiler-style detection of wild references
happens for "(eval '(setq foo *))" and so forth.

[The older way in which NIL's evaluator dealt with this situation,
 (explicitly doing a (PROCLAIM '(SPECIAL ...)) and printing a warning
 to *ERROR-OUTPUT* whenever the interpreter saw a free reference) was
 flushed some time ago in favour of the above scheme]
[Another hack is that that the environment object in the lisp machine
 implementation can also flag that -all- variable references are
 special.  This was intended to be used when people were converting
 code which ran with the old dynamic interpreter.  As it happened, not
 much  seemed to require this sort of degenerate backwardness]

∂31-Oct-85  0947	FAHLMAN@C.CS.CMU.EDU 	free variable references in interpreter.   
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 31 Oct 85  09:46:36 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 31 Oct 85 12:48:36-EST
Date: Thu, 31 Oct 1985  12:48 EST
Message-ID: <FAHLMAN.12155549655.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Richard Mlynarik <MLY@MIT-MC.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: free variable references in interpreter.
In-reply-to: Msg of 31 Oct 1985  11:49-EST from Richard Mlynarik <MLY at MIT-MC.ARPA>


The default behavior of the LMI/MIT version of the Lisp Machine code, as
described by MLY and GJC, is not legal Common Lisp as I understand the
manual (page 55).  In Common Lisp, references to variables not lexically
bound in the current environment are supposed to refer to the special
value of that variable, and should not generate an error (unless the
special variable has no current value).  This is true whether or not the
reference occurs at top level.  One can argue about whether the LMI
behavior is better, but it is not Common Lisp.  At least they provide a
switch which makes the system conform to Common Lisp in this matter, but
I find disturbing the sentiment that anyone setting this switch, except
when dealing with "crufty old code" should be shot, at least if LMI is
advertising their system as a Common Lisp.  In that case, I think that
Common Lisp compatibility should be the default.

-- Scott

∂31-Oct-85  1551	GJC@MIT-MC.ARPA 	free variable references in interpreter.   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 31 Oct 85  15:51:34 PST
Date: Thu, 31 Oct 85 18:53:27 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject:  free variable references in interpreter.
To: Fahlman@C.CS.CMU.EDU
cc: MLY@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
In-reply-to: Msg of Thu 31 Oct 1985  12:48 EST from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[MIT-MC.ARPA].700350.851031.GJC>

The purpose of the interpreter behavior was to be compatible with
compiler behavior that has been the accepted standard for years,
to warn or give some indication on UNDECLARE SPECIAL VARIABLES.
This should be obvious. It has been an invaluable aid in
tracking down problems in code being converted to common-lisp
and I recommend it as an option for everybody.

The default-behavior issue has nothing to do with advertising, it has
to do with the mechanics of customer support. There are two possible
settings, T and NIL. If set to NIL then users will quickly find
problems in their code relating to undeclared variables that are both
globally set and lambda bound. If set to T then most of these common
problems with scoping become more subtle, and instead turn into
lengthy phone calls. In the more rare cases you find someone that
really wants to do (SET 'FOO <x>) then (EVAL <something with FOO>).
This might happen in a production rule system for example. In these
cases we get the chance to advise people to put in the call to
PROCLAIM.

But serious folks. There is a lot more to find disturbing about MLY
than his sentiments. Maybe we'll all get a chance to take our shots
at the next common-lisp meeting.

Let me propose one of my sentiments:
Any lispmachine company that would advertise their machine just:

  "AS A COMMON LISP"

would be underselling it severely. lispmachine companies generally
seem to be saying things along the lines of "SUPPORTS COMMON LISP"
or "RUNS CODE CONFORMING TO THE ..."

But what justifies your too disparaging tone "at least they provide a
switch...?"  Give us some credit here where credit is due, it is
rather that "OF COURSE THEY PROVIDE A SWITCH!!" This is a minor
stylistic difference we have here, not something to get yourself
worked up about, bordering on insult.

There is the letter of the law here vs the intent. One of the major
intents of CL was to have interpreter/compiler compatibility. The
purpose of the LMI switch was merely along these lines.

Isn't much better in the long run to view the CL book as a constitution rather 
than as a statement of dogma?


∂31-Oct-85  1820	FAHLMAN@C.CS.CMU.EDU 	free variable references in interpreter.   
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 31 Oct 85  18:20:39 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 31 Oct 85 21:22:43-EST
Date: Thu, 31 Oct 1985  21:22 EST
Message-ID: <FAHLMAN.12155643250.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   "George J. Carrette" <GJC@MIT-MC.ARPA>
Cc:   common-lisp@SU-AI.ARPA, MLY@MIT-MC.ARPA
Subject: free variable references in interpreter.
In-reply-to: Msg of 31 Oct 1985  18:53-EST from George J. Carrette <GJC at MIT-MC.ARPA>


    But what justifies your too disparaging tone "at least they provide a
    switch...?"  Give us some credit here where credit is due, it is
    rather that "OF COURSE THEY PROVIDE A SWITCH!!" This is a minor
    stylistic difference we have here, not something to get yourself
    worked up about, bordering on insult.

I wasn't trying to insult anybody.  (When I am trying to insult someone,
I generally do a better job of it than this.)  I just didn't want people
seeing this exchange to assume that the behavior you and MLY described
was legal Common Lisp, and that it really is an error to reference an
undeclared special.  Your post gave that impression, and MLY compounded
the problem by saying that the switch in question was only to be used
for backwards compatibility.  So my statement was that the default
behavior you described was not, strictly speaking, legal Common Lisp.  I
also said that "at least" your system provided a switch in it that would
turn on the legal behavior, though MLY had just said that anyone using
that switch should be shot.  The "at least" meant "at least the
switch is there, though some believe that it shouldn't be used."

I happen to agree that it is lousy style to reference undeclared
specials, and I think it is a useful feature in a Common Lisp
implementation to have a mode available where such things get flagged.
I personally would not make this the default, but that is a minor issue.

The more important question is to what extent we should encourage small
improvements that happen to violate the Common Lisp standard, such as it
is.  I have no quarrel with any manufacturer who wants to stand up and
say clearly in their documentation that "we have chosen to deviate from
the Common Lisp standard in the following N ways because we feel that
these changes are improvements".  Maybe LMI has done this; I haven't
seen their documentation.  But if such small deviations, however
well-meaning, are made without proper acknowledgement, they constitute a
real threat to the standardization of the language.  That's why I try to
flag these things when I see them.

-- Scott

∂31-Oct-85  1858	GSB@MIT-MC.ARPA 	free variable references in interpreter.   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 31 Oct 85  18:58:46 PST
Date: Thu, 31 Oct 85 22:00:45 EST
From: "Glenn S. Burke" <GSB@MIT-MC.ARPA>
Subject: free variable references in interpreter.
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].700561.851031.GSB>

In NIL we had at least two years of experience with automatic special
declarations of free variables.  What used to happen was a free
reference would cause, on the first occurrence, a warning message to
be printed, and a special proclamation to be performed.  This was a
big pain and caused a fair amount of grief.

Now, what happens is that a free variable reference generates a
free-variable-reference error.  The result of this is that the user
gets to choose (via the debugger) to globally declare the variable
special, to just use the special value "just this once" (i.e., the
error will occur again), or any other general debugger action.  It
seems fair to me that you should be warned about a free variable which
is not declared within the current lexical scope.  Remember that the
compiler cannot tell what dynamic scope the function will be called
in, so (in the interpreter) blindly and silently using whatever
dynamic value is around doesn't seem to me to be such a hot idea.

And, "OF COURSE IT'S CONTROLLED BY A SWITCH!!!" --
si::*interpreter-special-warn*.

And, as MLY said, we also have special dispensation for the toplevel
null lexical environment to utilize free variables without this
interference, so that one can do things like
	(setq x ...)
without globally corrupting the usage of X.  (If you want to, you use
defparameter instead.)
----------------

I would appreciate it if other people would refrain from describing
what NIL does when they are at all unfamiliar with the development
version.  It is unfortunate that the latest public NIL release came
out 1.5 years ago and the published benchmarks for some reason were
those for the version before that, so i don't need any additional help
in the spread of misinformation.

∂01-Nov-85  0846	gls@THINK-AQUINAS.ARPA 	free variable references in interpreter. 
Received: from THINK.COM by SU-AI.ARPA with TCP; 1 Nov 85  08:46:17 PST
Received: from desiderius by GODOT.THINK.COM via CHAOS; Fri, 1 Nov 85 11:48:22 est
Date: Fri, 1 Nov 85 11:49 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: free variable references in interpreter.
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <FAHLMAN.12155643250.BABYL@C.CS.CMU.EDU>
Message-Id: <851101114946.2.GLS@DESIDERIUS.THINK.COM>

I don't believe there is anything in the Common Lisp book that
explicitly states that a Common Lisp implementation may not signal
errors in any situations not explicitly defined in the book to be
errors.  On tbe other hand, I think there is at least an implicit
expectation that a purely computational section of a valid Common Lisp
program will execute without requiring the user to hit a "resume" key
every three seconds.  I am not sure what we can say in the book about
this without unduly contraining experimentation with programming
environments and debugging tools.

Here is a set of thought experiments about a LISP system.  Question:  in
each case, is it or is is not consistent with the letter and/or the
spirit of Common Lisp?  There are two subcases for each experiment,
according to whether the interpreter or compiler is involved.  I will
use the noun "system" to refer to either the interpreter of the
compiler, and I will use "warning" to mean any action that draws the
user's attention to a message (and that may or may not require explicit
user action before continuing with the computation).  Some of these
examples are intentionally outlandish.

(1) You refer to a function without declaring it first, and the system
gives you a warning.  (Note that I said "declaring", not "defining".
Consider the compiler especially.)

(2) You refer to a special variable without declaring it, and the system
gives you a warning.

(3) You write "(+ x (cons y z))" and the system warns you that CONS
cannot produce (or has not produced) a value that is valid as an
argument to +.

(4) You write
	(COND ((ATOM X) 'A) (T 'C) ((BAZ X) 'D))
and the system warns you that the last COND clause is unreachable.

(5) You write
	(COND ((ATOM X) 'A) ((CONSP X) 'C) ((BAZ X) 'D))
and the system warns you that the last COND clause is unreachable.

(6) You write
	(MULTIPLE-VALUE-BIND (A B C) (FLOOR X Y) ...)
and the system warns you that FLOOR returns only two values.

(7) You use several GO's in a PROG, and the system warns you that this
code will probably be very hard to maintain.

(8) You write
	(DEFUN FIB (N)
	  (COND ((<= N 1) 1))	      ;Note parenthesis error!
	        (T (+ (FIB (- N 1)) (FIB (- N 2)))))
and the system warns you that your code is not properly indented. 

(9) You write
	(DEFUN FIB (N)
	       (COND ((<= N 1) 1)
	       (T (+ (FIB (- N 1))
               (FIB (- N 2))))))
and the system warns you that your code is not properly indented. 

(10) You write a DO loop, and the system warns you that it could have
been expressed more simply and efficiently by using a call to RASSOC
with the :TEST-NOT and :KEY options.

(11) You write two nested DO loops, and the system warns you that the
SORT primitive is much better than the bubble sort that you wrote.

(12) You write
	(DEFUN FIB (N) (IF (ZEROP N) 1 (* N (FIB (- N 1)))))
and the system warns you that your function FIB is computing factorials
and not Fibonacci numbers.

Is there some generalization we can derive from these thought
experiments, or others, that is worth putting in the book?

--Guy

∂01-Nov-85  1136	FAHLMAN@C.CS.CMU.EDU 	free variable references in interpreter.   
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 Nov 85  11:36:04 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 1 Nov 85 14:37:33-EST
Date: Fri, 1 Nov 1985  14:37 EST
Message-ID: <FAHLMAN.12155831623.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Guy Steele <gls@AQUINAS.THINK.COM>
Cc:   common-lisp@SU-AI.ARPA
Subject: free variable references in interpreter.
In-reply-to: Msg of 1 Nov 1985  11:49-EST from Guy Steele <gls at THINK-AQUINAS.ARPA>


    I don't believe there is anything in the Common Lisp book that
    explicitly states that a Common Lisp implementation may not signal
    errors in any situations not explicitly defined in the book to be
    errors.  On tbe other hand, I think there is at least an implicit
    expectation that a purely computational section of a valid Common Lisp
    program will execute without requiring the user to hit a "resume" key
    every three seconds.  I am not sure what we can say in the book about
    this without unduly contraining experimentation with programming
    environments and debugging tools.

If Common Lisp is to be of any value at all as a standard promoting
portable software, the following assumption has to be true (or as close
to true as we can possibly make it): If an implementation claims to be a
Common Lisp or a superset of Common Lisp, any legal program that
conforms to what is in the manual and uses nothing that is not in the
manual ought to run in that implementation.  "Run" means "run without
signalling any errors".  I'm not sure we need Guy's hedge about "purely
computational"; I don't know what he means by that, but if he means "not
involving user-interface or system-interface" issues, I think we have
excluded most of that from the current language spec, and have indicated
the range of permissible variation in the remaining cases.

Of course, this is more a goal than an iron-clad rule, since the manual
is ambiguous and incomplete in some areas.  Still, I think that we
should state this explicitly and strive to achieve it.  I thought that
we already had stated this or something close to it, but maybe not.  On
the question of how we say this without unduly constraining
experimentation, I don't see that as a problem.  People should feel free
to experiment all they want, but if they knowingly violate the standard
they should point that out and not claim to be a Common Lisp (in those
specific respects).  Manufactuers would be well-advised to provide a
mode that that is strictly kosher Common Lisp -- as close as they can
come, anyway -- and if they want to experiment with incompatible
improvements, these should be enabled by a switch of some sort.
Ideally, it should be straightforward to get at the strict Common Lisp;
you should not have to poke around setting 53 undocumented switches,
some of them guarded by people with guns, in order to get behavior that
conforms to the standard.

Given the above, I think I can answer all of Guy's queries with a single
statement of principle:

When operating as a strict Common Lisp, the system should run any legal
Common Lisp program without signalling any ERRORS.  If the system wants
to mumble warnings and critiques of my style, that's fine -- the more,
the better -- as long as these warnings are of a sort that I am free to
turn them off or at least ignore them.  If the warnings require some
explicit action in order for me to proceed, or if they cause my
compilation not to complete properly, then that is not OK, unless this
is an optional behavior that I can easily get rid of.  I don't mind the
intereter mumbling warnings (into some separate stream, so that they
don't mess up what my legal but unstylish program is trying to print),
though customers will have varying opinions about how much they want to
pay for such criticism at runtime.

Doesn't that cover it?  I think that Guy threw us a curve by asking
whether warnings were OK in various situations, while saying that these
"warnings" might or might not require some explicit action -- to me, that
is the critical issue.

Of course, a few of Guy's examples are so outlandish that I would find
the warnings in question irritating.  Perhaps we need several levels:
Error, Warning, Style Critique, Friendly Advice, Kibitz.

-- Scott

∂01-Nov-85  1242	shebs%utah-orion@utah-cs.arpa 	Declaring Functions
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 1 Nov 85  12:41:22 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
	id AA20713; Fri, 1 Nov 85 13:45:59 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
	id AA07112; Fri, 1 Nov 85 13:45:55 MST
Date: Fri, 1 Nov 85 13:45:55 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8511012045.AA07112@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Declaring Functions

The notion of a function type is mentioned in two places: p. 47 of the
CLM, where the (function ...) type specifier is defined, and p. 158-159,
where (ftype ...) and (function ...) are defined as options to declare.
Are they intended to be the same?  If so, then the second definition
should say that keywords and a (values ...) type specifier are allowed.
If not, then what is the point of a function type specifier, since you
can't feed it to typep anyway?

Also, what is the intended syntax for lambda lists with keywords in
a type specifier?  Somehow,

(deftype make-seq-type ()
  '(function (type integer &key initial-element t) sequence))

doesn't look quite right... Has anybody done anything but punt on
function declarations?

							stan shebs

∂01-Nov-85  1529	DCP@SCRC-STONY-BROOK.ARPA 	free variable references in interpreter.   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 1 Nov 85  15:29:19 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 346455; Fri 1-Nov-85 17:57:03-EST
Date: Fri, 1 Nov 85 17:59 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: free variable references in interpreter.
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
    Guy Steele <gls@AQUINAS.THINK.COM>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12155831623.BABYL@C.CS.CMU.EDU>
Message-ID: <851101175928.6.DCP@NEPONSET.SCRC.Symbolics.COM>

Talking about supersets...

It seems obvious that supersets can extend functions by allowing more
optional arguments or additional keywords to those already specified in
CLtL.  For example, Symbolics' make-array can take a
:displaced-conformally keyword to do multidimensional displacement in a
slightly different way than specified.

That's all well and good for the function calling direction, but what
about the receiving direction?  That is, we have had requests to have
GETHASH return three values instead of two, the third being the key as
stored in the hash table, which might be EQUAL but not EQ to the given
to GETHASH.  This third value seems OK since most applications will only
be looking for one or two values.  But what about subtle cases like
	(multiple-value-list (gethash key hash-table))
or
	(multiple-value-call #'list
			     (gethash key1 hash-table)
			     (gethash key2 hash-table))
where the difference is readily apparent.

Therefore, I have two questions:

Do we all agree that extra optional arguments or additional keyword
arguments are an upward compatible extension and that programs that do
not use these extensions should run on other implementations?

What about the extra values problem?  Note that CLtL does not have a way
to say I want <n> values as a result of executing this form.  Again,
programs that do not use the extra values will run on all
implementations, except for those places (such as the above examples)
where the extra values are visible.

∂01-Nov-85  1721	FAHLMAN@C.CS.CMU.EDU 	free variable references in interpreter.   
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 Nov 85  17:21:28 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 1 Nov 85 20:22:41-EST
Date: Fri, 1 Nov 1985  20:22 EST
Message-ID: <FAHLMAN.12155894458.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: free variable references in interpreter.
In-reply-to: Msg of 1 Nov 1985  17:59-EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>


I think that it is OK for an implementation to take extra args and
keywords on the built-in functions.  I can't think of any reasonable
ways in which this breaks correct Common Lisp programs, though it might
make trouble if the Common Lisp standard is later extended to allow
additional arguments that are not the same as the ones this
implementation has chosen.

I think that extra multiple values are another thing that ought to be
legal, but unfortunately there are ways in which these would break
certain legal but odd programs, as you point out.  I think we blew the
language design here -- we just weren't thinking of this issue when we
nailed down the multiple-value stuff.

So, I suppose that in order to be 100% legal, an implementation should
not return extra values, unless perhaps they can be turned off with a
switch.  As deviations go, however, this is a pretty harmless class of
them, breaking only rather odd code.  So if there is a really good
reason to return extra values as an extension, it might be reasonable to
go ahead and do this, as long as this minor deviation from the standard
is carefully documented as such.

-- Scott

∂02-Nov-85  2052	isrlist@tove.umd.edu 	defvar, defparameter, :unbound   
Received: from TOVE.UMD.EDU by SU-AI.ARPA with TCP; 2 Nov 85  20:52:38 PST
Received: by tove.umd.edu (5.5/4.7)
	id AA00775; Sat, 2 Nov 85 23:55:45 EST
Date: Sat, 2 Nov 85 23:55:45 EST
Message-Id: <8511030455.AA00775@tove.umd.edu>
From: Nick Papadakis <isrlist@tove.umd.edu>
To: common-lisp@su-ai.ARPA
Subject: defvar, defparameter, :unbound


On the lispmachines, defvar will take a second argument of :unbound,
meaning that the variable will be initialized to an unbound state.

This occaisionally convenient feature should probably be added to
common-lisp, and defparameter should be extended to handle it as well.

	- nic

∂03-Nov-85  0510	GJC@MIT-MC.ARPA 	extra features/values  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Nov 85  05:10:40 PST
Date: Sun,  3 Nov 85 08:12:39 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject:  extra features/values
To: DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA, Fahlman@C.CS.CMU.EDU,
    gls@AQUINAS.THINK.COM
In-reply-to: Msg of Fri 1 Nov 85 17:59 EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
Message-ID: <[MIT-MC.ARPA].703111.851103.GJC>

How about (gethash key hash-table :give-me-extra-stuff t).

∂03-Nov-85  0719	SOLEY@MIT-MC.ARPA 	defvar, defparameter, :unbound 
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Nov 85  07:19:17 PST
Date: Sun,  3 Nov 85 10:21:19 EST
From: Richard Mark Soley <SOLEY@MIT-MC.ARPA>
Subject:  defvar, defparameter, :unbound
To: isrlist@TOVE.UMD.EDU
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Sat 2 Nov 85 23:55:45 EST from Nick Papadakis <isrlist at tove.umd.edu>
Message-ID: <[MIT-MC.ARPA].703165.851103.SOLEY>

    Date: Sat, 2 Nov 85 23:55:45 EST
    From: Nick Papadakis <isrlist at tove.umd.edu>
    To:   common-lisp at su-ai.ARPA
    Re:   defvar, defparameter, :unbound

    On the lispmachines, defvar will take a second argument of :unbound,
    meaning that the variable will be initialized to an unbound state.

    This occaisionally convenient feature should probably be added to
    common-lisp, and defparameter should be extended to handle it as well.

I disagree.  (defvar foo :unbound), to me, reads "set the value of the
symbol 'foo' to the symbol 'unbound' in the keyword package.  I think
(defvar foo) is more readable.

	-- Richard

∂03-Nov-85  0724	SOLEY@MIT-MC.ARPA 	extra features/values
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Nov 85  07:24:06 PST
Date: Sun,  3 Nov 85 10:26:06 EST
From: Richard Mark Soley <SOLEY@MIT-MC.ARPA>
Subject:  extra features/values
To: GJC@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA, Fahlman@C.CS.CMU.EDU,
    gls@AQUINAS.THINK.COM, DCP@SCRC-QUABBIN.ARPA
In-reply-to: Msg of Sun  3 Nov 85 08:12:39 EST from George J. Carrette <GJC at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].703168.851103.SOLEY>

    Date: Sun,  3 Nov 85 08:12:39 EST
    From: George J. Carrette <GJC at MIT-MC.ARPA>
    To:   DCP at SCRC-QUABBIN.ARPA
    cc:   common-lisp at SU-AI.ARPA, Fahlman at C.CS.CMU.EDU,
          gls at AQUINAS.THINK.COM
    Re:   extra features/values

    How about (gethash key hash-table :give-me-extra-stuff t).

This solves the GETHASH problem, but not the general problem (there are
likely to be many more functions from which a particular implementation wants
to return more values).  And I don't think adding the :give-me-extra-stuff
keyword to every one of them helps.  I think the one, central,
*ARE-WE-IN-PURE-COMMON-LISP-YET?* switch should control extra return value
behavior, to help the poor user who codes

(nth 2 (append (multiple-value-list (gethash key1 hasht1))
	       (multiple-value-list (gethash key2 hasht2)))

	-- Richard

∂04-Nov-85  0846	DCP@SCRC-QUABBIN.ARPA 	free variable references in interpreter.  
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 4 Nov 85  08:44:12 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 217507; Mon 4-Nov-85 11:45:30-EST
Date: Mon, 4 Nov 85 11:49 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: free variable references in interpreter.
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
    George J. Carrette <GJC@MIT-MC.ARPA>,
    Richard Mark Soley <SOLEY@MIT-MC.ARPA>,
    David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM
In-Reply-To: <FAHLMAN.12155894458.BABYL@C.CS.CMU.EDU>,
             <[MIT-MC.ARPA].703111.851103.GJC>,
             <[MIT-MC.ARPA].703168.851103.SOLEY>
Message-ID: <851104114947.1.DCP@NEPONSET.SCRC.Symbolics.COM>

I disagree with what GJC said, because of the reasons Soley gave, but I
disagree with Soley's counter on aesthetic reasons.  Suppose there were
a magic switch.  What would the end of GETHASH look like?
	(return-from gethash
	  (if *pure-cl*
	      (values entry got-it-p)
	      (values entry got-it-p key-stored-in-hash-table)))
That doesn't appeal to me, and neither does
	(multiple-value-call #'values
			     (values entry got-it-p)
			     (if *pure-cl* (values) (values key-stored-in-hash-table)))
I suppose this could be packaged as macros, but then I ask you: is it
reasonable for people to have to bind *pure-cl* to NIL (presumably it
has to default to to) in order to get extra values?  How is this really
different from GJC's request-is-via-optional-arguments-on-the-call-side?

A couple more random points of information.  I think multiple-value-call
is a poor name.  It should be called multiple-value-funcall.  The
symbolics system has a special form called sys:%multiple-value-call-n
which looks like
	(sys:%multiple-value-call-n fun vals1 n1 vals2 n2 ...)
which is more-or-less a highly optimized
	(multiple-value-call #'fun
			     (multiple-value-bind (v1 v2 ... vn1)
				 vals1
			       (values v1 v2 ... vn1))
			     (multiple-value-bind (v1 v2 ... vn2)
				 vals2
			       (values v1 v2 ... vn2))
			     ...)
In other words, fun is unquoted (for esoterit historical reasons I can
never remember), and the pairs of values-count say effectively "evaluate
valsM for nM values."  This win about this special form is that it is
insensitive to extra values because the caller explicitly says how many
values are requested.


∂04-Nov-85  1022	@MIT-MC.ARPA:Soley@MIT-MC.ARPA 	free variable references in interpreter.   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Nov 85  10:21:55 PST
Received: from MIT-CHERRY.ARPA by MIT-MC.ARPA via Chaosnet; 4 NOV 85  13:23:14 EST
Date: Mon, 4 Nov 85 13:23 EST
From: Soley@MIT-MC.ARPA
Subject: free variable references in interpreter.
To: DCP@SCRC-QUABBIN.ARPA, Fahlman@C.CS.CMU.EDU, GJC@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM
In-Reply-To: <851104114947.1.DCP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <851104132305.1.SOLEY@CHERRY.MIT.EDU>

    Date: Mon, 4 Nov 85 11:49 EST
    From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
    Subject: free variable references in interpreter.
    To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
	George J. Carrette <GJC@MIT-MC.ARPA>,
	Richard Mark Soley <SOLEY@MIT-MC.ARPA>,
	David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
    cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM

    I disagree with what GJC said, because of the reasons Soley gave, but I
    disagree with Soley's counter on aesthetic reasons.  Suppose there were
    a magic switch.  What would the end of GETHASH look like?
	    (return-from gethash
	      (if *pure-cl*
		  (values entry got-it-p)
		  (values entry got-it-p key-stored-in-hash-table)))
    That doesn't appeal to me.

Meta-point: I don't think we should care whether the IMPLEMENTATION code
is appealing or not, but whether code written in Common Lisp itself is
appealing.  I think the form above is fine.

I think that the usual way such a switch would be used would be used
would be one of:

(1) Some macro, like (IN-LOCAL-CL-DIALECT-SUPERSET (gethash . . .))

(2) "-*- Dialect: Symbolics-Common-Lisp -*-" in the file's attribute
    list.

(3) A global proclamation: (PROCLAIM '(SUPER-WINNING-LOCAL-DIALECT T)).

	-- Richard

∂04-Nov-85  1022	@MIT-MC.ARPA:Soley@MIT-MC.ARPA 	free variable references in interpreter.   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Nov 85  10:22:24 PST
Received: from MIT-CHERRY.ARPA by MIT-MC.ARPA via Chaosnet; 4 NOV 85  13:23:37 EST
Date: Mon, 4 Nov 85 13:23 EST
From: Soley@MIT-MC.ARPA
Subject: free variable references in interpreter.
To: DCP@SCRC-QUABBIN.ARPA, Fahlman@C.CS.CMU.EDU, GJC@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM
In-Reply-To: <851104114947.1.DCP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <851104132305.1.SOLEY@CHERRY.MIT.EDU>

    Date: Mon, 4 Nov 85 11:49 EST
    From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
    Subject: free variable references in interpreter.
    To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
	George J. Carrette <GJC@MIT-MC.ARPA>,
	Richard Mark Soley <SOLEY@MIT-MC.ARPA>,
	David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
    cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM

    I disagree with what GJC said, because of the reasons Soley gave, but I
    disagree with Soley's counter on aesthetic reasons.  Suppose there were
    a magic switch.  What would the end of GETHASH look like?
	    (return-from gethash
	      (if *pure-cl*
		  (values entry got-it-p)
		  (values entry got-it-p key-stored-in-hash-table)))
    That doesn't appeal to me.

Meta-point: I don't think we should care whether the IMPLEMENTATION code
is appealing or not, but whether code written in Common Lisp itself is
appealing.  I think the form above is fine.

I think that the usual way such a switch would be used would be used
would be one of:

(1) Some macro, like (IN-LOCAL-CL-DIALECT-SUPERSET (gethash . . .))

(2) "-*- Dialect: Symbolics-Common-Lisp -*-" in the file's attribute
    list.

(3) A global proclamation: (PROCLAIM '(SUPER-WINNING-LOCAL-DIALECT T)).

	-- Richard

∂04-Nov-85  1240	DLW@SCRC-STONY-BROOK.ARPA 	defvar, defparameter, :unbound   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Nov 85  12:40:00 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 347463; Mon 4-Nov-85 15:41:20-EST
Date: Mon, 4 Nov 85 15:44 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: defvar, defparameter, :unbound
To: common-lisp@SU-AI.ARPA
In-Reply-To: <8511030455.AA00775@tove.umd.edu>
Message-ID: <851104154406.6.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Sat, 2 Nov 85 23:55:45 EST
    From: Nick Papadakis <isrlist@tove.umd.edu>

    On the lispmachines, defvar will take a second argument of :unbound,
    meaning that the variable will be initialized to an unbound state.

I'm not sure which Lisp machine this message is supposed to apply to,
but just for the record, the Symbolics system does not do this.

∂04-Nov-85  1447	AS%hp-hulk.csnet@CSNET-RELAY.ARPA 	functions that return nonstandard extra values    
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 4 Nov 85  14:47:25 PST
Received: from hplabs by csnet-relay.csnet id ab03268; 4 Nov 85 17:50 EST
Received: by HP-VENUS id AA02886; Mon, 4 Nov 85 09:44:50 pst
Message-Id: <8511041744.AA02886@HP-VENUS>
Date: Mon 4 Nov 85 09:43:53-PST
From: Alan Snyder <AS%hplabs.csnet@CSNET-RELAY.ARPA>
Subject: functions that return nonstandard extra values
To: common-lisp@su-ai.arpa
Source-Info:  From (or Sender) name not authenticated.

Why not use the traditional solution of giving these
nonstandard functions different names?  Then you don't
have to worry about them becoming incompatible should
the standard be extended to have more return values.
-------

∂04-Nov-85  1500	hplabs!perdue%hplabs.csnet@CSNET-RELAY.ARPA 	Re: free variable references in interpreter. 
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 4 Nov 85  15:00:16 PST
Received: from hplabs by csnet-relay.csnet id af03268; 4 Nov 85 17:56 EST
Received: by HP-VENUS id AA10185; Mon, 4 Nov 85 14:24:06 pst
Message-Id: <8511042224.AA10185@HP-VENUS>
Date: Monday, November 4, 1985  14:21:50
From: perdue%hplabs.csnet@CSNET-RELAY.ARPA
Subject: Re: free variable references in interpreter.
To: common-lisp@su-ai.arpa
In-Reply-To: Your message of  1-Nov-85  14:37:00
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
Source-Info:  From (or Sender) name not authenticated.

Scott Fahlman's comments on permissibility of warning and error
messages when not called for by the Common LISP definition
look good to me.

Portably written code should port without hassles, and drawing
the line between warnings and errors looks right.  Warning
messages for legal code are OK sometimes as default behavior,
but signalling errors is not.

-------

∂04-Nov-85  1703	DCP@SCRC-STONY-BROOK.ARPA 	functions that return nonstandard extra values  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Nov 85  16:19:43 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 347618; Mon 4-Nov-85 19:22:09-EST
Date: Mon, 4 Nov 85 19:25 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: functions that return nonstandard extra values
To: Alan Snyder <AS%hplabs.csnet@CSNET-RELAY.ARPA>,
    common-lisp@SU-AI.ARPA
In-Reply-To: <8511041744.AA02886@HP-VENUS>
Message-ID: <851104192526.3.DCP@NEPONSET.SCRC.Symbolics.COM>

    Date: Mon 4 Nov 85 09:43:53-PST
    From: Alan Snyder <AS%hplabs.csnet@CSNET-RELAY.ARPA>

    Why not use the traditional solution of giving these
    nonstandard functions different names?  Then you don't
    have to worry about them becoming incompatible should
    the standard be extended to have more return values.

Because code that does a GETHASH but wants an extra value will have a
wart called GETHASH-MAGIC (or whatever, but not GETHASH), which could
conceivably double the number of functions in the superset.  If CL
changes, and it does so slowly because it is a standard, extensions are
expected to become compatible with the new standard and applications
that used the old extensions must be modified.  Note they would have to
be modified anyway in order to take advantage of the change to CL.

∂04-Nov-85  1858	GJC@MIT-MC.ARPA 	functions that return nonstandard extra values  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Nov 85  18:58:47 PST
Date: Mon,  4 Nov 85 22:00:48 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject:  functions that return nonstandard extra values
To: DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA, AS%hplabs.csnet@CSNET-RELAY.ARPA
In-reply-to: Msg of Mon 4 Nov 85 19:25 EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
Message-ID: <[MIT-MC.ARPA].705135.851104.GJC>

On the bright side, the existence of a standard helps system maintainers
to resist users continually asking for changes to the language that
have but minor benefit, such as this gethash thing. With only
a minor change in efficiency the user could store (CONS <key> <value>)
in the hash table, and get what he wanted, the EQ'ified key and
the value. If a user was really interested in efficiency he wouldnt
use the hairy system-provided hash table implementations anyway.

∂04-Nov-85  1925	DLW@SCRC-STONY-BROOK.ARPA 	Declaring Functions    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Nov 85  19:23:48 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 347679; Mon 4-Nov-85 22:26:17-EST
Date: Mon, 4 Nov 85 22:29 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Declaring Functions
To: shebs%utah-orion@UTAH-CS.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <8511012045.AA07112@utah-orion.ARPA>
Message-ID: <851104222904.2.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Fri, 1 Nov 85 13:45:55 MST
    From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)

    The notion of a function type is mentioned in two places: p. 47 of the
    CLM, where the (function ...) type specifier is defined, and p. 158-159,
    where (ftype ...) and (function ...) are defined as options to declare.
    Are they intended to be the same?  

Read page 159 more carefully.  It explains that they have the same
meaning, but are syntactically different.  "function" has the
disadvantage that you can only declare one thing per clause, unlike most
other declarations, but the advantage that it looks mildly like "defun".
				       
				       If so, then the second definition
    should say that keywords and a (values ...) type specifier are allowed.

If by keywords you mean &optional and friends, it isn't strictly
necessary to repeat that, although it would sure clear things up if
there were a cross reference in the book.

However, there appears to be a typo on page 159.  The form following the
phrase "entirely equivalent to", which currently reads

 (ftype (function arglist result-type1 result-type2 ...) name)

ought to read

  (ftype (function arglist (values result-type1 result-type2 ...)) name)

in order to be consistent with page 47.

∂04-Nov-85  1934	DLW@SCRC-STONY-BROOK.ARPA 	functions that return nonstandard extra values  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Nov 85  19:34:06 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 347683; Mon 4-Nov-85 22:33:07-EST
Date: Mon, 4 Nov 85 22:35 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: functions that return nonstandard extra values
To: GJC@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA, AS%hplabs.csnet@CSNET-RELAY.ARPA
In-Reply-To: <[MIT-MC.ARPA].705135.851104.GJC>
Message-ID: <851104223554.3.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Mon,  4 Nov 85 22:00:48 EST
    From: "George J. Carrette" <GJC@MIT-MC.ARPA>

	       If a user was really interested in efficiency he wouldnt
    use the hairy system-provided hash table implementations anyway.

This is completely the opposite of our point of view, which is that it
is the job of the system to provide usable and efficient tools.

∂04-Nov-85  2019	GSB@MIT-MC.ARPA 	defvar, defparameter, :unbound   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Nov 85  20:16:59 PST
Date: Mon,  4 Nov 85 23:18:59 EST
From: "Glenn S. Burke" <GSB@MIT-MC.ARPA>
Subject: defvar, defparameter, :unbound
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].705297.851104.GSB>

    From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
        Date: Sat, 2 Nov 85 23:55:45 EST
        From: Nick Papadakis <isrlist@tove.umd.edu>

        On the lispmachines, defvar will take a second argument of :unbound,
        meaning that the variable will be initialized to an unbound state.

    I'm not sure which Lisp machine this message is supposed to apply to,
    but just for the record, the Symbolics system does not do this.

This hack was added to NIL.  My personal feeling is that the special
case value is just asking to screw some poor user whose code just
happens to naively use :UNBOUND to mean something...   But i added the
defvar hack anyway, because the ability to do both the defvar and
specify the documentations string in a single form seemed worth it.
Doing
	(defvar *foo*)
	(setf (documentation '*foo* 'variable) "Documentaiton string")
looks pretty crufty.  Keyworded defvar, anyone?

∂05-Nov-85  0734	DCP@SCRC-STONY-BROOK.ARPA 	functions that return nonstandard extra values  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 5 Nov 85  07:34:06 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 347879; Tue 5-Nov-85 10:31:04-EST
Date: Tue, 5 Nov 85 10:34 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: functions that return nonstandard extra values
To: George J. Carrette <GJC@MIT-MC.ARPA>, DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA, AS%hplabs.csnet@CSNET-RELAY.ARPA
In-Reply-To: <[MIT-MC.ARPA].705135.851104.GJC>
Message-ID: <851105103431.9.DCP@NEPONSET.SCRC.Symbolics.COM>

    Date: Mon,  4 Nov 85 22:00:48 EST
    From: "George J. Carrette" <GJC@MIT-MC.ARPA>

    On the bright side, the existence of a standard helps system maintainers
    to resist users continually asking for changes to the language that
    have but minor benefit, such as this gethash thing. With only
    a minor change in efficiency the user could store (CONS <key> <value>)
    in the hash table, and get what he wanted, the EQ'ified key and
    the value.
This is no longer a simple hash table, as GETHASH doesn't get the value.
Instead, the user must do (CDR (GETHASH ...)), and MUST do it in all
places.  There are other problems with this solution.  PUTHASH over an
existing entry will change the key, forcing the user to do a GETHASH
first.  This is almost MODIFY-HASH, which is an efficiency item missing
from CL.
    If a user was really interested in efficiency he wouldnt
    use the hairy system-provided hash table implementations anyway.
I agree with DLW's reply to this statement.

∂05-Nov-85  0941	gls@THINK-AQUINAS.ARPA 	functions that return nonstandard extra values
Received: from THINK.COM by SU-AI.ARPA with TCP; 5 Nov 85  09:41:06 PST
Received: from desiderius by GODOT.THINK.COM via CHAOS; Tue, 5 Nov 85 12:41:19 est
Date: Tue, 5 Nov 85 12:42 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: functions that return nonstandard extra values
To: DLW@SCRC-QUABBIN.ARPA, GJC@MIT-MC.ARPA
Cc: common-lisp@SU-AI.ARPA, AS%hplabs.csnet@CSNET-RELAY.ARPA,
        gls@THINK-AQUINAS.ARPA
In-Reply-To: <851104223554.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <851105124241.2.GLS@DESIDERIUS.THINK.COM>

    Date: Mon, 4 Nov 85 22:35 EST
    From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>

	Date: Mon,  4 Nov 85 22:00:48 EST
	From: "George J. Carrette" <GJC@MIT-MC.ARPA>

		   If a user was really interested in efficiency he wouldnt
	use the hairy system-provided hash table implementations anyway.

    This is completely the opposite of our point of view, which is that it
    is the job of the system to provide usable and efficient tools.

My feeling exactly.  If implementations are such that users find it
desirable to ignore most of the built-in functions and roll their own,
then we have failed:  we might as well have used a smaller dialect, such
as SCHEME or PSL.  Common Lisp took the direction it did precisely
because we thought that all the built-in functions would be useful to
users.

--Guy

∂05-Nov-85  0950	gls@THINK-AQUINAS.ARPA 	defvar, defparameter, :unbound 
Received: from THINK.COM by SU-AI.ARPA with TCP; 5 Nov 85  09:49:47 PST
Received: from desiderius by GODOT.THINK.COM via CHAOS; Tue, 5 Nov 85 12:51:56 est
Date: Tue, 5 Nov 85 12:53 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: defvar, defparameter, :unbound
To: GSB@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <[MIT-MC.ARPA].705297.851104.GSB>
Message-Id: <851105125319.3.GLS@DESIDERIUS.THINK.COM>

    Date: Mon,  4 Nov 85 23:18:59 EST
    From: "Glenn S. Burke" <GSB@MIT-MC.ARPA>

	From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
	    Date: Sat, 2 Nov 85 23:55:45 EST
	    From: Nick Papadakis <isrlist@tove.umd.edu>

	    On the lispmachines, defvar will take a second argument of :unbound,
	    meaning that the variable will be initialized to an unbound state.

	I'm not sure which Lisp machine this message is supposed to apply to,
	but just for the record, the Symbolics system does not do this.

    This hack was added to NIL.  My personal feeling is that the special
    case value is just asking to screw some poor user whose code just
    happens to naively use :UNBOUND to mean something...   But i added the
    defvar hack anyway, because the ability to do both the defvar and
    specify the documentations string in a single form seemed worth it.
    Doing
	    (defvar *foo*)
	    (setf (documentation '*foo* 'variable) "Documentaiton string")
    looks pretty crufty.  Keyworded defvar, anyone?

One idea that was discussed previously was
	(defvar *foo* *foo* "Documentation string")
which self-evidently means "declare *foo* and initialize to its existing
value", but by special dispensation it arranges to work even when *foo*
is already unbound, i.e., it leaves it alone.  This is fine for DEFVAR,
but is less appealing for DEFPARAMETER.
--Guy

∂05-Nov-85  1154	isrlist@tove.umd.edu 	defvar, defparameter, :unbound   
Received: from TOVE.UMD.EDU by SU-AI.ARPA with TCP; 5 Nov 85  11:54:25 PST
Received: by tove.umd.edu (5.5/4.7)
	id AA01113; Tue, 5 Nov 85 12:36:00 EST
Date: Tue, 5 Nov 85 12:36:00 EST
Message-Id: <8511051736.AA01113@tove.umd.edu>
From: Nick Papadakis <isrlist@tove.umd.edu>
To: SOLEY@MIT-MC.ARPA
Cc: common-lisp@SU-AI.ARPA
In-Reply-To: Richard Mark Soley's message of Sun,  3 Nov 85 10:21:19 EST
Subject: defvar, defparameter, :unbound


   I disagree.  (defvar foo :unbound), to me, reads "set the value of the
   symbol 'foo' to the symbol 'unbound' in the keyword package.  I think
   (defvar foo) is more readable.

	   -- Richard

What if you want to use the optional documentation argument, as in

	(defvar foo :unbound "I am initially unbound.")  ???

How can you document it and yet leave it unbound too?

The problem initially arose when re-writing some code that made heavy
use of 

	(unless (boundp 'foo) ...

as a means of insuring that variables were initialized.  The variables
were NOT initialized in the defvar itself since re-initialization was
frequent and interactive.

	- nic

∂05-Nov-85  1213	LOOSEMORE@UTAH-20.ARPA 	queries about *query-io*  
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 5 Nov 85  12:13:52 PST
Date: Tue 5 Nov 85 13:16:24-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: queries about *query-io*
To: common-lisp@SU-AI.ARPA
Message-ID: <12156887294.22.LOOSEMORE@UTAH-20.ARPA>

What should *query-io* be bound to when running Lisp in "batch mode" where
normal input comes from a script file and there is not necessarily a
terminal or interactive process associated with the Lisp process?  For the
purposes of y-or-n-p, it might be reasonable to bind *query-io* to the
script file, since these are questions expected by the user and the answers
could be included in the script file.  However, for unexpected questions
asked via yes-or-no-p, this approach would almost certainly fail.  Or,
*query-io* could be left unbound or it could be bound to an empty stream.

This leads to the second problem:  what should y-or-n-p and yes-or-no-p
do if *query-io* is unbound or has an end-of-file condition?  Since there
is no way to specify a default value to be returned, I think signalling an
error is about the only reasonable thing to do.  Comments?

-Sandra Loosemore
-------

∂05-Nov-85  1239	DCP@SCRC-STONY-BROOK.ARPA 	defvar, defparameter, :unbound   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 5 Nov 85  12:38:57 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 348169; Tue 5-Nov-85 15:41:25-EST
Date: Tue, 5 Nov 85 15:44 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: defvar, defparameter, :unbound
To: Guy Steele <gls@THINK-AQUINAS.ARPA>, GSB@MIT-MC.ARPA,
    common-lisp@SU-AI.ARPA
In-Reply-To: <851105125319.3.GLS@DESIDERIUS.THINK.COM>
Message-ID: <851105154455.3.DCP@NEPONSET.SCRC.Symbolics.COM>

    Date: Tue, 5 Nov 85 12:53 EST
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>

	Date: Mon,  4 Nov 85 23:18:59 EST
	From: "Glenn S. Burke" <GSB@MIT-MC.ARPA>

	    From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
		Date: Sat, 2 Nov 85 23:55:45 EST
		From: Nick Papadakis <isrlist@tove.umd.edu>

		On the lispmachines, defvar will take a second argument of :unbound,
		meaning that the variable will be initialized to an unbound state.

	    I'm not sure which Lisp machine this message is supposed to apply to,
	    but just for the record, the Symbolics system does not do this.

	This hack was added to NIL.  My personal feeling is that the special
	case value is just asking to screw some poor user whose code just
	happens to naively use :UNBOUND to mean something...   But i added the
	defvar hack anyway, because the ability to do both the defvar and
	specify the documentations string in a single form seemed worth it.
	Doing
		(defvar *foo*)
		(setf (documentation '*foo* 'variable) "Documentaiton string")
	looks pretty crufty.  Keyworded defvar, anyone?

    One idea that was discussed previously was
	    (defvar *foo* *foo* "Documentation string")
    which self-evidently means "declare *foo* and initialize to its existing
    value", but by special dispensation it arranges to work even when *foo*
    is already unbound, i.e., it leaves it alone.  This is fine for DEFVAR,
    but is less appealing for DEFPARAMETER.

Recall that DEFPARAMETER's initial value is not optional, with implied
(perhaps stated) semantics that it must always have a value.

∂05-Nov-85  1517	HENRIK@MIT-MC.ARPA 	queries about *query-io* 
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 Nov 85  15:15:27 PST
Date: Tue,  5 Nov 85 18:17:28 EST
From: "Lawrence A. DeLuca, Jr." <HENRIK@MIT-MC.ARPA>
Subject:  queries about *query-io*
To: LOOSEMORE@UTAH-20.ARPA
cc: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].706637.851105.HENRIK>


I guess the closest analogy to "batch mode" the lisp machine offers is
a deexposed window with a process running in it.  In this case, when
a process wants to type out or needs input the user is sent a message
that the window requires attention, a la:

	Process SUPDUP1 Wants to type out.

The process can continue to output, and the text will be displayed the
next time the user exposes the window.  When typein is required, the
process will wait until the required input is supplied. It would
probably be most reasonable to have the output of *query-io* go to
*standard-output*.

As to the question of (y-or-n-p ... ), most batch processes are only
going to use some such construct to signal an unusual event, so it
would probably be better to have the process wait for input (assuming
there is some method to "attach" to the process provided) as opposed
to merely signaling and error and returning, or worse, aborting.

					larry...


∂05-Nov-85  1655	LOOSEMORE@UTAH-20.ARPA 	Re: queries about *query-io*   
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 5 Nov 85  16:55:29 PST
Date: Tue 5 Nov 85 17:57:57-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: Re: queries about *query-io*
To: HENRIK@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[MIT-MC.ARPA].706637.851105.HENRIK>
Message-ID: <12156938550.9.LOOSEMORE@UTAH-20.ARPA>

I'm afraid this approach would not work very well in a multi-user
environment.  In VMS, for example, the user can submit a job to a batch
queue and then log off the interactive terminal and go away for a week.  It
would not be looked upon very kindly by other users to have this batch job
sitting indefinitely waiting for the user to log back on again so it can
ask him/her a question, and all the while consuming cpu time and clogging up
the batch queue.  And the problem is not unique to VMS -- one can do similar
things under Unix and probably other operating systems as well.

-Sandra
-------

∂06-Nov-85  0400	GJC@MIT-MC.ARPA 	(GETHASH X Y)  ==> (CDR (GETHASH X Y))
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Nov 85  04:00:19 PST
Date: Wed,  6 Nov 85 07:02:23 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject:  (GETHASH X Y)  ==> (CDR (GETHASH X Y))
To: DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA, AS%hplabs.csnet@CSNET-RELAY.ARPA
In-reply-to: Msg of Tue 5 Nov 85 10:34 EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
Message-ID: <[MIT-MC.ARPA].707437.851106.GJC>

It is ridiculous to assume that users program via QUERY-REPLACE in EMACS,
or through the "looks productive" CONTROL-K CONTROL-Y method.
More likely it is the case that:

(DEFUN DATABASE-LOOKUP (...)
   (GETHASH ...) ... (PUTHASH ....))

For one thing the user might consider GETHASH to be a silly name.


∂06-Nov-85  0429	GJC@MIT-MC.ARPA 	functions that return nonstandard extra values  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Nov 85  04:27:25 PST
Date: Wed,  6 Nov 85 07:29:27 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject:  functions that return nonstandard extra values
To: DLW@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA, AS%hplabs.csnet@CSNET-RELAY.ARPA
In-reply-to: Msg of Mon 4 Nov 85 22:35 EST from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
Message-ID: <[MIT-MC.ARPA].707467.851106.GJC>

    Date: Mon, 4 Nov 85 22:35 EST
    From: Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
    To:   GJC at MIT-MC.ARPA
    cc:   common-lisp at SU-AI.ARPA, AS%hplabs.csnet at CSNET-RELAY.ARPA
    Re:   functions that return nonstandard extra values

        Date: Mon,  4 Nov 85 22:00:48 EST
        From: "George J. Carrette" <GJC@MIT-MC.ARPA>

    	       If a user was really interested in efficiency he wouldnt
        use the hairy system-provided hash table implementations anyway.

    This is completely the opposite of our point of view, which is that it
    is the job of the system to provide usable and efficient tools.

Oh, I love your use of the royal WE/OUR here. Lets not make this into
a OUR-COMPANY (RA RA!!!) vs others kind of thing. I'm talking
about what lispmachine systems provide NOW. Remember how long it
took the lispmachine crew to adopt semantically correct SETF, long
after other implementations had done so. The track record is not good.
In fact, the track record is one of unabated changes that continously
break major applications packages in minor ways, diverting resources,
and all in the name of progress. (RA RA).

If your soapbox stand is that it is my(i.e. LMI's) view that
the system does not have to provide usable and efficient tools then
a retraction of your statement is in order.

But the Common-Lisp system lacks many useful basic tools. Functions for
manipulating circular queues, or recursive alists (like TRI's), or
resolution nets. It lacks a DEFSTRUCT that can deal with
the same kind of data that STRUCT in C deals with. (Disk Controller blocks,
Filesystem records, network packets defined by programmers in the non-lisp
world, etc). There are many things a user will have to build himself.


∂06-Nov-85  0738	MEEHAN@YALE.ARPA 	CL erratissimo   
Received: from YALE.ARPA by SU-AI.ARPA with TCP; 6 Nov 85  07:37:52 PST
Received: by Yale-Bulldog.YALE.ARPA; 6 Nov 85 10:30:50 EST (Wed)
Message-Id: <8511061530.AA07724@Yale-Bulldog.YALE.ARPA>
Date:    Wed, 6 Nov 85 10:33:11 EST
From: Jim Meehan <Meehan@YALE.ARPA>
Subject: CL erratissimo
To: common-lisp@SU-AI

Section 7.9.2, Rules Governing the Passing of Multiple Values, is indexed
under "multiple values," sub-indexed under "rules governing parsing of."
                                                              ↑
(Not exactly your random typo.)
-------

∂06-Nov-85  0904	mips!escargot.earl@glacier 	defvar, defparameter, :unbound  
Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 6 Nov 85  09:04:12 PST
Received: by glacier with Sendmail; Wed, 6 Nov 85 09:05:50 pst
Received: from escargot.UUCP (escargot.ARPA) by mips.UUCP (4.12/4.7)
	id AA14102; Wed, 6 Nov 85 07:03:44 pst
Received: by escargot.UUCP (4.12/4.7)
	id AA06129; Wed, 6 Nov 85 07:02:16 pst
Date: Wed, 6 Nov 85 07:02:16 pst
From: mips!escargot.earl@glacier (Earl Killian)
Message-Id: <8511061502.AA06129@escargot.UUCP>
To: Glacier!isrlist@tove.umd.edu
Cc: SOLEY@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: Nick Papadakis's message of Tue, 5 Nov 85 12:36:00 EST
Subject: defvar, defparameter, :unbound

This doesn't seem important enough to become a language feature; one
of advantages of lisp is that you could have written a DOCVAR macro
that does what you want for this one particular application, and then
just done
	(docvar foo "Foo is unbound")
instead of
	(defvar foo :unbound "Foo is unbound")

∂06-Nov-85  0947	gls@THINK-AQUINAS.ARPA 	CL erratissimo  
Received: from THINK.COM by SU-AI.ARPA with TCP; 6 Nov 85  09:47:35 PST
Received: from desiderius by GODOT.THINK.COM via CHAOS; Wed, 6 Nov 85 12:49:40 est
Date: Wed, 6 Nov 85 12:51 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: CL erratissimo
To: Meehan@YALE.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <8511061530.AA07724@Yale-Bulldog.YALE.ARPA>
Message-Id: <851106125102.4.GLS@DESIDERIUS.THINK.COM>

    Date:    Wed, 6 Nov 85 10:33:11 EST
    From: Jim Meehan <Meehan@YALE.ARPA>

    Section 7.9.2, Rules Governing the Passing of Multiple Values, is indexed
    under "multiple values," sub-indexed under "rules governing parsing of."
								  ↑
    (Not exactly your random typo.)
    -------

Snows me.  Good eye!
--Guy

∂08-Nov-85  1646	FAHLMAN@C.CS.CMU.EDU 	astronaut  example on p.313      
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 8 Nov 85  16:46:36 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 8 Nov 85 19:18:25-EST
Date: Thu, 7 Nov 1985  22:10 EST
Message-ID: <FAHLMAN.12157486962.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: astronaut  example on p.313  
In-reply-to: Msg of 7 Nov 1985  14:56-EST from S Sridhar <sridhar%tekchips%tektronix.csnet at CSNET-RELAY.ARPA>


    On p.313, we've
     (setq x (make-astronaut :name 'buzz :age 45
    			 :sex t :helmet-size 17.5))
    I don't like this :sex t. It would be perhaps more appropriate
    to have :sex 'm or :sex 'f or ...

    --sridhar

A deliberate joke on Guy's part, I believe.  A more amusing value might
be 7.3, however...

-- Scott

∂08-Nov-85  1648	FAHLMAN@C.CS.CMU.EDU 	Language spec should be public domain 
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 8 Nov 85  16:46:07 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 8 Nov 85 19:18:24-EST
Date: Thu, 7 Nov 1985  22:06 EST
Message-ID: <FAHLMAN.12157486280.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   REM@MIT-MC.ARPA
Cc:   COMMON-LISP@SU-AI.ARPA
Subject: Language spec should be public domain
In-reply-to: Msg of 1985 Nov 07 15:27:32 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.SU.EDU>


    Before CL can ever become very widely used (like ASCII for example),
    it must become an ANSI/CCITT/ISO standard...

I disagree totally with this view.  Lots of things are widely used that
are not blessed by these particular bureaucracies.  But I do agree with
the view that the proprietary nature of the document is hurting us, and
is hurting some more than others.

-- Scott

∂08-Nov-85  1649	gls@THINK-AQUINAS.ARPA 	Common Lisp manual online?
Received: from THINK.COM by SU-AI.ARPA with TCP; 8 Nov 85  16:49:31 PST
Received: from desiderius by GODOT.THINK.COM via CHAOS; Fri, 8 Nov 85 14:37:01 est
Date: Fri, 8 Nov 85 14:38 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Common Lisp manual online?
To: Fahlman@C.CS.CMU.EDU, Masinter.pa@XEROX.ARPA
Cc: Common-Lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <FAHLMAN.12157444377.BABYL@C.CS.CMU.EDU>
Message-Id: <851108143815.3.GLS@THINK-DESIDERIUS.ARPA>

I can report that Dr. Toru Ishida of Nippon Telephone and Telegraph
requested of Digital Press permission to acquire a machine-readable copy
of the manual for research purposes (research into developing an on-line
query system), and this permission was granted relatively quickly (a
month or so).  So that's one precedent.  It's not the same as a
precedent for making the manual available on-line for commercial use.
Maybe someone would like to help establish one promptly?  The way
lawyers are, I can push all I want for a policy from a theoretical point
of view, but you won't get action until there is an actual instance for
them to chew on.

--Guy

∂08-Nov-85  1651	gls@THINK-AQUINAS.ARPA 	astronaut  example on p.313    
Received: from THINK.COM by SU-AI.ARPA with TCP; 8 Nov 85  16:50:17 PST
Received: from desiderius by GODOT.THINK.COM via CHAOS; Fri, 8 Nov 85 14:16:28 est
Date: Fri, 8 Nov 85 14:17 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: astronaut  example on p.313  
To: sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 7 Nov 85 14:56-EST from S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
Message-Id: <851108141743.2.GLS@THINK-DESIDERIUS.ARPA>

    Date: Thursday, 7 Nov 85 11:56:33 PST
    From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>

    On p.313, we've
     (setq x (make-astronaut :name 'buzz :age 45
			     :sex t :helmet-size 17.5))
    I don't like this :sex t. It would be perhaps more appropriate
    to have :sex 'm or :sex 'f or ...

    --sridhar

I suppose that this is one of the "subtly witty" things that Winston had
in mind (see the quote on the back cover).  The entire point is that it
isn't clear.  Then again it is: it says that the astronaut has a sex,
but doesn't say which.  (HAL, in the movie 2001, is an examples of an
astronaut that has no sex.)  I'm sorry you don't like it.  It certainly
is not exemplary of god programming style.  Maybe we should change it in
the next edition.

--Guy

∂08-Nov-85  1705	hplabs!snyder%hplabs.csnet@CSNET-RELAY.ARPA 	compiler-let (clarification needed)
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 8 Nov 85  17:05:38 PST
Received: from hplabs by csnet-relay.csnet id ah07165; 8 Nov 85 8:25 EST
Received: by HP-VENUS id AA06577; Thu, 7 Nov 85 16:34:35 pst
Message-Id: <8511080034.AA06577@HP-VENUS>
Date: Thursday, November 7, 1985  08:41:25
From: snyder%hplabs.csnet@CSNET-RELAY.ARPA
Subject: compiler-let (clarification needed)
To: common-lisp@su-ai.arpa
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
Source-Info:  From (or Sender) name not authenticated.

The definition of COMPILER-LET (page 112) states that when executed by the
"Lisp interpreter", COMPILER-LET behaves exactly like LET (with all the
variable bindings implicitly declared SPECIAL).  However, on page 143 it
states that a Common Lisp implementation might, for example, expand macros in
a DEFUN at the time the DEFUN is executed.

Since the primary purpose of COMPILER-LET is to provide for the communication
of information at macro expansion time, I believe that if an implementation
(even when "interpreting") expands macros before run-time, then it should
process a COMPILER-LET at that same time, in which case COMPILER-LET is NOT the
same as LET.

The definition of COMPILER-LET should be changed to make this clear.

  Alan Snyder
-------
-------

∂08-Nov-85  2244	PGS%MIT-OZ@MIT-MC.ARPA 	astronaut  example on p.313    
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 8 Nov 85  22:43:57 PST
Date: Sat, 9 Nov 1985  01:47 EST
Message-ID: <PGS.12157788594.BABYL@MIT-OZ>
From: PGS%MIT-OZ@MIT-MC.ARPA
To:   Guy Steele <gls@AQUINAS.THINK.COM>
Cc:   common-lisp@SU-AI.ARPA,
      sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA
Subject: astronaut  example on p.313  
In-reply-to: Msg of 8 Nov 1985  14:17-EST from Guy Steele <gls at THINK-AQUINAS.ARPA>

    Date: Friday, 8 November 1985  14:17-EST
    From: Guy Steele <gls at THINK-AQUINAS.ARPA>

        Date: Thursday, 7 Nov 85 11:56:33 PST
        From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>

        On p.313, we've
         (setq x (make-astronaut :name 'buzz :age 45
    			     :sex t :helmet-size 17.5))
        I don't like this :sex t. It would be perhaps more appropriate
        to have :sex 'm or :sex 'f or ...

    I suppose that this is one of the "subtly witty" things that Winston had
    in mind (see the quote on the back cover).  The entire point is that it
    isn't clear.  Then again it is: it says that the astronaut has a sex,
    but doesn't say which.  (HAL, in the movie 2001, is an examples of an
    astronaut that has no sex.)  I'm sorry you don't like it.  It certainly
    is not exemplary of god programming style.  Maybe we should change it in
    the next edition.

Gee, I always read it as an allusion to the joke in which a job applicant,
filling out an employment application form, chews over the SEX: ←←←←
question for a while, and then writes in "Occasionally."

∂09-Nov-85  1115	DLW@SCRC-STONY-BROOK.ARPA 	Suggested addition to the index of CLtL    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Nov 85  11:13:45 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 351262; Sat 9-Nov-85 14:15:43-EST
Date: Sat, 9 Nov 85 14:20 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Suggested addition to the index of CLtL
To: common-lisp@SU-AI.ARPA
Message-ID: <851109142016.5.DLW@CHICOPEE.SCRC.Symbolics.COM>

We've had several users who tried to figure out how to copy an array in
Common Lisp, and could not find a function in CLtL to do it.  The
function is COPY-SEQ, but if you set off trying to find a function to
copy an array, you can miss it pretty easily.  Perhaps an index entry
for "copying arrays" could be added to the index in the next edition, to
direct the programming to COPY-SEQ.  ("Copying list", too, couldn't
hurt.)  Thanks.

∂09-Nov-85  1606	RPG  	Meeting: The Details    
To:   common-lisp@SU-AI.ARPA
After much hassle and complaint, terror and theats; after a month
of ill-feelings and fights, I've scheduled the Common Lisp meeting
for specific days, at a specific place, and I am sending out the message
essentially 1 month ahead of time.

I know some of you will not like the details I have settled on.

The meeting will be Monday, Tuesday, Wednesday, Decembers 9, 10,
and 11; at:

	Boston Marriott Hotel Copley Place
        110 Huntington Avenue
	Boston, Massachusetts 02117
	(617)236-5800

The room will be ours from 8:30am until 6:00pm each of those days.
There is a block of rooms at that hotel set aside for us. I understand
that it is a fancy hotel, and the rooms are not cheap, even with
the discount I got for the meeting. The rooms are $100 single and
$115 double, which is $60 off the regular rate. When you make your
reservations, specifically mention the Common Lisp meeting.

The block of rooms will be held for us until November 25, and
they can be booked for the evenings of Decemeber 8, 9, 10.

The usual caveats apply to this hotel: a reservation without
a guarantee will only hold the room until 6:00pm of the evening
of your arrival. A guarantee is usually an American Express card
number.

The meeting room will hold 250 easily, but I understand that up to
350 could fit. The sessions will be sequential, not parallel.

There is a non-zero chance that DARPA will not be able to pay for the
meeting room; the hotel doesn't seem to want to give it to us free
if we fill up 75 rooms, which is unusual - they claim they need closer
to 200 filled by us to give us such a large meeting room. In the event
DARPA will not help us out, I will be approaching the vendors for contributions
towards the meeting room. For now, Lucid is fronting the money.

We can get coffee and pastry delivered to the meeting room in the mornings,
but it will also cost us. To do that would cost about $7.75 per person. 
Is there an interest in this happening? If so, I will go ahead with the
arrangements, and perhaps you'll be dunned later. 

The major topics as I see them are:

	1. Charter
	2. Adoption of changes discussed on this list
	3. Plans for a second edition
	4. Public Domain/Online manual
	5. Object-oriented programming 
	6. Windows
	7. Error Handling
	8. Validation

I expect specific proposals to be discussed for topics 1, 5, 6, 7, and 8.

Vendors and implementation groups are allowed to send 2 voting individuals
(3 official repesentatives altogether), user groups are allowed to send 1
voting individual (2 official representatives altogether), and individuals
of standing in the community are allowed to attend and possibly vote.
Groups that are not implementing a Common Lisp, but who are proposing a
standard in some area which they intend to implement, are allowed to send
2 voting members for that session only.

Any one of Scott Fahlman, Guy Steele, or myself is allowed to grant
an individual standing in the community for the purposes of attending
the meeting as a voting individual. 

I will allow into the room any observers up to a number which,
added to the voting and accessory repesentatives, leaves the room
comfortable. Thus, a vendor can send more than 3 people, but only
3 will be guaranteed spots in the room.  In general, only the
official representatives and the qualified voting individuals will
be allowed to speak.

I hope we have a pleasant and productive meeting. See you all in
1 month.
			-rpg-

Common-lisp/su
Reminder about the Common Lisp Meeting

I would like to remind you about the Common Lisp meeting, which will be
Monday, Tuesday, Wednesday, Decembers 9, 10, and 11; at:

	Boston Marriott Hotel Copley Place
        110 Huntington Avenue
	Boston, Massachusetts 02117
	(617)236-5800

The room will be ours from 8:30am until 6:00pm each of those days.
There is a block of rooms at that hotel set aside for us. I understand
that it is a fancy hotel, and the rooms are not cheap, even with
the discount I got for the meeting. The rooms are $100 single and
$115 double, which is $60 off the regular rate. When you make your
reservations, specifically mention the Common Lisp meeting.

Here is an important piece of information:

************************************************************************
*								       *
*   The block of rooms will be held for us until November 25, and      *
*   they can be booked for the evenings of Decemeber 8, 9, 10.         *
*								       *
************************************************************************

The usual caveats apply to this hotel: a reservation without
a guarantee will only hold the room until 6:00pm of the evening
of your arrival. A guarantee is usually an American Express card
number.

			-rpg-
∂10-Nov-85  1828	EVAN@SU-CSLI.ARPA 	Pointers to vax/unix version   
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 10 Nov 85  18:27:55 PST
Date: Sun 10 Nov 85 18:28:42-PST
From: Evan Kirshenbaum <evan@SU-CSLI.ARPA>
Subject: Pointers to vax/unix version
To: common-lisp@SU-AI.ARPA

I've been trying (unsuccessfully) for a while to track down a version
of Common Lisp (or even a reasonable subset) that runs under 4.2BSD
Unix.  This is a very elusive animal, as everyone has heard rumours of
one, but nobody has every quite seen it.  Any pointers anyone could
give would be most helpful and much appreciated.

Evan Kirshenbaum 
ARPA: evan@SU-CSLI 
UUCP: {ucbvax | decvax}!decwrl!glacier!evan

P.S. This is urgent.  I'm doing a prototype using Hedrick's TOPS-20 
     version, and if you don't come through, they're going to make
     me translate it into franz!!!
-------

∂11-Nov-85  0944	Kahn.pa@Xerox.ARPA 	RE: Steele's programming style
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 11 Nov 85  09:43:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 NOV 85 09:34:42 PST
Date: 11 Nov 85 09:34 PST
Sender: Kahn.pa@Xerox.ARPA
Subject: RE: Steele's programming style
To: COMMON-LISP@SU-AI.ARPA
From: bobrow.pa@Xerox.ARPA, kahn.pa@Xerox.ARPA
LineFold: No
Message-ID: <851111-093442-1201@Xerox>

 I suppose that this is one of the "subtly witty" things that Winston had
 in mind (see the quote on the back cover).  The entire point is that it
 isn't clear.  Then again it is: it says that the astronaut has a sex,
 but doesn't say which.  (HAL, in the movie 2001, is an examples of an
 astronaut that has no sex.)  I'm sorry you don't like it.  It certainly
 is not exemplary of god programming style.  Maybe we should change it in
 the next edition.

 --Guy

" not exemplary of god programming style "

We suppose god would never simply affirm sex,
but would be more explicit.


∂18-Nov-85  1331	gls@THINK-AQUINAS.ARPA 	TYPEP and arrays of (SATISFIES F)   
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 18 Nov 85  13:31:02 PST
Received: from THINK-HILARION.ARPA by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 1220; Mon 18-Nov-85 16:35:19-EST
Date: Mon, 18 Nov 85 16:35 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: TYPEP and arrays of (SATISFIES F)
To: common-lisp@SU-AI.ARPA
cc: gls@THINK-AQUINAS.ARPA
Message-ID: <851118163500.9.GLS@THINK-HILARION.ARPA>

Bob Rorschach has raised the following question:  what is the
result of (TYPEP (MAKE-ARRAY 10) '(ARRAY (SATISFIES F) (10)))
supposed to be?  Consider these special cases:

	(TYPEP (MAKE-ARRAY 10 :ELEMENT-TYPE INTEGER)
	       '(ARRAY (SATISFIES FIXNUMP) (10)))

	(TYPEP (MAKE-ARRAY 10 :ELEMENT-TYPE FIXNUM)
	       '(ARRAY (SATISFIES FIXNUMP) (10)))

We can easily dismiss the first case, because clearly an array
specialized to hold integers is not necessarily the same as one
specialized to hold fixnums.  The second is more difficult.  It happens
to be the case that FIXNUM and (SATISFIES FIXNUMP) are equivalent type
specifiers, but in many implementations SUBTYPEP cannot discern this
fact (and indeed is not required to).

When TYPEP sees a plain old SATISFIES specifier, it can just call the
function, but not so when it is the element type of an ARRAY specifier.

One way out (proposed language change) is to define TYPEP to be like
SUBTYPEP, in that it returns two values; if the first value is NIL, the
second value says whether that's a "no" or a "maybe".  So for the
first special case above TYPE would return either NIL T or NIL NIL,
depending on the cleverness of the implementation, and for the second
special case would return either NIL NIL or T T.

--Guy

∂19-Nov-85  0056	RAM@C.CS.CMU.EDU 	:Structure-Print and *print-level*   
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 Nov 85  00:56:36 PST
Received: ID <RAM@C.CS.CMU.EDU>; Tue 19 Nov 85 03:56:29-EST
Date: Tue, 19 Nov 1985  03:56 EST
Message-ID: <RAM.12160433529.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: :Structure-Print and *print-level*


    The current depth in printing is an argument to defstruct
structure printing functions.  If the print function calls print
recursively, should print start over again at zero, or do something
else?  If the depth in printing is preserved across the call to the
structure-print function, should it be the same in the recursive call,
or one greater?

  Rob

∂19-Nov-85  1346	KESSLER@UTAH-20.ARPA 	Universal Catch   
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 19 Nov 85  13:46:40 PST
Date: Tue 19 Nov 85 14:45:20-MST
From: Robert R. Kessler <KESSLER@UTAH-20.ARPA>
Subject: Universal Catch
To: common-lisp@SU-AI.ARPA
Message-ID: <12160573501.22.KESSLER@UTAH-20.ARPA>

One of the "features" of PSL is that if the tag of a catch is NIL, then
that catch will catch any throw.  This feature is especially nice when
writing top loops and similar functions that you want to permit
arbitrary interaction with throws.  Does CL provide a similar functionality
(I haven't seen anything similar in the manual)?  Is it an extension that
might be included in CL-86 (or whatever we call it)?  Comments?

Bob.
-------

∂19-Nov-85  1645	REM@IMSSS 	CATCH-ALL
Received: from IMSSS by SU-AI with PUP; 19-Nov-85 16:45 PST
Date: 19 Nov 1985 1641-PST
From: Rem@IMSSS
Subject: CATCH-ALL
To:   KESSLER%UTAH-20.ARPA@SCORE
cc:   COMMON-LISP@SU-AI

MacLISP and ZetaLisp (Symbolics LISP Machine) had/have that feature too.
CATCH-ALL was/is a macro that generates the appropriate (:CATCH NIL form).
But the ZetaLisp manual says if you think you need this you probably want
UNWIND-PROTECT instead.
Perhaps what we really need is an extra feature in UNWIND-PROTECT, whereby
the cleaup forms can find out why they are being called. Some global
variable can be SETQ'd by the unwinding mechanism, to NIL in the case of
falling out of the main form nomally, to ERROR in the case of an error
signal that is being passed up to an errset, or to the tag if a THROW
is happening. This would give the cleanup form the opportunity to
intercept certain tags in the same way CATCH-ALL did in MacLISP, but
maybe be a bit cleaner? Or maybe we really need CATCH-ALL because it
woul be cleaner than the enhanced UNWIND-PROTECT. Esthetic opinion anybody?
-------

∂19-Nov-85  1657	RWK@SCRC-YUKON.ARPA 	Universal Catch    
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 19 Nov 85  16:57:15 PST
Received: from CROW.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 172000; Tue 19-Nov-85 19:56:36-EST
Date: Tue, 19 Nov 85 19:53 EST
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Universal Catch
To: Robert R. Kessler <KESSLER@UTAH-20.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <12160573501.22.KESSLER@UTAH-20.ARPA>
Message-ID: <851119195331.3.RWK@CROW.SCRC.Symbolics.COM>

    Date: Tue 19 Nov 85 14:45:20-MST
    From: Robert R. Kessler <KESSLER@UTAH-20.ARPA>

    One of the "features" of PSL is that if the tag of a catch is NIL, then
    that catch will catch any throw.  This feature is especially nice when
    writing top loops and similar functions that you want to permit
    arbitrary interaction with throws.  Does CL provide a similar functionality
    (I haven't seen anything similar in the manual)?  Is it an extension that
    might be included in CL-86 (or whatever we call it)?  Comments?

I don't understand how this helps write "top loops".
It sure makes it hard to figure out why your program suddenly
quit to top level because somewhere you misspelled HEIRARCHY
in a THROW.  It's much more useful if it is an error.

I can think of other arbitrary interactions you could permit
with THROW; why is this one any better? ;-)

I think what you are really looking for here is a "catch-barrier",
which says "never throw above here", so you don't accidentally
throw out of your breakpoint or debugger?  I think that's better,
but it makes it harder to deliberatly continue by throwing out
to some tag.  If I remember right, I think NIL has such a feature.

∂19-Nov-85  1739	kessler%utah-orion@utah-cs.arpa 	Re:  Universal Catch  
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 19 Nov 85  17:36:49 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
	id AA17394; Tue, 19 Nov 85 18:36:48 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
	id AA07391; Tue, 19 Nov 85 18:36:45 MST
Date: Tue, 19 Nov 85 18:36:45 MST
From: kessler%utah-orion@utah-cs.arpa (Robert Kessler)
Message-Id: <8511200136.AA07391@utah-orion.ARPA>
To: RWK@scrc-yukon.arpa
Subject: Re:  Universal Catch
Cc: common-lisp@su-ai.arpa

Yes, a catch barrier is what I am thinking about.  My top loop analogy
was just that, you want to be able to keep any errors or extraneous throws
from leaving your top loop.  One does need to be able to get the value
of the tag though.  I suppose that one could use a really disgusting
hack with unwind-protect where instead of exiting in the cleanup forms,
the code could recursively call the top loop.  Geez that would be a real
hack ;-)

Bob.

∂19-Nov-85  1925	GSB@MIT-MC.ARPA 	catching
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 19 Nov 85  19:25:15 PST
Date: Tue, 19 Nov 85 22:27:38 EST
From: "Glenn S. Burke" <GSB@MIT-MC.ARPA>
Subject: catching
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].724785.851119.GSB>

NIL contains two undocumented special operators CATCHALL and
CATCH-BARRIER.

CATCHALL takes an argument list (function &body body).  It evaluates
and saves function, then evaluates the body as a progn.  If a THROW is
performed through this construct, the function gets invoked on two
arguments:  the tag being thrown to, and the value being thrown.
Obviously this is incorrect wrt throwing multiple values;  the obvious
correction is to make the function get called on all of the values
being thrown.  The idea is, however, that one can inspect the tag and
repeat the throw as if nothing had happened.  Normal return, and
abnormal returns that do not use THROW (we have a
force-return-from-function-call-frame operation in NIL for use by the
debugger) do not invoke the catchall function, even though they would
invoke the cleanup forms of an unwind-protect.  And, there are NO
special catch tags;  they are objects compared with EQ.

CATCH-BARRIER is just like CATCH, except that it effectively makes all
established CATCH tags outside of its dynamic scope invisible.  I.e.,
	(catch 'foo
	   (catch-barrier 'bar
		(throw 'foo t)))
will complain that FOO is an unseen catch tag.

∨

∂19-Nov-85  1941	@MIT-MC.ARPA:BROOKS@MIT-OZ 	Re:  Universal Catch  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 19 Nov 85  19:40:06 PST
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 19 NOV 85  21:52:51 EST
Date: Tue 19 Nov 85 21:48:59-EST
From: "Rodney A. Brooks" <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: Re:  Universal Catch
To: kessler%utah-orion@UTAH-CS.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8511200136.AA07391@utah-orion.ARPA>
Message-ID: <12160628778.50.BROOKS@MIT-OZ>

    From: kessler%utah-orion@utah-cs.arpa (Robert Kessler)
    Message-Id: <8511200136.AA07391@utah-orion.ARPA>
    To: RWK@scrc-yukon.arpa
    Subject: Re:  Universal Catch
    Cc: common-lisp@su-ai.arpa

    Yes, a catch barrier is what I am thinking about.  My top loop analogy
    was just that, you want to be able to keep any errors or extraneous throws
    from leaving your top loop.  One does need to be able to get the value
    of the tag though.  I suppose that one could use a really disgusting
    hack with unwind-protect where instead of exiting in the cleanup forms,
    the code could recursively call the top loop.  Geez that would be a real
    hack ;-)

    Bob.

You don't need a recursive call. Below will keep doing <stuff> forever.

  (loop (block toplevel
          (unwind-protect <stuff>
                          (return-from toplevel nil))))

Of course it doesn't give you access to the tag that was thrown to.
-------

∂20-Nov-85  0050	sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA 	Extra paren in example on p.430   
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 20 Nov 85  00:47:16 PST
Received: from tektronix by csnet-relay.csnet id ab08617; 20 Nov 85 3:38 EST
From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
To: common-lisp@su-ai.ARPA
Fcc: cl-mail
Received: from tekchips by tektronix with smtp ; 19 Nov 85 13:14:59 PST
Date: Tuesday, 19 Nov 85 13:00:45 PST
Subject: Extra paren in example on p.430

The fourth line in the definition of the function
command-dispatch, the book shows
   (funcall fn)) 
it should be (funcall fn)


--sridhar

∂20-Nov-85  0911	gls@THINK-AQUINAS.ARPA 	Extra paren in example on p.430
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 20 Nov 85  09:11:27 PST
Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 1727; Wed 20-Nov-85 10:18:21-EST
Date: Wed, 20 Nov 85 10:18 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Extra paren in example on p.430
To: sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA,
    common-lisp@SU-AI.ARPA
cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 19 Nov 85 16:00-EST from S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
Message-ID: <851120101831.3.GLS@FAUSTINUS.THINK.COM>

    Date: Tuesday, 19 Nov 85 13:00:45 PST
    From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>

    The fourth line in the definition of the function
    command-dispatch, the book shows
       (funcall fn)) 
    it should be (funcall fn)


    --sridhar

Right you are.  Thank you.
--Guy

∂20-Nov-85  1139	gls@THINK-AQUINAS.ARPA 	Extra paren in example on p.430
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 20 Nov 85  09:11:27 PST
Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 1727; Wed 20-Nov-85 10:18:21-EST
Date: Wed, 20 Nov 85 10:18 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Extra paren in example on p.430
To: sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA,
    common-lisp@SU-AI.ARPA
cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 19 Nov 85 16:00-EST from S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
Message-ID: <851120101831.3.GLS@FAUSTINUS.THINK.COM>

    Date: Tuesday, 19 Nov 85 13:00:45 PST
    From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>

    The fourth line in the definition of the function
    command-dispatch, the book shows
       (funcall fn)) 
    it should be (funcall fn)


    --sridhar

Right you are.  Thank you.
--Guy

∂20-Nov-85  1148	BSG@SCRC-STONY-BROOK.ARPA 	CATCH-ALL    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Nov 85  11:48:04 PST
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 358764; Wed 20-Nov-85 12:42:13-EST
Date: Wed, 20 Nov 85 12:45 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: CATCH-ALL
To: Rem@IMSSS, KESSLER%UTAH-20.ARPA@SU-SCORE.ARPA
cc: COMMON-LISP@SU-AI.ARPA
In-Reply-To: The message of 19 Nov 85 19:41-EST from Rem@IMSSS
Message-ID: <851120124522.4.BSG@CONCORD.SCRC.Symbolics.COM>

    Date: 19 Nov 1985 1641-PST
    From: Rem@IMSSS

    MacLISP and ZetaLisp (Symbolics LISP Machine) had/have that feature too.
    CATCH-ALL was/is a macro that generates the appropriate (:CATCH NIL form).
    But the ZetaLisp manual says if you think you need this you probably want
    UNWIND-PROTECT instead.
    Perhaps what we really need is an extra feature in UNWIND-PROTECT, whereby
    the cleaup forms can find out why they are being called. Some global
    variable can be SETQ'd by the unwinding mechanism, to NIL in the case of
    falling out of the main form nomally, to ERROR in the case of an error
    signal that is being passed up to an errset, or to the tag if a THROW
    is happening. This would give the cleanup form the opportunity to
    intercept certain tags in the same way CATCH-ALL did in MacLISP, but
    maybe be a bit cleaner? Or maybe we really need CATCH-ALL because it
    woul be cleaner than the enhanced UNWIND-PROTECT. Esthetic opinion anybody?
    -------

I think this is all pretty disgusting, and a blatant controversion of
modularity.  I'd like to hear the proposed use of CATCH-ALL, or
whatever.  Please don't confuse it with a need to catch all -errors-,
which is a function of an error system, not catch/throw semantics.

∂20-Nov-85  1417	Moon@SCRC-QUABBIN.ARPA 	Fill-pointers and sequences    
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 20 Nov 85  14:15:57 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 222518; Wed 20-Nov-85 17:14:20-EST
Date: Wed, 20 Nov 85 17:14 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Fill-pointers and sequences
To: Common-Lisp@SU-AI.ARPA
Message-ID: <851120171407.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

Consider this code:

  (setq a (make-array 10 :fill-pointer 3))
  (fill a nil :start (fill-pointer a) :end (array-dimension a 0))

Is this correct Common Lisp?  In our implementation this signals an
error that you are accessing outside the bounds of the sequence, but
I believe that is not correct.  It is accessing outside the bounds
of the sequence, defined by its fill-pointer, but it is not accessing
outside the bounds of the array.

An example application would be filling the part of a array past its
fill-pointer with its initial-element, so the garbage collector doesn't
have to preserve objects referenced by leftover array contents there.

I checked the Common Lisp manual carefully, and it never says what the
legal values for the :start and :end arguments to a sequence function
are, except that :start must not be > than :end.  :end defaults to the
fill-pointer, but it is not clear that it is an error for :end to be
specified larger than the fill-pointer.  Perhaps the answer depends on
exactly how we are to interpret the use of the word "subsequence" in the
first sentence of the last paragraph on page 246.  Does the answer
depend on whether the sequence function in question is one that writes
(like FILL or REPLACE) or one that reads (like POSITION or REMOVE)?

Does anyone have an opinion to offer?

∂20-Nov-85  1428	Moon@SCRC-QUABBIN.ARPA 	Universal Catch 
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 20 Nov 85  14:28:15 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 222525; Wed 20-Nov-85 17:26:48-EST
Date: Wed, 20 Nov 85 17:26 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Universal Catch
To: Robert R. Kessler <KESSLER@UTAH-20.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <12160573501.22.KESSLER@UTAH-20.ARPA>
Message-ID: <851120172629.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue 19 Nov 85 14:45:20-MST
    From: Robert R. Kessler <KESSLER@UTAH-20.ARPA>

    One of the "features" of PSL is that if the tag of a catch is NIL, then
    that catch will catch any throw.  This feature is especially nice when
    writing top loops and similar functions that you want to permit
    arbitrary interaction with throws.  

Please don't confuse THROW with ERROR.  They are different functions for
different purposes.

I realize it's difficult, because Common Lisp hasn't yet acquired an
error-handling system, only a (primitive) error-signalling system.  That
happened because of deadline pressure in getting out the original
language specification.

Good proposals have been made, they only need to be finished.  I hope
this deficiency of Common Lisp can be rectified in finite time; all it
takes is someone to write a complete proposal and an institutional
context for creating a revised language specification.

					Does CL provide a similar functionality
    (I haven't seen anything similar in the manual)?  Is it an extension that
    might be included in CL-86 (or whatever we call it)?  Comments?

Early versions of Common Lisp contained primitives called CATCH-ALL and UNWIND-ALL.
After discussion, they were removed.  They definitely should not be put back in.

∂20-Nov-85  1429	Moon@SCRC-QUABBIN.ARPA 	CATCH-ALL  
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 20 Nov 85  14:29:15 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 222527; Wed 20-Nov-85 17:27:43-EST
Date: Wed, 20 Nov 85 17:27 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: CATCH-ALL
To: Rem@IMSSS
cc: KESSLER%UTAH-20.ARPA@SU-SCORE.ARPA, COMMON-LISP@SU-AI.ARPA
In-Reply-To: The message of 19 Nov 85 19:41-EST from Rem@IMSSS
Message-ID: <851120172724.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 19 Nov 1985 1641-PST
    From: Rem@IMSSS

    MacLISP and ZetaLisp (Symbolics LISP Machine) had/have that feature too.
    CATCH-ALL was/is a macro that generates the appropriate (:CATCH NIL form).
    But the ZetaLisp manual says if you think you need this you probably want
    UNWIND-PROTECT instead.

Just to set the record straight, Zetalisp does not contain CATCH-ALL.

∂20-Nov-85  1432	Moon@SCRC-QUABBIN.ARPA 	CATCH-ALL  
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 20 Nov 85  14:32:27 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 222529; Wed 20-Nov-85 17:28:39-EST
Date: Wed, 20 Nov 85 17:28 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: CATCH-ALL
To: Rem%IMSSS@SU-SCORE.ARPA
cc: COMMON-LISP@SU-AI.ARPA
In-Reply-To: The message of 19 Nov 85 19:41-EST from Rem@IMSSS
Message-ID: <851120172830.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 19 Nov 1985 1641-PST
    From: Rem@IMSSS

    MacLISP and ZetaLisp (Symbolics LISP Machine) had/have that feature too.
    CATCH-ALL was/is a macro that generates the appropriate (:CATCH NIL form).
    But the ZetaLisp manual says if you think you need this you probably want
    UNWIND-PROTECT instead.

Just to set the record straight, Zetalisp does not contain CATCH-ALL.

∂20-Nov-85  1729	FAHLMAN@C.CS.CMU.EDU 	Fill-pointers and sequences 
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Nov 85  17:29:27 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 20 Nov 85 20:29:15-EST
Date: Wed, 20 Nov 1985  20:29 EST
Message-ID: <FAHLMAN.12160876394.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   Common-Lisp@SU-AI.ARPA
Subject: Fill-pointers and sequences
In-reply-to: Msg of 20 Nov 1985  17:14-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>


It seems to me that this is a question of what abstraction we want to
associate with the concept of a "sequence": when a vector is treated as
a sequence, is the sequence only that part of the vector up to the fill
pointer, or the whole thing?  I think that we have pretty consistently
adhered to the former view.  The :start and :end defaults suggest this,
as do the definitions for functions like Length.  Aref is allowed to
reference past the fill pointer, but this is noted in the manual as an
exceptional case.

So if we want to be consistent and minimize confusion, I would argue
that sequence functions should signal an error (or at least that it
should "be an error") if we try to make such functions access past the
fill pointer.  This supports the abstraction that moving the fill
pointer changes the legnth of the sequence.  I think that's what we had
in mind when we put this stuff in, though of course we might not all
have had the same things in mind.

As an additional argument, on page 295 of the manual it says the
following: "Nearly all functions that operate on the contents of a
vector operate only on the active elements.  An important exception is
Aref ..."  A good lawyer could wiggle out of this, but it seems that
this is trying to tell us that vanilla sequence functions should not be
allowed to do things to elements past the fill pointer.

-- Scott

∂21-Nov-85  0702	FAHLMAN@C.CS.CMU.EDU 	:Structure-Print and *print-level*    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Nov 85  07:02:50 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 21 Nov 85 10:02:39-EST
Date: Thu, 21 Nov 1985  10:02 EST
Message-ID: <FAHLMAN.12161024452.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Rob MacLachlan <RAM@C.CS.CMU.EDU>
Cc:   common-lisp@SU-AI.ARPA
Subject: :Structure-Print and *print-level*
In-reply-to: Msg of 19 Nov 1985  03:56-EST from Rob MacLachlan <RAM>


        The current depth in printing is an argument to defstruct
    structure printing functions.  If the print function calls print
    recursively, should print start over again at zero, or do something
    else?  If the depth in printing is preserved across the call to the
    structure-print function, should it be the same in the recursive call,
    or one greater?

      Rob

I was hoping that someone who had thought a lot about printing issues
would jump up and take a crack at this, but since nobody has, I'll give
it a try.  I haven't dealt with printer issues much, so if somebody sees
a deep bogosity in my analsysis, please step forward.

When built-in data structures are being printed, each level of recursion
into sub-structure bumps some hidden counter by 1, and when this value
exceeds *print-level*, the printing becomes terse.  This facility is not
accessible to the user in any way that I can see -- either there is some
special internal call to print that takes a current-depth argument or
print looks at some undocumented special to get this sort of behavior.
The user-accessible Print function, as it is currently defined, would
seem always to set the print-depth back to zero when called explicitly.
At least, in my quick scan of the manual I didn't see any way of doing
this.

The obvious intent in structure printing is that we want users to be
able to write print functions that mimic the behavior of built-in print
methods -- in this way, we hope to make the user-defined structures act
like built-in data types.  So the right thing to do would be to let
these print functions access the current depth, and let them call the
print functions, explicitly passing on the depth argument, usually
incremented by one.

Well, I think we blew it, since user-code has no way of calling Print
and friends with an explicit depth argument, incremented or not.  It
would be possible to add some magic kludge whereby Print and friends
realize that they are being called recursively within a structure-print
routine and somehow figure out what the current depth ought to be.  That
stikes me as being very confusing and dangerous.  I would suggest that
Print and friends continue to reset the depth to zero when called
explicitly, but that sometime soon we should provide a way of slipping
some non-zero current depth to these functions explicitly.  This should
probably be done with an additional optional or keyword arg to the
existing print functions (or maybe just to Write).

-- Scott

∂21-Nov-85  0741	gls@THINK-AQUINAS.ARPA 	Fill-pointers and sequences    
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 21 Nov 85  07:41:17 PST
Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 1935; Thu 21-Nov-85 10:42:42-EST
Date: Thu, 21 Nov 85 10:42 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Fill-pointers and sequences
To: Moon@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA
cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <851120171407.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <851121104241.1.GLS@FAUSTINUS.THINK.COM>

There are two other passages you might consider.  First, page 246, last
paragraph, states that the :start and :end arguments should be integer
indices "into the sequence"; is an index larger than the fill pointer
"into the sequence" or merely "into the vector"?  Second, page 291 notes
that "aref is unusual among the functions that operate on arrays in that
it completely ignores fill pointers".  If we really believed the book to
be careful and accurate, we might infer that other functions not
specifically documented to be in this unusual category may not access
beyond the fill pointer; but in the actual event this inference is shaky
at best.

I think I would be inclined to write the code in this manner:

  (setq a (make-array 10 :fill-pointer 3))

  (let ((old-fill-pointer (shiftf (fill-pointer a) (array-total-size a))))
    (fill a nil :start (fill-pointer a) :end (array-dimension a 0))
    (setf (fill-pointer a) old-fill-pointer))

or, for the truly worried,

  (let ((old-fill-pointer (array-total-size a)))
    (unwind-protect
	(progn (setf (fill-pointer a) (array-total-size a))
	       (fill a nil :start (fill-pointer a) :end (array-dimension a 0)))
      (setf (fill-pointer a) old-fill-pointer)))

I do not feel strongly about which way this issue is resolved, but I
agree that it should be tied down.  I mildly favor a strict interpretation.

--Guy

∂21-Nov-85  0844	gls@THINK-AQUINAS.ARPA 	Fill-pointers and sequences    
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 21 Nov 85  07:41:17 PST
Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 1935; Thu 21-Nov-85 10:42:42-EST
Date: Thu, 21 Nov 85 10:42 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Fill-pointers and sequences
To: Moon@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA
cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <851120171407.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <851121104241.1.GLS@FAUSTINUS.THINK.COM>

There are two other passages you might consider.  First, page 246, last
paragraph, states that the :start and :end arguments should be integer
indices "into the sequence"; is an index larger than the fill pointer
"into the sequence" or merely "into the vector"?  Second, page 291 notes
that "aref is unusual among the functions that operate on arrays in that
it completely ignores fill pointers".  If we really believed the book to
be careful and accurate, we might infer that other functions not
specifically documented to be in this unusual category may not access
beyond the fill pointer; but in the actual event this inference is shaky
at best.

I think I would be inclined to write the code in this manner:

  (setq a (make-array 10 :fill-pointer 3))

  (let ((old-fill-pointer (shiftf (fill-pointer a) (array-total-size a))))
    (fill a nil :start (fill-pointer a) :end (array-dimension a 0))
    (setf (fill-pointer a) old-fill-pointer))

or, for the truly worried,

  (let ((old-fill-pointer (array-total-size a)))
    (unwind-protect
	(progn (setf (fill-pointer a) (array-total-size a))
	       (fill a nil :start (fill-pointer a) :end (array-dimension a 0)))
      (setf (fill-pointer a) old-fill-pointer)))

I do not feel strongly about which way this issue is resolved, but I
agree that it should be tied down.  I mildly favor a strict interpretation.

--Guy

∂21-Nov-85  0846	gls@THINK-AQUINAS.ARPA 	:Structure-Print and *print-level*  
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 21 Nov 85  08:45:40 PST
Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 1958; Thu 21-Nov-85 11:24:58-EST
Date: Thu, 21 Nov 85 11:25 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: :Structure-Print and *print-level*
To: Fahlman@CMU-CS-C.ARPA, RAM@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <FAHLMAN.12161024452.BABYL@C.CS.CMU.EDU>
Message-ID: <851121112509.7.GLS@FAUSTINUS.THINK.COM>

Many thanks to Scott for illuminating this issue.  The idea I had had
in mind was that the defstruct printing function would look something
like

(defun astronaut-print-fn (obj s depth)
   (format s "[***>>> ASTRONAUT!  Name: ")
   (write (astro-name obj) :stream s :level (- *print-level* depth))
   (format s " <<<***]"))

However, this is not quite the right thing if the originally specified
:level argument had not defaulted to the value of *print-level*.

One suggestion is to redefine the third argument to a structure print
function to be "depth remaining", to be compared against zero.  Then
one would write

(defun astronaut-print-fn (obj s depth)
   (format s "[***>>> ASTRONAUT!  Name: ")
   (write (astro-name obj) :stream s :level (- depth 1))
   (format s " <<<***]"))

In retrospect, I think it was not defined this way because in MacLISP
I had frequently found it very convenient, when faced with a large
(possible infinite) printout, to do a break, set PRINLEVEL to some
finite value, and then resume, whereupon the printout would quickly
cut itself off, allowing computation to resume.  The second treatment
shown above would not respond to dynamic changes in *PRINT-LEVEL*.
Is this important?

--Guy

∂21-Nov-85  1030	greek%bach.decnet@hudson.dec.com 	Recursive print & depth abbreviation
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 21 Nov 85  10:28:20 PST
Date: 0  0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Recursive print & depth abbreviation
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
We really have two issues here.

First of all we need a recursive-p argument to the print functions,
including PRINT et al and FORMAT.  This is for precisely the same
reasons as the read functions -- in order to print an object I may
have to use print functions recursively.  It's not clear that there's a
good way to add recursive-p, especially since FORMAT already takes an
&rest argument.  (Excluding FORMAT for some religious reason would be
wrong.)

The second issue is that of print depth.  We never should have passed
the level to a structure print function.  Instead we should have said
that the print system worries about print depth in some automatic
fashion.  After all, the structure print function is going to utilize
the print system to print the structure, so the print system ought to be
able to do the depth abbreviation just fine.  An example of how to do
this is given by Dick Waters' PP facility, which implements all
abbreviation more or less automatically.

Another case in which a top-level versus recursive print must be
distinguished is when the printing system buffers output.  If you
interrupt it in the middle of a print and enter a break loop, clearly a
new set of buffers is required so that the original print can continue
undaunted later on.  The break loop needs to start a new top-level
print.  Hey, it's just like reading!

Passing a level or depth argument to the WRITE function is going to add
even more confusion (particularly given our silly definitions of
level vs. depth).  Anyway, why have we demoted PRINT, PRINC, PRIN1, and
FORMAT to second class functions?  Hell, everybody uses FORMAT in a
structure print function.
------

∂21-Nov-85  1214	hoey@nrl-aic 	Re: :Structure-Print and *print-level*   
Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 21 Nov 85  12:09:40 PST
Date: 21 Nov 1985 13:26:40 EST (Thu)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: :Structure-Print and *print-level*
To: Guy Steele <gls@THINK-AQUINAS.ARPA>
Cc: common-lisp@SU-AI.ARPA
Message-Id: <501445600/hoey@nrl-aic>
In-Reply-To: Guy Steele's message of Thu, 21 Nov 85 1125 EST

    The idea I had had in mind was that the defstruct printing function
    would look something like

    (defun astronaut-print-fn (obj s depth)
       (format s "[***>>> ASTRONAUT!  Name: ")
       (write (astro-name obj) :stream s :level (- *print-level* depth))
       (format s " <<<***]"))

    However, this is not quite the right thing if the originally specified
    :level argument had not defaulted to the value of *print-level*.

Which arises if the printed representation of an astronaut can contain
the p. r. of another astronaut.  But the real problem with this method
is that it confuses the two notions of print level and of print depth.

I see no problem with the hidden variable representing the depth in
printing functions.  My expectation is that this variable should always
be incremented on entry to the function WRITE, and restored on exit.
In this way a user's printing functions that call PRINT or WRITE behave
the same way that WRITE does when it calls itself recursively.

One thing that may not be immediately apparent is that the depth should
be specific to each stream, so that a printing function that uses WRITE
on another stream (presumably as part of determining what its output
should be) is not affected by the depth of the stream that it is to
print its object on.

The assumption here is that during the period when a WRITE to a stream
is in progress, any recursive call to WRITE on that stream is for the
purpose of printing a part of the object for which the first WRITE was
issued.  I can imagine cases for which this assumption might not be
appropriate:

   -- some sort of random access scheme with an automatically-maintained
	index of astronauts in some other part of the file, or
   -- a debugging trap or trace output that occurs during printing,
	where some extraneous material will appear in the middle of the
	printed representation of the object,

but I think that both of these uses can be implemented in ways that do
not need to know how to access the hidden variable.

Dan

∂21-Nov-85  1313	greek%bach.decnet@hudson.dec.com 	Recursive printing.  
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 21 Nov 85  13:09:16 PST
Date: 0  0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Recursive printing.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Apologies if you got an abbreviated version of this message.

Dan Hoey has certainly hit upon some of the problems with recursive 
printing.  And he has suggested, as we have, that depth abbreviation 
could be handled automatically.

The right way to decide if a print is recursive is not by using 
heuristics (like switching streams or entering break loops), but by 
explicitly specifying it with recursive-p.  The heuristics will only be 
a hack.  However, it certainly isn't clear how to add recursive-p to all 
the appropriate functions.

Perhaps we can agree that depth abbreviation is to be done 
automatically, but let's not specify how to do it.  

------

∂21-Nov-85  1324	FAHLMAN@C.CS.CMU.EDU 	:Structure-Print and *print-level*    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Nov 85  13:24:44 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 21 Nov 85 16:24:31-EST
Date: Thu, 21 Nov 1985  16:24 EST
Message-ID: <FAHLMAN.12161093987.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Dan Hoey <hoey@NRL-AIC.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: :Structure-Print and *print-level*
In-reply-to: Msg of 21 Nov 1985  13:26-EST from Dan Hoey <hoey at nrl-aic.ARPA>


Hoey's proposal sounds good to me, at least as a pretty good way to
handle all this until we can modify the language to give the user more
explicit control.  Maybe we should suggest this as the preferred thing
for an implementation to do, as the language stands now.

-- Scott

∂21-Nov-85  1402	greek%bach.decnet@hudson.dec.com 	Recursive printing.  
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 21 Nov 85  13:59:08 PST
Date: 0  0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Recursive printing.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
What exactly is Hoey's proposal?  It seems to be twofold.

1.  Depth abbreviation is performed automatically by WRITE.

2.  A top-level print is started when you print to a different stream
    from the last print.

Is this correct?

------

∂21-Nov-85  1703	hoey@nrl-aic 	Re: Recursive printing.   
Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 21 Nov 85  17:03:15 PST
Date: 21 Nov 1985 18:18:28 EST (Thu)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: Recursive printing.
To: "BACH::GREEK" <greek%bach.decnet@dec-hudson.ARPA>
Cc: Common-lisp@su-ai.ARPA
Message-Id: <501463108/hoey@nrl-aic>
In-Reply-To: "BACH::GREEK"'s message of 0  0 000000 EST

    Date: 0  0 00:00:00 EST
    From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>

    What exactly is Hoey's proposal?  It seems to be twofold.

    1.  Depth abbreviation is performed automatically by WRITE.

    2.  A top-level print is started when you print to a different stream
        from the last print.

    Is this correct?

No, that isn't what I proposed.

Point 1 is the rationale for the proposal.  I would like to avoid
forcing people to scatter :RECURSIVELY-P's throughout their print
functions.

I proposed that a depth be maintained for every stream, and that WRITE
to a stream should increment that stream's depth at entry and restore
the depth on exit.

Your point 2, if I understand it correctly, is that there be some
notion of the current stream, and a single depth that applies to
whatever stream is current.  A WRITE to the current stream increments
the depth; a WRITE to another stream sets the depth to 1 and sets the
current stream to that stream.  Both depth and current stream are
restored on exit from WRITE.

Both proposals work for the normal case, when the user's printing
function does no output except for the object being printed.

Both proposals work for the case I am most concerned about, where
printing an object involves normal output on another stream.

Where the proposals differ is when printing an object involves output
on another stream, and the output on the other stream involves output
on the first stream.  For instance, with

    (defun astronaut-print-fn (obj s depth)
        (format s "[ ~S in space ]"
		(or (astro-name obj)
		    (progn (format (astro-control obj)
				   "My buddy is ~S.  Who am I?~%"
				   (astro-buddy obj))
			   (read (astro-control obj))))))

if two anonymous astronauts are each other's buddies, they will try to
print each other to their respective name servers.  If the name servers
are different, your proposal does not allow a depth cutoff, whereas mine
does.

I can't think of any reason why we should prefer one proposal over the
other, but they are different.

Dan

∂21-Nov-85  1913	robbins%bach.decnet@hudson.dec.com 	Recursive printing.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 21 Nov 85  19:03:58 PST
Date: 0  0 00:00:00 EST
From: "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>
Subject: Recursive printing.
To: "common-lisp" <common-lisp@su-ai.ARPA>
cc: robbins     
Reply-To: "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>
Dan is right.  It would be nice if people did not have to scatter RECURSIVE-P's
throughout their PRINT functions.  It would also be nice if they did not have
to scatter them throughout their READ functions.  However, they are needed in
both instances, unfortunately, they are only defined for READ.

The proposal:

  " ... that a depth be maintained for every stream, and that WRITE to
    a stream should increment that stream's depth at entry and restore
    the depth on exit"

assumes that it is never the case that someone will want to start a new top
level print on a stream when there is printing in progress.

Incrementing a counter upon entry to WRITE will not handle the situation where
someone interrupts pretty printing and enters a break loop.  Printing done
during the break loop should not be done as if it were nested within the pretty
print, it should be done as though it were at top level.  How can this be
expressed without explicitly initiating a new top level print?

Without a way of explicitly starting a new top level print some heuristic
must be used to attempt to determine when a new top level print is started
within a recursive print.  A good rule of thumb is that the use of a new stream
signals the start of a new top level print.

Dan's two astronaut print provides an example where the stream switch
heuristic fails.  The break loop case provides an example where incrementing
the internal depth counter whenever WRITE is entered fails.  The problem is
that we lack a mechanism for explicitly stating that a new top level print
is desired.  Adding RECURSIVE-P give us this mechanism (although it does
not address the problem presented by FORMAT).

--Rich
------

∂22-Nov-85  0738	DLW@SCRC-STONY-BROOK.ARPA 	adjust-array with :initial-elements and fill pointers
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85  07:33:03 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360372; Fri 22-Nov-85 10:30:23-EST
Date: Fri, 22 Nov 85 10:36 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: adjust-array with :initial-elements and fill pointers
To: common-lisp@SU-AI.ARPA
Supersedes: <851122103625.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-ID: <851122103647.7.DLW@CHICOPEE.SCRC.Symbolics.COM>

Consider the following forms:

  (setq a (make-array 5 :fill-pointer 3))
  (adjust-array a 7 :initial-element 'b)

What should happen?  On page 297, it says "The elements of the new array
that are not in the bounds of array are initalized to the
:initial-element".  The question is whether the elements that follow the
fill pointer are considered to be within the "bounds of the array".  The
sentence on page 295, "Nearly all functions that operate on the contents
of a vector will operate only on the active elements", is what makes
this issue less than perfectly clear.

Our recommendation is that the entire new array be initialized, despite
the presence of the fill pointer, and that adjust-array be clearly
designated as one of the exceptions to the "nearly all" phrase.

∂22-Nov-85  0826	greek%bach.decnet@hudson.dec.com 	Apology for our brain-damaged mailer.    
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85  08:25:56 PST
Date: 0  0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Apology for our brain-damaged mailer.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
This is an apology from us DECies for our newly-acquired Wollongong Group
Arpanet mailer.  The VAX LISP group doesn't manage the Arpanet software,
but we'll keep telling those who do about the problems.

I suppose the mail heading breaks ZMail and Babyl and other software.
Sorry.

- Paul
------

∂22-Nov-85  0856	KMP@SCRC-STONY-BROOK.ARPA 	adjust-array with :initial-elements and fill pointers
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85  08:56:12 PST
Received: from DUPAGE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360471; Fri 22-Nov-85 11:54:46-EST
Date: Fri, 22 Nov 85 11:55 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: adjust-array with :initial-elements and fill pointers
To: DLW@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851122103647.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-ID: <851122115545.9.KMP@DUPAGE.SCRC.Symbolics.COM>

    Date: Fri, 22 Nov 85 10:36 EST
    From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>

    Consider the following forms:

      (setq a (make-array 5 :fill-pointer 3))
      (adjust-array a 7 :initial-element 'b)

    What should happen?  On page 297, it says "The elements of the new array
    that are not in the bounds of array are initalized to the
    :initial-element".  The question is whether the elements that follow the
    fill pointer are considered to be within the "bounds of the array".  The
    sentence on page 295, "Nearly all functions that operate on the contents
    of a vector will operate only on the active elements", is what makes
    this issue less than perfectly clear.

    Our recommendation is that the entire new array be initialized, despite
    the presence of the fill pointer, and that adjust-array be clearly
    designated as one of the exceptions to the "nearly all" phrase.

Given:

  (setq a (make-array 5 :fill-pointer 3))
  (setf (aref a 0) 'x)
  (setf (aref a 2) 'z)
  (adjust-array a 7 :initial-element 'b)

Which of the following are you proposing:

  1.  A = [ X ? Z ? ? B B ]
  2.  A = [ X ? Z B B B B ]
  3.  A = [ X B Z B B B B ]
  4.  A = [ B B B B B B B ]
  5.  Other (please specify)

CLtL doesn't seem to say what happens to the fill pointer if there was no fill 
pointer specified in the ADJUST-ARRAY call but there was one specified to 
MAKE-ARRAY. I assume the implication is that the fill pointer remains 3. (GLS 
or Scott should correct me if I'm wrong). DLW, I am not clear on whether you 
are suggesting that it it be reset (ie, that it be the same as specifying 
:FILL-POINTER NIL or :FILL-POINTER T). Can you elaborate?

I would be curious to hear an elaboration of your motivation. In my mind, there
are reasons for believing any of these are reasonable -- depending on the 
application, which suggests to me that finer control (ie, more keywords) rather
than some arbitrary decision may be the really right thing. Of course, the 
default must be clarified in any case.

∂22-Nov-85  0938	robbins%bach.decnet@hudson.dec.com 	Recursive printing proposal  
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85  09:33:20 PST
Date: 0  0 00:00:00 EST
From: "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>
Subject: Recursive printing proposal
To: "common-lisp" <common-lisp@su-ai.ARPA>
cc: robbins     
Reply-To: "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>

I propose that we add the following macro:

	TOP-LEVEL-PRINT &BODY BODY

The macro is responsible for ensuring that any printing within BODY will
be started as a top level print.

This achieves what having RECURSIVE-P arguments to printing functions would
without breaking existing source code and without requiring any changes to
FORMAT.

I think that while we should specify that the printer automatically handles
depth abbreviation, we should not specify how it is to be implemented.

-- Rich


------

∂22-Nov-85  1015	RPG  	Reminder about the Common Lisp Meeting 
To:   Common-lisp@SU-AI.ARPA

I would like to remind you about the Common Lisp meeting, which will be
Monday, Tuesday, Wednesday, Decembers 9, 10, and 11; at:

	Boston Marriott Hotel Copley Place
        110 Huntington Avenue
	Boston, Massachusetts 02117
	(617)236-5800

The room will be ours from 8:30am until 6:00pm each of those days.
There is a block of rooms at that hotel set aside for us. I understand
that it is a fancy hotel, and the rooms are not cheap, even with
the discount I got for the meeting. The rooms are $100 single and
$115 double, which is $60 off the regular rate. When you make your
reservations, specifically mention the Common Lisp meeting.

Here is an important piece of information:

************************************************************************
*								       *
*   The block of rooms will be held for us until November 25, and      *
*   they can be booked for the evenings of Decemeber 8, 9, 10.         *
*								       *
************************************************************************

The usual caveats apply to this hotel: a reservation without
a guarantee will only hold the room until 6:00pm of the evening
of your arrival. A guarantee is usually an American Express card
number.

			-rpg-

∂22-Nov-85  1106	robbins%bach.decnet@hudson.dec.com 	LET-IF   
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85  10:43:09 PST
Date: 0  0 00:00:00 EST
From: "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>
Subject: LET-IF
To: "common-lisp" <common-lisp@su-ai.ARPA>
cc: robbins     
Reply-To: "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>

Is there a good reason why we don't have a ZetaLisp style LET-IF special form?
Using PROGV to bind an item based on some trivial condition seems like
overkill to me.

-- Rich
------

∂22-Nov-85  1127	FAHLMAN@C.CS.CMU.EDU 	Recursive printing proposal 
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Nov 85  11:27:38 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 22 Nov 85 14:26:37-EST
Date: Fri, 22 Nov 1985  14:26 EST
Message-ID: <FAHLMAN.12161334664.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   "BACH::ROBBINS" <robbins%bach.decnet@HUDSON.DEC.COM>
Cc:   common-lisp <common-lisp@SU-AI.ARPA>
Subject: Recursive printing proposal
In-reply-to: Msg of 0  0 00:00:00 EST from BACH::ROBBINS <robbins%bach.decnet at hudson.dec.com>


I think this would have to be a special form and not a macro, since it
cannot be implemented using existing forms.  It might be better to add a
function to sense and setf the current print depth, and implement your
own macro in terms of that.

-- Scott

∂22-Nov-85  1156	greek%bach.decnet@hudson.dec.com 	TOP-LEVEL-PRINT macro.    
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85  11:54:16 PST
Date: 0  0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: TOP-LEVEL-PRINT macro.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I'm not sure why a TOP-LEVEL-PRINT macro would have to be a special
form.  It just generates whatever code the print system needs to realize
this is a top-level print.  For example, it could bind a special
variable to zero and then execute the body.  It only has to set the
state of the world so that the print system knows it's a top-level
print.

Don't want to restrict anything by saying there is something to fetch
and SETF, or whatever.  There is no need to know how the print system
deals with TOP-LEVEL-PRINT.

- Paul
------

∂22-Nov-85  1143	FAHLMAN@C.CS.CMU.EDU 	LET-IF  
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Nov 85  11:42:46 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 22 Nov 85 14:41:52-EST
Date: Fri, 22 Nov 1985  14:41 EST
Message-ID: <FAHLMAN.12161337435.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   robbins%bach.decnet@HUDSON.DEC.COM
Cc:   common-lisp <common-lisp@SU-AI.ARPA>
Subject: LET-IF
In-reply-to: Msg of 0  0 00:00:00 EST from BACH::ROBBINS <robbins%bach.decnet at hudson.dec.com>


    Is there a good reason why we don't have a ZetaLisp style LET-IF special form?
    Using PROGV to bind an item based on some trivial condition seems like
    overkill to me.

What would you use this for?  Why not just rebind the variable to its
old value and then conditionally change it?  Common Lisp is big enough
without adding special forms that would only be used only very rarely.

-- Scott

∂22-Nov-85  1208	DLW@SCRC-STONY-BROOK.ARPA 	adjust-array with :initial-elements and fill pointers
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85  12:07:45 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360668; Fri 22-Nov-85 14:49:16-EST
Date: Fri, 22 Nov 85 14:55 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: adjust-array with :initial-elements and fill pointers
To: KMP@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851122115545.9.KMP@DUPAGE.SCRC.Symbolics.COM>
Message-ID: <851122145536.0.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Fri, 22 Nov 85 11:55 EST
    From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>

    Given:

      (setq a (make-array 5 :fill-pointer 3))
      (setf (aref a 0) 'x)
      (setf (aref a 2) 'z)
      (adjust-array a 7 :initial-element 'b)

    Which of the following are you proposing:

      1.  A = [ X ? Z ? ? B B ]
      2.  A = [ X ? Z B B B B ]
      3.  A = [ X B Z B B B B ]
      4.  A = [ B B B B B B B ]
      5.  Other (please specify)

I am assuming that "in the bounds" means "less than 5".  Therefore, I am
advocating choice number 1.  See the definition of :initial-element on
page 297.

    CLtL doesn't seem to say what happens to the fill pointer if there was no fill 
    pointer specified in the ADJUST-ARRAY call but there was one specified to 
    MAKE-ARRAY. I assume the implication is that the fill pointer remains 3. (GLS 
    or Scott should correct me if I'm wrong). DLW, I am not clear on whether you 
    are suggesting that it it be reset (ie, that it be the same as specifying 
    :FILL-POINTER NIL or :FILL-POINTER T). Can you elaborate?

I am also assuming that the fill pointer remains 3.

    I would be curious to hear an elaboration of your motivation.

The feeling is that the programmer would reasonably expect this code to
initialize the elements beyond the fill pointer, so that when the fill
pointer is increased, instead of finding unpredictable junk in the
array, the contents will be what was specified by :initial-elements.  It
seems like the most useful definition.

∂22-Nov-85  1224	Moon@SCRC-STONY-BROOK.ARPA 	LET-IF 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85  12:24:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360684; Fri 22-Nov-85 15:06:01-EST
Date: Fri, 22 Nov 85 15:05 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: LET-IF
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: robbins%bach.decnet@HUDSON.DEC.COM,
    common-lisp <common-lisp@SU-AI.ARPA>
In-Reply-To: <FAHLMAN.12161337435.BABYL@C.CS.CMU.EDU>
Message-ID: <851122150515.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 22 Nov 1985  14:41 EST
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>


	Is there a good reason why we don't have a ZetaLisp style LET-IF special form?
	Using PROGV to bind an item based on some trivial condition seems like
	overkill to me.

    What would you use this for?  Why not just rebind the variable to its
    old value and then conditionally change it?  Common Lisp is big enough
    without adding special forms that would only be used only very rarely.

What if the variable is unbound?

Not that I am advocating adding this to Common Lisp.  There are things
that I firmly believe belong in Symbolics Common Lisp and equally firmly
believe do not belong in the Common Lisp language standard, which as you
say is quite large already.

∂22-Nov-85  1243	Moon@SCRC-STONY-BROOK.ARPA 	:Structure-Print and *print-level*   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85  12:43:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360717; Fri 22-Nov-85 15:28:35-EST
Date: Fri, 22 Nov 85 15:27 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: :Structure-Print and *print-level*
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
    Guy Steele <gls@THINK-AQUINAS.ARPA>,
    "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>,
    Dan Hoey <hoey@NRL-AIC.ARPA>,
    "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>,
    Rob MacLachlan <RAM@C.CS.CMU.EDU>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12161024452.BABYL@C.CS.CMU.EDU>,
             <851121112509.7.GLS@FAUSTINUS.THINK.COM>,
             <501445600/hoey@nrl-aic>,
             <FAHLMAN.12161093987.BABYL@C.CS.CMU.EDU>,
             <501463108/hoey@nrl-aic>,
             The message from "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>,
             <FAHLMAN.12161334664.BABYL@C.CS.CMU.EDU>,
             The message from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Message-ID: <851122152746.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

Introducing magic hidden variables and kludgey recursive-p arguments to control
them is inviting disaster.  I'm strongly opposed to this.  We've had some experience
with this in Zetalisp and it is not good.  It is always better to pass this kind
of state around as explicit arguments than to put it in hidden variables.

I fail to see what was wrong with the suggestion in Fahlman's original message of
adding a :DEPTH argument to WRITE, which defaults to 0 but can be supplied by a
structure's print function if it so desires.  

I should think the answer to the question of whether a structure's print
function should increment the depth that it received as an argument
before passing it on to WRITE is perfectly obvious:  it depends on
whether the print function printed any left parentheses before calling
WRITE.  I think the fact that the print system has no reasonable way to
tell whether the print function printed any left parentheses, other than
the print function telling it so, counters Greek's argument that the old
thing should be automatic.  Suppose the print function uses brackets as
part of its syntax and wants them treated as equivalent to a level
of parentheses for depth-abbreviation purposes.

I'm not concerned about the case of print functions that call FORMAT.  FORMAT is
a convenient abbreviation mechanism for writing code to do simple forms of
formatting quickly.  If you need to do something more complicated, you don't add
a new feature to FORMAT, you use Lisp instead of the FORMAT string language.

∂22-Nov-85  1249	Moon@SCRC-STONY-BROOK.ARPA 	Fill-pointers and sequences
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85  12:49:22 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360737; Fri 22-Nov-85 15:37:13-EST
Date: Fri, 22 Nov 85 15:36 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Fill-pointers and sequences
To: Guy Steele <gls@THINK-AQUINAS.ARPA>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <851121104241.1.GLS@FAUSTINUS.THINK.COM>
Message-ID: <851122153632.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 21 Nov 85 10:42 EST
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>

    There are two other passages you might consider.  First, page 246, last
    paragraph, states that the :start and :end arguments should be integer
    indices "into the sequence"; is an index larger than the fill pointer
    "into the sequence" or merely "into the vector"?  Second, page 291 notes
    that "aref is unusual among the functions that operate on arrays in that
    it completely ignores fill pointers".  If we really believed the book to
    be careful and accurate, we might infer that other functions not
    specifically documented to be in this unusual category may not access
    beyond the fill pointer; but in the actual event this inference is shaky
    at best.

    I think I would be inclined to write the code in this manner:

      (setq a (make-array 10 :fill-pointer 3))

      (let ((old-fill-pointer (shiftf (fill-pointer a) (array-total-size a))))
	(fill a nil :start (fill-pointer a) :end (array-dimension a 0))
	(setf (fill-pointer a) old-fill-pointer))

    or, for the truly worried,

      (let ((old-fill-pointer (array-total-size a)))
	(unwind-protect
	    (progn (setf (fill-pointer a) (array-total-size a))
		   (fill a nil :start (fill-pointer a) :end (array-dimension a 0)))
	  (setf (fill-pointer a) old-fill-pointer)))

    I do not feel strongly about which way this issue is resolved, but I
    agree that it should be tied down.  I mildly favor a strict interpretation.

Okay, but I have to ask what we gain by making the user go through this 5-line
rigamarole when a simple call to FILL would suffice if the language were defined
the other way.  To me, the fill-pointer is simply the current length and doesn't
mean that the rest of the vector does not exist in any sense (see the note on
p.295 that vector elements not in the active region are still part of the vector).
I guess the language is going to be ugly either way.

I also want to repeat my query which no one addressed yet: Does the answer
depend on whether the sequence function in question is one that writes
(like FILL or REPLACE) or one that reads (like POSITION or REMOVE)?

∂22-Nov-85  1253	Moon@SCRC-STONY-BROOK.ARPA 	TYPEP and arrays of (SATISFIES F)    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85  12:52:56 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360754; Fri 22-Nov-85 15:46:04-EST
Date: Fri, 22 Nov 85 15:45 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: TYPEP and arrays of (SATISFIES F)
To: Guy Steele <gls@THINK-AQUINAS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851118163500.9.GLS@THINK-HILARION.ARPA>
Message-ID: <851122154519.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 18 Nov 85 16:35 EST
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>

    Bob Rorschach has raised the following question:  what is the
    result of (TYPEP (MAKE-ARRAY 10) '(ARRAY (SATISFIES F) (10)))
    supposed to be?  Consider these special cases:

	    (TYPEP (MAKE-ARRAY 10 :ELEMENT-TYPE INTEGER)
		   '(ARRAY (SATISFIES FIXNUMP) (10)))

	    (TYPEP (MAKE-ARRAY 10 :ELEMENT-TYPE FIXNUM)
		   '(ARRAY (SATISFIES FIXNUMP) (10)))

    We can easily dismiss the first case, because clearly an array
    specialized to hold integers is not necessarily the same as one
    specialized to hold fixnums.  The second is more difficult.  It happens
    to be the case that FIXNUM and (SATISFIES FIXNUMP) are equivalent type
    specifiers, but in many implementations SUBTYPEP cannot discern this
    fact (and indeed is not required to).

    When TYPEP sees a plain old SATISFIES specifier, it can just call the
    function, but not so when it is the element type of an ARRAY specifier.

Returning NIL for (TYPEP (MAKE-ARRAY 10) '(ARRAY (SATISFIES F) (10)))
seems consistent with the discussion on page 45 of the manual.
Referring to the last line on that page, in an implementation without a
specialized array type for elements of type (SATISFIES F), no object
can pass that test.

I guess it's still an open question whether every implementation should
be required to return T for (EQUAL-TYPEP 'FIXNUM '(SATISFIES FIXNUMP))
and hence T for (TYPEP (MAKE-ARRAY 10 :ELEMENT-TYPE 'FIXNUM)
		       '(ARRAY (SATISFIES FIXNUMP) (10))).
Yes, I know EQUAL-TYPEP is not a standard Common Lisp function, but I
think you get what I mean by it.  I don't think it would be a good idea
to require this, because you quickly open the door to questions like
"well, what about (SATISFIES SMALL-INTEGER-P) where somewhere in the
program it says (DEFUN SMALL-INTEGER-P (X) (FIXNUMP X))".

    One way out (proposed language change) is to define TYPEP to be like
    SUBTYPEP, in that it returns two values; if the first value is NIL, the
    second value says whether that's a "no" or a "maybe".  So for the
    first special case above TYPE would return either NIL T or NIL NIL,
    depending on the cleverness of the implementation, and for the second
    special case would return either NIL NIL or T T.

I don't think we need to change the language.

∂22-Nov-85  1304	greek%bach.decnet@hudson.dec.com 	Common LISP is too big?   
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85  13:03:46 PST
Date: 0  0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Common LISP is too big?
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>

I'm not sure I understand everyone's attitude about Common LISP being 
too big.  Dave Moon has a construct he likes so much that he absolutely 
believes it ought to be in Symbolics Common LISP but doesn't want anyone 
else to have it.  Perhaps he just thinks that for compatability with 
ZetaLisp, which I guess makes some sense.

You know, we could certainly prevent the language from gaining weight by 
leaving out an error handling system, an object system, windows, etc.
If we don't want to make the language larger than it is today, we should 
have made it smaller in the first place.  But we didn't.

- Paul

------

∂22-Nov-85  1304	robbins%bach.decnet@hudson.dec.com 	LET-IF   
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85  13:04:10 PST
Date: 0  0 00:00:00 EST
From: "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>
Subject: LET-IF
To: "common-lisp" <common-lisp@su-ai.ARPA>
cc: robbins     
Reply-To: "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>

I will give an example to illustrate why I think that we need LET-IF.
If there is a clean way to get around my need for a conditional bind,
then please let me know.

(defvar *flag*)

(defun f ()
  (let-if (some-condition-that-may-be-satisfied-several-times)
          ((*flag* nil))
    ;; large body that will call f recursively and possibly set *flag*
    (when *flag*
      ;; perform special processing
      )))

I don't want to have to double the size of the function by having the body
twice.

I can't use catch and throw when the event happens because I only wish to
note that the event has happened, not terminate processing.

The function f is to be called very frequently and I want it to be as
fast as possible, hence PROGV seems like overkill.

Binding *flag* to a mutable object ...

  (let ((*flag* (if (condition) (cons nil nil) *flag*))) ...

seems like a real hack.

-- Rich
------

∂22-Nov-85  1305	KMP@SCRC-STONY-BROOK.ARPA 	Recursive printing proposal 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85  13:05:48 PST
Received: from DUPAGE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360771; Fri 22-Nov-85 15:57:13-EST
Date: Fri, 22 Nov 85 15:58 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Recursive printing proposal
To: Fahlman@C.CS.CMU.EDU
cc: robbins%bach.decnet@HUDSON.DEC.COM, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12161334664.BABYL@C.CS.CMU.EDU>
Message-ID: <851122155820.2.KMP@DUPAGE.SCRC.Symbolics.COM>

    Date: Fri, 22 Nov 1985  14:26 EST
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    I think this would have to be a special form and not a macro, since it
    cannot be implemented using existing forms. 

It could be introduced as a function which took a printer continuation. A macro
could then be written by anyone who didn't like functional notation.

    It might be better to add a function to sense and setf the current print depth, 
    and implement your own macro in terms of that.

I'd agree with adding such primitives, but I don't think this is a good way to
think about a toplevel printing abstraction. What if some day we decide there
is more to toplevel printing than just noticing when the depth gets reset to 
zero. Better to have an abstraction which does "any necessary setup" for printing
a toplevel object.

I'm not sure that this is a good abstraction to have, but if we have it, I think 
that these thoughts are relevant.

I do know that I think we should have had an INVOKE-TOPLEVEL-READER abstraction
rather than passing around recursive-p information. 

I guess I'd be willing to consider a function like the following:

 PRINT-OBJECT-TOPLEVEL OBJECT &KEY FUNCTION STREAM

which could be described to do something roughly like the following, plus any 
system-specific stuff which didn't interfere with the basic idea ... whatever 
that means (sigh) ... 

 (DEFUN PRINT-OBJECT-TOPLEVEL (OBJECT &KEY FUNCTION STREAM)
   (LET ((*STANDARD-OUTPUT* (OR STREAM *STANDARD-OUTPUT*)))
     (LET ((OLD-DEPTH (CURRENT-PRINT-DEPTH *STANDARD-OUTPUT*)))
       (UNWIND-PROTECT (PROGN (SETF (CURRENT-PRINT-DEPTH *STANDARD-OUTPUT*) 0)
			      (FUNCALL (OR FUNCTION #'PRIN1) OBJECT))
	 (SETF (CURRENT-PRINT-DEPTH *STANDARD-OUTPUT*) OLD-DEPTH)))))

∂22-Nov-85  1321	KMP@SCRC-STONY-BROOK.ARPA 	adjust-array with :initial-elements and fill pointers
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85  13:21:12 PST
Received: from DUPAGE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360792; Fri 22-Nov-85 16:05:11-EST
Date: Fri, 22 Nov 85 16:06 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: adjust-array with :initial-elements and fill pointers
To: DLW@SCRC-QUABBIN.ARPA, KMP@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851122145536.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-ID: <851122160610.3.KMP@DUPAGE.SCRC.Symbolics.COM>

    Date: Fri, 22 Nov 85 14:55 EST
    From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>

	Date: Fri, 22 Nov 85 11:55 EST
	From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>

	Given:

	  (setq a (make-array 5 :fill-pointer 3))
	  (setf (aref a 0) 'x)
	  (setf (aref a 2) 'z)
	  (adjust-array a 7 :initial-element 'b)

	Which of the following are you proposing:

	  1.  A = [ X ? Z ? ? B B ]
	  2.  A = [ X ? Z B B B B ]
	  3.  A = [ X B Z B B B B ]
	  4.  A = [ B B B B B B B ]
	  5.  Other (please specify)

    I am assuming that "in the bounds" means "less than 5".  Therefore, I am
    advocating choice number 1.  See the definition of :initial-element on
    page 297.

Oh, ok. I couldn't imagine that you were suggesting #1. I'm glad I asked.
#1 sounds fine to me.

	CLtL doesn't seem to say what happens to the fill pointer if there was no fill 
	pointer specified in the ADJUST-ARRAY call but there was one specified to 
	MAKE-ARRAY. I assume the implication is that the fill pointer remains 3. (GLS 
	or Scott should correct me if I'm wrong). DLW, I am not clear on whether you 
	are suggesting that it it be reset (ie, that it be the same as specifying 
	:FILL-POINTER NIL or :FILL-POINTER T). Can you elaborate?

    I am also assuming that the fill pointer remains 3.

	I would be curious to hear an elaboration of your motivation.

    The feeling is that the programmer would reasonably expect this code to
    initialize the elements beyond the fill pointer, so that when the fill
    pointer is increased, instead of finding unpredictable junk in the
    array, the contents will be what was specified by :initial-elements.  It
    seems like the most useful definition.

Although, interestingly, in this example, elements 3 and 4 will (rightly) contain
unpredictable junk. I think we agree even though I don't think what you said 
in this paragraph is true. I believe what you meant is that in the case of:

	  (setq a (make-array 5 :fill-pointer 3
			      	:initial-element 'q)) ;added this
	  (setf (aref a 0) 'x)
	  (setf (aref a 2) 'z)
	  (adjust-array a 7 :initial-element 'b)

he has a right to expect that information beyond element 2 will not be junk
(ie, slots 3 and 4 will contain non-junk from the MAKE-ARRAY and slots
5 and 6 will contain non-junk from the ADJUST-ARRAY).

∂22-Nov-85  1328	FAHLMAN@C.CS.CMU.EDU 	Fill-pointers and sequences 
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Nov 85  13:23:20 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 22 Nov 85 16:22:42-EST
Date: Fri, 22 Nov 1985  16:22 EST
Message-ID: <FAHLMAN.12161355803.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   Common-Lisp@SU-AI.ARPA
Subject: Fill-pointers and sequences
In-reply-to: Msg of 22 Nov 1985  15:36-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>


        I do not feel strongly about which way this issue is resolved, but I
        agree that it should be tied down.  I mildly favor a strict interpretation.

    Okay, but I have to ask what we gain by making the user go through this 5-line
    rigamarole when a simple call to FILL would suffice if the language were defined
    the other way.  To me, the fill-pointer is simply the current length and doesn't
    mean that the rest of the vector does not exist in any sense (see the note on
    p.295 that vector elements not in the active region are still part of the vector).
    I guess the language is going to be ugly either way.

    I also want to repeat my query which no one addressed yet: Does the answer
    depend on whether the sequence function in question is one that writes
    (like FILL or REPLACE) or one that reads (like POSITION or REMOVE)?

We've got two data abstractions going here: the sequence and the vector
which implements it.  I am suggesting that the stuff beyond the fill
pointer is in the vector, but not in the sequence.  What we gain is a
nice clean image of what the sequence is, without a lot of special
cases.  In my opinion, the read/write distinction should not matter --
generic sequence functions should not read or write beyond the current
boundaries of the sequence, though vector/array primitives like AREF and
SVREF may do so.

-- Scott

∂22-Nov-85  1331	FAHLMAN@C.CS.CMU.EDU 	LET-IF  
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Nov 85  13:28:54 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 22 Nov 85 16:28:09-EST
Date: Fri, 22 Nov 1985  16:28 EST
Message-ID: <FAHLMAN.12161356793.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp <common-lisp@SU-AI.ARPA>
Subject: LET-IF
In-reply-to: Msg of 22 Nov 1985  15:05-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>


    What if the variable is unbound?

Well, in that case it usually does no harm to rebind the thing
unconditionally.  The code would then look like

(let ((foo (if (boundp foo) foo foo-default)))
  ...)

I grant that a user might want to use a macro to abbreviate the above
idiom if it is used a lot, but it is probably not something that is used
enough to belong in the langauge proper.  Are there other common uses of
LET-IF that would not be captured adequately by something like the
above?

-- Scott

∂22-Nov-85  1352	FAHLMAN@C.CS.CMU.EDU 	Recursive printing proposal 
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Nov 85  13:52:04 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 22 Nov 85 16:51:36-EST
Date: Fri, 22 Nov 1985  16:51 EST
Message-ID: <FAHLMAN.12161361052.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Recursive printing proposal
In-reply-to: Msg of 22 Nov 1985  15:58-EST from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>


The right way to fix this is to give the user some way to obtain the
current depth (the structure printing stuff already has this), and some
way to pass the depth to use as an optional or keyword argument to Write
(and maybe to the other printing thingies).  This seems much simpler to
me than adding printer continuations and such to the language.  The
other suggestions were merely for quick and dirty fixes that might fall
within the current language spec, but I guess we'd better not play that
game lest such things get locked in.

-- Scott

∂22-Nov-85  1419	greek%bach.decnet@hudson.dec.com 	Sigh on recursive printing.    
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85  14:18:33 PST
Date: 0  0 00:00:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Sigh on recursive printing.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Passing around the current depth is NOT a reasonable solution.
Perhaps you folks aren't reading our mail because of the screwed
up date (although why your mail readers care about our date I'll
never understand).

Anyway, the solutions in order of cleanliness seem to me:

1.  Add a recursive-p argument to ALL the printing functions.

2.  Implement some kind of TOP-LEVEL-PRINT macro.

3.  Add a depth argument to ALL the printing functions.  Why are
    you assuming that top-level prints only affect the depth?  They
    may do all sorts of other things.

Since we aren't likely to accept 1 or 3 because we can't add arguments
to functions, then it looks like 2.

- Paul
------

∂22-Nov-85  1430	FAHLMAN@C.CS.CMU.EDU 	LET-IF  
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Nov 85  14:29:27 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 22 Nov 85 17:28:39-EST
Date: Fri, 22 Nov 1985  17:28 EST
Message-ID: <FAHLMAN.12161367808.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   "BACH::ROBBINS" <robbins%bach.decnet@HUDSON.DEC.COM>
Cc:   common-lisp <common-lisp@SU-AI.ARPA>
Subject: LET-IF
In-reply-to: Msg of 0  0 00:00:00 EST from BACH::ROBBINS <robbins%bach.decnet at hudson.dec.com>


    (defvar *flag*)

    (defun f ()
      (let-if (some-condition-that-may-be-satisfied-several-times)
              ((*flag* nil))
        ;; large body that will call f recursively and possibly set *flag*
        (when *flag*
          ;; perform special processing
          )))

It's hard for me to see exactly what is intended here, since I think
you've got some bugs in your example.  If that condition isn't true,
*flag* stays unbound and the WHEN form gets an error.  It looks to me
like you're trying to establish some sort of handler whenever you find
the hairy condition to be true, so that when you emerge from the body
you will do something at this level (only) whenever the flag has been
set.  But in the code you give, the "special processing" will occur at
all calls to F between the place where flag is set and the innermost
surrounding F where the condition was true.

I think that in most cases I would be inclined to handle this upward
communication by the return value rather than by side-effecting some
conditionally bound variable.  It's less confusing that way.

But if you must do something like this, I see no reason not to use
PROGV.  It shouldn't be any more inefficient than any other way of
binding a special, as long as the list of variables is a quoted constant
at compile time.  If your local compiler generates lousy code for PROGV,
it should be easy to add an optimization to handle the
constant-variable-list case as efficiently as any other binding of a
special.  If you don't like the looks of PROGV, then you can easily
write your own LET-IF macro in terms of PROGV, as long as you restrict
this form to binding special variables only.  I perhaps mistakenly
assumed that the "overkill" you referred to earlier was in being forced
to use a special variable when you wanted a lexical one, but that is not
the case in your example.

-- Scott

∂22-Nov-85  1515	JAR@MIT-MC.ARPA 	LET-IF  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Nov 85  14:42:46 PST
Date: Fri, 22 Nov 85 17:45:05 EST
From: Jonathan A Rees <JAR@MIT-MC.ARPA>
Subject:  LET-IF
To: robbins%bach.decnet@HUDSON.DEC.COM
cc: common-lisp@SU-AI.ARPA, robbins@HUDSON.DEC.COM
In-reply-to: Msg of 0  0 00:00:00 EST from BACH::ROBBINS <robbins%bach.decnet at hudson.dec.com>
Message-ID: <[MIT-MC.ARPA].729122.851122.JAR>

What's wrong with

(defmacro let-if (test bindings &body body)
  (let ((f (gensym)))
    `(flet ((,f () ,@body))
       (if ,test (let ,bindings (,f)) (,f)))))

?

∂22-Nov-85  1636	DLW@SCRC-STONY-BROOK.ARPA 	Sigh on recursive printing. 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85  16:30:24 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 361025; Fri 22-Nov-85 19:29:11-EST
Date: Fri, 22 Nov 85 19:35 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Sigh on recursive printing.
To: greek%bach.decnet@hudson.dec.com, common-lisp@SU-AI.ARPA
In-Reply-To: The message from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Message-ID: <851122193538.9.DLW@CHICOPEE.SCRC.Symbolics.COM>

    From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>

    Perhaps you folks aren't reading our mail because of the screwed
    up date (although why your mail readers care about our date I'll
    never understand).

Since you've mentioned this more than once: Zmail doesn't get broken in
any way by your messages.  It understands that the header is illegal and
displays the message anyway.  I am sending this message using the Zmail
"reply" command, and it had no trouble reversing the addresses.  We
are receiving all your mail.

∂22-Nov-85  1722	GJC@MIT-MC.ARPA 	Recursive printing proposal 
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Nov 85  17:22:29 PST
Date: Fri, 22 Nov 85 20:24:55 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject:  Recursive printing proposal
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA
In-reply-to: Msg of Fri 22 Nov 1985  16:51 EST from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[MIT-MC.ARPA].729486.851122.GJC>

One way to deal with printer extensions is to make them a bit more
formal, like the SETF extension mechanism which is less general then
macro definition but gets the intended job done with less duplicated work.
In the implementations that people have now I venture to say they could
look at the way that circular-print is handled, and build at least
PRINT-DEPTH handling into that. Maybe we should adopt a "programmable
printer" like that of Hawkinson, or a cleaned-up version of Waters?

∂22-Nov-85  1733	robbins%bach.decnet@hudson.dec.com 	LET-IF   
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85  17:33:01 PST
Date: 0  0 00:00:00 EST
From: "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>
Subject: LET-IF
To: "common-lisp" <common-lisp@su-ai.ARPA>
cc: robbins     
Reply-To: "BACH::ROBBINS" <robbins%bach.decnet@hudson.dec.com>
Both Jonathan and Scott have suggested methods to deal with the
situation that I posed.  While LET-IF is certainly not required
I still think it would be worth having in the language.  Sigh.

-- Rich
------

∂22-Nov-85  1743	Moon@SCRC-QUABBIN.ARPA 	Sigh on recursive printing.    
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 22 Nov 85  17:38:00 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 223229; Fri 22-Nov-85 20:36:20-EST
Date: Fri, 22 Nov 85 20:36 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Sigh on recursive printing.
To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
cc: common-lisp <common-lisp@SU-AI.ARPA>
In-Reply-To: The message from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Message-ID: <851122203606.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 0  0 00:00:00 EST
    From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
    
    Perhaps you folks aren't reading our mail because of the screwed
    up date (although why your mail readers care about our date I'll
    never understand).

Never?  I like being able to sort conversations into chronological order
so I have a hope of understanding them when I read them.  Unpredictable
network delays frequently cause messages to get out of order.

∂22-Nov-85  1743	GJC@MIT-MC.ARPA 	LET-IF  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Nov 85  17:39:25 PST
Date: Fri, 22 Nov 85 20:41:51 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject:  LET-IF
To: robbins%bach.decnet@HUDSON.DEC.COM
cc: common-lisp@SU-AI.ARPA, robbins@HUDSON.DEC.COM
In-reply-to: Msg of 0  0 00:00:00 EST from BACH::ROBBINS <robbins%bach.decnet at hudson.dec.com>
Message-ID: <[MIT-MC.ARPA].729508.851122.GJC>

Funny you should mention that, I'm considering flushing quite a few
special forms in the LMI system and replacing them with macros, LET-IF
is one, and the following definition seems right:

(defmacro let-if (pred bindings &body body)
  (let ((f (gentemp "f)))
   `(flet ((,f () ,@body))
       (if ,pred (let ,bindings (,f)) (,f)))))

The are similar constructions that conditionally bind dynamic things of
various kinds that are already implemented by taking advantage of
lexical scoping, CONDITION-BIND-IF (conditionally binding error handling)
is one fairly common form:

(condition-bind-if (not *debugging*) (x) (form) (error x)) for example.

Anyway, FLET is an ideal tool for avoiding what you describe as
 "I don't want to have to double the size of the function by having the
  body twice"

Or, as Mr Roberts would say, "can you say... CLOSURE," yes boys and girls...


∂23-Nov-85  0913	shebs%utah-orion@utah-cs.arpa 	Misc Queries  
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 23 Nov 85  09:13:24 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
	id AA08458; Sat, 23 Nov 85 10:13:27 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
	id AA22920; Sat, 23 Nov 85 10:13:25 MST
Date: Sat, 23 Nov 85 10:13:25 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8511231713.AA22920@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Misc Queries

While working on PCLS, we've encountered some situations which are probably
trivial, but which I don't recall having been brought up:

1) What should (export nil) do?  The CLM says that the first argument
is either a symbol or list of symbols, but doesn't tell how to handle
nil.  Personally, I would prefer having nil mean an empty list, but Spice
code assumes you want to export the symbol nil.

2) The definition of macroexpand is that it does macroexpand-1 repeatedly,
while (for instance) PSL macroexpand tries to find all macros in a form
and expand them.  Is CL macroexpand defined correctly?  If so, is an
exhaustive macroexpander considered a compiler thing (because of the
need for special form knowledge)?

3) What is the general theory of destructive operations during lambda
list processing (such as by initforms)? For instance, how much structure
should be shared by an &rest binding and &key bindings?

4) What should happen if one does a defun with a documentation string
included, then later redefines the same function, but without specifying
a doc string?  Should the old one go away?  Spice Lisp seems to leave
it alone.

							stan shebs

∂23-Nov-85  1348	DLW@SCRC-STONY-BROOK.ARPA 	Minor typo   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 Nov 85  13:45:42 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 361428; Sat 23-Nov-85 16:43:13-EST
Date: Sat, 23 Nov 85 16:49 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Minor typo
To: common-lisp@SU-AI.ARPA
Message-ID: <851123164942.5.DLW@CHICOPEE.SCRC.Symbolics.COM>

There seems to be a minor typo on page 23, second paragraph of 2.2.4,
second line, in which an existential qualifier symbol appears where
there ought to be a numeral "3".

∂23-Nov-85  1356	Moon@SCRC-STONY-BROOK.ARPA 	Misc Queries
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 Nov 85  13:55:37 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 361434; Sat 23-Nov-85 16:54:13-EST
Date: Sat, 23 Nov 85 16:53 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Misc Queries
To: Stanley Shebs <shebs%utah-orion@UTAH-CS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8511231713.AA22920@utah-orion.ARPA>
Message-ID: <851123165317.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sat, 23 Nov 85 10:13:25 MST
    From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)

    While working on PCLS, we've encountered some situations which are probably
    trivial, but which I don't recall having been brought up:

    1) What should (export nil) do?  The CLM says that the first argument
    is either a symbol or list of symbols, but doesn't tell how to handle
    nil.  Personally, I would prefer having nil mean an empty list, but Spice
    code assumes you want to export the symbol nil.

The second sentence of the last paragraph on page 182 is quite explicit.
The Spice implementation is not the definition of the language.

    2) The definition of macroexpand is that it does macroexpand-1 repeatedly,
    while (for instance) PSL macroexpand tries to find all macros in a form
    and expand them.  Is CL macroexpand defined correctly?  

What the book says is "correct" by definition.  Whether it's the best possible
language definition is another matter.

							    If so, is an
    exhaustive macroexpander considered a compiler thing (because of the
    need for special form knowledge)?

Yes.  It's a useful thing to have, but it isn't the same as the macroexpand
function.  It's necessary to have something more general than this to implement
setf correctly, so I expect most implementations have this capability.

    3) What is the general theory of destructive operations during lambda
    list processing (such as by initforms)? For instance, how much structure
    should be shared by an &rest binding and &key bindings?

This would be clearer if you gave an example.  If you're thinking of something
like
  (defun disgust (&rest r &key (a (setq r nil)) b)
    (list a b))
  (disgust :b 2)
or even worse
  (defun disgust (&rest r &key (a (setf (second r) nil)) b)
    (list a b))
  (disgust :b 2)
I don't think we anticipated that anybody would try this when we were designing
the language.  I'd be happy to say that each of these is an error.

I wasn't able to come up with any problematic examples that didn't involve
modifying the &rest argument.  Did you have others in mind?

    4) What should happen if one does a defun with a documentation string
    included, then later redefines the same function, but without specifying
    a doc string?  Should the old one go away?  Spice Lisp seems to leave
    it alone.

It should go away; think about what happens if you changed the function so that
it no longer conforms to what the old documentation said.
The Spice implementation is not the definition of the language.


∂23-Nov-85  1429	FAHLMAN@C.CS.CMU.EDU 	Misc Queries 
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Nov 85  14:29:37 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 23 Nov 85 17:29:29-EST
Date: Sat, 23 Nov 1985  17:29 EST
Message-ID: <FAHLMAN.12161630105.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Stanley Shebs <shebs%utah-orion@UTAH-CS.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Misc Queries
In-reply-to: Msg of 23 Nov 1985  16:53-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>


I agree with Moon's analysis of your queries.

Not only is the Spice implementation not the definition of the language,
but it has never been exhaustively tested for compliance with the manual
-- it is hard to get part-time undergrads (and overworked faculty
members) to do such tedious things, and we have never had sufficient
funding to hire people specifically to do testing.  So Spice Lisp is
useful as an implementors kit (the best one I know of that you can get
for free) but nobody should be too surprised if it contains occasional
errors in odd corners.

-- Scott

∂23-Nov-85  1628	RPG  	Minor Typo = Major Faux Pas! 
To:   common-lisp@SU-AI.ARPA
Dan mentioned that an existential quantifier was mistyped at some
place where a 3 was meant. He meant to say the an existential
quantifier was mistyped *every* place a 3 was meant. I think the
spot to which he refers is a place where the TTY font for `3'
belongs, and that representation of `3' looks exactly like an
existential sign. This is because that is the best font Digital
Press could come up with.
			-rpg-

∂23-Nov-85  1933	mips!escargot.earl@glacier 	Misc Queries
Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 23 Nov 85  19:33:38 PST
Received: by glacier with Sendmail; Sat, 23 Nov 85 19:33:06 pst
Received: from escargot.UUCP (escargot.ARPA) by mips.UUCP (4.12/4.7)
	id AA28866; Sat, 23 Nov 85 15:40:25 pst
Received: by escargot.UUCP (4.12/4.7)
	id AA13650; Sat, 23 Nov 85 15:38:07 pst
Date: Sat, 23 Nov 85 15:38:07 pst
From: mips!escargot.earl@glacier (Earl Killian)
Message-Id: <8511232338.AA13650@escargot.UUCP>
To: shebs%utah-orion@utah-cs.ARPA
Cc: common-lisp@su-ai.ARPA
In-Reply-To: glacier!shebs%utah-orion@utah-cs.arpa's message of Sat, 23 Nov 85 10:13:25 MST
Subject: Misc Queries

    Date: Sat, 23 Nov 85 10:13:25 MST
    From: glacier!shebs%utah-orion@utah-cs.arpa (Stanley Shebs)

    While working on PCLS, we've encountered some situations which are probably
    trivial, but which I don't recall having been brought up:

    1) What should (export nil) do?  The CLM says that the first argument
    is either a symbol or list of symbols, but doesn't tell how to handle
    nil.  Personally, I would prefer having nil mean an empty list, but Spice
    code assumes you want to export the symbol nil.

Since (export (nil)) gets you the symbol interpretation, (export nil)
should mean (export ()).  This should be a general principle: things
that take symbols or lists of symbols interpret nil as ().  Of
course, this an example of how bankrupt having () be a symbol is.

∂24-Nov-85  0930	shebs%utah-orion@utah-cs.arpa 	Re:  Misc Queries  
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 24 Nov 85  09:30:46 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
	id AA16140; Sun, 24 Nov 85 10:30:56 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
	id AA27238; Sun, 24 Nov 85 10:30:53 MST
Date: Sun, 24 Nov 85 10:30:53 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8511241730.AA27238@utah-orion.ARPA>
To: Moon@scrc-stony-brook.arpa, shebs%utah-orion@utah-cs.arpa
Subject: Re:  Misc Queries
Cc: common-lisp@su-ai.arpa

    Date: Sat, 23 Nov 85 16:53 EST
    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
    
    The second sentence of the last paragraph on page 182 is quite explicit.
    The Spice implementation is not the definition of the language.

Well, now that I notice the sentence, it's pretty plain!  One of the
trouble with huge specs I suppose...  The reason I brought up Spice's
behavior is that a lot of people have based their implementations on
it, so any wrongnesses in it will be propagated unawares.  For instance,
the PCLS package system is actually derived indirectly from Spice, via
HP, who now presumably have something to fix in their implementation!
I don't mean to criticize Spice code either; by and large, it's some of
the cleanest implementation code I've seen, and we should all be thankful
to Fahlman & Co. for making it available.
    
        3) What is the general theory of destructive operations during lambda
        list processing (such as by initforms)? For instance, how much structure
        should be shared by an &rest binding and &key bindings?
    
    This would be clearer if you gave an example.  If you're thinking of something
    like
      (defun disgust (&rest r &key (a (setq r nil)) b)
        (list a b))
      (disgust :b 2)
    or even worse
      (defun disgust (&rest r &key (a (setf (second r) nil)) b)
        (list a b))
      (disgust :b 2)
    I don't think we anticipated that anybody would try this when we were designing
    the language.  I'd be happy to say that each of these is an error.
    
    I wasn't able to come up with any problematic examples that didn't involve
    modifying the &rest argument.  Did you have others in mind?

How about
  (defun more-disgusting (a &optional (b (setq a nil))) (list a b))

This is almost plausible (you could save a supplied-p for b), and the CLM
doesn't disallow it.  Perhaps the spec could be modified to say that
initforms may refer to parameters on the left, but not modify them.

							stan shebs


    
    

∂24-Nov-85  1500	Moon@SCRC-STONY-BROOK.ARPA 	Re:  Misc Queries
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Nov 85  14:58:29 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 361709; Sun 24-Nov-85 17:56:58-EST
Date: Sun, 24 Nov 85 17:55 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re:  Misc Queries
To: Stanley Shebs <shebs%utah-orion@UTAH-CS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8511241730.AA27238@utah-orion.ARPA>
Message-ID: <851124175559.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sun, 24 Nov 85 10:30:53 MST
    From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
    How about
      (defun more-disgusting (a &optional (b (setq a nil))) (list a b))

    This is almost plausible (you could save a supplied-p for b), and the CLM
    doesn't disallow it.  

I don't see anything at all problematic about this.  a is just a variable like
any other variable.  This doesn't have the problem that the previous examples
had, where the same data were being used for more than one argument: the rest
argument and the keyword arguments.

			  Perhaps the spec could be modified to say that
    initforms may refer to parameters on the left, but not modify them.

I don't see any reason to change the language here.


    
    


∂25-Nov-85  0739	gls@THINK-AQUINAS.ARPA 	LET-IF
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 25 Nov 85  07:39:08 PST
Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 2671; Mon 25-Nov-85 10:41:36-EST
Date: Mon, 25 Nov 85 10:40 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: LET-IF
To: GJC@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA, robbins%HUDSON.DEC.COM@GODOT.THINK.COM,
    gls@THINK-AQUINAS.ARPA
In-Reply-To: <[MIT-MC.ARPA].729508.851122.GJC>
Message-ID: <851125104047.2.GLS@FAUSTINUS.THINK.COM>

    Date: Fri, 22 Nov 85 20:41:51 EST
    From: "George J. Carrette" <GJC@MIT-MC.ARPA>

    ...

    Or, as Mr Roberts would say, "can you say... CLOSURE," yes boys and girls...


Hurrah for closures!  But did you mean "Mr. Roberts" or "Mr. Rogers"?
(I can't imagine Mr. Roberts talking about closures.  Then again,
it's just as hard to image Mr. Rogers talking about it.)
--Guy

∂25-Nov-85  0747	gls@THINK-AQUINAS.ARPA 	Minor typo 
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 25 Nov 85  07:47:32 PST
Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 2674; Mon 25-Nov-85 10:50:17-EST
Date: Mon, 25 Nov 85 10:49 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Minor typo
To: DLW@SCRC-QUABBIN.ARPA, common-lisp@SU-AI.ARPA
cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <851123164942.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-ID: <851125104923.3.GLS@FAUSTINUS.THINK.COM>

    Date: Sat, 23 Nov 85 16:49 EST
    From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>

    There seems to be a minor typo on page 23, second paragraph of 2.2.4,
    second line, in which an existential qualifier symbol appears where
    there ought to be a numeral "3".

Aw, c'mon!  I *know* the code font stinks...
--Guy

∂25-Nov-85  0752	gls@THINK-AQUINAS.ARPA 	Minor Typo = Major Faux Pas!   
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 25 Nov 85  07:52:05 PST
Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 2676; Mon 25-Nov-85 10:54:48-EST
Date: Mon, 25 Nov 85 10:53 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Minor Typo = Major Faux Pas! 
To: RPG@SU-AI.ARPA, common-lisp@SU-AI.ARPA
cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 23 Nov 85 19:28-EST from Dick Gabriel <RPG@SU-AI.ARPA>
Message-ID: <851125105359.4.GLS@FAUSTINUS.THINK.COM>

    Date: 23 Nov 85  1628 PST
    From: Dick Gabriel <RPG@SU-AI.ARPA>

    Dan mentioned that an existential quantifier was mistyped at some
    place where a 3 was meant. He meant to say the an existential
    quantifier was mistyped *every* place a 3 was meant. I think the
    spot to which he refers is a place where the TTY font for `3'
    belongs, and that representation of `3' looks exactly like an
    existential sign. This is because that is the best font Digital
    Press could come up with.
			    -rpg-


Similarly, on page 49, third line, you will see a terminal cursor
                           s
between "(integer " and " 2 -1)", and again on the next line.

That threw me during proofreading!

--Guy

∂25-Nov-85  1408	@SCRC-RIVERSIDE.ARPA:rsl@RUSSIAN.SPA.Symbolics.COM 	LET-IF  
Received: from SCRC-RIVERSIDE.ARPA by SU-AI.ARPA with TCP; 25 Nov 85  14:08:28 PST
Received: from CERRIDWYN.SSF.Symbolics.COM by SCRC-RIVERSIDE.ARPA via CHAOS with CHAOS-MAIL id 55745; Mon 25-Nov-85 17:16:31-EST
Received: from QUETZLCOATL.SSF.Symbolics.COM by CERRIDWYN.SSF.Symbolics.COM via CHAOS with CHAOS-MAIL id 55477; Mon 25-Nov-85 14:09:40-PST
Date: Mon, 25 Nov 85 14:08 PST
From: Richard Lamson <rsl@RUSSIAN.SPA.Symbolics.COM>
Subject: LET-IF
To: George J. Carrette <GJC@MIT-MC.ARPA>,
    robbins%bach.decnet@HUDSON.DEC.COM
cc: common-lisp@SU-AI.ARPA, robbins@HUDSON.DEC.COM
In-Reply-To: <[MIT-MC.ARPA].729508.851122.GJC>
Message-ID: <851125140843.3.RSL@QUETZLCOATL.SSF.Symbolics.COM>
Reply-To: RSL@SCRC-STONY-BROOK.ARPA

    Date: Fri, 22 Nov 85 20:41:51 EST
    From: "George J. Carrette" <GJC@MIT-MC.ARPA>

    Funny you should mention that, I'm considering flushing quite a few
    special forms in the LMI system and replacing them with macros, LET-IF
    is one, and the following definition seems right:

    (defmacro let-if (pred bindings &body body)
      (let ((f (gentemp "f")))
       `(flet ((,f () ,@body))
	   (if ,pred (let ,bindings (,f)) (,f)))))

Unfortunately, this doesn't work if you want the bindings to be lexical
instead of special bindings.  Consider:

   (defun xor (a b)
     (let-if a ((b (not b)))
       b))

Unless B is special, this won't work using your scheme.

∂25-Nov-85  1547	sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA 	Typos on p.284 and p.324
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 25 Nov 85  15:47:24 PST
Received: from tektronix by csnet-relay.csnet id ac04345; 25 Nov 85 18:38 EST
From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
To: common-lisp@su-ai.ARPA
Fcc: cl-mail
Received: from tekchips by tektronix with smtp ; 25 Nov 85 09:45:08 PST
Date: Monday, 25 Nov 85 09:36:19 PST
Subject:  Typos on p.284 and p.324


p.284: A minor grammatical typo :
      Near the beginning of the last quarter of the page , the
sentence:
   "means the approximately the same as"  should read
   "means approximately the same as" 

p.324:  The second and third line: From the trace , it would appear
that the second argument to the floor function was intended to be 3
and not 2. So the 2 in these two lines should be replaced by a 3.

p.67: Another one pointed out by a colleague: At the beginning of the 
page it says: "The defun special form ...." and in the very next line
defun is said to be a macro. [ defun does not appear in the list
of special forms on p.57 ]. Light ?

--sridhar


∂25-Nov-85  1715	RPG  	New, Improved Agenda    
To:   Common-lisp@SU-AI.ARPA

Here is an outline of my idea of the agenda we should use for the
meeting:

Sunday Night:
	Registration and intense lobyying

Monday, December 9
	8:30am  Welcome, registration, and coffee
	(Registration information will used for updating the mailing
	 lists, possible dunning for expenses unless I can sweet talk
	 DARPA into fronting some money for this meeting, and for making
	 sure that the groups are represented.)

	9:00am  Charter Discussion
	Noon	Lunch. You are on your own for this.
	1:30pm	Charter/Validation Discussion
	6:00pm  Dinner (Intense Lobbying and Discussions)

Tuesday
	8:30am 	Coffee
	9:00am  Charter/Validation/ANSI etc Discussion
	12:00   Lunch. You are on your own.
	1:30pm  Object-oriented programming
	6:00pm  Dinner

Wednesday
	8:30am 	Coffee
	9:00am  Windows
	12:00   Lunch. You are on your own.
	1:30pm  Windows/Errors/Varia
	5:00pm  Hit the Road

During the Charter discussion, the following topics will be discussed:

	Fahlman's Proposals

	Inclusion of the recent minor changes and errata to the 
	Common Lisp specification

	Publishing problems - Copyright, additions to the book

	Validation

	Real standardization

During the object oriented programming session, Symbolics will present
some the developments going on there with respect to flavors. Xerox will
present their plans for CommonLoops testing using an implementation that
they have been working on. I expect that the discussions will focus more
closely on the methods and plans for evaluating the various proposals than
on the detailed technical merits of the proposals.

During the Windows discussion proposals can be presented along with
implementation plans. 

For people who would like to make presentations, here are some guidelines:

	1. Overhead or 35 millimeter slides are OK
	2. Let me know that you want to make a presentation
	   as well as why a formal presentation is necessary.
	3. If you want to include a handout, make at least 50 copies
	   (that's about 1 per group).
	4. Try to limit your presentation to 30 minutes, maximum. I
	   will have a large hook.

			-rpg-

∂26-Nov-85  0537	BSG@SCRC-STONY-BROOK.ARPA 	LET-IF  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Nov 85  05:37:32 PST
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 362815; Tue 26-Nov-85 08:35:48-EST
Date: Tue, 26 Nov 85 08:42 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: LET-IF
To: RSL@SCRC-STONY-BROOK.ARPA, GJC@MIT-MC.ARPA,
    robbins%bach.decnet@HUDSON.DEC.COM
cc: common-lisp@SU-AI.ARPA, robbins@HUDSON.DEC.COM
In-Reply-To: <851125140843.3.RSL@QUETZLCOATL.SSF.Symbolics.COM>
Message-ID: <851126084235.2.BSG@CONCORD.SCRC.Symbolics.COM>

    Date: Mon, 25 Nov 85 14:08 PST
    From: Richard Lamson <rsl@RUSSIAN.SPA.Symbolics.COM>

	Date: Fri, 22 Nov 85 20:41:51 EST
	From: "George J. Carrette" <GJC@MIT-MC.ARPA>

	Funny you should mention that, I'm considering flushing quite a few
	special forms in the LMI system and replacing them with macros, LET-IF
	is one, and the following definition seems right:

	(defmacro let-if (pred bindings &body body)
	  (let ((f (gentemp "f")))
	   `(flet ((,f () ,@body))
	       (if ,pred (let ,bindings (,f)) (,f)))))

    Unfortunately, this doesn't work if you want the bindings to be lexical
    instead of special bindings.  Consider:

       (defun xor (a b)
	 (let-if a ((b (not b)))
	   b))

    Unless B is special, this won't work using your scheme.

I can't imagine what LET-IF would mean with lexical variables
no matter what the implementation.

∂26-Nov-85  0805	GJC@MIT-MC.ARPA 	Mr Roberts vs Mr Rogers
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 26 Nov 85  08:03:30 PST
Date: Tue, 26 Nov 85 11:06:00 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject:  Mr Roberts vs Mr Rogers
To: gls@AQUINAS.THINK.COM
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Mon 25 Nov 85 10:40 EST from Guy Steele <gls at THINK-AQUINAS.ARPA>
Message-ID: <[MIT-MC.ARPA].733419.851126.GJC>

Too much jungle juice I suppose.

∂26-Nov-85  0940	GJC@MIT-MC.ARPA 	Mr Roberts vs Mr Rogers
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 26 Nov 85  08:03:30 PST
Date: Tue, 26 Nov 85 11:06:00 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject:  Mr Roberts vs Mr Rogers
To: gls@AQUINAS.THINK.COM
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Mon 25 Nov 85 10:40 EST from Guy Steele <gls at THINK-AQUINAS.ARPA>
Message-ID: <[MIT-MC.ARPA].733419.851126.GJC>

Too much jungle juice I suppose.

∂26-Nov-85  0959	gls@THINK-AQUINAS.ARPA 	LET-IF
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 26 Nov 85  09:55:41 PST
Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 2970; Tue 26-Nov-85 12:17:09-EST
Date: Tue, 26 Nov 85 12:15 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: LET-IF
To: BSG@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <851126084235.2.BSG@CONCORD.SCRC.Symbolics.COM>
Message-ID: <851126121559.6.GLS@FAUSTINUS.THINK.COM>

    Date: Tue, 26 Nov 85 08:42 EST
    From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>

	Date: Mon, 25 Nov 85 14:08 PST
	From: Richard Lamson <rsl@RUSSIAN.SPA.Symbolics.COM>

	    Date: Fri, 22 Nov 85 20:41:51 EST
	    From: "George J. Carrette" <GJC@MIT-MC.ARPA>

	    Funny you should mention that, I'm considering flushing quite a few
	    special forms in the LMI system and replacing them with macros, LET-IF
	    is one, and the following definition seems right:

	    (defmacro let-if (pred bindings &body body)
	      (let ((f (gentemp "f")))
	       `(flet ((,f () ,@body))
		   (if ,pred (let ,bindings (,f)) (,f)))))

	Unfortunately, this doesn't work if you want the bindings to be lexical
	instead of special bindings.  Consider:

	   (defun xor (a b)
	     (let-if a ((b (not b)))
	       b))

	Unless B is special, this won't work using your scheme.

    I can't imagine what LET-IF would mean with lexical variables
    no matter what the implementation.

    Date: Tue, 26 Nov 85 08:42 EST
    From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>

	Date: Mon, 25 Nov 85 14:08 PST
	From: Richard Lamson <rsl@RUSSIAN.SPA.Symbolics.COM>

	    Date: Fri, 22 Nov 85 20:41:51 EST
	    From: "George J. Carrette" <GJC@MIT-MC.ARPA>

	    Funny you should mention that, I'm considering flushing quite a few
	    special forms in the LMI system and replacing them with macros, LET-IF
	    is one, and the following definition seems right:

	    (defmacro let-if (pred bindings &body body)
	      (let ((f (gentemp "f")))
	       `(flet ((,f () ,@body))
		   (if ,pred (let ,bindings (,f)) (,f)))))

	Unfortunately, this doesn't work if you want the bindings to be lexical
	instead of special bindings.  Consider:

	   (defun xor (a b)
	     (let-if a ((b (not b)))
	       b))

	Unless B is special, this won't work using your scheme.

    I can't imagine what LET-IF would mean with lexical variables
    no matter what the implementation.

I can imagine: (let-if a ((b (not b))) (f b)) means

	(if a (let ((b (not b))) (f b)) (f b)).

But in most such cases I should imagine

	(let ((b (if a (not b) b))) (f b))

would do just as well (and result in better code), because a redundant
bindings of b to iself doesn't hurt in the lexical case (whereas it is
not allowed in the special case, as it would result in visibly different
semantics).

∂26-Nov-85  1128	hplabs!schumacher@hplabs.ARPA 	Amatuer Archivists.
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 26 Nov 85  11:28:02 PST
Received: from hplabs.arpa by CSNET-RELAY.ARPA id a012324; 26 Nov 85 14:21 EST
Received: by hplabsd ; Tue, 26 Nov 85 11:21:21 pst
Date: Monday, November 25, 1985  15:17:03
From: schumacher@hplabs.arpa
Subject: Amatuer Archivists.
To: hplabs!gls%aquinas.think.com@csnet-relay.arpa
Cc: common-lisp <@csnet-relay.arpa:common-lisp@su-ai.arpa>
In-Reply-To: Your message of 26-Nov-85  12:15:00
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46

Is it really necessary to include the @i(entire) text of a previous msg to
reference it ?  Guy's last msg was a particularly egregious example, starting out
with :


    Date: Tue, 26 Nov 85 08:42 EST
    From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>

	Date: Mon, 25 Nov 85 14:08 PST
	From: Richard Lamson <rsl@RUSSIAN.SPA.Symbolics.COM>

	    Date: Fri, 22 Nov 85 20:41:51 EST
	    From: "George J. Carrette" <GJC@MIT-MC.ARPA>

and then repeating it a SECOND time.  Really folks,  its not like we're all reading
mail with a line editor. 

 Lee
-------

∂26-Nov-85  1200	gls@THINK-AQUINAS.ARPA 	Amatuer Archivists.  
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 26 Nov 85  11:57:33 PST
Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 3017; Tue 26-Nov-85 15:00:28-EST
Date: Tue, 26 Nov 85 14:59 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Amatuer Archivists.
To: schumacher!hplabs@CSNET-RELAY.ARPA
cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 25 Nov 85 15:17-EST from schumacher@hplabs.arpa
Message-ID: <851126145919.0.GLS@FAUSTINUS.THINK.COM>

    Da e:  on ay, No  mb r  5, 1 8   15:1 : 3
    From  s huma he @h  abs.ar a

    Is  t  eally   ce sa y to i  lude  h  @ ( ntire  t xt o  a pr  ious m g  o
    r fe ence i  ?  Gu 's l s  msg w s a  a ticul  l  egr gi us  xample  s art ng  ut
    wi   : 

	Date   u , 26 N v 8  08:42  ST
	Fr m: Ber ard S. Gre nb rg  BS  SCRC-  ONY B OOK. R A 

	    Dat   Mon,  5  ov  5  4:0  PST
	     ro : R ch  d Lam  n < s @RUS I N SPA. y bol  s.COM  

		Dat : Fri  22 No  85 20: 1: 1 E T
		Fr m:  Ge rge J.  arret  " < J @MIT M . RPA> 

     a d th n  epeat n  i    SECO    ime.  R al   folks    ts  ot  ik  we're  ll
     re di g     mail w th a lin    itor. 

     Lee
     -------

Well, if we're all not using line editors, then having all that text
there shouldn't hurt.  The redundant copy was, of course, an error on my
part (sorry).  There is also somewhat of a tradition of allowing large
messages to build up occasionally.  The likelihood of this happening is
inversely correlated with the seriousness of the subject matter.

Please note that, to save space, I have excerpted and condensed your
original message above.

--Quux

∂26-Nov-85  1202	gls@THINK-AQUINAS.ARPA 	Amatuer Archivists (again)
Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 26 Nov 85  12:02:17 PST
Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 3021; Tue 26-Nov-85 15:05:22-EST
Date: Tue, 26 Nov 85 15:04 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Amatuer Archivists (again)
To: schumacher!hplabs@CSNET-RELAY.ARPA
cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 25 Nov 85 15:17-EST from schumacher@hplabs.arpa
Message-ID: <851126150415.1.GLS@FAUSTINUS.THINK.COM>

On a more serious note, I receive anywhere between 20 and 100 messages a
day by electronic mail.  Not infrequently there are three or four
distinct conversations on the common-lisp mailing list alone, and then
there are other mailing lists, as well as mail related to work I
actually get paid for.  I often find it helpful to have some previous
context for each message.  Maybe I tend to overdo it because I rely on
it more than others do.  I'm sorry that I upset you.
--Guy

∂26-Nov-85  1202	KMP@SCRC-STONY-BROOK.ARPA 	DEFSTRUCT and predicates    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Nov 85  12:02:26 PST
Received: from DUPAGE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 363211; Tue 26-Nov-85 14:48:26-EST
Date: Tue, 26 Nov 85 14:49 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: DEFSTRUCT and predicates
To: ALAN@MIT-MC.ARPA, GLS@THINK-AQUINAS.ARPA
cc: Common-Lisp@SU-AI.ARPA
Message-ID: <851126144928.6.KMP@DUPAGE.SCRC.Symbolics.COM>

The :PREDICATE option to DEFSTRUCT (CLtL, p312) violates the supposed 
convention for the formation of predicate names (CLtL, p71) by blindly
adding -P to the end of the symbol rather than adding just "P" when 
there is no "-" in the base symbol.

∂26-Nov-85  1224	WHOLEY@C.CS.CMU.EDU 	DEFSTRUCT and predicates
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Nov 85  12:21:04 PST
Received: ID <WHOLEY@C.CS.CMU.EDU>; Tue 26 Nov 85 15:20:05-EST
Date: Tue, 26 Nov 1985  15:20 EST
Message-ID: <WHOLEY.12162392973.BABYL@C.CS.CMU.EDU>
Sender: WHOLEY@C.CS.CMU.EDU
From: Skef Wholey <Wholey@C.CS.CMU.EDU>
To:   Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc:   ALAN@MIT-MC.ARPA, Common-Lisp@SU-AI.ARPA, GLS@AQUINAS.THINK.COM
Subject: DEFSTRUCT and predicates
In-reply-to: Msg of 26 Nov 1985  14:49-EST from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>

    Date: Tuesday, 26 November 1985  14:49-EST
    From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>

    The :PREDICATE option to DEFSTRUCT (CLtL, p312) violates the supposed 
    convention for the formation of predicate names (CLtL, p71) by blindly
    adding -P to the end of the symbol rather than adding just "P" when 
    there is no "-" in the base symbol.

Yeah, at one point the language spec (or at least the language specifiers) said
that defstrict would "do the right thing" with defstruct predicates.  This
decision was changed to the current one for some reason I don't recall.  Note
that one can get the right effect by specifying the predicate name onesself.
As both an implementor and user of defstruct, I like the current situation -- I
don't think the naming conventions used by the system supplied functions should
be forced upon every single programmer.

Of course, Common Lisp follows a somewhat more complicated hueristic with
"-P"'ing things (e.g. Alpha-Charp).  It's better that a program like defstruct
always do the same predictable dumb thing all the time than try to be clever
when it's going to be wrong occasionally.

--Skef

∂26-Nov-85  1418	NGALL@BBNG.ARPA 	Re: DEFSTRUCT and predicates
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 26 Nov 85  14:17:52 PST
Date: 26 Nov 1985 17:20-EST
Sender: NGALL@BBNG.ARPA
Subject: Re: DEFSTRUCT and predicates
From: NGALL@BBNG.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[BBNG.ARPA]26-Nov-85 17:20:36.NGALL>
In-Reply-To: <WHOLEY.12162392973.BABYL@C.CS.CMU.EDU>

	
    From: Skef Wholey <Wholey@C.CS.CMU.EDU>
    To:   Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
    Subject: DEFSTRUCT and predicates
    Message-ID: <WHOLEY.12162392973.BABYL@C.CS.CMU.EDU>
    
	Date: Tuesday, 26 November 1985  14:49-EST
	From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
    
	The :PREDICATE option to DEFSTRUCT (CLtL, p312) violates the supposed 
	convention for the formation of predicate names (CLtL, p71) by blindly
	adding -P to the end of the symbol rather than adding just "P" when 
	there is no "-" in the base symbol.
    
    Yeah, at one point the language spec (or at least the language specifiers) said
    that defstrict would "do the right thing" with defstruct predicates.  This
    decision was changed to the current one for some reason I don't recall.  Note
    that one can get the right effect by specifying the predicate name onesself.
    As both an implementor and user of defstruct, I like the current situation -- I
    don't think the naming conventions used by the system supplied functions should
    be forced upon every single programmer.
    
    Of course, Common Lisp follows a somewhat more complicated hueristic with
    "-P"'ing things (e.g. Alpha-Charp).  It's better that a program like defstruct
    always do the same predictable dumb thing all the time than try to be clever
    when it's going to be wrong occasionally.
    
    --Skef
    
    
	      --------------------
		
The only complexity in the CL "-P" heuristic is dealing with qualified
predicates such as string-(lessp).  Since defstruct created predicates
will ALWAYS be suffixing data-type names (NEVER existing predicate
names), defstruct can safely use the simple hyphenation heuristic,
i.e., if the data-type name is hyphenated, add "-P", otherwise add
"P".  Can anyone think of counter-examples?

I think defstruct SHOULD obey the CL convention.  At the very least,
it should be documented that it is BREAKING the convention.

	-- Nick

∂26-Nov-85  1528	WHOLEY@C.CS.CMU.EDU 	DEFSTRUCT and predicates
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Nov 85  15:28:09 PST
Received: ID <WHOLEY@C.CS.CMU.EDU>; Tue 26 Nov 85 18:27:46-EST
Date: Tue, 26 Nov 1985  18:27 EST
Message-ID: <WHOLEY.12162427138.BABYL@C.CS.CMU.EDU>
Sender: WHOLEY@C.CS.CMU.EDU
From: Skef Wholey <Wholey@C.CS.CMU.EDU>
To:   NGALL@BBNG.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: DEFSTRUCT and predicates
In-reply-to: Msg of 26 Nov 1985  17:20-EST from NGALL at BBNG.ARPA

    Date: Tuesday, 26 November 1985  17:20-EST
    From: NGALL at BBNG.ARPA

    The only complexity in the CL "-P" heuristic is dealing with qualified
    predicates such as string-(lessp).  Since defstruct created predicates
    will ALWAYS be suffixing data-type names (NEVER existing predicate
    names), defstruct can safely use the simple hyphenation heuristic,
    i.e., if the data-type name is hyphenated, add "-P", otherwise add
    "P".  Can anyone think of counter-examples?

How about:

(defstruct person
  mom
  dad
  kids
  shoe-size)

(defstruct (space-person (:include person))
  planet-of-birth
  number-of-eyes)

Space-Person-P (or Space-Personp) is what you call a "qualified predicate."

    I think defstruct SHOULD obey the CL convention.  At the very least,
    it should be documented that it is BREAKING the convention.

Yes, such a note in the manual would be worthwhile.

--Skef

∂26-Nov-85  2233	TIM@MIT-MC.ARPA 	Amatuer Archivists (again)  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 26 Nov 85  22:33:46 PST
Date: Wed, 27 Nov 85 01:36:13 EST
From: Tim McNerney <TIM@MIT-MC.ARPA>
Subject:  Amatuer Archivists (again)
To: common-lisp@SU-AI.ARPA
cc: schumacher!hplabs@CSNET-RELAY.ARPA, gls@THINK.COM
Message-ID: <[MIT-MC.ARPA].734507.851127.TIM>

I sympathize with those of you who have short terminals and have to wade
through pages and pages of "context."  (About 1/2 of my terminal's ram is
shot, so mine is about 14 lines tall).  But I also agree with Steele.

Perhaps the problem lies with the conventions we use for replying to mail.
If, instead of putting the reply at the end of the message (as is so easy to
do when using BABYL, RMAIL and ZMAIL), we put our reply at the beginning, we
could have the best of both worlds: Immediacy and Context.

	Tim

    Date: Tue, 26 Nov 85 15:04 EST
    From: Guy Steele <gls at THINK-AQUINAS.ARPA>

    On a more serious note, I receive anywhere between 20 and 100 messages a
    day by electronic mail.  Not infrequently there are three or four
    distinct conversations on the common-lisp mailing list alone, and then
    there are other mailing lists, as well as mail related to work I
    actually get paid for.  I often find it helpful to have some previous
    context for each message.  Maybe I tend to overdo it because I rely on
    it more than others do.  I'm sorry that I upset you.
    --Guy

∂27-Nov-85  1901	mips!escargot.earl@glacier 	lexical scope and dynamic extent
Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 27 Nov 85  19:01:49 PST
Received: by glacier with Sendmail; Wed, 27 Nov 85 19:01:17 pst
Received: from escargot.UUCP (escargot.ARPA) by mips.UUCP (4.12/4.7)
	id AA11694; Wed, 27 Nov 85 18:32:27 pst
Received: by escargot.UUCP (4.12/4.7)
	id AA15071; Wed, 27 Nov 85 18:31:55 pst
Date: Wed, 27 Nov 85 18:31:55 pst
From: mips!escargot.earl@glacier (Earl Killian)
Message-Id: <8511280231.AA15071@escargot.UUCP>
To: common-lisp@su-ai.ARPA
Subject: lexical scope and dynamic extent

Some entities in the language are described as having lexical scope
and dynamic extent, which means that they can be refered to after
they're gone.  Do any of the implementations have good ways of
detecting such things?  Here's a nasty one:

(defun foo ()
  (tagbody
    l (return-from foo #'(lambda () (go l)))))
(funcall (foo))

If you type this at various implementations, what do you get?

∂27-Nov-85  2011	BROOKS%MIT-OZ@MIT-MC.ARPA 	Re: lexical scope and dynamic extent  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Nov 85  20:11:13 PST
Date: Wed 27 Nov 85 23:11:34-EST
From: "Rodney A. Brooks" <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: Re: lexical scope and dynamic extent
To: mips!escargot.earl@SU-GLACIER.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8511280231.AA15071@escargot.UUCP>
Message-ID: <12162740965.44.BROOKS@MIT-OZ>

In Lucid's SUN Common Lisp 1.0, compiled foo, you get

>>Error: A go to one of (L) occured from within an out of scope closure

Maybe the English needs a little work...

    Date: Wed, 27 Nov 85 18:31:55 pst
    From: mips!escargot.earl@glacier (Earl Killian)
    Message-Id: <8511280231.AA15071@escargot.UUCP>
    To: common-lisp@su-ai.ARPA
    Subject: lexical scope and dynamic extent

    Some entities in the language are described as having lexical scope
    and dynamic extent, which means that they can be refered to after
    they're gone.  Do any of the implementations have good ways of
    detecting such things?  Here's a nasty one:

    (defun foo ()
      (tagbody
        l (return-from foo #'(lambda () (go l)))))
    (funcall (foo))

    If you type this at various implementations, what do you get?
-------

∂28-Nov-85  1051	ACUFF@SUMEX-AIM.ARPA 	Re: lexical scope and dynamic extent  
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 28 Nov 85  10:51:25 PST
Date: Thu 28 Nov 85 10:51:07-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Re: lexical scope and dynamic extent
To: mips!escargot.earl@SU-GLACIER.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <8511280231.AA15071@escargot.UUCP>
Message-ID: <12162901082.56.ACUFF@SUMEX-AIM.ARPA>

   In Explorer Common Lisp you get:

>>>ERROR: GO tag L is not defined or is no longer valid

which seems reasonable given the statment near the top of pg. 131 of
CLtL, "Once a tagbody construct has been exited, it is no longer legal
to go to a tag in its body."

   I think you may be confusing dynamic extent and indefinite extent.
An entity with dynamic extent (in this case the tag) continues to
exist only as long as the form that establishes it (the tagbody),
while entities with indefinite extent continue to exist as long as
there is a reference to them.

	-- Rich
-------

∂30-Nov-85  1245	RPG  	ANSI/ISO 
To:   quinquevirate@SU-AI.ARPA   

I had hoped to have gotten the full story behind what I'm about to
relate to you before I had to send this message, but time before the
CL meeting is short, and I'll have to remember the story as best I can.

ISO met some time in September or October. Steve Squires sent his friend,
Bob Mathis, who was part of the Ada ISO committee (?). The meeting was in
Paris, and Steve was concerned that `something funny' would happen. As it
turned out, France proposed to propose a Lisp standard and volunteered to
head the Lisp committee. Being primed, Mathis stepped in and got himself
appointed head of the ad hoc committee to study the question of an ISO
standard Lisp.

Squires put Mathis in touch with me to start the wheels in motion for the
Common Lisp group to do something about France's bid. I have heard rumors
of French disappointment with CL (mostly voiced by Jerome Chailloux).

I believe that we may have to respond to this challenge somehow or other,
and possibly it requires us to start down the true standardization road.
Not having seen this road before, it doesn't scare me, but I gather it scares
many others. Mathis is coming to the meeting, and we can discuss the issues
more fully with him.

∂30-Nov-85  1257	RPG  	More on the CL meeting  
To:   quinquevirate@SU-AI.ARPA   

Would you folks be interested in a caucus before the meeting to talk
about what you think will go on? We can caucus via this medium, if you
like.

Having seen how these meetings tend to go, I'd like to recommend the
style of meeting in which people are recognized to hold the floor for
some length of time, yielding in formal ways to others. This would
be along the normal lines of parliamentary rules. I want to keep the
randomness to a minimum, and I can easily imagine someone like Carrette 
and Jonl going at it with each other - this I want to avoid.

The three proposals for charter that seem viable are the Fahlman
full-blown proposal of Jan 21, the Fahlman mimimalist proposal of Feb 18,
and the Fahlman Common Lisp Club idea. This last idea, if I may present
it, is for us to form a Common Lisp Organization as a private `club,'
with rules and bylaws, and curious document called the Common Lisp Book.
People may join the club and agree to live by the Book, but CL is no more
standard than that. Fahlman's idea is a little less silly than that sounds,
in that it would be a legal organization with some instrument of `incorporation'
of some sort. 

I propose we put these proposals on the table for discussion and record
the opinions we get at the meeting.

One phenomenon I'd like to point out to you as existing, but about which you
might not be aware, is that a large fraction of the programming-related
world that knows of Common Lisp, believes that there is a Common Lisp Group
that makes decisions and holds a standard somewhere. People are constantly
calling me and asking when the Common Lisp Group will decide this, that, or
the other thing.  People tend to identify that group with us. Perhaps it's
time for us to demonstrate a little more leadership than we have in the past.
			-rpg-

∂01-Dec-85  1219	DLW@SCRC-STONY-BROOK.ARPA 	lexical scope and dynamic extent 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 1 Dec 85  12:19:26 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 364776; Sun 1-Dec-85 15:17:00-EST
Date: Sun, 1 Dec 85 15:23 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: lexical scope and dynamic extent
To: mips!escargot.earl@SU-GLACIER.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <8511280231.AA15071@escargot.UUCP>
Message-ID: <851201152340.2.DLW@CHICOPEE.SCRC.Symbolics.COM>

In the Symbolics system, interpreted, you get

>>Error: The GO tag L is no longer dynamically active

Compiled, you get a less-comprehensible error message:

>>Error: Attempt to %UNWIND-INTO-FRAME-AT-PC to a frame not running a
compiled function

In both cases, the system has detected that something's wrong.  In the
latter case, it goes to look for the tag, and finds an interpreted frame
where it expected a compiled frame, because the outer frame is gone.  To
improve the error message, we'd probably have to add some more
debugging-info (debugging-info is extra structure that lives with a
compiled code object to help the system create error messages and to
help various debugging tools figure out what's happening, among other
things).  It wouldn't be particularly hard.

∂01-Dec-85  1645	NGALL@BBNG.ARPA 	Re: DEFSTRUCT and predicates
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 1 Dec 85  16:44:32 PST
Date: 1 Dec 1985 19:47-EST
Sender: NGALL@BBNG.ARPA
Subject: Re: DEFSTRUCT and predicates
From: NGALL@BBNG.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[BBNG.ARPA] 1-Dec-85 19:47:09.NGALL>
In-Reply-To: <WHOLEY.12162427138.BABYL@C.CS.CMU.EDU>

	
    Date: Tue, 26 Nov 1985  18:27 EST
    From: Skef Wholey <Wholey@C.CS.CMU.EDU>
    To:   NGALL@BBNG.ARPA
    Subject: DEFSTRUCT and predicates
    In-Reply-To: Msg of 26 Nov 1985  17:20-EST from NGALL at BBNG.ARPA
    Message-ID: <WHOLEY.12162427138.BABYL@C.CS.CMU.EDU>
    
	Date: Tuesday, 26 November 1985  17:20-EST
	From: NGALL at BBNG.ARPA
    
	The only complexity in the CL "-P" heuristic is dealing with qualified
	predicates such as string-(lessp).  Since defstruct created predicates
	will ALWAYS be suffixing data-type names (NEVER existing predicate
	names), defstruct can safely use the simple hyphenation heuristic,
	i.e., if the data-type name is hyphenated, add "-P", otherwise add
	"P".  Can anyone think of counter-examples?
    
    How about:
    
    (defstruct person
      mom
      dad
      kids
      shoe-size)
    
    (defstruct (space-person (:include person))
      planet-of-birth
      number-of-eyes)
    
    Space-Person-P (or Space-Personp) is what you call a "qualified predicate."
    
Hmmm.  I think I disagree.  I don't think Space-Person-P falls under
the CL definition of "qualified predicate":

1. The rationale for for NOT hyphenating the "P" in "STRING-LESSP" is
that it would "incorrectly imply that it is a predicate that tests for
a kind of object called a STRING-LESS."  This is exactly what we WANT
to imply in the case of SPACE-PERSON; so the predicate should be
SPACE-PERSON-P.

2. Your definition by example would require that SIMPLE-STRING-P
become SIMPLE-STRINGP, BIT-VECTOR-P become BIT-VECTORP, etc., since
STRINGP, VECTORP, etc., are already predicates.

3. In my opinion, the only predicates that retain their
"P"s "as is" are predicates such as lessp, greaterp, equalp, i.e.,
non-type-predicates.  And these are the kind of predicate that
defstruct will never have to deal with.

	-- Nick

∂01-Dec-85  1756	Moon@SCRC-STONY-BROOK.ARPA 	More on the CL meeting     
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 1 Dec 85  17:56:22 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 364899; Sun 1-Dec-85 20:53:51-EST
Date: Sun, 1 Dec 85 20:52 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: More on the CL meeting  
To: Dick Gabriel <RPG@SU-AI.ARPA>
cc: quinquevirate@SU-AI.ARPA
In-Reply-To: The message of 30 Nov 85 15:57-EST from Dick Gabriel <RPG@SU-AI.ARPA>
Message-ID: <851201205239.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 30 Nov 85  1257 PST
    From: Dick Gabriel <RPG@SU-AI.ARPA>

    Would you folks be interested in a caucus before the meeting to talk
    about what you think will go on? We can caucus via this medium, if you
    like.

I'm busy but willing to listen to mail.  I have not planned to participate in
the charter discussion at all.

    ....One phenomenon I'd like to point out to you as existing, but about which you
    might not be aware, is that a large fraction of the programming-related
    world that knows of Common Lisp, believes that there is a Common Lisp Group
    that makes decisions and holds a standard somewhere. People are constantly
    calling me and asking when the Common Lisp Group will decide this, that, or
    the other thing.  People tend to identify that group with us. Perhaps it's
    time for us to demonstrate a little more leadership than we have in the past.

Does this mean that a fourth proposal should be put on the table, that anything
to which the five people on the title page of the manual agree among themselves
is the law and everyone else has to accept it?

∂02-Dec-85  0815	FAHLMAN@C.CS.CMU.EDU 	ANSI/ISO     
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Dec 85  08:15:23 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 2 Dec 85 11:11:42-EST
Date: Mon, 2 Dec 1985  11:11 EST
Message-ID: <FAHLMAN.12163920553.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   quinquevirate@SU-AI.ARPA
Subject: ANSI/ISO 


I'm not convinced that the ISO thing is any kind of threat to the spread
of Common Lisp.  Suppose we do nothing.  The French get ISO to form a
committee on Lisp, seize control of it, and produce some silly standard
based on Le Lisp.  My guess is that all of the major U.S. manufacturers,
plus most manufacturers in Japan and some in Europe (Siemens, for
example) will ignore this and continue to develop Common Lisp and things
based on Common Lisp.

If that's how it works out, how does the ISO business hurt anything?  Is
there really a chance that anyone outside of the EEC would follow the
ISO standard, or that it would lead to a serious split if some Europeans
did decide to fillow ISO?  Some of the Europeans will undoubtedly find
some reason to split off anyway, just to keep their record for chronic
wrong-headedness intact.  Might European governments require ISO Lisp,
even though that shuts them off from all of the best technology?  I
suppose that an ISO standard would give the French an excuse to split
off by themselves while saying that they are right and everyone else is
wrong, since only they are adhering to the ISO standard, but the French
do this all the time anyway and the rest of the world ignores them.  If
we're careful to lend no credibility to the ISO thing, it should just
disappear as so many silly standards have in the past.

So unless someone can make a case for why this is important, I say we
should just ignore it, after maybe a bit of discussion at the meeting.

-- Scott

∂02-Dec-85  0822	FAHLMAN@C.CS.CMU.EDU 	More on the CL meeting      
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Dec 85  08:22:17 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 2 Dec 85 11:22:11-EST
Date: Mon, 2 Dec 1985  11:22 EST
Message-ID: <FAHLMAN.12163922524.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   quinquevirate@SU-AI.ARPA
Subject: More on the CL meeting  
In-reply-to: Msg of 30 Nov 1985  15:57-EST from Dick Gabriel <RPG at SU-AI.ARPA>


I am preparing some thoughts on charter stuff that I will send out later
today. 

It would be helpful if one of the Boston people (

∂02-Dec-85  0828	DLW@SCRC-STONY-BROOK.ARPA 	More on the CL meeting      
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 Dec 85  08:28:43 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 365216; Mon 2-Dec-85 11:23:12-EST
Date: Mon, 2 Dec 85 11:29 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: More on the CL meeting  
To: Moon@SCRC-STONY-BROOK.ARPA
cc: quinquevirate@SU-AI.ARPA
In-Reply-To: <851201205239.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <851202112950.6.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Sun, 1 Dec 85 20:52 EST
    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>

    Does this mean that a fourth proposal should be put on the table, that anything
    to which the five people on the title page of the manual agree among themselves
    is the law and everyone else has to accept it?

I didn't get the impression that RPG was suggesting anything quite that
extreme.  I, too, am aware that lots of people assume that there is a
"Common Lisp committee" out there somewhere, and that things are under
some kind of control.  Right now, of course, that's not true; we don't
even have a forum for resolving ambiguities in the manual.

Big meetings such as the upcoming one can go on for a long time and not
produce any results, and if that happens at this meeting, not only will
we all feel like we wasted our time, but we will probably give up on
ever trying to have such a meeting again, because we'll be convinced
that it's hopeless.  So it's important that this meeting get something
done, and give us all the feeling that progress is being made.  The
question is how to help assure that the meeting really is effective.

My interpretation of what RPG was suggesting is that one way to help
make sure something happens is for us to show some leadership.  We hope
that if we can form a core group (a) with a more or less consistent
opinion, and (b) with our implied prestige, then this might form a seed
around which other opinions could crystalize.  If it turns out that a
lot of people are opposed to what the five of us might feel, then of
course we don't take any special kind of precedence.  What we're trying
to prevent is a situation in which there are several alternatives, some
of which are better than doing nothing at all, but nothing at all gets
done because there's no way to build a concensus.  At least that's my
interpretation.

∂02-Dec-85  1051	FAHLMAN@C.CS.CMU.EDU 	as I was saying...
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Dec 85  10:51:23 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 2 Dec 85 13:51:21-EST
Date: Mon, 2 Dec 1985  13:51 EST
Message-ID: <FAHLMAN.12163949688.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   quinquevirate@SU-AI.ARPA
Subject: as I was saying...


The last message went off half-cocked.  I was trying to say two things:

1. I have some thoughts on the charter stuff that I will try to cast
into some usable form and get off to the rest of you later today.

2. It would help if someone in Boston (maybe Guy) were to investigate
what effect this hotel strike is likely to have on the upcoming
conference.  If by the end of this week it looks like the hotel we are
meeting in is down, we might need to cancel this whole thing.

-- Scott

∂02-Dec-85  1054	RPG  	ANSI/ISO and Hotel Strike    
To:   quinquevirate@SU-AI.ARPA   

I'm simply not sure whether or not having an ISO standard Lisp
makes any difference, either in general or anymore. It seems
we are at the crossroads as to whether Common Lisp remains the
`property' of us (the CLG at large) or whether it is part of the
world at large.

There are two possible courses: Leave standardization alone, and
go after it.

People mention horror stories. So far the people who have done so
are people who would seem to be otherwise afraid of political
battle. I'll buy a lobster dinner at Legal for any one of you who
can tell me a real horror story that actually happened and which
scares me in some way. If we ignored all standardization, that makes
a statement against official standards and also tells the world
we are above the normal hue and cry. Is that what we want?

If we go for standardization, we should aim to avoid to the supposed
horror scenarios and thereby show the world that it can be done. Then
we'll be able to tell our friends anti-horror stories about the
standardization battle. 

Suppose we start down the ISO route and it gets bad, can't we simply
drop it or lose interest enough so that it isn't a hassle for us anymore?
In other words, what is the downside of ignoring the standardization
issue? If there isn't one, why did Squires send his stooge to Paris to
prevent us from losing the edge?

I don't want the reason for us not going with ANSI and ISO to be:
Gee, I heard a horror story about something or other and I don't want
us involved with that; plus, we're too strong for anyone to make a
dent in our position. ...Unless we know the facts about what can happen
and how those events are unimportant or reparable.

About the hotel strike: My Boston operatives are looking into it
even now. The belief is that it will not affect us one way or the
other, but we will know later today or tomorrow.

			-rpg-

∂02-Dec-85  1135	FAHLMAN@C.CS.CMU.EDU 	ANSI/ISO and Hotel Strike        
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Dec 85  11:34:52 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 2 Dec 85 14:28:20-EST
Date: Mon, 2 Dec 1985  14:28 EST
Message-ID: <FAHLMAN.12163956376.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   rpg@SU-AI.ARPA
Cc:   quinquevirate@SU-AI.ARPA
Subject: ANSI/ISO and Hotel Strike    
In-reply-to: Msg of 2 Dec 1985  13:54-EST from Dick Gabriel <RPG at SU-AI.ARPA>


Some further thoughts on the ISO thing:

    I'm simply not sure whether or not having an ISO standard Lisp
    makes any difference, either in general or anymore. It seems
    we are at the crossroads as to whether Common Lisp remains the
    `property' of us (the CLG at large) or whether it is part of the
    world at large.

Maybe the question is whether Common Lisp remains the property of the
active Lisp community (largely in the U.S.) or whether it is taken over
by European fanatics who don't like Lisp anyway and who have nothing
better to do than to play political games with committees.

    There are two possible courses: Leave standardization alone, and
    go after it.

Leaving ISO and ANSI alone is not the same as leaving "standardization"
alone.  The IBM/PC is a standard, for example.  Official standardization
is just one kind of standardization, and is generally the weakest kind.

    If we ignored all standardization, that makes
    a statement against official standards and also tells the world
    we are above the normal hue and cry. Is that what we want?

Standards are fine for plugs, character codes, and floppy-disk formats.
I don't think that anything as large and complex (not to mention
political) as Common Lisp has ever been successfully standardized by an
official committee of this sort.  Big things get standardized by brute
force and a committee maybe blesses them later.  Indeed, Common Lisp is
already somewhat unique among huge systems in that the standard did not
come from one single company as a fait accompli, but was discussed by
many participants.  I think the ARPANET was a key ingedient in making
this possible, and that the ISO machinery is unsuitable.  Can you
imagine doing what we did if everyone had to fly off to face-to-face
meetings twice a year and to communicate by international airsnail at
other times?  Can you imagine the process going smoothly in the future
under those conditions, even now that we all agree on the lowest-level
stuff?

    Suppose we start down the ISO route and it gets bad, can't we simply
    drop it or lose interest enough so that it isn't a hassle for us anymore?
    In other words, what is the downside of ignoring the standardization
    issue?

I see two downsides: first, we've got work still to do in
standardizations and the last thing we need is to saddle ourselves with
a lot of extraneous bureaucratic restrictions on how this work will be
done; second, if the ISO process gets our participation and produces
something close to Common Lisp but not close enough to satisfy us, then
we've created confusion as to which is the "real" Common Lisp.  A
strictly French effort in which they do their own thing would not
confuse the issues in this way.  Getting ISO to approve Common Lisp
exactly as we define it is probably not possible (am I wrong about
this?), and a near miss is the worst possible outcome.

If someone wants to do all the work to capture the ISO process and
believes that we can either get true Common Lisp approved or walk out
cleanly, that's OK with me, but it's a big effort for dubious gain in my
opinion.

-- Scott

∂02-Dec-85  1153	RPG  	Exposing My Machiavellan Tendencies    
To:   quinquevirate@SU-AI.ARPA   

Suppose France gains control of the ISO process, and suppose they
do something that is the direct marriage of what they want and Common Lisp.
I think this is both the most likely outcome and the best outcome we
can expect. They want a subset - at least that's what Chailloux wants.

What we end up with as an ISO standard is a smallish subset of Common Lisp.
France does something in computer science, and they do build/distribute/sell
computers. So what does someone in Europe do to be `safe' when writing
Lisp code? He codes in the intersection, which happens to be the standard.

What does someone in the US do when he codes for US machines that are
used in Europe and when the code will be shipped there? He codes in the
intersection.

This creates confusion in a lot of peoples's minds. What I would like 
to propose is that we start down the ISO path, in order to block the
thrust of the French bid. Then we delay on the official front while
continuing on on the informal front as we have been. Eventually we can
make the right decision, or perhaps we can delay until it is clear no
decision is needed.

The idea is to shield our normal activities from the potential irritation
that a French ISO bid could cause.
			-rpg-

∂02-Dec-85  1209	FAHLMAN@C.CS.CMU.EDU 	Exposing My Machiavellan Tendencies        
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Dec 85  12:09:18 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 2 Dec 85 15:09:11-EST
Date: Mon, 2 Dec 1985  15:09 EST
Message-ID: <FAHLMAN.12163963846.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Dick Gabriel <RPG@SU-AI.ARPA>
Cc:   quinquevirate@SU-AI.ARPA
Subject: Exposing My Machiavellan Tendencies    
In-reply-to: Msg of 2 Dec 1985  14:53-EST from Dick Gabriel <RPG at SU-AI.ARPA>


OK, the best outcome would be to get ISO to agree to accept Common Lisp
is is and to track changes.  Not feasible.

The second best outcomes (a tie) are either to screw up the ISO process
so that nothing comes out of it, or to get the French to do something so
different from Common Lisp that nobody will injure himself by trying to
straddle the fence.

The bad case is that the ISO thing ends up looking very much like Common
Lisp, but that it is different enough (perhaps by being a subset) to
cause real trouble, confusion, and to split the Common Lisp market
because of that.

The worst possible case is that we cooperate a little bit with this, but
end up in the "bad case" anyway, because then it lends legitimacy to
this mutant offspring.

So we do have something to talk about: how do we prevent the bad case
without wasting a lot of everyone's valuable time and without falling
into the worst possible case.  But we can't talk about trying to stall
this process in public, so we have to pretend that if we participate at
all we are going for full acceptance of Common Lisp.  A tricky business.

-- Scott

∂02-Dec-85  1250	DLW@SCRC-QUABBIN.ARPA 	ANSI/ISO    
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 2 Dec 85  12:50:27 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 224838; Mon 2-Dec-85 15:46:53-EST
Date: Mon, 2 Dec 85 15:54 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: ANSI/ISO 
To: Fahlman@C.CS.CMU.EDU, quinquevirate@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12163920553.BABYL@C.CS.CMU.EDU>
Message-ID: <851202155411.1.DLW@CHICOPEE.SCRC.Symbolics.COM>

I agree with what you say about ISO.  We should spend at least a little
time at the meeting, though, finding out just what is the worst that
would happen if ISO goes its own way.  In other words, we should get
answers to the questions you asked in your mail.

∂02-Dec-85  1622	DLW@SCRC-STONY-BROOK.ARPA 	ANSI/ISO
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 Dec 85  16:22:26 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 365743; Mon 2-Dec-85 18:36:33-EST
Date: Mon, 2 Dec 85 18:43 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: ANSI/ISO
To: quinquevirate@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12163956376.BABYL@C.CS.CMU.EDU>
Message-ID: <851202184313.6.DLW@CHICOPEE.SCRC.Symbolics.COM>

Hmm.  I sympathize with all the points I've heard.  It's a hard
question.

Let me toss in one more anti-official-standards point:  because there
are so many standards organizations running around, we have to worry
about whether there might be an ISO standard, an ANSI standard, an IEEE
standard, a CCITT standard, and so on.  The network protocol world is
the canonical example of this problem.  The latest things I've been
hearing about is a new protocol that's basically a lot like IP/TCP, but
incompatible, called MAP, which is a General Motors standard (no
kidding) that has become popular in the factory-automation world.  The
world of networking also has HDLC, SDLC, and LAPB, which are nearly
identical, but not quite, and sponsored by different organizations, one
of which is IBM.

In light of this, I am particularly worried by Scott's poing that we
might end up with "original CL" and "ISO CL", which are pretty close but
not quite the same.

I am tempted to add "not the same, because some random French LeLisp
people wanted to have some say in the standard, so they changed the
order of arguments to some functions randomly just so that they could
feel that they were among the creators of the standard."  Everyone wants
to be one of the creators of the standard.  For example, T.I. has been
broadly advertising that they were heavily involved in the design of
Common Lisp.  I hate the idea of opening it up again just so that more
people can wear "I created Common Lisp" buttons.

There's no point in having a language standard if it is in a continual
state of redesign.  While I don't know any particular horror stories, I
do know that these things typically take significant amount of time,
like several years, before they come out with standards.  I'd hate to
have to say "wait, world, there isn't actually any Common Lisp standard
yet, wait for the ISO committee."  This is a fast-moving field; we
really cannot wait that long.

Now, in the past, we've mentioned having a "Common Lisp 89" or whatever,
a second generation language standard to come out in several years.
Perhaps if we (or the new charter group) still believe that, we should
consider dealing with ISO and/or ANSI.

I understand Steele has been involved in the ANSI C committee; perhaps
he could comment on all this in light of his experience.

∂02-Dec-85  1738	Moon@SCRC-STONY-BROOK.ARPA 	Hotel Strike
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 Dec 85  17:38:18 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 365784; Mon 2-Dec-85 19:33:12-EST
Date: Mon, 2 Dec 85 19:32 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Hotel Strike
To: Dick Gabriel <RPG@SU-AI.ARPA>
cc: quinquevirate@SU-AI.ARPA
In-Reply-To: The message of 2 Dec 85 13:54-EST from Dick Gabriel <RPG@SU-AI.ARPA>
Message-ID: <851202193211.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 02 Dec 85  1054 PST
    From: Dick Gabriel <RPG@SU-AI.ARPA>

    About the hotel strike: My Boston operatives are looking into it
    even now. The belief is that it will not affect us one way or the
    other, but we will know later today or tomorrow.

It was settled yesterday.  The union members vote on it later this week,
and it is predicted that they will approve the agreement that the union
leaders and management agreed to, but I suppose you could always worry
that they won't.

∂02-Dec-85  2037	FAHLMAN@C.CS.CMU.EDU 	Charter stuff
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Dec 85  20:37:21 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 2 Dec 85 23:37:16-EST
Date: Mon, 2 Dec 1985  23:37 EST
Message-ID: <FAHLMAN.12164056344.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   quinquevirate@SU-AI.ARPA
Cc:   fahlman@C.CS.CMU.EDU
Subject: Charter stuff


In his recent mail, Dick Gabriel suggested that there are three
proposals we might want to discuss: the "full-blown" proposal, the
"minimalist" proposal, and the "club" proposal.  I see the issues a bit
differently, I guess.  Basically, I see three almost orthogonal issues
and one big problem.

Issue 1: Do we want an organization to do only what is absolutely
necessary, or do we want it to provide a range of services to the
community?

This is the difference between the "full blown" and "minimalist"
proposals.  A minimal organization would basically just provide a
technical committee, some way of electing the committee, a communication
channel for questions, discussion, and decisions, a legal entity that
can own those things that belong to "the Common Lisp community".  The
other services that a "full blown" organization might provide would
include keeping the archives in some sort of order, maintaining and
distributing a public-domain library including such things as the Spice
Lisp and Hemlock sources, perhaps a newsletter, communication by mail to
those not on electronic networks, maintaining and distributing a
validation suite, maybe running the actual validations, and so on.

To provide these services would require a full-time employee or two and
would cost maybe $150K/year if done within some existing organization
(sharing office space and some other facilities).  In the past, CMU has
done some of this stuff, others have done some, and some important
things have just not been done.  I'm pretty sick of dealing with this
stuff at CMU without adequate administrative support, so if nothing else
is set up, things are soon going to get much worse -- no more tapes sent
to people, etc.  If the Common Lisp association does these things, we
will have to raise big bucks either through corporate dues or grants.
At one point the DARPA folks suggested that they would give a contract
to ISI to do these things, but nothing seems to be happening on that
front and ISI doesn't seem to have much enthusiasm for the task.  Maybe
this idea can be resurrected; if so, I think a minimalist organization
is preferable to a heavy one.

Issue 2: Who decides who is to decide?

We probably want a rather small technical committee that would operate
by discussing issues with the community at large (that part of it
reachable by netmail, anyway) but that would then be able to make
decisions about the language without having to get 100% consensus.
Everyone could discuss (cajole, threaten, whatever) but only a few
people would actually make the decisions.  The question is how we elect
a technical committee.

The obvious move is to let anyone join the organization as an individual
member who wants to pay the dues (not too much, maybe $20/year), and to
let these individual members elect the technical committee -- one
member, one vote.  The big problem here is to ensure that this
democratic process is not subverted (e.g. by some company packing the
membership by signing up all their employees) and that an influx of
people from some odd corner of the community does not carry Common Lisp
off in directions that the original community and the major
manufacturers do not want to see it go in.  I can imagine an invasion of
hobbyist types, for example, who might decide that the most important
thing is to be sure that Common Lisp fits easily into 640K of memory.
Such people should have a voice, but it is not clear that every random
hobbyist who has paid his $20 should have as large a voice as someone
who is using Lisp in a serious professional way.

So the real question is, if we go with a democratically elected
technical committee, whether we need some extra machinery to keep
the language true to its original goals.  Some possible responses:

A. This might once have been a problem, when major groups were trying to
bend Common Lisp to be closer to their old Lisps, but is no longer an
issue.

B. The technical committee should be elected, but the manufacturers and
other corporations should have a veto power of some sort.  This was the
genesis of my earlier proposal that we have corporate members (filtered
by their willingness to pay big dues) and that 2/3 or 3/4 of these
corporate members are sufficent to veto actions by the technical
committee.  The very existence of this veto would make it useless for
any one company to try to pack the membership and take over the
technical committee.

C. We could try to write into the organization's constitution all of
those things that we never want anyone to change.  This has always
struck me as infeasible.

D. We could pick a few well-known people who have been involved in the
Common Lisp effort from the start and make them a sort of "supreme
court".  For the first few years of the organization's existence, these
people (by a 2/3 vote or something like that) would have the right to
veto any changes that they view as contrary to the original goals and
ongoing well-being of the language.  There is a problem of how to
get this set up -- if the initial supreme court is elected
democratically, all of the same potential problems come up here as with
the technical committee.  See below for one possible solution.

Issue 3:  How do we bootstrap such an organization?

I think that we are going to have a hell of a time getting consensus on
any detailed plan for an organization at the Boston meeting or via the
network.  In a group that large and diverse, there will always be
somebody who wants to quibble at length about something.  And if we
don't have either a consensus or a pre-existing constitution, how do we
settle these issues?  Who gets to vote?  Who has a veto?  The Boston
meeting will not fairly represent the community as a whole because of
geography -- the local companies will have many more people there.

One thought I have had (RPG calls it the "club" proposal, but I think
that this is bad PR), is that a few of us get together and form an
organization ourselves.  We would do our best to come up with a plan
that the community will approve of, and we can ask individuals or the
whole community for advice, but in the end we make the decisions.  "We"
in this case is the five of us, plus any others we decide to invite into
the process at this stage.  We elect an initial set of officers and a
technical committee.  Guy would agree that future editions of his book
would reflect Common Lisp as defined by this organization.  Then, once
this is all in place, we open up membership to anyone who wants to join.

Now, this organization has no power or authority at the start, except
what it derives from the "big names" who are associated with.  But if a
lot of companies join and announce that they intend to follow this
organization's definition of Common Lisp, then it quickly becomes the de
facto setter of standards.  If anyone doesn't like some detail of the
way we set up the organization, they can stay out and pout, but they
can't induce paralysis.

What gives us the right to go off and set this up the wy we want to?
Well, everyone has the same right, but our attempt to do this might
stick because of our stature in the Common Lisp community.  And this is
not so unusual; most new organizations start this way, with a small
nucleus of people who decide to set something up.  As I understand it,
AAAI came about when a few of the major people in the field of AI
decided that there ought to be a national AI organization and just went
off and created it.  By the time most of us heard about this
orgainzation, it was a fait accompli, with a constitution and a set of
officers already in place.

Anyway, this is something to think about.  I don't see any good
alternative.  We don't have to be sneaky about this.  We can ask the
people at the meeting what they think about this, which is not the same
as asking their permission.

This is orthogonal to the heavy/lightweight issue, except that we
obviously couldn't offer many services until we have some money coming
in.  It is also orthogonal to the issue of whether we need to build in
some sort of stabilization mechanism, except that it gives us an easy
way to create a "supreme court" effect if we want to.  The idea is that
we would elect an initial technical committee before we open up
membership to the world at large, and we install a trustworthy set of
people for fairly long terms.  The new membership could elect new people
as vacancies open up, but even in the worst case it would take several
years before new people would outnumber our initial handpicked group.
Probably this is all the stability we need.

MAJOR PROBLEM: how can we protect the people prominently involved in
this organization from harassment by lawyers.

Sooner or later, some decision is going to go against some company that
likes to use the legal system as a weapon.  Or maybe some group on the
outside decides to try to destroy Common Lisp by suing the organization
and the visible people in it.  Even if the lawsuit is totally without
merit, a large company can destroy a random private citizen by forcing
him to spend a fortune on legal fees.  Unless the organization has both
the commitment and the resources to protect the people involved from
lawsuits, I for one am not going to expose myself to that kind of risk.
(CMU has some sort of indemnification policy for its faculty, but it is
vague and probably worthless.  I don't think it would cover something
this far from my "usual" duties.)  Even to get some lawyer to explain to
us what the risks and possible defenses really are would cost quite a
bit.  I'm not sure how big a war chest would be adequate, or whather
there is some way to insure against this kind of threat, or whether some
company or other organization would be able to shield us while we set up
some sort of organization.

Anyway, this has to be dealt with BEFORE we do anything else, and
especially before we try to start an organization by ourselves as
individuals.  I don't know what to do about this.  Ever since Beau Sheil
and Xerox started making legal threats last year I've been really afraid
of this.  I've got no access to lawyers to discuss this problem unless I
spend my own money, which I'm not eager to do.  It's a shame that this
kind of nonsense has to enter into our considerations, but that's the
way it is.  Ideas?

-- Scott

∂03-Dec-85  1706	hplabs!snyder@hplabsd 	manual bug (index)    
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 3 Dec 85  17:06:28 PST
Received: by hplabsd ; Tue, 3 Dec 85 17:04:55 pst
Date: Tuesday, December 3, 1985  16:54:15
From: snyder@hplabsd
Subject: manual bug (index)
To: common-lisp@su-ai
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46

In case it's not been noticed before,
the function KEYWORDP appears in the index as KEYWORD.
-------

∂03-Dec-85  1719	hplabs!snyder@hplabsd 	keywords    
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 3 Dec 85  17:19:01 PST
Received: by hplabsd ; Tue, 3 Dec 85 17:17:25 pst
Date: Tuesday, December 3, 1985  17:07:20
From: snyder@hplabsd
Subject: keywords
To: common-lisp@su-ai
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46

Is it legal to use a keyword as the name of a function?

Does a keyword have a property list?

I have always assumed the answer to these questions is "no", but I cannot find
any clear statement to this effect in the manual.  The only related statement
I could find is on page 175, and is somewhat vague:

"... name conflicts are not an issue because these
symbols are used only as labels and never to carry package-specific
values or properties."

Opinions?

  Alan Snyder
-------

∂03-Dec-85  1954	FAHLMAN@C.CS.CMU.EDU 	keywords
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 3 Dec 85  19:54:14 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 3 Dec 85 22:53:58-EST
Date: Tue, 3 Dec 1985  22:53 EST
Message-ID: <FAHLMAN.12164310601.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   snyder@HPLABS.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: keywords
In-reply-to: Msg of 3 Dec 1985  17:07-EST from snyder at hplabsd


It is certainly terrible style to use a keyword as the name of a
function or to give it any properties.  The book doesn't seem to say
whether "it is an error" to do either of these things.  I think it
should be an error.  On the other hand, I don't know of any Common Lisp
that goes to the trouble of signaling such an error or that special
cases keyword symbols in such a way as to eliminate the function and
property-list cells.

-- Scott

∂03-Dec-85  2030	RPG  	More on Issues
To:   quinquevirate@SU-AI.ARPA   
Scott has raised what I consider the most important issues. From what
I understand, if the `club' is a corporation (of a certain type?), then
the corporation can be sued, but not the individuals. This way
Xerox can destroy the club, but not us.

Would Xerox (for example) want to destroy us? I doubt it. Suppose
we form no organizationat all; suppose Lucid stays friends
with Symbolics. Then Lucid and Symbolics can decide to proceed with
Common Lisp as we and they see fit. With even this coalition, people have
to follow or be out of the game. If we add DEC to the coalition, all
doubt about the efficacy of this plan disappear. 

The point is that Common Lisp is almost as much of a defacto standard
as could be expected under any situation - witness: Xerox and Fateman
(Franz) have caved in. Given that, if some corporation or private individual
brought a suit, it would simply smear the corporation's image.

The situation was different before everyone recognized Common Lisp as
*the* Lisp. Before that, we could have been sued for trying to establish
a standard. Now anyone who tried to `break' the standard would be
in a bad situation.

So, maybe the right thing to do is nothing, except to pretend that there
is a Common Lisp Group that is making decisions somewhere. 
			-rpg-

∂04-Dec-85  0120	TIM@MIT-MC.ARPA 	The variables +, -, *, and /
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Dec 85  01:19:57 PST
Date: Wed,  4 Dec 85 04:22:30 EST
From: Tim McNerney <TIM@MIT-MC.ARPA>
Subject:  The variables +, -, *, and /
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].740954.851204.TIM>

It seems unfortunate that the variables +, -, *, and / were reserved for use
by the Top-Level Loop.  This choice of names makes it difficult to build the
run-time environment for Scheme-like language that compiles into Common Lisp
and that supports the illusion that there are no separate function and value
cells.  If these variables had not been reserved, one could

    (DEFCONSTANT + #'+)
    (DEFCONSTANT * #'*)
    etc...

so that

    ((IF SUM? + *) X Y) 

could be simply compiled into

    (FUNCALL (IF SUM? + *) X Y)

Sigh...

∂04-Dec-85  0301	wagner%fang@gswd-vms 	minor index errors
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 4 Dec 85  03:01:13 PST
Received: from fang.GSD (fang.ARPA) by gswd-vms.ARPA (5.9/5.6)
	id AA00873; Wed, 4 Dec 85 09:15:19 CST
Message-Id: <8512041515.AA00873@gswd-vms.ARPA>
Date: Wed, 4 Dec 85 09:04:51 cst
From: wagner%fang@gswd-vms (Fran Wagner)
To: common-lisp@su-ai.arpa
Subject: minor index errors
Cc: wagner%fang@gswd-vms


These may be known, but in CLtL index:

Entry for MULTIPLE-VALUES-LIMIT is 1325, should be 135.
Main entry for THE is 162-163, should be 161-162.

∂04-Dec-85  0310	smh@mit-ems.ARPA 	Re:  The variables +, -, *, and /    
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 4 Dec 85  03:09:24 PST
Received: by mit-ems.ARPA (4.12/4.8)  id AA11143; Wed, 4 Dec 85 07:43:55 est
Date: Wed, 4 Dec 85 07:43:55 est
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8512041243.AA11143@mit-ems.ARPA>
To: TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
Subject: Re:  The variables +, -, *, and /

> From: Tim McNerney <TIM@MIT-MC.ARPA>
> Subject:  The variables +, -, *, and /
> 
> It seems unfortunate that the variables +, -, *, and / were reserved
> for use by the Top-Level Loop.  This choice of names makes it difficult
> to build the run-time environment for Scheme-like language that
> compiles into Common Lisp and that supports the illusion that there are
> no separate function and value cells.  If these variables had not been
> reserved, one could
> 
>     (DEFCONSTANT + #'+)
>     (DEFCONSTANT * #'*)
>     etc...
> 
> so that
> 
>     ((IF SUM? + *) X Y) 
> 
> could be simply compiled into
> 
>     (FUNCALL (IF SUM? + *) X Y)

Perhaps these symbols aren't the real problem:  CL compilers tend to
have built-in knowledge about certain special forms that a user can't
easily modify.  So if you're really scheming up a language with
different semantics for the functional position of a form, you'll
probably have to write new top-level loops for both compiler and
interpreter which preprocess all top-level forms appropriately.  Your
top-level interpreter loop would probably have a reentrant top-level
unwind-protect so the user doesn't ever fall out into the CL one, even
during error recovery.  Thus, the CLtL top-level loop won't be around
to mess with +, ++, etc.

∂04-Dec-85  0312	BSG@SCRC-STONY-BROOK.ARPA 	keywords
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Dec 85  03:12:23 PST
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 366846; Wed 4-Dec-85 09:14:05-EST
Date: Wed, 4 Dec 85 09:25 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: keywords
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12164310601.BABYL@C.CS.CMU.EDU>
Message-ID: <851204092534.6.BSG@CONCORD.SCRC.Symbolics.COM>

    Date: Tue, 3 Dec 1985  22:53 EST
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>


    It is certainly terrible style to use a keyword as the name of a
    function or to give it any properties.  The book doesn't seem to say
    whether "it is an error" to do either of these things.  I think it
    should be an error.  On the other hand, I don't know of any Common Lisp
    that goes to the trouble of signaling such an error or that special
    cases keyword symbols in such a way as to eliminate the function and
    property-list cells.

    -- Scott

Symbolics Common Lisp relies heavily on the property lists of keywords.
Given that a keyword is "an indicator that means X in context Y",
it is right reasonable that context Y might want to hang properties off 
of it to implement that.

∂04-Dec-85  0806	FAHLMAN@C.CS.CMU.EDU 	keywords
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 4 Dec 85  08:03:23 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 4 Dec 85 10:57:03-EST
Date: Wed, 4 Dec 1985  10:56 EST
Message-ID: <FAHLMAN.12164442247.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   "Bernard S. Greenberg" <BSG@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: keywords
In-reply-to: Msg of 4 Dec 1985  09:25-EST from Bernard S. Greenberg <BSG at SCRC-STONY-BROOK.ARPA>


    Symbolics Common Lisp relies heavily on the property lists of keywords.
    Given that a keyword is "an indicator that means X in context Y",
    it is right reasonable that context Y might want to hang properties off 
    of it to implement that.

OK, I guess I accept that this is not so terrible a thing to do.  If the
property names are package-specific, it shouldn't bother them that they
are sharing the same package-neutral keyword, since the different uses
still have a way of staying out of each other's way.  It strikes me as a
bit unclean, but maybe that's just that I like the abstraction of a
keyword as a pure token.

I would still be inclinded to holler at anyone naming a function :FOO,
however.

-- Scott

∂04-Dec-85  0814	FAHLMAN@C.CS.CMU.EDU 	The variables +, -, *, and /
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 4 Dec 85  08:13:58 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 4 Dec 85 11:13:37-EST
Date: Wed, 4 Dec 1985  11:13 EST
Message-ID: <FAHLMAN.12164445251.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Tim McNerney <TIM@MIT-MC.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: The variables +, -, *, and /
In-reply-to: Msg of 4 Dec 1985  04:22-EST from Tim McNerney <TIM at MIT-MC.ARPA>


We thought brielfly about such issues and decided that we would quickly go mad
if we tried to avoid stepping on symbols (or ways of using them) for
every other Lisp-like language.  That's why there are packages.  The
Common Lisp top-level will not mess around with the value of SCHEME:*,
etc.  Customize the scheme symbols any way you want, and import from
the LISP package those things that happen to be right.

-- Scott

∂04-Dec-85  0833	FAHLMAN@C.CS.CMU.EDU 	More on Issues    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 4 Dec 85  08:32:57 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 4 Dec 85 11:32:13-EST
Date: Wed, 4 Dec 1985  11:32 EST
Message-ID: <FAHLMAN.12164448639.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   quinquevirate@SU-AI.ARPA
Subject: More on Issues
In-reply-to: Msg of 3 Dec 1985  23:30-EST from Dick Gabriel <RPG at SU-AI.ARPA>


First, let me say that I don't think that Xerox is the most likely
source of legal problems any more.  I mentioned their name only because
they were the ones who brought the whole issue up with their
pre-Monterey threats.  When the legal shit hits the fan, it will
probably come from some completely unforseen quarter.

I would be very pleased if Dick's view of incorporation protecting us
all were the case.  Maybe it is -- without having a long (expensive)
talk with a lawyer, I don't know.  My suspicion is that the individuals
could also be sued, as individuals.  It would be hard for the assailant
to win that suit, but there is just enough precedent that it wouldn't be
considered totally groundless.  And that means that there would be large
legal fees incurred by the individuals, and a strong incentive to
settle.  Big corporations solve this by creating policies that if
individuals get sued as a result of their activity on behalf of the
corporation, the corporation defends the case and pays any judgement.
There also are various kinds of liability insurance covering corproate
officers.  But for any of this to be credible protection, the
corporation has to have enough resources to be an effective shield.

Maybe our "home" corporations (Lucid, Symbolics, CMU,...) would cover
each of us, but that's not the usual pattern if you go off and do
something on the side, so we'd better get firm assurances to that
effect.  As I said, CMU's policy on this is vague and does not inspire
me to stick my neck out.

Maybe I'm wrong about about all this.  We've got to find out.

I think that the "club" model, in which there is a formal decision
mechanism (wherever it came from) to which various groups can pledge
their allegiance, is very different from the sort of informal situation
Dick describes (which is what we have now).  With nobody really knowing
what the rules are, we either do not make any progress on controversial
things or we open things up for raw power politics -- whoever decides to
be the nastiest wins the decision.  I have found the last year to be
extremely uncomfortable, so I am not enthusiastic about the "do nothing"
suggestion, though I guess that is another alternative that we might
want to discuss.

-- Scott

∂04-Dec-85  0837	@MIT-MC.ARPA:Soley@MIT-MC.ARPA 	The variables +, -, *, and /
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Dec 85  08:37:45 PST
Received: from MIT-CHERRY.ARPA by MIT-MC.ARPA via Chaosnet; 4 DEC 85  11:37:15 EST
Date: Wed, 4 Dec 85 11:34 EST
From: Soley@MIT-MC.ARPA
Subject: The variables +, -, *, and /
To: TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <[MIT-MC.ARPA].740954.851204.TIM>
Message-ID: <851204113446.4.SOLEY@MIT-CHERRY.ARPA>

    Received: from SU-AI.ARPA by MIT-MC.ARPA  4 Dec 85 04:32:20 EST
    Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Dec 85  01:19:57 PST
    Date: Wed,  4 Dec 85 04:22:30 EST
    From: Tim McNerney <TIM@MIT-MC.ARPA>
    Subject:  The variables +, -, *, and /
    To: common-lisp@SU-AI.ARPA
    Message-ID: <[MIT-MC.ARPA].740954.851204.TIM>

    It seems unfortunate that the variables +, -, *, and / were reserved for use
    by the Top-Level Loop.  This choice of names makes it difficult to build the
    run-time environment for Scheme-like language that compiles into Common Lisp
    and that supports the illusion that there are no separate function and value
    cells.  If these variables had not been reserved, one could

	(DEFCONSTANT + #'+)
	(DEFCONSTANT * #'*)
	etc...

    so that

	((IF SUM? + *) X Y) 

    could be simply compiled into

	(FUNCALL (IF SUM? + *) X Y)

Why not create a package SCHEME that doesn't import any symbols or use
any other package, and do what you like in that package, i.e.,

	(LISP:DEFCONSTANT + #'LISP:+)

and build your own world?  This is not unlike the Symbolics solution to
Common Lisp vs. Zetalisp on the 3600 -- two different worlds rooted at
different packages ("GLOBAL" and "SYMBOLICS-COMMON-LISP").

	-- Richard

∂04-Dec-85  0844	AS@HP-HULK 	Re: keywords 
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 4 Dec 85  08:43:13 PST
Received: from HP-HULK by hplabsd ; Wed, 4 Dec 85 08:41:11 pst
Date: Wed 4 Dec 85 08:42:23-PST
From: Alan Snyder <AS@HP-HULK>
Subject: Re: keywords
To: BSG%scrc-stony-brook.arpa@CSNET-RELAY.ARPA
Cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message from ""Bernard S. Greenberg" <BSG%scrc-stony-brook.arpa@CSNET-RELAY>" of Wed 4 Dec 85 07:56:31-PST

  Symbolics Common Lisp relies heavily on the property lists of keywords.
  Given that a keyword is "an indicator that means X in context Y",
  it is right reasonable that context Y might want to hang properties off 
  of it to implement that.

An alternative is to use the keyword as the indicator on a property
list attached to Y, which avoids the potential conflicts in using
a global database (a propertly list attached to a keyword).
It is inevitable that keywords will be interpreted differently
in different contexts.  What you want to avoid is conflicts
that would prevent the different contexts from coexisting.

P.S.

Can a keyword be used as the name of a type?

Can a keyword be used as the name of a block?

Can a keyword be used as a tag?

-------

∂04-Dec-85  1006	KMP@SCRC-STONY-BROOK.ARPA 	The variables +, -, *, and /
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Dec 85  10:05:26 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 367089; Wed 4-Dec-85 13:02:25-EST
Date: Wed, 4 Dec 85 13:05 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: The variables +, -, *, and /
To: TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <[MIT-MC.ARPA].740954.851204.TIM>
Message-ID: <851204130539.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Wed,  4 Dec 85 04:22:30 EST
    From: Tim McNerney <TIM@MIT-MC.ARPA>

    It seems unfortunate that the variables +, -, *, and / were reserved for use
    by the Top-Level Loop.  This choice of names makes it difficult to build the
    run-time environment for Scheme-like language that compiles into Common Lisp
    and that supports the illusion that there are no separate function and value
    cells.  If these variables had not been reserved, one could

	(DEFCONSTANT + #'+)
	(DEFCONSTANT * #'*)
	etc...

    so that

	((IF SUM? + *) X Y) 

    could be simply compiled into

	(FUNCALL (IF SUM? + *) X Y)

    Sigh...

The good Scheme dialects all do modules via closure hacks, rather than via
read-time hacks like packages. As such, there's no reason you can't build a
Scheme package which shadows those symbols and which all Scheme users share.
Talk to Jonathan Rees -- I think he's done just that with a Scheme hack he
wrote to run in CL.

∂04-Dec-85  1019	BSG@SCRC-STONY-BROOK.ARPA 	Re: keywords 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Dec 85  10:19:27 PST
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 367107; Wed 4-Dec-85 13:16:30-EST
Date: Wed, 4 Dec 85 13:28 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Re: keywords
To: AS%HP-HULK@CSNET-RELAY.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 4 Dec 85 11:42-EST from Alan Snyder <AS@HP-HULK>
Message-ID: <851204132801.3.BSG@CONCORD.SCRC.Symbolics.COM>

    Date: Wed 4 Dec 85 08:42:23-PST
    From: Alan Snyder <AS@HP-HULK>

      Symbolics Common Lisp relies heavily on the property lists of keywords.
      Given that a keyword is "an indicator that means X in context Y",
      it is right reasonable that context Y might want to hang properties off 
      of it to implement that.

    An alternative is to use the keyword as the indicator on a property
    list attached to Y, which avoids the potential conflicts in using
    a global database (a propertly list attached to a keyword).
When propertly implemented [sorry], you use packages to isolate these
things.  The issue is no different than with any other symbol.
    It is inevitable that keywords will be interpreted differently
    in different contexts.  What you want to avoid is conflicts
    that would prevent the different contexts from coexisting.
That's why you use property lists.

∂04-Dec-85  1109	BSG@SCRC-STONY-BROOK.ARPA 	Re: keywords 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Dec 85  10:19:27 PST
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 367107; Wed 4-Dec-85 13:16:30-EST
Date: Wed, 4 Dec 85 13:28 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Re: keywords
To: AS%HP-HULK@CSNET-RELAY.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 4 Dec 85 11:42-EST from Alan Snyder <AS@HP-HULK>
Message-ID: <851204132801.3.BSG@CONCORD.SCRC.Symbolics.COM>

    Date: Wed 4 Dec 85 08:42:23-PST
    From: Alan Snyder <AS@HP-HULK>

      Symbolics Common Lisp relies heavily on the property lists of keywords.
      Given that a keyword is "an indicator that means X in context Y",
      it is right reasonable that context Y might want to hang properties off 
      of it to implement that.

    An alternative is to use the keyword as the indicator on a property
    list attached to Y, which avoids the potential conflicts in using
    a global database (a propertly list attached to a keyword).
When propertly implemented [sorry], you use packages to isolate these
things.  The issue is no different than with any other symbol.
    It is inevitable that keywords will be interpreted differently
    in different contexts.  What you want to avoid is conflicts
    that would prevent the different contexts from coexisting.
That's why you use property lists.

∂04-Dec-85  1344	MLY@MIT-MC.ARPA 	keywords
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Dec 85  13:44:21 PST
Date: Wed,  4 Dec 85 16:46:53 EST
From: Richard Mlynarik <MLY@MIT-MC.ARPA>
Subject: keywords
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].741648.851204.MLY>

That's why you use hashtables

∂05-Dec-85  0023	REM%IMSSS.#Pup@SU-SCORE.ARPA 	Bad to hang properties off keywords to install their semantics   
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Dec 85  00:23:09 PST
Received: from IMSSS by Score with Pup; Thu 5 Dec 85 00:20:13-PST
Date:  5 Dec 1985 0020-PST
From: Rem@IMSSS
Subject: Bad to hang properties off keywords to install their semantics
To:   COMMON-LISP%SU-AI@SCORE
cc:   BSG%SCRC-STONY-BROOK.ARPA@SCORE

I don't think it's a good idea to implement keyword usage (semantics) by
having each function that uses that keyword to hang a property off that
keyword. The reason is you can have hundreds of different uses for a single
keyword (for example :REVERSE to do some operation backwards from default,
:IP to do something in place, :FAST to make it run fast, etc.), so then
it takes a long time each time you use that keyword for the function to
scan down the keyword's property list looking for the one item that
tells this particular function what to do while ignoring all the other
properties that are used by other functions. Better to hang the keyword
as a property-tag off the property list of the function, that way the
search is for the various keywords used by one function rather than the
various functions that use one keyword and thus the search length is
under the control of whoever wrote that function rather than being the
total search length by however many packages may be loaded.

As an alternative to using the property list of either the keyword
or the funcion, you could use the value cell of that keyword or function
pointing to a hash table, although in the case of keywod.value-->hashtable
you have to a general concensus.

One other problem with hanging anything at all of a shared thing such as
a keyword property-list cell, is that if you have interrupts you have
to carefully interlock all updates. If you hang things off the function
name instead, you only have to interlock against other processes in
the same package, which may be a lot more managable.

In my opinion, it's totally painful to have either value or function
cells hanging off a keyword, except in the case where there is some
global agreement about that that cell will hold (such as a hashtable),
and it's workable but rather inefficient to put properties on the keyword.
-------

∂05-Dec-85  0118	@SU-SCORE.ARPA:DOUG@SU-CSLI.ARPA 	Bad to hang properties off keywords to install their semantics    
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Dec 85  01:18:01 PST
Received: from SU-CSLI.ARPA by SU-SCORE.ARPA with TCP; Thu 5 Dec 85 01:15:03-PST
Date: 5 Dec 1985  01:17 PST (Thu)
Message-ID: <DOUG.12164631704.BABYL@SU-CSLI.ARPA>
From: Doug Cutting <DOUG@SU-CSLI.ARPA>
To:   Rem@IMSSS
Cc:   BSG%SCRC-STONY-BROOK.ARPA@SCORE, COMMON-LISP%SU-AI@SCORE,
      Doug@SU-CSLI.ARPA
Subject: Bad to hang properties off keywords to install their semantics
In-reply-to: Msg of 5 Dec 1985  00:20-PST from Rem at IMSSS

    Date: Thursday, 5 December 1985  00:20-PST
    From: Rem at IMSSS

			[...] it takes a long time each time you use that
    keyword for the function to scan down the keyword's property list
    looking for the one item that tells this particular function what to
    do while ignoring all the other properties that are used by other
    functions. [...]

This seems like an implementation issue and has little to do with
what the language standard should be.

∂05-Dec-85  0135	REM@IMSSS 	Implementation issue? (re proplist on keyword)   
X-Sent: to SU-AI.ARPA by IMSSS.FRONSTAD.EDU via ETHERNET with PUPFTP; 1985-Dec-05 01:33:56 PST (=GMT-8hr)
X-Mailer: EMACS -> PSL (FORMAT+SEND-ALL) -> PUPFTP
Date: 1985 December 05 01:33:25 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132504103204.G0353
From: Robert Elton Maas <REM@IMSSS.STANFORD.EDU>
To:DOUG@SU-CSLI.ARPA
CC:COMMON-LISP@SAIL.STANFORD.EDU
subject:Implementation issue? (re proplist on keyword)
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up)

| Date: 5 Dec 1985  01:17 PST (Thu)
| From: Doug Cutting <DOUG@SU-CSLI.ARPA>
| Subject: Bad to hang properties off keywords to install their semantics
|     Date: Thursday, 5 December 1985  00:20-PST
|     From: Rem at IMSSS
| 			[...] it takes a long time each time you use that
|     keyword for the function to scan down the keyword's property list
|     looking for the one item that tells this particular function what to
|     do while ignoring all the other properties that are used by other
|     functions. [...]
| This seems like an implementation issue and has little to do with
| what the language standard should be.
Common LISP has already gotten into the implementation mess here by
insisting adamently that a property list MUST be an alternating list
rather than an ASSOC list or a hashtable etc. Since we've forced the
implementor to make it a linear list of a given format, we ought not
to then encourage LUSER programmers to mis-use it by hanging one
property per function off this one poor daisy-chain
(linear-liked-list) so that the ensemble of such additions in a large
system makes simple functions run very slow searching down that list.

∂05-Dec-85  0638	@SU-SCORE.ARPA:BSG@SCRC-YUKON.ARPA 	Bad to hang properties off keywords to install their semantics  
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Dec 85  06:38:27 PST
Received: from SCRC-YUKON.ARPA by SU-SCORE.ARPA with TCP; Thu 5 Dec 85 06:13:54-PST
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 176322; Thu 5-Dec-85 09:14:32-EST
Date: Thu, 5 Dec 85 09:19 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: Bad to hang properties off keywords to install their semantics
To: Rem@IMSSS, COMMON-LISP%SU-AI@SU-SCORE.ARPA
In-Reply-To: The message of 5 Dec 85 03:20-EST from Rem@IMSSS
Message-ID: <851205091935.9.BSG@CONCORD.SCRC.Symbolics.COM>

    Date:  5 Dec 1985 0020-PST
    From: Rem@IMSSS

    I don't think it's a good idea to implement keyword usage (semantics) by
    having each function that uses that keyword to hang a property off that
    keyword. The reason is you can have hundreds of different uses for a single
    keyword.

I don't see how that's different than the case with any symbol, except that
there is greater likelihood that there will be more code that knows about it.
What about "t"?  Or "print"?  Is it a good idea to put properties on them?

One of the profound features of Lisp is the set of services done
magically by the reader, most specifically, interning, done before the
program is even run.   That you do not have to look up names in symbol
tables, in the course of your program, as in other languages, but can go
"directly" to a referenced symbol and inspect its properties:  this is a
major linguistic feature.  You pay for this somewhere; Property lists
assume you have many more symbols than things you might want to say
about any of them.  When that is not so, you pay.   That is the tradeoff
of using property lists at all.   Saying "hey, for keywords, there is
some chance you'll really have to start paying", is OK, but putting the
blame for the problem anywhere but with the basic idea of property lists
(or, as has been noted, the requirement of cons-pair implementation) is
false.

∂05-Dec-85  0841	AS@HP-HULK 	Keywords with cells    
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 5 Dec 85  08:40:38 PST
Received: from HP-HULK by hplabsd ; Thu, 5 Dec 85 08:38:45 pst
Return-Path: <REM%IMSSS.#Pup@SU-SCORE.ARPA>
Received: from hplabsd by HP-HULK with TCP; Wed 4 Dec 85 23:58:18-PST
Received: from SU-SCORE.ARPA by hplabsd ; Wed, 4 Dec 85 23:56:39 pst
Received: from IMSSS by Score with Pup; Wed 4 Dec 85 23:55:12-PST
Date:  4 Dec 1985 2356-PST
From: Rem@IMSSS
Subject: Keywords with cells
To: snyder%HPLABS.ARPA@SCORE
Resent-Date: Thu 5 Dec 85 08:40:05-PST
Resent-From: Alan Snyder <AS@HP-HULK>
Resent-To: common-lisp@SU-AI.ARPA

I thought one of the reasons for having keywords in their own package
was that you can make that a stripped down package that is just a bare
hashtable with no value/function/property cells? I agree "is an error"
should be the case, so if such is the case you truly do get a crashout,
and in implementations that have full package with cells it's up to
the implementor to decide whether to check the "error" or not.
-------

∂05-Dec-85  1049	LOOSEMORE@UTAH-20.ARPA 	keywords   
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 5 Dec 85  10:49:30 PST
Date: Thu 5 Dec 85 11:48:31-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: keywords
To: common-lisp@SU-AI.ARPA
Message-ID: <12164735616.32.LOOSEMORE@UTAH-20.ARPA>

Personally, I think that implementing keywords without value/function/property
cells is a rotten idea.  Essentially, this would make keywords be symbols
that aren't really symbols after all.  Making the behavior of symbols which
just happen to be interned in the keyword package inconsistent with everything
else has the potential for causing real problems for the unsuspecting user.
If SYMBOLP is true of an object, then all of the functions defined on symbols
should work on that object.

-Sandra
-------

∂05-Dec-85  1101	FAHLMAN@C.CS.CMU.EDU 	Keywords with cells    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 5 Dec 85  11:01:28 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 5 Dec 85 14:01:04-EST
Date: Thu, 5 Dec 1985  14:00 EST
Message-ID: <FAHLMAN.12164737885.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Common-Lisp@SU-AI.ARPA
Subject: Keywords with cells


    I thought one of the reasons for having keywords in their own package
    was that you can make that a stripped down package that is just a bare
    hashtable with no value/function/property cells?

I don't think that this was aprt of the motivation for having a separate
keyword package.  The main reason was just so that every package could
get at keywords with equal facility, and so that a keyword with the same
spelling would be EQ in every context.  This was thought to be desirable
since keywords are used primarily as tokens and not as places to stash
package-dependent data.

-- Scott

∂05-Dec-85  1649	DLW@SCRC-STONY-BROOK.ARPA 	Charter stuff
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 5 Dec 85  16:49:00 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 368382; Thu 5-Dec-85 18:18:24-EST
Date: Thu, 5 Dec 85 18:25 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Charter stuff
To: Fahlman@C.CS.CMU.EDU, quinquevirate@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12164056344.BABYL@C.CS.CMU.EDU>
Message-ID: <851205182509.5.DLW@CHICOPEE.SCRC.Symbolics.COM>

Issue 1: I agree that we should go with the minimalist organization.  In
addition to the reasons you presented, I add the following: (1) it's
much easier to get a smaller thing off the ground; (2) we can always
gradually grow it later, if things work out well.

Issue 2: Who decides?  This is very hard.  On point A, I do think it's
still an issue.  Just read the mail.  As I've groused before, everyone
wants to be the designer of Common Lisp.  On point C, I agree that it's
not feasible.  What I am most concerned about is not so much the
individual decisions (they're important too) as the general policies
that will guide the individual decisions.

Issue 3: I like your idea for having the five of us bootstrap an
organization and le it become the de facto organization.  The more I
think about large meetings of diverse individuals, the more I think that
this is the way most likely to produce effective results.  There's just
one thing: the meeting is coming up very soon now.  Can we really put
something together before the meeting?  If not, then what will happen
during all those hours allocated to discuss the charter?  (Actually,
even if we do put something together, then what happens at the meeting?)

Lawyers: I think we have no choice but to consult a lawyer about this.
We will therefore need an initial dollop of cash.  After an initial
consultation, we'll know more and we can decide what to do next.  Since
we're all in different places, I'm not sure exactly how to arrange this
physically, unless you want to try to do it sometime next week.  I'm
pretty sure I can get good recommendations for lawyers in the area,
though whether I could get in to see one on such short notice I don't
know.

∂05-Dec-85  1728	FAHLMAN@C.CS.CMU.EDU 	ISO
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 5 Dec 85  17:27:50 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 5 Dec 85 20:24:17-EST
Date: Thu, 5 Dec 1985  20:24 EST
Message-ID: <FAHLMAN.12164807653.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   quinquevirate@SU-AI.ARPA
Subject: ISO


First, a minor item: I got a copy of CMU's professional liability policy
today, and it appears that they eliminated most of the vagueness last
summer.  So if I am doing something for the good of the community as a
representative of CMU, and if I am not being paid for it (except for
reasonable expenses), and if I believe that I am operating within the
law, and if I get sued, CMU is supposed to pay legal expenses and any
judgement or settlement.  The CMU trustees could decide to abrogate this
policy, but that's a very small risk that I am willing to assume.  So I
feel a lot better about my own legal risks if I should take part in some
organization.  I hope that all of you are similarly covered by your
respective employers.

More important: I had a long talk with Bob Mathis today.  He's the guy
who has coordinated the process of turning Ada into an ISO standard, and
who has taken the first steps toward doing the same thing for Common
Lisp.  He seems to have a very good grasp of the whole process.  He's
also very persuasive.

Mathis says that he is confident that we could form a standards
committee within ISO that could get Common Lisp ratified pretty much as
is, and that would fairly represent the community as it now exists in
considering future changes.  For example, we could get all the right
people appointed to the technical committee that makes the decisions,
and this technical committee would be able to do their work via the
arpanet, just as we do it now.  I was quite skeptical about all this,
but Mathis has been there and seems to ahve all the right connections
within ANSI and ISO.  If we want him to, he is willing to play a role in
this as the "convener" or the committee, and (with some help from Steve
Squires) to handle the political process of getting this thing set up
within ISO.

Well, as I said earlier, the best possible case is if we can actually
get ISO to bless Common Lisp as we would like it to be defined.  I
didn't think this was possible, but after talking with Mathis, I think
it may be possible after all.  In fact, if we go this way, we may not
need any other formal organization -- the ISO technical committee would
be able to speak with authority on what Common Lisp is, or at least on
what they are going to recommend for adoption by ISO when the time
comes.  Of course, we'll still need all those services, but if DARPA
goes ahead with the plans to set up ISI to do this job, maybe we can
do that without a separate organization as well.

It's very attractive to believe that we could do this in the "right" way
and avoid having to create yet another bureaucratic organization in the
world.  I'm not sure that I believe this yet, but I think that it would
be worthwhile to introduce the ISO possibility early in the Boston
meeting and to explore this option throughly before we spend too much
time talking about a separate organization for Common Lisp.  This may be
worth a shot.

Of course, if people come through with enough of those horror stories
that Dick asked for, then this whole idea is a non-starter.

-- Scott

∂06-Dec-85  0028	TIM@MIT-MC.ARPA 	The variables +, -, *, and /
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Dec 85  00:28:09 PST
Date: Fri,  6 Dec 85 03:30:43 EST
From: Tim McNerney <TIM@MIT-MC.ARPA>
Subject:  The variables +, -, *, and /
To: FAHLMAN@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA, greek%bach.decnet@HUDSON.DEC.COM,
    smh@MIT-EMS.ARPA
In-reply-to: Msg of Wed 4 Dec 1985  11:13 EST from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[MIT-MC.ARPA].743936.851206.TIM>

I realize that there are ways of working around the problems caused by this
unfortunate choice of names, but this is not the point.  I am appealing, not
for seasoned Lisp hacker, but for the Lisp user experimenting with new
languages who is not familiar with, for instance, the subtleties of creating
packages which do not :use the LISP package.

The Common Lisp language is riddled with historical relics which were
preserved in the interest of making old programs like Macsyma have some hope
of being ported to Common Lisp (an example of this is the separate function
and value cell), but there is no reason to make the Top-Level Loop compatible
with Maclisp and their descendants.  Furthermore, to reserve variable names
which admittedly do not follow the *...* convention, which are side-effected
by the Top-Level Loop, which are globally declared special, and which naive
Lisp users are likely to try use in their programs, seems inexcusable.

If Common Lisp were not supposed to be an excellent language for developing
new languages, I would not be nearly so disappointed.

	Tim McNerney
	ICAD, Inc.

P.S.  Incidentally, please, please, let us not stumble into another discussion
      about the pros and cons of separate function and value cells.

    Date: Wed, 4 Dec 1985  11:13 EST
    From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>

    We thought brielfly about such issues and decided that we would quickly go
    mad if we tried to avoid stepping on symbols (or ways of using them) for
    every other Lisp-like language.  That's why there are packages.  The
    Common Lisp top-level will not mess around with the value of SCHEME:*,
    etc.  Customize the scheme symbols any way you want, and import from
    the LISP package those things that happen to be right.

    -- Scott

∂06-Dec-85  0606	GJC@MIT-MC.ARPA 	macsyma and common-lisp
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Dec 85  06:06:22 PST
Date: Fri,  6 Dec 85 09:08:54 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject:  macsyma and common-lisp
To: TIM@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA, FAHLMAN@C.CS.CMU.EDU
In-reply-to: Msg of Fri  6 Dec 85 03:30:43 EST from Tim McNerney <TIM at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].744105.851206.GJC>

I've heard that one too many times. Certainly it was even mentioned by
people at some of the early CL meetings that "we cant do X because of
programs like Macsyma," but that has certainly proved not the case.
When it comes to a program the size of DOE-Macsyma at least yours truly
takes the minimum work route, SHADOW EVERYTHING IN SIGHT! Keep my own
private copies of the maclisp-compatible functions because you know
you cant trust the quality (speed or accuracy) of things supposedly
done for maclisp compatibility in some of the more popular
lisp/operating-system environments. And then parts of DOE-macsyma depend
heavily on the dynamic scoping in the maclisp interpreter, and I tell
you that was a pain.

In fact, I remember a very specific statement about (SYMBOLP ()) = T,
in the early CL meetings: "we cant change that because of programs
like Macsyma" Unfortunately the facts didnt seem to matter when I
replied that Macsyma had already been brought up in NIL (which at the
time had a more rational/orthogonal type scheme) and that the fact
that (SYMBOLP ()) was now FALSE and (GET () 'ANYTHING) was now an
error had uncovered some bugs that had escaped tracking down for
years. The proof of actual experience of porting a large system to
what at the time was the post-maclisp dialect pointing to common-lisp
did not in fact matter. (Or as Hitler once said, "How many [army] divisions
does the Pope have?").

So lets not entertain any further mention of things for the benefit of
Macsyma.


∂06-Dec-85  0642	KMP@SCRC-VALLECITO.ARPA 	The variables +, -, *, and /  
Received: from SCRC-VALLECITO.ARPA by SU-AI.ARPA with TCP; 6 Dec 85  06:42:36 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-VALLECITO.ARPA via CHAOS with CHAOS-MAIL id 68648; Fri 6-Dec-85 09:42:02-EST
Date: Fri, 6 Dec 85 09:42 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: The variables +, -, *, and /
To: TIM@MIT-MC.ARPA, FAHLMAN@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA, greek%bach.decnet@HUDSON.DEC.COM,
    smh@MIT-EMS.ARPA
In-Reply-To: <[MIT-MC.ARPA].743936.851206.TIM>
Message-ID: <851206094203.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Fri,  6 Dec 85 03:30:43 EST
    From: Tim McNerney <TIM@MIT-MC.ARPA>

    I realize that there are ways of working around the problems caused by this
    unfortunate choice of names, but this is not the point.  I am appealing, not
    for seasoned Lisp hacker, but for the Lisp user experimenting with new
    languages who is not familiar with, for instance, the subtleties of creating
    packages which do not :use the LISP package.

Naive users should be taught how to program using reasonable techniques. 
There are recently dozens of examples of people who did langauges embedded in
another which were implemented as puns on primitive language semantics and then
had their respective jokes spoiled by changes to the language. The case that
comes immediately to mind are languages that claimed to be dynamically scopped
but which were in fact depended on their underlying language to be dynamic, so
when the underlying language became lexical, the embedded language became broken.
There are right and wrong ways to do embedded languages. People should not continue
to use broken techniques when workable ones exist.

    The Common Lisp language is riddled with historical relics which were
    preserved in the interest of making old programs like Macsyma have some hope
    of being ported to Common Lisp (an example of this is the separate function
    and value cell), but there is no reason to make the Top-Level Loop compatible
    with Maclisp and their descendants.  Furthermore, to reserve variable names
    which admittedly do not follow the *...* convention, which are side-effected
    by the Top-Level Loop, which are globally declared special, and which naive
    Lisp users are likely to try use in their programs, seems inexcusable.

System constants (eg, PI, MOST-POSITIVE-FIXNUM, ARRAY-RANK-LIMIT) are already in
that namespace even if they are treated slightly differently. Your naive users had
better know about these or they'll confuse themselves. Once they've learned about
these, a few more un-starred names is not unreasonable.

Besides, Lisp is a symbol-processing language. By that we mean that it's the token
itself, not the character string which is its print-name, which is of interest.
Allowing stars on the end of the symbol's printname to dictate the semantics of a 
variable is what would be inexcusable.

    If Common Lisp were not supposed to be an excellent language for developing
    new languages, I would not be nearly so disappointed.

The proposed solution (using packages) mentioned by all the respondents thus far
does not inhibit you from doing reasonable things. I don't know why you should be
disappointed. If you dislike packages as much as I, you should be pleased that they
offer a way for you to isolate yourself from the rest of the CL world and build 
your own personalized world out of symbols whose semantics, plist, value, etc will
be untarnished by CL's hairy mechanisms. It would be far less easy to hide a CL
embedded in any of the Scheme's I know of.

	    Tim McNerney
	    ICAD, Inc.

    P.S.  Incidentally, please, please, let us not stumble into another discussion
	  about the pros and cons of separate function and value cells.

	Date: Wed, 4 Dec 1985  11:13 EST
	From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>

	We thought brielfly about such issues ...

On the subject of amateur archiving, let me say that I find including another's message
at the end of a long message like this to be silly. It gives me the impression that my
Babyl file has been trashed and that somehow the boundary between two messages has 
disappeared. If I've gotten as far as reading to the point where this sort of included
message appears, I no longer need the context.

∂06-Dec-85  0702	FAHLMAN@C.CS.CMU.EDU 	The variables +, -, *, and /
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 6 Dec 85  07:02:23 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 6 Dec 85 10:02:11-EST
Date: Fri, 6 Dec 1985  10:02 EST
Message-ID: <FAHLMAN.12164956539.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Tim McNerney <TIM@MIT-MC.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: The variables +, -, *, and /
In-reply-to: Msg of 6 Dec 1985  03:30-EST from Tim McNerney <TIM at MIT-MC.ARPA>


In fact, we did not blindly follow precedent in this case.  I remember
asking, at the time we were doing the Eval chapter, whether we should
flush these names in favor of something more mnemonic and more
standard-looking.  The feeling was that these things are for use by the
user at the keyboard and that they want to be very short.  Some users
have an interaction style that depends on these things very heavily.
Given that, these seemed like the one-character symbols that a user was
least likely to accidentally include in a program as a symbol, precisely
because they are so universally used as function names that they look
ugly as variables.  If we had been willing to postulate an Emacs-like
top-level for every implementation, we could have come up with some
different mechanism than the use of side effects on variables to save
the recent results, but at the time we felt that we had to allow for
simple but usable top-levels.  I'm not sure I'd make the same choice
today, but it's not one that look obviously crazy to me.

I think that by the time a user is playing with embedded languages, he
is not such a beginner and he had damned well better make friends with
packages.  That's what they are for, and I think they are a reasonably
good solution.  Note that you don't have to avoid using LISP in this
case, if *+/- is your only concern.  Just create a new package, use
LISP, and shadow those specific symbols.

-- Scott

∂06-Dec-85  1223	jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	ISO Standard   
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 6 Dec 85  12:23:21 PST
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK   via Janet with NIFTP
           id a009085; 2 Dec 85 20:48 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>
Date: Mon, 2 Dec 85 20:31:41 GMT
To: common-lisp@su-ai.arpa
Subject: ISO Standard

The 21 November issue of Computer Weekly (one of the UK "computer comics")
had a short article on a recent ISO meeting in Paris, entitled "Three
language standards come closer".  One of the languages was C, and the 
ISO would use the ANSI draft standard as a basis.  The other two were
Prolog and Lisp:

	At the Paris meeting ISO also set up a study group to
	standardize the artificial intelligence languages, Lisp
	and Prolog.
	This group is to be chaired by Bob Mathis, who has been
	closely involved in the development of the Ada standard.
	The artificial intelligence group will report by Sept.
	1986 to the ISO on the need for standards in the Lisp
	and prolog languages.

They go on to say "the UK and France are already well advanced towards
a Prolog standard" but say nothing more about Lisp.

Does anyone know anything about this?

∂06-Dec-85  1321	FAHLMAN@C.CS.CMU.EDU 	ISO Standard 
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 6 Dec 85  13:21:07 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 6 Dec 85 16:05:57-EST
Date: Fri, 6 Dec 1985  16:05 EST
Message-ID: <FAHLMAN.12165022759.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Jeff Dalton <jeff%aiva.edinburgh.ac.uk@CS.UCL.AC.UK>
Cc:   common-lisp@SU-AI.ARPA
Subject: ISO Standard
In-reply-to: Msg of 2 Dec 1985  15:31-EST from Jeff Dalton <jeff%aiva.edinburgh.ac.uk at cs.ucl.ac.uk>


Bob Mathis will be at the Boston meeting and will fill us all in on what
is happening with ISO, and also on what the possibilities are for
getting Common Lisp standardized under ISO in some reasonable way.
After some discussion with Mathis, I think that the idea of cooperating
in a serious way with the ISO standardization effort may be a good idea
after all.  We'll see what develops in Boston.

-- Scott

∂06-Dec-85  1916	TIM@MIT-MC.ARPA 	The variables +, -, *, and /
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Dec 85  19:16:47 PST
Date: Fri,  6 Dec 85 22:19:16 EST
From: Tim McNerney <TIM@MIT-MC.ARPA>
Subject:  The variables +, -, *, and /
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Fri 6 Dec 1985  10:02 EST from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[MIT-MC.ARPA].745025.851206.TIM>

    Date: Fri, 6 Dec 1985  10:02 EST
    From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>

    I think that by the time a user is playing with embedded languages, he
    is not such a beginner and he had damned well better make friends with
    packages.

You would be surprised.  I know people working on embedded languages who
have either never had to use packages or have only gotten screwed by them
and would prefer never to touch them again.

I suspect that you will find that the majority of graduate students in AI
using Common Lisp for their thesis project will not learn about even a
significant fraction of Common Lisp's pitfalls before they complete their
degrees.  They will have neither the time nor the inclination.

	Tim

∂07-Dec-85  0719	FAHLMAN@C.CS.CMU.EDU 	The variables +, -, *, and /
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 7 Dec 85  07:19:11 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 7 Dec 85 10:19:00-EST
Date: Sat, 7 Dec 1985  10:18 EST
Message-ID: <FAHLMAN.12165221752.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Tim McNerney <TIM@MIT-MC.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: The variables +, -, *, and /
In-reply-to: Msg of 6 Dec 1985  22:19-EST from Tim McNerney <TIM at MIT-MC.ARPA>


    You would be surprised.  I know people working on embedded languages who
    have either never had to use packages or have only gotten screwed by them
    and would prefer never to touch them again.

    I suspect that you will find that the majority of graduate students in AI
    using Common Lisp for their thesis project will not learn about even a
    significant fraction of Common Lisp's pitfalls before they complete their
    degrees.  They will have neither the time nor the inclination.

I guess I would be surprised.  Most of the grad students I've known
around CMU and MIT either go in and completely master their tools or
else they find out what they need and master that part.  But maybe these
places are atypical.  I grant you that some undergrads try to slide by
with the minimum competence needed to pass, but are we really designing
a language for those guys?

Anyway, if packages are really proving to be that tough for people, we
either need better training materials or else there are things in the
package system we need to fix up to make it esier to use.  Probably
both.  I don't think that the solution is to try to mess up the rest of
the language so that people can do embedded languages without using
packages -- we would basically have to take all the good names away from
Common Lisp in order to leave them free for other use.  The +*/-
characters are just the tip of the iceberg.

-- Scott

∂07-Dec-85  1206	RPG  	Legal Issues  
To:   quinquevirate@SU-AI.ARPA   

I talked to our (Lucid) lawyer yesterday about organizations that
allow, let's say, us to maintain and set standards, yet provide us
protection from personal lawsuits. The lawyer said that there are
trade-union-type organizations which set standards but are fully
protected. The danger comes when the bylaws of the organization
allows the organization to take actions or set standards that tend
to prevent companies from being competitive. So the organization
could not set advertising standards or dictate marketting policies.

Morever, the organization can be set up to be non-profit, and thereby
it would enjoy a good tax situation.

Needless to say, our lawyers know about Lucid's business, the
software business, the Common Lisp situation, and my exposure, so
I think this is a well-informed opinion.
			-rpg-

∂07-Dec-85  1723	REM@IMSSS 	need subset of CL! 
X-Sent: to SU-AI.ARPA by IMSSS.FRONSTAD.EDU via ETHERNET with PUPFTP; 1985-Dec-07 17:09:42 PST (=GMT-8hr)
X-Mailer: EMACS -> PSL (FORMAT+SEND-ALL) -> PUPFTP
Date: 1985 December 07 17:05:56 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132507010126.G0357
From: Robert Elton Maas <REM@IMSSS.STANFORD.EDU>
To:TIM@MIT-MC.ARPA
CC:COMMON-LISP@SU-AI.ARPA
subject:need subset of CL!
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up)

| Date: Fri,  6 Dec 85 22:19:16 EST
| From: Tim McNerney <TIM@MIT-MC.ARPA>
| Subject:  The variables +, -, *, and /
| I suspect that you will find that the majority of graduate students in AI
| using Common Lisp for their thesis project will not learn about even a
| significant fraction of Common Lisp's pitfalls before they complete their
| degrees.  They will have neither the time nor the inclination.

I take this as evidence that CL is too big. If there are so many functions
and special cases (keyword & optional args) to learn that the student
doesn't have time to learn basic stuff like packages, something is wrong.
I continue to say that we need some subset of CL that (1) can be taught
completely to a student in one semester, (2) can be implemented on a
small microcomputer by a small team of programmers in a reasonable time,
(3) can be exhaustively tested for correctness (I don't mean by exhaustive
trial of all combinations; I mean that each and every feature is tested
without exception) by a reasonable test suite.

∂07-Dec-85  2328	masinter.PA@Xerox.ARPA 	packages   
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 7 Dec 85  23:28:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 07 DEC 85 23:28:42 PST
From: masinter.PA@Xerox.ARPA
Date: 7 Dec 85 23:25:37 PST
Subject: packages
To: common-lisp@su-ai.ARPA
Message-ID: <851207-232842-4561@Xerox>

I think that most people recognize that the package system is seriously
flawed, but that it was the best that was available by the time it was
necessary to publish the book. There have not as of yet been any serious
proposals for how to fix the current flaws. Perhaps this needs a
separate subcommittee.

∂08-Dec-85  0606	FAHLMAN@C.CS.CMU.EDU 	packages
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 8 Dec 85  06:06:43 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 8 Dec 85 09:06:42-EST
Date: Sun, 8 Dec 1985  09:06 EST
Message-ID: <FAHLMAN.12165470736.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   masinter.PA@XEROX.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: packages
In-reply-to: Msg of 8 Dec 1985  02:25-EST from masinter.PA at Xerox.ARPA


I think the history of the various subcommittees shows that they don't
really begin to function until someone comes up with a concrete
proposal or at least a coherent set of objectives and ideas.  Whenever
we have such a proposal, that would be the time to consider changes to
the package system, either in a subcommittee or all together.

Aside from the case-sensitivity lossage in package names, I'm not sure
what people find to be so hard.  If it is just that they get confused
about what symbols live where, maybe all we need is a good tool
(Masterscope-like?) for finding out which symbols live where, which ones
shadow other sysmbols, etc., and for displaying the result in a
reasonable form.

-- Scott

∂08-Dec-85  1107	DLW@SCRC-STONY-BROOK.ARPA 	need subset of CL!
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Dec 85  11:07:22 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 369695; Sun 8-Dec-85 14:03:55-EST
Date: Sun, 8 Dec 85 14:10 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: need subset of CL!
To: quinquevirate@SU-AI.ARPA
In-Reply-To: SU-IMSSS.REM.A132507010126.G0357
Message-ID: <851208141046.3.DLW@CHICOPEE.SCRC.Symbolics.COM>

I wanted to send this reply, but restrained myself.

    Date: 1985 December 07 17:05:56 PST (=GMT-8hr)
    From: Robert Elton Maas <REM@IMSSS.STANFORD.EDU>

     Date: Fri,  6 Dec 85 22:19:16 EST
     From: Tim McNerney <TIM@MIT-MC.ARPA>
     Subject:  The variables +, -, *, and /
     I suspect that you will find that the majority of graduate students in AI

    I take this as evidence that CL is too big.

You take an off-the-cuff "I suspect" from one person as "evidence"?
Remind me not to hire you as my attorney.

∂08-Dec-85  1806	RWK@SCRC-STONY-BROOK.ARPA 	The variables +, -, *, and /
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Dec 85  18:06:09 PST
Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 369781; Sun 8-Dec-85 21:02:38-EST
Date: Sun, 8 Dec 85 21:00 EST
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: The variables +, -, *, and /
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: Tim McNerney <TIM@MIT-MC.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12165221752.BABYL@C.CS.CMU.EDU>
Message-ID: <851208210052.9.RWK@CROW.SCRC.Symbolics.COM>

    Date: Sat, 7 Dec 1985  10:18 EST
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
    I guess I would be surprised.  Most of the grad students I've known
    around CMU and MIT either go in and completely master their tools or
    else they find out what they need and master that part.  But maybe these
    places are atypical.  I grant you that some undergrads try to slide by
    with the minimum competence needed to pass, but are we really designing
    a language for those guys?
Maybe the difference between grad students and us drop-outs
is that us drop-outs always read the whole manual and learn
our tools, instead of going to class?

Anyway, for the sake of students trying to do their thesis
in two weeks,  I suggest we put somewhere prominent a list of
facilities of interest to people imbedding languages.  Anyone
THEN not willing to read the little material involved doesn't
deserve a degree.  (I read it ALL immediately, can I get a
degree?)

I'm not arguing against other proposals to make it easier to use.
But maybe we could make it a bit easier for the guy in a rush
who only wants to learn about what he needs.  Probably most
people are in that situation when they start out using something
new, even if they aren't by the time they're done.  We just tend
to forget the feeling once we become expert.

∂08-Dec-85  1823	MATHIS@USC-ISIF.ARPA 	Re: ISO Standard  
Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 8 Dec 85  18:23:10 PST
Date: 8 Dec 1985 18:21-PST
Sender: MATHIS@USC-ISIF.ARPA
Subject: Re: ISO Standard
From: MATHIS@USC-ISIF.ARPA
To: jeff%aiva.edinburgh.ac.uk@UCL-CS.ARPA
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISIF.ARPA] 8-Dec-85 18:21:40.MATHIS>
In-Reply-To: The message of Mon, 2 Dec 85 20:31:41 GMT from Jeff Dalton <jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>

At  the  meeting in Boston, I will be talking to people about the
ISO effort for a LISP standard.  -- Bob Mathis

∂10-Dec-85  1352	hplabs!perdue@hplabsd 	Macrolet index bug    
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 10 Dec 85  13:51:51 PST
Received: by hplabsd ; Tue, 10 Dec 85 13:49:37 pst
Date: Tuesday, December 10, 1985  11:17:28
From: perdue@hplabsd
Subject: Macrolet index bug
To: common-lisp@su-ai
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46

In the manual the main index for macrolet is listed at pages 93-94.
The main reference should be to page 113 instead.
-------

∂12-Dec-85  1836	shebs%utah-orion@utah-cs.arpa 	Special Form Question   
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 12 Dec 85  18:36:14 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
	id AA19193; Thu, 12 Dec 85 19:36:42 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
	id AA20979; Thu, 12 Dec 85 19:36:38 MST
Date: Thu, 12 Dec 85 19:36:38 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8512130236.AA20979@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Special Form Question

This may seem like an exceptionally stupid question, but what should
the following do?

  (setf (symbol-function 'foo) (symbol-function 'quote))
  (foo (a b c))

While CLtL prohibits defining new special forms, it's not clear
that this use is defining a "new" form.  Also, symbol-function on
special forms is allowed to return something (whose exact nature is
carefully left vague) which presumably can be used elsewhere.  The
whole thing sure looks like a nod to implementations which still have
nasty fexprs :-), and for which the above trick would be valid.
Am I right?  Or is it OK for symbol-function of a special form to
signal an error?

							stan shebs

∂13-Dec-85  0705	DLW@SCRC-STONY-BROOK.ARPA 	Special Form Question  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Dec 85  07:04:19 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 373758; Fri 13-Dec-85 10:04:22-EST
Date: Fri, 13 Dec 85 10:12 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Special Form Question
To: shebs%utah-orion@UTAH-CS.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <8512130236.AA20979@utah-orion.ARPA>
Message-ID: <851213101236.3.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Thu, 12 Dec 85 19:36:38 MST
    From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)

    This may seem like an exceptionally stupid question, but what should
    the following do?

      (setf (symbol-function 'foo) (symbol-function 'quote))
      (foo (a b c))

It certainly should not be required to make foo act like quote.  But
exactly how to rule it out is not completely clear.  symbol-function is
sort of useful as a tool to examine your environment, so having it
signal an error might not be appropriate.  Perhaps the function that the
setf turns into should be responsible for not storing special forms?  Or
maybe this is too implementation dependant, and we should just say "it
is an error" to store such a thing?

∂13-Dec-85  0708	NGALL@BBNG.ARPA 	Re: Special Form Question   
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 13 Dec 85  07:08:23 PST
Date: 13 Dec 1985 10:04-EST
Sender: NGALL@BBNG.ARPA
Subject: Re: Special Form Question
From: NGALL@BBNG.ARPA
To: shebs%utah-orion@UTAH-CS.ARPA
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[BBNG.ARPA]13-Dec-85 10:04:31.NGALL>
In-Reply-To: <8512130236.AA20979@utah-orion.ARPA>

	
    Date: Thu, 12 Dec 85 19:36:38 MST
    From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
    To: common-lisp@su-ai.arpa
    Subject: Special Form Question
    Message-ID: <8512130236.AA20979@utah-orion.ARPA>
    
    This may seem like an exceptionally stupid question, but what should
    the following do?
    
      (setf (symbol-function 'foo) (symbol-function 'quote))
      (foo (a b c))
    
    While CLtL prohibits defining new special forms, it's not clear
    that this use is defining a "new" form.  Also, symbol-function on
    special forms is allowed to return something (whose exact nature is
    carefully left vague) which presumably can be used elsewhere.  The
    whole thing sure looks like a nod to implementations which still have
    nasty fexprs :-), and for which the above trick would be valid.
    Am I right?  Or is it OK for symbol-function of a special form to
    signal an error?
    
							    stan shebs
    
	      --------------------
		
It is clearly NOT OK for (symbol-function 'quote) to signal an error, pg. 90.
It is not clear (in CLtL) whether
	(setf (symbol-function 'foo)
              #<object-representing-special-form-quote>)
is an error ("The set of special forms is fixed in CL." pg. 57);
must "work" (Note that there is no restriction on the "specified definition"
that may be assigned to the symbol-function gen. var., pg. 90;
is left undefined (Note that vagueness of what symbol-function of a special
form returns and what special-form-p returns (and what can be done with them).

I vote for "is an error" for the simple reason that portable code analyzers
(incl. compilers) count on the fact that they must have special-purpose 
code only for the symbols in Table 5-1 (cf. the code-analysis "algorithm" on
pg. 57).  If we break this restriction, portable code ananlyzers would become
much more complicated (if not impossible without further CLtL revisions).

Besides, why would anyone need to do such a thing? Remember macros?...

	-- Nick

∂13-Dec-85  0744	shebs%utah-orion@utah-cs.arpa 	Re: Special Form Question    
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 13 Dec 85  07:43:55 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
	id AA26265; Fri, 13 Dec 85 08:44:27 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
	id AA22517; Fri, 13 Dec 85 08:44:24 MST
Date: Fri, 13 Dec 85 08:44:24 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8512131544.AA22517@utah-orion.ARPA>
To: NGALL@bbng.arpa, shebs%utah-orion@utah-cs.arpa
Subject: Re: Special Form Question
Cc: common-lisp@su-ai.arpa

From NGALL@BBNG.ARPA Fri Dec 13 08:08:41 1985
	
      (setf (symbol-function 'foo) (symbol-function 'quote))
      (foo (a b c))
    
   I vote for "is an error" for the simple reason that portable code analyzers
   (incl. compilers) count on the fact that they must have special-purpose 
   code only for the symbols in Table 5-1 (cf. the code-analysis "algorithm" on
   pg. 57).  If we break this restriction, portable code ananlyzers would become
   much more complicated (if not impossible without further CLtL revisions).

   Besides, why would anyone need to do such a thing? Remember macros?...

There are a lot of things that CL talks about that nobody would really do!
This particular issue has a lot to do with whether an implementation needs
to support fako fexprs secretly, or whether it can treat each special form
case-by-case in both the compiler and interpreter.  Without naming names,
I can point to CL implementations which *do* have fexprs, and which *do*
allow the above, but if I were to sit down and do an implementation today,
I wouldn't have anything even remotely resembling fexpr functions at all.
"Is an error" seems like the right answer.

								stan shebs

∂13-Dec-85  0804	FAHLMAN@C.CS.CMU.EDU 	Special Form Question  
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Dec 85  08:03:52 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 13 Dec 85 11:03:40-EST
Date: Fri, 13 Dec 1985  11:03 EST
Message-ID: <FAHLMAN.12166802750.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   shebs%utah-orion@λutah-cs.arpa (Stanley Shebs)λ
Cc:   common-lisp@SU-AI.ARPA
Subject: Special Form Question
In-reply-to: Msg of 12 Dec 1985  21:36-EST from shebs%utah-orion at utah-cs.arpa (Stanley Shebs)


You do come up with the most imaginative questions...

We clearly do not require that

(setf (symbol-function 'foo) (symbol-function 'quote))

somehow makes foo act like quote.  Nor do we explicitly require this to
signal an error.  The case that you describe is so perverse that I do
not think it is worthwhile for those implementations that use something
like internal FEXPRs in the interpreter to bother checking that they are
being called in a legitimate way.

I think the best position to take is the following: Symbols that name
special forms do have symbol-function slots, just like any other symbol.
The implementation is allowed, but not required, to put some strange
object in that slot, and we cannot prevent users from getting their
hands on this object if it exists.  However, the nature of this object,
if it exists, is completely unspecified and users cannot count on doing
anything useful with it.  It is an error to funcall or apply this thing,
or to stick it in a symbol-function slot of some symbol and then
evaluate a form with that symbol as the Car.

-- Scott

∂13-Dec-85  1022	Moon@SCRC-QUABBIN.ARPA 	Special Form Question
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 13 Dec 85  10:22:22 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 228016; Fri 13-Dec-85 13:17:12-EST
Date: Fri, 13 Dec 85 13:17 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Special Form Question
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12166802750.BABYL@C.CS.CMU.EDU>
Message-ID: <851213131726.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 13 Dec 1985  11:03 EST
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    We clearly do not require that

    (setf (symbol-function 'foo) (symbol-function 'quote))

    somehow makes foo act like quote.  Nor do we explicitly require this to
    signal an error.  The case that you describe is so perverse that I do
    not think it is worthwhile for those implementations that use something
    like internal FEXPRs in the interpreter to bother checking that they are
    being called in a legitimate way.

    I think the best position to take is the following: Symbols that name
    special forms do have symbol-function slots, just like any other symbol.
    The implementation is allowed, but not required, to put some strange
    object in that slot, and we cannot prevent users from getting their
    hands on this object if it exists.  However, the nature of this object,
    if it exists, is completely unspecified and users cannot count on doing
    anything useful with it.  It is an error to funcall or apply this thing,
    or to stick it in a symbol-function slot of some symbol and then
    evaluate a form with that symbol as the Car.

I agree.  I'd like to propose a clarification about macros.  If a symbol is
the name of a macro, then symbol-function returns an unspecified object that
it is an error to funcall or apply, however sticking that object into the
symbol-function slot of another symbol does make that other symbol name the
same macro.  The alternative would be to say that it's just as illegal for
macros as for special forms.

∂13-Dec-85  1101	NGALL@BBNG.ARPA 	Re: Special Form Question   
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 13 Dec 85  11:00:54 PST
Date: 13 Dec 1985 13:56-EST
Sender: NGALL@BBNG.ARPA
Subject: Re: Special Form Question
From: NGALL@BBNG.ARPA
To: Fahlman@C.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[BBNG.ARPA]13-Dec-85 13:56:25.NGALL>
In-Reply-To: <FAHLMAN.12166802750.BABYL@C.CS.CMU.EDU>

	
    Date: Fri, 13 Dec 1985  11:03 EST
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
    To:   shebs%utah-orion@λutah-cs.arpa (Stanley Shebs)λ
    Subject: Special Form Question
    In-Reply-To: Msg of 12 Dec 1985  21:36-EST from shebs%utah-orion at utah-cs.arpa (Stanley Shebs)
    Message-ID: <FAHLMAN.12166802750.BABYL@C.CS.CMU.EDU>
    
    
    You do come up with the most imaginative questions...
    
    We clearly do not require that
    
    (setf (symbol-function 'foo) (symbol-function 'quote))
    
    somehow makes foo act like quote.  Nor do we explicitly require this to
    signal an error.  The case that you describe is so perverse that I do
    not think it is worthwhile for those implementations that use something
    like internal FEXPRs in the interpreter to bother checking that they are
    being called in a legitimate way.
    
    I think the best position to take is the following: Symbols that name
    special forms do have symbol-function slots, just like any other symbol.
Wrong.  A CL symbol does not have a function as a "user-visible
component" (i.e., slot; cf. pg. 163).  Since CLtL goes out of its way
to point this out, I think it is a good idea to not slip back into
definition by implementation (are any implementtations NOT using
function cells?).
    The implementation is allowed, but not required, to put some strange
    object in that slot, and we cannot prevent users from getting their
    hands on this object if it exists.  However, the nature of this object,
    if it exists, is completely unspecified and users cannot count on doing
    anything useful with it.  It is an error to funcall or apply this thing,
If this "strange object" is to be completely unspecified, then the
section of the defintion of special-form-p (pg. 91) that DOES specify
what this strange object "typically" is, should be made an
Implementation Note.
    or to stick it in a symbol-function slot of some symbol and then
    evaluate a form with that symbol as the Car.
    
    -- Scott
    
	      --------------------
		
	-- Nick

∂13-Dec-85  1109	NGALL@BBNG.ARPA 	Re: Special Form Question   
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 13 Dec 85  11:09:25 PST
Date: 13 Dec 1985 14:05-EST
Sender: NGALL@BBNG.ARPA
Subject: Re: Special Form Question
From: NGALL@BBNG.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[BBNG.ARPA]13-Dec-85 14:05:25.NGALL>
In-Reply-To: <851213131726.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

	
    Date: Fri, 13 Dec 85 13:17 EST
    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
    To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
    Subject: Special Form Question
    In-Reply-To: <FAHLMAN.12166802750.BABYL@C.CS.CMU.EDU>
    Message-ID: <851213131726.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
    
    ...
    I agree.  I'd like to propose a clarification about macros.  If a symbol is
    the name of a macro, then symbol-function returns an unspecified object that
    it is an error to funcall or apply, however sticking that object into the
    symbol-function slot of another symbol does make that other symbol name the
    same macro.  The alternative would be to say that it's just as illegal for
    macros as for special forms.
    
	      --------------------
		
What about symbols that have both a macro definition and are
special-form names?

I prefer the alternative. Use macro-function to get the macro,
special-form-p to "typically" get the fexpr :-), and symbol-function
for honest-to-god functions.  Otherwise, implementations that don't
just return the value of the function cell will be forced to put macro
and special-form accessing machinery into symbol-function.

	-- Nick

∂13-Dec-85  1155	shebs%utah-orion@utah-cs.arpa 	Clarification Comments (long)
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 13 Dec 85  11:55:13 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
	id AA00503; Fri, 13 Dec 85 12:55:43 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
	id AA23353; Fri, 13 Dec 85 12:55:38 MST
Date: Fri, 13 Dec 85 12:55:38 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8512131955.AA23353@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Clarification Comments (long)

The following long message is a set of knee-jerk reactions to Guy's list
of suggested clarifications.  They are (more or less) keyed by page, as
in the printed list handed out at the meeting.  You'll need the list,
since I left out context to save space.

1 There are at least two reasons for having undo operations.  The most
obvious is for user-friendliness and mistake-fixing, while the other
reason is to support really arcane things.  I would put the various
"un" package functions into the first category, while something like
makunbound is more in the second.  If CL is the subset used for portable
programs, then it seems to me that functions whose sole purpose is to
improve the user interface are less important; they are unlikely to
show up in programs to be ported.  From that point of view, a general
undo is not appropriate for CL, although certain specific things like
delete-package might be OK.  If an implementation *does* have an undo,
I would like to see it as elaborate as the facilities in Interlisp -
fixing a mistaken (setq *macroexpand-hook* #'tailp) shouldn't result
in (makunbound '*macroexpand-hook*)!

47 This is OK, although it feels a little uncomfortable to include the
name of a local keyword variable in a proclamation that may be in
another file.  Bye bye alpha conversion...

51 Yes!

56, 58 Go for it.

60 Yes, on the principle that it might allow more optimization
(I have here in my hand a list of 203 known compiler optimizations that
this would make possible...).

82 Sounds like a good idea - I even thought back over old code to
see it would simplify any complicated conditionals.  Sadly, I couldn't
remember any.

107 Yup, on the principle of decoupling functionality.

113 Sounds OK, but do I vaguely remember battles on possibly difficult
problems with this one?

120 Yes, on the principle of orthogonality, but it'll fatten up the
code a bit (unless of course one has the fabled "sufficiently good"
compiler).

130 I didn't realize until now that tagbody does have a restriction
on body contents.  That seems wrong to me.  Presumably lots of things
will macroexpand into tagbodies, and every one inherits the same
restriction.  Worse, one implementation's dolist will macroexpand
into a tagbody, while in another, it will be a special form.  Why
not say that integers and symbols are tags, and everything else is
a form? Or that all non-lists are tags?

130 Might have same problems as previous point, but it seems less
likely to be a problem.  OK by me (but needs more thought).

144 Seems reasonable, although I'm sure there's some subtle point
I'm missing about why macro-function should be defined this way,
and symbol-function should not.

145 Yes!  Although it needs a fairly careful specification.
Should parse-body work on all def* bodies?

145 Yes.

145 Yes. (Why so many clarifications for macros anyway? :-)

158 Yup.

159 Good.

162 OK.

172 Yes, although it breaks much code...

186 Doesn't seem *wrong*, but not clear why one can't explicitly test
symbol-package and intern instead.  Sounds like a frob.

187 Ah yes, making the spec conform to reasonable implementations!

202 Sure.

212 Isn't a proposal that's *already* been accepted that we could
follow?

226 "All in all, it's just another frob in the spec..."

239 This one seems really unmotivated - why the bits and not the
font anyway?  Perhaps we could add keywords to char comparison
to tell which parts of the char are to be considered :-)

249 I think the effect of mapping over circular lists should be
to delete the offending program and harass the user every time
he/she starts up the Lisp thereafter.  Trying to make all of the
functions work on arbitrarily hairy list structure involves too
many imponderables - mapcar and "circular" lists is just the tip
of the iceberg.

268 Yes - I always assumed this one slipped through the cracks.
Should it work on circular lists? :-)

275 Yes.

283 Yes.  Does anybody actually have an implementation for which these
functions would be more than structure accessors that already exist
internally?

293 Yes.  The array functions are, shall we say, sketchy; these seem
like worthwhile additions.  There are probably others.

295 Yes - how would anyone adjust *part* of an array?

297 Sounds OK to me, but I haven't studied the issues closely.

297 Yes, to be consistent with p. 295 clarification.

307 Yes.

307 Yes, and should this be extended to cover both plain slot names
and ones with conc-names added?  Or is the normal "functions stepping
on each other" protocol sufficient?

321 Seems like a frob, but there's no real reason not to do it.

322 Makes sense.

328 Yes, but I would go further and say that there are no requirements
*at all* about which streams are bound to which, or whether any are
bound at all!  But then one would have to define more behavior
(the issue has already come up of yes-or-no-p being called when one
is running a batch job, and doesn't plan to login until next week).

425 Yes.

439 Pretty dramatic clarification!  This isn't even hinted at in the
book.  OK by me, although made unnecessary if uncompile is defined.

439 Yeah.

439 This constrains the implementation to save source code somewhere,
which is more of a nuisance than a hardship.  This is really another
one of those user convenience things.

440 Sure, with the same proviso as for inline functions, that a macro
call may not be traceable because it's been expanded already.

443 Now we know how to implement apropos! :-)

447 What's another function when you've got hundreds? Sure.

							stan

∂13-Dec-85  1215	gls@THINK-AQUINAS.ARPA 	list of proposed changes to Common Lisp  
Received: from THINK.COM by SU-AI.ARPA with TCP; 13 Dec 85  12:15:29 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Fri, 13 Dec 85 15:15:17 est
Date: Fri, 13 Dec 85 15:15 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: list of proposed changes to Common Lisp
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <851213151511.1.GLS@THINK-JEHOSEPHAT.ARPA>

The following is the text, verbatim, of the handout I made available
this past Monday at the Common Lisp meeting.  One exception: in the entry
for page 293, the second occurrence of (DISPLACED-ARRAY-P NEW-ARRAY)
has been deleted because it was a typographical error.

------------------------------------------------------------------------
These are changes that I (Guy Steele) think are important but must not
be made without the general approval of the Common Lisp community.
Items that I think particularly important (because they correct
important flaws or resolve ambiguity in the specification) are marked
(*).

1 DELETE-SETF-METHOD takes the name of an access-fn and removes the SETF
data associated with that name.  DELETE-PACKAGE takes a package,
uninterns all symbols in that package, unuses all packages it uses, and
gets rid of the package.  An error is signalled if the package is used
by any other package.  Maybe other things, such as DELETE-TYPE (undoes a
DEFTYPE), UNDEFUN, UNDEFVAR, UNDEFCONSTANT, and so on are needed as
well.  One suggestion is to have a single special form UNDO, allowing
one to write such things as (UNDO DEFUN FOO), (UNDO DEFINE-SETF-METHOD
FOO), and so on (syntax negotiable).  Presumably (UNDO SETQ FOO) means
roughly the same as (MAKUNBOUND 'FOO)--or does it?  What of the scoping
of FOO?  We need some way to do these things, but I have no concrete
suggestion as yet.

(*) 47 Specify that, in a FUNCTION type specifier, following the &KEY
marker one should use items of the form (keyword type-specifier)
instead of just a type-specifier:
(DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY (FROM-END T)
		           (START (INTEGER 0 ())) (END (INTEGER 0 ()))
			   (INITIAL-VALUE T))
		          T)
	        REDUCE))
Specify that such a declaration implies that no other keywords may be
used unless the declaration also contains &ALLOW-OTHER-KEYWORDS; in
other words, one must explicitly declare types for all keyword arguments
or else use &ALLOW-OTHER-KEYWORDS.  Specify that a type specifier for a
&REST argument indicates the type of each argument, not the type of a
rest-argument list (which is always a list, after all):
(DECLARE (FTYPE (FUNCTION (ARRAY &REST (INTEGER 0 ())) T) AREF))

(*) 51 Add a new function TYPE-SPECIFIER-P that is true of valid type
specifiers and false of all other Lisp objects.  Note that the use of
DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
time.

(*) 56, 68  Clarify that using DEFCONSTANT to redefine any constant
described in the Common Lisp specification is an error.  Clarify that if
the user defines a constant, compiles code that refers to that constant,
and then redefines the constant, then behavior of the compiled code may
be unpredictable.  (Perhaps it ``is an error'' to execute such code.)

(*) 60  Specify that it is an error for two parameters (including supplied-p
parameters) in the same lambda-list to have the same (EQL) name.  (An
alternative is to say that it is not an error, and the effective binding
order is from left to right, as you would expect from the rules for init
forms.  This is no worse than LET*, but somehow does not appeal to me.
A possible compromise is that no two required arguments may have the
same name.)

82 Have a function XOR of any number of arguments that returns T if an
odd number of its arguments are non-NIL, and otherwise returns NIL.
This complements AND and OR (but there is no point in making it a
special form as all arguments must be evaluated).

(*) 107 Clarify that GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE do
not perform macro-expansion on the given form, and that in most contexts
the usage should be (GET-SETF-METHOD (MACROEXPAND form env)).  Indeed,
the simplified example version of SETF given on page 108 should be
changed to:
(DEFMACRO SETF (REFERENCE VALUE &ENVIRONMENT ENV)
  (MULTIPLE-VALUE-BIND (...)
      (GET-SETF-METHOD (MACROEXPAND REFERENCE ENV))
    ...))
[Alternatively, we could specify that GET-SETF-METHOD should take an
environment as an additional, optional argument, but that would be a
change to the language rather than simply a clarification.]

(*) 113 Permit declarations before the body of a LABELS, FLET, or MACROLET.

(*) 120 In addition to DEFUN, the following macros should implicitly wrap a
BLOCK around their bodies: DEFMACRO, DEFSETF, DEFINE-SETF-METHOD, and
DEFTYPE.  This should be encouraged as a philosophy of style for
user-written macros.  Also, LABELS, FLET amd MACROLET should wrap
a block around the bodies of the locally defined functions.

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

(*) 130  Specify that it is an error for the same (EQL) tag to appear more
than once in the body of a TAGBODY.  (However, a TAGBODY may have the
same tag as another TAGBODY in which it nests, in which case the tag in
the outer TAGBODY is shadowed, as already specified.)

(*) 144 Delete the third paragraph of the description of MACRO-FUNCTION,
which specifies that MACRO-FUNCTION cannot be used to access macro
functions defined by MACROLET.  Change MACRO-FUNCTION to take an
optional environment argument so that it can get at macros defined by
MACROLET.  Specify that when SETF is used with MACRO-FUNCTION, only one
argument may be given to MACRO-FUNCTION.

(*) 145 Add a new function PARSE-BODY, taking arguments body, environment,
and documentation-allowed-p.  It pulls apart the body into three parts:
a list of DECLARE forms, a documentation string (or NIL if none), and
the body proper.  These are returned in the order body, declarations,
and doc-string as three values.  PARSE-BODY may perform macro-expansion
(using the given environment) in order to determine whether a macro-call
expands into a DECLARE form (or documentation string??).

145 Extend the syntax of an &BODY parameter to DEFMACRO to allow writing
&body (body-var [declarations-var [doc-string-var]]).  If only body-var
appears in parentheses, it means the same as a body-var with no
parentheses.  Otherwise, it means to give the original body to
PARSE-BODY (with documentation-allowed-p true iff the doc-string-var is
specified) and then bind the variables to the corresponding values
returned by PARSE-BODY.  This is purely a syntactic convenience for the
user of DEFMACRO so that he doesn't have to use &ENVIRONMENT and then
call PARSE-BODY himself.

(*) 145 Specify that the &REST or &BODY argument to a macro may be the very
list from the macro call, and not a copy, and therefore the user should
not perform destructive operations on it.  Similarly, a function that
takes as &REST argument should not destroy it because its top-level list
structure might might share with a list that the user gave as the last
argument to APPLY.

(*) 158 Specify that it is an error for more than one TYPE declaration for a
given variable to appear in a group of declarations (those all at the
head of the same body), or more than one FTYPE or FUNCTION declaration
for a given function name, or both an INLINE and a NOTINLINE declaration
for the same function.  Proclamations produce no such conflict; the
most recent proclamation supersedes all others.

(*) 159  Clarify that in the following example
(DEFUN FOO (X)
  (DECLARE (INLINE BAR))
  (BAR X)			    ;first
  (FLET ((BAR (Z) (BAR (+ Z 1))))   ;second
    (BAR X))			    ;third
  (BAR X))			    ;fourth
the first, second, and fourth calls to BAR are affected by the INLINE
declaration, but not the third one.

(*) 159 For consistency with the FUNCTION type specifier, change the
syntax of the FUNCTION declaration to (FUNCTION name arglist result-type)
with a note to the effect that types of multiple values are expressed as
(FUNCTION name arglist (VALUES result-type-1 result-type-2 ...)).

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

(*) 172  Revise the paragraph beginning ``As a verb'' to reflect the fact
that INTERN cannot take a symbol, only a string.  One ought to speak of
interning a name in a package, producing a symbol.

186  Modify the definition of IMPORT as follows:  if any symbol to be
imported has no home package, then IMPORT sets the home package of the
symbol to the specified package being imported to.

(*) 187  Modify description of DO-SYMBOLS to specify that it may execute the
body more than once for some symbols.

(*) 202 Define (LCM) to return 1 (the manual is incorrect in claiming that
the result should be infinity).

212 Change the branch cuts of the ATAN function to follow W. Kahan's
recommendations.  (Paul Penfield intends to recommend the same change to
the APL community.)

226 Add a function SIGNED-LDB that is like LDB but sign-extends the
extracted byte.

239 Change CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP,
CHAR-NOT-LESSP, and CHAR-NOT-GREATERP to consider two characters to be
different if their bits attributes are different.

249 What is the effect of giving circular lists to MAP, MAPCAR, SOME,
EVERY, etc.?  Specify that there is an error?  Is it good style to write
(MAPCAR \#' CONS X (STAR Y)) for (MAPCAR \#' (LAMBDA (Z) (CONS Z Y)) X)
where (DEFUN START (X) (RPLACD X X) X)?  I recommend that this be
considered an error.

268 Have a function COPY that can copy any single object.  For a
structure, it would use the user-specified copy function, if any.  For a
CONS cell it would copy just that CONS.  Whether (EQ X (COPY X)) for X a
character or number is implementation-dependent.

(*) 275  Clarify that (TAILP NIL X) returns NIL for all lists X.  The second
sentence in the description of TAILP is incorrect.

283 Functions HASH-TABLE-REHASH-SIZE, HASH-TABLE-REHASH-THRESHOLD,
HASH-TABLE-SIZE, and HASH-TABLE-TEST each take a hash table and return
the appropriate current information.

(*) 293 Add a function ROW-MAJOR-AREF, taking an array and a single
subscript, that accesses an array element according to the row-major
ordering.  Add a function DISPLACED-ARRAY-P, which takes an array and
returns NIL and 0 if it is not displaced or the array displaced to and
the displaced-index-offset if it is displaced.  These allow certain code
efficiencies, and also allow array displacement to be explained in
terms of Lisp primitives:
(DEFUN AREF (ORIGINAL-ARRAY &REST SUBSCRIPTS)
  (LABELS ((FOO (ARRAY INDEX)
	     (MULTIPLE-VALUE-BIND (NEW-ARRAY OFFSET) (DISPLACED-ARRAY-P ARRAY)
	       (IF (NULL NEW-ARRAY)
	           (ROW-MAJOR-AREF ARRAY INDEX)
		   (MULTIPLE-VALUE-CALL #'FOO
		                        NEW-ARRAY
					(+ INDEX OFFSET)))))
      (FOO ORIGINAL-ARRAY
	   (APPLY #'ARRAY-ROW-MAJOR-INDEX ORIGINAL-ARRAY SUBSCRIPTS))))
As a bow to efficiency, note the fact that if array A is displaced to B
with offset M, and B is displaced to C with offset N, and B is not
adjustable, then DISPLACED-ARRAY-P of A might return either array B with
offset M or array C with offset (+ M N).  This generalizes to chains
of non-adjustable arrays.

(*) 295 Specify that ADJUST-ARRAY is another important exception to the
general rule about operating only on active elements of arrays.
(See proposed clarifications of ADJUST-ARRAY.)

(*) 297 Here are the interactions of ADJUST-ARRAY with displacement.
Suppose we are adjusting array A, which is perhaps displaced
to B before adjustment and perhaps to C after adjustment.
(1) Not displaced before or after.  The dimensions of A are altered, and
the contents rearranged as appropriate.  Additional elements of A are
taken from the :initial-element.  The use of :initial-contents causes
all old contents to be discarded.
(2) Not displaced before, but displaced afterwards to C.  As already
specified, none of the original contents of A appears in A afterwards,
but rather the contents of C without any rearrangement of C.
(3) Displaced beforehand to B, and afterward to C.  As in case (2), no
contents of B appear in A afterward.  If :DISPLACED-INDEX-OFFSET is not
specified in this case, it defaults to zero; the old offset (into B) is
not retained.
(4) Displaced beforehand to B, but not displaced afterward.  A gets a
new "data region", and contents of B are copied into it as appropriate
to maintain the existing old contents; additional elements of A are
taken from the :initial-element.  However, the use of :initial-contents
causes all old contents to be discarded.

(*) 297 Specify that the fill pointer is ignored for the purposes of
deciding whether a given element of a new array resulting from
ADJUST-ARRAY should take its value from the old array contents or from
the specified :INITIAL-ELEMENT.

(*) 307  Allow a call to DEFSTRUCT to have no slot-descriptions.

(*) 307  Specify that it is an error for two slots in a single DEFSTRUCT
to have the same name.  If structure A includes structure B, then
no additional slot of A may have the same name as any slot of B.

(*) 321 Modify EVAL to have an optional environment argument.

(*) 322  At end of second paragraph on *APPLYHOOK*, clarify that the apply
hook function is not used when special forms are evaluated.

(*) 328 Remove the requirement that *STANDARD-INPUT*, etc., must be
initially bound to synonym streams to *TERMINAL-IO*; demote this to the
level of an implementation suggestion.  This is to allow flexibility of
implementation, for example to allow UNIX [TM and all the usual
deferences that people for some reason pay to UNIX but not to Kleenex or
Coke or Star Wars] redirection to win.  (I don't mind noting the
trademark status of UNIX; it just bugs me that people who do so are not
so consistently diligent about other trademarks.)

425  Generalize FILE-LENGTH to accept any filename, not just an open
file-stream.  Let it take a keyword argument :ELEMENT-TYPE, defaulting
to STRING-CHAR for non-stream arguments and to the element-type of the
stream for a stream argument.

(*) 439 Clarify that if DISASSEMBLE is given a symbol whose function
definition is interpreted, that definition is indeed compiled and
then disassembled, but the resulting compiled definition does not
replace the interpreted one as the symbol's function definition.

439 COMPILEDP takes a function and returns non-NIL if it is a compiled
function, and NIL if it is not.  If the function is a symbol whose
compiled-function definition was installed by the COMPILE function, then
the non-NIL value returned is the interpreted definition that was
compiled.

439 UNCOMPILE takes a symbol and restores the previous interpreted
definition of that symbol if that symbol previously had an interpreted
definition and was then given to COMPILE; otherwise no action is taken.

440 Specify explicitly that one may trace macros as well as functions
(but not special forms).

(*) 443  Modify description of APROPOS to replace the words ``available in''
to ``accessible in,'' and specify that APROPOS on a given package finds
the same symbols that DO-SYMBOLS would.

447 The USER-NAME function returns a string identifying the user of the
Common Lisp system, or NIL if that cannot be determined.

∂13-Dec-85  1217	gls@THINK-AQUINAS.ARPA 	Typographical corrections to Common Lisp book 
Received: from THINK.COM by SU-AI.ARPA with TCP; 13 Dec 85  12:17:06 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Fri, 13 Dec 85 15:16:58 est
Date: Fri, 13 Dec 85 15:16 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Typographical corrections to Common Lisp book
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <851213151656.2.GLS@THINK-JEHOSEPHAT.ARPA>

The following is the text, verbatim, of the other handout I made
available this past Monday at the Common Lisp meeting.

----------------------------------------------------------------------
Corrections to first printing of  Common Lisp: The Language
Thanks to the many people who noticed these problems, and
especially to Dr. Masayuki Ida, who found over fifty of them.
				-- Guy Steele, December 1985


6  line 4 from bottom:  Definition 1-1 => Table 1-1

7  line 2 from bottom:  Definition 1-2 => Table 1-2

8  line 3   Definition 1-3 => Table 1-3

8  line 7   Definition 1-4 => Table 1-4

8  line 9 from bottom:  Definition 1-5 => Table 1-5

9  line 17  A\( B => A\(B  (blank should be deleted)

9  Under \, "a symbol whose name is consists of the" =>
"a symbol whose name consists of the".

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

20 line 1   "#,"  (bad printing)

35 line 12  "where x is subtype of common" => "where x is a subtype of common"

43  Table 43-1 should include the names "signed-byte" and "unsigned-byte".

44  Delete both compatibility notes.

67  "The defun special form" => "The defun macro"

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".

69 Clarify that EVAL-WHEN returns the value of the last form in its body.

73 In the compatibility note, observe that Common Lisp ATOM corresponds
to Interlisp NLISTP.

75 line 5 from bottom:  vectorp => simple-vector-p

80 Delete the first compatibility note.

87 Rewrite the second sentence in the description of FUNCTION as
follows:  "In particular, if fn is a symbol, then the functional
definition of that name is returned, which is that established by the
innermost lexically enclosing FLET, LABELS, or MACROLET construct, if
there is one, or else the global functional definition of the symbol
(see SYMBOL-FUNCTION)."

92 line 13  setf => psetf

94 line 11 from bottom:  "newvalue2)" => "newvalue2"

99 line 8    place => place1

99  In first line of second paragraph, delete the italicized word "newvalue".

108 In the compatibility note, observe that Interlisp APPLY*, unlike
Common Lisp FUNCALL, can be used to apply special forms.

118 In the compatibility note, observe that Interlisp SELECTQ has
a syntax different from that of Common Lisp CASE in having a separate
trailing "else" form.

122 line 2 from bottom:  "init" should be italic

122 line 1 from bottom:  "var" should be italic

125 Line 9: Delete first sentence and replace with: "As an example of
nested loops, consider a data structure that is a list of conses."
(Remove spurious reference to "env".)

128 Delete compatibility note.

132 line 15 from bottom: "Mismatch-gleep!S" => "Mismatch-gleep!~S"

132 line 2 from bottom:  (same as P132 B15L)

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.

154 Add to the table of forms allowing declarations in their bodies
WITH-OPEN-STREAM, WITH-OPEN-FILE, WITH-OUTPUT-TO-STRING, and
WITH-INPUT-FROM-STRING.

157  In third line, "declaration-form" should be "decl-spec" (in italics).

159  After the line "... entirely equivalent to" the next line should read
(ftype (function arglist (values result-type-1 result-type-2 ...)) name)

189 In the code comments, "just a few thing" => "just a few things".

190 In LEAD-TO-GOLD, "(phlogiston:heat-flow x)" =>
"(phlogiston:heat-flow 1/137 x x)".

191 Before HEAT-FLOW definition, insert "(DEFVAR *FEELING-WEAK* NIL)"
and rename FEELING-WEAK => *FEELING-WEAK*.  (Actually, maybe we can come
up with a more realistic example of two modules for the next edition.)

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)."

205 line 7 from bottom:  "x" should be italic

206 line 5   "number" should be italic

206 line 7   "x" should be italic

209 Delete the last two sentences of the compatibility note, as the
information about Interlisp is not (or is no longer) correct.

214 line 1 from bottom:  "x" should be italic

215 line 2   "x" should be italic

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))) ...".
[Actually, it would be better to rewrite this whole section, but this
fix at least makes it accurate.]

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

222 Occurrences of "logiorc1" and "logiorc2" should be "logorc1" and
"logorc2".

226  In definition of haipart, the occurrence of "n" should be "count".

227 line 8 from bottom:  "dpb" => "deposit-field"

230  In second line of description of make-random-state, the
occurrence of random-state should be make-random-state.

246 line 13  "item" and "seq" should be italic, and "seq" => "sequence"

265 line 12  "'a b c" => "'a 'b 'c"

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.

283 In the last sentence of the compatibility note, replace the last
clause with "and in Common Lisp the cases of NIl as a value and no
entry in the hash table can be distinguished."

284  "means the approximately the same as" => "means approximately the
same as"

287  In the last line, :type should be :element-type.

295  In example use of bit-andc1, result should be #*0010, not #*0100.

297 Clarify that if an array with a fill pointer is adjusted and no new
:FILL-ARRAY specification is given, or one is given with the value T,
then the fill pointer retains its old value.  It is an error to adjust
the array to be smaller than the (old or explicit new) fill pointer.
If one specifies :FILL-POINTER NIL explicitly to ADJUST-ARRAY, then it
is an error if the array to be adjusted does have a fill pointer.

301 Change the compatibility note to "string= is similar to the
Interlisp function strequal."

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.

315  Under ":type list", ":unnamed" => "not :named".

323 line 19  "applications." => "applications,"

324  In the second and third lines, replace "2" with "3".

325  The name of the variable "-" does not appear in the header line.

344 In the compatibility note, delete the reference to the Interlisp
RADIX function, and move it to page 372 as a comment on the
*print-radix* variable.

348 line 1   horizontal line should be moved to before compatibility note.

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

357  All occurrences of "constructor macro" should read "constructor function".

365  "The user is encouraged to" => "The user may, for some applications,
wish to".

373  Third and sixth lines from bottom: "print-array" in monospace should
be "*print-array*".

394  "~Scale factor" => "~%Scale factor"

394 "(- k 5) 3.14159))" => "(- k 5) (- k 5) 3.14159))"

396  Fourth line: "x x x))" => "x x x x))"

396  Line 12: "314.2$+10" => "314.0$+10" and "3.14L+12" => "3.14E+12"

412 line 20  version. => version).

422 Observe that if :IF-EXISTS NIL or :IF-DOES-NOT-EXIST NIL is used
with WITH-OPEN-FILE then the variable may be bound to NIL, and the
body should test for this case before attempting to use the stream.

430  The sixth line on the page should be "(funcall fn)", not "(funcall fn))".

432 "*break-on-warnings" should be "*break-on-warnings*" (in the heading
for that item).

437 The first argument to CCASE should be called "keyplace", not "keyform".

440 line 3   [function] in the right margin.

449  Replace reference 9 with a reference to the following:
IEEE Standard for Binary Floating-Point Arithmetic
ANSI/IEEE Std 754-1985 (approved July 26, 1985)
IEEE, 345 E 47 St. NY, NY 10017  (stock number SH10116 price $6.50)

452 right column, line 27 from bottom: (entry for characters,
macros) 246-351 => 346-351

454  In index entry for "defun", first page number should be 67, not 57.

458  Entry for function "keyword" should be for "keywordp".

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".

459 left column, line 19 from bottom: "parsing" => "passing"

459 left column, line 9 from bottom: 1325 => 135

461 right column, column, line 18 from bottom:  replacd => rplacd

462 First reference to "shadow function" should be 186-187, not 182-183.

463 left column, line 26 from bottom:   382;420 => 332;420

463 left column, line 21 from bottom:   comparison 300-306 => 300-302

464 "unread char function" => "unread-char function"

465 right column, line 11   ~: => ~|

465 right column, line 12   :~ => ~;

465 right column, line 20 from bottom:  >E => ~E

465 right column, line 19 from bottom:  >F => ~F

[END]

∂13-Dec-85  1320	gls@THINK-AQUINAS.ARPA 	Clarification Comments (long)  
Received: from THINK.COM by SU-AI.ARPA with TCP; 13 Dec 85  13:19:55 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Fri, 13 Dec 85 16:19:46 est
Date: Fri, 13 Dec 85 16:19 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Clarification Comments (long)
To: shebs%utah-orion@UTAH-CS.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <8512131955.AA23353@utah-orion.ARPA>
Message-Id: <851213161945.4.GLS@THINK-JEHOSEPHAT.ARPA>

A few comments on the comments from SHEBS:

    47 This is OK, although it feels a little uncomfortable to include the
    name of a local keyword variable in a proclamation that may be in
    another file.  Bye bye alpha conversion...

The example was poorly chosen.  The name of the local keyword variable
can be anything, but is normally the same (but in a different package)
as the name of the keyword that the caller needs to use.  Perhaps the
example should have read
(DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY (:FROM-END T)
			   (:START (INTEGER 0 ())) (:END (INTEGER 0 ()))
			   (:INITIAL-VALUE T))
			  T)
		REDUCE)
Now that I think of it, I was trying to follow the rule that the
declaration should look like the parameter list, but with types
substituted for the variable names and with init forms (and supplied-p
parameters) omitted.  It is tempting to use the flatter syntax
(DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY :FROM-END T
			   :START (INTEGER 0 ()) :END (INTEGER 0 ())
			   :INITIAL-VALUE T)
			  T)
		REDUCE)
but that confuses call syntax with parameter-list syntax.  Now that I have
enunciated the principle, I now see that the truly consistent syntax
is not either of the two example above; to match parameter-list syntax
exactly another level of parentheses is needed:
(DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY ((:FROM-END T))
			   ((:START (INTEGER 0 ()))) ((:END (INTEGER 0 ())))
			   ((:INITIAL-VALUE T)))
			  T)
		REDUCE)
These extra parentheses could be unambiguously elided in type specifiers,
but the corresponding parentheses may not be elided in parameter lists.

    130 I didn't realize until now that tagbody does have a restriction
    on body contents.  That seems wrong to me.  Presumably lots of things
    will macroexpand into tagbodies, and every one inherits the same
    restriction.  Worse, one implementation's dolist will macroexpand
    into a tagbody, while in another, it will be a special form.  Why
    not say that integers and symbols are tags, and everything else is
    a form? Or that all non-lists are tags?

But all objects other than symbols and lists are either constants or
erroneous when treated as forms.  Someone has suggested that strings be
permitted in a TAGBODY as comments.  I don't think we want
floating-point tags.

    186 Doesn't seem *wrong*, but not clear why one can't explicitly test
    symbol-package and intern instead.  Sounds like a frob.

INTERN cannot take a symbol, only a string.

    239 This one seems really unmotivated - why the bits and not the
    font anyway?  Perhaps we could add keywords to char comparison
    to tell which parts of the char are to be considered :-)

The book already specifies that the fonts may or may not be
examined, depending on the implementation, and an example is
given to explain why.

    439 This constrains the implementation to save source code somewhere,
    which is more of a nuisance than a hardship.  This is really another
    one of those user convenience things.

Yes, it's "just" a convenience.  Only COMPILE is so constrained; files
produced by COMPILE-FILE are not required to retain the source code
as well for later loading.

    440 Sure, with the same proviso as for inline functions, that a macro
    call may not be traceable because it's been expanded already.

Good point.

∂13-Dec-85  1401	shebs%utah-orion@utah-cs.arpa 	Re:  Clarification Comments (long)
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 13 Dec 85  14:01:26 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
	id AA02288; Fri, 13 Dec 85 15:01:05 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
	id AA24274; Fri, 13 Dec 85 15:00:55 MST
Date: Fri, 13 Dec 85 15:00:55 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8512132200.AA24274@utah-orion.ARPA>
To: gls@aquinas.think.com
Subject: Re:  Clarification Comments (long)
Cc: common-lisp@su-ai.arpa

Comments on comments on comments on clarifications:

    Date: Fri, 13 Dec 85 16:19 EST
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>
    
        47 This is OK, although it feels a little uncomfortable to include the
        name of a local keyword variable in a proclamation that may be in
        another file.  Bye bye alpha conversion...
    
    The example was poorly chosen.  The name of the local keyword variable
    can be anything, but is normally the same (but in a different package)
    as the name of the keyword that the caller needs to use.  Perhaps the
    example should have read
    (DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY (:FROM-END T)
    			   (:START (INTEGER 0 ())) (:END (INTEGER 0 ()))
    			   (:INITIAL-VALUE T))
    			  T)
    		REDUCE)
    Now that I think of it, I was trying to follow the rule that the
    declaration should look like the parameter list, but with types
    substituted for the variable names and with init forms (and supplied-p
    parameters) omitted.  It is tempting to use the flatter syntax
    (DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY :FROM-END T
    			   :START (INTEGER 0 ()) :END (INTEGER 0 ())
    			   :INITIAL-VALUE T)
    			  T)
    		REDUCE)
    but that confuses call syntax with parameter-list syntax.  Now that I have
    enunciated the principle, I now see that the truly consistent syntax
    is not either of the two example above; to match parameter-list syntax
    exactly another level of parentheses is needed:
    (DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY ((:FROM-END T))
    			   ((:START (INTEGER 0 ()))) ((:END (INTEGER 0 ())))
    			   ((:INITIAL-VALUE T)))
    			  T)
    		REDUCE)
    These extra parentheses could be unambiguously elided in type specifiers,
    but the corresponding parentheses may not be elided in parameter lists.

I like the last solution (without the extra parens!).
    
        130 I didn't realize until now that tagbody does have a restriction
        on body contents.  That seems wrong to me.  Presumably lots of things
        will macroexpand into tagbodies, and every one inherits the same
        restriction.  Worse, one implementation's dolist will macroexpand
        into a tagbody, while in another, it will be a special form.  Why
        not say that integers and symbols are tags, and everything else is
        a form? Or that all non-lists are tags?
    
    But all objects other than symbols and lists are either constants or
    erroneous when treated as forms.  Someone has suggested that strings be
    permitted in a TAGBODY as comments.  I don't think we want
    floating-point tags.

After poring over the book, it seems that it is specified as to which things
have tagbodies and which do not.  I have no problem with this clarification
then.

        186 Doesn't seem *wrong*, but not clear why one can't explicitly test
        symbol-package and intern instead.  Sounds like a frob.
    
    INTERN cannot take a symbol, only a string.
    
OK, OK, so I left out a step...  I still don't understand why import needs
extra features - is it just to prevent what would otherwise be an error?

        239 This one seems really unmotivated - why the bits and not the
        font anyway?  Perhaps we could add keywords to char comparison
        to tell which parts of the char are to be considered :-)
    
    The book already specifies that the fonts may or may not be
    examined, depending on the implementation, and an example is
    given to explain why.

Now that I look at the book, it all makes sense.  Yes, bits should be
considered, in an implementation-dependent manner.

							stan

∂13-Dec-85  1606	REM%IMSSS.#Pup@SU-SCORE.ARPA 	What about advising special forms? 
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 13 Dec 85  16:06:17 PST
Received: from IMSSS by Score with Pup; Fri 13 Dec 85 15:46:50-PST
Date: 13 Dec 1985 1545-PST
From: Rem@IMSSS
Subject: What about advising special forms?
To:   COMMON-LISP%SU-AI@SCORE

A common debugging technique is to advise a function by splicing some
I/O code or case-checking code between the function name and the code
in its function cell. The most common example is tracing a function.
One common implementation is to make up a funny name and copy the code
pointer into that new function cell, and then make the original function
cell point to a piece of code that does the advising and calls the
new-name function. Are we saying in CL we can't ever advise (trace etc.)
a special operator because we can't be sure that
(SETF (FUNCTION-CELL 'FUNNY-NAME) (FUNCTION-CELL 'ORIGINAL-SPECIAL-OPERATOR))
will work at all in the interpretor?
-------

∂13-Dec-85  1703	Moon@SCRC-STONY-BROOK.ARPA 	Re: Special Form Question  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Dec 85  17:02:57 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 374163; Fri 13-Dec-85 19:26:59-EST
Date: Fri, 13 Dec 85 19:22 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: Special Form Question
To: NGALL@BBNG.ARPA
cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <[BBNG.ARPA]13-Dec-85 13:56:25.NGALL>
Message-ID: <851213192202.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 13 Dec 1985 13:56-EST
    From: NGALL@BBNG.ARPA
    ....If this "strange object" is to be completely unspecified, then the
    section of the defintion of special-form-p (pg. 91) that DOES specify
    what this strange object "typically" is, should be made an
    Implementation Note.

special-form-p is not the same function as symbol-function and does not
(necessarily) return the same strange unspecified objects.

∂13-Dec-85  1846	FAHLMAN@C.CS.CMU.EDU 	What about advising special forms?    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Dec 85  18:46:32 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 13 Dec 85 21:46:17-EST
Date: Fri, 13 Dec 1985  21:46 EST
Message-ID: <FAHLMAN.12166919735.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Rem @ MIT-MC.ARPA
Cc:   COMMON-LISP@SU-AI.ARPA
Subject: What about advising special forms?
In-reply-to: Msg of 13 Dec 1985  18:45-EST from Rem at IMSSS


    Are we saying in CL we can't ever advise (trace etc.)
    a special operator because we can't be sure that
    (SETF (FUNCTION-CELL 'FUNNY-NAME)
          (FUNCTION-CELL 'ORIGINAL-SPECIAL-OPERATOR))
    will work at all in the interpretor?

We are saying that the ability to advise (trace etc) special forms is
not something that you can do in a strictly portable way, depending on
the above sort of replacement.  Implementations that want to provide
this facility are free to do this if it happens to be feasible.  One
cannot just call the normal TRACE function on a special form in any
event, since the handling of arguments is different and since the trace
is liable to get into an infinite loop if you don't take some care to
prevent this.  So I see no great loss in saying that this case will not
work in general.

-- Scott

∂13-Dec-85  1903	FAHLMAN@C.CS.CMU.EDU 	Re: Special Form Question   
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Dec 85  19:02:35 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 13 Dec 85 22:02:13-EST
Date: Fri, 13 Dec 1985  22:02 EST
Message-ID: <FAHLMAN.12166922635.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   NGALL@BBNG.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: Re: Special Form Question
In-reply-to: Msg of 13 Dec 1985 13:56-EST from NGALL@BBNG.ARPA


        I think the best position to take is the following: Symbols that name
        special forms do have symbol-function slots, just like any other symbol.
    Wrong.  A CL symbol does not have a function as a "user-visible
    component" (i.e., slot; cf. pg. 163).  Since CLtL goes out of its way
    to point this out, I think it is a good idea to not slip back into
    definition by implementation (are any implementtations NOT using
    function cells?).

All right, on page 163 it says that Symbol-function is not necessarily a
slot in the symbol object, but on page 90 it says that symbol-function
returns an object that "may be a function or may be an object
representing a special form or macro".  However, it is an error if you
try to invoke an object of the latter kind as a function.  I think that
this is consistent with the behavior I suggested, though I should not
have referred to Symbol-Function as fetching something from a slot.

If we decide to go with this description of the required behavior, some
wording on page 9 needs to be clarified.  It says that a error IS
SIGNALLED if you do Symbol-Function on a symbol with no funciton
definition, but then seems to indicate that this error would not be
signalled if the definition is a macro or special form.  Alternatively,
we could specify that the error is signalled unless the symbol defines a
function in the strict sense, but if we do that a lot of implementaitons
would have to be fixed in ways that might hurt efficiency.

-- Scott

∂13-Dec-85  2146	RAM@C.CS.CMU.EDU 	list of proposed changes to Common Lisp   
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Dec 85  21:46:35 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sat 14 Dec 85 00:46:29-EST
Date: Sat, 14 Dec 1985  00:46 EST
Message-ID: <RAM.12166952525.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   Guy Steele <gls@AQUINAS.THINK.COM>
Cc:   common-lisp@SU-AI.ARPA
Subject: list of proposed changes to Common Lisp
In-reply-to: Msg of 13 Dec 1985  15:15-EST from Guy Steele <gls at THINK-AQUINAS.ARPA>

    (*) 107 Clarify that GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE do
    not perform macro-expansion on the given form, and that in most contexts
    the usage should be (GET-SETF-METHOD (MACROEXPAND form env)).  Indeed,
    the simplified example version of SETF given on page 108 should be
    changed to:
    (DEFMACRO SETF (REFERENCE VALUE &ENVIRONMENT ENV)
      (MULTIPLE-VALUE-BIND (...)
	  (GET-SETF-METHOD (MACROEXPAND REFERENCE ENV))
	...))
    [Alternatively, we could specify that GET-SETF-METHOD should take an
    environment as an additional, optional argument, but that would be a
    change to the language rather than simply a clarification.]

This won't work, as it prohibits defining setf methods for macros.
GET-SETF-METHOD needs the environment so that it can expand macros one
level at a time, checking if the result has a setf method.  I also
suggest that the environment argument not be optional, as any user
code which doesn't supply it is surely broken.

    268 Have a function COPY that can copy any single object.  For a
    structure, it would use the user-specified copy function, if any.  For a
    CONS cell it would copy just that CONS.  Whether (EQ X (COPY X)) for X a
    character or number is implementation-dependent.
What does this function do in the presence of displaced and adjustable
arrays?  Are these attributes preserved, or is the result just
structurally identical?  How about a COPY-ALL function which descends
into structure until it finds something not needing to be copied?

    I have some of my own unclarities and clarifications:

If we're allowed to clarify things by adding new functions, then I
propose my own: a structural equality predicate.  It descends into
arrays and structures, but compares leaves with EQL.  This is what
EQUAL should have been, but couldn't for hysterical reasons.
("Descending into arrays is too inefficient.", to which I reply "Not
if you want to compare arrays.")  As far as equality predicates go,
arrays are still second-class citizens of the language.

312 It should be explicitly noted somewhere that defstruct copiers
work on structures which are a subtype by inclusion, e.g. COPY-PERSON
works on an astronaut.  This is a natural consequence of the subtype
semantics of inclusion, but isn't necessarily obvious to pea-brained
implementors.

416 I think that the DEFAULTS argument to MAKE-PATHNAME should be
allowed to be an arbitrary thing, rather than being constrained to
being a pathname.  All other pathname args can be any thing accepted
by PATHNAME.

413,424 The semantics of TRUENAME and PROBE-FILE on open streams
needs to be clarified.  The requirement that PROBE-FILE never return
NIL on an open file is clearly broken.  Spice Lisp currently
implements TRUENAME and PROBE-FILE in the same way, except that
TRUENAME errors instead of returning NIL.  Someone (Moon, I believe)
suggested that (PROBE-FILE <stream>) was the same as 
(PROBE-FILE (PATHNAME <stream>)), but that (TRUENAME <stream>) was
somehow different.  There also needs to be some discussion of the
meaning of operations on closed streams.  The manual never says which
operations may be done on closed streams, let alone what the
operations do.

410 There should be some clarification of what can be expected from
implementations where some of the pathname components are meaningless,
i.e. host and version.  Must these fields actually exist in the
pathname object?  What must the operations do with these fields?

419 Are implementations really required to support all those element
types?  (signed-byte 1234567)?  I guess arbitrary restrictions would
be allowed by the implementation note on 421, but it doesn't really
apply here.  It is possible in any filesystem to implement I/O of all
these things.  The question is whether it's worth the effort.

419 I believe that everyone agreed that :DIRECTION :PROBE was silly
and should be flushed.

438 There should be some discussion of the semantics of compilation on
literal constants (things appearing in quoted structure in code).
 1] What types of objects may be constants?  Surely not any, as some
    implementations find it impossible to dump things such as compiled
    function objects.
 2] To what degree is sharing and non-sharing preserved?  Many
    implementations both introduce and remove sharing.  Probably most
    don't dump circular structures.
 3] How does symbol dumping and loading work?

Since the reference model for compilation is that "it may run faster",
it seems that ideally the semantics of loading a compiled file should
be indentical to those of loading the source.  This goal is
unrealistic, since the reading of the source by the compiler loses
information.  A better model is that compilation and loading should be
similar to printing and reading again.  This is probably excessively
restrictive, but may also be too liberal in that it suggests that
circular structures can be dumped.

  Rob

∂14-Dec-85  1752	edsel!eb@su-navajo.arpa 	Undoing global side-effects   
Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 14 Dec 85  17:52:27 PST
Received: by su-navajo.arpa with Sendmail; Sat, 14 Dec 85 17:49:43 pst
Received: by edsel.uucp (2.2/SMI-2.0)
	id AA01705; Sat, 14 Dec 85 17:40:07 pst
Date: Sat, 14 Dec 85 17:40:07 pst
From: edsel!eb@su-navajo.arpa (Eric Benson)
Message-Id: <8512150140.AA01705@edsel.uucp>
To: navajo!Common-Lisp@SAIL
Subject: Undoing global side-effects

I went through the Common Lisp manual looking for functions which have
global side-effects and came up with the following list, along with
suggested functions for removing those side effects:


PROCLAIM SPECIAL
DEFVAR
DEFPARAMETER
  These should all be undoable by MAKUNBOUND and an UNSPECIAL
proclamation.  UNSPECIAL should be restricted to use in PROCLAIM and not
allowed in DECLARE.  This will prevent a major incompatible change in
declaration processing.

DEFCONSTANT
  DELETE-CONSTANT should make a symbol unbound, unspecial and
inconstant (yes, it's a real English word).

DEFUN
DEFMACRO
SETF of SYMBOL-FUNCTION
SETF of MACRO-FUNCTION
  These are undone by FMAKUNBOUND.  In some implementations, DEFUN and
DEFMACRO record information other than the function definition.  Since
this is outside the scope of Common Lisp, the language standard need not
include a way to undo it.

DEFSETF
DEFINE-SETF-METHOD
  These are undone by the DELETE-SETF-METHOD function previously
described.

DEFTYPE
  The DELETE-TYPE function should undo this.  It should signal an error
if any other type is a subtype of the specified type.  It "is an error"
to DELETE-TYPE any of the built-in Common Lisp types.

DEFSTRUCT
  There ought to be a DELETE-DEFSTRUCT function which undoes all the
effects of the DEFSTRUCT, by removing all function definitions
(including compiler database entries for inline compilation), removing
any type database entry, removing the :PRINT-FUNCTION entry, and
removing any information from DEFSTRUCT's own database (that which
allows a name to be used in the :INCLUDE option).  It should signal an
error if any other structure type has :INCLUDEd the given type (unless
that structure type has also been deleted).

MAKE-PACKAGE
  This is undone by the DELETE-PACKAGE function previously described.

SHADOW
  Document the fact that SHADOW can be undone by UNINTERN, causing any
otherwise inherited symbol to become accessible again.

SETF of DOCUMENTATION
SET-MACRO-CHARACTER
SET-DISPATCH-MACRO-CHARACTER
  These should all be undoable by using NIL as the new value.  This must
be documented.


Thus there are five new functions
DELETE-PACKAGE
DELETE-SETF-METHOD
DELETE-CONSTANT
DELETE-TYPE
DELETE-DEFSTRUCT
and one new proclamation, UNSPECIAL.  It doesn't seem to me to be worth
inventing some new SETF-like meta-deletion macro to handle these.  If we
like this naming convention it might a good idea to add the names
DELETE-VALUE and DELETE-FUNCTION as synonyms for MAKUNBOUND and
FMAKUNBOUND, eventually phasing out the latter names.

∂14-Dec-85  1953	edsel!eb@su-navajo.arpa 	Questions, comments and clarifications on clarifications    
Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 14 Dec 85  19:53:24 PST
Received: by su-navajo.arpa with Sendmail; Sat, 14 Dec 85 19:50:34 pst
Received: by edsel.uucp (2.2/SMI-2.0)
	id AA01849; Sat, 14 Dec 85 18:30:16 pst
Date: Sat, 14 Dec 85 18:30:16 pst
From: edsel!eb@su-navajo.arpa (Eric Benson)
Message-Id: <8512150230.AA01849@edsel.uucp>
To: navajo!Common-Lisp@SAIL
Subject: Questions, comments and clarifications on clarifications

82.  Is it gratuitous pseudo-generality to allow an arbitrary number of
arguments to XOR, instead of requiring exactly two?  Give an example.

107.  GET-SETF-METHOD should definitely take an optional environment
argument.  Calling MACROEXPAND is seldom a good thing to do in a
program, even a compiler, since there may be intermediate macros which
require special handling.  In this case an intermediate macro may have a
setf method.  Even though a user program is probably incorrect if it
does not supply the environment argument to GET-SETF-METHOD, we should
make it optional for maximum compatibility with the existing standard.

Along with allowing an optional environment argument to GET-SETF-METHOD,
it is important to allow DEFINE-SETF-METHOD to take an &ENVIRONMENT
argument.  It is also important that macros defined with
DEFINE-MODIFY-MACRO correctly pass the environment to GET-SETF-METHOD;
this belongs in an implementation note.

A hard question: Does MACROLET shadow a setf method or not?

(DEFUN LOSER (X)
  (CAR X)

(DEFUN SET-LOSER (X Y)
  (SETF (CAR X) Y))

(DEFSETF LOSER SET-LOSER)

(DEFUN LOSSAGE (X Y)
  (MACROLET ((LOSER (X)
	       `(SYMBOL-VALUE ,X)))
    (SETF (LOSER X) Y)))

Does LOSSAGE call SET-LOSER or SET?

130.  I think it is better to say that anything other than a symbol or
an integer at the top level in a TAGBODY is evaluated normally, rather
than having special rules.  This is not a major point, however.

144. Can an FLET shadow a DEFMACRO?

(DEFMACRO FOO ()
  )

(DEFUN BAR ()
  (FLET ((FOO () ...))
    (MACROLET ((BAZ (&ENVIRONMENT ENV)
		 (IF (MACRO-FUNCTION 'FOO ENV)
		     "Lose"
		     "Win")))
      (BAZ))))

Does (BAR) return "Win" or "Lose"?  (See if you can guess what I think
it should do.)

268.  There's no need to mention that COPY uses the user-specified copy
function for structures, since the user only specifies a @i(name) for the
function; the system supplies the definition.

Along the same lines, there really should be a true structural equality
comparison function, i.e. a case-sensitive EQUALP, or EQUAL which
descends into arrays and structures.  It would also be nice to have a
graph isomorphism comparison function, but perhaps this is beyond the
scope of Common Lisp.  I only brought it up because it cannot be written
portably so that it descends into all structures.  How about graph
isomorphism modulo gensyms?

293.  ROW-MAJOR-AREF should be SETFable.

295.  Also include SETF of AREF, ROW-MAJOR-AREF, and SETF of
ROW-MAJOR-AREF among the functions which can access beyond the fill
pointer of an array.

∂14-Dec-85  1953	edsel!eb@su-navajo.arpa 	More clarifications 
Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 14 Dec 85  19:53:28 PST
Received: by su-navajo.arpa with Sendmail; Sat, 14 Dec 85 19:50:43 pst
Received: by edsel.uucp (2.2/SMI-2.0)
	id AA01946; Sat, 14 Dec 85 18:55:35 pst
Date: Sat, 14 Dec 85 18:55:35 pst
From: edsel!eb@su-navajo.arpa (Eric Benson)
Message-Id: <8512150255.AA01946@edsel.uucp>
To: navajo!Common-Lisp@SAIL
Subject: More clarifications

Here are a couple more items which should be included in the
clarifications:

In the description of FUNCTIONP (p. 76) it says that FUNCTIONP is always
true of symbols.  Shouldn't that be changed to say that FUNCTIONP is
true of symbols for which FBOUNDP is true?

In the description of Decoded Time format (p. 444), the Time-zone
component is required to be an integer which is the number of hours west
of GMT.  (The latest term is Coordinated Universal Time, or UTC, by the
way).  Since time zones are not always an integral number of hours west
of GMT, this should be changed to either (a) a non-complex, non-negative
number which is the number of hours west of GMT, or (b) an integer which
is the number of {minutes, seconds} west of GMT.  My personal preference
is for (b) for ease of implementation, but (a) might be preferable for
compatibility with the existing standard.  On the other hand, most
programs dealing with time will probably want to deal with integral time
units.  Having the time zone bias introduce a ratio or a float by
contagion is probably undesirable.  Because of this, and because
Universal Time is defined in units of seconds, I believe the best course
is (b) with seconds, in spite of the incompatibility.  (There are 86400
seconds in 24 hours.)

∂15-Dec-85  1155	RAM@C.CS.CMU.EDU 	Another omission: global lexicals    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85  11:53:31 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 15 Dec 85 14:53:24-EST
Date: Sun, 15 Dec 1985  14:53 EST
Message-ID: <RAM.12167368856.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: Another omission: global lexicals


    It is truly silly that there is no way to define a global lexical
variable in Common Lisp.  Many places where defvar is used there is no
need for dynamic binding, since the variable is never bound.  If a
variable is known to be a global lexical then various optimizations
can be made which are otherwise impossible:
 1] A global lexical cannot be unbound, therefore there is no need to
    check that is bound before accessing it.
 2] Since it cannot be globally rebound, there is no need to search
    for the value in an implementation which deep-binds specials.
    This is significant since shallow-binding doesn't work in
    multi-processor implementations.

    A global lexical is also less dangerous to use than a global
special, since a global lexical doesn't magically specialify other
lexical uses of the same name.  Dynamic binding is overkill in many
applications.  I believe that programs would be clearer if it was more
obvious which variables are actually bound dynamically.

    It is also worth noting that it should be trivial to add global
lexicals to any implementation.  The value is kept in the global value
cell, just as for a special; the only difference is that there is no
special annotation.

    I suggest this syntax:  DEFGLOBAL <name> <value> [<doc-string>]

  Rob

∂15-Dec-85  1322	RPG   	[Richard Acuff <Acuff@SUMEX-AIM.ARPA>: Summary of Common Lisp meeting]   
 ∂14-Dec-85  1906	ACUFF@SUMEX-AIM.ARPA 	[Richard Acuff <Acuff@SUMEX-AIM.ARPA>: Summary of Common Lisp meeting]   
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 14 Dec 85  19:06:27 PST
Date: Sat 14 Dec 85 19:06:20-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: [Richard Acuff <Acuff@SUMEX-AIM.ARPA>: Summary of Common Lisp meeting]
To: rpg@SU-AI.ARPA
Message-ID: <12167185537.54.ACUFF@SUMEX-AIM.ARPA>

   Ok, here it is.  I'd appreciate any corrections or additions.  This
is rather thrown together, so pardon bad spelling and grammer.

	-- Rich
                ---------------

Mail-From: ACUFF created at 13-Dec-85 16:23:58
Date: Fri 13 Dec 85 16:23:54-PST
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Summary of Common Lisp meeting
To: common-lisp@SUMEX-AIM.ARPA
Message-ID: <12166893822.45.ACUFF@SUMEX-AIM.ARPA>

   The following is a report on the Common Lisp meeting held in Boston
from 9-Dec-85 to 11-Dec-85.  The following issues were addressed:
charter and validation, object oriented programming, error handling, and
windows.  I will attempt to summarize the sessions, though it is likely
that I've missed something.  If you have particular interest in one of
the areas, please contact Dick Gabriel (RPG@SAIL) to be placed on the
appropriate mailing list.  Also, all of the documents mentioned herein
are available for copying from me.

Charter
-------

   It was decided that the "gang of five", Guy Steele, Dick Gabriel,
Scott Fahlman, David Moon, and Dan Weinreb, plus Steve Squires of DARPA
and Bob Mathis (worked on ADA standardization and is familiar with ISO),
would start the task of moving Common Lisp (CL) towards ISO
standardization.  This was felt necessary in order to make Common Lisp
the international standard, especially since the French were proposing
an alternate Lisp standard.  This ad hoc committee is to set up and
charter a strategy committee which will work towards the above mentioned
standardization, and set policy for revision and interpretation of the
current language manual.  Another committee will be formed to see that
services needed by the CL community, such as maintaining a library (the
"yellow pages"), performing validation, distributing information,
maintaining archives, etc.  Discussion of these issues will continue on
the CL Charter mailing list.

   Guy Steele distributed two documents of interest.  One is a list of
clear cut corrections to "Common Lisp the Language".  The other is a
list of clarifications that Guy is proposing.

Validation
----------

   After much discussion, almost all vendors present agreed to
contribute the code that they have developed for testing Common Lisp to
a validation and testing suite which is to be administrated via ISI.
Also, most vendors agreed to take a piece of the manual and implement
testing for parts of the language specified in that piece.  Discussion
of this will continue on the CL Validation mailing list.

Object Oriented Programming
---------------------------

   Three presentations were made.  David Moon of Symbolics described New
Flavors, which features advanced method combination and is different
from the flavors system Symolics is now selling.  Gregor Kiczales of
Xerox PARC described Common Loops, which features multi-methods (which
method gets invoked is a function of more than one object) and meta
classes.  Alan Snyder of Hewlett-Packard presented Common Objects, which
features good modularity between classes (flavors) and is efficient on
stock hardware.

   There seemed to be good consensus amoung the various proposers that
none of the systems necessarily precluded features in the others, and it
looked likely that further discussion would lead to a synthesis which
all could agree upon, since all proposals seemed to have the same basic
functionality including integration with the CL type system, multiple
inheritance, slots, method combination, etc.  This discussion is to go
on via the CL Objects mailing list.  I also have copies of the handouts
that accompanied each of the presentations available for copying.

   Concretely, it was proposed, and accepted, that proposers should make
available a mostly portable version of their systems to the CL community
by April to allow experimentation.  Further decsions are to be made at
the Lisp Conference in August.

Error Handling
--------------

   Kent Pittman of Symbolics, chair of the Errors subcommittee,
presented a third generation proposal for an error handling system,
which seemed to be accepted, though no action was taken.  The proposal
includes mechanism for defining condition objects, establishing handlers
for conditions, and signalling them.  I have a copy of the proposal
available for copying.

Windows
-------

  Lucid and Intellicorp have been collaborating on a design for a window
system and made a presentation on their work.  The goals seem to be to
have a powerful, flexible interface specification so that a CL window
system can live on top of a variety of vendor window systems (eg. Sun,
Appolo, Vax, Symbolics, Xerox, etc.) that still allows advanced
interaction such as active regions and event triggered methods.  Another
goal is to have a small, simple interface (such as Interlisp-D's) so
that sophisticated interfaces can be built up easily when extra hair is
not needed (Scribe was presented as a good analogy).  There will be more
discussion of this on the CL Windows mailing list, and I can elaborate a
few details of the work if anyone is interested.


   Bob Balzar from ISI presented some work on environments that has been
going on there.  They are trying to develop a fileless environment
wherein all data are objects and there are tools for keeping track of
these objects at various levels (eg. modules, definitions), as well as
providing analysis and version tracking.  Anyone interested in this work
can contact Balzar@ISI-VAXA.

	-- Rich
-------
-------

∂15-Dec-85  1327	DLW@SCRC-STONY-BROOK.ARPA 	Questions, comments and clarifications on clarifications  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Dec 85  13:26:58 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 374583; Sun 15-Dec-85 16:26:45-EST
Date: Sun, 15 Dec 85 16:35 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Questions, comments and clarifications on clarifications
To: common-lisp@SU-AI.ARPA
In-Reply-To: <8512150230.AA01849@edsel.uucp>
Message-ID: <851215163501.5.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Sat, 14 Dec 85 18:30:16 pst
    From: edsel!eb@su-navajo.arpa (Eric Benson)

    82.  Is it gratuitous pseudo-generality to allow an arbitrary number of
    arguments to XOR, instead of requiring exactly two?  Give an example.

One could argue that XOR should take an arbitary number of arguments for
symmetry with AND and OR, even if we can't come up with a satisfying
example.  Symmetry is important to keep the language self-consistent and
easier to learn.

As long as I'm sending mail, here are a few more quick comments:

249: There continues to be widespread disagreement among the expert
users I know about circular list arguments to mapping functions.
Several feel that it's natural, elegant, and seriously useful.  I do not
have any strong personal opinion, and I do not tend to use this style
personally, but I don't think this issue is nearly as clear-cut as many
of the others in "clarifications.text".

268: I suspect that COPY needs to be defined more specifically than it
is in "clarifications.text" before we can decide whether it ought to be
in the language.  While I like the basic idea very much, I'm worried
about a number of details.  Someone already brought up the question of
whether copying an array means preserving all of its attributes, such as
displacement.  If you COPY an interned symbol, is the result interned or
uninterned, and what's the symbol-package?  Are the conses of the
property list copied also, or are the property lists shared?  What if
you copy a keyword symbol?  Can you copy a package, and if so what is
the name of the copy?  If you copy a pathname, is the result allowed to
be EQ to the argument?  Can you copy a stream object that's open to a
file and positioned 254 characters into the file?  Can you copy an
output stream that's in the middle of writing characters to a file that
it's creating itself?  If you copy a closure, do you get a new closure
that shares the variable environment with the original, or does the
environment get copied too?  What other such issues might there be?  I'd
rather not express an opinion on COPY until a more detailed
specification is proposed.

425: A new argument, :ELEMENT-TYPE, to FILE-LENGTH is proposed, but the
proposal doesn't say what it means.  I'd like to hear what this argument
is supposed to be defined to mean, expressed in a way that is
implementation-independent in any sense, such that this argument could
ever be used in a portable program and relied upon to do any specific
thing in particular.

439: What is COMPILEDP defined to do if you give it a lexical closure
over a function that is compiled?

439: [The following is not well thought out; I apologize in advance.]
All this stuff about the COMPILE function retaining the interpreted
definition is starting to make me nervous about the line between a
programming language and a programming environment.  This, and also the
"how do you undefine an X" issue, point out that the current design is
wavering between trying to be a language specification and trying to be
a programming environment specification.  Obviously, in Lisp it's hard
to draw the line.  However, we are all assuming that there is some kind
of distinction.  To pick an extreme but illustrative example, suppose
there were a purported Common Lisp implementation in which the CAR
function, before returning the car of a cons, printed out some message
on the terminal.  Most of us would consider this a violation of the
Common Lisp spec; that is, if I tried to port my program and my program
failed to work because of this message, I'd blame the CL implementation,
not my program.  But LOAD is defined in CLtL just as much as CAR is, and
I haven't heard anybody complain that a Lisp is out of conformance with
the standard because LOAD prints out a message.  I don't have any
specific constructive suggestions at this time, but I think if we don't
figure this stuff out, we may be letting ourselves in for trouble and
surprising portability problems.

443: Do you also want to say that APROPOS might find some specific
symbols more than once, assuming that 187 is accepted?

∂15-Dec-85  1330	DLW@SCRC-STONY-BROOK.ARPA 	Another omission: global lexicals
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Dec 85  13:30:04 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 374588; Sun 15-Dec-85 16:29:42-EST
Date: Sun, 15 Dec 85 16:38 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Another omission: global lexicals
To: RAM@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12167368856.BABYL@C.CS.CMU.EDU>
Message-ID: <851215163801.6.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Sun, 15 Dec 1985  14:53 EST
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>

    I suggest this syntax:  DEFGLOBAL <name> <value> [<doc-string>]

And what semantics do you suggest?  That is, OK, it's lexical, so what
is its lexical scope?

The oft-discussed

(let ((a 4))
  (defun foo (x) ...)
  (defun bar (y) ...)
)

would be a way to get global lexicals, if it were Common Lisp.  The
current manual is ambiguous, or at least vague, about whether this is
construct is part of valid portable Common Lisp or not.

∂15-Dec-85  1341	Moon@SCRC-STONY-BROOK.ARPA 	XOR    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Dec 85  13:41:30 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 374601; Sun 15-Dec-85 16:40:32-EST
Date: Sun, 15 Dec 85 16:35 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: XOR
To: Steele@Aquinas.Think.COM
cc: Common-Lisp@SU-AI.ARPA
Message-ID: <851215163550.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

The XOR function in your list of suggested language improvements
handed out last week was intended to be a joke, wasn't it?  I assumed
it was, but other people on the mailing list are taking it seriously,
so I'm asking for clarification.

∂15-Dec-85  1350	RAM@C.CS.CMU.EDU 	Another omission: global lexicals    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85  13:50:03 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 15 Dec 85 16:49:24-EST
Date: Sun, 15 Dec 1985  16:49 EST
Message-ID: <RAM.12167389974.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Another omission: global lexicals
In-reply-to: Msg of 15 Dec 1985  16:38-EST from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>

    Date: Sunday, 15 December 1985  16:38-EST
    From: Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
    To:   RAM, common-lisp at SU-AI.ARPA
    Re:   Another omission: global lexicals

    The oft-discussed

    (let ((a 4))
      (defun foo (x) ...)
      (defun bar (y) ...)
    )

    would be a way to get global lexicals, if it were Common Lisp.  The
    current manual is ambiguous, or at least vague, about whether this is
    construct is part of valid portable Common Lisp or not.

This is clearly legal; any implementation which doesn't allow it is
broken.  There is some confusion about the meaning "top level forms"
such as PROCLAIM within such a construct, but I don't see any other
problems.

The lexical scope of a global lexical is everything.  If you insist on
thinking about it this way, a global lexical is a global special which
isn't special, i.e. bindings of that name are lexical instead of
special.  You can also think of a global lexical as being syntactic
sugar for wrapping a let around all the code in the world.

The only issue that seems murky to me is the interaction between
global specials and global lexicals.  What happens if you do a
DEFGLOBAL and then a special procalamation on the same name?  Is a
global lexical BOUNDP?  Can you MAKUNBOUND it?

  Rob

∂15-Dec-85  1447	DLW@SCRC-STONY-BROOK.ARPA 	Another omission: global lexicals
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Dec 85  14:47:05 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 374652; Sun 15-Dec-85 17:46:48-EST
Date: Sun, 15 Dec 85 17:55 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Another omission: global lexicals
To: RAM@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12167389974.BABYL@C.CS.CMU.EDU>
Message-ID: <851215175503.0.DLW@CHICOPEE.SCRC.Symbolics.COM>

Oh.  OK, I see what you're saying: top level forms, instead of being
considered to be in the null lexical environment as they are now, are
instead considered to be in a particular distinguished unique lexical
environment, the "global" lexical environment.  All lexical environments
"inherit from" (whatever) this one.  In addition, there is a macro or
special form called DEFGLOBAL that side-effects this global environment
by adding to it a new variable/value pair.

If foo is a global lexical, and your top-level defun function makes a
reference to foo that's free with respect to the defun, then it refers
to the global lexical variable foo.  But if your function does a LET of
foo, it gets a new lexical variable, just as if foo had not been in the
global lexical environment at all.

This all seems semantically consistent.  One could ask why it's possible
to side-effect this lexical environment when it isn't possible to
side-effect any other lexical environment.  I'm not sure that's really
relevant or interesting, but I thought I'd bring it up in case someone
else does think so.

As for your questions "Is a global lexical BOUNDP?  Can you MAKUNBOUND
it?", the answers are clearly "No" and "No", just as for any other
lexical variable.  If you do (defglobal foo 3) and then do (boundp'foo),
the latter is asking about the symbol foo, which has nothing to do with
the lexical variable.  If you (set 'foo 3), the lexical variable is
likewise unaffected.  If you do a special proclaimation on the same
name, then all references and LETs and so on will refer to the symbol
(the special variable); the global lexical variable still exists, but
there is no way to get at it.  (Except maybe if you make a closure over
it before you evaluate the proclaimation!)

I'll refrain from making any comments about implementation issues, until
we're sure that we have worked out the semantics so that we know what
we're talking about and we are all talking about the same thing.

∂15-Dec-85  1447	RAM@C.CS.CMU.EDU 	Another Common Lisp unclarity   
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85  14:47:01 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 15 Dec 85 17:46:51-EST
Date: Sun, 15 Dec 1985  17:46 EST
Message-ID: <RAM.12167400426.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: Another Common Lisp unclarity


    While we are discussing issues needing to be resolved, I will drag
out yet another problem which has been discussed in the past.  It
would be nice if someone would keep track of these things starting
*now* so that we don't have to iterate N times.

    The problem is with the notion of "top level forms" and things
containing a EVAL-WHEN (COMPILE), possibly implicit.  Examples of
forms with implicit compiler evaluation are PROCLAIM, DEFMACRO and
DEFCONSTANT.  Other possibles are package manipulation.

    The question is whether the compile-time action is done when the
form appears in a context where it is not obvious that the form will
ever be evaluated at run time.  What happens if the compiler finds this?
  (if (oddp (get-universal-time))
      (defmacro foo ...)
      (defmacro foo ...))

    My answer is that the compiler always does the evaluation, no
matter where the forms appears.  The manual seems to support this
interpretation.  See the definition of EVAL-WHEN on 69 and DEFMACRO on
146.  If this is the correct interpretation, then the manual should
say so, possibly illustrating with an example, since this can result
in non-obvious problems, especially for naive users who foolishly
believe that programs do the same thing when compiled as when
interpreted.

    There is some question about what to do with the package
functions.  Probably they only want to be evaluated when the function
appears "really at top level".  We wouldn't want compilation of this
function to die with an unbound-symbol error:
    (defun my-export (syms) (export syms "MY-PACKAGE"))
This contradicts the manual, since on page 182 it says that these
functions are implicitly wrapped in an EVAL-WHEN (COMPILE LOAD EVAL).

  Rob

∂15-Dec-85  1455	REM%IMSSS.#Pup@SU-SCORE.ARPA 	Elegant rule for what to copy 
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 15 Dec 85  14:54:53 PST
Received: from IMSSS by Score with Pup; Sun 15 Dec 85 14:52:06-PST
Date: 15 Dec 1985 1449-PST
From: Rem@IMSSS
Subject: Elegant rule for what to copy
To:   COMMON-LISP%SU-AI@SCORE

Here's an elegant rule for what to recursively copy and what to stop at
when doing a recusive copy operation. Stop at anything that has an interned
name (whereby READing in that name will give that same object) and recurse
through anything else. The idea is that copying a structure will be the
same as PRIN1ing it out and READing it back in but more efficient.
Thus a named array (does CL have them?) will be a stop point, wheras an
anonymous array will be recursed through. Interned symbols (IDs) will be
stop points, but GENSYMs will be recursed through, with another GENSYM of
exactly the same name replacing it, and with copies of the value and plist
and function. (In that case READing it back in would accidently INTERN all
the former GENSYMs, so COPY is more "right" than PRIN1-READ.)
There's a slight problem for numbers, where you're supposed to recurse through
them but there's nothing much to recurse through, so the elegant rule does
have a little deficiency there.
Of course for circular structure and to-be-preserved shared structure we
have an alternate more expensive printing routine and likewise should have
a more expensive copy routine.
-------

∂15-Dec-85  1503	GJC@MIT-MC.ARPA 	Another omission: global lexicals
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 15 Dec 85  15:02:59 PST
Date: Sun, 15 Dec 85 18:05:36 EST
From: "George J. Carrette" <GJC@MIT-MC.ARPA>
Subject:  Another omission: global lexicals
To: DLW@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA, RAM@C.CS.CMU.EDU
In-reply-to: Msg of Sun 15 Dec 85 16:38 EST from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
Message-ID: <[MIT-MC.ARPA].755061.851215.GJC>

Seriously Dan, if you fellows go before the ISO and say that
    "The oft-discussed:"

    (let ((a 4))
      (defun foo (x) ...)
      (defun bar (y) ...)
    )

is vague with respect to legality in Common Lisp the USA is going to
look pretty wimpy. Maybe it wouldn't be so vague if more implementations
took the extra trouble (or, what is better, the extra level of uniformity
and generality of treatment) to implement it. Certainly anybodies
CL interpreter would have to either be very broken or being going
out of its way to make this not work at top level:

 (let ((a 4))
   (setf (symbol-function 'foo) #'(lambda (x) ...))
   (setf (symbol-function 'bar) #'(lambda (y) ...)))

So whats the big deal about passing the same thing to a compiler?
Some compilers may not compile the lambda expressions, but a user
could rightly say that is a bug, the compiler generating slow code
instead of good machine code.


∂15-Dec-85  1541	RAM@C.CS.CMU.EDU 	Another omission: global lexicals    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85  15:41:38 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 15 Dec 85 18:41:02-EST
Date: Sun, 15 Dec 1985  18:40 EST
Message-ID: <RAM.12167410294.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Another omission: global lexicals
In-reply-to: Msg of 15 Dec 1985  17:55-EST from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>


    Yes, we seem to be talking about the same thing.  I believe you
have the right model for interaction with specials: there is none.
Unfortunately this means that shallow-binding implementations would
have to have separate lexical and special value cells, since you could
do something like this:

(defglobal foo :global)
(let ((foo :special))
  (declare (special foo))
  (bar))

(defun bar ()
  (format t "~S or ~S, take you pick."
	  foo (locally (declare (special foo)) foo)))

This doesn't mean that your symbol needs another slot though.  You
could keep the lexical value cells somewhere else (such as on the
PLIST!!), since you only need to locate the value cell at load time.

  Rob

∂15-Dec-85  1608	RPG   	Name change  
 ∂27-Nov-85  0040	CORK%umass-cs.csnet@CSNET-RELAY.ARPA 	Name change 
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 27 Nov 85  00:40:30 PST
Received: from umass-cs by csnet-relay.csnet id ba05609; 27 Nov 85 3:12 EST
Date:     Tue, 26 Nov 85 17:38 EST
From:     "Dan Corkill (413) 545-0156" <CORK%umass-cs.csnet@CSNET-RELAY.ARPA>
To:       common-lisp-request@su-ai.ARPA
Subject:  Name change

Please change CORK.UMASS@CSNET-RELAY to CMLISP.UMASS@CSNET-RELAY in your
Common Lisp mailing lists.  Thanx.

--Dan Corkill

comlsp.dis and clmultl.dis
 ∂28-Nov-85  0234	rdoty%lumiere%tektronix.csnet@CSNET-RELAY.ARPA 	Please add Tek to the list 
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 28 Nov 85  02:33:51 PST
Received: from tektronix by csnet-relay.csnet id ab18510; 28 Nov 85 5:23 EST
From: rdoty%lumiere%tektronix.csnet@CSNET-RELAY.ARPA
To: rpg@su-ai.ARPA
Cc: rdoty%tektronix.csnet@CSNET-RELAY.ARPA
Received: from lumiere by tektronix with smtp ; 27 Nov 85 21:40:52 PST
Comment: Message received over unauthenticated port at tektronix
Received: by lumiere (5.31/5.14),	id AA12035; Wed, 27 Nov 85 21:38:30 PST
Message-Id: <8511280538.AA12035@lumiere>
Subject: Please add Tek to the list
Date: 27 Nov 85 21:38:18 PST (Wed)

Please add common-lisp@tektronix to your distribution list.  Thanks.
(add-dis common)
"common-lisp%tektronix.csnet"@csnet-relay

rdoty

Richard A. Doty - Tektronix, Inc., ds 19-333, Beaverton OR 97077.
rdoty@tektronix -or- usenet@tektronix               (503)627-6517

∂15-Dec-85  1621	RAM@C.CS.CMU.EDU 	Minor package unclarity    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85  16:21:20 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 15 Dec 85 19:21:06-EST
Date: Sun, 15 Dec 1985  19:20 EST
Message-ID: <RAM.12167417579.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: Minor package unclarity


    It says on 177 that "There is no way to inherit the internal
symbols of another package; to refer to an internal symbol, the user
must either make the symbol's home package current, use a qualifier,
or import that symbol into the current package."  This not really
true, since a symbol may be internal in some packages and external in
others.  The real vaguery is in the phrase "internal symbol"; there is
no such thing.  A symbol is only internal with respect to a particular
package.

    This may seem like a quibble, but it can cause confusion.  Naive
users have enough problems without encouraging misconceptions.  It is
a misconception that internalness or externalness is a property of a
symbol.  This misconception should be thouroughly stamped out.

  Rob

∂15-Dec-85  1631	RPG  
 ∂12-Dec-85  1657	Moon@SCRC-STONY-BROOK.ARPA    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 12 Dec 85  16:56:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 373439; Thu 12-Dec-85 19:56:44-EST
Date: Thu, 12 Dec 85 19:51 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
To: rpg@SU-AI.ARPA
Message-ID: <851212195148.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

Please put me on the cl-charter @ su-ai mailing list if I'm not already
on it.  (SAIL doesn't support the EXPN protocol for finding out.)

(add-dis charter)
moon

∂15-Dec-85  1631	RPG   	Please add `mly-lispm@mit-mc' to cl-error-handling   
 ∂13-Dec-85  0237	MLY@MIT-MC.ARPA 	Please add `mly-lispm@mit-mc' to cl-error-handling   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Dec 85  02:37:10 PST
Date: Fri, 13 Dec 85 05:39:47 EST
From: Richard Mlynarik <MLY@MIT-MC.ARPA>
Subject: Please add `mly-lispm@mit-mc' to cl-error-handling
To: cl-error-handling-request@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].752230.851213.MLY>

Thanks⊗

(add-dis errors)
mly-lispm@mit-mc

∂15-Dec-85  1659	RAM@C.CS.CMU.EDU 	unclarities: defstruct print functions    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85  16:58:04 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 15 Dec 85 19:57:50-EST
Date: Sun, 15 Dec 1985  19:57 EST
Message-ID: <RAM.12167424265.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: unclarities: defstruct print functions


    Another issue in need of resolution is that of communicating the
current depth in the printing when there are user-defined print
functions.  Guy said that what had in mind was that the user would
bind *print-level* according to the depth arg supplied to the print
function, but there were several problems with this.  Most of the
tasteful solutions involved adding new args to WRITE which indicated
the nature of the recursive use of the printer.  Others objected that
nobody uses WRITE, so that isn't a real fix.

    This was discussed about a month ago.  Only God knows how many
unresolved issues lie buried and forgotten in the Common Lisp archive.

  Rob

∂15-Dec-85  1855	JAR@MIT-MC.ARPA 	Another omission: global lexicals
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 15 Dec 85  18:55:41 PST
Date: Sun, 15 Dec 85 21:58:18 EST
From: Jonathan A Rees <JAR@MIT-MC.ARPA>
Subject:  Another omission: global lexicals
To: RAM@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].755383.851215.JAR>

    Date: Sun, 15 Dec 1985  14:53 EST
    From: Rob MacLachlan <RAM at C.CS.CMU.EDU>

        It is also worth noting that it should be trivial to add global
    lexicals to any implementation.  The value is kept in the global value
    cell, just as for a special; the only difference is that there is no
    special annotation.

I interpret your suggestion as saying that DEFGLOBAL means the same
thing as SETQ, except that it lets compilers know that you really do
want a global lexical variable, so they shouldn't generate warning
messages that they might otherwise be inclined to generate ("FOO
declared special").  If you dynamically bind one, everyone sees the
dynamic binding.

I agree that this would be nice.  You have to make sure you know how
implementations which use deep binding for special variables are going
to deal with this; my interpretation of your proposal makes different
implementation demands from Weinreb's interpretation.  However, I think
deep-bound Common Lisps can simply cause references to DEFGLOBAL'ed
variables to always go through its top-level value cell (presumably one
still exists, even if the variable has been dynamically bound).
SYMBOL-VALUE would still always get the special binding.

I think one could go either as you suggest or as Weinreb suggests on
this.  My reading of your proposal seems to be a less radical departure
from common lisp.  But it's important to keep in mind the distinction
and consider the ramifications and possible generalizations of any
proposal.

I'm also frustrated by the absence of global lexical variables.  There's
no way you can PREVENT a LET or LAMBDA from doing dynamic binding if the
variable obtained its top-level binding with DEFVAR.  To make matters
worse, some implementations (viz. the one I use) even discourage you
from doing top-level references and SETQ's on variables which haven't
been declared or proclaimed SPECIAL - you get "FOO declared special"
messages (fortunately it does a DECLARE and not a PROCLAIM!).

I asked the list a while ago if anyone could remember why there was no
UNSPECIAL declaration in the language, and I didn't get any answer.  If
UNSPECIAL existed, you could redefine LET, LAMBDA, etc. to put implicit
DECLARE UNSPECIAL's in their bodies, and get the effect of global
lexicals just by using DEFVAR.  The only reason I can think of to
exclude UNSPECIAL is to avoid putting constraints on deep-bound or
hybrid implementations.

The solution I ended up using is this: I use SETQ, never DEFVAR to
introduce a top-level binding; I always write

  (locally (declare (special x)) x)

to reference the global "x" (to inhibit the compiler's automatic DECLARE
SPECIAL and its annoying warning message); I use

  (let ((temp (compute-value ...)))
    (setq x temp))

to make an assignment (for the same reasons - and macroized, of course);
and I never use implicit (proclaimed) SPECIAL declarations - if I want
to do a special binding I use a DECLARE.

Of course, my code will very likely stop working if I ever run it in a
deep-bound implementation.

In short: DEFGLOBAL is an important addition to the language, and very
easy to implement.  (It will probably wreak havoc on the manual - how
many places implicitly assume that global variables are always special?)

-----
[Aside: MIT Scheme and T have a generalization of this which allows ANY
lexical variable to be dynamically bound.  As in your proposal,
top-level lexicals and top-level specials live in the same place.
Specials are lexically shadowed by lexical bindings of the same name,
but any lexical variable, not just a top-level lexical variable, can be
dynamically bound.  Dynamicness is not a property of variables (names),
but of binding.

I would expect people who haven't thought about this before to be
confused.  I certainly was when I first saw it.  Here is an example.

(setq y 'top)

(defun foo1 ()
  (let ((y 'lexical))
    (bar #'(lambda (f)
	     (fluid-let ((y 'fluid))
	       (funcall f)))		;scheme dynamic binding
	 #'(lambda () y))))

(defun foo2 ()
  (let ((y 'lexical))
    (bar #'(lambda (f)
	     (let ((y 'fluid))
	       (declare (special y))	;CL dynamic binding, for comparison
	       (funcall f)))
	 #'(lambda () y))))

(defun bar (g h)
  (funcall g #'(lambda () (list (funcall h) y))))

(foo1)  =>  (FLUID TOP)
(foo2)  =>  (LEXICAL FLUID)  ;[probably, at least in shallow implementations]

The semantics of (fluid-let ((x value)) body) is similar to

(let ((temp x))
  (setq x value)
  (unwind-protect body
		  (setq x temp)))

except of course that it interacts properly with context switches.  It
turns out this facility is moderately useful.  And it works in either
shallow-bound implementations or deep-bound ones (both MIT Scheme and T
use shallow binding right now, but T is changing to deep binding).

I think this is subsumed by Zetalisp's LETF, for those of you familiar
with that.]

- Jonathan

∂15-Dec-85  1935	RAM@C.CS.CMU.EDU 	list of proposed changes to Common Lisp   
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85  19:35:09 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 15 Dec 85 22:34:59-EST
Date: Sun, 15 Dec 1985  22:34 EST
Message-ID: <RAM.12167452884.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   Guy Steele <gls@AQUINAS.THINK.COM>
Cc:   common-lisp@SU-AI.ARPA
Subject: list of proposed changes to Common Lisp


    (*) 158 Specify that it is an error for more than one TYPE declaration
    for a given variable to appear in a group of declarations (those all
    at the head of the same body), or more than one FTYPE or FUNCTION
    declaration for a given function name, or both an INLINE and a
    NOTINLINE declaration for the same function.

I think this is excessively restrictive.  The obvious meaning of
multiple type declarations for the same variable is that the value of
the variable is of *both* types.  (declare (type a foo) (type b foo))
is the same as (declare (type (and a b) foo)).

This feature could actually be used to good effect.  Suppose a clever
writer of the DOTIMES macro realized that the variable will always be
of type (INTEGER 0), and added such a declaration in the expansion.
The user of DOTIMES might know that the upper bound is always a
fixnum, and write (dotimes (i x) (declare (fixnum i)).  The compiler
could then determine that the step variable is in fact a non-negative
fixnum, which might be a useful piece of information.

Note that if the declared types are known to be disjoint, the variable
will have effectively been declared to be of type NIL, thus the
binding (not the declaration) is illegal, since its initial value
cannot be of type NIL.  Note also that this interpretation won't break
anything; the variable belongs to all the types, thus an
implementation which uses any one will still be correct.

An FTYPE declaration is identical to a type declaration except for
specifying the result of functional evaluation, so the same reasoning
holds.  A FUNCTION declaration is in fact a (TYPE FUNCTION ...)
declaration, so this is also reasonable.

I have no objection of saying that conflicting INLINE and NOTINLINE
declarations are illegal, but due to the advisory nature of INLINE
declarations, it might be reasonable to say the compiler can obey
whichever declaration it feels like.

While we are talking about types, I will mention that there is a
missing type specifier, namely REAL, which is probably the same as
(OR FLOAT RATIONAL).  Although probably useless as a declaration, it
is useful for things like CHECK-TYPE.

  Rob

∂15-Dec-85  2128	RAM@C.CS.CMU.EDU 	Another omission: global lexicals    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85  21:26:35 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 16 Dec 85 00:26:15-EST
Date: Mon, 16 Dec 1985  00:26 EST
Message-ID: <RAM.12167473144.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   Jonathan A Rees <JAR@MIT-MC.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Another omission: global lexicals
In-reply-to: Msg of 15 Dec 1985  21:58-EST from Jonathan A Rees <JAR at MIT-MC.ARPA>


Each symbol potentially has one global value cell.  This value cell is
used to store the value of global variables and constants.  The
functions SYMBOL-VALUE, BOUNDP and MAKUNBOUND operate on this value
cell.  References to global lexical variables and constants may use
this cell directly.  In a shallow-binding Lisp, a special binding
shallow-binds this cell, and a special reference reads this cell.
In a deep-binding Lisp, some search needs to be done for a special
reference or store.

    You are right.  In fact I think it wouldn't break any Common Lisp
programs (certainly not any tasteful ones) to allow dynamic bindings
on any variable.  It would only make a difference in contorted cases
where there is both a lexical binding and a special binding of the
same name in the same lexical scope.  I doubt this exists outside of
the example in the manual.

    If even this slight possibility scares you, then you could say
that a special binding always binds the global value cell for the symbol.

∂15-Dec-85  2134	RAM@C.CS.CMU.EDU 	Another omission: global lexicals    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85  21:34:03 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 16 Dec 85 00:33:45-EST
Date: Mon, 16 Dec 1985  00:33 EST
Message-ID: <RAM.12167474504.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   Jonathan A Rees <JAR@MIT-MC.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Another omission: global lexicals


Now that I'm done editing, let's try again:
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←

    Beautiful: I knew there was a justification for the obvious
implementation.  A special binding is actually a binding of the global
value cell.  Each symbol potentially has one global value cell.  This
value cell is used to store the value of global variables and
constants.  The functions SYMBOL-VALUE, BOUNDP and MAKUNBOUND operate
on this value cell.  In a shallow-binding lisp, all global references
can go directly to this cell.  In a deep-binding lisp, global
references other than special references can go direct; special
references potentially involve a search.

    In fact I think it wouldn't break any Common Lisp programs
(certainly not any tasteful ones) to allow dynamic bindings on any
variable.  It would only make a difference in contorted cases where
there is both a lexical binding and a special binding of the same name
in the same lexical scope.  I doubt this exists outside of the example
in the manual.

  Rob

∂16-Dec-85  0303	cfry%MIT-OZ@MIT-MC.ARPA 	clarifications 
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 16 Dec 85  03:03:28 PST
Received: from MIT-JANIS by MIT-OZ via Chaosnet; 16 Dec 85 06:02-EST
Date: Mon, 16 Dec 85 06:03 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: clarifications
To: common-lisp@SU-AI.ARPA
Message-ID: <851216060351.3.CFRY@JANIS.AI.MIT.EDU>

130: Self-evaluating forms (such as strings] in tagbodies
     are no-ops but otherwise harmless.
     Its not worth it to make a special case to rule them out.
     Code (or humans) that write/modify other code shouldn't have to worry
     about what's in the body that its wrapping a tagbody around.

268: Can the proposed COPY be installed like SETF?
     Call it COPYF. Depth of copying could be specified with
     an integer.

425: Along with FILE-LENGTH, it would be nice to be
     able to ask the operating system how much 
     disk-space is available in a given directory,
     so you could have some control when attempting to
     write too-large files without going through
     some error mechanism.
     (disk-free-space pathname) => number of bytes available.			

∂16-Dec-85  0641	DLW@SCRC-STONY-BROOK.ARPA 	Another omission: global lexicals
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Dec 85  06:41:15 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 374896; Mon 16-Dec-85 09:40:13-EST
Date: Mon, 16 Dec 85 09:48 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Another omission: global lexicals
To: GJC@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA, RAM@C.CS.CMU.EDU
In-Reply-To: <[MIT-MC.ARPA].755061.851215.GJC>
Message-ID: <851216094829.3.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Sun, 15 Dec 85 18:05:36 EST
    From: "George J. Carrette" <GJC@MIT-MC.ARPA>

    Seriously Dan, if you fellows go before the ISO and say that
	"The oft-discussed:"
    is vague with respect to legality in Common Lisp the USA is going to
    look pretty wimpy.

You're right, George.  I'll never again say that anything is vague with
respect to legality.  Every issue is clear-cut.  We'll see if we can get
Rambo for the technical committee.

∂16-Dec-85  0657	wagner%fang@gswd-vms 	&ALLOW-OTHER-KEYS 
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 16 Dec 85  06:57:42 PST
Received: from fang.GSD (fang.ARPA) by gswd-vms.ARPA (5.9/5.6)
	id AA08881; Mon, 16 Dec 85 08:58:46 CST
Message-Id: <8512161458.AA08881@gswd-vms.ARPA>
Date: Mon, 16 Dec 85 08:57:27 cst
From: wagner%fang@gswd-vms (Fran Wagner)
To: common-lisp@su-ai.arpa
Subject: &ALLOW-OTHER-KEYS
Cc: wagner%fang@gswd-vms

In the clarifications that Guy distributed in Boston, mention is
made of &ALLOW-OTHER-KEYWORDS (p.1).  In CLtL and in implementations
I could check, this lambda-list keyword is named &ALLOW-OTHER-KEYS.
The KEYWORDS form is more natural, but it is a mistake, right?

--Fran

∂16-Dec-85  0704	DLW@SCRC-STONY-BROOK.ARPA 	Another omission: global lexicals
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Dec 85  07:03:21 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 374918; Mon 16-Dec-85 10:03:00-EST
Date: Mon, 16 Dec 85 10:11 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Another omission: global lexicals
To: RAM@C.CS.CMU.EDU
cc: JAR@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12167474504.BABYL@C.CS.CMU.EDU>
Message-ID: <851216101119.7.DLW@CHICOPEE.SCRC.Symbolics.COM>

I thought we were in agreement, but now I'm not sure.  What does this
program print?

(defglobal g 4)

(set 'g 5)

(defun foo ()
  (setq g 6))

(foo)

(print g)

In my interpretation of your original proposal, (print g) is referring
to g lexically, since nobody ever declared it special.  foo is referring
to g lexically also.  The value of the symbol named g is irrelevant; the
program prints 6.

Before I continue this message, is it your current claim that it prints
6, or that it prints 5?

∂16-Dec-85  0935	gls@THINK-AQUINAS.ARPA 	list of proposed changes to Common Lisp  
Received: from THINK.COM by SU-AI.ARPA with TCP; 16 Dec 85  09:34:52 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 16 Dec 85 12:34:48 est
Date: Mon, 16 Dec 85 12:34 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: list of proposed changes to Common Lisp
To: RAM@C.CS.CMU.EDU, gls@THINK-AQUINAS.ARPA
Cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <RAM.12166952525.BABYL@C.CS.CMU.EDU>
Message-Id: <851216123446.3.GLS@THINK-JEHOSEPHAT.ARPA>

    Date: Sat, 14 Dec 1985  00:46 EST
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>

	(*) 107 Clarify that GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE do
	not perform macro-expansion on the given form ...

    This won't work, as it prohibits defining setf methods for macros.
    GET-SETF-METHOD needs the environment so that it can expand macros one
    level at a time, checking if the result has a setf method.  I also
    suggest that the environment argument not be optional, as any user
    code which doesn't supply it is surely broken.

Right you are.

    312 It should be explicitly noted somewhere that defstruct copiers
    work on structures which are a subtype by inclusion, e.g. COPY-PERSON
    works on an astronaut.  This is a natural consequence of the subtype
    semantics of inclusion, but isn't necessarily obvious to pea-brained
    implementors.

Presumably COPY-PERSON, when applied to an ASTRONAUT, returns something
that is a PERSON but not an ASTRONAUT; that is, it makes a copy of just
the PERSON part of an ASTRONAUT?

--Guy

∂16-Dec-85  1002	gls@THINK-AQUINAS.ARPA 	Questions, comments and clarifications on clarifications
Received: from THINK.COM by SU-AI.ARPA with TCP; 16 Dec 85  10:01:58 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 16 Dec 85 13:01:46 est
Date: Mon, 16 Dec 85 13:01 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Questions, comments and clarifications on clarifications
To: DLW@SCRC-QUABBIN.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <851215163501.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <851216130145.5.GLS@THINK-JEHOSEPHAT.ARPA>

    Date: Sun, 15 Dec 85 16:35 EST
    From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
    425: A new argument, :ELEMENT-TYPE, to FILE-LENGTH is proposed, but the
    proposal doesn't say what it means.  I'd like to hear what this argument
    is supposed to be defined to mean, expressed in a way that is
    implementation-independent in any sense, such that this argument could
    ever be used in a portable program and relied upon to do any specific
    thing in particular.

Sorry it wasn't clean.  FILE-LENGTH is defined to return the length of a
file measured in units of ELEMENT-TYPE.  FILE-LENGTH now is guaranteed
to work only on an open stream, and it uses the ELEMENT-TYPE specified
when the stream was opened.  The proposal is to allow FILE-LENGTH to
take any pathname, but in that case it may be necessary to specify an
ELEMENT-TYPE explicitly in order to get the answer you want.

    439: What is COMPILEDP defined to do if you give it a lexical closure
    over a function that is compiled?

I would say it should return T.

    443: Do you also want to say that APROPOS might find some specific
    symbols more than once, assuming that 187 is accepted?

Yep.

∂16-Dec-85  1005	gls@THINK-AQUINAS.ARPA 	XOR   
Received: from THINK.COM by SU-AI.ARPA with TCP; 16 Dec 85  10:05:05 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 16 Dec 85 13:05:08 est
Date: Mon, 16 Dec 85 13:05 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: XOR
To: Moon@SCRC-STONY-BROOK.ARPA, Steele@THINK-AQUINAS.ARPA
Cc: Common-Lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <851215163550.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <851216130507.6.GLS@THINK-JEHOSEPHAT.ARPA>

    Date: Sun, 15 Dec 85 16:35 EST
    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>

    The XOR function in your list of suggested language improvements
    handed out last week was intended to be a joke, wasn't it?  I assumed
    it was, but other people on the mailing list are taking it seriously,
    so I'm asking for clarification.

Of all the functions not in Common Lisp that I use day-to-day on my
3600, this is the one I use most frequently.  I admit that I have been,
among other things, constructing logic models of various kinds.
However, I also find it useful in random COND clauses.  Maybe the rest
of you will decide it is not useful, but in any case it is not a joke.

∂16-Dec-85  1014	gls@THINK-AQUINAS.ARPA 	Another omission: global lexicals   
Received: from THINK.COM by SU-AI.ARPA with TCP; 16 Dec 85  10:14:16 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 16 Dec 85 13:14:09 est
Date: Mon, 16 Dec 85 13:14 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Another omission: global lexicals
To: RAM@C.CS.CMU.EDU, DLW@SCRC-QUABBIN.ARPA
Cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <RAM.12167410294.BABYL@C.CS.CMU.EDU>
Message-Id: <851216131407.7.GLS@THINK-JEHOSEPHAT.ARPA>

    Date: Sun, 15 Dec 1985  18:40 EST
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>

	Yes, we seem to be talking about the same thing.  I believe you
    have the right model for interaction with specials: there is none.
    Unfortunately this means that shallow-binding implementations would
    have to have separate lexical and special value cells, since you could
    do something like this:

    (defglobal foo :global)
    (let ((foo :special))
      (declare (special foo))
      (bar))

    (defun bar ()
      (format t "~S or ~S, take you pick."
	      foo (locally (declare (special foo)) foo)))

    This doesn't mean that your symbol needs another slot though.  You
    could keep the lexical value cells somewhere else (such as on the
    PLIST!!), since you only need to locate the value cell at load time.

      Rob


I think it is a bad idea to let "global lexicals" and specials be completely
independent, for the simple reason that in

(defvar foo 3)
(defun baz () foo)
(baz) => 3
(defglobal foo 5)
(baz) => 5

the DEFGLOBAL changes the meaning of the variable reference in BAZ.
Right now the meaning of FOO within BAZ can be determined by inspection
of only BAZ:  because there is no *lexically apparent* lexical binding,
the reference to FOO must be special.  With DEFGLOBAL as proposed, the
meaning of FOO cannot be understood out of context.

Here is a different model for DEFGLOBAL: it is just like DEFCONSTANT
except you are allowed to SETQ it.  So you can change its value with a
side effect (or even make it unbound), but it is an error to bind it.

--Guy

∂16-Dec-85  1032	gls@THINK-AQUINAS.ARPA 	meta corrections to CLtL  
Received: from THINK.COM by SU-AI.ARPA with TCP; 16 Dec 85  10:31:48 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 16 Dec 85 13:31:44 est
Date: Mon, 16 Dec 85 13:31 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: meta corrections to CLtL
To: cfry@OZ.AI.MIT.EDU
Cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851216055254.2.CFRY@JANIS.AI.MIT.EDU>
Message-Id: <851216133143.9.GLS@THINK-JEHOSEPHAT.ARPA>

    Date: Mon, 16 Dec 85 05:52 EST
    From: Christopher Fry <cfry@OZ.AI.MIT.EDU>

    I updated my copy of CLtL to include all
    of your comments, except that I think you made a few errors
    in the Corrections doc:

    189  fewethings => few things
	 Your habit of typing e where SPACE should be is pretty confusing!

I forgot to mention this at the conference: the handouts I produced were
printed on a laser printer that was placed a bit too far from its host
(on a long cable) or something.  Some electrical glitch causes it to
randomly turn a space into "a" or "e".  This seems to occur only when
the space immediately follows a "w".
--Guy

∂16-Dec-85  1035	gls@THINK-AQUINAS.ARPA 	&ALLOW-OTHER-KEYS    
Received: from THINK.COM by SU-AI.ARPA with TCP; 16 Dec 85  10:34:12 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 16 Dec 85 13:34:12 est
Date: Mon, 16 Dec 85 13:34 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: &ALLOW-OTHER-KEYS
To: wagner%fang@GSWD-VMS.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <8512161458.AA08881@gswd-vms.ARPA>
Message-Id: <851216133412.0.GLS@THINK-JEHOSEPHAT.ARPA>

    Date: Mon, 16 Dec 85 08:57:27 cst
    From: wagner%fang@gswd-vms (Fran Wagner)

    In the clarifications that Guy distributed in Boston, mention is
    made of &ALLOW-OTHER-KEYWORDS (p.1).  In CLtL and in implementations
    I could check, this lambda-list keyword is named &ALLOW-OTHER-KEYS.
    The KEYWORDS form is more natural, but it is a mistake, right?

    --Fran

Yes, I made a mistake.  Thanks for pointing it out.
--Guy

∂16-Dec-85  1058	DCP@SCRC-QUABBIN.ARPA 	get-setf-method  
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 16 Dec 85  10:58:04 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 228614; Mon 16-Dec-85 13:52:25-EST
Date: Mon, 16 Dec 85 13:58 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: get-setf-method
To: Common-Lisp@SU-AI.ARPA
Message-ID: <851216135850.0.DCP@NEPONSET.SCRC.Symbolics.COM>

Excuse me if this has already been cleared up, but
	(get-setf-method (macroexpand form env))
just won't cut it.  Consider this example:

	(defmacro raster-aref (raster-array x y)
	  ...code-to-ensure-order-of-evaluation...
	  `(aref ,raster-array ,y ,x))
	(defsetf raster-aref ...)

Now,
	(raster-aref array (foo) (bar))
expands into (in our system, at least)
	(let ((.gensym-for-raster-array. array)
	      (.gensym-for-bar. (bar)))
	  (aref .gensym-for-raster-array. .gensym-for-bar. (foo)))
Since when does LET have a DEFSETF method?

I agree with whoever said the environment should be a required argument.

∂16-Dec-85  1058	DLW@SCRC-QUABBIN.ARPA 	Questions, comments and clarifications on clarifications 
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 16 Dec 85  10:57:43 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 228613; Mon 16-Dec-85 13:52:07-EST
Date: Mon, 16 Dec 85 14:05 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Questions, comments and clarifications on clarifications
To: gls@THINK-AQUINAS.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <851216130145.5.GLS@THINK-JEHOSEPHAT.ARPA>
Message-ID: <851216140512.2.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Mon, 16 Dec 85 13:01 EST
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>

    Sorry it wasn't clean.  FILE-LENGTH is defined to return the length of a
    file measured in units of ELEMENT-TYPE.  FILE-LENGTH now is guaranteed
    to work only on an open stream, and it uses the ELEMENT-TYPE specified
    when the stream was opened.  The proposal is to allow FILE-LENGTH to
    take any pathname, but in that case it may be necessary to specify an
    ELEMENT-TYPE explicitly in order to get the answer you want.

If this is what you mean, it should be made clear that (1) the model of
a "file" is that it has a single associated element-type, and (2) if you
use the new form of file-length, and you pass in :element-type, then the
value must be the same as the actual element-type of the file, or else
it is an error (the result is undefined).

(Put more crudely, there should be no defined way to write a file in
units of X and then ask for its length in units of Y, that claims to be
portable.)

∂16-Dec-85  1149	DLW@SCRC-QUABBIN.ARPA 	Another omission: global lexicals    
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 16 Dec 85  11:49:12 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 228643; Mon 16-Dec-85 14:43:43-EST
Date: Mon, 16 Dec 85 14:57 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Another omission: global lexicals
To: gls@THINK-AQUINAS.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851216131407.7.GLS@THINK-JEHOSEPHAT.ARPA>
Message-ID: <851216145707.3.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Mon, 16 Dec 85 13:14 EST
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>

    (defvar foo 3)
    (defun baz () foo)
    (baz) => 3
    (defglobal foo 5)
    (baz) => 5

    the DEFGLOBAL changes the meaning of the variable reference in BAZ.

In the only semantics that currently seems to make sense to me, the
DEFGLOBAL does not change the meaning.  Since FOO is still declared
special, the FOO in the body of BAZ is still a special reference.

Unless you are assuming that DEFGLOBAL does a sort of (PROCLAIM (UNSPECIAL)),
which I am not.

    Right now the meaning of FOO within BAZ can be determined by inspection
    of only BAZ:  because there is no *lexically apparent* lexical binding,
    the reference to FOO must be special.  With DEFGLOBAL as proposed, the
    meaning of FOO cannot be understood out of context.

I'm not sure I concur with this logic.  The meaning of FOO within BAZ
depends on non-lexically-local information, namely whether FOO has been
proclaimed special.  In present CL as I know it, FOO is either a special
reference or an error depending on whether FOO is proclaimed special; in
the new proposal, semantics as I am assuming, FOO is either a special
reference or a local reference or an error, depending on whether FOO is
proclaimed special and on whether FOO is part of the global lexical
environment or not.  So the DEFGLOBAL is just another thing like a
special proclaimation.

Again, I'm not trying to support anything or object to anything, just
trying to nail down what it is that the proposal means.

∂16-Dec-85  1154	RAM@C.CS.CMU.EDU 	list of proposed changes to Common Lisp   
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 Dec 85  11:53:44 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 16 Dec 85 14:14:20-EST
Date: Mon, 16 Dec 1985  14:14 EST
Message-ID: <RAM.12167623892.BABYL@>
From: Rob MacLachlan <RAM@λλ>
To:   Guy Steele <gls@AQUINAS.THINK.COM>
Cc:   common-lisp@SU-AI.ARPA
Subject: list of proposed changes to Common Lisp
In-reply-to: Msg of 16 Dec 1985  12:34-EST from Guy Steele <gls at THINK-AQUINAS.ARPA>

    Date: Monday, 16 December 1985  12:34-EST
    From: Guy Steele <gls at THINK-AQUINAS.ARPA>
    Re:   list of proposed changes to Common Lisp

    Presumably COPY-PERSON, when applied to an ASTRONAUT, returns
    something that is a PERSON but not an ASTRONAUT; that is, it makes a
    copy of just the PERSON part of an ASTRONAUT?

Well, so maybe it's not so clear-cut.  I thought the obvious
interpretation was that COPY-PERSON was the same thing as
COPY-ASTRONAUT when applied to an astronaut.  It now seems we have
three possible interpretations:
 1] It is illegal to use a copier for an included structure on an
    instance of the including structure.
 2] The copier for the included structure returns an object of the
    same type as the included structure, containing only the included
    slots.
 3] The copier for the included structure also copies instances of any
    structure which include it.
If there are three modedately reasonable interpretations, is even more
important to specify which applies.  One thing worth considering is
how well the interpretation fits into possible object-oriented
programming systems such as Common Loops.

  Rob

∂16-Dec-85  1400	masinter.pa@Xerox.ARPA 	Re: Special Form Question 
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 16 Dec 85  14:00:20 PST
Received: from Salvador.ms by ArpaGateway.ms ; 16 DEC 85 13:04:11 PST
Date: 16 Dec 85 13:03 PST
From: masinter.pa@Xerox.ARPA
Subject: Re: Special Form Question
To: common-lisp@SU-AI.ARPA
Message-ID: <851216-130411-1214@Xerox>

It would be more consistent and portable to define
(symbol-function 'quote) => nil.

under the theory that "symbol-function" really means to return a
function rather than "what this symbol means when seen as car of
something to be EVAL'd."

Similarly, it would be more consistent and portable to require that
after (defmacro foo --) that (symbol-function 'foo) also return nil.

This would mean that values returned by symbol-function could be assumed
to be functions, in the "funcall-able" sense.

It is likely that implementations will want to have some internal
"really give me what this symbol means when you see it as the CAR of a
form about to be EVALd" for use by the interpreter, but its not clear to
me why that primitive has to be "symbol-function".

Larry

∂16-Dec-85  1412	GSB@MIT-MC.ARPA 	get-setf-method   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 16 Dec 85  14:12:39 PST
Date: Mon, 16 Dec 85 17:15:19 EST
From: "Glenn S. Burke" <GSB@MIT-MC.ARPA>
Subject: get-setf-method
To: common-lisp@SU-AI.ARPA
Message-ID: <[MIT-MC.ARPA].756838.851216.GSB>

I had thought it had been established long ago that the environment
argument is necessary.  Not only for the reason Dave Plummer notes,
but also for the correct macroexpansion of macros from within setf
methods (such as LDB).  I have no objections to the environment argument
to get-setf-method being required, although I would be inclined to
make it optional just as it is to macro-expand.  Although one could
argue for the environment arg to macro-expand being required, similarly...

∂16-Dec-85  1518	masinter.pa@Xerox.ARPA 	Re: clarifications   
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 16 Dec 85  15:17:59 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 DEC 85 14:37:51 PST
Date: 16 Dec 85 14:37 PST
From: masinter.pa@Xerox.ARPA
Subject: Re: clarifications
In-reply-to: Christopher Fry <cfry@OZ.AI.MIT.EDU>'s message of Mon, 16
 Dec 85 06:03 EST
To: cfry@OZ.AI.MIT.EDU
cc: common-lisp@SU-AI.ARPA
Message-ID: <851216-143751-1352@Xerox>

Some pathnames don't denote disks, and yet "free-space" is a meaningful
concept. Why not "free-space" or "file-free-space" at least, instead of
"disk-free-space"?

∂16-Dec-85  1524	DCP@SCRC-STONY-BROOK.ARPA 	XOR
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Dec 85  15:23:58 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 375442; Mon 16-Dec-85 16:42:38-EST
Date: Mon, 16 Dec 85 16:44 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: XOR
To: Guy Steele <gls@THINK-AQUINAS.ARPA>, Moon@SCRC-STONY-BROOK.ARPA,
    Steele@THINK-AQUINAS.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <851216130507.6.GLS@THINK-JEHOSEPHAT.ARPA>
Message-ID: <851216164401.5.DCP@NEPONSET.SCRC.Symbolics.COM>

    Date: Mon, 16 Dec 85 13:05 EST
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>

	Date: Sun, 15 Dec 85 16:35 EST
	From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>

	The XOR function in your list of suggested language improvements
	handed out last week was intended to be a joke, wasn't it?  I assumed
	it was, but other people on the mailing list are taking it seriously,
	so I'm asking for clarification.

    Of all the functions not in Common Lisp that I use day-to-day on my
    3600, this is the one I use most frequently.  I admit that I have been,
    among other things, constructing logic models of various kinds.
    However, I also find it useful in random COND clauses.  Maybe the rest
    of you will decide it is not useful, but in any case it is not a joke.

One argument I have heard against XOR is that, unlike AND and OR, it
must evaluate all of its forms.

Of course, MLB once sent an amusing thing describing an XOR that returns
the right answer but somehow knows what the forms evaluate to so it can
stop early after the things it doesn't know a priori !-}

∂16-Dec-85  1703	mips!escargot.earl@glacier 	Re: Special Form Question  
Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 16 Dec 85  17:01:39 PST
Received: by glacier with Sendmail; Mon, 16 Dec 85 17:00:25 pst
Received: from escargot.UUCP (escargot.ARPA) by mips.UUCP (4.12/4.7)
	id AA10372; Mon, 16 Dec 85 16:30:09 pst
Received: by escargot.UUCP (4.12/4.7)
	id AA04100; Mon, 16 Dec 85 16:29:10 pst
Date: Mon, 16 Dec 85 16:29:10 pst
From: mips!escargot.earl@glacier (Earl Killian)
Message-Id: <8512170029.AA04100@escargot.UUCP>
To: masinter.pa@Xerox.ARPA
Cc: common-lisp@SU-AI.ARPA
In-Reply-To: glacier!masinter.pa@Xerox.ARPA's message of 16 Dec 85 13:03 PST
Subject: Re: Special Form Question

    Date: 16 Dec 85 13:03 PST
    From: glacier!masinter.pa@Xerox.ARPA

    It would be more consistent and portable to define
    (symbol-function 'quote) => nil.

    under the theory that "symbol-function" really means to return a
    function rather than "what this symbol means when seen as car of
    something to be EVAL'd."

    Similarly, it would be more consistent and portable to require that
    after (defmacro foo --) that (symbol-function 'foo) also return nil.

    This would mean that values returned by symbol-function could be assumed
    to be functions, in the "funcall-able" sense.

    It is likely that implementations will want to have some internal
    "really give me what this symbol means when you see it as the CAR of a
    form about to be EVALd" for use by the interpreter, but its not clear to
    me why that primitive has to be "symbol-function".

Alternatively, you could leave symbol-function as the thing that
accesses a symbol's "function cell", and provide a new function that
is the same as FUNCTION, except that its argument is evaluated.  It
could be applied to things other than symbols (e.g. lists with CAR =
LAMBDA).  Call it FEVAL??  Then you could eliminate lambda
expressions as functions (the only argument for them was that you
needed to be able to construct functions on the fly -- now you can
construct lambda expressions and use FEVAL to turn them into
functions).

∂16-Dec-85  2018	DLW@SCRC-STONY-BROOK.ARPA 	Non-top-level DEFUN    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Dec 85  20:18:11 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 375729; Mon 16-Dec-85 23:17:43-EST
Date: Mon, 16 Dec 85 23:18 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Non-top-level DEFUN
To: common-lisp@SU-AI.ARPA
Message-ID: <851216231823.7.DLW@CHICOPEE.SCRC.Symbolics.COM>

In recent mail, I said that I wasn't sure that DEFUNs inside a top-level
LET were valid CL.  This was a completely error on my part, resulting
from my having spent too much time in design discussions to remember how
they came out.  Yes, it's legal Common Lisp.  And the Symbolics
implementation supports it correctly, too.  Sorry about that.

∂16-Dec-85  2042	FAHLMAN@C.CS.CMU.EDU 	Non-top-level DEFUN    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 Dec 85  20:41:53 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 16 Dec 85 23:41:16-EST
Date: Mon, 16 Dec 1985  23:41 EST
Message-ID: <FAHLMAN.12167727095.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Non-top-level DEFUN
In-reply-to: Msg of 16 Dec 1985  23:18-EST from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>


Whether or not Weinreb was confused, the larger point remains:

The notion of "top-level form" is a complete disaster and should be
abolished.  We should flush this in favor of a careful specification of
just what things the compiler is required to handle in well-defined ways
and which things are left to the discretion of the implementor.  We've
got enough experience by now that we can tie down some things that we
were afraid to specify earlier.

-- Scott

∂17-Dec-85  0808	gls@THINK-AQUINAS.ARPA 	Questions, comments and clarifications on clarifications
Received: from THINK.COM by SU-AI.ARPA with TCP; 17 Dec 85  07:59:50 PST
Received: from ignatius by GODOT.THINK.COM via CHAOS; Tue, 17 Dec 85 10:59:39 est
Date: Tue, 17 Dec 85 10:58 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Questions, comments and clarifications on clarifications
To: DLW@SCRC-QUABBIN.ARPA, gls@THINK-AQUINAS.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <851216140512.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <851217105855.3.GLS@THINK-IGNATIUS.ARPA>

    Date: Mon, 16 Dec 85 14:05 EST
    From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>

	Date: Mon, 16 Dec 85 13:01 EST
	From: Guy Steele <gls@THINK-AQUINAS.ARPA>
	...

    If this is what you mean, it should be made clear that (1) the model of
    a "file" is that it has a single associated element-type, and (2) if you
    use the new form of file-length, and you pass in :element-type, then the
    value must be the same as the actual element-type of the file, or else
    it is an error (the result is undefined).

    (Put more crudely, there should be no defined way to write a file in
    units of X and then ask for its length in units of Y, that claims to be
    portable.)

I agree.  I think that (1) was already, if not clear, then at least translucent
from the existing description of FILE-LENGTH.  Clearly (2) is a necessary
consequence for portability.

∂17-Dec-85  0911	gls@THINK-AQUINAS.ARPA 	Questions, comments and clarifications on clarifications
Received: from THINK.COM by SU-AI.ARPA with TCP; 17 Dec 85  07:59:50 PST
Received: from ignatius by GODOT.THINK.COM via CHAOS; Tue, 17 Dec 85 10:59:39 est
Date: Tue, 17 Dec 85 10:58 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Questions, comments and clarifications on clarifications
To: DLW@SCRC-QUABBIN.ARPA, gls@THINK-AQUINAS.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <851216140512.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <851217105855.3.GLS@THINK-IGNATIUS.ARPA>

    Date: Mon, 16 Dec 85 14:05 EST
    From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>

	Date: Mon, 16 Dec 85 13:01 EST
	From: Guy Steele <gls@THINK-AQUINAS.ARPA>
	...

    If this is what you mean, it should be made clear that (1) the model of
    a "file" is that it has a single associated element-type, and (2) if you
    use the new form of file-length, and you pass in :element-type, then the
    value must be the same as the actual element-type of the file, or else
    it is an error (the result is undefined).

    (Put more crudely, there should be no defined way to write a file in
    units of X and then ask for its length in units of Y, that claims to be
    portable.)

I agree.  I think that (1) was already, if not clear, then at least translucent
from the existing description of FILE-LENGTH.  Clearly (2) is a necessary
consequence for portability.

∂17-Dec-85  1026	vanroggen%bizet.decnet@hudson.dec.com 	more comments   
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 17 Dec 85  10:23:32 PST
Date: 17 Dec 85 11:50:00 EST
From: "BIZET::VANROGGEN" <vanroggen%bizet.decnet@hudson.dec.com>
Subject: more comments
To: "common-lisp" <common-lisp@su-ai.ARPA>
cc: vanroggen   
Reply-To: "BIZET::VANROGGEN" <vanroggen%bizet.decnet@hudson.dec.com>
Comments on clarifications/minor changes:

1   UNDO is too vague.
    I suggest something like either
    (UNPROCLAIM '(CONSTANT FOO)) or (PROCLAIM '(NOTCONSTANT FOO))
    Same for SPECIAL. We'll need a PROCLAIM CONSTANT too.
    But wait--what will it mean to make incompatible proclamations?
    As is said in [clarification 56,58], redefining a constant is
    an error. Then surely making a constant a variable ought to be
    at least as dangerous.
    This problem is more general than just wanting to be able to "undo"
    a definition--we need to decide how to change definitions. For
    example, if one first (PROCLAIM '(FTYPE (FUNCTION STRING INTEGER) FOO))
    and then (DEFUN FOO (S I) (DECLARE (TYPE SEQUENCE S) (TYPE FIXNUM I))
    ...), is the DECLARE in error or does it supersede the proclamation,
    or does it just shadow the proclamation for the body of the function?
    What if later (DEFUN FOO (A B C) (DECLARE (FLOAT A B C)) ...)?
    Or if there's a PROCLAIM to that effect?
    I hope we can define some reasonable behavior, but I think there will
    always be some conflict between "static" proclamations and the "dynamic"
    redefinitions done during program development until some notion of
    "state" is introduced.
    Also, should DEFVAR update the documentation string even when
    the variable already had a value and thus didn't get reset?

47  The problem with the idiosyncratic use of &REST in a function type
    specifier is that we really need a more general list-type description
    without resorting to arbitrary predicates. Although &REST (INTEGER 0)
    is a cute idea, I'm mildly opposed.

60  Yes, "an error" to have two parameters be the same symbol. I assume
    "same (EQL) name" isn't really meant here, since the following should
    be OK: (DEFUN FOO (PACK1:X PACK2:X) ...)

82  XOR seems to be stretching the analogy between control constructs and
    logical operations a bit. BTW, there ought to be a mention of EVERY and
    SOME in the descriptions of AND and OR if one wants to apply their
    functionalities.

107,144 Would life, the language, and everything be simpler if MACROLET
    didn't exist?

145 I'd prefer (BODY &OPTIONAL DOCP ENV) for PARSE-BODY where DOCP
    defaults to NIL.

145 Is it OK to destroy the non-top-level list provided by &REST? Should
    this be different for macros than for functions?

158 No, this should be an error only if the types conflict.

161 Should be OK if there are fewer returned values if they still match
    the type specified. (I.e., if NIL is TYPEP the given type).

249 Hmmm. For now we can state that circular lists are "an error", just
    so the language can be more precisely defined.

307 Also watch out for a slot named "P".

321 EVAL doesn't need an environment arg--what's wrong with the existing
    EVALHOOK function?

439 I didn't mean that COMPILE had to save the interpreted definition for
    COMPILEDP to potentially return. Rather, +if+ COMPILE had saved it,
    COMPILEDP would return it and UNCOMPILE would restore it. Also, COMPILEDP
    is supposed to work on names and can be true for macros (and special
    forms, though that's not relevant), which distinguishes it from
    COMPILED-FUNCTION-P. COMPILEDP should be false for a closure over a
    compiled function, but COMPILED-FUNCTION-P should be true.

			---Walter
------

∂17-Dec-85  1129	edsel!jonl@su-navajo.arpa 	Functions for special operators  
Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 17 Dec 85  11:29:09 PST
Received: by su-navajo.arpa with Sendmail; Tue, 17 Dec 85 11:26:10 pst
Received: by edsel.uucp (2.2/SMI-2.0)
	id AA04609; Tue, 17 Dec 85 10:51:50 pst
Date: Tue, 17 Dec 85 10:51:50 pst
From: edsel!jonl@su-navajo.arpa (Jon L White)
Message-Id: <8512171851.AA04609@edsel.uucp>
To: navajo!common-lisp@su-ai
Subject: Functions for special operators


[Following what appeared to be the majority opinion of some time ago, I'm 
refering to "special forms" as "special operators"]

It's certainly consistent with the rest of Common Lisp for symbol-function
of a special operator to be "is an error" -- early versions of VAX/NIL put
a "trap" function there, with the interpreter dispatching through a table
which was completely independent of the symbol's function cell.  Putting 
any old random value [like, NIL] in the symbol-function cell would be also 
be consistent.

But this does beg a question of implementation technology.  Background on
this "question" is the following assertion, rooted in antiquity:
  ''The only "special operators" needed by Lisp are Lambda and Quote''
[sure, the lambda calculus reduced it to only one -- lambda -- but before
extending the discussion on this point, try to remember that Lisp isn't
exactly the lambda calculus].  For example, COND could be implemented as
a macro
  (defmacro COND (&rest clauses)
     `(COND-SUBR (QUOTE ,clauses)))
and then COND-SUBR would be written in the typical way that parts of an
interpreter are written.   So it may appear that putting the code for
COND-SUBR directly into the symbol-function cell of COND is perfectly fine, 
and maybe even a good way to distribute the code of the interpreter.  After 
all, it is only *how* the interpreter goes about fetching an argument for 
COND that is somewhat odd; after the fetch has been completed, it doesn't 
matter whether it dispatches through the symbol-function cell of COND, or 
to another function obtained in another manner.

The three implementation technologies I've seen over the years are:
  1) essentially nothing in the symbol-function cell of special operators;  
     the interpreter "discerns" and dispatches all special operators through 
     some other mechanism such as the table mentioned above;  the compiler 
     also has a lot of special cases in it for them.  Although this may be
     closer to the spirit of CLtL, section 5.1.3, it is less commonly used.
  2) extend the set of applicable, function-like objects to include FSUBRs
     and MSUBRs; the former, when found in a symbol's function cell, makes
     it a special operator, and the latter, when found in a symbol's function 
     cell, makes it a macro.  The beauty of this approach is that it 
     disconnects the macro/special-operator question from any property of 
     the particular symbol which holds it;  this is generally good since it
     supports renaming easily, but it really isn't feasible for a Common Lisp 
     implementation -- as page 57 of CLtL says "... the predicates
     'macro-function' and 'special-form-p' may both be true of the same
     symbol".  Nevertheless, it has been used in other Lisp implementations.
  3) a variant of (2) -- only true functions are put into the symbol-function
     cell, but some other property of the symbol [like, a bit in a "header"
     word?] determines whether the meaning of that function is FSUBR of MSUBR.

There seems to be some good advantage to upgrading the macro-function idea
into an MSUBR, for it would simplify code which moves definitions around.
The mark against upgrading special operators into FSUBRs, however, is the 
explicit desire of CLtL *not* to facilitate "moving special operators around" 
except where there is also a macro definition (which would, of course, occupy 
the symbol-function cell).
    

-- JonL --


P.S. Nit-picking addenda:
     (i)  "symbol-function cell" merely means a certain data abstraction, and
          doesn't constrain the implementational technology.
     (ii) the above macro definition for COND won't really work -- it would
          at least have to have an &environment argument -- but it is only
          a simplification for purposes of illustration.


∂17-Dec-85  1129	edsel!jonl@su-navajo.arpa 	"lexical" globals?
Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 17 Dec 85  11:29:02 PST
Received: by su-navajo.arpa with Sendmail; Tue, 17 Dec 85 11:26:01 pst
Received: by edsel.uucp (2.2/SMI-2.0)
	id AA04592; Tue, 17 Dec 85 10:50:24 pst
Date: Tue, 17 Dec 85 10:50:24 pst
From: edsel!jonl@su-navajo.arpa (Jon L White)
Message-Id: <8512171850.AA04592@edsel.uucp>
To: navajo!ram@c.cs.cmu.edu
Cc: navajo!common-lisp@su-ai
Subject: "lexical" globals?


Distinguishing dynamic variables from truly global variables came up at
Lucid last spring, and I think (but am not fully sure) that what you
are calling "lexical globals" is subsumed by the general issue of having
a GLOBAL declaration/proclamation.   I've appended to the end of this note 
the paper I circulated back then to a couple dozen people.  Since it wasn't 
a pressing issue, we didn't raise it in the mailing list, although I spoke,
verbally, at length with a few more people about the problem [in particular, 
GLS, since I had imagined that ThinkCo would be interested in deep-bound 
implementations of Common Lisp].

The reason that I'm not 100% sure that simple global variables cover what
you are calling "lexical globals" is the volume of discussion about
   (let ((a <some-value>))
     (defun foo ...)
     (defun bar ...))
In this example, it's entirely possible that a "global" value cell for "a" 
will be allocated, which is essentially different from the top-level global 
value for "a".  Something like this is possible with "block compilation" in 
Interlisp -- the BLOCK declaration disconnects most of the names appearing 
therein from the outside world, and the compiled image doesn't even have to 
have symbols existing with those names (because the code is compiled in a
fashion similar to the more vanilla, strongly-typed languages,in which "global
variables" are just names for specific runtime memory cells). 

Also, some comments in the recent discussion seem to be misleading as to
how a deep-bound implementation works;  there is no "re-binding" of the
toplevel global value cell, but rather a stackframe which binds a special
variable will have a value cell right in that frame (and will also have the 
name of the variable in the frame, at least implicitly if not directly
present in the frame).  I'm not sure if there is a good reference on deep
binding in general -- the "spaghetti stack" papers are one source -- but
several implementations which I've seen have independently invented similar
sorts of "wheels" for accelerating performance.  [Or, at least they did so 
after a year's experience using the "oval wheels" they started out with!]

Perhaps you, and/or the other people who have volunteered opinions on this 
topic, can comment on whether a GLOBAL declaration, in parallel to the SPECIAL
declaration, would be satisfactory; or whether there is a need for a more 
scheme-like mechanism also.

-- JonL -- 




---------------------------------------------------------------------------
A "white paper" from March 1985
---------------------------------------------------------------------------

    A serious shortfall exists in the defined capabilities for treating
variables either as global or as dynamic, which will badly impact the user
trying to write sensible code runnable both in a deep bound implementation 
and in a shallow bound one.  Common Lisp has gone on record as not being
limited to shallow-bound implementations, and with the appearance of
multi-processor work-stations and "computers", the issue of a deep-bound
implementation of CL is coming to reality.

    This note is rather long, so I've organized the remainder into
four sections, with the the more important items first.
  ** Statement of the Problem
  ** Comparisons with Deep- and Shallow-Bound Interlisps
  ** A Noticeable Semantic Distinction 
  ** Benefits of Distinction


                   Statement of the Problem

    In Commonlisp Lisp, there is no means to specify that a variable's
references are "global" rather than dynamic [of course, this only applies 
to free variable references -- global variables may not be bound].  
Section 5.3.2 of the CL manual recommends 'defvar' as the means to declare 
a variable as special, and (unwisely, I think) suggests this as the means of 
defining "globally defined variables"; defconstant adddresses an issue not
really related to "variables", but rather to named constants (i.e., you cannot
setq a symbol which has been defined by defconstant); defparameter isn't
quite right either, depending on one's implementation (most implementations
I've seen cause defparamater to do a SPECIAL proclaimation on the variable).

         Comparisons with Deep- and Shallow-Bound Interlisps

    Interlisp-10 is a shallow-bound implementation, whereas Interlisp-D and 
Interlisp/VAX are deep bound; so this problem of distinction has already been 
faced in that world.  Since the shortfall is hardly perceptible to the user 
of a shallow-bound implementation, I recommend reading that part of the 
Interlisp reference manual dealing with the differences between the functions 
GETTOPVAL, GETATOMVAL, and EVALV.  [This is found in section 2.4.1 of the 
Oct 1983 version of the IRM, and at the end of section 5.1 of the Oct 1978 
version].   The comments therein about performance implications are not just 
theoretical, but have been observed to account for an order-of-magnitude 
difference between a poorly ported application and a properly ported one.  
Interlisp's EVALV corresponds by definition to CL's 'symbol-value'  
[note well: symbol-value is *not* defined by reference to a "value cell", 
but rather to the dynamic binding environment]; but there is no CL equivalent 
to GETTOPVAL, and GETATOMVAL.


                       A Proffered Solution

    Actually, defvar "proclaims" a variable to be special; to meet the 
problems of this shortfall, there would need to be a declaration of globality
for variables, just as there is a declaration of dynamic scoping for them (see
the "special" section of section 9.2 in the manual).  The observable 
differences between a variable of global scope and one of dynamic, or special,
scope are:
  (1) it is an error to bind a global variable, but setq'ing is ok; and 
  (2) a deep-bound implementation would do a "shallow" value-cell fetch
      for global references, rather than the kind of free-variable lookup 
      it must do for dynamic references.
Additionally, there should be a 'defglobalvar' which proclaims a variable to 
be of global scope, just as defvar proclaims one to be of dynamic scope.


                A Noticeable Semantic Distinction 

    In addition to the perceived performance loss (in the deep-bound case)
of not making accurate global declarations, there is in fact a semantic
difference discernible in both deep and shallow.  
    (setq x "Topval for x")
    (defun lookat () 
      (let ((x "Random dynamic val for x")) 
           (declare (special x)) 
           (list (see-special) (see-global))))
    (defun see-special () (declare (special x)) x)
    (defun see-global () (declare (global x)) x)
When the global declaration is correctly done, the result of (lookat) will
be ("Random dynamic val for x"  "Topval for x") rather than
("Random dynamic val for x"  "Random dynamic val for x")
[Let me forstall any side-tracking discussion about the inadvisibility of 
using a variable both globally and specially in the same module.  This example 
is only for illustrative purposes;  the issue is really the protection of 
one module's usages against those of others, just as a local variable in one 
function needs to be sheilded from the dynamic bindings in another, lexically 
different, function.]


                    Benefits of Distinction

    For the record, I will say that I believe programmers have in general 
overused dynamic variables in the past, ** particularly when attempting to
define global state variables -- I've seen a lot of code that mistakenly 
defines some global variable, which in fact holds something that is process
dependent, or application dependent.   I think this will change in the future,
due to the influence of Scheme and to the insistence by this community for 
correct lexical scoping in Lisp interpreters.  This statement is only a 
generalization, but it comes from observing much code that had to be re-thought
very carefully in the face of a multi-processing Lisp.  One must distinguish 
global state in a machine, 
    such as *modules*  (section 11.8 of CL manual), 
    or, say, *network-routing-table*
from dynamic state
    such as *package* or *read-base*
    or, say, *standard-output* (which will be process-specific, at least)
Properly used, each has their own place, that will become more individually
secure as deep-bound implementations of CL come into being.


-- JonL --

∂17-Dec-85  1633	KMP@SCRC-STONY-BROOK.ARPA 	XOR
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 17 Dec 85  16:32:45 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 375936; Tue 17-Dec-85 10:44:57-EST
Date: Tue, 17 Dec 85 10:45 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: XOR
To: DCP@SCRC-QUABBIN.ARPA, gls@THINK-AQUINAS.ARPA,
    Moon@SCRC-STONY-BROOK.ARPA, Steele@THINK-AQUINAS.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <851216164401.5.DCP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <851217104550.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Mon, 16 Dec 85 16:44 EST
    From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
    Subject: XOR
    To: Guy Steele <gls@THINK-AQUINAS.ARPA>, Moon@SCRC-STONY-BROOK.ARPA,
	Steele@THINK-AQUINAS.ARPA
    cc: Common-Lisp@SU-AI.ARPA
    In-Reply-To: <851216130507.6.GLS@THINK-JEHOSEPHAT.ARPA>
    Message-ID: <851216164401.5.DCP@NEPONSET.SCRC.Symbolics.COM>

	Date: Mon, 16 Dec 85 13:05 EST
	From: Guy Steele <gls@THINK-AQUINAS.ARPA>

	    Date: Sun, 15 Dec 85 16:35 EST
	    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>

	    The XOR function in your list of suggested language improvements
	    handed out last week was intended to be a joke, wasn't it?  I assumed
	    it was, but other people on the mailing list are taking it seriously,
	    so I'm asking for clarification.

	Of all the functions not in Common Lisp that I use day-to-day on my
	3600, this is the one I use most frequently.  I admit that I have been,
	among other things, constructing logic models of various kinds.
	However, I also find it useful in random COND clauses.  Maybe the rest
	of you will decide it is not useful, but in any case it is not a joke.

    One argument I have heard against XOR is that, unlike AND and OR, it
    must evaluate all of its forms.

Actually, that doesn't bother me. All three share the property that they evaluate
forms left to right until they have enough information to decide. The fact that
"enough information" is available early for AND and OR shouldn't be held against
XOR, which has other great properties to offer in exchange.

    Of course, MLB once sent an amusing thing describing an XOR that returns
    the right answer but somehow knows what the forms evaluate to so it can
    stop early after the things it doesn't know a priori !-}

(:- Sure. eg, (WITHOUT-INTERRUPTS (XOR (FOO) (NOT (CAR X)) (CAR X))) :-)

On the more serious side, if we did introduce XOR, people might eventually
want reasonable answers to the following related issues, which would be left
open...

 * Why is OR not called IOR? (Or, why is LOGIOR not called LOGOR)

 * Why aren't there special forms called NAND, NOR, CLR, SET(!), EQV, 
   ORC1, ANDC2, ... which do the other logical operations. If there were,
   such forms (whatever they were named), some would have very peculiar 
   rules about when evaluation could be allowed to stop, and I'm not sure 
   if I'd want to have to learn them.

Certainly I've had a lot more use for NAND and NOR than for XOR.

A possibly reasonable alternative proposal might be to introduce a full set of
functional (ie, not special form) versions of all these operators. That way, we'd
simulataneously solve the problem that AND and OR cannot be applied (by providing
functions that could be). eg, just as a straw man I'll propose *AND, *IOR, *XOR,
*CLR, *SET, *EQV, *ORC1, ... Such functions could be known the the compiler and
interestingly optimized in predicate positions without needing to be special forms.
Also, (MAPCAR #'*AND (FOO)) or (APPLY #'*XOR (BAR)) would be possible.

∂17-Dec-85  2126	KMP@SCRC-STONY-BROOK.ARPA 	XOR
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 17 Dec 85  16:32:45 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 375936; Tue 17-Dec-85 10:44:57-EST
Date: Tue, 17 Dec 85 10:45 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: XOR
To: DCP@SCRC-QUABBIN.ARPA, gls@THINK-AQUINAS.ARPA,
    Moon@SCRC-STONY-BROOK.ARPA, Steele@THINK-AQUINAS.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <851216164401.5.DCP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <851217104550.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Mon, 16 Dec 85 16:44 EST
    From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
    Subject: XOR
    To: Guy Steele <gls@THINK-AQUINAS.ARPA>, Moon@SCRC-STONY-BROOK.ARPA,
	Steele@THINK-AQUINAS.ARPA
    cc: Common-Lisp@SU-AI.ARPA
    In-Reply-To: <851216130507.6.GLS@THINK-JEHOSEPHAT.ARPA>
    Message-ID: <851216164401.5.DCP@NEPONSET.SCRC.Symbolics.COM>

	Date: Mon, 16 Dec 85 13:05 EST
	From: Guy Steele <gls@THINK-AQUINAS.ARPA>

	    Date: Sun, 15 Dec 85 16:35 EST
	    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>

	    The XOR function in your list of suggested language improvements
	    handed out last week was intended to be a joke, wasn't it?  I assumed
	    it was, but other people on the mailing list are taking it seriously,
	    so I'm asking for clarification.

	Of all the functions not in Common Lisp that I use day-to-day on my
	3600, this is the one I use most frequently.  I admit that I have been,
	among other things, constructing logic models of various kinds.
	However, I also find it useful in random COND clauses.  Maybe the rest
	of you will decide it is not useful, but in any case it is not a joke.

    One argument I have heard against XOR is that, unlike AND and OR, it
    must evaluate all of its forms.

Actually, that doesn't bother me. All three share the property that they evaluate
forms left to right until they have enough information to decide. The fact that
"enough information" is available early for AND and OR shouldn't be held against
XOR, which has other great properties to offer in exchange.

    Of course, MLB once sent an amusing thing describing an XOR that returns
    the right answer but somehow knows what the forms evaluate to so it can
    stop early after the things it doesn't know a priori !-}

(:- Sure. eg, (WITHOUT-INTERRUPTS (XOR (FOO) (NOT (CAR X)) (CAR X))) :-)

On the more serious side, if we did introduce XOR, people might eventually
want reasonable answers to the following related issues, which would be left
open...

 * Why is OR not called IOR? (Or, why is LOGIOR not called LOGOR)

 * Why aren't there special forms called NAND, NOR, CLR, SET(!), EQV, 
   ORC1, ANDC2, ... which do the other logical operations. If there were,
   such forms (whatever they were named), some would have very peculiar 
   rules about when evaluation could be allowed to stop, and I'm not sure 
   if I'd want to have to learn them.

Certainly I've had a lot more use for NAND and NOR than for XOR.

A possibly reasonable alternative proposal might be to introduce a full set of
functional (ie, not special form) versions of all these operators. That way, we'd
simulataneously solve the problem that AND and OR cannot be applied (by providing
functions that could be). eg, just as a straw man I'll propose *AND, *IOR, *XOR,
*CLR, *SET, *EQV, *ORC1, ... Such functions could be known the the compiler and
interestingly optimized in predicate positions without needing to be special forms.
Also, (MAPCAR #'*AND (FOO)) or (APPLY #'*XOR (BAR)) would be possible.

∂17-Dec-85  2157	JAR@MIT-MC.ARPA 	"lexical" globals?
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 17 Dec 85  21:38:24 PST
Date: Tue, 17 Dec 85 23:47:46 EST
From: Jonathan A Rees <JAR@MIT-MC.ARPA>
Subject:  "lexical" globals?
To: edsel!jonl@SU-NAVAJO.ARPA
cc: common-lisp@SU-AI.ARPA, ram@C.CS.CMU.EDU
In-reply-to: Msg of Tue 17 Dec 85 10:50:24 pst from edsel!jonl at su-navajo.arpa (Jon L White)
Message-ID: <[MIT-MC.ARPA].758912.851217.JAR>

    Date: Tue, 17 Dec 85 10:50:24 pst
    From: edsel!jonl at su-navajo.arpa (Jon L White)

    Perhaps you, and/or the other people who have volunteered opinions on this 
    topic, can comment on whether a GLOBAL declaration, in parallel to the SPECIAL
    declaration, would be satisfactory; or whether there is a need for a more 
    scheme-like mechanism also.

I liked your message.  I think that a (PROCLAIM '(GLOBAL FOO))
proclamation would do the trick.  A DEFGLOBAL macro analogous to DEFVAR
would be convenient, and symmetrical with DEFVAR and the other DEF's.

Much as I like the feature, I think that adding the full generality of
the MIT/Yale Schemes' fluid-let would confuse too many people and anger
too many implementors.  I only mentioned it for its educational value.

As far as forbidding LAMBDA-binding of globals, this hadn't occurred to
me, but it's probably the right thing, for similar reasons.  Again, I'm
a fan of block structured languages, but Common Lisp simply is NOT block
structured, and this feature would be too confusing.  Forbidding
lambda-binding globals sort of defeats the idea of lexical scoping, but
then so does (PROCLAIM '(SPECIAL ...)).  Also, it's a conservative
approach, since it doesn't preclude possible later relaxation of the
language.

If Common Lisp hadn't re-cycled LAMBDA for the two different purposes of
lexical and dynamic binding, we wouldn't be having these problems now.
But c'est la vie.  I can't really complain, since I didn't make a stink
about it when the decisions were being made.  Maybe we'll get it right
next time around.

∂17-Dec-85  2213	mcvax!delphi.UUCP!beppe@seismo.CSS.GOV 	mailing list   
Received: from SEISMO.CSS.GOV by SU-AI.ARPA with TCP; 17 Dec 85  21:41:18 PST
Return-Path: <mcvax!delphi.UUCP!beppe>
Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Wed, 18 Dec 85 00:37:39 EST
From: mcvax!delphi.UUCP!beppe@seismo.CSS.GOV
Received: by mcvax.UUCP; Wed, 18 Dec 85 05:56:13 +0100 (MET)
Received: by mcvax.UUCP; Wed, 18 Dec 85 05:56:03 +0100 (MET)
Received: by delphi.uucp (2.0/SMI-2.0)
	id AA20558; Tue, 17 Dec 85 16:50:45 -0100
Date: Tue, 17 Dec 85 16:49:05 MET
Subject: mailing list
To: common-lisp@su-ai.arpa
Message-Id: <85/12/17 1649.144@delphi>

Could you please add my name to the Common Lisp mailing list?

Thank you.

Giuseppe Attardi

∂18-Dec-85  0330	cfry%MIT-OZ@MIT-MC.ARPA 	Re: clarifications  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Dec 85  03:30:41 PST
Received: from MIT-JANIS by MIT-OZ via Chaosnet; 18 Dec 85 06:30-EST
Date: Wed, 18 Dec 85 06:30 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: Re: clarifications
To: masinter.pa@XEROX.ARPA, cfry@OZ.AI.MIT.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851216-143751-1352@Xerox>
Message-ID: <851218063059.1.CFRY@JANIS.AI.MIT.EDU>

    Some pathnames don't denote disks, and yet "free-space" is a meaningful
    concept. Why not "free-space" or "file-free-space" at least, instead of
    "disk-free-space"?
Yes. You've helped clarify the intended semantics which is,
If I saved a file with pathname P, how big could it be before
it ran out of room?
"free-space" could mean: how much virtual memory have I got left?
"file-free-space" disambiguates, however, we might want to disambiguate
based on the type of the argument [with maybe a few keywords].

There could be a whole set of free-space functions for:
virtual-memory [ROOM prints out a user useful answer, not a number that
                could be used by a program]
arrays         [returns number of elements between fill pointer and the
                real length]
numbers of various kinds  [how much more they can grow before they reach
               their limit. If number is negative, how much more they
               can grow downward? This should probably be disambiguated with
               a keyword. One problem is, you'd like to return a number of the
               same type, which would be impossible to do for, say, a number
               that was negative, to represent the distance to its positive max.]
hash-table    [how much room before a rehash is necessary. This is necessarily 
               implementation dependent
               Also, if there is a maximum size for a hash-table, how much
               room until then?]          
package        how many more symbols can I stick in this package
readtable      how many dispatch macros are undefined for the dispatch char
               C,  which would default to #   .
stream         You might want to open a stream for writting and specify a
               limit. Free-space would tell you how far until that limit.
list
sequence

For lists and sequences, you might be adding to them sequentially, after having
               initially creted them with some "empty" value such as NIL.
               free-space could find out how much space there was from the end
               until the first "non-empty" element. The empty value would default to nil.

Think of free-space like we've been thinking of undo, copy, setf ....
a generally useful concept that can be reasonably applied to a lot
of different data types.
It would make it easier to implement this free-space in terms of
another class of fns, SIZE or LENGTH.  
There is already an attempt to make LENGTH work generically 
in sequences. Why not with files, etc?
In fact, a bunch of the sequence operators could be meaningfully
applied to other data types. 

I recognize that these concepts mesh
with ideas from new flavors and commonloops.  

∂18-Dec-85  0701	preece%ccvaxa@gswd-vms 	Re: XOR    
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 18 Dec 85  07:01:42 PST
Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.9/5.6)
	id AA00787; Wed, 18 Dec 85 09:02:27 CST
Message-Id: <8512181502.AA00787@gswd-vms.ARPA>
Date: Wed, 18 Dec 85 09:02:19 cst
From: preece%ccvaxa@gswd-vms (Scott E. Preece)
To: COMMON-LISP@su-ai.arpa
Subject: Re: XOR

   /**** ccvaxa:commonlisp / KMP@SCRC-STON / 11:42 pm  Dec 17, 1985 ****/
   From @SU-AI.ARPA:KMP@SCRC-STONY-BROOK.ARPA  Tue Dec 17 23:41:59 1985
   From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
   Subject: XOR
           Steele@THINK-AQUINAS.ARPA
   In-Reply-To: <851216164401.5.DCP@NEPONSET.SCRC.Symbolics.COM>
   Message-Id: <851217104550.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

   ...
   
   On the more serious side, if we did introduce XOR, people might eventually
   want reasonable answers to the following related issues, which would be left
   open...
   
    * Why is OR not called IOR? (Or, why is LOGIOR not called LOGOR)
----------
Actually, I don't like calling GLS's proposed function XOR.  An
exclusive or should be true if exactly one of the arguments is
true, not if any odd number of arguments is true.  The proposed
XOR isn't exclusive enough ...

-- 
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece

∂18-Dec-85  0842	@MC.LCS.MIT.EDU:RAMBO@AI.AI.MIT.EDU 	recent request for assistance    
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Dec 85  08:38:23 PST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 18 DEC 85  11:40:47 EST
Date: Wed, 18 Dec 85 11:39:11 EST
From: RAMBO%AI.AI.MIT.EDU@MC.LCS.MIT.EDU
Subject: recent request for assistance
To: dlw@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA
Message-ID: <[AI.AI.MIT.EDU].8969.851218.RAMBO>

We learned of this through our usual sources inside the DIA. I
am at your disposal if the need arises. For all the overworked
implementors on this mailing list, may I suggest the relaxation of
my winter insurgency training camp.

∂18-Dec-85  1153	Gregor.pa@Xerox.ARPA 	what do :copiers do?   
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 18 Dec 85  11:53:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 18 DEC 85 11:23:17 PST
Date: 18 Dec 85 11:23 PST
From: Gregor.pa@Xerox.ARPA
Subject: what do :copiers do?
To: common-lisp@SU-AI.ARPA
Message-ID: <851218-112317-1434@Xerox>

Assuming that the functionality of being able to copy a structure and
get back a structure of the same type and the functionality of being
able to copy a particular "sub-type part" of a structure are worthwhile,
here is a scheme which seems nice:

   Remember that: 
   (defstruct person name)
   (defstruct (astronaut (:include person)) helmet-size)

In the scheme I am proposing:
- copy-person of an astronaut returns a person
- a "new" function, copy, which given an astronaut returns an astronaut

More abstractly, 
COPY-xxx as defined by a defstruct returns a structure  of that
defstruct's type.

COPY returns a structure of the same type as its argument.

∂19-Dec-85  0932	gls@THINK-AQUINAS.ARPA 	XOR   
Received: from THINK.COM by SU-AI.ARPA with TCP; 19 Dec 85  09:32:49 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Thu, 19 Dec 85 12:32:45 est
Date: Thu, 19 Dec 85 12:32 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: XOR
To: KMP@SCRC-STONY-BROOK.ARPA, DCP@SCRC-QUABBIN.ARPA, gls@THINK-AQUINAS.ARPA,
        Moon@SCRC-STONY-BROOK.ARPA, Steele@THINK-AQUINAS.ARPA
Cc: Common-Lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <851217104550.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <851219123258.6.GLS@THINK-JEHOSEPHAT.ARPA>

    Date: Tue, 17 Dec 85 10:45 EST
    From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>

     * Why is OR not called IOR? (Or, why is LOGIOR not called LOGOR)

I dunno.  That goes way back into history.

     * Why aren't there special forms called NAND, NOR, CLR, SET(!), EQV, 
       ORC1, ANDC2, ... which do the other logical operations. If there were,
       such forms (whatever they were named), some would have very peculiar 
       rules about when evaluation could be allowed to stop, and I'm not sure 
       if I'd want to have to learn them.

One problem is that NAND and NOR are not associative.  They could reasonably
be restricted to being two-place.  So could XOR, for that matter.

∂19-Dec-85  0935	gls@THINK-AQUINAS.ARPA 	READ-DELIMTED-LIST and dots    
Received: from THINK.COM by SU-AI.ARPA with TCP; 19 Dec 85  09:35:09 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Thu, 19 Dec 85 12:35:08 est
Date: Thu, 19 Dec 85 12:35 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: READ-DELIMTED-LIST and dots
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <851219123523.7.GLS@THINK-JEHOSEPHAT.ARPA>

I propose that READ-DELIMITED-LIST be extended by adding one
more optional argument, dot-permitted-p, defaulting to nil,
that if true allows the delimited list to contain dot notation,
and if false forbids dot notation.

Right now the manual does not address the question of dot notation
in this context, and at least one implementation does not
permit dot notation in delimited lists, which makes that function
useless for simulating the action of "(".

∂19-Dec-85  1346	Masinter.pa@Xerox.ARPA 	fonts in CLtL   
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 19 Dec 85  13:46:37 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 DEC 85 13:46:28 PST
Date: 19 Dec 85 13:09 PST
From: Masinter.pa@Xerox.ARPA
Subject: fonts in CLtL
To: common-Lisp@su-ai.ARPA
Message-ID: <851219-134629-1475@Xerox>

Are there any implementations which use a value of CHAR-FONT-LIMIT other
than 1, or a non-vacuous definition for CHAR-FONT? If not, could we
remove this feature from the language? (Under the theory that "optional"
features which no implementation uses should be removed from the
specification.)

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

Return-Path: <Moon@SCRC-STONY-BROOK.ARPA>
Received: from SCRC-STONY-BROOK.ARPA by Xerox.ARPA ; 17 DEC 85 18:18:31
PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via
CHAOS with CHAOS-MAIL id 376532; Tue 17-Dec-85 20:48:14-EST
Date: Tue, 17 Dec 85 20:43 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: fonts in CLtL
To: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>, masinter.pa
cc: rpg@SU-AI.ARPA, sybalsky.pa
In-Reply-To: <851216230521.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-ID: <851217204330.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 16 Dec 85 23:05 EST
    From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>

	Date: 16 Dec 85 15:11 PST
	From: masinter.pa@Xerox.ARPA

	It was my impression looking over the latest Symbolics documentation
	that Symbolics has moved away from using font-bits in characters. We've
	found them impossible -- they don't contain enough information. If
there
	aren't any other implementations that use font-bits, maybe we could get
	rid of them.

	I thought I'd ask privately before broadcasting.

    Yes, I proposed this recently and I think that we have agreed to do
it.
    Our model of character styles does not include any mapping from
integers
    to styles (fonts) that is suitable for Common Lisp's model of the
font
    attribute.  (There is a mapping, but its lifetime is only over one
Lisp
    environment, so it would be meaningless to say #3\A in a file.)

    (I've CC'ed Moon so he can correct me if necessary.)

The above is all correct.  CHAR-FONT-LIMIT will be 1 in our next
release, CHAR-FONT will always return 0, and we will have a field in
characters, whose value is an instance rather than an integer, that
doesn't pretend to be any of the Common Lisp character fields.

NB: None of this has anything to do with CHAR-BITS, which we make good
use of.


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

∂19-Dec-85  2051	apollo!dfm@uw-beaver.arpa 	GLS's clarifications list (moderately long)
Received: from UW-BEAVER.ARPA by SU-AI.ARPA with TCP; 19 Dec 85  20:51:39 PST
Received: by uw-beaver.arpa (4.42/4.2)
	id AA03243; Thu, 19 Dec 85 20:53:17 PST
Return-Path: <apollo!dfm@uw-beaver.arpa>
Message-Id: <8512200453.AA03243@uw-beaver.arpa>
From: apollo!dfm@uw-beaver.arpa
Date: Thu, 19 Dec 85 17:18:36 EST 
Subject:  GLS's clarifications list (moderately long)
To: COMMON-LISP@su-ai.arpa

Apologies if any of the following have been discussed and resolved before.


+ COMMON LISP's #n=/#n# syntax invites the creation of circular lists.  For
  example, the following seems more tasteful than the example with star, and
  is, I believe, fairly perspicuous:

    (mapcar #'cons p-list '#0=(property value . #0#))

  Another place where circular lists are useful is with progv.  Suppose I'm
  passed a list of dynamic variables to be bound and initialized to nil, but
  whose length I don't know.  Three obvious ways are (1) to cons up a list
  of nils at runtime, (2) write a recursive macro, and (3), the following, which
  seems clearest:

    (progv var-list '#0=(nil . #0#)
      ...)

  Whether circular arguments to such functions are allowed or forbidden, all
  the functions where folks might be tempted to use them may need to be identified,
  so an explicit "it is an error to pass a circular list ...,"  "implementations
  are required to support circular lists ...," or whatever can be put in their
  descriptions.  Alternatively some general rule, or possibly a table, can be
  constructed.  Since people can do some pretty tasteless things, the list
  of possibilities is quite large.  So far I've come up with the following,
  although I'm sure I've missed some:

    - map, every, some, notany, and notevery
    - mapc, mapcan, mapcar, mapcon, mapl, and maplist
    - the format directives ~?, ~{, ~:{, and ~:@{
    - progv
    - dolist
    - the following, so long as :end (or possibly :end1, :end2, or :count) is
      supplied, although for most of them I have a lot of trouble imagining why
      anyone would actually try to use a circular list:
        count, count-if, count-if-not, delete, delete-if, delete-if-not,
        fill, find, find-if, find-if-not, mismatch, nsubstitute, nsubstitute-if,
        nsubstitute-if-not, position, position-if, position-if-not, reduce,
        remove, remove-if, remove-if-not, remove-duplicates, replace, search,
        substitute, substitute-if, and substitute-if-not
    - getting even more far-fetched, if tests with side-effects are allowed
      (possibly in conjuction with :test or :test-if-not) a lot of the functions
      in the previous item together with the following are possibilities:
        assoc, assoc-if-not, member, member-if, member-if-not, adjoin, union,
        nunion, intersection, nintersection, set-difference, nset-difference,
        set-exclusive-or, nset-exclusive-or, subset, rassoc, rassoc-if,
        rassoc-if-not, and pushnew.
    - does GLS's clarification of (tailp '() L) imply that the following is legal?
        (tailp '() '#0=(x . #0#))

  I can imagine someone tastefully using everything down to and including dolist
  with circular lists, even though I'd never use most of them myself.  Below that
  everything seems a revolting quagmire, and should explicitly "be an error."

  Does COMMON LISP guarantee that we can successfully call inspect on a circular
  list or structure?  It should.

  A related clarification.  Not only can data be circular, so can code.
  It should probably "be an error" to try to eval something like

    (progn . #0=((f) . #0#))    ; an ugly way of saying (loop (f))


+       From:  SCRC-STONY-BROOK.arpa!KMP@uw-beaver.UUCP (Kent M Pitman)
        Certainly I've had a lot more use for NAND and NOR than for XOR.

  Xor might be useful in that it avoids having to either repeat an expression or
  introduce a let variable.  This is what distinguishes it from nand and nor.
  For example,
  
    (nand
      (one-of-my-special-expressions-p x)
      (apply (get (first x) 'dispatcher) (rest x)) )

  can be written 

    (not (and
           (one-of-my-special-expressions-p x)
           (apply (get (first x) 'dispatcher) (rest x)) ))

  which isn't much hairier, while
    
    (xor
      (one-of-my-special-expressions-p x)
      (apply (get (first x) 'dispatcher) (rest x)) )

  can be written        

    (if (one-of-my-special-expressions-p x)
      (not (apply (get (first x) 'dispatcher) (rest x)))
      (apply (get (first x) 'dispatcher) (rest x)) )

  or

    (let* ((x (one-of-my-special-expressions-p x))
           (y (apply (get (first x) 'dispatcher) (rest x))) )
      (if x (not y) y) )
 
  both of which are, I believe, hairier.

  Such reasoning led me write an xor several times.  But neither I nor anyone
  else ever used the ones I wrote, as far as I can tell.  Ever.  It probably has
  no place in the language, especially since the rare someone who actually needs
  it a lot can easily enough write one.


+ Regarding adding the functions hash-table-rehash-size, hash-table-rehash-threshold,
  hash-table-size, and hash-table-test: 

    - Would these be setf'able?  I would expect the first two could be done easily,
      and even the size and test can be changed by rehashing the table.

    - What does hash-table-test return?  'eql or #'eql?

  While on the subject of hash tables, here are a couple more points that have been
  bothering me:

    - Why is there no way to hash on arrays (other than bit-vectors and strings) and
      structures?  Should #'equalp hash tables also be supported?  Things I would
      have preferred to implement as structures I've implemented as lists, 
      defining accessors by hand, just so I can hash on them.

    - Shouldn't it be made explicit that hash tables may store the actual key,
      and that destructive operations should not be performed on it?  Or is this
      even true?  I suppose one might expect a #'eq hash table to continue working
      even if you mucked around with the keys stored in it, even though one would
      probably not expect that of a #'equal hash table (yuk).


+ Regarding requiring that implementations support tracing of macros:  What does
  it mean to trace a macro?  Do you just print information when the macro is
  expanded, or do you arrange to have information printed every time the expansion
  is eval'd?  There are LISPs out there doing it each way.


+ Regarding globals:  Standard LISP has the notion of a global.  Nearly every
  time I've modified a Standard LISP program that used globals extensively I've
  had to change one or two of them to fluids (i.e. special) because something the
  original implementor (often myself) thought no one would ever want to rebind I
  neede to rebind.  Even worse are the plethora of cases where somebody squirrels away
  a global's value in a local, and restores it on the way back out (at least doing
  this in COMMON LISP could be reasonably safe because of unwind-protect, which
  Standard LISP lacks).  Of course, these have always been shallow binding
  implementations, where specials come for nearly free.  I'd rather not see globals
  introduced into the language, but deep binding implementations may really need
  them,  and it would be better to have one, standard mechanism than have each
  deep binding implementation define its own incompatible one.


+ Not only would it be nice to be able to copy things involving structures, it
  would be nice to be able to walk an arbitrary LISP object, including going
  through structures.  As near as I can tell, there's no portable way to walk
  through the slots of an arbitrary structure.  For example, how could one write
  a recursive function which counted the number of occurances of the symbol 'foo
  in an arbitrary LISP object which might contain, at any level, arbitrary
  structures?  Have I missed something?  I get the feeling that there may have been
  a deliberate decision to not allow this, but I'm not sure why.
                           

+ I'm sure I'm being dense, but could someone explain two things from GLS's
  list of clarifications to me?

    - Why does (tailp '() L) return nil?  I would have expected it to always
      return t (I think that means that I would have thought the second sentence
      of the description was right, and the first sentence was incorrect).

    - Why does xor with more than two arguments do the odd/even stuff?  I would
      have expected it either to look for exactly one true value or exactly one
      false, but not something as random as an odd number of trues.


+ (-: The obvious way to have an all-purpose undo function is to generalize setf
      to work with an odd number of arguments:

        (setf (symbol-function 'foo))  =>  (undefun 'foo)
        (setf (symbol-value '*foov*))  =>  (mkunbound '*foov*)                  :-)


                                        - Don Morrison

∂20-Dec-85  1203	FAHLMAN@C.CS.CMU.EDU 	fonts in CLtL
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Dec 85  12:03:38 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 20 Dec 85 14:39:32-EST
Date: Fri, 20 Dec 1985  14:38 EST
Message-ID: <FAHLMAN.12168676959.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Masinter.pa@XEROX.ARPA
Cc:   common-Lisp@SU-AI.ARPA
Subject: fonts in CLtL
In-reply-to: Msg of 19 Dec 1985  16:09-EST from Masinter.pa at Xerox.ARPA


I believe that all of us at CMU (I'm sure I'll be corrected if I'm
wrong) feel that the fonts attribute in a character is worthless.  For
editor-like applications, it's too much work and too much wasted storage
to deal with this on a per-character basis.  It might be useful for
extended character sets (e.g. Greek or Japanese), but not for the usual
use of switching between various sizes and shapes of Roman characters.
It's much better to use an additional data structure for that.

I've felt for some time that the bits attribute is also a bit misguided.
It seems to me that there are two distinct concepts that have become
muddled together: input keystroke objects, which are probably keyborad
or system dependent and which want to represent things like the various
flavors of shift and whether a keystroke came from the alphanumeric area
or the numeric keypad, and internal characters in some implementation
independent encoding suitable for stuffing into strings or shoving into
an output stream.  The former has "bits" attached, but all you really do
with such things is pass them around, translate them to true characters,
dispatch on them, and maybe store them into a script of some sort.

This is not something to be changed lightly, but I agree with Masinter
that it is probably worth seeing whether anyone is really using these
thing sin the way that they were originally intended to be used.  If
nobody is, or if the people using them also feel that they are not the
right thing, then we should think hard about making a change.

-- Scott


∂20-Dec-85  1211	gls@THINK-AQUINAS.ARPA 	GLS's clarifications list (moderately long)   
Received: from THINK.COM by SU-AI.ARPA with TCP; 20 Dec 85  12:11:13 PST
Received: from wenceslas by GODOT.THINK.COM via CHAOS; Fri, 20 Dec 85 11:28:13 est
Date: Fri, 20 Dec 85 11:28 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: GLS's clarifications list (moderately long)
To: apollo!dfm@UW-BEAVER.ARPA, COMMON-LISP@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <8512200453.AA03243@uw-beaver.arpa>
Message-Id: <851220112818.5.GLS@THINK-WENCESLAS.ARPA>

    Date: Thu, 19 Dec 85 17:18:36 EST 
    From: apollo!dfm@uw-beaver.arpa


    + COMMON LISP's #n=/#n# syntax invites the creation of circular lists.  For
      example, the following seems more tasteful than the example with star, and
      is, I believe, fairly perspicuous:

	(mapcar #'cons p-list '#0=(property value . #0#))

Of course, the example with the STAR function:
    (mapcar #'cons baz (star 'foo))
allows the value to be calculated at run time.
The obvious way to do it with #n= syntax is to use backquote:
    (mapcar #'cons p-list `#0=(,property ,value . #0#))
but right now backquote is not defined to work on circular lists.
We could define it to do so (or maybe introduce `@ to handle the circular case).

      Does COMMON LISP guarantee that we can successfully call inspect on a circular
      list or structure?  It should.

I agree, but it isn't addressed explicitly.

      A related clarification.  Not only can data be circular, so can code.
      It should probably "be an error" to try to eval something like

	(progn . #0=((f) . #0#))    ; an ugly way of saying (loop (f))

A LISP for the IBM 370 developed at Yorktown by Fred Blair and
colleagues actually made this work in both interpreter and compiler.
Fred was very proud of it.

    + Regarding globals:  ...                       I'd rather not see globals
      introduced into the language, but deep binding implementations may really need
      them...

Actually, a trick that was designed for S-1 LISP may reduce the overhead
in deep-binding implementations:  let there be a counter associated with
the global value cell, initially zero.  Every time a deep binding of
that variable is created, the counter is incremented, and when the
binding is destroyed, the counter is decremented.  Lookup of a special
variable proceeds as follows: first check the global counter.  If it is
zero, just grab the global value cell.  Otherwise do the usual
deep-binding search.  Process-switching involves nothing new.  Note that
if there are several processes, they share a single counter.  The
counter merely serves as a hint: you might do the search even if you
didn't really have to (in the case where your process hasn't done a
special binding but some other process did), but in the truly global
case, no one has bound it and so the search is eliminated.  It does
increase the cost of the lookup in the special case, but only by a
single zero check.  One does have to be careful to destroy all bindings
(in order to adjust the counts) when a process is destroyed if the
efficiency is to be maintained.

    + (-: The obvious way to have an all-purpose undo function is to generalize setf
	  to work with an odd number of arguments:

	    (setf (symbol-function 'foo))  =>  (undefun 'foo)
	    (setf (symbol-value '*foov*))  =>  (mkunbound '*foov*)                  :-)

I would favor this quite a bit had not SETF been generalized to any even
number of argument forms rather than just two.  With the generalization,
the chances for accidental lossage are too great.  Maybe we could make one
argument form do an undo, but three or five would be illegal.

					    - Don Morrison

--Guy

∂20-Dec-85  1403	gls@THINK-AQUINAS.ARPA 	Multiple values and &optional  
Received: from THINK.COM by SU-AI.ARPA with TCP; 20 Dec 85  14:03:00 PST
Received: from wenceslas by GODOT.THINK.COM via CHAOS; Fri, 20 Dec 85 17:03:02 est
Date: Fri, 20 Dec 85 17:03 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Multiple values and &optional
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <851220170310.1.GLS@THINK-WENCESLAS.ARPA>

Just for the record, I had an application today where I really wanted to
write something like

	(MULTIPLE-VALUE-BIND (VALUE &OPTIONAL (FOUNDP T))
	    (FUNCALL (MAGIC-HOOK-FUNCTION THINGY) FUNNY-ARG)
	  (WHEN FOUNDP
	    (CACHE-SOME-STUFF THINGY FUNNY-ARG VALUE))
	  (VALUES VALUE FOUNDP))

The context was that I wanted to have a user hook for a GETHASH-like
protocol, where a second return value indicates whether or not a goodie
was actually found.  However, for convenience I wanted to allow the user
hook function to be any function that returns one thing as well, in
which case one assumes that the thing was found.  In short, I wanted the
second return value to default to T, not NIL.

I ended up writing this instead:

	(LET ((STUFF (MULTIPLE-VALUE-LIST
		       (FUNCALL (MAGIC-HOOK-FUNCTION THINGY) FUNNY-ARG))))
	  (WHEN (OR (NULL (CDR STUFF)) (CADR STUFF))
	    (CACHE-SOME-STUFF THINGY FUNNY-ARG (CAR STUFF)))
	  (VALUES-LIST STUFF))

--Guy

∂20-Dec-85  1636	DLW@SCRC-STONY-BROOK.ARPA 	GLS's clarifications list (moderately long)
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Dec 85  16:36:13 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 379983; Fri 20-Dec-85 19:35:18-EST
Date: Fri, 20 Dec 85 19:35 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: GLS's clarifications list (moderately long)
To: gls@THINK-AQUINAS.ARPA, apollo!dfm@UW-BEAVER.ARPA,
    COMMON-LISP@SU-AI.ARPA
In-Reply-To: <851220112818.5.GLS@THINK-WENCESLAS.ARPA>
Message-ID: <851220193530.7.DLW@CHICOPEE.SCRC.Symbolics.COM>

I would like to point out that you are discussing the implementation
details of "globals" before we have agreed what "globals" are.  There
were several interpretations of "globals" floating around on the mail
and no resolution of which one we were talking about.

∂20-Dec-85  2356	apollo!dfm@uw-beaver.arpa 	Re: Elegant rule for what to copy
Received: from UW-BEAVER.ARPA by SU-AI.ARPA with TCP; 20 Dec 85  23:55:56 PST
Received: by uw-beaver.arpa (4.42/4.2)
	id AA15611; Fri, 20 Dec 85 22:43:24 PST
Return-Path: <apollo!dfm>
Message-Id: <8512210643.AA15611@uw-beaver.arpa>
From: apollo!dfm@uw-beaver.arpa
Date: Fri, 20 Dec 85 10:49:08 EST 
Subject:  Re: Elegant rule for what to copy
To: uw-beaver!Rem%IMSSS
Cc: COMMON-LISP@su-ai.arpa

            From:  Rem@IMSSS@uw-beaver.UUCP
         Subject:  Elegant rule for what to copy
              To:  COMMON-LISP%SU-AI@SCORE
    
                                              Interned symbols (IDs) will be
    stop points, but GENSYMs will be recursed through, with another GENSYM of
    exactly the same name replacing it, and with copies of the value and plist
    and function. (In that case READing it back in would accidently INTERN all
    the former GENSYMs, so COPY is more "right" than PRIN1-READ.)

That's not quite right, at least if *print-gensym* has its default value of t.
Instead a gensym would be prin1'd using #: notation, and read back in as a new
gensym with the same print name but *not* with the same plist, value, or function.

∂21-Dec-85  1724	Moon@SCRC-STONY-BROOK.ARPA 	Multiple values and &optional   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 21 Dec 85  17:21:03 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 380091; Fri 20-Dec-85 22:32:47-EST
Date: Fri, 20 Dec 85 22:27 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Multiple values and &optional
To: Guy Steele <gls@THINK-AQUINAS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851220170310.1.GLS@THINK-WENCESLAS.ARPA>
Message-ID: <851220222705.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

MULTIPLE-VALUE-CALL.

∂21-Dec-85  1738	NGALL@BBNG.ARPA 	Re: Multiple values and &optional
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 21 Dec 85  17:37:57 PST
Date: 21 Dec 1985 18:20-EST
Sender: NGALL@BBNG.ARPA
Subject: Re: Multiple values and &optional
From: NGALL@BBNG.ARPA
To: gls@AQUINAS.THINK.COM
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[BBNG.ARPA]21-Dec-85 18:20:32.NGALL>
In-Reply-To: <851220170310.1.GLS@THINK-WENCESLAS.ARPA>

	
    Date: Fri, 20 Dec 85 17:03 EST
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>
    To: common-lisp@SU-AI.ARPA
    Subject: Multiple values and &optional
    Message-ID: <851220170310.1.GLS@THINK-WENCESLAS.ARPA>
    
    Just for the record, I had an application today where I really wanted to
    write something like
    
	    (MULTIPLE-VALUE-BIND (VALUE &OPTIONAL (FOUNDP T))
		(FUNCALL (MAGIC-HOOK-FUNCTION THINGY) FUNNY-ARG)
	      (WHEN FOUNDP
		(CACHE-SOME-STUFF THINGY FUNNY-ARG VALUE))
	      (VALUES VALUE FOUNDP))
    
How about:

        (multiple-value-call #'(lambda (value &optional (foundp t))
                                 (when foundp
                                   (cache-some-stuff thingy funny-arg value))
                                 (values value foundp))
                             (magic-hook-function thingy))

And I agree that MULTIPLE-VALUE-BIND should be able to take a full-blown
lambda-list.

	-- Nick

∂21-Dec-85  2102	NGALL@BBNG.ARPA 	Re: Multiple values and &optional
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 21 Dec 85  17:37:57 PST
Date: 21 Dec 1985 18:20-EST
Sender: NGALL@BBNG.ARPA
Subject: Re: Multiple values and &optional
From: NGALL@BBNG.ARPA
To: gls@AQUINAS.THINK.COM
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[BBNG.ARPA]21-Dec-85 18:20:32.NGALL>
In-Reply-To: <851220170310.1.GLS@THINK-WENCESLAS.ARPA>

	
    Date: Fri, 20 Dec 85 17:03 EST
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>
    To: common-lisp@SU-AI.ARPA
    Subject: Multiple values and &optional
    Message-ID: <851220170310.1.GLS@THINK-WENCESLAS.ARPA>
    
    Just for the record, I had an application today where I really wanted to
    write something like
    
	    (MULTIPLE-VALUE-BIND (VALUE &OPTIONAL (FOUNDP T))
		(FUNCALL (MAGIC-HOOK-FUNCTION THINGY) FUNNY-ARG)
	      (WHEN FOUNDP
		(CACHE-SOME-STUFF THINGY FUNNY-ARG VALUE))
	      (VALUES VALUE FOUNDP))
    
How about:

        (multiple-value-call #'(lambda (value &optional (foundp t))
                                 (when foundp
                                   (cache-some-stuff thingy funny-arg value))
                                 (values value foundp))
                             (magic-hook-function thingy))

And I agree that MULTIPLE-VALUE-BIND should be able to take a full-blown
lambda-list.

	-- Nick

∂23-Dec-85  0030	MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA 	Comments  
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 23 Dec 85  00:30:45 PST
Received: from umass-cs by csnet-relay.csnet id a026470; 23 Dec 85 3:25 EST
Date:     Sun, 22 Dec 85 17:15 EST
From:     MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
To:       common-lisp@su-ai.ARPA
Subject:  Comments


  I think the discussion about whether there should be an XOR
function is very much off the mark.  I think the criterion for
including any new  operator in the language should be one of
the following: 
  1) It is not possible to write it in Common Lisp.
  2) It can be implemented MUCH more
     efficiently in an implemention dependant way.
  3) It requires a lot of programming effort (and is generally useful).

As long as an operator is implementable in Common Lisp, your program
would still be portable.
The only problem that could arise is that your function/macro
is called something that later on becomes defined in Common Lisp, with
different syntax/semantics.  But that problem exists with ANY operator
that you define, and packages can deal with it.  Thus I see no reason
to include something like XOR.  The language is certainly big enough
already.  

Other Issues:

  I would like to vehemently disagree with the proposed change
to the mapping functions, such that it is an error to pass them
circular-lists.  A see no advantage to this, and a clear
disadvantage (I use this mechanism, and often find it the clearest
way to express certain computation e.g.
 (mapcar #'two-arg-fun  arg1-list (or extra-arg-list (circular-list NIL))).
Moreoever, any implementation that actually Checked for the error
is certainly a foolish one. 

  It seems to me that the DEFGLOBAL proposal adds more confusion than
it could ever be worth.  If the desire is to create a global variable
without taking chances on doing a dynamic binding of it, then it
seems the informal policy of doing *this* to a dynamic variable
is adequate.  Anyone who does (let ((*something* ...))) is surely
begging to get a dynamic binding.  Moreoever, it would seem to generate
no more efficiency.

;; I vote for eradication of MacroLet.  

  I recall someone has already asked for the inclusion of the
function MACROEXPAND-ALL.  If this hasn't been accepted, I second
the motion on the grounds of criterion 3 above (It requires knowledge
of  special-operators).

  It appears that there is no way to return multiple values from
conditional forms in any useful way. COND,AND,OR don't return
multiple values for their predicate forms, except for the last form.
AND isn't problematic, since if it returns non-nil, it returns the
values of the last form, and hence multiple-values.  It is OR that
is problematic.  I find it unfortunate that something like:
  
  (defun find-it (list parallel-list)
    (cond ((null list) nil)
	  ((and (atom list) (passes-test list))
	   (values list parallel-list))
	  (t (or (find-it (car list) (car parallel-list))
	         (find-it (cdr list) (cdr parallel-list))))))

Won't work since the OR won't return the multiple values
for the first (car) form.  What is most distressing is
that OR WILL return multiple values for the last form.  This
can easily create subtle bugs that are hard to figure out unless
you know of the peculiar behavior of OR.  Of course, you can
give up on multiple-values, but it seems a real problem if you
have to resort to returning Lists in cases like these.

It is therfore my opinion that OR should return multiple values for ALL of it's
forms, or none of them.  If the latter, Multiple-Value-OR can be written
in Common Lisp, but I wonder if it possible to do it more efficiently
in an implementation dependant way?

(BTW: Page 84 of Cltl refers to OR as a Special Form)

Random Functions:

I would also like to suggest the addition of the predicate
FILE-STREAM-P, which if true, would return the file pathname.

On the basis of being implementation dependant (criterion 1), I suggest
three more functions:

FUNCTION-ARGLIST, MACRO-ARGLIST, and FUNCTION-NAME.

These should work for system functions as well as user defined ones.
And for all kinds of functions - closures, compiled, interpreted.

 - Kelly Murray
   University Of Massachusetts

∂23-Dec-85  0756	NGALL@BBNG.ARPA 	Re:  Comments
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 23 Dec 85  07:49:33 PST
Date: 23 Dec 1985 10:51-EST
Sender: NGALL@BBNG.ARPA
Subject: Re:  Comments
From: NGALL@BBNG.ARPA
To: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[BBNG.ARPA]23-Dec-85 10:51:26.NGALL>
In-Reply-To: The message of     Sun, 22 Dec 85 17:15 EST from     MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA

	
    Date:     Sun, 22 Dec 85 17:15 EST
    From:     MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
    To:       common-lisp@su-ai.ARPA
    Subject:  Comments
    
    
      I think the discussion about whether there should be an XOR
    function is very much off the mark.  I think the criterion for
    including any new  operator in the language should be one of
    the following: 
      1) It is not possible to write it in Common Lisp.
      2) It can be implemented MUCH more
	 efficiently in an implemention dependant way.
      3) It requires a lot of programming effort (and is generally useful).
    
    As long as an operator is implementable in Common Lisp, your program
    would still be portable.
    The only problem that could arise is that your function/macro
    is called something that later on becomes defined in Common Lisp, with
    different syntax/semantics.  But that problem exists with ANY operator
    that you define, and packages can deal with it.  Thus I see no reason
    to include something like XOR.  The language is certainly big enough
    already.  

I would change criterion (3) to

3) It is generally useful and without it, ugly (i.e., opaque) idioms
must be used.

Since (I believe) the point is whether or not "everyone" is going to
implement it anyway, given that it is so useful.  If they are, it
should be standardized, regardless of the implementation effort.  So,
to me, the question concerning XOR is, will "everyone" use it?  Since
I have NEVER been aware of the need for such a construct, I would vote NO.
    
...

      I recall someone has already asked for the inclusion of the
    function MACROEXPAND-ALL.  If this hasn't been accepted, I second
    the motion on the grounds of criterion 3 above (It requires knowledge
    of  special-operators).
    
I agree (on the grounds of my revised critterion 3).

...

    Random Functions:
    
    I would also like to suggest the addition of the predicate
    FILE-STREAM-P, which if true, would return the file pathname.
    
On the grounds of what criteria?

    On the basis of being implementation dependant (criterion 1), I suggest
    three more functions:
    
    FUNCTION-ARGLIST, MACRO-ARGLIST, and FUNCTION-NAME.
    
    These should work for system functions as well as user defined ones.
    And for all kinds of functions - closures, compiled, interpreted.

I heartily agree (at least about the first one)!  I'm desperate for
such right now!  I'm writing a profile module now and I'm "advising"
data collection calls around functions.  And to make the advising
function as fast as possible I'd like it to have an "equivalent"
lambda-list.

For example, currently, I'm forced to write something like:

`(lambda (&rest arglist)
   (start-data-collection)
   (unwind-protect
     (apply ',original-function arglist)
     (stop-data-collection)))

which is SLOW (in most (?) implementations) due to both the use of
&REST and the use of APPLY.

If I could get the number of req. and opt. args and an indication of
whether or not a &rest arg (implicit or not) is required, I could
write something like the following:

(multiple-value-bind (req-args-count opt-args-count restp)
		     (parameter-info original-function)
  (if (not restp)
      (let ((req-args '())
	    (opt-args '()))
	(dotimes (i req-args-count) (push (gensym) req-args))
	(dotimes (i opt-args-count) (push (gensym) opt-args))
	`(lambda (,@req-args &optional ,@opt-args)
	   (declare (inline ,original-function))
	   (start-data-collection)
	   (unwind-protect
	    `(,original-function ,@req-args &optional ,@opt-args)
	    (stop-data-collection)))) 
      <code for the APPLY case (see above)>))

The above code if oversimplified.  It assumes that the optional
parameters of the original-function all default to NIL and don't
contain <svar>s.  But I hope you get the point.

Thus I recommend a function named PARAMETER-INFO that takes an
arg. of type (SATISFIES FUNCTIONP) and returns three values: the
number of required parameters (an integer), the number of optional
parameters (an integer), and either T or NIL depending on whether any
&REST or &KEYWORD parameters appear in the lambda-list.  I believe
this information is retained (in all (?) implementations) even by
compiled code.

P.S. Does anyone know how I could get such info about a compiled
function definition in VaxLisp?!

-- Nick

∂23-Dec-85  0756	GSB@MC.LCS.MIT.EDU 	xor  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 23 Dec 85  07:48:31 PST
Date: Mon, 23 Dec 85 10:51:14 EST
From: "Glenn S. Burke" <GSB@MC.LCS.MIT.EDU>
Subject: xor
To: common-lisp@SU-AI.ARPA
Message-ID: <[MC.LCS.MIT.EDU].764612.851223.GSB>

What i don't like about XOR is that it sounds like it is in the same
class as AND and OR, and it is not all that like them.  Like it or
not, AND and OR are control constructs.  (I have never had any problem
with this, but Lisp is my first programming language.  I am somewhat
disturbed by attempts to mask this nature of them -- they may lead to
even more confusion by this deemphasis.)

I wouldn't mind the functionality, but it's not clear to me that it is
worth too much confusion.  As far as implementation is concerned, i
can see being able to implement this much better as a special operator
than as a macro.

∂23-Dec-85  0756	FAHLMAN@C.CS.CMU.EDU 	Comments
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Dec 85  07:56:00 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 23 Dec 85 10:55:46-EST
Date: Mon, 23 Dec 1985  10:55 EST
Message-ID: <FAHLMAN.12169422751.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: Comments
In-reply-to: Msg of 22 Dec 1985  17:15-EST from MURRAY%umass-cs.csnet at CSNET-RELAY.ARPA


I don't agree with Murray's three cirteria for what should go into the
language.  I think a reasonable fourth criterion is:

4) The proposed construct will be used a lot, represents some
abstraction that is easy to grasp, and code using it is
clearer than the equivalent lower-level stuff appearing inline.

Actually, that's a criterion that every programmer should use in deciding
whether to create a new function or macro, but if the "used a lot" part
applies to the Common Lisp community as a whole and not just to one or
two application programs, then it is worthwhile putting this new thing
in.

This leads to a large language, but one in which there are lots of
useful constructs and one in which it is much easier for person A to
read person B's code.  Murray's rules would lead to a very lean
language, perhaps easier to learn and a little bit easier to implement,
but not so good for heavy duty programming.  For better or for worse, we
decided years ago that Common Lisp would include a lot of these optional
things.  That is why, for example, we include all the sequence functions
that could just as easily have been written as DO's (or as PROG's and
GO's, for that matter.)

Of course, we've got to stop somewhere.  Constructs whose usefulness is
unclear don't make it, nor do constructs where each person wants
something a little bit different and where there is no general agreement
on how to bundle these different versions into a single clear package.
If an item is controversial, but is implementable in a strictly portable
way, we generally suggest that it be put into a Yellow Pages library
until we see if it is going to "take" or not.

I don't like XOR because it doesn't look generally useful to me and
because it can be quite confusing to deal with.  There are several
closely-related things that XOR might mean (only one versus odd parity,
for example) and the parallelism with AND and OR breaks down in
some ugly ways.

-- Scott

∂23-Dec-85  1029	REM%IMSSS.#Pup@SU-SCORE.ARPA 	Ground rules not yet decided???    
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 23 Dec 85  10:29:44 PST
Received: from IMSSS by Score with Pup; Mon 23 Dec 85 10:26:42-PST
Date: 23 Dec 1985 0828-PST
From: Rem@IMSSS
Subject: Ground rules not yet decided???
To:   COMMON-LISP%SU-AI@SCORE

I thought the main reason for the big meeting this month was to
make a constitution and to decide basic ground rules such as what
rule of thumb should decide whether a given feature should be in CL or not?
Why are we still arguing over it? Wasn't it decided at the meeting?
I think the CL group should hurry up and decide these basic issues,
so our debate over details of this should be in and this should be out
won't be in a vacuum where only random personal opinions guide us.
-------

∂23-Dec-85  1323	JAR@MC.LCS.MIT.EDU 	unspecial & global & macrolet 
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 23 Dec 85  13:22:52 PST
Date: Mon, 23 Dec 85 16:25:37 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject:  unspecial & global & macrolet
To: common-lisp@SU-AI.ARPA
Message-ID: <[MC.LCS.MIT.EDU].764953.851223.JAR>

I don't much care whether DEFGLOBAL exists.  But I will lobby for a
(declare (unspecial ...)) or (declare (lexical ...)), which provides the
sorely needed ability to do an assured lexical binding, independent of
the existence of a global special binding.

Does anyone have objections to the addition of an unspecial declaration?
I have asked about this twice before and haven't had any replies,
although I know there must be SOME reason it isn't in CLtL, since
Maclisp and the various Lisp Machine Lisps have it, and it must have
been considered.

I guess one objection is that for symmetry there ought to be a (proclaim
'(lexical ...)) to go with (declare (lexical ...)), and then we're
back to arguing about DEFGLOBAL again.  But Common Lisp doesn't strike
me as a language in which symmetry and orthogonality play important
roles, so I don't see that this objection carries much weight; you could
have one and not the other.

---
I actually make good use of MACROLET; I think it's too late to eradicate
it, since many other users will be depending on it also.

Jonathan

∂23-Dec-85  1357	FAHLMAN@C.CS.CMU.EDU 	Ground rules not yet decided???  
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Dec 85  13:55:20 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 23 Dec 85 16:55:27-EST
Date: Mon, 23 Dec 1985  16:55 EST
Message-ID: <FAHLMAN.12169488230.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Common-Lisp@SU-AI.ARPA
Subject: Ground rules not yet decided???
In-reply-to: Msg of 23 Dec 1985  11:28-EST from Rem at IMSSS


In response to REM@IMSSS (mail sent to that address always bounces back
in my face):

It was never our intention to try to formalize the "ground rules"
covering the philosophy of language design at the Boston meeting or
anywhere else.  This is a fluid process with a lot of varying opinions,
and in the end these choices come down to taste and experience.  I don't
think it would be wise to try to chisel a set of principles in stone,
even if we could get people to agree.

What we did try to do in Boston was to work out some more formal way for
making final decisions on what is in Common Lisp and what is not.  I had
assumed that everyone who cared about this had heard the news from
someone who attended the meeting, but maybe not.  What happened in the
charter area was this (very briefly):

After some discussion of the possible kinds of organization we might
want to form, we heard from Bob Mathis on what it would take to
standardize Common Lisp in a formal way under ISO.  Mathis used to run
the Ada and Stars programs at DOD, and he was deeply involved in the
effort to get Ada standardized by ISO.  In the past, most of us had
discounted the formal standards organizations as unwieldy bureaucracies
that mangle everything they touch, but Mathis persuaded most of us that
there was a good chance of setting things up so that a technical
committee acceptable to the current Common Lisp community produces a
recommendation for a standard (perhaps a series of standards, one every
couple of years) and the ISO approves this as the standard definition of
Common Lisp without a lot of gratuitous alterations.

We decided that this route was worth a try.  The original gang of five,
plus Mathis and Squires, were appointed to try to put together a
steering committee to do the political work and a technical commitee
that would be more representative of the total community than the gang
of five are by themselves.  This will then be proposed to ISO, with
Mathis as the "convenor" of the committee -- a position of some power.
The formation of a separate standards organization for Common Lisp was
put on hold for six months, by which time we should have a good idea
whether the ISO process is going to work the way we want it to.
However, we hope to proceed rapidly toward getting ISI a contract from
DARPA for performing various non-decision-making support tasks for
Common Lisp.

The intention is that the technical committee, once formed, would work
in more or less the way that we always have worked.  Issues would be
raised, discussed via the network (we hope to establish better mail
connections with Europe and Japan as quickly as possible), and when some
sort of near consensus emerges, a decision would be made and recorded.
The technical committee would then announce that this is going to be in
the proposed standard that is sent on to ISO.  Eventually, all of these
decisions are bundled together, sent to ISO, and (we hope) they emerge
from the other end of the process as an ISO standard.  Getting through
these last few steps could take a long time, but companies would be
perfectly free to go ahead and implement what is in the proposal, rather
than waiting for the final standard to be approved.

One thing that became clear at the meeting was that there is
considerable interest in Europe, especially in Jerome Chailloux's group
in France, in working on a smaller, cleaner Lisp that probably would be
a subset of Common Lisp.  Of course, there has been some interest in
this in the U.S. as well, particularly in Kessler's PCLS group at Utah,
and Dr. Ida in Japan has been working on something similar.

I personally don't see any fundamental conflict here.  What might well
emerge is a two-level standard (or maybe two distinct standards): big,
ugly, hairy industrial strength Common Lisp on the one hand, and some
cleaner subset on the other.  (Whether the subset people can reach
agreement is another matter -- there are many different reasons for
doing a subset, and the resulting language would be different in each
case.)  It would cause a lot of confusion to use the name "Common Lisp"
to refer to anything other than the big language more or less as defined
in Guy's book, but if we're careful in choosing what to call the subset,
the two levels should be able to coexist quite happily.

So the next task is to work out the membership of the technical and
steering committees, and then do whatever one does to get ISO to
recognize them.  This will take awhile.  In the meantime, nobody is in a
position to make any binding decisions on language issues, but we can
continue to muddle along as we have for the last year or two until the
more formal mechanism is in place.

-- Scott

∂23-Dec-85  2058	apollo!dfm@uw-beaver.arpa 	copy (moderately long message)   
Received: from UW-BEAVER.ARPA by SU-AI.ARPA with TCP; 23 Dec 85  20:57:58 PST
Received: by uw-beaver.arpa (4.42/4.2)
	id AA10071; Mon, 23 Dec 85 20:59:20 PST
Return-Path: <apollo!dfm@uw-beaver.arpa>
Message-Id: <8512240459.AA10071@uw-beaver.arpa>
From: apollo!dfm@uw-beaver.arpa
Date: Mon, 23 Dec 85 17:03:01 EST 
Subject: copy (moderately long message)
To: COMMON-LISP@su-ai.arpa
Cc: dfm

Here's a more detailed description of one possible version of copy.  I believe this
combines most of the features people have suggested in recent mail and clarifies
most of the ambiguities people have pointed out in recent mail.



copy object &key :array :structure :hash-table :readtable :pathname :random-state
                 :gensym :fill-pointer :adjustable :level :circle

Recursively copies object as follows:

  If object is a cons copy returns a new cons (i.e. it is guaranteed that
  (and (consp object) (eq (copy object) object)) => nil) and calls itself
  recursively to fill in the car and cdr.

  If object is an array and :array is non-nil (it defaults to t) copy returns a new
  array as follows:

    The rank, dimensions, and element type are the same as object, subject to the
    restrictions regarding fill pointers below.  Even if object is displaced, the
    result is not.  The contents of the array are recursively copied.  If an element
    of the array is undefined (e. g. not initialized), it is undefined in the
    result.  In particular, if an implementation can recognize that an element
    is undefined it need not copy that element.

    Only if object has a fill pointer and :fill-pointer is non-nil will the result
    have a fill pointer.  The fill pointer is initialized to the same value as
    object's fill pointer, and all the defined elements of object, even those that
    are inactive with respect to the fill pointer, are copied.  If the object has a
    fill pointer but :fill-pointer is nil the result does not have a fill pointer,
    and the length of the resulting vector is reduced to the current value of
    object's fill pointer.  :Fill-pointer defaults to nil.

    Only if object is adjustable and :adjustable is non-nil is the result adjustable.
    :Adjustable defaults to nil.

  If object is a user defined structure and :structure is non-nil copy returns
  a new structure of the same type.  If object is named, the result acquires the
  same name (i.e. if object is a user defined, named structure then
  (eq (type-of object) (type-of (copy object)) => t).  The values of the slots
  of object are recursively copied to the result.  If the value of a slot of object
  is undefined, the value of the corresponding slot in the result is undefined.
  In particular, if an implementation can recognize that a slot's value is
  undefined it need not copy that slot.  Any slots skipped over by the
  :initial-offset option to defstruct are not recursively copied; that is, their
  values in the result are eql to their values in object.  :Structure defaults
  to t.

  If object is a hash table and :hash-table is non-nil copy returns a new hash table
  whose size is at least as large as that of object, and with the same test,
  rehash-size, and rehash-threshold.  An entry is made in the new hash table for
  each entry in object: keys are not recursively copied (i.e. the key in the new
  table is eql to that in the old) but values are recursively copied.  :Hash-table
  defaults to nil.

  If object is a readtable and :readtable is non-nil copy returns the same value as
  (copy-readtable object).  :Readtable defaults to nil.
  
  If object is a pathname and :pathname is non-nil copy returns the same value as
  (make-pathname :host      (pathname-host object)
                 :device    (pathname-device object)
                 :directory (pathname-directory object)
                 :name      (pathname-name object)
                 :type      (pathname-type object)
                 :version   (pathname-version object) )
  :Pathname defaults to t.

  If object is a random state and :random-state is non-nil copy returns the same
  value as (make-random-state object).  :Random-state defaults to t.

  If object is an uninterned symbol and :gensym is non-nil copy returns the same
  value as (copy-symbol object).  :Gensym defaults to t.

  Otherwise copy simply returns a value eql to object.

The :level argument can be used to limit the depth of recursion.  If supplied and
non-nil it should be a non-negative integer, in which case copy will only copy items
at that depth or shallower.  For example, (copy object :level 1) copies only the top
level object itself.  As a boundary case (copy object :level 0) returns object with-
out any copying.  In the case of conses the depth is considered to increase only
through the cars, and not the cdrs; that is, an entire list is considered to be at
the same level.  For example, if L is a list, then (copy L :level 1) returns the
same value as (copy-seq L).  :Level defaults to nil.

If object is circular, or contains circular substructures, copy may fail to
terminate.  If :circle is non-nil copy endeavors to detect cycles and terminate
normally, returning an isomorphic object.  :Circle defaults to nil.




NOTES:

- The basic intention is that (copy object) be similar to
  (read-from-string (write-to-string object :array t)), with objects that would be
  printed using #< notation not being copied.  Exactly what objects are printed
  using #< notation is implementation dependent, and it seems best that the value
  returned by copy be as implementation independent as possible.  Therefore some
  choices have to be made, mostly reflected in the defaults (e.g. I expect most
  implementations to print hash tables using #<, but pathnames in some readable
  format).  These choices are obviously subjective.

- The reason no mechanism for preserving displacement in copying arrays is provided
  is that displacement is typically an effort to deliberately avoid copying.

- It might seem strange to allow numeric and character keys in a #'eq hash table
  to be copied (a la eql).  However, I don't think that it can ever make sense to
  use a #'eq hash table portably with numbers and characters.

- Note that copying a readtable, pathname, or random state may be a "shallow" copy.
  However, since the structure of these items is not defined by the language it
  seems incorrect to try to define it otherwise.

- No mechanism is supplied for copying interned ids or packages as that would appear
  to raise some prohibitively awkward issues.

- No machinism is supplied for copying streams or functions, as the semantics of
  these seem to be too implementation dependent.

- I see no reason why implementations couldn't allow copying other types of objects
  by supplying more keyword arguments.  Such extensions would, of course, not be
  portable.

- Regarding :level and cdrs there seems to be a choice to be made between lists and
  trees of conses.  Lists are by far the more prevalent data structure so it seems
  best to favor them.  This also makes :level parallel the use of :level in write.

- One might expect that if there's a :level there should be a :length.  This is
  awkward for anything but lists, however.  While I would expect
  (copy '((1) (2) (3)) :length 2) to copy the first two elements but not the third,
  what do I do about (copy '#((1) (2) (3)) :length 2)?  One could say that we don't
  copy the entire surrounding structure, and, for consistency, apply the same rule
  to lists; the complexity of this seems to more than outweigh the dubious
  usefulness of :length in copy.

- I believe that (equalp x (copy x)) => t.  Indeed, the intermediate equality
  predicate that Eric Benson proposed (case sensitive equalp) (and that I agree
  is needed -- and should be supported as a hash table test) should also be true.

- I believe that this copy can easily be written in COMMON LISP, once the proposed
  functions hash-table-size, etc. have been added, except for the code dealing with
  structures. That implies to me that COMMON LISP probably needs more functionality
  for manipulating structures.  For example, I don't think that there is even a
  portable way of even telling whether or not an object *is* a user defined
  structure.

                                                - Don Morrison

∂23-Dec-85  2058	α@uw-beaver.arpa    
Received: from UW-BEAVER.ARPA by SU-AI.ARPA with TCP; 23 Dec 85  20:58:23 PST
Received: by uw-beaver.arpa (4.42/4.2)
	id AA10088; Mon, 23 Dec 85 21:00:04 PST
Date: Mon, 23 Dec 85 21:00:04 PST
From: α@uw-beaver.arpa
Return-Path: <α@uw-beaver.arpa>
Message-Id: <8512240500.AA10088@uw-beaver.arpa>
Apparently-To: COMMON-LISP@SU-AI.ARPA


∂24-Dec-85  1530	gls@THINK-AQUINAS.ARPA 	Reader hacks    
Received: from THINK.COM by SU-AI.ARPA with TCP; 24 Dec 85  15:30:50 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 23 Dec 85 16:49:47 est
Date: Mon, 23 Dec 85 16:47 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Reader hacks
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <851223164735.3.GLS@THINK-JEHOSEPHAT.ARPA>

I am writing code for reader macros and find I need the following
things:
(1) A predicate that is true of whitespace characters and false
    of all others.  The problem is that
	(member foo '(#\Space #\Newline))
    doesn't cover tabs, etc., and
	(member foo '(#\Space #\Newline #\Tab #\Form))
    is not completely portable because of the semi-standard
    character names.
(2) I find I can't easily write myself something akin to
    READ-DELIMITED-LIST that handles dotted lists because of
    the problem of recognizing all-dots tokens.  PEEK-CHAR can
    only peek one ahead, so I can't tell whether there is a
    space after a dot before calling READ recursively.
--Guy

∂24-Dec-85  1535	gls@THINK-AQUINAS.ARPA 	GLS's clarifications list (moderately long)   
Received: from THINK.COM by SU-AI.ARPA with TCP; 24 Dec 85  15:35:39 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 23 Dec 85 12:19:04 est
Date: Mon, 23 Dec 85 12:16 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: GLS's clarifications list (moderately long)
To: DLW@SCRC-QUABBIN.ARPA, apollo!dfm@UW-BEAVER.ARPA, COMMON-LISP@SU-AI.ARPA
In-Reply-To: <851220193530.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <851223121647.1.GLS@THINK-JEHOSEPHAT.ARPA>

    Date: Fri, 20 Dec 85 19:35 EST
    From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>

    I would like to point out that you are discussing the implementation
    details of "globals" before we have agreed what "globals" are.  There
    were several interpretations of "globals" floating around on the mail
    and no resolution of which one we were talking about.

You are quite right, of course.  In my case that was intentional, but I
failed to make that clear.  I was trying to explicate an alternative
semantics by proposing an implementation (not a specific one, but rather
one tied to DEFCONSTANT).

∂26-Dec-85  0934	Moon@SCRC-STONY-BROOK.ARPA 	Symbols as pathnames  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Dec 85  09:34:30 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 381485; Thu 26-Dec-85 12:33:42-EST
Date: Thu, 26 Dec 85 12:27 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Symbols as pathnames
To: common-lisp@SU-AI.ARPA
In-Reply-To: <851011153205.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <851226122756.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 11 Oct 85 15:32 EDT
    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>

	Date: Fri, 11 Oct 85 09:47:43 CDT
	From: wagner@GSWD-VMS

	On page 418 of CLtL, concerning the OPEN function:  "The filename
	...may be a string, a pathname, or a stream."  May it not also be
	a symbol, and shouldn't the spec say so?  Same for WITH-OPEN-FILE,
	etc.?  (The underlying pathname functions work with symbols.)

    It's true that most places in the manual say that symbols are acceptable
    where pathnames are required, and are parsed as namestrings.  I don't
    understand why this feature is in there; it seems like asking for trouble.
    What about implementations (yes they exist) where some streams are
    implemented as symbols?  How do you tell whether a symbol was supposed to
    be a stream or supposed to be a string?  What if NIL is accidentally used
    where a pathname was expected, do you really want to get a file named "NIL"?

    It's possible that the feature of allowing symbols as pathnames was blindly
    copied from an old version of Zetalisp, which used to allow that.  A couple
    of bad ideas got into Common Lisp that way, in spite of significant effort
    by the committee to try to keep it from happening.  Zetalisp allowed symbols
    for compatibility with an old version of pdp-10 Maclisp that didn't have
    strings.

I never saw a response to the above.  Now that we are discussing clarifications,
I'd like to suggest the following as a proposed clarification, to fix the fact
that in some places the manual says symbols are accepted as pathnames and in
other places it says they aren't.  Symbolics' implementation currently contains
some inconsistencies in this area, which cannot be corrected without deviating
from what the manual currently says in one way or another.  I'd prefer to see
all implementations deviate in the same direction.

If you reply to this message, please delete the enclosures from October, which
I only included for context.

p.413, 3rd paragraph: change "string or symbol" to "string" in both sentences.

p.413, pathname function: same.

p.414, 2nd to last paragraph: same.

p.417, pathname-host function, 1st sentence: same.

p.417, namestring function, 1st sentence: same.

p.414, parse-namestring function: delete the clause saying that @I[thing] may be
a symbol, in the second sentence.

p.415, merge-pathnames function, 3rd sentence: delete "or symbol".

p.424, probe-file function: Specify what @I[file] may be (I presume a string,
a pathname, or a stream).

p.423, rename-file function: change "@I[new-name] (which must be a filename)"
to "@I[new-name]." and add at the end of the first paragraph "@I[New-name] must
be a pathname, a string, or a stream."  I see no reason to disallow streams
here; the conversion from stream to pathname is as defined by the PATHNAME function.

p.424, file-write-date and file-author functions, also GLS's proposed extension
to the file-length function: These use the term "filename", which I cannot find
defined elsewhere.  Change "filename" to "pathname or string".

p.426, load function: This has an argument named "filename", whose type is not
defined.  Define it to be a pathname, string, or stream--the same as the
argument named "filename" for open and with-open-file.

In chapter 23, there are arguments named pathname, thing, filename, file, and
name (really new-name).  As far as I can tell there is no semantic difference
associated with these five different names.  A consistent terminology should
be adopted.  I suggest calling all of them pathname.

∂26-Dec-85  1012	Moon@SCRC-STONY-BROOK.ARPA 	XOR    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Dec 85  10:12:01 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 381519; Thu 26-Dec-85 13:11:31-EST
Date: Thu, 26 Dec 85 13:05 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: XOR
To: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 22 Dec 85 17:15-EST from MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
Message-ID: <851226130548.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date:     Sun, 22 Dec 85 17:15 EST
    From:     MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA

      I think the discussion about whether there should be an XOR
    function is very much off the mark.  I think the criterion for
    including any new  operator in the language should be one of
    the following: 
      1) It is not possible to write it in Common Lisp.
      2) It can be implemented MUCH more
	 efficiently in an implemention dependant way.
      3) It requires a lot of programming effort (and is generally useful).

    As long as an operator is implementable in Common Lisp, your program
    would still be portable.
    The only problem that could arise is that your function/macro
    is called something that later on becomes defined in Common Lisp, with
    different syntax/semantics.  But that problem exists with ANY operator
    that you define, and packages can deal with it.  Thus I see no reason
    to include something like XOR.  The language is certainly big enough
    already.  

I agree completely.  I could not have stated my position as clearly and
completely as you have.

[Rest of message, about other issues, not included in this particular reply]

∂26-Dec-85  1028	gls@THINK-AQUINAS.ARPA 	Comments   
Received: from THINK.COM by SU-AI.ARPA with TCP; 26 Dec 85  10:28:07 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Thu, 26 Dec 85 13:27:58 est
Date: Thu, 26 Dec 85 13:28 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Comments
To: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 22 Dec 85 17:15-EST from MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
Message-Id: <851226132828.4.GLS@THINK-JEHOSEPHAT.ARPA>

    Date:     Sun, 22 Dec 85 17:15 EST
    From: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA

      I think the discussion about whether there should be an XOR
    function is very much off the mark.  I think the criterion for
    including any new  operator in the language should be one of
    the following: 
      1) It is not possible to write it in Common Lisp.
      2) It can be implemented MUCH more
	 efficiently in an implemention dependant way.
      3) It requires a lot of programming effort (and is generally useful).

There should be a fourth criterion:
      4) It is so useful that many individual users keep reinventing it,
         and therefore it is deserving of standardization.
PUSH and POP fall into this category, for example.  On the other hand, I
will not argue that XOR does fall into this category, as all the
reent evidence on the mailing list indicates otherwise.

Several others have also pointed out the potential ambiguity in extending
XOR to more than two arguments: is it "an odd number true", "exactly one
true", or "all but one true" (the latter being unlikely given the name,
but nevertheless a consistent extension)?  The main reason for choosing
"an odd number true" is that that definition is associative, whereas the
other choices are not.  If XOR were to be added to the language (and I will
not argue strongly that it should be), I would suggest making it a function
(not a special form) of exactly two arguments (to avoid the ambiguity).

I do not find convincing the argument against XOR on the grounds that
it cannot terminate its execution early the way AND and OR do.  After all,
NOT is usually in the same bag as AND and OR, and it is not a special form.
I would say that XOR is more like NOT than like AND and OR.

--Guy

∂26-Dec-85  1054	Moon@SCRC-STONY-BROOK.ARPA 	Reader hacks
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Dec 85  10:54:39 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 381574; Thu 26-Dec-85 13:52:11-EST
Date: Thu, 26 Dec 85 13:46 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Reader hacks
To: Guy Steele <gls@THINK-AQUINAS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851223164735.3.GLS@THINK-JEHOSEPHAT.ARPA>
Message-ID: <851226134628.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 23 Dec 85 16:47 EST
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>

    I am writing code for reader macros and find I need the following
    things:
    (1) A predicate that is true of whitespace characters and false
	of all others.  The problem is that
	    (member foo '(#\Space #\Newline))
	doesn't cover tabs, etc., and
	    (member foo '(#\Space #\Newline #\Tab #\Form))
	is not completely portable because of the semi-standard
	character names.

Is this something different from
  (or (char-equal char #\space)
      (not (graphic-char-p char))) ?


    (2) I find I can't easily write myself something akin to
	READ-DELIMITED-LIST that handles dotted lists because of
	the problem of recognizing all-dots tokens.  PEEK-CHAR can
	only peek one ahead, so I can't tell whether there is a
	space after a dot before calling READ recursively.

How about a way (a special variable?) to turn off the somewhat silly
restriction that you can't have a symbol named .?  Alternatively,
how about a function that does the token-isolating portion of READ
but not the printed-representation-to-object conversion portion of
READ?

∂26-Dec-85  1139	Bobrow.pa@Xerox.ARPA 	Re: copy     
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 26 Dec 85  11:39:06 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 DEC 85 11:39:17 PST
Date: 26 Dec 85 11:39 PST
From: Bobrow.pa@Xerox.ARPA
Subject: Re: copy 
To: dfm@uw-beaver.arpa
cc: COMMON-LISP@su-ai.arpa
Message-ID: <851226-113917-1685@Xerox>

If we adopt something like CommonLoops where all objects have an
associated class, then the Copy problem becomes factored in a different
way; that is, one independently decides for each class the response to
two messages, COPY and COPY-IN:

COPY  is the top level call.  It produces a copy if it can
	 e.g. a new cons pair, same symbol, but a copy of a named structure
(unnamed).

COPY-IN  is the recursive call.  Each type determines whether to return
itself or a copy for inclusion in a larger structure.

The protocol suggested by dfm is probably the appropriate definition for
COPY-IN.  For named objects, COPY and COPY-IN would differ.  For CONSes
they would be the same, etc.

danny


∂26-Dec-85  1240	LOOSEMORE@UTAH-20.ARPA 	BOA constructor questions 
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 26 Dec 85  12:40:04 PST
Date: Thu 26 Dec 85 13:38:50-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: BOA constructor questions
To: common-lisp@SU-AI.ARPA
Message-ID: <12170260722.11.LOOSEMORE@UTAH-20.ARPA>

It is not clear from the discussion of BOA constructors in the manual what
is supposed to happen if you don't mention all the slot names in the arglist,
or even that it's legal to omit slots from the arglist.  Presumably, the
omitted slots should be initialized to whatever default value was given in
the body of the defstruct; if this is the case, the manual should say so.
Perhaps a better example would help.

Also, it says that "the keywords &optional, &rest, and &aux are recognized
in the argument list".  Is there a reason why &key is not permitted?  Or
is this an oversight?

-Sandra
-------

∂26-Dec-85  1309	gls@THINK-AQUINAS.ARPA 	BOA constructor questions 
Received: from THINK.COM by SU-AI.ARPA with TCP; 26 Dec 85  13:09:07 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Thu, 26 Dec 85 16:09:15 est
Date: Thu, 26 Dec 85 16:09 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: BOA constructor questions
To: LOOSEMORE@UTAH-20.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <12170260722.11.LOOSEMORE@UTAH-20.ARPA>
Message-Id: <851226160949.7.GLS@THINK-JEHOSEPHAT.ARPA>

    Date: Thu 26 Dec 85 13:38:50-MST
    From: SANDRA <LOOSEMORE@UTAH-20.ARPA>

    It is not clear from the discussion of BOA constructors in the manual what
    is supposed to happen if you don't mention all the slot names in the arglist,
    or even that it's legal to omit slots from the arglist.  Presumably, the
    omitted slots should be initialized to whatever default value was given in
    the body of the defstruct; if this is the case, the manual should say so.
    Perhaps a better example would help.

    Also, it says that "the keywords &optional, &rest, and &aux are recognized
    in the argument list".  Is there a reason why &key is not permitted?  Or
    is this an oversight?

    -Sandra
    -------

I don't see any technical reason why &KEY should not be permitted, with
semantics analogous to those for &OPTIONAL.  Then the standard
constructor function can be explained as a special case the more general
constructor feature that happens to take an argument for every slot and
takes them all as &KEY arguments.

But this prompts in me another question: does

(defstruct (foo (:constructor build-foo (&optional baz &aux baz)))
  (baz 5))

mean that

(make-foo)		initializes BAZ to 5
(make-foo :baz 43)	initializes BAZ to 43
(build-foo 91)		initializes BAZ to 91
(build-foo)		*does not initialize* BAZ   ?

If not, how else can I say it?  (Never mind why I would want to.)

--Guy

∂26-Dec-85  1342	GSB@MC.LCS.MIT.EDU 	Reader hacks   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 26 Dec 85  13:42:18 PST
Date: Thu, 26 Dec 85 16:45:01 EST
From: "Glenn S. Burke" <GSB@MC.LCS.MIT.EDU>
Subject: Reader hacks
To: Moon@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM
Message-ID: <[MC.LCS.MIT.EDU].766640.851226.GSB>

    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>

        From: Guy Steele <gls@THINK-AQUINAS.ARPA>

        I am writing code for reader macros and find I need the following
        things:
        (1) A predicate that is true of whitespace characters and false
    	of all others. . . . 

    Is this something different from
      (or (char-equal char #\space)
          (not (graphic-char-p char))) ?

Well, i was going to say that backspace didn't fit this mold, but CLtM
says it isn't a token constituent unless quoted.  Oh well.  Anyway,
have we ever speculated on the relationship of predicates like
graphic-char-p or this hypothetical whitespace-p, and readtables?  How
well-defined is it to transfer the syntax of one character to another?

        (2) I find I can't easily write myself something akin to
    	READ-DELIMITED-LIST that handles dotted lists because of
    	the problem of recognizing all-dots tokens.  PEEK-CHAR can
    	only peek one ahead, so I can't tell whether there is a
    	space after a dot before calling READ recursively.

    How about a way (a special variable?) to turn off the somewhat silly
    restriction that you can't have a symbol named .?

Flushing the restriction of unquoted all-dots tokens would only
ameliorate the problem a bit, because he would still have to read the
token himself because he wouldn't be able to unread-char both the dot
and the following token.  Besides all the other stuff which is almost
what read-delimited-list provides.  Restated, the problem is that one
might want read-delimited-list to barf about cons dots;  for instance,
to implement #( syntax.  Alternatively, one might want to do
variations of ordinary parentheses in which cons-dot is meaningful.
So having some sort of flag argument to read-delimited-list makes
sense.

    Alternatively, how about a function that does the token-isolating
    portion of READ but not the printed-representation-to-object
    conversion portion of READ?

Do you think this could be done without over half the implementors
having apoplectic fits, and with no loss of life?

∂26-Dec-85  1628	REM%IMSSS.#Pup@SU-SCORE.ARPA 	COPY and COPY-IN    
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 26 Dec 85  16:28:28 PST
Received: from IMSSS by Score with Pup; Thu 26 Dec 85 16:25:19-PST
Date: 26 Dec 1985 1625-PST
From: Rem@IMSSS
Subject: COPY and COPY-IN
To:   Bobrow.pa%Xerox.ARPA@SCORE
cc:   COMMON-LISP%SU-AI@SCORE

Do I understand your proposed semantics correctly, that at the very top
level COPY will force-copy a named object creating an unnamed object with
all the same parts as the original but not EQ to it and inaccessible via
the oblist, but recursively an object is copied if and only if it isn't
named, being a recursion-stop-point if it is named?
(at least that's the proposed default, which could be overriden by
keyword parameters to COPY which become fluid parameters accessed by COPY-IN)
-------

∂26-Dec-85  1706	@SU-SCORE.ARPA:Bobrow.pa@Xerox.ARPA 	Re: COPY and COPY-IN   
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 26 Dec 85  17:05:59 PST
Received: from Xerox.ARPA by SU-SCORE.ARPA with TCP; Thu 26 Dec 85 17:02:36-PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 DEC 85 17:05:48 PST
Date: 26 Dec 85 17:05 PST
From: Bobrow.pa@Xerox.ARPA
Subject: Re: COPY and COPY-IN
In-reply-to: Rem@IMSSS.ARPA's message of 26 Dec 85 16:25 PST
To: Rem@IMSSS.ARPA
cc: Bobrow.pa%Xerox.ARPA@SU-SCORE.ARPA, COMMON-LISP%SU-AI@SU-SCORE.ARPA
Message-ID: <851226-170548-1750@Xerox>

  Do I understand your proposed semantics correctly, that at the very
top
  level COPY will force-copy a named object creating an unnamed object
with
  all the same parts as the original but not EQ to it and inaccessible
via
  the oblist, but recursively an object is copied if and only if it
isn't
  named, being a recursion-stop-point if it is named?
  (at least that's the proposed default, which could be overriden by
  keyword parameters to COPY which become fluid parameters accessed by
 COPY-IN)

-------

I would propose that the top level COPY will force-copy (if that makes
sense); but what it does is determined by a METHOD associated with the
class of the object.

Similarly, the recursion is controlled by the COPY-IN METHOD for each
class.  A class could have its own specific response to
keyword-parameters.



∂26-Dec-85  1959	Moon@SCRC-STONY-BROOK.ARPA 	XOR    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Dec 85  19:59:39 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 381615; Thu 26-Dec-85 14:36:40-EST
Date: Thu, 26 Dec 85 14:30 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: XOR
To: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 22 Dec 85 17:15-EST from MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
Supersedes: <851226130548.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <851226143056.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date:     Sun, 22 Dec 85 17:15 EST
    From:     MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA

      I think the discussion about whether there should be an XOR
    function is very much off the mark.  I think the criterion for
    including any new  operator in the language should be one of
    the following: 
      1) It is not possible to write it in Common Lisp.
      2) It can be implemented MUCH more
	 efficiently in an implemention dependant way.
      3) It requires a lot of programming effort (and is generally useful).

    As long as an operator is implementable in Common Lisp, your program
    would still be portable.
    The only problem that could arise is that your function/macro
    is called something that later on becomes defined in Common Lisp, with
    different syntax/semantics.  But that problem exists with ANY operator
    that you define, and packages can deal with it.  Thus I see no reason
    to include something like XOR.  The language is certainly big enough
    already.  

I agree completely.  I could not have stated my position as clearly and
completely as you have.

LATER: I also agree with the other people who said that a 4th criterion
should be added, that enough people will use it that it's important to
standardize the name, even though everyone could implement it for themselves.
They seemed to think that by saying this they were disagreeing with you,
but I didn't read what you said as disagreeing with that sentiment.

[Rest of message, about other issues, not included in this particular reply]

∂26-Dec-85  2000	Moon@SCRC-STONY-BROOK.ARPA 	RE: Symbols as pathnames   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Dec 85  19:59:59 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 381627; Thu 26-Dec-85 14:55:15-EST
Date: Thu, 26 Dec 85 14:49 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: RE: Symbols as pathnames
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 26 Dec 85 14:47-EST from "BACH::NELSON" <nelson%bach.decnet@hudson.dec.com>
Message-ID: <851226144932.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 12/26/85 14:47
    From: "BACH::NELSON" <nelson%bach.decnet@hudson.dec.com>

    By choosing one from the list of pathname, filename, etc. to refer
    to pathnames, streams, and strings, did you mean that an argument
    called pathname could be any of those three types?  If you meant
    that the word pathname actually means "pathname, symbol or string"
    when used in the text of the book, that seems confusing; while a statement
    that an argument called "pathname" could be a pathname, string, or
    stream seems helpful.

I meant the latter; sorry to be ambiguous.

    If, by the way, the approach is to enumerate
    those three types under each function in chapter 23, it would probably
    be a god idea to do so for the pathname argument to require, as well.

Thanks, I missed that one.  Consider it added to my proposal.

∂27-Dec-85  0320	cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	GLS's clarifications list (moderately long)  
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Dec 85  03:20:44 PST
Received: from JANIS.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 27 Dec 85 06:26-EST
Date: Fri, 27 Dec 85 06:21 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: GLS's clarifications list (moderately long)
To: COMMON-LISP@SU-AI.ARPA
In-Reply-To: <8512200453.AA03243@uw-beaver.arpa>
Message-ID: <851227062125.6.CFRY@JANIS.AI.MIT.EDU>

   + (-: The obvious way to have an all-purpose undo function is to generalize setf
	  to work with an odd number of arguments:

	    (setf (symbol-function 'foo))  =>  (undefun 'foo)
	    (setf (symbol-value '*foov*))  =>  (mkunbound '*foov*)                  :-)

Not obvious to me, even if there's only one argument.
The overloading of the semantics of setf is clever ...
which is exactly why I'd prefer the function that does
the undo semantics to be spelled differently than "setf" .

To me (setf (accessor ...)) implies setting the thing to NIL,
but I wouldn't want setf to have that semantics either.

∂27-Dec-85  0530	GJC@MC.LCS.MIT.EDU 	Reader hacks   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Dec 85  05:30:41 PST
Date: Fri, 27 Dec 85 08:33:24 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject:  Reader hacks
To: GSB@MC.LCS.MIT.EDU
cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM,
    Moon@SCRC-STONY-BROOK.ARPA
In-reply-to: Msg of Thu 26 Dec 85 16:45:01 EST from Glenn S. Burke <GSB at MC.LCS.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].767075.851227.GJC>

A reader should be able to be a portable common lisp program right?
Maybe if a sufficiently flexible reader could be published then people like
GLS could use it.

∂27-Dec-85  1054	LOOSEMORE@UTAH-20.ARPA 	Another inconsistency in CLtL  
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 27 Dec 85  10:54:16 PST
Date: Fri 27 Dec 85 11:53:01-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: Another inconsistency in CLtL
To: common-lisp@SU-AI.ARPA
Message-ID: <12170503603.18.LOOSEMORE@UTAH-20.ARPA>

The specification for INTERN describes the optional "package" argument as
being a package, not a package name.  However, the discussion of #S syntax
for reading structures on page 357 shows INTERN being called with the
"package" argument being the symbol 'keyword.  Should this actually be
(find-package 'keyword), or have I missed something in the packages chapter
that says arguments named "package" can be either packages or package names?

-Sandra
-------

∂28-Dec-85  1509	Moon@SCRC-YUKON.ARPA 	BOA constructor questions   
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 28 Dec 85  15:09:14 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 182987; Sat 28-Dec-85 18:04:58-EST
Date: Sat, 28 Dec 85 18:02 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: BOA constructor questions
To: Guy Steele <gls@THINK-AQUINAS.ARPA>, LOOSEMORE@UTAH-20.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851226160949.7.GLS@THINK-JEHOSEPHAT.ARPA>
Message-ID: <851228180256.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 26 Dec 85 16:09 EST
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>

	Date: Thu 26 Dec 85 13:38:50-MST
	From: SANDRA <LOOSEMORE@UTAH-20.ARPA>

	It is not clear from the discussion of BOA constructors in the manual what
	is supposed to happen if you don't mention all the slot names in the arglist,
	or even that it's legal to omit slots from the arglist.  Presumably, the
	omitted slots should be initialized to whatever default value was given in
	the body of the defstruct; if this is the case, the manual should say so.
	Perhaps a better example would help.

I agree with your interpretation and with the suggestion for improving the manual.

	Also, it says that "the keywords &optional, &rest, and &aux are recognized
	in the argument list".  Is there a reason why &key is not permitted?  Or
	is this an oversight?

    I don't see any technical reason why &KEY should not be permitted, with
    semantics analogous to those for &OPTIONAL.  

Indeed.  It works with the obvious semantics in our implementation.

						 Then the standard
    constructor function can be explained as a special case the more general
    constructor feature that happens to take an argument for every slot and
    takes them all as &KEY arguments.

    But this prompts in me another question: does

    (defstruct (foo (:constructor build-foo (&optional baz &aux baz)))
      (baz 5))

    mean that

    (make-foo)		initializes BAZ to 5
    (make-foo :baz 43)	initializes BAZ to 43
    (build-foo 91)		initializes BAZ to 91
    (build-foo)		*does not initialize* BAZ   ?

    If not, how else can I say it?  (Never mind why I would want to.)

Isn't this in conflict with your (Guy's) suggested clarification to page 60,
that a function may not have two parameters with the same name?  If that clarification
was not intended to apply to &AUX variables, you didn't say so.

The way I read the Common Lisp manual, your example defstruct above does not
define any function named make-foo.  You'd have to say

    (defstruct (foo (:constructor build-foo (&optional baz &aux baz))
		    (:constructor make-foo))
      (baz 5))

if you wanted that.

I think the answer to "how else can I say it?" is that you can't say
it except by being more explicit and verbose, e.g.

    (defstruct (foo (:constructor build-foo (&optional baz))
		    (:constructor make-foo (&key (baz 5))))
      baz)

∂28-Dec-85  1533	edsel!eb@su-navajo.arpa 	Tail recursive Common Lisp interpreter? 
Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 28 Dec 85  15:33:25 PST
Received: by su-navajo.arpa with Sendmail; Sat, 28 Dec 85 15:30:24 pst
Received: by edsel.uucp (2.2/SMI-2.0)
	id AA12247; Sat, 28 Dec 85 15:15:18 pst
Date: Sat, 28 Dec 85 15:15:18 pst
From: edsel!eb@su-navajo.arpa (Eric Benson)
Message-Id: <8512282315.AA12247@edsel.uucp>
To: navajo!Common-Lisp@SU-AI
Subject: Tail recursive Common Lisp interpreter?

Recently, we added a new feature to our compiler: general tail-recursion
removal.  That is, when FOO returns the value of calling BAR, there is
no need to grow the stack; BAR can use the same stack frame as FOO and
return to its caller.  Scheme requires this behavior, so that iteration
can be defined in terms of recursion.  Scheme supporters tend to get
irate about Lisp implementations which do not have this behavior.  In
fact, they call this "properly tail-recursive," giving a moral tone to
the whole issue.

When I wrote our interpreter, I tried to be very careful so that if it
were compiled with a compiler which does tail recursion elimination, it
too would be properly tail recursive.  Finally, I had a chance to try it
out.  I compiled EVAL, loaded it in and typed

(DEFUN FOO (X)
  (IF (ZEROP X)
      (BREAK)
      (FOO (1- X))))

(FOO 10)

thus entering the debugger, expecting to find no frames on the stack.
To my dismay, I saw 10 BLOCK frames.  Then it dawned on me: every DEFUN
wraps a BLOCK around the body, so that I would have been able to say
(RETURN-FROM FOO ...) anywhere in my definition.  BLOCK is implemented
with a CATCH in the interpreter, and the last call of a CATCH is not
tail recursive; the CATCH frame must be removed from the stack before
returning.  Even FLET and LABELS aren't tail recursive, for the same
reason, due to our recent extension to them of the "implicit BLOCK"
feature.  Only raw LAMBDAs are truly tail recursive.

I would like to change this, but I don't want to do a lot of static
analysis in the interpreter. That tends to defeat the purpose of EVAL,
which I take to be fast turnaround time in testing code.  I can't see
any other way of implementing the implicit BLOCK except using CATCH or
some other mechanism which defeats tail recursion.  Does anyone have any
clever ideas for solving this problem?

∂28-Dec-85  1636	GJC@MC.LCS.MIT.EDU 	Tail recursive Common Lisp interpreter? 
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 28 Dec 85  16:36:04 PST
Date: Sat, 28 Dec 85 19:38:46 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject:  Tail recursive Common Lisp interpreter?
To: edsel!eb@SU-NAVAJO.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-reply-to: Msg of Sat 28 Dec 85 15:15:18 pst from edsel!eb at su-navajo.arpa (Eric Benson)
Message-ID: <[MC.LCS.MIT.EDU].767631.851228.GJC>

Thats an extremely interesting discovery. One known way to win: You
can implement an explicit control evaluator like one might in Scheme.
The control-point from a block then falls out like schemes lexical
catch contruct does. Or, what is easier, given a Scheme with lexical catch,
write your Common-Lisp interpreter in that. 

Here is another tail-recursion story. One of Papert's hackers was relating
to me one day how LOGO was tail recursive even though it used shallow
binding, and how that this was a pretty clever thing (to pull off)
So I said, ok, lets try to write:
  (DEFUN IFACT (N ACC) (IF (ZEROP N) ACC (IFACT (1- N) (* N ACC))))
and thus (DEFUN FACT (N) (IFACT N 1)). Well, my first try didnt work
at all, in fact, it didnt return ANY VALUE. I was then told that, OH,
to return a value you have to use OUTPUT. Thus (excuse the inexact logo syntax)
   TO IFACT :N :ACC IF N=0 OUTPUT ACC ELSE OUTPUT IFACT N-1 N*ACC
well, the OUTPUT caused the tail recursion to be broken.

  Or, you cant teach an ancient dog old tricks.
  Or, you can dress the language up but you cant take it ...


∂29-Dec-85  1415	DCP@SCRC-STONY-BROOK.ARPA 	Multiple values and &optional    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 29 Dec 85  14:15:51 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 382604; Sun 29-Dec-85 17:15:01-EST
Date: Sun, 29 Dec 85 17:18 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Multiple values and &optional
To: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>,
    Guy Steele <gls@THINK-AQUINAS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <851220222705.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <851229171821.7.DCP@NEPONSET.SCRC.Symbolics.COM>

    Date: Fri, 20 Dec 85 22:27 EST
    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>

    MULTIPLE-VALUE-CALL.

Not only is that the right answer, but recall that MULTIPLE-VALUE-BIND
is a MACRO, so says CLtL, and as far as I know the only way that macro
can expand into special forms and functions defined in CLtL is via
MULTIPLE-VALUE-CALL.

∂29-Dec-85  1524	NGALL@BBNG.ARPA 	Re: Reader hacks  
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 29 Dec 85  15:24:02 PST
Date: 29 Dec 1985 18:21-EST
Sender: NGALL@BBNG.ARPA
Subject: Re: Reader hacks
From: NGALL@BBNG.ARPA
To: gls@AQUINAS.THINK.COM
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[BBNG.ARPA]29-Dec-85 18:21:24.NGALL>
In-Reply-To: <851223164735.3.GLS@THINK-JEHOSEPHAT.ARPA>

	
    Date: Mon, 23 Dec 85 16:47 EST
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>
    To: common-lisp@SU-AI.ARPA
    Subject: Reader hacks
    Message-ID: <851223164735.3.GLS@THINK-JEHOSEPHAT.ARPA>
    
    I am writing code for reader macros and find I need the following
    things:
    (1) A predicate that is true of whitespace characters and false
	of all others.  The problem is that
	    (member foo '(#\Space #\Newline))
	doesn't cover tabs, etc., and
	    (member foo '(#\Space #\Newline #\Tab #\Form))
	is not completely portable because of the semi-standard
	character names.

How about?:

(defun whitespace-p (char)
  (with-input-from-string (input-string (string char))
    (null (peek-char t input-string nil nil nil))))

If char is a whitespace char., PEEK-CHAR will hit EOF and return NIL;
otherwise PEEK-CHAR will return the char.  Inefficient, but the only
portable solution I know.

I think there should be a function

SYNTAX-TYPE char  => {ILLEGAL | WHITESPACE | CONSTITUENT |
                      SINGLE-ESCAPE | MULTIPLE-ESCAPE | MACRO}


	-- Nick

∂30-Dec-85  0237	REM@IMSSS 	Retry, IMSSS->SCORE mail down a few days; Flush implicit catch frames
X-Sent: to SU-AI.ARPA by IMSSS.FRONSTAD.EDU via ETHERNET with PUPFTP; 1985-Dec-30 02:31:40 PST (=GMT-8hr)
X-Mailer: EMACS -> PSL (FORMAT+SEND-ALL) -> PUPFTP
Date: 1985 December 29 23:21:04 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A132535112014.G0353
From: Robert Elton Maas <REM@IMSSS.STANFORD.EDU>
To:edsel!eb@su-navajo.arpa
CC:COMMON-LISP@SU-AI
Subject:Retry, IMSSS->SCORE mail down a few days; Flush implicit catch frames
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until IMSSS.STANFORD.EDU registered)

Date: 28 Dec 1985 1824-PST
From: Rem@λIMSSSλ
Subject: I favor flushing implicit catch frames except where appropriate
To:   edsel!eb%su-navajo.arpa@λSCOREλ
cc:   COMMON-LISP%SU-AI@λSCOREλ

Your message is very interesting. It sounds like CL in forcing the
availibility of RETURN-FROM just about everywhere in the language has
accidently forbid efficient tail recursion except when an optimizing
compiler has gone around and flushed unneeded RETURN-FROM (CATCH) frames.
If you are correct, I would favor flushing this default behaviour of
CL, instead requiring programmers to say explicitly when some PROG or
LET might need the RETURN-FROM capability.

When I want to do a non-local return, I first think of THROW/CATCH, which
is completely general, and not of RETURN-FROM. Something like 99% of
PROGs and LETs et al are simple, don't need a non-local return mechanism.
Let's take a survey. Is there anyone who programs in such a way that any
significant fraction of PROGs or LETs et al make use of RETURN-FROM?
Is there anyone would have to rewrite a lot of code if RETURN-FROM frames
weren't implicit everywhere in the language. Would anyone object to
requiring explicit CATCH where nonlocal return frames are desired?

P.S. Normally all those extra frames are useful during debugging, so
when something bombs out you can look up the recursion stack and see
all the calls and jcalls still on the stack instead of just the calls
(notation: jcall = tail-recursion, call = true-recursion). But often
one has an interpreted function that is highly recursive but where
those extra frames aren't useful and cause stack overflow, so I can see
the value in being able to disable the creation of tail-recursion frames,
and I second the motion to maybe flush them.
-------

∂30-Dec-85  0601	GJC@MC.LCS.MIT.EDU 	tail recursion in CL interpreters. 
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 30 Dec 85  06:01:39 PST
Date: Mon, 30 Dec 85 09:04:23 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject:  tail recursion in CL interpreters.
To: REM%IMSSS@SU-SCORE.ARPA
cc: COMMON-LISP@SU-AI.ARPA
In-reply-to: Msg of 1985 Dec 29 23:21:04 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.STANFORD.EDU>
Message-ID: <[MC.LCS.MIT.EDU].768550.851230.GJC>

Did my reply get lost or something? It explained how you could write
an interpreter with tail recursion even with all the implicit BLOCK
statements.

∂30-Dec-85  0832	gls@THINK-AQUINAS.ARPA 	BOA constructor questions 
Received: from THINK.COM by SU-AI.ARPA with TCP; 30 Dec 85  08:32:29 PST
Received: from yon by GODOT.THINK.COM via CHAOS; Mon, 30 Dec 85 11:32:39 est
Date: Mon, 30 Dec 85 11:32 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: BOA constructor questions
To: Moon@SCRC-STONY-BROOK.ARPA, gls@THINK-AQUINAS.ARPA, LOOSEMORE@UTAH-20.ARPA
Cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
In-Reply-To: <851228180256.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <851230113242.2.GLS@THINK-YON.ARPA>

    Date: Sat, 28 Dec 85 18:02 EST
    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>

	Date: Thu, 26 Dec 85 16:09 EST
	From: Guy Steele <gls@THINK-AQUINAS.ARPA>

        ...

	But this prompts in me another question: does

	(defstruct (foo (:constructor build-foo (&optional baz &aux baz)))
	  (baz 5))

	mean that

	(make-foo)		initializes BAZ to 5
	(make-foo :baz 43)	initializes BAZ to 43
	(build-foo 91)		initializes BAZ to 91
	(build-foo)		*does not initialize* BAZ   ?

	If not, how else can I say it?  (Never mind why I would want to.)

    Isn't this in conflict with your (Guy's) suggested clarification to page 60,
    that a function may not have two parameters with the same name?  If that clarification
    was not intended to apply to &AUX variables, you didn't say so.

Yes, I suppose it is; but then the interpretation of &AUX variables in
this context is completely crocky anyway.  I think I prefer to have the
very simple rule that no duplicate names are permitted within a single
parameter list, period.  One can come up with reasonable interpretations
in many special cases, but such cases are probably all very poor
examples of style.

    The way I read the Common Lisp manual, your example defstruct above does not
    define any function named make-foo.  You'd have to say

	(defstruct (foo (:constructor build-foo (&optional baz &aux baz))
			(:constructor make-foo))
	  (baz 5))

    if you wanted that.

Funny.  I always thought that the normal constructor always gets created
unless explicitly suppressed with (:constructor nil), BOA constructors
being irrelevant to the question.  However, I now find that the prose at
the bottom of page 315 is horribly ambiguous.

    I think the answer to "how else can I say it?" is that you can't say
    it except by being more explicit and verbose, e.g.

	(defstruct (foo (:constructor build-foo (&optional baz))
			(:constructor make-foo (&key (baz 5))))
	  baz)

This sounds fine to me.  This might be awkward if "5" were a very large
expression and I wanted three constructors, two of which initialize slot
BAZ, but I am not going to lose sleep over it.

--Guy

∂30-Dec-85  1231	JAR@MC.LCS.MIT.EDU 	Retry, IMSSS->SCORE mail down a few days; Flush implicit catch frames 
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 30 Dec 85  12:30:40 PST
Date: Mon, 30 Dec 85 15:33:21 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject:  Retry, IMSSS->SCORE mail down a few days; Flush implicit catch frames
To: REM%IMSSS@SU-SCORE.ARPA
cc: COMMON-LISP@SU-AI.ARPA, edsel!eb@SU-NAVAJO.ARPA
In-reply-to: Msg of 1985 Dec 29 23:21:04 PST (=GMT-8hr) from Robert Elton Maas <REM at IMSSS.STANFORD.EDU>
Message-ID: <[MC.LCS.MIT.EDU].768914.851230.JAR>

    Date: 1985 December 29 23:21:04 PST (=GMT-8hr)
    From: Robert Elton Maas <REM at IMSSS.STANFORD.EDU>

    Your message is very interesting. It sounds like CL in forcing the
    availibility of RETURN-FROM just about everywhere in the language has
    accidently forbid efficient tail recursion except when an optimizing
    compiler has gone around and flushed unneeded RETURN-FROM (CATCH) frames.
    If you are correct, I would favor flushing this default behaviour of
    CL, instead requiring programmers to say explicitly when some PROG or
    LET might need the RETURN-FROM capability.

As GJC correctly points out, Scheme has always had a lexical catch (i.e.
block/return) which is implementable in such a way that catches incur no
net stack growth, and no static code analysis is needed.  The usual way
to do this allocates the control point (either a stub pointing into the
control stack, or the entire control stack) in the heap, but there are
more or less hairy alternative implementation strategies which do less
heap allocation (none, most of the time).  I don't think this problem is
much different from that of allocating storage for lexical environments,
which if not done carefully also threatens tail recursion.

So tail-recursion is not a reason to flush implicit blocks.  (I can
think of other reasons, but that's not the point.)

∂30-Dec-85  1247	REM%IMSSS.#Pup@SU-SCORE.ARPA 	Reader hacks, whitespace algorithm 
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 30 Dec 85  12:47:10 PST
Received: from IMSSS by Score with Pup; Mon 30 Dec 85 12:28:23-PST
Date: 29 Dec 1985 1717-PST
From: Rem@IMSSS
Subject: Reader hacks, whitespace algorithm
To:   NGALL%BBNG.ARPA@SCORE
cc:   COMMON-LISP%SU-AI@SCORE

It doesn't matter if your algorithm is inefficient, because it has
to be run only once per different character, after which the results
can be kept in a lookup table or as properties hanging off the character
objects. Therefore if the algorithm works at all, I think you have
solved the problem at hand, and since it's portable there's no urgency
to put your algorithm in the CLtL manual, the yellow pages will suffice.
<opinion of REM>
-------

∂02-Jan-86  1022	GSB@MC.LCS.MIT.EDU 	Re: Reader hacks    
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Jan 86  10:21:48 PST
Date: Thu,  2 Jan 86 13:24:29 EST
From: "Glenn S. Burke" <GSB@MC.LCS.MIT.EDU>
Subject: Re: Reader hacks
To: NGALL@BBNG.ARPA
cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM
Message-ID: <[MC.LCS.MIT.EDU].770795.860102.GSB>

    Date: 29 Dec 1985 18:21-EST
    From: NGALL@BBNG.ARPA

    I think there should be a function

    SYNTAX-TYPE char  => {ILLEGAL | WHITESPACE | CONSTITUENT |
                          SINGLE-ESCAPE | MULTIPLE-ESCAPE | MACRO}

Yes.  Please.  Don't forget terminating vs. non-terminating macro, and
keywords in the keyword package...

∂03-Jan-86  0050	cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	Re: Reader hacks    
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Jan 86  00:49:50 PST
Received: from DUANE.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 3 Jan 86 03:47-EST
Date: Fri, 3 Jan 86 03:46 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: Re: Reader hacks
To: GSB@MC.LCS.MIT.EDU, NGALL@BBNG.ARPA
cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM
In-Reply-To: <[MC.LCS.MIT.EDU].770795.860102.GSB>
Message-ID: <860103034658.1.CFRY@DUANE.AI.MIT.EDU>

    Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 2 Jan 86 13:46-EST
    Received: from SU-AI.ARPA by MC.LCS.MIT.EDU  2 Jan 86 13:48:16 EST
    Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Jan 86  10:21:48 PST
    Date: Thu,  2 Jan 86 13:24:29 EST
    From: "Glenn S. Burke" <GSB@MC.LCS.MIT.EDU>
    Subject: Re: Reader hacks
    To: NGALL@BBNG.ARPA
    cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM
    Message-ID: <[MC.LCS.MIT.EDU].770795.860102.GSB>

	Date: 29 Dec 1985 18:21-EST
	From: NGALL@BBNG.ARPA

	I think there should be a function

	SYNTAX-TYPE char  => {ILLEGAL | WHITESPACE | CONSTITUENT |
			      SINGLE-ESCAPE | MULTIPLE-ESCAPE | MACRO}

    Yes.  Please.  Don't forget terminating vs. non-terminating macro, and
    keywords in the keyword package...

I hope you meant here that syntax types should be specified by symbols
in the keyword package, ie :illegal, :whitespace, etc.

∂03-Jan-86  0818	REM%IMSSS.#Pup@SU-SCORE.ARPA 	Reader hacks, whitespace algorithm 
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 3 Jan 86  08:17:59 PST
Received: from IMSSS by Score with Pup; Fri 3 Jan 86 08:14:41-PST
Date: 29 Dec 1985 1717-PST
From: Rem@IMSSS
Subject: Reader hacks, whitespace algorithm
To:   NGALL%BBNG.ARPA@SCORE
cc:   COMMON-LISP%SU-AI@SCORE

It doesn't matter if your algorithm is inefficient, because it has
to be run only once per different character, after which the results
can be kept in a lookup table or as properties hanging off the character
objects. Therefore if the algorithm works at all, I think you have
solved the problem at hand, and since it's portable there's no urgency
to put your algorithm in the CLtL manual, the yellow pages will suffice.
<opinion of REM>
-------

∂03-Jan-86  0917	LOOSEMORE@UTAH-20.ARPA 	yet another typo in the manual 
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 3 Jan 86  09:17:31 PST
Date: Fri 3 Jan 86 10:16:31-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: yet another typo in the manual
To: gls@AQUINAS.THINK.COM
cc: common-lisp@SU-AI.ARPA
Message-ID: <12172321045.30.LOOSEMORE@UTAH-20.ARPA>

I haven't seen any mention of this one before:  on page 133, the prog*
macro is referred to as a special form.

-Sandra
-------

∂04-Jan-86  1905	@SU-SCORE.ARPA:GSB@MC.LCS.MIT.EDU 	Reader hacks, whitespace algorithm 
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Jan 86  19:05:23 PST
Received: from MC.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Sat 4 Jan 86 18:35:17-PST
Date: Sat,  4 Jan 86 14:51:14 EST
From: "Glenn S. Burke" <GSB@MC.LCS.MIT.EDU>
Sender: HENRIK@MC.LCS.MIT.EDU
Subject: Reader hacks, whitespace algorithm
To: "REM@IMSSS"@MC.LCS.MIT.EDU
cc: COMMON-LISP%SU-AI@SU-SCORE.ARPA
Message-ID: <[MC.LCS.MIT.EDU].772855.860104.HENRIK>

Any caching scheme has to be integrated with the existing system
sufficiently so that the information gets uncached if anyone
changes character syntaxes.

∂05-Jan-86  1523	shebs%utah-orion@utah-cs.arpa 	Defsetf and define-setf-method    
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 5 Jan 86  15:23:40 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
	id AA04498; Sun, 5 Jan 86 16:24:00 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
	id AA05598; Sun, 5 Jan 86 16:23:57 MST
Date: Sun, 5 Jan 86 16:23:57 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8601052323.AA05598@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Defsetf and define-setf-method

Recently I had a bright idea concerning the complex form of defsetf and
define-setf-method, namely that any defsetf could expand into an equivalent
call on define-setf-method, and that this would be the right thing for
complex defsetfs.  Well, after a few days of screwing around with this,
I decided that I didn't really understand how a complex defsetf was
supposed to work, or what its full setf method should look like.  Is it
all inherently hairy, or is there a simple relation between defsetf and
define-setf-method that this pea-brained implementor has failed to notice?

								stan

∂06-Jan-86  0854	RAM@C.CS.CMU.EDU 	Another inconsistency in CLtL   
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 6 Jan 86  08:54:06 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 6 Jan 86 11:54:17-EST
Date: Mon, 6 Jan 1986  11:54 EST
Message-ID: <RAM.12173103405.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   SANDRA <LOOSEMORE@UTAH-20.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Another inconsistency in CLtL
In-reply-to: Msg of 27 Dec 1985  13:53-EST from SANDRA <LOOSEMORE at UTAH-20.ARPA>


    I brought this up a couple months back, and I believe the
consensus was that all the functions that take package arguments will
accept a string or symbol as well, excepting the PACKAGE-xxx functions
which will only accept a package object.  I doesn't say this anywhere
in the manual; this is a "clarification."

  Rob

∂06-Jan-86  1323	Moon@SCRC-YUKON.ARPA 	Defsetf and define-setf-method   
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 6 Jan 86  13:23:00 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 185039; Mon 6-Jan-86 16:18:08-EST
Date: Mon, 6 Jan 86 16:23 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Defsetf and define-setf-method
To: Stanley Shebs <shebs%utah-orion@UTAH-CS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8601052323.AA05598@utah-orion.ARPA>
Message-ID: <860106162308.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sun, 5 Jan 86 16:23:57 MST
    From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)

    Recently I had a bright idea concerning the complex form of defsetf and
    define-setf-method, namely that any defsetf could expand into an equivalent
    call on define-setf-method, and that this would be the right thing for
    complex defsetfs.  

That is certainly a reasonable implementation technique and in fact is what I
believe most implementations do.  Actually defsetf and define-setf-method
usually both expand into a third, internal thing.

		       Well, after a few days of screwing around with this,
    I decided that I didn't really understand how a complex defsetf was
    supposed to work, or what its full setf method should look like.  Is it
    all inherently hairy, or is there a simple relation between defsetf and
    define-setf-method that this pea-brained implementor has failed to notice?

When you use define-setf-method you write a lot of calls to gensym, but when
you use defsetf the macro-expansion of defsetf takes care of making the gensyms
itself.  See the discussion on page 103.

Here's an example (Guy, maybe this should go in the manual):

(defsetf subseq (sequence start &optional end) (new-sequence)
  `(progn (replace ,sequence ,new-sequence
		   :start1 ,start :end1 ,end)
	  ,new-sequence))

(define-setf-method subseq (sequence start &optional end)
  (let ((seqtemp (gensym))
	(startemp (gensym))
	(endtemp (gensym))
	(stotemp (gensym)))
    (values (list seqtemp startemp endtemp)
	    (list sequence start end)
	    (list stotemp)
	    `(progn (replace ,seqtemp ,stotemp
			     :start1 ,startemp :end1 ,endtemp)
		    ,stotemp)
	    `(subseq ,seqtemp ,startemp ,endtemp))))

∂07-Jan-86  0038	cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	Type questions 
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 7 Jan 86  00:38:03 PST
Received: from JANIS.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 7 Jan 86 03:37-EST
Date: Tue, 7 Jan 86 03:38 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: Type questions
To: common-lisp@SU-AI.ARPA
Message-ID: <860107033828.3.CFRY@JANIS.AI.MIT.EDU>

- What's the relationship between keyword, the type,
  and keyword, a symbol in the keyword package?
  Spicelisp calls the type keyword a subtype of symbol.

- is (subtype foo foo) true for any valid type foo ?

- Are the new types: signed-byte and unsigned-byte
  subtypes of fixnum, like bit is?

- In Spicelisp, COMMON is a subtype of ATOM and
  ATOM is a subtype of COMMON. True in CL? 

CLtL should have explicite paragraphs and index entries
for every type. I noticed BIT and KEYWORD lacked this
kind of documentation.

∂07-Jan-86  0911	gls@THINK-AQUINAS.ARPA 	Type questions  
Received: from THINK.COM by SU-AI.ARPA with TCP; 7 Jan 86  09:10:50 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Tue, 7 Jan 86 12:10:49 est
Date: Tue, 7 Jan 86 12:11 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Type questions
To: cfry@OZ.AI.MIT.EDU, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <860107033828.3.CFRY@JANIS.AI.MIT.EDU>
Message-Id: <860107121140.2.GLS@THINK-JEHOSEPHAT.ARPA>

    Date: Tue, 7 Jan 86 03:38 EST
    From: Christopher Fry <cfry@OZ.AI.MIT.EDU>

    - What's the relationship between keyword, the type,
      and keyword, a symbol in the keyword package?
      Spicelisp calls the type keyword a subtype of symbol.

They are the same notion.  An item of type keyword is a symbol in the
keyword package.

    - is (subtype foo foo) true for any valid type foo ?

The book does not require this right now; SUBTYPEP is permitted to throw
up its hands and say "I don't know".  The nature of SUBTYPEP and what cases
it is required to handle ought to be tied down more.

    - Are the new types: signed-byte and unsigned-byte
      subtypes of fixnum, like bit is?

Yes.  The descriptions of these types on pages 48-49 explicitly describe
them as being equivalent to specified subtypes of integer (type specifiers
of the form (INTEGER x y)).

    - In Spicelisp, COMMON is a subtype of ATOM and
      ATOM is a subtype of COMMON. True in CL? 

How can COMMON be a subtype of ATOM?  CONS must be a subtype of COMMON,
so if COMMON is a subtype of ATOM then CONS must be a subtype of ATOM.
But no cons can be an ATOM (by the definition of ATOM), so if CONS is
a subtype of ATOM then CONS must be an empty type.  Therefore if COMMON
is a subtype of ATOM there are no conses.

    CLtL should have explicite paragraphs and index entries
    for every type. I noticed BIT and KEYWORD lacked this
    kind of documentation.

See my next message.

∂07-Jan-86  0913	gls@THINK-AQUINAS.ARPA 	No more index typos, please    
Received: from THINK.COM by SU-AI.ARPA with TCP; 7 Jan 86  09:12:57 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Tue, 7 Jan 86 12:12:56 est
Date: Tue, 7 Jan 86 12:13 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: No more index typos, please
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <860107121347.3.GLS@THINK-JEHOSEPHAT.ARPA>

I would like to ask that no more messages be sent to me about erroneous
or missing index entries in CLtL.  I am aware that the index is dreadful
and that many important entries are missing.  I have plans to do a much
more thorough job on the next edition of the book by starting from
scratch, so incremental corrections to the existing idnex are not useful
to me at this time.  Thanks to everyone who has pointed out errors in
the past.
--Guy

∂08-Jan-86  0839	kempf@hplabsc 	Hooks for Common Objects 
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 8 Jan 86  08:38:25 PST
Received: from hplabsc by hplabs.ARPA ; Wed, 8 Jan 86 08:37:10 pst
Received: by hplabsc (4.16/4.30) ;
	id AA03359; Wed, 8 Jan 86 08:37:59 pst
Date: Wed, 8 Jan 86 08:37:59 pst
From: Jim Kempf <kempf@hplabsc>
Message-Id: <8601081637.AA03359@hplabsc>
To: common-lisp@su-ai.ARPA
Subject: Hooks for Common Objects

(Please ignore if this posting is repeated, we're having some
 trouble with our mailer daemon)


At the December Common Lisp meeting in Boston, Alan Snyder
presented a list of proposed language changes which we
felt were needed in order to implement CommonObjects. For
the benefit of those who weren't at the meeting, here
is a quick summary of the changes (with notations for
changes which are also part of Guy Steele's list):

1) Change DEFSTRUCT in the following ways, to better support
   encapsulation:

  a) Specify that the underlying data structure for DEFSTRUCT's is
     a vector-like object to which user access is
     made difficult,

  b) Add a keyword argument specifying that no accessor
     functions be generated. Access to slots would then
     only be through the accessor functions for the underlying
     data structure,

  c) Require that the type predicate, if specified, be used
     by TYPEP,

  d) Allow DEFSTRUCT to take function names for functions to
     be used when two DEFSTRUCT's are compared using EQL, EQUAL,
     and EQUALP.

2) Change the type system in the following ways:

  a) Introduce a new predicate, TYPE-DEFINED-P, which takes a
     symbol and returns T if a type with that name is defined,

  b) Introduce a new function, UNDEFINE-TYPE, which takes a
     symbol and undefines the type, if it is defined. This is
     similar to Steele's proposal for undo functions,

  c) Introduce a new function, RENAME-TYPE, which takes two
     symbols, and renames the type known as the first to the
     second.

3) Introduction of a new special form, LET-PSEUDO, which allows
   the definition of lexical instance variables (might also be
   useful for Smalltalk and Flavors instance variable access).

4) Clarify the role of #, so that load-time execution of embedded forms
   is possible from compiled, as well as interpreted code.

5) Introduce the following optimization hooks:

   a) Allow the environment parameter to DEFMACRO to be queried for various
      information which would make optimization more portable. This is similar
      to Steele's proposal for PARSE-BODY, except DECLARE forms from the
      environment as well as the body would need to be returned,

   b) Allow a macro to be associated with a function name for compilation
      purposes. Most implementations will do this in a nonportably anyway,
      if only to allow arithmetic operations to be optimized,

   c) Add two functions, which facilitate the efficient definition of
      indirect function calls.

6) Introduce the following hooks for seperate compilation:

  a) Allow a macro to inquire on its &ENVIRONMENT parameter if the result
     will be used in a file compilation,

  b) Provide a hash table for each COMPILE-FILE where information associated
     with the compilation can be stored.

People who are interested in more details can ask for the document outlining
the hooks:

	A Common Objects Implementation Kernel, by Alan Snyder, Michael Creech,
	and James Kempf, STL-TM-85-14

Electronic addresses are SNYDER@HPLABS or KEMPF@HPLABS. Mail address is:

	Hewlett-Packard Labs
	1501 Page Mill Rd.
	Palo Alto, CA
	94304

The most critical of the above hooks is 6). Currently, COMPILE-FILE is not
defined to change its environment in any way which would allow one to
know that a file is being compiled. This has many (mostly unpleasent)
consequences for bootstrapping and type definition, and we currently 
use a nonportable technique which catches about 98% of the problems. 

We would be interested in other people's experiences with seperate 
compilation. How does one handle problems with compiling type/flavor/class
defintions which are part of the compiler, for example? Would the above
mentioned changes simplify things, or is there some way within the
current language standard that seperate compilation can be done
safely and portably?

	Jim Kempf	kempf@hplabs	

∂09-Jan-86  0847	gls@THINK-AQUINAS.ARPA 	Common Lisp 'open'   
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 9 Jan 86  08:33:10 PST
Received: from eligius by GODOT.THINK.COM via CHAOS; Thu, 9 Jan 86 10:44:07 est
Date: Thu, 9 Jan 86 10:45 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Common Lisp 'open'
To: massar@THINK-AQUINAS.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: The message of 8 Jan 86 20:13-EST from JP Massar <massar>
Message-Id: <860109104511.2.GLS@THINK-ELIGIUS.ARPA>

    Date: Wed, 8 Jan 86 20:13:29 est
    From: massar (JP Massar)

    Suppose I have the following:

    (open "x" :direction :output :if-exists :append :if-does-not-exist :create)

    This is fine and dandy unless I don't have permission to write to the file
    and/or create a new file.  Probing the file is of no use, since either the
    file is there and it tells me so or it isn't and it tells me so -- in 
    either case I still want to execute the open.

    It seems like a generic :if-unable-to <retval> construct would be a good
    idea.

    As it is I can see no way or writing robust, portable code that deals with
    files.  I realize that "The opening if files is an area where complete
    portability is too much to hope for", but this seems like a pretty general
    problem (even on a Lispm, I could probe a file, then have the Chaosnet
    go down, and have the open fail on me...).

    Any ideas?  Helpful hints?

What we really need is a Common Lisp error-handling system.
However, I am forwarding this to the Common Lisp mailing list.
--Guy

∂09-Jan-86  1910	LOOSEMORE@UTAH-20.ARPA 	questions about packages  
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 9 Jan 86  19:09:12 PST
Date: Thu 9 Jan 86 20:08:03-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: questions about packages
To: common-lisp@SU-AI.ARPA
Message-ID: <12174001594.14.LOOSEMORE@UTAH-20.ARPA>

1.  Can a package use itself?  Or is this "an error"?

2.  Does the :use argument to in-package default to the list of the
    lisp package in the same way that it does for make-package?  In
    other words, if you do (in-package 'foo) and package foo does not
    yet exist, does it default to using the lisp package?  What if
    package foo does exist but doesn't already use the lisp package?

-Sandra
-------

∂10-Jan-86  0711	NGALL@G.BBN.COM 	Re: questions about packages
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 10 Jan 86  07:11:21 PST
Date: 10 Jan 1986 09:52-EST
Sender: NGALL@G.BBN.COM
Subject: Re: questions about packages
From: NGALL@G.BBN.COM
To: LOOSEMORE@UTAH-20.ARPA
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]10-Jan-86 09:52:42.NGALL>
In-Reply-To: <12174001594.14.LOOSEMORE@UTAH-20.ARPA>

	
    Date: Thu 9 Jan 86 20:08:03-MST
    From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
    To: common-lisp@SU-AI.ARPA
    Subject: questions about packages
    Message-ID: <12174001594.14.LOOSEMORE@UTAH-20.ARPA>
    
    1.  Can a package use itself?  Or is this "an error"?
Yes. A package can use itself (though an error may be signalled due to name
conflicts).
    
    2.  Does the :use argument to in-package default to the list of the
	lisp package in the same way that it does for make-package?  In
	other words, if you do (in-package 'foo) and package foo does not
	yet exist, does it default to using the lisp package?  What if
	package foo does exist but doesn't already use the lisp package?
Hmmm...Good Question. "This function is similar to MAKE-PACKAGE" should be
made more explicit.  I think the intent here is that if :USE was
actually an argument to IN-PACKAGE it is merely passed on to the call
to MAKE-PACKAGE (in the case of FOO not existing); if it wasn't an
actual arg. to IN-PACKAGE, MAKE-PACKAGE is called with no :USE arg.
(and hence :USE defaults to '(LISP)).  In the case where FOO existed,
if :USE is not an actual arg. to IN-PACKAGE, :USE defaults to '().

	-- Nick

∂10-Jan-86  0941	RPG  	Varia from Tektronix    
To:   common-lisp@SU-AI.ARPA

I am forwarding this for Will Clinger at Tektronix:

With regard to the proposed starred change to page 145 of CLtL:

    (*) 145 ....Similarly, a function that takes a &REST argument
    should not destroy it because its top-level list structure might
    share with a list that the user gave as the last argument to
    APPLY.

This would imply that destructive operations on any list given as the
last argument to APPLY are also forbidden unless it is known that the
function being applied does not take a &REST argument.  The following
code, for example, would be in error:

(defun baz (&rest x)
   (if (numberp (car x))
       #'(lambda () (1+ (car x)))
       #'(lambda () 0)))

(defun kablooey ()
   (let* ((zog (list 3))
	  (bar (apply #'baz zog)))
      (setf (car zog) 'zag)
      (funcall bar)))

;;; William Clinger
;;; willc%tekchips@tektronix.csnet
;;; Tektronix Computer Research Laboratory

∂10-Jan-86  1102	GJC@MC.LCS.MIT.EDU 	SETF of an &REST list.   
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 10 Jan 86  11:02:22 PST
Date: Fri, 10 Jan 86 14:01:04 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject:  SETF of an &REST list.
To: RPG@SU-AI.ARPA
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of 10 Jan 86  0941 PST from Dick Gabriel <RPG at SU-AI.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].779630.860110.GJC>

What you have to say is that SETF on the &REST list is not portable.
e.g. 

(defun foo (&rest l) (setf (car l) 'foo))

(defun test ()
 (let ((x (list nil)))
   (apply 'foo x)
   (car x)))
   
In NIL (or Maclisp for that matter): (test) ==> NIL
In zetalisp its always been that: (test) ==> FOO.

This is also the kind of behavior that may be different depending
on if a function is interpreted or compiled or traced etc.


∂12-Jan-86  0642	RAM@C.CS.CMU.EDU 	fill-pointers and destructive sequence functions    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 12 Jan 86  06:42:04 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 12 Jan 86 09:42:21-EST
Date: Sun, 12 Jan 1986  09:42 EST
Message-ID: <RAM.12174652267.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: fill-pointers and destructive sequence functions


    If a destructive sequence function such as DELETE is passed an
array with a fill pointer, may it reduce the size of the argument by
adjusting the fill-pointer?  The alternative would be to require the
(ARRAY-DIMENSION <res> 0) to be the resulting length.  This seems
excessively restrictive, since sequence functions only deal with the
active elements of vectors.

    What should ADJUST-ARRAY do with the fill-pointer in an array if
there is no :FILL-POINTER argument specified?  It seems sub-optimal to
leave it pointing into hyperspace.  Does the fill pointer go away?

    Is it legal for MAKE-ARRAY to return an array with a fill-pointer
when no :FILL-POINTER option was specified?  This question is similar
to the question "Are there contexts in which not having a fill-pointer
is important?"  Currently any Spice Lisp vector which is not a
SIMPLE-ARRAY has a fill pointer.

  Rob

∂13-Jan-86  1711	LOOSEMORE@UTAH-20.ARPA 	time of evaluation   
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 13 Jan 86  17:10:05 PST
Date: Mon 13 Jan 86 18:08:50-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: time of evaluation
To: common-lisp@SU-AI.ARPA
Message-ID: <12175028466.9.LOOSEMORE@UTAH-20.ARPA>

Should types defined via deftype and defstruct be entered into the type
structure at compile time as well as load/eval time?  It seems pretty
useless to declare things to be of a structure type if the compiler
doesn't recognize the structure name as a valid type specifier.  The
documentation for deftype/defstruct says nothing special about things
happening at compiletime, though, so I assume the usual defaults apply
and nothing happens until loadtime unless you wrap an eval-when around
it.  Seems kind of awkward.

Along similar lines, I assume one has to wrap an eval-when around
defstructs if one wishes to use #s syntax later on in the file to
create a constant structure, so that the constructor function required
for reading in the constant will be defined at compiletime.

-Sandra
-------

∂14-Jan-86  1217	@MC.LCS.MIT.EDU:Soley@MC.LCS.MIT.EDU 	time of evaluation    
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 14 Jan 86  12:17:11 PST
Received: from CHERRY.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 JAN 86  15:17:47 EST
Date: Tue, 14 Jan 86 15:17 EST
From: Soley@MIT-MC.ARPA
Subject: time of evaluation
To: LOOSEMORE@UTAH-20.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <12175028466.9.LOOSEMORE@UTAH-20.ARPA>
Message-ID: <860114151755.6.SOLEY@MIT-CHERRY.ARPA>

    Date: Mon 13 Jan 86 18:08:50-MST
    From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
    Subject: time of evaluation
    To: common-lisp@SU-AI.ARPA
    Message-ID: <12175028466.9.LOOSEMORE@UTAH-20.ARPA>

    Should types defined via deftype and defstruct be entered into the type
    structure at compile time as well as load/eval time?

Definitely yes.  Although the book may not say so, it would be pretty
bad for the compiler to not recognize (and perhaps open-code accessors
of) a type previously defined in the same file.

    Along similar lines, I assume one has to wrap an eval-when around
    defstructs if one wishes to use #s syntax later on in the file to
    create a constant structure, so that the constructor function required
    for reading in the constant will be defined at compiletime.

I think DEFSTRUCT should be "implicitly" eval-when (eval compile load),
for the same reasons as above.  This is what Gold Hill GCLisp and others
do, for example.

	-- Richard Soley

∂14-Jan-86  1854	sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA 	Errata on p.431    
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 14 Jan 86  18:54:07 PST
Received: from tektronix by csnet-relay.csnet id ah00838; 14 Jan 86 21:43 EST
From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
To: common-lisp@su-ai.ARPA
Received: from tekchips by tektronix with smtp ; 14 Jan 86 13:08:36 PST
Date: Tuesday, 14 Jan 86 12:54:57 PST
Subject: Errata on p.431

There are two mistakes in the first example on p.431.
The function cerror in both places has an argument vals missing.
In the first half of the example:
 (cerror "Assume .............
 	  .....................
	  but ~R ~:[were~;was~] supplied."
          nvals (= nvals 1))
The last 2 args should be replaced by the three args:
 vals nvals (= nvals 1)

Similarly in the second cerror function, after the line
	but ~R were supplied."
the line 
 	 nvals)
should be replaced by
	vals nvals)

--sridhar



∂15-Jan-86  0606	BSG@SCRC-STONY-BROOK.ARPA 	time of evaluation
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Jan 86  06:05:55 PST
Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 392860; Wed 15-Jan-86 09:06:01-EST
Date: Wed, 15 Jan 86 09:11 EST
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: time of evaluation
To: Soley@MIT-MC.ARPA, LOOSEMORE@UTAH-20.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <860114151755.6.SOLEY@MIT-CHERRY.ARPA>
Message-ID: <860115091150.4.BSG@CONCORD.SCRC.Symbolics.COM>

    Date: Tue, 14 Jan 86 15:17 EST
    From: Soley@MIT-MC.ARPA

	Date: Mon 13 Jan 86 18:08:50-MST
	From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
	Subject: time of evaluation
	To: common-lisp@SU-AI.ARPA
	Message-ID: <12175028466.9.LOOSEMORE@UTAH-20.ARPA>

	Should types defined via deftype and defstruct be entered into the type
	structure at compile time as well as load/eval time?

    Definitely yes.  Although the book may not say so, it would be pretty
    bad for the compiler to not recognize (and perhaps open-code accessors
    of) a type previously defined in the same file.

	Along similar lines, I assume one has to wrap an eval-when around
	defstructs if one wishes to use #s syntax later on in the file to
	create a constant structure, so that the constructor function required
	for reading in the constant will be defined at compiletime.

    I think DEFSTRUCT should be "implicitly" eval-when (eval compile load),
    for the same reasons as above.  This is what Gold Hill GCLisp and others
    do, for example.

	    -- Richard Soley

This is completely unclear.  Consider an incompatible change to a defstruct
used by the compiler.  Consider that one of the accessor functions is passed
as a funarg by the compiler.  Doing this would break the compiler.  It has
to do something a lot more subtle, that limits its effects to functions being
compiled in the same file.

∂15-Jan-86  0815	SOLEY@MC.LCS.MIT.EDU 	time of evaluation
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 15 Jan 86  08:15:08 PST
Date: Wed, 15 Jan 86 11:16:02 EST
From: Richard Mark Soley <SOLEY@MC.LCS.MIT.EDU>
Subject:  time of evaluation
To: BSG@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA, LOOSEMORE@UTAH-20.ARPA
In-reply-to: Msg of Wed 15 Jan 86 09:11 EST from Bernard S. Greenberg <BSG at SCRC-STONY-BROOK.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].784707.860115.SOLEY>

    Date: Wed, 15 Jan 86 09:11 EST
    From: Bernard S. Greenberg <BSG at SCRC-STONY-BROOK.ARPA>
    To:   Soley at MIT-MC.ARPA, LOOSEMORE at UTAH-20.ARPA,
          common-lisp at SU-AI.ARPA
    Re:   time of evaluation

        Date: Tue, 14 Jan 86 15:17 EST
        From: Soley@MIT-MC.ARPA

    	Date: Mon 13 Jan 86 18:08:50-MST
    	From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
    	Subject: time of evaluation
    	To: common-lisp@SU-AI.ARPA
    	Message-ID: <12175028466.9.LOOSEMORE@UTAH-20.ARPA>

    	Should types defined via deftype and defstruct be entered into the type
    	structure at compile time as well as load/eval time?

    This is completely unclear.  Consider an incompatible change
    to a defstruct used by the compiler.  Consider that one of
    the accessor functions is passed as a funarg by the compiler.
    Doing this would break the compiler.  It has to do something
    a lot more subtle, that limits its effects to functions being
    compiled in the same file.

I had this exact problem with the GCLisp compiler, as a matter of fact.
HOWEVER, I think the language should be designed more for the user
than the compiler writer, who we assume has more smarts.

	-- Richard

∂15-Jan-86  0858	DLW@SCRC-STONY-BROOK.ARPA 	time of evaluation
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Jan 86  08:58:50 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 393039; Wed 15-Jan-86 11:58:41-EST
Date: Wed, 15 Jan 86 11:58 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: time of evaluation
To: BSG@SCRC-STONY-BROOK.ARPA, Soley@MIT-MC.ARPA, LOOSEMORE@UTAH-20.ARPA,
    common-lisp@SU-AI.ARPA
In-Reply-To: <860115091150.4.BSG@CONCORD.SCRC.Symbolics.COM>
Message-ID: <860115115858.7.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Wed, 15 Jan 86 09:11 EST
    From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>

    This is completely unclear.  Consider an incompatible change to a defstruct
    used by the compiler.

(Are you aware that defstruct is implicitly "(compile load eval)" in our
implementation, and always has been?)

The real issue here is what it means to "compile from a file".  It's a
tricky issue when the Lisp environment that's running the compiler is
not a special Lisp created only for that compilation and then discarded
(the way we used to do it in Maclisp), but is an ongoing environment.

When the compiler sees a "defmacro" early in a file, it ideally should
not actually alter the Lisp environment at all, but it should let forms
in the file use that macro.  It needs to maintain a "subjunctive Lisp
environment", in which the contract of the compiler, given a Lisp
fucntion to compile, is to produce code that will do the same thing that
the interpreted code would do if that interpreted code were run in the
"subjunctive environment", which means "if all the previous stuff file,
but not the subsequent stuff, had been evaluated".

The Symbolics implementation really does maintain a "subjunctive
environment" for macros.  But it doesn't do a perfect job.  Consider a
file with the following forms:

(defun util (x) (list x x))

(defmacro mac (y) (util y))

(defun test (z) (mac z))

Now, if you call compile-file on this file, your Lisp environment should
not end up having "util" defined when you are done.  Yet, "util" needs
to be in the "subjunctive environment", so that when the compiler tries
to compile "mac", it will be able to.  Our implementation of
compile-file signals "The function UTIL is not defined."  I'd be interested
to know if any implementation handles this correctly.

The current practice is that the programmer has to get around this by
inserting an eval-when around the definition of util (or put it into a
"defs" file that gets loaded before compilation, which is really the
same thing).  The problem is that it conflicts with/overrides the
definition of "util" in the running environment.

This is essentially the same problem as the one you are pointing out, in
the "defstruct that's part of the compiler" example, except that
breaking the compiler is obviously a more serious thing that will lead
to immediate worse problems.  Richard is right about how users don't
hack the compiler much, but it's still true that using (eval-when
(compile ...) ...)  breaks the principle that compile-file should leaves
the state of the Lisp environment unchanged, and user programs can
definitely suffer from this problem: you compile a new version, and the
suddently the old version doesn't work any more, perhaps because you
modified some function like util.

∂15-Jan-86  1002	kempf@hplabsc 	Re:  time of evaluation  
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 15 Jan 86  09:55:14 PST
Received: from hplabsc by hplabs.ARPA ; Wed, 15 Jan 86 09:53:25 pst
Received: by hplabsc (4.16/4.30) ;
	id AA07687; Wed, 15 Jan 86 09:54:28 pst
Date: Wed, 15 Jan 86 09:54:28 pst
From: Jim Kempf <kempf@hplabsc>
Message-Id: <8601151754.AA07687@hplabsc>
To: BSG@SCRC-STONY-BROOK.ARPA, DLW@SCRC-QUABBIN.ARPA, LOOSEMORE@UTAH-20.ARPA,
        Soley@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
Subject: Re:  time of evaluation
Cc: snyder@hplabsc

This discussion is interesting, in that, it parallels some of
our thinking on modifications to the compile time environment
to support CommonObjects object oriented programming. A
proposed addition to Common Lisp which we have suggested
is a compiler dictionary (essentially, a hash table) which
gets created during file compilation and into which defstructs
and define-types (which create CommonObjects types) can enter
information which needs to be discarded after the file is 
compiled. The problems with "really" defining a type or
defstruct at compile time not only have to do with the
compiler but also with the environment in general. Consider
development in an environment which uses types or defstructs
in its implementation. If changes are made to the types or
defstructs, one doesn't want those changes to be propogated
to the environment during the debugging and development
phase, otherwise the entire environment may fall apart. 
Our current version of CommonObjects uses a highly implementation
dependent way of getting around these problems, which works
about 99% of the time. It is inherently not portable, however,
because it depends on being able to tell when a file is
being compiled, and, according to the definition of compile-file,
this information is not made available. A similar problem occurs
with defstruct.

		Jim Kempf	kempf@hplabs

∂15-Jan-86  1049	FAHLMAN@C.CS.CMU.EDU 	time of evaluation
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jan 86  10:49:45 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 15 Jan 86 12:57:17-EST
Date: Wed, 15 Jan 1986  12:57 EST
Message-ID: <FAHLMAN.12175474181.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: time of evaluation
In-reply-to: Msg of 15 Jan 1986  12:54-EST from Jim Kempf <kempf at hplabsc>


I agree pretty much with Weinreb's analysis of the problem.  It seems to
me that defstructs and deftypes should be handled the same way macros
are when compiling a file.  In older Lisps of the Maclisp generation, I
think that it was always the case that such things were simply evaluated
in the Lisp in which the compiler is running, altering that environment
permanently.  This didn't bother people too much, since typically you
fired up a special Lisp/Compiler job that was only used for compiling
one or more files.  I think that this scheme is permitted in Common
Lisp, but I haven't gone back to check the fine print; I'm sure that
many implementations do it this way.

In newer Lisps, people would like to be able to call Compile-File, have
the compiler do its thing on one or more files, and then go on to do
other things in that Lisp.  The process of compiling one or more files
should ideally not have any permanent effects on the Lisp in which
Compile-File is called.  One way to do this is to have Compile-File
spawn a separate Lisp process to do the compilation(s) in, perhaps a
virgin Lisp or perhaps a clone of the calling Lisp.  (Which is
preferable?  Should a file being compiled be able to depend on macros
that happen to be defined in the calling Lisp?)

That solution is not attractive in systems like the Lisp Machine, where
there is only one big Lisp address space and where people like to live
in that for days or weeks on end without polluting it.  Such systems do
indeed need to create some sort of quarantined environment within their
single Lisp.  One suggestion made some time ago was that when a file did
not specify any particular package, it should not be compiled in the
calling Lisp's current package, but rather in
SPECIAL-COMPILER-TEMPORARY-PACKAGE.  The thing that dumps out the FASL
file (or whatever) would arrange that symbols interned in this specific
package would be loaded into whatever package is current when the FASL
file is read in.  On the other hand, if the file specifies package FOO,
you read the stuff into package FOO.  It seems to me that this would
solve the problem in many cases, since if the user defined a macro,
structure-name, or type name, the symbol naming that thing would be
quarantined.  However, you still could get conflicts in some odd cases,
or when the user compiles a file with a specified package from a Lisp
that has that package loaded.

-- Scott

∂15-Jan-86  1226	RAM@C.CS.CMU.EDU 	time of evaluation    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jan 86  12:25:55 PST
Received: ID <RAM@C.CS.CMU.EDU>; Wed 15 Jan 86 14:32:25-EST
Date: Wed, 15 Jan 1986  14:32 EST
Message-ID: <RAM.12175491458.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc:   BSG@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA,
      LOOSEMORE@UTAH-20.ARPA, Soley@MIT-MC.ARPA
Subject: time of evaluation


    I think it's a bad idea to make defstruct literally
eval-when (compile load eval).  It will cause you (the implementor) no
end of grief even if it doesn't bother users much.  In Spice Lisp, our
current solution is to have two separate defstruct definition
properties, DEFSTRUCT-DEFINITION and DEFSTRUCT-DEFINITION-IN-COMPILER.
The -IN-COMPILER property is set when the defstruct is compiled, and
the normal definition is set at load time.  The compiler definition is
used preferentially for purposes of inclusion and any compiler uses.

    Compiling a defstruct puts compiler information into the
environment so that accessors and predicates are open-coded, but the
actual function definitions are not put into the environment.  One
problem with a strict eval-when compile strategy is that it causes any
accessors in the environment to be clobbered with interpreted
definitions.  We also had problems with compiling the file which
defines streams breaking the type structure such that *TERMINAL-IO*
was no longer a stream, with understandably serious consequences.

    I'm sure that there are lots of problems with this approach, both
in particular and in general, since it is similar to the defmacro
problem but more complicated due to the more complicated semantics of
defstruct.  Nonetheless, I think that an approach like this is
expedient for the same reasons that make special-casing macros
important.

  Rob

∂15-Jan-86  1430	LOOSEMORE@UTAH-20.ARPA 	Re: time of evaluation    
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 15 Jan 86  14:30:04 PST
Date: Wed 15 Jan 86 15:27:01-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: Re: time of evaluation
To: RAM@C.CS.CMU.EDU
cc: DLW@SCRC-QUABBIN.ARPA, BSG@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA,
    Soley@MIT-MC.ARPA
In-Reply-To: <RAM.12175491458.BABYL@C.CS.CMU.EDU>
Message-ID: <12175523298.9.LOOSEMORE@UTAH-20.ARPA>

This sounds similar to what currently happens with DEFSTRUCT in PCLS --
the information needed to open-code accessors and for handling :include
gets added at both compile and load time, but the functions defstruct
generates are only defined a load time.  I think that, to be consistent,
it would probably be better if the functions were defined at compile
time too.  After all, if you've just overwritten part of the information
for an existing structure type, you might as well overwrite the rest of
it too, and then at least the two pieces of information will agree with
each other.

The reason why I brought this up in the first place is that it's very
difficult to write macros portably without knowing what things become
part of the compile-time environment and what things don't.  I suppose
one could take the conservative approach and wrap an
(eval-when (eval compile load) ...) around the entire contents of
each file, but somehow I don't think this is what the language
designers really had in mind.  I don't have particularly strong feelings
myself on what things should happen when, or whether things defined
in the context of the compiler should or shouldn't modify the
environment permanently.  I would rather see some agreement now on a
standard that most implementations already do, or can easily be changed
to do, rather than spend 3 years arguing about what the most elegant
solution is, and then another 3 years while everybody figures out how
to implement it....

-Sandra
-------

∂15-Jan-86  1445	DLW@SCRC-STONY-BROOK.ARPA 	time of evaluation
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Jan 86  14:45:28 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 393440; Wed 15-Jan-86 17:45:29-EST
Date: Wed, 15 Jan 86 17:45 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: time of evaluation
To: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12175474181.BABYL@C.CS.CMU.EDU>
Message-ID: <860115174547.1.DLW@CHICOPEE.SCRC.Symbolics.COM>

In what Lisp environment is compile-file defined to compile the file?
There are two possibilities: (1) it should use the present Lisp
environment; (2) it should use an empty initial Lisp environment.  CLtL
doesn't say, but it needs to, because the two are significantly
semantically different.

If (1), then the techniques of spawning a separate Lisp process, or
using a new package, won't work, unless you try to cleverly copy state
from one place another or something.  If (2), then you can't break your
program into a "defs" file that defines a bunch of macros, which you
then load before you compile other files.  It means that every time you
do a compile-file, you start with a bare Lisp and have to load up all
the files with all the macros and other things that you plan to use.
Even if you're compiling twenty files in a row and they all use the same
defs files, you have to load the defs files over and over again.  This
kind of "batch" operation is highly undesirable.

∂15-Jan-86  1457	RAM@C.CS.CMU.EDU 	time of evaluation    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jan 86  14:56:28 PST
Received: ID <RAM@C.CS.CMU.EDU>; Wed 15 Jan 86 17:55:22-EST
Date: Wed, 15 Jan 1986  17:55 EST
Message-ID: <RAM.12175528440.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   SANDRA <LOOSEMORE@UTAH-20.ARPA>
Cc:   BSG@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA, DLW@SCRC-QUABBIN.ARPA,
      Soley@MIT-MC.ARPA
Subject: time of evaluation
In-reply-to: Msg of 15 Jan 1986  17:27-EST from SANDRA <LOOSEMORE at UTAH-20.ARPA>


    I agree it would be most consistent to evaluate everything all the
time, but as JAR pointed out a while back, consistency is not an
attribute of the Common Lisp language.  In this case, I think it is
better to be inconsistent so that you aren't consistently screwed.

    One thing to consider is that when you make a thing implicitly
eval-when compile, there is no way to override this behavior.  In
contrast, it is always possible to make something evaluated in the
compiler by using eval-when (compile).  At least, that is my
interpretation of eval-when's semantics, which are rather poorly
defined, as I have mentioned before.

  Rob

∂15-Jan-86  1504	Moon@SCRC-STONY-BROOK.ARPA 	time of evaluation of defstruct, deftype, etc. 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Jan 86  15:04:41 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 393466; Wed 15-Jan-86 18:00:48-EST
Date: Wed, 15 Jan 86 18:01 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: time of evaluation of defstruct, deftype, etc.
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12175474181.BABYL@C.CS.CMU.EDU>
Message-ID: <860115180103.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

This problem cannot be solved with multiple address spaces, unless you have a
very complicated mechanism for sharing objects between address spaces, and
cannot be solved with packages, because packages provide partial sharing and
partial isolation with the division between sharing and isolation not being the
same division that you need to distinguish the Lisp world in which you are
running the compiler from the Lisp world that will exist when the compiler's
output is loaded.

A more viable technique is to attack the problem not at the level of binding
objects to addresses, and not at the level of binding strings to symbols, but
at the level of binding names to objects.  Many compilers already do this for
macros, using one mechanism for binding the name of a macro to its definition
when DEFMACRO is loaded, or evaluated interactively, and a second mechanism
when DEFMACRO is compiled.  It isn't difficult to extend this to other name
bindings, such as binding a structure name to the internal description of the
structure.  I'm sure we can all design data representations for doing this.
The main issue in implementing this is getting each place that looks up a name,
looking for an object, to know which mechanism it is supposed to be using.  In
some cases the lexical environment Common Lisp passes to macros is an
appropriate place to store this information.  I could say more, and so could
other implementors, but I don't want to bore you.

Stepping back a level, the main issue for the Common Lisp community is do
we want to say that this is an issue which each implementation should solve
for itself, in order to have a compiler that can be considered "high quality",
or is this something that should be made a standard part of the language,
with a portable interface?  Obviously one alternative is "better" for the
users and the other alternative is less work for the language standardization
effort.

∂15-Jan-86  1728	FAHLMAN@C.CS.CMU.EDU 	time of evaluation
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jan 86  17:27:56 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 15 Jan 86 20:27:31-EST
Date: Wed, 15 Jan 1986  20:27 EST
Message-ID: <FAHLMAN.12175556144.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: time of evaluation
In-reply-to: Msg of 15 Jan 1986  17:45-EST from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>


    In what Lisp environment is compile-file defined to compile the file?
    There are two possibilities: (1) it should use the present Lisp
    environment; (2) it should use an empty initial Lisp environment.  CLtL
    doesn't say, but it needs to, because the two are significantly
    semantically different.

I agree that it would be worthwhile to nail this down.

    If (1), then the techniques of spawning a separate Lisp process, or
    using a new package, won't work, unless you try to cleverly copy state
    from one place another or something.  If (2), then you can't break your
    program into a "defs" file that defines a bunch of macros, which you
    then load before you compile other files.  It means that every time you
    do a compile-file, you start with a bare Lisp and have to load up all
    the files with all the macros and other things that you plan to use.
    Even if you're compiling twenty files in a row and they all use the same
    defs files, you have to load the defs files over and over again.  This
    kind of "batch" operation is highly undesirable.

Your objection to interpretation 1 depends totally on what sort of
system you're thinking about.  On Unix, you can create a clone of the
current process with a simple fork.  Then if you're the new copy, you do
the compile and commit suicide.  Nothing clever required.

Your objection to 2 also depends on the assumptions you are making about
the system environment.  In the previous message, I was careful to say
"when you compile ONE OR MORE files".  If you spawn a virgin Lisp
process in which to compile, you just tell it to compile all 20 files
(including some defs files) in a lump, preserving state between
compiles; then commit suicide.  Or you could keep the compiler process
and its associated state around indefinitely and give the user a
REVIRGINIZE-COMPILER call which kills off the now-polluted compiler
process and creates a new fresh one.

On the 3600, either of these solutions presents a problem, I guess.
Since there's only one huge Lisp process (address space) to play with,
and since it is very expensive to save a copy of this huge thing on
disk, you don't have the option of compiling in one copy of an address
space while running in a second copy that is not polluted by the
compile.  The right solution is to catch up with Unix and other modern
operating systems by putting in true multiple processes (sorry, couldn't
resist), but if that is not possible, I guess this business of stashing
the compiler's state changes in funny undoable places is about the best
you can do.  I wouldn't like to see this solution cast in concrete for
everyone, though.

-- Scott

∂15-Jan-86  1736	FAHLMAN@C.CS.CMU.EDU 	time of evaluation of defstruct, deftype, etc.  
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jan 86  17:36:37 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 15 Jan 86 20:35:54-EST
Date: Wed, 15 Jan 1986  20:35 EST
Message-ID: <FAHLMAN.12175557655.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: time of evaluation of defstruct, deftype, etc.
In-reply-to: Msg of 15 Jan 1986  18:01-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>


    This problem cannot be solved with multiple address spaces, unless you have a
    very complicated mechanism for sharing objects between address spaces, 

I don't understand this.  What has to be shared in a complicated way?


    Stepping back a level, the main issue for the Common Lisp community is do
    we want to say that this is an issue which each implementation should solve
    for itself, in order to have a compiler that can be considered "high quality",
    or is this something that should be made a standard part of the language,
    with a portable interface?  Obviously one alternative is "better" for the
    users and the other alternative is less work for the language standardization
    effort.

As I said in my answer to Weinreb, the way you want to go about solving
this problem depends a lot on the kind of system you're running in.  In
Accent, for example, there are multiple processes and it is very quick
and easy to create a clone process due to the copy-on-write memory
management.  We should probably standardize those things that we have to
in order to have sets of portable source files that can be compiled and
run anywhere, and leave to the local culture those things that are not
required for this.

-- Scott

∂15-Jan-86  1850	Moon@SCRC-STONY-BROOK.ARPA 	time of evaluation of defstruct, deftype, etc. 
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Jan 86  18:50:25 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 393624; Wed 15-Jan-86 21:50:12-EST
Date: Wed, 15 Jan 86 21:50 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: time of evaluation of defstruct, deftype, etc.
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12175557655.BABYL@C.CS.CMU.EDU>
Message-ID: <860115215029.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 15 Jan 1986  20:35 EST
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

	This problem cannot be solved with multiple address spaces, unless you have a
	very complicated mechanism for sharing objects between address spaces, 

    I don't understand this.  What has to be shared in a complicated way?

Copy-on-write is fine for getting things to the compiler, but what if you want to
get something back?

I don't want to get into a long discussion of this.

	Stepping back a level, the main issue for the Common Lisp community is do
	we want to say that this is an issue which each implementation should solve
	for itself, in order to have a compiler that can be considered "high quality",
	or is this something that should be made a standard part of the language,
	with a portable interface?  Obviously one alternative is "better" for the
	users and the other alternative is less work for the language standardization
	effort.

    As I said in my answer to Weinreb, the way you want to go about solving
    this problem depends a lot on the kind of system you're running in.

So your position is that this should not be made a standard part of the language.
OK.

∂16-Jan-86  0141	REM@IMSSS 	2 ways to compile macros correctly
X-Sent: to SU-AI.ARPA by IMSSS.FRONSTAD.EDU via ETHERNET with PUPFTP; 1986-Jan-16 01:39:30 PST (=GMT-8hr)
X-Mailer: EMACS -> PSL (FORMAT+SEND-ALL) -> PUPFTP
Date: 1986 January 16 01:37:21 PST (=GMT-8hr)
From: Robert Elton Maas <REM@IMSSS> (this host known locally only)
To:COMMON-LISP@SU-AI
Subject:2 ways to compile macros correctly
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA

From the discussion, it seems there are two major ways to implement
isolation of the compiler environment from the week-old running
environment so that the compiler doesn't side-effect the running
environment (assuming your operating system doesn't allow you to
simply create a second virtual machine identical to the original but
with copy-on-write):
 (1) You can implement copy-on-write at the LISP level, if you have
  tree-structured packages or can fake the same out by long names of packages.
 (2) You can install all compiler side-effects as unusual properties
  instead of the usual properties.

To implement (1), when you start a compilation you make a complete
copy of all the packages in the current environment, origined from
some lower level instead of the top level of the package-tree, except
you don't actualy copy the packages (hashtables) you merely set up an
indirect vector that is copy-on-write, so the first time you actually
modify any package that hashtable gets copied but the ones you haven't
modified don't need to get copied at all. If you implement hashtables
as balanced binary trees instead of as linear arrays, you only have
to copy the log(N) path down to the change rather than en masse the
whole contiguous hash array.

To implement (2) (Moon's suggestion I believe), whenever a macro
definition is compiled, you store it as a CMACRO instead of a normal
MACRO, whenever a global SETQ occurs, you use the CVALUE property
instead of the VALUE cell, likewise for CFUNCTION property instead of
FUNCTION cell, CDEFSTRUCT instead of DEFSTRUCT, etc. etc.  When the
compiler is looking for the definition of a macro or auxilary function
needed for macro etc. it looks first for the C... which overrides the
normal definition if both are present. Meanwhile the compiler innerds
continues to use the normal definitions and totally ignore he C...
stuff, so none of the C... stuff can break the compiler itself.

CLtL should specify the semantics, namely that (1) the compiled-file
environment should be initialized to the current running environment
unless that is overridden (virgin LISP wanted instead for example),
(2) side-effects due to compiling definitions and SETQs etc. should
afect only the compiled-file environment not the compiler-innerds =
current-running-LISP environment, (3) when done with a batch of
compilations the compiled-file environment should be discarded unless
for some reason the operator wants it kept around for later use
compiling more files or debugging etc. -- The method of implementation
should be up to the compiler writer, with the above two methods (and
spawn extra process on Unix or other multi-virtual-machine systems as
a third method) merely suggested as ways it can done.

Alternately the above can be summarized by two postulates, (1) as it
says now, later loading the compiled file should have the same
semantics as later loading it interpreted, (2) anything needed to make
(1) work shouldn't modify the current running environment (in which
the compiler itself runs) in any way even temporarily except of course
for consuming memory and time.

(Opinion of REM)

∂16-Jan-86  1126	HEDRICK@RED.RUTGERS.EDU 	compiler enviornment
Received: from RED.RUTGERS.EDU by SU-AI.ARPA with TCP; 16 Jan 86  11:26:05 PST
Date: 16 Jan 86 14:25:13 EST
From: Charles Hedrick <HEDRICK@RED.RUTGERS.EDU>
Subject: compiler enviornment
To: common-lisp@SU-AI.ARPA
Message-ID: <12175752345.24.HEDRICK@RED.RUTGERS.EDU>

We have some experience with the compiler environment, based on
our UCI Lisp implementations.  In our second-generation
UCI Lisp (called ELISP), we decided to separate the environment
of the compiler from that of the current core image.  We carefully
kept all macros defined in a compiled file on separate properties
from the normal macro property, and did other related things.
We found that this confused users no end.  For simple programs, none
of this mattered.  For complex systems, we found that users would
normally supply macros, structure declarations, and functions that
were used to expand both the macros and structure declarations.
They would get very confused when macro compilation blew up because
it couldn't get to functions that they had defined in their core image.
I am sure that all of this could be solved by appropriate use of
EVAL-WHEN, and appropriate care in implementation.  But I suspect
that most users would find it easier just to let the compiler use
the current Lisp environment.  I don't think Lisp-level copy on write
is really needed.  Most of our users are capable of writing 
initialization files that load in all of the pieces of their system
that are needed for compilation.  Then they have the choice of
compiling in their current core image, or getting a new one,
loading in the necessary initialization file, and compiling there.
I suspect it would be handy to have a way of making it easy to do
that in a subfork.  A function like 
  (COMPILE-IN-SUBFORK files-to-load files-to-compile)
with some way to keep the subfork around for later compilations.
Unless I hear some proposal more convincing than those so far, I don't
think these mechanisms are ready for standardization yet.
-------

∂16-Jan-86  1407	REM@IMSSS 	compiler environment, how best to isolate side effects
X-Sent: to SU-AI.ARPA by IMSSS.FRONSTAD.EDU via ETHERNET with PUPFTP; 1986-Jan-16 14:05:55 PST (=GMT-8hr)
X-Mailer: EMACS -> PSL (FORMAT+SEND-ALL) -> PUPFTP
Date: 1986 January 16 14:04:27 PST (=GMT-8hr)
From: Robert Elton Maas <REM@IMSSS> (this host known locally only)
To:COMMON-LISP@SU-AI.ARPA
CC:HEDRICK@RED.RUTGERS.EDU
Subject:compiler environment, how best to isolate side effects
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA

H> Date: 16 Jan 86 14:25:13 EST
H> From: Charles Hedrick <HEDRICK@RED.RUTGERS.EDU>
H> We carefully kept all macros defined in a compiled file on separate
H> properties from the normal macro property, ...
H> We found that this confused users no end.

Reasonable argument against Moon's separate-C-property idea, sigh. I
was hoping that would be the method of choice because it's the easiest
correct method to implement.

H> For complex systems, we found that users would normally supply macros,
H> structure declarations, and functions that were used to expand both
H> the macros and structure declarations.  They would get very confused
H> when macro compilation blew up because it couldn't get to functions
H> that they had defined in their core image.

It sounds like your compiler used the C... properties exclusively,
refusing to use normal propertis even when the C... property didn't
exist. My suggestion (perhaps I was unclear) was to have the C...
properties mask the normal properties for the compiler operations on
the file, so if the user happened to define a normal macro or auxilary
function in the normal environment before starting the compilation
task the macro or auxilary function would still be seen unless it was
shadowed by a new definition within the file itself (and would be
shadowed only later in the file after the new definition actually
occurred). Thus the compiler would never "blow up because it couldn't
get to functions ..." as your compiler did. (In the other direction,
the innerds of the compiler and other things running in the normal
environment would not see the C... stuff at all. Perhaps that's the
phrase you saw and misapplied to the reverse case of compilation
seeing normal stuff.)

H> But I suspect that most users would find it easier just to let the
H> compiler use the current Lisp environment.

Remember the problem stated by somebody earlier in this discussion, if
you do that you can't build a new version of the compiler because
macros and auxilary functions being compiled will replace macros and
auxilary functions the compiler is trying to use to conduct the
compilation, causing the compiler to crash. We are trying to find a
bugfix for that problem so that it will be easy to compile compilers
in common-lisp.

H> Then they have the choice of compiling in their current core image, or
H> getting a new one, ...
H> I suspect it would be handy to have a way of making it easy to do
H> that in a subfork.  A function like 
H>   (COMPILE-IN-SUBFORK files-to-load files-to-compile)
H> with some way to keep the subfork around for later compilations.

As was pointed out, on LISP machines and other single-address-space
machines, you can't do that except by discarding the current core
image that may have taken weeks to build up. It would be nice to solve
address-space problems (using "address space" in the general sense of
tag->value mapping such as value cell or functional properties etc.)
within LISP itself without assuming an underlying operating system that
supports multiple virtual machines (forks etc.).

H> Unless I hear some proposal more convincing than those so far, I don't
H> think these mechanisms are ready for standardization yet.

With this I agree. On machines with multiple virtual machines that can
be initialized to have identical memory contents but with
copy-on-write, most users will want the COMPILE-IN-SUBFORK feature,
although compiling a new version of the compiler will take special
care. On other machines without multiple virtual machines the whole
thing will need to be done within LISP itself somehow. The desiderata
(semantics) should be specified, perhaps somewhat like I proposed in
my previous message (compiled file equivalent to interpreted file, no
side effects propagate back to normal environment), leaving the
implementation method for the implementor to pick.

(Another example: I still dislike the insistance that property lists
 be implemented as alternating lists instead of using whatever method
 the implementor chooses. Balanced binary trees for property lists
 would solve a lot of expensive-linear-search problems we were
 discussing a few weeks ago, and the implementor should be able to
 choose ASSOC lists or alternating or bbt or hashtable or whatever. You
 don't need a whole new set of functions, since you can use optional or
 keyword parameters for modifying the existing functions, such as
  (ASSOC key alist) can give you normal ASSOC-list search, while
  (ASSOC key altlist :FORMAT ALTLIST) can force it to handle
 alternating lists if you use them somewhere explicitly, or
  (ASSOC key balbinarytree :FORMAT BBT) can force it to handle balanced
 binary trees, and finally
  (ASSOC key plist :FORMAT PLIST) can give you whatever the
 implementation is using for property lists.
 Likewise (GET symbol key default) et al can be extended to
  (GET bbt key default :FORMAT BBT), (REMPROP altlist key :FORMAT ALIST)
 et al.)

If we can prove mathematically there's only one internal mechanism
that works, then we should set that in concrete in CLtL, otherwise not.

(Opinion of REM)

∂17-Jan-86  0303	GJC@MC.LCS.MIT.EDU 	compiler enviornment
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 17 Jan 86  03:03:24 PST
Date: Fri, 17 Jan 86 06:04:14 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject:  compiler enviornment
To: HEDRICK@RED.RUTGERS.EDU
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of 16 Jan 86 14:25:13 EST from Charles Hedrick <HEDRICK at RED.RUTGERS.EDU>
Message-ID: <[MC.LCS.MIT.EDU].786938.860117.GJC>

I agree, compiling and running in the same environment is just
something that users need to be aware of if they are the type that
like to debug their code using COMPILE-DEFUN in their ZMACS buffers,
as compared with the type that like to make a couple changes in their
sources and do MAKE-SYSTEM :COMPILE. If it were not for global special
declarations, macros, defstruct, defflavor and the like there really
wouldnt be much difference in semantics between the two styles.
That the implementations usually go to a bit of trouble to avoid
certain screws with defmacro and defflavor is nice of course.

∂17-Jan-86  0701	pyramid!bein@sri-unix 	compile environment.. 
Received: from SRI-UNIX.ARPA by SU-AI.ARPA with TCP; 17 Jan 86  07:01:11 PST
Received: by sri-unix.ARPA (4.12/4.16)
	id AA23958; Fri, 17 Jan 86 06:56:36 pst
Received: by pyramid (4.12/3.14)
	id AA10463; Fri, 17 Jan 86 04:07:56 pst
Date: 17 Jan 1986 04:00 PST
From: David Bein <pyramid!bein@sri-unix>
Subject: compile environment..
To: fahlman@cmu-cs-spice.ARPA
Cc: common-lisp@su-ai.ARPA
Message-Id: <506342289/bein@pyramid>

Scott:

  Two cheers for Accent -- they have clones and do it via copy-on-write
  One cheer for Unix -- they don't have copy-on-write..

  How about the following?

(1) compile-file :affect-environment <val> :use-environment <val>
		:load-result <val>

	:affect-environment specifies whether or not it is permissible
	to muck with current image in the process of effecting the
	compilation. default: nil -- do not mess with my space

	:use-environment specifies that the current environment is
	needed (or not) for the compilation. default: nil always
	be clean and use the "standard" environment.

	:load-result says what to do with the result and does not
	necessarily imply that the current environment will be
	messed with in any ways other than what are implied if
	you only load the result of compilation. default: nil

Letting the defaults for these be NIL and putting the handling
of them into the same gray-zone as some of the file ops implies
that they are standardized for those environments where they
make sense (and can be implemented) and simply ignored where
they can not be done or do not make sense.

(Look out for the black-zone)...

(2) compile :clone <val> :virgin <val> :in-current-env <explicit-progn-form>
		:in-other-environment <explicit-progn-form>

	:clone means explicitly do not mess with my process space
	to compile my function. The result of the compilation, i.e.
	the function object, magically finds it way into my space.

	default: nil -- do it in my space -- mess with it too.

	:virgin implies clone and do something akin to an exec
	with proper redirection such that the result of the
	compilation comes back as in :clone. Exactly what the
	"clean" environment must look like should be well
	specified as it is expected that this is the only
	part which could easily be standardized.

	default: nil -- do it in my space -- mess with it too.

	:in-current-environment means evaluate forms in the current
	environment and then :clone with the result being stuffed
	back into my current space. This is somewhat akin to
	eval-before-context-save or something like that.

	default: nil -- this means nothing special if there is not some
	kind of context saving mechanism going on other than yet another
	kind of top-level eval-when-who-knows kind of form.

	:in-other-environment means evaluate the forms after getting
	into the new environment. It applies to either :clone or
	:virgin. It is somewhat akin to eval-after-context-save
	or something like that. The effects of this should not
	be noticed in the post-compile environment.

	default: nil -- this means nothing if there is no way
	to get a new context or maybe it should be yet another
	pre-form which acts like eval-when- ...

Somewhere in here we find that it is useful to have a working
definition of what is a process (from a CL point of view) and
that many things we would like to be able to do are limited
by the fact that we don't have a good handle on things. I
could very easily graft pieces from Accent or Unix into
a working process definition, but that is beyond the question
at hand. I guess your reply to Moon et al is just the tip of
the iceberg.

Comments?

--David

p.s. What about errors in compilation if we do it in another
	process space?

∂17-Jan-86  0753	FAHLMAN@C.CS.CMU.EDU 	compile environment..  
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 Jan 86  07:53:48 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 17 Jan 86 10:53:40-EST
Date: Fri, 17 Jan 1986  10:53 EST
Message-ID: <FAHLMAN.12175975952.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   David Bein <pyramid!bein@SRI-UNIX.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: compile environment..
In-reply-to: Msg of 17 Jan 1986  07:00-EST from David Bein <pyramid!bein at sri-unix>


David,

I think your suggestions are good ones for systems that can provide
these styles of compilation.  I have a quibble or two about the
defaults, and am dubious about providing nay isolation for COMPILE, but
basically something like this would give the user the proper degree of
control.

I guess my preference would be to leave this sort of thing outside the
language standard, but let implementations that can support this stuff
use the same syntax by informal agreement.  It seems to cause a lot of
confusion to put something into the standard but to indicate that it is
optional.  Most of the environment-sensing functions were put into the
book in the spirit of "you don't have to provide this, but if you do it
should look like this".  I get a lot of bug reports from people who
don't understand that some of this stuff is optional.

-- Scott

∂17-Jan-86  1628	DLW@SCRC-QUABBIN.ARPA 	time of evaluation    
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 17 Jan 86  16:28:42 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 236379; Fri 17-Jan-86 19:28:08-EST
Date: Fri, 17 Jan 86 19:28 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: time of evaluation
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12175556144.BABYL@C.CS.CMU.EDU>
Message-ID: <860117192843.4.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Wed, 15 Jan 1986  20:27 EST
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

					  I guess this business of stashing
    the compiler's state changes in funny undoable places is about the best
    you can do.  I wouldn't like to see this solution cast in concrete for
    everyone, though.

There's no reason that this solution, or any other internal
implementation technique used in a Lisp system, should be cast in
concrete for everyone.  It's important to distinguish between the
defined semantics of Common Lisp, and implementation techniques.

The semantic question is what compile-file does vis a vis the Lisp
environment in which compile-file is called.  Revising my earlier
twofold choice in light of something Moon said, there are three
possibilities:

(1) The files being compiled see an empty Lisp environment when the
compilation starts.  The Lisp environment that called compile-file is
untouched.

(2) The files being compiled see a Lisp environment identical to the one
from which compile-file was called.  The Lisp environment that called
compile-file is untouched.

(3) The files being compiled see a Lisp environment identical to the one
from which compile-file was called.  The Lisp environment that called
compile-file is modified by side-effects performed on the Lisp
environment during the compilation.

Personally, I would find style (1) to be painful and inconvenient even
if my machine could switch to a new Lisp environment in two nanoseconds,
because I want the compilation to see the state in my Lisp environment.
Think of people who define their favorite macros in their init files,
who would then have to create some sort of "compiler init file" to set
up the compilation environment for all of their programs, as a simple
example.  I admit that this is a matter of philosophy of programming
environment that other people could validly disagree with.  I think that
(2) is what I want, although I can see some benefits in (3) under some
circumstances.

Do we have to make a decision on this?  If we feel that this behavior
must be made consistent from one Common Lisp to the next in order to
allow portability, that would mean that we have to make a decision.
Otherwise we can just say "Common Lisp doesn't specify it."  But let's
make sure that we're not introducing a new way to make porting not work.

∂17-Jan-86  1644	DLW@SCRC-QUABBIN.ARPA 	compiler environment, how best to isolate side effects   
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 17 Jan 86  16:42:48 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 236384; Fri 17-Jan-86 19:41:45-EST
Date: Fri, 17 Jan 86 19:42 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: compiler environment, how best to isolate side effects
To: REM%IMSSS@SU-SCORE.ARPA, COMMON-LISP@SU-AI.ARPA
cc: HEDRICK@RED.RUTGERS.EDU
In-Reply-To: The message of 16 Jan 86 17:04-EST from Robert Elton Maas <REM@IMSSS>
Message-ID: <860117194222.5.DLW@CHICOPEE.SCRC.Symbolics.COM>

Your "C-property" stuff is an implementation-oriented description of
what I referred to as a "subjunctive environment".  Contrary your mail,
what Hedrick said is NOT a "reasonable argument against" this.  In
Hedrick's system, macros were placed into the subjunctive environment,
but functions were not.  That's why users were confused no end.  Had
everything been put into the sujunctive environment, it would have
worked fine.

The Symbolics system right now is like what Hedrick describes, except
that EVAL-WHEN is available.  So users can carefully put EVAL-WHEN's
around functions that are needed in the subjunctive environment, so that
the macros that call them will work.  Unfortunately, (1) you have to
remember to put in the EVAL-WHEN's, and understand what they mean, and
(2) when you do compile-file, the function is left around in your Lisp
environment.  While I haven't seen a lot of evidence of confused users,
I agree that this is the sort of thing I'd expect to confuse people,
since it's rather subtle.  Doing the "subjunctive environment" would
make everything work right without muss or fuss.  We would have done
it by now except that it's so hard to implement in this architecture.

I'm getting pretty close to agreeing that this isn't something we can
tackle easily by simply dictating a behavior in CLtL.  Instead we'll
have to come up with one or two conventions so that portability can be
achieved.

∂17-Jan-86  1813	hplabs!snyder@hplabs.ARPA 	Re: time of evaluation 
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 17 Jan 86  18:13:35 PST
Received: by hplabs.ARPA ; Fri, 17 Jan 86 18:12:12 pst
Date: Friday, January 17, 1986  18:10:18
From: snyder@hplabs.ARPA
Subject: Re: time of evaluation
To: common-lisp@SU-AI.ARPA
In-Reply-To: <860117192843.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46

        There's no reason that this solution, or any other internal
        implementation technique used in a Lisp system, should be cast in
        concrete for everyone.  It's important to distinguish between the
        defined semantics of Common Lisp, and implementation techniques.

However, if there are mechanisms being used to support side-effect-free (or at
least "reduced side effect") file compilation, it would be nice if there were
a portable interface by which those mechanisms could be accessed by language
extensions (for example, object oriented programming extensions).

It would also be nice if those mechanisms were as effective as we know how to
(portably) make them.  For example, I believe a side-effect avoiding mechanism
should have the following properties:

  1. It should distinguish forms being compiled from forms being
     interpreted during compilation (e.g., because the compiler is
     interpreted, or because a macro expansion function is interpreted, or
     because a break loop was entered).  Only a form being compiled should
     look in a special place for macro definitions, for example.

  2. It should distinguish between different invocations of compile-file,
     as might arise if one compile-file entered a break loop and the
     user started another compile-file while the first was still active.

We might be able to standardize on minimum requirements for a mechanism for
"reduced side-effect compilation".  If the requirements are reasonable, we
might also be able to standardize on that mechanism being used by default,
with options provided to select other (nonstandard) techniques, as has been
suggested.
-------

∂19-Jan-86  1537	pyramid!bein@sri-unix 	floating point question    
Received: from SRI-UNIX.ARPA by SU-AI.ARPA with TCP; 19 Jan 86  15:37:14 PST
Received: by sri-unix.ARPA (4.12/4.16)
	id AA02136; Sun, 19 Jan 86 15:34:41 pst
Received: by pyramid (4.12/3.14)
	id AA20488; Sun, 19 Jan 86 15:10:53 pst
Date: 19 Jan 1986 14:55 PST
From: David Bein <pyramid!bein@sri-unix>
Subject: floating point question
To: fahlman@cmu-cs-spice.ARPA
Cc: common-lisp@su-ai.ARPA
Message-Id: <506559328/bein@pyramid>

Scott:

  I am wondering about the following bizarre character of
the Common Lisp treatment of floats and ratios when doing
comparisons, specifically = ..

  Suppose that you have X and Y where x is a SINGLE-FLOAT and
Y is a RATIO. Also suppose that X is 0.0. Mathematically speaking
no ratio is 0. So, according to rules of floating point contagion,
you are supposed to convert Y to be a SINGLE-FLOAT which may result
in a SINGLE-FLOAT == 0.0 due to rounding all of which results in
notions like floating point 0.0 equals a non-zero ratio
due to conversion. If I take another approach for = and test
that the float is indeed 0.0 and thus conclude that no ratio
(by rules of ratio canonicalization) is 0, then I end up with
anomalies like (= X Y) != (= X (FLOAT Y X)) which does seem
strange, but from a mathematical point of view, (= X Y)
in this case should be FALSE. What do you think?

  Please pardon me if this question has been asked and/or resolved
in some previous mail.

--David

∂19-Jan-86  1559	RPG  
 ∂19-Jan-86  1335	unido!uklirb!przy@seismo.CSS.GOV   
Received: from SEISMO.CSS.GOV by SU-AI.ARPA with TCP; 19 Jan 86  13:35:37 PST
Received: from unido.UUCP by seismo.CSS.GOV with UUCP; Sun, 19 Jan 86 16:28:24 EST
Received: by unido.uucp with uucp; Sun, 19 Jan 86 22:14:23 -0100
Received: by uklirb.UUCP (4.12/4.7)
	id AA02054; Sun, 19 Jan 86 21:58:39 -0100
Date: Sun, 19 Jan 86 21:58:39 -0100
From: unido!uklirb!przy@seismo.CSS.GOV (Gebhard Przyrembel)
Message-Id: 	<8601192058.AA02054@uklirb.UUCP>
To: common-lisp-request@su-ai.arpa
Return-Path: <uklirb!przy> (from unido.uucp)


 Please, add me to your mailing-list.

		Thanks in advance,

			Gebhard



/---------------------------------------------------------\
| e-mail:    przy@uklirb.UUCP             or              |
|            ..!mcvax!unido!uklirb!przy                   |
| Real-Name: Gebhard Przyrembel                           |
|            University Kaiserslautern                    |
|            Departement of Computer Sciene               |
|            D-6750 Kaiserslautern                        |
|            West-Germany                                 |
\---------------------------------------------------------/

(add-dis common)
"unido!uklirb!przy"@seismo.CSS.GOV   

∂19-Jan-86  1706	FAHLMAN@C.CS.CMU.EDU 	floating point question
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 Jan 86  16:58:13 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 19 Jan 86 19:57:28-EST
Date: Sun, 19 Jan 1986  19:57 EST
Message-ID: <FAHLMAN.12176599253.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   David Bein <pyramid!bein@SRI-UNIX.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: floating point question
In-reply-to: Msg of 19 Jan 1986  17:55-EST from David Bein <pyramid!bein at sri-unix>


I'm not sure why you are asking me specifically about this.  Of all the
people on the Common Lisp mailing list, I'm probably the one who cares
the least about the fine points of floating-point roundoff hackery and
related mathematicalia.  But anyway...

It is well known that floating point numbers are mere approximations to
mathematical truth, due to roundoff error.  So I see no paradox here.
No Common Lisp ratio is strictly equal to zero (else it would be reduced
to an integer), but it is quite possible to have one whose closest
approximation in the domain of short-floats is 0.0.  So what?  There are
an infinite number of other examples where, due to roundoff, two arithmetic
expressions that are supposed to lead to identical results in fact
produce slightly different floating point numbers.  No paradox, just the
result of dealing with an approximation.

-- Scott

∂19-Jan-86  1736	Moon@SCRC-STONY-BROOK.ARPA 	floating point question    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 19 Jan 86  17:36:40 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 396264; Sun 19-Jan-86 20:17:28-EST
Date: Sun, 19 Jan 86 20:17 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: floating point question
To: David Bein <pyramid!bein@SRI-UNIX.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <506559328/bein@pyramid>
Message-ID: <860119201711.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

Floating-point arithmetic is never exact, so I don't think it's any
more surprising if (= 0.0 1/123456789123456789123456789123456789)
than if (= 1.0 (+ 1.0 1e-10)).

∂20-Jan-86  0951	BACH@SU-SCORE.ARPA 	Spelling correction 
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 20 Jan 86  09:51:48 PST
Date: Mon 20 Jan 86 09:48:22-PST
From: Rene Bach <BACH@SU-SCORE.ARPA>
Subject: Spelling correction
To: common-lisp@SU-AI.ARPA
Message-ID: <12176783291.16.BACH@SU-SCORE.ARPA>


I am new on this list (please forgive me if this topic has been discussed
already).

It has been our experience that using the spelling correction facilities
provided by Interlisp are very useful to provide nice user interfaces.
It is also my belief that to do flexible symbol matching requires
spelling correction.

My question is: why doesn't CL include a specification for a spelling
correction function. The description of the Interlisp functions could be
used as specification for the I/O. The choice of the algorithm could
be left open.

Regards
Rene Bach
-------

∂20-Jan-86  1023	FAHLMAN@C.CS.CMU.EDU 	Spelling correction    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Jan 86  10:23:08 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 20 Jan 86 13:23:11-EST
Date: Mon, 20 Jan 1986  13:23 EST
Message-ID: <FAHLMAN.12176789605.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Rene Bach <BACH@SU-SCORE.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Spelling correction
In-reply-to: Msg of 20 Jan 1986  12:48-EST from Rene Bach <BACH at SU-SCORE.ARPA>


Common Lisp deliberately specifies very little about the top-level
command loop.  This is so that many "cultures" (styles of dealing with
the machine) can be supported on top of a common language that allows
code packages to be shared.

The overwhelming majority of Common Lisp implementors and users, at
least at the start, come from the Maclisp tradition in which code is
created by the use of some text editor, usually Emacs-like and usually
written in the Lisp itself.  CMU's Hemlock editor is a public-domain
implementation of such a thing.  It is not 100% portable, since it
depends on the host system's screen management, but the majority of
Common Lisp vendors who do not already have a good Emacs implementation
on their machines are importing Hemlock.  Most of these Emacs-like
systems provide the user with an editor top-level mode, in which
expressions are created within the editor and then are passed into the
Lisp for evaluation.  This provides full editing power (including
spelling correction, word abbreviation mode, and the like) plus a buffer
that records the history of the session.  Instead of using a specialized
mechanism for repeating and altering earlier commands, you just grab
what you want from the buffer and fix it up before transmitting it to
the Lisp.

Anyone who is more comfortable with the Interlisp style of structure
editing, DWIM, Masterscope, history, etc., is free to implement this on
top of Common Lisp, and I suspect that at least one manufacturer is
going to follow this route (though I hope they eventually provide a
Hemlock-style interface as well).

One could argue the merits of the two styles, but the point for Common
Lisp is that they can coexist happily and that we don't need to
standardize on either of them.  Portable code lives below this level.

-- Scott

∂20-Jan-86  1052	DCP@SCRC-QUABBIN.ARPA 	Spelling correction   
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 20 Jan 86  10:52:39 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 236886; Mon 20-Jan-86 13:51:40-EST
Date: Mon, 20 Jan 86 13:56 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Spelling correction
To: Rene Bach <BACH@SU-SCORE.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <12176783291.16.BACH@SU-SCORE.ARPA>
Message-ID: <860120135654.9.DCP@NEPONSET.SCRC.Symbolics.COM>

    Date: Mon 20 Jan 86 09:48:22-PST
    From: Rene Bach <BACH@SU-SCORE.ARPA>


    I am new on this list (please forgive me if this topic has been discussed
    already).

    It has been our experience that using the spelling correction facilities
    provided by Interlisp are very useful to provide nice user interfaces.
    It is also my belief that to do flexible symbol matching requires
    spelling correction.

    My question is: why doesn't CL include a specification for a spelling
    correction function. The description of the Interlisp functions could be
    used as specification for the I/O. The choice of the algorithm could
    be left open.

Base my following reaction on never having used Interlisp but only heard
about it and some of its 'features.'

The only 'spelling corrector' I've heard of in Interlisp is a DWIM
facility to change the name of variables out from under you because you
mistyped them.  I don't believe in that kind of programming, since that
will, among other things, hide bugs that will resurface indefinitely
later if you happen to name a variable the same as your previous
misspelling.  Errors should be signalled.  DWIMing is a function of the
application program only (provided CL had an error system to deal with
errors) and is not a function of the system itself.  For example, if I
mistyped
	*BAX*
when I meant
	*BAZ*
I want an error.  Someday I may legally define *BAX*.

[Shift to programming enviroments...]  I also make use of the compiler
to tell me when variables are unknown and declared special (which is the
most common manifestation of my misspellings) and functions being called
that aren't defined.

If there is a spelling corrector of this type, it should be integrated
into the system at the user-interface level, which is probably out of
bounds for CLtL.

∂20-Jan-86  1859	RPG   	the Common-Lisp mailinglist 
 ∂20-Jan-86  1810	enea!kuling!victor@seismo.CSS.GOV 	the Common-Lisp mailinglist   
Received: from SEISMO.CSS.GOV by SU-AI.ARPA with TCP; 20 Jan 86  18:10:32 PST
Return-Path: <enea!kuling!victor>
Received: from enea.UUCP by seismo.CSS.GOV with UUCP; Mon, 20 Jan 86 21:01:29 EST
Received: by enea.UUCP; Tue, 21 Jan 86 02:33:57 +0100 (MET)
Received: by kuling.UUCP; Mon, 20 Jan 86 19:28:15 -0100
Date: Mon, 20 Jan 86 19:28:15 -0100
From: enea!kuling!victor@seismo.CSS.GOV (Bjorn Victor)
Message-Id: <8601201828.AA11512@kuling.UUCP>
To: "common-lisp-request@su-ai"@seismo.CSS.GOV
Cc: victor@seismo.CSS.GOV
Subject: the Common-Lisp mailinglist

I'd be happy to join the mailinglist.   I use and maintain Hedrick's
implementation on TOPS-20 (have two 2060's), but we are not on any net
(yet), so I'll use this address until we get on it.

If it's OK with you, I'll forward articles of special interest to my
colleagues here at the department.

--Bjorn Victor			UUCP: {mcvax,seismo}!enea!kuling!victor
Computing Science Dept/UPMAIL	ARPA: enea!kuling!victor@SEISMO.CSS.GOV
Uppsala University, PO Box 2059
S-750 02  UPPSALA, SWEDEN

(add-dis common)
"enea!kuling!victor"@SEISMO.CSS.GOV

∂21-Jan-86  0836	gls@THINK-AQUINAS.ARPA 	Spelling correction  
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 21 Jan 86  08:36:20 PST
Received: from yon by GODOT.THINK.COM via CHAOS; Tue, 21 Jan 86 11:36:09 est
Date: Tue, 21 Jan 86 11:36 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Spelling correction
To: DCP@SCRC-QUABBIN.ARPA, BACH@SU-SCORE.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <860120135654.9.DCP@NEPONSET.SCRC.Symbolics.COM>
Message-Id: <860121113658.6.GLS@THINK-YON.ARPA>

    Date: Mon, 20 Jan 86 13:56 EST
    From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>

	Date: Mon 20 Jan 86 09:48:22-PST
	From: Rene Bach <BACH@SU-SCORE.ARPA>

	...

	My question is: why doesn't CL include a specification for a spelling
	correction function. The description of the Interlisp functions could be
	used as specification for the I/O. The choice of the algorithm could
	be left open.

    Base my following reaction on never having used Interlisp but only heard
    about it and some of its 'features.'

    The only 'spelling corrector' I've heard of in Interlisp is a DWIM
    facility to change the name of variables out from under you because you
    mistyped them.

Let me observe that there are several distinct things that may be desired:
(1) DETECTION of spelling errors
(2) CORRECTION of spelling errors.
(2) PREVENTION of spelling errors.
The correction process may proceed in different ways depending on how the
error was detected.  In some cases it is easier to prevent the error in the
first place.

The most general way in which spelling errors are "detected" is that a compiler
warning or interpreter error is issued, and maybe you get a debugging breakpoint.
This is not always the easiest way to correct the error.

The Symbolics implementation handles undefined variables and functions at top level
in a more useful way.  First of all, it looks around in other packages to see
whether a different symbol of the same name has the appropriate definition; if so,
it offers to make the substitution.  This is a kind of spelling correction (the
package name having been "misspelled").  Failing that, it prints a warning and
offers the opportunity to type a rubout or other input editor command rather than
having to go through the heavy-duty debugger.

Here at TMC we have an additional hack that allows the <complete> key to operate in
nearly all contexts, including the top level.  Frequently I need only type
R E N <complete> to get "RENAME-WITHIN-NEW-DEFINITION-MAYBE" on the screen.
This is spelling correction before the fact rather than after.

It would be easy, in a similar manner, to make <complete> (or Meta-$) examine the
previous word and apply a spelling-correction algorithm to it.  This is explicit
correction rather than implicit.

So there are many styles for dealing with the spelling problem.  I think
it would be premature to standardize on any one.

--Guy

∂21-Jan-86  1039	SCHUMACHER@HP-HULK  
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 21 Jan 86  10:38:51 PST
Received: from HP-HULK by hplabs.ARPA ; Tue, 21 Jan 86 10:37:24 pst
Date: Tue 21 Jan 86 10:37:59-PST
From: SCHUMACHER%HP-HULK@HPLABS
To: common-lisp@su-ai.ARPA


-------

∂22-Jan-86  1324	DDYER@SCRC-QUABBIN.ARPA 	Spelling correction 
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 22 Jan 86  13:24:41 PST
Received: from WHITE.SWW.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 237773; Wed 22-Jan-86 16:23:02-EST
Received: from PURPLE.SWW.Symbolics.COM by WHITE.SWW.Symbolics.COM via CHAOS with CHAOS-MAIL id 168110; Wed 22-Jan-86 13:24:03-PST
Date: Wed, 22 Jan 86 13:26 PST
From: DDYER@SCRC-RIVERSIDE.ARPA
Subject: Spelling correction
To: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>,
    Rene Bach <BACH@SU-SCORE.ARPA>, common-lisp@SU-AI.ARPA
Fcc: W:>ddyer>mail.sent
In-Reply-To: <860120135654.9.DCP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <860122132621.2.DDYER@PURPLE.SWW.Symbolics.COM>
Fonts: CPTFONT, CPTFONTB, CPTFONTI

    Date: Mon, 20 Jan 86 13:56 EST
    From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>

	Date: Mon 20 Jan 86 09:48:22-PST
	From: Rene Bach <BACH@SU-SCORE.ARPA>


	I am new on this list (please forgive me if this topic has been discussed
	already).

	It has been our experience that using the spelling correction facilities
	provided by Interlisp are very useful to provide nice user interfaces.
	It is also my belief that to do flexible symbol matching requires
	spelling correction.

	My question is: why doesn't CL include a specification for a spelling
	correction function. The description of the Interlisp functions could be
	used as specification for the I/O. The choice of the algorithm could
	be left open.

    Base my following reaction on never having used Interlisp but only heard
    about it and some of its 'features.'

You are somewhat under-informed about the Interlisp spelling corrector.  Here's
the straight scoop from one who knows.

Underlying everything, Interlisp has a function called FIXSPELL which has
lots of optional arguments, but which essentially checks a "misspelled" 
symbol against a specified list of possible corrections.  The parameters
control how FIXSPELL responds to spelling errors or various degrees of 
severity.  Depending on the various severity thresholds and the response
specification, FIXSPELL can return a "correction" without comment, with
a comment/warning message, with a Y-OR-N-P type response, or with an
error.

Interlisp has several mechanisms for automatically maintaining "spelling lists";
for example, it keeps a lists of "system" functions "system" variables, 
"user" functions and "user" variables.

DWIM is an entirely separate facility, which among other things, can
invoke FIXSPELL to attempt to find a correction.   This is the use of
the spelling corrector which is most often encountered by the casual
Interlisp user.   Forms you type to a lisp listener are passed to DWIM
if an error occurs, and (various switches permitting) FIXSPELL can be
invoked to find semantically reasonable corrections.   DWIM (and
therefore FIXSPELL) are also invoked by the compiler.   Due to the
form-based nature of Interlisp's environment, changes made by DWIM
are automatically propagated to the sources.  ε2All ε0changes made
by DWIM are undoable.


Summary:  FIXSPELL is a utility which we could use.  DWIM is a completely
separate facility, which is controversial even within the Interlisp community.
Most of use have a love/hate relationship with it, but few choose to turn it
off.

----

    The only 'spelling corrector' I've heard of in Interlisp is a DWIM
    facility to change the name of variables out from under you because you
    mistyped them.  I don't believe in that kind of programming, since that
    will, among other things, hide bugs that will resurface indefinitely
    later if you happen to name a variable the same as your previous
    misspelling.

This is a misconception; DWIM (as used by the compiler) actually fixes
the sources, so the bug won't resurface later.  The choice to fix
the sources "silently" "noisily" or "with confirmation only" is
available to the user.   The really important thing you apparently
didn't know is that when DWIM fixes something itε2 staysε0 fixed; So 
today's Error-fixed-by-dwim doesn't become tomorrow's non-bug
because *BAX* is now defined.

For example, if in a lispm compilation you get the warning "Function foo-bax-mumble is undefined",
DWIM might instead have run an interaction such as

	Function FOO-BAX-MUMBLE is undefined.  Do you mean FOO-BAR-MUMBLE? 

and if you respond Y, it fixes the source for you once and for all.  I always
found this extremely user-friendly, since DWIM was almost always right and 
since it saved me the trouble of doing another edit-compile cycle.


∂22-Jan-86  1738	BACH@SU-SCORE.ARPA 	Re: Spelling correction  
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 22 Jan 86  17:37:02 PST
Date: Wed 22 Jan 86 17:16:26-PST
From: Rene Bach <BACH@SU-SCORE.ARPA>
Subject: Re: Spelling correction
To: DDYER@SCRC-RIVERSIDE.ARPA
cc: DCP@SCRC-QUABBIN.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <860122132621.2.DDYER@PURPLE.SWW.Symbolics.COM>
Message-ID: <12177389147.33.BACH@SU-SCORE.ARPA>

Thank you. I have been waiting until the first burst of comments subsided
before coming back. Yes. what I really had in mind were the equivalent
of FIXSPELL and MISSPELLED? (see interlisp manual, in the 1978 edition
it's page 17.18, for a specification of those functions. I'll type in
the specs if asked to do so.)

And I am not a LISP developer, but I am a user. I use LISP to write
expert systems and believe that Common Lisp should be a helpful tool
for the researchers in the different areas of AI. Thus many of the
comments about DWIM and code development issues were somewhat off.

I believe that FIXSPELL and MISSPELLED? functions have a wide range of
utility and deserve to be included in C-L. Think of them as being
smart equivalent of the MEMBER function.
-------

∂22-Jan-86  2048	shebs%utah-orion@utah-cs.arpa 	Re: Spelling correction 
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 22 Jan 86  20:48:31 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
	id AA10541; Wed, 22 Jan 86 21:49:10 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
	id AA20265; Wed, 22 Jan 86 21:49:06 MST
Date: Wed, 22 Jan 86 21:49:06 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8601230449.AA20265@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Re: Spelling correction

I can't get really enthused about spelling correction, even if it's
just a pair of relatively innocuous functions.  Common Lisp is already
pretty fat ("pleasingly plump"?), and spelling correction really
falls into a gray area, if one applies the agreed-upon inclusion criteria.
Yellow pages seems appropriate, unless someone wants to argue that
implementors can make it significantly better by doing implementation
dependent hacks?

							stan

∂22-Jan-86  2228	shebs%utah-orion@utah-cs.arpa 	Re: Spelling correction 
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 22 Jan 86  20:48:31 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2)
	id AA10541; Wed, 22 Jan 86 21:49:10 MST
Received: by utah-orion.ARPA (5.5/4.40.2)
	id AA20265; Wed, 22 Jan 86 21:49:06 MST
Date: Wed, 22 Jan 86 21:49:06 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8601230449.AA20265@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Re: Spelling correction

I can't get really enthused about spelling correction, even if it's
just a pair of relatively innocuous functions.  Common Lisp is already
pretty fat ("pleasingly plump"?), and spelling correction really
falls into a gray area, if one applies the agreed-upon inclusion criteria.
Yellow pages seems appropriate, unless someone wants to argue that
implementors can make it significantly better by doing implementation
dependent hacks?

							stan

∂23-Jan-86  0657	FAHLMAN@C.CS.CMU.EDU 	Spelling correction    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Jan 86  06:57:39 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 23 Jan 86 09:58:31-EST
Date: Thu, 23 Jan 1986  09:58 EST
Message-ID: <FAHLMAN.12177538793.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Rene Bach <BACH@SU-SCORE.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: Spelling correction
In-reply-to: Msg of 22 Jan 1986  20:16-EST from Rene Bach <BACH at SU-SCORE.ARPA>


I agree that a set of simple spelling error detection/correction
facilities would make a useful addition to the Yellow pages.  If people
eventually decide that these things are universally used, we could move
them into the standard language at that time.

We already have such a package built into Hemlock, though I'm not sure
how easy it would be to extract it.  

I have a hunch that a list of legal words is not the best possible
interface to this thing.  You want to have a spelling dictionary object
type that can be built from a set of words, and that can be modified
later.  Probably once this reaches a certain size you want this object
to be a hash-table or balanced binary tree or something like that, and
not a simple list.  The spell checking and correcting functions would
operate on one of these objects, and not on the raw word-list.

-- Scott

∂23-Jan-86  1333	gls@THINK-AQUINAS.ARPA 	[vrotney@isi-vaxa.ARPA: Forwarded]  
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 23 Jan 86  13:33:20 PST
Received: from quentin by GODOT.THINK.COM via CHAOS; Thu, 23 Jan 86 16:33:01 est
Date: Thu, 23 Jan 86 16:33 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: [vrotney@isi-vaxa.ARPA: Forwarded]
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <860123163356.1.GLS@THINK-QUENTIN.ARPA>

Can anyone help with the following problem?
--Guy
    
    Date: Wed, 22 Jan 86 18:00:58 pst
    From: vrotney@isi-vaxa.ARPA (Bill Vrotney)
    
    Guy Steele,
    
    I am implementing our FSD on the HP 9000 machines
    in Common Lisp. I need a public domain loop macro
    that is roughly equivalent to the Zetalisp version,
    but will compile under Common Lisp. I copied over
    M.I.T.'s loop macro, but Common Lisp doesn't seem
    to have the "*features*" that it needs. Do you
    know of any such public domian loop macro designed
    for Common Lisp?
    
    Bill Vrotney
    USC/Information Sciences Institute
    vrotney@ISI-VAXA.ARPA

∂23-Jan-86  1847	mips!escargot.earl@glacier 	time of evaluation    
Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 23 Jan 86  18:47:28 PST
Received: by glacier with Sendmail; Thu, 23 Jan 86 18:46:49 pst
Received: from escargot.UUCP (escargot.ARPA) by mips.UUCP (4.12/4.7)
	id AA29948; Thu, 23 Jan 86 13:57:02 pst
Received: by escargot.UUCP (4.12/4.7)
	id AA23779; Thu, 23 Jan 86 13:56:39 pst
Date: Thu, 23 Jan 86 13:56:39 pst
From: mips!escargot.earl@glacier (Earl Killian)
Message-Id: <8601232156.AA23779@escargot.UUCP>
To: DLW@SCRC-QUABBIN.ARPA
Cc: COMMON-LISP@SU-AI.ARPA
In-Reply-To: Daniel L. Weinreb's message of Fri, 17 Jan 86 19:28 EST
Subject: time of evaluation

    Date: Fri, 17 Jan 86 19:28 EST
    From: Daniel L. Weinreb <glacier!DLW@SCRC-QUABBIN.ARPA>
    ...
    (1) The files being compiled see an empty Lisp environment when the
    compilation starts.  The Lisp environment that called compile-file is
    untouched.
    ...
    Personally, I would find style (1) to be painful and inconvenient even
    if my machine could switch to a new Lisp environment in two nanoseconds,
    because I want the compilation to see the state in my Lisp environment.
    Think of people who define their favorite macros in their init files,
    who would then have to create some sort of "compiler init file" to set
    up the compilation environment for all of their programs, as a simple
    example.

It is annoying to start out in a empty environment, but it is the only
way you'll get people to write portable stuff.  If compiling a file
something implicitly depends on their favorite personal macros, then
nobody else can use it.  On the other hand, all that's required to
live with the empty compiler environment is (REQUIRE DLW-DEFINITIONS).
You just get in the habit of putting that in every file you create...

∂23-Jan-86  2124	Moon@SCRC-STONY-BROOK.ARPA 	[vrotney@isi-vaxa.ARPA: Forwarded]   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 Jan 86  21:23:48 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 400276; Fri 24-Jan-86 00:23:22-EST
Date: Fri, 24 Jan 86 00:23 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: [vrotney@isi-vaxa.ARPA: Forwarded]
To: common-lisp@SU-AI.ARPA
In-Reply-To: <860123163356.1.GLS@THINK-QUENTIN.ARPA>
Message-ID: <860124002342.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 23 Jan 86 16:33 EST
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>

    Can anyone help with the following problem?
    
	Date: Wed, 22 Jan 86 18:00:58 pst
	From: vrotney@isi-vaxa.ARPA (Bill Vrotney)
        I need a public domain loop macro
	that is roughly equivalent to the Zetalisp version,
	but will compile under Common Lisp.

I don't have one, but if someone wants to write one I may be
able to offer some guidance.  I'd like to see it redesigned,
but perhaps there is enough demand for a simple reimplementation
in Common Lisp of the existing specification.

∂23-Jan-86  2253	GSB@MC.LCS.MIT.EDU 	common-lisp loop    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 23 Jan 86  22:53:22 PST
Date: Fri, 24 Jan 86 01:54:14 EST
From: "Glenn S. Burke" <GSB@MC.LCS.MIT.EDU>
Subject: common-lisp loop
To: common-lisp@SU-AI.ARPA
Message-ID: <[MC.LCS.MIT.EDU].794262.860124.GSB>

A group at DEC in Hudson had one which had been derived from, i think,
the source used in Symbolics release 5.something.  I had been going to
look it over, but never did;  i no longer know where i put the source,
if i ever had it online.  If someone at hudson could get ahold of this
from the natural language group (or linguistics or somesuch) i could
check it to see if it really did correspond to a fairly recent loop.
(They are the group a couple rows of cubicles over from the vaxlisp
people, at least during the summer.  I was over there once but all the
vaxlisp people were out partying or something.)  If not i suppose i
could just sit down with the latest source and do the conversion.

∂24-Jan-86  1258	fateman@dali.berkeley.edu 	comparisons between floats and ratios 
Received: from UCBVAX.BERKELEY.EDU by SU-AI.ARPA with TCP; 24 Jan 86  12:57:59 PST
Received: by ucbvax.berkeley.edu (5.44/1.7)
	id AA26935; Fri, 24 Jan 86 12:56:18 PST
Received: by dali.berkeley.edu (5.44/5.16)
	id AA29507; Fri, 24 Jan 86 12:25:47 PST
Date: Fri, 24 Jan 86 12:25:47 PST
From: fateman@dali.berkeley.edu (Richard Fateman)
Message-Id: <8601242025.AA29507@dali.berkeley.edu>
To: common-lisp@su-ai.arpa
Subject: comparisons between floats and ratios

There is a rule (top of p 194, CLtL) indicating that CL preserves
"as much accuracy as possible" (although not guaranteeing it).
Thus when two numeric values are operated upon, the coercion
is to the larger precision, which tends to preserve more accuracy.

To be consistent with this rule, operations which combine floats of
any precision with ratios should convert floats to ratios, not the
reverse.
Any float (except possibly IEEE NaN and infinity) can be converted to a
ratio without loss of precision. (and Nan=0/0, inf = 1/0 might even be
used).  Of course the rational answer could be re-floated if required.

This would solve the problem of incorrect equality of 0.0 with a
non-zero but small ratio which "underflows".

Now consider comparing the floating point number 0.5 with an integer
sufficiently large as to overflow the exponent range of floats.  The
comparison is "an error", according to CLtL (p 194).  If one is to
ensure correct handling of the large number of numeric data types
in the language specification, I think the comparison should return
the mathematically correct answer.

(Alternatively, one could consider re-building all built-in functions 
for applications like Macsyma.) 

∂24-Jan-86  1618	Cassels@SCRC-STONY-BROOK.ARPA 	comparisons between floats and ratios  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Jan 86  16:18:39 PST
Received: from CUYAHOGA.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 401241; Fri 24-Jan-86 19:18:12-EST
Date: Fri, 24 Jan 86 19:20 EST
From: Robert A. Cassels <Cassels@TENEX.SCRC.Symbolics.COM>
Subject: comparisons between floats and ratios
To: fateman@dali.berkeley.edu, common-lisp@SU-AI.ARPA
In-Reply-To: <8601242025.AA29507@dali.berkeley.edu>
Message-ID: <860124192014.5.CASSELS@CUYAHOGA.SCRC.Symbolics.COM>
Reply-To: Robert A. Cassels <Cassels@SCRC-STONY-BROOK.ARPA>

    Date: Fri, 24 Jan 86 12:25:47 PST
    From: fateman@dali.berkeley.edu (Richard Fateman)

    There is a rule (top of p 194, CLtL) indicating that CL preserves
    "as much accuracy as possible" (although not guaranteeing it).
    Thus when two numeric values are operated upon, the coercion
    is to the larger precision, which tends to preserve more accuracy.

    To be consistent with this rule, operations which combine floats of
    any precision with ratios should convert floats to ratios, not the
    reverse.

By introducing a floating-point number into a computation, you're
introducing a [hopefully] controlled inaccuracy.  CLtL is just trying to
preserve that amount of inaccuracy.

    Any float (except possibly IEEE NaN and infinity) can be converted to a
    ratio without loss of precision. (and Nan=0/0, inf = 1/0 might even be
    used).  Of course the rational answer could be re-floated if required.

    This would solve the problem of incorrect equality of 0.0 with a
    non-zero but small ratio which "underflows".

    Now consider comparing the floating point number 0.5 with an integer
    sufficiently large as to overflow the exponent range of floats.  The
    comparison is "an error", according to CLtL (p 194).  If one is to
    ensure correct handling of the large number of numeric data types
    in the language specification, I think the comparison should return
    the mathematically correct answer.

    (Alternatively, one could consider re-building all built-in functions 
    for applications like Macsyma.) 

You bring up three issues:
 - the coercion rules for mixed-type operations (+, -, *, etc.)
 - the coercion rules for mixed-type comparisons (=, <, etc.)
 - "correct answers" for mixed-type comparisons vs. blowing out 

I believe that although they are related, they are orthogonal.  So I
will discuss them separately.

I don't think that you really want the coercion rules for operations to
prefer rational arithmetic to floating-point.  Consider that (+ x 1)
will leave you with a rational result.  Remember that rational
canonicalization means you can't distinguish a "ratio" 1/1 from an
integer 1.  You'd have to be incredibly compulsive to keep your
computations from consing ratios and taking forever.

The reason we keep floating-point around is to do computations
efficiently.  By introducing a float, you're saying, "I know the answer
might not be exactly correct, but I know what I'm doing -- just give me
an answer, and give it to me fast."  [-: I do know that a lot of people
who use floating-point don't know what they're doing.  But we should
pretend they do. :-]

You might want comparisons to be done rationally, although pretending
that 0.0 is the same as 0 seems foolish to me.  And the efficiency issue
remains, since (< x 1) would most likely cons you a ratio of bigna.

I do agree that you'd like to get answers to any comparison that doesn't
involve NaNs.  But that's possible even with the current CLtL coercion
rules.  In the next release of the Symbolics system, mixed-type
comparisons are done in floating-point ala CLtL, but over- and underflow
are accounted for so that "correct" answers are always given.

∂24-Jan-86  1935	Cassels@SCRC-STONY-BROOK.ARPA 	comparisons between floats and ratios  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Jan 86  16:18:39 PST
Received: from CUYAHOGA.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 401241; Fri 24-Jan-86 19:18:12-EST
Date: Fri, 24 Jan 86 19:20 EST
From: Robert A. Cassels <Cassels@TENEX.SCRC.Symbolics.COM>
Subject: comparisons between floats and ratios
To: fateman@dali.berkeley.edu, common-lisp@SU-AI.ARPA
In-Reply-To: <8601242025.AA29507@dali.berkeley.edu>
Message-ID: <860124192014.5.CASSELS@CUYAHOGA.SCRC.Symbolics.COM>
Reply-To: Robert A. Cassels <Cassels@SCRC-STONY-BROOK.ARPA>

    Date: Fri, 24 Jan 86 12:25:47 PST
    From: fateman@dali.berkeley.edu (Richard Fateman)

    There is a rule (top of p 194, CLtL) indicating that CL preserves
    "as much accuracy as possible" (although not guaranteeing it).
    Thus when two numeric values are operated upon, the coercion
    is to the larger precision, which tends to preserve more accuracy.

    To be consistent with this rule, operations which combine floats of
    any precision with ratios should convert floats to ratios, not the
    reverse.

By introducing a floating-point number into a computation, you're
introducing a [hopefully] controlled inaccuracy.  CLtL is just trying to
preserve that amount of inaccuracy.

    Any float (except possibly IEEE NaN and infinity) can be converted to a
    ratio without loss of precision. (and Nan=0/0, inf = 1/0 might even be
    used).  Of course the rational answer could be re-floated if required.

    This would solve the problem of incorrect equality of 0.0 with a
    non-zero but small ratio which "underflows".

    Now consider comparing the floating point number 0.5 with an integer
    sufficiently large as to overflow the exponent range of floats.  The
    comparison is "an error", according to CLtL (p 194).  If one is to
    ensure correct handling of the large number of numeric data types
    in the language specification, I think the comparison should return
    the mathematically correct answer.

    (Alternatively, one could consider re-building all built-in functions 
    for applications like Macsyma.) 

You bring up three issues:
 - the coercion rules for mixed-type operations (+, -, *, etc.)
 - the coercion rules for mixed-type comparisons (=, <, etc.)
 - "correct answers" for mixed-type comparisons vs. blowing out 

I believe that although they are related, they are orthogonal.  So I
will discuss them separately.

I don't think that you really want the coercion rules for operations to
prefer rational arithmetic to floating-point.  Consider that (+ x 1)
will leave you with a rational result.  Remember that rational
canonicalization means you can't distinguish a "ratio" 1/1 from an
integer 1.  You'd have to be incredibly compulsive to keep your
computations from consing ratios and taking forever.

The reason we keep floating-point around is to do computations
efficiently.  By introducing a float, you're saying, "I know the answer
might not be exactly correct, but I know what I'm doing -- just give me
an answer, and give it to me fast."  [-: I do know that a lot of people
who use floating-point don't know what they're doing.  But we should
pretend they do. :-]

You might want comparisons to be done rationally, although pretending
that 0.0 is the same as 0 seems foolish to me.  And the efficiency issue
remains, since (< x 1) would most likely cons you a ratio of bigna.

I do agree that you'd like to get answers to any comparison that doesn't
involve NaNs.  But that's possible even with the current CLtL coercion
rules.  In the next release of the Symbolics system, mixed-type
comparisons are done in floating-point ala CLtL, but over- and underflow
are accounted for so that "correct" answers are always given.

∂24-Jan-86  1946	FAHLMAN@C.CS.CMU.EDU 	comparisons between floats and ratios 
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 24 Jan 86  19:45:54 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 24 Jan 86 22:17:03-EST
Date: Fri, 24 Jan 1986  21:41 EST
Message-ID: <FAHLMAN.12177928890.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: comparisons between floats and ratios
In-reply-to: Msg of 24 Jan 1986  19:20-EST from Robert A. Cassels <Cassels at TENEX.SCRC.Symbolics.COM>


The phrase that Fateman spotted on page 194 occurs in the middle of a
discussion of FLOATING-POINT contagion rules.  I think there is no
suggestion, explicit or implicit, that as things currently stand this
rule is meant to cover other kinds of numbers.

Of course, it is legitimate to propose that we consider extending the
rule in this way.  After thinking about it a bit, I agree with Cassels
on this.  Coercing a float/rational operation to produce a rational is
certainly going to lead to a lot of needless inefficiency and confusion,
just to get rid of a paradox that most of us don't view as being
paradoxical at all.  And it just doesn't seem reasonable to me -- it's a
bit like trying to restore the number's virginity.

-- Scott

∂24-Jan-86  2101	fateman@dali.berkeley.edu 	Re:  comparisons between floats and ratios 
Received: from UCBVAX.BERKELEY.EDU by SU-AI.ARPA with TCP; 24 Jan 86  21:00:46 PST
Received: by ucbvax.berkeley.edu (5.44/1.8)
	id AA04759; Fri, 24 Jan 86 21:00:59 PST
Received: by dali.berkeley.edu (5.44/5.16)
	id AA05647; Fri, 24 Jan 86 21:00:53 PST
Date: Fri, 24 Jan 86 21:00:53 PST
From: fateman@dali.berkeley.edu (Richard Fateman)
Message-Id: <8601250500.AA05647@dali.berkeley.edu>
To: Fahlman@c.cs.cmu.edu, common-lisp@su-ai.arpa
Subject: Re:  comparisons between floats and ratios

Subject: Re:  comparisons between floats and ratios

I remain unconvinced, and a private note from Cassels also didn't
help. (My mailing system was unable to send to Cassels individually,
	  so here is a simplified response )
consider (/ (expt 10 68) 1.0E38) .
The numerator overflows when you convert to floating point.
The quotient is representable. I think that CL should err on the
side of slow&correct.

While Cassel's solution to comparisons, by looking at overflows should be ok,
it won't solve the above problem.

Anyone who writes (+ x 1) when he means (+ x 1.0) can be warned or should
pay the cost. Anyone who wants to AVOID conversions to mathematically
reliable answers can easily insist on sloppy floats. 

∂26-Jan-86  1324	Moon@SCRC-STONY-BROOK.ARPA 	Re:  comparisons between floats and ratios
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Jan 86  13:24:45 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 401792; Sun 26-Jan-86 16:23:56-EST
Date: Sun, 26 Jan 86 16:24 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re:  comparisons between floats and ratios
To: Richard Fateman <fateman@dali.berkeley.edu>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8601250500.AA05647@dali.berkeley.edu>
Message-ID: <860126162435.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 24 Jan 86 21:00:53 PST
    From: fateman@dali.berkeley.edu (Richard Fateman)

    I remain unconvinced, and a private note from Cassels also didn't
    help. (My mailing system was unable to send to Cassels individually,
	      so here is a simplified response )
    consider (/ (expt 10 68) 1.0E38) .
    The numerator overflows when you convert to floating point.
    The quotient is representable. I think that CL should err on the
    side of slow&correct.

How is this example different from (/ (* 1.0e34 1.0e34) 1.0E38) ?

If you want to campaign against the widespread misimpression that floating
point is foolproof way to do numerical calculations, that's a fine thing, but
I think this is the wrong mailing list.

∂26-Jan-86  1413	fateman@dali.berkeley.edu 	more boring-to-most-people floating point stuff 
Received: from UCBVAX.BERKELEY.EDU by SU-AI.ARPA with TCP; 26 Jan 86  14:13:22 PST
Received: by ucbvax.berkeley.edu (5.44/1.8)
	id AA01884; Sun, 26 Jan 86 14:13:36 PST
Received: by dali.berkeley.edu (5.44/5.16)
	id AA19482; Sun, 26 Jan 86 14:13:29 PST
Date: Sun, 26 Jan 86 14:13:29 PST
From: fateman@dali.berkeley.edu (Richard Fateman)
Message-Id: <8601262213.AA19482@dali.berkeley.edu>
To: Moon@scrc-stony-brook.arpa
Subject: more boring-to-most-people floating point stuff
Cc: common-lisp@su-ai.arpa

The example  (/ (expt 10 68) 1.0e38) is illustrating
( <operator> <number-type-1> <number-type-2> )  whereas
(/ (* 1.0e34 1.0e34) 1.0e38) is illustrating (recursively)
(<operator> <number-type-1> <number-type-1>) .

Only when you combine two number types, one majorizing the other,
do you face this issue. The intent when combining different precisions
(and ranges) within floats is clear.  You coerce to the longer precision
because it is likely to give you the right answer. Not the fastest.
A reasonable extension of this is if you mix floats with even longer
precision numbers (i.e., rational), you convert to rational, because it
gives you the right answer, not the fastest.

You can, of course, promote the notion that "anything goes" as soon as exact
and approximate numeric types are mixed, or claim that it would be too
costly to do the right thing. 
 To say this is the wrong forum for this is to
appear at odds with the space devoted to this
and other numeric data types in the language specification.

∂26-Jan-86  1920	GJC@MC.LCS.MIT.EDU 	precision vs more information 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 26 Jan 86  19:20:01 PST
Date: Sun, 26 Jan 86 22:20:54 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject:  precision vs more information
To: fateman@DALI.BERKELEY.EDU
cc: common-lisp@SU-AI.ARPA, Moon@SCRC-STONY-BROOK.ARPA
In-reply-to: Msg of Sun 26 Jan 86 14:13:29 PST from fateman at dali.berkeley.edu (Richard Fateman)
Message-ID: <[MC.LCS.MIT.EDU].796884.860126.GJC>

If you go from a floating point number to a ratio you lose information,
the information that the number is an approximation. Exactly how
much of an approximation is hard to tell of course because it depends
on the computational history of the quantity. But the fact that it is
a floating point number can be dangerous information to loose so easily.
This about this:

(defun s (t)
  (* 1/2 g (↑ t 2)))

The 1/2 has been introduced do to a process of symbolic integration.
Why should it affect the form of the answer to a formula?
Returning a floating point number tells you that the result might
not be the right answer. But with rational arithmetic you can be
sure of getting simply meaningful mathematic results from your
formuli.


∂26-Jan-86  1939	KSH@MC.LCS.MIT.EDU  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 26 Jan 86  19:38:58 PST
Date: Sun, 26 Jan 86 22:39:53 EST
From: Kjeld Hvatum <KSH@MC.LCS.MIT.EDU>
To: common-lisp@SU-AI.ARPA
Message-ID: <[MC.LCS.MIT.EDU].796915.860126.KSH>

 From: Steve Bacher (CSDL)
 To: Robert Elton Maas
 Subject: Compiler side effects lossage
 
    It sounds like your compiler used the C... properties exclusively,
    refusing to use normal propertis {sic} even when the C... property
    didn't exist.
 
 I can't speak for Charles Hedrick or his compiler, but I do know that
 this problem can definitely occur even when the property masking you
 describe is in use.  Consider the case of a DEFMACRO which references
 a function defined via DEFUN (or DEFMACRO, etc.) in the same file.
 If the compiler dutifully assigns a CMACRO or CFUNCTION property for
 the function in question, then invokes MACROEXPAND on the macro
 definition associated with the first DEFMACRO, you should expect to
 run into trouble if your macroexpander uses the standard evaluator,
 since that one, as described, WILL NOT find compiler-generated defs
 like CFUNCTION.  Now, unless you want to rewrite the evaluator for
 the compiler to process Cfrobs, you can't get around this.
 The user will simply have to wrap an (eval-when (compile ...))
 around the ancillary DEFstuff - and this implies that the way the
 compiler treats DEFUN, DEFMACRO, etc. *cannot* be desribed as a case
 of an implicit (eval-when (compile)).  Which means that I must take
 issue with the earlier statement of Rob MacLachlan's that there's no
 way to override the implicit eval-whenitude of DEFUN et al.
 
 Lest you believe that this is all idle speculation and windbagging,
 let me point out that this is essentially how I have structured my
 LISP compiler, and this problem does come up despite the best of
 intentions.  (Another screw case is defining SETF methods.)
 
       - Steve Bacher
 


∂27-Jan-86  0543	GZ%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	comparisons between floats and ratios
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 Jan 86  05:43:29 PST
Date: Mon 27 Jan 86 08:42:53-EST
From: "Gail Zacharias" <GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: comparisons between floats and ratios
To: common-lisp@SU-AI.ARPA
Message-ID: <12178573608.22.GZ@OZ.AI.MIT.EDU>

Is (> a-rational a-float) supposed to err out when (float a-rational a-float)
would overflow?  If so, there should at least be some way to tell ahead of time
if that's going to happen, for people who want to write a more careful
comparison routine.  The only way I can figure out of doing this now is
(> a-ratio (rational most-positive-xx-float)).  Consing up a bignum
representation of the largest float seems like a high price to pay for being
careful.

Since most floating point implementations can (internally at least) represent
infinity, it shouldn't cause a great loss of efficiency to require that this
case return T. 

A not-entirely-unrelated question:  What kind of rounding is FLOAT supposed
to do?
-------

∂27-Jan-86  0644	RAM@C.CS.CMU.EDU 	Compiler side effects lossage   
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 Jan 86  06:44:30 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 27 Jan 86 09:44:46-EST
Date: Mon, 27 Jan 1986  09:44 EST
Message-ID: <RAM.12178584864.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: Compiler side effects lossage
Cc:   Kjeld Hvatum <KSH@MC.LCS.MIT.EDU>
In-reply-to: Msg of 26 Jan 1986  22:39-EST from Kjeld Hvatum <KSH at MC.LCS.MIT.EDU>


    From: Steve Bacher (CSDL)
    To: Robert Elton Maas
    Subject: Compiler side effects lossage

    The user will simply have to wrap an (eval-when (compile ...))
    around the ancillary DEFstuff - and this implies that the way the
    compiler treats DEFUN, DEFMACRO, etc. *cannot* be desribed as a case
    of an implicit (eval-when (compile)).  Which means that I must take
    issue with the earlier statement of Rob MacLachlan's that there's no
    way to override the implicit eval-whenitude of DEFUN et al.

Actually this is exactly my point.  I was arguing that such forms
should not be considered to have an implicit (eval-when (compile)); if
they really did there would be no way to inhibit the compile-time
evaluation.  This is more a statement about the language which should
be used in the definition than it is about the semantics of Common Lisp.

  Rob

∂27-Jan-86  0737	FAHLMAN@C.CS.CMU.EDU 	comparisons between floats and ratios 
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 Jan 86  07:37:10 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 27 Jan 86 10:37:58-EST
Date: Mon, 27 Jan 1986  10:37 EST
Message-ID: <FAHLMAN.12178594550.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Gail Zacharias <GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Cc:   common-lisp@SU-AI.ARPA
Subject: comparisons between floats and ratios
In-reply-to: Msg of 27 Jan 1986  08:42-EST from Gail Zacharias <GZ%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU>


    Is (> a-rational a-float) supposed to err out when (float a-rational a-float)
    would overflow?  If so, there should at least be some way to tell ahead of time
    if that's going to happen, for people who want to write a more careful
    comparison routine.

Sounds like a job for the error system (a proposal for which KMP is
supposed to have ready soon).  Better to intercept this rare overflow
problem when it occurs, and when you actually care, than to slow down
the universe by trying to prevent it.

∂27-Jan-86  0742	FAHLMAN@C.CS.CMU.EDU 	comparisons between floats and ratios 
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 Jan 86  07:41:35 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 27 Jan 86 10:42:18-EST
Date: Mon, 27 Jan 1986  10:42 EST
Message-ID: <FAHLMAN.12178595334.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Gail Zacharias <GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Cc:   common-lisp@SU-AI.ARPA
Subject: comparisons between floats and ratios
In-reply-to: Msg of 27 Jan 1986  08:42-EST from Gail Zacharias <GZ%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU>


    A not-entirely-unrelated question:  What kind of rounding is FLOAT supposed
    to do?

I think that the GOAL is to produce the closest approximation to the
ratio that is possible in a given floating-point format.  That's what
implementors should shoot for.  Whether it makes sense to REQUIRE this
in the very last bit is less clear.  I don't think I've ever seen a
floating-point package that got this right all the time.

-- Scott

∂27-Jan-86  0812	DCP@SCRC-VALLECITO.ARPA 	comparisons between floats and ratios   
Received: from SCRC-VALLECITO.ARPA by SU-AI.ARPA with TCP; 27 Jan 86  08:11:03 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-VALLECITO.ARPA via CHAOS with CHAOS-MAIL id 79954; Mon 27-Jan-86 11:10:26-EST
Date: Mon, 27 Jan 86 11:16 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: comparisons between floats and ratios
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
    Gail Zacharias <GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12178594550.BABYL@C.CS.CMU.EDU>
Message-ID: <860127111609.5.DCP@NEPONSET.SCRC.Symbolics.COM>

    Date: Mon, 27 Jan 1986  10:37 EST
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>


	Is (> a-rational a-float) supposed to err out when (float a-rational a-float)
	would overflow?  If so, there should at least be some way to tell ahead of time
	if that's going to happen, for people who want to write a more careful
	comparison routine.

    Sounds like a job for the error system (a proposal for which KMP is
    supposed to have ready soon).  Better to intercept this rare overflow
    problem when it occurs, and when you actually care, than to slow down
    the universe by trying to prevent it.

There are two places to put the condition-case/bind (or whatever the KMP
equivalent is).  One is in the application program, the other is in the
system code that does the comparision.

Putting it in the application program will look like Common Lisp has a
wart that numeric comparisons need special help sometimes.

Putting it in the system code would probably slow it down as much as
doing the check.  The system code would probably look like (already
checked that both are positive):
	
	(block nil
	  (> (condition-case ()
		  (float a-rational a-float)
		(<overflow> (return t))
		(<underflow> (return nil)))
	     a-float))

This points up a problem with putting it in the application program: If
overflow is signalled, how does the application figure out what the
intent was?  It might be hard to figure out that (float a-rational a-float),
which is where the error happened, was being used for >.

∂27-Jan-86  1153	fateman@dali.berkeley.edu 	precision, accuracy, and floating conversion (GJC's comment)   
Received: from UCBVAX.BERKELEY.EDU by SU-AI.ARPA with TCP; 27 Jan 86  11:52:52 PST
Received: by ucbvax.berkeley.edu (5.44/1.8)
	id AA19106; Mon, 27 Jan 86 11:52:45 PST
Received: by dali.berkeley.edu (5.44/5.16)
	id AA06514; Mon, 27 Jan 86 11:52:37 PST
Date: Mon, 27 Jan 86 11:52:37 PST
From: fateman@dali.berkeley.edu (Richard Fateman)
Message-Id: <8601271952.AA06514@dali.berkeley.edu>
To: common-lisp@su-ai.arpa
Subject: precision, accuracy, and floating conversion (GJC's comment)


GJC's view that a floating point number x means an interval
[x-epsilon,x+epsilon]  for some unknown epsilon, is not
treated kindly in most of the current thinking about floating
point arithmetic.  To be consistent here, you should also propose
that in combining floating point numbers, the SHORTEST precision
should be used, because that would indicate that the answer is 
particularly uncertain.

As for GJC's example, if I understand it, you want a floating point
number so you can return (the float (* 1/2 ...))  or (* (the float 1/2) ...)


∂27-Jan-86  1417	gls@THINK-AQUINAS.ARPA 	precision, accuracy, and floating conversion (GJC's comment) 
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 27 Jan 86  14:17:22 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 27 Jan 86 17:17:37 est
Date: Mon, 27 Jan 86 17:18 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: precision, accuracy, and floating conversion (GJC's comment)
To: common-lisp@SU-AI.ARPA
In-Reply-To: <8601271952.AA06514@dali.berkeley.edu>
Message-Id: <860127171840.5.GLS@THINK-JEHOSEPHAT.ARPA>

    Date: Mon, 27 Jan 86 11:52:37 PST
    From: fateman@dali.berkeley.edu (Richard Fateman)

    ...

    As for GJC's example, if I understand it, you want a floating point
    number so you can return (the float (* 1/2 ...))  or (* (the float 1/2) ...)

Technical nit: I think these expressions should be
	(float (* 1/2 ...))  or (* (float 1/2) ...)
to be correct.  On the other hand, I think that GJC really wanted was
to write a constant at the bottom of the coercion chain so that the type
of the argument would determine the type of the answer.  Hence
	(coerce (* 1/2 ...) (type-of arg))  or (* (coerce 1/2 (type-of arg)) ...)
would do.

∂27-Jan-86  1449	gls@THINK-AQUINAS.ARPA 	Comparing float to rational    
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 27 Jan 86  14:49:31 PST
Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 27 Jan 86 17:49:27 est
Date: Mon, 27 Jan 86 17:50 EST
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: Comparing float to rational
To: common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
Message-Id: <860127175030.6.GLS@THINK-JEHOSEPHAT.ARPA>

I thinm that Fateman has raised a valid issue that deserves discussion.
Right now the Common Lisp book does seem to specify quite clearly (page
194) that for comparison as well as "combining" of a rational with a
float, the rational shall be converted to a float of the same format.

Evidence on the other side of the question is the remark that for
MAX and MIN, if the largest (resp. smallest) argument is a rational
then the returned result may be a rational even though the argument
is a float.

I think there is a lot to be said for requiring comparison between a
rational and a float always to work and not to overflow.  I think there
is much less to be said in the case of addition, but I am on less solid
ground here.  What is FORTRAN's position on this?  In FORTRAN when an
integer meets a float, the integer gets converted to a float.  I can't
find my copy of the FORTRAN '77 standard just this minute, but I don't
recall anything in the standard requiring the range of a float to be as
large as that of an integer (granted that for an integer to exceed the
range of a float would be considered unusual in that culture).

I also reject the notion that a floating-point number is really an
interval (though I'm not sure GJC implied this directly).  However, I do
think it is reasonable to consider floating-point numbers to be
approximations--at least, once the inexact flag gets set.  (It seems to
me, by the way, that if bits were free it would be more sensible to have
an inexact bit in every value rather than a single global flag; but bits
are not free and the 754 committee was having to sweat as it was to cram
everything into 32 bits.)  One strives for a reasonable economic balance
between accuracy, speed, and ease of understanding.  In the case of
comparisons, it is not too difficult to be completely accurate, and
doing so makes it much easier to understand.  That's as far as I go with
confidence.  The issue for addition or multiplication is not so clear,
because the speed costs are not clear (they can cascade).  This is a
reasonable matter for discussion.
--Guy

∂27-Jan-86  1608	GJC@MC.LCS.MIT.EDU 	precision, accuracy, and floating conversion (GJC's comment)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 Jan 86  16:08:46 PST
Date: Mon, 27 Jan 86 19:09:33 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject:  precision, accuracy, and floating conversion (GJC's comment)
To: fateman@DALI.BERKELEY.EDU
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Mon 27 Jan 86 11:52:37 PST from fateman at dali.berkeley.edu (Richard Fateman)
Message-ID: <[MC.LCS.MIT.EDU].798122.860127.GJC>

Quote RJF:
 "GJC's view that a floating point number x means an interval
  [x-epsilon,x+epsilon]  for some unknown epsilon, is not ..."
Quote GJC:
 "...that is *not* GJC's view"
Quote GJC again (sigh):
 "'nuff said, but what about the PI bit? If the PI bit is set then
  floating point numbers are to be taken as a multiplier of PI. If the E bit
  then as a multiplier of (EXP 1)..."


∂27-Jan-86  1854	ME  	:capitalize in *print-case*   
To:   common-lisp@SU-AI.ARPA
CC:   ME@SU-AI.ARPA    
CLtL says that lowercase letters in print names are always printed in
lowercase, and that *print-case* controls the printing of uppercase.

This implies that with *print-case* set to :CAPITALIZE, the symbol |aBCD|
should be printed as |abcd|.  This is of course not a capitalized word,
and I've seen at least one Common Lisp implementation that prints this
symbol as |Abcd|, thus violating the claim that "lowercase letters are
always printed in lowercase".

So which way should it be with :CAPITALIZE?  Should it really capitalize
or should lowercase letters always be printed in lowercase?

∂27-Jan-86  2050	FAHLMAN@C.CS.CMU.EDU 	:capitalize in *print-case*      
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 Jan 86  20:50:16 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 27 Jan 86 23:50:53-EST
Date: Mon, 27 Jan 1986  23:50 EST
Message-ID: <FAHLMAN.12178738898.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Martin Frost <ME@SU-AI.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: :capitalize in *print-case*   
In-reply-to: Msg of 27 Jan 1986  21:54-EST from Martin Frost <ME at SU-AI.ARPA>


I think that the manual means what it says here: lower-case characters
don't get touched, regardless of the setting of this switch.  The theory
is that most symbol print names end up in all-upper-case internally, and
the *print-case* flags control how you want to see those.  If the user
has taken special trouble to get a lower-case character into a symbol's
print name, we assume that he really wants to see a lower-case character
there.  This is all pretty ugly, but seemed like the thing to do at the
time; it's something of a holdover from the bad old days when the only
way to get a character string was to make it the print-name of a symbol.

-- Scott

∂27-Jan-86  2110	Moon@SCRC-STONY-BROOK.ARPA 	:capitalize in *print-case*     
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 27 Jan 86  21:09:41 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 403054; Tue 28-Jan-86 00:08:06-EST
Date: Tue, 28 Jan 86 00:08 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: :capitalize in *print-case*   
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: Martin Frost <ME@SU-AI.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12178738898.BABYL@C.CS.CMU.EDU>
Message-ID: <860128000857.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 27 Jan 1986  23:50 EST
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    I think that the manual means what it says here: lower-case characters
    don't get touched, regardless of the setting of this switch.

I agree.  Note that the manual clearly states that this switch does not
affect printing when vertical bar syntax is used and that internally
lowercase characters are printed in lowercase with an escape (backslash
or vertical bar).

An implementation where *print-case* changes what appears inside vertical
bars is incorrect.

∂27-Jan-86  2308	fateman@dali.berkeley.edu 	IEEE float co-processors    
Received: from UCBVAX.BERKELEY.EDU by SU-AI.ARPA with TCP; 27 Jan 86  23:08:04 PST
Received: by ucbvax.berkeley.edu (5.44/1.8)
	id AA00269; Mon, 27 Jan 86 23:08:29 PST
Received: by dali.berkeley.edu (5.44/5.16)
	id AA04790; Mon, 27 Jan 86 23:08:19 PST
Date: Mon, 27 Jan 86 23:08:19 PST
From: fateman@dali.berkeley.edu (Richard Fateman)
Message-Id: <8601280708.AA04790@dali.berkeley.edu>
To: common-lisp@su-ai.arpa
Subject: IEEE float co-processors
Cc: fateman@dali.berkeley.edu

in CLtL p193-194 it is stated that an operation combining a short float
with a long results in a long. Presumably if you combine
a short + a single you get a single.  But how precise is the intermediate
arithmetic?
Is it OK to do the arithmetic in "long", or MUST you do the arithmetic 
no more precisely and with no larger range than "single"?

Consider any of a number of existing and proposed
co-processors in which all arithmetic is in fact done in, say, 80 bit units.
A single * short * short then stored to a single
would be done by converting each argument to a long, multiplying
and rounding to single.  This is faster than any other method using most
such chips.

Unfortunately, it might get an answer better than that prescribed by following
CLtL strictly.  Using the method on p 194, one can come up with problems
where intermediate arithmetic done in single might overflow, underflow,
or lose precision disasterously, (or all of these)  before the final,
exactly-single-representable answer is computed. 

I believe the standard should allow the processor to perform all floating
point arithmetic computations in highest precision, and not require
multiple conversions (from short to single to double to long).

The paragraph which allows rearrangement or conversion to the longest
format IN THE EXPRESSION is not flexible enough to quite allow this.

∂28-Jan-86  0331	cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU 	Spelling correction 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 Jan 86  03:31:11 PST
Received: from DUANE.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 28 Jan 86 06:30-EST
Date: Tue, 28 Jan 86 06:29 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: Spelling correction
To: Fahlman@C.CS.CMU.EDU, BACH@SU-SCORE.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12177538793.BABYL@C.CS.CMU.EDU>
Message-ID: <860128062939.3.CFRY@DUANE.AI.MIT.EDU>

Spelling correction would be less necessary in
Common Lisp if the names of certain functions were
easier to spell.
For example:
rplaca
cddadr
nsublis
svref
sqrt
hash-table [the type, includes dash]
readtable  [the type, no dash]
exp, expt
dpb

Fixing the source of common spelling errors would be
more profitable than adding heuristic patches like
spelling correctors.
Since the above examples are set in concrete,
a yellow pages spelling corrector may make it possible
for a part-time hacker [whose voice isn't heard on this mailing list]
to survive in the unnecessarily complex CL environment.

∂28-Jan-86  0452	GJC@MC.LCS.MIT.EDU 	Spelling correction 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 Jan 86  04:52:19 PST
Date: Tue, 28 Jan 86 07:53:17 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject:  Spelling correction
To: cfry@OZ.AI.MIT.EDU
cc: common-lisp@SU-AI.ARPA, BACH@SU-SCORE.ARPA,
    Fahlman@C.CS.CMU.EDU
In-reply-to: Msg of Tue 28 Jan 86 06:29 EST from Christopher Fry <cfry at OZ.AI.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].798777.860128.GJC>

In the LMI system we have a spelling correction function that evolved
as MIDAS (ITS SPELL) -> C (by Pace Willison) -> ZetaLisp (again Pace).
It has only been used for META-$ in Zmacs so far; but maybe somebody
would be willing to CL'ify it and perhaps try hooking it into the
DWIMIFY-PACKAGE hooks that are in various error handlers.

∂28-Jan-86  0545	FAHLMAN@C.CS.CMU.EDU 	Spelling correction    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 28 Jan 86  05:45:12 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 28 Jan 86 08:46:01-EST
Date: Tue, 28 Jan 1986  08:45 EST
Message-ID: <FAHLMAN.12178836317.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: Spelling correction
In-reply-to: Msg of 28 Jan 1986  06:29-EST from Christopher Fry <cfry at OZ.AI.MIT.EDU>


In reply to Christopher Fry <cfry at OZ.AI.MIT.EDU>

Sounds to me like you want a synonym facility rather than spelling
correction.  Then you can spell things however you like.

For Hemlock users, we've now got word abbrev mode in, and people are
experimenting with various versions of Lisp-mode symbol-completion.

-- Scott

∂28-Jan-86  0555	FAHLMAN@C.CS.CMU.EDU 	IEEE float co-processors    
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 28 Jan 86  05:55:45 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 28 Jan 86 08:56:35-EST
Date: Tue, 28 Jan 1986  08:56 EST
Message-ID: <FAHLMAN.12178838237.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   fateman@λdali.berkeley.edu (Richard Fateman)λ
Cc:   common-lisp@SU-AI.ARPA
Subject: IEEE float co-processors
In-reply-to: Msg of 28 Jan 1986  02:08-EST from fateman at dali.berkeley.edu (Richard Fateman)


    I believe the standard should allow the processor to perform all floating
    point arithmetic computations in highest precision, and not require
    multiple conversions (from short to single to double to long).

    The paragraph which allows rearrangement or conversion to the longest
    format IN THE EXPRESSION is not flexible enough to quite allow this.

This sounds like a good proposal, and it wouldn't break anyone's code to
implement it.  I think that all we need is a clarification that says
that a compiler is allowed to do whatever it wants to in handling
the precision of intermediate arithmetic results, as long as any outputs
finally accessible to the user are of the specified type and as long as
precision is at least as good as you would get by doing the obvious
coercions at each step.

My only concern is that the interpreter would probably be stuck with
doing the coercions at each step, and therefore might get a slightly
different (less precise) answer than the compiler would come up with.
Would that bother anyone?  (Not me, but I only look at the first two
digits anyway...)

-- Scott

∂28-Jan-86  0728	csi!meehan%UUCP@YALE.ARPA 	DEFUN inside LET  
Received: from YALE-CHEOPS.ARPA by SU-AI.ARPA with TCP; 28 Jan 86  07:28:07 PST
Received: by yale-cheops.YALE.ARPA; Tue, 28 Jan 86 10:15:42 est
Message-Id: <8601281515.AA16516@yale-cheops.YALE.ARPA>
Received: by CSI-RING; Tue, 28 Jan 86 10:06:27 est
Date: Tue, 28 Jan 86 10:06:27 est
From: James R. Meehan <csi!meehan%UUCP@YALE.ARPA>
To: common-lisp@su-ai.arpa
Subject: DEFUN inside LET

I remember seeing some mail on this topic, but I don't remember
whether there was a consensus.  Is Common Lisp supposed to support
DEFUN inside LET?  I know you can always write
    (SETF (SYMBOL-FUNCTION 'FOO) #'(LAMBDA ...))
to get much the same effect, but that's awkward.

∂28-Jan-86  0748	DCP@SCRC-STONY-BROOK.ARPA 	IEEE float co-processors    
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Jan 86  07:47:08 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 403255; Tue 28-Jan-86 10:39:42-EST
Date: Tue, 28 Jan 86 10:45 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: IEEE float co-processors
To: Richard Fateman <fateman@dali.berkeley.edu>,
    Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, common-lisp@SU-AI.ARPA
In-Reply-To: <8601280708.AA04790@dali.berkeley.edu>,
             <FAHLMAN.12178838237.BABYL@C.CS.CMU.EDU>
Message-ID: <860128104531.4.DCP@NEPONSET.SCRC.Symbolics.COM>

I think I agree with what you two are talking about.  It is critical
that the answer be of the correct type.  We (Symbolics) used to have a
proceed option such that if a single float computation overflowed, the
user could continue using double floats.  We got rid of that after we
realized that was tempting users to believe they had more accuracy than
they actually had.  It all goes back to: If you are going to use
floating point, you better know what you are doing.

∂28-Jan-86  1108	Moon@SCRC-STONY-BROOK.ARPA 	IEEE float co-processors   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Jan 86  11:06:14 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 403454; Tue 28-Jan-86 13:47:43-EST
Date: Tue, 28 Jan 86 13:48 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: IEEE float co-processors
To: Richard Fateman <fateman@dali.berkeley.edu>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8601280708.AA04790@dali.berkeley.edu>
Message-ID: <860128134840.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

Note that on page 16 of the Common Lisp manual, the language is carefully
defined not to require any particular floating-point format or arithmetic.
For the same reasons that the language does not require adherence to the
IEEE floating-point standard (or any other), I think it makes sense for
the language not to require any particular precision for intermediate
results.  Defining floating point more precisely would limit portability
to different pieces of hardware, or else would limit efficiency, and if
efficiency is not a concern, why use floating point at all?

∂28-Jan-86  1250	Cassels@SCRC-STONY-BROOK.ARPA 	Comparing float to rational  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Jan 86  12:49:36 PST
Received: from CUYAHOGA.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 403553; Tue 28-Jan-86 14:54:13-EST
Date: Tue, 28 Jan 86 14:56 EST
From: Robert A. Cassels <Cassels@TENEX.SCRC.Symbolics.COM>
Subject: Comparing float to rational
To: gls@THINK-AQUINAS.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <860127175030.6.GLS@THINK-JEHOSEPHAT.ARPA>
Message-ID: <860128145652.9.CASSELS@CUYAHOGA.SCRC.Symbolics.COM>
Reply-To: Robert A. Cassels <Cassels@SCRC-STONY-BROOK.ARPA>

    Date: Mon, 27 Jan 86 17:50 EST
    From: Guy Steele <gls@THINK-AQUINAS.ARPA>

    I thinm that Fateman has raised a valid issue that deserves discussion.
    Right now the Common Lisp book does seem to specify quite clearly (page
    194) that for comparison as well as "combining" of a rational with a
    float, the rational shall be converted to a float of the same format.

    Evidence on the other side of the question is the remark that for
    MAX and MIN, if the largest (resp. smallest) argument is a rational
    then the returned result may be a rational even though the argument
    is a float.

    I think there is a lot to be said for requiring comparison between a
    rational and a float always to work and not to overflow.  I think there
    is much less to be said in the case of addition, but I am on less solid
    ground here.  What is FORTRAN's position on this?  In FORTRAN when an
    integer meets a float, the integer gets converted to a float.  I can't
    find my copy of the FORTRAN '77 standard just this minute, but I don't
    recall anything in the standard requiring the range of a float to be as
    large as that of an integer (granted that for an integer to exceed the
    range of a float would be considered unusual in that culture).

Right.  In the land of Fortran machines, integers can't overflow when
converted to floats.  But, speaking of Fortran, perhaps overflow
considerations are where the coercion rules came from -- integers don't
overflow when converted to singles, and singles don't overflow when
converted to doubles.  Now that we have bignums, the ground rules are
different and we can rethink the rules.

    I also reject the notion that a floating-point number is really an
    interval (though I'm not sure GJC implied this directly).  However, I do
    think it is reasonable to consider floating-point numbers to be
    approximations--at least, once the inexact flag gets set.  (It seems to
    me, by the way, that if bits were free it would be more sensible to have
    an inexact bit in every value rather than a single global flag; but bits
    are not free and the 754 committee was having to sweat as it was to cram
    everything into 32 bits.)  One strives for a reasonable economic balance
    between accuracy, speed, and ease of understanding.  In the case of
    comparisons, it is not too difficult to be completely accurate, and
    doing so makes it much easier to understand.  That's as far as I go with
    confidence.  The issue for addition or multiplication is not so clear,
    because the speed costs are not clear (they can cascade).  This is a
    reasonable matter for discussion.
    --Guy


∂28-Jan-86  1256	Cassels@SCRC-STONY-BROOK.ARPA 	comparisons between floats and ratios  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Jan 86  12:56:44 PST
Received: from CUYAHOGA.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 403567; Tue 28-Jan-86 15:04:10-EST
Date: Tue, 28 Jan 86 15:06 EST
From: Robert A. Cassels <Cassels@TENEX.SCRC.Symbolics.COM>
Subject: comparisons between floats and ratios
To: DCP@SCRC-QUABBIN.ARPA, Fahlman@C.CS.CMU.EDU,
    GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <860127111609.5.DCP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <860128150652.0.CASSELS@CUYAHOGA.SCRC.Symbolics.COM>
Reply-To: Robert A. Cassels <Cassels@SCRC-STONY-BROOK.ARPA>

    Date: Mon, 27 Jan 86 11:16 EST
    From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>

	Date: Mon, 27 Jan 1986  10:37 EST
	From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>


	    Is (> a-rational a-float) supposed to err out when (float a-rational a-float)
	    would overflow?  If so, there should at least be some way to tell ahead of time
	    if that's going to happen, for people who want to write a more careful
	    comparison routine.

	Sounds like a job for the error system (a proposal for which KMP is
	supposed to have ready soon).  Better to intercept this rare overflow
	problem when it occurs, and when you actually care, than to slow down
	the universe by trying to prevent it.

    There are two places to put the condition-case/bind (or whatever the KMP
    equivalent is).  One is in the application program, the other is in the
    system code that does the comparision.

    Putting it in the application program will look like Common Lisp has a
    wart that numeric comparisons need special help sometimes.

    Putting it in the system code would probably slow it down as much as
    doing the check.  The system code would probably look like (already
    checked that both are positive):
	
	    (block nil
	      (> (condition-case ()
		      (float a-rational a-float)
		    (<overflow> (return t))
		    (<underflow> (return nil)))
		 a-float))

    This points up a problem with putting it in the application program: If
    overflow is signalled, how does the application figure out what the
    intent was?  It might be hard to figure out that (float a-rational a-float),
    which is where the error happened, was being used for >.

Ack!  Even though we have an error system, I didn't consider using it
for this particular application.  I used the IEEE-required ability to
turn off overflow traps:  [simplified for presentation]

(defnumop < ((x float) (y bignum))
  (if (infinite x)  ; + or - infinity
      (minusp x)
      (without-floating-overflow-traps
	(< x (float y x)))))

∂28-Jan-86  1309	Cassels@SCRC-STONY-BROOK.ARPA 	comparisons between floats and ratios  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Jan 86  13:08:50 PST
Received: from CUYAHOGA.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 403573; Tue 28-Jan-86 15:06:29-EST
Date: Tue, 28 Jan 86 15:09 EST
From: Robert A. Cassels <Cassels@TENEX.SCRC.Symbolics.COM>
Subject: comparisons between floats and ratios
To: Fahlman@C.CS.CMU.EDU, GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12178595334.BABYL@C.CS.CMU.EDU>
Message-ID: <860128150911.1.CASSELS@CUYAHOGA.SCRC.Symbolics.COM>
Reply-To: Robert A. Cassels <Cassels@SCRC-STONY-BROOK.ARPA>

    Date: Mon, 27 Jan 1986  10:42 EST
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>


	A not-entirely-unrelated question:  What kind of rounding is FLOAT supposed
	to do?

    I think that the GOAL is to produce the closest approximation to the
    ratio that is possible in a given floating-point format.  That's what
    implementors should shoot for.  Whether it makes sense to REQUIRE this
    in the very last bit is less clear.  I don't think I've ever seen a
    floating-point package that got this right all the time.

You haven't looked at your 36xx lately, then.

    -- Scott

∂28-Jan-86  1314	lab@rochester.arpa 	IEEE float co-processors 
Received: from ROCHESTER.ARPA by SU-AI.ARPA with TCP; 28 Jan 86  13:13:37 PST
Received: from ur-seneca.rochester.arpa (ur-seneca) by ur-cayuga.rochester.arpa id AA00446 (4.12u); Tue, 28 Jan 86 16:13:29 est
Received: by ur-seneca.rochester.arpa id AA01690 (4.12v); Tue, 28 Jan 86 15:12:49 est
Message-Id: <8601282012.1690@ur-seneca.rochester.arpa>
Date: Tue, 28 Jan 86 15:12:49 est
From: Lab Manager(Brad Miller)  <lab@rochester.arpa>
To: Moon@SCRC-STONY-BROOK.ARPA
Cc: common-lisp@SU-AI.ARPA
In-Reply-To: David A. Moon's message of Tue, 28 Jan 86 13:48 EST
Subject: IEEE float co-processors


I have not been thrilled with this ongoing meandering about floating
point, but I'd like to take exception to your statement about leaving
intermediate result precision unspecified. It would be nice if a
program working on one machine also worked on another. Surely that is
what portability is supposed to insure, not that the language is so
general that any floating point result is OK. Make everything BIGNUM
and forget it.

∂28-Jan-86  1500	REM@IMSSS 	Rebuttal to incorrect statement of portability definition  
X-Sent: to SU-AI.ARPA by IMSSS.FRONSTAD.EDU via ETHERNET with PUPFTP; 1986-Jan-28 14:59:18 PST (=GMT-8hr)
X-Mailer: EMACS -> PSL (FORMAT+SEND-ALL) -> PUPFTP
Date: 1986 January 28 14:56:44 PST (=GMT-8hr)
From: Robert Elton Maas <REM@IMSSS> (this host known locally only)
To:lab@rochester.arpa
CC:COMMON-LISP@SU-AI.ARPA
Subject:Rebuttal to incorrect statement of portability definition
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA

L> Date: Tue, 28 Jan 86 15:12:49 est
L> From: Lab Manager(Brad Miller)  <lab@rochester.arpa>
L> It would be nice if a program working on one machine also worked on
L> another. Surely that is what portability is supposed to insure, not
L> that the language is so general that any floating point result is OK.

The contrapositive is that if it fails on another then it also fails
on the one. I.e. nobody is allowed to make any improvements beyond the
minimal implementation. Nobody is allowed to make private enhancements
to the language, such as a window system etc. I disapprove.

The correct statement, in my opinion, is that any program which
restricts itself to features and capabilities as defined in CLtL will
run on any machine, but programs are permitted to take advantage of
nonportable features at the expense of no longer being portable. Thus
in the case at hand, programs that rely only on the minimal accuracy
of minimal results will be portable, runnable on all CL
implementations, but it is possible that some programs may take
advantage of extra accuracy available only on certain machines and
those programs will not be portable. The programmer should attempt to
determine whether the program is truly portable or not, although
sometimes that may be difficult to determine without actually trying
it on other machines (computer programming is still an experimental
science). It may be desirable to have a flag that disables use of
extended precision co-processors in order to test portability on a
single machine, but it should be legal to switch that flag to
machine-dependent maximum-precision mode at times.

∂28-Jan-86  1526	Moon@SCRC-STONY-BROOK.ARPA 	IEEE float co-processors   
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Jan 86  15:26:37 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 403727; Tue 28-Jan-86 17:32:17-EST
Date: Tue, 28 Jan 86 17:33 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: IEEE float co-processors
To: common-lisp@SU-AI.ARPA
In-Reply-To: <8601282012.1690@ur-seneca.rochester.arpa>
Message-ID: <860128173314.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 28 Jan 86 15:12:49 est
    From: Lab Manager(Brad Miller)  <lab@rochester.arpa>

    I have not been thrilled with this ongoing meandering about floating
    point, but I'd like to take exception to your statement about leaving
    intermediate result precision unspecified. It would be nice if a
    program working on one machine also worked on another. Surely that is
    what portability is supposed to insure, not that the language is so
    general that any floating point result is OK.

Well, you see, there are two conflicting goals here.  It would be nice
for programs to be portable.  It would also be nice for the Common Lisp
community not to have to take on the job of forcing IBM and DEC to agree
on a common format and semantics for floating-point arithmetic.

What we have done is to provide some features for finding out the
characteristics of floating-point arithmetic in a particular implementation.
This may be only a half measure, but it may also be the best we can do.

Taking off my language designer hat and putting on my manufacturer hat, of
course the system my company sells conforms to the IEEE standard and otherwise
makes an effort to provide reasonable, consistent, and standardized
floating-point semantics.  Some other manufacturers do so as well.  But I
don't think we want to forbid Common Lisp to be implemented on hardware that,
for whatever reason, has different ideas about how floating-point should work.

I'm going to try not to send any more mail on this subject.

∂28-Jan-86  1803	Cassels@SCRC-STONY-BROOK.ARPA 	more boring-to-most-people floating point stuff  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Jan 86  18:03:28 PST
Received: from WAIKATO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 403885; Tue 28-Jan-86 20:49:51-EST
Received: from CUYAHOGA.SCRC.Symbolics.COM by WAIKATO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 150379; Tue 28-Jan-86 20:51:24-EST
Date: Tue, 28 Jan 86 20:52 EST
From: Robert A. Cassels <Cassels@TENEX.SCRC.Symbolics.COM>
Subject: more boring-to-most-people floating point stuff
To: fateman@dali.berkeley.edu, Moon@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8601262213.AA19482@dali.berkeley.edu>
Message-ID: <860128205234.4.CASSELS@CUYAHOGA.SCRC.Symbolics.COM>
Reply-To: Robert A. Cassels <Cassels@SCRC-STONY-BROOK.ARPA>

    Date: Sun, 26 Jan 86 14:13:29 PST
    From: fateman@dali.berkeley.edu (Richard Fateman)

    The example  (/ (expt 10 68) 1.0e38) is illustrating
    ( <operator> <number-type-1> <number-type-2> )  whereas
    (/ (* 1.0e34 1.0e34) 1.0e38) is illustrating (recursively)
    (<operator> <number-type-1> <number-type-1>) .

    Only when you combine two number types, one majorizing the other,
    do you face this issue. The intent when combining different precisions
    (and ranges) within floats is clear.  You coerce to the longer precision
    because it is likely to give you the right answer. Not the fastest.
    A reasonable extension of this is if you mix floats with even longer
    precision numbers (i.e., rational), you convert to rational, because it
    gives you the right answer, not the fastest.

    You can, of course, promote the notion that "anything goes" as soon as exact
    and approximate numeric types are mixed, or claim that it would be too
    costly to do the right thing. 

I agree it's a question of what's right, not what's costly.  [Now that
we have the EGC, we don't worry so much about consing.]  I think my
earlier statements about efficiency were really trying to get at my last
point below about generic numeric functions.  (Although I would like my
generic functions to be as efficient as possible.)

     To say this is the wrong forum for this is to
    appear at odds with the space devoted to this
    and other numeric data types in the language specification.

Okay, I think I see what you're driving at.  You are saying that
rational arithmetic is "right" (mathematically correct) and so
computations should be encouraged to happen rationally.  A user who
*really* wants floating-point should have to be careful to say so.

I agree that we should be pushing rational arithmetic.  But I think that
we should point out that use of a floating-point number anywhere in a
computation must be assumed to have "tainted" the result.  I think it
would be misleading and less useful for (* pi 2) =>
884279719003555/140737488355328.  It would certainly be confusing for
(* .001 10) => 42949675/4294967296.  It's hard enough explaining that
(* .001 10) => 0.010000001.

I guess I prefer that any fuzziness in the computation be reflected in
fuzziness of the result.  You could object that coercion should then
prefer the smaller precision rather than the larger, and I'd probably
agree.

From a pragmatic and language design point of view, I'd like to be able
to write generic functions which work on both rational and
floating-point numbers, such that rational inputs get rational results
and floating inputs get floating results of the same precision.  I'd
prefer that the constants in those functions to be written rationally
when they're (mathematically) rational numbers.  So I'd still like
coercion to prefer floating-point.

∂28-Jan-86  1823	hilfingr@renoir.berkeley.edu 	Re: IEEE float co-processors  
Received: from UCBVAX.BERKELEY.EDU by SU-AI.ARPA with TCP; 28 Jan 86  18:23:15 PST
Received: by ucbvax.berkeley.edu (5.44/1.9)
	id AA10532; Tue, 28 Jan 86 18:23:27 PST
Received: by renoir.berkeley.edu (5.44/5.16)
	id AA07538; Tue, 28 Jan 86 18:23:15 PST
Resent-From: hilfingr@renoir.berkeley.edu (Paul Hilfinger)
Resent-Message-Id: <8601290223.AA07538@renoir.berkeley.edu>
Message-Id: <8601290223.AA07538@renoir.berkeley.edu>
Resent-To: common-lisp@su-ai.arpa
To: fateman@kim.berkeley.edu
Subject: Re: IEEE float co-processors
In-Reply-To: Your message of Tue, 28 Jan 1986  08:56 EST.
	     <FAHLMAN.12178838237.BABYL@C.CS.CMU.EDU>
Date: 28 Jan 86 12:24:12 PST (Tue)
From: hilfingr@renoir.berkeley.edu
Resent-Date: 28 Jan 86 16:10:21 PST (Tue)


> My only concern is that the interpreter would probably be stuck with
> doing the coercions at each step, and therefore might get a slightly
> different (less precise) answer than the compiler would come up with.
> Would that bother anyone?  (Not me, but I only look at the first two
> digits anyway...)

I don't do numerical work, but working down the hall from a
particularly famous and outspoken numerical analyst as I do, I don't
dare be completely uninformed on the issue.  

I think that one clearly wants the compiler and interpreter to give
identical results, not only for obvious reasons having to do with
debugging, but also for consistency with the CL campaign to bring
compiled and interpreted semantics closer together.  Fateman's
proposal doesn't seem to make it hard for the interpreter to be
consistent with the compiler.  For example, the implementation might
choose an implementation in which

   1. All expressions of the form (arith-op a b c ...) are grouped 
      left-associatively (at least if one operand is floating point
      and possibly always.

   2. All arithmetic involving floating point is done in extended
      precision, with the result being rounded to the appropriate
      precision at the end.

Is there any difficulty in having either interpreter or compiler
follow this semantics?

Frankly, I think the freedom to re-arrange allowed on page 194 is a
bad idea for any expression that might involve floating point operands
(maybe for others, too, but my opinion isn't strong on that.)  In
CL, of course, you don't have the freedom to say ``well, we'll compile
it this way for integers and ratios and that way for floating point''
because CL is not strongly typed.  I therefore anticipate the
objection, ``well we don't want to lower the quality of code for the
usual case (some sort of integers, I presume).''  However, in the
absence of very clear, solid, empirical evidence suggesting
appreciable degradation of performance resulting from the compiler's
inability to reassociate expressions, I'd just as soon chuck the
flexibility.

There is a prevailing opinion that ``well, floating point is
approximate, so who cares?  Why not rearrange as convenient?''  The
fact of the matter is that while floating point arithmetic is
approximate, it is ``approximate in a precise way'' (at least on most
architectures, and certainly on anything conforming to the IEEE
Standard 754.)  For example, on most machines x+y, x*y, x-y, and x/y
all have the property that in the absence of over/underflow, the
result has a very small (order 2**(-number of binary digits of
precision or so)) RELATIVE error.  Indeed, for addition (subtraction),
if the magnitudes of the operands are within a factor of 2 of each
other and the operands have opposite (the same) signs, so that
extensive cancellation occurs, the result is mathematically exact.
The common intuition that cancellation introduces error is completely
wrong.  This property turns out to be very useful (for example, it
makes it possible to compute the area of a triangle with a simple
formula that works well even for very flat triangles.)  It also
explains why some of us would like to avoid cavalier rounding of small
rationals to 0: doing so suddenly introduces a 100% relative error
into the computation.  Better to get an error indication or the right
answer.

I suppose one could argue that usually, one doesn't care.  For
integers and ratios this is certainly true, since the answer will be
identical in any case, unless something exceptional (and in particular
rare) happens.  But when regrouping changes the answer in
unexceptional cases, and when important properties of that answer by
rights could be predicted by simple and well-understood rules if only
the grouping were predictable, one has to wonder.

Paul Hilfinger

∂28-Jan-86  2015	FAHLMAN@C.CS.CMU.EDU 	DEFUN inside LET  
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 28 Jan 86  20:11:43 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 28 Jan 86 23:12:32-EST
Date: Tue, 28 Jan 1986  23:12 EST
Message-ID: <FAHLMAN.12178994051.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   "James R. Meehan" <csi!meehan%UUCP@YALE.ARPA>
Cc:   common-lisp@SU-AI.ARPA
Subject: DEFUN inside LET
In-reply-to: Msg of 28 Jan 1986  10:06-EST from James R. Meehan <csi!meehan%UUCP at YALE.ARPA>


I'm not sure if there's actually a firm consensus on this, but in my
opinion Defun inside Let should always work.  It's an idiom I use a lot,
and if some alleged Common Lisp didn't supply this, I'd either complain
or fix it myself.

-- Scott

∂29-Jan-86  1040	mcvax!nplmg1a.uucp!jrp@seismo.CSS.GOV 	Floating Point Computation
Received: from SEISMO.CSS.GOV by SU-AI.ARPA with TCP; 29 Jan 86  10:38:08 PST
Return-Path: <mcvax!nplmg1a.uucp!jrp>
Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Wed, 29 Jan 86 13:09:37 EST
From: mcvax!nplmg1a.uucp!jrp@seismo.CSS.GOV
Received: by mcvax.uucp; Wed, 29 Jan 86 18:43:01 +0100 (MET)
Received: by mcvax.uucp; Wed, 29 Jan 86 18:42:49 +0100 (MET)
Received: from nplmg1a.uucp by eagle.Ukc.AC.UK   with UUCP  id a000367;
          29 Jan 86 16:44 GMT
To: common-lisp@su-ai.arpa
Subject: Floating Point Computation
Return-Receipt-To: mcvax!nplmg1a.uucp!jrp@seismo.CSS.GOV
Date: 29 Jan 86 16:38:25 GMT (Wed)
Message-Id: <1000.507400705@nplmg1a>


I hope that the following paper will put final rest to the speculations
on floating point arithmetic:-

	Brown, W.S.,
	A Simple but Realistic Model of Floating-Point Computation,
	ACM Transactions on Mathematical Software Vol. 7 No. 4, Dec 81.

	(Material is also to be found in the ADA reference manual)

Do not  assume  that  the  arithmetic on  your  machine  is  implemented
correctly (in hardware).   Do  not assume  (particularly for  UNIX-based
systems) that the text -> internal conversion routines are any good.  Do
not assume that the elementary functions are any good on your machine.

You will not go far wrong!
John Pavel

∂29-Jan-86  1052	FAHLMAN@C.CS.CMU.EDU 	Floating Point Computation  
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 29 Jan 86  10:52:10 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 29 Jan 86 13:52:43-EST
Date: Wed, 29 Jan 1986  13:52 EST
Message-ID: <FAHLMAN.12179154269.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   mcvax!nplmg1a.uucp!jrp@SEISMO.CSS.GOV
Cc:   common-lisp@SU-AI.ARPA
Subject: Floating Point Computation
In-reply-to: Msg of 29 Jan 1986  11:38-EST from mcvax!nplmg1a.uucp!jrp at seismo.CSS.GOV


Thanks for the reference.  I'm not sure what point you are trying to
make, however.  Is there some specific recommendation lurking in here?
Or are you just saying that everything about floating-point is so
screwed up that we shouldn't waste time arguning about how to make it
better?

-- Scott

∂29-Jan-86  1133	fateman@dali.berkeley.edu 	Re:  Floating Point Computation  
Received: from UCBVAX.BERKELEY.EDU by SU-AI.ARPA with TCP; 29 Jan 86  11:32:59 PST
Received: by ucbvax.berkeley.edu (5.44/1.9)
	id AA25344; Wed, 29 Jan 86 11:32:58 PST
Received: by dali.berkeley.edu (5.44/5.16)
	id AA21319; Wed, 29 Jan 86 11:32:39 PST
Date: Wed, 29 Jan 86 11:32:39 PST
From: fateman@dali.berkeley.edu (Richard Fateman)
Message-Id: <8601291932.AA21319@dali.berkeley.edu>
To: common-lisp@su-ai.arpa, mcvax!nplmg1a.uucp!jrp@seismo.css.gov
Subject: Re:  Floating Point Computation

Sorry to disappoint you, but
Brown's model was intended to provide a model to include nearly all 
known horrors.  It is hardly a prescription for what to do in
designing either a computer or a language. 

∂29-Jan-86  1144	JAR@MC.LCS.MIT.EDU 	DEFUN inside LET    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 Jan 86  11:43:55 PST
Date: Wed, 29 Jan 86 14:45:27 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject:  DEFUN inside LET
To: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Tue 28 Jan 1986  23:12 EST from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[MC.LCS.MIT.EDU].800572.860129.JAR>

    Date: Tue, 28 Jan 1986  23:12 EST
    From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>

    I'm not sure if there's actually a firm consensus on this, but in my
    opinion Defun inside Let should always work.  It's an idiom I use a lot,
    and if some alleged Common Lisp didn't supply this, I'd either complain
    or fix it myself.

I don't understand how one can argue with p. 67 of CLtL which (to me)
unequivocally says that DEFUN inside LET should "work":

"Evaluating a DEFUN form causes the symbol ... to be a global name for
the function specified by the LAMBDA-expression ... in the lexical
environment in which the DEFUN form was executed."

Also, since DEFUN is a macro, it's hard to imagine what it could expand
into in order to behave much differently from this.

∂29-Jan-86  1206	FAHLMAN@C.CS.CMU.EDU 	DEFUN inside LET  
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 29 Jan 86  12:05:52 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 29 Jan 86 15:06:10-EST
Date: Wed, 29 Jan 1986  15:06 EST
Message-ID: <FAHLMAN.12179167652.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Cc:   common-lisp@SU-AI.ARPA
Subject: DEFUN inside LET
In-reply-to: Msg of 29 Jan 1986  14:45-EST from Jonathan A Rees <JAR at MC.LCS.MIT.EDU>


Fine, I'm happy to agree that this passage is unequivocal.  One might
have been confused by the mumbling about "top-level forms" that
surrounds this passage, but let's not be.  Does anyone out there want to
argue that DEFUN inside of LET is not required to work?

-- Scott

∂30-Jan-86  0702	NGALL@G.BBN.COM 	Re:  DEFUN inside LET  
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 30 Jan 86  06:58:56 PST
Date: 30 Jan 1986 09:58-EST
Sender: NGALL@G.BBN.COM
Subject: Re:  DEFUN inside LET
From: NGALL@G.BBN.COM
To: JAR@MC.LCS.MIT.EDU
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]30-Jan-86 09:58:55.NGALL>
In-Reply-To: <[MC.LCS.MIT.EDU].800572.860129.JAR>

	
    Date: Wed, 29 Jan 86 14:45:27 EST
    From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
    Subject:  DEFUN inside LET
    
	Date: Tue, 28 Jan 1986  23:12 EST
	From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
    
	I'm not sure if there's actually a firm consensus on this...

    I don't understand how one can argue with p. 67 of CLtL which (to me)
    unequivocally says that DEFUN inside LET should "work":
    
    "Evaluating a DEFUN form causes the symbol ... to be a global name for
    the function specified by the LAMBDA-expression ... in the lexical
    environment in which the DEFUN form was executed."

That passage sounds unequivocal (by itself) to me too (and I am VERY
much in favor of DEFUNs in LETs).  Unfortunately, on pg.  66, is this
very equivocal passage that may imply that a DEFUN inside a LET is not
guaranteed to work in CL:

"It is not illegal to use these forms at other than top level, but whether it
is meaningful to do so depends on context [talk about waffling!]. Compilers,
for example, may not recognize these forms properly in other than top-level
contexts."

As I recall, this is the passage that has prevented a "firm consensus" and
I think there was some sort of consensus that the passage should be clarified
to unequivocally allow DEFUNs in LETs (and to state more explicitly what
forms are not meaningful in which contexts).  

    Also, since DEFUN is a macro, it's hard to imagine what it could expand
    into in order to behave much differently from this.
    
Imagine this:

(defmacro simple-defun (name lambda-list &body body)
  `(setf (symbol-function ',name)
         '(lambda ,lambda-list ,@body)))

The quote in front of the lambda ensures that the lambda expression is
defined in the null lexical environment.

	-- Nick

∂30-Jan-86  0834	mcvax!nplmg1a.uucp!jrp@seismo.CSS.GOV 	Re: Floating Point Computation 
Received: from SEISMO.CSS.GOV by SU-AI.ARPA with TCP; 30 Jan 86  08:31:41 PST
Return-Path: <mcvax!nplmg1a.uucp!jrp>
Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Thu, 30 Jan 86 11:10:05 EST
From: mcvax!nplmg1a.uucp!jrp@seismo.CSS.GOV
Received: by mcvax.uucp; Thu, 30 Jan 86 16:03:51 +0100 (MET)
Received: by mcvax.uucp; Thu, 30 Jan 86 16:03:33 +0100 (MET)
Received: from nplmg1a.uucp by eagle.Ukc.AC.UK   with UUCP  id a009312;
          30 Jan 86 9:44 GMT
To: Fahlman@c.cs.cmu.edu
Cc: nplmg1a!jrp@seismo.CSS.GOV, common-lisp@su-ai.arpa
Subject: Re: Floating Point Computation
In-Reply-To: Your message of Wed, 29 Jan 1986  13:52 EST.
	     <FAHLMAN.12179154269.BABYL@C.CS.CMU.EDU>
Date: 30 Jan 86 09:42:27 GMT (Thu)
Message-Id: <1000.507462147@nplmg1a>


    
    Thanks for the reference.  I'm not sure what point you are trying to
    make, however.  Is there some specific recommendation lurking in here?

I don't think that I have anything very profound to say, save don't take
*anything* for granted when it comes  to floating point.  The  reference
gives a  number of  simple axioms  which *should*  be satisfied  by  any
reasonable processor, but  are surprisingly often  not satisfied in  all
cases.  In any  case, these axioms should  permit you to determine  what
you can  resonably do  with floating-point  in what  might be  called  a
"sane" environment.

By  the  way,  there  are  a  number  of  packages  for  assessing   the
floating-point performance of  a given  processor (e.g.   from NAG,  the
Numerical Algorithms Group in Oxford).

And when it comes to "double-length" arithmetic...

    Or are you just saying that everything about floating-point is so
    screwed up that we shouldn't waste time arguning about how to make
    it better?

I  would  not  go  that  far,  but  when  it  comes  to  "double-length"
arithmetic...

John Pavel

∂30-Jan-86  1011	jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	Re:  DEFUN inside LET    
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 30 Jan 86  10:10:53 PST
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK   via Janet with NIFTP
           id a000168; 30 Jan 86 13:33 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk>
Date: Wed, 29 Jan 86 17:47:51 GMT
Message-Id: <Wed Jan 29 17:47:51 1986 @ aiva.edinburgh.ac.uk>
To: Fahlman@c.cs.cmu.edu, meehan <@yale.arpa,@harvard.harvard.edu:meehan@csi>
Subject: Re:  DEFUN inside LET
Cc: common-lisp@su-ai.arpa

    Date: Tue, 28 Jan 1986  23:12 EST
    From: "Scott E. Fahlman" <Fahlman@edu.cmu.cs.c>

    I'm not sure if there's actually a firm consensus on this, but in my
    opinion Defun inside Let should always work.  It's an idiom I use a lot,
    and if some alleged Common Lisp didn't supply this, I'd either complain
    or fix it myself.

Another issue is what DEFUN inside LET should do.  My understanding of Common
Lisp is that

  (let ((a 1)) (defun f () a) ...)

is supposed to be equivalent (modulo implicit blocks, &c) to

  (let ((a 1)) (setf (symbol-function 'f) #'(lambda () a)) ...)

but that in Scheme it is equivalent to

  (let ((a 1)) (labels ((f () a)) ...))

In other words, does an internal DEFUN define a local or a global function?
My opinion now is that I would rather have it define a local function (a la
Scheme), because I think that looks better than a LABELS, because I use local
functions a lot, and because, to me, it seems more natural.  But if I used
global functions defined inside environments a lot, I could well change my
mind since the SETF is clearly worse than LABELS (and hence more in need of a
sweetened syntax).  At the moment, though, I'm not sure what a global DEFUN
inside a LET is supposed to express (i.e., what is it good for?).

-- Jeff



∂30-Jan-86  1130	FAHLMAN@C.CS.CMU.EDU 	Defun inside Let  
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 Jan 86  11:29:25 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 30 Jan 86 14:29:43-EST
Date: Thu, 30 Jan 1986  14:29 EST
Message-ID: <FAHLMAN.12179423154.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: Defun inside Let


There can be no question at all on the point Jeff Dalton raises: when a
Defun occurs inside a Let or anywhere else, it changes the GLOBAL
function definition for the symbol in question.  It is not a form of
LABELS.

-- Scott

∂30-Jan-86  1146	RAM@C.CS.CMU.EDU 	DEFUN inside of LET   
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 Jan 86  11:46:39 PST
Received: ID <RAM@C.CS.CMU.EDU>; Thu 30 Jan 86 14:46:55-EST
Date: Thu, 30 Jan 1986  14:46 EST
Message-ID: <RAM.12179426294.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: DEFUN inside of LET


    The meaning of DEFUN inside of LET has been discussed at least
twice before on thie mailing list.  Each time some people say that
they aren't sure whether it is required to work, and the rest of the
people say that "The U.S. will look pretty wimpy in ISO standardization
if DEFUN doesn't work inside of LET."

    If you have a lexical Lisp, DEFUN with a non-null environment will
work without any major effort.  I can't think of any reason for
arbitrarily making the environment for DEFUN null, and I can think of
good reasons for not doing so.  If you want a definition in a null
environment, you can always put the definition in a null environment.

    It is my opinion that the notion of a top-level form doesn't make
sense in a lexical Lisp.  This issue definitely needs to be clarified.
I think that passage in CLTL about top-level forms not being well
defined in non-top-level contexts should be flushed.  It should be
replaced with text describing what the forms do.  This opinion is
based on the assumption that it is reasonable to make definitions in a
non-null environment.  Such definitions are clearly not in a top-level
context, so the semantics of definitions in non-top-level contexts
must be defined.

    As to whether DEFUN makes a local definition, I would say no.  It
seems to me that the semantics of defun is to change the global
function definition, no matter where it appears.  Common Lisp has no
notion of a block which implicitly gloms onto definitions in its body.
If you want to make a local definition, you use a binding form.

  Rob

P.S. Rambo for technical committee!

∂30-Jan-86  1304	DCP@SCRC-STONY-BROOK.ARPA 	Defun inside Let  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 30 Jan 86  13:03:18 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 405501; Thu 30-Jan-86 16:01:52-EST
Date: Thu, 30 Jan 86 16:08 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Defun inside Let
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12179423154.BABYL@C.CS.CMU.EDU>
Message-ID: <860130160817.5.DCP@NEPONSET.SCRC.Symbolics.COM>

    Date: Thu, 30 Jan 1986  14:29 EST
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    There can be no question at all on the point Jeff Dalton raises: when a
    Defun occurs inside a Let or anywhere else, it changes the GLOBAL
    function definition for the symbol in question.  It is not a form of
    LABELS.

We've discussed this inside Symbolics, and we don't have a solution for
the following problem:

(let ((a 3)
      (b 5))
  (defun add-and-increment ()
    (prog1 (+ a b)
	   (incf a)
	   (incf b)))
  (defun sub-and-decrement ()
    (prog1 (- a b)
	   (decf a)
	   (decf b))))

That's all fine and dandy.  Now come the hard parts.  

 - What if I want to redefine add-and-increment to be
     (defun add-and-increment (&optional amount)
       (prog1 (+ a b)
	      (incf a amount)
	      (incf b amount)))
   Is the system expected to know that >the old version< of
   add-and-increment is a lexical closure over some variables and make the
   new one share that same environment?
   
 - What if I wanted to add a variable to the lexical environment?  What
   forms to I type to splice something in?
   
 - What if I want to redefine add-and-increment to be interpreted?  Are you
   forcing all implementations to have the same compiler and interpreter
   environment?
   
 - Suppose you declare 'you are not allowed to redefine a function whose
   old definition is closed over a non-null lexical environment and
   expect it to inherit the old environment.'  What if I interpret the
   above LET.  Am I allowed to compile just one of the functions?  If
   not, why not?  If not, am I allowed to compile both?  If so, how do I
   manage that with the tools provided (which presumably compile on
   thing at a time.)  If I am allowed to compile just one, does that
   enforce the same format for compiled and interpreted lexical
   environments?

I don't have answers for any of those.  It's not clear to me there ARE
answers to some of them.  What if somebody on the ISO board thinks up
roughly the same questions?  If somebody does have >answers<, I'd like
to hear them.  My personal feeling is that DEFUN that requires a
non-null lexical environment, such as created by LET, is a timebomb
ticking quickly.

∂30-Jan-86  1405	JAR@MC.LCS.MIT.EDU 	Defun inside Let    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 30 Jan 86  14:03:37 PST
Date: Thu, 30 Jan 86 17:05:05 EST
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Sender: JAR0@MC.LCS.MIT.EDU
Subject:  Defun inside Let
To: DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Thu 30 Jan 86 16:08 EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].802081.860130.JAR0>

    Date: Thu, 30 Jan 86 16:08 EST
    From: David C. Plummer <DCP at SCRC-QUABBIN.ARPA>

    ... That's all fine and dandy.  Now come the hard parts.  

       Is the system expected to know that >the old version< of
       add-and-increment is a lexical closure over some variables and make the
       new one share that same environment?

     - What if I wanted to add a variable to the lexical environment?  What
       forms to I type to splice something in?

    ...

    I don't have answers for any of those.  It's not clear to me there ARE
    answers to some of them.  What if somebody on the ISO board thinks up
    roughly the same questions?  If somebody does have >answers<, I'd like
    to hear them.  My personal feeling is that DEFUN that requires a
    non-null lexical environment, such as created by LET, is a timebomb
    ticking quickly.

The questions you raise are valid and important ones, but I don't see
what they have to do with DEFUN.  They apply equally to SETQ, SETF,
FLET, LABELS, etc., and are bound to arise the minute you have lexical
closures at all.  Yes, it would be nice to be able to update the code
for a closure, alter environments, and so forth, for debugging.  But I
don't see why debugging questions should enter into this semantic
question.  Is there some reason that DEFUN is different?  If there's a
problem with making (DEFUN FOO ...) mean the same [except with respect
to debugging, which Common Lisp doesn't address anyhow] as (SETF
(SYMBOL-FUNCTION 'FOO) #'(LAMBDA ...)), why isn't that problem also a
problem with the SETF form?

Jonathan

∂30-Jan-86  1426	smh@mit-ems.ARPA 	Re:  DEFUN inside LET 
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 30 Jan 86  14:25:34 PST
Received: by mit-ems.ARPA (4.12/4.8)  id AA10164; Thu, 30 Jan 86 17:18:25 est
Date: Thu, 30 Jan 86 17:18:25 est
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8601302218.AA10164@mit-ems.ARPA>
To: DCP@SCRC-STONY-BROOK.ARPA, JAR%MC.LCS.MIT.EDU@mit-ems.ARPA,
        NGALL%G.BBN.COM@mit-ems.ARPA
Subject: Re:  DEFUN inside LET
Cc: common-lisp@SU-AI.ARPA

> From @SU-AI.ARPA:NGALL@G.BBN.COM Thu Jan 30 11:27:51 1986
> 
> > Also, since DEFUN is a macro, it's hard to imagine what it could expand
> > into in order to behave much differently from this.
>     
> Imagine this:
> 
> (defmacro simple-defun (name lambda-list &body body)
>   `(setf (symbol-function ',name)
>          '(lambda ,lambda-list ,@body)))
> 
> The quote in front of the lambda ensures that the lambda expression is
> defined in the null lexical environment.

Wouldn't one instead use:

  (defmacro simple-defun (name lambda-list &body body)
    `(setf (symbol-function ',name)
           (function (lambda ,lambda-list ,@body))))

This would seem to capture the lexical environment quite unambiguously.
If, as DCP suggests, a defun that captures its lexical environment is
really a "time bomb", defun could be "fixed".  But how could it be
possible to prohibit constructions like the above?

∂30-Jan-86  1506	DCP@SCRC-STONY-BROOK.ARPA 	Defun inside Let  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 30 Jan 86  15:05:47 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 405638; Thu 30-Jan-86 18:03:56-EST
Date: Thu, 30 Jan 86 18:10 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Defun inside Let
To: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>,
    Steven Haflich <smh@MIT-EMS.ARPA>
cc: DCP@SCRC-QUABBIN.ARPA, JAR%MC.LCS.MIT.EDU@MIT-EMS.ARPA,
    NGALL%G.BBN.COM@MIT-EMS.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <[MC.LCS.MIT.EDU].802081.860130.JAR0>,
             <8601302218.AA10164@mit-ems.ARPA>
Message-ID: <860130181022.1.DCP@NEPONSET.SCRC.Symbolics.COM>

You two bring up the same point.  What if DEFUN's macro expansion were

	(setf (symbol-function 'foo) #'(lambda arglist . body))

Minor nit: some systems would lose the name of the function inside the
lambda.  All compiled functions have names.

Disagreement with Rees: I think debugging questions should come into the
semantics of things.  Some companies use debuggability and the power of
their debug tools as one of their selling points.  Indeed this isn't
an issue for applications that don't alter functions, but it is
to developers.  Anyway...  

This is no different from defun.  The problem is that there is a top
level functional form, #'(lambda ...) in this case, that the compiler
has to do something with.  Maybe a compiler that sees such a thing in a
non-null lexical environment punts (this doesn't address several other
issues I raised).  Then people will complain, and have to us, that it is
inefficient by generating interpreted code.

∂30-Jan-86  1529	REM@IMSSS 	Defun inside Let   
X-Sent: to SU-AI.ARPA by IMSSS.FRONSTAD.EDU via ETHERNET with PUPFTP; 1986-Jan-30 15:28:45 PST (=GMT-8hr)
X-Mailer: EMACS -> PSL (FORMAT+SEND-ALL) -> PUPFTP
Date: 1986 January 30 15:26:53 PST (=GMT-8hr)
From: Robert Elton Maas <REM@IMSSS> (this host known locally only)
To:DCP@SCRC-QUABBIN.ARPA
CC:Fahlman@C.CS.CMU.EDU,COMMON-LISP@SU-AI.ARPA
Subject: Defun inside Let
Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications)
Reply-to: REM%IMSSS@SU-SCORE.ARPA

S> Date: Thu, 30 Jan 1986  14:29 EST
S> From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
S> when a Defun occurs inside a Let or anywhere else, it changes the
S> GLOBAL function definition for the symbol in question.  It is not a
S> form of LABELS.

I agree, see my related opinion below.

D> Date: Thu, 30 Jan 86 16:08 EST
D> From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
D> (let ((a 3) (b 5))
D>   (defun add-and-increment ()
D>     (prog1 (+ a b) (incf a) (incf b)))
D>   (defun sub-and-decrement ()
D>     (prog1 (- a b) (decf a) (decf b))))

Clearly that creates two global function-bindings (definitions) to
function-objects each of which has access to the same lexical
environment (the one containing a and b initialized to 3 and 5 resp.).
I think we all agree so far.

D> That's all fine and dandy.  Now come the hard parts.  
D>  - What if I want to redefine add-and-increment to be
D>      (defun add-and-increment (&optional amount)
D>        (prog1 (+ a b) (incf a amount) (incf b amount)))

If you just do a toplevel defun, you are replacing the old definition
with a new one that uses the null lexical environment instead of the
one with a and b used by the earlier definitions. Thus you are
probably making a mistake, doing something other than what you
obviously wanted to do. The old function-object still accesses the a,b
environment but is inaccessible, while the new function-object
currently function-bound to the symbol add-and-increment access the
null environment instead. But if you had explicitly recovered the
lexical environment from either add-and-increment or
sub-and-decrement (either will do in this case), and executed the new
DEFUN in that environment, then the new function-object could share
lexical a,b once again. In this particular example you can recover
from the mistake because even though the old add-and-increment
function-object is inaccessible so you can no longer recover the a,b
environment from it (unless your user interface has a history/undo
mechanism), you can still recover the environment from the
not-yet-lost sub-and-increment function-object which is still
function-bound to the sub-and-increment symbol thus accessible.
(However I don't know how to actually obtain explicit CLtL-level
access to that lexical environment; in earlier debate on macro
expansion didn't we decide that at present CLtL provides no such
mechanism for explicitly handling &environment stuff but ought to be
changed to provide it?)

D> Is the system expected to know that >the old version< of
D> add-and-increment is a lexical closure over some variables and make the
D> new one share that same environment?

I'd say definitely not. If you specify null lexical environment, by
doing a toplvel DEFUN, that's what you should get.

D> - What if I wanted to add a variable to the lexical environment?  What
D>    forms to I type to splice something in?

I'm under the impression lexical environments (except possibly the
null environment) can't get new variables once they are formed, but
there were suggestions to change this both for debugging reasons and
for consistency with the null environment.
   
D> - What if I want to redefine add-and-increment to be interpreted?  Are you
D>    forcing all implementations to have the same compiler and interpreter
D>    environment?

Now the cans of worms really start to open. I'd say if there is a
mechanism for redefining functions inside a non-null lexical
environment, as in the a,b example above, or if by any other mechanism
it is possible to create a situation where some but not all functions
in a particular lexical environment are compiled, this implies that
both interpreted and compiled functions must access lexical
environments in the same way essentially, i.e. that there be just one
implementation of lexical environment that is used by both kinds of
code. (Well, it would maybe be possible to have two kinds of lexical
environments, one optimized for compiled code and one not, but allow
either kind of function to access either kind of environment, sort of
like the way interpreted functions can call compiled functions by
calling APPLY on the contents of the function cell and vice versa by
linking to COMPILED-CALLING-INTERPRETED or whatever which sets up a
call to APPLY. But then if you initially load some functions
interpreted and later compile them in memory you may be permanently
stuck with the compiled functions running slowly as they access the
non-compiled lexical environment.)
   
D> My personal feeling is that DEFUN that requires a
D> non-null lexical environment, such as created by LET, is a timebomb
D> ticking quickly.

Well, if the language allows the DEFUN to be done, but the implementor
doesn't take care to do things correctly, indeed poor programmers will
find their code blowing up whenever they trigger the bugs.

One major question for CL advocates. Has anybody written a completely
correct implemention of CL, with no exceptions whatsoever, with all
these esoteric/messy cases correctly handled, with both interpretor
and compiler doing the expected things, so that we can establish by
example that CLtL isn't self-contradictory?? I personally believe that
as currently documented CLtL is indeed self-contradictory, even after
all the typos have been fixed, and thus in some sense hopeless as a
standard, but I'd be glad if I was wrong.

∂30-Jan-86  1712	smh@mit-ems.ARPA 	Re:  Defun inside Let 
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 30 Jan 86  17:08:54 PST
Received: by mit-ems.ARPA (4.12/4.8)  id AA10928; Thu, 30 Jan 86 20:03:44 est
Date: Thu, 30 Jan 86 20:03:44 est
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8601310103.AA10928@mit-ems.ARPA>
To: REM%IMSSS.MIT.EDU@mit-ems.ARPA
Subject: Re:  Defun inside Let
Cc: common-lisp@su-ai.ARPA

> From @SU-AI.ARPA:REM@IMSSS Thu Jan 30 19:00:10 1986
> 
> But if you had explicitly recovered the lexical environment from
> either add-and-increment or sub-and-decrement (either will do in this
> case), and executed the new DEFUN in that environment, then the new
> function-object could share lexical a,b once again.

> I'm under the impression lexical environments (except possibly the null
> environment) can't get new variables once they are formed, but there
> were suggestions to change this both for debugging reasons and for
> consistency with the null environment.

I'm under the same impression.  There is a very good motivation for
hiding the insides of lexical closures:  The compiler (and by
implication also the interpreter) is allowed to do whatever flow and
variable analysis it can in order to bum or completely eliminate
closures.  By requiring that it be possible subsequently to modify a
closure, such analysis becomes impossible.  See the four examples on
CLtL pp.88-9 where in one case the compiler can avoid making a closure,
and in another merge many closures into a single object.

These optimizations could be especially important when compiling
automatically-generated code.  It is worth every bit of effort to make
CL compilers super-analyzing/optimizing, because that's the place in a
CL system that has the most leverage on language performance.
   
> Has anybody written a completely correct implemention of CL so that we
> can establish by example that CLtL isn't self-contradictory??

How would he know if he had?  If knowing were so easy, compiler
validation wouldn't be the subject of so much research.  And we
wouldn't hear about validation suites in Ada land that execute
such-and-so percentage of the language features...

∂30-Jan-86  1714	RAM@C.CS.CMU.EDU 	Defun inside Let 
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 Jan 86  17:13:57 PST
Received: ID <RAM@C.CS.CMU.EDU>; Thu 30 Jan 86 20:13:52-EST
Date: Thu, 30 Jan 1986  20:13 EST
Message-ID: <RAM.12179485813.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc:   common-lisp@SU-AI.ARPA, "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Subject: Defun inside Let
In-reply-to: Msg of 30 Jan 1986  16:08-EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>

    Date: Thursday, 30 January 1986  16:08-EST
    From: David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
    To:   Scott E. Fahlman <Fahlman>, common-lisp at SU-AI.ARPA
    Re:   Defun inside Let

    That's all fine and dandy.  Now come the hard parts.  

     - What if I want to redefine add-and-increment to be
       ...
       Is the system expected to know that >the old version< of
       add-and-increment is a lexical closure over some variables and make the
       new one share that same environment?
No, and for the reson REM says.  The new definition is in the
environment you define it in, which is null in this case.  Common Lisp
doesn't need to be able to redefine functions within an old
environment.  Perhaps a useful feature, but certainly not necessary to
make good use of definitions in non null-environments.  This is more
of a programming environment issue than a lexical environment issue.
Uses of definitions in non-null environments are usually such that it
is easy to recompile the whole shebang.  You can't do it with COMPILE,
but in Hemlock, all I have to do is "Compile Defun".
       
     - What if I wanted to add a variable to the lexical environment?  What
       forms to I type to splice something in?
Not defined in Common Lisp.  I have been living without it.
       
     - What if I want to redefine add-and-increment to be interpreted?  Are you
       forcing all implementations to have the same compiler and interpreter
       environment?
If you can't redefine it without its environment, you can't redefine
it to be interpreted without EVAL'ing it all, thus there is no problem.
       
     - Suppose you declare 'you are not allowed to redefine a function whose
       old definition is closed over a non-null lexical environment and
       expect it to inherit the old environment.'  What if I interpret the
       above LET.  Am I allowed to compile just one of the functions?  If
       not, why not?  If not, am I allowed to compile both?  If so, how do I
       manage that with the tools provided (which presumably compile on
       thing at a time.)  If I am allowed to compile just one, does that
       enforce the same format for compiled and interpreted lexical
       environments?
Well, you can expect whatever you want... :-)
Spice Lisp doesn't let you use COMPILE on functions defined in a non-null
environment.  Why not?  Because it's hard to implement and not worth
the effort.  Of course, Common Lisp COMPILE could just do nothing in
this case.

    I don't have answers for any of those.  My personal feeling is
    that DEFUN that requires a non-null lexical environment, such as
    created by LET, is a timebomb ticking quickly.
I think many of the cited problems are contingent in the assumption
that COMPILE lets you do everything you want to do.  You are bothered
mostly by programming environment issues which Common Lisp mostly
doesn't address.

  Rob

∂30-Jan-86  1723	mips!escargot.earl@glacier 	DEFUN inside of LET   
Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 30 Jan 86  17:23:29 PST
Received: by glacier with Sendmail; Thu, 30 Jan 86 17:21:39 pst
Received: from escargot.UUCP (escargot.ARPA) by mips.UUCP (4.12/4.7)
	id AA18926; Thu, 30 Jan 86 13:37:50 pst
Received: by escargot.UUCP (4.12/4.7)
	id AA04616; Thu, 30 Jan 86 13:37:13 pst
Date: Thu, 30 Jan 86 13:37:13 pst
From: mips!escargot.earl@glacier (Earl Killian)
Message-Id: <8601302137.AA04616@escargot.UUCP>
To: common-lisp@SU-AI.ARPA
In-Reply-To: Rob MacLachlan's message of Thu, 30 Jan 1986  14:46 EST
Subject: DEFUN inside of LET

No one has suggested that making DEFUN inside of LET not work is the
right thing (people have suggested that it may not be required by the
current wording of the Common Lisp manual).  If someone feels that
DEFUN inside of LET shouldn't work, they ought to speak up!

∂30-Jan-86  1805	@SCRC-QUABBIN.ARPA,@EUPHRATES.SCRC.Symbolics.COM:Moon@SCRC-STONY-BROOK.ARPA 	Defun inside Let  
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 30 Jan 86  18:02:52 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via INTERNET with SMTP id 240543; 30 Jan 86 20:59:51-EST
Date: Thu, 30 Jan 86 21:02 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Defun inside Let
To: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
cc: DCP@SCRC-QUABBIN.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <[MC.LCS.MIT.EDU].802081.860130.JAR0>
Message-ID: <860130210226.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 30 Jan 86 17:05:05 EST
    From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>

	Date: Thu, 30 Jan 86 16:08 EST
	From: David C. Plummer <DCP at SCRC-QUABBIN.ARPA>

    The questions you raise are valid and important ones, but I don't see
    what they have to do with DEFUN.  They apply equally to SETQ, SETF,
    FLET, LABELS, etc., and are bound to arise the minute you have lexical
    closures at all.  Yes, it would be nice to be able to update the code
    for a closure, alter environments, and so forth, for debugging.  But I
    don't see why debugging questions should enter into this semantic
    question.  Is there some reason that DEFUN is different?  

Yes, it defines a name in the global environment.  This means the user
can talk about a particular DEFUN.  A user can't talk about a particular
SETQ or a particular FLET in this way, because they don't have names.

I think calling this "debugging" is ducking a genuine issue of language
definition.  "Making DEFUN inside of LET work" is not as simple as some
people seem to think, because the definition of what it means to "work"
is not simple and involves issues like the ones DCP raised, which have
been raised many times before and are probably the reason for the paragraph
on page 66 that everyone likes to dump on.

							      If there's a
    problem with making (DEFUN FOO ...) mean the same [except with respect
    to debugging, which Common Lisp doesn't address anyhow] as (SETF
    (SYMBOL-FUNCTION 'FOO) #'(LAMBDA ...)), why isn't that problem also a
    problem with the SETF form?

Who says it isn't?  The only difference is that users aren't accustomed to
writing (SETF (SYMBOL-FUNCTION 'FOO) #'(LAMBDA ...)) all the time.

Let me put it this way.  It's easy enough to say that (LET ... (DEFUN FOO ...))
has the same effect as (LET ... (SETF (SYMBOL-FUNCTION 'FOO) #'(LAMBDA ...))),
and in fact I know of no implementation where that is not already true.
The problem comes when people try to use this to do real work.  It
quickly becomes apparent that you have actually added a whole new
feature to the language, without much thought or standardization of how
it is to be used.


∂30-Jan-86  1805	DCP@SCRC-STONY-BROOK.ARPA 	Defun inside Let  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 30 Jan 86  17:59:15 PST
Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 405743; Thu 30-Jan-86 20:57:21-EST
Date: Thu, 30 Jan 86 21:03 EST
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Defun inside Let
To: Rob MacLachlan <RAM@C.CS.CMU.EDU>,
    Earl Killian <mips!escargot.earl@SU-GLACIER.ARPA>,
    David C. Plummer <DCP@SCRC-QUABBIN.ARPA>, common-lisp@SU-AI.ARPA
cc: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
In-Reply-To: <RAM.12179485813.BABYL@C.CS.CMU.EDU>,
             <8601302137.AA04616@escargot.UUCP>
Message-ID: <860130210351.3.DCP@NEPONSET.SCRC.Symbolics.COM>

    Date: Thu, 30 Jan 1986  20:13 EST
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>

	I don't have answers for any of those.  My personal feeling is
	that DEFUN that requires a non-null lexical environment, such as
	created by LET, is a timebomb ticking quickly.

    I think many of the cited problems are contingent in the assumption
    that COMPILE lets you do everything you want to do.  You are bothered
    mostly by programming environment issues which Common Lisp mostly
    doesn't address.

That's right, I am bothered by programming environment.  That isn't
necessarily an issue to the people who use the code, but it sure is an
issue to those that write it and have to debug it.  [Actually, the users
never come into it; for all they know the program they are running is
written in Ada.  This is only an issue for developers.]  I agree it is
probably not in CL's domain to address these issues, but it shouldn't
prohibit it.  Maybe another example?

(let ((counter 0))
  (defun hairy-function-counter ()
    counter)
  (defun hairy-function (arg1 ...)
    (incf counter)
    ...big-and-hairy-compuation-bound-to-get-
    called-a-lot-and-have-bugs-that-need-fixing...))

Why, during my debugging cycle, should I be forced to have the counter
reset to 0 each time I need to change hairy-function?

    Date: Thu, 30 Jan 86 13:37:13 pst
    From: mips!escargot.earl@glacier (Earl Killian)

    No one has suggested that making DEFUN inside of LET not work is the
    right thing (people have suggested that it may not be required by the
    current wording of the Common Lisp manual).  If someone feels that
    DEFUN inside of LET shouldn't work, they ought to speak up!

I have reservations.

∂30-Jan-86  1811	GJC@MC.LCS.MIT.EDU 	editing environments
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 30 Jan 86  18:11:07 PST
Date: Thu, 30 Jan 86 21:12:29 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject:  editing environments
To: DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA, Fahlman@C.CS.CMU.EDU
In-reply-to: Msg of Thu 30 Jan 86 16:08 EST from David C. Plummer <DCP at SCRC-QUABBIN.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].802352.860130.GJC>

I guess what you can say is that the 'text editor' (human readable)
will sectionalize the buffer in such a way so that a compile-region
is meaningfull only for the entire top-level-form, so that the question
of 'the environment editor' doesnt come up. 

But lets face it, CL, as defined, is very compile-whole-file oriented.
It doesnt take into account very well the programming environment style
that has been in use with Emacs/LEDIT/MACLISP on the PDP-10 and the
Lispmachine for at least a decade. Constructs such as (in-package ...)
and (eval-when (compile) (setq *readtable* ...)) etc that cause the
most painful confusion to even our best attempts at making our program
editors deal with such thing are, in the final analysis, far too unconstrained
to be able to expect a uniform and well understood behavior.

It will be very difficult to come up with a workable model.
Greenblatt had some suggestions recently in private correspondence
that harken back to certain tricks that the famous MDL compiler "COMBAT"
used. Such analogies however do not add any comfort to the situation.

-gjc

∂30-Jan-86  1930	FAHLMAN@C.CS.CMU.EDU 	Defun inside Let  
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 Jan 86  19:23:20 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 30 Jan 86 22:23:40-EST
Date: Thu, 30 Jan 1986  22:23 EST
Message-ID: <FAHLMAN.12179509449.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   common-lisp@SU-AI.ARPA
Subject: Defun inside Let


I was about to reply to Plummer's objections, but discovered that others
had already said most of what I want to.  I agree with Jonathan Rees and
with Rob Maclachlan on this issue.

It is certainly true that for debugging purposes, there are some useful
things that a Common Lisp environment might supply to make people with
debugging styles like Plummer's more comfortable.  For example, it might
be nice to be able to grab a function's definition and say "I want to
define an additional function in the same lexical environment that
this guy sees" or "I want to redefine this function, but continue using
the lexical environment of the old definition (plus the following
additional lexical variables)".  In most Common Lisp interpreters I have
seen (and all of the ones I've written), it's pretty trivial to add
that, though it does require descending to system-internal levels to do
it.

Nothing in Common Lisp makes this impossible or even very hard.  We
could probably add a standard set of hooks to make such a feature
portable if we tried hard enough, but after all the hassle we went
through to put in the evalhook stuff, I'm not eager to go through that
sort of exercise again.  Let the manufacturers compete to produce the
best debugging environment, each consistent with his machine's style and
philosophy of user interaction.

It is much harder to add such facilities for modifying compiled
functions that share a lexical environment.  The easy way to do this
would be to follow the trail back to the source code, make the changes
the user wants, and then recompile the whole top-level form which
defines the lexical environment in question.  I'm quite content to do
this by hand, but there's no reason that someone couldn't write a
package to do it automatically, much as flavor methods are now
recompiled when you change anything.

-- Scott

∂30-Jan-86  2050	meehan@YALE.ARPA    
Received: from YALE.ARPA by SU-AI.ARPA with TCP; 30 Jan 86  20:49:53 PST
Received: by Yale-Bulldog.YALE.ARPA; 30 Jan 86 23:47:30 EST (Thu)
Date: 30 Jan 86 23:47:30 EST (Thu)
From: James Meehan <meehan@YALE.ARPA>
Message-Id: <8601310447.AA06340@Yale-Bulldog.YALE.ARPA>
To: common-lisp@su-ai.arpa

[This may be a duplicate message.  Our mail system is ill.]

I remember seeing some bboard mail on this topic, but I don't remember whether
there was a consensus:  Is Common Lisp supposed to allow DEFUN inside
LET?  I know I can say
    (setf (symbol-function 'foo) #'(lambda ...))
and get much the same effect, but that's more awkward.


∂30-Jan-86  2055	FAHLMAN@C.CS.CMU.EDU
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 Jan 86  20:55:24 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 30 Jan 86 23:55:50-EST
Date: Thu, 30 Jan 1986  23:55 EST
Message-ID: <FAHLMAN.12179526230.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   James Meehan <meehan@YALE.ARPA>
Cc:   common-lisp@SU-AI.ARPA
In-reply-to: Msg of 30 Jan 1986  23:47-EST from James Meehan <meehan at YALE.ARPA>


Your mail system must be ill.  Your earlier message arrived and has
sparked a furious debate on the Common Lisp mailing list.  I thought it
was a simple question, but apparently there's no such thing in this
forum.

-- Scott

∂31-Jan-86  0906	DLW@SCRC-STONY-BROOK.ARPA 	Defun inside Let  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 31 Jan 86  09:06:15 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 406162; Fri 31-Jan-86 12:04:41-EST
Date: Fri, 31 Jan 86 12:06 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Defun inside Let
To: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12179423154.BABYL@C.CS.CMU.EDU>
Message-ID: <860131120618.3.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Thu, 30 Jan 1986  14:29 EST
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    There can be no question at all on the point Jeff Dalton raises: when a
    Defun occurs inside a Let or anywhere else, it changes the GLOBAL
    function definition for the symbol in question.  It is not a form of
    LABELS.

Agreed.  This is completely clear from the manual.  If DEFUN inside LET
is valid Common Lisp (I think it is, modulo the general smokescreen of
the page 66 paragraph), then it changes the global definition.

∂31-Jan-86  0938	DLW@SCRC-QUABBIN.ARPA 	Defun inside Let 
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 31 Jan 86  09:38:01 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 240693; Fri 31-Jan-86 12:35:03-EST
Date: Fri, 31 Jan 86 12:37 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Defun inside Let
To: DCP@SCRC-QUABBIN.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <860130210351.3.DCP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <860131123758.6.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Thu, 30 Jan 86 21:03 EST
    From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>

    That's right, I am bothered by programming environment.  
							     I agree it is
    probably not in CL's domain to address these issues, but it shouldn't
    prohibit it.  Maybe another example?

I believe that all the problems you've been talking about have to do
with the poor interaction between lexical scoping and incremental
programming.  These poor interactions are discussed in the paper "The
Art of the Interpreter:  Parts Zero, One, and Two" by Guy Steele and
Gerry Sussman.  They are not incidental design flaws of Common Lisp;
they are part of the deep nature of lexical scoping.  I don't think they
represent a "time bomb" in the language.  They just show how lexical
scoping, itself, has problems when it comes to program development, when
used in this way.  I don't think any language change is called for.  If
anybody writes a textbook or something that makes recommendations about
programming practices and styles, though, they should take these
problems into account.

I hope Steele will correct me if I'm wrong.

∂31-Jan-86  1806	OLDMAN@USC-ISI.ARPA 	Defmacro inside of a let
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 31 Jan 86  12:33:37 PST
Date: 31 Jan 1986 15:33-EST
Sender: OLDMAN@USC-ISI.ARPA
Subject: Defmacro inside of a let
From: OLDMAN@USC-ISI.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]31-Jan-86 15:33:44.OLDMAN>
Comment: Remailed at SU-AI after delay caused by mailing list error.

We all agree that a defun should be ok inside a let.  Why does
the language explicitly state that a defmacro evaluated inside a
let is ok but must IGNORE the lexical environment?  (See the
first paragraph on page 145 of CLtL.)

-- Dan

∂31-Jan-86  1806	OLDMAN@USC-ISI.ARPA 	&environment  
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 31 Jan 86  12:50:28 PST
Date: 31 Jan 1986 15:43-EST
Sender: OLDMAN@USC-ISI.ARPA
Subject: &environment
From: OLDMAN@USC-ISI.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]31-Jan-86 15:43:34.OLDMAN>
Comment: Remailed at SU-AI after delay caused by mailing list error.

Are there any restrictions on placement of the &environment
marker in a lambda list?  Our implementation currently requires
that it be either after an &body or first if there is no &body.

-- Dan

∂31-Jan-86  1808	OLDMAN@USC-ISI.ARPA 	deftype with &key  
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 31 Jan 86  12:58:27 PST
Date: 31 Jan 1986 15:58-EST
Sender: OLDMAN@USC-ISI.ARPA
Subject: deftype with &key
From: OLDMAN@USC-ISI.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]31-Jan-86 15:58:40.OLDMAN>
Comment: Remailed at SU-AI after delay caused by mailing list error.

In the area of minor cleanup, I propose that deftype add &key to
its list of legal lambda-list markers.  I don't see why it is not
there now and it seems that it would be occationally useful.

-- Dan

∂31-Jan-86  2156	OLDMAN@USC-ISI.ARPA 	Defmacro inside of a let
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 31 Jan 86  12:33:37 PST
Date: 31 Jan 1986 15:33-EST
Sender: OLDMAN@USC-ISI.ARPA
Subject: Defmacro inside of a let
From: OLDMAN@USC-ISI.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]31-Jan-86 15:33:44.OLDMAN>
Comment: Remailed at SU-AI after delay caused by mailing list error.

We all agree that a defun should be ok inside a let.  Why does
the language explicitly state that a defmacro evaluated inside a
let is ok but must IGNORE the lexical environment?  (See the
first paragraph on page 145 of CLtL.)

-- Dan

∂31-Jan-86  2228	FAHLMAN@C.CS.CMU.EDU 	&environment 
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 31 Jan 86  21:59:09 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 1 Feb 86 00:59:29-EST
Date: Sat, 1 Feb 1986  00:59 EST
Message-ID: <FAHLMAN.12179799956.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   OLDMAN@USC-ISI.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: &environment
In-reply-to: Msg of 31 Jan 1986  15:43-EST from OLDMAN at USC-ISI.ARPA


Lacking any evidence to the contrary, I would think that &environment
should be allowed to appear anywhere in the lambda list.  Is it really
important to you that the location be restricted?  I can't see why it
would be.

-- Scott

∂31-Jan-86  2306	OLDMAN@USC-ISI.ARPA 	&environment  
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 31 Jan 86  12:50:28 PST
Date: 31 Jan 1986 15:43-EST
Sender: OLDMAN@USC-ISI.ARPA
Subject: &environment
From: OLDMAN@USC-ISI.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]31-Jan-86 15:43:34.OLDMAN>
Comment: Remailed at SU-AI after delay caused by mailing list error.

Are there any restrictions on placement of the &environment
marker in a lambda list?  Our implementation currently requires
that it be either after an &body or first if there is no &body.

-- Dan

∂31-Jan-86  2337	OLDMAN@USC-ISI.ARPA 	get-setf-method-multiple-value    
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 31 Jan 86  12:50:43 PST
Date: 31 Jan 1986 15:49-EST
Sender: OLDMAN@USC-ISI.ARPA
Subject: get-setf-method-multiple-value
From: OLDMAN@USC-ISI.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]31-Jan-86 15:49:30.OLDMAN>
Comment: Remailed at SU-AI after delay caused by mailing list error.

Could anyone give me some motivation for the existance of this
function?  I don't understand what is ment by storing multiple
values into a generalized variable.

-- Dan

∂01-Feb-86  0025	OLDMAN@USC-ISI.ARPA 	deftype with &key  
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 31 Jan 86  12:58:27 PST
Date: 31 Jan 1986 15:58-EST
Sender: OLDMAN@USC-ISI.ARPA
Subject: deftype with &key
From: OLDMAN@USC-ISI.ARPA
To: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]31-Jan-86 15:58:40.OLDMAN>
Comment: Remailed at SU-AI after delay caused by mailing list error.

In the area of minor cleanup, I propose that deftype add &key to
its list of legal lambda-list markers.  I don't see why it is not
there now and it seems that it would be occationally useful.

-- Dan

∂01-Feb-86  0051	Moon@SCRC-STONY-BROOK.ARPA 	Retraction  
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 31 Jan 86  17:19:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 406640; Fri 31-Jan-86 20:17:17-EST
Date: Fri, 31 Jan 86 20:18 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Retraction
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860131201842.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comment: Remailed at SU-AI after delay caused by mailing list error.

    Date: Thu, 30 Jan 86 21:02 EST
    From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
    Subject: Defun inside Let

    Let me put it this way.  It's easy enough to say that (LET ... (DEFUN
    FOO ...)) has the same effect as (LET ... (SETF (SYMBOL-FUNCTION 'FOO)
    #'(LAMBDA ...))), and in fact I know of no implementation where that is
    not already true.

As a couple of people have pointed out to me, they do not have the same
effect in Symbolics Release 6.1.  I apologize for leaping without
looking.  I assumed that because it worked in the newer software I was
running, I didn't need to check whether it worked in the released
version.  I'll try to be more careful about opening my mouth in the future.

Anyway, the point I was trying to make was that we all agree that those two
forms are equivalent.  The questions are (less important) does Common Lisp
say that these are legal forms, and (much more important) does Common Lisp
presently contain everything needed to effectively make use of that
programming technique.

∂01-Feb-86  0713	RAM@C.CS.CMU.EDU 	Defmacro inside of a let   
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 Feb 86  07:13:17 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sat 1 Feb 86 10:13:42-EST
Date: Sat, 1 Feb 1986  10:13 EST
Message-ID: <RAM.12179900850.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To:   OLDMAN@USC-ISI.ARPA
Cc:   common-lisp@SU-AI.ARPA
Subject: Defmacro inside of a let


    That's because the compiler wants to be able to evaluate macros at
compile time.  It would be impossible to compute the lexical
environment of a macro definition without actually interpreting the
surrounding code.  This is basically impossible, and is almost
certainly not what you want.  It is more obvious in the case of
MACROLET, which is usually embedded in random code somewhere.  This is
explained to some degree on page 114.

    If you really want a closure as macroexpansion function, you can 
(setf (macro-function 'foo) #'(lambda (form env) ...))
In this case there is no problem, since the macro won't be defined
until the form is evaluated, in which case its environment will be
available.

  Rob

∂01-Feb-86  0805	FAHLMAN@C.CS.CMU.EDU 	Retraction   
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 Feb 86  08:05:42 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 1 Feb 86 11:05:57-EST
Date: Sat, 1 Feb 1986  11:05 EST
Message-ID: <FAHLMAN.12179910348.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc:   Common-Lisp@SU-AI.ARPA
Subject: Retraction
In-reply-to: Msg of 31 Jan 1986  20:18-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>


    Anyway, the point I was trying to make was that we all agree that those two
    forms are equivalent.  The questions are (less important) does Common Lisp
    say that these are legal forms, and (much more important) does Common Lisp
    presently contain everything needed to effectively make use of that
    programming technique.

I believe that the consensus is that they are legal forms, the waffling
language about top-level forms notwithstanding.  And I feel strongly
that the language has everything NEEDED to effectively make use of that
programming technique.  We are missing a few things that would make it
more CONVENIENT, but those can easily be added on an
implementation-specific basis.

-- Scott

∂01-Feb-86  1235	Moon@SCRC-QUABBIN.ARPA 	get-setf-method-multiple-value 
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 1 Feb 86  12:35:27 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 241003; Sat 1-Feb-86 15:32:32-EST
Date: Sat, 1 Feb 86 15:35 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: get-setf-method-multiple-value
To: OLDMAN@USC-ISI.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[USC-ISI.ARPA]31-Jan-86 15:49:30.OLDMAN>
Message-ID: <860201153520.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 31 Jan 1986 15:49-EST
    From: OLDMAN@USC-ISI.ARPA

    Could anyone give me some motivation for the existance of this
    function?  I don't understand what is ment by storing multiple
    values into a generalized variable.

(setf (values a b c) (foo x y)) is a simple example.  Presumably
this expands into (multiple-value-setq (a b c) (foo x y)).  A
more interesting example would be 
(setf (values (aref a i) (aref a j) (aref a k)) (foo x y))

This is a possible extension rather than standard Common Lisp because
some people thought it was too complicated and hard to understand,
although to me it seems like an obvious symmetry.

∂01-Feb-86  1500	Moon@SCRC-STONY-BROOK.ARPA 	deftype with &key
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 1 Feb 86  15:00:27 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 407198; Sat 1-Feb-86 17:58:40-EST
Date: Sat, 1 Feb 86 18:00 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: deftype with &key
To: OLDMAN@USC-ISI.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[USC-ISI.ARPA]31-Jan-86 15:58:40.OLDMAN>
Message-ID: <860201180011.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 31 Jan 1986 15:58-EST
    From: OLDMAN@USC-ISI.ARPA

    In the area of minor cleanup, I propose that deftype add &key to
    its list of legal lambda-list markers.  I don't see why it is not
    there now and it seems that it would be occationally useful.

I don't know why it's not there either.  We put it into our DEFTYPE.

∂01-Feb-86  1630	GJC@MC.LCS.MIT.EDU 	Retraction
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 1 Feb 86  16:25:55 PST
Date: Sat,  1 Feb 86 19:27:28 EST
From: "George J. Carrette" <GJC@MC.LCS.MIT.EDU>
Subject:  Retraction
To: Moon@SCRC-STONY-BROOK.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-reply-to: Msg of Fri 31 Jan 86 2